You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@dubbo.apache.org by li...@apache.org on 2022/07/26 13:15:13 UTC
[dubbo-awesome] branch master updated: doc: update health check and service call
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 5c0289e doc: update health check and service call
new 69c1256 Merge pull request #83 from conghuhu/cgq
5c0289e is described below
commit 5c0289e21b8b7b8acd3032ba0032845fcf304a49
Author: conghuhu <co...@gmail.com>
AuthorDate: Tue Jul 26 18:15:13 2022 +0800
doc: update health check and service call
---
proposals/D3.1-thinsdk-sidecar-mesh.md | 136 ++++++++++++++++++++-------------
1 file changed, 83 insertions(+), 53 deletions(-)
diff --git a/proposals/D3.1-thinsdk-sidecar-mesh.md b/proposals/D3.1-thinsdk-sidecar-mesh.md
index ac47936..1653ffa 100644
--- a/proposals/D3.1-thinsdk-sidecar-mesh.md
+++ b/proposals/D3.1-thinsdk-sidecar-mesh.md
@@ -1,100 +1,127 @@
# 3.1 Dubbo Thin SDK (draft)
-* Authors: Zhongming Hua, Jun Liu
+
+- Authors: Zhongming Hua, Jun Liu, Guoqing Cong
## Objective
+
## Background
+
### Dubbo 基本工作原理介绍
除了应用启动和服务注册流程以外，其他两大流程都是在直连模式下：服务发现以及服务调用流程。其中应用下线不单独列出来主要是优雅下线时候的处理
+
#### 应用启动
-以下是应用启动的大致流程（省略了spring容器启动等与mesh无关的流程）：
-1. ApplicationDeployer #initialize()：注册ShutdownHook ->开启配置中心 -> 加载应用配置 -> 初始化ModuleDeployer -> 开启元数据中心
+
+以下是应用启动的大致流程（省略了 spring 容器启动等与 mesh 无关的流程）：
+
+1. ApplicationDeployer #initialize()：注册 ShutdownHook ->开启配置中心 -> 加载应用配置 -> 初始化 ModuleDeployer -> 开启元数据中心
2. ApplicationDeployer #doStart()：ModuleDeployer #start()
3. ModuleDeployer #start()：ModuleDeployer #initialize() -> 暴露服务 -> 引用服务
4. ApplicationDeployer #onModuleStarted()：暴露 MetadataService 服务-> 上报元数据信息-> 注册应用实例地址
+
#### 服务暴露
- 以下是服务暴露的流程：
+
+以下是服务暴露的流程：
+
1. 暴露 injvm 协议的服务
2. 暴露 Triple 协议的服务
3. 发起服务注册：registry 协议
4. 暴露 MetadataService 服务
5. 发起服务注册：service-discovery-registry 协议
+
#### 服务发现
- 在应用启动中的服务引用过程包含了服务发现，以下是直连模式下的引用服务流程：
+
+在应用启动中的服务引用过程包含了服务发现，以下是直连模式下的引用服务流程：
1. TripleProtocol #refer
2. 创建 TripleInvoker 实例
3. 与对端建连（ConnectionManager #connect）
-4. 将 TripleInvoker 实例包装成ClusterInvoker，附加集群相关处理能力（Cluster #join）
-5. 新增Cluster Interceptor（主要是附加一些容错策略、结果处理策略）
-6. 推送consumer端元数据信息
+4. 将 TripleInvoker 实例包装成 ClusterInvoker，附加集群相关处理能力（Cluster #join）
+5. 新增 Cluster Interceptor（主要是附加一些容错策略、结果处理策略）
+6. 推送 consumer 端元数据信息
7. 创建代理
#### 服务调用
+
1. InvokerInvocationHandler #invoke()
-2. filter chain处理：ConsumerContextFilter 、FutureFilter 、MonitorFilter 、RouterSnapshotFilter
+2. filter chain 处理：ConsumerContextFilter 、FutureFilter 、MonitorFilter 、RouterSnapshotFilter
3. 执行 router chain（直连模式不需要路由）
-4. 执行负载均衡策略（由于是直连一个sidecar，所以负载均衡策略没有效果）：（AbstractClusterInvoker #select）
+4. 执行负载均衡策略（由于是直连一个 sidecar，所以负载均衡策略没有效果）：（AbstractClusterInvoker #select）
5. TripleInvoker #doInvoke()
6. DefaultFuture2 #received
## Related Proposals
+
[Proxyless Mesh]()
+
## Proposal
### ThinSDK 改造方案
+
#### 应用启动
-1. Dubbo应用进程与Sidecar生命周期对齐，正常启动后，让Sidecar感知到该Endpoint是健康的。
- * 初步方案：Dubbo应用与Sidecar建连，并且发送POST /healthcheck/ok。**这里具体是往哪个端口和地址发送请求？**
- * 运行态：通过健康检查来保活
-2. Dubbo应用优雅下线时，需要能够让Sidecar感知到该Endpoint下线了。（应用所在的Container原地热升级、应用优雅下线等场景）
- * 初步方案：发送POST /healthcheck/fail
+1. Dubbo 应用进程与 Sidecar 生命周期对齐，正常启动后，让 Sidecar 感知到该 Endpoint 是健康的。
+
+- 初步方案：Dubbo 应用与 Sidecar 建连，并且发送 POST /healthcheck/ok。**这里具体是往哪个端口和地址发送请求？**
+- 运行态：通过健康检查来保活
-3. 在启动过程中，除了生命周期对齐以外，其他主要需要做缩减的动作，对mesh主流程影响不大。
+2. Dubbo 应用优雅下线时，需要能够让 Sidecar 感知到该 Endpoint 下线了。（应用所在的 Container 原地热升级、应用优雅下线等场景）
+
+- 初步方案：发送 POST /healthcheck/fail
+
+3. 在启动过程中，除了生命周期对齐以外，其他主要需要做缩减的动作，对 mesh 主流程影响不大。
#### 健康检查
-运行态，通过envoy的健康检查来保证Dubbo应用是否正常。目前Triple协议基于gRPC的Health接口实现健康检查。需要支持Envoy的HTTP健康检查Filter：
-* 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
+
+运行态，通过 envoy 的健康检查来保证 Dubbo 应用是否正常。目前 Triple 协议基于 gRPC 的 Health 接口实现健康检查。需要在 Consumer 端侧的 Envoy 配置 EnvoyFilter 支持 HTTP 健康检查 Filter，对其上游集群 provider 做主动健康检查(GRPC)：
+
+- [参考 EnvoyFilter 配置](https://github.com/apache/dubbo-samples/blob/master/dubbo-samples-mesh-k8s/deploy/EnvoyFilter.yml)
+- 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
补充：
-1. 使用grpc的Health来做健康检查。Triple现在是支持Health服务的。
-2. Dubbo会开启如下默认端口 Triple: 50051、Metadata : 20880、Qos: 22222，后续要做端口复用，以后在一个端口上提供了Triple协议和QOS协议，在QOS基础上支持REST的/health，这样/health就自动集成进去了。
-3. 使用 https://github.com/grpc-ecosystem/grpc-health-probe 验证gRPC 服务的健康状况。
+1. 使用 grpc 的 Health 来做健康检查。Triple 现在是支持 Health 服务的。
+2. Dubbo 会开启如下默认端口 Triple: 50051、Metadata : 20880、Qos: 22222，后续要做端口复用，以后在一个端口上提供了 Triple 协议和 QOS 协议，在 QOS 基础上支持 REST 的/health，这样/health 就自动集成进去了。
#### 服务注册
-istio中所支持的注册中心中成熟度最高的是Kubernetes，第一阶段推荐使用Kubernetes Registry，Kubernetes 调度的服务将自动被Istion识别所以第一阶段暂不需要做额外操作。
-Dubbo项目目前已经有SPI扩展K8S注册中心解决方案，地址：https://github.com/apache/dubbo-spi-extensions/tree/master/dubbo-registry-extensions/dubbo-registry-kubernetes ，官方提供的dubbo-samples- kubernetes是dubbo协议的，由于mesh方案是基于Tripple协议，所以将其改造成Tripple协议，以protobuf交互，代码已推送至github：https://github.com/conghuhu/dubbo-samples-K8S-tri 。
-> 应用如何配置？指定哪个协议的注册中心扩展
-> 框架如何改造？框架内的行为与流程是怎样的
+istio 中所支持的注册中心中成熟度最高的是 Kubernetes，第一阶段推荐使用 Kubernetes Registry，Kubernetes 调度的服务将自动被 Istio 识别所以第一阶段暂不需要做额外操作。
+
+将注册中心配置为 N/A，不需要额外的注册中心。
+
+```properties
+dubbo.registry.address=N/A
+```
#### 服务发现
-服务发现需要解决的问题是如何触发数据面的服务发现。目前Pilot的操作是在集群第一次启动时从Kubernetes中发现全量的Service、Workload数据，并将这些服务发现数据通过xDS下发给Envoy（Pilot-Agent）实例，后续则以增量的方式推送。
-
+服务发现需要解决的问题是如何触发数据面的服务发现。目前 Pilot 的操作是在集群第一次启动时从 Kubernetes 中发现全量的 Service、Workload 数据，并将这些服务发现数据通过 xDS 下发给 Envoy（Pilot-Agent）实例，后续则以增量的方式推送。
-> 应用如何配置？指定哪个协议的注册中心扩展
-> 框架如何改造？框架内的行为与流程是怎样的
+
#### 服务调用
-Isito官网给出的BookInfo demo中，微服务之间的调用方式，可以看到使用K8S的服务名作为主机名即可。
+
+Isito 官网给出的 BookInfo demo 中，微服务之间的调用方式，可以看到使用 K8S 的服务名作为主机名即可。
-1. 解决Dubbo SDK的请求如何代理给sidecar？
- * sdk的RPC请求转换为类似如下格式的请求动作：http://demo.default.svc.cluster.local:50051. 其中，demo为当前接口对应的 app-name，default为当前的namespace。
- * 避免dubbo之前的 Cluster 选址等问题
+1. 解决 Dubbo SDK 的请求如何代理给 sidecar？
+
+- sdk 的 RPC 请求转换为类似如下格式的请求动作：http://demo.default.svc.cluster.local:50051. 其中，demo 为当前接口对应的 app-name，default 为当前的 namespace。
+- 避免 dubbo 之前的 Cluster 选址等问题
+
+ 目前对 consumer 端增加 meshEnable 和 providerPort 配置，跑通基础的 mesh 模式，代码[dubbo mesh demo](https://github.com/apache/dubbo-samples/tree/master/dubbo-samples-mesh-k8s)
2. 第二阶段工作（路由等流量治理接入）
-负载均衡策略的对接：交由Sidecar来做：
- * envoy支持的负载均衡策略：https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers
- * 服务路由：路由规则的存储，将Kubernetes API Server作为Config Store，注册Kubernetes CRD资源来作为路由规则的存储。通过RDS下发路由规则到Sidecar，由Sidecar来做服务路由。
- * 涉及到现有的路由规则如何迁移到istio中路由规则管控的问题。
+负载均衡策略的对接：交由 Sidecar 来做：
+
+- envoy 支持的负载均衡策略：https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/upstream/load_balancing/load_balancers
+- 服务路由：路由规则的存储，将 Kubernetes API Server 作为 Config Store，注册 Kubernetes CRD 资源来作为路由规则的存储。通过 RDS 下发路由规则到 Sidecar，由 Sidecar 来做服务路由。
+- 涉及到现有的路由规则如何迁移到 istio 中路由规则管控的问题。
+
+目前 triple 协议默认的 header：
-目前triple协议默认的header：
```bash
[
:scheme: http,
@@ -109,23 +136,26 @@ tri-consumer-appname: dubbo-demo-triple-api-consumer
```
在进行服务调用时：
- * :authority会被识别成一个virtual host，需要适配成如demo.default.svc.cluster.local:50051标准格式。
- * 需要支持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
+- :authority 会被识别成一个 virtual host，需要适配成如 demo.default.svc.cluster.local:50051 标准格式。
+- 需要支持 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
### 其他事项：
-* 优雅下线的时候已经有相关的逻辑。
-* 接口级别的服务注册对接sidecar
-* 多实例：应用。
-* 没有mesh 迁移到mesh的方案
-* gRPC 相关的支持内容调研
-### 2022.5.19会议记录：
+- 优雅下线的时候已经有相关的逻辑。
+- 接口级别的服务注册对接 sidecar
+- 多实例应用。
+- 没有 mesh 迁移到 mesh 的方案
+- gRPC 相关的支持内容调研
+- 目前 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调用。
+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 调用。