This is an automated email from the ASF dual-hosted git repository.
liujun pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/dubbo-awesome.git
The following commit(s) were added to refs/heads/master by this push:
new 4d7cadc Add more to thinsdk proposal
4d7cadc is described below
commit 4d7cadce3bc0ede0dd3a6104d50d68985637384f
Author: chickenlj <[email protected]>
AuthorDate: Wed Aug 10 00:27:35 2022 +0800
Add more to thinsdk proposal
---
proposals/D3.1-thinsdk-sidecar-mesh.md | 144 +++++++++++++++++++++++++++++----
1 file changed, 129 insertions(+), 15 deletions(-)
diff --git a/proposals/D3.1-thinsdk-sidecar-mesh.md
b/proposals/D3.1-thinsdk-sidecar-mesh.md
index 1653ffa..91655fc 100644
--- a/proposals/D3.1-thinsdk-sidecar-mesh.md
+++ b/proposals/D3.1-thinsdk-sidecar-mesh.md
@@ -79,10 +79,128 @@
-
https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/filters/http/health_check/v3/health_check.proto#envoy-v3-api-msg-extensions-filters-http-health-check-v3-healthcheck
-
https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/health_check.proto
-补充：
+##### Kubernetes 相关实例状态检查
-1. 使用 grpc 的 Health 来做健康检查。Triple 现在是支持 Health 服务的。
-2. Dubbo 会开启如下默认端口 Triple: 50051、Metadata : 20880、Qos:
22222，后续要做端口复用，以后在一个端口上提供了 Triple 协议和 QOS 协议，在 QOS 基础上支持 REST
的/health，这样/health 就自动集成进去了。
+Pod 的生命周期与服务调度息息相关，通过对 Kubernetes 官方探针的实现，能够使 Dubbo 乃至整个应用的生命周期与 Pod 的生命周期对齐。
+
+**存活检测**
+
+对于 livenessProbe 存活检测，由于 Dubbo 框架本身无法获取到应用的存活状态，因此本接口无默认实现，且默认返回成功。开发者可以根据 SPI
定义对此 SPI 接口进行拓展，从应用层次对是否存活进行判断。
+
+**就绪检测**
+
+对于 readinessProbe 就绪检测，目前 Dubbo 默认提供了两个检测维度，一是对 Dubbo
服务自身是否启停做判断，另外是对所有服务是否存在已注册接口，如果所有服务均已从注册中心下线（可以通过 QOS
+运维进行操作）将返回未就绪的状态。（readinessProbe 目前 dubbo 实现方式不适用于 mesh，mesh 模式不配置注册中心，dubbo 的
readinessProbe 会返回 false）
+
+**启动检测**
+
+对于 startupProbe 启动检测，目前Dubbo 默认提供了一个检测维度，即是在所有启动流程（接口暴露、注册中心写入等）均结束后返回已就绪状态。
+
+**使用方法：**
+
+参考配置(具体可以参考 [dubbo-samples-mesh-provider 的配置文件](#properties))
+
+```yaml
+livenessProbe:
+ httpGet:
+ path: /live
+ port: 22222
+ initialDelaySeconds: 5
+ periodSeconds: 5
+readinessProbe:
+ httpGet:
+ path: /ready
+ port: 22222
+ initialDelaySeconds: 5
+ periodSeconds: 5
+startupProbe:
+ httpGet:
+ path: /startup
+ port: 22222
+ failureThreshold: 30
+ periodSeconds: 10
+```
+
+##### Envoy 主动主动健康检车
+
+本次从 consumer 侧的 Envoy ，对其上游集群 provider 做主动健康检查(GRPC)。
+
+配置EnvoyFilter如下：
+
+```yaml
+apiVersion: networking.istio.io/v1alpha3
+kind: EnvoyFilter
+metadata:
+ name: cluster
+ namespace: dubbo-demo
+spec:
+ workloadSelector:
+ labels:
+ app: dubbo-samples-mesh-consumer
+ configPatches:
+ - applyTo: CLUSTER
+ match:
+ cluster:
+ name:
outbound|50052||dubbo-samples-mesh-provider.dubbo-demo.svc.cluster.local
+ patch:
+ operation: MERGE
+ value:
+ health_checks:
+ - timeout: 5s
+ interval: 5s
+ initial_jitter: 1s
+ interval_jitter: 1s
+ interval_jitter_percent: 50
+ unhealthy_threshold: 1
+ healthy_threshold: 1
+ reuse_connection: true
+ no_traffic_interval: 2s
+ no_traffic_healthy_interval: 4s
+ unhealthy_interval: 5s
+ unhealthy_edge_interval: 10s
+ healthy_edge_interval: 10s
+ tls_options:
+ alpn_protocols:
+ - http1.1
+ - h2
+ transport_socket_match_criteria:
+ useMTLS: true
+ grpc_health_check:
+ authority:
dubbo-samples-mesh-provider.dubbo-demo.svc.cluster.local
+```
+
+Envoy健康检查的配置说明(
+详见[Envoy
健康检查文档](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/health_check.proto#envoy-v3-api-msg-config-core-v3-healthcheck)):
+
+```yaml
+{
+ "timeout": "{...}",超时时间
+ "interval": "{...}",检测间隔
+ "initial_jitter": "{...}",初始抖动
+ "interval_jitter": "{...}",间隔抖动
+ "interval_jitter_percent": "...",间隔抖动比例
+ "unhealthy_threshold": "{...}",不健康阈值
+ "healthy_threshold": "{...}",健康阈值
+ "reuse_connection": "{...}",重用连接
+ "http_health_check": "{...}",http类型健康检测
+ "tcp_health_check": "{...}",tcp类型健康检测
+ "grpc_health_check": "{...}",grpc类型健康检测
+ "custom_health_check": "{...}",自定义健康检测
+ "no_traffic_interval": "{...}",没有流量时的间隔
+ "no_traffic_healthy_interval": "{...}",没有流量健康后的间隔
+ "unhealthy_interval": "{...}",不健康的间隔
+ "unhealthy_edge_interval": "{...}",不健康边缘间隔
+ "healthy_edge_interval": "{...}",健康边缘间隔
+ "event_log_path": "...",日志路径
+ "always_log_health_check_failures": "...",失败总是记录日志
+ "tls_options": "{...}",选项
+ "transport_socket_match_criteria": "{...}"trasport_socket匹配条件
+}
+```
+
+- [Dubbo
探针文档](https://dubbo.apache.org/zh/docs/v3.0/references/lifecycle/brief/)
+- [Istio
服务的健康检查官方文档](https://istio.io/latest/zh/docs/ops/configuration/mesh/app-health-check/)
+- [Envoy
健康检查文档](https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/health_check.proto#envoy-v3-api-msg-config-core-v3-healthcheck)
#### 服务注册
@@ -141,21 +259,17 @@ tri-consumer-appname: dubbo-demo-triple-api-consumer
- 需要支持 envoy
header：https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_conn_man/headers#config-http-conn-man-headers-custom-request-headers
- 需要支持 envoy router 的 header：调用时支持 Envoy router
header：https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter#id7
\*对比 google grpc 和 envoy grpc 的差异，适配 header
内容：https://www.envoyproxy.io/docs/envoy/latest/api-v3/config/core/v3/grpc_service.proto.html#envoy-api-field-core-grpcservice-envoy-grpc
+## 下一步工作计划
+
+* 探索envoy和istio支持的服务治理的内容，比如开发者需要实现重试，API处要传什么值。
+* 解决目前readinessProbe不适用mesh模式的问题
+* 精简SDK。
+
### 其他事项：
- 优雅下线的时候已经有相关的逻辑。
- 接口级别的服务注册对接 sidecar
- 多实例应用。
-- 没有 mesh 迁移到 mesh 的方案
-- gRPC 相关的支持内容调研
+- 老系统迁移到 mesh 的方案
- 目前 mesh 模式的 providerPort 没有考虑多端口情况
-- 目前 Dubbo 的 ReadinessProbe 不适用 mesh 场景，需重写 ReadinessProbe 实现
-
-### 2022.5.19 会议记录：
-
-第一阶段需要解决的问题：
-
-1. 通过 gRPC+istio 的部署用例，分析拆分的步骤，完整的跑通；然后再做一个 Dubbo 的用例，做好文档记录。
-2. 解决 Dubbo SDK 如何确定发送 RPC
请求的地址，比如http://demo.default.svc.cluster.local:50051，这个地址与envoy内部的路由相关。要根据接口组装出appname格式的地址。
-3. 解决 Dubbo sdk 需要规避服务发现和直连的逻辑，如果不规避可能会报错。
-4. 成功跑通经过 Sidecar，从 Consumer -> Provider 的 RPC 调用。
+- 目前 Dubbo 的 ReadinessProbe 不适用 mesh 场景，需修正 ReadinessProbe 的计算逻辑
\ No newline at end of file
