美團配送資金安全治理之對帳體系建設

時間 2019-11-17

原文原文鏈接

前言

隨着美團配送業務的飛速發展，單量已經達到千萬級別，同時天天產生的資金額已經超過幾千萬，清結算系統在保證線上服務穩定可靠的前提下，如何系統化的保障資金安全是很是核心且重要的課題，配送清結算系統通過近3年的建設和打磨，在資金安全保障的多個方面均有一些總結和實踐，保障資金安全是值得系統思考的課題，隻言片語難以全面歸納，須要更多的着墨才能較完整闡述。html

本文側重點會闡述「對帳」的概念，在支付&清結算領域，這是一個很是重要的專業名詞，下文將介紹「對帳」在分佈式系統建設中的實踐和解決方案，力求在系統覆蓋度、資金準確性、時效等多個維度爲系統資金安全保駕護航，實現更健壯可靠的資金履約。數據庫

背景&問題

隨着美團外賣配送事業的蓬勃發展，配送清結算業務的複雜性也在不斷的增高，總結起來，主要有如下幾個特色：安全

場景多：包括專送、衆包、快送、跑腿、外部單等多條業務線；訂單補貼、活動發放、獎懲、餐損、打賞、保險等多種結算場景；對接外部十多個系統。
鏈路長：清結算內部經歷訂價、記帳、彙總帳單、付款等多個流程。
單量大：目前日單量已達到千萬級別。

在這樣的業務背景下，咱們的系統可謂險象環生。因業務高度複雜，稍有不慎就會出現問題，面對千萬級的日單量，同時還要確保結算金額的準確，這就讓咱們對問題的容忍度變得極低。這也給咱們的資金安全保障形成了巨大的挑戰。下面咱們列舉了一些系統平常運行過程當中出現的問題。網絡

能夠看出，這些都是一些上下游交互的邊界場景，以及遇到的問題。固然不只限於這些場景，凡有系統交互、數據交互邊界的場景，都會出現此類問題，咱們稱之爲「一致性問題」。經粗略統計，咱們清結算系統創建以來有70%左右的問題都屬於一致性問題。架構

致使一致性問題的緣由有不少，諸如：併發

冪等、併發控制不當。
基礎環境故障：好比網絡、數據庫、消息中間將發生故障。
其餘代碼bug。

目前配送的日結算金額已達到千萬級別，每一個一致性問題都有可能給咱們整個美團點評形成巨大的損失。所以如何解決系統的一致性問題成爲咱們保障資金安全的重中之重。關於一致性問題，業內已經論述的很是成熟了，搜索引擎中搜索「一致性問題」，隨處可見此概念的定義、問題闡述、意義以及解決思路，諸如：異步

強一致性協議: 兩階段提交、三階段提交、TCC (Try-Confirm-Cancel)等

最終一致性: 主動輪詢、異步確保、可靠消息、消息事務等

這些手段的目標都是在事中避免問題的發生。可是在實際場景中，不管是系統的內部邏輯仍是外部環境都十分複雜多變、不可預知，咱們很難徹底避免問題。所以過後對於問題數據的發現以及修復就顯得尤其重要。這些也正是咱們這篇文章要論述的「對帳」的核心使命。咱們力求總結對帳領域內最專業的思路和方法，並結合自身的業務特色，建設配送清結算的對帳體系，構築配送資金安全的堅固防線。在系統的整個構建過程當中咱們主要圍繞如下幾個目標：分佈式

場景覆蓋的完整性：無死角覆蓋清結算業務涉及的各個場景。
問題發現的準確性：可以準確的發現問題，保證不漏報，不誤報。
問題處理的實時性：儘量縮短問題處理的週期，極力避免可能形成的損失。

下面開始正式介紹美團配送清結算對帳體系的構建經驗。工具

對帳的定義

對帳的概念隨着金融、互聯網行業的發展，定義上也經歷了幾個階段的變化，以下：學習

stage 1 ：對帳最初來源於***會計覈算***，是爲保證帳簿記錄正確可靠，對帳簿中的相關數據進行檢查和核對的工做。
stage 2 ：隨着***互聯網金融或電商***行業的發展，對帳也擴大了應用範圍，這一時期，對帳是指在固定週期內，支付使用方和支付提供方（銀行和第三方支付）相互確認交易、資金的正確性，保證雙方的交易、資金一致正確。
stage 3 ：從廣義來看，***全部的跨端系統***之間的數據覈對都應該叫對帳，主要是檢查和發現數據在流轉過程當中的不一致問題。一般分爲信息流的核對和資金流的核對。信息流覈對主要是對業務數據之間的核對，資金流是對資金交易數據進行覈對。

對帳系統的構建思路

系統概況

配送結算作爲核心交易履約系統，上游對接了訂單、獎懲、活動等十多個外部系統，下游又承擔了對接支付平臺、財務系統的職責，不只「承上啓下」，並且涉及業務複雜。而系統內部又歷經訂價、計費（清算）、記帳、彙總帳單、付款等多個環節，系統的高度複雜性給對帳的全面性和準確性形成了極大的困難，如圖：

