微信公眾號「後端進階」，專注後端技術分享：Java、Golang、WEB框架、分散式中介軟體、服務治理等等。
老司機傾囊相授，帶你一路進階，來不及解釋了快上車！

我在前一家公司的第一個任務是開發統一支付平臺，由於公司的業務需求，需要接入多個第三方支付，之前公司的支付都是散落在各個專案中，及其不利於支付的管理，於是聚合三方支付，統一支付平臺的任務就落在我手上，可以說是完全從 0 開始設計，經過一翻實戰總結，我得出了一些架構設計上的思考，之前就一直很想把自己的架構設計思路寫出來，但一直沒動手，前幾天在技術群裡有人問到相關問題，我覺得有必要把它寫出來，以幫助到更多需要開發支付平臺的開發人員。

元件模式

由於公司業務在很多地區都有，需要提供多種支付途徑，以滿足業務的發展，所以設計的支付平臺需要接入多種第三方支付渠道，如：微信支付、支付寶支付、PayPal、IPayLinks 等等，我們都知道，每個第三方支付，都有自己一套對外 API，官方都有一套 SDK 來實現這些 API，我們應該如何組織這些 API 呢？

由於第三方支付渠道會隨著業務的發展變動，所以組織這些 SDK 就需要在不影響支付平臺整體架構的前提下可靈活插拔，這裡我使用了元件的思想，將支付 API 拆分成各種元件支付元件、退款元件、訂單元件、賬單元件等等，那麼這樣就可以當引入一個第三方支付 SDK 時，可靈活在元件上面新增需要的 API，架構設計如下：

通過 Builder 模式根據請求引數構建對應的元件物件，將元件與外部分離，隱藏元件構建的實現。元件模式 + Builder 模式使得支付平臺具備了高擴充套件性。

多賬戶體系

在接入各種第三方支付平臺，我們當時又遇到一個賬戶的問題，原因是公司當時的小程式與 APP 使用的是不同的微信賬號，因此會出現微信支付會對應到多個賬戶的問題，而我當時設計支付平臺時，沒有考慮到這個問題，當時第三方支付只對應了一個賬戶，而且不同的第三方支付的賬戶之間相互獨立且不統一。

於是我引入了多賬戶體系，多賬戶體系最重要的一個核心概念是以賬戶為粒度，接入多個第三方支付，統一賬戶的引數，構建了統一的支付賬戶體系，支付平臺無需關心不同支付之間的賬戶差異以及第三方支付是否有多少個賬戶。

此時我在支付平臺架構圖加上賬戶層：

前端只需要傳遞 accountId，支付平臺就可以根據 accountId 查詢出對應的支付賬戶，然後通過 Builder 模式構建支付賬戶對應的元件物件，完全遮蔽不同支付之間的差異，在多賬戶體系裡面，可以支援無限多個支付賬戶，完全滿足了公司業務的發展需求。

統一回調與非同步分發處理

做過支付開發的同學都知道，目前的第三方支付都有一個特點，就是支付/退款成功後，會有一個支付/退款回撥的功能，目的是為了讓商戶平臺自行校驗該筆訂單是否合法，比如：防止在支付時，客戶端惡意篡改金額等引數，那麼此時支付成功後，訂單會處於支付中狀態，需要等待第三方支付的回撥，如果此時收到了回撥，在校驗時發現訂單的金額與支付的金額不對，然後將訂單改成支付失敗，以防止資金損失。回撥的思想是隻要保證最終的一致性，所以我們調起支付時，並不需要在此時校驗引數的正確性，只需要在回撥時校驗即可。

講完了回撥的目的，那麼我們如何來設計支付平臺的回撥呢？

由於支付平臺接入了多個第三方支付，如果此時每個第三方支付設定一個回撥地址，那麼將會出現多個回撥地址，由於回撥的 API 必須是暴露出去才能接受第三方的回撥請求，所以就會有安全問題，我們必須在 API 外層設定安全過濾，不然很容易出現一些非法暴力訪問，所以我們需要統一回調 API，統一做安全校驗，之後再進行一層分發。

