zuul使用中的一些问题

1.token不向后传

微服务设计中,header中的信息(Cookie/Set-Cookie/Authorization)属于附加鉴权相关,
而统一鉴权属于网关工作范畴,所以请求经过网关后,header信息不会继续向后传.最小知道原则

想解决 配置文件中 sensitive-headers:置空即可

2.项目改造过程中,路由问题

原有服务域名old.com
重构服务域名new.com
将app调用old.com的请求转发到 新服务 new.com

解决办法:

1.zuul网关中,新老url做映射
2.nginx中进行匹配
3.zuul中自定义filter

3.动态路由(流量定向分发)问题

根据特定规则,将不同用户请求分发到不同服务中去,
思路参考:《灰度发布与ABtest》

4.网关一般作用:

分发服务
鉴权
过滤请求
监控
(动态)路由
限流

• 流量峰值估算,28原则
  80%的流量集中在在20%的时间中

5.zuul四种过滤器

pre 在请求被路由之前调用,可实现鉴权、选择微服务、日志、限流
route在请求路由到微服务时调用,利用httpClient或ribbon实现
post在调用微服务之后调用，将相应返回客户端，可用于添加heder、记录日志
error 其它阶段发生异常时

6.filter实现过程

1.继承zuulfilter
2.shoudFilter() true:执行当前filter false:不执行
3.run()filter具体业务逻辑
4.filterType:pre、route、post、error
5.order:数字越小,执行顺序越靠前

7.zuul中404问题

zuul中地址来源:Eureka中获取/配置文件中获取,
如果都找不到就会404

8.zuul容错

实现FallbackProvider

9.过滤器开关

shoudFilter(),中信息存储到redis或者配置中心,
不需要重启服务可完成过滤器的开启和关闭

• sendZuulResponse(false)将短路下一类型filter,
  但是同类型filter不受影响,如果需要短路同类型,需要自行在同类型filtershoudFilter()中对sendZuulResponse进行判断

网关限流

• 通过filter+google.guava令牌桶进行限流
• 微服务自身也应该有限流,也可以通过filterfilter+google.guava限流,
  也可采用filter+Sentinel或者@SentinelResource注解方式