从注册中心控制台到云原生管控面，Dubbo 服务治理能力全新升级！

作者：陈才、雪涛、刘军

Apache Dubbo Admin 是一个用于更好地可视化、监控、治理 Dubbo 微服务应用程序的管控台。0.7.0 版本是一个以 Kubernetes 原生为核心设计目标的里程碑版本，标志着 Apache Dubbo Admin 从“注册中心管理控制台”，演进为云原生环境中的服务治理控制面（Control Plane） 。

版本摘要：Kubernetes 原生的控制与治理平台

Apache Dubbo Admin 0.7.0 围绕 Kubernetes 原生运行、事件驱动治理、控制面架构进行了系统性重构，以下是 Admin 整体架构图：

image

  • 兼容传统注册中心与 Kubernetes 架构：同时支持传统注册中心、Kubernetes Service 架构，支持应用、实例、服务视角的全局可视化治理；支持多注册中心与跨集群部署方案；

  • 治理能力全新升级：统一的流量治理界面，后端实现传统注册中心、Kubernetes 资源的自动规则转换与分发；

  • 可观测能力深度集成：Admin 不再只是展示应用、实例、服务等“元数据”，而是提供调用链路的实时可观测能力，支持 Metrics、Tracing 等的可视化展示；

  • Kubernetes 原生设计：Admin 与 Kubernetes 集群无缝衔接，后端系统基于 Go 语言重构，与 client-go、informer、cache 深度集成。

此次重构，Admin 基于领域驱动的思想对 Dubbo 领域的实体进行了完整的建模，Dubbo 的领域模型有应用（Application），服务（Service），实例（Instance）以及路由规则（Rule）。这几个用户熟知的领域模型贯穿了 Admin 的产品设计以及前后端架构。基于这些领域模型，Admin 定义出了一套完全遵循 Kubernetes 的“CRD”。这也是一个重要的 K8s 原生体现，同时也为以后更多的 K8s 原生功能拓展打下了坚实的基础。

此外，得益于 client-go 的 informer 机制，新版本中对注册中心/K8s 的监听使用 list-watch 模型进行了统一，所有的资源都以事件的方式进行异步更新，对于控制台的前端查询始终走的是本地的缓存，大大减小了对注册中心/K8s 的查询压力。

核心亮点一：前端 UI 焕新

此次 Admin 控制台 UI 全面焕新，从产品设计上紧紧围绕着 Dubbo 的领域模型来展开，将应用，实例，服务有机地串联在一起，并能够与 K8s 资源进行联动。此外，Dubbo 经典的路由规则（动态配置，条件路由，标签路由）也全部表单化，进一步降低用户的对流量管控的使用门槛。用户可以一站式地管理自己的 Dubbo 应用。

image

image

核心亮点二：Kubernetes 原生

Apache Dubbo Admin 0.7.0 是“为 Kubernetes 设计的”，而不是“跑在 Kubernetes 上的”。 Admin 以组件化的方式原生支持运行在 K8s 上的 Dubbo 实例，无需配置就能够打通微服务生命周期与 K8s pod 的生命周期。让用户能够直观地感受到 Dubbo 应用的底层运行状态，更好地运维 K8s 上的 Dubbo 实例。这一套模型使 Dubbo Admin 能自然融入 Kubernetes 的 Controller / Reconcile / Desired State 体系。

image

Apache Dubbo Admin 0.7 版本的云原生主要体现在以下方面：

  • 对于传统注册中心模式，如果部署在 Kubernetes 平台下，支持与 Kubernetes 状态、资源的无缝集成，让开发者以应用、实例、服务的统一视角运维与监控微服务集群；
  • 支持 Kubernetes Service 微服务模式，Admin 可以统一管理 Kubernetes Service 模式注册的服务，让用户以应用、实例、服务的统一视角运维集群，与传统注册中心模式保持一致。

在内部架构设计上，Admin 将 Kubernetes 中的一些优秀的原生架构拓展到了对于传统注册中心部署架构的支持。我们构建了一套基于 Informer 框架的统一治理模型，将传统注册中心和 Kubernetes CRD 资源全部纳入同一套事件驱动机制中。这个机制能够很好地屏蔽底层差异，无论数据来自运行时引擎 Kubernetes、还是来自于注册中心 Zookeeper 或 Nacos，均通过 Informer 统一接入，这为以后接入更多的数据源如 Docker Compose， VMWare 等打下了坚实的基础。

