如何画好一张零售电商架构图：从业务设计到系统演进

以零售电商为背景，系统讲清架构图如何确定读者与范围、划分业务域、表达交易一致性与失败补偿，并从单体、集群、领域服务化逐步演进到平台化架构。

一张好的架构图，不是把 Redis、Kafka、MySQL 和微服务图标排得很整齐；它应该让业务负责人看懂能力边界，让研发看清调用和数据流，让运维知道哪里会失效，让团队知道下一步为什么演进。

很多架构图的问题，不是“画得不漂亮”，而是没有回答真实问题：为什么拆？哪里是一致性边界？大促流量来了先保护谁？订单成功但库存失败怎么办？门店、仓库、线上商城如何共享一盘货？

大型互联网系统不是一次设计完成的，而是在业务变化中持续演进。高并发、高可用、高性能、缓存、队列、领域驱动、限流、熔断、容灾和最终一致性，都不是独立的“技术名词”，而是业务压力达到某个阶段后的架构选择。

本文把这些原则放进零售电商场景，给出一套可以用于方案评审、技术汇报和系统演进的画图方法。

一、先确定：这张架构图要帮助谁做什么决定

架构图不是系统截图，也不是组件清单。画图前先写出一句话：

这张图要帮助谁，在什么约束下，做出什么决定？

零售电商常见的架构图至少有四种：

不要试图用一张图回答所有问题。本文的三张图分别承担“全景”“核心交易链路”“演进路线”三个职责。

二、架构设计的起点不是技术，而是业务压力

画图前，先把模糊目标变成可验证约束。以零售电商大促为例：

• 峰值流量：商品浏览 20 万 QPS，下单 1 万 TPS；
• 体验目标：商品详情 P95 小于 200ms，提交订单 P95 小于 500ms；
• 可用性目标：核心交易链路 99.99%，非核心推荐链路允许降级；
• 正确性目标：不能超卖、不能重复扣款、订单状态必须可恢复；
• 履约目标：线上订单可以路由到仓库或门店，库存口径一致；
• 恢复目标：单可用区故障自动切换，重大故障有明确 RTO/RPO；
• 组织约束：商品、交易、库存、履约团队可以独立发布和扩容。

这一步决定图上应该出现什么。比如“不超卖”要求画出库存预占、版本控制和补偿；“非核心链路允许降级”要求画出隔离与降级；“团队独立发布”才构成领域服务化的真实理由。

三、画全景图：按照业务流向组织，而不是按技术品牌堆叠

一张可评审的零售电商全景图，可以从上到下画七层。

1. 触点渠道层

包括商城 App/H5、门店 POS、运营工作台，以及未来可能接入的小程序、第三方平台和开放 API。渠道被放在最外层，是为了提醒团队：不同终端的交互不同，但底层业务规则不能各写一套。

2. 体验与接入层

BFF 负责面向终端聚合页面数据，API Gateway 负责认证、鉴权、路由、灰度、限流和协议适配。两者职责不同：BFF 解决体验聚合，网关解决统一流量治理。

3. 业务领域层

领域边界应来自业务语言：会员域、商品域、营销域、搜索推荐域、交易域、支付域、库存域、履约域。这里强调“域”，而不是先决定有多少微服务。

一个领域内部可以先是模块，必要时再拆成服务。拆分依据通常是：变化频率不同、容量模型不同、可靠性等级不同、数据所有权不同、团队责任不同。

4. 事件与流程协同层

订单已创建、库存已预占、支付成功、履约已发货等事实通过事件传播。事件总线用于解耦副作用和跨域协作，但不应该掩盖核心链路：哪些步骤同步完成，哪些步骤异步处理，必须画清楚。

5. 数据与检索层

交易数据、领域数据、缓存、搜索索引和实时数仓用途不同：

• 订单、支付等事务数据优先保证正确性；
• Redis 承担热点和短生命周期状态，不是最终事实来源；
• 搜索引擎服务于检索和聚合，不承载交易真相；
• 湖仓或实时数仓服务于分析、画像、推荐和预测。

