一个商户接的支付通道从来不止一家。微信、支付宝、银联、各家银行直连，这些通道同时摆在面前，每家的费率不同、成功率不同、单笔限额不同、维护时间不同。用户在收银台点下付款的那一刻，系统只有几百毫秒的时间决定这笔支付走哪个通道。这个决定要同时满足几个互相打架的目标，成功率要高不然用户支付失败流失，成本要低不然利润被费率吃掉，通道要稳定不然一个挂了整条支付链路瘫掉，还要满足合规和风控的硬约束。
支付路由就是在这几个目标之间做实时权衡的子系统。它难就难在，这几个目标几乎总是冲突的。费率低的通道往往成功率也低，成功率高的通道费率往往高。一个静态规则把所有交易都走最便宜的通道，短期看省成本，长期看失败的支付带来的用户流失和客服成本，远超省下的那点费率差。所以支付路由从第一天起就是个动态决策问题，没有一劳永逸的解法。
决策依赖通道画像
路由要能做决策，前提是对每个通道有准确及时的认识，这就是通道画像。画像不是静态的，是实时更新的。
画像的基础数据来自通道的接口规范，费率多少、单笔和单日的限额、支持的支付方式、维护时间窗口。这些相对固定。画像的动态数据来自实时统计，每个通道最近一段时间内的成功率、平均响应时间、近期故障次数。成功率是滑动窗口实时算的，比如最近 5 分钟内这个通道的支付成功数除以总尝试数。一个通道今天上午突然成功率掉到 80%，很可能它背后的银行系统在抖动，路由必须立刻感知到并把这个通道降权，否则继续往它身上导流量，失败率会越叠越高。
画像还要维护通道的可用性状态。某个通道在维护时间窗口内不可用，路由得直接把它从候选里排除。某个通道最近错误率飙升触发熔断，也得暂时摘掉。这些状态变化必须实时反映到路由决策里，用陈旧的画像做决策，等于闭着眼睛导流量。
图：通道画像由静态属性、滑动窗口动态指标、可用性状态三部分组成，回调实时刷新成功率驱动降权与熔断
从静态规则到加权评分
路由策略有个自然的演进路径，从简单的静态规则起步，随着数据积累逐步升级到加权评分，数据足够了再考虑机器学习。一上来就追求智能路由是典型的过度设计，冷启动阶段根本没有足够的历史数据训练模型，模型还不如几条规则准。
起步阶段用静态规则路由就够覆盖大部分场景。根据这笔支付的金额、支付方式、用户特征，用一组硬规则筛出候选通道。金额不能超过单笔限额，通道得支持这种支付方式，当前时间不在维护窗口内，满足合规约束比如单日累计限额。筛完之后，剩下的候选通道按一个简单策略选一个，比如费率最低或者轮询。
图：路由策略按冷启动→跑稳→数据成熟三阶段演进，切忌一上来就过度设计
List<Channel> candidates = channelRegistry.getAll().stream() .filter(c -> c.supports(payMethod)) // 支持该支付方式 .filter(c -> payAmount <= c.singleLimit) // 不超单笔限额 .filter(c -> c.isAvailable(now)) // 当前可用 .filter(c -> c.meetsCompliance(user)) // 合规 .collect(toList());跑稳之后，静态规则的局限就暴露了。它无法综合权衡多个维度，比如通道 A 费率低但成功率也低，通道 B 费率高但成功率高，规则路由只能二选一拍死，无法根据当前情况动态取舍。这时就该上加权评分。
加权评分给每个候选通道算一个综合分，把成功率、费率、稳定性几个维度分别归一化打分，再按权重加权求和。权重要可配置，因为不同业务场景的侧重不同。大额支付场景成功率权重高，宁可走贵但稳的通道，因为失败一次的损失大。小额支付场景费率权重高，可以激进走便宜通道，失败了重试成本低。综合分实时算，实时选最高分的通道。
机器学习路由是更进阶的玩法，用历史交易数据训练模型，预测每一笔交易在每个通道上的成功概率，结合费率算出每个通道的期望成本，选期望成本最低的。这需要足够的成交数据和失败数据，冷启动期还是得靠规则路由兜底。我个人的判断是，规则加实时成功率反馈这套组合，已经能覆盖绝大多数优化需求，机器学习的边际收益要数据和工程都到位才划算，大部分团队到不了那个临界点。
实时成功率是路由的眼睛
通道成功率是动态的，今天好好的通道，明天可能因为背后的银行系统抖动而成功率暴跌。路由要能实时感知这种变化，核心机制是滑动窗口统计。
每收到一笔支付回调，成功或者失败，更新对应通道在滑动窗口里的计数。窗口要短，5 到 10 分钟，这样才能快速捕捉通道的突发异常。如果窗口太长，比如一小时，通道出问题后要很久才能在成功率数字上反映出来，这段时间路由还在往这个通道导流量。窗口越短反应越快，但样本量越小数字波动越大，这中间要取一个平衡，5 分钟通常是个合理的折中。
决策时，路由查每个候选通道的实时成功率。成功率跌破一个阈值的通道，自动降权，综合分大幅下降。跌得更狠的，比如跌破 70%，直接熔断这个通道，把它从候选里摘掉，流量自动转给次优通道。熔断期满后放少量流量探测这个通道是否恢复，这就是经典的熔断器半开探测。这套机制让路由对通道故障有自愈能力，不需要人工介入摘流量。
图：通道按实时成功率在 关闭→降权→熔断→半开探测 间流转，实现故障自愈
容灾是标配不是可选
支付通道的稳定性远低于自家服务。银行系统定期维护、第三方通道间歇性抖动、网络运营商抽风，这些在支付场景里是常态。路由设计必须从第一天就假设任何通道随时可能挂，把容灾做成标配。
容灾的核心是通道级重试。一笔支付走通道 A 失败了，自动重试通道 B，B 还失败再试 C。这种通道级的降级重试能显著提升整体成功率。单看一个通道，成功率 98% 已经不错，但意味着每 50 笔就有 1 笔失败。如果接了三个通道做级联重试，三个通道同时失败的概率极低，整体成功率能推到 99.9% 以上。
重试要避免无脑重试放大流量。一次支付失败马上重试下一个通道是合理的，但如果失败是因为用户余额不足或者卡号错误这类业务原因，重试多少个通道都没用，还会白白消耗通道调用。所以重试前要判断失败原因，通道侧的原因，超时、通道错误，才重试，业务侧的原因直接返回失败。这个判断逻辑要基于通道返回的错误码，不同通道的错误码语义不一样，得分别适配。
成本优化是长期博弈
成本优化不能短视地理解为无脑走最便宜通道。一笔支付失败，用户可能放弃支付、可能去客服投诉、可能对平台失去信任，这些隐形成本很难量化但真实存在，往往高于几分钱的费率差。
所以成本优化要分场景。大额交易优先成功率，一笔几千块的支付失败了，损失的是整笔交易的利润，为了省 0.1% 的费率差去走成功率更低的通道，得不偿失。小额交易可以激进走低费率通道，一笔十几块的支付失败了重试，成本可控，省下的费率差在小额高频场景下累积起来很可观。
路由的决策结果要完整记录，每笔支付走了哪个通道、为什么选它、最终成功还是失败，这些日志是成本分析和规则调优的基础。定期回溯这些数据，看各通道的实际占比、实际成功率、实际成本，反过来调整权重和规则。成本优化不是一次配好就结束，是持续的数据驱动的迭代。
支付路由最容易犯的错是过度设计。新系统一上来就想做机器学习路由，结果冷启动数据不够，模型预测的成功率比拍脑袋还不准，反而拉低了整体成功率。正确的节奏是先上静态规则，跑稳，覆盖八成场景。积累几个月的真实成交和失败数据，再上加权评分。等数据量足够大、工程能力到位了，最后才考虑模型。规则加实时成功率反馈这套组合，生命周期比想象的长。
