1、背景介紹

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

2 系統(tǒng)目標

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

3 系統(tǒng)設計詳解

下圖是系統(tǒng)執(zhí)行規(guī)則流程圖，觸發(fā)事件源(trigger msg)驅動規(guī)則執(zhí)行(實時或者延時執(zhí)行)，目標事件數(shù)據(jù)源(Target msg-可以不配置目標數(shù)據(jù)源，則通過RPC方式獲取需要校驗的目標數(shù)據(jù)源)是被校驗的數(shù)據(jù)內(nèi)容。

3.1 系統(tǒng)執(zhí)行時序圖

T1時刻，系統(tǒng)收到觸發(fā)消息后，命中規(guī)則且延時到T3時刻進行數(shù)據(jù)校驗動作。T2時刻，收到目標消息，則將目標消息處理后，暫存到Codis中，等到T3時刻對目標消息進行校驗，然后根據(jù)校驗結果執(zhí)行后續(xù)流程。

3.2 消息訂閱模塊

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

3.3 規(guī)則執(zhí)行模塊

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

當前我們支持兩種規(guī)則執(zhí)行引擎:

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

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

3.4 告警模塊

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

• 告警短信通知信息，透出的業(yè)務數(shù)據(jù)源按需配置，需要透出哪些信息，方便后續(xù)定位。

• 異常數(shù)據(jù)收集列表

3.5 數(shù)據(jù)自動修復模塊

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

3.6 監(jiān)控指標

系統(tǒng)會將所有的規(guī)則信息上報到轉轉的監(jiān)控系統(tǒng)(Prometheus- 轉轉進行了二次開發(fā))，對一些經(jīng)常關注的指標進行統(tǒng)計上報。如規(guī)則命中統(tǒng)計，執(zhí)行規(guī)則校驗通過，執(zhí)行校驗未通過次數(shù)等。

3.7 后臺配置

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

參考資料

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

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