流量管控 on Apache Dubbo

Dubbo 路由（router）机制及其如何实现流量管控介绍

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo 提供了丰富的流量管控策略

地址发现与负载均衡，地址发现支持服务实例动态上下线，负载均衡确保流量均匀的分布到每个实例上。
基于路由规则的流量管控，路由规则对每次请求进行条件匹配，并将符合条件的请求路由到特定的地址子集。

服务发现保证调用方看到最新的提供方实例地址，服务发现机制依赖注册中心 (Zookeeper、Nacos、Istio 等) 实现。在消费端，Dubbo 提供了多种负载均衡策略，如随机负载均衡策略、一致性哈希负载、基于权重的轮询、最小活跃度优先、P2C 等。

Dubbo 的流量管控规则可以基于应用、服务、方法、参数等粒度精准的控制流量走向，根据请求的目标服务、方法以及请求体中的其他附加参数进行匹配，符合匹配条件的流量会进一步的按照特定规则转发到一个地址子集。流量管控规则有以下几种：

条件路由规则
标签路由规则
脚本路由规则
动态配置规则

如果底层用的是基于 HTTP 的 RPC 协议 (如 REST、gRPC、Triple 等)，则服务和方法等就统一映射为 HTTP 路径 (path)，此时 Dubbo 路由规则相当于是基于 HTTP path 和 headers 的流量分发机制。

Dubbo 中有应用、服务和方法的概念，一个应用可以发布多个服务，一个服务包含多个可被调用的方法，从抽象的视角来看，一次 Dubbo 调用就是某个消费方应用发起了对某个提供方应用内的某个服务特定方法的调用，Dubbo 的流量管控规则可以基于应用、服务、方法、参数等粒度精准的控制流量走向。

Router工作原理

以下是 Dubbo 单个路由器的工作过程，路由器接收一个服务的实例地址集合作为输入，基于请求上下文 (Request Context) 和 (Router Rule) 实际的路由规则定义对输入地址进行匹配，所有匹配成功的实例组成一个地址子集，最终地址子集作为输出结果继续交给下一个路由器或者负载均衡组件处理。

通常，在 Dubbo 中，多个路由器组成一条路由链共同协作，前一个路由器的输出作为另一个路由器的输入，经过层层路由规则筛选后，最终生成有效的地址集合。

Dubbo 中的每个服务都有一条完全独立的路由链，每个服务的路由链组成可能不通，处理的规则各异，各个服务间互不影响。
对单条路由链而言，即使每次输入的地址集合相同，根据每次请求上下文的不同，生成的地址子集结果也可能不同。

路由规则分类

标签路由规则

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

标签路由规则是一个非此即彼的流量隔离方案，也就是匹配标签的请求会 100% 转发到有相同标签的实例，没有匹配标签的请求会 100% 转发到其余未匹配的实例。如果您需要按比例的流量调度方案，请参考示例基于权重的按比例流量路由。

标签主要是指对 Provider 端应用实例的分组，目前有两种方式可以完成实例分组，分别是动态规则打标和静态规则打标。动态规则打标 可以在运行时动态的圈住一组机器实例，而 静态规则打标 则需要实例重启后才能生效，其中，动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

条件路由规则

Mon, 01 Jan 0001 00:00:00 +0000

条件路由规则将符合特定条件的请求转发到特定的地址实例子集上。规则首先对发起流量的请求参数进行匹配，符合匹配条件的请求将被转发到包含特定实例地址列表的子集。

以下是一个条件路由规则示例。

基于以下示例规则，所有 org.apache.dubbo.samples.CommentService 服务 getComment 方法的调用都将被转发到有 region=Hangzhou 标记的地址子集。

configVersion: v3.0
scope: service
force: true
runtime: true
enabled: true
key: org.apache.dubbo.samples.CommentService
conditions:
 - method=getComment => region=Hangzhou

可以看具体的例子代码：条件路由

ConditionRule

条件路由规则主体。定义路由规则生效的目标服务或应用、流量过滤条件以及一些特定场景下的行为。

