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

📌 30 秒摘要（Layer 3）

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

🗺 心智圖（Canvas）

鳳凰架構

鳳凰架構

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

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

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

🎯 什麼情境該想到我

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

⚙️ 怎麼用

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 過早微服務化＝把「函式呼叫」變成「網路呼叫」，換來分散式事務與除錯地獄。

🔗 相關工具

• 工具-限界上下文 —— 拆分邊界怎麼畫的判準，按業務語意切比按技術層切耐用
• 工具-服務容錯設計 —— 拆完必付的代價，一旦跨網路呼叫就得處理雪崩
• 工具-管理複雜度 —— 決策準則，微服務把單體的複雜度換成分散式的複雜度，值不值得用它衡量

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

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

工具-透明多級分流

🎯 什麼情境該想到我

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

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

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

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 每多一層都是複雜度與延遲；按實際規模採用，別一開始就全套。

🔗 相關工具

• 工具-服務容錯設計 —— 下一層防線，分流擋不住的故障靠熔斷與降級收尾
• 工具-資料分區 —— 更後面的瓶頸，前端流量分散了，資料層還是得自己切
• 工具-可靠可擴展可維護 —— 上位框架，分流同時服務可用性與可擴展兩個目標

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

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

工具-分散式事務的取捨

🎯 什麼情境該想到我

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

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

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

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 別預設「一定要強一致」；強一致代價很高。也別在 DB 交易內直接發 MQ。

🔗 相關工具

• 工具-Transactional-Outbox-Pattern —— 最常落地的一種實作：用本地交易＋Outbox 換掉 2PC 的分散式鎖
• 工具-交易與隔離等級 —— 單機版的對照組，先懂單機保證了什麼，才知道跨服務失去了什麼
• 工具-MQ消費端防禦三原則 —— 走最終一致路線後的必要配套：consumer 必須能承受重複與亂序

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

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

工具-服務容錯設計

🎯 什麼情境該想到我

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

⚙️ 怎麼用（組合使用）

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

🧪 我實際套用的紀錄

• 2026-07-15：（待填）

⚠️ 注意

• 無腦重試是雪崩幫兇；重試前先確認「冪等 + 退避 + 熔斷」都到位。

🔗 相關工具

• 工具-MQ消費端防禦三原則 —— 非同步那一側的容錯，這張顧同步呼叫鏈，它顧訊息消費端
• 工具-防禦式編程 —— 更小顆粒的同一心態，容錯在服務層設界線，防禦式在函式層設界線
• 工具-透明多級分流 —— 上游配套，健康檢查與流量調度是熔斷之前就該擋掉問題的那一層

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

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

容器 × 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