Netflix 以其龐大的原創內容庫而聞名。你是否曾想過支撐其運營的技術？

今天，我們將探討 Netflix Studio API 架構的演進歷程。下圖展示了其 4 個階段。

01 大單體

早期，Netflix Studio 采用的是單體架構。想象一下一個龐大的互聯系統，所有組件都是一個統一代碼庫的一部分。

02 直接訪問

隨著 Netflix 的發展以及與更多的電影公司合作創作原創內容，這塊巨石開始成為路障。那么，下一步該怎么辦？Netflix 的工程師們將單體分割成微服務。這種轉變提高效率和自主性。它將其架構變成了一個服務網。

03 網關聚合層

但直接訪問的效果卻遠非理想。為了克服這一難題，他們引入了網關聚合層。他們構建了一個 API 網關，將所有服務綁定在一起為客戶提供統一的前臺。這種設置非常適用于跨多個服務的用例。

試想一下，Studio 服務需要 3 個 API（如電影、制作和人才）來渲染前端用戶界面，網關聚合層使之成為可能。

04 聯合網關

網關聚合層本應帶來秩序，但隨著團隊的壯大，服務的增多和領域復雜性的增加，開發網關聚合層變得越來越困難。為了解決這個問題，Netflix 使用 GraphQL 并引入了聯合網關（Federated Gateway）。

這一策略允許領域專家管理自己的 "圖"，同時為各種 Studio 應用程序提供統一、高效的訪問點。

GraphQL 是 Federated Gateway 的核心。這種強大的查詢語言使用戶界面能在一次往返中準確獲取所需內容。GraphQL 聯合允許 Netflix 建立一個單一的 GraphQL 網關，從所有其他 API 獲取數據。

從單體到聯合網關的過程說明，系統架構應適應不斷動態增長的業務需求。

我們也不應該單純地去復制 Netflix 和 Google 等巨頭的基礎設施，因為這些需求我們可能永遠也遇不到。無需過度優化我們不存在的問題。

最好的架構是適合我們業務需求的架構，而不是模仿科技巨頭。