背景

今天給大家分享一個話題，就是對于線上跟錢有關的計費類的系統(tǒng)，在線上可能出現(xiàn)的一些把錢算錯的問題，以及我們如何來設計架構解決這些問題。

但凡是跟算錢相關的系統(tǒng)，都是每個公司的重中之重，比如說價格系統(tǒng)、運費系統(tǒng)、計費系統(tǒng)、支付系統(tǒng)、基金系統(tǒng)、財務系統(tǒng)、結算系統(tǒng)等等，因為這些系統(tǒng)運行過程中，隨時可能因為技術問題或者運營的人為誤操作問題，把錢給算錯了。

所以今天來給大家講講這一類跟算錢有關的系統(tǒng)，我們應該如何來保證他不會把錢給算錯呢?

計費業(yè)務系統(tǒng)架構設計

業(yè)務場景引入

首先，我們先來引入一個業(yè)務場景，假設我們現(xiàn)在有 B 端、M 端和 C 端三個系統(tǒng)。

其中 B 端可以由商家/入駐客戶/供應商/合作伙伴這一類 B 端角色對自己的一些計費規(guī)則進行設置和調整，M 端是是公司的運營可以進行統(tǒng)一的基礎性計費規(guī)則調整，C 端是面向用戶的，在處理一些請求的時候，會根據(jù) B 端和 M 端的計費規(guī)則進行計算，算出當前的支付金額。

如下圖：

這個時候可能你說了，這看起來沒啥問題啊，不就在平臺層和商家層允許修改計費規(guī)則，然后c端系統(tǒng)實時根據(jù)兩個系統(tǒng)的計費規(guī)則計算費用么。

真的是這樣嗎?上面那套計費模型里，看著簡單，其實蘊藏著大量的問題，下面來給大家一一說明。

業(yè)務系統(tǒng)消息同步丟失

首先，因為歷史原因，上述計費模型會非常的復雜，不是我們看起來那么的簡單。

實際上，B 端系統(tǒng)每次修改完了計費規(guī)則以后，是要把計費規(guī)則通過 MQ 同步給 M 端系統(tǒng)的，然后 M 端系統(tǒng)會匯總 B 端系統(tǒng)的所有商家的計費規(guī)則，接著后續(xù) C 端系統(tǒng)在計費的時候，是調用 M 端系統(tǒng)的接口拉取所有需要的計費規(guī)則來進行計算的。

如下圖所示：

單單就上圖這一個架構，就可能會讓我們在計費的時候可能因為一些技術原因出現(xiàn)問題。

比如說最典型的就是，不管因為什么，B 端系統(tǒng)那里修改了計費規(guī)則以后，可能因為網(wǎng)絡原因、MQ 故障、代碼 bug 等各種原因，并沒有同步到 M 端系統(tǒng)那里去，這就會導致 C 端系統(tǒng)一直用老的計費規(guī)則在計費。

嚴格來說，這就已經(jīng)導致計費錯誤了。

如下圖所示：

這還僅僅只是同步問題導致的計費錯誤而已，其實還有更加麻煩的一個問題，那就是當 M 端系統(tǒng)收到了 B 端系統(tǒng)同步過來的計費規(guī)則了以后，他可能會陸續(xù)把復雜的計費規(guī)則寫入多個數(shù)據(jù)存儲中。

沒錯，你沒看錯，有可能 M 端系統(tǒng)會用異構數(shù)據(jù)存儲架構，來存放不同的計費規(guī)則，比如 MySQL、MongoDB，等等。

如下圖：

計費業(yè)務系統(tǒng)計費問題

這個時候可能會出現(xiàn)一個問題，那就是 C 端系統(tǒng)可能會在你的一次計費規(guī)則同步的過程中，就從你 M 端系統(tǒng)這里來查詢各種計費規(guī)則來進行計費。

但是這個時候有可能會出現(xiàn)一個問題，那就是 MongoDB 里可能已經(jīng)是最新的計費規(guī)則，而從 MySQL 里查出來的還是老的計費規(guī)則，也就是說，完全可能會出現(xiàn)，用了不一致的計費規(guī)則來進行計費。

比如下圖：

這是第二個可能出現(xiàn)計費錯誤的場景，第一個計費規(guī)則同步失敗和第二個計費規(guī)則并發(fā)讀寫，都是技術類的問題。

第三個計費錯誤的場景，就是我們的商家或者自己的運營，手欠甚至手抽，把計費規(guī)則改成了非常離譜的錯誤。

比如說，某一個計費規(guī)則正常基準金額是百元級別的，但是他給改成了幾塊錢，這可能會導致公司出現(xiàn)嚴重的損失。

如下圖：

所有這一切問題，都可能會導致計費的錯誤，那么說到這里，大家是不是想說，那還不簡單，case by case 的優(yōu)化和處理不就完了。

