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 2018/08/22 03:39:55 UTC
[incubator-servicecomb-docs] branch master updated (a376c20 ->
2562a98)
This is an automated email from the ASF dual-hosted git repository.
liubao pushed a change to branch master
in repository https://gitbox.apache.org/repos/asf/incubator-servicecomb-docs.git.
from a376c20 correct web-container.md and standalone.md translate issue
new 71beec5 translate java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md
new 8abb342 translate java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md
new 2562a98 translate java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md
The 3 revisions listed above as "new" are entirely new to this
repository and will be described in separate emails. The revisions
listed as "add" were already present in the repository and have only
been added to this reference.
Summary of changes:
.../configuration/downgrade-strategy.md | 101 +++++++--------------
.../build-provider/configuration/lb-strategy.md | 76 +++++++---------
.../configuration/ratelimite-strategy.md | 86 +++++++++---------
3 files changed, 113 insertions(+), 150 deletions(-)
[incubator-servicecomb-docs] 02/03: translate
java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit 8abb3429514455ae12bf1f880c1582baecc37edc
Author: DeanLee <li...@huawei.com>
AuthorDate: Tue Aug 21 15:52:44 2018 +0800
translate java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md
---
.../build-provider/configuration/lb-strategy.md | 76 ++++++++++------------
1 file changed, 35 insertions(+), 41 deletions(-)
diff --git a/java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md b/java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md
index 9028584..64668c5 100644
--- a/java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md
+++ b/java-chassis-reference/en_US/build-provider/configuration/lb-strategy.md
@@ -1,35 +1,34 @@
-## 场景描述
+## Load Balancing Policy
+### Scenario
-ServiceComb提供了基于Ribbon的负载均衡方案，用户可以通过配置文件配置负载均衡策略，当前支持随机、顺序、基于响应时间的权值等多种负载均衡路由策略。
+ ServiceComb provides a Ribbon-based load balancing solution. You can configure a load balancing policy in the configuration file. Currently, a load balancing routing policy can be random, sequential, or based on response time weight.
-## 配置说明
+### Configuration
-负载均衡策略在mocroservice.yaml文件中配置，配置项为`servicecomb.loadbalance.[MicroServiceName].[property name]`，其中若省略MicroServiceName，则为全局配置；若指定MicroServiceName，则为针对特定微服务的配置。
+ Load balancing policies are configured by setting the parameter `servicecomb.loadbalance.[MicroServiceName].[property name]` in the microservice.yaml fiel. If MicroServiceName is not set, the configuration is set for all microservices. Otherwise, the configuration is set for a specific microservice.
-表1-1配置项说明
+ **Table 1 Configuration items of load balancing policy**
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| servicecomb.loadbalance.\[服务名\].strategy.name | RoundRobin | RoundRobin（轮询）<br/>Random（随机）<br/>WeightedResponse（服务器响应时间权值）<br/>SessionStickiness（会话保持） | 否 | 负载均衡路由策略 | - |
-| servicecomb.loadbalance.\[服务名\].SessionStickinessRule.sessionTimeoutInSeconds | 30 | Integer | 否 | 客户端闲置时间，超过限制后选择后面的服务器。 | - |
-| servicecomb.loadbalance.\[服务名\].SessionStickinessRule.successiveFailedTimes | 5 | Integer | 否 | 客户端失败次数，超过后会切换服务器 | - |
-| servicecomb.loadbalance.\[服务名\].retryEnabled | FALSE | Boolean | 否 | 负载均衡捕获到服务调用异常，是否进行重试 | - |
-| servicecomb.loadbalance.\[服务名\].retryOnNext | 0 | Integer | 否 | 尝试新的服务器的次数 | - |
-| servicecomb.loadbalance.\[服务名\].retryOnSame | 0 | Integer | 否 | 同一个服务器尝试的次数 | - |
-| servicecomb.loadbalance.\[服务名\].isolation.enabled | FALSE | Boolean | 否 | 是否开启故障实例隔离功能 | - |
-| servicecomb.loadbalance.\[服务名\].isolation.enableRequestThreshold | 20 | Integer | 否 | 当实例的调用总次数达到该值时开始进入隔离逻辑门槛 | - |
-| servicecomb.loadbalance.\[服务名\].isolation.continuousFailureThreshold | - | Integer | 否 | 当请求实例连续出错达到此阈值时触发实例隔离 | 若配置了此项则覆盖实例故障百分比的配置，否则按照实例故障百分比触发隔离。<br/>由于按请求错误率触发实例隔离在请求次数较多时不易触发也不易恢复，因此建议使用此配置项代替实例故障百分比配置。<br/>请求实例成功时会将连续错误次数请零以保证实例快速恢复。 |
-| servicecomb.loadbalance.\[服务名\].isolation.errorThresholdPercentage | 20 | Integer，区间为\(0,100\] | 否 | 实例故障隔离错误百分比 | - |
-| servicecomb.loadbalance.\[服务名\].isolation.singleTestTime | 10000 | Integer | 否 | 故障实例单点测试时间 | 单位为ms |
+| Configuration Items | Default Value | Value Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :--------------------------------------- | :--------------------------------------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| servicecomb.loadbalance.NFLoadBalancerRuleClassName | com.netflix.loadbalancer.RoundRobinRule | com.netflix.loadbalancer.RoundRobinRule（polling）com.netflix.loadbalancer.RandomRule（random）com.netflix.loadbalancer.WeightedResponseTimeRule（server response time weight）org.apache.servicecomb.loadbalance.SessionStickinessRule（session stickiness） | No | Specifiles the load balancing policy | - |
+| servicecomb.loadbalance.SessionStickinessRule.sessionTimeoutInSeconds | 30 | Integer | No | Specifies the idle time of a client. If the idle time exceeds the set value, ServiceComb will select another server. | Currently, this parameter cannot be set for a certain microservice. For example, servicecomb.loadbalance.SessionStickinessRule.sessionTimeoutInSeconds cannot be set to servicecomb.loadbalance.DemoServi [...]
+| servicecomb.loadbalance.SessionStickinessRule.successiveFailedTimes | 5 | Integer | No | Specifies the number of failed requests from the client. If the number exceeds the set value, ServiceComb will switch to another server | Currently, this parameter cannot be set for a certain microservice. |
+| servicecomb.loadbalance.retryEnabled | FALSE | Boolean | No | Specifies whether to call a service again when a exception is captured by the load balance. | - |
+| servicecomb.loadbalance.retryOnNext | 0 | Integer | No | Specifies the number of attempts to connect to another server. | - |
+| servicecomb.loadbalance.retryOnSame | 0 | Integer | No | Specifies the number of attempts to connect to the same server. | - |
+| servicecomb.loadbalance.isolation.enabled | FALSE | Boolean | No | Specifies whether to enable faulty instance isolation. | - |
+| servicecomb.loadbalance.isolation.enableRequestThreshold | 20 | Integer | No | Specifies the threshold number of instance calls. If this value is reached, isolation is enabled. | - |
+| servicecomb.loadbalance.isolation.errorThresholdPercentage | 20 | Integer，\(0,100\] | No | Specifies the error percentage. Instance fault isolation is enabled when the set value is reached. | - |
+| servicecomb.loadbalance.isolation.singleTestTime | 10000 | Integer | No | Specifies the duration of a faulty instance test on a single node. | This unit is ms. |
+| servicecomb.loadbalance.transactionControl.policy | org.apache.servicecomb.loadbalance.filter.SimpleTransactionControlFilter | - | No | Specifies the offload policies for dynamic routing. | The framework provides simple offload mechanisms. You can also customize offload policies. |
+| servicecomb.loadbalance.transactionControl.options | - | key/value pairs | No | Specifies the parameter configured for the SimpleTransactionControlFilter offload policy. You can add any filtration tag for this item. | - |
-**说明**：
-- 以上配置项都支持全局和微服务两个粒度的配置。例如：servicecomb.loadbalance.strategy.name是全局的负载均衡路由策略；servicecomb.loadbalance.DemoService.strategy.name是仅在调用DemoService服务时生效的负载均衡路由策略。
+### Sample Code
-## 示例代码
+ in the src/main/resources/microservice.yaml file, configure a load balancing policy.
-负载均衡策略配置在src\main\resources\microservice.yaml文件中。
-
-配置处理链：
+ Configure a processing link：
```yaml
servicecomb:
@@ -38,33 +37,28 @@ servicecomb:
chain:
Consumer:
default: loadbalance
+ # other configurations omitted
```
-增加路由策略：
+ Add a routing policy:
```yaml
-servicecomb:
+servicecomb：
# other configurations omitted
loadbalance:
- strategy:
- name: RoundRobin
+ NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RoundRobinRule
+ # other configurations omitted
```
-## 自定义路由策略
+## Customizing Routing Policies
-用户可以在ServiceComb提供的路由策略框架下根据业务需要，通过编程的方式来开发路由策略。实施步骤如下：
+ Based on the routing policy framework provided by ServiceComb, you can program to customize routing policies as required. Perform the following steps:
-* 实现接口`com.netflix.loadbalancer.IRule`中定义的接口方法。
- 路由选择逻辑在`public Server choose(Object key)`方法中实现。LoadBalancerStats是一个封装了负载均衡器当前运行状态的一个结构。通过获取stats中各个实例的运行指标，在choose方法中，判定将当前请求路由到哪个实例上进行处理。处理风格可以参照`org.apache.servicecomb.loadbalance.SessionStickinessRule`。
-* 定义一个负载均衡规则工厂类，实现接口`ExtensionsFactory`。<br/>
-其中，`boolean isSupport(String key, String value)`方法用于确定此工厂是否支持microservice.yaml文件中配置的规则（key值为`Configuration.PROP_RULE_STRATEGY_NAME`，value值为自定义的规则名称）；`IRule createLoadBalancerRule(String ruleName)`方法用于获取对应的规则。具体实现方式参考`org.apache.servicecomb.loadbalance.RuleNameExtentionsFactory`，该实现类需要打上`@Component`注解以保证能够被引用。
-* 通过SDK配置该负载均衡策略，假如是`AbcRule`。则配置如下：<br/>
-```yaml
- servicecomb:
- loadbalance:
- strategy:
- name: AbcRule
-```
+* Encode using the API method defined in the `com.netflix.loadbalancer.IRule` API. Encode in the public Server choose(Object key) method. LoadBalancerStats is a structure that encapsulates the running state of the load balancer. Determine on which instance the current routing request will be processed based on the running indexes of each instance by using the Server choose(Object key) method. Use method `org.apache.servicecomb.loadbalance.SessionStickinessRule`for instance processing.
+
+* Compile the developed policy and ensure that the generated class is under classpath.
+
+* Use the software development kit(SDK) to configure the routing policy. Use AbcRule as a routing policy example. The configuration is as follows: `servicecomb.loadbalance.NFLoadBalancerRuleClassName=org.apache.servicecomb.ribbon.rule.AbcRule`
## 过滤器机制
[incubator-servicecomb-docs] 03/03: translate
java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit 2562a9871303ccbf6478eef7cfd52b9548a4d862
Author: DeanLee <li...@huawei.com>
AuthorDate: Tue Aug 21 15:52:59 2018 +0800
translate java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md
---
.../configuration/ratelimite-strategy.md | 86 +++++++++++-----------
1 file changed, 45 insertions(+), 41 deletions(-)
diff --git a/java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md b/java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md
index 5d4dca5..067ccc8 100644
--- a/java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md
+++ b/java-chassis-reference/en_US/build-provider/configuration/ratelimite-strategy.md
@@ -1,41 +1,45 @@
-## 场景描述
-
-用户在provider端使用限流策略，可以限制指定微服务向其发送请求的频率，达到限制每秒钟最大请求数量的效果。
-
-## 注意事项
-
-1. 限流策略的控制并不是绝对精确的，可能会有少量误差。
-2. provider端的流量控制是业务层面的功能，不是安全意义上的流量控制，如需防止DDoS攻击，需要结合其他的一系列措施。
-3. 流量控制是微服务级的，不是实例级的。例如一个consumer服务有三个实例，当对它们依赖的provider实例配置限流策略后，provider不会区分consumer的请求具体是由哪个实例发出的，而是汇总成微服务级的统计数据进行限流判断。
-
-## 配置说明
-
-限流策略配置在microservice.yaml文件中，相关配置项见表**QPS流控配置项说明**。要开启服务提供者端的限流策略，还需要在处理链中配置服务端限流handler，并添加pom依赖。
-
-* microservice.yaml配置示例如下：
- ```yaml
- servicecomb:
- handler:
- chain:
- Provider:
- default: qps-flowcontrol-provider
- ```
-* 添加handler-flowcontrol-qps的pom依赖：
- ```xml
- <dependency>
- <groupId>org.apache.servicecomb</groupId>
- <artifactId>handler-flowcontrol-qps</artifactId>
- <version>1.0.0.B003</version>
- </dependency>
- ```
-
-**QPS流控配置项说明**
-
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| servicecomb.flowcontrol.Provider.qps.enabled | true | true/false | 否 | 是否启用Provider流控 | - |
-| servicecomb.flowcontrol.Provider.qps.limit.\[ServiceName\].\[Schema\].\[operation\] | 2147483647（max int） | \(0,2147483647\]，整形 | 否 | 每秒钟允许的请求数 | 支持microservice/schema/operation三个级别的配置，后者的优先级高于前者 |
-| servicecomb.flowcontrol.Provider.qps.global.limit | 2147483647（max int） | \(0,2147483647\]，整形 | 否 | provider接受请求流量的全局配置 | 没有具体的流控配置时，此配置生效 |
-
-> **注意：**
-> provider端限流策略配置中的`ServiceName`指的是调用该provider的consumer，而`shema`、`operation`指的是provider自身的。即provider端限流配置的含义是，限制指定consumer调用本provider的某个schema、operation的流量。
+
+## Rate Limiting Policy
+### Scenario
+
+Users at the provider end can use the rate limiting policy to limit the maximum number of requests sent from a specified microservice per second.
+
+### Precautions
+
+1. There may be a small different between the rate limit and actual traffic.
+2. The rate limit function at the provider end is for service rather than security purpose. To prevent distributed denial of service(DDos) attacks, you need to take other measures.
+3. Traffic control is a microservice-level rather than process-level function.
+
+### Configuration
+
+ Rate limiting policies are configured in the microservice.yaml file. For related configuration items, see Table 2. To enable the rate limiting policy at the provider end, you also need to configure the rate limiting handler on the server in the processing chain and add dependencies in the pom.xml file.
+
+ An example of microservice.yaml file configuration is as follows,
+
+```yaml
+servicecomb:
+ handler:
+ chain:
+ Provider:
+ default: qps-flowcontrol-provider
+```
+
+ Add dependencies of handler-flowcontrol-qps in the pom.xml file,
+
+```xml
+<dependency>
+ <groupId>org.apache.servicecomb</groupId>
+ <artifactId>handler-flowcontrol-qps</artifactId>
+ <version>1.0.0-m1</version>
+</dependency>
+```
+
+ **Table2 Configuration items of the QPS rate limit**
+
+| Configuration Item | Default Value | Value Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :------------------ | :----------------------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| servicecomb.flowcontrol.Provider.qps.enabled | true | true/false | No | Specifies whether to enable traffic control at the provider end. | - |
+| servicecomb.flowcontrol.Provider.qps.limit.\[ServiceName\] | 2147483647（max int） | \(0,2147483647\]，Integer | No | Specifies the number of requests allowed per second. | This parameter can only be configured for microservice |
+| servicecomb.flowcontrol.Provider.qps.global.limit | 2147483647（max int） | (0,2147483647\]，Integer | No | Specifies the total number of requests allowed per second at the provider end | If no configuration is set for any specific microservices, this parameter takes effect |
+
+##
\ No newline at end of file
[incubator-servicecomb-docs] 01/03: translate
java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md
Posted by li...@apache.org.
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/incubator-servicecomb-docs.git
commit 71beec515a3be6068a90d2166b91d06c88cbd204
Author: DeanLee <li...@huawei.com>
AuthorDate: Tue Aug 21 15:52:27 2018 +0800
translate java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md
---
.../configuration/downgrade-strategy.md | 101 +++++++--------------
1 file changed, 33 insertions(+), 68 deletions(-)
diff --git a/java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md b/java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md
index 2a02d2f..9543646 100644
--- a/java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md
+++ b/java-chassis-reference/en_US/build-provider/configuration/downgrade-strategy.md
@@ -1,78 +1,46 @@
-## 概念阐述
+## Fallback Policy
-降级策略是当服务请求异常时，微服务所采用的异常处理策略。
+### Concept Description
-降级策略有三个相关的技术概念：“隔离”、“熔断”、“容错”：
+A fallback policy is used when a service request is abnormal.
-* “隔离”是一种异常检测机制，常用的检测方法是请求超时、流量过大等。一般的设置参数包括超时时间、同时并发请求个数等。
-* “熔断”是一种异常反应机制，“熔断”依赖于“隔离”。熔断通常基于错误率来实现。一般的设置参数包括统计请求的个数、错误率等。
-* “容错”是一种异常处理机制，“容错”依赖于“熔断”。熔断以后，会调用“容错”的方法。一般的设置参数包括调用容错方法的次数等。
+There are three key concepts in fallback: isolation, fallbreak, and fault tolerance:
-把这些概念联系起来：当"隔离"措施检测到N次请求中共有M次错误的时候，"熔断"不再发送后续请求，调用"容错"处理函数。这个技术上的定义，是和Netflix Hystrix一致的，通过这个定义，非常容易理解它提供的配置项，参考：[https://github.com/Netflix/Hystrix/wiki/Configuration](https://github.com/Netflix/Hystrix/wiki/Configuration)。当前ServiceComb提供两种容错方式，分别为返回null值和抛出异常。
+* Isolation is an exception detection mechanism. Two common items that need to be detected are timeout duration and the number of concurrent requests.
+* Fallbreak is an exception response mechanism, and it depends on isolation. Fallbreak is triggered based on the error rate. Two common items need to set are the number of requests to collect and error rate.
+* Fault tolerance is an exception handling mechanism that depends on fallbreak. Fault tolerance is called after a fallbreak. For fault tolerance, you need to set the number of fault tolerance call items.
-## 场景描述
+During fallback, if M(the threshold) errors are detected in N requests, the consumer will no longer send requests and the fault tolerance mechanism will be enabled. The preceding fallback process is accepted in Netflix Hystrix and helps you configure the parameters. Obtain information about the parameter configuration at [https://github.com/Netflix/Hystrix/wiki/Configuration](https://github.com/Netflix/Hystrix/wiki/Configuration). Currently, ServiceComb provides two types of fault toler [...]
-用户通过配置降级策略，可以设置微服务的异常处理策略。
+### Scenario
-## 配置说明
+By configuring a fallback policy, you can handler microservice exceptions.
-配置项支持对所有接口生效，或者对某个微服务的某个具体方法生效。
+### Configuration
-### 配置项生效范围
+ Configuration items of fallback policies are as follows:
-* 按照类型\(type\)：配置项能够针对Provider, Consumer进行配置
+ **Table 3 Configuration items of the fallback policy**
-* 按照范围\(scope\)：配置项能够针对MicroService进行配置, 也可以针对【x-schema-id + operationId】进行配置
+| Configuration Item | Default value | Value Range | Mandatory | Description | Remarks |
+| :--------------------------------------- | :------------- | :---------------------------- | :-------- | :--------------------------------------- | :--------------------------------------- |
+| servicecomb.isolation.timeout.enabled | FALSE | - | No | Specifies whether to enable timeout detection. | |
+| servicecomb.isolation.timeoutInMilliseconds | 30000 | - | No | Specifies the timeout duration threshold. | |
+| servicecomb.isolation.maxConcurrentRequests | 10 | - | No | Specifies the maximum number of concurrent requests. | |
+| servicecomb.circuitBreaker.enabled | TRUE | - | No | Specifies whether to enable fallbreak. | |
+| servicecomb.circuitBreaker.forceOpen | FALSE | - | No | Specifies that fallbreak is enable regardless of the number of failed requests or the error rate. | |
+| servicecomb.circuitBreaker.forceClosed | FALSE | - | No | Specifies that fallbreak can be implemented at any time. | If this parameter and servicecomb.circuitBreaker.forceOpen both need to be configured, servicecomb.circuitBreaker.forceOpen has priority. |
+| servicecomb.circuitBreaker.sleepWindowInMilliseconds | 15000 | - | No | Specifies the duration needed to recover from fallbreak. | After the recovery, the number of failed requests will be recalculated. Note: If the consumer fails to send a request to the provider after the recovery, fallbreak is enabled again. |
+| servicecomb.circuitBreaker.requestVolumeThreshold | 20 | - | No | Specifies the threshold of failed requests sent within 10 seconds. If the threshold is reached, fallbreak is triggered. | Ten seconds will be divided into ten 1 seconds, and the error rate is calculated 1 second later after an error occurred. Therefore, fallbreak can be implemented at least 1 second after the call. |
+| servicecomb.circuitBreaker.errorThresholdPercentage | 50 | - | No | Specifies the threshold of error rate. If the threshold is reached, fallbreak is triggered. | |
+| servicecomb.fallback.enabled | TRUE | - | No | Specifies whether to enable troubleshooting measures after an error occurred. | |
+| servicecomb.fallback.maxConcurrentRequests | 10 | - | No | Specifies the number of fault tolerance(servicecomb.fallbackpolicy.policy) requests concurrently called. If the value exceeds 10, the measures will no longer be called, and exception are returned. | |
+| servicecomb.fallbackpolicy.policy | throwexception | returnnulll \| throwexception | No | Specifies the error handling policies after an error occurred. | |
-本章节如果没有特殊说明，所有的配置项都支持按照下面的格式进行配置：
+**Caution:** Be cautious when setting servicecomb.isolation.timeout.enabled to TRUE, All processes are asynchronously processed in the system, and any error value returned by an intermediate process because the set timeout duration is reached can cause failure of the follow-up processes. Therefore, you are advised to keep the default value FALSE for servicecomb.isolation.timeout.enabled. For timeout duration from the network aspect, you are advised to set servicecomb.request.timeout=30000.
+{: .notice--warning}
-```
-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
-```
-
-### 配置项列表
-
-注意：在下面的表格里面，全部省略type和MicroServiceName。未特殊说明，配置项都支持Provider和Consumer。
-
-例如：对于服务消费者，需要配置为：servicecomb.isolation.Consumer.timeout.enabled
-
-例如：对于服务提供者，需要配置为：servicecomb.isolation.Provider.timeout.enabled
-
-表1-1降级策略相关配置项说明
-
-| 配置项 | 默认值 | 取值范围 | 是否必选 | 含义 | 注意 |
-| :--- | :--- | :--- | :--- | :--- | :--- |
-| servicecomb.isolation.timeout.enabled | FALSE | - | 否 | 是否启用超时检测 | |
-| servicecomb.isolation.timeoutInMilliseconds | 30000 | - | 否 | 超时时间阈值 | |
-| servicecomb.isolation.maxConcurrentRequests | 10 | - | 否 | 最大并发数阈值 | |
-| servicecomb.circuitBreaker.enabled | TRUE | - | 否 | 是否启用熔断措施 | |
-| servicecomb.circuitBreaker.forceOpen | FALSE | - | 否 | 不管失败次数，都进行熔断 | |
-| servicecomb.circuitBreaker.forceClosed | FALSE | - | 否 | 任何时候都不熔断 | 当与forceOpen同时配置时，forceOpen优先。 |
-| servicecomb.circuitBreaker.sleepWindowInMilliseconds | 15000 | - | 否 | 熔断后，多长时间恢复 | 恢复后，会重新计算失败情况。注意：如果恢复后的调用立即失败，那么会立即重新进入熔断。 |
-| servicecomb.circuitBreaker.requestVolumeThreshold | 20 | - | 否 | 10s内统计错误发生次数阈值，超过阈值则触发熔断 | 由于10秒还会被划分为10个1秒的统计周期，经过1s中后才会开始计算错误率，因此从调用开始至少经过1s，才会发生熔断。 |
-| servicecomb.circuitBreaker.errorThresholdPercentage | 50 | - | 否 | 错误率阈值，达到阈值则触发熔断 | |
-| servicecomb.fallback.enabled | TRUE | - | 否 | 是否启用出错后的故障处理措施 | |
-| servicecomb.fallback.maxConcurrentRequests | 10 | - | 否 | 并发调用容错处理措施（servicecomb.fallbackpolicy.policy）的请求数，超过这个值则不再调用处理措施，直接返回异常 | |
-| servicecomb.fallbackpolicy.policy | throwexception | lreturnnulllthrowexception | 否 | 出错后的处理策略 | |
-
-> **小心**：
-> 谨慎使用servicecomb.isolation.timeout.enabled=true。因为系统处理链都是异步执行，中间处理链的返回，会导致后面处理链的逻辑处理效果丢失。尽可能将servicecomb.isolation.timeout.enabled保持默认值false，并且正确设置网络层超时时间servicecomb.request.timeout=30000。
-
-## 示例代码
+## Sample Code
```yaml
servicecomb:
@@ -87,7 +55,6 @@ servicecomb:
timeoutInMilliseconds: 30000
circuitBreaker:
Consumer:
- enabled: true
sleepWindowInMilliseconds: 15000
requestVolumeThreshold: 20
fallback:
@@ -98,8 +65,6 @@ servicecomb:
policy: throwexception
```
-> **说明：**
-> 降级策略需要启用服务治理能力，对应的服务提供者的handler是`bizkeeper-provider`，服务消费者的handler是`bizkeeper-consumer`。
-
-
-
+> **NOTE:**
+>
+> You need to enable service governance for fallback, The provider handler is `bizkeeper-provider`, and the consumer handler is `bizkeeper-consumer`. If `Consumer:`/`Provider:` was omitted, your configuration would not work, and service governance would be enabled with default configuration.
\ No newline at end of file