SpringCloud和Dubbo的区别介绍

介绍：
Dubbo，Apache Dubbo是一款高性能的Java RPC框架。其前身是阿里巴巴公司开源的一个高性能、轻量级的开源Java RPC框                架，可以和Spring框架无缝集成。Dubbo 是 SOA 时代的产物，它的关注点主要在于服务的调用，流量分发、流量监控和              熔断.Dubbo主要定位在服务治理上
Spring Cloud，从命名我们就可以知道，它是Spring Source的产物，Spring社区的强大背书可以说是Java企业界最有影响力的组              织了，除了Spring Source之外，还有Pivotal和Netfix是其强大的后盾与技术输出。其中Netflix开源的整套微服务架构套件              是Spring Cloud的核心。而 Spring Cloud 诞生于微服务架构时代，考虑的是微服务治理的方方面面，另外由于依托了                    Spirng、Spirng Boot 的优势之上.

传输：
Dubbo由于是二进制的传输，占用带宽会更少；
Spring Cloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大。但是在国内95%的公司内，网络消耗不是什么太大问题，如果真的成了问题，通过压缩、二进制、高速缓存、分段降级等方法，很容易解。

开发难度：
Dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决；
Spring Cloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级

注册中心：
Dubbo的注册中心可以选择zk,redis等多种；Zookeeper 是 Apache Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 。
Spring Cloud:的注册中心只能用Eureka或者自研Eureka：就是服务注册中心(可以是一个集群)，对外暴露自己的地址.

配置中心：
dubbo：如果我们使用配置中心、分布式跟踪这些内容都需要自己去集成，无形中增加了使用难度。
Spring Cloud：提供了微服务的一整套解决方案：服务发现注册中心Eureka  consul、配置中心config、消息总线bus、负载均衡Ribbon、熔断器Hystrix、数据监控、服务通信Feign  网关 Geteway等

核心部件的比较：
Dubbo：
Provider：暴露服务的提供方，可以通过 jar 或者容器的方式启动服务。
Consumer：调用远程服务的服务消费方。
Registry：服务注册中心和发现中心。
Monitor：统计服务和调用次数，调用时间监控中心。（Dubbo 的控制台页面中可以显示，目前只有一个简单版本。）
Container：服务运行的容器。
Spring Cloud：
Service Provider： 暴露服务的提供方。
Service Consumer：调用远程服务的服务消费方。
EureKa Server： 服务注册中心和服务发现中心。

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

后续改进：
Dubbo通过dubbofilter，很多东西没有，需要自己继承，如监控，如日志，如限流，如追踪
Spring Cloud自己带了很多监控、限流措施，但是功能可能和欧美习惯相同，国内需要进行适当改造，但更简单，就是ServletFilter而已，但是总归比dubbo多一些东西是好的；

服务依赖方式：
Dubbo：服务提供方与消费方通过接口的方式依赖，服务调用设计如下：
Interface 层：服务接口层，定义了服务对外提供的所有接口。
Molel 层：服务的 DTO 对象层。
Business层：业务实现层，实现 Interface 接口并且和 DB 交互。
因此需要为每个微服务定义各自的 Interface 接口，并通过持续集成发布到私有仓库中。调用方应用对微服务提供的抽象接口存在强依赖关系，开发、测试、集成环境都需要严格的管理版本依赖。

通过 maven 的 install & deploy 命令把 Interface 和 Model 层发布到仓库中，服务调用方只需要依赖 Interface 和 Model 层即可。在开发调试阶段只发布 Snapshot 版本，等到服务调试完成再发布；Release 版本，通过版本号来区分每次迭代的版本。通过 xml 配置方式即可接入 Dubbo，对程序无入侵。
总之：服务提供方与消费方通过接口的方式依赖，Dubbo 服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。

Spring Cloud：
服务提供方和服务消费方通过 Json 方式交互，因此只需要定义好相关 Json 字段即可，消费方和提供方无接口依赖。通过注解方式来实现服务配置，对于程序有一定入侵。
通过 Json 交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身 Rest API 方式交互，为跨平台调用奠定了基础。

总体：
Dubbo：使用Dubbo构建的微服务架构就像组装电脑，各环节我们的选择自由度很高，但是最终结果很有可能因为一条内存质量不行就点不亮了，总是让人不怎么放心，但是如果你是一名高手，那这些都不是问题；
Spring Cloud就像品牌机，在Spring Source的整合下，做了大量的兼容性测试，保证了机器拥有更高的稳定性，但是如果要在使用非原装组件外的东西，就需要对其基础有足够的了解。