微信号:Top100Case

介绍:TOP 100软件案例研究峰会是科技界一年一度案例研究盛会,每年甄选有代表的100个技术创新/研发管理案例,旨在揭幕100件案例背后的思考、长尾价值,为听众提炼最佳学习路径,帮助他人的项目或团队获得启示、成长,...

微服务网关哪家强?一文看懂Zuul, Nginx, Spring Cloud, Link

2018-08-03 11:52 Turgay Çelik


本文转载自微信平台“高可用架构”。原作者Turgay Çelik,由邓启明翻译。


导语: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 2、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/





2018最新案例征集中


TOP100summit是科技界一年一度的案例研究峰会,每年甄选有学习价值的100个技术创新/研发管理实践,分享他们在本年度最值得的总结、盘点的实践启示;TOP100summit于2018年12月1-3日在北京国家会议中心举办,与其在别处仰望,不如来这里并肩。



入选标准

1. 您带领的产品或项目案例(再或从事的工程实践)具有借鉴价值,能够帮助他人的项目或团队获得启示、成长的长尾效应;

2. 您是一位热爱创新、敏于思考、善于总结经验的“教练”;

3. 谢绝广告、市场化公关演讲,壹佰案例遵循100%案例研究学习为宗旨;


您将获得

1. 候选案例入选《案例研究智库》平台,其中优秀案例文稿入选《全球软件案例研究年鉴》图书,部分杰出文章还有机会获得业界权威杂志刊登、媒体报道、副刊专辑;

2. 入选壹佰案例的分享者或所在团队荣获《TOP 100 Case Studies Of The Year》奖章,并受邀以“理事单位”的身份出席峰会解读案例;

3. 分享者获得VIP通行证,参加全程会议,以及三天闭门交流午宴和晚宴;

4. 分享者所在团队购买大会门票享有“理事单位”六折门票价格;


入选范围

1. 来自科技领域一线研发管理实践及技术创新案例;

2. 截止日期2018年9月30日;


如果你或你所在的研发团队有优秀的技术研发创新案例,欢迎自荐加入;如果你身边的朋友也有好的案例,不妨点击“阅读原文”一起提交给我们吧!

 
壹佰案例 更多文章 运维绝不是背锅、填坑和救火,价值在于持续集成与交付! 3天破9亿!上万条评论解读《西虹市首富》是否值得一看 终于有人把云计算、大数据和人工智能讲明白了! 平台化测试难度大?京东教你如何用无人测试实现产品质量效率双提升 从Memcache转战Redis,聊聊缓存使用填过的“坑”
猜您喜欢 加密货币的本质 java使用默认线程池踩过的坑(一) 回收也是一种生活方式 电商邮件服务平台性能优化谈 #通知#天了噜,PHP7正式版跳票,将延期发布