简介： 做过微办事开辟的开辟者信赖对 Dubbo 都不陌生，Dubbo 是一款能赞助我们快速解决微办事开辟、通信以及流量治理的框架。比拟于之前只限制在 Java 说话范围内，Dubbo 的多说话版本在这两年出现了优胜的成长势头，个中，Dubbo Go 说话版本在功能、稳定性各个方面都已异常完全，其它几种主流的多说话版本在社区也有供给。

作者 | 陆龟

来源 | 阿里巴巴云原生"大众,"号

本文整顿自作者在3月20日云原生中心件 Meetup 上海站的分享。答复关键字“中心件”可以获取视频录播地址和 PPT。

就在今天，Dubbo 社区方才宣布了 3.0 的首个预览版本 - 3.0.0.preview。

https://github.com/apache/dubbo/releases/tag/3.0.0.preview

本文将和读者一路解读 Dubbo3 的首个 preview 版本：一方面，我们将深刻分析 Dubbo3 云原生变革的核心理念；另一方面，我们将逐个解读 preview 版本的核心功能。

做过微办事开辟的开辟者信赖对 Dubbo 都不陌生，Dubbo 是一款能赞助我们快速解决微办事开辟、通信以及流量治理的框架。比拟于之前只限制在 Java 说话范围内，Dubbo 的多说话版本在这两年出现了优胜的成长势头，个中，Dubbo Go 说话版本在功能、稳定性各个方面都已异常完全，其它几种主流的多说话版本在社区也有供给。

云原生视角的微办事项革

Dubbo 重要解决微办事开辟、运行域问题，它和微办事的编程、通信、流量治理等密切接洽关系，是以，在探寻 Dubbo3 的云原生变革之前，我们先测验测验从云原生视角不雅察云原生基本举措措施带给微办事架构和实践的变革，进而总结出 Dubbo 如许一个和微办事实践密切相干的框架所面对的变革与挑衅。

微办事在让营业开辟演进更灵活、快捷的同时，也带来了一些它独有的特点和需求：如微办事之后组件数量越来越多，若何解决各个组件的稳定性，若何快速的程度扩容等。

这些诉求，尤其是运维、交付相干诉求，如微办事组件的生命周期、收集、通用办事绑定、办事状况治理等，并不该该是开辟人员存眷的重点，因为它们已经完全离开了营业逻辑，开辟人员更愿意专注在有营业价值组件上，但这个层次的诉求倒是实现微办事交付的关键才能。开辟者期望由底层基本举措措施来供给此类才能支撑，而处于不合阶段成长的基本举措措施却不必定具备如许的才能，是以，在微办事软件架构和底层基本举措措施之间就出现了一条鸿沟，我们须要有组件能弥补这一鸿沟，让微办事组件能更好的接入底层基本举措措施。

这里从一个更抽象的层面，测验测验用两条成长曲线演示了软件架构诉求与底层基本举措措施才能丰富度之间的关系。总体上，两者之间的成长关系可拆分为两个阶段。

在第一个阶段，软件架构（这条红色的线）从单体应用、到面向办事的软件架构、再到微办事架构，快速演进，从而也提出了上文我们讲到的对基本举措措施对交付的诉求，这个时刻基本举措措施层还多是以定制化的方法来知足软件架构的诉求，如过往的集中化的 ESB、各个不合的 PaaS 平台等。

第二个阶段，是安闲器、Kubernetes 为代表的基本产品的出现开端，蓝线与红线之间的增长速度被快速拉近，以云原生技巧为代表的底层基本举措措施丰富度获得了极大年夜改良，它们不再只是被动的知足微办事开辟的诉求，而是开端抽象更多的软件诉求到底层的基本举措措施，将它们下沉为基本才能，并开端以同一的、标准化的情势向上输出以知足微办事对交付、运维等的诉求，不仅如斯，经由过程更深刻的主动立异、持续的向上释放才能，底层基本举措措施还开端反过来影响微办事的开辟、接入方法，如 sidecar、dapr 等模型。

Dubbo3 的云原生变革

经由过程上文云对原生基本举措措施演进给传统微办事带来变革的分析，我们得出，以 Dubbo 为代表的微办事开辟框架，应重点在以下偏向冲破与变革。

