What？一个 Dubbo 服务启动要两个小时！

前言

前几天在测试环境碰到一个很是奇怪的与 dubbo 相关的问题，过后我在网上搜索了一圈并无发现相似的帖子或文章，因而便有了这篇。

但愿对还未碰到或正在碰到的朋友有所帮助。

现象

现象是这样的，有一天测试在测试环境从新部署一个 dubbo 应用的时候发现应用“启动不起来”。
但过几个小时候以后又能本身慢慢恢复，并可以对外提供 dubbo 服务。

但其实通过我后续排查发现刚开始其实并非启动不起来，而是启动速度很是缓慢，因此当应用长时间启动后才会对外提供服务。

而这个速度慢到竟然要花费 2 个小时。

致使的一个结果是测试彻底不敢在测试环境发版验证了，每验证一个功能修复一个 bug 就得等上两个小时，这谁受得了😂。

并且通过屡次观察，确实每次都是花费两小时左右应用才能启动起来。

尝试解决

最后测试顶不住了，只能让我这个“事故报告撰写专家”来看看。

当我得知这个问题的现象时其实彻底没当一回事：

都不用想，这不就是主线程阻塞了嘛，先看看是否在初始化的时候数据库、Zookeeper 之类的连不上致使阻塞了-------来之屡次事故处理的经验告诉我。

因而我把这事打回给测试让他先找运维排查下，不到万不得已不要影响我 Touch fish🐳。

次日一早看到测试同窗的微信头像跳动时我都已经准备接受又一句 “膜拜大佬👍” 的回复时，却收到 “网络一切正常，没人动过，再不解决就要罢工了🤬”。

好吧，忽悠不过去了。

首先这类问题的排查方向应该不会错，就是主线程阻塞了，至因而啥致使的阻塞就不能像以前那样瞎猜了。

我将应用重启后用 jstack pid 将线程快照打印到终端，直接拉到最后看看 main 线程到底在干啥。
前几回的快照都是很正常：

加载 Spring ---->链接 Zookeeper ---> 链接 Redis，都是依次执行下来没有阻塞。

隔了一段后应用确实还没起来，我再次 jstack 后获得以下信息：

翻源码

我一直等了十几分钟再屡次 jstack 获得的快照获得的信息都是同样的。

如图所示可见主线程是卡在了 dubbo 的某个方法 ServiceConfig.java 的 303 行中。

因而我找到此处的源码：

简单来讲这里的逻辑就是要获取本机的 IP 将其注册到 Zookeeper 中用于其余服务调用。

但这是一个 native 方法，咱们应用也根本干涉不了，最终的现象就是调用这个本地方法很是耗时。

因而这问题貌似也阻塞在这儿了，没有太多办法。

最终解决

既然这是一个 native 方法，那说明和应用自己没有啥关系（确实也是这样，这个问题是忽然间出现的。）

那是不是服务器自己的问题呢，想到在 native 方法里是获取本机的 hostname，那是否和这个 hostname 有关系呢。

这是在我本身的阿里云服务器上测试，真正的测试环境不是这个名字。

拿到服务器 hostname 后再尝试 ping 这个 hostname，奇怪的现象发生了：

命令刚开始会卡住一段时间（大概几十秒），而后才会输出 hostname 对应的 ip 以及对应的延迟。

而当我直接 ping 这个 ip 时却能快速响应后面的输出。

最后我尝试在 /etc/hosts 配置文件中加入了对应的 host 配置：

xx.xx.xx.xx(ip) hostname

再次 ping hostname 的效果就和直接 ping ip 同样了。

因而我再次重启应用，一切都正常了。

总结

最后根据我调整的内容尝试分析下本次问题的缘由：

• 当 Dubbo 在启动获取本地 ip 时，是经过服务器 hostname 从 dns 服务器返回当前的 ip 地址。
• 因为 dns 服务器或者是本地服务器与 dns 服务器之间存在网络问题，致使这个过程的时间被拉长（猜想）。
• 我在本地的 host 文件中配置后，就至关于本地有一个缓存，优先取本地配置的 ip ，避免了和 dns 服务器交互的过程，因此速度提高了。

虽然问题获得解决了，但仍是有几个疑问：

第一个是为何和 DNS 服务器的交互会这么慢，即使是慢也没有像应用那样须要 2 个小时才能返回，这里我也没搞得太清楚，有相关经验的朋友能够留言讨论。

第二就是 Dubbo 在这个依赖外部获取资源时健壮性是否能够作的更好，虽然说我这问题估计也几人碰到。

对于这种长时间没有启动成功的问题是否能够加上提示，好比直接抛出异常退出程序，将问题可能的缘由告诉开发者，方便排查问题。