一、架构完整度：
从上图可以看出，Dubbo只是实现了服务治理，而Spring Cloud下面有17个子项目（可能还会新增）分别覆盖了微服务架构下的方方面面，服务治理只是其中的一个方面，一定程度来说，Dubbo只是Spring Cloud Netflix中的一个子集。如果dubbo要实现这些功能就需要额外去集成一些组件。
二、通信方式：
Dubbo的服务调用是通过RPC实现的：
优势：服务调用性能损耗小
劣势：
1.dubbo的每个微服务定义了各自的service抽象接口，并通过持续集成发布到私有仓库中jar的版本管理过于严格，当项目慢慢发展壮大后，jar的版本维护成本会越来越高；
2.接口复用较为困难，通常我们在提供对外服务时，都会以REST的方式提供出去，这样可以实现跨平台的特点，任何一个语言的调用方都可以根据接口定义来实现。那么在Dubbo中我们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。
Springcloud是基于http协议的REST API通信方式：
优势：满足微服务的设计理念，易于对外提供服务，为跨平台调用奠定了基础
劣势：
1.性能消耗比rpc通信大一点，但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，可以解决；
2.无法强力约束接口规范，需要有一个严格的规范约束，不然随着系统的扩展，接口定义可能会百花齐放。
总结：
使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；而Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解
