springcloud 与 dubbo 比较

做者：潜龙勿用
连接：https://www.zhihu.com/question/45413135/answer/242224410
来源：知乎
著做权归做者全部。商业转载请联系做者得到受权，非商业转载请注明出处。

有关微服务架构的讨论最近一直很火。近期也看到一些分享Spring Cloud的相关实施经验，这对于最近正在整理Spring Cloud相关套件内容与实例应用的我而言，仍是有很多激励的。目前，Spring Cloud在国内的知名度并不高，与一些互联网公司的架构师、技术VP或者CTO在交流时，有些甚至还不知道该项目的存在。这也许与国内的开源服务治理框架Dubbo有必定的关系，除了Dubbo自己较为完善的中文文档以外，很多科技公司的架构师均出自阿里系，因此就目前状况看，短时间国内仍是Dubbo的天下。

那么第一次实施微服务架构时，咱们应该选择哪一个基础框架更好呢？我我的有一些观点，若有不妥，还请包涵。

1背景

Dubbo，是阿里巴巴服务化治理的核心框架，并被普遍应用于阿里巴巴集团的各成员站点。阿里巴巴近几年对开源社区的贡献不论在国内仍是国外都是引人注目的，好比：JStorm捐赠给Apache并加入Apache基金会等，为中国互联网人争足了面子，使得阿里巴巴在国人眼里已经从电商升级为一家科技公司了。

Spring Cloud，从命名咱们就能够知道，它是Spring Source的产物，Spring社区的强大背书能够说是Java企业界最有影响力的组织了，除了Spring Source以外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件是Spring Cloud的核心。

小结：若是拿Dubbo与Netflix套件作对比，前者在国内影响力较大，后者在国外影响力较大，可是若要与Spring Cloud作对比，因为Spring Source的加入，在背书上，Spring Cloud略胜一筹。不过，英雄不问出处，在背景这一点上，不能做为选择框架的主要因素，当您束手无策的时候，能够做为参考依据。

2社区活跃度

咱们选择一个开源框架，社区的活跃度是咱们极为关注的一个要点。社区越活跃，解决问题的速度越快，框架也会愈来愈完善，否则当咱们碰到问题，就不得不本身解决。而对于团队来讲，也就意味着咱们不得不本身去维护框架的源码，这对于团队来讲也将会是一个很大的负担。

小结：在社区活跃度上，Spring Cloud毋庸置疑的优于Dubbo，这对于没有大量精力与财力维护这部分开源内容的团队来讲，Spring Cloud会是更优的选择。

 

 

3架构完整度

或许不少人会说Spring Cloud和Dubbo的对比有点不公平，Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，必定程度来讲，Dubbo只是Spring Cloud Netflix中的一个子集。可是在选择框架上，方案完整度偏偏是一个须要重点关注的内容。

根据Martin Fowler对 微服务架构 的描述中，虽然该架构相较于单体架构有模块化解耦、可独立部署、技术多样性等诸多优势，可是因为分布式环境下解耦，也带出了很多测试与运维复杂度。

根据微服务架构在各方面的要素，看看Spring Cloud和Dubbo都提供了哪些支持。

 

Dubbo Spring Cloud

服务注册中心 Zookeeper Spring Cloud Netflix Eureka

服务调用方式 RPC REST API

服务网关 无 Spring Cloud Netflix Zuul

断路器 不完善 Spring Cloud Netflix Hystrix

分布式配置 无 Spring Cloud Config

服务跟踪 无 Spring Cloud Sleuth

消息总线 无 Spring Cloud Bus

数据流 无 Spring Cloud Stream

批量任务 无 Spring Cloud Task

…… …… ……

以上列举了一些核心部件，大体能够理解为何以前说Dubbo只是相似Netflix的一个子集了吧。固然这里须要申明一点，Dubbo对于上表中总结为“无”的组件不表明不能实现，而只是Dubbo框架自身不提供，须要另外整合以实现对应的功能，好比：

分布式配置：可使用淘宝的diamond、百度的disconf来实现分布式配置管理。可是Spring Cloud中的Config组件除了提供配置管理以外，因为其存储可使用git，所以它自然的实现了配置内容的版本管理，能够完美的与应用版本管理整合起来。

服务跟踪：可使用京东开源的Hydra

批量任务：可使用当当开源的Elastic-Job

……

虽然，Dubbo自身只是实现了服务治理的基础，其余为保证集群安全、可维护、可测试等特性方面都没有很好的实现，可是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。

 

