Closed CoderPoet closed 1 month ago
Hi, @CoderPoet! I am interested in this proposal, is there anything I could help with?
Hi, @CoderPoet! I am interested in this proposal, is there anything I could help with?
Very welcome, I have drawn you into the working group, we will dismantle some tasks later!
Istio 服务发现是基于 Kubernetes 实现的. Istio 控制面中,Pilot 组件负责管理服务网格内部的服务和流量策略。Pilot 将服务信息和路由策略转换为 xDS 接口的标准数据结构,下发到数据面的 Envoy. 个人理解,如果只是简单的应用开发,其实不用考虑 xDS 协议底层到底做了些什么,“应用” 和 “网络” 做到解耦。过不过kitex 能从底层支持 xDS 协议,是最好不过了,这样更贴近“云原生”,在相关场景下的应用会更广泛。
Istio 服务发现是基于 Kubernetes 实现的. Istio 控制面中,Pilot 组件负责管理服务网格内部的服务和流量策略。Pilot 将服务信息和路由策略转换为 xDS 接口的标准数据结构,下发到数据面的 Envoy. 个人理解,如果只是简单的应用开发,其实不用考虑 xDS 协议底层到底做了些什么,“应用” 和 “网络” 做到解耦。过不过kitex 能从底层支持 xDS 协议,是最好不过了,这样更贴近“云原生”,在相关场景下的应用会更广泛。
嗯嗯,对的,目的就是为了丰富网格数据面部署架构形态,让用户可以在不同场景下有更多更适合特定场景的部署形态选择
另外稍微补充下 Kubernetes 只是 istio 的服务注册及发现的其中一种,并作为默认的 provider 存在,其实还可以对接外部注册中心的哈
目前所有功能基本完成,详见文档,用户如果有问题欢迎提交 Issue 反馈:https://www.cloudwego.io/zh/docs/kitex/tutorials/advanced-feature/xds/
背景
希望 Kitex 能够原生支持 xDS 协议 ,让 Kitex 服务能够以 Proxyless 的模式被服务网格统一纳管,从而丰富网格数据面部署架构形态,让用户可以在不同场景下有更多更适合特定场景的部署形态选择
目标
设计介绍
整体架构
整体主要有几个模块组成:
框架治理能力适配
为了对接治理能力,框架需要做的适配包括以下几部分:
RouterMW
,顺序在内置中间件的第一位(动态路由后才能确定之后的配置)。Resolver
接口实现XdsResolver
,判断服务发现类型,基于 eds 获取实例信息。LoadBalancer
接口实现XdsLoadbalancer
,根据 cds 动态调整负载均衡策略。各种治理能力适配思路如下
1. 服务注册
Istio 虽然本身不提供服务注册中心,但是内部维护了统一的服务模型和服务注册表,并且支持集成两种类型的服务注册中心 Provider
因此,我们在该方案中无需去设计并实现一套服务注册流程了,只需要直接去对接现有的服务注册中心即可。
2. 动态路由
流程大致如下所示:
3. 服务发现
基于 Kitex 的 Resolver 接口,拓展一个 XDSResolver 来进行服务发现。
服务发现类型包括以下几种:
4. 负载均衡
Lb policy 包含在 CDS 内,所以 lb 策略的变化是在动态路由选定 cluster 之后获取并应用的。 Kitex 支持自定义 LoadBalancer,实际上就是根据lb策略,从服务发现获得的实例列表内选取一个实例进行调用。
如果希望动态调整 lb 策略,需要扩展一个 XDSLoadBalancer 。 在 GetPicker 的实现内完成 lb 策略的获取 (CDS),及不同策略的实现。
5. 超时控制
根据 RDS 中的 timeout 配置来动态调整 RPC Timeout Middleware 的 RPCInfo 中的超时时间即可,实现方式:
6. 熔断器
我们这期先支持基础的异常检测熔断策略,大致流程如下:
7. 重试
RDS 中会携带 retry policy 规则,Kitex 可以根据这个动态调整其客户端重试策略