1 引言

2 背景知識介紹

2.1 名詞解釋

2.2 邏輯解釋

3 支付路由系統(tǒng)歷史演進

階段1：基礎配置模式

階段2：規(guī)則引擎模式

階段3：模塊構(gòu)建模式

4 路由系統(tǒng)解密

4.1 整體架構(gòu)

4.2 路由模塊構(gòu)成

4.3 表達式引擎

4.4 異常檢測、自動下線

4.5 自動恢復

5 總結(jié)與展望

5.1 系統(tǒng)演進總結(jié)

5.2 未來展望

5.3 結(jié)語

1.引言

在電商交易場景中，支付環(huán)節(jié)是整個用戶購物環(huán)節(jié)中的關鍵節(jié)點。用戶從搜索、推薦、瀏覽、比較、加購、下單，到最終的支付環(huán)節(jié)，每一步都經(jīng)歷了層層漏斗的篩選。當用戶到達支付環(huán)節(jié)時，已經(jīng)展現(xiàn)出強烈的購買意向，這時的流量價值已經(jīng)遠超最初環(huán)節(jié)。支付環(huán)節(jié)的體驗直接關系到最終的成交轉(zhuǎn)化，因此收銀臺不僅要確保支付流程的順暢，更要保證支付的安全性和可靠性。隨著業(yè)務規(guī)模的不斷擴大，支付場景的日益復雜，如何構(gòu)建一個高效、穩(wěn)定、智能的支付路由系統(tǒng)，成為了我們面臨的重要挑戰(zhàn)。

本文將深入解析轉(zhuǎn)轉(zhuǎn)收銀臺支付路由系統(tǒng)的設計與實現(xiàn)，從系統(tǒng)架構(gòu)、規(guī)則引擎、異常處理等多個維度，分享我們在支付路由系統(tǒng)演進過程中的實踐經(jīng)驗和技術(shù)心得。通過這篇文章，你將了解到：

• 轉(zhuǎn)轉(zhuǎn)收銀臺支付路由系統(tǒng)是如何從簡單的規(guī)則配置，演進到模塊構(gòu)建模式路由
• 規(guī)則引擎如何支持靈活的業(yè)務配置，實現(xiàn)支付渠道的智能調(diào)度
• 系統(tǒng)如何通過完善的監(jiān)控和自動化機制，保證支付服務的穩(wěn)定性

無論你是支付領域的從業(yè)者，還是對系統(tǒng)架構(gòu)感興趣的技術(shù)人，相信這篇文章都能給你帶來一些啟發(fā)和思考。讓我們一起走進轉(zhuǎn)轉(zhuǎn)收銀臺支付路由系統(tǒng)的技術(shù)世界。

2.背景知識介紹

2.1 名詞解釋

2.2 邏輯解釋

上面的名詞概念非常重要，此處著重介紹部分概念。

1）為什么需要終端和版本？

不同的終端版本支持的支付方式和產(chǎn)品不一樣，比如：假設某個支付方式需要集成某個SDK，而這個SDK是從x.x.x之后的版本才開始集成的，那么低于這個版本的就不能透出這個支付方式。

2）展示渠道和支付機構(gòu)概念是否沖突？

不沖突，有些展示渠道是抽象出來的，沒有實際的映射，比如分筆支付、組合支付。而有些情況是多個展示渠道對應一個支付機構(gòu)，比如花唄和支付寶，都是屬于同一種支付機構(gòu)。

3）為什么在商戶號之外設計支付渠道的概念？

支付渠道是商戶號更精細化控制的維度，假設在某間聯(lián)通道注冊了商戶號B，同時B是支持微信（B1）和支付寶（B2）的，為了分別精準控制B1、B2的可用狀態(tài)、分流比例、權(quán)重等因素，需要設計支付渠道的維度。

3.支付路由系統(tǒng)歷史演進

要真正理解一個系統(tǒng)，我們必須追溯它的發(fā)展歷程，了解它的來龍去脈。每一個決策、每一個設計，都是特定條件下的產(chǎn)物。它們或許不是最優(yōu)的選擇，甚至可能不是最合適的方案，但每一個環(huán)節(jié)的設置都承載著當時的考量與權(quán)衡。這些決策背后，往往有著復雜的技術(shù)背景、業(yè)務需求、現(xiàn)實約束和歷史原因。系統(tǒng)演進每一步都是在前人的基礎上不斷積累和創(chuàng)新的結(jié)果。了解這個過程，不僅能夠幫助我們更好地理解系統(tǒng)的現(xiàn)狀，更能為未來的優(yōu)化和演進提供寶貴的參考，只有理解了"為什么是這樣"，才能更好地思考"應該是什么樣"。

階段1：基礎配置模式

