用於實現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。前提是你知道你會失去多少性能。