电商分布式架构设计：服务拆分、高并发与避坑实践

简介：这是一份聚焦电商平台分布式架构设计的方案文档，适用于正在规划系统扩展路径的架构师、技术负责人及后端开发者。文档以电商业务为背景，从架构设计的必要性与前提条件切入，系统梳理客户对在线购物、支付、物流、客服、评价等核心需求，并给出业务模块拆分与技术架构演进的整体思路。资源为单个docx文件，约1.46MB，内容结构完整，便于按章节阅读。文中覆盖从早期单体服务器，到应用/数据库/图片分离、缓存引入、集群与负载均衡，再到分布式、消息队列等高级设计的演变过程，并结合业务架构图与技术架构图说明各阶段选型理由。已有133人学习下载，适合希望理解电商后端架构设计逻辑、为高并发场景做技术准备的读者参考。

1. 电商平台分布式架构设计：先想清楚"为什么要拆"，再谈怎么拆

大多数电商平台走到分布式架构设计这一步，并不是流量先把它压垮了，而是复杂度先把它拖垮的。业务还在单机时，几十个开发往一个工程里叠代码，每次发布都要全员待命；订单、库存、支付耦合在一个进程里，改一行库存字段得拉着三个团队一起回归。这篇要聊的方案，就是一套能支撑高并发、可扩展、还能让团队并行开发的运行架构。它适合已经在做单体拆分、准备上微服务，或者正在经历大促压测的从业者。做这份设计时，我习惯先问一句：你想通过分布式得到什么？如果答案只是"高并发"，后面大概率会被一致性、链路追踪和运维复杂度反复折磨，方案选型也会跟着摇摆。

2. 分布式架构的底层逻辑：电商业务哪些特性决定了必须分布

2.1 电商业务的四个必然：高并发、高可用、数据一致性与成本弹性

电商和其他业务系统最大的差异是流量模型和链路复杂度。日常一个中小平台的QPS可能只有几千，大促瞬间冲到几十万，流量曲线像心电图；订单、库存、支付、物流、会员之间互相依赖，一次下单要跨越五六个服务。这四条核心特性，几乎决定了架构设计里所有的重要选择。

这张表是做架构评审时经常用来对需求的。高并发逼着你把服务拆开、把状态外置，让任何一台机器挂了都不影响整体；高可用逼着你接受"部分失败"：一个服务慢不能拖垮整条链路；数据一致性最让架构师头疼，因为它会让你在性能和正确性之间反复权衡；成本弹性则是容易被忽略的点，分布式架构能扛流量，但扛不住无意义的资源浪费，容量规划必须和业务预测一起做。

我见过不少团队把微服务拆得特别细，结果日常QPS只有几百，机器开了二十台，大部分时间利用率不到百分之五，这就是只看到了高并发、没算成本账。所以做方案之前，先把这四个必然摆到桌面上，所有设计决策都可以回到这四条来验证。

2.2 向上扩展还是向外扩展：服务粒度怎么切才不后悔

选扩展方向没有玄学，就是一台机器扛不住的时候，你是换更大的机器还是加更多机器。单机的CPU、内存、IO总有上限，一台64核512G内存的物理机，价格翻好几倍，性能和成本都不是线性增长，所以电商这类高并发业务默认选向外扩展。向外扩展的前提是服务无状态，或者状态被外置到缓存、数据库、对象存储里，否则扩容只会加剧数据不一致。

服务粒度怎么切，是架构设计里最容易争吵的地方。我一般先按业务域切：用户域、商品域、订单域、库存域、支付域。每个域一组服务，域名之间通过接口交互，不共享数据库表。这样切的理由有三条：第一是数据归属清晰，订单表归订单域管，其他域要查订单数据必须走接口；第二是变更频率隔离，商品改版不影响订单发布；第三是对应团队边界，一个域由一个小组维护，符合康威定律。

相反，如果按功能切，比如把"下单接口"单独拆一个服务、"查询接口"再拆一个服务，服务之间要互相调数据库，调用链绕来绕去，最后变成比单体更复杂的分布式单体。判断粒度是否合适有个实用标准：如果一次业务操作要在五个服务之间同步调用才能完成，而你又说不清每个服务独立存在的价值，那就说明拆碎了。五个服务演进成三十个服务很容易，但每个服务都变成调用链上的黑匣子，排查问题全靠日志拼图，这是做分布式最直接的代价。

2.3 动工之前的检查清单：分布式不是免费午餐

