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。

最终结论

（编辑：湖南网）

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