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 4aa7513  [SCB-1819]add bizkeeper module documents to handlers and fix 
some problems
4aa7513 is described below

commit 4aa75138a3c81685b7054c1435730c84a35adc54
Author: liubao <bi...@qq.com>
AuthorDate: Tue Mar 24 17:40:26 2020 +0800

    [SCB-1819]add bizkeeper module documents to handlers and fix some problems
---
 .../zh_CN/docs/build-consumer/catalog.md           |   1 -
 .../zh_CN/docs/build-consumer/circuit-breaker.md   |   9 --
 .../zh_CN/docs/build-provider/catalog.md           |   1 -
 .../configuration/downgrade-strategy.md            | 105 -----------------
 .../zh_CN/docs/build-provider/thread-pool.md       |  33 +++---
 .../zh_CN/docs/catalog/build-provider.md           |   1 -
 .../zh_CN/docs/references-handlers/bizkeeper.md    | 131 +++++++++++++++++++++
 .../zh_CN/docs/references-handlers/intruduction.md |  11 +-
 java-chassis-reference/zh_CN/mkdocs.yml            |   1 +
 9 files changed, 154 insertions(+), 139 deletions(-)

diff --git a/java-chassis-reference/zh_CN/docs/build-consumer/catalog.md 
b/java-chassis-reference/zh_CN/docs/build-consumer/catalog.md
index 0606821..9692ff9 100644
--- a/java-chassis-reference/zh_CN/docs/build-consumer/catalog.md
+++ b/java-chassis-reference/zh_CN/docs/build-consumer/catalog.md
@@ -6,7 +6,6 @@
 * [使用RPC方式开发服务消费者](develop-consumer-using-rpc.md)
 * [使用服务契约](with-contract.md)
 * 调用控制
-    * [熔断策略](circuit-breaker.md)
     * [限流策略](flow-control.md)
     * [故障注入](fault-injection.md)
 * [调用第三方REST服务](3rd-party-service-invoke.md)
\ No newline at end of file
diff --git 
a/java-chassis-reference/zh_CN/docs/build-consumer/circuit-breaker.md 
b/java-chassis-reference/zh_CN/docs/build-consumer/circuit-breaker.md
deleted file mode 100644
index 2ab51b0..0000000
--- a/java-chassis-reference/zh_CN/docs/build-consumer/circuit-breaker.md
+++ /dev/null
@@ -1,9 +0,0 @@
-# 熔断策略
-
-## 场景描述
-
-熔断策略是对ServiceComb熔断功能的设置,用户通过配置熔断策略可以指定在何种条件下ServiceComb框架将终止发送请求。
-
-## 配置说明
-
-熔断作为异常反应机制是降级策略的一部分,相关概念还有隔离和容错。三者的关系以及配置方式参见[降级策略](../build-provider/configuration/downgrade-strategy.md)。
\ No newline at end of file
diff --git a/java-chassis-reference/zh_CN/docs/build-provider/catalog.md 
b/java-chassis-reference/zh_CN/docs/build-provider/catalog.md
index 23c02bb..3892300 100644
--- a/java-chassis-reference/zh_CN/docs/build-provider/catalog.md
+++ b/java-chassis-reference/zh_CN/docs/build-provider/catalog.md
@@ -12,7 +12,6 @@
 * [线程池](thread-pool.md)
 * 服务配置 
     * [限流策略](configuration/ratelimite-strategy.md)
-    * [降级策略](configuration/downgrade-strategy.md)
     * [参数效验](configuration/parameter-validator.md)
     * [程序启动逻辑](bootup.md)
 * [Access Log配置](access-log-configuration.md)
\ No newline at end of file
diff --git 
a/java-chassis-reference/zh_CN/docs/build-provider/configuration/downgrade-strategy.md
 
