OpsGenie是一家DevOps管理工具公司，我们在人员和产品功能方面一直在积极发展。去年我们的工程团队从15个增长到了50个。为了扩大开发团队，我们通过遵守双比萨团队规则将工程力量分为八人一个团队。

目前我们的产品有点庞大。团队实现并行开发工作，用CI / CD（持续集成/持续交付）流程等。我们一直正在关注当前的流行趋势，并正在从单体转向微服务架构。您可以阅读Martin Fowler的微服务文章，理解更多关于微服务架构及其好处，有少量适使用于微服务的架构模式。其中一种模式就是API网关。

API网关是所有用户端的单一入口点。API网关将请求路由到适当的服务。

API网关模式是微服务体系结构的一个很好的起点，由于它使特定的请求能够路由到我们从单体中分离出来的不同服务。

其实API网关对我们来说不是一个新概念。到目前为止，我们已经在单体应使用程序之前用Nginx作为API网关，但是我们想要在切换微服务的背景下重新评估我们的决定。我们关心性能，易扩展性和额外的功能，如限速。

第一步是在重负载下评估替代方案的性能，以确保它们的规模足以满足我们的需求。

在这篇博客文章中，我们解释了如何设置我们的测试环境，并比较候选API网关的性能：Zuul 1，Nginx，Spring Cloud Gateway和Linkerd。

事实上，我们有其余的选择，如Lyft的Envoy和UnderTow。我们将用这些工具执行相似的测试，并在未来的博客文章中分享结果。

Zuul 1似乎对我们很有前途，由于它是使用Java开发的，并且拥有Spring框架的强大支持。已经有少量博客文章比较Zuul和Nginx，但是我们也想评估Spring Cloud Gateway和Linkerd的性能。此外，我们打算进行进一步的负载测试，所以我们决定设置我们自己的测试工作台。

为了独立评估API网关的性能，我们创立了独立于OpsGenie产品的独立测试环境。我们用Apache Http Server Benchmarking工具 – ab作为基准。

根据官方的Nginx文档，我们首先将Nginx安装到AWS EC2 t2.micro实例。这个环境是我们最初的测试环境，我们在这个环境中添加了Zuul和Spring Cloud Gateway安装。Nginx Web服务器托管静态资源，我们为Nginx，Zuul和Spring云网关定义了Web服务器的反向代理商。我们还启动了另一个t2.micro EC2来执行请求（用户端EC2）。

测试方式：

1.直接访问

2.通过Nginx反向代理商访问

3.通过Zuul访问

4.通过Spring云网关访问

5.通过Linkerd访问

我们知道你可能急不可耐地想看到结果，所以我们先给出结果，稍后再给出详细结果。

性能基准总结

测试策略

我们用了Apache HTTP Server Benchmarking工具。我们在每次测试中用200个并发线程完成了总共10,000个请求。

ab -n 10000 -c 200 HTTP:///

我们对三种不同的AWS EC2服务器配置进行了测试。我们在每一步缩小了测试使用例的范围：

1.我们在第一步中执行了一个额外的直接访问测试，以查看代理商的开销，但因为直接访问对我们来说不是选项，所以我们没有在以下步骤中执行此测试。

2.因为Spring Cloud Gateway尚未正式发布，因而我们仅在最后一步对其进行评估。

3.在第一次测试通过之后，Zuul的体现会更好。我们认为这可能是第一次调使用JIT（Just In Time）的优化，所以我们把Zuul的第一个叫做“Warmup”。以下汇总表中显示的数值是在热身体现之后。

4.我们知道Linkerd是一个资源密集型的代理商，所以我们只是在最后一步使用最高的资源配置进行比较。

测试配置

T1.Micro – 单核CPU，1GB内存：我们运行了直接访问，Ngnix反向代理商和Zuul（热身后）的测试。

M4.Large – 双核CPU，8GB内存：我们比较了Nginx反向代理商和Zuul（热身后）的性能。

M4.2xLarge – 8核CPU，32GB内存：我们比较了Nginx反向代理商，Zuul（预热后），Spring Cloud Gateway和Linkerd的性能。

检测结果

绩效基准汇总如下：

1.Micro – 单核CPU情况下：

（1）直接访问：每秒6519.68个请求，每个请求花费时间30.676ms

（2）Nginx：每秒4888.24个请求, 每个请求花费时间40.915ms

（3）Zuul: 每秒950.57个请求, 每个请求花费时间210.399ms

2.在M4.Large – 双核CPU情况下：

（1）Nginx：每秒6187.14个请求，每个请求花费时间32.325ms

（2）Zuul: 每秒2099.93个请求，每个请求花费时间95.241ms

3.在M4.2xLarge – 8核CPU情况下：

（1）zuul:每秒7036.9个请求，每个请求花费时间28.422ms

（2）Linkerd: 每秒6995个请求，每个请求花费时间28.592ms

（3）Nginx: 每秒6233.4个请求，每个请求花费时间32.085ms

（4）Spring Cloud Gateway：每秒873.14个请求，每个请求花费时间229.058ms

Spring Cloud Gateway每秒可以解决873个请求，每个请求的平均时间为229ms。根据我们的测试，Spring Cloud Gateway的性能无法达到Zuul，Linkerd和Nginx的水平，至少在Github的当前代码库就是这种情况。