說明：

1. 支付方式咨詢：根據用戶的請求，組裝可用支付方式列表返回給用戶。由收銀域提供服務。
2. 渠道咨詢：根據用戶的請求，組裝可用的渠道列表和渠道屬性返回給收銀域，再由收銀域轉換為支付方式返回給用戶。由渠道網關提供服務。
3. 渠道路由：當有多個渠道可用時，選擇出最優的一個渠道。由渠道網關提供服務。

再詳細一點，如下：

支付方式咨詢：解決用戶可以使用哪些支付方式，比如余額、招行借記卡、招行信用卡等。比如虛擬商品不能使用信用卡，這種支付方式的管理就是支付方式咨詢的職責。

渠道咨詢：解決是否有渠道可以支持當前的支付行為。比如用戶綁定了招行借記卡，但招行當前正在維護無法提供服務，那就將渠道狀態設置為不可用，收銀域對應的支付方式會置灰。

渠道路由：解決最優渠道問題。需要綜合支付成功率、支付成本、用戶體驗、渠道狀態等多種因素挑選出最優的一條渠道。

2.?渠道路由核心作用

渠道路由核心作用是當有多個渠道同時滿足業務訴求時，綜合支付成功率、支付成本、用戶體驗、渠道狀態等多種因素挑選出最優的一條渠道。具體如下：

1. 提高支付成功率：通過選擇最合適的渠道，可以提高支付的成功率，減少支付失敗帶來的用戶流失。原因在于不同的渠道在其內部的風險偏好是不一樣的，同一個請求在A渠道會失敗，但在B渠道會成功。
2. 優化成本：不同渠道的費用可能不同，通過合理的路由，可以降低支付成本。一些渠道還有階梯收費，需要通過分流不同的渠道，保持整體成本最優。
3. 提升用戶體驗：快速、穩定的支付體驗能增強用戶的滿意度和忠誠度。用戶如果經常在A渠道支付，新的請求過來后，仍然發給A渠道支付的成功率往往會更高。
4. 負載均衡：將支付請求合理分配到不同的渠道，避免某個渠道過載，提升整體系統的穩定性。

舉幾個渠道路由應用的小場景：

1. 用戶使用招行信用卡支付，支付平臺同時對接了網聯和銀聯，而網聯和銀聯都支持招行信用卡，那么就需要渠道路由挑選一個渠道。
2. 做實名認證，平臺對接了多個實名認證通道，通過渠道路由挑選一個認證渠道。

由上面可以看到，除了支付路由外，還可能有信息類渠道路由，比如實名認證類。

那退款有沒有路由？顯示沒有。在銀聯做的支付，只能去銀聯退款。特殊的渠道也沒有路由，比如用戶選擇使用支付寶支付，因為支付寶只能在支付寶做支付，所以無需路由。

3. 渠道路由的設計原則

渠道路由作為支付系統的核心模塊，需要滿足以下幾個設計原則：

• 靈活性：路由規則需要支持動態調整。從業務的角度出發，有些場景考慮成本，有些場景考慮成功率，都能方便支持。
• 擴展性：設計時要考慮到未來可能新增的支付渠道，新增的決策因子，這些都不能在代碼中寫死，確保系統易于擴展。
• 高可用性：路由系統本身需要具備高可用性，確保在高并發和故障情況下仍能穩定運行，哪怕內部報錯，仍然能返回一條可用的渠道。
• 性能：在保證準確性的前提下，路由決策需要快速，不能成為支付流程的瓶頸。

4. 業界常見的幾種路由形態

根據業務的需要，通常有以下幾種路由形態：

1. 硬編碼取第一個。在項目上線初期，為了趕進度，同時渠道也不多，常常在代碼中寫死取第一個，先保證支付主流程能走通。
2. 基于規則的路由。通過預定義的規則提高靈活性和可擴展性。
3. 智能路由。利用機器學習和大數據分析，根據歷史數據和實時狀態，智能地選擇最佳渠道。

5. 一種典型的基于規則的渠道路由設計

