简介这份《电商平台系统建设方案》是一份面向O2O在线购物平台建设的完整技术文档适合项目经理、开发人员、业务分析师及运营团队参考用于梳理从需求分析到系统落地的整体思路。方案围绕用户管理、商品管理、订单处理、支付系统、物流追踪等核心子系统展开并覆盖用户接口、硬件接口、软件接口与通信接口的设计要求同时涉及性能、安全、数据传输等非功能需求。资源包内含1个docx文档压缩包约268KB结构清晰、章节完整便于按模块查阅。文档从前言、术语与缩略语、目标用户、支付与沟通方式到设计概述、系统架构、接口需求及安全策略均有展开可帮助读者快速理解电商平台的功能边界与实施要点。目前已有77人学习适合需要撰写系统方案、搭建平台架构或补充O2O业务知识的技术与产品人员参考。1. 电商平台系统建设方案从一份 docx 里拆出可落地的架构决策如果你正在负责一个电商项目的技术选型或者被老板丢过来一句“两周内出一份系统建设方案”那你大概率会需要一份能直接对标行业主流做法的参考文档。这份《电商平台系统建设方案.docx》就是干这个用的——它不是某个开源项目的 README也不是某家云厂商的推销白皮书而是一份从业务架构、技术架构到部署运维都覆盖到的方案型文档。我拿到手之后第一件事不是通读而是翻到技术架构那一章看它怎么拆服务边界、怎么定数据一致性策略。因为电商系统最怕的不是功能多而是订单、库存、支付三者的状态流转没设计好上线后天天对账。这份文档适合三类人刚接手电商项目的后端负责人、需要写技术方案的架构师、以及想理解电商系统全貌的全栈开发者。它解决的核心问题是让你在动手写代码之前先把该定的东西定下来。2. 业务架构拆解从用户端到履约端的模块划分逻辑2.1 电商系统的四层业务域是怎么切的一份建设方案能不能用先看它的业务架构是不是按真实交易链路来切的。这份文档把整个平台拆成四层用户域、商品域、交易域、履约域。用户域管注册登录、会员等级、收货地址商品域管类目、SPU/SKU、库存、价格交易域管购物车、订单、支付、优惠券履约域管发货、物流、售后。这个切法不是拍脑袋来的它对应的是电商系统里数据一致性要求的不同等级。用户域和商品域可以接受最终一致比如会员等级更新晚几秒无所谓。但交易域和履约域必须强一致或者用可靠消息来保证否则会出现“订单已支付但库存没扣”这种血泪场景。文档里给了一张业务域划分表我把它整理成更直观的对比业务域核心实体一致性要求典型并发量级用户域用户、地址、等级最终一致中低商品域类目、SPU、SKU、库存库存强一致高交易域购物车、订单、支付单强一致极高履约域发货单、物流单、售后单最终一致中这张表的价值在于它直接决定了你后面做微服务拆分时哪些服务可以独立部署、哪些必须共享数据库或者走分布式事务。我见过太多团队把库存和订单拆成两个独立服务结果每次大促都超卖最后又合并回去。文档里明确建议库存扣减和订单创建放在同一个本地事务里或者用 TCC 模式不要图省事用消息队列异步扣库存。2.2 从业务域到微服务边界的映射方法业务域切完之后下一步是映射到具体的服务。文档给了一个原则一个业务域可以对应多个微服务但一个微服务不能跨两个业务域。比如交易域可以拆成购物车服务、订单服务、支付服务、优惠券服务但订单服务不能同时管库存。具体操作上我一般会按这个步骤来列出所有业务用例比如“用户下单”“用户支付”“运营改价”“仓库发货”。每个用例标注它涉及哪些业务域。把频繁交互且数据强相关的用例归到同一个服务里。检查跨服务调用是否可以用异步消息替代同步调用。文档里给了一个订单创建的时序描述虽然没有画图但文字写得很清楚用户提交订单 → 订单服务校验商品和价格 → 调用库存服务预占库存 → 生成订单 → 返回支付参数。这里的关键是“预占库存”而不是“扣减库存”因为用户可能不付款。预占库存需要一个超时释放机制文档建议用延迟消息或者定时任务扫表。提示如果你用的是 RocketMQ延迟消息可以做到 30 分钟精度如果用 RabbitMQ需要装延迟插件。没有消息队列的话用 Redis 的 zset 存预占记录定时任务每分钟扫一次过期 key。3. 技术架构选型Spring Cloud 与 Dubbo 的取舍依据3.1 微服务框架选型的三个硬指标文档在技术架构章节花了很大篇幅对比 Spring Cloud 和 Dubbo。它没有直接说哪个好而是给了三个硬指标服务治理能力、协议性能、团队熟悉度。服务治理包括限流、熔断、降级、链路追踪Spring Cloud Alibaba 这套用 Sentinel 和 Sleuth 基本开箱即用Dubbo 需要自己集成 Sentinel 或者用 Dubbo 自带的治理中心。协议性能上Dubbo 默认走 Dubbo 协议比 HTTP 快但 Spring Cloud 可以用 gRPC 或者 Feign 加连接池来弥补。团队熟悉度这个指标最容易被忽略。文档里写了一句很实在的话“如果团队里没人写过 Dubbo 的泛化调用和异步调用那选 Spring Cloud 至少能保证出问题的时候有人能查。”我自己的经验也是这样Spring Cloud 的文档和社区案例多遇到坑搜一下基本有答案Dubbo 的很多问题需要看源码或者去邮件列表问。文档最终的建议是中小团队用 Spring Cloud Alibaba大团队或者对性能有极致要求的用 Dubbo 3.x。这个建议不算新鲜但它把理由写清楚了不是拍脑袋。3.2 数据存储与缓存的具体配置参数电商系统的数据存储选型文档给了明确的组合MySQL 做交易数据Redis 做缓存和分布式锁Elasticsearch 做商品搜索MongoDB 做日志和用户行为数据。这个组合是行业主流没什么争议。但文档里给了一些具体的参数建议这些才是真正能抄作业的地方。MySQL 方面文档建议订单表按用户 ID 分库分表用 ShardingSphere 做中间件。分片数建议是 2 的幂次比如 16 库 64 表方便后续扩容。每个分片的数据量控制在 500 万行以内。连接池用 HikariCP最大连接数设为 CPU 核数乘以 2 再加磁盘数这个公式来自 PostgreSQL 的推荐MySQL 也适用。Redis 方面文档建议缓存商品详情用 Hash 结构过期时间加随机值防止雪崩。分布式锁用 Redisson不要自己用 SETNX 实现因为锁续期和可重入很容易写错。库存扣减用 Lua 脚本保证原子性脚本大概长这样-- 库存扣减 Lua 脚本 -- KEYS[1]: 库存 key -- ARGV[1]: 扣减数量 -- ARGV[2]: 当前时间戳 local stock redis.call(GET, KEYS[1]) if not stock then return -1 -- 库存不存在 end if tonumber(stock) tonumber(ARGV[1]) then return -2 -- 库存不足 end redis.call(DECRBY, KEYS[1], ARGV[1]) return tonumber(stock) - tonumber(ARGV[1])这段脚本的逻辑是先检查库存是否存在再检查是否足够最后扣减并返回剩余库存。参数说明KEYS[1] 是库存的 Redis key通常用stock:sku:{skuId}格式ARGV[1] 是扣减数量一般传 1ARGV[2] 是时间戳用于后续排查问题时记录操作时间。返回值 -1 表示库存未初始化-2 表示库存不足正数表示扣减后的剩余库存。调用的时候用EVAL或者EVALSHARedisson 的RScript接口可以直接用。Elasticsearch 方面文档建议商品索引按类目和价格区间做分片副本数至少 1。搜索建议用bool查询组合must和filterfilter不走评分性能更好。MongoDB 用来存用户行为日志按天分集合设置 TTL 索引自动过期。注意Redis 的 Lua 脚本里不要用KEYS命令遍历所有 key因为 Redis 是单线程的遍历大量 key 会阻塞其他请求。库存扣减只操作单个 key所以没问题。4. 部署与运维方案容器化与监控告警的落地细节4.1 Docker 与 Kubernetes 的部署清单文档在部署章节给了一套完整的容器化方案。基础镜像是 OpenJDK 17 的 slim 版本应用打包成 fat jar 后复制进去。Dockerfile 大概是这样FROM openjdk:17-jdk-slim WORKDIR /app COPY target/order-service.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, -Xms512m, -Xmx1024m, -Dspring.profiles.activeprod, app.jar]逻辑说明基础镜像用 slim 版本减小体积WORKDIR设置工作目录COPY把构建好的 jar 包复制进去EXPOSE声明端口ENTRYPOINT启动应用并指定 JVM 参数和 Spring profile。参数说明-Xms512m是初始堆大小-Xmx1024m是最大堆大小生产环境建议根据容器内存限制来设一般是容器内存的 50% 到 75%。-Dspring.profiles.activeprod指定生产环境配置。Kubernetes 方面文档建议每个服务至少 2 个副本用 Deployment 管理。资源限制按服务的重要性来分订单服务和支付服务给 2 核 4G商品服务和用户服务给 1 核 2G。健康检查用/actuator/health端点就绪探针和存活探针分开配置。就绪探针的initialDelaySeconds设为 30存活探针设为 60因为 Java 应用启动比较慢。4.2 监控告警的指标与阈值设置文档给了一套基于 Prometheus Grafana 的监控方案。需要采集的指标包括JVM 内存和 GC 次数、HTTP 请求的 QPS 和延迟、数据库连接池活跃数、Redis 命中率、消息队列积压量。告警阈值方面文档建议JVM 老年代使用率超过 80% 持续 5 分钟告警HTTP 接口 P99 延迟超过 500ms 持续 1 分钟告警数据库连接池活跃数超过最大连接数的 80% 告警Redis 命中率低于 90% 告警消息队列积压超过 1000 条告警这些阈值不是绝对的需要根据业务量调整。但文档里有一句话很关键“告警不是越多越好每条告警都必须有对应的处理动作否则就是噪音。”我见过一个团队配了 200 多条告警结果每天收到几百条通知最后所有人都把告警静音了真出问题的时候没人知道。日志收集用 ELK 或者 Loki文档建议用 Loki因为资源占用比 ELK 小。日志格式统一用 JSON方便解析。链路追踪用 SkyWalking 或者 Jaeger文档建议用 SkyWalking因为对 Java 应用无侵入只需要加启动参数。5. 避坑与常见问题从超卖到分布式事务的排查记录5.1 库存超卖的三种典型场景现象大促期间库存扣成负数或者同一个 SKU 卖出超过实际库存。原因通常有三种第一种是缓存和数据库不一致Redis 扣了但数据库没扣第二种是并发扣减时没有加锁两个请求同时读到相同库存然后各自扣减第三种是预占库存没有释放导致可用库存越来越少。解决第一种情况用延迟双删或者 Canal 监听 binlog 来同步缓存第二种情况用 Redis Lua 脚本或者分布式锁第三种情况用延迟消息或者定时任务扫预占记录超过 30 分钟未支付的自动释放。文档里特别强调预占库存和实际扣减要分开记录预占用 Redis实际扣减用数据库对账的时候两边都要查。5.2 分布式事务导致订单状态不一致现象用户支付成功但订单状态还是“待支付”或者订单已取消但支付单还是“已支付”。原因订单服务和支付服务用了不同的数据库跨服务调用没有保证原子性。常见做法是用 Seata 的 AT 模式或者 TCC 模式但 Seata 对业务代码有侵入TCC 需要自己写补偿逻辑。解决文档建议对一致性要求极高的场景用 TCC比如支付和订单。TCC 的三个阶段是 Try、Confirm、CancelTry 阶段预留资源Confirm 阶段确认Cancel 阶段回滚。如果不想引入 Seata可以用本地消息表加定时任务补偿。本地消息表的思路是在订单库建一张消息表订单创建和消息插入在同一个本地事务里然后定时任务扫消息表发送到消息队列支付服务消费消息后更新支付状态。5.3 缓存雪崩和热点 key 问题现象大量缓存同时过期请求全部打到数据库数据库连接池被打满。或者某个热点商品被大量请求Redis 单节点 CPU 跑满。原因缓存过期时间设了固定值没有加随机值热点 key 没有做本地缓存或者多级缓存。解决过期时间加随机值比如基础过期时间 30 分钟随机加 0 到 5 分钟。热点 key 用本地缓存加 Redis 两级缓存本地缓存用 Caffeine过期时间设短一点比如 5 秒。文档里还提到热点 key 可以用 Redis 的CLUSTER KEYSLOT命令查看落在哪个节点如果集中在某个节点可以考虑用 hash tag 打散。5.4 消息队列消息丢失和重复消费现象订单创建后发送消息到队列但库存服务没收到导致库存没扣。或者库存服务收到了两条相同的消息扣了两次库存。原因消息丢失可能是生产者发送失败、队列持久化没开、消费者手动确认没配好重复消费是因为网络抖动导致生产者重发或者消费者处理完没及时确认。解决生产者用同步发送加重试队列开启持久化消费者手动确认。重复消费用幂等性解决比如每条消息带一个唯一 ID消费者处理前先查 Redis 看这个 ID 是否已处理过。文档建议幂等键用业务 ID比如订单号加操作类型不要用消息 ID因为消息 ID 可能变。5.5 数据库连接池配置不当导致请求阻塞现象接口响应时间突然变长日志里出现“等待连接超时”。原因连接池最大连接数设得太小或者连接泄漏没有回收。常见做法是 HikariCP 的maximumPoolSize设为 CPU 核数乘以 2 再加磁盘数但很多人直接设成 100 或者 200结果数据库端连接数爆了。解决先看数据库的max_connections是多少然后算一下所有服务加起来的总连接数不能超过这个值。HikariCP 的connectionTimeout设成 3 秒idleTimeout设成 10 分钟maxLifetime设成 30 分钟比数据库的wait_timeout小一点。如果还是出现等待检查代码里有没有手动获取连接没关闭的地方用try-with-resources或者Transactional让框架管理。6. 方案验证与迭代用压测和混沌工程检验架构韧性方案写完不是终点能不能扛住真实流量才是。文档最后一章给了验证方法我把它拆成两个可执行的步骤压测和混沌工程。压测用 JMeter 或者 wrk重点压三个接口商品详情、下单、支付。商品详情看缓存命中率和 Redis 延迟下单看库存扣减的原子性和数据库写入速度支付看分布式事务的成功率。压测参数从低到高逐步加先压 100 QPS 跑 10 分钟观察错误率和延迟没问题再加到 500 QPS再到 1000 QPS。文档建议在压测环境模拟真实数据量比如商品表至少 100 万行订单表至少 1000 万行否则压测结果没有参考价值。混沌工程用 ChaosBlade 或者 Litmus模拟三种故障Redis 节点宕机、MySQL 主库延迟、消息队列积压。Redis 宕机看本地缓存能不能顶住MySQL 延迟看读写分离和降级策略是否生效消息队列积压看消费者扩容能不能及时跟上。文档里有一句话我印象很深“不要等到大促当天才发现降级开关没配好。”我自己的习惯是每次大版本上线前强制走一遍混沌演练至少模拟一次 Redis 不可用和一次数据库主从切换。验证通过之后方案要迭代。迭代的依据是监控数据和故障复盘。文档建议每季度做一次架构复盘重点看三个指标可用性、延迟、成本。可用性低于 99.95% 就要找原因延迟 P99 超过 500ms 就要优化成本超过预算就要考虑降配或者换方案。我一般会在复盘会上让每个人写一条“最后悔的决策”比如“当初不该把库存和订单拆成两个服务”这些后悔药比成功经验更有价值。从那以后我每次写建设方案都会在最后一页加一个“验证清单”把压测场景、混沌演练、回滚步骤列清楚不写完不准上线。希望这份拆解能帮到你少走一些我走过的弯路。本文还有配套的精品资源点击获取 电商平台系统建设方案：架构决策与避坑指南
简介这份《电商平台系统建设方案》是一份面向O2O在线购物平台建设的完整技术文档适合项目经理、开发人员、业务分析师及运营团队参考用于梳理从需求分析到系统落地的整体思路。方案围绕用户管理、商品管理、订单处理、支付系统、物流追踪等核心子系统展开并覆盖用户接口、硬件接口、软件接口与通信接口的设计要求同时涉及性能、安全、数据传输等非功能需求。资源包内含1个docx文档压缩包约268KB结构清晰、章节完整便于按模块查阅。文档从前言、术语与缩略语、目标用户、支付与沟通方式到设计概述、系统架构、接口需求及安全策略均有展开可帮助读者快速理解电商平台的功能边界与实施要点。目前已有77人学习适合需要撰写系统方案、搭建平台架构或补充O2O业务知识的技术与产品人员参考。1. 电商平台系统建设方案从一份 docx 里拆出可落地的架构决策如果你正在负责一个电商项目的技术选型或者被老板丢过来一句“两周内出一份系统建设方案”那你大概率会需要一份能直接对标行业主流做法的参考文档。这份《电商平台系统建设方案.docx》就是干这个用的——它不是某个开源项目的 README也不是某家云厂商的推销白皮书而是一份从业务架构、技术架构到部署运维都覆盖到的方案型文档。我拿到手之后第一件事不是通读而是翻到技术架构那一章看它怎么拆服务边界、怎么定数据一致性策略。因为电商系统最怕的不是功能多而是订单、库存、支付三者的状态流转没设计好上线后天天对账。这份文档适合三类人刚接手电商项目的后端负责人、需要写技术方案的架构师、以及想理解电商系统全貌的全栈开发者。它解决的核心问题是让你在动手写代码之前先把该定的东西定下来。2. 业务架构拆解从用户端到履约端的模块划分逻辑2.1 电商系统的四层业务域是怎么切的一份建设方案能不能用先看它的业务架构是不是按真实交易链路来切的。这份文档把整个平台拆成四层用户域、商品域、交易域、履约域。用户域管注册登录、会员等级、收货地址商品域管类目、SPU/SKU、库存、价格交易域管购物车、订单、支付、优惠券履约域管发货、物流、售后。这个切法不是拍脑袋来的它对应的是电商系统里数据一致性要求的不同等级。用户域和商品域可以接受最终一致比如会员等级更新晚几秒无所谓。但交易域和履约域必须强一致或者用可靠消息来保证否则会出现“订单已支付但库存没扣”这种血泪场景。文档里给了一张业务域划分表我把它整理成更直观的对比业务域核心实体一致性要求典型并发量级用户域用户、地址、等级最终一致中低商品域类目、SPU、SKU、库存库存强一致高交易域购物车、订单、支付单强一致极高履约域发货单、物流单、售后单最终一致中这张表的价值在于它直接决定了你后面做微服务拆分时哪些服务可以独立部署、哪些必须共享数据库或者走分布式事务。我见过太多团队把库存和订单拆成两个独立服务结果每次大促都超卖最后又合并回去。文档里明确建议库存扣减和订单创建放在同一个本地事务里或者用 TCC 模式不要图省事用消息队列异步扣库存。2.2 从业务域到微服务边界的映射方法业务域切完之后下一步是映射到具体的服务。文档给了一个原则一个业务域可以对应多个微服务但一个微服务不能跨两个业务域。比如交易域可以拆成购物车服务、订单服务、支付服务、优惠券服务但订单服务不能同时管库存。具体操作上我一般会按这个步骤来列出所有业务用例比如“用户下单”“用户支付”“运营改价”“仓库发货”。每个用例标注它涉及哪些业务域。把频繁交互且数据强相关的用例归到同一个服务里。检查跨服务调用是否可以用异步消息替代同步调用。文档里给了一个订单创建的时序描述虽然没有画图但文字写得很清楚用户提交订单 → 订单服务校验商品和价格 → 调用库存服务预占库存 → 生成订单 → 返回支付参数。这里的关键是“预占库存”而不是“扣减库存”因为用户可能不付款。预占库存需要一个超时释放机制文档建议用延迟消息或者定时任务扫表。提示如果你用的是 RocketMQ延迟消息可以做到 30 分钟精度如果用 RabbitMQ需要装延迟插件。没有消息队列的话用 Redis 的 zset 存预占记录定时任务每分钟扫一次过期 key。3. 技术架构选型Spring Cloud 与 Dubbo 的取舍依据3.1 微服务框架选型的三个硬指标文档在技术架构章节花了很大篇幅对比 Spring Cloud 和 Dubbo。它没有直接说哪个好而是给了三个硬指标服务治理能力、协议性能、团队熟悉度。服务治理包括限流、熔断、降级、链路追踪Spring Cloud Alibaba 这套用 Sentinel 和 Sleuth 基本开箱即用Dubbo 需要自己集成 Sentinel 或者用 Dubbo 自带的治理中心。协议性能上Dubbo 默认走 Dubbo 协议比 HTTP 快但 Spring Cloud 可以用 gRPC 或者 Feign 加连接池来弥补。团队熟悉度这个指标最容易被忽略。文档里写了一句很实在的话“如果团队里没人写过 Dubbo 的泛化调用和异步调用那选 Spring Cloud 至少能保证出问题的时候有人能查。”我自己的经验也是这样Spring Cloud 的文档和社区案例多遇到坑搜一下基本有答案Dubbo 的很多问题需要看源码或者去邮件列表问。文档最终的建议是中小团队用 Spring Cloud Alibaba大团队或者对性能有极致要求的用 Dubbo 3.x。这个建议不算新鲜但它把理由写清楚了不是拍脑袋。3.2 数据存储与缓存的具体配置参数电商系统的数据存储选型文档给了明确的组合MySQL 做交易数据Redis 做缓存和分布式锁Elasticsearch 做商品搜索MongoDB 做日志和用户行为数据。这个组合是行业主流没什么争议。但文档里给了一些具体的参数建议这些才是真正能抄作业的地方。MySQL 方面文档建议订单表按用户 ID 分库分表用 ShardingSphere 做中间件。分片数建议是 2 的幂次比如 16 库 64 表方便后续扩容。每个分片的数据量控制在 500 万行以内。连接池用 HikariCP最大连接数设为 CPU 核数乘以 2 再加磁盘数这个公式来自 PostgreSQL 的推荐MySQL 也适用。Redis 方面文档建议缓存商品详情用 Hash 结构过期时间加随机值防止雪崩。分布式锁用 Redisson不要自己用 SETNX 实现因为锁续期和可重入很容易写错。库存扣减用 Lua 脚本保证原子性脚本大概长这样-- 库存扣减 Lua 脚本 -- KEYS[1]: 库存 key -- ARGV[1]: 扣减数量 -- ARGV[2]: 当前时间戳 local stock redis.call(GET, KEYS[1]) if not stock then return -1 -- 库存不存在 end if tonumber(stock) tonumber(ARGV[1]) then return -2 -- 库存不足 end redis.call(DECRBY, KEYS[1], ARGV[1]) return tonumber(stock) - tonumber(ARGV[1])这段脚本的逻辑是先检查库存是否存在再检查是否足够最后扣减并返回剩余库存。参数说明KEYS[1] 是库存的 Redis key通常用stock:sku:{skuId}格式ARGV[1] 是扣减数量一般传 1ARGV[2] 是时间戳用于后续排查问题时记录操作时间。返回值 -1 表示库存未初始化-2 表示库存不足正数表示扣减后的剩余库存。调用的时候用EVAL或者EVALSHARedisson 的RScript接口可以直接用。Elasticsearch 方面文档建议商品索引按类目和价格区间做分片副本数至少 1。搜索建议用bool查询组合must和filterfilter不走评分性能更好。MongoDB 用来存用户行为日志按天分集合设置 TTL 索引自动过期。注意Redis 的 Lua 脚本里不要用KEYS命令遍历所有 key因为 Redis 是单线程的遍历大量 key 会阻塞其他请求。库存扣减只操作单个 key所以没问题。4. 部署与运维方案容器化与监控告警的落地细节4.1 Docker 与 Kubernetes 的部署清单文档在部署章节给了一套完整的容器化方案。基础镜像是 OpenJDK 17 的 slim 版本应用打包成 fat jar 后复制进去。Dockerfile 大概是这样FROM openjdk:17-jdk-slim WORKDIR /app COPY target/order-service.jar app.jar EXPOSE 8080 ENTRYPOINT [java, -jar, -Xms512m, -Xmx1024m, -Dspring.profiles.activeprod, app.jar]逻辑说明基础镜像用 slim 版本减小体积WORKDIR设置工作目录COPY把构建好的 jar 包复制进去EXPOSE声明端口ENTRYPOINT启动应用并指定 JVM 参数和 Spring profile。参数说明-Xms512m是初始堆大小-Xmx1024m是最大堆大小生产环境建议根据容器内存限制来设一般是容器内存的 50% 到 75%。-Dspring.profiles.activeprod指定生产环境配置。Kubernetes 方面文档建议每个服务至少 2 个副本用 Deployment 管理。资源限制按服务的重要性来分订单服务和支付服务给 2 核 4G商品服务和用户服务给 1 核 2G。健康检查用/actuator/health端点就绪探针和存活探针分开配置。就绪探针的initialDelaySeconds设为 30存活探针设为 60因为 Java 应用启动比较慢。4.2 监控告警的指标与阈值设置文档给了一套基于 Prometheus Grafana 的监控方案。需要采集的指标包括JVM 内存和 GC 次数、HTTP 请求的 QPS 和延迟、数据库连接池活跃数、Redis 命中率、消息队列积压量。告警阈值方面文档建议JVM 老年代使用率超过 80% 持续 5 分钟告警HTTP 接口 P99 延迟超过 500ms 持续 1 分钟告警数据库连接池活跃数超过最大连接数的 80% 告警Redis 命中率低于 90% 告警消息队列积压超过 1000 条告警这些阈值不是绝对的需要根据业务量调整。但文档里有一句话很关键“告警不是越多越好每条告警都必须有对应的处理动作否则就是噪音。”我见过一个团队配了 200 多条告警结果每天收到几百条通知最后所有人都把告警静音了真出问题的时候没人知道。日志收集用 ELK 或者 Loki文档建议用 Loki因为资源占用比 ELK 小。日志格式统一用 JSON方便解析。链路追踪用 SkyWalking 或者 Jaeger文档建议用 SkyWalking因为对 Java 应用无侵入只需要加启动参数。5. 避坑与常见问题从超卖到分布式事务的排查记录5.1 库存超卖的三种典型场景现象大促期间库存扣成负数或者同一个 SKU 卖出超过实际库存。原因通常有三种第一种是缓存和数据库不一致Redis 扣了但数据库没扣第二种是并发扣减时没有加锁两个请求同时读到相同库存然后各自扣减第三种是预占库存没有释放导致可用库存越来越少。解决第一种情况用延迟双删或者 Canal 监听 binlog 来同步缓存第二种情况用 Redis Lua 脚本或者分布式锁第三种情况用延迟消息或者定时任务扫预占记录超过 30 分钟未支付的自动释放。文档里特别强调预占库存和实际扣减要分开记录预占用 Redis实际扣减用数据库对账的时候两边都要查。5.2 分布式事务导致订单状态不一致现象用户支付成功但订单状态还是“待支付”或者订单已取消但支付单还是“已支付”。原因订单服务和支付服务用了不同的数据库跨服务调用没有保证原子性。常见做法是用 Seata 的 AT 模式或者 TCC 模式但 Seata 对业务代码有侵入TCC 需要自己写补偿逻辑。解决文档建议对一致性要求极高的场景用 TCC比如支付和订单。TCC 的三个阶段是 Try、Confirm、CancelTry 阶段预留资源Confirm 阶段确认Cancel 阶段回滚。如果不想引入 Seata可以用本地消息表加定时任务补偿。本地消息表的思路是在订单库建一张消息表订单创建和消息插入在同一个本地事务里然后定时任务扫消息表发送到消息队列支付服务消费消息后更新支付状态。5.3 缓存雪崩和热点 key 问题现象大量缓存同时过期请求全部打到数据库数据库连接池被打满。或者某个热点商品被大量请求Redis 单节点 CPU 跑满。原因缓存过期时间设了固定值没有加随机值热点 key 没有做本地缓存或者多级缓存。解决过期时间加随机值比如基础过期时间 30 分钟随机加 0 到 5 分钟。热点 key 用本地缓存加 Redis 两级缓存本地缓存用 Caffeine过期时间设短一点比如 5 秒。文档里还提到热点 key 可以用 Redis 的CLUSTER KEYSLOT命令查看落在哪个节点如果集中在某个节点可以考虑用 hash tag 打散。5.4 消息队列消息丢失和重复消费现象订单创建后发送消息到队列但库存服务没收到导致库存没扣。或者库存服务收到了两条相同的消息扣了两次库存。原因消息丢失可能是生产者发送失败、队列持久化没开、消费者手动确认没配好重复消费是因为网络抖动导致生产者重发或者消费者处理完没及时确认。解决生产者用同步发送加重试队列开启持久化消费者手动确认。重复消费用幂等性解决比如每条消息带一个唯一 ID消费者处理前先查 Redis 看这个 ID 是否已处理过。文档建议幂等键用业务 ID比如订单号加操作类型不要用消息 ID因为消息 ID 可能变。5.5 数据库连接池配置不当导致请求阻塞现象接口响应时间突然变长日志里出现“等待连接超时”。原因连接池最大连接数设得太小或者连接泄漏没有回收。常见做法是 HikariCP 的maximumPoolSize设为 CPU 核数乘以 2 再加磁盘数但很多人直接设成 100 或者 200结果数据库端连接数爆了。解决先看数据库的max_connections是多少然后算一下所有服务加起来的总连接数不能超过这个值。HikariCP 的connectionTimeout设成 3 秒idleTimeout设成 10 分钟maxLifetime设成 30 分钟比数据库的wait_timeout小一点。如果还是出现等待检查代码里有没有手动获取连接没关闭的地方用try-with-resources或者Transactional让框架管理。6. 方案验证与迭代用压测和混沌工程检验架构韧性方案写完不是终点能不能扛住真实流量才是。文档最后一章给了验证方法我把它拆成两个可执行的步骤压测和混沌工程。压测用 JMeter 或者 wrk重点压三个接口商品详情、下单、支付。商品详情看缓存命中率和 Redis 延迟下单看库存扣减的原子性和数据库写入速度支付看分布式事务的成功率。压测参数从低到高逐步加先压 100 QPS 跑 10 分钟观察错误率和延迟没问题再加到 500 QPS再到 1000 QPS。文档建议在压测环境模拟真实数据量比如商品表至少 100 万行订单表至少 1000 万行否则压测结果没有参考价值。混沌工程用 ChaosBlade 或者 Litmus模拟三种故障Redis 节点宕机、MySQL 主库延迟、消息队列积压。Redis 宕机看本地缓存能不能顶住MySQL 延迟看读写分离和降级策略是否生效消息队列积压看消费者扩容能不能及时跟上。文档里有一句话我印象很深“不要等到大促当天才发现降级开关没配好。”我自己的习惯是每次大版本上线前强制走一遍混沌演练至少模拟一次 Redis 不可用和一次数据库主从切换。验证通过之后方案要迭代。迭代的依据是监控数据和故障复盘。文档建议每季度做一次架构复盘重点看三个指标可用性、延迟、成本。可用性低于 99.95% 就要找原因延迟 P99 超过 500ms 就要优化成本超过预算就要考虑降配或者换方案。我一般会在复盘会上让每个人写一条“最后悔的决策”比如“当初不该把库存和订单拆成两个服务”这些后悔药比成功经验更有价值。从那以后我每次写建设方案都会在最后一页加一个“验证清单”把压测场景、混沌演练、回滚步骤列清楚不写完不准上线。希望这份拆解能帮到你少走一些我走过的弯路。本文还有配套的精品资源点击获取