作為OpsGenie，我們在員勞工數和産品功能方面都在積極發展。為了給您一些想法，我們的工程團隊從去年的15人增加到了50人。為了擴大開發團隊，我們遵循兩個比薩餅團隊規則将工程能力劃分為八人團隊。
如您所料，我們目前的産品有些單片。在團隊的并行開發工作，CI / CD(連續內建/連續傳遞)流程等方面，開發和操作它具有挑戰性。我們正在順應目前的趨勢，并緻力于從整體式架構過渡到微服務架構。你可以閱讀更多關于微服務架構和Martin Fowler的它的好處此文章。
有一些建議的體系結構模式可用于應用微服務概念。這些模式之一是API網關。API網關是所有用戶端的單個入口點。API網關以兩種方式之一處理請求。一些請求僅被代理/路由到适當的服務。它通過扇出多個服務來處理其他請求。
API網關模式是微服務體系結構的一個很好的起點，因為它可以将特定的請求路由到我們從整體中分離的不同服務。實際上，API網關對我們來說不是一個新概念。到目前為止，我們一直在整體應用程式之前使用Nginx作為API網關，但是我們想在微服務轉換的背景下重新評估我們的決定。我們關心性能，易擴充性和速率限制等附加功能。第一步是評估替代方案在重負荷下的性能，以確定它們的規模足以滿足我們的需求。
在此部落格文章中，我們解釋了如何設定測試環境并比較替代API網關的性能：Zuul 1，Nginx，Spring Cloud Gateway和Linkerd。實際上，我們還有其他選擇，例如Lyft的Envoy和UnderTow。我們将使用這些工具執行類似的測試，并在以後的部落格文章中分享結果。
Zuul 1對我們來說似乎很有希望，因為它是用Java開發的，并得到Spring架構的大力支援。已經有一些部落格文章将Zuul與Nginx進行了比較，但是我們還想評估Spring Cloud Gateway和Linkerd的性能。此外，我們計劃執行進一步的負載測試，是以我們決定設定自己的測試工作台。
為了獨立評估API網關的性能，我們建立了獨立于OpsGenie産品的隔離測試環境。我們使用了Apache Http Server基準測試工具-ab作為基準測試。
我們首先根據官方Nginx文檔将Nginx安裝到AWS EC2 t2.micro執行個體。該環境是我們的初始測試環境，我們在此環境中添加了Zuul和Spring Cloud Gateway安裝。Nginx Web伺服器托管靜态資源，我們為Nginx，Zuul和Spring Cloud Gateway定義了Web伺服器的反向代理。我們還啟動了另一個t2.micro EC2來執行請求(用戶端EC2)。
初始測試環境
圖中的虛線箭頭是我們的測試路徑。其中有四個：
- 直接通路
- 通過Nginx反向代理通路
- 通過Zuul通路
- 通過Spring Cloud Gateway通路
- 通過Linkerd通路
我們知道您不耐煩看到結果，是以讓我們先給出結果，然後再給出詳細資訊。
績效基準摘要
測試政策
我們使用了Apache HTTP Server基準測試工具。每次測試運作時，我們使用200個并發線程發出10,000個請求。
ab -n 10000 -c 200 HTTP：// /
我們對三種不同的AWS EC2伺服器配置進行了測試。我們在每個步驟中縮小了測試用例，以進一步闡明：
- 我們僅在第一步中執行了其他直接通路測試，以檢視代理的開銷，但是由于直接通路不是我們的選擇，是以我們沒有在後續步驟中執行此測試。
- 由于Spring Cloud Gateway仍未正式釋出，是以我們僅在最後一步對其進行了評估。
- 在第一次通話後的後續通話中，Zuul的表現更好。我們認為這可能是由于在第一次調用時執行了JIT(及時)優化，是以我們将Zuul運作的第一個調用稱為“預熱”。下表彙總表中顯示的值是預熱性能之後的值。
- 我們知道Linkerd是一個資源密集型代理，是以我們僅在最後一步将它與最高資源配置進行了比較。
測試配置
T2.Micro —單核CPU，1GB記憶體：我們進行了直接通路，Ngnix反向代理和Zuul(預熱後)的測試。
M4.Large —雙核CPU，8GB記憶體：我們比較了Nginx反向代理和Zuul(預熱後)的性能。
M4.2xLarge — 8核心CPU，32GB記憶體：我們比較了Nginx反向代理，Zuul(預熱後)，Spring Cloud Gateway和Linkerd的性能。
試驗結果
性能基準摘要如下：
測試細節
直接通路請求
首先，我們直接通路靜态資源而沒有任何代理。結果如下。每個請求的平均時間為30毫秒。
直接通路靜态資源
通過Nginx反向代理通路
在第二個測試中，我們通過Nginx反向代理通路資源。每個請求的平均時間為40毫秒。我們可以說Nginx反向代理與上一節中說明的直接通路相比平均增加了％33的開銷。
Ngnix反向代理的性能
通過Zuul反向代理通路
之後，我們使用主方法建立了一個Spring Boot Application：
這是我們的application.yml檔案：
初始Zuul測試的結果如下：
Zuul反向代理首次運作性能
對于直接通路和Nginx反向代理，每個Nginx請求的時間分别為30ms和40ms。每次運作Zuul的每次請求時間為388ms。如其他部落格文章所述，JVM預熱可能會有所幫助。當我們重新運作測試時，我們得到以下結果：
預熱後的Zuul反向代理
預熱後，Zuul代理的性能更好(每個請求的時間為200毫秒)，但與得分為40毫秒的Nginx反向代理相比，效果仍然不佳。
如果我們将伺服器更新到m4.large怎麼辦？
如圖1所示，伺服器是t2.micro ec2，它具有單個核心和1GB記憶體。Nginx是本機C ++應用程式，而Zuul是基于Java的。我們知道Java應用程式有點:)要求更高。是以，我們将伺服器更改為具有兩個CPU核心和8GB記憶體的m4.large執行個體。
我們再次運作了Nginx和Zuul反向代理測試，結果如下：
M4.large上的Nginx反向代理
m4.large上的Zuul反向代理(預熱後)
如上圖所示，Nginx和Zuul的每秒請求值分别為32ms和95ms。這些結果要好于t2.micro上40ms和200ms的測試結果。
一個有效的批評是，我們通過Spring Boot應用程式使用Zuul引入了額外的開銷。如果我們将Zuul作為獨立的應用程式運作，則很有可能會更好地執行。
如果将伺服器更新到m4.2xlarge怎麼辦？
我們還評估了具有八個核心和32GB記憶體的m4.2xlarge伺服器。下圖給出了Ngnix和Zuul的結果：
M4.2xlarge伺服器上的Nginx反向代理
M4.2xlarge伺服器上的Zuul反向代理
Zuul在m4.2xlarge伺服器上的性能優于Ngnix。我們進行了一些研究，以找出Netflix用于托管Zuul執行個體的ec2執行個體類型，但找不到任何有關它的資訊。在一些部落格文章中，人們抱怨Zuul的性能，并詢問Netflix如何擴充它。我們認為這就是答案；據說，Zuul受CPU限制:)
Linkerd的基準
Linkerd是Cloud Native Computing Foundation的成員項目。它是在Scala中開發的服務網格應用程式。除了服務網格功能(例如服務發現)以外，它還提供反向代理功能。我們評估了Linkerd的性能，并在下面給出結果。Linkerd的表現與Zuul非常接近。
m4.2xlarge伺服器上的Linkerd反向代理
Spring Cloud Gateway基準
Spring Cloud社群也在開發網關子產品。盡管尚未正式釋出，但我們認為值得将其與其他替代産品進行比較。是以，我們根據測試環境修改了網關應用程式的示例應用程式。
我們使用Apache Http Server Benchmarking Tool進行了相同的性能測試，該工具使用200個并發線程發送10,000個請求。結果如下圖所示：
m4.2xlarge伺服器上的Spring Cloud Gateway
如圖所示，Spring Cloud Gateway每秒可以處理873個請求，每個請求的平均時間為229ms。根據我們的測試，Spring Cloud Gateway的性能無法達到Zuul，Linkerd和Nginx的水準，至少在目前基于Github的代碼庫中是如此。Nginx，Zuul，Linkerd和Spring Cloud Gateway的比較已在“基準摘要”部分末尾給出。