十年再出发，Dubbo 3.0 Preview 即将在 3 月发布

作者 | Apache Dubbo
来源|阿里巴巴云原生公众号

• 2011 年，阿里 B2B 团队决定将项目开源，一年时间就收获了来自不同行业的大批用户

• 2014 年，由于团队调整，Dubbo 暂停更新

• 2017 年，Dubbo 开源重启

• 2019 年，Dubbo 在仅用时 15 个月的情况下从 Apache 基金会毕业

• 2020 年，阿里内部开始 HSF 和 Dubbo 的融合

• 2021 年 3 月，Dubbo 3.0 Preview 即将发布

• ……

从 2011 到 2021，Dubbo 已经开源十年。十年，对于风起云涌的云计算领域是漫长且充满变化的，但 Dubbo 在这个时代的浪潮里不仅没有变成被人遗忘的“前浪”，更在云原生时代，迎来内核云原生技术栈全面升级。本文是对阿里集团服务框架负责人北纬的采访，他在阿里同时负责 HSF、Dubbo 和 Spring Cloud Alibaba。本文讲述了他 2017 年接手 Dubbo 后社区的进展，并展望开源十年的 Dubbo 将如何走好云原生之路。

---

2017年，我开始接手 Dubbo 项目后，我们对外表示会重新维护这个项目，就收到了很多积极的反馈，随着对这个项目的深入了解，我发现国内很多大型厂商，甚至传统国企都在广泛使用该项目，才意识到身上的责任。Dubbo 3.0 Preview 版即将在 3 月发布，我们准备了 Dubbo 3.0 前瞻系列电子书（**获取方式见文末）**，也借这个机会大家聊聊 Dubbo 重启开源后被频繁问到的问题：

• 从 Apache 毕业两年不到的时间，我们都做了什么？
• 阿里内部是如何进行 Dubbo 和 HSF 融合的？规模怎么样？
• 如何看待 Spring Cloud 和 gRPC?
• 3.0 有什么值得期待的？

同期毕业最快的 Apache 项目，多语言全面发展

2017 年，我负责这个项目以来，一些开发者在担心 Dubbo 只是阿里主导的 KPI 开源项目，比较担心这个项目能不能持续发展、会不会断更。既然这样，那我干脆就把它放到中立的位置上，Apache 基金会是一个很好的选择， 正是这一决定让 Dubbo 成为同期五个项目中最快从 Apache 基金会毕业的项目：2019 年 5 月 21 日，Dubbo 在仅用时 15 个月的情况下从 Apache 基金会毕业。

事实证明，把 Dubbo 捐给 Apache，让 Dubbo 变成一个社区主导的项目是一个非常正确的决策。根据 X-lab 开放实验室最新发布的《2020 年微服务领域开源数字化报告》，Dubbo 的开源活跃度全球排名 693，在微服务框架中排名第五，参与过社区建设的开发者数量已经超过 1 万多人，来自外部的代码贡献量已经超过阿里员工的贡献量。

数据来源 -《2020 年微服务领域开源数字化报告》

Dubbo 项目从 Apache 毕业 2 年不到的时间，整个社区拥有 21 名 PMC 成员，61 名 committer，以及多达 370 名贡献者。在过去一年，Dubbo 在多语言建设方面先后从社区收获了 JS、Python、Erlang、PHP、Go 的实现，特别郑重感谢千米网、携程网、乐信以及其他开发者们捐献或者提交了这些多语言版本的绝大多数代码，为社区带来了丰富的多语言支持解决方案。在于雨的带领下，Dubbo-go 可以说是当前众多多语言版本中最活跃的一个分支，有者非常活跃的 go 子社区及持续增长的企业级用户，目前 Dubbo go 已经在 1.5 版本追平 Dubbo Java 2.7 的特性；目前正在和 Java 齐头并进，一起规划 Dubbo 3.0 中云原生的路线图。

我们对这个大版本 Dubbo 3 的定义是云原生、阿里背书。计划分为三个版本迭代，在后面 Dubbo 3 的路线图中有详细的描述。Dubbo 3.0 正在紧锣密鼓的开发中，核心功能包括 Dubbo3 协议、应用级服务发现、新版路由规则等，go 与 java 版本预计将以同样的时间节奏兑现以上所有功能，3 月底会有 preview 版本与社区见面。

