背景
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 进行深度优化，具备多可用区容灾能力，免运维，高可用等能力，助力用户构建稳固高效的微服务利用。
作者：子葵
原文链接
本文为阿里云原创内容，未经容许不得转载。