This is an automated email from the ASF dual-hosted git repository.
liujun pushed a commit to branch refactor/next
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/refactor/next by this push:
new f903d9c1fec Update docs, traffic management (#1797)
f903d9c1fec is described below
commit f903d9c1fec1bfab498aab36d5b764f75a486746
Author: Ken Liu <[email protected]>
AuthorDate: Mon Jan 2 14:16:32 2023 +0800
Update docs, traffic management (#1797)
---
.../overview/core-features/service-definition.md | 488 ++++++++++++++++++++-
.../overview/core-features/traffic-management.md | 33 +-
content/zh/overview/quickstart/_index.md | 485 --------------------
content/zh/overview/tasks/api-management/_index.md | 8 -
content/zh/overview/tasks/ecosystem/_index.md | 70 ++-
.../zh/overview/tasks/microservice-demo/_index.md | 8 -
content/zh/overview/tasks/migration/2to3.md | 44 --
content/zh/overview/tasks/migration/_index.md | 49 ---
.../overview/tasks/migration/migration-triple.md | 38 --
.../tasks/migration/service-discovery-samples.md | 76 ----
content/zh/overview/tasks/observability/admin.md | 18 +-
content/zh/overview/tasks/prepare/_index.md | 8 -
.../overview/tasks/prepare/prepare-kubernetes.md | 7 -
content/zh/overview/tasks/prepare/prepare-vm.md | 7 -
.../overview/tasks/{triple => protocols}/_index.md | 18 +-
content/zh/overview/tasks/protocols/dubbo2.md | 7 +
content/zh/overview/tasks/protocols/grpc.md | 7 +
content/zh/overview/tasks/protocols/http.md | 7 +
.../zh/overview/tasks/protocols/triple/_index.md | 8 +
.../overview/tasks/{ => protocols}/triple/idl.md | 0
.../tasks/{ => protocols}/triple/streaming.md | 0
.../overview/tasks/{ => protocols}/triple/wrap.md | 0
.../zh/overview/tasks/traffic-management/_index.md | 148 ++++++-
.../overview/tasks/traffic-management/accesslog.md | 81 ++++
.../overview/tasks/traffic-management/arguments.md | 83 ++++
.../zh/overview/tasks/traffic-management/host.md | 61 +++
.../overview/tasks/traffic-management/isolation.md | 123 +++---
.../zh/overview/tasks/traffic-management/mock.md | 65 +++
.../zh/overview/tasks/traffic-management/region.md | 79 ++++
.../zh/overview/tasks/traffic-management/retry.md | 67 +++
.../overview/tasks/traffic-management/timeout.md | 91 ++--
.../tasks/traffic-management/traffic-condition.md | 63 ---
.../tasks/traffic-management/traffic-gray.md | 104 -----
.../tasks/traffic-management/traffic-routing.md | 66 ---
.../zh/overview/tasks/traffic-management/weight.md | 96 ++--
.../zh/overview/tasks/traffic-management/zone.md | 63 ---
static/imgs/v3/tasks/accesslog/accesslog1.png | Bin 0 -> 47901 bytes
static/imgs/v3/tasks/arguments/arguments1.png | Bin 0 -> 3922219 bytes
static/imgs/v3/tasks/arguments/arguments2.png | Bin 0 -> 151366 bytes
static/imgs/v3/tasks/gray/gray1.png | Bin 0 -> 1399430 bytes
static/imgs/v3/tasks/gray/gray2.png | Bin 0 -> 104649 bytes
static/imgs/v3/tasks/host/host1.png | Bin 0 -> 76975 bytes
static/imgs/v3/tasks/mock/mock0.png | Bin 0 -> 560592 bytes
static/imgs/v3/tasks/mock/mock1.png | Bin 0 -> 5089314 bytes
static/imgs/v3/tasks/mock/mock2.png | Bin 0 -> 5089314 bytes
static/imgs/v3/tasks/region/region1.png | Bin 0 -> 562695 bytes
static/imgs/v3/tasks/region/region2.png | Bin 0 -> 1118997 bytes
static/imgs/v3/tasks/region/region3.png | Bin 0 -> 3921056 bytes
static/imgs/v3/tasks/region/region4.png | Bin 0 -> 5086160 bytes
static/imgs/v3/tasks/retry/retry1.png | Bin 0 -> 3943648 bytes
static/imgs/v3/tasks/retry/retry2.png | Bin 0 -> 109012 bytes
static/imgs/v3/tasks/retry/retry3.png | Bin 0 -> 34451 bytes
static/imgs/v3/tasks/timeout/timeout1.png | Bin 0 -> 22226 bytes
static/imgs/v3/tasks/timeout/timeout2.png | Bin 0 -> 43029 bytes
static/imgs/v3/tasks/timeout/timeout3.png | Bin 0 -> 23511 bytes
static/imgs/v3/tasks/timeout/timeout4.png | Bin 0 -> 35682 bytes
static/imgs/v3/tasks/weight/weight1.png | Bin 0 -> 167740 bytes
static/imgs/v3/tasks/weight/weight2.png | Bin 0 -> 3945463 bytes
static/imgs/v3/traffic/shop-arc-deploy.png | Bin 0 -> 112879 bytes
static/imgs/v3/traffic/shop-arc-deploy2.png | Bin 0 -> 131625 bytes
static/imgs/v3/traffic/shop-arc.png | Bin 0 -> 46312 bytes
61 files changed, 1390 insertions(+), 1186 deletions(-)
diff --git a/content/zh/overview/core-features/service-definition.md
b/content/zh/overview/core-features/service-definition.md
index 68ea877e4e0..14a2fe722ff 100644
--- a/content/zh/overview/core-features/service-definition.md
+++ b/content/zh/overview/core-features/service-definition.md
@@ -8,4 +8,490 @@ feature:
title: 定义服务
description: >
定义服务
----
\ No newline at end of file
+---
+
+本文可帮助开发者了解 Dubbo 微服务项目构建、开发、部署、观测、治理的全生命周期基本流程，这篇文档更多的是展示 Dubbo 的开发流程与开发模式。
+
+如果您需要可实际动手实践的示例，期望能跟随示例讲解一步步的完成开发，请参考以下每个语言的快速开始：
+* [Java 快速开始]()
+* [Go 快速开始]()
+* [Rust 快速开始]()
+
+## 第一步，准备微服务环境
+在开发微服务之前，您需要安装相关的微服务基础设施如注册中心、服务治理控制台等。
+
+以下文档可以引导您快速的安装 Nacos、Zookeeper、Dubbo Admin 等注册中心与控制台组件。
+* [Kubernetes 环境安装]()
+* [传统虚拟机环境安装]()
+
+安装注册中心、服务治理中心等组件
+
+## 第一步，初始化项目
+如果您正在使用 Java 或 Go 开发微服务，则可以使用 Dubbo 提供的脚手架快速创建项目骨架，骨架项目包含开发 Dubbo
必须的依赖和配置，同时还包含一些对应的微服务开发的常用模式：
+* Java 项目脚手架
+* Go 项目脚手架
+
+以下是一个脚手架示例项目结构：
+
+![骨架项目截图]()
+
+可以直接导入 IDE 开始微服务业务开发。对于除 Java 和 Go 之外的其他语言，您也可以基于 Dubbo 提供的指引快速的创建项目。
+
+## 第二步，定义服务
+服务是 Dubbo 开发、通信和治理的基本单位，通常我们讲的 Dubbo
服务是一个类似编程语言接口的概念，它是一系列可以被调用的方法的集合。通常来说，服务提供者 (Server) 负责提供服务定义的实现，而服务消费者
(Client) 基于服务定义对服务提供者发起 RPC 调用。
+
+Dubbo 提供多种语言实现，开发者既可以选择以语言特有的方式定义服务，也可以选择使用语言中立的 IDL (Proto Buffers) 定义服务。
+
+{{< tabpane langEqualsHeader=true >}}
+{{< tab header="Java" >}}
+public interface DemoService {
+ String sayHello(String name);
+}
+{{< /tab >}}
+{{< tab header="Go" >}}
+type DemoService struct {
+ SayHello func(req []string) (string, error)
+}
+{{< /tab >}}
+{{< tab header="IDL" >}}
+syntax = "proto3";
+
+option java_multiple_files = true;
+option java_package = "org.apache.dubbo.demo.hello";
+option java_outer_classname = "HelloWorldProto";
+option objc_class_prefix = "HLW";
+
+package helloworld;
+
+service Greeter{
+ // unary
+ rpc greet(HelloRequest) returns (HelloReply);
+}
+
+// The request message containing the user's name.
+message HelloRequest {
+ string name = 1;
+}
+
+// The response message containing the greetings
+message HelloReply {
+ string message = 1;
+}
+{{< /tab >}}
+{{< /tabpane >}}
+
+## 第三步，开发服务提供者
+服务提供者（Server）需要完成两件事情：
+1. 基于上一步的服务定义给出业务逻辑实现
+2. 启动一个 Dubbo Server 监听来自客户端的请求并返回服务响应
+<br/><br/>
+
+首先，开发者遵循服务定义规范编写业务逻辑实现，如业务类需要实现特定接口或者抽象某个抽象类等。
+<br/><br/>
+
+{{< tabpane langEqualsHeader=true >}}
+{{< tab header="Java" >}}
+public class DemoServiceImpl implements DemoService {
+ @Override
+ public String sayHello(String name) {
+ return "Hello " + name + ", response from provider: " +
RpcContext.getServiceContext().getLocalAddress();
+ }
+}
+{{< /tab >}}
+{{< tab header="Go" >}}
+type DemoServiceImpl struct {
+}
+
+func (u *DemoServiceImpl) SayHello(msg string) (string, error) {
+ return "Response message!", nil
+}
+{{< /tab >}}
+{{< tab header="IDL Java" lang="Java" >}}
+// Code generated by Dubbo plugin of protoc compiler
+// Greeter.java
+public interface Greeter {
+ String JAVA_SERVICE_NAME = "org.apache.dubbo.demo.hello.Greeter";
+ String SERVICE_NAME = "helloworld.Greeter";
+
+ org.apache.dubbo.demo.hello.HelloReply
greet(org.apache.dubbo.demo.hello.HelloRequest request);
+
+ default CompletableFuture<org.apache.dubbo.demo.hello.HelloReply>
greetAsync(org.apache.dubbo.demo.hello.HelloRequest request){
+ return CompletableFuture.completedFuture(greet(request));
+ }
+ // ......
+}
+
+// Code generated by Dubbo plugin of protoc compiler
+// DubboGreeterTriple.java
+public static abstract class GreeterImplBase implements Greeter,
ServerService<Greeter> {
+ @Override
+ public org.apache.dubbo.demo.hello.HelloReply
greet(org.apache.dubbo.demo.hello.HelloRequest request){
+ throw unimplementedMethodException(greetMethod);
+ }
+ // ......
+}
+
+// The actual business logic that is written and provided by Dubbo user
+public class GreeterServiceImpl extends DubboGreeterTriple.GreeterImplBase {
+ @Override
+ public HelloReply greet(HelloRequest request) {
+ return HelloReply.newBuilder()
+ .setMessage("Hello " + request.getName())
+ .build();
+ }
+}
+{{< /tab >}}
+{{< tab header="IDL Go" lang="Go" >}}
+// Paste the protoc generated and user provided code snippet here.
+{{< /tab >}}
+{{< tab header="IDL Rust" lang="Rust" >}}
+use ...
+
+#[allow(dead_code)]
+#[derive(Default, Clone)]
+struct GreeterServerImpl {
+ name: String,
+}
+
+// #[async_trait]
+#[async_trait]
+impl Greeter for GreeterServerImpl {
+ async fn greet(
+ &self,
+ request: Request<GreeterRequest>,
+ ) -> Result<Response<GreeterReply>, dubbo::status::Status> {
+ println!("GreeterServer::greet {:?}", request.metadata);
+
+ Ok(Response::new(GreeterReply {
+ message: "hello, dubbo-rust".to_string(),
+ }))
+ }
+}
+{{< /tab >}}
+{{< tab header="IDL Node.js" >}}
+// Paste the protoc generated and user provided code snippet here.
+{{< /tab >}}
+{{< /tabpane >}}
+
+<br/>
+配置并注册以上服务实现类，同时，还可以指定服务参数、注册中心地址、协议与端口等配置，以下是支持几种配置格式示例：
+<br/><br/>
+
+{{< tabpane langEqualsHeader=true >}}
+{{< tab header="YAML" lang="yaml" >}}
+dubbo:
+ application:
+ name: demo-provider
+ protocol:
+ name: dubbo
+ port: -1
+ registry:
+ address: zookeeper://127.0.0.1:2181
+{{< /tab >}}
+{{< tab header="API" lang="java" >}}
+public static void main(String[] args) throws Exception {
+ ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
+ service.setInterface(DemoService.class);
+ service.setRef(new DemoServiceImpl());
+
+ DubboBootstrap bootstrap = DubboBootstrap.getInstance();
+ bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
+ .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
+ .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
+ .service(service)
+ .start()
+ .await();
+}
+{{< /tab >}}
+{{< tab header="Spring XML" >}}
+<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
+ xmlns="http://www.springframework.org/schema/beans";
+ xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
+ http://dubbo.apache.org/schema/dubbo
http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
+
+ <!-- Process related configurations -->
+ <dubbo:application name="demo-provider"/>
+
+ <!-- Registry address for service discovery-->
+ <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
+
+ <!-- Specifies the RPC protocol to use and the TCP port to listen on -->
+ <dubbo:protocol name="dubbo" port="-1"/>
+
+ <!-- Put all services need to be exported here -->
+ <dubbo:service interface="org.apache.dubbo.demo.DemoService"
timeout="3000" ref="demoService"/>
+ <bean id="demoService"
class="org.apache.dubbo.demo.provider.DemoServiceImpl"/>
+</beans>
+{{< /tab >}}
+{{< tab header="Java Annotation" lang="Java" >}}
+@DubboService
+public class DemoServiceImpl implements DemoService {
+ // business implementation
+}
+
+public class DemoServiceComponent implements DemoService {
+ @DubboReference
+ private DemoService demoService;
+}
+{{< /tab >}}
+{{< tab header="dubbo.properties" lang="properties" >}}
+dubbo.application.name=dubbo-demo-annotation-provider
+dubbo.protocol.name=dubbo
+dubbo.protocol.port=-1
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+{{< /tab >}}
+{{< /tabpane >}}
+
+<br/>
+启动 Server 监听服务
+<br/><br/>
+
+{{< tabpane langEqualsHeader=true >}}
+{{< tab header="Java" >}}
+public static void main(String[] args) throws Exception {
+ ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
+ service.setInterface(DemoService.class);
+ service.setRef(new DemoServiceImpl());
+
+ DubboBootstrap bootstrap = DubboBootstrap.getInstance();
+ bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
+ .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
+ .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
+ .service(service)
+ .start()
+ .await();
+}
+{{< /tab >}}
+{{< tab header="Go" >}}
+func main() {
+ config.SetProviderService(&DemoServiceImpl{})
+ if err := config.Load(); err != nil {
+ panic(err)
+ }
+ select {}
+}
+{{< /tab >}}
+{{< tab header="Rust" >}}
+#[tokio::main]
+async fn main() {
+ register_server(GreeterServerImpl {
+ name: "greeter".to_string(),
+ });
+
+ // Dubbo::new().start().await;
+ Dubbo::new()
+ .with_config({
+ let r = RootConfig::new();
+ match r.load() {
+ Ok(config) => config,
+ Err(_err) => panic!("err: {:?}", _err), // response was droped
+ }
+ })
+ .start()
+ .await;
+}
+{{< /tab >}}
+{{< tab header="Node.js" >}}
+// Put node.js server bootstrapping snippet here
+{{< /tab >}}
+{{< /tabpane >}}
+
+<br/>
+至此，能监听请求并提供特定服务的 Dubbo Server 就开发和启动完成了。
+
+## 第四步，开发服务消费者
+
+接下来就是开发一个调用服务的 Client 了
+
+> 在 Client 调用服务的前提是需要有服务定义的依赖，这可以通过语言特定的依赖分发系统或 IDL 管理系统实现。
+
+通过配置/API声明服务调用，告诉 Dubbo 要生成 Proxy 的服务，同时可以指定服务发现的注册中心等配置：
+
+{{< tabpane langEqualsHeader=true >}}
+{{< tab header="YAML" lang="yaml" >}}
+dubbo:
+ application:
+ name: demo-consumer
+ registry:
+ address: zookeeper://127.0.0.1:2181
+{{< /tab >}}
+{{< tab header="API" lang="java" >}}
+private static void main(String[] args) {
+ ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
+ reference.setInterface(DemoService.class);
+ reference.setGeneric("true");
+
+ DubboBootstrap bootstrap = DubboBootstrap.getInstance();
+ bootstrap.application(new ApplicationConfig("demo-consumer"))
+ .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
+ .reference(reference)
+ .start();
+}
+{{< /tab >}}
+{{< tab header="Spring XML" >}}
+<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
+ xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
+ xmlns="http://www.springframework.org/schema/beans";
+ xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
+ http://dubbo.apache.org/schema/dubbo
http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
+
+ <dubbo:application name="demo-consumer"/>
+
+ <dubbo:registry id="demo1" address="zookeeper://127.0.0.1:2181"/>
+
+ <dubbo:reference id="demoService" check="false"
interface="org.apache.dubbo.demo.DemoService"/>
+</beans>
+{{< /tab >}}
+{{< tab header="Java Annotation" lang="Java" >}}
+public class SpringApplication {
+ @DubboReference
+ private DemoService demoService;
+}
+{{< /tab >}}
+{{< tab header="dubbo.properties" lang="properties" >}}
+dubbo.application.name=dubbo-demo-annotation-provider
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+{{< /tab >}}
+{{< /tabpane >}}
+
+<br/>
+启动 Client
+<br/><br/>
+
+{{< tabpane langEqualsHeader=true >}}
+{{< tab header="Java" >}}
+public static void main(String[] args) throws Exception {
+ // ...
+ DemoService demoService = bootstrap.getCache().get(reference);
+ String message = demoService.sayHello("dubbo");
+ System.out.println("Result: " + message);
+}
+{{< /tab >}}
+{{< tab header="Go" >}}
+func main() {
+ config.SetProviderService(&DemoServiceImpl{})
+ if err := config.Load(); err != nil {
+ panic(err)
+ }
+ select {}
+}
+{{< /tab >}}
+{{< tab header="Rust" >}}
+#[tokio::main]
+async fn main() {
+ let mut cli =
GreeterClient::new().with_uri("http://127.0.0.1:8888".to_string());
+
+ println!("# unary call");
+ let resp = cli
+ .greet(Request::new(GreeterRequest {
+ name: "message from client".to_string(),
+ }))
+ .await;
+ let resp = match resp {
+ Ok(resp) => resp,
+ Err(err) => return println!("{:?}", err),
+ };
+ let (_parts, body) = resp.into_parts();
+ println!("Response: {:?}", body);
+}
+{{< /tab >}}
+{{< tab header="Node.js" >}}
+// Put node.js client snippet here
+{{< /tab >}}
+{{< /tabpane >}}
+
+服务调用
+
+## 第五步，打包部署
+
+#### 语言特定形式分发包
+
+您可以选择以语言特定方式打包 Dubbo 开发的服务 (如 Java Jar、Go Module
等)，并以语言提供的发机制将二进制包分发出去。一般来讲，要注意一以下几点：
+* 服务定义最好作为单独的二进制包由 Server 端定义并打包分发，以便所有 Client 都能依赖并基于服务定义编码；
+* Dubbo Server 和 Dubbo Client 的打包与分发与普通应用完全一样，如 Java 应用就可以用 Maven 或 Gradle
直接打包分发；
+* 如果您是以 IDL 方式定义服务，还需要考虑 IDL 的分发与管理方式；
+
+#### Docker 镜像
+
+在当今容器时代，打包为 Docker 镜像已变为更通用的分发形式
+
+```sh
+docker build -t ${your-organization}/${project-name}:${tag-or-version} .
+```
+
+> 通常，在脚手架生成的根目录下 `/deploy` 有预先生成的镜像打包 Dockerfile 模版，可以按需修改后直接用来打包。
+
+
+## 第六步，部署
+Dubbo 微服务支持多种部署架构，与云原生基础设施做了很好的适配：
+* 传统的自建服务治理体系模式，需自行维护微服务需要的注册中心集群、配置中心集群等
+* 基于 Kubernetes Native Service 微服务体系，此时 Kubernetes 集群承担服务抽象、注册中心、配置中心等角色
+* 服务网格架构，服务治理角色由控制面承担，Dubbo 作为数据面组件与 Sidecar 部署在一起，或者采用无 Sidecar 的 Proxyless 架构
+
+#### 传统自建注册、配置中心模式
+
+Dubbo 微服务需要依赖一些中心化集群协调状态，以下是一个抽象的 Dubbo 部署架构图：
+
+![三中心部署架构图]()
+
+图：部署在虚拟机或 Kubernetes 集群的传统 Dubbo 微服务架构
+
+* 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
+* 配置中心 (可选)
+ * 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
+ * 负责服务治理规则（路由规则、动态配置等）的存储与推送。
+* 元数据中心 (可选)
+ * 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
+ * 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
+
+以上三个中心集群并不是运行 Dubbo
的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会从独立的注册中心开始 Dubbo
服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。注册中心、配置中心和元数据中心都是逻辑概念，它们完全可以是同一个物理集群，如部署一个
Zookeeper 集群同时作为注册中心、配置中心和元数据中心。
+
+如您是在 Kubernetes 搭建 Dubbo 微服务集群，请参考 [如何在 Kubernetes 集群部署 Dubbo 服务]() 了解更多。
+
+#### Kubernetes 原生服务
+
+![参考下 Spring Kubernetes 等的架构图]()
+
+在这种模式下，Dubbo 服务将与 Kubernetes 原生服务实现概念对齐，同时，开发者也不再需要部署独立的注册、配置中心集群，这部分职责由
Kubernetes 及相应组件如 Service、ConfigMap、Deployment 等承担。具体是原理上，是由 Dubbo 节点直接与
Kubernete api-server 或 DNS 通信实现。
+
+请参考 [Dubbo Kubernetes 原生服务任务]() 了解更多
+
+#### 服务网格
+
+Dubbo 服务可以无缝接入 Istio 体系，并且，Dubbo 支持更灵活的数据面部署形式
+* Sidecar 模式，Dubbo 可以与 Envoy 等代理部署在一起，实现流量拦截和治理
+* Proxyless 模式，Dubbo 通过直接与 Istio 等控制面通信，实现与 Sidecar 模式对等能力的同时，减少了部署成本和性能损耗。
+
+
+
+具体可参见 [Dubbo 服务网格]() 部分说明。
+
+## 第七步，观测服务状态
+
+可以通过 Dubbo 官方提供的 Admin 控制台非常方便的观测服务运行状态。
+
+![Admin 截图]()
+
+请参考 [如何部署 Admin]() 了解如何将 Admin 部署您的开发或生产环境。
+
+> 注意：部署过程中必须要配置 Admin 连接到您正在使用的注册中心或配置中心集群，保证 Admin 和 Dubbo 微服务集群共享相同数据源。
+
+如果您将 Dubbo 部署在服务网格架构，则还可以使用对应控制面产品支持的控制台来观测 Dubbo 服务状态，如 Istio、Kiali。更多可观测能力如
Accessing Log、Tracing 等，请参考[可观测性]()文档。
+
+## 第八步，服务治理
+为了使 Dubbo 服务稳定、可控的运行，我们需要在运行态对 Dubbo 服务进行治理。
+
+首先，可以通过 Dubbo Admin 完成绝大多数的治理需求，如查看服务状态、下发流量规则等
+
+![Dubbo Admin 治理效果图]()
+
+对于更高阶的治理诉求，可通过以下内容了解：
+
+* [网关流量接入]()，通过网关实现前端 HTTP 流量接入 Dubbo 服务
+* [限流降级]()，通过 Sentinel 等突发流量，就要用到限流降级能力，
+* [数据一致性]()，了解 Dubbo 服务的分布式事物解决方案
+* [全链路追踪]()，了解 Dubbo 服务如何接入 Zipkin、Skywalking、OpenTracing 等全链路监控组件
+* [服务发现]()，了解 Dubbo 的服务发现机制和扩展实现
+* [流量管控]()，了解 Dubbo 丰富的流量管控规则定义及使用方式
+
diff --git a/content/zh/overview/core-features/traffic-management.md
b/content/zh/overview/core-features/traffic-management.md
index 3d0802fec3c..c14106dfb8e 100644
--- a/content/zh/overview/core-features/traffic-management.md
+++ b/content/zh/overview/core-features/traffic-management.md
@@ -8,4 +8,35 @@ feature:
title: 流量管控
description: >
Dubbo
支持通过一系列流量规则控制服务与服务之间的流量分布与行为，基于这些规则可以实现基于权重流量分布、流量灰度验证、金丝雀发布、按请求参数的路由、超时、限流降级等能力。
----
\ No newline at end of file
+---
+
+
+
+## 标签路由
+## 动态配置
+---
+configVersion: v3.0
+scope: application/service
+key: app-name/group+service+version
+enabled: true
+configs:
+- match:
+ address:
+ wildcard: xxx
+ service:
+ oneof: []
+ application:
+ oneof: []
+ param:
+ - key: url-key
+ value:
+ exact: url-value
+ - key: url-key
+ value:
+ exact: url-value
+ side: consumer
+ parameters:
+ timeout: 1000
+ cluster: failfase
+ loadbalance: random
+...
\ No newline at end of file
diff --git a/content/zh/overview/quickstart/_index.md
b/content/zh/overview/quickstart/_index.md
index aa98ff4def5..41aa339d23a 100755
--- a/content/zh/overview/quickstart/_index.md
+++ b/content/zh/overview/quickstart/_index.md
@@ -4,488 +4,3 @@ title: "一文了解 Dubbo 微服务开发、部署全流程"
linkTitle: "入门"
weight: 15
---
-本文可帮助开发者了解 Dubbo 微服务项目构建、开发、部署、观测、治理的全生命周期基本流程，这篇文档更多的是展示 Dubbo 的开发流程与开发模式。
-
-如果您需要可实际动手实践的示例，期望能跟随示例讲解一步步的完成开发，请参考以下每个语言的快速开始：
-* [Java 快速开始]()
-* [Go 快速开始]()
-* [Rust 快速开始]()
-
-## 第一步，准备微服务环境
-在开发微服务之前，您需要安装相关的微服务基础设施如注册中心、服务治理控制台等。
-
-以下文档可以引导您快速的安装 Nacos、Zookeeper、Dubbo Admin 等注册中心与控制台组件。
-* [Kubernetes 环境安装]()
-* [传统虚拟机环境安装]()
-
-安装注册中心、服务治理中心等组件
-
-## 第一步，初始化项目
-如果您正在使用 Java 或 Go 开发微服务，则可以使用 Dubbo 提供的脚手架快速创建项目骨架，骨架项目包含开发 Dubbo
必须的依赖和配置，同时还包含一些对应的微服务开发的常用模式：
-* Java 项目脚手架
-* Go 项目脚手架
-
-以下是一个脚手架示例项目结构：
-
-![骨架项目截图]()
-
-可以直接导入 IDE 开始微服务业务开发。对于除 Java 和 Go 之外的其他语言，您也可以基于 Dubbo 提供的指引快速的创建项目。
-
-## 第二步，定义服务
-服务是 Dubbo 开发、通信和治理的基本单位，通常我们讲的 Dubbo
服务是一个类似编程语言接口的概念，它是一系列可以被调用的方法的集合。通常来说，服务提供者 (Server) 负责提供服务定义的实现，而服务消费者
(Client) 基于服务定义对服务提供者发起 RPC 调用。
-
-Dubbo 提供多种语言实现，开发者既可以选择以语言特有的方式定义服务，也可以选择使用语言中立的 IDL (Proto Buffers) 定义服务。
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab header="Java" >}}
-public interface DemoService {
- String sayHello(String name);
-}
-{{< /tab >}}
-{{< tab header="Go" >}}
-type DemoService struct {
- SayHello func(req []string) (string, error)
-}
-{{< /tab >}}
-{{< tab header="IDL" >}}
-syntax = "proto3";
-
-option java_multiple_files = true;
-option java_package = "org.apache.dubbo.demo.hello";
-option java_outer_classname = "HelloWorldProto";
-option objc_class_prefix = "HLW";
-
-package helloworld;
-
-service Greeter{
- // unary
- rpc greet(HelloRequest) returns (HelloReply);
-}
-
-// The request message containing the user's name.
-message HelloRequest {
- string name = 1;
-}
-
-// The response message containing the greetings
-message HelloReply {
- string message = 1;
-}
-{{< /tab >}}
-{{< /tabpane >}}
-
-## 第三步，开发服务提供者
-服务提供者（Server）需要完成两件事情：
-1. 基于上一步的服务定义给出业务逻辑实现
-2. 启动一个 Dubbo Server 监听来自客户端的请求并返回服务响应
-<br/><br/>
-
-首先，开发者遵循服务定义规范编写业务逻辑实现，如业务类需要实现特定接口或者抽象某个抽象类等。
-<br/><br/>
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab header="Java" >}}
-public class DemoServiceImpl implements DemoService {
- @Override
- public String sayHello(String name) {
- return "Hello " + name + ", response from provider: " +
RpcContext.getServiceContext().getLocalAddress();
- }
-}
-{{< /tab >}}
-{{< tab header="Go" >}}
-type DemoServiceImpl struct {
-}
-
-func (u *DemoServiceImpl) SayHello(msg string) (string, error) {
- return "Response message!", nil
-}
-{{< /tab >}}
-{{< tab header="IDL Java" lang="Java" >}}
-// Code generated by Dubbo plugin of protoc compiler
-// Greeter.java
-public interface Greeter {
- String JAVA_SERVICE_NAME = "org.apache.dubbo.demo.hello.Greeter";
- String SERVICE_NAME = "helloworld.Greeter";
-
- org.apache.dubbo.demo.hello.HelloReply
greet(org.apache.dubbo.demo.hello.HelloRequest request);
-
- default CompletableFuture<org.apache.dubbo.demo.hello.HelloReply>
greetAsync(org.apache.dubbo.demo.hello.HelloRequest request){
- return CompletableFuture.completedFuture(greet(request));
- }
- // ......
-}
-
-// Code generated by Dubbo plugin of protoc compiler
-// DubboGreeterTriple.java
-public static abstract class GreeterImplBase implements Greeter,
ServerService<Greeter> {
- @Override
- public org.apache.dubbo.demo.hello.HelloReply
greet(org.apache.dubbo.demo.hello.HelloRequest request){
- throw unimplementedMethodException(greetMethod);
- }
- // ......
-}
-
-// The actual business logic that is written and provided by Dubbo user
-public class GreeterServiceImpl extends DubboGreeterTriple.GreeterImplBase {
- @Override
- public HelloReply greet(HelloRequest request) {
- return HelloReply.newBuilder()
- .setMessage("Hello " + request.getName())
- .build();
- }
-}
-{{< /tab >}}
-{{< tab header="IDL Go" lang="Go" >}}
-// Paste the protoc generated and user provided code snippet here.
-{{< /tab >}}
-{{< tab header="IDL Rust" lang="Rust" >}}
-use ...
-
-#[allow(dead_code)]
-#[derive(Default, Clone)]
-struct GreeterServerImpl {
- name: String,
-}
-
-// #[async_trait]
-#[async_trait]
-impl Greeter for GreeterServerImpl {
- async fn greet(
- &self,
- request: Request<GreeterRequest>,
- ) -> Result<Response<GreeterReply>, dubbo::status::Status> {
- println!("GreeterServer::greet {:?}", request.metadata);
-
- Ok(Response::new(GreeterReply {
- message: "hello, dubbo-rust".to_string(),
- }))
- }
-}
-{{< /tab >}}
-{{< tab header="IDL Node.js" >}}
-// Paste the protoc generated and user provided code snippet here.
-{{< /tab >}}
-{{< /tabpane >}}
-
-<br/>
-配置并注册以上服务实现类，同时，还可以指定服务参数、注册中心地址、协议与端口等配置，以下是支持几种配置格式示例：
-<br/><br/>
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab header="YAML" lang="yaml" >}}
-dubbo:
- application:
- name: demo-provider
- protocol:
- name: dubbo
- port: -1
- registry:
- address: zookeeper://127.0.0.1:2181
-{{< /tab >}}
-{{< tab header="API" lang="java" >}}
-public static void main(String[] args) throws Exception {
- ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
- service.setInterface(DemoService.class);
- service.setRef(new DemoServiceImpl());
-
- DubboBootstrap bootstrap = DubboBootstrap.getInstance();
- bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
- .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
- .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
- .service(service)
- .start()
- .await();
-}
-{{< /tab >}}
-{{< tab header="Spring XML" >}}
-<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
- xmlns="http://www.springframework.org/schema/beans";
- xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
- http://dubbo.apache.org/schema/dubbo
http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
-
- <!-- Process related configurations -->
- <dubbo:application name="demo-provider"/>
-
- <!-- Registry address for service discovery-->
- <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
-
- <!-- Specifies the RPC protocol to use and the TCP port to listen on -->
- <dubbo:protocol name="dubbo" port="-1"/>
-
- <!-- Put all services need to be exported here -->
- <dubbo:service interface="org.apache.dubbo.demo.DemoService"
timeout="3000" ref="demoService"/>
- <bean id="demoService"
class="org.apache.dubbo.demo.provider.DemoServiceImpl"/>
-</beans>
-{{< /tab >}}
-{{< tab header="Java Annotation" lang="Java" >}}
-@DubboService
-public class DemoServiceImpl implements DemoService {
- // business implementation
-}
-
-public class DemoServiceComponent implements DemoService {
- @DubboReference
- private DemoService demoService;
-}
-{{< /tab >}}
-{{< tab header="dubbo.properties" lang="properties" >}}
-dubbo.application.name=dubbo-demo-annotation-provider
-dubbo.protocol.name=dubbo
-dubbo.protocol.port=-1
-dubbo.registry.address=zookeeper://127.0.0.1:2181
-{{< /tab >}}
-{{< /tabpane >}}
-
-<br/>
-启动 Server 监听服务
-<br/><br/>
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab header="Java" >}}
-public static void main(String[] args) throws Exception {
- ServiceConfig<DemoServiceImpl> service = new ServiceConfig<>();
- service.setInterface(DemoService.class);
- service.setRef(new DemoServiceImpl());
-
- DubboBootstrap bootstrap = DubboBootstrap.getInstance();
- bootstrap.application(new ApplicationConfig("dubbo-demo-api-provider"))
- .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
- .protocol(new ProtocolConfig(CommonConstants.DUBBO, -1))
- .service(service)
- .start()
- .await();
-}
-{{< /tab >}}
-{{< tab header="Go" >}}
-func main() {
- config.SetProviderService(&DemoServiceImpl{})
- if err := config.Load(); err != nil {
- panic(err)
- }
- select {}
-}
-{{< /tab >}}
-{{< tab header="Rust" >}}
-#[tokio::main]
-async fn main() {
- register_server(GreeterServerImpl {
- name: "greeter".to_string(),
- });
-
- // Dubbo::new().start().await;
- Dubbo::new()
- .with_config({
- let r = RootConfig::new();
- match r.load() {
- Ok(config) => config,
- Err(_err) => panic!("err: {:?}", _err), // response was droped
- }
- })
- .start()
- .await;
-}
-{{< /tab >}}
-{{< tab header="Node.js" >}}
-// Put node.js server bootstrapping snippet here
-{{< /tab >}}
-{{< /tabpane >}}
-
-<br/>
-至此，能监听请求并提供特定服务的 Dubbo Server 就开发和启动完成了。
-
-## 第四步，开发服务消费者
-
-接下来就是开发一个调用服务的 Client 了
-
-> 在 Client 调用服务的前提是需要有服务定义的依赖，这可以通过语言特定的依赖分发系统或 IDL 管理系统实现。
-
-通过配置/API声明服务调用，告诉 Dubbo 要生成 Proxy 的服务，同时可以指定服务发现的注册中心等配置：
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab header="YAML" lang="yaml" >}}
-dubbo:
- application:
- name: demo-consumer
- registry:
- address: zookeeper://127.0.0.1:2181
-{{< /tab >}}
-{{< tab header="API" lang="java" >}}
-private static void main(String[] args) {
- ReferenceConfig<DemoService> reference = new ReferenceConfig<>();
- reference.setInterface(DemoService.class);
- reference.setGeneric("true");
-
- DubboBootstrap bootstrap = DubboBootstrap.getInstance();
- bootstrap.application(new ApplicationConfig("demo-consumer"))
- .registry(new RegistryConfig("zookeeper://127.0.0.1:2181"))
- .reference(reference)
- .start();
-}
-{{< /tab >}}
-{{< tab header="Spring XML" >}}
-<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
- xmlns="http://www.springframework.org/schema/beans";
- xsi:schemaLocation="http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
- http://dubbo.apache.org/schema/dubbo
http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
-
- <dubbo:application name="demo-consumer"/>
-
- <dubbo:registry id="demo1" address="zookeeper://127.0.0.1:2181"/>
-
- <dubbo:reference id="demoService" check="false"
interface="org.apache.dubbo.demo.DemoService"/>
-</beans>
-{{< /tab >}}
-{{< tab header="Java Annotation" lang="Java" >}}
-public class SpringApplication {
- @DubboReference
- private DemoService demoService;
-}
-{{< /tab >}}
-{{< tab header="dubbo.properties" lang="properties" >}}
-dubbo.application.name=dubbo-demo-annotation-provider
-dubbo.registry.address=zookeeper://127.0.0.1:2181
-{{< /tab >}}
-{{< /tabpane >}}
-
-<br/>
-启动 Client
-<br/><br/>
-
-{{< tabpane langEqualsHeader=true >}}
-{{< tab header="Java" >}}
-public static void main(String[] args) throws Exception {
- // ...
- DemoService demoService = bootstrap.getCache().get(reference);
- String message = demoService.sayHello("dubbo");
- System.out.println("Result: " + message);
-}
-{{< /tab >}}
-{{< tab header="Go" >}}
-func main() {
- config.SetProviderService(&DemoServiceImpl{})
- if err := config.Load(); err != nil {
- panic(err)
- }
- select {}
-}
-{{< /tab >}}
-{{< tab header="Rust" >}}
-#[tokio::main]
-async fn main() {
- let mut cli =
GreeterClient::new().with_uri("http://127.0.0.1:8888".to_string());
-
- println!("# unary call");
- let resp = cli
- .greet(Request::new(GreeterRequest {
- name: "message from client".to_string(),
- }))
- .await;
- let resp = match resp {
- Ok(resp) => resp,
- Err(err) => return println!("{:?}", err),
- };
- let (_parts, body) = resp.into_parts();
- println!("Response: {:?}", body);
-}
-{{< /tab >}}
-{{< tab header="Node.js" >}}
-// Put node.js client snippet here
-{{< /tab >}}
-{{< /tabpane >}}
-
-服务调用
-
-## 第五步，打包部署
-
-#### 语言特定形式分发包
-
-您可以选择以语言特定方式打包 Dubbo 开发的服务 (如 Java Jar、Go Module
等)，并以语言提供的发机制将二进制包分发出去。一般来讲，要注意一以下几点：
-* 服务定义最好作为单独的二进制包由 Server 端定义并打包分发，以便所有 Client 都能依赖并基于服务定义编码；
-* Dubbo Server 和 Dubbo Client 的打包与分发与普通应用完全一样，如 Java 应用就可以用 Maven 或 Gradle
直接打包分发；
-* 如果您是以 IDL 方式定义服务，还需要考虑 IDL 的分发与管理方式；
-
-#### Docker 镜像
-
-在当今容器时代，打包为 Docker 镜像已变为更通用的分发形式
-
-```sh
-docker build -t ${your-organization}/${project-name}:${tag-or-version} .
-```
-
-> 通常，在脚手架生成的根目录下 `/deploy` 有预先生成的镜像打包 Dockerfile 模版，可以按需修改后直接用来打包。
-
-
-## 第六步，部署
-Dubbo 微服务支持多种部署架构，与云原生基础设施做了很好的适配：
-* 传统的自建服务治理体系模式，需自行维护微服务需要的注册中心集群、配置中心集群等
-* 基于 Kubernetes Native Service 微服务体系，此时 Kubernetes 集群承担服务抽象、注册中心、配置中心等角色
-* 服务网格架构，服务治理角色由控制面承担，Dubbo 作为数据面组件与 Sidecar 部署在一起，或者采用无 Sidecar 的 Proxyless 架构
-
-#### 传统自建注册、配置中心模式
-
-Dubbo 微服务需要依赖一些中心化集群协调状态，以下是一个抽象的 Dubbo 部署架构图：
-
-![三中心部署架构图]()
-
-图：部署在虚拟机或 Kubernetes 集群的传统 Dubbo 微服务架构
-
-* 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
-* 配置中心 (可选)
- * 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
- * 负责服务治理规则（路由规则、动态配置等）的存储与推送。
-* 元数据中心 (可选)
- * 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
- * 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
-
-以上三个中心集群并不是运行 Dubbo
的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会从独立的注册中心开始 Dubbo
服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。注册中心、配置中心和元数据中心都是逻辑概念，它们完全可以是同一个物理集群，如部署一个
Zookeeper 集群同时作为注册中心、配置中心和元数据中心。
-
-如您是在 Kubernetes 搭建 Dubbo 微服务集群，请参考 [如何在 Kubernetes 集群部署 Dubbo 服务]() 了解更多。
-
-#### Kubernetes 原生服务
-
-![参考下 Spring Kubernetes 等的架构图]()
-
-在这种模式下，Dubbo 服务将与 Kubernetes 原生服务实现概念对齐，同时，开发者也不再需要部署独立的注册、配置中心集群，这部分职责由
Kubernetes 及相应组件如 Service、ConfigMap、Deployment 等承担。具体是原理上，是由 Dubbo 节点直接与
Kubernete api-server 或 DNS 通信实现。
-
-请参考 [Dubbo Kubernetes 原生服务任务]() 了解更多
-
-#### 服务网格
-
-Dubbo 服务可以无缝接入 Istio 体系，并且，Dubbo 支持更灵活的数据面部署形式
-* Sidecar 模式，Dubbo 可以与 Envoy 等代理部署在一起，实现流量拦截和治理
-* Proxyless 模式，Dubbo 通过直接与 Istio 等控制面通信，实现与 Sidecar 模式对等能力的同时，减少了部署成本和性能损耗。
-
-
-
-具体可参见 [Dubbo 服务网格]() 部分说明。
-
-## 第七步，观测服务状态
-
-可以通过 Dubbo 官方提供的 Admin 控制台非常方便的观测服务运行状态。
-
-![Admin 截图]()
-
-请参考 [如何部署 Admin]() 了解如何将 Admin 部署您的开发或生产环境。
-
-> 注意：部署过程中必须要配置 Admin 连接到您正在使用的注册中心或配置中心集群，保证 Admin 和 Dubbo 微服务集群共享相同数据源。
-
-如果您将 Dubbo 部署在服务网格架构，则还可以使用对应控制面产品支持的控制台来观测 Dubbo 服务状态，如 Istio、Kiali。更多可观测能力如
Accessing Log、Tracing 等，请参考[可观测性]()文档。
-
-## 第八步，服务治理
-为了使 Dubbo 服务稳定、可控的运行，我们需要在运行态对 Dubbo 服务进行治理。
-
-首先，可以通过 Dubbo Admin 完成绝大多数的治理需求，如查看服务状态、下发流量规则等
-
-![Dubbo Admin 治理效果图]()
-
-对于更高阶的治理诉求，可通过以下内容了解：
-
-* [网关流量接入]()，通过网关实现前端 HTTP 流量接入 Dubbo 服务
-* [限流降级]()，通过 Sentinel 等突发流量，就要用到限流降级能力，
-* [数据一致性]()，了解 Dubbo 服务的分布式事物解决方案
-* [全链路追踪]()，了解 Dubbo 服务如何接入 Zipkin、Skywalking、OpenTracing 等全链路监控组件
-* [服务发现]()，了解 Dubbo 的服务发现机制和扩展实现
-* [流量管控]()，了解 Dubbo 丰富的流量管控规则定义及使用方式
-
diff --git a/content/zh/overview/tasks/api-management/_index.md
b/content/zh/overview/tasks/api-management/_index.md
deleted file mode 100755
index 0921f3d55a4..00000000000
--- a/content/zh/overview/tasks/api-management/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-type: docs
-title: "API管理"
-linkTitle: "API管理"
-description: ""
-weight: 20
-no_list: true
----
diff --git a/content/zh/overview/tasks/ecosystem/_index.md
b/content/zh/overview/tasks/ecosystem/_index.md
index 78a6aaa6ddb..33a7a7bc5ac 100755
--- a/content/zh/overview/tasks/ecosystem/_index.md
+++ b/content/zh/overview/tasks/ecosystem/_index.md
@@ -1,9 +1,9 @@
---
type: docs
-title: "服务治理"
-linkTitle: "服务治理"
-description: "演示如何解决 Dubbo 微服务治理问题，如事务、全链路跟踪、限流降级等。"
+title: "微服务生态"
+linkTitle: "微服务生态"
+description: "围绕 Dubbo 生态的限流降级、全链路追踪、分布式一致性等解决方案"
weight: 40
no_list: true
---
@@ -36,7 +36,7 @@ no_list: true
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <p>http 网关接入（文档建设中）</p>
+ <a href='{{< relref "./rate-limit/" >}}'>网关接入</a>
</h4>
<p>通过网关 http 到 dubbo 协议转换，实现前端流量接入后端 dubbo 服务。</p>
</div>
@@ -46,7 +46,67 @@ no_list: true
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <p>Spring Cloud 体系互通（文档建设中）</p>
+ <a href='{{< relref "./rate-limit/" >}}'>全链路追踪 Tracing</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./rate-limit/" >}}'>异步消息</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./rate-limit/" >}}'>控制台 Admin</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./rate-limit/" >}}'>服务发现</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./rate-limit/" >}}'>配置中心</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./rate-limit/" >}}'>元数据中心</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./rate-limit/" >}}'>Spring Cloud 体系互通</a>
</h4>
<p>演示如何通过 Dubbo3 应用级服务发现机制，实现和 Spring Cloud 的 rest 协议互通。</p>
</div>
diff --git a/content/zh/overview/tasks/microservice-demo/_index.md
b/content/zh/overview/tasks/microservice-demo/_index.md
deleted file mode 100755
index e385bd0fc4b..00000000000
--- a/content/zh/overview/tasks/microservice-demo/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-type: docs
-title: "示例初始化"
-linkTitle: "示例初始化"
-description: ""
-weight: 10
-no_list: true
----
diff --git a/content/zh/overview/tasks/migration/2to3.md
b/content/zh/overview/tasks/migration/2to3.md
deleted file mode 100644
index 9c3280e7c2a..00000000000
--- a/content/zh/overview/tasks/migration/2to3.md
+++ /dev/null
@@ -1,44 +0,0 @@
----
-type: docs
-title: "升级到 Dubbo3"
-linkTitle: "升级到 Dubbo3"
-weight: 1
-description: "快速了解 Dubbo 3 的升级步骤与兼容性"
----
-
-**无需改动任何代码，直接升级到 Dubbo 3.0。**
-
-在 3.0 版本的设计与开发之初，我们就定下了兼容老版本 Dubbo 用户（2.5、2.6、2.7）的目标。因此，往 3.0
版本的升级过程将会是完全透明的，用户无需做任何业务改造，升级 3.x 后的框架行为将保持与 2.x 版本完全一致。
-
-```xml
-<dependency>
- <groupId>org.apache.dubbo</groupId>
- <artifactId>dubbo</artifactId>
- <version>3.0.10</version>
-</dependency>
-```
-
-
-但也要注意，透明升级仅仅是通往 3.0 的第一步，因为 "框架行为保持一致" 也就意味着用户将无法体验到 3.0 的新特性。**如果要启用 3.0
的带来的新特性，用户则需要进行一定的改造，我们称这个过程为迁移，这是一个按需开启的过程。**
-
-
-
-因此，对老用户而言，有两条不同的迁移路径：
-
-* **分两步走，先以兼容模式推动业务升级到 3.0 版本（无需改造），之后在某些时机按需启用新特性（按需改造）；**
-* **升级与迁移同步完成，在业务升级到 3.0 版本的同时，完成改造并启用新特性；**
-
-
-
-Dubbo 3.0 提供的新特性包括：
-
-* **新的地址发现模型（应用级服务发现）。**
- *
查看[应用级服务发现迁移示例](/zh/docs3-v2/java-sdk/upgrades-and-compatibility/service-discovery/service-discovery-samples/)。
- *
查看[应用级服务发现的迁移步骤](/zh/docs3-v2/java-sdk/upgrades-and-compatibility/service-discovery/migration-service-discovery/)
- *
查看[应用级服务发现地址迁移规则说明](/zh/docs3-v2/java-sdk/upgrades-and-compatibility/service-discovery/service-discovery-rule/)
-* **下一代基于 HTTP/2 的 Triple 协议。**
- * 查看[Triple
协议迁移步骤](/zh/docs3-v2/java-sdk/upgrades-and-compatibility/migration-triple/)
- * 查看 [Triple
协议使用方式](/zh/docs3-v2/java-sdk/reference-manual/protocol/triple/guide/)
- * 查看 [Triple
协议设计与实现](/zh/docs3-v2/java-sdk/reference-manual/protocol/triple/overview/)。
-* **统一的路由规则。**
- *
查看[统一路由规则设计与实现](/zh/docs3-v2/java-sdk/advanced-features-and-usage/traffic/mesh-style/)
\ No newline at end of file
diff --git a/content/zh/overview/tasks/migration/_index.md
b/content/zh/overview/tasks/migration/_index.md
deleted file mode 100755
index fc8a16a4aad..00000000000
--- a/content/zh/overview/tasks/migration/_index.md
+++ /dev/null
@@ -1,49 +0,0 @@
-
----
-type: docs
-title: "版本迁移"
-linkTitle: "版本迁移"
-description: "演示如何以最小代价迁移到 Dubbo3 并开启各项新特性。"
-weight: 80
-no_list: true
----
-
-{{< blocks/section color="white" height="auto">}}
-<div class="td-content list-page">
- <div class="lead"></div><header class="article-meta">
- </header><div class="row">
- <div class="col-sm col-md-6 mb-4 mb-md-0">
- <div class="h-100 card shadow" href="#">
- <div class="card-body">
- <h4 class="card-title">
- <a href='{{< relref "./2to3/" >}}'>平滑升级到 Dubbo3 </a>
- </h4>
- <p>平滑升级到 Dubbo3 版本。</p>
- </div>
- </div>
- </div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
- <div class="h-100 card shadow">
- <div class="card-body">
- <h4 class="card-title">
- <a href='{{< relref "./service-discovery-samples/"
>}}'>迁移到 Dubbo3 应用级服务发现</a>
- </h4>
- <p>迁移到 Dubbo3 应用级服务发现。</p>
- </div>
- </div>
- </div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
- <div class="h-100 card shadow">
- <div class="card-body">
- <h4 class="card-title">
- <a href='{{< relref "./migration-triple/" >}}'>迁移到 Triple
协议</a>
- </h4>
- <p>迁移到 Dubbo3 Triple 协议</p>
- </div>
- </div>
- </div>
-</div>
-<hr>
-</div>
-
-{{< /blocks/section >}}
\ No newline at end of file
diff --git a/content/zh/overview/tasks/migration/migration-triple.md
b/content/zh/overview/tasks/migration/migration-triple.md
deleted file mode 100644
index 90fda127807..00000000000
--- a/content/zh/overview/tasks/migration/migration-triple.md
+++ /dev/null
@@ -1,38 +0,0 @@
----
-type: docs
-linkTitle: "Triple 协议"
-title: "Dubbo 协议迁移至 Triple 协议指南"
-weight: 2
-description: "Triple 协议迁移指南"
----
-
-## Triple 介绍
-
-`Triple` 协议的格式和原理请参阅 [RPC 通信协议](/zh/docs/concepts/rpc-protocol/)
-
-根据 Triple 设计的目标，`Triple` 协议有以下优势:
-
-- 具备跨语言交互的能力，传统的多语言多 SDK 模式和 Mesh 化跨语言模式都需要一种更通用易扩展的数据传输协议。
-- 提供更完善的请求模型，除了支持传统的 Request/Response 模型（Unary 单向通信），还支持 Stream（流式通信） 和
Bidirectional（双向通信）。
-- 易扩展、穿透性高，包括但不限于 Tracing / Monitoring 等支持，也应该能被各层设备识别，网关设施等可以识别数据报文，对 Service
Mesh 部署友好，降低用户理解难度。
-- 完全兼容 grpc，客户端/服务端可以与原生grpc客户端打通。
-- 可以复用现有 grpc 生态下的组件, 满足云原生场景下的跨语言、跨环境、跨平台的互通需求。
-
-当前使用其他协议的 Dubbo 用户，框架提供了兼容现有序列化方式的迁移能力，在不影响线上已有业务的前提下，迁移协议的成本几乎为零。
-
-需要新增对接 Grpc 服务的 Dubbo 用户，可以直接使用 Triple 协议来实现打通，不需要单独引入 grpc client
来完成，不仅能保留已有的 Dubbo 易用性，也能降低程序的复杂度和开发运维成本，不需要额外进行适配和开发即可接入现有生态。
-
-对于需要网关接入的 Dubbo 用户，Triple 协议提供了更加原生的方式，让网关开发或者使用开源的 grpc 网关组件更加简单。网关可以选择不解析
payload ，在性能上也有很大提高。在使用 Dubbo 协议时，语言相关的序列化方式是网关的一个很大痛点，而传统的 HTTP 转 Dubbo
的方式对于跨语言序列化几乎是无能为力的。同时，由于 Triple 的协议元数据都存储在请求头中，网关可以轻松的实现定制需求，如路由和限流等功能。
-
-
-## Dubbo2 协议迁移流程
-
-Dubbo2 的用户使用 dubbo 协议 + 自定义序列化，如 hessian2 完成远程调用。
-
-而 Grpc 的默认仅支持 Protobuf 序列化，对于 Java 语言中的多参数以及方法重载也无法支持。
-
-Dubbo3的之初就有一条目标是完美兼容 Dubbo2，所以为了 Dubbo2 能够平滑升级， Dubbo
框架侧做了很多工作来保证升级的无感，目前默认的序列化和 Dubbo2 保持一致为`hessian2`。
-
-**所以，如果决定要升级到 Dubbo3 的 `Triple` 协议，只需要修改配置中的协议名称为 `tri` (注意: 不是triple)即可。**
-
-关于 `Triple` 协议更多使用说明可以参考 [Triple
协议迁移指南](/zh/docs3-v2/java-sdk/upgrades-and-compatibility/migration-triple/)。
\ No newline at end of file
diff --git a/content/zh/overview/tasks/migration/service-discovery-samples.md
b/content/zh/overview/tasks/migration/service-discovery-samples.md
deleted file mode 100644
index 81f5e9995fa..00000000000
--- a/content/zh/overview/tasks/migration/service-discovery-samples.md
+++ /dev/null
@@ -1,76 +0,0 @@
----
-type: docs
-title: "Dubbo3 应用级服务发现"
-linkTitle: "应用级服务发现"
-weight: 5
-description: "本文具体说明了用户在升级到 Dubbo 3.0 之后如何快速开启应用级服务发现新特性。"
----
-
-应用级服务发现为应用间服务发现的协议，因此使用应用级服务发现需要消费端和服务端均升级到 Dubbo 3.0
版本并开启新特性（默认开启）才能在链路中使用应用级服务发现，真正发挥应用级服务发现的优点。
-## 开启方式
-## 服务端
-应用升级到 Dubbo 3.0 后，服务端自动开启接口级 + 应用级双注册功能，默认无需开发者修改任何配置
-
-### 消费端
-应用升级到 Dubbo 3.0 后，消费端自动始接口级 + 应用级双订阅功能，默认无需开发者修改任何配置。建议在服务端都升级到 Dubbo 3.0
并开启应用级注册以后通过规则配置消费端关闭接口级订阅，释放对应的内存空间。
-
-## 详细说明
-### 服务端配置
-
-1. 全局开关
-
-应用配置（可以通过配置文件或者 -D 指定）`dubbo.application.register-mode` 为
instance（只注册应用级）、all（接口级+应用级均注册）开启全局的注册开关，配置此开关后，默认会向所有的注册中心中注册应用级的地址，供消费端服务发现使用。
->
示例：[https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-servicediscovery-migration/dubbo-servicediscovery-migration-provider2/src/main/resources/dubbo.properties](https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-servicediscovery-migration/dubbo-servicediscovery-migration-provider2/src/main/resources/dubbo.properties)
-
-```
-# 双注册
-dubbo.application.register-mode=all
-```
-```
-# 仅应用级注册
-dubbo.application.register-mode=instance
-```
-
-2. 注册中心地址参数配置
-
-注册中心的地址上可以配置 `registry-type=service`
来显示指定该注册中心为应用级服务发现的注册中心，带上此配置的注册中心将只进行应用级服务发现。
->
示例：[https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-demo-servicediscovery-xml/servicediscovery-provider/src/main/resources/spring/dubbo-provider.xml](https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-demo-servicediscovery-xml/servicediscovery-provider/src/main/resources/spring/dubbo-provider.xml)
-
-```xml
-<dubbo:registry
address="nacos://${nacos.address:127.0.0.1}:8848?registry-type=service"/>
-```
-### 消费端订阅模式
-FORCE_INTERFACE：仅接口级订阅，行为和 Dubbo 2.7 及以前版本一致。
-APPLICATION_FIRST：接口级 +
应用级多订阅，如果应用级能订阅到地址就使用应用级的订阅，如果订阅不到地址则使用接口级的订阅，以此保证迁移过程中最大的兼容性。（注：由于存在同时进行订阅的行为，此模式下内存占用会有一定的增长，因此在所有服务端都升级到
Dubbo 3.0 以后建议迁移到 FORCE_APPLICATION 模式降低内存占用）
-FORCE_APPLICATION：仅应用级订阅，将只采用全新的服务发现模型。
-### 消费端配置
-
-1. 默认配置（不需要配置）
-
-升级到 Dubbo 3.0
后默认行为为接口级+应用级多订阅，如果应用级能订阅到地址就使用应用级的订阅，如果订阅不到地址则使用接口级的订阅，以此保证最大的兼容性。
-
-2. 订阅参数配置
-
-应用配置（可以通过配置文件或者 -D 指定）`dubbo.application.service-discovery.migration` 为
`APPLICATION_FIRST` 可以开启多订阅模式，配置为 `FORCE_APPLICATION` 可以强制为仅应用级订阅模式。
-具体接口订阅可以在 `ReferenceConfig` 中的 `parameters` 中配置 Key 为 `migration.step`，Value 为
`APPLICATION_FIRST` 或 `FORCE_APPLICATION` 的键值对来对单一订阅进行配置。
->
示例：[https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-servicediscovery-migration/dubbo-servicediscovery-migration-consumer/src/test/java/org/apache/dubbo/demo/consumer/DemoServiceConfigIT.java](https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-servicediscovery-migration/dubbo-servicediscovery-migration-consumer/src/test/java/org/apache/dubbo/demo/consumer/DemoServiceConfigIT.java)
-
-```java
-System.setProperty("dubbo.application.service-discovery.migration",
"APPLICATION_FIRST");
-```
-```java
-ReferenceConfig<DemoService> referenceConfig = new
ReferenceConfig<>(applicationModel.newModule());
-referenceConfig.setInterface(DemoService.class);
-referenceConfig.setParameters(new HashMap<>());
-referenceConfig.getParameters().put("migration.step", mode);
-return referenceConfig.get();
-```
-
-3. 动态配置（优先级最高，可以在运行时修改配置）
-
-此配置需要基于配置中心进行推送，Key 为应用名 + `.migration` （如 `demo-application.migraion`），Group
为
`DUBBO_SERVICEDISCOVERY_MIGRATION`。规则体配置详见[接口级服务发现迁移至应用级服务发现指南](/zh/docs3-v2/java-sdk/upgrades-and-compatibility/service-discovery/service-discovery-rule/)。
->
示例：[https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-servicediscovery-migration/dubbo-servicediscovery-migration-consumer/src/main/java/org/apache/dubbo/demo/consumer/UpgradeUtil.java](https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-cloud-native/dubbo-servicediscovery-migration/dubbo-servicediscovery-migration-consumer/src/main/java/org/apache/dubbo/demo/consumer/UpgradeUtil.java)
-
-```java
-step: FORCE_INTERFACE
-```
diff --git a/content/zh/overview/tasks/observability/admin.md
b/content/zh/overview/tasks/observability/admin.md
index e8d4ea04da0..a009a12fdff 100644
--- a/content/zh/overview/tasks/observability/admin.md
+++ b/content/zh/overview/tasks/observability/admin.md
@@ -2,7 +2,23 @@
type: docs
title: "Admin"
linkTitle: "Admin"
-description: "演示如何将 Dubbo 部署到 Kubernetes 并复用 Kubernetes Native Service。"
+description: ""
weight: 60
no_list: true
---
+
+大盘
+
+流量治理
+
+服务查询
+
+服务测试
+
+服务文档
+
+服务监控
+
+规则管理
+
+IDL 管理
\ No newline at end of file
diff --git a/content/zh/overview/tasks/prepare/_index.md
b/content/zh/overview/tasks/prepare/_index.md
deleted file mode 100755
index 0ea7c65efa2..00000000000
--- a/content/zh/overview/tasks/prepare/_index.md
+++ /dev/null
@@ -1,8 +0,0 @@
----
-type: docs
-title: "环境准备"
-linkTitle: "环境准备"
-description: ""
-weight: 5
-no_list: true
----
diff --git a/content/zh/overview/tasks/prepare/prepare-kubernetes.md
b/content/zh/overview/tasks/prepare/prepare-kubernetes.md
deleted file mode 100644
index 5fb9136222c..00000000000
--- a/content/zh/overview/tasks/prepare/prepare-kubernetes.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-type: docs
-title: "虚拟机开发环境准备"
-linkTitle: "虚拟机开发环境准备"
-weight: 1
-description: ""
----
diff --git a/content/zh/overview/tasks/prepare/prepare-vm.md
b/content/zh/overview/tasks/prepare/prepare-vm.md
deleted file mode 100644
index c8c9616a057..00000000000
--- a/content/zh/overview/tasks/prepare/prepare-vm.md
+++ /dev/null
@@ -1,7 +0,0 @@
----
-type: docs
-title: "Kubernetes 开发环境准备"
-linkTitle: "Kubernetes 开发环境准备"
-weight: 2
-description: ""
----
diff --git a/content/zh/overview/tasks/triple/_index.md
b/content/zh/overview/tasks/protocols/_index.md
similarity index 61%
rename from content/zh/overview/tasks/triple/_index.md
rename to content/zh/overview/tasks/protocols/_index.md
index 4ee14bc3ca4..25f467579bb 100755
--- a/content/zh/overview/tasks/triple/_index.md
+++ b/content/zh/overview/tasks/protocols/_index.md
@@ -3,7 +3,7 @@
type: docs
title: "通信协议"
linkTitle: "通信协议"
-description: "演示 Triple 跨语言通信、Streaming 等能力"
+description: "演示 Dubbo 支持的通信协议"
weight: 50
no_list: true
---
@@ -16,7 +16,7 @@ no_list: true
<div class="h-100 card shadow" href="#">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./idl/" >}}'>使用 IDL 定义服务</a>
+ <a href='{{< relref "./triple/" >}}'>基于 HTTP/2 的 Dubbo3
通信协议</a>
</h4>
<p>使用 IDL 定义跨语言服务</p>
</div>
@@ -26,7 +26,7 @@ no_list: true
<div class="h-100 card shadow" href="#">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./wrap/" >}}'>Pojo 序列化兼容模式</a>
+ <a href='{{< relref "./triple/" >}}'>基于 TCP 的 Dubbo2
通信协议</a>
</h4>
<p>Pojo 序列化兼容模式</p>
</div>
@@ -36,7 +36,17 @@ no_list: true
<div class="h-100 card shadow" href="#">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./streaming/" >}}'>Streaming 通信</a>
+ <a href='{{< relref "./triple/" >}}'>HTTP 通信协议</a>
+ </h4>
+ <p>Stream 通信模式</p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="h-100 card shadow" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./triple/" >}}'>gRPC 通信协议</a>
</h4>
<p>Stream 通信模式</p>
</div>
diff --git a/content/zh/overview/tasks/protocols/dubbo2.md
b/content/zh/overview/tasks/protocols/dubbo2.md
new file mode 100644
index 00000000000..df7a010b2e3
--- /dev/null
+++ b/content/zh/overview/tasks/protocols/dubbo2.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "基于 HTTP 的通信协议"
+linkTitle: "HTTP 协议"
+description: ""
+weight: 20
+---
\ No newline at end of file
diff --git a/content/zh/overview/tasks/protocols/grpc.md
b/content/zh/overview/tasks/protocols/grpc.md
new file mode 100644
index 00000000000..a71ef11f2e9
--- /dev/null
+++ b/content/zh/overview/tasks/protocols/grpc.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "gRPC 通信协议"
+linkTitle: "gRPC 协议"
+description: ""
+weight: 40
+---
\ No newline at end of file
diff --git a/content/zh/overview/tasks/protocols/http.md
b/content/zh/overview/tasks/protocols/http.md
new file mode 100644
index 00000000000..4457d9eff14
--- /dev/null
+++ b/content/zh/overview/tasks/protocols/http.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "基于 TCP 的 RPC 通信协议"
+linkTitle: "Dubbo2 协议"
+description: ""
+weight: 30
+---
\ No newline at end of file
diff --git a/content/zh/overview/tasks/protocols/triple/_index.md
b/content/zh/overview/tasks/protocols/triple/_index.md
new file mode 100755
index 00000000000..6d027b90676
--- /dev/null
+++ b/content/zh/overview/tasks/protocols/triple/_index.md
@@ -0,0 +1,8 @@
+
+---
+type: docs
+title: "Dubbo3 通信协议 -- Triple"
+linkTitle: "Triple 协议"
+description: ""
+weight: 10
+---
\ No newline at end of file
diff --git a/content/zh/overview/tasks/triple/idl.md
b/content/zh/overview/tasks/protocols/triple/idl.md
similarity index 100%
rename from content/zh/overview/tasks/triple/idl.md
rename to content/zh/overview/tasks/protocols/triple/idl.md
diff --git a/content/zh/overview/tasks/triple/streaming.md
b/content/zh/overview/tasks/protocols/triple/streaming.md
similarity index 100%
rename from content/zh/overview/tasks/triple/streaming.md
rename to content/zh/overview/tasks/protocols/triple/streaming.md
diff --git a/content/zh/overview/tasks/triple/wrap.md
b/content/zh/overview/tasks/protocols/triple/wrap.md
similarity index 100%
rename from content/zh/overview/tasks/triple/wrap.md
rename to content/zh/overview/tasks/protocols/triple/wrap.md
diff --git a/content/zh/overview/tasks/traffic-management/_index.md
b/content/zh/overview/tasks/traffic-management/_index.md
index d47b46f992e..0a466b6d266 100755
--- a/content/zh/overview/tasks/traffic-management/_index.md
+++ b/content/zh/overview/tasks/traffic-management/_index.md
@@ -8,77 +8,183 @@ weight: 30
no_list: true
---
+此任务基于一个简单的线上商城微服务系统演示了 Dubbo 的流量管控能力。
+
+线上商城的架构图如下：
+
+
+
+系统由 5 个微服务应用组成：
+* `Frontend 商城主页`，作为与用户交互的 web 界面，通过调用 `User`、`Detail`、`Order`
等提供用户登录、商品展示和订单管理等服务。
+* `User 用户服务`，负责用户数据管理、身份校验等。
+* `Order 订单服务`，提供订订单创建、订单查询等服务，依赖 `Detail` 服务校验商品库存等信息。
+* `Detail 商品详情服务`，展示商品详情信息，调用 `Comment` 服务展示用户对商品的评论记录。
+* `Comment 评论服务`，管理用户对商品的评论数据。
+
+## 部署商场系统
+
+为方便起见，我们将整个系统部署在 Kubernetes 集群，执行以下命令即可完成商城项目部署，项目源码示例在
[dubbo-samples/task](https://github.com/apache/dubbo-samples/tree/master/10-task/dubbo-samples-shop)。
+
+```sh
+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都已正常运行：
+```sh
+$ kubectl get services -n dubbo-demo
+
+```
+
+```sh
+$ kubectl get pods -n dubbo-demo
+
+```
+
+为了保障系统完整性，除了商城相关的几个微服务应用，示例还在后台拉起了 Nacos 注册配置中心、Dubbo Admin 控制台 和 Skywalking
全链路追踪系统。
+
+```sh
+$ kubectl get services -n dubbo-system
+
+```
+
+```sh
+$ kubectl get pods -n dubbo-system
+
+```
+
+## 获得访问地址
+执行以下命令，将集群端口映射到本地端口：
+
+```sh
+kubectl port-forward -n dubbo-demo deployment/shop-frontend 8080:8080
+```
+
+```sh
+kubectl port-forward -n dubbo-system service/dubbo-admin 38080:38080
+```
+
+```sh
+kubectl port-forward -n dubbo-system service/skywalking-oap-dashboard 8082:8082
+```
+
+此时，打开浏览器，即可通过以下地址访问：
+* 商城首页 [http://localhost:8080/](http://localhost:8080/)
+* Dubbo Admin 控制台 [http://localhost:38080/](http://localhost:38080/)
+* Skywalking 控制台 [http://localhost:8082/](http://localhost:8082/)
+
+## 任务项
+接下来，试着通过如下任务项给商城增加一些流量管控规则吧。
+
{{< blocks/section color="white" height="auto">}}
<div class="td-content list-page">
<div class="lead"></div><header class="article-meta">
</header><div class="row">
- <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow" href="#">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./timeout/" >}}'>动态调整请求超时时间</a>
+ <a href='{{< relref "./timeout/" >}}'>调整超时时间</a>
+ </h4>
+
<p>通过在运行期动态的调整服务超时时间，可以有效的应对超时设置不合理、系统突发情况等导致的服务频繁超时、服务阻塞等问题，提升系统稳定性。</p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./retry/" >}}'>增加重试次数</a>
+ </h4>
+ <p>在服务初次调用失败后，通过重试能有效的提升总体调用成功率。</p>
+ </div>
+ </div>
+ </div>
+ <div class="col-sm col-md-6 mb-4">
+ <div class="h-100 card shadow">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./accesslog/" >}}'>访问日志</a>
</h4>
- <p>给 Dubbo 请求设置超时时间可以有效的提高系统稳定性，避免个别服务阻塞占用过多资源。<br/><br/>
而通过在运行期动态的调整服务超时时间，可以有效的应对超时设置不合理、系统突发情况等导致的服务频繁超时、服务阻塞等问题，提升系统稳定性。</p>
+ <p>访问日志可以很好的记录某台机器在某段时间内处理的所有服务请求信息，运行态动态的开启访问日志对于排查问题非常有帮助。
+ </p>
</div>
</div>
</div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./weight/" >}}'>通过权重调整流量分布</a>
+ <a href='{{< relref "./region/" >}}'>同机房/区域优先</a>
</h4>
- <p>通过权重调整流量分布</p>
+
<p>同机房/区域优先是指应用调用服务时，优先调用同机房/区域的服务提供者，避免了跨区域带来的网络延时，从而减少了调用的响应时间。
+ </p>
</div>
</div>
</div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./isolation/" >}}'>临时踢除服务实例</a>
+ <a href='{{< relref "./isolation/" >}}'>环境隔离</a>
</h4>
- <p>临时踢除服务实例</p>
+ <p>通过为集群中的某一个或多个应用划分逻辑隔离环境，可用于灰度环境或多套测试环境搭建。
+ </p>
</div>
</div>
</div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./traffic-gray/" >}}'>流量灰度</a>
+ <a href='{{< relref "./arguments/" >}}'>参数路由</a>
</h4>
- <p>根据请求上下文中的标签，实现对流量进行约束，实现灰度发布</p>
+ <p>如基于用户 ID 路由流量，将一小部分用户请求转发到最新发布的产品版本，以验证新版本的稳定性、获取用户的产品体验反馈等。
+ </p>
</div>
</div>
</div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./traffic-routing/" >}}'>根据请求条件路由</a>
+ <a href='{{< relref "./weight/" >}}'>权重比例</a>
</h4>
- <p>根据请求发起方、请求的方法条件路由</p>
+ <p>通过规则动态调整单个或一组机器的权重，可以在运行态改变请求流量的分布，实现动态的按比例的流量路由。
+ </p>
</div>
</div>
</div>
- <div class="col-sm col-md-6 mb-4 mb-md-0" style="margin-bottom:20px">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./traffic-condition/" >}}'>流量隔离</a>
+ <a href='{{< relref "./mock/" >}}'>服务降级</a>
</h4>
- <p>将不同环境的服务流量进行隔离，保证服务相互不受影响</p>
+ <p>服务降级的核心目标就是针对这些弱依赖项，在弱依赖不可用或调用失败时，通过返回降级结果尽可能的维持功能完整。
+ </p>
</div>
</div>
</div>
- <div class="col-sm col-md-6 mb-4 mb-md-0">
+ <div class="col-sm col-md-6 mb-4">
<div class="h-100 card shadow">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./zone/" >}}'>同机房/区域优先</a>
+ <a href='{{< relref "./host/" >}}'>固定机器导流</a>
</h4>
- <p>应用调用服务时，优先调用同机房/区域的服务提供者。</p>
+ <p>通过将请求固定的转发某一台提供者机器，帮助快速复现开发或线上问题。
+ </p>
</div>
</div>
</div>
diff --git a/content/zh/overview/tasks/traffic-management/accesslog.md
b/content/zh/overview/tasks/traffic-management/accesslog.md
new file mode 100644
index 00000000000..466ef5094d2
--- /dev/null
+++ b/content/zh/overview/tasks/traffic-management/accesslog.md
@@ -0,0 +1,81 @@
+---
+type: docs
+title: "通过动态开启访问日志跟踪服务调用情况"
+linkTitle: "访问日志"
+weight: 3
+description: ""
+---
+
+访问日志可以很好的记录某台机器在某段时间内处理的所有服务请求信息，包括请求接收时间、远端
IP、请求参数、响应结果等，运行态动态的开启访问日志对于排查问题非常有帮助。
+
+## 开始之前
+* [部署 Shop 商城项目](../#部署商场系统)
+* 部署并打开 [Dubbo Admin]()
+
+## 任务详情
+
+商城的所有用户服务都由 `User` 应用的 UserService 提供，通过这个任务，我们为 `User`
应用的某一台或几台机器开启访问日志，以便观察用户服务的整体访问情况。
+
+### 动态开启访问日志
+
+Dubbo 通过 `accesslog` 标记识别访问日志的开启状态，我们可以指定日志文件的输出位置，也可以单独打开某台机器的访问日志。
+
+
+
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【访问日志】
+3. 点击 "创建"，输入应用名 `shop-user` 并勾选 "开启访问日志"（此时访问日志将和普通日志打印在一起）。
+
+![Admin 访问日志设置截图]()
+
+再次访问登录页面，登录到 `User` 应用的任意一台机器，可以看到如下格式的访问日志。
+
+```text
+[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
+
+**规则体**
+
+```yaml
+configVersion: v3.0
+enabled: true
+configs:
+ - side: provider
+ parameters:
+ accesslog: true
+```
+
+以下是开启访问日志的关键配置
+
+```yaml
+parameters:
+ accesslog: true
+```
+
+accesslog 的有效值如下：
+* `true` 或 `default` 时，访问日志将随业务 logger 一同输出，此时可以在应用内提前配置 `dubbo.accesslog`
appender 调整日志的输出位置和格式
+* 具体的文件路径如 `/home/admin/demo/dubbo-access.log`，这样访问日志将打印到指定的文件内
+
+在 Admin 界面，还可以单独指定开启某一台机器的访问日志，以方便精准排查问题，对应的后台规则如下：
+
+```yaml
+configVersion: v3.0
+enabled: true
+configs:
+ - match
+ address:
+ oneof:
+ - wildcard: "{ip}:*"
+ side: provider
+ parameters:
+ accesslog: true
+```
+
+其中，`{ip}` 替换为具体的机器地址即可。
\ No newline at end of file
diff --git a/content/zh/overview/tasks/traffic-management/arguments.md
b/content/zh/overview/tasks/traffic-management/arguments.md
new file mode 100644
index 00000000000..941adb0038e
--- /dev/null
+++ b/content/zh/overview/tasks/traffic-management/arguments.md
@@ -0,0 +1,83 @@
+---
+type: docs
+title: "根据请求参数引导流量分布"
+linkTitle: "参数路由"
+weight: 6
+description: ""
+---
+
+根据请求参数值转发流量，是一种非常灵活且实用的流量管控策略。比如微服务实践中，根据参数（如用户
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`
方法定义如下，第二个参数为用户名。
+
+```java
+public interface DetailService {
+ Item getItem(long sku, String username);
+}
+```
+
+因此，接下来我们就为 `DetailService` 服务的 `getItem` 方法增加参数路由规则，如果用户参数是 `dubbo` 就转发到 v2
版本的服务。
+
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【服务治理】 > 【参数路由】
+3. 点击 "创建" 按钮，输入。
+
+![Admin 参数路由设置截图]()
+
+方法参数的索引从 `0` 开始，我们上面填入 `1` 表示根据第二个参数进行流量转发。
+
+#### 规则详解
+
+**规则 key** ：`org.apache.dubbo.samples.DetailService`
+
+**规则体**
+```yaml
+configVersion: v3.0
+key: org.apache.dubbo.samples.DetailService
+scope: service
+force: false
+enabled: true
+priority: 1
+conditions:
+ - method=getItem & arguments[1]=dubbo => orderVersion=v2
+```
+
+* `method=getItem & arguments[1]=dubbo` 表示流量规则匹配 `getItem` 方法调用的第二个参数，当参数值为
`dubbo` 时做进一步的地址子集筛选。
+* `orderVersion=v2` 将过滤出所有带有 `orderVersion=v2` 标识的 URL 地址子集（在示例部署中，我们所有 detail
v2 的实例都已经打上了 `orderVersion=v2` 标签）。
+
+```yaml
+conditions:
+ - method=getItem & arguments[1]=dubbo => orderVersion=v2
+```
+
+`force: false` 表示如果没有 `type=vip` 的地址，则随机访问所有可用地址。
+
+## 其他事项
+本示例只是 Dubbo 条件路由的一种使用场景，除了根据方法名、参数匹配进行流量转发，条件路由还可以根据附加参数 Attachments、URL
中的数据等进行流量转发，同时匹配条件也支持范围、通配符等，比如：
+* attachments[key]=hello*
+* arguments[0]=1~100
+* url_key=value
+
+更为灵活的是，条件路由的匹配条件支持扩展，用户可以自定义匹配条件的来源和格式，具体可参见 [条件路由规则说明]()。
diff --git a/content/zh/overview/tasks/traffic-management/host.md
b/content/zh/overview/tasks/traffic-management/host.md
new file mode 100644
index 00000000000..1f3ac5f2a0b
--- /dev/null
+++ b/content/zh/overview/tasks/traffic-management/host.md
@@ -0,0 +1,61 @@
+---
+type: docs
+title: "将流量点对点引导到一台机器 (如排查问题)"
+linkTitle: "固定机器导流"
+weight: 9
+description: ""
+---
+
+自动的地址发现和负载均衡机制有很多优势，它让我们构建可伸缩的分布式微服务系统成为可能，但这种动态的流量分配也带来很多复杂性。一个典型问题是我们无法再预测一次请求具体会落到那一台提供者机器上，但有时能预期或控制请求固定的发往某一台提供者机器在一些场景下会非常有用处，比如当开发者在测试甚至线上环境排查一些复杂问题时，如果能在某一台指定的机器上稳定复现问题现象，对于最终的问题排查肯定会带来很大帮助。
+
+## 开始之前
+
+* [部署 Shop 商城项目](../#部署商场系统)
+* 部署并打开 [Dubbo Admin]()
+
+## 任务详情
+
+本任务我们将以 User 服务作为示例，将商城中 Frontend 应用对用户详情方法的调用 `UserService#getInfo`
全部导流到一台固定实例上去。
+
+
+
+### 将用户详情服务调用导流到一台固定机器
+
+首先，确定部署 User 应用的实际机器列表
+
+```sh
+$ kubectl get pods -n dubbo-demo
+# list result here
+```
+
+为 `org.apache.dubbo.samples.UserService` 服务的 `getInfo`
方法调用设置条件路由规则，所有这个方法的调用全部转发到一台指定机器。
+
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【指定机器导流】
+3. 点击 "创建"，输入服务 `org.apache.dubbo.samples.UserService` 。
+
+![Admin 指定机器导流配置截图]()
+
+打开机器日志，刷新页面多触发机器用户详情服务调用，可以看到只有规则中指定实例中的日志在持续更新。
+
+#### 规则详解
+
+**规则 key** ：`org.apache.dubbo.samples.UserService`
+
+**规则体**
+```yaml
+configVersion: v3.0
+enabled: true
+force: false
+conditions:
+ - 'method=getInfo => host = {your ip address}'
+```
+
+替换 `{your ip address}` 为 User 实际的部署地址。
+
+## 清理
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的条件路由规则。
+
+## 其他事项
+在生产环境中引导流量到固定机器要做好安全性评估，避免单机负载过高影响系统稳定性，另外，云原生背景下的 IP 地址的变化更加频繁，IP
地址可能随时会失效，要注意及时清理绑定特定 IP 的路由规则。
diff --git a/content/zh/overview/tasks/traffic-management/isolation.md
b/content/zh/overview/tasks/traffic-management/isolation.md
index 3a55ca7d6e8..91d87d51eb2 100644
--- a/content/zh/overview/tasks/traffic-management/isolation.md
+++ b/content/zh/overview/tasks/traffic-management/isolation.md
@@ -1,78 +1,103 @@
---
type: docs
-title: "临时踢除问题服务实例"
-linkTitle: "临时踢除问题服务实例"
+title: "通过标签实现流量隔离环境（灰度、多套开发环境等）"
+linkTitle: "环境隔离"
weight: 5
-description: "在 Dubbo-Admin 临时踢除问题服务实例"
+description: ""
---
+无论是在日常开发测试环境，还是在预发生产环境，我们经常都会遇到流量隔离环境的需求。
+* 在日常开发中，为了避免开发测试过程中互相干扰，我们有搭建多套独立测试环境的需求，但通过搭建物理集群的方式成本非常高且不够灵活
+*
在生产发布过程中，为了保障新版本得到充分的验证，我们需要搭建一套完全隔离的线上灰度环境用来部署新版本服务，线上灰度环境能完全模拟生产运行情况，但只有固定的带有特定标记的线上流量会被导流到灰度环境，充分验证新版本的同时将线上变更风险降到最低。
-Dubbo提供临时踢除问题服务实例的服务治理能力，可以在无需重启应用的情况下，临时踢除问题服务实例。
-
-Dubbo可以通过XML配置，注解配置，动态配置实现临时踢除问题服务实例，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
+利用 Dubbo
提供的标签路由能力，可以非常灵活的实现流量隔离能力。可以单独为集群中的某一个或多个应用划分隔离环境，也可以为整个微服务集群划分隔离环境；可以在部署态静态的标记隔离环境，也可以在运行态通过规则动态的隔离出一部分机器环境。
+>
注意：标签路由是一套严格隔离的流量体系，对于同一个应用而言，一旦打了标签则这部分地址子集就被隔离出来，只有带有对应标签的请求流量可以访问这个地址子集，这部分地址不再接收没有标签或者具有不同标签的流量。举个例子，如果我们将一个应用进行打标，打标后划分为
tag-a、tag-b、无 tag 三个地址子集，则访问这个应用的流量，要么路由到 tag-a (当请求上下文 dubbo.tag=tag-a)，要么路由到
tag-b (dubbo.tag=tag-b)，或者路由到无 tag 的地址子集 (dubbo.tag 未设置)，不会出现混调的情况。
## 开始之前
-请确保成功运行Dubbo-Admin
+* [部署 Shop 商城项目](../#部署商场系统)
+* 部署并打开 [Dubbo Admin]()
+
+## 任务详情
+
+我们决定为商城系统建立一套完整的线上灰度验证环境，灰度环境和线上环境共享一套物理集群，需要我们通过 Dubbo
标签路由从逻辑上完全隔离出一套环境，做到灰度流量和线上流量互不干扰。
-## 背景信息
+
+
+### 为商城搭建一套完全隔离的灰度环境
+首先，为 User、Detail、Comment、Order 几个应用都部署灰度环境实例，我们为这部分实例都带有 `env=gray`
的环境标。部署可以通过以下命令快速完成
+
+```sh
+kubectl apply -f
https://raw.githubusercontent.com/apache/dubbo-samples/master/10-task/dubbo-samples-shop/deploy/Gray.yml
+```
-服务在线上运行的过程中，难免遇到某些节点有问题，为了不影响整体服务的正常运行，需要临时下线问题的服务实例。Dubbo-Admin提供了临时踢除问题服务实例能力，能够帮助您临时下线问题服务实例，不影响整体服务的运行。
+接下来，我们开始为几个应用分别增加标签规则，将刚刚部署的实例从普通流量实例隔离出来。
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【流量隔离】
+3. 点击 "创建"，输入 `shop-detail` 和流量隔离条件保存即可；重复为 `shop-comment`、`shop-order`
创建相同的隔离规则。
-## 操作步骤
+![Admin 灰度隔离环境设置截图]()
-### 动态配置
+以上规则为每个应用隔离出了一套独立的灰度环境，所有带有 `env=gray`
的标签都属于灰度环境。等待一小会确保规则下发完成，接下来就可以验证灰度流量在隔离环境中运行。
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 动态配置。
-3. 点击创建按钮，在创建动态配置面板中，填写规则内容，然后单击保存。
+为了模拟灰度流量，我们为商城示例首页设置了一个 `Login To Gray`
的入口来模拟从灰度环境进入商城的流量，在真实环境中这可以通过在入口网关根据某些规则识别流量并自动打标实现。
+
+通过 `Login To Gray` 登录后，之后所有请求 Detail、Comment、Order、User 服务的流量都会自动带有
`dubbo.tag=gray` 的标识，Dubbo 标签路由组件会识别这个标识，并将流量路由到刚才圈定的灰度环境（即所有 `env=gray` 的实例）。
#### 规则详解
-##### 配置模板
+我们需要通过 Admin 为 `shop-detail`、`shop-comment`、`shop-order`、`shop-user`
四个应用分别设置标签归组规则，以 `shop-detail` 为例：
+
+**规则 key** ：`shop-detail`
+
+**规则体**
```yaml
----
-configVersion: v2.7
-scope: application/service
-key: app-name/group+service+version
+configVersion: v3.0
+force: 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: shop-detail
+tags:
+ - name: gray
+ match:
+ - key: env
+ value:
+ exact: gray
```
-**对于临时踢除问题服务实例场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
+其中，`name` 为灰度环境的流量匹配条件，只有请求上下文中带有 `dubbo.tag=gray` 的流量才会被转发到隔离环境地址子集。请求上下文可通过
`RpcContext.getClientAttachment().setAttachment("dubbo.tag", "gray")` 传递。
+
+```yaml
+name: gray
+```
+
+`match` 指定了地址子集筛选条件，示例中我们匹配了所有地址 URL 中带有 `env=gray` 标签的地址列表（商城示例中 v2
版本部署的实例都带已经被打上这个标签）。
+
+```yaml
+match:
+ - key: env
+ value:
+ exact: gray
+```
+
+`force` 指定了是否允许流量跳出灰度隔离环境，这决定了某个服务发现灰度隔离环境没有可用地址时的行为，默认值为 `false` 表示会 fallback
到不属于任何隔离环境 (不带标签) 的普通地址集（不会 fallback 到任何已经归属其他隔离环境的 ip 地址）。示例中设置 `froce: true`
表示当灰度环境地址子集为空时，服务调用失败（No provider exception）。
+
+```yaml
+force: true
+```
+
+## 清理
+
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的流量隔离规则。
+
+## 其他事项
-1. 要修改整个应用的配置还是某个服务的配置。
- - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- - 服务：`scope: service, key:group+service+version `。
-2. 修改是作用到提供者端。
- - 提供者：`side: provider`。
-3. 配置是否只对某几个特定实例生效。
- - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- - 指定实例：`addersses[实例地址列表]`。
-4. 要修改的disabled参数。
+除了示例中演示的动态环境划分，也可以在部署态指定实例所属流量标签（通过一个特殊的 key `dubbo.provider.tag`
实现），这样当实例启动成功后就已经被自动圈定在某个流量环境，具体配置方式可参见 [标签路由]() 说明。
-## 结果验证
-选择和临时踢除问题服务实例配置相关的应用，触发该调用验证。
\ No newline at end of file
+通常，`dubbo.tag` 流量标的传递需要依赖全链路追踪工具的帮助，Dubbo 只会负责 A-B 的点对点标签传递，示例中也是通过在每次点对点 RPC
调用前重复设置达成的传递效果，在实践中，全链路灰度往往从 tag 设置进全链路上下文后自动启动，我们只需要扩展 Dubbo Filter
将全链路工具上下文中的 tag 标签读取并设置进 Dubbo 上下文即可实现全链路在 Dubbo 中的自动传递，具体可参见 [Dubbo
链路追踪集成示例]()。另外，除了 RPC 调用，在微服务体系的其他基础产品中也需要依赖全链路上下文保证灰度标识的传递，以保证完整的流量隔离环境。
\ No newline at end of file
diff --git a/content/zh/overview/tasks/traffic-management/mock.md
b/content/zh/overview/tasks/traffic-management/mock.md
new file mode 100644
index 00000000000..7428a042383
--- /dev/null
+++ b/content/zh/overview/tasks/traffic-management/mock.md
@@ -0,0 +1,65 @@
+---
+type: docs
+title: "在大促之前对弱依赖调用进行服务降级"
+linkTitle: "服务降级"
+weight: 9
+description: ""
+---
+
+由于微服务系统的分布式特性，一个服务往往需要依赖非常多的外部服务来实现某一项功能，因此，一个服务的稳定性不但取决于其自身，同时还取决于所有外部依赖的稳定性。我们可以根据这些依赖的重要程度将它们划分为强依赖和弱依赖：强依赖是指那些无论如何都要保证稳定性的服务，如果它们不可用则当前服务也就不可用；弱依赖项指当它们不可用之后当前服务仍能正常工作的依赖项，弱依赖不可用只是影响功能的部分完整性。
+
+服务降级的核心目标就是针对这些弱依赖项。在弱依赖不可用或调用失败时，通过返回降级结果尽可能的维持功能完整性；另外，我们有时也会主动的屏蔽一些非关键弱依赖项的调用，比如在大促流量洪峰之前，通过预先设置一些有效的降级策略来短路部分依赖调用，来有效的提升流量高峰时期系统的整体效率和稳定性。
+
+## 开始之前
+
+* [部署 Shop 商城项目](../#部署商场系统)
+* 部署并打开 [Dubbo Admin]()
+
+## 任务详情
+
+正常情况下，商品详情页会展示来自顾客的商品评论信息。
+
+
+
+评论信息的缺失在很多时候并不会影响用户浏览和购买商品，因此，我们定义评论信息属于商品详情页面的弱依赖。接下来，我们就模拟在大促前夕常用的一个策略，通过服务降级提前关闭商品详情页对于评论服务的调用（返回一些本地预先准备好的历史评论数据），来降低集群整体负载水位并提高响应速度。
+
+
+
+### 通过降级规则短路 Comment 评论服务调用
+
+评论数据由 Comment 应用的 `org.apache.dubbo.samples.CommentService` 服务提供，接下来我们就为
`CommentService` 配置降级规则。
+
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【服务降级】
+3. 点击 "创建"，输入服务 `org.apache.dubbo.samples.CommentService` 和降级规则。
+
+![Admin 服务降级规则配置截图]()
+
+等待降级规则推送完成之后，刷新商品详情页面，发现商品评论信息已经变为我们预先设置的 "Mock Comment"，因为商品详情页的 Comment
服务调用已经在本地短路，并没有真正的发送到后端服务提供者机器上。
+
+
+
+#### 规则详解
+
+**规则 key** ：`org.apache.dubbo.samples.CommentService`
+
+**规则体**
+
+```yaml
+configVersion: v3.0
+enabled: true
+configs:
+ - side: consumer
+ parameters:
+ mock: force:return Mock Comment
+```
+
+## 清理
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的降级规则。
+
+## 其他事项
+
+服务降级功能也可以用于开发测试环境，由于微服务分布式的特点，不同的服务或应用之间都有相互依赖关系，因此，一个服务或应用很难不依赖其他服务而独立部署工作。但测试环境下并不是所有服务都是随时就绪的状态，这对于微服务强调的服务独立演进是一个很大的障碍，通过服务降级这个功能，我们可以模拟或短路应用对其他服务的依赖，从而可以让应用按照自己预期的行为
Mock 外部服务调用的返回结果。具体可参见 [Dubbo Admin 服务 Mock]() 特性的使用方式。
+
+Dubbo 的降级规则用来设置发生降级时的行为和返回值，而对于何时应该执行限流降级动作，即限流降级时机的判断并没有过多涉猎，这一点 Dubbo
通过集成更专业的限流降级产品如 Sentinel 进行了补全，可以配合 Dubbo 降级规则一起使用，具体可参见 [限流降级]() 文档。
diff --git a/content/zh/overview/tasks/traffic-management/region.md
b/content/zh/overview/tasks/traffic-management/region.md
new file mode 100644
index 00000000000..07b84d77efb
--- /dev/null
+++ b/content/zh/overview/tasks/traffic-management/region.md
@@ -0,0 +1,79 @@
+---
+type: docs
+title: "同机房/区域优先"
+linkTitle: "同区域优先"
+weight: 4
+description: "在 Dubbo-Admin 动态配置同机房/区域优先"
+---
+
+为了保证服务的整体高可用，我们经常会采用把服务部署在多个可用区(机房)的策略，通过这样的冗余/容灾部署模式，当一个区域出现故障的时候，我们仍可以保证服务整体的可用性。
+
+当应用部署在多个不同机房/区域的时候，应用之间相互调用就会出现跨区域的情况，而跨区域调用会增加响应时间，影响用户体验。同机房/区域优先是指应用调用服务时，优先调用同机房/区域的服务提供者，避免了跨区域带来的网络延时，从而减少了调用的响应时间。
+
+## 开始之前
+
+* [部署 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 始终组合展示
+
+#### 操作步骤
+1. 登录 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】 > 【同区域优先】。
+3. 点击 "创建" 按钮，填入要启用同区域优先的服务如 `org.apache.dubbo.samples.CommentService` 与
`区域标识` 如 `region` 即可。
+
+![Admin 同区域优先设置截图]()
+
+同区域优先开启后，此时再尝试刷新商品详情页面，可以看到 description 与 comment 始终保持 v1 或 v2 的同步。
+
+
+
+如果你将 `hangzhou` 区域部署的 Comment v2 版本全部下线，则 Detail v2 会自动的跨区域访问到 `beijing` 区域的
Comment v1。
+
+#### 规则详解
+
+**规则 key** ：`org.apache.dubbo.samples.CommentService`
+
+**规则体**
+```yaml
+configVersion: v3.0
+enabled: true
+force: false
+conditions:
+ - '=> region = $region'
+```
+
+这里使用的是条件路由，`region` 为我们示例中的区域标识，会自动的识别当前发起调用的一方所在的区域值，当请求到达 `hangzhou` 区域部署的
Detail 后，从 Detail 发出的请求自动筛选 URL 地址中带有 `region=hangzhou` 标识的 Comment
地址，如果发现有可用的地址子集则将请求发出，如果没有匹配条件的地址，则随机发往任意可用区地址。
+
+```yaml
+conditions:
+ - '=> region = $region'
+```
+
+`force: false` 也是关键，这允许在同区域无有效地址时，可以跨区域调用服务。
+
+## 清理
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的同区域流量规则。
+
+## 其他事项
+
+我们上面的示例并未纳入多区域之间注册中心的复杂性，如果每个区域部署有独立的注册中心，则多区域间的地址同步就是一个需要考虑的问题。对于这种场景，Dubbo
通过多注册&多订阅机制也提供了同区域优先的支持，具体可以参见[多注册&多订阅]()相关文档。
diff --git a/content/zh/overview/tasks/traffic-management/retry.md
b/content/zh/overview/tasks/traffic-management/retry.md
new file mode 100644
index 00000000000..9846178dcf4
--- /dev/null
+++ b/content/zh/overview/tasks/traffic-management/retry.md
@@ -0,0 +1,67 @@
+---
+type: docs
+title: "通过重试提高服务调用成功率"
+linkTitle: "服务重试"
+weight: 2
+description: ""
+---
+
+在服务初次调用失败后，通过重试能有效的提升总体调用成功率。但也要注意重试可能带来的响应时间增长，系统负载升高等，另外，重试一般适用于只读服务，或者具有幂等性保证的写服务。
+
+## 开始之前
+* [部署 Shop 商城项目](../#部署商场系统)
+* 部署并打开 [Dubbo Admin]()
+
+## 任务详情
+
+成功登录商城项目后，商城会默认在首页展示当前登录用户的详细信息。
+
+
+
+但有些时候，提供用户详情的 Dubbo 服务也会由于网络不稳定等各种原因变的不稳定，比如我们提供用户详情的 User
服务就很大概率会调用失败，导致用户无法看到账户的详细信息。商城为了获得带来更好的使用体验，用户信息的加载过程是异步的，因此用户信息加载失败并不会影响对整个商城页面的正常访问，但如果能始终展示完整的用户信息总能给使用者留下更好的印象。
+
+
+
+### 增加重试提高成功率
+
+考虑到访问用户详情的过程是异步的（隐藏在页面加载背后），只要最终数据能加载出来，适当的增加等待时间并不是大的问题。因此，我们可以考虑通过对每次用户访问增加重试次数的方式，提高服务详情服务的整体访问成功率。
+
+
+
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【服务重试】
+3. 点击 "创建"，输入服务 `org.apache.dubbo.samples.UserService` 和失败重试次数如 `4` 即可。
+
+![Admin 重试次数设置截图]()
+
+保存后，尝试多次刷新页面，发现用户详情数据总是能正常显示，虽然有时由于重试的缘故加载时间会明显变长。
+
+#### 规则详解
+
+**规则 key** ：`org.apache.dubbo.samples.UserService`
+
+**规则体**
+
+```yaml
+configVersion: v3.0
+enabled: true
+configs:
+ - side: consumer
+ match
+ parameters:
+ retries: 4
+```
+
+从 `UserService` 服务消费者视角（即 Frontend 应用）增加了调用失败后的重试次数。
+
+```yaml
+parameters:
+ retries: 4
+```
+
+`side: consumer` 配置会将规则发送到服务消费方实例，所有 `UserService` 服务实例会基于新的 timeout
值进行重新发布，并通过注册中心通知给所有消费方。
+
+## 清理
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的重试规则。
+
diff --git a/content/zh/overview/tasks/traffic-management/timeout.md
b/content/zh/overview/tasks/traffic-management/timeout.md
index b793b776ae5..2f3795dc8a8 100644
--- a/content/zh/overview/tasks/traffic-management/timeout.md
+++ b/content/zh/overview/tasks/traffic-management/timeout.md
@@ -1,79 +1,70 @@
---
type: docs
title: "动态调整服务超时时间"
-linkTitle: "动态调整服务超时时间"
-weight: 5
+linkTitle: "调整超时时间"
+weight: 1
description: "在 Dubbo-Admin 动态调整服务超时时间"
---
+Dubbo 提供动态调整服务超时时间的能力，在无需重启应用的情况下调整服务的超时时间，这对于临时解决一些服务上下游依赖不稳定而导致的调用失败问题非常有效。
+## 开始之前
+* [部署 Shop 商城项目](../#部署商场系统)
+* 部署并打开 [Dubbo Admin]()
-Dubbo提供动态调整超时时间的服务治理能力，可以在无需重启应用的情况下，动态调整服务超时时间。
+## 任务详情
-Dubbo可以通过XML配置，注解配置，动态配置实现动态调整超时时间，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
+商城项目通过 `org.apache.dubbo.samples.UserService` 提供用户信息管理服务，访问
`http://localhost:8080/` 打开商城并输入任意账号密码，点击 `Login` 即可以正常登录到系统。
-## 开始之前
+
-请确保成功运行Dubbo-Admin
+有些场景下，User 服务的运行速度会变慢，比如存储用户数据的数据库负载过高导致查询变慢，这时就会出现 `UserService`
访问超时的情况，导致登录失败。
-## 背景信息
+
-在日常工作中会遇到各类超时配置，业务逻辑变更后，已有调用关系随着业务发展可能需要不断调整，相应服务接口响应时间的变化可能需要上线后才能确定。Dubbo-Admin提供了动态的超时配置能力，能够帮助您快速动态调整接口超时时间，提高服务的可用性。
+在示例系统中，可通过下图 `Timeout Login` 模拟突发的 `UserService` 访问超时异常
+
+### 通过规则动态调整超时时间
-## 操作步骤
+为了解决突发的登录超时问题，我们只需要适当增加 `UserService` 服务调用的等待时间即可。
-### 动态配置
+
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 动态配置。
-3. 点击创建按钮，在创建动态配置面板中，填写规则内容，然后单击保存。
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【超时时间】
+3. 点击 "创建"，输入服务 `org.apache.dubbo.samples.UserService` 和新的超时时间如 `2000` 即可。
+![Admin 超时时间设置截图]()
+保存后，再次点击 `Timeout Login`，此时在经过短暂的等待后系统可以正常登录。
#### 规则详解
-##### 配置模板
+**规则 key** ：`org.apache.dubbo.samples.UserService`
+
+**规则体**
```yaml
----
-configVersion: v2.7
-scope: application/service
-key: app-name/group+service+version
+configVersion: v3.0
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
-...
+ - side: provider
+ parameters:
+ timeout: 2000
+```
+
+从 `UserService` 服务提供者视角，将超时时间总体调整为 2s。
+
+```yaml
+parameters:
+ timeout: 2000
```
-**对于动态调整超时时间场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改整个应用的配置还是某个服务的配置。
- - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- - 服务：`scope: service, key:group+service+version `。
-2. 修改是作用到消费者端还是提供者端。
- - 消费者：`side: consumer` ，作用到消费端时，你还可以进一步使用`providerAddress`,
`applications`选定特定的提供者示例或应用，如果同时配置消费者和提供者，消费者会覆盖提供者。
- - 提供者：`side: provider`。
-3. 配置是否只对某几个特定实例生效。
- - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- - 指定实例：`addersses[实例地址列表]`。
-4. 要修改的超时时间。
-
-## 结果验证
-选择和超时配置相关的应用，触发该调用验证。
\ No newline at end of file
+`side: provider` 配置会将规则发送到服务提供方实例，所有 `UserService` 服务实例会基于新的 timeout
值进行重新发布，并通过注册中心通知给所有消费方。
+
+## 清理
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的超时规则。
+
diff --git a/content/zh/overview/tasks/traffic-management/traffic-condition.md
b/content/zh/overview/tasks/traffic-management/traffic-condition.md
deleted file mode 100644
index e3d5e22d508..00000000000
--- a/content/zh/overview/tasks/traffic-management/traffic-condition.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-type: docs
-title: "流量隔离"
-linkTitle: "流量隔离"
-weight: 5
-description: "在 Dubbo-Admin 动态进行流量隔离"
----
-
-Dubbo提供动态流量隔离的服务治理能力，可以在无需重启应用的情况下，动态进行流量隔离。
-
-Dubbo可以通过XML配置，注解配置，动态配置实现流量隔离，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
-
-## 开始之前
-
-请确保成功运行Dubbo-Admin
-
-## 背景信息
-
-如果一个应用有多个版本在线上同时运行，部署在不同环境中，如日常环境和特殊环境，则可以使用标签路由对不同环境中的不同版本进行流量隔离，将秒杀订单流量或不同渠道订单流量路由到特殊环境，将正常的流量路由到日常环境。即使特殊环境异常，本应进入特殊环境的流量也不会进入日常环境，不影响日常环境的使用。
-
-
-## 操作步骤
-
-### 标签路由
-
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 标签路由。
-3. 点击创建按钮，在创建新标签规则面板中，填写规则内容，然后单击保存。
-
-#### 规则详解
-
-##### 配置模板
-
-```yaml
----
- 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"]
- ...
-```
-
-**对于流量隔离场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改服务所属提供者应用的配置。
- - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
-2. 当路由结果为空，是否强制返回。
- - force=false: 当路由结果为空，降级请求tag为空的提供者。
- - force=true: 当路由结果为空，直接返回异常。
-3. 路由规则的优先级
- - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
-4. 配置是否只对某几个特定实例生效。
- - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- - 指定实例：`addersses[实例地址列表]`。
-5. 要修改的标签名。
-
-## 结果验证
-选择和流量隔离配置相关的应用，触发该调用验证。
diff --git a/content/zh/overview/tasks/traffic-management/traffic-gray.md
b/content/zh/overview/tasks/traffic-management/traffic-gray.md
deleted file mode 100644
index eb93aeb737a..00000000000
--- a/content/zh/overview/tasks/traffic-management/traffic-gray.md
+++ /dev/null
@@ -1,104 +0,0 @@
----
-type: docs
-title: "流量灰度"
-linkTitle: "流量灰度"
-weight: 5
-description: "在 Dubbo-Admin 中配置标签路由规则实现灰度发布"
----
-
-Dubbo提供流量灰度的服务治理能力，可以在无需重启应用的情况下，配置标签路由规则和条件路由实现灰度发布。
-
-Dubbo可以通过XML配置，注解配置，动态配置实现流量灰度，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
-
-## 开始之前
-
-请确保成功运行Dubbo-Admin
-
-## 背景信息
-
-在产品开发中会遇到需求变化、版本迭代的场景，为了兼顾需求变化和系统稳定，发布要尽可能平滑，影响人群要由少到多，一旦有问题马上回滚。Dubbo-Admin提供了动态的流量灰度能力，能够帮助您对新服务作标，服务平滑发布，提高服务的稳定和可用性。
-
-## 操作步骤
-
-### 条件路由
-
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 条件路由。
-3. 点击创建按钮，在创建新路由规则面板中，填写规则内容，然后单击保存。
-
-
-#### 规则详解
-
-##### 配置模板
-
-```yaml
----
-scope: application/service
-force: true
-runtime: true
-enabled: true
-key: app-name/group+service+version
-conditions:
- - application=app1 => address=*:20880
- - method=sayHello => address=*:20880
-```
-
-**对于流量灰度场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-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
----
- 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"]
- ...
-```
-
-**对于流量灰度场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改服务所属提供者应用的配置。
- - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
-2. 当路由结果为空，是否强制返回。
- - force=false: 当路由结果为空，降级请求tag为空的提供者。
- - force=true: 当路由结果为空，直接返回异常。
-3. 路由规则的优先级
- - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
-4. 配置是否只对某几个特定实例生效。
- - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- - 指定实例：`addersses[实例地址列表]`。
-5. 要修改的标签名。
-
-## 结果验证
-选择和流量灰度配置相关的应用，触发该调用验证。
diff --git a/content/zh/overview/tasks/traffic-management/traffic-routing.md
b/content/zh/overview/tasks/traffic-management/traffic-routing.md
deleted file mode 100644
index 59b234acdba..00000000000
--- a/content/zh/overview/tasks/traffic-management/traffic-routing.md
+++ /dev/null
@@ -1,66 +0,0 @@
----
-type: docs
-title: "请求路由"
-linkTitle: "请求路由"
-weight: 5
-description: "在 Dubbo-Admin 根据请求条件路由"
----
-
-Dubbo提供动态创建条件路由的服务治理能力，可以在无需重启应用的情况下，根据请求发起方、请求的方法条件路由。
-
-Dubbo可以通过XML配置，注解配置，动态配置实现动态根据请求条件路由，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
-
-## 开始之前
-
-请确保成功运行Dubbo-Admin
-
-## 背景信息
-
-在业务场景如黑白名单，排除预发布机，只暴露部分机器，分环境隔离等，需要路由规则在发起RPC调用前过滤目标服务器地址，过滤后的地址作为最终发起RPC调用的备选地址。Dubbo-Admin提供条件路由的能力，能够帮助您配置路由规则，满足业务场景。
-
-## 操作步骤
-
-### 条件路由
-
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 条件路由。
-3. 点击创建按钮，在创建新路由规则面板中，填写规则内容，然后单击保存。
-
-
-#### 规则详解
-
-##### 配置模板
-
-```yaml
----
-scope: application/service
-force: true
-runtime: true
-enabled: true
-key: app-name/group+service+version
-conditions:
- - application=app1 => address=*:20880
- - method=sayHello => address=*:20880
-```
-
-**对于条件路由场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-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 =>
-
-## 结果验证
-选择和条件路由配置相关的应用，触发该调用验证。
\ 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 04a07d15eb1..87418d8d2dd 100644
--- a/content/zh/overview/tasks/traffic-management/weight.md
+++ b/content/zh/overview/tasks/traffic-management/weight.md
@@ -1,49 +1,89 @@
---
type: docs
-title: "通过权重调整流量分布"
-linkTitle: "通过权重调整流量分布"
-weight: 5
-description: "在 Dubbo-Admin 通过权重调整流量分布"
+title: "基于权重值的比例流量转发"
+linkTitle: "权重比例"
+weight: 7
+description: ""
---
+Dubbo 提供了基于权重的负载均衡算法，可以实现按比例的流量分布：权重高的提供者机器收到更多的请求流量，而权重低的机器收到相对更少的流量。
-
-Dubbo提供通过权重调整流量分布的服务治理能力，可以在无需重启应用的情况下，通过权重动态调整流量分布。
-
-Dubbo可以通过XML配置，注解配置，动态配置实现通过权重调整流量分布，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
+以基于权重的流量调度算法为基础，通过规则动态调整单个或一组机器的权重，可以在运行态改变请求流量的分布，实现动态的按比例的流量路由，这对于一些典型场景非常有用。
+* 当某一组机器负载过高，通过动态调低权重可有效减少新请求流入，改善整体成功率的同时给高负载机器提供喘息之机。
+* 刚刚发布的新版本服务，先通过赋予新版本低权重控制少量比例的流量进入，待验证运行稳定后恢复正常权重，并完全替换老版本。
+* 服务多区域部署或非对等部署时，通过高、低权重的设置，控制不同部署区域的流量比例。
## 开始之前
-请确保成功运行Dubbo-Admin
+* [部署 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。
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 权重调整。
-3. 点击创建按钮，在新建权重规则面板中，填写规则内容，然后单击保存。
+接下来，我们就开始调整订单服务访问 v1 和 v2 的流量比例，订单创建服务由
`org.apache.dubbo.samples.OrderService` 接口提供，接下来通过动态规则调整新版本 `OrderService`
实例的权重值。
+#### 操作步骤
+1. 打开 Dubbo Admin 控制台
+2. 在左侧导航栏选择【流量管控】>【权重比例】
+3. 点击 "创建"，输入要调整的 `org.apache.dubbo.samples.OrderService` 、目标实例匹配条件和权重值。
-#### 规则详解
+![Admin 权重比例设置截图]()
+再次疯狂点击 "Buy Now" 尝试多次创建订单，现在大概只有 20% 的机会看到 v2 版本的订单详情信息
-**对于通过权重动态调整流量分布场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
+在确定 v2 版本的 Order 服务稳定运行后，进一步的增加 v2 权重，直到所有老版本服务都被新版本替换掉，这样就完成了一次稳定的服务版本升级。
-1. 要修改整个应用的配置还是某个服务的配置。
- - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
- - 服务：`scope: service, key:group+service+version `。
-2. 地址列表配置是否只对某几个特定实例生效。
- - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- - 指定实例：`addersses[实例地址列表]`。
-3. 要修改的权重。
+#### 规则详解
-## 结果验证
-选择和权重配置相关的应用，触发该调用验证。
\ No newline at end of file
+**规则 key** ：`org.apache.dubbo.samples.UserService`
+
+**规则体**
+
+```yaml
+configVersion: v3.0
+scope: service
+key: org.apache.dubbo.samples.OrderService
+configs:
+ - side: provider
+ match:
+ param:
+ - key: orderVersion
+ value:
+ exact: v2
+ parameters:
+ weight: 25
+```
+
+以下匹配条件表示权重规则对所有带有 `orderVersion=v2` 标签的实例生效（Order 服务的所有 v2 版本都已经带有这个标签）。
+
+```yaml
+match:
+ param:
+ - key: orderVersion
+ value:
+ exact: v2
+```
+
+`weight: 25` 是因为 v1 版本的默认权重是 `100`，这样 v2 和 v1 版本接收到的流量就变成了 25:100 即 1:4 的比例。
+
+```yaml
+parameters:
+ weight: 25
+```
+
+## 清理
+为了不影响其他任务效果，通过 Admin 删除或者禁用刚刚配置的权重规则。
+
+## 其他事项
+`weight=0`
\ No newline at end of file
diff --git a/content/zh/overview/tasks/traffic-management/zone.md
b/content/zh/overview/tasks/traffic-management/zone.md
deleted file mode 100644
index 037b0ce58c6..00000000000
--- a/content/zh/overview/tasks/traffic-management/zone.md
+++ /dev/null
@@ -1,63 +0,0 @@
----
-type: docs
-title: "同机房/区域优先"
-linkTitle: "同机房/区域优先"
-weight: 5
-description: "在 Dubbo-Admin 动态配置同机房/区域优先"
----
-
-Dubbo提供动态配置同机房/区域优先的服务治理能力，可以在无需重启应用的情况下，动态配置同机房/区域优先。
-
-Dubbo可以通过XML配置，注解配置，动态配置同机房/区域优先，这里主要介绍动态配置的方式，其他配置方式请参考旧文档[配置](https://dubbo.apache.org/zh/docsv2.7/user/configuration/)
-
-## 开始之前
-
-请确保成功运行Dubbo-Admin
-
-## 背景信息
-
-当应用部署在多个不同机房/区域的时候，应用之间相互调用会出现跨区域的情况，跨区域调用会增加响应时间。同机房/区域优先是指应用调用服务时，优先调用同机房/区域的服务提供者。Dubbo-Admin提供了动态的同机房/区域优先能力，能够帮助您快速动态配置同机房/区域优先，避免了跨区域带来的网络延时，从而减少了调用的响应时间。
-
-
-## 操作步骤
-
-### 标签路由
-
-1. 登录Dubbo-Admin控制台
-2. 在左侧导航栏选择服务治理 > 标签路由。
-3. 点击创建按钮，在创建新标签规则面板中，填写规则内容，然后单击保存。
-
-#### 规则详解
-
-##### 配置模板
-
-```yaml
----
- 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"]
- ...
-```
-
-**对于同机房/区域优先场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
-
-1. 要修改服务所属提供者应用的配置。
- - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
-2. 当路由结果为空，是否强制返回。
- - force=false: 当路由结果为空，降级请求tag为空的提供者。
- - force=true: 当路由结果为空，直接返回异常。
-3. 路由规则的优先级
- - priority=1: 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 0。
-4. 配置是否只对某几个特定实例生效。
- - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
- - 指定实例：`addersses[实例地址列表]`。
-5. 要修改的标签名。
-
-## 结果验证
-选择和同机房/区域优先配置相关的应用，触发该调用验证。
diff --git a/static/imgs/v3/tasks/accesslog/accesslog1.png
b/static/imgs/v3/tasks/accesslog/accesslog1.png
new file mode 100644
index 00000000000..a1146affbf5
Binary files /dev/null and b/static/imgs/v3/tasks/accesslog/accesslog1.png
differ
diff --git a/static/imgs/v3/tasks/arguments/arguments1.png
b/static/imgs/v3/tasks/arguments/arguments1.png
new file mode 100644
index 00000000000..5b6f0b0ef20
Binary files /dev/null and b/static/imgs/v3/tasks/arguments/arguments1.png
differ
diff --git a/static/imgs/v3/tasks/arguments/arguments2.png
b/static/imgs/v3/tasks/arguments/arguments2.png
new file mode 100644
index 00000000000..4b91422d768
Binary files /dev/null and b/static/imgs/v3/tasks/arguments/arguments2.png
differ
diff --git a/static/imgs/v3/tasks/gray/gray1.png
b/static/imgs/v3/tasks/gray/gray1.png
new file mode 100644
index 00000000000..8696907288c
Binary files /dev/null and b/static/imgs/v3/tasks/gray/gray1.png differ
diff --git a/static/imgs/v3/tasks/gray/gray2.png
b/static/imgs/v3/tasks/gray/gray2.png
new file mode 100644
index 00000000000..9b8dd14777d
Binary files /dev/null and b/static/imgs/v3/tasks/gray/gray2.png differ
diff --git a/static/imgs/v3/tasks/host/host1.png
b/static/imgs/v3/tasks/host/host1.png
new file mode 100644
index 00000000000..47ee6523c84
Binary files /dev/null and b/static/imgs/v3/tasks/host/host1.png differ
diff --git a/static/imgs/v3/tasks/mock/mock0.png
b/static/imgs/v3/tasks/mock/mock0.png
new file mode 100644
index 00000000000..6e249008fdd
Binary files /dev/null and b/static/imgs/v3/tasks/mock/mock0.png differ
diff --git a/static/imgs/v3/tasks/mock/mock1.png
b/static/imgs/v3/tasks/mock/mock1.png
new file mode 100644
index 00000000000..c9d8bc52802
Binary files /dev/null and b/static/imgs/v3/tasks/mock/mock1.png differ
diff --git a/static/imgs/v3/tasks/mock/mock2.png
b/static/imgs/v3/tasks/mock/mock2.png
new file mode 100644
index 00000000000..c9d8bc52802
Binary files /dev/null and b/static/imgs/v3/tasks/mock/mock2.png differ
diff --git a/static/imgs/v3/tasks/region/region1.png
b/static/imgs/v3/tasks/region/region1.png
new file mode 100644
index 00000000000..53314f80c1a
Binary files /dev/null and b/static/imgs/v3/tasks/region/region1.png differ
diff --git a/static/imgs/v3/tasks/region/region2.png
b/static/imgs/v3/tasks/region/region2.png
new file mode 100644
index 00000000000..39a17f535e2
Binary files /dev/null and b/static/imgs/v3/tasks/region/region2.png differ
diff --git a/static/imgs/v3/tasks/region/region3.png
b/static/imgs/v3/tasks/region/region3.png
new file mode 100644
index 00000000000..ce9077f6177
Binary files /dev/null and b/static/imgs/v3/tasks/region/region3.png differ
diff --git a/static/imgs/v3/tasks/region/region4.png
b/static/imgs/v3/tasks/region/region4.png
new file mode 100644
index 00000000000..9758c36e972
Binary files /dev/null and b/static/imgs/v3/tasks/region/region4.png differ
diff --git a/static/imgs/v3/tasks/retry/retry1.png
b/static/imgs/v3/tasks/retry/retry1.png
new file mode 100644
index 00000000000..ce3f9d9fa5d
Binary files /dev/null and b/static/imgs/v3/tasks/retry/retry1.png differ
diff --git a/static/imgs/v3/tasks/retry/retry2.png
b/static/imgs/v3/tasks/retry/retry2.png
new file mode 100644
index 00000000000..5a11152cbc7
Binary files /dev/null and b/static/imgs/v3/tasks/retry/retry2.png differ
diff --git a/static/imgs/v3/tasks/retry/retry3.png
b/static/imgs/v3/tasks/retry/retry3.png
new file mode 100644
index 00000000000..21014ab37d1
Binary files /dev/null and b/static/imgs/v3/tasks/retry/retry3.png differ
diff --git a/static/imgs/v3/tasks/timeout/timeout1.png
b/static/imgs/v3/tasks/timeout/timeout1.png
new file mode 100644
index 00000000000..30229dbef97
Binary files /dev/null and b/static/imgs/v3/tasks/timeout/timeout1.png differ
diff --git a/static/imgs/v3/tasks/timeout/timeout2.png
b/static/imgs/v3/tasks/timeout/timeout2.png
new file mode 100644
index 00000000000..d6920f9f23b
Binary files /dev/null and b/static/imgs/v3/tasks/timeout/timeout2.png differ
diff --git a/static/imgs/v3/tasks/timeout/timeout3.png
b/static/imgs/v3/tasks/timeout/timeout3.png
new file mode 100644
index 00000000000..ca5a2a45b50
Binary files /dev/null and b/static/imgs/v3/tasks/timeout/timeout3.png differ
diff --git a/static/imgs/v3/tasks/timeout/timeout4.png
b/static/imgs/v3/tasks/timeout/timeout4.png
new file mode 100644
index 00000000000..2b55112eb0f
Binary files /dev/null and b/static/imgs/v3/tasks/timeout/timeout4.png differ
diff --git a/static/imgs/v3/tasks/weight/weight1.png
b/static/imgs/v3/tasks/weight/weight1.png
new file mode 100644
index 00000000000..33e7015483e
Binary files /dev/null and b/static/imgs/v3/tasks/weight/weight1.png differ
diff --git a/static/imgs/v3/tasks/weight/weight2.png
b/static/imgs/v3/tasks/weight/weight2.png
new file mode 100644
index 00000000000..6c0518812a0
Binary files /dev/null and b/static/imgs/v3/tasks/weight/weight2.png differ
diff --git a/static/imgs/v3/traffic/shop-arc-deploy.png
b/static/imgs/v3/traffic/shop-arc-deploy.png
new file mode 100644
index 00000000000..c977eb7d2fc
Binary files /dev/null and b/static/imgs/v3/traffic/shop-arc-deploy.png differ
diff --git a/static/imgs/v3/traffic/shop-arc-deploy2.png
b/static/imgs/v3/traffic/shop-arc-deploy2.png
new file mode 100644
index 00000000000..515efaa98d4
Binary files /dev/null and b/static/imgs/v3/traffic/shop-arc-deploy2.png differ
diff --git a/static/imgs/v3/traffic/shop-arc.png
b/static/imgs/v3/traffic/shop-arc.png
new file mode 100644
index 00000000000..bd9ea23ca52
Binary files /dev/null and b/static/imgs/v3/traffic/shop-arc.png differ
