STAR暴涨115%！阿里重启Dubbo开源背后的故事，你有酒吗，兄弟？

Posted 2021-04-06 左潇龙

自从去年7月份阿里宣布重启Dubbo开源以来，开源社区热度最高的两个问题：一是这次开源和以前有什么不一样的地方？二是阿里的Dubbo和Spring boot、 Spring cloud 是什么关系？

阿里巴巴高级技术专家，Dubbo开源项目负责人罗毅在Qcon全球软件开发者大会上分享了Dubbo的现状与未来规划，以及Dubbo进入Apache孵化的历程。

Dubbo的基本原理

简单的说，Dubbo是基于Java的RPC框架。如图所示，Dubbo工作分为4个角色，分别是服务提供者、服务消费者、注册中心和监控中心。

Dubbo 工作原理

Dubbo 整体架构图

从Dubbo的整体架构图来看，从左往右分为两部份，左半边蓝色背景的部分代表服务消费者，右半边绿色背景的部分代表服务提供者。从上往下看又分为九层，左边九层按功能来划分又被分为了三大类，分别是面向用户的 biz，框架核心 RPC 以及负责远程传输的 Remoting，图的右边按面向人群又划分为了两类，上面两层是面向用户的API，而下面七层是面向扩展提供者的SPI。

图中的线代表对象与对象之间不同的关系，紫色代表继承、黑色代表依赖、蓝色虚线代表服务注册、服务订阅的过程，也就是上面讲的部署阶段，红色代表一次完整的RPC调用，也就是运行阶段。顺着红色的线，可以体验一次完整的 rpc 调用是如何进行的。

解读完Dubbo的架构图，再来看看架构图中体现的设计原则。Dubbo秉承高内聚、低耦合的设计，这一点体现在架构图中九层的清晰划分上，也体现在依赖的方向上。线条的方向永远是从上指向下，没有循环依赖和反向依赖的出现。Dubbo还有一个很重要的设计哲学就是平等对待第三方的扩展，即Dubbo内建的功能也是通过同样的扩展机制提供出来的，第三方的扩展和内建功能可以相互取代。正是由于Dubbo将第三方扩展当成框架的一等公民，为未来基于这个机制建立生态带来了可能性。

重启开源的缘由

Dubbo重启开源的缘由主要有四个方面：战略、社区、生态和回馈。

首先阿里巴巴将开源提到了新的战略高度，去年云栖大会上阿里云宣布了加大技术投入、拥抱开源的策略。阿里巴巴在开源领域耕耘多年，目前在 GitHub 上有 150 个开源项目，总 star 数超过 19 万，在全球的排名前十。这其中有不少大家耳熟能详的项目，包括 jstorm, rocketmq, fastjson, druid, weex，当然还有 Dubbo。其中 jstorm 和 rocketmq 成为 apache 的顶级项目，而 weex 和 dubbo 也正在 apache 中孵化。阿里，尤其是阿里云，有意愿成为一家科技公司，保持在开源上的领先，打造技术影响力，并最终帮助到企业的生意。

从社区来看，这两年由于疏于维护，社区提交的 pull request 和问题没有得到及时的解决，一些公司不得不开始自己维护dubbo的私有分支，版本分化严重，社区无法分享这些分支上的工作。所以，Dubbo希望与社区进一步的互动，同时激发 Dubbo 团队的产品灵感。

众所周知，一个活跃的社区必将产生一个繁荣的生态，而一个繁荣的生态将会普惠所有使用 Dubbo 的人，更重要的是，其中收益最大的将会是Dubbo本身，毕竟很多有趣的想法单单靠单一团队的力量是无法提供的，需要开发者们共同推动。目前Dubbo团队就是阿里巴巴内部负责服务框架的团队，在大流量、大规模集群、服务治理领域有着丰富的实践，未来也将回馈给社区。

Dubbo 开源的现状

从数据维度来看，7月重启至今，Dubbo 在 github 上的 star 数增长了 115% ，超过了 1.9 万，目前在 GitHub java 类项目中排名 7 位，在去年开源中国举办的2017最受欢迎的开源项目中 Dubbo 和阿里巴巴其他三款软件 fastjson、druid、rocketmq 共同入选。

从用户来看，主要有3种类型，第一类是以阿里巴巴，滴滴，当当为代表的互联网企业；第二类是向互联网转型的大型企业，其中有中国工商银行、中国电信和中国人寿；第三类是使用dubbo作为服务化方案的 ISV，如亚信，文思。这些企业中，有一些维护着自己的私有分支，有些企业的员工积极参与Dubbo的建设，在这次进入apache孵化的过程中，当当、去哪儿、微店的员工成为了初始成员。今年我们将在北上广深、及杭州举办几场Dubbo开发者沙龙，将为工程师们分享架构分析、源码解读、未来规划、案例分析等内容，最近的一次将在6月23日上海浦东创新港举行。

如何才能重新赢得社区的信任成为Dubbo重启开源的重要目标，为此重新建设了网页和文档，全面更新了三方的依赖，在打好基础的前提下，又确立了版本发布策略，采取特性版本和维护版本并行，每个月至少发布一个版本。迄今为止，已经发布了7个维护版本和2个特性版本。在这些版本中，重点考虑了社区呼声最高的特性，其中就有 对spring boot 和对 REST 服务的支持。最后，为了打消社区对Dubbo未来发展的顾虑，阿里做出了将Dubbo捐献给Apache基金会的决定。

