【问题记录】近期开发中遇到的几个问题

1 一个截断问题的记录

        近期开发的系统B遇到一个Bug，经排查发现问题是一个截断导致的。系统的部署情况是：A与B是通过网络进行通信，系统B是多机部署，B之间是对等的。系统的处理流程如下，A发请求1给B，B处理后在响应2中会回带一些信息给系统A，系统A进行一些其他的处理工作，然后将2中B回带的信息通过请求3透传给B，B发现透传过来的信息被截断（1%的概率），导致处理结果非预期。

       问题已经很明确，直接的方案如下：

       方案一：系统A排查哪个环节存在截断，进行修改

       方案二：B系统精简回带给A的信息，或者是进行某种形式的压缩

       方案三：B系统将回带信息存储到某个公共存储，在请求3到来时根据请求的关联字段查出回带信息

 

       鉴于是线上问题，解决方案必须简单快速。A系统逻辑复杂，涉及到的业务众多，通过版本解决的进度慢、涉及面广，时间成本和风险较高。另外，如果A能透传的限制加大，但是B系统仍然对回带信息长度不做限制，未来还会有截断的风险。因此方案一不会优先考虑(跟系统的实际情况紧密相关)。

       由于A系统本来就支持回带透传的功能，B系统自己做信息存储和读取，需要额外的工作量，也会增加系统的复杂性，新的逻辑也会因为新的网络交互，带来一定运行时间开销和潜在风险，改动量也较多。因此方案三也不会有先考虑。

       方案二，经过分析，回带的信息相当多，但最终只是为了请求3到来时，B能根据这些信息选择出要处理某数据库表中的n（n<10，且多行关键字段有相同的值）行中的某行（配置数据）。因此，又有方案：是否可以在请求1的时候将表的行号带出即可？原则上，只要行号没有人、系统去变更，是没有问题的，但是行号并不是配置的内容信息，一旦有人将行号变更，将是很危险的。

       那么是否可以压缩？只是一定程度的解决，同A系统找到截断的地方进行修改是一样的，暂时解决问题也是可以的，但是不是很优。

       将所对应的那行配置中用到的关键信息根据一定的方式算出一个签名，比如md5，进行回传，在处理请求3时，根据md5过滤出该处理的那行。（B系统对报错易容忍，对处理错误难容忍，配置变更找不到会报错）

      

       好，问题基本解决了，修改（新版本兼容老协议）、测试、上线了，上线过程中，运维人员进行了灰度上线，灰度了B中的一台，并且运行了一段时间，才发现问题：没有升级的B处理不了升级的B回带的按新协议回带的md5值，导致未升级的B进行请求3的处理的时候失败了。测试的时候，测试人员并没有将B多机部署，造成问题没有及时发现，酿成问题。

 

       总结一下：

       （1）系统A提供了透传信息的机制，但是当量变不断积累时可能引发质变，导致Bug的出现。开发系统的时候要特别注意，比如打开的文件不断增多，创建的连接不断增多，某些信息越来越长，挂载的so越来越多等，都可能造成量变到质变，发生危险。需要有一定的风险意识，在开发阶段进行评估。

       （2）当协议发生变更时，新版本的系统能兼容老协议，但是老版本的系统无法处理新协议。因此如果确定要做协议，一定是不得已时才确定做，当真的做了协议变更时，一定要重视上线方案的讨论。