1. 程式人生 > >支付渠道路由系統進化史

支付渠道路由系統進化史

支付系統一般需要對接多個支付渠道,一是為了保證系統的可靠性,不能因為單一渠道的問題影響整個支付系統。二是為了提高支付能力,不同渠道提供支付能力不同。三是為了降低支付成本。

對接多個支付渠道以後,為了可以正確選擇支付渠道支付,因此設計渠道路由系統。

從上圖可以看到路由系統功能其實很簡單,分發支付請求到正確的渠道。但就是這個簡單系統,也經過幾次系統改造升級,最終才成為現在的樣子。下面就來說說這個系統是如何演進。

下面假設對接支付渠道為支付寶與微信。

初期

支付系統初期,這個階段業務需求較簡單,僅僅需要滿足一個支付場景(例如使用支付寶支付)。為了快速上線,設計方案就簡單粗暴,對外直接暴露支付服務介面,由業務系統發起直接呼叫。

系統設計圖如下:

這個階段由於只有一個支付渠道,所以也不需要有路由系統,直接由業務系統呼叫支付服務介面發起支付。

這個設計方案存在很多問題:

  1. 業務系統與支付系統位於同一個系統,系統任何一次變更都會影響整個系統。
  2. 擴充套件性問題。接入新支付渠道,如微信,需要新暴露一個微信支付服務介面。業務系統需要改動程式碼。從另一方面講,業務系統承擔路由系統的功能。
  3. 複用性。新支付渠道,其實除了與支付渠道互動相關程式碼之外,其他程式碼可以複用。

針對以上問題,將系統進行了相應改造。

首先是將支付系統與業務系統單獨拆分出來,成為兩套單獨的系統。支付系統對外暴露一組通用介面。業務系統僅對接這組介面。業務系統若想指定支付渠道支付,介面引數傳入渠道標識即可。這樣就將耦合在業務系統中路由功下沉到支付系統。

其次梳理渠道介面文件,抽象出共性介面。接入新支付渠道,只要繼承介面,實現相關方法即可,簡化渠道開發難度。

改版後的系統實現圖如下:

此時,路由系統知識支付系統的一個模組,具體實現如下。

首先定義通用渠道介面,其中 channelName 方法,返回渠道渠道唯一標識,如支付寶渠道返回 aliPay。

然後根據 Spring ApplicationContext getBeansOfType 方法,獲取實現同一個介面的所有 Bean.最後將其放入 Map 快取中,其中鍵值為 channelName 方法返回渠道標識。

這個階段方案的問題在於支付系統所有模組位於同一工程。有些模組需要頻繁釋出,而有些模組,如渠道模組,路由模組改動就很少。這樣就導致系統任一改動釋出,影響整個支付系統可用性。

中期

針對初期後面的問題,進行了相應改造。

首先還是進行拆分,將支付系統按照模組拆分。路由系統,渠道系統,成為獨立系統,獨立部署維護。

系統之間呼叫採用 RPC 通訊,使用 Dubbo 框架。

相關實現如下:

相關介面邏輯不變,只是將同一程序內呼叫變成跨系統的呼叫。

渠道系統提供服務:

這裡改動,將渠道標識放入 Dubbo 服務 group 欄位,藉助 Dubbo 分組功能標識中唯一的渠道系統。

路由系統引用渠道系統的服務:

這裡同樣需要設定 group 且需要和服務提供者一致。然後在路由系統中將服務註冊到快取中,使用渠道標識為 key,渠道服務名為 value。

最後路由系統藉助 Spring ApplicationContext getBean 獲取具體的服務。

這個設計的問題在於:

路由系統中需要手動引用渠道系統服務,然後再註冊。這樣在增加渠道系統就比較繁瑣。那是不是可以做到增加渠道系統時,無需修改路由系統,路由系統自動發現服務?

藉助 Dubbo API。

後期

檢視 Dubbo 文件,可以直接使用 ReferenceConfig 直接查詢服務提供者。

官方文件建議:

ReferenceConfig 例項很重,封裝了與註冊中心的連線以及與提供者的連線,需要快取。否則重複生成 ReferenceConfig 可能造成效能問題並且會有記憶體和連線洩漏。在 API 方式程式設計時,容易忽略此問題。

這裡使用ReferenceConfigCache,用於快取 ReferenceConfig 例項。

去除之前所有引用服務配置檔案以及快取註冊程式碼,引入 ReferenceConfigCache,改造如下。

總結

回顧上文路由系統,可以看到初期沒有路由系統,整個系統可以執行下去。但是隨著系統複雜度提高,初期系統架構已經不能滿足系統的高效執行,所以才一步步改進系統。改進的過程中,不斷髮現方案不足處,然後一步步迭代演進。這個過程中,要善於利用現有框架的功能,加速功能的開發