This is an automated email from the ASF dual-hosted git repository.
albumenj pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-website.git
The following commit(s) were added to refs/heads/master by this push:
new 34ed8c2a1ae [fix] optimization (#1378)
34ed8c2a1ae is described below
commit 34ed8c2a1ae6a01cd8e2427b8bed01294793b976
Author: JM <[email protected]>
AuthorDate: Sun Aug 14 10:52:27 2022 +0800
[fix] optimization (#1378)
---
.../java-sdk/concepts-and-architecture/service-discovery.md | 6 ++++--
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git
a/content/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery.md
b/content/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery.md
index 53dbd401b14..6ad80d2540c 100644
---
a/content/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery.md
+++
b/content/zh/docs3-v2/java-sdk/concepts-and-architecture/service-discovery.md
@@ -6,8 +6,10 @@ weight: 3
---
服务发现，即消费端自动发现服务地址列表的能力，是微服务框架需要具备的关键能力，借助于自动化的服务发现，微服务之间可以在无需感知对端部署位置与 IP
地址的情况下实现通信。
+### 实现方式
实现服务发现的方式有很多种，Dubbo 提供的是一种 Client-Based
的服务发现机制，通常还需要部署额外的第三方注册中心组件来协调服务发现过程，如常用的 Nacos、Consul、Zookeeper 等，Dubbo
自身也提供了对多种注册中心组件的对接，用户可以灵活选择。
+### 工作原理
Dubbo 基于消费端的自动服务发现能力，其基本工作原理如下图：
@@ -24,7 +26,7 @@ dubbo
address: zookeeper://127.0.0.1:2181
```
-## 应用级服务发现简介
+### 应用级服务发现简介
概括来说，Dubbo3 引入的应用级服务发现主要有以下优势
* 适配云原生微服务变革。云原生时代的基础设施能力不断向上释放，像 Kubernetes 等平台都集成了微服务概念抽象，Dubbo3
的应用级服务发现是适配各种微服务体系的通用模型。
* 提升性能与可伸缩性。支持超大规模集群的服务治理一直以来都是 Dubbo
的优势，通过引入应用级服务发现模型，从本质上解决了注册中心地址数据的存储与推送压力，相应的 Consumer
侧的地址计算压力也成数量级下降；集群规模也开始变得可预测、可评估（与 RPC 接口数量无关，只与实例部署规模相关）。
@@ -54,4 +56,4 @@ Dubbo3 服务发现模型更适合构建可伸缩的服务体系，这点要如
对于 Dubbo3 来说，新的注册发现模型只需要 1 个服务（只和应用有关和接口无关）， 只注册和机器实例数相等的 1 * 100 = 100
个虚拟节点到注册中心。
在这个简单的示例中，Dubbo 所注册的地址数量下降到了原来的 1 / 100，对于注册中心、订阅方的存储压力都是一个极大的释放。更重要的是，
地址发现容量彻底与业务 RPC 定义解耦开来，整个集群的容量评估对运维来说将变得更加透明：部署多少台机器就会有多大负载，不会像 Dubbo2 一样，
-因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
\ No newline at end of file
+因为业务 RPC 重构就会影响到整个集群服务发现的稳定性。
