干货分享 | 解密转转收银台背后的路由系统

• 1 引言
• 2 背景知识介绍
• 2.1 名词解释
• 2.2 逻辑解释
• 3 支付路由系统历史演进
• 阶段1：基础配置模式
• 阶段2：规则引擎模式
• 阶段3：模块构建模式
• 4 路由系统解密
• 4.1 整体架构
• 4.2 路由模块构成
• 4.3 表达式引擎
• 4.4 异常检测、自动下线
• 4.5 自动恢复
• 5 总结与展望
• 5.1 系统演进总结
• 5.2 未来展望
• 5.3 结语

1 引言

在电商交易场景中，支付环节是整个用户购物环节中的关键节点。用户从搜索、推荐、浏览、比较、加购、下单，到最终的支付环节，每一步都经历了层层漏斗的筛选。当用户到达支付环节时，已经展现出强烈的购买意向，这时的流量价值已经远超最初环节。支付环节的体验直接关系到最终的成交转化，因此收银台不仅要确保支付流程的顺畅，更要保证支付的安全性和可靠性。随着业务规模的不断扩大，支付场景的日益复杂，如何构建一个高效、稳定、智能的支付路由系统，成为了我们面临的重要挑战。

本文将深入解析转转收银台支付路由系统的设计与实现，从系统架构、规则引擎、异常处理等多个维度，分享我们在支付路由系统演进过程中的实践经验和技术心得。通过这篇文章，你将了解到：

1. 转转收银台支付路由系统是如何从简单的规则配置，演进到模块构建模式路由
2. 规则引擎如何支持灵活的业务配置，实现支付渠道的智能调度
3. 系统如何通过完善的监控和自动化机制，保证支付服务的稳定性

无论你是支付领域的从业者，还是对系统架构感兴趣的技术人，相信这篇文章都能给你带来一些启发和思考。让我们一起走进转转收银台支付路由系统的技术世界。

2 背景知识介绍

2.1 名词解释

2.2 逻辑解释

上面的名词概念非常重要，此处着重介绍部分概念。

1：为什么需要终端和版本？

不同的终端版本支持的支付方式和产品不一样，比如：假设某个支付方式需要集成某个SDK，而这个SDK是从x.x.x之后的版本才开始集成的，那么低于这个版本的就不能透出这个支付方式。

2：展示渠道和支付机构概念是否冲突？

不冲突，有些展示渠道是抽象出来的，没有实际的映射，比如分笔支付、组合支付。而有些情况是多个展示渠道对应一个支付机构，比如花呗和支付宝，都是属于同一种支付机构。

3：为什么在商户号之外设计支付渠道的概念？

支付渠道是商户号更精细化控制的维度，假设在某间联通道注册了商户号B，同时B是支持微信（B1）和支付宝（B2）的，为了分别精准控制B1、B2的可用状态、分流比例、权重等因素，需要设计支付渠道的维度。

3 支付路由系统历史演进

要真正理解一个系统，我们必须追溯它的发展历程，了解它的来龙去脉。每一个决策、每一个设计，都是特定条件下的产物。它们或许不是最优的选择，甚至可能不是最合适的方案，但每一个环节的设置都承载着当时的考量与权衡。这些决策背后，往往有着复杂的技术背景、业务需求、现实约束和历史原因。系统演进每一步都是在前人的基础上不断积累和创新的结果。了解这个过程，不仅能够帮助我们更好地理解系统的现状，更能为未来的优化和演进提供宝贵的参考，只有理解了"为什么是这样"，才能更好地思考"应该是什么样"。

阶段1：基础配置模式

基础配置模式是符合支付路由系统目标的最简单实现方式，它采用简单直接的配置规则，通过几个核心条件就能完成支付渠道的路由选择。这种模式就像是一个简单的导航系统，只需要输入目的地，就能给出明确的路线指引。

在这种模式下，系统主要通过业务场景和公司主体等基础维度，精准匹配到对应的收单商户号。比如，当用户选择微信支付时，系统会根据当前业务场景（如换新等）和公司主体信息，直接返回预设的商户号配置。

基础配置模式特别适合业务规则相对固定、支付需求稳定的场景。它的优势在于：

• 配置简单直观，易于维护
• 执行效率高，响应速度快
• 代码结构清晰，易于理解

虽然随着业务的发展，系统已经演进到了更复杂的阶段，但基础配置模式并未被完全淘汰。恰恰相反，由于其简单高效的特点，在一些业务场景简单、对响应速度要求高的场景中，这种模式仍然有一席之地。这就像是在现代交通工具中，自行车依然因其简单便捷而不可或缺一样。

这种模式的存在，体现了系统设计中的一个重要原则：不是所有场景都需要最复杂的解决方案，有时候简单直接的方案反而是最优的选择。

阶段2：规则引擎模式

