簡介
您可以在幾個小時內編寫一個簡單的 CRUD 應用程式。但是，當該應用程式需要服務數百萬用戶，每秒處理數千個請求，並確保99.99% 的正常運行時間時 - 這就是您需要系統設計的時候。
系統設計不僅僅是面試的知識。這是一項核心技能，可以幫助您：
- 建構可擴展的系統
- 做出正確的架構決策
- 避免代價高昂的錯誤（重建整個系統）
- 與團隊就技術決策進行有效溝通
1.什麼是系統設計？
1.1 定義
系統設計是確定軟體系統的架構、組件、模組、介面和資料以滿足特定要求的過程。
System Design = Architecture + Components + Data Flow + Trade-offs
1.2 為什麼系統設計很重要？
| 相 | 沒有系統設計 | 是的系統設計 |
|---|---|---|
| 原型 | 快速、簡單 | 有一個清晰的計劃 |
| 100 位使用者 | 運作良好 | 運作良好 |
| 10K 用戶 | 慢啟動 | 依然穩定 |
| 100 萬用戶 | 系統崩潰，不得不重寫 | 按計劃規模 |
| 成本 | 重寫 = 10x 初始成本 | 漸進式改善 |
1.3 系統設計與編碼
Coding: "Làm sao để implement feature X?"
System Design: "Làm sao để feature X hoạt động với 10M users,
99.99% uptime, <100ms latency?"
2. 如何解決系統設計問題
2.1 框架 4步
當遇到任何系統設計問題時，請使用以下框架：
┌─────────────────────────────────────────────────────┐
│ Step 1: Requirements & Constraints │
│ ┌─────────────────────────────────────────────┐ │
│ │ Functional Requirements (FR) │ │
│ │ Non-functional Requirements (NFR) │ │
│ │ Constraints & Assumptions │ │
│ └─────────────────────────────────────────────┘ │
│ ▼ │
│ Step 2: High-Level Design │
│ ┌─────────────────────────────────────────────┐ │
│ │ Main components & connections │ │
│ │ Data flow diagrams │ │
│ │ API design (endpoints) │ │
│ └─────────────────────────────────────────────┘ │
│ ▼ │
│ Step 3: Deep Dive into Core Components │
│ ┌─────────────────────────────────────────────┐ │
│ │ Database schema │ │
│ │ Algorithm choices │ │
│ │ Data structures │ │
│ └─────────────────────────────────────────────┘ │
│ ▼ │
│ Step 4: Identify & Resolve Bottlenecks │
│ ┌─────────────────────────────────────────────┐ │
│ │ Single points of failure │ │
│ │ Scaling strategies │ │
│ │ Monitoring & alerting │ │
│ └─────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────┘
2.2 範例：設計新聞閱讀系統
第 1 步 - 要求：
- FR：使用者查看文章清單、閱讀詳細資訊、搜尋、評論
- NFR：1000 萬天， <200ms latency, 99.9% availability
- Constraints: Read-heavy (100:1 read/write ratio)
Step 2 - High-Level Design:
Users → CDN → Load Balancer → Web Servers → Cache → Database
│
└→ Search Service (Elasticsearch)
Step 3 - Deep Dive:
- Database: PostgreSQL cho articles, Redis cho cache
- 搜尋：帶有全文索引的Elasticsearch
- CDN: Cache static assets + rendered HTML
Step 4 - Bottlenecks:
- Database read bottleneck → Add read replicas
- 熱門文章 → 使用 TTL 進行主動緩存
- Search latency → Elasticsearch cluster scaling
3. Monolith vs Distributed Systems
3.1 Monolithic Architecture
┌─────────────────────────────────────┐
│ Monolithic Application │
│ ┌─────┬─────┬─────┬─────┬──────┐ │
│ │ UI │User │Order│Pay │Search│ │
│ │Layer│ Svc │ Svc │ Svc │ Svc │ │
│ └─────┴─────┴─────┴─────┴──────┘ │
│ ┌─────────────────────────────┐ │
│ │ Shared Database │ │
│ └─────────────────────────────┘ │
└─────────────────────────────────────┘
優勢：
- 初始開發簡單
- 易於部署（1 個工件）
- 易於調試（單進程）
- 元件之間沒有網路延遲
缺點：
- 很難縮放每個單獨的部分
- 一個小錯誤可能會導致整個系統崩潰
- 當程式碼庫很大時部署很慢
- Technology lock-in (1 language/framework)
3.2 Distributed Systems
┌────────┐ ┌────────┐ ┌────────┐ ┌────────┐
│ User │ │ Order │ │Payment │ │ Search │
│Service │ │Service │ │Service │ │Service │
│ DB │ │ DB │ │ DB │ │ DB │
└───┬────┘ └───┬────┘ └───┬────┘ └───┬────┘
│ │ │ │
└───────────┴─────┬─────┴───────────┘
│
Message Queue / API Gateway
優勢：
- 獨立擴展每項服務
- 故障隔離（1個服務故障≠整個系統故障）
- 團隊自治（每個團隊擁有 1 項服務）
- Technology diversity
缺點：
- 更複雜
- 服務之間的網路延遲
- Data consistency challenges
- Operational overhead (monitoring, debugging)
3.3 什麼時候選擇什麼？
| 標準 | 巨石 | 分散式 |
|---|---|---|
| Team size | < 10 developers | > 10 名開發人員 |
| 交通 | < 10K RPS | > 10K RPS |
| 階段 | MVP，早期啟動 | 成長、規模 |
| 複雜性 | 中 | 高 |
| 部署頻率 | 每週/每月 | 每日/每小時 |
建議： 大多數系統應該從 Monolith 開始，然後根據需要擴展到分散式。不要從一開始就過度設計！
4. 需要掌握的核心概念
4.1 系統設計圖
System Design
│
┌────────────────────┼────────────────────┐
│ │ │
Fundamentals Components Patterns
│ │ │
├─ Scalability ├─ Load Balancer ├─ Microservices
├─ Availability ├─ CDN ├─ Event-Driven
├─ Consistency ├─ Cache ├─ CQRS
├─ Latency ├─ Database ├─ Saga
├─ Throughput ├─ Message Queue ├─ Circuit Breaker
├─ CAP Theorem ├─ API Gateway ├─ DDD
└─ Networking ├─ Reverse Proxy └─ Serverless
└─ Search Engine
4.2 學習路線圖
Tháng 1-2: Fundamentals
├─ Scalability, Availability, Consistency
├─ CAP Theorem
└─ Networking basics
Tháng 3-4: Infrastructure Components
├─ Load Balancer, CDN, Cache
├─ Database (SQL, NoSQL, Sharding)
└─ Message Queues
Tháng 5-6: Architectural Patterns
├─ Microservices, Event-Driven
├─ CQRS, Saga, DDD
└─ Serverless
Tháng 7-8: Case Studies & Practice
├─ Design URL Shortener
├─ Design Chat System
├─ Design News Feed
└─ Design Video Streaming
5. 粗略計算
系統設計的一項重要技能是快速估算：
5.1 二的冪
| 電源 | 確切值 | 大約 | 位元組 |
|---|---|---|---|
| 10 | 10 1,024 | 1,024 1000 | 1000 1 KB |
| 20 | 1,048,576 | 1,048,576 100 萬 | 1MB |
| 30 | 1,073,741,824 | 10 億 | 1GB |
| 40 | 1,099,511,627,776 | 1兆 | 1TB |
5.2 每個程式設計師都應該知道的延遲數字
L1 cache reference: 0.5 ns
L2 cache reference: 7 ns
Main memory reference: 100 ns
SSD random read: 150,000 ns = 150 μs
HDD seek: 10,000,000 ns = 10 ms
Send 1 MB over 1 Gbps network: 10,000,000 ns = 10 ms
Read 1 MB from SSD: 1,000,000 ns = 1 ms
Read 1 MB from HDD: 30,000,000 ns = 30 ms
Roundtrip same datacenter: 500,000 ns = 500 μs
Roundtrip CA → Netherlands: 150,000,000 ns = 150 ms
5.3 範例：Twitter 的儲存估算
Giả sử:
- 500M users, 200M DAU
- Mỗi user tweet 2 lần/ngày
- Mỗi tweet: 140 chars * 2 bytes = 280 bytes
- 10% tweets có media (ảnh 200KB trung bình)
Tweets/ngày: 200M * 2 = 400M tweets
Text storage/ngày: 400M * 280B = 112 GB/ngày
Media storage/ngày: 40M * 200KB = 8 TB/ngày
Storage/năm: (112GB + 8TB) * 365 ≈ 3 PB/năm
6. 總結
| 主題 | 要點 |
|---|---|
| 系統設計 | 設計符合大規模需求的系統 |
| 框架 | 需求→進階→深入研究→瓶頸 |
| 巨石 | 從整體開始，根據需要進行分離 |
| 分散式 | 更複雜但允許縮放 |
| 估計 | 設計前一定要進行評估 |
練習
-
估價實務： 預計 YouTube 1 年內所需儲存空間（500M DAU，每天上傳 500 萬個視頻，轉碼後平均 50MB/視頻）
-
整體式 vs 分散式： 您正在為越南市場（500 萬用戶）建立飯店預訂應用程式。您會選擇整體式還是分散式？解釋一下為什麼。
-
系統設計架構： 應用 4 步驟架構來草擬 餐廳預約管理系統 的設計（5 萬家餐廳，100 萬用戶）。