Dubbo,SpringCloud,EJB对比

引言

最近一段时间不论互联网仍是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论微服务框架。近期也看到各大技术社区开始组织一些沙龙和论坛来分享spring cloud的相关实施经验。

目前，Spring Cloud在国内的知名度不高。其实以前国内比较流行的是阿里巴巴的服务治理框架Dubbo有必定的关系，出了Dubbo自己有本身较为完善的中文文档，短时间内是Dubbo的天下。咱们项目中用到的EJB框架作为SOA服务核心，EJB做为J2EE的113个规范之一，实在是有本身不能够或缺的地位。如今咱们就来比较一下那个基础框架更好一些。

背景：

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

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

EJB是是为"服务集群"和"企业级开发"而生，其庞大且唬人的背景，我就不阐述了，EJB实现原理： 就是把原来放到客户端实现的代码放到服务器端，并依靠RMI进行通讯。RMI实现原理 ：就是经过Java对象可序列化机制实现分布计算。服务器集群： 就是经过RMI的通讯，链接不一样功能模块的服务器，以实现一个完整的功能。

社区活跃度：

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

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

架构完整性：

在SpringCloud和Dubbo以及EJB的比较中，用张图来比较一下：

 

	EJB	Dubbo	SpringCloud
开发方	标准由Oracle开发	阿里	Spring社区
最新版本及时间	3.1，2009年	2.5.3，2012年10月23号	Camden.SR3，2016年11月29号
维护状态	不活跃，3.2只是草案	再也不继续维护	活跃
互联网应用案例	暂未发现	阿里、京东、当当等	中国联通子公司 上海米么金服 指点无限（北京）科技有限公司 易保软件 目前在定制开发中 广州简法网络 深圳睿云智合科技有限公司 猪八戒网，目前调研中 上海云首科技有限公司 华为 整合netty进来用rpc 包括nerflix那套东西 须要注意的是sleuth traceid的传递须要本身写。tps在物理机上能突破20w 东软 南京云账房网络科技有限公司 四众互联(北京)网络科技有限公司 深圳摩令技术科技有限公司 广州万表网 视觉中国 上海秦苍信息科技有限公司-买单侠 爱油科技(大连)有限公司 爱油科技基于SpringCloud的微服务实践
基于协议	Rmi	可选，默认dobbo	http
可用的语言	Java	Java	全部语言
分布式事物	是	否	否
无状态部署	否	是	是
服务器治理	服务发现、负载均衡	服务发现、服务路由、服务负载均衡、服务列表、服务分组、服务依赖管理、服务权重、服务受权、服务直连、上下文隐式传参、分组聚合、结果缓存	除dubbo有的外：服务网关、断路器、服务跟踪、消息总线、批量任务
分布式配置	无	第三方	有
基于的web容器	Jboss	Tomcat内嵌	Tomcat内嵌
单元测试	支持	支持	支持
性能对比

 

 

咱们通常使用EJB，彻底是很看好它的分布式的远程调用，可是在这个网络发展面向大数据的时代，光能实现远程调用是远远不够的，好比说服务跟踪、服务治理、批量任务等等。

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

 

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

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

根据微服务架构在各方面的要素，看看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对于上表中总结为“无”的组件不表明不能实现，而只是Dubbo框架自身不提供，须要另外整合以实现对应的功能，好比：
分布式配置：可使用淘宝的diamond、百度的disconf来实现分布式配置管理。可是Spring Cloud中的Config组件除了提供配置管理以外，因为其存储可使用Git，所以它自然的实现了配置内容的版本管理，能够完美的与应用版本管理整合起来。

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

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

RMI vs RPC vs REST

RMI对于服务间调用：性能是几种里面快的，EJB性能没得说，相比于RPC和REST。可是RMI在服务中也是有接口依赖方式比较强，下面会介绍，所以RMI和RPC在通讯灵活方面是没有REST更加灵活地。可是性能是是RMI>RPC>REST的。

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

小结：

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

文档质量：

EJB做为一种规范，EJB容器出了服务治理方面上的完整架构，可是仍是服务治理方面是它的硬伤呀。

 

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

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

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

总结

 

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