一、前言

對賬，從狹義上來說，就是核對賬目，是保證會計賬簿記錄質量的重要程式。從廣義上來說，對賬可以解釋為資料比對，用於解決所有分散式系統之間互動(遠端呼叫、訊息觸發等)出現的資料不一致問題。有贊作為一家Saas公司，隨著業務的發展，商家數達到上百萬，每天產生上千萬的業務資料，系統穩定性更加要求達到99.99%。資料對賬作為業務穩定性必要的一環，下文將介紹配置化資料對賬平臺在有讚的解決方案，如何在複雜的系統之間，保證不一致的快速發現、展示以及解決。

二、背景

目前有讚的業務不斷髮展，業務複雜度不斷提高，出現不一致的情況也逐漸增多。下面簡述幾個出現不一致資料的場景：

場景一：有贊商家呼叫達達同城配送，隨後取消配送訂單，但達達系統未取消，導致第三方達達系統同城送計費多算。場景二：買家在有贊商家店鋪購買商品參與了滿減送，但是贈送的優惠券遲遲沒有送達。場景三：買家在有贊商家店鋪下的訂單支付成功了，但是訂單狀態還是"待付款"。

從上述列舉的場景分析，資料不一致問題，容易出現在交易、物流、營銷等分散式系統之間資訊流互動的邊界上。

根據背景以及公司內部現狀，總結痛點：

業務場景複雜，不能夠及時發現問題，給商家以及買家造成困擾。功能快速迭代，出現業務問題，客服反饋量容易出現快速上升，公司對外處理問題比較被動。部分業務有零散的對賬實現，但是硬編碼在業務中，每經歷業務變更，對賬邏輯可能會跟著變化，導致開發成本增大。業務方在處理不一致問題時，沉澱文件費勁，沒有歸檔為後面排查問題提供經驗支援。三、設計目標

業務對賬平臺設計目標主要從以下幾點出發：

方便業務對賬場景接入，實現業務用例場景覆蓋。實時處理海量業務資料比對，及時發現數據不一致問題併產生反饋，儘可能減少對客戶的影響。離線業務資料比對，實現業務資料海量回歸，全方位核對，降低不一致資料的出現機率。針對業務快速迭代開發，實現靈活調整對賬業務邏輯以及對賬相關的配置。提供豐富的視覺化業務比對圖表，供業務方監控當前資料的比對情況。為不一致比對結果提供對賬鏈路的資料快照，方便定位問題。整合資料訂正工具，實現簡單業務邏輯，自動修復，減少人力成本。為業務線提供業務資料穩定性報告。四、整體設計4.1 整體架構

業務對賬平臺採用DDD設計，分為4層：接入層、應用層、領域層、基礎層。

接入層：支援對賬平臺後臺操作與統一排程服務排程的接入。

應用層：支援多個領域層細力度操作的整合，面向業務提供服務。

領域層：對賬邏輯執行核心，其中包含支撐域、核心域與領域模型。從源資料載入，資料組裝，任務排程，到任務執行，結果儲存進行報警，完整實現了對賬的核心鏈路。

基礎層：提供基礎設施服務，其中包含資料持久化儲存、訊息傳遞、任務開關配置、黑白名單設定等。

4.2 核心用例圖

從整體上觀察，面向使用者，支援哪些操作。面向開發者，拆分對賬平臺管理端用例。面向排程系統，拆分具體執行用例。

4.3 對賬核心思路

基於一系列的對賬場景梳理，進行業務抽象，得到對賬的核心構建思路，主要分為資料準備、邏輯比對、差錯處理。

4.3.1 資料準備

資料準備模組作為對賬核心構建思路的第一步，支援業務方多種形式資料的接入，為對賬提供所需的資料，即基準資料和待比對資料。

資料接入

資料準備模組為滿足公司內部不同業務方的資料接入需求，提供了多種資料接入方式：

資料上傳：支援excel檔案上傳，業務按照自定義欄位轉化規則進行源資料轉換，寫入到源資料池。資料拉取：支援dubbo或者http介面呼叫輪詢全量或者增量拉取資料，進行資料迭代。資料推送：支援數倉規則化資料寫入到源資料池。資料儲存與隔離

多種業務資料匯入到源資料池，源資料池中混雜各種資料。為了區分各類業務資料，採取這樣的規則用來區分：

