Dubbo和SpringCloud架构设计 有什么区别

一个微服务架构的设计 需要考虑到 通讯协议，服务依赖模式，开始模式，运行模式等等很多方面考虑
首先说一下微服务架构
微服务架构是互联网很热⻔的话题，是互联网技术发展的必然结果。
早期的项目 10年前的项目 大多是 单体项目后来随着项目规模的发展不断裂变将单一应用程序划分成一组小的服务服务之间互相协调 互相配合，为用户提供最终价值虽然微服务架构没有公认的技术标准和规范或者草案但业界已经有一些很有影响力的开源微服务架构框架提供了微服务的关键思路我们先说一下 微服务的主要优势
1：降低复杂度 将原来偶合在一起的复杂业务拆分为单个服务规避了原本复杂度无止境的积累。每个微服务专注于单一功能，并通过定义良好的接口清晰表述服务边界，每个服务开发者只专注服务本身，通过使用缓存，DAL等各种技术手段来提升系统的性能，而对于消费方来说完全透明
2：可以独立部署
由于各个微服务具备独立的运行进程，所以每个微服务合一独立部署，当业务迭代时只需要发布相关服务的迭代即可，降低了测试的工作量同时也降低了服务发布的⻛险。
3：容错
微服务架构下
当某一组件发生故障时，故障会被隔离在单个服务中
通过限流、熔断等方式降低错误导致的危害，保障核心业务正常运行
4：扩展
单块架构应用也可以实现横向扩展，就是将整个应用完整的复制到不同的节点
当应用的不同组件在扩展需求上存在差异时，微服务架构便体现出其灵活性，因为每个服务可以根据实际需求独立进行扩展
Dubbo和Spring Cloud 的对比
先说一下 Dubbo的核心部件

Provider：暴露服务的提供方，可以通过jar或者容器的方式启动服务
Consumer：调用远程服务的服务消费方

Registry：服务注册中心和发现中心。
Monitor：统计服务和调用次数，调用时间监控中心。
Container：服务运行的容器
接下来看一下 Spring Cloud总体架构

Service Provider：暴露服务的提供方。
Service Consumer：调用远程服务的服务消费方。
EureKa Server：服务注册中心和服务发现中心。
从整体架构上来看，二者模式接近，都需要需要服务提供方，注册中心，服务消费方。
Dubbo只是实现了服务治理，而Spring Cloud子项目分别覆盖了微服务架构下的众多部件，而服务治理只是其中的一个方面。Dubbo提供了各种Filter，对于上述中“无”的要素，可以通过扩展Filter来完善。
从核心要素来看，Spring Cloud 更胜一筹，在开发过程中只要整合Spring Cloud的子项目就可以顺利的完成各种组件的融合，而Dubbo缺需要通过实现各种Filter来做定制，开发成本以及技术难度略高。
接下来看一下通讯协议
dubbo使用RPC通讯协议
Spring Cloud 使用HTTP协议的REST API
使用一个Pojo对象包含10个属性，请求10万次，Dubbo和Spring Cloud在不同的线程数量下，每次请求耗时（ms）如下：

dubbo支持各种通信协议，而且消费方和服务方使用⻓链接方式交互，通信速度上略胜SpringCloud，如果对于系统的响应时间有严格要求，⻓链接更合适。
服务依赖方式 方面 Dubbo：服务提供方与消费方通过接口的方式依赖，Spring Cloud：服务提供方和服务消费方通过json方式交互，因此只需要定义好相关json字段即可，消费方和提供方无接口依赖。

Dubbo服务依赖略重，需要有完善的版本管理机制，但是程序入侵少。而Spring Cloud通过Json交互，省略了版本管理的问题，但是具体字段含义需要统一管理，自身Rest API方式交互，为跨平台调用奠定了基础
接下来看一下 组件运行流程方面

每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务。每个service层和单独的DB交互

Dubbo组件运行流程gateWay:前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成Service：原子服务，只提供该业务相关的原子服务Zookeeper：原子服务注册到zk上
下图中的每个组件都是需要部署在单独的服务器上，gateway用来接受前端请求、聚合服务，并批量调用后台原子服务。每个service层和单独的DB交互。▲Dubbo组件运行流程gateWay:前置网关，具体业务操作，gateWay通过dubbo提供的负载均衡机制自动完成Service：原子服务，只提供该业务相关的原子服务Zookeeper：原子服务注册到zk上▲Spring Cloud 组件运行Spring Cloud所有请求都统一通过 API 网关（Zuul）来访问内部服务。网关接收到请求后，从注册中心（Eureka）获取可用服务。由 Ribbon 进行均衡负载后，分发到后端的具体实例。微服务之间通过 Feign 进行通信处理业务

接下来给大家总结一下吧

Dubbo出生于阿里系，是阿里巴巴服务化治理的核心框架，并被广泛应用于中国各互联网公司；只需要通过spring配置的方式即可完成服务化，对于应用无入侵。设计的目的还是服务于自身的业务为主。虽然阿里内部原因dubbo曾经一度暂停维护版本，但是框架本身的成熟度以及文档的完善程度，完全能满足各大互联网公司的业务需求。如果我们需要使用配置中心、分布式跟踪这些内容都需要自己去集成，
这样无形中增加了使用 Dubbo 的难度
Spring Cloud 是大名鼎鼎的 Spring 家族的产品，专注于企业级开源框架的研发。 Spring Cloud 自从发展到现在，仍然在不断的高速发展，几乎考虑了服务治理的方方面面，开发起来非常的便利和简单。