Dubbo + ZooKeeper｜如何解决线上故障排查链路长的难题

云布道师

ZooKeeper 作为通用的元数据存储组件，用途广泛，是 Dubbo 最早支持的注册中心之一，经过长时间的磨合，目前 Dubbo 和 ZooKeeper 的组合具有很好的稳定性和扩展性。

ZooKeeper 作为 Dubbo 注册中心时，由于开源 ZooKeeper 没有提供服务注册的逻辑模型，因此对 Dubbo 服务的管理成本比较高，存在问题排查链路长等一系列治理问题。针对这些问题，MSE ZooKeeper 最新提供 Dubbo 服务管理能力，同时结合 TopN 监控大盘，推送轨迹等自治能力，帮助用户提高问题排查速度，集群运维效率。

服务管理

通过实例详情页中的数据管理中的服务管理来查看 ZooKeeper 中注册的服务，以及服务的提供者，订阅者信息。服务详情页展示对应的服务名以及服务类型，目前只支持 Dubbo，未来还会支持更多的服务注册类型，单击服务名进入服务详情页面。

服务详情页面展示了服务的元信息，包含服务的版本、分组、应用名等信息，支持多个分组、版本展示。服务提供者信息通过更加合理的表格结构化展示，并且可以实时看到实例的上下线、权重、超时时间等信息，能够更加清晰地掌握应用的配置信息。

如果您想对 Dubbo 服务进行精细化的治理，可以将您的 Dubbo 服务接入 MSE 微服务治理。在接入服务治理的情况下，您可以通过点击接口详情按钮来跳转到微服务治理对应的页面，查看您的 Dubbo 服务的详细数据信息，包含服务的 QPS、延时、成功率、并发等信息。

如果您的 Dubbo 应用遇到了一些线上问题，需要在保留现场的场景下进行问题定位。您可以在跳转后的微服务治理对应的界面中找到节点详情菜单。选择出现问题的实例，通过右侧的服务下线按钮进行下线操作。这样就可以将出问题实例的流量摘除掉，在既保留现场又不影响业务的情况下进行问题定位。

结合 MSE 服务治理能力，能够轻松实现服务的无损伤上下线，灰度发布，使得发布过程中更加平滑，风险降低。同时结合推送轨迹功能方便查询服务提供者的上下线记录，能够协助排查注册不上，重复注册，服务下线但是注册中心中数据未删除，频繁变更等场景。

同时通过查询订阅者的推送轨迹我们直观看到每次服务上下线被推送的客户端情况。

同时 MSE ZooKeeper 增强了稳定性，对于异常的注册场景，Server 提供防护能力，防止因为业务侧异常导致服务宕机。

例如，某用户由于代码缺陷导致 Dubbo Service Refrence 泄漏，ZooKeeper 中存在大量泄露的 Reference 创建的临时节点，并且由于 ZooKeeper 同步机制中的限制（可参考ZooKeeper 避坑指南，jute.maxbuffer 的设置文章），导致服务宕机，MSE ZooKeeper 针对这种极端情况做了 Server 侧的自我保护，在 Reference 泄漏的情况下会限制业务注册的无用的数据，保证 Server 的稳定性。

问题排查

对于极端情况下问题的排查，MSE ZooKeeper 提供丰富的 TopN 大盘，结合上述的推送轨迹能力，能够帮助用户快速找到问题源头。例如在 Dubbo Service Refrence 这种场景下，我们首先可以根据 TopN 大盘中的 Session Tps TopN 确定泄漏的 refrence 是由哪一个客户端产生的。

之后我们通过此客户端的 SessionId，在推送轨迹中查询对应的变更记录，并通过变更记录找到问题的原因。

从推送轨迹中我们可以看到异常 session 创建的所有的 path，从 path 中包含的信息可以快速溯源到源客户端，从而找到问题原因。

欢迎感兴趣的同学扫描下方二维码加入钉钉交流群，一起参与探讨交流。

你可能还想看关注我们欢迎关注加星标✨ 精彩推送不错过