導(dǎo)語：API Gateway是實現(xiàn)微服務(wù)重要的組件之一。面對諸多的開源API Gateway，如何進行選擇也是架構(gòu)師需要關(guān)注的焦點。本文作者對幾個較大的開源API Gateway進行了壓力測試，對于架構(gòu)師來說，相信可以提供不少幫助。

過去一段時間，OpsGenie的員工數(shù)量和產(chǎn)品特性都經(jīng)歷了快速發(fā)展。去年，僅僅是我們的工程師團隊就由15人增長到了50人。針對開發(fā)團隊的劃分，我們遵循兩個披薩原則[1]將每個團隊控制在8個工程師。

如你所料的，我們的產(chǎn)品還是一個單體應(yīng)用。對并行開發(fā)的團隊來說，CI/CD等過程，開發(fā)和運維都是有挑戰(zhàn)的。我們跟隨當前的技術(shù)趨勢，正處于單體應(yīng)用到微服務(wù)架構(gòu)的過渡期。你可以閱讀Martin Fowler的這篇文章[2]，了解更多微服務(wù)架構(gòu)和它的好處。

這里有一些關(guān)于微服務(wù)概念推薦的架構(gòu)模式[3]。其中的一個模式是API網(wǎng)關(guān)[4]。API網(wǎng)關(guān)是所有客戶端的統(tǒng)一入口。API網(wǎng)關(guān)對于任意一種處理請求有兩種方式處理。一部分請求只要簡單路由到相應(yīng)的服務(wù)；還有一些請求需要拆分到多個服務(wù)。

API網(wǎng)關(guān)模式是開始微服務(wù)架構(gòu)很好的切入點，因為它能路由具體的請求到拆分出來的不同服務(wù)。事實上，API網(wǎng)關(guān)對我們來說不是一個新概念。到目前為止，我們已經(jīng)使用過Nginx放在我們的單體應(yīng)用前面充當API網(wǎng)關(guān)，但是我們想重新評估過渡時期繼續(xù)使用Nginx的合理性。我們關(guān)心性能、可擴展性和其他的擴展能力，例如限流。首先，評估大流量下的性能，確保它們能滿足我們的需求。

在這篇文章中，我們講解如何設(shè)置我們的測試環(huán)境，并且對比這些網(wǎng)關(guān)的性能：?Zuul 1[5],?Nginx[6],?Spring Cloud Gateway[7],?Linkerd[8]。事實上，我們還有另外兩個選擇Envoy[9]和?UnderTow[10]。我們將會對這些工具做相同的測試，并且在后面的博客中公布測試結(jié)果。

Zuul 1由于使用Java開發(fā)，并且對Spring框架有很強的支持，對我們來說似乎很合適。盡管有很多文章對比過Zuul和Nginx，但是我們還想跟Spring Cloud Gateway和Linkerd一起評估。此外，我們計劃做高負載的測試，所以我們決定設(shè)置我們自己的測試環(huán)境。

為了評估API網(wǎng)關(guān)各自的性能，我們?yōu)镺psGenie產(chǎn)品創(chuàng)建了一個隔離的獨立測試環(huán)境。我們使用Apache的ab作為壓測工具。

首先，我們參照Nginx文檔在一個單核1G內(nèi)存的AWS EC2實例上安裝了一個Nginx。這個環(huán)境是我們的初始測試環(huán)境，然后我們安裝Zuul和Spring Cloud Gateway到這個環(huán)境中。Nginx為靜態(tài)資源提供web服務(wù)，我們通過Nginx、Zuul和Spring Cloud Gateway定義反向代理到這個web服務(wù)。我們同樣啟動了另外一個單核1G內(nèi)存的EC2實例發(fā)起壓測請求。

圖片中的箭頭是我們的測試路徑。這里有4種情況：

• 直接訪問

• Nginx反向代理訪問

• Zuul訪問

• Spring Cloud Gateway訪問

• Linkerd訪問

我們知道大家急于想看測試結(jié)果，所以，我們先給測試結(jié)果，然后再做詳細說明。

?

性能壓測總結(jié)

---

測試策略

我們使用Apache的ab做壓測工具。我們發(fā)起總共10000個請求、使用200個并發(fā)線程分別進行壓測。

我們將在3種不同配置的AWS EC2服務(wù)器上進行測試。我們會縮小每一步的測試用例的范圍：

• 盡管我們不選擇直接訪問，但是我們在第一步額外做了直接訪問的測試，用于衡量代理的理想值，這個測試我們不會在后面的步驟中進行。

• 盡管Spring Cloud Gateway依然沒有官方穩(wěn)定版，我們會在最后那步評估它。

• Zuul隨后的性能比第一次壓測的性能更好。我們估計出現(xiàn)這種情況的原因是第一次壓測進行了JIT優(yōu)化，所以我們把針對Zuul的第一次壓測當成“預(yù)熱”。在總結(jié)表中的值是預(yù)熱之后的性能。

• 我們知道Linkerd是資源密集型代理，所以我們只在高資源配置的最后一步對比。

測試配置

T2.Micro——單核1G內(nèi)存：我們對比測試直接訪問、Nginx反向代理和Zuul（預(yù)熱之后）。

M4.Micro?——雙核8G內(nèi)存：我們對比測試Nginx反向代理和Zuul（預(yù)熱之后）。

