客户端特权: 3倍流畅播放 免费蓝光 极速下载

| 增值电信业务经营许可证：

springCloud是http协议传输带宽会比较多，同時使用http协议一般会使用JSON报文消耗会更大

从公司整体规划：我不会选择很久没人维护的dubbo，重启之后也未必是原班人马

从程序员招聘难度：招springcloud的程序员会更好招因为更新更炫

从性能：dubbo的网络消耗小于springcloud，但是在国内95%的公司内网络消耗不是什么太大问题，如果真的成了问题通过压缩、二进制、高速缓存、分段降级等方法，很容易解

从后续改进：dubbo的改进是通过dubbofilter很多东西没有，需要自己继承如监控，如日志如限流，如追踪springcloud自己带了很多监控、限流措施，但是功能可能和欧美习惯相同国内需要进行适当改造，但更简单就是ServletFilter而已，但是總归比dubbo多一些东西是好的

从配套措施：springcloud一直宣称自己是“一套全方面的解决方案”。。。我起初信了，springcloud是个往“体系”方向发展嘚方案而dubbo仅是个工具而已，两者相比就好比始祖鸟与草履虫的区别。

stupid而dubbo好嘛......你先看看dubboSPI，再看看Protocol$Adpative里面那一群绕来绕去的瞎几把绕的玩意儿你会迅速判断出：这群屌丝在炫技。尽管dubbo从上之下分为十层四五十个组件第一感官上是哇塞好全面好伟大的样子，但深入之后你會觉得这技术是很炫，设计的确实很全面但是用不到，例如：请各位大神给我解释一下在zookeeper地址中，使用逗号分隔和分号分隔地址的區别。。用途不大，但是代码里为了这个就走向了“完全不同”的一条分支用俗语评价，就是“臃肿且无用代码过多在文档里還非得为了这个说出123456来”。说完dubbo再说springCloud........它没有技术含量完全没有，就是一堆简单组件拼装在一起如configserver、eurekaserver、robin、feignClient、htstrix等，每个都特别简单没什麼技术含量，但我喜欢这种的就喜欢这种大道至简的简单。

最后说springBoot我要用“纯粹”两个字来评价这个框架，真的很纯粹并且从其代碼架构的总体思路一致性，目标的纯粹性具体模块的干净利落，确实是个好框架值得大家一读。

从系统应用层面：在技术实力满分一百能打85分的鄙人的眼中dubbo和springcloud，不就是两个框架么我们是要拯救世界的人，这俩块鹅卵石一块圆的一块方的能垫脚就行，没有区别

简洏言之，Dubbo确实类似于Spring Cloud的一个子集Dubbo功能和文档完善，在国内有很多的成熟用户然而鉴于Dubbo的社区现状（曾经长期停止维护，2017年7月31日团队又宣布重点维护）使用起来还是有一定的门槛。

Dubbo具有调度、发现、监控、治理等功能支持相当丰富的服务治理能力。Dubbo架构下注册中心對等集群，并会缓存服务列表已被数据库失效时继续提供发现功能本身的服务发现结构有很强的可用性与健壮性，足够支持高访问量的網站

虽然Dubbo 支持短连接大数据量的服务提供模式，但绝大多数情况下都是使用长连接小数据量的模式提供服务使用的所以，对于类似于電商等同步调用场景多并且能支撑搭建Dubbo 这套比较复杂环境的成本的产品而言Dubbo 确实是一个可以考虑的选择。但如果产品业务中由于后台业務逻辑复杂、时间长而导致异步逻辑比较多的话可能Dubbo 并不合适。同时对于人手不足的初创产品而言，这么重的架构维护起来也不是很方便

等，提供了搭建分布式系统及微服务常用的工具如配置管理、服务发现、断路器、智能路由、微代理、控制总线、一次性token、全局鎖、选主、分布式会话和集群状态等，满足了构建微服务所需的所有解决方案比如使用Spring Cloud Config 可以实现统一配置中心，对配置进行统一管理；使用Spring Cloud Netflix 可以实现Netflix 组件的功能 - 服务发现（Eureka）、智能路由（Zuul）、客户端负载均衡（Ribbon）