RPC vs REST

 

另外，因为Dubbo是基础框架，其实现的内容对于咱们实施微服务架构是否合理，也须要咱们根据自身需求去考虑是否要修改，好比Dubbo的服务调用是经过RPC实现的，可是若是仔细拜读过Martin Fowler的 microservices 一文，其定义的服务间通讯是HTTP协议的REST API。那么这两种有何区别呢？

先来讲说，使用Dubbo的RPC来实现服务间调用的一些痛点：

服务提供方与调用方接口依赖方式太强：咱们为每一个微服务定义了各自的service抽象接口，并经过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，所以不论开发、测试、集成环境都须要严格的管理版本依赖，才不会出现服务方与调用方的不一致致使应用没法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，每每一个依赖不少服务的上层应用，天天都要更新不少代码并install以后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，固然REST接口也有痛点，由于接口定义太轻，很容易致使定义文档与实际实现不一致致使服务集成时的问题，可是该问题很好解决，只须要经过每一个服务整合swagger，让每一个服务的代码与文档一体化，就能解决。因此在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。

服务对平台敏感，难以简单复用：一般咱们在提供对外服务时，都会以REST的方式提供出去，这样能够实现跨平台的特色，任何一个语言的调用方均可以根据接口定义来实现。那么在Dubbo中咱们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若咱们每一个服务自己就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。

相信这些痛点也是为何当当网在dubbox（基于Dubbo的开源扩展）中增长了对REST支持的缘由之一。

小结：Dubbo实现了服务治理的基础，可是要完成一个完备的微服务架构，还须要在各环节去扩展和完善以保证集群的健康，以减轻开发、测试以及运维各个环节上增长出来的压力，这样才能让各环节人员真正的专一于业务逻辑。而Spring Cloud依然发扬了Spring Source整合一切的做风，以标准化的姿态将一些微服务架构的成熟产品与框架揉为一体，并继承了Spring Boot简单配置、快速开发、轻松部署的特色，让本来复杂的架构工做变得相对容易上手一些（若是您读过我以前关于Spring Cloud的一些核心组件使用的文章，应该能体会这些让人兴奋而激动的特性，传送门）。因此，若是选择Dubbo请务必在各个环节作好整套解决方案的准备，否则极可能随着服务数量的增加，整个团队都将疲于应付各类架构上不足引发的困难。而若是选择Spring Cloud，相对来讲每一个环节都已经有了对应的组件支持，可能有些也不必定能知足你全部的需求，可是其活跃的社区与高速的迭代进度也会是你能够依靠的强大后盾。

 

4文档质量

Dubbo的 文档 能够说在国内开源框架中算是一流的，很是全，而且讲解的也很是深刻，因为版本已经稳定再也不更新，因此也不太会出现不一致的状况，另外提供了中文与英文两种版本，对于国内开发者来讲，阅读起来更加容易上手，这也是dubbo在国内更火一些的缘由吧。

Spring Cloud因为整合了大量组件，文档在体量上天然要比dubbo多不少，文档内容上还算简洁清楚，可是更多的是偏向整合，更深刻的使用方法仍是须要查看其整合组件的详细文档。另外因为Spring Cloud基于Spring Boot，不少例子相较于传统Spring应用要简单不少（由于自动化配置，不少内容都成了约定的默认配置），这对于刚接触的开发者可能会有些不适应，比较建议了解和学习Spring Boot以后再使用Spring Cloud，否则可能会出现不少只知其一;不知其二的状况。

小结：虽然Spring Cloud的文档量大，可是若是使用Dubbo去整合其余第三方组件，实际也是要去阅读大量第三方组件文档的，因此在文档量上，我以为区别不大。对于文档质量，因为Spring Cloud的迭代很快，不免会出现不一致的状况，因此在质量上我认为Dubbo更好一些。而对于文档语言上，Dubbo天然对国内开发团队来讲更有优点。

 

总结

经过上面再几个环节上的分析，相信你们对Dubbo和Spring Cloud有了一个初步的了解。就我我的对这两个框架的使用经验和理解，打个不恰当的比喻：使用Dubbo构建的微服务架构就像组装电脑，各环节咱们的选择自由度很高，可是最终结果颇有可能由于一条内存质量不行就点不亮了，老是让人不怎么放心，可是若是你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，作了大量的兼容性测试，保证了机器拥有更高的稳定性，可是若是要在使用非原装组件外的东西，就须要对其基础有足够的了解。