• 更多的微办事组件及才能正下沉到以 Kubernetes 为代表的基本举措措施层。传统微办事开辟框架应剔除一些冗余机制，积极的适配到基本举措措施层以做到才能复用；微办事框架生命周期、办事治理等才能应更好地与 Kubernetes 办事编排机制融合。
• 以 Service Mesh 为代表微办事架构给微办事开辟带来的新的选择，但因为 Mesh 架构本身的复杂性，其距离大年夜范围临盆落地还有一段距离。我们信赖，基于 ServiceMesh 的体系会慢慢从孵化器走向成熟期，会有越来越多的企业采取 Service Mesh技巧，但在将来在很长一段时光内，基于办事框架的传统微办事体系还将是主流，经久仍将占据荆棘铜驼。

我们不妨回想一下，在云原生基本举措措施才能被充分释放前，环绕 Dubbo 构建微办事时，它给微办事开辟供给了哪些才能？或者我们期望它供给哪些才能？

Dubbo2 供给了包含办事注册、办事发明、负载均衡、流量治理等相当丰富的才能，当然还包含微办事最须要的长途通信才能，这些才能很好地解决了微办事的诉求。

而在云原生架构之下，我们须要从新核阅，Dubbo2 的哪些才能是冗余的，是须要接入基本举措措施的？哪些才能是已经不合适云原生时代的，须要被重构的？

起首，是接入云原生基本举措措施后，一些才能出现了反复，像办事定义、办事注册、甚至是办事治理才能在不合层面基本举措措施中出现了反复，须要 Dubbo3 作出适配与调剂，以更好的解放营业开辟效力，应用好这些基本才能。

其次，是 Dubbo 在微办事架构中的最根本的才能：RPC 长途通信。通信协定和数据传输格局的标准化应当算是 Dubbo2 面对的又一重要挑衅，在云原生背影下，协定、数据定义、传输格局的标准化和穿透才能成为更须要优先推敲的指标，即使私有协定具有更高效、灵活的潜力，但推敲到云原生下多说话、组件间互通、网关等代理设备友爱性、避免厂商锁定等诉求，在 Dubbo3 中私有协定都应当被摒弃，转而拥抱基于 HTTP/2 的更通用的协定，采取跨说话的更通用的数据定义和传输格局。

最后，是关于办事治理才能，Dubbo 的办事治理才能应当充分结合底层基本举措措施的特点，比如之前绑定 ip 的流量过滤筹划在地址不固定的 Kubernetes 平台就已不再实用，别的，流量治理也要充分的与调剂平台的灰度宣布、动态扩缩容才能整合起来；推敲到将来微办事可能会有多种不合的安排形态（下文会讲到），Dubbo3 应当制订一种能实用于各类安排形态的路由规矩。

从云原生视角来说，Dubbo3 的核心才能根本上也就成环绕以上几点分析展开的，重要涉及：抽象全新的办事发明模型、定义下一代的更能用的 RPC 协定与数据传输格局、办事治理才能重构等。接下来，我们就看看 3.0 preview 中这些才能的具体实现。

Preview 版本功能速览

就在今天，Dubbo 3.0.0.preview 版本正式经由过程了 Apache 社区投票并完成了正式宣布，作为 3.0 的首个宣布版本，代表了社区 3.0 版本的周全启动，也展示了将来 3.0 的成长偏向。当然，我们要意识到 preview 版本还远未达到临盆可用，它只是为了让大年夜家快速、便利懂得 Dubbo3 的一个预览版本，离正式版本甚至 alpha 版本还有一段时光要走，具体大年夜家可存眷文后的 Dubbo Roadmap。

以下 preview 版本宣布的几个核心特点：

• 全新的办事发明模型
• 下一代基于 HTTP/2 的 RPC 协定：Triple
• 办事治理重构：全新路由规矩
• 机能晋升
• 百万节点级程度扩容
• 调用链路 QPS 机能晋升

在 preview 以上才能中，特别值得留意的是得益于 Dubbo3 与 HSF 的融合，Dubbo3 的整体机能也有望获得大年夜幅晋升。

Preview 版本是从架构层面对 Dubbo 的一次周全进级，接下来，社区一方面会从功能完美度、稳定性等几个方面持续加强 3.0 版本，并将在 6 月份宣布首个稳定版本，另一方面社区将兑现更多新的功能。起首，接下来即将交付的是 Kubernetes Service 集成，而 Proxyless Mesh、基于反压的智能流量调剂等功能正在前期的调研或开辟阶段。

