流量管控 on Apache Dubbo

示例应用架构

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

此任务基于一个简单的线上商城微服务系统演示了 Dubbo 的流量管控能力。

注意

本示例展示的所有能力均基于 Dubbo 路由规则实现，如想了解具体工作原理可查看详情。

线上商城的架构图如下：

系统由 5 个微服务应用组成：

Frontend 商城主页，作为与用户交互的 web 界面，通过调用 User、Detail、Order 等提供用户登录、商品展示和订单管理等服务。
User 用户服务，负责用户数据管理、身份校验等。
Order 订单服务，提供订订单创建、订单查询等服务，依赖 Detail 服务校验商品库存等信息。
Detail 商品详情服务，展示商品详情信息，调用 Comment 服务展示用户对商品的评论记录。
Comment 评论服务，管理用户对商品的评论数据。

部署商场系统

为方便起见，我们将整个系统部署在 Kubernetes 集群，执行以下命令即可完成商城项目部署，项目源码示例在 dubbo-samples/task。

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/10-task/dubbo-samples-shop/deploy/All.yml

完整的部署架构图如下：

Order 订单服务有两个版本 v1 和 v2，v2 是订单服务优化后发布的新版本。

版本 v1 只是简单的创建订单，不展示订单详情
版本 v2 在订单创建成功后会展示订单的收货地址详情

Detail 和 Comment 服务也分别有两个版本 v1 和 v2，我们通过多个版本来演示流量导流后的效果。

版本 v1 默认为所有请求提供服务
版本 v2 模拟被部署在特定的区域的服务，因此 v2 实例会带有特定的标签

执行以下命令，确定所有服务、Pod都已正常运行：

$ kubectl get services -n dubbo-demo

$ kubectl get pods -n dubbo-demo

为了保障系统完整性，除了商城相关的几个微服务应用，示例还在后台拉起了 Nacos 注册配置中心、Dubbo Admin 控制台和 Skywalking 全链路追踪系统。

动态调整服务超时时间

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

Dubbo 提供动态调整服务超时时间的能力，在无需重启应用的情况下调整服务的超时时间，这对于临时解决一些服务上下游依赖不稳定而导致的调用失败问题非常有效。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

商城项目通过 org.apache.dubbo.samples.UserService 提供用户信息管理服务，访问 http://localhost:8080/ 打开商城并输入任意账号密码，点击 Login 即可以正常登录到系统。

有些场景下，User 服务的运行速度会变慢，比如存储用户数据的数据库负载过高导致查询变慢，这时就会出现 UserService 访问超时的情况，导致登录失败。

在示例系统中，可通过下图 Timeout Login 模拟突发的 UserService 访问超时异常

通过规则动态调整超时时间

为了解决突发的登录超时问题，我们只需要适当增加 UserService 服务调用的等待时间即可。

操作步骤

打开 Dubbo Admin 控制台
在左侧导航栏选择【服务治理】>【动态配置】
点击 “创建”，输入服务 org.apache.dubbo.samples.UserService 和新的超时时间如 2000 即可。

保存后，再次点击 Timeout Login，此时在经过短暂的等待后系统可以正常登录。

规则详解

规则 key ：org.apache.dubbo.samples.UserService

规则体

configVersion: v3.0
enabled: true
configs:
 - side: provider
 parameters:
 timeout: 2000

从 UserService 服务提供者视角，将超时时间总体调整为 2s。

通过重试提高服务调用成功率

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

在服务初次调用失败后，通过重试能有效的提升总体调用成功率。但也要注意重试可能带来的响应时间增长，系统负载升高等，另外，重试一般适用于只读服务，或者具有幂等性保证的写服务。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

成功登录商城项目后，商城会默认在首页展示当前登录用户的详细信息。

但有些时候，提供用户详情的 Dubbo 服务也会由于网络不稳定等各种原因变的不稳定，比如我们提供用户详情的 User 服务就很大概率会调用失败，导致用户无法看到账户的详细信息。

