Dubbo开源现状与未来规划

摘要：今天的话题是与的开源现状和未来规划，我们知道，过去一段时间疏于维护，去年阿里高调宣布重启开源之后，社区里问的最多的问题是，这次开源与上次有什么一样，还有就是和是什么关系希望通过这次的分享能够解答这些问题。

摘要： Dubbo 在过去一段时间疏于维护，去年阿里高调宣布重启 Dubbo 开源之后，社区里问的最多的问题是，这次开源与上次有什么一样，还有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么关系？希望通过这次Dubbo沙龙的分享能够解答这些问题。

本文章是根据朱勇老师在上海Dubbo沙龙的演讲稿进行整理，意在为大家展示最真实、最一手的沙龙技术干货。

前言
大家好，非常荣幸有机会和大家做这个分享。我先做个自我介绍，我叫朱勇，来自阿里巴巴中间件团队，主要工作在应用容器、微服务、RPC几个领域。我是 09 年加入阿里，13年加入中间件团队。

今天的话题是与 Dubbo 的开源现状和未来规划，我们知道，Dubbo 过去一段时间疏于维护，去年阿里高调宣布重启 Dubbo 开源之后，社区里问的最多的问题是，这次开源与上次有什么一样，还有就是 Dubbo 和 Spring Boot、Spring Cloud 是什么关系？希望通过这次的分享能够解答这些问题。

这次分享包含以下几个环节，Dubbo 基本原理、Dubbo 社区、开源现状、以及后续规划几个部分。

Dubbo 工作原理
考虑到有些同学可能对 Dubbo 不太熟悉，我先简单介绍下 Dubbo 的工作原理和架构。简单的说，Dubbo 是 基于 Java 的 RPC 框架。Dubbo 工作分为 4 个角色，分别是服务提供者、服务消费者、注册中心、和监控中心。按照工作阶段又分为部署阶段和运行阶段。其中部署阶段在图中以蓝色的线来表示，代表服务注册、服务订阅的过程，而运行阶段在图中以红色的线来表示，代表一次 RPC 的完整调用。部署阶段中服务提供方在启动时在指定的端口上暴露服务，并向注册中心汇报自己的地址，服务调用方启动时向注册中心订阅自己感兴趣的服务。运行阶段注册中心先将地址列表推送给服务消费者，服务消费者选取一个地址向对端发起调用。在这个过程中，服务消费者和服务提供者的运行状态会上报给监控中心。

其实，这里讲的基本原理套用到任何一个成熟的服务框架都是合适的，但是 Dubbo 在框架设计上有着自己的设计哲学。

这里是 Dubbo 的整体架构图。首先这张图看起来很复杂、信息量很大。我先介绍一下这张图的解读方式。这张图从左往右看，分为两部分，左半边蓝色背景的部分代表服务消费者，右半边绿色背景的部分代表服务提供者。从上往下看又分为九层。左边九层按功能来划分又被分为了三大类，分别是面向用户的 Biz 层、框架核心 RPC 以及负责远程传输的 Remoting，右边按面向人群又划分为了两类，上面两层是面向用户的 API，而下面七层是面向扩展提供者的 SPI。图中的线代表对象与对象之间不同的关系，紫色代表继承；黑色代表依赖；蓝色虚线代表服务注册、服务订阅的过程，也就是上面讲的部署阶段；红色代表一次完整的 RPC 调用，也就是运行阶段。我们顺着红色的线，来看下一次完整的 RPC 调用是如何进行的。首先从图的左边开始，服务消费者从 Proxy 层发起一次 RPC 调用，Dubbo 从 Registry 层拿到服务的地址列表，再通过 Cluster 层选择其中的一个作为目标地址，再流经 Protocol 决定的执行链，最后将服务信息，包括要调用的服务名、方法名、参数等序列化，再经过应用协议编码，通过 Transport 层发送到网络上。右边的服务提供者从网络上收到数据以后，从下往上，依次通过应用协议解码、反序列化得到要调用的服务信息，再经由执行链，最终通过 Invoker 找到目标服务的目标方法，执行并返回结果。解读完 Dubbo 的架构图，再来看看架构图中体现的设计原则。Dubbo 秉承高内聚、低耦合的设计，这一点体现在架构图中九层的清晰划分上，并且也体现在依赖的方向上。黑色的线条的方向永远是从上指向下，没有循环依赖和反向依赖的出现。Dubbo 还有一个很重要的设计哲学就是平等对待第三方的扩展，即 Dubbo 内建的功能也是通过同样的扩展机制提供出来的，第三方的扩展和内建功能可以相互取代。正是由于 Dubbo 将第三方扩展当成框架的一等公民，为未来基于这个机制建立生态带来了可能性。这一点，我们在后面规划部分进一步展开。

