简介
本文介绍Dubbo与SpringCloud的区别。会介绍它们的使用场景以及各自的优缺点。
对比
使用场景
SpringCloud | Dubbo |
中小项目。 | 大项目，并发大。（一般百人以上的项目） |
SpringCloud占优势的项
项 | SpringCloud | Dubbo |
包依赖 | 维护简单：通过maven指定spring-cloud-parent版本即可。 | 维护困难：需要手动维护jar包依赖。 |
功能支持 | 功能完善：SpringCloud定位是微服务架构。 提供了微服务整套方案：服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等。 | 功能不完善：Dubbo定位是RPC 和服务治理。 配置中心、分布式跟踪等都需要自己去集成; |
开发难度 | 简单：通过注解、配置等方式可直接使用。 | 复杂：服务提供方要提供服务接口jar包。 服务提供方与调用方接口依赖方式太强，需管理好版本。 通常我们在提供对外服务时，都会以REST的方式提供出去。Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。 |
后期维护 | 容易：社区活跃，教程丰富，遇到问题容易找到解决方案 | 较难：社区不够活跃 |
Dubbo占优势的项
项 | SpringCloud | Dubbo |
性能 | 稍弱（主要是通信协议问题）。 Http 协议 + Rest 接口。 | 稍强。 RPC：TCP长连接和NIO异步传输（Netty实现）；。 适合系统的响应时间有严格要求的场景（长连接的作用）。 |
网络消耗 | 大。 http协议传输，带宽会比较多 国内95%的公司内，网络消耗不是什么太大问题。若真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解决。 | 小。 二进制的传输，占用带宽会更少。 |
接口约定 | 较难约束（接口协议约定比较自由且松散）。 需要有强有力的行政措施来限制接口无序升级。 | 容易约束。 统一提供方提供的服务接口jar包版本即可。 |
功能支持
项 Dubbo Spring Cloud 服务注册中心 Nacos，Zookeeper Spring Cloud Netflix Eureka 服务调用方式 RPC REST API 服务网关 无 Spring Cloud Netflix Zuul 断路器 Sentinel Spring Cloud Netflix Hystrix 分布式配置 Nacos 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
- ……
虽然，Dubbo自身只是实现了服务治理的基础，其他为保证集群安全、可维护、可测试等特性方面都没有很好的实现，但是几乎大部分关键组件都能找到第三方开源来实现，这些组件主要来自于国内各家大型互联网企业的开源产品。
Dubbo 已经适配到 Spring Cloud 生态，比如作为 Spring Cloud 的二进制通信方案来发挥 Dubbo 的性能优势，Dubbo 通过模块化以及对 HTTP 的支持适配到 Spring Cloud。
