這部影片由 Dev Mastery 頻道推出，是一堂系統設計入門到進階的完整課程。內容涵蓋從單一伺服器架構開始，逐步延伸到資料庫選型、負載均衡策略、API 設計原則（REST、GraphQL、gRPC）、網路協定（TCP/UDP）、身分驗證與授權機制，以及 API 安全防護七大技巧。適合想要突破中階瓶頸、準備系統設計面試的開發者。

---

原影片連結：https://www.youtube.com/watch?v=adOkTjIIDnk

影片重點

• 系統設計能力是區分中階與資深工程師的關鍵技能
• 從單一伺服器架構開始理解核心元件，再逐步擴展
• 關聯式資料庫（SQL）適合結構化資料與交易一致性；非關聯式資料庫（NoSQL）適合彈性與低延遲需求
• 垂直擴展有上限，水平擴展搭配負載均衡器才是大規模應用的解法
• 七種負載均衡演算法各有適用場景：Round Robin、Least Connections、IP Hash 等
• API 設計三大風格：REST（最常見）、GraphQL（減少來回請求）、gRPC（微服務間高效通訊）
• RESTful API 四大設計原則：一致性、簡潔性、安全性、效能
• TCP 可靠但較慢，UDP 快速但不保證送達 — 根據需求選擇
• 身分驗證從 Basic Auth 到 OAuth2 + JWT，層層遞進
• 授權模型三大類：RBAC（角色）、ABAC（屬性）、ACL（存取控制清單）
• API 安全七大技巧：Rate Limiting、CORS、SQL Injection 防護、Firewall、VPN、CSRF Token、XSS 防護

詳細內容

[00:00] 為什麼系統設計很重要

多數開發者無法從零設計一個系統。他們可以在別人建好的架構上加功能、處理明確需求的任務，但要求從頭設計時往往會卡住。這正是中階與資深工程師的分水嶺 — 資深工程師能做架構決策、處理模糊需求、設計取捨方案。公司願意付六位數薪資，不是為了會寫程式的人，而是為了能做架構決策、優化系統效能的人。

[01:30] 單一伺服器架構：一切的起點

設計支援百萬用戶的系統很複雜，但每個複雜系統都從簡單開始。一台伺服器同時跑 Web 應用、資料庫和快取。用戶透過域名存取，DNS 將域名解析為 IP 位址，接著用戶端發送 HTTP 請求，伺服器回傳 HTML 頁面或 JSON 資料。Web 用戶走 HTML/CSS/JS，行動端用戶則透過 API 取得 JSON 回應。這個架構適合小型用戶群，但流量一大就會出問題。

[04:30] 資料庫選型：SQL vs NoSQL

當用戶增長後，需要將 Web 層與資料層分離，各自獨立擴展。資料庫有兩大類：

關聯式資料庫（SQL）：PostgreSQL、MySQL 等。資料以表格和列的方式儲存，支援複雜的 JOIN 操作。最大優勢是 ACID 交易特性 — 原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability），適合銀行、電商等需要資料完整性的場景。

非關聯式資料庫（NoSQL） 有四種類型：文件儲存（MongoDB）、寬列儲存（Cassandra）、圖形資料庫（Neo4j）、鍵值儲存（Redis）。NoSQL 可以把用戶、訂單、產品放在同一個文件中，省去 JOIN 操作，適合低延遲、大量非結構化資料的場景。

選擇原則：資料結構明確且需要強一致性 → SQL；需要超低延遲或資料是非結構化的 → NoSQL。

[12:00] 垂直擴展 vs 水平擴展

垂直擴展（Scale Up）：幫現有伺服器加 RAM、CPU。簡單但有硬體上限，且只有一台伺服器時沒有備援 — 伺服器掛了整個應用就掛了。

水平擴展（Scale Out）：增加更多伺服器分擔負載。容錯性更高（一台掛了還有其他），可擴展性更好（隨時加新伺服器）。但問題來了：多台伺服器怎麼分配流量？這就需要負載均衡器。

[15:00] 負載均衡器與七種演算法

負載均衡器坐在用戶端和伺服器群之間，負責分配流量。七種常見演算法：

