dubbo（8）：高可用

╰半夏微凉° 2022-10-16 04:46 135阅读 0赞

# 一、Zookeeper宕机与dubbo直连 #

zookeeper注册中心宕机还可以消费dubbo暴露的服务。

原因：健壮性

*  监控中心宕掉不影响使用，只是丢失部分采样数据。
 *  数据库宕掉后，监控中心仍能通过缓存提供服务列表查询，但不能注册新服务。
 *  注册中心对等集群，任意一台宕掉后，将自动切换到另一台。
 *  注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通信。
 *  服务提供者无状态，任意一台宕掉后不影响使用。
 *  服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复。

高可用，通过设计减少系统不能提供服务的时间。也可以使用直连的方式绕过注册中心，直接连接服务提供者，使用url指向服务提供者地址。

@DubboReference(url="192.168.1.2:20080") // 去dubbo注册中心中寻找
        private UserService userService;

# 二、负载均衡机制 #

在集群负载均衡时，dubbo提供了多种均衡策略，缺省为Random随机调用。负载均衡策略：

*  Random LoadBalance：随机，按权重设置随机概率。在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
 *  RoundRobin LoadBalance：轮询，按公约后的权重设置轮询比率。可能会存在慢的提供者累积请求的问题，比如，第二台机器很慢，但没挂。当请求调用到第二台机器时就卡在那，久而久之，所有请求都卡在调用第二台机器上。
 *  Leastactive LoadBalance：自动感知策略。如果某个机器性能越差，那么接收的请求越少，越不活跃，此时就会给不活跃的性能差的机器分配更少的请求。
 *  ConsistantHash LoadBalance，一致性 Hash 算法。即相同参数的请求一定分发到一个provider。当provider挂掉的时候，会基于虚拟节点均匀分配剩余的流量，抖动不会太大。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 1][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 2][]

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 3][]

复制两份服务提供者，测试负载均衡。

![20210526201316457.png][]

启动3服务提供者和消费者。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 4][]

多次访问[http://localhost:8802/Order/initOrder/1][http_localhost_8802_Order_initOrder_1]查看

![20210526202452327.png][]

![20210526202537679.png][]

![20210526202547769.png][]

## 改变负载均衡机制 ##

官方文档中提供了4种配置方法，注解版则在相应的注解中配置，例如：@DubboReference(loadbalance = "roundrobin")

### 服务端服务级别 ###

<dubbo:service interface="..." loadbalance="roundrobin" />

### 客户端服务级别 ###

<dubbo:reference interface="..." loadbalance="roundrobin" />

### 服务端方法级别 ###

<dubbo:service interface="...">
        <dubbo:method name="..." loadbalance="roundrobin"/>
    </dubbo:service>

### 客户端方法级别 ###

<dubbo:reference interface="...">
        <dubbo:method name="..." loadbalance="roundrobin"/>
    </dubbo:reference>

服务器负载均衡策略一般根据不同情况做相应的调整，所以一般会在可视化界面进行调整。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 5][]

# 三、服务降级 #

降级 Dubbo 服务。可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。向注册中心写入动态配置覆盖规则：

RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
    Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
    registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));

其中：

*  `mock=force:return+null` 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
 *  还可以改为 `mock=fail:return+null` 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。

# 四、集群容错 #

集群调用失败时，Dubbo 提供的容错方案

在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 6][]

各节点关系：

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

## 集群容错模式 ##

可以自行扩展集群容错策略，参见：[集群扩展][Link 1]

### Failover Cluster ###

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

重试次数配置如下：

<dubbo:service retries="2" />

或

<dubbo:reference retries="2" />

或

<dubbo:reference>
        <dubbo:method name="findFoo" retries="2" />
    </dubbo:reference>

提示

该配置为缺省配置

### 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 及以上版本生效。

Broadcast Cluster 配置 broadcast.fail.percent。

broadcast.fail.percent=20 代表了当 20% 的节点调用失败就抛出异常，不再调用其他节点。

@reference(cluster = "broadcast", parameters = {"broadcast.fail.percent", "20"})

提示

`2.1.0` 开始支持

## 集群模式配置 ##

按照以下示例在服务提供方和消费方配置集群模式

