共计 2611 个字符，预计需要花费 7 分钟才能阅读完成。
作者：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 官网！
