作者：子葵

背景

Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，具有易用、超大规模微服务实践、云原生基础设施适配、安全性等特点。但是不正确的 Dubbo 使用姿势可能会导致 Dubbo 应用以及 ZooKeeper 注册中心出现稳定性问题。近期，一线上客户发布时，由于 Dubbo Reference 重复初始化，导致 ZooKeeper 出现不可用，服务注册订阅失败，造成业务大面积故障。

ZooKeeper 出现异常日志↓

并且 ZooKeeper 集群持续不可用，无法自愈。

原因分析

Dubbo Reference 是 Dubbo 框架中服务提供者在调用者中的代理实现，在初始化 Dubbo Reference 的时候会将 consumer 本身注册在订阅的服务的 consumer 列表中，如果在一个应用中实例化了多个同一个接口的 Dubbo Reference，那么 ZooKeeper 中对应的被订阅的服务 consumer 列表中也会存在多个由于此应用订阅产生的 Znode 节点，这些 Znode 节点的 Path 除了 timestamp 字段都是一致的。

Dubbo 本身通过这种方式表示真实的订阅关系，但是在客户端不正确的使用的情况下，就可能导致 Dubbo 应用本身以及 ZooKeeper 的稳定性问题。

https://github.com/apache/dubbo/issues/4587

例如在 Dubbo 2.7.9 之前的版本中在应用中初始化多个相同接口的 Dubbo Reference， 可能会导致内存溢出的问题。

对于 ZooKeeper 集群，在之前 jute.maxbuffer 调优文章中分析过在 ZooKeeper Server 之间数据同步的时候会严格根据 jute.maxbuffer 的限制进行 Server 之间用于同步的数据包大小的校验，如果数据包超过限制会导致 Follower 和 Leader 之间断连。对于由于错误使用，应用不断初始化同一个接口的 Dubbo Reference，在应用崩溃之后，应用创建的大量的临时节点会导致 ZooKeeper 集群持续崩溃。

问题排查以及解决方案

针对注册配置中心

如果使用的是 ZooKeeper 作为注册配置中心， 可以根据 jute.maxbuffer 一文中的建议，增加 jute.maxbuffer 参数的值，从而延缓问题，但是无法根本解决问题。MSE ZooKeeper 针对此类问题特别设计了限流机制，保证在客户端误用，或者非预期异常的情况下，限制客户端重复注册同一个 consumer，从而保证 ZooKeeper 集群的稳定，并且根据 MSE ZooKeeper 的观测系统可轻松排查具体的应用注册信息。

使用 MSE ZooKeeper 排查步骤：

例如，有一应用 test 由于初始化方式不合理，导致应用重复初始化对于接口 com.demo.provider 的 Dubbo Reference，在应用启动一段时间后，注册就会报错，此时 MSE ZooKeeper 已经限制了此客户端进行注册行为，从而保障 ZooKeeper Server 自身的稳定性，此时我们可以在 MSE 控制台中根据监控以及推送轨迹信息，排查问题应用。

首先进入 MSE 控制台对应的实例详情页，打开观测分析-> 监控中心 -> TopN 监控。

通过 TopN 监控中的客户端 TPS TopN 找到时间段内频繁写入的 SessionId，通过此 SessionId，在数据管理 -> 数据轨迹中查询对应 SessionId 的数据操作记录。

通过查询结果可以看出具体的某一个机器进行了多次 consumer 注册。

针对 Dubbo 应用本身

升级 Dubbo 版本到最新的稳定版本，同时在使用过程中需要注意 Dubbo Reference 的初始化方式，减少非必要的同一个接口的多个 Dubbo Reference，Dubbo Reference 本身比较重，多个 Dubbo Reference 本身会消耗机器资源。

总结

在平时业务开发中，由于框架的误用或者 bug 导致的业务以及业务依赖的中间件的稳定性问题需要有快捷的手段进行排查，找到原因及时止血，MSE ZooKeeper 针对多种使用场景，提供多种数据统计聚合能力，帮助用户提高问题排查的效率，并且针对 ZooKeeper 多种使用场景，提供丰富的监控指标，基于 Dragonwell jdk 进行深度优化，具有多可用区容灾能力，免运维，高可用等能力，助力用户构建稳定高效的微服务应用。