1.服务网关在微服务中的应用
(1)对外提供服务的难题分析:
微服务架构下的应用系统体系很庞大,光是需要独立部署的基础组件就有注册中心、配置中心和服务总线、Turbine异常聚合和监控大盘、调用链追踪器和链路聚合,还有Kaka和MQ之类的中间件,再加上拆分后的零散微服务模块。---个小系统都能轻松弄出20个左右的部署包。
如果采用localhost加端口的方式直接访问,如果这些服务---并都要提供给外部用户访问那该怎么办呢?可以让前端程序员加班加点在各个页面给各种不同请求配置URL和端口号,人不是问题,项目完成就行。也可以我们配一个URL,通过F5或者Nginx可以做路由,话是没错,可是这样就要让运维团队手工维护路由规则表,当我们新增删除节点或者因为更换机房导致IP变化的时候就很麻烦。因此我们需要引入---套机制来降低路由表的维护成本。
还有一个问题就是安全性,我们在提供外部服务的时候往往会加入一些访问控制,比如说下单接口不允许未登录用户的访问,有的服务还会通过一些JWT签名等防止客户端篡改数据。如果让每个服务提供者都实现同样的访问验证逻辑未免有些太繁琐,这样纯属是增加研发人员的怒气值,况且如果有一天我们需要更换权限认证方案,比如更换为OAuth2.0,难不成还要每个服务提供者都做变更?
我们如何对外提供服务,既能管好路由规则,还能做好访问控制呢?在这个背景下,API网关应运而生,接待所有来访请求。
(2)网关层
微服务引入一层专事专办的中间层。
两件事:
1.访问控制,看你是否有权限访问,拒绝未授权的来访者
2.引导指路 问清楚你要办的事,指一条明路。找到对应处理这些事的人
网关层引入后,微服务的架构变成:
网关层作为唯一的对外服务,外部请求不直接访问服务层。由网关层承接所有HTTP
请求,在实际应用中。我们会将Gateway与Nginx一同使用。
(3)访问控制和路由规则
访问控制:
主要包含两个方面的任务,具体的实现并不是由网关层提供的,但是网关作为一个载体承载了两个任务:
拦截请求:有的接口需要登录用户才能访问,对于这类接口的访问,网关层可以检查访问请求中是否携带令牌等身份信息,比兔HTTP Header中的Authorization或者token属性。如果没有携带令牌,说明没登录,可以直接返回403 Forbidden
鉴权:对于携带令牌的服务,我们需要验证令牌的真假,否则用户可以
通过伪造的令牌进行通信,对令牌校验失败的请求,或者令牌已经过期
的请求执行拒绝服务!
路由规则
路由规则包含两个方面,分别是URL映射和服务寻址
URL映射:在大多数情况下,客户端访问的HTTP URL往往不是我们在Controller里配置的真实路径,比如客户端可以发起请求"/password/update"来修改密码,但后台并没有这个服务,这时候就需要网关层做一个路由规则,将来访URL映射成真正的服务路径,比如将刚才的密码修改请求的路径映射到"/user/settings/security/password"请求
服务寻址URL映射:好了之后,网关层就需要找到可以提供服务的服务器地址,对于服务集群的话,还需要实现负载均衡策略。(在Spring Cloud中,Gateway是借助Eureka的服务发现机制来实现服务寻址的,负载均衡则依靠Ribbon)
2.第二代网关组件Gateway介绍
Gateway业务场景:
3.Gateway体系架构解析
(打开Gateway的自动装配工厂,gatewayAutoConfiguration看,第一个就是Netty)
Netty是什么?在网络传输领域Netty就是身份的象征,它是非阻塞、高性能、高可靠的异步输入输出框架,用一个字概括就是"快"。这里我们不对Netty做深入探讨,但是需要了解下Netty在Gateway中主要应用在以下几个地方:
发起服务调用:由NettyRoutingFilter过滤器实现,底层采用基于Netty的HttpClient发起外部服务的调用
Response传输:由NettyResponseFilter过滤器实现,网络请求结束后要将Response回传给调用者
- Socket连接:具体由ReactortNettyWebSocketClient类承接,通过Netty的Httpclient发起连接请求
在Gateway中发起Request和回传Response之类的步骤都是通过一系列过滤翮完成的,有关过滤器的内容将在稍后介绍。
(正常HTTP调用与netty的http调用的区别:
核心区别:javax.servlet.http.HttpServletRequest主要用于服务器端的HTTP请求处理,而Netty的HttpClient用于客户端发起HTTP请求)
Client发起请求到服务网关之后,由NettyRoutingFilter底层的HttpClient(Netty组件)向
服务发起调用,调用结束后,Response有NettyResponseFilter再回传给客户端。有了netty加持,网络请求效率大幅提升!Netty贯穿从Request发起到Response结束的过程,承担了所有网络调用相关的任务
(1)Gateway自动装配:
AutoConfig: 作为核心自动装配主类,GatewayAutoConfiguration负责初始化所有的Route路由规则、Predicate断言工厂和Filter(包括Global Filter和Route Filter),这三样是Gateway吃饭的家伙,用来完成路由功能。AutoConfig也会同时加载Netty配置
LoadBalancerGlient: 这部分在AutoConfig完成之后由GatewayLoadBalancerClientAutoConfiguration负责加载,用来加载Ribbon和一系列负载均衡配置
ClassPathWarning:同样也是在AutoConfig完成之后触发(具体加载类为GatewayClassPathWarningAutoConfiguration),由于Gateway底层依赖Spring WebFlux的实现,所以它会检查项目是否加载了正确配置
Redis:在Gateway中Redis主要负责限流的功能。
除了上面几个核心装配工厂以外,还有两个打酱油的路人,它们并不直接参与Gateway的核心功能,但是会提供---些重要的支持功能:
GatewayMetricsAutoConfiguration:负责做一些统计工作,比如对所谓的"short task"运行时长和调用次数做统计
GatewayDiscoveryClientAutoConfiguration:服务发现客户端自动装配类
爬坑指南
Gateway项目启动出错,但是查来查去,发现也没有什么配置问题。这时候就要看一下是不是引入了错误的依赖,Gateway比较坑的一个地方是它基于WebFlux实现,因此它需要的依赖是spring-boot-starter-webflux,假如我们不小心引入了spring-boot-starter-web将导致启动问题,
由于我们大部分的Spring Cloud项目都依赖spring-boot-starter-web,所以很容易就误将其依赖导入到了Gateway项目中,碰到这种问题只要打印出依赖树,排查下错误依赖的来源,然后将它在pom中排除出去就好了。
路由流程
这里就涉及到了Gateway最核心的路由功能,路由主要由断言和过滤器配合来实现,我们把这部分内容拆分为3个小节,分别介绍路由的整体功能、断言的使用、过滤器原理和生命周期。
4.路由功能详解
Gateway网关的路由功能可不简简单单的转发请求,在请求到达网关再流转到指定服务之间发生了很多事!它不光可以拒绝请求,甚至可以篡改请求的参数!
一个route包含完整转发规则的路由,主要由一下三部分组成:
断言集合:断言是路由处理的第一个环节,它是路由的匹配规则,它决定了一个网络请求是否可以匹配给当前路由来处理。之所以它是一个集合的原因是我们可以给一个路由添加多个断言,当每个断言都匹配成功以后才算过了路由的第一关。有关断言的详细内容将在下一小节进行介绍
过滤器集合:如果请求通过了前面的断言匹配,那就表示它被当前路由正式接手了,接下来这个请求就要经过一系列的过滤器集合。过滤器的功能就是八仙过海各显神通了,可以对当前请求做一系列的操作,比如说权限验证,或者将其他非业务性校验的规则提到网关过滤器这一层。在过滤器这一层依然可以通过修改Response里的status Code达到中断效果,比如对鉴权失败的访问请求设置Status Code为403之后中断操作。有关过滤器的详细内容将在后面的小节介绍
URI:如果请求顺利通过过滤器的处理,接下来就到了最后一步,那就是转发请求。URI是统一资源标识符,它可以是一个具体的网址,也可以是IP+端口的组合,或者是Eureka中注册的服务名称
关于负载均衡:
对最后一步寻址来说,如果采用基于Eureka的服务发现机制,那么在Gateway的转发过程中可以采用服务注册名的方式来调用,后台会借助Ribbon实现负载均衡(可以为某个服务指定具体的负载均衡策略),其配置方式如:1b://FEIGN-SERVICE-PROVIDER/。前面的lb就是指代Ribbon作为LoadBalancer,
路由的规则流程:
Predicate Handler:具体承接类是RoutePredicateHandlerMapping。首先它获取所有的路由(配置的routes全集),然后依次循环每个Route,把应用请求与Route中配置的所有断言进行匹配,如果当前Route所有断言都验证通过,Predict Handler就选定当前的路由。这个模式是典型的职责链。
Filter Handler:在前一步选中路由后,由FilteringWebHandler将请求交给过滤器,在具体处理过程中,不仅当前Route中定义的过滤器会生效,我们在项目中添加的全局过滤器(Global Filter)也会一同参与。同学们看到图中有Pre Filter和Post Filter,这是指过滤器的作用阶段,我们在稍后的章节中再深入了解
寻址:这一步将把请求转发到URI指定的地址,在发送请求之前,所有Pre类型过滤器都将被执行,而Post过滤器会在调用请求返回之后起作用。
5.断言功能详解(Predict)
Predicate机制:
Predicate是Java 8中引入的一个新功能,就和我们平时在项目中写单元测试时用到的Assertion差不多,Predicate接收一个判断条件,返回一个ture或false的布尔值结果,告知调用方判断结果。你也可以通过and (与),or(或)和negative (非)三个操作符将多个Predicate串联在一块共同判断。
如果Gateway是挡在微服务前面的中介,那这个Predicate就是和中介的接头暗号。比如中介可以要求你的Request中必须带有某个指定的参数叫name,对应的值必须是一个指定的信息,如果你的Request中没有包含指定信息,或者指定信息错误,那就是断言失败。只有当你的请求完全和接头暗号匹配的时候,中介才能给你放行。
说白了predicate就是一种路由规则,通过gateway中丰富内置断言的组合,
我们就能让一个请求找到对应的route来处理。
断言的作用阶段:
在一个请求抵达网关层后,首先就要进行断言匹配,在满足所有断言之后
才会进入Filter阶段!
常用断言介绍 :gateway提供了十多种内置断言:
路径匹配 :path断言是最常用一个断言。
.route(r -> r.path("/gateway/**")
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
.route(r -> r.path("/baidu")
.uri("http://baidu.com:80/")
)
Path断言的使用非常简单,就像我们在Controller中配置@RequestPath的方式一样,在Path断言中填上---段URL匹配规则,当实际请求的URL和断言中的规则相匹配的时候,就下发到该路由中URI指定的地址,这个地址可以是一个具体的HTTP地址,也可以是Eureka中注册的服务名称。在上面的例子中,如果我们访问"Igateway/test",这个路径将匹配到第一个路由。
Method断言:
这个断言是专门验证HTTP Method的,在下面的例子中,我们把Method断言和Path断言通过一个and连接符合并起来,共同作用于路由判断,当我们访问"lgateway/sample"并且HTTP Method是GET的时候,将适配下面的路由
.route(r -> r.path("/gateway/")
.and().method(HttpMethod.GET)
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
RequestParam匹配:请求断言也是业务中经常使用的,它会从ServerHttpRequest中
的Parameters列表中查询指定的属性,如下有两种不同的使用方式:
.route(r -> r.path("/gateway/ ")
.and().method(HttpMethod.GET)
.and().query("name", "test")
.and().query("age")
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
属性名验证 :如query("age"),此时断言只会验证QueryPrameters列表中是否包含了一个叫age的属性,并不会验证它的值
属性值验证:如query ( ""name" ,"test"),它不仅会验证name属性是否存在,还会验证它的值是不是和断言相匹配,比如当前的断言会验证请求参数中的name属性值是不是test,第二个参数实际上是一个用作模式匹配的正则表达式
**Header断言:这个断言会检查Header中是否包含了响应的属性,通常可以用来
验证请求是否携带了令牌:
.route(r -> r.path("/gateway/ ")
.and().header("Authorization")
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
上面的断言指定Header中必须包含一个Authorization属性,Header断言和Query断言
一样,也可以通过传入两个参数形式对属性值进行检查
Cookie断言:
顾名思义,Cookie验证的是Cookie中保存的信息,Cookie断言和上面介绍的两种断言使用方式大同小异,唯一的不同是它必须连同属性值一同验证,不能单独只验证属性是否存在,示例如下:
.route(r -> r.path("/gateway/**")
.and().cookie("name", "test")
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
时间片匹配:
时间匹配有三种模式,分别是Before、After和Between,这些断言指定了在什么时间范围内路由才会生效
.route(r -> r.path("/gateway/**")
.and().before(ZonedDateTime.now().plusMinutes(1))
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
自定义断言:
Gateway也提供了一个扩展方法,用来将自定义的断言应用到路由上。老师给出两点提示,希望同学们顺着这个方向来参考Gateway的源码,实现一个自定义断言,完成一个小功能:将所有请求参数大于5个的访问请求拦截掉,即RequestParam个数小于5个的请求才能被放行。
提示1:所有断言类都可以继承自AbstractRoutePredicateFactory
提示2:在路由配置时可以通过predicate或者asyncPredicate传入一个自定义断言
6.过滤器原理和生命周期
过滤器的工作模式:
Gateway的过滤器是一样的模型,他们经过优先级排序,所有网关调用请求从最高优先级的过滤器开始,一路走到头,直到被最后一个过滤器处理。
过滤器的实现方式:
在Gateway实现一个过滤器非常简单,只要实现GatewayFilter接口的默认方法就好!
java
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 随意发挥
return chain.filter(exchange);
}
这里面有两个关键信息:
ServerWebExchange:这是Spring封装的HTTP request-response交互协议,从中我们可以获取request和response中的各种请求参数,也可以向其中添加内容
GatewayFilterChain:它是过滤器的调用链,在方法结束的时候我们需要将exchange对象传入调用链中的下一个对象
过滤器的执行阶段:
不同于springcloud中上一代网关组件Zuul里对过滤器的Pre和Post的定义,
Gateway是通过Filter中的代码来实现类似Pre和Post的效果!
Pre和Post是指当代过滤器执行阶段,Pre是在下一个过滤器之前被执行,Post
是在过滤器执行过后再执行。我们在GatewayFileter也可以同时定义Pre和Post执行逻辑!!
Pre类型:
AddResponseHeaderGatewayFilterFactory,它可以向Response中添加Header信息:
java
@Override
public GatewayFilter apply(NameValueConfig config) {
return (exchange, chain) -> {
exchange.getResponse().getHeaders().add(config.getName(), config.getValue());
return chain.filter(exchange);
};
}
Post类型:
SetStatusGatewayFilterFactory,它在过滤器执行完毕之后,将制定的HTTP status返回给调用方!!
java
return chain.filter(exchange).then(Mono.fromRunnable(() -> {
// 这里是业务逻辑
}));
这个过滤器的主要逻辑在then方法中,then是一个回调函数,在下级调用链路都完成以后再执行,因此这类过滤器可以看做是Post Filter
过滤器排座次:
在Gateway中我们可以通过实现org.springframework.core.Ordered接口,来给过滤器指定执行顺序,比如下面的代码实现了Ordered接口方法,将过滤器执行顺序设置为0:
java
@Override
public int getOrder() {
return 0;
}
Pre
类型的过滤器来说,数字越大表示优先级越高,也就越早被执行。但对于Post类型的过滤器,则是数字越小越先被执行。
过滤器示例:
Header过滤器
这个系列有很多组过滤器,AddRequestHeader和AddResponseHeader,分别向Request和Response里加入指定Header。相应的RemoveRequestHeader和RemoveResponseHeader分别做移除操作,用法也很简单:
java
.filters(f -> f.addResponseHeader("who", "gateway-header"))
上面的例子会向header中添加一个who的属性,对应的值是gateway-heade
StringPrefix过滤器:
这是个比较常用的过滤器,它的作用是去掉部分URL路径。比如我们的过滤器配置如下:
java
.route(r -> r.path("/gateway-test/**")
.filters(f -> f.stripPrefix(1))
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
假如HTTP请求访问的是/gateway-test/sample/update,如果没有StripPrefix过滤器,那么转发到FEIGN-SERVICE-PROVIDER服务的访问路径也是一样的。当我们添加了这个过滤器之后,Gateway就会根据"stripPrefix(1)"中的值截取URL中的路径,比如这里我们设置的是1,那么就去掉一个前缀,最终发送给后台服务的路径变成了"/sample/update"
PrefixPath过滤器:
它和StripPrefix的作用是完全相反的,会在请求路径的前面加入前缀
java
.route(r -> r.path("/gateway-test/**")
.filters(f -> f.prefixPath("go"))
.uri("lb://FEIGN-SERVICE-PROVIDER/")
)
比如说我们访问"/gateway-test/sample"的时候,上面例子中配置的过滤器就会把请求发送到"/go/gateway-test/sample"。
RedirectTo过滤器:
可以把收到特定的状态码的请求重定向到一个特定的网址:
.filters(f -> f.redirect(302, "https://www.xxx.com/"))
上面的例子接收HTTP status code和URL两个参数,如果请求结果是404,则重定向到第二个参数指定的页面,这个功能也可以做统一异常处理,将Unauthorized或Forbidden请求重定向到登录页面。