Netflix 以其龐大的原創(chuàng)內(nèi)容庫而聞名。你是否曾想過支撐其運營的技術(shù)？

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

01 大單體

早期，Netflix Studio 采用的是單體架構(gòu)。想象一下一個龐大的互聯(lián)系統(tǒng)，所有組件都是一個統(tǒng)一代碼庫的一部分。

02 直接訪問

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

03 網(wǎng)關(guān)聚合層

但直接訪問的效果卻遠(yuǎn)非理想。為了克服這一難題，他們引入了網(wǎng)關(guān)聚合層。他們構(gòu)建了一個 API 網(wǎng)關(guān)，將所有服務(wù)綁定在一起為客戶提供統(tǒng)一的前臺。這種設(shè)置非常適用于跨多個服務(wù)的用例。

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

04 聯(lián)合網(wǎng)關(guān)

網(wǎng)關(guān)聚合層本應(yīng)帶來秩序，但隨著團隊的壯大，服務(wù)的增多和領(lǐng)域復(fù)雜性的增加，開發(fā)網(wǎng)關(guān)聚合層變得越來越困難。為了解決這個問題，Netflix 使用 GraphQL 并引入了聯(lián)合網(wǎng)關(guān)（Federated Gateway）。

這一策略允許領(lǐng)域?qū)＜夜芾碜约旱?"圖"，同時為各種 Studio 應(yīng)用程序提供統(tǒng)一、高效的訪問點。

GraphQL 是 Federated Gateway 的核心。這種強大的查詢語言使用戶界面能在一次往返中準(zhǔn)確獲取所需內(nèi)容。GraphQL 聯(lián)合允許 Netflix 建立一個單一的 GraphQL 網(wǎng)關(guān)，從所有其他 API 獲取數(shù)據(jù)。

從單體到聯(lián)合網(wǎng)關(guān)的過程說明，系統(tǒng)架構(gòu)應(yīng)適應(yīng)不斷動態(tài)增長的業(yè)務(wù)需求。

我們也不應(yīng)該單純地去復(fù)制 Netflix 和 Google 等巨頭的基礎(chǔ)設(shè)施，因為這些需求我們可能永遠(yuǎn)也遇不到。無需過度優(yōu)化我們不存在的問題。

最好的架構(gòu)是適合我們業(yè)務(wù)需求的架構(gòu)，而不是模仿科技巨頭。