简介： 做过微服务开发的开发者置信对 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 重构就会影响到整个集群服务发现的稳定性。

1. 下一代通信协议：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 的反对。

1. 对立的路由规定

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》一文分享。

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