这样讲API网关，你应该能明白了吧( 二 ) _API网关

大多数的功能都在这一层完成，例如：验证，鉴权，负载均衡，协议转换，服务路由，数据缓存。如果没有其他两个子系统，它也是可以单独运行的。
Gateway-Admin 网关管理界面，可以进行 API、组件等系统基础信息的配置;例如：限流的策略，缓存配置，告警设置。
Gateway-Monitor 监控日志、生成各种运维管理报表、自动告警等;管理和监控系统主要是为核心系统服务的，起到支撑的作用。
API 网关技术原理
上面谈到了网关的架构思路，这里谈几点技术原理。平时我们在使用网关的时候，多注重其实现的功能。例如：路由，负载均衡，限流，缓存，日志，发布等等。
实际上这些功能的背后有一些原理我们可以了解，这样在应用功能的时候会更加笃定。下面是几个原理分享给大家。
协议转换
每个系统内部服务之间的调用，可以统一使用一种协议，例如：HTTP ， GRPC 。
假设每个系统使用的协议不同，那么系统之间的调用或者数据传输，就存在协议转换的问题了。如果解决这个问题呢?API 网关通过泛化调用的方式实现协议之间的转化。
实际上就是将不同的协议转换成“通用协议” ，然后再将通用协议转化成本地系统能够识别的协议。
这一转化工作通常在 API 网关完成。通用协议用得比较多的有 JSON ，当然也有使用 XML 或者自定义 JSON 文件的。

文章插图

不同的协议需要转化成共同语言进行传输
链式处理
设计模式中有一种责任链模式，它将“处理请求”和“处理步骤”分开。每个处理步骤，只关心这个步骤上需要做的处理操作，处理步骤存在先后顺序。
消息从第一个“处理步骤”流入，从最后一个“处理步骤”流出，每个步骤对经过的消息进行处理，整个过程形成了一个链条。在 API 网关中也用到了类似的模式。

文章插图

Zuul 网关过滤器链式处理
下面以 Zuul 为例，当消息出入网关需要经历一系列的过滤器。这些过滤器之间是有先后顺序的，并且在每个过滤器需要进行的工作也是各不一样：

PRE：前置过滤器，用来处理通用事务，比如鉴权，限流，熔断降级，缓存。并且可以通过 Custom 过滤器进行扩展。
ROUTING：路由过滤器，在这种过滤器中把用户请求发送给 Origin Server 。它主要负责：协议转化和路由的工作。
POST：后置过滤器，从 Origin Server 返回的响应信息会经过它，再返回给调用者。在返回的 Response 上加入 Response Header ，同时可以做 Response 的统计和日志记录。
ERROR：错误过滤器，当上面三个过滤器发生异常时，错误信息会进到这里，并对错误进行处理。

异步请求
所有的请求通过 API 网关访问应用服务，一旦吞吐量上去了，如何高效地处理这些请求?
拿 Zuul 为例， Zuul1 采用：一个线程处理一个请求的方式。线程负责接受请求，然后调用应用返回结果。
如果把网络请求看成一次 IO 操作的话，处理请求的线程，从接受请求，到服务返回响应，都是阻塞状态。
同时，如果多个线程都处在这种状态，会导致系统缓慢。因为每个网关能够开启的线程数量是有限的，特别是在访问的高峰期。

文章插图

每个线程处理一个请求
为了解决这个问题， Zuul2 启动了异步请求的机制。每个请求进入网关的时候，会被包装成一个事件， CPU 内核会维持一个监听器，不断轮询“请求事件” 。
一旦，发现请求事件，就会调用对应的应用。获取应用返回的信息以后，按照请求的要求把数据/文件放到指定的缓冲区，同时发送一个通知事件，告诉请求端数据已经就绪，可以从这个缓冲获取数据/文件。