首先,网关能为咱们做什么?
它能为咱们做路由转发,黑、白名单、过滤申请等等等等
网关的实质,其实就是一系列的过滤器,记得咱们最开始学习过滤器的时候,servlet的doFilter,有没有小伙伴的DNA动了,哈哈
咱们明天要说的就是利用网关的实质,过滤器,来做灰度公布
说之前,先讲讲什么是灰度公布,常常听到这个名词,就是不晓得是干嘛的
明天,必须得给他整的明明白白的
灰度公布,也叫金丝雀公布,说的就是可能平滑过渡的一种公布版本的一种形式,在其上能够进行A/B testing,即让一部分用户持续用产品个性A,一部分用户开始用产品个性B,如果用户对B没有什么拥护意见,那么逐渐扩大范围,把所有用户都迁徙到B下面来。
有啥益处呢?
它能够保障整体零碎的稳固,在初始灰度的时候就能够发现、调整问题,以保障其影响度。
除了灰度公布还有那种公布形式呢?
蓝绿公布、滚动公布等等
简略说说蓝绿公布的原理:
须要另外在开启三台服务器(承载新的服务)
滚动公布:
就是将新服务代替其中一个服务,被代替的闲暇进去持续装载另一个新服务,一个一个替换
灰度公布:
启动雷同的服务设置配置文件的版本,例如:启动3个雷同服务,一个版本是V2,剩下两个是V1(版本能够利用Eureka注册核心的API来动静批改)
eureka: instance: metadata-map: #自定义属性 版本V1、V2 version: v2
所有准备就绪,回到Zuul网关,Zuul网关的过滤器,分那么几种类型,pre、route、post、error
执行程序是:pre —> route —> post
想要自定义网关过滤器,继承ZuulFilter,实现其的办法
应用@Component注解,交由Spring容器治理
实现办法是有4个办法,fileType、filterOrder、shouldFilter、run
- fileType办法,指定这个过滤器是什么类型的,pre、route、post、error
- filterOrder办法,决定执行程序,数越小,越先执行
- shouldFilter办法,决定这个过滤器是否执行,true执行,false不执行
- run办法,过滤器的执行逻辑
自定义网关过滤器,相似这种灰度公布,就尽量应用pre类型的过滤器
在发动申请,申请头携带userId(依据用户ID来辨别是否是来拜访新的的服务)
@Overridepublic Object run() throws ZuulException { //获取申请上下文 RequestContext currentContext = RequestContext.getCurrentContext(); //获取到HttpServletRequest HttpServletRequest request = currentContext.getRequest(); //获取申请头携带的userId Integer userId = Integer.parseInt(request.getHeader("userId")); //查问本地缓存/DB/Redis,来确定这个用户是否须要拜访新服务,还是持续拜访旧服务 if (userId >= 5000) { //伪代码,假如这个用户是ID属于比5000要大,就让他拜访/体验新服务 RibbonFilterContextHolder.getCurrentContext().add("version", "v2"); } else { //否则,持续让用户体验旧的服务 //因为V1咱们启动了两个所以负载平衡也能够持续应用 RibbonFilterContextHolder.getCurrentContext().add("version", "v1"); } return null;}
这里用到了RibbonFilter相干的依赖,也给大家筹备好了
<dependency> <groupId>io.jmnarloch</groupId> <artifactId>ribbon-discovery-filter-spring-cloud-starter</artifactId> <version>2.1.0</version></dependency>
还有一点要留神的是,网关在过滤申请的时候,有可能会使你申请头数据失落,没错,的确是网关给你吃了
它不是过意的哈,它是想保障平安,一些比拟特地的key,他就会给你抹掉,如Authorization、Cookie等
//网关配置好这个,什么都不必填,就能够不让网管把携带的申请头参数抹掉zuul: sensitive-header:
嘿嘿,大家喜爱的能够关注我的微信公众号哦,据说当初关注的,当前都是尊贵的老粉了