分發的機制我這裡建議用 RocketMQ 來處理，可能有人會問，如果用 RocketMQ 來做分發處理，此時怎麼實時返回校驗結果到第三方支付呢？這個問題也是我當時一直頭疼的問題，以下是我對回撥設計的一些思考：

1. 公司的系統是基於 SpringCloud 微服務架構，微服務之間通過 HTTP 通訊，當時有很多個微服務接入了我的支付平臺，如果用 HTTP 作分發，可以保證訊息返回的實時性，但也會出現一個問題，由於網路不穩定，就會出現請求失敗或超時的問題，介面的穩定性得不到保障。
2. 由於第三方支付如果收到 false 響應，就在接下來一段時間內再次發起回撥請求，這麼做的目的是為了保證回撥的成功率，對於第三方支付來說，這沒毛病，但對於商戶支付平臺來說，也許就是一個比較坑爹的設計，你想一下，假設有一筆訂單在支付時惡意篡改了金額，回撥校驗失敗，返回 false 到第三方支付，此時第三方支付會再重複傳送回撥，無論傳送多少次回撥，都會校驗失敗，這就額外增加了不必要的互動，當然這裡也可以用冪等作處理，以下是微信支付回撥的應用場景說明：

基於以上兩點思考，我認為返回 false 到第三方支付是沒必要的，為了系統的健壯性，我採用了訊息佇列來做非同步分發，支付平臺收到回撥請求後直接返回 true，這時你可能會提出一個疑問，如果此時校驗失敗了，但此時返回 true，會不會出現問題？首先，校驗失敗情況，訂單必定是處於支付失敗的狀態，此時返回 true 目的是為了減少與第三方支付不必要的遠端互動。

因為 RocketMQ 的訊息是持久化到磁碟的，所以用訊息佇列來做非同步分發最大的好處，就是可以複查訊息佇列裡面的訊息來排查問題，而且訊息佇列可以在業務的高峰期進行流量削峰。

以下是統一回調與分發處理的架構設計圖：

聚合支付

支付平臺聚合了多種第三方支付，因此在請求層需要做很多的適配工作，以滿足多種支付的需求，可能你會想，直接在適配那裡加幾行 if else 不就得了嗎，這麼做也沒問題，也可以滿足多種支付的需求，但你有沒有想過，假設此時再加一個第三方支付，你會怎麼做？你只能原有方法上加多個 else 條件，這樣就會導致請求層程式碼不斷地隨著業務發展改變，使得程式碼及其不優雅，而且也不好維護，這時我們就得用上策略模式，將這些 if else 程式碼消除，當我們增加一個第三方支付時，我們只需要新建一個 Strategy 類就可以了，策略模式究竟怎麼使用可以看看大話設計模式。

因此我在 Builder 模式前加多了一層支付策略層：

請求處理

由於支付平臺涉及到資金，支付的各種請求與返回，以及異常記錄在一個支付平臺中異常重要，因此我們需要記錄每一次的支付請求記錄，以便後續排查問題。

基於這點需求，我在開始請求第三方支付之前，設計了一層 Handler 層，所有的請求都必須經過 Handler 層進行處理，Handler 核心方法如下：

public K handle(T t) {
  K k;
  try {
    before(t);
    k = execute(t);
    after(k);
  } catch (Exception e) {
    exception(t, e);
  }
  return k;
}
protected abstract void before(T t);
protected abstract void after(K k);
protected abstract void exception(T t, Exception exception);

原則上來說，我設計的 Handler 層，利用了模版模式，不僅僅可以實現日誌的記錄，還可以實現多種處理方式，比如請求監控，訊息推送等等，實現了 Handler 層的高擴充套件性。

以下是 Handler 層的架構設計圖：

寫在最後

以上就是我的支付平臺架構設計思路，總結來說，支付平臺需要具備可擴充套件性、穩定性、高可用性，因此我在設計支付平臺時使用了很多設計模式以及引入訊息佇列處理回撥分發的問題，使得支付平臺具備這幾點特性，希望能夠給你一些啟發與幫助，最後我把支付平臺整體的架構設計圖貼出來：

相關推薦