下面，我们就拔取以上三个核心功能，深刻懂得它们的实现机制。

1. 全新办事发明模型

下图是 Dubbo2 的办事发明模型：Provider 注册办事地址，Consumer 经由注册中间调和并发明办事地址，进而对地址提议通信，这是被绝大年夜多半微办事框架的经典办事发明流程。而 Dubbo2 的特别之处在于，它把 “RPC 接口”的信息也融合在了地址发明过程中，而这部分信息往往是和具体的营业定义密切相干的。

而在接入云原生基本举措措施后，基本举措措施融入了微办事概念的抽象，容器化微办事被编排、调剂的过程即完成了在基本举措措施层面的注册。如下图所示，基本举措措施即承担了注册中间的职责，又完成了办事注册的动作，而 “RPC 接口”这部分信息，因为与具体的营业相干，弗成能也不合适被基本举措措施托管。

在如许的场景下，对 Dubbo3 的办事注册发明机制提出了两个请求：

1. Dubbo3 须要在原有办事发明流程中抽象出通用的、与营业逻辑无关的地址映射模型，并确保这部分模型足够合理，以支撑将地址的注册行动和存储委托给基层基本举措措施；
2. Dubbo3 特有的营业接口同步机制，是 Dubbo3 须要保存的优势，须要在 1 中定义的新地址模型之上，经由过程框架内的自有机制予以解决。

如许设计的全新的办事发明模型，在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大年夜的优势。

在架构兼容性上，如上文所述，Dubbo3 复用基层基本举措措施的办事抽象才能成为了可能；另一方面，如 Spring Cloud 等业界其它微办事解决筹划也沿用这种模型，在打通了地址发明之后，使得用户摸索用 Dubbo 连接异构的微办事体系成为了一种可能。

Dubbo3 办事发明模型更合适构建可伸缩的办事体系，这点要若何懂得？这里先举个简单的例子，来直不雅的比较 Dubbo2 与 Dubbo3 在地址发明流程上的数据流量变更：假设一个微办事应用定义了 100 个接口（Dubbo 中的办事），则须要往注册中间中注册 100 个办事，假如这个应用被安排在了 100 台机械上，那这 100 个办事总共会产生 100 100 = 10000 个虚拟节点；而同样的应用，对于 Dubbo3 来说，新的注册发明模型只须要 1 个办事（只和应用有关和接口无关）， 只注册和机械实例数相等的 1 100 = 100 个虚拟节点到注册中间。在这个简单的示例中，Dubbo 所注册的地址数量降低到了本来的 1 / 100，对于注册中间、订阅方的存储压力都是一个极大年夜的释放。更重要的是，地址发明容量彻底与营业 RPC 定义解藕开来，全部集群的容量评估对运维来说将变得加倍透明：安排若干台机械就会有多大年夜负载，不会像 Dubbo2 一样，因为营业 RPC 重构就会影响到全部集群办事发明的稳定性。

2. 下一代通信协定：Triple

我们将 Dubbo3 的新协定定名为 Triple，有代表第 3 代协定的意思。在云原生背景下，Triple 协定须要解决两大年夜问题：

• 通信协定和数据传输格局的标准化问题。这涉及到 RPC 协定、数据定义、数据传输等环节，将来可移植性、不被厂商锁定会成为每个上云企业用户的诉求，组件内的私有协定和特稀有据格局，必定会成为很多用户选型的挂念。
• 穿透性、通用性问题。在 Mesh 等架构假想下，微办事甚至所有组件的通信都要经由 sidecar 代理转发，理论上，Sidecar 是要透明的转发流量的（收到什么就转发什么），起码 payload 不该该是 Sidecar 存眷的；而 Sidecar 在某些时刻也须要感知流量内容的，因为它要基于些做流量的调剂，这个时刻，Triple 就要做到足够通用 -- 让所有的 Sidecar 都能在预期的处所取到其存眷的元数据，而不消解析全部 payload。

除了以上两个核心问题，Triple 协定还须要被设计用来支撑更多的营业语义。

• 协定应当供给更完美的请求模型，除了 Request/Response 模型，还应当支撑 Streaming 和 Bidirectional。
• 在机能上，新的协定应当保存 request Id 机制，以避免 HOL 带来的机能损耗。
• 新协定应当易于扩大，包含但不限于 Tracing、Monitoring、BackPressure 等支撑。