此外在 informer 框架的基础之上，我们拓展增强了 lister-watcher，store，index 等关键组件，做到了：

  • 事件驱动，实时感知：实现对服务注册、配置变更、实例状态等事件的实时监听，真正做到 “变化即响应”；
  • 低延迟，功能更丰富的本地缓存：基于 client-go cache 构建的 Memory Store，提供低延迟、强一致性读取能力，完美匹配 Kubernetes Watch、List 语义，同时具备极高的吞吐性能，能够支持多样的索引能力。

核心亮点三：云原生 Discovery 与多注册中心

在 Kubernetes 世界里，“注册中心”只是数据源之一。 此次版本更新还引入了一个重要的特性——多注册中心支持。与此前版本的 Admin 的支持方式不同，新版本中将注册中心作为一个“隔离域”，所有的资源（应用/服务/实例/规则等）都会规约到一个注册中心下面，切换注册中心就相当于切换一个“隔离域”，这也契合大多数企业在生产实践中的使用方式。添加新的注册中心只需要在配置文件中新增注册中心地址即可。

image

Apache Dubbo Admin 0.7.0 将 Discovery 能力纳入统一控制面架构：

  • Nacos Discovery 原生实现
  • Zookeeper Discovery 原生实现
  • 控制台支持多注册中心：统一视图、支持混合部署、多环境、多集群。这使得 Admin 能够：
    • 同时治理 Kubernetes Service + 外部注册中心
    • 作为多环境统一治理入口

核心亮点四：可观测×治理，真正的闭环控制面

从“看得见服务”到“看得清调用”，Dubbo Admin 0.7.0 正式补齐可观测控制面。 Dubbo SDK 在 3.2+ 版本中进行了 metric 和 trace 的埋点，支持上报 metric 和 trace 到 metric/trace 后端，而此次控制台以 Grafana 为可视化基础，不仅支持 Prometheus，jaeger，zipking 等多种数据源，并直接在控制台中集成了 Dubbo 调用的监控面板和链路追踪面板，让排查问题不再为难。

image

image

Dubbo SDK 原生埋点

自 Dubbo Client 3.2+  起，Dubbo 已在指标与链路层面完成系统性埋点：

  • Metrics：请求 QPS / RT / 错误率、服务级 / 方法级调用指标、支持 Prometheus 标准采集；
  • Tracing：完整 Dubbo 调用链路、支持 OTLP / Jaeger / Zipkin 等主流链路后端。

以 Grafana 为基础的可观测控制台

Dubbo Admin 0.7.0 首次将可观测能力作为控制面的一部分进行整合：

  • 以 Grafana 作为统一可视化基础；
  • 内置 Dubbo 调用监控面板：服务 / 方法维度调用趋势；延迟、错误率、吞吐一目了然；
  • 内置链路追踪面板：直接查看 Dubbo 调用链路、快速定位慢调用与异常节点。

image

立即体验

详细的 Changelog，更多特性介绍以及完整的部署方式请看：

如果您有任何的需求、问题等，欢迎在 Github issue/discussion 中一起讨论！

2026 Roadmap

未来 Apache Dubbo Admin 将围绕几个方面持续投入：

  1. 持续深耕服务治理，完善接口测试，服务拓扑等能力。持续优化数据链路，保障 Admin 作为控制面的核心能力稳定。
  2. 围绕 metric，trace 以及 log，进一步增强可观测能力。此外，结合 K8s 的 event，Admin 还会刻画出每个领域实体的事件瀑布流，更好地观测应用的生命周期，便于工程师排查问题。
  3. Admin 将作为 mcp server，在支持原生 Dubbo mcp 的基础上，通过代理的方式支持用户低成本将现有的 Dubbo 接口变成可调用的 mcp 工具，助力 AI 业务创新。
  4. 通过 RAG，Agent 等技术，推出 AI assistant，充当 Dubbo 领域的知识专家，并协助用户排查 Dubbo 领域的问题。
posted @ 2026-03-20 13:35  阿里云云原生  阅读(3)  评论(0)    收藏  举报