1. Round Robin：依序輪流分配，適合規格相同的伺服器
2. Least Connections：導向連線數最少的伺服器，適合 Session 長度不一的場景
3. Least Response Time：選回應最快且連線最少的伺服器
4. IP Hash：根據用戶 IP 的雜湊值固定導向同一台伺服器，適合需要 Session 黏著的場景
5. Weighted 加權變體：根據伺服器效能分配權重
6. Geographical 地理位置：導向距離用戶最近的伺服器，降低延遲
7. Consistent Hashing：用雜湊環分配，同時確保用戶一致性和伺服器增減時最小化重新分配

負載均衡器還內建健康檢查功能，持續監控伺服器狀態，自動跳過故障節點。實作上可用軟體（Nginx、HAProxy）、硬體（F5）或雲端服務（AWS ELB、Azure Load Balancer）。

[25:00] 單點故障與解決方案

單點故障（Single Point of Failure）是系統中任何一個元件故障就能導致整體癱瘓的點。例如只有一個資料庫或一個負載均衡器，一旦掛掉全部停擺。解決策略：增加冗餘（多個負載均衡器）、健康檢查監控、自我修復系統（偵測故障後自動替換新實例）。

[29:00] API 設計基礎：REST、GraphQL、gRPC

API（Application Programming Interface）是軟體元件間的溝通契約，定義可發送什麼請求、期望什麼回應。

REST API：最常見，使用 HTTP 方法（GET/POST/PUT/DELETE），無狀態，每個請求獨立包含所有資訊。適合 Web 和行動應用。

GraphQL：Facebook 開發，單一端點處理所有操作。客戶端精確指定需要的資料結構，避免多次來回請求和過度擷取（over-fetching）。適合複雜 UI。

gRPC：Google 開發的高效能 RPC 框架，使用 Protocol Buffers 和 HTTP/2。支援串流和雙向通訊，最適合微服務間的內部通訊。

[36:00] API 四大設計原則

1. 一致性：命名風格統一（camelCase 或 snake_case 擇一貫徹）
2. 簡潔性：最好的 API 是不用看文件就能使用的 API
3. 安全性：身分驗證、授權、輸入驗證、Rate Limiting
4. 效能：快取策略、分頁（Pagination）、最小化 Payload、減少來回次數

[40:00] API 協定：HTTP、WebSocket、AMQP、gRPC

HTTP/HTTPS：Web API 的基礎，請求-回應模式。HTTPS 加上 TLS/SSL 加密保護傳輸中的資料。

WebSocket：解決 HTTP 輪詢的效率問題。建立連線後伺服器可主動推送資料，實現即時通訊（聊天室、即時串流）。

AMQP（Advanced Message Queuing Protocol）：用於非同步通訊。生產者發送訊息到佇列（Queue），消費者依自身能力拉取處理，實現解耦和流量緩衝。

gRPC：基於 HTTP/2 的高效能協定，適合伺服器之間的通訊，瀏覽器支援有限。

[48:00] 傳輸層協定：TCP vs UDP

TCP（Transmission Control Protocol）：可靠傳輸，三次握手建立連線，保證封包送達且有序。適合支付、認證、用戶資料等不能丟失的場景。

UDP（User Datagram Protocol）：快速但不保證送達、不保證順序。適合視訊通話、線上遊戲、直播 — 丟幾個封包沒關係，重要的是即時性。

[53:00] RESTful API 最佳實踐

資源建模用名詞複數（/products 而非 /getProducts），支援巢狀資源（/products/123/reviews）。查詢參數實現篩選（?category=electronics&in_stock=true）、排序（?sort=price_asc）和分頁（?page=2&limit=10）。HTTP 方法對應 CRUD：GET 讀取、POST 建立、PUT/PATCH 更新、DELETE 刪除。狀態碼要正確：200 成功、201 已建立、404 找不到、500 伺服器錯誤。API 要有版本控制（/api/v1/）。

[62:00] GraphQL 深入解析