用户账户详情查询失败后的系统界面如下：

商城为了获得带来更好的使用体验，用户信息的加载过程是异步的，因此用户信息加载失败并不会影响对整个商城页面的正常访问，但如果能始终展示完整的用户信息总能给使用者留下更好的印象。

增加重试提高成功率

考虑到访问用户详情的过程是异步的（隐藏在页面加载背后），只要最终数据能加载出来，适当的增加等待时间并不是大的问题。因此，我们可以考虑通过对每次用户访问增加重试次数的方式，提高服务详情服务的整体访问成功率。

操作步骤

打开 Dubbo Admin 控制台
在左侧导航栏选择【服务治理】>【动态配置】
点击 “创建”，输入服务 org.apache.dubbo.samples.UserService 和失败重试次数如 4 即可。

保存后，尝试多次刷新页面，发现用户详情数据总是能正常显示，虽然有时由于重试的缘故加载时间会明显变长。

规则详解

规则 key ：org.apache.dubbo.samples.UserService

规则体

configVersion: v3.0
enabled: true
configs:
 - side: consumer
 parameters:
 retries: 5

从 UserService 服务消费者视角（即 Frontend 应用）增加了调用失败后的重试次数。

parameters:
 retries: 5

side: consumer 配置会将规则发送到服务消费方实例，所有 UserService 服务实例会基于新的 timeout 值进行重新发布，并通过注册中心通知给所有消费方。

清理

为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的重试规则。

通过动态开启访问日志跟踪服务调用情况

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

访问日志可以很好的记录某台机器在某段时间内处理的所有服务请求信息，包括请求接收时间、远端 IP、请求参数、响应结果等，运行态动态的开启访问日志对于排查问题非常有帮助。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

商城的所有用户服务都由 User 应用的 UserService 提供，通过这个任务，我们为 User 应用的某一台或几台机器开启访问日志，以便观察用户服务的整体访问情况。

动态开启访问日志

Dubbo 通过 accesslog 标记识别访问日志的开启状态，我们可以指定日志文件的输出位置，也可以单独打开某台机器的访问日志。

操作步骤

打开 Dubbo Admin 控制台
在左侧导航栏选择【服务治理】>【动态配置】
点击 “创建”，输入应用名 shop-user 并勾选 “开启访问日志”（此时访问日志将和普通日志打印在一起）。

再次访问登录页面，登录到 User 应用的任意一台机器，可以看到如下格式的访问日志。

[2022-12-30 12:36:31.15900] -> [2022-12-30 12:36:31.16000] 192.168.0.103:60943 -> 192.168.0.103:20884 - org.apache.dubbo.samples.UserService login(java.lang.String,java.lang.String) ["test",""], dubbo version: 3.2.0-beta.4-SNAPSHOT, current host: 192.168.0.103
[2022-12-30 12:36:33.95900] -> [2022-12-30 12:36:33.95900] 192.168.0.103:60943 -> 192.168.0.103:20884 - org.apache.dubbo.samples.UserService getInfo(java.lang.String) ["test"], dubbo version: 3.2.0-beta.4-SNAPSHOT, current host: 192.168.0.103
[2022-12-30 12:36:31.93500] -> [2022-12-30 12:36:34.93600] 192.168.0.103:60943 -> 192.168.0.103:20884 - org.apache.dubbo.samples.UserService getInfo(java.lang.String) ["test"], dubbo version: 3.2.0-beta.4-SNAPSHOT, current host: 192.168.0.103

规则详解

规则 key ： shop-user

同机房/区域优先

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

为了保证服务的整体高可用，我们经常会采用把服务部署在多个可用区(机房)的策略，通过这样的冗余/容灾部署模式，当一个区域出现故障的时候，我们仍可以保证服务整体的可用性。

当应用部署在多个不同机房/区域的时候，应用之间相互调用就会出现跨区域的情况，而跨区域调用会增加响应时间，影响用户体验。同机房/区域优先是指应用调用服务时，优先调用同机房/区域的服务提供者，避免了跨区域带来的网络延时，从而减少了调用的响应时间。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

