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 dc30d48901d update v3 docs (#1835)
dc30d48901d is described below
commit dc30d48901ddb9cd51bf8402c6790541e79c76a7
Author: Ken Liu <[email protected]>
AuthorDate: Wed Jan 11 09:32:33 2023 +0800
update v3 docs (#1835)
---
assets/scss/main.scss | 16 ++
content/zh/_index.html | 2 +-
content/zh/blog/java/codeanalysis/3.0.8/_index.md | 2 +-
.../java/demos/multiple-protocols-registries.md | 298 +++++++++++++++++++++
content/zh/overview/core-features/ecosystem.md | 64 +----
content/zh/overview/core-features/extensibility.md | 78 ++++++
content/zh/overview/core-features/load-balance.md | 82 +++++-
content/zh/overview/core-features/more.md | 71 +++++
content/zh/overview/core-features/observability.md | 36 ++-
content/zh/overview/core-features/protocols.md | 72 ++++-
content/zh/overview/core-features/security.md | 103 ++++++-
.../overview/core-features/service-definition.md | 4 +-
.../zh/overview/core-features/service-discovery.md | 57 ++++
content/zh/overview/core-features/service-mesh.md | 84 +++++-
.../zh/overview/core-features/traffic/_index.md | 5 +
content/zh/overview/quickstart/_index.md | 55 +++-
content/zh/overview/quickstart/go/_index.md | 6 +
content/zh/overview/quickstart/java/_index.md | 6 +
content/zh/overview/quickstart/nodejs/_index.md | 6 +
content/zh/overview/quickstart/rust/_index.md | 6 +
content/zh/overview/tasks/develop/_index.md | 79 ++++++
content/zh/overview/tasks/develop/async.md | 7 +
content/zh/overview/tasks/develop/context.md | 7 +
content/zh/overview/tasks/develop/generic.md | 7 +
.../zh/overview/tasks/develop/service_reference.md | 7 +
content/zh/overview/tasks/develop/template.md | 7 +
content/zh/overview/tasks/develop/version_group.md | 7 +
content/zh/overview/tasks/ecosystem/_index.md | 2 +-
.../ecosystem}/configuration.md | 0
content/zh/overview/tasks/extensibility/_index.md | 4 +-
content/zh/overview/tasks/kubernetes/_index.md | 22 +-
content/zh/overview/tasks/observability/_index.md | 6 +-
content/zh/overview/tasks/protocols/_index.md | 3 +-
.../zh/overview/tasks/traffic-management/_index.md | 2 +-
content/zh/overview/what/_index.md | 8 +-
content/zh/overview/what/advantages/_index.md | 4 +-
.../zh/overview/what/advantages/extensibility.md | 23 +-
.../overview/what/advantages/traffic-management.md | 36 ++-
content/zh/overview/what/overview.md | 84 +++---
content/zh/overview/what/overview.md.backup | 112 --------
content/zh/overview/what/xyz-difference.md | 8 +-
static/imgs/blog/2023/01/protocols/img.png | Bin 0 -> 291215 bytes
static/imgs/blog/2023/01/protocols/img_1.png | Bin 0 -> 282594 bytes
static/imgs/blog/2023/01/protocols/img_10.png | Bin 0 -> 347545 bytes
static/imgs/blog/2023/01/protocols/img_2.png | Bin 0 -> 491291 bytes
static/imgs/blog/2023/01/protocols/img_3.png | Bin 0 -> 364383 bytes
static/imgs/blog/2023/01/protocols/img_4.png | Bin 0 -> 780405 bytes
static/imgs/blog/2023/01/protocols/img_5.png | Bin 0 -> 359842 bytes
static/imgs/blog/2023/01/protocols/img_6.png | Bin 0 -> 375634 bytes
static/imgs/blog/2023/01/protocols/img_7.png | Bin 0 -> 212331 bytes
static/imgs/blog/2023/01/protocols/img_8.png | Bin 0 -> 262350 bytes
static/imgs/blog/2023/01/protocols/img_9.png | Bin 0 -> 255272 bytes
static/imgs/v3/concepts/architecture-2.png | Bin 0 -> 108398 bytes
static/imgs/v3/difference/dubbo-grpc.png | Bin 0 -> 32938 bytes
static/imgs/v3/difference/dubbo-springcloud.png | Bin 0 -> 317312 bytes
static/imgs/v3/difference/img.png | Bin 0 -> 166723 bytes
static/imgs/v3/feature/ecosystem/ecosystem.png | Bin 0 -> 260564 bytes
static/imgs/v3/feature/extensibility/filter.png | Bin 0 -> 173543 bytes
static/imgs/v3/feature/protocols/protocols1.png | Bin 0 -> 66680 bytes
static/imgs/v3/feature/security/arch.png | Bin 0 -> 10876 bytes
static/imgs/v3/feature/security/auth-1.png | Bin 0 -> 9768 bytes
static/imgs/v3/feature/security/authz-1.png | Bin 0 -> 10275 bytes
static/imgs/v3/feature/security/authz-2.png | Bin 0 -> 32041 bytes
static/imgs/v3/feature/service-discovery/arc.png | Bin 0 -> 190245 bytes
static/imgs/v3/feature/service-discovery/arc2.png | Bin 0 -> 377769 bytes
.../imgs/v3/feature/service-discovery/metadata.png | Bin 0 -> 552211 bytes
.../v3/feature/service-discovery/registry-data.png | Bin 0 -> 62503 bytes
.../v3/feature/service-discovery/subscription1.png | Bin 0 -> 142691 bytes
.../v3/feature/service-discovery/subscription2.png | Bin 0 -> 148136 bytes
static/imgs/v3/what/framework1.png | Bin 0 -> 226132 bytes
static/imgs/v3/what/framework2.png | Bin 0 -> 75625 bytes
static/imgs/v3/what/governance.png | Bin 0 -> 117257 bytes
static/imgs/v3/what/protocol.png | Bin 0 -> 123653 bytes
73 files changed, 1235 insertions(+), 253 deletions(-)
diff --git a/assets/scss/main.scss b/assets/scss/main.scss
index 935b180de5f..06971344e3f 100644
--- a/assets/scss/main.scss
+++ b/assets/scss/main.scss
@@ -73,6 +73,22 @@ footer {
}
}
+.msemap-section{
+ .msemap-container{
+ h3{
+ font-family: Avenir-Medium;
+ font-weight: 700;
+ font-size: 36px;
+ color: #333;
+ text-align: center;
+ margin-bottom: 20px;
+ }
+ #mse-arc-container{
+ height: 700px !important;
+ }
+ }
+}
+
@import "styles_project";
@import "skin";
@import "base";
diff --git a/content/zh/_index.html b/content/zh/_index.html
index fd86b65e4bf..ef7cc22e903 100644
--- a/content/zh/_index.html
+++ b/content/zh/_index.html
@@ -6,7 +6,7 @@ linkTitle = "Apache Dubbo Website"
{{< blocks/cover title="Apache Dubbo" image_anchor="top" height="max"
color="secondary" >}}
<div class="mx-auto">
- <p class="display-4 lead font-weight-light">一款易用的、提供高性能 RPC
通信及服务治理能力的微服务开发框架</p>
+ <p class="display-4 lead font-weight-light">一款易用的、具备高性能 RPC
通信及服务治理能力的微服务开发框架</p>
</div>
<div class="mx-auto mt-3">
diff --git a/content/zh/blog/java/codeanalysis/3.0.8/_index.md
b/content/zh/blog/java/codeanalysis/3.0.8/_index.md
index 70eb9ed13bf..5748b6d8f70 100644
--- a/content/zh/blog/java/codeanalysis/3.0.8/_index.md
+++ b/content/zh/blog/java/codeanalysis/3.0.8/_index.md
@@ -1,7 +1,7 @@
---
title: "Dubbo 3.0.8 源码解析"
-linkTitle: "Dubbo 3.0.8"
+linkTitle: "Dubbo3 [v3.0.8] 源码解析"
weight: 20
---
diff --git a/content/zh/blog/java/demos/multiple-protocols-registries.md
b/content/zh/blog/java/demos/multiple-protocols-registries.md
new file mode 100644
index 00000000000..26d11a9c573
--- /dev/null
+++ b/content/zh/blog/java/demos/multiple-protocols-registries.md
@@ -0,0 +1,298 @@
+---
+title: "Dubbo 连接异构微服务体系 - 多协议&多注册中心"
+linkTitle: "Dubbo 连接异构微服务体系 - 多协议&多注册中心"
+date: 2023-01-05
+description: >
+ 本文介绍了 Dubbo 的多协议、多注册中心支持方案，以及如何用它们实现多协议共存、多协议互通、多协议迁移等能力。
+---
+
+从编程开发的角度来说，Dubbo 首先是一款 RPC 服务框架，它最大的优势在于提供了面向接口代理的服务编程模型，对开发者屏蔽了底层的远程通信细节。同时
Dubbo 也是一款服务治理框架，它为分布式部署的微服务提供了服务发现、流量调度等服务治理解决方案。
+
+在这篇文章中，我们将以以上基础能力为背景，尝试突破 Dubbo 体系自身，探索如何利用 Dubbo
对多协议、多服务发现模型的支持，来实现异构微服务体系间的互联互通。在实际业务场景中，这可以用来解决异构技术体系共存场景下的通信问题，帮助公司实现在异构技术体系间作平滑迁移，解决大规模跨区域、多集群部署场景的地址发现及流量调度等问题。
+
+## 面向接口代理的透明服务开发框架
+
+我们还是从 **Dubbo 是一个微服务开发框架** 这个大家熟知的概念开始。就像 Spring 是开发 Java 应用的基础框架一样，我们经常会选用
Dubbo 作为开发微服务业的基础框架。 Dubbo 框架的最大优势我认为就在其面向接口的编程模型，使得开发远程服务调用就像开发本地服务一样（以 Java
语言为例）：
+
+1. 服务定义
+
+```java
+public interface GreetingsService {
+ String sayHi(String name);
+}
+```
+
+2. 消费方调用服务
+
+```java
+// 和调用本地服务一样，完全透明。
+@Reference
+private GreetingService greetingService;
+
+public void doSayHello(String name) {
+ greetingService.sayHi("Hello world!");
+}
+```
+
+下图是 Dubbo 的基本工作原理图，服务提供者与服务消费者之间通过注册中心协调地址，通过约定的协议实现数据交换。
+
+
+
+
+## 同构/异构微服务体系面临的问题
+
+关于 Dubbo 协议本身及其服务治理相关功能细节并不是本文的重点，我们今天将从一个更高的层次，来看看公司内部构建微服务体系所面的挑战，以及 Dubbo
能为架构选型和迁移等提供哪些解决思路。
+
+一个公司内部的微服务可能都是基于某一个相同的服务框架开发的，比如说
Dubbo，对于这样的架构，我们称之为是**同构的微服务体系**；而有些公司的微服务可能是使用多个不同的服务框架所建设，我们称之为**异构的微服务体系**，多个不同技术栈微服务体系的共存在大型组织内还是非常普遍的，造成这种局面可能有很多原因。比如，可能是遗留系统带来的，也可能是公司正在做技术栈迁移，或者就是不同业务部门为了满足各自特殊需求而做的独立选型（这也意味着异构微服务体系的长期共存）。
+
+**1. 异构微服务体系共存**
+
+我们很容易想到的一个挑战是：**不同的体系间通常是使用不同的 RPC
通信协议、部署独立的注册中心集群，面对这种多协议、多注册中心集群的场景，要如何实现相互之间透明的地址发现和透明的 RPC
调用？**如果我们什么都不做，那么每个微服务体系就只能感知到自己体系内的服务状态，流量也在各自的体系内封闭。而要做到从体系 A 平滑的迁移到体系
B，或者想长期的保持公司内部多个体系的共存，则解决不同体系间的互联互通，实现流量的透明调度将是非常重要的环节。
+
+
+
+
+**2. Dubbo 体系内部**
+
+**多协议、多注册中心集群的问题在同构的微服务体系中也可能存在，尤其是当一个组织内部的微服务规模增长到一定量级的时候。**
+
+*
我们可能要在不同的服务之间采用不同的通信协议，因为不同的服务面临不同的业务场景，而这也进一步导致了数据传输特点的不同，我们需要分别采用更适合各类业务特点的协议。比如典型的场景：我们可能对于普通的业务服务采用
Dubbo 协议，对于和 FrontEnd 交互的服务需要 HTTP 协议，而对于需要流式数据传输的业务则采用 gRPC 协议等等。
+
+* Dubbo
体系内部另一个常出现的问题是，在大规模分布式部署的场景下，微服务系统会做跨区域、跨注册中心的部署，这个时候就会出现多集群间地址同步和流量调度的问题。
+
+总结起来，**不论是同构体系还是异构体系，都面临对多协议通信、多注册中心集群地址发现的问题。**Dubbo
目前是支持多协议、多注册中心的，可以说就是为解决我们上面分析的 Dubbo
同构体系内的场景而设计的，因此下面我们从同构体系的多协议、多注册中心场景讲起，先了解 Dubbo
多协议、多注册中心的基本支持情况以及它们是如何工作的。而在后面的一章再进一步探索怎么扩展这个能力来支持异构微服务体系的互联互通。
+
+## Dubbo 体系内的多协议、多注册中心机制
+
+我们将通过两个场景示例，来分别具体的讲一下 Dubbo 的多协议、多注册中心机制的使用方式和工作原理。
+
+### 多协议
+
+
+
+以上是使用 Dubbo 开发的一套微服务，服务间通信使用到了不同的协议，根据我们的调研发现，公司内部启用多协议其实是非常普遍需求，具体场景在此我们暂不做解释。
+
+应用 B 作为服务提供者，发布了 5 个服务，其中：
+
+* `DemoService1` `DemoService2` 通过 `dubbo` 协议发布
+* `DemoService3` `DemoService4` 通过 `gRPC` 协议发布
+* `DemoService0` 通过 `dubbo` 、`gRPC` 双协议发布
+
+应用 A 作为消费者，使用 dubbo 协议消费 `DemoService1` `DemoService2`，使用 gRPC 协议消费
`DemoService0`。
+
+应用 B 作为消费者，使用 gRPC 协议消费 `DemoService2` `DemoService4`，使用 dubbo 协议消费
`DemoService0`。
+
+以下是具体的代码配置：
+
+1. 提供端应用 B
+
+```xml
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService1"
protocol="dubbo"/>
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService2"
protocol="dubbo"/>
+
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService3"
protocol="grpc"/>
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService4"
protocol="grpc"/>
+
+<dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService0"
protocol="dubbo, grpc"/>
+```
+
+2. 消费端应用 A
+
+```xml
+<dubbo:reference protocol="dubbo"
interface="org.apache.dubbo.samples.basic.api.DemoService1"/>
+<dubbo:reference protocol="dubbo"
interface="org.apache.dubbo.samples.basic.api.DemoService2"/>
+
+<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
+```
+
+3. 消费端应用 C
+
+```xml
+<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService3"/>
<dubbo:reference protocol="grpc"
interface="org.apache.dubbo.samples.basic.api.DemoService4"/>
+
+<dubbo:reference protocol="dubbo"
interface="org.apache.dubbo.samples.basic.api.DemoService0"/>
+
+```
+
+#### Dubbo 多协议支持现状
+
+Dubbo 目前所支持的协议包括 Dubbo、REST、Thrift、gRPC、JsonRPC、Hessian 等，基本涵盖了业界大多数主流的 RPC
通信协议。需要注意的是，这些协议的支持都是以直接集成官方 Release 实现的形式来做的，我认为这是一个很好的选择，既保证了协议解析自身的稳定性，又能使
Dubbo 社区更专注的将更多的精力放在 Dubbo 外围服务治理能力的改善上。试想如果 Dubbo
社区自己为每个协议提供实现，那是要花费多少精力和时间才能使每种协议达到稳定的生产可用。
+
+除了以上官方提供支持的协议之外，得益于 Dubbo 灵活的扩展机制，想要为 Dubbo 扩展协议非常容易，开发者可以随时为 Dubbo
增加更多的协议支持，包括自有协议扩展。
+
+关于对 gRPC (HTTP/2) 协议的支持，请参阅上期文档
+
+https://yuque.antfin-inc.com/ken.lj/xga6e2/dxgrn4
+
+
+
+#### 多协议能解决的问题
+
+* 将 RPC 框架无缝地接入 Dubbo 的服务治理体系。
+
+ 通过协议扩展将 RPC 协议纳入 Dubbo 服务开发体系，从而复用 Dubbo 的编程模型和服务发现、流量管控等能力。比如
gRPC，其服务治理体系相对比较弱、编程 API 不够友好，很难直接用于微服务开发。
+
+* 满足不同场景的调用需求。
+
+ 各个服务可能是为了满足不同业务需求而开发，同时外围消费端应用的技术栈也可能多种多样，通过启用不同的通信协议，可以最优化不同场景的通信需求。
+
+* 实现协议间的迁移。
+
+ 通过支持多种协议，借助注册中心的协调，可以快速满足公司内协议迁移的需求。如从自有协议升级到 Dubbo 协议，Dubbo 协议自身升级，从 Dubbo
协议迁移到 gRPC，从 REST 迁移到 Dubbo 协议等。
+
+
+### 多注册中心
+
+当服务集群规模小的时候，一个中心化的集群部署方案能很好的解决我们的业务问题。但是随着应用规模的增长、用户流量的增加，我们就不得不考虑要为业务系统引入跨区域、多集群的部署方案，而此时同业务系统密切相关的注册中心集群也面临部署方案的选型：
+
+1.
继续维持全局共享的注册中心集群。这种架构方案的优点是简单；缺点是注册中心集群由于要保存全量的地址数据，存储和推送压力会变得很大，另外对于一些注册中心产品（如
Zookeeper 等）在跨集群网络部署的场景下稳定性和性能可能都会面临挑战。
+
+2.
每个业务集群部署独立的注册中心集群。多注册中心集群的优点是能解决跨集群网络可用性的问题，同时也能够减轻注册中心的存储和推送压力；缺点则是要求服务框架（如
Dubbo 等）能有同时发布/监听多个注册中心集群的能力。
+
+下面我们具体看一下，Dubbo 为多注册中心集群场景提供的解决方案。
+
+
+
+上图有两个业务集群，分别部署在北京和上海，每个业务集群有自己独立的注册中心集群，要解决两个业务集群间服务的透明 RPC 通信问题。
+
+1. 服务提供端，双注册中心发布
+
+```xml
+<dubbo:registry id="beijingRegistry"
address="zookeeper://${zookeeper.address1}" default="false"/>
<dubbo:registry
id="shanghaiRegistry" address="zookeeper://${zookeeper.address2}" />
+
+<dubbo:service
interface="org.apache.dubbo.samples.multi.registry.api.HelloService"
ref="helloService" registry="shanghaiRegistry,beijingRegistry"/>
+<dubbo:service
interface="org.apache.dubbo.samples.multi.registry.api.DemoService"
ref="demoService" registry="shanghaiRegistry,beijingRegistry"/>
+
+```
+
+2. 服务消费端，根据消费需求做单/双注册中心订阅
+
+```xml
+<dubbo:registry id="beijingRegistry"
address="zookeeper://${zookeeper.address1}" default="false" preferred="true"
weight="100"/>
<dubbo:registry id="shanghaiRegistry"
address="zookeeper://${zookeeper.address2}" default="true" weight="20"/>
+
+<dubbo:reference
interface="org.apache.dubbo.samples.multi.registry.api.DemoService"/>
+
+<dubbo:reference
interface="org.apache.dubbo.samples.multi.registry.api.DemoService"
registry="beijingRegistry, shanghaiRegistry"/>
+
+<dubbo:reference
interface="org.apache.dubbo.samples.multi.registry.api.HelloService"
registry="beijingRegistry"/>
+
+<dubbo:reference
interface="org.apache.dubbo.samples.multi.registry.api.HelloService"
registry="shanghaiRegistry,shanghaiRegistry"/>
+
+```
+
+#### Dubbo 对异构注册中心集群的支持
+
+虽然我们会做多注册中心集群部署，但通常情况下，我们部署的都是相同的注册中心产品，如都是 Zookeeper、Nacos；而对于注册中心迁移的场景，则要求
Dubbo 能提供对更多的注册中心产品的支持，或者最重要的要有很好的扩展能力。Dubbo 官方目前支持的注册中心实现有：
+
+
+
+这里需要特别提到的一点是，当前 Dubbo 的服务注册/发现模型是以接口为粒度的，而从 2.7.5 版本开始，Dubbo
新引入了应用粒度的服务注册/发现模型。这一方面有助于优化 Dubbo 当前服务发现机制、提升服务容量，另一方面对于联通以 SpringCloud
为代表的微服务体系也非常重要（关于这点在下一章中有进一步提及）。更多关于《应用粒度服务发现：服务自省》的介绍，我们将在接下来的文章或文档中予以补充，请持续关注。
+
+#### 多订阅带来的流量调度问题
+
+在引入多注册中心集群后，Dubbo 在流量选址时的多了一层注册中心集群间的负载均衡：
+
+
+
+在 Cluster Invoker 这一级，我们支持的选址策略有（2.7.5+ 版本，具体使用请参见文档）：
+
+* 指定优先级
+
+ ```xml
+ <!-- 来自 preferred=“true” 注册中心的地址将被优先选择，只有该中心无可用地址时才 Fallback 到其他注册中心 -->
+ <dubbo:registry address="zookeeper://${zookeeper.address1}" preferred="true"
/>
+ ```
+
+* 同 zone 优先
+
+ ```xml
+ <!-- 选址时会和流量中的 zone key 做匹配，流量会优先派发到相同 zone 的地址 -->
+ <dubbo:registry address="zookeeper://${zookeeper.address1}" zone="beijing" />
+ ```
+
+* 权重轮询
+
+ ```xml
+ <!-- 来自北京和上海集群的地址，将以 10:1 的比例来分配流量 -->
+ <dubbo:registry id="beijing" address="zookeeper://${zookeeper.address1}"
weight=”100“ />
+ <dubbo:registry id="shanghai" address="zookeeper://${zookeeper.address2}"
weight=”10“ />
+ ```
+
+* 默认，stick to 任意可用
+
+#### 多注册中心适用的场景
+
+* 同区域流量优先调度
+
+
出于容灾或者服务伸缩性需求，服务/应用往往需要部署在多个独立的机房/区域，在每个区域有独立注册中心集群的场景下，实现同区域的流量优先调度就能很好的解决延迟和可用性问题。
+
+* 注册中心迁移
+
+ 公司的服务一直以来可能是存储在某一个注册中心，如
Zookeeper，但到了某个时间节点，因为各种各样的原因，当我们要迁移到另外的注册中心时，多注册中心模型能够保证平滑的迁移。
+
+* 异构系统互通
+
+ 不同微服务体系开发的服务，都封闭在各自的服务发现体系中，而通过统一的多注册中心模型，可以实现不同体系的服务互相发现。
+
+## 借助 Dubbo 联通异构的微服务体系
+
+上文我们提到了在组织内存在异构微服务体系的各种合理可能性，现在我们来具体看一下异构微服务体系的实际场景，以及使用 Dubbo
实现互联互通的解决方法。首先我们先通过一张图来看一下，联通异构的微服务体系具体是一个什么样的场景。
+
+
+
+如上图所示，我们有部分微服务可以是基于 SpringCloud、gRPC、K8S
或者是自建体系构建的，他们各自之间默认是相互隔离无法联通的。当我们再构建一套基于 Dubbo 的微服务体系时，则利用 Dubbo
的多协议、多服务发现模型，我们就可以做到和各个微服务体系间的两两之间的互联互通。进一步的，如图中橙色箭头所示，依赖 Dubbo
体系作为桥接层，我们还可以实现两个异构微服务体系间的打通。
+
+对于以下几个示例场景，由于在地址发现层面目前没有统一的标准，我们暂且假设地址发现层面不同的体系建是没有障碍的，我们将重点关注迁移的基本流程以及通信协议环节。（关于地址发现部分，我们将在后续《服务自省：基于应用粒度的服务发现》之后再深入探讨）
+
+### Dubbo 体系内的协议迁移（共存）
+
+绝大多数开发者对 Dubbo 有这么一个固有认知：使用 Dubbo 开发微服务系统，则就要用 Dubbo
协议来作为服务间的通信协议才是最优方案。实际上，我们完全没有必要只束缚在 Dubbo RPC 协议上。Dubbo 作为微服务开发框架和 Dubbo 作为
RPC 协议这是两个概念，其实是完全可以分开来看待的，比如我们用 Dubbo 框架开发的业务系统，选用 rest、gRPC 通信是完全没有问题的（参加
Dubbo 支持的协议列表），具体用什么协议根据业务特点和技术规划才是最适合的。
+
+
+
+当前在云原生、Mesh 的大背景下， HTTP1/2、gRPC
协议开始受到越来越多的关注，一方面原因自然是因为它们在标准化方面做的更好，得到的更多的网络设备和基础设施的支持，具备更好的通用性和穿透性。对于很多有云原生迁移意愿的企业来说，往此类协议迁移无疑将对之后的架构升级有更多的帮助。
+
+下图演示了在 Dubbo 体系内，从 Dubbo 协议向 gRPC 协议迁移的一个中间状态。
+
+
+
+* 最左边的代表尚未迁移的老应用，这类应用在迁移过程中仍然要消费和提供 Dubbo 协议的服务。
+* 中间的代表处于迁移中的应用，他们中间可能有些是服务提供者，既要为左边的老系统提供提供 Dubbo 协议服务；又要为右边的新系统提供 gRPC
服务；因此他们都是双协议暴露服务。
+* 最右边则代表是新开发的或者已经迁移完成的应用，这个体系内已能完全用 gRPC 协议通信。
+* 最终度过中间态后，我们期望所有的应用都达到最左边应用的状态，实现完全的 gRPC 协议通信。
+
+### Spring Cloud 体系迁移到 Dubbo 体系（共存）
+
+如前文所述，由于 SpringCloud 和 Dubbo 间服务发现模型的问题，要两个体系间的地址互通需要 Dubbo
侧作相应的适配，关于这部分内容将在接下来的 2.7.5 版本《服务自省》部分发布，在此我们暂且认为已经打通。
+
+
+
+Dubbo 体系内的部分应用作为透明的联通两个体系的关键节点，部分服务提供者应用要双协议发布、部分消费者应用要做到选定协议消费。由于老的 Spring
Cloud 体系不允许做任何改动，因此联通两套体系的关键是 REST 协议，对 Dubbo 侧的应用来说：
+
+* 部分应用可能要以 REST 协议消费 SpringCloud 的服务；
+* 部分应用可能要暴露 REST 协议共 SpringCloud 消费；
+* Dubbo 自有体系内则通过自己选定的协议通信，这里就比较灵活了，可以是 Dubbo、REST、gRPC 等其中的任一种。而如果选定 REST
协议则对于与 SpringCloud 体系的联通就变得更加自然了，因为两端的协议都是统一的。
+
+对于消费 Spring Cloud 服务的应用，要配置服务 ：
+
+```xml
+<dubbo:reference interface ="xxx.SpringService" protocol="rest"/>
+```
+
+对于提供服务给 Spring Cloud 侧消费的应用，则指定服务暴露为 rest 协议，或者双协议暴露（因如果这个服务还要被新体系内的应用调用到）：
+
+```xml
+<dubbo:service interface="xxx.NewService" protocol="rest,dubbo"/>
+```
+
+作为 Dubbo 的维护者，虽然我们这里有明显的偏向性，讲的是从如何从 SpringCloud 体系迁移到 Dubbo
体系。但是反过来考虑，如果你已经或者即将选型 Dubbo 来开发微服务，则未来从 Dubbo 迁移到 SpringCloud 也是同样的思路，Dubbo
的多协议、多注册模型为双向迁移都提供了同样的灵活性。
+
+### 自建体系迁移到 Dubbo 体系（共存）
+
+这个场景和上一节中讲到的的 SpringCloud 迁移有些类似，最大的区别在于 rest 协议是 Dubbo
官方默认提供支持的，而对于已有的微服务体系内的私有通信协议，则需要先要自己去扩展 Dubbo Protocol 来提供协议层面的支持，关于 Protocol
如何扩展请参见以下官方文档：
+
+http://dubbo.apache.org/zh-cn/docs/dev/impls/protocol.html
+
+## 总结与展望
+
+要实现异构微服务体系间的共存或迁移，关键点在打通异构体系间的`协议`与`服务发现`，得益于 Dubbo 自身对多协议、多注册模型的支持，我们可以很容易的使
Dubbo 成为桥接异构微服务体系的中间层。熟悉 Dubbo
多协议实现细节的同学，可能会担心在服务数量较多的场景下，多协议注册会导致地址数量翻倍从而影响地址推送性能；另外在文中《借助 Dubbo
联通异构的微服务体系》一节，关于如何实现异构体系间的透明服务发现部分我们没有做详细的说明。关于涉及服务发现的这部分，我们将在接下来的文章中做具体阐述，看看
Dubbo 2.7.5 版本引入新的服务发现机制是如何解决这个问题的，请持续关注后续文章及 Dubbo 官方文档。
\ No newline at end of file
diff --git a/content/zh/overview/core-features/ecosystem.md
b/content/zh/overview/core-features/ecosystem.md
index e7e9730943f..02e35da6bb2 100644
--- a/content/zh/overview/core-features/ecosystem.md
+++ b/content/zh/overview/core-features/ecosystem.md
@@ -2,7 +2,7 @@
type: docs
title: "微服务生态"
linkTitle: "微服务生态"
-weight: 70
+weight: 90
description: ""
feature:
title: 丰富生态
@@ -10,57 +10,21 @@ feature:
在以下微服务领域提供了众多官方生态适配，包括注册中心、配置中心、网关、限流降级、负载均衡、一致性事务、异步消息、Tracing、可观测等。
---
+<!-- <link rel="stylesheet"
href="https://g.alicdn.com/mamba/assets/0.0.3/mse-arc-ui.min.css"; /> -->
+<!-- <script
src="https://g.alicdn.com/mamba/assets/0.0.3/mse-arc-ui.min.js";></script> -->
-### Dashboard
-* [Dubbo-admin](https://github.com/apache/dubbo-admin)
+<!-- {{< blocks/section color="white" height="auto" >}} -->
+<!-- <div class="msemap-section"> -->
+<!-- <div class="msemap-container"> -->
+<!-- <div id="mse-arc-container"></div> -->
+<!-- </div> -->
+<!-- </div> -->
+<!-- {{< /blocks/section >}} -->
-### 支持的组件与部署架构
+Dubbo 社区和众多优秀的开源项目一起围绕 Dubbo 建立了丰富的微服务生态支持，这让开发者从选型 Dubbo
作为开发框架的第一天，就无需担心后续的服务治理诉求，Dubbo 对每一个常见问题均提供了生产级的解决方案。
-Dubbo 实现普遍支持以下产品或部署架构，具体多语言 SDK 实现可能有差异。
+基于 Dubbo 灵活的可扩展性，Dubbo 微服务集群不会绑定任何特定组件实现、不绑定单一通信协议。
-* 注册中心
- * Zookeeper
- * [Nacos](https://nacos.io/zh-cn/docs/use-nacos-with-dubbo.html)
- * Kubernetes
-* 元数据中心
- * Zookeeper
- * [Nacos](https://nacos.io/zh-cn/docs/use-nacos-with-dubbo.html)
- * Redis
-* 配置中心
- * Zookeeper
- * [Nacos](https://nacos.io/zh-cn/docs/use-nacos-with-dubbo.html)
- * Redis
- * Apollo
-* Mesh
- * 数据面 Envoy
- * 控制面 Istio
+
-### 协议与互通性
-* 基于 Triple 协议可实现与 gRPC 体系互通
-* 基于 REST 协议以及应用级服务发现可实现 Spring Cloud 体系在协议和地址发现层面的互通
-
-### SPI 集成
-这里有众多的 Dubbo 扩展实现，包括协议、序列化、注册中心等
-* [dubbo-spi-extensions]
-
-### 网关组件
-* [Apache
Shenyu](/zh/blog/2022/05/04/%E5%A6%82%E4%BD%95%E9%80%9A%E8%BF%87-apache-shenyu-%E7%BD%91%E5%85%B3%E4%BB%A3%E7%90%86-dubbo-%E6%9C%8D%E5%8A%A1/)
-* [Apache
APISIX](/zh/blog/2022/01/18/%E4%BB%8E%E5%8E%9F%E7%90%86%E5%88%B0%E6%93%8D%E4%BD%9C%E8%AE%A9%E4%BD%A0%E5%9C%A8-apache-apisix-%E4%B8%AD%E4%BB%A3%E7%90%86-dubbo-%E6%9C%8D%E5%8A%A1%E6%9B%B4%E4%BE%BF%E6%8D%B7/)
-* [Apache Dubbo-pixiu]
-* [Tengine]
-
-### 链路追踪
-* [Zipkin]
-* [Apache Skywalking]
-
-### 其他微服务组件
-* 限流 [Sentinel]
-* 事务 [Seata]
-
-### 多语言实现
-* Golang
-* Java
-* Rust
-* Node
-* Python
-* PHP
+可通过 [微服务生态]() 任务，了解更多 Dubbo 生态能力和使用方式。
diff --git a/content/zh/overview/core-features/extensibility.md
b/content/zh/overview/core-features/extensibility.md
index e7bf27b0532..d40bf1f1173 100644
--- a/content/zh/overview/core-features/extensibility.md
+++ b/content/zh/overview/core-features/extensibility.md
@@ -10,3 +10,81 @@ feature:
以插件形式定义所有关键微服务组件，用户可基于 Filter、Router、Service Discovery、Configuration
等扩展点对接、适配自建或开源微服务生态。
---
+Dubbo 的各语言 sdk 实现都是采用的 "微内核+插件"
的设计模式，几乎所有流程中的核心节点都被定义为扩展点，官方发布的组件也是以扩展点的实现形式发布，因此 Dubbo 可以平等的对待所有官方与第三方组件扩展。
+* 扩展适配能力是实现 Dubbo 微服务生态的关键，Dubbo 生态组件如全链路追踪、注册中心实现等的适配都是基于
Filter、Registry、DynamicConfiguration 等扩展点实现。
+* 扩展适配给用户带来最大的灵活性，开发者可以随时接入公司内部组件、按需定制核心能力等。
+
+
+
+以上是按架构层次划分的 Dubbo 内的一些核心扩展点定义及实现，从三个层次来展开：
+* 协议通信层
+* 流量管控层
+* 服务治理层
+
+## 协议通信层
+在通信协议一节我们强调过，Dubbo 不绑定任何协议，用户可以选择 Triple、gRPC、Dubbo2、REST、自定义协议等任一 RPC
远程通信协议，除此之外，RPC 协议之上的数据编码格式 (即序列化协议) 也是通过扩展点定义，用户可以灵活选择 RPC 与序列化的通信协议组合。
+
+
+
+### Protocol
+Protocol 扩展点定义对应的是 RPC 协议，利用这个扩展点可以让 Dubbo
作为统一的微服务开发和治理框架，而在下层通信协议上实现灵活切换。官方发布了对大多数主流 RPC
通信协议的适配，你可以通过几条简单的配置直接使用，如果你想使用公司自定义的 RPC 通信协议，请通过 Protocol 提供自定义扩展实现。
+
+### Serialization
+Serialization 扩展点定义了序列化协议扩展，Dubbo 官方提供了 Fastjson、Protobuf、Hessian2、Kryo、FST
等序列化协议适配。
+
+## 流量管控层
+Dubbo 在服务调用链路上预置了大量扩展点，通过这些扩展点用户可以控制运行态的流量走向、改变运行时调用行为等，包括 Dubbo
内置的一些负载均衡策略、流量路由策略、超时等很多流量管控能力都是通过这类扩展点实现的。
+
+
+
+### Filter
+Filter 流量拦截器是 Dubbo 服务调用之上的 AOP 设计模式，Filter 用来对每次服务调用做一些预处理、后处理动作，使用 Filter
可以完成访问日志、加解密、流量统计、参数验证等任务，Dubbo 中的很多生态适配如限流降级 Sentinel、全链路追踪 Tracing 等都是通过
Fitler 扩展实现的。一次请求过程中可以植入多个 Filter，Filter 之间相互独立没有依赖。
+* 从消费端视角，它在请求发起前基于请求参数等做一些预处理工作，在接收到响应后，对响应结果做一些后置处理；
+* 从提供者视角则，在接收到访问请求后，在返回响应结果前做一些预处理，
+
+### Router
+Router 路由器是 Dubbo 中流量管控的关键组件，它将符合一定条件的流量转发到特定分组的地址子集，是 Dubbo
流量管控中一些关键能力如按比例流量转发、流量隔离等的基础。每次服务调用请求都会流经一组路由器
(路由链)，每个路由器根据预先设定好的规则、全量地址列表以及当前请求上下文计算出一个地址子集，再传给下一个路由器，重复这一过程直到最后得出一个有效的地址子集。
+
+Dubbo 官方发布版本预置了丰富的流量管控规则与 router 实现，如 [流量管控]()
一文中阐述的，用户通过下发规则即可实现各种模式的流量管控。如果有其他流量管控诉求，可以通过提供自定义的 router 扩展实现。
+
+### Load Balance
+在 Dubbo 中，Load Balance 负载均衡工作在 router 之后，对于每次服务调用，负载均衡负责在 router
链输出的地址子集中选择一台机器实例进行访问，保证一段时间内的调用都均匀的分布在地址子集的所有机器上。
+
+Dubbo 官方提供了加权随机、加权轮询、一致性哈希、最小活跃度优先、最短响应时间优先等负载均衡策略，还提供了根据集群负载自适应调度的负载均衡算法。
+
+## 服务治理层
+以下是 Dubbo 部署的经典架构图，由注册中心 (服务发现)、配置中心和元数据中心构成了整个服务治理的核心。
+
+
+
+这里我们主要从架构、实现的视角来分析了 Dubbo 服务治理，Dubbo 很多服务治理的核心能力都是通过上图描述的几个关键组件实现的，用户通过控制面或者
Admin 下发的各种规则与配置、各类微服务集群状态的展示等都是直接与注册中心、配置中心和元数据中心交互。
+
+在具体实现或者部署上，注册中心、配置中心和元数据中心可以是同一组件，比如 Zookeeper 可同时作为注册、配置和元数据中心，Nacos
也是如此。因此，三个中心只是从架构职责上的划分，你甚至可以用同一个 Zookeeper
集群来承担所有三个职责，只需要在应用里将他们设置为同一个集群地址就可以了。
+
+> 在云原生部署架构下，随着 Kubernetes、Service Mesh 架构的流行，微服务基础设施呈现下沉趋势，注册、配置和元数据中心的职责正被
Kubernetes、Istio 等组件取代，具体可参见 [服务网格]() 一节的描述。
+
+### Registry
+注册中心是 Dubbo 实现服务发现能力的基础，Dubbo 官方支持 Zookeeper、Nacos、Etcd、Consul、Eureka 等注册中心。
+
+通过对 Consul、Eureka 的支持，Dubbo 也实现了与 Spring Cloud 体系在地址和通信层面的互通，让用户同时部署 Dubbo 与
Spring Cloud，或者从 Spring Cloud 迁移到 Dubbo 变得更容易。
+
+### Config Center
+配置中心是用户实现动态控制 Dubbo 行为的关键组件，我们在 [流量管控]() 任务中下发的所有规则，都是先下发到配置中心保存起来，进而 Dubbo
实例通过监听配置中心的变化，收到路由规则并达到控制流量的行为。
+
+Dubbo 官方支持 Zookeeper、Nacos、Etcd、Redis、Apollo 等配置中心实现。
+
+### Metadata Center
+与配置中心相反，从用户视角来看元数据中心是只读的，元数据中心唯一的写入放是 Dubbo 进程实例，Dubbo
实例会在启动之后将一些内部状态（如服务列表、服务配置、服务定义格式等）上报到元数据中心，供一些治理能力作为数据来源，如服务测试、文档管理、服务状态展示等。
+
+Dubbo 官方支持 Zookeeper、Nacos、Etcd、Redis 等元数据中心实现。
+
+## 更多扩展
+本文列出了 Dubbo 常用的一些扩展点，但还有大量的扩展点可供灵活定制，并且不同语言 sdk 的扩展定义和配置方式上也存在差异，以下是 Dubbo SDK
的扩展点手册。
+
+* [Java 扩展点手册]()
+* [Go 扩展点手册]()
+* [Rust 扩展点手册]()
+* [Node.js 扩展点手册]()
+
+
+
diff --git a/content/zh/overview/core-features/load-balance.md
b/content/zh/overview/core-features/load-balance.md
index 421b990aa65..43568d27e3c 100644
--- a/content/zh/overview/core-features/load-balance.md
+++ b/content/zh/overview/core-features/load-balance.md
@@ -4,4 +4,84 @@ title: "负载均衡"
linkTitle: "负载均衡"
weight: 20
description: ""
----
\ No newline at end of file
+---
+
+在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 `weighted random` 基于权重的随机负载均衡策略。
+
+具体实现上，Dubbo 提供的是客户端负载均衡，即由 Consumer 通过负载均衡算法得出需要将请求提交到哪个 Provider 实例。
+
+## 负载均衡策略
+目前 Dubbo 内置了如下负载均衡算法，可通过调整配置项启用。
+
+| 算法 | 特性 | 备注
|
+| :-------------------------- | :---------------------- |
:---------------------------------------------- |
+| Weighted Random LoadBalance | 加权随机 | 默认算法，默认权重相同
|
+| RoundRobin LoadBalance | 加权轮询 | 借鉴于 Nginx
的平滑加权轮询算法，默认权重相同， |
+| LeastActive LoadBalance | 最少活跃优先 + 加权随机 | 背后是能者多劳的思想
|
+| Shortest-Response LoadBalance | 最短响应优先 + 加权随机 | 更加关注响应速度
|
+| ConsistentHash LoadBalance | 一致性哈希 | 确定的入参，确定的提供者，适用于有状态请求
|
+
+### Weighted Random
+
+* **加权随机**，按权重设置随机概率。
+* 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
+* 缺点：存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
+
+### RoundRobin
+* **加权轮询**，按公约后的权重设置轮询比率，循环调用节点
+* 缺点：同样存在慢的提供者累积请求的问题。
+
+加权轮询过程过程中，如果某节点权重过大，会存在某段时间内调用过于集中的问题。
+例如 ABC 三节点有如下权重：`{A: 3, B: 2, C: 1}`
+那么按照最原始的轮询算法，调用过程将变成：`A A A B B C`
+
+对此，Dubbo 借鉴 Nginx 的平滑加权轮询算法，对此做了优化，调用过程可抽象成下表:
+
+| 轮前加和权重 | 本轮胜者 | 合计权重 | 轮后权重（胜者减去合计权重） |
+| :------------------ | :------- | :------- | :--------------------------- |
+| 起始轮 | \ | \ | `A(0), B(0), C(0)` |
+| `A(3), B(2), C(1)` | A | 6 | `A(-3), B(2), C(1)` |
+| `A(0), B(4), C(2)` | B | 6 | `A(0), B(-2), C(2)` |
+| `A(3), B(0), C(3)` | A | 6 | `A(-3), B(0), C(3)` |
+| `A(0), B(2), C(4)` | C | 6 | `A(0), B(2), C(-2)` |
+| `A(3), B(4), C(-1)` | B | 6 | `A(3), B(-2), C(-1)` |
+| `A(6), B(0), C(0)` | A | 6 | `A(0), B(0), C(0)` |
+
+我们发现经过合计权重（3+2+1）轮次后，循环又回到了起点，整个过程中节点流量是平滑的，且哪怕在很短的时间周期内，概率都是按期望分布的。
+
+如果用户有加权轮询的需求，可放心使用该算法。
+
+### LeastActive
+* **加权最少活跃调用优先**，活跃数越低，越优先调用，相同活跃数的进行加权随机。活跃数指调用前后计数差（针对特定提供者：请求发送数 -
响应返回数），表示特定提供者的任务堆积量，活跃数越低，代表该提供者处理能力越强。
+* 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大；相对的，处理能力越强的节点，处理更多的请求。
+
+### ShortestResponse
+* **加权最短响应优先**，在最近一个滑动窗口中，响应时间越短，越优先调用。相同响应时间的进行加权随机。
+* 使得响应时间越快的提供者，处理更多的请求。
+* 缺点：可能会造成流量过于集中于高性能节点的问题。
+
+这里的响应时间 = 某个提供者在窗口时间内的平均响应时间，窗口时间默认是 30s。
+
+
+### ConsistentHash
+* **一致性 Hash**，相同参数的请求总是发到同一提供者。
+* 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
+* 算法参见：[Consistent Hashing |
WIKIPEDIA](http://en.wikipedia.org/wiki/Consistent_hashing)
+* 缺省只对第一个参数 Hash，如果要修改，请配置 `<dubbo:parameter key="hash.arguments" value="0,1"
/>`
+* 缺省用 160 份虚拟节点，如果要修改，请配置 `<dubbo:parameter key="hash.nodes" value="320" />`
+
+## 配置方式
+Dubbo
支持在服务提供者一侧配置默认的负载均衡策略，这样所有的消费者都将默认使用提供者指定的负载均衡策略，消费者可以自己配置要使用的负载均衡策略，如果都没有任何配置，
+则默认使用随机负载均衡策略。
+
+同一个应用内支持配置不同的服务使用不同的负载均衡策略，支持为同一服务的不同方法配置不同的负载均衡策略。
+
+具体配置方式参加以下多语言实现
+
+* [Java]()
+* [Golang]()
+* [Rust]()
+* [Node.js]()
+
+## 自定义扩展
+负载均衡策略支持自定义扩展实现，具体请参见 [Dubbo 可扩展性](../extensibility)
\ No newline at end of file
diff --git a/content/zh/overview/core-features/more.md
b/content/zh/overview/core-features/more.md
new file mode 100644
index 00000000000..07faf637615
--- /dev/null
+++ b/content/zh/overview/core-features/more.md
@@ -0,0 +1,71 @@
+---
+type: docs
+title: "更多高级功能"
+linkTitle: "更多高级功能"
+weight: 100
+description: ""
+---
+作为一款与应用开发紧密相关的微服务框架，同时旨在为微服务集群提供完善的服务治理能力，Dubbo
还提供了很多高级功能，涵盖服务调用行为控制、服务诊断与调优、服务治理等。
+
+多种语言 sdk 在功能实现、配置方式上会略有差异，具体功能列表和使用方式可参考如下文档：
+* [Java]()
+* [Golang]()
+* [Rust]()
+* [Node.js]()
+
+## 控制服务调用行为
+* 服务版本
+* 服务分组
+* 分组聚合
+* 异步调用
+* 异步执行
+* 流式通信
+* 响应式编程
+* 泛化调用
+* 泛化实现
+* 调用链路传递隐式参数
+* RPC调用上下文
+* 调用触发事件通知
+* 服务端对客户端进行回调
+* 只订阅
+* 只注册
+* 运行时动态指定 IP 调用
+* 直连提供者
+* 启动时检查
+* 本地调用
+* 参数校验
+* 本地伪装
+* 本地存根
+* 回声测试
+* 调用信息记录
+* 延迟暴露
+* 集群容错
+* 服务降级
+
+## 诊断与调优
+* 端口协议复用
+* 线程池隔离
+* 多协议
+* 多注册中心
+* 请求耗时采样
+* 线程模型
+* 服务引用配置对象缓存
+* 路由状态采集
+* 负载均衡
+* 注册信息简化
+* 调用结果缓存
+* 并发控制
+* 连接控制
+* 延迟连接
+* 粘滞连接
+* 支持 Graal VM
+* 导出线程堆栈
+* Kryo 和 FST 序列化
+* 自定义服务容器
+* 优雅停机
+* 主机地址自定义暴露
+* 一致性哈希选址
+* 日志框架适配及运行时管理
+* Kubernetes 生命周期探针
+
+
diff --git a/content/zh/overview/core-features/observability.md
b/content/zh/overview/core-features/observability.md
index 5221be558d2..8b7445e27be 100644
--- a/content/zh/overview/core-features/observability.md
+++ b/content/zh/overview/core-features/observability.md
@@ -8,5 +8,39 @@ feature:
title: 可观测性
description: >
多维度的可观测指标（Metrics、Tracing、Access Logs）帮助了解服务运行状态，为持续定位、维护和优化服务提供依据，Admin
控制台帮助实现数据指标可视化展示
+---
+
+Dubbo 内部维护了多个纬度的可观测指标，并且支持多种方式的可视化监测。可观测性指标从总体上来说分为三个度量纬度：
+
+* **Metrics。** Dubbo 统计了一系列的流量指标如
QPS、RT、成功请求数、失败请求数等，还包括一系列的内部组件状态如线程池数、服务健康状态等。
+
+* **Tracing。** Dubbo 与业界主流的链路追踪工作做了适配，包括 Skywalking、Zipkin、Jaeger 都支持 Dubbo
服务的链路追踪。
+
+* **Logging。** Dubbo 支持多种日志框架适配。以 Java 体系为例，支持包括
Slf4j、Log4j2、Log4j、Logback、Jcl 等，用户可以基于业务需要选择合适的框架；同时 Dubbo 还支持 Access Log
记录请求踪迹。
+
+## Metrics
+Dubbo 运行时统计了包括 qps、rt、调用总数、成功数、失败数，失败原因统计等在内的核心服务指标，同时，为了更好的监测服务运行状态，Dubbo
还提供了对核心组件状态的监控，如线程池数量、服务健康状态等。
+
+可以通过 Dubbo Admin 可视化的查看 Metrics 指标
+
+![Admin 效果图]()
+
+也可以使用 Grafana、Prometheus 等实现可视化指标监测，具体请参考以下可视化任务示例：
+
+* [Admin 任务链接]()
+* [Grafana 任务链接]()
+* [Prometheus 任务链接]()
+
+## Tracing
+全链路追踪对于监测分布式系统运行状态具有非常重要的价值，Dubbo 通过 Filter 拦截器实现了请求运行时的埋点跟踪，通过将跟踪数据导出到一些主流实现如
Zipkin、Skywalking、Jaeger 等，可以实现全链路跟踪数据的分析与可视化展示。
+
+只需要简单的一行配置即可切换链路跟踪的后端实现，并且，你可以随时通过 Dubbo Admin 等治理平台动态调整 Dubbo
的链路追踪采样率，对于问题排查都非常有价值。
+
+* [基于 Skywalking 实现全链路追踪]()
+* [基于 Zipkin 实现全链路追踪]()
+
+## Logging
+访问日志可以帮助分析系统的流量情况，在有些场景下，开启访问日志对于排查问题也非常有帮助。
+
+* [开启 Access Log]()
----
\ No newline at end of file
diff --git a/content/zh/overview/core-features/protocols.md
b/content/zh/overview/core-features/protocols.md
index 924ce46275e..12b6f9a847c 100644
--- a/content/zh/overview/core-features/protocols.md
+++ b/content/zh/overview/core-features/protocols.md
@@ -8,4 +8,74 @@ feature:
title: 多种通信协议
description: >
根据技术栈与业务需求选择合适的通信协议，如 gRPC/Triple (HTTP/2)、TCP 二进制、HTTP+JSON
等，切换协议只需要修改一行配置，同时支持单个端口上的多协议发布
----
\ No newline at end of file
+---
+
+Dubbo 框架提供了自定义的高性能 RPC 通信协议：基于 HTTP/2 的 Triple 协议 和 基于 TCP 的 Dubbo2
协议。除此之外，Dubbo 框架支持任意第三方通信协议，如官方支持的 gRPC、Thrift、REST、JsonRPC、Hessian2
等，更多协议可以通过自定义扩展实现。这对于微服务实践中经常要处理的多协议通信场景非常有用。
+
+**Dubbo 框架不绑定任何通信协议，在实现上 Dubbo 对多协议的支持也非常灵活，它可以让你在一个应用内发布多个使用不同协议的服务，并且支持用同一个
port 端口对外发布所有协议。**
+
+
+
+通过 Dubbo 框架的多协议支持，你可以做到：
+* 将任意通信协议无缝地接入 Dubbo 服务治理体系。Dubbo 体系下的所有通信协议，都可以享受到 Dubbo
的编程模型、服务发现、流量管控等优势。比如 gRPC over Dubbo 的模式，服务治理、编程 API 都能够零成本接入 Dubbo 体系。
+* 兼容不同技术栈，业务系统混合使用不同的服务框架、RPC 框架。比如有些服务使用 gRPC 或者 Spring Cloud 开发，有些服务使用 Dubbo
框架开发，通过 Dubbo 的多协议支持可以很好的实现互通。
+* 让协议迁移变的更简单。通过多协议、注册中心的协调，可以快速满足公司内协议迁移的需求。比如如从自研协议升级到 Dubbo 协议，Dubbo
协议自身升级，从 Dubbo 协议迁移到 gRPC，从 HTTP 迁移到 Dubbo 协议等。
+
+## HTTP/2 (Triple)
+Triple 协议是 Dubbo3 发布的面向云原生时代的通信协议，它基于 HTTP/2 并且完全兼容 gRPC 协议，原生支持 Streaming
通信语义，自 Triple 协议开始，Dubbo 还支持基于 Protobuf 的服务定义与数据传输。Triple
具备更好的网关、代理穿透性，因此非常适合于跨网关、代理通信的部署架构，如服务网格等。
+
+Triple 协议的核心特性如下：
+* 支持 TLS 加密、Plaintext 明文数据传输
+* 支持反压与限流
+* 支持 Streaming 流式通信
+
+在编程与通信模型上，Triple 协议支持如下模式：
+* 消费端异步请求(Client Side Asynchronous Request-Response)
+* 提供端异步执行（Server Side Asynchronous Request-Response）
+* 消费端请求流（Request Streaming）
+* 提供端响应流（Response Streaming）
+* 双向流式通信（Bidirectional Streaming）
+
+开发实践
+* [Triple 协议使用]() 请参见具体语言 sdk 文档
+* [Triple 协议规范]()
+
+## Dubbo2
+Dubbo2 协议是基于 TCP 传输层协议之上构建的一套 RPC 通信协议，由于其紧凑、灵活、高性能的特点，在 Dubbo2
时代取得了非常广泛的应用，是企业构建高性能、大规模微服务集群的关键通信方案。在云原生时代，我们更推荐使用通用性、穿透性更好的 Triple 协议。
+
+[Dubbo2 协议规范]()
+
+## gRPC
+你可以用 Dubbo 开发和治理微服务，然后设置使用 gRPC 协议进行底层通信。但为什么要这么做那，与直接使用 gRPC
框架对比有什么优势？简单的答案是，这是使用 gRPC 进行微服务开发的常用模式，具体请往下看。
+
+gRPC 是谷歌开源的基于 HTTP/2 的通信协议，如同我们在 [产品对比]() 文档中提到的，gRPC 的定位是通信协议与实现，是一款纯粹的 RPC
框架，而 Dubbo 定位是一款微服务框架，为微服务实践提供解决方案。因此，相比于 Dubbo，gRPC 相对欠缺了微服务编程模型、服务治理等能力的抽象。
+
+在 Dubbo 体系下使用 gRPC 协议 (gRPC over Dubbo Framework) 是一个非常高效和轻量的选择，它让你既能使用原生的
gRPC 协议通信，又避免了基于 gRPC 进行二次定制与开发的复杂度 (二次开发与定制 gRPC，是很多企业规模化实践后证实不可避免的环节，Dubbo
框架替开发者完成了这一步，让开发者可以直接以最简单的方式使用 gRPC)。
+
+[gRPC over Dubbo 示例]()
+
+## REST
+微服务领域常用的一种通信模式是 HTTP + JSON，包括 Spring Cloud、Microprofile
等一些主流的微服务框架都默认使用的这种通信模式，Dubbo 同样提供了对基于 HTTP 的编程、通信模式的支持。
+
+* [HTTP over Dubbo 示例]()
+* [Dubbo 与 Spring Cloud 体系互通]()
+
+## 其他通信协议
+除了以上介绍的几种协议之外，你还可以将以下协议运行在 Dubbo 之上。对 Dubbo
而言，只需要修改一行简单的配置，就可以切换底层服务的通信协议，其他外围 API 和治理能力不受影响。
+* Hessian2
+* Thrift
+* JsonRPC
+
+## 异构微服务体系互通
+关于协议迁移、多协议技术栈共存的实践方案，请参考本篇[博客文章](../../../blog/java/demos/multiple-protocols-registries.md)。
+
+## 配置方式
+以上协议的配置和使用方式，包括如何配置 `单端口多协议` 支持等，请参照以下 sdk 示例文档：
+
+* [Java]()
+* [Golang]()
+* [Rust]()
+* [Node.js]()
+
+## 自定义扩展
+除了以上官方版本支持的通信协议，Dubbo 支持扩展新协议支持，具体请参见 [Dubbo 可扩展性](../extensibility)
diff --git a/content/zh/overview/core-features/security.md
b/content/zh/overview/core-features/security.md
index 05c2d683c10..56c156e6552 100644
--- a/content/zh/overview/core-features/security.md
+++ b/content/zh/overview/core-features/security.md
@@ -2,10 +2,109 @@
type: docs
title: "认证鉴权"
linkTitle: "认证鉴权"
-weight: 80
+weight: 70
description: ""
feature:
title: 认证鉴权
description: >
支持基于 TLS 的传输链路认证与加密通信、基于 token
的请求级别认证，支持基于服务来源和目的地的鉴权检查，可结合证书分发等分布式组件构建零信任分布式体系。
----
\ No newline at end of file
+---
+
+Breaking down a monolithic application into atomic services offers various
benefits, including better agility, better scalability and better ability to
reuse services. However, microservices also have particular security needs:
+
+* To defend against man-in-the-middle attacks, they need traffic encryption.
+* To provide flexible service access control, they need mutual TLS and
fine-grained access policies.
+* To determine who did what at what time, they need auditing tools.
+
+Istio Security provides a comprehensive security solution to solve these
issues. This page gives an overview on how you can use Istio security features
to secure your services, wherever you run them. In particular, Istio security
mitigates both insider and external threats against your data, endpoints,
communication, and platform.
+
+The Istio security features provide strong identity, powerful policy,
transparent TLS encryption, and authentication, authorization and audit (AAA)
tools to protect your services and data.
+
+## 架构
+
+Security in Istio involves multiple components:
+
+* A Certificate Authority (CA) for key and certificate management
+* The configuration API server distributes to the proxies:
+ * authentication policies
+ * authorization policies
+ * secure naming information
+* Sidecar and perimeter proxies work as Policy Enforcement Points (PEPs) to
secure communication between clients and servers.
+* A set of Envoy proxy extensions to manage telemetry and auditing
+
+The control plane handles configuration from the API server and configures the
PEPs in the data plane. The PEPs are implemented using Envoy. The following
diagram shows the architecture.
+
+
+
+> **证书的生成和分发不在本文讨论范围，我们假设您已经有完善的基础设施解决了证书管理问题，因此，我们将更专注在讲解 Dubbo
体系的认证和鉴权机制与流程。** 如果您并没有这些证书管理设施，我们推荐您使用服务网格架构 (具体请参见 [Dubbo Mesh 服务网格]()
文档说明)，借助 [Istio](https://istio.io/latest/docs/concepts/security/)
等服务网格控制面的证书管理机制和安全策略，您可以很容易将 Dubbo 集群的认证和鉴权能力实施起来。
+
+## Authentication 认证
+
+Istio provides two types of authentication:
+
+* Peer authentication: used for service-to-service authentication to verify
the client making the connection. Istio offers mutual TLS as a full stack
solution for transport authentication, which can be enabled without requiring
service code changes. This solution:
+ * Provides each service with a strong identity representing its role to
enable interoperability across clusters and clouds.
+ * Secures service-to-service communication.
+ * Provides a key management system to automate key and certificate
generation, distribution, and rotation.
+* Request authentication: Used for end-user authentication to verify the
credential attached to the request. Istio enables request-level authentication
with JSON Web Token (JWT) validation and a streamlined developer experience
using a custom authentication provider or any OpenID Connect providers, for
example:
+ * ORY Hydra
+ * Keycloak
+ * Auth0
+ * Firebase Auth
+ * Google Auth
+
+In all cases, Istio stores the authentication policies in the Istio config
store via a custom Kubernetes API. Istiod keeps them up-to-date for each proxy,
along with the keys where appropriate. Additionally, Istio supports
authentication in permissive mode to help you understand how a policy change
can affect your security posture before it is enforced.
+
+### 架构图
+You can specify authentication requirements for workloads receiving requests
in an Istio mesh using peer and request authentication policies. The mesh
operator uses .yaml files to specify the policies. The policies are saved in
the Istio configuration storage once deployed. The Istio controller watches the
configuration storage.
+
+Upon any policy changes, the new policy is translated to the appropriate
configuration telling the PEP how to perform the required authentication
mechanisms. The control plane may fetch the public key and attach it to the
configuration for JWT validation. Alternatively, Istiod provides the path to
the keys and certificates the Istio system manages and installs them to the
application pod for mutual TLS. You can find more info in the Identity and
certificate management section.
+
+Istio sends configurations to the targeted endpoints asynchronously. Once the
proxy receives the configuration, the new authentication requirement takes
effect immediately on that pod.
+
+Client services, those that send requests, are responsible for following the
necessary authentication mechanism. For request authentication, the application
is responsible for acquiring and attaching the JWT credential to the request.
For peer authentication, Istio automatically upgrades all traffic between two
PEPs to mutual TLS. If authentication policies disable mutual TLS mode, Istio
continues to use plain text between PEPs. To override this behavior explicitly
disable mutual TLS mod [...]
+
+
+
+#### TLS
+
+#### mutual TLS
+Istio tunnels service-to-service communication through the client- and
server-side PEPs, which are implemented as Envoy proxies. When a workload sends
a request to another workload using mutual TLS authentication, the request is
handled as follows:
+
+1. Istio re-routes the outbound traffic from a client to the client’s local
sidecar Envoy.
+2. The client side Envoy starts a mutual TLS handshake with the server side
Envoy. During the handshake, the client side Envoy also does a secure naming
check to verify that the service account presented in the server certificate is
authorized to run the target service.
+3. The client side Envoy and the server side Envoy establish a mutual TLS
connection, and Istio forwards the traffic from the client side Envoy to the
server side Envoy.
+4. The server side Envoy authorizes the request. If authorized, it forwards
the traffic to the backend service through local TCP connections.
+
+### 认证策略
+
+https://istio.io/latest/docs/concepts/security/#authentication-policies
+
+## Authorization 鉴权
+
+Istio’s authorization features provide mesh-, namespace-, and workload-wide
access control for your workloads in the mesh. This level of control provides
the following benefits:
+
+* Workload-to-workload and end-user-to-workload authorization.
+* A simple API: it includes a single AuthorizationPolicy CRD, which is easy to
use and maintain.
+* Flexible semantics: operators can define custom conditions on Istio
attributes, and use CUSTOM, DENY and ALLOW actions.
+* High performance: Istio authorization (ALLOW and DENY) is enforced natively
on Envoy.
+* High compatibility: supports gRPC, HTTP, HTTPS and HTTP/2 natively, as well
as any plain TCP protocols.
+
+### 架构图
+
+The authorization policy enforces access control to the inbound traffic in the
server side Envoy proxy. Each Envoy proxy runs an authorization engine that
authorizes requests at runtime. When a request comes to the proxy, the
authorization engine evaluates the request context against the current
authorization policies, and returns the authorization result, either ALLOW or
DENY. Operators specify Istio authorization policies using .yaml files.
+
+
+
+Dubbo 完整的鉴权工作流程如下：
+
+
+
+### 鉴权策略
+鉴权策略
+
+https://istio.io/latest/docs/concepts/security/#authorization-policies
+
+## 示例任务
+
+访问如下 [示例]() 进行安全策略动手实践。
diff --git a/content/zh/overview/core-features/service-definition.md
b/content/zh/overview/core-features/service-definition.md
index 14a2fe722ff..27fd038a8e5 100644
--- a/content/zh/overview/core-features/service-definition.md
+++ b/content/zh/overview/core-features/service-definition.md
@@ -1,7 +1,7 @@
---
type: docs
-title: "定义服务"
-linkTitle: "定义服务"
+title: "Dubbo 一站式微服务开发"
+linkTitle: "微服务开发"
weight: 1
description: ""
feature:
diff --git a/content/zh/overview/core-features/service-discovery.md
b/content/zh/overview/core-features/service-discovery.md
index 82f83e498db..bf32d294345 100644
--- a/content/zh/overview/core-features/service-discovery.md
+++ b/content/zh/overview/core-features/service-discovery.md
@@ -10,3 +10,60 @@ feature:
服务地址注册与发现是构建微服务体系的关键，Dubbo 默认提供 Nacos、Zookeeper 等注册中心并支持自定义扩展；Dubbo3
应用级服务发现模型解决 Dubbo2 规模瓶颈问题的同时，实现了与 Kubernetes Native Service 及 Spring Cloud
等微服务体系的互通。
---
+Dubbo 提供的是一种 Client-Based 的服务发现机制，依赖第三方注册中心组件来协调服务发现过程，支持常用的注册中心如
Nacos、Consul、Zookeeper 等。
+
+以下是 Dubbo 服务发现机制的基本工作原理图：
+
+
+
+服务发现包含提供者、消费者和注册中心三个参与角色，其中，Dubbo 提供者实例注册 URL 地址到注册中心，注册中心负责对数据进行聚合，Dubbo
消费者从注册中心读取地址列表并订阅变更，每当地址列表发生变化，注册中心将最新的列表通知到所有订阅的消费者实例。
+
+## 面向百万实例集群的服务发现机制
+区别于其他很多微服务框架的是，**Dubbo3
的服务发现机制诞生于阿里巴巴超大规模微服务电商集群实践场景，因此，其在性能、可伸缩性、易用性等方面的表现大幅领先于业界大多数主流开源产品**。是企业面向未来构建可伸缩的微服务集群的最佳选择。
+
+
+
+* 首先，Dubbo 注册中心以应用粒度聚合实例数据，消费者按消费需求精准订阅，避免了大多数开源框架如 Istio、Spring Cloud
等全量订阅带来的性能瓶颈。
+* 其次，Dubbo SDK 在实现上对消费端地址列表处理过程做了大量优化，地址通知增加了异步、缓存、bitmap
等多种解析优化，避免了地址更新常出现的消费端进程资源波动。
+* 最后，在功能丰富度和易用性上，服务发现除了同步 ip、port 等端点基本信息到消费者外，Dubbo 还将服务端的 RPC/HTTP
服务及其配置的元数据信息同步到消费端，这让消费者、提供者两端的更细粒度的协作成为可能，Dubbo 基于此机制提供了很多差异化的治理能力。
+
+### 高效地址推送实现
+
+从注册中心视角来看，它负责以应用名 (dubbo.application.name)
对整个集群的实例地址进行聚合，每个对外提供服务的实例将自身的应用名、实例ip:port 地址信息 (通常还包含少量的实例元数据，如机器所在区域、环境等)
注册到注册中心。
+
+> Dubbo2 版本注册中心以服务粒度聚合实例地址，比应用粒度更细，也就意味着传输的数据量更大，因此在大规模集群下也遇到一些性能问题。
+> 针对 Dubbo2 与 Dubbo3 跨版本数据模型不统一的问题，Dubbo3 给出了[平滑迁移方案]()，可做到模型变更对用户无感。
+
+
+
+<br/>
+每个消费服务的实例从注册中心订阅实例地址列表，相比于一些产品直接将注册中心的全量数据 (应用 + 实例地址) 加载到本地进程，Dubbo
实现了按需精准订阅地址信息。比如一个消费者应用依赖 app1、app2，则只会订阅 app1、app2 的地址列表更新，大幅减轻了冗余数据推送和解析的负担。
+
+<p> </p>
+<br/>
+
+
+
+### 丰富元数据配置
+除了与注册中心的交互，Dubbo3 的完整地址发现过程还有一条额外的元数据通路，我们称之为元数据服务
(MetadataService)，实例地址与元数据共同组成了消费者端有效的地址列表。
+
+
+
+完整工作流程如上图所示，首先，消费者从注册中心接收到地址 (ip:port)
信息，然后与提供者建立连接并通过元数据服务读取到对端的元数据配置信息，两部分信息共同组装成 Dubbo
消费端有效的面向服务的地址列表。以上两个步骤都是在实际的 RPC 服务调用发生之前。
+
+> 关于 MetadataService 的定义及完整服务发现流程分析，请查看 [应用级服务发现详解]()。
+
+> 对于微服务间服务发现模型的数据同步，REST 定义了一套非常有意思的成熟度模型，感兴趣的朋友可以参考这里的链接
https://www.martinfowler.com/articles/richardsonMaturityModel.html， 按照文章中的 4
级成熟度定义，Dubbo 当前基于接口粒度的模型可以对应到最高的 L4 级别。
+
+## 配置方式
+Dubbo 服务发现扩展了多种注册中心组件支持，如 Nacos、Zookeeper、Consul、Redis、kubernetes
等，可以通过配置切换不通实现，同时还支持鉴权、命名空间隔离等配置。具体配置方式请查看 SDK 文档
+
+* [Java]()
+* [Golang]()
+* [Rust]()
+* [Node.js]()
+
+Dubbo 还支持一个应用内配置多注册中心的情形如双注册、双订阅等，这对于实现不同集群地址数据互通、集群迁移等场景非常有用处，[最佳实践]()
任务里有关于这部分的示例说明。
+
+## 自定义扩展
+注册中心适配支持自定义扩展实现，具体请参见 [Dubbo 可扩展性](../extensibility)
diff --git a/content/zh/overview/core-features/service-mesh.md
b/content/zh/overview/core-features/service-mesh.md
index f31e942ba72..6f897c5f624 100644
--- a/content/zh/overview/core-features/service-mesh.md
+++ b/content/zh/overview/core-features/service-mesh.md
@@ -2,10 +2,90 @@
type: docs
title: "服务网格"
linkTitle: "服务网格"
-weight: 90
+weight: 80
description: ""
feature:
title: 服务网格(Service Mesh)
description: >
多种形态数据面支持，包括以 Thin SDK 模式与 Envoy 等一起部署或以 Proxyless
模式独立部署，所有模式均可以开源标准方式无缝接入 Istio、Consul 等服务治理体系。
----
\ No newline at end of file
+---
+
+Dubbo Mesh 是 Dubbo 在云原生背景的微服务整体解决方案，它帮助开发者实现 Dubbo 服务与标准的 Kubernetes Native
Service 体系的打通，让 Dubbo 应用能够无缝接入 Istio 等业界主流服务网格产品。
+
+以下是 Dubbo Mesh 的部署架构图
+
+
+
+* 控制面。Istio 作为统一控制面，为集群提供 Kubernetes 适配、服务发现、证书管理、可观测性、流量治理等能力。
+* 数据面。Dubbo 应用实例作为数据面组件，支持两种部署模式
+ * Proxy 模式。Dubbo 进程与 Envoy 部署在同一 pod，进出 Dubbo 的流量都经 Envoy 代理拦截，由 Envoy
执行流量管控。
+ * Proxyless 模式。Dubbo 进程独立部署，进程间直接通信，通过 xDS 协议与控制面直接交互。
+
+关于服务网格架构以及为何要接入 Istio 控制面，请参考 [Istio
官网](https://istio.io/)，本文不包含这部分通用内容的讲解，而是会侧重在 Dubbo Mesh 解决方案本身。
+
+## Dubbo Mesh
+
+### Proxy Mesh
+在 proxy 模式下，Dubbo 与 Envoy 等边车 (Sidecar) 部署在一起
+
+
+
+以上是 Dubbo Proxy Mesh 部署架构图
+* Dubbo 与 Envoy 部署在同一个 Pod 中，Istio 实现对流量和治理的统一管控。
+* Dubbo 只提供面向业务应用的编程 API、RPC 通信能力，其余流量管控能力如地址发现、负载均衡、路由寻址等都下沉到 Envoy，Envoy
拦截所有进出流量并完成路由寻址等服务治理工作。
+* 控制面与 Envoy 之间通过图中虚线所示的 xDS 协议进行配置分发。
+
+在 Proxy 模式下，Dubbo3 通信层选用 Triple、gRPC、REST 等基于 HTTP 的通信协议可以获得更好的网关穿透性与性能体验。
+
+### Proxyless Mesh
+在 Proxyless 模式下，没有 Envoy 等代理组件，Dubbo 进程保持独立部署并直接通信，Istio 控制面通过 xDS 与 Dubbo
进程进行治理能力交互。
+
+
+
+Proxyless 模式下 Dubbo 部署与服务网格之前基本一致，通过不同语言版本的 Dubbo3 SDK 直接实现 xDS 协议解析
+
+#### 为什么需要 Proxyless Mesh
+
+Proxy 模式很好的实现了治理能力与有很多优势，如平滑升级、多语言、业务侵入小等，但也带来了一些额外的问题，比如：
+* Sidecar 通信带来了额外的性能损耗，这在复杂拓扑的网络调用中将变得尤其明显。
+* Sidecar 的存在让应用的声明周期管理变得更加复杂。
+* 部署环境受限，并不是所有的环境都能满足 Sidecar 部署与请求拦截要求。
+
+在 Proxyless 模式下，Dubbo 进程之间继续保持直连通信模式：
+* 没有额外的 Proxy 中转损耗，因此更适用于性能敏感应用
+* 更有利于遗留系统的平滑迁移
+* 架构简单，容易运维部署
+* 适用于几乎所有的部署环境
+
+## 示例任务
+了解了足够多的原理知识，我们推荐你访问如下 [示例]() 进行动手实践。
+
+## 可视化
+推荐使用 [Dubbo Admin]() 作为您 Dubbo 集群的可视化控制台，它兼容所有 Kubernetes、Mesh 和非 Mesh 架构的部署。
+
+除此之外，你也可以使用 [Istio
官方推荐的可视化工具](https://istio.io/latest/docs/tasks/observability/kiali/) 来管理您的
Dubbo Mesh 集群。
+
+## 接入非 Istio 控制面
+Dubbo Mesh 本身并不绑定任何控制面产品实现，你可以使用 Istio、Linkerd、Kuma 或者任一支持 xDS 协议的控制面产品，对于
Sidecar 亦是如此。
+
+如果你已经完整的体验了 [基于 Istio 的 Dubbo Mesh]() 示例任务，并且发现 Istio 很好的满足了你的 Dubbo Mesh
治理诉求，那么采用 Istio 作为你的控制面是首选的解决方案。
+
+如果你发现 Istio 模式下 Dubbo 部分能力受限，而这部分能力正好是你需要的，那么你需要考虑接入 Dubbo 控制面，用 Dubbo 控制面来替代
Istio，以获得更多 Dubbo 体系原生能力支持、更好的性能体验。具体请参见 [基于 Dubbo 定制控制面 的 Dubbo Mesh]() 示例任务。
+
+> 简单来讲，这是 Dubbo 社区发布的一款基于 Istio 的定制版本控制面，Dubbo 控制面安装与能力差异请参见上面的示例任务链接。
+
+## 老系统迁移方案
+### 如何解决注册中心数据同步的问题？
+
+
+### 如何解决 Dubbo2 协议通信的问题？
+
+Aeraki Mesh
+
+
+
+
+
+
+
+
diff --git a/content/zh/overview/core-features/traffic/_index.md
b/content/zh/overview/core-features/traffic/_index.md
index 3327f7ff04c..2809daa3791 100755
--- a/content/zh/overview/core-features/traffic/_index.md
+++ b/content/zh/overview/core-features/traffic/_index.md
@@ -6,6 +6,11 @@ linkTitle: "流量管控"
weight: 30
---
+Dubbo 提供了多种策略和实现，可以很好的管控流入、流出 Dubbo 集群的流量。从 Server 视角来看，部署 Dubbo
应用的实例是时刻在动态变化的，因此消费方 (Dubbo Consumer) 要能随时感知节点变化并将流量均匀的分布到每个实例上，Dubbo
的服务发现与负载均衡机制可以很好的解决这个问题；Dubbo
中有应用、服务和方法的概念，一个应用可以发布多个服务，一个服务包含多个可被调用的方法，从抽象的视角来看，一次 Dubbo
调用就是某个消费方应用发起了对某个提供方 (Dubbo Provider) 应用内的某个服务特定方法的调用，Dubbo
的流量管控规则可以基于应用、服务、方法、参数等粒度精准的控制流量走向。
+
+Dubbo 服务发现保证调用方随时看到最新的提供方实例地址，服务发现机制依赖注册中心的协调，注册中心可以是 Zookeeper、Nacos
等独立集群，也可以是 Istio 等控制面组件。在消费端，Dubbo
提供了多种负载均衡策略，比如通过随机负载均衡策略能最大限度的做到流量在后端实例上的均匀分布，而一致性哈希负载均衡、基于权重的负载均衡等策略则能满足一些特定场景的流量调度需求。
+
+从流量管控的视角，一次请求的目标是服务和方法，Dubbo
的流量管控就是根据请求的目标服务、方法以及请求体中的其他附加参数进行匹配的，符合匹配太条件的流量会被按照特定规则转发到一个地址子集。匹配条件最细支持到方法粒度，同时还能根据参数值进行流量转发。如果是基于
http 的 rpc 协议 (如 REST、gRPC、Triple 等)，则服务和方法的就统一转换为 http 的路径 (path)，此时 Dubbo
的流量规则就是基于 http path 和 headers 的流量分发。
### 标签路由规则
diff --git a/content/zh/overview/quickstart/_index.md
b/content/zh/overview/quickstart/_index.md
index 41aa339d23a..0bebea8a3ef 100755
--- a/content/zh/overview/quickstart/_index.md
+++ b/content/zh/overview/quickstart/_index.md
@@ -1,6 +1,59 @@
---
type: docs
-title: "一文了解 Dubbo 微服务开发、部署全流程"
+title: "入门"
linkTitle: "入门"
weight: 15
+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">
+ <div class="h-100 card shadow" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./java/" >}}'>Java 微服务开发入门</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 "./go/" >}}'>Go 微服务开发入门</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 "./rust/" >}}'>Rust 微服务开发入门</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 "./nodejs/" >}}'>Nodejs 微服务开发入门</a>
+ </h4>
+
<p>同机房/区域优先是指应用调用服务时，优先调用同机房/区域的服务提供者，避免了跨区域带来的网络延时，从而减少了调用的响应时间。
+ </p>
+ </div>
+ </div>
+ </div>
+</div>
+<hr>
+</div>
+
+{{< /blocks/section >}}
\ No newline at end of file
diff --git a/content/zh/overview/quickstart/go/_index.md
b/content/zh/overview/quickstart/go/_index.md
new file mode 100755
index 00000000000..50a71b4047e
--- /dev/null
+++ b/content/zh/overview/quickstart/go/_index.md
@@ -0,0 +1,6 @@
+---
+type: docs
+title: "Go 微服务开发入门"
+linkTitle: "Go"
+weight: 20
+---
diff --git a/content/zh/overview/quickstart/java/_index.md
b/content/zh/overview/quickstart/java/_index.md
new file mode 100755
index 00000000000..a427432d176
--- /dev/null
+++ b/content/zh/overview/quickstart/java/_index.md
@@ -0,0 +1,6 @@
+---
+type: docs
+title: "Java 微服务开发入门"
+linkTitle: "Java"
+weight: 10
+---
diff --git a/content/zh/overview/quickstart/nodejs/_index.md
b/content/zh/overview/quickstart/nodejs/_index.md
new file mode 100755
index 00000000000..88980c0883f
--- /dev/null
+++ b/content/zh/overview/quickstart/nodejs/_index.md
@@ -0,0 +1,6 @@
+---
+type: docs
+title: "Node.js 微服务开发入门"
+linkTitle: "Node.js"
+weight: 40
+---
diff --git a/content/zh/overview/quickstart/rust/_index.md
b/content/zh/overview/quickstart/rust/_index.md
new file mode 100755
index 00000000000..fe8537da2a2
--- /dev/null
+++ b/content/zh/overview/quickstart/rust/_index.md
@@ -0,0 +1,6 @@
+---
+type: docs
+title: "Rust 微服务开发入门"
+linkTitle: "Rust"
+weight: 30
+---
diff --git a/content/zh/overview/tasks/develop/_index.md
b/content/zh/overview/tasks/develop/_index.md
new file mode 100755
index 00000000000..6500971c5fc
--- /dev/null
+++ b/content/zh/overview/tasks/develop/_index.md
@@ -0,0 +1,79 @@
+
+---
+type: docs
+title: "开发服务"
+linkTitle: "开发服务"
+description: ""
+weight: 5
+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 "./template/" >}}'>生成项目模板</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" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./service_reference/" >}}'>发布和引用服务</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" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./async/" >}}'>异步调用</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" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./version_group/" >}}'>版本与分组</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" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./context/" >}}'>上下文参数</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" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./generic/" >}}'>泛化调用</a>
+ </h4>
+ <p></p>
+ </div>
+ </div>
+ </div>
+</div>
+<hr>
+</div>
+
+{{< /blocks/section >}}
\ No newline at end of file
diff --git a/content/zh/overview/tasks/develop/async.md
b/content/zh/overview/tasks/develop/async.md
new file mode 100644
index 00000000000..5b1eb726b65
--- /dev/null
+++ b/content/zh/overview/tasks/develop/async.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "异步调用"
+linkTitle: "异步调用"
+weight: 3
+description: ""
+---
diff --git a/content/zh/overview/tasks/develop/context.md
b/content/zh/overview/tasks/develop/context.md
new file mode 100644
index 00000000000..d867aee9951
--- /dev/null
+++ b/content/zh/overview/tasks/develop/context.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "上下文参数传递"
+linkTitle: "上下文参数"
+weight: 5
+description: ""
+---
diff --git a/content/zh/overview/tasks/develop/generic.md
b/content/zh/overview/tasks/develop/generic.md
new file mode 100644
index 00000000000..ce11529b392
--- /dev/null
+++ b/content/zh/overview/tasks/develop/generic.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "泛化调用"
+linkTitle: "泛化调用"
+weight: 6
+description: ""
+---
diff --git a/content/zh/overview/tasks/develop/service_reference.md
b/content/zh/overview/tasks/develop/service_reference.md
new file mode 100644
index 00000000000..a8ff03010e9
--- /dev/null
+++ b/content/zh/overview/tasks/develop/service_reference.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "发布和调用 Dubbo 服务"
+linkTitle: "发布和调用"
+weight: 2
+description: ""
+---
diff --git a/content/zh/overview/tasks/develop/template.md
b/content/zh/overview/tasks/develop/template.md
new file mode 100644
index 00000000000..5fde6e878b0
--- /dev/null
+++ b/content/zh/overview/tasks/develop/template.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "通过模板生成项目脚手架"
+linkTitle: "生成项目"
+weight: 1
+description: ""
+---
diff --git a/content/zh/overview/tasks/develop/version_group.md
b/content/zh/overview/tasks/develop/version_group.md
new file mode 100644
index 00000000000..b8787b672d3
--- /dev/null
+++ b/content/zh/overview/tasks/develop/version_group.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "版本与分组"
+linkTitle: "版本与分组"
+weight: 4
+description: ""
+---
diff --git a/content/zh/overview/tasks/ecosystem/_index.md
b/content/zh/overview/tasks/ecosystem/_index.md
index 33a7a7bc5ac..66f212bf48d 100755
--- a/content/zh/overview/tasks/ecosystem/_index.md
+++ b/content/zh/overview/tasks/ecosystem/_index.md
@@ -4,7 +4,7 @@ type: docs
title: "微服务生态"
linkTitle: "微服务生态"
description: "围绕 Dubbo 生态的限流降级、全链路追踪、分布式一致性等解决方案"
-weight: 40
+weight: 30
no_list: true
---
diff --git a/content/zh/overview/core-features/configuration.md
b/content/zh/overview/tasks/ecosystem/configuration.md
similarity index 100%
rename from content/zh/overview/core-features/configuration.md
rename to content/zh/overview/tasks/ecosystem/configuration.md
diff --git a/content/zh/overview/tasks/extensibility/_index.md
b/content/zh/overview/tasks/extensibility/_index.md
index 8ac4957ec12..8559112df33 100755
--- a/content/zh/overview/tasks/extensibility/_index.md
+++ b/content/zh/overview/tasks/extensibility/_index.md
@@ -1,8 +1,8 @@
---
type: docs
-title: "可扩展性"
-linkTitle: "可扩展性"
+title: "自定义扩展"
+linkTitle: "自定义扩展"
description: "演示如何将 Dubbo 部署到 Kubernetes 并复用 Kubernetes Native Service。"
weight: 60
no_list: true
diff --git a/content/zh/overview/tasks/kubernetes/_index.md
b/content/zh/overview/tasks/kubernetes/_index.md
index 59edd416e0c..b0ac4b3cf75 100755
--- a/content/zh/overview/tasks/kubernetes/_index.md
+++ b/content/zh/overview/tasks/kubernetes/_index.md
@@ -1,10 +1,10 @@
---
type: docs
-title: "Kubernetes"
-linkTitle: "Kubernetes"
-description: "演示如何将 Dubbo 部署到 Kubernetes 并复用 Kubernetes Native Service。"
-weight: 60
+title: "部署服务"
+linkTitle: "部署服务"
+description: ""
+weight: 10
no_list: true
feature:
title: 云原生友好
@@ -20,7 +20,17 @@ feature:
<div class="h-100 card shadow" href="#">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "./deploy-on-k8s/" >}}'>API-SERVER</a>
+ <a href='{{< relref "./deploy-on-k8s/" >}}'>传统虚拟机环境部署</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" href="#">
+ <div class="card-body">
+ <h4 class="card-title">
+ <a href='{{< relref "./deploy-on-k8s/" >}}'>Docker 环境部署</a>
</h4>
<p>以 API-SERVER 为注册中心，将 Dubbo 应用部署到 Kubernetes 并复用 Kubernetes
Native Service 的使用示例</p>
</div>
@@ -30,7 +40,7 @@ feature:
<div class="h-100 card shadow" href="#">
<div class="card-body">
<h4 class="card-title">
- <a href='{{< relref "../mesh/" >}}'>Dubbo Mesh</a>
+ <a href='{{< relref "../mesh/" >}}'>Kubernetes 部署</a>
</h4>
<p>通过 Dubbo Control Plane 屏蔽服务治理细节，保留适配 kubernetes
原生能力的同时从架构上实现数据面与 kubernetes 的解耦，避免数据面与 kubernetes 直接通信带来的各种问题。<br/><br/>具体请参见
Mesh解决方案 小节</p>
</div>
diff --git a/content/zh/overview/tasks/observability/_index.md
b/content/zh/overview/tasks/observability/_index.md
index cc4cf7e63e6..c3e959aae3d 100755
--- a/content/zh/overview/tasks/observability/_index.md
+++ b/content/zh/overview/tasks/observability/_index.md
@@ -1,9 +1,9 @@
---
type: docs
-title: "可观测性"
-linkTitle: "可观测性"
+title: "观测服务"
+linkTitle: "观测服务"
description: "演示如何将 Dubbo 部署到 Kubernetes 并复用 Kubernetes Native Service。"
-weight: 60
+weight: 50
no_list: true
---
\ No newline at end of file
diff --git a/content/zh/overview/tasks/protocols/_index.md
b/content/zh/overview/tasks/protocols/_index.md
index 25f467579bb..950f46ea5b3 100755
--- a/content/zh/overview/tasks/protocols/_index.md
+++ b/content/zh/overview/tasks/protocols/_index.md
@@ -4,7 +4,8 @@ type: docs
title: "通信协议"
linkTitle: "通信协议"
description: "演示 Dubbo 支持的通信协议"
-weight: 50
+weight: 40
+hide: true
no_list: true
---
diff --git a/content/zh/overview/tasks/traffic-management/_index.md
b/content/zh/overview/tasks/traffic-management/_index.md
index 0a466b6d266..df9ab19517f 100755
--- a/content/zh/overview/tasks/traffic-management/_index.md
+++ b/content/zh/overview/tasks/traffic-management/_index.md
@@ -4,7 +4,7 @@ type: docs
title: "流量管控"
linkTitle: "流量管控"
description: "演示 Dubbo 流量治理特性的使用方式。"
-weight: 30
+weight: 20
no_list: true
---
diff --git a/content/zh/overview/what/_index.md
b/content/zh/overview/what/_index.md
index 826ca72b802..9aad588e507 100644
--- a/content/zh/overview/what/_index.md
+++ b/content/zh/overview/what/_index.md
@@ -42,17 +42,17 @@ Dubbo 服务可以直接部署在容器、Kubernetes、Service Mesh等多种架
* **活跃的社区**
-Dubbo 项目托管在 Apache 社区，有来自国际、国内的活跃贡献者维护着超 10
个生态项目，贡献者来自阿里巴巴、工商银行、携程、蚂蚁、腾讯等知名企业技术专家，这确保 Dubbo 及时解决项目缺陷、需求及安全漏洞，跟进业界最新技术发展趋势。
+Dubbo 项目托管在 Apache 社区，有来自国际、国内的活跃贡献者维护着超 10
个生态项目，贡献者包括来自海外、阿里巴巴、工商银行、携程、蚂蚁、腾讯等知名企业技术专家，确保 Dubbo
及时解决项目缺陷、需求及安全漏洞，跟进业界最新技术发展趋势。
* **庞大的用户群体**
-Dubbo 的用户群体是其稳定性、需求来源、先进性的基础。
+Dubbo3 已在阿里巴巴成功取代 HSF 框架实现全面落地，成为阿里集团面向云原生时代的统一服务框架，庞大的用户群体是 Dubbo
保持稳定性、需求来源、先进性的基础。
## Dubbo 不是什么？
* **不是应用开发框架的替代者**
-Dubbo 设计为让开发者以主流的应用开发框架的开发模式工作，它不是各个语言应用开发框架的替代者，如它不是 Spring/Spring Boot
的竞争者，当你使用 Spring 时，它无缝的与 Spring & Spring Boot 集成在一起。
+Dubbo 设计为让开发者以主流的应用开发框架的开发模式工作，它不是各个语言应用开发框架的替代者，如它不是 Spring/Spring Boot
的竞争者，当你使用 Spring 时，Dubbo 可以无缝的与 Spring & Spring Boot 集成在一起。
* **不仅仅只是一款 RPC 框架**
@@ -60,7 +60,7 @@ Dubbo 提供了内置 RPC 通信协议实现，但它不仅仅是一款 RPC 框
* **不是 gRPC 协议的替代品**
-Dubbo 支持基于 gRPC 协议的底层通信，在 Dubbo 模式下使用 gRPC 可以带来更好的开发体验，更低的服务治理接入成本
+Dubbo 支持基于 gRPC 作为底层通信协议，在 Dubbo 模式下使用 gRPC 可以带来更好的开发体验，享有统一的编程模型和更低的服务治理接入成本
* **不只有 Java 语言实现**
diff --git a/content/zh/overview/what/advantages/_index.md
b/content/zh/overview/what/advantages/_index.md
index 3947e00342c..bcf04b8aa60 100644
--- a/content/zh/overview/what/advantages/_index.md
+++ b/content/zh/overview/what/advantages/_index.md
@@ -1,7 +1,7 @@
---
type: docs
-title: "核心特性"
-linkTitle: "核心特性"
+title: "核心优势"
+linkTitle: "核心优势"
weight: 30
description: ""
---
\ No newline at end of file
diff --git a/content/zh/overview/what/advantages/extensibility.md
b/content/zh/overview/what/advantages/extensibility.md
index 6e10b668d2a..15f17c9dd5e 100644
--- a/content/zh/overview/what/advantages/extensibility.md
+++ b/content/zh/overview/what/advantages/extensibility.md
@@ -5,12 +5,12 @@ linkTitle: "可扩展性"
weight: 60
---
-Dubbo 在设计上是高度可扩展的，通过这些扩展点你可以做到：
+Dubbo 从设计上是高度可扩展的，通过这些扩展点你可以做到：
* 拦截流量并控制流量行为
* 按需调优 Dubbo 的一些默认策略与实现
-* 将 Dubbo 服务适配到自己内部微服务集群或其他主流的开源组件
+* 将 Dubbo 服务适配到公司内部微服务集群或其他主流的开源组件
-## 扩展点定义
+## 一切皆可扩展
Dubbo 扩展能力使得 Dubbo 项目很方便的切分成一个一个的子模块，实现热插拔特性。用户完全可以基于自身需求，替换 Dubbo
原生实现，来满足自身业务需求。
@@ -18,22 +18,19 @@ Dubbo 扩展能力使得 Dubbo 项目很方便的切分成一个一个的子模
基于以上扩展点定义，可以实现如下功能的灵活拓展：通信协议、序列化编码协议、流量统计、集群容错策略、路由规则、负载均衡、注册中心、线程池策略、配置中心、分布式事务实现、全链路追踪、监控系统、熔断策略、限流降级等。
-## 部分官方扩展实现
-
-以下是官方或官方生态项目提供的一些默认实现，更多实现可以在 [apache/dubbo-spi-extensions]() 中了解。
-
-
+可参考这篇文档了解更多 [扩展点定义](../../../core-features/extensibility/)
## 扩展示例
-以下演示了如何扩展 Dubbo 来解决实际问题，可以跟随示例学习。
+以下示例演示了如何扩展 Dubbo 来解决实际问题，可以跟随示例学习。
* [自定义负载均衡策略]()
-* [自定义的注册中心]()
-* [拦截流量]()
+* [自定义注册中心]()
+* [自定义拦截器]()
-还有如下一些高级扩展示例：
+## 微服务生态
+通过扩展对接微服务生态的示例。
* [全链路追踪]()
* [数据一致性]()
-* [限流降级]()
\ No newline at end of file
+* [限流降级]()
diff --git a/content/zh/overview/what/advantages/traffic-management.md
b/content/zh/overview/what/advantages/traffic-management.md
index 38b40f949fe..3db8af1f583 100644
--- a/content/zh/overview/what/advantages/traffic-management.md
+++ b/content/zh/overview/what/advantages/traffic-management.md
@@ -9,25 +9,41 @@ Dubbo 丰富的流量管控规则可以控制服务间的流量走向和 API 调
## Dubbo 的流量管控体系
-Dubbo 提供了多种策略和实现，可以很好的管控流入、流出 Dubbo 集群的流量。从 Server 视角来看，部署 Dubbo
应用的实例是时刻在动态变化的，因此消费方 (Dubbo Consumer) 要能随时感知节点变化并将流量均匀的分布到每个实例上，Dubbo
的服务发现与负载均衡机制可以很好的解决这个问题；Dubbo
中有应用、服务和方法的概念，一个应用可以发布多个服务，一个服务包含多个可被调用的方法，从抽象的视角来看，一次 Dubbo
调用就是某个消费方应用发起了对某个提供方 (Dubbo Provider) 应用内的某个服务特定方法的调用，Dubbo
的流量管控规则可以基于应用、服务、方法、参数等粒度精准的控制流量走向。
+Dubbo 服务发现和负载均衡机制，保证。Dubbo 提供了多种策略和实现，可以很好的管控流入、流出 Dubbo 集群的流量。Dubbo
的流量管控规则可以基于应用、服务、方法、参数等粒度精准的控制流量走向。从流量管控的视角，Dubbo
的流量管控就是根据请求的目标服务、方法以及请求体中的其他附加参数进行匹配的，符合匹配太条件的流量会被按照特定规则转发到一个地址子集。
-Dubbo 服务发现保证调用方随时看到最新的提供方实例地址，服务发现机制依赖注册中心的协调，注册中心可以是 Zookeeper、Nacos
等独立集群，也可以是 Istio 等控制面组件。在消费端，Dubbo
提供了多种负载均衡策略，比如通过随机负载均衡策略能最大限度的做到流量在后端实例上的均匀分布，而一致性哈希负载均衡、基于权重的负载均衡等策略则能满足一些特定场景的流量调度需求。
+* 条件路由规则
+* 标签路由规则
+* 脚本路由规则
+* 动态配置规则
+* 云原生路由规则
-从流量管控的视角，一次请求的目标是服务和方法，Dubbo
的流量管控就是根据请求的目标服务、方法以及请求体中的其他附加参数进行匹配的，符合匹配太条件的流量会被按照特定规则转发到一个地址子集。匹配条件最细支持到方法粒度，同时还能根据参数值进行流量转发。如果是基于
http 的 rpc 协议 (如 REST、gRPC、Triple 等)，则服务和方法的就统一转换为 http 的路径 (path)，此时 Dubbo
的流量规则就是基于 http path 和 headers 的流量分发。
+具体规则定义请参见 [Dubbo 流量管控规则设计与定义](../../../core-features/traffic/)
## Dubbo 流量管控能解决哪些问题
+搭建多套独立的逻辑测试环境，搭建一套完全隔离的线上灰度环境用来部署新版本服务
-> 增加流量分布图、从示例里摘几个。
+
+
+金丝雀发布
+
+
+
+当应用部署在多个不同机房/区域的时候，优先调用同机房/区域的服务提供者，避免了跨区域带来的网络延时，从而减少了调用的响应时间。
+
+
以上介绍了几种 Dubbo
中支持的流量管控规则，我们可以依赖它们中的一种或多种，通过改变规则中的匹配条件，实现微服务场景中的多种服务治理能力，常见的包括以下一些：
-* 灰度流量隔离
+* 动态调整超时时间
+* 服务重试
+* 访问日志
+* 同区域优先
+* 灰度环境隔离
+* 参数路由
+* 按权重比例分流
* 金丝雀发布
-* A/B 测试
-* 黑白名单
* 服务降级
-* 修改服务行为，如重试、打开访问日志、限流参数等
-* 超时时间调整
* 实例临时拉黑
+* 指定机器导流
-可以在 [流量管理任务]() 中了解更多这部分的细节。
+可以在 [流量管理任务](../../../tasks/traffic-management/) 中了解以上实践场景细节。
diff --git a/content/zh/overview/what/overview.md
b/content/zh/overview/what/overview.md
index bab2917a30d..59a679e3285 100644
--- a/content/zh/overview/what/overview.md
+++ b/content/zh/overview/what/overview.md
@@ -1,87 +1,105 @@
---
type: docs
-title: "了解 Dubbo 的核心概念和架构"
+title: "了解 Dubbo 核心概念和架构"
linkTitle: "概念与架构"
weight: 10
description: ""
---
-
+
-以上是 Dubbo 的工作原理架构图，有三个核心的抽象角色：服务消费者 (Client/Consumer)、服务提供者
(Server/Provider)、服务治理中心。
-* **代表业务服务的消费者和提供者统称为 Dubbo 数据面**，组成数据面的业务服务之间依赖 Dubbo 实现数据传输，即某个服务 (消费者) 以
RPC 或 HTTP 形式发起调用，目标服务 (提供者) 收到并回复对方的请求，Dubbo 定义了微服务开发与调用规范并完成数据传输的编解码工作。
-* **服务治理中心控制并观测 Dubbo
数据面的流量**，比如作为注册中心协调服务组件间的地址自动发现、作为规则管控中心下发流量治理策略等。治理中心不是特指如注册中心类的单个具体组件，而是对
Dubbo 治理体系的抽象表达。
+以上是 Dubbo 的工作原理图，从抽象架构上分为两层：**服务治理抽象控制面** 和 **Dubbo 数据面** 。
+* **服务治理控制面**。服务治理控制面不是特指如注册中心类的单个具体组件，而是对 Dubbo
治理体系的抽象表达。控制面包含协调服务发现的注册中心、流量管控策略、Dubbo Admin 控制台等，如果采用了 Service Mesh 架构则还包含
Istio 等服务网格控制面。
+* **Dubbo 数据面**。数据面代表集群部署的所有 Dubbo 进程，进程之间通过 RPC 协议实现数据交换，Dubbo
定义了微服务应用开发与调用规范并负责完成数据传输的编解码工作。
+ * 服务消费者 (Dubbo Consumer)，发起业务调用或 RPC 通信的 Dubbo 进程
+ * 服务提供者 (Dubbo Provider)，接收业务调用或 RPC 通信的 Dubbo 进程
## Dubbo 数据面
-从数据面的视角，Dubbo 解决了微服务实践中的以下问题：
-* Dubbo 作为**服务开发框架**定义了微服务定义、开发与调用的规范
-* Dubbo 作为 **RPC 通信协议实现**解决服务间通信的编解码工作
+从数据面视角，Dubbo 帮助解决了微服务实践中的以下问题：
+* Dubbo 作为 **服务开发框架** 约束了微服务定义、开发与调用的规范，定义了服务治理流程及适配模式
+* Dubbo 作为 **RPC 通信协议实现** 解决服务间数据传输的编解码问题
-
+
### 服务开发框架
微服务的目标是构建足够小的、自包含的、独立演进的、可以随时部署运行的分布式应用程序，几乎每个语言都有类似的应用开发框架来帮助开发者快速构建此类微服务应用，比如
Java 微服务体系的 Spring Boot，它帮 Java 微服务开发者以最少的配置、最轻量的方式快速开发、打包、部署与运行应用。
-微服务的分布式特性，使得应用间的依赖、网络交互、数据传输变得更频繁，因此不同的**微服务应用需要定义、暴露或调用 RPC 服务，那么这些 RPC
服务如何定义、如何与应用开发框架结合、服务调用行为如何控制？这就是 Dubbo 服务开发框架的含义，Dubbo 在微服务应用开发框架之上抽象了一套 RPC
服务定义、暴露、调用与治理的编程范式**，比如 Dubbo Java 作为服务开发框架，当运行在 Spring 体系时就是构建在 Spring Boot
应用开发框架之上的微服务开发框架，并在此之上抽象了一套 RPC 服务定义、暴露、调用与治理的编程范式。
+微服务的分布式特性，使得应用间的依赖、网络交互、数据传输变得更频繁，因此不同的**应用需要定义、暴露或调用 RPC 服务，那么这些 RPC
服务如何定义、如何与应用开发框架结合、服务调用行为如何控制？这就是 Dubbo 服务开发框架的含义，Dubbo 在微服务应用开发框架之上抽象了一套 RPC
服务定义、暴露、调用与治理的编程范式**，比如 Dubbo Java 作为服务开发框架，当运行在 Spring 体系时就是构建在 Spring Boot
应用开发框架之上的微服务开发框架，并在此之上抽象了一套 RPC 服务定义、暴露、调用与治理的编程范式。
-Dubbo 作为服务开发框架包含的具体内容如下：
-* **RPC 服务定义**。IDL、多语言Java、Golang 等
-* **RPC 服务调用暴露与调用 API**。同步、异步、Reactive Streaming
-* **RPC 服务行为、治理相关配置**。超时、延迟注册、预热、治理中心等，xml yaml properties
+
-这些 Dubbo 服务的行为，你也何种形式发起调用，
+Dubbo 作为服务开发框架包含的具体内容如下：
+* **RPC 服务定义、开发范式**。比如 Dubbo 支持通过 IDL 定义服务，也支持编程语言特有的服务开发定义方式，如通过 Java
Interface 定义服务。
+* **RPC 服务发布与调用 API**。Dubbo 支持同步、异步、Reactive Streaming 等服务调用编程模式，还支持请求上下文
API、设置超时时间等。
+* **服务治理策略、流程与适配方式等**。作为服务框架数据面，Dubbo 定义了服务地址发现、负载均衡策略、基于规则的流量路由、Metrics
指标采集等服务治理抽象，并适配到特定的产品实现。
-快速体验如何用 Dubbo 开发微服务：
+如果你不知道如何开始微服务开发，选择如下 Dubbo 服务开发框架实现，就可以开始微服务项目开发之旅啦：
* [Java](../../..docs3-v2/java-sdk/)
* [Golang]()
* [Rust]()
* [Node]()
### 通信协议
-**Dubbo 从设计上不绑定任何一款特定通信协议，REST、gRPC、Json-rpc、Hessian2 等几乎所有主流的通信协议 Dubbo
框架都可以提供支持。** 这样的 Protocol
设计模式给构建微服务带来了最大的灵活性，开发者可以根据需要如性能、通用型等选择不同的通信协议，不再需要任何的代理来实现协议转换，甚至你还可以通过 Dubbo
实现不同协议间的迁移。
+**Dubbo 从设计上不绑定任何一款特定通信协议，HTTP/2、REST、gRPC、JsonRPC、Thrift、Hessian2
等几乎所有主流的通信协议，Dubbo 框架都可以提供支持。** 这样的 Protocol
设计模式给构建微服务带来了最大的灵活性，开发者可以根据需要如性能、通用型等选择不同的通信协议，不再需要任何的代理来实现协议转换，甚至你还可以通过 Dubbo
实现不同协议间的迁移。
+
+
-Dubbo Protocol 被设计支持扩展，您可以将内部私有协议适配到 Dubbo 框架上，进而将私有协议接入 Dubbo 体系，以享用 Dubbo
的开发体验与服务治理能力。比如 Dubbo3 的典型用户阿里巴巴，就是通过扩展支持 HSF 协议实现了内部 HSF 框架到 Dubbo3
框架的整体迁移。Dubbo 还支持多协议暴露，您可以在单个端口上暴露多个协议，Dubbo Server 能够自动识别并确保请求被正确处理，也可以将同一个
RPC 服务发布在不同的端口（协议），为不同技术栈的调用方服务。Dubbo 灵活的通信协议设计可满足各种微服务通信场景的组合。
+Dubbo Protocol 被设计支持扩展，您可以将内部私有协议适配到 Dubbo 框架上，进而将私有协议接入 Dubbo 体系，以享用 Dubbo
的开发体验与服务治理能力。比如 Dubbo3 的典型用户阿里巴巴，就是通过扩展支持 HSF 协议实现了内部 HSF 框架到 Dubbo3 框架的整体迁移。
-Dubbo 提供了两款**内置高性能 Dubbo2、Triple (兼容 gRPC) 协议实现**，以满足部分微服务用户对高性能通信的诉求。Dubbo2
协议是在 TCP 传输层协议之上设计的二进制通信协议，而 Triple 则是基于 HTTP/2 之上构建的支持流式模式的通信协议，并且 Triple 完全兼容
gRPC 但实现上做了更多的符合 Dubbo 框架特点的优化，两者最开始都设计和诞生于阿里巴巴内部的高性能通信业务场景。
+Dubbo 还支持多协议暴露，您可以在单个端口上暴露多个协议，Dubbo Server 能够自动识别并确保请求被正确处理，也可以将同一个 RPC
服务发布在不同的端口（协议），为不同技术栈的调用方服务。
+
+Dubbo 提供了两款内置高性能 Dubbo2、Triple (兼容 gRPC)
协议实现，以满足部分微服务用户对高性能通信的诉求，两者最开始都设计和诞生于阿里巴巴内部的高性能通信业务场景。
+* Dubbo2 协议是在 TCP 传输层协议之上设计的二进制通信协议
+* Triple 则是基于 HTTP/2 之上构建的支持流式模式的通信协议，并且 Triple 完全兼容 gRPC 但实现上做了更多的符合 Dubbo
框架特点的优化。
总的来说，Dubbo 对通信协议的支持具有以下特点：
* 不绑定通信协议
* 提供高性能通信协议实现
* 支持流式通信模型
-* 不绑定序列化协议，
+* 不绑定序列化协议
* 支持单个服务的多协议暴露
* 支持单端口多协议发布
-
-
+* 支持一个应用内多个服务使用不同通信协议
## Dubbo 服务治理
-只有服务开发框架还不够，要构建符合 12
要素的微服务应用，开发者还需要解决无状态服务节点动态变化、外部化配置、日志跟踪、可观测性、流量管理、高可用性等一系列问题。Dubbo
抽象了一套微服务治理模式并提供了一系列官方实现，用来帮助开发、运维简化微服务实践，更专注在微服务业务本身。
+服务开发框架解决了开发与通信的问题，但在微服务集群环境下，我们仍需要解决无状态服务节点动态变化、外部化配置、日志跟踪、可观测性、流量管理、高可用性、数据一致性等一系列问题，我们将这些问题统称为服务治理。
-Dubbo 提供的服务治理能力包括:
+Dubbo 抽象了一套微服务治理模式并发布了对应的官方实现，服务治理可帮助简化微服务开发与运维，让开发者更专注在微服务业务本身。
-* **服务发现**
+### 服务治理抽象
-服务地址注册与发现是构建微服务体系的关键，Dubbo 默认提供 Nacos、Zookeeper 等注册中心并支持自定义扩展；Dubbo3
应用级服务发现模型解决 Dubbo2 规模瓶颈问题的同时，实现了与 Kubernetes Native Service 及 Spring Cloud
等微服务体系的互通。
+以下展示了 Dubbo 核心的服务治理功能定义
-* **负载均衡**
+
+* **地址发现**
-* **动态配置**
+Dubbo 服务发现具备高性能、支持大规模集群、服务级元数据配置等优势，默认提供 Nacos、Zookeeper、Consul 等多种注册中心适配，与
Spring Cloud、Kubernetes Service 模型打通，支持自定义扩展。
+* **负载均衡**
+Dubbo 默认提供加权随机、加权轮询、最少活跃请求数优先、最短响应时间优先、一致性哈希和自适应负载等策略
* **流量路由**
-Dubbo
支持通过一系列流量规则控制服务与服务之间的流量分布与行为，基于这些规则可以实现基于权重流量分布、流量灰度验证、金丝雀发布、按请求参数的路由、超时、限流降级等能力。
+Dubbo
支持通过一系列流量规则控制服务调用的流量分布与行为，基于这些规则可以实现基于权重的比例流量分发、灰度验证、金丝雀发布、按请求参数的路由、同区域优先、超时配置、重试、限流降级等能力。
* **链路追踪**
-多维度的可观测指标（Metrics、Tracing、Access Logs）帮助了解服务运行状态，为持续定位、维护和优化服务提供依据，Admin
控制台帮助实现数据指标可视化展示
+全链路追踪
+
+* **可观测性**
+
+Dubbo 实例通过 Prometheus 等上报 QPS、RT、请求次数、成功率、异常次数等多维度的可观测指标帮助了解服务运行状态，通过接入
Grafana、Admin 控制台帮助实现数据指标可视化展示。
+
+Dubbo 服务治理生态还提供了对 API 网关、限流降级、数据一致性、认证鉴权等场景的支持。
+
+### Dubbo Admin
+Admin 控制台是 Dubbo
+
+### 服务网格
-* **服务网格**
-多种形态数据面支持，包括以 Thin SDK 模式与 Envoy 等一起部署或以 Proxyless 模式独立部署，所有模式均可以开源标准方式无缝接入
Istio、Consul 等服务治理体系。
-除此之外，Dubbo 生态体系还提供了对 API 网关、限流降级、数据一致性、认证鉴权等场景的支持。
diff --git a/content/zh/overview/what/overview.md.backup
b/content/zh/overview/what/overview.md.backup
deleted file mode 100644
index a58841559b7..00000000000
--- a/content/zh/overview/what/overview.md.backup
+++ /dev/null
@@ -1,112 +0,0 @@
----
-type: docs
-title: "了解 Dubbo 的核心概念和架构"
-linkTitle: "概念与架构"
-weight: 10
-description: ""
----
-
-## 基本架构
-
-
-以上是 Dubbo 的工作原理架构图，有三个核心的抽象角色：服务消费者 (Client/Consumer)、服务提供者
(Server/Provider)、服务治理中心。
-* **代表业务服务的消费者和提供者统称为 Dubbo 数据面**，组成数据面的业务服务之间依赖 Dubbo 实现数据传输，即某个服务 (消费者) 以
RPC 或 HTTP 形式发起调用，目标服务 (提供者) 收到并回复对方的请求，Dubbo 定义了微服务开发与调用规范并完成数据传输的编解码工作。
-* **服务治理中心控制 Dubbo
数据面的行为**，比如作为注册中心协调服务组件间的地址自动发现、作为规则管控中心下发流量治理策略等。治理中心不是指如注册中心类的单个具体组件，而是 对
Dubbo 治理体系的抽象表达。
-
-## Dubbo 数据面
-从数据面的视角，Dubbo 帮我们完成如下事项：
-* Dubbo 作为**服务开发框架**定义了微服务定义、开发与调用的规范
-* Dubbo 作为 **RPC 协议实现**解决服务间通信的编解码工作
-
-
-
-### 服务开发框架
-就好比 Java 体系的 Spring 定义了
-服务定义：IDL、Java、Golang 等
-调用方式：同步、异步、Reactive
-服务行为：超时、延迟注册、预热、治理中心等
-配置：xml yaml properties
-多语言：Java Spring、Golang xx
-
-### 通信协议
-不绑定通信协议
-流式通信模型
-不绑定序列化协议
-多协议暴露、同时支持单端口上的协议自动识别
-高性能实现：benchmark 图
-
-
-
-Dubbo 首先是一款 RPC 框架，它定义了自己的 RPC 通信协议与编程方式。如上图所示，用户在使用 Dubbo 时首先需要定义好 Dubbo
服务；其次，是在将 Dubbo 服务部署上线之后，依赖 Dubbo 的应用层通信协议实现数据交换，Dubbo
所传输的数据都要经过序列化，而这里的序列化协议是完全可扩展的。
-使用 Dubbo 的第一步就是定义 Dubbo 服务，服务在 Dubbo
中的定义就是完成业务功能的一组方法的集合，可以选择使用与某种语言绑定的方式定义，如在 Java 中 Dubbo 服务就是有一组方法的 Interface
接口，也可以使用语言中立的 Protobuf Buffers [IDL
定义服务](../../tasks/triple/idl/)。定义好服务之后，服务端（Provider）需要提供服务的具体实现，并将其声明为 Dubbo
服务，而站在服务消费方（Consumer）的视角，通过调用 Dubbo 框架提供的 API
可以获得一个服务代理（stub）对象，然后就可以像使用本地服务一样对服务方法发起调用了。
-在消费端对服务方法发起调用后，
-Dubbo
框架负责将请求发送到部署在远端机器上的服务提供方，提供方收到请求后会调用服务的实现类，之后将处理结果返回给消费端，这样就完成了一次完整的服务调用。如图中的
Request、Response 数据流程所示。
->需要注意的是，在 Dubbo 中，我们提到服务时，通常是指 RPC
粒度的、提供某个具体业务增删改功能的接口或方法，与一些微服务概念书籍中泛指的服务并不是一个概念。
-
-在分布式系统中，尤其是随着微服务架构的发展，应用的部署、发布、扩缩容变得极为频繁，作为 RPC 消费方，如何动态的发现服务提供方地址成为 RPC
通信的前置条件。Dubbo
提供了自动的地址发现机制，用于应对分布式场景下机器实例动态迁移的问题。如下图所示，通过引入注册中心来协调提供方与消费方的地址，提供者启动之后向注册中心注册自身地址，消费方通过拉取或订阅注册中心特定节点，动态的感知提供方地址列表的变化。
-
-跨进程或主机的服务通信是 Dubbo 的一项基本能力，Dubbo RPC
以预先定义好的协议编码方式将请求数据（Request）发送给后端服务，并接收服务端返回的计算结果（Response）。RPC
通信对用户来说是完全透明的，使用者无需关心请求是如何发出去的、发到了哪里，每次调用只需要拿到正确的调用结果就行。除了同步模式的
Request-Response 通信模型外，Dubbo3 还提供更丰富的通信模型选择：
-* 消费端异步请求(Client Side Asynchronous Request-Response)
-* 提供端异步执行（Server Side Asynchronous Request-Response）
-* 消费端请求流（Request Streaming）
-* 提供端响应流（Response Streaming）
-* 双向流式通信（Bidirectional Streaming）
-
-## 服务治理
-
-服务发现
-负载均衡
-动态配置
-流量路由
-链路追踪
-服务网格
-
-#### 自动服务（地址）发现
-Dubbo 的服务发现机制，让微服务组件之间可以独立演进并任意部署，消费端可以在无需感知对端部署位置与 IP 地址的情况下完成通信。Dubbo 提供的是
Client-Based 的服务发现机制，使用者可以有多种方式启用服务发现：
-* 使用独立的注册中心组件，如 Nacos、Zookeeper、Consul、Etcd 等。
-* 将服务的组织与注册交给底层容器平台，如 Kubernetes，这被理解是一种更云原生的使用方式
-
-#### 运行态流量管控
-透明地址发现让 Dubbo 请求可以被发送到任意 IP 实例上，这个过程中流量被随机分配。当需要对流量进行更丰富、更细粒度的管控时，就可以用到 Dubbo
的流量管控策略，Dubbo
提供了包括负载均衡、流量路由、请求超时、流量降级、重试等策略，基于这些基础能力可以轻松的实现更多场景化的路由方案，包括金丝雀发布、A/B测试、权重路由、同区域优先等，更酷的是，Dubbo
支持流控策略在运行态动态生效，无需重新部署。具体可参见：
-* [流量治理示例](../../tasks/traffic-management)
-
-#### 丰富的扩展组件及生态
-Dubbo 强大的服务治理能力不仅体现在核心框架上，还包括其优秀的扩展能力以及周边配套设施的支持。通过 Filter、Router、Protocol
等几乎存在于每一个关键流程上的扩展点定义，我们可以丰富 Dubbo 的功能或实现与其他微服务配套系统的对接，包括 Transaction、Tracing
目前都有通过 SPI 扩展的实现方案，具体可以参见 Dubbo 扩展性的详情，也可以在
[apache/dubbo-spi-extensions](https://github.com/apache/dubbo-spi-extensions)
项目中发现与更多的扩展实现。具体可参见：
-* [Dubbo 生态](../../what/ecosystem)
-* [Dubbo 可扩展性设计](../../what/extensibility)
-
-#### 面向云原生设计
-
-Dubbo 从设计上是完全遵循云原生微服务开发理念的，这体现在多个方面，首先是对云原生基础设施与部署架构的支持，包括 容器、Kubernetes
等，Dubbo Mesh 总体解决方案也在 3.1 版本正式发布；另一方面，Dubbo 众多核心组件都已面向云原生升级，包括 Triple
协议、统一路由规则、对多语言的支持。
-
-值得一提的是，如何使用 Dubbo 支持弹性伸缩的服务如 Serverless 也在未来计划之中，这包括利用 Native Image 提高 Dubbo
的启动速度与资源消耗等。
-
-结合当前版本，本节主要从以下两点展开 Dubbo 的云原生特性
-* [容器调度平台（Kubernetes）](../../tasks/kubernetes/deploy-on-k8s)
-* [Dubbo Mesh](/zh/docs3-v2/java-sdk/concepts-and-architecture/mesh/)
-
-##### Kubernetes
-Dubbo 微服务要支持 Kubernetes 平台调度，最基础的就是实现 dubbo 服务生命周期与容器生命周期的对齐，这包括 Dubbo
的启动、销毁、服务注册等生命周期事件。相比于以往 Dubbo 自行定义生命周期事件，并要求开发人员在运维实践过程中遵守约定，Kubernetes
底层基础设施定义了严格的组件生命周期事件(probe)，转而要求 Dubbo 去按约定适配。
-
-Kubernetes Service
是另一个层面的适配，这体现了服务定义与注册向云原生底层基础设施下沉的趋势。在这种模式下，用户不再需要搭建额外的注册中心组件，Dubbo 消费端节点能自动对接到
Kubernetes（API-Server 或 DNS），根据服务名（Kubernetes Service Name） 查询到实例列表（Kubernetes
endpoints）。 此时服务是通过标准的 Kubernetes Service API 定义，并被调度到各个节点。
-
-##### Dubbo Mesh
-
-Service Mesh
在业界得到了广泛的传播与认可，并被认为是下一代的微服务架构，这主要是因为它解决了很多棘手的问题，包括透明升级、多语言、依赖冲突、流量治理等。Service
Mesh 的典型架构是通过部署独立的 Sidecar 组件来拦截所有的出口与入口流量，并在 Sidecar
中集成丰富的流量治理策略如负载均衡、路由等，除此之外，Service Mesh 还需要一个控制面（Control Panel）来实现对 Sidecar
流量的管控，即各种策略下发。我们在这里称这种架构为经典 Mesh。
-
-然而任何技术架构都不是完美的，经典 Mesh 在实施层面也面临成本过高的问题
-1. 需要运维控制面（Control Panel）
-2. 需要运维 Sidecar
-3. 需要考虑如何从原有 SDK 迁移到 Sidecar
-4. 需要考虑引入 Sidecar 后整个链路的性能损耗
-
-为了解决 Sidecar 引入的相关成本问题，Dubbo 引入并实现了全新的 Proxyless Mesh 架构，顾名思义，Proxyless Mesh
就是指没有 Sidecar 的部署，转而由 Dubbo SDK 直接与控制面交互，其架构图如下
-
-
-
-可以设想，在不同的组织、不同的发展阶段，未来以 Dubbo 构建的微服务将会允许有三种部署架构：传统 SDK、基于 Sidecar 的 Service
Mesh、脱离 Sidecar 的 Proxyless Mesh。基于 Sidecar 的 Service Mesh，即经典的 Mesh 架构，独立的
sidecar 运行时接管所有的流量，脱离 Sidecar 的 Proxyless Mesh，副 SDK 直接通过 xDS 与控制面通信。Dubbo
微服务允许部署在物理机、容器、Kubernetes 平台之上，能做到以 Admin 为控制面，以统一的流量治理规则进行治理。
-
-
-
-
-
diff --git a/content/zh/overview/what/xyz-difference.md
b/content/zh/overview/what/xyz-difference.md
index 50634e8579f..bb40a76b714 100644
--- a/content/zh/overview/what/xyz-difference.md
+++ b/content/zh/overview/what/xyz-difference.md
@@ -6,13 +6,13 @@ weight: 20
description: ""
---
-很多开发者经常会问到 Apache Dubbo 与 Spring Cloud、gRPC 以及一些 Service Mesh 项目如 Istio
的关系，要解释清楚它们的关系并不困难，你只需要跟随这篇文章和 Dubbo 文档做一些更深入的了解，但总的来说，它们有些能力与 Dubbo
是重合的，但在一些场景你可以把它们放在一起使用。
+很多开发者经常会问到 Apache Dubbo 与 Spring Cloud、gRPC 以及一些 Service Mesh 项目如 Istio
的关系，要解释清楚它们的关系并不困难，你只需要跟随这篇文章和 Dubbo
文档做一些更深入的了解，但总的来说，它们之间有些能力是重合的，但在一些场景你可以把它们放在一起使用。
虽然这是一篇 Dubbo 维护者写的文档，我们仍会尽力将 Dubbo
与其他组件之间的联系与差异客观、透明的展现出来，但考虑到每个人对不同产品的熟悉程度不一，这里的个别表述可能并不完全准确，希望能给开发者带来帮助。
## Dubbo 与 Spring Cloud
-
+
从上图我们可以看出，Dubbo 和 Spring Cloud 有很多相似之处，它们都在整个架构图的相同位置并提供一些相似的功能。
@@ -53,6 +53,8 @@ Dubbo 与 gRPC 最大的差异在于两者的定位上：
Dubbo 不绑定特定的通信协议，即 Dubbo 服务间可通过多种 RPC 协议通信并支持灵活切换。因此，你可以在 Dubbo 开发的微服务中选用 gRPC
通信，**Dubbo 完全兼容 gRPC，并将 gRPC 设计为内置原生支持的协议之一**。
+
+
如果您看中基于 HTTP/2 的通信协议、基于 Protobuf 的服务定义，并基于此决定选型 gRPC
作为微服务开发框架，那很有可能您会在未来的微服务业务开发中遇到障碍，这主要源于 gRPC 没有为开发者提供以下能力：
* 缺乏与业务应用框架集成的开发模式，用户需要基于 gRPC 底层的 RPC API 定义、发布或调用微服务，中间可能还有与业务应用开发框架整合的问题
* 缺乏微服务周边生态扩展与适配，如服务发现、限流降级、链路追踪等没有多少可供选择的官方实现，且扩展起来非常困难
@@ -69,7 +71,7 @@ Service Mesh 是近年来在云原生背景下诞生的一种微服务架构，
**Dubbo 已经实现了对 Istio 体系的全面接入，可以用 Istio 控制面治理 Dubbo 服务，而在数据面部署架构上，针对 Sidecar
引入的复杂性与性能问题，Dubbo 还支持无代理的 Proxyless 模式。** 除此之外，Dubbo Mesh 体系还解决了 Istio
架构落地过程中的很多问题，包括提供更灵活的数据面部署架构、更低的迁移成本等。
-
+
从**数据面**的视角，Dubbo 支持如下两种开发和部署模式，可以通过 Istio、Consul、Linkerd 等控制面组件实现对数据面服务的治理。
* 以 Dubbo ThinSDK 的模式与 Envoy 一起部署，此时，Dubbo 作为微服务编程框架 & 协议通信组件而存在，与 Istio
控制面的交互由 Envoy 实现
diff --git a/static/imgs/blog/2023/01/protocols/img.png
b/static/imgs/blog/2023/01/protocols/img.png
new file mode 100644
index 00000000000..bdcc52186b8
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_1.png
b/static/imgs/blog/2023/01/protocols/img_1.png
new file mode 100644
index 00000000000..e81a33fcf8d
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_1.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_10.png
b/static/imgs/blog/2023/01/protocols/img_10.png
new file mode 100644
index 00000000000..058fedc1d10
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_10.png
differ
diff --git a/static/imgs/blog/2023/01/protocols/img_2.png
b/static/imgs/blog/2023/01/protocols/img_2.png
new file mode 100644
index 00000000000..8fb50486bfc
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_2.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_3.png
b/static/imgs/blog/2023/01/protocols/img_3.png
new file mode 100644
index 00000000000..8436d6b38fd
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_3.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_4.png
b/static/imgs/blog/2023/01/protocols/img_4.png
new file mode 100644
index 00000000000..ad6f950c923
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_4.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_5.png
b/static/imgs/blog/2023/01/protocols/img_5.png
new file mode 100644
index 00000000000..e8c3800cc0d
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_5.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_6.png
b/static/imgs/blog/2023/01/protocols/img_6.png
new file mode 100644
index 00000000000..c179b127e26
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_6.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_7.png
b/static/imgs/blog/2023/01/protocols/img_7.png
new file mode 100644
index 00000000000..5f3b0232eb3
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_7.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_8.png
b/static/imgs/blog/2023/01/protocols/img_8.png
new file mode 100644
index 00000000000..bbefdbe0171
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_8.png differ
diff --git a/static/imgs/blog/2023/01/protocols/img_9.png
b/static/imgs/blog/2023/01/protocols/img_9.png
new file mode 100644
index 00000000000..293b19de8bc
Binary files /dev/null and b/static/imgs/blog/2023/01/protocols/img_9.png differ
diff --git a/static/imgs/v3/concepts/architecture-2.png
b/static/imgs/v3/concepts/architecture-2.png
new file mode 100644
index 00000000000..5745b2cde7e
Binary files /dev/null and b/static/imgs/v3/concepts/architecture-2.png differ
diff --git a/static/imgs/v3/difference/dubbo-grpc.png
b/static/imgs/v3/difference/dubbo-grpc.png
new file mode 100644
index 00000000000..981a3e91a7e
Binary files /dev/null and b/static/imgs/v3/difference/dubbo-grpc.png differ
diff --git a/static/imgs/v3/difference/dubbo-springcloud.png
b/static/imgs/v3/difference/dubbo-springcloud.png
new file mode 100644
index 00000000000..b3542feb90a
Binary files /dev/null and b/static/imgs/v3/difference/dubbo-springcloud.png
differ
diff --git a/static/imgs/v3/difference/img.png
b/static/imgs/v3/difference/img.png
new file mode 100644
index 00000000000..9a9b0bca67d
Binary files /dev/null and b/static/imgs/v3/difference/img.png differ
diff --git a/static/imgs/v3/feature/ecosystem/ecosystem.png
b/static/imgs/v3/feature/ecosystem/ecosystem.png
new file mode 100644
index 00000000000..385dd1c9977
Binary files /dev/null and b/static/imgs/v3/feature/ecosystem/ecosystem.png
differ
diff --git a/static/imgs/v3/feature/extensibility/filter.png
b/static/imgs/v3/feature/extensibility/filter.png
new file mode 100644
index 00000000000..9ad4fccf8c2
Binary files /dev/null and b/static/imgs/v3/feature/extensibility/filter.png
differ
diff --git a/static/imgs/v3/feature/protocols/protocols1.png
b/static/imgs/v3/feature/protocols/protocols1.png
new file mode 100644
index 00000000000..f77563fd378
Binary files /dev/null and b/static/imgs/v3/feature/protocols/protocols1.png
differ
diff --git a/static/imgs/v3/feature/security/arch.png
b/static/imgs/v3/feature/security/arch.png
new file mode 100644
index 00000000000..3df2ca15af2
Binary files /dev/null and b/static/imgs/v3/feature/security/arch.png differ
diff --git a/static/imgs/v3/feature/security/auth-1.png
b/static/imgs/v3/feature/security/auth-1.png
new file mode 100644
index 00000000000..3f77bdc77a1
Binary files /dev/null and b/static/imgs/v3/feature/security/auth-1.png differ
diff --git a/static/imgs/v3/feature/security/authz-1.png
b/static/imgs/v3/feature/security/authz-1.png
new file mode 100644
index 00000000000..fc089f33f3b
Binary files /dev/null and b/static/imgs/v3/feature/security/authz-1.png differ
diff --git a/static/imgs/v3/feature/security/authz-2.png
b/static/imgs/v3/feature/security/authz-2.png
new file mode 100644
index 00000000000..4e5079ed338
Binary files /dev/null and b/static/imgs/v3/feature/security/authz-2.png differ
diff --git a/static/imgs/v3/feature/service-discovery/arc.png
b/static/imgs/v3/feature/service-discovery/arc.png
new file mode 100644
index 00000000000..55c26f497c5
Binary files /dev/null and b/static/imgs/v3/feature/service-discovery/arc.png
differ
diff --git a/static/imgs/v3/feature/service-discovery/arc2.png
b/static/imgs/v3/feature/service-discovery/arc2.png
new file mode 100644
index 00000000000..458fe4ea70f
Binary files /dev/null and b/static/imgs/v3/feature/service-discovery/arc2.png
differ
diff --git a/static/imgs/v3/feature/service-discovery/metadata.png
b/static/imgs/v3/feature/service-discovery/metadata.png
new file mode 100644
index 00000000000..9622611163e
Binary files /dev/null and
b/static/imgs/v3/feature/service-discovery/metadata.png differ
diff --git a/static/imgs/v3/feature/service-discovery/registry-data.png
b/static/imgs/v3/feature/service-discovery/registry-data.png
new file mode 100644
index 00000000000..6cd05d8be79
Binary files /dev/null and
b/static/imgs/v3/feature/service-discovery/registry-data.png differ
diff --git a/static/imgs/v3/feature/service-discovery/subscription1.png
b/static/imgs/v3/feature/service-discovery/subscription1.png
new file mode 100644
index 00000000000..18bd5ddbc11
Binary files /dev/null and
b/static/imgs/v3/feature/service-discovery/subscription1.png differ
diff --git a/static/imgs/v3/feature/service-discovery/subscription2.png
b/static/imgs/v3/feature/service-discovery/subscription2.png
new file mode 100644
index 00000000000..e36a51676c8
Binary files /dev/null and
b/static/imgs/v3/feature/service-discovery/subscription2.png differ
diff --git a/static/imgs/v3/what/framework1.png
b/static/imgs/v3/what/framework1.png
new file mode 100644
index 00000000000..5ad447fd1d0
Binary files /dev/null and b/static/imgs/v3/what/framework1.png differ
diff --git a/static/imgs/v3/what/framework2.png
b/static/imgs/v3/what/framework2.png
new file mode 100644
index 00000000000..9cf485f1bb7
Binary files /dev/null and b/static/imgs/v3/what/framework2.png differ
diff --git a/static/imgs/v3/what/governance.png
b/static/imgs/v3/what/governance.png
new file mode 100644
index 00000000000..bd4596deecc
Binary files /dev/null and b/static/imgs/v3/what/governance.png differ
diff --git a/static/imgs/v3/what/protocol.png b/static/imgs/v3/what/protocol.png
new file mode 100644
index 00000000000..8e50a17e44d
Binary files /dev/null and b/static/imgs/v3/what/protocol.png differ
