Spring Cloud，Dubbo及HSF对比

Round 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略胜一筹。不过，英雄不问出处，在背景这一点上，不能做为选择框架的主要因素，当您束手无策的时候，能够做为参考依据。

Round 2：社区活跃度

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

下面看看这两个项目在github上的更新时间，下面截图自2016年7月30日：

• Dubbo ： https://github.com/dubbo

最后更新时间为：2016年5月6日

• Spring Cloud ： https://github.com/spring-cloud

最后更新时间为：12分钟前

能够看到Dubbo的更新已是几个月前，而且更新频率很低。而Spring Cloud的更新是12分钟前，仍处于高速迭代的阶段。

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

Round 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，相对来讲每一个环节都已经有了对应的组件支持，可能有些也不必定能知足你全部的需求，可是其活跃的社区与高速的迭代进度也会是你能够依靠的强大后盾。

Round 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的整合下，作了大量的兼容性测试，保证了机器拥有更高的稳定性，可是若是要在使用非原装组件外的东西，就须要对其基础有足够的了解。

从目前Spring Cloud的被关注度和活跃度上来看，颇有可能未来会成为微服务架构的标准框架。因此，Spring Cloud的系列文章，我会继续写下去。也欢迎各位朋友一块儿交流，共同进步。

 

HSF：

简介：HSF提供的是分布式服务开发框架，taobao内部使用较多，整体来讲其提供的功能及一些实现基础：
1.标准Service方式的RPC
  1）、Service定义：基于OSGI的Service定义方式
  2）、TCP/IP通讯：
   IO方式：nio,采用mina框架
   链接方式：长链接
   服务器端有限定大小的链接池
   WebService方式
  3）、序列化：Hessian序列化机制
2.软件负载体系
3.模块化、动态化
4.服务治理

性能：

Dubbo  &  HSF compare

Dubbo优势：

1.  Dubbo比HSF的部署方式更轻量，HSF要求使用指定的JBoss等容器，还须要在JBoss等容器中加入sar包扩展，对用户运行环境的侵入性大，若是你要运行在Weblogic或Websphere等其它容器上，须要自行扩展容器以兼容HSF的ClassLoader加载，而Dubbo没有任何要求，可运行在任何Java环境中。 
2.  Dubbo比HSF的扩展性更好，很方便二次开发，一个框架不可能覆盖全部需求，Dubbo始终保持平等对待第三方理念，即全部功能，均可以在不修改Dubbo原生代码的状况下，在外围扩展，包括Dubbo本身内置的功能，也和第三方同样，是经过扩展的方式实现的，而HSF若是你要加功能或替换某部分实现是很困难的，好比支付宝和淘宝用的就是不一样的HSF分支，由于加功能时改了核心代码，不得不拷一个分支单独发展，HSF现阶段就算开源出来，也很难复用，除非对架构重写。 
3.  HSF依赖比较多内部系统，好比配置中心，通知中心，监控中心，单点登陆等等，若是要开源还须要作不少剥离工做，而Dubbo为每一个系统的集成都留出了扩展点，并已梳理干清全部依赖，同时为开源社区提供了替代方案，用户能够直接使用。 
4.  Dubbo比HSF的功能更多，除了ClassLoader隔离，Dubbo基本上是HSF的超集，Dubbo也支持更多协议，更多注册中心的集成，以适应更多的网站架构。

Dubbo在安全机制方面是如何解决的？
Dubbo主要针对内部服务，对外的服务，阿里有开放平台来处理安全和流控，因此Dubbo在安全方面实现的功能较少，基本上只防君子不防小人，只防止误调用。 
Dubbo经过Token令牌防止用户绕过注册中心直连，而后在注册中心上管理受权。Dubbo还提供服务黑白名单，来控制服务所容许的调用方。

HSF优势：

1.HSF框架采用 Netty + Hession数据序列化协议实现服务交互，Netty + Hession的组合在互联网高并发量的场景下,特别是在TPS 上达到10w 以上时，性能和效率远比REST 或者Web Service 高。

2.HSF框架的容错机制，配置服务器是采用长链接的方式与服务节点进行网络通信，一旦发现有服务提供者实例出现故障，配置服务器在秒级就会感知到，此时会将出问题这台服务提供者的信息从该服务的服务器列表中删除，并将更新后的服务器列表采用推送的方式同步给与该服务相关的全部服务调用者端，这样当下次服务调用者再进行此服务的调用时，就不会由于随机的方式再次对已经中止服务提供的服务器发起服务的调用。

3.HSF框架的线性扩展支持

 

Spring cloud:

Spring Cloud为开发人员提供了快速构建分布式系统中的一些通用模式（例如配置管理，服务发现，断路器，智能路由，微代理，控制总线，一次性令牌，全局锁，领导选举，分布式 会话，群集状态）。 分布式系统的协调引出样板模式（boiler plate patterns），而且使用Spring Cloud开发人员能够快速地实现这些模式来启动服务和应用程序。 它们能够在任何分布式环境中正常工做，包括开发人员本身的笔记本电脑，裸机数据中心和受管平台，如Cloud Foundry。

 

Dubbo和spring cloud的区别 ：  两个框架的定义层面也不同，具体能够参照项目需求来选择；