Detail 应用和 Comment 应用都有双区域部署，其中 Detail v1 与 Comment v1 部署在区域 Beijing，Detail v2 与 Comment v2 部署在区域 Hangzhou 区域。为了保证服务调用的响应速度，我们需要增加同区域优先的调用规则，确保 Beijing 区域内的 Detail v1 始终默认调用 Comment v1，Hangzhou 区域内的 Detail v2 始终调用 Comment v2。

当同区域内的服务出现故障或不可用时，则允许跨区域调用。

配置 `Detail` 访问同区域部署的 `Comment` 服务

正常登录商城系统后，首页默认展示商品详情信息，多次刷新页面，发现商品详情 (description) 与评论 (comment) 选项会出现多个不同版本的组合，结合上面 Detail 和 Comment 的部署结构，这说明服务调用并没有遵循同区域优先的原则。

因此，接下来我们需要添加同区域优先规则，保证：

hangzhou 区域的 Detail 服务调用同区域的 Comment 服务，即 description v1 与 comment v1 始终组合展示
beijing 区域的 Detail 服务调用同区域的 Comment 服务，即 description v2 与 comment v2 始终组合展示

操作步骤

登录 Dubbo Admin 控制台
在左侧导航栏选择【服务治理】 > 【条件路由】。
点击 “创建” 按钮，填入要启用同区域优先的服务如 org.apache.dubbo.samples.CommentService 与 区域标识 如 region 即可。

通过标签实现流量隔离环境（灰度、多套开发环境等）

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

无论是在日常开发测试环境，还是在预发生产环境，我们经常都会遇到流量隔离环境的需求。

在日常开发中，为了避免开发测试过程中互相干扰，我们有搭建多套独立测试环境的需求，但通过搭建物理集群的方式成本非常高且不够灵活
在生产发布过程中，为了保障新版本得到充分的验证，我们需要搭建一套完全隔离的线上灰度环境用来部署新版本服务，线上灰度环境能完全模拟生产运行情况，但只有固定的带有特定标记的线上流量会被导流到灰度环境，充分验证新版本的同时将线上变更风险降到最低。

利用 Dubbo 提供的标签路由能力，可以非常灵活的实现流量隔离能力。可以单独为集群中的某一个或多个应用划分隔离环境，也可以为整个微服务集群划分隔离环境；可以在部署态静态的标记隔离环境，也可以在运行态通过规则动态的隔离出一部分机器环境。

注意：标签路由是一套严格隔离的流量体系，对于同一个应用而言，一旦打了标签则这部分地址子集就被隔离出来，只有带有对应标签的请求流量可以访问这个地址子集，这部分地址不再接收没有标签或者具有不同标签的流量。举个例子，如果我们将一个应用进行打标，打标后划分为 tag-a、tag-b、无 tag 三个地址子集，则访问这个应用的流量，要么路由到 tag-a (当请求上下文 dubbo.tag=tag-a)，要么路由到 tag-b (dubbo.tag=tag-b)，或者路由到无 tag 的地址子集 (dubbo.tag 未设置)，不会出现混调的情况。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

我们决定为商城系统建立一套完整的线上灰度验证环境，灰度环境和线上环境共享一套物理集群，需要我们通过 Dubbo 标签路由从逻辑上完全隔离出一套环境，做到灰度流量和线上流量互不干扰。

为商城搭建一套完全隔离的灰度环境

首先，为 User、Detail、Comment、Order 几个应用都部署灰度环境实例，我们为这部分实例都带有 env=gray 的环境标。部署可以通过以下命令快速完成

kubectl apply -f https://raw.githubusercontent.com/apache/dubbo-samples/master/10-task/dubbo-samples-shop/deploy/Gray.yml

如何为机器或实例打标？

方法一：通过 dubbo.labels 或 DUBBO_LABELS 指定需要增加到 URL 中的键值对。

