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 81f598d update traffic governance (#276)
81f598d is described below
commit 81f598daddad6329f67a07272b89839ccc64c71f
Author: liubao68 <[email protected]>
AuthorDate: Wed Sep 14 08:59:14 2022 +0800
update traffic governance (#276)
---
.../zh_CN/docs/references-handlers/governance.md | 116 ++++++++++++++++++++-
.../zh_CN/docs/references-handlers/loadbalance.md | 29 ------
java-chassis-reference/zh_CN/mkdocs.yml | 2 +-
3 files changed, 113 insertions(+), 34 deletions(-)
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
b/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
index 16c879b..957c668 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
@@ -1,6 +1,6 @@
-# 基于动态配置的流量特征治理
+# 流量特征治理
-基于动态配置的流量特征治理旨在提供一种通用的，适合不同语言、不同微服务开发框架的治理规则。治理规则规定了微服务治理的过程、治理的策略，
+流量特征治理旨在提供一种通用的，适合不同语言、不同微服务开发框架的治理规则。治理规则规定了微服务治理的过程、治理的策略，
可以使用不同的开发框架、技术实现治理规则约定的治理能力。
开发者可以在 [ServiceComb Java Chassis][java-chassis], [Go
Chassis][go-chassis],[Spring Cloud][spring-cloud],
@@ -9,10 +9,118 @@
[ServiceComb Java Chassis][java-chassis] 提供了实现 SDK，可以将其用于其他开发框架。SDK 默认采用
[Resilience4j][resilience4j]
实现治理过程。规范没有约束治理过程的实现框架，可以很方便的使用其他的治理框架实现治理过程。
-基于动态配置的流量特征治理详细概念和开发指南请参考[微服务引擎开发指南](https://support.huaweicloud.com/devg-cse/cse_devg_0026.html)
+流量特征治理[概念和规范参考](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
\ No newline at end of file
+[resilience4j]: https://github.com/resilience4j
+
+## 使用客户端熔断
+
+在 `Handler` 中包含客户端熔断处理链：
+
+```yaml
+servicecomb:
+ handler:
+ chain:
+ Consumer:
+ default: loadbalance,instance-isolation-consumer
+```
+
+配置参数：
+
+```
+servicecomb:
+ instanceIsolation:
+ allOperation: |
+ minimumNumberOfCalls: 10
+ slidingWindowSize: 20
+ slidingWindowType: COUNT_BASED
+ failureRateThreshold: 50
+ slowCallRateThreshold: 100
+ slowCallDurationThreshold: 3000
+ waitDurationInOpenState: 10000
+ permittedNumberOfCallsInHalfOpenState: 10
+```
+
+上诉参数使用计算滑动窗口，如果错误率超过50%，就会进行熔断。
+
+## 使用客户端隔离仓
+
+在 `Handler` 中包含客户端熔断处理链：
+
+```yaml
+servicecomb:
+ handler:
+ chain:
+ Consumer:
+ default: loadbalance,instance-bulkhead-consumer
+```
+
+配置参数：
+
+```
+servicecomb:
+ instanceBulkhead:
+ allOperation: |
+ maxConcurrentCalls: 20
+ maxWaitDuration: 1000
+```
+
+上诉参数控制最大并发数为20，超过的请求会等待1000毫秒以获取许可，如果得到许可，可以继续处理，否则会拒绝请求。
+
+## 使用重试
+
+配置参数：
+
+```yaml
+servicecomb:
+ retry:
+ allOperation: |
+ maxAttempts: 2
+ retryOnSame: 0
+```
+
+maxAttempts表示最大重试次数（不包括第1次调用），retryOnSame表示使用第1次调用的实例进行重试次数。后续的重试会根据负载均衡策略，重新选择一个新的实例重试（也可能选择到同一个实例）。
+
+**注意事项:**
+
+* 并不是所有的异常都会触发重试。缺省的情况，只有网络异常，或者 502，503 错误码才会触发重试。 详细可以参考
`ServiceCombRetryExtension` 的定义。
+
+## 组合使用
+
+一个比较好的实践是组合使用 `重试` 、 `客户端熔断` 和 `客户端隔离仓`。
+
+```yaml
+servicecomb:
+ handler:
+ chain:
+ Consumer:
+ default:
loadbalance,instance-isolation-consumer,instance-bulkhead-consumer
+```
+
+这种组合可以防止偶然的实例错误导致的失败，也可以防止单个实例处理能力下降（比如刚刚启动的实例、故障的实例等场景）导致的整体故障。
+
+```
+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/loadbalance.md
b/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md
index 5c5310d..a9c42dd 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/loadbalance.md
@@ -179,35 +179,6 @@ servicecomb:
successiveFailedTimes: 5 # 客户端失败次数，超过后会切换服务器
```
-## 设置重试策略
-负载均衡模块还支持配置失败重试的策略。
-```yaml
-servicecomb:
- loadbalance:
- retryEnabled: false
- retryOnNext: 0
- retryOnSame: 0
-```
-缺省情况未启用重试。同时也支持对不同的服务设置特殊的策略：
-```yaml
-servicecomb:
- loadbalance:
- myservice：
- retryEnabled: true
- retryOnNext: 1
- retryOnSame: 0
-```
-
-retryOnNext表示失败以后，根据负载均衡策略，重新选择一个实例重试（可能选择到同一个实例）。
retryOnSame表示仍然使用上次失败的实例进行重试。
-
-**注意事项:**
-
- 1.并不是所有的异常都会触发重试。缺省的情况，只有网络异常，或者 503 错误码才会触发重试。 详细可以参考
`DefaultRetryExtensionsFactory` 的定义。
-
- 2.retry的场景下，对于同步调用,
同步调用的主线程已经被挂起，无法再主线程中进行重试，重试也不能在网络线程（event-loop）中进行，未被保护的阻塞操作会导致网络线程挂起，因此当前的重试机制会另起一个retry-pool-thread进行重试，因此如果业务在扩展`HttpClientFilter`的时候，如果涉及到通过ThreadLocal获取线程上下文的时候，会存在获取不到的情况，针对这种场景，建议在获取的时候做个判断处理，或者针对涉及ThreadLocal获取线程上下文的业务场景，建议采取通过扩展Handler的机制，进行处理，并保证扩展的Handler在loadbalance之前执行。
-
-
3.如果代码中引入了solution-basic依赖，重试默认开启，详细配置可以参考该依赖里面的[配置文件](https://github.com/apache/servicecomb-java-chassis/blob/master/solutions/solution-basic/src/main/resources/microservice.yaml)
。
-
## 自定义
负载均衡模块提供的功能已经非常强大，能够通过配置支持大部分应用场景。同时它也提供了强大的扩展能力，包括DiscoveryFilter、ServerListFilterExt、ExtensionsFactory（扩展IRule，RetryHandler等）。loadbalance模块本身包含了每一个扩展的实现，这里不再详细描述如何扩展，只简单描述步骤。开发者可以自行下载ServiceComb源码进行参考。
diff --git a/java-chassis-reference/zh_CN/mkdocs.yml
b/java-chassis-reference/zh_CN/mkdocs.yml
index 1737a3c..9a4de66 100644
--- a/java-chassis-reference/zh_CN/mkdocs.yml
+++ b/java-chassis-reference/zh_CN/mkdocs.yml
@@ -33,7 +33,7 @@ nav:
- 灰度发布: references-handlers/router.md
- 故障注入: references-handlers/fault-injection.md
- 隔离熔断容错: references-handlers/bizkeeper.md
- - 基于动态配置的流量特征治理: references-handlers/governance.md
+ - 流量特征治理: references-handlers/governance.md
- 快速失败和重试: references-handlers/fail-retry.md
- 网关功能参考:
- 介绍: edge/open-service.md
