🎯 什麼情境該想到我
當你在設計「使用者請求如何一路被導到正確、健康的服務節點」，或思考 CDN／負載均衡／網關該怎麼擺時。
⚙️ 怎麼用（一層層把流量導到對的地方，越前面擋掉越多越好）
- DNS：把網域解析到最近/可用的入口。
- CDN：靜態內容就近快取，別讓請求都打到源站。
- 負載均衡：把流量分散到多個健康節點（四層/七層）。
- API 網關：統一入口，做認證、限流、路由、聚合。
- 服務發現：讓呼叫端動態找到可用的服務實例（配合健康檢查）。
原則：能在越外層解決/擋掉的流量，就別讓它進到越內層，層層減壓。
★ 完整的分流鏈（越前面擋掉越便宜）
瀏覽器快取 ← ★ 最便宜：連請求都不發出
↓
DNS / GSLB ← 地理就近、機房級故障轉移
↓
CDN / 邊緣快取 ← ★ 靜態資源與可快取的 API 不進源站
↓
WAF / DDoS 防護 ← 惡意流量在這裡被擋
↓
L4 負載均衡 ← 四層：只看 IP:Port，極快
↓
L7 負載均衡／API 閘道 ← ★ 認證、限流、路由、聚合
↓
服務（+ 服務發現、服務網格）
↓
應用快取（Redis）
↓
資料庫（+ 讀取副本、連線池）
★ 核心原則：「每往內一層，成本大約高一個數量級。」
一個能在 CDN 命中的請求，成本大約是打到資料庫的千分之一。
所以架構優化的第一個問題永遠是：「這個請求能不能在更外層就被解決？」
★ L4 vs L7 負載均衡
| L4（傳輸層） | L7（應用層） | |
|---|---|---|
| 看得到什麼 | IP、Port、TCP 連線 | ★ HTTP 方法、路徑、header、cookie |
| 能做什麼 | 依連線分流 | ★ 依路徑路由、依使用者黏著、重寫、壓縮、TLS 終止 |
| 效能 | ★ 極高（可以只改封包不拆解） | 較低（要解析 HTTP） |
| 健康檢查 | TCP 連得上就算活 | ★ 能打 /healthz 看真實狀態 |
| 例子 | LVS、AWS NLB | Nginx、Envoy、AWS ALB |
★ 實務上常兩層都有：L4 做第一層分散與 DDoS 吸收，L7 做智慧路由。
★ API 閘道：該放什麼、不該放什麼
| ✅ 該放（橫切關注點） | ❌ 不該放 |
|---|---|
| 認證與 token 驗證 | ★ 業務邏輯 |
| 限流與配額（見 工具-限流器設計） | ★ 資料轉換與聚合的複雜邏輯 |
| 路由與版本 | 需要頻繁改動的東西 |
| 請求/回應日誌與 trace 注入 | 任何「屬於某個團隊」的規則 |
| TLS 終止、壓縮、CORS |
★★ API 閘道最大的風險：它會變成新的單體。
每個團隊都想在閘道加一點邏輯 → 它變成所有人都要改、誰都不敢動的中心元件，
而且它掛了全站都掛。
→ 閘道只放「所有服務都一樣」的東西；只要有「某個服務特別」的邏輯，就該放回服務裡。
★ 快取的層次與失效難度
| 層 | 命中的價值 | ★ 失效的難度 |
|---|---|---|
| 瀏覽器 | 最高（零請求） | ★ 最難（你無法主動清除別人的瀏覽器） |
| CDN | 很高 | 中（可以 purge，但有延遲） |
| 閘道/反向代理 | 高 | 中 |
| 應用內（Redis） | 中 | ★ 最容易（你完全控制） |
★ 這張表解釋了一個重要的取捨：
越外層越省，但也越難改。
→ 內容會變的東西用短 TTL 或放內層；不會變的（帶 hash 的靜態資源）才用長 TTL 放最外層。
→ 靜態資源用 content hash 檔名（app.a3f1c2.js）+ 永久快取，是這個取捨的標準解法。
★ 服務發現
| 方式 | 例子 |
|---|---|
| DNS | ★ 簡單，但有快取與 TTL 問題 |
| 註冊中心 | Consul、etcd、Eureka |
| ★ 平台內建 | Kubernetes Service（多數情況的正解） |
| 服務網格 | Istio / Linkerd —— ★ 把重試、逾時、mTLS、追蹤下沉到 sidecar |
★ 服務網格的取捨：它把容錯邏輯從應用抽出來（好），但多一層代理的延遲、更多的運維複雜度、更難除錯（壞）。
服務數量少於一二十個時，通常不值得。
🧪 我實際套用的紀錄
- 2026-07-15：（待填）
⚠️ 注意 / 什麼時候不適用
- ★★ 每一層都是一個可能的單點。加一層 = 多一個會掛的東西、多一跳延遲、多一個要監控的對象。
不要為了「架構完整」而把每一層都加上。 - ★ 快取失效是最難的部分。加快取容易，「什麼時候該讓它失效」才是問題。
沒想清楚就加 → 「資料明明改了但使用者看到舊的」（見 工具-快取與資源優化）。 - ★ 閘道不要變成單體（見上）。
- DNS 的 TTL 不可靠。很多解析器會忽略你設的 TTL → 不要依賴 DNS 做快速故障轉移。
- TLS 終止的位置決定了內網是否加密。合規要求端到端加密時，不能只在邊緣終止。
- 健康檢查要檢查「真的能做事」，不是只回 200（見 工具-故障偵測）。
- 小系統不需要這麼多層。一個 Nginx + 應用 + 資料庫能撐很久。先量再加。
🔗 相關工具
- 工具-快取與資源優化 —— 快取策略與失效
- 工具-限流器設計 —— 閘道層的保護
- 工具-服務容錯設計 —— 每一層都該有的容錯
- 工具-故障偵測 —— 健康檢查的設計
- 工具-網站高可用與伸縮性設計 —— 更上層的可用性設計
- 工具-前端效能優化規則 —— 瀏覽器那一端
- 工具-網站架構模式九式 —— 架構手法的完整目錄
- 鳳凰架構