字段名	类型	描述	必填
configVersion	string	条件路由的版本，当前版本为 `v3.0`	是
scope	string	支持 `service` 和 `application` 两种规则	是
key	string	应用到的目标服务或应用程序的标识符 - 当 `scope:service` 时, `key`应该是该规则生效的服务名比如 org.apache.dubbo.samples.CommentService - 当 `scope:application` 时, then `key`应该是该规则应该生效的应用名称，比如说my-dubbo-service.	是
enabled	bool	规则是否生效当 `enabled:false` 时，规则不生效	是
conditions	string[]	配置中定义的条件规则，详情可以看条件规则	是
force	bool	T路由后实例子集为空时的行为。 `true` 则抛出一个No Provider Exception。 `false` 则忽略规则，直接去请求其他的实例。默认值是false	否
runtime	bool	是否为每个 rpc 调用运行路由规则或使用路由缓存（如果可用）。默认值是false（false则走缓存，true不走缓存）	否

Condition

Condition 为条件路由规则的主体，类型为一个复合结构的 string 字符串，如 method=getComment => region=Hangzhou。其中，

标签路由规则

Mon, 01 Jan 0001 00:00:00 +0000

标签路由通过将某一个服务的实例划分到不同的分组，约束具有特定标签的流量只能在指定分组中流转，不同分组为不同的流量场景服务，从而达到实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景能力的基础。目前有两种方式可以对实例打标，分别是动态规则打标和静态规则打标。动态规则打标 可以在运行时动态的圈住一组机器实例，而 静态规则打标 则需要实例重启后才能生效，其中，动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。

本文要讲的就是标签路由规则就是 动态规则打标。

标签路由是一套严格隔离的流量体系，对于同一个应用而言，一旦打了标签则这部分地址子集就被隔离出来，只有带有对应标签的请求流量可以访问这个地址子集，这部分地址不再接收没有标签或者具有不同标签的流量。

举个例子，如果我们将一个应用进行打标，打标后划分为 tag-a、tag-b、无 tag 三个地址子集，则访问这个应用的流量，要么路由到 tag-a (当请求上下文 dubbo.tag=tag-a)，要么路由到 tag-b (dubbo.tag=tag-b)，或者路由到无 tag 的地址子集 (dubbo.tag 未设置)，不会出现混调的情况。

标签路由的作用域是提供者应用，消费者应用无需配置标签路由规则。一个提供者应用内的所有服务只能有一条分组规则，不会有服务 A 使用一条路由规则、服务 B 使用另一条路由规则的情况出现。以下条件路由示例，在 shop-detail 应用中圈出了一个隔离环境 gray，gray 环境包含所有带有 env=gray 标识的机器实例。

configVersion: v3.0
force: true
enabled: true
key: shop-detail
tags:
 - name: gray
 match:
 - key: env
 value:
 exact: gray

TagRule

标签路由规则主体。定义路由规则生效的目标应用、标签分类规则以及一些特定场景下的行为。

Field	Type	Description	Required
configVersion	string	The version of the tag rule definition, currently available version is `v3.0`	Yes
key	string	The identifier of the target application that this rule is about to control	Yes
enabled	bool	Whether enable this rule or not, set `enabled:false` to disable this rule.	Yes
tags	Tag[]	The tag definition of this rule.	Yes
force	bool	The behaviour when the instance subset is empty after routing. `true` means return no provider exception while `false` means fallback to subset without any tags.	No
runtime	bool	Whether run routing rule for every rpc invocation or use routing cache if available.	No

Tag

标签定义，根据 match 条件筛选出一部分地址子集。

脚本路由规则

Mon, 01 Jan 0001 00:00:00 +0000

脚本路由为流量管理提供了最大的灵活性，所有流量在执行负载均衡选址之前，都会动态的执行一遍规则脚本，根据脚本执行的结果确定可用的地址子集。

脚本路由只对消费者生效且只支持应用粒度管理，因此， key 必须设置为消费者应用名；脚本语法支持多种，以 Dubbo Java SDK 为例，脚本语法支持 Javascript、Groovy、Kotlin 等，具体可参见每个语言实现的限制。

脚本路由由于可以动态加载远端代码执行，因此存在潜在的安全隐患，在启用脚本路由前，一定要确保脚本规则在安全沙箱内运行。

configVersion: v3.0
key: demo-provider
type: javascript
enabled: true
script: |
 (function route(invokers,invocation,context) {
 var result = new java.util.ArrayList(invokers.size());
 for (i = 0; i < invokers.size(); i ++) {
 if ("10.20.3.3".equals(invokers.get(i).getUrl().getHost())) {
 result.add(invokers.get(i));
 }
 }
 return result;
 } (invokers, invocation, context)); // 表示立即执行方法

