Spring Cloud gateway + nacos 微服务流量转发配置最佳实践

服务网关在微服务拆分过程中，进行流量转发是一个比较常规的操作。
如果使用SpringCloud全家桶，那么流量转发可以使用目前已经存在的gateway组件来实现，同时可以保留gateway灰度实例选择。

版本信息

gateway: 2.2.6.RELEASE
nacos: 1.4.1

先看几组参数：

gateway自动代理nacos上已注册服务

spring:
  cloud:
    gateway:
      discovery:
        locator:
          enabled: true

为什么要讲这个参数呢？
当此参数为true时，表示gateway可以直接去注册中心拉取服务名，这里使用的是nacos，下文全用nacos，自动帮忙转发。例如：
http://localhost:9999/microservice-xx/list，这里microservice-xx即为nacos中注册的服务名，有了此参数，即可将/list流量转到内部服务上进行服务。反之，则无法提供服务。

gateway手动代理内部服务

如果不使用上面的配置进行自动代理，怎么通过gateway访问一个内部微服务呢？例如：

spring:
  cloud:
    gateway:
	   route:
	   	     - id: microService-xx_route
		  uri: lb://microService-xx
		  predicates:
			- Path=/microService-xx/**
		  filters:
			- StripPrefix=1
		  order: 10001

这里：

• id：表示一个唯一的路由规则命名
• uri: 当用lb://开头时，表示一个内部服务，如果是http://开头，则表示一个网络地址，也可以表示一个未接入nacos的其他语言服务
• predicates: 表示一个断言，是否命中此规则
• filters: 这里有好几个参数，例如：StripPrefix=1表示再往下游转发时，去掉第一个目录，如果是2，则表示去掉前2个目录，以此类推。
  这样就以手动配置方式完成内部微服务转发了。

以上区别是什么？

• 手动配置微服务转发更安全一些，如果有一些服务不需要通过gateway对外暴露接口，不配置即可
• 自动配置更方便一些，注册在nacos上，即表示能对外提供服务了
• 如果一个旧的接口被拆到了一个新服务，你又不能通知调用方改接口，则一定要使用手动的方式进行转发，这样才能通过重写url规则的方式将旧接口流量转到新服务，同时保留gateway组件灰度选择新服务的能力

旧接口流量转发新服务

spring:
  cloud:
    gateway:
	   route:
		  - id: rewritepath_xx_to_newXX_route1
		  uri: lb://microservice-new-xx
		  predicates:
			- Path=/microservice-xx/list/**
		  filters:
			- RewritePath=/microservice-xx/list/(?>.*), /microservice-new-xx/list/$\{segment}
			- StripPrefix=1
		  order: 1

这里的意思是当命中/microService-xx/list/**路径时，通过filters的规则将microservice-xx/list的流量转到/microservice-new-xx/list/，其服务名为lb://microservice-new-xx。

几个注意事项：

• order提供的顺序，需要排在微服务选择前面，如果在微服务选择后面，规则不会生效
• 目前测试出来，一个filters只能有一条路径重写规则，如果能实现多条规则，在下面评论告知
• 不能使用自动代理nacos的服务名，即第一条所写的配置，目测原因是自动代理的代码执行优先级更高

参考资料：
https://juejin.cn/post/7170933034248732703