2016年，我在博客中发表过一篇《微服务架构的基础框架选择：Spring Cloud还是Dubbo？》（http://blog.didispace.com/microservice-framework/）获得了很大的阅读量和转载量。在这篇文章中，我主要对比了Spring Cloud与Dubbo所具备的能力，并阐述了个人推崇Spring Cloud的原因。但是，最近各大技术社区出现了不少类似的文章，观点比较激进，对于Spring Cloud的褒扬远胜于Dubbo，但是这些评价很多都忽略了Spring Cloud与Dubbo在设计视角上的不同。其实在前文中我也说明了Dubbo与Spring Cloud的对比本身就不公平，因为两者产出的目标格局是不一样的。所以，就目前阶段来说，大家对于框架的选择上，还是要综合考虑自身团队与遗留业务系统的特点来确定更合适的技术栈，而不是盲从于“时髦”的架构体系。

昨天看到了开源中国对Dubbo社区维护者的访谈，内容非常不错。所以这里分享给大家。其实，在最近一年多的时间里，结合实际的生产实践，我也有了更多的理解与感悟。或许在后面的一段时间里，以博文或GitChat的方式与大家分享一下我对Dubbo与Spring Cloud的“爱恨情仇”！

以下内容经授权转载自公众号“开源中国”

曾风靡国内的开源 RPC 服务框架 Dubbo 在重启维护后，令许多用户为之雀跃，但同时，也迎来了一些质疑的声音。互联网技术发展迅速，Dubbo 是否还能跟上时代？Dubbo 与 Spring Cloud 相比又有何优势和差异？是否会有相关举措保证 Dubbo 的后续更新频率？带着这些疑问，本期开源访谈邀请到了主导 Dubbo 重启维护开发的刘军，解答大家最想了解的相关问题。

【本期嘉宾】

刘军，阿里巴巴中间件高级研发工程师，主导了 Dubbo 重启维护以后的几个发版计划，专注于高性能 RPC 框架和微服务相关领域。曾负责网易考拉 RPC 框架的研发及指导在内部使用，参与了服务治理平台、分布式跟踪系统、分布式一致性框架等从无到有的设计与开发过程。

【访谈内容】

1、为什么会在三年后重新维护 Dubbo ？

对于这个问题社区的用户比较关心，我们在之前的一些渠道也专门做了解答，我在此引用如下：

Dubbo 自 2011 年开源以來，深受国内友商和开源爱好者的青睐，虽然一直陆续在维护，但是由于 Dubbo 用户群体庞大，日常维护根本无法完全满足社区的旺盛需求。随着集团内部技术水平的迅速发展，如今不仅能够保证集团及客户的系统高效运行，还能抽调更多精力将技术赋能给全社会。

开源就是阿里巴巴集团在技术层面赋能的重要领域。阿里巴巴中间件团队今后不仅要聆听社区的声音，及时修复问题，及时合并优秀的 pull request，还会力争将 Dubbo 打造成有国际影响力的 RPC 框架。

从集团层面看，阿里为国内甚至国际开源社区贡献了大量优秀开源项目，如大家熟知的 RocketMQ、JStorm、Fastjson、Dubbo、Weex 等。在今年的云栖大会上，阿里集团公开宣布了将加大技术投入、拥抱开源的发展策略。正是由于以上几个原因，阿里巴巴中间件团队决定Dubbo的下一步计划是持续发展，并走向国际化。

2、Dubbo 在停更后还能一直受到喜爱和广泛使用的原因是什么？其优势在哪？

Dubbo 自开源以后，被国内很多互联网公司用作服务化基础框架，经历了在阿里内部及很多大型互联网公司长时间生产环境实践，已经被证明是一个高度可靠、经受得住大规模流量考验的服务治理框架，这些成功的实践案例，在服务化框架选型时能给予架构师足够的信心与经验。

另外，相比很多开源 RPC 框架，Dubbo 在服务治理功能集上可谓非常完善：不仅提供了服务注册发现、负载均衡及路由等面向分布式集群的基础能力，还设计了面向开发测试阶段的 mock、泛化调用等机制，同时也提供了服务治理、监控的可视化平台。

Dubbo 是一个高度可扩展的框架，几乎所有核心功能都被设计为一个扩展点，因此从用户的角度，即使之前在 Dubbo 的官方社区支持不足的情况下，使用者仍可以很容易的对 Dubbo 进行裁剪或扩展以满足组织内部的需求。

3、互联网技术发展迅速，云、容器等技术的快速应用，是否已经让 Dubbo 存在掉队倾向？后续要如何解决？

首先从 RPC 的角度来说，RPC 是一个相对成熟的方向，Dubbo 在协议、网络通信等层面的设计已经保证了稳定性与高性能，在这个层面 Dubbo 已经做得非常好了；而从服务治理的角度，Dubbo 已经对很多集群场景下的服务治理特性提供了支持，同时随着近两年微服务架构的流行，Dubbo 在某些功能上确实需要加强：比如社区关心的熔断功能，Dubbo 虽有容错支持但却还没有融入熔断的理念。我们计划在接下来的几个版本中会重点对这些缺失的功能逐步增强。

