轉轉業務資料校驗平臺實踐分享

　　 1 背景介紹

　　隨著轉轉業務規模快速增長，系統拓撲結構越來越複雜，加上二手交易玩法也非常多（如C2C、C2B、B2B、B2C、C2B2C等），在這種複雜系統架構和業務場景下，無法避免會出現RPC呼叫失敗，訊息漏發，線上Bug，業務新老規則衝突等因素引發資料異常，導致使用者客訴，以及公司產生損失。當時公司沒有一個統一的資料校驗治理方案，行業也無相關開源系統，導致業務資料治理這塊一直都是一個沒有深入治理的領域。基於以上背景，轉轉業務規則校驗平臺(簡稱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 後臺配置

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