基于以上需求，Triple 协定是完全基于 HTTP/2 之上构建的，别的，Triple 协定将会做到完全兼容 gRPC 协定；在办事定义、数据格局定义以及传输格局上，Triple 将更增长对 Protobuf 的支撑。

3. 同一的路由规矩

Dubbo3 会对办事治理规矩进行周全的重构，以更好的适应云原生基本举措措施的变革。

当前的 3.0 preview 版本供给了一个重构后的路由规矩机制原型，固然当前版本的实现还须要持续加强，但从设计理念上，我们可以解读出：Dubbo3 期望供给一种跨平台、跨说话、跨多种安排架构的通用路由规矩。

跟着微办事对治理需求的发掘，Dubbo2 路由规矩除了在语义表达上不克不及涵盖所有场景之外，更为重要的是，其基于特定说话、特定主机 ip 的过滤机制，已不再适应底层调剂平台的工作机制，Dubbo3 须要引入一种全新设计的路由规矩。而对于“跨多种安排架构” 这个点，我们假想将来以 Dubbo 构建的微办事会有三种安排架构：传统 SDK、基于 Sidecar 的 Service Mesh以及离开 Sidecar 的 Service Mesh，这三种安排形态都将由 Dubbo3 同一的路由规矩进行治理。

• 基于 Sidecar 的 Service Mesh，经典的 Mesh 架构，自力的 sidecar 运行时接收所有的流量。
• 离开 Sidecar 的 Service Mesh，变种 Mesh 架构，没有 sidecar 运行时，富 SDK 直接经由过程 xDS 与控制面通信，我们将在后续宣布关于 Proxyless 模式更具体的解读。

实践中的 Dubbo3

云原生微办事项革在各大年夜厂商内部早已展开，比拟于当前开源社区的 preview 版本，Dubbo3 在阿里巴巴的开辟与实践已经在慢慢铺开：部分功能已经在阿里巴巴的部分营业线上获得了范围化验证（考拉），并且更多的功能和营业线也将进入试点、推广阶段（饿了么、钉钉等）。有一点是值得特别说起的是：在接下来阿里巴巴的微办事架构进级计谋中，Dubbo3 将成为阿里巴巴经济体将来独一的标准办事框架，它将慢慢在所有营业线代替 HSF 和 Dubbo2，并且我们等待在接下来的 1-2 年 Dubbo3 内能覆盖大年夜多半重要的营业线。

说在这里，有须要提一下阿里巴巴的微办事框架演进过程。大年夜概在 2011 年，阿里巴巴开源了 Dubbo2 这一款办事框架并获得极大年夜成功，在 Dubbo2 开源不久，在阿里巴巴内部又成长出了一款全新的办事框架 -- HSF，两者在设计理念上是高度类似的，而经由这么些年的成长，HSF 得以跟随阿里巴巴的营业体系更快速的成长，由其是在大年夜集群、大年夜流量治理下展示出了更好的机能和稳定性。在阿里云原生微办事计谋下，整合各个优良的框架并成长同一品牌的 Dubbo3 被纳入成长筹划，在此背景下，Dubbo3 实现了Dubbo2 与 HSF 的融合，并将推动实现内、外技巧栈的同一。

除了阿里之外，工商银行等标杆用户也已启动了对 Dubbo3 项目标试点。从社区角度来说，preview 预览版本的宣布只是开端，将来跟着阿里巴巴、工商银行等更多标杆用户的周全落地，将推动项目更快、更高质量的成长，助力项目保持持续的立异才能和社区生命力。

将来筹划（Roadmap）

以下是 Dubbo3 的 Roadmap，截止此文发稿，社区已经完成了 3.0 preview 版本的宣布。

在 6 月份，我们期望能迎来 Dubbo3 的首个社区正式版本。

随后，一向到下半年的 11 月份，我们将重点投入在对 Kubernetes、ServiceMesh 架构的支撑上，中心当然也包含了对办事治理规矩的周全重构。

在此之后，我们将开端在办事柔性上的测验测验，以期供给一种能更高效的应用资本且能进步体系稳定性的流量高度机制。

本文开篇关于云原生微办事项革部分思惟引自阿里云高等技巧专家、CNCF TOC 张磊 《Microservices - A Cloud Native View》一文分享。

本文为阿里云原创内容，未经许可不得转载。