在現代企業信息系統架構中，我們常常面臨如下挑戰：某個業務系統屬于“不可變更系統”，我們既不能修改其業務邏輯，也不能對其核心代碼做任何侵入式改動。但與此同時，我們又需要對該系統中的某些關鍵業務數據變更做出響應，例如同步數據、驅動流程、記錄日志或派發消息。
一種常見做法是：通過數據庫觸發器（Trigger）監控特定表的數據變動，實現“非侵入”的處理邏輯。但觸發器作為數據庫層的一種機制，存在可維護性差、調試困難、性能不可控等問題。在更大規模、可觀測性要求高、或多系統協同的場景中，顯得力不從心。
本文將探討在“無法更改系統”的前提下，除了觸發器，還有哪些更合適的解決方案，并對各種方式進行橫向對比。
一、觸發器方式：簡單但代價高
優點：
非侵入：不修改源系統代碼。
實時性強：數據變更即觸發，無需輪詢。
缺點：
對數據庫性能有負擔，尤其是高并發更新場景容易造成死鎖。
可測試性和調試難度大，不利于復雜邏輯。
運維困難，部署依賴數據庫DDL操作，缺少版本管理支持。
多數數據庫不支持跨庫觸發，影響系統整合能力。
二、替代方案分析
1. CDC（Change Data Capture）/日志訂閱
原理： 通過數據庫的redo log或binlog采集變更事件，使用Kafka等中間件進行下游事件派發。
代表工具：
MySQL：Debezium、Canal
PostgreSQL：Logical decoding
SQL Server：原生 CDC 功能
優點：
非侵入、低延遲
不影響線上 DML 操作
可以構建完整事件流架構
缺點：
部署和運維復雜度相對較高
依賴數據庫日志配置和權限
對于一些云數據庫可能權限受限
適用場景：
數據同步、數據湖落地、事件驅動系統（EDA）
多系統間的異步集成
2. 異步輪詢機制
原理： 定時掃描數據表中變化的數據（如按時間戳、狀態字段篩選），由獨立服務讀取并處理。
優點：
技術實現簡單
可控性高，適合小批量、低頻任務
缺點：
實時性弱，粒度通常是分鐘級別
需要有合適的“增量標記字段”（如 last_modified）
適用場景：
報表生成、數據備份、低頻同步場景
3. 數據庫代理層（Proxy/Middleware）監聽
原理： 在數據庫前部署一個代理，攔截SQL語句，識別變更操作進行處理。
代表方案：
ShardingSphere 的透明代理
自定義 MySQL Proxy
優點：
透明性好，無需改應用代碼或數據庫結構
實現復雜邏輯處理能力強
缺點：
性能瓶頸顯著，對核心系統而言風險高
落地門檻高、維護成本大
適用場景：
對核心業務做全量審計
安全審計、數據變更合規分析
4. 利用數據庫審計功能（Audit）
部分商業數據庫（如 Oracle、SQL Server 企業版）或通過第三方插件支持對表的所有變更行為記錄到審計日志中。
優點：
非侵入性極高
官方支持穩定
缺點：
審計信息格式復雜，處理困難
多數審計日志是寫入文件或系統表，解析開銷大
適用場景：
合規性審計、敏感數據訪問監控
5. 構建數據網關（Data Gateway）服務
將對不可更改系統的數據寫操作通過網關中轉，網關負責記錄或轉發事件。但這種方式要求系統寫操作不是“直連數據庫”，而是通過統一服務層。
優點：
高可控、可插拔事件處理機制
易于接入事件總線、告警、緩存刷新等機制
缺點：
適用于新建系統或尚可改造系統，對不可更改系統不可行
三、總結對比
| 方案 | 實時性 | 侵入性 | 可維護性 | 性能影響 | 技術復雜度 | 建議適用場景 |
|---|---|---|---|---|---|---|
| 觸發器 | 高 | 無 | 差 | 中高 | 低 | 小型系統數據同步 |
| CDC/日志訂閱 | 高 | 無 | 中 | 低 | 中高 | 企業級數據中臺、數據湖同步 |
| 定時輪詢 | 低 | 無 | 高 | 低 | 低 | 周期性任務、低頻業務驅動 |
| DB代理 | 高 | 無 | 差 | 高 | 高 | 核心系統SQL審計、高安全場景 |
| 審計功能 | 中 | 無 | 差 | 中 | 中 | 審計要求場景、敏感數據監控 |
四、架構建議
若該“不可更改系統”穩定性要求極高，建議優先選擇 CDC 模型或定時輪詢模型，尤其是通過 Kafka + Debezium 實現數據事件總線，是現代企業中臺架構中主流做法。觸發器雖然實現門檻低，但更適合作為臨時、過渡方案使用。
若系統未來存在替換或微服務化可能性，應盡早推動架構升級，引入統一事件總線、數據同步服務或將寫操作納入“業務網關”模式中，逐步去除對底層數據庫邏輯的強耦合。
 add方法報錯java.lang.UnsupportedOperationException)
)
