鳳凰架構 The Fenix Project（構建可靠的大型分散式系統）

📌 30 秒摘要（Layer 3）

目標是「像鳳凰一樣，由不可靠的零件組成能自我修復的可靠系統」。全書沿著服務架構的演進（單體→SOA→微服務→雲原生）鋪陳，系統性講解要駕馭大型分散式系統必備的幾件事：透明多級分流（把流量一層層導到對的地方）、分散式事務（在無法用單機交易時如何保證一致）、服務容錯（讓局部故障不擴散）、以及雲原生（容器、K8s、服務網格）。與 設計資料密集型應用 互補——DDIA 談資料層，本書談服務/架構層。

🗺 心智圖（Canvas）

鳳凰架構

鳳凰架構

周志明｜用不可靠的部件構造可靠的系統

🏗 架構演進 單體 → SOA → 微服務 → 雲原生

工具-服務架構的演進與拆分

🎯 什麼情境該想到我

當你在猶豫「要不要從單體走向微服務、怎麼拆」，或被「微服務很潮」帶風向時。

⚙️ 怎麼用

1. 認清各階段的取捨：單體（簡單、部署一體）→ SOA → 微服務（獨立部署/擴展，但引入分散式複雜度）→ 無伺服器。微服務不是免費的——你用開發簡單度換來運維與分散式的複雜度。
2. 先具備前置條件再拆：自動化部署、監控、服務治理都到位，才適合微服務。
3. 按業務邊界拆，而非技術分層——切點對齊 工具-限界上下文。
4. 能單體就先單體（modular monolith），真的遇到擴展/團隊瓶頸再拆。

📌 這一組有三張卡，分工如下：
本卡＝「有哪些選項、各自的代價」｜工具-架構隨業務規模演進＝「什麼時候該演進」｜工具-服務邊界與演進式拆分＝「切在哪、怎麼切」

★ 四種架構的代價表

	單體	模組化單體	微服務	無伺服器
部署	一次全部	一次全部	★ 獨立	獨立
本地開發	★ 跑一個就好	★ 跑一個就好	⚠️ 要跑一堆或用 mock	難
跨模組重構	★ 一次 commit，編譯器幫你檢查	★ 同左	⚠️ 跨服務的改動要協調部署順序	同微服務
除錯	★ 一份堆疊追蹤	★ 同左	⚠️ 需要分散式追蹤	更難
交易	★ 本地 ACID	★ 同左	⚠️ 分散式事務（見 工具-分散式事務的取捨）	同微服務
獨立擴展	❌	❌	★ 可以	★ 自動
團隊自主	❌	⚠️ 有限	★ 高	高
技術異質	❌	❌	★ 可以（但通常不該）	可以
運維複雜度	★ 低	★ 低	⚠️ 高	中（換成廠商鎖定）

★ 最容易被忽略的是第 3、4、5 列：
微服務讓「跨邊界的改動」從「一次 commit」變成「多個 repo、多次部署、要考慮順序與相容性」。
這個成本天天都要付，而「獨立擴展」的好處多數團隊一年用不到幾次。

★ 微服務的前置條件（沒有這些就是自找麻煩）

□ ★ 自動化部署（每個服務都能一鍵、安全地上線與回滾）
□ ★ 集中式日誌 + 分散式追蹤（不然事故時完全瞎）
□ 監控與告警（每個服務都有）
□ ★ 服務發現與設定管理
□ 契約測試或 schema 相容性檢查（見 [[工具-資料編碼與演進]]）
□ ★ 團隊真的能獨立負責一個服務（見 [[工具-康威定律]]）

★ 沒有這六項就拆微服務 = 把「一個難維護的系統」變成「N 個難維護的系統 + 一個難懂的網路」。
→ 這正是「分散式單體」的定義：拆開了，但還是要一起部署。

★ 模組化單體：最被低估的選項

internal/
  sales/      ← 邊界清楚，只透過公開介面往來
  warehouse/
  billing/
cmd/server/   ← 一個二進位檔

你拿到了	你避開了
★ 模型與團隊的邊界清晰	❌ 網路呼叫的延遲與失敗
★ 編譯期就能驗證邊界（架構測試）	❌ 分散式事務
★ 本地交易、本地重構	❌ 部署協調
★ 需要時可以再拆出去	❌ 運維成本