6. 平台治理层

日志、指标、链路追踪、限流、隔离、熔断、降级、风控和审计应该出现在正式架构图里。没有这些内容的图，最多只能说明“功能能跑”，不能说明“系统能稳定运行”。

7. 云与运行时底座

容器平台、弹性伸缩、多可用区、CI/CD、灰度发布、备份、容灾演练和容量成本治理，是架构从设计进入生产的最后一层。

四、画核心交易链路：把一致性边界和失败路径画出来

全景图说明系统边界，但真正决定电商系统质量的，是核心交易链路。

1. 正向链路要有清晰顺序

典型链路是：收银台提交订单 → 订单服务创建待支付订单 → 库存服务预占 → 支付服务确认 → 履约服务拆单和路由。

这不是唯一实现，但图必须回答：

• 价格以哪个时刻的快照为准；
• 重复点击是否会创建多个订单；
• 库存何时扣减或预占；
• 支付回调乱序、重复时如何处理；
• 支付成功后多久进入履约；
• 超时未支付时谁关闭订单并释放库存。

2. 一个服务内强一致，跨服务最终一致

订单服务写订单和 Outbox 记录，可以放在一个本地事务里；库存服务的预占记录与库存版本，也在自己的本地事务里完成。跨订单、库存、支付、履约四个数据所有者时，不应把数据库大事务强行拉长。

跨域一致性通常依靠：

• 业务状态机，限制状态只能合法迁移；
• Outbox 或事务消息，保证业务事实最终被发布；
• 消费幂等，允许安全重试；
• 重试队列和死信告警，避免失败被悄悄吞掉；
• 补偿动作，执行释放库存、关闭订单、原路退款；
• 对账与人工兜底，处理自动化无法判断的异常。

3. 失败路径要和成功路径同样醒目

很多图只画“正常箭头”，上线后才发现团队没有定义超时和补偿。架构评审时，可以逐个节点追问：

1. 调用超时后，调用方知道对方是否成功吗？
2. 重试会不会产生重复订单、重复扣款或重复发货？
3. 消息长时间未消费，谁会发现？
4. 补偿失败后，进入哪个人工处理队列？
5. 用户看到的订单状态如何解释系统正在恢复？

当这些问题能从图上找到责任边界，核心链路才算闭环。

五、高并发不是“加缓存”三个字

电商系统的读写模型差异很大，应分别设计。

高并发读

商品详情、类目、活动会场和推荐流量远高于交易流量。常见手段包括 CDN、页面静态化、多级缓存、热点隔离、搜索索引和读模型预计算。

但图中还要标出缓存的事实来源、失效策略、热点保护和降级结果。否则缓存只是把数据库问题变成一致性问题。

高并发写

下单、库存和支付写入不能只靠扩机器。应结合业务键做分区或分片，使用队列削峰，控制热点 SKU 的竞争，并保证每个写入入口都有幂等语义。

“异步化”也不是越多越好。影响用户即时决策的步骤应保持清晰同步结果；积分、通知、画像、报表等副作用更适合异步处理。

六、架构如何演进：每一步都应该有业务触发器

阶段一：单体起步

业务仍在验证期时，一个模块化单体和一个数据库通常是更好的选择。它事务简单、调试直接、发布成本低，最适合快速跑通商品—下单—支付闭环。

这一阶段的重点不是“提前微服务化”，而是保持模块边界、避免跨模块随意访问数据，为未来拆分留下接口。

阶段二：集群与缓存

访问量增加、大促峰值出现后，先解决容量和单点：无状态应用集群、负载均衡、缓存、读写分离、CDN、数据库备份和基本监控。

这一步主要解决“机器不够”和“单点故障”，不必同时完成组织和领域重构。

阶段三：领域服务化

