經典架構拆解 · 01 — Netflix 全球串流架構

講到串流影片，有一家公司的工程選擇幾乎是每個架構師都讀過的：Netflix。他們厲害的地方不只是規模大，而是每個決策背後都有一個說得出口的業務理由——這也剛好是 PCA（Professional Cloud Architect）考試最想看你示範的思維：不是背服務，是解釋「為什麼是這個」。

這是經典工程架構拆解系列的第一篇，我們從最具代表性的 Netflix 開始。

為什麼值得拆解

Netflix 從 2008 年資料庫崩潰那一刻開始，花了 7 年把自家服務搬上 AWS，後來又花了更久的時間，把整個平台拆成上千個微服務（microservices）。他們公開聊過的那些架構模式，像是 Open Connect CDN、Chaos Engineering、Zuul gateway、Hystrix 熔斷器（circuit breaker），幾乎都成了整個產業的教材。

對 PCA 考生來說，Netflix 這個案例剛好踩在三個常考的點上：全球流量分散（global load distribution）、active-active 容錯、事件驅動架構（event-driven architecture）。這三件事後面各會配一個考場提點，告訴你題目會怎麼問、選項會怎麼挖坑。把這家公司的設計邏輯弄懂，你就會發現很多看似不同的考題，其實在問同一件事。

商業規模與壓力

根據 Netflix 2024 年 Q4 財報公開揭露，付費訂閱戶在 2024 年底超過 3.01 億，全球約 190 個國家有服務；單季營收約 102 億美元。根據 Sandvine 於 2023 年公開發表的《Global Internet Phenomena Report》，Netflix 流量長期占據北美下行網際網路頻寬前三名，部分時段可達總量的 14% 以上。

這種規模代表什麼意思？

• 任何一個微服務若失效 5 分鐘，就可能影響數百萬同時觀看的使用者。
• 單一資料中心（data center）無論多大，都裝不下全球的 ISP 流量，必須把內容推到離使用者最近的地方。
• 晚間尖峰時段，單一熱門影集（例如《魷魚遊戲》）可以在同一小時內被數千萬帳號同時點播。

規模大本身沒什麼好學的，真正要學的是怎麼把這種規模拆成一個個管得動的架構決策。

架構演進簡史

把這條演進線收斂成一張圖，整個系統的骨架大概長這樣：

核心技術決策

這張表裡最值得體會的，是「成本會隨流量怎麼長」這個直覺。Netflix 走 Open Connect 是因為商業 CDN 的帳單跟著流量線性爬，規模到了就爆——我在一個小很多的案子也碰過同一種取捨：一個下載量不大的媒體網站，早期圖檔與影片全靠物件儲存直出，每月 egress（對外流量）費用看著還好，直到一支內容被分享出去，當月流量翻了快十倍，帳單也跟著翻。後來在前面掛一層 CDN，把熱門檔案快取住，下個月成本就壓回來了。規模差了好幾個數量級，但底層的力學一模一樣：會隨流量線性成長的成本，遲早要靠快取或邊緣攔下來，這也是 PCA 算成本題時最常見的轉折點。

如果用 GCP 重新蓋

若今天要在 GCP 上重蓋類似平台，可以這樣對應：

• 邊緣內容分發： Cloud CDN + Media CDN，搭配 Cross-Cloud Interconnect 拉到主要 ISP；真正重度的 ISP 嵌入仍需自建，GCP 端提供來源（origin）層。
• 微服務平台： GKE（regional cluster）+ Cloud Service Mesh（原 Anthos Service Mesh），用 Istio 做統一路由、mTLS、限流，取代 Zuul + Hystrix 的角色。
• 事件匯流： Pub/Sub 作為行為日誌與服務間事件的主幹線。
• 中繼資料（metadata）： Spanner（強一致、多區）存影片 catalog、使用者狀態；Bigtable 存 time-series 的觀看事件。
• 離線分析與推薦訓練： BigQuery + Dataflow + Vertex AI。
• 容錯演練： GCP 沒有對等 AWS Fault Injection Service 的原生託管服務，可用 Chaos Toolkit（含 GCP driver）或自建 Kubernetes 層 chaos controller（如 Chaos Mesh）。

這份對應表不是要你死背，而是練一種感覺：同樣一個業務問題，換到別朵雲也能推出差不多的架構。我自己換工具鏈時最有用的就是這種對應——把上一份工作學到的設計直覺，平移到新的雲廠商，比從零開始啃文件快太多。

📝 考場提點

