🎯 什麼情境該想到我
當你「有一個本身不使用訊息的應用程式或資料源，卻想把它接上訊息系統」的時候，而且最好不必大改那個系統。
⚙️ 怎麼用（步驟 / 公式）
意圖：用一個配接器把不使用訊息的應用（或其資料庫、API）連上訊息通道，在兩者間雙向搬運資料。
做法 / 結構要點：
- 配接器以該系統原本的方式存取它（呼叫其 API、讀寫其資料庫、監看其事件）。
- 一端與應用溝通、一端與訊息通道溝通，把應用資料轉成訊息送出、或把訊息轉成對應用的操作。
- 讓既有系統幾乎不必修改，就能參與訊息式整合。
★ 今天最常見的三種通道配接器
| 類型 | 實例 | 一句話 |
|---|---|---|
| ① ★ CDC（資料庫 → 訊息） | Debezium、AWS DMS、Kafka Connect | 讀 WAL／binlog，把資料變更變成事件 |
| ② API ↔ 訊息 | API Gateway → SQS、Webhook → 佇列、Kafka Connect HTTP sink | 讓不會講訊息的系統參與 |
| ③ 檔案 ↔ 訊息 | S3 Event → SQS、Kafka Connect S3 sink | 見 檔案傳輸 |
★ 配接器的價值：讓「不能改的系統」也能參與訊息架構。
遺留系統、第三方 SaaS、只會寫資料庫的舊應用——你在它外面接一個配接器，不動它一行程式碼。
★★ CDC 是這個模式今天最重要的形態
應用程式 ──寫──▶ PostgreSQL ──WAL──▶ Debezium ──▶ Kafka ──▶ 下游服務
↑ ★ 應用程式完全不知道這條管線存在
為什麼 CDC 特別有價值：
- ★ 零侵入：不改應用程式、不需要它發訊息。
- ★ 不會漏：WAL 是交易日誌，只要交易 commit 了就一定在裡面——
這順便解決了雙寫問題（見 保證投遞、工具-預寫日誌與崩潰復原）。 - ★ 是拆分單體的遷移路徑：下游從「直接讀表」改成「訂閱事件」，每一步可回退
（見 共享資料庫）。
★★ 但 CDC 有一個根本的設計問題：它洩漏資料庫 schema。
CDC 事件 = 「orders 表的第 42 列，status 從 'pending' 變成 'paid'」
業務事件 = 「訂單 #42 已付款」
↑ ★ 這兩者不一樣
★★ CDC 給你的是「資料變更」，不是「業務事件」。
直接把 CDC 事件發給下游 → 下游依賴你的表結構，你改欄位名就破壞它們（見 內幕交易）。
兩種解法：
- ★ 配一個轉換層（Kafka Streams／一個服務）把資料變更轉成業務事件（訊息轉換器／防腐層）。
- ★ 或改用 Outbox：應用程式明確寫出業務事件到 outbox 表，CDC 只讀那張表
→ 這是目前公認最好的組合（見 工具-Transactional-Outbox-Pattern）。
★ 配接器的三個實務陷阱
① ★★ 初始快照（initial snapshot）
CDC 上線時要先讀一次全表 → 幾千萬列灌進 Kafka
→ ★ 會壓垮下游，也可能壓垮來源 DB
→ 要規劃：分批快照、限流、或先讓下游準備好
② ★ WAL 保留與 replication slot
Postgres 的 logical replication slot 如果消費者停了，★ WAL 會一直累積不能回收
→ ★★ 磁碟滿了資料庫就會停止寫入。這是 CDC 最嚴重的營運風險
→ 一定要監控 slot 的 lag 與 WAL 大小
③ ★ 配接器是單點
Debezium 掛了 → 事件流停了，但應用程式完全正常（★ 沒有任何錯誤會出現）
→ ★ 要監控「最後一筆事件的時間」，不要只監控配接器的存活
★ 兄弟辨析
| 差別 | |
|---|---|
| 訊息橋接 | ★ 連接兩個訊息系統（Kafka ↔ RabbitMQ）；配接器連接「非訊息系統 ↔ 訊息系統」 |
| 訊息閘道 | ★ 在應用程式內部封裝 broker API；配接器在應用程式外面 |
| 服務啟動器 | 讓同一個服務同時能被訊息與同步呼叫觸發（★ 在應用程式內） |
| 正規化器 | 多種格式轉成一種（配接器可能用到它） |
🧪 我實際套用的紀錄
- （待填）
⚠️ 注意 / 什麼時候不適用
-
配接器通常需為特定系統客製，且可能綁定其內部細節（如資料庫結構），耦合較深。
-
直接讀寫他人資料庫的配接方式可能繞過該應用的商業邏輯，需謹慎。
-
★★ CDC 給你的是「資料變更」不是「業務事件」。直接發給下游 = 下游依賴你的表結構。配轉換層，或改用 Outbox + CDC。
-
★★ Postgres 的 logical replication slot 停了會讓 WAL 無限累積，磁碟滿了資料庫就停止寫入。 這是 CDC 最嚴重的營運風險，必須監控 slot lag。
-
★ CDC 的初始快照會灌爆下游（也可能壓垮來源 DB）。要規劃分批與限流。
-
★ 配接器掛了不會有任何錯誤出現——應用程式完全正常，只是事件流停了。要監控「最後一筆事件的時間」。
-
★ CDC 看不到「意圖」：
status從 pending 變 paid，是付款成功還是人工修資料？業務語義只有應用程式知道。 -
配接器是額外的部署與監控負擔。能改應用程式直接發訊息時，不一定需要它。
-
DELETE 在 CDC 裡特別麻煩：有些設定只給主鍵、拿不到舊值（Postgres 要設
REPLICA IDENTITY FULL，代價是 WAL 變大）。
🔗 相關工具
- 訊息端點 Message Endpoint（通道配接器是一種特殊端點）
- 訊息橋接 Messaging Bridge（對照：橋接連兩套訊息系統，配接器連非訊息系統）
- 訊息轉換器 Message Translator（常與配接一起把外部格式轉成內部格式）
- 企業整合模式
- 訊息橋接 —— 連接兩個訊息系統
- 訊息閘道 —— 應用程式內部的封裝
- 檔案傳輸 —— 檔案型配接器
- 防腐層、訊息轉換器 —— 把資料變更轉成業務事件
- 工具-Transactional-Outbox-Pattern —— ★ Outbox + CDC 是公認最佳組合
- 工具-預寫日誌與崩潰復原 —— CDC 為什麼不會漏
- 共享資料庫 —— CDC 作為拆分的遷移路徑