爲了系統更加專業化的實現對帳、作好對帳，咱們對支付、清結算等資金領域進行了體系化的調研和學習，並結合業務的自身的特色，總結了一套對帳系統構建的思路方法，並基於該思路進行了較完整的系統化實現。

設計思路

從總體來看，按照時序維度的前後，系統對帳主要分爲三階段的工做。分別是***數據準備***、數據覈對***和***差錯處理。在對帳專業概念中，數據覈對和差錯處理又叫***軋帳***和***平帳***。三個環節緊密相連，從前期準備、問題發現、問題處理三個角度展開對帳工做。

數據準備

數據準備，顧名思義，咱們須要把對帳所需的所有數據，接入到咱們的對帳系統。該模塊主要實現兩個目標：

爲不一樣的外部系統提供多元化的接入機制。
經過數據適配的手段把外部數據以統一的格式進行轉換和存儲。

在數據接入層，咱們會針對不一樣的數據接入方提供三種不一樣的數據接入模式。

數據拉取：咱們主動拉取數據，並經過數據適配的方式，將數據存儲到對帳數據池中。
數據推送：由數據接入方將數據經過ETL（Extract-Transform-Load）等方式直接推送到咱們的對帳數據池中，數據格式由數據接入方自行適配。
文件上傳：咱們會提供標準的文件模板，由數據接入方填充數據，經過文件上傳的方式將數據接入到咱們的數據池。

其中第二種方式是咱們最優選擇的，由於數據推送這種形式對於數據接入方來講只須要一次性編寫相關的代碼，按期運行，一勞永逸，減小了人工上傳的成本。對於咱們結算來講，也不須要感知對方的數據格式以及業務邏輯。

數據覈對（軋帳）

數據覈對是對帳中最核心的一個階段。其目標是發現問題數據。數據覈對階段咱們的兩個目標是保障數據覈對的***覆蓋度***和***準確性***。通過總結和梳理，數據覈對過程能夠分爲如下5個環節。

1. 問題梳理

因爲數據覈對的目標是發現問題，那麼咱們進行數據覈對就要從問題出發，首先明確咱們要經過對帳發現哪些問題，只有這樣才能保證數據覈對的覆蓋度。通過梳理，咱們發如今數據流轉中過程當中數據的不一致問題能夠統一歸結爲三類，分別是***漏結***、重複結、錯結。咱們能夠從這三個角度去統一進行問題梳理。下面介紹一下這三種錯誤類型的具體含義。

漏結：發起方有數據，而接收方沒有數據。舉個例子，目前清結算系統會在訂單送達時給騎手結算。若是訂單的狀態是送達，而沒有給騎手生成對應的結算數據。就是一種典型的漏結算場景。
重複結：接收方重複處理。仍是上面的例子，若是訂單送達，給騎手結算了兩次，產生了重複的結算數據，就是重複結算。
錯結：發起方和接受方數據不一致。通常會發生在金額和狀態兩個字段。好比說訂單上的數據是用戶加小費3元。結算這邊只產生了2元的小費結算數據，就是錯結。

2. 對帳方式

對帳方式主要分爲兩種，單向對帳***和***雙向對帳。

單向對帳：以一方數據爲基準進行對帳。好比結算跟支付平臺，以結算數據爲基準和支付平臺覈對，用來發現結算數據爲支付成功，支付平臺支付失敗等問題。
雙向對帳：以雙方的數據互爲基準對帳。既要保證結算數據爲成功的，支付平臺也要成功，又要保證支付平臺數據爲成功的，結算數據也要成功。

顯而易見，雙向對帳更可以全面的發現問題。所以在條件容許的狀況下，咱們會優先選擇雙向對帳。

3. 對帳粒度

對帳粒度也分爲兩種，分別是***明細對帳***和***總數對帳***。

明細對帳：對雙方的每條數據依次進行比對。它的優勢是能夠準肯定位問題數據。缺點是對帳口徑的設計比較複雜。由於咱們須要同時針對漏、重、錯三種錯誤類別設計不一樣的對帳口徑，同時還要考慮到業務的邊緣場景。稍有不慎，就會影響對帳的準確性。
總數對帳：選擇一個維度，進行總數級別的對帳。總數級別的對帳好處是對帳口徑的設計比較簡單，能夠快速實現，不易出錯。缺點就是沒法定位問題數據，一旦對帳發現問題。還須要進一步尋找問題數據。

所以，推薦的作法應該是以明細對帳爲主，定位具體問題。以總數對帳爲輔，對明細對帳的結果進行復核兜底。

4. 對帳口徑

對帳口徑，也就是具體的對帳邏輯的設計。咱們會提供固定的***對帳模板***，供不一樣的對帳場景選取。若是某些特殊場景對帳模板不能覆蓋，也能夠採起對帳邏輯***自定義***的方式進行對帳。通過總結咱們發現，對帳的形式無非就是兩方比對和自身異常檢測兩種。兩方比對又能夠細分爲一對1、多對1、一對多。比對方法也主要是分爲條目匹配和金額匹配。自身異常檢測主要是重複性和異常狀態的檢測。咱們把這些通用的對帳邏輯模板化，減小重複的開發工做。

