微服务架构-服务网关(Gateway)-路由功能详解

路由功能详解

这一节我们看一看Gateway中的路由是怎么工作的;GateWay网关的路由功能可不是简简单单的 “转发" 请求,在请求到达网关要流转到指定服务之间发生了很多事儿,它不光可以拒绝请求,甚至可以"篡改” 请求的参数,我们接下来就去看看路由这里面的门道。

1、路由三重门

Gateway中可以定义很多个Route,一个Route就是一套包含完整转发规则的路由,主要由三部分组成:
在这里插入图片描述

  • 断言集合: 断言是路由处理的第一个环节,它是路由的匹配规则,它决定了一个网络请求是否可以匹配给当前路由来处理。之所以它是一个集合的原因是我们可以给一个路由添加多个断言,当每个断言都匹配成功以后才算过了路由的第一关。
  • 过滤器集合: 如果请求通过了前面的断言匹配,那就表示它被当前路由正式接手了,接下来这个请求就要经过一系列的过滤器集合。过滤器的功能就是八仙过海各显神通了,可以对当前请求做一系列的操作,比如说权限验证,或者将其他非业务性校验的规则提到网关过滤器这一层。在过滤器这一层依然可以通过修改Response里的Status Code达到中断效果,比如对鉴权失败的访问请求设置Status Code为403之后中断操作;
  • URI: 如果请求顺利通过过滤器的处理,接下来就到了最后一步,那就是转发请求。URL是统一资源标识符,它可以是一个具体的网址,也可以是IP+端口的组合,或者是Eureka中注册的服务名称。

2、关于负载均衡

对最后一步寻址来说,如果采用基于Eureka的服务发现机制,那么在Gateway的转发过程中可以采用服务注册名的方式来调用,后台会借助Ribbon实现负载均衡(可以为某个服务指定具体的负载均衡策略),其配置方式如: lb://FEIGN-SERVICE-PROVIDER/,前面的lb就是指代Ribbon作为LoadBalancer。

3、路由的工作流程

从一个请求到达网关开始,看看Gateway内部流转的过程。

在这里插入图片描述
Predicate Handler: 具体承接类是RoutePredicateHandlerMapping,首先它获取所有的路由(配置的routes全集),然后依次循环每个Route,把应用请求与Route中配置的所有断言进行匹配,如果当前Route所有断言都验证通过,Predict Handler就选定当前的路由,这个模式是典型的职责链。

Filter Handler: 在前一步选中路由后,由FilteringWebHandler将请求交给过滤器,在具体处理过程中,不仅当前Route中定义的过滤器会生效我们在项目中添加的全局过滤器(Global Filter) 也会一同参与。可以看到图中有Pre Filter和Post Filter,这是指过滤器的作用阶段,我们在稍后的章节中再深入了解。

寻址: 这一步将把请求转发到URL指定的地址,在发送请求之前,所有Pre类型过滤器都将被执行,而Post 过滤器会在调用请求返回之后起作用,有关过滤器的详细内容将会在稍后的章节里讲到。