基于規則的渠道路由是最常見的設計。簡單地說，就是符合什么條件就執行什么樣的分流邏輯。比如：支付平臺對接了網聯和銀聯，招行信用卡全部走網聯，工行信用卡500塊以內的走網聯，500塊以上的走銀聯。

5.1.?核心流程設計

說明：

1. 先進行唯一渠道判斷，如果只有一條渠道，直接返回。
2. 判斷規則，如果規則沒有命中，那就從可用渠道中隨機挑選一條。
3. 如果命中規則，再根據規則中的分流邏輯進行分流。
4. 最后返回唯一的一條渠道。

5.2. 分流算法設計

如果一個請求既可以走銀聯，也可以走網聯，還可以走直連，有以下幾種情況：

1. 沒有命中任何一條規則，隨機選擇一條渠道。
2. 有多條規則可以命中，選擇優先級最高的。
3. 命中的路由規則里，銀聯和網聯分別是40%和40%，直連20%，根據規則分流。如果當前銀聯掛了，把銀聯按比例分配到網聯和直連。

常見的分流算法是先把各渠道的分流比例換算成0-100區間的數字，從大到小排序，再根據用戶ID取模、請求單號取?；蛏梢粋€隨機數，再看這個數落在哪個區間，對應的渠道就是命中的渠道。

偽代碼如下：

int random = 用戶ID取模（或請求單號取模，或生成隨機數）;
for (int i = 0; i < 分流集合.size(); i++) {
    if (random -= 分流集合[i] <= 0) {
        return 命中的渠道;
    }
}

5.3.?路由規則配置模型

說明：

1. 路由規則用于規則引擎運算是否命中。核心字段包括：規則ID、規則類型、規則表達式、優先級。實際實現時可根據各公司內部情況加字段。

1. 規則ID：用于分流配置做關聯；
2. 規則類型：用于區分支付、實名認證等。
3. 規則表達式：用于規則引擎運算；
4. 優先級：用于排序，如果有多個規則都符合，以優先級最高的為準；
5. 分流配置用于規則命中后，如何進行分流。核心字段包括：規則ID、渠道名、分流比例。

1. 規則ID：用于與路由規則進行關聯。
2. 渠道名：表示要分流去的渠道。
3. 分流比例：說明有多少流量要分過去。
4. 決策因子定義用于決策的條件。比如卡BIN，卡品牌，金額等。

5.4. 規則引擎選擇

業務的規則引擎有很多，比如大名鼎鼎的Drools等，也可以選擇自研，各公司可以根據自己的技術生態來選擇。

我個人推薦QlExpress。推薦理由：簡單實用。因為路由規則都非常簡單，沒有過于復雜的運算，不需要引入一些很重的規則引擎。

關于QlExpress的資料，可參考官網介紹。

后面會有QlExpress的規則示例。

5.5. 決策子選擇

決策因子就是路由規則匹配的條件，一般有以下幾種：

1. 金額：比如小于某個金額，或大于某個金額。
2. 卡品牌：VISA、MASTER、UPAY等。
3. 發卡行：CMB、ICBC等。
4. 卡類型：借記卡、信用卡等。
5. 卡BIN：某個號段的卡。
6. 業務場景字段：各公司自定，比如線下場景，線上場景等。

5.6. 路由規則示例

規則的編寫和規則引擎強相關。下面以QLExpress做個示例。實際落地時，需要根據自己選擇的規則引擎做改造。

假設：支付平臺對接了網聯和銀聯，要求：

1）招行信用卡全部走網聯。

2）工行信用卡500塊以內（不包含）的40%走網聯，60%走銀聯。

3）工行信用卡500塊以上的走銀聯。

一些基本的變量定義：

銀行名稱：bankName

支付方式：paymentMethod

卡類型：cardType

金額變量：amount

網聯：NUCC

銀聯：UPAY

招行：CMB

工行：ICBC

定義規則：

1. 規則1：paymentMethod=’card’ && cardType=’credit’ && bankName=’CMB’

分流：NUCC：100

2. 規則2：paymentMethod=’card’ && cardType=’credit’ && bankName=’ICBC’ and amount < 500.00