<dubbo:service cluster="failsafe" />

或

<dubbo:reference cluster="failsafe" />

# 五、路由规则 #

通过 Dubbo 中的路由规则做服务治理

路由规则在发起一次RPC调用前起到过滤目标服务器地址的作用，过滤后的地址列表，将作为消费端最终发起RPC调用的备选地址。

*  条件路由。支持以服务或 Consumer 应用为粒度配置路由规则。
 *  标签路由。以 Provider 应用为粒度配置路由规则。

后续我们计划在 2.6.x 版本的基础上继续增强脚本路由功能。

## 条件路由 ##

您可以随时在服务治理控制台 [Dubbo-Admin][] 写入路由规则

### 简介 ###

*  应用粒度
    
        # app1的消费者只能消费所有端口为20880的服务实例
        # app2的消费者只能消费所有端口为20881的服务实例
        ---
        scope: application
        force: true
        runtime: true
        enabled: true
        key: governance-conditionrouter-consumer
        conditions:
          - application=app1 => address=*:20880
          - application=app2 => address=*:20881
        ...
 *  服务粒度
    
        # DemoService的sayHello方法只能消费所有端口为20880的服务实例
        # DemoService的sayHi方法只能消费所有端口为20881的服务实例
        ---
        scope: service
        force: true
        runtime: true
        enabled: true
        key: org.apache.dubbo.samples.governance.api.DemoService
        conditions:
          - method=sayHello => address=*:20880
          - method=sayHi => address=*:20881
        ...

### 规则详解 ###

各字段含义

*  `scope`表示路由规则的作用粒度，scope的取值会决定key的取值。**必填**。
    
     *  service 服务粒度
     *  application 应用粒度
 *  `Key`明确规则体作用在哪个服务或应用。**必填**。
    
     *  scope=service时，key取值为\[\{group\}:\]\{service\}\[:\{version\}\]的组合
     *  scope=application时，key取值为application名称
 *  `enabled=true` 当前路由规则是否生效，可不填，缺省生效。
 *  `force=false` 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 `false`。
 *  `runtime=false` 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 `true`，需要注意设置会影响调用的性能，可不填，缺省为 `false`。
 *  `priority=1` 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 `0`。
 *  `conditions` 定义具体的路由规则内容。**必填**。

Conditions规则体

`conditions`部分是规则的主体，由1到任意多条规则组成，下面我们就每个规则的配置语法做详细说明：

1.  **格式**

*  `=>` 之前的为消费者匹配条件，所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
 *  `=>` 之后为提供者地址列表的过滤条件，所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。
 *  如果匹配条件为空，表示对所有消费方应用，如：`=> host != 10.20.153.11`
 *  如果过滤条件为空，表示禁止访问，如：`host = 10.20.153.10 =>`

1.  **表达式**

参数支持：

*  服务调用信息，如：method, argument 等，暂不支持参数路由
 *  URL 本身的字段，如：protocol, host, port 等
 *  以及 URL 上的所有参数，如：application, organization 等

条件支持：

*  等号 `=` 表示"匹配"，如：`host = 10.20.153.10`
 *  不等号 `!=` 表示"不匹配"，如：`host != 10.20.153.10`

值支持：

*  以逗号 `,` 分隔多个值，如：`host != 10.20.153.10,10.20.153.11`
 *  以星号 `*` 结尾，表示通配，如：`host != 10.20.*`
 *  以美元符 `$` 开头，表示引用消费者参数，如：`host = $host`

1.  **Condition示例**

*  排除预发布机：

=> host != 172.22.3.91

*  白名单：

注意

一个服务只能有一条白名单规则，否则两条规则交叉，就都被筛选掉了

*  黑名单：

*  服务寄宿在应用上，只暴露一部分的机器，防止整个集群挂掉：

=> host = 172.22.3.1*,172.22.3.2*

*  为重要应用提供额外的机器：

application != kylin => host != 172.22.3.95,172.22.3.96

*  读写分离：

method = find*,list*,get*,is* => host = 172.22.3.94,172.22.3.95,172.22.3.96
    method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98

*  前后台分离：

application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93
    application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96

*  隔离不同机房网段：

