什么是API网关？
在微服务架构中，通常会将业务模块化，细分为多个服务，譬如：订单服务、文件服务、社交服务等。随着业务体系的逐渐庞大，微服务也会增加，在多个微服务中提供统一的访问入口，在依据API路由到服务提供者，运用网关就可以对外暴露聚合API，屏蔽内部微服务的具体实施者，保持整个系统的稳定性。当然这只是网关众多功能中的一部分，除此之外，还可以做负载均衡，统一鉴权，协议转换，监控监测等一系列功能。
什么是Zuul?
Zuul是Spring Cloud五大组件之一的微服务API网关。
设备或网站的请求，经过API网关Zuul过滤，转发到具体的服务提供方。
Zuul特点：
- 认证和安全，识别每个需要认证的资源，拒绝非法请求；
- 性能监测，在服务边界追踪并统计数据，提供精确的生产视图；
- 动态路由，根据API资源路径，转发到具体的服务提供者；
- IP限流，自定义同一IP在规定时间内访问系统的次数；
- 负载均衡， 无缝衔接ribbon、Hystrix，提升系统的高可用性；
- 减少客户端与服务端的耦合，服务可以独立发展，通过网关层来做映射；
Zuul网关过滤器
Zuul中提供了过滤器定义，可以用来过滤代理请求，提供额外功能逻辑。如：权限验证，日志记录等。
Zuul提供的过滤器是一个父类。父类是ZuulFilter提供了4个抽象方法，分别是：filterType, filterOrder, shouldFilter, run。
filterType：方法返回字符串数据，代表当前过滤器的类型。可选值有pre、route、post、error，其功能分别是：
- pre：前置过滤，是请求进入Zuul之后，立刻执行的过滤逻辑。
- routed：路由后过滤，是请求进入Zuul之后，并Zuul实现了请求路由后执行的过滤逻辑，路由后过滤，是在远程服务调用之前过滤的逻辑。
- post：后置过滤，远程服务调用结束后执行的过滤逻辑。
- error：异常过滤，是任意一个过滤器发生异常或远程服务调用无结果反馈的时候执行的过滤逻辑。无结果反馈，就是远程服务调用超时。
filterOrder：返回int数据，用于为同filterType的多个过滤器定制执行顺序，返回值越小，执行顺序越优先；
shouldFilter：返回boolean数据，代表当前filter是否生效；
run：具体的过滤执行逻辑。如pre类型的过滤器，可以通过对请求的验证来决定是否将请求路由到服务上；如post类型的过滤器，可以对服务响应结果做加工处理（如为每个响应增加footer数据）。
Zuul过滤器 的生命周期
代码示例
/**
* Zuul过滤器，必须继承ZuulFilter父类。
* 当前类型的对象必须交由Spring容器管理。使用@Component注解描述。
* 继承父类后，必须实现父类中定义的4个抽象方法。
* shouldFilter、 run、 filterType、 filterOrder
*/
@Component
public class LoggerFilter extends ZuulFilter {
private static final Logger logger = LoggerFactory.getLogger(LoggerFilter.class);
/**
* 返回boolean类型。代表当前filter是否生效。
* 默认值为false。
* 返回true代表开启filter。
*/
@Override
public boolean shouldFilter() {
return true;
}
/**
* run方法就是过滤器的具体逻辑。
* return 可以返回任意的对象，当前实现忽略。（spring-cloud-zuul官方解释）
* 直接返回null即可。
*/
@Override
public Object run() throws ZuulException {
// 通过zuul，获取请求上下文
RequestContext rc = RequestContext.getCurrentContext();
HttpServletRequest request = rc.getRequest();
logger.info("LogFilter1.....method={},url={}",
request.getMethod(),request.getRequestURL().toString());
// 可以记录日志、鉴权，给维护人员记录提供定位协助、统计性能
return null;
}
/**
* 过滤器的类型。可选值有：
* pre - 前置过滤
* route - 路由后过滤
* error - 异常过滤
* post - 远程服务调用后过滤
*/
@Override
public String filterType() {
return "pre";
}
/**
* 同种类的过滤器的执行顺序。
* 按照返回值的自然升序执行。
*/
@Override
public int filterOrder() {
return 0;
}
}
Zuul网关容错（与hystrix无缝衔接）
在spring cloud中，Zuul启动器中包含了Hystrix相关依赖，在Zuul网关工程中，默认是提供了Hystrix Dashboard服务监控数据的(hystrix.stream)，但是不会提供监控面板的界面展示。可以说，在spring cloud中，zuul和Hystrix是无缝结合的。
- Zuul中的服务降级处理
在Edgware版本之前，Zuul提供了接口ZuulFallbackProvider用于实现fallback处理。从Edgware版本开始，Zuul提供了ZuulFallbackProvider的子接口FallbackProvider来提供fallback处理。
Zuul的fallback容错处理逻辑，只针对timeout异常处理，当请求被Zuul路由后，只要服务有返回（包括异常），都不会触发Zuul的fallback容错逻辑。
因为对于Zuul网关来说，做请求路由分发的时候，结果由远程服务运算的。那么远程服务反馈了异常信息，Zuul网关不会处理异常，因为无法确定这个错误是否是应用真实想要反馈给客户端的。
- 代码示例
@Component
public class DefaultFallbackProvider implements FallbackProvider {
@Override
public String getRoute() {
//匹配微服务名字，*表示匹配所有
return "*";
}
@Override
public ClientHttpResponse fallbackResponse() {
return null;
}
@Override
public ClientHttpResponse fallbackResponse(Throwable cause) {
return new ClientHttpResponse() {
@Override
public HttpStatus getStatusCode() throws IOException {
//当fallback时返回给调用者的状态码
return HttpStatus.OK;
}
@Override
public int getRawStatusCode() throws IOException {
return this.getStatusCode().value();
}
@Override
public String getStatusText() throws IOException {
//状态码的文本形式
return null;
}
@Override
public void close() {
}
@Override
public InputStream getBody() throws IOException {
//响应体
return new ByteArrayInputStream("default fallback".getBytes());
}
@Override
public HttpHeaders getHeaders() {
//设定headers
HttpHeaders headers = new HttpHeaders();
headers.setContentType(MediaType.TEXT_HTML);
return headers;
}
};
}
}
Zuul网关限流策略
Zuul网关组件也提供了限流保护。当请求并发达到阀值，自动触发限流保护，返回错误结果。只要提供error错误处理机制即可。
Zuul的限流保护需要额外依赖spring-cloud-zuul-ratelimit组件。
- 全局限流配置
# 开启限流保护
zuul.ratelimit.enabled=true
# 60s内请求超过3次，服务端就抛出异常，60s后可以恢复正常请求
zuul.ratelimit.default-policy.limit=3
zuul.ratelimit.default-policy.refresh-interval=60
# 针对IP进行限流，不影响其他IP
zuul.ratelimit.default-policy.type=origin
- 局部限流配置
# 开启限流保护
zuul.ratelimit.enabled=true
# hystrix-application-client服务60s内请求超过3次，服务抛出异常。
zuul.ratelimit.policies.hystrix-application-client.limit=3
zuul.ratelimit.policies.hystrix-application-client.refresh-interval=60
# 针对IP限流。
zuul.ratelimit.policies.hystrix-application-client.type=origin
- 限流参数
Zuul网关请求超时
使用Zuul的spring cloud微服务结构图：
从上图中可以看出。整体请求逻辑还是比较复杂的，在没有zuul网关的情况下，app client请求app service的时候，也有请求超时的可能。那么当增加了zuul网关的时候，请求超时的可能就更明显了。
当请求通过zuul网关路由到服务，并等待服务返回响应，这个过程中zuul也有超时控制。zuul的底层使用的是Hystrix+ribbon来实现请求路由。结构如下：
zuul中的Hystrix内部使用线程池隔离机制提供请求路由实现，其默认的超时时长为1000毫秒。ribbon底层默认超时时长为5000毫秒。如果Hystrix超时，直接返回超时异常。如果ribbon超时，同时Hystrix未超时，ribbon会自动进行服务集群轮询重试，直到Hystrix超时为止。如果Hystrix超时时长小于ribbon超时时长，ribbon不会进行服务集群轮询重试。
那么在zuul中可配置的超时时长就有两个位置：Hystrix和ribbon。具体配置如下：
# 开启zuul网关重试
zuul.retryable=true
# hystrix超时时间设置
# 线程池隔离，默认超时时间1000ms
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=8000
# ribbon超时时间设置：建议设置比Hystrix小
# 请求连接的超时时间: 默认5000ms
ribbon.ConnectTimeout=5000
# 请求处理的超时时间: 默认5000ms
ribbon.ReadTimeout=5000
# 重试次数：MaxAutoRetries表示访问服务集群下原节点（同路径访问）；MaxAutoRetriesNextServer表示访问服务集群下其余节点（换台服务器）
ribbon.MaxAutoRetries=1
ribbon.MaxAutoRetriesNextServer=1
# 开启重试
ribbon.OkToRetryOnAllOperations=true
Spring-cloud中的zuul网关重试机制是使用spring-retry实现的。工程必须依赖下述资源：
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
Zuul网关高可用
Zuul网关组件的高可用，关系到整个系统的可访问性，外部请求路由到具体服务者，全会经过Zuul，为避免单点故障，网关的高可用非常关键。
方案一：多节点Zuul注册到Eureka Server上，即可实现Zuul的高可用
方案二：Zuul客户端未注册到Eureka Server
例如，Zuul客户端是一个手机APP——我们不可能让所有的手机终端都注册到Eureka Server上，可借助一个额外的负载均衡器来实现Zuul的高可用，例如Nginx、HAProxy、F5等。