过去 2 年社区的经历更让我相信，单靠核心团队的几位工程师凭着单纯的开源情怀是很难持续的。全国各地有上百数千家企业在使用 Dubbo，仅依靠我们一个小团队的力量远远不够，我们希望社区内的开发者可以更多地参与进来。对 Dubbo 而言，不管开发者最初进入并对项目有所贡献的原因是什么。重要的是，我们希望能够让整个社区保持开放，即便个别工程师仅仅只是为了日后找份工作来参与社区也没有关系，我认为这种想法很正常，毕竟贡献项目会占据开发者很多业余时间，我们也希望这个项目可以对大家有所帮助。

Dubbo 和 HSF 融合，阿里先自己用上 Dubbo 再说

我面临的第二个最大的质疑是：阿里内部都不用 Dubbo，如何获得开发者的信任？

熟悉阿里技术历史的同学可能知道，淘宝的 HSF 项目也是一个中间件服务框架，与 Dubbo 做的事情高度重合。而 Dubbo 在开源过程中很多开发者诟病的也是阿里自己都没有在用 Dubbo。这也是我们一直在苦恼的：阿里内部的自研体系、商业化的产品技术与开源的项目，三方的技术路线一直没有机会融为一体。

随着阿里自研体系的上云，融合的机遇终于到来了。2020 年，阿里云提出了“三位一体”理念，即：将“自研技术”、“开源项目”、“商业产品”形成统一的技术体系，最大化技术的价值。

HSF 目前以 Dubbo 3.0 为核心，内部特性以 Dubbo 插件的方式存在，并把 HSF 只在阿里集团内部大规模场景下高并发、高性能等优化经验应用到 Dubbo 3.0 核心上，实现了内外功能的统一，使得社区和客户都能用到这些优质经验；另外一方面，Dubbo 3.0 云原生相关的功能借助于社区开发力量得到进一步发展。通过“三位一体”与社区达成开放共赢的局面。

我的老领导林昊、阿里人称毕大师，由于设计开发了 HSF 今年获得了中国计算机学会的杰出工程师奖，他在获奖采访中提到：作为工程师来讲，很大的成就感来自于自己所做的技术被公司大范围的使用，并且对这家公司的业务发展能起到很大的支撑作用；更大的成就感来自于自己做所的技术背后的思想、实现思路能影响到中国各大互联网公司、企业去拥抱微服务。随着 Dubbo 和 HSF 的整合，我们在整个开源的体系中更多地去展现了 HSF 的能力，能够让更多的人通过使用 Dubbo 像阿里巴巴之前使用 HSF 一样更好地构建服务化的系统。

在 2020 年 双11，Dubbo 3.0 在集团电商业务上已经进入落地阶段，电子书里也会跟大家分享一些我们的实践经验。

如何看待 Spring Cloud 和 gRPC？

在 Dubbo 沉寂的几年，出来很多新生的服务框架，Dubbo 和 Sping Cloud 是什么关系？是不是二选一就够了？Dubbo 和 gRPC 之间的差别是什么？

Dubbo 和 Spring Cloud 如何二选一？

长久以来，总有开发者喜欢将 Dubbo 与 Spring Cloud 进行比较，提到这两个名字的第一反应往往是应该选哪个，而不是二者如何配合使用。在我看来，这主要还是技术选型的问题，以及用户对随之而来的切换成本的顾虑。其实这是一种误解，两者的关系不是非此即彼。今天的 Dubbo 已经成为了  Spring Cloud Alibaba 中一个重要的技术组件，Dubbo 服务和 Spring Cloud 服务可以完美地互相调用。未来，Dubbo 3.0 进一步的简化了 Dubbo 和 Spring Cloud 混布场景中服务基础设施的部署。 Spring Cloud 依托于 Spring 已经成为 Java 开发的标准框架，这是不争的事实，并结合大量业界经验逐渐抽象出一套微服务通用架构模式标准。这套标准的好处在于可以让开发者非常便捷地进行微服务软件产品开发，且在整个 Spring 生态的加持下已经成为开发者的“一揽子”解决方案。

