說明：

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

再詳細一點，如下：

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

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

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

2.?渠道路由核心作用

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

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

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

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

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

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

3. 渠道路由的設計原則

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

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

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

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

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

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

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

5.1.?核心流程設計

說明：

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

5.2. 分流算法設計

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

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

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

偽代碼如下：

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

5.3.?路由規則配置模型

說明：

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

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

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

5.4. 規則引擎選擇

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

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

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

后面會有QlExpress的規則示例。

5.5. 決策子選擇

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

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

5.6. 路由規則示例

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

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

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

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

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

一些基本的變量定義：

銀行名稱：bankName

支付方式：paymentMethod

卡類型：cardType

金額變量：amount

網聯：NUCC

銀聯：UPAY

招行：CMB

工行：ICBC

定義規則：

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

分流：NUCC：100

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

分流：NUCC：40，UPAY：60

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

分流：UPAY：100

5.7. 界面配置示例

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

說明：

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

5.8. 一些調優思路

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