内容简介：微服务API网关NGINX、ZUUL、Spring Cloud Gateway与
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://<server-address>/<path to resource>
我们对三种不同的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的当前代码库就是这种情况。
更多测试细节见原文：
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
Google成功的七堂课
罗耀宗 / 电子工业出版社 / 2005-7 / 28.00元
Google是全球使用人数最多的搜索引擎，在短短几年内，Google从斯坦福大学的实验室，茁壮成长为举世瞩目的IT业超级巨人，他们的成功绝非偶然，尤其是在网络泡沫破灭，行业一片萧条之际，它的崛起更为IT业带来一缕曙光。作者从趋势观察家的角度，以讲座的形式，向读者讲述Google成功的关键因素：破除因循守旧、不断打破常规，核心技术领先、做出了“更好的捕鼠器”，使得Google在搜索技术方面远远超越对......一起来看看 《Google成功的七堂课》 这本书的介绍吧!
