记服务上线的一个坑

经过

今天将测试环境中测试通过后的服务很小心地不熟到线上后，自以为万事大吉，就坐等客户端发布版本了。谁知道测试在验证正式环境的服务时，不断地报超时。而这在测试环境中是经过多次的测试，并且都是通过的，真是日了个狗的。第一反应当然是怀疑自己部署到线上的时候，是否配置弄错了。查了大半天，都是一样的！由于版本未发，因此就在正式环境中打些日志出来，看看发生了什么事情。后来定位到，是一个PHP前端将客户端发来的包转到后端服务的时候，后端服务收到的包得长度总是为0，后端服务由于请求为0，因此就没有响应返回，导致PHP前端总是超时。真是日了个狗的，而此时经理和一群队友都在等着我解决问题，脑袋也不灵活了，不断地怀疑自己究竟是哪里配错了，正式环境跟测试环境究竟哪里有不同之处。找了好长时间，都没有找到问题。后来，由于在抓包的时候，发现后端服务监听的端口的流量有异常，就怀疑是不是监听的端口有问题。于是就将监听的端口有5000换到82222。神奇的一幕发生了，服务正常了... ...估计，有大量的包长度为0的包发送到5000端口，然后导致PHP前端发送的包都给丢掉了... ...这次真是踩到了坑上了，这从下午五点，一直查找问题到晚上九点多才解决... ...

总结

1. 百度内部的坑多，踩到了只能认栽
2. 一开始，用tcpdump抓包的时候，是发现到5000端口有异常的流量过来的，但是没有太留意，这只能说自己的经验还是不足。如果能对这敏感些，说不定很快就解决问题了，而不是总是怀疑自己的配置有问题。
3. 今天的压力太大了，又累，一堆人围着，又心急，导致脑袋都不正常使用了。如果使用的环境能标准化一些，上线流程嫩更加自动化一些，估计就不会怀疑是自己配置的问题了。
4. 问题估计最大的还是测试跟线上的环境不一致，导致服务从部署得到线上时容易出现问题。哎，这个也不是自己能够解决的，有历史遗留的问题。