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 f2280dc3a55 update docs
f2280dc3a55 is described below
commit f2280dc3a55b426b0422eaee0fe3b4b8e485ec0a
Author: chickenlj <[email protected]>
AuthorDate: Mon Nov 21 18:01:49 2022 +0800
update docs
---
content/zh/overview/core-features/configuration.md | 119 +++++++++++++++++-
content/zh/overview/core-features/ecosystem.md | 57 ++++++++-
content/zh/overview/what/advantages/_index.md | 2 +-
.../zh/overview/what/advantages/observability.md | 10 +-
content/zh/overview/what/advantages/performance.md | 81 +------------
.../overview/what/advantages/traffic-management.md | 54 ---------
content/zh/overview/what/advantages/usability.md | 134 +++------------------
content/zh/overview/what/observability.md | 6 -
content/zh/overview/what/overview.md | 87 ++-----------
.../what/{overview.md => overview.md.backup} | 2 +-
content/zh/overview/what/xyz-difference.md | 50 +++++---
11 files changed, 254 insertions(+), 348 deletions(-)
diff --git a/content/zh/overview/core-features/configuration.md
b/content/zh/overview/core-features/configuration.md
index 383c132d91b..1183363d34f 100644
--- a/content/zh/overview/core-features/configuration.md
+++ b/content/zh/overview/core-features/configuration.md
@@ -8,4 +8,121 @@ feature:
title: 配置管理
description: >
配置管理
----
\ No newline at end of file
+---
+
+## RPC 通信
+Dubbo3 的 Triple 协议构建在 HTTP/2 协议之上，因此具有更好的穿透性与通用性，Triple 协议兼容 gRPC，提供 Request
Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通信模型；从
Triple 协议开始，Dubbo 还支持基于 IDL 的服务定义。
+
+此外，Dubbo 还集成了业界主流的大部分协议，使得用户可以在 Dubbo
框架范围内使用这些通信协议，为用户提供了统一的编程模型与服务治理模型，这些协议包括 rest、hessian2、jsonrpc、thrift 等，注意不同语言
SDK 实现支持的范围会有一些差异。
+
+具体可查看
+* [Triple 速览](/zh/docs3-v2/java-sdk/concepts-and-architecture/triple/)
+*
[Specification](https://github.com/apache/dubbo-awesome/blob/master/proposals/D0-triple.md)
+
+## 服务发现
+服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP
地址的情况下实现通信。
+
+实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based
的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的
[Nacos](https://nacos.io/)、Consul、Zookeeper 等，Dubbo 自身也提供了对多种注册中心组件的对接，用户可以灵活选择。
+
+Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：
+
+
+
+在传统的部署架构下，服务发现涉及提供者、消费者和注册中心三个参与角色，其中，提供者注册 URL
地址到注册中心，注册中心负责对数据进行聚合，消费者从注册中心订阅 URL 地址更新。
+在云原生背景下，比如当应用部署在 Kubernetes
等平台，由于平台自身维护了应用/服务与实例间的映射关系，因此注册中心与注册动作在一定程度上被下沉到了基础设施层，因此框架自身的注册动作有时并不是必须的。
+
+Dubbo3 提供了全新的应用级服务发现模型，该模型在设计与实现上区别于 Dubbo2 的接口级服务发现模型。可在此查看：
+*
[应用级服务发现](/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/#应用级服务发现简介)
+
+## 流量治理
+Dubbo2 开始 Dubbo 就提供了丰富服务治理规则，包括路由规则、动态配置等。
+
+一方面 Dubbo3 正在通过对接 xDS 对接到时下流行的 Mesh 产品如 Istio 中所使用的以
VirtualService、DestinationRule 为代表的治理规则，另一方面 Dubbo
正寻求设计一套自有规则以实现在不同部署场景下的流量治理，以及灵活的治理能力。
+
+* [Dubbo2 服务治理规则](../../tasks/traffic-management)
+* Dubbo3 服务治理规则
+
+## Dubbo Mesh
+Dubbo Mesh 的目标是提供适应 Dubbo 体系的完整 Mesh 解决方案，包含定制化控制面（Control
Plane）、定制化数据面解决方案。Dubbo 控制面基于业界主流 Istio 扩展，支持更丰富的流量治理规则、Dubbo应用级服务发现模型等，Dubbo
数据面可以采用 Envoy Sidecar，即实现 Dubbo SDK + Envoy 的部署方案，也可以采用 Dubbo Proxyless 模式，直接实现
Dubbo 与控制面的通信。Dubbo Mesh 在快速演进中，我们将努力保持文档内容的更新。
+
+
+
+在此查看 Dubbo Mesh 设计细节
+* [Dubbo Proxy
Mesh](https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.1-thinsdk-sidecar-mesh.md)
+* [Dubbo Proxyless
Mesh](https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.2-proxyless-mesh.md)
+* [Dubbo
控制面规划](https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.2-proxyless-mesh.md)
+
+## 部署架构
+> 本节侧重描述传统模式下的 Dubbo 部署架构，在云原生背景下的部署架构会有些变化，主要体现在基础设施（Kubernetes、Service
Mesh等）会承担更多的职责，
+> 中心化组件如注册中心、元数据中心、配置中心等的职责被集成、运维变得更加简单，但通过强调这些中心化的组件能让我们更容易理解 Dubbo 的工作原理。
+
+作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作，
+Dubbo 定义了一些中心化组件，这包括：
+* 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
+* 配置中心。
+ * 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
+ * 负责服务治理规则（路由规则、动态配置等）的存储与推送。
+* 元数据中心。
+ * 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
+ * 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
+
+
+
+上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。
+
+以上三个中心并不是运行 Dubbo
的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心
+以开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
+
+### 注册中心
+
+注册中心扮演着非常重要的角色，它承载着服务注册和服务发现的职责。目前Dubbo支持以下两种粒度的服务发现和服务注册，分别是接口级别和应用级别，注册中心可以按需进行部署：
+
+- 在传统的Dubbo SDK使用姿势中，如果仅仅提供直连模式的RPC服务，不需要部署注册中心。
+- 无论是接口级别还是应用级别，如果需要Dubbo SDK自身来做服务注册和服务发现，则可以选择部署注册中心，在Dubbo中集成对应的注册中心。
+
+- 在Dubbo + Mesh 的场景下，随着 Dubbo
服务注册能力的弱化，Dubbo内的注册中心也不再是必选项，其职责开始被控制面取代，如果采用了Dubbo +
Mesh的部署方式，无论是ThinSDK的mesh方式还是Proxyless的mesh方式，都不再需要独立部署注册中心。
+
+而注册中心并不依赖于配置中心和元数据中心，如下图所示：
+
+
+
+该图中没有部署配置中心和元数据中心，在Dubbo中会默认将注册中心的实例同时作为配置中心和元数据中心，这是Dubbo的默认行为，如果确实不需要配置中心或者元数据中心的能力，可在配置中关闭，在注册中心的配置中有两个配置分别为use-as-config-center和use-as-metadata-center，将配置置为false即可。
+
+### 元数据中心
+
+元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：
+
+1. 对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3
会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用“应用 ——
实例列表”结构的数据组织形式，不再是以往的“接口 ——
实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。
+2.
为了让注册中心更加聚焦于地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。
+
+如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。
+
+元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：
+
+
+
+该图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了Dubbo
mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
+
+### 配置中心
+
+配置中心与其他两大中心不同，它无关于接口级还是应用级，它与接口并没有对应关系，它仅仅与配置数据有关，即使没有部署注册中心和元数据中心，配置中心也能直接被接入到Dubbo应用服务中。在整个部署架构中，整个集群内的实例（无论是Provider还是Consumer）都将会共享该配置中心集群中的配置，如下图所示：
+
+
+该图中不配备注册中心，意味着可能采用了Dubbo mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
+
+该图中不配备元数据中心，意味着Consumer可以从Provider暴露的MetadataService获取服务元数据，从而实现RPC调用
+
+### 保证三大中心高可用的部署架构
+
+虽然三大中心已不再是Dubbo应用服务所必须的，但是在真实的生产环境中，一旦已经集成并且部署了该三大中心，三大中心还是会面临可用性问题，Dubbo需要支持三大中心的高可用方案。在Dubbo中就支持多注册中心、多元数据中心、多配置中心，来满足同城多活、两地三中心、异地多活等部署架构模式的需求。
+
+Dubbo SDK对三大中心都支持了Multiple模式。
+
+- 多注册中心：Dubbo
支持多注册中心，即一个接口或者一个应用可以被注册到多个注册中心中，比如可以注册到ZK集群和Nacos集群中，Consumer也能够从多个注册中心中进行订阅相关服务的地址信息，从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群，保证能够正常提供服务以及发起服务调用。这也能够满足注册中心在部署上适应各类高可用的部署架构模式。
+-
多配置中心：Dubbo支持多配置中心，来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。
+
+- 多元数据中心：Dubbo
支持多元数据中心：用于应对容灾等情况导致某个元数据中心集群不可用，此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供有关服务元数据的管理能力。
+
+拿注册中心举例，下面是一个多活场景的部署架构示意图：
+
+
diff --git a/content/zh/overview/core-features/ecosystem.md
b/content/zh/overview/core-features/ecosystem.md
index 9e859d4afd0..e7e9730943f 100644
--- a/content/zh/overview/core-features/ecosystem.md
+++ b/content/zh/overview/core-features/ecosystem.md
@@ -8,4 +8,59 @@ feature:
title: 丰富生态
description: >
在以下微服务领域提供了众多官方生态适配，包括注册中心、配置中心、网关、限流降级、负载均衡、一致性事务、异步消息、Tracing、可观测等。
----
\ No newline at end of file
+---
+
+
+### Dashboard
+* [Dubbo-admin](https://github.com/apache/dubbo-admin)
+
+### 支持的组件与部署架构
+
+Dubbo 实现普遍支持以下产品或部署架构，具体多语言 SDK 实现可能有差异。
+
+* 注册中心
+ * 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
diff --git a/content/zh/overview/what/advantages/_index.md
b/content/zh/overview/what/advantages/_index.md
index 914d72612dd..3947e00342c 100644
--- a/content/zh/overview/what/advantages/_index.md
+++ b/content/zh/overview/what/advantages/_index.md
@@ -2,6 +2,6 @@
type: docs
title: "核心特性"
linkTitle: "核心特性"
-weight: 20
+weight: 30
description: ""
---
\ No newline at end of file
diff --git a/content/zh/overview/what/advantages/observability.md
b/content/zh/overview/what/advantages/observability.md
index b7318cf4151..5d400a66f40 100644
--- a/content/zh/overview/what/advantages/observability.md
+++ b/content/zh/overview/what/advantages/observability.md
@@ -3,4 +3,12 @@ type: docs
title: "可观测性"
linkTitle: "可观测性"
weight: 50
----
\ No newline at end of file
+---
+
+可观测性分为三个维度度量、链路追踪以及日志，Dubbo从这三个方面为开发者提供了全面的可观测性解决方案。
+
+Metrics：Dubbo集成了prometheus监控系统，在指标数据上Dubbo支持多维度的RT指标数据，包括Max、Min、Avg、P99、P95等维度，支持多维度的请求量指标数据，包括QPS、调用成功的请求量、调用失败的请求量等。除此之外，Dubbo还能够通过SPI扩展来完成集成其他监控系统。
+
+Tracing：Dubbo提供了链路追踪所需的必备数据，为Dubbo集成各类链路追踪系统提供了便捷，以辅助用户完成更加强大的链路追踪能力。目前流行的skywalking、zipkin、jaeger都支持Dubbo服务的链路追踪。
+
+Logging：Dubbo支持多种的日志框架的适配。包括常见的slf4j、log4j2、log4j、jcl等。用户可以在这些框架中自由切换。
\ No newline at end of file
diff --git a/content/zh/overview/what/advantages/performance.md
b/content/zh/overview/what/advantages/performance.md
index c5c122190f6..26744ebbfac 100644
--- a/content/zh/overview/what/advantages/performance.md
+++ b/content/zh/overview/what/advantages/performance.md
@@ -6,80 +6,11 @@ linkTitle: "高性能"
weight: 30
---
-本文将带你快速了解 Dubbo3 的设计背景、总体架构与核心特性、与典型用户如阿里巴巴 HSF2 的关系等。也可以通过如下部分了解更多：
-* **小白用户，快速浏览 Dubbo3 核心特性：**
- * [下一代通信协议 - Triple](/zh/docs3-v2/java-sdk/concepts-and-architecture/triple/)
- * [百万实例集群的秘密 -
应用级服务发现](/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/)
- * [Dubbo Mesh](/zh/docs3-v2/java-sdk/concepts-and-architecture/mesh/)
-* **Dubbo3 的兼容性与迁移成本?**
- * [Java - 迁移指南](/zh/docs3-v2/java-sdk/upgrades-and-compatibility)
- * [Golang - 迁移指南](/zh/docs3-v2/golang-sdk/)
-* **Dubbo3 相关资源：**
- * 更多资料，如性能指标、高级特性说明等请参考 [多语言 SDK 实现](/zh/overview/mannual/)
- * 演讲与线下活动
+Triple 是基于 HTTP/2 开发的新一代 RPC 协议，在网关穿透性和通用性以及 Stream 通信模型都具备优势。
-### 背景
+Streaming 通信：基于 Triple 协议进行 Stream 流模式。
+响应式编程：基于 Triple 协议流式调用。
+流式通信：基于 Triple 协议进行流式通信。
+应用级服务发现是基于应用粒度的服务发现机制，适配云原生微服务变革。在大规模集群展现极致性能以及大幅降低系统资源的利用率。
-Dubbo3 的设计与开发有两个大的背景。
-
-**首先，如何更好的满足企业实践诉求。** Dubbo 自 2011
由阿里巴巴捐献开源以来，一直是众多大型企业微服务实践的首选开源服务框架。在此期间，企业架构经历了从 SOA 架构到微服务架构变迁，Dubbo
社区自身也在不断的更新迭代以更好的满足企业诉求。然而 Dubbo2 架构上的局限逐渐在实践中凸显：
-- **协议**，Dubbo2 协议以性能、简洁著称，但却在云原生时代遇到越来越多的通用性、穿透性问题；
-- **可伸缩性**，Dubbo2 在可伸缩性上依旧远超很多其他框架，但随着微服务带来更多应用与实例我们不得不思考如何应对更大规模集群的实战；
-- **服务治理易用性**，如更丰富的流量治理、可观测性、智能负载均衡等。
-
-**其次，适配云原生技术栈的发展。**
微服务让业务开发演进更灵活、快捷的同时，也带来了一些它独有的特征和需求：如微服务之后组件数量越来越多，如何解决各个组件的稳定性，如何快速的水平扩容等，以
Docker、Kubernetes、Service Mesh 为代表的云原生基础设施为解决这些问题带来了一些新的选择。随着更多的微服务组件及能力正下沉到以
Kubernetes
为代表的基础设施层，传统微服务开发框架应剔除一些冗余机制，积极的适配到基础设施层以做到能力复用，微服务框架生命周期、服务治理等能力应更好地与
Kubernetes 服务编排机制融合； 以 Service Mesh 为代表微服务架构给微服务开发带来的新的选择，Sidecar
给多语言、透明升级、流量管控等带来的优势，但同时也带来运维复杂性、性能损耗等弊端，因此基于服务框架的传统微服务体系还将是主流，长
期仍将占据半壁江山，在长时间内将会维持混合部署状态。
-
-### 总体目标
-Dubbo3 依旧保持了 2.x
的经典架构，以解决微服务进程间通信为主要职责，通过丰富的服务治理（如地址发现、流量管理等）能力来更好的管控微服务集群；Dubbo3
对原有框架的升级是全面的，体现在核心 Dubbo 特性的几乎每个环节，通过升级实现了稳定性、性能、伸缩性、易用性的全面提升。
-
-
-
-* **通用的通信协议。** 全新的 RPC 协议应摒弃私有协议栈，以更通用的 HTTP/2 协议为传输层载体，借助 HTTP
协议的标准化特性，解决流量通用性、穿透性等问题，让协议能更好的应对前后端对接、网关代理等场景；支持 Stream
通信模式，满足不同业务通信模型诉求的同时给集群带来更大的吞吐量。
-* **面向百万集群实例，集群高度可伸缩。**
随着微服务实践的推广，微服务集群实例的规模也在不停的扩展，这得益于微服务轻量化、易于水平扩容的特性，同时也给整个集群容量带来了负担，尤其是一些中心化的服务治理组件；Dubbo3
需要解决实例规模扩展带来的种种资源瓶颈问题，实现真正的无限水平扩容。
-* **更丰富的编程模型，更小的业务侵入。** 在开发态业务应用面向 Dubbo SDK 编程，在运行态 SDK 与业务应用运行在同一个进程，SDK
的易用性、稳定性与资源消耗将在很大程度上影响业务应用；因此 3.0 应该具备更抽象的 API、更友好的配置模式、更少的侵占业务应用资源、具备更高的可用性。
-* **更易用、更丰富的服务治理能力。** 微服务的动态特性给治理工作带来了很高的复杂性，而 Dubbo
这方面一直做的不错，是最早的一批治理能力定义者与实践者；3.0
需面向更丰富的场景化，提供诸如可观测性、安全性、灰度发布、错误注入、外部化配置、统一的治理规则等能力。
-* **全面拥抱云原生。**
-
-### 面向企业生产实践痛点
-Dubbo2 仍旧是国内首选开源服务框架，被广泛应用在互联网、金融保险、软件企业、传统企业等几乎所有数字化转型企业中，久经规模化生产环境检验。以
Dubbo2 的贡献者和典型用户阿里巴巴为例，阿里巴巴基于 Dubbo2 在内部维护的 HSF2 框架经历了历次双十一峰值考验，每天数十亿次的 RPC
调用，治理着超过千万的服务实例。在长期的优化和实践积累中，阿里巴巴有了对下一代服务框架的设想与方案，在内部开始了快速演进，并快速的被贡献到 Apache
社区，如同阿里巴巴一样，其他用户的实践诉求与痛点也在开源社区快速的积累，形成了一致的方向和技术方案，可以说 Dubbo3
的诞生就来自于超大基数的企业用户积累，为了更好的满足他们的实践诉求。
-
-
-
-Dubbo3 融合了阿里巴巴 HSF2 及其他社区企业的大量服务治理经验，当前 Dubbo3
已经被全面应用到生产实践环境，用户包括阿里巴巴电商、饿了么、钉钉、考拉、阿里云、小米、工商银行、风火递、平安健康等。社区与用户的合作形成的良性循环极大的促进了
Dubbo3 的发展，阿里巴巴已经以社区版 Dubbo3 完全取代了内部维护的 HSF2 框架，他们的实践经验一方面推动 Dubbo3
的稳定性，另一方面正够源源不断的将服务治理实践经验输出到开源社区。
-
-### 面向百万集群实例，横向可扩容
-随着微服务实践经验的积累，微服务被拆分成更细粒度，部署到越来越多的机器实例，以支撑不断增长的业务规模。在众多的 Dubbo2
企业用户中，尤其是以金融保险、互联网为代表的规模化企业开始遇到集群容量瓶颈问题（典型的请参照 [工商银行实践案例](/zh/users/icbc/) ）：
-* **服务发现过程**
- * 注册中心数据存储规模达到容量瓶颈
- * 数据注册&推送效率严重下降
-* **Dubbo 进程**
- * 侵占更多机器资源，导致业务资源利用率降低
- * 频繁 GC 影响业务稳定性
-
-Dubbo3 在设计上很好的解决了这些问题，通过全新设计实现的服务治理（服务发现）模型，可以实现服务发现链路上的数据传输、数据存储量平均下降 90%
左右；同时 Dubbo3 自身在业务进程中变得更轻量、更稳定，实现提升资源利用率 50%。
-
-Dubbo3 一个更大的优势在于其对整体架构稳定性的提升，新的服务发现架构使得对于整个集群容量、可伸缩性评估变得更容易、更准确。
-
-
-
-如果将应用开发粗略划分为业务开发、运维部署两个层次，其中变化比较频繁的因素包括服务（接口）、应用、机器实例。在 2.x
时代，所有这三个因素的增长都会影响微服务集群的总体容量，尤其是接口增减带来的波动，对整体容量评估是非常不透明的。而在 3.0
中集群容量变化仅与应用名、机器实例两个因素相关，而容量评估的对象往往都是应用与实例，因此整个集群变的更稳定透明。
-
-### 云原生
-在云原生时代，底层基础设施的变革正深刻影响应用的部署、运维甚至开发过程，往上也影响了 Dubbo3 微服务技术方案的选型与部署模式。
-
-#### 下一代 RPC 协议
-新一代的 Triple 协议基于 HTTP/2 作为传输层，具备更好的网关、代理穿透性，原生支持 Stream 通信语义，兼容 gRPC 协议。
-
-#### 多语言友好
-Dubbo3 从服务定义、RPC 协议、序列化、服务治理等多个方面都已经将多语言友好性作为重点考量因素，目前提供了 Java、Golang
稳定的多语言版本，更多语言版本的 3.0 实现如 Rust、Javascript、C/C++、C# 等在开发建设中。
-
-#### Kubernetes
-Dubbo3 开发的应用可以原生部署到 Kubernetes 平台，Dubbo3 在地址、生命周期等已设计可与 Kubernetes
等容器调度平台对齐；对于要进一步复用 Kubernetes 底层基础设施能力的用户来说，Dubbo3 也已对接到了原生的 Kubernetes Service
体系。
-
-#### Service Mesh
-Service Mesh 强调控制面在微服务治理中的作用，在一定程度上推动了控制面通信协议、职责范围的扩展与标准化；传统 Mesh 架构下的 Sidecar
模型强调旁路代理对于流量的统一管控，以实现透明升级、多语言无感、无业务侵入等特性。
-
-Dubbo3 提供了基于自身思考的 Dubbo Mesh 解决方案，强调了控制面对微服务集群的统一管控，而在部署架构上，同时支持 sicecar 与无
sidecar 的 proxyless 部署架构，使用 Dubbo Mesh 的用户基于自身的业务特点将有更多的部署架构选择。
-
-#### 异构体系互通
-我们正看到越来越多的异构微服务体系互通的诉求，典型如 Dubbo、Spring Cloud、gRPC
等。有些是因为技术栈迁移，有些是组织合并后需要实现业务互调，Dubbo3 借助于新的服务发现模型以及可灵活扩展的 RPC 协议，可以成为 Dubbo3
未来的发展目标。
+应用级服务发现：提升性能与可伸缩性。
\ 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 ea8295dcd12..f355e14ffe7 100644
--- a/content/zh/overview/what/advantages/traffic-management.md
+++ b/content/zh/overview/what/advantages/traffic-management.md
@@ -4,57 +4,3 @@ title: "流量治理"
linkTitle: "流量治理"
weight: 40
---
-
-### Dashboard
-* [Dubbo-admin](https://github.com/apache/dubbo-admin)
-
-### 支持的组件与部署架构
-
-Dubbo 实现普遍支持以下产品或部署架构，具体多语言 SDK 实现可能有差异。
-
-* 注册中心
- * 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
diff --git a/content/zh/overview/what/advantages/usability.md
b/content/zh/overview/what/advantages/usability.md
index 8e6560d654c..2f4e8994478 100644
--- a/content/zh/overview/what/advantages/usability.md
+++ b/content/zh/overview/what/advantages/usability.md
@@ -4,119 +4,21 @@ title: "易用性"
linkTitle: "易用性"
weight: 20
---
-## RPC 通信
-Dubbo3 的 Triple 协议构建在 HTTP/2 协议之上，因此具有更好的穿透性与通用性，Triple 协议兼容 gRPC，提供 Request
Response、Request Streaming、Response Streaming、Bi-directional Streaming 等通信模型；从
Triple 协议开始，Dubbo 还支持基于 IDL 的服务定义。
-
-此外，Dubbo 还集成了业界主流的大部分协议，使得用户可以在 Dubbo
框架范围内使用这些通信协议，为用户提供了统一的编程模型与服务治理模型，这些协议包括 rest、hessian2、jsonrpc、thrift 等，注意不同语言
SDK 实现支持的范围会有一些差异。
-
-具体可查看
-* [Triple 速览](/zh/docs3-v2/java-sdk/concepts-and-architecture/triple/)
-*
[Specification](https://github.com/apache/dubbo-awesome/blob/master/proposals/D0-triple.md)
-
-## 服务发现
-服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP
地址的情况下实现通信。
-
-实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based
的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的
[Nacos](https://nacos.io/)、Consul、Zookeeper 等，Dubbo 自身也提供了对多种注册中心组件的对接，用户可以灵活选择。
-
-Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：
-
-
-
-在传统的部署架构下，服务发现涉及提供者、消费者和注册中心三个参与角色，其中，提供者注册 URL
地址到注册中心，注册中心负责对数据进行聚合，消费者从注册中心订阅 URL 地址更新。
-在云原生背景下，比如当应用部署在 Kubernetes
等平台，由于平台自身维护了应用/服务与实例间的映射关系，因此注册中心与注册动作在一定程度上被下沉到了基础设施层，因此框架自身的注册动作有时并不是必须的。
-
-Dubbo3 提供了全新的应用级服务发现模型，该模型在设计与实现上区别于 Dubbo2 的接口级服务发现模型。可在此查看：
-*
[应用级服务发现](/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery/#应用级服务发现简介)
-
-## 流量治理
-Dubbo2 开始 Dubbo 就提供了丰富服务治理规则，包括路由规则、动态配置等。
-
-一方面 Dubbo3 正在通过对接 xDS 对接到时下流行的 Mesh 产品如 Istio 中所使用的以
VirtualService、DestinationRule 为代表的治理规则，另一方面 Dubbo
正寻求设计一套自有规则以实现在不同部署场景下的流量治理，以及灵活的治理能力。
-
-* [Dubbo2 服务治理规则](../../tasks/traffic-management)
-* Dubbo3 服务治理规则
-
-## Dubbo Mesh
-Dubbo Mesh 的目标是提供适应 Dubbo 体系的完整 Mesh 解决方案，包含定制化控制面（Control
Plane）、定制化数据面解决方案。Dubbo 控制面基于业界主流 Istio 扩展，支持更丰富的流量治理规则、Dubbo应用级服务发现模型等，Dubbo
数据面可以采用 Envoy Sidecar，即实现 Dubbo SDK + Envoy 的部署方案，也可以采用 Dubbo Proxyless 模式，直接实现
Dubbo 与控制面的通信。Dubbo Mesh 在快速演进中，我们将努力保持文档内容的更新。
-
-
-
-在此查看 Dubbo Mesh 设计细节
-* [Dubbo Proxy
Mesh](https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.1-thinsdk-sidecar-mesh.md)
-* [Dubbo Proxyless
Mesh](https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.2-proxyless-mesh.md)
-* [Dubbo
控制面规划](https://github.com/apache/dubbo-awesome/blob/master/proposals/D3.2-proxyless-mesh.md)
-
-## 部署架构
-> 本节侧重描述传统模式下的 Dubbo 部署架构，在云原生背景下的部署架构会有些变化，主要体现在基础设施（Kubernetes、Service
Mesh等）会承担更多的职责，
-> 中心化组件如注册中心、元数据中心、配置中心等的职责被集成、运维变得更加简单，但通过强调这些中心化的组件能让我们更容易理解 Dubbo 的工作原理。
-
-作为一个微服务框架，Dubbo sdk 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作，
-Dubbo 定义了一些中心化组件，这包括：
-* 注册中心。协调 Consumer 与 Provider 之间的地址注册与发现
-* 配置中心。
- * 存储 Dubbo 启动阶段的全局配置，保证配置的跨环境共享与全局一致性
- * 负责服务治理规则（路由规则、动态配置等）的存储与推送。
-* 元数据中心。
- * 接收 Provider 上报的服务接口元数据，为 Admin 等控制台提供运维能力（如服务测试、接口文档等）
- * 作为服务发现机制的补充，提供额外的接口/方法级别配置信息的同步能力，相当于注册中心的额外扩展
-
-
-
-上图完整的描述了 Dubbo 微服务组件与各个中心的交互过程。
-
-以上三个中心并不是运行 Dubbo
的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心
-以开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
-
-### 注册中心
-
-注册中心扮演着非常重要的角色，它承载着服务注册和服务发现的职责。目前Dubbo支持以下两种粒度的服务发现和服务注册，分别是接口级别和应用级别，注册中心可以按需进行部署：
-
-- 在传统的Dubbo SDK使用姿势中，如果仅仅提供直连模式的RPC服务，不需要部署注册中心。
-- 无论是接口级别还是应用级别，如果需要Dubbo SDK自身来做服务注册和服务发现，则可以选择部署注册中心，在Dubbo中集成对应的注册中心。
-
-- 在Dubbo + Mesh 的场景下，随着 Dubbo
服务注册能力的弱化，Dubbo内的注册中心也不再是必选项，其职责开始被控制面取代，如果采用了Dubbo +
Mesh的部署方式，无论是ThinSDK的mesh方式还是Proxyless的mesh方式，都不再需要独立部署注册中心。
-
-而注册中心并不依赖于配置中心和元数据中心，如下图所示：
-
-
-
-该图中没有部署配置中心和元数据中心，在Dubbo中会默认将注册中心的实例同时作为配置中心和元数据中心，这是Dubbo的默认行为，如果确实不需要配置中心或者元数据中心的能力，可在配置中关闭，在注册中心的配置中有两个配置分别为use-as-config-center和use-as-metadata-center，将配置置为false即可。
-
-### 元数据中心
-
-元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：
-
-1. 对于一个原先采用老版本Dubbo搭建的应用服务，在迁移到Dubbo 3时，Dubbo 3
会需要一个元数据中心来维护RPC服务与应用的映射关系（即接口与应用的映射关系），因为如果采用了应用级别的服务发现和服务注册，在注册中心中将采用“应用 ——
实例列表”结构的数据组织形式，不再是以往的“接口 ——
实例列表”结构的数据组织形式，而以往用接口级别的服务注册和服务发现的应用服务在迁移到应用级别时，得不到接口与应用之间的对应关系，从而无法从注册中心得到实例列表信息，所以Dubbo为了兼容这种场景，在Provider端启动时，会往元数据中心存储接口与应用的映射关系。
-2.
为了让注册中心更加聚焦于地址的发现和推送能力，减轻注册中心的负担，元数据中心承载了所有的服务元数据、大量接口/方法级别配置信息等，无论是接口粒度还是应用粒度的服务发现和注册，元数据中心都起到了重要的作用。
-
-如果有以上两种需求，都可以选择部署元数据中心，并通过Dubbo的配置来集成该元数据中心。
-
-元数据中心并不依赖于注册中心和配置中心，用户可以自由选择是否集成和部署元数据中心，如下图所示：
-
-
-
-该图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了Dubbo
mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
-
-### 配置中心
-
-配置中心与其他两大中心不同，它无关于接口级还是应用级，它与接口并没有对应关系，它仅仅与配置数据有关，即使没有部署注册中心和元数据中心，配置中心也能直接被接入到Dubbo应用服务中。在整个部署架构中，整个集群内的实例（无论是Provider还是Consumer）都将会共享该配置中心集群中的配置，如下图所示：
-
-
-该图中不配备注册中心，意味着可能采用了Dubbo mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
-
-该图中不配备元数据中心，意味着Consumer可以从Provider暴露的MetadataService获取服务元数据，从而实现RPC调用
-
-### 保证三大中心高可用的部署架构
-
-虽然三大中心已不再是Dubbo应用服务所必须的，但是在真实的生产环境中，一旦已经集成并且部署了该三大中心，三大中心还是会面临可用性问题，Dubbo需要支持三大中心的高可用方案。在Dubbo中就支持多注册中心、多元数据中心、多配置中心，来满足同城多活、两地三中心、异地多活等部署架构模式的需求。
-
-Dubbo SDK对三大中心都支持了Multiple模式。
-
-- 多注册中心：Dubbo
支持多注册中心，即一个接口或者一个应用可以被注册到多个注册中心中，比如可以注册到ZK集群和Nacos集群中，Consumer也能够从多个注册中心中进行订阅相关服务的地址信息，从而进行服务发现。通过支持多注册中心的方式来保证其中一个注册中心集群出现不可用时能够切换到另一个注册中心集群，保证能够正常提供服务以及发起服务调用。这也能够满足注册中心在部署上适应各类高可用的部署架构模式。
--
多配置中心：Dubbo支持多配置中心，来保证其中一个配置中心集群出现不可用时能够切换到另一个配置中心集群，保证能够正常从配置中心获取全局的配置、路由规则等信息。这也能够满足配置中心在部署上适应各类高可用的部署架构模式。
-
-- 多元数据中心：Dubbo
支持多元数据中心：用于应对容灾等情况导致某个元数据中心集群不可用，此时可以切换到另一个元数据中心集群，保证元数据中心能够正常提供有关服务元数据的管理能力。
-
-拿注册中心举例，下面是一个多活场景的部署架构示意图：
-
-
+Dubbo提供了简单易用的配置方式，支持XML、Properties、Annotation、Yaml等格式的配置文件。以Dubbo Java
SDK为例，Dubbo支持Spring Boot + Annotation的方式来开发应用。开发者只需要使用@DubboService和
@EnableDubbo来暴露服务，通过@DubboReference和@EnableDubbo即可调用暴露的服务，通过application.properties或application.yml来定义服务相关的配置信息。
+
+Dubbo提供了丰富的samples，开发者可以根据具体情况选择合适的脚手架来构建自己的项目。
+
+Java SDK：dubbo-samples
+Golang SDK：dubbo-go-samples
+Rust SDK：dubbo-rust-samples
+Dubbo从开发者的角度出发，提供了一系列能力降低开发者在调试、部署和调用等环节的复杂度：
+
+本地调用：当在本地开发时，无需配置注册中心也可以实现服务注册发现功能，减少了对注册中心的依赖。
+泛化调用：可以将开发的服务用Http协议对外进行暴露，能够满足在多语言场景下服务调用的需求。
+依赖检查：在服务部署的过程中，Dubbo可以检测依赖的服务是否部署成功。
+延迟暴露：部署的服务可以经过一段时间以后再对外暴露，可以满足服务需要预热的需求。
+异步调用：可以通过Dubbo提供的异步调用功能来提供系统的吞吐量。
+关键词
+支持多种格式的配置文件：支持XML、Properties、Annotation、Yaml等格式的配置文件。
+提供了丰富的脚手架：不同的开发语言提供了对应的开发脚手架。目前已经支持Java、Golang和Rust。
+降低调试、部署和调用等环节的复杂度：支持本地调用、泛化调用、异步调用、依赖检查和延迟暴露。
\ No newline at end of file
diff --git a/content/zh/overview/what/observability.md
b/content/zh/overview/what/observability.md
deleted file mode 100644
index b7318cf4151..00000000000
--- a/content/zh/overview/what/observability.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-type: docs
-title: "可观测性"
-linkTitle: "可观测性"
-weight: 50
----
\ No newline at end of file
diff --git a/content/zh/overview/what/overview.md
b/content/zh/overview/what/overview.md
index bc0e39f5a50..7593c68e343 100644
--- a/content/zh/overview/what/overview.md
+++ b/content/zh/overview/what/overview.md
@@ -18,41 +18,25 @@ description: ""
* Dubbo 作为**服务开发框架**定义了微服务定义、开发与调用的规范
* Dubbo 作为 **RPC 协议实现**解决服务间通信的编解码工作
-<架构图>
+
### 服务开发框架
-就好比 Java 体系的 Spring 定义了
-服务定义：IDL、Java、Golang 等
-调用方式：同步、异步、Reactive
-服务行为：超时、延迟注册、预热、治理中心等
-配置：xml yaml properties
-多语言：Java Spring、Golang xx
+* 服务定义：IDL、Java、Golang 等
+* 调用方式：同步、异步、Reactive
+* 服务行为：超时、延迟注册、预热、治理中心等
+* 配置：xml yaml properties
+* 多语言：Java Spring、Golang xx
### 通信协议
-不绑定通信协议
-流式通信模型
-不绑定序列化协议
-多协议暴露、同时支持单端口上的协议自动识别
-高性能实现：benchmark 图
+* 不绑定通信协议
+* 流式通信模型
+* 不绑定序列化协议
+* 多协议暴露、同时支持单端口上的协议自动识别
+* 高性能实现：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 服务治理
服务发现
负载均衡
@@ -61,52 +45,5 @@ Dubbo 框架负责将请求发送到部署在远端机器上的服务提供方
链路追踪
服务网格
-#### 自动服务（地址）发现
-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/overview.md
b/content/zh/overview/what/overview.md.backup
similarity index 99%
copy from content/zh/overview/what/overview.md
copy to content/zh/overview/what/overview.md.backup
index bc0e39f5a50..a58841559b7 100644
--- a/content/zh/overview/what/overview.md
+++ b/content/zh/overview/what/overview.md.backup
@@ -18,7 +18,7 @@ description: ""
* Dubbo 作为**服务开发框架**定义了微服务定义、开发与调用的规范
* Dubbo 作为 **RPC 协议实现**解决服务间通信的编解码工作
-<架构图>
+
### 服务开发框架
就好比 Java 体系的 Spring 定义了
diff --git a/content/zh/overview/what/xyz-difference.md
b/content/zh/overview/what/xyz-difference.md
index f56523f596f..50634e8579f 100644
--- a/content/zh/overview/what/xyz-difference.md
+++ b/content/zh/overview/what/xyz-difference.md
@@ -1,23 +1,25 @@
---
type: docs
-title: "与 gRPC、Spring Cloud、Service Mesh 的关系"
-linkTitle: "对比 gRPC、Spring Cloud、Service Mesh"
-weight: 30
+title: "与 gRPC、Spring Cloud、Istio 的关系"
+linkTitle: "对比 gRPC、Spring Cloud、Istio"
+weight: 20
description: ""
---
-很多开发者经常会问到 Apache Dubbo 与 Spring Cloud、gRPC 以及一些 Service Mesh 项目如 Istio
的关系，要解释清楚它们的关系并不困难，你只需要跟随这篇文章和 Dubbo 文档做一些更深入的了解，但总的来说，它们有些能力与 Dubbo
是重合的，但在一些场景你可以把它们放在一起使用。虽然这是一篇 Dubbo 维护者写的文档，我们仍会尽力将 Dubbo
与其他组件之间的联系与差异客观、透明的展现出来，但考虑到每个人对不同产品的熟悉程度不一，这里的个别表述可能并不完全准确，希望能给开发者带来帮助。
+很多开发者经常会问到 Apache Dubbo 与 Spring Cloud、gRPC 以及一些 Service Mesh 项目如 Istio
的关系，要解释清楚它们的关系并不困难，你只需要跟随这篇文章和 Dubbo 文档做一些更深入的了解，但总的来说，它们有些能力与 Dubbo
是重合的，但在一些场景你可以把它们放在一起使用。
+
+虽然这是一篇 Dubbo 维护者写的文档，我们仍会尽力将 Dubbo
与其他组件之间的联系与差异客观、透明的展现出来，但考虑到每个人对不同产品的熟悉程度不一，这里的个别表述可能并不完全准确，希望能给开发者带来帮助。
## Dubbo 与 Spring Cloud
-架构图
+
从上图我们可以看出，Dubbo 和 Spring Cloud 有很多相似之处，它们都在整个架构图的相同位置并提供一些相似的功能。
* **Dubbo 和 Spring Cloud
都侧重在对分布式系统中常见问题模式的抽象（如服务发现、负载均衡、动态配置等）**，同时对每一个问题都提供了配套组件实现，形成了一套微服务整体解决方案，让使用
Dubbo 及 Spring Cloud 的用户在开发微服务应用时可以专注在业务逻辑开发上。
* **Dubbo 和 Spring Cloud 都完全兼容 Spring 体系的应用开发模式**，Dubbo 对 Spring 应用开发框架、Spring
Boot 微服务框架都做了很好的适配，由于 Spring Cloud 出自 Spring 体系，在这一点上自然更不必多说。
-虽然两者有很多相似之处，但由于它们在诞生背景与架构设计上的巨大差异，两者在性能、适用的微服务集群规模、生产稳定性保障、服务治理等方面都有很大差异。
+虽然两者有很多相似之处，但由于它们在诞生背景与架构设计上的巨大差异，**两者在性能、适用的微服务集群规模、生产稳定性保障、服务治理等方面都有很大差异**。
Spring Cloud 的优势在于：
* 同样都支持 Sprig 开发体系的情况下，Spring Cloud 得到更多的原生支持
@@ -41,22 +43,36 @@ Spring Cloud 的问题有：
* Dubbo 是在超大规模微服务集群实践场景下开发的框架，可以做到百万实例规模的集群水平扩容，应对集群增长带来的各种问题
* Dubbo 提供 Java 外的多语言实现，使得构建多语言异构的微服务体系成为可能
-Dubbo 也有一些欠缺的地方，尤其是资料的欠缺使得入门门槛略高，体现在依赖配置管理、文档、demo
示例完善度上，当前整个社区在重点投入这一部分的建设，期望能降低用户在第一天体验和学习 Dubbo 时的门槛。
-
如果您的目标是构建企业级应用，并期待在未来的持久维护中能够更省心、更稳定，我们建议你能更深入的了解 Dubbo 的使用和其提供的能力。
+> Dubbo 在入门资料上的欠缺是对比 Spring Cloud 的一个劣势，这体现在依赖配置管理、文档、demo
示例完善度上，当前整个社区在重点投入这一部分的建设，期望能降低用户在第一天体验和学习 Dubbo 时的门槛，不让开发者因为缺乏文档而错失 Dubbo
这样一款优秀的产品。
## Dubbo 与 gRPC
-gRPC 定位为一款 RPC 框架，而 Dubbo
+Dubbo 与 gRPC 最大的差异在于两者的定位上：
+* **gRPC 定位为一款 RPC 框架**，Google 推出它的核心目标是定义云原生时代的 rpc 通信规范与标准实现；
+* **Dubbo 定位是一款微服务开发框架**，它侧重解决微服务实践从服务定义、开发、通信到治理的问题，因此 Dubbo 同时提供了 RPC
通信、与应用开发框架的适配、服务治理等能力。
+
+Dubbo 不绑定特定的通信协议，即 Dubbo 服务间可通过多种 RPC 协议通信并支持灵活切换。因此，你可以在 Dubbo 开发的微服务中选用 gRPC
通信，**Dubbo 完全兼容 gRPC，并将 gRPC 设计为内置原生支持的协议之一**。
+
+如果您看中基于 HTTP/2 的通信协议、基于 Protobuf 的服务定义，并基于此决定选型 gRPC
作为微服务开发框架，那很有可能您会在未来的微服务业务开发中遇到障碍，这主要源于 gRPC 没有为开发者提供以下能力：
+* 缺乏与业务应用框架集成的开发模式，用户需要基于 gRPC 底层的 RPC API 定义、发布或调用微服务，中间可能还有与业务应用开发框架整合的问题
+* 缺乏微服务周边生态扩展与适配，如服务发现、限流降级、链路追踪等没有多少可供选择的官方实现，且扩展起来非常困难
+* 缺乏服务治理能力，作为一款 rpc 框架，缺乏对服务治理能力的抽象
+
+因此，gRPC 更适合作为底层的通信协议规范或编解码包，而 Dubbo 则可用作微服务整体解决方案。**对于 gRPC 协议，我们推荐的使用模式 Dubbo
+ gRPC 的组合**，这个时候，gRPC 只是隐藏在底层的一个通信协议，不被微服务开发者感知，开发者基于 Dubbo 提供的 API
和配置开发服务，并基于 dubbo 的服务治理能力治理服务，在未来，开发者还能使用 Dubbo 生态还开源的 IDL 配套工具管理服务定义与发布。
+
+如果我们忽略 gRPC 在应用开发框架侧的空白，只考虑如何给 gRPC 带来服务治理能力，则另一种可以采用的模式就是在 Service Mesh 架构下使用
gRPC，这就引出了我们下一小节要讨论的内容：Dubbo 与 Service Mesh 架构的关系。
-Dubbo 完全兼容 gRPC，并将 gRPC 设计为内置支持的最重要的协议之一。
+## Dubbo 与 Istio
+Service Mesh 是近年来在云原生背景下诞生的一种微服务架构，在 Kubernetes
体系下，让微服务开发中的更多能力如流量拦截、服务治理等下沉并成为基础设施，让微服务开发、升级更轻量。Istio 是 Service Mesh
的开源代表实现，它从部署架构上分为数据面与控制面，从这一点上与 [Dubbo 总体架构](./overview) 是基本一致的，Istio 带来的主要变化在于：
+* 数据面，Istio 通过引入 Sidecar 实现了对服务流量的透明拦截，Sidecar 通常是与 Dubbo 等开发的传统微服务组件部署在一起
+* 控制面，将之前抽象的服务治理中心聚合为一个具有统一实现的具体组件，并实现了与底层基础设施如 Kubernetes 无缝适配
-## Dubbo 与 Service Mesh
-Dubbo Service Mesh
+**Dubbo 已经实现了对 Istio 体系的全面接入，可以用 Istio 控制面治理 Dubbo 服务，而在数据面部署架构上，针对 Sidecar
引入的复杂性与性能问题，Dubbo 还支持无代理的 Proxyless 模式。** 除此之外，Dubbo Mesh 体系还解决了 Istio
架构落地过程中的很多问题，包括提供更灵活的数据面部署架构、更低的迁移成本等。
-<架构图>
+
-从**数据面**的视角，Dubbo 与 Istio、Consul、Linkerd 等控制面之间是无缝接入和合作关系，
-* 作为，Dubbo 将作为编程框架 & 通信组件而存在，
-* 对于 Dubbo Proxyless 模式，Dubbo 可以通过标准 xDS 协议接入 Istio、Consul、Linkerd 等控制面组件，
+从**数据面**的视角，Dubbo 支持如下两种开发和部署模式，可以通过 Istio、Consul、Linkerd 等控制面组件实现对数据面服务的治理。
+* 以 Dubbo ThinSDK 的模式与 Envoy 一起部署，此时，Dubbo 作为微服务编程框架 & 协议通信组件而存在，与 Istio
控制面的交互由 Envoy 实现
+* 以 Dubbo Proxyless 模式独立部署，此时，Dubbo 可以通过标准 xDS 协议直接接入 Istio、Consul、Linkerd
等控制面组件。
-从**控制面**视角，Dubbo 体系基于 Istio 给出了自己的定制版本控制面实现，
+从**控制面**视角，如之前所述，Dubbo 服务可接入原生 Istio 标准控制面和规则体系，而对于一些 Dubbo 深度用户、老版本用户，Dubbo
Mesh 提供了基于 Istio 的定制版本控制面实现，可以帮助老版本用户平滑的迁移到 Service Mesh 体系。
