简介： 如今，Dubbo 已经毕业一年，越来越多开发者开始询问 Dubbo 3.0 到底有哪些变化，阿里巴巴内部到底用不用 Dubbo，这是不是一个 KPI 开源项目以及 Dubbo 和 Spring Cloud 之间到底是什么关系。本文，将独家对话 Dubbo 项目二代掌门人北纬（GitHub ID@beiwei30），听他一一解答上述问题。

作者 | 北纬、赵钰莹

导读：2008 年，Dubbo 项目诞生；2014 年，由于内部团队调整，Dubbo 暂停更新；2017 年，北纬带领团队重新唤醒 Dubbo，并将其捐献给了 Apache 基金会。短短 15 个月，Dubbo 便从基金会毕业。如今，Dubbo 已经毕业一年，越来越多开发者开始询问 Dubbo 3.0 到底有哪些变化，阿里巴巴内部到底用不用 Dubbo，这是不是一个 KPI 开源项目以及 Dubbo 和 Spring Cloud 之间到底是什么关系。本文，将独家对话 Dubbo 项目二代掌门人北纬（GitHub ID@beiwei30），听他一一解答上述问题。

Dubbo 回归的这些年

Dubbo 项目诞生于 2008 年，最初只是一个阿里内部的系统；2011 年，阿里 B2B 决定将整个项目开源，一年时间就收获了来自不同行业的大批用户；2014 年，由于内部团队调整，Dubbo 暂停更新；2017 年 9 月，就在该项目将近 3 年没动静的时候，Dubbo 连续发布了好几个新版本，并且开始在内部招募对 Dubbo 感兴趣的同事。新版本背后的主力开发团队是阿里巴巴中间件团队，其中一个最重要的人就是北纬，他从 2017 年 7 月开始全面接手 Dubbo。

“我知道这是一个特别出名的开源软件，但是很长一段时间没有人维护，我当时在阿里内部的工作方向和 Dubbo 完全一致，也是做服务框架，所以对于认知 Dobbo 并不是非常困难。

接手之后，我们开始没有做太多事情，只是对外表示会重新维护这个项目，就收到了很多积极的反馈，这让我非常惊讶，很多开发者也在问我们可以重新维护多久。随着对这个项目的深入了解，我发现国内很多大型厂商，甚至传统国企都在广泛使用该项目，当时也觉得自己的责任重大，不知道可不可以把这个项目做好。”

彼时，北纬面临的第一个问题是：在 Dubbo 主版本停止更新的这些年，业界出现了很多 Dubbo 的分支版本，不同的团队都在维护自己的分支，如果不重视这一客观事实，很可能导致只有主版本在快速迭代，其他社区成员根本参与不进来，这样的开源意义不大。采访中，北纬表示：“对 Dubbo 来说，这些分支版本同样重要。我们还是希望可以给大部分深度用户一条安全的合并路径，根据我们的主要版本进行迭代。在这个过程中，我们和几大主流分支版本的开发团队都进行过交流，他们也非常愿意同主版本进行合并。”

在 Dubbo 正式复出之后，北纬也听到了一些开发者的疑问，比如这次能维护多久之类的。“既然放到阿里巴巴下面，开发者有这样的担心，那我干脆就把它放到中立的位置上，Apache 基金会是一个很好的选择，因为 GPL 协议太偏理想化，Dubbo 项目更多用在商业化公司，GPL 协议可能会影响后续推广。相对来说，Apache 协议比较实用。”

正是这一决定让广大开发者见到了最短时间从 Apache 基金会毕业的项目：2019 年 5 月 21 日，Dubbo 在仅用时 15 个月的情况下从 Apache 基金会毕业。

“我记得，与 Dubbo 同期毕业的有五个项目，Dubbo 是用时最短的。我们并不着急让 Dubbo 毕业，但我们原来预期的时间比 15 个月还要短，但碍于基金会的沟通流程，时间周期会相对拉长。”

Apache 基金会的特点是宽进严出，也就是说进去可能相对容易，但毕业是难的，而且非常强调公开透明。在国内，大部分人习惯通过微信和钉钉沟通，响应时间也会比较短，但 Apache 基金会是一个面向全球的组织，所有交流都基于邮件传递，一项提议必须在 72 小时内（考虑到全球的时差问题）没有成员提出反对才可以被采纳，这些流程都让时间周期变得更长。