業務資料型別：區分不同業務資料，比如retailspues表示零售商品庫商品es對賬資料。執行週期版本號：業務週期版本號，比如20200101表示當前業務資料迭代器載入哪個版本批次資料。資料規則化

業務資料比較複雜，按照每個業務定義的class解析，維護成本高，資料規則化為了克服資料的多樣性，對賬資料平臺提供源資料格式標準化接入，按照JSON資料格式序列化儲存，使用時按照Map.class進行反序列化使用。

{    "dataAttributes":{        "deductFee":"0.0",        "orderNo":"YZ202011122334455",        "deliveryFee":"10.0",        "tipFee":"0.0",    },    "uniqueKey":"YZ202011122334455"}

資料準備詳細流程設計：

4.3.2 邏輯比對

業務邏輯比對，是資料對賬平臺最核心的一步。業務邏輯核對結果決定了後續差錯處理、任務結果趨勢統計、業務健康度等環節。所以，業務邏輯核對需要做到結果準確，指令碼靈活調整。

如何保證邏輯比對結果準確？

業務邏輯指令碼質量由接入業務方進行保證，業務對賬平臺提供Mock測試工具，支援業務方構造引數來測試對賬流程準確性。

如何保證比對指令碼靈活調整？

if (order == null) {    return ;}def orderStatus = order.orderStatus;def errorMsg;if (orderStatus != "WAIT_SHIPPED" && orderStatus != "SHIPPED") {    errorMsg = "訂單號:" + order.orderNo + ",訂單狀態未流轉至待發貨，當前狀態為:" + orderStatus;}return errorMsg;

靈活性：邏輯核對邏輯使用Grovvy實現，透過載入上下文資料，業務方自由實現業務比對邏輯，按照規則進行返回錯誤。每個任務對賬邏輯儲存在DB中，每當有對賬執行透過載入到記憶體，執行邏輯核對。當然，當業務方業務邏輯有更改，需要檢查指令碼的準確性，重新進行Mock測試。

對賬方式

載入業務源資料，進行Grovvy指令碼邏輯比對，必然會出現左右方業務資料進行核對，對賬方式也會出現兩種：

單向對賬：以左方資料作為基準資料，另一方資料作為待比對資料，進行業務邏輯核對，得出不一致結果。雙向對賬：兩方資料互為基準資料和待比對資料，進行業務邏輯核對，核對出雙方沒有對方資料的差異。

業務對賬平臺透過建立兩個對賬任務，左右方資料分別作為基準資料進行源資料載入核對。

對賬粒度

對賬粒度主要劃分為明細對賬和總數對賬兩塊。

明細對賬：單條源資料，根據業務唯一標識進行關聯，實現業務邏輯比對。總數對賬：使用者自定義業務邏輯比對維度，系統按照該維度進行統計，與另外一個統計的總數進行一般。

從兩種對賬力度來看，明細對賬透過複雜的業務邏輯判斷，更加細膩，可以發現漏掉、重複、錯誤的資料等，總數對賬只能在某個維度來對賬，不能夠定位到單條記錄上。所以，在一般的對賬場景中，明細對賬為主，總數對賬為輔，兩者結合使用。

邏輯比對詳細流程設計：

4.3.3 差錯處理

差錯處理是關鍵性的第三步，反饋結果給技術人員與業務系統。差錯處理含有對不一致結果進行展示，重試，報警，訂正，下載等操作。

二次核對

二次核對有兩種方式組成，自動重試與手工重試。

自動重試：解決因為網路抖動、外部資料載入異常，導致對賬邏輯錯誤的問題。手工重試：業務訂正不一致資料後，校驗業務資料。結果報表下載

對賬結果按照開發者自定義轉換規則，直接加工形成報表，生成第三方需要的格式檔案。

報表生成流程：

報表案例：

案例備註

業務方支援在業務對賬平臺進行案例沉澱，方便案例在業務組內共享，減少業務排查時間，節省人力成本。

報警案例：

業務資料訂正

對賬平臺透過比對結果，按照指定的異常，進行傳送RPC泛化呼叫和非同步訊息兩種方式進行通知業務方，業務方可以配置對應的訂正方式。

差錯處理詳細流程設計：

五、功能介紹

