糾錯帖：Zuul & Spring Cloud Gateway & Linkerd性能對比

原文： http://www.itmuch.com/spring-cloud-sum/performance-zuul-and-gateway-linkerd/ ，轉載請說明出處。

動機

已經不止一次看到“Spring Cloud Gateway性能比Zuul更差”的言論了，不少人人雲亦雲，來問我，既然如此，那Spring官方還開發Spring Cloud Gateway幹嘛？難道僅僅是為了支援Zuul 1.x不支援的長連接配接、Web Socket嗎？

故而寫篇部落格，糾正一下大家的錯誤觀點。

開端

網上搜尋了一下，說Spring Cloud Gateway性能比Zuul差的言論來自：

http://www.servicemesh.cn/?/article/45

作者使用

ab

進行benchmark，操作非常标準。從結果來看，确實Spring Cloud Gateway比Zuul差了一大截。

但，讓我們打開官方的Issue：

Throughput problems when compared with Netflix Zuul and Nginx

，裡面官方人員回答道：

reactor-netty has issues with http 1.0 and hence ab. reactor/reactor-netty#21

不妨跟蹤到

，看看說了啥：

As discussed recently about the issue raised on https://jira.spring.io/browse/SPR-14964 , a very simple

ab -n 1 -c 1 http://localhost:8082/items/10

on Spring + Reactor Netty based server block forever likely because Reactor Netty does not support HTTP 1.0.

裡面說了，Reactor Netty不支援HTTP 1.0，而Spring Cloud Gateway依賴了

reactor-netty

。

也就是說——由于reactor-netty的bug，使用

ab

壓測結果并不準确！

正确姿勢

官方建議使用

wrk

進行benchmark測試。不僅如此，官方人員還十（喪）分（心）貼（病）心（狂）地建立了一個benchmark的項目：

spring-cloud-gateway-bench

，其中對比了：

• Spring Cloud Gateway
• Zuul
• Linkerd

三者的性能。

思路非常簡單：

static

項目是一個使用Go語言編寫的簡單伺服器；然後分别使用Gateway/Zuul/Linkerd來代理該服務的端點，并對比。

最終結果：

元件	RPS(request per second)
	Requests/sec: 32213.38
	Requests/sec: 20800.13
	Requests/sec: 28050.76

從結果可知，Spring Cloud Gateway的RPS是Zuul的1.6倍！比Linkerd性能還好！

展望

• 本文的Zuul，指的是Zuul 1.x，是一個基于阻塞io的API Gateway。
• Spring Cloud Gateway是一個很有前途的項目，上手簡單，功能也比較強大。
• Linkerd也是一個非常有前途的項目，是基于Scala實作的、目前市面上僅有的生産級别的Service Mesh（其他諸如Istio、Conduit暫時還不能用于生産）。
• Zuul已經釋出了Zuul 2.x，基于Netty，也是非阻塞的，支援長連接配接，但Spring Cloud暫時還沒有整合計劃。