🎯 什麼情境該想到我
當你「想建立一個企業級的共用整合骨幹，讓各種應用像插上同一條匯流排般彼此協作、又保持鬆耦合」的時候。
⚙️ 怎麼用（步驟 / 公式）
意圖：提供一個共用的訊息骨幹（匯流排），讓不同應用透過它以最小耦合協同運作，可各自獨立地加入或移除。
做法 / 結構要點：
- 匯流排由幾件事組成：共用的訊息基礎設施、一組各方共同遵守的通用資料模型/命令結構，以及各應用接上匯流排用的配接器。
- 應用透過匯流排收發訊息，不需彼此直接相連，就像元件插上主機板匯流排。
- 新應用只要遵守共同約定並接上匯流排，即可與既有系統互通。
★★ 這個模式的現代處境：它同時是「目標」也是「反模式」
2003 年的 ESB（Enterprise Service Bus）
→ 一個中央匯流排，內含路由、轉換、編排、監控
→ ★ 2010 年代被公認為反模式：★★ 智慧集中在匯流排，服務變成笨端點
★ 匯流排團隊變成所有變更的瓶頸
今天還活著的部分：
★ 「共用的訊息基礎設施 + 共用的訊息契約」 ← ✅ 這部分完全正確
★ 「中央化的路由與編排邏輯」 ← ❌ 這部分是反模式
★★ 微服務社群的口號：「smart endpoints, dumb pipes」（聰明的端點、笨的管道）。
這正是對 ESB 的直接反駁——業務邏輯屬於服務，不屬於基礎設施。
★ 一個健康的「訊息匯流排」今天長什麼樣
| 匯流排該提供 | 匯流排不該提供 |
|---|---|
| ★ 共用的 broker 叢集（含 HA、監控、備份） | ★ 業務路由規則 |
| ★ 共用的訊息信封格式（見 信封包裝器） | ★ 業務資料轉換 |
| ★ schema registry 與相容性檢查 | ★ 流程編排（那是 流程管理器，屬於某個服務） |
| ★ 通道命名規範與所有權登錄 | 「所有訊息都要經過的中央處理器」 |
| ★ 共用的 client library（trace、重試、冪等骨架） | 業務驗證 |
| 統一的可觀測性（trace id 貫穿） | — |
★ 判準：這件事需要「業務知識」嗎？ 需要 → 屬於服務，不屬於匯流排。
★ 共用 client library：匯流排最有價值的一塊，也最容易做壞
// ★ 好的共用 library：只管橫切關注點，不含任何業務邏輯
package bus
type Publisher interface {
Publish(ctx context.Context, topic string, msg any) error // ★ 自動帶 message-id、trace、schema 版本
}
func Consume(ctx context.Context, topic string, h Handler, opts ...Option) error
// ★ 內建：重試退避、DLQ、冪等去重骨架、metrics、優雅關閉⚠️ 兩個常見的失敗：
- ★ library 開始塞業務邏輯（「所有訂單訊息都要驗證這個欄位」）→ 它變成分散式的上帝物件。
- ★★ library 變成強制升級的耦合點：改一個版本要協調二十個服務一起升。
→ 對策：library 只做加法、保持向後相容，並允許服務停留在舊版本（見 內幕交易）。
★ 什麼時候真的需要「匯流排」這層抽象
| 需要 | 不需要 |
|---|---|
| ★ 服務數量多（十幾個以上），每個都在重複寫同樣的重試／trace／冪等骨架 | ★ 三、五個服務——直接用 broker 的 client，不要提前抽象 |
| ★ 跨團隊需要共同的訊息契約與治理 | 單一團隊 |
| ★ 需要統一的可觀測性 | — |
| 有明確的平台團隊在維護它 | ★ 沒有人擁有它 ⇒ 一定會腐敗 |
★★ 判準：有沒有一個團隊真的擁有它？
沒有 → 共用 library 會變成無主的commonpackage（見 內幕交易），
那比每個服務各自重複寫十行重試邏輯糟得多。
★ 兄弟辨析
| 差別 | |
|---|---|
| 發布訂閱通道 | 單一通道的機制；匯流排是★ 一整組通道 + 格式 + 治理 |
| 訊息橋接 | 點對點連接兩個訊息系統 |
| 標準資料模型 | ★ 匯流排常伴隨它——但它是匯流排最貴的一部分，見該頁 |
| 控制匯流排 | ★ 管理用的獨立通道（設定、健康、指令），不是資料流 |
| 中介者模式 | 行程內的同一個想法（★ 但中介者知道成員，匯流排不知道） |
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
-
成功關鍵在「共同的資料模型與命令契約」，這需要跨團隊治理，難度不低。
-
是企業層級的架構承諾，需要持續維運與治理；小範圍整合用單一通道即可，不必上匯流排。
-
★★ 中央化的路由與編排邏輯是反模式。「smart endpoints, dumb pipes」——業務邏輯屬於服務。
-
★★ 判準：這件事需要業務知識嗎？ 需要 → 不屬於匯流排。
-
★ 共用 client library 不可以塞業務邏輯，否則它變成分散式的上帝物件。
-
★★ 共用 library 是強制升級的耦合點。只做加法、保持向後相容、允許服務停在舊版。
-
★ 沒有團隊擁有的「匯流排」一定會腐敗，比各服務重複寫十行重試邏輯糟得多。
-
★ 三五個服務不需要這層抽象。提前抽象是 誇誇其談通用性。
-
匯流排常伴隨 標準資料模型，而那是它最貴的一部分——先讀那一頁。
-
統一的可觀測性是匯流排最實在的收益，比「統一格式」更值得先做。
🔗 相關工具
- 發布訂閱通道 Publish-Subscribe Channel（匯流排常以發布訂閱做事件廣播）
- 訊息橋接 Messaging Bridge（可用來把既有訊息系統併入匯流排）
- 通道配接器 Channel Adapter（讓各應用接上匯流排的接口）
- 企業整合模式
- 發布訂閱通道 —— 單一通道的機制
- 訊息橋接 —— 連接兩個訊息系統
- 標準資料模型 —— ★ 匯流排最貴的一部分
- 控制匯流排 —— 管理用的獨立通道
- 信封包裝器 —— 共用的訊息信封格式
- 內幕交易 —— 共用 library 腐敗的機制
- 中介者模式 —— 行程內的同一個想法