网关介绍
在微服务架构中，一个系统会被拆分为很多个微服务，那么作为客户端要如何调用这么多微服务呢？如果没有网关的存在，我们只能在客户端记录每个微服务的地址，然后分别去调用。这样的话会产生很多问题。例如：
- 客户端多次请求不同的微服务，增加客户端代码或配置编写的复杂性；
- 认证复杂，每个微服务都有独立认证；
- 存在跨域请求，在一定场景下处理比较复杂。
为解决上面的问题，所以引入网关的概念：所谓API网关，就是指系统的统一入口，提供内部服务的路由运转，为客户端提供统一服务，，一些与业务本身功能无关的公共逻辑可以在这里实现，诸如认证、监控、路由、转发等。
网关架构图：
网关对比
-
Zuul 1.x
Nefix开源的网关，基于Servlet框架构建，功能丰富，使用java语言开发，易于二次开发。
问题：即一个线程处理一次连接请求，这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。
-
Zuul 2.x
zuul2采用了实现异步非阻塞编程模型，每个cpu核一个线程，处理所有的请求和响应，请求和响应的生命周期是通过事件和回调来处理的，这种方式就减少了线程数量，因此开销较小。
-
GateWay
Spring公司为了替换Zuul而开发的网关服务，底层为Netty，在后面详细介绍。
-
Nginx+lua
使用nginx的反向代理和负载均衡可实现对Api服务器的负载均衡及高可用，lua是一种脚本语言，可以来编写一种简单的逻辑，nginx支持lua脚本。
问题：无法融入到微服务架构中。
-
Kong基于nginx+lua开发，性能高，稳定，有多个可用的插件，限流、鉴权等等。
-
问题：只支持http协议；二次开发，扩展困难，提供管理api，缺乏更简单的管控和配置方式。
GateWay
Spring Cloud GateWay 基于 Springboot 2.x、Spring WebFlux和Project Reactor，为微服务架构提供一种简单有效的统一的API路由管理方式，它主要是替代Netflix Zuul，它不仅提供了统一的路由方式，而且基于Filter链的方式提供了网关的基本功能，例如：安全、监控、限流等。
特点：
- 性能强劲，是zuul的1.6倍；
- 功能强大，有很多实用的功能，如限流、监控、转发等；
- 设计精巧，容易扩展。
基本概念
路由（Route）是GateWay中最基本的组件之一，表示一个具体的路由信息载体，主要定义包含了以下几个信息：
- id：路由标识，用于区别其它Route；
- uri：路由指向的目的地uri，就是客户端请求最终转发到的微服务；
- order：多个路由之间的排序，数值越小排序越靠前，匹配的优先级越高；
- predicate：断言，进行条件判断，只有断言都返回真，才会真正的路由；
- filter：过滤器，用于修改请求和响应信息。
执行流程
- GateWay Client 向 GateWay Server发送请求；
- 请求首先会被HttpWebHandlerAdapter进行提取组装成网关上下文；
- 然后网关的上下文会传递到DispatcherHandler，它负责将请求分发给RoutePredicateHandlerMapping；
- RoutePredicateHandleMapping负责路由查找，并根据路由断言判断路由是否可用；
- 如果断言成功，有FilteringWebHandler创建过滤器链并调用；
- 请求会依次经过PreFilter--微服务--PostFilter的方法，最终返回响应。
总结
SpringCloud GateWay使用的是webflux中的reactor-netty响应式编程组件，底层是Netty通讯框架。