从 0 到 2,000+ 次提交：ERP 四年的架构演进

sifanERP 的起点不是"设计一套漂亮架构"，而是解决 Amazon 运营过程中店铺、商品、订单、库存、FBA、广告和内部协同彼此割裂的问题。项目从 2022 年开始，经历了 Vue 2、Element UI、JDK 8 与 Spring Boot 的快速起步，也经历了前后端全面重构、平台接口治理、数据迁移和上线门禁建设。截至 2026 年 8 月，当前主分支已有 2,556 次提交，其中我的作者记录为 2,094 次；提交数量不能直接等同于业务价值，但它能够说明一件事：复杂系统不是一次"重写"完成的，而是在长期反馈中不断修正边界。

一、起点：先让分散业务能够协同

早期最直接的问题并不是系统性能，而是信息无法形成闭环：商品资料分散在不同表格，订单、库存与广告数据来自不同平台，运营人员需要人工核对，异常发生后也很难还原过程。

因此，第一阶段的目标很务实：尽快把核心业务放进同一个系统。初版采用 Vue 2、Element UI、JDK 8 和 Spring Boot，优先覆盖运营工作台、商品、订单、库存及基础权限等场景。

这种方案适合验证业务，但随着功能增加，问题也逐渐显现：

现象	对业务的影响	真正需要解决的问题
页面和接口持续堆叠	一个小改动可能影响多个模块	缺少稳定的业务边界
外部平台调用散落	限流、授权和异常处理不一致	缺少统一的平台接入层
数据结构依赖手工维护	环境之间容易出现结构差异	缺少可追踪的数据库演进机制
长任务与请求链路混合	同步阻塞、失败难恢复	缺少任务状态与生命周期设计
结果存在但过程缺失	出现异常后无法快速复盘	缺少可观察和可审计能力

这时如果只升级框架版本，旧问题仍会原样保留。真正需要重构的不是代码语法，而是系统如何表达业务、如何处理失败、如何持续上线。

二、第一次关键变化：从"功能集合"走向业务模块

后续重构将系统拆分为网关、核心业务、用户权限、Amazon 业务、内部集成和 AI 等模块，并将前端升级到 Vue 3、TypeScript 和 Vite，后端升级到 Java 21、Spring Boot 3 与 Spring Cloud 体系。

但模块数量并不是重构成果，边界清晰才是。

网关负责统一入口、认证过滤和路由，不承载具体业务判断。
用户服务负责登录、角色和权限，不让权限规则散落在各业务模块。
Amazon 服务集中处理店铺、订单、Listing、FBA、报告和广告数据。
核心服务承载产品、运营、文件及企业内部协作能力。
外部平台之间通过明确的数据契约协作，而不是直接访问彼此内部实现。

这一变化带来的业务价值，是把"修改一个功能可能影响全系统"逐步变成"修改发生在清晰边界内，并能通过契约验证影响范围"。

三、第二次关键变化：把平台接口当成长期系统，而不是一次调用

Amazon SP-API 和 Ads API 的难点，从来不只是发送请求和解析响应。真实环境还包含授权过期、接口限流、异步报告、跨站点时区、分页中断、重复数据和部分失败。

因此，平台集成逐渐形成了完整治理链路：

text 复制代码

授权与会话
  → 店铺级限流
  → 有边界的重试
  → 异步任务状态
  → 幂等保存
  → 成功游标
  → 缺口回补
  → 数据水位与验收

这套链路改变了系统对失败的理解。以前失败意味着"任务报错，需要重跑"；现在失败被拆成可恢复、不可恢复和需要人工处理的不同状态。已经成功的区间会保留进度，重复执行不会制造重复数据，下一轮可以从断点继续。

业务因此获得的并不是"接口更稳定"这么简单，而是数据能够持续更新、问题能够定位、任务能够恢复，运营不再依赖开发人员临时补数据。

四、第三次关键变化：数据库和部署也必须可演进

长期项目最危险的情况之一，是代码已经更新，但数据库结构、运行参数或任务配置仍停留在旧版本。为此，sifanERP 将数据库变化纳入 Flyway 迁移，并为核心业务与 Amazon 模块分别维护迁移历史。

每次结构变化都以新的迁移文件向前演进，不直接修改已经执行的历史；生产上线前还需要确认目标环境、迁移状态、任务配置、健康检查和回滚边界。

这让"上线"从一次 Git 推送变成完整交付链路：

text 复制代码

代码验证
  → 数据迁移检查
  → 任务与配置确认
  → 指定版本部署
  → 健康检查
  → 业务数据验收
  → 异常回滚或继续观察

当系统开始承载真实订单、库存和广告数据后，这些看起来不直接产生页面功能的工作，反而决定了系统是否可以长期运行。

五、2,000+ 次提交真正说明了什么

截至 2026 年 8 月 28 日，当前主分支共有 2,556 次提交。项目约 90% 的功能由我独立完成，这是对功能建设投入的概括；Git 中我的作者记录为 2,094 次，是另一项可核验的工程证据。两者口径不同，不应简单画等号。

我更愿意把这些数字理解为四类持续工作：

业务理解不断修正：字段、状态和流程会随着真实运营反馈变化。
外部平台持续变化：API 版本、限流和报告口径都需要长期适配。
历史设计需要偿还：早期为了快速交付形成的耦合，要在后续逐步拆解。
验证能力不断补齐：测试、迁移、运行手册和上线门禁必须跟上功能规模。

复杂系统的演进不是每隔几年推倒重来，而是识别当前最危险的不确定性，用最小但完整的改动把它消除。

六、目前仍然没有完成的部分

sifanERP 仍在持续建设。广告经营优化、产品健康判断、数据对账和可观察任务等能力，还需要更多真实案例验证。

下一阶段重点不是继续增加页面，而是形成更可靠的闭环：

目标	行动	验证方式	期望结果
提升数据可信度	建立多来源对账和数据水位	按店铺、站点、日期核对差异	异常能够定位到具体来源
降低同步维护成本	完善断点恢复和失败分类	重启、限流和部分失败演练	任务无需从头重跑
支撑经营决策	建立广告与业务指标关联	历史案例回放、影子运行	先证明建议有效，再开放执行
控制上线风险	统一版本、迁移和验收门禁	每次发布保留验证记录	部署结果可确认、问题可回退

结语

四年之后，我对 ERP 架构最大的认识是：架构不是模块图，也不是框架版本，而是系统面对变化和失败时的行为。

一个真正可持续的业务系统，应当让数据来源明确、过程可追踪、结果可验证、失败可恢复。技术升级只有转化成这些能力，才算完成了从"能用"到"可靠"的跨越。