GraphQL 的 Schema 是客戶端與伺服器的契約，定義 Type（資料型別）、Query（查詢）和 Mutation（變更）。客戶端在單一請求中精確指定所需欄位，伺服器只回傳被要求的資料。錯誤處理與 REST 不同 — GraphQL 永遠回傳 200 狀態碼，錯誤資訊放在回應的 errors 欄位中。最佳實踐：Schema 保持小而模組化、避免過深巢狀查詢、使用有意義的命名。

[68:00] 身分驗證：從 Basic Auth 到 OAuth2

Basic Auth：Base64 編碼的帳號密碼，容易反解，幾乎不再使用。 Bearer Token：每次請求帶 Token 而非帳密，無狀態且易於擴展。 OAuth2 + JWT：透過 Google、GitHub 等信任提供者登入，JWT Token 攜帶用戶資訊（ID、角色、過期時間），同樣無狀態。 Access + Refresh Token：Access Token 短命用於 API 呼叫，Refresh Token 長命用於更新 Access Token，兼顧安全與使用體驗。 SSO（Single Sign-On）：一次登入存取多個服務（如 Google 帳號同時用於 Gmail、Drive、Calendar），底層用 OAuth2 或 SAML 協定。

[76:00] 授權模型：RBAC、ABAC、ACL

RBAC（Role-Based Access Control）：依角色分配權限，最常見。例如 Admin 有完整權限、Editor 可編輯但不能刪除、Viewer 只能讀取。GitHub 的 Repository 權限就是典型案例。

ABAC（Attribute-Based Access Control）：根據用戶屬性（部門、年齡）、資源屬性（機密等級）和環境條件（時間、地點）決定存取權，比 RBAC 更彈性但也更複雜。

ACL（Access Control List）：每個資源有獨立的權限清單。Google Drive 的文件分享就是 ACL 的典型應用 — 對 Alice 設唯讀、對 Bob 設可編輯。控制精細但難以大規模管理。

OAuth2 和 JWT 是實作授權的技術手段：OAuth2 提供委託授權（如讓 Vercel 存取你的 GitHub Repo），JWT Token 攜帶用戶身分和權限聲明。

[84:00] API 安全七大防護技巧

1. Rate Limiting：限制單位時間內的請求數，防止暴力破解和 DDoS，可依端點、用戶 IP 或全局設定
2. CORS（Cross-Origin Resource Sharing）：控制哪些網域可以從瀏覽器呼叫你的 API
3. SQL/NoSQL Injection 防護：永遠使用參數化查詢，不要直接把用戶輸入拼進 SQL
4. Firewall（防火牆）：過濾惡意流量，如 AWS WAF 可攔截可疑的請求模式
5. VPN：內部 API 只允許同一 VPN 網路內的存取
6. CSRF Token：防止跨站請求偽造，在 Session Cookie 之外多加一層驗證
7. XSS 防護：防止攻擊者在評論等輸入欄位注入惡意 JavaScript 腳本

我的想法

這部影片本質上是一堂「系統設計速成課」，涵蓋面非常廣 — 從最基礎的 DNS 解析到 API 安全防護，幾乎把面試會問的核心概念都過了一遍。對於準備系統設計面試或想建立完整知識框架的開發者來說，是很好的入門地圖。

值得注意的是，影片在資料庫選型的討論中，雖然點出了 SQL vs NoSQL 的基本取捨，但實務中的選擇往往更複雜。例如 PostgreSQL 加上 JSONB 欄位其實也能處理半結構化資料，而 MongoDB 近年也加強了交易支援。真正的決策不是二選一，而是看你的讀寫比例、一致性需求和團隊熟悉度。

負載均衡的七種演算法講解得很清楚，但實務上大多數團隊直接用雲端服務（AWS ALB/NLB）就夠了，不需要自己設定 Nginx 的負載均衡。更關鍵的是理解什麼時候需要 Layer 4（TCP 層）vs Layer 7（HTTP 層）的負載均衡。

API 設計部分的 REST vs GraphQL vs gRPC 比較很實用。補充一點：近年 tRPC 在 TypeScript 全端開發中也越來越流行，它提供端對端型別安全，開發體驗介於 REST 和 gRPC 之間，值得關注。