對賬平臺倡導流程標準化，在幾個關鍵點進行配置，支援開發者花更多精力在對賬相關資訊、邏輯對賬細節，後續處理比對不一致結果上。

5.1 對賬任務配置化基本資訊：描述清楚對賬任務的目的，比如任務標題，任務許可權等。觸發時機：觸發對賬任務執行的時間點，準實時對賬按照領域事件觸發，離線對賬按照Tsp(有贊統一排程平臺)觸發。外部資料載入：實時載入業務對賬中的所需資料，基於Dubbo泛化呼叫實現。不一致結果報警：關聯配置統一報警平臺(支援電話、內部管理軟體、郵件、企業微信等渠道報警)配置，出現比對不一致結果進行報警推送。5.2 任務Mock測試工具

配置完任務，不確定對賬任務的準確性。對賬平臺提供了Mock測試工具，便於檢驗對賬整個流程。Mock測試工具支援引數Mock，以及執行流程快照視覺化，模擬實現對賬鏈路。

如何構造測試引數?實時對賬：測試引數為業務對應的訊息體，直接貼入訊息體即可，對賬平臺Mock執行環境流程進行對賬。離線對賬：測試引數為標準化結構，業務方按照對應的結構傳入引數，對賬平臺進行解析，透傳到Mock執行流程，進行對賬。

實時對賬Mock測試案例：

對賬資料展示：記錄對賬過程中，外部載入器實時載入的資料快照，用於下文業務邏輯核對。

5.3 對賬結果趨勢統計

對賬結果主要統計對賬執行過程中產生的資料，給開發者提供視覺化監控，觀察當時以及以往彙總資料，可以透過指標同比、環比，得出業務波動性。

趨勢統計指標主要分為兩個大維度，包括：時間維度和業務維度。

時間維度：時間維度按照5分鐘、1小時、1天三個維度在業務維度上進行聚合，形成一個槽，進行資料記錄。

業務維度：業務維度主要指的是業務指標，有校驗數量、不一致數量、解決數量、自動訂正數量等。業務指標反應出對賬任務的執行情況，業務的健康程度、修復情況等。

六、技術挑戰6.1 已遇到的技術挑戰業務介面限流

問題：業務對賬平臺支援業務介面實時反查，遇到大流量實時訊息或者大批次離線對賬時，對業務系統會形務呼叫洪峰，觸發業務介面限流。

解決方案：按照介面維度讓業務方給定QPS，對賬系統接入限流器，按照限流呼叫對應的介面進行對賬，如單個對賬任務存在多個介面，按照全域性最小QPS執行限流操作。限流方案：限流目前採用的是com.google.common.util.concurrent.RateLimiter，每臺機器RateLimiter = 例項介面支援安全的QPS / 對賬應用例項數重試方案：存在RPC呼叫失敗的情況，對賬系統這邊支援5s、30s、60s進行對賬重試，如果重試3次之後繼續失敗，進行業務報警。6.2 後續技術挑戰6.2.1 多流實時資料join

目前對賬系統這邊實時對賬驅動對賬執行是單流實時資料，為了減少業務介面反查，減少對業務系統的影響，對賬系統這邊已在考慮多流實時訊息join，透過業務唯一標識串聯多流資料，達到可執行狀態。

業務對賬執行緒池定時拉取可執行對賬源資料，進行基於資料級別業務對賬。

6.2.2 智慧化推薦對賬規則

當前業務的比對規則是業務專家給定的，但是業務專家給定的維度不一定完全，容易出現遺漏的地方。智慧化，可以從對賬規則維度，基於規則資料的學習來找出規律，從而推薦對賬規則。業務專家在編寫對賬規則的時候，透過引入推薦的對賬規則，加強對業務資料的校驗，從而發現資損點和異常資料。

七、未來

業務資料對賬，面向業務場景建立，與業務緊緊相關。有贊業務對賬平臺平臺自從上線以來，已承接公司各團隊的資訊流對賬，每天處理上千萬資料。分散式系統互動之間，資料不一致問題不能完全避免。未來資料比對平臺，在做好高實時、高吞吐量的時候，還會往配置化與視覺化方向發展，從業務資料生產到訂正業務資料，各維度統計攔截結果價值，反饋給業務方系統穩定性，形成業務資料對賬閉環。對於業務資料，我們保持謹慎，充滿敬畏，做好穩定性的守門員。