5. 對帳時機

數據覈對的最後一步就是對帳時機的選擇。分爲***離線對帳***和***在線對帳***。離線對帳主要是經過固定的週期進行對帳。最短週期爲Ｔ＋１。它的好處是適用性較強，基本能夠覆蓋全部的對帳場景。而在線對帳又分爲***實時對帳***和***準實時對帳***。實時對帳和準實時對帳的區別主要是實時對帳耦合在結算鏈路中，能夠在發現問題數據時，對結算流程進行攔截，而準實時對帳是異步進行的，不具有攔截能力。在線對帳有必定的侷限性，一方面它依賴於對帳數據是否能實時的準備好，另外一方面也比較佔用系統資源。所以咱們的作法應該是以週期對帳爲主，在某些實時性要求比較高，且條件知足的場景使用在線對帳。

差錯處理（平帳）

差錯處理主要是對數據覈對過程當中發現的問題數據進行處理。咱們會創建一個統一結構的差錯記錄，將數據覈對發現的問題進行統一存儲。差錯記錄中的數據會進行二次覈對，避免因爲日切等緣由形成的問題錯報。對於那些真實存在問題的數據咱們會提供兩種解決模式，若是是常見的問題，且有一套標準的解決方案的話，咱們會把它系統化，採起系統自動修復的方式；若是系統沒法自動修復，那麼咱們會進行系統報警，並進行人工處理。

對帳系統設計實現

整體架構

綜上所述，對帳體系的總體架構，分爲三個模塊，分別是離線對帳平臺，在線對帳平臺和平帳中心。徹底是按照咱們上面的對帳思路設計的。三個模塊互相協做，一體化的完成數據準備、數據覈對、問題處理三部分工做。因爲咱們整個清結算系統是圍繞不一樣的費用項創建的，所以費用項也是咱們設計對帳、執行的對帳一個最小粒度的單元。

具體介紹下三個模塊：

離線對帳模塊

離線對帳分爲三個子模塊，分別是數據接入層、對帳管理層和對帳執行層。

在數據接入層咱們提供拉取和推送兩種模式，經歷一個數據適配的過程，將數據存儲到咱們統一的對帳數據池當中。

在對帳管理層當中，咱們抽象出了一個對帳場景的概念，咱們基於對帳場景進行對帳屬性的配置：首先要選取對帳雙方的數據源；而後進行對帳口徑編輯，這裏提供了自定義和模板選擇兩種方式；最後配置對帳的週期。這裏咱們是經過cron表達式來進行週期配置的。

在對帳執行層，咱們會拉取對帳數據池和對帳核心配置中的相關數據，經歷配置解析，數據抽取，策略執行的過程，最終輸出對帳結果。

在線對帳模塊

下圖左邊是在線對帳平臺的架構圖，右邊是在線對帳的實例。咱們經過RPC、監聽消息隊列(MQ)、監聽數據庫binlog三種方式進行對帳接入。在線對帳平臺分爲管理層和執行層。管理層主要是承擔策略編輯、策略綁定和攔截管理的相關工做。而執行層分爲異步（準實時）對帳和同步（實時）對帳兩個模塊。

右邊兩圖分別是分別是異步對帳和同步對帳的實例。在異步對帳的實例中，是運單和結算單元的對帳。

運單是什麼？對應外賣訂單，做爲配送內部的基礎交易數據。

結算單元是什麼？清結算系統內部的模型，和運單是一對一關係，記錄運單各個節點的結算狀態。

①異步對帳：咱們分別監聽運單和結算單元的Binlog，經過Kafka->Storm的經典架構，進行對帳策略的執行。實際的流程比較複雜，這裏只是一張簡圖，大概就是：（細節能夠忽略）

收單運單消息後，咱們會把對於的運單以List的形式存儲到Squirrel(Redis)中，當結算消息來了之後，就把對應運單記錄Delete掉。若是有運單記錄一直停留在List當中，也就是說明結算消息沒有來，應該是發生了漏結算。咱們經過過定時任務輪詢運單List將問題數據輸出。

②同步對帳：示例中是結算內部的流程，經歷結算單、帳單、付款幾個流程。由於付款是最後一個流程，若是這個時候數據存在問題，那麼就會形成實際的資金損失。所以咱們會在付款環節以前，對前面的數據進行對帳。若是發現帳單和結算單的數據不一致，咱們就會進行數據攔截。

差錯處理模塊

在差錯處理階段，咱們會創建一個統一的差錯記錄模型，核心字段包括***對帳場景、對帳批次，數據來源，錯誤類型編碼和數據處理狀態***等。經過定時任務按期輪詢差錯記錄的方式發起差錯處理流程：首先對差錯記錄的數據進行二次覈對，若是二次覈對確認這條數據並無問題，咱們就會回更差錯記錄的處理狀態。若是二次覈對發現數據確實有問題。咱們會提供兩種處理模式。一種是經過系統的手段自動修復。另一種是經過報警的方式，人爲介入。此外咱們還創建了一個問題的人工處理模塊。能夠對一次結算流程的整個生命週期進行回放，並針對特定場景提供一鍵修復的能力。