作者：趙彬輝

團隊：零售技術

一、前言

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

二、背景

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

• 場景一：有贊商家呼叫達達同城配送，隨後取消配送訂單，但達達系統未取消，導致第三方達達系統同城送計費多算。

• 場景二：買家在有贊商家店鋪購買商品參與了滿減送，但是贈送的優惠券遲遲沒有送達。

• 場景三：買家在有贊商家店鋪下的訂單支付成功了，但是訂單狀態還是"待付款"。

從上述列舉的場景分析，數據不一致問題，容易出現在交易、物流、營銷等分佈式系統之間信息流交互的邊界上。

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

1. 業務場景複雜，不能夠及時發現問題，給商家以及買家造成困擾。

2. 功能快速迭代，出現業務問題，客服反饋量容易出現快速上升，公司對外處理問題比較 被動 。

3. 部分業務有零散的對賬實現，但是硬編碼在業務中，每經歷業務變更，對賬邏輯可能會跟着變化，導致 開發成本增大 。

4. 業務方在處理不一致問題時， 沉澱文檔費勁 ，沒有歸檔爲後面排查問題提供經驗支持。

三、設計目標

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

1. 方便業務對賬場景接入，實現業務用例場景覆蓋。

2. 實時處理海量業務數據比對，及時發現數據不一致問題併產生反饋，儘可能減少對客戶的影響。

3. 離線業務數據比對，實現業務數據海量回歸，全方位覈對，降低不一致數據的出現概率。

4. 針對業務快速迭代開發，實現靈活調整對賬業務邏輯以及對賬相關的配置。

5. 提供豐富的可視化業務比對圖表，供業務方監控當前數據的比對情況。

6. 爲不一致比對結果提供對賬鏈路的數據快照，方便定位問題。

7. 整合數據訂正工具，實現簡單業務邏輯，自動修復，減少人力成本。

8. 爲業務線提供業務數據穩定性報告。

四、整體設計

4.1 整體架構

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

接入層：支持對賬平臺後臺操作與統一調度服務調度的接入。

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

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

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

4.2 核心用例圖

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

4.3 對賬核心思路

4.3.1 數據準備

數據準備模塊作爲對賬核心構建思路的第一步，支持業務方多種形式數據的接入，爲對賬提供所需的數據，即基準數據和待比對數據。

數據接入

數據準備模塊爲滿足公司內部不同業務方的數據接入需求，提供了多種數據接入方式：

• 數據上傳：支持excel文件上傳，業務按照自定義字段轉化規則進行源數據轉換，寫入到源數據池。

• 數據拉取：支持dubbo或者http接口調用輪詢全量或者增量拉取數據，進行數據迭代。

• 數據推送：支持數倉規則化數據寫入到源數據池。

數據存儲與隔離

多種業務數據導入到源數據池，源數據池中混雜各種數據。爲了區分各類業務數據，採取這樣的規則用來區分：

1. 業務數據類型：區分不同業務數據，比如retail spu es表示零售商品庫商品es對賬數據。

2. 執行週期版本號：業務週期版本號，比如20200101表示當前業務數據迭代器加載哪個版本批次數據。

數據規則化

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

數據準備詳細流程設計：

4.3.2 邏輯比對

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

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

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

如何保證比對腳本靈活調整？

靈活性 ：邏輯覈對邏輯使用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 智能化推薦對賬規則

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

七、未來

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

擴展閱讀

相關文章