路由系统的价值
路由从作用上来说，即是根据一系列规则获取目标结果的过程。
直白点，就是根据一个一个条件去做匹配，最终匹配到目标结果，这与我们通常做判断，做选择的过程完全一致。
为什么
那么我们或者系统为什么要做判断，做选择？
显而易见，是因为可选项多，而且往往不止一个。而对于支付机构，出于以下原因，必定会对接多个网银、快捷、代扣、代付、实名认证渠道：
服务能力方面，保证渠道的多样性，提高交易成功率，增强服务能力，比如，支持更多银行的银行卡，毕竟单个渠道支持的银行是有限的；
风险控制方面，预防渠道方做升级或者其他原因，被停交易，没有渠道可用；
运营方面，差异化渠道配置，增加支付机构自身的收入；
其他……
核心作用
对接了那么多渠道，路由就有了存在的意义，它的作用有两个：
一个是渠道筛选；一个是帮公司省钱（至于路由的稳定性、扩展性、性能等，是路由自身的问题，与产品设计有关，也与应用架构有关，并不是路由存在的价值，这里暂不讨论）。
渠道筛选，是对路由最基本的要求，即筛选出所有符合当前交易要求的渠道，由于存在多个渠道，也就是存在备用渠道，所以可以提高交易成功率；
帮公司省钱，这是在基本要求的基础上，路由存在的最重要的意义，为了达到这个目的，路由模块中需要增加一个计算模块，计算出所有筛选出的符合当前交易要求的渠道的渠道成本，并按照渠道成本从小到大的顺序排列，交易自然就可以先发往渠道成本最低的渠道，降低公司的成本，增加公司的收入。
路由的实现
1. 筛选渠道的方式
路由筛选渠道的方式，一般分为三种：
人工路由：这种方式适合渠道很少的情况，随着渠道增多，这种方式就不适合了；
规则路由：一般可以通过收集到的条件，进行数据库查询的时候，自行匹配出合适的渠道，并完成优劣选择，这是最常用的方式；
基于权重的路由：这种方式比较复杂，且权重的设置需要不断的尝试，也可能针对不同的场景还要有多套权重设置方案，实操起来并不简单。
由于基于权重的路由实操起来很难，所以路由设计一般会将人工路由和规则路由一起使用，规则路由为主，人工路由为辅，进行人工干预，打破规则路由的规则。
2. 筛选渠道的要素
规则路由筛选渠道的要素，可以分为以下三类：
商户侧：商户ID（根据商户的等级、商户行业、商户地域等信息为商户配置渠道之后，在调用路由模块时，只需要上传商户ID即可，如果有共用的渠道可以使用的话，则可能需要上传商户的更多信息）；
业务侧：交易时间、交易金额（单笔、汇总、阶梯）、渠道类型、卡类型、交易银行；
渠道侧：费率（单笔、汇总、阶梯）、营销（优惠、折扣、补贴总金额、活动时间）、渠道等级（稳定性、TPS、掉单率、到账时效）、资金头寸（只在付款的交易中需要考虑）。
3. 路由设计
后台服务型系统的设计一般都逃不过三个范围：业务流程、管理页面、接口。
业务流程
业务流程是后台服务型系统模块的核心，它规定了该系统模块的业务处理逻辑；
管理页面
管理页面是操作员进行系统模块的管理入口，通常用来进行必要的信息设置，以及查看该模块产生的日志信息；
接口
接口是供其他系统模块请求本系统模块的入口，接收到请求之后，本系统模块即会按照既定的业务流程，进行业务处理，并返回处理结果。
支付路由也属于后台服务型的系统模块，它的业务流程一般分布在来自管理页面的配置和接口的调用当中，不存在自动化的业务处理。
其中，管理页面的功能范围，要有对应上述业务侧和渠道侧信息的渠道入驻管理（包括关停、启用）、以及商户和渠道之间建立关联关系的管理功能；
接口则是在被调用的时候，根据请求参数和筛选出的各渠道的成本排序，完成成本最低的最优渠道选择，并在接口被同一笔订单多次调用的时候，依次返回最优、次优渠道，直到可选渠道全部尝试完毕（如果系统本身进行了尝试渠道次数的限制；比如限制3次，则另当别论；另外对于付款交易，为了防止资金损失，一般不建议在调用一个渠道失败之后，调用另一个渠道）。
个人所见，以上就是路由模块的共性部分，具体到每个公司的方案实施，可能会有按照渠道成功率等信息进行渠道优劣分级的功能，可能会要求有阶梯费率的情况，可能会要求先调用指定渠道再调用渠道成本最低的渠道。
路由的使用
我们正常生活中会收款、也会付款，对应在支付系统中，则存在收款和付款的正向和反向交易，那么在这两种情景下，路由在交易的过程中所处的位置相同吗？
如下图，从正反向交易信息流来看，路由在交易过程中所处的位置显然是不同的，唯一的相同点是路由总是在收付款渠道之前且中间没有其他系统模块。
正向交易
忽略收付款渠道和清结算，可以看到正向交易信息流是：订单系统→风控→支付路由→记账；
正向交易信息流中，支付路由之所以在记账之前，是因为我们（支付公司）不可能还没有收到钱，就先记下收了钱，要是突然被找了个借口，又被拖着；
收不到钱呢？白白记了账，记得划掉还是好的，要是忘了划掉，可能就真以为已经收了钱。
这就是为什么正向交易中，支付路由要在记账之前的原因。
反向交易
反向交易信息流是：订单系统→风控→记账→支付路由。
明显的差别就是支付路由和记账的位置发生了变化。
反向交易信息流中，记账在支付路由之前，这就相当于角色互换，我们先记下还了钱，下一步还钱成功，皆大欢喜，没还成功，我们也不亏，大不了再还一次。
假如和正向交易一样，支付路由在记账之前，可能的结果会是我们还了钱，但是没有记账，下次还要再还一次，这就造成了亏损，不论对个人，还是对公司来说，亏损都是很难接受的。
个人理解
实际上每一个系统都应该细化为对账+余额+出款。
对账对平之后才进行出款，从而留有一定的缓冲。
代码实现
整体架构
支付路由并不会直接对接前端的支付产品或者后端的支付渠道，它是支付网关的一部分。
如果是基于微服务的架构，支付路由作为一个独立的服务，被支付网关所调用。
计算因子
所有的排序都需要对应的计算因子，这个部分应该是可以页面灵活配置的。
路由规则是支付路由的核心。
在规则设置上，需要和公司的业务、支付服务的 scope 来综合考虑。
这里讲述的是通用的规则设计，供具体实现时参考。
产品类型：当然，路由时首选需要考虑渠道可以支持的支付产品。
费率：费率是路由最重要的一个指标。一般银行是按照额度来收费，部分是按照交易笔数来收费，复杂点的是阶梯收费，比如 10 万一个费率档次，100 万一个费率档次。
优惠活动：银行、第三方支付为了延揽客户，经常也会提供一些补贴给对接的商户，对于使用该渠道的交易进行补贴。而优惠的策略也是多种多样。
交易限额：不同通道会限制每次交易的金额上限，以及针对每个账户每天的额度限制。超过这个额度，需要变换通道。
卡类型：通道支持的信用卡或者借记卡。
通道的 QOS：掉单率、网络延迟以及接口能支持的 TPS，是路由的一个重要衡量因素。
资金头寸：电商公司在银行或者第三方平台的资金头寸。如果资金头寸不足，则不能使用这个通道来执行。
到账时效：对于转账，资金什么时候到目标账户上，也是影响路由选择的一个因素。
商户类型：不同类型的商户可以选择不同的通道。比如高性能、费率高的通道，预留给高级商户。
模块设计
支付路由从架构上来说，一般是作为支付网关的一部分。采用微服务架构时，路由模块作为一个独立的服务来部署，为支付网关所调用。
所涉及的模块如下所示：
支付通道管理：提供通道支持的产品类型、费率等信息。
支付通道 QOS 监控：收集通道使用过程中的错误信息，接口延迟，超时情况等信息，用于统计 QOS。
资金头寸管理：用于监控公司在各个支付通道上的头寸，并提供头寸的信息。
优惠活动：银行、第三方支付为了延揽客户，经常也会提供一些补贴给对接的商户，对于使用该渠道的交易进行补贴。而优惠的策略也是多种多样：
支付策略：针对使用该通道的所有支付进行补贴；仅针对首次使用该通道的用户进行补贴；仅针对绑卡的用户进行补贴。
补贴时，按照支付金额来设置优惠额度，或者按比例打折。
一般活动都会设置补贴总额度。该额度用完了就停止补贴。当然，活动也都会设置开始和截止时间。
路由计算
人工路由
大部分支付系统在接入渠道不多时，人工路由也是一个不错的选择。
运营人员指定支付渠道和产品之间的映射关系。
出问题时人工切换即可。
这种路由的优势是性能高，路由结果可控，出问题时易于排查问题。
当接入通道数量增加，营销活动频繁时，人工路由会是一个巨大的投入。
基于规则的路由
这是相对比较简单的自动路由设计。
按照业务要求设置各种路由规则，比如：
if(支付方式==招商借记卡 && 额度<100) then 目标通道==银联token支付
if(支付方式==招商借记卡 && 额度>100) then 目标通道==招商快捷支付
ps: 这种伪代码的方式对业务人员不够友好，最好是可以页面点击配置的，不要涉及到任何代码。
技术上，规则可以使用 drools 来描述。
基于权重的路由
规则路由的难点各种规则的制定。
在路由因子增多的情况下，规则的维护会是一个噩梦。基于权重的路由则可以缓解这个问题。
这种计算方式，简单说，就是对各个通道打分，分数最高的就命中。难点在于制定打分的标准以及计算公式。
比如可以从费率、优惠额度、QOS 和使用率角度来评分，给优惠额度高一点的比重，这会导致高优惠额度的通道被优先命中。
注意每个维度上的计算公式也不是一成不变的，比如使用率和 QOS 都是动态打分计算。
权重的调整是一个挑战，需要在运行过程中不断的调试。必要时，可以使用旁路测试来比较两种算法的优劣。
路由是支付的核心模块，稳定性是第一要素，其次是性能，最后才是怎么省钱。
路由系统的设计，需要和公司业务发展保持一致，并适度超前。
简单的 if else 实现可以满足大多数场景下的需求，应该尽量避免在系统建设初期引入过于复杂的路由。
需要考虑的因素
对于一个支付路由而言，设计时需要考量的因素有哪些呢？
本章会从系统的输入与输出入手，阐述支付路由中需要考量的业务因素，继而推出路由算法以及背后的整体流程方案。
系统的输入与输出
对于任何一个系统设计而言，首先需要明确系统的边界在哪里。
支付路由可以简化为公式：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元。
路由业务：
我们将具体的业务因素定义为两大类：过滤性因素以及选择性因素。
过滤性因素指在一个支付方案在这个因素不被满足时，则整个系统就不会采纳这个支付方案，选择性因素指在多个支付方案可以在这个因素上进行比较，从而很大因素上影响支付方案结果的产生。
过滤性因素
典型的过滤性因素包括但不限于以下几类：
-
渠道/银行维护：渠道和银行并不是总是在 7*24小时内保持有效。大部分时候渠道/银行会提前知会公司有关维护信息。
-
渠道银行限额：不同渠道银行在不同的支付产品下会有不同的限额设置，限额包括单笔限额，单日限额，单月限额。
-
渠道银行交易频率限制：对于特定的渠道, 单卡的每日交易次数也是有所限制。
-
渠道用户绑卡情况限制：某些支付产品，渠道是需要先绑卡后使用，对于绑卡失败的用户，该渠道并不能被使用。
-
可用渠道配置限制：系统管理员可以根据公司签署的渠道和产品，在系统中配置相应产品对应的多种渠道。对于不在配置列表的方案，则不应予以采纳。
-
白名单/黑名单限制：支付请求可以对应相应的白名单和黑名单请求，表示在指定的渠道/指定以外的渠道内进行选择。
选择性因素
典型的选择性因素包括但不限于以下几类：
-
渠道费率：对于不同的渠道，相同的支付请求往往会对应不同的支付费率。费率比较是支付路由的核心比较之一。
-
渠道成功率：不同的渠道由于其技术,运营水平的差异，往往对应不同的支付成功率。成功率比较也是支付路由的核心比较之一。
路由算法
路由系统是否可以支持费率优先，或者成功率优先，或是其他更复杂的算法呢？
在本章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的设计图可知，无论是对于过滤性因素，还是选择性因素或者是路由算法。
整个系统是可以被实现为可配置化的路由决策系统。
在关键的组件上，还可以实现 DSL 用户自定义编程，从而系统可以拥有线上灵活更改路由的能力。
下图即为一个路由策略的配置参数：
不要过度设计
支付路由作为支付系统的重要模块，对配置人员的要求会稍高一些，管理页面的设计应该尽可能的考虑使操作简单化；
路由的设计也没有必要追求复杂，满足公司的业务发展即可，应着重关注路由的稳定性和性能；路由的设计和使用一定要避免产生资金损失的可能。
