基于请求路径的动态路由功能支持

[wuchencm]

基于Nacos服务注册中心，我们的服务选择都是根据请求的path（路径）来生成动态路由的，这样免去了人工配置静态路由的工作。

例如：
当请求 https://gateway.abc.com/order 时，网关会自动去nacos上寻找服务为order的实例列表，且不需要提前配置/order路由，即约定路径order选择order服务，当然有静态路由配置的时候，静态配置要大于约定配置。

[johnlanni]

现在是用的 spring cloud gateway，配置也放到 Nacos 上了吗，对应的配置是怎样的，我在想是否让 Higress 兼容对应的配置

[wuchencm]

使用的是springcloud gateway，服务注册跟配置都是使用的nacos，gateway根据request path自动生成动态路由，服务都是注册到public命名空间下的

[johnlanni]

@wuchencm 我看了下 spring cloud gateway 貌似不支持这样的配置，是你们自己写了 FIlter 实现的吧？

[wuchencm]

discovery:
        locator:
          #自动为每一发现的服务生成路由：/serviceId/**，并转发请求时删除/serviceId前缀
          enabled: true
          #serviceId使用小写字符
          lower-case-service-id: true
          

 准确的讲是gateway为发现的服务生成了路由

[CH3CHO]

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

[johnlanni]

@wuchencm 这里的 serviceId 是基于什么获取的，注册到 nacos 时是不是就是命名空间下的服务名称？

[wuchencm]

@wuchencm 这里的 serviceId 是基于什么获取的，注册到 nacos 时是不是就是命名空间下的服务名称？

是的，gateway所在命名空间下的其他服务名称

[johnlanni]

@wuchencm 这个Higress是可以实现的，在McpBridge里监听Nacos中的服务信息时，目前只转换成ServiceEntry，通过一个开关可以转换为VirtualService就可以了。控制台交互类似，cc @CH3CHO ：

[CH3CHO]

@wuchencm 这个Higress是可以实现的，在McpBridge里监听Nacos中的服务信息时，目前只转换成ServiceEntry，通过一个开关可以转换为VirtualService就可以了。控制台交互类似，cc @CH3CHO ：

感觉是不是放到路由下面好一点呢？它属于一种特殊的路由类型，关联一个服务来源而不是服务

[johnlanni]

@CH3CHO 实现上我觉得还是跟着 McpBridge 走，不跟着 Ingress，但是交互上可以考虑放到路由里

[johnlanni]

放到服务来源里也说的通，因为是通过关联服务来源自动生成路由

[CH3CHO]

@CH3CHO 实现上我觉得还是跟着 McpBridge 走，不跟着 Ingress，但是交互上可以考虑放到路由里

嗯，这个我理解，就是增加一个创建动态路由的功能，配置写到McpBridge里，但界面放到路由管理里。这个我界面设计一下先，等Controller那边支持了再做界面。

[CH3CHO]

放到服务来源里也说的通，因为是通过关联服务来源自动生成路由

对用户来说他应该管理的还是路由吧，所有路由相关的应该都展示在路由管理里，虽然其实关联的是服务来源。

[CH3CHO]

SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的，我们这里需要支持自定义吗？ @johnlanni

[wuchencm]

SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的，我们这里需要支持自定义吗？ @johnlanni

建议自定义大于动态路由，有些特殊情况下，path跟serverName并不是一致的。个人愚见~

[CH3CHO]

SCG 里是支持自定义动态路由的 Path 和 Rewrite 规则的，我们这里需要支持自定义吗？ @johnlanni

建议自定义大于动态路由，有些特殊情况下，path跟serverName并不是一致的。个人愚见~

有些特殊情况下，path跟serverName并不是一致的：能举个例子吗？

[wuchencm]

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 接口

当然以上问题跟使用规范有关，但是现实情况，有些系统是有“历史问题“的，如果不支持自定义配置的化，那调用方或者服务提供者需要修改接口地址

[CH3CHO]

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 接口

当然以上问题跟使用规范有关，但是现实情况，有些系统是有“历史问题“的，如果不支持自定义配置的化，那调用方或者服务提供者需要修改接口地址

这种情况是不是就应该做人工路由配置，而不是自动从注册中心生成路由了呢？

[wuchencm]

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 接口
当然以上问题跟使用规范有关，但是现实情况，有些系统是有“历史问题“的，如果不支持自定义配置的化，那调用方或者服务提供者需要修改接口地址

这种情况是不是就应该做人工路由配置，而不是自动从注册中心生成路由了呢？

是的，自定义配置大于默认生成

[CH3CHO]

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 请求这一服务呢？

[wuchencm]

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(接口地址)

[CH3CHO]

总结一下这个需求：

