歡迎光臨
每天分享高質量文章

微服務網關哪家強?一文看懂Zuul, Nginx, Spring Cloud, Linkerd性能差異

導語: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,由鄧啟明翻譯,轉載本文請註明出處,技術原創及架構實踐文章,歡迎通過公眾號選單「聯繫我們」進行投稿。


相關閱讀:



高可用架構

改變互聯網的構建方式

長按二維碼 關註「高可用架構」公眾號

赞(0)

分享創造快樂