您好,登錄后才能下訂單哦!
本篇文章為大家展示了Zuul & Spring Cloud 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來代理該服務的端點,并對比。
最終結果:
組件 | RPS(request per second) |
---|---|
Spring Cloud Gateway | Requests/sec: 32213.38 |
Zuul | Requests/sec: 20800.13 |
Linkerd | Requests/sec: 28050.76 |
從結果可知,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暫時還沒有整合計劃。
上述內容就是Zuul & Spring Cloud Gateway & Linkerd性能對比是怎樣的,你們學到知識或技能了嗎?如果還想學到更多技能或者豐富自己的知識儲備,歡迎關注億速云行業資訊頻道。
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。