Dubbo 重启维护一年多，现在还活着吗？

Dubbo 去年宣布重启维护，到现在已经一年有余，当初重启的消息在开发者中引起了强烈的反响，很多人看好，也有人持怀疑的态度，甚至到今天，还是有不少人认为 Dubbo 早已死去，回不了魂。

质疑声中，Dubbo 将首要目标定位于重新激活社区，赢回开发者的信任。在这个过程中，Dubbo 发布了多个版本，并逐渐从一个 RPC 框架向微服务生态系统转变；团队 “把 Dubbo 打造成一个国际化与现代化项目”的探索目前来看也有所呼应，比如年初 Dubbo 入驻 Apache 软件基金会孵化器，比如它在特性中提供了更加全面的异步支持；而目前 GitHub 上的 star 数也已经有 2.3w+。

期间还有 Dubbo 3.0 的消息放出，3.0 将会是一个变革的版本，它去一切阻塞的变化甚至将影响到阿里 10 多年积累的中间件。

不难看出，目前 Dubbo 还活着。近期 Dubbo 将发布重启后的第一个里程碑版本 2.7.0，而且还预告了项目即将从 Apache 软件基金会毕业，借此机会，我们采访了 Dubbo 的项目负责人北纬，请他为开发者梳理了重启维护这一年多 Dubbo 的进展，并分享了接下来的计划。

开源中国：2.7.0 新版本最值得关注的地方在哪里?

北纬：Dubbo 2.7.0 添加了社区呼声很高的 异步化支持 、以及 注册中心与配置中心分离 这两个特性。

与 2.6 及以前的版本相比， 异步化支持 不再局限于基于 Future 接口的异步，也不再仅仅局限于只能在客户端异步。具体来说，Dubbo 2.7.0 版本全面拥抱 JDK8，在客户端开始支持基于 CompletableFuture 的异步编程范式，在服务端支持基于 AsyncContext 的异步模型。

2.6 及以前的版本，元数据全部存储在 URL 上，配置信息和注册信息只能存储在注册中心上，注册中心的容量和扩展成为瓶颈。这个限制在使用 ZooKeeper 作为注册中心的大规模 Dubbo 应用场景下尤为突出。

在 2.7.0 中，通过对 URL 的改造，将 注册中心拆分成了三个中心 ，分别是注册中心、配置中心和元数据中心，三者各司其责，不仅有效地解决了上述容量问题，而且很好地适应了微服务的技术架构，用户可以开始自由选择适合自己场景的注册中心和配置中心。

2.7.0 将内建支持 ZooKeeper、Nacos 和 Apollo 等第三方注册和配置中心，在后续的版本中，还会进一步提供对 Consul 和 etcd 的支持。另外，通过引入一个全新的元数据中心，将与注册配置无关的服务信息单独存储，除了减轻配置中心与注册中心的工作压力之外，还为将来 更丰富的服务治理 打下基础。未来，Dubbo 会基于元数据中心提供服务测试、服务 Mock 以及服务 API 管理等特性。

针对三个中心的分离，Dubbo 还会配套发布全新设计的 Dubbo Ops 控制台 。

另外，2.7.x 会是 Dubbo 在 Apache 软件基金会 毕业的版本 ，安装包包名正式切换到了 org.apache.dubbo，为了保证向前的兼容性，我们还在这个版本中提供了 com.alibaba.dubbo 的兼容包。

开源中国：多语言支持现在看只有一个 PHP 版本对齐得比较完善，Python 和 Node 版本是提供了一个客户端去配合实现功能。在语言支持这方面，现在进展是怎么样，有什么计划？

北纬：除了 PHP 版本对齐得比较好以外，Node 版本也值得推荐。目前生态中的 Node 实现有两个版本，分别是 千米网贡献的 dubbo2.js 和 蚂蚁金服 egg 团队贡献的 egg-dubbo-rpc 。这些语言的实现都是在生产系统里验证过的，其中 egg 的实现既支持客户端也支持服务端。

除了 PHP 和 Node，Dubbo 还提供了 Go 和 Python 支持。其中 Python 版本支持客户端与服务端互通，走的是 json-rpc 协议，Go 版本将支持原生 Dubbo 协议，并计划同时提供客户端和服务端。