基礎配置模式是符合支付路由系統(tǒng)目標的最簡單實現(xiàn)方式，它采用簡單直接的配置規(guī)則，通過幾個核心條件就能完成支付渠道的路由選擇。這種模式就像是一個簡單的導航系統(tǒng)，只需要輸入目的地，就能給出明確的路線指引。

在這種模式下，系統(tǒng)主要通過業(yè)務場景和公司主體等基礎維度，精準匹配到對應的收單商戶號。比如，當用戶選擇微信支付時，系統(tǒng)會根據(jù)當前業(yè)務場景（如換新等）和公司主體信息，直接返回預設的商戶號配置。

基礎配置模式特別適合業(yè)務規(guī)則相對固定、支付需求穩(wěn)定的場景。它的優(yōu)勢在于：

• 配置簡單直觀，易于維護
• 執(zhí)行效率高，響應速度快
• 代碼結(jié)構(gòu)清晰，易于理解

雖然隨著業(yè)務的發(fā)展，系統(tǒng)已經(jīng)演進到了更復雜的階段，但基礎配置模式并未被完全淘汰。恰恰相反，由于其簡單高效的特點，在一些業(yè)務場景簡單、對響應速度要求高的場景中，這種模式仍然有一席之地。這就像是在現(xiàn)代交通工具中，自行車依然因其簡單便捷而不可或缺一樣。

這種模式的存在，體現(xiàn)了系統(tǒng)設計中的一個重要原則：不是所有場景都需要最復雜的解決方案，有時候簡單直接的方案反而是最優(yōu)的選擇。

階段2：規(guī)則引擎模式

規(guī)則引擎模式引入了業(yè)務匹配規(guī)則和規(guī)則引擎的概念。系統(tǒng)通過買家、賣家、業(yè)務線等維度定義業(yè)務場景，將每個商戶號的每種支付產(chǎn)品作為獨立的支付方式，并定義了不同終端、不同版本下的可用支付方式列表。

系統(tǒng)處理流程示意如下：

圖片

這種模式特別適合業(yè)務線眾多、支付方式多樣、業(yè)務規(guī)則相對穩(wěn)定的場景。然而，隨著業(yè)務發(fā)展，其局限性也逐漸顯現(xiàn)：

1）配置維護成本高：每次增加商戶號或業(yè)務場景，需要修改大量配置數(shù)據(jù)，耗時較長。

2）商戶號使用受限：不支持同一業(yè)務場景下同一種支付方式使用多個商戶號，限制了業(yè)務擴展的靈活性。

3）維度擴展困難：業(yè)務場景維度擴充不夠便捷，難以快速響應新的業(yè)務需求。

階段3：模塊構(gòu)建模式

模塊構(gòu)建模式引入了 Aviator 表達式引擎，使得規(guī)則維度的擴展更為便捷。系統(tǒng)對原有的終端環(huán)境和版本進行了結(jié)構(gòu)拆解，使業(yè)務場景不再與具體的環(huán)境和支付產(chǎn)品深度綁定。

同時，系統(tǒng)對文案、排序等配置項進行了解耦，不再要求每個支付方式都綁定固定文案，這大大方便了活動文案的配置和復用。此外，系統(tǒng)還豐富了對同一場景多商戶號的支持，并引入了異常渠道自動上下線機制，顯著提高了服務的穩(wěn)定性。

這種模式的出現(xiàn)，使支付路由系統(tǒng)具備了更強的靈活性和穩(wěn)定性。

4.路由系統(tǒng)解密

4.1 整體架構(gòu)

支付系統(tǒng)作為轉(zhuǎn)轉(zhuǎn)平臺的核心基礎設施，不僅需要支撐內(nèi)部運營人員的路由管理需求，更要承擔全平臺用戶的支付請求處理。系統(tǒng)需要適配多樣化的環(huán)境（包括各版本APP、小程序等）和不同用戶角色（如普通買家、普通賣家、商家、回收個人等）。

在架構(gòu)設計上，支付系統(tǒng)直接承接C端流量，同時與各業(yè)務部門緊密協(xié)作。基礎能力和底層服務則由公司架構(gòu)團隊提供支持。

整體架構(gòu)如下：

圖片

獲取可用支付方式的邏輯示意圖如下：

其中提交收銀臺在支付路由的邏輯部分和獲取可用支付方式邏輯類似，不再贅述。

圖片

4.2 路由模塊構(gòu)成

思考心路：在規(guī)則引擎模式中有一些很明顯的痛點

1）業(yè)務場景和終端環(huán)境以及版本高度綁定這個特點在后續(xù)版本升級繼承不同渠道的時候就會存在一個業(yè)務線，在同一個APP要配置N套支付方式，繼承微信SDK版本的一套；繼承微信SDK且支付寶SDK的一套；繼承微信SDK且支付寶SDK且京東SDK的一套....