★ 「先模組化單體，被驗證穩定的邊界才拆出去」是截至 2026-10 業界最主流的建議（判斷，非統計），
而且它讓你用低成本試錯邊界——切錯了只要改個資料夾，不是改一個 repo。

★ 什麼時候真的該拆

拆的正當理由	不是理由
★ 團隊互相擋住彼此的部署	「微服務比較現代」
★ 某個部分的資源需求差異極大（ML 推論要 GPU、影片轉檔要 CPU）	「想試試 Kubernetes」
★ 不同的可用性/合規要求（金流要更嚴的稽核）	「檔案太大了」
不同的發布節奏（一個一天十次、一個一季一次）	「聽說單體不好」
需要用不同語言（真的有技術理由）	「想用 Rust」

★ 注意共同點：前四個都是「組織或營運的理由」，不是技術的理由。

★ 無伺服器的真實取捨

✅	❌
零運維、自動擴縮、按用量計費	★ 冷啟動（延遲敏感的服務不適合）
事件驅動天然契合	★ 執行時間上限
突發流量友善	★ 廠商鎖定、本地測試困難
★ 低流量時極省錢	★ 高且穩定的流量時反而比 VM 貴

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

• ★★ 不要一開始就微服務。你還不知道邊界在哪，而錯的邊界比單體更難改（跨服務重構極貴）。
• ★ 微服務不會讓程式碼變乾淨。爛的設計拆成十個服務只會變成十份爛設計 + 網路問題。
  先把模組邊界理清楚（那在單體裡就能做）。
• ★ 「分散式單體」是最糟的結果：拆開了，但每次發布都要按順序一起部署。
  判準：能不能只部署其中一個服務？不能 → 你只是把方法呼叫換成了 HTTP。
• 技術異質是雙面刃。五種語言 = 五套工具鏈、五種監控接法、人員無法流動。
  ★ 多數團隊應該「刻意限制」技術選擇（見 技術選型收斂）。
• ★ 拆分是難以逆轉的。合併回去比拆開更痛。所以要在「有足夠證據」時才拆。
• 團隊規模是硬限制。少於 15–20 人基本不該考慮微服務——你沒有足夠的人來維運。

🔗 相關工具

• 工具-架構隨業務規模演進 —— ★ 什麼時候該演進（觸發訊號）
• 工具-服務邊界與演進式拆分 —— ★ 切在哪、怎麼切（絞殺者模式）
• 工具-限界上下文 —— 邏輯邊界（拆分的依據）
• 工具-康威定律 —— 組織結構決定可行的架構
• 工具-分散式事務的取捨 —— 拆分後最大的技術代價
• 技術選型收斂 —— 為什麼不該濫用技術異質
• 工具-部署管線與持續交付 —— 前置條件
• 微服務設計

各有適用場景， 微服務不是免費的—— 拆分帶來的分散式成本要先算清楚

🌊 透明多級分流 流量怎麼進入系統

工具-透明多級分流

🎯 什麼情境該想到我

當你在設計「使用者請求如何一路被導到正確、健康的服務節點」，或思考 CDN／負載均衡／網關該怎麼擺時。

⚙️ 怎麼用（一層層把流量導到對的地方，越前面擋掉越多越好）

1. DNS：把網域解析到最近/可用的入口。
2. CDN：靜態內容就近快取，別讓請求都打到源站。
3. 負載均衡：把流量分散到多個健康節點（四層/七層）。
4. API 網關：統一入口，做認證、限流、路由、聚合。
5. 服務發現：讓呼叫端動態找到可用的服務實例（配合健康檢查）。

原則：能在越外層解決/擋掉的流量，就別讓它進到越內層，層層減壓。

★ 完整的分流鏈（越前面擋掉越便宜）

瀏覽器快取      ← ★ 最便宜：連請求都不發出
  ↓
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 + 應用 + 資料庫能撐很久。先量再加。

🔗 相關工具

