Netflix正式开源其API网关Zuul 2--转
微信公眾號：聊聊架構
5 月 21 日，Netflix 在其官方博客上宣布正式開源微服務網關組件 Zuul 2。Netflix 公司是微服務界的楷模，他們有大規模生產級微服務的成功應用案例，也開源了相當多的微服務組件（詳見 GitHub 主頁），受到了業內同行的高度認可。Zuul 是 Netflix 于 2013 年 6 月 12 日開源的網關組件，目前在 GitHub 已經有超過 4000 個關注，包括 Riot、攜程、拍拍貸等公司都已經在生產環境中使用。
Zuul 在英文中是一種怪獸，星際爭霸中蟲族里頭也有 Zuul，Netflix 為網關起名 Zuul，寓意看門神獸。2013 年左右，InfoQ 曾經對前 Netflix 架構總監 Adrian Cockcroft 有過一次專訪，其中有問 Adrian：“Netflix 開源這么多項目，你認為哪一個是最不可或缺的 (MOST Indispensable)”，Adrian 回答說：“在 NetflixOSS 開源項目中，有一個容易被忽略，但是 Netflix 最強大的基礎服務之一，它就是 Zuul 網關服務。Zuul 網關主要用于智能路由，同時也支持認證，區域和內容感知路由，將多個底層服務聚合成統一的對外 API。Zuul 網關的一大亮點是動態可編程，配置可以秒級生效”。從 Adrian 的回答中，我們可以感受到 Zuul 網關對微服務基礎架構的重要性。
因為 Zuul 開源時間較早，在架構方面也存在一些問題，所以在 2016 年 9 月，Netflix 對外宣布他們將會調整 Zuul 的架構。Zuul 原本采用同步阻塞架構，轉型后叫作 Zuul 2，采用異步非阻塞架構。Zuul 2 和 Zuul 1 在架構方面的主要區別在于，Zuul 2 運行在異步非阻塞的框架上，比如 Netty。Zuul 1 依賴多線程來支持吞吐量的增長，而 Zuul 2 使用的 Netty 框架依賴事件循環和回調函數。
下面是 Netflix 官方博客中對于 Zuul 2 的介紹，供讀者參考。
Netflix 的 Cloud Gateway 團隊運行并維護著 80 多個 Zuul 2 集群，將流量分發到大約 100 個（還在不斷增長）后端服務集群，每秒的請求數超過 100 萬個。所有這些流量幾乎都來自啟用了大家熟悉的發現和回放體驗的客戶端設備和瀏覽器。
本文將詳細介紹 Netflix 今天發布的 Zuul 2 的一些有趣特性，并討論我們正在使用 Zuul 2 構建的其他一些項目。
Zuul 2 的工作原理
以下是 Zuul 2 的大體架構圖：
過濾器前端和后端的 Netty 事件處理器（handler）主要負責處理網絡協議、Web 服務器、連接管理和代理工作。這些內部工作被抽象之后，所有主要的工作都會交給過濾器完成。入站過濾器在代理請求之前運行，可用于驗證、路由或裝飾請求。端點過濾器可用于返回靜態響應，或將請求代理到后端服務。出站過濾器在返回響應后運行，可用于諸如壓縮（gzipping）、指標或增刪自定義請求頭之類的內容。
Zuul 的功能幾乎完全取決于每個過濾器的邏輯。這意味著它可以部署在多種上下文中，使用配置和運行的過濾器解決不同的問題。
我們在所有外部流量進入 Netflix 云服務的入口處都會使用 Zuul，并且也開始使用它來路由內部流量。Zuul用作外部流量網關和內部流量網關時，Zuul的核心架構是一樣的，只是用作內部流量網關時實現相應功能的過濾器要少很多。
正式開源
今天運行的 Zuul 代碼是 Zuul 最穩定和最有彈性的版本。經過多個階段的代碼庫演化和重構，我們無比高興將它分享給你們。
今天我們將發布許多核心特性。以下是最讓人激動的：
服務器協議
-
HTTP/2——完整的入站（inbound）HTTP/2 連接服務器支持
-
雙向 TLS（Mutual TLS）——支持在更安全的場景下運行 Zuul
彈性特性
-
自適應重試——Netflix 用于增強彈性和可用性的核心重試邏輯
-
源并發保護——可配置的并發限制，避免源過載，隔離 Zuul 背后的各個源
運營特性
-
請求 Passport——跟蹤每個請求的所有生命周期事件，這對調試異步請求非常有用
-
狀態分類——請求成功和失敗的可能狀態枚舉，比 HTTP 狀態碼更精細
-
請求嘗試——跟蹤每個代理的嘗試和狀態，對調試重試和路由特別有用
我們也在研究一些即將推出的功能，包括：
-
Websocket/SSE——支持通道推送通知
-
限流和限速——防止惡意客戶端連接和請求，幫助抵御大規模攻擊
-
掉電過濾器——Zuul 過載時禁用一些 CPU 密集型特性
-
可配置路由——基于文件的路由配置，而不需要在 Zuul 中創建路由過濾器
Zuul 2 在 Netflix 的應用
在 Netflix，幾個主要特性我們一直在研究，但尚未開源。每一個都值得專門寫一篇博文介紹，但是我們現在只簡單介紹一下。
?自助服務路由
我們的合作伙伴使用最廣泛的特性是自助服務路由。我們為用戶提供應用程序和 API，以根據請求 URL、路徑、查詢參數或請求頭中的任何條件創建路由規則。然后，我們將這些路由規則發布到所有 Zuul 實例。
主要的用例是將流量路由到特定的測試或臨時集群。但是，實際生產流量有很多用例。例如：
-
需要分割流量的服務會創建路由規則，將某些路徑或前綴映射到不同的源
-
通過創建新主機名映射到新的源的路由，開發人員上線新服務
-
開發人員運行負載測試，將一定比例的現有流量路由到小型集群，并確保應用程序在負載情況下會優雅地服務降級
-
通過逐步創建映射流量的規則，一次一條路徑，重構應用程序的團隊可以逐漸遷移到新的源
-
團隊通過向運行新版本的插樁群集（instrumented cluster）發送一小部分流量來測試變更（金絲雀測試）
-
如果團隊測試的變更需要多次連續請求新版本，他們將運行 Sticky 金絲雀測試，短時間內將同一批用戶路由到新版本
-
安全團隊創建基于路徑或請求頭的規則，拒絕所有 Zuul 集群中的“惡意”請求
正如你所看到的，我們廣泛地使用自助服務路由，并且在增加路由的可定制性和范圍，以支持更多的用例。
?彈性負載均衡
我們一直在努力的另一個主要特性是，使負載均衡更加智能化。我們能夠繞過運行大量節點時經常出現的故障、緩慢、GC 問題以及各種其他問題。這個特性的目標是提高所有 Netflix 服務的彈性、可用性和服務質量。
以下是我們處理的幾個案例：
冷實例
當新的源實例啟動時，一段時間內，我們會將它們的流量減少，直到它們變熱。在具有大型代碼庫和使用巨大的元數據空間的應用程序中，我們觀察到了這個問題。這些應用需要花費大量的時間來解釋（JIT）代碼并準備好處理大量的流量。
如果碰巧命中影響速度的冷卻的實例，我們通常還會將流量偏向較舊的實例，我們總是可以重試熱的實例。這使我們在可用性方面有了一個數量級的提高。
高錯誤率
由于各種原因，錯誤總是發生，無論是由于代碼中的錯誤、錯誤的實例還是設置了無效的配置屬性。幸運的是，作為代理，我們可以可靠地檢測錯誤——無論是 5xx 錯誤還是服務連接問題。
我們跟蹤每個源的錯誤率，如果錯誤率很高，這意味著整個服務都有問題。我們限制設備的重試次數并禁用內部重試，以便服務恢復。此外，我們還會追蹤每個實例的連續失敗并在一段時間內將失敗的實例列入黑名單。
過載實例
通過上述方法，我們向集群中限流或拒絕連接的服務器發送較少的流量，并通過在其他服務器上重試這些失敗請求來減輕影響。
我們現在正推出一個額外的方法，目標是一開始就避免服務器過載。這是通過讓源向 Zuul 發送它們當前的利用率來實現的，Zuul 然后將利用率用作其負載均衡選擇中的一個因子——從而降低錯誤率、重試和延遲。
源為所有響應添加請求頭，說明其百分比利用率，以及期望的整個集群的目標利用率。計算百分比利用率完全取決于每個應用程序，工程師可以使用最適合他們的任何指標。與我們提出一種通用的方法相比，這可以提供一個一般的解決方案。
通過這個特性，我們為每個實例分配一個分數（實例利用率和其他因素的組合），并進行二選一負載均衡選擇。
?異常檢測和上下文警告
隨著我們從少數幾個源發展到任何人都可以快速啟動一個容器集群并將其部署在 Zuul 后面，我們發現需要自動檢測并確定源的故障。
得益于 Mantis 實時事件流，我們構建了一個異常檢測器，匯總每項服務的錯誤率，并在服務出現問題時實時通知我們。它根據給定的時間窗口內所有異常，創建一個所有有問題的源的時間表。然后，我們創建一個包含上下文的警報電子郵件，其中包含事件時間表和受影響的服務。這使得運維人員可以快速關聯這些事件并厘清思路，調試特定的應用程序或功能，并最終找到根本原因。
事實上，發送通知給源團隊本身非常有用。除 Zuul 之外，我們還添加了更多內部應用程序，可以構建更為廣泛的事件時間表。這在生產事故中提供了巨大幫助，幫助運維人員在發生嚴重中斷之前迅速發現并解決問題。
原文地址：https://medium.com/netflix-techblog/open-sourcing-zuul-2-82ea476cb2b3
轉載于:https://www.cnblogs.com/davidwang456/p/9103832.html
總結
以上是生活随笔為你收集整理的Netflix正式开源其API网关Zuul 2--转的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Anaconda(miniconda)安
- 下一篇： python vs java的rsa加密