經典架構拆解 · 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 這個案例至少涵蓋 3 個重點考點：全球流量分散（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 隨機關機」變成正式工程實踐 |
| 2012 | Zuul gateway 開源 | 把前端路由、認證、限流統一收攏到 API gateway |
| 2016 | 完成 AWS 遷移 | 最後一個地端資料中心關機，七年上雲計畫結束 |
| 2017–今 | Open Connect 深度嵌入 ISP | 全球 1,000+ ISP 直接在機房放 Netflix 快取盒 |
核心技術決策
| 決策 | 為何這樣選 | 替代方案與為何沒選 |
|---|---|---|
| 影片走 Open Connect（自建 CDN 嵌入 ISP） | 影片檔大、流量長、商業 CDN 在高訂閱密度地區成本會爆炸；直接把快取放進 ISP 機房還能降低跨境骨幹壓力 | 純買 Akamai / CloudFront：成本隨流量線性成長，無法優化骨幹 |
| 控制平面全上 AWS，不自建資料中心 | Netflix 想把資源投在差異化能力（推薦、編碼、個人化），不想再管硬體 | 自建或混合雲：維運負擔與擴容速度都跟不上業務 |
| 微服務 + Zuul gateway | 拆到幾千個服務，讓不同團隊能獨立部署；gateway 統一處理路由、認證、限流 | 單體或粗粒度 SOA：部署頻率被互相阻擋 |
| 主動混沌工程（Chaos Monkey / Simian Army） | 與其被動等故障發生，不如每天在正式環境（production）隨機拔插頭，強迫所有服務具備容錯 | 僅做 staging 測試：staging 永遠無法重現真實流量與依賴圖 |
| 推薦與個人化用 event-driven + 離線訓練 | 使用者行為量太大，無法同步處理；用 Kafka 匯流後離線建模、線上推論 | 全線即時：延遲與成本都不可行 |
如果用 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。
- 容錯演練： 用 Fault Injection Testing 服務或自建 Kubernetes 層 chaos controller。
這份對應表不是要你死背，而是練一種感覺：同樣一個業務問題，換到別朵雲也能推出差不多的架構。
PCA 考點映射
| 考點 | Netflix 對應 |
|---|---|
| 全球負載均衡與邊緣分發 | Open Connect + 控制平面分區部署，題目常問「如何降低跨洲延遲」 |
| active-active 與 region 失效切換 | Netflix 控制平面部署在 3 個 AWS region，任何一個掛掉可在分鐘內接管 |
| event-driven 解耦 | 推薦、計費、觀看事件全走訊息佇列（Kafka / Pub/Sub），考點會問「如何避免同步依賴」 |
常見誤解
- 「Netflix 所有東西都放 AWS」 —— 錯。影片本體走 Open Connect，只有控制平面、計費、推薦訓練在 AWS。把兩者混為一談會低估 CDN 成本對架構的決定性。
- 「Chaos Monkey 只是測試工具」 —— 它的意義不是工具本身，而是把「故障永遠會發生」變成工程文化。考題若問「如何驗證多區容錯」，答案不是跑一次 failover drill，而是建立常態化注入故障的流程。
- 「微服務越多越好」 —— Netflix 公開承認過微服務的複雜度成本極高，需要 Zuul、Eureka、Hystrix 等一整套治理工具。盲目拆分會複製複雜度但沒有對應團隊能力。
來源與延伸閱讀
- 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 即時派單架構，看他們怎麼用地理分片，搞定「每秒鐘成千上萬次的司機與乘客配對」。
🎯 換你練習