ScriptRule

脚本路由规则主体。定义脚本规则生效的目标消费者应用、流量过滤脚本以及一些特定场景下的行为。

Field	Type	Description	Required
configVersion	string	The version of the script rule definition, currently available version is `v3.0`	Yes
key	string	The identifier of the target application that this rule is about to apply to.	Yes
type	string	The script language used to define `script`.	Yes
enabled	bool	Whether enable this rule or not, set `enabled:false` to disable this rule.	Yes
script	string	The script definition used to filter dubbo provider instances.	Yes
force	bool	The behaviour when the instance subset is empty after after routing. `true` means return no provider exception while `false` means ignore this rule.	No

Script

script 为脚本路由规则的主体，类型为一个具有符合结构的 string 字符串，具体取决于 type 指定的脚本语言。

动态配置规则

Mon, 01 Jan 0001 00:00:00 +0000

动态配置规则 (ConfigurationRule) 是 Dubbo 设计的在无需重启应用的情况下，动态调整 RPC 调用行为的一种能力，也称为动态覆盖规则，因为它是通过在运行态覆盖 Dubbo 实例或者 Dubbo 实例中 URL 地址的各种参数值，实现改变 RPC 调用行为的能力。

使用动态配置规则，有以下几条关键信息值得注意：

设置规则生效过滤条件。 配置规则支持一系列的过滤条件，用来限定规则只对符合特定条件的服务、应用或实例才生效。
设置规则生效范围。 一个 rpc 服务有服务发起方（消费者）和服务处理方（提供者）两个角色，对某一个服务定义的规则，可以具体到限制是对消费者还是提供者生效。
选择规则管理粒度。 Dubbo 支持从服务和应用两个粒度来管理和下发规则。

以下一个应用级别的配置示例，配置生效后，shop-detail 应用下提供的所有服务都将启用 accesslog，对 shop-detail 部署的所有实例生效。

configVersion: v3.0
scope: application
key: shop-detail
configs:
 - side: provider
 parameters:
 accesslog: 'true'

以下是一个服务级别的配置示例，key: org.apache.dubbo.samples.UserService 和 side: consumer 说明这条配置对所有正在消费 UserService 的 Dubbo 实例生效，在调用失败后都执行 4 次重试。match 条件进一步限制了消费端的范围，限定为只对应用名为 shop-frontend 的这个消费端应用生效。

configVersion: v3.0
scope: service
key: org.apache.dubbo.samples.UserService
configs:
 - match:
 application:
 oneof:
 - exact: shop-frontend
 side: consumer
 parameters:
 retries: '4'

ConfigurationRule

配置规则主体，定义要设置的目标服务或应用、具体的规则配置。具体配置规则 (configs) 可以设置多条。

限流 & 熔断

Mon, 01 Jan 0001 00:00:00 +0000

由于微服务分布式的特点，如何构建稳定的微服务集群是一个很大的挑战，其中有两项非常关键的点值得关注

流量控制 (Rate Limiting)
熔断降级 (Circuit Breaking)

流量控制

流量控制更多的是站在 Dubbo 服务提供者视角来保证服务稳定性，通过明确的为 Dubbo 服务设置请求上限阈值，确保服务所处理的请求数始终在一个合理范围之内，从而确保系统整体的稳定性。

根据服务的具体部署情况，服务所能处理的流量上限是一定的，当对服务的请求数量保持在合理的范围时，系统运行正常；而当请求数量严重超过服务处理能力时，如大促期间的流量洪峰等场景，就可能造成服务提供者端的资源过度消耗、负载过高，进而出现响应延迟、请求无应答、系统假死等情况。

流量控制解决的问题和工作方式比较容易理解，而其使用的难点就是如何确定服务所能处理的流量最大值？

一种模式是由用户预先设定一个固定的限流值，如 Dubbo 通过集成 Sentinel 等产品实现的限流能力即是这种模式
- Dubbo Sentinel 流量控制
另一种方式是 Dubbo 框架自动根据系统或集群负载情况执行限流，相比用户预先设置限流值更加灵活方便，Dubbo 目前内置了自适应限流模式，具体可参见：

熔断降级

