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/12/09 03:12:22 UTC
[servicecomb-docs] branch master updated: modify fallback spelling
and http filter contents (#212)
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 32c3893 modify fallback spelling and http filter contents (#212)
32c3893 is described below
commit 32c3893e69da9e8d51e12c336d4dde05ef8c176b
Author: bao liu <bi...@qq.com>
AuthorDate: Wed Dec 9 11:12:12 2020 +0800
modify fallback spelling and http filter contents (#212)
---
.../configuration/downgrade-strategy.md | 4 +-
.../application-bmi/service-management.md | 4 +-
.../zh_CN/docs/general-development/http-filter.md | 63 +++++++++++-----------
.../zh_CN/docs/references-handlers/bizkeeper.md | 4 +-
4 files changed, 38 insertions(+), 37 deletions(-)
diff --git a/java-chassis-reference/en_US/docs/build-provider/configuration/downgrade-strategy.md b/java-chassis-reference/en_US/docs/build-provider/configuration/downgrade-strategy.md
index bc63b12..daa2e17 100644
--- a/java-chassis-reference/en_US/docs/build-provider/configuration/downgrade-strategy.md
+++ b/java-chassis-reference/en_US/docs/build-provider/configuration/downgrade-strategy.md
@@ -66,7 +66,7 @@ For Consumers, the conriguration item should be servicecomb.isolation.Provider.t
| servicecomb.circuitBreaker.[type].errorThresholdPercentage | 50 | - | No | The threshold of error rate. If the threshold is reached, circuit breaker is triggered. | |
| servicecomb.fallback.[type].enabled | TRUE | - | No | Enable fallback handling or not | |
| servicecomb.fallback.[type].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.[type].policy | throwexception | returnnulll \| throwexception | No | The fallback policy when errors occurred. | |
+| servicecomb.fallbackpolicy.[type].policy | throwException | returnNull \| throwException | No | The fallback policy when errors occurred. | |
**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.
@@ -94,7 +94,7 @@ servicecomb:
enabled: true
fallbackpolicy:
Consumer:
- policy: throwexception
+ policy: throwException
```
> **NOTE:**
diff --git a/java-chassis-reference/zh_CN/docs/featured-topics/application-bmi/service-management.md b/java-chassis-reference/zh_CN/docs/featured-topics/application-bmi/service-management.md
index f75ef93..9f7f191 100644
--- a/java-chassis-reference/zh_CN/docs/featured-topics/application-bmi/service-management.md
+++ b/java-chassis-reference/zh_CN/docs/featured-topics/application-bmi/service-management.md
@@ -31,13 +31,13 @@ servicecomb:
requestVolumeThreshold: 3
fallbackpolicy:
Provider:
- policy: returnnull
+ policy: returnNull
```
也可以通过环境变量的方式动态修改配置文件的值，比如采用以下指令重新运行即可：
```bash
-mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dservicecomb.handler.chain.Provider.default=bizkeeper-provider -Dservicecomb.circuitBreaker.Provider.calculator.requestVolumeThreshold=3 -Dservicecomb.fallbackpolicy.Provider.policy=returnnull"
+mvn spring-boot:run -Dspring-boot.run.jvmArguments="-Dservicecomb.handler.chain.Provider.default=bizkeeper-provider -Dservicecomb.circuitBreaker.Provider.calculator.requestVolumeThreshold=3 -Dservicecomb.fallbackpolicy.Provider.policy=returnNull"
```
## 验证
diff --git a/java-chassis-reference/zh_CN/docs/general-development/http-filter.md b/java-chassis-reference/zh_CN/docs/general-development/http-filter.md
index 67edb31..b9357c7 100644
--- a/java-chassis-reference/zh_CN/docs/general-development/http-filter.md
+++ b/java-chassis-reference/zh_CN/docs/general-development/http-filter.md
@@ -1,24 +1,27 @@
-某些场景中，业务使用http而不是https，作为网络传输通道，此时为了防止被伪造或篡改请求，需要提供consumer、producer之间对http码流的签名功能。
+# HTTP Filter
-签名功能使用org.apache.servicecomb.common.rest.filter.HttpClientFilter和org.apache.servicecomb.common.rest.filter.HttpServerFilter接口来承载，建议http码流强相关的逻辑使用这里的Filter机制，而契约参数相关逻辑使用Handler机制。
+使用 Java Chassis 对请求进行拦截推荐的方式是[处理链](../references-handlers/intruduction.md)。使用处理链不关注通信协议，
+无论使用 HIGHWAY 还是使用 REST， 请求均会经过处理链进行处理。 当用户使用 REST 的时候，支持两种通道：`REST over Servlet` 和
+`REST over Vertx`，这两种通道都支持通过 `HttpClientFilter` 和 `HttpServerFilter` 两个接口对请求进行拦截。
-关于Filter接口的使用，可以参考[demo-signature](https://github.com/ServiceComb/ServiceComb-Java-Chassis/tree/master/demo/demo-signature)。
+比如某些场景中，业务使用 http 而不是 https，为了防止被伪造或篡改请求，需要提供consumer、producer之间对http码流的签名功能。
+签名功能可以使用 `HttpClientFilter` 和 `HttpServerFilter` 实现， 详细参考[示例代码][demo-signature]。 本章节通过
+签名功能的实现介绍如何使用 `HttpClientFilter` 和 `HttpServerFilter` 。
+[demo-signature]: https://github.com/apache/servicecomb-java-chassis/tree/master/demo/demo-signature
+## HttpClientFilter 和 HttpServerFilter 介绍
-# 1.概述
+HttpClientFilter 和 HttpServerFilter 使用 Java 标准的 SPI 机制加载。 允许加载多个， 各实例之间的执行顺序由getOrder的返回值决定。
+如果getOrder返回值相同，则相应的实例顺序随机决定。无论是request，还是response，读取body码流，都使用getBodyBytes\(\)，返回值可能为
+null（比如get调用的场景），如果不为null，对应的码流长度，通过getBodyBytesLength\(\)获取。
-Filter机制使用Java标准的SPI机制加载。
+>***注意事项***:
+> HttpClientFilter 的 beforeSendRequest 在接口调用的当前线程执行， afterReceiveResponse 在业务线程池中执行。
+> HttpClientFilter 的 afterReceiveRequest 在业务线程池中执行。beforeSendResponse 和 beforeSendResponseAsync
+> 可能在业务线程池执行， 也可能在网络线程池执行， 务必保证不能够出现阻塞操作。
-HttpClientFilter、HttpServerFilter都各自允许加载多个：
-
-* 各实例之间的执行顺序由getOrder的返回值决定
-
-* 如果getOrder返回值相同，则相应的实例顺序随机决定
-
-无论是request，还是response，读取body码流，都使用getBodyBytes\(\)，返回值可能为null（比如get调用的场景），如果不为null，对应的码流长度，通过getBodyBytesLength\(\)获取。
-
-# 2.HttpClientFilter
+## HttpClientFilter
系统内置2个HttpClientFilter，扩展功能时注意order值不要冲突：
@@ -26,7 +29,7 @@ HttpClientFilter、HttpServerFilter都各自允许加载多个：
* org.apache.servicecomb.transport.rest.client.http.DefaultHttpClientFilter, order值为Integer.MAX\_VALUE
-## 2.1原型
+* 原型
```
public interface HttpClientFilter {
@@ -40,21 +43,19 @@ public interface HttpClientFilter {
}
```
-## 2.2 beforeSendRequest
+* beforeSendRequest
用于在已经生成码流之后，发送请求之前，根据url、header、query、码流计算签名，并设置到header中去\(requestEx.setHeader\)。
-
从入参invocation中可以获取本次调用的各种元数据以及对象形式的参数（码流是根据这些参数生成的）。
-## 2.3 afterReceiveResponse
+* afterReceiveResponse
用于在从网络收到应答后，根据header、码流计算签名，并与header中的签名对比。如果签名不对，直接构造一个Response
-
作为返回值，只要不是返回NULL，则框架会中断对其他HttpClientFilter的调用。
-# 3 HttpServerFilter
+## HttpServerFilter
-## 3.1原型
+* 原型
```
public interface HttpServerFilter {
@@ -73,25 +74,25 @@ public interface HttpServerFilter {
}
```
-## 3.2 needCacheRequest
+* needCacheRequest
-与HttpClientFilter不同的是，增加了决定是否缓存请求的功能。
-
-这是因为ServiceComb不仅仅能使用standalone的方式运行，也能运行于web容器（比如tomcat），在servlet的实现上，请求码流只能读取一次，并且不一定支持reset（比如tomcat），RESTful框架需要执行反序列化，需要读取body码流，签名逻辑也需要读取body码流，如果使用默认的处理，必然有一方功能无法实现。
+与HttpClientFilter不同的是，增加了决定是否缓存请求的功能。这是因为ServiceComb不仅仅能使用standalone的方式运行，也
+能运行于web容器（比如tomcat），在servlet的实现上，请求码流只能读取一次，并且不一定支持reset（比如tomcat），REST 框架需要执行反序列化，需
+要读取body码流，签名逻辑也需要读取body码流，如果使用默认的处理，必然有一方功能无法实现。
所以运行于web容器场景时，所有HttpServerFilter，只要有一个返回需要缓存请求，则body码流会被复制保存起来，以支持重复读取。
入参是本次请求对应的元数据，业务可以针对该请求决定是否需要缓存请求。
-## 3.3 afterReceiveRequest
-
-在收到请求后，根据url、header、query、码流计算签名，并与header中的签名对比,如果签名不对，直接构造一个Response作为返回值，只要不是返回NULL，则框架会中断对其他HttpClientFilter的调用。
+* afterReceiveRequest
-## 3.4 beforeSendResponse
+在收到请求后，根据url、header、query、码流计算签名，并与header中的签名对比,如果签名不对，直接构造一个Response作为返回值，
+只要不是返回NULL，则框架会中断对其他HttpClientFilter的调用。
-在发送应答之前，根据header、码流计算签名，并设置到header中去。
+* beforeSendResponse 和 beforeSendResponseAsync
-因为可能invocation还没来得及构造，调用流程已经出错，所以入参invocation可能是null。
+在发送应答之前，根据header、码流计算签名，并设置到header中去。因为可能invocation还没来得及构造，调用流程
+已经出错，所以入参invocation可能是null。
diff --git a/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md b/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md
index 8ef6ca3..3681605 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/bizkeeper.md
@@ -91,7 +91,7 @@ servicecomb.isolation.Provider.DemoService.hello.sayHello.timeout.enabled
| servicecomb.circuitBreaker.[type].[scope].errorThresholdPercentage | 50 | - | 否 | 错误率阈值，达到阈值则触发熔断 | 由于10秒还会被划分为10个1秒的统计周期，经过1s中后才会开始计算错误率，因此从调用开始至少经过1s，才会发生熔断。 |
| servicecomb.fallback.[type].[scope].enabled | TRUE | - | 否 | 是否启用出错后的故障处理措施 | |
| servicecomb.fallback.[type].[scope].maxConcurrentRequests | 10 | - | 否 | 并发调用容错处理措施（servicecomb.fallbackpolicy.policy）的请求数，超过这个值则不再调用处理措施，直接返回异常 | |
-| servicecomb.fallbackpolicy.[type].[scope].policy | throwexception | returnull \| throwexception | 否 | 出错后的处理策略 | |
+| servicecomb.fallbackpolicy.[type].[scope].policy | throwException | returnNull \| throwexception | 否 | 出错后的处理策略 | |
**小心**：谨慎使用 `servicecomb.isolation.timeout.enabled=true` 。因为系统处理链都是异步执行，中间处理链的返回，会导致
后面处理链的逻辑处理效果丢失。尽可能将 `servicecomb.isolation.timeout.enabled` 保持默认值false，并且正确设置网络层超时时
@@ -121,7 +121,7 @@ servicecomb:
enabled: true
fallbackpolicy:
Consumer:
- policy: throwexception
+ policy: throwException
```
> **说明：**