Dubbo 和 Spring Cloud 优缺点比较
文章目录
前言
Dubbo 和 Spring Cloud 都是微服务架构中涉及到的框架，但是Dubbo 相对 Spring Cloud 来说，其在一些模块功能方面的实现并没有Spring Cloud 齐全，但它也有自己的一些优势。
提示：以下是本篇文章正文内容，下面案例可供参考
1、什么是Dubbo?
Apache Dubbo 是一款微服务开发框架，目前主要提供了 RPC通信（RPC即远程过程调用，如两台服务器分别部署A项目和B项目，A项目通过网络（不在一个内存不能直接调用）调用B项目的方法的过程，叫做RPC）和微服务管理两大功能。使用Dubbo 提供的微服务，可以具备相互之间远程发现和通信能力，Dubbo 也有很多的微服务管理能力，如服务的注册发现，负载均衡，服务监控等功能。Dubbo 具有很强的扩展能力，开发者可以根据自己的业务特点，对Dubbo 的框架的默认行为进行改变，从而更好的满足自己的业务员。
1.1服务发现
消费端自动发现地址列表的能力，是微服务框架具备的关键能力，借助于自动化的服务发现，在不知道对端部署位置和IP 的情况下实现通信。
实现服务发现的方式很多，Dubbo 提供的是基于客户端的（Client-Based），通常还需要部署第三方注册中心插件来实现服务发现过程，如Nacos 、Consul 、 Zookeeper，当然Dubbo 自己也有很多注册中心组件。
架构图如下：
0. 服务容器负责启动加载服务
1.服务提供者在启动时，向注册中心注册自己的服务
2.服务消费者在启动时，向注册中心订阅所需服务
3.注册中心返回服务注册列表给消费者，如果有变更，注册中心基于长连接变更数据给消费者
4.服务消费者，从提供者的地址列表中，基于负载均衡算法，选择一台服务进行调用，失败则请求另外一台
5.服务消费者和提供者在内存中的累计调用次数和调用时间每隔一分钟定时发送给监控中心
1.2服务流量管理
流量管理的本质是根据制定好的规则将请求分发到应用服务上。
路由规则可以有多个，不同的路由规则之间存在优先级。如：Router(1) -> Router(2) -> …… -> Router(n)
一个路由规则可以路由到多个不同的应用服务。如：Router(2)既可以路由到Service(1)也可以路由到Service(2)
多个不同的路由规则可以路由到同一个应用服务。如：Router(1)和Router(2)都可以路由到Service(2)
路由规则也可以不路由到任何应用服务。如：Router(m)没有路由到任何一个Service上，所有命中Router(m)的请求都会因为没有对应的应用服务处理而导致报错
应用服务可以是单个的实例，也可以是一个应用集群
1.3 配置
按照编程方式可以分为四种方式：
- API配置，基于java编码的方式配置
- XML的配置，以xml 的方式配置各种组件，与Spring 无缝衔接
- 注解配置
- 属性配置
1.4 扩展
主要步骤为 4 个：
- 读取并解析配置文件
- 缓存所有扩展实现
- 基于用户执行的扩展名，实例化对应的扩展实现
- 进行扩展实例属性的 IOC 注入以及实例化扩展的包装类，实现 AOP 特性
使用场景：
- 如果你需要自定义负载均衡策略，你可以使用 Dubbo 扩展能力。
- 如果你需要实现自定义的注册中心，你可以使用 Dubbo 扩展能力。
- 如果你需要实现自定义的过滤器，你可以使用 Dubbo 扩展能力。
2 、Dubbo 和SpringCloud对比
2.1 各大组件对比
-
实现的组件对比
Dubbo : 服务的注册和发现、服务调用、负载均衡、容错、流量监控
SpringCloud ： 服务调用、服务的注册和发现、服务容错、服务网关、服务配置中心、服务链路追踪 -
相同功能组件的实现方案对比
容错方案：
Dubbo 主要采用的是集群的方式
SpringCloud 采用的主要是隔离、熔断、降级、限流服务调用：
Dubbo 采用的是RPC
Spring Cloud 采用的是RestTemplate
总结：Dubbo 在扩展方面来说比 SpringCloud 更加灵活，而Spring Cloud 组件比较完整强大，整个生态比较大，更加的成熟。