熔断降级则是更多的从 Dubbo 服务消费者视角来保障系统稳定性的重要手段。一个服务往往需要调用更多的下游 Dubbo 服务来完成业务逻辑，这时下游服务的稳定性就会影响当前服务甚至整个系统的稳定性，熔断（Circuit Breaking）即是面向不稳定服务场景设计的，它能最大限度避免下游服务不稳定对上游服务带来的影响。

而相比于熔断后直接返回调用失败信息，配合服务降级能力，我们可以继续调用预先设置好的服务降级逻辑，以降级逻辑的结果作为最终调用结果，以更优雅的返回给服务调用方。

如上图所示，Dubbo Consumer 依赖的下游的三个 Dubbo 服务，当 Service 3 出现不稳定的情况时（如响应时间变长、错误率增加等），从而 Consumer 调用 Service 3 的线程等资源就会产生堆积，如果此时我们不在 Consumer 侧做任何限制，则 Service 1 与 Service 2 的调用都会受到稳定性影响。通过熔断 Service 3 我们就能保证整个 Dubbo Consumer 服务的稳定性，不拖垮整个 Consumer 服务，熔断 Service 3 的方式可以有很多种实现，包括线程数、信号量、错误率等。

Mesh 路由规则

Mon, 01 Jan 0001 00:00:00 +0000

Dubbo Mesh 路由规则是基于 Istio 的 VirtualService、DestinationRule 改造而来，总体思路和格式可以参考 Istio 流量管控规则参考手册：Istio VirtualService 和 Istio DestinationRule

本文描述了 Dubbo Mesh 路由规则的设计原理，以及它和 Istio 规则的差异等。参考链接：https://www.yuque.com/docs/share/c132d5db-0dcb-487f-8833-7c7732964bd4?#。

基本思想

基于路由链，采用Pipeline的处理方式，如下图所示：

可以把路由链的逻辑简单的理解为 target = rn(…r3(r2(r1(src))))。对于每一个 router 内部的逻辑，可以抽象为输入地址 addrs-in 与 router 中按全量地址 addrs-all 实现切分好的 n 个互不相交的地址池 addrs-pool-1 … addrs-pool-n 按实现定义好的规则取交集作为输出 addrs-out。以此类推，完成整个路由链的计算。

另外一方面，如果 router(n) 需要执行 fallback 逻辑的时候，那么需要经过 router(n) 就应该决定好 fallback 逻辑

fallback 处理原则

由于多个 router 之间多个条件组件之后，很容易出现地址被筛选为空的情况，那么我们需要针对这情况进行 fallback 处理，保证业务在正确性的前提下，能够顺利找到有效地址。

首先我们看一下以下规则

apiVersion: service.dubbo.apache.org/v1alpha1
kind: VirtualService
metadata:
 name: demo-route
spec:
 hosts:
 - demo // 统一定义为应用名
 dubbo:
 - service:
 - exact: com.taobao.hsf.demoService:1.0.0
 - exact: com.taobao.hsf.demoService:2.0.0
 routedetail:
 - name: sayHello-String-method-route
 match:
 - method:
 name_match:
 exact: "sayHello"
 .....
 argp:
 - string
 route:
 - destination:
 host: demo
 subset: v1
 fallback:
 destination:
 host: demo
 subset: v2
 fallback:
 destination:
 host: demo
 subset: v3

 - name: sayHello-method-route
 match:
 - method:
 name_match:
 exact: "s-method"
 route:
 - destination:
 host: demo
 subset: v2
 fallback:
 destination:
 host: demo
 subset: v3

 - name: interface-route
 route:
 - destination:
 host: demo
 subset: v3

 - service:

 ....
---
apiVersion: service.dubbo.apache.org/v1alpha1
kind: DestinationRule
metadata:
 name: demo-route
spec:
 host: demo
 subsets:
 - name: v1
 labels:
 sigma.ali/mg: v1-host

 - name: v2
 labels:
 sigma.ali/mg: v2-host

 - name: v3
 labels:
 sigma.ali/mg: v3-host

我们以脚本路由为例，这个脚本路由的匹配条件是遵循一个原则的，就是匹配的范围是从精确到广泛的一个过程，在这个示例来说，就是 sayHello(string)参数 -> sayHello 方法 -> 接口级路由的一个匹配查找过程。