• 工具-快取與資源優化 —— 快取策略與失效
• 工具-限流器設計 —— 閘道層的保護
• 工具-服務容錯設計 —— 每一層都該有的容錯
• 工具-故障偵測 —— 健康檢查的設計
• 工具-網站高可用與伸縮性設計 —— 更上層的可用性設計
• 工具-前端效能優化規則 —— 瀏覽器那一端
• 工具-網站架構模式九式 —— 架構手法的完整目錄
• 鳳凰架構

DNS → CDN → 負載均衡 → 網關 → 服務發現 一層層把請求導到對的節點

🔄 分散式事務 跨服務怎麼保證一致

工具-分散式事務的取捨

🎯 什麼情境該想到我

當一個業務動作要跨多個服務/資料庫、卻無法用單機交易保證「要嘛全成、要嘛全敗」時。

⚙️ 怎麼用（依一致性需求選方案，沒有銀彈）

1. 可靠訊息佇列（本地訊息表 = Outbox）：把業務寫入與事件記錄放同一本地交易，再由 relay 投遞 → 最終一致。最常用、最務實（見 工具-Transactional-Outbox-Pattern）。
2. TCC（Try-Confirm-Cancel）：業務層自己實作預留/確認/取消，強一致但侵入性高、開發成本大。
3. Saga：把長交易拆成一連串本地交易 + 對應的補償動作，失敗就反向補償。適合長流程。
4. 2PC/XA：強一致但同步阻塞、協調者單點，效能差，少用於高併發。

先問：這個場景需要強一致，還是最終一致就好？多數選最終一致（1）。

★ 先問三個問題（多數情況根本不需要分散式事務）

① ★ 這兩件事真的必須在「不同的服務／資料庫」嗎？
   → 常常是切錯了邊界。同一個聚合內的東西不該跨服務（見 [[工具-限界上下文]]）

② ★ 真的需要「強一致」，還是「最終一致 + 使用者看得到狀態」就好？
   → 「下單後 3 秒庫存才扣」在業務上幾乎總是可以接受的

③ ★ 失敗時可以「人工處理」嗎？
   → 每天 3 筆異常 → 對帳報表 + 人工補償，★ 遠比建一套 Saga 框架划算

★ 最好的分散式事務是「不要有分散式事務」。
大多數「需要分散式事務」的需求，實際上是服務邊界切錯了的症狀。

★ 四種方案的完整對照

方案	一致性	複雜度	可用性	★ 什麼時候用
★ Outbox（本地訊息表）	最終	低	高	★ 預設選這個。90% 的場景
Saga	最終	中	高	長流程、多步驟、有明確的補償動作
TCC	準強	高	中	需要「預留資源」的場景（訂票、扣庫存）
2PC / XA	強	中	★ 低	幾乎不要用（見下）

★ Outbox：為什麼它是預設答案

❌ 雙寫問題（dual write）
BEGIN; UPDATE orders ...; COMMIT;
kafka.Publish(event)          ← ★ 這裡掛掉 → 訂單建了但沒人知道

✅ Outbox
BEGIN;
  INSERT INTO orders ...;
  INSERT INTO outbox (event) VALUES (...);   ← ★ 同一個本地交易，要嘛都成功要嘛都失敗
COMMIT;
-- 背景 relay（或 CDC 讀 WAL）把 outbox 推到訊息佇列

★ 它的天才之處：把「跨系統的原子性」化約成「單一資料庫的本地交易」，
而單一資料庫的交易是可靠的（見 工具-交易與隔離等級）。

代價：至少一次投遞 → ★ 消費端必須冪等（見 工具-MQ消費端防禦三原則）。

★ Saga：補償的設計才是難點

正向：  建訂單 → 扣款 → 扣庫存 → 出貨
補償：  取消訂單 ← 退款 ← 回補庫存 ← （已出貨無法補償）

三件必須想清楚的事：

問題	說明
★ 補償不等於回滾	退款 ≠ 沒扣過款（帳上留下兩筆紀錄、可能有手續費）。 Saga 沒有「原子性」，只有「最終達到某個可接受的狀態」
★ 有些步驟不可補償	已出貨、已寄出的 email、已呼叫的第三方 API。 → ★ 把不可逆的步驟排在最後，或改成「可逆的形式」（延遲執行、草稿）
★ 補償本身也會失敗	退款 API 也可能掛。→ 補償必須可重試 + 冪等 + 最終有人工介入的出口（dead letter）

