在微服务架构下，网关的本质，其实就是对请求进行路由转发，在此基础上我们可以根据网关在整个微服务架构中的特殊位置，对请求进行前置和后置的处理。

请求转发和路由：网关类似于一个门面，微服务的组织细节对外界来说是不可知的，网关作为统一的接口提供方，将部分微服务系统的能力提供给客户端

请求过滤和控制：主要包含鉴权、限流、参数统一加密解密等

常见的开源网关方案有：Zuul、GateWay

---

Zuul：Netflix公司开源的一款为服务网关，主要功能是实现请求的转发和过滤控制。它定义了4种过滤器：Pre Filters、Routing Filters、Post Filters和Error Filters。

当请求进来时，先经过前置过滤器Pre Filters，所以这个过滤器常用作权限校验、参数解密和限流操作，此时如果发生错误，则会调用错误过滤器Error Filters；

当请求通过Pre Filters后，通过路由过滤器Routing Filters，将请求转发到不同的微服务进行处理，如果在执行过滤器逻辑过程中，或在调用微服务处理期间发生错误，则会调用错误过滤器Error Filters；

当请求经微服务正常处理之后，则调用后置过滤器Post Filters，后置过滤器一般会用作一些数据统计和监控，我们可以采用Prometheus的手段采集到微服务的调用时间和接口调用次数的数据，统计得到相应的热点接口予以性能优化。期间如果发生调用错误，也会调用错误过滤器Error Filters；

---

GateWay：是Spring官网团队研发的一款API网关。主要目的是为了取代Zuul。

Zuul存在一个问题，就是在处理一个请求的时候，Zuul内部会专门创建一个线程去进行请求的处理，并且只有当请求完成才会释放这个线程。这就导致线程在高并发场景下会被阻塞，降低系统的整体吞吐能力，影响服务的稳定运行。

看得出来Zuul初期是基于BIO模型进行设计的。后来Netflix团队也意识到这个问题，但因为迟迟未能完成版本更新，所以Spring团队决定采用非阻塞IO的模型来开发网关产品。

GateWay是依赖于SpringBoot2.x、Spring WebFlux和Reactor等技术进行开发，不仅提供了统一的路由请求方式，还基于过滤链的方式提供了网关的过滤控制功能。

---

GateWay的基本架构图：

 一句话描述：GateWay启动时，内置的Netty Server监听指定端口。当客户端的请求到达Gateway时，它将基于Predicate的匹配结果，计算得到访问的路由Router，然后通过Router中的Filter链进行请求的处理。处理的过程和Zuul的那四类Filter的处理流程大致相同，就不再赘述。

---

GateWay支持多种路由匹配的Predicate：

1.基于Header的路由匹配

2.基于Host的路由匹配

3.基于请求路径的路由匹配

4.基于请求方式的路由匹配

5.基于Cookie的路由匹配

6.基于时间的路由匹配，常用于做灰度发布

如果需要更详细信息，可以移步官网进行了解

---

GateWay内的过滤器分为前置过滤器和后置过滤器。它内部内置了很多过滤器，分类一共有两类，即GatewayFilter和GlobalFilter。GlobalFilter的作用域是所有请求，而GatewayFilter仅会作用域单个路由或者若干个分组的路由上。

此外，如果GateWay提供的Filter不能满足需求的话，它也提供了自定义扩展的功能，通过自定义继承AbstractGatewayFilterFactory或实现GlobalFilter即可完成扩展。