慢接口处理思路复盘

一、总结

问题：【服务Z 】内部请求【服务A】接口api，响应时间为5秒（偶发）（阿里云arms接口监控超过4秒会钉钉提醒）

不想看全文的，看下面的结论：

服务-AUI服务暴露入口，UI启动后，服务A-网关服务发生异常重启，造成服务A-UI服务缓存的内部域名地址失效。

解决办法：

重启服务A-UI服务（清除了nginx域名缓存）

二、排查过程

1. 入口

查询arms链路追踪确认报错接口

点击详情确认报错接口

这里再往详细的看，没有报出具体的位置

 2. 页面日志

通过接口查询到具体的业务，此业务有监控耗时，通过Activitiy各工作节点，确认是回调业务系统【服务A】慢。

查询案件数据

 3. 服务Z:日志

如果不熟悉业务下面只能看业务日志了

（如果项目都熟悉，可能定位更快，你可能知道业务运行近况比如最近需求没有改动这块逻辑，那就几乎可以排除是代码问题了，数据库慢会在arms链路追踪报出来，剩下就可以往网络慢了去考虑了.......zzzzz）​​​​​​​

 问题1：服务Z请求之前处理慢；

 问题2：服务Z到服务A网络有问题；

 问题3：服务A处理慢；

​​​​​​​

服务Z发起调用时间和响应时间间隔3秒，那么接口慢就在调用服务A这个过程。

排除问题1；考虑问题2、3

4. 服务A.Z通信方式 

查询服务z调用服务a的地址为：

5. 服务A:日志 

查看服务接口，发现该接口进来后，有记录日志

根据上面的日志平台得知：

服务A在11:00:20秒才进来请求，那么这么就能推测出大概率网络是有问题的。

6. 运维协查

根据请求地址，得知 【k8s服务名】是服务A的前端UI服务，那么再去查看UI日志

（当前前提你得有，不然得让运维添加日志了，我们使用的loki直接收集的k8s集群的日志）

7. 运维排查

运维之前有遇到过此类问题，再看过网关、UI服务后，发现其中一个网关节点在UI服务之后有重启，俩个pod创建时间不一致。

UI服务启动时间为：2024-08-15 19:22:00

网关服务（UI服务没有截到图）

简单的说就是：UI服务作为所有的请求入口，那么他会缓存一些内部域名对应的ip，当请求进来后，缓存了（网关服务的）ip。

后面网关2个节点，其中一个服务发生了重启，UI服务（nginx）缓存的ip失效，当来新的请求时，解析域名走的是缓存，缓存池中2个IP(节点)其中一个重启后ip发生变更了，所以当请求打到缓存旧IP时就会失败！

当他请求失败时，Nginx他会再次重试，当轮询到可访问的ip时就能正常访问了。

三、解决问题

1. 重启UI服务

四、问题思考

1. 为什么会有此问题？

• 集群内部通过集群域名进行访问，当nginx缓存了集群服务X对应的域名后，集群服务X如果进行重启，那么你再想通过nginx访问集群X就有可能找不到服务，单节点可能就直接报错了，多个节点，重试后会恢复。

2.如何避免此问题？

• 服务Z调用服务A不再走UI服务转发，直接调用网关服务。
• 能不能有刷新nginx缓存的方案？——通过upstream参数可以每次都会重新根据DNS解析域名，不会读取缓存。
• 涉及到网关服务升级，确保ui最后启动；

3.还有没有其他替代方案？

目前了解到，目前这种微服务架构通常只会暴露1个入口就是前端nginx，请求后端在通过nginx做转发。

我能不能把网关暴露出去呢？

网关暴露出去不能做一些请求监控，走UI服务一个入口可以依赖nginx抓取请求日志，做请求分析啊、报错分析这些……

使用同一个入口有哪些好处呢？

• 刚才提到了，可以做请求日志、可以借助nginx做一些安全策略
• 避免了跨域等问题
• 隐藏后端服务的真实地址和端口，减少直接暴露给互联网的攻击面

以上就是慢接口排查的全过程以及简单的一些思考……

在此抛砖引玉，各位大佬请指点……