[转]EJB、Dubbo、Spring Cloud对比

引言

 

 

最近一段时间不论互联网还是传统行业，凡是涉及信息技术范畴的圈子几乎都在讨论微服务框架。近期也看到各大技术社区开始组织一些沙龙和论坛来分享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的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。

参考博客：Dubbo vs SpringCloud

 

转自：http://blog.csdn.net/qiumuxia0921/article/details/52713791

评论

1 楼 zhendongloveyou 2017-08-15  

准备启用springCloud了吗