host != 172.22.3.* => host != 172.22.3.*

*  提供者与消费者部署在同集群内，本机只访问本机的服务：

=> host = $host

## 标签路由规则 ##

### 简介 ###

标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。

Provider

标签主要是指对Provider端应用实例的分组，目前有两种方式可以完成实例分组，分别是`动态规则打标`和`静态规则打标`，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

*  动态规则打标，可随时在**服务治理控制台**下发标签归组规则
    
        # governance-tagrouter-provider应用增加了两个标签分组tag1和tag2
        # tag1包含一个实例 127.0.0.1:20880
        # tag2包含一个实例 127.0.0.1:20881
        ---
          force: false
          runtime: true
          enabled: true
          key: governance-tagrouter-provider
          tags:
            - name: tag1
              addresses: ["127.0.0.1:20880"]
            - name: tag2
              addresses: ["127.0.0.1:20881"]
         ...
 *  静态打标
    
        <dubbo:provider tag="tag1"/>
    
    or
    
        <dubbo:service tag="tag1"/>
    
    or
    
        java -jar xxx-provider.jar -Ddubbo.provider.tag={the tag you want, may come from OS ENV}

Consumer

RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"tag1");

请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。

> 目前仅仅支持 hardcoding 的方式设置 requestTag。注意到 RpcContext 是线程绑定的，优雅的使用 TagRouter 特性，建议通过 servlet 过滤器(在 web 环境下)，或者定制的 SPI 过滤器设置 requestTag。

### 规则详解 ###

格式

*  `Key`明确规则体作用到哪个应用。**必填**。
 *  `enabled=true` 当前路由规则是否生效，可不填，缺省生效。
 *  `force=false` 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 `false`。
 *  `runtime=false` 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 `true`，需要注意设置会影响调用的性能，可不填，缺省为 `false`。
 *  `priority=1` 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 `0`。
 *  `tags` 定义具体的标签分组内容，可定义任意n（n>=1）个标签并为每个标签指定实例列表。**必填**。
    
     *  name， 标签名称
 *  addresses， 当前标签包含的实例列表

降级约定

1.  `request.tag=tag1` 时优先选择 标记了`tag=tag1` 的 provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag为空的provider；如果要改变这种默认行为，即找不到匹配tag1的provider返回异常，需设置`request.tag.force=true`。
2.  `request.tag`未设置时，只会匹配tag为空的provider。即使集群中存在可用的服务，若 tag 不匹配也就无法调用，这与约定1不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。

提示

`2.6.x` 版本以及更早的版本请使用[老版本路由规则][Link 2]

自定义路由参考[路由扩展][Link 3]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70]: /images/20221014/81522785655440daaf5f0c2aa5762868.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 1]: /images/20221014/28e3b89f0f2142c7955475a68fe90873.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 2]: /images/20221014/66a7049cbdf245f485c1bccdca202ec6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 3]: /images/20221014/71538ed8224f4eb3b2db0d5e80a14033.png
[20210526201316457.png]: /images/20221014/9218dd85ed52471c8db3bfa8b3db2dab.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 4]: /images/20221014/005c9d58a25e42d1b607f7e2d6cc345b.png
[http_localhost_8802_Order_initOrder_1]: http://localhost:8802/Order/initOrder/1
[20210526202452327.png]: /images/20221014/e8137df66ebd471ea0cfeef26c4ae3b1.png
[20210526202537679.png]: /images/20221014/c206a814bff34f89bc4932cc66b10424.png
[20210526202547769.png]: /images/20221014/8ac6e94cfc4f4910a3da4d5f318f97c7.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 5]: /images/20221014/9defae008c3441f4a320e18f31697110.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzQwMjk4MzUx_size_16_color_FFFFFF_t_70 6]: /images/20221014/6a5973d1204a40c5b4aa15398bee7301.png
[Link 1]: https://dubbo.apache.org/zh/docs/v2.7/dev/impls/cluster
[Dubbo-Admin]: https://github.com/apache/dubbo-admin
[Link 2]: https://dubbo.apache.org/zh/docs/v2.7/user/examples/routing-rule-deprecated
[Link 3]: https://dubbo.apache.org/zh/docs/v2.7/dev/impls/router