Dubbo 社区
Dubbo 社区，我想从战略、社区、生态和回馈四个方面讲一讲。首先阿里巴巴将开源提到了新的战略高度，去年云栖大会上阿里云宣布了加大技术投入、拥抱开源的策略。阿里巴巴在开源领域耕耘多年，目前在 Github 上有 150 多个开源项目，总 Star 数在 17 万，并且 Alibaba 这个 Group 在全球的排名进入前十。这其中有不少我们大家耳熟能详的项目，包括 JStorm, RocketMQ, FastJson, Druid, Weex，当然还有我们 Dubbo。其中 JStorm 和 RocketMQ 成为 Apache 的顶级项目，而 Weex 和 Dubbo 也正在 Apache 中孵化。社区方面，Dubbo 这两年疏于维护，很多开发者提交的 Pull Request 和 Issue 没有得到及时的解决，一些公司不得不维护 Dubbo 私有分支，版本分化严重，导致社区无法 分享这些分支上的成果。我们希望改变这一点，让整个社区都能享受到开源的好处。一个活跃的社区将会产生一个繁荣的生态，而一个繁荣的生态将会普惠所有使用 Dubbo 的人，最终形成社区和生态共同发展的良性循环。另外在阿里内部，负责 Dubbo 的团队就是负责服务框架的团队，我们在大流量、大规模集群、服务治理领域有着丰富的实践，这些会有计划地回馈给社区。

这里强调一点，为了打消社区对 Dubbo 未来发展的顾虑，我们做出了把 Dubbo 捐献给 Apache 基金会的决定，并且在2018新年之前，Dubbo 正式进入 Apache 孵化。Apache 认为 社区的重要性大于代码，非常注重多样性，强调一个项目需要有多个公司和个人贡献者参与，避免被一家公司左右，所以现在 Dubbo 的发展完全是按 Apache Way 社区化的方式来运作的；个人贡献者的参与方式可以是多种形式，除了贡献代码外，还可以通过报 Issue、增强文档、参与邮件讨论等方式；只要让社区看到你的贡献，你就可以一步一步从 Contributor 成为 Committer，再从 Committer 成为 PMC Member。所以希望 大家多参与 Dubbo 的社区互动，多分享你们在实践中的经验，反馈碰到的问题，只有你们的参与，Dubbo 的未来才有可能成功。

这里顺便分享下 Dubbo 进入 Apache 孵化的历程，希望对其他要把自己的项目捐献给 Apache 的小伙伴们有帮助。进入 Apache 分为三个阶段，准备阶段、孵化阶段和毕业阶段。准备阶段需要做的事情有找到愿意帮助孵化的导师，向 Apache 提交进入孵化的申请，经过导师们讨论并投票，如果通过的话就可以进入孵化。孵化阶段分为两大环节，第一个环节是公司和个人签署协议向 Apache 移交代码和知识产权，目前 Dubbo 已经完成了第一个环节。之后就是在导师的指导下按照 Apache 的规范 做版本迭代、运营社区、发展更多的 Committer，如果最终通过了成熟度评估，就可以顺利毕业成为 Apache 的顶级项目。

开源现状
Dubbo 开源的现状我打算从数据、用户、项目 三个维度分别阐述。数据方面是这样，从去年七月份重启开源，到目前为止，Dubbo 在 Github 上的 Star 数增长了 115% 达到了 1.9+ 万，目前在 Github Java 类项目中排名第 7 位，在去年开源中国举办的 2017 最受欢迎的开源项目中 Dubbo 和阿里巴巴其他三款软件 FastJson、Druid、RocketMQ 共同入选。

用户方面 Dubbo 的用户主要分为三类，第一类是以阿里巴巴、滴滴、当当为代表的互联网企业，第二类是向互联网转型的大型企业，如中国工商银行、中国电信和中国人寿等，第三类是使用 Dubbo 作为服务化方案的 ISV，包括亚信和文思。在这些企业中，有些维护着自己的私有分支，有些企业的员工积极参与 Dubbo 的建设，在这次进入 Apache 孵化的过程中，我们邀请了当当、去哪儿、微店的员工成为初始成员，6月份刚刚发展了有赞的一位开发者成为 Dubbo Committer。今年我们打算在北上广深、以及杭州等地举办几次 Dubbo 开发者沙龙，这是第二站。沙龙的主题是面向工程师的，包括架构分析、源码解读、未来规划、案例分析等内容，没能来到现场的也没有关系，整个沙龙会全程通过网络直播。