編排（orchestration）vs 協同（choreography）：

	Orchestration	Choreography
流程在哪	★ 一個中央協調者（看得到整條流程）	散在各服務的事件監聽裡
好處	★ 流程可讀、可追蹤、易改	鬆耦合，沒有中心
壞處	協調者是新的耦合點	★ 沒有人知道完整流程長什麼樣
建議	★ 步驟 ≥ 3 就用編排	只有兩步時可以協同

★ 為什麼 2PC 幾乎不該用

協調者 → 「準備好了嗎？」→ 所有參與者鎖住資源並回「好了」
       ★ 此時協調者掛掉 → 所有參與者「永遠持鎖等待」（in-doubt）
       → 資源被鎖住，無法自行決定，必須等協調者回來

問題	說明
★ 協調者單點	它掛了，參與者全部卡住
★ 同步阻塞	整個 prepare→commit 期間所有參與者持鎖
可用性差	任一參與者不可用，整個交易失敗（可用性是各方的乘積）
效能差	至少兩輪網路往返 + 持鎖時間長

★ 它在單一資料庫叢集內（同一個 DBMS 的多個分片）還算堪用；跨異質系統基本上是災難。

★ 產品端要配合的事（技術解不了的部分）

最終一致性必須在產品層面被承認，不能偷偷做：

• ★ 顯示中間狀態：「訂單處理中」而不是假裝已完成
• ★ 提供查詢入口：使用者能看到目前進度
• 定義補償後的使用者體驗：退款要通知、要說明原因
• ★ 對帳機制：定期比對兩邊，找出不一致並告警——
  這是最被忽略但最重要的一環。沒有對帳，你永遠不知道系統有沒有出錯。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

• ★★ 先檢討服務邊界。頻繁需要跨服務事務 = 邊界切錯了（見 工具-服務邊界與演進式拆分）。
  合併回同一個服務往往是正確答案，而不是蓋一套 Saga 框架。
• ★ 一定要有對帳。任何最終一致的系統都會飄移，只是你知不知道。 排定期對帳 + 告警 + 人工修補流程。
• ★ 消費端冪等不是可選的。所有方案都是「至少一次」投遞。
• 不可逆的步驟要排在最後，或延遲執行（見 可逆性、審計與人類把關 的 L3 降級技巧）。
• Saga 的狀態要持久化。流程執行到一半服務重啟 → 要能從中斷處續跑（見 狀態模式）。
• 不要用「分散式鎖」代替分散式事務。鎖不安全（見 工具-線性一致性與共識 的 fencing token）。
• ★ 測試很難。要測「第 3 步失敗時補償有沒有正確執行」——故障注入是必要的（見 工具-注入故障與韌性演練）。
• 監控要能看到「卡住的 Saga」：超過 N 分鐘還沒完成的流程要告警。

🔗 相關工具

• 工具-Transactional-Outbox-Pattern —— ★ 預設方案的完整做法
• 工具-交易與隔離等級 —— 單機交易是 Outbox 的基礎
• 工具-MQ消費端防禦三原則 —— 冪等與重試
• 工具-服務邊界與演進式拆分 —— ★ 先檢討邊界
• 工具-線性一致性與共識 —— 為什麼分散式鎖不安全
• 工具-預寫日誌與崩潰復原 —— CDC 作為 Outbox 的替代
• 狀態模式 —— Saga 的狀態持久化
• 工具-注入故障與韌性演練 —— 補償路徑要被測試

2PC／3PC × TCC × Saga 可靠訊息佇列（本地訊息表＝Outbox） 沒有銀彈，按一致性需求選 （見 [[工具-Transactional-Outbox-Pattern]]）

🛡 服務容錯 讓局部故障不擴散

工具-服務容錯設計

🎯 什麼情境該想到我

當一個下游服務變慢/掛掉，就把整條鏈路甚至整個系統拖垮（雪崩）時。

⚙️ 怎麼用（組合使用）

