架构完整度

Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。

Dubbo 提供了各种 Filter，对于上述中“无”的要素，虽然Dubbo本身并不提供，但可以通过扩展 Filter 来完善。例如：

• 分布式配置：可以使用淘宝的 diamond、百度的 disconf 来实现分布式配置管理。
• 服务跟踪：可以使用京东开源的 Hydra，或者扩展 Filter 用 Zippin 来做服务跟踪。
• 批量任务：可以使用当当开源的 Elastic-Job、tbschedule。

注意：Spring Cloud中的Config组件除了提供配置管理之外。由于其存储可以使用git，因此它天然的实现了配置内容的版本管理，可以完美的与应用版本管理整合起来

通讯协议

Dubbo的服务调用是通过RPC实现的，SpringCloud是基于HTTP协议的REST API。

使用Dubbo的RPC来实现服务间调用的一些痛点：

• 服务提供方与调用方接口存在强依赖关系
  不论开发、测试、集成环境都需要严格的管理版本依赖，才不会出现服务方与调用方的不一致导致应用无法编译成功等一系列问题。
  而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，当然REST接口也有痛点，因为接口定义过轻，很容易导致定义文档与实际实现不一致导致服务集成时的问题，但是该问题很好解决，只需要通过每个服务整合swagger，让每个服务的代码与文档一体化，就能解决。所以在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。
• 服务对平台敏感，难以简单复用
  通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若我们每个服务本身就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。这也是为什么当当网在dubbox（基于Dubbo的开源扩展）中增加了对REST支持的原因之一。

本文参考：
https://blog.csdn.net/anningzhu/article/details/76599875
https://blog.csdn.net/zhangweiwei2020/article/details/78646252