用于实现API网关的技术有不少,大体分为这么几类:git
API网关最基本的功能就是反向代理,因此在对API网关作技术选型的时候须要着重考察其性能表现,本文对Nginx、Haproxy、Netty、Spring Cloud Gateway、Zuul2作了性能测试,测试代码能够在github得到。github
/examples/jsp/jsp2/simpletag/book.jsp
下图是吞吐量的状况,能够看到Netty、Nginx、Haproxy均比直压Tomcat低一点点,而Spring Cloud Gateway和Zuul2则要低得多。算法
下面这张图能够更明显的看到吞吐量比较,Tomcat为100%由于它是基准值,Netty、Nginx、Haproxy的只比基准值低8%,而Spring Cloud Gateway和Zuul2则只是基准值的35%和34%(难兄难弟)。编程
下图能够看到Netty、Nginx、Haproxy的平均响应时间与Tomcat差很少。可是Spring Cloud Gateway和Zuul2则是Tomcat的3倍多,不出所料。api
下图一样是以Tomcat做为基准值的比较:服务器
光看平均响应时间是不够的,咱们还得看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工具
下面一样是把结果与Tomcat基准值作对比:
能够看到几个颇有趣的现象:
Nginx、Haproxy、Netty三者的表现均很不错,其对于吞吐量和响应时间的性能损耗很低,能够忽略不计。
可是目前最为火热的Spring Cloud Gateway和Zuul2则表现得比较糟糕,因我没有写额外的业务逻辑这,能够推测这和它们的内置逻辑有关,那么大体有这么几种可能:
不论是上面的哪种都须要再后续分析。
不过话说回来考虑选用那种做为API网关(的基础技术)不光要看性能,还要看:
性能只是咱们手里的一个筹码,当咱们知道这个东西性能到底几何后,才能够与上面的这些作交换(trade-off)。好比Nginx和Haproxy的可扩展性不好,那么咱们可使用Netty。若是你以为Netty的API太底层了太难用了,那么能够考虑Spring Cloud Gateway或Zuul2。前提是你知道你会失去多少性能。