糾錯帖：Zuul & Spring Cloud Gateway & Linkerd性能對比 （轉載）
糾錯帖：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 -n 1 -c 1 http://localhost:8082/items/10on 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是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暫時還沒有整合計劃。
相關文章
- Zuul的高可用
- Spring Cloud Edgware新特性之五：filters端點
- 跟我學Spring Cloud（Finchley版）-18-Zuul深入
- 跟我學Spring Cloud（Finchley版）-16-Zuul
- 跟我學Spring Cloud（Finchley版）-17-Zuul路由配置詳解
糾錯帖：Zuul & Spring Cloud Gateway & Linkerd性能對比 （轉載）