M4.2xLarge——8核32G內(nèi)存：我們對比測試Nginx反向代理、Zuul（預(yù)熱之后）、Spring Cloud Gateway和Linkerd。

測試結(jié)果

性能壓測結(jié)果如下

測試詳情

直接訪問

首先，我們不使用代理，直接訪問靜態(tài)資源。結(jié)果如下，單個請求平均30ms。

Nginx反向代理

我們的第2個測試，通過Nginx反向代理訪問資源。單次請求平均耗時40ms。可以說，Nginx代理對比直接訪問，平均增加了33%的耗時。

Zuul反向代理

接下來，我們創(chuàng)建了一個Spring Boot應(yīng)用：

這是我們的application.yml文件：

Zuul第1次測試結(jié)果如下：

直接訪問Nginx單次請求是30ms，通過Nginx反向代理訪問是40ms。Zuul首次訪問單次請求在388ms。如在另外一篇博客[12]中提到的，JVM預(yù)熱會有作用。我們重新壓測，結(jié)果如下：

預(yù)熱后Zuul代理的性能更好（單次請求是200ms），但是跟Nginx反向代理的40ms對比，仍然不好。

服務(wù)器升級到雙核8G內(nèi)存會怎么樣呢？

前面的測試服務(wù)器配置是單核1G內(nèi)存。Nginx是C++應(yīng)用，Zuul是基于Java的。我們知道，Java應(yīng)用對環(huán)境要求更苛刻。所以我們將服務(wù)器配置換成雙核8G內(nèi)存實例。

我們重新對Nginx和Zuul做壓測，結(jié)果如下

由上面圖片可見，Nginx反向代理和Zuul代理單次請求花費時間分別是32ms和95ms。這次壓測結(jié)果比單核1G內(nèi)存的40ms和200ms更好。

由此可見，使用Spring Boot部署的Zuul有額外的消耗。很可能Zuul的獨立應(yīng)用會有更好的性能。

服務(wù)器升級到8核32G內(nèi)存會怎么樣呢？

我們繼續(xù)評估8核32G內(nèi)存的服務(wù)器配置。Nginx和Zuul的壓測結(jié)果如下

在8核32G的配置上，Zuul跑贏了Nginx。我們想找到Netflix的Zuul實例部署在哪種類型的ec2服務(wù)器上，但是我們沒有找到任何信息。一些博客中，有人說了Zuul的性能，并且詢問Netflix如何處理的。我們認為這可能是答案，Zuul使用CPU綁定。

Linkerd壓測

Linkerd是CNCF的項目，是Scala開發(fā)的service mesh應(yīng)用。他提供反向代理能力用于擴展service mesh能力，例如服務(wù)發(fā)現(xiàn)。我們評估Linkerd性能并且給出如下結(jié)果。Linkerd跟Zuul的性能很接近。

Spring Cloud Gateway性能測試

Spring Cloud組織也開發(fā)了一個Gateway模塊。盡管官方還沒有正式版本，我們覺得還是有必要跟其他選擇進行對比。但是，我們按照我們的測試環(huán)境修改了Gateway的例子。

我們用Apache的ab使用了20個線程、發(fā)了總共10000個請求做了同樣的壓測。測試結(jié)果在下面這張圖中：

由上圖可見，Spring Cloud Gateway每秒能處理873個請求，單次請求平均耗時229ms。根據(jù)我們的測試結(jié)果，Spring Cloud Gateway不能達到Zuul、Linkerd、Nginx的性能水平，這是他們目前最新版本測試的結(jié)果。Nginx、Zuul、Linkerd和Spring Cloud Gateway的最后一次測試結(jié)果上面已經(jīng)給出。

接下來呢？

這篇文章中，我們使用Apache的工具ab對比了Zuul、Nginx、Linkerd和Spring Cloud Gateway的性能。下一步我們的計劃如下：

• 我們計劃去評估Envoy。事實上，Envoy不止是API網(wǎng)關(guān)，它是service mesh，但是也提供了API網(wǎng)關(guān)功能，能放在應(yīng)用的前面。

• Undertow也有反向代理能力，所以我們也計劃去評估一下。

• Netflix基于Netty的非阻塞重新設(shè)計了Zuul應(yīng)用，新的版本叫“Zuul 2”。如果官方發(fā)布了新版本的Zuul，我們也會進行性能壓測，然后將壓測結(jié)果分享出來。

• Spring Cloud Gateway依然在開發(fā)中，基于Netty的非阻塞的Java網(wǎng)關(guān)，所以對我們來說是一個很好的候選。我們將會評估它的官方穩(wěn)定版的性能。

• 一些API網(wǎng)關(guān)（Zuul 1）是阻塞的，另外一些（Zuul 2、Linkerd、Envoy）是非阻塞的。阻塞架構(gòu)對開發(fā)和跟蹤請求友好，但是阻塞可能產(chǎn)生擴展性問題。非阻塞架構(gòu)對于團隊開發(fā)和跟蹤更復(fù)雜，但是有更好的可擴展和彈性。我們之后將會決定使用阻塞架構(gòu)還是使用非阻塞架構(gòu)。

• 我們將使用Gatling做性能測試，將在我們的下一篇博客中共享結(jié)果。

我們將會在博客中共享每一步的成功結(jié)果，敬請期待！

?

文中鏈接

[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/

總結(jié)

以上是生活随笔為你收集整理的微服务网关哪家强？一文看懂Zuul, Nginx, Spring Cloud, Linkerd性能差异的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。