知識星球導語：API Gateway是實現微服務重要的元件之一。面對諸多的開源API Gateway，如何進行選擇也是架構師需要關註的焦點。本文作者對幾個較大的開源API Gateway進行了壓力測試，對於架構師來說，相信可以提供不少幫助。
過去一段時間，OpsGenie的員工數量和產品特性都經歷了快速發展。去年，僅僅是我們的工程師團隊就由15人增長到了50人。針對開發團隊的劃分，我們遵循兩個披薩原則[1]將每個團隊控制在8個工程師。
如你所料的，我們的產品還是一個單體應用。對並行開發的團隊來說，CI/CD等過程，開發和運維都是有挑戰的。我們跟隨當前的技術趨勢，正處於單體應用到微服務架構的過渡期。你可以閱讀Martin Fowler的這篇文章[2]，瞭解更多微服務架構和它的好處。
這裡有一些關於微服務概念推薦的架構樣式[3]。其中的一個樣式是API閘道器[4]。API閘道器是所有客戶端的統一入口。API閘道器對於任意一種處理請求有兩種方式處理。一部分請求只要簡單路由到相應的服務；還有一些請求需要拆分到多個服務。
API閘道器樣式是開始微服務架構很好的切入點，因為它能路由具體的請求到拆分出來的不同服務。事實上，API閘道器對我們來說不是一個新概念。到目前為止，我們已經使用過Nginx放在我們的單體應用前面充當API閘道器，但是我們想重新評估過渡時期繼續使用Nginx的合理性。我們關心效能、可擴充套件性和其他的擴充套件能力，例如限流。首先，評估大流量下的效能，確保它們能滿足我們的需求。
在這篇文章中，我們講解如何設定我們的測試環境，並且對比這些閘道器的效能： Zuul 1[5], Nginx[6], Spring Cloud Gateway[7], Linkerd[8]。事實上，我們還有另外兩個選擇Envoy[9]和 UnderTow[10]。我們將會對這些工具做相同的測試，並且在後面的部落格中公佈測試結果。
Zuul 1由於使用Java開發，並且對Spring框架有很強的支援，對我們來說似乎很合適。儘管有很多文章對比過Zuul和Nginx，但是我們還想跟Spring Cloud Gateway和Linkerd一起評估。此外，我們計劃做高負載的測試，所以我們決定設定我們自己的測試環境。
為了評估API閘道器各自的效能，我們為OpsGenie產品建立了一個隔離的獨立測試環境。我們使用Apache的ab作為壓測工具。
首先，我們參照Nginx檔案在一個單核1G記憶體的AWS EC2實體上安裝了一個Nginx。這個環境是我們的初始測試環境，然後我們安裝Zuul和Spring Cloud Gateway到這個環境中。Nginx為靜態資源提供web服務，我們透過Nginx、Zuul和Spring Cloud Gateway定義反向代理到這個web服務。我們同樣啟動了另外一個單核1G記憶體的EC2實體發起壓測請求。
圖片中的箭頭是我們的測試路徑。這裡有4中情況：
-
直接訪問
-
Nginx反向代理訪問
-
Zuul訪問
-
Spring Cloud Gateway訪問
-
Linkerd訪問
我們知道大家急於想看測試結果，所以，我們先給測試結果，然後再做詳細說明。
效能壓測總結
測試策略
我們使用Apache的ab做壓測工具。我們發起總共10000個請求、使用200個併發執行緒分別進行壓測。
我們將在3種不同配置的AWS EC2伺服器上進行測試。我們會縮小每一步的測試用例的範圍：
-
儘管我們不選擇直接訪問，但是我們在第一步額外做了直接訪問的測試，用於衡量代理的理想值，這個測試我們不會在後面的步驟中進行。
-
儘管Spring Cloud Gateway依然沒有官方穩定版，我們會在最後那步評估它。
-
Zuul隨後的效能比第一次壓測的效能更好。我們估計出現這種情況的原因是第一次壓測進行了JIT最佳化，所以我們把針對Zuul的第一次壓測當成“預熱”。在總結表中的值是預熱之後的效能。
-
我們知道Linkerd是資源密集型代理，所以我們只在高資源配置的最後一步對比。
測試配置
T2.Micro——單核1G記憶體：我們對比測試直接訪問、Nginx反向代理和Zuul（預熱之後）。
M4.Micro ——雙核8G記憶體：我們對比測試Nginx反向代理和Zuul（預熱之後）。
M4.2xLarge——8核32G記憶體：我們對比測試Nginx反向代理、Zuul（預熱之後）、Spring Cloud Gateway和Linkerd。
測試結果
效能壓測結果如下
測試詳情
直接訪問
首先，我們不使用代理，直接訪問靜態資源。結果如下，單個請求平均30ms。
Nginx反向代理
我們的第2個測試，透過Nginx反向代理訪問資源。單次請求平均耗時40ms。可以說，Nginx代理對比直接訪問，平均增加了33%的耗時。
Zuul反向代理
接下來，我們建立了一個Spring Boot應用：
這是我們的application.yml檔案：
Zuul第1次測試結果如下：
直接訪問Nginx單次請求是30ms，透過Nginx反向代理訪問是40ms。Zuul首次訪問單次請求在388ms。如在另外一篇部落格[12]中提到的，JVM預熱會有作用。我們重新壓測，結果如下：
預熱後Zuul代理的效能更好（單次請求是200ms），但是跟Nginx反向代理的40ms對比，仍然不好。
伺服器升級到雙核8G記憶體會怎麼樣呢？
前面的測試伺服器配置是單核1G記憶體。Nginx是C++應用，Zuul是基於Java的。我們知道，Java應用對環境要求更苛刻。所以我們將伺服器配置換成雙核8G記憶體實體。
我們重新對Nginx和Zuul做壓測，結果如下
由上面圖片可見，Nginx反向代理和Zuul代理單次請求花費時間分別是32ms和95ms。這次壓測結果比單核1G記憶體的40ms和200ms更好。
由此可見，使用Spring Boot部署的Zuul有額外的消耗。很可能Zuul的獨立應用會有更好的效能。
伺服器升級到8核32G記憶體會怎麼樣呢？
我們繼續評估8核32G記憶體的伺服器配置。Nginx和Zuul的壓測結果如下
在8核32G的配置上，Zuul跑贏了Nginx。我們想找到Netflix的Zuul實體部署在哪種型別的ec2伺服器上，但是我們沒有找到任何資訊。一些部落格中，有人說了Zuul的效能，並且詢問Netflix如何處理的。我們認為這可能是答案，Zuul使用CPU系結。
Linkerd壓測
Linkerd是CNCF的專案，是Scala開發的service mesh應用。他提供反向代理能力用於擴充套件service mesh能力，例如服務發現。我們評估Linkerd效能並且給出如下結果。Linkerd跟Zuul的效能很接近。
Spring Cloud Gateway效能測試
Spring Cloud組織也開發了一個Gateway模組。儘管官方還沒有正式版本，我們覺得還是有必要跟其他選擇進行對比。但是，我們按照我們的測試環境修改了Gateway的例子。
我們用Apache的ab使用了20個執行緒、發了總共10000個請求做了同樣的壓測。測試結果在下麵這張圖中：
由上圖可見，Spring Cloud Gateway每秒能處理873個請求，單次請求平均耗時229ms。根據我們的測試結果，Spring Cloud Gateway不能達到Zuul、Linkerd、Nginx的效能水平，這是他們目前最新版本測試的結果。Nginx、Zuul、Linkerd和Spring Cloud Gateway的最後一次測試結果上面已經給出。
接下來呢？
這篇文章中，我們使用Apache的工具ab對比了Zuul、Nginx、Linkerd和Spring Cloud Gateway的效能。下一步我們的計劃如下：
-
我們計劃去評估Envoy。事實上，Envoy不止是API閘道器，它是service mesh，但是也提供了API閘道器功能，能放在應用的前面。
-
Undertow也有反向代理能力，所以我們也計劃去評估一下。
-
Netflix基於Netty的非阻塞重新設計了Zuul應用，新的版本叫“Zuul 2”。如果官方釋出了新版本的Zuul，我們也會進行效能壓測，然後將壓測結果分享出來。
-
Spring Cloud Gateway依然在開發中，基於Netty的非阻塞的Java閘道器，所以對我們來說是一個很好的候選。我們將會評估它的官方穩定版的效能。
-
一些API閘道器（Zuul 1）是阻塞的，另外一些（Zuul 2、Linkerd、Envoy）是非阻塞的。阻塞架構對開發和跟蹤請求友好，但是阻塞可能產生擴充套件性問題。非阻塞架構對於團隊開發和跟蹤更複雜，但是有更好的可擴充套件和彈性。我們之後將會決定使用阻塞架構還是使用非阻塞架構。
-
我們將使用Gatling做效能測試，將在我們的下一篇部落格中共享結果。
我們將會在部落格中共享每一步的成功結果，敬請期待！
文中連結
[1] http://www.businessinsider.com/jeff-bezos-two-pizza-rule-for-productive-meetings-2013-10
[2] https://martinfowler.com/articles/microservices.html
[3] http://microservices.io/patterns/microservices.html
[4] http://microservices.io/patterns/apigateway.html
[5] https://github.com/Netflix/zuul
[6] http://www.nginx.com/
[7] https://github.com/spring-cloud/spring-cloud-gateway
[8] https://linkerd.io/
[9] http://envoyproxy.io/
[10] http://undertow.io/
[11] https://httpd.apache.org/docs/2.4/programs/ab.html
[12] http://instea.sk/2015/04/netflix-zuul-vs-nginx-performance/
[13] https://gatling.io/
本文作者Turgay Çelik，由鄧啟明翻譯，轉載本文請註明出處，技術原創及架構實踐文章，歡迎透過公眾號選單「聯絡我們」進行投稿。
相關閱讀：
高可用架構
改變網際網路的構建方式
長按二維碼 關註「高可用架構」公眾號
