记一次网关线上问题----网关无法对外提供服务

## 现象
9月28号上午9:35左右，有个业务同事反馈说我们的业务出现问题了，好像跟网关有关，于是我马上查看网关服务。查看ucenter服务是否正常(ucenter的管理端请求的是网关的服务端)，发现响应异常慢(详见如下图1)，由此可见网关服务响应慢，可以得出其他的应用系统只要请求了网关服务的都应该比较慢。
![](/media/202310/2023-10-10_085946_409001.png)
图1：ucenter服务响应慢
## 排查
查看网关服务的日志，报错了很多TIMEOUT PT30，同时报错信息显示持续在请求某个应用(EAA系统)的某个接口(获取EAA认证信息)，且没有响应。当时来不及截图，这里就不显示图片。
## 推测
由于请求EAA系统的认证接口没有响应，且外围系统(ERP-WEB)持续在请求，因此推测EAA的服务出故障了。接着马上联系了EAA的运维同事查看。同时分析日志：其他的很多TIMEOUT PT30，都显示超时了，因此推测是网关服务阻塞住了。
## 临时解决
为了保证网关可以正常对外提供服务，我们马上关闭了网关请求EAA系统的认证接口。此时网关服务正常了，可以满足正常的其他业务了。
## 排查事故原因
排查网关服务请求EAA应用，发现网关请求EAA服务的超时时间是1800000ms(即1800s,即30分钟)。详见图2
![](/media/202310/2023-10-10_092526_154148.png)
图2：请求EAA服务超时时间
结合到EAA服务没有响应(后面运维部同事排查到原因是网络问题，即请求EAA服务网络可以进去，但是响应无法出来，即形成了阻塞)，由此推测是外围系统持续不断的请求EAA服务，导致网关服务的线程池满了。
## 验证事故原因推测
原始应用流程：ERP-WEB ----> 网关 ----> EAA。
模拟验证流程：压测工具 ----> 网关 ----> 下游系统(写代码阻塞住1800s)
结合模拟验证流程，具体的实施验证过程(一波多折，运维部的兄弟协助解决的)，最终复现了现象，即网关服务被阻塞住(即网关的线程数用完了，网关线程数具体多少没来及收集(这里需要借助三方工具))。
意外收获：验证的过程中正好复现出另外一个问题，即网关服务divide插件中的selector的状态变成close的问题(这个问题在9月28号出现，9月29号开始放中秋国庆假，节后第一天(10月7号)被业务发现了)。原因：divide插件中selector的status由open变成close的原因是管理端admin持续在ping selector中的upstrem url，确保服务响应正常(这个点由网关官方兄弟提供支持确认)。28号时，admin服务持续ping不通EAA服务的upstrem url，导致触发了保护机制，关闭了selector的状态，即这个selector不在向下游系统发送请求，同时保障了其他应用可以正常访问网关。总结：超负载的情况下，admin ping不通selector中的handle，此时出发保护机制，将status由open变成close。
## 制定解决方案
1.减少请求EAA系统的超时时间，目前是1800s。减少后，一旦达到超时时间，线程池立马会释放出这条线程，给下一个请求使用。但是这样需要上游系统修改每次传输给EAA系统的数据量。----最是最理想的方案
2.采用限流的方式来解决这个问题。这里是为了解决高并发场景下，线程被用完的场景。本集团实际的业务，ERP-WEB系统开了17个线程，每个线程对应一个业务接口，每个线程都是同步执行，即假设每个线程当天要发送1w条记录，以2500作为基准，同步发送4次，即第一次发送成功了，再发送第二次。其他线程类同。在加上其他系统请求EAA，同时请求的话，约20多个线程同时执行，并发数其实不算高。总结本集团的这个业务场景并发不高，不代表以后的业务中不存在并发高的场景，因此加上个限流插件保险，主要解决selector中的handle 被admin ping不通的场景。
## 验证解决方案
我们采用网关中的Hystrix插件来做限流处理，设置好相关的参数后，采用压测工具进行测试，得出的结论是：高并发场景下，selector中的status值没有被更新成close，且熔断生效了，即熔断措施可以保证selector持续正常。因此，采用这种方案来解决本次事故遇到的问题。
备注一张9月28号事故时的CPU负载图
![](/media/202310/2023-10-10_101419_048557.png)
说明：CPU是4c，由图明显的看出，cpu负载超过4了，因此导致网关服务超负载了，不会对外提供服务了。