支付设计白皮书：支付系统的路由系统设计

路由从作用上来说，即是根据一系列规则获取目标结果的过程。直白点，就是根据一个一个条件去做匹配，最终匹配到目标结果，这与我们通常做判断，做选择的过程完全一致。

路由器是史上最强“通道挑选官”，可大可小，可弱可强；可有可无，对他就是这么随性潇洒

什么是支付路由

基于支付通道的属性特点和业务系统的要求，为支付交易筛选出符合业务要求的最优的通道；简单的说就是业务系统要收款，你路由器帮我选一条最好的通道吧！这就是路由的职能，为通道选择做决策。

例如你从广州去北京，可以开车，可以坐火车，可以坐高铁，也可以坐飞机，那么根据不同的条件筛选出最符合你的一个方式的方法，我们就可以称之为路由

支付路由的作用

刚才说了，为了选择一条最优的通道，那么作用其实就是：

降低成本：越便宜越好；
提高用户体验：用户支付的越爽越好；
确保有可用通道：这个不行换那个，确保能完成支付。
或者有特殊情况下，可以指定我们的特定通道

路由按服务特点分类

咨询型路由：你问他，他告诉你一条通道；
服务型路由：你问他，他为你选择一条通道，并调用通道完成支付，告诉你支付结果。

路由的实现

筛选渠道的方式

路由筛选渠道的方式，一般分为三种：

人工路由：这种方式适合渠道很少的情况，随着渠道增多，这种方式就不适合了；
规则路由：一般可以通过收集到的条件，进行数据库查询的时候，自行匹配出合适的渠道，并完成优劣选择，这是最常用的方式；
基于权重的路由：这种方式比较复杂，且权重的设置需要不断的尝试，也可能针对不同的场景还要有多套权重设置方案，实操起来并不简单。

由于基于权重的路由实操起来很难，所以路由设计一般会将人工路由和规则路由一起使用，规则路由为主，人工路由为辅，进行人工干预，打破规则路由的规则。

筛选渠道的要素

规则路由筛选渠道的要素，可以分为以下三类：

商户侧：商户ID（根据商户的等级、商户行业、商户地域等信息为商户配置渠道之后，在调用路由模块时，只需要上传商户ID即可，如果有共用的渠道可以使用的话，则可能需要上传商户的更多信息）；
业务侧：交易时间、交易金额（单笔、汇总、阶梯）、渠道类型、卡类型、交易银行；
渠道侧：费率（单笔、汇总、阶梯）、营销（优惠、折扣、补贴总金额、活动时间）、渠道等级（稳定性、TPS、掉单率、到账时效）、资金头寸（只在付款的交易中需要考虑）。

路由设计

后台服务型系统的设计一般都逃不过三个范围：业务流程、管理页面、接口。

业务流程是后台服务型系统模块的核心，它规定了该系统模块的业务处理逻辑；
管理页面是操作员进行系统模块的管理入口，通常用来进行必要的信息设置，以及查看该模块产生的日志信息；
接口是供其他系统模块请求本系统模块的入口，接收到请求之后，本系统模块即会按照既定的业务流程，进行业务处理，并返回处理结果。

支付路由也属于后台服务型的系统模块，它的业务流程一般分布在来自管理页面的配置和接口的调用当中，不存在自动化的业务处理。

其中，管理页面的功能范围，要有对应上述业务侧和渠道侧信息的渠道入驻管理（包括关停、启用）、以及商户和渠道之间建立关联关系的管理功能；

接口则是在被调用的时候，根据请求参数和筛选出的各渠道的成本排序，完成成本最低的最优渠道选择，并在接口被同一笔订单多次调用的时候，依次返回最优、次优渠道，直到可选渠道全部尝试完毕（如果系统本身进行了尝试渠道次数的限制；比如限制3次，则另当别论；另外对于付款交易，为了防止资金损失，一般不建议在调用一个渠道失败之后，调用另一个渠道）。

个人所见，以上就是路由模块的共性部分，具体到每个公司的方案实施，可能会有按照渠道成功率等信息进行渠道优劣分级的功能，可能会要求有阶梯费率的情况，可能会要求先调用指定渠道再调用渠道成本最低的渠道。

支付路由怎么设计的？

在设计之前，我们首先要了解下路由的基本流程，路由在筛选最优渠道时候主要包括五个部分： 命中+优先级排序+可用性判断+成本计算+权重分流

命中

首先我们搞清楚什么叫命中？以及命中维度？所谓命中就是交易参数上送到路由系统，触发规则引擎，查找出哪些渠道可能会支持这笔交易，打个形象描述吧，这个步骤就是警察拿着目击证人对罪犯的描述信息（报文参数），从一群人中找出符合外貌描述的可疑人，并且这些可疑人天生就有罪犯长相，特别是光头，在后期审问时候头发越少越重点关注，先从发量少的的开始审问（规则优先级）；还有的原来蹲过局子，有前科，就算你有一头乌黑亮发，也优于光头先审问，说不准就是惯犯作案呢（强制规则），有的是劳模榜样，国家好青年，则排除（排除规则），取得这些嫌疑人信息后，移交审讯组根据证据确定哪个是罪犯。命中维度问题，也就是锁定嫌疑人范围问题：

