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