Spring Cloud与Dubbo详细对比

转自：CSDN，做者：Crazy晓枫 http://www.javashuo.com/article/p-bazfacgl-bc.html

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

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

Dubbo 的注册中心能够选择 Zookeeper、Redis 等多种；Spring Cloud 的注册中心只能用 Eureka 或者自研。

但若是我选，我会用 Spring Cloud。

从公司总体规划考虑

我不会选择好久没人维护的 Dubbo，重启以后也未必是原班人马。

从程序员招聘难度考虑

招 Spring Cloud 的程序员会更好招，由于更新更炫。

从系统结构简易程度考虑

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

从性能考虑

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

从开发难易度考虑

Dubbo 的神坑是 jar 包依赖，开发阶段难度极大。我曾经带一个三十人的团队，由于 jar 包升级问题，把每一个人的电脑都操做过。尤为每一个人电脑的库路径、命令、快捷键、键盘，鼠标快慢都不同，那会儿我默默的（此处省略200字）。Spring Cloud比较自由，但带来的问题是没法“强力约束接口规范”，建议用行政方式解决，且咱们团队的强力行政约束作的仍是比较好的，在接口管控层面比较强效，一个没有行政组织能力的IT团队真的是个废渣，用什么框架都很差使。

从后续改进考虑

Dubbo 的改进是经过 dubbofilter，不少东西没有，须要本身继承，如监控、日志、限流、追踪。Spring Cloud 本身带了不少监控、限流措施，可是功能可能和欧美习惯相同，国内须要进行适当改造，但更简单，就是 ServletFilter 而已，可是总归比 Dubbo 多一些东西是好的。

从配套措施考虑

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

从技术实力层面考虑

对比双方的源码，不得不说 Dubbo 做者的技术能力要高于Spring Cloud，而 Spring Boot 的做者技术能力要高于 Dubbo，即：

Spring Boot > Dubbo > Spring Cloud

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

最后说 Spring Boot，我要用“纯粹”两个字来评价这个框架。真的很纯粹，而且从其代码架构的整体思路一致性，目标的纯粹性，具体模块的干净利落，确实是个好框架，值得你们一读。

从系统应用层面考虑

在技术实力满分一百能打85分的鄙人的眼中，Dubbo 和 Spring Cloud，不就是两个框架么？咱们是要拯救世界的人，这俩块鹅卵石一块圆的一块方的，能垫脚就行，没有区别。

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

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

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

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

但它并无重复造轮子，而是选用目前各家公司开发的比较成熟的、经得住实践考验的服务框架（咱们须要特别感谢 Netflix ，这家很早就成功实践微服务的公司，几年前把自家几乎整个微服务框架栈贡献给了社区，Spring Cloud 主要是对 Netflix 开源组件的进一步封装），经过 Spring Boot 进行封装集成并简化其使用方式。基于 Spring Boot，意味着其使用方式如 Spring Boot 简单易用；可以与Spring Framework、Spring Boot、Spring Data 等其它 Spring 项目完美融合，意味着能从 Spring 得到巨大的便利，意味着能减小已有项目的迁移成本。

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

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

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

详见：网易考拉海购Dubbok框架优化详解 http://www.javashuo.com/article/p-rnhpwmjo-ko.html

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

为何选择使用 Spring Cloud 而放弃了 Dubbo

可能你们会问，为何选择了使用 Dubbo 以后，而又选择全面使用 Spring Cloud呢？其中有几个缘由：

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

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

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

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

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

Spring 推出 Spring Boot/Cloud 也是由于自身的不少缘由。Spring 最初推崇的轻量级框架，随着不断的发展也愈来愈庞大，随着集成项目愈来愈多，配置文件也愈来愈混乱，慢慢的背离最初的理念。随着这么多年的发展，微服务、分布式链路跟踪等更多新的技术理念的出现，Spring 急需一款框架来改善之前的开发模式，所以才会出现 Spring Boot/Cloud 项目，咱们如今访问 Spring 官网，会发现 Spring Boot 和 Spring Cloud 已经放到首页最重点突出的三个项目中的前两个，可见 Spring 对这两个框架的重视程度。

**总结一下，Dubbo 曾经确实很牛逼，可是 Spring Cloud 是站在近些年技术发展之上进行开发，所以更具技术表明性。**Spring Cloud 是整机，Dubbo 须要本身组装；整机的性能有保证，组装的机子更自由。

欢迎关注个人公众号：：一点教程。得到独家整理的学习资源和平常干货推送。 若是您对个人系列教程感兴趣，也能够关注个人网站：yiidian.com