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 cc586fb3ba add metadata docs (#1327)
cc586fb3ba is described below
commit cc586fb3bac1d8aee8454e67e0ff9fc6e701f325
Author: ken.lj <[email protected]>
AuthorDate: Tue Aug 2 19:15:59 2022 +0800
add metadata docs (#1327)
---
.../reference-manual/config-center/_index.md | 6 +-
.../config-center/apollo/_index.md | 58 +-
.../reference-manual/config-center/nacos/_index.md | 20 +-
.../config-center/zookeeper/_index.md | 35 +-
.../reference-manual/config/properties/_index.md | 7 +-
.../metadata-center/nacos/_index.md | 383 ++-----------
.../metadata-center/overview/_index.md | 633 ++++-----------------
.../metadata-center/redis/_index.md | 3 +-
.../metadata-center/zookeeper/_index.md | 172 +++++-
.../reference-manual/performance/benchmarking.md | 62 +-
.../{benchmarking.md => rpc-benchmarking.md} | 67 +--
.../spi/description/metadata-report.md | 91 +++
12 files changed, 507 insertions(+), 1030 deletions(-)
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/_index.md
index b7757bd786..0c2439b3a3 100644
--- a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/_index.md
+++ b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/_index.md
@@ -6,7 +6,7 @@ weight: 7
description: ""
---
-配置中心 (config-center) 在 Dubbo 中可承担 3 个职责：
+配置中心 (config-center) 在 Dubbo 中可承担两类职责：
1. [外部化配置](../config/principle/#33-外部化配置)：启动配置的集中式存储 （简单理解为 dubbo.properties
的外部化存储）。
2. 流量治理规则存储
@@ -15,9 +15,9 @@ description: ""
值得注意的是 Dubbo 动态配置中心定义了两个不同层次的隔离选项，分别是 namespce 和 group。
* namespace - 配置命名空间，默认值
`dubbo`。命名空间通常用于多租户隔离，即对不同用户、不同环境或完全不关联的一系列配置进行逻辑隔离，区别于物理隔离的点是不同的命名空间使用的还是同一物理集群。
-* group - 配置分组，默认值 `dubbo`。`group` 通常用于归类一组相同类型/目的的配置项，是对 `namespace` 下的进一步隔离。
+* group - 配置分组，默认值 `dubbo`。`group` 通常用于归类一组相同类型/目的的配置项，是对 `namespace`
下配置项的进一步隔离。
-参考 [配置中心配置项手册](../config/properties/#config-center) 了解 namespce 和 group 之外
config-center 开放的更多配置项。
+参考 [配置说明 - 配置项手册](../config/properties/#config-center) 了解 namespce 和 group 之外
config-center 开放的更多配置项。
> 为了兼容 2.6.x 版本配置，在使用 Zookeeper 作为注册中心，且没有显示配置配置中心的情况下，Dubbo 框架会默认将此 Zookeeper
> 用作配置中心，但将只作服务治理用途。
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/apollo/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/apollo/_index.md
index 6cf5f2f474..e0d92100c7 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/apollo/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/apollo/_index.md
@@ -60,40 +60,56 @@ configCenter.setAddress("apollo://localhost:8080");
```
## 3 高级配置
+Apollo中的一个核心概念是命名空间 - namespace，和上面 Zookeeper、Nacos 的 namespace
概念不同，因此使用方式上也比较特殊些，建议充分了解 Apollo 自身的用法后再阅读以下文档内容。
+
+但总的来说，对 Apollo 的适配而言：
+* namespace 特用于流量治理规则隔离，参见 3.1
+* group 特用于外部化配置的隔离，参见 3.2
+
+### 3.1 外部化配置
-### 3.1 配置隔离
```xml
-<dubbo:config-center protocol="apollo" address="127.0.0.1:2181"/>
+<dubbo:config-center group="demo-provider" address="apollo://localhost:8080"/>
```
-Apollo中的一个核心概念是命名空间 -
namespace（和上面zookeeper的namespace概念不同），在这里全局和应用级别配置就是通过命名空间来区分的。
-
-默认情况下，Dubbo会从名叫`dubbo`（由于 Apollo 不支持特殊后缀 `.properties`
）的命名空间中读取全局配置（`<dubbo:config-center namespace="your namespace">`）
+config-center 的 `group` 决定了 Apollo 读取外部化配置 `dubbo.properties` 文件的位置：
+1. 如果 group 为空，则默认从 `dubbo` namespace 读取配置，用户须将外部化配置写在 `dubbo` namespace 下。
+2. 如果 group 不为空
+ 2.1 group 值为应用名，则从应用当前的 namespace 读取配置，用户须将外部化配置写在 Apollo 自动指定的应用默认
namespace 下。
+ 2.2 group 值为任意值，则从对应的 namespace 读取配置，用户须将外部化配置写在该 namespace 下。
+如以下示例是用的默认 group='dubbo' 的全局外部化配置，即该配置可被所有应用读取到。
-由于 Apollo 也默认将会在 `dubbo` namespace 中存储服务治理规则（如路由规则），建议通过单独配置 `group`
将服务治理和配置文件托管分离开，以 XML 配置方式为例：
-```xml
-<dubbo namespace="governance" group ="dubbo"/>
-```
-这里，服务治理规则将存储在 governance namespace，而配置文件将存储在 dubbo namespace，如下图所示：
-
+如果配置 group='应用名' 则是应用特有配置，只有该应用可以读取到。
-> 关于文件配置托管，相当于是把 `dubbo.properties` 配置文件的内容存储在了 Apollo 中，应用通过关联共享的 `dubbo`
namespace 继承公共配置,
-> 应用也可以按照 Apollo 的做法来覆盖个别配置项。
+> 关于外部化文件配置托管，相当于是把 `dubbo.properties` 配置文件的内容存储在了 Apollo 中。每个应用都可以通过关联共享的
`dubbo` namespace 继承公共配置, 进而可以单独覆盖个别配置项。
-## 4 工作原理
+### 3.2 流量治理规则
+**流量治理规则一定都是全局共享的，因此每个应用内的 namespace 配置都应该保持一致。**
-所有的服务治理规则都是全局性的，默认从公共命名空间 `dubbo` 读取和订阅：
+```xml
+<dubbo:config-center namespace="governance" address="apollo://localhost:8080"/>
+```
-
+config-center 的 `namespace` 决定了 Apollo 存取 `流量治理规则` 的位置：
+1. 如果 namespace 为空，则默认从 `dubbo` namespace 存取配置，须治理规则写在 `dubbo` namespace 下。
+2. 如果 namespace 不为空，则从对应的 namespace 值读取规则，须治理规则写在该 namespace 下。
-不同的规则以不同的 key 后缀区分：
+如以下示例是通过 `namespace='governance'` 将流量治理规则放在了 `governance` namespace 下。
+
-- configurators，[覆盖规则](../../examples/config-rule)
-- tag-router，[标签路由](../../examples/routing-rule)
-- condition-router，[条件路由](../../examples/condition-router)
-- migration, [迁移规则](../../examples/todo)
+### 3.3 更多 Apollo 特有配置
+当前 Dubbo 适配了 env、apollo.meta、apollo.cluster、apollo.id 等特有配置项，可通过 config-center
的扩展参数进行配置。
+如
+```properties
+dubbo.config-center.address=apollo://localhost:8080
+```
+或者
+```properties
+dubbo.config-center.prameters.apollo.meta=xxx
+dubbo.config-center.prameters.env=xxx
+```
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/nacos/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/nacos/_index.md
index c3f5513314..5b457c64e8 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/nacos/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/nacos/_index.md
@@ -64,7 +64,7 @@ dubbo
-dataId 是 `dubbo.properties`，group 分组与 config-center 保持一致，如未设置则默认是 `dubbo`。
+dataId 是 `dubbo.properties`，group 分组与 config-center 保持一致，如未设置则默认填 `dubbo`。
#### 3.1.2 应用特有外部化配置
@@ -82,7 +82,7 @@ dubbo
-dataId 是 `dubbo.properties`，group 分组为应用名即 `demo-provider`。
+dataId 是 `dubbo.properties`，group 分组设置为应用名即 `demo-provider`。
### 3.2 设置 group 与 namespace
```yaml
@@ -91,22 +91,24 @@ dubbo
address: zookeeper://127.0.0.1:2181
group: dubbo-cluster1
namespace: dev1
-```
+``
对配置中心而言，`group` 与 `namespace` 应该是全公司（集群）统一的，应该避免不同应用使用不同的值。
-## 4 工作原理
+### 3.3 Nacos 扩展配置
+更多 Nacos sdk/server 支持的参数配置请参见 [Nacos 注册中心 -
更多配置](../../registry/nacos/#3.5-更多配置)
+
+## 4 流量治理规则
对 Nacos 而言，所有流量治理规则和外部化配置都应该是全局可见的，因此相同逻辑集群内的应用都必须使用相同的 namespace 与
group。其中，namespace 的默认值是 `public`，group 默认值是 `dubbo`，应用不得擅自修改 namespace 与
group，除非能保持全局一致。
-### 4.1 流量治理规则
+流量治理规则的增删改建议通过 dubbo-admin 完成，更多内容可查看 [Dubbo 支持的流量治理能力]()。
流量治理规则有多种类型，不同类型的规则 dataId 的后缀是不同的：
-- configurators，[覆盖规则](../../examples/config-rule)
-- tag-router，[标签路由](../../examples/routing-rule)
-- condition-router，[条件路由](../../examples/condition-router)
-- migration, [迁移规则](../../examples/todo)
+- configurators，[覆盖规则](../../../advanced-features-and-usage/rpc/config-rule/)
+-
tag-router，[标签路由](../../../advanced-features-and-usage/service/routing/routing-rule/#标签路由)
+-
condition-router，[条件路由](../../../advanced-features-and-usage/service/routing/routing-rule/#条件路由)
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/zookeeper/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/zookeeper/_index.md
index 95c5998d4b..7b78b22032 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/config-center/zookeeper/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/config-center/zookeeper/_index.md
@@ -49,7 +49,8 @@ configCenter.setAddress("zookeeper://127.0.0.1:2181");
## 3 高级配置
如要开启认证鉴权，请参考 [zookeeper 注册中心 - 启用认证鉴权](../../registry/zookeeper/#31-认证与鉴权)
-### 3.1 外部化配置
+### 3.1 定制外部化配置 key
+**1. 启用外部化配置，并指定 key**
```yaml
dubbo
config-center
@@ -59,20 +60,7 @@ dubbo
`config-file` - 外部化配置文件 key 值，默认 `dubbo.properties`。`config-file` 代表将 Dubbo
配置文件存储在远端注册中心时，文件在配置中心对应的 key 值，通常不建议修改此配置项。
-### 3.1 设置 group 与 namespace
-```yaml
-dubbo
- config-center
- address: zookeeper://127.0.0.1:2181
- group: dubbo-cluster1
- namespace: dev1
-```
-
-对配置中心而言，`group` 与 `namespace` 应该是全公司（集群）统一的，应该避免不同应用使用不同的值。
-
-## 4 工作原理
-
-### 4.1 外部化配置
+**2. Zookeeper 配置中心增加配置**
外部化配置的存储结构如下图所示
@@ -82,8 +70,21 @@ dubbo
- dubbo 与 application，分别用来隔离全局配置、应用级别配置：dubbo 是默认 group 值，application 对应应用名
- dubbo.properties，此节点的node value存储具体配置内容
-### 4.2 流量治理规则
-所有流量治理规则默认都存储在 `/dubbo/config` 节点下，具体节点结构图如下：
+> 这里是为了说明工作原理，建议使用 dubbo-admin 进行配置管理。
+
+### 3.2 设置 group 与 namespace
+```yaml
+dubbo
+ config-center
+ address: zookeeper://127.0.0.1:2181
+ group: dubbo-cluster1
+ namespace: dev1
+```
+
+对配置中心而言，`group` 与 `namespace` 应该是全公司（集群）统一的，应该避免不同应用使用不同的值，外部化配置和治理规则也应该存放在对应的
group 与 namespace。
+
+## 4 流量治理规则
+所有流量治理规则默认都存储在 `/dubbo/config` 节点下，具体节点结构图如下。流量治理规则的增删改建议通过 dubbo-admin
完成，更多内容可查看 [Dubbo 支持的具体流量治理能力]()
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/config/properties/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/config/properties/_index.md
index 96a5a3403d..8f0bb2550d 100644
--- a/content/zh/docs3-v2/java-sdk/reference-manual/config/properties/_index.md
+++ b/content/zh/docs3-v2/java-sdk/reference-manual/config/properties/_index.md
@@ -180,7 +180,7 @@ description: "包含 Dubbo 支持的所有配置组件及每个配置组件支
| parameters | parameters | Map<string, string> | 可选 |
| 扩展参数，用来支持不同配置中心的定制化配置参数 | 2.7.0以上版本 |
| includeSpringEnv |include-spring-env| boolean | 可选 | false
| 使用Spring框架时支持，为true时，会自动从Spring Environment中读取配置。<br />默认依次读取<br
/>key为dubbo.properties的配置<br />key为dubbo.properties的PropertySource | 2.7.0以上版本 |
-### metadata-config
+### metadata-report-config
元数据中心。对应的配置类：`org.apache.dubbo.config.MetadataReportConfig`
@@ -200,8 +200,9 @@ description: "包含 Dubbo 支持的所有配置组件及每个配置组件支
| cluster | cluster | string | 可选 | |
含义视所选定的元数据中心而不同。<br />如Apollo中用来区分不同的配置集群 | 2.7.0以上版本 |
| file | file | string | 可选 | |
使用文件缓存元数据中心列表，应用重启时将基于此文件恢复，注意：两个元数据中心不能使用同一文件存储 | 2.7.0以上版本 |
| check | check | boolean | 可选 | true |
当元数据中心连接失败时，是否终止应用启动。 | 3.0.0以上版本 |
-| reportMetadata | report-metadata | boolean | 可选 | false |
当元数据存储类型为本地(`metadataType=local`)时，是否同步元数据到元数据中心 | 3.0.0以上版本 |
-| reportDefinition | report-definition | boolean | 可选 | true | 是否上报接口级别元数据
| 3.0.0以上版本 |
+| reportMetadata | report-metadata | boolean | 可选 | false |
是否上地址发现中的接口配置报元数据，`dubbo.application.metadata-type=remote`
该配置不起作用即一定会上报，`dubbo.application.metadata-type=local` 时是否上报由该配置值决定 | 3.0.0以上版本 |
+| reportDefinition | report-definition | boolean | 可选 | true | 是否上报服务运维用元数据
| 3.0.0以上版本 |
+| reportConsumerDefinition | report-consumer-definition | boolean | 可选 | true
| 是否在消费端上报服务运维用元数据 | 3.0.0以上版本 |
| parameters | parameters | Map<string, string> | 可选 | |
扩展参数，用来支持不同元数据中心的定制化配置参数 | 2.7.0以上版本 |
### protocol
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/nacos/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/nacos/_index.md
index e62f86cf01..af8f758367 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/nacos/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/nacos/_index.md
@@ -2,236 +2,65 @@
type: docs
title: "Nacos"
linkTitle: "Nacos"
-weight: 3
-description: ""
+weight: 2
+description: "Nacos 元数据中心基本使用与工作原理"
---
-
-#简单介绍
-Dubbo
provider中的服务配置项有接近[30个配置项](https://dubbo.apache.org/zh/docs/references/xml/dubbo-provider/)
。
排除注册中心服务治理需要之外，很大一部分配置项是provider自己使用，不需要透传给消费者。这部分数据不需要进入注册中心，而只需要以key-value形式持久化存储。
-
-Dubbo
consumer中的配置项也有[20+个配置项](https://dubbo.apache.org/zh/docs/references/xml/dubbo-consumer/)
。在注册中心之中，服务消费者列表中只需要关注application、version、group、ip、dubbo版本等少量配置，其他配置也可以以key-value形式持久化存储。
-
-这些数据是以服务为维度注册进入注册中心，导致了数据量的膨胀，进而引发注册中心(如nacos)的网络开销增大，性能降低。
-
-除了上述配置项的存储之外，Dubbo服务元数据信息也需要被存储下来。元数据信息包括服务接口列表和接口的方法信息，这些信息将被用于服务mock和服务测试。
-
-使用Dubbo`3.0.0`及以上版本时，引入了应用元数据的概念，并且引入了服务自省映射，用于应用级别的服务发现。
-
-# 预备工作
--
了解[Dubbo基本开发步骤](https://dubbo.apache.org/zh/docs3-building/java-sdk/quick-start/spring-boot/)
-- 启动nacos server，请参考[nacos快速入门](https://nacos.io/zh-cn/docs/quick-start.html)
+## 1 预备工作
+- 了解 [Dubbo
基本开发步骤](https://dubbo.apache.org/zh/docs3-building/java-sdk/quick-start/spring-boot/)
+- 参考 [Nacos快速入门](https://nacos.io/zh-cn/docs/quick-start.html) 启动 Nacos server
> 当Dubbo使用`3.0.0`及以上版本时，需要使用Nacos `2.0.0`及以上版本
-# 快速上手
-Dubbo 融合 Nacos 成为元数据中心的操作步骤非常简单，大致分为“增加 Maven 依赖”以及“配置元数据中心”两步。
+## 2 使用说明
+Dubbo 融合 Nacos 成为元数据中心的操作步骤非常简单，大致分为 `增加 Maven 依赖` 以及 `配置元数据中心` 两步。
> 如果元数据地址(dubbo.metadata-report.address)也不进行配置，会使用注册中心的地址来用作元数据中心。
-## 增加Maven依赖
-只需要将dubbo-metadata-report-nacos的Maven依赖添加到pom.xml文件中即可。
+### 2.1 增加 Maven 依赖
+如果项目已经启用 Nacos 作为注册中心，则无需增加任何额外配置。
-引入dubbo-metadata-report-nacos会自动引入dubbo-configcenter-nacos，将元数据放到配置中心。
+如果未启用 Nacos 注册中心，则请参考 [为注册中心增加 Nacos 依赖](../../registry/nacos/#21-增加依赖)。
-Dubbo`3.0.0`及以上版本，dubbo-metadata-report-nacos引入nacos-client版本为`2.0.0`及以上版本。
+### 2.2 启用 Nacos 配置中心
```xml
-<dependencies>
- ...
- <!-- Dubbo Nacos Metadata Report dependency -->
- <dependency>
- <groupId>org.apache.dubbo</groupId>
- <artifactId>dubbo-metadata-report-nacos</artifactId>
- <version>3.0.7</version>
- </dependency>
-
- <!-- Dubbo dependency -->
- <dependency>
- <groupId>org.apache.dubbo</groupId>
- <artifactId>dubbo</artifactId>
- <version>3.0.7</version>
- </dependency>
- ...
-</dependencies>
+<dubbo:metadata-report address="nacos://127.0.0.1:8848"/>
```
-## 配置元数据中心
-如果Dubbo使用 Spring Framework 装配，有三种配置方法分别为：
-- [Dubbo Spring 外部化配置](#method1)
-- [Spring XML 配置文件](#method2)
-- [API配置](#method3)
-
-### <a id="method1">Dubbo Spring外部化配置</a>
-Dubbo Spring 外部化配置是由 Dubbo 2.5.8引入的新特性，可通过 Spring Environment 属性自动地生成并绑定 Dubbo
配置 Bean，实现配置简化，并且降低微服务开发门槛。
-
-当Dubbo使用Nacos为注册中心，假设启动服务器IP为：10.20.153.10，端口号为：8848，则在Dubbo外部化配置文件中添加以下配置：
-
-```properties
-## application
-dubbo.application.name=your-dubbo-application
-
-## Nacos Metadata Report address
-dubbo.metadata-report.address=nacos://10.20.153.10:8848
-
-##如果要使用其他参数，可以使用以下2种方式
-#第一种方式
-#dubbo.metadata-report.address=nacos://10.20.153.10:8848?username=nacos&password=nacos&namespace=5cbb70a5-xxx-xxx-xxx-d43479ae0932&group=demo
-
-#第二种方式
-#dubbo.metadata-report.address=nacos://10.20.153.10:8848
-#dubbo.metadata-report.username=nacos
-#dubbo.metadata-report.password=nacos
-#dubbo.metadata-report.parameters.namespace=5cbb70a5-xxx-xxx-xxx-d43479ae0932
-#dubbo.metadata-report.group=demo
-...
+或者
+```yaml
+dubbo
+ metadata-report
+ address: nacos://127.0.0.1:8848
```
-可配置的参数参考完整配置项说明
->
Dubbo`3.0.0`版本以后，增加了是否注册消费者的元数据，如果需要将消费者元数据存放到nacos元数据中心上，需要将参数(report-consumer-definition)设置为true，默认是false。
+或者
-设置方式如下：
```properties
- ##设置是否注册消费者的参数，可以使用以下2种方式
- #第一种方式
-
#dubbo.registry.address=nacos://10.20.153.10:8848?report-consumer-definition=true
-
- #第二种方式
- #dubbo.registry.address=nacos://10.20.153.10:8848
- #dubbo.registry.parameters.report-consumer-definition=true
- ```
-随后，重启Dubbo应用，在Nacos的控制台上可看到服务提供者和消费者的应用级别以及接口级别元数据信息：
-
-
-
-#### 应用级别元数据
-
-应用级别元数据只有当一个应用定义服务之后，才会进行暴露。会根据当前应用的自身信息，以及接口信息，去计算出该应用的 revision
修订值，用于保存应用级别元数据。
-
->
在Dubbo`3.0.0`及以上版本中，引入了应用元数据的概念，应用元数据描述的是整个应用的信息概览。如需暴露应用级别元数据，需要将配置参数metadata-type设置为remote(默认为local)，或将参数reportMetadata设置为true(默认为false)。
-
-设置方式如下：
-```properties
- #设置是否暴露应用级别元数据，可以使用以下2种方式
- #第一种方式
- dubbo.metadata-report.address=nacos://10.20.153.10:8848
- dubbo.application.metadata-type=remote
-
- #第二种方式
- #dubbo.metadata-report.address=nacos://10.20.153.10:8848
- #dubbo.metadata-report.report-metadata=true
- #或
- #dubbo.metadata-report.address=nacos://10.20.153.10:8848?report-metadata=true
- ```
-元数据信息详情：
-
-
-
-#### 接口级别元数据
-
-在 Nacos 中，本身就存在配置中心这个概念，正好用于元数据存储。在配置中心的场景下，存在命名空间- namespace 的概念，在 namespace
之下，还存在 group 概念。即通过 namespace 和 group 以及 dataId 去定位一个配置项，在不指定 namespace
的情况下，默认使用 ```public``` 作为默认的命名空间。
-
-```properties
-Provider: namespace: 'public', dataId: '{service
name}:{version}:{group}:provider:{application name}', group: 'dubbo'
-Consumer: namespace: 'public', dataId: '{service
name}:{version}:{group}:consumer:{application name}', group: 'dubbo'
-```
-当 version 或者 group 不存在时`:` 依然保留:
-```properties
-Provider: namespace: 'public', dataId: '{service name}:::provider:{application
name}', group: 'dubbo'
-Consumer: namespace: 'public', dataId: '{service name}:::consumer:{application
name}', group: 'dubbo'
+dubbo.metadata-report.address=nacos://127.0.0.1:8848
```
-Providers接口元数据详情：
+或者
-
+```java
+MetadataReportConfig metadataConfig = new MetadataReportConfig();
+metadataConfig.setAddress("nacos://127.0.0.1:8848");
+```
-Consumers接口元信息详情：
+`address` 格式请参考 [Nacos 注册中心 - 启用配置](../../registry/nacos/#2.2-配置并启用-Nacos)
-
+## 3 高级配置
-### <a id="method2">Spring XML配置文件</a>
-同样，当Dubbo使用Nacos为注册中心，假设启动服务器IP为：10.20.153.10，端口号为：8848，则在Spring
Bean在XML文件中添加以下配置：
-
-```xml
-<?xml version="1.0" encoding="UTF-8"?>
-<beans xmlns="http://www.springframework.org/schema/beans";
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
- xsi:schemaLocation="http://www.springframework.org/schema/beans
- http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
- http://dubbo.apache.org/schema/dubbo
- http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
-
- <!-- 提供方应用信息 -->
- <dubbo:application name="your-dubbo-application"/>
-
- <!-- 使用 Nacos 元数据中心 -->
- <dubbo:metadata-report address="nacos://10.20.153.10:8848"
username="nacos" password="nacos" />
-
- <!-- 如果要使用其他参数可以使用下面方式 -->
- <!-- 当参数在xsd中有定义时，可用以下方式 -->
- <!-- <dubbo:metadata-report address="nacos:// 10.20.153.10:8848"
username="nacos" password="nacos" group="demo" /> -->
-
- <!-- 或者使用以下方式，将参数配置在address中 -->
- <!-- <dubbo:metadata-report
address="nacos://10.20.153.10:8848?namespace=5cbb70a5-xxx-xxx-xxx-d43479ae0932"
username="nacos" password="nacos" /> -->
- ...
-</beans>
-```
-可配置的参数参考完整配置项说明
+完整配置参数请参考
[metadata-report-config](../../config/properties/#metadata-report-config)。
->
Dubbo`3.0.0`版本以后，增加了是否注册消费者的元数据，如果需要将消费者元数据存放到nacos元数据中心上，需要将参数(report-consumer-definition)设置为true，默认是false。
+## 4 工作原理
-设置方式如下：
-```xml
- <?xml version="1.0" encoding="UTF-8"?>
- <beans xmlns="http://www.springframework.org/schema/beans";
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
- xsi:schemaLocation="http://www.springframework.org/schema/beans
- http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
- http://dubbo.apache.org/schema/dubbo
- http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
-
- ...
- <!-- 使用 Nacos 元数据中心 -->
- <dubbo:metadata-report
address="nacos://10.20.153.10:8848?report-consumer-definition=true"
username="nacos" password="nacos" />
- ...
- </beans>
- ```
+### 4.1 [服务运维元数据](../overview/2-服务运维元数据)
-随后，重启Dubbo应用，在Nacos的控制台上可看到服务提供者和消费者的应用级别以及接口级别元数据信息：
+在 Nacos 的控制台上可看到服务提供者、消费者注册的服务运维相关的元数据信息：
-#### 应用级别元数据
-应用级别元数据只有当一个应用定义服务之后，才会进行暴露。会根据当前应用的自身信息，以及接口信息，去计算出该应用的 revision
修订值，用于保存应用级别元数据。
-
->
在Dubbo`3.0.0`及以上版本中，引入了应用元数据的概念，应用元数据描述的是整个应用的信息概览。如需暴露应用级别元数据，需要将配置参数metadata-type设置为remote(默认为local)，或将参数reportMetadata设置为true(默认为false)。
-
-设置方式如下：
- ```xml
- <?xml version="1.0" encoding="UTF-8"?>
- <beans xmlns="http://www.springframework.org/schema/beans";
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
- xmlns:dubbo="http://dubbo.apache.org/schema/dubbo";
- xsi:schemaLocation="http://www.springframework.org/schema/beans
- http://www.springframework.org/schema/beans/spring-beans-4.3.xsd
- http://dubbo.apache.org/schema/dubbo
- http://dubbo.apache.org/schema/dubbo/dubbo.xsd";>
- ...
- <!-- 设置是否暴露应用级别元数据，可以使用以下两种方式-->
- <!-- 第一种方式 -->
- <dubbo:application name="your-dubbo-application" metadata-type="remote"/>
-
- <!-- 第二种方式 -->
- <dubbo:metadata-report address="nacos://10.20.153.10:8848" username="nacos"
password="nacos" report-metadata="true"/>
- ...
- </beans>
- ```
-
-元数据信息详情：
-
-
-#### 接口级别元数据
在 Nacos 中，本身就存在配置中心这个概念，正好用于元数据存储。在配置中心的场景下，存在命名空间- namespace 的概念，在 namespace
之下，还存在 group 概念。即通过 namespace 和 group 以及 dataId 去定位一个配置项，在不指定 namespace
的情况下，默认使用 ```public``` 作为默认的命名空间。
```properties
@@ -239,164 +68,48 @@ Provider: namespace: 'public', dataId: '{service
name}:{version}:{group}:provide
Consumer: namespace: 'public', dataId: '{service
name}:{version}:{group}:consumer:{application name}', group: 'dubbo'
```
当 version 或者 group 不存在时`:` 依然保留:
-
```properties
Provider: namespace: 'public', dataId: '{service name}:::provider:{application
name}', group: 'dubbo'
Consumer: namespace: 'public', dataId: '{service name}:::consumer:{application
name}', group: 'dubbo'
```
-Providers接口元数据详情：
+Providers接口元数据详情 (通过 `report-definition=true` 控制此部分数据是否需要上报)：
-Consumers接口元信息详情：
+Consumers接口元信息详情（通过 `report-consumer-definition=true` 控制是否上报，默认 false）：
+### 4.2 [地址发现 - 接口-应用映射](../overview/2-地址发现元数据)
+在上面提到，service name 和 application name 可能是一对多的，在 nacos 中，使用单个 key-value 进行保存，多个
application name 通过英文逗号`,`隔开。由于是单个 key-value
去保存数据，在多客户端的情况下可能会存在并发覆盖的问题。因此，我们使用 nacos 中 publishConfigCas 的能力去解决该问题。在 nacos
中，使用 publishConfigCas 会让用户传递一个参数 casMd5，该值的含义是之前配置内容的 md5 值。不同客户端在更新之前，先去查一次
nacos 的 content 的值，计算出 md5 值，当作本地凭证。在更新时，把凭证 md5 传到服务端比对 md5 值,
如果不一致说明在次期间被其他客户端修改过，重新获取凭证再进行重试(CAS)。目前如果重试6次都失败的话，放弃本次更新映射行为。
-### <a id="method3">API配置</a>
-同样，当Dubbo使用Nacos为注册中心，假设启动服务器IP为：10.20.153.10，端口号为：8848，则在Spring
Bean在XML文件中添加以下配置：
-
+Nacos api:
```java
-public class ProviderBootstrap {
-
- @Bean
- public MetadataReportConfig metadataReportConfig() {
- MetadataReportConfig metadataReportConfig = new MetadataReportConfig();
- // 使用 Nacos 元数据中心
-
metadataReportConfig.setAddress("nacos://10.20.153.10:8848?username=nacos&password=nacos");
-
- //如果要使用其他参数可以使用下面方式
- //作为地址参数传入
-
//metadataReportConfig.setAddress("nacos://localhost:8848?username=nacos&password=nacos&namespace=5cbb70a5-xxx-xxx-xxx-d43479ae0932");
-
- //直接set值，如果set没有找到相关参数，可以放入parameters中
- //metadataReportConfig.setAddress("nacos://localhost:8848");
- //metadataReportConfig.setUsername("nacos");
- //metadataReportConfig.setPassword("nacos");
- //
- //Map<String, String> map = new HashMap();
- //map.put("namespace","5cbb70a5-xxx-xxx-xxx-d43479ae0932");
- //metadataReportConfig.setParameters(map);
-
- return metadataReportConfig;
- }
-
-}
+ConfigService configService = ...
+configService.publishConfigCas(key, group, content, ticket);
```
-可配置的参数参考完整配置项说明
->
Dubbo`3.0.0`版本以后，增加了是否注册消费者的元数据，如果需要将消费者元数据存放到nacos元数据中心上，需要将参数(report-consumer-definition)设置为true，默认是false。
+映射信息位于 namespace: 'public', dataId: '{service name}', group: 'mapping'.
-设置方式如下：
+
-> ```java
-> public class ConsumerBootstrap {
-> @Bean
-> public MetadataReportConfig metadataReportConfig() {
-> MetadataReportConfig metadataReportConfig = new MetadataReportConfig();
->
metadataReportConfig.setAddress("nacos://localhost:8848?username=nacos&password=nacos&report-consumer-definition=true");
-> return metadataReportConfig;
-> }
-> }
-> ```
-随后，重启Dubbo应用，在Nacos的控制台上可看到服务提供者和消费者的应用级别以及接口级别元数据信息：
+### 4.3 [地址发现 - 接口配置元数据](../overview/2-地址发现元数据)
-
-
-#### 应用级别元数据
-应用级别元数据只有当一个应用定义服务之后，才会进行暴露。会根据当前应用的自身信息，以及接口信息，去计算出该应用的 revision
修订值，用于保存应用级别元数据。
-
->
在Dubbo`3.0.0`及以上版本中，引入了应用元数据的概念，应用元数据描述的是整个应用的信息概览。如需暴露应用级别元数据，需要将配置参数metadata-type设置为remote(默认为local)，或将参数reportMetadata设置为true(默认为false)。
-
-设置方式如下：
- ```java
- public class ProviderBootstrap {
-
- //设置是否暴露应用级别元数据，可以使用以下两种方式
- //第一种方式
- @Bean
- public MetadataReportConfig metadataReportConfig() {
- MetadataReportConfig metadataReportConfig = new MetadataReportConfig();
-
metadataReportConfig.setAddress("nacos://localhost:8848?username=nacos&password=nacos");
- metadataReportConfig.setReportMetadata(true);
- return metadataReportConfig;
- }
-
- //第二种方式
- @Bean
- public ApplicationConfig applicationConfig() {
- ApplicationConfig applicationConfig = new ApplicationConfig();
- applicationConfig.setName("nacos-metadata-demo-provider-annotation");
- applicationConfig.setMetadataType(REMOTE_METADATA_STORAGE_TYPE);
- return applicationConfig;
- }
- }
- ```
-
-元数据信息详情：
-
-
-
-#### 接口级别元数据
-在 Nacos 中，本身就存在配置中心这个概念，正好用于元数据存储。在配置中心的场景下，存在命名空间- namespace 的概念，在 namespace
之下，还存在 group 概念。即通过 namespace 和 group 以及 dataId 去定位一个配置项，在不指定 namespace
的情况下，默认使用 `public` 作为默认的命名空间。
+要开启远程接口配置元数据注册，需在应用中增加以下配置，因为默认情况下 Dubbo3 应用级服务发现会启用服务自省模式，并不会注册数据到元数据中心。
```properties
-Provider: namespace: 'public', dataId: '{service
name}:{version}:{group}:provider:{application name}', group: 'dubbo'
-Consumer: namespace: 'public', dataId: '{service
name}:{version}:{group}:consumer:{application name}', group: 'dubbo'
-```
+ dubbo.application.metadata-type=remote
+ ```
-当 version 或者 group 不存在时`:` 依然保留:
+或者，在自省模式模式下仍开启中心化元数据注册
```properties
-Provider: namespace: 'public', dataId: '{service name}:::provider:{application
name}', group: 'dubbo'
-Consumer: namespace: 'public', dataId: '{service name}:::consumer:{application
name}', group: 'dubbo'
+dubbo.application.metadata-type=local
+dubbo.metadata-report.report-metadata=true
```
-Providers接口元数据详情：
-
-
-
-Consumers接口元信息详情：
-
-
-
-
+Nacos server 中的元数据信息详情如下：
-# 服务自省映射 - Service Name Mapping
-
-Dubbo`3.0.0`及以上版本中，默认使用了服务自省机制去实现服务发现，关于服务自省可以查看[服务自省](https://mercyblitz.github.io/2020/05/11/Apache-Dubbo-服务自省架构设计/)
-
-简而言之，服务自省机制需要能够通过 interface name 去找到对应的 application name，这个关系可以是一对多的，即一个
service name 可能会对应多个不同的 application name。在 3.0 中，元数据中心提供此项映射的能力。
-
-在上面提到，service name 和 application name 可能是一对多的，在 nacos 中，使用单个 key-value 进行保存，多个
application name 通过英文逗号,隔开。由于是单个 key-value 去保存数据，在多客户端的情况下可能会存在并发覆盖的问题。因此，我们使用
nacos 中 publishConfigCas 的能力去解决该问题。在 nacos 中，使用 publishConfigCas 会让用户传递一个参数
casMd5，该值的含义是之前配置内容的 md5 值。不同客户端在更新之前，先去查一次 nacos 的 content 的值，计算出 md5
值，当作本地凭证。在更新时，把凭证 md5 传到服务端比对 md5 值,
如果不一致说明在次期间被其他客户端修改过，重新获取凭证再进行重试(CAS)。目前如果重试6次都失败的话，放弃本次更新映射行为。
-
-Nacos api:
-
-```properties
-ConfigService configService = ...
-configService.publishConfigCas(key, group, content, ticket);
-```
+
-映射信息位于 ```namespace: ‘public’, dataId: ‘{service name}’, group: ‘mapping’```.
-
-
-
-# 完整配置项
-
-参数名 | 中文描述| 默认值
----|---|---
-username|连接Nacos Server的用户名|空
-paasword|连接Nacos Server的密码|空
-backup|访问Nacos备用地址|空
-namespace|命名空间的ID|public
-group|分组名称|DEFAULT_GROUP
-timeout|请求元数据中心超时时间（ms）|
-retry-time|重试次数|100
-retry-period|重试间隔时间(ms)|3000
-cycle-report|是否每天上报元数据|true
-sync-report|是否同步上报元数据|false
-file|保存元数据中心动态列表的文件|空
-report-metadata|当metadataType为local时是否上报应用元数据|false
-report-definition|是否上报接口级别元数据|true
-report-consumer-definition|是否上报消费端|false
\ No newline at end of file
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/overview/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/overview/_index.md
index 3dece31ac6..6bb7277718 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/overview/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/overview/_index.md
@@ -5,113 +5,115 @@ linkTitle: "元数据中心概述"
weight: 1
---
+元数据中心为 Dubbo 中的两类元数据提供了存取能力：
+- 1 地址发现元数据
+ - 1.1 '接口-应用' 映射关系
+ - 1.2 接口配置数据
+- 2 服务运维元数据
+ - 2.1 接口定义描述数据
+ - 2.2 消费者订阅关系数据
-## 背景
+关于如何配置开启元数据中心请参考具体实现文档。
-dubbo
provider中的服务配置项有接近[30个配置项](https://dubbo.apache.org/zh/docs/v2.7/user/references/xml/dubbo-provider/)。
排除注册中心服务治理需要之外，很大一部分配置项是provider自己使用，不需要透传给消费者。这部分数据不需要进入注册中心，而只需要以key-value形式持久化存储。
-dubbo
consumer中的配置项也有[20+个配置项](https://dubbo.apache.org/zh/docs/v2.7/user/references/xml/dubbo-consumer/)。在注册中心之中，服务消费者列表中只需要关注application，version，group，ip，dubbo版本等少量配置，其他配置也可以以key-value形式持久化存储。
-这些数据是以服务为维度注册进入注册中心，导致了数据量的膨胀，进而引发注册中心(如zookeeper)的网络开销增大，性能降低。
-除了上述配置项的存储之外，dubbo服务元数据信息也需要被存储下来。元数据信息包括服务接口，及接口的方法信息。这些信息将被用于服务mock，服务测试。
+## 1 地址发现元数据
+Dubbo3 中引入了 [应用级服务发现机制](/zh/overview/whatsnew/service-discovery/)
用来解决异构微服务体系互通与大规模集群实践的性能问题，应用级服务发现将全面取代 2.x 是时代的接口级服务发现。
+同时为了保持 Dubbo 面向服务/接口的易用性、服务治理的灵活性，Dubbo 围绕应用级服务发现构建了一套元数据机制，即 `接口 - 应用映射关系` 与
`接口配置元数据`。
-以上的元数据都是基于接口级别。在3.0版本中，引入了应用元数据的概念，应用元数据描述的是整个应用的信息概览。并且引入了服务自省映射，用于应用级别的服务发现。
+### 1.1 接口 - 应用映射关系
+Dubbo 一直以来都能做到精确的地址发现，即只订阅 Consumer
声明要关心的服务及相关的地址列表，相比于拉取/订阅全量地址列表，这样觉有很好的性能优势。
+在应用级服务发现模型中，想做到精确地址订阅并不容易，因为 Dubbo Consumer 只声明了要消费的接口列表，Consumer 需要能够将接口转换为
Provider 应用名才能进行精准服务订阅，
+为此，Dubbo 需要在元数据中心维护这一份 `接口名->应用名` 的对应关系，Dubbo3 中通过 provider 启动的时主动向元数据中心上报实现。
+接口 (service name) - 应用 (Provider application name) 的映射关系可以是一对多的，即一个 service
name 可能会对应多个不同的 application name。
-## 目标
+以 zookeeper 为例，映射关系保存在以下位置:
-需要将注册中心原来的数据信息和元数据信息保存到独立的key-value的存储中，这个key-value可以是DB，redis或者其他持久化存储。核心代码中支持了zookeeper，redis,
nacos(推荐)的默认支持。
->因为是基于key-value存储，key不会改变，最新的value会将原来的value进行覆盖
-
-Provider存储内容的格式，参见：org.apache.dubbo.metadata.definition.model.FullServiceDefinition。是该类型gson化之后的存储。
-Consumer存储内容，为Map格式。从Consumer端注册到注册中心的URL中的获取参数信息。即通过URL.getParameterMap()获取到的Map，进行gson化之后进行存储。
-
-详细的内容，可以参考下面的sample输出。
-
-
-
-## 配置
-
-默认的元数据存储，额外支持以下几个特性：
-* 失败重试
-* 每天定时重刷
-
-#### 失败重试
-失败重试可以通过retrytimes （重试次数,默认100），retryperiod（重试周期，默认3000ms）进行设置。
-
-#### 定时刷新
-默认开启，可以通过设置cycleReport=false进行关闭。
-
-#### 完整的配置项：
-
-```properties
-dubbo.metadata-report.address=zookeeper://127.0.0.1:2181
-dubbo.metadata-report.username=xxx ##非必须
-dubbo.metadata-report.password=xxx ##非必须
-dubbo.metadata-report.retry-times=30 ##非必须,default值100
-dubbo.metadata-report.retry-period=5000 ##非必须,default值3000
-dubbo.metadata-report.cycle-report=false ##非必须,default值true
-dubbo.metadata-report.sync.report=false ##非必须,default值为false
-```
->
如果元数据地址(dubbo.metadata-report.address)也不进行配置，会判断注册中心的协议是否支持元数据中心，如果支持，会使用注册中心的地址来用作元数据中心。
-
-
-接下来看几个sample的配置。无论哪种配置方式，都需要引入maven依赖：
-
-zookeeper:
-```xml
-<dependency>
- <groupId>org.apache.dubbo</groupId>
- <artifactId>dubbo-metadata-report-zookeeper</artifactId>
-</dependency>
-```
-
-redis:
-```xml
-<dependency>
- <groupId>org.apache.dubbo</groupId>
- <artifactId>dubbo-metadata-report-redis</artifactId>
-</dependency>
-```
-
-nacos:
-```xml
-<dependency>
- <groupId>org.apache.dubbo</groupId>
- <artifactId>dubbo-metadata-report-nacos</artifactId>
-</dependency>
+```shell
+$ ./zkCli.sh
+$ get /dubbo/mapping/org.apache.dubbo.demo.DemoService
+$ demo-provider,two-demo-provider,dubbo-demo-annotation-provider
```
+1. 节点路径是 `/dubbo/mapping/{interface name}`
+2. 多个应用名通过英文逗号 `,` 隔开
->
**完整的sample，查看[sample-2.7](https://github.com/dubbo/dubbo-samples/tree/master)**
+### 1.2 接口配置元数据
-### 方式一：在配置中心配置
+`接口级配置元数据`是作为地址发现的补充，只有当才会进行暴露。会根据当前应用的自身信息，以及接口信息，去计算出该应用的 revision
修订值，用于保存应用级别元数据，
-参考sample：dubbo-samples-metadata-report/dubbo-samples-metadata-report-configcenter
工程。
+以 Zookeeper 为例，接口配置元数据保存在以下位置：
-##### 配置中心配置
+/dubbo/metadata/{application name}/{revision}
-配置中心的配置，可以参考configcenter的文档。配置的内容如下：
-
-```properties
-dubbo.registry.address=zookeeper://127.0.0.1:2181
-### 注意驼峰式风格
-dubbo.metadata-report.address=zookeeper://127.0.0.1:2181 ###元数据存储的地址
+```shell script
+[zk: localhost:2181(CONNECTED) 33] get
/dubbo/metadata/demo-provider/da3be833baa2088c5f6776fb7ab1a436
```
-在sample中，使用了Zookeeper作为配置中心。启动本地zookeeper服务之后，直接运行：org.apache.dubbo.samples.metadatareport.configcenter.ZKTools
就可以完成写入。
-如果配置中心使用了nacos，apollo，这些产品本身支持ops配置。
-
-##### 应用配置
-
-```properties
-###dubbo.properties
-dubbo.config-center.address=zookeeper://127.0.0.1:2181
-...
+```json
+{
+ "app":"demo-provider",
+ "revision":"da3be833baa2088c5f6776fb7ab1a436",
+ "services":{
+ "org.apache.dubbo.demo.DemoService:dubbo":{
+ "name":"org.apache.dubbo.demo.DemoService",
+ "protocol":"dubbo",
+ "path":"org.apache.dubbo.demo.DemoService",
+ "params":{
+ "side":"provider",
+ "release":"",
+ "methods":"sayHello,sayHelloAsync",
+ "deprecated":"false",
+ "dubbo":"2.0.2",
+ "pid":"38298",
+ "interface":"org.apache.dubbo.demo.DemoService",
+ "service-name-mapping":"true",
+ "timeout":"3000",
+ "generic":"false",
+ "metadata-type":"remote",
+ "delay":"5000",
+ "application":"demo-provider",
+ "dynamic":"true",
+ "REGISTRY_CLUSTER":"registry1",
+ "anyhost":"true",
+ "timestamp":"1626887121829"
+ }
+ },
+ "org.apache.dubbo.demo.RestDemoService:1.0.0:rest":{
+ "name":"org.apache.dubbo.demo.RestDemoService",
+ "version":"1.0.0",
+ "protocol":"rest",
+ "path":"org.apache.dubbo.demo.RestDemoService",
+ "params":{
+ "side":"provider",
+ "release":"",
+ "methods":"getRemoteApplicationName,sayHello,hello,error",
+ "deprecated":"false",
+ "dubbo":"2.0.2",
+ "pid":"38298",
+ "interface":"org.apache.dubbo.demo.RestDemoService",
+ "service-name-mapping":"true",
+ "version":"1.0.0",
+ "timeout":"5000",
+ "generic":"false",
+ "revision":"1.0.0",
+ "metadata-type":"remote",
+ "delay":"5000",
+ "application":"demo-provider",
+ "dynamic":"true",
+ "REGISTRY_CLUSTER":"registry1",
+ "anyhost":"true",
+ "timestamp":"1626887120943"
+ }
+ }
+ }
+}
```
-完成上述两步之后，注册中心地址、元数据地址将从配置中心进行获取。现在可以依次运行Provider类和Consumer类，会在console中得到对应的输出或者直接通过zookeeper的cli查看。
+## 2 服务运维元数据
-##### Provider配置
+Dubbo
上报的服务运维元数据通常为各种运维系统所用，如服务测试、网关数据映射、服务静态依赖关系分析等。各种第三方系统可直接读取并使用这部分数据，具体对接方式可参见本章提及的几个第三方系统。
+### 2.1 Provider 上报的元数据
provider端存储的元数据内容如下：
```json
@@ -155,12 +157,13 @@ provider端存储的元数据内容如下：
"type": "char"
}]
}
-
```
-provider存储的内容包括了provider服务往注册中心填写的全部参数，以及服务的方法信息（方法名，入参出参的格式）。
+主要有两部分：
+* `parameters` 为服务配置与参数详情。
+* `types` 为服务定义信息。
-##### Consumer配置：
+##### Consumer 上报的元数据：
```json
{
@@ -177,443 +180,33 @@ provider存储的内容包括了provider服务往注册中心填写的全部参
}
```
-consumer端存储了consumer往注册中心填写的全部参数。
+Consumer 进程订阅时使用的配置元数据。
+## 3 元数据上报工作机制
+元数据上报默认是一个异步的过程，为了更好的控制异步行为，元数据配置组件 (metadata-report) 开放了两个配置项：
+* 失败重试
+* 每天定时重刷
-上面的例子，主要是将元数据地址放在配置中心，在元数据区存储下来的provider端服务信息和consumer端服务信息的展示。
-接下来的两个例子，主要讲解在工程中配置：xml方式，annotation方式。
-
-### 方式二：配置在项目中-properties方式引入配置
+### 3.1 retrytimes 失败重试
+失败重试可以通过 retrytimes （重试次数,默认100），retryperiod（重试周期，默认3000ms）进行设置。
-参考sample：dubbo-samples-metadata-report/dubbo-samples-metadata-report-local-properties工程。
+### 3.2 定时刷新
+默认开启，可以通过设置 cycleReport=false 进行关闭。
-##### dubbo.properties
+### 3.3 完整的配置项
```properties
dubbo.metadata-report.address=zookeeper://127.0.0.1:2181
+dubbo.metadata-report.username=xxx ##非必须
+dubbo.metadata-report.password=xxx ##非必须
+dubbo.metadata-report.retry-times=30 ##非必须,default值100
+dubbo.metadata-report.retry-period=5000 ##非必须,default值3000
+dubbo.metadata-report.cycle-report=false ##非必须,default值true
+dubbo.metadata-report.sync.report=false ##非必须,default值为false
```
+>
如果元数据地址(dubbo.metadata-report.address)也不进行配置，会判断注册中心的协议是否支持元数据中心，如果支持，会使用注册中心的地址来用作元数据中心。
-配置完成这个之后，其余的不用特别关注。也可以直接查看对应的provider和consumer端的服务信息。
-
-##### provider存储的某个服务的内容：
-
-```json
-{
- "parameters": {
- "valid": "true",
- "async": "true",
- "side": "provider",
- "application": "metadatareport-local-xml-provider",
- "methods": "sayHello",
- "dubbo": "2.0.2",
- "interface":
"org.apache.dubbo.samples.metadatareport.local.xml.api.DemoService",
- "generic": "false",
- "anyhost": "true"
- },
- "canonicalName":
"org.apache.dubbo.samples.metadatareport.local.xml.api.DemoService",
- "codeSource":
"file:/Users/cvictory/workspace/work-mw/dubbo-samples/dubbo-samples-metadata-report/dubbo-samples-metadata-report-local-xml/target/classes/",
- "methods": [{
- "name": "sayHello",
- "parameterTypes": ["java.lang.String"],
- "returnType": "java.lang.String"
- }],
- "types": [{
- "type": "int"
- }, {
- "type": "char"
- }, {
- "type": "java.lang.String",
- "properties": {
- "value": {
- "type": "char[]"
- },
- "hash": {
- "type": "int"
- }
- }
- }]
-}
-
-```
-
-##### consumer端存储的内容：
-
-```json
-{
- "valid": "true",
- "side": "consumer",
- "application": "metadatareport-local-xml-consumer",
- "methods": "sayHello",
- "dubbo": "2.0.2",
- "interface":
"org.apache.dubbo.samples.metadatareport.local.xml.api.DemoService"
-}
-
-```
-
-
-
-### 方式三：配置在项目中-annotation方式引入配置
-
-参考sample：dubbo-samples-metadata-report/dubbo-samples-metadata-report-local-annotaion工程。
-
-##### @Bean 引入bean
-
-```java
-@Bean
-public MetadataReportConfig metadataReportConfig() {
- MetadataReportConfig metadataReportConfig = new MetadataReportConfig();
- metadataReportConfig.setAddress("zookeeper://127.0.0.1:2181");
- return metadataReportConfig;
-}
-
-```
-引入Bean之后，其余的地方也不需要特别配置。直接查看对应的服务信息：
-
-##### provider存储的某个服务的内容：
-
-```json
-{
- "parameters": {
- "side": "provider",
- "methods": "sayHello",
- "dubbo": "2.0.2",
- "interface":
"org.apache.dubbo.samples.metadatareport.local.annotation.api.AnnotationService",
- "version": "1.1.8",
- "generic": "false",
- "revision": "1.1.8",
- "valid": "true",
- "application": "metadatareport-local-annotaion-provider",
- "default.timeout": "1000",
- "group": "d-test",
- "anyhost": "true"
- },
- "canonicalName":
"org.apache.dubbo.samples.metadatareport.local.annotation.api.AnnotationService",
- "codeSource":
"file:/Users/cvictory/workspace/work-mw/dubbo-samples/dubbo-samples-metadata-report/dubbo-samples-metadata-report-local-annotaion/target/classes/",
- "methods": [{
- "name": "sayHello",
- "parameterTypes": ["java.lang.String"],
- "returnType": "java.lang.String"
- }],
- "types": [{
- "type": "int"
- }, {
- "type": "java.lang.String",
- "properties": {
- "value": {
- "type": "char[]"
- },
- "hash": {
- "type": "int"
- }
- }
- }, {
- "type": "char"
- }]
-}
-```
-
-##### consumer端存储的内容：
-
-```json
-{
- "valid": "true",
- "side": "consumer",
- "application": "metadatareport-local-annotaion-consumer",
- "methods": "sayHello",
- "dubbo": "2.0.2",
- "interface":
"org.apache.dubbo.samples.metadatareport.local.annotation.api.AnnotationService",
- "version": "1.1.8",
- "revision": "1.1.8",
- "group": "d-test"
-}
-```
-
-## 扩展
-### SPI定义
-
-参考：org.apache.dubbo.metadata.store.MetadataReportFactory ，
org.apache.dubbo.metadata.store.MetadataReport
-
-```java
-@SPI("redis")
-public interface MetadataReportFactory {
- @Adaptive({"protocol"})
- MetadataReport getMetadataReport(URL url);
-}
-```
-
-
-
-### 自定义元数据的存储
-
-下面以Redis存储为例进行说明。
-
-新建一个project，需要支持以下修改：
-
-#### 扩展AbstractMetadataReport
-
-```java
-public class RedisMetadataReport extends AbstractMetadataReport {
- private final static Logger logger =
LoggerFactory.getLogger(RedisMetadataReport.class);
- final JedisPool pool;
-
- public RedisMetadataReport(URL url) {
- super(url);
- pool = new JedisPool(new JedisPoolConfig(), url.getHost(),
url.getPort());
- }
- @Override
- protected void doStoreProviderMetadata(ProviderMetadataIdentifier
providerMetadataIdentifier, String serviceDefinitions) {
- this.storeMetadata(providerMetadataIdentifier, serviceDefinitions);
- }
- @Override
- protected void doStoreConsumerMetadata(ConsumerMetadataIdentifier
consumerMetadataIdentifier, String value) {
- this.storeMetadata(consumerMetadataIdentifier, value);
- }
- private void storeMetadata(MetadataIdentifier metadataIdentifier, String
v) {
- try (Jedis jedis = pool.getResource()) {
- jedis.set(metadataIdentifier.getIdentifierKey() +
META_DATA_SOTRE_TAG, v);
- } catch (Throwable e) {
- logger.error("Failed to put " + metadataIdentifier + " to redis "
+ v + ", cause: " + e.getMessage(), e);
- throw new RpcException("Failed to put " + metadataIdentifier + "
to redis " + v + ", cause: " + e.getMessage(), e);
- }
- }
-}
-```
-
-#### 扩展 AbstractMetadataReportFactory
-
-```java
-public class RedisMetadataReportFactory extends AbstractMetadataReportFactory {
- @Override
- public MetadataReport createMetadataReport(URL url) {
- return new RedisMetadataReport(url);
- }
-}
-```
-
-#### 增加 MetadataReportFactory
-
-> META-INF/dubbo/internal/org.apache.dubbo.metadata.store.MetadataReportFactory
-
-```properties
-redis=org.apache.dubbo.metadata.store.redis.RedisMetadataReportFactory
-```
-
-只要将上面的修改和project打包成jar包，然后配置元数据中心的url：redis://10.20.153.10:6379。
-
-至此，一个自定义的元数据存储就可以运行了。
-
-
-### 数据存储
-
-#### 接口级别元数据
-
-##### Zookeeper
-
-```xml
-<dubbo:metadata-report address="zookeeper://127.0.0.1:2181"/>
-```
-
-Zookeeper 基于树形结构进行数据存储，它的元数据信息位于以下节点:
-```text
-Provider: /dubbo/metadata/{interface
name}/{version}/{group}/provider/{application name}
-Consumer: /dubbo/metadata/{interface
name}/{version}/{group}/consumer/{application name}
-```
-
-当 version 或者 group 不存在时，version 路径和 group 路径会取消，路径如下:
-```text
-Provider: /dubbo/metadata/{interface name}/provider/{application name}
-Consumer: /dubbo/metadata/{interface name}/consumer/{application name}
-```
-
-通过 zkCli get 操作查看数据.
-
-Provider node:
-```shell script
-[zk: localhost:2181(CONNECTED) 8] get
/dubbo/metadata/org.apache.dubbo.demo.DemoService/provider/demo-provider
-{"parameters":{"side":"provider","interface":"org.apache.dubbo.demo.DemoService","metadata-type":"remote","application":"demo-provider","dubbo":"2.0.2","release":"","anyhost":"true","delay":"5000","methods":"sayHello,sayHelloAsync","deprecated":"false","dynamic":"true","timeout":"3000","generic":"false"},"canonicalName":"org.apache.dubbo.demo.DemoService","codeSource":"file:/Users/apple/IdeaProjects/dubbo/dubbo-demo/dubbo-demo-interface/target/classes/","methods":[{"name":"sayHelloAsync"
[...]
-cZxid = 0x25a9b1
-ctime = Mon Jun 28 21:35:17 CST 2021
-mZxid = 0x25a9b1
-mtime = Mon Jun 28 21:35:17 CST 2021
-pZxid = 0x25a9b1
-cversion = 0
-dataVersion = 0
-aclVersion = 0
-ephemeralOwner = 0x0
-dataLength = 1061
-numChildren = 0
-```
-
-Consumer node:
-```shell script
-[zk: localhost:2181(CONNECTED) 10] get
/dubbo/metadata/org.apache.dubbo.demo.DemoService/consumer/demo-consumer
-{"side":"consumer","interface":"org.apache.dubbo.demo.DemoService","metadata-type":"remote","application":"demo-consumer","dubbo":"2.0.2","release":"","sticky":"false","check":"false","methods":"sayHello,sayHelloAsync"}
-cZxid = 0x25aa24
-ctime = Mon Jun 28 21:57:43 CST 2021
-mZxid = 0x25aa24
-mtime = Mon Jun 28 21:57:43 CST 2021
-pZxid = 0x25aa24
-cversion = 0
-dataVersion = 0
-aclVersion = 0
-ephemeralOwner = 0x0
-dataLength = 219
-numChildren = 0
-```
-
-
-##### Redis
-
-```xml
-<dubbo:metadata-report address="redis://127.0.0.1:6779"/>
-```
-
-在Redis中，使用string数据结构来进行存储元数据信息:
-```text
-Provider: {service name}:{version}:{group}:provider:{application name}
-Consumer: {service name}:{version}:{group}:consumer:{application name}
-```
-
-当 version 或者 group 不存在时，`:` 依然保留:
-
-```text
-Provider: {service name}:::provider:{application name}
-Consumer: {service name}:::consumer:{application name}
-```
-
-通过 Redis client get key 查看数据.
-
-Provider key:
-```shell script
-127.0.0.1:6379> get org.apache.dubbo.demo.DemoService:::provider:demo-provider
-"{\"parameters\":{\"side\":\"provider\",\"interface\":\"org.apache.dubbo.demo.DemoService\",\"metadata-type\":\"remote\",\"application\":\"demo-provider\",\"dubbo\":\"2.0.2\",\"release\":\"\",\"anyhost\":\"true\",\"delay\":\"5000\",\"methods\":\"sayHello,sayHelloAsync\",\"deprecated\":\"false\",\"dynamic\":\"true\",\"timeout\":\"3000\",\"generic\":\"false\"},\"canonicalName\":\"org.apache.dubbo.demo.DemoService\",\"codeSource\":\"file:/Users/apple/IdeaProjects/dubbo/dubbo-demo/dubbo-demo
[...]
-```
-
-Consumer key:
-```shell script
-127.0.0.1:6379> get org.apache.dubbo.demo.DemoService:::consumer:demo-consumer
-"{\"side\":\"consumer\",\"interface\":\"org.apache.dubbo.demo.DemoService\",\"metadata-type\":\"remote\",\"application\":\"demo-consumer\",\"dubbo\":\"2.0.2\",\"release\":\"\",\"sticky\":\"false\",\"check\":\"false\",\"methods\":\"sayHello,sayHelloAsync\"}"
-```
-
-##### Nacos
-```xml
-<dubbo:metadata-report address="nacos://127.0.0.1:8848"/>
-```
-
-在 Nacos 中，本身就存在配置中心这个概念，正好用于元数据存储。在配置中心的场景下，存在命名空间- namespace 的概念，在 namespace
之下，还存在 group 概念。即通过 namespace 和 group 以及 dataId 去定位一个配置项，在不指定 namespace
的情况下，默认使用 `public` 作为默认的命名空间。
-
-```text
-Provider: namespace: 'public', dataId: '{service
name}:{version}:{group}:provider:{application name}', group: 'dubbo'
-Consumer: namespace: 'public', dataId: '{service
name}:{version}:{group}:consumer:{application name}', group: 'dubbo'
-```
-
-当 version 或者 group 不存在时，`:` 依然保留:
-
-```text
-Provider: namespace: 'public', dataId: '{service name}:::provider:{application
name}', group: 'dubbo'
-Consumer: namespace: 'public', dataId: '{service name}:::consumer:{application
name}', group: 'dubbo'
-```
-
-可以通过 Nacos 自带的 web console 界面进行查看.
-
-Provider data:
-
-
-Consumer data:
-
-
-
-#### 应用级别元数据
-应用级别元数据只有当一个应用定义服务之后，才会进行暴露。会根据当前应用的自身信息，以及接口信息，去计算出该应用的 revision
修订值，用于保存应用级别元数据，
-
-##### Zookeeper
-Zookeeper 的应用级别元数据位于 /dubbo/metadata/{application name}/{revision}
-
-```shell script
-[zk: localhost:2181(CONNECTED) 33] get
/dubbo/metadata/demo-provider/da3be833baa2088c5f6776fb7ab1a436
-{"app":"demo-provider","revision":"da3be833baa2088c5f6776fb7ab1a436","services":{"org.apache.dubbo.demo.DemoService:dubbo":{"name":"org.apache.dubbo.demo.DemoService","protocol":"dubbo","path":"org.apache.dubbo.demo.DemoService","params":{"side":"provider","release":"","methods":"sayHello,sayHelloAsync","deprecated":"false","dubbo":"2.0.2","pid":"38298","interface":"org.apache.dubbo.demo.DemoService","service-name-mapping":"true","timeout":"3000","generic":"false","metadata-type":"remote
[...]
-cZxid = 0x25b336
-ctime = Thu Jul 22 01:05:55 CST 2021
-mZxid = 0x25b336
-mtime = Thu Jul 22 01:05:55 CST 2021
-pZxid = 0x25b336
-cversion = 0
-dataVersion = 0
-aclVersion = 0
-ephemeralOwner = 0x0
-dataLength = 1286
-numChildren = 0
-```
-
-#### Redis
-Redis 元数据中心目前还不支持应用级别元数据，但已提上日程，会在近期进行实现。
-
-##### Nacos
-Nacos 应用级别的元数据位于 namespace: 'public', dataId: '{application name}', group:
'{revision}'
-
-
-
-
-#### 服务自省映射 - Service Name Mapping
-在Dubbo 3.0
中，默认使用了服务自省机制去实现服务发现，关于服务自省可以查看[服务自省](https://mercyblitz.github.io/2020/05/11/Apache-Dubbo-%E6%9C%8D%E5%8A%A1%E8%87%AA%E7%9C%81%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/)
-
-简而言之，服务自省机制需要能够通过 interface name 去找到对应的 application name，这个关系可以是一对多的，即一个
service name 可能会对应多个不同的 application name。在 3.0 中，元数据中心提供此项映射的能力。
-
-
-##### Zookeeper
-在上面提到，service name 和 application name 可能是一对多的，在 zookeeper 中，使用单个 key-value
进行保存，多个 application name 通过英文逗号`,`隔开。由于是单个 key-value
去保存数据，在多客户端的情况下可能会存在并发覆盖的问题。因此，我们使用 zookeeper 中的版本机制 version 去解决该问题。在 zookeeper
中，每一次对数据进行修改，dataVersion 都会进行增加，我们可以利用 version
这个机制去解决多个客户端同时更新映射的并发问题。不同客户端在更新之前，先去查一次 version，当作本地凭证。在更新时，把凭证 version
传到服务端比对 version, 如果不一致说明在次期间被其他客户端修改过，重新获取凭证再进行重试(CAS)。目前如果重试6次都失败的话，放弃本次更新映射行为。
-
-Curator api.
-```java
-CuratorFramework client = ...
-client.setData().withVersion(ticket).forPath(path, dataBytes);
-```
-
-映射信息位于:
-```text
-/dubbo/mapping/{service name}
-```
-
-通过 zkCli get 操作查看数据.
-
-```shell script
-[zk: localhost:2181(CONNECTED) 26] get
/dubbo/mapping/org.apache.dubbo.demo.DemoService
-demo-provider,two-demo-provider,dubbo-demo-annotation-provider
-cZxid = 0x25a80f
-ctime = Thu Jun 10 01:36:40 CST 2021
-mZxid = 0x25a918
-mtime = Fri Jun 11 18:46:40 CST 2021
-pZxid = 0x25a80f
-cversion = 0
-dataVersion = 2
-aclVersion = 0
-ephemeralOwner = 0x0
-dataLength = 62
-numChildren = 0
-```
-
-
-##### Redis
-Redis 元数据中心目前还不支持服务自省映射，但已提上日程，会在近期进行实现。
-
-
-##### Nacos
-在上面提到，service name 和 application name 可能是一对多的，在 nacos 中，使用单个 key-value 进行保存，多个
application name 通过英文逗号`,`隔开。由于是单个 key-value
去保存数据，在多客户端的情况下可能会存在并发覆盖的问题。因此，我们使用 nacos 中 publishConfigCas 的能力去解决该问题。在 nacos
中，使用 publishConfigCas 会让用户传递一个参数 casMd5，该值的含义是之前配置内容的 md5 值。不同客户端在更新之前，先去查一次
nacos 的 content 的值，计算出 md5 值，当作本地凭证。在更新时，把凭证 md5 传到服务端比对 md5 值,
如果不一致说明在次期间被其他客户端修改过，重新获取凭证再进行重试(CAS)。目前如果重试6次都失败的话，放弃本次更新映射行为。
-
-Nacos api:
-```java
-ConfigService configService = ...
-configService.publishConfigCas(key, group, content, ticket);
-```
-
-映射信息位于 namespace: 'public', dataId: '{service name}', group: 'mapping'.
-
-
-
-
-
-
-
-
+## 4 了解如何扩展
+请参见 [扩展 metadata-report](../spi/description/metadata-report/) 了解如何扩展自定义第三方实现。
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/redis/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/redis/_index.md
index 34200f8139..9362c77a88 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/redis/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/redis/_index.md
@@ -3,5 +3,6 @@ type: docs
title: "Redis"
linkTitle: "Redis"
weight: 4
-description: ""
+description: "Redis 元数据中心基本使用与工作原理"
---
+暂未支持
\ No newline at end of file
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/zookeeper/_index.md
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/zookeeper/_index.md
index 2864a6f0b1..77039bcf23 100644
---
a/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/zookeeper/_index.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/metadata-center/zookeeper/_index.md
@@ -2,6 +2,174 @@
type: docs
title: "Zookeeper"
linkTitle: "Zookeeper"
-weight: 2
-description: ""
+weight: 3
+description: "Zookeeper 元数据中心基本使用与工作原理"
---
+
+## 1 预备工作
+- 了解 [Dubbo 基本开发步骤](/zh/docs3-v2/java-sdk/quick-start/spring-boot/)
+- 安装并启动 [Zookeeper](https://zookeeper.apache.org/)
+
+## 2 使用说明
+
+### 2.1 增加 Maven 依赖
+如果项目已经启用 Zookeeper 作为注册中心，则无需增加任何额外配置。
+
+如果未使用 Zookeeper 注册中心，则请参考 [为注册中心增加 Zookeeper
相关依赖](../../registry/zookeeper/#21-增加-maven-依赖)。
+
+### 2.2 启用 Zookeeper 配置中心
+```xml
+<dubbo:metadata-report address="zookeeper://127.0.0.1:2181"/>
+```
+
+或者
+
+```yaml
+dubbo
+ metadata-report
+ address: zookeeper://127.0.0.1:2181
+```
+
+或者
+
+```properties
+dubbo.metadata-report.address=zookeeper://127.0.0.1:2181
+```
+
+或者
+
+```java
+MetadataReportConfig metadataConfig = new MetadataReportConfig();
+metadataConfig.setAddress("zookeeper://127.0.0.1:2181");
+```
+
+`address` 格式请参考 [zookeeper 注册中心 -
启用配置](../../registry/zookeeper/#22-配置并启用-zookeeper)
+
+## 3 高级配置
+
+完整配置参数请参考
[metadata-report-config](../../config/properties/#metadata-report-config)。
+
+## 4 工作原理
+
+### 4.1 [服务运维元数据](../overview/2-服务运维元数据)
+
+Zookeeper 基于树形结构进行数据存储，它的元数据信息位于以下节点:
+```text
+Provider: /dubbo/metadata/{interface
name}/{version}/{group}/provider/{application name}
+Consumer: /dubbo/metadata/{interface
name}/{version}/{group}/consumer/{application name}
+```
+
+当 version 或者 group 不存在时，version 路径和 group 路径会取消，路径如下:
+```text
+Provider: /dubbo/metadata/{interface name}/provider/{application name}
+Consumer: /dubbo/metadata/{interface name}/consumer/{application name}
+```
+
+通过 zkCli get 操作查看数据.
+
+Provider node:
+```shell script
+[zk: localhost:2181(CONNECTED) 8] get
/dubbo/metadata/org.apache.dubbo.demo.DemoService/provider/demo-provider
+{"parameters":{"side":"provider","interface":"org.apache.dubbo.demo.DemoService","metadata-type":"remote","application":"demo-provider","dubbo":"2.0.2","release":"","anyhost":"true","delay":"5000","methods":"sayHello,sayHelloAsync","deprecated":"false","dynamic":"true","timeout":"3000","generic":"false"},"canonicalName":"org.apache.dubbo.demo.DemoService","codeSource":"file:/Users/apple/IdeaProjects/dubbo/dubbo-demo/dubbo-demo-interface/target/classes/","methods":[{"name":"sayHelloAsync"
[...]
+cZxid = 0x25a9b1
+ctime = Mon Jun 28 21:35:17 CST 2021
+mZxid = 0x25a9b1
+mtime = Mon Jun 28 21:35:17 CST 2021
+pZxid = 0x25a9b1
+cversion = 0
+dataVersion = 0
+aclVersion = 0
+ephemeralOwner = 0x0
+dataLength = 1061
+numChildren = 0
+```
+
+Consumer node:
+```shell script
+[zk: localhost:2181(CONNECTED) 10] get
/dubbo/metadata/org.apache.dubbo.demo.DemoService/consumer/demo-consumer
+{"side":"consumer","interface":"org.apache.dubbo.demo.DemoService","metadata-type":"remote","application":"demo-consumer","dubbo":"2.0.2","release":"","sticky":"false","check":"false","methods":"sayHello,sayHelloAsync"}
+cZxid = 0x25aa24
+ctime = Mon Jun 28 21:57:43 CST 2021
+mZxid = 0x25aa24
+mtime = Mon Jun 28 21:57:43 CST 2021
+pZxid = 0x25aa24
+cversion = 0
+dataVersion = 0
+aclVersion = 0
+ephemeralOwner = 0x0
+dataLength = 219
+numChildren = 0
+```
+
+### 4.2 [地址发现 - 接口-应用名映射](../overview/2-地址发现元数据)
+在Dubbo 3.0
中，默认使用了服务自省机制去实现服务发现，关于服务自省可以查看[服务自省](https://mercyblitz.github.io/2020/05/11/Apache-Dubbo-%E6%9C%8D%E5%8A%A1%E8%87%AA%E7%9C%81%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/)
+
+简而言之，服务自省机制需要能够通过 interface name 去找到对应的 application name，这个关系可以是一对多的，即一个
service name 可能会对应多个不同的 application name。在 3.0 中，元数据中心提供此项映射的能力。
+
+
+##### Zookeeper
+在上面提到，service name 和 application name 可能是一对多的，在 zookeeper 中，使用单个 key-value
进行保存，多个 application name 通过英文逗号`,`隔开。由于是单个 key-value
去保存数据，在多客户端的情况下可能会存在并发覆盖的问题。因此，我们使用 zookeeper 中的版本机制 version 去解决该问题。在 zookeeper
中，每一次对数据进行修改，dataVersion 都会进行增加，我们可以利用 version
这个机制去解决多个客户端同时更新映射的并发问题。不同客户端在更新之前，先去查一次 version，当作本地凭证。在更新时，把凭证 version
传到服务端比对 version, 如果不一致说明在次期间被其他客户端修改过，重新获取凭证再进行重试(CAS)。目前如果重试6次都失败的话，放弃本次更新映射行为。
+
+Curator api.
+```java
+CuratorFramework client = ...
+client.setData().withVersion(ticket).forPath(path, dataBytes);
+```
+
+映射信息位于:
+```text
+/dubbo/mapping/{service name}
+```
+
+通过 zkCli get 操作查看数据.
+
+```shell script
+[zk: localhost:2181(CONNECTED) 26] get
/dubbo/mapping/org.apache.dubbo.demo.DemoService
+demo-provider,two-demo-provider,dubbo-demo-annotation-provider
+cZxid = 0x25a80f
+ctime = Thu Jun 10 01:36:40 CST 2021
+mZxid = 0x25a918
+mtime = Fri Jun 11 18:46:40 CST 2021
+pZxid = 0x25a80f
+cversion = 0
+dataVersion = 2
+aclVersion = 0
+ephemeralOwner = 0x0
+dataLength = 62
+numChildren = 0
+```
+
+### 4.3 [地址发现 - 接口配置元数据](../overview/2-地址发现元数据)
+
+要开启远程接口配置元数据注册，需在应用中增加以下配置，因为默认情况下 Dubbo3 应用级服务发现会启用服务自省模式，并不会注册数据到元数据中心。
+
+```properties
+ dubbo.application.metadata-type=remote
+ ```
+
+或者，在自省模式模式下仍开启中心化元数据注册
+
+```properties
+dubbo.application.metadata-type=local
+dubbo.metadata-report.report-metadata=true
+```
+
+Zookeeper 的应用级别元数据位于 /dubbo/metadata/{application name}/{revision}
+
+```shell script
+[zk: localhost:2181(CONNECTED) 33] get
/dubbo/metadata/demo-provider/da3be833baa2088c5f6776fb7ab1a436
+{"app":"demo-provider","revision":"da3be833baa2088c5f6776fb7ab1a436","services":{"org.apache.dubbo.demo.DemoService:dubbo":{"name":"org.apache.dubbo.demo.DemoService","protocol":"dubbo","path":"org.apache.dubbo.demo.DemoService","params":{"side":"provider","release":"","methods":"sayHello,sayHelloAsync","deprecated":"false","dubbo":"2.0.2","pid":"38298","interface":"org.apache.dubbo.demo.DemoService","service-name-mapping":"true","timeout":"3000","generic":"false","metadata-type":"remote
[...]
+cZxid = 0x25b336
+ctime = Thu Jul 22 01:05:55 CST 2021
+mZxid = 0x25b336
+mtime = Thu Jul 22 01:05:55 CST 2021
+pZxid = 0x25b336
+cversion = 0
+dataVersion = 0
+aclVersion = 0
+ephemeralOwner = 0x0
+dataLength = 1286
+numChildren = 0
+```
+
+
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
b/content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
index f5e36dd6a4..c6e3d94c25 100644
--- a/content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
+++ b/content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
@@ -1,7 +1,7 @@
---
type: docs
-title: "基准测试"
-linkTitle: "基准测试"
+title: "应用级服务发现基准测试"
+linkTitle: "应用级服务发现基准"
weight: 1
description: ""
---
@@ -14,10 +14,6 @@ description: ""
- 服务发现资源利用率显著提升。
- 对比接口级服务发现，单机常驻内存下降 50%，地址变更期 GC 消耗下降一个数量级 (百次 -> 十次)
- 对比应用级服务发现，单机常驻内存下降 75%，GC 次数趋零
-- Dubbo 协议性能持平，Triple 协议在网关、Stream吞吐量方面更具优势。
- - Dubbo协议 （3.0 vs 2.x），3.0 实现较 2.x 总体 qps rt 持平，略有提升
- - Triple协议 vs Dubbo协议，直连调用场景 Triple 性能并无优势，其优势在网关、Stream调用场景。
-
以下是详细压测过程与数据
@@ -50,57 +46,3 @@ description: ""
- Dubbo3 接口级服务发现模型，YGC 次数 2.x 版本大幅下降，从数百次下降到十几次
- Dubbo3 应用级服务发现模型，FGC 次数 2.x 版本大幅下降，从数百次下降到零次
-
-
-
-## 3 RPC 协议（远程调用链路）
-
-- Dubbo3 的 _Dubbo协议 _实现与 Dubbo2 版本在性能上基本持平。
-- 由于 Triple协议 本身是基于 HTTP/2 构建，因此在单条链路上的 RPC 调用并未比基于 TCP 的 Dubbo2
有提升，反而在某些调用场景出现一定下降。但 _Triple协议 _更大的优势在于网关穿透性、通用性，以及 Stream 通信模型带来的总体吞吐量提升。
-- Triple 预期在网关代理场景下一定会有更好的性能表现，鉴于当前压测环境，本轮 benchmark 暂未提供。
-
-
-
-### 3.1 环境
-
-
-| | 描述 |
-| ------------ | ------------------------------------------------------------ |
-| **机器** | 4C8G Linux JDK 1.8（Provider）4C8G Linux JDK 1.8 （Consumer） |
-| **压测用例** | RPC 方法类型包括：无参无返回值、普通pojo返回值、pojo列表返回值<br /><br />2.7 版本 Dubbo
协议（Hessian2 序列化）<br />3.0 版本 Dubbo 协议（Hessian2 序列化）<br />3.0 版本 Dubbo
协议（Protobuf 序列化）<br />3.0 版本 Triple 协议（Protobuf 序列化）<br />3.0 版本 Triple
协议（Protobuf 套 Hessian2 序列化） |
-| **压测方法** | 单链接场景下，消费端起 32 并发线程（当前机器配置 qps rt 较均衡的并发数），持续压后采集压测数据<br />
压测数据通过 https://github.com/apache/dubbo-benchmark 得出 |
-
-<br />
-
-### 3.2 数据分析
-
-| | **Dubbo + Hessian2<br />2.7** | **Dubbo + Hessian2<br
/>3.0** | **Dubbo + Protobuf<br />3.0** | **Triple + Protobuf<br />3.0** |
**Triple + Protobuf(Hessian)<br />3.0** |
-| ------------------ | ----------------------------- |
----------------------------- | ----------------------------- |
------------------------------ | --------------------------------------- |
-| **无参方法** | 30333 ops/s<br />2.5ms P99 | 30414 ops/s<br />2.4ms P99
| 24123 ops/s<br />3.2ms P99 | 7016 ops/s<br />8.7ms P99 | 6635
ops/s<br />9.1ms P99 |
-| **pojo返回值** | 8984 ops/s<br />6.1 ms P99 | 12279 ops/s<br />5.7 ms
P99 | 21479 ops/s<br />3.0 ms P99 | 6255 ops/s<br />8.9 ms P99 | 6491
ops/s<br />10 ms P99 |
-| **pojo列表返回值** | 1916 ops/s<br />34 ms P99 | 2037 ops/s<br />34 ms P99
| 12722 ops/s<br />7.7 ms P99 | 6920 ops/s<br />9.6 ms P99 | 2833
ops/s<br />27 ms P99 |
-
-#### 3.2.1 Dubbo 协议不同版本实现对比
-
-
-
-<br />图三 Dubbo协议在不同版本的实现对比<br />
-
-- 就 Dubbo RPC + Hessian 的默认组合来说，Dubbo3 与 Dubbo2 在性能上在不同调用场景下基本持平
-
-#### 3.2.2 Dubbo协议 vs Triple协议
-
-
-
-<br />图四 Triple vs Dubbo<br />
-
-- 单纯看 Consumer <-> Provider 的点对点调用，可以看出 Triple 协议本身并不占优势，同样使用 Protobuf
序列化方式，Dubbo RPC 协议总体性能还是要优于 Triple。<br /><br />
-- Triple 实现在 3.0 版本中将会得到持续优化，但不能完全改变在某些场景下“基于 HTTP/2 的 RPC 协议”对比“基于 TCP 的 RPC
协议”处于劣势的局面
-
-#### 3.2.3 补充网关场景
-
-TBD<br /><br />
-
-#### 3.3.4 模拟 Stream 通信场景的吞吐量提升
-
-TBD
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
b/content/zh/docs3-v2/java-sdk/reference-manual/performance/rpc-benchmarking.md
similarity index 54%
copy from
content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
copy to
content/zh/docs3-v2/java-sdk/reference-manual/performance/rpc-benchmarking.md
index f5e36dd6a4..ab3b87b2bd 100644
--- a/content/zh/docs3-v2/java-sdk/reference-manual/performance/benchmarking.md
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/performance/rpc-benchmarking.md
@@ -1,67 +1,16 @@
---
type: docs
-title: "基准测试"
-linkTitle: "基准测试"
+title: "RPC 协议 Triple&Dubbo 基准测试"
+linkTitle: "RPC 基准"
weight: 1
description: ""
---
-
-## 1 Benchmark 结论
-
-对比 2.x 版本，Dubbo3 版本
-
-- 服务发现资源利用率显著提升。
- - 对比接口级服务发现，单机常驻内存下降 50%，地址变更期 GC 消耗下降一个数量级 (百次 -> 十次)
- - 对比应用级服务发现，单机常驻内存下降 75%，GC 次数趋零
-- Dubbo 协议性能持平，Triple 协议在网关、Stream吞吐量方面更具优势。
- - Dubbo协议 （3.0 vs 2.x），3.0 实现较 2.x 总体 qps rt 持平，略有提升
- - Triple协议 vs Dubbo协议，直连调用场景 Triple 性能并无优势，其优势在网关、Stream调用场景。
-
-
-
-以下是详细压测过程与数据
-
-## 2 应用级服务发现（地址推送链路）
-
-此部分压测数据是由工商银行 Dubbo 团队基于内部生产数据给出，压测过程模拟了“生产环境地址+zookeeper”的服务发现架构。
-
-### 2.1 环境
-
-| | 描述 |
-| ------------ | ------------------------------------------------------------ |
-| **压测数据** |
提供者<br/>500运行实例✖️8interface✖️5protocol，即每个提供者向注册中心注册40个URL，总计20000个URL，每个URL字符长度约1k。<br/><br/>注册中心<br/>2个独立zookeeper注册中心，服务提供者消费者采用并行配置。<br/><br/>消费者<br/>配置1c2g，xmx=768，开启GC，从2个注册中心订阅，每5秒调用一次服务。运行20小时。
|
-| **压测环境** | Java version "1.8.0"<br/>Java(TM) SE Runtime Enviroment (build
pxa6480sr3fp12-20160919_01(SR3 FP12))<br/>IBM J9 VM (Build 2.8, JRE 1.8.0 Linux
amd64-64 Compressed References 20160915_318796, JIT enabled, AOT enabled) |
-
-
-### 2.2 数据分析
-
-
-
-<br />图一 服务发现模型内存占用变化<br /><br />
-
-- Dubbo3 接口级服务发现模型，常驻内存较 2.x 版本下降约 50%
-- Dubbo3 应用级服务发现模型，常驻内存较 2.x 版本下降约 75%
-
-
-
-
-<br />图二 服务发现模型 GC 变化<br /><br />
-
-- Dubbo3 接口级服务发现模型，YGC 次数 2.x 版本大幅下降，从数百次下降到十几次
-- Dubbo3 应用级服务发现模型，FGC 次数 2.x 版本大幅下降，从数百次下降到零次
-
-
-
-## 3 RPC 协议（远程调用链路）
-
- Dubbo3 的 _Dubbo协议 _实现与 Dubbo2 版本在性能上基本持平。
- 由于 Triple协议 本身是基于 HTTP/2 构建，因此在单条链路上的 RPC 调用并未比基于 TCP 的 Dubbo2
有提升，反而在某些调用场景出现一定下降。但 _Triple协议 _更大的优势在于网关穿透性、通用性，以及 Stream 通信模型带来的总体吞吐量提升。
- Triple 预期在网关代理场景下一定会有更好的性能表现，鉴于当前压测环境，本轮 benchmark 暂未提供。
-
-
-### 3.1 环境
+## 1.1 环境
| | 描述 |
@@ -72,7 +21,7 @@ description: ""
<br />
-### 3.2 数据分析
+## 1.2 数据分析
| | **Dubbo + Hessian2<br />2.7** | **Dubbo + Hessian2<br
/>3.0** | **Dubbo + Protobuf<br />3.0** | **Triple + Protobuf<br />3.0** |
**Triple + Protobuf(Hessian)<br />3.0** |
| ------------------ | ----------------------------- |
----------------------------- | ----------------------------- |
------------------------------ | --------------------------------------- |
@@ -80,7 +29,7 @@ description: ""
| **pojo返回值** | 8984 ops/s<br />6.1 ms P99 | 12279 ops/s<br />5.7 ms
P99 | 21479 ops/s<br />3.0 ms P99 | 6255 ops/s<br />8.9 ms P99 | 6491
ops/s<br />10 ms P99 |
| **pojo列表返回值** | 1916 ops/s<br />34 ms P99 | 2037 ops/s<br />34 ms P99
| 12722 ops/s<br />7.7 ms P99 | 6920 ops/s<br />9.6 ms P99 | 2833
ops/s<br />27 ms P99 |
-#### 3.2.1 Dubbo 协议不同版本实现对比
+### 1.2.1 Dubbo 协议不同版本实现对比
@@ -88,7 +37,7 @@ description: ""
- 就 Dubbo RPC + Hessian 的默认组合来说，Dubbo3 与 Dubbo2 在性能上在不同调用场景下基本持平
-#### 3.2.2 Dubbo协议 vs Triple协议
+### 1.2.2 Dubbo协议 vs Triple协议
@@ -97,10 +46,10 @@ description: ""
- 单纯看 Consumer <-> Provider 的点对点调用，可以看出 Triple 协议本身并不占优势，同样使用 Protobuf
序列化方式，Dubbo RPC 协议总体性能还是要优于 Triple。<br /><br />
- Triple 实现在 3.0 版本中将会得到持续优化，但不能完全改变在某些场景下“基于 HTTP/2 的 RPC 协议”对比“基于 TCP 的 RPC
协议”处于劣势的局面
-#### 3.2.3 补充网关场景
+### 1.2.3 补充网关场景
TBD<br /><br />
-#### 3.3.4 模拟 Stream 通信场景的吞吐量提升
+### 1.3.4 模拟 Stream 通信场景的吞吐量提升
TBD
diff --git
a/content/zh/docs3-v2/java-sdk/reference-manual/spi/description/metadata-report.md
b/content/zh/docs3-v2/java-sdk/reference-manual/spi/description/metadata-report.md
new file mode 100644
index 0000000000..3f442a2db4
--- /dev/null
+++
b/content/zh/docs3-v2/java-sdk/reference-manual/spi/description/metadata-report.md
@@ -0,0 +1,91 @@
+---
+type: docs
+title: "元数据中心扩展"
+linkTitle: "元数据中心扩展"
+weight: 13
+---
+
+## 设计目的
+请参见 [元数据中心手册](../../../metadata-center/overview/)
+
+## 扩展接口
+
+* `org.apache.dubbo.metadata.store.MetadataReportFactory`
+* `org.apache.dubbo.metadata.store.MetadataReport`
+
+## 已知扩展
+
+## 实现原理
+
+### SPI定义
+
+参考：org.apache.dubbo.metadata.store.MetadataReportFactory，org.apache.dubbo.metadata.store.MetadataReport
+
+```java
+@SPI("redis")
+public interface MetadataReportFactory {
+ @Adaptive({"protocol"})
+ MetadataReport getMetadataReport(URL url);
+}
+```
+
+
+
+### 自定义元数据的存储
+
+下面以Redis存储为例进行说明。
+
+新建一个project，需要支持以下修改：
+
+#### 扩展AbstractMetadataReport
+
+```java
+public class RedisMetadataReport extends AbstractMetadataReport {
+ private final static Logger logger =
LoggerFactory.getLogger(RedisMetadataReport.class);
+ final JedisPool pool;
+
+ public RedisMetadataReport(URL url) {
+ super(url);
+ pool = new JedisPool(new JedisPoolConfig(), url.getHost(),
url.getPort());
+ }
+ @Override
+ protected void doStoreProviderMetadata(ProviderMetadataIdentifier
providerMetadataIdentifier, String serviceDefinitions) {
+ this.storeMetadata(providerMetadataIdentifier, serviceDefinitions);
+ }
+ @Override
+ protected void doStoreConsumerMetadata(ConsumerMetadataIdentifier
consumerMetadataIdentifier, String value) {
+ this.storeMetadata(consumerMetadataIdentifier, value);
+ }
+ private void storeMetadata(MetadataIdentifier metadataIdentifier, String
v) {
+ try (Jedis jedis = pool.getResource()) {
+ jedis.set(metadataIdentifier.getIdentifierKey() +
META_DATA_SOTRE_TAG, v);
+ } catch (Throwable e) {
+ logger.error("Failed to put " + metadataIdentifier + " to redis "
+ v + ", cause: " + e.getMessage(), e);
+ throw new RpcException("Failed to put " + metadataIdentifier + "
to redis " + v + ", cause: " + e.getMessage(), e);
+ }
+ }
+}
+```
+
+#### 扩展 AbstractMetadataReportFactory
+
+```java
+public class RedisMetadataReportFactory extends AbstractMetadataReportFactory {
+ @Override
+ public MetadataReport createMetadataReport(URL url) {
+ return new RedisMetadataReport(url);
+ }
+}
+```
+
+#### 增加 MetadataReportFactory
+
+> META-INF/dubbo/internal/org.apache.dubbo.metadata.store.MetadataReportFactory
+
+```properties
+redis=org.apache.dubbo.metadata.store.redis.RedisMetadataReportFactory
+```
+
+只要将上面的修改和project打包成jar包，然后配置元数据中心的url：redis://10.20.153.10:6379。
+
+至此，一个自定义的元数据存储就可以运行了。
\ No newline at end of file