b/java-chassis-reference/zh_CN/docs/build-provider/configuration/downgrade-strategy.md
deleted file mode 100644
index 1988341..0000000
--- 
a/java-chassis-reference/zh_CN/docs/build-provider/configuration/downgrade-strategy.md
+++ /dev/null
@@ -1,105 +0,0 @@
-## 概念阐述
-
-降级策略是当服务请求异常时,微服务所采用的异常处理策略。
-
-降级策略有三个相关的技术概念:“隔离”、“熔断”、“容错”:
-
-* “隔离”是一种异常检测机制,常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、同时并发请求个数等。
-* “熔断”是一种异常反应机制,“熔断”依赖于“隔离”。熔断通常基于错误率来实现。一般的设置参数包括统计请求的个数、错误率等。
-* “容错”是一种异常处理机制,“容错”依赖于“熔断”。熔断以后,会调用“容错”的方法。一般的设置参数包括调用容错方法的次数等。
-
-把这些概念联系起来:当"隔离"措施检测到N次请求中共有M次错误的时候,"熔断"不再发送后续请求,调用"容错"处理函数。这个技术上的定义,是和Netflix 
Hystrix一致的,通过这个定义,非常容易理解它提供的配置项,参考:[https://github.com/Netflix/Hystrix/wiki/Configuration](https://github.com/Netflix/Hystrix/wiki/Configuration)。当前ServiceComb提供两种容错方式,分别为返回null值和抛出异常。
-
-## 场景描述
-
-用户通过配置降级策略,可以设置微服务的异常处理策略。
-
-## 配置说明
-
-配置项支持对所有接口生效,或者对某个微服务的某个具体方法生效。
-
-### 配置项生效范围
-
-* 按照类型\(type\):配置项能够针对Provider, Consumer进行配置
-
-* 按照范围\(scope\):配置项能够针对MicroService进行配置, 也可以针对【x-schema-id + operationId】进行配置
-
-本章节如果没有特殊说明,所有的配置项都支持按照下面的格式进行配置:
-
-```
-servicecomb.[namespace].[type].[MicroServiceName].[接口名称].[property name]
-```
-
-type指Provider或者Consumser, 针对特定的微服务的配置,需要增加MicroServiceName, 
针对接口配置的,需要指定接口名称,接口名称由【x-schema-id + operationId】组成。
-
-隔离  
-配置可选配置项格式示例如下:
-
-```
-servicecomb.isolation.Consumer.timeout.enabled
-servicecomb.isolation.Consumer.DemoService.timeout.enabled
-servicecomb.isolation.Consumer.DemoService.hello.sayHello.timeout.enabled
-servicecomb.isolation.Provider.timeout.enabled
-servicecomb.isolation.Provider.DemoService.timeout.enabled
-servicecomb.isolation.Provider.DemoService.hello.sayHello.timeout.enabled
-```
-
-### 配置项列表
-
-注意:在下面的表格里面,全部省略MicroServiceName。未特殊说明,配置项都支持Provider和Consumer。
-
-例如:对于服务消费者,需要配置为:servicecomb.isolation.Consumer.timeout.enabled
-
-例如:对于服务提供者,需要配置为:servicecomb.isolation.Provider.timeout.enabled
-
-表1-1降级策略相关配置项说明
-
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| servicecomb.isolation.[type].timeout.enabled | FALSE | - | 否 | 是否启用超时检测 |  |
-| servicecomb.isolation.[type].timeoutInMilliseconds | 30000 | - | 否 | 超时时间阈值 
|  |
-| servicecomb.isolation.[type].maxConcurrentRequests | 10 | - | 否 | 最大并发数阈值 |  
|
-| servicecomb.circuitBreaker.[type].enabled | TRUE | - | 否 | 是否启用熔断措施 |  |
-| servicecomb.circuitBreaker.[type].forceOpen | FALSE | - | 否 | 不管失败次数,都进行熔断 | 
 |
-| servicecomb.circuitBreaker.[type].forceClosed | FALSE | - | 否 | 任何时候都不熔断 | 
当与forceOpen同时配置时,forceOpen优先。 |
-| servicecomb.circuitBreaker.[type].sleepWindowInMilliseconds | 15000 | - | 否 
| 熔断后,多长时间恢复 | 恢复后,会重新计算失败情况。注意:如果恢复后的调用立即失败,那么会立即重新进入熔断。 |
-| servicecomb.circuitBreaker.[type].requestVolumeThreshold | 20 | - | 否 | 
10s内统计错误发生次数阈值,超过阈值则触发熔断 | 
由于10秒还会被划分为10个1秒的统计周期,经过1s中后才会开始计算错误率,因此从调用开始至少经过1s,才会发生熔断。 |
-| servicecomb.circuitBreaker.[type].errorThresholdPercentage | 50 | - | 否 | 
错误率阈值,达到阈值则触发熔断 |  |
-| servicecomb.fallback.[type].enabled | TRUE | - | 否 | 是否启用出错后的故障处理措施 |  |
-| servicecomb.fallback.[type].maxConcurrentRequests | 10 | - | 否 | 
并发调用容错处理措施(servicecomb.fallbackpolicy.policy)的请求数,超过这个值则不再调用处理措施,直接返回异常 |  |
-| servicecomb.fallbackpolicy.[type].policy | throwexception | returnull \| 
throwexception | 否 | 出错后的处理策略 |  |
-
-> **小心**:  
-> 
谨慎使用servicecomb.isolation.timeout.enabled=true。因为系统处理链都是异步执行,中间处理链的返回,会导致后面处理链的逻辑处理效果丢失。尽可能将servicecomb.isolation.timeout.enabled保持默认值false,并且正确设置网络层超时时间servicecomb.request.timeout=30000。
-
-## 示例代码
-
-```yaml
-servicecomb:
-  handler:
-    chain:
-      Consumer:
-        default: bizkeeper-consumer
-  isolation:
-    Consumer:
-      timeout:
-        enabled: true
-      timeoutInMilliseconds: 30000
-  circuitBreaker:
-    Consumer:
-      enabled: true
-      sleepWindowInMilliseconds: 15000
-      requestVolumeThreshold: 20
-  fallback:
-    Consumer:
-      enabled: true
-  fallbackpolicy:
-    Consumer:
-      policy: throwexception
-```
-
-> **说明:**  
-> 
降级策略需要启用服务治理能力,对应的服务提供者的handler是`bizkeeper-provider`,服务消费者的handler是`bizkeeper-consumer`。
-
-
-
diff --git a/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md 
b/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md
index 209fdab..e9d1acd 100644
--- a/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md
+++ b/java-chassis-reference/zh_CN/docs/build-provider/thread-pool.md
@@ -1,30 +1,26 @@
 # 线程池
 
-## 说明
-线程池用于执行同步模式的业务逻辑。  
-网络收发及reactive模式的业务逻辑在Eventloop中执行,与线程池无关  
+线程池用于执行同步模式的业务逻辑,网络收发及reactive模式的业务逻辑在 event-loop 中执行,与线程池无关。 默认情况下,  Consumer 
和 Provider 的
+业务逻辑代码的执行都是在线程池里面, Edge Service 的业务逻辑执行在 event-loop 里面。 
 
-默认所有同步方法都在一个全局内置线程池中执行  
-如果业务有特殊的需求,可以指定使用自定义的全局线程池,并且可以根据schemaId或operationId指定各自使用独立的线程池,实现隔离仓的效果  
+Java Chassis 提供了一个全局的内置线程池, 如果业务有特殊的需求,可以指定使用自定义的全局线程池,并且可以根
+据 schemaId 或 operationId 指定各自使用独立的线程池,实现隔离仓的效果。   
 
 ## 定制线程池
+
 * 实现线程池  
-  下面的方法任选其一即可
-  * 实现`java.util.concurrent.Executor`接口  
-    为了支持优雅退出,如果内部线程未设置为daemon线程,则还需要实现`java.io.Closeable`接口,负责销毁线程池
-  * 实现`java.util.concurrent.ExecutorService`接口
-* 将实现的线程池声明为spring bean
+    下面的方法任选其一即可
+    * 实现`java.util.concurrent.Executor`接口, 
为了支持优雅退出,如果内部线程未设置为daemon线程,则还需要实现`java.io.Closeable`接口,负责销毁线程池
+    * 实现`java.util.concurrent.ExecutorService`接口
+* 将实现的线程池声明为 spring bean
 * 启用线程池  
   假设新线程池bean id为custom-executor
-  * 替换全局线程池  
-    servicecomb.executors.default: custom-executor
-  * 指定schema专用的线程池  
-    servicecomb.executors.Provider.${schemaId}: custom-executor
-  * 指定operation专用的线程池  
-    servicecomb.executors.Provider.${schemaId}.${operationId}: custom-executor
-  
-
+  * 替换全局线程池:`servicecomb.executors.default: custom-executor`
+  * 指定schema专用的线程池: `servicecomb.executors.Provider.${schemaId}: 
custom-executor`
+  * 指定operation专用的线程池: 
`servicecomb.executors.Provider.${schemaId}.${operationId}: custom-executor`
+ 
 ## ServiceComb内置线程池
+
 
一般的线程池都是所有线程共享一个任务队列,在这种情况下,所有网络线程需要向同一个队列申请请求入队,线程池中的所有线程需要从同一个队列中抢任务执行,对于高吞吐的场景,这会导致竞争冲突,形成性能瓶颈
  
 所以,为了提升性能,ServiceComb内置线程池实际是真正线程池的包装,允许在其内部配置多组线程池,且每个网络线程绑定一组线程池,以减小竞争冲突  
 ![](../assets/producer-default-executor.png)
@@ -36,6 +32,7 @@
 | servicecomb.executor.default.group               | 2            | 创建几组线程池    
     |
 | servicecomb.executor.default.thread-per-group    | CPU数        | 每组线程池的线程数   
  |
 
+
 * 大于等于1.2.0的版本
 
 | 配置项                                              | 默认值            | 含义       
                                                               |
diff --git a/java-chassis-reference/zh_CN/docs/catalog/build-provider.md 
b/java-chassis-reference/zh_CN/docs/catalog/build-provider.md
index af48c07..156ec0a 100644
--- a/java-chassis-reference/zh_CN/docs/catalog/build-provider.md
+++ b/java-chassis-reference/zh_CN/docs/catalog/build-provider.md
@@ -36,6 +36,5 @@
 
 • [负载均衡策略](/build-provider/configuration/lb-strategy.html)  
 • [限流策略](/build-provider/configuration/ratelimite-strategy.html)  
-• [降级策略](/build-provider/configuration/downgrade-strategy.html)  
 • [参数教研](/build-provider/configuration/parameter-validator.html)  
 
diff --git a/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md 
b/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md
new file mode 100644
index 0000000..a0d174a
--- /dev/null
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md
@@ -0,0 +1,131 @@
+# 隔离熔断容错
+
+bizkeeper 模块集成了 
[Hystrix](https://github.com/Netflix/Hystrix/wiki/Configuration) , 
提供隔离、熔断和容错等服务故障保护能力。 Java
+Chassis 对 Hystrix 进行了封装, 只需要进行简单的配置即可启用这些功能。 
+
+在项目中引入如下 Handler 模块, 
+
+```xml
+ <dependency>
+  <groupId>org.apache.servicecomb</groupId>
+  <artifactId>handler-bizkeeper</artifactId>
+  </dependency>
+```
+
+并且增加 Handler 配置:
+
+```yaml
+servicecomb:
+  handler:
+    chain:
+      Consumer:
+        default: bizkeeper-consumer
+      Provider:
+        default: bizkeeper-provider
+```
+
+** 注意事项: **
+
+在实际微服务运维实践中,发现 Hystrix 存在如下一些问题, 开发者可以结合实际业务情况,谨慎的使用这个模块。 Java Chassis 的
+[负载均衡](loadbalance.md) 也提供了实例隔离和错误重试能力, 
加上内置的[线程池隔离](../build-provider/thread-pool.md), 能够
+实现大部分 Hystrix 核心治理能力。 
+
+* 调用栈很深,在某些异常情况下,可能屏蔽底层异常,导致问题原因分析困难。
+* 超时机制、重试机制和线程池隔离机制和 Java Chassis 的一些内部机制的协作存在一些不友好的情况,需要特别注意合理的开启超时和重试。 
默认情况下是禁用的。Java Chassis 只能使用信号量隔离机制。
+* Hystrix 的引入对性能影响很大, 会有 20% 以上的框架性能损失。    
+* Hystrix 项目目前已经停止维护。 
+
+## 概念阐述
+
+服务故障保护指服务请求异常时,微服务所采用的异常处理策略, 根据处理机制和效果把它分解为三个技术概念:“隔离”、“熔断”、“容错”:
+
+* “隔离”是一种异常检测机制,常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、同时并发请求个数等。
+* “熔断”是一种异常反应机制,“熔断”依赖于“隔离”。熔断通常基于错误率来实现。一般的设置参数包括统计请求的个数、错误率等。
+* “容错”是一种异常处理机制,“容错”依赖于“熔断”。熔断以后,会调用“容错”的方法。一般的设置参数包括调用容错方法的次数等。
+
+当前 ServiceComb 提供两种容错方式,分别为返回 null 值和抛出异常。
+
+*** 注意 : *** 在不同的上下文,“隔离”、“熔断”、“容错”、“降级” 等概念可能存在不一样的含义,发现这里的定义和其他地方存在不一样的
+的时候不用感到意外, 但是不用担心, 当服务出现故障的时候, 需要一定的措施进行应对, 对于措施和应对方式的理解胜于对于名词的理解。
+
+## 配置说明
+
+配置项支持对所有接口生效,或者对某个微服务的某个具体方法生效。
+
+* 配置项生效范围
+    * 按照类型\(type\):配置项能够针对Provider, Consumer进行配置
+    * 按照范围\(scope\):配置项能够针对 MicroService 进行配置, 也可以针对 `schemaId` 和 
`operationId` 进行配置
+
+本章节如果没有特殊说明,所有的配置项都支持按照下面的格式进行配置:
+
+```
+servicecomb.[namespace].[type].[scope].[property name]
+```
+
+type 指 Provider 或者 Consumser。 scope 指配置项生效范围, 针对特定的微服务的配置,需要增加 
MicroServiceName, 针对接口配置的,需要指定接口名称,接口名
+称由 `schemaId` 和 `operationId` 组成。
+
+下面是一些配置示例:
+
+```
+servicecomb.isolation.Consumer.timeout.enabled
+servicecomb.isolation.Consumer.DemoService.timeout.enabled
+servicecomb.isolation.Consumer.DemoService.hello.sayHello.timeout.enabled
+servicecomb.isolation.Provider.timeout.enabled
+servicecomb.isolation.Provider.DemoService.timeout.enabled
+servicecomb.isolation.Provider.DemoService.hello.sayHello.timeout.enabled
+```
+
+* 配置项列表
+
+| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
+| :--- | :--- | :--- | :--- | :--- | :--- |
+| servicecomb.isolation.[type].[scope].timeout.enabled | FALSE | - | 否 | 
是否启用超时检测 |  |
+| servicecomb.isolation.[type].[scope].timeoutInMilliseconds | 30000 | - | 否 | 
超时时间阈值 |  |
+| servicecomb.isolation.[type].[scope].maxConcurrentRequests | 10 | - | 否 | 
最大并发数阈值 |  |
+| servicecomb.circuitBreaker.[type].[scope].enabled | TRUE | - | 否 | 是否启用熔断措施 
|  |
+| servicecomb.circuitBreaker.[type].[scope].forceOpen | FALSE | - | 否 | 
不管失败次数,都进行熔断 |  |
+| servicecomb.circuitBreaker.[type].[scope].forceClosed | FALSE | - | 否 | 
任何时候都不熔断 | 当与forceOpen同时配置时,forceOpen优先。 |
+| servicecomb.circuitBreaker.[type].[scope].sleepWindowInMilliseconds | 15000 
| - | 否 | 熔断后,多长时间恢复 | 恢复后,会重新计算失败情况。注意:如果恢复后的调用立即失败,那么会立即重新进入熔断。 |
+| servicecomb.circuitBreaker.[type].[scope].requestVolumeThreshold | 20 | - | 
否 | 10s内统计错误发生次数阈值,超过阈值则触发熔断 | 
由于10秒还会被划分为10个1秒的统计周期,经过1s中后才会开始计算错误率,因此从调用开始至少经过1s,才会发生熔断。 |
+| servicecomb.circuitBreaker.[type].[scope].errorThresholdPercentage | 50 | - 
| 否 | 错误率阈值,达到阈值则触发熔断 |  |
+| servicecomb.fallback.[type].[scope].enabled | TRUE | - | 否 | 是否启用出错后的故障处理措施 
|  |
+| servicecomb.fallback.[type].[scope].maxConcurrentRequests | 10 | - | 否 | 
并发调用容错处理措施(servicecomb.fallbackpolicy.policy)的请求数,超过这个值则不再调用处理措施,直接返回异常 |  |
+| servicecomb.fallbackpolicy.[type].[scope].policy | throwexception | 
returnull \| throwexception | 否 | 出错后的处理策略 |  |
+
+**小心**:谨慎使用 `servicecomb.isolation.timeout.enabled=true` 
。因为系统处理链都是异步执行,中间处理链的返回,会导致
+后面处理链的逻辑处理效果丢失。尽可能将 `servicecomb.isolation.timeout.enabled` 
保持默认值false,并且正确设置网络层超时时
+间 `servicecomb.request.timeout=30000` 。
+
+
+* 示例代码
+
+```yaml
+servicecomb:
+  handler:
+    chain:
+      Consumer:
+        default: bizkeeper-consumer
+  isolation:
+    Consumer:
+      timeout:
+        enabled: true
+      timeoutInMilliseconds: 30000
+  circuitBreaker:
+    Consumer:
+      enabled: true
+      sleepWindowInMilliseconds: 15000
+      requestVolumeThreshold: 20
+  fallback:
+    Consumer:
+      enabled: true
+  fallbackpolicy:
+    Consumer:
+      policy: throwexception
+```
+
+> **说明:**  
+> 
降级策略需要启用服务治理能力,对应的服务提供者的handler是`bizkeeper-provider`,服务消费者的handler是`bizkeeper-consumer`。
+
+
+
diff --git 
a/java-chassis-reference/zh_CN/docs/references-handlers/intruduction.md 
b/java-chassis-reference/zh_CN/docs/references-handlers/intruduction.md
index ab80dea..4e6ba34 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/intruduction.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/intruduction.md
@@ -1,8 +1,9 @@
-## 处理链参考
+# 处理链参考
 
 
处理链(Handlers)是ServiceComb的核心组成部分,它们构成服务运行管控的基础。ServiceComb通过处理链来处理负载均衡、熔断容错、流量控制等。
 
-### 处理链配置
+## 处理链配置
+
 处理链分为Consumer和Provider,分别配置如下:
 
 ```yaml
@@ -15,7 +16,8 @@ servicecomb:
         default: qps-flowcontrol-provider
 ```
 
-通过名字配置处理链,可以根据需要调整处理链的顺序,配置在前面的处理链先执行。
+通过名字配置处理链,可以根据需要调整处理链的顺序,配置在前面的处理链先执行。不同的处理链可能存在一定的逻辑关联,处理链的顺序
+不同,程序运行的效果会存在差异。
 
 上述配置指定目标微服务缺省处理链,开发者还可以对特定的微服务配置不同的处理链,比如:
 
@@ -31,7 +33,8 @@ servicecomb:
 
 对于转发到authentication-server的请求,不经过auth处理链,转发到其他的微服务的请求,则经过auth处理链。
 
-### 开发处理链
+## 开发新的处理链
+
 
开发者自定义处理链包含如下几个步骤。由于ServiceComb的核心组成就是处理链,开发者可以参考handlers目录的实现详细了解处理链。下面简单总结下几个关键步骤:
 
 * 实现Handler接口
diff --git a/java-chassis-reference/zh_CN/mkdocs.yml 
b/java-chassis-reference/zh_CN/mkdocs.yml
index ffedb6f..18fc09a 100644
--- a/java-chassis-reference/zh_CN/mkdocs.yml
+++ b/java-chassis-reference/zh_CN/mkdocs.yml
@@ -36,6 +36,7 @@ nav:
 - 处理链参考: 
     - 处理链介绍: references-handlers/intruduction.md
     - 负载均衡: references-handlers/loadbalance.md
+    - 隔离熔断容错: references-handlers/bizkeeper.md
     - 公钥认证: references-handlers/publickey.md
 - 常用配置项参考:
     - REST Transport Client 配置项: config-reference/rest-transport-client.md

Reply via email to