公司有一項儲值卡充值業務：客戶在微信公眾號開通儲值卡服務，通過微信支付往卡里面充值，充值成功后客戶可收到訊息通知，并進行消費，
看起來是一項很簡單的業務，最初我們儲值卡團隊的實作也確實很簡單，我們看看最初的實作：
相信聰明的你一眼就能看出問題：
- 壓根沒有考慮分布式事務一致性，比如第 12 步根本沒有考慮卡系統充值失敗的情況該如何處理，而是默認其一定能成功；
- 大部分的處理都是放在前端業務系統（除了這里的公眾號系統，還有 POS 機系統，而 POS 機是通過調公眾號系統介面來實作的）；
- 第 4 步直接下單，第 5 步直接調微信支付，壓根沒有跟卡系統有任何通信：這里默認用戶的充值行為一定是合法的；
- 在微信的支付回呼中（第 10 步往后），是先處理一系列業務邏輯，最后才調充值介面，這里也是默認卡充值一定能成功；
看到這里你可能會大呼開發人員是不是沒長腦子？
實際情況是，這個版本的開發是幾年前的事情了，那時候公司還是創業早期，第一目標是盡快上線能用，而且客戶量沒有那么大，雖然中間也出現過一些資料不一致的情況，也都通過人工處理了事了，
隨著公司業務的發展，用戶量越來越大，而且還要和第三方合作（儲值卡作為一種支付方式提供給第三方使用），問題出現得也越來越頻繁，不得不將這塊提上重構議程，
那么，針對上面提的幾點問題，我們大體能想到如下重構項：
- 將充值業務邏輯從前端系統剝離，做成單獨的服務；
- 在下單前，先調一下卡系統介面，檢查用戶的充值行為是否合法，避免后面不必要的麻煩；
- 在支付回呼中，處理充值失敗的場景；
初步設計如下：
這里我們重點討論下對第 14 步（卡充值介面回傳結果）的處理：
- 如果回傳充值成功，那萬事大吉，該干嘛干嘛；
- 如果失敗呢？可能的處理方式如下：
- 繼續重試，最多重試 3 次，如果成功了，萬事大吉；
- 如果上面重試還是失敗，那么調微信退款，并將訂單狀態改成充值失敗；
騷年你等等！
你說什么？重試失敗了就去退款？
實踐中，遠程呼叫失敗的一個很大原因是網路超時（而超時的很大原因又是對方負載過高），而面對超時，我們是不知道對方到底有沒有處理成功的，萬一這邊把錢退掉了，那邊又充值成功咋辦？（我們是 SaaS 服務商，這時真正的損失方是我們的商戶，而商戶無疑會找我們索賠的）
一種方案是：
在多次重試失敗后發起微信退款之前，先調卡系統查詢介面，如果查詢結果是充值成功，則不退款，繼續后續流程，否則發起退款；
該方案在實際中也基本行不通，因為如果那段時間網路有問題或者對方服務器負載高，查詢也有很大概率失敗，或者就算查成功了并回傳充值記錄不存在，也有可能之前調的充值介面還在跑（比如處于鎖等待狀態），
有人可能會說，沒關系啊，就算退款后充值成功了，那后面通過人工或者系統發現資料問題再處理掉不就行了嗎？
問題在于，如果在發現問題之前，用戶已經從卡上消費掉了呢（比如用戶當場沖1000 然后立馬消費掉，這在我們實際場景中是經常發生的，因為很多商戶會搞充值活動，比如沖1000 送 200）？把卡余額扣成負數？（這不是我杜撰的，在我們老儲值卡系統就出現過幾次這種情況，當時是直接由公司給商戶賠錢）
因此，關鍵在于，當充值中心不知道卡系統有無充值成功的情況下，需要內部假定充值成功了，
最終，我們決定用定時任務來解決，在微信支付回呼中，如果多次調卡充值介面失敗，我們不發起退款，也不進行后續流程，而是在資料庫中寫入一條例外記錄，然后結束本次處理，
在定時任務中（比如 10 分鐘一次），我們取出那些例外記錄，調卡系統相關介面核對最終狀態，如果充值成功了，則補充執行充值成功的后續流程，否則發起微信退款，并執行其他充值失敗流程（如改訂單狀態，給用戶發通知、回呼業務系統等），
為了防止錢退了后卡又充值成功，定時任務中只處理 1 小時前的資料，
另一個隱藏的問題是，在前面的充值流程中，直到微信支付回呼，卡系統都沒有關于這次充值行為的任何記錄，這可能會導致后續一系列問題，其中一個問題是，在最初下單（步驟 5）到最終充值（步驟 13）這段時間內，一旦任何變數（充值規則）發生改變，這次充值就有可能會失敗（或者導致資料差錯），這個時間差短則幾十毫秒，長則幾分鐘十幾分鐘都有可能，另一個次要問題是，一旦發生充值例外，卡系統自身是不知情的（因為沒有任何記錄），對卡系統的任何查詢也都不會反映這次充值行為，
為了解決該問題，我們引入預充值的概念，在下單后調微信支付前，先同步調卡系統的預充值介面，該介面計算充值合法性并生成一條預充值記錄，該記錄包含充值賬號、充值金額、支付金額、充值單號等關鍵資訊，狀態為“充值中”，
在微信支付回呼中，將預充值狀態改成“充值成功”，并處理一些其他邏輯，
綜合，最終方案如圖：
總結：
- 任何涉及到分布式事務的地方都是復雜的，必須小心設計；
- 遠程程序處理不具有時序性，設計時必須考慮進去（如退款后最終又充值成功的情況）；
- 現實中的設計很多時候做不到完美，我們要做的是保證出現例外的概率最小化并設定最終檢查哨兵（上面的定時任務）；
- 就算增設了哨兵，也不排除需要人工干預的可能性，因而在設計上盡量保證需要人工干預時有跡可循、方便處理；
- 遠程呼叫需要有重試機制（上面只說了對充值介面的重試，其實其他介面也一樣需要有重試機制）；
- 記住一句話：網路總是不可靠的；
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/4525.html
標籤：架構設計
上一篇：訊息佇列全面了解（一）
下一篇：訊息佇列全面了解（二）