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注解方式
