某大型电商平台的清结算系统

清结算系统负责确定平台的付款对象、付款金额及其计算依据，并为每笔结果保留可核对、可追溯的记录。

系统虽然以财务后台和业务单据为主要界面，但其状态与数据直接关系到资金安全。一个字段或状态的变化，可能同时影响对账、付款、开票、导出、权限和审计。

我在 2023—2024 年参与这套系统的应用架构与持续演进。企业名称、金额和内部规则已经隐去，下面重点说明问题以及我做了什么。

业务复杂性

一次结算通常要经过对账、生成结算单、确认、付款和开票等步骤。每一步都可能由不同系统、不同岗位在不同时间完成。

例如，平台向支付系统发起付款后连接超时。此时我们只知道“没有收到回复”，却不能直接认定付款失败：对方可能已经付了，只是回复没有传回来。如果系统盲目重试，就有重复付款的风险。

所以清结算系统不能只把正常流程做通，还必须回答三个问题：钱算得对不对、异常能不能恢复、事后能不能查清楚。

职责与关键工作

在项目中，我负责应用架构与关键方案设计，将分散在页面、接口和定时任务中的业务规则整理为可以统一维护、持续演进的系统结构。

关键工作包括：

• 梳理核心业务对象。 明确对账记录、结算单、付款指令、发票、收款信息和结算主体之间的关系，避免不同模块对同一概念各说各话。
• 统一关键规则。 把金额精度、舍入方式、状态流转、权限和人工调整要求集中管理，避免 Web、API、批处理和导出各写一套逻辑。
• 划清模块责任。 查询负责找数据，业务操作负责改变状态，批处理负责大批量计算，集成层负责连接支付、ERP 和开票系统，导出任务则与在线请求隔离。
• 补齐异常和审计设计。 把超时、重复请求、部分成功、冲正和人工修复纳入正式流程，而不是出了问题以后再写临时脚本。
• 控制发布风险。 在变更前检查受影响数据和状态，准备回滚或补偿方案，并在发布后通过对账确认结果。

这些工作让团队面对需求变化时，不再只考虑“代码能不能改”，而会同时考虑资金、状态、外部系统和恢复路径。

资金操作的安全设计

对外付款、开票等操作都会使用稳定的业务编号。同一个请求即使因为超时被再次提交，远端也能识别它是不是已经处理过。

对于结果未知的请求，系统不会简单标记为成功或失败，而是进入待确认状态，再由对账任务查询远端结果。这样可以减少重复付款，也不会把一笔真实成功的交易误当作失败。

人工调整同样受到约束：要记录谁在什么时间改了什么、为什么修改、修改前后分别是什么，以及是否经过审批。日志不再只是排查程序错误的辅助信息，而是业务记录的一部分。

模块边界与部署策略

这套系统既有在线查询，也有耗时导出、定时计算和外部系统调用。架构首先按职责划分模块，但不要求每个模块都成为独立微服务。

关键目标是保证规则只定义一次、依赖方向清楚，并避免耗时任务影响在线操作。是否独立部署，由流量、故障隔离需求和维护成本共同决定。

结果与架构价值

这项工作的价值可以概括为：让涉及资金的变更更可控。

业务规则有了统一位置，异常情况有明确去向，外部调用可以核对，人工操作可以追溯，发布也有验证和恢复方案。这样既降低了重复付款、状态混乱和数据无法解释的风险，也让后续需求能够在清晰边界内继续迭代。

复杂的财务业务因此变成了明确的系统规则；异常发生时，系统仍然控制得住、恢复得了、解释得清。