时间:2021-05-19
在前面我们使用zuul搭建了网关
关于网关的作用,这里就不再次赘述了,我们今天的重点是zuul的Filter。通过Filter,我们可以实现安全控制,比如,只有请求参数中有用户名和密码的客户端才能访问服务端的资源。那么如何来实现Filter了?
要想实现Filter,需要以下几个步骤:
1、继承ZuulFilter类,为了验证Filter的特性,我们这里创建3个Filter
根据用户名来过滤
通过继承ZuulFilter然后覆写上面的4个方法,就可以实现一个简单的过滤器,下面就相关注意点进行说明
filterType:返回一个字符串代表过滤器的类型,在zuul中定义了四种不同生命周期的过滤器类型,具体如下:
Zuul的主要请求生命周期包括“pre”,“route”和“post”等阶段。对于每个请求,都会运行具有这些类型的所有过滤器。
filterOrder:通过int值来定义过滤器的执行顺序
shouldFilter:返回一个boolean类型来判断该过滤器是否要执行,所以通过此函数可实现过滤器的开关。在上例中,我们直接返回true,所以该过滤器总是生效
run:过滤器的具体逻辑。需要注意,这里我们通过ctx.setSendZuulResponse(false)令zuul过滤该请求,不对其进行路由,然后通过ctx.setResponseStatusCode(401)设置了其返回的错误码
过滤器间的协调
过滤器没有直接的方式来访问对方。 它们可以使用RequestContext共享状态,这是一个类似Map的结构,具有一些显式访问器方法用于被认为是Zuul的原语,内部是使用ThreadLocal实现的,有兴趣的同学可以看下源码。
再建一个过滤器,根据密码来过滤:
最后建一个post过滤器
2、在主类中,先开启前面的两个过滤器
3、输入请求,验证
(1)请求为:http://localhost:8768/h2service/user/1?username=chhliu
测试结果为:{"result":"password is not correct!"}
控制台打印结果
GET AccessUserNameFilter request to http://localhost:8768/h2service/user/1
GET AccessPasswordFilter request to http://localhost:8768/h2service/user/1
通过了AccessUserNameFilter过滤器,在验证AccessPasswordFilter过滤器的时候失败了
后台无sql打印,说明请求没有被路由
(2)请求为:http://localhost:8768/h2service/user/1?password=123456
测试结果为:{"result":"username is not correct!"}
控制台打印结果:
GET AccessUserNameFilter request to http://localhost:8768/h2service/user/1
说明到了AccessUserNameFilter过滤器,但是没有到AccessPasswordFilter过滤器,因为AccessUserNameFilter过滤器的优先级高一些,会先执行,在执行的时候,发现过滤条件不符合,于是跳过了后面所有的过滤器,并返回结果
后台无sql打印,说明请求没有被路由
(3)请求为:http://localhost:8768/h2service/user/1?password=123456&username=chhliu
测试结果为:
{
"id": 1,
"username": "user1",
"name": "张三",
"age": 20,
"balance": 100.00
}
控制台打印的结果:
GET AccessUserNameFilter request to http://localhost:8768/h2service/user/1
GET AccessPasswordFilter request to http://localhost:8768/h2service/user/1
说明是先执行了AccessUserNameFilter然后才执行AccessPasswordFilter这也和我们前面说的order的值越小,优先级越高是吻合的。
同时被请求的服务有sql输出:
Hibernate: select user0_.id as id1_0_0_, user0_.age as age2_0_0_, user0_.balance as balance3_0_0_, user0_.name as name4_0_0_, user0_.username as username5_0_0_ from user user0_ where user0_.id=?
说明请求被路由了。
4、开启post过滤器,再跑一次
测试结果:发现post过滤器是最后执行的,尽管它的优先级为0
关于zuul的Filter的生命周期,见下图
注:上图有个小错误,routing应该是route
5、拓展
zuul还提供了一类特殊的过滤器,分别为:StaticResponseFilter和SurgicalDebugFilter
StaticResponseFilter:StaticResponseFilter允许从Zuul本身生成响应,而不是将请求转发到源。
SurgicalDebugFilter:SurgicalDebugFilter允许将特定请求路由到分隔的调试集群或主机。
以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持。
声明:本页内容来源网络,仅供用户参考;我单位不保证亦不表示资料全面及准确无误,也不保证亦不表示这些资料为最新信息,如因任何原因,本网内容或者用户因倚赖本网内容造成任何损失或损害,我单位将不会负任何法律责任。如涉及版权问题,请提交至online#300.cn邮箱联系删除。
zuul各版本实现存在一些微小的变化,总的实现思想未改变,以spring-cloud-netflix-core-1.3.6.RELEASE为例一、zuul的重要
先简单说一下我们工程的架构:前端工程是采用react,后端工程采用spring-cloud,里面分为zuul工程和其他功能模块。zuul工程除了提供后端的路由转
1.官方文档https://cloud.spring.io/spring-cloud-static/spring-cloud-openfeign/2.2.2.R
构建Zuul自定义过滤器,限制ip频繁请求自定义zuul过滤器其实很简单1.首先pom文件得先引入zuul依赖org.springframework.cloud
文档地址https://github.com/alibaba/spring-cloud-alibaba/blob/master/spring-cloud-ali