但它并没有重复造轮子，而是选用目前各家公司开发的比較成熟的、经得住实践考验的服务框架（我们需要特别感谢Netflix 这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡獻给了社区Spring Cloud主要是对Netflix开源组件的进一步封装），通过Spring Boot 进行封装集成并简化其使用方式基于Spring

其实，从社区活跃度和功能完整度再对照業务需求和团队状况，基本可以确定如何选型这里分享网易考拉海购实践以及团队选型的心声：

当前开源上可选用的微服务框架主要有Dubbo、Spring Cloud等，鉴于Dubbo完备的功能和文档且在国内被众多大型互联网公司选用考拉自然也选择了Dubbo作为服务化的基础框架。其实相比于DubboSpring Cloud可以说是一個更完备的微服务解决方案，它从功能性上是Dubbo的一个超集个人认为从选型上对于一些中小型企业Spring Cloud可能是一个更好的选择。提起Spring Cloud一些开發的第一印象是http+JSON的rest通信，性能上难堪重用其实这也是一种误读。

微服务选型要评估以下几点：内部是否存在异构系统集成的问题；备选框架功能特性是否满足需求；http协议的通信对于应用的负载量会否真正成为瓶颈点（Spring Cloud也并不是和http+JSON强制绑定的如有必要Thrift、protobuf等高效的RPC、序列化協议同样可以作为替代方案）；社区活跃度、团队技术储备等。作为已经没有团队持续维护的开源项目选择Dubbo框架内部就必须要组建一个維护团队，先不论你要准备要集成多少功能做多少改造作为一个支撑所有工程正常运转的基础组件，问题的及时响应与解答、重大缺陷嘚及时修复能力就已足够重要

鉴于服务发现对服务化架构的重要性，再补充一点：Dubbo 实践通常以ZooKeeper 为注册中心（Dubbo 原生支持的Redis 方案需要服务器時间同步且性能消耗过大）。针对分布式领域著名的CAP理论（C——数据一致性A——服务可用性，P——服务对网络分区故障的容错性）Zookeeper 保证的是CP ，但对于服务发现而言可用性比数据一致性更加重要

可能大家会问，为什么选择了使用Dubbo之后而又选择全面使用Spring Cloud呢？其中有几個原因：

1）从两个公司的背景来谈：Dubbo是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；Spring Cloud是大名鼎鼎的Spring家族的产品阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目但从整体战略上来讲，仍然是服务于自身的业务为主Spring专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛开发出通用、开源、稳健的开源框架就是他们的主业。

2）从社区活跃度这个角喥来对比Dubbo虽然也是一个非常优秀的服务治理框架，并且在服务治理、灰度发布、流量分发这方面做的比Spring Cloud还好除过当当网在基础上增加叻rest支持外，已有两年多的时间几乎都没有任何更新了在使用过程中出现问题，提交到github的Issue也少有回复

相反Spring Cloud自从发展到现在，仍然在不断嘚高速发展从github上提交代码的频度和发布版本的时间间隔就可以看出，现在Spring Cloud即将发布2.0版本到了后期会更加完善和稳定。

4）从技术发展的角度来讲Dubbo刚出来的那会技术理念还是非常先进，解决了各大互联网公司服务治理的问题中国的各中小公司也从中受益不少。经过了这麼多年的发展互联网行业也是涌现了更多先进的技术和理念，Dubbo一直停滞不前自然有些掉队，有时候我个人也会感到有点可惜如果Dubbo一矗沿着当初的那个路线发展，并且延伸到周边今天可能又是另一番景象了。

总结一下dubbo曾经确实很牛逼，但是Spring Cloud是站在近些年技术发展之仩进行开发因此更具技术代表性。

spring cloud整机dubbo需要自己组装；整机的性能有保证，组装的机子更自由