2）業(yè)務場景和支付配置高度綁定原來的配置方式上，直接決定了某個業(yè)務場景在具體終端環(huán)境和版本下的支付渠道，是指明了支付產(chǎn)品、支付圖標、支付標題、支付文案等配置。這一設計導致每新增一個支付渠道都需要把對應的圖標、文案、標題等信息重復配置一遍。

基于上述痛點，我們在設計新的結(jié)構(gòu)的時候，把整個路由系統(tǒng)進行了模塊拆分，使得模塊之間不再深度綁定，這樣既可以輕松擴展，也方便模塊的復用，同時在管理方面也不需要關注太多的因素。

支付路由內(nèi)部可以劃分為如下模塊：

1）業(yè)務場景管理

核心模塊之一，根據(jù)業(yè)務線和收款賬戶定義業(yè)務場景，后續(xù)引導路由是基于業(yè)務場景再次進行匹配。可以抽象的理解為定制好的一個規(guī)則組。

業(yè)務場景目前后臺限制了只配置業(yè)務線和收款賬戶，但是系統(tǒng)本身是支持更多維度的。

圖片

2）商戶號管理

維護系統(tǒng)中的商戶號信息，包括商戶號、收單機構(gòu)、是否支持降級、登錄賬戶、支持的支付方式和支付產(chǎn)品、手續(xù)費信息和對賬信息等。

圖片

3）支付渠道管理

基于商戶號的擴展，配置對應的密鑰信息、渠道參數(shù)。一個商戶號可以對應多個支付渠道。系統(tǒng)異常上下線和分流比例都是基于支付渠道配置的。

4）路由策略管理

路由策略分為兩種

分流：配置同一種支付方式下不同支付渠道的比值關系。

不可用：限制某支付渠道不可用。

圖片

5）基礎因素管理

配置不同環(huán)境本身支持的支付方式上限

圖片

6）可用支付方式

可用支付方式限制了業(yè)務場景使用的支付方式上限，和基礎因素共同約束了用戶的可用支付方式。

圖片

整體模塊一覽如下圖：

圖片

4.3 表達式引擎

業(yè)務場景是支付路由的核心概念，可用支付方式、分流比例、顯示文案和排序規(guī)則都是在業(yè)務場景的基礎上配置的。因此，如何定義業(yè)務場景至關重要。

盡管我們可以窮舉所有能用到的維度，但如果將來出現(xiàn)新的維度需要劃分，我們的設計如何支持后續(xù)的擴展（比如，根據(jù)所在城市顯示不同的支付方式）？基于上述考量，我們將業(yè)務場景設計成腳本語言表達式。這種腳本語言表達式不僅應用于業(yè)務場景模塊，還貫穿整個支付路由系統(tǒng)。

下面我們使用具體的例子來理解表達式引擎，同時對比一下和硬編碼實現(xiàn)的特點。

假設業(yè)務的訴求是，業(yè)務線等于1001或者1002，并且終端環(huán)境等于找靚機安卓，并且版本在3.1.2和6.3.8之間，并且支付金額小于6萬，那么可以使用的支付方式為：微信、支付寶、京東。

使用硬編碼實現(xiàn)：

if("業(yè)務線樹".contains("1001")||"業(yè)務線樹".contains("1002")){
    if("終端環(huán)境".equals("找靚機安卓")){
        if("版本判斷"("版本","3.1.2","6.3.8")){//版本判斷為自定義的函數(shù)
            if("金額"<6萬){
                return "微信、支付寶、京東";
            }
        }
    }
}

可以預見到，如果使用硬編碼實現(xiàn)，當面對規(guī)則變動和規(guī)則及維度變多的時候，將面對災難級的現(xiàn)場。

使用表達式引擎的實現(xiàn)：

//加載自定義函數(shù)
AviatorEvaluator.addFunction(new BusinessFunction());
AviatorEvaluator.addFunction(new VersionFunction());
//當前請求的變量
Map<String, Object> env = new HashMap<>();
env.put("fl_business_line", [1001,10011000]);
env.put("f_t", "找靚機安卓");
env.put("f_v", "5.7.2");
env.put("f_m", "4000.00");
//當前規(guī)則的表達式展開
String expressinotallow="func_business(fl_business_line,seq.set('1001','1002'))&&include(seq.set('找靚機安卓'),f_t)&&func_version(f_v,'3.1.2','6.3.8')&&f_m<60000";
boolean match=AviatorEvaluator.getInstance().execute(expression, env, true);
if(match){
    return"微信、支付寶、京東";    
}

通過表達式引擎的示例代碼，我們看到，當業(yè)務需要新增維度的時候，比如增加一個條件:城市等于北京，注意：城市可以添加多個。

