文档目的与读者对象

本文面向以下角色：

• 企业技术架构师、应用架构师
• 订单 / 交易中台技术负责人
• ERP、全渠道系统的集成与平台工程师
• 集团型数字化项目的 IT 决策者

文档目标是帮助读者理解 OMS 业务中台「是什么架构、为什么这样设计、如何集成与扩展、如何支撑大促与多组织」，而非功能营销清单。

问题域：为什么订单需要中台化

当企业并行运营多个电商平台、私域商城、门店与 B2B 渠道，并存在多法人、多品牌主体时，订单系统通常会积累四类典型技术债：

订单中台化的本质，是把「订单」从各渠道的私有后台，提升为企业级共享服务：下层收敛 ERP / WMS / TMS / 库存，上层以标准契约（API + 事件）服务多渠道，实现「能力复用、数据归一、规则可配、弹性可扩」。

总体架构设计

分层架构总览

采用「渠道接入 — 订单中心 — 策略与库存 — 集成与底座」四层，并以事件总线解耦上下游：

图 3：DigiOS OMS 全栈架构 — SAAS → A-PAAS → PAAS → IAAS 四层体系

核心设计原则

• 云原生与微服务：订单、库存、策略等能力拆分为独立部署的微服务，容器化（Kubernetes）运行，支持按负载独立扩缩容。
• 中台化复用：订单、库存、策略作为共享服务，前端渠道通过标准契约调用，避免重复建设。
• 事件驱动（EDA）：订单状态变更以领域事件发布到事件总线，下游异步消费，降低系统耦合。
• DDD 限界上下文：按订单、库存、履约等划分上下文，各自维护领域模型与边界，互不污染。
• CQRS 读写分离：命令侧处理写操作，查询侧构建只读视图，缓解读写争用。
• 多租户隔离：支持租户级数据隔离（独立 schema 或行级 tenant_id）与资源配额隔离。

核心子系统设计

全渠道接入与订单归一化

各渠道订单经「渠道适配器（Adapter）」转换为统一订单模型（Unified Order Model）。适配器负责：字段映射、币种 / 税率归一、地址标准化，以及把渠道特有扩展字段沉淀到扩展表。核心模型保持稳定，渠道差异以「外挂扩展」方式承载，避免核心域被渠道细节侵蚀。

订单中心与状态机

订单以聚合根（Aggregate Root）建模，生命周期由显式有限状态机（FSM）驱动：

状态迁移须经状态机校验，非法迁移被拒绝，保证订单生命周期可控、可审计、可回溯。

策略引擎（寻仓 / 分单 / 拆合单）

策略采用「规则与决策分离」：规则（就近发货、库存最优、成本最低、时效优先）配置化，引擎在订单进入后计算最优仓与路由，并支持：

• 拆单：同一订单不同仓发货时自动拆分
• 合单：同仓多单合并出库
• 转单：库存不足时自动转其他仓 / 供应商履约

规则支持热更新，无需发版即可调整经营策略。

库存中台

统一管理多维度库存：实物库存、可用库存、渠道锁定、在途库存、预售占用。采用「库存事务 + 预占 / 释放」模型，通过行级锁或 Redis 原子扣减防止超卖；库存变更发布领域事件，供订单与履约下游消费，保证库存视图最终一致。

事件总线与集成层

以 Kafka / RocketMQ 等消息中间件承载领域事件（OrderCreated、OrderRouted、StockLocked 等）。集成层通过 API 网关与预置连接器对接 ERP / WMS / TMS：异步事件保证最终一致，关键链路保留同步接口保证实时性。

领域建模（DDD 限界上下文）

商品 / 会员上下文由商品中台、会员中台提供，OMS 仅持有引用与快照，不持有源数据。上下文间通过「防腐层（ACL，Anti-Corruption Layer）」对接，避免外部模型直接渗透进订单域。

数据一致性设计

分布式环境下不追求强一致，而采用「最终一致性 + 幂等」：

• 关键写操作（扣库存、生成发货单）通过 Saga 编排 或 本地消息表 / 事务消息 保证跨服务一致
• 所有事件与接口具备幂等键（订单号 + 业务动作），重复投递安全
• 对账任务定期核对「订单侧、库存侧、财务侧」三侧数据，异常自动告警并保留人工干预入口

高并发与高可用设计（大促峰值）

面向大促洪峰，采用分层削峰与弹性策略：

设计目标为单集群支撑万级订单 / 秒的接入与处理能力，并可在峰值时分钟级扩容。

安全与多租户隔离

• 认证授权：OAuth2 / OIDC + RBAC / ABAC，租户间权限严格隔离
• 数据安全：传输 TLS、存储加密、敏感字段脱敏
• 租户隔离：数据层 tenant_id 隔离或独立 schema，资源配额与流量隔离
• 审计合规：操作审计日志全量留痕，满足等保及跨境数据合规要求
• 防重防刷：下单幂等、风控规则前置校验

部署形态与技术栈

支持三种部署形态：

基础技术栈：Spring CloudKubernetesKafka/RocketMQRedisMySQL/MongoDBPrometheusSkyWalking

与周边系统的集成

• ERP：OMS 完成履约调度后推送核算数据，ERP 回写财务 / 库存台账，二者通过「事件 + 批量对账」协同，OMS 不替代 ERP 的核算职责
• WMS：下发发货指令、回传库存与出库结果
• TMS：获取物流轨迹并回写订单
• 数据中台：订单 / 库存事件流入，支撑实时经营大屏与分析

集成以「契约优先 + 事件驱动」为原则，降低对源系统的侵入，保护既有 IT 投资。

架构师落地建议

• 演进路线：先建统一订单模型与全渠道接入，再上策略引擎与库存中台，最后打通 ERP 与履约，循序渐进
• 职责边界：明确 OMS 中台与 ERP 的分工——中台管「敏捷的订单流转」，ERP 管「严谨的核算」
• 规则外置：尽量把分单 / 寻仓逻辑配置化，避免规则散落各渠道系统
• 可观测先行：上线即建设链路追踪与对账，否则大促问题难以定位
• 多租户前置：集团型企业从第一天起按租户建模，避免后期重构代价

术语表与常见问题 FAQ