spring cloud vs dubbo

题外话

dubbo到底是读杜博还是达博，官方已有音标 |ˈdʌbəʊ|

正题

一、背景方面

-----------------------------------------------------------------------------------------------

• dubbo前期社区活跃度并不高，淘宝系主推的是HSF而并非dubbo。2017年dubbo被阿里重启、2018年dubbo正式进入Apache孵化器。随着dubbo重启及进行apache体系，dubbo社区也非常活跃，阿里也把dubbo做为重点项目。
• dubbo前期只是一个PRC框架，目前随着nacos、sentinel等阿里系项目开源，阿里微服务架构也逐步成为生态。
• 阿里巴巴是一个商业公司，虽然也开源了很多的顶级的项目，但从整体战略上来讲，仍然是服务于自身的业务为主。
• 目前带‘国’字号的企业使用dubbo还是比较多的，中国人寿、中国电信、中国工商银行...

vs

• springcloud有着强大活跃的社区，在全全球范围使用与影响巨大。
• springcloud是大名鼎鼎的Spring家族的产品,Spring专注于企业级开源框架的研发，不论是在中国还是在世界上使用都非常广泛，开发出通用、开源、稳健的开源框架就是他们的主业
• springcloud生态相对全面完Spring Cloud Config、Spring Cloud Netflix、Spring Cloud Consul 等(springcloud全家桶)
• 刘军作为Dubbo重启的负责人也发表过观点，Dubbo的发展方向是积极适应SpringCloud生态，并不是起冲突。

 

二、通讯方面

-----------------------------------------------------------------------------------------------

• Dubbo基于RPC协议，在OSI七层参考模型中http处于第一层应用层而rpc处于第三层会话层，是二进制的传输，占用带宽会更少。
• Dubbo框架在于面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样
• RPC依赖性强，对客户端与服务端均要引用共用的service，对双方在版本控制也有要求增加一定的耦合性
• REST在分布式环境下比RPC更加灵活,这也是为什么当当网的DubboX在对Dubbo的增强中增加了对REST的支持的原因

vs

• Spring Cloud是HTTP协议传输，带宽占用会比较多。但当下的企业内这点消耗的影响还是比较小的，并且http的报文也可以做一些压缩的优化。
• springcloud使用feign(open feign)是rest轻量级、松散、更加灵活，不存在代码之间的耦合，比较自由且松散。
• 微服务的提出者马丁福勒定义的微服务通讯就是基于散耦合的rest

 

三、实现方面

-----------------------------------------------------------------------------------------------

• dubbo为每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，这就是大家所说的要依赖一大堆jar包。

vs

• Spring Cloud的接口协议约定比较自由且松散不存在强依赖

 

四、人才方面

-----------------------------------------------------------------------------------------------

• 目前市场上Spring Cloud的研发人员相关dubbo会更好招，springcloud人才更受企业欢迎