Dubbo and SpringCloud

• Dubbo 总体架构
• Spring 的核心架构
• 生态
• 支持协议
• 性能比较
• 服务依赖方式
• 组件运行流程

• Provider ：暴露服务的提供方，可以通过Jar或者容器方式启动服务
• Consumer：调用远程服务的服务消费方
• Register：服务注册中心和发现中心
• Monitor：统计服务和调用次数的、调用时间监控中心。
• Container ：服务运行的容器

• Service Provider：暴露服务的提供方
• Service Consumer：调用远程服务的服务消费方
• EureKa：服务注册中心和服务发现中心

从整体设计来看，二者模式接近，都要服务提供方，注册中心，服务消费方

Dubbo 只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，服务治理只是其中的一个方面。

Dubbo 提供了各种Filter，对于一些没有提供的服务，可以通过扩展Filter来实现。而对于Spring Cloud 的子项目就可以顺利的完成各个组件的融合，相比之下Dubbo的开发成本更高。

Dubbo 使用RPC通讯协议，支持的协议较多：

• Dubbo协议
• Hessian 协议
• HTTP协议
• Webservice

Spring Cloud 使用HTTP协议的REST API

使用一个 Pojo 对象包含 10 个属性，请求 10 万次，Dubbo 和 Spring Cloud 在不同的线程数量下，每次请求耗时（ms）如下：

说明：客户端和服务端配置均采用阿里云的 ECS 服务器，4 核 8G 配置，Dubbo 采用默认的 Dubbo 协议。
通过对比可以看出Dubbo 的性能稍微好一些

Dubbo 需要提供一个借口jar， 并通过持续继承发布到私有仓库中，调用方应用对微服务提供的抽象借口存在前依赖关系，开发、测试、集成环境都要严格管理版本依赖。

Spring Cloud 服务提供方和服务消费方通过json方式交互，因此只需要定义好相关的JSON字段即可，消费方和提供方无借口依赖，为跨平台奠定了基础。

Dubbo 需要开发自己的一套API网关，而Spring Cloud则可以通过Spring Getway 配置即可完成网关定制。使用方式上Dubbo 会更加繁琐一些。