摘要：業(yè)務(wù)對賬平臺的核心目的，就是及時發(fā)現(xiàn)類似問題，并及時修復(fù)。這對對賬平臺的吞吐量造成了挑戰(zhàn)。五健康度對賬中心可以拿到業(yè)務(wù)系統(tǒng)及其所在整個鏈路的數(shù)據(jù)一致性信息。在分布式環(huán)境下，沒有人能回避數(shù)據(jù)一致性問題，我們對此充滿著敬畏。

根據(jù)CAP原理，分布式系統(tǒng)無法在保證了可用性（Availability）和分區(qū)容忍性（Partition）之后，繼續(xù)保證一致性（Consistency）。我們認(rèn)為，只要存在網(wǎng)絡(luò)調(diào)用，就會存在調(diào)用失敗的可能，系統(tǒng)之間必然存在著長或短的不一致狀態(tài)。在服務(wù)化流行的今天，怎樣及時發(fā)現(xiàn)系統(tǒng)服務(wù)間的不一致狀態(tài)，以及怎樣去量化衡量一個系統(tǒng)的數(shù)據(jù)一致性，成為每個分布式環(huán)境下的開發(fā)者需要考慮并解決的問題。

以交易鏈路為例，存在著如下一些潛在的不一致場景：

訂單支付成功了，但是訂單狀態(tài)卻還是“待付款”

物流已經(jīng)發(fā)貨了，但是訂單上面還是“待發(fā)貨”

銀行退款已經(jīng)到賬了，但是訂單上面還是“退款中”

訂單發(fā)貨已經(jīng)超過7天了，但是卻沒有自動完成

…

上述每個業(yè)務(wù)場景，都可能產(chǎn)生用戶反饋，給用戶帶來困擾。業(yè)務(wù)對賬平臺的核心目的，就是及時發(fā)現(xiàn)類似問題，并及時修復(fù)。使問題在反饋前即被提前處理。

那么一個業(yè)務(wù)對賬平臺，會面臨著哪些挑戰(zhàn)？

我們對于一個業(yè)務(wù)對賬平臺的核心訴求，主要包括要方便業(yè)務(wù)系統(tǒng)快速接入，要能處理業(yè)務(wù)方海量的數(shù)據(jù)，并保證一定的實時性。這會深刻影響業(yè)務(wù)對賬平臺的系統(tǒng)設(shè)計。

從局部到整體，本文先從解決上面三個問題的角度，來看有贊業(yè)務(wù)對賬平臺的局部設(shè)計，再來看整體系統(tǒng)結(jié)構(gòu)。

我們認(rèn)為所有的對賬流程，都可以分解為“數(shù)據(jù)加載”、“轉(zhuǎn)換解析”、“對比”、“結(jié)果處理”這 4 步。為了適應(yīng)多樣化的業(yè)務(wù)場景，其中的每一步都需要做到可編排，放置各種差異化的執(zhí)行組件。在每一個流程節(jié)點，需要通過規(guī)則可以自由選擇嵌入哪個組件。其次，需要把數(shù)據(jù)從原始格式，轉(zhuǎn)換到對賬的標(biāo)準(zhǔn)格式（基于標(biāo)準(zhǔn)格式，就能做標(biāo)準(zhǔn)的通用對比器）?？偨Y(jié)起來，我們認(rèn)為對賬引擎需要具備以下的能力：

流程編排能力

規(guī)則能力

插件化接入能力

目前業(yè)務(wù)對賬平臺的對賬引擎結(jié)構(gòu)如下：

其中的 ResourceLoader 、 Parser 、 Checker 、 ResultHandler 均為標(biāo)準(zhǔn)接口，所有實現(xiàn)了對應(yīng)接口的 spring bean ，都能被編排到對賬流程之中，包括業(yè)務(wù)方自己實現(xiàn)的 plugin。這樣就實現(xiàn)了插件化和可編排。每個流程節(jié)點的功能如下：

ResourceLoader ：基于各種數(shù)據(jù)源（DB、FILE、RPC、REST等）提供加載器工廠，加載各個數(shù)據(jù)源的原始數(shù)據(jù)。加載的方式支持驅(qū)動加載、并行加載、多方加載等方式。業(yè)務(wù)方也可以自己實現(xiàn)加載器，利用流程編排能力嵌入到對賬流程中。

Parser ：對已加載的原始數(shù)據(jù)進(jìn)行建模，轉(zhuǎn)換為對賬標(biāo)準(zhǔn)模型。利用規(guī)則引擎，提供腳本化（Groovy）的轉(zhuǎn)換方式。

Checker ：按照配置對指定字段、按指定規(guī)則進(jìn)行比較，并產(chǎn)生對賬結(jié)果。支持 findFirst（找出第一個不一致）、full（找出所有不一致）等對比策略。

ResultHandler ：使用指定的handler對結(jié)果進(jìn)行處理，常見的處理器包括持久化、發(fā)送報警郵件、甚至直接修復(fù)數(shù)據(jù)等等。

通過統(tǒng)一的 facade，將整個對賬流程進(jìn)行串聯(lián)。在執(zhí)行不同節(jié)點時，根據(jù)配置選擇不同的默認(rèn)組件或者插件來執(zhí)行。可以在管理后臺，對每個流程節(jié)點進(jìn)行編排：

一些離線定時對賬場景，單次對賬的數(shù)據(jù)量可能達(dá)到百萬級，甚至千萬級。這對對賬平臺的吞吐量造成了挑戰(zhàn)。我們面對海量數(shù)據(jù)問題的通常解決思路，就是“拆”。分布式任務(wù)拆分+單機(jī)內(nèi)任務(wù)拆分，將數(shù)據(jù)塊變小。同時，也可以利用一些大數(shù)據(jù)的工具來幫我們減輕負(fù)擔(dān)。

