[dubbo-awesome] 34/44: Update D3.1-thinsdk-sidecar-mesh.md

[li...@apache.org]

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 <ke...@gmail.com>
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 相关的支持内容调研