資訊專欄INFORMATION COLUMN
摘要：被測的網關都沒有添加額外業務，只做反向代理吞吐量下圖是吞吐量的情況，可以看到均比直壓低一點點，而和則要低得多。結論三者的表現均很不錯，其對于吞吐量和響應時間的性能損耗很低，可以忽略不計。
用于實現API網關的技術有很多，大致分為這么幾類：
通用反向代理：Nginx、Haproxy、……
網絡編程框架：Netty、Servlet、……
API網關框架：Spring Cloud Gateway、Zuul、Zuul2、……
API網關最基本的功能就是反向代理，所以在對API網關做技術選型的時候需要著重考察其性能表現，本文對Nginx、Haproxy、Netty、Spring Cloud Gateway、Zuul2做了性能測試，測試代碼可以在github獲得。
測試方法準備了三臺2CPU 4G內存的服務器，分別運行Tomcat、API Gateway、Gatling（壓測工具）
先對Tomcat做壓測，取Tomcat充分預熱后的壓測結果作為基準。壓的是Tomcat自帶的example：/examples/jsp/jsp2/simpletag/book.jsp
在對Netty、Zuul2、Spring Cloud Gateway做壓測時候也是先壓個幾輪做預熱。
被測的API網關都沒有添加額外業務，只做反向代理
吞吐量下圖是吞吐量的情況，可以看到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倍多，不出所料。
下圖同樣是以Tomcat作為基準值的比較：
響應時間分布光看平均響應時間是不夠的，我們還得看P50、P90、P99、P99.9以及Max響應時間（可惜Gatling只能設置4個百分位，否則我還想看看P99.99的響應時間）。
為何要觀察P99.9的響應時間？光看P90不夠嗎？理由有兩個：1）觀察P99、P99.9、P99.99的響應時間可以觀察系統的在高壓情況下的穩定性，如果這三個時間的增長比較平滑那么說明該系統在高壓力情況下比較穩定，如果這個曲線非常陡峭則說明不穩定。
2）觀察P99、P99.9、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%的概率。
關于如何正確測量系統可以看 “How NOT to Measure Latency” by Gil Tene
下面同樣是把結果與Tomcat基準值做對比：
可以看到幾個很有趣的現象：
Haproxy、Nginx的P50、P90、P99、P99.9、Max都是逐漸遞增的。
Netty的P50、P90、P99、P99.9是很平坦的，Max則為基準值的207%。
Spring Cloud Gateway和Zuul2則是相反的，它們的平面呈現下降趨勢。Spring Cloud Gateway的Max甚至還比基準值低了一點點（94%），我相信這只是一個隨機出現的數字，不要太在意。
結論Nginx、Haproxy、Netty三者的表現均很不錯，其對于吞吐量和響應時間的性能損耗很低，可以忽略不計。
但是目前最為火熱的Spring Cloud Gateway和Zuul2則表現得比較糟糕，因我沒有寫額外的業務邏輯這，可以推測這和它們的內置邏輯有關，那么大致有這么幾種可能：
內置邏輯比較多
內置邏輯算法存在問題，占用了太多CPU時間
內置邏輯存在阻塞
內置邏輯沒有用正確姿勢使用Netty（兩者皆基于Netty）
不管是上面的哪一種都需要再后續分析。
不過話說回來考慮選用那種作為API網關（的基礎技術）不光要看性能，還要看：
是否易于擴展自己的業務邏輯
API使用的便利性
代碼的可維護性
文檔是否齊全
...
性能只是我們手里的一個籌碼，當我們知道這個東西性能到底幾何后，才可以與上面的這些做交換（trade-off）。比如Nginx和Haproxy的可擴展性很差，那么我們可以使用Netty。如果你覺得Netty的API太底層了太難用了，那么可以考慮Spring Cloud Gateway或Zuul2。前提是你知道你會失去多少性能。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/40586.html
摘要：被測的網關都沒有添加額外業務，只做反向代理吞吐量下圖是吞吐量的情況，可以看到均比直壓低一點點，而和則要低得多。結論三者的表現均很不錯，其對于吞吐量和響應時間的性能損耗很低，可以忽略不計。 用于實現API網關的技術有很多，大致分為這么幾類： 通用反向代理：Nginx、Haproxy、…… 網絡編程框架：Netty、Servlet、…… API網關框架：Spring Cloud Gate...
摘要：主流消息中間件介紹是由出品，是一個完全支持和規范的實現。主流消息中間件介紹是阿里開源的消息中間件，目前也已經孵化為頂級項目。 showImg(https://img-blog.csdnimg.cn/20190509221741422.gif);showImg(https://img-blog.csdnimg.cn/20190718204938932.png?x-oss-process=...
摘要：作者簡介戴嘉樂前百度高級研發工程師應用實踐者布道師個人網站聯系方式微信號。二技術介紹對這項技術不熟悉的同學，可以參考我之前一次演講分享的內容戴嘉樂詳解的本質技術架構以及應用。 作者簡介：戴嘉樂( Mr.Maple ) | 前百度高級研發工程師 | IPFS應用實踐者&布道師|個人網站：https://www.daijiale.cn聯系方式：微信號：daijiale6239。 一、應用背...
摘要：五參考文獻區塊鏈利用構建自己的去中心化分布式系統相關文章和視頻推薦戴嘉樂入門基于和構建自維護資源網關圓方圓學院匯集大批區塊鏈名師，打造精品的區塊鏈技術課程。 作者簡介：戴嘉樂( Mr.Maple ) | 前百度高級研發工程師 | IPFS應用實踐者&布道師|個人網站：https://www.daijiale.cn聯系方式：微信號：daijiale6239。 一、背景 上篇文章[《（入門...
閱讀 1401·2021-10-14 09:43
閱讀 991·2021-09-10 10:51
閱讀 1441·2021-09-01 10:42
閱讀 2188·2019-08-30 15:55
閱讀 584·2019-08-30 15:55
閱讀 2338·2019-08-30 14:21
閱讀 1714·2019-08-30 13:04
閱讀 3466·2019-08-29 13:09
