一、总结
问题:【服务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做一些安全策略
- 避免了跨域等问题
- 隐藏后端服务的真实地址和端口,减少直接暴露给互联网的攻击面
以上就是慢接口排查的全过程以及简单的一些思考……
在此抛砖引玉,各位大佬请指点……