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则是一个残缺的分布式一站式框架，他有着一样的服务注册核心，服务提供者，服务消费者，管控台，断路器，分布式配置服务，音讯总线，以及服务追踪等；