目錄

• 前言

• 到家運費系統簡介

• BCS設計與實踐

• 總結與展望

前言

任何系統在需求迭代過程中都會產生一定BUG，幾乎所有BUG都會在功能上線前發現修復，但是難免會有漏網之魚。寫出BUG并不可怕，可怕的是寫出的BUG都沒有及時被發現，等BUG引爆出來的時候已造成巨大資金虧損。如何在系統出現問題前或問題出現后及時發現解決，這個問題是運費團隊一直思考的問題。雖然所在團隊制定一系列制度來避免此類的發生，但是仍然無法完全避免此類問題的出現。

到家運費團隊結合目前運費業務場景和系統痛點設計出一套運費BCS系統(業務校驗系統)來保障系統穩定。目前線上出現問題后可快速被發現，如數據異構改造引發的數據不一致、計算邏輯錯誤造成的資金虧損、運營誤操作造成的資金虧損等一系列問題。

到家運費業務簡介

【運費基礎業務】

到家運費系統主要分為B端和C端兩種業務。

B端業務分為商家端和平臺運營端，商家端由商家運營去配置門店運費基礎信息和運費促銷活動。運營端由到家運營設置運費規則信息。

C端業務是基于運費規則對訂單進行實時運費計算。

【運費共建業務】

到家運費系統除了提供支撐到家內部業務能力外同樣對京東主站融合共建類業務提供支持。其中主要代表業務為小時購共建業務，用戶可在京東商城小時購模塊區域通過門店結算下單，到家運費系統為業務共建提供運費規則計算所需要的數據。小時購數據由到家B端入口管理配置，修改后通過數據同步方式傳遞到京東主站運費系統。

BCS設計與實踐

運費BCS系統基于現有業務總結出多種校驗模式，不同校驗模式有著相應的適用場景。

【同源異構數據的一致性問題校驗】

主要適用校驗場景：

• 多端垂直接入，漏測率高。

• 回溯計算邏輯上下文場景。

【業務邏輯的正確性校驗】

主要適用校驗場景：

• 運營誤操作。

• 業務漏洞或技術漏洞。

同源異構數據的一致性問題校驗

主要實現原理：

采取校驗的方式為最終一致校驗，規避入口和中間流程的繁瑣復雜，通過結果反向驗證整個流程是否存在問題。

同源異構數據的一致性問題校驗主要體現在到家運費系統中小時購業務處理。小時購業務每次需求迭代都需要特別考慮幾個點，一旦這幾個點出問題不但會產生數據不一致并且不好被快速發現。問題點如下：

• 業務數據變更主要來源于B端業務，但是B端修改數據的入口較多（如開放平臺、商家中心等），而且每個入口數據變更方式也同樣多樣化（如單條新增、批量修改、刪除等），有時候一個功能迭代可能涉及到多個模塊的修改，如果測試和開發有所遺漏就會出現一定問題，這種情況對于跟錢打交道的核心系統來說是不會被允許的，目前這種需求處理的方式無外乎就是靠著文檔梳理、產品研發測試對業務熟悉程度進行規避，但是杯水車薪。這種流程依舊存在巨大隱患，無論是在對接初期還是后期的功能迭代中總容易遺漏功能改造點。

• 部分業務流程節點多且邏輯復雜，并且流轉到最后節點涉及數據量很難預知。小時購運費數據可以針對不同方式對運費數據變更，因為運費配置模版生效是有優先級的，會根據命中的運費模版實時計算出不同的運費信息。如果調整某個城市下的運費，那么涉及到的門店和其命中運費模版數據很難被提前預知出來，并且期間會經過多次數據拆分轉換，先查詢出城市下所有門店，然后調用多個服務批量補全同步所需要的數據（數據過多需要多次補全），最終同步到京東主站運費系統。其中一個步驟出現問題都會造成部分數據丟失未同步。

具體實現方式：

模式核心是通過反向校驗（最終一致性校驗）方式對數據進行校驗，從而規避需要考慮正向流程中繁多的業務入口、復雜的同步流程等場景，只需要比較到家存儲數據與京東主站運費數據是否一致即可。什么時候去觸發校驗是一個需要考慮的重要點，總結出兩套方案如下：

進行綜合考慮最終決定使用第二套方案，校驗邏輯可以完全獨立原業務外，并且原系統不會產生任何接入成本。功能圖如下：

任務發布者：周期性獲取小時購全量門店數據并放入到任務池中，待任務執行器校驗門店數據是否一致。

任務池：存放待校驗京東到家與京東主站運費數據的門店id。

任務執行器：實時拉取到家和京東運費數據，并選擇提供的校驗規則去校驗數據一致情況。

數據一致校驗模式還提供一個可視化查詢界面方便查看數據一致情況，并且方便定位查詢出同步產生問題點。如果到家運費信息調整后因系統問題未同步至京東主站運費系統中，除報警通知外可以在該界面查詢出具體什么信息不同步，問題確定后可以手動同步修正數據。

業務邏輯的正確性校驗

主要實現原理

采取校驗的方式是收集業務數據并根據配置的校驗規則進行業務合理校驗。

主要實現方式是在運費項目中集成數據采集端，將一套完整業務涉及的相關的業務數據進行串聯，將串聯后的數據發送到數據采集端。目前數據采集端基于接口業務數據采集，使用注解AOP實現方式。通過收集影響運費計算的源數據，依靠http協議進行實時上報，發送過程使用異步線程池，如果期間待發送任務達到閾值后丟棄新產生的任務，通過這些流程最終完成數據上報流程。

業務數據在運費BCS系統進行收集，收集到的數據進行邏輯聚合，拆解根據配置好的校驗規則去做業務校驗，相關的數據可用于核心計算流程查詢分析，同樣也可以為人工排查提供依據。

具體應用方式：

通過BCS數據采集端采集數據后就可以使用這些數據去做校驗，針對需要校驗不同業務場景功能實現有一定差別，具體如下。

總結與展望

運費BCS系統是基于現有運費業務提煉出來的可擴展校驗系統，從上線至今已幫助運費解決不少問題其中不缺乏生產環境的隱藏雷點。運費BCS系統仍處于摸索階段還有很多計劃中的功能待實現，如支持更靈活的規則配置和校驗、報警精確化、問題數據自動訂正處理等。