業務背景

公司業務現用的通道為 A、B，為了降本，引入新的支付通道 Y，但 Y 通道的穩定性要低于 A、B，系統要能在 Y 通道故障時自動切回到 A、B，等 Y 恢復正常后，再切換到 Y。

乍一看很簡單，不就是熔斷降級、故障恢復嗎，有很多成熟的解決方案了。

但有個特殊的業務場景，在支付通道的頁面中（也就是輸入密碼的這一步）可能因為商戶原因，無法繼續支付。這一步已經脫離了我們自己業務的頁面，所以也無法獲知這個失敗場景。

還有一個場景是到輸密碼這一步，由于種種原因，用戶返回了，終止了 支付流程。這種我們系統也無法獲知，更無法區分是商戶還是用戶的原因，導致這筆支付沒有完成。

這個業務場景很重要，雖然發生的概率極低，但必須要解決，否則真有問題等用戶反饋過來，其影響是不能接受的。

調研

現成的技術方案，像 Sentinel 等框架，都需要告訴框架一個明確的采樣規則及觸發點。

比如1分鐘內異常的數量、超時的數量、請求失敗的數量，或者調用量達到多少后觸發。

由于業務場景的特殊性，沒找到可以直接滿足業務需求的現成方案，只能自己想辦法解決。

方案設計

如上所述，需要解決的2個關鍵點是采樣規則和觸發點。

采樣規則可細分為 采樣窗口、采樣數量、采樣數據。

根據我們業務的支付量，我們確定了采樣窗口為最近半小時內，依次向后滑動；

采樣數量為走 Y 通道的全量；

采樣數據為支付成功數據、總數據。

上面交代了系統無法直接準確獲知 Y 通道失敗，所以就換了解決思路。

我們可以從系統現有的 A、B 通道的數據分析出用戶原因未支付的比例（A、B 通道非常穩定，通道導致的失敗率可以忽略不計），這樣一來就可以得出支付成功的比例。

如果切換到 Y 通道后，低于這個比例，大概率是商戶問題導致支付中斷。

這個比例就可以作為我們的觸發點。

簡單畫個草圖

通過這個方案就可以盡早發現商戶問題導致的支付中斷，滿足業務訴求。

扯兩句

用低成本滿足業務訴求；

任何方案都要權衡取舍。

原創不易，多多關注，一鍵三連，感謝支持！