# JVM 参数
-Ddubbo.labels = "tag1=value1; tag2=value2"

# 环境变量
DUBBO_LABELS = "tag1=value1; tag2=value2"

最终生成的 URL 会包含 tag1、tag2 两个 key: dubbo://xxx?tag1=value1&tag2=value2

方法二：通过 dubbo.env.keys 或 DUBBO_ENV_KEYS 指定要加载的环境变量，Dubbo 会尝试从环境变量加载每个 key。

基于条件的流量路由

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

路由是 Dubbo 中的核心流量管控机制，我们可以基于它实现金丝雀发布、按比例流量转发、同区域优先、全链路灰度等流量策略。Dubbo 中路由（Router）机制的设计与基本原理，内置的几种路由规则

常用流量管控场景

Dubbo 内置的流量策略非常的灵活，但同时也有一定的理解与使用成本，因此，我们根据总结了一些常用的使用场景，并给出了配置方法：

场景	效果	作用对象	说明
超时时间
访问日志
调用重试

接下来，我们就以一个条件路由为例，来看一下如何使用 Dubbo 流量管控机制。

一个条件路由示例

需求非常的直观明了。

匹配这个条件的流量，转发到这一批机器
匹配另一个条件的流量，转发到另一批机器

画一张流量匹配和转发的图

这在 Dubbo 中就是用条件路由来实现的，关于其详细工作原理我们在介绍中有详细讲解。在以上示例中，xxx 代表；yyy 代表

我们需要把规则下发到运行中的dubbo sdk，在 dubbo 体系中这是如下如下工作的。

路由规则的分发与生效原理图

一个 zk/nacos、下发一条规则，dubbo实例接收到规则推送，rpc调用过程中应用规则筛选，选出地址子集调用

注意

传统 Nacos/Zookeeper 的微服务部署方案中，Dubbo 的路由规则配置中心存储并转发到 Dubbo SDK，而在 Kubernetes Service 或服务网格场景下，路由规则的存储与推送机制会有一些变化，具体请参考 Kubernetes 最佳实践。

这时，如果我们对 xxx 服务发送一个请求，

根据请求参数引导流量分布

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

根据请求参数值转发流量，是一种非常灵活且实用的流量管控策略。比如微服务实践中，根据参数（如用户 ID）路由流量，将一小部分用户请求转发到最新发布的产品版本，以验证新版本的稳定性、获取用户的产品体验反馈等，是生产实践中常用的一种有效的灰度机制。

或者，有些产品提供差异化的付费服务，需要根据请求参数中的用户 ID 将请求路由到具有不同服务等级保障的集群，就像接下来我们在示例任务中所做的那样。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

为了增加用户粘性，我们为商城示例系统新增了 VIP 用户服务，现在商城有两类用户：普通用户和 VIP 用户，其中 VIP 用户可以看到比普通用户更低的商品价格。

回到商城登录页面，我们以 VIP 用户 dubbo 登录系统，是否看到如下图所示的 VIP 专属商品价格，多刷新几次商品页面那？

哦，是不是价格忽高忽低？！这是因为在当前部署的示例系统中，只有 detail v2 版本才能识别 VIP 用户并提供特价服务，因此，我们要确保 dubbo 用户始终访问 detail v2 实例，以便享受稳定的 VIP 服务。

为 VIP 用户提供稳定的特价商品服务

Detail v2 版本能够识别 VIP 用户并在商品详情中展示特价。商品详情服务由 Detail 应用中的 org.apache.dubbo.samples.DetailService 服务提供，DetailService 显示商品详情的 getItem 方法定义如下，第二个参数为用户名。

public interface DetailService {
 Item getItem(long sku, String username);
}

因此，接下来我们就为 DetailService 服务的 getItem 方法增加参数路由规则，如果用户参数是 dubbo 就转发到 v2 版本的服务。

基于权重值的比例流量转发

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

