现在的架构基本都是使用微服务的，而网关作为微服务的统一门户在架构模式中用得越来越多，API网关是所有客户端的单一入口点。
API网关模式是微服务体系结构的一个很好的起点，因为它能够将特定的请求路由到我们从整体上分离的不同服务。事实上，API网关并不是我们的新概念。到目前为止，我们一直在使用。Nginx作为API网关在我们的整块应用程序前面，但是我们希望在微服务转换的背景下重新评估我们的决定。
我们关心的性能，易于扩展性和额外的能力，如速率限制。第一步是评估在重载下的备选方案的性能，以确保它们的规模足以满足我们的需要。
在这篇博客文章中，我们将解释如何设置测试环境并比较下面API网关的性能：
- Zuul
- Nginx
- SpringCloud Gateway
- Linkerd
事实上，我们还有其他选择，比如[Envoy和[UnderTow..我们将使用这些工具进行类似的测试，并在的博客文章中分享结果
Zuul视乎还是挺好的，因为它是用Java开发的，并且有Spring框架的强大支持。已经有一些博客文章比较ZUUL和NGIXX，但我们也想评估Spring cloud gateway和Linkerd的性能。此外，我们计划进行进一步的负载测试，所以我们决定设置自己的测试任务。
我们首先安装NGIX到AWS EC2 T2微实例，根据官方的NGNX文档。这个环境是我们的初始测试环境，并且我们将ZUUL和Spring cloud Gateway安装添加到这个环境中。NGNIX Web服务器托管静态资源，并为NGIX、ZUUL和cloud Gateway定义了反向代理。我们还启动了另一个T2微服务EC2来执行请求（客户端EC2）。
图中的虚线箭头是我们的测试路径。其中有五个：
- 直接存取
- 通过NGIX反向代理访问
- 通过ZUL访问
- 通过Spring云网关访问
- 通过Linkerd访问
我们知道你不耐烦地看到结果，所以让我们先给出结果，然后再详细说明。
1.1. 性能基准总结
1.1.1. 测试策略
我们使用Apache HTTP服务器基准工具。在每次测试运行中，我们用200个并发线程完成了10000个总请求。
ab -n 10000 -c 200 HTTP://<server-address>/<path to resource>
我们在三个不同的AWS EC2服务器配置上进行了测试。我们在每一步缩小测试用例以获得最终的结果
1、我们在第一步中执行了额外的直接访问测试来查看代理的开销，但是由于直接访问不是我们的选择，所以我们没有在下面的步骤中执行这个测试。
2、由于Spring Cloud Gateway 使用部是特别多，再最后一步再进行测试。
3、ZUUL的性能在第一次调用后的后续调用更好。我们认为这可能是由于JIT（准时）优化在第一次调用上进行的，所以我们称ZUUL运行的第一个为“热身”所以下面的汇总表中显示的值是在预热性能之后。
4、我们知道Linkerd是一个资源密集型的代理，所以我们在最后一个步骤与最高的资源配置进行了比较。
1.2. 测试配置
T2、Micro 单核CPU、1GB内存：我们运行直接访问、NGNIX反向代理和ZUUL（热身后）的测试。
M4.Large 双核CPU，8GB的内存：我们比较了NGIX反向代理和ZUUL（热身后）的性能。
M4.2xLarge 8内核CPU，32GB内存：我们比较了NGIX反向代理、ZUUL（热身后）、Spring cloud gateway和Linkerd的性能。
1.3. 测试结果
性能测试的结果如下
第一张图显示每一秒不同的网关处理的请求数，可见在硬件都很糟糕的情况下nginx是不错的选择，如果硬件性能都提升的情况下，Zuul和Linkerd性能能反超nginx
但是SpringCloud Gateway的性能有点让人失望
这个图也是同样，测试的是每次请求的平均时间，单位是毫秒，在单核cpu的情况下zuul表现确实差强人意，但一旦到了服务器的硬件条件下，zuul的性能确是4个中最好的
但是不管从哪个层面来看geteway的性能都不能让人满意
1.4. 测试详细
1.4.1. 直接访问
首先，我们在没有任何代理的情况下直接访问静态资源。结果如下。平均每次请求时间为30毫秒。
1.4.2. 通过nginx反向代理访问的情况
在第二个测试中，我们通过NGNX反向代理访问资源。每次请求的平均时间是40毫秒。我们可以说，与上一部分中所解释的直接访问相比，nginx的性能增加了部分开销
1.4.3. 使用Zuul来做代理的情况
在配置文件里面仅仅做些简单的路由配置，其中的yml文件如下：
最后zuul的测试结果如下：
直接访问和用nginx反向代理访问的时间为30ms和40ms，第一次使用zuul的请求时间是388ms,效果非常不理想，当然可以使用JVM预热，会对zuul的性能有所提升，下面是进一步测试的情况。
ZUUL代理在预热（每个请求的时间为200毫秒）后表现更好，但与40ms的NGIX反向代理相比，它仍然不太好。
上面做的测试是使用单核CPU和1G内存的服务器，Nginx是一个本地的C++应用测试，而ZUUL是JAVA开发的，我们知道Java应用程序有点：要求更高。因此，我们将服务器更改为具有两个CPU内核和8GB内存的M4大型实例。
我们再次运行了NGIX和ZUUL反向代理测试，结果如下：
如上述图所示，对于NGIX和ZUUL，每秒请求值分别为32毫秒和95ms。这些结果比T2微测试的结果要好得多，分别为40ms和200 ms。
一个有效的批评是，我们通过使用ZULL通过Spring启动应用程序引入额外的开销。如果我们将ZUUL作为独立的应用程序运行，它可能会运行得更好。
我们还评估了具有八个核心和32GB内存的M4.2X大型服务器。NGNIX和ZUUL的结果在下面的数字中给出：
如你所视，这个时候zuul的性能已经反超nginx了，很多人在抱怨zuul的性能太差，远远没有nginx的性能好，其实这样的看法其实还是太片面了，在真实的项目服务器情况下zuul的性能不会太差。
1.4.4. Linkerd的测试情况
这也是使用大型八个核心和32GB内存的M4.2X大型服务器，测试出的结果和zuul非常相近
1.4.5. SpringCloud Gateway测试情况
Geteway号称有取代其他网关的能力，所以在这也与其他的网关进行下比较，们进行了同样的性能测试。Apache HTTP服务器基准测试工具用200个并发线程发送10000个请求。结果如下图所示：
如图所示，Spring云网关可以处理每秒873个请求，平均请求时间为229毫秒。根据我们的测试，Spring云网关的性能达不到ZUUL、Linkerd和NGNIX的水平，至少情况是这样，这样的测试结果真让人大失所望！
