网关选择困难症

近期因为新项目需要,我们的后端选用的技术栈是spring cloud微服务,需要对网关进行选型,所以有了一下这篇网关的性能测试分析,对你有帮助的,关注一下公众号:二当家的黑板报

测试机器

image-20181121104328341

使用的是4核4G内存的虚拟机,系统是Ubuntu18

wrk测试

以下为10个线程,200并发,持续30秒,对不同网关的测试结果。(wrk使用的是http1.1版本)

直连

image-20181120151113284

Nginx

image-20181120151226801

zuul(热身后),时不时有timeout的情况

image-20181120151329457

gateway(热身后)

image-20181120151631488

linkerd(热身后)

image-20181120151901127

测试结果说明

  1. 当没有网关,直接连接服务时,每秒可处理22433个请求,每个线程平均延时13.25ms
  2. 使用Nginx代理时,每秒可处理12507个请求,约为直连时的56%,平均延时75.43ms
  3. 使用热身后的zuul,每秒可处理6517个请求,约为直连时的29%,平均延时105.06ms;多次测试,偶尔会有几次存在3、4个timeout的请求。
  4. 使用热身后的gateway,每秒可处理9228个请求,约为直连时的41%,平均延时为21.83ms
  5. 使用热身后的linkerd,每秒可处理9999个请求,约为直连时的44%,平均延时为20.35ms

ab测试,针对http1.0

以下使用ab做200并发,50000个请求测试:

直连

image-20181121101205314

Nginx

image-20181121101346153

zuul(热身后)

image-20181121101538843

gateway(热身后)

image-20181121101844302

linkerd(热身后)

image-20181121102151407

测试结果说明

针对网上有个帖子用ab测试,测试到gateway性能很差,官方已排查是ab用的是http1.0,而gateway的底层reactor-netty不支持http1.0,这个问题已修复。

https://cloud.tencent.com/developer/article/1083254

https://github.com/reactor/reactor-netty/issues/21

  1. 直连,50000个请求,总耗时2.748秒,每秒处理18195个请求,平均11ms一个请求
  2. Nginx,总耗时5.021秒,每秒处理9958个请求,约为直连的55%,平均20ms一个请求
  3. 热身后的zuul,总耗时7.862秒,每秒处理6360个请求,约为直连的35%,平均31ms一个请求
  4. 热身后的gateway,总耗时6.762秒,每秒处理7394个请求,约为直连的41%,平均27ms一个请求
  5. 热身后的linkerd,总耗时6.972秒,每秒处理7171个请求,约为直连的39%,平均28ms一个请求

简单总结

  1. 根据测试情况,多种网关中Nginx的性能无疑是最好的,无论是淘宝的Tengine的功能增强,还是OpenResty的模块增强,都是对Nginx优化。不过从定位来说,我比较倾向于把它定位为传统的只是承载请求转发的工具,对于我们开发的技术栈没那么友好。另外,OpenResty有一个lua-resty-mysql模块,可做mysql的网关,我们没用过,不知道性能如何。
  2. zuul和gateway,都是可以无缝对接spring cloud,结合服务发现,对服务层来说可以做到屏蔽机器资源(ip或内外网域名等),服务对机器无依赖性。它们的定位是融合在微服务的网关,承载着对微服务增强的功能。对于二次开发的易用性来说,两者对我们开发上手都比较容易。
  3. zuul和gateway对比,根据测试情况,gateway的性能还是比zuul好很多的。另外,gateway的也有很多zuul没有的功能,比如支持http2、websocket,根据域名转发等。对于做服务转发,而不是数据库转发这种高性能要求,性能上和Nginx差距不大。
  4. linkerd则是服务网格的概念了,linkerd的原理是系统代理请求,对服务是无侵入性的,有比较成熟的监控管理界面。gateway的官方测试是,gateway性能比linkerd好很多,但是在我的虚拟机上测试,两者差不多。linkerd结合docker和k8s使用,对机器资源的抽象就更上一层。linkerd更像是应用程序或者说微服务间的 TCP/IP,网络监控、限流、熔断对服务层来说是透明无感的。

以上,个人感觉是不同维度的东西,可以根据自己的功能需求、开发技术栈等,来选取对应的网关。

  • 本文作者:二当家的
  • 本文链接: 2018/12/16/网关选择困难症/
  • 版权声明: 本博客所有文章除特别声明外,均采用 CC BY-NC-SA 3.0 CN 许可协议。转载请注明出处!
  • 彩蛋: 左边Overview微信公众号二维码,扫描它获取更多技术信息