前言
大家好，这篇文章我们介绍一下《渠道路由》的第二部分——重路由。对于支付业务来说，支付成功率是衡量支付服务质量的一个重要指标，而重路由对这个指标的“贡献“可谓是至关重要。除了提升成功率之外，一定程度上还能协助渠道路由降低渠道手续费。假设有两个渠道A和B，A的费率高于B，但成功率没有B高，那么有了重路由的能力我们就可以将B配置为优秀的渠道，如果B失败，那么使用重路由走A通道，这样就能既保证成功率又保证渠道费率不那么的高。但上述场景并不是重路由的主要应用场景，重路由主要解决两类问题导致的交易异常或交易失败问题：第一类，因渠道服务临时不可用或网络问题导致的交易故障，这类问题通过延迟重试大部分都能解决；第二种，支付要素信息正确因渠道能力问题如余额不够导致的交易失败，这类问题需要通过更换渠道重试，大部分也都能解决。下面我们将内容分成两部分来介绍：第一部分我们介绍一下重路由规则的配置项，第二部分我们介绍一下重路由模块的程序设计。
重路由规则
重路由规则由匹配规则和执行规则两部分构成，匹配规则部分定义重路由的适用场景，该部分的配置决定程序什么情况下才允许执行重路由操作，而执行规则定义执行重路由的形式，就是限定程序应该如何执行比如执行几次，是同步还是异步，是否要更换订单号等等，接下来我们解释一下这些配置项。
类型
重路由有原渠道重试和换渠道重试两种，如果算上两种混合的形式那么有三种类型的重路由。原渠道重试主要用来解决渠道临时性的故障，这些故障通常可以在几分钟之后恢复的，那么使用原渠道延迟重试就能满足需求。比如代扣，因为对方网络响应超时，链接被断开导致结果不确定，这种情况如果对方接口支持幂等那么五分钟后重试一下，如果这时对方服务恢复正常，那么就能确定改变交易的状态或者重新向渠道提交交易。换渠道重试主要应用在渠道服务能力受限的情况下如余额不足、限额，这时候只能换渠道上送交易来提高这边交易的成功率。最后，混合形式的重路由场景的特征是期望如果原渠道重试能恢复，那么尽可能原渠道重试，确定原渠道无法重试的状态，那就换渠道重试。比如这么一个场景有A、B两个渠道，A的费率比B的费率低，此时A渠道服务重启导致平台上送失败，为了成本考虑，这时候就可以先进行原渠道重试，重试如果碰到余额不足而失败，那么就可以进行换渠道重试。这样既能节省一定的成本，也能提高成功率，但是交易的延迟会升高。
适用接口
适用接口这里是指重路由规则可以被应用于那些接口，支付系统中可以除了渠道下单接口可以集成重路由外，回调和主查接口也可以，这样才能最大限度的提高订单的成功率。主查和回调本身是异步的接口，所以只适合那些可以异步处理的支付业务。
统一状态码
因为重路由是重发支付指令，而指令重发涉及资金安全的问题，这就需要明确什么情况下可重试什么情况不可重试，能不能重试可以通过渠道状态码来分辨，但渠道状态码的标准各异，需要将其映射成平台统一定义的状态码既统一状态码，详见《统一状态码》这篇文章。这样基于一套标准来定义那些状态码可以重试，那些不能重试就非常的方便，而非基于渠道本身原始的状态码来定义是否可重试。由于重试有关资金安全，重试之前至少要明确这么几点：第一，渠道接口是否幂等既支持相同单号重复下单而不重复支付，这里的支付泛指入款、出款、退款；第二，明确统一状态码重入状态既重试时对应的交易状态，这个状态在某些情况和正常的交易状态不太一样，比如一笔付款，第一次因为网络超时订单处于未知状态，此时支付可能成功也可能未提交；因为想通过重试确定交易状态不至于卡单，所以为网络超时配置了原渠道重路由策略，该笔单子后续会进入重路由环节，但重试的时候碰到一个前置环节的token失效，如果是正常的付款，那么碰到这个状态交易就是失败的状态，但是在重试的场景下统一状态码就需要有重入状态，否则按正常状态这笔单子就失败了，但实际有可能第一次是成功的。
执行方式
执行方式有同步和异步两种，同步重试多用于无法异步的代收场景，所以这种场景下重试次数不易设置过多，一次就差不多了，因为重试次数越多，客户端的延迟也就越高，而且过多的重试还会加重系统负载。异步重试多用于可异步收付退场景，这种场景对支付结果的及时性要求不高，因此可以多设置几次重试，来提升支付成功率。
是否换单
是否换单是指重试的时候是否需要更换支付平台向支付机构提交订单时的唯一识别号，更换单号也就意味着创建新的渠道订单，换不换需要依据重路由类型和交易类型来决定，如果是原渠道网络故障重试，那么不需要换单，否则就会出现重复付款的情况；而如果是换渠道重试，合理的方式是更换单号进行重试，让上送动作有迹可循，做到可追溯；否则出现因换渠道导致重复付款，但系统只有一笔成功的记录的情况，这样就导致数据缺失，后续渠道对账发现不了系统重复付款的错误。另外，有些渠道对单号有特殊限制，原先A渠道生成的平台单号，不一定适用于B渠道，这种情况就必须要换单重试。
重路由设计
我们先简单回顾一下上面这张《渠道路由》里面的路由架构图，重路由属于路由里面的一个子模块，它对支付核心来说是透明的，支付核心感知不到它的存在，比如代付因渠道余额不足失败而触发重路由，那么路由服务会向构建一个处理中的结果先返回给支付核心，后续重试之后再将最终支付结果异步通知给支付核心。因为重路由是对已有组件的组合复用，其详细的程序设计我们就不展开了，仅简单的概述一下重试任务状态机的设计。
重路由状态机
Init（初始）：重路由任务创建后的状态
ready（就绪）：表示任务可执行的状态
pending（处理中）：表示任务正在执行中
waiting（等待）：任务重试之后，还可以继续重试但还不可执行时的状态，到达可执行时间点后进入ready状态
stoped：暂停状态，当重试后的支付结果是处理中且未超过重试次数时，会进入这个状态，因为后续如果回调或者主查失败的时候，如果状态码是可重路由的，那么可以重启这个任务。
closed：关闭状态，当任务不可再继续重试的时流转到这个状态比如重试超限。另外，如果重试的支付结果是不可重试的状态如成功、不可重试的失败，那么也会流转到这个状态。
总结
重试虽然能提高支付成功率，但有一定的资损可能，因为即使重路由程序本身没有问题，但因为渠道原因：交易先给了失败状态但后续又成功了，那就有可能导致资损。针对这类非系统原因导致的问题，属于不可控的范畴，平台本身只能尽量控制和减少这样的问题出现，比如可重试状态码明确到具体的小类状态码而非大类，同一小类错误码重试的交易数量设置上限。大小类状态码的概念解释详见《统一状态码》，这里就不再解释。
