提到路由，不免會想到網(wǎng)絡通信過程中起到數(shù)據(jù)包轉發(fā)的路由器。

而我們今天講到支付路由系統(tǒng)，也是起到類似的作用。路由系統(tǒng)本身并不處理具體業(yè)務，它的作用就是將支付請求轉發(fā)底層支付通道。

如上圖所示，支付系統(tǒng)接入層，接收到支付請求之后，經過內部運算，最后將會通過路由系統(tǒng)轉發(fā)給具體底層的支付通道。

另外，除了路由轉發(fā)功能以外，路由器一般還會有一些額外的功能，比如防火墻等。

那我們其實也可以在支付路由系統(tǒng)加入額外功能，比如實時計算底層支付渠道的成功率，若低于一定的閾值，進行報警并且將該渠道下線。

這里需要說明一點，這里的路由系統(tǒng)可以是一個應用中子模塊，也可以是一個單獨子系統(tǒng)。

為什么需要路由系統(tǒng)

看到這里，可能會有一些小伙伴會思考，一定需要這個路由系統(tǒng)嗎？直接將請求發(fā)給支付通道不好嗎？

答案當然是可以的，如果當前只對接「一兩個支付渠道」，這么做沒問題，并且也推薦這么做。

這個階段由于業(yè)務量不大，支付系統(tǒng)可能只是一個單體應用，或者也可能是其他應用內一個子模塊而已。

那這個時候，業(yè)務很簡單，系統(tǒng)也很簡單，那我們不需要額外的路由系統(tǒng)，增加系統(tǒng)復雜度。

不過這樣的系統(tǒng)弊端也很明顯，如果后期再新增一個支付通道，我們需要再開發(fā)對接。

另外由于所有實現(xiàn)都在一個系統(tǒng)，假設系統(tǒng)應用發(fā)生問題，那么就是大家一起「死」，這其實也是單體系統(tǒng)最大弊端。

所以如果底層對接支付通道很多，像一般第三支付公司的支付系統(tǒng)，同一家銀行的可能會對接很多支付通道，比對銀聯(lián)無跳轉支付，網(wǎng)聯(lián)支付，也有可能是 XX 行自己提供的接口。

那么這種情況就非常需要單獨維護一個路由系統(tǒng)。

PS：630 政策之前，支付公司對接支付通道那真是一個多，同一家銀行，可能會對接四五個通道。

但是 630政策之后， 不允許支付機構直接對接銀行。

所以現(xiàn)在支付機構對接通道可能會比之前少很多。

實現(xiàn)方式

路由系統(tǒng)實現(xiàn)方式有很多，下面主要分享一下我所經歷過實現(xiàn)方案。

我們的路由系統(tǒng)經歷過三個階段的迭代，才有了現(xiàn)在的實現(xiàn)方案。

第一個階段-混沌初開

這個階段就跟上面講的場景一樣，業(yè)務需求較簡單，僅僅只需要對接一兩個支付通道。

為了快速上線，設計方案就簡單粗暴，所有業(yè)務都處于一個應用。

支付子模塊對內暴露暴露支付服務接口，由業(yè)務系統(tǒng)發(fā)起直接調用。

系統(tǒng)設計圖如下:

這個階段由于只有一個支付渠道，所以也不需要有路由系統(tǒng)，直接由業(yè)務系統(tǒng)調用支付服務接口發(fā)起支付。

不過隨著業(yè)務量增大之后，這個設計方案就暴露很多問題：

1. 業(yè)務系統(tǒng)與支付系統(tǒng)位于同一個系統(tǒng)，系統(tǒng)任何一次變更都會影響整個系統(tǒng)。
2. 擴展性問題。每接入一個新的支付通道如微信，就需要增加一個新的實現(xiàn)類。另外，業(yè)務系統(tǒng)的代碼同時也需要改動，需要調用新的實現(xiàn)類。

針對以上問題，我們進行第一版的改造。

首先我們將整個支付模塊從原來應用中拆分出來，成為一個獨立的子系統(tǒng)，專門運行支付業(yè)務。

這個系統(tǒng)對外提供一組支付接口，業(yè)務系統(tǒng)只需要調用這個接口，傳入必要的參數(shù)，無需關心支付系統(tǒng)到底是如何實現(xiàn)的。

如果業(yè)務系統(tǒng)想指定某個支付通道，比如支付寶，那么可以在接口傳入這個渠道標識，支付系統(tǒng)將會根據(jù)這個渠道標識調用相應的支付通道。

其次梳理渠道接口文檔，抽象出共性接口，每個支付通道實現(xiàn)都需要繼承這個接口。

這組通用渠道接口，其中 「channelName」 方法，代表這個實現(xiàn)類具體代表哪個通道。比如說這個方法返回 「aliPay」，那么就代表這個實現(xiàn)類將會調用支付寶通道。

支付系統(tǒng)子應用中將會維護一個類似路由表，這里簡單使用 Map 存儲映射關系，「key」 為上文提到的渠道唯一應用標識，而 「value」 為具體的實現(xiàn)類。

應用初始化之后，將會調用 「Spring ApplicationContext getBeansOfType」 方法，獲取同一個接口的所有實現(xiàn)類 ，最后將其放入 Map 緩存中。

每次支付調用都會根據(jù)渠道唯一標識從路由表獲取具體實現(xiàn)類，然后由具體的子類實現(xiàn)支付邏輯。

