导语:API Gateway是实现微服务重要的组件之一。面对诸多的开源API Gateway,如何进行选择也是架构师须要关注的焦点。本文做者对几个较大的开源API Gateway进行了压力测试,对于架构师来讲,相信能够提供很多帮助。
过去一段时间,OpsGenie的员工数量和产品特性都经历了快速发展。去年,仅仅是咱们的工程师团队就由15人增加到了50人。针对开发团队的划分,咱们遵循两个披萨原则[1]将每一个团队控制在8个工程师。
如你所料的,咱们的产品仍是一个单体应用。对并行开发的团队来讲,CI/CD等过程,开发和运维都是有挑战的。咱们跟随当前的技术趋势,正处于单体应用到微服务架构的过渡期。你能够阅读Martin Fowler的这篇文章[2],了解更多微服务架构和它的好处。
这里有一些关于微服务概念推荐的架构模式[3]。其中的一个模式是API网关[4]。API网关是全部客户端的统一入口。API网关对于任意一种处理请求有两种方式处理。一部分请求只要简单路由到相应的服务;还有一些请求须要拆分到多个服务。
API网关模式是开始微服务架构很好的切入点,由于它能路由具体的请求到拆分出来的不一样服务。事实上,API网关对咱们来讲不是一个新概念。到目前为止,咱们已经使用过Nginx放在咱们的单体应用前面充当API网关,可是咱们想从新评估过渡时期继续使用Nginx的合理性。咱们关心性能、可扩展性和其余的扩展能力,例如限流。首先,评估大流量下的性能,确保它们能知足咱们的需求。
在这篇文章中,咱们讲解如何设置咱们的测试环境,而且对比这些网关的性能: Zuul 1[5], Nginx[6], Spring Cloud Gateway[7], Linkerd[8]。事实上,咱们还有另外两个选择Envoy[9]和 UnderTow[10]。咱们将会对这些工具作相同的测试,而且在后面的博客中公布测试结果。
Zuul 1因为使用Java开发,而且对Spring框架有很强的支持,对咱们来讲彷佛很合适。尽管有不少文章对比过Zuul和Nginx,可是咱们还想跟Spring Cloud Gateway和Linkerd一块儿评估。此外,咱们计划作高负载的测试,因此咱们决定设置咱们本身的测试环境。
为了评估API网关各自的性能,咱们为OpsGenie产品建立了一个隔离的独立测试环境。咱们使用Apache的ab做为压测工具。
首先,咱们参照Nginx文档在一个单核1G内存的AWS EC2实例上安装了一个Nginx。这个环境是咱们的初始测试环境,而后咱们安装Zuul和Spring Cloud Gateway到这个环境中。Nginx为静态资源提供web服务,咱们经过Nginx、Zuul和Spring Cloud Gateway定义反向代理到这个web服务。咱们一样启动了另一个单核1G内存的EC2实例发起压测请求。
图片中的箭头是咱们的测试路径。这里有4中状况:
- 直接访问
- Nginx反向代理访问
- Zuul访问
- Spring Cloud Gateway访问
- Linkerd访问
咱们知道你们急于想看测试结果,因此,咱们先给测试结果,而后再作详细说明。
性能压测总结
测试策略
咱们使用Apache的ab作压测工具。咱们发起总共10000个请求、使用200个并发线程分别进行压测。
咱们将在3种不一样配置的AWS EC2服务器上进行测试。咱们会缩小每一步的测试用例的范围:
- 尽管咱们不选择直接访问,可是咱们在第一步额外作了直接访问的测试,用于衡量代理的理想值,这个测试咱们不会在后面的步骤中进行。
- 尽管Spring Cloud Gateway依然没有官方稳定版,咱们会在最后那步评估它。
- Zuul随后的性能比第一次压测的性能更好。咱们估计出现这种状况的缘由是第一次压测进行了JIT优化,因此咱们把针对Zuul的第一次压测当成“预热”。在总结表中的值是预热以后的性能。
- 咱们知道Linkerd是资源密集型代理,因此咱们只在高资源配置的最后一步对比。
测试配置
T2.Micro——单核1G内存:咱们对比测试直接访问、Nginx反向代理和Zuul(预热以后)。
M4.Micro ——双核8G内存:咱们对比测试Nginx反向代理和Zuul(预热以后)。
M4.2xLarge——8核32G内存:咱们对比测试Nginx反向代理、Zuul(预热以后)、Spring Cloud Gateway和Linkerd。
测试结果
性能压测结果以下
测试详情
直接访问
首先,咱们不使用代理,直接访问静态资源。结果以下,单个请求平均30ms。
Nginx反向代理
咱们的第2个测试,经过Nginx反向代理访问资源。单次请求平均耗时40ms。能够说,Nginx代理对比直接访问,平均增长了33%的耗时。
Zuul反向代理
接下来,咱们建立了一个Spring Boot应用:
这是咱们的application.yml文件:
Zuul第1次测试结果以下:
直接访问Nginx单次请求是30ms,经过Nginx反向代理访问是40ms。Zuul首次访问单次请求在388ms。如在另一篇博客[12]中提到的,JVM预热会有做用。咱们从新压测,结果以下:
预热后Zuul代理的性能更好(单次请求是200ms),可是跟Nginx反向代理的40ms对比,仍然很差。
服务器升级到双核8G内存会怎么样呢?
前面的测试服务器配置是单核1G内存。Nginx是C++应用,Zuul是基于Java的。咱们知道,Java应用对环境要求更苛刻。因此咱们将服务器配置换成双核8G内存实例。
咱们从新对Nginx和Zuul作压测,结果以下
由上面图片可见,Nginx反向代理和Zuul代理单次请求花费时间分别是32ms和95ms。此次压测结果比单核1G内存的40ms和200ms更好。
因而可知,使用Spring Boot部署的Zuul有额外的消耗。极可能Zuul的独立应用会有更好的性能。
服务器升级到8核32G内存会怎么样呢?
咱们继续评估8核32G内存的服务器配置。Nginx和Zuul的压测结果以下
在8核32G的配置上,Zuul跑赢了Nginx。咱们想找到Netflix的Zuul实例部署在哪一种类型的ec2服务器上,可是咱们没有找到任何信息。一些博客中,有人说了Zuul的性能,而且询问Netflix如何处理的。咱们认为这多是答案,Zuul使用CPU绑定。
Linkerd压测
Linkerd是CNCF的项目,是Scala开发的service mesh应用。他提供反向代理能力用于扩展service mesh能力,例如服务发现。咱们评估Linkerd性能而且给出以下结果。Linkerd跟Zuul的性能很接近。
Spring Cloud Gateway性能测试
Spring Cloud组织也开发了一个Gateway模块。尽管官方尚未正式版本,咱们以为仍是有必要跟其余选择进行对比。可是,咱们按照咱们的测试环境修改了Gateway的例子。
咱们用Apache的ab使用了20个线程、发了总共10000个请求作了一样的压测。测试结果在下面这张图中:
由上图可见,Spring Cloud Gateway每秒能处理873个请求,单次请求平均耗时229ms。根据咱们的测试结果,Spring Cloud Gateway不能达到Zuul、Linkerd、Nginx的性能水平,这是他们目前最新版本测试的结果。Nginx、Zuul、Linkerd和Spring Cloud Gateway的最后一次测试结果上面已经给出。
接下来呢?
这篇文章中,咱们使用Apache的工具ab对比了Zuul、Nginx、Linkerd和Spring Cloud Gateway的性能。下一步咱们的计划以下:
- 咱们计划去评估Envoy。事实上,Envoy不止是API网关,它是service mesh,可是也提供了API网关功能,能放在应用的前面。
- Undertow也有反向代理能力,因此咱们也计划去评估一下。
- Netflix基于Netty的非阻塞从新设计了Zuul应用,新的版本叫“Zuul 2”。若是官方发布了新版本的Zuul,咱们也会进行性能压测,而后将压测结果分享出来。
- Spring Cloud Gateway依然在开发中,基于Netty的非阻塞的Java网关,因此对咱们来讲是一个很好的候选。咱们将会评估它的官方稳定版的性能。
- 一些API网关(Zuul 1)是阻塞的,另一些(Zuul 二、Linkerd、Envoy)是非阻塞的。阻塞架构对开发和跟踪请求友好,可是阻塞可能产生扩展性问题。非阻塞架构对于团队开发和跟踪更复杂,可是有更好的可扩展和弹性。咱们以后将会决定使用阻塞架构仍是使用非阻塞架构。
- 咱们将使用Gatling作性能测试,将在咱们的下一篇博客中共享结果。
咱们将会在博客中共享每一步的成功结果,敬请期待!
文中连接
[1] http://www.businessinsider.com/jeff-bezos-two-pizza-rule-for-productive-meetings-2013-10
[2] https://martinfowler.com/articles/microservices.html
[3] http://microservices.io/patterns/microservices.html
[4] http://microservices.io/patterns/apigateway.html
[5] https://github.com/Netflix/zuul
[6] http://www.nginx.com/
[7] https://github.com/spring-cloud/spring-cloud-gateway
[8] https://linkerd.io/
[9] http://envoyproxy.io/
[10] http://undertow.io/
[11] https://httpd.apache.org/docs/2.4/programs/ab.html
[12] http://instea.sk/2015/04/netflix-zuul-vs-nginx-performance/
[13] https://gatling.io/
本文做者Turgay Çelik,由邓启明翻译,转载本文请注明出处,技术原创及架构实践文章,欢迎经过公众号菜单「联系咱们」进行投稿。
相关阅读:
高可用架构