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进行判断10. 网关限流
• 通过filter+google.guava令牌桶进行限流
• 微服务自身也应该有限流,也可以通过filterfilter+google.guava限流, 也可采用filter+Sentinel或者@SentinelResource注解方式