目前的對賬有 2 種模式：一種常規(guī)模式，是通過數(shù)據(jù)平臺（包含了所有要進(jìn)行對賬的原始主鍵數(shù)據(jù)，如訂單號）將數(shù)據(jù) push 到對賬中心的 DB ，然后訂單中心集群通過分片策略，并按分頁分批加載，加載數(shù)據(jù)進(jìn)行對比。另一種，則是當(dāng)數(shù)據(jù)量超過千萬時，利用數(shù)據(jù)平臺的 spark 引擎從 hive 表中獲取數(shù)據(jù)，然后投遞到 nsq（自研消息隊列）。nsq 會選擇其中一個 consumer 進(jìn)行投遞（不會投遞到多個consumer）。這樣千萬級的數(shù)據(jù)會變成消息被分散的對賬服務(wù)器執(zhí)行。

對賬任務(wù)一般會選擇在業(yè)務(wù)量較小的凌晨進(jìn)行，是因為在對賬過程中會需要通過反查業(yè)務(wù)接口，來獲取實時數(shù)據(jù)。而更好的情況是，對賬時能去除對業(yè)務(wù)接口的反查。因此，會需要對業(yè)務(wù)數(shù)據(jù)進(jìn)行準(zhǔn)實時同步，提前進(jìn)入對賬中心的 DB 集群。

主要思路是基于業(yè)務(wù) DB 的 binlog 日志或者業(yè)務(wù)系統(tǒng)自身的消息，進(jìn)行數(shù)據(jù)同步。后續(xù)流程則類似。

一些特定的業(yè)務(wù)場景，比如買家已經(jīng)付款成功了，但是由于銀行第三方的支付狀態(tài)回調(diào)延遲，導(dǎo)致訂單狀態(tài)還是待付款。這種情況，買家會比較焦急，可能產(chǎn)生投訴。面對這樣一些場景，就需要進(jìn)行實時對賬，也可以叫做秒級對賬。

秒級對賬往往基于業(yè)務(wù)消息進(jìn)行觸發(fā)，需要在事件觸發(fā)后的短時間內(nèi)執(zhí)行完對賬任務(wù)。且事件消息的觸發(fā)，往往具有高并發(fā)的特點，因此需要相應(yīng)的架構(gòu)來進(jìn)行支持。

設(shè)計中主要加入了 EventPool 來緩沖處理高并發(fā)的事件消息，并加入限流、取樣、路由、處理的 pipeline。同時在進(jìn)入事件處理線程池之前，需要進(jìn)入阻塞隊列，避免大量的請求直接耗盡線程資源，同時實現(xiàn)事件處理的異步化。處理線程批量定時從阻塞隊列獲取任務(wù)來執(zhí)行。同時，利用延遲阻塞隊列，還可以實現(xiàn)延遲對賬的特性。（我們認(rèn)為出現(xiàn)不一致的情況時，如果立即去進(jìn)行對比，往往還是不一致的。所以就需要根據(jù)情況，在事件發(fā)生后的一段時間內(nèi)，再觸發(fā)對比）

上面介紹了業(yè)務(wù)對賬平臺的各個局部設(shè)計，下面來看下整體結(jié)構(gòu)。

整體上主要采用調(diào)度層+對賬引擎(core+plugin)+基礎(chǔ)設(shè)施的分層架構(gòu)。調(diào)度層主要負(fù)責(zé)任務(wù)觸發(fā)、任務(wù)拆分、調(diào)度；對賬引擎則負(fù)責(zé)執(zhí)行可編排的對賬流程；基礎(chǔ)設(shè)置層則提供規(guī)則引擎、流程引擎、泛化調(diào)用、監(jiān)控等基礎(chǔ)能力。

對賬中心可以拿到業(yè)務(wù)系統(tǒng)及其所在整個鏈路的數(shù)據(jù)一致性信息。基于此，對賬平臺具備了給予業(yè)務(wù)系統(tǒng)和鏈路健康度反饋的能力。

前面有提到，對賬的流程被拆分為四個固定的流程節(jié)點，且有四個對應(yīng)的標(biāo)準(zhǔn)接口。通過流程引擎和規(guī)則引擎的能力，可以根據(jù) spring bean name，來將系統(tǒng)默認(rèn)組件或者插件編排到對賬流程之中?；谶@種開放性的設(shè)計，業(yè)務(wù)對賬平臺支持與業(yè)務(wù)團(tuán)隊進(jìn)行共建。

首先，對賬平臺提供標(biāo)準(zhǔn)接口的 API jar 包，業(yè)務(wù)方通過引入 jar，實現(xiàn)相關(guān)接口，并將 impl 打包。這樣，對賬平臺通過 spi 的方式，可以引入業(yè)務(wù)方的插件包，并加載到對賬中心的 JVM 中執(zhí)行。

業(yè)務(wù)對賬平臺，是面向業(yè)務(wù)場景建立，但同時屬于數(shù)據(jù)密集型應(yīng)用。平臺上線以來，已經(jīng)接入公司各團(tuán)隊數(shù)十個對賬任務(wù)，每天處理千萬級的數(shù)據(jù)。展望未來，業(yè)務(wù)對賬平臺的使命會從主要進(jìn)行離線數(shù)據(jù)分析處理，演進(jìn)到利用應(yīng)用系統(tǒng)的健康度數(shù)據(jù)幫助系統(tǒng)進(jìn)行實時調(diào)整的方向。在分布式環(huán)境下，沒有人能回避數(shù)據(jù)一致性問題，我們對此充滿著敬畏。歡迎聯(lián)系 [email protected]，交流心得。