分流：NUCC：40，UPAY：60

3. 規則3：paymentMethod=’card’ && cardType=’credit’ && bankName=’ICBC’ and amount >= 500.00

分流：UPAY：100

5.7. 界面配置示例

下面只是示意一個簡單的路由配置。如果是多層次的與和或關系，需要產品經理做一些稍微復雜一點的界面。

說明：

1. 示例規則的業務訴求：工行信用卡500塊以內（不包含）的40%走網聯，60%走銀聯。
2. 后臺保存的規則為：“paymentMethod=’card’ && cardType=’credit’ && bankName=’ICBC’ and amount < 500.00”，分流有2兩條，分別是：“NUCC：40”，“UPAY：60”。
3. 用于決策因子的元數據，需要提前定義好，包括這些字段的運算規則（比如開戶行就不能使用大于、等于）。

5.8. 一些調優思路

1. 用戶最近支付成功記錄優先，提高成功率。比如用戶可以用銀聯，也可以使用網聯，如果5天內最近一次使用了銀聯是成功的，那么為了成功率，可以考慮再次路由到銀聯去。因為從渠道風控的角度，已經成功的前提下，再次成功的可能性更大（余額不足除外）。
2. 根據用戶ID做分流，而不是當前訂單號做分流，或者完全隨機數。也就是使用偽隨機。好處是同一個用戶更大概率走到同一個渠道，有利于提高成功率，進而提升用戶體驗。
3. 適當使用緩存，以提高運算速度。

6. 加入自動化開關的渠道路由

外部渠道服務經常不穩定，通過自動化開關模塊監聽支付引擎或渠道網關的支付結果消息，實時計算渠道的狀態，在渠道出現問題后自動關閉，并推送給渠道路由。

說明：

1. 由自動化開關模塊監聽支付引擎的支付結果消息，每秒計算一次渠道的狀態，在渠道出現問題后，自動關閉，并把結果推送給渠道路由。
2. 渠道關閉后，再發起探測服務，探測成功后，灰度打開渠道。

下圖是渠道自動化渠道開關的示意圖。有多種技術手段可以實現，基本原理就是基于滑動時間窗口算法來做，具體落地可以使用時序數據庫，或者自己通過redis實現。

說明：

1. 初始是完成打開。
2. 指定時間內全部失敗或指定時間內成功率低于閥值，關閉渠道。
3. 指定時間后，發起查詢，如果查詢渠道失敗，持續關閉。
4. 如果查詢成功，就灰度打開，如果灰度打開后的成功率不滿足要求，就繼續關閉。
5. 如果灰度打開后的成功率滿足要求，就持續加大灰度，直到完成打開。

后面會單獨起一篇文章來講自動化渠道開關的設計與實現。

7. 高階的智能路由

一些有實力的公司，通過算法和機器學習來做智能路由。所謂智能路由，就是不僅是根據路由規則來計算路由，而是根據當前的請求參數和渠道數據，綜合成功率、成本、用戶使用習慣、地域等多因子計算出最優的一條渠道。

這個方案有幾個難題不好解決。

首先是公司實力足夠強。有人才來做算法，且這些算法同學需要懂一點業務；

其次是經驗不好總結。比如成功率提升了2%，是因為什么原因提升了？有一些不可解釋性。

最后業務無法直接操作調優。比如有些場景下業務希望保成功率，有些場景下業務希望保較低的成本，智能路由如何調參？

我個人更傾向于【規則路由 + 離線數據分析】的組合。其中離線數據分析平臺可以引入一些算法來分析各因子對成功率的影響，供業務人員決策，并調整路由規則。

說明：

1. 通過分析數據，找到影響成功率成本的因子。
2. 更新路由規則。
3. 重復第1步。

8. 結束語

渠道路由在現代支付系統中扮演著至關重要的角色，一個高效、靈活的渠道路由設計能夠顯著提升支付成功率，優化成本，并改善用戶體驗。通過本文的介紹，希望能為大家在實際項目中設計和實現渠道路由提供一些有益的參考。

本文轉自 微信公眾號@隱墨星辰