Spring Cloud与Duddo比较(非原创）

文章大纲

1、Spring Cloud与Duddo背景介绍
2、Spring Cloud与Duddo比较
3、参考文章

 

1、Spring Cloud与Duddo背景介绍

  国内技术人员喜欢拿 Dubbo 和 Spring Cloud 进行对比，是由于二者都是服务治理很是优秀的开源框架。但它们二者的出发点是不同的，Dubbo 关注于服务治理这块而且之后也会继续往这个方向去发展，Spring Cloud 关注的是微服务的全套解决方案，服务治理也只是微服务生态的一部分而已。所以能够大胆的判定，Dubbo 将来会在服务治理方面更为出色，而 Spring Cloud 在微服务治理上面无人能敌。

  随着Dubbo成为Apache孵化项目，并且Alibaba从新启动维护Dubbo，Spring Cloud整合Dubbo是必然的，目前已经在Github上。

  同时阿里巴巴已经推出了Spring Cloud Alibaba项目由两部分组成：阿里巴巴开源组件和阿里云产品组件，旨在为Java开发人员在使用阿里巴巴产品的同时，经过利用 Spring 框架的设计模式和抽象能力，注入Spring Boot和Spring Cloud的优点。

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

  dubbo因为是二进制的传输，占用带宽会更少，springCloud是http协议传输，带宽会比较多，同时使用http协议通常会使用JSON报文，消耗会更大。

  dubbo的开发难度较大，缘由是dubbo的jar包依赖问题不少大型工程没法解决，springcloud的接口协议约定比较自由且松散，须要有强有力的行政措施来限制接口无序升级。

  dubbo的注册中心能够选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研。

2、Spring Cloud与Duddo比较

1. 公司的背景

  Dubbo，是阿里巴巴服务化治理的核心框架，并被普遍应用于中国各互联网公司；Spring Cloud是大名鼎鼎的Spring家族的产品。阿里巴巴是一个商业公司，虽然也开源了不少的顶级的项目，但从总体战略上来说，仍然是服务于自身的业务为主。Spring专一于企业级开源框架的研发，不管是在中国仍是在世界上使用都很是普遍，开发出通用、开源、稳健的开源框架就是他们的主业。

2. 系统结构简易程序

  springcloud的系统结构更简单、“注册+springmvc=springcloud”，而dubbo各类复杂的Url，protocol，register，invocation，dubbofilter，dubboSPI，dubbo序列化..........炫技的成分更多一些

3. 开发难易度

  Duddo的神坑是jar包依赖，开发阶段难度极大。springcloud比较自由，但带来的问题是没法“强力约束接口规范”。
  从后续改进：dubbo的改进是经过dubbofilter，不少东西没有，须要本身继承，如监控，如日志，如限流，如追踪。springcloud本身带了不少监控、限流措施，可是功能可能和欧美习惯相同，国内须要进行适当改造，但更简单，就是ServletFilter而已，可是总归比dubbo多一些东西是好的

4. 配套措施

  springcloud一直宣称本身是“一套全方面的解决方案”。。。。。。我起初信了，后来发现上当了，实话说：有，可是不是很健全，100分打50的样子，不少你还须要改造。而DUBBO相反，一直宣称本身是“一套全方面的服务化方案”。。。。。。纯服务化顶个鸟用，任何系统都是相辅相成配套的，一个完整的系统，要有前台、中台、后台、前台包括前端和交互，中台包括交易、任务、数据，后台包括财务、帐户、管理...........单纯的服务化解决不了“任何问题”，惟有体系才能解决。在这个层面，springcloud是个往“体系”方向发展的方案，而dubbo仅是个工具而已，二者相比，就比如始祖鸟与草履虫的区别。

5. 技术实力层面

  对比双方的源码，不得不说dubbo做者的技术能力要高于springCloud，而springBoot的做者技术能力要高于dubbo。即：springboot>dubbo>springcloud。我喜欢springboot这种大道至简的风格，keep it simple and stupid。而dubbo好嘛......你先看看dubboSPI，再看看Protocol$Adpative里面那一群绕来绕去的瞎几把绕的玩意儿，你会迅速判断出：这群屌丝在炫技。尽管dubbo从上之下分为十层四五十个组件，第一感官上是哇塞好全面好伟大的样子，但深刻以后你会以为，这技术是很炫，设计的确实很全面，可是用不到，例如：请各位大神给我解释一下，在zookeeper地址中，使用逗号分隔和分号分隔地址的区别。。。。。用途不大，可是代码里为了这个就走向了“彻底不一样”的一条分支。用俗语评价，就是“臃肿且无用代码过多，在文档里还非得为了这个说出123456来”。说完dubbo再说springCloud........它没有技术含量，彻底没有，就是一堆简单组件拼装在一块儿，如configserver、eurekaserver、robin、feignClient、htstrix等，每一个都特别简单，没什么技术含量，但我喜欢这种的，就喜欢这种大道至简的简单。

6. 社区活跃度

  Dubbo虽然也是一个很是优秀的服务治理框架，而且在服务治理、灰度发布、流量分发这方面作的比Spring Cloud还好，除过当当网在基础上增长了rest支持外，已有两年多的时间几乎都没有任何更新了。在使用过程当中出现问题，提交到github的Issue也少有回复。
  相反Spring Cloud自从发展到如今，仍然在不断的高速发展，从github上提交代码的频度和发布版本的时间间隔就能够看出，如今Spring Cloud即将发布2.0版本，到了后期会更加完善和稳定。

7. 架构完整度

  Dubbo框架只是专一于服务之间的治理，若是咱们须要使用配置中心、分布式跟踪这些内容都须要本身去集成，这样无形中使用dubbo的难度就会增长。Spring Cloud几乎考虑了服务治理的方方面面，更有Spring Boot这个大将的支持，开发起来很是的便利和简单。

8. 性能

  Dubbo的网络消耗小于springcloud，可是在国内95%的公司内，网络消耗不是什么太大问题，若是真的成了问题，经过压缩、二进制、高速缓存、分段降级等方法，很容易解

9. 文档质量

  Dubbo的文档能够说在国内开源框架中算是一流的，很是全，而且讲解的也很是深刻，因为版本已经稳定再也不更新，因此也不太会出现不一致的状况，另外提供了中文与英文两种版本，对于国内开发者来讲，阅读起来更加容易上手，这也是dubbo在国内更火一些的缘由吧。
  Spring Cloud因为整合了大量组件，文档在体量上天然要比dubbo多不少，文档内容上还算简洁清楚，可是更多的是偏向整合，更深刻的使用方法仍是须要查看其整合组件的详细文档。另外因为Spring Cloud基于Spring Boot，不少例子相较于传统Spring应用要简单不少（由于自动化配置，不少内容都成了约定的默认配置），这对于刚接触的开发者可能会有些不适应，比较建议了解和学习Spring Boot以后再使用Spring Cloud，否则可能会出现不少只知其一;不知其二的状况。
  虽然Spring Cloud的文档量大，可是若是使用Dubbo去整合其余第三方组件，实际也是要去阅读大量第三方组件文档的，因此在文档量上，我以为区别不大。对于文档质量，因为Spring Cloud的迭代很快，不免会出现不一致的状况，因此在质量上我认为Dubbo更好一些。而对于文档语言上，Dubbo天然对国内开发团队来讲更有优点。

10. 总结

   spring cloud整机，dubbo须要本身组装；整机的性能有保证，组装的机子更自由。

3、参考文章

1. https://blog.csdn.net/u010664947/article/details/80007767
2. http://www.51ui.cn/taiw/2919129/
3. https://blog.csdn.net/chendeyou5/article/details/79449423