和 Spring Cloud 不同，Dubbo 在设计之初，扩展性、灵活性就被放在了一个很重要的位置。Dubbo 很容易集成别人，别人也容易集成 Dubbo。同时，Dubbo 经过大量用户生产验证，阿里在服务化领域持续实践的产品。这两点是 Spring Cloud 目前无法做到的。随着 Dubbo 恢复更新，其场景丰富程度与稳定性也有了非常大的提升，目前已经在多家头部公司大规模应用。

回到众多开发者对技术选型问题的顾虑：这两套框架并不是非此即彼。相反的，用户可以轻松的在这两套框架之间切换，甚至未来可以完美的在一起协同工 作，这得益于 Spring Cloud Alibaba 的出现。

Spring Cloud 拥有一个强大的国际化社区，阿里巴巴作为社区里的重要成员，也贡献出了 Spring Cloud Alibaba 这套实现，这也是目前整个 Spring Cloud 体系下最完善并且在持续更新的实现方案。

Spring Cloud Alibaba 出现

现在的 Dubbo 2.7 已经可以很好的在 Spring Cloud 体系下工作。通过 Spring Cloud Alibaba 中 Dubbo 的集成，Spring Cloud 应用可以调用原生发布的 Dubbo 服务，Spring Cloud 发布的 Dubbo 服务也可以被原生的 Dubbo 客户端调用。这个得益于 2.7 中服务自省的实验性项目，以及 Spring Cloud 侧对 Dubbo 的适配。

在正在开展的 3.0 大版本中，这个实验性的项目进化为原生应用级服务注册机制。通过这个特性，未来 Spring Cloud 应用和 Dubbo 应用可以更加完美的混布。用户可以为 Spring Cloud 和 Dubbo 复用同一套服务发现、服务配置、和服务管理体系，为 Dubbo 和 Spring 互通需要额外搭建网关将成为过去式，用户可以零成本的在两者之间切换，或者视场景不同选择不同的框架，甚至可以在同一个应用中混用。Dubbo 与 Spring Cloud 混布场景中业界常规的 Proxy 集群终于去掉，整个体系的架构更加简单和稳定。在 Dubbo 3.0 版本中，整个团队会继续进化应用级服务注册的想法，期望通过这项工作让 Spring Cloud Alibaba 与 Dubbo 在注册数据的模型上达成高度统一，复用同一套服务注册中心，进一步简化混布场景中的架构。

另外，我们团队也在积极发展 Spring Cloud Alibaba 生态。作为国内 Java 界最具影响力的团队之一，阿里中间件团队一直在密切关注 Spring 项目，通过 Spring 的封装提升阿里的中间件开发体验。阿里巴巴电商体系绝大部分应用已经实现 Boot 化。

当 Spring Cloud 初具影响力的时候，我们主动通过 Spring Cloud 来集成阿里巴巴开源组件就变成一件自然而然的事情了 目前，Spring Cloud Alibaba 已经支持 Nacos 作为服务注册中心、配置中心，Sentinel 作为限流，Seata 作为分布式事务组件，RocketMQ 作为分布式消息组件，当然还有 Dubbo 作为 RPC 组件，全面取代了已经宣布停止更新的 Spring Cloud Netflix 全家桶。另外，为了加速国内工程师对 Spring Initializr 的访问，团队还通过阿里云上托管的 start.aliyun.com 提供了快速生成 Spring Cloud Alibaba 应用的能力。

无论从 GitHub 的项目活跃度数据还是关注度数据来看，毫不夸张地说，Spring Cloud Alibaba 已经成为 Spring Cloud 框架中的事实标准了。

如何看待 gRPC？

我们从不避讳 gRPC，它是一个令人尊敬的对手，是云原生基础设施之间通讯协议的事实标准。

但是 Dubbo 的优势是不单单是一个 RPC，而且是一个 有着强大治理能力的 服务框架。我们认为：Dubbo 是 gRPC with batteries。

