为什么要使用网关
不同的微服务一般会有不同的网络地址，而外部客户端（例如手机APP）可能需要调用多个服务的接口才能完成一个业务需求。例如一个电影购票的手机APP，可能会调用多个微服务的接口，才能完成一次购票的业务流程，如下图所示。
如果让客户端直接与各个微服务通信，会有以下的问题：
-
客户端会多次请求不同的微服务，增加了客户端的复杂性。
-
存在跨域请求，在一定场景下处理相对复杂。
-
认证复杂，每个服务都需要独立认证。
-
难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
-
某些微服务可能使用了防火墙/浏览器不友好的协议，直接访问会有一定的困难。
以上问题可借助微服务网关解决。微服务网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过微服务网关。使用微服务网关后，架构如下所示。
此时，微服务网关封装了应用程序的内部结构，客户端只须跟网关交互，而无须直接调用特定微服务的接口。这样，开发就可以得到简化。不仅如此，使用微服务网关还有以下优点：
-
易于监控。可在微服务网关收集监控数据并将其推送到外部系统进行分析。
-
易于认证。可在微服务网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。
-
减少了客户端与各个微服务之间的交互次数。
Zuul 简介
Zuul 是Netflix开源的一个API网关, 本质上是一个Web Servlet应用。Zuul也是Spring Cloud全家桶中的一员, 它可以和Eureka、Ribbon、Hystrix等组件配合使用。
Zuul的核心是一系列的过滤器，这些过滤器帮助我们完成以下功能：
-
验证与安全保障: 识别面向各类资源的验证要求并拒绝那些与要求不符的请求。
-
审查与监控: 在边缘位置追踪有意义数据及统计结果，从而为我们带来准确的生产状态结论。
-
动态路由: 以动态方式根据需要将请求路由至不同后端集群处。
-
压力测试: 逐渐增加指向集群的负载流量，从而计算性能水平。
-
负载分配: 为每一种负载类型分配对应容量，并弃用超出限定值的请求。
-
静态响应处理: 在边缘位置直接建立部分响应，从而避免其流入内部集群。
-
多区域弹性: 跨越AWS区域进行请求路由，旨在实现ELB使用多样化并保证边缘位置与使用者尽可能接近。
除此之外，Netflix公司还利用Zuul的功能通过金丝雀版本实现精确路由与压力测试。
注：以上介绍来自Zuul官方文档，但其实开源版本的Zuul以上功能一个都没有——开源的Zuul只是几个Jar包而已，以上能力指的应该是Netflix官方自用的Zuul的能力。
快速入门
定义2个服务：hello-server和user-server，他们分别都注册到eureka服务上，示例如下（这里将下面讲到的Zuul也注册上去了）：
在未经过网关时，我们可以通过以下2个接口来分别访问hello-server和user-server：
http://localhost:8081/hello
http://localhost:8082/user
现在我们来定义Zuul服务，相关的Maven依赖如下：
<dependencies>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
<version>2.2.2.RELEASE</version>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<version>2.2.2.RELEASE</version>
</dependency>
</dependencies>
application.yml文件中添加如下配置：
spring:
application:
name: zuul-service
eureka:
client:
service-url:
defaultZone: http://localhost:8761/eureka
server:
port: 6069
启动类中添加@EnableZuulProxy注解
import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.netflix.zuul.EnableZuulProxy;
@SpringBootApplication
@EnableZuulProxy
public class ZuulServiceApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulServiceApplication.class, args);
}
}
启动程序之后，我们可以通过服务网关访问上面的2个接口：
curl http://localhost:6069/hello-server/hello
curl http://localhost:6069/user-server/user
注意：默认的Zuul结合Eureka会注册到Eureka的服务名作为访问的ContextPath。在Zuul中我们可以自定义配置各种路由规则，这里就不再做相关赘述了。
请求过滤
上面的示例中，我们通过Zuul实现了请求路由的功能，这样我们的微服务应用提供的接口就可以通过统一的API网关入口被客户端访问到了。
每个客户端用户请求服务应用提供的接口时，他们的访问权限往往都有一定的限制，系统并不会将所有的微服务接口对他们开放。然而，目前的服务路由并没有限制权限这样的功能，所有请求都会被毫无保留的转发到具体的应用并返回结果，为了实现对客户端请求的安全校验和权限控制，最简单和粗暴的方法就是在每个微服务应用都实现一套用于校验签名和鉴别权限的过滤器或拦截器。这样有个问题就是功能实现太过冗余。比较好的做法就是将这些校验逻辑剥离出去，构建一个独立的鉴权服务。在完成剥离之后，直接在微服务应用中通过调用鉴权系统服务来实现校验，但是这样仅仅只是解决了鉴权逻辑的分离，并没有在本质上将这部分不属于冗余的逻辑从原有的微服务应用中拆出去，冗余的拦截器或者过滤器依然会存在。
对于这样的问题，更好的做法是通过前置的网关服务来完成这些非业务性质的校验。由于网关服务的加入，外部客户端访问我们的系统已经有了统一的入口，既然这些校验与具体的业务无关，那何不在请求到达的时候就完成校验和过滤，微服务应用端就可以去除各种复杂的过滤器和拦截器了，这使得微服务应用接口的开发和测试复杂度也得到了相应的降低。这就涉及到了zuul的另一个主要功能，请求过滤。
下面通过一个简单的示例来了解一下过滤器的使用：
import com.netflix.zuul.ZuulFilter;
import com.netflix.zuul.context.RequestContext;
import com.netflix.zuul.exception.ZuulException;
import lombok.extern.log4j.Log4j2;
import javax.servlet.http.HttpServletRequest;
@Log4j2
public class AccessFilter extends ZuulFilter {
//过滤器的类型，它决定过滤器在请求的哪个生命周期中执行，这里定义为pre，代表会在请求被理由之前执行。
@Override
public String filterType() {
return "pre";
}
//过滤器的执行顺序。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行
@Override
public int filterOrder() {
return 0;
}
//判断该过滤器是否需要被执行。这里我们直接返回了true，因此该过滤器对所有的请求都生效。实际运行中我们可以利用该函数
//来指定过滤器的有效范围。
@Override
public boolean shouldFilter() {
return true;
}
//过滤器的具体执行逻辑。
@Override
public Object run() throws ZuulException {
RequestContext ctx = RequestContext.getCurrentContext();
HttpServletRequest request = ctx.getRequest();
log.info("send {} request to {}", request.getMethod(), request.getRequestURI().toString());
Object accessToken = request.getParameter("accessToken");
if (accessToken == null) {
log.warn("access token is empty");
ctx.setSendZuulResponse(false);
ctx.setResponseStatusCode(401);
} else {
log.info("access token ok");
}
return null;
}
}
代码示例中的ZuulFilter接口中定义了4个方法：
-
filterType：过滤器的类型（Type），它决定过滤器在请求的哪个生命周期中执行，这里定义为pre，代表会在请求被理由之前执行。（有关过滤器的类型会在下面的篇幅中详细描述）
-
filterOrder：过滤器的执行顺序（Execution Order）。当请求在一个阶段中存在多个过滤器时，需要根据该方法返回的值来依次执行。
-
shouldFilter：判断该过滤器是否需要被执行（Criteria）。这里我们直接返回了true，因此该过滤器对所有的请求都生效。实际运行中我们可以利用该函数。
-
run：过滤器的具体执行逻辑（Action）。
在启动类中添加上这个过滤器：
@Bean
public AccessFilter accessFilter(){
return new AccessFilter();
}
此时，再访问 curl http://localhost:6069/hello-server/hello 接口时会报错，状态码为401，正确的访问姿势是：
curl http://localhost:6069/hello-server/hello?accessToken=666
过滤器的生命周期
Zuul中定义了4种标准的过滤器：pre、routing、post以及error，这些过滤器类型对应于请求的典型生命周期。我们参考下面的生命周期图来讲述一下这4种过滤器的作用以及执行顺序。
外部HTTP请求到达API网关服务的时候，首先它会进入第一个阶段pre，在这里它会被pre类型的过滤器进行处理。该类型过滤器的主要目的是在进行请求路由之前做一些前置加工，比如权限限制等。
在完成了pre类型的过滤器处理之后，请求进入第二个阶段routing，也就是路由请求转发阶段，请求将会被routing类型的过滤器处理。这里的具体处理内容就是将外部请求转发到具体服务实例上去的过程，当服务实例请求结果都返回之后，routing阶段完成，请求进入第三个阶段post。
此时请求将会被post类型的过滤器处理，这些过滤器在处理的时候不仅可以获取到请求信息，还能获取到服务实例的返回信息，所以在post类型的过滤器中，我们可以对处理结果进行一些加工或转换等内容，比如为响应添加标准的HTTP Header、收集统计信息和指标等。
另外，还有一个特殊的阶段error，该阶段只有在上述三个阶段中发生异常的时候才会触发。我们通过下面的过滤器执行流程图来加深一下对error过滤器的理解。
一般来讲，正常流程是pre -> route -> post。如果在pre过滤器阶段抛出异常，那么流程是：pre -> error -> post；如果在route过滤阶段抛出异常，那么流程是：pre -> route -> error -> post；如果在post过滤阶段抛出异常，最终流程是：pre -> route -> post -> error。
除了默认的过滤器类型，Zuul还允许我们创建自定义的过滤器类型。例如，我们可以定制一种STATIC类型的过滤器，直接在Zuul中生成响应，而不将请求转发到后端的微服务。
过滤器是Zuul实现API网关功能最核心的部件，每一个进入Zuul的HTTP请求都会经过一系列的过滤器处理链得到请求响应并返回给客户端。就以Zuul的路由功能为例，路由功能在真正运行时，它的路由映射和请求转发都是由几个不同的过滤器完成的。其中，路由映射主要通过pre类型的过滤器完成，它将请求路径与配置的路由规则进行匹配，以找到需要转发的目标地址；而请求转发的部分则是由route类型的过滤器来完成，对pre类型过滤器获得的路由地址进行转发。
Zuul的架构
下图展示了Zuul Core的工作原理，根据此图，我们可以更好地理解Zuul。
Zuul 的过滤器基本上是由 Groovy 语言编写的，这些过滤器起初以文件（以.groovy结尾）的形式存放在特定的目录下面。Zuul中的 FilterFileManager 会定期轮训这些目录，新加入的或者修改过的过滤器会被动态的加载进来。FilterFileManager 读取完 .groovy 文件之后会使用 GroovyComplier 将其编译成为JVM Class，之后再实例化（Class.newInstance）成 ZuulFilter 对象（即过滤器），最终保存在 FilterRegistry 中。FilterRegistry 是图中 FilterLoader 包含的一个对象，所以我们可以说成是：ZuulFilter 对象最终保存在FilterLoader中。
FilterRegistry可以看成是一个ConcurrentHashMap，其中key为.groovy文件的路径，value是动态加载之后的ZuulFilter对象。
Zuul的过滤器之间没有直接的相互通信，他们之间通过一个RequestContext（也可以看成是一个ConcurrentHashMap）来进行数据传递的。RequestContext 类中由 ThreadLocal 变量来记录每个 Request 所需要传递的数据。
当一个请求进入 Zuul 时，首先是交由 ZuulServlet 处理，ZuulServlet 中有一个ZuulRunner对象，该对象中初始化了前面所说的RequestContext。ZuulRunner中还有一个FilterProcessor，这个FilterProcessor从FilterLoader（FilterRegistry）中获取ZuulFilter(s)。有了这些ZuulFilter(s)之后，ZuulServlet首先执行的pre类型的过滤器，再执行route类型的过滤器，最后执行的是post 类型的过滤器，如果在执行这些过滤器有错误的时候则会执行error类型的过滤器。执行完这些过滤器，最终将请求的结果返回给客户端。
Zuul 2.x
5 月 21 日，Netflix 在其官方博客上宣布正式开源微服务网关组件 Zuul 2（Zuul是 Netflix 于 2013 年 6 月 12 日开源的，为了便于区分，下面都将前面所讲的 Zuul 表述为 Zuul 1）。Zuul 2 和 Zuul 1 在架构方面的主要区别在于，Zuul 2 运行在异步非阻塞的框架上，比如 Netty。Zuul 1 依赖多线程来支持吞吐量的增长，而 Zuul 2 使用的 Netty 框架依赖事件循环和回调函数。
Zuul2是一个在 Netty 上运行一系列Filter的服务，执行完成inbound filters之后将请求通过 Netty Client 转发出去，然后将请求的结果通过一系列outbound filters返回，如上图所示。正如之前的ZuulFilter分为了pre、post、routing、error，Zuul 2的Filter分为三种类型：
-
Inbound Filters: 在路由之前执行
-
Endpoint Filters: 路由操作
-
Outbound Filters: 得到相应数据之后执行
Zuul 2大体架构如上图所示，和Zuul 1没有本质上的区别。之前ZuulFilter分为了pre、post、routing、error，Zuul 2的Filter分为三种类型：inbound、endpoint、outbound。在Zuul 2中，过滤器前端用Netty Server代替了原本 Zuul 1中的Servlet，后端过滤器使用Netty Client 代替了HttpClient，这样前后端都可以支持异步（Zuul1可以使用Servlet 3.0规范支持的AsyncServlet进行优化，可以实现前端异步，支持更多的连接数，达到和Zuul2一样的效果）。相比如Zuul 1，Zuul 2在功能上也丰富和优化了很多，比如对HTTP/2、WebSocket的支持。
Zuul 1 vs Zuul 2
Zuul1设计比较简单，代码不多也比较容易读懂，它本质上就是一个同步Servlet，采用多线程阻塞模型，如下图所示。
同步Servlet使用thread per connection方式处理请求。简单讲，对于每一个新入站的请求，Servlet容器都要为其分配一个线程，直到响应返回客户端这个线程才会被释放返回容器线程池。如果后台服务调用比较耗时，那么这个线程就会被阻塞，阻塞期间线程资源被占用，不能执行其他任务。Servlet容器线程池的大小是有限制的，当前端请求量大，而后台慢服务比较多时，很容易耗尽容器线程池内的线程，造成容器无法接受新的请求，Netflix为此还专门研发了Hystrix熔断组件来解决慢服务耗尽资源问题。
这种同步阻塞模式编程模型比较简单，整个请求->处理->响应的流程(call flow)都是在一个线程中处理的，开发调试也便于理解，Debug也比较方便。不过，同步阻塞模式一般会启动很多的线程，必然引入线程切换开销。另外，同步阻塞模式下，容器线程池的数量一般是固定的，造成对连接数有一定限制，当后台服务慢，容器线程池易被耗尽，一旦耗尽容器会拒绝新的请求，这个时候容器线程其实并不忙，只是被后台服务调用IO阻塞，但是干不了其它事情。
总体上，同步阻塞模式比较适用于计算密集型(CPU bound)应用场景。对于IO密集型场景(IO bound)，同步阻塞模式会白白消耗很多线程资源，它们都在等待IO的阻塞状态，没有做实质性工作。
Zuul2的设计相对比较复杂，代码也不太容易读懂，它采用了Netty实现异步非阻塞编程模型，如下图所示。
如果需要阅读 Zuul 2源码，通过《[Zuul2源码分析](http://springcloud.cn/view/344)》这篇文章辅助一下也许会事半功倍。
在上图中，你可以简单理解为前端有一个队列专门负责处理用户请求，后端有个队列专门负责处理后台服务调用，中间有个事件环线程(Event Loop Thread)，它同时监听前后两个队列上的事件，有事件就触发回调函数处理事件。这种模式下需要的线程比较少，基本上每个CPU核上只需要一个事件环处理线程，前端的连接数可以很多，连接来了只需要进队列，不需要启动线程，事件环线程由事件触发，没有多线程阻塞问题。
异步非阻塞模式启动的线程很少，使用的线程资源少，上下文切换开销也少。非阻塞模式可以接受的连接数大大增加，可以简单理解为请求来了只需要进队列，这个队列的容量可以设得很大，只要不超时，队列中的请求都会被依次处理。异步模式让编程模型变得复杂。异步模型没有一个明确清晰的请求->处理->响应执行流程，它的流程是通过事件触发的，请求处理的流程随时可能被切换断开，内部实现要通过一些关联id机制才能把整个执行流再串联起来，这就给开发调试运维引入了很多复杂性，比如你在IDE里头调试异步请求流就非常困难。
总体上，异步非阻塞模式比较适用于IO密集型(IO bound)场景，这种场景下系统大部分时间在处理IO，CPU计算比较轻，少量事件环线程就能处理。
至于Zuul1和Zuul2的性能比对，Netflix给出了一个比较模糊的数据，大致Zuul2的性能比Zuul1好20%左右，这里的性能主要指每节点每秒处理的请求数。为什么说模糊呢？因为这个数据受实际测试环境，流量场景模式等众多因素影响，你很难复现这个测试数据。即便这个20%的性能提升是确实的，其实这个性能提升也并不大，和异步引入的复杂性相比，这20%的提升是否值得是个问题。Netflix本身在其Blog [References 5] 和 ppt [References 8] 中也是有点含糊其词，甚至自身都有一些疑问的。
那么问题来了，你选则使用Zuul1还是Zuul2, 或者是Spring Cloud Gateway，亦或者是Kong?
想知道更多？扫描下面的二维码关注我
