排查思路
一：日志查证
出现问题首先要通过日志查出大概原因，通过入口日志和错误日志进行判断，出现故障大概半个小时。同时发现B机房（故障机房）流量是平时的N倍，A机房流量正常。B机房的网关因为服务超时进入熔断托底流程，而进入托底后，网关的线程释放较慢，线程积压严重，产生大量超时。这是从日志看出来的原因，因为流量陡然激增，然而，B机房的机器有30多台，按照之前压测的tps1k，能承受的压力也是激增的流量。到底是什么问题呢，还需要继续验证。
二：问题复现（压测）
想要找到原因，必须要复现出情况，对于这种情况，可以压出生产的包的最高tps。立即从生产拉下一台gateway机器和服务机器，并mock服务的sleep时间3s，测试熔断的情况。这种情况压测下来，tps压测下来只有80，tps很不正常。接着找时间慢在哪里，查具体线程耗时有个很好的工具Arthas，能跟踪到耗时较慢的方法。发现打印日志，并存到磁盘较慢，开始怀疑是两个环境的磁盘问题。接着就开始用控制变量法进行两个机房的压测，对比两边机房是否有大的区别，结果压测试下来，两个机房的机器性能相差不大，排除机器磁盘问题。根据控制变量法进行压测，压测下来发现是降级时日志量太大造成的tps降低，特别是降级的error日志。最后，对日志的打印进行优化，能打一次的不打两次，降低磁盘io次数，压测后性能明显提升。总结：生产的环境的日志打印要慎重，特别是业务日志，非必要不要打，一旦流量上来，性能影响较大。
后续
虽然这次问题查到了，但是对于后续的开发工作还是有很多思考。
1.对于网关等高tps的服务要进行各种情况的压测，甚至每次修改代码后都应该进行压测。很多问题真的只有压测的时候才能暴露出来，尤其对于性能要求较高的服务。2.重视日志的打印规范，在日常开发中，为了便于排除问题，但是生产不可以随便打日志。日志打印可由架构师用sdk进行统一规范和约束。3.此次压测排除进行了很长时间，一开始的压测有点毫无章法。每次压测要清楚每个环节的具体情况，通过控制变量法和对比才能快速找到原因。
本文分享自微信公众号 - 技术茶话会（coder-party）。
如有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一起分享。