我们从 gRPC 身上学到最有价值的一点就是反思 Dubbo 2 中协议设计的不足，开始重视云原生支持领域里两个重要的问题：多语言支持和网关/Mesh 解析友好。在 Dubbo 3.0 中，新版本的协议是重中之重，除了解决上述两个问题，对 gRPC 协议的兼容也是新协议的设计目标之一。gRPC 有几项明显的优势：在支持 HTTP/2 协议上走在了前列，提供了非常丰富的多语言库支持，与 Google 主导的许多云原生基础设施无缝打通。gRPC 及时下流行的 Mesh 等云原生技术构建了一套看起来相对完善的微服务技术栈，落地这套技术栈看起来是基于 gRPC 的微服务解决方案。

但 gRPC 框架自身而言还是专注在 RPC 通信。相比而言，Dubbo 提供了一站式的微服务开发、治理解决方案，Dubbo 有更易用的面向接口的服务定义模型，有更完善的服务发现、服务治理机制。同时，在即将发布的 3.0 规划中，Dubbo 3 也将提供官方的 Mesh 解决方案支持，继续给社区带来易用的、一站式的解决方案。 

Dubbo 3.0 展望：对云原生支持

社区中的很多开发者都对 3.0 版本期待已久。Dubbo 3 的主基调就是云原生支持，计划分为三个版本迭代。重点交付云原生友好的新一代 RPC 协议、应用级服务注册发现、K8s 原生服务发布、Mesh 控制面 xDS 协议对接以及分布式服务柔性等重磅级特性。

• 3.0 版本，重点发布应用级服务注册发现、Tripe、新路由规则。

• 3.1 版本，重点发布 K8s 原生服务、Mesh 控制面 xDS 协议对接。

• 3.2 版本，重点发布分布式服务柔性。

目前应用级服务发现已经在内部和一些头部用户的场景做试点，后续随着项目的进展，团队会第一时间发布功能实现细节。通过 Dubbo 3.0 的发布，我们期待带来一款向云原生迁移友好的，对云原生基础设施友好的新一代服务框架体系。

未来，Dubbo 项目总的发展基调还是坚持合作开放的开源路线不动摇，追求更高质量和功能更完善的路线不动摇。目前，社区发展的重中之重是 Dubbo3.0 演进。在不久后的 9 月份， Dubbo 3.0 应用级注册发现将在阿里巴巴内部和开源侧各公司落地。这不仅是 Dubbo 迈向云原生微服务的第一步，也是对接 K8s 注册发现和跨框架 RPC 互通的前提。

就应用方而言，从接口级注册发现到应用级注册发现可以显著降低注册中心和客户端的内存压力。今年 双11，云原生服务治理规则会把 Dubbo 多年以来在大规模高并发服务治理方面的最佳实践融入云原生。下一代协议将基于 http2/protobuf 带来更好的生态和 Reactive 的全面支持，柔性增强所涵盖的自适应策略和分布式负载均衡将会在性能和稳定性上带来更大的突破。

回到 Dubbo 重启开源之时，生态相对薄弱 。如今，Dubbo 生态已经日益完善。

Dubbo 丰富的扩展实现

比如，多语言支持已经达到 6 种，30+ 生态子项目。在 Dubbo 主动集成周边的同时，我们也被第三方开源项目 Spring Cloud Sleuth、Zipkin、Skywalking、Envoy、tengine 等主动集成。

我心中的完善是希望能够产出一个官方推荐的 Dubbo Stack，免除用户选择上面的烦恼。至于 Dubbo Stack 中是否都源自阿里，我倒是抱着顺其自然的态度，这还是需要数据说话，谁家的组件在生产系统中运用最广，我们就推荐谁。总的来说，这件事情的决定权在社区和 Dubbo 用户。
 
最后，感谢十年来 Dubbo 的用户和社区贡献者们，对于 Dubbo 3.0 Roadmap 中的云原生友好的新一代 RPC 协议、应用级服务注册发现、K8s 原生服务发布等重磅级特性，**我们梳理了一系列前瞻的文章整理成了电子书。