【工做随笔】两个线上问题（不停机发布&大型字符串hashcode出现负数）以及解决方案

      自从去年11月入职新公司后，工做职责忽然扩大了，不只仅是测试开发，连部分QA的活也干了，这其中就包含了线上发布。

      说实话，从11年工做到如今，第一次接触到项目发布，而后就发现了几个比较有记念性的问题：

      问题一 ：不停机发布 && 没有关闭服务入口致使脏数据。

      系统架构：    咱们这个系统是用户经过web调用service，service作用户登陆校验和各系统调用，business系统就是其中一个系统。

     系统使用状况: 这个系统是给公司经销商和内部人员用，用户不到1500，使用频率更是一月5~6次。

      之前提发布流程，我都是只提单要求发布对应服务。此次也不例外，直接部署business。没想到碰巧有个经销商在提报活动，根据后来我查数据以及比对代码，代码是已经走到business的事务里，调用了额度系统，准备调用审批流程系统时，服务刚好重启，即若是审批流程系统没有数据，这个事务也没了，活动表也就没有数据。咱们business作的事务一致性只能保证其余服务挂了时会回滚数据，本身系统重启就只能毫无办法，咱们系统也没有定时任务给重要的数据作数据一致性检查，因此这个问题直到昨晚由于经销商一个普通咨询才发现。 综合考虑，这种问题仍是在发布的时候就能够防范，发布时直接先把web停了，发布好business再启动web，左右不过几分钟的事，却能避免一些诸如：经销商钱被吞了一部分这种大问题。

 

       问题二：一个线上才会出现的问题。

      公司重质量重视到严格执行测试流程的地步，不压缩测试时间。因此这个变动我是在release分支测试结束后，代码反合再合并到master分支后回归测试主流程，都没问题。发现线上后，借了业务帐号再试，结果发现了一个坑。流程系统在流程拒绝后不发消息了，由于开发为了让不一样系统发出的消息有顺序的被业务系统消费，将非数字型code取hashcode再排序，因为线下数据少，不会出现问题。线上数据多，code取hashcode后变负数，就不发消息了。   这个问题经过黑盒测不到，由于这个不是业务需求，只能经过代码走查方式了提早发现。再否则就是等用户发现不对后，前来反馈。

 

     解决方法：

       项目开发过程当中，需求文档只能做为方向，具体小细节仍是每一个开发人员本身定，这就致使了有些问题测试发现不了，上面的问题二就是这种状况。至于停机发布，我所经历的项目都没有停机发布过，最可能是选择一个用户使用频率低的时间范围发布，因此问题一的状况也避免不了。 

      既然问题没法从源头解决，那能够换个思路，启用数据检查机制。就像人类没法让本身不生病，可是能够按期体检同样。可使用脚本或者存储过程对数据库里重要的那部分数据进行按期检查，检查时间则参考各个项目。