Dubbo的未来规划

Dubbo 后续规划主要围绕技术趋势与自身定位两块：从技术趋势来看，主要包含3个方面：

第一方面：模块化和元数据。通过这两块的优化来解决适应未来技术方向的问题，也就是微服务和云原生，具体来说，目前 Dubbo 服务治理与网络传输耦合严重，通过进一步的模块化工作可以为 Dubbo 成为服务网格中的数据面板做好准备。元数据目前既包含服务注册信息，也包含服务配置信息，将两者分离可以更清晰的分开注册层和配置层，为适配微服务的注册中心和配置中心打好基础。

第三方面：增强异步化。包括对 CompletableFuture 的支持以及跨进程 Reactive Stream 的预研，目前 Reactive Stream 在 Dubbo 3.0 中正在孵化，压测表明这项技术对于提升 CPU 利用率和系统的吞吐率有极大帮助。

从生态建设来看，就是利用核心的扩展能力尽可能多的提供开箱即用的扩展实现。按照架构图中的层次划分归纳了每一层可能提供的扩展实现。其中蓝黑色的代表Dubbo框架已经支持的，绿色部分代表这次重启开源之后新加入的，而橙色的部分代表我们计划在未来加入的。从下往上，未来在序列化层计划加入对 Protobuf 的支持，在 Transport 层加入对 HTTP2 的支持，在 Protocol 层加入对 gRPC 的支持，在 cluster、router、loadbalance 代表的服务治理层计划加入阿里对服务治理方面的实践。

再往上通过元数据的优化，可以更清晰的分开注册层和配置层，从而可以在注册层加入更多的对微服务注册中心的支持，比如 eureka，consule，在配置层也可以开始支持配置的动态推送，在这两层会提供对阿里体系中的注册中心 config server、配置中心 diamond 的支持。最顶上是对 API 的支持，对 Spring Cloud 的适配。

生态建设的另一方面是要解决 dubbo 服务与外界互通的问题。这里的互通有两方面的含义。第一是 Dubbo 服务与外围系统互通，第二是异构系统如何调用Dubbo服务的问题。

外围系统也分为两类，图中草绿色部分包括了 Dubob admin, test server, mock server, swagger server，无非就是解决服务如何查询，服务治理规则如何配置，如何测试服务，开发阶段如何解决上下游依赖，服务的 API 支持等问题，这些问题与Dubbo服务紧密相关，后续计划提供这方面的支持。

从图中橙色的部分来看，包括了服务注册中心、配置中心、鉴权中心，链路追踪和监控中心，这些系统也有很多开源和商业的选择，Dubbo的思路是尽可能多的提供适配性来为用户带来开箱即用的体验。

值得一提的是，这一块的建设是双向的，目前 spring cloud sleuth 主动支持了 Dubbo。谈到异构系统如何调用Dubbo服务，本质上是多语言支持的问题。要解决多语言调用，无非有两种做法，一种是通过代理方式来调用，代理根据部署形式的不同又分为中心化的 api gateway 方式和本地部署的 sidecar 方式。对于 api gateway 方式，只需要 Dubbo 服务可以按照 json-rpc 或者 rest 的方式暴露服务就好。另一种调用方式就是原生语言客户端，要支持的语言包括了常用的 python，node，php，go 等等。

通过核心、生态、互通三方面的建设，Dubbo体系可以成为服务化改造的国内首选方案，并且能够很好的适应微服务，云原生这两个技术趋势。

最后从云原生来看，Dubbo Mesh成为了重点。目前各大云计算厂商开始定义云原生，鼓励用户将应用往云上迁移。云原生的定义每家都不太一样，但是其中可以看到有这么两个趋势。一个是云计算场景里多语言支持是强诉求，基于单一语言的架构和方案会有很大的局限性，这可能也是 Spring Cloud 体系的短板，另一个是原来与应用共生的服务治理能力开始从应用中解耦出来，并下沉为平台的基础能力，这样做的好处是应用开发更简单、应用更轻、多语言支持也变得容易。这一块就是 linkerd 率先提出的服务网格的概念。

Dubbo 通过进一步的模块化工作，可以把服务治理能力单独剥离出来独立部署，成为服务网格中的数据面板，被称之为 Dubbo mesh，它负责接管由本地所有rpc流量，并负责与外围的注册中心、配置中心对接。在服务网格下，一次RPC调用就会变成， 左边草绿色的 Dubbo rpc 发起一次调用，请求会发给和部署在一起的 Dubbo mesh，Dubbo mesh 又会把这个 rpc 请求转发到对端的 Dubbo mesh，对端的 Dubbo mesh 又会将收到的请求发给对端的 Dubbo rpc, 也就是图中右边的橙色部分。

Dubbo进入apache孵化的历程，分为三个阶段：准备阶段、孵化阶段和毕业阶段。

 Apache 孵化阶段

准备阶段，要找到愿意帮助孵化的导师，向apache提交进入孵化的申请，经过导师们讨论并投票，如果通过的话就可以进入孵化。孵化阶段分为两大环节，第一个环节是公司和个人签署协议向apache移交代码和知识产权，目前Dubbo已经完成了第一个环节，之后就是在导师的指导下按照apache的规范做版本迭代、运营社区、发展更多的committer，如果最终通过了成熟度评估，就可以顺利毕业成为apache的顶级项目。