- Create MigrationTool console app for exporting DB config to K8s YAML - Support dry-run mode and validation - Add Npgsql and YamlDotNet dependencies
23 lines
1.9 KiB
Markdown
23 lines
1.9 KiB
Markdown
#### 网关配置的新想法
|
||
|
||
路由/集群/目标 等配置还是通过数据库变更通知网关进行重新加载的方式触发变更
|
||
|
||
k8s 的service中需要有固定的label来约定产生新的配置
|
||
以下是范例
|
||
service-label
|
||
- app-router-host = https://hostname #代表网关域名地址
|
||
- app-router-name = member # 代表路由名
|
||
- app-router-prefix = /member # 代表路由前缀
|
||
- app-cluster-name = member #代表集群名(id)
|
||
- app-cluster-destination = default # 代表标准服务目标 如果不是default 比如 1668 则代表企业编号独有的目标
|
||
详细请求说明:
|
||
比如一个请求进来了 请求路径是 {host}/member/api/v1/memberinfo/{id} header:{authorization: bearer xxx}
|
||
-> 根据 host+ prefix匹配到 member路由 -> 进入到对应的cluster ->
|
||
中间件进行解析或者是yarp-transform能做到最好使用yarp-transform来处理 或者如果我集成了openiddict是否可以拿到jwt这部分的信息
|
||
-> 解析出 customer/或者是租户id都行 只要能表示租户的都算 -> 找到对应的租户就进对应的目标服务 找不到就进 标准服务目标
|
||
|
||
配置生效详细说明:
|
||
1.在console项目中监听k8s 的服务 如果发现有新的app-router-name 相关信息就要产生待执行配置 用户明确确认后 生成数据库配置 在此之前只能存在于内存/缓存中 ;
|
||
2.同样的监听服务 发现app-cluster-name 检查是否有新的app-cluster-name 如果有新的 同样产生待执行配置 后续于路由一致
|
||
3.同样监听服务 发现app-cluster-destination 检查对应的cluster是否存在这个destination 如果不存在 同样产生待执行配置 后续与上述一致
|
||
4.用户确认是否执行这些配置 用户加载到界面后可调整配置,同意后产生持久化数据到数据库,点击立即生效才下发到yarp网关 网关重新根据新的配置加载到最新配置后生效 |