學過設計模式的同學，這里應該不會陌生，這其實是使用設計模式中的策略模式。

這個階段，由于業(yè)務還不是很復雜，系統(tǒng)還是挺簡單，路由系統(tǒng)還只是系統(tǒng)中的一個子模塊。

第二個階段-神功初成

經歷過一段時間，公司的業(yè)務量變的越來越大，這個階段我們開始追求系統(tǒng)的穩(wěn)定性。

但是在第一階段設計方案中，支付系統(tǒng)所有模塊位于同一工程。有些模塊可能需要頻繁發(fā)布，這樣一旦發(fā)布就會影響所有系統(tǒng)功能。

第二點，系統(tǒng)功能全都耦合在一起，團隊開發(fā)也變的困難，分支沖突，代碼丟失也是經常的事。

第三點，一旦某些改動發(fā)布發(fā)生問題，整個系統(tǒng)都受到影響，真的是「要死一起死」。

所以這個階段針對以上的問題，我們進行了相應改造，開始將支付系統(tǒng)進行拆分。

首先按照功能，將支付系統(tǒng)拆分幾個獨立的子系統(tǒng)，路由系統(tǒng)，渠道系統(tǒng)，成為獨立系統(tǒng)，獨立部署維護。

每個支付通道單獨維護部署，成為一個單獨的子應用。

系統(tǒng)之間的調用關系，就從同一進程內調用，變成使用 「RPC」 進行跨進程調用。

這個時候就會有個問題，渠道系統(tǒng)可能會因為發(fā)布而下線/上線，這時路由系統(tǒng)必須動態(tài)維護這種關系，在渠道系統(tǒng)某一節(jié)點下線時，自動刪除調用關系，而當應用上線時，新增調用關系。

「說白了，路由系統(tǒng)需要實現(xiàn)渠道服務動態(tài)發(fā)現(xiàn)?！?/strong>

看到這里不要怕，其實 Dubbo 框架已經自帶這個功能，我們沒必要自己再去實現(xiàn)了。

Dubbo 配置中有一個屬性-「group」，這個屬性可以用于服務分組。

當同一個接口有多個實現(xiàn)，我們就可以根據(jù)這個來區(qū)分不同渠道系統(tǒng)的實現(xiàn)。

因為渠道系統(tǒng)實現(xiàn)同一組接口之后，提供出 Dubbo 服務需要加上相應的 group 屬性，值為相應的渠道唯一標識。

如下所示：

路由系統(tǒng)只要引入這個 Dubbo 服務，設置相應的 「group」 屬性 ，路由系統(tǒng)引用渠道系統(tǒng)的服務：

此時路由系統(tǒng)就跟第一階段一樣，內部維護一個路由表就好了。

這里采用了 XML 配置存儲渠道標識與 Dubbo 引用服務的映射關系，如下所示：

服務啟動之后解析這個 XML 文件，然后將其維護在 Map 中。每次支付調用都會根據(jù)渠道唯一標識從路由表獲取服務名，然后借助 「Spring ApplicationContext#getBean」 獲取具體的 Dubbo 引用服務。

后續(xù)如果再新增渠道系統(tǒng)，路由系統(tǒng)不需要再修改任何代碼，只要在配置文件中新增 Dubbo 服務引用以及增加路由表引用關系即可。

第三階段-登峰造極

第二個階段路由系統(tǒng)基本上已經滿足現(xiàn)有階段業(yè)務實用，不過還是存在個問題，渠道應用新增時，還需要新增配置「重啟應用」。

之前有一次新增渠道，忘記了在路由系統(tǒng)新增配置，從而導致新的渠道應用無法被調用，找了很久的問題，才發(fā)現(xiàn)是這個問題。

所以第三階段，主要是優(yōu)化路由系統(tǒng)，去掉上述配置文件，到達新增渠道應用，而不用重啟路由系統(tǒng)。

這個階段的改造，我們不再使用 XML 配置引用服務，而是借助 「Dubbo API」 ，動態(tài)引用 Dubbo 服務。

查看 ?Dubbo 文檔 ，可以直接使用 ReferenceConfig 直接查找服務提供者。

官方文檔建議：

ReferenceConfig 實例很重，封裝了與注冊中心的連接以及與提供者的連接，需要緩存。否則重復生成 ReferenceConfig 可能造成性能問題并且會有內存和連接泄漏。在 API 方式編程時，容易忽略此問題。

這里使用ReferenceConfigCache，用于緩存 「ReferenceConfig」 實例。

改造之后，去除之前所有引用服務配置文件以及緩存注冊代碼，不用再使用 Map 存儲路由的映射關系。改造如下：

總結

回顧上文，可以看到初期沒有路由系統(tǒng)，整個系統(tǒng)可以運行下去。

但是隨著業(yè)務量不斷變大變復雜，最開始的系統(tǒng)架構已經不能適應當前的環(huán)境，所以我們才開始系統(tǒng)拆分，進行微服務改造，一步步改進系統(tǒng)。

改進的過程中，不斷發(fā)現(xiàn)方案不足處，然后一步步迭代演進。這個過程中，要善于利用現(xiàn)有框架的功能，加速功能的開發(fā)。

最后，本文給出了幾種不同階段路由系統(tǒng)實現(xiàn)方式，適合不同階段、不同類型的系統(tǒng)。

如果各位同學剛好也有類似需要，可以根據(jù)自己系統(tǒng)的情況借鑒參考。