| 技术维度 |Dubbo| SpringCloud| | --- | --- | --- | |服务注册中心| Zookeeper| Spring Cloud Netflix Eureka| |服务调用方式| RPC| REST API| |服务监控| Dubbo-monitor| Spring Boot Admin| |断路器| 不完善| Spring Cloud Netflix Hystrix| |服务网关| 无| Spring Cloud Netflix Zuul| |分布式配置| 无| Spring Cloud Config| |服务跟踪| 无| Spring Cloud Sleuth| |消息总线| 无| Spring Cloud Bus| |数据流 | 无| Spring Cloud Stream| |批量任务| 无| Spring Cloud Task| >[info]最大区别：SpringCloud 抛弃了 Dubbo 的 RPC 通信，采用的是基于 HTTP 的 REST 方式。 严格来说，这两种方式各有优劣。虽然从一定程度上来说，Spring Cloud 牺牲了服务调用的性能，但也避免了原生 RPC 带来的问题。而且 REST 相比 RPC 更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更加合适。 <br/> **1. 品牌机与组装机的区别** 很明显，Spring Cloud 的功能比 Dubbo 更加强大，涵盖面更广，而且作为 Spring 的拳头项目，它也能够与 Spring Framework，Spring Boot、Spring Data、Spring Batch 等其他 Spring 项目完美融合，这些对于微服务而言是至关重要的。 使用 Dubbo 构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而 Spring Cloud 就像品牌机，在 Spring Source 的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。 <br/> **2. 社区支持与更新力度** 最为重要的是，Dubbo 停止了 5 年左右的更新，虽然 2017.7 重启了。 对于技术发展的新需求，需要由开发者自行拓展升级(比如当当网弄出了 DubboX)，这对于很多想要采用微服务架构的中小软件组织，显然是不太合适的，中小公司没有这么强大的技术能力去修改 Dubbo 源码 + 周边的一整套解决方案，并不是每一个公司都有阿里的大牛+真实的线上生产环境测试过。 <br/> **3. Dubbo 与 SpringCloud 总结如下** —— 阿里中间件高级研发工程师刘军的原话： **** 关于 Dubbo 和 Spring Cloud 间的关系，我们在开源中国年终盛典的 Dubbo 分享中也作了简单阐述，首先要明确的一点是 Dubbo 和 Springcloud 并不是完全的竞争关系，两者所解决的问题域并不—样。 Dubbo 的定位始终是—款 RPC 框架，Spring Cloud 的目标是微服务架构下的—站式解决方案。如果非要比较的话，我觉得 Dubbo 可以类比到 Netflix OSS 技术栈，而Spring Cloud集成了 Netflix OSS 作为分布式服务治理解决方案，但除此之外 SpringCloud 还提供了包括 Config、Stream、Security、Sleuth 等等分布式问题解决方案。 当前由于 RPC 协议、注册中心元数据不匹配等问题，<mark>在面临微服务基础框架选型时 Dubbo 与 Spring Cloud 是只能二选一</mark>，这也是为什么大家总是拿 Dubbo和Spring Cloud 做对比的原因之一。 Dubbo 之后会积极录求适配到 SpringCloud 生态，比如作为 Spring cloud 的二进制通信方案来发挥 Dubbo 的性能优势，或者 Dubbo 通过模块化以及对 http 的支持适配到 Spring Cloud 。