如今，Dubbo 项目已经毕业一年有余，整个社区拥有 18 名 PMC 成员，57 名 committer，以及多达 370 名贡献者，社区代码比例已经超过 50%。在采访中，北纬表示，过去一年，Dubbo 在多语言建设方面先后从社区收获了 JS、Python、Erlang、PHP、Go 的实现，特别郑重感谢千米网、乐信以及其他开发者们，为社区带来了多语言支持。提到 Dubbo，大家第一个想到的可能还是 Java，但目前 Dubbo go 已经在 1.5 版本追平 Dubbo java 2.7 的特性。目前正在和 Java 齐头并进，一起规划 Dubbo 3.0 中云原生的路线图。

自 Dubbo 2.7 版本之后，整个发版节奏逐渐变慢，很多开发者也注意到“Dubbo 3.0 will come soon”的公告挂了很久。北纬表示，其实是有意识放慢了发版节奏，追求功能的稳定，这不仅仅是因为 Apache Dubbo 的深度用户，比如工商银行、携程、滴滴、斗鱼、瓜子等对 Dubbo 的使用规模越来越大，整个阿里经济体未来也会开始在内部核心电商业务陆续推进 Dubbo 和 HSF 的融合，Dubbo 的用户越多，团队的敬畏感越强烈。

在带领 Dubbo 前进的过程中，团队也听到了来自开发者社区的声音，比如 Dubbo 和 Sping Cloud 是什么关系？是不是二选一就够了？Dubbo 和 gRPC 之间的差别是什么？这是不是阿里的一个 KPI 开源项目？阿里内部用吗？

阿里与 Dubbo 之间的关系

“事实上，从我负责这个项目以来，我个人的体感是大家一直比较担心这个项目能不能持续发展，会不会断更。我也知道一些开发者在担心 Dubbo 只是阿里主导的 KPI 开源项目。”

根据 X-lab 开放实验室最新发布的《2020 年微服务领域开源数字化报告》，Dubbo 的开源活跃度全球排名 693，在微服务框架中排名第五，仅今年参与过社区建设的开发者数量已经达到 500 多人。整个社区蓬勃发展，来自外部的代码贡献量已经超过来自阿里员工的贡献量。

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

在阿里巴巴云原生公众号后台回复“微服务报告”即可查看完整报告。

“我一直认为社区很重要，单靠核心团队的几位工程师来做这件事情非常困难，一些想法也是我们想不到的。如今，全国各地有上百家企业在使用 Dubbo，仅依靠我们两三位工程师的力量远远不够，我们希望社区内的开发者可以更多地参与进来。”

一直以来，开源的理想状态可能就是单纯依靠情怀，但这真的很难做好，靠情怀的始终是少数人，尤其是中国目前的开源远未达到这种状态，还处于发展过程中。采访中，北纬表示，对 Dubbo 而言，不管开发者最初进入并对项目有所贡献的原因是什么。重要的是，我们希望能够让整个社区保持开放，即便个别工程师仅仅只是为了日后找份工作来参与社区也没有关系，我认为这种想法很正常，毕竟贡献项目会占据开发者很多业余时间，我们也希望这个项目可以对大家有所帮助。

此外，阿里巴巴内部也在采用 Dubbo 项目，并且开始逐渐向核心交易场景推进。在 Dubbo 最初的成长过程中，阿里内部曾经提过“整个公司大统一，希望不要重复建设，但凡相同的项目都要合并”的想法。当时，淘宝的 HSF 项目也是一个中间件服务框架，与 Dubbo 做的事情高度重合，所以当时表示要将两个项目进行合并。

时至今日，HSF 和 Dubbo 在阿里经济体内部都有落地的场景。北纬表示，选择权由业务视自己的诉求来决定，技术上保证了框架之间的互操作。相对来说，电商场景里 HSF 的使用是主流，而云的场景里 Dubbo 使用更多。当然，对于这么大规模的服务化场景，统一技术栈一直是我们的诉求和目标。在云原生时代 Dubbo 3.0 的定义中，我们已经开始以开源的 Dubbo 作为核心进行融合，并以此为基础定义云原生场景中的关键特性，在集团部分电商业务上已经进入落地阶段，后续也会跟大家分享我们的实践经验。

