故障处理二则

今天解决的2个问题

1、总结：节点资源可能影响应用和rocketmq的通信

现象：

1、服务重启后一直连接不上rocketmq，提示与broker心跳保持失败；
2、在阿里云rocketmq上查看客户端，提示客户端离线；
3、该服务并无发版和其他资源异常，服务上的HTTP接口响应正常；
4、通过TCPDUMP抓包未发现明细传输层异常；

环境：
rocketmq 连接方式： tcp

解决方式：

通过将pod调度到不同的节点，解决此问题；将pod调度回问题节点，问题可复现。

总结：
因为节点的网络资源占用较高，可能会引起同节点上服务和rocketmq的心跳保持中断。

========================================================

2、总结：服务的资源上升，并不一定是服务自身的代码问题导致，也可能来自于外部请求的增高；

现象：

1、应用市场服务的POD CPU突然上升，居高不下；
2、通过对服务的横向扩容，依然无法解决此问题；
3、回退代码并没有解决此问题；
4、该服务提供的都是HTTP接口；
5、POD内的业务日志不全，记录信息没有参考价值；

分析：
1、通过POD完整监控分析，发现CPU上升时入站带宽同时上升，初步分析是外部请求增加导致的问题；
2、通过对接口请求总量环比、同比的对比分析，发现当天同时段请求量翻倍，由 2千万变成今天的4千万，锁定是请求激增导致；
3、通过对请求量和负载的计算，当单POD资源为5核时，每秒1万次请求会将服务CPU打爆；

总结

1、需要对核心接口进行防攻击保护，这种攻击可能来自内部也可能来自外部，限流和熔断策略需要加上；
2、需要增加业务监控，针对可能出现的业务问题进行提前扩容和预警，例如执行完某业务后必然会出现另一个业务的请求量增加；
3、需要对POD服务进行压力测试和性能压榨，提高资源利用率；
4、限流需要和资源情况进行结合，当达到服务支撑的最大阈值并且无法扩容，那么限流策略要自动触发，或者根据IP进行针对接口的限流进行服务保护；
5、高频请求接口或有崩溃风险的接口进行风险隔离，最大可能保护其他服务不受干扰；
6、关于服务压测，需要的不仅仅是压测的请求量和资源使用率的数据，还需要对内存快照进行抓取，以挖掘内存中潜在的问题。