北京沙龙报名 | 关于Dubbo开源的那些事儿

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

2018年5月12日（周六），我们将在北京举行Dubbo开发者沙龙暨第四届阿里中间件性能挑战赛技术行，为你答疑解惑。免费报名活动，名额有限，先到先得哦。

Dubbo是阿里巴巴自研的分布式服务框架，自2012年开源以来，深得开发人员的喜爱，并被广泛用于服务化解决方案中。自去年阿里巴巴中间件团队宣布重启维护后，在社区引起极大的反响，目前在github上的star数增加至18000，并于2018年2月正式加入Apache孵化器进行孵化。本次沙龙，将为大家介绍近期Dubbo所完成的一些工作及未来规划，并对第四届中间件性能挑战赛赛题“挑战Dubbo Agent”做出详细解读。

还不了解Dubbo的童鞋，下面让我们一起来深入学习。

Dubbo 的基本原理

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

Dubbo工作原理

按照工作阶段又分为部署阶段和运行阶段。其中部署阶段在图中以蓝色的线来表示，代表服务注册、服务订阅的过程，而运行阶段在图中以红色的线来表示，代表一次RPC的完整调用。部署阶段中服务提供方在启动时在制定的端口上暴露服务，并向注册中心汇报自身的地址，服务调用方启动时向注册中心订阅感兴趣的地址。运行阶段中注册中心首先将地址列表推送给服务消费者，服务消费者从其中选取一个地址向对端发起调用。在这个过程中，服务消费者和服务提供者的运行状态会上报给监控中心。

Dubbo整体架构图

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

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

首先从图的左边开始，用户从 Proxy 层发起一次RPC调用，Dubbo 从 Registry 层拿到服务的地址列表，再通过 Cluster 层选择其中的一个作为目标地址，再流经Protocol 决定的执行链，最后将服务信息，包括要调用的服务名、方法名、参数等序列化，再经过应用协议编码，通过 Transport 层发送到网络上。右边的服务提供者从网络上收到数据以后，从下往上，依次通过应用协议解码、反序列化得到要调用的服务信息，再经由执行链，最终通过 Invoker 找到目标服务的目标方法，执行并返回结果。

解读完Dubbo的架构图，再来看看架构图中体现的设计原则。

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

Dubbo 开源的现状

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

从用户来看，主要有3种类型，第一类是以阿里巴巴，滴滴，当当为代表的互联网企业；第二类是向互联网转型的大型企业，其中有中国工商银行、中国电信和中国人寿；第三类是使用Dubbo作为服务化方案的 ISV，如亚信，文思。这些企业中，有一些维护着自己的私有分支，有些企业的员工积极参与Dubbo的建设，在这次进入Apache孵化的过程中，当当、去哪儿、微店的员工成为了初始成员。5月12日，Dubbo将在北京车库咖啡举行首次线下沙龙。

Dubbo 未来规划与进入 Apache 孵化

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

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

第二方面：如何将阿里在服务治理方面的经验回馈给社区。其中包括了路由策略、大流量和大规模，在路由策略中阿里打算引入多机房路由、参数路由、灰度路由等策略，在大流量方面重点考虑熔断、限流、隔离的支持，在大规模集群方面需要解决超大规模地址列表对CPU、内存带来的压力。

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

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

Apache 孵化阶段

目前Dubbo已经完成了第一个环节，之后就是在导师的指导下按照Apache的规范做版本迭代、运营社区、发展更多的committer，如果最终通过了成熟度评估，就可以顺利毕业成为Apache的顶级项目。