共计 789 个字符，预计需要花费 2 分钟才能阅读完成。
Dubbo 架构图
SpringCloud 架构图
总览
面向微服务的技术 (SpringCloud)
Spring Cloud 摈弃了 Dubbo 的 RPC 通信，采纳的是基于 HTTP 的 REST 形式。严格来说，这两种形式各有优劣。尽管从肯定水平上来说，后者就义了服务调用的性能，但也防止了下面提到的原生 RPC 带来的问题。而且 REST 相比 RPC 更为灵便，服务提供方和调用方，不存在代码级别的强依赖，这在强调疾速演变的微服务环境下显得更加适合。
最大的区别：
- Dubbo 底层是应用 Netty 这样的 NIO 框架，是基于 TCP 协定传输的，配合以 Hession 序列化实现 RPC 通信;
- 而 SpringCloud 是基于 Http 协定 +rest 接口调用近程过程的通信，相对来说，Http 申请会有更大的报文，占的带宽也会更多。然而 REST 相比 RPC 更为灵便，服务提供方和调用方的依赖只依附一纸契约，不存在代码级别的强依赖，这在强调疾速演变的微服务环境下，显得更为适合，至于重视通信速度还是不便灵活性，具体情况具体思考。
定位区别：
Dubbo 是 SOA 时代的产物，它的关注点次要在于服务的调用，流量散发、流量监控和熔断; 而 Spring Cloud 诞生于微服务架构时代，思考的是微服务治理的方方面面，另外因为依靠 Spirng、Spirng Boot 的劣势之上，两个框架在开始指标就不统一，Dubbo 定位服务治理、Spirng Cloud 是一个生态。因而能够大胆地判断，Dubbo 将来会在服务治理方面更为杰出，而 SpringCloud 在微服务治理下面无人能敌。
模块区别：
1、Dubbo 次要分为服务注册核心，服务提供者，服务消费者，还有管控核心；
2、相比起 Dubbo 简略的四个模块，SpringCloud 则是一个残缺的分布式一站式框架，他有着一样的服务注册核心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，音讯总线，以及服务追踪等；
正文完