Apache Dubbo(概念篇)

文章目录

  • 什么是dubbo?
    • 概念
    • 特性
      • 1.服务发现
      • 2.RPC远程服务调用
        • 2.1 服务调用过程
        • 2.2 提供方暴露一个服务的详细过程
        • 2.3 消费方消费一个服务的过程
      • 3.负载均衡
      • 4.容错机制
      • 5.配置管理
        • 5.1 启动阶段配置项
        • 5.2 服务治理规则
        • 5.3 动态配置项

什么是dubbo?

概念

Dubbo是阿里巴巴公司开源的一个高性能优秀的分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。

现已成为 Apache 基金会孵化项目,2021年6月已经发布3.0版本

官方文档 https://dubbo.apache.org/zh/docs/

特性

  1. 服务发现
  2. RPC远程服务调用
  3. 负载均衡
  4. 容错机制
  5. 配置管理

1.服务发现

Dubbo 基于消费端的自动服务发现能力,其基本工作原理如下图:
Apache Dubbo(概念篇)_第1张图片
节点说明

节点 角色
Provider 暴露服务的服务提供方
Consumer 调用远程服务的服务消费方
Registry 调用远程服务的服务消费方
Monitor 统计服务的调用次数和调用时间的监控中心
Container 服务运行容器

工作原理图解

0.服务容器负责启动,加载,运行服务提供方
1.服务提供方启动时,向注册中心注册自己提供的接口
2.服务消费方启动时,向注册中心订阅自己所需的服务
3.注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者
4.服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用
5.服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心

2.RPC远程服务调用

2.1 服务调用过程

Dubbo 服务调用过程比包含众多步骤,比如发送请求、编解码、服务降级、过滤器链处理、序列化、线程派发以及响应请求等步骤

步骤:

1.服务消费者通过代理对象 Proxy 发起远程调⽤
2.接着 通过⽹络客⼾端 Client 将编码后的请求发送给服务提供⽅的⽹络层(Server)上
3.Server 在收到请求后,先对数据包进⾏解码及序列化
4.将解码后的请求发送⾄分发器 Dispatcher
5.再由分发器将请求派发到指定的线程池上
6.最后由线程池调⽤具体的服务

如图:
Apache Dubbo(概念篇)_第2张图片

2.2 提供方暴露一个服务的详细过程

