各大API网关性能比较

用于实现API网关的技术有不少,大体分为这么几类:git

  • 通用反向代理:Nginx、Haproxy、……
  • 网络编程框架:Netty、Servlet、……
  • API网关框架:Spring Cloud Gateway、Zuul、Zuul二、……

API网关最基本的功能就是反向代理,因此在对API网关作技术选型的时候须要着重考察其性能表现,本文对Nginx、Haproxy、Netty、Spring Cloud Gateway、Zuul2作了性能测试,测试代码能够在github得到。github

测试方法

  • 准备了三台2CPU 4G内存的服务器,分别运行Tomcat、API Gateway、Gatling(压测工具)
  • 先对Tomcat作压测,取Tomcat充分预热后的压测结果做为基准。压的是Tomcat自带的example:/examples/jsp/jsp2/simpletag/book.jsp
  • 在对Netty、Zuul二、Spring Cloud Gateway作压测时候也是先压个几轮作预热。
  • 被测的API网关都没有添加额外业务,只作反向代理

吞吐量

下图是吞吐量的状况,能够看到Netty、Nginx、Haproxy均比直压Tomcat低一点点,而Spring Cloud Gateway和Zuul2则要低得多。算法

clipboard.png

下面这张图能够更明显的看到吞吐量比较,Tomcat为100%由于它是基准值,Netty、Nginx、Haproxy的只比基准值低8%,而Spring Cloud Gateway和Zuul2则只是基准值的35%和34%(难兄难弟)。编程

clipboard.png

平均响应时间

下图能够看到Netty、Nginx、Haproxy的平均响应时间与Tomcat差很少。可是Spring Cloud Gateway和Zuul2则是Tomcat的3倍多,不出所料。api

clipboard.png

下图一样是以Tomcat做为基准值的比较:服务器

clipboard.png

响应时间分布

光看平均响应时间是不够的,咱们还得看P50、P90、P9九、P99.9以及Max响应时间(惋惜Gatling只能设置4个百分位,不然我还想看看P99.99的响应时间)。网络

为什么要观察P99.9的响应时间?光看P90不够吗?理由有两个:

1)观察P9九、P99.九、P99.99的响应时间能够观察系统的在高压状况下的稳定性,若是这三个时间的增加比较平滑那么说明该系统在高压力状况下比较稳定,若是这个曲线很是陡峭则说明不稳定。框架

2)观察P9九、P99.九、P99.99的响应时间可以帮助你估算用户体验。假设你有一个页面会发出5次请求,那么这5次请求均落在P90之内几率是多少?90%^5=59%,至少会经历一次 > P90响应时间的几率是 100%-59%=41%,若是你的P90=10s,那么就意味着用户有41%的几率会在加载页面的时候超过10s,是否是很惊人?若是你的P99=10s,那么用户只有5%的几率会在访问页面的时候超过10s。若是P99.9=10s,则有0.4%的几率。jsp

关于如何正确测量系统能够看 “How NOT to Measure Latency” by Gil Tene工具

clipboard.png

下面一样是把结果与Tomcat基准值作对比:

clipboard.png

能够看到几个颇有趣的现象:

  • Haproxy、Nginx的P50、P90、P9九、P99.九、Max都是逐渐递增的。
  • Netty的P50、P90、P9九、P99.9是很平坦的,Max则为基准值的207%。
  • Spring Cloud Gateway和Zuul2则是相反的,它们的平面呈现降低趋势。Spring Cloud Gateway的Max甚至还比基准值低了一点点(94%),我相信这只是一个随机出现的数字,不要太在乎。

结论

Nginx、Haproxy、Netty三者的表现均很不错,其对于吞吐量和响应时间的性能损耗很低,能够忽略不计。

可是目前最为火热的Spring Cloud Gateway和Zuul2则表现得比较糟糕,因我没有写额外的业务逻辑这,能够推测这和它们的内置逻辑有关,那么大体有这么几种可能:

  1. 内置逻辑比较多
  2. 内置逻辑算法存在问题,占用了太多CPU时间
  3. 内置逻辑存在阻塞
  4. 内置逻辑没有用正确姿式使用Netty(二者皆基于Netty)

不论是上面的哪种都须要再后续分析。

不过话说回来考虑选用那种做为API网关(的基础技术)不光要看性能,还要看:

  • 是否易于扩展本身的业务逻辑
  • API使用的便利性
  • 代码的可维护性
  • 文档是否齐全
  • ...

性能只是咱们手里的一个筹码,当咱们知道这个东西性能到底几何后,才能够与上面的这些作交换(trade-off)。好比Nginx和Haproxy的可扩展性不好,那么咱们可使用Netty。若是你以为Netty的API太底层了太难用了,那么能够考虑Spring Cloud Gateway或Zuul2。前提是你知道你会失去多少性能。

相关文章
相关标签/搜索