Dubbo 提供了基于权重的负载均衡算法，可以实现按比例的流量分布：权重高的提供者机器收到更多的请求流量，而权重低的机器收到相对更少的流量。

以基于权重的流量调度算法为基础，通过规则动态调整单个或一组机器的权重，可以在运行态改变请求流量的分布，实现动态的按比例的流量路由，这对于一些典型场景非常有用。

当某一组机器负载过高，通过动态调低权重可有效减少新请求流入，改善整体成功率的同时给高负载机器提供喘息之机。
刚刚发布的新版本服务，先通过赋予新版本低权重控制少量比例的流量进入，待验证运行稳定后恢复正常权重，并完全替换老版本。
服务多区域部署或非对等部署时，通过高、低权重的设置，控制不同部署区域的流量比例。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

示例项目中，我们发布了 Order 服务 v2 版本，并在 v2 版本中优化了下单体验：用户订单创建完成后，显示订单收货地址信息。

现在如果你体验疯狂下单 (不停的点击 “Buy Now”)，会发现 v1 与 v2 总体上是 50% 概率出现，说明两者目前具有相同的默认权重。但我们为了保证商城系统整体稳定性，接下来会先控制引导 20% 流量到 v2 版本，80% 流量依然访问 v1 版本。

实现 Order 服务 80% v1 、20% v2 的流量分布

在调整权重前，首先我们要知道 Dubbo 实例的权重 (weight) 都是绝对值，每个实例的默认权重 (weight) 是 100。举个例子，如果一个服务部署有两个实例：实例 A 权重值为 100，实例 B 权重值为 200，则 A 和 B 收到的流量分布为 1:2。

接下来，我们就开始调整订单服务访问 v1 和 v2 的流量比例，订单创建服务由 org.apache.dubbo.samples.OrderService 接口提供，接下来通过动态规则调整新版本 OrderService 实例的权重值。

在大促之前对弱依赖调用进行服务降级

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

由于微服务系统的分布式特性，一个服务往往需要依赖非常多的外部服务来实现某一项功能，因此，一个服务的稳定性不但取决于其自身，同时还取决于所有外部依赖的稳定性。我们可以根据这些依赖的重要程度将它们划分为强依赖和弱依赖：强依赖是指那些无论如何都要保证稳定性的服务，如果它们不可用则当前服务也就不可用；弱依赖项指当它们不可用之后当前服务仍能正常工作的依赖项，弱依赖不可用只是影响功能的部分完整性。

服务降级的核心目标就是针对这些弱依赖项。在弱依赖不可用或调用失败时，通过返回降级结果尽可能的维持功能完整性；另外，我们有时也会主动的屏蔽一些非关键弱依赖项的调用，比如在大促流量洪峰之前，通过预先设置一些有效的降级策略来短路部分依赖调用，来有效的提升流量高峰时期系统的整体效率和稳定性。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

正常情况下，商品详情页会展示来自顾客的商品评论信息。

评论信息的缺失在很多时候并不会影响用户浏览和购买商品，因此，我们定义评论信息属于商品详情页面的弱依赖。接下来，我们就模拟在大促前夕常用的一个策略，通过服务降级提前关闭商品详情页对于评论服务的调用（返回一些本地预先准备好的历史评论数据），来降低集群整体负载水位并提高响应速度。

通过降级规则短路 Comment 评论服务调用

评论数据由 Comment 应用的 org.apache.dubbo.samples.CommentService 服务提供，接下来我们就为 CommentService 配置降级规则。

操作步骤

打开 Dubbo Admin 控制台
在左侧导航栏选择【流量管控】>【服务降级】
点击 “创建”，输入服务 org.apache.dubbo.samples.CommentService 和降级规则。

等待降级规则推送完成之后，刷新商品详情页面，发现商品评论信息已经变为我们预先设置的 “Mock Comment”，因为商品详情页的 Comment 服务调用已经在本地短路，并没有真正的发送到后端服务提供者机器上。

再次刷新页面

规则详解

规则 key ：org.apache.dubbo.samples.CommentService

