-
-## 使用Sermant后
-如下图所示: 文档中演示使用的应用示例在使用Sermant时, Sermant会将原本注册到Zookeeper的应用信息注册到ServiceCenter中; Sermant采用zookeeper作为默认的配置中心，向插件提供了动态配置管理的能力。
-
-
-
-# 获取编译结果
-
-## 下载release包
-点击 [here](https://github.com/huaweicloud/Sermant/releases) 下载release包
-
-## 源码编译
-- 编译机器需具备[git](https://git-scm.com/downloads) , [jdk 8或11](https://www.oracle.com/java/technologies/downloads/) , [maven](https://maven.apache.org/download.cgi) 环境
-- 执行`git clone -b main https://github.com/huaweicloud/Sermant-examples.git` 克隆最新源码
-- 执行`cd sermant-template`进入源码目录
-- 执行`mvn clean package` 编译示例项目, 将在`sermant-template`目录下生成`agent`文件夹，包含sermant示例组件
-
-# 启动
-- 运行环境需要具备[ServiceCenter](https://github.com/apache/servicecomb-service-center/releases) ,[zookeeper](https://zookeeper.apache.org/releases.html) 分别作为注册中心和配置中心。
-
-- 进入编译后可执行文件根目录(例如:**sermant-agent-1.0.0**)
-
-- 执行以下命令启动backend，详细的后端模块介绍以及更多的配置修改，请参考[backend模块](user-guide/backend-zh.md)
- ```bash
- # windows
- java -jar server\sermant\sermant-backend-x.x.x.jar
-
- # mac, linux
- java -jar server/sermant/sermant-backend-x.x.x.jar
- ```
-
-- 执行以下命令启动注册插件provider示例应用(请自行下载[示例应用源码](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-register/resttemplate-provider))
-
- ```bash
- # windows
- java -javaagent:agent\sermant-agent.jar=appName=provider -jar resttemplate-provider.jar
- # mac linux
- java -javaagent:agent/sermant-agent.jar=appName=provider -jar resttemplate-provider.jar
- ```
-
-- 执行以下命令启动注册插件consumer示例应用(请自行下载[示例应用源码](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-register/resttemplate-consumer))
- ```bash
- # windows
- java -javaagent:agent\sermant-agent.jar=appName=consumer -jar resttemplate-consumer.jar
- # mac linux
- java -javaagent:agent/sermant-agent.jar=appName=consumer -jar resttemplate-consumer.jar
- ```
-
-- 浏览器访问：[http://localhost:8900](http://localhost:8900) 查看框架和启用插件的运行状态。
- 
-
-- 浏览器访问：[http://localhost:30103](http://localhost:30103) 查看应用注册状态。
- 
-
-- 浏览器访问：[http://localhost:8005/hello](http://localhost:8005/hello) 验证provider和consumer注册和订阅成功。
-
- 
-
-## 查看日志
-Sermant和Backend日志的存放目录分别位于sermant运行环境下`./logs/sermant/core`和`./logs/sermant/backend`
-
-## 相关文档
-
-插件开发, 请参考 [插件开发相关文档](./README-zh.md)。
-
-常见问题说明与解决指导,请参考[FAQ](./FAQ-zh.md)。
\ No newline at end of file
diff --git a/docs/QuickStart.md b/docs/QuickStart.md
deleted file mode 100644
index c16234b59b..0000000000
--- a/docs/QuickStart.md
+++ /dev/null
@@ -1,76 +0,0 @@
-# Quick Start Instructions for Service Registration and Discovery
-
-[简体中文](QuickStart-zh.md) | [English](QuickStart.md)
-
-Based on the scenario where the host application changes the registration center, we will use the registration plugin of the Sermant framework, and fully show how to use the Sermant plugin to non-invasively extend the functionality of the host application.
-
-In addition, refer to [List of Plugin Functions](user-guide/feature-list.md) to get more plugin functions.
-
-## Before Adopting Sermant
-The following figure shows the example application demonstrated in this documentation is registered with Zookeeper when Sermant is not used.
-
-
-## After Adopting Sermant
-This figure shows When using a Sermant, the Sermant registers the application information which originally registered with Zookeeper to ServiceCenter. Sermant adopts ZooKeeper as the default configuration center to provide dynamic configuration management capabilities to the plugins.
-
-
-
-# Get Compiled Products
-
-## Download the release package
-Click [here](https://github.com/huaweicloud/Sermant/releases) to download the release package
-
-## Compile Source Code
-- Prepare [git](https://git-scm.com/downloads) , [jdk 8 or 11](https://www.oracle.com/java/technologies/downloads/) , [maven](https://maven.apache.org/download.cgi) for your machine
-- execute `git clone -b main https://github.com/huaweicloud/Sermant-examples.git` to clone the source code
-- execute `cd sermant-template`to entry into Sermant directory
-- execute `mvn clean package` to compile source code of Sermant, which genetates `agent` in `sermant-template` that contains example package.
-
-# Startup
-- Runtime environment requires [ServiceCenter](https://github.com/apache/servicecomb-service-center/releases), and [zookeeper](https://zookeeper.apache.org/releases.html) as the registration center and configuration center respectively.
-
-- entry into the root directory of the compiled executable file(e.g. **sermant-agent-1.0.0**).
-
-- To start Backend, run the following command. For a detailed description of the backend module and more configuration modifications, please refer to [Backend Module](user-guide/backend.md).
- ```bash
- # windows
- java -jar server\sermant\sermant-backend-x.x.x.jar
-
- # mac, linux
- java -jar server/sermant/sermant-backend-x.x.x.jar
- ```
-
-- Execute the following command to launch the sample provider application that mounts the register plugin.(Download [source code of demo](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-register/resttemplate-provider))
- ```bash
- # windows
- java -javaagent:agent\sermant-agent.jar=appName=provider -jar resttemplate-provider.jar
- # mac linux
- java -javaagent:agent/sermant-agent.jar=appName=provider -jar resttemplate-provider.jar
- ```
-
-- Execute the following command to launch the sample consumer application that mounts the register plugin.(Download [source code of demo](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-register/resttemplate-consumer))
- ```bash
- # windows
- java -javaagent:agent\sermant-agent.jar=appName=consumer -jar resttemplate-consumer.jar
- # mac linux
- java -javaagent:agent/sermant-agent.jar=appName=consumer -jar resttemplate-consumer.jar
- ```
-
-- Open a browser to access: http://localhost:8900 to check the running state of Sermant and the enabled plugin.
- 
-
-- Open a browser to access:[http://localhost:30103](http://localhost:30103) to check the application registration status.
- 
-
-- Open a browser to access:[http://localhost:8005/hello](http://localhost:8005/hello) to check if the provider and consumer registered and subscribed successfully
-
-
-
-## Check Logs
-The log directories for Sermant and Backend are located in `./logs/sermant/core ` and `./logs/sermant/backend` respectively in the environment of host application.
-
-## Related Documents
-
-For plugin development, please refer to [Introduction to Sermant Development and Usage](./README.md).
-
-Frequently asked questions and solution guidance, please refer to [FAQ](./FAQ.md).
\ No newline at end of file
diff --git a/docs/README-zh.md b/docs/README-zh.md
deleted file mode 100644
index 6fa9560c2d..0000000000
--- a/docs/README-zh.md
+++ /dev/null
@@ -1,95 +0,0 @@
-# Sermant 开发和使用介绍
-
-[简体中文](README-zh.md) | [English](README.md)
-
-Sermant 是基于Java Agent的字节码增强技术，通过 Java Agent 对宿主应用进行非侵入式增强，以解决Java应用的微服务治理问题。Sermant的初衷是建立一个面向微服务治理的对开发态无侵入的解决方案生态，降低服务治理开发和使用的难度，通过抽象接口、功能整合、插件隔离等手段，达到简化开发、功能即插即用的效果。
-
-本文档对如何开发和使用 Sermant 做详细介绍。
-
-## 运行环境
-
-- [HuaweiJDK 1.8](https://gitee.com/openeuler/bishengjdk-8) / [OpenJDK 1.8](https://github.com/openjdk/jdk) / [OracleJDK 1.8](https://www.oracle.com/java/technologies/downloads/)
-- [Apache Maven 3](https://maven.apache.org/download.cgi)
-
-## 模块说明
-
-**Sermant**包含以下模块：
-
-- [sermant-agentcore](../sermant-agentcore): *Java Agent*相关内容
- - [sermant-agentcore-core](../sermant-agentcore/sermant-agentcore-core): 核心功能模块
- - [sermant-agentcore-premain](../sermant-agentcore/sermant-agentcore-premain): *Java Agent*入口模块
- - [sermant-agentcore-config](../sermant-agentcore/sermant-agentcore-config): 配置模块
-- [sermant-backend](../sermant-backend): 消息发送模块服务端
-- [sermant-package](../sermant-package): 打包模块
-- [sermant-plugins](../sermant-plugins): 插件根模块，内含各种功能的插件及相关附加件
-- [sermant-injector](../sermant-injector): sermant-agent容器化部署Admission Webhook组件
-
-## 打包流程
-
-**Sermant**的打包流程大致分为以下步骤：
-
-- *agent*: 编译、打包核心功能和插件
-- *example*: 编译、打包核心功能和示例模块(默认不开启)
-- *backend*: 编译、打包**Sermant**后端模块
-- *ext*: 编译、打包插件附带的后端、前端和其他附加件
-- *package*: 将以上的打包结果归档为产品包
-- *release*: 发布构建产物到中央仓库
-- *all*: 执行以上全部步骤(默认不开启)
-
-执行以下*maven*命令，对**Sermant**工程进行默认打包：
-
-```shell
-mvn clean package -Dmaven.test.skip
-```
-
-命令执行完毕后，工程目录下将生成一个形如`sermant-agent-x.x.x`的文件夹和形如`sermant-agent-x.x.x.tar.gz`的压缩文件，后者为**Sermant**的产品包，前者则为产品包解压后的内容。
-
-## 产品目录说明
-
-- *agent*: Java Agent相关内容
- - *config*: 配置文件目录
- - *bootstrap.properties*: 启动配置
- - *config.properties*: 核心功能配置
- - *plugins.yaml*: 插件配置，配置着需要被加载的插件功能
- - *core/sermant-agentcore-core-x.x.x.jar*: **Sermant**的核心功能包
- - *pluginPackage*: 插件包目录，插件按功能名称分类
- - *xxx*: 任意插件功能
- - *config/config.yaml*: 插件配置文件
- - *plugin*: 插件包目录
- - *service*: 插件服务包目录
- - *sermant-agent.jar*: JavaAgent入口包
-- *server*: 服务器目录，含**Sermant**的服务端，插件的服务端和客户端
-
-## 容器化部署说明
-k8s环境下，Sermant支持通过sermant-injector组件实现宿主应用自动挂载sermant-agent包的快速部署方式。如何部署sermant-injector与宿主应用可以参考[容器化部署指导手册](user-guide/injector-zh.md)
-
-## 插件开发
-
-如何新增一个插件可以参考[插件模块开发手册](dev-guide/dev_plugin_module-zh.md)，其中涉及添加插件、插件服务及附加件的详细流程。
-
-如何编写一个插件的内容可以参考[插件代码开发手册](dev-guide/dev_plugin_code-zh.md)，其中涉及大部分开发插件过程中可能遇到场景。
-
-## 相关文档
-
-|文档名称|文档类型|
-|---|---|
-|[第三方版权说明手册](dev-guide/third_party_copyright-zh.md)|开发手册|
-|[版本管理手册](dev-guide/version_manage-zh.md)|开发手册|
-|[插件模块开发手册](dev-guide/dev_plugin_module-zh.md)|开发手册|
-|[插件代码开发手册](dev-guide/dev_plugin_code-zh.md)|开发手册|
-|[插件去源码开发指导](dev-guide/dev_plugin_introduce-zh.md)|开发手册|
-|[动态配置服务介绍](dev-guide/service_dynamicconfig-zh.md)|开发手册|
-|[心跳服务介绍](dev-guide/service_heartbeat-zh.md)|开发手册|
-|[网关服务介绍](dev-guide/service_send-zh.md)|开发手册|
-|[核心模块介绍](user-guide/agentcore-zh.md)|使用手册|
-|[入口模块介绍](user-guide/entrance-zh.md)|使用手册|
-|[后端模块介绍](user-guide/backend-zh.md)|使用手册|
-|[容器化部署指导手册](user-guide/injector-zh.md) |使用手册|
-|[限流降级功能介绍](user-guide/flowcontrol/flowcontrol-zh.md)|使用手册|
-|[负载均衡功能介绍](user-guide/loadbalancer/document-zh.md)|使用手册|
-|[动态配置功能介绍](user-guide/dynamic-config/document-zh.md)|使用手册|
-|[服务注册功能介绍](user-guide/registry/document-zh.md)|使用手册|
-|[优雅上下线功能介绍](user-guide/graceful/document-zh.md)|使用手册|
-|[标签路由功能介绍](user-guide/router/document-zh.md)|使用手册|
-|[当前插件功能汇总列表](user-guide/feature-list-zh.md)|使用手册|
-|[常见问题说明指导](./FAQ-zh.md)|使用手册|
\ No newline at end of file
diff --git a/docs/README.md b/docs/README.md
deleted file mode 100644
index 3ebbb96799..0000000000
--- a/docs/README.md
+++ /dev/null
@@ -1,96 +0,0 @@
-# Introduction to Sermant Development and Usage
-
-[简体中文](README-zh.md) | [English](README.md)
-
-Sermant is a bytecode enhancement technology based on Java Agent. It uses Java Agent to enhance the host application in a non-intrusive way to solve the microservice governance problem of Java applications. The original intention of Sermant is to establish a solution ecosystem for micro-service governance that is non-intrusive to the development state, reduce the difficulty of service governance development and use, and achieve the effect of simplified development and plug-and-play by means of abstract interface, function integration and plugin isolation.
-
-This document describes how to develop and use Sermant in detail.
-
-## Runtime Environment
-
-- [HuaweiJDK 1.8](https://gitee.com/openeuler/bishengjdk-8) / [OpenJDK 1.8](https://github.com/openjdk/jdk) / [OracleJDK 1.8](https://www.oracle.com/java/technologies/downloads/)
-- [Apache Maven 3](https://maven.apache.org/download.cgi)
-
-## Project Modules
-
-**Sermant** contains the following modules:
-
-- [sermant-agentcore](../sermant-agentcore): *Java Agent* related content
- - [sermant-agentcore-core](../sermant-agentcore/sermant-agentcore-core): Core functional module of the framework
- - [sermant-agentcore-premain](../sermant-agentcore/sermant-agentcore-premain): *Java Agent* entry module
- - [sermant-agentcore-config](../sermant-agentcore/sermant-agentcore-config): Configuration module of the framework
-- [sermant-backend](../sermant-backend): Server side of message sending module
-- [sermant-package](../sermant-package): Packaging module
-- [sermant-plugins](../sermant-plugins): Root module of plugins, contains a variety of functional plugins and related add-ons
-- [sermant-injector](../sermant-injector): Admission webhook module for deployment of sermant-agent via containers
-
-## Packaging Steps
-
-The packaging process of **Sermant** is roughly divided into the following steps:
-
-- *agent*: Compile or package core function and plugins
-- *example*: Compile or package core function and demo modules(disabled by default)
-- *backend*: Compile or package **Sermant** backend module
-- *ext*: Compile and package the backend, frontend, and other add-ons that come with plugins
-- *package*: Archive the above packaging results as a product package
-- *release*: Publish built artifacts to Maven Central Repository
-- *all*: Perform all the preceding steps (disabled by default)
-
-Execute the following *maven* command package the **Sermant** project by default：
-
-```shell
-mvn clean package -Dmaven.test.skip
-```
-
-After the command is executed, a folder such as `sermant-agent-x.x.x` and a compressed file such as `sermant-agent-x.x.x.tar.gz` will be generated in the project directory. The latter is the product package of **sermant** and the former is the decompressed content of the product package.
-
-## Product Directory
-
-- *agent*: Java Agent related product
- - *config*: Configuration file directory
- - *bootstrap.properties*: Startup configuration
- - *config.properties*: Core function configuration
- - *plugins.yaml*: Plugin configuration, which config the plugin functionality that needs to be loaded
- - *core/sermant-agentcore-core-x.x.x.jar*: Core package of **Sermant** framework
- - *pluginPackage*: Plugin package directory, where plugins are classified by feature name
- - *xxx*: Any plugin functionality
- - *config/config.yaml*: Plugin configuration file
- - *plugin*: Plugin package directory
- - *service*: plugin service's package directory
- - *sermant-agent.jar*: Java Agent entry package
-- *server*: Server directory, which contains server with **Sermant**, plugin server and client
-
-## Containerized Deployment
-In K8S environment, Sermant supports quickly deployment by using Sermant-Injector module to automatically mount Sermant-Agent package for host application. To know more about deploying Sermant-Injector and host applications, you can refer to [Containerized Deployment Guide](user-guide/injector.md).
-
-## Plugin Development
-
-How to develop a new plugin module？You can refer to the [Plugin Module Development Guide](dev-guide/dev_plugin_module.md) for details on adding plugins, plugin services, and add-ons.
-
-How to write a plugin can be found in the [Plugin Code Development Guide](dev-guide/dev_plugin_code.md), which covers most of the possible scenarios in developing a plugin.
-
-## Other Related Documents
-
-|Document Name|Type of Document|
-|---|---|
-|[Third Party Copyright Declaration](dev-guide/third_party_copyright.md)|Development Guide|
-|[Version Management Guide](dev-guide/version_manage.md)|Development Guide|
-|[Plugin Module Development Guide](dev-guide/dev_plugin_module.md)|Development Guide|
-|[Plugin Code Development Guide](dev-guide/dev_plugin_code.md)|Development Guide|
-|[Plugin without Source Code Development Guide](dev-guide/dev_plugin_introduce.md)|Development Guide|
-|[Introduction to Dynamic Configuration Service](dev-guide/service_dynamicconfig.md)|Development Guide|
-|[Introduction to Heartbeat Service](dev-guide/service_heartbeat.md)|Development Guide|
-|[Introduction to Gateway Service](dev-guide/service_send.md)|Development Guide|
-|[Introduction to Core Modules](user-guide/agentcore.md)|User Guide|
-|[Introduction to Sermant Entrance Module](user-guide/entrance.md)|User Guide|
-|[Introduction to Backend Module](user-guide/backend.md)|User Guide|
-|[Containerized Deployment Guide](user-guide/injector.md) |User Guide|
-|[Introduction to Flow Control and Degradation](user-guide/flowcontrol/flowcontrol.md)|User Guide|
-|[Introduction to Loadbalancer](user-guide/loadbalancer/document.md)|User Guide|
-|[Introduction to Dynamic Configuration](user-guide/dynamic-config/document.md)|User Guide|
-|[Introduction to Service Registration](user-guide/registry/document.md)|User Guide|
-|[Introduction to Tag Router](user-guide/router/document.md)|User Guide|
-|[Introduction to Graceful online/offline](user-guide/graceful/document.md)|User Guide|
-|[Summary List of Current Plugin Features](user-guide/feature-list.md)|User Guide|
-|[FAQ](./FAQ.md)|User Guide|
-
diff --git a/docs/binary-docs/add_archetype.png b/docs/binary-docs/add_archetype.png
deleted file mode 100644
index c2b591aa8f..0000000000
Binary files a/docs/binary-docs/add_archetype.png and /dev/null differ
diff --git a/docs/binary-docs/after_use_agent.png b/docs/binary-docs/after_use_agent.png
deleted file mode 100644
index 738658847a..0000000000
Binary files a/docs/binary-docs/after_use_agent.png and /dev/null differ
diff --git a/docs/binary-docs/archetype_info.png b/docs/binary-docs/archetype_info.png
deleted file mode 100644
index 8b17bed8d4..0000000000
Binary files a/docs/binary-docs/archetype_info.png and /dev/null differ
diff --git a/docs/binary-docs/before_use_agent.png b/docs/binary-docs/before_use_agent.png
deleted file mode 100644
index 3b729bd940..0000000000
Binary files a/docs/binary-docs/before_use_agent.png and /dev/null differ
diff --git a/docs/binary-docs/check_application.png b/docs/binary-docs/check_application.png
deleted file mode 100644
index 6b974abc2e..0000000000
Binary files a/docs/binary-docs/check_application.png and /dev/null differ
diff --git a/docs/binary-docs/contribute.png b/docs/binary-docs/contribute.png
deleted file mode 100644
index 3b6bca1f90..0000000000
Binary files a/docs/binary-docs/contribute.png and /dev/null differ
diff --git a/docs/binary-docs/contributor_definition.png b/docs/binary-docs/contributor_definition.png
deleted file mode 100644
index 7610295ba6..0000000000
Binary files a/docs/binary-docs/contributor_definition.png and /dev/null differ
diff --git a/docs/binary-docs/create_project_by_template.png b/docs/binary-docs/create_project_by_template.png
deleted file mode 100644
index 8f67004337..0000000000
Binary files a/docs/binary-docs/create_project_by_template.png and /dev/null differ
diff --git a/docs/binary-docs/create_project_by_template_result.png b/docs/binary-docs/create_project_by_template_result.png
deleted file mode 100644
index 3310187a4f..0000000000
Binary files a/docs/binary-docs/create_project_by_template_result.png and /dev/null differ
diff --git a/docs/binary-docs/idea_new_project.png b/docs/binary-docs/idea_new_project.png
deleted file mode 100644
index 9add4d8bb2..0000000000
Binary files a/docs/binary-docs/idea_new_project.png and /dev/null differ
diff --git a/docs/binary-docs/register-application.PNG b/docs/binary-docs/register-application.PNG
deleted file mode 100644
index f402ba08ef..0000000000
Binary files a/docs/binary-docs/register-application.PNG and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-1.png b/docs/binary-docs/registry-faq-1.png
deleted file mode 100644
index 06098d8dda..0000000000
Binary files a/docs/binary-docs/registry-faq-1.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-2.png b/docs/binary-docs/registry-faq-2.png
deleted file mode 100644
index ecbc339ba0..0000000000
Binary files a/docs/binary-docs/registry-faq-2.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-3.png b/docs/binary-docs/registry-faq-3.png
deleted file mode 100644
index 743a927e01..0000000000
Binary files a/docs/binary-docs/registry-faq-3.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-4.png b/docs/binary-docs/registry-faq-4.png
deleted file mode 100644
index 5a4d0ca1e2..0000000000
Binary files a/docs/binary-docs/registry-faq-4.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-5.png b/docs/binary-docs/registry-faq-5.png
deleted file mode 100644
index 4ca03e934e..0000000000
Binary files a/docs/binary-docs/registry-faq-5.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-6.png b/docs/binary-docs/registry-faq-6.png
deleted file mode 100644
index 544fca0840..0000000000
Binary files a/docs/binary-docs/registry-faq-6.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-7.png b/docs/binary-docs/registry-faq-7.png
deleted file mode 100644
index c2b3b94117..0000000000
Binary files a/docs/binary-docs/registry-faq-7.png and /dev/null differ
diff --git a/docs/binary-docs/registry-faq-8.png b/docs/binary-docs/registry-faq-8.png
deleted file mode 100644
index 68025d5d65..0000000000
Binary files a/docs/binary-docs/registry-faq-8.png and /dev/null differ
diff --git a/docs/binary-docs/sermant-classloader-arch.png b/docs/binary-docs/sermant-classloader-arch.png
deleted file mode 100644
index 464bad464d..0000000000
Binary files a/docs/binary-docs/sermant-classloader-arch.png and /dev/null differ
diff --git a/docs/binary-docs/sermant-register-migration-en.png b/docs/binary-docs/sermant-register-migration-en.png
deleted file mode 100644
index 68f3d6d987..0000000000
Binary files a/docs/binary-docs/sermant-register-migration-en.png and /dev/null differ
diff --git a/docs/binary-docs/sermant-register-migration.png b/docs/binary-docs/sermant-register-migration.png
deleted file mode 100644
index 44e6ce8266..0000000000
Binary files a/docs/binary-docs/sermant-register-migration.png and /dev/null differ
diff --git a/docs/dev-guide/dev_plugin_code-zh.md b/docs/dev-guide/dev_plugin_code-zh.md
deleted file mode 100644
index 96c567e8df..0000000000
--- a/docs/dev-guide/dev_plugin_code-zh.md
+++ /dev/null
@@ -1,582 +0,0 @@
-# 插件代码开发手册
-
-[简体中文](dev_plugin_code-zh.md) | [English](dev_plugin_code.md)
-
-本文档主要针对**Sermant**的[示例模块](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template)，介绍插件开发过程中常见的一些场景。
-
-- [组成部分](#组成部分)
-- [插件模块](#插件模块)
- - [增强定义](#增强定义)
- - [原生类增强](#原生类增强)
- - [拦截器](#拦截器)
- - [插件配置](#插件配置)
- - [插件服务](#插件服务)
- - [简单插件服务](#简单插件服务)
- - [复杂插件服务](#复杂插件服务)
- - [日志功能](#日志功能)
- - [心跳功能](#心跳功能)
- - [链路功能](#链路功能)
- - [动态配置功能](#动态配置功能)
-- [插件服务模块](#插件服务模块)
-
-## 组成部分
-
-由[插件模块开发手册](dev_plugin_module-zh.md)可知，一个`插件主模块(main)`中可能包含以下5种内容：
-
-- `插件模块(plugin)`，该模块主要用于声明对宿主应用的增强逻辑
-- `服务模块(service)`，用于为插件包提供服务实现
-- `后端模块(server)`，用于接收插件数据的服务端
-- `前端模块(webapp)`，用于对服务端数据作前端展示
-- `其他模块(other)`，特殊附加件，一般用作调试
-
-考虑到后三者随实际业务场景不同有较大变化，因此赋予他们的开发自由度较高，对他们仅有模块目录和输出目录的限制。出于这点考虑，`示例模块`将不对他们做参考案例。`示例模块`中包含以下模块：
-
-- [template-plugin](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin): 示例插件
-- [template-service](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-service): 示例插件服务
-- [demo-application](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-application): 示例宿主应用
-
-## 插件模块
-
-示例插件模块`template-plugin`中，主要用于向插件开发者展示在插件开发过程中可能遇到的一些场景以及可能使用到的一些功能。
-
-开始之前，必须约定的就是，`插件模块(plugin)`中，开发者只能使用*Java*原生API和[**Sermant**核心功能模块](../../sermant-agentcore/sermant-agentcore-core)中的API，不能依赖或使用任何`byte-buddy`与`slf4j`以外的第三方依赖。如果应业务要求，需要使用其他第三方依赖的话，只能在`插件模块(plugin)`中定义接口，在`服务模块(service)`中编写实现。更多相关内容详见[插件模块开发手册](dev_plugin_module-zh.md#添加插件模块)。
-
-### 增强定义
-
-**Sermant**的核心能力是对宿主应用做非侵入式的字节码增强，而这些增强规则则是插件化的。在每个**Sermant**的`插件主模块(main)`中，都可以定义一些增强定义，针对宿主应用的某些特定方法进行字节码增强，从而实现某种功能。因此`插件主模块(main)`如何告知**Sermant**该增强哪些类，是一个重要的课题。
-
-插件的增强定义需要实现[PluginDeclarer](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/declarer/PluginDeclarer.java)接口，其中包含两个接口方法：
-
-- `getClassMatcher`方法用于获取被增强类的匹配器[ClassMatcher](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/matcher/ClassMatcher.java)。
-- `getInterceptDeclarers`方法用于获取被增强类的拦截点方法，以及嵌入其中的拦截器，他们封装于方法拦截点[InterceptDeclarer](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/declarer/InterceptDeclarer.java)中。
-- `getSuperTpeDecarers`方法用于获取插件的超类声明[SuperTypeDeclarer](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/declarer/SuperTypeDeclarer.java)
-
-对匹配器 [ClassMatcher](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/matcher/ClassMatcher.java)，在核心模块中提供了两种类型的匹配器：
-
-[ClassTypeMatcher](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/matcher/ClassTypeMatcher.java)(类的类型匹配器)
-
-- 完全通过名称匹配，也是最常见的定位方式，通过以下方法获取：
- ```java
- ClassMatcher.nameEquals("${class reference}");
- ```
- 其中`${class reference}`为被增强类的全限定名。
-
-
-- 通过名称匹配多个类，属于`nameEquals`的复数版，可通过以下方法获取：
- ```java
- ClassMatcher.nameContains("${class reference array}");
- ```
- 其中`${class reference array}`为被增强类的全限定名可变数组。
-
-[ClassFuzzyMatcher](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/matcher/ClassFuzzyMatcher.java)（类的模糊匹配器）
-
-- 通过全限定名前缀定位到被增强类，可通过以下方法获取：
- ```java
- ClassMatcher.namePrefixedWith("${prefix}");
- ```
- 其中`${prefix}`为全限定名前缀。
-
-
-- 通过全限定名后缀定位到被增强类，可以通过一下方法获取：
- ```java
- ClassMatcher.nameSuffixedWith("${suffix}")
- ```
- 其中`${suffix}`为全限定名后缀。
-
-
-- 通过全限定名内缀定位到被增强类，可以通过以下方法获取：
- ```java
- ClassMatcher.nameinfixedWith("${infix}")
- ```
- 其中`${infix}`为全限定名内缀。
-
-
-- 通过正则表达式匹配全限定名定位到被增强类，可以通过以下方法获取：
- ```java
- ClassMatcher.nameMatches("${pattern}")
- ```
- 其中`${pattern}`为正则表达式。
-
-
-- 通过注解定位到被该注解修饰的类，可通过以下方法获取：
- ```java
- ClassMatcher.isAnnotationWith("${annotation reference array}");
- ```
- 其中`${annotation reference array}`为注解的全限定名可变数组。
-
-
-- 通过超类定位到该类的子类，可通过以下方法获取：
- ```java
- ClassMatcher.isExtendedFrom("${super class array}");
- ```
- 其中`${super class array}`为超类可变数组。考虑到Java的继承规则，该数组只能有一个`Class`，其余必须全为`Interface`。
-
-
-- 匹配的逻辑操作，匹配器全部不匹配时为真：
- ```java
- ClassMatcher.not("${class matcher array}")
- ```
- 其中`${class matcher array}`为匹配器可变长数组
-
-
-- 匹配的逻辑操作，匹配器全部都匹配时为真：
- ```java
- ClassMatcher.and("${class matcher array}")
- ```
- 其中`${class matcher array}`为匹配器可变长数组
-
-
-- 匹配的逻辑操作，匹配器其中一个匹配时为真：
- ```java
- ClassMatcher.or("${class matcher array}")
- ```
- 其中`${class matcher array}`为匹配器可变长数组
-
-对于方法拦截点[MethodMatcher](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/matcher/MethodMatcher.java)，提供了多种匹配方法：
-
-- 全数匹配：
- ```java
- MethodMatcher.any();
- ```
-- 名称匹配：
- ```java
- MethodMatcher.nameEquals("${method name}");
- ```
- 其中`${method name}`为方法名称。
-
-
-- 匹配静态方法：
- ```java
- MethodMatcher.isStaticMethod();
- ```
-- 匹配构造函数：
- ```java
- MethodMatcher.isConstructor();
- ```
-- 匹配多个方法：
- ```java
- MethodMatcher.nameContains("${method name array}");
- ```
- 其中`${method name array}`为方法名称数组。
-
-
-- 根据方法名称前缀匹配：
- ```java
- MethodMatcher.namePrefixedWith("${method name prefix}");
- ```
- 其中`${method name prefix}`为方法名称前缀。
-
-
-- 根据方法名称后缀匹配：
- ```java
- MethodMatcher.nameSuffixedWith("${method name suffix}");
- ```
- 其中`${method name suffix}`为方法名称后缀。
-
-
-- 根据方法名称内缀匹配：
- ```java
- MethodMatcher.nameinfixedWith("${method name infix}");
- ```
- 其中`${method name infix}`为方法名称内缀。
-
-
-- 根据正则表达式匹配：
- ```java
- MethodMatcher.nameMatches("${pattern}");
- ```
- 其中`${pattern}`为正则表达式。
-
-
-- 匹配被传入注解修饰的方法：
- ```java
- MethodMatcher.isAnnotatedWith("${annotations array}");
- ```
- 其中`${annotations array}`为注解集。
-
-
-- 匹配指定入参数量的方法：
- ```java
- MethodMatcher.paramCountEquals("${param count}");
- ```
- 其中`${param count}`为入参数量。
-
-
-- 匹配指定入参类型的方法：
- ```java
- MethodMatcher.paramTypeEquals("${param type array}");
- ```
- 其中`${param type array}`为入参类型集。
-
-
-- 匹配指定返回值类型的方法：
- ```java
- MethodMatcher.resultTypeEquals("${result type}");
- ```
- 其中`${result type}`返回值类型。
-
-
-- 逻辑操作，方法匹配器集全不匹配时则结果为真
- ```java
- MethodMatcher.not("${element matcher array}");
- ```
- 其中`${element matcher array}`为方法匹配器集。
-
-
-- 逻辑操作，方法匹配器集全匹配时则结果为真
- ```java
- MethodMatcher.and("${element matcher array}");
- ```
- 其中`${element matcher array}`为方法匹配器集。
-
-
-- 逻辑操作，方法匹配器集其中一个匹配时则结果为真
- ```java
- MethodMatcher.or("${element matcher array}");
- ```
- 其中`${element matcher array}`为方法匹配器集。
-
-更多方法匹配方式可以参考[byte-buddy](https://javadoc.io/doc/net.bytebuddy/byte-buddy/latest/net/bytebuddy/matcher/ElementMatchers.html)中含`MethodDescription`泛型的方法。
-
-开发到最后，不要忘记添加`PluginDeclarer`接口的*SPI*配置文件：
-
-- 在资源目录`resources`下添加`META-INF/services`文件夹。
-- 在`META-INF/services`中添加`com.huaweicloud.sermant.core.plugin.agent.declarer.PluginDeclarer`配置文件。
-- 在上述文件中，以换行为分隔，键入插件包中所有的增强定义`PluginDeclarer`实现。
-
-**Sermant**的`示例模块`中包含以下`PluginDeclarer`接口的实现示例：
-
-- [DemoAnnotationDeclarer](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/declarer/DemoAnnotationDeclarer.java): 通过注解定位被修饰类的普通增强定义
-- [DemoNameDeclarer](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/declarer/DemoNameDeclarer.java): 通过名称定位到被增强类的普通增强定义
-- [DemoSuperTypeDeclarer](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/declarer/DemoSuperTypeDeclarer.java): 通过超类定位到被增强子类的普通增强定义
-- [DemoBootstrapDeclarer](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/declarer/DemoBootstrapDeclarer.java): 对启动类加载器进行增强的定义，详见[原生类增强](#原生类增强)一节
-- [DemoTraceDeclarer](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/declarer/DemoTraceDeclarer.java): 对示例应用使用链路功能的增强定义，详见[链路功能](#链路功能)一节
-
-在各插件开发者在编写插件增强定义的时候，可以以以上示例为参考，开发符合自身需要的增强定义。
-
-#### 原生类增强
-
-对于`java.lang.Thread`等*Java*原生类，他们由启动类加载器`BootStrapClassLoader`加载，对他们进行增强的话，主要会面临两个困难：
-
-- 原生类被启动类加载器加载，那么如果对他们做增强的话，就需要将被增强后的字节码重新覆盖回启动类加载器中。考虑到增强后的嵌入代码主要是在**拦截器**中编写的，而这些内容主要由系统类加载器`AppClassLoader`加载，启动类加载器无法访问。得益于[**Advice模板类**](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/template)中使用反射调用拦截器的方法，使得原生类在增强时，编写的拦截器不受拘束。
-
-- 鉴于*Java*重定义*Class*的限制，我们无法修改这些原生类的元信息，那么就无法使用byte-buddy委派的方式对他们进行增强(原理是添加委派属性和静态代码块)。所幸我们可以使用[**Advice模板类**](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/template)配合[**byte-buddy advice**](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/transformer/BootstrapTransformer.java)技术进行增强，而现在**核心模块**就是这么做的。
-
-结合上述内容，其实增强原生类和增强普通类在增强定义和拦截器编写上没有什么区别，但是还是希望插件开发者尽量少地对原生类进行增强，原因有三：
-
-- 对原生类的增强往往是发散的，对他们增强很可能会对其他插件或宿主功能造成影响。
-- 对原生类的增强逻辑，将使用反射的方式调用系统类加载器中的拦截器方法。由于*Java*重定义*Class*的限制，每次调用被增强方法的时候，都会进行反射处理的逻辑，这将极大限制该方法的*TPS*上限。
-- 对原生类的增强过程中，涉及到使用**Advice模板类**生成动态拦截类。对于每个被增强的原生类方法，都会动态生成一个，他们将被系统类加载器加载。如果不加限制的增强原生类，加载动态类也会成为启动过程中不小的负担。
-
-综上，[**Sermant**核心功能模块](../../sermant-agentcore/sermant-agentcore-core)中提供对*Java*原生类增强的能力，但是，不建议不加限制地对他们进行增强，如果有多个增强点可选，优先考虑增强普通类。
-
-**Sermant**的`示例模块`中，[DemoBootstrapDeclarer](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/declarer/DemoBootstrapDeclarer.java)对`java.lang.Thread`做了增强，可以启动示例应用[DemoApplication](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-application/src/main/java/com/huawei/example/demo/DemoApplication.java)观察`java.lang.Thread`是否被正常增强。
-
-### 拦截器
-
-新版插件的开发中在拦截器层面不再对静态方法、构造函数和实例方法作区分，降低插件开发的复杂度。
-对于方法拦截点`MethodInterceptPoint`，有静态方法、构造函数和实例方法三种获取类型，对应的拦截器也有三种类型：
-
-- [interceptor](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/agent/interceptor/Interceptor.java): 拦截器接口，其中包含三个方法：
- - `before`，前置方法，该方法在拦截点之前执行。ExecuteContext参数为插件执行的上下文，里面封装拦截器运作所需的所有参数，通过skip方法可跳过主要流程，并设置最终方法结果，注意，增强构造函数时，不能跳过主要流程。
- - `after`，后置方法，无论被拦截方法是否正常执行，最后都会进入后置方法中。后置方法可以通过返回值覆盖被拦截方法的返回值，因此这里开发者需要注意不要轻易返回null。
- - `onThrow`，处理异常的方法，当被拦截方法执行异常时触发。这里处理异常并不会影响异常的正常抛出。
-
-**Sermant**的`示例模块`中包含以下拦截器示例：
-
-- [DemoStaticInterceptor](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/interceptor/DemoStaticInterceptor.java): 普通的静态方法拦截器
-- [DemoConstInterceptor](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/interceptor/DemoConstInterceptor.java): 普通的构造函数拦截器
-- [DemoMemberInterceptor](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/interceptor/DemoMemberInterceptor.java): 普通的实例方法拦截器
-- [DemoConfigInterceptor](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/interceptor/DemoConfigInterceptor.java): 插件配置使用示例拦截器，详见[插件配置](#插件配置)一节
-- [DemoServiceInterceptor](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/interceptor/DemoServiceInterceptor.java): 插件服务使用示例拦截器，详见[插件服务](#插件服务)一节
-
-在各插件开发者在编写自定义拦截器的时候，可以以以上示例为参考，开发满足自身功能需要的拦截器。
-
-### 插件配置
-
-**插件配置**指的是在插件包和插件服务包使用的配置系统，主要由三部分组成：
-
-- [PluginConfig](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/config/PluginConfig.java)插件配置接口: 所有普通的插件配置都要实现该接口。
-
-- [PluginConfigManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/config/PluginConfigManager.java)插件配置管理器: 提供获取插件配置`PluginConfig`的接口：
-
- ```java
- // ${plugin config class}为插件配置的Class
- PluginConfigManager.getPluginConfig(${plugin config class});
- ```
- `PluginConfigManager`是统一配置管理器[ConfigManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/config/ConfigManager.java)的特例，插件端可以直接使用后者的接口获取插件配置和统一配置：
-
- ```java
- // ${base config class}为统一配置或插件配置的Class
- ConfigManager.getConfig(${base config class});
- ```
-
-从**Sermant**的`示例模块`的插件配置文件[config.yaml](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/config/config.yaml)可以看出，该配置文件是一个*yaml*文件，一个`插件主模块(main)`的`插件模块(plugin)`和`服务模块(service)`中的插件配置对应的配置信息都封装在这唯一的`config.yaml`中。
-
-相较于传统的*yaml*格式配置文件对应一个*Java Pojo*对象，这里的`config.yaml`可以封装多个*Java Pojo*，他们由全限定名或别名进行区分，形成类似*Map*的结构，其中`demo.test`键对应的是**示例插件包**中的[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)对象，`com.huawei.example.demo.config.DemoServiceConfig`键对应的是**示例插件服务包**中的[DemoServiceConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-service/src/main/java/com/huawei/example/demo/config/DemoServiceConfig.java)对象。
-
-[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)相较于`DemoServiceConfig`，前者被[ConfigTypeKey](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/config/common/ConfigTypeKey.java)注解修饰，因此设定了`demo.test`的别名。如果没有被`ConfigTypeKey`注解修饰，则直接使用全限定名做索引。
-
-[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)中的`map`属性被[ConfigFieldKey](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/config/common/ConfigFieldKey.java)注解修饰，将其属性名修改为`str2DemoSimplePojoMap`。不过需要注意的是，使用该注解的**Java Pojo**如果被数组、*List*或*Map*包装了一层，该注解的语义无效，因此，目前该注解只能用于修饰当前**插件配置类**或直接使用的**Java Pojo**。
-
-从[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)中可以看出，插件配置现在支持的数据类型包括：
-
-- 布尔、数值类的基础类型及包装类型
-- 字符串类型
-- 枚举类型
-- 复杂对象类型
-- 上述类型构成的数组
-- 前四种类型构成的*List*
-- 前四种类型构成的*Map*
-
-*yaml*格式配置文件目前还有一些其他规则：
-
-- 对于数组、List和Map中涉及的复杂对象，不支持`ConfigFieldKey`修正属性名
-- 对于数组、List和Map中的字符串，不支持`${}`转换，**插件配置类**的字符串属性和复杂类型属性内部的字符串属性支持
-- 仅在字符串做`${}`转换时使用入参，不支持使用入参直接设置属性值
-- 配置类的字段名一般为小驼峰命名，可用[ConfigFieldKey](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/config/common/ConfigFieldKey.java)注解修饰为中划线风格定义别名。添加注解后，在*yaml*中即可用中划线或小驼峰皆可解析，参考[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)的`intField`属性
-- 配置生效的优先级为：启动参数 > 环境变量 > 系统变量(-D参数) > *yaml*文件配置
-- 配置类的属性在按照生效的优先级获取参考值(启动参数，环境变量和系统变量(-D参数))时，小驼峰和中划线都可以被分割成单词来进行查找匹配。例如对于[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)的`intField`属性，key将被转化为如下多种形式按顺序来查找：
- - demo.test.intField
- - demo_test_intField
- - demo-test-intField
- - DEMO.TEST.INTFIELD
- - DEMO_TEST_INTFIELD
- - DEMO-TEST-INTFIELD
- - demo.test.intfield
- - demo_test_intfield
- - demo-test-intfield
- - demo.test.int.field
- - demo_test_int_field
- - demo-test-int-field
- - DEMO.TEST.INT.FIELD
- - DEMO_TEST_INT_FIELD
- - DEMO-TEST-INT-FIELD
-- 若*yaml*配置中基本数据类型/数组/map/list/set(不支持包含复杂对象)的key未定义，将按照配置生效的优先级：启动参数 > 环境变量 > 系统变量(-D参数) 来获取参考值。从上述数据源获取参考值时，需注意：
- - 数组/list/set需配置为`yaml`字符串格式，例如：DEMO_TEST_LIST_NAME=[elem1,elem2]
- - map需配置为`yaml`字符串格式，例如：DEMO_TEST_MAP_NAME={key1: value1, key2: value2}
-
-[DemoConfig](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/config/DemoConfig.java)中已经包含了大部分可能的配置场景，插件开发者可以参考并编写符合自身业务需求的插件配置类。
-
-最后，不要忘记添加插件配置的*SPI*配置文件：
-
-- 在资源目录`resources`下添加`META-INF/services`文件夹。
-- 在`META-INF/services`中添加`com.huaweicloud.sermant.core.plugin.config.PluginConfig`配置文件。
-- 在上述文件中，以换行为分隔，键入插件包中所有的插件配置`PluginConfig`实现。
-
-### 插件服务
-
-**插件服务**指的是在插件包和插件服务包使用的服务系统，主要由两部分组成：
-
-- [PluginService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/service/PluginService.java)插件服务接口。
-- [PluginServiceManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/service/PluginServiceManager.java)插件服务管理器，其中提供获取`PluginService`的接口：
- ```java
- // ${plugin service class}为插件服务的Class
- PluginServiceManager.getPluginService(${plugin service class});
- ```
- `PluginServiceManager`其实只是[ServiceManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/ServiceManager.java)的一个特例，可以直接使用后者的接口获取核心服务和插件服务：
-
- ```java
- // ${base service class}为核心服务或插件服务的Class
- ServiceManager.getService(${base service class});
- ```
-
- 从[插件模块开发手册](dev_plugin_module-zh.md#添加插件模块)可知，插件有**简单插件**和**复杂插件**之分，这主要和他们所定义服务的复杂程度有关：
-
- - **简单插件**中定义的服务只能使用*Java*原生*API*、[**Sermant**核心功能模块](../../sermant-agentcore/sermant-agentcore-core)中自研的*API*(`com.huawei`开头)，以及`byte-buddy`和`slf4j`的*API*。
- - **复杂插件**中的服务除了能使用上述*API*，还有权使用其他第三方依赖的*API*。这些服务需要分离出**插件服务接口**和**插件服务实现**：前者编写于`插件模块(plugin)`中，供拦截器调用；后者编写于`服务模块(service)`中，由自定义*ClassLoader*加载，以实现类加载器级别的依赖隔离。
-
-#### 简单插件服务
-
-对于**简单插件服务**，实现[PluginService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/service/PluginService.java)接口即可，如[DemoSimpleService](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/service/DemoSimpleService.java)示例，在实现`start`方法和`stop`方法的基础上，可以添加其他所需的方法，如`activeFunc`方法，通过以下代码获得`DemoSimpleService`的示例并调用`activeFunc`方法：
-```java
-DemoSimpleService simpleService = PluginServiceManager.getPluginService(DemoSimpleService.class);
-simpleService.activeFunc();
-```
-
-对于**简单插件服务**来说，唯一的限制就是只能使用*Java*原生*API*，[**Sermant**核心功能模块](../../sermant-agentcore/sermant-agentcore-core)中自研的*API*(`com.huawei`开头)，以及`byte-buddy`和`slf4j`的*API*。
-
-插件开发者可以参照[DemoSimpleService](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/service/DemoSimpleService.java)，按需编写自身业务所需的**简单插件服务**。
-
-最后不要忘记添加[PluginService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/plugin/service/PluginService.java)的*SPI*配置文件：
-
-- 在资源目录`resources`下添加`META-INF/services`文件夹。
-- 在`META-INF/services`中添加`com.huaweicloud.sermant.core.plugin.service.PluginService`配置文件。
-- 在上述文件中，以换行为分隔，键入插件包中所有的插件服务`PluginService`实现。
-
-特别需要注意的是，不要尝试在`PluginService`的`start`方法中获取其他**插件服务**的实例，由于**插件服务**仍在初始化当中，可能无法正确获取这些**插件服务**实例。
-
-#### 复杂插件服务
-
-**复杂插件服务**比起**简单插件服务**，只有两点区别：
-
-- **复杂插件服务**在`插件模块(plugin)`中编写接口，在[`服务模块(service)`](#插件服务模块)中编写实现，而**简单插件服务**不需要编写接口，直接在`插件模块(plugin)`中实现。
-- **复杂插件服务**的实现可以按需使用任意第三方依赖。
-
-[DemoComplexService](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/service/DemoComplexService.java)是**复杂插件服务**示例接口，其中可以按需添加接口，如`activeFunc`方法，[DemoComplexServiceImpl](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-service/src/main/java/com/huawei/example/demo/service/DemoComplexServiceImpl.java)是对应的实现。我们可以通过以下代码调用`activeFunc`方法：
-
-```java
-DemoComplexService complexService = PluginServiceManager.getPluginService(DemoComplexService.class);
-complexService.activeFunc();
-```
-
-添加*SPI*配置及其他注意事项和**简单插件服务**没有区别，这里不做赘述。开发者可以参照`DemoComplexService`接口和`DemoComplexServiceImpl`实现编写符合自身业务要求的**复杂插件服务**。
-
-#### 日志功能
-
-考虑到依赖隔离的问题，[**Sermant**核心功能模块](../../sermant-agentcore/sermant-agentcore-core)提供给`插件模块(plugin)`和`服务模块(service)`使用的日志只能是**jul**日志，通过以下方法获取**jul**日志实例：
-
-```java
-
-import com.huaweicloud.sermant.core.common.LoggerFactory;
-Logger logger=LoggerFactory.getLogger();
-```
-
-插件开发者如果需要输出日志信息，可以参考[DemoLogger](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/template/template-plugin/src/main/java/com/huawei/example/demo/common/DemoLogger.java)示例开发。
-
-#### 心跳功能
-
-心跳功能是[**Sermant**核心功能模块](../../sermant-agentcore/sermant-agentcore-core)的核心服务之一，通过以下代码获取实例：
-```java
-HeartbeatService heartbeatService = ServiceManager.getService(HeartbeatService.class);
-```
-
-心跳功能在初始化的时候就会启动执行，定期将每个插件的名称、版本等信息发送至后端服务器。目前来说，插件的心跳上报的信息包括：
-
-- `hostname`：发送客户端的主机名
-- `ip`：发送客户端的IP地址
-- `app`：应用名称，即启动参数中的`appName`
-- `appType`：应用类型，即启动参数中的`appType`
-- `heartbeatVersion`：上一次心跳发送时间
-- `lastHeartbeat`：上一次心跳发送时间
-- `version`：核心包的版本，即核心包`manifest`文件的`Sermant-Version`值
-- `pluginName`：插件名称，通过插件设定文件确定
-- `pluginVersion`：插件版本号，取插件jar包中`manifest`文件的`Sermant-Plugin-Version`值
-
-如果希望在插件上报的数据中增加额外的内容，可以调用以下api：
-```java
-// 通过自定义ExtInfoProvider提供额外内容集合
-heartbeatService.setExtInfo(new ExtInfoProvider() {
- @Override
- public Map注意，当同一节点的其他监听器被精准移除时，由于该监听器无法鉴别到底是不是移除自身，因此会选择放弃循环注册|
- |boolean addPersistentRecursiveWatches(String, Watcher)|添加持久递归的监听器，对子孙节点有效|
- |boolean removeDataWatches(String)|移除数据监听器|
- |boolean removeAllWatches(String)|移除节点下所有的监听器，含子孙节点|
- |void close()|关闭`ZooKeeper`客户端|
-
-## Kie实现
-
-对于`Kie`服务来说，所谓动态配置就是`Kie`配置的键值，`Kie`是基于标签去查询关联配置， 至于`Key`与`Group`则是关联配置的元素。`Key`即配置的键的名称，而`Group`则是关联`Key`的标签， 每一个`Key`都可配置一个或者多个标签，其格式往往如下:
-
-```properties
-{
- "key": "keyName", # 配置键
- "value": "value", # 配置值
- "labels": {
- "service": "serviceName" #标签，kv形式，支持一个或者多个
- },
- "status": "enabled"
-}
-```
-
-相对于`Zookeeper`, `Kie`更专注于`Group`, 其传值格式也有所不同，`Kie`的传值格式如下:
-
-```properties
-groupKey1=groupValue1[&groupKey2=groupVaue2...]
-```
-
-> 其中`groupKey`为标签键， `groupValue`则为标签值，多个标签使用`&`拼接；`Group`可通过[LabelGroupUtils#createLabelGroup](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/utils/LabelGroupUtils.java)生成
->
-> **特别说明：**
->
-> 若传入的`Group`非以上格式，则会默认添加标签`GROUP=传入Group`
-
-`Kie`的实现见于包[kie](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie), 主要包含[KieDynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/KieDynamicConfigService.java)、[LabelGroupUtils](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/utils/LabelGroupUtils.java)与[SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java)三个类：
-
-- [KieDynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/KieDynamicConfigService.java)是[DynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/DynamicConfigService.java)的`Kie`实现类， 主要职责是封装[SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java)的订阅API以及`Group`的`Key`管理
-
-- [LabelGroupUtils](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/utils/LabelGroupUtils.java)则是负责`Group`转换，主要包含以下API：
-
- | 方法 | 解析 |
- | --------------------------- | -------------------------------- |
- | createLabelGroup（Map） | 创建标签，多个标签使用KV形式传入 |
- | getLabelCondition（String） | 将Group转换为请求的条件 |
- | isLabelGroup（String） | 判断是否为Kie的标签 |
-
-- [SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java)主要职责是管理`Group`的所有订阅者以及进行数据更新通知；其会根据订阅的Group，即标签组，与`Kie`建立连接请求任务，动态监听数据更新变化；该类主要包含以下API：
-
- | 方法 | 解析 |
- | ------------------------------------------------------------ | ------------------------------------------------------------ |
- | boolean addGroupListener(String, DynamicConfigListener, boolean) | 订阅标签监听，由[SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java)管理，建立监听任务，并提供首次订阅通知能力 |
- | boolean removeGroupListener(String, DynamicConfigListener) | 移除标签监听 |
- | boolean publishConfig(String, String, String) | 发布Kie配置 |
-
-## 实现包装
-
-从[核心模块介绍](../user-guide/agentcore-zh.md#插件服务系统)可知，**插件服务系统**是基于`SPI`实现的，而[DynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/DynamicConfigService.java)对应的`SPI`实现配置为[BufferedDynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/BufferedDynamicConfigService.java)，后者为前者所有具体实现类的包装。它在初始化的过程中读取[DynamicConfig](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/config/DynamicConfig.java)配置，通过`dynamic.config.dynamic_config_type`配置选择具体的服务实现，并将所有`API`委派给这些具体的服务实现完成。
-
-## 使用方式
-
-**动态配置服务**主要应用于插件的拦截器或插件服务中，具体使用方式可以参见[插件代码开发手册的动态配置功能一节](dev_plugin_code.md#动态配置功能)，使用过程中较为关键的当属`Key`和`Group`的构建，具体内容可参见前文中几种实现中对这两个值的要求，这里不做赘述。
-
-[返回**Sermant**说明文档](../README-zh.md)
diff --git a/docs/dev-guide/service_dynamicconfig.md b/docs/dev-guide/service_dynamicconfig.md
deleted file mode 100644
index f41801036a..0000000000
--- a/docs/dev-guide/service_dynamicconfig.md
+++ /dev/null
@@ -1,183 +0,0 @@
-# Dynamic Configuration Service
-
-[简体中文](service_dynamicconfig-zh.md) | [English](service_dynamicconfig.md)
-
-This document is about the [Dynamic Configuration Service](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig) in **sermant-agentcore**.
-
-- [Function Orientation](#Function-Orientation)
-- [API](#API)
-- [Implementation for ZooKeeper](#Implementation-for-ZooKeeper)
-- [Implementation for Kie](#Implementation-for-Kie)
-- [Wrapper](#Wrapper)
-- [How to Use](#How-to-Use)
-
-## Function Orientation
-
-**Dynamic Configuration Service** is a service that allows developers to dynamically pull configuration from servers, acting as a [Unified Configuration System](../user-guide/agentcore.md#Unified-Configuration-System). Its core purpose is to solve the problem that the configuration provided by the latter can not be changed.
-
-## API
-
-The functionality `API` of **Dynamic Configuration Service** is provided by the abstract class [DynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/DynamicConfigService.java) , which implements three interfaces, as seen in [api](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/api) directory, The concrete interface is as follows:：
-
-|Interface|Method|Explanation|
-|:-|:-|:-|
-|[KeyService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/api/KeyService.java)|String getConfig(String)|Get the configured value for a key (default group).|
-|[KeyService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/api/KeyService.java)|boolean publishConfig(String, String)|Set value for a key (default group) .|
-|[KeyService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/api/KeyService.java)|boolean removeConfig(String)|Remove a configured value for a key (default group).|
-|[KeyService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/api/KeyService.java)|List\ Note that when other watchers on the same node are accurately removed, the watcher will choose to abandon the loop registration because it cannot identify whether it has been removed.|
- |boolean addPersistentRecursiveWatches(String, Watcher)|Add a watches for persistent recursion, valid for descendant nodes|
- |boolean removeDataWatches(String)|Remove data watchers|
- |boolean removeAllWatches(String)|Remove all watchers under a node, including descendant nodes|
- |void close()|Close `ZooKeeper` client|
-
-## Implementation for Kie
-
-For the `Kie` service, the so-called dynamic configuration is the value of the `Kie'` configuration. `Kie` queries the associated configuration based on the label. `Key` and `Group` are the elements of the associated configuration. `Key` is the name of the configured Key, and `Group` is the label of the associated Key. Each `Key` can be configured with one or more labels. The format is usually as follows:
-
-```properties
-{
- "key": "keyName", # key
- "value": "value", # value
- "labels": {
- "service": "serviceName" #label，support one or more
- },
- "status": "enabled"
-}
-```
-
-Compared with `Zookeeper`, `Kie` is more focused on `Group` and its value transfer format is different. The value transfer format of `Kie` is as follows:
-
-```properties
-groupKey1=groupValue1[&groupKey2=groupValue2...]
-```
-
-> `groupKey` is the key of label, `groupValue` is the value of label. Multiple labels are spliced by `&`. `Group` could be generated by [LabelGroupUtils#createLabelGroup](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/utils/LabelGroupUtils.java).
->
-> **NOTE：**
->
-> If the input `Group` is not in the above format, the label `Group=input Group` will be added by default.
-
-The implementation of `Kie` could be found in [kie](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie), which contains [KieDynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/KieDynamicConfigService.java), [LabelGroupUtils](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/utils/LabelGroupUtils.java) and [SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java):
-
-- [KieDynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/KieDynamicConfigService.java) is an implementation of [DynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/DynamicConfigService.java) for `Kie`. Its main duty is to wrap the subscription API of [SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java) and the `Key` management of `Group`.
-
-- [LabelGroupUtils](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/utils/LabelGroupUtils.java) is used for conversion of `Group`, which contains following APIs：
-
- | Method | Explanation |
- | --------------------------- | --------------------------------------------------- |
- | createLabelGroup（Map） | Create labels and transfer multiple labels in KV |
- | getLabelCondition（String） | Converts the `Group` to the condition for a request |
- | isLabelGroup（String） | Check whether it is a label of `Kie` |
-
-- The main responsibility of [SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java) is to manage all the `Group` subscribers and to provide data update notifications. It will establish a connection request task with `Kie` according to the subscribed Group, namely the Label Group, and dynamically monitor data update changes. This class contains the following APIs:
-
- | Method | Explanation |
- | ------------------------------------------------------------ | ------------------------------------------------------------ |
- | boolean addGroupListener(String, DynamicConfigListener, boolean) | And a listener for a label group , which is managed by [SubscriberManager](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/kie/listener/SubscriberManager.java). Listening task will be established and the ability to notify the first subscription is provided. |
- | boolean removeGroupListener(String, DynamicConfigListener) | Remove a label group listener. |
- | boolean publishConfig(String, String, String) | Publish configuration of Kie |
-
-## Wrapper
-
-You can learn from [Sermant-agentcore-core](../user-guide/agentcore.md#Plugin-Service-System) that **Plugin Service System** is based on `SPI`.
-
-The corresponding ` SPI ` implementation of [DynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/DynamicConfigService.java) is [BufferedDynamicConfigService](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/BufferedDynamicConfigService.java). The latter is the wrapper of all the methods of the former. It reads [DynamicConfig](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/dynamicconfig/config/DynamicConfig.java) configuration at startup, selects concrete service implementation and delegates all `API` to these concrete service implementations via `dynamic.config. dynamic_config_type`.
-
-## How to Use
-
-**Dynamic Configuration Service** is mainly used in plugin interceptors or plugin services. The specific way can be found [Plugin Code Development Guide](dev_plugin_code.md). The important thing is the construction of `Key` and `Group`. For details, see the requirements for these two values in the previous implementations.
-
-[Back to README of **Sermant** ](../README.md)
diff --git a/docs/dev-guide/service_heartbeat-zh.md b/docs/dev-guide/service_heartbeat-zh.md
deleted file mode 100644
index 0ecfd1b22a..0000000000
--- a/docs/dev-guide/service_heartbeat-zh.md
+++ /dev/null
@@ -1,85 +0,0 @@
-# 心跳服务介绍
-
-[简体中文](service_heartbeat-zh.md) | [English](service_heartbeat.md)
-
-本文档主要介绍**核心模块**的[心跳服务](../../sermant-agentcore/sermant-agentcore-core/src/main/java/com/huaweicloud/sermant/core/service/heartbeat)。
-
-## 功能定位
-
-**心跳服务**指的是**核心模块**定期向**后端模块**发送心跳包的服务，起到告知当前`Sermant`应用存活的作用。**心跳服务**主要针对所有插件，对每个`插件主模块(main)`，**心跳服务**都会为其定制一个心跳数据包并定期发送，这些定制化数据将在**后端模块**的后续流程中发挥作用。
-
-## 实现方式
-
-**心跳服务**以**核心服务系统**为基础开发的一套用于`告知存活`和`定制数据`的服务。
-
-**核心服务系统**相关内容详见[核心模块介绍](../user-guide/agentcore-zh.md#核心服务系统)，这里不做赘述。
-
-心跳系统的常见使用方式如下：
-```java
-// 创建netty客户端
-NettyClient nettyClient = ClientManager.getNettyClientFactory().getNettyClient(
- AgentConfigManager.getNettyServerIp(),
- Integer.parseInt(AgentConfigManager.getNettyServerPort()));
-// 创建心跳数据包，其中包含一些默认数据，下面会介绍
-HeartbeatMessage message = new HeartbeatMessage();
-// 定制心跳数据包中的其他数据
-message.registerInformation("${key}", "${value}");
-// 构建心跳数据包信息
-String msg = message.generateCurrentMessage();
-// 序列化心跳数据包，并通过netty客户端发送，数据类型标注为心跳
-nettyClient.sendData(msg.getBytes(Charset.forName("UTF-8")), Message.ServiceData.DataType.SERVICE_HEARTBEAT);
-```
-
-其中`HeartbeatMessage`中默认包含的数据如下：
-
-- `hostname`：发送客户端的主机名
-- `ip`：发送客户端的IP地址
-- `app`：应用名称，即启动参数中的`appName`
-- `appType`：应用类型，即启动参数中的`appType`
-- `heartbeatVersion`：上一次心跳发送时间
-- `lastHeartbeat`：上一次心跳发送时间
-- `version`：核心包的版本
-
-### 初始化插件心跳
-
-**心跳服务**在初始化的时候，将从**插件管理器**中获取插件的名称和版本号：
-```java
-// 键为插件名称，值为插件版本
-Map
SpringWebMvc 4.1.3.RELEASE - 5.3.x
Dubbo 2.6.x-2.7.x|servicecomb-kie
ZooKeeper|N/A|-|
-|[服务注册](registry/document-zh.md)|GA|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0
Dubbo 2.6.x-2.7.x|N/A|servicecomb-service-center|-|
-|[服务双注册迁移](registry/spring-cloud-registry-migiration-zh.md)|实验|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0
Dubbo 2.6.x-2.7.x|N/A|**目标注册中心**支持：servicecomb-service-center
**SpringCloud原注册中心**支持：Eureka、Nacos、Zookeeper、Consul
**Dubbo原注册中心**支持：Nacos、Zookeeper|-|
-|[负载均衡](loadbalancer/document-zh.md)|开发中|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0|servicecomb-kie
ZooKeeper|N/A|不同的版本所支持的负载均衡策略不同，具体请参考[负载均衡策略支持](loadbalancer/document.md#负载均衡策略支持一览)
当前暂不支持网关应用|
-|[标签路由](router/document-zh.md)|实验|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0
Dubbo 2.6.x-2.7.x|servicecomb-kie|servicecomb-service-center|不支持异步调用
不支持混合框架（Dubbo调SpringCloud或者SpringCloud调Dubbo）做路由|
-|[区域路由](router/zone-router-zh.md)|实验|Dubbo 2.6.x-2.7.x|servicecomb-kie
ZooKeeper|servicecomb-service-center
ZooKeeper|-|
-|[优雅上下线](graceful/document-zh.md)|实验|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0|servicecomb-kie
ZooKeeper|N/A|该功能基于SpringCloud默认负载均衡实现，若实现自定义负载均衡，该能力将失效|
-|[动态配置](dynamic-config/document-zh.md)|开发中|SpringBoot 1.5.x - 2.6.2
spring-cloud-starter-alibaba-nacos-config 1.5.0.RELEASE+
spring-cloud-starter-zookeeper-config 1.2.0.RELEASE+|servicecomb-kie
ZooKeeper|-|-|
-|[服务监控](server-monitor/document-zh.md)|开发中|ALL|N/A|N/A|-|
-|[服务注册与发现（SpringBoot）](springboot-registry/document-zh.md)|实验|SpringBoot 1.5.10.Release+|servicecomb-kie
ZooKeeper|Zookeeper 3.4.x+|-|
diff --git a/docs/user-guide/feature-list.md b/docs/user-guide/feature-list.md
deleted file mode 100644
index 189eb635ea..0000000000
--- a/docs/user-guide/feature-list.md
+++ /dev/null
@@ -1,17 +0,0 @@
-# Summary List of Current Plugin Features
-
-[简体中文](feature-list-zh.md) | [English](feature-list.md)
-
-|Feature|Status|Microservice Framework Supported|Configuration Center Supported|Registration Center Supported|Notice|
-|:-:|:-:|:-----|:--|:--|:--|
-|[FlowControl](flowcontrol/flowcontrol.md)|Experimental Stage|SpringBoot 1.2.x - 2.6.x
SpringWebMvc 4.1.3.RELEASE - 5.3.x
Dubbo 2.6.x-2.7.x|servicecomb-kie
ZooKeeper|N/A|-|
-|[Service Registration](registry/document.md)|GA|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0
Dubbo 2.6.x-2.7.x|N/A|servicecomb-service-center|-|
-|[Service Dual Registration and Migration](registry/spring-cloud-registry-migiration.md)|Experimental Stage|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0
Dubbo 2.6.x-2.7.x|N/A|**Target Registration Center** supported：servicecomb-service-center
**Original Registration Center of SpringCloud** supported：Eureka、Nacos、Zookeeper、Consul
**Original Registration Center of Dubbo** supported：Nacos、Zookeeper|-|
-|[Loadbalancer](loadbalancer/document.md)|In Development|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0|servicecomb-kie
ZooKeeper|N/A|Different versions support different load balancing policies. For details, refer to [Policies Supported in Loadbalance](loadbalancer/document.md#The-Strategy-Loadbalacne-Support)
Gateway applications are not supported at present.|
-|[Tag Router](router/document.md)|Experimental Stage|SpringBoot 1.5.x - 2.6.2
SpringCloud Edgware.SR2 - 2021.0.0
Dubbo 2.6.x-2.7.x|servicecomb-kie|servicecomb-service-center|Asynchronous invocation is not supported.
Hybrid frameworks (SpringCloud or Dubbo) are not supported for routing|
-|[Zone Router](router/zone-router.md)|Experimental Stage|Dubbo 2.6.x-2.7.x|servicecomb-kie
ZooKeeper|servicecomb-service-center
ZooKeeper|-|
-|[Graceful Online/Offline](graceful/document.md)|Experimental Stage|SpringBoot 1.5.x - 2.6.2
SpringCloud
-Edgware.SR2 - 2021.0.0|servicecomb-kie
ZooKeeper|N/A|This function is implemented based on the default loadbalance of SpringCloud. If user-defined loadbalance is implemented, this function won't work.|
-|[Dynamic Configuration](dynamic-config/document.md)|In Development|SpringBoot 1.5.x - 2.6.2
spring-cloud-starter-alibaba-nacos-config 1.5.0.RELEASE+
spring-cloud-starter-zookeeper-config 1.2.0.RELEASE+|servicecomb-kie
ZooKeeper|-||
-|[Server Monitor](server-monitor/document.md)|In Development|ALL|N/A|N/A|-|
-|[Service Registration and Discovery](springboot-registry/document.md)|Experimental Stage |SpringBoot 1.5.10.Release+|servicecomb-kie
ZooKeeper|Zookeeper 3.4.x+|-|
\ No newline at end of file
diff --git a/docs/user-guide/flowcontrol/FAQ-zh.md b/docs/user-guide/flowcontrol/FAQ-zh.md
deleted file mode 100644
index 6e668f1fb5..0000000000
--- a/docs/user-guide/flowcontrol/FAQ-zh.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# 流控常见问题
-
-[简体中文](FAQ-zh.md) | [English](FAQ.md)
-
-本文档主要说明在使用流控插件时遇到的常见问题
-
-## 关于业务场景的apiPath是如何定义的
-
-- `apiPath`指需要作用的接口，针对不同框架定义会有所不同，当前支持http与dubbo协议请求：
- - `http协议`： 指请求的路径，例如存在接口http://localhost:8080/test, 则其`apiPath`为`/test`；
- - `dubbo协议`：由`"请求接口：接口版本.方法"`组成，如果无接口版本或者版本为0.0.0，则`apiPath`为`"请求接口.方法"`。
-
-## 如何确定配置规则生效
-
-- 首先需在配置中心上正确配置相关业务场景与治理策略，配置后可观察agent日志，一般在jar包启动路径的logs文件夹下，查看sermant-x.log文件， 搜索`has been`或者配置的键名， 若搜索到的日志与当前时间匹配，则说明规则已生效。
-
-## 熔断策略未生效的可能原因
-
-- 熔断生效有一定的前提，通常熔断从两个指标来判定：
- - `异常比例`：即接口请求发生异常时所占比例，在规定时间内发生异常的比例大于配置的即会触发熔断；
- - `慢调用比例`：即接口请求发生慢调用所占比例，设置熔断策略时需设置慢调用的阈值，例如100ms，则必须接口调用耗时超出100ms且超过配置的慢调用比例才可触发；
-- 因此针对以上两项指标，首先排查应用接口是否满足以上其中一个条件，且规则时间内调用超过最小调用数（minimumNumberOfCalls配置）才可触发。
-
-## 隔离仓规则未生效的可能原因
-
-- 隔离仓规则需满足以下条件：
- - `调用满足并发数`（maxConcurrentCalls配置）要求，例如配置的阈值为2，则确保并发数需大于2；
- - `最大等待时间`（maxWaitDuration配置），即在达到最大并发数时，线程等待最大时间，超过该时间未拿到许可便会触发；
-- 因此在实际测试时，若模拟该规则，建议确保业务接口耗时大于最大等待时间，并且并发数大于配置值。
-
-## 重试规则未生效的可能原因
-
-- 确保下游应用抛出的异常或者状态码符合重试策略要求，例如默认dubbo会检测下游是否抛出RpcException，Spring应用则可配置指定状态码检测。
-
-## 启动报HttpHostConnectException异常的可能原因
-
-- 出现该异常的原因是未启动`Sermant`后台服务`sermant-backhend`, 找到启动类`com.huawei.apm.backend.NettyServerApplication`启动后台服务，并重启应用即可。
-
-
-
-[返回**Sermant**说明文档](../../README-zh.md)
\ No newline at end of file
diff --git a/docs/user-guide/flowcontrol/FAQ.md b/docs/user-guide/flowcontrol/FAQ.md
deleted file mode 100644
index 075771f746..0000000000
--- a/docs/user-guide/flowcontrol/FAQ.md
+++ /dev/null
@@ -1,41 +0,0 @@
-# Flow Control FAQs
-
-[简体中文](FAQ-zh.md) | [English](FAQ.md)
-
-This document describes the common problems encountered when the flow control plug-in is used.
-
-## How Is The APIPath Defined In The Service Scenario?
-
-- `apiPath` indicates the interface to be used. The definition varies according to the framework. Currently, HTTP and Dubbo requests are supported:
- - `http procotol`： Indicates the request path. For example, if the interface http://localhost:8080/test exists, the apiPath of the interface is `/test`.
- - `dubbo procotol`：Request interface: `interface:version. Method`. If there is no interface version or the version is 0.0.0, the value of apiPath is Request `interface.Method`.
-
-## How Do I Determine Whether a Configuration Rule Takes Effect?
-
-- Configure service scenarios and governance policies correctly in the configuration center. After the configuration, you can view the agent logs. Generally, in the logs folder in the startup path of the JAR package, view the sermant-x.log file and search for `has been` or the configured key name. If the found logs match the current time, the rule has taken effect.
-
-## Possible Causes For The Failure Of The Circuit Breaker Policy To Take Effect
-
-- A circuit breaker takes effect only after the following conditions are met:
- - `Error Rate`：The percentage of error interface requests. If the percentage of error interface requests within a specified period is greater than the configured value, the circuit breaker is triggered.
- - `Slow Invoking Ratio`：The percentage of slow invoking requests. When setting the circuit breaker policy, you need to set the slow invoking threshold. For example, if the time required for invoking the interface exceeds 100 ms and exceeds the configured slow invoking ratio, the circuit breaker can be triggered only when the time required for invoking the interface exceeds 100 ms.
-- Therefore, for the preceding two indicators, check whether the application interface meets either of the preceding conditions and whether the number of invoking requests within the rule period exceeds the minimum number specified by minimumNumberOfCalls.
-
-## Possible Reasons Why The Quarantine Rule Does Not Take Effect
-
-- The quarantine rules must meet the following conditions:
- - `The number of concurrent calls meets the requirement` (configured by maxConcurrentCalls). For example, if the threshold is set to 2, ensure that the number of concurrent calls is greater than 2.
- - `Maximum waiting time` (configured by maxWaitDuration), that is, the maximum waiting time of a thread when the number of concurrent connections reaches the maximum. If no permission is obtained after the maximum waiting time expires, the thread is triggered.
-- Therefore, you are advised to ensure that the service interface duration is greater than the maximum waiting time and the number of concurrent requests is greater than the configured value.
-
-## Possible Causes For The Retry Rule Does Not Take Effect
-
-- Ensure that exceptions or status codes thrown by downstream applications meet the retry policy requirements. For example, by default, dubbo checks whether the downstream applications throw RpcException, and a specified status code can be configured for Spring applications.
-
-## Possible Causes Of The HttpHostConnectException Error Reported During Startup
-
-- The cause is that the Sermant background service sermant-backhend is not started. Find the startup class com.huawei.apm.backend.NettyServerApplication to start the background service and restart the application.
-
-
-
-[Back to README of **Sermant** ](../../README.md)
\ No newline at end of file
diff --git a/docs/user-guide/flowcontrol/flowcontrol-zh.md b/docs/user-guide/flowcontrol/flowcontrol-zh.md
deleted file mode 100644
index 1b108d6610..0000000000
--- a/docs/user-guide/flowcontrol/flowcontrol-zh.md
+++ /dev/null
@@ -1,441 +0,0 @@
-# FlowControl
-
-[简体中文](flowcontrol-zh.md) | [English](flowcontrol.md)
-
-本文档主要介绍[流控插件](../../../sermant-plugins/sermant-flowcontrol)以及该插件的使用方法
-
-## 功能
-
-流控插件基于[resilience4j](https://github.com/resilience4j)框架，以"流量"切入点，实现"无侵入式"流量控制；当前支持**限流**、**熔断**、**隔离仓**、**错误注入**与**重试**能力，并且支持配置中心动态配置规则，实时生效。
-
-- **限流**：对指定接口限制1S秒内通过的QPS，当1S内流量超过指定阈值，将触发流控，限制请求流量。
-- **熔断**：对指定接口配置熔断策略，可从单位统计时间窗口内的错误率或者慢请求率进行统计，当请求错误率或者慢请求率达到指定比例阈值，即触发熔断，在时间窗口重置前，隔离所有请求。
-- **隔离仓**：针对大规模并发流量，对并发流量进行控制，避免瞬时并发流量过大导致服务崩溃。
-- **重试**：当服务遇到非致命的错误时，可以通过重试的方式避免服务的最终失败。
-- **错误注入:** 指在服务运行时，给指定服务配置错误注入策略，在客户端访问目标服务前，以指定策略模式返回。该策略多用于减少目标服务的访问负载，可作为降级的一种措施。
-
-## 使用说明
-
-### 环境准备
-
-**（1）部署ServiceCenter环境与Kie环境**
-
-**（2）打包编译Sermant Agent**
-
- 参考[Sermant源码编译](../../QuickStart-zh.md#源码编译)
-
-### 配置agent
-
-**（1）修改服务注册信息**
-
-找到`${javaagent path}/agent/config/config.properties`，修改如下配置
-
-```properties
-# 服务app名称
-service.meta.application=default
-# 服务版本
-service.meta.version=1.0.0
-# serviceComb 命名空间
-service.meta.project=default
-# 环境
-service.meta.environment=development
-# 自定义标签，按需配置，用于后续的配置订阅
-service.meta.customLabel=public
-service.meta.customLabelValue=default
-```
-
-**提示**：以上配置均可通过环境变量指定，对应的键值即为环境变量键，例如服务app名称可由`-Dservice.meta.application=application`指定, 其他配置文件的所有键均可采用该方式配置。
-
-##### **（2）修改配置中心**
-
-修改配置文件`${javaagent路径}/config/config.properties`, 修改配置中心类型与地址，如下位置：
-
-```properties
-# 配置中心地址， 根据配置中心地址配置
-dynamic.config.server_address=127.0.0.1:30110
-# 配置中心类型， 支持KIE与ZOOKEEPER
-dynamic.config.dynamic_config_type=KIE
-```
-
-**（3）配置流控插件**
-
-修改配置文件`${javaagent路径}/pluginPackage/flowcontrol/config/config.yaml`
-
-```yaml
-flow.control.plugin:
- useCseRule: true # 是否开启ServiceComb适配
-```
-
-开启适配后，插件将根据应用配置，服务配置以及自定义标签订阅配置中心配置
-
-> 此处若设置useCseRule为false，流控插件将基于当前实例的服务名进行配置订阅，例如：用户配置的spring.application.name=flowControlDemo, 则在实际订阅时会根据标签service=flowControlDemo接收配置。
-
-### 部署应用
-
-执行以下命令启动应用
-
-```shell
-# 其中agent路径指打包后的路径
-# serviceName值应用名
-# applicationName即对应app名称
-# environment即对应环境名称
-# xxx.jar值打包后应用jar包
-java -javaagent:${agent路径}/sermant-agent.jar=appName=${serviceName} -Dservice.meta.application=${applicationName} -Dservice.meta.environment=${environment} -jar xxx.jar
-```
-
-### 验证应用部署
-
-登录[Service Center](localhost:30103)后台, 查看应用是否正确注册
-
-### 流控规则介绍
-
-流量治理采用流量标记+流控规则的方式对指定的流量进行流控，所谓流量标记，通俗讲为请求信息，例如接口路径、接口方法类型、请求头以及下游服务名。流控规则的是否生效取决与流量标记，仅当流量标记与请求相匹配，流控规则才会实际生效。而如何将流量标记对应上具体规则，则取决于业务场景名，通常流量标记与流控规则配置均要配置指定前缀，例如流量标记的键需以`servicecomb.MatchGroup`为前缀, 而限流规则则以`servicecomb.rateLimiting`为前缀，以一个具体的例子：
-
-流量标记配置键为：`servicecomb.MatchGroup.flow`
-
-限流规则配置键为：`servicecomb.rateLimiting.flow`
-
-如上，`flow`即为业务场景名，仅当两者业务场景名称一致，当请求匹配上流量标记时，限流规则才会生效
-
-下面依次介绍相关配置：
-
-- **流量标记**
-
- ```yaml
- matches: # 匹配器集合，可配置多个
- - apiPath: # 匹配的api路径， 支持各种比较方式，相等(exact)、包含(contains)等
- exact: /degrade # 具体匹配路径
- headers: # 请求头
- key:
- exact: value # 请求头值，此处为key=value, 比较方式同apiPath
- method: # 支持方法类型
- - GET
- name: degrade # 可选，配置名
- ```
-
- **流量标记解释:**
-
- - 请求路径为`/degrade`且方法类型为`GET`, 同时满足要求请求头包含`key=value`即匹配成功
-
- 详细配置项可参考[ServiceComb开发文档](http://servicecomb.gitee.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/references-handlers/governance.html#_2)流量标记部分
-
- **流量标记请求路径（apiPath）配置说明**
-
- 流量标记的请求路径会因不同的请求协议配置而存在差异，当前主要为Http（Spring）与Rpc（Dubbo）协议，下面分别说明两种请求协议的配置方式：
-
- - Http协议
-
- 该协议依据请求路径进行匹配，例如请求路径为localhost:8080/test/flow, 则实际拿到的路径为`/test/flow`，因此若需设置匹配规则，需依据该路径进行配置。
-
- 值得注意的是，如果用户配置的contextPath, 则需要加上contextPath前缀才可生效。
-
- - Rpc协议（Dubbo）
-
- 该协议调用需要基于接口+方法，例如请求的接口为com.demo.test, 其方法为flow， 则对应的请求路径为`com.demo.test.flow`, 特别的，如果用户有配置接口的版本，例如指定的version为1.0.0， 则请求路径为`com.demo.test:1.0.0.flow`。同时需要配置请求方法为`POST`, RPC协议仅支持POST类型。
-
-- **限流**
-
- | 配置项 | 说明 |
- | ------------------ | ------------------------------------------------------------ |
- | limitRefreshPeriod | 单位统计时间，单位毫秒, 若需配置秒则可增加单位`S`， 例如`10S` |
- | rate | 单位统计时间所能通过的**请求个数** |
-
-- **熔断**
-
- | 配置项 | 说明 |
- | ------------------------- | ------------------------------------------------------------ |
- | failureRateThreshold | 熔断所需达到的错误率 |
- | minimumNumberOfCalls | 滑动窗口内的最小请求数， 超过最小请求数才开始判断熔断条件 |
- | name | 配置项名称，可选参数 |
- | slidingWindowSize | 滑动统计窗口大小，支持毫秒与秒，例如`1000`为1000毫秒, `10S`代表10秒 |
- | slidingWindowType | 滑动窗口类型，目前支持`time`与`count`两种类型，前者基于时间窗口统计，后者基于请求次数 |
- | slowCallDurationThreshold | 慢请求阈值，单位同滑动窗口配置 |
- | slowCallRateThreshold | 慢请求占比，当慢调用请求数达到该比例触发通断 |
- | waitDurationInOpenState | 熔断后恢复时间，默认`60S` |
-
-- **隔离**
-
- | 配置项 | 说明 |
- | ------------------ | ------------------------------------------------------------ |
- | maxConcurrentCalls | 最大并发数 |
- | maxWaitDuration | 最大等待时间，若线程超过`maxConcurrentCalls`，会尝试等待，若超出等待时间还未获取资源，则抛出隔离仓异常 |
- | name | 可选，配置名称 |
-
-- **重试**
-
- | 配置项 | 说明 |
- | --------------------- | ------------------------------------------------------------ |
- | waitDuration | 重试等待时间，默认毫秒；支持秒单位，例如2S |
- | retryStrategy | 重试策略，当前支持两种重试策略：固定时间间隔（FixedInterval）， 指数增长间隔(RandomBackoff) |
- | maxAttempts | 最大重试次数 |
- | retryOnResponseStatus | HTTP状态码，当前仅支持HTTP请求；针对dubbo请求，可通过配置异常类型确定是否需要重试，默认为RpcException |
-
-- **错误注入**
-
- | 配置项 | 说明 |
- | ------------ | ------------------------------------------------------------ |
- | type | 错误注入类型, 目前支持abort(请求直接返回)与delay（请求延时） |
- | percentage | 错误注入触发概率 |
- | fallbackType | 请求调用返回类型，仅`type=abort`生效。当前支持两种`ReturnNull`:直接返回空内容，状态码200；`ThrowException`: 按照指定错误码返回，关联配置`errorCode` |
- | errorCode | 指定错误码返回, 默认500, 仅在`type=abort`且`fallbackType=ThrowException`生效 |
- | forceClosed | 是否强制关闭错误注入能力, 当为true时，错误注入将不会生效。默认false |
-
-### 配置流控规则
-
-#### 基于配置文件配置流控规则
-
-如果您的应用**非**SpringBoot应用， 该方式将不适用。
-
-流控插件在应用启动时，会尝试的从SpringBoot加载的配置源读取流控规则以及对应的流量标记，用户需要在启动之前进行配置。如下为配置示例, 示例配置直接基于`application.yml`进行配置
-
-```yaml
-servicecomb:
- matchGroup:
- demo-fault-null: |
- matches:
- - apiPath:
- exact: "/flow"
- demo-retry: |
- matches:
- - apiPath:
- prefix: "/retry"
- serviceName: rest-provider
- method:
- - GET
- demo-rateLimiting: |
- matches:
- - apiPath:
- exact: "/flow"
- demo-circuitBreaker-exception: |
- matches:
- - apiPath:
- exact: "/exceptionBreaker"
- demo-bulkhead: |
- matches:
- - apiPath:
- exact: "/flowcontrol/bulkhead"
- rateLimiting:
- demo-rateLimiting: |
- rate: 1
- retry:
- demo-retry: |
- maxAttempts: 3
- retryOnResponseStatus:
- - 500
- circuitBreaker:
- demo-circuitBreaker-exception: |
- failureRateThreshold: 44
- minimumNumberOfCalls: 2
- name: 熔断
- slidingWindowSize: 10000
- slidingWindowType: time
- waitDurationInOpenState: 5s
- bulkhead:
- demo-bulkhead: |
- maxConcurrentCalls: 1
- maxWaitDuration: 10
- faultInjection:
- demo-fault-null: |
- type: abort
- percentage: 100
- fallbackType: ReturnNull
- forceClosed: false
-```
-
-以上配置，配置当前支持的流控规则，具体配置项请根据实际需要进行变更。
-
-#### 基于sermant-backend统一配置接口发布规则
-
-[backend]()服务提供配置发布功能, 通过请求接口`/publishConfig`发布配置，请求参数如下：
-
-| 配置参数 | 说明 |
-| -------- | ------------------------------------------------ |
-| key | 配置键 |
-| group | 配置的标签组 |
-| content | 配置内容，即具体的规则配置，其格式均为`YAML`格式 |
-
-> 其中**group**的配置格式为k1=v1, 多个值使用"&"分隔，例如k1=v1&k2=v2, 代表该key绑定的标签组
-
-**以下配置以`app=region-A`,` serviceName=flowControlDemo`, `environment=testing`举例**
-
-- #### 流量标记配置示例
-
- ```json
- {
- "key":"servicecomb.matchGroup.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"alias: scene\nmatches:\n- apiPath:\n exact: /flow\n headers: {}\n method:\n - POST\n name: rule1\n"
- }
- ```
-
-
-**规则解释:**
-
-- 请求路径为`/flow`且方法类型为`GET`即匹配成功
-- 针对app为region-A，服务名为flowControlDemo且环境为testing的服务实例生效
-
-
-
-> **注意事项：**
->
-> - 流控配置首先需配置业务场景，再配置与业务场景绑定的流控规则
-> - `key`必须以`servicecomb.matchGroup.`为前置，`scene`则为业务名称
-
-- #### **流控规则配置示例**
-
- ```json
- {
- "key":"servicecomb.rateLimiting.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"limitRefreshPeriod: \"1000\"\nname: flow\nrate: \"2\"\n"
- }
- ```
- **规则解释：**
-
- - 针对app为region-A，服务名为flowControlDemo且环境为testing的服务实例生效
- - 1秒内超过2个请求，即触发流控效果
-
-
-
- > **注意事项：**
- >
- > `key`必须以`servicecomb.rateLimiting.`为前置，`scene`则为业务名称，确保与流量标记的业务场景名称一致
-
-- #### **熔断规则配置示例**
-
- ```json
- {
- "key":"servicecomb.circuitBreaker.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"failureRateThreshold: 90\nminimumNumberOfCalls: 3\nname: degrade\nslidingWindowSize: 10S\nslidingWindowType: time\nslowCallDurationThreshold: \"1\"\nslowCallRateThreshold: 80\nwaitDurationInOpenState: 10s"
- }
- ```
- **规则解释:**
-
- - 针对app为region-A，服务名为flowControlDemo且环境为testing的服务实例生效
- - 10秒内，若请求接口`/flow`次数超过3次，且错误率超过90%或者慢请求占比超过80%则触发熔断
-
-
-
- > **注意事项：**
- >
- > `key`必须以`servicecomb.circuitBreaker.`为前置，`scene`则为业务名称，确保与流量标记的业务场景名称一致
-
-- #### 隔离仓规则配置示例
-
- ```json
- {
- "key":"servicecomb.bulkhead.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"maxConcurrentCalls: \"5\"\nmaxWaitDuration: \"10S\"\nname: \"隔离仓\"\n"
- }
- ```
-
- **规则解释:**
-
- - 针对app为region-A，服务名为flowControlDemo且环境为testing的服务实例生效
- - 针对接口`/flow`, 若最大并发数超过5，且新的请求等待10S，还未获取资源，则触发隔离仓异常
-
-
-
- > **注意事项：**
- >
- > `key`必须以`servicecomb.bulkhead.`为前置，`scene`则为业务名称，确保与流量标记的业务场景名称一致
-
-- #### 重试规则配置示例
-
- ```json
- {
- "key":"servicecomb.retry.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"waitDuration: \"2000\"\nretryStrategy: FixedInterval\nmaxAttempts: 2\nretryOnResponseStatus:\n- 500"
- }
- ```
-
- **规则解释：**
-
- - 针对app为region-A，服务名为flowControlDemo且环境为testing的服务实例生效
- - 针对接口`/flow`, 当请求抛出500异常时进行重试，直到重试成功或者达到最大重试次数
-
-
-
- > **注意事项：**
- >
- > `key`必须以`servicecomb.retry.`为前置，`scene`则为业务名称，确保与流量标记的业务场景名称一致
-
- **特别说明**：对于Dubbo重试， 流控插件采用替代原生的ClusterInvoker方式实现, 请求逻辑将采用流控插件自身实现的ClusterInvoker进行调用，而原宿主选择的将会失效（例如：dubbo默认的FailoverClusterInvoker）。如果此处仍需使用原来的ClusterInvoker，可通过添加环境变量`-Dflow.control.plugin.useOriginInvoker=true`实现， 但该方式可能存在少量的性能损失。
-
-- #### 错误注入规则示例
-
- ```json
- {
- "key":"servicecomb.faultInjection.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"type: abort\npercentage: 100\nfallbackType: ReturnNull\nforceClosed: false\nerrorCode: 503"
- }
- ```
-
- **规则解释：**
-
- - 针对app为region-A，服务名为flowControlDemo且环境为testing的服务实例生效
- - 当请求接口`/flow`时，100%将返回空
-
-
-
- > **注意事项：**
- >
- > `key`必须以`servicecomb.faultInjection.`为前置，`scene`则为业务名称，确保与流量标记的业务场景名称一致
-
-## 快速开始
-
-### 1、编译打包
-
-通过[此处](https://github.com/huaweicloud/Sermant/releases)下载sermant软件包, 并下载[Demo源码](https://github.com/huaweicloud/Sermant-examples/tree/main/flowcontrol-demo/spring-cloud-demo/spring-provider)
-
-执行以下maven命令对Demo应用执行打包
-
-```shell
-mvn clean package
-```
-
-### 2、启动应用
-
-```shell
-java -javaagent:${agent路径}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=spring-flow-provider -Dservice.meta.application=region-A -Dservice.meta.environment=testing -Dspring.application.name=spring-flow-provider -jar spring-provider.jar
-```
-
-### 3、配置规则
-
-参考[配置流控规则](#配置流控规则)配置**流量标记**与**流控规则**
-
-**流量标记:**
-
-```json
-{
- "key": "servicecomb.matchGroup.sceneFlow",
- "group": "app=sc&service=spring-flow-provider&environment=testing",
- "content": "alias: scene\nmatches:\n- apiPath:\n exact: /flow\n headers: {}\n method:\n - POST\n name: flow\n"
-}
-```
-
-**流控规则：**
-
-```json
-{
- "key": "servicecomb.rateLimiting.scene",
- "group": "app=region-A&service=spring-flow-provider&environment=testing",
- "content": "limitRefreshPeriod: \"2S\"\nname: flow\nrate: \"4\"\n"
-}
-```
-
-### 4、验证结果
-
-多次请求`localhost:8003/flow`, 若在2秒内请求数超过4个时返回`rate limited`，则触发流控成功
-
-## 其他
-
-若使用过程中遇到问题请先参考[FAQ文档](./FAQ-zh.md)
-
-
-
-[返回**Sermant**说明文档](../../README-zh.md)
diff --git a/docs/user-guide/flowcontrol/flowcontrol.md b/docs/user-guide/flowcontrol/flowcontrol.md
deleted file mode 100644
index f21bb9f9b5..0000000000
--- a/docs/user-guide/flowcontrol/flowcontrol.md
+++ /dev/null
@@ -1,445 +0,0 @@
-# FlowControl
-
-[简体中文](flowcontrol-zh.md) | [English](flowcontrol.md)
-
-This document is used to introduce the usage of [Flow Control Plugin](../../../sermant-plugins/sermant-flowcontrol)
-
-## Functions
-
-The flow control plugin is based on the [resilience4j]((https://github.com/resilience4j)) framework and implements non-intrusive flow control based on the "traffic" entry point. Currently, **Traffic Limiting, Circuit Breaker, Bulkhead, Error Injection, and Retry** are supported. In addition, rules can be dynamically configured in the configuration center and take effect in real time.
-
-- **Traffic Limiting**：The number of QPS that pass through a specified interface within 1s is limited. When the traffic within 1s exceeds the specified threshold, flow control is triggered to limit the requested traffic.
-- **Circuit Breaker**：Configure a circuit breaker policy for a specified interface to collect statistics on the error rate or slow request rate in a specified time window. When the error rate or slow request rate reaches a specified threshold, the circuit breaker is triggered. Before the time window is reset, all requests are isolated.
-- **Bulkhead**：Controls concurrent traffic for a large number of concurrent traffic to prevent service breakdown caused by excessive instantaneous concurrent traffic.
-- **Retry**：If a service encounters a non-fatal error, you can retry the service to prevent the service failure.
-- **Error Injection:** An error injection policy is configured for a specified service when the service is running. Before the client accesses the target service, the error injection policy is used. This policy is mainly used to reduce the access load of the target service and can be used as a measure of downgrading the target service.
-
-## Usage
-
-### Environment Preparation
-
-**（1）Deploying the ServiceCenter and Kie environments**
-
-**（2）Package and compile Sermant Agent**
-
-The way that compile Sermant Agent referring [this article](../../QuickStart.md#Get-Compiled-Products)
-
-Compile by referring to the Sermant source code.
-
-### Configure Agent
-
-**（1）Modify Service Registration Information**
-
-Find the `${javaagent path}/agent/config/config.properties` and modify the content comply following configuration:
-
-```properties
-# application name, you can keep default
-service.meta.application=default
-# service version
-service.meta.version=1.0.0
-# serviceComb namespace, keep default
-service.meta.project=default
-# environment, it only support development/testing/production
-service.meta.environment=development
-# custom label, it use to subscribe the config of config center
-service.meta.customLabel=public
-service.meta.customLabelValue=default
-```
-
-**Notice**：The preceding configurations can be specified using environment variables. The corresponding key value is the environment variable key. For example, the service app name can be specified by `-Dservice.meta.application=application`. All keys in other configuration files can be configured using this method.
-
-##### **（2）Modify the Configuration Center**
-
-Modify the configuration file ${javaagent path}/config/config.properties and modify the configuration center type and address as follows:
-
-```properties
-# IP address of the configuration center. Set this parameter based on the IP address of the configuration center.
-dynamic.config.server_address=127.0.0.1:30110
-# Configuration center type. The options are KIE and ZOOKEEPER.
-dynamic.config.dynamic_config_type=KIE
-```
-
-**（3）Configure the Flow Control Plugin**
-
-Modify the Configuration File`${javaagent path}/pluginPackage/flowcontrol/config/config.yaml`
-
-```yaml
-flow.control.plugin:
- useCseRule: true
-```
-
-If adaptation is enabled, the plugin subscribes to the configuration center based on the application configuration, service configuration, and customized tag configuration.
-
-> If useCseRule is set to false, the flow control plugin configures subscription based on the service name of the current instance. For example, if spring.application.name is set to flowControlDemo, the flow control plugin receives configuration based on the service=flowControlDemo tag during actual subscription.
-
-### Deploying Applications
-
-Run the following command to start the application:
-
-```shell
-# agent path indicates the package path.
-# serviceName indicates the name of your service
-# applicationName indicates the app name
-# environment indicates the environment of your service, support testing/producation/developing
-# xxx.jar indicates the application packages of your service
-java -javaagent:${agent path}/sermant-agent.jar=appName=${serviceName} -Dservice.meta.application=${applicationName} -Dservice.meta.environment=${environment} -jar xxx.jar
-```
-
-### Verify Application Deployment
-
-Login to the [Service Center](localhost:30103) background and check whether the application is correctly registered.
-
-### Flow Control Rules Specification
-
-Traffic governance uses traffic marking and flow control rules to control specified traffic. Traffic marking refers to request information, such as the interface path, interface method type, request header, and downstream service name. Whether a flow control rule takes effect depends on the traffic flag. A flow control rule takes effect only when the traffic flag matches the request. The mapping between traffic marks and specific rules depends on the service scenario name. Generally, a specified prefix must be configured for traffic marks and traffic control rules. For example, the key of traffic marks must be prefixed with `servicecomb.MatchGroup`. The traffic limiting rule is prefixed with `servicecomb.rateLimiting`. The following is an example:
-
-The traffic marking configuration key：`servicecomb.MatchGroup.flow`
-
-The key for configuring the traffic limiting rule：`servicecomb.rateLimiting.flow`
-
-In the preceding information, `flow `is the service scenario name. The traffic limiting rule takes effect only when the two service scenario names are the same and the request matches a traffic flag.
-
-The following describes the related configurations:
-
-- **Traffic Marking**
-
- ```yaml
- matches: # Matcher set. Multiple matchers can be configured.
- - apiPath: # Matched API path. Various comparison modes are supported, such as exact and contain.
- exact: /degrade # Specific Matching Path
- headers: # Request header
- key:
- exact: value # Request header value. The value is key=value. The comparison method is the same as that of apiPath.
- method: # Supported Method Types
- - GET
- name: degrade # Configuration name, which is optional.
- ```
-
- **what traffic marking above can match :**
-
- - If the request path is `/degrade`, the method type is `GET`, and the request header contains `key=value`, the matching is successful.
-
-
-
- > For details about the configuration items, see the traffic marking section in the [ServiceComb development document](http://servicecomb.gitee.io/servicecomb-java-chassis-doc/java-chassis/zh_CN/references-handlers/governance.html#_2).
-
- **Traffic marking request path (apiPath) configuration description**
-
- The request path for traffic marking varies according to the request protocol configuration. Currently, HTTP (Spring) and RPC (Dubbo) protocols are used. The following describes how to configure the two request protocols:
-
- - **Http protocol**
-
- This protocol performs matching based on the request path. For example, if the request path is `localhost:8080/test/flow`, the actual path is `/test/flow`. Therefore, if you need to set a matching rule, you need to configure the matching rule based on the path.
-
- It should be noted that if the contextPath configured by the user is valid only after the contextPath prefix is added.
-
- - **Rpc protocol(Dubbo)**
-
- The protocol invoking needs to be based on an interface+method. For example, if the requested interface is `com.demo.test`, and the method is `flow`, a corresponding request path is `com.demo.test.flow`. Specially, if a user configures an interface version, for example, a specified version is `1.0.0`, The request path is `com.demo.test:1.0.0.flow`. In addition, set the request method to `POST`. The RPC protocol supports only POST.
-
-- **Traffic Limiting**
-
- | Configuration | Description |
- | ------------------ | ------------------------------------------------------------ |
- | limitRefreshPeriod | Unit of statistics time, in milliseconds. If you need to set this parameter, the unit can be set to `S`, for example, `10s`. |
- | rate | Number of requests that can be processed in the unit of statistical time. |
-
-- **Circuit Breaker**
-
- | Configuration | Description |
- | ------------------------- | ------------------------------------------------------------ |
- | failureRateThreshold | Error rate required for fuse |
- | minimumNumberOfCalls | Minimum number of requests in the sliding window. The fuse condition is determined only when the minimum number of requests is exceeded. |
- | name | Specifies the name of a configuration item. This parameter is optional. |
- | slidingWindowSize | Size of the sliding statistics window. The value can be milliseconds or seconds. For example, 1000 indicates 1000 milliseconds, and 10s indicates 10 seconds. |
- | slidingWindowType | Sliding window type. Currently, `time` and `count` are supported. The former is based on the time window and the latter is based on the number of requests. |
- | slowCallDurationThreshold | Slow request threshold. The unit is the same as that of the sliding window. |
- | slowCallRateThreshold | Percentage of slow invoking requests. When the number of slow invoking requests reaches this percentage, connectivity is triggered. |
- | waitDurationInOpenState | Recovery time after a circuit breaker. The default value is `60s`. |
-
-- **Bulkhead**
-
- | Configuration | Description |
- | ------------------ | ------------------------------------------------------------ |
- | maxConcurrentCalls | Maximum number of concurrent calls |
- | maxWaitDuration | Maximum waiting time. If the thread exceeds maxConcurrentCalls, the thread attempts to wait. If the thread does not obtain resources after the waiting time expires, an isolation warehouse exception is thrown. |
- | name | name of configuration, which is optional. |
-
-- **Retry**
-
- | Configuration | Description |
- | --------------------- | ------------------------------------------------------------ |
- | waitDuration | Retry wait time. The default value is milliseconds. The unit is second, for example, 2s. |
- | retryStrategy | Retry policy. Currently, two retry policies are supported: fixed interval (FixedInterval) and exponential increase interval (RandomBackoff). |
- | maxAttempts | Maximum number of retries |
- | retryOnResponseStatus | HTTP status code. Currently, only HTTP requests are supported. For dubbo requests, you can configure the exception type to determine whether to retry. The default value is RpcException. |
-
-- **Error Injection**
-
- | Configuration | Description |
- | ------------- | ------------------------------------------------------------ |
- | type | Error injection type. Currently, `abort (request response)` and `delay (request delay)` are supported. |
- | percentage | Error Injection triggering probability |
- | fallbackType | Return type of the request invoking. This parameter is valid only when `type is set to abort`. Currently, two types are supported, `ReturnNull`: empty content is directly returned and the status code is 200. `ThrowException`: The error code is returned based on the specified error code.` |
- | errorCode | Specifies the returned error code. The default value is 500. This parameter is valid only `when type is abort and fallbackType is ThrowException`. |
- | forceClosed | Indicates whether to forcibly disable the error injection capability. If this parameter is set to true, error injection does not take effect. The default value is false. |
-
-### Configuring Flow Control Rule
-
-#### Configuring Flow Control Rules Based On The Configuration File
-
-If your application is not a SpringBoot application, this method is not applicable.
-
-When an application is started, the flow control plugin attempts to read the flow control rules and corresponding traffic flags from the configuration source loaded by SpringBoot. You need to configure the flow control rules before starting the application. The following is a configuration example. The example configuration is based on the `application.yml` file.
-
-```yaml
-servicecomb:
- matchGroup:
- demo-fault-null: |
- matches:
- - apiPath:
- exact: "/flow"
- demo-retry: |
- matches:
- - apiPath:
- prefix: "/retry"
- serviceName: rest-provider
- method:
- - GET
- demo-rateLimiting: |
- matches:
- - apiPath:
- exact: "/flow"
- demo-circuitBreaker-exception: |
- matches:
- - apiPath:
- exact: "/exceptionBreaker"
- demo-bulkhead: |
- matches:
- - apiPath:
- exact: "/flowcontrol/bulkhead"
- rateLimiting:
- demo-rateLimiting: |
- rate: 1
- retry:
- demo-retry: |
- maxAttempts: 3
- retryOnResponseStatus:
- - 500
- circuitBreaker:
- demo-circuitBreaker-exception: |
- failureRateThreshold: 44
- minimumNumberOfCalls: 2
- name: circuit breaker
- slidingWindowSize: 10000
- slidingWindowType: time
- waitDurationInOpenState: 5s
- bulkhead:
- demo-bulkhead: |
- maxConcurrentCalls: 1
- maxWaitDuration: 10
- faultInjection:
- demo-fault-null: |
- type: abort
- percentage: 100
- fallbackType: ReturnNull
- forceClosed: false
-```
-
-The preceding configurations are used to configure the supported flow control rules. Change the configuration items based on the site requirements.。
-
-#### Configuring Interface Advertisement Rules Based on Sermant Backend
-
-The backend service provides the function of publishing configurations through the /publishConfig request interface. The request parameters are as follows:
-
-| Configuration | Description |
-| ------------- | ------------------------------------------------------------ |
-| key | Configuration key |
-| group | Configured tag group |
-| content | Configuration content, that is, specific rule configuration, is in YAML format. |
-
-> The format of group is k1=v1, and multiple values are separated by ampersands (&). For example, k1=v1&k2=v2, indicating the label group bound to the key.
-
-**The following uses `app=region-A,serviceName=flowControlDemo, environment=testing` as an example.**
-
-- #### The Example Configuration For Traffic Marking Rule
-
- ```json
- {
- "key":"servicecomb.matchGroup.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"alias: scene\nmatches:\n- apiPath:\n exact: /flow\n headers: {}\n method:\n - POST\n name: rule1\n"
- }
- ```
-
-
-**Rule Interpretation:**
-
-- If the request path is `/flow` and the method type is `GET`, the matching is successful.
-- This parameter takes effect for the service instance whose app is `region-A`, service name is `flowControlDemo`, and environment is `testing`.
-
-
-
-> **Notices：**
->
-> - To configure flow control, you need to configure the service scenario and then configure the flow control rule bound to the service scenario.
-> - The `key` must be preceded by `servicecomb.matchGroup`. and the scene indicates the service name.
-
-- #### The Example Configuration For Traffic Limiting Rule
-
- ```json
- {
- "key":"servicecomb.rateLimiting.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"limitRefreshPeriod: \"1000\"\nname: flow\nrate: \"2\"\n"
- }
- ```
- **Rule Interpretation：**
-
- - This parameter takes effect for the service instance whose app is region-A, service name is flowControlDemo, and environment is testing.
- - If more than two requests are received within one second, flow control is triggered.
-
-
-
- > **Notices：**
- >
- > The `key` must be preceded by `servicecomb.rateLimiting`. and scene indicates the service name. Ensure that the value is the same as the service scenario name of the traffic tag.
-
-- #### The Example Configuration For Circuit Breaker Rule
-
- ```json
- {
- "key":"servicecomb.circuitBreaker.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"failureRateThreshold: 90\nminimumNumberOfCalls: 3\nname: degrade\nslidingWindowSize: 10S\nslidingWindowType: time\nslowCallDurationThreshold: \"1\"\nslowCallRateThreshold: 80\nwaitDurationInOpenState: 10s"
- }
- ```
- **Rule Interpretation:**
-
- - This parameter takes effect for the service instance whose app is region-A, service name is flowControlDemo, and environment is testing.
- - If the number of interface or flow requests exceeds three within 10 seconds and the error rate exceeds 90% or the percentage of slow requests exceeds 80%, the circuit breaker is triggered.
-
-
-
- > **Notices：**
- >
- > The key must be preceded by servicecomb.circuitBreaker. and scene indicates the service name. Ensure that the value is the same as the service scenario name of the traffic tag.
-
-- #### The Example Configuration For Bulkhead Rule
-
- ```json
- {
- "key":"servicecomb.bulkhead.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"maxConcurrentCalls: \"5\"\nmaxWaitDuration: \"10S\"\nname: \"bulkhead\"\n"
- }
- ```
-
- **Rule Interpretation:**
-
- - This parameter takes effect for the service instance whose app is region-A, service name is flowControlDemo, and environment is testing.
- - For an interface `/flow`, if the maximum number of concurrent requests exceeds 5 and a new request waits for 10 seconds and resources are not obtained, an exception occurs in the isolation repository.
-
-
-
- > **Notices：**
- >
- > The key must be preceded by servicecomb.bulkhead. and scene indicates the service name. Ensure that the value is the same as the service scenario name of the traffic tag.
-
-- #### The Example Configuration For Retry Rule
-
- ```json
- {
- "key":"servicecomb.retry.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"waitDuration: \"2000\"\nretryStrategy: FixedInterval\nmaxAttempts: 2\nretryOnResponseStatus:\n- 500"
- }
- ```
-
- **Rule Interpretation：**
-
- - This parameter takes effect for the service instance whose app is region-A, service name is flowControlDemo, and environment is testing.
- - For an interface `/flow`, when the 500 exception is thrown, the request is retried until the retry succeeds or the maximum number of retry times is reached.
-
-
-
- > **Notices**：
- >
- > The key must be preceded by servicecomb.retry. and scene indicates the service name. Ensure that the value is the same as the service scenario name of the traffic tag.
-
- **Notices**: For Dubbo retry, the flow control plugin will replace the original ClusterInvoker. The request logic is invoked by the ClusterInvoker implemented by the flow control plugin, and the original ClusterInvoker will become invalid (for example: Default FailoverClusterInvoker for dubbo. If you need to use original ClusterInvoker, you can add the environment variable `-Dflow.control.plugin.useOriginInvoker=true`. However, this method may cause a small performance loss.
-
-- #### The Example Configuration For Error Injection Rule
-
- ```json
- {
- "key":"servicecomb.faultInjection.scene",
- "group":"app=region-A&service=flowControlDemo&environment=testing",
- "content":"type: abort\npercentage: 100\nfallbackType: ReturnNull\nforceClosed: false\nerrorCode: 503"
- }
- ```
-
- **Rule Interpretation：**
-
- - This parameter takes effect for the service instance whose app is region-A, service name is flowControlDemo, and environment is testing.
- - When the interface /flow is requested, 100% returns null.
-
-
-
- > **Notices**：
- >
- > The key must be preceded by servicecomb.faultInjection. and scene indicates the service name. Ensure that the value is the same as the service scenario name of the traffic tag.
-
-## Quick Start
-
-### 1、Compile And Package
-
-Download the [sermant release package](https://github.com/huaweicloud/Sermant/releases) and [demo source code](https://github.com/huaweicloud/Sermant-examples/tree/main/flowcontrol-demo/spring-cloud-demo/spring-provider).
-
-Run the following maven command to package the demo application:
-
-```shell
-mvn clean package
-```
-
-### 2、Start Application
-
-```shell
-java -javaagent:${agent path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=spring-flow-provider -Dservice.meta.application=region-A -Dservice.meta.environment=testing -Dspring.application.name=spring-flow-provider -jar spring-provider.jar
-```
-
-### 3、Configure The Rule
-
-Configure traffic marking and traffic limiting rules by referring to [Configuring Flow Control Rules](#Configuring-Flow-Control-Rule).
-
-**Traffic Marking:**
-
-```json
-{
- "key": "servicecomb.matchGroup.sceneFlow",
- "group": "app=sc&service=spring-flow-provider&environment=testing",
- "content": "alias: scene\nmatches:\n- apiPath:\n exact: /flow\n headers: {}\n method:\n - POST\n name: flow\n"
-}
-```
-
-**Traffic Limiting Rule：**
-
-```json
-{
- "key": "servicecomb.rateLimiting.scene",
- "group": "app=region-A&service=spring-flow-provider&environment=testing",
- "content": "limitRefreshPeriod: \"2S\"\nname: flow\nrate: \"4\"\n"
-}
-```
-
-### 4、Verify Result
-
-Request `localhost:8003/flow` for multiple times. If `rate limited` is returned when the number of requests exceeds 4 within 2 seconds, flow control is triggered successfully.
-
-## Others
-
-If you encounter any problems, refer to the [FAQ document](./FAQ.md).
-
-
-
-[Back to README of **Sermant** ](../../README.md)
diff --git a/docs/user-guide/graceful/document-zh.md b/docs/user-guide/graceful/document-zh.md
deleted file mode 100644
index f9b8f1f596..0000000000
--- a/docs/user-guide/graceful/document-zh.md
+++ /dev/null
@@ -1,191 +0,0 @@
-# Graceful Online/Offline
-
-[简体中文](document-zh.md) | [English](document.md)
-
-该文档主要介绍优雅上下线能力以及其使用方法，该功能当前集成在[注册插件](../../../sermant-plugins/sermant-service-registry) 中, 但功能可独立使用。
-
-## 功能
-
-应用的重启、升级、扩容等操作无法避免，而该过程中时常会遇到以下问题：
-
-- 刚上线的实例，由于流量过大，该实例在初始化时便被大量流量访问，导致请求阻塞，甚至宕机。例如存在懒加载的场景
-- 实例下线时，因注册发现延迟刷新问题，无法及时告知上游，导致流量丢失或者错误。
-
-为解决上述问题，优雅上下线应运而生，针对以上两个问题，插件提供**预热**与**优雅下线**能力，对上述场景问题提供保护。
-
-**预热**， 顾名思义，即先用少部分流量对实例访问，后续根据时间推移，逐渐增加增加流量，确保新启动实例能成功过渡。
-
-**优雅下线**，即对下线的实例提供保护，插件基于**实时通知**+**刷新缓存的机制**快速更新上游缓存，同时基于流量统计的方式，确保即将下线的实例尽可能的将流量处理完成，最大程度避免流量丢失。
-
-## 版本支持
-
-当前优雅上下线能力**仅支持SpringCloud应用**，需确保SpringCloud版本在`Edgware.SR2`及以上。
-
-注册中心支持：Zookeeper、Consul、Naocs、Eureka、ServiceCenter
-
-**特别说明**：优雅上下线能力基于SpringCloud的默认负载均衡能力开发，若您实现了自定义负载均衡能力，该能力将不再适用。
-
-## 使用说明
-
-### 开启优雅上下线
-
-若需要使用优雅上下线能力，首先需开启该能力，相关配置见[配置文件](../../../sermant-plugins/sermant-service-registry/config/config.yaml)， 若您已完成Sermant打包，则配置文件路径为`${agent path}/agent/pluginPackge/service-registry/config/config.yaml`
-
-```yaml
-grace.rule:
- enableSpring: true # springCloud优雅上下线开关
- startDelayTime: 0 # 优雅上下线启动延迟时间, 单位S
- enableWarmUp: true # 是否开启预热
- warmUpTime: 120 # 预热时间, 单位S
- enableGraceShutdown: true # 是否开启优雅下线
- shutdownWaitTime: 30 # 关闭前相关流量检测的最大等待时间, 单位S. 需开启enabledGraceShutdown才会生效
- enableOfflineNotify: true # 是否开启下线主动通知
- httpServerPort: 16688 # 开启下线主动通知时的httpServer端口
- upstreamAddressMaxSize: 500 # 缓存上游地址的默认大小
- upstreamAddressExpiredTime: 60 # 缓存上游地址的过期时间
-```
-
-除上述配置文件方式外，您还可基于环境变量或者系统参数进行配置，以开启优雅上下线开关为例，此处可配置环境变量`-Dgrace.rule.enableSpring=true`开启开关。
-
-### 使用优雅上下线
-
-#### 虚机场景
-
-根据OS，携带agent并配置优雅上下线相关参数启动即可。
-
-```shell
-# windows
-java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar xxx.jar
-
-# mac, linux
-java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar xxx.jar
-```
-
-相关标识符说明：
-
-- ${path}: 此处路径（path）为实际打包的agent路径，请替换为实际路径
-- sermant-agent-x.x.x： x.x.x请换成实际打包的Sermant版本， 例如1.0.0
-- xxx.jar: 为您的应用包，请根据你的应用包名进行替换
-
-#### 容器场景
-
-容器场景可基于`Sermant-Injector`快速启动， 参考[容器化部署](../injector-zh.md)。
-
-同时需修改[Deployment编排文件](../injector-zh.md#部署)，添加优雅上下线环境变量，修改后的编排文件如下：
-
-```yaml
-apiVersion: v1
-kind: Deployment
-metadata:
- name: demo-test
- labels:
- app: demo-test
-spec:
- replicas: 1
- selector:
- app: demo-test
- matchLabels:
- app: demo-test
- template:
- metadata:
- labels:
- app: demo-test
- sermant-injection: enabled
- spec:
- containers:
- - name: image
- # 请替换成您的应用镜像
- image: image:1.0.0
- ports:
- - containerPort: 8080
- env:
- - name: "grace_rule_enableSpring"
- value: "true"
- - name: "grace.rule.enableWarmUp"
- value: "true"
- - name: "grace_rule_enableGraceShutdown"
- value: "true"
- - name: "grace.rule.enableOfflineNotify"
- value: "true"
- ports:
- - port: 443
- targetPort: 8443
-```
-
-随后按照容器化流程启动即可。
-
-## 快速入门
-
-下面以一个简单demo演示如何在虚机场景验证优雅上下线
-
-1. 环境准备
-
- （1）下载JDK，并配置JDK环境，JDK需在1.8及以上；下载Maven，并配置Maven环境
-
- （2）下载最新Sermant release包，点击[此处](https://github.com/huaweicloud/Sermant/releases)下载
-
- （3）下载[Demo 源码](https://github.com/huaweicloud/Sermant-examples/tree/main/grace-demo/spring-grace-nacos-demo)
-
- （4）编译Demo
-
- 执行以下命令打包demo
-
- `mvn clean package`
-
- （5）下载nacos，并启动
-
- （6）下载zookeeper，并启动（作为sermant配置中心）
-
-2. 部署
-
- 我们将部署一个consumer实例，2个provider实例， 一个data实例。如下:
-
- `consumer -----------> provider(两实例) -------------> data`
-
- 其中consumer开启优雅上下线能力，一个provider实例开启预热与优雅下线能力， 另一个provider实例仅开启优雅下线能力。
-
- （1）启动data
-
- ```shell
- java -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -jar nacos-rest-data-2.2.0.RELEASE.jar
- ```
-
- （2）启动第一个provider实例（端口8880, **关闭预热功能**）
-
- ```shell
- # windows
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=false -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8880 -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
-
- # mac, linux
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=false -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8880 -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
- ```
-
- （3）启动第二个provider实例（端口8890, **开启预热能力**）
-
- ```shell
- # windows
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8890 -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
-
- # mac, linux
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8890 -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
- ```
-
- （4）启动consumer
-
- ```shell
- # windows
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8800 -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar nacos-rest-consumer-2.2.0.RELEASE.jar
-
- # mac, linux
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8800 -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar nacos-rest-consumer-2.2.0.RELEASE.jar
- ```
-
-3. 验证预热能力
-
- 访问接口`localhost:8800/graceHot`, 根据接口返回的ip与port判断预热是否生效。若预热时间段内（默认120s）访问偏向8880，随时间推移流量逐渐平均，则说明预热生效。
-
-4. 验证优雅下线
-
- 持续访问接口`localhost:8800/graceDownOpen`, 此时下线其中一个provider实例，观察请求是否出现错误，若未出现错误，则优雅下线能力验证成功。
-
-[返回**Sermant**说明文档](../../README-zh.md)
\ No newline at end of file
diff --git a/docs/user-guide/graceful/document.md b/docs/user-guide/graceful/document.md
deleted file mode 100644
index 5f6670b319..0000000000
--- a/docs/user-guide/graceful/document.md
+++ /dev/null
@@ -1,191 +0,0 @@
-# Graceful Online/Offline
-
-[简体中文](document-zh.md) | [English](document.md)
-
-The document is used to introduce the usage of graceful online/offline, it is currently integrated in the [Service Registration Plugin](../../../sermant-plugins/sermant-service-registry), but can be used independently.
-
-## Functions
-
-Operations such as restarting, upgrading, and capacity expansion of applications cannot be avoided. During these operations, the following problems may occur:
-
-- Due to heavy traffic, the instance is accessed by a large amount of traffic during initialization. As a result, requests may be blocked or even broken down. For example, lazy loading.
-- When an instance goes offline, the upstream application cannot be notified in real time due to it's refresh mechanism which need refresh instances at schedule time. As a result, traffic is lost or incorrect.
-
-To solve the preceding problems, graceful online/offline is developed. To solve the preceding problems, the plug-in provides the **warm up** and **graceful offline** capabilities to protect against the preceding problems.
-
-**Warm up**, as the name suggests, uses a small amount of traffic to access the instance first, and gradually increases the traffic based on time to ensure that the newly started instance can successfully transition.
-
-**Graceful offline**, The plugin quickly updates the upstream cache based on the **real-time notification** + **cache update mechanism**. In addition, traffic statistics are collected to ensure that the instances that are about to go offline can process traffic as much as possible, preventing traffic loss to the greatest extent.
-
-## Support Versions
-
-Currently, the graceful online/offline capability **supports only SpringCloud applications**. Ensure that the SpringCloud version is `Edgware.SR2` or later.
-
-Regitry Center Support：Zookeeper、Consul、Naocs、Eureka、Service Center
-
-**Notice**：The graceful online/offline capability is developed based on the default load balancing capability of SpringCloud. If you have implemented the custom load balancing capability, this capability is no longer applicable.
-
-## Usage
-
-### Enabling Graceful Online and Offline
-
-To use the graceful Online and Offline capability, you need to enable the capability. For details, see the [configuration file](../../../sermant-plugins/sermant-service-registry/config/config.yaml). If you have packed the Sermant or download Release package, the configuration file path is `${agent path}/agent/pluginPackge/service-registry/config/config.yaml`
-
-```yaml
-grace.rule:
- enableSpring: true # SpringCloud graceful online/offline switch
- startDelayTime: 0 # Graceful online/offline start delay, unit is seconds
- enableWarmUp: true # Whether to enable warm up
- warmUpTime: 120 # Warm up time unit is seconds
- enableGraceShutdown: true # Whether to enable graceful offline
- shutdownWaitTime: 30 # The maximum waiting time before traffic detection is disabled. Unit: s. This parameter takes effect only after enabledGraceShutdown is enabled.
- enableOfflineNotify: true # Whether to enable proactive offline notification.
- httpServerPort: 16688 # Enable the http server port for proactive offline notification.
- upstreamAddressMaxSize: 500 # Default size of the cache upstream address
- upstreamAddressExpiredTime: 60 # Expiration time of the cached upstream address
-```
-
-In addition to the preceding configuration file mode, you can also configure environment variables or system parameters. For example, you can set the environment variable `-Dgrace.rule.enableSpring=true to enable` for configuration 'enableSpring'.
-
-### Use Graceful Online and Offline
-
-#### Virtual Machine Scenario
-
-Based your OS, start application with agent, in addition configure configuration which to enable graceful online/offline.
-
-```shell
-# windows
-java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar xxx.jar
-
-# mac, linux
-java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar xxx.jar
-```
-
-Description of relevant identifiers:
-
-- ${path}: path indicates the actual agent path. Please replace it with the actual path.
-- sermant-agent-x.x.x： x.x.x need be replaced with the actual Sermant version, for example, 1.0.0.
-- xxx.jar: is your app package. Please replace it with your app package name.
-
-#### Container Scenario
-
-In container scenarios, you can quickly start using the `Sermant-Injector`. For details, see [Container-based Deployment](../injector.md).
-
-In addition, you need to modify the [deployment orchestration file](../injector.md#Deployment) by adding environment variables for graceful login and logout. The modified orchestration file is as follows:
-
-```yaml
-apiVersion: v1
-kind: Deployment
-metadata:
- name: demo-test
- labels:
- app: demo-test
-spec:
- replicas: 1
- selector:
- app: demo-test
- matchLabels:
- app: demo-test
- template:
- metadata:
- labels:
- app: demo-test
- sermant-injection: enabled
- spec:
- containers:
- - name: image
- # Please replace it with own image
- image: image:1.0.0
- ports:
- - containerPort: 8080
- env:
- - name: "grace_rule_enableSpring"
- value: "true"
- - name: "grace.rule.enableWarmUp"
- value: "true"
- - name: "grace_rule_enableGraceShutdown"
- value: "true"
- - name: "grace.rule.enableOfflineNotify"
- value: "true"
- ports:
- - port: 443
- targetPort: 8443
-```
-
-Then start application according to the containerization process .
-
-## Quick Start
-
-The following uses a simple demo to demonstrate how to verify graceful online/offline in a VM scenario.
-
-1. Environment Preparation
-
- （1）Download the JDK and configure the JDK environment. The JDK version must be 1.8 or later. Download the Maven and configure the Maven environment.
-
- （2）Download the latest Sermant release package. Click [here](https://github.com/huaweicloud/Sermant/releases) to download it.
-
- （3）Download the [Demo Source Code](https://github.com/huaweicloud/Sermant-examples/tree/main/grace-demo/spring-grace-nacos-demo)
-
- （4）Compile Demo
-
- Run the following command to package the demo:
-
- `mvn clean package`
-
- （5）Download nacos and start
-
- （6）Download and start the ZooKeeper (the sermant configuration center).
-
-2. Deploy
-
- We will deploy one consumer instance, two provider instances, and one data instance, as shown in the following figure:
-
- `consumer -----------> provider(two instances) -------------> data`
-
- The graceful online/offline are enabled for the consumer, the warm up and graceful offline are enabled for one provider instance, and only the graceful offline are enabled for the other provider instance.
-
- （1）Startup data
-
- ```shell
- java -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -jar nacos-rest-data-2.2.0.RELEASE.jar
- ```
-
- （2）Start the first provider instance (port is 8880, with the **warm up disabled**).
-
- ```shell
- # windows
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=false -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dgrace.rule.httpServerPort=16688 -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8880 -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
-
- # mac, linux
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=false -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dgrace.rule.httpServerPort=16688 -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8880 -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
- ```
-
- （3）Start the second provider instance (port is 8890, with the **warm up enabled**).
-
- ```shell
- # windows
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dgrace.rule.httpServerPort=16689 -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8890 -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
-
- # mac, linux
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dgrace.rule.httpServerPort=16689 -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8890 -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar nacos-rest-provider-2.2.0.RELEASE.jar
- ```
-
- （4）Startup consumer
-
- ```shell
- # windows
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dgrace.rule.httpServerPort=16690 -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8800 -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -jar nacos-rest-consumer-2.2.0.RELEASE.jar
-
- # mac, linux
- java -Dgrace.rule.enableSpring=true -Dgrace.rule.enableWarmUp=true -Dgrace.rule.enableGraceShutdown=true -Dgrace.rule.enableOfflineNotify=true -Dgrace.rule.httpServerPort=16690 -Dspring.cloud.nacos.discovery.server-addr=localhost:8848 -Dserver.port=8800 -javaagent:${path}/sermant-agent-x.x.x/agent/sermant-agent.jar=appName=default -jar nacos-rest-consumer-2.2.0.RELEASE.jar
- ```
-
-3. Verify warm up
-
- Request the `localhost:8800/graceHot` interface and check whether the preheating takes effect based on the IP address and port number returned by the interface. If the response contains port 8880 in the majority during the warm up period (120s by default), and the traffic is averaged over time, the warm up has taken effect.
-
-4. Verify graceful offline
-
- Continuously request the `localhost:8800/graceDownOpen` interface. Make one of the provider instances offline. Check whether occurs error in the request. If no error occurs, the graceful offline verification is successful.
-
-[Back to README of **Sermant** ](../../README.md)
\ No newline at end of file
diff --git a/docs/user-guide/injector-zh.md b/docs/user-guide/injector-zh.md
deleted file mode 100644
index d02ae8d066..0000000000
--- a/docs/user-guide/injector-zh.md
+++ /dev/null
@@ -1,180 +0,0 @@
-# 容器化部署指导手册
-
-[简体中文](injector-zh.md) | [English](injector.md)
-
-k8s环境下，Sermant支持通过sermant-injector组件实现宿主应用自动挂载sermant-agent包的快速部署方式。本文档主要介绍sermant-injector模块以及上述部署方式的具体流程。
-
-## sermant-injector模块介绍
-sermant-injector是基于Kubernetes准入控制器（Admission Controllers）特性开发而来。准入控制器位于k8s API Server中，能够拦截对API Server的请求，完成身份验证、授权、变更等操作。
-
-sermant-injector属于变更准入控制器(MutatingAdmissionWebhook), 能够在创建容器资源前对请求进行拦截和修改。sermant-injector部署在k8s后，只需在宿主应用部署的YAML文件中`spec > template > metadata> labels`层级加入`sermant-injection: enabled`即可实现自动挂载sermant-agent。
-
-### 组成部分
-`sermant-injector`文件夹下
-
-- `deployment`，部署sermant-injector应用的helm包文件
- - `release`
- - `injector` helm包，支持k8s 1.15版本及以上环境部署
-- `images`
- - `injector` sermant-injector Dockerfile及镜像构建脚本
- - `sermant-agent` sermant-agent Dockerfile及镜像构建脚本
-- `scripts` 包含证书生成脚本等
-- `src` 项目代码
-
-## 容器化部署流程
-
-### 运行环境
-[Kubernetes 1.15+](https://kubernetes.io/)
-
-[Helm v3](https://helm.sh/)
-
-### 生成证书
-Kubernetes webhook只能通过HTTPS(SSL/TLS)调用，因此需要为sermant-injector生成ssl key和证书。
-
-在k8s任一节点上任一目录下执行`scripts`下的`certificate.sh`脚本。
-
-> 注意：脚本中`NAMESPACE`参数必须和`deployment/release`下的`values.yaml`中的`namespace.name`保持一致。其他参数无需修改
-
-### 构建镜像
-
-在部署sermant-injector前需要先构建sermant-agent镜像以及sermant-injector镜像。
-
-#### sermant-agent镜像
-
-##### 下载release包
-
-点击 [here](https://github.com/huaweicloud/Sermant/releases)下载release包。
-
-你也可以在项目中执行以下命令来打包：
-
-```shell
-mvn clean package -Dmaven.test.skip
-```
-
-##### 制作镜像
-
-修改文件夹 `images/sermant-agent`下`build-sermant-image.sh` 脚本中`sermantVersion`,`imageName`和`imageVerison`的值：
-
-> 1. `sermantVersion`为release包的版本
->
-> 2. `imageName`为构建的sermant-agent镜像名称
->
-> 3. `imageVerison`为构建的sermant-agent镜像版本
-
-在k8s节点下，将`build-sermant-image.sh`和`Sermant.Dockerfile`置于release包`sermant-agent-xxx.tar.gz`同一目录下，执行`build-sermant-image.sh`脚本，完成sermant-agent镜像制作。
-
-```shell
-sh build-sermant-image.sh
-```
-
-#### sermant-injector镜像
-
-##### sermant-injector打包
-
-在sermant-injector项目下执行`mvn clean package`命令，在项目目录下生成`sermant-injector.jar`文件
-
-##### 制作镜像
-
-修改文件夹 `images/injector`下`build-injector-image.sh` 脚本中`imageName`和`imageVerison`的值：
-
-> 1. `imageName`为构建的sermant-injector镜像名称
-> 2. `imageVerison`为构建的sermant-injector镜像版本
-
-在k8s节点下，将`build-injector-image.sh`、`start.sh`和`Injector.Dockerfile`置于sermant-injector包`sermant-injector.jar`同一目录下，执行`build-injector-image.sh`脚本，完成sermant-injector镜像制作。
-
-```shell
-sh build-injector-image.sh
-```
-
-### 部署sermant-injector实例
-
-在宿主应用容器化部署前，需要先部署sermant-injector实例。本项目采用Helm进行Kubernetes包管理。
-
-使用`deploment/release`下的`injector`Chart模版。
-
-按实际环境修改`values.yaml`中的模版变量：
-
-> 1. `namespace.name`变量与`certificate.sh`中的`NAMESPACE`参数必须保持一致
->
-> 2. `agent.image.addr`和`injector.image.addr`变量与构建镜像时的镜像地址保持一致
->
-> 3. `injector.webhook.caBundle`变量为k8s证书，可在k8s节点执行以下命令获取：
->
-> ```shell
-> kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}'
-> ```
-
-完成后，执行`helm install`命令在k8s中部署sermant-injector实例:
-
-```shell
-helm install sermant-injector ../injector
-```
-
-检查sermant-injector部署pod状态为running。
-
-至此，宿主应用部署前的环境配置工作完成。
-
-### 部署宿主应用
-
-#### 部署
-
-在完成上述sermant-injector部署后，用户根据实际应用编写YAML部署K8s Deployment资源，只需在`spec > template > metadata> labels`层级加入`sermant-injection: enabled`即可实现自动挂载sermant-agent。(如后续不希望挂载，删除后重新启动应用即可)
-
-```yaml
-apiVersion: v1
-kind: Deployment
-metadata:
- name: demo-test
- labels:
- app: demo-test
-spec:
- replicas: 1
- selector:
- app: demo-test
- matchLabels:
- app: demo-test
- template:
- metadata:
- labels:
- app: demo-test
- sermant-injection: enabled
- spec:
- containers:
- - name: image
- # 请替换成您的应用镜像
- image: image:1.0.0
- ports:
- - containerPort: 8080
- ports:
- - port: 443
- targetPort: 8443
-```
-
-若pod无法创建，请检查sermant-injector是否正确部署以及sermant-agent镜像是否正确构建。
-
-#### 验证
-
-pod创建成功后，执行如下命令，其中`${pod_name}`为宿主应用的pod名称
-
-```shell
-kubectl get po/${pod_name} -o yaml
-```
-
-1. 查看上述命令输出内容`spec > containers > - env`下是否包含环境变量：name为`JAVA_TOOL_OPTIONS`，value为 `-javaagent:/home/sermant-agent/agent/sermant-agent.jar=appName=default`。
-
-2. 查看上述命令输出内容`spec > containers > initContainers > image` 的值是否为构建sermant-agent镜像时的镜像地址。
-
-执行如下命令，其中`${pod_name}`为用户应用的pod名称，`${namespace}`为用户部署应用的namespace名称
-
-```shell
-kubectl logs ${pod_name} -n ${namespace}
-```
-
-3. 查看上述命令输出内容pod日志开头部分是否包含：
-
-```
-[INFO] Loading sermant agent...
-```
-
-如果上述信息无误，则表明sermant-agent已成功挂载至用户应用中。
-
diff --git a/docs/user-guide/injector.md b/docs/user-guide/injector.md
deleted file mode 100644
index 2960b0ddd1..0000000000
--- a/docs/user-guide/injector.md
+++ /dev/null
@@ -1,180 +0,0 @@
-# Containerized Deployment Guide
-
-[简体中文](injector-zh.md) | [English](injector.md)
-
-In Kubernetes environment, Sermant supports quickly deployment by using **sermant-injector** module to automatically mount sermant-agent package for host application. This document describes the **sermant-injector** module and how to deploy **sermant-injector** and **host application with sermant-agent** in k8s environment.
-
-## Sermant-injector
-Sermant-injector is based on the **Kubernetes Admission Controllers.** The admission controller is located in the K8s API Server and is able to intercept requests to the API Server to complete operations such as authentication, authorization, and mutation.
-
-Sermant-injector is a MutatingAdmissionWebhook that can intercept and modify requests before creating container resources. After sermant-injector is deployed on K8s, just add `sermant-injection:Enabled` to the YAML file of the host application deployment configuration at the `spec > Template > metadata> labels` ' then the host application can automatically mount the sermant-agent package.
-
-### Components
-`sermant-injector` contains:
-
-- `deployment`, contains helm package file for deploying the sermant-injector application.
- - `release`
- - `injector` contains helm package file for K8S 1.15+.
-- `images`
- - `injector`, contains dockerfile and image build script of **sermant-injector**.
- - `sermant-agent`, contains dockerfile and image build script of **sermant-agent**.
-- `scripts`, contains certificate generation scripts, etc.
-- `src`, contains source code.
-
-## Containerized Deployment Steps
-
-### **Runtime Environment**
-[Kubernetes 1.15+](https://kubernetes.io/)
-
-[Helm v3](https://helm.sh/)
-
-### Generate a Certificate for Sermant-injector
-
-The Kubernetes webhook can only be invoked over HTTPS(SSL/TLS), so the SSL key and certificate need to be generated for the sermant-injector.
-
-Execute the `certificate.sh` script under `scripts` in any directory of any K8s node.
-
-> NOTE：The parameter `NAMESPACE` must be set as the same value as `namespace.name` in `values.yaml` under `deployment/release`. No need to modify other parameters.
-
-### Build Images
-
-Before deploying **sermant-injector**, you need to build the **sermant-agent** image and the **sermant-injector** image.
-
-#### Image of Sermant-agent
-
-##### Download release package
-
-Click [here](https://github.com/huaweicloud/Sermant/releases) to download latest release package `sermant-agent-x.x.x.tar.gz`.
-
-Or you can get above package by executing the following command in the project.
-
-```shell
-mvn clean package -Dmaven.test.skip
-```
-
-##### Build Image
-
-Modify the values of `sermantVersion`, `imageName` and `imageVerison` in the `build-sermant-image.sh` under `images/sermant-agent` folder:
-
-> 1. `sermantVersion` is the version of the release package.
->
-> 2. `imageName` is the name of the built sermant-agent image.
->
-> 3. `imageVerison` is the version for the built sermant-agent image.
-
-Move `build-sermant-image.sh` and `Sermant.dockerfile` to the same directory as the release package `sermant-agent-xxx.tar.gz` in one of K8s nodes. Run `build-sermant-image.sh` to build the sermant-agent image.
-
-```shell
-sh build-sermant-image.sh
-```
-
-#### Image of Sermant-injector
-
-##### Package Sermant-injector
-
-Execute the `mvn clean package` command to generate the `sermant-injector.jar` file in the directory of sermant-injector project.
-
-##### Build Image
-
-Modify the values of `imageName` and `imageVerison` in the `build-injector-image.sh` script under `images/injector` folder:
-
-> 1. `imageName` is the name of the built image of sermant-injector.
-> 2. `imageVerison` is the version of the built image of sermant-injector.
-
-Move `build-injector-image.sh`, `start.sh` and `Injector.Dockerfile` to the same directory as the package `sermant-injector.jar`. Run `build-injector-image.sh` to create the sermant-injector image.
-
-```shell
-sh build-injector-image.sh
-```
-
-### Deploy Workload of Sermant-injector
-
-Before the host application can be containerized, the workload of sermant-injector needs to be deployed. This project adopts Helm for Kubernetes package management.
-
-Use Chart template in`injector` under `deploment/release`.
-
-Modify the template variable in `values.yaml` according to the actual environment:
-
-> 1. The value of `namespace.name` must be identical to the `NAMESPACE` in `certificate.sh`
->
-> 2. The values of `agent.image.addr` and `injector.image.addr` are the same as the image address when the images are built
->
-> 3. `injector.webhook.caBundle` is the K8s certificate, which can be obtained from the K8s node by executing the following command：
->
-> ```shell
-> kubectl config view --raw --minify --flatten -o jsonpath='{.clusters[].cluster.certificate-authority-data}'
-> ```
-
-Once this is done, execute `helm install` to deploy the sermant-injector workload in K8s:
-
-```shell
-helm install sermant-injector ../injector
-```
-
-Check that the status of the deployed pod of sermant-injector is running.
-
-At this point, the environment configuration of the host application before deployment is complete.
-
-### Deploy Host Application
-
-#### Deployment
-
-After the deployment of above sermant-injector, developers should write YAML file to deploy K8s Deployment resources according to the actual application. Simply add `sermant-injection: enabled` at the `spec > Template > Metadata > Labels` to automatically mount the sermant-agent. (If you do not want to mount it later, just delete it and restart the application)
-
-```yaml
-apiVersion: v1
-kind: Deployment
-metadata:
- name: demo-test
- labels:
- app: demo-test
-spec:
- replicas: 1
- selector:
- app: demo-test
- matchLabels:
- app: demo-test
- template:
- metadata:
- labels:
- app: demo-test
- sermant-injection: enabled
- spec:
- containers:
- - name: image
- # Please replace it with own image
- image: image:1.0.0
- ports:
- - containerPort: 8080
- ports:
- - port: 443
- targetPort: 8443
-```
-
-If the pod cannot be created, check that the sermant-injector is deployed correctly and that the sermant-agent image is built correctly.
-
-#### Verification
-
-Once the pod is created, execute the following command, where `${pod_name}` is the pod name of host application.
-
-```shell
-kubectl get po/${pod_name} -o yaml
-```
-
-1. Check if the output contains the environment variable whose name is `JAVA_TOOL_OPTIONS`and value is `-javaagent:/home/sermant-agent/agent/sermant-agent.jar=appName=default` in `spec > containers > - env`.
-
-2. Check if the value of `spec > containers > initContainers > image` is the image address used to build the sermant-agent image.
-
-Execute the following command, where `${pod_name}` is the pod name of host application and `${namespace}` is the namespace name of deployed host application.
-
-```shell
-kubectl logs ${pod_name} -n ${namespace}
-```
-
-3. Check if the beginning of the pod log in the output of the above command contains:
-
-```
-[INFO] Loading sermant agent...
-```
-
-If the above information is correct, the sermant-agent has been successfully mounted into the host application.
diff --git a/docs/user-guide/loadbalancer/document-zh.md b/docs/user-guide/loadbalancer/document-zh.md
deleted file mode 100644
index 35740b2522..0000000000
--- a/docs/user-guide/loadbalancer/document-zh.md
+++ /dev/null
@@ -1,181 +0,0 @@
-# 负载均衡
-
-[简体中文](document-zh.md) | [English](document.md)
-
-该文档主要介绍[负载均衡插件](../../../sermant-plugins/sermant-loadbalancer)的使用方法
-
-## 功能:
-
-根据配置中心的配置，无侵入地动态修改宿主应用的负载均衡策略。
-
-## 负载均衡策略支持一览
-
-| 框架类型 | 策略名 | 配置值 / 负载均衡策略 | 版本支持 |
-| --------------------------- | ---------------------------- | ---------------------------------------------- | ------------------------------------------------------------ |
-| dubbo | 随机（dubbo默认） | Random / RANDOM | 2.6.x, 2.7.x |
-| dubbo | 轮询 | RoundRobin / ROUNDROBIN | 2.6.x, 2.7.x |
-| dubbo | 最少活跃 | leastActive / LEASTACTIVE | 2.6.x, 2.7.x |
-| dubbo | 一致性HASH | consistentHash / CONSISTENTHASH | 2.6.x, 2.7.x |
-| dubbo | 最短响应时间 | shortestResponse / SHORTESTRESPONSE | 2.7.7+ |
-| spring-cloud-netflix-ribbon | 区域权重（ribbon默认） | zoneAvoidance / ZONE_AVOIDANCE | ZONE_AVOIDANCEspring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 随机 | Random / RANDOM | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 轮询 | RoundRobin / ROUND_ROBIN | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 重试 | retry / RETRY | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 最低并发 | bestAvailable / BEST_AVAILABLE | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 筛选过滤轮询 | availabilityFiltering / AVAILABILITY_FILTERING | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 响应时间加权重（Deprecated） | ResponseTimeWeighted / RESPONSE_TIME_WEIGHTED | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | 响应时间加权重 | weightedResponseTime / WEIGHTED_RESPONSE_TIME | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-loadbalancer | 轮询（loadbalancer默认） | RoundRobin / ROUND_ROBIN | spring cloud Hoxton.SR10+, spring cloud 2020.0.x, spring cloud 2021.0.x |
-| spring-cloud-loadbalancer | 随机 | Random / RANDOM | spring cloud Hoxton.SR10+, spring cloud 2020.0.x, spring cloud 2021.0.x |
-
-## 配置说明
-
-负载均衡基于配置中心进行动态配置，因此使用该能力需在配置中心配置对应负载均衡策略。负载均衡插件采用**流量标记+负载均衡规则**的方式规则，即配置一条规则需**同时配置两者**，下面分别介绍两项配置：
-
-### 流量标记
-
-流量标记用于标记当前针对那些服务生效，若服务为空，则会应用与所有微服务，配置示例如下:
-
-**配置key:** `servicecomb.matchGroup.testLb`
-
-> 配置键说明:
->
-> `servicecomb.matchGroup. `：流量标记的固定前缀，所有key均需已此为前缀配置流量标记
->
-> `testLb`：业务场景名，对应的负载均衡规则需配置相同的业务场景名
-
-**配置content:**
-
-```yaml
-alias: loadbalancer-rule
-matches:
-- serviceName: zk-rest-provider # 目标服务名
-```
-
-示例规则说明: `serviceName`为下游服务名，即针对请求微服务`zk-rest-provider`将应用匹配的负载均衡规则；若配置项`serviceName`未配置，则应用于所有微服务。需要注意的是，该配置仅需配置`serviceName`配置项，其他的格式需保持不变。
-
-> 优先级说明：若同时配置了多个负载均衡规则，插件会优先匹配配置服务名的负载均衡规则，否则采用未配置服务名的匹配的负载均衡规则。
-
-### 负载均衡规则
-
-负载均衡规则需为应用配置具体的负载均衡策略，负载均衡策略目前完全依赖与宿主本身存在的负载均衡策略，即宿主本身支持才可配置，支持列表见[负载均衡策略支持一览](#负载均衡策略支持一览)。
-
-**配置key：**`servicecomb.loadbalance.testLb`
-
-> 配置键说明:
->
-> `servicecomb.loadbalance. `：负载均衡规则配置的固定前缀，所有key均需已此为前缀配置负载均衡规则
->
-> `testLb`：业务场景名，需与流量标记的业务场景相同才可生效
-
-**配置content:**
-
-```yaml
-rule: Random
-```
-
-示例配置项说明: 即配置**随机负载均衡规则**， 配置值见表[负载均衡策略支持一览](#负载均衡策略支持一览)的**配置值**
-
-> 以上需确认宿主自身应用的框架版本，确定当前支持的负载均衡策略。
-
-### 发布配置
-
-Sermant backend提供api的方式发布配置, 使用前需启动backend后台应用，如下为配置发布接口：
-
-**URL**
-
-POST /publishConfig
-
-**请求Body**
-
-| 参数 | 是否必填 | 参数类型 | 描述 |
-| ------- | -------- | -------- | ---------------------- |
-| key | √ | String | 配置键 |
-| group | √ | String | 配置组，用于配置订阅 |
-| content | √ | String | 配置文本，即为具体规则 |
-
-其中上表中`key`与`content`对应流量标记与负载均衡规则的配置key与配置content，而group则是针对指定服务的标签，group的配置采用标签对的模式进行配置，例如app=default&environment=development即对同时订阅该标签的微服务发布配置。
-
-负载均衡插件默认会存在三种订阅标签：
-
-- 自定义标签：默认会订阅标签`public=default`，您也可以通过设置环境变量修改自定义标签，启动参数添加如下参数：`-Dservice.meta.customLabel=public -Dservice.meta.customLabelValue=default`
-- 微服务标签: 默认会订阅标签`app=default&service=${yourServiceName}&environment=`，其中`${yourServiceName}`为微服务的名称，`environment`默认为空。当然同样可以采用环境变量进行变更，启动参数添加如下参数：`-Dservice.meta.application=default -Dservice.meta.environment=${yourEnvironment}`, 分别对应`app`与`envrionment`，而服务名为动态获取。
-- 应用标签：默认会订阅标签`app=default&&environment=`, `environment`默认为空, 环境变量配置方式同**微服务标签**。
-
-### 版本说明
-
-- 在spring cloud 2020.0.x之前，spring cloud负载均衡默认使用的核心组件为spring-cloud-netflix-ribbon（宿主应用可通过排除ribbon相关的组件使用spring-cloud-loadbalancer组件），从spring cloud 2020.0.x开始，负载均衡的核心组件为spring-cloud-loadbalancer。
-
-- 在spring cloud Hoxton.SR10之前，spring-cloud-loadbalancer的负载均衡策略只有轮询（ROUND_ROBIN），所以插件并不支持修改Hoxton. SR10之前的spring-cloud-loadbalancer组件的负载均衡策略，spring cloud Hoxton.SR10之前版本建议使用spring-cloud-netflix-ribbon组件进行负载均衡。
-
-## 结果验证
-
-1. 前提条件[已下载Sermant RELEASE包](https://github.com/huaweicloud/Sermant/releases), [已下载demo源码](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-register)，[已下载zookeeper](https://zookeeper.apache.org/releases.html#download)
-
-2. 启动zookeeper
-
-3. 启动backend, 参考[后端模块介绍](../backend-zh.md)
-
-4. 编译demo应用
-
- ```
- mvn clean package
- ```
-
-
-
-5. 发布流量标记
-
- 调用接口`localhost:8900/publishConfig`, 请求参数如下:
-
- ```json
- {
- "content": "alias: loadbalancer-rule\nmatches:\n- serviceName: zk-rest-provider",
- "group": {
- "app": "default",
- "environment": "",
- "service": "zk-rest-consumer"
- },
- "key": "servicecomb.matchGroup.testLb"
- }
- ```
-
-
-
-6. 发布匹配的负载均衡规则（以Random为例）
-
- 调用接口`localhost:8900/publishConfig`, 请求参数如下:
-
- ```json
- {
- "content": "rule: Random",
- "group": {
- "app": "default",
- "environment": "",
- "service": "zk-rest-consumer"
- },
- "key": "servicecomb.loadbalance.testLb"
- }
- ```
-
-
-
-7. 启动生产者（两个实例）
-
- ```shell
- java -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -Dserver.port=${port} -jar zk-rest-provider.jar
- ```
-
- 其中`path`需要替换为Sermant实际打包路径, `port`为生产者端口，这里需要启动两个实例, 请分别配置不同的端口，有利于结果观察
-
-8. 启动消费者（一个实例即可）
-
- ```shell
- java -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -Dserver.port=8005 -jar zk-rest-consumer.jar
- ```
-
-9. 测试
-
- 上面步骤全部完成后，访问接口`localhost:8005/hello`, 通过返回的端口判断随机负载均衡规则（默认为轮询）是否生效。
-
-[返回**Sermant**说明文档](../../README-zh.md)
diff --git a/docs/user-guide/loadbalancer/document.md b/docs/user-guide/loadbalancer/document.md
deleted file mode 100644
index 2e0210a6e6..0000000000
--- a/docs/user-guide/loadbalancer/document.md
+++ /dev/null
@@ -1,181 +0,0 @@
-# Loadbalancer
-
-[简体中文](document-zh.md) | [English](document.md)
-
-This document is used to introduce the usage of [loadbalancer](../../../sermant-plugins/sermant-loadbalancer)
-
-## Functions:
-
-Based on the configuration in the configuration center, the loadbalance rules of the host application can be dynamically modified without intrusion.
-
-## The Strategy Loadbalacne Support
-
-| Framework | Strategy | Configuration value/Loadbalance Strategy | version support |
-| --------------------------- | ------------------------------------ | ---------------------------------------------- | ------------------------------------------------------------ |
-| dubbo | Random (Dubbo default) | Random / RANDOM | 2.6.x, 2.7.x |
-| dubbo | RoundRobin | RoundRobin / ROUNDROBIN | 2.6.x, 2.7.x |
-| dubbo | leastActive | leastActive / LEASTACTIVE | 2.6.x, 2.7.x |
-| dubbo | Consistent hash | consistentHash / CONSISTENTHASH | 2.6.x, 2.7.x |
-| dubbo | Minimum response time | shortestResponse / SHORTESTRESPONSE | 2.7.7+ |
-| spring-cloud-netflix-ribbon | Area weight (default value) | zoneAvoidance / ZONE_AVOIDANCE | ZONE_AVOIDANCEspring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | Random | Random / RANDOM | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | RoundRobin | RoundRobin / ROUND_ROBIN | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | retry | retry / RETRY | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | bestAvailable | bestAvailable / BEST_AVAILABLE | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | availabilityFiltering | availabilityFiltering / AVAILABILITY_FILTERING | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | Response Time Weighting (Deprecated) | ResponseTimeWeighted / RESPONSE_TIME_WEIGHTED | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-netflix-ribbon | Response time weighting | weightedResponseTime / WEIGHTED_RESPONSE_TIME | spring cloud Edgware.x, spring cloud Finchley.x, spring cloud Greenwich.x, spring cloud Hoxton.x |
-| spring-cloud-loadbalancer | RoundRobin(default) | RoundRobin / ROUND_ROBIN | spring cloud Hoxton.SR10+, spring cloud 2020.0.x, spring cloud 2021.0.x |
-| spring-cloud-loadbalancer | Random | Random / RANDOM | spring cloud Hoxton.SR10+, spring cloud 2020.0.x, spring cloud 2021.0.x |
-
-## How to Configure
-
-Load balancing is dynamically configured based on the configuration center. To use this capability, you need to configure the corresponding load balancing policy in the configuration center. The loadbalance plugin uses **traffic marking + loadbalance rules**. To configure a rule, you **need to configure both of them**. The following describes the two configurations:
-
-### Traffic Marking
-
-Traffic marking is used to mark the services that take effect. If the service is empty, the traffic marking is applied to all microservices. The configuration example is as follows:
-
-**Configuring key:** `servicecomb.matchGroup.testLb`
-
-> description of key:
->
-> `servicecomb.matchGroup. `：Fixed prefix of traffic marking. Traffic marking must be configured for all keys.
->
-> `testLb`：Service scenario name. The corresponding load balancing rule must be configured with the same service scenario name.
-
-**configure content:**
-
-```yaml
-alias: loadbalancer-rule
-matches:
-- serviceName: zk-rest-provider # downstream service name
-```
-
-Example rule description: serviceName indicates the name of the downstream service, that is, the loadbalance rule to be applied to the requested microservice zk-rest-provider. If the serviceName configuration item is not set, the configuration item applies to all microservices. Note that only the serviceName configuration item needs to be configured in this configuration. Other formats remain unchanged.
-
-> Priority: If multiple load balancing rules are configured, the plugin preferentially matches the load balancing rule with the service name configured. Otherwise, the plugin uses the load balancing rule with no service name configured.
-
-### Loadbalance Rule
-
-Load balancing rules must be configured for applications. Load balancing policies depend on the existing load balancing policies of the host. That is, load balancing policies can be configured only when the host supports the load balancing policies. For details about the supported load balancing policies, see the [The Strategy Loadbalacne Support](#The-Strategy-Loadbalacne-Support).
-
-**configure key：**`servicecomb.loadbalance.testLb`
-
-> configuration item description:
->
-> `servicecomb.loadbalance. `：Fixed prefix configured for the loadbalancer rule. Loadbalancer rules must be configured for all keys.
->
-> `testLb`：Service scenario name, which takes effect only when it is the same as the service scenario of the traffic flag.
-
-**configure content:**
-
-```yaml
-rule: Random
-```
-
-Example configuration item description: Configure a random load balancing rule. For details about the configuration values, see the [The Strategy Loadbalacne Support](#The-Strategy-Loadbalacne-Support).
-
-> Check the framework version of the host application and determine the supported load balancing strategy.
-
-### Publish Loadbalance Rule
-
-The Sermant Backend provides APIs for releasing configurations. Before using the API, you need to start the backend application. The following describes the configuration publishing interface:
-
-**URL**
-
-POST /publishConfig
-
-**Request Body**
-
-| Params | Mandatory or not | Param type | Description |
-| ------- | ---------------- | ---------- | ------------------------------------------------------------ |
-| key | √ | String | configuration key |
-| group | √ | String | Configuration group, which is used to configure subscriptions |
-| content | √ | String | Configuration text, that is, specific rules |
-
-In the preceding table, the key and content correspond to the key and content of the traffic tag and load balancing rule. The group refers to the tag of the specified service. The group is configured in the tag pair mode. For example, app=default&environment=development indicates publishing configurations for microservices that subscribe to this tag.
-
-The loadbalance plugin has three subscription tags by default.：
-
-- custom tag：By default, the tag `public=defaul`t is subscribed to. You can also modify the customized tag by setting environment variables and add the following parameters to the startup parameter: `-Dservice.meta.customLabel=public -Dservice.meta.customLabelValue=default`
-- microservice tag: By default, the `app=default&service=${yourServiceName}&environment= tag is subscribed. ${yourServiceName}` indicates the microservice name and environment is empty by default. You can also use environment variables to change the startup parameters. Add the following parameters to the startup parameters: `-Dservice.meta.application=default -Dservice.meta.environment=${yourEnvironment}`, corresponds to app and envrionment, and the service name is dynamically obtained.
-- application tag：By default, the tag `app=default&environment=` is subscribed. The environment variable configuration method is the same as that of the microservice tag.
-
-### Version Notices
-
-- In versions earlier than spring cloud 20200.0.x, the core component used by spring cloud load balancers is spring-cloud-netflix-ribbon by default. (The host application can use the spring-cloud-loadbalancer component by excluding ribbon-related components.) From spring cloud 20200.0.x, the core component of load balancing is spring-cloud-loadbalancer.
-
-- In versions earlier than spring cloud Hoxton.SR10, the load balancing policy of spring-cloud-loadbalancer can only be round robin (ROUND_ROBIN). Therefore, the plugin does not support modifying the load balancing policy of spring-cloud-loadbalancer components earlier than Hoxton.SR10. For versions earlier than spring cloud Hoxton.SR10, you are advised to use the spring-cloud-netflix-ribbon component for load balancing.
-
-## Verify Result
-
-1. Prerequisites: [sermant has been downloaded](https://github.com/huaweicloud/Sermant/releases), [the demo source code is downloaded](https://github.com/huaweicloud/Sermant-examples/tree/main/sermant-template/demo-register), and [the ZooKeeper is downloaded](https://zookeeper.apache.org/releases.html#download).
-
-2. start zookeeper
-
-3. start backend, referring to the [backend module introduction](../backend.md)
-
-4. compile and package demo application
-
- ```
- mvn clean package
- ```
-
-
-
-5. publish traffic marking rule
-
- Invoke the interface `localhost:8900/publishConfig`, request body just follow below:
-
- ```json
- {
- "content": "alias: loadbalancer-rule\nmatches:\n- serviceName: zk-rest-provider",
- "group": {
- "app": "default",
- "environment": "",
- "service": "zk-rest-consumer"
- },
- "key": "servicecomb.matchGroup.testLb"
- }
- ```
-
-
-
-6. publish loadbalance rule (Random as a example).
-
- Invoke the interface`localhost:8900/publishConfig`, request body just follow below:
-
- ```json
- {
- "content": "rule: Random",
- "group": {
- "app": "default",
- "environment": "",
- "service": "zk-rest-consumer"
- },
- "key": "servicecomb.loadbalance.testLb"
- }
- ```
-
-
-
-7. Starting a provider (two instances)
-
- ```shell
- java -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -Dserver.port=${port} -jar zk-rest-provider.jar
- ```
-
- Replace `path` with the **actual packaging path** of the Sermant and port with the producer port. In this example, you need to start two instances. Configure different ports for the two instances.
-
-8. Start a consumer (one instance).
-
- ```shell
- java -javaagent:${path}\sermant-agent-x.x.x\agent\sermant-agent.jar=appName=default -Dserver.port=8005 -jar zk-rest-consumer.jar
- ```
-
-9. testing
-
- After the preceding steps are complete, access the localhost:8005/hello interface and check whether the random load balancing rule (by default, RoundRobin) takes effect based on the returned port.
-
-[Back to README of **Sermant** ](../../README.md)
diff --git a/docs/user-guide/monitor/document-zh.md b/docs/user-guide/monitor/document-zh.md
deleted file mode 100644
index b3e805e68c..0000000000
--- a/docs/user-guide/monitor/document-zh.md
+++ /dev/null
@@ -1,177 +0,0 @@
-# monitor
-
-本文档主要用于[monitor模块](../../../sermant-plugins/sermant-monitor)的使用说明
-
-资源监控模块用于监控宿主应用所在服务器的CPU、内存、磁盘IO和网络IO等硬件资源的使用情况，以及宿主应用Java虚拟机的使用情况。
-监控模块依赖于prometheus进行指标收集,prometheus定期调用java agent的httpServer服务，获取插件注册的指标信息，并进行存储展示。
-
-## 目录说明
-
-- `config`: 配置文件目录
-- `monitor-service`: 服务器硬件资源和JVM监控采集服务
-
-## 配置文件内容说明
-```yaml
-monitor.config: # 监控服务配置
- enable-start-service: false # 监控服务启动开关
-```
-
-## monitor-service插件说明
-
-*使用背景*
-
-本服务包含两个采集子服务，分别为Linux资源监控采集、JVM资源监控
-
-- Linux资源监控采集功能需要宿主应用部署在Linux环境。
-- JVM内存监控采集功能需要宿主应用使用OpenJDK或者基于OpenJDK的JDK版本
-
-*功能说明*
-
-- **Linux资源监控采集**：通过执行linux命令获取系统CPU、内存、磁盘IO、网络IO资源使用情况数据，并注册到prometheus的默认注册器。
-```shell
- #CPU
- cat /proc/stat
- #MEMORY
- cat /proc/meminfo
- #DISK
- cat /proc/diskstats
- #NETWORK
- cat /proc/net/dev
- #CPU CORE
- lscpu
- ```
-- **采集内容**
-```
- CPU
- double cpu_user; // 用户态时间占比
- double cpu_sys; // 系统时间占比
- double cpu_wait; // 等待时间百分占比
- double cpu_idle; // 空闲时间占比
- double cpu_cores; // CPU物理核心数
-```
-
-```
- 内存使用情况
- double memory_total; // 总内存大小
- double memory_swap; // 对应cat /proc/meminfo指令的SwapCached
- double memory_cached; // 对应cat /proc/meminfo指令的Cached
- double memory_buffer; // 对应cat /proc/meminfo指令的Buffers
- double memory_used; // 已使用的内存大小
-```
-
-```
- 内存使用情况
- double memory_total; // 总内存大小
- double memory_swap; // 对应cat /proc/meminfo指令的SwapCached
- double memory_cached; // 对应cat /proc/meminfo指令的Cached
- double memory_buffer; // 对应cat /proc/meminfo指令的Buffers
- double memory_used; // 已使用的内存大小
-```
-
-```
- 磁盘IO
- double disk_readBytesPerSec; // 采集周期内的每秒读字节数
- double disk_writeBytesPerSec; // 采集周期内的每秒写字节数
- double disk_ioSpentPercentage; // 采集周期内，IO花费的时间百分占比
-```
-
-```
- 网络
- double network_readBytesPerSec; // 采集周期内的每秒读字节数
- double network_writeBytesPerSec; // 采集周期内的每秒写字节数
- double network_readPackagePerSec; // 采集周期内的每秒读包数
- double network_writePackagePerSec; // 采集周期内的每秒写包数
-```
-
-- **JVM监控采集**：定时从java.lang.management.ManagementFactory获取JVM的指标情况
-
-```
- JVM内存
- double heap_memory_init; // 堆内存初始化值
- double heap_memory_max; // 堆内存最大值
- double heap_memory_used // 堆内存已使用
- double heap_memory_committed // 堆内存已提交
-
- double non_heap_memory_init; // 非堆内存初始化值
- double non_heap_memory_max; // 非堆内存最大值
- double non_heap_memory_used // 非堆内存已使用
- double non_heap_memory_committed // 非堆内存已提交
-
- double code_cache_init; // 代码缓存区初始化值
- double code_cache_max; // 代码缓存区最大值
- double code_cache_used // 代码缓存区已使用
- double code_cache_committed // 代码缓存区已提交
-
- double meta_sapce_init; // 元空间初始化值
- double meta_sapce_max; // 元空间最大值
- double meta_sapce_used // 元空间已使用
- double meta_sapce_committed // 元空间已提交
-
- double compressed_class_space_init; // 压缩类空间初始化值
- double compressed_class_space_max; // 压缩类空间最大值
- double compressed_class_space_used // 压缩类空间已使用
- double compressed_class_space_committed // 压缩类空间已提交
-
- double eden_init; // eden区内存初始化值
- double eden_max; // eden区内存最大值
- double eden_used // eden区内存已使用
- double eden_committed // eden区内存已提交
-
- double survivor_init; // survivor区内存初始化值
- double survivor_max; // survivor区内存最大值
- double survivor_used // survivor区内存已使用
- double survivor_committed // survivor区内存已提交
-
- double old_gen_init; // 老年代内存初始化值
- double old_gen_max; // 老年代内存最大值
- double old_gen_used // 老年代内存已使用
- double old_gen_committed // 老年代内存已提交
-```
-
-```
- 线程
- double thread_live; // 活动线程
- double thread_peak; // 线程峰值
- double thread_daemon; // 守护线程
-```
-
-```
- GC
- double new_gen_count; // 年轻代GC次数
- double new_gen_spend; // 年轻代GC耗时
- double old_gen_count; // 老年代GC次数
- double old_gen_spend; // 老年代GC耗时
-```
-
-```
- JVM其他指标
- double cpu_used; JVM占用CPU情况
- double start_time; JVM已经启动时间，毫秒数
-```
-
-*使用说明*
-
-1、修改sermant-agentcore-config监控配置--config.properties。修改对外提供服务的IP 端口 以及开关
-```yaml
-monitor.service.address=127.0.0.1 // 修改为宿主服务IP
-monitor.service.port=12345 // 修改为对外提供服务端口
-monitor.service.isStartMonitor=false // 对外服务开关 -- 开关true时prometheus可以调用服务端口获取指标信息
-```
-
-2、修改sermant-monitor的配置文件--config.properties。
-```yaml
-monitor.config: # 监控服务配置
- enable-start-service: false # 监控服务启动开关
-```
-修改enable-start-service为true
-
-3、修改prometheus的配置文件. 在scrape_configs下增加对应的job信息（根据第一步配置的内容）
-
-4、宿主应用挂载java agent之后即可在prometheus看到对应的指标信息。
-
-
-
-
-
-
-
diff --git a/docs/user-guide/registry/FAQ-zh.md b/docs/user-guide/registry/FAQ-zh.md
deleted file mode 100644
index 875ed4e1c2..0000000000
--- a/docs/user-guide/registry/FAQ-zh.md
+++ /dev/null
@@ -1,102 +0,0 @@
-# 服务注册常见问题
-
-[简体中文](FAQ-zh.md) | [English](FAQ.md)
-
-本文主要介绍[服务注册插件](../../../sermant-plugins/sermant-service-registry)在使用时遇到的常见问题。
-
-## 报错：No such extension org.apache.dubbo.registry.RegistryFactory by name sc
-
-如下图所示：
-
-
-
-该错误原因有以下3种：
-
-1.1 宿主没有带agent启动。因为原生dubbo并不支持往sc注册，所以如果没带agent启动且配置的注册地址的协议为sc时，就会产生以上报错。
-
-1.2 核心配置文件（${agent_package_path}/agent/config/config.properties）配置问题。仔细观察启动日志，会发现伴有类似以下的错误：
-
-
-
-- 原因是核心配置文件中，配置中心类型（dynamic.config.dynamic_config_type）的值（需要为KIE/ZOOKEEPER）配置错误，从而导致宿主应用无法加载agent，最后导致No such extension org.apache.dubbo.registry.RegistryFactory by name sc的报错。
-
-1.3 核心配置文件（${agent_package_path}/agent/config/config.properties）配置问题。仔细观察启动日志，会发现伴有类似以下错误：
-
-
-
-- 原因是核心配置文件中，配置中心地址（dynamic.config.server_address）配置错误或者配置中心没有启动或者网络不通，从而导致宿主应用无法加载agent，最后导致No such extension org.apache.dubbo.registry.RegistryFactory by name sc的报错。
-
-## 报错：/sermant/master/v1/register error
-
-如下图所示：
-
-
-
-原因是backend未启动或者配置地址不正确，请启动backend或正确配置地址。backend相关信息请见[backend文档](../backend-zh.md)。
-
-注：该错误不会影响注册插件的流程，但会有相关报错。
-
-## 报错：Connection reset
-
-如下图所示：
-
-
-
-请检查插件配置（${agent_package_path}/agent/pluginPackage/service-registry/config/config.yaml）中，注册中心地址（servicecomb.service.address）是否正确，协议是否正确（http/https）。
-
-## 报错：https protocol is not supported
-
-如下图所示：
-
-
-
-需要在插件配置（${agent_package_path}/agent/pluginPackage/service-registry/config/config.yaml）中，开启ssl（servicecomb.service.sslEnabled）。
-
-## 报错：No such extension org.apache.dubbo.metadata.report.MetadataReportFactory by name sc
-
-如下图所示：
-
-
-
-请检查dubbo应用的注册配置，protocol是否存在且不为sc，如下所示：
-
-- 例如dubbo/provider.xml
-
-```xml
-