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