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

从介绍来看，linkerd 是我们面向微服务的开源 RPC 代理，它直接立足于 Finagle(Twitter 的内部核心库，负责管理不同服务间之通信流程。事实上，Twitter 公司的每一项在线服务都立足于 Finagle 构建而成，而且其支持着每秒发生的成百上千万条 RPC 调用)构建而成，设计目标在于帮助用户简化微服务架构下的运维，它是专用于处理时间敏感的服务到服务的通信基础设施层。

和 Spring Cloud 类似，Linkerd 也提供了负载均衡、熔断机器、服务发现、动态请求路由、重试和离线、TLS、HTTP 网关集成、透明代理、gRPC、分布式跟踪、运维等诸多功能，功能是相当全了，为微服务框架的技术选型又增加了一个。由于没有接触过 Linkerd，所以暂时无法从架构层面进行分析，后续会补充这方面的内容，自己来做一次技术选型。

性能测试结果

Turgay Çelik 博士的那篇文章里使用了 Apache 的 HTTP 服务器性能评估工具 AB 作为测试工具。注意，由于他是基于亚马逊(AWS)公有云的进行的测试，可能和你实际物理机上的测试结果有出入。

实验中启动了客户端和服务端两台机器，分别安装多个待测试服务，客户端通过几种方式分别访问，尝试获取资源。测试方案如下图所示：

测试选择了三个环境，分别是：

1. 单 CPU 核，1GB 内存：用于比较 Nginx 反向代理和 Zuul(去除第一次运行后的平均结果);
2. 双 CPU 核，8GB 内存：用于比较 Nginx 反向代理和 Zuul(去除第一次运行后的平均结果);
3. 8 个核 CPU，32GB 内存：用于比较 Nginx 反向代理、Zuul(去除第一次运行后的平均结果)、Spring Cloud Zuul、Linkerd。

测试过程均采用 200 个并行线程发送总共 1 万次请求，命令模板如下所示：

ab -n 10000 -c 200 HTTP://<server-address>/<path to resource> 

注意：由于 Turgay Çelik 博士的测试过程中是基于 Zuul 1 进行的测试，所以性能上较差，不能真实反映当前 Zuul 版本的性能状况。

从上面的结果来看，单核环境下，Zuul 的性能最差(950.57 次 /s)，直接访问方式性能最好(6519.68 次 /s)，采用 Nginx 反向代理方式较直接访问方式损失 26% 的性能(4888.24 次 /s)。在双核环境下，Nginx 的性能较 Zuul 性能强接近 3 倍(分别是 6187.14 次 /s 和 2099.93 次 /s)。在较强的测试环境下(8 核)，直接访问、Nginx、Zuul 差距不大，但是 Spring Cloud Zuul 可能由于内部整体消耗，导致每秒的请求数只有 873.14。

最终结论

（编辑：晋中站长网）

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