You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@servicecomb.apache.org by GitBox <gi...@apache.org> on 2018/09/16 13:50:52 UTC
[GitHub] WillemJiang closed pull request #64: Polish/configurations
WillemJiang closed pull request #64: Polish/configurations
URL: https://github.com/apache/incubator-servicecomb-docs/pull/64
This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:
As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):
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 9543646..d526788 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,44 +1,78 @@
-## Fallback Policy
+## Fallback
+### Concepts
-### Concept Description
+A fallback policy is applied when a service request is abnormal.
-A fallback policy is used when a service request is abnormal.
+There are three key concepts in fallback: isolation, circuit breaking, and fault tolerance:
-There are three key concepts in fallback: isolation, fallbreak, and fault tolerance:
+* **Isolation** is an exception detection mechanism. There are two common "exception"s: timeout and overload, which can be controlled by timeout duration and max concurrent requests.
+* **Circuit breaking** is an exception response mechanism which depends on isolation. Circuit breaking is triggered by the error rate, like the number of bad requests, or the rate of invalid calls.
+* **Fault tolerance** is an exception handling mechanism that depends on circuit breaking. Fault tolerance is called after a circuit breaking is triggered. Users can set the number of fault tolerance calls in the configuration.
-* 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 tolerance modes: returning null values and throwing exceptions.
+Let's combine the 3 concepts: the **isolation** mechanism detects there are M(the threshold) errors in N requests, the **circuit breaking** is triggered and make sure there are no more requests sent, and then **fault tolerance** method is called. Technically the concept definition is the same with Netflix Hystrix, making it easy to understand the config items(Reference: [Hystrix Configuration]([https://github.com/Netflix/Hystrix/wiki/Configuration](https://github.com/Netflix/Hystrix/wiki/Configuration))). ServiceComb provides 2 fault tolerance methods: returning null values and throwing exceptions.
### Scenario
-By configuring a fallback policy, you can handler microservice exceptions.
+Users configure a fallback policy to handle microservices' exceptions.
### Configuration
- Configuration items of fallback policies are as follows:
+Configuration items can be set to be applied to all APIs or a particular method of a microservice.
+
+### Configuration Scope
+
+- Configuration by type: items can be applied to Providers and Consumers
+- Configuration by scope: items can be applied to a specific microservice, or [x-schema-id+operationId]
+
+All the items in this chapter can be configured in the following format:
+
+```
+servicecomb.[namespace].[type].[MicroServiceName].[interface name].[property name]
+```
+
+The type can be Consumer or Provider. Specify the [MicroServiceName] to apply configuration to specific microservice. To make the configuration applied to API, we have to specify the API name in the format x-[schema-id+operationId]
+
+The possible Isolation config items are as follows:
+
+```
+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
+```
+
+
+
+### Configuration Items
+
+Tips: the items' type' field is omitted in the following table, while items can be applied to both Provider and Consumer.
+
+For Providers, the configuration item should be: servicecomb.isolation.Consumer.timeout.enabled
+
+For Consumers, the conriguration item should be servicecomb.isolation.Provider.timeout.enabled
+
+**Table 1-1 The fallback policy config items**
+
+| Configuration Item | Default value | Value Range | Required | Description | Tips |
+| :--------------------------------------------------- | :------------- | :---------------------------- | :------- | :----------------------------------------------------------- | :----------------------------------------------------------- |
+| servicecomb.isolation.timeout.enabled | FALSE | - | No | Enable timeout detection or not. | |
+| servicecomb.isolation.timeoutInMilliseconds | 30000 | - | No | The timeout duration threshold. | |
+| servicecomb.isolation.maxConcurrentRequests | 10 | - | No | The maximum number of concurrent requests. | |
+| servicecomb.circuitBreaker.enabled | TRUE | - | No | Enable circuit breaking or not. | |
+| servicecomb.circuitBreaker.forceOpen | FALSE | - | No | Force circuit breaker to be enabled regardless of the number of errors. | |
+| servicecomb.circuitBreaker.forceClosed | FALSE | - | No | Force circuit breaker to be disabled. | When forceOpen and forceClose are set at the same time, forceOpen will take effect. |
+| servicecomb.circuitBreaker.sleepWindowInMilliseconds | 15000 | - | No | How long to recover from a circuit breaking. | After the recovery, the number of failures will be reset. Note: If the call fails immediately after a recover, the circuit breaker is triggered immediately again. |
+| servicecomb.circuitBreaker.requestVolumeThreshold | 20 | - | No | The threshold of failed requests within 10 seconds. If the threshold is reached, circuit breaker is triggered. | The 10 seconds duration is splitted evenly into 10 segments for error calculation. The calculation will start after 1 second. So circuit breakers are triggered after at least 1 second. |
+| servicecomb.circuitBreaker.errorThresholdPercentage | 50 | - | No | The threshold of error rate. If the threshold is reached, circuit breaker is triggered. | |
+| servicecomb.fallback.enabled | TRUE | - | No | Enable fallback handling or not | |
+| servicecomb.fallback.maxConcurrentRequests | 10 | - | No | The max number of concurrent fallback(specified by servicecomb.fallbackpolicy.policy) calls. When the threshold is reached, the fallback method is not called by return exception directly. | |
+| servicecomb.fallbackpolicy.policy | throwexception | returnnulll \| throwexception | No | The fallback policy when errors occurred. | |
- **Table 3 Configuration items of the fallback policy**
+**Caution:** Be cautious to set servicecomb.isolation.timeout.enabled to true. All handlers in the handler chain are asynchronously executed, the intermediate handlers' return will make the follow-up handlers processing abandoned. Therefore, we recommend to set servicecomb.isolation.timeout.enabled to be false(by default) and set the network timeout duration servicecomb.request.timeout to 30000.
-| 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}
## Sample Code
@@ -67,4 +101,4 @@ servicecomb:
> **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
+> You need to enable service governance for fallback. The corresponding provider handler `bizkeeper-provider`, and the consumer handler is `bizkeeper-consumer`.
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 492039e..a215971 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 +1 @@
-The content of this page has been outdated, please refer to [Load Balancing](/references-handlers/loadbalance.md).
+The content of this page has been outdated, please refer to [Load Balancing](/java-chassis-reference/en_US/references-handlers/loadbalance.md)
diff --git a/java-chassis-reference/en_US/build-provider/configuration/parameter-validator.md b/java-chassis-reference/en_US/build-provider/configuration/parameter-validator.md
index 148ee16..9d13827 100644
--- a/java-chassis-reference/en_US/build-provider/configuration/parameter-validator.md
+++ b/java-chassis-reference/en_US/build-provider/configuration/parameter-validator.md
@@ -1,6 +1,6 @@
# Parameter Validation
## Scenario
-The user uses the parameter validation on the provider client, and can set the corresponding parameter input requirements in advance, and perform the effect processing before the interface is actually called to achieve the effect of the control parameter input standard.
+Users can set parameter validation rules in the provider's configuration. The rules will validate input parameters when provider APIs are called, so the parameters can be defined in a specific format.
## Configuration instructions
@@ -13,7 +13,7 @@ The user uses the parameter validation on the provider client, and can set the c
</dependency>
```
-* Add validator annotations to the code that requires validation according to the JSR 349 specification, such as @NotNull, @Min, @Max, etc.
+* Add validator annotations to the code that requires validation by the JSR 349 specification, such as @NotNull, @Min, @Max, etc.
## Sample Code
@@ -49,7 +49,7 @@ public class Validator {
* bean class validation
-You need to add @Valid in front of the incoming Student object, as shown in the figure above, sayHello\(@Valid Student student\).
+Add @Valid in front of the incoming Student object, like the method sayHello\(@Valid Student student\) shown above.
```java
public class Student {
@@ -78,15 +78,15 @@ public class Student {
```
## Custom return exception
-* The default parameter validation parameter ParameterValidator has implemented the interface ProducerInvokeExtension to handle the required parameter validation in accordance with the JSR 349 specification.
+* The default parameter validator ParameterValidator has implemented the interface ProducerInvokeExtension to handle the required parameter validation with the JSR 349 specification.
If any parameter validation fails, the default error is BAD\_REQUEST\(400, "Bad Request"\).
- Return error support for custom extensions, using the SPI mechanism.
+ Return error can be customized with the SPI mechanism.
-* You can customize the returned error information by implementing the interface ExceptionToResponseConverter, taking the ConstraintViolationExceptionToResponseConverter as an example.
+* Developer can customize the returned error information by implementing the interface ExceptionToResponseConverter, taking the ConstraintViolationExceptionToResponseConverter as an example.
- 1. Implement the ExceptionToResponseConverter interface, override the method, where the return result of the getOrder method indicates the priority of the validator. The smaller the value, the higher the priority.
+ 1. Implement the ExceptionToResponseConverter interface, override the method, the return value of the getOrder method indicates the priority of the validator. The smaller the value, the higher the priority.
```java
public class ConstraintViolationExceptionToResponseConverter
@@ -95,12 +95,12 @@ public class Student {
public Class<ConstraintViolationException> getExceptionClass() {
return ConstraintViolationException.class;
}
-
+
@Override
public Response convert(SwaggerInvocation swaggerInvocation, ConstraintViolationException e) {
return Response.createFail(new InvocationException(Status.BAD_REQUEST, e.getConstraintViolations().toString()));
}
-
+
@Override
public int getOrder() {
return -100;
@@ -108,6 +108,4 @@ public class Student {
}
```
- 2. Add a file in the services folder under META-INF, with the implementation interface x.x.x.ExceptionToResponseConverter\ (with package name\) as the name, and the concrete implementation class x.x.x.ConstraintViolationExceptionToResponseConverter\ (with package name\) as the content.
-
-
+ 2. Add a file in the services folder under META-INF, with the implemented interface x.x.x.ExceptionToResponseConverter(with package name\) as the name, and the implementation class x.x.x.ConstraintViolationExceptionToResponseConverter(with package name\) as the content.
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 067ccc8..25b39e5 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
@@ -2,19 +2,19 @@
## 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.
+Users can set the rate limiting policy in the provider's configuration. By setting the request frequency from a particular micro service, provider can limit the max number of requests per second.
-### Precautions
+### Cautions
-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.
+1. There may be a small difference between the rate limit and actual traffic.
+2. The provider's rate limit control is for service rather than security. To prevent distributed denial of service(DDos) attacks, you need to take other measures.
+3. Traffic control is scoped to microservice rather than instance. Consume a consumer microservice has 3 instances, and calls a provider service. After configuring the rate limit policy, the provider won't distinguish which consumer instance makes the request, but take all requests together as the 'consume request' for rate limiting.
### 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.
+Rate limiting policies are configured in the microservice.yaml file. The table below shows all the configuration items. To enable the provider's rate limit policy, you also need to configure the rate limiting handler in the server's handler chain and add dependencies in the pom.xml file.
- An example of microservice.yaml file configuration is as follows,
+- An example of rate limit configuration in microservice.yaml:
```yaml
servicecomb:
@@ -24,7 +24,7 @@ servicecomb:
default: qps-flowcontrol-provider
```
- Add dependencies of handler-flowcontrol-qps in the pom.xml file,
+- Add the handler-flowcontrol-qps dependency in the pom.xml file:
```xml
<dependency>
@@ -34,12 +34,14 @@ servicecomb:
</dependency>
```
- **Table2 Configuration items of the QPS rate limit**
+**QPS rate limit configuration items**
-| 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 |
+| Configuration Item | Default Value | Value Range | Required | Description | Remarks |
+| :--------------------------------------------------------- | :-------------------- | :------------------------ | :------- | :--------------------------------------------------- | :----------------------------------------------------------- |
+| servicecomb.flowcontrol.Provider.qps.enabled | true | true/false | No | Enable provider's traffic control or not | - |
+| servicecomb.flowcontrol.Provider.qps.limit.\[ServiceName\] | 2147483647（max int） | \(0,2147483647\]，Integer | No | Specifies the number of requests allowed per second. | This parameter can be configured to microservice/schema/operation, the latter has a higher priorty |
+| servicecomb.flowcontrol.Provider.qps.global.limit | 2147483647（max int） | (0,2147483647\]，Integer | No | Specifies the provider's total number of requests | If no configuration is set for any specific microservice, this parameter takes effect |
-##
\ No newline at end of file
+> **Notes:**
+>
+> The `ServiceName` in provider's rate limit config is the name of the consumer that calls the provider. While `schema` and `operation` is the provider's own config item. That is, the rate limit policy controls the consumer requests that call the provider's schema or operation.
\ No newline at end of file
diff --git a/java-chassis-reference/en_US/build-provider/service-configuration.md b/java-chassis-reference/en_US/build-provider/service-configuration.md
index 10e5815..4bbb52a 100644
--- a/java-chassis-reference/en_US/build-provider/service-configuration.md
+++ b/java-chassis-reference/en_US/build-provider/service-configuration.md
@@ -1,12 +1,11 @@
## [Load Balancing Policy](/build-provider/configuration/lb-strategy.html)
-• 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. [Service Center](https://github.com/apache/incubator-servicecomb-saga)
+• ServiceComb provides a Ribbon-based load balancing solution which can be configured through file. There are different routing policies including random, sequential, policy based on response time weight etc. [Service Center](https://github.com/apache/incubator-servicecomb-saga)
## [Rate Limiting Policy](/build-provider/configuration/ratelimite-strategy.html)
-• 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.
+• Users can set the rate limiting policy in the provider's configuration. By setting the request frequency from a particular micro service, provider can limit the max number of requests per second.
## [Fallback Policy](/build-provider/configuration/parameter-validator.html)
• A fallback policy is used when a service request is abnormal.
## [Parameter Validation](/build-provider/configuration/parameter-validator.html)
-• The user uses the parameter validation on the provider client, and can set the corresponding parameter input requirements in advance, and perform the effect processing before the interface is actually called to achieve the effect of the control parameter input standard.
-
+• Users can set parameter validation rules in the provider's configuration. The rules will validate input parameters when provider APIs are called, so the parameters can be defined in a specific format.
\ No newline at end of file
diff --git a/java-chassis-reference/en_US/references-handlers/loadbalance.md b/java-chassis-reference/en_US/references-handlers/loadbalance.md
index cfa8220..bdc6f7a 100644
--- a/java-chassis-reference/en_US/references-handlers/loadbalance.md
+++ b/java-chassis-reference/en_US/references-handlers/loadbalance.md
@@ -1,13 +1,13 @@
# load balancing
-## Scene Description
+## Scenario
-ServiceComb provides very powerful load balancing capabilities. Its core consists of two parts. The first part is DiscoveryTree. DiscoveryFilter is its main component by grouping microservice instances according to interface compatibility, data center, instance status, etc. The second part is based on Ribbon's load balancing scheme, which supports random. Various load balancing routing policies IRule, such as order, response time-based weights, and ServerListFilterExt that can support the Invocation state.
+ServiceComb provides very powerful load balancing capabilities, which consists of two core parts. The first part DiscoveryTree, whose core part is DiscoveryFilter, groups microservice instances by their interface compatibility, data center, status, etc. The second part is the load balancing scheme based on Ribbon, which supports various load balancing policies(IRule) include random, sequential, response time-based weights, and ServerListFilterExt which is based on Invocation state.
-DiscoveryTree's logic is more complex. You can understand its processing through the following process.
+DiscoveryTree's logic is more complex, its processing progress is as below:
-Load balancing is applied to the Consumer processing chain. The name is loadbalance. The examples are as follows:
+Load balancing can be configured in the Consumer processing chain, the handler name is loadbalance, as follows:
```
servicecomb:
@@ -25,7 +25,7 @@ POM dependence:
</dependency>
```
-## Routing and forwarding according to data center information
+## Routing and forwarding by data center information
Service providers and consumers can declare their service center information in microservice.yaml:
```yaml
servicecomb:
@@ -35,21 +35,21 @@ servicecomb:
availableZone: my-Zone
```
-Consumers compare their own data center information and provider information, preferentially forward the request to the same instance of region and availableZone; if it does not exist, it forwards to the same instance of the region; if it still does not exist, it forwards to other Example.
+Consumers compare their own data center information and providers' information, preferentially forward the request to the provider instance in the same region and availableZone; if the target instance is not available, it forwards request to the instance in the same region; if the target still does not exist, it forwards requests to other instances.
-The region and availableZone here are general concepts, and users can determine their business meanings to apply them to resource-isolated scenarios. See [Logical isolation relationships between microservice instances] (/build-provider/definition/isolate-relationship.md) for more isolation and isolation mechanisms.
+The region and availableZone here are general concepts, users can determine their business meanings to apply them to resource-isolated scenarios. See [Logical isolation relationships between microservice instances](/build-provider/definition/isolate-relationship.md) for more details of the isolation.
-This rule is enabled by default. If it is not needed, it can be closed by servicecomb.loadbalance.filter.zoneaware.enabled. Data center information isolation is implemented in ZoneAwareDiscoveryFilter.
+This rule is enabled by default. If it is not needed, set servicecomb.loadbalance.filter.zoneaware.enabled to false. Data center information isolation is implemented in ZoneAwareDiscoveryFilter.
-## Routing and forwarding based on instance attributes
-Microservices can specify the properties of an instance. Instance properties can be specified in microservice.yaml or modified through the API of the service center.
+## Routing and forwarding by instance attributes
+Users can specify the properties of microservice instances in microservice.yaml, or by calling service center APIs.
```
instance_description:
properties:
tag: mytag
```
-Consumers can specify to consume instances with certain attributes without accessing other instances.
+Consumers can specify provider instances' attributes to determine which instances to call.
```
servicecomb:
loadbalance:
@@ -58,14 +58,14 @@ servicecomb:
options:
tag: mytag
```
-The above configuration means that only instances with the tag attribute mytag in all instances of myservice are accessed.
+The above configuration shows that only myservice instances with the tag attribute mytag are called.
-This rule needs to be configured separately for each service. Unconfigured means that the rule is not enabled and global configuration for all services is not supported.
+This rule needs to be configured separately for each service. Global rule for all services is not supported.
-This rule is enabled by default. If it is not needed, it can be closed by servicecomb.loadbalance.filter.instanceProperty.enabled. The route forwarding function based on the instance attribute is implemented in InstancePropertyDiscoveryFilter.
+This rule is enabled by default, it can be disabled by setting servicecomb.loadbalance.filter.instanceProperty.enabled to false. The instance attributes based routing policy is implemented in InstancePropertyDiscoveryFilter.
## Instance isolation
-Developers can configure instance-isolated parameters to temporarily mask access to the wrong instance, improving system reliability and performance. Below are its configuration items and default values
+Developers can configure instance-isolated parameters to temporarily drop access to the wrong instance, improving system reliability and performance. Below are the configuration items and default values:
```
servicecomb:
loadbalance:
@@ -77,14 +77,21 @@ servicecomb:
continuousFailureThreshold: 2
```
-The statistical period of isolation is 1 minute. According to the above configuration, in 1 minute, if the total number of requests is greater than 5, and the [1] error rate is greater than 20% or [2] consecutive errors exceed 2 times, then the instance is isolated. The instance isolation time is 60 seconds. After 60 seconds, the instance will be tried (it needs to be determined according to the load balancing policy).
+The interval of isolation calculation is 1 minute. According to the above configuration, in 1 minute, if the total number of requests is greater than 5, and more than 2 consecutive errors occur, the instance is isolated.
-Note that ServiceComb starts a thread in the background to detect the instance state, and checks the instance state every 10 seconds (if the instance is accessed within 10 seconds, it is not detected). If the detection fails, each test will count the error. Plus 1. The count here also affects instance isolation.
+The default value of errorThresholdPercentage is 0, indicates that the rule is ommited. The item should be a integer less than 100, for example 20, then within 1 minutes, if the total number of request is greater than 5 and [1] error rate is greater than 20% or [2] more than 2 consecutive errors occur, is instance is isolated.
-The system default instance state detection mechanism is to send a telnet instruction, refer to the implementation of SimpleMicroserviceInstancePing. If the service needs to cover the status detection mechanism, you can complete the following two steps:
+After 60 seconds, the instance will be re-enabled and accessible if it matches the rules of load balancing policy.
+
+Notes:
+
+1. When error rate reaches the threshold, is instance is isolated and the error rate will be calculated again after the interval. Then with the successful accesses, the rate will decrease and become less than the threshold, then instance is available again. Since the rate is calculated by number of requests, if the total requests reaches the threshold and the error rate is much greater than its threshold, the instance would take a long time to recover.
+2. ServiceComb starts a thread in the background to detect the instance state, and checks the instance state every 10 seconds (if the instance is accessed within 10 seconds, it is not detected). If the detection fails, the error number is accumulated with 1. The count here also affects instance isolation.
+
+The default instance state detection mechanism is to send a telnet instruction, refer to the implementation of SimpleMicroserviceInstancePing. Users can overwrite the status detection mechanism with the following two steps:
1. Implement the MicroserviceInstancePing interface
-2. Configure SPI: Add META-INF/services/org.apache.servicecomb.serviceregistry.consumer.MicroserviceInstancePing, the full name of the implementation class
+2. Configure SPI: Add META-INF/services/org.apache.servicecomb.serviceregistry.consumer.MicroserviceInstancePing, the content is the full path of the implementation class
Developers can configure different isolation policies for different microservices. Just add a service name to the configuration item, for example:
```
@@ -99,9 +106,9 @@ servicecomb:
continuousFailureThreshold: 2
```
-This rule is enabled by default and can be turned off by servicecomb.loadbalance.filter.isolation.enabled if it is not needed. Data center information isolation is implemented in IsolationDiscoveryFilter.
+This rule is enabled by default and can be turned off by setting servicecomb.loadbalance.filter.isolation.enabled to false. Data center information isolation is implemented in IsolationDiscoveryFilter.
-## Configuring routing rules
+## Configuring route rules
Developers can specify load balancing policies through configuration items.
```
servicecomb:
@@ -110,7 +117,7 @@ servicecomb:
name: RoundRobin # Support RoundRobin,Random,WeightedResponse,SessionStickiness
```
-Developers can configure different policies for different microservices, add a service name to the configuration item, for example:
+Developers can configure policies for different microservices by adding a service name, for example:
```
servicecomb:
loadbalance:
@@ -119,7 +126,7 @@ servicecomb:
name: RoundRobin # Support RoundRobin,Random,WeightedResponse,SessionStickiness
```
-Each policy also has some proprietary configuration items that also support configuration for different microservices.
+Each policy has some specific configuration items.
* SessionStickiness
@@ -132,7 +139,7 @@ servicecomb:
```
## Set retry strategy
-The load balancing module also supports the policy of configuring failed retry.
+The load balancing module also supports the policy retry.
```
servicecomb:
loadbalance:
@@ -140,7 +147,7 @@ servicecomb:
retryOnNext: 0
retryOnSame: 0
```
-Retry is not enabled by default. It also supports setting special strategies for different services:
+Retry is not enabled by default. Developers can set different strategies for different services:
```
servicecomb:
loadbalance:
@@ -150,19 +157,19 @@ servicecomb:
retryOnSame: 0
```
-retryOnNext indicates that after the failure, according to the load balancing policy, re-select an instance to retry (may choose to the same instance). retryOnSame means that the last failed instance is still used for retry.
+retryOnNext indicates that after the failure, according to the load balancing policy, re-select an instance to retry (may choose the same instance), while retryOnSame means that the last failed instance is still used for retry.
## Customization
-The load balancing module provides powerful functions that can support most application scenarios through configuration. It also provides powerful extension capabilities, including DiscoveryFilter, ServerListFilterExt, ExtensionsFactory (extension IRule, RetryHandler, etc.). The loadbalance module itself contains the implementation of each extension. The extension is not described in detail here. The steps are described simply. Developers can download the ServiceComb source code for reference.
+The load balancing module provides various configurations that can support most application scenarios. It also provides flexible extension capabilities, including DiscoveryFilter, ServerListFilterExt, ExtensionsFactory (extension IRule, RetryHandler, etc.). The loadbalance module itself contains the implementation of each extension. The brief introduction of extending load balancing module is described below. Developers can download the ServiceComb source code to see the details.
* DiscoveryFilter
* Implement the DiscoveryFilter interface
- * Configure SPI: Add META-INF/services/org.apache.servicecomb.serviceregistry.discovery.DiscoveryFilter file with the full name of the implementation class
+ * Configure SPI: Add META-INF/services/org.apache.servicecomb.serviceregistry.discovery.DiscoveryFilter file with the full path of the implementation class
* ServerListFilterExt
* Implement the ServerListFilterExt interface
- * Configure SPI: Add META-INF/services/org.apache.servicecomb.loadbalance.ServerListFilterExt file, the content is the full name of the implementation class
- * Note: This development note applies to versions 1.0.0 and later. Earlier versions were developed differently.
+ * Configure SPI: Add META-INF/services/org.apache.servicecomb.loadbalance.ServerListFilterExt file, the content is the full pathof the implementation class
+ * Note: This instruction applies to version 1.0.0 and later. Earlier versions are extended in a different way.
* ExtensionsFactory
* Implement the ExtensionsFactory and publish it as a spring bean using @Component.
diff --git a/java-chassis-reference/zh_CN/build-provider/configuration/downgrade-strategy.md b/java-chassis-reference/zh_CN/build-provider/configuration/downgrade-strategy.md
index 2a02d2f..65d851d 100644
--- a/java-chassis-reference/zh_CN/build-provider/configuration/downgrade-strategy.md
+++ b/java-chassis-reference/zh_CN/build-provider/configuration/downgrade-strategy.md
@@ -67,7 +67,7 @@ servicecomb.isolation.Provider.DemoService.hello.sayHello.timeout.enabled
| servicecomb.circuitBreaker.errorThresholdPercentage | 50 | - | 否 | 错误率阈值，达到阈值则触发熔断 | |
| servicecomb.fallback.enabled | TRUE | - | 否 | 是否启用出错后的故障处理措施 | |
| servicecomb.fallback.maxConcurrentRequests | 10 | - | 否 | 并发调用容错处理措施（servicecomb.fallbackpolicy.policy）的请求数，超过这个值则不再调用处理措施，直接返回异常 | |
-| servicecomb.fallbackpolicy.policy | throwexception | lreturnnulllthrowexception | 否 | 出错后的处理策略 | |
+| servicecomb.fallbackpolicy.policy | throwexception | returnull \| throwexception | 否 | 出错后的处理策略 | |
> **小心**：
> 谨慎使用servicecomb.isolation.timeout.enabled=true。因为系统处理链都是异步执行，中间处理链的返回，会导致后面处理链的逻辑处理效果丢失。尽可能将servicecomb.isolation.timeout.enabled保持默认值false，并且正确设置网络层超时时间servicecomb.request.timeout=30000。
diff --git a/java-chassis-reference/zh_CN/build-provider/configuration/lb-strategy.md b/java-chassis-reference/zh_CN/build-provider/configuration/lb-strategy.md
index 93b4201..a2ca2df 100644
--- a/java-chassis-reference/zh_CN/build-provider/configuration/lb-strategy.md
+++ b/java-chassis-reference/zh_CN/build-provider/configuration/lb-strategy.md
@@ -1 +1 @@
-本章节的内容已过时，新的负载均衡策略说明见[负载均衡](/references-handlers/loadbalance.md)。
+本章节的内容已过时，新的负载均衡策略说明见[负载均衡](/java-chassis-reference/zh_CN/references-handlers/loadbalance.md)
diff --git a/java-chassis-reference/zh_CN/build-provider/configuration/ratelimite-strategy.md b/java-chassis-reference/zh_CN/build-provider/configuration/ratelimite-strategy.md
index 5d4dca5..e842e4c 100644
--- a/java-chassis-reference/zh_CN/build-provider/configuration/ratelimite-strategy.md
+++ b/java-chassis-reference/zh_CN/build-provider/configuration/ratelimite-strategy.md
@@ -38,4 +38,5 @@
| servicecomb.flowcontrol.Provider.qps.global.limit | 2147483647（max int） | \(0,2147483647\]，整形 | 否 | provider接受请求流量的全局配置 | 没有具体的流控配置时，此配置生效 |
> **注意：**
-> provider端限流策略配置中的`ServiceName`指的是调用该provider的consumer，而`shema`、`operation`指的是provider自身的。即provider端限流配置的含义是，限制指定consumer调用本provider的某个schema、operation的流量。
+> provider端限流策略配置中的`ServiceName`指的是调用该provider的consumer，而`schema`、`operation`指的是provider自身的。即provider端限流配置的含义是，限制指定consumer调用本provider的某个schema、operation的流量。
+
diff --git a/java-chassis-reference/zh_CN/build-provider/service-configuration.md b/java-chassis-reference/zh_CN/build-provider/service-configuration.md
index bf7f433..257fe78 100644
--- a/java-chassis-reference/zh_CN/build-provider/service-configuration.md
+++ b/java-chassis-reference/zh_CN/build-provider/service-configuration.md
@@ -11,4 +11,3 @@
## [参数效验](/build-provider/configuration/parameter-validator.html)
• 用户在provider端使用参数效验，可以对相应的参数输入要求预先进行设置，在接口实际调用前进行效验处理，达到控制参数输入标准的效果。
-
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services