怎么解决Dubbo服务启动两个小时问题

这篇文章主要讲解了“怎么解决Dubbo服务启动两个小时问题”，文中的讲解内容简单清晰，易于学习与理解，下面请大家跟着小编的思路慢慢深入，一起来研究和学习“怎么解决Dubbo服务启动两个小时问题”吧！

目前创新互联建站已为超过千家的企业提供了网站建设、域名、网站空间、绵阳服务器托管、企业网站设计、塔城网站维护等服务，公司将坚持客户导向、应用为本的策略，正道将秉承"和谐、参与、激情"的文化，与客户和合作伙伴齐心协力一起成长，共同发展。

现象

现象是这样的，有一天测试在测试环境重新部署一个 dubbo 应用的时候发现应用“启动不起来”。

但过几个小时候之后又能自己慢慢恢复，并能够对外提供 dubbo 服务。

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

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

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

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

尝试解决

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

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

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

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

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

好吧，忽悠不过去了。

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

我将应用重启后用 jstack pid 将线程快照打印到终端，直接拉到最后看看 main 线程到底在干啥。

前几次的快照都是很正常：

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

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

翻源码

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

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

于是我找到此处的源码：

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

再往下跟就如堆栈中一样是卡在了 Inet4AddressImpl.getLocalHostName 处。

但这是一个 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服务启动两个小时问题”的内容了，经过本文的学习后，相信大家对怎么解决Dubbo服务启动两个小时问题这一问题有了更深刻的体会，具体使用情况还需要大家实践验证。这里是创新互联，小编将为大家推送更多相关知识点的文章，欢迎关注！