SpringCloud与Dubbo对比
| Dubbo | SpringCloud | |
|---|---|---|
| 服务注册中心 | Zookeeper | SpringCloud Netflix Eureka |
| 服务调用方式 | RPC | REST API |
| 服务监控 | Dubbo-monitor | SpringBoot Admin |
| 断路器 | 不完善 | SpringCloud Netflix Hystrix |
| 服务网关 | 无 | SpringCloud Netflix Zuul |
| 分布式配置 | 无 | SpringCloud Config |
| 服务跟踪 | 无 | SpringCloud Sleuth |
| 消息总线 | 无 | SpringCloud Bus |
| 数据流 | 无 | SpringCloud Stream |
| 批量任务 | 无 | SpringCloud Task |
最大区别：SpringCloud抛弃了Dubbo的RPC通信，采用的是基于HTTP的REST方式
严格来说，这两种方式各有优劣，虽然从一定程度上来说，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题，而且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显的更加合适
-
社区支持与更新力度
最为重要的是，Dubbo停止了5年左右的更新，虽然2017年重启了对Dubbo维护，对于技术发展的新需求，需要由开发者自行拓展升级（比如当当网弄出了DubboX），这对于很多想要采用微服务架构的中小软件组织，显然是不太合适，中小公司没有这么强大的技术能力去修改Dubbo源码+周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过 -
Dubbo重启之后的主要负责人刘军谈Dubbo和SpringCloud：
明确一点Dubbo和SpringCloud并不是完全的竞争关系，两者所解决的问题域并不一样：Dubbo的定位始终是一款RPC框架，而SpringCloud的目标是微服务架构下的一站式解决方案，如果非要比较的话，我觉得Dubbo可以类比到Netflix OSS技术栈，而SpringCloud集成了Netflix OSS作为分布式服务治理解决方案，但除此之外SpringCloud还提供了包括config，stream，security，sleuth等等分布式问题解决方案
当前由于RPC协议，注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo与SpringCloud是只能二选一，这也是为什么大家总是拿Dubbo和SpringCloud做对比的原因之一，Dubbo之后会积极寻求适配到SpringCloud生态，比如作为SpringCloud的二进制通信方案来发挥Dubbo的性能，或者Dubbo通过模块化以及对http的支持适配到SpringCloud
版权声明
本文仅代表作者观点，不代表百度立场。
本文系作者授权百度百家发表，未经许可，不得转载。