全球流量分散這類題，PCA 最常用「跨洲使用者抱怨延遲」或「某區域流量暴增」當包裝。看到關鍵字就往邊緣靠：靜態與大檔（影片、圖片、套件）→ Cloud CDN / Media CDN 把內容快取到離使用者最近的 PoP；要把全球請求導到最近、最健康的後端 → global external HTTP(S) Load Balancer（單一 anycast IP，這點常是正解的決定性差異）。

選項陷阱有兩種長相：一是給你「在每個區域各開一台 regional load balancer，再自己用 DNS 輪流」，看起來能動，但少了 anycast 與自動故障切換，跨區體驗很差——比不上單一 global LB；二是把「加大單一資料中心的機器」當答案，這在「全球」題裡幾乎一定是錯的，因為一座機房再大也吃不下全球 ISP 流量，Netflix 當年就是看清這件事才走 Open Connect。

常見誤解

• 「Netflix 所有東西都放 AWS」 —— 錯。影片本體走 Open Connect，只有控制平面、計費、推薦訓練在 AWS。把兩者混為一談會低估 CDN 成本對架構的決定性。
• 「Chaos Monkey 只是測試工具」 —— 它的意義不是工具本身，而是把「故障永遠會發生」變成工程文化。考題若問「如何驗證多區容錯」，答案不是跑一次 failover drill，而是建立常態化注入故障的流程。
• 「微服務越多越好」 —— Netflix 公開承認過微服務的複雜度成本極高，需要 Zuul、Eureka（服務發現，幫服務互相找到對方）、Hystrix（熔斷器，某個下游掛了就先擋住、不讓故障擴散）等一整套治理工具。盲目拆分會複製複雜度但沒有對應團隊能力。

關於同步依賴這件事，我自己踩過一個小坑：一個訂單系統在送出訂單的同一條請求裡，順手同步呼叫了寄信服務寄確認信。平常沒事，直到某天郵件供應商變慢，整個下單流程跟著卡住——明明信晚點寄完全沒關係，卻因為綁在同一條同步鏈上，把核心交易一起拖垮。後來把寄信改成丟一則訊息到佇列、由背景處理，下單就再也不受它影響。Netflix 把計費、推薦、觀看事件全推上訊息佇列是同樣的道理，只是他們的量級大到非這樣不可；而這個「該解耦的地方有沒有解耦」正是 PCA 反覆在考的判斷。

📝 考場提點

容錯題的關鍵字是「region 掛掉還要能服務」「跨區自動切換」「RTO 接近零」。看到就往 active-active（雙活：兩區平常都在收流量，一區掛了另一區直接頂上，前面用 global LB 自動把故障區的流量導走）想，而不是 active-passive 的冷備援（備援區平常閒置，出事才啟動）——後者切換要時間，碰到「分鐘內接管」「使用者無感」的要求會輸。資料層別忘了配跨區強一致的 Spanner，不然算到 region 切換才發現資料不同步。陷阱選項常見「靠人工觸發 failover」或「只跑過一次演練就當作驗證完成」，這兩個都會被「常態化、自動化」的選項比下去。

另一條主線是事件驅動解耦：題目描述「尖峰時上游一變慢、下游就整串卡死」或「兩個服務硬綁在一起、要一起部署」，答案幾乎都是在中間插一層 Pub/Sub 把同步呼叫改成非同步。看到「削峰填谷」「buffer 突發流量」「服務間不要直接相依」這些字眼，先往訊息佇列靠，再回頭檢查選項裡有沒有人把它包成別的服務。

來源與延伸閱讀

• Netflix TechBlog — Netflix 公開工程部落格，Open Connect、Hystrix、Chaos Monkey 原始說明皆在此。
• Netflix Open Connect 官網 — Netflix 對 ISP 說明自家 CDN 的官方頁面，含硬體規格與嵌入流程。
• Chaos Monkey GitHub — 開源 repo 與設計文件。
• Sandvine Global Internet Phenomena Report 2023 — 公開引用的全球網路流量年度報告，內含 Netflix 占比數據。
• Netflix Q4 2024 Shareholder Letter — 訂閱戶、營收等財報數字引用來源。

下一篇：規模一樣大，但問題完全不同的Uber 即時派單架構，看他們怎麼用地理分片，搞定「每秒鐘成千上萬次的司機與乘客配對」。

🎯 換你練習

想動手設計類似系統？到 架構師設計工作坊 用這套思考步驟走一遍，也可以對照 PCA 五大案例庫 的官方題目練手。