文轩在线加盟商系统：多平台店铺的运维与结算治理

背景

文轩在线的加盟商系统，把加盟商在各电商平台的店铺接进来统一运营：商品售价同步、订单抓取、退换货与结算。店铺数量接近 200 家，横跨天猫、京东、当当、亚马逊等多个平台，每个平台的接口行为、结算口径与促销规则都不一样。

这类系统的压力不来自代码复杂度，而来自外部依赖的不可控：平台接口会限流、会调整、会在促销期间给出异常数据，而加盟商的生意直接挂在这些数据上。

我做的事

我的角色是核心运维与开发，日常工作与专项攻关各占一半：

• 多店铺日常运维：处理商品售价同步异常、订单抓取延迟、退换货结算差异等各类问题，保障加盟商业务正常运转
• 大促技术保障：参与双十一大促前的锁库方案制定与凌晨技术支持，协调运维完成系统扩容
• 异常处理规范化：针对「促销活动结束导致下单结算差异」这类高频问题建立处理 SOP
• 业务扩展：配合运营需求扩展预售业务，调整下单支付逻辑，并把预售商品推送到天猫等平台
• 分布式事务攻关：主导退换货订单结算异常的技术攻关，基于 JTA + Atomikos 解决多数据库分布式事务问题

关键决策与取舍

退换货结算选择强一致的分布式事务方案。 结算数据直接对应钱，最终一致意味着在一段时间窗口里「账是不对的」——而这正是客服与财务最容易被投诉的点。因此这里选了基于 JTA + Atomikos 的多数据库事务，用性能与实现复杂度换取结算准确性，解决了历史遗留的结算差异问题。

高频异常用 SOP 收敛，而不是靠人。 促销结束导致的下单结算差异会周期性出现，每次靠个人经验排查既慢又不稳定。把排查路径固化成 SOP 之后，处理效率才有可预期的下限。

结果

• 支撑近 200 家加盟商店铺的日常运营
• 退换货结算的分布式事务改造落地，结算准确性痛点得到根治
• 异常处理 SOP 建立后，问题平均处理时长缩短 50%
• 多次双十一大促技术保障，系统平稳运行

反思

这段经历给我最大的影响是对「钱相关的链路」的判断标准会变。一般业务可以接受最终一致、可以容忍短时间的脏数据；一旦涉及结算，判断标准就完全不同。后来我在别的项目里做支付回调幂等、做结算口径确认，本质上都是这条经验在复用。