Spring Cloud從一開始最受大家質疑的就是閘道器效能，那是由於Spring Cloud最初選擇了使用Netflix幾年前開源的Zuul作為基礎，而高效能版的Zuul 2在經過了多次跳票之後，對於Spring這樣的整合專家可能也不願意再繼續等待，Spring Cloud Gateway應運而生，那麼這個由Spring社群自己開發推出的閘道器又如何呢？最近一篇《實測 | 轉型微服務，這4大工具誰是API閘道器效能最優？》的翻譯中對比了NGINX、ZUUL、Spring Cloud Gateway、Linkerd，得出的結論讓不少讀者感到詫異，Spring Cloud Gateway是否真的有這麼差？不妨通過下文來進一步瞭解（以下內容轉載自來《Spring Cloud與Docker微服務實戰》作者周立的博文，原文地址：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

不妨跟蹤到reactor/reactor-netty#21 ，看看說了啥：

As discussed recently about the issue raised on https://jira.spring.io/browse/SPR-14964, a very simple ab-n1-c1http://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來代理該服務的端點，並對比。

最終結果：

從結果可知，Spring Cloud Gateway的RPS是Zuul1的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暫時還沒有整合計劃。

推薦閱讀

長按指紋

一鍵關注

點選 “閱讀原文” 看看本號其他精彩內容