图解支付系统的渠道路由设计
在现代支付系统中，渠道路由扮演着至关重要的角色，它决定了支付请求在多个可用渠道中的最佳路径。本文将深入探讨渠道路由的基本概念、核心作用以及设计原则，并通过实际案例分析，展示如何构建一个既灵活又高效的渠道路由系统。
这篇文章主要讲清楚：渠道路由是什么，为什么需要渠道路由，渠道路由的几种形态，一个简洁而实用的基于规则的渠道路由设计。
注：有些公司称渠道为通道，都是一个意思，为方便起见，本文统称为渠道。
01 一些背景知识
有些支付公司没有区分支付方式咨询、渠道咨询、渠道路由，而是混在一起做掉，这样的好处是简单而实用，缺点是扩展性不足。下面将以扩展性最好的拆分方式来讲解。
下面是三者之间的简单关系图：
说明：
- 支付方式咨询：根据用户的请求，组装可用支付方式列表返回给用户。由收银域提供服务。
- 渠道咨询：根据用户的请求，组装可用的渠道列表和渠道属性返回给收银域，再由收银域转换为支付方式返回给用户。由渠道网关提供服务。
- 渠道路由：当有多个渠道可用时，选择出最优的一个渠道。由渠道网关提供服务。
再详细一点，如下：
- 支付方式咨询：解决用户可以使用哪些支付方式，比如余额、招行借记卡、招行信用卡等。比如虚拟商品不能使用信用卡，这种支付方式的管理就是支付方式咨询的职责。
- 渠道咨询：解决是否有渠道可以支持当前的支付行为。比如用户绑定了招行借记卡，但招行当前正在维护无法提供服务，那就将渠道状态设置为不可用，收银域对应的支付方式会置灰。
- 渠道路由：解决最优渠道问题。需要综合支付成功率、支付成本、用户体验、渠道状态等多种因素挑选出最优的一条渠道。
02 渠道路由核心作用
渠道路由核心作用是当有多个渠道同时满足业务诉求时，综合支付成功率、支付成本、用户体验、渠道状态等多种因素挑选出最优的一条渠道。具体如下：
- 提高支付成功率：通过选择最合适的渠道，可以提高支付的成功率，减少支付失败带来的用户流失。原因在于不同的渠道在其内部的风险偏好是不一样的，同一个请求在A渠道会失败，但在B渠道会成功。
- 优化成本：不同渠道的费用可能不同，通过合理的路由，可以降低支付成本。一些渠道还有阶梯收费，需要通过分流不同的渠道，保持整体成本最优。
- 提升用户体验：快速、稳定的支付体验能增强用户的满意度和忠诚度。用户如果经常在A渠道支付，新的请求过来后，仍然发给A渠道支付的成功率往往会更高。
- 负载均衡：将支付请求合理分配到不同的渠道，避免某个渠道过载，提升整体系统的稳定性。
举几个渠道路由应用的小场景：
- 用户使用招行信用卡支付，支付平台同时对接了网联和银联，而网联和银联都支持招行信用卡，那么就需要渠道路由挑选一个渠道。
- 做实名认证，平台对接了多个实名认证通道，通过渠道路由挑选一个认证渠道。
由上面可以看到，除了支付路由外，还可能有信息类渠道路由，比如实名认证类。
那退款有没有路由？显示没有。在银联做的支付，只能去银联退款。特殊的渠道也没有路由，比如用户选择使用支付宝支付，因为支付宝只能在支付宝做支付，所以无需路由。
03 渠道路由的设计原则
渠道路由作为支付系统的核心模块，需要满足以下几个设计原则：
- 灵活性：路由规则需要支持动态调整。从业务的角度出发，有些场景考虑成本，有些场景考虑成功率，都能方便支持。
- 扩展性：设计时要考虑到未来可能新增的支付渠道，新增的决策因子，这些都不能在代码中写死，确保系统易于扩展。
- 高可用性：路由系统本身需要具备高可用性，确保在高并发和故障情况下仍能稳定运行，哪怕内部报错，仍然能返回一条可用的渠道。
- 性能：在保证准确性的前提下，路由决策需要快速，不能成为支付流程的瓶颈。
04 业界常见的几种路由形态
根据业务的需要，通常有以下几种路由形态：
- 硬编码取第一个。在项目上线初期，为了赶进度，同时渠道也不多，常常在代码中写死取第一个，先保证支付主流程能走通。
- 基于规则的路由。通过预定义的规则提高灵活性和可扩展性。
- 智能路由。利用机器学习和大数据分析，根据历史数据和实时状态，智能地选择最佳渠道。
05 一种典型的基于规则的渠道路由设计
基于规则的渠道路由是最常见的设计。简单地说，就是符合什么条件就执行什么样的分流逻辑。比如：支付平台对接了网联和银联，招行信用卡全部走网联，工行信用卡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. 路由规则配置模型
说明：
1）路由规则用于规则引擎运算是否命中。核心字段包括：规则ID、规则类型、规则表达式、优先级。实际实现时可根据各公司内部情况加字段。
- 规则ID：用于分流配置做关联；
- 规则类型：用于区分支付、实名认证等。
- 规则表达式：用于规则引擎运算；
- 优先级：用于排序，如果有多个规则都符合，以优先级最高的为准；
2）分流配置用于规则命中后，如何进行分流。核心字段包括：规则ID、渠道名、分流比例。
- 规则ID：用于与路由规则进行关联。
- 渠道名：表示要分流去的渠道。
- 分流比例：说明有多少流量要分过去。
3）决策因子定义用于决策的条件。比如卡BIN，卡品牌，金额等。
5.4. 规则引擎选择
业务的规则引擎有很多，比如大名鼎鼎的Drools等，也可以选择自研，各公司可以根据自己的技术生态来选择。
我个人推荐Aviator。推荐理由：简单实用。因为路由规则都非常简单，没有过于复杂的运算，不需要引入一些很重的规则引擎。
关于Aviator的资料，可参考官网介绍。
后面会有Aviator的规则示例。
5.5. 决策子选择
决策因子就是路由规则匹配的条件，一般有以下几种：
- 金额：比如小于某个金额，或大于某个金额。
- 卡品牌：VISA、MASTER、UPAY等。
- 发卡行：CMB、ICBC等。
- 卡类型：借记卡、信用卡等。
- 卡BIN：某个号段的卡。
- 业务场景字段：各公司自定，比如线下场景，线上场景等。
5.6. 路由规则示例
规则的编写和规则引擎强相关。下面以Aviator做个示例。实际落地时，需要根据自己选择的规则引擎做改造。
假设：支付平台对接了网联和银联，要求：
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. 界面配置示例
下面只是示意一个简单的路由配置。如果是多层次的与和或关系，需要产品经理做一些稍微复杂一点的界面。
说明：
- 示例规则的业务诉求：工行信用卡500块以内（不包含）的40%走网联，60%走银联。
- 后台保存的规则为：“paymentMethod=’card’ && cardType=’credit’ && bankName=’ICBC’ and amount < 500.00”，分流有2两条，分别是：“NUCC：40”，“UPAY：60”。
- 用于决策因子的元数据，需要提前定义好，包括这些字段的运算规则（比如开户行就不能使用大于、等于）。
5.8. 一些调优思路
- 用户最近支付成功记录优先，提高成功率。比如用户可以用银联，也可以使用网联，如果5天内最近一次使用了银联是成功的，那么为了成功率，可以考虑再次路由到银联去。因为从渠道风控的角度，已经成功的前提下，再次成功的可能性更大（余额不足除外）。
- 根据用户ID做分流，而不是当前订单号做分流，或者完全随机数。也就是使用伪随机。好处是同一个用户更大概率走到同一个渠道，有利于提高成功率，进而提升用户体验。
- 适当使用缓存，以提高运算速度。
06 加入自动化开关的渠道路由
外部渠道服务经常不稳定，通过自动化开关模块监听支付引擎或渠道网关的支付结果消息，实时计算渠道的状态，在渠道出现问题后自动关闭，并推送给渠道路由。
说明：
- 由自动化开关模块监听支付引擎的支付结果消息，每秒计算一次渠道的状态，在渠道出现问题后，自动关闭，并把结果推送给渠道路由。
- 渠道关闭后，再发起探测服务，探测成功后，灰度打开渠道。
下图是渠道自动化渠道开关的示意图。有多种技术手段可以实现，基本原理就是基于滑动时间窗口算法来做，具体落地可以使用时序数据库，或者自己通过redis实现。
说明：
- 初始是完成打开。
- 指定时间内全部失败或指定时间内成功率低于阀值，关闭渠道。
- 指定时间后，发起查询，如果查询渠道失败，持续关闭。
- 如果查询成功，就灰度打开，如果灰度打开后的成功率不满足要求，就继续关闭。
- 如果灰度打开后的成功率满足要求，就持续加大灰度，直到完成打开。
后面会单独起一篇文章来讲自动化渠道开关的设计与实现。
07 高阶的智能路由
一些有实力的公司，通过算法和机器学习来做智能路由。所谓智能路由，就是不仅是根据路由规则来计算路由，而是根据当前的请求参数和渠道数据，综合成功率、成本、用户使用习惯、地域等多因子计算出最优的一条渠道。
这个方案有几个难题不好解决。
首先是公司实力足够强。有人才来做算法，且这些算法同学需要懂一点业务；
其次是经验不好总结。比如成功率提升了2%，是因为什么原因提升了？有一些不可解释性。
最后业务无法直接操作调优。比如有些场景下业务希望保成功率，有些场景下业务希望保较低的成本，智能路由如何调参？
我个人更倾向于【规则路由 + 离线数据分析】的组合。其中离线数据分析平台可以引入一些算法来分析各因子对成功率的影响，供业务人员决策，并调整路由规则。
说明：
- 通过分析数据，找到影响成功率成本的因子。
- 更新路由规则。
- 重复第1步。
8. 结束语
渠道路由在现代支付系统中扮演着至关重要的角色，一个高效、灵活的渠道路由设计能够显著提升支付成功率，优化成本，并改善用户体验。通过本文的介绍，希望能为大家在实际项目中设计和实现渠道路由提供一些有益的参考。
