You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by li...@apache.org on 2021/06/04 02:29:33 UTC
[dubbo-website] branch master updated: reorganize v3 doc content
(#819)
This is an automated email from the ASF dual-hosted git repository.
liujun 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 fd58653 reorganize v3 doc content (#819)
fd58653 is described below
commit fd586539ddbf3bf361ed1954ecd98abb65b621da
Author: ken.lj <ke...@gmail.com>
AuthorDate: Fri Jun 4 10:29:25 2021 +0800
reorganize v3 doc content (#819)
---
content/zh/docs/v3.0/advanced/_index.md | 2 +-
content/zh/docs/v3.0/concepts/configuration.md | 12 +-
.../concepts/registry-configcenter-metadata.md | 2 +-
.../docs/v3.0/examples/configuration-override.md | 8 +
content/zh/docs/v3.0/examples/idl-service.md | 9 +
content/zh/docs/v3.0/examples/quick-start.md | 4 +-
.../routerule.md => examples/routing-rule.md} | 0
content/zh/docs/v3.0/examples/service-discovery.md | 8 +
content/zh/docs/v3.0/languages/_index.md | 9 +
content/zh/docs/v3.0/languages/erlang/_index.md | 9 +
.../zh/docs/v3.0/languages/erlang/quick-start.md | 66 ++
content/zh/docs/v3.0/languages/erlang/reference.md | 24 +
.../zh/docs/v3.0/languages/erlang/serialization.md | 27 +
content/zh/docs/v3.0/languages/erlang/service.md | 30 +
content/zh/docs/v3.0/references/_index.md | 9 -
.../docs/v3.0/references/configuration/_index.md | 7 +
.../v3.0/references/configuration/annotation.md | 97 ++
.../zh/docs/v3.0/references/configuration/api.md | 127 ++
.../v3.0/references/configuration/config-center.md | 149 +++
.../configuration/configuration-load-process.md | 180 +++
.../configuration/environment-variables.md | 35 +
.../v3.0/references/configuration/properties.md | 44 +
.../references/configuration/references/_index.md | 7 +
.../references/configuration/references/api.md | 71 ++
.../references/configuration/references/maven.md | 26 +
.../configuration/references/metadata.md | 391 ++++++
.../configuration/references/protocol/_index.md | 10 +
.../configuration/references/protocol/dubbo.md | 129 ++
.../configuration/references/protocol/gRPC.md | 25 +
.../configuration/references/protocol/hessian.md | 74 ++
.../configuration/references/protocol/http.md | 65 +
.../configuration/references/protocol/memcached.md | 53 +
.../configuration/references/protocol/redis.md | 54 +
.../configuration/references/protocol/rest.md | 748 ++++++++++++
.../configuration/references/protocol/rmi.md | 92 ++
.../configuration/references/protocol/thrift.md | 45 +
.../references/protocol/webservice.md | 119 ++
.../references/configuration/references/qos.md | 243 ++++
.../configuration/references/registry/_index.md | 9 +
.../configuration/references/registry/multicast.md | 46 +
.../configuration/references/registry/nacos.md | 135 +++
.../configuration/references/registry/redis.md | 86 ++
.../configuration/references/registry/simple.md | 55 +
.../configuration/references/registry/zookeeper.md | 167 +++
.../references/configuration/references/telnet.md | 111 ++
.../configuration/references/xml/_index.md | 20 +
.../references/xml/dubbo-application.md | 20 +
.../configuration/references/xml/dubbo-argument.md | 20 +
.../references/xml/dubbo-config-center.md | 25 +
.../configuration/references/xml/dubbo-consumer.md | 30 +
.../configuration/references/xml/dubbo-method.md | 36 +
.../configuration/references/xml/dubbo-module.md | 16 +
.../configuration/references/xml/dubbo-monitor.md | 14 +
.../references/xml/dubbo-parameter.md | 28 +
.../configuration/references/xml/dubbo-protocol.md | 36 +
.../configuration/references/xml/dubbo-provider.md | 56 +
.../references/xml/dubbo-reference.md | 40 +
.../configuration/references/xml/dubbo-registry.md | 30 +
.../configuration/references/xml/dubbo-service.md | 43 +
.../zh/docs/v3.0/references/configuration/xml.md | 98 ++
content/zh/docs/v3.0/references/features/_index.md | 12 +
.../zh/docs/v3.0/references/features/accesslog.md | 21 +
.../zh/docs/v3.0/references/features/async-call.md | 139 +++
.../features/async-execute-on-provider.md | 102 ++
.../zh/docs/v3.0/references/features/attachment.md | 38 +
content/zh/docs/v3.0/references/features/auth.md | 28 +
.../v3.0/references/features/callback-parameter.md | 120 ++
.../references/features/concurrency-control.md | 74 ++
.../v3.0/references/features/config-connections.md | 41 +
.../references/features/config-rule-deprecated.md | 57 +
.../docs/v3.0/references/features/config-rule.md | 177 +++
.../references/features/consumer-threadpool.md | 45 +
.../zh/docs/v3.0/references/features/context.md | 46 +
.../docs/v3.0/references/features/delay-publish.md | 59 +
.../references/features/distributed-transaction.md | 15 +
content/zh/docs/v3.0/references/features/dump.md | 26 +
.../docs/v3.0/references/features/echo-service.md | 29 +
.../docs/v3.0/references/features/events-notify.md | 108 ++
.../v3.0/references/features/explicit-target.md | 58 +
.../references/features/fault-tolerent-strategy.md | 104 ++
.../v3.0/references/features/generic-reference.md | 103 ++
.../v3.0/references/features/generic-service.md | 51 +
.../v3.0/references/features/graceful-shutdown.md | 41 +
.../docs/v3.0/references/features/group-merger.md | 67 ++
.../v3.0/references/features/hostname-binding.md | 64 +
.../docs/v3.0/references/features/lazy-connect.md | 18 +
.../docs/v3.0/references/features/loadbalance.md | 66 ++
.../zh/docs/v3.0/references/features/local-call.md | 55 +
.../zh/docs/v3.0/references/features/local-mock.md | 106 ++
.../zh/docs/v3.0/references/features/local-stub.md | 50 +
.../v3.0/references/features/logger-strategy.md | 29 +
.../v3.0/references/features/multi-protocols.md | 53 +
.../v3.0/references/features/multi-registry.md | 90 ++
.../v3.0/references/features/multi-versions.md | 49 +
content/zh/docs/v3.0/references/features/netty4.md | 46 +
.../references/features/parameter-validation.md | 193 +++
.../references/features/pb-generic-reference.md | 102 ++
.../v3.0/references/features/preflight-check.md | 61 +
.../docs/v3.0/references/features/protobuf-idl.md | 38 +
.../references/features/reference-config-cache.md | 43 +
.../docs/v3.0/references/features/registry-only.md | 23 +
.../docs/v3.0/references/features/result-cache.md | 38 +
.../references/features/routing-rule-deprecated.md | 199 ++++
.../docs/v3.0/references/features/routing-rule.md | 257 ++++
.../docs/v3.0/references/features/serialization.md | 85 ++
.../v3.0/references/features/service-container.md | 67 ++
.../v3.0/references/features/service-downgrade.md | 27 +
.../docs/v3.0/references/features/service-group.md | 33 +
.../zh/docs/v3.0/references/features/set-host.md | 75 ++
.../references/features/simplify-registry-data.md | 262 +++++
.../v3.0/references/features/static-service.md | 31 +
.../zh/docs/v3.0/references/features/stickiness.md | 24 +
.../v3.0/references/features/subscribe-only.md | 25 +
.../docs/v3.0/references/features/thread-model.md | 37 +
content/zh/docs/v3.0/references/features/tls.md | 51 +
.../references/features/token-authorization.md | 37 +
content/zh/docs/v3.0/references/lifecycle/rest.md | 1243 ++++++++++++++++++++
content/zh/docs/v3.0/references/protocols/rest.md | 1243 ++++++++++++++++++++
.../zh/docs/v3.0/references/{ => protocols}/tri.md | 0
content/zh/docs/v3.0/references/routers/_index.md | 7 +
.../v3.0/references/{ => routers}/routerule.md | 0
.../references/serializations/serialization.md | 222 ++++
content/zh/docs/v3.0/references/spis/_index.md | 9 +
content/zh/docs/v3.0/references/spis/cache.md | 88 ++
content/zh/docs/v3.0/references/spis/cluster.md | 79 ++
content/zh/docs/v3.0/references/spis/compiler.md | 60 +
.../zh/docs/v3.0/references/spis/config-center.md | 103 ++
content/zh/docs/v3.0/references/spis/container.md | 67 ++
content/zh/docs/v3.0/references/spis/dispatcher.md | 67 ++
content/zh/docs/v3.0/references/spis/exchanger.md | 96 ++
.../docs/v3.0/references/spis/exporter-listener.md | 71 ++
.../docs/v3.0/references/spis/extension-factory.md | 62 +
content/zh/docs/v3.0/references/spis/filter.md | 94 ++
.../docs/v3.0/references/spis/invoker-listener.md | 69 ++
.../zh/docs/v3.0/references/spis/load-balance.md | 68 ++
.../zh/docs/v3.0/references/spis/logger-adapter.md | 89 ++
content/zh/docs/v3.0/references/spis/merger.md | 65 +
content/zh/docs/v3.0/references/spis/monitor.md | 80 ++
content/zh/docs/v3.0/references/spis/networker.md | 64 +
content/zh/docs/v3.0/references/spis/page.md | 61 +
content/zh/docs/v3.0/references/spis/protocol.md | 157 +++
.../zh/docs/v3.0/references/spis/proxy-factory.md | 70 ++
content/zh/docs/v3.0/references/spis/registry.md | 210 ++++
content/zh/docs/v3.0/references/spis/remoting.md | 127 ++
content/zh/docs/v3.0/references/spis/router.md | 69 ++
content/zh/docs/v3.0/references/spis/serialize.md | 77 ++
.../zh/docs/v3.0/references/spis/status-checker.md | 69 ++
.../zh/docs/v3.0/references/spis/telnet-handler.md | 82 ++
content/zh/docs/v3.0/references/spis/threadpool.md | 66 ++
content/zh/docs/v3.0/references/spis/validation.md | 80 ++
150 files changed, 13021 insertions(+), 19 deletions(-)
diff --git a/content/zh/docs/v3.0/advanced/_index.md b/content/zh/docs/v3.0/advanced/_index.md
index 31ed9a3..224d0fc 100755
--- a/content/zh/docs/v3.0/advanced/_index.md
+++ b/content/zh/docs/v3.0/advanced/_index.md
@@ -3,7 +3,7 @@
type: docs
title: "高级用法"
linkTitle: "高级用法"
-weight: 40
+weight: 30
description: "Dubbo 3.0 文档"
---
diff --git a/content/zh/docs/v3.0/concepts/configuration.md b/content/zh/docs/v3.0/concepts/configuration.md
index 6812482..b13b460 100644
--- a/content/zh/docs/v3.0/concepts/configuration.md
+++ b/content/zh/docs/v3.0/concepts/configuration.md
@@ -1,7 +1,7 @@
---
-type: docs
-title: "配置管理"
-linkTitle: "配置"
-weight: 4
-description: "描述 Dubbo 支持的配置，Dubbo 的动态配置能力。"
----
\ No newline at end of file
+ type: docs
+ title: "配置管理"
+ linkTitle: "配置"
+ weight: 4
+ description: "描述 Dubbo 支持的配置，Dubbo 的动态配置能力。"
+ ---
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md b/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md
index 8d45e23..ad827f7 100644
--- a/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md
+++ b/content/zh/docs/v3.0/concepts/registry-configcenter-metadata.md
@@ -1,6 +1,6 @@
---
type: docs
-title: "Dubbo 部署架构（注册中心 配置中心 元数据中心）"
+title: "部署架构（注册中心 配置中心 元数据中心）"
linkTitle: "部署架构"
weight: 5
description: "了解 Dubbo 的三大中心化组件，它们各自的职责、工作方式。"
diff --git a/content/zh/docs/v3.0/examples/configuration-override.md b/content/zh/docs/v3.0/examples/configuration-override.md
new file mode 100644
index 0000000..59341dc
--- /dev/null
+++ b/content/zh/docs/v3.0/examples/configuration-override.md
@@ -0,0 +1,8 @@
+---
+type: docs
+title: "动态修改运行态配置项"
+linkTitle: "动态配置"
+weight: 50
+description: "了解 Dubbo Override 配置规则的工作方式，示例展示如何在运行态修改服务权重与超时时间。"
+---
+
diff --git a/content/zh/docs/v3.0/examples/idl-service.md b/content/zh/docs/v3.0/examples/idl-service.md
new file mode 100644
index 0000000..bdaebe0
--- /dev/null
+++ b/content/zh/docs/v3.0/examples/idl-service.md
@@ -0,0 +1,9 @@
+---
+type: docs
+title: "使用 IDL 定义 Dubbo 服务"
+linkTitle: "服务定义"
+weight: 20
+description: "尝试使用 IDL 定义服务"
+---
+
+
diff --git a/content/zh/docs/v3.0/examples/quick-start.md b/content/zh/docs/v3.0/examples/quick-start.md
index 30e0ddf..0c05975 100644
--- a/content/zh/docs/v3.0/examples/quick-start.md
+++ b/content/zh/docs/v3.0/examples/quick-start.md
@@ -2,11 +2,11 @@
type: docs
title: "快速开始"
linkTitle: "快速开始"
-weight: 1
+weight: 10
description: ""
---
-Dubbo 集成了多种开发模式
+Dubbo 集成了多种开发模式，以下简单
* Raw API
* Spring / Spring Boot Starter
* 配置文件
diff --git a/content/zh/docs/v3.0/references/routerule.md b/content/zh/docs/v3.0/examples/routing-rule.md
similarity index 100%
copy from content/zh/docs/v3.0/references/routerule.md
copy to content/zh/docs/v3.0/examples/routing-rule.md
diff --git a/content/zh/docs/v3.0/examples/service-discovery.md b/content/zh/docs/v3.0/examples/service-discovery.md
new file mode 100644
index 0000000..c87c552
--- /dev/null
+++ b/content/zh/docs/v3.0/examples/service-discovery.md
@@ -0,0 +1,8 @@
+---
+type: docs
+title: "应用级服务发现"
+linkTitle: "服务发现"
+weight: 30
+description: ""
+---
+
diff --git a/content/zh/docs/v3.0/languages/_index.md b/content/zh/docs/v3.0/languages/_index.md
new file mode 100755
index 0000000..fe6231a
--- /dev/null
+++ b/content/zh/docs/v3.0/languages/_index.md
@@ -0,0 +1,9 @@
+
+---
+type: docs
+title: "多语言实现"
+linkTitle: "多语言"
+weight: 60
+description: "Dubbo 社区提供了丰富的多语言 sdk 支持，请在此了解每种语言的特殊用法"
+---
+
diff --git a/content/zh/docs/v3.0/languages/erlang/_index.md b/content/zh/docs/v3.0/languages/erlang/_index.md
new file mode 100755
index 0000000..1f969c9
--- /dev/null
+++ b/content/zh/docs/v3.0/languages/erlang/_index.md
@@ -0,0 +1,9 @@
+
+---
+type: docs
+title: "Erlang"
+linkTitle: "Erlang"
+weight: 200
+description: "Erlang 支持"
+---
+
diff --git a/content/zh/docs/v3.0/languages/erlang/quick-start.md b/content/zh/docs/v3.0/languages/erlang/quick-start.md
new file mode 100644
index 0000000..d57c422
--- /dev/null
+++ b/content/zh/docs/v3.0/languages/erlang/quick-start.md
@@ -0,0 +1,66 @@
+---
+type: docs
+title: "快速开始"
+linkTitle: "快速开始"
+weight: 1
+description: "Erlang 快速开始"
+---
+
+建议先使用 java 定义接口 jar，并使用 [erlanalysis](https://github.com/apache/dubbo-erlang/tree/master/tools/erlanalysis) 工具解析java接口至Erlang lib
+
+## 导入依赖库
+
+### 使用 Rebar 编译工具。
+Add dubblerl to rebar.config with your project
+```erlang
+{deps, [
+ {dubboerl, {git, "https://github.com/apache/dubbo-erlang.git", {branch, "master"}}}
+]}.
+```
+
+### 使用 erlang.mk 编译工具
+`待补充`
+
+## 导入接口库
+Suppose the interface lib you exported is called dubbo_service.
+* If you didn't upload your lib to your git repository, It is recommended that you copy the `dubbo_service` lib
+into the project's `apps` directory.
+* If it is upload to your git repository, you can import like this:
+```erlang
+{deps, [
+ {dubboerl, {git, "https://github.com/apache/dubbo-erlang.git", {branch, "master"}}},
+ {dubbo_service,{git,"${INTERFACE_LIB_URL}",{branch,"master"}}} %% replace ${INTERFACE_LIB_URL} with your lib git repos url
+]}.
+```
+
+## 消费者配置
+Please reference [Reference Config](./reference.md)
+
+## Init dubbolib in your project
+It is need you
+```erlang
+dubboerl:init().
+```
+
+## 如何调用？
+
+### 同步调用
+```erlang
+Request = #userInfoRequest{requestId = 123, username = "testname"},
+{ok,RequestRef,Response,RpcContent} = userOperator:queryUserInfo(Request,#{sync=> true}).
+```
+If it occur error, is reponse `{error,Reason}`.
+
+### 异步调用
+
+Default is Async call.
+```erlang
+Request = #userInfoRequest{requestId = 123, username = "testname"},
+{ok,RequestRef} = userOperator:queryUserInfo(Request).
+
+%% you can receive the message after.
+handle_cast({msg_back,RequestRef,Response,RpcContent},State).
+```
+
+## 示例
+参考项目 [dubboerl_demo](https://github.com/apache/dubbo-erlang/tree/master/samples)
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/languages/erlang/reference.md b/content/zh/docs/v3.0/languages/erlang/reference.md
new file mode 100644
index 0000000..64ab24d
--- /dev/null
+++ b/content/zh/docs/v3.0/languages/erlang/reference.md
@@ -0,0 +1,24 @@
+---
+type: docs
+title: "消费者配置"
+linkTitle: "消费者配置"
+weight: 2
+description: "在 erlang 中配置消费者"
+---
+
+## 基础配置
+
+消费者配置项需要添加到 `sys.config` 文件 `dubboerl` 应用配置项里。
+
+```erlang
+{dubboerl,[
+ %% other config ...
+ {consumer,[
+ {<<"interface fullname">>,[Option]},
+ %% eg:
+ {<<"org.apache.dubbo.erlang.sample.service.facade.UserOperator">>,[]},
+ ]}
+]}
+```
+
+Option 配置项待添加中。
diff --git a/content/zh/docs/v3.0/languages/erlang/serialization.md b/content/zh/docs/v3.0/languages/erlang/serialization.md
new file mode 100644
index 0000000..6957e2a
--- /dev/null
+++ b/content/zh/docs/v3.0/languages/erlang/serialization.md
@@ -0,0 +1,27 @@
+---
+type: docs
+title: "序列化配置项"
+linkTitle: "序列化配置项"
+weight: 4
+description: "在 erlang 中配置序列化方式"
+---
+
+当前该库只实现了 `dubbo://` 通讯协议。
+
+序列化方式实现了 `hessian` 和 `json` 两种方式。
+
+## 配置样例
+
+序列化配置需要添加到 `sys.config` 文件 `dubboerl` 应用配置项里。
+
+```erlang
+{dubboerl,[
+ %% other config ...
+ {protocol,hessian}
+]}
+```
+
+| ConfigName | Type | DefaultValue | Remarks |
+| --- | --- | --- | --- |
+| protocol | atom() | hessian | hessian,json |
+
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/languages/erlang/service.md b/content/zh/docs/v3.0/languages/erlang/service.md
new file mode 100644
index 0000000..e3394e0
--- /dev/null
+++ b/content/zh/docs/v3.0/languages/erlang/service.md
@@ -0,0 +1,30 @@
+---
+type: docs
+title: "提供者配置"
+linkTitle: "提供者配置"
+weight: 3
+description: "在 erlang 中配置服务提供者"
+---
+
+## 基本配置
+
+提供者配置项需要添加到 `sys.config` 文件 `dubboerl` 应用配置项里。
+
+```erlang
+{dubboerl,[
+ %% other config ...
+ {provider,[
+ {module_implements,interface_module,interface_fullname,[Options]},
+ %% eg:
+ {userOperator_impl,userOperator,<<"org.apache.dubbo.erlang.sample.service.facade.UserOperator">>,[Option]}
+ ]}
+]}
+```
+
+| ConfigName | Type | DefaultValue | Remarks |
+| --- | --- | --- | --- |
+| module_implements | atom() | - | The service implements module name|
+| interface_module | atom() | - | Interface module name is transfer form java jar |
+| interface_fullname | binary() | - | Interface full name is the java class name |
+
+Option is to be added.
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/_index.md b/content/zh/docs/v3.0/references/_index.md
deleted file mode 100644
index e1651b9..0000000
--- a/content/zh/docs/v3.0/references/_index.md
+++ /dev/null
@@ -1,9 +0,0 @@
----
-type: docs
-title: "功能参考手册"
-linkTitle: "参考手册"
-weight: 30
-description: "面向用户的参考手册，涵盖了 Dubbo3 的所有核心功能"
----
-
-这篇文档详细讲解了 Dubbo3 的使用，基本涵盖 Dubbo3 的所有功能特性。如果你正依赖 Dubbo3 作为你业务工程的服务框架，这里可以作为你的参考手册。
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/_index.md b/content/zh/docs/v3.0/references/configuration/_index.md
new file mode 100644
index 0000000..a285c52
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/_index.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "Dubbo 配置"
+linkTitle: "配置"
+weight: 5
+description: "以不同的方式来配置你的 Dubbo 应用"
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/annotation.md b/content/zh/docs/v3.0/references/configuration/annotation.md
new file mode 100644
index 0000000..63a1469
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/annotation.md
@@ -0,0 +1,97 @@
+---
+type: docs
+title: "注解配置"
+linkTitle: "注解配置"
+weight: 4
+description: "以注解配置的方式来配置你的 Dubbo 应用"
+---
+
+{{% alert title="提示" color="primary" %}}
+需要 `2.6.3` 及以上版本支持。 点此查看 [完整示例](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-annotation)
+{{% /alert %}}
+
+
+## 服务提供方
+
+### `Service`注解暴露服务
+
+```java
+@Service
+public class AnnotationServiceImpl implements AnnotationService {
+ @Override
+ public String sayHello(String name) {
+ return "annotation: hello, " + name;
+ }
+}
+```
+
+### 增加应用共享配置
+
+```properties
+# dubbo-provider.properties
+dubbo.application.name=annotation-provider
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+dubbo.protocol.name=dubbo
+dubbo.protocol.port=20880
+```
+
+### 指定Spring扫描路径
+
+```java
+@Configuration
+@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.impl")
+@PropertySource("classpath:/spring/dubbo-provider.properties")
+static public class ProviderConfiguration {
+
+}
+```
+
+## 服务消费方
+
+### `Reference`注解引用服务
+
+```java
+@Component("annotationAction")
+public class AnnotationAction {
+
+ @Reference
+ private AnnotationService annotationService;
+
+ public String doSayHello(String name) {
+ return annotationService.sayHello(name);
+ }
+}
+
+```
+
+### 增加应用共享配置
+
+```properties
+# dubbo-consumer.properties
+dubbo.application.name=annotation-consumer
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+dubbo.consumer.timeout=3000
+```
+
+### 指定Spring扫描路径
+
+```java
+@Configuration
+@EnableDubbo(scanBasePackages = "org.apache.dubbo.samples.simple.annotation.action")
+@PropertySource("classpath:/spring/dubbo-consumer.properties")
+@ComponentScan(value = {"org.apache.dubbo.samples.simple.annotation.action"})
+static public class ConsumerConfiguration {
+
+}
+```
+
+### 调用服务
+
+```java
+public static void main(String[] args) throws Exception {
+ AnnotationConfigApplicationContext context = new AnnotationConfigApplicationContext(ConsumerConfiguration.class);
+ context.start();
+ final AnnotationAction annotationAction = (AnnotationAction) context.getBean("annotationAction");
+ String hello = annotationAction.doSayHello("world");
+}
+```
diff --git a/content/zh/docs/v3.0/references/configuration/api.md b/content/zh/docs/v3.0/references/configuration/api.md
new file mode 100644
index 0000000..ba92508
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/api.md
@@ -0,0 +1,127 @@
+---
+type: docs
+title: "API 配置"
+linkTitle: "API 配置"
+weight: 3
+description: "以API 配置的方式来配置你的 Dubbo 应用"
+---
+
+API 属性与配置项一对一，各属性含义，请参见：[配置参考手册](../references/xml/)，比如：`ApplicationConfig.setName("xxx")` 对应 `<dubbo:application name="xxx" />` [^1]
+
+## 服务提供者
+
+```java
+import org.apache.dubbo.rpc.config.ApplicationConfig;
+import org.apache.dubbo.rpc.config.RegistryConfig;
+import org.apache.dubbo.rpc.config.ProviderConfig;
+import org.apache.dubbo.rpc.config.ServiceConfig;
+import com.xxx.XxxService;
+import com.xxx.XxxServiceImpl;
+
+// 服务实现
+XxxService xxxService = new XxxServiceImpl();
+
+// 当前应用配置
+ApplicationConfig application = new ApplicationConfig();
+application.setName("xxx");
+
+// 连接注册中心配置
+RegistryConfig registry = new RegistryConfig();
+registry.setAddress("10.20.130.230:9090");
+registry.setUsername("aaa");
+registry.setPassword("bbb");
+
+// 服务提供者协议配置
+ProtocolConfig protocol = new ProtocolConfig();
+protocol.setName("dubbo");
+protocol.setPort(12345);
+protocol.setThreads(200);
+
+// 注意：ServiceConfig为重对象，内部封装了与注册中心的连接，以及开启服务端口
+
+// 服务提供者暴露服务配置
+ServiceConfig<XxxService> service = new ServiceConfig<XxxService>(); // 此实例很重，封装了与注册中心的连接，请自行缓存，否则可能造成内存和连接泄漏
+service.setApplication(application);
+service.setRegistry(registry); // 多个注册中心可以用setRegistries()
+service.setProtocol(protocol); // 多个协议可以用setProtocols()
+service.setInterface(XxxService.class);
+service.setRef(xxxService);
+service.setVersion("1.0.0");
+
+// 暴露及注册服务
+service.export();
+```
+
+## 服务消费者
+
+```java
+import org.apache.dubbo.rpc.config.ApplicationConfig;
+import org.apache.dubbo.rpc.config.RegistryConfig;
+import org.apache.dubbo.rpc.config.ConsumerConfig;
+import org.apache.dubbo.rpc.config.ReferenceConfig;
+import com.xxx.XxxService;
+
+// 当前应用配置
+ApplicationConfig application = new ApplicationConfig();
+application.setName("yyy");
+
+// 连接注册中心配置
+RegistryConfig registry = new RegistryConfig();
+registry.setAddress("10.20.130.230:9090");
+registry.setUsername("aaa");
+registry.setPassword("bbb");
+
+// 注意：ReferenceConfig为重对象，内部封装了与注册中心的连接，以及与服务提供方的连接
+
+// 引用远程服务
+ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); // 此实例很重，封装了与注册中心的连接以及与提供者的连接，请自行缓存，否则可能造成内存和连接泄漏
+reference.setApplication(application);
+reference.setRegistry(registry); // 多个注册中心可以用setRegistries()
+reference.setInterface(XxxService.class);
+reference.setVersion("1.0.0");
+
+// 和本地bean一样使用xxxService
+XxxService xxxService = reference.get(); // 注意：此代理对象内部封装了所有通讯细节，对象较重，请缓存复用
+```
+
+## 特殊场景
+
+下面只列出不同的地方，其它参见上面的写法
+
+### 方法级设置
+
+```java
+...
+
+// 方法级配置
+List<MethodConfig> methods = new ArrayList<MethodConfig>();
+MethodConfig method = new MethodConfig();
+method.setName("createXxx");
+method.setTimeout(10000);
+method.setRetries(0);
+methods.add(method);
+
+// 引用远程服务
+ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); // 此实例很重，封装了与注册中心的连接以及与提供者的连接，请自行缓存，否则可能造成内存和连接泄漏
+...
+reference.setMethods(methods); // 设置方法级配置
+
+...
+```
+
+### 点对点直连
+
+```java
+
+...
+
+ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>(); // 此实例很重，封装了与注册中心的连接以及与提供者的连接，请自行缓存，否则可能造成内存和连接泄漏
+// 如果点对点直连，可以用reference.setUrl()指定目标地址，设置url后将绕过注册中心，
+// 其中，协议对应provider.setProtocol()的值，端口对应provider.setPort()的值，
+// 路径对应service.setPath()的值，如果未设置path，缺省path为接口名
+reference.setUrl("dubbo://10.20.130.230:20880/com.xxx.XxxService");
+
+...
+```
+
+[^1]: API使用范围说明：API 仅用于 OpenAPI, ESB, Test, Mock 等系统集成，普通服务提供方或消费方，请采用[XML 配置](../xml)方式使用 Dubbo
diff --git a/content/zh/docs/v3.0/references/configuration/config-center.md b/content/zh/docs/v3.0/references/configuration/config-center.md
new file mode 100644
index 0000000..2e6e346
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/config-center.md
@@ -0,0 +1,149 @@
+---
+type: docs
+title: "动态配置中心"
+linkTitle: "动态配置中心"
+weight: 2
+description: "Dubbo 2.7 中的动态配置中心"
+---
+
+配置中心（v2.7.0）在 Dubbo 中承担两个职责：
+
+1. 外部化配置。启动配置的集中式存储 （简单理解为 dubbo.properties 的外部化存储）。
+2. 服务治理。服务治理规则的存储与通知。
+
+启用动态配置，以 Zookeeper 为例，可查看 [动态配置配置项详解](../../references/xml/dubbo-config-center)
+
+```xml
+<dubbo:config-center address="zookeeper://127.0.0.1:2181"/>
+```
+
+或者
+
+```properties
+dubbo.config-center.address=zookeeper://127.0.0.1:2181
+```
+
+或者
+
+```java
+ConfigCenterConfig configCenter = new ConfigCenterConfig();
+configCenter.setAddress("zookeeper://127.0.0.1:2181");
+```
+
+> 为了兼容 2.6.x 版本配置，在使用 Zookeeper 作为注册中心，且没有显示配置配置中心的情况下，Dubbo 框架会默认将此 Zookeeper 用作配置中心，但将只作服务治理用途。
+
+## 外部化配置
+
+外部化配置目的之一是实现配置的集中式管理，这部分业界已经有很多成熟的专业配置系统如 Apollo, Nacos 等，Dubbo 所做的主要是保证能配合这些系统正常工作。
+
+外部化配置和其他本地配置在内容和格式上并无区别，可以简单理解为 `dubbo.properties` 的外部化存储，配置中心更适合将一些公共配置如注册中心、元数据中心配置等抽取以便做集中管理。
+
+```properties
+# 将注册中心地址、元数据中心地址等配置集中管理，可以做到统一环境、减少开发侧感知。
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+dubbo.registry.simplified=true
+
+dubbo.metadata-report.address=zookeeper://127.0.0.1:2181
+
+dubbo.protocol.name=dubbo
+dubbo.protocol.port=20880
+
+dubbo.application.qos.port=33333
+```
+
+- 优先级
+
+ 外部化配置默认较本地配置有更高的优先级，因此这里配置的内容会覆盖本地配置值，关于 [各配置形式间的覆盖关系](../configuration-load-process) 有单独一章说明，你也可通过以下选项调整配置中心的优先级：
+
+ ```properties
+ -Ddubbo.config-center.highest-priority=false
+ ```
+
+- 作用域
+
+ 外部化配置有全局和应用两个级别，全局配置是所有应用共享的，应用级配置是由每个应用自己维护且只对自身可见的。当前已支持的扩展实现有Zookeeper、Apollo。
+
+
+#### Zookeeper
+
+```xml
+<dubbo:config-center address="zookeeper://127.0.0.1:2181"/>
+```
+
+默认所有的配置都存储在 `/dubbo/config` 节点，具体节点结构图如下：
+
+
+
+- namespace，用于不同配置的环境隔离。
+- config，Dubbo约定的固定节点，不可更改，所有配置和服务治理规则都存储在此节点下。
+- dubbo/application，分别用来隔离全局配置、应用级别配置：dubbo是默认group值，application对应应用名
+- dubbo.properties，此节点的node value存储具体配置内容
+
+
+
+#### Apollo
+
+```xml
+<dubbo:config-center protocol="apollo" address="127.0.0.1:2181"/>
+```
+
+Apollo中的一个核心概念是命名空间 - namespace（和上面zookeeper的namespace概念不同），在这里全局和应用级别配置就是通过命名空间来区分的。
+
+默认情况下，Dubbo会从名叫`dubbo`（由于 Apollo 不支持特殊后缀 `.properties` ）的命名空间中读取全局配置（`<dubbo:config-center namespace="your namespace">`）
+
+
+
+由于 Apollo 也默认将会在 `dubbo` namespace 中存储服务治理规则（如路由规则），建议通过单独配置 `group` 将服务治理和配置文件托管分离开，以 XML 配置方式为例：
+```xml
+<dubbo namespace="governance" group ="dubbo"/>
+```
+这里，服务治理规则将存储在 governance namespace，而配置文件将存储在 dubbo namespace，如下图所示：
+
+
+> 关于文件配置托管，相当于是把 `dubbo.properties` 配置文件的内容存储在了 Apollo 中，应用通过关联共享的 `dubbo` namespace 继承公共配置,
+> 应用也可以按照 Apollo 的做法来覆盖个别配置项。
+
+
+#### 自己加载外部化配置
+
+所谓 Dubbo 对配置中心的支持，本质上就是把 `.properties` 从远程拉取到本地，然后和本地的配置做一次融合。理论上只要 Dubbo 框架能拿到需要的配置就可以正常的启动，它并不关心这些配置是自己加载到的还是应用直接塞给它的，所以Dubbo还提供了以下API，让用户将自己组织好的配置塞给 Dubbo 框架（配置加载的过程是用户要完成的），这样 Dubbo 框架就不再直接和 Apollo 或 Zookeeper 做读取配置交互。
+
+```java
+// 应用自行加载配置
+Map<String, String> dubboConfigurations = new HashMap<>();
+dubboConfigurations.put("dubbo.registry.address", "zookeeper://127.0.0.1:2181");
+dubboConfigurations.put("dubbo.registry.simplified", "true");
+
+//将组织好的配置塞给Dubbo框架
+ConfigCenterConfig configCenter = new ConfigCenterConfig();
+configCenter.setExternalConfig(dubboConfigurations);
+```
+
+
+
+## 服务治理
+
+#### Zookeeper
+
+默认节点结构：
+
+
+
+- namespace，用于不同配置的环境隔离。
+- config，Dubbo 约定的固定节点，不可更改，所有配置和服务治理规则都存储在此节点下。
+- dubbo，所有服务治理规则都是全局性的，dubbo 为默认节点
+- configurators/tag-router/condition-router，不同的服务治理规则类型，node value 存储具体规则内容
+
+
+
+#### Apollo
+
+所有的服务治理规则都是全局性的，默认从公共命名空间 `dubbo` 读取和订阅：
+
+
+
+不同的规则以不同的 key 后缀区分：
+
+- configurators，[覆盖规则](../../examples/config-rule)
+- tag-router，[标签路由](../../examples/routing-rule)
+- condition-router，[条件路由](../../examples/routing-rule)
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/configuration-load-process.md b/content/zh/docs/v3.0/references/configuration/configuration-load-process.md
new file mode 100644
index 0000000..6398a70
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/configuration-load-process.md
@@ -0,0 +1,180 @@
+---
+type: docs
+title: "配置加载流程"
+linkTitle: "配置加载流程"
+weight: 5
+description: "Dubbo 中的配置加载流程介绍"
+---
+
+此篇文档主要讲在**应用启动阶段，Dubbo框架如何将所需要的配置采集起来**（包括应用配置、注册中心配置、服务配置等），以完成服务的暴露和引用流程。
+
+根据驱动方式的不同（比如Spring或裸API编程）配置形式上肯定会有所差异，具体请参考[XML配置](../xml)、[Annotation配置](../annotation)、[API配置](../api)三篇文档。除了外围驱动方式上的差异，Dubbo的配置读取总体上遵循了以下几个原则：
+
+1. Dubbo 支持了多层级的配置，并按预定优先级自动实现配置间的覆盖，最终所有配置汇总到数据总线URL后驱动后续的服务暴露、引用等流程。
+2. ApplicationConfig、ServiceConfig、ReferenceConfig 可以被理解成配置来源的一种，是直接面向用户编程的配置采集方式。
+3. 配置格式以 Properties 为主，在配置内容上遵循约定的 `path-based` 的命名[规范](#配置格式)
+
+
+
+## 配置来源
+
+首先，从Dubbo支持的配置来源说起，默认有四种配置来源：
+
+- JVM System Properties，-D 参数
+- Externalized Configuration，外部化配置
+- ServiceConfig、ReferenceConfig 等编程接口采集的配置
+- 本地配置文件 dubbo.properties
+
+### 覆盖关系
+
+下图展示了配置覆盖关系的优先级，从上到下优先级依次降低：
+
+
+
+点此查看[外部化配置详情](../config-center)
+
+
+## 配置格式
+
+目前Dubbo支持的所有配置都是`.properties`格式的，包括`-D`、`Externalized Configuration`等，`.properties`中的所有配置项遵循一种`path-based`的配置格式：
+
+```properties
+# 应用级别
+dubbo.{config-type}[.{config-id}].{config-item}={config-item-value}
+# 服务级别
+dubbo.service.{interface-name}[.{method-name}].{config-item}={config-item-value}
+dubbo.reference.{interface-name}[.{method-name}].{config-item}={config-item-value}
+# 多配置项
+dubbo.{config-type}s.{config-id}.{config-item}={config-item-value}
+```
+
+应用级别
+
+```properties
+dubbo.application.name=demo-provider
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+dubbo.protocol.port=-1
+```
+
+服务级别
+
+```properties
+dubbo.service.org.apache.dubbo.samples.api.DemoService.timeout=5000
+dubbo.reference.org.apache.dubbo.samples.api.DemoService.timeout=6000
+dubbo.reference.org.apache.dubbo.samples.api.DemoService.sayHello.timeout=7000
+```
+
+多配置项
+
+```properties
+dubbo.registries.unit1.address=zookeeper://127.0.0.1:2181
+dubbo.registries.unit2.address=zookeeper://127.0.0.1:2182
+
+dubbo.protocols.dubbo.name=dubbo
+dubbo.protocols.dubbo.port=20880
+dubbo.protocols.hessian.name=hessian
+dubbo.protocols.hessian.port=8089
+```
+
+扩展配置
+
+```properties
+dubbo.application.parameters.item1=value1
+dubbo.application.parameters.item2=value2
+dubbo.registry.parameters.item3=value3
+dubbo.reference.org.apache.dubbo.samples.api.DemoService.parameters.item4=value4
+```
+
+## 几种编程配置方式
+
+接下来，我们看一下选择不同的开发方式时，对应到 ServiceConfig、ReferenceConfig 等编程接口采集的配置的变化。
+
+#### Spring XML
+
+> 参见[示例](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-basic)
+
+```xml
+ <!-- dubbo-provier.xml -->
+
+ <dubbo:application name="demo-provider"/>
+ <dubbo:config-center address="zookeeper://127.0.0.1:2181"/>
+
+ <dubbo:registry address="zookeeper://127.0.0.1:2181" simplified="true"/>
+ <dubbo:metadata-report address="redis://127.0.0.1:6379"/>
+ <dubbo:protocol name="dubbo" port="20880"/>
+
+ <bean id="demoService" class="org.apache.dubbo.samples.basic.impl.DemoServiceImpl"/>
+ <dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService" ref="demoService"/>
+ ```
+
+#### Spring Annotation
+
+> 参见[示例](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-annotation)
+
+```java
+ // AnnotationService服务实现
+
+ @Service
+ public class AnnotationServiceImpl implements AnnotationService {
+ @Override
+ public String sayHello(String name) {
+ System.out.println("async provider received: " + name);
+ return "annotation: hello, " + name;
+ }
+ }
+ ```
+
+```properties
+ ## dubbo.properties
+
+ dubbo.application.name=annotation-provider
+ dubbo.registry.address=zookeeper://127.0.0.1:2181
+ dubbo.protocol.name=dubbo
+ dubbo.protocol.port=20880
+```
+
+#### Spring Boot
+
+> 参见[示例](https://github.com/apache/dubbo-spring-boot-project/tree/master/dubbo-spring-boot-samples)
+
+```properties
+ ## application.properties
+
+ # Spring boot application
+ spring.application.name=dubbo-externalized-configuration-provider-sample
+
+ # Base packages to scan Dubbo Component: @com.alibaba.dubbo.config.annotation.Service
+ dubbo.scan.base-packages=com.alibaba.boot.dubbo.demo.provider.service
+
+ # Dubbo Application
+ ## The default value of dubbo.application.name is ${spring.application.name}
+ ## dubbo.application.name=${spring.application.name}
+
+ # Dubbo Protocol
+ dubbo.protocol.name=dubbo
+ dubbo.protocol.port=12345
+
+ ## Dubbo Registry
+ dubbo.registry.address=N/A
+
+ ## DemoService version
+ demo.service.version=1.0.0
+```
+
+#### API
+
+> 参考[示例](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-api)
+
+```java
+public static void main(String[] args) throws IOException {
+ ServiceConfig<GreetingsService> service = new ServiceConfig<>();
+ service.setApplication(new ApplicationConfig("first-dubbo-provider"));
+ service.setRegistry(new RegistryConfig("multicast://224.5.6.7:1234"));
+ service.setInterface(GreetingsService.class);
+ service.setRef(new GreetingsServiceImpl());
+ service.export();
+ System.out.println("first-dubbo-provider is running.");
+ System.in.read();
+}
+```
+
diff --git a/content/zh/docs/v3.0/references/configuration/environment-variables.md b/content/zh/docs/v3.0/references/configuration/environment-variables.md
new file mode 100644
index 0000000..dbc0201
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/environment-variables.md
@@ -0,0 +1,35 @@
+---
+type: docs
+title: "自动加载环境变量"
+linkTitle: "自动加载环境变量"
+weight: 2
+description: "在 Dubbo 中自动加载环境变量"
+---
+
+从 2.7.3 版本开始，Dubbo 会自动从约定 key 中读取配置，并将配置以 Key-Value 的形式写入到URL中。
+
+支持的 key 有以下两个：
+
+1. `dubbo.labels`，指定一些列配置到 URL 中的键值对，通常通过 JVM -D 或系统环境变量指定。
+
+ 增加以下配置：
+
+ ```properties
+ # JVM
+ -Ddubbo.labels = "tag1=value1; tag2=value2"
+ # 环境变量
+ DUBBO_LABELS = "tag1=value1; tag2=value2"
+ ```
+
+ 最终生成的 URL 会包含 tag1、tag2 两个 key: `dubbo://xxx?tag1=value1&tag2=value2`
+
+2. `dubbo.env.keys`，指定环境变量 key 值，Dubbo 会尝试从环境变量加载每个 key
+
+ ```properties
+ # JVM
+ -Ddubbo.env.keys = "DUBBO_TAG1, DUBBO_TAG2"
+ # 环境变量
+ DUBBO_ENV_KEYS = "DUBBO_TAG1, DUBBO_TAG2"
+ ```
+
+ 最终生成的 URL 会包含 DUBBO_TAG1、DUBBO_TAG2 两个 key: `dubbo://xxx?DUBBO_TAG1=value1&DUBBO_TAG2=value2`
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/properties.md b/content/zh/docs/v3.0/references/configuration/properties.md
new file mode 100644
index 0000000..1d5da56
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/properties.md
@@ -0,0 +1,44 @@
+---
+type: docs
+title: "属性配置"
+linkTitle: "属性配置"
+weight: 2
+description: "以属性配置的方式来配置你的 Dubbo 应用"
+---
+
+如果你的应用足够简单，例如，不需要多注册中心或多协议，并且需要在spring容器中共享配置，那么，我们可以直接使用 `dubbo.properties` 作为默认配置。
+
+Dubbo 可以自动加载 classpath 根目录下的 dubbo.properties，但是你同样可以使用 JVM 参数来指定路径：`-Ddubbo.properties.file=xxx.properties`。
+
+# 映射规则
+
+可以将 xml 的 tag 名和属性名组合起来，用 ‘.’ 分隔。每行一个属性。
+
+* `dubbo.application.name=foo` 相当于 `<dubbo:application name="foo" />`
+* `dubbo.registry.address=10.20.153.10:9090` 相当于 `<dubbo:registry address="10.20.153.10:9090" /> `
+
+如果在 xml 配置中有超过一个的 tag，那么你可以使用 ‘id’ 进行区分。如果你不指定 id，它将作用于所有 tag。
+
+* `dubbo.protocol.rmi.port=1099` 相当于 `<dubbo:protocol id="rmi" name="rmi" port="1099" /> `
+* `dubbo.registry.china.address=10.20.153.10:9090` 相当于 `<dubbo:registry id="china" address="10.20.153.10:9090" />`
+
+如下，是一个典型的 dubbo.properties 配置样例。
+
+```properties
+dubbo.application.name=foo
+dubbo.application.owner=bar
+dubbo.registry.address=10.20.153.10:9090
+```
+
+## 重写与优先级
+
+
+
+优先级从高到低：
+
+* JVM -D 参数：当你部署或者启动应用时，它可以轻易地重写配置，比如，改变 dubbo 协议端口；
+* XML：XML 中的当前配置会重写 dubbo.properties 中的；
+* Properties：默认配置，仅仅作用于以上两者没有配置时。
+
+1. 如果在 classpath 下有超过一个 dubbo.properties 文件，比如，两个 jar 包都各自包含了 dubbo.properties，dubbo 将随机选择一个加载，并且打印错误日志。
+2. 如果 `id` 没有在 `protocol` 中配置，将使用 `name` 作为默认属性。
diff --git a/content/zh/docs/v3.0/references/configuration/references/_index.md b/content/zh/docs/v3.0/references/configuration/references/_index.md
new file mode 100644
index 0000000..cdf3cb4
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/_index.md
@@ -0,0 +1,7 @@
+---
+type: docs
+title: "参考手册"
+linkTitle: "参考手册"
+weight: 7
+description: "Dubbo 参考手册"
+---
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/references/api.md b/content/zh/docs/v3.0/references/configuration/references/api.md
new file mode 100644
index 0000000..78ee419
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/api.md
@@ -0,0 +1,71 @@
+---
+type: docs
+title: "API 参考手册"
+linkTitle: "API 参考手册"
+weight: 7
+description: "Dubbo API 参考手册"
+---
+
+Dubbo 的常规功能，都保持零侵入，但有些功能不得不用 API 侵入才能实现。
+
+{{% alert title="提示" color="primary" %}}
+Dubbo 中除这里声明以外的接口或类，都是内部接口或扩展接口，普通用户请不要直接依赖，否则升级版本可能出现不兼容。
+{{% /alert %}}
+
+API 汇总如下：
+
+## 配置 API
+
+```
+org.apache.dubbo.config.ServiceConfig
+org.apache.dubbo.config.ReferenceConfig
+org.apache.dubbo.config.ProtocolConfig
+org.apache.dubbo.config.RegistryConfig
+org.apache.dubbo.config.MonitorConfig
+org.apache.dubbo.config.ApplicationConfig
+org.apache.dubbo.config.ModuleConfig
+org.apache.dubbo.config.ProviderConfig
+org.apache.dubbo.config.ConsumerConfig
+org.apache.dubbo.config.MethodConfig
+org.apache.dubbo.config.ArgumentConfig
+```
+
+详细参见：[API配置](../../configuration/api)
+
+## 注解 API
+
+```
+org.apache.dubbo.config.annotation.Service
+org.apache.dubbo.config.annotation.Reference
+```
+
+详细参见：[注解配置](../../configuration/annotation)
+
+## 模型 API
+
+```
+org.apache.dubbo.common.URL
+org.apache.dubbo.rpc.RpcException
+```
+
+## 上下文 API
+
+```
+org.apache.dubbo.rpc.RpcContext
+```
+
+详细参见：[上下文信息](../../examples/context) & [隐式传参](../../examples/attachment) & [异步调用](../../examples/async-call)
+
+## 服务 API
+
+```
+org.apache.dubbo.rpc.service.GenericService
+org.apache.dubbo.rpc.service.GenericException
+```
+
+详细参见：[泛化引用](../../examples/generic-reference) & [泛化实现](../../examples/generic-service)
+
+```
+org.apache.dubbo.rpc.service.EchoService
+```
+详细参见：[回声测试](../../examples/echo-service)
diff --git a/content/zh/docs/v3.0/references/configuration/references/maven.md b/content/zh/docs/v3.0/references/configuration/references/maven.md
new file mode 100644
index 0000000..493e502
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/maven.md
@@ -0,0 +1,26 @@
+---
+type: docs
+title: "Maven 插件参考手册"
+linkTitle: "Maven 插件参考手册"
+weight: 12
+description: "Dubbo 的 Maven 插件"
+---
+
+
+## 启动一个简易注册中心
+
+以指定的 9099 端口启动一个简易注册中心 [^1]：
+
+```sh
+mvn dubbo:registry -Dport=9099
+```
+
+## 生成 demo 服务提供者应用
+
+生成指定接口和版本的服务提供者应用：
+
+```sh
+mvn dubbo:create -Dapplication=xxx -Dpackage=com.alibaba.xxx -Dservice=XxxService,YyyService -Dversion=1.0.0
+```
+
+[^1]: 如果端口不指定，默认端口为 9090
diff --git a/content/zh/docs/v3.0/references/configuration/references/metadata.md b/content/zh/docs/v3.0/references/configuration/references/metadata.md
new file mode 100644
index 0000000..76178d3
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/metadata.md
@@ -0,0 +1,391 @@
+---
+type: docs
+title: "元数据参考手册"
+linkTitle: "元数据参考手册"
+weight: 5
+description: "Dubbo 服务元数据参考手册"
+---
+
+## 背景
+
+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，服务测试。
+
+
+
+## 目标
+
+需要将注册中心原来的数据信息和元数据信息保存到独立的key-value的存储中，这个key-value可以是DB，redis或者其他持久化存储。核心代码中支持了zookeeper，redis(推荐)的默认支持。
+
+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.address)也不进行配置，整个元数据的写入不会生效，但是不影响程序运行。
+
+
+接下来看几个sample的配置。无论哪种配置方式，都需要引入maven依赖：
+
+```xml
+<dependency>
+ <groupId>org.apache.dubbo</groupId>
+ <artifactId>dubbo-metadata-report-zookeeper</artifactId>
+</dependency>
+```
+如果需要使用redis，可以引入对应的redis的依赖：
+
+```xml
+<dependency>
+ <groupId>org.apache.dubbo</groupId>
+ <artifactId>dubbo-metadata-report-redis</artifactId>
+</dependency>
+```
+
+> **完整的sample，查看[sample-2.7](https://github.com/dubbo/dubbo-samples/tree/master)**
+
+### 方式一：在配置中心配置
+
+参考sample：dubbo-samples-metadata-report/dubbo-samples-metadata-report-configcenter 工程。
+
+##### 配置中心配置
+
+配置中心的配置，可以参考configcenter的文档。配置的内容如下：
+
+```properties
+dubbo.registry.address=zookeeper://127.0.0.1:2181
+### 注意驼峰式风格
+dubbo.metadata-report.address=zookeeper://127.0.0.1:2181 ###元数据存储的地址
+```
+
+在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
+...
+```
+
+完成上述两步之后，注册中心地址、元数据地址将从配置中心进行获取。现在可以依次运行Provider类和Consumer类，会在console中得到对应的输出或者直接通过zookeeper的cli查看。
+
+##### Provider配置
+
+provider端存储的元数据内容如下：
+
+```json
+{
+ "parameters": {
+ "side": "provider",
+ "methods": "sayHello",
+ "dubbo": "2.0.2",
+ "threads": "100",
+ "interface": "org.apache.dubbo.samples.metadatareport.configcenter.api.AnnotationService",
+ "threadpool": "fixed",
+ "version": "1.1.1",
+ "generic": "false",
+ "revision": "1.1.1",
+ "valid": "true",
+ "application": "metadatareport-configcenter-provider",
+ "default.timeout": "5000",
+ "group": "d-test",
+ "anyhost": "true"
+ },
+ "canonicalName": "org.apache.dubbo.samples.metadatareport.configcenter.api.AnnotationService",
+ "codeSource": "file:/Users/cvictory/workspace/work-mw/dubbo-samples/dubbo-samples-metadata-report/dubbo-samples-metadata-report-configcenter/target/classes/",
+ "methods": [{
+ "name": "sayHello",
+ "parameterTypes": ["java.lang.String"],
+ "returnType": "java.lang.String"
+ }],
+ "types": [{
+ "type": "java.lang.String",
+ "properties": {
+ "value": {
+ "type": "char[]"
+ },
+ "hash": {
+ "type": "int"
+ }
+ }
+ }, {
+ "type": "int"
+ }, {
+ "type": "char"
+ }]
+}
+
+```
+
+provider存储的内容包括了provider服务往注册中心填写的全部参数，以及服务的方法信息（方法名，入参出参的格式）。
+
+##### Consumer配置：
+
+```json
+{
+ "valid": "true",
+ "side": "consumer",
+ "application": "metadatareport-configcenter-consumer",
+ "methods": "sayHello",
+ "default.timeout": "6666",
+ "dubbo": "2.0.2",
+ "interface": "org.apache.dubbo.samples.metadatareport.configcenter.api.AnnotationService",
+ "version": "1.1.1",
+ "revision": "1.1.1",
+ "group": "d-test"
+}
+```
+
+consumer端存储了consumer往注册中心填写的全部参数。
+
+
+
+上面的例子，主要是将元数据地址放在配置中心，在元数据区存储下来的provider端服务信息和consumer端服务信息的展示。
+接下来的两个例子，主要讲解在工程中配置：xml方式，annotation方式。
+
+### 方式二：配置在项目中-properties方式引入配置
+
+参考sample：dubbo-samples-metadata-report/dubbo-samples-metadata-report-local-xml工程。
+
+##### dubbo.properties
+
+```properties
+dubbo.metadata-report.address=zookeeper://127.0.0.1:2181
+```
+
+配置完成这个之后，其余的不用特别关注。也可以直接查看对应的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。
+
+至此，一个自定义的元数据存储就可以运行了。
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/_index.md b/content/zh/docs/v3.0/references/configuration/references/protocol/_index.md
new file mode 100644
index 0000000..0bd1ab7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/_index.md
@@ -0,0 +1,10 @@
+---
+type: docs
+title: "协议参考手册"
+linkTitle: "协议参考手册"
+weight: 2
+description: "Dubbo 协议参考手册"
+---
+
+推荐使用 Dubbo 协议。各协议的性能情况，请参见：[性能测试报告](../../perf-test)
+
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/dubbo.md b/content/zh/docs/v3.0/references/configuration/references/protocol/dubbo.md
new file mode 100644
index 0000000..04289c8
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/dubbo.md
@@ -0,0 +1,129 @@
+---
+type: docs
+title: "dubbo 协议"
+linkTitle: "dubbo://"
+weight: 1
+description: "dubbo:// 协议参考手册"
+---
+
+Dubbo 缺省协议采用单一长连接和 NIO 异步通讯，适合于小数据量大并发的服务调用，以及服务消费者机器数远大于服务提供者机器数的情况。
+
+反之，Dubbo 缺省协议不适合传送大数据量的服务，比如传文件，传视频等，除非请求量很低。
+
+
+
+* Transporter: mina, netty, grizzy
+* Serialization: dubbo, hessian2, java, json
+* Dispatcher: all, direct, message, execution, connection
+* ThreadPool: fixed, cached
+
+## 特性
+
+缺省协议，使用基于 netty `3.2.5.Final` 和 hessian2 `3.2.1-fixed-2(Alibaba embed version)` 的 tbremoting 交互。
+
+* 连接个数：单连接
+* 连接方式：长连接
+* 传输协议：TCP
+* 传输方式：NIO 异步传输
+* 序列化：Hessian 二进制序列化
+* 适用范围：传入传出参数数据包较小（建议小于100K），消费者比提供者个数多，单一消费者无法压满提供者，尽量不要用 dubbo 协议传输大文件或超大字符串。
+* 适用场景：常规远程服务方法调用
+
+## 约束
+
+* 参数及返回值需实现 `Serializable` 接口
+* 参数及返回值不能自定义实现 `List`, `Map`, `Number`, `Date`, `Calendar` 等接口，只能用 JDK 自带的实现，因为 hessian 会做特殊处理，自定义实现类中的属性值都会丢失。
+* Hessian 序列化，只传成员属性值和值的类型，不传方法或静态变量，兼容情况 [^1][^2]：
+
+| 数据通讯 | 情况 | 结果 |
+| ------------- | ------------- | ------------- |
+| A->B | 类A多一种 属性（或者说类B少一种 属性）| 不抛异常，A多的那 个属性的值，B没有， 其他正常 |
+| A->B | 枚举A多一种 枚举（或者说B少一种 枚举），A使用多 出来的枚举进行传输 | 抛异常 |
+| A->B | 枚举A多一种 枚举（或者说B少一种 枚举），A不使用 多出来的枚举进行传输 | 不抛异常，B正常接 收数据 |
+| A->B | A和B的属性 名相同，但类型不相同 | 抛异常 |
+| A->B | serialId 不相同 | 正常传输 |
+
+接口增加方法，对客户端无影响，如果该方法不是客户端需要的，客户端不需要重新部署。输入参数和结果集中增加属性，对客户端无影响，如果客户端并不需要新属性，不用重新部署。
+
+输入参数和结果集属性名变化，对客户端序列化无影响，但是如果客户端不重新部署，不管输入还是输出，属性名变化的属性值是获取不到的。
+
+总结：服务器端和客户端对领域对象并不需要完全一致，而是按照最大匹配原则。
+
+## 配置
+
+配置协议：
+
+```xml
+<dubbo:protocol name="dubbo" port="20880" />
+```
+
+设置默认协议：
+
+```xml
+<dubbo:provider protocol="dubbo" />
+```
+
+设置服务协议：
+
+```xml
+<dubbo:service protocol="dubbo" />
+```
+
+多端口：
+
+```xml
+<dubbo:protocol id="dubbo1" name="dubbo" port="20880" />
+<dubbo:protocol id="dubbo2" name="dubbo" port="20881" />
+```
+
+配置协议选项：
+
+```xml
+<dubbo:protocol name=“dubbo” port=“9090” server=“netty” client=“netty” codec=“dubbo” serialization=“hessian2” charset=“UTF-8” threadpool=“fixed” threads=“100” queues=“0” iothreads=“9” buffer=“8192” accepts=“1000” payload=“8388608” />
+```
+
+多连接配置：
+
+Dubbo 协议缺省每服务每提供者每消费者使用单一长连接，如果数据量较大，可以使用多个连接。
+
+```xml
+<dubbo:service connections="1"/>
+<dubbo:reference connections="1"/>
+```
+
+* `<dubbo:service connections="0">` 或 `<dubbo:reference connections="0">` 表示该服务使用 JVM 共享长连接。**缺省**
+* `<dubbo:service connections="1">` 或 `<dubbo:reference connections="1">` 表示该服务使用独立长连接。
+* `<dubbo:service connections="2">` 或`<dubbo:reference connections="2">` 表示该服务使用独立两条长连接。
+
+为防止被大量连接撑挂，可在服务提供方限制大接收连接数，以实现服务提供方自我保护。
+
+```xml
+<dubbo:protocol name="dubbo" accepts="1000" />
+```
+
+`dubbo.properties` 配置：
+
+```sh
+dubbo.service.protocol=dubbo
+```
+
+
+## 常见问题
+
+#### 为什么要消费者比提供者个数多?
+
+因 dubbo 协议采用单一长连接，假设网络为千兆网卡 [^3]，根据测试经验数据每条连接最多只能压满 7MByte(不同的环境可能不一样，供参考)，理论上 1 个服务提供者需要 20 个服务消费者才能压满网卡。
+
+#### 为什么不能传大包?
+
+因 dubbo 协议采用单一长连接，如果每次请求的数据包大小为 500KByte，假设网络为千兆网卡 [^3]，每条连接最大 7MByte(不同的环境可能不一样，供参考)，单个服务提供者的 TPS(每秒处理事务数)最大为：128MByte / 500KByte = 262。单个消费者调用单个服务提供者的 TPS(每秒处理事务数)最大为：7MByte / 500KByte = 14。如果能接受，可以考虑使用，否则网络将成为瓶颈。
+
+#### 为什么采用异步单一长连接?
+
+因为服务的现状大都是服务提供者少，通常只有几台机器，而服务的消费者多，可能整个网站都在访问该服务，比如 Morgan 的提供者只有 6 台提供者，却有上百台消费者，每天有 1.5 亿次调用，如果采用常规的 hessian 服务，服务提供者很容易就被压跨，通过单一连接，保证单一消费者不会压死提供者，长连接，减少连接握手验证等，并使用异步 IO，复用线程池，防止 C10K 问题。
+
+[^1]: 由吴亚军提供
+[^2]: 总结：会抛异常的情况：枚举值一边多一种，一边少一种，正好使用了差别的那种，或者属性名相同，类型不同
+[^3]: 1024Mbit=128MByte
+
+
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/gRPC.md b/content/zh/docs/v3.0/references/configuration/references/protocol/gRPC.md
new file mode 100644
index 0000000..ee13d47
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/gRPC.md
@@ -0,0 +1,25 @@
+---
+type: docs
+title: "gRPC 协议"
+linkTitle: "grpc://"
+weight: 5
+description: "grpc:// 协议参考手册"
+---
+
+Dubbo 自 2.7.5 版本开始支持 gRPC 协议，对于计划使用 HTTP/2 通信，或者想利用 gRPC 带来的 Stream、反压、Reactive 编程等能力的开发者来说，
+都可以考虑启用 gRPC 协议。
+
+## 支持 gRPC 的好处
+* 为期望使用 gRPC 协议的用户带来服务治理能力，方便接入 Dubbo 体系
+* 用户可以使用 Dubbo 风格的，基于接口的编程风格来定义和使用远程服务
+
+## 如何在 Dubbo 中使用 gRPC
+大概需要以下步骤：
+1. 使用 IDL 定义服务
+2. 配置 compiler 插件，本地预编译
+3. 配置暴露/引用 Dubbo 服务
+
+具体可参见以下[示例](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-grpc)
+
+除了原生 StreamObserver 接口类型之外，Dubbo 还支持 [RxJava](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-rxjava)、[Reactor](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-grpc/dubbo-samples-reactor) 编程风格的 API
+
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/hessian.md b/content/zh/docs/v3.0/references/configuration/references/protocol/hessian.md
new file mode 100644
index 0000000..c3e8ab9
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/hessian.md
@@ -0,0 +1,74 @@
+---
+type: docs
+title: "hessian 协议"
+linkTitle: "hessian://"
+weight: 4
+description: "hessian:// 协议参考手册"
+---
+
+Hessian [^1] 协议用于集成 Hessian 的服务，Hessian 底层采用 Http 通讯，采用 Servlet 暴露服务，Dubbo 缺省内嵌 Jetty 作为服务器实现。
+
+Dubbo 的 Hessian 协议可以和原生 Hessian 服务互操作，即：
+
+* 提供者用 Dubbo 的 Hessian 协议暴露服务，消费者直接用标准 Hessian 接口调用
+* 或者提供方用标准 Hessian 暴露服务，消费方用 Dubbo 的 Hessian 协议调用。
+
+## 特性
+
+* 连接个数：多连接
+* 连接方式：短连接
+* 传输协议：HTTP
+* 传输方式：同步传输
+* 序列化：Hessian二进制序列化
+* 适用范围：传入传出参数数据包较大，提供者比消费者个数多，提供者压力较大，可传文件。
+* 适用场景：页面传输，文件传输，或与原生hessian服务互操作
+
+## 依赖
+
+```xml
+<dependency>
+ <groupId>com.caucho</groupId>
+ <artifactId>hessian</artifactId>
+ <version>4.0.7</version>
+</dependency>
+```
+
+## 约束
+
+* 参数及返回值需实现 `Serializable` 接口
+* 参数及返回值不能自定义实现 `List`, `Map`, `Number`, `Date`, `Calendar` 等接口，只能用 JDK 自带的实现，因为 hessian 会做特殊处理，自定义实现类中的属性值都会丢失。
+
+## 配置
+
+定义 hessian 协议：
+
+```xml
+<dubbo:protocol name="hessian" port="8080" server="jetty" />
+```
+
+设置默认协议：
+
+```xml
+<dubbo:provider protocol="hessian" />
+```
+
+设置 service 协议：
+
+```xml
+<dubbo:service protocol="hessian" />
+```
+
+多端口：
+
+```xml
+<dubbo:protocol id="hessian1" name="hessian" port="8080" />
+<dubbo:protocol id="hessian2" name="hessian" port="8081" />
+```
+
+直连：
+
+```xml
+<dubbo:reference id="helloService" interface="HelloWorld" url="hessian://10.20.153.10:8080/helloWorld" />
+```
+
+[^1]: [Hessian](http://hessian.caucho.com) 是 Caucho 开源的一个 RPC 框架，其通讯效率高于 WebService 和 Java 自带的序列化。
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/http.md b/content/zh/docs/v3.0/references/configuration/references/protocol/http.md
new file mode 100644
index 0000000..b6916a7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/http.md
@@ -0,0 +1,65 @@
+---
+type: docs
+title: "http 协议"
+linkTitle: "http://"
+weight: 3
+description: "http:// 协议参考手册"
+---
+
+基于 HTTP 表单的远程调用协议，采用 Spring 的 HttpInvoker 实现
+
+{{% alert title="提示" color="primary" %}}
+`2.3.0` 以上版本支持
+{{% /alert %}}
+
+## 特性
+
+* 连接个数：多连接
+* 连接方式：短连接
+* 传输协议：HTTP
+* 传输方式：同步传输
+* 序列化：表单序列化
+* 适用范围：传入传出参数数据包大小混合，提供者比消费者个数多，可用浏览器查看，可用表单或URL传入参数，暂不支持传文件。
+* 适用场景：需同时给应用程序和浏览器 JS 使用的服务。
+
+## 约束
+* 参数及返回值需符合 Bean 规范
+
+## 配置
+
+配置协议：
+
+```xml
+<dubbo:protocol name="http" port="8080" />
+```
+
+配置 Jetty Server (默认)：
+
+```xml
+<dubbo:protocol ... server="jetty" />
+```
+
+配置 Servlet Bridge Server (推荐使用)：
+
+```xml
+<dubbo:protocol ... server="servlet" />
+```
+
+配置 DispatcherServlet：
+
+```xml
+<servlet>
+ <servlet-name>dubbo</servlet-name>
+ <servlet-class>org.apache.dubbo.remoting.http.servlet.DispatcherServlet</servlet-class>
+ <load-on-startup>1</load-on-startup>
+</servlet>
+<servlet-mapping>
+ <servlet-name>dubbo</servlet-name>
+ <url-pattern>/*</url-pattern>
+</servlet-mapping>
+```
+
+注意，如果使用 servlet 派发请求：
+
+* 协议的端口 `<dubbo:protocol port="8080" />` 必须与 servlet 容器的端口相同，
+* 协议的上下文路径 `<dubbo:protocol contextpath="foo" />` 必须与 servlet 应用的上下文路径相同。
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/memcached.md b/content/zh/docs/v3.0/references/configuration/references/protocol/memcached.md
new file mode 100644
index 0000000..68faa75
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/memcached.md
@@ -0,0 +1,53 @@
+---
+type: docs
+title: "memcached 协议"
+linkTitle: "memcached://"
+weight: 5
+description: "memcached:// 协议参考手册"
+---
+
+基于 memcached [^1] 实现的 RPC 协议。
+
+{{% alert title="提示" color="primary" %}}
+`2.3.0` 以上版本支持
+{{% /alert %}}
+
+## 注册 memcached 服务的地址
+
+```java
+RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
+Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
+registry.register(URL.valueOf("memcached://10.20.153.11/com.foo.BarService?category=providers&dynamic=false&application=foo&group=member&loadbalance=consistenthash"));
+```
+
+## 在客户端引用
+
+在客户端使用 [^2]：
+
+```xml
+<dubbo:reference id="cache" interface="java.util.Map" group="member" />
+```
+
+或者，点对点直连：
+
+```xml
+<dubbo:reference id="cache" interface="java.util.Map" url="memcached://10.20.153.10:11211" />
+```
+
+也可以使用自定义接口：
+
+```xml
+<dubbo:reference id="cache" interface="com.foo.CacheService" url="memcached://10.20.153.10:11211" />
+```
+
+方法名建议和 memcached 的标准方法名相同，即：get(key), set(key, value), delete(key)。
+
+如果方法名和 memcached 的标准方法名不相同，则需要配置映射关系 [^3]：
+
+```xml
+<dubbo:reference id="cache" interface="com.foo.CacheService" url="memcached://10.20.153.10:11211" p:set="putFoo" p:get="getFoo" p:delete="removeFoo" />
+```
+
+[^1]: [Memcached](http://memcached.org/) 是一个高效的 KV 缓存服务器
+[^2]: 不需要感知 Memcached 的地址
+[^3]: 其中 "p:xxx" 为 spring 的标准 p 标签
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/redis.md b/content/zh/docs/v3.0/references/configuration/references/protocol/redis.md
new file mode 100644
index 0000000..916affb
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/redis.md
@@ -0,0 +1,54 @@
+---
+type: docs
+title: "redis 协议"
+linkTitle: "redis://"
+weight: 4
+description: "redis:// 协议参考手册"
+---
+
+
+基于 Redis [^1] 实现的 RPC 协议。
+
+{{% alert title="提示" color="primary" %}}
+`2.3.0` 以上版本支持
+{{% /alert %}}
+
+## 注册 redis 服务的地址
+
+```java
+RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
+Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
+registry.register(URL.valueOf("redis://10.20.153.11/com.foo.BarService?category=providers&dynamic=false&application=foo&group=member&loadbalance=consistenthash"));
+```
+
+## 在客户端引用
+
+在客户端使用 [^2]：
+
+```xml
+<dubbo:reference id="store" interface="java.util.Map" group="member" />
+```
+
+或者，点对点直连：
+
+```xml
+<dubbo:reference id="store" interface="java.util.Map" url="redis://10.20.153.10:6379" />
+```
+
+也可以使用自定义接口：
+
+```xml
+<dubbo:reference id="store" interface="com.foo.StoreService" url="redis://10.20.153.10:6379" />
+```
+
+方法名建议和 redis 的标准方法名相同，即：get(key), set(key, value), delete(key)。
+
+如果方法名和 redis 的标准方法名不相同，则需要配置映射关系 [^3]：
+
+```xml
+<dubbo:reference id="cache" interface="com.foo.CacheService" url="redis://10.20.153.10:6379" p:set="putFoo" p:get="getFoo" p:delete="removeFoo" />
+```
+
+[^1]: [Redis](http://redis.io) 是一个高效的 KV 存储服务器
+[^2]: 不需要感知 Redis 的地址
+[^3]: 其中 "p:xxx" 为 spring 的标准 p 标签
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/rest.md b/content/zh/docs/v3.0/references/configuration/references/protocol/rest.md
new file mode 100644
index 0000000..cf88b31
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/rest.md
@@ -0,0 +1,748 @@
+---
+type: docs
+title: "rest 协议"
+linkTitle: "rest://"
+weight: 2
+description: "rest:// 协议参考手册"
+---
+
+
+基于标准的Java REST API——JAX-RS 2.0（Java API for RESTful Web Services的简写）实现的REST调用支持
+
+
+## 快速入门
+
+在dubbo中开发一个REST风格的服务会比较简单，下面以一个注册用户的简单服务为例说明。
+
+这个服务要实现的功能是提供如下URL（注：这个URL不是完全符合REST的风格，但是更简单实用）：
+
+```
+http://localhost:8080/users/register
+```
+
+而任何客户端都可以将包含用户信息的JSON字符串POST到以上URL来完成用户注册。
+
+首先，开发服务的接口：
+
+```java
+public interface UserService {
+ void registerUser(User user);
+}
+```
+
+然后，开发服务的实现：
+
+```java
+@Path("/users")
+public class UserServiceImpl implements UserService {
+
+ @POST
+ @Path("/register")
+ @Consumes({MediaType.APPLICATION_JSON})
+ public void registerUser(User user) {
+ // save the user...
+ }
+}
+```
+上面的实现非常简单，但是由于该 REST 服务是要发布到指定 URL 上，供任意语言的客户端甚至浏览器来访问，所以这里额外添加了几个 JAX-RS 的标准 annotation 来做相关的配置。
+
+@Path("/users")：指定访问UserService的URL相对路径是/users，即http://localhost:8080/users
+
+@Path("/register")：指定访问registerUser()方法的URL相对路径是/register，再结合上一个@Path为UserService指定的路径，则调用UserService.register()的完整路径为http://localhost:8080/users/register
+
+@POST：指定访问registerUser()用HTTP POST方法
+
+@Consumes({MediaType.APPLICATION_JSON})：指定registerUser()接收JSON格式的数据。REST框架会自动将JSON数据反序列化为User对象
+
+最后，在spring配置文件中添加此服务，即完成所有服务开发工作：
+
+ ```xml
+<!-- 用rest协议在8080端口暴露服务 -->
+<dubbo:protocol name="rest" port="8080"/>
+
+<!-- 声明需要暴露的服务接口 -->
+<dubbo:service interface="xxx.UserService" ref="userService"/>
+
+<!-- 和本地bean一样实现服务 -->
+<bean id="userService" class="xxx.UserServiceImpl" />
+```
+
+## REST服务提供端详解
+
+下面我们扩充“快速入门”中的UserService，进一步展示在dubbo中REST服务提供端的开发要点。
+
+### HTTP POST/GET的实现
+
+REST服务中虽然建议使用HTTP协议中四种标准方法POST、DELETE、PUT、GET来分别实现常见的“增删改查”，但实际中，我们一般情况直接用POST来实现“增改”，GET来实现“删查”即可（DELETE和PUT甚至会被一些防火墙阻挡）。
+
+前面已经简单演示了POST的实现，在此，我们为UserService添加一个获取注册用户资料的功能，来演示GET的实现。
+
+这个功能就是要实现客户端通过访问如下不同URL来获取不同ID的用户资料：
+
+```
+http://localhost:8080/users/1001
+http://localhost:8080/users/1002
+http://localhost:8080/users/1003
+```
+
+当然，也可以通过其他形式的URL来访问不同ID的用户资料，例如：
+
+```
+http://localhost:8080/users/load?id=1001
+```
+
+JAX-RS本身可以支持所有这些形式。但是上面那种在URL路径中包含查询参数的形式（http://localhost:8080/users/1001） 更符合REST的一般习惯，所以更推荐大家来使用。下面我们就为UserService添加一个getUser()方法来实现这种形式的URL访问：
+
+```java
+@GET
+@Path("/{id : \\d+}")
+@Produces({MediaType.APPLICATION_JSON})
+public User getUser(@PathParam("id") Long id) {
+ // ...
+}
+```
+
+@GET：指定用HTTP GET方法访问
+
+@Path("/{id : \\d+}")：根据上面的功能需求，访问getUser()的URL应当是“http://localhost:8080/users/ + 任意数字"，并且这个数字要被做为参数传入getUser()方法。 这里的annotation配置中，@Path中间的{id: xxx}指定URL相对路径中包含了名为id参数，而它的值也将被自动传递给下面用@PathParam("id")修饰的方法参数id。{id:后面紧跟的\\d+是一个正则表达式，指定了id参数必须是数字。
+
+@Produces({MediaType.APPLICATION_JSON})：指定getUser()输出JSON格式的数据。框架会自动将User对象序列化为JSON数据。
+
+### Annotation放在接口类还是实现类
+
+在Dubbo中开发REST服务主要都是通过JAX-RS的annotation来完成配置的，在上面的示例中，我们都是将annotation放在服务的实现类中。但其实，我们完全也可以将annotation放到服务的接口上，这两种方式是完全等价的，例如：
+
+```java
+@Path("/users")
+public interface UserService {
+
+ @GET
+ @Path("/{id : \\d+}")
+ @Produces({MediaType.APPLICATION_JSON})
+ User getUser(@PathParam("id") Long id);
+}
+```
+
+在一般应用中，我们建议将annotation放到服务实现类，这样annotation和java实现代码位置更接近，更便于开发和维护。另外更重要的是，我们一般倾向于避免对接口的污染，保持接口的纯净性和广泛适用性。
+
+但是，如后文所述，如果我们要用dubbo直接开发的消费端来访问此服务，则annotation必须放到接口上。
+
+如果接口和实现类都同时添加了annotation，则实现类的annotation配置会生效，接口上的annotation被直接忽略。
+
+### JSON、XML等多数据格式的支持
+
+在dubbo中开发的REST服务可以同时支持传输多种格式的数据，以给客户端提供最大的灵活性。其中我们目前对最常用的JSON和XML格式特别添加了额外的功能。
+
+比如，我们要让上例中的getUser()方法支持分别返回JSON和XML格式的数据，只需要在annotation中同时包含两种格式即可：
+
+```java
+@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
+User getUser(@PathParam("id") Long id);
+```
+
+或者也可以直接用字符串（还支持通配符）表示MediaType：
+
+```java
+@Produces({"application/json", "text/xml"})
+User getUser(@PathParam("id") Long id);
+```
+
+如果所有方法都支持同样类型的输入输出数据格式，则我们无需在每个方法上做配置，只需要在服务类上添加annotation即可：
+
+```java
+@Path("/users")
+@Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
+@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
+public class UserServiceImpl implements UserService {
+ // ...
+}
+
+```
+
+在一个REST服务同时对多种数据格式支持的情况下，根据JAX-RS标准，一般是通过HTTP中的MIME header（content-type和accept）来指定当前想用的是哪种格式的数据。
+
+但是在dubbo中，我们还自动支持目前业界普遍使用的方式，即用一个URL后缀（.json和.xml）来指定想用的数据格式。例如，在添加上述annotation后，直接访问http://localhost:8888/users/1001.json则表示用json格式，直接访问http://localhost:8888/users/1002.xml则表示用xml格式，比用HTTP Header更简单直观。Twitter、微博等的REST API都是采用这种方式。
+
+如果你既不加HTTP header，也不加后缀，则dubbo的REST会优先启用在以上annotation定义中排位最靠前的那种数据格式。
+
+> 注意：这里要支持XML格式数据，在annotation中既可以用MediaType.TEXT_XML，也可以用MediaType.APPLICATION_XML，但是TEXT_XML是更常用的，并且如果要利用上述的URL后缀方式来指定数据格式，只能配置为TEXT_XML才能生效。
+
+### 中文字符支持
+
+为了在dubbo REST中正常输出中文字符，和通常的Java web应用一样，我们需要将HTTP响应的contentType设置为UTF-8编码。
+
+基于JAX-RS的标准用法，我们只需要做如下annotation配置即可：
+
+```java
+@Produces({"application/json; charset=UTF-8", "text/xml; charset=UTF-8"})
+User getUser(@PathParam("id") Long id);
+```
+
+为了方便用户，我们在dubbo REST中直接添加了一个支持类，来定义以上的常量，可以直接使用，减少出错的可能性。
+
+```java
+@Produces({ContentType.APPLICATION_JSON_UTF_8, ContentType.TEXT_XML_UTF_8})
+User getUser(@PathParam("id") Long id);
+```
+
+### XML数据格式的额外要求
+
+由于JAX-RS的实现一般都用标准的JAXB（Java API for XML Binding）来序列化和反序列化XML格式数据，所以我们需要为每一个要用XML传输的对象添加一个类级别的JAXB annotation，否则序列化将报错。例如为getUser()中返回的User添加如下：
+
+```java
+@XmlRootElement
+public class User implements Serializable {
+ // ...
+}
+```
+
+此外，如果service方法中的返回值是Java的 primitive类型（如int，long，float，double等），最好为它们添加一层wrapper对象，因为JAXB不能直接序列化primitive类型。
+
+例如，我们想让前述的registerUser()方法返回服务器端为用户生成的ID号：
+
+```java
+long registerUser(User user);
+```
+
+由于primitive类型不被JAXB序列化支持，所以添加一个wrapper对象：
+
+```java
+@XmlRootElement
+public class RegistrationResult implements Serializable {
+
+ private Long id;
+
+ public RegistrationResult() {
+ }
+
+ public RegistrationResult(Long id) {
+ this.id = id;
+ }
+
+ public Long getId() {
+ return id;
+ }
+
+ public void setId(Long id) {
+ this.id = id;
+ }
+}
+```
+
+并修改service方法：
+
+```java
+RegistrationResult registerUser(User user);
+```
+
+这样不但能够解决XML序列化的问题，而且使得返回的数据都符合XML和JSON的规范。例如，在JSON中，返回的将是如下形式：
+
+```javascript
+{"id": 1001}
+```
+
+如果不加wrapper，JSON返回值将直接是
+
+```
+1001
+```
+
+而在XML中，加wrapper后返回值将是：
+
+```xml
+<registrationResult>
+ <id>1002</id>
+</registrationResult>
+```
+
+这种wrapper对象其实利用所谓Data Transfer Object（DTO）模式，采用DTO还能对传输数据做更多有用的定制。
+
+### 定制序列化
+
+如上所述，REST的底层实现会在service的对象和JSON/XML数据格式之间自动做序列化/反序列化。但有些场景下，如果觉得这种自动转换不满足要求，可以对其做定制。
+
+Dubbo中的REST实现是用JAXB做XML序列化，用Jackson做JSON序列化，所以在对象上添加JAXB或Jackson的annotation即可以定制映射。
+
+例如，定制对象属性映射到XML元素的名字：
+
+```java
+@XmlRootElement
+@XmlAccessorType(XmlAccessType.FIELD)
+public class User implements Serializable {
+
+ @XmlElement(name="username")
+ private String name;
+}
+```
+
+定制对象属性映射到JSON字段的名字：
+
+```java
+public class User implements Serializable {
+
+ @JsonProperty("username")
+ private String name;
+}
+```
+
+更多资料请参考JAXB和Jackson的官方文档，或自行google。
+
+### 配置REST Server的实现
+
+目前在dubbo中，我们支持5种嵌入式rest server的实现，并同时支持采用外部应用服务器来做rest server的实现。rest server可以通过如下配置实现：
+
+```xml
+<dubbo:protocol name="rest" server="jetty"/>
+```
+
+以上配置选用了嵌入式的jetty来做rest server，同时，如果不配置server属性，rest协议默认也是选用jetty。jetty是非常成熟的java servlet容器，并和dubbo已经有较好的集成（目前5种嵌入式server中只有jetty和后面所述的tomcat、tjws，与dubbo监控系统等完成了无缝的集成），所以，如果你的dubbo系统是单独启动的进程，你可以直接默认采用jetty即可。
+
+
+```xml
+<dubbo:protocol name="rest" server="tomcat"/>
+```
+
+以上配置选用了嵌入式的tomcat来做rest server。在嵌入式tomcat上，REST的性能比jetty上要好得多（参见后面的基准测试），建议在需要高性能的场景下采用tomcat。
+
+```xml
+<dubbo:protocol name="rest" server="netty"/>
+```
+
+以上配置选用嵌入式的netty来做rest server。（TODO more contents to add）
+
+```xml
+<dubbo:protocol name="rest" server="tjws"/> (tjws is now deprecated)
+<dubbo:protocol name="rest" server="sunhttp"/>
+```
+
+以上配置选用嵌入式的tjws或Sun HTTP server来做rest server。这两个server实现非常轻量级，非常方便在集成测试中快速启动使用，当然也可以在负荷不高的生产环境中使用。 注：tjws目前已经被deprecated掉了，因为它不能很好的和servlet 3.1 API工作。
+
+如果你的dubbo系统不是单独启动的进程，而是部署到了Java应用服务器中，则建议你采用以下配置：
+
+```xml
+<dubbo:protocol name="rest" server="servlet"/>
+```
+
+通过将server设置为servlet，dubbo将采用外部应用服务器的servlet容器来做rest server。同时，还要在dubbo系统的web.xml中添加如下配置：
+
+```xml
+<web-app>
+ <context-param>
+ <param-name>contextConfigLocation</param-name>
+ <param-value>/WEB-INF/classes/META-INF/spring/dubbo-demo-provider.xml</param-value>
+ </context-param>
+
+ <listener>
+ <listener-class>org.apache.dubbo.remoting.http.servlet.BootstrapListener</listener-class>
+ </listener>
+
+ <listener>
+ <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
+ </listener>
+
+ <servlet>
+ <servlet-name>dispatcher</servlet-name>
+ <servlet-class>org.apache.dubbo.remoting.http.servlet.DispatcherServlet</servlet-class>
+ <load-on-startup>1</load-on-startup>
+ </servlet>
+
+ <servlet-mapping>
+ <servlet-name>dispatcher</servlet-name>
+ <url-pattern>/*</url-pattern>
+ </servlet-mapping>
+</web-app>
+```
+
+即必须将dubbo的BootstrapListener和DispatherServlet添加到web.xml，以完成dubbo的REST功能与外部servlet容器的集成。
+
+> 注意：如果你是用spring的ContextLoaderListener来加载spring，则必须保证BootstrapListener配置在ContextLoaderListener之前，否则dubbo初始化会出错。
+
+其实，这种场景下你依然可以坚持用嵌入式server，但外部应用服务器的servlet容器往往比嵌入式server更加强大（特别是如果你是部署到更健壮更可伸缩的WebLogic，WebSphere等），另外有时也便于在应用服务器做统一管理、监控等等。
+
+### 获取上下文（Context）信息
+
+在远程调用中，值得获取的上下文信息可能有很多种，这里特别以获取客户端IP为例。
+
+在dubbo的REST中，我们有两种方式获取客户端IP。
+
+第一种方式，用JAX-RS标准的@Context annotation：
+
+```java
+public User getUser(@PathParam("id") Long id, @Context HttpServletRequest request) {
+ System.out.println("Client address is " + request.getRemoteAddr());
+}
+```
+
+用Context修饰getUser()的一个方法参数后，就可以将当前的HttpServletRequest注入进来，然后直接调用servlet api获取IP。
+
+> 注意：这种方式只能在将server设置为 tjws、tomcat、jetty 或者 servlet 的时候才能工作，因为只有这几种 server 的实现才提供了 servlet 容器。另外，标准的JAX-RS还支持用@Context修饰service类的一个实例字段来获取HttpServletRequest，但在dubbo中我们没有对此作出支持。
+
+第二种方式，用dubbo中常用的RpcContext：
+
+```java
+public User getUser(@PathParam("id") Long id) {
+ System.out.println("Client address is " + RpcContext.getContext().getRemoteAddressString());
+}
+```
+
+> 注意：这种方式只能在设置server="jetty"或者server="tomcat"或者server="servlet"或者server="tjws"的时候才能工作。另外，目前dubbo的RpcContext是一种比较有侵入性的用法，未来我们很可能会做出重构。
+
+如果你想保持你的项目对JAX-RS的兼容性，未来脱离dubbo也可以运行，请选择第一种方式。如果你想要更优雅的服务接口定义，请选用第二种方式。
+
+此外，在最新的dubbo rest中，还支持通过RpcContext来获取HttpServletRequest和HttpServletResponse，以提供更大的灵活性来方便用户实现某些复杂功能，比如在dubbo标准的filter中访问HTTP Header。用法示例如下：
+
+```java
+if (RpcContext.getContext().getRequest() != null && RpcContext.getContext().getRequest() instanceof HttpServletRequest) {
+ System.out.println("Client address is " + ((HttpServletRequest) RpcContext.getContext().getRequest()).getRemoteAddr());
+}
+
+if (RpcContext.getContext().getResponse() != null && RpcContext.getContext().getResponse() instanceof HttpServletResponse) {
+ System.out.println("Response object from RpcContext: " + RpcContext.getContext().getResponse());
+}
+```
+
+> 注意：为了保持协议的中立性，RpcContext.getRequest()和RpcContext.getResponse()返回的仅仅是一个Object类，而且可能为null。所以，你必须自己做null和类型的检查。
+
+> 注意：只有在设置server="jetty"或者server="tomcat"或者server="servlet"的时候，你才能通过以上方法正确的得到HttpServletRequest和HttpServletResponse，因为只有这几种server实现了servlet容器。
+
+为了简化编程，在此你也可以用泛型的方式来直接获取特定类型的request/response：
+
+```java
+if (RpcContext.getContext().getRequest(HttpServletRequest.class) != null) {
+ System.out.println("Client address is " + RpcContext.getContext().getRequest(HttpServletRequest.class).getRemoteAddr());
+}
+
+if (RpcContext.getContext().getResponse(HttpServletResponse.class) != null) {
+ System.out.println("Response object from RpcContext: " + RpcContext.getContext().getResponse(HttpServletResponse.class));
+}
+```
+
+如果request/response不符合指定的类型，这里也会返回null。
+
+### 配置端口号和Context Path
+
+dubbo中的rest协议默认将采用80端口，如果想修改端口，直接配置：
+
+```xml
+<dubbo:protocol name="rest" port="8888"/>
+```
+
+另外，如前所述，我们可以用@Path来配置单个rest服务的URL相对路径。但其实，我们还可以设置一个所有rest服务都适用的基础相对路径，即java web应用中常说的context path。
+
+只需要添加如下contextpath属性即可：
+
+```xml
+<dubbo:protocol name="rest" port="8888" contextpath="services"/>
+```
+
+以前面代码为例：
+
+```java
+@Path("/users")
+public class UserServiceImpl implements UserService {
+
+ @POST
+ @Path("/register")
+ @Consumes({MediaType.APPLICATION_JSON})
+ public void registerUser(User user) {
+ // save the user...
+ }
+}
+```
+
+现在registerUser()的完整访问路径为：
+
+```
+http://localhost:8888/services/users/register
+```
+
+注意：如果你是选用外部应用服务器做rest server，即配置:
+
+```xml
+<dubbo:protocol name="rest" port="8888" contextpath="services" server="servlet"/>
+```
+
+则必须保证这里设置的port、contextpath，与外部应用服务器的端口、DispatcherServlet的上下文路径（即webapp path加上servlet url pattern）保持一致。例如，对于部署为tomcat ROOT路径的应用，这里的contextpath必须与web.xml中DispacherServlet的`<url-pattern/>`完全一致：
+
+```xml
+<servlet-mapping>
+ <servlet-name>dispatcher</servlet-name>
+ <url-pattern>/services/*</url-pattern>
+</servlet-mapping>
+```
+
+### 配置线程数和IO线程数
+
+可以为rest服务配置线程池大小：
+
+```xml
+<dubbo:protocol name="rest" threads="500"/>
+```
+
+> 注意：目前线程池的设置只有当server="netty"或者server="jetty"或者server="tomcat"的时候才能生效。另外，如果server="servlet"，由于这时候启用的是外部应用服务器做rest server，不受dubbo控制，所以这里的线程池设置也无效。
+
+如果是选用netty server，还可以配置Netty的IO worker线程数：
+
+```xml
+<dubbo:protocol name="rest" iothreads="5" threads="100"/>
+```
+
+### 配置长连接
+
+Dubbo中的rest服务默认都是采用http长连接来访问，如果想切换为短连接，直接配置：
+
+```xml
+<dubbo:protocol name="rest" keepalive="false"/>
+```
+
+> 注意：这个配置目前只对server="netty"和server="tomcat"才能生效。
+
+### 配置最大的HTTP连接数
+
+可以配置服务器提供端所能同时接收的最大HTTP连接数，防止REST server被过多连接撑爆，以作为一种最基本的自我保护机制：
+
+```xml
+<dubbo:protocol name="rest" accepts="500" server="tomcat/>
+```
+
+> 注意：这个配置目前只对server="tomcat"才能生效。
+
+### 配置每个消费端的超时时间和HTTP连接数
+
+如果rest服务的消费端也是dubbo系统，可以像其他dubbo RPC机制一样，配置消费端调用此rest服务的最大超时时间以及每个消费端所能启动的最大HTTP连接数。
+
+```xml
+<dubbo:service interface="xxx" ref="xxx" protocol="rest" timeout="2000" connections="10"/>
+```
+
+当然，由于这个配置针对消费端生效的，所以也可以在消费端配置：
+
+```xml
+<dubbo:reference id="xxx" interface="xxx" timeout="2000" connections="10"/>
+```
+
+但是，通常我们建议配置在服务提供端提供此类配置。按照dubbo官方文档的说法：“Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题。”
+
+> 注意：如果dubbo的REST服务是发布给非dubbo的客户端使用，则这里`<dubbo:service/>`上的配置完全无效，因为这种客户端不受dubbo控制。
+
+
+### 用Annotation取代部分Spring XML配置
+
+以上所有的讨论都是基于dubbo在spring中的xml配置。但是，dubbo/spring本身也支持用annotation来作配置，所以我们也可以按dubbo官方文档中的步骤，把相关annotation加到REST服务的实现中，取代一些xml配置，例如：
+
+```java
+@Service(protocol = "rest")
+@Path("/users")
+public class UserServiceImpl implements UserService {
+
+ @Autowired
+ private UserRepository userRepository;
+
+ @POST
+ @Path("/register")
+ @Consumes({MediaType.APPLICATION_JSON})
+ public void registerUser(User user) {
+ // save the user
+ userRepository.save(user);
+ }
+}
+```
+
+annotation的配置更简单更精确，通常也更便于维护（当然现代IDE都可以在xml中支持比如类名重构，所以就这里的特定用例而言，xml的维护性也很好）。而xml对代码的侵入性更小一些，尤其有利于动态修改配置，特别是比如你要针对单个服务配置连接超时时间、每客户端最大连接数、集群策略、权重等等。另外，特别对复杂应用或者模块来说，xml提供了一个中心点来涵盖的所有组件和配置，更一目了然，一般更便于项目长时期的维护。
+
+当然，选择哪种配置方式没有绝对的优劣，和个人的偏好也不无关系。
+
+### 添加自定义的Filter、Interceptor等
+
+Dubbo的REST也支持JAX-RS标准的Filter和Interceptor，以方便对REST的请求与响应过程做定制化的拦截处理。
+
+其中，Filter主要用于访问和设置HTTP请求和响应的参数、URI等等。例如，设置HTTP响应的cache header：
+
+```java
+public class CacheControlFilter implements ContainerResponseFilter {
+
+ public void filter(ContainerRequestContext req, ContainerResponseContext res) {
+ if (req.getMethod().equals("GET")) {
+ res.getHeaders().add("Cache-Control", "someValue");
+ }
+ }
+}
+```
+
+Interceptor主要用于访问和修改输入与输出字节流，例如，手动添加GZIP压缩：
+
+```java
+public class GZIPWriterInterceptor implements WriterInterceptor {
+
+ @Override
+ public void aroundWriteTo(WriterInterceptorContext context)
+ throws IOException, WebApplicationException {
+ OutputStream outputStream = context.getOutputStream();
+ context.setOutputStream(new GZIPOutputStream(outputStream));
+ context.proceed();
+ }
+}
+```
+
+在标准JAX-RS应用中，我们一般是为Filter和Interceptor添加@Provider annotation，然后JAX-RS runtime会自动发现并启用它们。而在dubbo中，我们是通过添加XML配置的方式来注册Filter和Interceptor：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="xxx.TraceInterceptor, xxx.TraceFilter"/>
+```
+
+在此，我们可以将Filter、Interceptor和DynamicFeature这三种类型的对象都添加到`extension`属性上，多个之间用逗号分隔。（DynamicFeature是另一个接口，可以方便我们更动态的启用Filter和Interceptor，感兴趣请自行google。）
+
+当然，dubbo自身也支持Filter的概念，但我们这里讨论的Filter和Interceptor更加接近协议实现的底层，相比dubbo的filter，可以做更底层的定制化。
+
+> 注：这里的XML属性叫extension，而不是叫interceptor或者filter，是因为除了Interceptor和Filter，未来我们还会添加更多的扩展类型。
+
+如果REST的消费端也是dubbo系统（参见下文的讨论），则也可以用类似方式为消费端配置Interceptor和Filter。但注意，JAX-RS中消费端的Filter和提供端的Filter是两种不同的接口。例如前面例子中服务端是ContainerResponseFilter接口，而消费端对应的是ClientResponseFilter:
+
+```java
+public class LoggingFilter implements ClientResponseFilter {
+
+ public void filter(ClientRequestContext reqCtx, ClientResponseContext resCtx) throws IOException {
+ System.out.println("status: " + resCtx.getStatus());
+ System.out.println("date: " + resCtx.getDate());
+ System.out.println("last-modified: " + resCtx.getLastModified());
+ System.out.println("location: " + resCtx.getLocation());
+ System.out.println("headers:");
+ for (Entry<String, List<String>> header : resCtx.getHeaders().entrySet()) {
+ System.out.print("\t" + header.getKey() + " :");
+ for (String value : header.getValue()) {
+ System.out.print(value + ", ");
+ }
+ System.out.print("\n");
+ }
+ System.out.println("media-type: " + resCtx.getMediaType().getType());
+ }
+}
+```
+
+### 添加自定义的Exception处理
+
+Dubbo的REST也支持JAX-RS标准的ExceptionMapper，可以用来定制特定exception发生后应该返回的HTTP响应。
+
+```java
+public class CustomExceptionMapper implements ExceptionMapper<NotFoundException> {
+
+ public Response toResponse(NotFoundException e) {
+ return Response.status(Response.Status.NOT_FOUND).entity("Oops! the requested resource is not found!").type("text/plain").build();
+ }
+}
+```
+
+和Interceptor、Filter类似，将其添加到XML配置文件中即可启用：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="xxx.CustomExceptionMapper"/>
+```
+
+### 配置HTTP日志输出
+
+Dubbo rest支持输出所有HTTP请求/响应中的header字段和body消息体。
+
+在XML配置中添加如下自带的REST filter：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="org.apache.dubbo.rpc.protocol.rest.support.LoggingFilter"/>
+```
+
+然后配置在logging配置中至少为org.apache.dubbo.rpc.protocol.rest.support打开INFO级别日志输出，例如，在log4j.xml中配置：
+
+```xml
+<logger name="org.apache.dubbo.rpc.protocol.rest.support">
+ <level value="INFO"/>
+ <appender-ref ref="CONSOLE"/>
+</logger>
+```
+
+当然，你也可以直接在ROOT logger打开INFO级别日志输出：
+
+```xml
+<root>
+ <level value="INFO" />
+ <appender-ref ref="CONSOLE"/>
+</root>
+```
+
+然后在日志中会有类似如下的内容输出：
+
+```
+The HTTP headers are:
+accept: application/json;charset=UTF-8
+accept-encoding: gzip, deflate
+connection: Keep-Alive
+content-length: 22
+content-type: application/json
+host: 192.168.1.100:8888
+user-agent: Apache-HttpClient/4.2.1 (java 1.5)
+```
+
+```
+The contents of request body is:
+{"id":1,"name":"dang"}
+```
+
+打开HTTP日志输出后，除了正常日志输出的性能开销外，也会在比如HTTP请求解析时产生额外的开销，因为需要建立额外的内存缓冲区来为日志的输出做数据准备。
+
+### 输入参数的校验
+
+dubbo的rest支持采用Java标准的bean validation annotation（JSR 303)来做输入校验http://beanvalidation.org/
+
+为了和其他dubbo远程调用协议保持一致，在rest中作校验的annotation必须放在服务的接口上，例如：
+
+```java
+public interface UserService {
+
+ User getUser(@Min(value=1L, message="User ID must be greater than 1") Long id);
+}
+
+```
+
+当然，在很多其他的bean validation的应用场景都是将annotation放到实现类而不是接口上。把annotation放在接口上至少有一个好处是，dubbo的客户端可以共享这个接口的信息，dubbo甚至不需要做远程调用，在本地就可以完成输入校验。
+
+然后按照dubbo的标准方式在XML配置中打开验证：
+
+```xml
+<dubbo:service interface=xxx.UserService" ref="userService" protocol="rest" validation="true"/>
+```
+
+在dubbo的其他很多远程调用协议中，如果输入验证出错，是直接将`RpcException`抛向客户端，而在rest中由于客户端经常是非dubbo，甚至非java的系统，所以不便直接抛出Java异常。因此，目前我们将校验错误以XML的格式返回：
+
+```xml
+<violationReport>
+ <constraintViolations>
+ <path>getUserArgument0</path>
+ <message>User ID must be greater than 1</message>
+ <value>0</value>
+ </constraintViolations>
+</violationReport>
+```
+
+稍后也会支持其他数据格式的返回值。至于如何对验证错误消息作国际化处理，直接参考bean validation的相关文档即可。
+
+如果你认为默认的校验错误返回格式不符合你的要求，可以如上面章节所述，添加自定义的ExceptionMapper来自由的定制错误返回格式。需要注意的是，这个ExceptionMapper必须用泛型声明来捕获dubbo的RpcException，才能成功覆盖dubbo rest默认的异常处理策略。为了简化操作，其实这里最简单的方式是直接继承dubbo rest的RpcExceptionMapper，并覆盖其中处理校验异常的方法即可：
+
+```java
+public class MyValidationExceptionMapper extends RpcExceptionMapper {
+
+ protected Response handleConstraintViolationException(ConstraintViolationException cve) {
+ ViolationReport report = new ViolationReport();
+ for (ConstraintViolation cv : cve.getConstraintViolations()) {
+ report.addConstraintViolation(new RestConstraintViolation(
+ cv.getPropertyPath().toString(),
+ cv.getMessage(),
+ cv.getInvalidValue() == null ? "null" : cv.getInvalidValue().toString()));
+ }
+ // 采用json输出代替xml输出
+ return Response.status(Response.Status.INTERNAL_SERVER_ERROR).entity(report).type(ContentType.APPLICATION_JSON_UTF_8).build();
+ }
+}
+```
+
+然后将这个ExceptionMapper添加到XML配置中即可：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="xxx.MyValidationExceptionMapper"/>
+```
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/rmi.md b/content/zh/docs/v3.0/references/configuration/references/protocol/rmi.md
new file mode 100644
index 0000000..67106a7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/rmi.md
@@ -0,0 +1,92 @@
+---
+type: docs
+title: "rmi 协议"
+linkTitle: "rmi://"
+weight: 5
+description: "rmi:// 协议参考手册"
+---
+
+
+RMI 协议采用 JDK 标准的 `java.rmi.*` 实现，采用阻塞式短连接和 JDK 标准序列化方式。
+
+注意：如果正在使用 RMI 提供服务给外部访问 [^1]，同时应用里依赖了老的 common-collections 包 [^2] 的情况下，存在反序列化安全风险 [^3]。
+
+## 特性
+
+* 连接个数：多连接
+* 连接方式：短连接
+* 传输协议：TCP
+* 传输方式：同步传输
+* 序列化：Java 标准二进制序列化
+* 适用范围：传入传出参数数据包大小混合，消费者与提供者个数差不多，可传文件。
+* 适用场景：常规远程服务方法调用，与原生RMI服务互操作
+
+## 约束
+
+* 参数及返回值需实现 `Serializable` 接口
+* dubbo 配置中的超时时间对 RMI 无效，需使用 java 启动参数设置：`-Dsun.rmi.transport.tcp.responseTimeout=3000`，参见下面的 RMI 配置
+
+## dubbo.properties 配置
+
+```properties
+dubbo.service.protocol=rmi
+```
+
+## RMI配置
+
+```sh
+java -Dsun.rmi.transport.tcp.responseTimeout=3000
+```
+更多 RMI 优化参数请查看 [JDK 文档](https://docs.oracle.com/javase/6/docs/technotes/guides/rmi/sunrmiproperties.html)
+
+
+## 接口
+
+如果服务接口继承了 `java.rmi.Remote` 接口，可以和原生 RMI 互操作，即：
+
+* 提供者用 Dubbo 的 RMI 协议暴露服务，消费者直接用标准 RMI 接口调用，
+* 或者提供方用标准 RMI 暴露服务，消费方用 Dubbo 的 RMI 协议调用。
+
+如果服务接口没有继承 `java.rmi.Remote` 接口：
+
+* 缺省 Dubbo 将自动生成一个 `com.xxx.XxxService$Remote` 的接口，并继承 `java.rmi.Remote` 接口，并以此接口暴露服务，
+* 但如果设置了 `<dubbo:protocol name="rmi" codec="spring" />`，将不生成 `$Remote` 接口，而使用 Spring 的 `RmiInvocationHandler` 接口暴露服务，和 Spring 兼容。
+
+## 配置
+
+定义 RMI 协议：
+
+```xml
+<dubbo:protocol name="rmi" port="1099" />
+```
+
+设置默认协议：
+
+```xml
+<dubbo:provider protocol="rmi" />
+```
+
+设置服务协议：
+
+```xml
+<dubbo:service protocol="rmi" />
+```
+
+多端口：
+
+```xml
+<dubbo:protocol id="rmi1" name="rmi" port="1099" />
+<dubbo:protocol id="rmi2" name="rmi" port="2099" />
+
+<dubbo:service protocol="rmi1" />
+```
+
+Spring 兼容性：
+
+```xml
+<dubbo:protocol name="rmi" codec="spring" />
+```
+
+[^1]: 公司内网环境应该不会有攻击风险
+[^2]: dubbo 不会依赖这个包，请排查自己的应用有没有使用
+[^3]: 请检查应用：将 commons-collections3 请升级到 [3.2.2](https://commons.apache.org/proper/commons-collections/release_3_2_2.html)；将 commons-collections4 请升级到 [4.1](https://commons.apache.org/proper/commons-collections/release_4_1.html)。新版本的 commons-collections 解决了该问题
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/thrift.md b/content/zh/docs/v3.0/references/configuration/references/protocol/thrift.md
new file mode 100644
index 0000000..759987f
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/thrift.md
@@ -0,0 +1,45 @@
+---
+type: docs
+title: "thrift 协议"
+linkTitle: "thrift://"
+weight: 4
+description: "thrift:// 协议参考手册"
+---
+
+
+当前 dubbo 支持的 thrift 协议是对 thrift 原生协议 [^1] 的扩展，在原生协议的基础上添加了一些额外的头信息，比如 service name，magic number 等。
+
+{{% alert title="提示" color="primary" %}}
+`2.3.0` 以上版本支持
+{{% /alert %}}
+
+使用 dubbo thrift 协议同样需要使用 thrift 的 idl compiler 编译生成相应的 java 代码，后续版本中会在这方面做一些增强。
+
+## 依赖
+
+```xml
+<dependency>
+ <groupId>org.apache.thrift</groupId>
+ <artifactId>libthrift</artifactId>
+ <version>0.8.0</version>
+</dependency>
+```
+
+## 配置
+
+所有服务共用一个端口 [^2]：
+
+```xml
+<dubbo:protocol name="thrift" port="3030" />
+```
+
+## 使用
+
+可以参考 [dubbo 项目中的示例代码](https://github.com/apache/dubbo/tree/master/dubbo-rpc/dubbo-rpc-thrift/src/test/java/org/apache/dubbo/rpc/protocol/thrift)
+
+## 常见问题
+
+* Thrift 不支持 null 值，即：不能在协议中传递 null 值
+
+[^1]: [Thrift](http://thrift.apache.org) 是 Facebook 捐给 Apache 的一个 RPC 框架
+[^2]: 与原生Thrift不兼容
diff --git a/content/zh/docs/v3.0/references/configuration/references/protocol/webservice.md b/content/zh/docs/v3.0/references/configuration/references/protocol/webservice.md
new file mode 100644
index 0000000..9afc7be
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/protocol/webservice.md
@@ -0,0 +1,119 @@
+---
+type: docs
+title: "webservice 协议"
+linkTitle: "webservice://"
+weight: 5
+description: "webservice:// 协议参考手册"
+---
+
+基于 WebService 的远程调用协议，基于 [Apache CXF](http://cxf.apache.org) [^1] 的 `frontend-simple` 和 `transports-http` 实现。
+
+{{% alert title="提示" color="primary" %}}
+`2.3.0` 以上版本支持
+{{% /alert %}}
+
+可以和原生 WebService 服务互操作，即：
+
+* 提供者用 Dubbo 的 WebService 协议暴露服务，消费者直接用标准 WebService 接口调用，
+* 或者提供方用标准 WebService 暴露服务，消费方用 Dubbo 的 WebService 协议调用。
+
+## 依赖
+
+```xml
+<dependency>
+ <groupId>org.apache.cxf</groupId>
+ <artifactId>cxf-rt-frontend-simple</artifactId>
+ <version>2.6.1</version>
+</dependency>
+<dependency>
+ <groupId>org.apache.cxf</groupId>
+ <artifactId>cxf-rt-transports-http</artifactId>
+ <version>2.6.1</version>
+</dependency>
+```
+
+## 特性
+
+* 连接个数：多连接
+* 连接方式：短连接
+* 传输协议：HTTP
+* 传输方式：同步传输
+* 序列化：SOAP 文本序列化
+* 适用场景：系统集成，跨语言调用
+
+## 约束
+
+* 参数及返回值需实现 `Serializable` 接口
+* 参数尽量使用基本类型和 POJO
+
+## 配置
+
+配置协议：
+
+```xml
+<dubbo:protocol name="webservice" port="8080" server="jetty" />
+```
+
+配置默认协议：
+
+```xml
+<dubbo:provider protocol="webservice" />
+```
+
+配置服务协议：
+
+```xml
+<dubbo:service protocol="webservice" />
+```
+
+多端口：
+
+```xml
+<dubbo:protocol id="webservice1" name="webservice" port="8080" />
+<dubbo:protocol id="webservice2" name="webservice" port="8081" />
+```
+
+直连：
+
+```xml
+<dubbo:reference id="helloService" interface="HelloWorld" url="webservice://10.20.153.10:8080/com.foo.HelloWorld" />
+```
+
+WSDL：
+
+```
+http://10.20.153.10:8080/com.foo.HelloWorld?wsdl
+```
+
+Jetty Server (默认)：
+
+```xml
+<dubbo:protocol ... server="jetty" />
+```
+
+Servlet Bridge Server (推荐)：
+
+```xml
+<dubbo:protocol ... server="servlet" />
+```
+
+配置 DispatcherServlet：
+
+```xml
+<servlet>
+ <servlet-name>dubbo</servlet-name>
+ <servlet-class>org.apache.dubbo.remoting.http.servlet.DispatcherServlet</servlet-class>
+ <load-on-startup>1</load-on-startup>
+</servlet>
+<servlet-mapping>
+ <servlet-name>dubbo</servlet-name>
+ <url-pattern>/*</url-pattern>
+</servlet-mapping>
+```
+
+注意，如果使用 servlet 派发请求：
+
+* 协议的端口 `<dubbo:protocol port="8080" />` 必须与 servlet 容器的端口相同，
+* 协议的上下文路径 `<dubbo:protocol contextpath="foo" />` 必须与 servlet 应用的上下文路径相同。
+
+[^1]: CXF 是 Apache 开源的一个 RPC 框架，由 Xfire 和 Celtix 合并而来
diff --git a/content/zh/docs/v3.0/references/configuration/references/qos.md b/content/zh/docs/v3.0/references/configuration/references/qos.md
new file mode 100644
index 0000000..244af15
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/qos.md
@@ -0,0 +1,243 @@
+---
+type: docs
+title: "在线运维命令参考手册"
+linkTitle: "QOS 手册"
+weight: 11
+description: "新版本 telnet 命令使用说明"
+---
+
+dubbo `2.5.8` 新版本增加了 QOS 模块，提供了新的 telnet 命令支持。
+
+## 端口
+新版本的 telnet 端口 与 dubbo 协议的端口是不同的端口，默认为 `22222`，可通过配置文件`dubbo.properties` 修改:
+
+```
+dubbo.application.qos.port=33333
+```
+
+或者通过设置 JVM 参数:
+
+```
+-Ddubbo.application.qos.port=33333
+```
+
+## 安全
+
+默认情况下，dubbo 接收任何主机发起的命令，可通过配置文件`dubbo.properties` 修改:
+
+```
+dubbo.application.qos.accept.foreign.ip=false
+```
+
+或者通过设置 JVM 参数:
+
+```
+-Ddubbo.application.qos.accept.foreign.ip=false
+```
+
+拒绝远端主机发出的命令，只允许服务本机执行
+
+
+## telnet 与 http 协议
+
+telnet 模块现在同时支持 http 协议和 telnet 协议，方便各种情况的使用
+
+示例如下：
+
+```
+➜ ~ telnet localhost 22222
+Trying ::1...
+telnet: connect to address ::1: Connection refused
+Trying 127.0.0.1...
+Connected to localhost.
+Escape character is '^]'.
+ ████████▄ ███ █▄ ▀█████████▄ ▀█████████▄ ▄██████▄
+ ███ ▀███ ███ ███ ███ ███ ███ ███ ███ ███
+ ███ ███ ███ ███ ███ ███ ███ ███ ███ ███
+ ███ ███ ███ ███ ▄███▄▄▄██▀ ▄███▄▄▄██▀ ███ ███
+ ███ ███ ███ ███ ▀▀███▀▀▀██▄ ▀▀███▀▀▀██▄ ███ ███
+ ███ ███ ███ ███ ███ ██▄ ███ ██▄ ███ ███
+ ███ ▄███ ███ ███ ███ ███ ███ ███ ███ ███
+ ████████▀ ████████▀ ▄█████████▀ ▄█████████▀ ▀██████▀
+
+
+dubbo>ls
+As Provider side:
++----------------------------------+---+
+| Provider Service Name |PUB|
++----------------------------------+---+
+|org.apache.dubbo.demo.DemoService| N |
++----------------------------------+---+
+As Consumer side:
++---------------------+---+
+|Consumer Service Name|NUM|
++---------------------+---+
+
+dubbo>
+```
+
+
+```
+➜ ~ curl "localhost:22222/ls?arg1=xxx&arg2=xxxx"
+As Provider side:
++----------------------------------+---+
+| Provider Service Name |PUB|
++----------------------------------+---+
+|org.apache.dubbo.demo.DemoService| N |
++----------------------------------+---+
+As Consumer side:
++---------------------+---+
+|Consumer Service Name|NUM|
++---------------------+---+
+```
+
+## 支持的命令
+
+### ls 列出消费者和提供者
+
+```
+dubbo>ls
+As Provider side:
++----------------------------------+---+
+| Provider Service Name |PUB|
++----------------------------------+---+
+|org.apache.dubbo.demo.DemoService| Y |
++----------------------------------+---+
+As Consumer side:
++---------------------+---+
+|Consumer Service Name|NUM|
++---------------------+---+
+```
+
+列出 dubbo 的所提供的服务和消费的服务，以及消费的服务地址数
+
+### Online 上线服务命令
+
+当使用延迟发布功能的时候(通过设置 org.apache.dubbo.config.AbstractServiceConfig#register 为 false)，后续需要上线的时候，可通过 Online 命令
+
+```
+//上线所有服务
+dubbo>online
+OK
+
+//根据正则，上线部分服务
+dubbo>online com.*
+OK
+```
+
+常见使用场景：
+
+ - 当线上的 QPS 比较高的时候，当刚重启机器的时候，由于没有进行JIT 预热或相关资源没有预热，可能会导致大量超时，这个时候，可通过分批发布服务，逐渐加大流量
+ - 当由于某台机器由于某种原因，需要下线服务，然后又需要重新上线服务
+
+
+
+### Offline 下线服务命令
+
+由于故障等原因，需要临时下线服务保持现场，可以使用 Offline 下线命令。
+
+
+```
+//下线所有服务
+dubbo>offline
+OK
+
+//根据正则，下线部分服务
+dubbo>offline com.*
+OK
+```
+
+### help 命令
+
+
+
+```
+//列出所有命令
+dubbo>help
+
+//列出单个命令的具体使用情况
+dubbo>help online
++--------------+----------------------------------------------------------------------------------+
+| COMMAND NAME | online |
++--------------+----------------------------------------------------------------------------------+
+| EXAMPLE | online dubbo |
+| | online xx.xx.xxx.service |
++--------------+----------------------------------------------------------------------------------+
+
+dubbo>
+```
+
+## 相关参数说明
+
+QoS提供了一些启动参数，来对启动进行配置，他们主要包括：
+
+| 参数 | 说明 | 默认值 |
+| ------------------ | ----------------- | ------ |
+| qosEnable | 是否启动QoS | true |
+| qosPort | 启动QoS绑定的端口 | 22222 |
+| qosAcceptForeignIp | 是否允许远程访问 | false |
+
+> 注意，从2.6.4/2.7.0开始，qosAcceptForeignIp默认配置改为false，如果qosAcceptForeignIp设置为true，有可能带来安全风险，请仔细评估后再打开。
+
+QoS参数可以通过如下方式进行配置
+
+* 系统属性
+* dubbo.properties
+* XML方式
+* Spring-boot自动装配方式
+
+其中，上述方式的优先顺序为系统属性 > dubbo.properties > XML/Spring-boot自动装配方式。
+
+### 使用系统属性方式进行配置
+
+```
+-Ddubbo.application.qos.enable=true
+-Ddubbo.application.qos.port=33333
+-Ddubbo.application.qos.accept.foreign.ip=false
+```
+
+### 使用dubbo.properties文件进行配置
+
+在项目的`src/main/resources`目录下添加dubbo.properties文件，内容如下:
+```
+dubbo.application.qos.enable=true
+dubbo.application.qos.port=33333
+dubbo.application.qos.accept.foreign.ip=false
+```
+
+### 使用XML方法进行配置
+
+如果要通过XML配置响应的QoS相关的参数，可以进行如下配置：
+
+```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.xsd
+ http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
+ <dubbo:application name="demo-provider">
+ <dubbo:parameter key="qos.enable" value="true"/>
+ <dubbo:parameter key="qos.accept.foreign.ip" value="false"/>
+ <dubbo:parameter key="qos.port" value="33333"/>
+ </dubbo:application>
+ <dubbo:registry address="multicast://224.5.6.7:1234"/>
+ <dubbo:protocol name="dubbo" port="20880"/>
+ <dubbo:service interface="org.apache.dubbo.demo.provider.DemoService" ref="demoService"/>
+ <bean id="demoService" class="org.apache.dubbo.demo.provider.DemoServiceImpl"/>
+</beans>
+```
+
+### 使用spring-boot自动装配方式配置
+
+如果是spring-boot的应用，可以在`application.properties`或者`application.yml`上配置:
+
+```
+dubbo.application.qosEnable=true
+dubbo.application.qosPort=33333
+dubbo.application.qosAcceptForeignIp=false
+```
+
+
+
diff --git a/content/zh/docs/v3.0/references/configuration/references/registry/_index.md b/content/zh/docs/v3.0/references/configuration/references/registry/_index.md
new file mode 100644
index 0000000..e17456b
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/registry/_index.md
@@ -0,0 +1,9 @@
+---
+type: docs
+title: "注册中心参考手册"
+linkTitle: "注册中心参考手册"
+weight: 3
+description: "Dubbo 注册中心参考手册"
+---
+
+推荐使用 [Zookeeper 注册中心](zookeeper)
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/configuration/references/registry/multicast.md b/content/zh/docs/v3.0/references/configuration/references/registry/multicast.md
new file mode 100644
index 0000000..ad31bb4
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/registry/multicast.md
@@ -0,0 +1,46 @@
+---
+type: docs
+title: "Multicast 注册中心"
+linkTitle: "Multicast"
+weight: 2
+description: "Multicast 注册中心参考手册"
+---
+
+Multicast 注册中心不需要启动任何中心节点，只要广播地址一样，就可以互相发现。
+
+
+
+0. 提供方启动时广播自己的地址
+1. 消费方启动时广播订阅请求
+2. 提供方收到订阅请求时，单播自己的地址给订阅者，如果设置了 `unicast=false`，则广播给订阅者
+3. 消费方收到提供方地址时，连接该地址进行 RPC 调用。
+
+组播受网络结构限制，只适合小规模应用或开发阶段使用。组播地址段: 224.0.0.0 - 239.255.255.255
+
+## 配置
+
+```xml
+<dubbo:registry address="multicast://224.5.6.7:1234" />
+```
+
+或
+
+```xml
+<dubbo:registry protocol="multicast" address="224.5.6.7:1234" />
+```
+
+为了减少广播量，Dubbo 缺省使用单播发送提供者地址信息给消费者，如果一个机器上同时启了多个消费者进程，消费者需声明 `unicast=false`，否则只会有一个消费者能收到消息; 当服务者和消费者运行在同一台机器上，消费者同样需要声明`unicast=false`，否则消费者无法收到消息，导致No provider available for the service异常：
+
+```xml
+<dubbo:application name="demo-consumer">
+ <dubbo:parameter key="unicast" value="false" />
+</dubbo:application>
+```
+
+或
+
+```xml
+<dubbo:consumer>
+ <dubbo:parameter key="unicast" value="false" />
+</dubbo:consumer>
+```
diff --git a/content/zh/docs/v3.0/references/configuration/references/registry/nacos.md b/content/zh/docs/v3.0/references/configuration/references/registry/nacos.md
new file mode 100644
index 0000000..edd775b
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/registry/nacos.md
@@ -0,0 +1,135 @@
+---
+type: docs
+title: "Nacos 注册中心"
+linkTitle: "Nacos"
+weight: 1
+description: "Nacos 注册中心参考手册"
+---
+
+Nacos 是 Dubbo 生态系统中重要的注册中心实现，其中 [`dubbo-registry-nacos`](https://github.com/apache/incubator-dubbo/tree/master/dubbo-registry/dubbo-registry-nacos) 则是 Dubbo 融合 Nacos 注册中心的实现。
+
+## 预备工作
+
+当您将 [dubbo-registry-nacos](https://github.com/apache/incubator-dubbo/tree/master/dubbo-registry/dubbo-registry-nacos) 整合到您的 Dubbo 工程之前，请确保后台已经启动 Nacos 服务。如果您尚且不熟悉 Nacos 的基本使用的话，可先行参考 [Nacos 快速入门](https://nacos.io/en-us/docs/quick-start.html)。建议使用 Nacos `1.0.0` 及以上的版本。
+
+## 快速上手
+
+Dubbo 融合 Nacos 成为注册中心的操作步骤非常简单，大致步骤可分为“增加 Maven 依赖”以及“配置注册中心“。
+
+
+### 增加 Maven 依赖
+
+首先，您需要将 `dubbo-registry-nacos` 的 Maven 依赖添加到您的项目 `pom.xml` 文件中，并且强烈地推荐您使用 Dubbo `2.6.5`：
+
+```xml
+<dependencies>
+
+ ...
+
+ <!-- Dubbo Nacos registry dependency -->
+ <dependency>
+ <groupId>com.alibaba</groupId>
+ <artifactId>dubbo-registry-nacos</artifactId>
+ <version>0.0.2</version>
+ </dependency>
+
+ <!-- Keep latest Nacos client version -->
+ <dependency>
+ <groupId>com.alibaba.nacos</groupId>
+ <artifactId>nacos-client</artifactId>
+ <version>[0.6.1,)</version>
+ </dependency>
+
+ <!-- Dubbo dependency -->
+ <dependency>
+ <groupId>com.alibaba</groupId>
+ <artifactId>dubbo</artifactId>
+ <version>2.6.5</version>
+ </dependency>
+
+ <!-- Alibaba Spring Context extension -->
+ <dependency>
+ <groupId>com.alibaba.spring</groupId>
+ <artifactId>spring-context-support</artifactId>
+ <version>1.0.2</version>
+ </dependency>
+
+ ...
+
+</dependencies>
+```
+
+当项目中添加 `dubbo-registry-nacos` 后，您无需显式地编程实现服务发现和注册逻辑，实际实现由该三方包提供，接下来配置 Naocs 注册中心。
+
+### 配置注册中心
+
+假设您 Dubbo 应用使用 Spring Framework 装配，将有两种配置方法可选，分别为：[Dubbo Spring 外部化配置](https://mercyblitz.github.io/2018/01/18/Dubbo-%E5%A4%96%E9%83%A8%E5%8C%96%E9%85%8D%E7%BD%AE/)以及 Spring XML 配置文件，推荐前者。
+
+
+### Dubbo Spring 外部化配置
+
+> [参考](https://mercyblitz.github.io/2018/01/18/Dubbo-%E5%A4%96%E9%83%A8%E5%8C%96%E9%85%8D%E7%BD%AE/)
+
+Dubbo Spring 外部化配置是由 Dubbo `2.5.8` 引入的新特性，可通过 Spring `Environment` 属性自动地生成并绑定 Dubbo 配置 Bean，实现配置简化，并且降低微服务开发门槛。
+
+假设您的 Nacos Server 同样运行在服务器 `10.20.153.10` 上，并使用默认 Nacos 服务端口 `8848`，您只需将 `dubbo.registry.address` 属性调整如下：
+
+```properties
+## 其他属性保持不变
+
+## Nacos registry address
+dubbo.registry.address = nacos://10.20.153.10:8848
+...
+```
+
+随后，重启您的 Dubbo 应用，Dubbo 的服务提供和消费信息在 Nacos 控制台中可以显示：
+
+
+
+
+
+如图所示，服务名前缀为 `providers:` 的信息为服务提供者的元信息，`consumers:` 则代表服务消费者的元信息。点击“**详情**”可查看服务状态详情：
+
+
+
+如果您正在使用 Spring XML 配置文件装配 Dubbo 注册中心的话，请参考下一节。
+
+### Spring XML 配置文件
+
+与 [Dubbo Spring 外部化配置](https://mercyblitz.github.io/2018/01/18/Dubbo-%E5%A4%96%E9%83%A8%E5%8C%96%E9%85%8D%E7%BD%AE/) 配置类似，只需要调整 `address` 属性配置即可：
+
+```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="dubbo-provider-xml-demo" />
+
+ <!-- 使用 Nacos 注册中心 -->
+ <dubbo:registry address="nacos://10.20.153.10:8848" />
+ ...
+</beans>
+```
+
+
+
+重启 Dubbo 应用后，您同样也能发现服务提供方和消费方的注册元信息呈现在 Nacos 控制台中：
+
+
+
+
+**附加信息**: 在nacos-server@`1.0.0`版本后，支持客户端通过上报一些包含特定的元数据的实例到服务端来控制实例的一些行为。
+
+ 例如:
+`preserved.heart.beat.timeout` : 该实例在不发送心跳后，从健康到不健康的时间。（单位:毫秒）
+`preserved.ip.delete.timeout` : 该实例在不发送心跳后，被服务端下掉该实例的时间。（单位:毫秒）
+`preserved.heart.beat.interval` : 该实例在客户端上报心跳的间隔时间。（单位:毫秒）
+`preserved.instance.id.generator`: 该实例的id生成策略，值为`snowflake`时，从0开始增加。
+`preserved.register.source` : 保留键，目前未使用。
+
+该功能将在Dubbo@`2.7.10`开始支持，通过在address中增加参数来进行配置.
+例如: `nacos://10.20.153.10:8848?preserved.heart.beat.timeout=15000&preserved.ip.delete.timeout=30000&preserved.heart.beat.interval=10000`
+
diff --git a/content/zh/docs/v3.0/references/configuration/references/registry/redis.md b/content/zh/docs/v3.0/references/configuration/references/registry/redis.md
new file mode 100644
index 0000000..7b2a507
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/registry/redis.md
@@ -0,0 +1,86 @@
+---
+type: docs
+title: "Redis 注册中心"
+linkTitle: "Redis"
+weight: 3
+description: "Redis 注册中心参考手册"
+---
+
+基于 Redis [^1] 实现的注册中心。
+
+{{% alert title="提示" color="primary" %}}
+从 `2.1.0` 版本开始支持。
+
+Redis 过期数据通过心跳的方式检测脏数据，服务器时间必须同步，并且对服务器有一定压力，否则过期检测会不准确
+{{% /alert %}}
+
+
+
+使用 Redis 的 Key/Map 结构存储数据结构：
+
+* 主 Key 为服务名和类型
+* Map 中的 Key 为 URL 地址
+* Map 中的 Value 为过期时间，用于判断脏数据，脏数据由监控中心删除 [^3]
+
+使用 Redis 的 Publish/Subscribe 事件通知数据变更：
+
+* 通过事件的值区分事件类型：`register`, `unregister`, `subscribe`, `unsubscribe`
+* 普通消费者直接订阅指定服务提供者的 Key，只会收到指定服务的 `register`, `unregister` 事件
+* 监控中心通过 `psubscribe` 功能订阅 `/dubbo/*`，会收到所有服务的所有变更事件
+
+调用过程：
+
+0. 服务提供方启动时，向 `Key:/dubbo/com.foo.BarService/providers` 下，添加当前提供者的地址
+1. 并向 `Channel:/dubbo/com.foo.BarService/providers` 发送 `register` 事件
+2. 服务消费方启动时，从 `Channel:/dubbo/com.foo.BarService/providers` 订阅 `register` 和 `unregister` 事件
+3. 并向 `Key:/dubbo/com.foo.BarService/consumers` 下，添加当前消费者的地址
+4. 服务消费方收到 `register` 和 `unregister` 事件后，从 `Key:/dubbo/com.foo.BarService/providers` 下获取提供者地址列表
+5. 服务监控中心启动时，从 `Channel:/dubbo/*` 订阅 `register` 和 `unregister`，以及 `subscribe` 和`unsubsribe `事件
+6. 服务监控中心收到 `register` 和 `unregister` 事件后，从 `Key:/dubbo/com.foo.BarService/providers` 下获取提供者地址列表
+7. 服务监控中心收到 `subscribe` 和 `unsubsribe` 事件后，从 `Key:/dubbo/com.foo.BarService/consumers` 下获取消费者地址列表
+
+
+## 配置
+
+```xml
+<dubbo:registry address="redis://10.20.153.10:6379" />
+```
+
+或
+
+```xml
+<dubbo:registry address="redis://10.20.153.10:6379?backup=10.20.153.11:6379,10.20.153.12:6379" />
+```
+
+或
+
+```xml
+<dubbo:registry protocol="redis" address="10.20.153.10:6379" />
+```
+
+或
+
+```xml
+<dubbo:registry protocol="redis" address="10.20.153.10:6379,10.20.153.11:6379,10.20.153.12:6379" />
+```
+
+## 选项
+
+* 可通过 `<dubbo:registry group="dubbo" />` 设置 redis 中 key 的前缀，缺省为 `dubbo`。
+* 可通过 `<dubbo:registry cluster="replicate" />` 设置 redis 集群策略，缺省为 `failover`：
+ * `failover`: 只写入和读取任意一台，失败时重试另一台，需要服务器端自行配置数据同步
+ * `replicate`: 在客户端同时写入所有服务器，只读取单台，服务器端不需要同步，注册中心集群增大，性能压力也会更大
+
+
+## 可靠性声明
+
+阿里内部并没有采用 Redis 做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Redis 注册中心并没有在阿里内部长时间运行的可靠性保障，此 Redis 桥接实现只为开源版本提供，其可靠性依赖于 Redis 本身的可靠性。
+
+
+## 安装
+
+
+安装方式参见: [Redis安装手册]( ../../../admin/install/redis.md)，只需搭一个原生的 Redis 服务器，并将 [Quick Start](../../preface/usage.md) 中 Provider 和 Consumer 里的 `conf/dubbo.properties` 中的 `dubbo.registry.address` 的值改为 `redis://127.0.0.1:6379` 即可使用。
+
+
+[^1]: [Redis](http://redis.io) 是一个高效的 KV 存储服务器
diff --git a/content/zh/docs/v3.0/references/configuration/references/registry/simple.md b/content/zh/docs/v3.0/references/configuration/references/registry/simple.md
new file mode 100644
index 0000000..90a0e01
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/registry/simple.md
@@ -0,0 +1,55 @@
+---
+type: docs
+title: "Simple 注册中心"
+linkTitle: "Simple"
+weight: 4
+description: "Simple 注册中心参考手册"
+---
+
+Simple 注册中心本身就是一个普通的 Dubbo 服务，可以减少第三方依赖，使整体通讯方式一致。
+
+## 配置
+
+将 Simple 注册中心暴露成 Dubbo 服务：
+
+```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="simple-registry" />
+ <!-- 暴露服务协议配置 -->
+ <dubbo:protocol port="9090" />
+ <!-- 暴露服务配置 -->
+ <dubbo:service interface="org.apache.dubbo.registry.RegistryService" ref="registryService" registry="N/A" ondisconnect="disconnect" callbacks="1000">
+ <dubbo:method name="subscribe"><dubbo:argument index="1" callback="true" /></dubbo:method>
+ <dubbo:method name="unsubscribe"><dubbo:argument index="1" callback="false" /></dubbo:method>
+ </dubbo:service>
+ <!-- 简单注册中心实现，可自行扩展实现集群和状态同步 -->
+ <bean id="registryService" class="org.apache.dubbo.registry.simple.SimpleRegistryService" />
+</beans>
+```
+
+引用 Simple Registry 服务：
+
+```xml
+<dubbo:registry address="127.0.0.1:9090" />
+```
+
+或者：
+
+```xml
+<dubbo:service interface="org.apache.dubbo.registry.RegistryService" group="simple" version="1.0.0" ... >
+```
+
+或者：
+
+```xml
+<dubbo:registry address="127.0.0.1:9090" group="simple" version="1.0.0" />
+```
+
+## 适用性说明
+
+此 `SimpleRegistryService` 只是简单实现，不支持集群，可作为自定义注册中心的参考，但不适合直接用于生产环境。
diff --git a/content/zh/docs/v3.0/references/configuration/references/registry/zookeeper.md b/content/zh/docs/v3.0/references/configuration/references/registry/zookeeper.md
new file mode 100644
index 0000000..9031b83
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/registry/zookeeper.md
@@ -0,0 +1,167 @@
+---
+type: docs
+title: "Zookeeper 注册中心"
+linkTitle: "Zookeeper"
+weight: 1
+description: "Zookeeper 注册中心参考手册"
+---
+
+[Zookeeper](http://zookeeper.apache.org) 是 Apache Hadoop 的子项目，是一个树型的目录服务，支持变更推送，适合作为 Dubbo 服务的注册中心，工业强度较高，可用于生产环境，并推荐使用 [^1]。
+
+
+
+流程说明：
+
+* 服务提供者启动时: 向 `/dubbo/com.foo.BarService/providers` 目录下写入自己的 URL 地址
+* 服务消费者启动时: 订阅 `/dubbo/com.foo.BarService/providers` 目录下的提供者 URL 地址。并向 `/dubbo/com.foo.BarService/consumers` 目录下写入自己的 URL 地址
+* 监控中心启动时: 订阅 `/dubbo/com.foo.BarService` 目录下的所有提供者和消费者 URL 地址。
+
+支持以下功能：
+
+* 当提供者出现断电等异常停机时，注册中心能自动删除提供者信息
+* 当注册中心重启时，能自动恢复注册数据，以及订阅请求
+* 当会话过期时，能自动恢复注册数据，以及订阅请求
+* 当设置 `<dubbo:registry check="false" />` 时，记录失败注册和订阅请求，后台定时重试
+* 可通过 `<dubbo:registry username="admin" password="1234" />` 设置 zookeeper 登录信息
+* 可通过 `<dubbo:registry group="dubbo" />` 设置 zookeeper 的根节点，不配置将使用默认的根节点。
+* 支持 `*` 号通配符 `<dubbo:reference group="*" version="*" />`，可订阅服务的所有分组和所有版本的提供者
+
+## 使用
+
+在 provider 和 consumer 中增加 zookeeper 客户端 jar 包依赖：
+
+```xml
+<dependency>
+ <groupId>org.apache.zookeeper</groupId>
+ <artifactId>zookeeper</artifactId>
+ <version>3.3.3</version>
+</dependency>
+```
+
+或直接[下载](http://repo1.maven.org/maven2/org/apache/zookeeper/zookeeper)。
+
+Dubbo 支持 zkclient 和 curator 两种 Zookeeper 客户端实现：
+
+**注意:在2.7.x的版本中已经移除了zkclient的实现,如果要使用zkclient客户端,需要自行拓展**
+
+### 使用 zkclient 客户端
+
+从 `2.2.0` 版本开始缺省为 zkclient 实现，以提升 zookeeper 客户端的健壮性。[zkclient](https://github.com/sgroschupf/zkclient) 是 Datameer 开源的一个 Zookeeper 客户端实现。
+
+缺省配置：
+
+```xml
+<dubbo:registry ... client="zkclient" />
+```
+
+或：
+
+```sh
+dubbo.registry.client=zkclient
+```
+
+或：
+
+```sh
+zookeeper://10.20.153.10:2181?client=zkclient
+```
+
+需依赖或直接[下载](http://repo1.maven.org/maven2/com/github/sgroschupf/zkclient)：
+
+```xml
+<dependency>
+ <groupId>com.github.sgroschupf</groupId>
+ <artifactId>zkclient</artifactId>
+ <version>0.1</version>
+</dependency>
+```
+
+
+### 使用 curator 客户端
+
+从 `2.3.0` 版本开始支持可选 curator 实现。[Curator](https://github.com/apache/curator) 是 Netflix 开源的一个 Zookeeper 客户端实现。
+
+如果需要改为 curator 实现，请配置：
+
+```xml
+<dubbo:registry ... client="curator" />
+```
+
+或：
+
+```sh
+dubbo.registry.client=curator
+```
+
+或：
+
+```sh
+zookeeper://10.20.153.10:2181?client=curator
+```
+
+需依赖或直接下载[curator-framework](https://repo1.maven.org/maven2/org/apache/curator/curator-framework/), [curator-recipes](https://repo1.maven.org/maven2/org/apache/curator/curator-recipes/)：
+
+```xml
+<properties>
+ <dubbo.version>2.7.8</dubbo.version>
+ <zookeeper.version>2.12.0</zookeeper.version>
+</properties>
+
+<dependency>
+ <groupId>org.apache.curator</groupId>
+ <artifactId>curator-framework</artifactId>
+ <version>${zookeeper.version}</version>
+</dependency>
+<dependency>
+ <groupId>org.apache.curator</groupId>
+ <artifactId>curator-recipes</artifactId>
+ <version>${zookeeper.version}</version>
+</dependency>
+```
+
+Zookeeper 单机配置:
+
+```xml
+<dubbo:registry address="zookeeper://10.20.153.10:2181" />
+```
+
+或：
+
+```xml
+<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181" />
+```
+
+Zookeeper 集群配置：
+
+```xml
+
+<dubbo:registry address="zookeeper://10.20.153.10:2181?backup=10.20.153.11:2181,10.20.153.12:2181" />
+```
+
+或：
+
+```xml
+<dubbo:registry protocol="zookeeper" address="10.20.153.10:2181,10.20.153.11:2181,10.20.153.12:2181" />
+```
+
+同一 Zookeeper，分成多组注册中心:
+
+```xml
+<dubbo:registry id="chinaRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="china" />
+<dubbo:registry id="intlRegistry" protocol="zookeeper" address="10.20.153.10:2181" group="intl" />
+```
+
+## zookeeper 安装
+
+安装方式参见: [Zookeeper安装手册](../../../../admin/install/zookeeper)，只需搭一个原生的 Zookeeper 服务器，并将 [Quick Start](../../../quick-start) 中 Provider 和 Consumer 里的 `conf/dubbo.properties` 中的 `dubbo.registry.address` 的值改为 `zookeeper://127.0.0.1:2181` 即可使用。
+
+
+## 可靠性声明
+
+阿里内部并没有采用 Zookeeper 做为注册中心，而是使用自己实现的基于数据库的注册中心，即：Zookeeper 注册中心并没有在阿里内部长时间运行的可靠性保障，此 Zookeeper 桥接实现只为开源版本提供，其可靠性依赖于 Zookeeper 本身的可靠性。
+
+## 兼容性声明
+
+因 `2.0.8` 最初设计的 zookeeper 存储结构不能扩充不同类型的数据，`2.0.9` 版本做了调整，所以不兼容，需全部改用 `2.0.9` 版本才行，以后的版本会保持兼容 `2.0.9`。`2.2.0` 版本改为基于 zkclient 实现，需增加 zkclient 的依赖包，`2.3.0` 版本增加了基于 curator 的实现，作为可选实现策略。
+
+[^1]: 建议使用 `2.3.3` 以上版本的 zookeeper 注册中心客户端
diff --git a/content/zh/docs/v3.0/references/configuration/references/telnet.md b/content/zh/docs/v3.0/references/configuration/references/telnet.md
new file mode 100644
index 0000000..0ed0e41
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/telnet.md
@@ -0,0 +1,111 @@
+---
+type: docs
+title: "Telnet 命令参考手册"
+linkTitle: "Telnet 手册"
+weight: 11
+description: "通过 Telnet 命令进行服务治理"
+---
+
+从 `2.0.5` 版本开始，dubbo 开始支持通过 telnet 命令来进行服务治理。
+
+## 使用
+
+```sh
+telnet localhost 20880
+```
+
+或者：
+
+```sh
+echo status | nc -i 1 localhost 20880
+```
+
+
+status命令所检查的资源也可以扩展，参见：[扩展参考手册](../../../dev/impls/status-checker)。
+
+## 命令
+
+以下展示了 dubbo 内建的 telnet 命令的说明和用法，此外，telnet 命令还支持用户自行扩展，参见：[Telnet 命令扩展](../../../dev/impls/telnet-handler)。
+
+### `ls`
+
+0. `ls`: 显示服务列表
+0. `ls -l`: 显示服务详细信息列表
+0. `ls XxxService`: 显示服务的方法列表
+0. `ls -l XxxService`: 显示服务的方法详细信息列表
+
+
+### `ps`
+
+0. `ps`: 显示服务端口列表
+0. `ps -l`: 显示服务地址列表
+0. `ps 20880`: 显示端口上的连接信息
+0. `ps -l 20880`: 显示端口上的连接详细信息
+
+
+### `cd`
+
+0. `cd XxxService`: 改变缺省服务，当设置了缺省服务，凡是需要输入服务名作为参数的命令，都可以省略服务参数
+0. `cd /`: 取消缺省服务
+
+### `pwd`
+
+`pwd`: 显示当前缺省服务
+
+### `trace`
+
+0. `trace XxxService`: 跟踪 1 次服务任意方法的调用情况
+0. `trace XxxService 10`: 跟踪 10 次服务任意方法的调用情况
+0. `trace XxxService xxxMethod`: 跟踪 1 次服务方法的调用情况
+0. `trace XxxService xxxMethod 10`: 跟踪 10 次服务方法的调用情况
+
+### `count`
+
+0. `count XxxService`: 统计 1 次服务任意方法的调用情况
+0. `count XxxService 10`: 统计 10 次服务任意方法的调用情况
+0. `count XxxService xxxMethod`: 统计 1 次服务方法的调用情况
+0. `count XxxService xxxMethod 10`: 统计 10 次服务方法的调用情况
+
+### `invoke`
+
+0. `invoke XxxService.xxxMethod(1234, "abcd", {"prop" : "value"})`: 调用服务的方法
+0. `invoke com.xxx.XxxService.XxxService.xxxMethod(1234, "abcd", {"prop" : "value"})`: 调用全路径服务的方法
+0. `invoke xxxMethod(1234, "abcd", {"prop" : "value"})`: 调用服务的方法(自动查找包含此方法的服务)
+0. `invoke xxxMethod({"name":"zhangsan","age":12,"class":"org.apache.dubbo.qos.legacy.service.Person"})` :当有参数重载，或者类型转换失败的时候，可以通过增加class属性指定需要转换类
+0. 当参数为Map<Integer,T>，key的类型为Integer时，建议指定类型。例如`invoke com.xxx.xxxApiService({"3":0.123, "class":"java.util.HashMap"})`
+
+### `select` [^2]
+
+0. `select 1`: 当 invoke 命令匹配到多个方法时使用，根据提示列表选择需要调用的方法
+
+### `status`
+
+0. `status`: 显示汇总状态，该状态将汇总所有资源的状态，当全部 OK 时则显示 OK，只要有一个 ERROR 则显示 ERROR，只要有一个 WARN 则显示 WARN
+0. `status -l`: 显示状态列表
+
+### `log` [^1]
+
+0. `log debug`: 修改 dubbo logger 的日志级别
+0. `log 100`: 查看 file logger 的最后 100 字符的日志
+
+### `help`
+
+0. `help`: 显示 telnet 命帮助信息
+0. `help xxx`: 显示xxx命令的详细帮助信息
+
+### `clear`
+
+0. `clear`: 清除屏幕上的内容
+0. `clear 100`: 清除屏幕上的指定行数的内容
+
+### `exit`
+
+`exit`: 退出当前 telnet 命令行
+
+### `shutdown` [^2]
+
+0. `shutdown`: 关闭 dubbo 应用
+0. `shutdown -t 1000`: 延迟 1000 毫秒关闭 dubbo 应用
+
+[^1]: `2.0.6` 以上版本支持
+[^2]: `2.7.1` 以上版本支持
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/_index.md b/content/zh/docs/v3.0/references/configuration/references/xml/_index.md
new file mode 100644
index 0000000..fc7c7a3
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/_index.md
@@ -0,0 +1,20 @@
+---
+type: docs
+title: "Schema 配置参考手册"
+linkTitle: "XML 配置"
+weight: 1
+description: "Dubbo 的 XML Schema 配置参考手册"
+---
+
+这里以 XML Config [^1] 为准，列举所有配置项 [^2]。其它配置方式，请参见相应转换关系：[属性配置](../../configuration/properties)，[注解配置](../../configuration/annotation)，[API 配置](../../configuration/api)。
+
+所有配置项分为三大类，参见下表中的"作用" 一列。
+
+* 服务发现：表示该配置项用于服务的注册与发现，目的是让消费方找到提供方。
+* 服务治理：表示该配置项用于治理服务间的关系，或为开发测试提供便利条件。
+* 性能调优：表示该配置项用于调优性能，不同的选项对性能会产生影响。
+* 所有配置最终都将转换为 URL [^3] 表示，并由服务提供方生成，经注册中心传递给消费方，各属性对应 URL 的参数，参见配置项一览表中的 "对应URL参数" 列。
+
+[^1]: XML Schema: http://dubbo.apache.org/schema/dubbo/dubbo.xsd
+[^2]: 注意：只有 group，interface，version 是服务的匹配条件，三者决定是不是同一个服务，其它配置项均为调优和治理参数。
+[^3]: URL 格式：`protocol://username:password@host:port/path?key=value&key=value`
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-application.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-application.md
new file mode 100644
index 0000000..c165582
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-application.md
@@ -0,0 +1,20 @@
+---
+type: docs
+title: "dubbo:application"
+linkTitle: "dubbo:application"
+weight: 1
+description: "dubbo:application 配置"
+---
+
+应用信息配置。对应的配置类：`org.apache.dubbo.config.ApplicationConfig`
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| name | application | string | <b>必填</b> | | 服务治理 | 当前应用名称，用于注册中心计算应用间依赖关系，注意：消费者和提供者应用名不要一样，此参数不是匹配条件，你当前项目叫什么名字就填什么，和提供者消费者角色无关，比如：kylin应用调用了morgan应用的服务，则kylin项目配成kylin，morgan项目配成morgan，可能kylin也提供其它服务给别人使用，但kylin项目永远配成kylin，这样注册中心将显示kylin依赖于morgan | 1.0.16以上版本 |
+| version | application.version | string | 可选 | | 服务治理 | 当前应用的版本 | 2.2.0以上版本 |
+| owner | owner | string | 可选 | | 服务治理 | 应用负责人，用于服务治理，请填写负责人公司邮箱前缀 | 2.0.5以上版本 |
+| organization | organization | string | 可选 | | 服务治理 | 组织名称(BU或部门)，用于注册中心区分服务来源，此配置项建议不要使用autoconfig，直接写死在配置中，比如china,intl,itu,crm,asc,dw,aliexpress等 | 2.0.0以上版本 |
+| architecture <br class="atl-forced-newline" /> | architecture <br class="atl-forced-newline" /> | string | 可选 | | 服务治理 | 用于服务分层对应的架构。如，intl、china。不同的架构使用不同的分层。 | 2.0.7以上版本 |
+| environment | environment | string | 可选 | | 服务治理 | 应用环境，如：develop/test/product，不同环境使用不同的缺省值，以及作为只用于开发测试功能的限制条件 | 2.0.0以上版本 |
+| compiler | compiler | string | 可选 | javassist | 性能优化 | Java字节码编译器，用于动态类的生成，可选：jdk或javassist | 2.1.0以上版本 |
+| logger | logger | string | 可选 | slf4j | 性能优化 | 日志输出方式，可选：slf4j,jcl,log4j,log4j2,jdk | 2.2.0以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-argument.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-argument.md
new file mode 100644
index 0000000..5ae3618
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-argument.md
@@ -0,0 +1,20 @@
+---
+type: docs
+title: "dubbo:argument"
+linkTitle: "dubbo:argument"
+weight: 1
+description: "dubbo:argument 配置"
+---
+
+方法参数配置。对应的配置类： `org.apache.dubbo.config.ArgumentConfig`。该标签为 `<dubbo:method>` 的子标签，用于方法参数的特征描述，比如：
+
+```xml
+<dubbo:method name="findXxx" timeout="3000" retries="2">
+ <dubbo:argument index="0" callback="true" />
+</dubbo:method>
+```
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| index | | int | <b>必填</b> | | 标识 | 参数索引 | 2.0.6以上版本 |
+| type | | String | 与index二选一 | | 标识 | 通过参数类型查找参数的index | 2.0.6以上版本 |
+| callback | <metodName><index>.retries | boolean | 可选 | | 服务治理 | 参数是否为callback接口，如果为callback，服务提供方将生成反向代理，可以从服务提供方反向调用消费方，通常用于事件推送. | 2.0.6以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-config-center.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-config-center.md
new file mode 100644
index 0000000..f9963b7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-config-center.md
@@ -0,0 +1,25 @@
+---
+type: docs
+title: "dubbo:config-center"
+linkTitle: "dubbo:config-center"
+weight: 1
+description: "dubbo:config-center 配置"
+---
+
+配置中心。对应的配置类：`org.apache.dubbo.config.ConfigCenterConfig`
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 描述 | 兼容性 |
+| ---------------- | ---------------------- | ------------------- | -------- | ---------------- | ------------------------------------------------------------ | ------ |
+| protocol | config.protocol | string | 可选 | zookeeper | 使用哪个配置中心：apollo、zookeeper、nacos等。<br />以zookeeper为例<br />1. 指定protocol，则address可以简化为`127.0.0.1:2181`；<br />2. 不指定protocol，则address取值为`zookeeper://127.0.0.1:2181` | 2.7.0+ |
+| address | config.address | string | 必填 | | 配置中心地址。<br />取值参见protocol说明 | 2.7.0+ |
+| highest-priority | config.highestPriority | boolean | 可选 | true | 来自配置中心的配置项具有最高优先级，即会覆盖本地配置项。 | 2.7.0+ |
+| namespace | config.namespace | string | 可选 | dubbo | 通常用于多租户隔离，实际含义视具体配置中心而不同。<br />如：<br />zookeeper - 环境隔离，默认值`dubbo`；<br />apollo - 区分不同领域的配置集合，默认使用`dubbo`和`application` | 2.7.0+ |
+| cluster | config.cluster | string | 可选 | | 含义视所选定的配置中心而不同。<br />如Apollo中用来区分不同的配置集群 | 2.7.0+ |
+| group | config.group | string | 可选 | dubbo | 含义视所选定的配置中心而不同。<br />nacos - 隔离不同配置集<br />zookeeper - 隔离不同配置集 | 2.7.0+ |
+| check | config.check | boolean | 可选 | true | 当配置中心连接失败时，是否终止应用启动。 | 2.7.0+ |
+| config-file | config.configFile | string | 可选 | dubbo.properties | 全局级配置文件所映射到的key<br />zookeeper - 默认路径/dubbo/config/dubbo/dubbo.properties<br />apollo - dubbo namespace中的dubbo.properties键 | 2.7.0+ |
+| timeout | config.timeout | integer | | 3000ms | 获取配置的超时时间 | 2.7.0+ |
+| username | | string | | | 如果配置中心需要做校验，用户名<br />Apollo暂未启用 | 2.7.0+ |
+| password | | string | | | 如果配置中心需要做校验，密码<br />Apollo暂未启用 | 2.7.0+ |
+| parameters | | Map<string, string> | | | 扩展参数，用来支持不同配置中心的定制化配置参数 | 2.7.0+ |
+| include-spring-env | | boolean | 可选 | false | 使用Spring框架时支持，为true时，会自动从Spring Environment中读取配置。<br />默认依次读取<br />key为dubbo.properties的配置<br />key为dubbo.properties的PropertySource | 2.7.0+ |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-consumer.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-consumer.md
new file mode 100644
index 0000000..abeb6b0
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-consumer.md
@@ -0,0 +1,30 @@
+---
+type: docs
+title: "dubbo:consumer"
+linkTitle: "dubbo:consumer"
+weight: 1
+description: "dubbo:consumer 配置"
+---
+
+服务消费者缺省值配置。配置类： `org.apache.dubbo.config.ConsumerConfig` 。同时该标签为 `<dubbo:reference>` 标签的缺省值设置。
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| timeout | default.timeout | int | 可选 | 1000 | 性能调优 | 远程服务调用超时时间(毫秒) | 1.0.16以上版本 |
+| retries | default.retries | int | 可选 | 2 | 性能调优 | 远程服务调用重试次数，不包括第一次调用，不需要重试请设为0,仅在cluster为failback/failover时有效 | 1.0.16以上版本 |
+| loadbalance | default.loadbalance | string | 可选 | random | 性能调优 | 负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用 | 1.0.16以上版本 |
+| async | default.async | boolean | 可选 | false | 性能调优 | 是否缺省异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程 | 2.0.0以上版本 |
+| connections | default.connections | int | 可选 | 100 | 性能调优 | 每个服务对每个提供者的最大连接数，rmi、http、hessian等短连接协议支持此配置，dubbo协议长连接不支持此配置 | 1.0.16以上版本 |
+| generic | generic | boolean | 可选 | false | 服务治理 | 是否缺省泛化接口，如果为泛化接口，将返回GenericService | 2.0.0以上版本 |
+| check | check | boolean | 可选 | true | 服务治理 | 启动时检查提供者是否存在，true报错，false忽略 | 1.0.16以上版本 |
+| proxy | proxy | string | 可选 | javassist | 性能调优 | 生成动态代理方式，可选：jdk/javassist | 2.0.5以上版本 |
+| owner | owner | string | 可选 | | 服务治理 | 调用服务负责人，用于服务治理，请填写负责人公司邮箱前缀 | 2.0.5以上版本 |
+| actives | default.actives | int | 可选 | 0 | 性能调优 | 每服务消费者每服务每方法最大并发调用数 | 2.0.5以上版本 |
+| cluster | default.cluster | string | 可选 | failover | 性能调优 | 集群方式，可选：failover/failfast/failsafe/failback/forking | 2.0.5以上版本 |
+| filter | reference.filter | string | 可选 | | 性能调优 | 服务消费方远程调用过程拦截器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| listener | invoker.listener | string | 可选 | | 性能调优 | 服务消费方引用服务监听器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| registry | | string | 可选 | 缺省向所有registry注册 | 配置关联 | 向指定注册中心注册，在多个注册中心时使用，值为<dubbo:registry>的id属性，多个注册中心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/A | 2.0.5以上版本 |
+| layer | layer | string | 可选 | | 服务治理 | 服务调用者所在的分层。如：biz、dao、intl:web、china:acton。 | 2.0.7以上版本 |
+| init | init | boolean | 可选 | false | 性能调优 | 是否在afterPropertiesSet()时饥饿初始化引用，否则等到有人注入或引用该实例时再初始化。 | 2.0.10以上版本 |
+| cache | cache | string/boolean | 可选 | | 服务治理 | 以调用参数为key，缓存返回结果，可选：lru, threadlocal, jcache等 | Dubbo2.1.0及其以上版本支持 |
+| validation | validation | boolean | 可选 | | 服务治理 | 是否启用JSR303标准注解验证，如果启用，将对方法参数上的注解进行校验 | Dubbo2.1.0及其以上版本支持 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-method.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-method.md
new file mode 100644
index 0000000..b041d32
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-method.md
@@ -0,0 +1,36 @@
+---
+type: docs
+title: "dubbo:method"
+linkTitle: "dubbo:method"
+weight: 1
+description: "dubbo:method 配置"
+---
+
+方法级配置。对应的配置类： `org.apache.dubbo.config.MethodConfig`。同时该标签为 `<dubbo:service>` 或 `<dubbo:reference>` 的子标签，用于控制到方法级。
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| name | | string | <b>必填</b> | | 标识 | 方法名 | 1.0.8以上版本 |
+| timeout | <methodName>.timeout | int | 可选 | 缺省为的timeout | 性能调优 | 方法调用超时时间(毫秒) | 1.0.8以上版本 |
+| retries | <methodName>.retries | int | 可选 | 缺省为<dubbo:reference>的retries | 性能调优 | 远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 | 2.0.0以上版本 |
+| loadbalance | <methodName>.loadbalance | string | 可选 | 缺省为的loadbalance | 性能调优 | 负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用 | 2.0.0以上版本 |
+| async | <methodName>.async | boolean | 可选 | 缺省为<dubbo:reference>的async | 性能调优 | 是否异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程 | 1.0.9以上版本 |
+| sent | <methodName>.sent | boolean | 可选 | true | 性能调优 | 异步调用时，标记sent=true时，表示网络已发出数据 | 2.0.6以上版本 |
+| actives | <methodName>.actives | int | 可选 | 0 | 性能调优 | 每服务消费者最大并发调用限制 | 2.0.5以上版本 |
+| executes | <methodName>.executes | int | 可选 | 0 | 性能调优 | 每服务每方法最大使用线程数限制- -，此属性只在<dubbo:method>作为<dubbo:service>子标签时有效 | 2.0.5以上版本 |
+| deprecated | <methodName>.deprecated | boolean | 可选 | false | 服务治理 | 服务方法是否过时，此属性只在<dubbo:method>作为<dubbo:service>子标签时有效 | 2.0.5以上版本 |
+| sticky | <methodName>.sticky | boolean | 可选 | false | 服务治理 | 设置true 该接口上的所有方法使用同一个provider.如果需要更复杂的规则，请使用路由 | 2.0.6以上版本 |
+| return | <methodName>.return | boolean | 可选 | true | 性能调优 | 方法调用是否需要返回值,async设置为true时才生效，如果设置为true，则返回future，或回调onreturn等方法，如果设置为false，则请求发送成功后直接返回Null | 2.0.6以上版本 |
+| oninvoke | attribute属性，不在URL中体现 | String | 可选 | | 性能调优 | 方法执行前拦截 | 2.0.6以上版本 |
+| onreturn | attribute属性，不在URL中体现 | String | 可选 | | 性能调优 | 方法执行返回后拦截 | 2.0.6以上版本 |
+| onthrow | attribute属性，不在URL中体现 | String | 可选 | | 性能调优 | 方法执行有异常拦截 | 2.0.6以上版本 |
+| cache | <methodName>.cache | string/boolean | 可选 | | 服务治理 | 以调用参数为key，缓存返回结果，可选：lru, threadlocal, jcache等 | Dubbo2.1.0及其以上版本支持 |
+| validation | <methodName>.validation | boolean | 可选 | | 服务治理 | 是否启用JSR303标准注解验证，如果启用，将对方法参数上的注解进行校验 | Dubbo2.1.0及其以上版本支持 |
+
+比如:
+
+```xml
+<dubbo:reference interface="com.xxx.XxxService">
+ <dubbo:method name="findXxx" timeout="3000" retries="2" />
+</dubbo:reference>
+```
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-module.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-module.md
new file mode 100644
index 0000000..62e169f
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-module.md
@@ -0,0 +1,16 @@
+---
+type: docs
+title: "dubbo:module"
+linkTitle: "dubbo:module"
+weight: 1
+description: "dubbo:module 配置"
+---
+
+模块信息配置。对应的配置类 `org.apache.dubbo.config.ModuleConfig`
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| name | module | string | <b>必填</b> | | 服务治理 | 当前模块名称，用于注册中心计算模块间依赖关系 | 2.2.0以上版本 |
+| version | module.version | string | 可选 | | 服务治理 | 当前模块的版本 | 2.2.0以上版本 |
+| owner | owner | string | 可选 | | 服务治理 | 模块负责人，用于服务治理，请填写负责人公司邮箱前缀 | 2.2.0以上版本 |
+| organization | organization | string | 可选 | | 服务治理 | 组织名称(BU或部门)，用于注册中心区分服务来源，此配置项建议不要使用autoconfig，直接写死在配置中，比如china,intl,itu,crm,asc,dw,aliexpress等 | 2.2.0以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-monitor.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-monitor.md
new file mode 100644
index 0000000..598f4b7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-monitor.md
@@ -0,0 +1,14 @@
+---
+type: docs
+title: "dubbo:monitor"
+linkTitle: "dubbo:monitor"
+weight: 1
+description: "dubbo:monitor 配置"
+---
+
+监控中心配置。对应的配置类： `org.apache.dubbo.config.MonitorConfig`
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| protocol | protocol | string | 可选 | dubbo | 服务治理 | 监控中心协议，如果为protocol="registry"，表示从注册中心发现监控中心地址，否则直连监控中心。 | 2.0.9以上版本 |
+| address | <url> | string | 可选 | N/A | 服务治理 | 直连监控中心服务器地址，address="10.20.130.230:12080" | 1.0.16以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-parameter.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-parameter.md
new file mode 100644
index 0000000..cfb4f1d
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-parameter.md
@@ -0,0 +1,28 @@
+---
+type: docs
+title: "dubbo:parameter"
+linkTitle: "dubbo:parameter"
+weight: 1
+description: "dubbo:parameter 配置"
+---
+
+选项参数配置。对应的配置类：`java.util.Map`。同时该标签为`<dubbo:protocol>`或`<dubbo:service>`或`<dubbo:provider>`或`<dubbo:reference>`或`<dubbo:consumer>`的子标签，用于配置自定义参数，该配置项将作为扩展点设置自定义参数使用。
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| key | key | string | <b>必填</b> | | 服务治理 | 路由参数键 | 2.0.0以上版本 |
+| value | value | string | <b>必填</b> | | 服务治理 | 路由参数值 | 2.0.0以上版本 |
+
+比如：
+
+```xml
+<dubbo:protocol name="napoli">
+ <dubbo:parameter key="http://10.20.160.198/wiki/display/dubbo/napoli.queue.name" value="xxx" />
+</dubbo:protocol>
+```
+
+也可以：
+
+```xml
+<dubbo:protocol name="jms" p:queue="xxx" />
+```
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-protocol.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-protocol.md
new file mode 100644
index 0000000..d176ee7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-protocol.md
@@ -0,0 +1,36 @@
+---
+type: docs
+title: "dubbo:protocol"
+linkTitle: "dubbo:protocol"
+weight: 1
+description: "dubbo:protocol 配置"
+---
+
+服务提供者协议配置。对应的配置类： `org.apache.dubbo.config.ProtocolConfig`。同时，如果需要支持多协议，可以声明多个 `<dubbo:protocol>` 标签，并在 `<dubbo:service>` 中通过 `protocol` 属性指定使用的协议。
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| id | | string | 可选 | dubbo | 配置关联 | 协议BeanId，可以在<dubbo:service protocol="">中引用此ID，如果ID不填，缺省和name属性值一样，重复则在name后加序号。 | 2.0.5以上版本 |
+| name | <protocol> | string | <b>必填</b> | dubbo | 性能调优 | 协议名称 | 2.0.5以上版本 |
+| port | <port> | int | 可选 | dubbo协议缺省端口为20880，rmi协议缺省端口为1099，http和hessian协议缺省端口为80；如果<b>没有</b>配置port，则自动采用默认端口，如果配置为<b>-1</b>，则会分配一个没有被占用的端口。Dubbo 2.4.0+，分配的端口在协议缺省端口的基础上增长，确保端口段可控。 | 服务发现 | 服务端口 | 2.0.5以上版本 |
+| host | <host> | string | 可选 | 自动查找本机IP | 服务发现 | -服务主机名，多网卡选择或指定VIP及域名时使用，为空则自动查找本机IP，-建议不要配置，让Dubbo自动获取本机IP | 2.0.5以上版本 |
+| threadpool | threadpool | string | 可选 | fixed | 性能调优 | 线程池类型，可选：fixed/cached | 2.0.5以上版本 |
+| threads | threads | int | 可选 | 200 | 性能调优 | 服务线程池大小(固定大小) | 2.0.5以上版本 |
+| iothreads | threads | int | 可选 | cpu个数+1 | 性能调优 | io线程池大小(固定大小) | 2.0.5以上版本 |
+| accepts | accepts | int | 可选 | 0 | 性能调优 | 服务提供方最大可接受连接数 | 2.0.5以上版本 |
+| payload | payload | int | 可选 | 8388608(=8M) | 性能调优 | 请求及响应数据包大小限制，单位：字节 | 2.0.5以上版本 |
+| codec | codec | string | 可选 | dubbo | 性能调优 | 协议编码方式 | 2.0.5以上版本 |
+| serialization | serialization | string | 可选 | dubbo协议缺省为hessian2，rmi协议缺省为java，http协议缺省为json | 性能调优 | 协议序列化方式，当协议支持多种序列化方式时使用，比如：dubbo协议的dubbo,hessian2,java,compactedjava，以及http协议的json等 | 2.0.5以上版本 |
+| accesslog | accesslog | string/boolean | 可选 | | 服务治理 | 设为true，将向logger中输出访问日志，也可填写访问日志文件路径，直接把访问日志输出到指定文件 | 2.0.5以上版本 |
+| path | <path> | string | 可选 | | 服务发现 | 提供者上下文路径，为服务path的前缀 | 2.0.5以上版本 |
+| transporter | transporter | string | 可选 | dubbo协议缺省为netty | 性能调优 | 协议的服务端和客户端实现类型，比如：dubbo协议的mina,netty等，可以分拆为server和client配置 | 2.0.5以上版本 |
+| server | server | string | 可选 | dubbo协议缺省为netty，http协议缺省为servlet | 性能调优 | 协议的服务器端实现类型，比如：dubbo协议的mina,netty等，http协议的jetty,servlet等 | 2.0.5以上版本 |
+| client | client | string | 可选 | dubbo协议缺省为netty | 性能调优 | 协议的客户端实现类型，比如：dubbo协议的mina,netty等 | 2.0.5以上版本 |
+| dispatcher | dispatcher | string | 可选 | dubbo协议缺省为all | 性能调优 | 协议的消息派发方式，用于指定线程模型，比如：dubbo协议的all, direct, message, execution, connection等 | 2.1.0以上版本 |
+| queues | queues | int | 可选 | 0 | 性能调优 | 线程池队列大小，当线程池满时，排队等待执行的队列大小，建议不要设置，当线程池满时应立即失败，重试其它服务提供机器，而不是排队，除非有特殊需求。 | 2.0.5以上版本 |
+| charset | charset | string | 可选 | UTF-8 | 性能调优 | 序列化编码 | 2.0.5以上版本 |
+| buffer | buffer | int | 可选 | 8192 | 性能调优 | 网络读写缓冲区大小 | 2.0.5以上版本 |
+| heartbeat | heartbeat | int | 可选 | 0 | 性能调优 | 心跳间隔，对于长连接，当物理层断开时，比如拔网线，TCP的FIN消息来不及发送，对方收不到断开事件，此时需要心跳来帮助检查连接是否已断开 | 2.0.10以上版本 |
+| telnet | telnet | string | 可选 | | 服务治理 | 所支持的telnet命令，多个命令用逗号分隔 | 2.0.5以上版本 |
+| register | register | boolean | 可选 | true | 服务治理 | 该协议的服务是否注册到注册中心 | 2.0.8以上版本 |
+| contextpath | contextpath | String | 可选 | 缺省为空串 | 服务治理 | | 2.0.6以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-provider.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-provider.md
new file mode 100644
index 0000000..3a4a26a
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-provider.md
@@ -0,0 +1,56 @@
+---
+type: docs
+title: "dubbo:provider"
+linkTitle: "dubbo:provider"
+weight: 1
+description: "dubbo:provider 配置"
+---
+
+服务提供者缺省值配置。对应的配置类： `org.apache.dubbo.config.ProviderConfig`。同时该标签为 `<dubbo:service>` 和 `<dubbo:protocol>` 标签的缺省值设置。
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| id | | string | 可选 | dubbo | 配置关联 | 协议BeanId，可以在<dubbo:service proivder="">中引用此ID | 1.0.16以上版本 |
+| protocol | <protocol> | string | 可选 | dubbo | 性能调优 | 协议名称 | 1.0.16以上版本 |
+| host | <host> | string | 可选 | 自动查找本机IP | 服务发现 | 服务主机名，多网卡选择或指定VIP及域名时使用，为空则自动查找本机IP，建议不要配置，让Dubbo自动获取本机IP | 1.0.16以上版本 |
+| threads | threads | int | 可选 | 200 | 性能调优 | 服务线程池大小(固定大小) | 1.0.16以上版本 |
+| payload | payload | int | 可选 | 8388608(=8M) | 性能调优 | 请求及响应数据包大小限制，单位：字节 | 2.0.0以上版本 |
+| path | <path> | string | 可选 | | 服务发现 | 提供者上下文路径，为服务path的前缀 | 2.0.0以上版本 |
+| server | server | string | 可选 | dubbo协议缺省为netty，http协议缺省为servlet | 性能调优 | 协议的服务器端实现类型，比如：dubbo协议的mina,netty等，http协议的jetty,servlet等 | 2.0.0以上版本 |
+| client | client | string | 可选 | dubbo协议缺省为netty | 性能调优 | 协议的客户端实现类型，比如：dubbo协议的mina,netty等 | 2.0.0以上版本 |
+| codec | codec | string | 可选 | dubbo | 性能调优 | 协议编码方式 | 2.0.0以上版本 |
+| serialization | serialization | string | 可选 | dubbo协议缺省为hessian2，rmi协议缺省为java，http协议缺省为json | 性能调优 | 协议序列化方式，当协议支持多种序列化方式时使用，比如：dubbo协议的dubbo,hessian2,java,compactedjava，以及http协议的json,xml等 | 2.0.5以上版本 |
+| default | | boolean | 可选 | false | 配置关联 | 是否为缺省协议，用于多协议 | 1.0.16以上版本 |
+| filter | service.filter | string | 可选 | | 性能调优 | 服务提供方远程调用过程拦截器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| listener | exporter.listener | string | 可选 | | 性能调优 | 服务提供方导出服务监听器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| threadpool | threadpool | string | 可选 | fixed | 性能调优 | 线程池类型，可选：fixed/cached/limit(2.5.3以上)/eager(2.6.x以上) | 2.0.5以上版本 |
+| accepts | accepts | int | 可选 | 0 | 性能调优 | 服务提供者最大可接受连接数 | 2.0.5以上版本 |
+| version | version | string | 可选 | 0.0.0 | 服务发现 | 服务版本，建议使用两位数字版本，如：1.0，通常在接口不兼容时版本号才需要升级 | 2.0.5以上版本 |
+| group | group | string | 可选 | | 服务发现 | 服务分组，当一个接口有多个实现，可以用分组区分 | 2.0.5以上版本 |
+| delay | delay | int | 可选 | 0 | 性能调优 | 延迟注册服务时间(毫秒)- ，设为-1时，表示延迟到Spring容器初始化完成时暴露服务 | 2.0.5以上版本 |
+| timeout | default.timeout | int | 可选 | 1000 | 性能调优 | 远程服务调用超时时间(毫秒) | 2.0.5以上版本 |
+| retries | default.retries | int | 可选 | 2 | 性能调优 | 远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 | 2.0.5以上版本 |
+| connections | default.connections | int | 可选 | 0 | 性能调优 | 对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数 | 2.0.5以上版本 |
+| loadbalance | default.loadbalance | string | 可选 | random | 性能调优 | 负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用 | 2.0.5以上版本 |
+| async | default.async | boolean | 可选 | false | 性能调优 | 是否缺省异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程 | 2.0.5以上版本 |
+| stub | stub | boolean | 可选 | false | 服务治理 | 设为true，表示使用缺省代理类名，即：接口名 + Local后缀。 | 2.0.5以上版本 |
+| mock | mock | boolean | 可选 | false | 服务治理 | 设为true，表示使用缺省Mock类名，即：接口名 + Mock后缀。 | 2.0.5以上版本 |
+| token | token | boolean | 可选 | false | 服务治理 | 令牌验证，为空表示不开启，如果为true，表示随机生成动态令牌 | 2.0.5以上版本 |
+| registry | registry | string | 可选 | 缺省向所有registry注册 | 配置关联 | 向指定注册中心注册，在多个注册中心时使用，值为<dubbo:registry>的id属性，多个注册中心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/A | 2.0.5以上版本 |
+| dynamic | dynamic | boolean | 可选 | true | 服务治理 | 服务是否动态注册，如果设为false，注册后将显示后disable状态，需人工启用，并且服务提供者停止时，也不会自动取消册，需人工禁用。 | 2.0.5以上版本 |
+| accesslog | accesslog | string/boolean | 可选 | false | 服务治理 | 设为true，将向logger中输出访问日志，也可填写访问日志文件路径，直接把访问日志输出到指定文件 | 2.0.5以上版本 |
+| owner | owner | string | 可选 | | 服务治理 | 服务负责人，用于服务治理，请填写负责人公司邮箱前缀 | 2.0.5以上版本 |
+| document | document | string | 可选 | | 服务治理 | 服务文档URL | 2.0.5以上版本 |
+| weight | weight | int | 可选 | | 性能调优 | 服务权重 | 2.0.5以上版本 |
+| executes | executes | int | 可选 | 0 | 性能调优 | 服务提供者每服务每方法最大可并行执行请求数 | 2.0.5以上版本 |
+| actives | default.actives | int | 可选 | 0 | 性能调优 | 每服务消费者每服务每方法最大并发调用数 | 2.0.5以上版本 |
+| proxy | proxy | string | 可选 | javassist | 性能调优 | 生成动态代理方式，可选：jdk/javassist | 2.0.5以上版本 |
+| cluster | default.cluster | string | 可选 | failover | 性能调优 | 集群方式，可选：failover/failfast/failsafe/failback/forking | 2.0.5以上版本 |
+| deprecated | deprecated | boolean | 可选 | false | 服务治理 | 服务是否过时，如果设为true，消费方引用时将打印服务过时警告error日志 | 2.0.5以上版本 |
+| queues | queues | int | 可选 | 0 | 性能调优 | 线程池队列大小，当线程池满时，排队等待执行的队列大小，建议不要设置，当线程池满时应立即失败，重试其它服务提供机器，而不是排队，除非有特殊需求。 | 2.0.5以上版本 |
+| charset | charset | string | 可选 | UTF-8 | 性能调优 | 序列化编码 | 2.0.5以上版本 |
+| buffer | buffer | int | 可选 | 8192 | 性能调优 | 网络读写缓冲区大小 | 2.0.5以上版本 |
+| iothreads | iothreads | int | 可选 | CPU + 1 | 性能调优 | IO线程池，接收网络读写中断，以及序列化和反序列化，不处理业务，业务线程池参见threads配置，此线程池和CPU相关，不建议配置。 | 2.0.5以上版本 |
+| telnet | telnet | string | 可选 | | 服务治理 | 所支持的telnet命令，多个命令用逗号分隔 | 2.0.5以上版本 |
+| <dubbo:service> | contextpath | contextpath | String | 可选 | 缺省为空串 | 服务治理 | | 2.0.6以上版本 |
+| layer | layer | string | 可选 | | 服务治理 | 服务提供者所在的分层。如：biz、dao、intl:web、china:acton。 | 2.0.7以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-reference.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-reference.md
new file mode 100644
index 0000000..e163b4e
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-reference.md
@@ -0,0 +1,40 @@
+---
+type: docs
+title: "dubbo:reference"
+linkTitle: "dubbo:reference"
+weight: 1
+description: "dubbo:reference 配置"
+---
+
+
+服务消费者引用服务配置。对应的配置类： `org.apache.dubbo.config.ReferenceConfig`
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| id | | string | <b>必填</b> | | 配置关联 | 服务引用BeanId | 1.0.0以上版本 |
+| interface | | class | <b>必填</b> | | 服务发现 | 服务接口名 | 1.0.0以上版本 |
+| version | version | string | 可选 | | 服务发现 | 服务版本，与服务提供者的版本一致 | 1.0.0以上版本 |
+| group | group | string | 可选 | | 服务发现 | 服务分组，当一个接口有多个实现，可以用分组区分，必需和服务提供方一致 | 1.0.7以上版本 |
+| timeout | timeout | long | 可选 | 缺省使用<dubbo:consumer>的timeout | 性能调优 | 服务方法调用超时时间(毫秒) | 1.0.5以上版本 |
+| retries | retries | int | 可选 | 缺省使用<dubbo:consumer>的retries | 性能调优 | 远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 | 2.0.0以上版本 |
+| connections | connections | int | 可选 | 缺省使用<dubbo:consumer>的connections | 性能调优 | 对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数 | 2.0.0以上版本 |
+| loadbalance | loadbalance | string | 可选 | 缺省使用<dubbo:consumer>的loadbalance | 性能调优 | 负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用 | 2.0.0以上版本 |
+| async | async | boolean | 可选 | 缺省使用<dubbo:consumer>的async | 性能调优 | 是否异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程 | 2.0.0以上版本 |
+| generic | generic | boolean | 可选 | 缺省使用<dubbo:consumer>的generic | 服务治理 | 是否缺省泛化接口，如果为泛化接口，将返回GenericService | 2.0.0以上版本 |
+| check | check | boolean | 可选 | 缺省使用<dubbo:consumer>的check | 服务治理 | 启动时检查提供者是否存在，true报错，false忽略 | 2.0.0以上版本 |
+| url | url | string | 可选 | | 服务治理 | 点对点直连服务提供者地址，将绕过注册中心 | 1.0.6以上版本 |
+| stub | stub | class/boolean | 可选 | | 服务治理 | 服务接口客户端本地代理类名，用于在客户端执行本地逻辑，如本地缓存等，该本地代理类的构造函数必须允许传入远程代理对象，构造函数如：public XxxServiceLocal(XxxService xxxService) | 2.0.0以上版本 |
+| mock | mock | class/boolean | 可选 | | 服务治理 | 服务接口调用失败Mock实现类名，该Mock类必须有一个无参构造函数，与Local的区别在于，Local总是被执行，而Mock只在出现非业务异常(比如超时，网络异常等)时执行，Local在远程调用之前执行，Mock在远程调用后执行。 | Dubbo1.0.13及其以上版本支持 |
+| cache | cache | string/boolean | 可选 | | 服务治理 | 以调用参数为key，缓存返回结果，可选：lru, threadlocal, jcache等 | Dubbo2.1.0及其以上版本支持 |
+| validation | validation | boolean | 可选 | | 服务治理 | 是否启用JSR303标准注解验证，如果启用，将对方法参数上的注解进行校验 | Dubbo2.1.0及其以上版本支持 |
+| proxy | proxy | boolean | 可选 | javassist | 性能调优 | 选择动态代理实现策略，可选：javassist, jdk | 2.0.2以上版本 |
+| client | client | string | 可选 | | 性能调优 | 客户端传输类型设置，如Dubbo协议的netty或mina。 | Dubbo2.0.0以上版本支持 |
+| registry | | string | 可选 | 缺省将从所有注册中心获服务列表后合并结果 | 配置关联 | 从指定注册中心注册获取服务列表，在多个注册中心时使用，值为<dubbo:registry>的id属性，多个注册中心ID用逗号分隔 | 2.0.0以上版本 |
+| owner | owner | string | 可选 | | 服务治理 | 调用服务负责人，用于服务治理，请填写负责人公司邮箱前缀 | 2.0.5以上版本 |
+| actives | actives | int | 可选 | 0 | 性能调优 | 每服务消费者每服务每方法最大并发调用数 | 2.0.5以上版本 |
+| cluster | cluster | string | 可选 | failover | 性能调优 | 集群方式，可选：failover/failfast/failsafe/failback/forking | 2.0.5以上版本 |
+| filter | reference.filter | string | 可选 | default | 性能调优 | 服务消费方远程调用过程拦截器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| listener | invoker.listener | string | 可选 | default | 性能调优 | 服务消费方引用服务监听器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| layer | layer | string | 可选 | | 服务治理 | 服务调用者所在的分层。如：biz、dao、intl:web、china:acton。 | 2.0.7以上版本 |
+| init | init | boolean | 可选 | false | 性能调优 | 是否在afterPropertiesSet()时饥饿初始化引用，否则等到有人注入或引用该实例时再初始化。 | 2.0.10以上版本 |
+| protocol | protocol | string | 可选 | | 服务治理 | 只调用指定协议的服务提供方，其它协议忽略。 | 2.2.0以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-registry.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-registry.md
new file mode 100644
index 0000000..086c65a
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-registry.md
@@ -0,0 +1,30 @@
+---
+type: docs
+title: "dubbo:registry"
+linkTitle: "dubbo:registry"
+weight: 1
+description: "dubbo:registry 配置"
+---
+
+注册中心配置。对应的配置类： `org.apache.dubbo.config.RegistryConfig`。同时如果有多个不同的注册中心，可以声明多个 `<dubbo:registry>` 标签，并在 `<dubbo:service>` 或 `<dubbo:reference>` 的 `registry` 属性指定使用的注册中心。
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| id | | string | 可选 | | 配置关联 | 注册中心引用BeanId，可以在<dubbo:service registry="">或<dubbo:reference registry="">中引用此ID | 1.0.16以上版本 |
+| address | <host:port> | string | <b>必填</b> | | 服务发现 | 注册中心服务器地址，如果地址没有端口缺省为9090，同一集群内的多个地址用逗号分隔，如：ip:port,ip:port，不同集群的注册中心，请配置多个<dubbo:registry>标签 | 1.0.16以上版本 |
+| protocol | <protocol> | string | 可选 | dubbo | 服务发现 | 注册中心地址协议，支持`dubbo`, `multicast`, `zookeeper`, `redis`, `consul(2.7.1)`, `sofa(2.7.2)`, `etcd(2.7.2)`, `nacos(2.7.2)`等协议 | 2.0.0以上版本 |
+| port | <port> | int | 可选 | 9090 | 服务发现 | 注册中心缺省端口，当address没有带端口时使用此端口做为缺省值 | 2.0.0以上版本 |
+| username | <username> | string | 可选 | | 服务治理 | 登录注册中心用户名，如果注册中心不需要验证可不填 | 2.0.0以上版本 |
+| password | <password> | string | 可选 | | 服务治理 | 登录注册中心密码，如果注册中心不需要验证可不填 | 2.0.0以上版本 |
+| transport | registry.transporter | string | 可选 | netty | 性能调优 | 网络传输方式，可选mina,netty | 2.0.0以上版本 |
+| timeout | registry.timeout | int | 可选 | 5000 | 性能调优 | 注册中心请求超时时间(毫秒) | 2.0.0以上版本 |
+| session | registry.session | int | 可选 | 60000 | 性能调优 | 注册中心会话超时时间(毫秒)，用于检测提供者非正常断线后的脏数据，比如用心跳检测的实现，此时间就是心跳间隔，不同注册中心实现不一样。 | 2.1.0以上版本 |
+| file | registry.file | string | 可选 | | 服务治理 | 使用文件缓存注册中心地址列表及服务提供者列表，应用重启时将基于此文件恢复，注意：两个注册中心不能使用同一文件存储 | 2.0.0以上版本 |
+| wait | registry.wait | int | 可选 | 0 | 性能调优 | 停止时等待通知完成时间(毫秒) | 2.0.0以上版本 |
+| check | check | boolean | 可选 | true | 服务治理 | 注册中心不存在时，是否报错 | 2.0.0以上版本 |
+| register | register | boolean | 可选 | true | 服务治理 | 是否向此注册中心注册服务，如果设为false，将只订阅，不注册 | 2.0.5以上版本 |
+| subscribe | subscribe | boolean | 可选 | true | 服务治理 | 是否向此注册中心订阅服务，如果设为false，将只注册，不订阅 | 2.0.5以上版本 |
+| dynamic | dynamic | boolean | 可选 | true | 服务治理 | 服务是否动态注册，如果设为false，注册后将显示为disable状态，需人工启用，并且服务提供者停止时，也不会自动取消注册，需人工禁用。 | 2.0.5以上版本 |
+| group | group | string | 可选 | dubbo | 服务治理 | 服务注册分组，跨组的服务不会相互影响，也无法相互调用，适用于环境隔离。 | 2.0.5以上版本 |
+| simplified | simplified | boolean | 可选 | false | 服务治理 | 注册到注册中心的URL是否采用精简模式的（与低版本兼容） | 2.7.0以上版本 |
+| extra-keys | extraKeys | string | 可选 | | 服务治理 | 在simplified=true时，extraKeys允许你在默认参数外将额外的key放到URL中，格式："interface,key1,key2"。 | 2.7.0以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-service.md b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-service.md
new file mode 100644
index 0000000..cd5a0b4
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/references/xml/dubbo-service.md
@@ -0,0 +1,43 @@
+---
+type: docs
+title: "dubbo:service"
+linkTitle: "dubbo:service"
+weight: 1
+description: "dubbo:service 配置"
+---
+
+服务提供者暴露服务配置。对应的配置类：`org.apache.dubbo.config.ServiceConfig`
+
+| 属性 | 对应URL参数 | 类型 | 是否必填 | 缺省值 | 作用 | 描述 | 兼容性 |
+| --- | --- | ---- | --- | --- | --- | --- | --- |
+| interface | | class | <b>必填</b> | | 服务发现 | 服务接口名 | 1.0.0以上版本 |
+| ref | | object | <b>必填</b> | | 服务发现 | 服务对象实现引用 | 1.0.0以上版本 |
+| version | version | string | 可选 | 0.0.0 | 服务发现 | 服务版本，建议使用两位数字版本，如：1.0，通常在接口不兼容时版本号才需要升级 | 1.0.0以上版本 |
+| group | group | string | 可选 | | 服务发现 | 服务分组，当一个接口有多个实现，可以用分组区分 | 1.0.7以上版本 |
+| path | <path> | string | 可选 | 缺省为接口名 | 服务发现 | 服务路径 (注意：1.0不支持自定义路径，总是使用接口名，如果有1.0调2.0，配置服务路径可能不兼容) | 1.0.12以上版本 |
+| delay | delay | int | 可选 | 0 | 性能调优 | 延迟注册服务时间(毫秒) ，设为-1时，表示延迟到Spring容器初始化完成时暴露服务 | 1.0.14以上版本 |
+| timeout | timeout | int | 可选 | 1000 | 性能调优 | 远程服务调用超时时间(毫秒) | 2.0.0以上版本 |
+| retries | retries | int | 可选 | 2 | 性能调优 | 远程服务调用重试次数，不包括第一次调用，不需要重试请设为0 | 2.0.0以上版本 |
+| connections | connections | int | 可选 | 100 | 性能调优 | 对每个提供者的最大连接数，rmi、http、hessian等短连接协议表示限制连接数，dubbo等长连接协表示建立的长连接个数 | 2.0.0以上版本 |
+| loadbalance | loadbalance | string | 可选 | random | 性能调优 | 负载均衡策略，可选值：random,roundrobin,leastactive，分别表示：随机，轮询，最少活跃调用 | 2.0.0以上版本 |
+| async | async | boolean | 可选 | false | 性能调优 | 是否缺省异步执行，不可靠异步，只是忽略返回值，不阻塞执行线程 | 2.0.0以上版本 |
+| local | local | class/boolean | 可选 | false | 服务治理 | 设为true，表示使用缺省代理类名，即：接口名 + Local后缀，已废弃，请使用stub| 2.0.0以上版本 |
+| stub | stub | class/boolean | 可选 | false | 服务治理 | 设为true，表示使用缺省代理类名，即：接口名 + Stub后缀，服务接口客户端本地代理类名，用于在客户端执行本地逻辑，如本地缓存等，该本地代理类的构造函数必须允许传入远程代理对象，构造函数如：public XxxServiceStub(XxxService xxxService) | 2.0.0以上版本 |
+| mock | mock | class/boolean | 可选 | false | 服务治理 | 设为true，表示使用缺省Mock类名，即：接口名 + Mock后缀，服务接口调用失败Mock实现类，该Mock类必须有一个无参构造函数，与Local的区别在于，Local总是被执行，而Mock只在出现非业务异常(比如超时，网络异常等)时执行，Local在远程调用之前执行，Mock在远程调用后执行。 | 2.0.0以上版本 |
+| token | token | string/boolean | 可选 | false | 服务治理 | 令牌验证，为空表示不开启，如果为true，表示随机生成动态令牌，否则使用静态令牌，令牌的作用是防止消费者绕过注册中心直接访问，保证注册中心的授权功能有效，如果使用点对点调用，需关闭令牌功能 | 2.0.0以上版本 |
+| registry | | string | 可选 | 缺省向所有registry注册 | 配置关联 | 向指定注册中心注册，在多个注册中心时使用，值为<dubbo:registry>的id属性，多个注册中心ID用逗号分隔，如果不想将该服务注册到任何registry，可将值设为N/A | 2.0.0以上版本 |
+| provider | | string | 可选 | 缺省使用第一个provider配置 | 配置关联 | 指定provider，值为<dubbo:provider>的id属性 | 2.0.0以上版本 |
+| deprecated | deprecated | boolean | 可选 | false | 服务治理 | 服务是否过时，如果设为true，消费方引用时将打印服务过时警告error日志 | 2.0.5以上版本 |
+| dynamic | dynamic | boolean | 可选 | true | 服务治理 | 服务是否动态注册，如果设为false，注册后将显示后disable状态，需人工启用，并且服务提供者停止时，也不会自动取消册，需人工禁用。 | 2.0.5以上版本 |
+| accesslog | accesslog | string/boolean | 可选 | false | 服务治理 | 设为true，将向logger中输出访问日志，也可填写访问日志文件路径，直接把访问日志输出到指定文件 | 2.0.5以上版本 |
+| owner | owner | string | 可选 | | 服务治理 | 服务负责人，用于服务治理，请填写负责人公司邮箱前缀 | 2.0.5以上版本 |
+| document | document | string | 可选 | | 服务治理 | 服务文档URL | 2.0.5以上版本 |
+| weight | weight | int | 可选 | | 性能调优 | 服务权重 | 2.0.5以上版本 |
+| executes | executes | int | 可选 | 0 | 性能调优 | 服务提供者每服务每方法最大可并行执行请求数 | 2.0.5以上版本 | | actives | actives | int | 可选 | 0 | 性能调优 | 每服务消费者每服务每方法最大并发调用数 | 2.0.5以上版本 |
+| proxy | proxy | string | 可选 | javassist | 性能调优 | 生成动态代理方式，可选：jdk/javassist | 2.0.5以上版本 |
+| cluster | cluster | string | 可选 | failover | 性能调优 | 集群方式，可选：failover/failfast/failsafe/failback/forking | 2.0.5以上版本 |
+| filter | service.filter | string | 可选 | default | 性能调优 | 服务提供方远程调用过程拦截器名称，多个名称用逗号分隔 | 2.0.5以上版本 |
+| listener | exporter.listener | string | 可选 | default | 性能调优 | 服务提供方导出服务监听器名称，多个名称用逗号分隔 | |
+| protocol | | string | 可选 | | 配置关联 | 使用指定的协议暴露服务，在多协议时使用，值为<dubbo:protocol>的id属性，多个协议ID用逗号分隔 | 2.0.5以上版本 |
+| layer | layer | string | 可选 | | 服务治理 | 服务提供者所在的分层。如：biz、dao、intl:web、china:acton。 | 2.0.7以上版本 |
+| register | register | boolean | 可选 | true | 服务治理 | 该协议的服务是否注册到注册中心 | 2.0.8以上版本 |
diff --git a/content/zh/docs/v3.0/references/configuration/xml.md b/content/zh/docs/v3.0/references/configuration/xml.md
new file mode 100644
index 0000000..e2bbbe8
--- /dev/null
+++ b/content/zh/docs/v3.0/references/configuration/xml.md
@@ -0,0 +1,98 @@
+---
+type: docs
+title: "XML 配置"
+linkTitle: "XML 配置"
+weight: 1
+description: "以 XML 配置的方式来配置你的 Dubbo 应用"
+---
+
+有关 XML 的详细配置项，请参见：[配置参考手册](../../references/xml)。如果不想使用 Spring 配置，而希望通过 API 的方式进行调用，请参见：[API配置](../api)。想知道如何使用配置，请参见：[快速启动](../../quick-start)。
+
+请在此查看文档描述的[完整示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-basic)
+
+## provider.xml 示例
+
+```xml
+<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
+ xmlns="http://www.springframework.org/schema/beans"
+ xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
+ http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
+ <dubbo:application name="demo-provider"/>
+ <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
+ <dubbo:protocol name="dubbo" port="20890"/>
+ <bean id="demoService" class="org.apache.dubbo.samples.basic.impl.DemoServiceImpl"/>
+ <dubbo:service interface="org.apache.dubbo.samples.basic.api.DemoService" ref="demoService"/>
+</beans>
+```
+
+## consumer.xml示例
+
+```xml
+<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
+ xmlns="http://www.springframework.org/schema/beans"
+ xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
+ http://dubbo.apache.org/schema/dubbo http://dubbo.apache.org/schema/dubbo/dubbo.xsd">
+ <dubbo:application name="demo-consumer"/>
+ <dubbo:registry group="aaa" address="zookeeper://127.0.0.1:2181"/>
+ <dubbo:reference id="demoService" check="false" interface="org.apache.dubbo.samples.basic.api.DemoService"/>
+</beans>
+```
+
+所有标签都支持自定义参数，用于不同扩展点实现的特殊配置，如：
+
+```xml
+<dubbo:protocol name="jms">
+ <dubbo:parameter key="queue" value="your_queue" />
+</dubbo:protocol>
+```
+
+或： [^1]
+
+```xml
+<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"
+ xmlns:p="http://www.springframework.org/schema/p"
+ 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:protocol name="jms" p:queue="your_queue" />
+</beans>
+```
+
+## 配置之间的关系
+
+
+
+标签 | 用途 | 解释
+------------- | ------------- | -------------
+`<dubbo:service/>` | 服务配置 | 用于暴露一个服务，定义服务的元信息，一个服务可以用多个协议暴露，一个服务也可以注册到多个注册中心
+`<dubbo:reference/>` [^2] | 引用配置 | 用于创建一个远程服务代理，一个引用可以指向多个注册中心
+`<dubbo:protocol/>` | 协议配置 | 用于配置提供服务的协议信息，协议由提供方指定，消费方被动接受
+`<dubbo:application/>` | 应用配置 | 用于配置当前应用信息，不管该应用是提供者还是消费者
+`<dubbo:module/>` | 模块配置 | 用于配置当前模块信息，可选
+`<dubbo:registry/>` | 注册中心配置 | 用于配置连接注册中心相关信息
+`<dubbo:monitor/>` | 监控中心配置 | 用于配置连接监控中心相关信息，可选
+`<dubbo:provider/>` | 提供方配置 | 当 ProtocolConfig 和 ServiceConfig 某属性没有配置时，采用此缺省值，可选
+`<dubbo:consumer/>` | 消费方配置 | 当 ReferenceConfig 某属性没有配置时，采用此缺省值，可选
+`<dubbo:method/>` | 方法配置 | 用于 ServiceConfig 和 ReferenceConfig 指定方法级的配置信息
+`<dubbo:argument/>` | 参数配置 | 用于指定方法参数配置
+
+
+## 不同粒度配置的覆盖关系
+
+以 timeout 为例，下图显示了配置的查找顺序，其它 retries, loadbalance, actives 等类似：
+
+* 方法级优先，接口级次之，全局配置再次之。
+* 如果级别一样，则消费方优先，提供方次之。
+
+其中，服务提供方配置，通过 URL 经由注册中心传递给消费方。
+
+
+
+（建议由服务提供方设置超时，因为一个方法需要执行多长时间，服务提供方更清楚，如果一个消费方同时引用多个服务，就不需要关心每个服务的超时设置）。
+
+理论上 ReferenceConfig 中除了`interface`这一项，其他所有配置项都可以缺省不配置，框架会自动使用ConsumerConfig，ServiceConfig, ProviderConfig等提供的缺省配置。
+
+[^1]: `2.1.0` 开始支持，注意声明：`xmlns:p="http://www.springframework.org/schema/p"`
+[^2]: 引用缺省是延迟初始化的，只有引用被注入到其它 Bean，或被 `getBean()` 获取，才会初始化。如果需要饥饿加载，即没有人引用也立即生成动态代理，可以配置：`<dubbo:reference ... init="true" />`
diff --git a/content/zh/docs/v3.0/references/features/_index.md b/content/zh/docs/v3.0/references/features/_index.md
new file mode 100644
index 0000000..4d8c77a
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/_index.md
@@ -0,0 +1,12 @@
+---
+type: docs
+title: "功能列表与用法示例"
+linkTitle: "功能列表"
+weight: 6
+description: "通过示例学习 Dubbo 的用法"
+---
+
+{{% alert title="Tips" color="primary" %}}
+想完整的运行起来，请参见：[快速启动](../quick-start)，这里只列出各种场景的配置方式。
+以下示例全部使用基于 Spring 的 [Xml配置](../configuration/xml)作为参考，如果不想使用 Spring，而希望通过 API 的方式进行调用，请参见：[API配置](../configuration/api)
+{{% /alert %}}
diff --git a/content/zh/docs/v3.0/references/features/accesslog.md b/content/zh/docs/v3.0/references/features/accesslog.md
new file mode 100644
index 0000000..75e75cf
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/accesslog.md
@@ -0,0 +1,21 @@
+---
+type: docs
+title: "访问日志"
+linkTitle: "访问日志"
+weight: 39
+description: "配置 Dubbo 的访问日志"
+---
+
+如果你想记录每一次请求信息，可开启访问日志，类似于apache的访问日志。**注意**：此日志量比较大，请注意磁盘容量。
+
+将访问日志输出到当前应用的log4j日志：
+
+```xml
+<dubbo:protocol accesslog="true" />
+```
+
+将访问日志输出到指定文件：
+
+```xml
+<dubbo:protocol accesslog="http://10.20.160.198/wiki/display/dubbo/foo/bar.log" />
+```
diff --git a/content/zh/docs/v3.0/references/features/async-call.md b/content/zh/docs/v3.0/references/features/async-call.md
new file mode 100644
index 0000000..ad5b120
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/async-call.md
@@ -0,0 +1,139 @@
+---
+type: docs
+title: "异步调用"
+linkTitle: "异步调用"
+weight: 21
+description: "在 Dubbo 中发起异步调用"
+---
+
+
+从 2.7.0 开始，Dubbo 的所有异步编程接口开始以 [CompletableFuture](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/CompletableFuture.html) 为基础
+
+基于 NIO 的非阻塞实现并行调用，客户端不需要启动多线程即可完成并行调用多个远程服务，相对多线程开销较小。
+
+
+
+
+## 使用 CompletableFuture 签名的接口
+
+需要服务提供者事先定义 CompletableFuture 签名的服务，具体参见[服务端异步执行]({{<ref "/docs/v2.7/user/examples/async-execute-on-provider.md" >}} "")接口定义：
+
+```java
+public interface AsyncService {
+ CompletableFuture<String> sayHello(String name);
+}
+```
+
+注意接口的返回类型是 `CompletableFuture<String>`。
+
+XML引用服务：
+
+```xml
+<dubbo:reference id="asyncService" timeout="10000" interface="com.alibaba.dubbo.samples.async.api.AsyncService"/>
+```
+
+调用远程服务：
+
+```java
+// 调用直接返回CompletableFuture
+CompletableFuture<String> future = asyncService.sayHello("async call request");
+// 增加回调
+future.whenComplete((v, t) -> {
+ if (t != null) {
+ t.printStackTrace();
+ } else {
+ System.out.println("Response: " + v);
+ }
+});
+// 早于结果输出
+System.out.println("Executed before response return.");
+```
+
+## 使用 RpcContext
+
+在 consumer.xml 中配置：
+
+```xml
+<dubbo:reference id="asyncService" interface="org.apache.dubbo.samples.governance.api.AsyncService">
+ <dubbo:method name="sayHello" async="true" />
+</dubbo:reference>
+```
+
+调用代码:
+
+```java
+// 此调用会立即返回null
+asyncService.sayHello("world");
+// 拿到调用的Future引用，当结果返回后，会被通知和设置到此Future
+CompletableFuture<String> helloFuture = RpcContext.getContext().getCompletableFuture();
+// 为Future添加回调
+helloFuture.whenComplete((retValue, exception) -> {
+ if (exception == null) {
+ System.out.println(retValue);
+ } else {
+ exception.printStackTrace();
+ }
+});
+```
+
+或者，你也可以这样做异步调用:
+
+```java
+CompletableFuture<String> future = RpcContext.getContext().asyncCall(
+ () -> {
+ asyncService.sayHello("oneway call request1");
+ }
+);
+
+future.get();
+```
+
+
+
+## 重载服务接口
+
+如果你只有这样的同步服务定义，而又不喜欢 RpcContext 的异步使用方式。
+
+```java
+public interface GreetingsService {
+ String sayHi(String name);
+}
+```
+
+那还有一种方式，就是利用 Java 8 提供的 default 接口实现，重载一个带有 CompletableFuture 签名的方法。
+
+有两种方式来实现：
+
+1. 提供方或消费方自己修改接口签名
+
+```java
+public interface GreetingsService {
+ String sayHi(String name);
+
+ // AsyncSignal is totally optional, you can use any parameter type as long as java allows your to do that.
+ default CompletableFuture<String> sayHi(String name, AsyncSignal signal) {
+ return CompletableFuture.completedFuture(sayHi(name));
+ }
+}
+```
+
+1. Dubbo 官方提供 compiler hacker，编译期自动重写同步方法，请[在此](https://github.com/dubbo/dubbo-async-processor#compiler-hacker-processer)讨论和跟进具体进展。
+
+
+
+你也可以设置是否等待消息发出： [^1]
+
+- `sent="true"` 等待消息发出，消息发送失败将抛出异常。
+- `sent="false"` 不等待消息发出，将消息放入 IO 队列，即刻返回。
+
+```xml
+<dubbo:method name="findFoo" async="true" sent="true" />
+```
+
+如果你只是想异步，完全忽略返回值，可以配置 `return="false"`，以减少 Future 对象的创建和管理成本：
+
+```xml
+<dubbo:method name="findFoo" async="true" return="false" />
+```
+
+[^1]: 异步总是不等待返回
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/async-execute-on-provider.md b/content/zh/docs/v3.0/references/features/async-execute-on-provider.md
new file mode 100644
index 0000000..c62181f
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/async-execute-on-provider.md
@@ -0,0 +1,102 @@
+---
+type: docs
+title: "异步执行"
+linkTitle: "异步执行"
+weight: 21
+description: "Dubbo 服务提供方的异步执行"
+---
+
+
+Provider端异步执行将阻塞的业务从Dubbo内部线程池切换到业务自定义线程，避免Dubbo线程池的过度占用，有助于避免不同服务间的互相影响。异步执行无益于节省资源或提升RPC响应性能，因为如果业务执行需要阻塞，则始终还是要有线程来负责执行。
+
+{{% alert title="注意" color="warning" %}}
+Provider 端异步执行和 Consumer 端异步调用是相互独立的，你可以任意正交组合两端配置
+- Consumer同步 - Provider同步
+- Consumer异步 - Provider同步
+- Consumer同步 - Provider异步
+- Consumer异步 - Provider异步
+{{% /alert %}}
+
+
+## 定义 CompletableFuture 签名的接口
+
+服务接口定义：
+
+```java
+public interface AsyncService {
+ CompletableFuture<String> sayHello(String name);
+}
+```
+
+服务实现：
+
+```java
+public class AsyncServiceImpl implements AsyncService {
+ @Override
+ public CompletableFuture<String> sayHello(String name) {
+ RpcContext savedContext = RpcContext.getContext();
+ // 建议为supplyAsync提供自定义线程池，避免使用JDK公用线程池
+ return CompletableFuture.supplyAsync(() -> {
+ System.out.println(savedContext.getAttachment("consumer-key1"));
+ try {
+ Thread.sleep(5000);
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ return "async response from provider.";
+ });
+ }
+}
+```
+
+通过 `return CompletableFuture.supplyAsync() `，业务执行已从 Dubbo 线程切换到业务线程，避免了对 Dubbo 线程池的阻塞。
+
+
+
+## 使用AsyncContext
+
+Dubbo 提供了一个类似 Serverlet 3.0 的异步接口`AsyncContext`，在没有 CompletableFuture 签名接口的情况下，也可以实现 Provider 端的异步执行。
+
+服务接口定义：
+
+```java
+public interface AsyncService {
+ String sayHello(String name);
+}
+```
+
+服务暴露，和普通服务完全一致：
+
+```xml
+<bean id="asyncService" class="org.apache.dubbo.samples.governance.impl.AsyncServiceImpl"/>
+<dubbo:service interface="org.apache.dubbo.samples.governance.api.AsyncService" ref="asyncService"/>
+```
+
+服务实现：
+
+```java
+public class AsyncServiceImpl implements AsyncService {
+ public String sayHello(String name) {
+ final AsyncContext asyncContext = RpcContext.startAsync();
+ new Thread(() -> {
+ // 如果要使用上下文，则必须要放在第一句执行
+ asyncContext.signalContextSwitch();
+ try {
+ Thread.sleep(500);
+ } catch (InterruptedException e) {
+ e.printStackTrace();
+ }
+ // 写回响应
+ asyncContext.write("Hello " + name + ", response from provider.");
+ }).start();
+ return null;
+ }
+}
+```
+
+
+
+
+
+
+
diff --git a/content/zh/docs/v3.0/references/features/attachment.md b/content/zh/docs/v3.0/references/features/attachment.md
new file mode 100644
index 0000000..f82a37f
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/attachment.md
@@ -0,0 +1,38 @@
+---
+type: docs
+title: "隐式参数"
+linkTitle: "隐式参数"
+weight: 20
+description: "通过 Dubbo 中的 Attachment 在服务消费方和提供方之间隐式传递参数"
+---
+
+可以通过 `RpcContext` 上的 `setAttachment` 和 `getAttachment` 在服务消费方和提供方之间进行参数的隐式传递。
+
+{{% alert title="注意" color="primary" %}}
+path, group, version, dubbo, token, timeout 几个 key 是保留字段，请使用其它值。
+{{% /alert %}}
+
+
+
+#### 在服务消费方端设置隐式参数
+
+`setAttachment` 设置的 KV 对，在完成下面一次远程调用会被清空，即多次远程调用要多次设置。
+
+```xml
+RpcContext.getContext().setAttachment("index", "1"); // 隐式传参，后面的远程调用都会隐式将这些参数发送到服务器端，类似cookie，用于框架集成，不建议常规业务使用
+xxxService.xxx(); // 远程调用
+// ...
+```
+
+#### 在服务提供方端获取隐式参数
+
+```java
+public class XxxServiceImpl implements XxxService {
+
+ public void xxx() {
+ // 获取客户端隐式传入的参数，用于框架集成，不建议常规业务使用
+ String index = RpcContext.getContext().getAttachment("index");
+ }
+}
+```
+
diff --git a/content/zh/docs/v3.0/references/features/auth.md b/content/zh/docs/v3.0/references/features/auth.md
new file mode 100644
index 0000000..4ae72b1
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/auth.md
@@ -0,0 +1,28 @@
+# 服务鉴权
+
+类似支付之类的对安全性敏感的业务可能会有限制匿名调用的需求。在加固安全性方面，2.7.5 引入了基于AK/SK机制的认证鉴权机制，并且引入了鉴权服务中心，主要原理是消费端在请求需要鉴权的服务时，会通过SK、请求元数据、时间戳、参数等信息来生成对应的请求签名，通过Dubbo的Attahcment机制携带到对端进行验签，验签通过才进行业务逻辑处理。如下图所示：
+
+
+
+
+
+具体的接入方式也并不复杂：
+
+1. 使用者需要在微服务站点上填写自己的应用信息，并为该应用生成唯一的证书凭证。
+
+2. 之后在管理站点上提交工单，申请某个敏感业务服务的使用权限，并由对应业务管理者进行审批，审批通过之后，会生成对应的AK/SK到鉴权服务中心。
+
+3. 导入该证书到对应的应用下，并且进行配置。配置方式也十分简单，以注解方式为例：
+
+ 服务提供端，只需要设置`service.auth`为true，表示该服务的调用需要鉴权认证通过。`param.sign`为`true`表示需要对参数也进行校验。
+
+ ```java
+ @Service(parameters = {"service.auth","true","param.sign","true"})
+ public class AuthDemoServiceImpl implements AuthService {
+ }
+
+ ```
+
+ 服务消费端，只需要配置好对应的证书等信息即可，之后会自动地在对这些需要认证的接口发起调用前进行签名操作，通过与鉴权服务的交互，用户无需在代码中配置AK/SK这些敏感信息，并且在不重启应用的情况下刷新AK/SK，达到权限动态下发的目的。
+
+该方案目前已经提交给Dubbo开源社区，并且完成了基本框架的合并，除了AK/SK的鉴权方式之外，通过SPI机制支持用户可定制化的鉴权认证以及适配公司内部基础设施的密钥存储。
diff --git a/content/zh/docs/v3.0/references/features/callback-parameter.md b/content/zh/docs/v3.0/references/features/callback-parameter.md
new file mode 100644
index 0000000..8bcf479
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/callback-parameter.md
@@ -0,0 +1,120 @@
+---
+type: docs
+title: "参数回调"
+linkTitle: "参数回调"
+weight: 23
+description: "通过参数回调从服务器端调用客户端逻辑"
+---
+
+参数回调方式与调用本地 callback 或 listener 相同，只需要在 Spring 的配置文件中声明哪个参数是 callback 类型即可。Dubbo 将基于长连接生成反向代理，这样就可以从服务器端调用客户端逻辑。可以参考 [dubbo 项目中的示例代码](https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-callback)。
+
+#### 服务接口示例
+
+###### CallbackService.java
+
+```java
+package com.callback;
+
+public interface CallbackService {
+ void addListener(String key, CallbackListener listener);
+}
+```
+
+###### CallbackListener.java
+
+```java
+package com.callback;
+
+public interface CallbackListener {
+ void changed(String msg);
+}
+```
+
+#### 服务提供者接口实现示例
+
+```java
+package com.callback.impl;
+
+import java.text.SimpleDateFormat;
+import java.util.Date;
+import java.util.Map;
+import java.util.concurrent.ConcurrentHashMap;
+
+import com.callback.CallbackListener;
+import com.callback.CallbackService;
+
+public class CallbackServiceImpl implements CallbackService {
+
+ private final Map<String, CallbackListener> listeners = new ConcurrentHashMap<String, CallbackListener>();
+
+ public CallbackServiceImpl() {
+ Thread t = new Thread(new Runnable() {
+ public void run() {
+ while(true) {
+ try {
+ for(Map.Entry<String, CallbackListener> entry : listeners.entrySet()){
+ try {
+ entry.getValue().changed(getChanged(entry.getKey()));
+ } catch (Throwable t) {
+ listeners.remove(entry.getKey());
+ }
+ }
+ Thread.sleep(5000); // 定时触发变更通知
+ } catch (Throwable t) { // 防御容错
+ t.printStackTrace();
+ }
+ }
+ }
+ });
+ t.setDaemon(true);
+ t.start();
+ }
+
+ public void addListener(String key, CallbackListener listener) {
+ listeners.put(key, listener);
+ listener.changed(getChanged(key)); // 发送变更通知
+ }
+
+ private String getChanged(String key) {
+ return "Changed: " + new SimpleDateFormat("yyyy-MM-dd HH:mm:ss").format(new Date());
+ }
+}
+```
+
+#### 服务提供者配置示例
+
+```xml
+<bean id="callbackService" class="com.callback.impl.CallbackServiceImpl" />
+<dubbo:service interface="com.callback.CallbackService" ref="callbackService" connections="1" callbacks="1000">
+ <dubbo:method name="addListener">
+ <dubbo:argument index="1" callback="true" />
+ <!--也可以通过指定类型的方式-->
+ <!--<dubbo:argument type="com.demo.CallbackListener" callback="true" />-->
+ </dubbo:method>
+</dubbo:service>
+```
+
+#### 服务消费者配置示例
+
+```xml
+<dubbo:reference id="callbackService" interface="com.callback.CallbackService" />
+```
+
+#### 服务消费者调用示例
+
+```java
+ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext("classpath:consumer.xml");
+context.start();
+
+CallbackService callbackService = (CallbackService) context.getBean("callbackService");
+
+callbackService.addListener("foo.bar", new CallbackListener(){
+ public void changed(String msg) {
+ System.out.println("callback1:" + msg);
+ }
+});
+```
+
+{{% alert title="提示" color="primary" %}}
+`2.0.6` 及其以上版本支持
+{{% /alert %}}
diff --git a/content/zh/docs/v3.0/references/features/concurrency-control.md b/content/zh/docs/v3.0/references/features/concurrency-control.md
new file mode 100644
index 0000000..fd84022
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/concurrency-control.md
@@ -0,0 +1,74 @@
+---
+type: docs
+title: "并发控制"
+linkTitle: "并发控制"
+weight: 28
+description: "Dubbo 中的并发控制"
+---
+
+## 配置样例
+
+### 样例 1
+
+限制 `com.foo.BarService` 的每个方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
+
+```xml
+<dubbo:service interface="com.foo.BarService" executes="10" />
+```
+
+### 样例 2
+
+限制 `com.foo.BarService` 的 `sayHello` 方法，服务器端并发执行（或占用线程池线程数）不能超过 10 个：
+
+```xml
+<dubbo:service interface="com.foo.BarService">
+ <dubbo:method name="sayHello" executes="10" />
+</dubbo:service>
+```
+### 样例 3
+
+限制 `com.foo.BarService` 的每个方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
+
+```xml
+<dubbo:service interface="com.foo.BarService" actives="10" />
+```
+
+或
+
+```xml
+<dubbo:reference interface="com.foo.BarService" actives="10" />
+```
+
+### 样例 4
+
+限制 `com.foo.BarService` 的 `sayHello` 方法，每客户端并发执行（或占用连接的请求数）不能超过 10 个：
+
+```xml
+<dubbo:service interface="com.foo.BarService">
+ <dubbo:method name="sayHello" actives="10" />
+</dubbo:service>
+```
+
+或
+
+```xml
+<dubbo:reference interface="com.foo.BarService">
+ <dubbo:method name="sayHello" actives="10" />
+</dubbo:service>
+```
+
+如果 `<dubbo:service>` 和 `<dubbo:reference>` 都配了actives，`<dubbo:reference>` 优先，参见：[配置的覆盖策略](../../configuration/xml)。
+
+## Load Balance 均衡
+
+配置服务的客户端的 `loadbalance` 属性为 `leastactive`，此 Loadbalance 会调用并发数最小的 Provider（Consumer端并发数）。
+
+```xml
+<dubbo:reference interface="com.foo.BarService" loadbalance="leastactive" />
+```
+
+或
+
+```xml
+<dubbo:service interface="com.foo.BarService" loadbalance="leastactive" />
+```
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/config-connections.md b/content/zh/docs/v3.0/references/features/config-connections.md
new file mode 100644
index 0000000..dd59bbb
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/config-connections.md
@@ -0,0 +1,41 @@
+---
+type: docs
+title: "连接控制"
+linkTitle: "连接控制"
+weight: 29
+description: "Dubbo 中服务端和客户端的连接控制"
+---
+
+## 服务端连接控制
+
+限制服务器端接受的连接不能超过 10 个 [^1]：
+
+```xml
+<dubbo:provider protocol="dubbo" accepts="10" />
+```
+
+或
+
+```xml
+<dubbo:protocol name="dubbo" accepts="10" />
+```
+
+## 客户端连接控制
+
+限制客户端服务使用连接不能超过 10 个 [^2]：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" connections="10" />
+```
+
+或
+
+```xml
+<dubbo:service interface="com.foo.BarService" connections="10" />
+```
+
+如果 `<dubbo:service>` 和 `<dubbo:reference>` 都配了 connections，`<dubbo:reference>` 优先，参见：[配置的覆盖策略](../../configuration/xml)
+
+[^1]: 因为连接在 Server上，所以配置在 Provider 上
+[^2]: 如果是长连接，比如 Dubbo 协议，connections 表示该服务对每个提供者建立的长连接数
+
diff --git a/content/zh/docs/v3.0/references/features/config-rule-deprecated.md b/content/zh/docs/v3.0/references/features/config-rule-deprecated.md
new file mode 100644
index 0000000..2630067
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/config-rule-deprecated.md
@@ -0,0 +1,57 @@
+---
+type: docs
+title: "旧配置规则"
+linkTitle: "旧配置规则"
+weight: 35
+description: "Dubbo 中旧版本的规则配置方式"
+---
+
+向注册中心写入动态配置覆盖规则。该功能通常由监控中心或治理中心的页面完成。
+
+```java
+RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
+Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
+registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&timeout=1000"));
+```
+
+其中：
+
+* `override://` 表示数据采用覆盖方式，支持 `override` 和 `absent`，可扩展，**必填**。
+* `0.0.0.0` 表示对所有 IP 地址生效，如果只想覆盖某个 IP 的数据，请填入具体 IP，**必填**。
+* `com.foo.BarService` 表示只对指定服务生效，**必填**。
+* `category=configurators` 表示该数据为动态配置类型，**必填**。
+* `dynamic=false` 表示该数据为持久数据，当注册方退出时，数据依然保存在注册中心，**必填**。
+* `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
+* `application=foo` 表示只对指定应用生效，可不填，表示对所有应用生效。
+* `timeout=1000` 表示将满足以上条件的 `timeout` 参数的值覆盖为 1000。如果想覆盖其它参数，直接加在 `override` 的 URL 参数上。
+
+示例：
+
+1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)
+
+ ```
+ override://10.20.153.10/com.foo.BarService?category=configurators&dynamic=false&disbaled=true
+ ```
+
+2. 调整权重：(通常用于容量评估，缺省权重为 100)
+
+ ```
+ override://10.20.153.10/com.foo.BarService?category=configurators&dynamic=false&weight=200
+ ```
+
+3. 调整负载均衡策略：(缺省负载均衡策略为 random)
+
+ ```
+ override://10.20.153.10/com.foo.BarService?category=configurators&dynamic=false&loadbalance=leastactive
+ ```
+
+4. 服务降级：(通常用于临时屏蔽某个出错的非关键服务)
+
+ ```
+ override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null
+ ```
+
+
+{{% alert title="提示" color="primary" %}}
+`2.2.0` 以上版本支持
+{{% /alert %}}
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/config-rule.md b/content/zh/docs/v3.0/references/features/config-rule.md
new file mode 100644
index 0000000..495e9d1
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/config-rule.md
@@ -0,0 +1,177 @@
+---
+type: docs
+title: "配置规则"
+linkTitle: "配置规则"
+weight: 34
+description: "在 Dubbo 中配置应用级治理规则和服务级治理规则"
+---
+
+{{% alert title="提示" color="primary" %}}
+本文描述的是新版本规则配置，而不是[老版本配置规则](../config-rule-deprecated)
+{{% /alert %}}
+
+
+覆盖规则是 Dubbo 设计的在无需重启应用的情况下，动态调整 RPC 调用行为的一种能力。2.7.0 版本开始，支持从**服务**和**应用**两个粒度来调整动态配置。
+
+## 概览
+
+请在[服务治理控制台](http://47.91.207.147/#/governance/config)查看或修改覆盖规则。
+
+应用粒度
+
+```yaml
+# 将应用demo（key:demo）在20880端口上提供（side:provider）的所有服务（scope:application）的权重修改为1000（weight:1000）。
+---
+configVersion: v2.7
+scope: application
+key: demo
+enabled: true
+configs:
+- addresses: ["0.0.0.0:20880"]
+ side: provider
+ parameters:
+ weight: 1000
+ ...
+```
+
+服务粒度
+
+```yaml
+# 所有消费（side:consumer）DemoService服务（key:org.apache.dubbo.samples.governance.api.DemoService）的应用实例（addresses:[0.0.0.0]），超时时间修改为6000ms
+---
+configVersion: v2.7
+scope: service
+key: org.apache.dubbo.samples.governance.api.DemoService
+enabled: true
+configs:
+- addresses: [0.0.0.0]
+ side: consumer
+ parameters:
+ timeout: 6000
+ ...
+```
+
+## 规则详解
+
+#### 配置模板
+
+```yaml
+---
+configVersion: v2.7
+scope: application/service
+key: app-name/group+service+version
+enabled: true
+configs:
+- addresses: ["0.0.0.0"]
+ providerAddresses: ["1.1.1.1:20880", "2.2.2.2:20881"]
+ side: consumer
+ applications/services: []
+ parameters:
+ timeout: 1000
+ cluster: failfase
+ loadbalance: random
+- addresses: ["0.0.0.0:20880"]
+ side: provider
+ applications/services: []
+ parameters:
+ threadpool: fixed
+ threads: 200
+ iothreads: 4
+ dispatcher: all
+ weight: 200
+...
+```
+
+其中：
+- `configVersion` 表示 dubbo 的版本
+- `scope`表示配置作用范围，分别是应用（application）或服务（service）粒度。**必填**。
+- `key` 指定规则体作用在哪个服务或应用。**必填**。
+ - scope=service时，key取值为[{group}:]{service}[:{version}]的组合
+- scope=application时，key取值为application名称
+- `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
+- `configs` 定义具体的覆盖规则内容，可以指定n（n>=1）个规则体。**必填**。
+ - side，
+ - applications
+ - services
+ - parameters
+ - addresses
+ - providerAddresses
+
+**对于绝大多数配置场景，只需要理清楚以下问题基本就知道配置该怎么写了：**
+1. 要修改整个应用的配置还是某个服务的配置。
+ - 应用：`scope: application, key: app-name`（还可使用`services`指定某几个服务）。
+ - 服务：`scope: service, key:group+service+version `。
+
+2. 修改是作用到消费者端还是提供者端。
+ - 消费者：`side: consumer` ，作用到消费端时（你还可以进一步使用`providerAddress`, `applications`选定特定的提供者示例或应用）。
+ - 提供者：`side: provider`。
+
+3. 配置是否只对某几个特定实例生效。
+ - 所有实例：`addresses: ["0.0.0.0"] `或`addresses: ["0.0.0.0:*"] `具体由side值决定。
+ - 指定实例：`addersses[实例地址列表]`。
+
+4. 要修改的属性是哪个。
+
+#### 示例
+
+1. 禁用提供者：(通常用于临时踢除某台提供者机器，相似的，禁止消费者访问请使用路由规则)
+
+ ```yaml
+ ---
+ configVersion: v2.7
+ scope: application
+ key: demo-provider
+ enabled: true
+ configs:
+ - addresses: ["10.20.153.10:20880"]
+ side: provider
+ parameters:
+ disabled: true
+ ...
+ ```
+
+2. 调整权重：(通常用于容量评估，缺省权重为 200)
+
+ ```yaml
+ ---
+ configVersion: v2.7
+ scope: application
+ key: demo-provider
+ enabled: true
+ configs:
+ - addresses: ["10.20.153.10:20880"]
+ side: provider
+ parameters:
+ weight: 200
+ ...
+ ```
+
+3. 调整负载均衡策略：(缺省负载均衡策略为 random)
+
+ ```yaml
+ ---
+ configVersion: v2.7
+ scope: application
+ key: demo-consumer
+ enabled: true
+ configs:
+ - side: consumer
+ parameters:
+ loadbalance: random
+ ...
+ ```
+
+4. 服务降级：(通常用于临时屏蔽某个出错的非关键服务)
+
+ ```yaml
+ ---
+ configVersion: v2.7
+ scope: service
+ key: org.apache.dubbo.samples.governance.api.DemoService
+ enabled: true
+ configs:
+ - side: consumer
+ parameters:
+ force: return null
+ ...
+ ```
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/consumer-threadpool.md b/content/zh/docs/v3.0/references/features/consumer-threadpool.md
new file mode 100644
index 0000000..39b067c
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/consumer-threadpool.md
@@ -0,0 +1,45 @@
+---
+type: docs
+title: "消费端线程池模型"
+linkTitle: "消费端线程池模型"
+weight: 35
+description: "Dubbo 消费端线程池模型用法"
+---
+
+2.7.5 版本对整个调用链路做了全面的优化，根据压测结果显示，总体 QPS 性能提升将近 30%，同时也减少了调用过程中的内存分配开销。其中一个值得提及的设计点是 2.7.5 引入了 Servicerepository 的概念，在服务注册阶段提前生成 ServiceDescriptor 和 MethodDescriptor，以减少 RPC 调用阶段计算 Service 原信息带来的资源消耗。
+
+## 消费端线程池模型优化
+
+对 2.7.5 版本之前的 Dubbo 应用，尤其是一些消费端应用，当面临需要消费大量服务且并发数比较大的大流量场景时（典型如网关类场景），经常会出现消费端线程数分配过多的问题，具体问题讨论可参见 [Need a limited Threadpool in consumer side #2013](https://github.com/apache/dubbo/issues/2013)
+
+改进后的消费端线程池模型，通过复用业务端被阻塞的线程，很好的解决了这个问题。
+
+#### 老的线程池模型
+
+
+
+我们重点关注 Consumer 部分：
+
+1. 业务线程发出请求，拿到一个 Future 实例。
+2. 业务线程紧接着调用 future.get 阻塞等待业务结果返回。
+3. 当业务数据返回后，交由独立的 Consumer 端线程池进行反序列化等处理，并调用 future.set 将反序列化后的业务结果置回。
+4. 业务线程拿到结果直接返回
+
+
+
+**2.7.5 版本引入的线程池模型**
+
+
+
+1. 业务线程发出请求，拿到一个 Future 实例。
+2. 在调用 future.get() 之前，先调用 ThreadlessExecutor.wait()，wait 会使业务线程在一个阻塞队列上等待，直到队列中被加入元素。
+3. 当业务数据返回后，生成一个 Runnable Task 并放入 ThreadlessExecutor 队列
+4. 业务线程将 Task 取出并在本线程中执行：反序列化业务数据并 set 到 Future。
+5. 业务线程拿到结果直接返回
+
+这样，相比于老的线程池模型，由业务线程自己负责监测并解析返回结果，免去了额外的消费端线程池开销。
+
+关于性能优化，在接下来的版本中将会持续推进，主要从以下两个方面入手：
+
+1. RPC 调用链路。目前能看到的点包括：进一步减少执行链路的内存分配、在保证协议兼容性的前提下提高协议传输效率、提高 Filter、Router 等计算效率。
+2. 服务治理链路。进一步减少地址推送、服务治理规则推送等造成的内存、cpu 资源消耗。
diff --git a/content/zh/docs/v3.0/references/features/context.md b/content/zh/docs/v3.0/references/features/context.md
new file mode 100644
index 0000000..ad41238
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/context.md
@@ -0,0 +1,46 @@
+---
+type: docs
+title: "上下文信息"
+linkTitle: "上下文信息"
+weight: 19
+description: "通过上下文存放当前调用过程中所需的环境信息"
+---
+
+上下文中存放的是当前调用过程中所需的环境信息。所有配置信息都将转换为 URL 的参数，参见 [schema 配置参考手册](../references/xml) 中的**对应URL参数**一列。
+
+RpcContext 是一个 ThreadLocal 的临时状态记录器，当接收到 RPC 请求，或发起 RPC 请求时，RpcContext 的状态都会变化。比如：A 调 B，B 再调 C，则 B 机器上，在 B 调 C 之前，RpcContext 记录的是 A 调 B 的信息，在 B 调 C 之后，RpcContext 记录的是 B 调 C 的信息。
+
+## 服务消费方
+
+```java
+// 远程调用
+xxxService.xxx();
+// 本端是否为消费端，这里会返回true
+boolean isConsumerSide = RpcContext.getContext().isConsumerSide();
+// 获取最后一次调用的提供方IP地址
+String serverIP = RpcContext.getContext().getRemoteHost();
+// 获取当前服务配置信息，所有配置信息都将转换为URL的参数
+String application = RpcContext.getContext().getUrl().getParameter("application");
+// 注意：每发起RPC调用，上下文状态会变化
+yyyService.yyy();
+```
+
+## 服务提供方
+
+```java
+public class XxxServiceImpl implements XxxService {
+
+ public void xxx() {
+ // 本端是否为提供端，这里会返回true
+ boolean isProviderSide = RpcContext.getContext().isProviderSide();
+ // 获取调用方IP地址
+ String clientIP = RpcContext.getContext().getRemoteHost();
+ // 获取当前服务配置信息，所有配置信息都将转换为URL的参数
+ String application = RpcContext.getContext().getUrl().getParameter("application");
+ // 注意：每发起RPC调用，上下文状态会变化
+ yyyService.yyy();
+ // 此时本端变成消费端，这里会返回false
+ boolean isProviderSide = RpcContext.getContext().isProviderSide();
+ }
+}
+```
diff --git a/content/zh/docs/v3.0/references/features/delay-publish.md b/content/zh/docs/v3.0/references/features/delay-publish.md
new file mode 100644
index 0000000..9fb7073
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/delay-publish.md
@@ -0,0 +1,59 @@
+---
+type: docs
+title: "延迟暴露"
+linkTitle: "延迟暴露"
+weight: 27
+description: "延迟暴露 Dubbo 服务"
+---
+
+如果你的服务需要预热时间，比如初始化缓存，等待相关资源就位等，可以使用 delay 进行延迟暴露。我们在 Dubbo 2.6.5 版本中对服务延迟暴露逻辑进行了细微的调整，将需要延迟暴露（delay > 0）服务的倒计时动作推迟到了 Spring 初始化完成后进行。你在使用 Dubbo 的过程中，并不会感知到此变化，因此请放心使用。
+
+## Dubbo 2.6.5 之前版本
+
+延迟到 Spring 初始化完成后，再暴露服务[^1]
+
+```xml
+<dubbo:service delay="-1" />
+```
+
+延迟 5 秒暴露服务
+
+```xml
+<dubbo:service delay="5000" />
+```
+
+## Dubbo 2.6.5 及以后版本
+
+所有服务都将在 Spring 初始化完成后进行暴露，如果你不需要延迟暴露服务，无需配置 delay。
+
+延迟 5 秒暴露服务
+
+```xml
+<dubbo:service delay="5000" />
+```
+
+## Spring 2.x 初始化死锁问题
+
+### 触发条件
+
+在 Spring 解析到 `<dubbo:service />` 时，就已经向外暴露了服务，而 Spring 还在接着初始化其它 Bean。如果这时有请求进来，并且服务的实现类里有调用 `applicationContext.getBean()` 的用法。
+
+1. 请求线程的 applicationContext.getBean() 调用，先同步 singletonObjects 判断 Bean 是否存在，不存在就同步 beanDefinitionMap 进行初始化，并再次同步 singletonObjects 写入 Bean 实例缓存。
+
+ 
+
+2. 而 Spring 初始化线程，因不需要判断 Bean 的存在，直接同步 beanDefinitionMap 进行初始化，并同步 singletonObjects 写入 Bean 实例缓存。
+
+ 
+
+ 这样就导致 getBean 线程，先锁 singletonObjects，再锁 beanDefinitionMap，再次锁 singletonObjects。
+而 Spring 初始化线程，先锁 beanDefinitionMap，再锁 singletonObjects。反向锁导致线程死锁，不能提供服务，启动不了。
+
+### 规避办法
+
+1. 强烈建议不要在服务的实现类中有 applicationContext.getBean() 的调用，全部采用 IoC 注入的方式使用 Spring的Bean。
+2. 如果实在要调 getBean()，可以将 Dubbo 的配置放在 Spring 的最后加载。
+3. 如果不想依赖配置顺序，可以使用 `<dubbo:provider delay=”-1” />`，使 Dubbo 在 Spring 容器初始化完后，再暴露服务。
+4. 如果大量使用 getBean()，相当于已经把 Spring 退化为工厂模式在用，可以将 Dubbo 的服务隔离单独的 Spring 容器。
+
+[^1]: 基于 Spring 的 ContextRefreshedEvent 事件触发暴露
diff --git a/content/zh/docs/v3.0/references/features/distributed-transaction.md b/content/zh/docs/v3.0/references/features/distributed-transaction.md
new file mode 100644
index 0000000..8992516
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/distributed-transaction.md
@@ -0,0 +1,15 @@
+---
+type: docs
+title: "分布式事务"
+linkTitle: "分布式事务"
+weight: 42
+description: "Dubbo 中分布式事务的支持"
+---
+
+分布式事务基于 JTA/XA 规范实现。
+
+两阶段提交：
+
+
+
+在 Dubbo 中，可以采用 [seata](/zh/blog/2019/01/17/如何使用seata保证dubbo微服务间的一致性/) 来完成对分布式事务的支持。
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/dump.md b/content/zh/docs/v3.0/references/features/dump.md
new file mode 100644
index 0000000..bd6c5e2
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/dump.md
@@ -0,0 +1,26 @@
+---
+type: docs
+title: "导出线程堆栈"
+linkTitle: "导出线程堆栈"
+weight: 43
+description: "在 Dubbo 自动导出线程堆栈来保留现场"
+---
+
+当业务线程池满时，我们需要知道线程都在等待哪些资源、条件，以找到系统的瓶颈点或异常点。dubbo 通过 Jstack 自动导出线程堆栈来保留现场，方便排查问题。
+
+默认策略:
+
+* 导出路径，user.home标识的用户主目录
+* 导出间隔，最短间隔允许每隔10分钟导出一次
+
+指定导出路径：
+```properties
+# dubbo.properties
+dubbo.application.dump.directory=/tmp
+```
+
+```xml
+<dubbo:application ...>
+ <dubbo:parameter key="dump.directory" value="/tmp" />
+</dubbo:application>
+```
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/echo-service.md b/content/zh/docs/v3.0/references/features/echo-service.md
new file mode 100644
index 0000000..afedc8b
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/echo-service.md
@@ -0,0 +1,29 @@
+---
+type: docs
+title: "回声测试"
+linkTitle: "回声测试"
+weight: 18
+description: "通过回声测试检测 Dubbo 服务是否可用"
+---
+
+回声测试用于检测服务是否可用，回声测试按照正常请求流程执行，能够测试整个调用是否通畅，可用于监控。
+
+所有服务自动实现 `EchoService` 接口，只需将任意服务引用强制转型为 `EchoService`，即可使用。
+
+Spring 配置：
+```xml
+<dubbo:reference id="memberService" interface="com.xxx.MemberService" />
+```
+
+代码：
+```java
+// 远程服务引用
+MemberService memberService = ctx.getBean("memberService");
+
+EchoService echoService = (EchoService) memberService; // 强制转型为EchoService
+
+// 回声测试可用性
+String status = echoService.$echo("OK");
+
+assert(status.equals("OK"));
+```
diff --git a/content/zh/docs/v3.0/references/features/events-notify.md b/content/zh/docs/v3.0/references/features/events-notify.md
new file mode 100644
index 0000000..197fbe2
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/events-notify.md
@@ -0,0 +1,108 @@
+---
+type: docs
+title: "事件通知"
+linkTitle: "事件通知"
+weight: 24
+description: "在调用之前、调用之后、出现异常时的时间通知"
+---
+
+在调用之前、调用之后、出现异常时，会触发 `oninvoke`、`onreturn`、`onthrow` 三个事件，可以配置当事件发生时，通知哪个类的哪个方法。
+
+{{% alert title="提示" color="primary" %}}
+支持版本：`2.0.7` 之后
+{{% /alert %}}
+
+#### 服务提供者与消费者共享服务接口
+
+```java
+interface IDemoService {
+ public Person get(int id);
+}
+```
+
+#### 服务提供者实现
+
+```java
+class NormalDemoService implements IDemoService {
+ public Person get(int id) {
+ return new Person(id, "charles`son", 4);
+ }
+}
+```
+
+#### 服务提供者配置
+
+```xml
+<dubbo:application name="rpc-callback-demo" />
+<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
+<bean id="demoService" class="org.apache.dubbo.callback.implicit.NormalDemoService" />
+<dubbo:service interface="org.apache.dubbo.callback.implicit.IDemoService" ref="demoService" version="1.0.0" group="cn"/>
+```
+
+#### 服务消费者 Callback 接口
+
+```java
+interface Notify {
+ public void onreturn(Person msg, Integer id);
+ public void onthrow(Throwable ex, Integer id);
+}
+```
+
+#### 服务消费者 Callback 实现
+
+```java
+class NotifyImpl implements Notify {
+ public Map<Integer, Person> ret = new HashMap<Integer, Person>();
+ public Map<Integer, Throwable> errors = new HashMap<Integer, Throwable>();
+
+ public void onreturn(Person msg, Integer id) {
+ System.out.println("onreturn:" + msg);
+ ret.put(id, msg);
+ }
+
+ public void onthrow(Throwable ex, Integer id) {
+ errors.put(id, ex);
+ }
+}
+```
+
+#### 服务消费者 Callback 配置
+
+```xml
+<bean id ="demoCallback" class = "org.apache.dubbo.callback.implicit.NotifyImpl" />
+<dubbo:reference id="demoService" interface="org.apache.dubbo.callback.implicit.IDemoService" version="1.0.0" group="cn" >
+ <dubbo:method name="get" async="true" onreturn = "demoCallback.onreturn" onthrow="demoCallback.onthrow" />
+</dubbo:reference>
+```
+
+`callback` 与 `async` 功能正交分解，`async=true` 表示结果是否马上返回，`onreturn` 表示是否需要回调。
+
+两者叠加存在以下几种组合情况：
+
+* 异步回调模式：`async=true onreturn="xxx"`
+* 同步回调模式：`async=false onreturn="xxx"`
+* 异步无回调 ：`async=true`
+* 同步无回调 ：`async=false`
+
+{{% alert title="提示" color="primary" %}}
+`async=false` 默认
+{{% /alert %}}
+
+#### 测试代码
+
+```java
+IDemoService demoService = (IDemoService) context.getBean("demoService");
+NotifyImpl notify = (NotifyImpl) context.getBean("demoCallback");
+int requestId = 2;
+Person ret = demoService.get(requestId);
+Assert.assertEquals(null, ret);
+//for Test：只是用来说明callback正常被调用，业务具体实现自行决定.
+for (int i = 0; i < 10; i++) {
+ if (!notify.ret.containsKey(requestId)) {
+ Thread.sleep(200);
+ } else {
+ break;
+ }
+}
+Assert.assertEquals(requestId, notify.ret.get(requestId).getId());
+```
diff --git a/content/zh/docs/v3.0/references/features/explicit-target.md b/content/zh/docs/v3.0/references/features/explicit-target.md
new file mode 100644
index 0000000..a6c3c79
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/explicit-target.md
@@ -0,0 +1,58 @@
+---
+type: docs
+title: "直连提供者"
+linkTitle: "直连提供者"
+weight: 5
+description: "Dubbo 中点对点的直连方式"
+---
+
+在开发及测试环境下，经常需要绕过注册中心，只测试指定服务提供者，这时候可能需要点对点直连，点对点直连方式，将以服务接口为单位，忽略注册中心的提供者列表，A 接口配置点对点，不影响 B 接口从注册中心获取列表。
+
+
+
+## 通过 XML 配置
+
+如果是线上需求需要点对点，可在 `<dubbo:reference>` 中配置 url 指向提供者，将绕过注册中心，多个地址用分号隔开，配置如下：
+
+```xml
+<dubbo:reference id="xxxService" interface="com.alibaba.xxx.XxxService" url="dubbo://localhost:20890" />
+```
+
+{{% alert title="提示" color="primary" %}}
+`1.0.6` 及以上版本支持
+{{% /alert %}}
+
+## 通过 -D 参数指定
+
+在 JVM 启动参数中加入-D参数映射服务地址，如：
+
+```sh
+java -Dcom.alibaba.xxx.XxxService=dubbo://localhost:20890
+```
+
+{{% alert title="提示" color="primary" %}}
+key 为服务名，value 为服务提供者 url，此配置优先级最高，`1.0.15` 及以上版本支持
+{{% /alert %}}
+
+## 通过文件映射
+
+如果服务比较多，也可以用文件映射，用 `-Ddubbo.resolve.file` 指定映射文件路径，此配置优先级高于 `<dubbo:reference>` 中的配置 [^3]，如：
+
+```sh
+java -Ddubbo.resolve.file=xxx.properties
+```
+
+然后在映射文件 `xxx.properties` 中加入配置，其中 key 为服务名，value 为服务提供者 URL：
+
+```properties
+com.alibaba.xxx.XxxService=dubbo://localhost:20890
+```
+
+{{% alert title="提示" color="primary" %}}
+`1.0.15` 及以上版本支持，`2.0` 以上版本自动加载 ${user.home}/dubbo-resolve.properties文件，不需要配置
+{{% /alert %}}
+
+{{% alert title="注意" color="warning" %}}
+为了避免复杂化线上环境，不要在线上使用这个功能，只应在测试阶段使用。
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/fault-tolerent-strategy.md b/content/zh/docs/v3.0/references/features/fault-tolerent-strategy.md
new file mode 100644
index 0000000..e4ec5e8
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/fault-tolerent-strategy.md
@@ -0,0 +1,104 @@
+---
+type: docs
+title: "集群容错"
+linkTitle: "集群容错"
+weight: 2
+description: "集群调用失败时，Dubbo 提供的容错方案"
+---
+
+在集群调用失败时，Dubbo 提供了多种容错方案，缺省为 failover 重试。
+
+
+
+各节点关系：
+
+* 这里的 `Invoker` 是 `Provider` 的一个可调用 `Service` 的抽象，`Invoker` 封装了 `Provider` 地址及 `Service` 接口信息
+* `Directory` 代表多个 `Invoker`，可以把它看成 `List<Invoker>` ，但与 `List` 不同的是，它的值可能是动态变化的，比如注册中心推送变更
+* `Cluster` 将 `Directory` 中的多个 `Invoker` 伪装成一个 `Invoker`，对上层透明，伪装过程包含了容错逻辑，调用失败后，重试另一个
+* `Router` 负责从多个 `Invoker` 中按路由规则选出子集，比如读写分离，应用隔离等
+* `LoadBalance` 负责从多个 `Invoker` 中选出具体的一个用于本次调用，选的过程包含了负载均衡算法，调用失败后，需要重选
+
+## 集群容错模式
+
+可以自行扩展集群容错策略，参见：[集群扩展](../../../dev/impls/cluster)
+
+### Failover Cluster
+
+失败自动切换，当出现失败，重试其它服务器。通常用于读操作，但重试会带来更长延迟。可通过 `retries="2"` 来设置重试次数(不含第一次)。
+
+重试次数配置如下：
+
+```xml
+<dubbo:service retries="2" />
+```
+
+或
+
+```xml
+<dubbo:reference retries="2" />
+```
+
+或
+
+```xml
+<dubbo:reference>
+ <dubbo:method name="findFoo" retries="2" />
+</dubbo:reference>
+```
+
+{{% alert title="提示" color="primary" %}}
+该配置为缺省配置
+{{% /alert %}}
+
+### Failfast Cluster
+
+快速失败，只发起一次调用，失败立即报错。通常用于非幂等性的写操作，比如新增记录。
+
+### Failsafe Cluster
+
+失败安全，出现异常时，直接忽略。通常用于写入审计日志等操作。
+
+### Failback Cluster
+
+失败自动恢复，后台记录失败请求，定时重发。通常用于消息通知操作。
+
+### Forking Cluster
+
+并行调用多个服务器，只要一个成功即返回。通常用于实时性要求较高的读操作，但需要浪费更多服务资源。可通过 `forks="2"` 来设置最大并行数。
+
+### Broadcast Cluster
+
+广播调用所有提供者，逐个调用，任意一台报错则报错。通常用于通知所有提供者更新缓存或日志等本地资源信息。
+
+现在广播调用中，可以通过 broadcast.fail.percent 配置节点调用失败的比例，当达到这个比例后，BroadcastClusterInvoker
+将不再调用其他节点，直接抛出异常。 broadcast.fail.percent 取值在 0～100 范围内。默认情况下当全部调用失败后，才会抛出异常。
+broadcast.fail.percent 只是控制的当失败后是否继续调用其他节点，并不改变结果(任意一台报错则报错)。broadcast.fail.percent 参数
+在 dubbo2.7.10 及以上版本生效。
+
+Broadcast Cluster 配置 broadcast.fail.percent。
+
+broadcast.fail.percent=20 代表了当 20% 的节点调用失败就抛出异常，不再调用其他节点。
+
+```text
+@reference(cluster = "broadcast", parameters = {"broadcast.fail.percent", "20"})
+```
+
+
+{{% alert title="提示" color="primary" %}}
+`2.1.0` 开始支持
+{{% /alert %}}
+
+## 集群模式配置
+
+按照以下示例在服务提供方和消费方配置集群模式
+
+```xml
+<dubbo:service cluster="failsafe" />
+```
+
+或
+
+```xml
+<dubbo:reference cluster="failsafe" />
+```
+
diff --git a/content/zh/docs/v3.0/references/features/generic-reference.md b/content/zh/docs/v3.0/references/features/generic-reference.md
new file mode 100644
index 0000000..7cf2c0c
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/generic-reference.md
@@ -0,0 +1,103 @@
+---
+type: docs
+title: "使用泛化调用"
+linkTitle: "使用泛化调用"
+weight: 16
+description: "实现一个通用的服务测试框架，可通过 `GenericService` 调用所有服务实现"
+---
+
+泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用 `Map` 表示，通常用于框架集成，比如：实现一个通用的服务测试框架，可通过 `GenericService` 调用所有服务实现。
+
+## 通过 Spring 使用泛化调用
+
+在 Spring 配置申明 `generic="true"`：
+
+```xml
+<dubbo:reference id="barService" interface="com.foo.BarService" generic="true" />
+```
+
+在 Java 代码获取 barService 并开始泛化调用：
+
+```java
+GenericService barService = (GenericService) applicationContext.getBean("barService");
+Object result = barService.$invoke("sayHello", new String[] { "java.lang.String" }, new Object[] { "World" });
+```
+
+## 通过 API 方式使用泛化调用
+
+```java
+import org.apache.dubbo.rpc.service.GenericService;
+...
+
+// 引用远程服务
+// 该实例很重量，里面封装了所有与注册中心及服务提供方连接，请缓存
+ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>();
+// 弱类型接口名
+reference.setInterface("com.xxx.XxxService");
+reference.setVersion("1.0.0");
+// 声明为泛化接口
+reference.setGeneric(true);
+
+// 用org.apache.dubbo.rpc.service.GenericService可以替代所有接口引用
+GenericService genericService = reference.get();
+
+// 基本类型以及Date,List,Map等不需要转换，直接调用
+Object result = genericService.$invoke("sayHello", new String[] {"java.lang.String"}, new Object[] {"world"});
+
+// 用Map表示POJO参数，如果返回值为POJO也将自动转成Map
+Map<String, Object> person = new HashMap<String, Object>();
+person.put("name", "xxx");
+person.put("password", "yyy");
+// 如果返回POJO将自动转成Map
+Object result = genericService.$invoke("findPerson", new String[]
+{"com.xxx.Person"}, new Object[]{person});
+
+...
+```
+
+## 有关泛化类型的进一步解释
+
+假设存在 POJO 如：
+
+```java
+package com.xxx;
+
+public class PersonImpl implements Person {
+ private String name;
+ private String password;
+
+ public String getName() {
+ return name;
+ }
+
+ public void setName(String name) {
+ this.name = name;
+ }
+
+ public String getPassword() {
+ return password;
+ }
+
+ public void setPassword(String password) {
+ this.password = password;
+ }
+}
+```
+
+则 POJO 数据：
+
+```java
+Person person = new PersonImpl();
+person.setName("xxx");
+person.setPassword("yyy");
+```
+
+可用下面 Map 表示：
+
+```java
+Map<String, Object> map = new HashMap<String, Object>();
+// 注意：如果参数类型是接口，或者List等丢失泛型，可通过class属性指定类型。
+map.put("class", "com.xxx.PersonImpl");
+map.put("name", "xxx");
+map.put("password", "yyy");
+```
diff --git a/content/zh/docs/v3.0/references/features/generic-service.md b/content/zh/docs/v3.0/references/features/generic-service.md
new file mode 100644
index 0000000..9235150
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/generic-service.md
@@ -0,0 +1,51 @@
+---
+type: docs
+title: "实现泛化调用"
+linkTitle: "实现泛化调用"
+weight: 17
+description: "实现一个通用的远程服务 Mock 框架，可通过实现 GenericService 接口处理所有服务请求"
+---
+
+泛接口实现方式主要用于服务器端没有 API 接口及模型类元的情况，参数及返回值中的所有 POJO 均用 Map 表示，通常用于框架集成，比如：实现一个通用的远程服务 Mock 框架，可通过实现 GenericService 接口处理所有服务请求。
+
+在 Java 代码中实现 `GenericService` 接口：
+
+```java
+package com.foo;
+public class MyGenericService implements GenericService {
+
+ public Object $invoke(String methodName, String[] parameterTypes, Object[] args) throws GenericException {
+ if ("sayHello".equals(methodName)) {
+ return "Welcome " + args[0];
+ }
+ }
+}
+```
+
+## 通过 Spring 暴露泛化实现
+
+在 Spring 配置申明服务的实现：
+
+```xml
+<bean id="genericService" class="com.foo.MyGenericService" />
+<dubbo:service interface="com.foo.BarService" ref="genericService" />
+```
+
+## 通过 API 方式暴露泛化实现
+
+```java
+...
+// 用org.apache.dubbo.rpc.service.GenericService可以替代所有接口实现
+GenericService xxxService = new XxxGenericService();
+
+// 该实例很重量，里面封装了所有与注册中心及服务提供方连接，请缓存
+ServiceConfig<GenericService> service = new ServiceConfig<GenericService>();
+// 弱类型接口名
+service.setInterface("com.xxx.XxxService");
+service.setVersion("1.0.0");
+// 指向一个通用服务实现
+service.setRef(xxxService);
+
+// 暴露及注册服务
+service.export();
+```
diff --git a/content/zh/docs/v3.0/references/features/graceful-shutdown.md b/content/zh/docs/v3.0/references/features/graceful-shutdown.md
new file mode 100644
index 0000000..2b82d81
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/graceful-shutdown.md
@@ -0,0 +1,41 @@
+---
+type: docs
+title: "优雅停机"
+linkTitle: "优雅停机"
+weight: 36
+description: "让 Dubbo 服务完成优雅停机"
+---
+
+Dubbo 是通过 JDK 的 ShutdownHook 来完成优雅停机的，所以如果用户使用 `kill -9 PID` 等强制关闭指令，是不会执行优雅停机的，只有通过 `kill PID` 时，才会执行。
+
+## 原理
+
+服务提供方
+
+* 停止时，先标记为不接收新请求，新请求过来时直接报错，让客户端重试其它机器。
+* 然后，检测线程池中的线程是否正在运行，如果有，等待所有线程执行完成，除非超时，则强制关闭。
+
+服务消费方
+
+* 停止时，不再发起新的调用请求，所有新的调用在客户端即报错。
+* 然后，检测有没有请求的响应还没有返回，等待响应返回，除非超时，则强制关闭。
+
+## 设置方式
+
+设置优雅停机超时时间，缺省超时时间是 10 秒，如果超时则强制关闭。
+
+```properties
+# dubbo.properties
+dubbo.service.shutdown.wait=15000
+```
+
+如果 ShutdownHook 不能生效，可以自行调用：
+
+```java
+DubboShutdownHook.destroyAll();
+```
+
+{{% alert title="建议" color="primary" %}}
+使用 tomcat 等容器部署的场景，建议通过扩展 ContextListener 等自行调用以下代码实现优雅停机
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/group-merger.md b/content/zh/docs/v3.0/references/features/group-merger.md
new file mode 100644
index 0000000..9d7f47f
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/group-merger.md
@@ -0,0 +1,67 @@
+---
+type: docs
+title: "分组聚合"
+linkTitle: "分组聚合"
+weight: 13
+description: "通过分组对结果进行聚合并返回聚合后的结果"
+---
+
+通过分组对结果进行聚合并返回聚合后的结果，比如菜单服务，用group区分同一接口的多种实现，现在消费方需从每种group中调用一次并返回结果，对结果进行合并之后返回，这样就可以实现聚合菜单项。
+
+相关代码可以参考 [dubbo 项目中的示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-merge)
+
+## 配置
+
+搜索所有分组
+
+```xml
+<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true" />
+```
+
+合并指定分组
+
+```xml
+<dubbo:reference interface="com.xxx.MenuService" group="aaa,bbb" merger="true" />
+```
+
+指定方法合并结果，其它未指定的方法，将只调用一个 Group
+
+```xml
+<dubbo:reference interface="com.xxx.MenuService" group="*">
+ <dubbo:method name="getMenuItems" merger="true" />
+</dubbo:reference>
+```
+
+某个方法不合并结果，其它都合并结果
+
+```xml
+<dubbo:reference interface="com.xxx.MenuService" group="*" merger="true">
+ <dubbo:method name="getMenuItems" merger="false" />
+</dubbo:reference>
+```
+
+指定合并策略，缺省根据返回值类型自动匹配，如果同一类型有两个合并器时，需指定合并器的名称
+
+{{% alert title="提示" color="primary" %}}
+参见：[合并结果扩展](../../../dev/impls/merger)
+{{% /alert %}}
+
+```xml
+<dubbo:reference interface="com.xxx.MenuService" group="*">
+ <dubbo:method name="getMenuItems" merger="mymerge" />
+</dubbo:reference>
+```
+
+指定合并方法，将调用返回结果的指定方法进行合并，合并方法的参数类型必须是返回结果类型本身
+
+```xml
+<dubbo:reference interface="com.xxx.MenuService" group="*">
+ <dubbo:method name="getMenuItems" merger=".addAll" />
+</dubbo:reference>
+```
+
+
+{{% alert title="提示" color="primary" %}}
+从 `2.1.0` 版本开始支持
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/hostname-binding.md b/content/zh/docs/v3.0/references/features/hostname-binding.md
new file mode 100644
index 0000000..7225c5b
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/hostname-binding.md
@@ -0,0 +1,64 @@
+---
+type: docs
+title: "主机绑定"
+linkTitle: "主机绑定"
+weight: 37
+description: "在 Dubbo 中绑定主机名"
+---
+
+## 查找顺序
+
+缺省主机 IP 查找顺序：
+
+* 通过 `LocalHost.getLocalHost()` 获取本机地址。
+* 如果是 `127.*` 等 loopback 地址，则扫描各网卡，获取网卡 IP。
+
+## 主机配置
+
+注册的地址如果获取不正确，比如需要注册公网地址，可以：
+
+1. 可以在 `/etc/hosts` 中加入：机器名 公网 IP，比如：
+
+ ```
+ test1 205.182.23.201
+ ```
+
+2. 在 `dubbo.xml` 中加入主机地址的配置：
+
+ ```xml
+ <dubbo:protocol host="205.182.23.201">
+ ```
+
+3. 或在 `dubbo.properties` 中加入主机地址的配置：
+
+ ```properties
+ dubbo.protocol.host=205.182.23.201
+ ```
+
+## 端口配置
+
+缺省主机端口与协议相关：
+
+协议 | 端口
+------------- | -------------
+dubbo | 20880
+rmi | 1099
+http | 80
+hessian | 80
+webservice | 80
+memcached | 11211
+redis | 6379
+
+可以按照下面的方式配置端口：
+
+1. 在 `dubbo.xml` 中加入主机地址的配置：
+
+ ```xml
+ <dubbo:protocol name="dubbo" port="20880">
+ ```
+
+2. 或在 `dubbo.properties` 中加入主机地址的配置：
+
+ ```properties
+ dubbo.protocol.dubbo.port=20880
+ ```
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/lazy-connect.md b/content/zh/docs/v3.0/references/features/lazy-connect.md
new file mode 100644
index 0000000..20875cb
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/lazy-connect.md
@@ -0,0 +1,18 @@
+---
+type: docs
+title: "延迟连接"
+linkTitle: "延迟连接"
+weight: 30
+description: "在 Dubbo 中配置延迟连接"
+---
+
+延迟连接用于减少长连接数。当有调用发起时，再创建长连接。
+
+```xml
+<dubbo:protocol name="dubbo" lazy="true" />
+```
+
+{{% alert title="提示" color="primary" %}}
+该配置只对使用长连接的 dubbo 协议生效。
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/loadbalance.md b/content/zh/docs/v3.0/references/features/loadbalance.md
new file mode 100644
index 0000000..598f005
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/loadbalance.md
@@ -0,0 +1,66 @@
+---
+type: docs
+title: "负载均衡"
+linkTitle: "负载均衡"
+weight: 3
+description: "Dubbo 提供的集群负载均衡策略"
+---
+
+在集群负载均衡时，Dubbo 提供了多种均衡策略，缺省为 `random` 随机调用。
+
+可以自行扩展负载均衡策略，参见：[负载均衡扩展](../../../dev/impls/load-balance)
+
+## 负载均衡策略
+
+### Random LoadBalance
+
+* **随机**，按权重设置随机概率。
+* 在一个截面上碰撞的概率高，但调用量越大分布越均匀，而且按概率使用权重后也比较均匀，有利于动态调整提供者权重。
+
+### RoundRobin LoadBalance
+
+* **轮询**，按公约后的权重设置轮询比率。
+* 存在慢的提供者累积请求的问题，比如：第二台机器很慢，但没挂，当请求调到第二台时就卡在那，久而久之，所有请求都卡在调到第二台上。
+
+### LeastActive LoadBalance
+
+* **最少活跃调用数**，相同活跃数的随机，活跃数指调用前后计数差。
+* 使慢的提供者收到更少请求，因为越慢的提供者的调用前后计数差会越大。
+
+### ConsistentHash LoadBalance
+
+* **一致性 Hash**，相同参数的请求总是发到同一提供者。
+* 当某一台提供者挂时，原本发往该提供者的请求，基于虚拟节点，平摊到其它提供者，不会引起剧烈变动。
+* 算法参见：http://en.wikipedia.org/wiki/Consistent_hashing
+* 缺省只对第一个参数 Hash，如果要修改，请配置 `<dubbo:parameter key="hash.arguments" value="0,1" />`
+* 缺省用 160 份虚拟节点，如果要修改，请配置 `<dubbo:parameter key="hash.nodes" value="320" />`
+
+## 配置
+
+### 服务端服务级别
+
+```xml
+<dubbo:service interface="..." loadbalance="roundrobin" />
+```
+
+### 客户端服务级别
+
+```xml
+<dubbo:reference interface="..." loadbalance="roundrobin" />
+```
+
+### 服务端方法级别
+
+```xml
+<dubbo:service interface="...">
+ <dubbo:method name="..." loadbalance="roundrobin"/>
+</dubbo:service>
+```
+
+### 客户端方法级别
+
+```xml
+<dubbo:reference interface="...">
+ <dubbo:method name="..." loadbalance="roundrobin"/>
+</dubbo:reference>
+```
diff --git a/content/zh/docs/v3.0/references/features/local-call.md b/content/zh/docs/v3.0/references/features/local-call.md
new file mode 100644
index 0000000..a55bbb7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/local-call.md
@@ -0,0 +1,55 @@
+---
+type: docs
+title: "本地调用"
+linkTitle: "本地调用"
+weight: 22
+description: "在 Dubbo 中进行本地调用"
+---
+
+本地调用使用了 injvm 协议，是一个伪协议，它不开启端口，不发起远程调用，只在 JVM 内直接关联，但执行 Dubbo 的 Filter 链。
+
+## 配置
+
+定义 injvm 协议
+
+```xml
+<dubbo:protocol name="injvm" />
+```
+
+设置默认协议
+
+```xml
+<dubbo:provider protocol="injvm" />
+```
+
+设置服务协议
+
+```xml
+<dubbo:service protocol="injvm" />
+```
+
+优先使用 injvm
+
+```xml
+<dubbo:consumer injvm="true" .../>
+<dubbo:provider injvm="true" .../>
+```
+
+或
+
+```xml
+<dubbo:reference injvm="true" .../>
+<dubbo:service injvm="true" .../>
+```
+
+{{% alert title="注意" color="primary" %}}
+Dubbo 从 `2.2.0` 每个服务默认都会在本地暴露，无需进行任何配置即可进行本地引用，如果不希望服务进行远程暴露，只需要在 provider 将 protocol 设置成 injvm 即可
+{{% /alert %}}
+
+## 自动暴露、引用本地服务
+
+从 `2.2.0` 开始，每个服务默认都会在本地暴露。在引用服务的时候，默认优先引用本地服务。如果希望引用远程服务可以使用一下配置强制引用远程服务。
+
+```xml
+<dubbo:reference ... scope="remote" />
+```
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/local-mock.md b/content/zh/docs/v3.0/references/features/local-mock.md
new file mode 100644
index 0000000..9e5e7b3
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/local-mock.md
@@ -0,0 +1,106 @@
+---
+type: docs
+title: "本地伪装"
+linkTitle: "本地伪装"
+weight: 26
+description: "如何在 Dubbo 中利用本地伪装实现服务降级"
+---
+
+本地伪装 [^1] 通常用于服务降级，比如某验权服务，当服务提供方全部挂掉后，客户端不抛出异常，而是通过 Mock 数据返回授权失败。
+
+在 spring 配置文件中按以下方式配置：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="true" />
+```
+
+或
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="com.foo.BarServiceMock" />
+```
+
+在工程中提供 Mock 实现 [^2]：
+
+```java
+package com.foo;
+public class BarServiceMock implements BarService {
+ public String sayHello(String name) {
+ // 你可以伪造容错数据，此方法只在出现RpcException时被执行
+ return "容错数据";
+ }
+}
+```
+
+如果服务的消费方经常需要 try-catch 捕获异常，如：
+
+```java
+Offer offer = null;
+try {
+ offer = offerService.findOffer(offerId);
+} catch (RpcException e) {
+ logger.error(e);
+}
+```
+
+请考虑改为 Mock 实现，并在 Mock 实现中 return null。如果只是想简单的忽略异常，在 `2.0.11` 以上版本可用：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="return null" />
+```
+
+## 进阶用法
+
+### return
+
+使用 `return` 来返回一个字符串表示的对象，作为 Mock 的返回值。合法的字符串可以是：
+* *empty*: 代表空，基本类型的默认值，或者集合类的空值
+* *null*: `null`
+* *true*: `true`
+* *false*: `false`
+* *JSON 格式*: 反序列化 JSON 所得到的对象
+
+### throw
+
+使用 `throw` 来返回一个 Exception 对象，作为 Mock 的返回值。
+
+当调用出错时，抛出一个默认的 RPCException:
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="throw" />
+```
+
+当调用出错时，抛出指定的 Exception：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="throw com.foo.MockException" />
+```
+
+### force 和 fail
+
+在 `2.6.6` 以上的版本，可以开始在 Spring XML 配置文件中使用 `fail:` 和 `force:`。`force:` 代表强制使用 Mock 行为，在这种情况下不会走远程调用。`fail:` 与默认行为一致，只有当远程调用发生错误时才使用 Mock 行为。`force:` 和 `fail:` 都支持与 `throw` 或者 `return` 组合使用。
+
+强制返回指定值：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="force:return fake" />
+```
+
+强制抛出指定异常：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" mock="force:throw com.foo.MockException" />
+```
+
+### 在方法级别配置 Mock
+
+Mock 可以在方法级别上指定，假定 `com.foo.BarService` 上有好几个方法，我们可以单独为 `sayHello()` 方法指定 Mock 行为。具体配置如下所示，在本例中，只要 `sayHello()` 被调用到时，强制返回 "fake":
+
+```xml
+<dubbo:reference id="demoService" check="false" interface="com.foo.BarService">
+ <dubbo:parameter key="sayHello.mock" value="force:return fake"/>
+</dubbo:reference>
+```
+
+[^1]: Mock 是 Stub 的一个子集，便于服务提供方在客户端执行容错逻辑，因经常需要在出现 RpcException (比如网络失败，超时等)时进行容错，而在出现业务异常(比如登录用户名密码错误)时不需要容错，如果用 Stub，可能就需要捕获并依赖 RpcException 类，而用 Mock 就可以不依赖 RpcException，因为它的约定就是只有出现 RpcException 时才执行。
+[^2]: 在 interface 旁放一个 Mock 实现，它实现 BarService 接口，并有一个无参构造函数
diff --git a/content/zh/docs/v3.0/references/features/local-stub.md b/content/zh/docs/v3.0/references/features/local-stub.md
new file mode 100644
index 0000000..f8c3a12
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/local-stub.md
@@ -0,0 +1,50 @@
+---
+type: docs
+title: "本地存根"
+linkTitle: "本地存根"
+weight: 25
+description: "在 Dubbo 中利用本地存根在客户端执行部分逻辑"
+---
+
+远程服务后，客户端通常只剩下接口，而实现全在服务器端，但提供方有些时候想在客户端也执行部分逻辑，比如：做 ThreadLocal 缓存，提前验证参数，调用失败后伪造容错数据等等，此时就需要在 API 中带上 Stub，客户端生成 Proxy 实例，会把 Proxy 通过构造函数传给 Stub [^1]，然后把 Stub 暴露给用户，Stub 可以决定要不要去调 Proxy。
+
+
+
+在 spring 配置文件中按以下方式配置：
+
+```xml
+<dubbo:service interface="com.foo.BarService" stub="true" />
+```
+
+或
+
+```xml
+<dubbo:service interface="com.foo.BarService" stub="com.foo.BarServiceStub" />
+```
+
+提供 Stub 的实现 [^2]：
+
+```java
+package com.foo;
+public class BarServiceStub implements BarService {
+ private final BarService barService;
+
+ // 构造函数传入真正的远程代理对象
+ public BarServiceStub(BarService barService){
+ this.barService = barService;
+ }
+
+ public String sayHello(String name) {
+ // 此代码在客户端执行, 你可以在客户端做ThreadLocal本地缓存，或预先验证参数是否合法，等等
+ try {
+ return barService.sayHello(name);
+ } catch (Exception e) {
+ // 你可以容错，可以做任何AOP拦截事项
+ return "容错数据";
+ }
+ }
+}
+```
+
+[^1]: Stub 必须有可传入 Proxy 的构造函数。
+[^2]: 在 interface 旁边放一个 Stub 实现，它实现 BarService 接口，并有一个传入远程 BarService 实例的构造函数
diff --git a/content/zh/docs/v3.0/references/features/logger-strategy.md b/content/zh/docs/v3.0/references/features/logger-strategy.md
new file mode 100644
index 0000000..4b20751
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/logger-strategy.md
@@ -0,0 +1,29 @@
+---
+type: docs
+title: "日志适配"
+linkTitle: "日志适配"
+weight: 38
+description: "在 Dubbo 中适配日志框架"
+---
+
+自 `2.2.1` 开始，dubbo 开始内置 log4j、slf4j、jcl、jdk 这些日志框架的适配[1]，也可以通过以下方式显式配置日志输出策略：
+
+0. 命令行
+
+ ```sh
+ java -Ddubbo.application.logger=log4j
+ ```
+
+0. 在 `dubbo.properties` 中指定
+
+ ```
+ dubbo.application.logger=log4j
+ ```
+
+0. 在 `dubbo.xml` 中配置
+
+ ```xml
+ <dubbo:application logger="log4j" />
+ ```
+
+[1]: 自定义扩展可以参考 [日志适配扩展](../../../dev/impls/logger-adapter)
diff --git a/content/zh/docs/v3.0/references/features/multi-protocols.md b/content/zh/docs/v3.0/references/features/multi-protocols.md
new file mode 100644
index 0000000..7f8f3ee
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/multi-protocols.md
@@ -0,0 +1,53 @@
+---
+type: docs
+title: "多协议"
+linkTitle: "多协议"
+weight: 9
+description: "在 Dubbbo 中配置多协议"
+---
+
+Dubbo 允许配置多协议，在不同服务上支持不同协议或者同一服务上同时支持多种协议。
+
+## 不同服务不同协议
+
+不同服务在性能上适用不同协议进行传输，比如大数据用短连接协议，小数据大并发用长连接协议
+
+```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="world" />
+ <dubbo:registry id="registry" address="10.20.141.150:9090" username="admin" password="hello1234" />
+ <!-- 多协议配置 -->
+ <dubbo:protocol name="dubbo" port="20880" />
+ <dubbo:protocol name="rmi" port="1099" />
+ <!-- 使用dubbo协议暴露服务 -->
+ <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" protocol="dubbo" />
+ <!-- 使用rmi协议暴露服务 -->
+ <dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" protocol="rmi" />
+</beans>
+```
+
+## 多协议暴露服务
+
+需要与 http 客户端相互操作
+
+```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="world" />
+ <dubbo:registry id="registry" address="10.20.141.150:9090" username="admin" password="hello1234" />
+ <!-- 多协议配置 -->
+ <dubbo:protocol name="dubbo" port="20880" />
+ <dubbo:protocol name="hessian" port="8080" />
+ <!-- 使用多个协议暴露服务 -->
+ <dubbo:service id="helloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" protocol="dubbo,hessian" />
+</beans>
+```
+
+[^1]: 可以自行扩展协议，参见：[协议扩展](http://dubbo.apache.org/books/dubbo-dev-book/impls/protocol.html)
diff --git a/content/zh/docs/v3.0/references/features/multi-registry.md b/content/zh/docs/v3.0/references/features/multi-registry.md
new file mode 100644
index 0000000..41e6dbe
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/multi-registry.md
@@ -0,0 +1,90 @@
+---
+type: docs
+title: "多注册中心"
+linkTitle: "多注册中心"
+weight: 10
+description: "在 Dubbo 中把同一个服务注册到多个注册中心上"
+---
+
+Dubbo 支持同一服务向多注册中心同时注册，或者不同服务分别注册到不同的注册中心上去，甚至可以同时引用注册在不同注册中心上的同名服务。另外，注册中心是支持自定义扩展的 [^1]。
+
+## 多注册中心注册
+
+比如：中文站有些服务来不及在青岛部署，只在杭州部署，而青岛的其它应用需要引用此服务，就可以将服务同时注册到两个注册中心。
+
+```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="world" />
+ <!-- 多注册中心配置 -->
+ <dubbo:registry id="hangzhouRegistry" address="10.20.141.150:9090" />
+ <dubbo:registry id="qingdaoRegistry" address="10.20.141.151:9010" default="false" />
+ <!-- 向多个注册中心注册 -->
+ <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="hangzhouRegistry,qingdaoRegistry" />
+</beans>
+```
+
+## 不同服务使用不同注册中心
+
+比如：CRM 有些服务是专门为国际站设计的，有些服务是专门为中文站设计的。
+
+
+```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="world" />
+ <!-- 多注册中心配置 -->
+ <dubbo:registry id="chinaRegistry" address="10.20.141.150:9090" />
+ <dubbo:registry id="intlRegistry" address="10.20.154.177:9010" default="false" />
+ <!-- 向中文站注册中心注册 -->
+ <dubbo:service interface="com.alibaba.hello.api.HelloService" version="1.0.0" ref="helloService" registry="chinaRegistry" />
+ <!-- 向国际站注册中心注册 -->
+ <dubbo:service interface="com.alibaba.hello.api.DemoService" version="1.0.0" ref="demoService" registry="intlRegistry" />
+</beans>
+```
+
+## 多注册中心引用
+
+比如：CRM 需同时调用中文站和国际站的 PC2 服务，PC2 在中文站和国际站均有部署，接口及版本号都一样，但连的数据库不一样。
+
+```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="world" />
+ <!-- 多注册中心配置 -->
+ <dubbo:registry id="chinaRegistry" address="10.20.141.150:9090" />
+ <dubbo:registry id="intlRegistry" address="10.20.154.177:9010" default="false" />
+ <!-- 引用中文站服务 -->
+ <dubbo:reference id="chinaHelloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" registry="chinaRegistry" />
+ <!-- 引用国际站站服务 -->
+ <dubbo:reference id="intlHelloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" registry="intlRegistry" />
+</beans>
+```
+
+如果只是测试环境临时需要连接两个不同注册中心，使用竖号分隔多个不同注册中心地址：
+
+```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="world" />
+ <!-- 多注册中心配置，竖号分隔表示同时连接多个不同注册中心，同一注册中心的多个集群地址用逗号分隔 -->
+ <dubbo:registry address="10.20.141.150:9090|10.20.154.177:9010" />
+ <!-- 引用服务 -->
+ <dubbo:reference id="helloService" interface="com.alibaba.hello.api.HelloService" version="1.0.0" />
+</beans>
+```
+
+[^1]: 可以自行扩展注册中心，参见：[注册中心扩展](../../../dev/impls/registry)
+
diff --git a/content/zh/docs/v3.0/references/features/multi-versions.md b/content/zh/docs/v3.0/references/features/multi-versions.md
new file mode 100644
index 0000000..4f744cb
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/multi-versions.md
@@ -0,0 +1,49 @@
+---
+type: docs
+title: "多版本"
+linkTitle: "多版本"
+weight: 12
+description: "在 Dubbo 中为同一个服务配置多个版本"
+---
+
+当一个接口实现，出现不兼容升级时，可以用版本号过渡，版本号不同的服务相互间不引用。
+
+可以按照以下的步骤进行版本迁移：
+
+1. 在低压力时间段，先升级一半提供者为新版本
+2. 再将所有消费者升级为新版本
+3. 然后将剩下的一半提供者升级为新版本
+
+老版本服务提供者配置：
+
+```xml
+<dubbo:service interface="com.foo.BarService" version="1.0.0" />
+```
+
+新版本服务提供者配置：
+
+```xml
+<dubbo:service interface="com.foo.BarService" version="2.0.0" />
+```
+
+老版本服务消费者配置：
+
+```xml
+<dubbo:reference id="barService" interface="com.foo.BarService" version="1.0.0" />
+```
+
+新版本服务消费者配置：
+
+```xml
+<dubbo:reference id="barService" interface="com.foo.BarService" version="2.0.0" />
+```
+
+如果不需要区分版本，可以按照以下的方式配置 [^1]：
+
+{{% alert title="提示" color="primary" %}}
+`2.2.0` 以上版本支持
+{{% /alert %}}
+
+```xml
+<dubbo:reference id="barService" interface="com.foo.BarService" version="*" />
+```
diff --git a/content/zh/docs/v3.0/references/features/netty4.md b/content/zh/docs/v3.0/references/features/netty4.md
new file mode 100644
index 0000000..482c58d
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/netty4.md
@@ -0,0 +1,46 @@
+---
+type: docs
+title: "Netty4 支持"
+linkTitle: "Netty4"
+weight: 44
+description: "在 Dubbo 中配置 Netty4"
+---
+
+Dubbo 2.5.6 版本新增了对 netty4 通信模块的支持，启用方式如下
+
+provider 端：
+```xml
+<dubbo:protocol server="netty4" />
+```
+
+或
+
+```xml
+<dubbo:provider server="netty4" />
+```
+
+consumer 端：
+```xml
+<dubbo:consumer client="netty4" />
+
+```
+
+{{% alert title="注意" color="warning" %}}
+1. provider 端如需不同的协议使用不同的通信层框架，请配置多个 protocol 分别设置
+2. consumer 端请使用如下形式：
+
+```xml
+<dubbo:consumer client="netty">
+ <dubbo:reference />
+</dubbo:consumer>
+```
+
+```xml
+<dubbo:consumer client="netty4">
+ <dubbo:reference />
+</dubbo:consumer>
+```
+
+接下来我们会继续完善： 性能测试指标及与 netty3 版本的性能测试对比，我们会提供一份参考数据
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/parameter-validation.md b/content/zh/docs/v3.0/references/features/parameter-validation.md
new file mode 100644
index 0000000..37e1210
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/parameter-validation.md
@@ -0,0 +1,193 @@
+---
+type: docs
+title: "参数验证"
+linkTitle: "参数验证"
+weight: 14
+description: "在 Dubbo 中进行参数验证"
+---
+
+参数验证功能是基于 [JSR303](https://jcp.org/en/jsr/detail?id=303) 实现的，用户只需标识 JSR303 标准的验证 annotation，并通过声明 filter 来实现验证。
+
+## Maven 依赖
+
+```xml
+<dependency>
+ <groupId>javax.validation</groupId>
+ <artifactId>validation-api</artifactId>
+ <version>1.0.0.GA</version>
+</dependency>
+<dependency>
+ <groupId>org.hibernate</groupId>
+ <artifactId>hibernate-validator</artifactId>
+ <version>4.2.0.Final</version>
+</dependency>
+```
+
+## 示例
+
+### 参数标注示例
+
+```java
+import java.io.Serializable;
+import java.util.Date;
+
+import javax.validation.constraints.Future;
+import javax.validation.constraints.Max;
+import javax.validation.constraints.Min;
+import javax.validation.constraints.NotNull;
+import javax.validation.constraints.Past;
+import javax.validation.constraints.Pattern;
+import javax.validation.constraints.Size;
+
+public class ValidationParameter implements Serializable {
+ private static final long serialVersionUID = 7158911668568000392L;
+
+ @NotNull // 不允许为空
+ @Size(min = 1, max = 20) // 长度或大小范围
+ private String name;
+
+ @NotNull(groups = ValidationService.Save.class) // 保存时不允许为空，更新时允许为空 ，表示不更新该字段
+ @Pattern(regexp = "^\\s*\\w+(?:\\.{0,1}[\\w-]+)*@[a-zA-Z0-9]+(?:[-.][a-zA-Z0-9]+)*\\.[a-zA-Z]+\\s*$")
+ private String email;
+
+ @Min(18) // 最小值
+ @Max(100) // 最大值
+ private int age;
+
+ @Past // 必须为一个过去的时间
+ private Date loginDate;
+
+ @Future // 必须为一个未来的时间
+ private Date expiryDate;
+
+ public String getName() {
+ return name;
+ }
+
+ public void setName(String name) {
+ this.name = name;
+ }
+
+ public String getEmail() {
+ return email;
+ }
+
+ public void setEmail(String email) {
+ this.email = email;
+ }
+
+ public int getAge() {
+ return age;
+ }
+
+ public void setAge(int age) {
+ this.age = age;
+ }
+
+ public Date getLoginDate() {
+ return loginDate;
+ }
+
+ public void setLoginDate(Date loginDate) {
+ this.loginDate = loginDate;
+ }
+
+ public Date getExpiryDate() {
+ return expiryDate;
+ }
+
+ public void setExpiryDate(Date expiryDate) {
+ this.expiryDate = expiryDate;
+ }
+}
+```
+
+### 分组验证示例
+
+```java
+public interface ValidationService { // 缺省可按服务接口区分验证场景，如：@NotNull(groups = ValidationService.class)
+ @interface Save{} // 与方法同名接口，首字母大写，用于区分验证场景，如：@NotNull(groups = ValidationService.Save.class)，可选
+ void save(ValidationParameter parameter);
+ void update(ValidationParameter parameter);
+}
+```
+
+### 关联验证示例
+
+```java
+import javax.validation.GroupSequence;
+
+public interface ValidationService {
+ @GroupSequence(Update.class) // 同时验证Update组规则
+ @interface Save{}
+ void save(ValidationParameter parameter);
+
+ @interface Update{}
+ void update(ValidationParameter parameter);
+}
+```
+
+### 参数验证示例
+
+```java
+import javax.validation.constraints.Min;
+import javax.validation.constraints.NotNull;
+
+public interface ValidationService {
+ void save(@NotNull ValidationParameter parameter); // 验证参数不为空
+ void delete(@Min(1) int id); // 直接对基本类型参数验证
+}
+```
+
+## 配置
+
+### 在客户端验证参数
+
+```xml
+<dubbo:reference id="validationService" interface="org.apache.dubbo.examples.validation.api.ValidationService" validation="true" />
+```
+
+### 在服务器端验证参数
+
+```xml
+<dubbo:service interface="org.apache.dubbo.examples.validation.api.ValidationService" ref="validationService" validation="true" />
+```
+
+## 验证异常信息
+
+```java
+import javax.validation.ConstraintViolationException;
+import javax.validation.ConstraintViolationException;
+
+import org.springframework.context.support.ClassPathXmlApplicationContext;
+
+import org.apache.dubbo.examples.validation.api.ValidationParameter;
+import org.apache.dubbo.examples.validation.api.ValidationService;
+import org.apache.dubbo.rpc.RpcException;
+
+public class ValidationConsumer {
+ public static void main(String[] args) throws Exception {
+ String config = ValidationConsumer.class.getPackage().getName().replace('.', '/') + "/validation-consumer.xml";
+ ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext(config);
+ context.start();
+ ValidationService validationService = (ValidationService)context.getBean("validationService");
+ // Error
+ try {
+ parameter = new ValidationParameter();
+ validationService.save(parameter);
+ System.out.println("Validation ERROR");
+ } catch (RpcException e) { // 抛出的是RpcException
+ ConstraintViolationException ve = (ConstraintViolationException) e.getCause(); // 里面嵌了一个ConstraintViolationException
+ Set<ConstraintViolation<?>> violations = ve.getConstraintViolations(); // 可以拿到一个验证错误详细信息的集合
+ System.out.println(violations);
+ }
+ }
+}
+```
+
+{{% alert title="提示" color="primary" %}}
+自 `2.1.0` 版本开始支持, 如何使用可以参考 [dubbo 项目中的示例代码](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-validation)
+
+验证方式可扩展，扩展方式参见开发者手册中的[验证扩展](../../../dev/impls/validation)
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/pb-generic-reference.md b/content/zh/docs/v3.0/references/features/pb-generic-reference.md
new file mode 100644
index 0000000..20f9e58
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/pb-generic-reference.md
@@ -0,0 +1,102 @@
+---
+type: docs
+title: "GoogleProtobuf 对象泛化调用"
+linkTitle: "Protobuf 泛化调用"
+weight: 17
+description: "对 Google Protobuf 对象进行泛化调用"
+---
+
+泛化接口调用方式主要用于客户端没有 API 接口及模型类元的情况，参考 [泛化调用](../generic-reference)。
+一般泛化调用只能用于生成的服务参数为POJO的情况，而 GoogleProtobuf 的对象是基于 Builder 生成的非正常POJO，可以通过 protobuf-json 泛化调用。
+
+GoogleProtobuf 序列化相关的Demo可以参考 [protobuf-demo](https://github.com/vio-lin/dubbo-samples/tree/protobuf-demo)
+
+## 通过Spring对Google Protobuf对象泛化调用
+
+在 Spring 中配置声明 generic = "protobuf-json"
+
+```xml
+<dubbo:reference id="barService" interface="com.foo.BarService" generic="protobuf-json" />
+```
+
+在 Java 代码获取 barService 并开始泛化调用：
+
+```java
+GenericService barService = (GenericService) applicationContext.getBean("barService");
+Object result = barService.$invoke("sayHello",new String[]{"org.apache.dubbo.protobuf.GooglePbBasic$CDubboGooglePBRequestType"}, new Object[]{"{\"double\":0.0,\"float\":0.0,\"bytesType\":\"Base64String\",\"int32\":0}"});
+```
+
+## 通过 API 方式对 Google Protobuf 对象泛化调用
+
+```java
+ReferenceConfig<GenericService> reference = new ReferenceConfig<GenericService>();
+// 弱类型接口名
+reference.setInterface(GenericService.class.getName());
+reference.setInterface("com.xxx.XxxService");
+// 声明为Protobuf-json
+reference.setGeneric(Constants.GENERIC_SERIALIZATION_PROTOBUF);
+
+GenericService genericService = reference.get();
+Map<String, Object> person = new HashMap<String, Object>();
+person.put("fixed64", "0");
+person.put("int64", "0");
+// 参考google官方的protobuf 3 的语法，服务的每个方法中只传输一个POJO对象
+// protobuf的泛化调用只允许传递一个类型为String的json对象来代表请求参数
+String requestString = new Gson().toJson(person);
+// 返回对象是GoolgeProtobuf响应对象的json字符串。
+Object result = genericService.$invoke("sayHello", new String[] {
+ "com.xxx.XxxService.GooglePbBasic$CDubboGooglePBRequestType"},
+ new Object[] {requestString});
+```
+
+## GoogleProtobuf 对象的处理
+
+GoogleProtobuf 对象是由 Protocol 契约生成,相关知识请参考 [ProtocolBuffers 文档](https://developers.google.com/protocol-buffers/?hl=zh-CN)。假如有如下Protobuf 契约
+
+```proto
+syntax = "proto3";
+package com.xxx.XxxService.GooglePbBasic.basic;
+message CDubboGooglePBRequestType {
+ double double = 1;
+ float float = 2;
+ int32 int32 = 3;
+ bool bool = 13;
+ string string = 14;
+ bytes bytesType = 15;
+}
+
+message CDubboGooglePBResponseType {
+ string msg = 1;
+}
+
+service CDubboGooglePBService {
+ rpc sayHello (CDubboGooglePBRequestType) returns (CDubboGooglePBResponseType);
+}
+```
+
+则对应请求按照如下方法构造
+
+```java
+Map<String, Object> person = new HashMap<>();
+person.put("double", "1.000");
+person.put("float", "1.00");
+person.put("int32","1" );
+person.put("bool","false" );
+//String 的对象需要经过base64编码
+person.put("string","someBaseString");
+person.put("bytesType","150");
+```
+
+## GoogleProtobuf 服务元数据解析
+
+Google Protobuf 对象缺少标准的 JSON 格式，生成的服务元数据信息存在错误。请添加如下依赖元数据解析的依赖。
+
+```xml
+<dependency>
+ <groupId>org.apache.dubbo</groupId>
+ <artifactId>dubbo-metadata-definition-protobuf</artifactId>
+ <version>${dubbo.version}</version>
+</dependency>
+```
+
+从服务元数据中也可以比较容易构建泛化调用对象。
diff --git a/content/zh/docs/v3.0/references/features/preflight-check.md b/content/zh/docs/v3.0/references/features/preflight-check.md
new file mode 100644
index 0000000..98847f3
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/preflight-check.md
@@ -0,0 +1,61 @@
+---
+type: docs
+title: "启动时检查"
+linkTitle: "启动时检查"
+weight: 1
+description: "在启动时检查依赖的服务是否可用"
+---
+
+Dubbo 缺省会在启动时检查依赖的服务是否可用，不可用时会抛出异常，阻止 Spring 初始化完成，以便上线时，能及早发现问题，默认 `check="true"`。
+
+可以通过 `check="false"` 关闭检查，比如，测试时，有些服务不关心，或者出现了循环依赖，必须有一方先启动。
+
+另外，如果你的 Spring 容器是懒加载的，或者通过 API 编程延迟引用服务，请关闭 check，否则服务临时不可用时，会抛出异常，拿到 null 引用，如果 `check="false"`，总是会返回引用，当服务恢复时，能自动连上。
+
+## 示例
+
+### 通过 spring 配置文件
+
+关闭某个服务的启动时检查 (没有提供者时报错)：
+
+```xml
+<dubbo:reference interface="com.foo.BarService" check="false" />
+```
+
+关闭所有服务的启动时检查 (没有提供者时报错)：
+
+```xml
+<dubbo:consumer check="false" />
+```
+
+关闭注册中心启动时检查 (注册订阅失败时报错)：
+
+```xml
+<dubbo:registry check="false" />
+```
+
+### 通过 dubbo.properties
+
+```properties
+dubbo.reference.com.foo.BarService.check=false
+dubbo.reference.check=false
+dubbo.consumer.check=false
+dubbo.registry.check=false
+```
+
+### 通过 -D 参数
+
+```sh
+java -Ddubbo.reference.com.foo.BarService.check=false
+java -Ddubbo.reference.check=false
+java -Ddubbo.consumer.check=false
+java -Ddubbo.registry.check=false
+```
+
+## 配置的含义
+
+`dubbo.reference.check=false`，强制改变所有 reference 的 check 值，就算配置中有声明，也会被覆盖。
+
+`dubbo.consumer.check=false`，是设置 check 的缺省值，如果配置中有显式的声明，如：`<dubbo:reference check="true"/>`，不会受影响。
+
+`dubbo.registry.check=false`，前面两个都是指订阅成功，但提供者列表是否为空是否报错，如果注册订阅失败时，也允许启动，需使用此选项，将在后台定时重试。
diff --git a/content/zh/docs/v3.0/references/features/protobuf-idl.md b/content/zh/docs/v3.0/references/features/protobuf-idl.md
new file mode 100644
index 0000000..de993ac
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/protobuf-idl.md
@@ -0,0 +1,38 @@
+---
+type: docs
+title: "Protobuf"
+linkTitle: "Protobuf"
+weight: 17
+description: "使用 IDL 定义服务"
+---
+
+当前 Dubbo 的服务定义和具体的编程语言绑定，没有提供一种语言中立的服务描述格式，比如 Java 就是定义 Interface 接口，到了其他语言又得重新以另外的格式定义一遍。
+2.7.5 版本通过支持 Protobuf IDL 实现了语言中立的服务定义。
+
+日后，不论我们使用什么语言版本来开发 Dubbo 服务，都可以直接使用 IDL 定义如下服务，具体请[参见示例](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-protobuf)
+
+```idl
+syntax = "proto3";
+
+option java_multiple_files = true;
+option java_package = "org.apache.dubbo.demo";
+option java_outer_classname = "DemoServiceProto";
+option objc_class_prefix = "DEMOSRV";
+
+package demoservice;
+
+// The demo service definition.
+service DemoService {
+ rpc SayHello (HelloRequest) returns (HelloReply) {}
+}
+
+// The request message containing the user's name.
+message HelloRequest {
+ string name = 1;
+}
+
+// The response message containing the greetings
+message HelloReply {
+ string message = 1;
+}
+```
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/reference-config-cache.md b/content/zh/docs/v3.0/references/features/reference-config-cache.md
new file mode 100644
index 0000000..37e9891
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/reference-config-cache.md
@@ -0,0 +1,43 @@
+---
+type: docs
+title: "ReferenceConfig 缓存"
+linkTitle: "ReferenceConfig 缓存"
+weight: 41
+description: "在 Dubbo 中缓存 ReferenceConfig"
+---
+
+`ReferenceConfig` 实例很重，封装了与注册中心的连接以及与提供者的连接，需要缓存。否则重复生成 `ReferenceConfig` 可能造成性能问题并且会有内存和连接泄漏。在 API 方式编程时，容易忽略此问题。
+
+因此，自 `2.4.0` 版本开始， dubbo 提供了简单的工具类 `ReferenceConfigCache`用于缓存 `ReferenceConfig` 实例。
+
+使用方式如下：
+
+```java
+ReferenceConfig<XxxService> reference = new ReferenceConfig<XxxService>();
+reference.setInterface(XxxService.class);
+reference.setVersion("1.0.0");
+......
+ReferenceConfigCache cache = ReferenceConfigCache.getCache();
+// cache.get方法中会缓存 Reference对象，并且调用ReferenceConfig.get方法启动ReferenceConfig
+XxxService xxxService = cache.get(reference);
+// 注意！ Cache会持有ReferenceConfig，不要在外部再调用ReferenceConfig的destroy方法，导致Cache内的ReferenceConfig失效！
+// 使用xxxService对象
+xxxService.sayHello();
+```
+
+消除 Cache 中的 `ReferenceConfig`，将销毁 `ReferenceConfig` 并释放对应的资源。
+
+```java
+ReferenceConfigCache cache = ReferenceConfigCache.getCache();
+cache.destroy(reference);
+```
+
+缺省 `ReferenceConfigCache` 把相同服务 Group、接口、版本的 `ReferenceConfig` 认为是相同，缓存一份。即以服务 Group、接口、版本为缓存的 Key。
+
+可以修改这个策略，在 `ReferenceConfigCache.getCache` 时，传一个 `KeyGenerator`。详见 `ReferenceConfigCache` 类的方法。
+
+```java
+KeyGenerator keyGenerator = new ...
+ReferenceConfigCache cache = ReferenceConfigCache.getCache(keyGenerator );
+```
+
diff --git a/content/zh/docs/v3.0/references/features/registry-only.md b/content/zh/docs/v3.0/references/features/registry-only.md
new file mode 100644
index 0000000..a62fefb
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/registry-only.md
@@ -0,0 +1,23 @@
+---
+type: docs
+title: "只注册"
+linkTitle: "只注册"
+weight: 41
+description: "只注册不订阅"
+---
+
+如果有两个镜像环境，两个注册中心，有一个服务只在其中一个注册中心有部署，另一个注册中心还没来得及部署，而两个注册中心的其它应用都需要依赖此服务。这个时候，可以让服务提供者方只注册服务到另一注册中心，而不从另一注册中心订阅服务。
+
+禁用订阅配置
+
+```xml
+<dubbo:registry id="hzRegistry" address="10.20.153.10:9090" />
+<dubbo:registry id="qdRegistry" address="10.20.141.150:9090" subscribe="false" />
+```
+
+或者
+
+```xml
+<dubbo:registry id="hzRegistry" address="10.20.153.10:9090" />
+<dubbo:registry id="qdRegistry" address="10.20.141.150:9090?subscribe=false" />
+```
diff --git a/content/zh/docs/v3.0/references/features/result-cache.md b/content/zh/docs/v3.0/references/features/result-cache.md
new file mode 100644
index 0000000..3a80b31
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/result-cache.md
@@ -0,0 +1,38 @@
+---
+type: docs
+title: "结果缓存"
+linkTitle: "结果缓存"
+weight: 15
+description: "通过缓存结果加速访问速度"
+---
+
+结果缓存，用于加速热门数据的访问速度，Dubbo 提供声明式缓存，以减少用户加缓存的工作量。
+
+## 缓存类型
+
+* `lru` 基于最近最少使用原则删除多余缓存，保持最热的数据被缓存。
+* `threadlocal` 当前线程缓存，比如一个页面渲染，用到很多 portal，每个 portal 都要去查用户信息，通过线程缓存，可以减少这种多余访问。
+* `jcache` 与 [JSR107](http://jcp.org/en/jsr/detail?id=107%27) 集成，可以桥接各种缓存实现。
+
+缓存类型可扩展，参见：[缓存扩展](../../../dev/impls/cache)
+
+## 配置
+
+```xml
+<dubbo:reference interface="com.foo.BarService" cache="lru" />
+```
+
+或：
+
+```xml
+<dubbo:reference interface="com.foo.BarService">
+ <dubbo:method name="findBar" cache="lru" />
+</dubbo:reference>
+```
+
+{{% alert title="提示" color="primary" %}}
+`2.1.0` 以上版本支持。
+
+[示例代码](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-cache)
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/routing-rule-deprecated.md b/content/zh/docs/v3.0/references/features/routing-rule-deprecated.md
new file mode 100644
index 0000000..ff15eac
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/routing-rule-deprecated.md
@@ -0,0 +1,199 @@
+---
+type: docs
+title: "旧路由规则"
+linkTitle: "旧路由规则"
+weight: 34
+description: "在 Dubbo `2.6.x` 版本以及更早的版本中配置路由规则"
+---
+
+路由规则 [^1] 决定一次 dubbo 服务调用的目标服务器，分为条件路由规则和脚本路由规则，并且支持可扩展 [^2]。
+
+## 写入路由规则
+
+向注册中心写入路由规则的操作通常由监控中心或治理中心的页面完成
+
+```java
+RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
+Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
+registry.register(URL.valueOf("route://0.0.0.0/com.foo.BarService?category=routers&dynamic=false&rule=" + URL.encode("host = 10.20.153.10 => host = 10.20.153.11")));
+```
+
+其中：
+
+* `route://` 表示路由规则的类型，支持条件路由规则和脚本路由规则，可扩展，**必填**。
+* `0.0.0.0` 表示对所有 IP 地址生效，如果只想对某个 IP 的生效，请填入具体 IP，**必填**。
+* `com.foo.BarService` 表示只对指定服务生效，**必填**。
+* `group=foo` 对指定服务的指定group生效，不填表示对未配置group的指定服务生效
+* `version=1.0`对指定服务的指定version生效，不填表示对未配置version的指定服务生效
+* `category=routers` 表示该数据为动态配置类型，**必填**。
+* `dynamic=false` 表示该数据为持久数据，当注册方退出时，数据依然保存在注册中心，**必填**。
+* `enabled=true` 覆盖规则是否生效，可不填，缺省生效。
+* `force=false` 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 `false`。
+* `runtime=false` 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 `true`，需要注意设置会影响调用的性能，可不填，缺省为 `false`。
+* `priority=1` 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 `0`。
+* `rule=URL.encode("host = 10.20.153.10 => host = 10.20.153.11")` 表示路由规则的内容，**必填**。
+
+## 条件路由规则
+
+基于条件表达式的路由规则，如：`host = 10.20.153.10 => host = 10.20.153.11`
+
+### 规则：
+
+* `=>` 之前的为消费者匹配条件，所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
+* `=>` 之后为提供者地址列表的过滤条件，所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。
+* 如果匹配条件为空，表示对所有消费方应用，如：`=> host != 10.20.153.11`
+* 如果过滤条件为空，表示禁止访问，如：`host = 10.20.153.10 =>`
+
+### 表达式：
+
+参数支持：
+
+* 服务调用信息，如：method, argument 等，暂不支持参数路由
+* URL 本身的字段，如：protocol, host, port 等
+* 以及 URL 上的所有参数，如：application, organization 等
+
+条件支持：
+
+* 等号 `=` 表示"匹配"，如：`host = 10.20.153.10`
+* 不等号 `!=` 表示"不匹配"，如：`host != 10.20.153.10`
+
+值支持：
+
+* 以逗号 `,` 分隔多个值，如：`host != 10.20.153.10,10.20.153.11`
+* 以星号 `*` 结尾，表示通配，如：`host != 10.20.*`
+* 以美元符 `$` 开头，表示引用消费者参数，如：`host = $host`
+
+### 示例：
+
+0. 排除预发布机：
+
+ ```
+ => host != 172.22.3.91
+ ```
+1. 白名单 [^3]：
+
+ ```
+ host != 10.20.153.10,10.20.153.11 =>
+ ```
+2. 黑名单：
+
+ ```
+ host = 10.20.153.10,10.20.153.11 =>
+ ```
+3. 服务寄宿在应用上，只暴露一部分的机器，防止整个集群挂掉：
+
+ ```
+ => host = 172.22.3.1*,172.22.3.2*
+ ```
+4. 为重要应用提供额外的机器：
+
+ ```
+ application != kylin => host != 172.22.3.95,172.22.3.96
+ ```
+5. 读写分离：
+
+ ```
+ method = find*,list*,get*,is* => host = 172.22.3.94,172.22.3.95,172.22.3.96
+ method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98
+ ```
+
+6. 前后台分离：
+
+ ```
+ application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93
+ application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96
+ ```
+
+7. 隔离不同机房网段：
+
+ ```
+ host != 172.22.3.* => host != 172.22.3.*
+ ```
+
+8. 提供者与消费者部署在同集群内，本机只访问本机的服务：
+
+ ```
+ => host = $host
+ ```
+
+## 脚本路由规则
+
+脚本路由规则 [^4] 支持 JDK 脚本引擎的所有脚本，比如：javascript, jruby, groovy 等，通过 `type=javascript` 参数设置脚本类型，缺省为 javascript。
+
+
+```
+"script://0.0.0.0/com.foo.BarService?category=routers&dynamic=false&rule=" + URL.encode("（function route(invokers) { ... } (invokers)）")
+```
+
+基于脚本引擎的路由规则，如：
+
+```javascript
+（function route(invokers) {
+ var result = new java.util.ArrayList(invokers.size());
+ for (i = 0; i < invokers.size(); i ++) {
+ if ("10.20.153.10".equals(invokers.get(i).getUrl().getHost())) {
+ result.add(invokers.get(i));
+ }
+ }
+ return result;
+} (invokers)）; // 表示立即执行方法
+```
+
+## 标签路由规则
+
+标签路由规则 [^5] ，当应用选择装配标签路由(TagRouter)之后，一次 dubbo 调用能够根据请求携带的 tag 标签智能地选择对应 tag 的服务提供者进行调用。
+
+### 服务提供者
+
+1. 给应用装配标签路由器：
+
+```Java
+@Bean
+public ApplicationConfig applicationConfig() {
+ ApplicationConfig applicationConfig = new ApplicationConfig();
+ applicationConfig.setName("provider-book");
+ applicationConfig.setQosEnable(false);
+ // instruct tag router
+ Map<String,String> parameters = new HashMap<>();
+ parameters.put(Constants.ROUTER_KEY, "tag");
+ applicationConfig.setParameters(parameters);
+ return applicationConfig;
+}
+```
+
+2. 给应用设置具体的标签：
+
+```java
+@Bean
+public ProviderConfig providerConfig(){
+ ProviderConfig providerConfig = new ProviderConfig();
+ providerConfig.setTag("red");
+ return providerConfig;
+}
+```
+
+应用未装配 tag 属性或服务提供者未设置 tag 属性，都将被认为是默认的应用，这些默认应用将会在调用无法匹配 provider 时当作降级方案。
+
+### 服务消费者
+
+```Java
+RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"red");
+```
+
+请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。
+
+> 目前仅仅支持 hardcoding 的方式设置 requestTag。注意到 RpcContext 是线程绑定的，优雅的使用 TagRouter 特性，建议通过 servlet 过滤器(在 web 环境下)，或者定制的 SPI 过滤器设置 requestTag。
+
+### 规则描述
+
+1. request.tag=red 时优先选择 tag=red 的 provider。若集群中不存在与请求标记对应的服务，可以降级请求 tag=null 的 provider，即默认 provider。
+
+2. request.tag=null 时，只会匹配 tag=null 的 provider。即使集群中存在可用的服务，若 tag 不匹配就无法调用，这与规则1不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。
+
+
+
+[^1]: `2.2.0` 以上版本支持
+[^2]: 路由规则扩展点：[路由扩展](../../../dev/impls/router)
+[^3]: 注意：一个服务只能有一条白名单规则，否则两条规则交叉，就都被筛选掉了
+[^4]: 注意：脚本没有沙箱约束，可执行任意代码，存在后门风险
+[^5]: 该特性在 `2.7.0` 以上版本支持
diff --git a/content/zh/docs/v3.0/references/features/routing-rule.md b/content/zh/docs/v3.0/references/features/routing-rule.md
new file mode 100644
index 0000000..9313109
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/routing-rule.md
@@ -0,0 +1,257 @@
+---
+type: docs
+title: "路由规则"
+linkTitle: "路由规则"
+weight: 33
+description: "通过 Dubbo 中的路由规则做服务治理"
+---
+
+路由规则在发起一次RPC调用前起到过滤目标服务器地址的作用，过滤后的地址列表，将作为消费端最终发起RPC调用的备选地址。
+
+- 条件路由。支持以服务或 Consumer 应用为粒度配置路由规则。
+- 标签路由。以 Provider 应用为粒度配置路由规则。
+
+后续我们计划在 2.6.x 版本的基础上继续增强脚本路由功能。
+
+## 条件路由
+
+您可以随时在服务治理控制台 [Dubbo-Admin](https://github.com/apache/dubbo-admin) 写入路由规则
+
+### 简介
+
+- 应用粒度
+
+ ```yaml
+ # app1的消费者只能消费所有端口为20880的服务实例
+ # app2的消费者只能消费所有端口为20881的服务实例
+ ---
+ scope: application
+ force: true
+ runtime: true
+ enabled: true
+ key: governance-conditionrouter-consumer
+ conditions:
+ - application=app1 => address=*:20880
+ - application=app2 => address=*:20881
+ ...
+ ```
+
+- 服务粒度
+
+ ```yaml
+ # DemoService的sayHello方法只能消费所有端口为20880的服务实例
+ # DemoService的sayHi方法只能消费所有端口为20881的服务实例
+ ---
+ scope: service
+ force: true
+ runtime: true
+ enabled: true
+ key: org.apache.dubbo.samples.governance.api.DemoService
+ conditions:
+ - method=sayHello => address=*:20880
+ - method=sayHi => address=*:20881
+ ...
+ ```
+
+
+
+### 规则详解
+
+#### 各字段含义
+
+- `scope`表示路由规则的作用粒度，scope的取值会决定key的取值。**必填**。
+ - service 服务粒度
+ - application 应用粒度
+- `Key`明确规则体作用在哪个服务或应用。**必填**。
+ - scope=service时，key取值为[{group}:]{service}[:{version}]的组合
+ - scope=application时，key取值为application名称
+- `enabled=true` 当前路由规则是否生效，可不填，缺省生效。
+- `force=false` 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 `false`。
+- `runtime=false` 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 `true`，需要注意设置会影响调用的性能，可不填，缺省为 `false`。
+- `priority=1` 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 `0`。
+- `conditions` 定义具体的路由规则内容。**必填**。
+
+#### Conditions规则体
+
+ `conditions`部分是规则的主体，由1到任意多条规则组成，下面我们就每个规则的配置语法做详细说明：
+
+1. **格式**
+
+- `=>` 之前的为消费者匹配条件，所有参数和消费者的 URL 进行对比，当消费者满足匹配条件时，对该消费者执行后面的过滤规则。
+- `=>` 之后为提供者地址列表的过滤条件，所有参数和提供者的 URL 进行对比，消费者最终只拿到过滤后的地址列表。
+- 如果匹配条件为空，表示对所有消费方应用，如：`=> host != 10.20.153.11`
+- 如果过滤条件为空，表示禁止访问，如：`host = 10.20.153.10 =>`
+
+2. **表达式**
+
+参数支持：
+
+- 服务调用信息，如：method, argument 等，暂不支持参数路由
+- URL 本身的字段，如：protocol, host, port 等
+- 以及 URL 上的所有参数，如：application, organization 等
+
+条件支持：
+
+- 等号 `=` 表示"匹配"，如：`host = 10.20.153.10`
+- 不等号 `!=` 表示"不匹配"，如：`host != 10.20.153.10`
+
+值支持：
+
+- 以逗号 `,` 分隔多个值，如：`host != 10.20.153.10,10.20.153.11`
+- 以星号 `*` 结尾，表示通配，如：`host != 10.20.*`
+- 以美元符 `$` 开头，表示引用消费者参数，如：`host = $host`
+
+3. **Condition示例**
+
+- 排除预发布机：
+
+```
+=> host != 172.22.3.91
+```
+
+- 白名单：
+
+```
+register.ip != 10.20.153.10,10.20.153.11 =>
+```
+
+{{% alert title="注意" color="warning" %}}
+一个服务只能有一条白名单规则，否则两条规则交叉，就都被筛选掉了
+{{% /alert %}}
+
+- 黑名单：
+
+```
+register.ip = 10.20.153.10,10.20.153.11 =>
+```
+
+- 服务寄宿在应用上，只暴露一部分的机器，防止整个集群挂掉：
+
+```
+=> host = 172.22.3.1*,172.22.3.2*
+```
+
+- 为重要应用提供额外的机器：
+
+```
+application != kylin => host != 172.22.3.95,172.22.3.96
+```
+
+- 读写分离：
+
+```
+method = find*,list*,get*,is* => host = 172.22.3.94,172.22.3.95,172.22.3.96
+method != find*,list*,get*,is* => host = 172.22.3.97,172.22.3.98
+```
+
+- 前后台分离：
+
+```
+application = bops => host = 172.22.3.91,172.22.3.92,172.22.3.93
+application != bops => host = 172.22.3.94,172.22.3.95,172.22.3.96
+```
+
+- 隔离不同机房网段：
+
+```
+host != 172.22.3.* => host != 172.22.3.*
+```
+
+- 提供者与消费者部署在同集群内，本机只访问本机的服务：
+
+```
+=> host = $host
+```
+
+
+
+## 标签路由规则
+
+### 简介
+
+标签路由通过将某一个或多个服务的提供者划分到同一个分组，约束流量只在指定分组中流转，从而实现流量隔离的目的，可以作为蓝绿发布、灰度发布等场景的能力基础。
+
+#### Provider
+
+标签主要是指对Provider端应用实例的分组，目前有两种方式可以完成实例分组，分别是`动态规则打标`和`静态规则打标`，其中动态规则相较于静态规则优先级更高，而当两种规则同时存在且出现冲突时，将以动态规则为准。
+
+- 动态规则打标，可随时在**服务治理控制台**下发标签归组规则
+
+ ```yaml
+ # governance-tagrouter-provider应用增加了两个标签分组tag1和tag2
+ # tag1包含一个实例 127.0.0.1:20880
+ # tag2包含一个实例 127.0.0.1:20881
+ ---
+ force: false
+ runtime: true
+ enabled: true
+ key: governance-tagrouter-provider
+ tags:
+ - name: tag1
+ addresses: ["127.0.0.1:20880"]
+ - name: tag2
+ addresses: ["127.0.0.1:20881"]
+ ...
+ ```
+
+
+
+- 静态打标
+
+ ```xml
+ <dubbo:provider tag="tag1"/>
+ ```
+
+ or
+
+ ```xml
+ <dubbo:service tag="tag1"/>
+ ```
+
+ or
+
+ ```properties
+ java -jar xxx-provider.jar -Ddubbo.provider.tag={the tag you want, may come from OS ENV}
+ ```
+
+
+
+#### Consumer
+
+```java
+RpcContext.getContext().setAttachment(Constants.REQUEST_TAG_KEY,"tag1");
+```
+
+请求标签的作用域为每一次 invocation，使用 attachment 来传递请求标签，注意保存在 attachment 中的值将会在一次完整的远程调用中持续传递，得益于这样的特性，我们只需要在起始调用时，通过一行代码的设置，达到标签的持续传递。
+
+> 目前仅仅支持 hardcoding 的方式设置 requestTag。注意到 RpcContext 是线程绑定的，优雅的使用 TagRouter 特性，建议通过 servlet 过滤器(在 web 环境下)，或者定制的 SPI 过滤器设置 requestTag。
+
+
+
+### 规则详解
+
+#### 格式
+
+- `Key`明确规则体作用到哪个应用。**必填**。
+- `enabled=true` 当前路由规则是否生效，可不填，缺省生效。
+- `force=false` 当路由结果为空时，是否强制执行，如果不强制执行，路由结果为空的路由规则将自动失效，可不填，缺省为 `false`。
+- `runtime=false` 是否在每次调用时执行路由规则，否则只在提供者地址列表变更时预先执行并缓存结果，调用时直接从缓存中获取路由结果。如果用了参数路由，必须设为 `true`，需要注意设置会影响调用的性能，可不填，缺省为 `false`。
+- `priority=1` 路由规则的优先级，用于排序，优先级越大越靠前执行，可不填，缺省为 `0`。
+- `tags` 定义具体的标签分组内容，可定义任意n（n>=1）个标签并为每个标签指定实例列表。**必填**。
+ - name， 标签名称
+- addresses， 当前标签包含的实例列表
+
+
+
+#### 降级约定
+
+1. `request.tag=tag1` 时优先选择 标记了`tag=tag1` 的 provider。若集群中不存在与请求标记对应的服务，默认将降级请求 tag为空的provider；如果要改变这种默认行为，即找不到匹配tag1的provider返回异常，需设置`request.tag.force=true`。
+
+2. `request.tag`未设置时，只会匹配tag为空的provider。即使集群中存在可用的服务，若 tag 不匹配也就无法调用，这与约定1不同，携带标签的请求可以降级访问到无标签的服务，但不携带标签/携带其他种类标签的请求永远无法访问到其他标签的服务。
+
+{{% alert title="提示" color="primary" %}}
+`2.6.x` 版本以及更早的版本请使用[老版本路由规则](../routing-rule-deprecated)
+
+自定义路由参考[路由扩展](../../../dev/impls/router)
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/serialization.md b/content/zh/docs/v3.0/references/features/serialization.md
new file mode 100644
index 0000000..efe1880
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/serialization.md
@@ -0,0 +1,85 @@
+---
+type: docs
+title: "Kryo 和 FST 序列化"
+linkTitle: "Kryo 和 FST 序列化"
+weight: 44
+description: "在 Dubbo 中使用高效的 Java 序列化（Kryo 和 FST）"
+---
+
+## 启用 Kryo 和 FST
+
+使用 Kryo 和 FST 非常简单，只需要在 dubbo RPC 的 XML 配置中添加一个属性即可：
+
+```xml
+<dubbo:protocol name="dubbo" serialization="kryo"/>
+```
+
+```xml
+<dubbo:protocol name="dubbo" serialization="fst"/>
+```
+
+## 注册被序列化类
+
+要让 Kryo 和 FST 完全发挥出高性能，最好将那些需要被序列化的类注册到 dubbo 系统中，例如，我们可以实现如下回调接口：
+
+```java
+public class SerializationOptimizerImpl implements SerializationOptimizer {
+
+ public Collection<Class> getSerializableClasses() {
+ List<Class> classes = new LinkedList<Class>();
+ classes.add(BidRequest.class);
+ classes.add(BidResponse.class);
+ classes.add(Device.class);
+ classes.add(Geo.class);
+ classes.add(Impression.class);
+ classes.add(SeatBid.class);
+ return classes;
+ }
+}
+```
+
+然后在 XML 配置中添加：
+
+```xml
+<dubbo:protocol name="dubbo" serialization="kryo" optimizer="org.apache.dubbo.demo.SerializationOptimizerImpl"/>
+```
+
+在注册这些类后，序列化的性能可能被大大提升，特别针对小数量的嵌套对象的时候。
+
+当然，在对一个类做序列化的时候，可能还级联引用到很多类，比如Java集合类。针对这种情况，我们已经自动将JDK中的常用类进行了注册，所以你不需要重复注册它们（当然你重复注册了也没有任何影响），包括：
+
+```
+GregorianCalendar
+InvocationHandler
+BigDecimal
+BigInteger
+Pattern
+BitSet
+URI
+UUID
+HashMap
+ArrayList
+LinkedList
+HashSet
+TreeSet
+Hashtable
+Date
+Calendar
+ConcurrentHashMap
+SimpleDateFormat
+Vector
+BitSet
+StringBuffer
+StringBuilder
+Object
+Object[]
+String[]
+byte[]
+char[]
+int[]
+float[]
+double[]
+```
+
+由于注册被序列化的类仅仅是出于性能优化的目的，所以即使你忘记注册某些类也没有关系。事实上，即使不注册任何类，Kryo和FST的性能依然普遍优于 hessian 和 dubbo 序列化。
+
diff --git a/content/zh/docs/v3.0/references/features/service-container.md b/content/zh/docs/v3.0/references/features/service-container.md
new file mode 100644
index 0000000..2e6c2ab
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/service-container.md
@@ -0,0 +1,67 @@
+---
+type: docs
+title: "服务容器"
+linkTitle: "服务容器"
+weight: 40
+description: "使用 Dubbo 中的服务容器"
+---
+
+服务容器是一个 standalone 的启动程序，因为后台服务不需要 Tomcat 或 JBoss 等 Web 容器的功能，如果硬要用 Web 容器去加载服务提供方，增加复杂性，也浪费资源。
+
+服务容器只是一个简单的 Main 方法，并加载一个简单的 Spring 容器，用于暴露服务。
+
+服务容器的加载内容可以扩展，内置了 spring, jetty, log4j 等加载，可通过[容器扩展点](../../../dev/impls/container)进行扩展。配置配在 java 命令的 -D 参数或者 `dubbo.properties` 中。
+
+## 容器类型
+
+### Spring Container
+
+* 自动加载 `META-INF/spring` 目录下的所有 Spring 配置。
+* 配置 spring 配置加载位置：
+
+ ```properties
+ dubbo.spring.config=classpath*:META-INF/spring/*.xml
+ ```
+
+### Jetty Container
+
+* 启动一个内嵌 Jetty，用于汇报状态。
+* 配置：
+ * `dubbo.jetty.port=8080`：配置 jetty 启动端口
+ * `dubbo.jetty.directory=/foo/bar`：配置可通过 jetty 直接访问的目录，用于存放静态文件
+ * `dubbo.jetty.page=log,status,system`：配置显示的页面，缺省加载所有页面
+
+
+### Log4j Container
+
+* 自动配置 log4j 的配置，在多进程启动时，自动给日志文件按进程分目录。
+* 配置：
+ * `dubbo.log4j.file=/foo/bar.log`：配置日志文件路径
+ * `dubbo.log4j.level=WARN`：配置日志级别
+ * `dubbo.log4j.subdirectory=20880`：配置日志子目录，用于多进程启动，避免冲突
+
+## 容器启动
+
+缺省只加载 spring
+
+```sh
+java org.apache.dubbo.container.Main
+```
+
+通过 main 函数参数传入要加载的容器
+
+```sh
+java org.apache.dubbo.container.Main spring jetty log4j
+```
+
+通过 JVM 启动参数传入要加载的容器
+
+```sh
+java org.apache.dubbo.container.Main -Ddubbo.container=spring,jetty,log4j
+```
+
+通过 classpath 下的 `dubbo.properties` 配置传入要加载的容器
+
+```
+dubbo.container=spring,jetty,log4j
+```
diff --git a/content/zh/docs/v3.0/references/features/service-downgrade.md b/content/zh/docs/v3.0/references/features/service-downgrade.md
new file mode 100644
index 0000000..170e0ae
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/service-downgrade.md
@@ -0,0 +1,27 @@
+---
+type: docs
+title: "服务降级"
+linkTitle: "服务降级"
+weight: 35
+description: "降级 Dubbo 服务"
+---
+
+可以通过服务降级功能临时屏蔽某个出错的非关键服务，并定义降级后的返回策略。
+
+向注册中心写入动态配置覆盖规则：
+
+```java
+RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
+Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
+registry.register(URL.valueOf("override://0.0.0.0/com.foo.BarService?category=configurators&dynamic=false&application=foo&mock=force:return+null"));
+```
+
+其中：
+
+* `mock=force:return+null` 表示消费方对该服务的方法调用都直接返回 null 值，不发起远程调用。用来屏蔽不重要服务不可用时对调用方的影响。
+* 还可以改为 `mock=fail:return+null` 表示消费方对该服务的方法调用在失败后，再返回 null 值，不抛异常。用来容忍不重要服务不稳定时对调用方的影响。
+
+{{% alert title="提示" color="primary" %}}
+`2.2.0` 以上版本支持
+{{% /alert %}}
+
diff --git a/content/zh/docs/v3.0/references/features/service-group.md b/content/zh/docs/v3.0/references/features/service-group.md
new file mode 100644
index 0000000..ebde09e
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/service-group.md
@@ -0,0 +1,33 @@
+---
+type: docs
+title: "服务分组"
+linkTitle: "服务分组"
+weight: 11
+description: "使用服务分组区分服务接口的不同实现"
+---
+
+当一个接口有多种实现时，可以用 group 区分。
+
+## 服务
+
+```xml
+<dubbo:service group="feedback" interface="com.xxx.IndexService" />
+<dubbo:service group="member" interface="com.xxx.IndexService" />
+```
+
+## 引用
+
+```xml
+<dubbo:reference id="feedbackIndexService" group="feedback" interface="com.xxx.IndexService" />
+<dubbo:reference id="memberIndexService" group="member" interface="com.xxx.IndexService" />
+```
+
+任意组：
+
+```xml
+<dubbo:reference id="barService" interface="com.foo.BarService" group="*" />
+```
+
+{{% alert title="提示" color="primary" %}}
+`2.2.0` 以上版本支持，总是只调一个可用组的实现
+{{% /alert %}}
diff --git a/content/zh/docs/v3.0/references/features/set-host.md b/content/zh/docs/v3.0/references/features/set-host.md
new file mode 100644
index 0000000..6a2aff4
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/set-host.md
@@ -0,0 +1,75 @@
+---
+type: docs
+title: "主机配置"
+linkTitle: "主机配置"
+weight: 37
+description: "自定义 Dubbo 服务对外暴露的主机地址"
+---
+
+## 背景
+
+在 Dubbo 中， Provider 启动时主要做两个事情，一是启动 server，二是向注册中心注册服务。启动 server 时需要绑定 socket，向注册中心注册服务时也需要发送 socket 唯一标识服务地址。
+
+1. `dubbo`中不设置`host`时默认`host`是什么?
+2. 那在`dubbo`中如何指定服务的`host`,我们是否可以用hostname或domain代替IP地址作为`host`?
+3. 在使用docker时,有时需要设置端口映射,此时,启动server时绑定的socket和向注册中心注册的socket使用不同的端口号,此时又该如何设置?
+
+#### dubbo 中不设置 host 时默认 host 是什么
+
+一般的 dubbo 协议配置如下:
+``` xml
+ ...
+ <dubbo:protocol name="dubbo" port="20890" />
+ ...
+```
+
+可以看到,只配置了端口号,没有配置 host，此时设置的 host 又是什么呢?
+
+查看代码发现,在 `org.apache.dubbo.config.ServiceConfig#findConfigedHosts()` 中,通过 `InetAddress.getLocalHost().getHostAddress()` 获取默认 host。其返回值如下：
+
+1. 未联网时，返回 127.0.0.1
+2. 在阿里云服务器中，返回私有地址,如: 172.18.46.234
+3. 在本机测试时，返回公有地址，如: 30.5.10.11
+
+#### 那在 dubbo 中如何指定服务的 socket?
+
+除此之外,可以通过 `dubbo.protocol` 或 `dubbo.provider `的 `host` 属性对 `host` 进行配置,支持IP地址和域名,如下:
+
+``` xml
+ ...
+ <dubbo:protocol name="dubbo" port="20890" host="www.example.com"/>
+ ...
+```
+
+#### 在使用 docker 时，有时需要设置端口映射，此时，启动 server 时绑定的 socket 和向注册中心注册的 socket 使用不同的端口号，此时又该如何设置？
+
+见 [dubbo 通过环境变量设置 host](https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-docker)
+
+有些部署场景需要动态指定服务注册的地址，如 docker bridge 网络模式下要指定注册宿主机 ip 以实现外网通信。dubbo 提供了两对启动阶段的系统属性，用于设置对外通信的ip、port地址。
+
+* DUBBO_IP_TO_REGISTRY --- 注册到注册中心的ip地址
+* DUBBO_PORT_TO_REGISTRY --- 注册到注册中心的port端口
+* DUBBO_IP_TO_BIND --- 监听ip地址
+* DUBBO_PORT_TO_BIND --- 监听port端口
+
+以上四个配置项均为可选项，如不配置 dubbo 会自动获取 ip 与端口，请根据具体的部署场景灵活选择配置。
+dubbo 支持多协议，如果一个应用同时暴露多个不同协议服务，且需要为每个服务单独指定 ip 或 port，请分别在以上属性前加协议前缀。 如：
+
+* HESSIAN_DUBBO_PORT_TO_BIND hessian协议绑定的port
+* DUBBO_DUBBO_PORT_TO_BIND dubbo协议绑定的port
+* HESSIAN_DUBBO_IP_TO_REGISTRY hessian协议注册的ip
+* DUBBO_DUBBO_PORT_TO_BIND dubbo协议注册的ip
+
+PORT_TO_REGISTRY 或 IP_TO_REGISTRY 不会用作默认 PORT_TO_BIND 或 IP_TO_BIND，但是反过来是成立的
+如设置 PORT_TO_REGISTRY=20881 IP_TO_REGISTRY=30.5.97.6，则 PORT_TO_BIND IP_TO_BIND 不受影响
+如果设置 PORT_TO_BIND=20881 IP_TO_BIND=30.5.97.6，则默认 PORT_TO_REGISTRY=20881 IP_TO_REGISTRY=30.5.97.6
+
+## 总结
+
+ 1. 可以通过`dubbo.protocol`或`dubbo.provider`的`host`属性对`host`进行配置,支持IP地址和域名.但此时注册到注册中心的IP地址和监听IP地址是同一个值
+ 2. 为了解决在虚拟环境或局域网内consumer无法与provider通信的问题,可以通过环境变量分别设置注册到注册中心的IP地址和监听IP地址,其优先级高于`dubbo.protocol`或`dubbo.provider`的`host`配置
+
+## 参考
+
+ 1. [Proposal: support hostname or domain in service discovery.](https://github.com/apache/dubbo/issues/2043)
+ 2. [dubbo通过环境变量设置host](https://github.com/dubbo/dubbo-samples/tree/master/dubbo-samples-docker)
diff --git a/content/zh/docs/v3.0/references/features/simplify-registry-data.md b/content/zh/docs/v3.0/references/features/simplify-registry-data.md
new file mode 100644
index 0000000..65f41e7
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/simplify-registry-data.md
@@ -0,0 +1,262 @@
+---
+type: docs
+title: "注册信息简化"
+linkTitle: "注册信息简化"
+weight: 37
+description: "减少注册中心上服务的注册数据"
+---
+
+## 背景
+
+Dubbo provider 中的服务配置项有接近 [30 个配置项](http://dubbo.apache.org/en-us/docs/user/references/xml/dubbo-service.html)。 排除注册中心服务治理需要之外，很大一部分配置项是 provider 自己使用，不需要透传给消费者。这部分数据不需要进入注册中心，而只需要以 key-value 形式持久化存储。
+
+Dubbo consumer 中的配置项也有 [20+个配置项](http://dubbo.apache.org/en-us/docs/user/references/xml/dubbo-reference.html)。在注册中心之中，服务消费者列表中只需要关注 application，version，group，ip，dubbo 版本等少量配置，其他配置也可以以 key-value 形式持久化存储。
+
+这些数据是以服务为维度注册进入注册中心，导致了数据量的膨胀，进而引发注册中心(如 zookeeper)的网络开销增大，性能降低。
+
+## 现有功能 sample
+
+当前现状一个简单展示。通过这个展示，分析下为什么需要做简化配置。
+
+参考 sample 子工程： dubbo-samples-simplified-registry/dubbo-samples-simplified-registry-nosimple （跑 sample 前，先跑下 ZKClean 进行配置项清理）
+
+dubbo-provider.xml配置
+
+```
+<dubbo:application name="simplified-registry-nosimple-provider"/>
+<dubbo:registry address="zookeeper://127.0.0.1:2181"/>
+<bean id="demoService" class="org.apache.dubbo.samples.simplified.registry.nosimple.impl.DemoServiceImpl"/>
+<dubbo:service async="true" interface="org.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService"
+ version="1.2.3" group="dubbo-simple" ref="demoService"
+ executes="4500" retries="7" owner="vict" timeout="5300"/>
+```
+
+启动 provider 的 main 方法之后，查看 zookeeper 的叶子节点（路径为：/dubbo/org.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService/providers 目录下）的内容如下：
+
+```
+dubbo%3A%2F%2F30.5.124.158%3A20880%2Forg.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService
+%3Fanyhost%3Dtrue%26application%3Dsimplified-registry-xml-provider%26async%3Dtrue%26dubbo%3D
+2.0.2%26**executes**%3D4500%26generic%3Dfalse%26group%3Ddubbo-simple%26interface%3D
+org.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService%26methods%3D
+sayHello%26**owner**%3Dvict%26pid%3D2767%26**retries**%3D7%26revision%3D1.2.3%26side%3D
+provider%26**timeout**%3D5300%26timestamp%3D1542361152795%26valid%3Dtrue%26version%3D1.2.3
+```
+
+从加粗字体中能看到有：executes, retries, owner, timeout。但是这些字段不是每个都需要传递给 dubbo ops 或者 dubbo consumer。 同样的，consumer 也有这个问题，可以在例子中启动 Consumer 的 main 方法进行查看。
+
+## 设计目标和宗旨
+
+期望简化进入注册中心的 provider 和 consumer 配置数量。
+期望将部分配置项以其他形式存储。这些配置项需要满足：不在服务调用链路上，同时这些配置项不在注册中心的核心链路上(服务查询，服务列表)。
+
+## 配置
+
+简化注册中心的配置，只在 2.7 之后的版本中进行支持。
+开启 provider 或者 consumer 简化配置之后，默认保留的配置项如下：
+
+provider：
+
+| Constant Key | Key | remark |
+| ------ | ------ | ------ |
+| APPLICATION_KEY | application | |
+| CODEC_KEY | codec | |
+| EXCHANGER_KEY | exchanger | |
+| SERIALIZATION_KEY | serialization | |
+| CLUSTER_KEY | cluster | |
+| CONNECTIONS_KEY | connections | |
+| DEPRECATED_KEY | deprecated | |
+| GROUP_KEY | group | |
+| LOADBALANCE_KEY | loadbalance | |
+| MOCK_KEY | mock | |
+| PATH_KEY | path | |
+| TIMEOUT_KEY | timeout | |
+| TOKEN_KEY | token | |
+| VERSION_KEY | version | |
+| WARMUP_KEY | warmup | |
+| WEIGHT_KEY | weight | |
+| TIMESTAMP_KEY | timestamp | |
+| DUBBO_VERSION_KEY | dubbo | |
+| SPECIFICATION_VERSION_KEY | **specVersion** | 新增，用于表述dubbo版本，如2.7.0 |
+
+
+consumer：
+
+| Constant Key | Key | remark |
+| ------ | ------ | ------ |
+| APPLICATION_KEY | application | |
+| VERSION_KEY | version | |
+| GROUP_KEY | group | |
+| DUBBO_VERSION_KEY | dubbo | |
+| SPECIFICATION_VERSION_KEY | **specVersion** | 新增，用于表述dubbo版本，如2.7.0 |
+
+Constant Key 表示来自于类 org.apache.dubbo.common.Constants 的字段。
+
+下面介绍几种常用的使用方式。所有的 sample，都可以查看[sample-2.7](https://github.com/dubbo/dubbo-samples/tree/master)
+
+### 方式1. 配置dubbo.properties
+
+sample 在 dubbo-samples-simplified-registry/dubbo-samples-simplified-registry-xml 工程下 （跑 sample 前，先跑下ZKClean 进行配置项清理）
+
+dubbo.properties
+
+```properties
+
+dubbo.registry.simplified=true
+dubbo.registry.extra-keys=retries,owner
+```
+
+怎么去验证呢？
+
+##### provider端验证
+
+provider端配置
+
+```xml
+<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
+ xmlns="http://www.springframework.org/schema/beans"
+ 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">
+ <!-- optional -->
+ <dubbo:application name="simplified-registry-xml-provider"/>
+ <dubbo:registry address="zookeeper://127.0.0.1:2181"/>
+ <bean id="demoService" class="org.apache.dubbo.samples.simplified.registry.nosimple.impl.DemoServiceImpl"/>
+ <dubbo:service async="true" interface="org.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService" version="1.2.3" group="dubbo-simple"
+ ref="demoService" executes="4500" retries="7" owner="vict" timeout="5300"/>
+
+</beans>
+```
+
+得到的 zookeeper 的叶子节点的值如下：
+
+```
+dubbo%3A%2F%2F30.5.124.149%3A20880%2Forg.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService%3F
+application%3Dsimplified-registry-xml-provider%26dubbo%3D2.0.2%26group%3Ddubbo-simple%26**owner**%3D
+vict%26**retries**%3D7%26**timeout**%3D5300%26timestamp%3D1542594503305%26version%3D1.2.3
+```
+
+和上面的**现有功能 sample**进行对比，上面的 sample 中，executes, retries, owner, timeout 四个配置项都进入了注册中心。但是本实例不是：
+* 配置了：dubbo.registry.simplified=true， 默认情况下，timeout 在默认的配置项列表，所以还是会进入注册中心；
+* 配置了：dubbo.registry.extra-keys=retries,owner ， 所以 retries，owner 也会进入注册中心。
+
+总结：timeout，retries,owner 进入了注册中心，而 executes 没有进入。
+
+consumer 端配置
+
+```xml
+
+<beans xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
+ xmlns:dubbo="http://dubbo.apache.org/schema/dubbo"
+ xmlns="http://www.springframework.org/schema/beans"
+ 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">
+
+ <!-- optional -->
+ <dubbo:application name="simplified-registry-xml-consumer"/>
+
+ <dubbo:registry address="zookeeper://127.0.0.1:2181" username="xxx" password="yyy" check="true"/>
+
+ <dubbo:reference id="demoService" interface="org.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService"
+ owner="vvv" retries="4" actives="6" timeout="4500" version="1.2.3" group="dubbo-simple"/>
+
+</beans>
+```
+
+得到的 zookeeper 的叶子节点的值如下：
+
+```
+consumer%3A%2F%2F30.5.124.149%2Forg.apache.dubbo.samples.simplified.registry.nosimple.api.DemoService%3F
+actives%3D6%26application%3Dsimplified-registry-xml-consumer%26category%3D
+consumers%26check%3Dfalse%26dubbo%3D2.0.2%26group%3Ddubbo-simple%26owner%3Dvvv%26version%3D1.2.3
+```
+
+* 配置了：dubbo.registry.simplified=true ， 默认情况下，application,version,group,dubbo 在默认的配置项列表，所以还是会进入注册中心；
+
+
+### 方式2. 声明spring bean
+
+sample在dubbo-samples-simplified-registry/dubbo-samples-simplified-registry-annotation 工程下 （跑 sample 前，先跑下ZKClean 进行配置项清理）
+
+##### Provider配置
+
+privide 端 bean 配置：
+
+```java
+// 等同于dubbo.properties配置，用@Bean形式进行配置
+@Bean
+public RegistryConfig registryConfig() {
+ RegistryConfig registryConfig = new RegistryConfig();
+ registryConfig.setAddress("zookeeper://127.0.0.1:2181");
+ registryConfig.setSimplified(true);
+ registryConfig.setExtraKeys("retries,owner");
+ return registryConfig;
+}
+```
+
+```java
+// 暴露服务
+@Service(version = "1.1.8", group = "d-test", executes = 4500, retries = 7, owner = "victanno", timeout = 5300)
+public class AnnotationServiceImpl implements AnnotationService {
+ @Override
+ public String sayHello(String name) {
+ System.out.println("async provider received: " + name);
+ return "annotation: hello, " + name;
+ }
+}
+```
+
+和上面 sample 中的 dubbo.properties 的效果是一致的。结果如下：
+* 默认情况下，timeout 在默认的配置项列表，所以还是会进入注册中心；
+* 配置了 retries,owner 作为额外的 key 进入注册中心 ， 所以 retries，owner 也会进入注册中心。
+
+总结：timeout，retries,owner 进入了注册中心，而 executes 没有进入。
+
+##### Consumer配置
+
+consumer 端 bean 配置：
+
+```java
+@Bean
+public RegistryConfig registryConfig() {
+ RegistryConfig registryConfig = new RegistryConfig();
+ registryConfig.setAddress("zookeeper://127.0.0.1:2181");
+ registryConfig.setSimplified(true);
+ return registryConfig;
+ }
+```
+
+消费服务：
+
+```java
+@Component("annotationAction")
+public class AnnotationAction {
+
+ @Reference(version = "1.1.8", group = "d-test", owner = "vvvanno", retries = 4, actives = 6, timeout = 4500)
+ private AnnotationService annotationService;
+ public String doSayHello(String name) {
+ return annotationService.sayHello(name);
+ }
+}
+```
+
+和上面 sample 中 consumer 端的配置是一样的。结果如下：
+* 默认情况下，application,version,group,dubbo 在默认的配置项列表，所以还是会进入注册中心。
+
+###### 注意：
+如果一个应用中既有provider又有consumer，那么配置需要合并成：
+
+```java
+@Bean
+public RegistryConfig registryConfig() {
+ RegistryConfig registryConfig = new RegistryConfig();
+ registryConfig.setAddress("zookeeper://127.0.0.1:2181");
+ registryConfig.setSimplified(true);
+ //只对provider生效
+ registryConfig.setExtraKeys("retries,owner");
+ return registryConfig;
+}
+```
+
+## 后续规划
+
+本版本还保留了大量的配置项，接下来的版本中，会逐渐删除所有的配置项。
diff --git a/content/zh/docs/v3.0/references/features/static-service.md b/content/zh/docs/v3.0/references/features/static-service.md
new file mode 100644
index 0000000..55a6b59
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/static-service.md
@@ -0,0 +1,31 @@
+---
+type: docs
+title: "静态服务"
+linkTitle: "静态服务"
+weight: 11
+description: "将 Dubbo 服务标识为非动态管理模式"
+---
+
+有时候希望人工管理服务提供者的上线和下线，此时需将注册中心标识为非动态管理模式。
+
+```xml
+<dubbo:registry address="10.20.141.150:9090" dynamic="false" />
+```
+
+或者
+
+```xml
+<dubbo:registry address="10.20.141.150:9090?dynamic=false" />
+```
+
+服务提供者初次注册时为禁用状态，需人工启用。断线时，将不会被自动删除，需人工禁用。
+
+如果是一个第三方服务提供者，比如 memcached，可以直接向注册中心写入提供者地址信息，消费者正常使用 [^1]：
+
+```java
+RegistryFactory registryFactory = ExtensionLoader.getExtensionLoader(RegistryFactory.class).getAdaptiveExtension();
+Registry registry = registryFactory.getRegistry(URL.valueOf("zookeeper://10.20.153.10:2181"));
+registry.register(URL.valueOf("memcached://10.20.153.11/com.foo.BarService?category=providers&dynamic=false&application=foo"));
+```
+
+[^1]: 通常由脚本监控中心页面等调用
\ No newline at end of file
diff --git a/content/zh/docs/v3.0/references/features/stickiness.md b/content/zh/docs/v3.0/references/features/stickiness.md
new file mode 100644
index 0000000..72ba499
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/stickiness.md
@@ -0,0 +1,24 @@
+---
+type: docs
+title: "粘滞连接"
+linkTitle: "粘滞连接"
+weight: 31
+description: "为有状态服务配置粘滞连接"
+---
+
+粘滞连接用于有状态服务，尽可能让客户端总是向同一提供者发起调用，除非该提供者挂了，再连另一台。
+
+粘滞连接将自动开启[延迟连接](../lazy-connect)，以减少长连接数。
+
+```xml
+<dubbo:reference id="xxxService" interface="com.xxx.XxxService" sticky="true" />
+```
+
+Dubbo 支持方法级别的粘滞连接，如果你想进行更细粒度的控制，还可以这样配置。
+
+```xml
+<dubbo:reference id="xxxService" interface="com.xxx.XxxService">
+ <dubbo:mothod name="sayHello" sticky="true" />
+</dubbo:reference>
+```
+
diff --git a/content/zh/docs/v3.0/references/features/subscribe-only.md b/content/zh/docs/v3.0/references/features/subscribe-only.md
new file mode 100644
index 0000000..8910676
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/subscribe-only.md
@@ -0,0 +1,25 @@
+---
+type: docs
+title: "只订阅"
+linkTitle: "只订阅"
+weight: 6
+description: "只订阅不注册"
+---
+
+为方便开发测试，经常会在线下共用一个所有服务可用的注册中心，这时，如果一个正在开发中的服务提供者注册，可能会影响消费者不能正常运行。
+
+可以让服务提供者开发方，只订阅服务(开发的服务可能依赖其它服务)，而不注册正在开发的服务，通过直连测试正在开发的服务。
+
+
+
+禁用注册配置
+
+```xml
+<dubbo:registry address="10.20.153.10:9090" register="false" />
+```
+
+或者
+
+```xml
+<dubbo:registry address="10.20.153.10:9090?register=false" />
+```
diff --git a/content/zh/docs/v3.0/references/features/thread-model.md b/content/zh/docs/v3.0/references/features/thread-model.md
new file mode 100644
index 0000000..8cb6233
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/thread-model.md
@@ -0,0 +1,37 @@
+---
+type: docs
+title: "线程模型"
+linkTitle: "线程模型"
+weight: 4
+description: "配置 Dubbo 中的线程模型"
+---
+
+如果事件处理的逻辑能迅速完成，并且不会发起新的 IO 请求，比如只是在内存中记个标识，则直接在 IO 线程上处理更快，因为减少了线程池调度。
+
+但如果事件处理逻辑较慢，或者需要发起新的 IO 请求，比如需要查询数据库，则必须派发到线程池，否则 IO 线程阻塞，将导致不能接收其它请求。
+
+如果用 IO 线程处理事件，又在事件处理过程中发起新的 IO 请求，比如在连接事件中发起登录请求，会报“可能引发死锁”异常，但不会真死锁。
+
+
+
+
+因此，需要通过不同的派发策略和不同的线程池配置的组合来应对不同的场景:
+
+```xml
+<dubbo:protocol name="dubbo" dispatcher="all" threadpool="fixed" threads="100" />
+```
+
+Dispatcher
+
+* `all` 所有消息都派发到线程池，包括请求，响应，连接事件，断开事件，心跳等。
+* `direct` 所有消息都不派发到线程池，全部在 IO 线程上直接执行。
+* `message` 只有请求响应消息派发到线程池，其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
+* `execution` 只有请求消息派发到线程池，不含响应，响应和其它连接断开事件，心跳等消息，直接在 IO 线程上执行。
+* `connection` 在 IO 线程上，将连接断开事件放入队列，有序逐个执行，其它消息派发到线程池。
+
+ThreadPool
+
+* `fixed` 固定大小线程池，启动时建立线程，不关闭，一直持有。(缺省)
+* `cached` 缓存线程池，空闲一分钟自动删除，需要时重建。
+* `limited` 可伸缩线程池，但池中的线程数只会增长不会收缩。只增长不收缩的目的是为了避免收缩时突然来了大流量引起的性能问题。
+* `eager` 优先创建`Worker`线程池。在任务数量大于`corePoolSize`但是小于`maximumPoolSize`时，优先创建`Worker`来处理任务。当任务数量大于`maximumPoolSize`时，将任务放入阻塞队列中。阻塞队列充满时抛出`RejectedExecutionException`。(相比于`cached`:`cached`在任务数量超过`maximumPoolSize`时直接抛出异常而不是将任务放入阻塞队列)
diff --git a/content/zh/docs/v3.0/references/features/tls.md b/content/zh/docs/v3.0/references/features/tls.md
new file mode 100644
index 0000000..6c90042
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/tls.md
@@ -0,0 +1,51 @@
+---
+type: docs
+title: "TLS"
+linkTitle: "TLS"
+weight: 32
+description: "通过 TLS 保证传输安全"
+---
+
+2.7.5 版本在传输链路的安全性上做了很多工作，对于内置的 Dubbo Netty Server 和新引入的 gRPC 协议都提供了基于 TLS 的安全链路传输机制。
+
+TLS 的配置都有统一的入口，如下所示：
+
+##### Provider 端
+
+```java
+SslConfig sslConfig = new SslConfig();
+sslConfig.setServerKeyCertChainPath("path to cert");
+sslConfig.setServerPrivateKeyPath(args[1]);
+// 如果开启双向 cert 认证
+if (mutualTls) {
+ sslConfig.setServerTrustCertCollectionPath(args[2]);
+}
+
+ProtocolConfig protocolConfig = new ProtocolConfig("dubbo/grpc");
+protocolConfig.setSslEnabled(true);
+```
+
+
+
+##### Consumer 端
+
+```java
+if (!mutualTls) {}
+ sslConfig.setClientTrustCertCollectionPath(args[0]);
+} else {
+ sslConfig.setClientTrustCertCollectionPath(args[0]);
+ sslConfig.setClientKeyCertChainPath(args[1]);
+ sslConfig.setClientPrivateKeyPath(args[2]);
+}
+```
+
+为尽可能保证应用启动的灵活性，TLS Cert 的指定还能通过 -D 参数或环境变量等方式来在启动阶段根据部署环境动态指定，具体请参见 Dubbo 配置读取规则与 TLS 示例
+
+{{% alert title="提示" color="primary" %}}
+参考 Dubbo [配置读取规则](../../configuration/configuration-load-process)，TLS [示例](https://github.com/apache/dubbo-samples/tree/master/java/dubbo-samples-ssl)
+
+如果要使用的是 gRPC 协议，在开启 TLS 时会使用到协议协商机制，因此必须使用支持 ALPN 机制的 Provider，推荐使用的是 netty-tcnative，具体可参见 gRPC Java 社区的[总结]( https://github.com/grpc/grpc-java/blob/master/SECURITY.md)
+{{% /alert %}}
+
+
+在服务调用的安全性上，Dubbo 在后续的版本中会持续投入，其中服务发现/调用的鉴权机制预计在接下来的版本中就会和大家见面。
diff --git a/content/zh/docs/v3.0/references/features/token-authorization.md b/content/zh/docs/v3.0/references/features/token-authorization.md
new file mode 100644
index 0000000..642aed2
--- /dev/null
+++ b/content/zh/docs/v3.0/references/features/token-authorization.md
@@ -0,0 +1,37 @@
+---
+type: docs
+title: "令牌验证"
+linkTitle: "令牌验证"
+weight: 32
+description: "通过令牌验证在注册中心控制权限"
+---
+
+通过令牌验证在注册中心控制权限，以决定要不要下发令牌给消费者，可以防止消费者绕过注册中心访问提供者，另外通过注册中心可灵活改变授权方式，而不需修改或升级提供者
+
+
+
+可以全局设置开启令牌验证：
+
+```xml
+<!--随机token令牌，使用UUID生成-->
+<dubbo:provider interface="com.foo.BarService" token="true" />
+```
+或
+
+```xml
+<!--固定token令牌，相当于密码-->
+<dubbo:provider interface="com.foo.BarService" token="123456" />
+```
+
+也可在服务级别设置：
+
+```xml
+<!--随机token令牌，使用UUID生成-->
+<dubbo:service interface="com.foo.BarService" token="true" />
+```
+或
+
+```xml
+<!--固定token令牌，相当于密码-->
+<dubbo:service interface="com.foo.BarService" token="123456" />
+```
diff --git a/content/zh/docs/v3.0/references/lifecycle/rest.md b/content/zh/docs/v3.0/references/lifecycle/rest.md
new file mode 100644
index 0000000..56bc7b3
--- /dev/null
+++ b/content/zh/docs/v3.0/references/lifecycle/rest.md
@@ -0,0 +1,1243 @@
+---
+type: docs
+title: "开发 REST 应用"
+linkTitle: "REST 支持"
+weight: 19
+description: "在 Dubbo 中开发 REST 风格的远程调用"
+---
+
+{{% pageinfo %}}
+作者：沈理
+
+文档版权：[Apache 2.0许可证 署名-禁止演绎](http://www.apache.org/licenses/LICENSE-2.0)
+
+本文篇幅较长，因为REST本身涉及面较多。另外，本文参照 Spring 等的文档风格，不仅仅局限于框架用法的阐述，同时也努力呈现框架的设计理念和优良应用的架构思想。
+对于想粗略了解 dubbo 和 REST 的人，只需浏览 概述 至 标准Java REST API：JAX-RS简介 几节即可。
+{{% /pageinfo %}}
+
+
+
+## 目录
+
+* 概述
+* REST的优点
+* 应用场景
+* 快速入门
+* 标准Java REST API：JAX-RS简介
+* REST服务提供端详解
+ * HTTP POST/GET的实现
+ * Annotation放在接口类还是实现类
+ * JSON、XML等多数据格式的支持
+ * 中文字符支持
+ * XML数据格式的额外要求
+ * 定制序列化
+ * 配置REST Server的实现
+ * 获取上下文（Context）信息
+ * 配置端口号和Context Path
+ * 配置线程数和IO线程数
+ * 配置长连接
+ * 配置最大的HTTP连接数
+ * 配置每个消费端的超时时间和HTTP连接数
+ * GZIP数据压缩
+ * 用Annotation取代部分Spring XML配置
+ * 添加自定义的Filter、Interceptor等
+ * 添加自定义的Exception处理
+ * 配置HTTP日志输出
+ * 输入参数的校验
+ * 是否应该透明发布REST服务
+ * Dubbo的REST提供端在被调用时使用header
+* REST服务消费端详解
+ * 场景1：非dubbo的消费端调用dubbo的REST服务
+ * 场景2：dubbo消费端调用dubbo的REST服务
+ * 场景3：dubbo的消费端调用非dubbo的REST服务
+ * Dubbo的消费端在调用REST服务时配置自定义header
+* Dubbo中JAX-RS的限制
+* REST常见问题解答（REST FAQ）
+ * Dubbo REST的服务能和Dubbo注册中心、监控中心集成吗？
+ * Dubbo REST中如何实现负载均衡和容错（failover）？
+ * JAX-RS中重载的方法能够映射到同一URL地址吗？
+ * JAX-RS中作POST的方法能够接收多个参数吗？
+* Dubbo当前体系可能的不足之处（与REST相关的）
+ * RpcContext的侵入性
+ * Protocol配置的局限性
+ * XML命名不符合spring规范
+* REST最佳实践
+* 性能基准测试
+ * 测试环境
+ * 测试脚本
+ * 测试结果
+* 扩展讨论
+ * REST与Thrift、Protobuf等的对比
+ * REST与传统WebServices的对比
+ * JAX-RS与Spring MVC的对比
+* 未来
+
+## 概述
+
+dubbo支持多种远程调用方式，例如dubbo RPC（二进制序列化 + tcp协议）、http invoker（二进制序列化 + http协议，至少在开源版本没发现对文本序列化的支持）、hessian（二进制序列化 + http协议）、WebServices （文本序列化 + http协议）等等，但缺乏对当今特别流行的REST风格远程调用（文本序列化 + http协议）的支持。
+
+有鉴于此，我们基于标准的Java REST API——JAX-RS 2.0（Java API for RESTful Web Services的简写），为dubbo提供了接近透明的REST调用支持。由于完全兼容Java标准API，所以为dubbo开发的所有REST服务，未来脱离dubbo或者任何特定的REST底层实现一般也可以正常运行。
+
+特别值得指出的是，我们并不需要完全严格遵守REST的原始定义和架构风格。即使著名的Twitter REST API也会根据情况做适度调整，而不是机械的遵守原始的REST风格。
+
+> 附注：我们将这个功能称之为REST风格的远程调用，即RESTful Remoting（抽象的远程处理或者调用），而不是叫RESTful RPC（具体的远程“过程”调用），是因为REST和RPC本身可以被认为是两种不同的风格。在dubbo的REST实现中，可以说有两个面向，其一是提供或消费正常的REST服务，其二是将REST作为dubbo RPC体系中一种协议实现，而RESTful Remoting同时涵盖了这两个面向。
+
+## REST的优点
+
+以下摘自维基百科：
+
+* 可更高效利用缓存来提高响应速度
+* 通讯本身的无状态性可以让不同的服务器的处理一系列请求中的不同请求，提高服务器的扩展性
+* 浏览器即可作为客户端，简化软件需求
+* 相对于其他叠加在HTTP协议之上的机制，REST的软件依赖性更小
+* 不需要额外的资源发现机制
+* 在软件技术演进中的长期的兼容性更好
+
+这里我还想特别补充REST的显著优点：基于简单的文本格式消息和通用的HTTP协议，使它具备极广的适用性，几乎所有语言和平台都对它提供支持，同时其学习和使用的门槛也较低。
+
+## 应用场景
+
+正是由于REST在适用性方面的优点，所以在dubbo中支持REST，可以为当今多数主流的远程调用场景都带来（显著）好处：
+
+1. 显著简化企业内部的异构系统之间的（跨语言）调用。此处主要针对这种场景：dubbo的系统做服务提供端，其他语言的系统（也包括某些不基于dubbo的java系统）做服务消费端，两者通过HTTP和文本消息进行通信。即使相比Thrift、ProtoBuf等二进制跨语言调用方案，REST也有自己独特的优势（详见后面讨论）
+
+2. 显著简化对外Open API（开放平台）的开发。既可以用dubbo来开发专门的Open API应用，也可以将原内部使用的dubbo service直接“透明”发布为对外的Open REST API（当然dubbo本身未来最好可以较透明的提供诸如权限控制、频次控制、计费等诸多功能）
+
+3. 显著简化手机（平板）APP或者PC桌面客户端开发。类似于2，既可以用dubbo来开发专门针对无线或者桌面的服务器端，也可以将原内部使用的dubbo service直接”透明“的暴露给手机APP或桌面程序。当然在有些项目中，手机或桌面程序也可以直接访问以上场景2中所述的Open API。
+
+4. 显著简化浏览器AJAX应用的开发。类似于2，既可以用dubbo来开发专门的AJAX服务器端，也可以将原内部使用的dubbo service直接”透明“的暴露给浏览器中JavaScript。当然，很多AJAX应用更适合与web框架协同工作，所以直接访问dubbo service在很多web项目中未必是一种非常优雅的架构。
+
+5. 为企业内部的dubbo系统之间（即服务提供端和消费端都是基于dubbo的系统）提供一种基于文本的、易读的远程调用方式。
+
+6. 一定程度简化dubbo系统对其它异构系统的调用。可以用类似dubbo的简便方式“透明”的调用非dubbo系统提供的REST服务（不管服务提供端是在企业内部还是外部）
+
+需要指出的是，我认为1～3是dubbo的REST调用最有价值的三种应用场景，并且我们为dubbo添加REST调用，其最主要到目的也是面向服务的提供端，即开发REST服务来提供给非dubbo的（异构）消费端。
+
+归纳起来，所有应用场景如下图所示：
+
+
+借用Java过去最流行的宣传语，为dubbo添加REST调用后，可以实现服务的”一次编写，到处访问“，理论上可以面向全世界开放，从而真正实现比较理想化的面向服务架构（SOA）。
+
+当然，传统的WebServices（WSDL/SOAP）也基本同样能满足以上场景（除了场景4）的要求（甚至还能满足那些需要企业级特性的场景），但由于其复杂性等问题，现在已经越来越少被实际采用了。
+
+## 快速入门
+
+在dubbo中开发一个REST风格的服务会比较简单，下面以一个注册用户的简单服务为例说明。
+
+这个服务要实现的功能是提供如下URL（注：这个URL不是完全符合REST的风格，但是更简单实用）：
+
+```
+http://localhost:8080/users/register
+```
+
+而任何客户端都可以将包含用户信息的JSON字符串POST到以上URL来完成用户注册。
+
+首先，开发服务的接口：
+
+```java
+public interface UserService {
+ void registerUser(User user);
+}
+```
+
+然后，开发服务的实现：
+
+```java
+@Path("users")
+public class UserServiceImpl implements UserService {
+
+ @POST
+ @Path("register")
+ @Consumes({MediaType.APPLICATION_JSON})
+ public void registerUser(User user) {
+ // save the user...
+ }
+}
+```
+上面的服务实现代码非常简单，但是由于REST服务是要被发布到特定HTTP URL，供任意语言客户端甚至浏览器来访问，所以这里要额外添加了几个JAX-RS的标准annotation来做相关的配置：
+
+@Path("users")：指定访问UserService的URL相对路径是/users，即http://localhost:8080/users
+
+@Path("register")：指定访问registerUser()方法的URL相对路径是/register，再结合上一个@Path为UserService指定的路径，则调用UserService.register()的完整路径为http://localhost:8080/users/register
+
+@POST：指定访问registerUser()用HTTP POST方法
+
+@Consumes({MediaType.APPLICATION_JSON})：指定registerUser()接收JSON格式的数据。REST框架会自动将JSON数据反序列化为User对象
+
+最后，在spring配置文件中添加此服务，即完成所有服务开发工作：
+
+ ```xml
+<!-- 用rest协议在8080端口暴露服务 -->
+<dubbo:protocol name="rest" port="8080"/>
+
+<!-- 声明需要暴露的服务接口 -->
+<dubbo:service interface="xxx.UserService" ref="userService"/>
+
+<!-- 和本地bean一样实现服务 -->
+<bean id="userService" class="xxx.UserServiceImpl" />
+```
+
+## 标准Java REST API：JAX-RS简介
+
+JAX-RS是标准的Java REST API，得到了业界的广泛支持和应用，其著名的开源实现就有很多，包括Oracle的Jersey，RedHat的RestEasy，Apache的CXF和Wink，以及restlet等等。另外，所有支持JavaEE 6.0以上规范的商用JavaEE应用服务器都对JAX-RS提供了支持。因此，JAX-RS是一种已经非常成熟的解决方案，并且采用它没有任何所谓vendor lock-in的问题。
+
+JAX-RS在网上的资料非常丰富，例如下面的入门教程：
+
+* Oracle官方的tutorial：http://docs.oracle.com/javaee/7/tutorial/doc/jaxrs.htm
+* IBM developerWorks中国站文章：http://www.ibm.com/developerworks/cn/java/j-lo-jaxrs/
+
+更多的资料请自行google或者百度一下。就学习JAX-RS来说，一般主要掌握其各种annotation的用法即可。
+
+> 注意：dubbo是基于JAX-RS 2.0版本的，有时候需要注意一下资料或REST实现所涉及的版本。
+
+## REST服务提供端详解
+
+下面我们扩充“快速入门”中的UserService，进一步展示在dubbo中REST服务提供端的开发要点。
+
+### HTTP POST/GET的实现
+
+REST服务中虽然建议使用HTTP协议中四种标准方法POST、DELETE、PUT、GET来分别实现常见的“增删改查”，但实际中，我们一般情况直接用POST来实现“增改”，GET来实现“删查”即可（DELETE和PUT甚至会被一些防火墙阻挡）。
+
+前面已经简单演示了POST的实现，在此，我们为UserService添加一个获取注册用户资料的功能，来演示GET的实现。
+
+这个功能就是要实现客户端通过访问如下不同URL来获取不同ID的用户资料：
+
+```
+http://localhost:8080/users/1001
+http://localhost:8080/users/1002
+http://localhost:8080/users/1003
+```
+
+当然，也可以通过其他形式的URL来访问不同ID的用户资料，例如：
+
+```
+http://localhost:8080/users/load?id=1001
+```
+
+JAX-RS本身可以支持所有这些形式。但是上面那种在URL路径中包含查询参数的形式（http://localhost:8080/users/1001） 更符合REST的一般习惯，所以更推荐大家来使用。下面我们就为UserService添加一个getUser()方法来实现这种形式的URL访问：
+
+```java
+@GET
+@Path("{id : \\d+}")
+@Produces({MediaType.APPLICATION_JSON})
+public User getUser(@PathParam("id") Long id) {
+ // ...
+}
+```
+
+@GET：指定用HTTP GET方法访问
+
+@Path("{id : \\d+}")：根据上面的功能需求，访问getUser()的URL应当是“http://localhost:8080/users/ + 任意数字"，并且这个数字要被做为参数传入getUser()方法。 这里的annotation配置中，@Path中间的{id: xxx}指定URL相对路径中包含了名为id参数，而它的值也将被自动传递给下面用@PathParam("id")修饰的方法参数id。{id:后面紧跟的\\d+是一个正则表达式，指定了id参数必须是数字。
+
+@Produces({MediaType.APPLICATION_JSON})：指定getUser()输出JSON格式的数据。框架会自动将User对象序列化为JSON数据。
+
+### Annotation放在接口类还是实现类
+
+在Dubbo中开发REST服务主要都是通过JAX-RS的annotation来完成配置的，在上面的示例中，我们都是将annotation放在服务的实现类中。但其实，我们完全也可以将annotation放到服务的接口上，这两种方式是完全等价的，例如：
+
+```java
+@Path("users")
+public interface UserService {
+
+ @GET
+ @Path("{id : \\d+}")
+ @Produces({MediaType.APPLICATION_JSON})
+ User getUser(@PathParam("id") Long id);
+}
+```
+
+在一般应用中，我们建议将annotation放到服务实现类，这样annotation和java实现代码位置更接近，更便于开发和维护。另外更重要的是，我们一般倾向于避免对接口的污染，保持接口的纯净性和广泛适用性。
+
+但是，如后文所述，如果我们要用dubbo直接开发的消费端来访问此服务，则annotation必须放到接口上。
+
+如果接口和实现类都同时添加了annotation，则实现类的annotation配置会生效，接口上的annotation被直接忽略。
+
+### JSON、XML等多数据格式的支持
+
+在dubbo中开发的REST服务可以同时支持传输多种格式的数据，以给客户端提供最大的灵活性。其中我们目前对最常用的JSON和XML格式特别添加了额外的功能。
+
+比如，我们要让上例中的getUser()方法支持分别返回JSON和XML格式的数据，只需要在annotation中同时包含两种格式即可：
+
+```java
+@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
+User getUser(@PathParam("id") Long id);
+```
+
+或者也可以直接用字符串（还支持通配符）表示MediaType：
+
+```java
+@Produces({"application/json", "text/xml"})
+User getUser(@PathParam("id") Long id);
+```
+
+如果所有方法都支持同样类型的输入输出数据格式，则我们无需在每个方法上做配置，只需要在服务类上添加annotation即可：
+
+```java
+@Path("users")
+@Consumes({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
+@Produces({MediaType.APPLICATION_JSON, MediaType.TEXT_XML})
+public class UserServiceImpl implements UserService {
+ // ...
+}
+
+```
+
+在一个REST服务同时对多种数据格式支持的情况下，根据JAX-RS标准，一般是通过HTTP中的MIME header（content-type和accept）来指定当前想用的是哪种格式的数据。
+
+但是在dubbo中，我们还自动支持目前业界普遍使用的方式，即用一个URL后缀（.json和.xml）来指定想用的数据格式。例如，在添加上述annotation后，直接访问http://localhost:8888/users/1001.json则表示用json格式，直接访问http://localhost:8888/users/1002.xml则表示用xml格式，比用HTTP Header更简单直观。Twitter、微博等的REST API都是采用这种方式。
+
+如果你既不加HTTP header，也不加后缀，则dubbo的REST会优先启用在以上annotation定义中排位最靠前的那种数据格式。
+
+> 注意：这里要支持XML格式数据，在annotation中既可以用MediaType.TEXT_XML，也可以用MediaType.APPLICATION_XML，但是TEXT_XML是更常用的，并且如果要利用上述的URL后缀方式来指定数据格式，只能配置为TEXT_XML才能生效。
+
+### 中文字符支持
+
+为了在dubbo REST中正常输出中文字符，和通常的Java web应用一样，我们需要将HTTP响应的contentType设置为UTF-8编码。
+
+基于JAX-RS的标准用法，我们只需要做如下annotation配置即可：
+
+```java
+@Produces({"application/json; charset=UTF-8", "text/xml; charset=UTF-8"})
+User getUser(@PathParam("id") Long id);
+```
+
+为了方便用户，我们在dubbo REST中直接添加了一个支持类，来定义以上的常量，可以直接使用，减少出错的可能性。
+
+```java
+@Produces({ContentType.APPLICATION_JSON_UTF_8, ContentType.TEXT_XML_UTF_8})
+User getUser(@PathParam("id") Long id);
+```
+
+### XML数据格式的额外要求
+
+由于JAX-RS的实现一般都用标准的JAXB（Java API for XML Binding）来序列化和反序列化XML格式数据，所以我们需要为每一个要用XML传输的对象添加一个类级别的JAXB annotation，否则序列化将报错。例如为getUser()中返回的User添加如下：
+
+```java
+@XmlRootElement
+public class User implements Serializable {
+ // ...
+}
+```
+
+此外，如果service方法中的返回值是Java的 primitive类型（如int，long，float，double等），最好为它们添加一层wrapper对象，因为JAXB不能直接序列化primitive类型。
+
+例如，我们想让前述的registerUser()方法返回服务器端为用户生成的ID号：
+
+```java
+long registerUser(User user);
+```
+
+由于primitive类型不被JAXB序列化支持，所以添加一个wrapper对象：
+
+```java
+@XmlRootElement
+public class RegistrationResult implements Serializable {
+
+ private Long id;
+
+ public RegistrationResult() {
+ }
+
+ public RegistrationResult(Long id) {
+ this.id = id;
+ }
+
+ public Long getId() {
+ return id;
+ }
+
+ public void setId(Long id) {
+ this.id = id;
+ }
+}
+```
+
+并修改service方法：
+
+```java
+RegistrationResult registerUser(User user);
+```
+
+这样不但能够解决XML序列化的问题，而且使得返回的数据都符合XML和JSON的规范。例如，在JSON中，返回的将是如下形式：
+
+```javascript
+{"id": 1001}
+```
+
+如果不加wrapper，JSON返回值将直接是
+
+```
+1001
+```
+
+而在XML中，加wrapper后返回值将是：
+
+```xml
+<registrationResult>
+ <id>1002</id>
+</registrationResult>
+```
+
+这种wrapper对象其实利用所谓Data Transfer Object（DTO）模式，采用DTO还能对传输数据做更多有用的定制。
+
+### 定制序列化
+
+如上所述，REST的底层实现会在service的对象和JSON/XML数据格式之间自动做序列化/反序列化。但有些场景下，如果觉得这种自动转换不满足要求，可以对其做定制。
+
+Dubbo中的REST实现是用JAXB做XML序列化，用Jackson做JSON序列化，所以在对象上添加JAXB或Jackson的annotation即可以定制映射。
+
+例如，定制对象属性映射到XML元素的名字：
+
+```java
+@XmlRootElement
+@XmlAccessorType(XmlAccessType.FIELD)
+public class User implements Serializable {
+
+ @XmlElement(name="username")
+ private String name;
+}
+```
+
+定制对象属性映射到JSON字段的名字：
+
+```java
+public class User implements Serializable {
+
+ @JsonProperty("username")
+ private String name;
+}
+```
+
+更多资料请参考JAXB和Jackson的官方文档，或自行google。
+
+### 配置REST Server的实现
+
+目前在dubbo中，我们支持5种嵌入式rest server的实现，并同时支持采用外部应用服务器来做rest server的实现。rest server的实现是通过如下server这个XML属性来选择的：
+
+```xml
+<dubbo:protocol name="rest" server="jetty"/>
+```
+
+以上配置选用了嵌入式的jetty来做rest server，同时，如果不配置server属性，rest协议默认也是选用jetty。jetty是非常成熟的java servlet容器，并和dubbo已经有较好的集成（目前5种嵌入式server中只有jetty和后面所述的tomcat、tjws，与dubbo监控系统等完成了无缝的集成），所以，如果你的dubbo系统是单独启动的进程，你可以直接默认采用jetty即可。
+
+
+```xml
+<dubbo:protocol name="rest" server="tomcat"/>
+```
+
+以上配置选用了嵌入式的tomcat来做rest server。在嵌入式tomcat上，REST的性能比jetty上要好得多（参见后面的基准测试），建议在需要高性能的场景下采用tomcat。
+
+```xml
+<dubbo:protocol name="rest" server="netty"/>
+```
+
+以上配置选用嵌入式的netty来做rest server。（TODO more contents to add）
+
+```xml
+<dubbo:protocol name="rest" server="tjws"/> (tjws is now deprecated)
+<dubbo:protocol name="rest" server="sunhttp"/>
+```
+
+以上配置选用嵌入式的tjws或Sun HTTP server来做rest server。这两个server实现非常轻量级，非常方便在集成测试中快速启动使用，当然也可以在负荷不高的生产环境中使用。 注：tjws目前已经被deprecated掉了，因为它不能很好的和servlet 3.1 API工作。
+
+如果你的dubbo系统不是单独启动的进程，而是部署到了Java应用服务器中，则建议你采用以下配置：
+
+```xml
+<dubbo:protocol name="rest" server="servlet"/>
+```
+
+通过将server设置为servlet，dubbo将采用外部应用服务器的servlet容器来做rest server。同时，还要在dubbo系统的web.xml中添加如下配置：
+
+```xml
+<web-app>
+ <context-param>
+ <param-name>contextConfigLocation</param-name>
+ <param-value>/WEB-INF/classes/META-INF/spring/dubbo-demo-provider.xml</param-value>
+ </context-param>
+
+ <listener>
+ <listener-class>org.apache.dubbo.remoting.http.servlet.BootstrapListener</listener-class>
+ </listener>
+
+ <listener>
+ <listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
+ </listener>
+
+ <servlet>
+ <servlet-name>dispatcher</servlet-name>
+ <servlet-class>org.apache.dubbo.remoting.http.servlet.DispatcherServlet</servlet-class>
+ <load-on-startup>1</load-on-startup>
+ </servlet>
+
+ <servlet-mapping>
+ <servlet-name>dispatcher</servlet-name>
+ <url-pattern>/*</url-pattern>
+ </servlet-mapping>
+</web-app>
+```
+
+即必须将dubbo的BootstrapListener和DispatherServlet添加到web.xml，以完成dubbo的REST功能与外部servlet容器的集成。
+
+> 注意：如果你是用spring的ContextLoaderListener来加载spring，则必须保证BootstrapListener配置在ContextLoaderListener之前，否则dubbo初始化会出错。
+
+其实，这种场景下你依然可以坚持用嵌入式server，但外部应用服务器的servlet容器往往比嵌入式server更加强大（特别是如果你是部署到更健壮更可伸缩的WebLogic，WebSphere等），另外有时也便于在应用服务器做统一管理、监控等等。
+
+### 获取上下文（Context）信息
+
+在远程调用中，值得获取的上下文信息可能有很多种，这里特别以获取客户端IP为例。
+
+在dubbo的REST中，我们有两种方式获取客户端IP。
+
+第一种方式，用JAX-RS标准的@Context annotation：
+
+```java
+public User getUser(@PathParam("id") Long id, @Context HttpServletRequest request) {
+ System.out.println("Client address is " + request.getRemoteAddr());
+}
+```
+
+用Context修饰getUser()的一个方法参数后，就可以将当前的HttpServletRequest注入进来，然后直接调用servlet api获取IP。
+
+> 注意：这种方式只能在设置server="tjws"或者server="tomcat"或者server="jetty"或者server="servlet"的时候才能工作，因为只有这几种REST server的实现才提供了servlet容器。另外，标准的JAX-RS还支持用@Context修饰service类的一个实例字段来获取HttpServletRequest，但在dubbo中我们没有对此作出支持。
+
+第二种方式，用dubbo中常用的RpcContext：
+
+```java
+public User getUser(@PathParam("id") Long id) {
+ System.out.println("Client address is " + RpcContext.getContext().getRemoteAddressString());
+}
+```
+
+> 注意：这种方式只能在设置server="jetty"或者server="tomcat"或者server="servlet"或者server="tjws"的时候才能工作。另外，目前dubbo的RpcContext是一种比较有侵入性的用法，未来我们很可能会做出重构。
+
+如果你想保持你的项目对JAX-RS的兼容性，未来脱离dubbo也可以运行，请选择第一种方式。如果你想要更优雅的服务接口定义，请选用第二种方式。
+
+此外，在最新的dubbo rest中，还支持通过RpcContext来获取HttpServletRequest和HttpServletResponse，以提供更大的灵活性来方便用户实现某些复杂功能，比如在dubbo标准的filter中访问HTTP Header。用法示例如下：
+
+```java
+if (RpcContext.getContext().getRequest() != null && RpcContext.getContext().getRequest() instanceof HttpServletRequest) {
+ System.out.println("Client address is " + ((HttpServletRequest) RpcContext.getContext().getRequest()).getRemoteAddr());
+}
+
+if (RpcContext.getContext().getResponse() != null && RpcContext.getContext().getResponse() instanceof HttpServletResponse) {
+ System.out.println("Response object from RpcContext: " + RpcContext.getContext().getResponse());
+}
+```
+
+> 注意：为了保持协议的中立性，RpcContext.getRequest()和RpcContext.getResponse()返回的仅仅是一个Object类，而且可能为null。所以，你必须自己做null和类型的检查。
+
+> 注意：只有在设置server="jetty"或者server="tomcat"或者server="servlet"的时候，你才能通过以上方法正确的得到HttpServletRequest和HttpServletResponse，因为只有这几种server实现了servlet容器。
+
+为了简化编程，在此你也可以用泛型的方式来直接获取特定类型的request/response：
+
+```java
+if (RpcContext.getContext().getRequest(HttpServletRequest.class) != null) {
+ System.out.println("Client address is " + RpcContext.getContext().getRequest(HttpServletRequest.class).getRemoteAddr());
+}
+
+if (RpcContext.getContext().getResponse(HttpServletResponse.class) != null) {
+ System.out.println("Response object from RpcContext: " + RpcContext.getContext().getResponse(HttpServletResponse.class));
+}
+```
+
+如果request/response不符合指定的类型，这里也会返回null。
+
+### 配置端口号和Context Path
+
+dubbo中的rest协议默认将采用80端口，如果想修改端口，直接配置：
+
+```xml
+<dubbo:protocol name="rest" port="8888"/>
+```
+
+另外，如前所述，我们可以用@Path来配置单个rest服务的URL相对路径。但其实，我们还可以设置一个所有rest服务都适用的基础相对路径，即java web应用中常说的context path。
+
+只需要添加如下contextpath属性即可：
+
+```xml
+<dubbo:protocol name="rest" port="8888" contextpath="services"/>
+```
+
+以前面代码为例：
+
+```java
+@Path("users")
+public class UserServiceImpl implements UserService {
+
+ @POST
+ @Path("register")
+ @Consumes({MediaType.APPLICATION_JSON})
+ public void registerUser(User user) {
+ // save the user...
+ }
+}
+```
+
+现在registerUser()的完整访问路径为：
+
+```
+http://localhost:8888/services/users/register
+```
+
+注意：如果你是选用外部应用服务器做rest server，即配置:
+
+```xml
+<dubbo:protocol name="rest" port="8888" contextpath="services" server="servlet"/>
+```
+
+则必须保证这里设置的port、contextpath，与外部应用服务器的端口、DispatcherServlet的上下文路径（即webapp path加上servlet url pattern）保持一致。例如，对于部署为tomcat ROOT路径的应用，这里的contextpath必须与web.xml中DispacherServlet的`<url-pattern/>`完全一致：
+
+```xml
+<servlet-mapping>
+ <servlet-name>dispatcher</servlet-name>
+ <url-pattern>/services/*</url-pattern>
+</servlet-mapping>
+```
+
+### 配置线程数和IO线程数
+
+可以为rest服务配置线程池大小：
+
+```xml
+<dubbo:protocol name="rest" threads="500"/>
+```
+
+> 注意：目前线程池的设置只有当server="netty"或者server="jetty"或者server="tomcat"的时候才能生效。另外，如果server="servlet"，由于这时候启用的是外部应用服务器做rest server，不受dubbo控制，所以这里的线程池设置也无效。
+
+如果是选用netty server，还可以配置Netty的IO worker线程数：
+
+```xml
+<dubbo:protocol name="rest" iothreads="5" threads="100"/>
+```
+
+### 配置长连接
+
+Dubbo中的rest服务默认都是采用http长连接来访问，如果想切换为短连接，直接配置：
+
+```xml
+<dubbo:protocol name="rest" keepalive="false"/>
+```
+
+> 注意：这个配置目前只对server="netty"和server="tomcat"才能生效。
+
+### 配置最大的HTTP连接数
+
+可以配置服务器提供端所能同时接收的最大HTTP连接数，防止REST server被过多连接撑爆，以作为一种最基本的自我保护机制：
+
+```xml
+<dubbo:protocol name="rest" accepts="500" server="tomcat/>
+```
+
+> 注意：这个配置目前只对server="tomcat"才能生效。
+
+### 配置每个消费端的超时时间和HTTP连接数
+
+如果rest服务的消费端也是dubbo系统，可以像其他dubbo RPC机制一样，配置消费端调用此rest服务的最大超时时间以及每个消费端所能启动的最大HTTP连接数。
+
+```xml
+<dubbo:service interface="xxx" ref="xxx" protocol="rest" timeout="2000" connections="10"/>
+```
+
+当然，由于这个配置针对消费端生效的，所以也可以在消费端配置：
+
+```xml
+<dubbo:reference id="xxx" interface="xxx" timeout="2000" connections="10"/>
+```
+
+但是，通常我们建议配置在服务提供端提供此类配置。按照dubbo官方文档的说法：“Provider上尽量多配置Consumer端的属性，让Provider实现者一开始就思考Provider服务特点、服务质量的问题。”
+
+> 注意：如果dubbo的REST服务是发布给非dubbo的客户端使用，则这里`<dubbo:service/>`上的配置完全无效，因为这种客户端不受dubbo控制。
+
+### GZIP数据压缩
+
+Dubbo的REST支持用GZIP压缩请求和响应的数据，以减少网络传输时间和带宽占用，但这种方式会也增加CPU开销。
+
+TODO more contents to add
+
+### 用Annotation取代部分Spring XML配置
+
+以上所有的讨论都是基于dubbo在spring中的xml配置。但是，dubbo/spring本身也支持用annotation来作配置，所以我们也可以按dubbo官方文档中的步骤，把相关annotation加到REST服务的实现中，取代一些xml配置，例如：
+
+```java
+@Service(protocol = "rest")
+@Path("users")
+public class UserServiceImpl implements UserService {
+
+ @Autowired
+ private UserRepository userRepository;
+
+ @POST
+ @Path("register")
+ @Consumes({MediaType.APPLICATION_JSON})
+ public void registerUser(User user) {
+ // save the user
+ userRepository.save(user);
+ }
+}
+```
+
+annotation的配置更简单更精确，经常也更便于维护（当然现代IDE都可以在xml中支持比如类名重构，所以就这里的特定用例而言，xml的维护性也很好）。而xml对代码的侵入性更小一些，尤其有利于动态修改配置，特别是比如你要针对单个服务配置连接超时时间、每客户端最大连接数、集群策略、权重等等。另外，特别对复杂应用或者模块来说，xml提供了一个中心点来涵盖的所有组件和配置，更一目了然，一般更便于项目长时期的维护。
+
+当然，选择哪种配置方式没有绝对的优劣，和个人的偏好也不无关系。
+
+### 添加自定义的Filter、Interceptor等
+
+Dubbo的REST也支持JAX-RS标准的Filter和Interceptor，以方便对REST的请求与响应过程做定制化的拦截处理。
+
+其中，Filter主要用于访问和设置HTTP请求和响应的参数、URI等等。例如，设置HTTP响应的cache header：
+
+```java
+public class CacheControlFilter implements ContainerResponseFilter {
+
+ public void filter(ContainerRequestContext req, ContainerResponseContext res) {
+ if (req.getMethod().equals("GET")) {
+ res.getHeaders().add("Cache-Control", "someValue");
+ }
+ }
+}
+```
+
+Interceptor主要用于访问和修改输入与输出字节流，例如，手动添加GZIP压缩：
+
+```java
+public class GZIPWriterInterceptor implements WriterInterceptor {
+
+ @Override
+ public void aroundWriteTo(WriterInterceptorContext context)
+ throws IOException, WebApplicationException {
+ OutputStream outputStream = context.getOutputStream();
+ context.setOutputStream(new GZIPOutputStream(outputStream));
+ context.proceed();
+ }
+}
+```
+
+在标准JAX-RS应用中，我们一般是为Filter和Interceptor添加@Provider annotation，然后JAX-RS runtime会自动发现并启用它们。而在dubbo中，我们是通过添加XML配置的方式来注册Filter和Interceptor：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="xxx.TraceInterceptor, xxx.TraceFilter"/>
+```
+
+在此，我们可以将Filter、Interceptor和DynamicFeature这三种类型的对象都添加到`extension`属性上，多个之间用逗号分隔。（DynamicFeature是另一个接口，可以方便我们更动态的启用Filter和Interceptor，感兴趣请自行google。）
+
+当然，dubbo自身也支持Filter的概念，但我们这里讨论的Filter和Interceptor更加接近协议实现的底层，相比dubbo的filter，可以做更底层的定制化。
+
+> 注：这里的XML属性叫extension，而不是叫interceptor或者filter，是因为除了Interceptor和Filter，未来我们还会添加更多的扩展类型。
+
+如果REST的消费端也是dubbo系统（参见下文的讨论），则也可以用类似方式为消费端配置Interceptor和Filter。但注意，JAX-RS中消费端的Filter和提供端的Filter是两种不同的接口。例如前面例子中服务端是ContainerResponseFilter接口，而消费端对应的是ClientResponseFilter:
+
+```java
+public class LoggingFilter implements ClientResponseFilter {
+
+ public void filter(ClientRequestContext reqCtx, ClientResponseContext resCtx) throws IOException {
+ System.out.println("status: " + resCtx.getStatus());
+ System.out.println("date: " + resCtx.getDate());
+ System.out.println("last-modified: " + resCtx.getLastModified());
+ System.out.println("location: " + resCtx.getLocation());
+ System.out.println("headers:");
+ for (Entry<String, List<String>> header : resCtx.getHeaders().entrySet()) {
+ System.out.print("\t" + header.getKey() + " :");
+ for (String value : header.getValue()) {
+ System.out.print(value + ", ");
+ }
+ System.out.print("\n");
+ }
+ System.out.println("media-type: " + resCtx.getMediaType().getType());
+ }
+}
+```
+
+### 添加自定义的Exception处理
+
+Dubbo的REST也支持JAX-RS标准的ExceptionMapper，可以用来定制特定exception发生后应该返回的HTTP响应。
+
+```java
+public class CustomExceptionMapper implements ExceptionMapper<NotFoundException> {
+
+ public Response toResponse(NotFoundException e) {
+ return Response.status(Response.Status.NOT_FOUND).entity("Oops! the requested resource is not found!").type("text/plain").build();
+ }
+}
+```
+
+和Interceptor、Filter类似，将其添加到XML配置文件中即可启用：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="xxx.CustomExceptionMapper"/>
+```
+
+### 配置HTTP日志输出
+
+Dubbo rest支持输出所有HTTP请求/响应中的header字段和body消息体。
+
+在XML配置中添加如下自带的REST filter：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="org.apache.dubbo.rpc.protocol.rest.support.LoggingFilter"/>
+```
+
+**然后在logging配置中至少为org.apache.dubbo.rpc.protocol.rest.support打开INFO级别日志输出**，例如，在log4j.xml中配置：
+
+```xml
+<logger name="org.apache.dubbo.rpc.protocol.rest.support">
+ <level value="INFO"/>
+ <appender-ref ref="CONSOLE"/>
+</logger>
+```
+
+当然，你也可以直接在ROOT logger打开INFO级别日志输出：
+
+```xml
+<root>
+ <level value="INFO" />
+ <appender-ref ref="CONSOLE"/>
+</root>
+```
+
+然后在日志中会有类似如下的内容输出：
+
+```
+The HTTP headers are:
+accept: application/json;charset=UTF-8
+accept-encoding: gzip, deflate
+connection: Keep-Alive
+content-length: 22
+content-type: application/json
+host: 192.168.1.100:8888
+user-agent: Apache-HttpClient/4.2.1 (java 1.5)
+```
+
+```
+The contents of request body is:
+{"id":1,"name":"dang"}
+```
+
+打开HTTP日志输出后，除了正常日志输出的性能开销外，也会在比如HTTP请求解析时产生额外的开销，因为需要建立额外的内存缓冲区来为日志的输出做数据准备。
+
+### 输入参数的校验
+
+dubbo的rest支持采用Java标准的bean validation annotation（JSR 303)来做输入校验http://beanvalidation.org/
+
+为了和其他dubbo远程调用协议保持一致，在rest中作校验的annotation必须放在服务的接口上，例如：
+
+```java
+public interface UserService {
+
+ User getUser(@Min(value=1L, message="User ID must be greater than 1") Long id);
+}
+
+```
+
+当然，在很多其他的bean validation的应用场景都是将annotation放到实现类而不是接口上。把annotation放在接口上至少有一个好处是，dubbo的客户端可以共享这个接口的信息，dubbo甚至不需要做远程调用，在本地就可以完成输入校验。
+
+然后按照dubbo的标准方式在XML配置中打开验证：
+
+```xml
+<dubbo:service interface=xxx.UserService" ref="userService" protocol="rest" validation="true"/>
+```
+
+在dubbo的其他很多远程调用协议中，如果输入验证出错，是直接将`RpcException`抛向客户端，而在rest中由于客户端经常是非dubbo，甚至非java的系统，所以不便直接抛出Java异常。因此，目前我们将校验错误以XML的格式返回：
+
+```xml
+<violationReport>
+ <constraintViolations>
+ <path>getUserArgument0</path>
+ <message>User ID must be greater than 1</message>
+ <value>0</value>
+ </constraintViolations>
+</violationReport>
+```
+
+稍后也会支持其他数据格式的返回值。至于如何对验证错误消息作国际化处理，直接参考bean validation的相关文档即可。
+
+如果你认为默认的校验错误返回格式不符合你的要求，可以如上面章节所述，添加自定义的ExceptionMapper来自由的定制错误返回格式。需要注意的是，这个ExceptionMapper必须用泛型声明来捕获dubbo的RpcException，才能成功覆盖dubbo rest默认的异常处理策略。为了简化操作，其实这里最简单的方式是直接继承dubbo rest的RpcExceptionMapper，并覆盖其中处理校验异常的方法即可：
+
+```java
+public class MyValidationExceptionMapper extends RpcExceptionMapper {
+
+ protected Response handleConstraintViolationException(ConstraintViolationException cve) {
+ ViolationReport report = new ViolationReport();
+ for (ConstraintViolation cv : cve.getConstraintViolations()) {
+ report.addConstraintViolation(new RestConstraintViolation(
+ cv.getPropertyPath().toString(),
+ cv.getMessage(),
+ cv.getInvalidValue() == null ? "null" : cv.getInvalidValue().toString()));
+ }
+ // 采用json输出代替xml输出
+ return Response.status(Response.Status.INTERNAL_SERVER_ERROR).entity(report).type(ContentType.APPLICATION_JSON_UTF_8).build();
+ }
+}
+```
+
+然后将这个ExceptionMapper添加到XML配置中即可：
+
+```xml
+<dubbo:protocol name="rest" port="8888" extension="xxx.MyValidationExceptionMapper"/>
+```
+
+### 是否应该透明发布REST服务
+
+Dubbo的REST调用和dubbo中其它某些RPC不同的是，需要在服务代码中添加JAX-RS的annotation（以及JAXB、Jackson的annotation），如果你觉得这些annotation一定程度“污染”了你的服务代码，你可以考虑编写额外的Facade和DTO类，在Facade和DTO上添加annotation，而Facade将调用转发给真正的服务实现类。当然事实上，直接在服务代码中添加annotation基本没有任何负面作用，而且这本身是Java EE的标准用法，另外JAX-RS和JAXB的annotation是属于java标准，比我们经常使用的spring、dubbo等等annotation更没有vendor lock-in的问题，所以一般没有必要因此而引入额外对象。
+
+另外，如果你想用前述的@Context annotation，通过方法参数注入HttpServletRequest（如`public User getUser(@PathParam("id") Long id, @Context HttpServletRequest request)`），这时候由于改变了服务的方法签名，并且HttpServletRequest是REST特有的参数，**所以如果你的服务要支持多种RPC机制的话**，则引入额外的Facade类是比较适当的。
+
+当然，在没有添加REST调用之前，你的服务代码可能本身已经就充当了Facade和DTO的角色（至于为什么有些场景需要这些角色，有兴趣可参考[微观SOA：服务设计原则及其实践方式](http://www.infoq.com/cn/articles/micro-soa-1)）。这种情况下，在添加REST之后，如果你再额外添加与REST相关的Facade和DTO，就相当于对原有代码对再一次包装，即形成如下调用链：
+
+`RestFacade/RestDTO -> Facade/DTO -> Service`
+
+这种体系比较繁琐，数据转换之类的工作量也不小，所以一般应尽量避免如此。
+
+### dubbo的提供端在调用REST服务时使用header
+
+Dubbo通过RpcContextFilter将header取出分解之后设置到RpcContext的attachments，所以在提供端可以直接从RpcContext的attachments中获取到消费端设置的header信息：
+
+```
+ RpcContext.getContext().getAttachment(key1)
+ RpcContext.getContext().getAttachment(key2)
+```
+
+## REST服务消费端详解
+
+这里我们用三种场景来分别讨论：
+
+1. 非dubbo的消费端调用dubbo的REST服务（non-dubbo --> dubbo）
+2. dubbo消费端调用dubbo的REST服务 （dubbo --> dubbo）
+3. dubbo的消费端调用非dubbo的REST服务 （dubbo --> non-dubbo）
+
+### 场景1：非dubbo的消费端调用dubbo的REST服务
+
+这种场景的客户端与dubbo本身无关，直接选用相应语言和框架中合适的方式即可。
+
+如果是还是java的客户端（但没用dubbo），可以考虑直接使用标准的JAX-RS Client API或者特定REST实现的Client API来调用REST服务。下面是用JAX-RS Client API来访问上述的UserService的registerUser()：
+
+```java
+User user = new User();
+user.setName("Larry");
+
+Client client = ClientBuilder.newClient();
+WebTarget target = client.target("http://localhost:8080/services/users/register.json");
+Response response = target.request().post(Entity.entity(user, MediaType.APPLICATION_JSON_TYPE));
+
+try {
+ if (response.getStatus() != 200) {
+ throw new RuntimeException("Failed with HTTP error code : " + response.getStatus());
+ }
+ System.out.println("The generated id is " + response.readEntity(RegistrationResult.class).getId());
+} finally {
+ response.close();
+ client.close(); // 在真正开发中不要每次关闭client，比如HTTP长连接是由client持有的
+}
+```
+
+上面代码片段中的User和RegistrationResult类都是消费端自己编写的，JAX-RS Client API会自动对它们做序列化/反序列化。
+
+当然，在java中也可以直接用自己熟悉的比如HttpClient，FastJson，XStream等等各种不同技术来实现REST客户端，在此不再详述。
+
+### 场景2：dubbo消费端调用dubbo的REST服务
+
+这种场景下，和使用其他dubbo的远程调用方式一样，直接在服务提供端和服务消费端共享Java服务接口，并添加spring xml配置（当然也可以用spring/dubbo的annotation配置），即可透明的调用远程REST服务：
+
+```xml
+<dubbo:reference id="userService" interface="xxx.UserService"/>
+```
+
+如前所述，这种场景下必须把JAX-RS的annotation添加到服务接口上，这样在dubbo在消费端才能共享相应的REST配置信息，并据之做远程调用:
+
+```java
+@Path("users")
+public interface UserService {
+
+ @GET
+ @Path("{id : \\d+}")
+ @Produces({MediaType.APPLICATION_JSON, MediaType.APPLICATION_XML})
+ User getUser(@PathParam("id") Long id);
+}
+```
+
+如果服务接口的annotation中配置了多种数据格式，这里由于两端都是dubbo系统，REST的大量细节被屏蔽了，所以不存在用前述URL后缀之类选择数据格式的可能。目前在这种情况下，排名最靠前的数据格式将直接被使用。
+
+因此，我们建议你在定义annotation的时候最好把最合适的数据格式放到前面，比如以上我们是把json放在xml前面，因为json的传输性能优于xml。
+
+### 场景3：dubbo的消费端调用非dubbo的REST服务
+
+这种场景下，可以直接用场景1中描述的Java的方式来调用REST服务。但其实也可以采用场景2中描述的方式，即更透明的调用REST服务，即使这个服务并不是dubbo提供的。
+
+如果用场景2的方式，由于这里REST服务并非dubbo提供，一般也就没有前述的共享的Java服务接口，所以在此我们需要根据外部REST服务的情况，自己来编写Java接口以及相应参数类，并添加JAX-RS、JAXB、Jackson等的annotation，dubbo的REST底层实现会据此去自动生成请求消息，自动解析响应消息等等，从而透明的做远程调用。或者这种方式也可以理解为，我们尝试用JAX-RS的方式去仿造实现一遍外部的REST服务提供端，然后把写成服务接口放到客户端来直接使用，dubbo的REST底层实现就能像调用dubbo的REST服务一样调用其他REST服务。
+
+例如，我们要调用如下的外部服务
+
+```
+http://api.foo.com/services/users/1001
+http://api.foo.com/services/users/1002
+```
+
+获取不同ID的用户资料，返回格式是JSON
+
+```javascript
+{
+ "id": 1001,
+ "name": "Larry"
+}
+```
+
+我们可根据这些信息，编写服务接口和参数类即可：
+
+```java
+@Path("users")
+public interface UserService {
+
+ @GET
+ @Path("{id : \\d+}")
+ @Produces({MediaType.APPLICATION_JSON})
+ User getUser(@PathParam("id") Long id);
+}
+```
+
+```java
+public class User implements Serializable {
+
+ private Long id;
+
+ private String name;
+
+ // …
+}
+```
+
+对于spring中的配置，因为这里的REST服务不是dubbo提供的，所以无法使用dubbo的注册中心，直接配置外部REST服务的url地址即可（如多个地址用逗号分隔）：
+
+```xml
+<dubbo:reference id="userService" interface="xxx.UserService" url="rest://api.foo.com/services/"/>
+```
+
+> 注意：这里协议必须用rest://而不是http://之类。如果外部的REST服务有context path，则在url中也必须添加上（除非你在每个服务接口的@Path annotation中都带上context path），例如上面的/services/。同时这里的services后面必须带上/，这样才能使dubbo正常工作。
+
+另外，这里依然可以配置客户端可启动的最大连接数和超时时间：
+
+```xml
+<dubbo:reference id="userService" interface="xxx.UserService" url="rest://api.foo.com/services/" timeout="2000" connections="10"/>
+```
+
+### dubbo的消费端在调用REST服务时配置自定义header
+
+Dubbo进行rest调用的时候，采用的是将RpcContext的attachment转换为header的方式，所以，dubbo消费端可以按以下方式进行自定义header的设置：
+
+```
+ RpcContext.getContext().setAttachment("key1", "value1");
+ RpcContext.getContext().setAttachment("key2", "value2");
+```
+
+即可设置如下格式的header:
+
+```
+ key1=value1
+ key2=value2
+```
+
+
+## Dubbo中JAX-RS的限制
+
+Dubbo中的REST开发是完全兼容标准JAX-RS的，但其支持的功能目前是完整JAX-RS的一个子集，部分因为它要受限于dubbo和spring的特定体系。
+
+在dubbo中使用的JAX-RS的局限包括但不限于：
+
+1. 服务实现只能是singleton的，不能支持per-request scope和per-lookup scope
+2. 不支持用@Context annotation对服务的实例字段注入 ServletConfig、ServletContext、HttpServletRequest、HttpServletResponse等等，但可以支持对服务方法参数的注入。但对某些特定REST server实现，（祥见前面的叙述），也不支持对服务方法参数的注入。
+
+## REST常见问题解答（REST FAQ）
+
+### Dubbo REST的服务能和Dubbo注册中心、监控中心集成吗？
+
+可以的，而且是自动集成的，也就是你在dubbo中开发的所有REST服务都会自动注册到注册中心和监控中心，可以通过它们做管理。
+
+但是，只有当REST的消费端也是基于dubbo的时候，注册中心中的许多服务治理操作才能完全起作用。而如果消费端是非dubbo的，自然不受注册中心管理，所以其中很多操作是不会对消费端起作用的。
+
+### Dubbo REST中如何实现负载均衡和容错（failover）？
+
+如果dubbo REST的消费端也是dubbo的，则Dubbo REST和其他dubbo远程调用协议基本完全一样，由dubbo框架透明的在消费端做load balance、failover等等。
+
+如果dubbo REST的消费端是非dubbo的，甚至是非java的，则最好配置服务提供端的软负载均衡机制，目前可考虑用LVS、HAProxy、 Nginx等等对HTTP请求做负载均衡。
+
+### JAX-RS中重载的方法能够映射到同一URL地址吗？
+
+http://stackoverflow.com/questions/17196766/can-resteasy-choose-method-based-on-query-params
+
+### JAX-RS中作POST的方法能够接收多个参数吗？
+
+http://stackoverflow.com/questions/5553218/jax-rs-post-multiple-objects
+
+## Dubbo当前体系的不足之处（与REST相关的）
+
+我认为dubbo当前体系中显然也有不少不足之处，这里列出几个与REST有关的、并影响用户使用的问题（不包括内部实现的问题），供参考评论，为下一步重构作准备。
+
... 4142 lines suppressed ...