服务网关在微服务拆分过程中,进行流量转发是一个比较常规的操作。
如果使用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/(?<segment>.*), /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