API Gateway示意圖
API Gateway主要是為了解決微服務(wù)下調(diào)用增淹、統(tǒng)一接入等問題。
用于實(shí)現(xiàn)API網(wǎng)關(guān)的技術(shù)有很多翔冀，大致分為這么幾類：
通用反向代理：Nginx铐然、Haproxy、……
網(wǎng)絡(luò)編程框架：Netty涮瞻、Servlet、……
API網(wǎng)關(guān)框架：Spring Cloud Gateway假褪、Zuul署咽、Zuul2、……
API網(wǎng)關(guān)最基本的功能就是反向代理生音，所以在對API網(wǎng)關(guān)做技術(shù)選型的時(shí)候需要著重考察其性能表現(xiàn)宁否，本文對Nginx、Haproxy缀遍、Netty慕匠、Spring Cloud Gateway、Zuul2做了性能測試域醇，測試代碼可以在github獲得台谊。
測試方法
準(zhǔn)備了三臺2CPU 4G內(nèi)存的服務(wù)器冤寿，分別運(yùn)行Tomcat、API Gateway青伤、Gatling（壓測工具）
先對Tomcat做壓測，取Tomcat充分預(yù)熱后的壓測結(jié)果作為基準(zhǔn)殴瘦。壓的是Tomcat自帶的example：
/examples/jsp/jsp2/simpletag/book.jsp在對Netty狠角、Zuul2、Spring Cloud Gateway做壓測時(shí)候也是先壓個(gè)幾輪做預(yù)熱蚪腋。
被測的API網(wǎng)關(guān)都沒有添加額外業(yè)務(wù)丰歌，只做反向代理
吞吐量
下圖是吞吐量的情況，可以看到Netty屉凯、Nginx立帖、Haproxy均比直壓Tomcat低一點(diǎn)點(diǎn)，而Spring Cloud Gateway和Zuul2則要低得多悠砚。
下面這張圖可以更明顯的看到吞吐量比較晓勇，Tomcat為100%因?yàn)樗腔鶞?zhǔn)值，Netty灌旧、Nginx绑咱、Haproxy的只比基準(zhǔn)值低8%，而Spring Cloud Gateway和Zuul2則只是基準(zhǔn)值的35%和34%（難兄難弟）枢泰。
平均響應(yīng)時(shí)間
下圖可以看到Netty描融、Nginx、Haproxy的平均響應(yīng)時(shí)間與Tomcat差不多衡蚂。但是Spring Cloud Gateway和Zuul2則是Tomcat的3倍多窿克，不出所料。
下圖同樣是以Tomcat作為基準(zhǔn)值的比較：
響應(yīng)時(shí)間分布
光看平均響應(yīng)時(shí)間是不夠的毛甲，我們還得看P50年叮、P90、P99丽啡、P99.9以及Max響應(yīng)時(shí)間（可惜Gatling只能設(shè)置4個(gè)百分位谋右，否則我還想看看P99.99的響應(yīng)時(shí)間）。
為何要觀察P99.9的響應(yīng)時(shí)間补箍？光看P90不夠嗎改执？理由有兩個(gè)：
1）觀察P99、P99.9坑雅、P99.99的響應(yīng)時(shí)間可以觀察系統(tǒng)的在高壓情況下的穩(wěn)定性辈挂，如果這三個(gè)時(shí)間的增長比較平滑那么說明該系統(tǒng)在高壓力情況下比較穩(wěn)定，如果這個(gè)曲線非常陡峭則說明不穩(wěn)定裹粤。
2）觀察P99终蒂、P99.9、P99.99的響應(yīng)時(shí)間能夠幫助你估算用戶體驗(yàn)。假設(shè)你有一個(gè)頁面會發(fā)出5次請求拇泣，那么這5次請求均落在P90以內(nèi)概率是多少噪叙？90%^5=59%，至少會經(jīng)歷一次 > P90響應(yīng)時(shí)間的概率是 100%-59%=41%霉翔，如果你的P90=10s睁蕾，那么就意味著用戶有41%的概率會在加載頁面的時(shí)候超過10s，是不是很驚人债朵？如果你的P99=10s子眶，那么用戶只有5%的概率會在訪問頁面的時(shí)候超過10s。如果P99.9=10s序芦，則有0.4%的概率臭杰。
關(guān)于如何正確測量系統(tǒng)可以看 “How NOT to Measure Latency” by Gil Tene
下面同樣是把結(jié)果與Tomcat基準(zhǔn)值做對比：
可以看到幾個(gè)很有趣的現(xiàn)象：
Haproxy、Nginx的P50谚中、P90渴杆、P99、P99.9藏杖、Max都是逐漸遞增的将塑。
Netty的P50、P90蝌麸、P99点寥、P99.9是很平坦的，Max則為基準(zhǔn)值的207%来吩。
Spring Cloud Gateway和Zuul2則是相反的敢辩，它們的平面呈現(xiàn)下降趨勢。Spring Cloud Gateway的Max甚至還比基準(zhǔn)值低了一點(diǎn)點(diǎn)（94%）弟疆，我相信這只是一個(gè)隨機(jī)出現(xiàn)的數(shù)字戚长，不要太在意。
結(jié)論
Nginx怠苔、Haproxy同廉、Netty三者的表現(xiàn)均很不錯(cuò)，其對于吞吐量和響應(yīng)時(shí)間的性能損耗很低柑司，可以忽略不計(jì)迫肖。
但是目前最為火熱的Spring Cloud Gateway和Zuul2則表現(xiàn)得比較糟糕，因我沒有寫額外的業(yè)務(wù)邏輯這攒驰，可以推測這和它們的內(nèi)置邏輯有關(guān)蟆湖，那么大致有這么幾種可能：
內(nèi)置邏輯比較多
內(nèi)置邏輯算法存在問題，占用了太多CPU時(shí)間
內(nèi)置邏輯存在阻塞
內(nèi)置邏輯沒有用正確姿勢使用Netty（兩者皆基于Netty）
不管是上面的哪一種都需要再后續(xù)分析玻粪。
不過話說回來考慮選用那種作為API網(wǎng)關(guān)（的基礎(chǔ)技術(shù)）不光要看性能隅津，還要看：
是否易于擴(kuò)展自己的業(yè)務(wù)邏輯
API使用的便利性
代碼的可維護(hù)性
文檔是否齊全
...
性能只是我們手里的一個(gè)籌碼诬垂，當(dāng)我們知道這個(gè)東西性能到底幾何后，才可以與上面的這些做交換（trade-off）伦仍。比如Nginx和Haproxy的可擴(kuò)展性很差结窘，那么我們可以使用Netty。如果你覺得Netty的API太底層了太難用了充蓝，那么可以考慮Spring Cloud Gateway或Zuul2晦鞋。前提是你知道你會失去多少性能。
- 更多測試技術(shù)分享棺克、學(xué)習(xí)資源以及一些其他福利可關(guān)注公眾號：【Coding測試】獲取：