步骤:

  1. 首先 ServiceConfig 类拿到对外提供服务的实际类 ref(如:HelloWorldImpl
  2. 然后通过 ProxyFactory 类的 getInvoker 方法使用 ref 生成一个 AbstractProxyInvoker 实例。到这一步就完成具体服务到 Invoker 的转化
  3. 接下来就是 Invoker 转换到 Exporter 的过程

如图:
Apache Dubbo(概念篇)_第3张图片

2.3 消费方消费一个服务的过程

步骤:

  1. 首先通过ReferenceConfig类的init方法调用Protocolrefer方法生成Invoker实例。
  2. 然后把Invoker转为客户端需要的接口。

如图:
Apache Dubbo(概念篇)_第4张图片

3.负载均衡

Dubbo提供了常见的多种集群策略实现,缺省为 random 随机调用。并预扩展点予以自行实现。如何扩展?

分类

Random LoadBalance (随机)

  • 按权重设置随机概率
  • 在一个截面上碰撞的概率高,但调用量越大分布越均匀,而且按概率使用权重后也比较均匀,有利于动态调整提供者权重。
     

RoundRobin LoadBalance(轮循)

  • 按公约后的权重设置轮询比率
  • 存在慢的提供者累积请求的问题,比如:第二台机器很慢,但没挂,当请求调到第二台时就卡在那,久而久之,所有请求都卡在调到第二台上
     

LeastActive LoadBalance(最少活跃)

  • 相同活跃数的随机,活跃数指调用前后计数差
  • 使慢的提供者收到更少请求,因为越慢的提供者的调用前后计数差会越大

ConsistentHash LoadBalance(一致性 Hash)

  • 相同参数的请求总是发到同一提供者
  • 当某一台提供者挂时,原本发往该提供者的请求,基于虚拟节点,平摊到其它提供者,不会引起剧烈变动
  • 算法参见:http://en.wikipedia.org/wiki/Consistent_hashing
  • 缺省只对第一个参数 Hash,如果要修改,请配置
  • 缺省用 160 份虚拟节点,如果要修改,请配置

4.容错机制

在集群调用失败时,Dubbo 提供了多种容错方案,缺省为 failover 重试。如何扩展?

节点关系,如图:
Apache Dubbo(概念篇)_第5张图片
各节点关系:

  1. 这里的 InvokerProvider 的一个可调用 Service 的抽象,Invoker 封装了 Provider 地址及 Service 接口信息
  2. Directory 代表多个 Invoker,可以把它看成 List ,但与 List不同的是,它的值可能是动态变化的,比如注册中心推送变更
  3. ClusterDirectory 中的多个 Invoker 伪装成一个 Invoker,对上层透明,伪装过程包含了容错逻辑,调用失败后,重试另一个
  4. Router 负责从多个 Invoker 中按路由规则选出子集,比如读写分离,应用隔离等
  5. LoadBalance 负责从多个 Invoker 中选出具体的一个用于本次调用,选的过程包含了负载均衡算法,调用失败后,需要重选 集群容错模式

分类

Failover Cluster(失败自动切换)

  • 当出现失败,重试其它服务器。通常用于读操作,但重试会带来更长延迟。可通过 retries="2" 来设置重试次数(不含第一次)
     

Failfast Cluster (快速失败)

  • 只发起一次调用,失败立即报错。通常用于非幂等性的写操作,比如新增记录
     

Failsafe Cluster (失败安全)

  • 出现异常时,直接忽略。通常用于写入审计日志等操作
     

Failback Cluster(失败自动恢复)

  • 后台记录失败请求,定时重发。通常用于消息通知操作
     

Forking Cluster(并行调用)

  • 并行调用多个服务器,只要一个成功即返回。通常用于实时性要求较高的读操作,但需要浪费更多服务资源。可通过 forks="2" 来设置最大并行数
     

Broadcast Cluster(广播)

  • 广播调用所有提供者,逐个调用,任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息
  • 现在广播调用中,可以通过 broadcast.fail.percent 配置节点调用失败的比例,当达到这个比例后,BroadcastClusterInvoker 将不再调用其他节点,直接抛出异常。 broadcast.fail.percent 取值在 0~100 范围内。默认情况下当全部调用失败后,才会抛出异常。 broadcast.fail.percent 只是控制的当失败后是否继续调用其他节点,并不改变结果(任意一台报错则报错)。broadcast.fail.percent 参数 在 dubbo2.7.10 及以上版本生效
  • 设置方式 @reference(cluster = "broadcast", parameters = {"broadcast.fail.percent", "20"})

集群模式配置

<dubbo:service cluster="failsafe" />

或者

<dubbo:reference cluster="failsafe" />

5.配置管理

Dubbo 的动态配置能力,主要分为几大类: 启动阶段配置项、服务治理规则、动态配置项

5.1 启动阶段配置项

Dubbo启动时读取的配置项,用于初始化各个组件,不会监听这些配置项的变化。

常用配置组件

  • application: Dubbo应用配置
  • registry: 注册中心
  • protocol: 服务提供者RPC协议
  • config-center: 配置中心
  • metadata-report: 元数据中心
  • service: 服务提供者配置
  • reference: 远程服务引用配置
  • provider: service的默认配置或分组配置
  • consumer: reference的默认配置或分组配置
  • module: 模块配置
  • monitor: 监控配置
  • metrics: 指标配置
  • ssl: SSL/TLS配置

配置来源

Dubbo框架的配置项比较繁多,为了更好地管理各种配置,将其按照用途划分为不同的组件,最终所有配置项都会汇聚到URL中,传递给后续处理模块

从Dubbo支持的配置来源说起,默认有6种配置来源

  • JVM System Properties,JVM -D 参数
  • System environment,JVM进程的环境变量
  • Externalized Configuration,外部化配置,从配置中心读取
  • Application Configuration,应用的属性配置,从Spring应用的Environment中提取"dubbo"打头的属性集
  • API / XML/注解等编程接口采集的配置可以被理解成配置来源的一种,是直接面向用户编程的配置采集方式
  • classpath读取配置文件 dubbo.properties

配置覆盖关系如下图:
Apache Dubbo(概念篇)_第6张图片

配置方式

  • API配置 (以Java编码的方式组织配置,包括Raw API和Bootstrap API)
  • XML配置 (以XML方式配置各种组件,支持与Spring无缝集成)
  • Annotation配置 (以注解方式暴露服务和引用服务接口,支持与Spring无缝集成)
  • 属性配置 (根据属性Key-value生成配置组件,类似SpringBoot的ConfigurationProperties。另一个重要特性是属性覆盖)
  • 外部化配置(目的之一是实现配置的集中式管理)
5.2 服务治理规则

服务治理规则主要作用是改变运行时服务的行为和选址逻辑,达到限流,权重配置等目的,包括覆盖规则、标签路由、条件路由。

Dubbo启动后监听服务治理相关的配置项,当配置发生变化时,会自动进行相应的处理。

服务治理规则的用法介绍请参考 服务治理和配置管理

服务治理规则的存储方法请参考 官方文档:配置中心#服务治理

5.3 动态配置项

动态配置项一般用于控制动态开关。
Dubbo启动后监听动态配置项,当配置发生变化时,会自动进行相应的处理。

动态配置的存储方式请参考 配置中心#动态配置

你可能感兴趣的:(分布式架构,apache,rpc,dubbo,分布式)