1、背景介紹

隨著轉轉業務規?？焖僭鲩L，系統拓撲結構越來越復雜，加上二手交易玩法也非常多（如C2C、C2B、B2B、B2C、C2B2C等），在這種復雜系統架構和業務場景下，無法避免會出現RPC調用失敗，消息漏發，線上Bug，業務新老規則沖突等因素引發數據異常，導致用戶客訴，以及公司產生損失。當時公司沒有一個統一的數據校驗治理方案，行業也無相關開源系統，導致業務數據治理這塊一直都是一個沒有深入治理的領域?；谝陨媳尘埃D轉業務規則校驗平臺(簡稱ZZBCP:ZZ Business Check Platform)孕育而生，此系統幫助業務系統實時校驗線上的每一筆單據數據，填補了業務數據質量治理領域的空白。

2 系統目標

• 實時發現線上業異常數據，及時間通知相關人員介入排查，以降低數據異常對用戶和業務的影響。
• 低成本接入各種場景數據校對。通過后臺配置方式，錄入校驗規則信息。
• 實時搜集監控數據，并生成統計監控報表，實時掌握系統數據質量。

3 系統設計詳解

下圖是系統執行規則流程圖，觸發事件源(trigger msg)驅動規則執行(實時或者延時執行)，目標事件數據源(Target msg-可以不配置目標數據源，則通過RPC方式獲取需要校驗的目標數據源)是被校驗的數據內容。

3.1 系統執行時序圖

T1時刻，系統收到觸發消息后，命中規則且延時到T3時刻進行數據校驗動作。T2時刻，收到目標消息，則將目標消息處理后，暫存到Codis中，等到T3時刻對目標消息進行校驗，然后根據校驗結果執行后續流程。

3.2 消息訂閱模塊

當前支持訂閱MQ和Binlog消息(Redis/ES暫時不支持)。該模塊將觸發事件和目標事件的數據，統一轉化成ZZBCP系統標準的數據格式，方便后續規則執行引擎統一進行處理。當前對binlog消費使用的Kafaka，將MySql, TiDB的binlog通過CDC中間件(Canal, Maxwell)推送到Kafka消息中間件。

3.3 規則執行模塊

延時隊列中的規則到期后，會執行數據組裝操作，從redis中查詢數據(目標數據源)，將數據按系統定義的格式組裝好，交給規則執行引擎執行。

當前我們支持兩種規則執行引擎:

• 一種是Aviator規則引擎，這種規則引擎適用校驗規則較為簡單的場景，編寫效率高， 但是一旦校驗邏輯復雜，使用此方式，則編寫的表達式晦澀難懂，而且后期維護成本高。另外， 除了支持Aviator通用函數，我們還內置一下內置函數，如支持redis訪問的函數，公司通用的中間件的操作函數。

• 另外一種是Java規則引擎，業務接入按系統規定實現接口方法，并支持泛化調用，不需要依賴業務接口協議接口定義，大大提示了接入效率，并由配置后臺實時動態編譯并生效，這個方式主要是為了解決校驗邏輯較為復雜，校驗的目標數據需要依賴RPC從第三方獲取的場景。對于動態編譯這塊，我們使用Java提供的原生編譯工具類進行動態編譯并加載到JVM中。這個過程中需要注意加載和執行時候ClassLoader不一致的問題。

3.4 告警模塊

該模塊主要是根據規則執行引擎返回的結果，判斷是否需要進行后續的告警操作,異常數據的收集，以及否需要進行重試執行校驗動作。

• 告警短信通知信息，透出的業務數據源按需配置，需要透出哪些信息，方便后續定位。

• 異常數據收集列表

3.5 數據自動修復模塊

對于以下特殊場景的數據異常，如果可以自動化觸發數據修復，則可以使用此功能進行一個數據修復。當前我們的內部財務對賬系統，就使用了此功能對異常數據進行自動修復。鑒于時刻對線上數據的敬畏之心，此功能具體修復邏輯，建議控制在業務所屬領域內，ZZBCP平臺只是一個觸發修復的入口。

3.6 監控指標

系統會將所有的規則信息上報到轉轉的監控系統(Prometheus- 轉轉進行了二次開發)，對一些經常關注的指標進行統計上報。如規則命中統計，執行規則校驗通過，執行校驗未通過次數等。

3.7 后臺配置

后臺配置提供了事件注冊注冊，報警相關配置和灰度以及手動執行規則等功能。方便業務快速的配置和測試自己的規則校驗邏輯。

參考資料

??https://www.infoq.cn/article/j*6vp2pbuggcrzbhcaog??

??https://tool.lu/en_US/deck/sw/detail?slide=8??