nginx 代理 内存_比较API网关性能：NGINX，ZUUL，Spring Cloud Gateway和Linkerd

作为OpsGenie，我们在员工人数和产品功能方面都在积极发展。为了给您一些想法，我们的工程团队从去年的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基准测试工具-ab作为基准测试。

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