规则体

configVersion: v3.0
enabled: true
configs:
 - side: consumer
 parameters:
 mock: force:return Mock Comment

清理

为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的降级规则。

其他事项

服务降级功能也可以用于开发测试环境，由于微服务分布式的特点，不同的服务或应用之间都有相互依赖关系，因此，一个服务或应用很难不依赖其他服务而独立部署工作。但测试环境下并不是所有服务都是随时就绪的状态，这对于微服务强调的服务独立演进是一个很大的障碍，通过服务降级这个功能，我们可以模拟或短路应用对其他服务的依赖，从而可以让应用按照自己预期的行为 Mock 外部服务调用的返回结果。具体可参见 Dubbo Admin 服务 Mock 特性的使用方式。

将流量点对点引导到一台机器 (如排查问题)

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

自动的地址发现和负载均衡机制有很多优势，它让我们构建可伸缩的分布式微服务系统成为可能，但这种动态的流量分配也带来很多复杂性。一个典型问题是我们无法再预测一次请求具体会落到那一台提供者机器上，但有时能预期或控制请求固定的发往某一台提供者机器在一些场景下会非常有用处，比如当开发者在测试甚至线上环境排查一些复杂问题时，如果能在某一台指定的机器上稳定复现问题现象，对于最终的问题排查肯定会带来很大帮助。

开始之前

部署 Shop 商城项目
部署并打开 Dubbo Admin

任务详情

本任务我们将以 User 服务作为示例，将商城中 Frontend 应用对用户详情方法的调用 UserService#getInfo 全部导流到一台固定实例上去。

将用户详情服务调用导流到一台固定机器

首先，确定部署 User 应用的实际机器列表

$ kubectl get pods -n dubbo-demo
# list result here

为 org.apache.dubbo.samples.UserService 服务的 getInfo 方法调用设置条件路由规则，所有这个方法的调用全部转发到一台指定机器。

操作步骤

打开 Dubbo Admin 控制台
在左侧导航栏选择【服务治理】>【条件路由】
点击 “创建”，输入服务 org.apache.dubbo.samples.UserService 。

打开机器日志，刷新页面多触发机器用户详情服务调用，可以看到只有规则中指定的实例中在持续刷新以下日志：

Received getInfo request......

规则详解

规则 key ：org.apache.dubbo.samples.UserService

规则体

configVersion: v3.0
enabled: true
force: false
conditions:
 - 'method=getInfo => host = {your ip address}'

替换 {your ip address} 为 User 实际的部署地址。

流量管控 on Apache Dubbo

示例应用架构

注意

部署商场系统

动态调整服务超时时间

开始之前

任务详情

通过规则动态调整超时时间

操作步骤

规则详解

通过重试提高服务调用成功率

开始之前

任务详情

增加重试提高成功率

操作步骤

规则详解

清理

通过动态开启访问日志跟踪服务调用情况

开始之前

任务详情

动态开启访问日志

操作步骤

规则详解

同机房/区域优先

开始之前

任务详情

配置 Detail 访问同区域部署的 Comment 服务

操作步骤

通过标签实现流量隔离环境（灰度、多套开发环境等）

开始之前

任务详情

为商城搭建一套完全隔离的灰度环境

如何为机器或实例打标？

基于条件的流量路由

常用流量管控场景

一个条件路由示例

注意

根据请求参数引导流量分布

开始之前

任务详情

为 VIP 用户提供稳定的特价商品服务

基于权重值的比例流量转发

开始之前

任务详情

实现 Order 服务 80% v1 、20% v2 的流量分布

在大促之前对弱依赖调用进行服务降级

开始之前

任务详情

通过降级规则短路 Comment 评论服务调用

操作步骤

规则详解

清理

其他事项

将流量点对点引导到一台机器 (如排查问题)

开始之前

任务详情

将用户详情服务调用导流到一台固定机器

操作步骤

规则详解

配置 `Detail` 访问同区域部署的 `Comment` 服务