Dubbo 本身的定位只是一个 RPC 框架，基于 Dubbo 开发的应用还是要依赖周边的平台与生态，所以 Dubbo 自然要去积极的适配周边生态的发展趋势。比如你提到的以容器技术为代表的 Cloud Native 生态，这个确实是 Dubbo 要去积极跟进的方向，Dubbo 也已经在行动，比如近期的版本中支持了 Docker 容器等隔离网络环境的部署，同时对 OpenTracing、Spring Boot 的支持也在进行中，而对于底层调度平台及周边生态的变化，我们也在积极关注，总之 Dubbo 会积极的融入到这些健康发展的生态中去，以支持基于 Dubbo 开发的系统可以更顺畅的走向云化。

4、是否会有相关举措保证 Dubbo 的后续更新频率以解决用户的担忧？

Dubbo 自 2017 年 8 月份重启维护以来，已经连续发布了 5 个版本，基本维持了每月一个版本的发版节奏，而发版内容上以优先解决社区呼声较高的需求为主。2.5.8 版本开始，之前社区累积报告的 bug 基本都已得到了修复，另外还对 netty4 的支持、annotation 的增强、java 8 的支持、docker 的支持等进行了增强。Dubbo 做出的一系列改进，让社区再次沸腾起来。

接下来，我们将继续投入一定的精力关注社区的使用反馈与需求，建立更完善的发版机制，做到影响版本稳定性的 bug 随时修复，用户关心的功能及时在 feature 版本予以支持。当前已经在我们规划中的，近期将会提供支持的功能点包括：spring boot 的集成、RESTful、优雅部署、容错增强、路由策略增强以及异步化增强等。

5、Dubbo 和 HSF 都是阿里自研的 RPC 服务框架，Dubbo 后续是否会吸取 HSF 上的一些特性以满足业务拓展需求？

当然，我们会考虑在合适的时机，陆续的将阿里在 HSF 框架以及在大规模服务化场景下的服务治理经验通过 Dubbo 输出到社区。HSF 本身完全兼容 Dubbo ，和阿里内部的很多系统结合比较紧密并且做了一些定制化的工作，这使得 HSF 更适合于阿里内部的超大规模集群场景，相信 HSF 在超大规模连接管理、智能路由、服务管控等方面的经验能帮助到 Dubbo 社区的用户。

值得一提的是，当前维护 Dubbo 的团队成员很多也同时参与 HSF 的维护，除此之外，还有一些来自阿里中间件其他团队的同学参与进来，这样更利于形成良性循环，做到真正意义上的内外统一。

6、目前 Dubbo 被拿来比较最多的就是 Spring Cloud ，您怎么看待二者的关系，业务上是否有所冲突？

关于 Dubbo 和 Spring Cloud 间的关系，我们在开源中国年终盛典的 Dubbo 分享中也作了简单阐述，首先要明确的一点是 Dubbo 和 Spring Cloud 并不是完全的竞争关系，两者所解决的问题域并不一样：Dubbo 的定位始终是一款 RPC 框架，而 Spring Cloud 的目标是微服务架构下的一站式解决方案。如果非要比较的话，我觉得 Dubbo 可以类比到 Netflix OSS 技术栈，而 Spring Cloud 集成了 Netflix OSS 作为分布式服务治理解决方案，但除此之外 Spring Cloud 还提供了包括 config、stream、security、sleuth 等等分布式问题解决方案。

当前由于 RPC 协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时 Dubbo 与 Spring Cloud 是只能二选一，这也是为什么大家总是拿 Dubbo 和 Spring Cloud 做对比的原因之一。Dubbo 之后会积极寻求适配到 Spring Cloud 生态，比如作为 Spring Cloud 的二进制通信方案来发挥 Dubbo 的性能优势，或者 Dubbo 通过模块化以及对 http 的支持适配到 Spring Cloud 。

7、现阶段的服务治理框架（方案）是否存在瓶颈，如何看待其后续发展方向？

首先，我想结合时下流行的容器调度平台简单说一下，以 kubernetes 为例，它不仅提供了容器的部署、调度等生命周期管理能力，还抽象出了服务的概念，能实现服务地址的动态注册发现、负载均衡、health check、动态配置等，可以说服务治理的能力在往底层平台层面下沉，而类似 Dubbo 的服务治理框架本身可以变得更轻量。

另一个方面，跨多语言的服务治理一直是开源服务治理框架面临的问题。有些 RPC 框架提供了完善跨语言的通信支持，但是服务治理能力有限，如 gRPC、thrift 等；而有丰富服务治理功能的框架往往局限于某一个特定的开发语言，如 Netflix、Dubbo 仅限定于 java 。最近兴起的 Service Mesh 方案看似是未来解决跨语言问题的完美方案，它接管了所有的网络流量，因此能实现流量调度和管控相关的功能。更进一步，类似 istio、conduit 等框架又与底层调度平台的服务注册发现等能力进行对接，同时也对微服务周边解决方案的适配提供了统一抽象，RPC 通信和服务治理能力不再耦合在一起，业务应用只需要面向基础的 RPC 通信框架编程。

从 Dubbo 自身来说，未来主要会着重向 Cloud Native 、多语言增强、微服务支持等几个方向演进，同时不断建设生态系统、社区、以及国际影响力。

【福利】赠书活动仍在继续中

《大话代码架构》

推荐阅读

Spring Cloud微服务架构汇总

浅谈微服务基建的逻辑

Service Mesh：下一代微服务

微服务（Microservices）【翻译】

那些没说出口的研发之痛，做与不做微服务的几大理由

谷歌大神为你解释Kubernetes, 微服务和容器化

长按指纹

一键关注

点击 “阅读原文” 看看本号其他精彩内容