--p219
Spring Cloud Zuul提供了一套过滤器机制
开发者可以通过使用Zuul来创建各种校验过滤器机制.....
简述通过Zuul实现的API网关服务的构建过程?
--p220
1,创建一个基础的Spring Boot工程,命名为api-gateway,并在pom.xml里引入spring-cloud-starter-zuul依赖
2,创建应用主类,使用@EnableZuulProxy注解开启Zuul的API网关服务功能.
3,在application.properties中配置Zuul应用的基础信息,如应用名,服务端口号等
请求路由(Spring Cloud Zuul的一个核心功能)
--p222
面向服务的路由
为了与Eureka整合,我们需要在api-gateway的pom.xml里引入spring-cloud-starter-eureka依赖
在api-gateway的application.properties配置文件中指定Eureka注册中心的位置,并配置服务路由.
zuul.routes.api-a.path=/api-a/**
zuul.routes.api-a.serviceId=hello-service
zuul.routes.api-b.path=/api-b/**
zuul.routes.api-b.serviceId=feign-consumer
eureka.client.serviceUrl.defaultZone=http://localhost:1111/eureka/
好处:通过面向服务的路由配置方式,我们不需要再为各个路由维护微服务应用的具体实例的位置,而是通过简单的path与serviceId的映射组合,
使得维护工作变得非常简单.
请求过滤(Spring Cloud Zuul的另一个核心功能)
--p224
Zuul允许开发者在API网关上通过定义过滤器来实现对请求的拦截与过滤,实现方法:extends ZuulFilter(抽象类) 并实现它定义的4个抽象方法就可以
完成对请求的拦截和过滤了.
--p225
filterType:过滤器类型,它决定过滤器在请求的那个生命周期执行.如:pre代表在请求被路由之前执行
filterOrdr:过滤器执行顺序
shouldFilter:判断该过滤器是否需要被执行.true 过滤器的有效范围
run:过滤器的具体逻辑
在实现了自定义过滤器之后,它并不会直接生效,还需要为其创建具体的Bean才能启动该过滤器,如:在应用主类中增加如下内容:
@Bean
public AccessFilter accessFilter(){
return new AccessFilter();
}
简述API网关服务对微服务的重要性?(Spring Cloud Zuul的优点)
1,它作为系统的统一入口,......
2,它可以与服务治理框架结合,实现自动化的服务实例维护以及负载均衡的路由转发.
3,它可以实现接口权限校验与微服务业务逻辑的解耦
4,通过服务网关中的过滤器,在各个生命周期中去校验请求的内容,将原本在对外服务层做的校验前移,......
路由详解
--p229
大部分的路由配置规则几乎都会采用服务名作为外部请求的前缀,如下:
zuul.routes.user-service.path=/user-service/**
zuul.routes.user-service.serviceId=user-service
对于这样具有规则性的配置内容,可以自动化完成
zuul.ignored-services=*的时候,Zuul将会对所有的服务都不自动创建路由规则.
默认情况下,Zuul自动为服务创建的路由表达式会采用服务名(serviceId)作为前缀. 10:52 2018-12-28
自定义路由映射规则
路由匹配:/v1/userservice/** 服务版本标识 服务名
实现步骤如下: ......
PatternServiceRouteMapper对象可以让开发者通过正则表达式来自定义服务与路由映射的生成关系.
路径匹配
由于properties的配置内容无法保证有序,所以当出现这种情况的时候,为了保证路由的优先顺序,我们需要使用YAML文件来配置,如:
zuul:
routes:
user-service-ext:
path:/user-service/ext/**
serviceId:user-service-ext
user-service:
path:/user-service/**
serviceId:user-service
忽略表达式
如果不希望/hello接口被路由,设置如下:
zuul.ignored-patterns=/**/hello/**
路由前缀
务必避免让路由表达式的起始字符串与zuul.prefix参数相同
本地跳转
--p235
Cookie与头信息
我们在开发Web项目时常用的Cookie在Spring Cloud Zuul网关中默认是不会传递的,这就会引发一个常见问题:如果我们使用了Spring Security,Shiro等
安全框架构建的Web应用通过Spring Cloud Zuul构建的网关来进行路由时,由于Cookie信息无法传递,我们的Web应用将无法实现登录和鉴权.
解决方法如下:
#方法1:对指定路由开启自定义敏感头
zuul.routes.<router>.customSensitiveHeaders=true
#方法2:将指定路由的敏感头设置为空
zuul.routes.<router>.sensitiveHeaders=
重定向问题
登录成功后,我们跳转到的页面URL是具体Web应用实例的地址,而不是通过网关的路由地址.这个问题很严重,因为使用API网关的一个重要原因就是要将网关
作为统一入口,从而不暴露所有内部服务细节.
原因:
请求头信息中的Host指向了具体的服务实例IP地址和端口
没将最初的Host信息设置正确
解决方法:
zuul.addHostHeader=true
由于Spring Cloud版本原因,目前Brixton版本采用了Spring-cloud-netflix-core-1.1.x,只有Camden版本采用Spring-cloud-netflix-core-1.2.x.
所以重定向的问题如果要在Zuul中解决,最简单的方法使用Camden版本
Hystrix和Ribbon支持
spring-cloud-starter-zuul依赖自身就包含了对spring-cloud-starter-hystrix和spring-cloud-starter-ribbon模块的依赖,所以Zuul天生就拥有线程
隔离和断路器的自我保护功能,以及对服务调用的客户端负载均衡功能.
注意:当使用path与URL的映射关系来配置路由规则时,对于路由转发的请求不会采用HystrixCommand来包装,所以这类路由请求没有线程隔离和断路器的保
护,且也不会有负载均衡的能力.因此,我们在使用Zuul时尽量使用path和serviceId的组合来进行配置
--p238
过滤器详解
过滤器
路由功能负责将外部请求转发到具体的微服务实例上,是实现外部访问统一入口的基础
过滤器功能负责对请求的处理过程进行干预,是实现请求校验,服务聚合等功能的基础
filterType:过滤器类型,它决定过滤器在请求的那个生命周期执行.
如:pre代表在请求被路由之前执行
routing代表在路由请求时被调用
post代表在routing和error过滤器之后被调用
error代表处理请求时发生错误时被调用
filterOrdr:通过int值来定义过滤器执行顺序,数值越小优先级越高
shouldFilter:判断该过滤器是否需要被执行.true 过滤器的有效范围
run:过滤器的具体逻辑 自定义的过滤逻辑,来确定是否拦截当前的请求 或在请求路由返回结果之后,对处理结果做一些加工等
请求生命周期
第一个阶段pre
第二个阶段routing
第三个阶段post 通过post过滤器将最终结果返回给请求客户端
特殊阶段error
核心过滤器
......
--p244
异常处理