规则引擎模式引入了业务匹配规则和规则引擎的概念。系统通过买家、卖家、业务线等维度定义业务场景，将每个商户号的每种支付产品作为独立的支付方式，并定义了不同终端、不同版本下的可用支付方式列表。

系统处理流程示意如下：

这种模式特别适合业务线众多、支付方式多样、业务规则相对稳定的场景。然而，随着业务发展，其局限性也逐渐显现：

1：配置维护成本高：每次增加商户号或业务场景，需要修改大量配置数据，耗时较长。

2：商户号使用受限：不支持同一业务场景下同一种支付方式使用多个商户号，限制了业务扩展的灵活性。

3：维度扩展困难：业务场景维度扩充不够便捷，难以快速响应新的业务需求。

阶段3：模块构建模式

模块构建模式引入了 Aviator 表达式引擎，使得规则维度的扩展更为便捷。系统对原有的终端环境和版本进行了结构拆解，使业务场景不再与具体的环境和支付产品深度绑定。

同时，系统对文案、排序等配置项进行了解耦，不再要求每个支付方式都绑定固定文案，这大大方便了活动文案的配置和复用。此外，系统还丰富了对同一场景多商户号的支持，并引入了异常渠道自动上下线机制，显著提高了服务的稳定性。

这种模式的出现，使支付路由系统具备了更强的灵活性和稳定性。

4 路由系统解密

4.1 整体架构

支付系统作为转转平台的核心基础设施，不仅需要支撑内部运营人员的路由管理需求，更要承担全平台用户的支付请求处理。系统需要适配多样化的环境（包括各版本APP、小程序等）和不同用户角色（如普通买家、普通卖家、商家、回收个人等）。

在架构设计上，支付系统直接承接C端流量，同时与各业务部门紧密协作。基础能力和底层服务则由公司架构团队提供支持。

整体架构如下：

获取可用支付方式的逻辑示意图如下：

其中提交收银台在支付路由的逻辑部分和获取可用支付方式逻辑类似，不再赘述。

4.2 路由模块构成

思考心路：
在规则引擎模式中有一些很明显的痛点

1：业务场景和终端环境以及版本高度绑定
这个特点在后续版本升级继承不同渠道的时候就会存在一个业务线，在同一个APP要配置N套支付方式，继承微信SDK版本的一套；继承微信SDK且支付宝SDK的一套；继承微信SDK且支付宝SDK且京东SDK的一套....

2：业务场景和支付配置高度绑定
原来的配置方式上，直接决定了某个业务场景在具体终端环境和版本下的支付渠道，是指明了支付产品、支付图标、支付标题、支付文案等配置。这一设计导致每新增一个支付渠道都需要把对应的图标、文案、标题等信息重复配置一遍。

基于上述痛点，我们在设计新的结构的时候，把整个路由系统进行了模块拆分，使得模块之间不再深度绑定，这样既可以轻松扩展，也方便模块的复用，同时在管理方面也不需要关注太多的因素。

支付路由内部可以划分为如下模块

1：业务场景管理

核心模块之一，根据业务线和收款账户定义业务场景，后续引导路由是基于业务场景再次进行匹配。可以抽象的理解为定制好的一个规则组。

业务场景目前后台限制了只配置业务线和收款账户，但是系统本身是支持更多维度的。

2：商户号管理

维护系统中的商户号信息，包括商户号、收单机构、是否支持降级、登录账户、支持的支付方式和支付产品、手续费信息和对账信息等。

3：支付渠道管理

基于商户号的扩展，配置对应的密钥信息、渠道参数。一个商户号可以对应多个支付渠道。系统异常上下线和分流比例都是基于支付渠道配置的。

4：路由策略管理

路由策略分为两种

分流：配置同一种支付方式下不同支付渠道的比值关系。

不可用：限制某支付渠道不可用。

5：基础因素管理

配置不同环境本身支持的支付方式上限

6：可用支付方式

可用支付方式限制了业务场景使用的支付方式上限，和基础因素共同约束了用户的可用支付方式。

整体模块一览如下图：

4.3 表达式引擎

业务场景是支付路由的核心概念，可用支付方式、分流比例、显示文案和排序规则都是在业务场景的基础上配置的。因此，如何定义业务场景至关重要。

尽管我们可以穷举所有能用到的维度，但如果将来出现新的维度需要划分，我们的设计如何支持后续的扩展（比如，根据所在城市显示不同的支付方式）？基于上述考量，我们将业务场景设计成脚本语言表达式。这种脚本语言表达式不仅应用于业务场景模块，还贯穿整个支付路由系统。

下面我们使用具体的例子来理解表达式引擎，同时对比一下和硬编码实现的特点。

假设业务的诉求是，业务线等于1001或者1002，并且终端环境等于找靓机安卓，并且版本在3.1.2和6.3.8之间，并且支付金额小于6万，那么可以使用的支付方式为：微信、支付宝、京东。

使用硬编码实现：

