跨境 ERP 系统架构设计

跨境 ERP 的核心不是大而全的页面，而是稳定的领域模型与同步管道。我们服务过月单量十万级的 Shopify 卖家，系统能撑住不是因为功能多，而是因为订单、库存、渠道三个域边界清晰，数据有唯一真相源。很多团队先做漂亮 Dashboard，后补 Webhook 和对账，最后库存和平台永远对不齐。架构评审时应先画事件流和数据归属，再画页面，顺序反了后期重构代价极高。

领域拆分：按变更频率切，不是按页面切

商品与变体管 SKU 主数据和渠道映射；订单与履约管状态机和物流回写；库存与仓位管可用量、在途量和锁定；渠道连接层封装 Shopify、Amazon 等 API 差异；报表与经营指标从事件流异步聚合，不阻塞交易写路径。各域通过明确接口通信，避免一个 Controller 里同时改库存又改订单。AI 模块单独成域，只消费领域事件，不直接写核心表。跨境还要独立关税、汇率域，避免硬编码在订单 Service 里，否则每接一个新国家就改一遍核心逻辑。

同步策略：事件驱动加定期对账

渠道 Webhook 进入 RabbitMQ，Consumer 落 PostgreSQL 后发布领域事件，触发库存重算和报表更新。Webhook 丢包时用 Admin API 对账补洞，以 PostgreSQL 为系统真相源，Redis 缓存热点读。关键写路径用乐观锁或行级锁，防止并发超卖。跨境场景还要考虑时区、币种和海关字段，从第一天就在订单表预留扩展 JSONB。多店铺 SaaS 必须在每条同步链路带 shop_id。部分发货、拆分单、退款单要在状态机里显式建模，不能只用平台 status 字符串映射，否则报表会对不上。

数据层：租户维度与审计字段前置

PostgreSQL 适合作为真相源：JSONB 存渠道原始 payload，便于排障；按 shop_id 分区或索引支撑多租户；created_at、updated_at、source 审计字段不可少。后期加店铺维度迁移，成本是前期的十倍。只读副本承接 ERP 报表和 BI 导出，主库专注交易一致性。历史订单冷热分离：近三个月热表，更早归档到对象存储或分区表，控制主库体积和备份时间。

AI 与自动化的插入点

商品标题翻译、异常订单分类适合走异步 AI 队列，结果回写前人工抽检。把 AI 当增强层，不当主链路，架构才经得起账单和故障的双重考验。稳定的多租户 ERP，靠的是领域边界、Webhook 幂等和 PostgreSQL 对账，而不是页面数量。上线 checklist：任一域能否独立扩容、任一渠道断流是否可降级、任一店铺数据能否单独导出——三条都满足，才称得上可售卖的跨境 ERP 架构。实践中我们还为每个渠道维护「健康度」指标：Webhook 成功率、API 429 次数、对账差异条数，低于阈值自动切换为纯拉取模式并通知运营。PostgreSQL 里保留原始 payload，排障时不必反复调平台接口。架构文档写清谁是真相源、谁是对账源，新人 onboarding 才不会在「以谁为准」上争论不休。跨境 ERP 还要预留「多币种结算延迟」：汇率快照写入订单行，报表按快照重算，避免月底和财务系统对不上。渠道 API 版本升级时，在连接层做 adapter 隔离，核心域模型保持稳定，升级 Shopify API 版本才不会牵动全盘。总结一句：跨境 ERP 卖的是「数据和平台一致」，架构所有选择都应服务这句话，而不是反过来。

小结

跨境 ERP 架构要围绕同步、库存与多租户隔离展开，Webhook 与补偿拉取并存。桌面端与 Web 共享业务内核时，差异应收敛在壳层。越早建立对账与幂等约定，后期渠道扩张越不痛苦。