通过前面的学习，使用Spring Cloud实现微服务的架构基本成型，大致是这样的：
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及均衡负载；通过Spring Cloud Config实现了应用多环境的外部化配置以及版本管理。为了使得服务集群更为健壮，使用Hystrix的融断机制来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在该架构中，我们的服务集群包含：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Service是一个对外的服务，通过均衡负载公开至服务调用方。我们把焦点聚集在对外服务这块，直接暴露我们的服务地址，这样的实现是否合理，或者是否有更好的实现方式呢？
先来说说这样架构需要做的一些事儿以及存在的不足：
- 首先，破坏了服务无状态特点。
- 为了保证对外服务的安全性，我们需要实现对服务访问的权限控制，而开放服务的权限控制机制将会贯穿并污染整个开放服务的业务逻辑，这会带来的最直接问题是，破坏了服务集群中REST API无状态的特点。
- 从具体开发和测试的角度来说，在工作中除了要考虑实际的业务逻辑之外，还需要额外考虑对接口访问的控制处理。
- 其次，无法直接复用既有接口。
- 当我们需要对一个即有的集群内访问接口，实现外部服务访问时，我们不得不通过在原有接口上增加校验逻辑，或增加一个代理调用来实现权限控制，无法直接复用原有的接口。
面对类似上面的问题，我们要如何解决呢？答案是：服务网关！
为了解决上面这些问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更强大一些的均衡负载器的 服务网关。
服务网关是微服务架构中一个不可或缺的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、均衡负载功能之外，它还具备了权限控制等功能。Spring Cloud Netflix中的Zuul就担任了这样的一个角色，为微服务架构提供了前门保护的作用，同时将权限控制这些较重的非业务逻辑内容迁移到服务路由层面，使得服务集群主体能够具备更高的可复用性和可测试性。
一、简介
官网：https://github.com/Netflix/zuul
Zuul：维基百科：
电影《捉鬼敢死队》中的怪兽，Zuul，在纽约引发了巨大骚乱。
事实上，在微服务架构中，Zuul就是守门的大Boss！一夫当关，万夫莫开！
二、Zuul加入后的架构
- 不管是来自于客户端（PC或移动端）的请求，还是服务内部调用。一切对服务的请求都会经过Zuul这个网关，然后再由网关来实现 鉴权、动态路由等等操作。Zuul就是我们服务的统一入口。
三、快速入门
1. 新建工程
2. 添加依赖
3. 启动类+注解
4. 添加配置（zuul的第一个功能-路由）
请求路径会被转发到指定Url
存在问题，路径写死了！！！
四、优化（从Eureka中拉取服务）
1. 添加Eureka客户端
2. 配置Eureka，及路由转发地址
3. 测试
4. 配置简化
Zuul默认配置就是简化配置（Eureka中所有服务都会进行简化配置），即可不写
五、自定义配置
1. 忽略服务
2. 去除前缀
全局配置（放外面,对user无效）
再次简化（此写法对user无效）
添加全局前缀prefix
六、过滤器
Zuul作为网关的其中一个重要功能，就是实现请求的鉴权。而这个动作我们往往是通过Zuul提供的过滤器来实现的。
1. ZuulFilter
ZuulFilter是过滤器的顶级父类。在这里我们看一下其中定义的4个最重要的方法：
public abstract ZuulFilter implements IZuulFilter{
abstract public String filterType();
abstract public int filterOrder();
boolean shouldFilter();
Object run() throws ZuulException;
}
-
shouldFilter：返回一个Boolean值，判断该过滤器是否需要执行。返回true执行，返回false不执行。 -
run：过滤器的具体业务逻辑。 -
filterType：返回字符串，代表过滤器的类型。包含以下4种：-
pre：请求在被路由之前执行 -
routing：在路由请求时调用 -
post：在routing和errror过滤器之后调用 -
error：处理请求时发生错误调用
-
-
filterOrder：通过返回的int值来定义过滤器的执行顺序，数字越小优先级越高。
2. 过滤器执行生命周期
这张是Zuul官网提供的请求生命周期图，清晰的表现了一个请求在各个过滤器的执行顺序。
- 正常流程：
- 请求到达首先会经过pre类型过滤器，而后到达routing类型，进行路由，请求就到达真正的服务提供者，执行请求，返回结果后，会到达post过滤器。而后返回响应。
- 异常流程：
- 整个过程中，pre或者routing过滤器出现异常，都会直接进入error过滤器，再error处理完毕后，会将请求交给POST过滤器，最后返回给用户。
- 如果是error过滤器自己出现异常，最终也会进入POST过滤器，而后返回。
- 如果是POST过滤器出现异常，会跳转到error过滤器，但是与pre和routing不同的时，请求不会再到达POST过滤器了。
所有内置过滤器列表：
3. 使用场景
场景非常多：
- 请求鉴权：一般放在pre类型，如果发现没有访问权限，直接就拦截了
- 异常处理：一般会在error类型和post类型过滤器中结合来处理。
- 服务调用时长统计：pre和post结合使用。
七、自定义过滤器
接下来我们来自定义一个过滤器，模拟一个登录的校验。基本逻辑：如果请求中有access-token参数，则认为请求有效，放行。
1. 定义过滤器类
@Component
public class LoginFilter extends ZuulFilter {
@Override
public String filterType() {
return FilterConstants.PRE_TYPE;
}
@Override
public int filterOrder() {
return FilterConstants.PRE_DECORATION_FILTER_ORDER - 1;
}
@Override
public boolean shouldFilter() {
return true;
}
@Override
public Object run() throws ZuulException {
// 获取请求参数
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
// 判断是否存在
String token = request.getParameter("access-token");
if (StringUtils.isBlank(token)) {
// 不存在，未登录，拦截
ctx.setSendZuulResponse(false);
// 返回403
ctx.setResponseStatusCode(HttpStatus.FORBIDDEN.value());
}
return null;
}
}
2. 测试
没有token参数时，访问失败：
添加token参数后：
八、负载均衡和熔断
Zuul中默认就已经集成了Ribbon负载均衡和Hystix熔断机制。但是所有的超时策略都是走的默认值，比如熔断超时时间只有1S，很容易就触发了。因此建议我们手动进行配置：
zuul:
retryable: true
ribbon:
ConnectTimeout: 250 # 连接超时时间(ms)
ReadTimeout: 2000 # 通信超时时间(ms)
OkToRetryOnAllOperations: true # 是否对所有操作重试
MaxAutoRetriesNextServer: 2 # 同一服务不同实例的重试次数
MaxAutoRetries: 1 # 同一实例的重试次数
hystrix:
command:
default:
execution:
isolation:
thread:
timeoutInMillisecond: 6000 # 熔断超时时长：6000ms
注意，Ribbon默认会进行一次重试，即（2000+500）*2<6000 需满足，否则启动警告。
也可配成不重试：MaxAutoRetriesNextServer: 0