if("业务线树".contains("1001")||"业务线树".contains("1002")){
    if("终端环境".equals("找靓机安卓")){
        if("版本判断"("版本","3.1.2","6.3.8")){//版本判断为自定义的函数
            if("金额"<6万){
                return "微信、支付宝、京东";
            }
        }
    }
}

可以预见到，如果使用硬编码实现，当面对规则变动和规则及维度变多的时候，将面对灾难级的现场。

使用表达式引擎的实现：

//加载自定义函数
AviatorEvaluator.addFunction(new BusinessFunction());
AviatorEvaluator.addFunction(new VersionFunction());
//当前请求的变量
Map<String, Object> env = new HashMap<>();
env.put("fl_business_line", [1001,10011000]);
env.put("f_t", "找靓机安卓");
env.put("f_v", "5.7.2");
env.put("f_m", "4000.00");
//当前规则的表达式展开
String expression="func_business(fl_business_line,seq.set('1001','1002'))&&include(seq.set('找靓机安卓'),f_t)&&func_version(f_v,'3.1.2','6.3.8')&&f_m<60000";
boolean match=AviatorEvaluator.getInstance().execute(expression, env, true);
if(match){
    return"微信、支付宝、京东";    
}

通过表达式引擎的示例代码，我们看到，当业务需要新增维度的时候，比如增加一个条件:城市等于北京，注意：城市可以添加多个

因为等值判断和集合判断是表达式本身就支持的，不需要自定义函数。所以改动如下

//新增维度值
env.put("f_c", "北京");
//扩充表达式
String expression="func_business(fl_business_line,seq.set('1001','1002'))&&include(seq.set('找靓机安卓'),f_t)&&func_version(f_v,'3.1.2','6.3.8')&&f_m<60000";
expression+="&&include(seq.set('北京'),f_c)";

通过这种方式，系统能够灵活应对未来的变化和扩展需求。

表达式引擎逻辑如下：

在技术选型时，我们调研对比了Aviator、Groovy、Drools等方式。
最后我们选择Aviator作为表达式引擎，有如下原因，其轻量、依赖少，且高性能，所支持的运算操作符满足我们的业务场景需求。
同时支付系统在设计上没有与Aviator脚本深度绑定，而是预留了一个可以扩展的输入输出接口。
我们可以选择Aviator、Groovy、Drools、easy-rule、也可以自己基于java代码实现一套数据匹配的逻辑。
这种可拔插的设计预留使我们系统在后续的发展中不会被某一种技术所锁定。

附上部分数据

4.4 异常检测、自动下线

虽然渠道异常是小概率事件，但随着接入渠道的增多，异常发生的概率也会呈几何级数增长。当系统检测到某个渠道异常时，可以通过技术手段来确保用户体验不会显著下降。

以下举两个例子来说明：

单一收单机构：假设京东支付方式背后只有京东一个收单机构，当京东收单机构异常时，可以将京东支付隐藏、置灰或增加风险提示，引导用户使用其他支付方式。

多收单机构：假设支付宝支付方式背后有支付宝和易宝两个收单机构，当易宝机构服务异常时，可以在支付时自动路由到支付宝的收单机构，用户感知不到异常的发生。

异常检测自动下线和自动恢复整体架构如下：

异常检测自动下线的逻辑如下：

通过异常检查、异常渠道自动下线的方式，系统能够在渠道异常时保持服务的稳定性和用户体验。

4.5 自动恢复

自动恢复的逻辑比自动下线简单，但需要考虑一种场景：为了减少短暂恢复再陷入异常情况对用户的影响，恢复过程中若有其他可用渠道，那么恢复渠道应采用逐步放量恢复的方法。

逻辑流程图如下：

5 总结与展望

5.1 系统演进总结

随着业务的发展，转转收银台支付路由系统也一直在持续演进，在基础配置模式阶段，系统通过简单的配置规则实现了基本的支付路由功能，为后续发展奠定了基础。规则引擎模式的引入，使系统具备了更强大的场景适配能力，能够更好地满足多样化的业务需求。而模块构建模式的出现，则标志着系统在灵活性和可扩展性方面达到了新的高度。

多渠道适配模式的引入，为支付渠道费用的优化提供了更多可能性，而渠道异常自动上下线能力的实现，则有效降低了第三方渠道波动对用户体验的影响，显著提升了系统的稳定性和可靠性。

5.2 未来展望

1. 体验优化
   基于渠道支付成功率和响应时间动态调整渠道权重，保障用户体验
   满足用户个性化定制收银台需求
   提升内部产研团队使用体验
2. AI助力
   探索AI在路由系统的应用

5.3 结语

物有本末，事有终始。知所先后，则近道矣。

至此，整个收银台路由系统中核心部分已经介绍完毕，文中所列数据、举例都非真实数据，是仅供学习交流的示例数据，可能缺失了真实样例的更多细节，不过整体结构和逻辑是完整的。

关于作者
张一鸣 转转支付后端研发