支付路由系统设计一：功能简介

支付路由系统设计一：功能简介

技术栈：Java+Groovy+Lua+Springboot+Mysql+Redis+Drools+Velocity+RabbitMQ+Spring Data Jpa

 一、背景

本篇博文，我们来片下支付系统中很重要的一个功能模块--路由系统，当然很多小公司的支付系统可能压根没有这个模块。

先说下路由系统的作用，随着业务不断丰富，支付系统为了满足各种支付场景提供多元化的支付产品，需要对接很多银行、第三方支付机构来为业务方提供服务，随着对接的支付渠道越来越多，支付渠道的管理问题就来了，渠道规则各异，如何从对接的渠道中选择一个可用的、成本最低的支付渠道？当最优通道失败后如何再过滤出次级最优通道？如何将一笔交易进行拆单？等等，都是支付路由可做的事。

这次我们先片第一个：如何从对接的渠道中选择最优的支付渠道？

在片之前，先了解我们的设计背景，元数据信息，以及元数据的关系结构模型，也就是我们的支付渠道，支付渠道支持的交易类型，以及交易类型支持的交易机构(银行)等等，这些是设计路由相关的元数据，其他的响应码映射、机构商户信息等元数据不在此次范围，咱们就暂且忽略。其上三部分信息的关系如图：

表结构关系：

在此不再展开解释了，每个支付公司各有各自的划分维度，比如将对接的一个支付机构再划分为代扣通道、快捷通道等什么的，我们此处为对接的一个支付机构在我们这里就是一个通道，代扣、快捷仅仅是其下的一种交易类型。

二、分析

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

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

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

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

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

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

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

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

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

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

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

三、总结

此篇文章我们片了支付路由大概处理逻辑，下篇我们片使用Drools规则引擎+Velovity模板引擎+Groovy实现命中逻辑，也就是支付路由的核心，最近忙着搞论文，更新日期未定~~