因為等值判斷和集合判斷是表達式本身就支持的，不需要自定義函數(shù)。所以改動如下：

//新增維度值
env.put("f_c", "北京");
//擴充表達式
String expressinotallow="func_business(fl_business_line,seq.set('1001','1002'))&&include(seq.set('找靚機安卓'),f_t)&&func_version(f_v,'3.1.2','6.3.8')&&f_m<60000";
expression+="&&include(seq.set('北京'),f_c)";

通過這種方式，系統(tǒng)能夠靈活應對未來的變化和擴展需求。

表達式引擎邏輯如下：

圖片

在技術(shù)選型時，我們調(diào)研對比了Aviator、Groovy、Drools等方式。最后我們選擇Aviator作為表達式引擎，有如下原因，其輕量、依賴少，且高性能，所支持的運算操作符滿足我們的業(yè)務場景需求。同時支付系統(tǒng)在設計上沒有與Aviator腳本深度綁定，而是預留了一個可以擴展的輸入輸出接口。我們可以選擇Aviator、Groovy、Drools、easy-rule、也可以自己基于java代碼實現(xiàn)一套數(shù)據(jù)匹配的邏輯。這種可拔插的設計預留使我們系統(tǒng)在后續(xù)的發(fā)展中不會被某一種技術(shù)所鎖定。

附上部分數(shù)據(jù)

4.4 異常檢測、自動下線

雖然渠道異常是小概率事件，但隨著接入渠道的增多，異常發(fā)生的概率也會呈幾何級數(shù)增長。當系統(tǒng)檢測到某個渠道異常時，可以通過技術(shù)手段來確保用戶體驗不會顯著下降。

以下舉兩個例子來說明：

單一收單機構(gòu)：假設京東支付方式背后只有京東一個收單機構(gòu)，當京東收單機構(gòu)異常時，可以將京東支付隱藏、置灰或增加風險提示，引導用戶使用其他支付方式。

多收單機構(gòu)：假設支付寶支付方式背后有支付寶和易寶兩個收單機構(gòu)，當易寶機構(gòu)服務異常時，可以在支付時自動路由到支付寶的收單機構(gòu)，用戶感知不到異常的發(fā)生。

異常檢測自動下線和自動恢復整體架構(gòu)如下：

圖片

異常檢測自動下線的邏輯如下：

圖片

通過異常檢查、異常渠道自動下線的方式，系統(tǒng)能夠在渠道異常時保持服務的穩(wěn)定性和用戶體驗。

4.5 自動恢復

自動恢復的邏輯比自動下線簡單，但需要考慮一種場景：為了減少短暫恢復再陷入異常情況對用戶的影響，恢復過程中若有其他可用渠道，那么恢復渠道應采用逐步放量恢復的方法。

邏輯流程圖如下：

圖片

5.總結(jié)與展望

5.1 系統(tǒng)演進總結(jié)

隨著業(yè)務的發(fā)展，轉(zhuǎn)轉(zhuǎn)收銀臺支付路由系統(tǒng)也一直在持續(xù)演進，在基礎配置模式階段，系統(tǒng)通過簡單的配置規(guī)則實現(xiàn)了基本的支付路由功能，為后續(xù)發(fā)展奠定了基礎。規(guī)則引擎模式的引入，使系統(tǒng)具備了更強大的場景適配能力，能夠更好地滿足多樣化的業(yè)務需求。而模塊構(gòu)建模式的出現(xiàn)，則標志著系統(tǒng)在靈活性和可擴展性方面達到了新的高度。

多渠道適配模式的引入，為支付渠道費用的優(yōu)化提供了更多可能性，而渠道異常自動上下線能力的實現(xiàn)，則有效降低了第三方渠道波動對用戶體驗的影響，顯著提升了系統(tǒng)的穩(wěn)定性和可靠性。

5.2 未來展望

• 體驗優(yōu)化基于渠道支付成功率和響應時間動態(tài)調(diào)整渠道權(quán)重，保障用戶體驗滿足用戶個性化定制收銀臺需求提升內(nèi)部產(chǎn)研團隊使用體驗
• AI助力探索AI在路由系統(tǒng)的應用

5.3 結(jié)語

物有本末，事有終始。知所先后，則近道矣。

至此，整個收銀臺路由系統(tǒng)中核心部分已經(jīng)介紹完畢，文中所列數(shù)據(jù)、舉例都非真實數(shù)據(jù)，是僅供學習交流的示例數(shù)據(jù)，可能缺失了真實樣例的更多細節(jié)，不過整體結(jié)構(gòu)和邏輯是完整的。

關于作者張一鳴 轉(zhuǎn)轉(zhuǎn)支付后端研發(fā)