很多团队做架构设计时，上来就画服务拓扑图，画完才发现连基础问题都没回答。我这里有一份评估清单，是用在各种项目启动会上的，至少能把方向拉回正轨。

这份清单做完，不少团队会发现当前阶段根本不需要完整分布式。业务模式还没验证清楚时，我建议先做模块化单体：代码分模块、数据库分schema、对外接口明确，但部署还是一个进程。等流量和数据量真的到了单机瓶颈，再按模块边界拆成独立服务，不用推翻重来。

还有一点很多人忽略：做架构设计前，最好先按企业数据架构设计方法把领域模型和数据归属梳理一遍。尤其是订单、库存、商品这些核心域，定义清楚核心实体、实体关系和数据生命周期，后面做服务拆分、分库分表才有依据。这一步省掉，后面每个服务都觉得自己该管库存，最后库存数据散落三套，对账对到怀疑人生。

3. 从单体到分布式的落地路径：先拆分流量，再拆分服务

3.1 第一刀：接入层网关的职责边界与限流参数

从单体走向分布式的第一刀不应该切服务，而是先切流量入口。完整链路通常是：DNS做域名解析和就近接入，负载均衡做四层转发，API网关做七层路由、鉴权、限流和灰度，然后流量才进入业务服务。网关的作用是把横切逻辑从业务代码里抽出来，不然每个服务都要自己写一套鉴权和限流，标准肯定不一致。

网关限流是进入分布式之后必须过的第一关。大促时真正的风险不是服务本身扛不住，而是服务被打满之前，数据库连接池和线程池先耗尽，导致所有请求都排队超时。我一般会在网关层做按用户维度的限流。配置里几个参数是必须明确的：QPS阈值、突发容量、超时时间。

# 网关限流配置参考，按用户维度控制请求速率 spring: cloud: gateway: routes: - id: order_route uri: lb://order-service predicates: - Path=/api/order/** filters: - name: RequestRateLimiter args: key-resolver: "#{@userKeyResolver}" redis-rate-limiter.replenishRate: 500 redis-rate-limiter.burstCapacity: 2000

这里replenishRate是每秒向令牌桶补充的令牌数，决定平均放行速率；burstCapacity是桶容量，决定允许的瞬时突发量。burstCapacity不是越大越好，设成2000意味着瞬间能放2000个请求到后端，后端如果只能扛1000，突发过去就是雪上加霜。限流参数的设定要配合压测结果：先压出后端的真实上限，再留30%余量反推网关阈值。

网关还需要承担超时控制。每个路由都应该配置连接超时和读超时，比如连接超时1000ms、读超时3000ms。一旦某个下游服务变慢，网关要能快速返回失败，而不是一直占用线程等待。很多团队把超时时间设成默认值，服务一慢整条链路跟着卡，这就是没把网关当成架构的一部分来设计。

3.2 第二刀：把订单、用户、商品拆成独立服务

服务拆分是有顺序的，不是哪热闹先拆哪。我一般先拆用户和商品，因为这两个域相对独立，调用方多、变更频繁，拆开之后可以快速验证微服务的发布和隔离效果；订单、库存、支付涉及写一致性和分布式事务，难度高，放到第二批。

订单域拆分时要做一个关键决定：要不要在订单服务里保存商品快照。如果不保存，订单列表页每次都要调商品服务查标题和图片，一次列表N条订单就是N次远程调用，性能很难看。常见做法是在下单时把商品标题、单价、图片URL冗余到订单表里，查询不再依赖商品服务。这违反了"数据只归属一个域"的原则，但电商场景里冗余字段换性能是值得的，只要字段是下单时刻的不可变快照，不会产生更新冲突。

服务拆分后，接口版本管理要提前想清楚。订单服务的接口不能今天叫/api/order/create，明天改成/api/order/placeOrder，下游商品服务、支付服务全要跟着改。我在设计文档里会明确要求：所有对外接口带版本号，比如/api/v1/order/create，接口字段只增不改，废弃接口至少保留两个版本周期。这条规范看起来是小事，但真到十多个服务相互调用时，接口乱改就是发布事故的主要来源。

服务之间的调用还需要约定失败策略。读取类接口可以设置快速失败，返回降级数据；写入类接口要设置合理超时和重试，但不能无脑重试——下游已经处理成功、响应丢了，重试就会造成重复下单，所以写接口的重试必须配合幂等设计，这在第4章展开。

3.3 第三刀：分库分表与读写分离的拆法