1. 支持为服务来源配置路由，支持自定义域名；
2. Path 仅支持前缀匹配。在进行路由匹配时，会自动将用户配置的前缀后面的一段 Path 中视为 ServiceID ，并进行路由。例如：若前缀配置为 /，请求 Path 为 /orderservice/getOrderById 时，ServiceID 为 orderservice；若前缀配置为 /api，请求 Path 为 /api/userservice/login 时，ServiceID 为 userservice；
3. 默认情况下，服务来源路由自动带有一个 Rewrite 规则，会移除 含 ServiceID 在内的 Path 前缀。用户可以自定义这一配置；
4. 在匹配 ServiceID 时应忽略服务来源自身的后缀，例如 sample-service.DEFAULT-GROUP.public.nacos 中的.DEFAULT-GROUP.public.nacos 就是服务来源自身的后缀。但这种情况下，如果一个服务来源监听了多个 NS 和 Group 的话可能会出现冲突；
5. 同一个域名下可以同时配置关联服务来源和关联服务的路由。当二者同时存在且 Path 存在重叠时，关联服务的路由优先级更高。

请 @wuchencm 看一下我的理解是否正确。

[wuchencm]

总结一下这个需求：

1. 支持为服务来源配置路由，支持自定义域名；
2. Path 仅支持前缀匹配。在进行路由匹配时，会自动将用户配置的前缀后面的一段 Path 中视为 ServiceID ，并进行路由。例如：若前缀配置为 /，请求 Path 为 /orderservice/getOrderById 时，ServiceID 为 orderservice；若前缀配置为 /api，请求 Path 为 /api/userservice/login 时，ServiceID 为 userservice；
3. 默认情况下，服务来源路由自动带有一个 Rewrite 规则，会移除 含 ServiceID 在内的 Path 前缀。用户可以自定义这一配置；
4. 在匹配 ServiceID 时应忽略服务来源自身的后缀，例如 sample-service.DEFAULT-GROUP.public.nacos 中的.DEFAULT-GROUP.public.nacos 就是服务来源自身的后缀。但这种情况下，如果一个服务来源监听了多个 NS 和 Group 的话可能会出现冲突；
5. 同一个域名下可以同时配置关联服务来源和关联服务的路由。当二者同时存在且 Path 存在重叠时，关联服务的路由优先级更高。

请 @wuchencm 看一下我的理解是否正确。

是的，这样基本上覆盖了上面沟通的所有情况，关于第4点，最好支持namespace的自定义，因为有些人的使用，并不一定都是public namespace，比如所有的服务都注册到了pro namespace等等

[CH3CHO]

总结一下这个需求：

1. 支持为服务来源配置路由，支持自定义域名；
2. Path 仅支持前缀匹配。在进行路由匹配时，会自动将用户配置的前缀后面的一段 Path 中视为 ServiceID ，并进行路由。例如：若前缀配置为 /，请求 Path 为 /orderservice/getOrderById 时，ServiceID 为 orderservice；若前缀配置为 /api，请求 Path 为 /api/userservice/login 时，ServiceID 为 userservice；
3. 默认情况下，服务来源路由自动带有一个 Rewrite 规则，会移除 含 ServiceID 在内的 Path 前缀。用户可以自定义这一配置；
4. 在匹配 ServiceID 时应忽略服务来源自身的后缀，例如 sample-service.DEFAULT-GROUP.public.nacos 中的.DEFAULT-GROUP.public.nacos 就是服务来源自身的后缀。但这种情况下，如果一个服务来源监听了多个 NS 和 Group 的话可能会出现冲突；
5. 同一个域名下可以同时配置关联服务来源和关联服务的路由。当二者同时存在且 Path 存在重叠时，关联服务的路由优先级更高。

请 @wuchencm 看一下我的理解是否正确。

是的，这样基本上覆盖了上面沟通的所有情况，关于第4点，最好支持namespace的自定义，因为有些人的使用，并不一定都是public namespace，比如所有的服务都注册到了pro namespace等等

这个现在就是支持的。

[CH3CHO]

请 @johnlanni 评估一下这个需求吧。

[johnlanni]

需求挺合理的，可以实现，我已经加上 help wanted 标签，看看有没有社区同学有兴趣认领

[2456868764]

please assign it to me

[carrypann]

@CH3CHO @2456868764 Is there any progress on this task? I'm willing to contribute if needed.

[lcfang]

想了解下，这个功能现在在做了吗？

[CH3CHO]

想了解下，这个功能现在在做了吗？

@carrypann is there any progress on this task?

[lcfang]

要是还没做的话我来做吧？

[johnlanni]

这个需求有个问题，动态创建的路由在什么情况下退场呢，如果没有退场机制会有路由配置泄漏的问题

[hoocoo]

@CH3CHO 这个需求有计划什么时候上吗？

[CH3CHO]

@CH3CHO 这个需求有计划什么时候上吗？

@lcfang ，请问现在进展如何了？