Dubbo Mesh - 从服务框架到统一服务控制平台

作者：Dubbo 社区

Apache Dubbo 是一款 RPC 服务开发框架，用于解决微服务架构下的服务治理与通信问题，官方提供了 Java、Golang 等多语言 SDK 实现。使用 Dubbo 开发的微服务原生具备相互之间的远程地址发现与通信能力， 利用 Dubbo 提供的丰富服务治理特性，可以实现诸如服务发现、负载均衡、流量调度等服务治理诉求。Dubbo 被设计为高度可扩展，用户可以方便地实现流量拦截、选址的各种定制逻辑。

什么是 Dubbo 3

Dubbo 3 保持了 Dubbo 2 的经典架构，以解决微服务进程间通信为主要职责，通过丰富的服务治理（如地址发现、流量管理等）能力来更好地管控微服务集群；Dubbo3 对原有框架的升级是全面的，体现在核心 Dubbo 特性的几乎每个环节，通过升级实现了稳定性、性能、伸缩性、易用性的全面提升。

通用的通信协议： 全新的 RPC 协议应摒弃私有协议栈，以更通用的 HTTP/2 协议为传输层载体，借助 HTTP 协议的标准化特性，解决流量通用性、穿透性等问题，让协议能更好地应对前后端对接、网关代理等场景；支持 Stream 通信模式，满足不同业务通信模型诉求的同时给集群带来更大的吞吐量。

面向百万集群实例，集群高度可伸缩：随着微服务实践的推广，微服务集群实例的规模也在不停地扩展，这得益于微服务轻量化、易于水平扩容的特性，同时也给整个集群容量带来了负担，尤其是一些中心化的服务治理组件；Dubbo 3 需要解决实例规模扩展带来的种种资源瓶颈问题，实现真正的无限水平扩容。

拥抱云原生：在云原生时代，底层基础设施的变革正深刻影响应用的部署、运维甚至开发过程，往上也影响了 Dubbo 3 微服务技术方案的选型与部署模式。Dubbo 3 在服务发现模型上全面对齐云原生基础设施的模型，在地址、生命周期等设计可与 Kubernetes 等容器调度平台对齐。

未来的 Dubbo 需要解决什么问题

在 Dubbo 3 功能基本完备的当下，我们开始重新对当前 Dubbo 的整体架构进行思考，总结出有以下几个问题：

业务代码与各微服务组件直接耦合，升级难度高

在目前的部署形态下，如果需要集成一个组件需要在业务代码的环境中对该组件进行适配。举一个简单的例子，如果需要接入一个自定义数据格式转换组件需要基于 Dubbo 的 SPI 在业务的代码中织入对应的适配实现。这种部署方式对业务的部署造成较高的侵入。如果这个转换组件需要升级，需要推动所有部署了该组件的业务方都升级一遍。在生产环境中难度极高。

多语言实现复杂度高

由于目前 Dubbo 所有的计算处理逻辑都以 SDK 的形式集成进业务代码中，在需要跨语言进行调用的时候不可避免地导致了实现复杂度高的问题。对于 Dubbo 来说，除了 Java 和 Golang 的 SDK 实现较为完善，其他语言仍欠缺对应完善的实现。此外，对于一个拦截器功能，在 Java SDK 下的实现由于语言和接口设计的差异不可能直接复用到 Golang 的 SDK 上，一定程度上也给中间件开发带来难度和不稳定因素。

治理能力下沉在数据面，中间件治理能力割裂

当前 Dubbo 的部署形态下在需要接入一个中间件治理能力的时候，需要通过数据面业务代码直接接入的方式集成的，这种方式会导致各治理组件独立工作，从全局视角来看数据面的接入十分混乱，无法通过一个统一的视角进行统一治理。同时由于这些组件是独立接入的，组件之间的工作在某些场景下并不能很好地结合起来。

Dubbo Mesh

Dubbo Mesh 从架构与部署形态上明确地区分为控制面与数据面。

其中控制面作为服务治理核心，具有抽象的、统一的模型，负责与底层基础设施的对接，提供从启动配置、服务发现、流量管理到认证鉴权等的统一治理入口。

数据面则专注在业务编程模型与通信能力上，基于多种部署形态（SDK、Sidecar、Agent）接入服务治理能力，基于动态部署能力从业务代码中解耦出来。

总体来说，数据面更轻量、专注，控制面更内聚、强大，只需要部署一套控制面即可使用生产级的服务治理能力。

以下分别从控制面和数据面两个部分分别说明在 Dubbo Mesh 下各自的职责与能力：

Dubbo 控制面

控制面是服务治理核心，具有抽象的、统一的模型，负责与底层基础设施的对接，提供从启动配置、服务发现、流量管理到认证鉴权等的统一治理入口。

1. 抽象的服务治理模型：Dubbo 控制面继承了 Dubbo 扩展性高的特点，划分了各种领域与扩展点供各组件使用。支持自定义增加组件，只需要组件按照标准的格式进行扩展就可以在 Dubbo Mesh 下进行快速部署、拉起、热更新等行为。

2. 屏蔽基础设施与组件：Dubbo 控制面将基础设施如 Kubernetes 的接入通过组件的模式集成在内部，面向数据面屏蔽来自各基础设施的差异，支持原生 Kubernetes 部署、VM 部署、混合部署等场景。

3. 统一的服务治理规则：Dubbo 控制面支持对接统一的服务治理规则，支持通过一套规则治理多种框架。

4. 跨语言支持：Dubbo 控制面通过通用的数据格式下发控制数据，配合数据面的多种部署方式解决跨语言的治理难题。

Dubbo 数据面

Dubbo 数据面将专注在业务编程模型与通信能力上，提供多种接入方式，对接来自 Dubbo 控制面的组件管控，支持通过组件热更新的方式动态拉取控制面下发的治理规则识别与执行能力。

1. 专注编程与通信：Dubbo 数据面将更专注于向业务开发者提供编程模型的支持。用户只需要依赖简单的调用 API 即可完成对应的 RPC 远程调用，而不再需要关心背后的治理能力的接入。

2. 多种接入方式：Dubbo 数据面在未来将支持基于 SDK 的 proxyless 模式接入、基于 Agent 的无感知接入以及基于 Sidecar 的跨语言接入方式，尽可能覆盖更过的使用场景，提高整体功能的易用性。

3. 组件热更新：Dubbo 数据面将支持动态加载、更新来自 Dubbo 控制面下发对应的治理组件能力，将治理能力的管理收口在 Dubbo 控制面进行统一管理，完善运维流程。

4. 治理规则识别与执行：Dubbo 数据面主要负责对应的治理规则的识别与执行，通过动态加载能力的方式加载对应的治理能力，实现对数据面流量的治理能力。

Roadmap

在今年年底，Dubbo Mesh 将发布具备有服务发现能力的版本，届时将面向所有 Dubbo 用户提供从低版本平滑迁移到 Mesh 架构的能力；在明年初春季的时候发布带有治理能力的版本；在明年年底前发布带插件热更新能力的版本。

点击此处，直达 Dubbo 官网！