比如說對 B 端和 M 端系統(tǒng)進行大范圍的加固，實現(xiàn) MQ 消息不丟失保障機制，對 M 端系統(tǒng)異構存儲寫入和讀取，加個分布式鎖，寫入的時候不能讀取，讀取的時候不能寫入，對運營修改計費規(guī)則的時候進行校驗，加入各種校驗規(guī)則，亂改就不讓你通過。

沒錯，大家說的這些其實都可以，但是不知道大家想過一個問題沒有，對于真正復雜的公司級系統(tǒng)，比如上述的 B 端系統(tǒng)，看起來在圖里僅僅是一個框而已。

其實一家公司里可能是幾十個人維護的大平臺，M 端系統(tǒng)也是同理，所以如果要推動各方實現(xiàn)各種技術方案來做保障，首先在跨部門推動方面成本就是很高的。

這僅僅是其一，其二，就是你現(xiàn)在做了一些措施做了加強，但是不代表以后就不會有新的問題了。

比如說，你對 MQ 同步實現(xiàn)了消息不丟失方案，可是哪一天如果 MQ 掛了呢?

比如說，你如果在 M 端系統(tǒng)實現(xiàn)寫入和讀取加分布式鎖做互斥，那可能會導致并發(fā)性能大幅度的降低。

比如說，你給計費規(guī)則修改加入校驗規(guī)則，可是隨著計費規(guī)則不停的變化，很可能會導致你的校驗規(guī)則失效，或者要持續(xù)不斷的加入更多新的校驗規(guī)則。

如下圖：

計費業(yè)務數(shù)據(jù)補償系統(tǒng)設計

所有這一切其實都是治標不治本，對于這一類線上跟錢相關的，固然應該在技術和業(yè)務上嚴防死守，但是這都依賴技術團隊的技術素養(yǎng)，以及對業(yè)務校驗規(guī)則的持續(xù)維護，如果想要一勞永逸，那么通常我們會引入一套計費數(shù)據(jù)補償系統(tǒng)。

這個計費數(shù)據(jù)補償系統(tǒng)，是額外獨立開發(fā)的，我們來看看，用這個系統(tǒng)我們會實現(xiàn)哪些功能來解決剛才看到的那些問題。

首先，從本質上來說，我們不管具體的 B 端和 M 端的代碼邏輯是如何寫的，第一個有一點是可以肯定的，那就是 B 端和 M 端是需要實現(xiàn)數(shù)據(jù)同步和最終一致的。

所以說，我們不管他們之間是通過 MQ 來同步或者是什么，我們可以直接監(jiān)聽 B 端和 M 端系統(tǒng)的數(shù)據(jù)存儲，通過定時拉取數(shù)據(jù)來實現(xiàn)比對，如果一旦發(fā)現(xiàn)兩邊數(shù)據(jù)不一致，則自動實現(xiàn)補償。

如下圖：

接著我們再來看第二個問題，不管你的 M 端計費規(guī)則的寫入和查詢邏輯如何，最大的問題就是你的某一次計費結果可能并沒有按照一致和正確的計費規(guī)則來進行。

所以說，我們的計費數(shù)據(jù)補償系統(tǒng)可以直接讓 C 端系統(tǒng)的計費接口把每次計費請求的日志上報給我們。

接著我們可以同時把 M 端系統(tǒng)的每一次計費規(guī)則的查詢和修改日志也上報給我們，我們可以把相關日志數(shù)據(jù)存儲到大數(shù)據(jù)系統(tǒng)中。

接著我們就可以基于大數(shù)據(jù)技術來進行相關系統(tǒng)的日志運算，檢查一下每一次計費運算查詢多個規(guī)則的時候，是否出現(xiàn)了多個規(guī)則在短時間內先后修改，然后導致使用了不一致的規(guī)則來計算的問題。

如下圖所示：

最后就是對于運營可能誤操作改錯計費規(guī)則的問題，我們可以拉取 C 端系統(tǒng)的每一次計費結果，然后對計費結果我們可以進行環(huán)比比對校驗。

就是說，你每一次計費結果都可以更過去的類似的計費結果進行比對，如果說差距過大，超過了 50% 的話，那么就會自動發(fā)送告警給運營，提醒他可能出現(xiàn)了計費額規(guī)則誤操作的問題。

如下圖所示：

總結

通過上述的計費數(shù)據(jù)補償系統(tǒng)，就可以直接繞開所有的具體計費規(guī)則和計費邏輯，跟 C 端系統(tǒng)、B 端系統(tǒng)、M 端系統(tǒng)完全解耦。

采用自行拉取數(shù)據(jù)、拉取日志、拉取計費結果等手段，用大數(shù)據(jù)一類的技術進行各種檢測，從根本上解決問題，以此來實現(xiàn)線上計費系統(tǒng)因為技術問題或者誤操作問題導致的計費錯誤。