Open wuchencm opened 1 year ago
现在是用的 spring cloud gateway,配置也放到 Nacos 上了吗,对应的配置是怎样的,我在想是否让 Higress 兼容对应的配置
使用的是springcloud gateway,服务注册跟配置都是使用的nacos,gateway根据request path自动生成动态路由,服务都是注册到public命名空间下的
@wuchencm 我看了下 spring cloud gateway 貌似不支持这样的配置,是你们自己写了 FIlter 实现的吧?
discovery:
locator:
#自动为每一发现的服务生成路由:/serviceId/**,并转发请求时删除/serviceId前缀
enabled: true
#serviceId使用小写字符
lower-case-service-id: true
准确的讲是gateway为发现的服务生成了路由
discovery: locator: #自动为每一发现的服务生成路由:/serviceId/**,并转发请求时删除/serviceId前缀 enabled: true #serviceId使用小写字符 lower-case-service-id: true
准确的讲是gateway为发现的服务生成了路由
应该是这里说的 DiscoveryClient Route Definition Locator 功能:https://cloud.spring.io/spring-cloud-gateway/multi/multi__configuration.html#_discoveryclient_route_definition_locator
@wuchencm 这里的 serviceId 是基于什么获取的,注册到 nacos 时是不是就是命名空间下的服务名称?
@wuchencm 这里的 serviceId 是基于什么获取的,注册到 nacos 时是不是就是命名空间下的服务名称?
是的,gateway所在命名空间下的其他服务名称
@wuchencm 这个Higress是可以实现的,在McpBridge里监听Nacos中的服务信息时,目前只转换成ServiceEntry,通过一个开关可以转换为VirtualService就可以了。控制台交互类似,cc @CH3CHO :
@wuchencm 这个Higress是可以实现的,在McpBridge里监听Nacos中的服务信息时,目前只转换成ServiceEntry,通过一个开关可以转换为VirtualService就可以了。控制台交互类似,cc @CH3CHO :
感觉是不是放到路由下面好一点呢?它属于一种特殊的路由类型,关联一个服务来源而不是服务
@CH3CHO 实现上我觉得还是跟着 McpBridge 走,不跟着 Ingress,但是交互上可以考虑放到路由里
放到服务来源里也说的通,因为是通过关联服务来源自动生成路由
@CH3CHO 实现上我觉得还是跟着 McpBridge 走,不跟着 Ingress,但是交互上可以考虑放到路由里
嗯,这个我理解,就是增加一个创建动态路由的功能,配置写到McpBridge里,但界面放到路由管理里。这个我界面设计一下先,等Controller那边支持了再做界面。
放到服务来源里也说的通,因为是通过关联服务来源自动生成路由
对用户来说他应该管理的还是路由吧,所有路由相关的应该都展示在路由管理里,虽然其实关联的是服务来源。
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
有些特殊情况下,path跟serverName并不是一致的:能举个例子吗?
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
有些特殊情况下,path跟serverName并不是一致的:能举个例子吗?
这个跟业务历程有关,比如: 场景1:gateway.abc.com/order/add,访问order服务的/add接口 场景2:gateway.abc.com/pay/add,访问pay服务的/pay/add接口 场景3:gateway.abc.com/warehouse/add, 访问ware-house的/add 接口
当然以上问题跟使用规范有关,但是现实情况,有些系统是有“历史问题“的,如果不支持自定义配置的化,那调用方或者服务提供者需要修改接口地址
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
有些特殊情况下,path跟serverName并不是一致的:能举个例子吗?
这个跟业务历程有关,比如: 场景1:gateway.abc.com/order/add,访问order服务的/add接口 场景2:gateway.abc.com/pay/add,访问pay服务的/pay/add接口 场景3:gateway.abc.com/warehouse/add, 访问ware-house的/add 接口
当然以上问题跟使用规范有关,但是现实情况,有些系统是有“历史问题“的,如果不支持自定义配置的化,那调用方或者服务提供者需要修改接口地址
这种情况是不是就应该做人工路由配置,而不是自动从注册中心生成路由了呢?
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
有些特殊情况下,path跟serverName并不是一致的:能举个例子吗?
这个跟业务历程有关,比如: 场景1:gateway.abc.com/order/add,访问order服务的/add接口 场景2:gateway.abc.com/pay/add,访问pay服务的/pay/add接口 场景3:gateway.abc.com/warehouse/add, 访问ware-house的/add 接口 当然以上问题跟使用规范有关,但是现实情况,有些系统是有“历史问题“的,如果不支持自定义配置的化,那调用方或者服务提供者需要修改接口地址
这种情况是不是就应该做人工路由配置,而不是自动从注册中心生成路由了呢?
是的,自定义配置大于默认生成
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
有些特殊情况下,path跟serverName并不是一致的:能举个例子吗?
这个跟业务历程有关,比如: 场景1:gateway.abc.com/order/add,访问order服务的/add接口 场景2:gateway.abc.com/pay/add,访问pay服务的/pay/add接口 场景3:gateway.abc.com/warehouse/add, 访问ware-house的/add 接口 当然以上问题跟使用规范有关,但是现实情况,有些系统是有“历史问题“的,如果不支持自定义配置的化,那调用方或者服务提供者需要修改接口地址
这种情况是不是就应该做人工路由配置,而不是自动从注册中心生成路由了呢?
是的,自定义配置大于默认生成
如果手动配置了 gateway.abc.com/warehouse 指向 ware-house 服务的话,那是否仍可以通过 gateway.abc.com/ware-house 请求这一服务呢?
SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的,我们这里需要支持自定义吗? @johnlanni
建议自定义大于动态路由,有些特殊情况下,path跟serverName并不是一致的。个人愚见~
有些特殊情况下,path跟serverName并不是一致的:能举个例子吗?
这个跟业务历程有关,比如: 场景1:gateway.abc.com/order/add,访问order服务的/add接口 场景2:gateway.abc.com/pay/add,访问pay服务的/pay/add接口 场景3:gateway.abc.com/warehouse/add, 访问ware-house的/add 接口 当然以上问题跟使用规范有关,但是现实情况,有些系统是有“历史问题“的,如果不支持自定义配置的化,那调用方或者服务提供者需要修改接口地址
这种情况是不是就应该做人工路由配置,而不是自动从注册中心生成路由了呢?
是的,自定义配置大于默认生成
如果手动配置了 gateway.abc.com/warehouse 指向 ware-house 服务的话,那是否仍可以通过 gateway.abc.com/ware-house 请求这一服务呢?
可以的,这是两个不同的路由,尽管它们都指向了同一个后端服务 走自定义配置:gateway.abc.com/warehouse/ruleAdd ---->ware-house(服务名)/ruleAdd(接口地址) 没有自定义配置,走默认:gateway.abc.com/ware-house/ruleAdd ----->ware-house(服务名)/ruleAdd(接口地址)
总结一下这个需求:
sample-service.DEFAULT-GROUP.public.nacos
中的.DEFAULT-GROUP.public.nacos
就是服务来源自身的后缀。但这种情况下,如果一个服务来源监听了多个 NS 和 Group 的话可能会出现冲突;请 @wuchencm 看一下我的理解是否正确。
总结一下这个需求:
- 支持为服务来源配置路由,支持自定义域名;
- Path 仅支持前缀匹配。在进行路由匹配时,会自动将用户配置的前缀后面的一段 Path 中视为 ServiceID ,并进行路由。例如:若前缀配置为 /,请求 Path 为 /orderservice/getOrderById 时,ServiceID 为 orderservice;若前缀配置为 /api,请求 Path 为 /api/userservice/login 时,ServiceID 为 userservice;
- 默认情况下,服务来源路由自动带有一个 Rewrite 规则,会移除 含 ServiceID 在内的 Path 前缀。用户可以自定义这一配置;
- 在匹配 ServiceID 时应忽略服务来源自身的后缀,例如
sample-service.DEFAULT-GROUP.public.nacos
中的.DEFAULT-GROUP.public.nacos
就是服务来源自身的后缀。但这种情况下,如果一个服务来源监听了多个 NS 和 Group 的话可能会出现冲突;- 同一个域名下可以同时配置关联服务来源和关联服务的路由。当二者同时存在且 Path 存在重叠时,关联服务的路由优先级更高。
请 @wuchencm 看一下我的理解是否正确。
是的,这样基本上覆盖了上面沟通的所有情况,关于第4点,最好支持namespace的自定义,因为有些人的使用,并不一定都是public namespace,比如所有的服务都注册到了pro namespace等等
总结一下这个需求:
- 支持为服务来源配置路由,支持自定义域名;
- Path 仅支持前缀匹配。在进行路由匹配时,会自动将用户配置的前缀后面的一段 Path 中视为 ServiceID ,并进行路由。例如:若前缀配置为 /,请求 Path 为 /orderservice/getOrderById 时,ServiceID 为 orderservice;若前缀配置为 /api,请求 Path 为 /api/userservice/login 时,ServiceID 为 userservice;
- 默认情况下,服务来源路由自动带有一个 Rewrite 规则,会移除 含 ServiceID 在内的 Path 前缀。用户可以自定义这一配置;
- 在匹配 ServiceID 时应忽略服务来源自身的后缀,例如
sample-service.DEFAULT-GROUP.public.nacos
中的.DEFAULT-GROUP.public.nacos
就是服务来源自身的后缀。但这种情况下,如果一个服务来源监听了多个 NS 和 Group 的话可能会出现冲突;- 同一个域名下可以同时配置关联服务来源和关联服务的路由。当二者同时存在且 Path 存在重叠时,关联服务的路由优先级更高。
请 @wuchencm 看一下我的理解是否正确。
是的,这样基本上覆盖了上面沟通的所有情况,关于第4点,最好支持namespace的自定义,因为有些人的使用,并不一定都是public namespace,比如所有的服务都注册到了pro namespace等等
这个现在就是支持的。
请 @johnlanni 评估一下这个需求吧。
需求挺合理的,可以实现,我已经加上 help wanted 标签,看看有没有社区同学有兴趣认领
please assign it to me
@CH3CHO @2456868764 Is there any progress on this task? I'm willing to contribute if needed.
想了解下,这个功能现在在做了吗?
想了解下,这个功能现在在做了吗?
@carrypann is there any progress on this task?
要是还没做的话我来做吧?
这个需求有个问题,动态创建的路由在什么情况下退场呢,如果没有退场机制会有路由配置泄漏的问题
@CH3CHO 这个需求有计划什么时候上吗?
@CH3CHO 这个需求有计划什么时候上吗?
@lcfang ,请问现在进展如何了?
基于Nacos服务注册中心,我们的服务选择都是根据请求的path(路径)来生成动态路由的,这样免去了人工配置静态路由的工作。
例如: 当请求 https://gateway.abc.com/order 时,网关会自动去nacos上寻找服务为order的实例列表,且不需要提前配置/order路由,即约定路径order选择order服务,当然有静态路由配置的时候,静态配置要大于约定配置。