Spring Cloud与Duddo比较(非原创）
文章大纲
一、Spring Cloud与Duddo背景介绍
二、Spring Cloud与Duddo比较
三、参考文章
一、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或者自研。
二、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需要自己组装；整机的性能有保证，组装的机子更自由。