服务拆完，数据库往往是下一个瓶颈。电商最典型的是订单库和库存库。以订单为例，单表数据量到千万级别，索引深度增加，写性能和查询性能都会明显下降。分库分表的第一原则是选对分片键。买家查询订单是最常见的场景，所以按user_id分片最合理。

// 分片路由规则：4个库，每库16张表 int dbIndex = (userId / 16) % 4; int tableIndex = userId % 16; String tableName = "t_order_" + tableIndex;

这段伪代码展示的是最简单的取模路由。dbIndex决定请求落到哪个库，tableIndex决定落到哪个表，同一个用户的订单永远落在同一个分片上。好处是单用户维度的查询只需要访问一个分片，不需要跨库聚合；坏处是后台运营如果要按seller_id查订单，这个查询要扫全部分片，根本没法用。

解决非分片键查询的常见做法是建索引表或宽表。比如维护一张order_seller_index，字段只有seller_id和order_id，也按seller_id分片；运营端查询先查索引表，再回订单表取详情。代价是写入时多一次冗余写入，但换来运营查询的可用性。千万级数据量下，索引表的异步写入可以通过消息队列来做，不阻塞主链路。

分片数量也不是拍脑袋定的。我习惯按三年数据量估算：假设年订单量2亿，三年6亿，单表容量尽量控制在1000万以内，需要60多张表，那么设计4库×16表等于64张表是合理的。注意分片数量要选择2的幂次，这样后续扩容时可以用一致性哈希的虚拟节点来迁移数据，代价最小。分表数量选成6库×11表这种非2的幂次，后面扩容时几乎要重写路由，这就是给自己挖坑。

读写分离在电商里也要区分场景。商品详情这种读多写少的场景适合主从分离；订单和库存写入路径绝对不能走从库，主从延迟哪怕只有几十毫秒，都可能让刚下单的用户查不到订单，投诉电话直接打爆。订单的查询要么走主库、要么走缓存，这个红线要在架构设计文档里写明。

3.4 异步化改造：消息队列到底放在哪一段

只要允许把同步调用变成异步，系统的抗压能力会上一个台阶。常见的做法是把非核心链路从请求线程里剥离：用户下单成功后，订单服务发一条消息给消息队列，然后由消费者去处理积分、会员等级、搜索索引更新、短信通知这类辅助业务。

消息队列的使用有几个参数要提前定好：重试次数、重试间隔、死信队列。消费失败不能无限重试，否则会拖死消息队列。我一般设置重试3次，间隔按指数退避（1秒、10秒、100秒），超过后进入死信队列，由人工或对账任务处理。这里的核心是定义清楚"什么算处理成功"：消费者拿到消息，写完业务数据，提交offset，才叫成功；如果业务写了一半应用宕机，消息会被重新投递，所以消费者必须实现幂等，这个点和第4章紧密相关。

还有一类消息不能异步，那就是库存扣减。如果下单流程先返回成功、再异步扣库存，库存不足时订单已经创建了，后续要么自动取消订单，要么超卖。要异步削峰，就得用缓存预扣减库存加异步落库的机制，这个在秒杀场景里再细说。异步化的原则一句话：能异步的都异步，但涉及资金和库存的最终一致链路，必须有兜底对账。

4. 核心场景的分布式设计：订单、库存、支付与定时任务

4.1 分布式事务选型：本地消息表、TCC与SAGA怎么权衡

跨服务的写一致性是分布式架构设计里最绕不开的话题。订单创建要扣库存、支付成功要改订单状态、下单要加积分，每个环节跨一个服务，数据库本地事务管不到别人家。解决方式不能一上来就上强一致，电商的高并发场景，强一致往往意味着低吞吐。

本地消息表是最容易落地的方案：核心服务在本地库建一张消息表，业务操作和消息写入在同一个数据库事务里完成，保证二者同时成功或同时失败；然后通过定时任务把消息表里的记录轮询发送到MQ。这个方案实现简单，缺点是要写对账和清理逻辑，消息表会持续膨胀，需要定期归档。

TCC思路是把一个操作拆成Try、Confirm、Cancel三步。下单时先Try冻结库存，订单确认后Confirm扣减，超时或失败则Cancel释放。TCC控制力强，但实现时要处理空回滚和悬挂两个麻烦，后面避坑章节详细写。SAGA适合跨多个服务的长时间业务流程，比如下单、扣库存、出库、物流，每一步一个事务，失败则逆向补偿。选型经验是：能不用分布式事务就不用了，优先通过业务流程设计规避；实在躲不开，首选本地消息表，资金类场景才上TCC，链路特别长的流程用SAGA编排。

