API 网关性能比较：Nginx vs. Zuul vs. Spring Cloud Gateway vs. Linke

 API 网关

API 网关出现的原因是微服务架构的出现，不同的微服务一般会有不同的网络地址，而外部客户端可能需要调用多个服务的接口才能完成一个业务需求，如果让客户端直接与各个微服务通信，会有以下的问题：

1. 客户端会多次请求不同的微服务，增加了客户端的复杂性。
2. 存在跨域请求，在一定场景下处理相对复杂。
3. 认证复杂，每个服务都需要独立认证。
4. 难以重构，随着项目的迭代，可能需要重新划分微服务。例如，可能将多个服务合并成一个或者将一个服务拆分成多个。如果客户端直接与微服务通信，那么重构将会很难实施。
5. 某些微服务可能使用了防火墙 / 浏览器不友好的协议，直接访问会有一定的困难。

以上这些问题可以借助 API 网关解决。API 网关是介于客户端和服务器端之间的中间层，所有的外部请求都会先经过 API 网关这一层。也就是说，API 的实现方面更多的考虑业务逻辑，而安全、性能、监控可以交由 API 网关来做，这样既提高业务灵活性又不缺安全性，典型的架构图如图所示：

使用 API 网关后的优点如下：

• 易于监控。可以在网关收集监控数据并将其推送到外部系统进行分析。
• 易于认证。可以在网关上进行认证，然后再将请求转发到后端的微服务，而无须在每个微服务中进行认证。
• 减少了客户端与各个微服务之间的交互次数。

NGINX 服务

Nginx 由内核和模块组成，内核的设计非常微小和简洁，完成的工作也非常简单，仅仅通过查找配置文件与客户端请求进行 URL 匹配，用于启动不同的模块去完成相应的工作。

下面这张图反应的是 HTTP 请求的常规处理流程：

Nginx 的模块直接被编译进 Nginx，因此属于静态编译方式。启动 Nginx 后，Nginx 的模块被自动加载，不像 Apache，首先将模块编译为一个 so 文件，然后在配置文件中指定是否进行加载。在解析配置文件时，Nginx 的每个模块都有可能去处理某个请求，但是同一个处理请求只能由一个模块来完成。

Nginx 在启动后，会有一个 Master 进程和多个 Worker 进程，Master 进程和 Worker 进程之间是通过进程间通信进行交互的，如图所示。Worker 工作进程的阻塞点是在像 select()、epoll_wait() 等这样的 I/O 多路复用函数调用处，以等待发生数据可读 / 写事件。Nginx 采用了异步非阻塞的方式来处理请求，也就是说，Nginx 是可以同时处理成千上万个请求的。一个 Worker 进程可以同时处理的请求数只受限于内存大小，而且在架构设计上，不同的 Worker 进程之间处理并发请求时几乎没有同步锁的限制，Worker 进程通常不会进入睡眠状态，因此，当 Nginx 上的进程数与 CPU 核心数相等时(最好每一个 Worker 进程都绑定特定的 CPU 核心)，进程间切换的代价是最小的。

Zuul

Zuul 是 Netflix 开源的微服务网关组件，它可以和 Eureka、Ribbon、Hystrix 等组件配合使用。Zuul 的核心是一系列的过滤器，这些过滤器可以完成以下功能：

• 身份认证与安全：识别每个资源的验证要求，并拒绝那些与要求不符的请求。
• 审查与监控：与边缘位置追踪有意义的数据和统计结果，从而带来精确的生产视图。
• 动态路由：动态地将请求路由到不同的后端集群。
• 压力测试：逐渐增加指向集群的流量，以了解性能。
• 负载分配：为每一种负载类型分配对应容量，并弃用超出限定值的请求。
• 静态响应处理：在边缘位置直接建立部分响应，从而避免其转发到内部集群。
• 多区域弹性：跨越 AWS Region 进行请求路由，旨在实现 ELB(Elastic Load Balancing，弹性负载均衡)使用的多样化，以及让系统的边缘更贴近系统的使用者。

上面提及的这些特性是 Nigix 所没有的，这是因为 Netflix 公司创造 Zuul 是为了解决云端的诸多问题(特别是帮助 AWS 解决跨 Region 情况下的这些特性实现)，而不仅仅是做一个类似于 Nigix 的反向代理，当然，我们可以仅使用反向代理功能，这里不多做描述。

Zuul1 是基于 Servlet 框架构建，如图所示，采用的是阻塞和多线程方式，即一个线程处理一次连接请求，这种方式在内部延迟严重、设备故障较多情况下会引起存活的连接增多和线程增加的情况发生。

Zuul2 的巨大区别是它运行在异步和无阻塞框架上，每个 CPU 核一个线程，处理所有的请求和响应，请求和响应的生命周期是通过事件和回调来处理的，这种方式减少了线程数量，因此开销较小。又由于数据被存储在同一个 CPU 里，可以复用 CPU 级别的缓存，前面提及的延迟和重试风暴问题也通过队列存储连接数和事件数方式减轻了很多(较线程切换来说轻量级很多，自然消耗较小)。这一变化一定会大大提升性能，我们在后面的测试环节看看结果。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!