This is an automated email from the ASF dual-hosted git repository.
albumenj pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new 5b8cd0a93ff 完善示例实践服务治理文档 (#1384)
5b8cd0a93ff is described below
commit 5b8cd0a93ff987b839a37252e5bc7bd8b344c985
Author: Trydamere <[email protected]>
AuthorDate: Sun Aug 14 10:51:55 2022 +0800
完善示例实践服务治理文档 (#1384)
* add traffic-gray
* add zone
---
.../zh/overview/tasks/traffic-management/_index.md | 18 +-
.../overview/tasks/traffic-management/isolation.md | 38 +--
.../overview/tasks/traffic-management/timeout.md | 35 +-
.../tasks/traffic-management/traffic-condition.md | 332 ++-----------------
.../tasks/traffic-management/traffic-gray.md | 353 ++++-----------------
.../tasks/traffic-management/traffic-routing.md | 333 +++----------------
.../zh/overview/tasks/traffic-management/weight.md | 33 +-
.../zh/overview/tasks/traffic-management/zone.md | 332 ++-----------------
8 files changed, 188 insertions(+), 1286 deletions(-)
diff --git a/content/zh/overview/tasks/traffic-management/_index.md
b/content/zh/overview/tasks/traffic-management/_index.md
index 7e95d194aa4..45a76d86d64 100755
--- a/content/zh/overview/tasks/traffic-management/_index.md
+++ b/content/zh/overview/tasks/traffic-management/_index.md
@@ -46,10 +46,9 @@ no_list: true
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
-<!-- <a href='{{< relref "./traffic-gray/" >}}'>流量灰度
(TBD)</a> -->
- <p>流量灰度 (文档建设中)</p>
+ <a href='{{< relref "./traffic-gray/" >}}'>流量灰度</a>
</h4>
- <p>根据请求上下文中的标签，实现对</p>
+ <p>根据请求上下文中的标签，实现对流量进行约束，实现灰度发布</p>
</div>
</div>
</div>
@@ -57,8 +56,7 @@ no_list: true
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
-<!-- <a href='{{< relref "./traffic-routing/" >}}'>请求路由
(TBD)</a> -->
- <p>根据请求条件路由 (文档建设中)</p>
+ <a href='{{< relref "./traffic-routing/" >}}'>根据请求条件路由</a>
</h4>
<p>根据请求发起方、请求的方法条件路由</p>
</div>
@@ -68,10 +66,9 @@ no_list: true
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
-<!-- <a href='{{< relref "./traffic-condition/" >}}'>流量隔离
(TBD)</a> -->
- <p>流量隔离 (文档建设中)</p>
+ <a href='{{< relref "./traffic-condition/" >}}'>流量隔离</a>
</h4>
- <p>流量隔离</p>
+ <p>将不同环境的服务流量进行隔离，保证服务相互不受影响</p>
</div>
</div>
</div>
@@ -79,10 +76,9 @@ no_list: true
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
-<!-- <a href='{{< relref "./zone/" >}}'>同机房/区域优先 (TBD)</a>
-->
- <p>同机房/区域优先 (文档建设中)</p>
+ <a href='{{< relref "./zone/" >}}'>同机房/区域优先</a>
</h4>
- <p>同机房/区域优先</p>
+ <p>应用调用服务时，优先调用同机房/区域的服务提供者。</p>
</div>
</div>
</div>
diff --git a/content/zh/overview/tasks/traffic-management/isolation.md
b/content/zh/overview/tasks/traffic-management/isolation.md
index d686b14353e..3a55ca7d6e8 100644
--- a/content/zh/overview/tasks/traffic-management/isolation.md
+++ b/content/zh/overview/tasks/traffic-management/isolation.md
@@ -9,43 +9,13 @@ description: "在 Dubbo-Admin 临时踢除问题服务实例"
Dubbo提供临时踢除问题服务实例的服务治理能力，可以在无需重启应用的情况下，临时踢除问题服务实例。
-Dubbo可以通过XML配置，注解配置，动态配置实现动态调整超时时间，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
+Dubbo可以通过XML配置，注解配置，动态配置实现临时踢除问题服务实例，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
## 开始之前
请确保成功运行Dubbo-Admin
-
-
-> **提示**
->
-> docker部署dubbo-admin，docker-compose.yml如下：
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-
-
## 背景信息
服务在线上运行的过程中，难免遇到某些节点有问题，为了不影响整体服务的正常运行，需要临时下线问题的服务实例。Dubbo-Admin提供了临时踢除问题服务实例能力，能够帮助您临时下线问题服务实例，不影响整体服务的运行。
@@ -54,15 +24,17 @@ Dubbo可以通过XML配置，注解配置，动态配置实现动态调整超时
## 操作步骤
+### 动态配置
+
1. 登录Dubbo-Admin控制台
2. 在左侧导航栏选择服务治理 > 动态配置。
3. 点击创建按钮，在创建动态配置面板中，填写规则内容，然后单击保存。
-## 规则详解
+#### 规则详解
-#### 配置模板
+##### 配置模板
```yaml
---
diff --git a/content/zh/overview/tasks/traffic-management/timeout.md
b/content/zh/overview/tasks/traffic-management/timeout.md
index 77499e8de00..b793b776ae5 100644
--- a/content/zh/overview/tasks/traffic-management/timeout.md
+++ b/content/zh/overview/tasks/traffic-management/timeout.md
@@ -16,35 +16,6 @@ Dubbo可以通过XML配置，注解配置，动态配置实现动态调整超时
请确保成功运行Dubbo-Admin
-
-
-> **提示**
->
-> docker部署dubbo-admin，docker-compose.yml如下：
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-
## 背景信息
在日常工作中会遇到各类超时配置，业务逻辑变更后，已有调用关系随着业务发展可能需要不断调整，相应服务接口响应时间的变化可能需要上线后才能确定。Dubbo-Admin提供了动态的超时配置能力，能够帮助您快速动态调整接口超时时间，提高服务的可用性。
@@ -53,15 +24,17 @@ Dubbo可以通过XML配置，注解配置，动态配置实现动态调整超时
## 操作步骤
+### 动态配置
+
1. 登录Dubbo-Admin控制台
2. 在左侧导航栏选择服务治理 > 动态配置。
3. 点击创建按钮，在创建动态配置面板中，填写规则内容，然后单击保存。
-## 规则详解
+#### 规则详解
-#### 配置模板
+##### 配置模板
```yaml
---
diff --git a/content/zh/overview/tasks/traffic-management/traffic-condition.md
b/content/zh/overview/tasks/traffic-management/traffic-condition.md
index 1fa46f9af13..e3d5e22d508 100644
--- a/content/zh/overview/tasks/traffic-management/traffic-condition.md
+++ b/content/zh/overview/tasks/traffic-management/traffic-condition.md
@@ -3,325 +3,61 @@ type: docs
title: "流量隔离"
linkTitle: "流量隔离"
weight: 5
-description: "在 Dubbo 中配置应用级治理规则和服务级治理规则"
-toc_hide: true
+description: "在 Dubbo-Admin 动态进行流量隔离"
---
-> **提示**
->
-> 本文描述的是新版本规则配置，而不是[老版本配置规则](/zh/docs/advanced/config-rule-deprecated)
-
-# 配置规则
-
-此任务将展示在 Dubbo 中配置应用级治理规则和服务级治理规则
-
-
-覆盖规则是 Dubbo 设计的在无需重启应用的情况下，动态调整 RPC 调用行为的一种能力。2.7.0
版本开始，支持从**服务**和**应用**两个粒度来调整动态配置。
-
+Dubbo提供动态流量隔离的服务治理能力，可以在无需重启应用的情况下，动态进行流量隔离。
+Dubbo可以通过XML配置，注解配置，动态配置实现流量隔离，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
## 开始之前
-- 安装idea
-
-- 克隆[dubbo-samples](https://github.com/apache/dubbo-samples.git)到本地，idea打开
-
-- 拉取dubbo-admin镜像并运行镜像
-
-
-
-
-> **提示**
->
-> 可参考如下步骤部署dubbo-admin
->
-> 1. 创建docker-compose.yml文件，内容如下:
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-> 2.运行命令
->
-> ```
-> docker-compose up
-> ```
-
-
-
-运行成功后，可以看见dubbo-admin界面
-
-
-
-
-
-## 概览
-
-
-
-dubbo-samples-governance示例包含dubbo-samples-applevel-override和dubbo-samples-servicelevel-override子示例，这2个子示例分别从**服务**和**应用**两个粒度应用覆盖规则动态调整路由。
-
-
-
-此任务的最初目标是应用覆盖规则在无需重启应用的情况下动态调整流量路由。稍后，您将从**服务**和**应用**两个粒度应用规则动态调整路由。
-
-
-
-下图展示本任务的应用端到端架构。
-
-
-
-
-
-### 应用粒度
-
-
-
-dubbo-samples-applevel-override示例中，BasicConsumer类和BascicProvider类为消费者类和提供者类，现在运行BasicProvider，成功后如图：
-
-
-
-
-
-在控制台查询服务，可以看到应用governance-appoverride-provider，如图：
-
-
-
-
-
-现在再运行一个提供者示例，运行在20881端口，首先修改dubbo-demo-provider.xml，将< dubbo:protocol
/>标签中端口修改修改为20881，运行BasicProvider，成功后查询控制台，如图：
-
-
-
-
-
+请确保成功运行Dubbo-Admin
-> **提示**
->
-> 如果运行BasicProvider示例失败，请修改BasicProvider配置，勾选Allow multiple instances
+## 背景信息
+如果一个应用有多个版本在线上同时运行，部署在不同环境中，如日常环境和特殊环境，则可以使用标签路由对不同环境中的不同版本进行流量隔离，将秒杀订单流量或不同渠道订单流量路由到特殊环境，将正常的流量路由到日常环境。即使特殊环境异常，本应进入特殊环境的流量也不会进入日常环境，不影响日常环境的使用。
-#### 任务1：临时剔除提供者
+## 操作步骤
-目前需要临时剔除在20880端口的提供者，可以使用覆盖规则进行动态配置。
+### 标签路由
-1.打开服务治理控制台，点击”创建“，填入应用名和配置，这个配置将禁用在20880端口上提供（side:provider）的所有服务（scope:application）。
+1. 登录Dubbo-Admin控制台
+2. 在左侧导航栏选择服务治理 > 标签路由。
+3. 点击创建按钮，在创建新标签规则面板中，填写规则内容，然后单击保存。
-```yaml
-configVersion: v2.7
-scope: application
-key: governance-appoverride-provider
-enabled: true
-configs:
-- addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- disabled: true
-```
-
-运行BasicConsumer，此时发现是运行在20881端口的提供者提供服务，说明覆盖规则生效。
-
-
-
-#### 任务2：评估系统容量
-
-目前需要对系统容量进行评估，进行调整权重。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整20880端口的提供者权重(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- weight: 1000
- ```
-
-多次运行BasicConsumer，发现运行在20880端口的提供者示例提供服务次数多于20881端口的提供者示例。
-
-
-
-#### 任务3：调整负载均衡策略
-
-目前需要调整负载均衡策略。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整负载均衡策略：(缺省负载均衡策略为 random)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ```
-
-Random策略按权重设置随机概率，多次运行BasicConsumer，BasicConsumer访问20880端口的概率大于访问20881端口的概率。
-
-
-
-### 服务粒度
-
-
-
-dubbo-samples-servicelevel-override示例与上面的示例类似，故不赘述。运行BasicProvider类。
+#### 规则详解
-
-
-#### 任务1：修改提供者服务的超时时间
-
-目前需要修改提供者服务的超时时间
-
-1.打开服务治理控制台，点击”创建“，填入服务名和配置，这个配置将所有消费（side:consumer）DemoService服务（org.apache.dubbo.samples.governance.api.DemoService）的应用实例（addresses:[0.0.0.0]），超时时间修改为300ms
-
-```yaml
-configVersion: v2.7
-scope: service
-key: org.apache.dubbo.samples.governance.api.DemoService
-enabled: true
-configs:
-- addresses: [0.0.0.0]
- side: consumer
- parameters:
- timeout: 300
-```
-
-运行BasicConsumer类，发现BasicConSumer抛异常无法调用远程方法，如图：
-
-
-
-
-
-## 规则详解
-
-#### 配置模板
+##### 配置模板
```yaml
---
-configVersion: v2.7
-scope: application/service
-key: app-name/group+service+version
-enabled: true
-configs:
-- addresses: ["0.0.0.0"]
- providerAddresses: ["1.1.1.1:20880", "2.2.2.2:20881"]
- side: consumer
- applications/services: []
- parameters:
- timeout: 1000
- loadbalance: random
-- addresses: ["0.0.0.0:20880"]
- side: provider
- applications/services: []
- parameters:
- threadpool: fixed
- threads: 200
- iothreads: 4
- dispatcher: all
- weight: 200
-...
+ 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"]
+ ...
```
-其中：
-
-- `configVersion` 表示 dubbo 的版本
-- `scope`表示配置作用范围，分别是应用（application）或服务（service）粒度。**必填**。
-- `key`指定规则体作用在哪个服务或应用。**必填**。
- - scope=service时，key取值为[{group}:]{service}[:{version}]的组合
- - scope=application时，key取值为application名称
+**对于流量隔离场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-- `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
-- `configs`定义具体的覆盖规则内容，可以指定n（n>=1）个规则体。**必填**。
- - side: 消费者端/提供者端
- - applications: 对应用覆盖规则
- - services: 对服务覆盖规则
- - parameters: 参数列表
- - addresses: 地址值
- - providerAddresses: 提供者地址值
-
-**对于绝大多数配置场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改整个应用的配置还是某个服务的配置。
+1. 要修改服务所属提供者应用的配置。
- 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- - 服务：`scope: service, key:group+service+version `。
-2. 修改是作用到消费者端还是提供者端。
- - 消费者：`side: consumer` ，作用到消费端时（你还可以进一步使用`providerAddress`,
`applications`选定特定的提供者示例或应用）。
- - 提供者：`side: provider`。
-3. 配置是否只对某几个特定实例生效。
+2. 当路由结果为空，是否强制返回。
+ - force=false: 当路由结果为空，降级请求tag为空的提供者。
+ - force=true: 当路由结果为空，直接返回异常。
+3. 路由规则的优先级
+ - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
+4. 配置是否只对某几个特定实例生效。
- 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- 指定实例：`addersses[实例地址列表]`。
-4. 要修改的属性是哪个。
-
-#### 示例
-
-1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- disabled: true
- ...
- ```
-
-2. 调整权重：(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- weight: 200
- ...
- ```
-
-3. 调整负载均衡策略：(缺省负载均衡策略为 random)
+5. 要修改的标签名。
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-consumer
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ...
- ```
+## 结果验证
+选择和流量隔离配置相关的应用，触发该调用验证。
diff --git a/content/zh/overview/tasks/traffic-management/traffic-gray.md
b/content/zh/overview/tasks/traffic-management/traffic-gray.md
index 0d2cd02ea75..eb93aeb737a 100644
--- a/content/zh/overview/tasks/traffic-management/traffic-gray.md
+++ b/content/zh/overview/tasks/traffic-management/traffic-gray.md
@@ -3,325 +3,102 @@ type: docs
title: "流量灰度"
linkTitle: "流量灰度"
weight: 5
-description: "在 Dubbo 中配置应用级治理规则和服务级治理规则"
-toc_hide: true
+description: "在 Dubbo-Admin 中配置标签路由规则实现灰度发布"
---
-> **提示**
->
-> 本文描述的是新版本规则配置，而不是[老版本配置规则](/zh/docs/advanced/config-rule-deprecated)
-
-# 配置规则
-
-此任务将展示在 Dubbo 中配置应用级治理规则和服务级治理规则
-
-
-覆盖规则是 Dubbo 设计的在无需重启应用的情况下，动态调整 RPC 调用行为的一种能力。2.7.0
版本开始，支持从**服务**和**应用**两个粒度来调整动态配置。
-
+Dubbo提供流量灰度的服务治理能力，可以在无需重启应用的情况下，配置标签路由规则和条件路由实现灰度发布。
+Dubbo可以通过XML配置，注解配置，动态配置实现流量灰度，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
## 开始之前
-- 安装idea
-
-- 克隆[dubbo-samples](https://github.com/apache/dubbo-samples.git)到本地，idea打开
-
-- 拉取dubbo-admin镜像并运行镜像
-
-
-
-
-> **提示**
->
-> 可参考如下步骤部署dubbo-admin
->
-> 1. 创建docker-compose.yml文件，内容如下:
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-> 2.运行命令
->
-> ```
-> docker-compose up
-> ```
-
-
-
-运行成功后，可以看见dubbo-admin界面
-
-
-
-
-
-## 概览
-
-
-
-dubbo-samples-governance示例包含dubbo-samples-applevel-override和dubbo-samples-servicelevel-override子示例，这2个子示例分别从**服务**和**应用**两个粒度应用覆盖规则动态调整路由。
-
-
-
-此任务的最初目标是应用覆盖规则在无需重启应用的情况下动态调整流量路由。稍后，您将从**服务**和**应用**两个粒度应用规则动态调整路由。
-
+请确保成功运行Dubbo-Admin
+## 背景信息
-下图展示本任务的应用端到端架构。
+在产品开发中会遇到需求变化、版本迭代的场景，为了兼顾需求变化和系统稳定，发布要尽可能平滑，影响人群要由少到多，一旦有问题马上回滚。Dubbo-Admin提供了动态的流量灰度能力，能够帮助您对新服务作标，服务平滑发布，提高服务的稳定和可用性。
-
+## 操作步骤
+### 条件路由
+1. 登录Dubbo-Admin控制台
+2. 在左侧导航栏选择服务治理 > 条件路由。
+3. 点击创建按钮，在创建新路由规则面板中，填写规则内容，然后单击保存。
-### 应用粒度
+#### 规则详解
-
-dubbo-samples-applevel-override示例中，BasicConsumer类和BascicProvider类为消费者类和提供者类，现在运行BasicProvider，成功后如图：
-
-
-
-
-
-在控制台查询服务，可以看到应用governance-appoverride-provider，如图：
-
-
-
-
-
-现在再运行一个提供者示例，运行在20881端口，首先修改dubbo-demo-provider.xml，将< dubbo:protocol
/>标签中端口修改修改为20881，运行BasicProvider，成功后查询控制台，如图：
-
-
-
-
-
-
-> **提示**
->
-> 如果运行BasicProvider示例失败，请修改BasicProvider配置，勾选Allow multiple instances
-
-
-
-#### 任务1：临时剔除提供者
-
-目前需要临时剔除在20880端口的提供者，可以使用覆盖规则进行动态配置。
-
-1.打开服务治理控制台，点击”创建“，填入应用名和配置，这个配置将禁用在20880端口上提供（side:provider）的所有服务（scope:application）。
+##### 配置模板
```yaml
-configVersion: v2.7
-scope: application
-key: governance-appoverride-provider
-enabled: true
-configs:
-- addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- disabled: true
-```
-
-运行BasicConsumer，此时发现是运行在20881端口的提供者提供服务，说明覆盖规则生效。
-
-
-
-#### 任务2：评估系统容量
-
-目前需要对系统容量进行评估，进行调整权重。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整20880端口的提供者权重(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- weight: 1000
- ```
-
-多次运行BasicConsumer，发现运行在20880端口的提供者示例提供服务次数多于20881端口的提供者示例。
-
-
-
-#### 任务3：调整负载均衡策略
-
-目前需要调整负载均衡策略。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整负载均衡策略：(缺省负载均衡策略为 random)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ```
-
-Random策略按权重设置随机概率，多次运行BasicConsumer，BasicConsumer访问20880端口的概率大于访问20881端口的概率。
-
-
-
-### 服务粒度
-
-
-
-dubbo-samples-servicelevel-override示例与上面的示例类似，故不赘述。运行BasicProvider类。
-
-
-
-#### 任务1：修改提供者服务的超时时间
-
-目前需要修改提供者服务的超时时间
-
-1.打开服务治理控制台，点击”创建“，填入服务名和配置，这个配置将所有消费（side:consumer）DemoService服务（org.apache.dubbo.samples.governance.api.DemoService）的应用实例（addresses:[0.0.0.0]），超时时间修改为300ms
-
-```yaml
-configVersion: v2.7
-scope: service
-key: org.apache.dubbo.samples.governance.api.DemoService
+---
+scope: application/service
+force: true
+runtime: true
enabled: true
-configs:
-- addresses: [0.0.0.0]
- side: consumer
- parameters:
- timeout: 300
+key: app-name/group+service+version
+conditions:
+ - application=app1 => address=*:20880
+ - method=sayHello => address=*:20880
```
-运行BasicConsumer类，发现BasicConSumer抛异常无法调用远程方法，如图：
+**对于流量灰度场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
+1. 要修改消费者应用的配置还是某个服务的配置。
+ - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
+ - 服务：`scope: service, key:group+service+version `。
+2. 当路由结果为空，是否强制返回。
+ - force=false: 当路由结果为空，降级请求tag为空的提供者。
+ - force=true: 当路由结果为空，直接返回异常。
+3. 路由规则的优先级
+ - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
+4. 配置是否只对某几个特定实例生效。
+ - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
+ - 指定实例：`addersses[实例地址列表]`。
+5. 要修改的条件规则。
+ - => 之前的为消费者匹配条件，所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
+ - => 之后为提供者地址列表的过滤条件，所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。
+ - 如果匹配条件为空，表示对所有消费方应用，如：=> host != 10.20.153.11
+ - 如果过滤条件为空，表示禁止访问，如：host = 10.20.153.10 =>
+### 标签路由
+1. 登录Dubbo-Admin控制台
+2. 在左侧导航栏选择服务治理 > 标签路由。
+3. 点击创建按钮，在创建新标签规则面板中，填写规则内容，然后单击保存。
-## 规则详解
+#### 规则详解
-#### 配置模板
+##### 配置模板
```yaml
---
-configVersion: v2.7
-scope: application/service
-key: app-name/group+service+version
-enabled: true
-configs:
-- addresses: ["0.0.0.0"]
- providerAddresses: ["1.1.1.1:20880", "2.2.2.2:20881"]
- side: consumer
- applications/services: []
- parameters:
- timeout: 1000
- loadbalance: random
-- addresses: ["0.0.0.0:20880"]
- side: provider
- applications/services: []
- parameters:
- threadpool: fixed
- threads: 200
- iothreads: 4
- dispatcher: all
- weight: 200
-...
+ 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"]
+ ...
```
-其中：
-
-- `configVersion` 表示 dubbo 的版本
-- `scope`表示配置作用范围，分别是应用（application）或服务（service）粒度。**必填**。
-- `key`指定规则体作用在哪个服务或应用。**必填**。
- - scope=service时，key取值为[{group}:]{service}[:{version}]的组合
- - scope=application时，key取值为application名称
-
-- `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
-- `configs`定义具体的覆盖规则内容，可以指定n（n>=1）个规则体。**必填**。
- - side: 消费者端/提供者端
- - applications: 对应用覆盖规则
- - services: 对服务覆盖规则
- - parameters: 参数列表
- - addresses: 地址值
- - providerAddresses: 提供者地址值
+**对于流量灰度场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-**对于绝大多数配置场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改整个应用的配置还是某个服务的配置。
+1. 要修改服务所属提供者应用的配置。
- 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- - 服务：`scope: service, key:group+service+version `。
-2. 修改是作用到消费者端还是提供者端。
- - 消费者：`side: consumer` ，作用到消费端时（你还可以进一步使用`providerAddress`,
`applications`选定特定的提供者示例或应用）。
- - 提供者：`side: provider`。
-3. 配置是否只对某几个特定实例生效。
+2. 当路由结果为空，是否强制返回。
+ - force=false: 当路由结果为空，降级请求tag为空的提供者。
+ - force=true: 当路由结果为空，直接返回异常。
+3. 路由规则的优先级
+ - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
+4. 配置是否只对某几个特定实例生效。
- 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- 指定实例：`addersses[实例地址列表]`。
-4. 要修改的属性是哪个。
-
-#### 示例
-
-1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- disabled: true
- ...
- ```
-
-2. 调整权重：(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- weight: 200
- ...
- ```
-
-3. 调整负载均衡策略：(缺省负载均衡策略为 random)
+5. 要修改的标签名。
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-consumer
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ...
- ```
+## 结果验证
+选择和流量灰度配置相关的应用，触发该调用验证。
diff --git a/content/zh/overview/tasks/traffic-management/traffic-routing.md
b/content/zh/overview/tasks/traffic-management/traffic-routing.md
index 6379bd02aa7..59b234acdba 100644
--- a/content/zh/overview/tasks/traffic-management/traffic-routing.md
+++ b/content/zh/overview/tasks/traffic-management/traffic-routing.md
@@ -3,325 +3,64 @@ type: docs
title: "请求路由"
linkTitle: "请求路由"
weight: 5
-description: "在 Dubbo 中配置应用级治理规则和服务级治理规则"
-toc_hide: true
+description: "在 Dubbo-Admin 根据请求条件路由"
---
-> **提示**
->
-> 本文描述的是新版本规则配置，而不是[老版本配置规则](/zh/docs/advanced/config-rule-deprecated)
-
-# 配置规则
-
-此任务将展示在 Dubbo 中配置应用级治理规则和服务级治理规则
-
-
-覆盖规则是 Dubbo 设计的在无需重启应用的情况下，动态调整 RPC 调用行为的一种能力。2.7.0
版本开始，支持从**服务**和**应用**两个粒度来调整动态配置。
-
+Dubbo提供动态创建条件路由的服务治理能力，可以在无需重启应用的情况下，根据请求发起方、请求的方法条件路由。
+Dubbo可以通过XML配置，注解配置，动态配置实现动态根据请求条件路由，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
## 开始之前
-- 安装idea
-
-- 克隆[dubbo-samples](https://github.com/apache/dubbo-samples.git)到本地，idea打开
-
-- 拉取dubbo-admin镜像并运行镜像
-
-
-
-
-> **提示**
->
-> 可参考如下步骤部署dubbo-admin
->
-> 1. 创建docker-compose.yml文件，内容如下:
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-> 2.运行命令
->
-> ```
-> docker-compose up
-> ```
-
-
-
-运行成功后，可以看见dubbo-admin界面
-
-
-
-
-
-## 概览
-
-
-
-dubbo-samples-governance示例包含dubbo-samples-applevel-override和dubbo-samples-servicelevel-override子示例，这2个子示例分别从**服务**和**应用**两个粒度应用覆盖规则动态调整路由。
-
-
-
-此任务的最初目标是应用覆盖规则在无需重启应用的情况下动态调整流量路由。稍后，您将从**服务**和**应用**两个粒度应用规则动态调整路由。
-
-
-
-下图展示本任务的应用端到端架构。
-
-
-
-
-
-### 应用粒度
-
-
-
-dubbo-samples-applevel-override示例中，BasicConsumer类和BascicProvider类为消费者类和提供者类，现在运行BasicProvider，成功后如图：
-
-
-
-
-
-在控制台查询服务，可以看到应用governance-appoverride-provider，如图：
-
-
-
-
-
-现在再运行一个提供者示例，运行在20881端口，首先修改dubbo-demo-provider.xml，将< dubbo:protocol
/>标签中端口修改修改为20881，运行BasicProvider，成功后查询控制台，如图：
-
-
-
-
-
-
-> **提示**
->
-> 如果运行BasicProvider示例失败，请修改BasicProvider配置，勾选Allow multiple instances
-
-
+请确保成功运行Dubbo-Admin
+
+## 背景信息
-#### 任务1：临时剔除提供者
+在业务场景如黑白名单，排除预发布机，只暴露部分机器，分环境隔离等，需要路由规则在发起RPC调用前过滤目标服务器地址，过滤后的地址作为最终发起RPC调用的备选地址。Dubbo-Admin提供条件路由的能力，能够帮助您配置路由规则，满足业务场景。
-目前需要临时剔除在20880端口的提供者，可以使用覆盖规则进行动态配置。
+## 操作步骤
-1.打开服务治理控制台，点击”创建“，填入应用名和配置，这个配置将禁用在20880端口上提供（side:provider）的所有服务（scope:application）。
+### 条件路由
-```yaml
-configVersion: v2.7
-scope: application
-key: governance-appoverride-provider
-enabled: true
-configs:
-- addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- disabled: true
-```
-
-运行BasicConsumer，此时发现是运行在20881端口的提供者提供服务，说明覆盖规则生效。
-
-
-
-#### 任务2：评估系统容量
-
-目前需要对系统容量进行评估，进行调整权重。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整20880端口的提供者权重(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- weight: 1000
- ```
-
-多次运行BasicConsumer，发现运行在20880端口的提供者示例提供服务次数多于20881端口的提供者示例。
-
-
-
-#### 任务3：调整负载均衡策略
-
-目前需要调整负载均衡策略。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整负载均衡策略：(缺省负载均衡策略为 random)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ```
-
-Random策略按权重设置随机概率，多次运行BasicConsumer，BasicConsumer访问20880端口的概率大于访问20881端口的概率。
-
-
-
-### 服务粒度
-
-
-
-dubbo-samples-servicelevel-override示例与上面的示例类似，故不赘述。运行BasicProvider类。
+1. 登录Dubbo-Admin控制台
+2. 在左侧导航栏选择服务治理 > 条件路由。
+3. 点击创建按钮，在创建新路由规则面板中，填写规则内容，然后单击保存。
+#### 规则详解
-#### 任务1：修改提供者服务的超时时间
-
-目前需要修改提供者服务的超时时间
-
-1.打开服务治理控制台，点击”创建“，填入服务名和配置，这个配置将所有消费（side:consumer）DemoService服务（org.apache.dubbo.samples.governance.api.DemoService）的应用实例（addresses:[0.0.0.0]），超时时间修改为300ms
-
-```yaml
-configVersion: v2.7
-scope: service
-key: org.apache.dubbo.samples.governance.api.DemoService
-enabled: true
-configs:
-- addresses: [0.0.0.0]
- side: consumer
- parameters:
- timeout: 300
-```
-
-运行BasicConsumer类，发现BasicConSumer抛异常无法调用远程方法，如图：
-
-
-
-
-
-## 规则详解
-
-#### 配置模板
+##### 配置模板
```yaml
---
-configVersion: v2.7
scope: application/service
-key: app-name/group+service+version
+force: true
+runtime: true
enabled: true
-configs:
-- addresses: ["0.0.0.0"]
- providerAddresses: ["1.1.1.1:20880", "2.2.2.2:20881"]
- side: consumer
- applications/services: []
- parameters:
- timeout: 1000
- loadbalance: random
-- addresses: ["0.0.0.0:20880"]
- side: provider
- applications/services: []
- parameters:
- threadpool: fixed
- threads: 200
- iothreads: 4
- dispatcher: all
- weight: 200
-...
+key: app-name/group+service+version
+conditions:
+ - application=app1 => address=*:20880
+ - method=sayHello => address=*:20880
```
-其中：
-
-- `configVersion` 表示 dubbo 的版本
-- `scope`表示配置作用范围，分别是应用（application）或服务（service）粒度。**必填**。
-- `key`指定规则体作用在哪个服务或应用。**必填**。
- - scope=service时，key取值为[{group}:]{service}[:{version}]的组合
- - scope=application时，key取值为application名称
+**对于条件路由场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-- `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
-- `configs`定义具体的覆盖规则内容，可以指定n（n>=1）个规则体。**必填**。
- - side: 消费者端/提供者端
- - applications: 对应用覆盖规则
- - services: 对服务覆盖规则
- - parameters: 参数列表
- - addresses: 地址值
- - providerAddresses: 提供者地址值
-
-**对于绝大多数配置场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改整个应用的配置还是某个服务的配置。
+1. 要修改消费者应用的配置还是某个服务的配置。
- 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- 服务：`scope: service, key:group+service+version `。
-2. 修改是作用到消费者端还是提供者端。
- - 消费者：`side: consumer` ，作用到消费端时（你还可以进一步使用`providerAddress`,
`applications`选定特定的提供者示例或应用）。
- - 提供者：`side: provider`。
-3. 配置是否只对某几个特定实例生效。
+2. 当路由结果为空，是否强制返回。
+ - force=false: 当路由结果为空，降级请求tag为空的提供者。
+ - force=true: 当路由结果为空，直接返回异常。
+3. 路由规则的优先级
+ - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
+4. 配置是否只对某几个特定实例生效。
- 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- 指定实例：`addersses[实例地址列表]`。
-4. 要修改的属性是哪个。
-
-#### 示例
-
-1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- disabled: true
- ...
- ```
-
-2. 调整权重：(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- weight: 200
- ...
- ```
-
-3. 调整负载均衡策略：(缺省负载均衡策略为 random)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-consumer
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ...
- ```
+5. 要修改的条件规则。
+ - => 之前的为消费者匹配条件，所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
+ - => 之后为提供者地址列表的过滤条件，所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。
+ - 如果匹配条件为空，表示对所有消费方应用，如：=> host != 10.20.153.11
+ - 如果过滤条件为空，表示禁止访问，如：host = 10.20.153.10 =>
+
+## 结果验证
+选择和条件路由配置相关的应用，触发该调用验证。
\ No newline at end of file
diff --git a/content/zh/overview/tasks/traffic-management/weight.md
b/content/zh/overview/tasks/traffic-management/weight.md
index 561c5b9da17..04a07d15eb1 100644
--- a/content/zh/overview/tasks/traffic-management/weight.md
+++ b/content/zh/overview/tasks/traffic-management/weight.md
@@ -17,35 +17,6 @@ Dubbo可以通过XML配置，注解配置，动态配置实现通过权重调整
请确保成功运行Dubbo-Admin
-
-> **提示**
->
-> docker部署dubbo-admin，docker-compose.yml如下：
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-
-
## 背景信息
在机器性能差异的场景下，不同机器的负载需要进行系统评估，需要对某些机器降级。通过权重调整机器的流量比例，可以合理地评估机器性能。
@@ -54,12 +25,14 @@ Dubbo可以通过XML配置，注解配置，动态配置实现通过权重调整
## 操作步骤
+### 权重调整
+
1. 登录Dubbo-Admin控制台
2. 在左侧导航栏选择服务治理 > 权重调整。
3. 点击创建按钮，在新建权重规则面板中，填写规则内容，然后单击保存。
-## 规则详解
+#### 规则详解
**对于通过权重动态调整流量分布场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
diff --git a/content/zh/overview/tasks/traffic-management/zone.md
b/content/zh/overview/tasks/traffic-management/zone.md
index 58edf36169c..037b0ce58c6 100644
--- a/content/zh/overview/tasks/traffic-management/zone.md
+++ b/content/zh/overview/tasks/traffic-management/zone.md
@@ -3,325 +3,61 @@ type: docs
title: "同机房/区域优先"
linkTitle: "同机房/区域优先"
weight: 5
-description: "在 Dubbo 中配置应用级治理规则和服务级治理规则"
-toc_hide: true
+description: "在 Dubbo-Admin 动态配置同机房/区域优先"
---
-> **提示**
->
-> 本文描述的是新版本规则配置，而不是[老版本配置规则](/zh/docs/advanced/config-rule-deprecated)
-
-# 配置规则
-
-此任务将展示在 Dubbo 中配置应用级治理规则和服务级治理规则
-
-
-覆盖规则是 Dubbo 设计的在无需重启应用的情况下，动态调整 RPC 调用行为的一种能力。2.7.0
版本开始，支持从**服务**和**应用**两个粒度来调整动态配置。
-
+Dubbo提供动态配置同机房/区域优先的服务治理能力，可以在无需重启应用的情况下，动态配置同机房/区域优先。
+Dubbo可以通过XML配置，注解配置，动态配置同机房/区域优先，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
## 开始之前
-- 安装idea
-
-- 克隆[dubbo-samples](https://github.com/apache/dubbo-samples.git)到本地，idea打开
-
-- 拉取dubbo-admin镜像并运行镜像
-
-
-
-
-> **提示**
->
-> 可参考如下步骤部署dubbo-admin
->
-> 1. 创建docker-compose.yml文件，内容如下:
->
-> ```
-> version: '3'
-> services:
-> zk:
-> image: zookeeper
-> container_name: zk
-> ports:
-> - 2181:2181
-> dubbo-admin:
-> image: apache/dubbo-admin
-> container_name: dubbo-admin
-> # 等待zk启动后再启动
-> depends_on:
-> - zk
-> ports:
-> - 8080:8080
-> environment:
-> - admin.registry.address=zookeeper://zk:2181
-> - admin.config-center=zookeeper://zk:2181
-> - admin.metadata-report.address=zookeeper://zk:2181
-> ```
->
-> 2.运行命令
->
-> ```
-> docker-compose up
-> ```
-
-
-
-运行成功后，可以看见dubbo-admin界面
-
-
-
-
-
-## 概览
-
-
-
-dubbo-samples-governance示例包含dubbo-samples-applevel-override和dubbo-samples-servicelevel-override子示例，这2个子示例分别从**服务**和**应用**两个粒度应用覆盖规则动态调整路由。
-
-
-
-此任务的最初目标是应用覆盖规则在无需重启应用的情况下动态调整流量路由。稍后，您将从**服务**和**应用**两个粒度应用规则动态调整路由。
-
-
-
-下图展示本任务的应用端到端架构。
-
-
-
-
-
-### 应用粒度
-
-
-
-dubbo-samples-applevel-override示例中，BasicConsumer类和BascicProvider类为消费者类和提供者类，现在运行BasicProvider，成功后如图：
-
-
-
-
-
-在控制台查询服务，可以看到应用governance-appoverride-provider，如图：
-
-
-
-
-
-现在再运行一个提供者示例，运行在20881端口，首先修改dubbo-demo-provider.xml，将< dubbo:protocol
/>标签中端口修改修改为20881，运行BasicProvider，成功后查询控制台，如图：
-
-
-
-
-
+请确保成功运行Dubbo-Admin
-> **提示**
->
-> 如果运行BasicProvider示例失败，请修改BasicProvider配置，勾选Allow multiple instances
+## 背景信息
+当应用部署在多个不同机房/区域的时候，应用之间相互调用会出现跨区域的情况，跨区域调用会增加响应时间。同机房/区域优先是指应用调用服务时，优先调用同机房/区域的服务提供者。Dubbo-Admin提供了动态的同机房/区域优先能力，能够帮助您快速动态配置同机房/区域优先，避免了跨区域带来的网络延时，从而减少了调用的响应时间。
-#### 任务1：临时剔除提供者
+## 操作步骤
-目前需要临时剔除在20880端口的提供者，可以使用覆盖规则进行动态配置。
+### 标签路由
-1.打开服务治理控制台，点击”创建“，填入应用名和配置，这个配置将禁用在20880端口上提供（side:provider）的所有服务（scope:application）。
+1. 登录Dubbo-Admin控制台
+2. 在左侧导航栏选择服务治理 > 标签路由。
+3. 点击创建按钮，在创建新标签规则面板中，填写规则内容，然后单击保存。
-```yaml
-configVersion: v2.7
-scope: application
-key: governance-appoverride-provider
-enabled: true
-configs:
-- addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- disabled: true
-```
-
-运行BasicConsumer，此时发现是运行在20881端口的提供者提供服务，说明覆盖规则生效。
-
-
-
-#### 任务2：评估系统容量
-
-目前需要对系统容量进行评估，进行调整权重。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整20880端口的提供者权重(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - addresses: ["0.0.0.0:20880"]
- side: provider
- parameters:
- weight: 1000
- ```
-
-多次运行BasicConsumer，发现运行在20880端口的提供者示例提供服务次数多于20881端口的提供者示例。
-
-
-
-#### 任务3：调整负载均衡策略
-
-目前需要调整负载均衡策略。
-
-1. 修改刚才的配置，填入配置如下，这个配置将调整负载均衡策略：(缺省负载均衡策略为 random)
-
- ```yaml
- configVersion: v2.7
- scope: application
- key: governance-appoverride-provider
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ```
-
-Random策略按权重设置随机概率，多次运行BasicConsumer，BasicConsumer访问20880端口的概率大于访问20881端口的概率。
-
-
-
-### 服务粒度
-
-
-
-dubbo-samples-servicelevel-override示例与上面的示例类似，故不赘述。运行BasicProvider类。
+#### 规则详解
-
-
-#### 任务1：修改提供者服务的超时时间
-
-目前需要修改提供者服务的超时时间
-
-1.打开服务治理控制台，点击”创建“，填入服务名和配置，这个配置将所有消费（side:consumer）DemoService服务（org.apache.dubbo.samples.governance.api.DemoService）的应用实例（addresses:[0.0.0.0]），超时时间修改为300ms
-
-```yaml
-configVersion: v2.7
-scope: service
-key: org.apache.dubbo.samples.governance.api.DemoService
-enabled: true
-configs:
-- addresses: [0.0.0.0]
- side: consumer
- parameters:
- timeout: 300
-```
-
-运行BasicConsumer类，发现BasicConSumer抛异常无法调用远程方法，如图：
-
-
-
-
-
-## 规则详解
-
-#### 配置模板
+##### 配置模板
```yaml
---
-configVersion: v2.7
-scope: application/service
-key: app-name/group+service+version
-enabled: true
-configs:
-- addresses: ["0.0.0.0"]
- providerAddresses: ["1.1.1.1:20880", "2.2.2.2:20881"]
- side: consumer
- applications/services: []
- parameters:
- timeout: 1000
- loadbalance: random
-- addresses: ["0.0.0.0:20880"]
- side: provider
- applications/services: []
- parameters:
- threadpool: fixed
- threads: 200
- iothreads: 4
- dispatcher: all
- weight: 200
-...
+ 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"]
+ ...
```
-其中：
-
-- `configVersion` 表示 dubbo 的版本
-- `scope`表示配置作用范围，分别是应用（application）或服务（service）粒度。**必填**。
-- `key`指定规则体作用在哪个服务或应用。**必填**。
- - scope=service时，key取值为[{group}:]{service}[:{version}]的组合
- - scope=application时，key取值为application名称
+**对于同机房/区域优先场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-- `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
-- `configs`定义具体的覆盖规则内容，可以指定n（n>=1）个规则体。**必填**。
- - side: 消费者端/提供者端
- - applications: 对应用覆盖规则
- - services: 对服务覆盖规则
- - parameters: 参数列表
- - addresses: 地址值
- - providerAddresses: 提供者地址值
-
-**对于绝大多数配置场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改整个应用的配置还是某个服务的配置。
+1. 要修改服务所属提供者应用的配置。
- 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- - 服务：`scope: service, key:group+service+version `。
-2. 修改是作用到消费者端还是提供者端。
- - 消费者：`side: consumer` ，作用到消费端时（你还可以进一步使用`providerAddress`,
`applications`选定特定的提供者示例或应用）。
- - 提供者：`side: provider`。
-3. 配置是否只对某几个特定实例生效。
+2. 当路由结果为空，是否强制返回。
+ - force=false: 当路由结果为空，降级请求tag为空的提供者。
+ - force=true: 当路由结果为空，直接返回异常。
+3. 路由规则的优先级
+ - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
+4. 配置是否只对某几个特定实例生效。
- 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- 指定实例：`addersses[实例地址列表]`。
-4. 要修改的属性是哪个。
-
-#### 示例
-
-1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- disabled: true
- ...
- ```
-
-2. 调整权重：(通常用于容量评估，缺省权重为 200)
-
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-provider
- enabled: true
- configs:
- - addresses: ["10.20.153.10:20880"]
- side: provider
- parameters:
- weight: 200
- ...
- ```
-
-3. 调整负载均衡策略：(缺省负载均衡策略为 random)
+5. 要修改的标签名。
- ```yaml
- ---
- configVersion: v2.7
- scope: application
- key: demo-consumer
- enabled: true
- configs:
- - side: consumer
- parameters:
- loadbalance: random
- ...
- ```
+## 结果验证
+选择和同机房/区域优先配置相关的应用，触发该调用验证。