1. 熔斷（Circuit Breaker）：偵測到下游持續失敗就「跳閘」，快速失敗、暫停呼叫，給它時間恢復，避免堆積。
2. 艙壁隔離（Bulkhead）：把資源（執行緒池/連線）按依賴分艙，一個依賴爆掉不會吃光全部資源。
3. 重試 + 退避：對暫時性失敗重試，但要指數退避 + 上限 + 冪等，避免重試風暴（見 工具-MQ消費端防禦三原則）。
4. 降級（Fallback）：失敗時回傳合理的預設/快取結果，保住核心體驗。
5. 流量控制（限流）：超過容量就擋，保護系統不被打垮。

★ 為什麼需要它：連鎖故障的機制

下游變慢（不是掛，只是慢）
  → 你的請求堆積，執行緒/連線被佔住
  → ★ 你自己的資源耗盡 → 你也開始變慢
  → 上游的請求在你這裡堆積 → 上游也垮
  → ★ 整條鏈一起倒

★ 最危險的不是「下游掛了」，是「下游變慢」。
掛了會快速失敗（連線被拒），資源立刻釋放；慢會持續佔住資源直到耗盡。
所以逾時是第一道防線，比斷路器更基本。

★ 五種手段的正確順序（由外而內）

限流 Rate Limit        ← ★ 最外層：擋掉超過容量的流量，保護自己
  艙壁 Bulkhead        ← 隔離資源，一個依賴爆掉不影響其他
    斷路器 Circuit Breaker  ← 下游持續失敗就快速失敗
      逾時 Timeout      ← ★ 必須在重試外層，否則重試會超出總時限
        重試 Retry      ← 只對暫時性錯誤
          實際呼叫

★ 順序錯了會失效：Retry 包在 Timeout 外面 → 總時間變成 n × timeout，SLO 直接破
（見 裝飾者模式 的 middleware 順序）。

★ 斷路器的三個狀態與參數

      失敗率超過閾值
CLOSED ──────────────▶ OPEN ──等待 cooldown──▶ HALF-OPEN
  ▲                     │                        │
  │   ★ 試探成功         │  ★ 直接快速失敗         │ 放少量請求試探
  └─────────────────────┴────────────────────────┘
                              試探失敗 → 回 OPEN

★ 它本質上是一個狀態機（見 狀態模式）。

參數	怎麼定
失敗率閾值	常見 50%。★ 要用「比例」不是「絕對次數」，否則低流量時永遠觸發不了
最小請求數	★ 必要：10 次請求裡錯 5 次不該跳閘（樣本太小）
cooldown	幾秒到幾十秒。太短 → 反覆試探打死下游；太長 → 恢復太慢
half-open 的試探量	1～數個。不要一次全放行（會瞬間打垮剛恢復的下游）

★ 「什麼算失敗」要想清楚：逾時、5xx 算；4xx（參數錯）不算（那是你的問題，重試也沒用）。

★ 重試的三條鐵律

鐵律	說明
① 只重試暫時性錯誤	429、503、逾時、連線失敗 可以；400、401、404、422 絕對不要
② ★ 必須冪等	非冪等的操作重試 = 重複下單、重複扣款。★ 帶冪等鍵（見 工具-MQ消費端防禦三原則）
③ ★ 指數退避 + jitter	沒有 jitter，所有客戶端會同步醒來再打一次，製造週期性尖峰

// ★ full jitter：業界標準做法
delay := time.Duration(rand.Int63n(int64(min(base<<attempt, maxDelay))))

★★ 重試放大是連鎖故障最常見的加速器：

三層服務，每層重試 3 次 → 最底層收到 3³ = 27 倍的流量
★ 下游已經在掙扎了，你送 27 倍過去 = 徹底打死

對策：

• ★ 只在最靠近失敗點的那一層重試，其他層直接往上回報
• 重試預算（retry budget）：全域限制「重試佔總請求的比例」（如 10%）
• 尊重 Retry-After header

★ 降級要事先設計，不能臨時想

降級層次	例子
回傳快取的舊資料	★ 最常用。要標示「資料更新於 X」
回傳預設值 / 空結果	推薦系統掛了 → 回熱門商品
關閉非核心功能	購物車能結帳，但「你可能也喜歡」消失
★ 排隊 / 非同步化	同步做不到 → 收下請求、回 202、之後處理
拒絕	★ 明確的錯誤 + Retry-After，遠勝於超時等待

