发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA

微服务API网关NGINX、ZUUL、Spring Cloud Gateway与

         
2018-01-12 13:17
赞助商链接

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的当前代码库就是这种情况。

更多测试细节见原文:

Comparing API Gateway Performances: NGINX vs. ZUUL

2
微服务      性能测试     

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com