訊息代理器

🎯 什麼情境該想到我

當你「眾多端點彼此直連造成耦合爆炸，想用一個中央樞紐集中路由、讓各端解耦」的時候。

⚙️ 怎麼用（步驟 / 公式）

意圖：在不耦合各端點、也不把路由散落各處的前提下，集中維護訊息的目的地決策。

做法要點：

• 設一個中央的 Message Broker。
• 各應用只要把訊息送給 broker、或從 broker 收訊息。
• 由 broker 決定訊息該轉往何處。
• 端點彼此不需知道對方，只需知道 broker——形成 hub-and-spoke 架構。

★★ 這個模式要小心讀：它和 ESB 反模式只有一線之隔

★ EIP 書裡的「訊息代理器」= 一個中央元件，接收訊息並依規則轉送到正確的目的地
→ ★★ 這正是 2010 年代被批判的 ESB（見 [[訊息匯流排]]）
→ 「smart endpoints, dumb pipes」就是對它的直接反駁

★★ 判準：這個中央元件裡有「業務知識」嗎？
有（「VIP 訂單要先送風控」）→ 業務邏輯跑進基礎設施了。
那個規則屬於某個服務，不屬於代理器。
沒有（純粹的技術轉送：協定轉換、拓撲隔離）→ 是合理的。

★ 今天還活著的三種合理形態

形態	例子	為什麼合理
① ★ broker 本身	Kafka／RabbitMQ／NATS	★ 它就是一個訊息代理器，而且沒有業務知識
② ★ 協定／拓撲轉接	通道配接器、訊息橋接、API Gateway → 佇列	純技術轉換
③ ★ 事件路由基礎設施	AWS EventBridge、Azure Event Grid	★ 規則是宣告式的、可版控的，而非程式碼

★ ③ 是最接近原始意圖、又避開 ESB 陷阱的形態：
規則用 IaC 宣告（Terraform／CDK），進版控、可 review、可測試——
這解掉了「拓撲不在任何 repo 裡」這個 ESB 最致命的問題。

★★ 如果你真的要自己寫一個代理器：三條紅線

① ★★ 不放業務規則
   ✅ 「type 開頭是 orders. 的送到 orders 相關通道」  ← 技術規則
   ❌ 「金額 > 10000 的送風控」                      ← ★ 業務規則，屬於某個服務

② ★★ 無狀態
   有狀態（等齊、排序、記進度）→ 那是 [[聚合器]]／[[流程管理器]]，不是代理器
   → 無狀態才能水平擴展、隨意重啟、不必擔心狀態恢復

③ ★★ 規則進版控，不放 UI／DB
   ★ 「在管理介面點幾下就改了路由」= 三年後沒人知道訊息為什麼流到那裡
   → 用 IaC 或程式碼宣告（見 [[隨選環境與基礎設施即程式碼]]）

★ 中央代理器的三個固有代價

① ★★ 單點
   代理器掛了 → 所有訊息流停止
   → ★ 但更糟的是「半掛」：某條規則出錯，只有一部分訊息不見了
   → ★ 每條路由規則都要有「通過量」指標，不只監控代理器存活

② ★ 瓶頸（組織上的，不只是技術上的）
   所有跨服務的變更都要經過代理器 → ★ 維護它的團隊變成所有人的瓶頸
   → ★★ 這是 ESB 真正失敗的原因，不是技術問題（見 [[內幕交易]]）

③ ★ 多一跳
   延遲、額外的失敗模式、除錯要多看一個系統

★ 什麼時候根本不需要它

• ★ 生產者知道自己在發什麼 → 直接發到正確的通道。這是預設答案。
• ★ 用 broker 的原生路由（RabbitMQ topic exchange、SNS filter policy）→ 零元件。
• ★ 用發布訂閱 + 消費者自己訂閱 → 完全不需要中央決策。
• ⚠️ Kafka 上要特別注意：它幾乎沒有內建路由，所以「加一個代理器」的誘惑最大——
  ★ 但那也意味著你要自己維運它（見 訊息路由器）。

★ 兄弟辨析

	差別
訊息路由器	★ 一個路由決策元件；代理器是一整組路由 + 通道的中心
訊息匯流排	★ 更偏「共用基礎設施 + 契約」；代理器偏「中央轉送」
控制匯流排	管理用通道，不是資料流
中介者模式	★ 行程內的同一想法（★ 中介者知道成員；代理器理想上不該知道）
代理模式	★ 名字像但不同：那是「代表某個物件」，不是「轉送訊息」

🧪 我實際套用的紀錄

• （待填）

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

• broker 是中心樞紐，須注意可擴充性與單點風險。

• 內部通常由多個路由模式組成。

• 避免 broker 承擔過多商業邏輯，變成難維護的「上帝元件」。

• ★★ 這個模式和 ESB 反模式只有一線之隔。判準：中央元件裡有業務知識嗎？有 → 業務邏輯跑進基礎設施了。

• ★★ 三條紅線：不放業務規則、保持無狀態、規則進版控。

• ★★ ESB 真正失敗的原因是組織性的：維護代理器的團隊變成所有人的瓶頸。

• ★ 中央代理器「半掛」比全掛更危險：某條規則出錯只有一部分訊息不見。每條規則都要有通過量指標。

• ★ 在管理介面點幾下改路由 = 三年後沒人知道訊息為什麼流到那裡。 用 IaC 宣告。

• ★ 生產者直接發、broker 原生路由、發布訂閱 —— 三者都比加代理器便宜。

• ★ Kafka 沒有內建路由，加代理器的誘惑最大——但那是一個你要維運的服務。

• AWS EventBridge／Event Grid 是最接近原意又避開陷阱的形態（宣告式、可版控）。

🔗 相關工具

• 內容路由器 Content-Based Router（broker 內部常用的路由手法）
• 流程管理器 Process Manager（同為中央化協調）
• 收件人清單 Recipient List（broker 可據此分送給多端點）
• 企業整合模式
• 訊息路由器 —— 單一路由決策元件
• 訊息匯流排 —— 共用基礎設施與契約
• 控制匯流排 —— 管理用通道
• 通道配接器、訊息橋接 —— 純技術轉接的合理形態
• 隨選環境與基礎設施即程式碼 —— 規則進版控
• 內幕交易 —— 中央元件變成組織瓶頸
• 中介者模式、代理模式 —— 行程內的相近想法