★ 降級開關要能手動觸發（feature flag），不要只靠自動偵測——
事故當下你需要能立刻關掉某個功能，而不是等斷路器自己判斷。

★ 艙壁隔離

❌ 共用一個執行緒池/連線池
   → 呼叫 A 服務的請求全部卡住 → 池子耗盡 → ★ 呼叫 B 服務的也沒資源了

✅ 每個下游依賴各自一個池（或 semaphore 限制併發數）
   → A 爆掉只影響 A 那一艙

★ Go 裡最簡單的實作就是每個依賴一個 semaphore（golang.org/x/sync/semaphore 或帶緩衝的 channel）。

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意 / 什麼時候不適用

• ★★ 逾時是第一優先，不是斷路器。 沒有逾時，其他手段全部失效——因為資源永遠不會被釋放。
  而且逾時要端到端傳遞（context），不是每層各設一個（見 工具-select超時與競速）。
• ★ 重試放大是連鎖故障的加速器（見上）。只在一層重試。
• ★ 斷路器在「低流量」時不可靠。一小時只有 20 次請求時，失敗率的統計意義很弱。
  → 設最小請求數，或對低流量服務不用斷路器。
• ★ 降級的品質要能被察覺。默默回傳空結果 → 使用者以為「真的沒有資料」。
  要有 metric 追蹤降級觸發率，而且降級中的回應要能被識別（header 或欄位標示）。
• 這些機制本身會製造 bug。斷路器誤跳、重試造成重複、降級邏輯有 bug——
  ★ 每一個容錯機制都要被測試（故障注入，見 工具-注入故障與韌性演練）。
• 不要對所有依賴都套用全套。核心依賴掛了就是該失敗；只有「可以沒有」的依賴才值得降級。
  → 先分清楚關鍵路徑與非關鍵路徑。
• 用成熟的函式庫（sony/gobreaker、failsafe-go、Envoy/Istio 的 outlier detection），不要自己寫。

🔗 相關工具

• 工具-select超時與競速 —— ★ 逾時必須沿 context 端到端傳遞
• 工具-故障偵測 —— 「掛了還是只是慢」與健康檢查
• 工具-MQ消費端防禦三原則 —— 冪等與重試
• 工具-注入故障與韌性演練 —— 這些機制要被測試
• 裝飾者模式 —— middleware 的順序原則
• 狀態模式 —— 斷路器是經典狀態機
• 工具-生產故障反模式清單 —— 連鎖故障的真實案例
• 工具-限流器設計 —— 最外層的保護

熔斷 × 艙壁隔離 × 重試 降級 × 流量控制 目的：防止故障擴散成雪崩

☁️ 雲原生 把關注點下沉到基礎設施

容器 × Kubernetes × 服務網格（Service Mesh） 把分散式關注點從應用碼 下沉到基礎設施 （本書一大主題，尚無獨立工具卡）

Link to original

🧰 這本書給我的工具

• 工具-服務架構的演進與拆分 — 決定要不要/如何走向微服務時
• 工具-分散式事務的取捨 — 跨服務要保證一致性時
• 工具-服務容錯設計 — 想讓局部故障不拖垮整個系統時
• 工具-透明多級分流 — 設計流量如何進入與分散到系統時

✨ 關鍵重點（Layer 1–2）

• 架構演進：單體、SOA、微服務、無伺服器各有適用場景；微服務不是免費的。
• 透明多級分流：DNS → CDN → 負載均衡 → 網關 → 服務發現，一層層把請求導到對的節點。
• 分散式事務：2PC/3PC、TCC、Saga、可靠訊息佇列（本地訊息表 = Outbox）——沒有銀彈，按一致性需求選。
• 服務容錯：熔斷、艙壁隔離、重試、降級、流量控制——防止故障擴散（雪崩）。
• 雲原生：容器、Kubernetes、服務網格（Service Mesh）把分散式關注點下沉到基礎設施。

💬 金句原文（Layer 0）

• 「用不可靠的部件，構造出可靠的系統。」

🔗 相關

• 資料層對應 設計資料密集型應用；可靠訊息呼應 工具-Transactional-Outbox-Pattern