这几个月我们在 Dubbo 上的工作 围绕一个目标 进行的，就是如何才能重新赢得社区的信任。为此我们首先要打好基础，包括重新建设了网页和文档，全面更新了三方的依赖，在打好基础的前提下，我们又确立了版本发布策略，采取特性版本和维护版本并行，每个月至少发布一个版本的节奏，迄今为止，我们已经发布了 7 个维护版本和 2 个特性版本。在这些版本中，我们重点考虑了社区呼声最高的特性，其中就有 Spring Boot 的支持和对 REST 服务的支持。

下面这些事情是我们已经在进行中的，绝大多数都是我们后面要讲的规划中的事项，比如核心增强中的异步 API、Metrics、熔断，生态中的多语言客户端、Dubbo Mesh，还有对 Dubbo OPS 的增强；这里特别提一下 Dubbo OPS，现在我们已经将 OPS 中对 WebX 的依赖去除，并基于 Spring Boot 2.0 进行了重新适配，代码已经合并到主干；接下来还会将原先 Dubbo Admin 以及 Dubbo Monitor 进行合并，同时会适配更多的注册中心 Registry；另外我们在社区发起了关于全新 Logo 及官网的讨论，目的是想通过全新官网的建设，更好的将文档、博客、活动等信息呈现给社区和开发者，新的官网在设计开发中，接下来会上线，请大家保持关注。

最后总结一下，Dubbo 重启开源的这几个月总的来说是成功的，背后主要有两点原因，一是公司层面的支持，其中有工程师团队的努力，也有宣传运营上的投入；二是依托Dubbo 的群众基础，我们这几个月的工作重新赢得了社区的信任，大家也开始关注 Dubbo 的发展。下面我会从核心和生态两部分谈下 Dubbo 未来规划的 思考。

未来规划
首先聊下规划的 整体思路。Dubbo 后续的规划主要是要 解决好两个问题。第一个问题是未来出现的技术趋势哪些是和 Dubbo 紧密相关的，如果 Dubbo 不跟随，就有可能在未来被淘汰的问题，第二个问题是 Dubbo 本身定位的问题，也就是只做框架够不够的问题。

关于第一个问题，我们看到的是越来越多的应用从单体架构转向微服务架构，微服务的理念也深入人心，还有就是各大云厂商开始宣传云原生的概念，一些应用也开始向云上迁移，我们认为 微服务 和 云原生 这两个技术趋势上值得 Dubbo 关注的。

第二个问题 Dubbo 自身的定位，Dubbo 核心要保持技术上的领先性，我们会重点关注性能、大流量、大规模集群领域的挑战，但是光有这样是远远不够的，在保持核心演进的同时，我们还需要围绕 Dubbo 核心发展生态，将 Dubbo 做成一个服务化改造的整体方案。

Dubbo 核心的规划又 分为三块，第一块包括模块化和元数据，通过这两块的优化来解决适应未来技术方向的问题，也就是微服务和云原生，具体来说，目前 Dubbo 服务治理与网络传输耦合严重，通过进一步的模块化工作可以为 Dubbo 成为服务网格中的数据面板做好准备，元数据目前既包含服务注册信息，也包含服务配置信息，将两者分离可以更清晰的分开注册层和配置层，为适配微服务的注册中心和配置中心 打好基础。第二块是关于我们如何把阿里在服务治理方面的经验回馈给社区，其中包括了这里的路由策略、大流量和大规模，在路由策略中我们打算引入多机房路由、参数路由、灰度路由等策略，在大流量方面 重点考虑 熔断、限流、隔离的支持，在大规模集群方面需要解决超大规模地址列表对 CPU、内存带来的压力，最后一块是进一步的增强异步化，包括对 CompletableFuture 的支持以及跨进程 Reactive Stream 的预研，目前 Reactive Stream 在内部 Dubbo 3.0 中正在孵化，压测表明这项技术对于提升 CPU 利用率和系统的吞吐率很有帮助。

