Dubbo重启一年，尚能饭否？

点击上方“Java后端技术”，选择“置顶或者星标”

每天带你看高清大图哦！

来源：开源中国 | 嘉宾：北纬

本文来源：开源中国；嘉宾介绍：北纬，开源中国社区昵称：beiwei30，Apache Dubbo™ PPMC，阿里巴巴高级技术专家，专注于大规模分布式系统、RPC 框架和微服务领域。

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

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

期间还有 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 原生客户端最小功能集，以及成熟度评估标准，持续运营社区，吸引更多的多语言志愿者加入。

开源中国：

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

北纬：

说到这个，其实 Dubbo 最近才刚刚在开源中国发起的“最受欢迎中国开源软件评选”中取得了第三名（Java 类第一名）的好成绩，感谢开发者们对 Dubbo 的信任，也感谢开源中国发起的这项活动。

自重启维护以来，到 2.7.0 发布，Dubbo 已经累计发布了 13 个版本。在这个过程中从零开始搭建 Dubbo EcoSystem，目前生态初具规模：

• 逐步提供了 Node、Python、Go 和 PHP 语言客户端实现、开发工具及配套(Initializr、Benchmark、IDE plugin) 与 samples；

• 丰富了核心 SPI 的扩展实现，包括 Hessian、Avro、Protobuf、HTTP/2、Thrift、JMS、etcd3、Sentinel、Nacos、Apollo、K8S 与 Docker；

• 改造并重新实现了 Dubbo Ops；

• 孵化了 27 个子项目；

同时，不少微服务开源项目开始主动对接 Dubbo，包括 Zipkin、spring-cloud-slueth、SkyWalking、Pinpoint 和 Jboot 等。

社区方面，GitHub 上 star 数已经突破 2.3w，增长 150%，在 GitHub Java 项目中排名前十，目前已有 25 位 PPMC 和 committer、162 位 contributor (自重启开源以来增长了 250%），共举办了 5 场 meetup，现场参与人数 2300+，线上参与人数 35000+。

下边 star 的增长数据可以大致看出 Dubbo 的成长：

目前 Dubbo 正在 Apache 软件基金会进行孵化，预计在未来的几个月将毕业成为顶级项目。

当然，这些并不是炫耀 Dubbo 重启开源后所取得的成绩，而是说在社区的共同努力下，Dubbo 正发挥着其更大的技术价值，让成千上万的开发者收益，这也是 Dubbo 团队成就感的最大来源。

我们除了感激社区的信赖之外，心中也充满了敬畏。因为 Dubbo 在国内的用户之多，已远超我们的想象。在“谁在使用 Dubbo”的调研中，目前已有 124 名用户提供了自己的使用场景，其中不乏著名的互联网公司和大型国企。我们相信这里收集的只是国内用户中的一小部分，只有更加努力，不断让 Dubbo 变得更好，才能不辜负使用者对 Dubbo 的信赖。

谁在使用 Dubbo：

https://github.com/apache/incubator-dubbo/issues/1012

过去这一年，团队的目标是重新激活社区和生态。通过线下开发者沙龙、开发者访谈、社区的 issues、pull request 以及邮件组的互动等方式来倾听社区的声音，同时，我们把 Dubbo 捐献给 Apache 进行孵化，积极发展外部的 committer 和 PPMC member，严格按照 Apache 之道来运作。通过这些努力，重新赢得了社区的信任。

接下来我们会更加关注核心能力的演进，2.7.0 版本是一个里程碑。这个版本准备了与微服务及云原生环境中基础设施对接的技术基础，未来，Dubbo 将会提供对应的适配，使得 Dubbo 可以更好地融入到微服务和云原生体系中去。

这里也顺便预告一下，近期我们 2019 年的第一场 meetup 也快来了，欢迎关注：

http://t.cn/Ebyekd6。

开源中国：

去年年初透露的 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 的分享：

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，希望通过这个生态帮助使用者更轻松、更快速地搭建微服务。

本文来源：

www.oschina.net/question/3820517_2302528

热门内容：