1. 摘要本文旨在提供一套基于Java生态的现代电商系统架构设计方案。电商系统具有高并发、复杂业务逻辑、分布式事务、海量数据处理等特点。我们将从业务架构分析入手逐步深入到技术选型、微服务划分、核心模块设计商品、订单、库存、促销、高并发策略以及最终的数据一致性保障。2. 业务架构分析在设计技术架构前必须理清电商的核心业务流程用户端注册登录、商品浏览搜索/筛选、购物车、下单支付、订单跟踪、评价。运营端商品管理上架/下架、类目管理、库存管理、促销活动秒杀/优惠券、订单处理发货/退款。基础支撑用户账户体系、支付网关对接、物流跟踪、消息通知。核心难题秒杀场景瞬间流量激增读多写少库存扣减准确。库存扣减防止超卖。订单一致性支付成功必须落单支付超时必须回滚库存。复杂查询多条件商品搜索、订单列表分页。3. 总体技术架构图 (分层视图)4. 微服务拆分策略 (基于Spring Cloud Alibaba)服务名称核心职责数据库隔离关键依赖用户中心注册、登录、权限、会员等级db_userJWT, OAuth2商品中心商品SPU/SKU、类目、属性db_productCanal (同步至ES)库存中心库存扣减、库存归还、锁定db_stockRedis Redisson, RocketMQ订单中心订单创建、状态流转、取消db_orderSeata (AT/TCC)促销中心优惠券、秒杀、满减db_promoQuartz (定时)支付中心支付回调、退款、对账db_pay支付宝/微信SDK购物车临时购物车、算价db_cart(可MongoDB)Redis5. 核心模块详细设计5.1 商品与搜索 (CQRS模式命令查询职责分离)写入运营后台新增商品 - 写入MySQL (product表)。读取高并发读、多条件筛选。方案采用Canal监听MySQL binlog异步同步到Elasticsearch。为什么MySQL不擅长大量组合条件的全文检索ES天然支持倒排索引和聚合。5.2 购物车与订单购物车存储在Redis中Hash结构Key为cart:${userId}。可设置过期时间如30天。下单流程重中之重提交订单前端传入SKU_ID和数量。验价调用促销服务计算最终金额。锁库存调用库存服务的tryLockStock接口预扣。创建订单状态为待支付写入订单库。释放购物车清除Redis中的对应商品。返回支付链接。5.3 库存扣减的终极方案 (防超卖)不可采用查库存 - if(库存够) - update库存。这是经典的并发问题。高性能方案Redis Lua脚本 异步同步库存预热秒杀开始前将库存加载到Redis。扣减逻辑 (Lua原子性)lualocal key KEYS[1] local num tonumber(ARGV[1]) local stock tonumber(redis.call(get, key)) if stock num then redis.call(decrby, key, num) return 1 -- 扣减成功 else return 0 -- 库存不足 end消息队列扣减成功后发送StockDeductedEvent消息。最终一致性消费者监听消息异步更新MySQL中的库存最终一致。兜底方案若Redis扣减成功但MySQL更新失败极少必须在落单时进行库存预扣见订单流程或利用定时任务对账。5.4 订单超时关闭 (延时消息)场景用户下单15分钟未支付需自动取消订单并归还库存。实现使用RocketMQ的延时消息或RabbitMQ的TTL死信队列。创建订单时发送延时消息DelayTimeLevel 15分钟。消费者15分钟后消费查询订单状态是否为待支付。若是更新为已取消调用库存服务unlockStock。6. 一致性保证 (分布式事务)在下单扣库存、退款改状态等跨服务场景无法避免分布式事务。策略选择场景方案理由下单 锁库存Seata AT模式(自动补偿)强一致性要求高吞吐量适中实现简单加注解。支付回调 增加积分 发短信RocketMQ 事务消息不需要强一致最终一致即可解耦且高吞吐。退款 回滚库存Seata TCC模式需要人工介入Try-Confirm-Cancel。推荐核心交易链路下单使用Seata AT非核心、异步链路通知使用MQ。7. 高并发与性能优化清单静态化商品详情页、活动页提前生成静态HTML推送至CDN。多级缓存Caffeine (本地缓存) - 热点商品SKU信息。Redis (分布式缓存) - 用户Session、库存、购物车。数据库优化订单表按user_id分库分表 (ShardingSphere-JDBC)。避免JOIN在服务层做聚合。索引优化订单查询最常使用user_id create_time。限流熔断网关层令牌桶算法限流例如每用户每秒10次请求。服务层Sentinel配置降级规则慢调用比例 0.5 自动熔断。秒杀特技独立秒杀接口与普通商品下单接口分离。前端答题/验证码防刷。InventoyService采用纯内存操作Redis下单成功后再MQ慢慢创建订单详情。8. 安全设计防重放每个请求携带timestampnoncesign服务端校验时间戳差值和签名。防越权所有敏感操作查询订单、修改收货地址必须校验userId与当前会话Token中的ID一致。SQL注入/XSSMyBatis使用#{}输出时对脚本进行转义。资金安全支付回调验签必须使用异步通知并校验订单金额与回调金额完全一致。9. 部署与运维架构容器化Docker 打包Kubernetes (K8s) 编排。环境隔离开发(dev)、测试(test)、预发(pre)、生产(prod)。预发环境与生产配置一致但不接入真实流量。全链路压测提前模拟双11流量观察各服务水位找出瓶颈往往是数据库连接池或IO。监控告警Prometheus Grafana (系统/JVM指标)。SkyWalking (Trace ID 追踪定位跨服务慢调用)。10. 总结与演进建议起步阶段如果是中小型电商不要直接上30个微服务。建议从Spring Boot单体 MySQL Redis开始当业务复杂度团队人数20人QPS1000迫使解耦时再按业务边界拆分为微服务。核心原则宁可先保证一致性再优化性能少卖比超卖好处理。最终一致性优于强一致性在大流量下允许积分迟几秒到账。监控优先于功能没有完善的监控分布式系统就是黑盒。通过以上架构设计Java电商系统能够应对日均百万级订单、秒级万级并发取决于服务器配置并具备水平扩展能力加机器即可提升TPS。