This is an automated email from the ASF dual-hosted git repository.
crazyhzm pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new ee727525aa update docs (#1100)
ee727525aa is described below
commit ee727525aa61d68b397cc6ddedb322001f0ca4da
Author: ken.lj <[email protected]>
AuthorDate: Thu Jun 9 15:13:08 2022 +0800
update docs (#1100)
---
content/zh/contribution-guidelines/_index.md | 3 -
.../zh/docs3-building/docs/what/architecture.md | 58 ++++++++++--
content/zh/docs3-building/docs/what/ecosystem.md | 40 ++++-----
.../zh/docs3-building/docs/what/extensibility.md | 100 +++++++++++++++++++++
content/zh/docs3-building/docs/what/overview.md | 34 +++----
content/zh/docs3-building/docs/what/usecases.md | 2 +-
.../docs/whatsnew/service-discovery.md | 34 +++++++
content/zh/docs3-building/docs/whatsnew/triple.md | 4 +-
content/zh/notices/_index.md | 3 -
content/zh/users/_index.md | 28 +++---
content/zh/users/alibaba.md | 25 +++++-
content/zh/users/eleme.md | 56 ++++++++++++
content/zh/users/fenghuodi.md | 7 ++
content/zh/users/icbc.md | 28 +++++-
content/zh/users/pingan.md | 8 ++
content/zh/users/xiaomi.md | 78 +++++++++++++++-
static/imgs/user/eleme/elem-arc.png | Bin 0 -> 107405 bytes
static/imgs/user/eleme/elem-result.png | Bin 0 -> 78649 bytes
static/imgs/user/eleme/elem-upgrade-consumer.png | Bin 0 -> 160777 bytes
static/imgs/user/eleme/elem-upgrade-consumer1.png | Bin 0 -> 119591 bytes
static/imgs/user/eleme/elem-upgrade-provider.png | Bin 0 -> 202140 bytes
static/imgs/user/eleme/elem-upgrade1.png | Bin 0 -> 115362 bytes
static/imgs/user/icbc/icbc-analyze.png | Bin 0 -> 93318 bytes
static/imgs/user/icbc/icbc-data1.png | Bin 0 -> 609563 bytes
static/imgs/user/icbc/icbc-data2.png | Bin 0 -> 751871 bytes
25 files changed, 426 insertions(+), 82 deletions(-)
diff --git a/content/zh/contribution-guidelines/_index.md
b/content/zh/contribution-guidelines/_index.md
index 8de0484e77..8e1cdc9852 100755
--- a/content/zh/contribution-guidelines/_index.md
+++ b/content/zh/contribution-guidelines/_index.md
@@ -4,9 +4,6 @@ type: docs
title: "为 Dubbo 做贡献"
linkTitle: "贡献指南"
description: "Dubbo 贡献指南"
-menu:
- main:
- weight: 50
---
diff --git a/content/zh/docs3-building/docs/what/architecture.md
b/content/zh/docs3-building/docs/what/architecture.md
index 9e281db456..3ea35f75d6 100644
--- a/content/zh/docs3-building/docs/what/architecture.md
+++ b/content/zh/docs3-building/docs/what/architecture.md
@@ -1,10 +1,54 @@
---
type: docs
-title: "总体架构"
-linkTitle: "总体架构"
+title: "概念与架构"
+linkTitle: "概念与架构"
weight: 2
---
-> 本文侧重描述传统模式下的 Dubbo 部署架构，在云原生背景下的部署架构会有些变化，主要体现在基础设施（Kubernetes、Service
Mesh等）会承担更多的职责，
+## 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 速览](../../whatsnew/triple)
+*
[Specification](https://github.com/apache/dubbo-awesome/blob/master/proposals/D0-triple.md)
+
+## 服务发现
+服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP
地址的情况下实现通信。
+
+实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based
的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo
自身也提供了对多种注册中心组件的对接，用户可以灵活选择。
+
+Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：
+
+
+
+在传统的部署架构下，服务发现涉及提供者、消费者和注册中心三个参与角色，其中，提供者注册 URL
地址到注册中心，注册中心负责对数据进行聚合，消费者从注册中心订阅 URL 地址更新。
+在云原生背景下，比如当应用部署在 Kubernetes
等平台，由于平台自身维护了应用/服务与实例间的映射关系，因此注册中心与注册动作在一定程度上被下沉到了基础设施层，因此框架自身的注册动作有时并不是必须的。
+
+Dubbo3 提供了全新的应用级服务发现模型，该模型在设计与实现上区别于 Dubbo2 的接口级服务发现模型。可在此查看：
+* [应用级服务发现速览]()
+*
[应用级服务发现详细设计方案](https://github.com/apache/dubbo-awesome/blob/master/proposals/D1-application-level-service-discovery.md)
+
+## 流量治理
+Dubbo2 开始 Dubbo 就提供了丰富服务治理规则，包括路由规则、动态配置等。
+
+一方面 Dubbo3 正在通过对接 xDS 对接到时下流行的 Mesh 产品如 Istio 中所使用的以
VirtualService、DestinationRule 为代表的治理规则，另一方面 Dubbo
正寻求设计一套自有规则以实现在不通部署场景下的流量治理，以及灵活的治理能力。
+
+* [Dubbo2 服务治理规则]()
+* Dubbo3 服务治理规则
+
+## Dubbo Mesh
+Dubbo Mesh 既有对业务通用产品如 Istio 的适配，又有集成
+
+
+
+在此查看 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 跟随着微服务组件被部署在分布式集群各个位置，为了在分布式环境下实现各个微服务组件间的协作，
@@ -24,7 +68,7 @@ Dubbo 定义了一些中心化组件，这包括：
以上三个中心并不是运行 Dubbo
的必要条件，用户完全可以根据自身业务情况决定只启用其中一个或多个，以达到简化部署的目的。通常情况下，所有用户都会以独立的注册中心
以开始 Dubbo 服务开发，而配置中心、元数据中心则会在微服务演进的过程中逐步的按需被引入进来。
-## 注册中心
+### 注册中心
注册中心扮演着非常重要的角色，它承载着服务注册和服务发现的职责。目前Dubbo支持以下两种粒度的服务发现和服务注册，分别是接口级别和应用级别，注册中心可以按需进行部署：
@@ -39,7 +83,7 @@ Dubbo 定义了一些中心化组件，这包括：
该图中没有部署配置中心和元数据中心，在Dubbo中会默认将注册中心的实例同时作为配置中心和元数据中心，这是Dubbo的默认行为，如果确实不需要配置中心或者元数据中心的能力，可在配置中关闭，在注册中心的配置中有两个配置分别为use-as-config-center和use-as-metadata-center，将配置置为false即可。
-## 元数据中心
+### 元数据中心
元数据中心在2.7.x版本开始支持，随着应用级别的服务注册和服务发现在Dubbo中落地，元数据中心也变的越来越重要。在以下几种情况下会需要部署元数据中心：
@@ -54,7 +98,7 @@ Dubbo 定义了一些中心化组件，这包括：
该图中不配备配置中心，意味着可以不需要全局管理配置的能力。该图中不配备注册中心，意味着可能采用了Dubbo
mesh的方案，也可能不需要进行服务注册，仅仅接收直连模式的服务调用。
-## 配置中心
+### 配置中心
配置中心与其他两大中心不同，它无关于接口级还是应用级，它与接口并没有对应关系，它仅仅与配置数据有关，即使没有部署注册中心和元数据中心，配置中心也能直接被接入到Dubbo应用服务中。在整个部署架构中，整个集群内的实例（无论是Provider还是Consumer）都将会共享该配置中心集群中的配置，如下图所示：
@@ -63,7 +107,7 @@ Dubbo 定义了一些中心化组件，这包括：
该图中不配备元数据中心，意味着Consumer可以从Provider暴露的MetadataService获取服务元数据，从而实现RPC调用
-## 保证三大中心高可用的部署架构
+### 保证三大中心高可用的部署架构
虽然三大中心已不再是Dubbo应用服务所必须的，但是在真实的生产环境中，一旦已经集成并且部署了该三大中心，三大中心还是会面临可用性问题，Dubbo需要支持三大中心的高可用方案。在Dubbo中就支持多注册中心、多元数据中心、多配置中心，来满足同城多活、两地三中心、异地多活等部署架构模式的需求。
diff --git a/content/zh/docs3-building/docs/what/ecosystem.md
b/content/zh/docs3-building/docs/what/ecosystem.md
index 3a5a591b9f..e5bee73b15 100644
--- a/content/zh/docs3-building/docs/what/ecosystem.md
+++ b/content/zh/docs3-building/docs/what/ecosystem.md
@@ -2,25 +2,22 @@
type: docs
title: "Dubbo 生态"
linkTitle: "生态系统"
-weight: 3
-description: ""
+weight: 4
---
-### SPI 扩展实现
-* [dubbo-spi-extensions](https://github.com/apache/dubbo-spi-extensions)
-
### 多语言实现
* Golang
* Java
* Rust
-* Javascript
+* Node
* Python
* PHP
### Dashboard
-* Dubbo-admin
+* [Dubbo-admin](https://github.com/apache/dubbo-admin)
-### 中心化组件
+### 支持的组件与部署架构
+Dubbo 实现普遍支持以下产品或部署架构。
* 注册中心
* Zookeeper
* Nacos
@@ -34,27 +31,30 @@ description: ""
* Nacos
* Redis
* Apollo
+* Mesh
+ * 数据面 Envoy
+ * 控制面 Istio
### 协议与互通性
-* 如何实现与 gRPC 体系互通
-* 如何实现与 Spring Cloud 体系互通
+* 基于 Triple 协议可实现与 gRPC 体系互通
+* 基于 REST 协议以及应用级服务发现可实现 Spring Cloud 体系在协议和地址发现层面的互通
### SPI 集成
-* dubbo-spi-extensions
-* 参见 SPI 扩展说明
+这里有众多的 Dubbo 扩展实现，包括协议、序列化、注册中心等
+* [dubbo-spi-extensions]()
### 网关组件
-* Apache Shenyu(Incubating)
-* Apache APISIX
-* Apache Dubbo-pixiu
-* Tengine
+* [Apache Shenyu(Incubating)]()
+* [Apache APISIX]()
+* [Apache Dubbo-pixiu]()
+* [Tengine]()
### 链路追踪
-* Zipkin
-* Apache Skywalking
+* [Zipkin]()
+* [Apache Skywalking]()
### 其他微服务组件
-* Sentinel
-* Seata
+* 限流 [Sentinel]()
+* 事务 [Seata]()
diff --git a/content/zh/docs3-building/docs/what/extensibility.md
b/content/zh/docs3-building/docs/what/extensibility.md
new file mode 100644
index 0000000000..895447f4ec
--- /dev/null
+++ b/content/zh/docs3-building/docs/what/extensibility.md
@@ -0,0 +1,100 @@
+---
+type: docs
+title: "可扩展性"
+linkTitle: "可扩展性"
+weight: 3
+---
+
+## 扩展设计理念
+
+可扩展性是任何一个系统所追求的，对于 Dubbo 来说是同样适用。
+
+### 什么是可扩展性
+
+可扩展性是一种设计理念，代表了我们对未来的一种预想，我们希望在现有的架构或设计基础上，当未来某些方面发生变化的时候，我们能够以最小的改动来适应这种变化。
+
+### 可扩展性的优点
+
+可扩展性的优点主要表现模块之间解耦，它符合开闭原则，对扩展开放，对修改关闭。当系统增加新功能时，不需要对现有系统的结构和代码进行修改，仅仅新增一个扩展即可。
+
+### 扩展实现方式
+
+一般来说，系统会采用 Factory、IoC、OSGI 等方式管理扩展(插件)生命周期。考虑到 Dubbo 的适用面，不想强依赖 Spring 等 IoC
容器。
+而自己造一个小的 IoC 容器，也觉得有点过度设计，所以选择最简单的 Factory 方式管理扩展(插件)。在 Dubbo
中，所有内部实现和第三方实现都是平等的。
+
+### Dubbo 中的可扩展性
+
+* 平等对待第三方的实现。在 Dubbo 中，所有内部实现和第三方实现都是平等的，用户可以基于自身业务需求，替换 Dubbo 提供的原生实现。
+*
每个扩展点只封装一个变化因子，最大化复用。每个扩展点的实现者，往往都只是关心一件事。如果用户有需求需要进行扩展，那么只需要对其关注的扩展点进行扩展就好，极大的减少用户的工作量。
+
+## Dubbo 扩展的特性
+
+Dubbo 中的扩展能力是从 JDK 标准的 SPI 扩展点发现机制加强而来，它改进了 JDK 标准的 SPI 以下问题：
+
+* JDK 标准的 SPI 会一次性实例化扩展点所有实现，如果有扩展实现初始化很耗时，但如果没用上也加载，会很浪费资源。
+* 如果扩展点加载失败，连扩展点的名称都拿不到了。比如：JDK 标准的 ScriptEngine，通过 getName() 获取脚本类型的名称，但如果
RubyScriptEngine 因为所依赖的 jruby.jar 不存在，导致 RubyScriptEngine 类加载失败，这个失败原因被吃掉了，和
ruby 对应不起来，当用户执行 ruby 脚本时，会报不支持 ruby，而不是真正失败的原因。
+
+用户能够基于 Dubbo 提供的扩展能力，很方便基于自身需求扩展其他协议、过滤器、路由等。下面介绍下 Dubbo 扩展能力的特性。
+
+* 按需加载。Dubbo 的扩展能力不会一次性实例化所有实现，而是用哪个扩展类则实例化哪个扩展类，减少资源浪费。
+* 增加扩展类的 IOC 能力。Dubbo 的扩展能力并不仅仅只是发现扩展服务实现类，而是在此基础上更进一步，如果该扩展类的属性依赖其他对象，则 Dubbo
会自动的完成该依赖对象的注入功能。
+* 增加扩展类的 AOP 能力。Dubbo 扩展能力会自动的发现扩展类的包装类，完成包装类的构造，增强扩展类的功能。
+* 具备动态选择扩展实现的能力。Dubbo 扩展会基于参数，在运行时动态选择对应的扩展类，提高了 Dubbo 的扩展能力。
+* 可以对扩展实现进行排序。能够基于用户需求，指定扩展实现的执行顺序。
+* 提供扩展点的 Adaptive 能力。该能力可以使的一些扩展类在 consumer 端生效，一些扩展类在 provider 端生效。
+
+从 Dubbo 扩展的设计目标可以看出，Dubbo 实现的一些例如动态选择扩展实现、IOC、AOP 等特性，能够为用户提供非常灵活的扩展能力。
+
+## Dubbo 扩展加载流程
+
+Dubbo 加载扩展的整个流程如下：
+
+
+
+主要步骤为 4 个：
+* 读取并解析配置文件
+* 缓存所有扩展实现
+* 基于用户执行的扩展名，实例化对应的扩展实现
+* 进行扩展实例属性的 IOC 注入以及实例化扩展的包装类，实现 AOP 特性
+
+## 如何使用 Dubbo 扩展能力进行扩展
+
+下面以扩展注册中心为例进行说明如何利用 Dubbo 提供的扩展能力扩展 Triple 协议。
+
+(1) 在协议的实现 jar
包内放置文本文件：META-INF/dubbo/org.apache.dubbo.remoting.api.WireProtocol
+```text
+tri=org.apache.dubbo.rpc.protocol.tri.TripleHttp2Protocol
+```
+
+(2) 实现类内容
+```java
+@Activate
+public class TripleHttp2Protocol extends Http2WireProtocol {
+ // ...
+}
+```
+
+说明下：Http2WireProtocol 实现了 WireProtocol 接口
+
+(3) Dubbo 配置模块中，扩展点均有对应配置属性或标签，通过配置指定使用哪个扩展实现。比如：
+```text
+<dubbo:protocol name="tri" />
+```
+
+从上面的扩展步骤可以看出，用户基本在黑盒下就完成了扩展。
+
+## Dubbo 扩展的应用
+
+Dubbo 的扩展能力非常灵活，在自身功能的实现上无处不在。
+
+
+
+Dubbo 扩展能力使得 Dubbo 项目很方便的切分成一个一个的子模块，实现热插拔特性。用户完全可以基于自身需求，替换 Dubbo
原生实现，来满足自身业务需求。
+
+## 使用场景
+
+* 如果你需要自定义负载均衡策略，你可以使用 Dubbo 扩展能力。
+* 如果你需要实现自定义的注册中心，你可以使用 Dubbo 扩展能力。
+* 如果你需要实现自定义的过滤器，你可以使用 Dubbo 扩展能力。
+
+Dubbo 扩展平等的对待内部实现和第三方实现。更多使用场景，参见 [SPI 扩展实现](../../references/spis/)
\ No newline at end of file
diff --git a/content/zh/docs3-building/docs/what/overview.md
b/content/zh/docs3-building/docs/what/overview.md
index 01a53c5097..a625e5bdb8 100644
--- a/content/zh/docs3-building/docs/what/overview.md
+++ b/content/zh/docs3-building/docs/what/overview.md
@@ -13,12 +13,12 @@ Dubbo3 定义为面向云原生的下一代 RPC 服务框架。3.0 基于 [Dubbo
### Dubbo 是什么
-Apache Dubbo 是一款开源 RPC 服务框架，它最初在 2008 年由 Alibaba
捐献开源，并且很快成为了国内开源服务框架选型的事实标准框架，得到了各行各业的广泛应用。在 2017 年，Dubbo 正式捐献到 Apache 软件基金会并成为
Apache 顶级项目，目前 Dubbo3 已经是一站式的微服务解决方案提供：
-* 基于 HTTP/2 的 [Triple 协议](../whatsnew/triple)以及面向代理 API 的编程体验。
-* 强大的[流量治理能力](../tasks/traffic-management)，如地址发现、负载均衡、路由选址、动态配置等。
-* [多语言 SDK 实现](../mannual/)，涵盖 Java、Golang、Javascript 等，更多语言实现将会陆续发布。
+Apache Dubbo 最初在 2008 年由 Alibaba 捐献开源，很快成为了国内开源服务框架选型的事实标准框架
，得到了各行各业的广泛应用。在 2017 年，Dubbo 正式捐献到 Apache 软件基金会并成为 Apache 顶级项目，目前 Dubbo3
已经是一站式的微服务解决方案提供：
+* 基于 HTTP/2 的 [Triple 协议](../../whatsnew/triple)以及面向代理 API 的编程体验。
+* 强大的[流量治理能力](../../tasks/traffic-management)，如地址发现、负载均衡、路由选址、动态配置等。
+* [多语言 SDK 实现](../../mannual/)，涵盖 Java、Golang、Javascript 等，更多语言实现将会陆续发布。
* 灵活的适配与扩展能力，可轻松与微服务体系其他组件如 Tracing、Transaction 等适配。
-* [Service Mesh 解决方案](../whatsnew/mesh)，同时支持 Sidecar、Proxyless 等灵活的 Mesh 部署方案。
+* [Service Mesh 解决方案](../../whatsnew/mesh)，同时支持 Sidecar、Proxyless 等灵活的 Mesh
部署方案。
Apache Dubbo
总体架构能很好的满足企业的大规模微服务实践，因为它从设计之初就是为了解决超大规模微服务集群实践问题，不论是阿里巴巴还是工商银行、中国平安、携程等社区用户，它们都通过多年的大规模生产环境流量对
Dubbo 的稳定性与性能进行了充分验证，因此，Dubbo 在解决业务落地与规模化实践方面有着无可比拟的优势：
* 开箱即用
@@ -27,33 +27,25 @@ Apache Dubbo 总体架构能很好的满足企业的大规模微服务实践，
* 面向超大规模微服务集群设计
* 极致性能，高性能的 RPC 通信协议设计与实现
* 横向可扩展，轻松支持百万规模集群实例的地址发现与流量治理
-* [高度可扩展]()
+* [高度可扩展](../extensibility)
* 调用过程中对流量及协议的拦截扩展，如 Filter、Router、LB 等
* 微服务治理组件扩展，如 Registry、Config Center、Metadata Center 等
* 企业级微服务治理能力
* 国内共有云厂商支持的事实标准服务框架
- * 多年企业实践经验考验，参考[用户实践案例](../../users)
+ * 多年企业实践经验考验，参考[用户实践案例](../../../users)
### Dubbo 基本工作流程
-Dubbo 首先是一款 RPC 框架，它定义了自己的 RPC 通信协议与编程方式。如上图所示，用户在使用 Dubbo 时首先需要定义好 Dubbo
服务；其次，是在将 Dubbo 服务部署上线之后，依赖 Dubbo 的应用层通信协议实现数据交换，Dubbo
所传输的数据都要经过序列化，而这里的[序列化协议]()是完全可扩展的。
-使用 Dubbo 的第一步就是定义 Dubbo 服务，服务在 Dubbo
中的定义就是完成业务功能的一组方法的集合，可以选择使用与某种语言绑定的方式定义，如在 Java 中 Dubbo 服务就是有一组方法的 Interface
接口，也可以使用语言中立的 Protobuf Buffers [IDL
定义服务]()。定义好服务之后，服务端（Provider）需要提供服务的具体实现，并将其声明为 Dubbo
服务，而站在服务消费方（Consumer）的视角，通过调用 Dubbo 框架提供的 API
可以获得一个服务代理（stub）对象，然后就可以像使用本地服务一样对服务方法发起调用了。
+Dubbo 首先是一款 RPC 框架，它定义了自己的 RPC 通信协议与编程方式。如上图所示，用户在使用 Dubbo 时首先需要定义好 Dubbo
服务；其次，是在将 Dubbo 服务部署上线之后，依赖 Dubbo 的应用层通信协议实现数据交换，Dubbo
所传输的数据都要经过序列化，而这里的序列化协议是完全可扩展的。
+使用 Dubbo 的第一步就是定义 Dubbo 服务，服务在 Dubbo
中的定义就是完成业务功能的一组方法的集合，可以选择使用与某种语言绑定的方式定义，如在 Java 中 Dubbo 服务就是有一组方法的 Interface
接口，也可以使用语言中立的 Protobuf Buffers [IDL
定义服务](../../tasks/idl)。定义好服务之后，服务端（Provider）需要提供服务的具体实现，并将其声明为 Dubbo
服务，而站在服务消费方（Consumer）的视角，通过调用 Dubbo 框架提供的 API
可以获得一个服务代理（stub）对象，然后就可以像使用本地服务一样对服务方法发起调用了。
在消费端对服务方法发起调用后，Dubbo
框架负责将请求发送到部署在远端机器上的服务提供方，提供方收到请求后会调用服务的实现类，之后将处理结果返回给消费端，这样就完成了一次完整的服务调用。如图中的
Request、Response 数据流程所示。
>需要注意的是，在 Dubbo 中，我们提到服务时，通常是指 RPC
>粒度的、提供某个具体业务增删改功能的接口或方法，与一些微服务概念书籍中泛指的服务并不是一个概念。
在分布式系统中，尤其是随着微服务架构的发展，应用的部署、发布、扩缩容变得极为频繁，作为 RPC 消费方，如何定动态的发现服务提供方地址成为 RPC
通信的前置条件。Dubbo
提供了自动的地址发现机制，用于应对分布式场景下机器实例动态迁移的问题。如下图所示，通过引入注册中心来协调提供方与消费方的地址，提供者启动之后向注册中心注册自身地址，消费方通过拉取或订阅注册中心特定节点，动态的感知提供方地址列表的变化。
-
-
-地址发现解决了实例变更的问题，但微服务环境下的服务治理诉求同样变得非常复杂，用户需要考虑 Dubbo
服务治理的问题如服务测试、服务元数据管理、流量管控、动态行为调整等，为此， Dubbo 架构引入了配置中心、元数据中心进一步拓展了其服务治理边界。
-
-
-
-随着云原生架构的发展，更多的微服务组件及能力正下沉到以 Kubernetes
为代表的基础设施层。一方面传统微服务开发框架应剔除一些冗余机制，积极的适配到基础设施层以做到能力复用；另一方面微服务框架生命周期、服务治理等能力应更好地与
Kubernetes 服务编排机制融合。更近一步的，以 Service Mesh 为代表的微服务架构给微服务开发带来了新的选择，Dubbo3 也完成了对
Kubernetes、Mesh 的适配。
-
-
+
### Dubbo 核心特性
@@ -65,7 +57,7 @@ Dubbo 首先是一款 RPC 框架，它定义了自己的 RPC 通信协议与编
* 提供端响应流（Response Streaming）
* 双向流式通信（Bidirectional Streaming）
-具体可参见[可选协议列表]()、[Triple协议]()
+具体可参见[可选协议列表]() 或 [Triple协议](../../triple)
#### 自动服务（地址）发现
Dubbo 的服务发现机制，让微服务组件之间可以独立演进并任意部署，消费端可以在无需感知对端部署位置与 IP 地址的情况下完成通信。Dubbo 提供的是
Client-Based 的服务发现机制，使用者可以有多种方式启用服务发现：
@@ -80,9 +72,9 @@ Dubbo 的服务发现机制，让微服务组件之间可以独立演进并任
#### 丰富的扩展组件及生态
Dubbo 强大的服务治理能力不仅体现在核心框架上，还包括其优秀的扩展能力以及周边配套设施的支持。通过 Filter、Router、Protocol
等几乎存在于每一个关键流程上的扩展点定义，我们可以丰富 Dubbo 的功能或实现与其他微服务配套系统的对接，包括 Transaction、Tracing
目前都有通过 SPI 扩展的实现方案，具体可以参见 Dubbo 扩展性的详情，也可以在
[apache/dubbo-spi-extensions](https://github.com/apache/dubbo-spi-extensions)
项目中发现与更多的扩展实现。具体可参见：
-* [Dubbo 生态](./ecosystem)
+* [Dubbo 生态](../ecosystem)
* [官方扩展组件](https://github.com/apache/dubbo-spi-extensions)
-* [Dubbo 可扩展性设计]()
+* [Dubbo 可扩展性设计](../extensibility)
#### 面向云原生设计
diff --git a/content/zh/docs3-building/docs/what/usecases.md
b/content/zh/docs3-building/docs/what/usecases.md
index da522ab493..d2a5bf1860 100644
--- a/content/zh/docs3-building/docs/what/usecases.md
+++ b/content/zh/docs3-building/docs/what/usecases.md
@@ -2,7 +2,7 @@
type: docs
title: "用户案例"
linkTitle: "用户案例"
-weight: 4
+weight: 5
manualLinkRelref: ../../../users/
manualLinkTarget: _blank
_build: { render: link }
diff --git a/content/zh/docs3-building/docs/whatsnew/service-discovery.md
b/content/zh/docs3-building/docs/whatsnew/service-discovery.md
index ed73940a73..db87dcf17d 100644
--- a/content/zh/docs3-building/docs/whatsnew/service-discovery.md
+++ b/content/zh/docs3-building/docs/whatsnew/service-discovery.md
@@ -5,7 +5,41 @@ linkTitle: "应用级服务发现"
weight: 3
---
+在这里查看更多文档
+*
[应用级服务发现详细设计](https://github.com/apache/dubbo-awesome/blob/master/proposals/D1-application-level-service-discovery.md)
+*
[如何从接口级服务发现迁移到应用级服务发现](../../../java-sdk/upgrades-and-compatibility/migration-service-discovery)
+* [饿了么应用级服务发现迁移指南](../../../../users/eleme)
+* [工商银行应用级服务发现](../../../../users/icbc)
+概括来说，Dubbo3 引入的应用级服务发现主要有以下优势
+* 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3
的应用级服务发现是适配各种微服务体系的通用模型。
+* 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo
的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer
侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
+下图是 Dubbo2 的服务发现模型：Provider 注册服务地址，Consumer
经过注册中心协调并发现服务地址，进而对地址发起通信，这是被绝大多数微服务框架的经典服务发现流程。而 Dubbo2 的特殊之处在于，它把 “RPC
接口”的信息也融合在了地址发现过程中，而这部分信息往往是和具体的业务定义密切相关的。
+
+
+
+而在接入云原生基础设施后，基础设施融入了微服务概念的抽象，容器化微服务被编排、调度的过程即完成了在基础设施层面的注册。如下图所示，基础设施既承担了注册中心的职责，又完成了服务注册的动作，而
“RPC 接口”这部分信息，由于与具体的业务相关，不可能也不适合被基础设施托管。
+
+
+
+在这样的场景下，对 Dubbo3 的服务注册发现机制提出了两个要求：
+Dubbo3 需要在原有服务发现流程中抽象出通用的、与业务逻辑无关的地址映射模型，并确保这部分模型足够合理，以支持将地址的注册行为和存储委托给下层基础设施
+Dubbo3 特有的业务接口同步机制，是 Dubbo3 需要保留的优势，需要在 Dubbo3 中定义的新地址模型之上，通过框架内的自有机制予以解决。
+
+这样设计的全新的服务发现模型，在架构兼容性、可伸缩性上都给 Dubbo3 带来了更大的优势。
+
+
+
+在架构兼容性上，如上文所述，Dubbo3 复用下层基础设施的服务抽象能力成为了可能；另一方面，如 Spring Cloud
等业界其它微服务解决方案也沿用这种模型，
+在打通了地址发现之后，使得用户探索用 Dubbo 连接异构的微服务体系成为了一种可能。
+
+Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如何理解？
+这里先举个简单的例子，来直观的对比 Dubbo2 与 Dubbo3 在地址发现流程上的数据流量变化：假设一个微服务应用定义了 100 个接口（Dubbo
中的服务），
+则需要往注册中心中注册 100 个服务，如果这个应用被部署在了 100 台机器上，那这 100 个服务总共会产生 100 * 100 = 10000
个虚拟节点；而同样的应用，
+对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100
个虚拟节点到注册中心。
+在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，
+地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，
+因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
diff --git a/content/zh/docs3-building/docs/whatsnew/triple.md
b/content/zh/docs3-building/docs/whatsnew/triple.md
index ecb1bfe2b7..35fa12f0b1 100644
--- a/content/zh/docs3-building/docs/whatsnew/triple.md
+++ b/content/zh/docs3-building/docs/whatsnew/triple.md
@@ -18,6 +18,6 @@ Java SDK 支持 [IDL 生成
Stub](../../../java-sdk/reference-manual/protocol/tr
和 [Java Interface](../../../java-sdk/reference-manual/protocol/triple/idl)
两种方式，多语言、生态互通、流式需求推荐使用 IDL 方式，现有服务平滑升级推荐使用
Interface 方式。
-- 已有服务参考[从现有协议升级至 Triple](TBD)
-- 新服务参考[Dubbo3 Triple Quick Start](../../../java-sdk/quick-start)
+- Dubbo2 老用户如何从现有协议[升级至 Triple](TBD)
+- 新用户或业务参考[Dubbo3 Triple Quick Start](../../../java-sdk/quick-start)
- 深入了解 Triple 协议:[Dubbo3 Triple 协议设计与原理](TBD)
diff --git a/content/zh/notices/_index.md b/content/zh/notices/_index.md
index ca14518426..0960d1d687 100755
--- a/content/zh/notices/_index.md
+++ b/content/zh/notices/_index.md
@@ -4,8 +4,5 @@ type: docs
title: "公告栏"
linkTitle: "公告"
description: "Dubbo 公告"
-menu:
- main:
- weight: 60
---
diff --git a/content/zh/users/_index.md b/content/zh/users/_index.md
index ee2f7b5005..b0bd78c22a 100644
--- a/content/zh/users/_index.md
+++ b/content/zh/users/_index.md
@@ -20,39 +20,39 @@ menu:
<div class="row">
<div class="col-12 col-lg-12">
-
+<p class="my-3">
Apache Dubbo
诞生于阿里巴巴微服务实践之中，在开源之后深受企业用户喜爱并迅速成为国内开源服务框架选型的事实标准产品，用户范围涵盖互联网、金融保险、科技公司、制造业、零售物流等领域的几乎所有头部用户。
-
+</p>
{{< cardpane >}}
{{< card header="阿里巴巴的 Dubbo3 落地实践" >}}
-阿里巴巴电商核心系统已成功升级到 Dubbo3 版本，用于取代上一代 HSF2 服务框架，2022 年起双 11 核心链路都将跑在 Dubbo3
之上。<br/>
-<a href='{{< relref "alibaba.md" >}}'>了解更多</a>
+阿里巴巴电商核心系统已成功升级到 Dubbo3 版本，用于取代上一代 HSF2 服务框架，2022 年起双 11 核心链路都将跑在 Dubbo3
之上。<br/><br/>
+<a href='{{< relref "alibaba" >}}'>了解更多</a>
{{< /card >}}
{{< card header="工商银行 Dubbo3 应用级服务发现实践" >}}
- 工商银行为什么要选型 Dubbo3 应用级服务发现架构那？核心原因是 2.x 版本架构在超大规模集群实战上的性能和容量瓶颈。<br/>
- <a href='{{< relref "alibaba" >}}'>了解更多</a>
+ 工商银行为什么要选型 Dubbo3 应用级服务发现架构那？2.x 版本架构在超大规模集群实战上遇到了那些性能和容量瓶颈？<br/><br/>
+ <a href='{{< relref "icbc" >}}'>了解更多</a>
{{< /card >}}
{{< card header="小米的 Dubbo3 实践" >}}
- 小米对 Dubbo 多语言版本 Java、Golang 都有着广泛的使用。<br/>
- <a href='{{< relref "alibaba" >}}'>了解更多</a>
+ 小米对 Dubbo 多语言版本 Java、Golang 都有着广泛的使用。<br/><br/>
+ <a href='{{< relref "xiaomi" >}}'>了解更多</a>
{{< /card >}}
{{< /cardpane >}}
{{< cardpane >}}
{{< card header="饿了么全站成功升级 Dubbo3" >}}
- 饿了么当前有超过 2000 应用，10 万实例跑在 Dubbo3 之上，通过应用级服务发现与 Triple 协议解决了跨单元的互联互通问题。<br/>
- <a href='{{< relref "alibaba" >}}'>了解更多</a>
+ 饿了么当前有接近 2000 应用、10 万实例跑在 Dubbo3 之上，通过应用级服务发现与 Triple
协议解决了跨单元的互联互通问题。<br/><br/>
+ <a href='{{< relref "eleme" >}}'>了解更多</a>
{{< /card >}}
{{< card header="平安健康" >}}
- 平安健康目前正从 2.x 版本迁移到 Dubbo3<br/>
- <a href='{{< relref "alibaba" >}}'>了解更多</a>
+ 平安健康目前正从 2.x 版本迁移到 Dubbo3，升级过程中与社区开发者进行了深度合作，中间也总结了一些升级经验，非常具有参考价值。<br/><br/>
+ <a href='{{< relref "pingan" >}}'>了解更多</a>
{{< /card >}}
{{< card header="烽火递" >}}
- 烽火递的所有新业务都使用 Dubbo3 构建，由于没有 dubbo2 的迁移成本，业务得以很快的稳定上线。<br/>
- <a href='{{< relref "alibaba" >}}'>了解更多</a>
+ 烽火递的所有新业务都使用 Dubbo3 构建，由于没有 dubbo2 的迁移成本，业务得以很快的稳定上线，新业务都跑在 Dubbo3
的新特性之上。<br/><br/>
+ <a href='{{< relref "fenghuodi" >}}'>了解更多</a>
{{< /card >}}
{{< /cardpane >}}
diff --git a/content/zh/users/alibaba.md b/content/zh/users/alibaba.md
index 983179735c..07586f380d 100644
--- a/content/zh/users/alibaba.md
+++ b/content/zh/users/alibaba.md
@@ -1,7 +1,26 @@
---
type: docs
-title: "阿里巴巴"
+title: "阿里巴巴升级 Dubbo3 全面取代 HSF2"
linkTitle: "阿里巴巴"
weight: 1
-description: Dubbo 用户案例分享，涵盖最新 3.0 版本
----
\ No newline at end of file
+---
+
+作为 Dubbo3 的主要定义者以及核心用户，阿里巴巴内部的核心业务线目前均已或正在迁移到 Dubbo3 版本。众所周知，阿里巴巴内部业务一直运行在自研
HSF2 框架之上，HSF2 与 Dubbo2 之间有很深的渊源，两者之间在设计理念上有很多相似之处，但实际上经过多年的发展已经演进成两个完全不同的框架，在
Dubbo3 设计的过程中完全汲取了 HSF2 与 Dubbo2两者的优势，尤其是 HSF2 在阿里内部多年超大规模集群实践的经验。
+
+ 阿里巴巴是如何用开源的 Dubbo3 取代 HSF2的那？一些企业内部特有的诉求并不能完全开源，这一点是怎么做到的？答案就是通过 SPI
扩展，所以在阿里内部也启动了一个全新的 HSF3 项目，HSF3 与以往的 HSF2 完全不同，HSF3 完全就是基于标准 Dubbo3 的 SPI
扩展库，因此它更像是一个 SPI
的插件扩展仓库，汇聚了诸如注册中心扩展、路由组件扩展、监控组件扩展等一系列扩展实现，而其他配置组装、服务暴露、服务发现、地址解析等核心流程都已经完全跑在开源
Dubbo3 之上；在这样的模式下，阿里巴巴的内部实践诉求已经完全体现在开源 Dubbo3 之上，包括内部开发人员也工作在开源 Dubbo3
之上，这对于开源社区的发展是一个很大的保障与补充。
+
+ 
+
+阿里巴巴的业务线非常广泛，而 Dubbo3 当前也在几乎所有的业务线都已经开始升级。阿里生态如本地生活饿了么、钉钉、考拉等都已经全面升级
Dubbo3；天猫、淘宝等电商核心链路也已完成 Dubbo3 升级，2022 双 11 整个系统将和 Dubbo3
一起迎来第一个峰值考验；阿里云的微服务平台以及多条产品线目前也是基于 Dubbo3 构建。
+
+对于阿里巴巴而言，其关注的核心特性包括：
+* 应用级服务发现，用于解决超大规模集群下的注册中心容量、消费端实例资源占用问题
+* Triple 协议，解决跨网关 RPC 通信 以及提供 Reactive Stream 通信模型。
+* 统一的流量治理规则，通过统一的流量治理规则及控制面实现服务治理能力的统一
+
+关于 Dubbo3 的升级经验与收益分享将持续在此发布。
+
+
+
+
+
diff --git a/content/zh/users/eleme.md b/content/zh/users/eleme.md
new file mode 100644
index 0000000000..ffb4a40925
--- /dev/null
+++ b/content/zh/users/eleme.md
@@ -0,0 +1,56 @@
+---
+type: docs
+title: "饿了么全站成功升级 Dubbo3 "
+linkTitle: "饿了么"
+weight: 3
+---
+### 升级目标
+
+
+这里是饿了么的的基本部署架构图。
+
+在升级之前，饿了么的微服务框架采用的是 HSF2，跨单元的 RPC 调用是通过 proxy 中转代理，在这个过程中 proxy
所承载的机器数和流量迅速增长，比较突出的一点是 proxy 在订阅所有的地址数据后资源消耗和稳定性都收到严峻挑战。
+
+通过全站升级 Dubbo3，业务线期望达到两个目标：
+* 将地址模型切换到应用级服务发现大幅减轻中心化节点和消费端节点的资源消耗压力。
+* 以应用级服务发现架构下的全局共享注册中心取代 proxy 模式，实现跨单元节点通信直连。
+
+
+### 升级过程
+
+
+不论是针对 Dubbo2 还是 HSF2，我们都做了全面的 API 兼容，因此 Dubbo3
基本可以做到零改造升级，并且每个应用都是独立透明升级，不需要关心它的上下游应用的升级状态，因为 Dubbo3
升级之后不论是从地址发现模型还是协议的默认行为都保持与 2.0 版本兼容，用户可以在任意时间点对任意应用按需切换 Dubbo3 行为。
+如右图所示，我们模拟展示了饿了么集群 Dubbo3 升级过程的一个中间状态，其中灰色标记的是老版本 HSF2 应用，橙色和绿色标记的是已经升级 Dubbo3
的应用，橙色部分的应用及其调用链路代表不但已经升级到 Dubbo3，同时也完成了 Dubbo3
行为的切换，在这里是指已经切换到了应用级地址模型。这里的升级过程主要为了说明 Dubbo3 框架升级的兼容性和独立性。
+
+接下来，我们详细分析一下橙色部分节点往 Dubbo3 应用级发现迁移的具体过程。
+
+
+
+首先看 Provider 侧，服务提供者在升级 Dubbo3
后会默认保持双注册行为，即同时注册接口级地址和应用级地址到注册中心，一方面保持兼容，另一方面为未来消费端迁移做好准备。双注册的开关可通过
-Ddubbo.application.register-mode=al/interface/interface控制，我们推荐保持双注册的默认行为以减少后续迁移成本。
+
+大家可能担心双注册给注册中心带来的存储压力，实际上在应用级服务发现模型下这并不是一个问题，因为大家如果回想前面我们对应用级服务发现工作原理的分析，注册地址已经被大幅精简，根据我们实际推算，每多注册一条应用级服务发现
URL 地址，只会增加 0.1% ～ 1% 的额外开销。
+
+
+
+与提供端类似，要实现平滑迁移消费端也要经历双订阅的过程，流程上就不再赘述。消费端的双订阅行为也可通过规则或开关进行动态调整，控制消费端的消费的某个服务、应用迁移到应用级地址模型；除此之外，Dubbo3
还内置了自动决策机制，在发现应用级地址可用的情况下即会自动完成切换，并且这个行为是默认的。
+
+以下是消费端双订阅时的选址流程：
+
+
+
+### 升级效果
+
+
+
+饿了么成功升级 Dubbo3 及应用级服务发现模型，实现了去 proxy 架构的目标，在我们关心的服务发现数据链路上：
+* 数据注册与订阅的传输量下降 90%
+* 注册中心数据存储的总体资源占用下降 90%
+* 消费端服务框架自身的常驻内存消耗下降达 50%
+集群总体的稳定性、性能都得到明显提升，也为未来容量扩展做好准备。
+
+
+
+
+
+
+
diff --git a/content/zh/users/fenghuodi.md b/content/zh/users/fenghuodi.md
new file mode 100644
index 0000000000..fe078e4cf5
--- /dev/null
+++ b/content/zh/users/fenghuodi.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "烽火递 Dubbo3 实践"
+linkTitle: "烽火递"
+weight: 6
+---
+Coming Soon ...
\ No newline at end of file
diff --git a/content/zh/users/icbc.md b/content/zh/users/icbc.md
index 745974d6c4..2ec4adfe36 100644
--- a/content/zh/users/icbc.md
+++ b/content/zh/users/icbc.md
@@ -1,7 +1,27 @@
---
type: docs
-title: "阿里巴巴"
-linkTitle: "阿里巴巴"
+title: "工商银行 Dubbo3 应用级服务发现实践"
+linkTitle: "工商银行"
weight: 2
-description: Dubbo 用户案例分享，涵盖最新 3.0 版本
----
\ No newline at end of file
+---
+
+### 问题分析
+以下是经典的 Dubbo 的工作原理图，服务提供者和消费者通过注册中心协调实现地址的自动发现。
+
+
+
+工商银行面临的主要瓶颈是在注册中心与服务消费端，接口级别地址的数量已经是亿级规模，一方面存储容量达到瓶颈、另一方面推送效率明显下降；而在消费端这一侧，Dubbo2
框架常驻内存已超 40%，每次地址推送带来的 cpu 等资源消耗率也非常高，影响正常的业务调用。
+
+这是 Dubbo2
接口级服务发现架构在大规模集群场景下的固有问题（具体原因请查看应用级服务发现原理解析），通过常规的性能优化无法从根本上解决问题。因此工商银行采用了
Dubbo3 中提出的应用级服务发现模型，经过实测，新的服务发现模型能实现节点到注册中心间数据传输量 90%
的下降，这就使得注册中心的压力极大降低，同时消费端的框架常驻内存也实现超 50% 下降。
+
+### 压测数据
+下面是工商银行联合 Dubbo 社区给出的一组基于真实服务特点给出的模拟压测数据。
+
+
+
+上图是对使用了应用级服务发现的消费端进程采样的内存对比数据。其中横轴是不同的 Dubbo 版本，纵轴是实际采样到的内存表现，可以看到 Dubbo
2.6、2.7 版本表现几乎一致，而升级到 3.0 版本后，即使不升级应用级服务发现，内存也降低接近
40%，而当切换到应用级服务发现之后，内存占用下降到只有原来的 30%。
+
+
+
+上图是消费端的 GC 情况统计，同样的，横轴是不同的 Dubbo 版本，纵轴是实际采样到的 GC
表现。这里的压测数据，是通过模拟注册中心不停的往消费端进程推送地址列表的场景得到的。可以看到 Dubbo 2.6、2.7 版本表现几乎一致，而在 3.0
版本中切换到应用级服务发现之后，GC 已经趋近于零次。
+
diff --git a/content/zh/users/pingan.md b/content/zh/users/pingan.md
new file mode 100644
index 0000000000..4807373ed8
--- /dev/null
+++ b/content/zh/users/pingan.md
@@ -0,0 +1,8 @@
+---
+type: docs
+title: "平安健康的 Dubbo3 迁移历程"
+linkTitle: "平安健康"
+weight: 5
+---
+
+Coming Soon ...
\ No newline at end of file
diff --git a/content/zh/users/xiaomi.md b/content/zh/users/xiaomi.md
index 4b67996f0d..0507482360 100644
--- a/content/zh/users/xiaomi.md
+++ b/content/zh/users/xiaomi.md
@@ -1,7 +1,77 @@
---
type: docs
-title: "小米"
+title: "小米与 Dubbo 社区的合作"
linkTitle: "小米"
-weight: 3
-description: Dubbo 用户案例分享，涵盖最新 3.0 版本
----
\ No newline at end of file
+weight: 4
+---
+
+小米一直在积极拥抱开源社区并提交贡献，参与Dubbo3建设发布以来，在内部业务也积极推进升级工作，目前实例数已经升级到了一定的比例
。升级过程总体平稳，稳定性指标正常，性能提升明显，率先升级完成的应用更早拥有了mesh化的条件。从升级后的数据表现来看，Dubbo3改变以往接口粒度的注册发现方式为应用粒度的注册发现方式，这样带来了注册中心存储和运行的更稳定，降低运维成本；使用protobuf协议进行序列化与反序列化，性能和字节大小均提升数量级；完全兼容gprc，给小米这样多言语并存的服务环境带来了极大便利。
+
+Xiaomi is devoted to making continuous contribution to the open source
community. Since the introduction of Dubbo3, internal projects are rapidly
upgrading to the latest version of Dubbo. Currently, At present the numbers of
instances has been upgrade to a certain proportion. Not only performance
improvements have been seen, but services are also running smoothly with
improvements in availability. Statistics provide proof that Dubbo’s switch from
api-level discovery to application-level [...]
+
+Dubbo3 基于 Dubbo2 演进而来，Dubbo3 在云原生基础设施适配、服务注册发现、面向下一代协议设计等几大方向上进行了全面升级。并且往 3.0
版本的升级过程将会是完全透明的，用户无需做任何业务改造，就可以直接升级到 Dubbo 3.0。
+下面从云原生适配、全新服务发现模型、通信协议、升级兼容四个方面详细介绍。
+
+Having evolved from Dubbo2, Dubbo3 is a major upgrade in several areas
including, Cloud Native adaptation, service discovery, communication protocols.
Furthermore, upgrading to version 3.0 requires no changes in application code.
The following is a detailed introduction to Dubbo3’s features.
+
+### 云原生适配 Cloud Native Adaptation
+Dubbo3从理念到设计再到实现最大的变革之一在于全面遵循云原生环境，做到了面向未来，为了达到这个目标dubbo本身做了相当重要的取舍。
+在“取”这个层面，Dubbo3众多核心组件已经面向云原生升级，支持 Kubernetes
平台调度，实现了服务生命周期与容器生命周期的对齐，Serverless、Native Image等机制都在计划之中。
+
+在“舍”这个层面，Dubbo3割舍了以往要求开发人员遵守并熟知的Dubbo启动、销毁、注册等生命周期事件，Dubbo3自身设配了Kubernetes基础设施定义的生命周期事件(probe)，并且将服务的定义与注册下沉到了Kubernetes
Service，重新划定了dubbo和k8s基础设施的边界。
+
+To be future proof, the design and development of Dubbo3 has fully adapted
Cloud Native. To meet this goal, Dubbo has made some trade-offs.Several core
components of Dubbo3 support Kubernetes. In particular, Dubbo3 implements
Kubernetes service and container life-cycle. Serverless and native image
support will be release in the future.
+
+To support Kubernetes, Dubbo3 places service registration and discovery down
to the Kubernetes Service layer, thus reestablishing the boundary between Dubbo
and Kubernetes. However, this requires deprecating Dubbo’s own service
discovery events.
+
+### 全新服务发现模型 New Service Discovery Model
+Dubbo以往版本与Spring
Cloud、gRPC等同属主流的服务框架进行服务发现的粒度不一致，Dubbo选择了基于更细粒度的接口来进行服务发现，Dubbo3.x进行了服务发现机制的对齐，即以应用粒度来进行服务发现，应用粒度的机制也带来了几点好处：
+
+1. 打通与其他异构微服务体系的地址互发现障碍，这一点对于小米这样的多语种多框架并存的技术组织非常重要。
+2. 提升了 Dubbo3 在大规模集群实践中的性能与稳定性。新模型可大幅提高系统资源利用率，降低 Dubbo
地址的单机内存消耗近一半，降低注册中心集群的存储与推送压力一半以上， Dubbo 可支持集群规模步入百万实例层次。
+
+Previous versions of Dubbo differs from other mainstream service discovery
middle-ware such as Spring Cloud and gRPC in its service discovery granularity.
In the past Dubbo discovers services at the API level. Dubbo3, however,
utilizes application level service discovery. This provides the following
benefits.
+
+1. Eliminates incompatibility issues with other service discovery platforms,
which is crucial since Xiaomi has diverse languages and development frameworks.
+2. The new service discovery model improves resource utilization, lowers Dubbo
address’s single machine memory usage, lowers service discover cluster’s load.
+
+### 全新RPC 通信协议 New RPC Communication Protocal
+定义了全新的 RPC 通信协议 – Triple，它是基于 HTTP/2 上构建的 RPC 协议。 使用 Triple 协议，用户将获得以下能力：
+
+1. 完全兼容gRPC，能够更友好的支持跨语言跨框架的微服务进行互通。
+2. 支持Protobuf进行序列化与反序列化，性能和字节大小均提升数量级。
+
+Introduction of a new RPC communication protocol based on HTTP/2 called
Triple. Using Triple has the following benefits.
+
+1. Complete compatibility with gRPC.
+2. Protobuf support for serialization and deserialization.
+
+### 升级与兼容性 Upgrade and Backwards Compatibility
+对业务而言，在保证兼容以往版本的前提下进行升级是最核心的问题，在 3.0 版本的设计与开发之初，就定下了兼容老版本 Dubbo
用户（2.5、2.6、2.7）的目标。因此，往 3.0 版本的升级过程将会是完全透明的，用户无需做任何业务改造，升级 3.x 后的框架行为将保持与 2.x
版本完全一致。
+
+但也要注意，透明升级仅仅是通往 3.0 的第一步，因为 “框架行为保持一致” 也就意味着用户将无法体验到 3.0 的新特性。如果要启用 3.0
带来的新特性，用户则需要进行一定的改造，这个过程称为迁移，这是一个按需开启的过程。
+因此，对老用户而言，有两条不同的迁移路径：
+
+1. 分两步走，先以兼容模式推动业务升级到 3.0 版本（无需改造），之后在某些时机按需启用新特性（按需改造）；
+2. 升级与迁移同步完成，在业务升级到 3.0 版本的同时，完成改造并启用新特性；
+
+第一种方式更安全，第二种方式更彻底，业务可根据自身的情况来进行评判选择。
+
+For production systems, upgrading a dependency while maintaining backward
compatibility is challenging. Supporting users of older versions of Dubbo (2.5,
2.6, 2,7) is a goal of Dubbo3’s design and development. Thus, upgrading to
Dubbo3 is painless. No changes are required to be made to existing production
systems. However to use Dubbo3’s new features, additional changes are needed to
existing code. Thus, there are two suggested upgrade paths.
+
+1. Upgrade to Dubbo3 but do not use Dubbo3’s new features. This path requires
no code changes.
+2. Upgrade to Dubbo3 while making additional changes to support the new
features.
+
+### 建议
+1. dubbo3已经和云原生做了深度适配，建议后续能够和istio等service
mesh框架进行更多的衔接打通，方便dubbo用户更简单的走向mesh化之路；
+2. 建议在调用方和服务方调用链路上增加更多的可选可观测点；
+
+Suggestions
+1. Since Dubbo3 is closely compatible with Cloud Native, further work can be
done to enhance Dubbo’s support of istio and other service mesh frameworks to
speed up Dubbo users’ adaption of service mesh.
+2. Add more performance metrics to monitor Dubbo consumers and providers.
+
+### 作者
+* 张志勇
+* 张平
+* 许铮
+
diff --git a/static/imgs/user/eleme/elem-arc.png
b/static/imgs/user/eleme/elem-arc.png
new file mode 100644
index 0000000000..74d0ad7cf3
Binary files /dev/null and b/static/imgs/user/eleme/elem-arc.png differ
diff --git a/static/imgs/user/eleme/elem-result.png
b/static/imgs/user/eleme/elem-result.png
new file mode 100644
index 0000000000..6faa075d8d
Binary files /dev/null and b/static/imgs/user/eleme/elem-result.png differ
diff --git a/static/imgs/user/eleme/elem-upgrade-consumer.png
b/static/imgs/user/eleme/elem-upgrade-consumer.png
new file mode 100644
index 0000000000..96d5df5bb3
Binary files /dev/null and b/static/imgs/user/eleme/elem-upgrade-consumer.png
differ
diff --git a/static/imgs/user/eleme/elem-upgrade-consumer1.png
b/static/imgs/user/eleme/elem-upgrade-consumer1.png
new file mode 100644
index 0000000000..82f8bff250
Binary files /dev/null and b/static/imgs/user/eleme/elem-upgrade-consumer1.png
differ
diff --git a/static/imgs/user/eleme/elem-upgrade-provider.png
b/static/imgs/user/eleme/elem-upgrade-provider.png
new file mode 100644
index 0000000000..3d26b4d800
Binary files /dev/null and b/static/imgs/user/eleme/elem-upgrade-provider.png
differ
diff --git a/static/imgs/user/eleme/elem-upgrade1.png
b/static/imgs/user/eleme/elem-upgrade1.png
new file mode 100644
index 0000000000..3e6a92dc16
Binary files /dev/null and b/static/imgs/user/eleme/elem-upgrade1.png differ
diff --git a/static/imgs/user/icbc/icbc-analyze.png
b/static/imgs/user/icbc/icbc-analyze.png
new file mode 100644
index 0000000000..5a50f82668
Binary files /dev/null and b/static/imgs/user/icbc/icbc-analyze.png differ
diff --git a/static/imgs/user/icbc/icbc-data1.png
b/static/imgs/user/icbc/icbc-data1.png
new file mode 100644
index 0000000000..a8203b56d7
Binary files /dev/null and b/static/imgs/user/icbc/icbc-data1.png differ
diff --git a/static/imgs/user/icbc/icbc-data2.png
b/static/imgs/user/icbc/icbc-data2.png
new file mode 100644
index 0000000000..7a7e08ef8d
Binary files /dev/null and b/static/imgs/user/icbc/icbc-data2.png differ
