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
commit eaa31e884b20a1ff16f075c5a93e8fde3b67928f Author: ken.lj <[email protected]> AuthorDate: Fri May 20 10:46:48 2022 +0800 Update D3.1-thinsdk-sidecar-mesh.md --- proposals/D3.1-thinsdk-sidecar-mesh.md | 68 +++++++++++++++++++--------------- 1 file changed, 39 insertions(+), 29 deletions(-) diff --git a/proposals/D3.1-thinsdk-sidecar-mesh.md b/proposals/D3.1-thinsdk-sidecar-mesh.md index a90987d..0eddd25 100644 --- a/proposals/D3.1-thinsdk-sidecar-mesh.md +++ b/proposals/D3.1-thinsdk-sidecar-mesh.md @@ -43,52 +43,62 @@ ### 四大流程涉及的改造点 #### 应用启动 +Dubbo应用进程与Sidecar生命周期对齐，正常启动后，让Sidecar感知到该Endpoint是健康的。 + * 初步方案：Dubbo应用与Sidecar建连，并且发送POST /healthcheck/ok。**这里具体是往哪个端口和地址发？** + * 运行态：通过健康检查来保活 -● Dubbo应用进程与Sidecar生命周期对齐 -○ 正常启动后，让Sidecar感知到该Endpoint是健康的。 -■ 初步方案：Dubbo应用与Sidecar建连，并且发送POST /healthcheck/ok -○ 运行态：通过健康检查来保活 -○ Dubbo应用优雅下线时，需要能够让Sidecar感知到该Endpoint下线了。（应用所在的Container原地热升级、应用优雅下线等场景） -■ 初步方案：发送POST /healthcheck/fail -● 在启动过程中，除了生命周期对齐以外，其他主要需要做缩减的动作，对mesh主流程影响不大。 +Dubbo应用优雅下线时，需要能够让Sidecar感知到该Endpoint下线了。（应用所在的Container原地热升级、应用优雅下线等场景） + * 初步方案：发送POST /healthcheck/fail + +在启动过程中，除了生命周期对齐以外，其他主要需要做缩减的动作，对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 +* 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 + + #### 服务注册 -istio中所支持的注册中心中成熟度最高的是Kubernetes，第一阶段推荐使用Kubernetes Registry。目前已经有Kubernetes Registry的实现，主要以 CRD 的方式存储到 Kubernetes 的 etcd 中： -● 元数据内容存储在annotation中。 -● 应用名对应 Kubernetes service模型。 -● hosts：{IDL service name}.{namespace}.svc.cluster.local -但是对于Kubernetes 服务注册还缺少了许多内容，应用级别的服务注册需要考虑interface name与应用名称的映射关系，除此之外还有自定义label、namespace等。需要增加对外的配置。 +istio中所支持的注册中心中成熟度最高的是Kubernetes，第一阶段推荐使用Kubernetes Registry，Kubernetes 调度的服务将自动被Istion识别所以第一阶段暂不需要做额外操作。 + +> 应用如何配置？指定哪个协议的注册中心扩展 +> 框架如何改造？框架内的行为与流程是怎样的 + #### 服务发现 服务发现需要解决的问题是如何触发数据面的服务发现。目前Pilot的操作是在集群第一次启动时从Kubernetes中发现全量的Service、Workload数据，并将这些服务发现数据通过xDS下发给Envoy（Pilot-Agent）实例，后续则以增量的方式推送。 + 在服务发现阶段，Dubbo应用仅仅与Envoy进行建连，并没有发起任何订阅的行为。 + + +> 应用如何配置？指定哪个协议的注册中心扩展 +> 框架如何改造？框架内的行为与流程是怎样的 + #### 服务调用 -● 负载均衡策略的对接：交由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： +解决Dubbo SDK的请求如何代理给sidecar？ + * sdk的RPC请求转换为类似如下格式的请求动作：http://demo.default.svc.cluster.local:50051。其中，demo为当前接口对应的 app-name + * 避免dubbo之前的 Cluster 选址等问题 -[:scheme: http, :method: POST, :path: /org.apache.dubbo.demo.GreeterService/sayHello, :authority: 127.0.0.1:50051, grpc-accept-encoding: gzip, te: trailers, content-type: application/grpc+proto, tri-consumer-appname: dubbo-demo-triple-api-consumer] +第二阶段工作（路由等流量治理接入） -● 在进行服务调用时： -○ :authority会被识别成一个virtual host，需要适配 -○ 需要支持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来做： + * 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： + +[:scheme: http, :method: POST, :path: /org.apache.dubbo.demo.GreeterService/sayHello, :authority: 127.0.0.1:50051, grpc-accept-encoding: gzip, te: trailers, content-type: application/grpc+proto, tri-consumer-appname: dubbo-demo-triple-api-consumer] +在进行服务调用时： + * :authority会被识别成一个virtual host，需要适配 + * 需要支持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 相关的支持内容调研 \ No newline at end of file +gRPC 相关的支持内容调研