如图：我们现在有这三个维度，支付渠道、交易类型、交易机构接着上面比喻吧，（支付渠道-某街道交易类型-某小区交易机构-某单元）在锁定可疑人时，锁定的维度越小，前期警察叔叔做的摸排工作就越多，体现在系统方面就是运营人在后台做的配置就越多越细，对于系统来说也就越耗性能，此处我们命中维度为交易类型，另外两个维度，一个太泛，一个太细，泛即失去了此环节的意义，太细又加重了此环节运营人员的配置和应用处理。

优先级

优先级是什么？继续上例：我们根据发量对嫌疑人进行分组（发量是嫌疑人自有属性，也就是命中的渠道有优先级属性），光头佬组，地中海组，乌黑油亮仔组，但是在进行排序审问前，了解到，其中有一个可疑人员有犯罪前科，那么我们就将其优先盘问，同时有一个刚获取到国家好青年表彰，那么我们从可疑人员中剔除，不在我们的排查范围。

注：很多人这里搞不清楚的一个问题，优先级和可用性问题，笔者公司就是将优先级放到可用性判断规则链里了，作为其中一个处理器，就这么一放，处理性能不知道降低了多少倍。这么设计的问题：没有搞清接口作用，路由系统，主要目的是返回给调用方最优支付渠道，也就是一条渠道，（当然也会有的是返回多条根据优先级进行排序好的可用渠道列表，此处我们不做此讨论），规则链应该是抽取出来的不同校验处理项，根据不同业务线进行组装，但是不管是支付通道过滤也好，签约通道过滤也好优先级必过滤项，都是必过滤一项，所以优先级不应该放入规则链中。

放入规则链中的问题：优先级和其他校验项，比如支持卡类型、公私标识、黑白名单…他们不属于同一层次的东西，笔者公司就是将他们放入同一层次了，先校验了其他校验项目，比如总共有十个校验项优先级排第九项，命中了五个通道，都通过了前面八个校验项，到第九个再根据优先级分组，如果优先级排序最高层次的有一条，中层次有三条，低层次有一条，过了优先级处理器后，就只取最高层次的一条，那么其余四条白过了前八项校验！正确处理姿势，应该是先对命中规则先进行优先级排序，从最高到最低依次流入规则链，如果最高层次有满足的支付渠道，那么就可以退出直接返回了，而不是先判断完所有命中渠道再筛选优先级最高的那条!

支付路由系统作为支付系统里最耗人设计能力的模块，稍有不慎，性能就大打折扣，性能问题，在设计编码时候就应时刻考虑，而不是仅仅完成功能开发，后期系统响应慢，想改都难了。

可用性判断

可用性判断，也就是对命中的渠道进行进一步判断，就像排查可以人当天夜晚在哪里，在干嘛等等，对应支付路由就是校验此交易类型是否支持此交易的卡行、公私类型、限额、此时是否在此渠道的工作时间等等，大概算下来足有二十项左右。首先进入可用性判断的是有前科的嫌疑人，也就是命中的强制规则，经过多方面盘问，最终两种结果，1.自己确实犯事，2.自己清白，如果是自己确实犯事了，流程结束，退出流程，返回此渠道，不再盘问其余可疑人，如果是清白的则开始盘问其他可疑人。

在我们盘问其他可疑人员时，根据分组，我们先从光头佬组开始，两个光头依次盘问，也就是从优先级最高的这组开始，如果此优先级所有渠道都没有经过可用性判断处理链，那么接着盘问地中海组可疑人员，如果此组经过可用性处理链后剩余多个渠道，那么流入下一流程，如果只存在一条则直接返回此渠道，如果不存在接着乌黑油亮仔组，这组还是没有则退出流程，无渠道可用。

成本计算

如果同一优先级经过可用性判断后，剩余多条可用通道，那么我们将在此步骤进行成本计算，根据通道成本规则计算。如果流入此步骤有三个渠道，经过计算后成本分别为：支付宝：1元,微信：2元,易宝：1元,那么经过此流程后剩余通道未：支付宝、易宝，将这两个渠道接着流入下一步骤，如果成本分别为：支付宝：1元,微信：2元,易宝：3元，那么直接返回支付宝渠道，为了降低复杂度，此处我们不讨论渠道成功率、接口响应时间之类的运行时指标，我们目前只讨论运营配置指标，后期讨论运行时指标。

权重

在上步骤经过计算成本后，同一优先级还剩余多个成本一样的可用通道，那么此步骤将做权重，看这笔交易走哪个通道，权重和优先级都是命中渠道的自有属性，权重就是在配置规则时候一个整形数值：比如到此流程时剩余两个渠道：支付宝权重：30 易宝权重：70，也就是这笔交易30%的概率走支付宝，70%的概率走易宝，以此来做分流。