需要强调的是，除了多语言客户端的支持，Dubbo 基于标准的 Java REST API——JAX-RS 2.0 实现了 REST 调用支持，具体的使用方法可以参照这里：

http://dubbo.apache.org/zh-cn/docs/user/references/protocol/rest.html

总的来说，相比于服务端， 客户端是 Dubbo 多语言支持的重点 。从实用的角度来讲，社区大量的诉求集中在如何用多语言调用后台的 Dubbo 服务。当然，目前多语言的支持还处于起步阶段，一方面是主流语言覆盖不够，比如 .NET 还没有可用版本，另一方面是因为各个语言的成熟度参差不齐，社区投入不够。

虽然 Service Mesh 的方案在这两年发展得如火如荼，但我们也发现原生多语言客户端在大量的场景中还会持续存在很长的时间，因此我们十分重视原生多语言客户端的建设。后面总体的思路是 定义 Dubbo 原生客户端最小功能集 ，以及成熟度评估标准，持续运营社区，吸引更多的多语言志愿者加入。

开源中国：重启维护这一年来主要的工作是关于哪些方面的？实质进展如何？

开源中国：去年年初透露的 3.0 目前是个什么情况？当初甚至说 3.0 去一切阻塞的变化将影响到阿里 10 年来积累的中间件，那现在具体情况如何？（2.7 中提到的实现全异步编程跟这个去阻塞有什么不同？）另一方面，3.0 中的 Service Mesh 建设现在如何了？其它方面呢？

北纬：过去一年多工作的重心是激活社区和生态。目前，我们已经开始把工作的 重心逐步转向核心建设 ，目标就是提供现代化的技术核心，解决好微服务、容器化与云原生等问题。已经发布的  2.7.0 是第一个里程碑，3.0 同步进入开发阶段 。

这里要指出的是，3.0 中规划的去阻塞和 2.7 中提供的异步是 两个层面的特性 。2.7 中的异步是建立在传统 RPC 中 request – response 会话模型上的，而 3.0 中的异步将会从 通讯协议层面由下向上构建 ，关注的是跨进程、全链路的异步问题。

通过底层协议开始支持 streaming 方式，不单单可以支持多种会话模型，还可以在协议层面开始支持反压、限流等特性，使得整个分布式体系更具有弹性。所以，2.7 关注的异步更局限在点对点的异步（一个 consumer 调用一个 provider），而 3.0 关注的异步化，宽度上则关注整个调用链上的异步，高度上则向上又可以包装成 Rx 的编程模型。

有趣的是，Spring 5.0 发布了对 Flux 的支持，随后开始解决跨进程的异步问题，有兴趣的开发者可以关注一下目前 RSocket 的发展情况。

3.0 中受到关注的还有 Dubbo Mesh 的发展。我们希望 Dubbo Mesh 未来可以 进入 Envoy 社区 ，目前 Dubbo 协议已经被 Envoy 支持。当然，Dubbo Mesh 离真正可用还有很长一段距离，其在选址、负载均衡和服务治理方面的工作需要继续在数据面建设，另外，控制面板的建设在社区也没有提上日程。

最后值得一提的是，Dubbo 3.0 定下了 内外融合的策略 ，也就是说 3.0 的核心最终会在阿里巴巴的生产系统中部署，相信通过大流量、大规模的考验，Dubbo 用户可以获得一个性能、稳定、服务治理实践各方面俱佳的核心，用户在生产系统中采用 3.0 也会更加放心。

开源中国：接下来 Dubbo 将会从 Apache 孵化器毕业，除了有个名誉，具体对项目之后的维护、发展有什么影响？

北纬：Apache 孵化器主席 Justin Mclean 每次来中国都会分享什么是“ Apache 之道 ”，它提倡公益使命、实用主义、社区胜于代码、公开透明与共识政策和任人唯贤，具体可以参照这篇 Apache 孵化器主席 Justin Mclean 的分享：

https://mp.weixin.qq.com/s/ULea2-uDEG5HRbRewuZjIg

Dubbo 进入 Apache 进行孵化，目的就是遵循 Apache 之道来规范化地发展 Dubbo。同时，通过孵化，Dubbo 团队的所有成员，对于如何运营好一个开源项目，建设好一个开源社区有了更深的体验，也就是说，孵化过程就是 Dubbo 团队自我学习和进阶的过程。

