Spring Cloud Zuul
简介
- Zuul是从设备和网站到后端应用程序所有请求到入口，为内部服务提供可配置的对外URL到服务的映射关系，基于
JVM的后端路由器。其具备功能如下：- 认证与鉴权
- 压力控制
- 金丝雀测试
- 动态路由
- 负载消减
- 静态响应处理
- 主动流量管理
底层基于servlet，本质组件是一系列Filter所构成的责任链
典型配置
路由配置
Zuul作为微服务"路由器"，那它都有哪些配置呢？
- 单实例serviceId映射
zuul:
routes:
client-a:
path: /client/**
serviceId: client-a
从/client/** 到 client-a服务到一个映射规则，其实我们可以把它简化成一个比较简单到配置：
zuul:
routes:
client-a: /client/**
此时，Zuul会为client-a添加一个默认的映射规则/client-a/**，相当于上面的配置;
- 单实例url映射
除了路由到服务之外，还可以路由到物理地址，将serviceId替换为url即可
zuul:
routes:
client-a:
path: /client/**
url: http://localhost:7070 #client-a的地址
- 多实例路由
默认情况下，Zuul会使用Eureka中集成的基本负载均衡功能，如果使用Ribbon的负载均衡功能，就需要指定一个serviceId，此操作需要禁止Ribbon使用Eureka，在E版之后，新增了负载均衡策略配置：
zuul:
routes:
ribbon-route:
path: /ribbon/**
serviceId: ribbon-route
ribbon:
eureka:
enabled: false #禁止Ribbon使用Eureka
ribbon-route:
ribbon:
NIWSServerListClassName: com.netflix.loadbalancer.ConfigurationBasedServerList
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule #Ribbon LB Strategy
listOfServers: localhost:7070,localhost:7071 #client services for Ribbon LB
- forward本地跳转
有时候我们在Zuul中会做一些逻辑处理，在网关中写好一个接口：
@RestController
public class TestController {
@GetMapping("/client")
public String add(Integer a, Integer b){
return "本地跳转：" + (a + b);
}
}
如果我们希望Zuul跳转到这个方法来处理，就要在配置中指定：
########################## foward跳转本地url ##########################
zuul:
routes:
client-a:
path: /client/**
url: forward:/client
- 相同路径的加载规则
配置多个会按照加载顺序，加载最末尾的，如下代码，会加载client-a：
########################## 映射覆盖情况 ##########################
zuul:
routes:
client-b:
path: /client/**
serviceId: client-b
client-a:
path: /client/**
serviceId: client-a
路由通配符
- path: /client/** 都是什么意思呢？如下图：
| 规则 | 释义 | 示例 |
|---|---|---|
| /** | 匹配任意数量的路径与字符 | /client/add，/client/mul，/client/a，/client/add/a，/client/mul/a/b， |
| /* | 匹配任意数量的字符 | /client/add，/client/mul，/client/a， |
| /? | 匹配单个字符 | /client/a，/client/b，/client/c， |
开发过程中可以根据需求进行路由匹配符的选择
功能配置
路由前缀
配置路由时，我们可以配置一个统一的代理前缀：
########################## 服务忽略、路径忽略、前缀、重定向问题 ##########################
zuul:
prefix: /pre #使用prefix指定前缀
routes:
client-a: /client/**
这样，我们在通过Zuul访问后台接口时就要加上pre前缀，请求路径即变成/pre/client/xxx，但实际起作用的是/client/add，即Zuul会把代理路径从请求路径中移除。可用stripPrefix=false关闭此功能：
########################## 敏感头设置 ##########################
zuul:
prefix: /pre
routes:
client-a:
path: /client/**
serviceId: client-a
stripPrefix: false
关闭后请求路径是/pre/client/xxx，实际请求路径也是/pre/client/xxx，建议实际开发中不要使用此配置
服务屏蔽与路径屏蔽
为了避免服务或路径被侵入，可将它们屏蔽掉：
zuul:
ignored-services: client-b #忽略的服务，防服务侵入
ignored-patterns: /**/div/** #忽略的接口，屏蔽接口
prefix: /pre #使用prefix指定前缀
routes:
client-a: /client/**
加上ignored-services和ignored-patterns之后，Zuul在拉取服务列表，创建映射规则时候，就会忽略掉client-b服务与/**/div/**接口
敏感头信息
构建系统时，将信息放入http的header传值是十分方便的，协议的认证信息默认也存放在header，例如：Cookie，或通过BASE64加密后放在Authorization里面。当系统和外部系统之间关联时，就可能会出现这些信息的泄漏。Zuul配置里面可以指定敏感头，切断它与下层服务之间的交互：
########################## 敏感头设置 ##########################
zuul:
prefix: /pre
routes:
client-a:
path: /client/**
sensitiveHeaders: Cookie,Set-Cookie,Authorization
serviceId: client-a
stripPrefix: false
重定向问题
在实际使用时，Zuul作为网关，认证后直接请求下游服务，在默认情况下会返回下游服务的host给客户端，而不是Zuul的host，这样就暴露了实际服务的host，我们通过以下配置可以解决：
zuul:
add-host-header: true #重定向header问题
routes:
client-a: /client/**
重试机制
实际投产后，请求会出现失败的情况，而由于业务的局限性我们不能做服务感知，只有通过重试来解决，可通过以下配置实现：
########################## 重试机制 ##########################
zuul:
retryable: true #开启重试
ribbon:
MaxAutoRetries: 1 #同一个服务重试的次数(除去首次)
MaxAutoRetriesNextServer: 1 #切换相同服务数量
切记：此功能慎用，要保证接口的幂等性前提时使用。