没错，使用Nacos踩坑了

问题发现

就在这周&＃xff0c;我接到 MSE Nacos 用户的反馈&＃xff0c;说线上 Nacos 不可用&＃xff0c;服务都下线了&＃xff0c;日志里面也是一堆报错&＃xff0c;我下意识以为线上炸了&＃xff0c;赶紧上线排查。本文主要记录这次问题的排查过程&＃xff0c;以及解决方案。

首先看用户反馈的报错&＃xff0c;日志如下&＃xff1a;

并且用户反馈业务日志也出现了大量的服务地址找不到的报错&＃xff0c;说明 Nacos 服务都下线了。

我立刻查看了服务端的监控&＃xff0c;发现用户的 MSE Nacos 集群并无异常&＃xff0c;cpu/内存等指标有下降&＃xff0c;并没有异常行为&＃xff0c;排除了服务端异常的可能性。

随即将视线聚焦在了客户端。老实说&＃xff0c;这个报错我第一次见&＃xff0c;看异常堆栈&＃xff0c;字面意思便是域名解析出问题了。这个报错大概持续了 10 分钟&＃xff0c;立刻让用户在业务节点上使用 ping、dig 等工具确认域名解析是否正常&＃xff0c;测试发现均无异常。继续让用户 telnet mse-xx.com 8848&＃xff0c;发现也能够 telnet 通。

根据这些现象&＃xff0c;大概能得出结论&＃xff1a;用户的机器上出现了短暂的域名解析问题&＃xff0c;导致短时间访问不通 MSE Nacos。但用户继续反馈说&＃xff0c;一部分重启以后的机器已经恢复了&＃xff0c;但没有重启的机器&＃xff0c;竟然还会出现调用报错。不然怎么说重启大法好呢&＃xff0c;但也加深了问题的诡异性。

正当一筹莫展时&＃xff0c;另一用户也找上来了&＃xff0c;竟然也是一样的问题&＃xff0c;并且由于第二个用户还同时使用了 redis&＃xff0c;报错日志中除了出现 nacos 的域名解析问题&＃xff0c;还报了 redis 的域名解析报错。至此&＃xff0c;更加坚定了我之前推测&＃xff0c;根因肯定是域名解析出现了故障&＃xff0c;导致这两个用户收到了影响。但问题在于&＃xff0c;为什么短暂的域名解析失败&＃xff08;大概 10 分钟&＃xff09;&＃xff0c;会导致持续性的 Nacos 问题呢&＃xff1f;并且只有重启才能恢复。

分析两个用户的共性&＃xff0c;最终我和同事将可疑点锁定在了 Nacos 客户端版本上&＃xff0c;对比发现&＃xff0c;用户都是同一个报错&＃xff0c;并且竟然都是 nacos-client 1.4.1 版本。

Nacos 1.4.1 版本引入的 bug

在问题发生时&＃xff0c;Nacos 1.x 最新的版本已经是 Nacos 1.4.2 了&＃xff0c;将源码 checkout 到 1.4.1 版本&＃xff0c;追踪堆栈附近的问题&＃xff0c;

上述这段代码是 Nacos 访问服务端的一段代码&＃xff0c;进入 595 行&＃xff0c;一探究竟。

我们成功找到了堆栈中的直接报错&＃xff0c;就是这段 IsIPv4 的判断触发。splitIPPortStr 这个方法的主要逻辑是从 Nacos 的连接串筛选出连接地址&＃xff0c;主要是为了做默认端口号的判断&＃xff0c;如果用户没有携带 8848&＃xff0c;会默认带上 8848。

但问题恰恰便是出现在这儿&＃xff1a;

InetAddress.getByName(addr) 是一个内置的方法&＃xff0c;描述如下&＃xff1a;

Given the name of a host, returns an array of its IP addresses, based on the configured name service on the system.


意思是把一个域名传给操作系统&＃xff0c;返回一串 IP&＃xff0c;这不就是域名解析吗&＃xff01;我当时就很好奇&＃xff0c;你说你判断 IPv4 格式&＃xff0c;为啥要这么判断呢&＃xff1f;直接判断 IPv4 的 pattern 不行吗&＃xff1f;而这段代码&＃xff0c;恰恰是导致问题的凶手之一。

我们看看 1.4.2&＃xff0c;已经修复了这个逻辑了&＃xff0c;直接改成了正则判断。

但疑问还是存在的&＃xff0c;域名解析短暂失败了&＃xff0c;为啥会导致服务全都下线了&＃xff0c;并且解析恢复后&＃xff0c;服务依旧没有上线呢&＃xff1f;

继续追踪这段代码&＃xff0c;发现 callServer 这段代码会被 com.alibaba.nacos.client.naming.beat.BeatReactor 持有&＃xff0c;用于维持自身和 Nacos 的心跳。

而由于上述域名解析失败&＃xff0c;抛出的异常是 IllegalArgumentException&＃xff0c;并没有被里层方法转换成 NacosException&＃xff0c;从而导致心跳线程没有 catch 住异常&＃xff0c;彻底停止发送心跳了&＃xff01;

这也就成功解释了&＃xff0c;为什么短暂的域名解析失败&＃xff0c;会导致服务全部下线了。&＃xff08;Nacos 是利用心跳维护和 server 端的存活状态的&＃xff09;

改进建议

1. 修改 isIPv6 和 isIPv4 的判断方式&＃xff0c;改为正则匹配。上文提及&＃xff0c;这点已经在 1.4.2 修复了。

2. 心跳线程要保证不被异常中断下一次心跳的提交。

第二点&＃xff0c;也已经被修复了。

总结

nacos-client 1.4.1 存在严重的 bug&＃xff0c;客户端与 Nacos Server 如果发生短暂的域名解析问题&＃xff0c;会导致心跳永久丢失&＃xff0c;进而引发服务全量下线&＃xff0c;即使网络恢复&＃xff0c;也不会自动恢复心跳。

域名解析失败常见于网络抖动或者 K8s 环境下的 coreDNS 访问超时等场景&＃xff0c;为避免域名解析对 Nacos 造成的重大影响&＃xff0c;请务必自查应用代码中使用的 nacos-client 的版本。

该问题仅存在于 1.4.1 版本&＃xff0c;低于此版本不受此问题的影响&＃xff0c;使用 1.4.1 的用户建议升级至 1.4.2 以避免此问题。

使用 SpringCloud/Dubbo 的用户&＃xff0c;需要确认实际框架使用的 nacos-client 版本&＃xff0c;可以通过显式指定 nacos-client 的版本以覆盖框架默认的版本。其中 Dubbo 用户要格外小心&＃xff0c;Dubbo 的 2.7.11 版本默认使用了 nacos-client 1.4.1&＃xff0c;务必显式指定 nacos-client 的版本到 1.4.2&＃xff0c;Dubbo 也将在下个 release 版本替换 Nacos 的默认版本。

热门内容&＃xff1a;Java这个高级特性-泛型&＃xff0c;很多人还没用过&＃xff01;
面试官问&＃xff1a;MySQL 的自增 ID 用完了&＃xff0c;怎么办&＃xff1f;
王者荣耀中一个英雄是怎么被产生的&＃xff1f;
饿了么CTO&＃xff1a;“不能被烂用的框架不是好框架”&＃xff01;
最近面试BAT&＃xff0c;整理一份面试资料《Java面试BAT通关手册》&＃xff0c;覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。获取方式&＃xff1a;点“在看”&＃xff0c;关注公众号并回复 666 领取&＃xff0c;更多内容陆续奉上。


明天见(&＃xff61;&＃xff65;ω&＃xff65;&＃xff61;)&＃xff89;♡