This is an automated email from the ASF dual-hosted git repository.
liubao pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/servicecomb-docs.git
The following commit(s) were added to refs/heads/master by this push:
new fa1bb04 add governance docs (#330)
fa1bb04 is described below
commit fa1bb04c91aa97b62607c9e07fe70173d992e754
Author: liubao68 <[email protected]>
AuthorDate: Thu Apr 25 17:47:35 2024 +0800
add governance docs (#330)
---
.../references-handlers/gateway-governance.png | Bin 0 -> 69657 bytes
.../governance-best-practise.md | 178 +++++++++++++
.../zh_CN/docs/references-handlers/governance.md | 98 -------
.../zh_CN/docs/references-handlers/ratelimit.md | 2 +-
.../docs/references-handlers/rule-governance.md | 296 +++++++++++++++++++++
.../references-handlers/service-governance.png | Bin 0 -> 75797 bytes
java-chassis-reference/zh_CN/mkdocs.yml | 3 +-
7 files changed, 477 insertions(+), 100 deletions(-)
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/gateway-governance.png
b/java-chassis-reference/zh_CN/docs/references-handlers/gateway-governance.png
new file mode 100644
index 0000000..3e78d7c
Binary files /dev/null and
b/java-chassis-reference/zh_CN/docs/references-handlers/gateway-governance.png
differ
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/governance-best-practise.md
b/java-chassis-reference/zh_CN/docs/references-handlers/governance-best-practise.md
new file mode 100644
index 0000000..07562da
--- /dev/null
+++
b/java-chassis-reference/zh_CN/docs/references-handlers/governance-best-practise.md
@@ -0,0 +1,178 @@
+# 流量特征治理最佳实践
+
+在[Java Chassis设计参考](../start/design.md)中总结了典型的微服务应用架构：
+
+
+
+参考这个架构，微服务系统有两个比较重要的微服务部件：应用网关和微服务。
这两个部件是微服务治理的重点对象，它们所处的位置和作用存在一些差异，因此应用服务治理的策略也会有所不同。 本文以这个两个部件说明常见的治理策略设计。
+
+首先，对应系统的所有API访问，做一个全局的业务定义。
+
+```yaml
+servicecomb:
+ matchGroup:
+ allOperation: |
+ matches:
+ - apiPath:
+ prefix: "/"
+```
+
+## 应用网关治理设计
+
+应用网关需要根据系统能够处理的最大流量，配置限流器，快速拒绝超过系统的流量，由用户（前端脚本）发起重试，在保证系统可用性的同时，尽可能降低对于用户体验的影响。还需要提供一定的基于背压的服务治理能力，比如如果后端服务某个实例不可用，或者某个服务刚刚启动完毕，需要初始化，发往这些服务的请求会表现为时延增加，如果不根据时延增加的反馈进行流量控制，就会导致用户体验极速下降。
+
+
+
+应用网关配置限流器、熔断器和隔离仓。
+
+*
服务端限流器：超过系统最大处理能力的请求场景，限流值的依据是压测的真实能力数据，可以控制在最大处理能力的80%左右。在系统上线初始阶段，默认设置全局限流器。在无法估算限流大小的时候，可以将流量限制设置为一个最大值，限流器也可以起到流量梳理平滑流量的作用。
+* 客户端熔断器：主要解决实例异常下线，本地缓存感知不及时的问题。实例熔断后会触发实例查询。因此，应用网关的熔断器的隔离时间会设置的比较短。
+*
客户端隔离仓：主要解决故障场景，比如数据库故障恢复、实例重启等，系统吞吐量下降的情况；或者微服务第一次启动、微服务长期没有请求突然进来大量请求的场景，这些场景可以限制并发连接，避免造成微服务和网关CPU大量使用，请求超时。
+* 应用网关可选客户端容错配置。最佳的方案是由小程序、WEB端应用发起重试，进行客户端容错。
+
+### 配置
+
+```yaml
+servicecomb:
+ matchGroup:
+ allOperation: |
+ matches:
+ - apiPath:
+ prefix: "/"
+ rateLimiting:
+ ## 限流器每10毫秒允许通过100个请求，如果一个请求超过1000毫秒没有获取到
+ ## 许可，将被拒绝
+ allOperation: |
+ rate: 100
+ limitRefreshPeriod: 10
+ timeoutDuration: 1000
+ instanceIsolation:
+ ## 熔断器错误率达到50%或者耗时请求达到100%，将开启。
+ ## 开启时间为5000毫秒，然后会放通10个请求。
+ allOperation: |
+ minimumNumberOfCalls: 10
+ slidingWindowSize: 20
+ slidingWindowType: COUNT_BASED
+ failureRateThreshold: 50
+ slowCallRateThreshold: 100
+ slowCallDurationThreshold: 1000
+ waitDurationInOpenState: 5000
+ permittedNumberOfCallsInHalfOpenState: 10
+ instanceBulkhead:
+ ## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到
+ ## 许可，将被拒绝。
+ allOperation: |
+ maxConcurrentCalls: 20
+ maxWaitDuration: 1000
+```
+
+### 持续演进
+场景一：耗时请求需要配置独立的限流策略。需要结合业务的持续演进，进行配置增加。
+
+```yaml
+servicecomb:
+ matchGroup:
+ timeConsumingOperation: |
+ matches:
+ - apiPath:
+ prefix: "/timeConsumingOperation"
+ rateLimiting:
+ ## 限流器每100毫秒允许通过1个请求，如果一个请求超过1000毫秒没有获取到
+ ## 许可，将被拒绝
+ timeConsumingOperation: |
+ rate: 1
+ limitRefreshPeriod: 100
+ timeoutDuration: 1000
+```
+
+场景二：需要防止机器人的场景，或者需要防止DDOS的场景，需要先考虑应用网关的扩容，然后根据用户ID或者请求端IP进行分布式限流。应用系统在规划的时候，需要考虑将用户ID通过HTTP
HEADER的方式传递；或者ELB需要将客户的IP通过x-real-ip HTTP HEADER传递。
+
+```yaml
+servicecomb:
+ matchGroup:
+ allOperation: |
+ matches:
+ - apiPath:
+ prefix: "/"
+ identifierRateLimiting:
+ ## 限流器每100毫秒允许通过1个请求，如果一个请求超过1000毫秒没有获取到
+ ## 许可，将被拒绝。相当于限制每个用户1秒钟10个请求。
+ allOperation: |
+ rate: 1
+ limitRefreshPeriod: 100
+ timeoutDuration: 1000
+ identifier: user-id
+```
+
+## 微服务治理设计
+
+微服务治理设计和网关设计有很多类似之处，也有少量的差异。
+
+
+
+微服务配置服务端限流、服务端隔离仓、客户端容错、客户端熔断和客户端隔离仓。
+
+*
服务端限流器：超过系统最大处理能力的请求场景，限流值的依据是压测的真实能力数据，可以控制在最大处理能力的80%左右。在系统上线初始阶段，默认设置全局限流器。在无法估算限流大小的时候，可以将流量限制设置为一个最大值，限流器也可以起到流量梳理平滑流量的作用。
+* 服务端隔离仓：主要针对耗时请求进行配置，防止耗时请求占用其他请求的处理资源。
+* 客户端重试器：主要解决网络错误、服务上下线的短暂故障等进行快速重试，降低错误率。该重试器只针对发送请求失败的场景，不涉及接口幂等问题。
+* 客户端熔断器：主要解决实例故障客户端没感知的场景，实现实例的快速刷新和同步。
+*
客户端隔离仓：主要解决故障场景，比如数据库故障恢复、实例重启等，系统吞吐量下降的情况；或者微服务第一次启动、微服务长期没有请求突然进来大量请求的场景，这些场景可以限制并发连接，避免造成微服务和网关CPU大量使用，请求超时。
+
+### 配置
+
+```yaml
+servicecomb:
+ matchGroup:
+ allOperation: |
+ matches:
+ - apiPath:
+ prefix: "/"
+ rateLimiting:
+ ## 限流器每10毫秒允许通过100个请求，如果一个请求超过1000毫秒没有获取到
+ ## 许可，将被拒绝
+ allOperation: |
+ rate: 100
+ limitRefreshPeriod: 10
+ timeoutDuration: 1000
+ instanceIsolation:
+ ## 熔断器错误率达到50%或者耗时请求达到100%，将开启。
+ ## 开启时间为5000毫秒，然后会放通10个请求。
+ allOperation: |
+ minimumNumberOfCalls: 10
+ slidingWindowSize: 20
+ slidingWindowType: COUNT_BASED
+ failureRateThreshold: 50
+ slowCallRateThreshold: 100
+ slowCallDurationThreshold: 1000
+ waitDurationInOpenState: 5000
+ permittedNumberOfCallsInHalfOpenState: 10
+ instanceBulkhead:
+ ## 隔离仓限制正在处理的请求数为20个，新来的请求等待1000毫秒没有获取到
+ ## 许可，将被拒绝。
+ allOperation: |
+ maxConcurrentCalls: 20
+ maxWaitDuration: 1000
+```
+
+### 持续演进
+
+场景一：服务端耗时请求，需要增加隔离仓配置。
+
+```yaml
+servicecomb:
+ matchGroup:
+ timeConsumingOperation: |
+ matches:
+ - apiPath:
+ prefix: "/timeConsumingOperation"
+ bulkhead:
+ ## 隔离仓限制正在处理的请求数为2个，新来的请求等待1000毫秒没有获取到
+ ## 许可，将被拒绝。
+ timeConsumingOperation: |
+ maxConcurrentCalls: 2
+ maxWaitDuration: 1000
+```
+
+## 关于最佳实践的说明
+
+任何的服务治理策略，都无法保证所有场景都能够优雅的工作，需要在成功率、可靠性、用户体验等多方面进行权衡，最佳实践提到的策略也不例外。最佳实践总体上倾向于设计一个准实时、优先保证用户体验的策略，并且尽可能的防止系统产生雪崩效应。这个策略在检测到系统过载的条件下，优先使用快速失败的策略，降低对于系统资源的占用，并通过重试来降低快速失败对于用户体验的影响。这种策略对于追求用户体验的互联网系统是非常棒的选择。这种策略会导致较多的请求失败（虽然通过重试可以成功），所以它不太适合对于成功率要求高于用户体验影响的场景，对于这些场景，在隔离仓上面应该配置更大的并发数限制，并设置较长的请求等待时间。
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
b/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
deleted file mode 100644
index 3fe5bbe..0000000
--- a/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
+++ /dev/null
@@ -1,98 +0,0 @@
-# 流量特征治理
-
-流量特征治理旨在提供一种通用的，适合不同语言、不同微服务开发框架的治理规则。治理规则规定了微服务治理的过程、治理的策略，
-可以使用不同的开发框架、技术实现治理规则约定的治理能力。
-
-开发者可以在 [ServiceComb Java Chassis][java-chassis], [Go
Chassis][go-chassis],[Spring Cloud][spring-cloud],
-[Dubbo][dubbo] 中使用该功能。
-
-[ServiceComb Java Chassis][java-chassis] 提供了实现 SDK，可以将其用于其他开发框架。SDK 默认采用
[Resilience4j][resilience4j]
-实现治理过程。规范没有约束治理过程的实现框架，可以很方便的使用其他的治理框架实现治理过程。
-
-流量特征治理[概念和规范参考](https://github.com/huaweicloud/spring-cloud-huawei/wiki/using-governance)
-
-[java-chassis]: https://github.com/apache/servicecomb-java-chassis
-[go-chassis]: https://github.com/go-chassis/go-chassis
-[spring-cloud]: https://github.com/huaweicloud/spring-cloud-huawei
-[dubbo]: https://github.com/huaweicloud/dubbo-servicecomb
-[resilience4j]: https://github.com/resilience4j
-
-## 使用客户端熔断
-
-配置参数：
-
-```
-servicecomb:
- instanceIsolation:
- allOperation: |
- minimumNumberOfCalls: 10
- slidingWindowSize: 20
- slidingWindowType: COUNT_BASED
- failureRateThreshold: 50
- slowCallRateThreshold: 100
- slowCallDurationThreshold: 3000
- waitDurationInOpenState: 10000
- permittedNumberOfCallsInHalfOpenState: 10
-```
-
-上诉参数使用计算滑动窗口，如果错误率超过50%，就会进行熔断。
-
-## 使用客户端隔离仓
-
-配置参数：
-
-```
-servicecomb:
- instanceBulkhead:
- allOperation: |
- maxConcurrentCalls: 20
- maxWaitDuration: 1000
-```
-
-上诉参数控制最大并发数为20，超过的请求会等待1000毫秒以获取许可，如果得到许可，可以继续处理，否则会拒绝请求。
-
-## 使用重试
-
-配置参数：
-
-```yaml
-servicecomb:
- retry:
- allOperation: |
- maxAttempts: 2
- retryOnSame: 0
-```
-
-maxAttempts表示最大重试次数（不包括第1次调用），retryOnSame表示使用第1次调用的实例进行重试次数。后续的重试会根据负载均衡策略，重新选择一个新的实例重试（也可能选择到同一个实例）。
-
-**注意事项:**
-
-* 并不是所有的异常都会触发重试。缺省的情况，只有网络异常，或者 502，503 错误码才会触发重试。 详细可以参考
`ServiceCombRetryExtension` 的定义。
-
-## 组合使用
-
-一个比较好的实践是组合使用 `重试` 、 `客户端熔断` 和 `客户端隔离仓`。
-
-这种组合可以防止偶然的实例错误导致的失败，也可以防止单个实例处理能力下降（比如刚刚启动的实例、故障的实例等场景）导致的整体故障。
-
-```
-servicecomb:
- retry:
- allOperation: |
- maxAttempts: 2
- retryOnSame: 0
- instanceIsolation:
- allOperation: |
- minimumNumberOfCalls: 10
- slidingWindowSize: 20
- slidingWindowType: COUNT_BASED
- failureRateThreshold: 50
- slowCallRateThreshold: 100
- slowCallDurationThreshold: 3000
- waitDurationInOpenState: 10000
- permittedNumberOfCallsInHalfOpenState: 10
- instanceBulkhead:
- allOperation: |
- maxConcurrentCalls: 20
- maxWaitDuration: 1000
-```
diff --git a/java-chassis-reference/zh_CN/docs/references-handlers/ratelimit.md
b/java-chassis-reference/zh_CN/docs/references-handlers/ratelimit.md
index 5a7320f..8862a47 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/ratelimit.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/ratelimit.md
@@ -8,7 +8,7 @@ java-chassis 支持 Provider 限流和 Consumer 限流。 Provider 限流控制
2. 流量控制是业务层面的功能，不是安全意义上的流量控制，如需防止DDoS攻击，需要结合其他的一系列措施。
3. 流量控制是微服务级的，不是实例级的。例如一个consumer服务有三个实例，当对它们依赖的provider实例配置限流策略后，
provider不会区分consumer的请求具体是由哪个实例发出的，而是汇总成微服务级的统计数据进行限流判断。
-4. 本模块介绍的限流机制是基于 `operation` 的， 使用起来比较简单。后续推荐使用[流量特征治理](governance.md) 来限制流量。
+4. 本模块介绍的限流机制是基于 `operation` 的， 使用起来比较简单。后续推荐使用[流量特征治理](using-governance.md)
来限制流量。
## 流控算法说明
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/rule-governance.md
b/java-chassis-reference/zh_CN/docs/references-handlers/rule-governance.md
new file mode 100644
index 0000000..7f16cc3
--- /dev/null
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/rule-governance.md
@@ -0,0 +1,296 @@
+# 流量特征治理
+
+流量特征治理旨在提供一种通用的，适合不同语言、不同微服务开发框架的治理规则。治理规则规定了微服务治理的过程、治理的策略，可以使用不同的开发框架、技术实现治理规则约定的治理能力。
+
+开发者可以在 Java Chassis, [Spring
Cloud](https://github.com/huaweicloud/spring-cloud-huawei), [Go
Chassis](https://github.com/go-chassis/go-chassis) 中使用该功能。
+
+Java Chassis提供了实现 SDK，可以将其用于其他开发框架。SDK 默认采用
[Resilience4j](https://github.com/resilience4j)
实现治理过程，并在规范中参考引用了很多其设计理念。规范没有约束治理过程的实现框架，可以很方便的使用其他的治理框架实现治理过程。
+
+## 概念定义
+
+流量特征治理可以从两个不同的角度进行描述。
+
+从管理流程上，可以分为进行 `业务定义` 和设置 `治理规则`
两个步骤。系统架构师将请求流量根据特征打上标记，用于区分一个或者一组代表具体含义的业务，然后对这些业务设置治理规则。
+
+从处理过程上，可以分为 `下发配置` 和 应用 `治理规则` 两个步骤。 可以通过配置文件、配置中心、环境变量等常见的配置管理手段下发配置。微服务 SDK
负责读取配置，解析治理规则，实现治理效果。
+
+* `业务定义`
+
+可以根据请求的特征进行业务定义。
+
+```yaml
+servicecomb:
+ matchGroup:
+ userLoginAction: |
+ matches:
+ - apiPath:
+ exact: "/login"
+ method:
+ - POST
+ - headers:
+ Authentication:
+ prefix: Basic
+```
+
+比如上面的示例定义了一个业务 `userLoginAction`，如果流量的 `apiPath=/login&method=POST`， 或者 请求头
`Authentication=Basic*` 那么认为这个流量是一个登陆操作。
+
+* `治理规则`
+
+定义好业务后，可以给它们设置治理规则。
+
+```yaml
+servicecomb:
+ rateLimiting:
+ userLoginAction: |
+ rate: 100
+```
+
+比如上面的示例设置 `userLoginAction` 的限流策略是 100 TPS。
+
+## 规范参考
+
+### 业务定义
+
+```yaml
+servicecomb:
+ matchGroup:
+ userLoginAction: |
+ matches:
+ - name: firstMatch
+ apiPath:
+ exact: "/login/v1"
+ method:
+ - POST
+ headers:
+ Authentication:
+ prefix: Basic
+ serviceName: exampleService
+ - name: secondeMatch
+ apiPath:
+ exact: "/login/v2"
+ method:
+ - POST
+ headers:
+ Authentication:
+ prefix: Basic
+ serviceName: exampleService
+ services: exampleService
+ name: userLoginAction
+```
+
+一个业务对应一个 Key， userLoginAction 为 Key 的名称。 一个业务可以定义多个标记规则，每个标记规则里面可以定义
`apiPath`, `method`, `headers`, `serviceName` 等匹配规则。 不同标记规则是或的关系，匹配规则是与的关系。
+
+* `services`: 可选。指出这个业务定义的生效范围。
在应用系统中，业务定义可能对于所有微服务都是可见的（如果业务定义只下发到该微服务，则不需要这个配置），一个微服务只会启用 `services`
包含自己的规则。这个属性可选，表示这条规则默认生效。可以使用 `example:1.0.0`
格式指明服务和版本，多个服务用逗号分隔，比如：`foo:1.0.0,bar`。
+
+* `name`: 可选。业务定义的名称。
+
+在match中提供了一系列的算子来对 `apiPath` 或者 `headers` 进行匹配.
+
+* `exact`: 精确匹配
+* `prefix`: 前缀匹配
+* `suffix`: 后缀匹配
+* `contains`: 包含， 目标字符串是否包含模式字符串
+* `compare`: 比较： 支持 >,<,>=,<=,=,!= 符号匹配，处理时会把模式字符串和目标字符串转化为 Double
类型进行比较，支持的数据范围为 Double 的数据范围。在进行 = 和 != 判断时 ， 如果二者的差值小于1e-6就视为相等。例如模式串为: >-10
会对大于-10以上的目标串匹配成功。
+
+业务定义可以在不同的应用层实现，比如在提供 REST 接口的服务端，可以通过 `HttpServletRequest` 获取请求信息。在
RestTemplate 调用的客户端，可以从
+`RestTemplate` 获取请求信息。不同的框架和应用层，提取信息的方式不一样。 实现层通过将特征映射到 `GovernanceRequest`
来屏蔽这些差异，使得在不同的框架，不同的应用层都可以使用治理。
+
+```java
+public class GovernanceRequest {
+ /**
+ headers with this request, maybe null.
+ For provider: headers indicates the request headers to me.
+ For consumer: headers indicates the request headers to the target.
+ */
+ private Map<String, String> headers;
+
+ /**
+ uri with this request, maybe null.
+ For provider: uri indicates the request uri to me.
+ For consumer: uri indicates the request uri to the target.
+ */
+ private String uri;
+
+ /**
+ method with this request, maybe null.
+ For provider: method indicates the request method to me.
+ For consumer: method indicates the request method to the target.
+ */
+ private String method;
+
+ /**
+ instance id with this request, maybe null.
+ For provider: instanceId indicates who calls me.
+ For consumer: instanceId indicates the target instance.
+ */
+ private String instanceId;
+
+ /**
+ microservice id (microservice name or application name + microservice
name) with this request, maybe null.
+ For provider: serviceName indicates who calls me.
+ For consumer: serviceName indicates the target service.
+ */
+ private String serviceName;
+}
+
+```
+
+### 限流
+
+```yaml
+servicecomb:
+ rateLimiting:
+ userLoginAction: |
+ timeoutDuration: 0
+ limitRefreshPeriod: 1000
+ rate: 1
+```
+
+规则解释：限流规则借鉴了`Resilience4j`的思想，其原理为：
每隔limitRefreshPeriod的时间会加入limitForPeriod（即rate）个新许可，如果获取不到新的许可(已经触发限流)，当前线程会park，最多等待timeoutDuration的时间，默认单位为毫秒。
+
+### 基于header的限流
+
+```yaml
+servicecomb:
+ identifierRateLimiting:
+ userLoginAction: |
+ timeoutDuration: 0
+ limitRefreshPeriod: 1000
+ rate: 1
+ identifier: user-id
+```
+
+基于header的限流和限流含义类似，它会针对 `identifier` 指定的 header 值， 每个值创建一个限流器。
+
+### 重试
+
+```yaml
+servicecomb:
+ retry:
+ userLoginAction: |
+ maxAttempts: 3
+ retryOnSame: 0
+ retryOnResponseStatus:
+ - 502
+ - 503
+ waitDuration: 1
+```
+
+规则解释：重试规则借鉴了`Resilience4j`的思想，其原理为：如果响应的错误码(502,
503)计算结果满足重试条件，或者异常在重试异常清单里面，则进行重试。下一次重试等待时间为 waitDuration。
+
+重试等待时间和具体的框架与运行机制有关。重试等待时间必须大于0。
+
+### 熔断
+
+```yaml
+servicecomb:
+ circuitBreaker:
+ userLoginAction: |
+ failureRateThreshold: 50
+ slowCallRateThreshold: 100
+ slowCallDurationThreshold: 60000
+ minimumNumberOfCalls: 100
+ slidingWindowType: COUNT_BASED
+ slidingWindowSize: 100
+ recordFailureStatus:
+ - 502
+ - 503
+ waitDurationInOpenState: 60000
+ permittedNumberOfCallsInHalfOpenState: 10
+ forceClosed: false
+ forceOpen: false
+```
+
+规则解释：熔断规则借鉴了`Resilience4j`的思想，其原理为：达到指定 failureRateThreshold 错误率或者
slowCallRateThreshold 慢请求率时进行熔断，慢请求通过 slowCallDurationThreshold
定义。minimumNumberOfCalls 是达到熔断要求的最低请求数量门槛。slidingWindowType指定滑动窗口
+类型，默认可选 COUNT_BASED和TIME_BASED 分别是基于请求数量窗口和基于时间窗口。slidingWindowSize
指定窗口大小，根据滑动窗口类型，单位是请求数量或者秒，根据滑动窗口类型决定。 forceClosed
表示强制关闭熔断器，即熔断器不工作；forceOpen表示强制开启熔断器，即请求都会发生熔断。
+
+熔断时间是waitDurationInOpenState，达到时间会放通permittedNumberOfCallsInHalfOpenState个请求。放通后，如果降低到阈值一下，则恢复；如果没有降低到阈值以下，则继续隔离。
+
+### 实例级熔断
+
+```yaml
+servicecomb:
+ instanceIsolation:
+ userLoginAction: |
+ failureRateThreshold: 50
+ slowCallRateThreshold: 100
+ slowCallDurationThreshold: 60000
+ minimumNumberOfCalls: 100
+ slidingWindowType: COUNT_BASED
+ slidingWindowSize: 100
+ recordFailureStatus:
+ - 502
+ - 503
+ waitDurationInOpenState: 60000
+ permittedNumberOfCallsInHalfOpenState: 10
+ forceClosed: false
+ forceOpen: false
+```
+
+实例级熔断和熔断的含义类似，但是他会针对每个实例创建一个熔断器。Java
Chassis会监听实例熔断事件，并调整熔断实例的优先级，降低对熔断实例的使用频率以达到实例隔离的作用。
+
+### 隔离仓
+
+```yaml
+servicecomb:
+ bulkhead:
+ userLoginAction: |
+ maxConcurrentCalls: 1000
+ maxWaitDuration: 0
+```
+
+规则解释：隔离仓规则借鉴了`Resilience4j`的思想，其原理为：当最大并发数超过 maxConcurrentCalls，等待
maxWaitDuration
+竞争资源，如果获得资源，则继续处理，如果获取不到，则拒绝执行请求。在异步框架，建议 maxWaitDuration 设置为0，防止阻塞事件派发线程。
+
+### 实例级隔离仓
+
+```yaml
+servicecomb:
+ instanceBulkhead:
+ userLoginAction: |
+ maxConcurrentCalls: 1000
+ maxWaitDuration: 0
+```
+
+实例级隔离仓和隔离仓的含义类似，但是他会针对每个实例创建一个隔离仓。
+
+### 错误注入
+
+```yaml
+servicecomb:
+ faultInjection:
+ userLoginAction: |
+ type: delay
+ delayTime: 1000
+ percentage: 50
+ errorCode: 500
+ fallbackType: ThrowException
+ forceClosed: false
+```
+
+规则解释：错误注入分为 `delay` 和 `abort` 两种。`delay` 表示对于 `percentage` 的请求，延迟 `delayTime`。
`abort` 表示对于 `percentage` 的请求，根据 `fallbackType` 抛出异常还是返回 null。
+
+### 公共参数
+
+治理规则存在一些公共参数， 比如 `services`, `order`, `name`。比如：
+
+```yaml
+servicecomb:
+ faultInjection:
+ userLoginAction: |
+ type: delay
+ delayTime: 1000
+ percentage: 50
+ errorCode: 500
+ fallbackType: ThrowException
+ forceClosed: false
+ services: helloService
+ order: 1
+ name: userLoginAction
+```
+
+* services: 表示该治理规则生效的微服务名称列表。
在应用系统中，治理规则可能对于所有微服务都是可见的（如果治理规则只下发到该微服务，则不需要这个配置），一个微服务只会启用 `services`
包含自己的规则。这个属性可选，表示这条规则默认生效。可以使用 `example:1.0.0`
格式指明服务和版本，多个服务用逗号分隔，比如：`foo:1.0.0,bar`。
+* order: 表示该治理规则的优先级，值越小优先级越高。 当一个请求匹配多个治理规则的时候，按照优先级使用优先级高的治理规则。
+* name: 表示该治理规则的名称，系统内部使用属性，其值等于规则里面的业务名称，用户不能修改。
+
+
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/service-governance.png
b/java-chassis-reference/zh_CN/docs/references-handlers/service-governance.png
new file mode 100644
index 0000000..a58ca29
Binary files /dev/null and
b/java-chassis-reference/zh_CN/docs/references-handlers/service-governance.png
differ
diff --git a/java-chassis-reference/zh_CN/mkdocs.yml
b/java-chassis-reference/zh_CN/mkdocs.yml
index ad012e4..89282da 100644
--- a/java-chassis-reference/zh_CN/mkdocs.yml
+++ b/java-chassis-reference/zh_CN/mkdocs.yml
@@ -86,11 +86,12 @@ nav:
- 使用Apollo: config/apollo.md
- 使用CSE1.0配置中心: config/cse1.md
- 服务治理功能参考:
+ - 流量特征治理: references-handlers/rule-governance.md
+ - 流量特征治理最佳实践: references-handlers/governance-best-practise.md
- 负载均衡: references-handlers/loadbalance.md
- 限流: references-handlers/ratelimit.md
- 灰度发布: references-handlers/router.md
- 故障注入: references-handlers/fault-injection.md
- - 流量特征治理: references-handlers/governance.md
- 快速失败和重试: references-handlers/fail-retry.md
- 网关功能参考:
- 介绍: edge/open-service.md