从孵化器毕业是一种荣誉，但这并不是结束，而是另一种开始。这有点像求学，毕业并不意味着学习上的中断，而是发挥更大社会价值的开始。毕业也更像是一个成人礼，意味着 Dubbo 团队已经符合 Apache 对一个成熟开源项目的要求，并开始具备独立发展的能力。

Dubbo 自从加入 Apache 的那一天起，就不再属于阿里巴巴。Dubbo 变得更好，是因为已经有越来越多来自社区的开发者参与到 Dubbo 的共建中。例如，Dubbo 目前的 162 位 contributor 中，有接近 90% 都是来自非阿里巴巴的开发者，这个比例在未来应该会更高。

开源中国：最近 Netflix 官方表示不再继续开发 Hystrix，用户被迫迁移，前一阵子 Netflix 也同样宣布了 Eureka 2.0 不再维护。而实际上，Spring 官方近期也表明 Netflix 相关项目进入维护模式（Maintenance Mode），即 Spring Cloud 团队不会再向 Netflix 模块添加新功能。这让开发者对 Netflix 产生质疑，有些人觉得 Spring Cloud 中的 Netflix 组件实现再用下去会不会有什么风险，不少开发者表示要另寻高明。而此时阿里正在建设的 Dubbo EcoSystem 与开源不久的 Spring Cloud Alibaba 正好进入大家的视野。但是开发者也在观望，不知道 Dubbo EcoSystem 与 Spring Cloud Alibaba 是否可以及时地接过大旗。

北纬：正如大家所看到的，今年发生在 Netflix 上的事情，对 Spring 生态产生了不小的影响，但作为开发者我们应该感谢 Netflix 在过去以及现在正在做的对开源的贡献。

做开源的技术人都有一种技术情怀，但仅凭情怀，很难将开源坚持下去，最终还是要回归到技术和商业的本质关系，即技术可以推动商业发展，但也需要商业来赋能技术前行。如果一家企业的战略主航道上，技术并不是其发展方向之一，那么其开源项目要维持下去的难度就很大。因此，在开源领域，我更看好技术服务型的企业，即对外输出技术和相关服务是企业的主营业务之一。

阿里巴巴在服务化改造和微服务领域实践多年，几乎涵盖了微服务技术栈的所有产品和组件，例如 Spring Cloud Alibaba 满足了在 Spring Cloud 体系中使用阿里巴巴技术栈的需求，Nacos 提供了注册中心和配置中心方面的功能，Sentinel 则解决了因高流量等访问行为带来的架构可靠性的问题。另外，作为已经成为 Apache 顶级项目的 RocketMQ，近期发布的首个社区子项目 RocketMQ-Spring-Boot，实现了 Spring 体系中通过 RocketMQ 进行分布式事务的回查和事务消息的发送。

其实，在微服务开发的领域，除了 RPC 和服务注册发现，开发者还需要更多的能力，例如 API 网关、分布式监控和分布式事务等，在这些方面由于没有事实上推荐的方案，开发者在调研和选型的过程通常都比较痛苦，甚至会遇到个别开源项目不再继续维护的窘境。

如何 通过 Dubbo 把这些微服务领域的其它能力整合起来，形成一套完整的解决方案 ，成为一个亟待解决的问题。

像前边提到的，我们计划并已经着手围绕 Dubbo 打造一个 微服务生态 ，它包含一系列开源项目，涵盖微服务开发中的各个方面。这里面的项目都是经过 Dubbo 社区共同评估过，和 Dubbo 进行了高度集成的，在生产中得到过验证的项目，且具有兼容性保障。这些项目不仅来自阿里巴巴自己的开源项目，也来自其它公司或社区。我们把它称之为 Apache Dubbo EcoSystem，希望通过这个生态帮助使用者更轻松、更快速地搭建微服务。

嘉宾介绍

北纬，社区昵称 beiwei30，Apache Dubbo™ PPMC，阿里巴巴高级技术专家，专注于大规模分布式系统、RPC 框架和微服务领域。

转自 https://www.oschina.net/question/3820517_2302528