Java 微服务随机掉线排查过程

点击上方“芋道源码”，选择“设为星标”

管她前浪，还是后浪？

能浪的浪，才是好浪！

每天 10:33 更新文章，每天掉亿点点头发...

源码精品专栏

 

• 原创 | Java 2021 超神之路，很肝~
  

• 中文详细注释的开源项目
  

• RPC 框架 Dubbo 源码解析

• 网络应用框架 Netty 源码解析
  

• 消息中间件 RocketMQ 源码解析
  

• 数据库中间件 Sharding-JDBC 和 MyCAT 源码解析

• 作业调度中间件 Elastic-Job 源码解析

• 分布式事务中间件 TCC-Transaction 源码解析

• Eureka 和 Hystrix 源码解析

• Java 并发源码

来源：cnblogs.com/lyalong/

p/17089373.html

• 背景

• 案发

• 排查和解决

• 完结感言

---

背景

我们的业务共使用 11 台（阿里云）服务器，使用 SpringcloudAlibaba 构建微服务集群, 共计 60 个微服务, 全部注册在同一个 Nacos 集群。

流量转发路径：nginx -> spring-gateway -> 业务微服务。

使用的版本如下：

• spring-boot.version：2.2.5.RELEASE

• spring-cloud.version：Hoxton.SR3

• spring-cloud-alibaba.version：2.2.1.RELEASE

• java.version：1.8

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

• 视频教程：https://doc.iocoder.cn/video/

案发

春节放假期间收到反馈，网页报错服务未找到（gateway 找不到服务的报错提示）。查看 nacos 集群列表，发现个别服务丢失 （下线）。

这个问题每几天出现一次, 出现时间不固定, 每次掉线的服务像是随机选的几个。服务手动 kill+restart 后能稳定运行 2-3 天。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

• 项目地址：https://github.com/YunaiV/yudao-cloud

• 视频教程：https://doc.iocoder.cn/video/

排查和解决

怀疑对象一：服务器内存爆了

进阿里云控制台查看故障机器近期的各项指标，但是发现故障机器的指标有重要的几项丢失。内存使用率、CPU 使用率、系统负载均不显示。

控制台看不了只好进服务器内查看各指标，free -m 查看内存无异常。提交阿里工单。授权阿里工程师帮忙修复控制台显示问题，怀疑这个问题对业务有影响。

控制台修复后掉线问题依然存在。

怀疑对象二：CPU满载

能感觉到执行命令很流畅，所以感觉不是这个原因。top 查看后很正常。

怀疑对象三：磁盘满了

虽然概率很小，但是 du -sh * 看一下，发现磁盘容量还能用到公司倒闭。

怀疑对象四：网络有问题

• 服务器那三个基本故障暂时排除后，最大怀疑对象就是网络。毕竟服务掉线肯定是服务端一段时间内接收不到客户端心跳包，所以把客户端踢下线了。

• 通过 telnet,mtr -n ...,netstat -nat |grep "TIME_WAIT" | wc -l 这些命令也只能看个大概。

• echo "1" > /proc/sys/net/ipv4/tcp_tw_reuse 修改内核参数，开启 TIME_WAIT socket 复用能力，提升实例的网络发送请求性能。

• 查看 nacos 客户端（微服务）的日志，在前面案发里提到没有日志记录。

怀疑对象五：Nacos 集群服务端故障

1. 查看 nacos 集群部署的那几台服务器, 查看服务器基础指标 (内存、CPU、磁盘等），未发现异常 （毕竟还有几十个微服务都很正常工作）。

2. 查看 nacos 服务端日志，发现确实有主动下线服务操作。那就奇怪了，这个机器上的有些服务还在正常工作，为什么会随机下线几个服务呢？

怀疑对象六：微服务占用资源太多

后来仔细想想，这个怀疑对象是不是有点离谱了？ 因为部署脚本都是同一个，而且负载均衡也是一样的。 但其他机器的这个服务都好好的。

1. 调大每个微服务的内存占用。

2. 添加堆栈打印。

1. 等待一段时间后，异常依然存在，并且没有堆栈打印？因为进程好好的并没退出。

2. google 搜索 nacos 服务掉线，找到一篇看起来极其靠谱的文章。

1. 上文提到我使用的 springcloud 版本，恰好这个版本的 nacos-client 版本就是 1.4.1， 于是立马测试升级。

1. 观察几天后，发现问题依旧，只能将探查方向继续转回微服务本身。

2. 用 arthas 进行勘测各项指标，发现所有正常的服务各指标均正常。

3. 想到服务掉线大概率是因为心跳包丢失，怀疑是心跳线程因为某些原因被杀死了。

4. 翻看 nacos-client 源码，找到心跳函数（nacos2.x 不是这个），使用 arthas 监听心跳包，尝试能找到心跳丢失的证据，贴上当时的记录。

1. 当异常再次发生，arthas 监听卡死，无任何记录和响应。

2. 无奈更换思路，写一个监听服务掉线的程序，期望可以在工作时间内及时获取到异常。

1. 终于在工作时间捕获到异常，第一时间进入服务器内查看情况。

1. 确认服务器基础项没问题后，使用 arthas 查看服务进程堆栈情况，但是 arthas 无法进入进程。

1. 用 jstat 查看 GC 情况，显示很正常。

1. 用 jmap/jstack 输出堆栈 jstack -l 25944 >heap.txt，但是提示无法进入进程。无奈使用添加 - F（这个参数的堆栈少了很多信息），jstack -F -l 25944 >heap.txt

2. 查看堆栈文件上万行记录，眼都看花了但是没有死锁也没有发现异常。

3. 此时发现监听程序提示服务上线了？检查后发现确实掉线的几个微服务自动恢复了，心想这就难排查了。

4. 尝试复现 Bug，此时离第一次案发已经过去一周多，必须尽快处理好这个 Bug 否则可能得被迫离职了。

5. 当第二次发生异常的时候，使用同样的方式 arthas 无法进入 ->...->jstack 输出堆栈。奇迹发生了，服务又恢复正常了。

6. 思考 / 猜测：因为 JVM 死了（假死），所以导致进程中的一切内容，包括心跳线程、日志等都 hold 住。

7. Google 搜索关键词 JVM 停止（假死）排查，终于找到一个极其靠谱的回答。

1. 连忙查看对比使用的几个机器内核版本号 uname -r。

1. 那个低版本的就是故障机器，确认相关信息后，联系阿里云提交工单。

1. 升级完内核并重启机器后，观察两天至今这个问题不存在了。谁能想到这个问题居然是因为 Linux 内核的 Bug 引起的？！不得不佩服第一个发现这个 Bug 的大佬。

完结感言

这个问题折磨了一周多，每日如鲠在喉！调试过程也是苦乐参半，乐的是突然有了调试思路，苦的是思路是一条死胡同，还好最终结果是满意的。

作为一名程序员，还是要时刻保持一颗探索的心，学海无涯！

---

---

欢迎加入我的知识星球，一起探讨架构，交流源码。加入方式，长按下方二维码噢：

已在知识星球更新源码解析如下：

最近更新《芋道 SpringBoot 2.X 入门》系列，已经 101 余篇，覆盖了 MyBatis、Redis、MongoDB、ES、分库分表、读写分离、SpringMVC、Webflux、权限、WebSocket、Dubbo、RabbitMQ、RocketMQ、Kafka、性能测试等等内容。

提供近 3W 行代码的 SpringBoot 示例，以及超 4W 行代码的电商微服务项目。

获取方式：点“在看”，关注公众号并回复 666 领取，更多内容陆续奉上。

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）