經典架構拆解 · 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 流量，必須把內容推到離使用者最近的地方。
- 晚間尖峰時段，單一熱門影集（例如《魷魚遊戲》）可以在同一小時內被數千萬帳號同時點播。
規模大本身沒什麼好學的，真正要學的是怎麼把這種規模拆成一個個管得動的架構決策。
架構演進簡史
| 年份 | 里程碑 | 意義 |
|---|---|---|
| 2008 | 資料庫大規模損壞事件 | Netflix 決定不再自建資料中心，開始搬上 AWS |
| 2011 | 發布 Chaos Monkey | 首次把「主動讓 EC2 隨機關機」變成正式工程實踐 |
| 2013 | Zuul gateway 開源 | 把前端路由、認證、限流統一收攏到 API gateway |
| 2016 | 完成 AWS 遷移 | 最後一個地端資料中心關機，七年上雲計畫結束 |
| 2017–今 | Open Connect 深度嵌入 ISP | 全球 1,000+ ISP 直接在機房放 Netflix 快取盒 |
把這條演進線收斂成一張圖，整個系統的骨架大概長這樣：
Netflix 核心架構：影片走 Open Connect 直送各地 ISP；控制流經 Zuul 進入 AWS 上的微服務，行為事件走 Kafka 做離線推薦；Chaos Monkey 常態注入故障。
核心技術決策
| 決策 | 為何這樣選 | 替代方案與為何沒選 |
|---|---|---|
| 影片走 Open Connect（自建 CDN 嵌入 ISP） | 影片檔大、流量長、商業 CDN 在高訂閱密度地區成本會爆炸；直接把快取放進 ISP 機房還能降低跨境骨幹壓力 | 純買 Akamai / CloudFront：成本隨流量線性成長，無法優化骨幹 |
| 控制平面全上 AWS，不自建資料中心 | Netflix 想把資源投在差異化能力（推薦、編碼、個人化），不想再管硬體 | 自建或混合雲：維運負擔與擴容速度都跟不上業務 |
| 微服務 + Zuul gateway | 拆到幾千個服務，讓不同團隊能獨立部署；gateway 統一處理路由、認證、限流 | 單體或粗粒度 SOA：部署頻率被互相阻擋 |
| 主動混沌工程（Chaos Monkey / Simian Army） | 與其被動等故障發生，不如每天在正式環境（production）隨機拔插頭，強迫所有服務具備容錯 | 僅做 staging 測試：staging 永遠無法重現真實流量與依賴圖 |
| 推薦與個人化用 event-driven + 離線訓練 | 使用者行為量太大，無法同步處理；用 Kafka 匯流後離線建模、線上推論 | 全線即時：延遲與成本都不可行 |
這張表裡最值得體會的，是「成本會隨流量怎麼長」這個直覺。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 即時派單架構，看他們怎麼用地理分片，搞定「每秒鐘成千上萬次的司機與乘客配對」。
🎯 換你練習
相關文章
您可能也會對這些文章感興趣
經典架構拆解 · 01 — Netflix 全球串流架構
拆解 Netflix 如何用 Open Connect、微服務與混沌工程撐起全球逾 3 億訂閱戶，對應 PCA 全球負載均衡與容錯考點。
經典架構拆解 · 02 — Uber 即時派單架構
拆解 Uber 如何用 H3 地理分片、Ringpop 一致性雜湊與 Cadence workflow 撐起即時派單，對應 PCA 事件驅動與地理分區考點。
經典架構拆解 · 03 — Stripe API 冪等性設計
拆解 Stripe 如何把冪等性（idempotency）寫進 API 骨子裡，避免重複扣款，對應 PCA at-least-once 與 webhook retry 考點。
