Dubbo Admin 控制面总体架构设计

本文描述了 Dubbo Admin 作为控制面的总体架构设计与抽象。

1 Dubbo 整体架构

架构上分为：服务治理抽象控制面 和 Dubbo 数据面 。

• 服务治理控制面。控制面包含注册中心、流量管控策略、Admin 控制台、Istio、OpenSergo 等组件。
• Dubbo 数据面。数据面代表集群部署的所有 Dubbo 进程，进程之间通过 RPC 协议实现数据交换，并与控制面进行治理策略交互。

**进一步解释：**https://cn.dubbo.apache.org/zh-cn/overview/what/overview/

Dubbo Admin 的整体定位与解释

Dubbo Admin 是对微服务治理体系的统一定义与抽象，通过自定义核心组件与一系列配套工具，为不同部署架构和基础设施环境下部署的微服务集群带来统一的开发与运维差异。

2 面向用户的开发步骤

第一步：安装 Dubbo Stack/Admin

核心思路是，屏蔽架构差异，通过统一入口将治理组件的安装和配置纳入成为 Dubbo 体系中的前置步骤

dubboctl install dubbo-stack

安装请参见: Dubbo Admin 安装指南

第二步：服务框架开发

• Java
• Go
• Node.js
• Rust

3 控制面方案

3.1 确定 Dubbo 微服务治理体系的核心能力

• 服务发现
• 配置管理
• 流量治理规则
• 安全基础设施
• 可视化控制台

3.2 统一服务治理层接入方式

**对于任何微服务部署模式，Dubbo 数据面统一面向 ****dubbo://hopst:ip**抽象服务治理控制面编程。

具体工作流程：

1. 数据面通过配置先与 admin 组件进行交互，admin 返回当前部署架构下的实际注册中心、配置中心等组件地址，如图中的 nacos://host:port。
2. 数据面组件接收到新的组件地址后，直接与 Nacos 建立通信，此后依赖 Nacos 完成服务发现等功能。

3.3 在不同场景下如何兑现这些核心能力？

场景一：传统微服务体系 (VM & Kubernetes)

• 控制面治理体系一键安装 (Admin & Nacos)
• 传统 Nacos 服务发现与治理模式
• 控制面可按需拉起更多的的组件，如 prometheus 等

场景二：Kubernetes Service

1. Istio 模式

1. 其他对等模式 Nacos/OpenSergo

场景三：Migration or Multi-cluster

集群处于隔离的子网络空间

• 1
• 2

集群处于同一网络空间

3.4 Admin 控制面

3.5 其他配套基础设施与工具

用户控制台 Console

交互地址：https://qedzyx.axshare.com/#id=2pqh0k&p=admin__&g=1

Dubboctl & Helm

最后修改 May 9, 2023: Initializer announcement (#2582) (21b062fcdbb)