当团队并行开发互相阻塞，商品、交易、库存、履约的容量和可靠性要求明显分化时，再按领域拆分服务。同步调用处理必要的即时确认，事件处理跨域副作用和最终一致性。

服务化同时会引入注册配置、调用治理、链路追踪、自动化发布和分布式一致性成本。因此，拆分收益必须大于这些新增复杂度。

阶段四：平台化架构

当企业进入多渠道、多品牌、多业态阶段，重复建设成为主要矛盾，才需要把会员、商品、交易、履约、营销等稳定能力平台化，并通过数据智能平台形成分析、推荐、预测和运营闭环。

平台化不是把所有服务归到一个“中台”名下，而是明确能力的产品责任、服务契约、版本策略、使用成本和退出机制。

七、如何判断架构到了该演进的时候

不要用“行业都这样做”推动演进。至少收集四类证据：

1. 业务规模：峰值容量、数据量、渠道数、品牌数是否持续突破现有设计；
2. 团队协作：发布冲突、跨团队等待、故障责任不清是否已成为主要成本；
3. 可靠性目标：现有故障域、恢复能力和数据一致性是否无法满足 SLO；
4. 变更成本：一个小需求是否需要修改大量模块并进行全量回归。

只有这些成本长期高于新架构带来的基础设施、开发、测试、运维和认知成本，演进才合理。

八、架构图评审清单

正式评审前，可以用下面的问题自检。

业务与范围

• 图的目标、读者和系统边界是否明确？
• 是否标出关键业务旅程和峰值场景？
• 哪些能力在范围内，哪些外部系统不在范围内？

边界与数据

• 服务边界是否符合业务语言和数据所有权？
• 谁是订单、库存、支付状态的事实来源？
• 是否存在跨服务直接读写数据库？
• 缓存、搜索、数仓与事务库的职责是否清楚？

调用与一致性

• 同步调用、异步事件、批处理是否用不同线型表达？
• 是否标出幂等、顺序、超时、重试和补偿？
• 失败路径、降级结果和人工兜底是否可见？

稳定性与安全

• 是否区分核心与非核心链路？
• 限流、隔离、熔断、降级、监控和告警是否进入设计？
• 是否说明多可用区、备份、RTO/RPO 和容灾演练？
• 敏感数据、支付风控、审计和权限边界是否明确？

演进与落地

• 当前架构要解决的主要矛盾是什么？
• 迁移步骤、双写或数据回填、灰度与回滚如何完成？
• 关键指标由谁观测，达到什么阈值后进入下一阶段？
• 架构决策是否记录为 ADR，并与代码和运行现状同步？

九、最常见的五个错误

1. 一上来就画终局

把多活、微服务、中台、事件驱动一次性搬到创业期系统，只会让团队先支付复杂度成本，却没有对应收益。

2. 只画技术组件，不画业务能力

一张只有网关、缓存、MQ 和数据库的图，无法解释系统为什么这样拆，也无法指导团队分工。

3. 箭头没有语义

同步请求、异步事件、数据复制、批处理全部用同一种箭头，读者无法判断时序、依赖和故障传播方向。

4. 只画成功路径

真实系统的大部分复杂度来自超时、重复、乱序、部分成功和外部依赖故障。失败路径缺失，意味着方案尚未完成。

5. 架构图发布后不再更新

过期图比没有图更危险。架构图应和代码、接口契约、SLO、告警、容量模型一起版本化，重大变更通过 ADR 记录原因和取舍。

结语

做好一张架构图，可以归纳成六个动作：

1. 明确读者和决策；
2. 把业务目标量化成架构约束；
3. 按业务能力划分边界；
4. 画清关键链路、数据所有权和失败路径；
5. 把稳定性、安全和运维能力放进图里；
6. 用业务证据驱动演进，并让图持续版本化。

真正专业的架构图，不在于组件多，而在于取舍清楚。它既能解释今天的系统为什么这样设计，也能说明什么时候应该走向下一阶段。