https://www.sohu.com/a/235139911_575744
前言
用户在一些P2P公司进行充值投资经常会收到手机短信提示输入手机验证码完成支付。细心的用户往往会发现，在不同的时间，不同的金额进行充值投资时，往往收到的短信验证码会略有不同。
这些前缀可能是“宝付支付”，“连连支付”，“易宝支付”等等。其实这背后是有一个支付路由在替用户选择一个最合适的支付通路完成支付。本文旨在揭示与阐述支付系统背后的路由设计与实践。
支付路由存在的意义
如前言所展示的替用户选择一个合适的充值渠道只是支付路由的冰山一角。
事实上，一个健壮，设计良好的支付路由存在的意义包括但不限于：
A. 降低公司的支付成本：不同支付通道有着不尽一致的支付成本，支付路由旨在尽可能择出一个对于公司而言节省成本的方案。
B. 保证支付成功率：对于投资用户而言，支付成功率是用户体验的重要组成部分。良好的支付成功率可以使用户投资顺畅，对于借款用户而言，支付成功率是投资用户的投资收益，以及借款按时计划还款的重要组成部分。
C. 支持个性化的支付定制：例如对于渠道灰度切换，特定银行特定渠道优先，或是渠道每日限额控制，A/B 测试，脚本定制。这些个性化的渠道方案定制策略都希望可以在路由系统中被考虑和实施。
D. 计算支付整体方案的能力：不仅仅计算单一的支付通道，而是拥有计算一个完成支付方案的能力。
E. 闭环控制：设计良好的支付路由系统应该有闭环控制的能力，能够根据外界环境的变化（比如渠道/银行维护，断路）而对于相同的输入参数给出不同的输出结果。从而降低公司整体的运营成本。
支付路由设计需要考量的因素
对于一个支付路由而言，设计时需要考量的因素有哪些呢？
本章会从系统的输入与输出入手，阐述支付路由中需要考量的业务因素，继而推出路由算法以及背后的整体流程方案。
A. 系统的输入与输出
对于任何一个系统设计而言，首先需要明确系统的边界在哪里。支付路由可以简化为公式：y=f(x).其中y =支付方案，x =支付请求。
支付请求：支付请求包括需要执行的支付金额，使用的银行卡，以及对应的产品。举例：(张三，银行卡A, 充值, 2000元)。 这是一个典型的投资者行为。张三在有一张绑定的银行卡A, 希望投资充值2000元。复杂一点的, (李四，银行卡A, 银行卡B, 代扣，7000元)。对应的业务可能是李四是借款人，登记了银行卡A和银行卡B，期望这次还他的贷款7000元。
支付方案：支付方案包括支付金额，使用的银行卡，渠道。对应支付请求中的例子。可能是：(张三， 银行卡A, 2000元，连连支付)。于是张三手机上收到连连支付发送给他的短信验证码。对应第二个例子复杂一点, 结果是: [(李四，银行卡A, 3000元， 宝付支付), (李四，银行B, 2000元，网易支付), (李四，银行卡B, 2000元，网易支付)]。表示这里会执行三次代扣，分别是通过宝付在银行卡A扣款3000元，通过网易在银行卡B分别扣款2000元。
B. 路由业务：
我们将具体的业务因素定义为两大类：过滤性因素以及选择性因素。
过滤性因素指在一个支付方案在这个因素不被满足时，则整个系统就不会采纳这个支付方案，选择性因素指在多个支付方案可以在这个因素上进行比较，从而很大因素上影响支付方案结果的产生。
典型的过滤性因素包括但不限于以下几类：
▪渠道/银行维护：渠道和银行并不是总是在 7*24小时内保持有效。大部分时候渠道/银行会提前知会公司有关维护信息。
▪ 渠道银行限额：不同渠道银行在不同的支付产品下会有不同的限额设置，限额包括单笔限额，单日限额，单月限额。
▪ 渠道银行交易频率限制：对于特定的渠道, 单卡的每日交易次数也是有所限制。
▪ 渠道用户绑卡情况限制：某些支付产品，渠道是需要先绑卡后使用，对于绑卡失败的用户，该渠道并不能被使用。
▪ 可用渠道配置限制：系统管理员可以根据公司签署的渠道和产品，在系统中配置相应产品对应的多种渠道。对于不在配置列表的方案，则不应予以采纳。
▪ 白名单/黑名单限制：支付请求可以对应相应的白名单和黑名单请求，表示在指定的渠道/指定以外的渠道内进行选择。
典型的选择性因素包括但不限于以下几类：
▪ 渠道费率：对于不同的渠道，相同的支付请求往往会对应不同的支付费率。费率比较是支付路由的核心比较之一。
▪ 渠道成功率：不同的渠道由于其技术,运营水平的差异，往往对应不同的支付成功率。成功率比较也是支付路由的核心比较之一。
C.路由算法：
路由系统是否可以支持费率优先，或者成功率优先，或是其他更复杂的算法呢？在本章B中的选择性因素只能给出对于一个具体的维度上，多个方案的排名优劣。但是并没有回答这个排名优劣如何作用于一个最终的决策。本文给出两个经典的常用算法：
🔘锦标赛算法：
锦标赛赛决出优胜者的方式是，通过一轮又一轮的比赛，在每一轮的比赛中，失败者淘汰，优胜者晋级直至最终冠军的产生。
举例: 一个锦标赛的路由算法配置：[费率优先，渠道成功率优先]. 表示这次比赛，所有的候选方案都先进行费率优先的比较，而后进行成功率优先的比较。
在A中张三投资2000元有三个方案参与了比赛，分别是S1: （张三， 银行卡A, 2000元，连连支付），S2: （张三， 银行卡A, 2000元，宝付支付），S3（张三， 银行卡A, 2000元，易宝支付）。 S1费率0.5元，S2费率0.5元，S3费率0.8元。则第一轮在费率上的比赛 S3出局，继续S1和S2的成功率比赛。S1成功率99.1%, S2成功率99.9%。则优胜者为S2. 最终张三收到连连支付发送的短信验证码. 锦标赛算法本质上这是一个偏序比较的算法。
🔘循环赛算法：
循环赛决出优胜者的方式是：所有候选者都参与每一轮的比赛，根据排名座次分别取得一定的积分。最终所有候选人根据总积分决定优胜者。
举例：一个循环赛的配置是：费率排名第一的得3.5分，第二得2分，第三得1分。成功率第一得4分，第二得2分，第三得1分。在这种设置下，假设S1在费率得1分，成功率得4分。总得分5分。而S2在费率得2分，在成功率得2分。总得分4分。则最终S1胜出。说明虽然S1费率最差，但是成功率的领先让其在路由中被择出。而如果S2在费率中排名第一，则S2的成绩从4分变为5.5分。则S2胜出了。说明在巨大的费率优势下，整个路由系统判定S2虽然成功率低一点但是也值得一试。循环赛算法本质上是一个权重比较的算法。
🔘自定义算法：
所有参与排序的方案在各个选择性因素上都可以得到一个通用的排名以及各个不同的比较结果参数。比如在费率的比较上，各个候选方案可以得到排名以及相对应的费率。在成功率的比较上，
也可以得到相应的排名和预测成功率数值。以下是公式定义与推导：
计费率优先算法为f1:
计成功率优先算法为f2:
则任何路由算法可以定义并且实现为f3:
D.系统流程
为了支持A中李四的例子，整个支付路由系统被设计成可重复迭代计算的流程。 以下设计为例：
当一个输入进入到路由系统时。对于此输入我们分配了若干的候选方案。经过金额结算器（Amount Decision Maker）计算出每个候选方案的支付金额。
而后经过过滤器（Filter Decision Maker）会根据渠道银行限额，渠道银行维护，黑名单，白名单等可配置的各种过滤性因素（见本章B的讨论）排除掉一些不合适的方案。
之后进入选择过滤器（Decision Comparator Maker）. 选择过滤器由两部分组成，一部分是业务的选择性因素(见本章B的讨论)，一部分是路由算法(见本章C的讨论)。
最终选出一个合适的候选方案。最终进入中断结算器（Terminal Decision Maker）。 中断结算器的作用是根据输入参数，和计算出的候选者（解）决定是否还需要迭代计算。
对于本章A中张三的例子，中断决算器判定不需要再迭代计算了。所以第一个候选方案就是最终方案（单解）。
而对于本章A中李四的例子，中断结算器在前两次的计算中判定还需要迭代出新的方案。所以最终可以看到完整的支付方案是包括三个解的解集（复解）。
E.系统扩展
根据高内聚，低耦合的软件设计原则，由本章D的设计图可知，无论是对于过滤性因素，还是选择性因素或者是路由算法。整个系统是可以被实现为可配置化的路由决策系统。在关键的组件上，还可以实现DSL用户自定义编程，从而系统可以拥有线上灵活更改路由的能力。下图即为一个路由策略的配置参数：
对于二次开发而言，开发人员也只需要根据业务增加新的过滤性因素，或者编写新的路由算法/脚本（或引入规则引擎）。线上人员只需要通过配置就可以引入这些新的功能。
整个支付系统还可以考虑针对不同渠道的返回或者自定义的计算方式决定打开/关闭某些渠道，或者动态调整渠道银行限额。从而使得路由系统拥有闭环控制的能力。
结语
支付路由作为支付系统的“大脑”，并不是简单的if-else的堆砌。
希望本文可以抛砖引玉，欢迎同行一起讨论更多的类似解决方案。