故障排查与性能优化 专栏收录该内容，点击查看专栏更多内容cpu负载高故障排查实战-网关故障导致业务请求堆积
原创 吴就业 159 0 2024-02-06
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://wujiuye.com/article/4c84476ba03b4fa6bdb4246aba50773f
作者：吴就业
链接：https://wujiuye.com/article/4c84476ba03b4fa6bdb4246aba50773f
来源：吴就业的网络日记
本文为博主原创文章，未经博主允许不得转载。
故障现象
收到相关告警，从监控指标看，http请求成功率下降。
网关是虚拟机部署，排查其中一台网关机器，发现CPU基本消耗完。
另外发现，该虚拟机实例的nginx句柄数被消耗完。
重启nginx和网关后，该机器CPU恢复正常。
安装go相关工具，排查到是非对称加密占用了大量CPU资源。
但这期间，CPU又继续飙升。由于nginx到网关是使用https通讯，紧急启用nginx到接入器连接复用，CPU占用率恢复正常。
总结
架构如下，业务app发起https请求，请求先到cdn，cdn通过https回源给nginx，nginx也通过https回源给网关。这里nginx其实是多余的，因为历史问题还要保留，而网关则是七层流量代理。
- akamai只支持https回源，其他cdn厂商支持http回源。
- nginx通过https将请求转发到网关这一段转发没有开启连接复用。
当请求增加的时候，nginx会使用更多的连接进行转发到网关的操作，因为go标准库实现tls握手性能比较差，在一台8核的机器，只能到达2000这个量级，所以当到达某个临界点的时候，握手占用CPU过高，反过头来影响正常的业务请求，导致了业务请求处理变得十分慢（故障时，在nginx的日志上可以找到很多十几秒才返回的请求，但是接入器的逻辑是5s就超时返回，明显是受到CPU的影响），从而客户端不断重试，进一步导致需要更多连接转发到接入器，同时nginx也收到更多来自CDN的连接，最终导致了雪崩（句柄数被用完，CPU占用率一直很高，请求没办法正常处理）
改进措施
- 网关支持对非对称加密的限流
- 消除技术债，移除nginx
#中间件
声明：公众号、CSDN、掘金的曾用名：“Java艺术”，因此您可能看到一些早期的文章的图片有“Java艺术”的水印。