回想一下刚才的架构图，除了上面的两层，下面的七层都是可扩展的。Dubbo 生态的建设我们的思路是利用核心的扩展能力尽可能多的提供开箱即用的扩展实现。这里我们按照架构图中的层次划分归纳了每一层可能提供的扩展实现。其中蓝黑色的代表 Dubbo 框架已经支持的，绿色部分代表这次重启开源之后新加入以及正在进行中的，而橙色的部分代表我们计划在未来加入的。从下往上，我们看下未来会加入的支持，我们在序列化层计划加入对 Protobuf 的支持，在 Transport 层加入对 Http2 的支持，在 Protocol 层加入对 gRPC 的支持，在 Cluster、Router、Load Balance 代表的服务治理层计划加入阿里对服务治理方面的实践，其中包括了熔断、多机房路由、灰度路由，以及更丰富的负载均衡策略。再往上通过元数据的优化，我们可以更清晰的分开注册层和配置层，从而可以在注册层加入更多的对微服务注册中心的支持，比如 Eureka，Consul，在配置层也可以开始支持配置的动态推送，当然在这两层我们也会提供对阿里体系中的注册中心 Config Server、配置中心 Diamond 的支持，这两个产品就是后续郭平老师给大家分享的 Nacos。最顶上是对 API 的支持，我们会做对 Spring Cloud 的适配。

我们有了不断向前演进的核心，丰富的扩展生态，我们还需要解决 Dubbo 服务与外界互通的问题。这里的互通有两方面的含义。第一是 Dubbo 服务与外围系统互通，第二是异构系统如何调用 Dubbo 服务的问题。首先说下外围系统对接的问题，外围系统也分为两类，图中草绿色部分包括了 Dubbo OPS、Test Server、Mock Server、 Swagger Server，无非就是解决服务如何查询，服务治理规则如何配置，如何测试服务，开发阶段如何解决上下游依赖，服务的 API 支持等问题，这些问题与 Dubbo 服务紧密相关，我们计划自己来提供这方面的支持。再看图中橙色的部分，包括了服务注册中心、配置中心、鉴权中心，链路追踪和监控中心，这些系统外面有很多开源和商业的选择，我们的思路是尽可能多的提供与他们的适配，为用户带来开箱急用的体验。值得一提的是，这一块的建设是双向的，目前 Spring Cloud Sleuth 主动支持了 Dubbo。谈到异构系统如何调用 Dubbo 服务，本质上是多语言支持的问题。要解决多语言调用，无非有两种做法，一种是通过代理方式来调用，代理根据部署形式的不同又分为中心化的 API Gateway 方式，和本地部署的 Sidecar 方式，Sidecar 方式我们在下张片子里进一步讨论，对于 API Gateway 方式，只需要 Dubbo 服务可以按照 Json-RPC 或者 REST 的方式暴露服务就好。另一种调用方式就是原生语言客户端，要支持的语言包括了常用的 Python，Node，Php，Go 等等，这一块的挑战和工作量都很大，我们的思路是和社区共建。目前千米网的同学已经开始把他们的 Node 和 Python 的客户端贡献给社区。Go 和 Php 的版本也会很快提供。

规划的最后部分我想聊聊 Dubbo Mesh，刚才谈到互通问题的时候，解决多语言调用的一种方式是通过 Sidecar，谈到 Sidecar 就不得不从云原生讲起。目前各大云计算厂商开始定义云原生，鼓励用户将应用往云上迁移。云原生的定义每家都不太一样，但是其中可以看到有这么两个趋势。一个是云计算场景里多语言支持是强诉求，基于单一语言的架构和方案会有很大的局限性；另一个是原来与应用共生的服务治理能力开始从应用中解耦出来，并下沉为平台的基础能力，这样做的好处是应用开发更简单、应用更轻、多语言支持也变得容易，服务治理能力可以透明升级。这一块就是 Linkerd 率先提出的服务网格的概念。Dubbo 通过进一步的模块化工作，可以把服务治理能力多带带剥离出来独立部署，成为服务网格中的数据面版，我们称之为 Dubbo Mesh，它负责接管由本地所有 RPC 流量，并负责与外围的注册中心、配置中心对接。在服务网格下，一次 RPC 调用就会变成，左边草绿色的 Dubbo RPC 发起一次调用，请求会发给和他部署在一起的 Dubbo Mesh，Dubbo Mesh 又会把这个 RPC 请求转发到对端的 Dubbo Mesh，对端的 Dubbo Mesh 又会将收到的请求发给和他部署在一起的 Dubbo RPC, 也就是图中右边的橙色部分。服务网格上我们非常关注的一个方向，目前我们正在做技术选型，相信很快就会有大家见面。

最后总结一下，通过核心、扩展、互通三方面的建设，我们相信 Dubbo 体系可以成为服务化改造的国内首选方案，并且能够很好的适应微服务和云原生这两个技术趋势。

原文链接