search

alibaba / higress

🤖 AI Gateway | AI Native API Gateway
https://higress.io
Apache License 2.0
3.16k stars 500 forks source link

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

Open wuchencm opened 1 year ago

wuchencm commented 1 year ago

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

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

johnlanni commented 1 year ago

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

wuchencm commented 1 year ago

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

johnlanni commented 1 year ago

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

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

 准确的讲是gateway为发现的服务生成了路由
CH3CHO commented 1 year ago 
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 commented 1 year ago

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

wuchencm commented 1 year ago

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

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

johnlanni commented 1 year ago

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

CH3CHO commented 1 year ago

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

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

johnlanni commented 1 year ago

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

johnlanni commented 1 year ago

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

CH3CHO commented 1 year ago

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

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

CH3CHO commented 1 year ago

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

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

CH3CHO commented 1 year ago

image

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

wuchencm commented 1 year ago

image

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

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

CH3CHO commented 1 year ago

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

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

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

wuchencm commented 1 year ago

image 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 commented 1 year ago

image 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 commented 1 year ago

image 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 commented 1 year ago

image 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 commented 1 year ago

image 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 commented 1 year ago

总结一下这个需求：

  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 commented 1 year ago

总结一下这个需求：

  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 commented 1 year ago

总结一下这个需求：

  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等等

这个现在就是支持的。

image

CH3CHO commented 1 year ago

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

johnlanni commented 1 year ago

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

2456868764 commented 1 year ago

please assign it to me

carrypann commented 10 months ago

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

lcfang commented 9 months ago

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

CH3CHO commented 9 months ago

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

@carrypann is there any progress on this task?

lcfang commented 9 months ago

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

johnlanni commented 8 months ago

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

hoocoo commented 7 months ago

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

CH3CHO commented 7 months ago

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

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