4.2 幂等设计：支付回调和下单请求为什么必须挡重

分布式环境下，重复请求是常态。支付平台回调可能因为网络超时重发三次，用户手抖点了两下"提交订单"按钮，MQ消费端处理完业务但还没来得及提交消息，消息又被投递一次。如果没有幂等保护，重复支付回调会让订单状态被覆盖成异常，重复下单会造出两笔一模一样的订单。

幂等设计最可靠的方式是数据库唯一约束。我一般会在核心服务里建一张幂等记录表，业务执行前先插入记录，成功才能继续。

CREATE TABLE `idempotent_record` ( `id` bigint NOT NULL AUTO_INCREMENT, `biz_type` varchar(32) NOT NULL COMMENT '业务类型：PAY_CALLBACK/ORDER_CREATE', `biz_id` varchar(64) NOT NULL COMMENT '业务唯一键，例如支付流水号', `status` tinyint NOT NULL DEFAULT '0' COMMENT '0处理中 1成功 2失败', `expire_time` datetime NOT NULL COMMENT '幂等记录过期时间', PRIMARY KEY (`id`), UNIQUE KEY `uk_biz_type_biz_id` (`biz_type`, `biz_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;

这个表的关键是uk_biz_type_biz_id联合唯一索引，数据库层面保证同一个业务ID只能插入一次。处理流程是：先插入status=0的幂等记录，插入成功说明是第一次请求，继续执行业务；插入失败说明是重复请求，直接返回上次的结果。业务执行完把status改成1，执行失败改成2，下次重试就能根据状态决定是恢复还是跳过。

幂等键的选取也讲究。支付回调要用支付平台返回的支付流水号，因为一次支付可能对应多笔订单？不对，应该是一笔支付对应一个支付流水号，用它当唯一键最准。下单请求要用客户端生成的UUID业务流水号，而不是订单号——订单号是服务端创建的，下单请求重复时订单号还没生成，复用不了。设计文档里必须明确每个写接口的幂等键来源，否则开发各写各的，等于没做。

4.3 秒杀与峰值流量：缓存预减库存与MQ削峰

秒杀是电商分布式架构里最极端的场景。有限的库存、巨大的瞬间流量，系统目标不是让每个请求都成功，而是保护主链路在极端流量下不崩溃。秒杀架构的核心是分层拦截：请求先过网关限流，再进秒杀服务判断资格，然后从Redis预减库存，最后通过消息队列异步落库。

// 预扣库存：Redis原子操作，扣减后小于0说明已被抢完 Long remain = redisTemplate.opsForValue().decrement(stockKey); if (remain < 0) { redisTemplate.opsForValue().increment(stockKey); // 回补库存 return "已售罄"; }

这里decrement是Redis的原子操作，不会出现两个并发请求同时读到同一个库存值，从根源上防止超卖。但要注意，扣减成功不等于真正买到，Redis里扣的只是预占数量，真正的库存扣减要等订单创建完成后再改数据库。如果用户抢到了却一直没有提交订单，就要靠后面讲到的分布式定时任务把超时未支付的预占库存回补。

秒杀流量不能全部放进订单创建链路。我一般会在秒杀服务后接一个消息队列，用户抢到资格后立即返回"排队中"，订单真正创建交给MQ消费者异步处理。这样就算瞬间有10万人抢，真正打到订单服务的只有每秒钟几百个。数据库层还要加一道兜底，扣库存的SQL必须带条件：

UPDATE t_inventory SET stock = stock - 1 WHERE sku_id = ? AND stock > 0;

AND stock > 0这个条件保证即使Redis层被绕过或者缓存失效，数据库也不会扣成负数。这条SQL是库存超卖的最后一道防线，任何一层缓存失误，数据库还能兜住。秒杀链路还必须有降级方案：Redis挂了就把秒杀活动开关切到DB限流，甚至直接拒绝本次秒杀，而不是让异常流量打到订单核心链路。

4.4 分布式定时任务：Spring Cloud环境下为什么不能用@Scheduled

在Spring Cloud微服务架构里直接写@Scheduled定时任务是新手最容易犯的错误。定时任务写在每个订单服务实例里，服务部署了三台，定时任务就同时执行三次。如果这个任务是"关闭超时未支付订单"，三个实例同时跑，可能关闭同一批订单，配合幂等设计还不至于出大乱子；但如果是"对账后发送短信"，三次执行就是三条短信，用户直接投诉。

分布式定时任务的正解是把任务调度从业务实例里抽出来，独立成调度中心，由调度中心触发任务执行，业务实例只提供执行入口。任务指定分片或者分布式锁，保证任意时刻全局只有一个实例在执行某个任务。

@Aspect @Component public class DistLockAspect { @Around("@annotation(distLock)") public Object around(ProceedingJoinPoint pjp, DistLock distLock) throws Throwable { String key = "lock:" + distLock.key(); // setIfAbsent 对应 SET key value NX EX，原子占锁 boolean locked = redisTemplate.opsForValue() .setIfAbsent(key, UUID.randomUUID().toString(), distLock.expireSeconds(), TimeUnit.SECONDS); if (!locked) { // 其他实例已经拿到锁，直接跳过本次执行 return null; } try { return pjp.proceed(); } finally { // 释放锁时要先校验持有者，防止误删别人的锁 redisTemplate.delete(key); } } }

这段AOP的本质就是分布式锁。setIfAbsent用Redis的SET NX EX原子语义，保证同一时刻只有一个实例能拿到锁；expireSeconds是锁的过期时间，必须大于任务实际执行耗时的最大值。否则任务执行到一半锁就过期了，另一个实例又拿到锁，任务重复执行，这就是网上常说的"锁过期导致的重复执行翻车"。

任务调度本身还要支持分片扫描。比如关闭超时订单这个任务每次扫描全表，数据量大时一次扫描几十秒，锁过期风险很高。更稳的写法是按用户ID分片，每个分片扫一部分数据，所有分片任务并行执行，缩短单次执行时间。Cron表达式也建议错峰，比如整点任务尽量避开数据库备份时间，0 0/10 * * * ?这类每十分钟的任务，最好配置在执行低峰期。

5. 分布式架构设计避坑：从真实故障里捞出来的五个翻车现场

5.1 缓存穿透、击穿与雪崩：现象一字之差，处置完全不同

现象：某个商品详情接口突然大量请求打到数据库，数据库QPS飙升到上限，整条链路跟着慢。排查时有人喊缓存穿透，有人喊缓存击穿，最后发现根本不是一回事，处置方案也完全不同。

原因：穿透是请求的key在缓存和数据库里都不存在，比如恶意用不存在的商品ID刷接口，缓存挡不住，每个请求都穿透到数据库；击穿是某个热点key在某一刻过期，比如爆款商品的缓存刚好失效，一瞬间大量请求全部涌向数据库；雪崩则是大批key同时过期，缓存层短时间内整体失效，数据库和依赖服务被压垮。

解决：穿透要用空值缓存或布隆过滤器，把不存在的key也缓存起来，缓存时间设短一些，比如60秒；击穿要给热点key加互斥锁，只放一个请求去重建缓存，其他请求等待或直接返回旧值；雪崩最容易预防，缓存过期时间不要设置为固定值，加一个随机偏移量，让过期时间分散。比如商品缓存设置3600秒，实际设置3600 + random(0, 300)秒。这条经验几乎每次大促前都要检查一遍，代码里写死过期时间的，全部改成随机偏移。

5.2 分库分表后的跨库查询与分布式ID

现象：订单分库分表之后，运营后台的"订单列表"接口变得异常慢，原来一次SQL查询变成几百次短查询，页面加载几十秒都出不来。

原因：分片键选的是user_id，但运营后台是按order_id或seller_id维度的查询，路由规则定位不到具体分片，只能全库全表扫描。再加上列表要展示买家昵称、商品标题，而这些字段在订单表里没有冗余，每一行都要回查用户服务和商品服务，形成了典型的N+1查询。

解决：按查询维度建索引表，比如order_seller_index表按seller_id分片，运营查询先定位到索引表，再回订单表。更彻底的做法是建立独立的读模型：订单写服务把数据同步到一套专门用于查询的分析库，运营端完全走读模型，不再碰在线订单表。如果沿用订单表直接做列表查询，就得把买家昵称、商品标题等展示字段冗余到订单表里，牺牲存储换性能。另外分布式ID要用雪花算法这类全局唯一方案，不能继续用数据库自增主键，否则多个分片会产生重复ID，一旦生成又改不了，后悔药都没有，所以上线前就要定好。

5.3 消息重复消费：至少一次投递下的幂等底线

现象：用户支付成功后收到两条"已支付"通知，账户积分被加了两次，搜索索引里的订单状态被重复刷新。后端查日志发现，支付成功消息被MQ投递了三次。

原因：消息中间件为了保证不丢消息，普遍采用at-least-once投递语义，消费者处理完消息还没来得及提交消费位点就宕机、超时或重启，消息会被重新投递。这是消息系统的设计取舍，不是配置错了。

解决：消费端必须按业务主键做幂等。以支付成功消息为例，消费时先查幂等表里有没有这笔支付流水号的记录，有就直接Ack，没有才执行加积分、更新订单状态。幂等表唯一索引是兜底，防止并发消息同时到达。我再强调一次：不能依赖"消息只被消费一次"这种假设，分布式环境里重复是常态，幂等是底线。另外，消费逻辑里的查询和插入要放在同一个事务里，查询到不存在、然后插入时被另一个重复消息抢先插入，这边就会插入失败，所以要捕获唯一键冲突，视为幂等成功。

5.4 TCC空回滚与悬挂：分布式事务的失控瞬间

现象：订单支付超时后，TCC协调器发起了Cancel，但此时Try请求因为网络原因还没到达账务服务。账务服务收到Cancel后查不到对应的Try记录，就当作空操作直接返回成功。随后Try请求又到达了，账务服务发现是新的Try，正常执行了资源预留。结果是一笔已经取消的事务，资源却被成功预占了。

原因：这是分布式事务里的空回滚和悬挂问题。空回滚是指在Try还没执行的情况下就收到Cancel，做了无意义的回滚；更危险的是悬挂，Try在Cancel之后才到达，资源被预留但永远不会被Confirm或Cancel释放。根因是网络调用时序无法保证，Try、Confirm、Cancel三个请求通过不同的网络路径到达对端，顺序可能颠倒。

解决：给每个事务分支加一张事务控制表，记录事务ID和分支状态。Try到达时检查状态：如果是CANCELED，说明Cancel已经先到，Try必须拒绝执行，不做资源预留；如果状态是NEW，才允许执行Try并更新状态为TRIED。Cancel到达时如果查不到Try记录，要写入一条CANCELED记录而不是直接返回，这样才能挡住后到的Try。这张状态表是分布式事务参与者层面的"记忆"，没有它，TCC在一些异常时序下就是失控的。

5.5 容量估算拍脑袋与压测失真

现象：压测报告显示核心下单链路能扛5000 QPS，大促当天流量刚到3000 QPS，数据库连接池先爆了，订单服务频繁超时，整个页面都在转圈。

原因：压测模型和真实流量不一致。压测时用脚本均匀地请求下单接口，而真实用户的行为是点开页面、浏览、加购、下单混杂在一起的，热点商品集中在少数几个SKU上，Redis、数据库、消息队列的访问不是均匀的，而是打在同一批热点数据上。还有压测只测了单业务链路，没有模拟服务间调用互相挤占线程池的情况，一个服务变慢，线程堆积，其他服务也跟着阻塞。

解决：压测场景要带长尾和热点。我的做法是按真实流量比例构造混合链路，比如浏览、加购、下单、支付比例为100:10:1，并且把数据集中到少量热点商品上；压测时间至少持续1小时，观察内存和连接数是否缓慢增长。容量估算要留30%冗余，不要按压测峰值卡线部署。更重要的是做故障演练：随机停掉一个订单服务实例，确认网关能把流量切走，确认数据库连接池不会被打满。压测结果不是用来写报告邀功的，是拿来找系统最短板的。

6. 验证与进阶：用一个最小订单链路检验你的架构设计

架构设计文档写得再完整，不经过验证都是纸面功夫。我习惯在任何分布式架构落地前，先搭一条最小订单链路来做验证：用户服务、订单服务、库存服务、支付回调模拟、MQ、MySQL、Redis，加上网关，七个子系统就够了。不要一上来就铺三十个服务，验证的是设计逻辑，不是服务数量。

这四个验证做完，架构设计里大部分纸上谈兵的问题都会现出原形。压测不过就回头调限流阈值、扩容节点，不要硬上线；对账有差异就查消息重试和幂等逻辑，不要指望生产环境自愈。

这些年带分布式架构，我吃过最大的亏是上线前不做故障演练，以为多部署几个实例就安全了，结果一次机房网络抖动，所有服务重试风暴直接打垮数据库。从那以后我的习惯是：任何分布式方案上线前，先问三个问题——某个服务挂了会怎样，缓存全丢会怎样，MQ整体不可用会怎样。把这三种情况在演练环境真实验证过，再谈上线。这套方法不一定最先进，但能让你在真正的故障来临时少一点手足无措。希望帮到你。

本文还有配套的精品资源，点击获取