如何看待 Dubbo 和 Spring Cloud 的关系？

长久以来，总有开发者喜欢将 Dubbo 与 Spring Cloud 进行比较，提到这两个名字的第一反应往往是应该选哪个，而不是二者如何配合使用。在北纬看来，这主要还是技术选型的问题，以及用户对随之而来的切换成本的顾虑。其实这是一种误解，两者的关系不是非此即彼。今天的 Dubbo 已经成为了 Spring Cloud Alibaba 中一个重要的技术组件，Dubbo 服务和 Spring Cloud 服务可以完美的互相调用。未来，Dubbo 3.0 进一步的简化了 Dubbo 和 Spring Cloud 混布场景中服务基础设施的部署。

如今，Spring Cloud 依托于 Spring 已经成为 Java 开发的标准框架，这是不争的

事实，并结合大量业界经验逐渐抽象出一套微服务通用架构模式标准。这套标准的好处在于可以让开发者非常便捷地进行微服务软件产品开发，且在整个 Spring 生态的加持下已经成为开发者的“一揽子”解决方案。

相较之下，Dubbo 是阿里对微服务领域持续实践的产品。在框架设计之初，扩展性、灵活性就被放在了一个很重要的位置，这也是为什么社区对 Dubbo 的热情一直高涨的原因。随着 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 在注册数据的模型上达成高度统一，复用同一套服务注册中心，进一步简化混布场景中的架构。

“我们把选择的自由留给用户，这是 Dubbo 3.0 中的重要目标。”

此外，北纬整个团队也在积极发展 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 应用的能力。

Dubbo 和 gRPC？

Spring Cloud 和 Dubbo 之间部分互补可能说的通，但 Dubbo 和 gRPC 确实是极为相似的。作为高性能、开源且通用的 RPC 框架，gRPC 多年来受到了众多开发者的欢迎和采纳。

相似就免不了被开发者比较，对此，北纬很坦然：“我们从不避讳 gPRC，它是一个令人尊敬的对手，是云原生基础设施之间通讯协议的事实标准。gRPC 的发展以及 gRPC 每年的会议，我们一直都有关注。”

“我们从 gRPC 身上学到最有价值的一点就是反思 Dubbo 2 中协议设计的不足，开始重视云原生支持领域里两个重要的问题：多语言支持和网关 /Mesh 解析友好。”采访中，北纬表示，在 Dubbo 3.0 中，新版本的协议是重中之重，除了解决上述两个问题，对 gRPC 协议的兼容也是新协议的设计目标之一。

在云原生时代，gRPC 作为 RPC 框架走在了前面，这一块短板在北纬看来是要尽快补齐的，而 Dubbo 的优势是不单单是一个 RPC，而且是一个有着强大治理能力的服务框架，可以这么说，Dubbo 是 gRPC with batteries。同时，Dubbo 在国内用户群体巨大，在业务向云原生技术迁移的历程中，Dubob 3.0 将可以发挥出巨大作用。

Dubbo 的未来发展

如今，社区中的很多开发者都对 3.0 版本期待已久。北纬表示，3.0 版本的主基调就是云原生支持，重点思考云原生友好的新一代 RPC 协议、应用级服务注册发现、K8s 原生服务发布、Mesh 控制面 xDS 协议对接以及分布式服务柔性等重磅级特性。

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

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

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

回到 Dubbo 重启开源之时，生态相对薄弱。毕业 15 个月之后的今天，Dubbo 生态已经日益完善。

（如今 Dubbo 丰富的扩展实现）

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

“或许如今的生态还不够完善，但也是极大丰富了，我心中的完善是希望能够产出一个官方推荐的 Dubbo Stack，免除用户选择上面的烦恼。至于 Dubbo Stack 中是否都源自阿里，我倒是抱着顺其自然的态度，这还是需要数据说话，谁家的组件在生产系统中运用最广，我们就推荐谁。总的来说，这件事情的决定权在社区和 Dubbo 用户。”