You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by li...@apache.org on 2020/03/24 09:49:41 UTC
[servicecomb-docs] branch master updated: [SCB-1819]add bizkeeper
module documents to handlers and fix some problems
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内置线程池实际是真正线程池的包装，允许在其内部配置多组线程池，且每个网络线程绑定一组线程池，以减小竞争冲突
@@ -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