SpringCloud与Dubbo区别对比

1：SpringCloud与Dubbo区别对比

（1）：活跃度

目前SpringCloud的活跃度明显远高于Dubbo（参考github）

（2）：主要区别

	Dubbo	Spring Cloud
服务注册中心	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
......	......	......

 

 

 

 

 

 

 

 

 

 

 

最大的区别:Spring Cloud抛弃了Dubbo 的RPC通讯，采用的是基于HTTP的REST方式。
严格来讲，这两种方式各有优劣。虽然在必定程度上来讲，后者牺牲了服务调用的性能，但也避免了上面提到的原生RPC带来的问题。
并且REST相比RPC更为灵活，服务提供方和调用方的依赖只依靠一纸契约，不存在代码级别的强依赖，这在强调快速演化的微服务环境下，显得更为合适。

例如：品牌机与组装机的区别

 

使用Dubbo构建的微服务架构就像组装电脑，各环节咱们的选择自由度很高，可是最终结果颇有可能由于一条内存质量不行就点不亮了，老是让人不怎么放心，可是若是你是一名高手，那这些都不是问题；

 

而Spring Cloud就像品牌（下面全部的框架负载均衡，服务网关。。。都是本身的）机，在Spring Source的整合下，作了大量的兼容性测试，保证了机器拥有更高的稳定性，可是若是要在使用非原装组件外的东西，就须要对其基础有足够的了解。

2：总结SpringCloud与Dubbo

Dubbo和Spring Cloud并非彻底的竞争关系，二者所解决的问题域不同：Dubbo的定位始终是一款RPC框架，而Spring Cloud的目的是微服务架构下的一站式解决方案。
非要比较的话，Dubbo能够类比到Netflix OSS技术栈，而Spring Cloud集成了Netflix OSS做为分布式服务治理解决方案，但除此以外Spring Cloud还提供了包括config、stream、security、sleuth等分布式服务解决方案。 当前因为RPC协议、注册中心元数据不匹配等问题，在面临微服务基础框架选型时Dubbo与Spring Cloud只能二选一，这也是二者总拿来作对比的缘由。
Dubbo以后会积极寻求适配到Spring Cloud生态，好比做为SpringCloud的二进制通信方案来发挥Dubbo的性能优点，或者Dubbo经过模块化以及对http的支持适配到Spring Cloud