MSE 自治服务帮你快速定位解决 Dubbo 重复订阅导致 RPC 服务注册失败问题

Posted 2023-05-23 阿里系统软件技术

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

作者：子葵

背景

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 进行深度优化，具有多可用区容灾能力，免运维，高可用等能力，助力用户构建稳定高效的微服务应用。

点击此处了解微服务引擎 MSE 产品详情

MSE+ASM实现双擎微服务治理

当下流行的微服务运动让软件服务越做越小的同时，服务与服务之间的相互发现、依赖和调用成为了一个亟待 治理 的领域，在Java和多语言的世界中分别诞生出了很多的解决方案，在Java的世界里基于Spring Cloud和Dubbo框架的方案占据主流地位，而在多语言的世界中基于K8s的Istio是毫无疑问的明星，MSE和ASM是阿里云在Java和多语言领域的微服务治理解决方案。

微服务引擎（Microservice Engin）是一个面向业务主流开源微服务框架Spring Cloud和Dubbo的一站式微服务平台。MSE主要包括四部分功能：

• 服务治理、提供服务目录、服务测试、服务限流降级、无损下线、流量控制等能力，支持五年内的Spring Cloud和Dubbo版本的“零”改造接入。
• 服务注册、可在Zookeeper/Nacos/Eureka三种引擎中任选，相对于自建服务注册中心具有更高的可用性保障。
• 服务配置、提供全托管的Nacos服务，支持配置查询和版本管理，相对于自建具有更高的可用性保障。
• 服务网关、提供全托管的Zuul、Kong、Spring Cloud Gateway服务网关服务，可按需选择开通。

服务网格ASM（Alibaba Cloud Service Mesh）是一个全托管的服务网格平台，与社区Istio兼容，支持对混合云环境下的K8S集群进行应用服务流量统一管理，包括阿里云ACK（阿里云托管或专有Kubernetes集群）、ASK（阿里云Serverless Kubernetes集群）、ECS或IDC上的自建Kubernetes集群、第三方云上的Kubernetes集群等，和社区版Istio一样，ASM支持包括流量管理、安全审计、监控诊断等功能。

ASM将Istio的控制平面组件全部托管，从而降低使用和维护的复杂度，通过一个托管的ASM实例可以管理来自多个kubernetes集群的应用服务、还可以借助于ASM VM Proxy接管非kubernetes集群下应用。

Istio使用Kubernetes来存储配置数据，因此导致对Kubernetes环境的强依赖，为了让Istio的应用场景扩展到更广阔的领域，Istio社区提出了MCP（Mesh Configuration Protocal），定义了向Istio控制平台下发配置数据的标准协议。

基于MCP，MSE与ASM进行了打通，可以使用MSE对ASM下的非Java应用编写的服务进行服务治理，且无需修改现有应用代码，只要通过在目标集群安装MSE服务治理组件并提供AMS的实例ID，该集群下的应用即可接入MSE治理中心进行治理，目前支持对ASM下的服务进行查询和为其配置标签路由。

标签路由通过标签将一个或多个服务的提供者划分到同一个分组，从而约束流量只在指定分组中流转，实现流量隔离的目的。标签路由可以作为蓝绿发布、灰度发布等场景的能力基础。