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 25cb70d update retry fail, governance and zero config new features
(#236)
25cb70d is described below
commit 25cb70d581fdfde65f771848bcfa109519b3b7e3
Author: bao liu <[email protected]>
AuthorDate: Wed Apr 28 11:36:37 2021 +0800
update retry fail, governance and zero config new features (#236)
---
.../zh_CN/docs/references-handlers/fail-retry.md | 15 ++--
.../zh_CN/docs/references-handlers/governance.md | 70 ++++++++++++++++
.../zh_CN/docs/registry/distributed.md | 93 ++++++++++------------
3 files changed, 116 insertions(+), 62 deletions(-)
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/fail-retry.md
b/java-chassis-reference/zh_CN/docs/references-handlers/fail-retry.md
index ba425f7..7fde294 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/fail-retry.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/fail-retry.md
@@ -68,7 +68,8 @@ Java Chassis 会在上述过程的开始阶段，执行超时检测，如果发
| 配置项 | 默认值 | 含义 |
| :--- | :--- | :--- |
-| servicecomb.invocation.enableTimeoutCheck | true | 功能开关，默认启用 |
+| servicecomb.invocation.timeout.check.enabled | false |
功能开关，默认关闭 |
+| servicecomb.invocation.timeout.check.strategy | passing-time |
全局时间计算策略，可选 passing-time 和 processing-time|
| servicecomb.invocation.${op-any-priority}.timeout | -1 |
请求超时时间，默认为-1，表示不超时 |
侵入式超时时间支持全局配置和针对某个具体接口配置， Producer 和 Consumer 配置不同。 比如：
@@ -85,8 +86,10 @@
servicecomb.invocation.${target_service}.${schema_id}.${operation_id}.timeout: 1
```
侵入式超时检测具备传播机制。 比如客户端->A->B的场景，当B判断是否已经超时的时候，会加上在A已经处理的时间。因此可以用侵入式超时时间控制
-请求链路的全局超时。 由于机器时间同步问题，全局超时并不是所有环节都是精确的，比如B在计算超时的时候，A的请求在网络传输的时间被忽略掉了，只计算实际
-在A已经处理的时间。
+请求链路的全局超时。 由于机器时间同步问题，全局超时包括两种计算方式，第一种是 passing-time，这种方式依赖于服务器的时间同步，B计算
+运行时间通过A记录的开始时间与B当前时间的差值；第二种是 processing-time，B在计算超时的时候，A的请求在网络传输的时间被忽略掉了，只计算实际
+在A已经处理的时间加上B已经处理的时间。第一种方式适合于服务器之间的时间非常同步，可以忽略差异的场景。第二种方式更加适合于不考虑时间同步，但是
+对于实际计算时间精度要求不高的场景。
开发者也可以在自定义 Filter, Handler, 业务逻辑（比如执行数据库操作前和操作后）增加超时检测。 具体方式是先获取 `Invocation`
对象， 然后调用
`ensureInvocationNotTimeout` 方法。
@@ -102,9 +105,3 @@ public String testInvocationTimeout(InvocationContext
context) {
}
```
-
-
-
-
-
-
\ No newline at end of file
diff --git
a/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
b/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
index 23c4ee5..604b877 100644
--- a/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
+++ b/java-chassis-reference/zh_CN/docs/references-handlers/governance.md
@@ -210,6 +210,42 @@ servicecomb:
default: governance-provider
```
+Java Chassis是基于Open API的REST/RPC框架，在模型上和单纯的REST框架存在差异。Java Chassis提供两种模式匹配规则，
+第一种是基于REST的，第二种是基于RPC的。可以通过配置项：`servicecomb.governance.{operation}.matchType`
指定匹配规则，
+默认使用REST。比如：
+
+```
+servicecomb:
+ governance:
+ matchType: rest # 设置全局默认是rest匹配模式
+ GovernanceEndpoint.helloRpc:
+ matchType: rpc # 设置服务端的接口helloRpc采用RPC匹配模式
+```
+
+在REST匹配模式下， apiPath使用url， 比如：
+
+```
+servicecomb:
+ matchGroup:
+ userLoginAction: |
+ matches:
+ - apiPath:
+ exact: "/user/login"
+```
+
+在RPC匹配模式下, apiPath使用operation, 比如：
+
+```
+servicecomb:
+ matchGroup:
+ userLoginAction: |
+ matches:
+ - apiPath:
+ exact: "UserSchema.login"
+```
+
+对于服务端治理，比如限流，REST模式下从HTTP取header；对于客户端治理，比如重试，REST模式下从InvocationContext取header。
+
* Spring Cloud
Spring
Cloud通过Aspect拦截RequestMappingHandlerAdater实现了限流、熔断和隔离仓，通过拦截RestTemplate和FeignClient实现了重试。
@@ -222,6 +258,22 @@ Spring Cloud通过Aspect拦截RequestMappingHandlerAdater实现了限流、熔
</dependency>
```
+Spring Cloud是基于REST的框架，能比较好的符合流量特征治理的匹配语义，apiPath和headers分别对应HTTP协议的概念：
+
+```
+servicecomb:
+ matchGroup:
+ userLoginAction: |
+ matches:
+ - apiPath:
+ exact: "/user/login"
+ method:
+ - POST
+ - headers:
+ Authentication:
+ prefix: Basic
+```
+
* Dubbo
Dubbo的Provider通过Filter拦截请求实现了限流、熔断和隔离仓，通过拦截ClusterInvoker实现了重试。使用流量标记治理能力，首先需要在代码中引入依赖：
@@ -240,6 +292,24 @@ Dubbo的Provider通过Filter拦截请求实现了限流、熔断和隔离仓，
<dubbo:consumer cluster="dubbo-servicecomb"></dubbo:consumer>
```
+Dubbo是一个RPC框架，需要定义operation和apiPath的映射关系，比如，服务端限流、熔断、隔离仓场景：
+ `com.huaweicloud.it.order.OrderGovernanceService.hello` ；客户端重试场景：
+ `com.huaweicloud.it.order.OrderGovernanceService.retry` 。
headers使用Attachments，需要包含在Attachments里面的头才会参与匹配。
+
+```
+servicecomb:
+ matchGroup:
+ userLoginAction: |
+ matches:
+ - apiPath:
+ exact: "com.huaweicloud.it.order.OrderGovernanceService.hello"
+ method:
+ - POST
+ - headers
+ Authentication:
+ prefix: Basic
+```
+
* 自定义
服务治理的默认实现并不一定能够解决业务的所有问题。自定义治理功能可以方便的在不同的场景下使用基于流量的治理能力，比如在网关场景下进行流控。
diff --git a/java-chassis-reference/zh_CN/docs/registry/distributed.md
b/java-chassis-reference/zh_CN/docs/registry/distributed.md
index 2775e38..12b7e91 100644
--- a/java-chassis-reference/zh_CN/docs/registry/distributed.md
+++ b/java-chassis-reference/zh_CN/docs/registry/distributed.md
@@ -1,64 +1,51 @@
-# 去中心化注册发现
+# 轻量化配置中心 zero-config
-去中心化注册发现指不通过服务中心中间件，实现服务注册发现。去中心化注册发现比较适合于小规模管理面服务的开发，或者
-对于弹性扩缩容要求不高的场景。 servicecomb 提供了两种方式满足去中心化的注册发现。这两种方式涉及如下模块：
+zero-config是Java Chassis提供的轻量化服务中心，以支持在小规模的应用场景下，不必专门部署独立的服务中心。
-* 本地注册发现: registry-local，通过本地配置文件注册发现
-* 组播注册发现: registry-zeroconfig, 采用组播的方式注册发现
-* 实例契约发现: registry-schema-dicovery, 通过给实例发送请求，从实例查询契约
+zero-config支持多种工作模式：
-## 本地注册发现 + 实例契约发现
-
-通过组合本地注册发现和实例契约发现能够实现去中心化注册发现。这种场景需要 consumer 配置 provider 的地址信息，
-适合 provider 地址固定的场景。 或者在容器部署的场景（比如 Istio）， consumer 可以通过固定的服务名访问 provider,
-采用这种注册发现方式能够很好利用容器的发现能力。
-
-通过组合本地注册发现和实例契约发现包含下面几个开发步骤：
-
-* 引入相关依赖
-
- ```xml
- <dependency>
- <groupId>org.apache.servicecomb</groupId>
- <artifactId>registry-schema-discovery</artifactId>
- </dependency>
- ```
-
- 备注： registry-schema-discovery 依赖于 registry-local
+* local
+
单机模式，没有实例动态发现能力，所有的服务调用，都使用[调用第三方服务](../build-consumer/3rd-party-service-invoke.md)机制处理。
-* 在 consumer 的 `registry.yaml` 中配置 provider 的微服务和微服务实例信息
+* multicast
+ 使用UDP多播发送微服务注册信息，适用于所有微服务实例都在同一个子网内的场景，每个微服务实例都相当于是一个服务中心实例。
-```yaml
-demo-zeroconfig-schemadiscovery-registry-edge:
- - id: "002"
- version: "0.0.2"
- appid: demo-zeroconfig-schemadiscovery-registry
- schemaIds:
- - ClientServerEndpoint
- - SchemaDiscoveryEndpoint
- instances:
- - endpoints:
- - rest://localhost:8888
-```
-
-## 组播注册发现 + 实例契约发现
-
-组播注册发现采用UDP协议发现实例。使用这种方式只需要在项目中配置依赖：
+使用 zero-config， 需要在项目中引入如下依赖：
```xml
- <dependency>
- <groupId>org.apache.servicecomb</groupId>
- <artifactId>registry-schema-discovery</artifactId>
- </dependency>
- <dependency>
- <groupId>org.apache.servicecomb</groupId>
- <artifactId>registry-zero-config</artifactId>
- </dependency>
+<dependency>
+ <groupId>org.apache.servicecomb</groupId>
+ <artifactId>registry-zero-config</artifactId>
+</dependency>
```
-可以看出使用这种方式非常简单，也是 zero-config 名称的由来。
+## zero-config 相关配置
+
+配置前缀： `servicecomb.service.zero-config`
-## 注意事项
+| 配置项 | 默认值 | 含义 |
+| :--- | :--- | :--- |
+| enabled | true | 是否使用zero-config服务中心功能 |
+| mode | multicast| 工作模式，内置multicast和local模式 |
+| heartbeat.interval | 30s | 发送注册/心跳消息的间隔 |
+| heartbeat.lost-times | 3 | 心跳丢失超过指定的次数，则删除相应的实例 |
+| pull-interval | 3s | consumer流程更新目标实例的间隔 |
+| multicast.address | 0.0.0.0:6666 | UDP的本地bind地址， 对于不允许bind
0.0.0.0的场景，需要修改本配置项。注意： 相应的网卡要打开UDP multicast功能 |
+| multicast.group | 225.6.7.8| UDP multicast多播group地址，根据标准，合法地址范围为(224.0.0.0,
239.255.255.255]。开发阶段，为避免不同开发人员之间产生环境互相干扰， 可以各自设置不同的group地址|
-使用去中心化注册发现，一般会去掉集中注册发现模块的依赖。 如果没去掉依赖，就会存在多种注册发现并存的情况。这种
-情况的行为可以参考注册发现概述的内容。
+示例：
+
+```
+servicecomb:
+ service:
+ zero-config:
+ enable: true
+ mode: multicast
+ heartbeat:
+ interval: 30s
+ lost-times: 3
+ pull-interval: 3s
+ multicast:
+ address: 0.0.0.0:6666
+ group: 225.6.7.8
+```
\ No newline at end of file
