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

·  阅读 1778

前言

支付系统的相关系统给大家已经写了几篇了,如果喜欢的话,可以给六六一个赞哦,下面是之前写的

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

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

什么是支付路由

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

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

支付路由的作用

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

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

路由按服务特点分类

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

路由的实现

筛选渠道的方式

路由筛选渠道的方式,一般分为三种:

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

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

筛选渠道的要素

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

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

路由设计

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

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

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

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

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

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

支付路由怎么设计的?

image.png

通道路由.jpg

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

image.png

命中

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

image.png

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

优先级

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

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

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

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

可用性判断

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

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

成本计算

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

权重

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

结束

好了,支付系统的路由设计给大家分享到这个,这个系统不是支付系统的必须模块,但是如果你的支付系统到了一定的规模就要设计做了,好了,今天到这里了,我是小六六,三天打鱼,两天晒网

我正在参与掘金技术社区创作者签约计划招募活动,点击链接报名投稿

分类:
后端
标签:
收藏成功!
已添加到「」, 点击更改