一、电商项目概述：从行业背景到架构设计

大家好，我是这门课的主讲。今天咱们聊聊电商项目工程化的第一课——电商行业背景、技术栈选型，还有整体架构设计。

说实话，电商这个领域我做了快十年。从早期的单机架构，到后来的微服务，再到现在的云原生，我踩过的坑真不少。嗯，今天就把这些经验掰开揉碎了讲给你听。

1.1 电商行业背景：为什么选电商做实战项目？

你想想看，电商系统几乎涵盖了后端开发的所有核心场景：

• 高并发：双十一、618，瞬间流量能冲到几十万QPS
• 复杂业务：商品、订单、支付、库存、物流，环环相扣
• 数据一致性：扣库存和支付，少一步都不行
• 分布式事务：跨服务、跨数据库，怎么保证最终一致？
• 海量数据：用户、订单、商品，动辄上亿条记录

我在项目中遇到过不少同学，简历上写着「熟悉高并发」，但一问细节就露馅。说白了，没真正做过电商项目，很难理解这些场景有多棘手。

1.2 项目技术栈选型：我为什么选这些？

技术栈选型这事儿，我个人的习惯是「够用就好，别炫技」。下面这张表是我为这个课程选的技术栈：

层级	技术选型	选型理由
后端框架	Spring Boot 3.x + Spring Cloud Alibaba	生态成熟，社区活跃，国内电商首选
服务注册与配置	Nacos	阿里出品，支持服务发现和配置管理二合一
网关	Spring Cloud Gateway	响应式网关，性能比Zuul好很多
数据库	MySQL 8.0 + ShardingSphere	分库分表实战，电商订单表必备
缓存	Redis Cluster	热点商品、Session共享，离不开它
消息队列	RocketMQ	高吞吐、低延迟，电商异步场景首选
搜索引擎	Elasticsearch	商品搜索、日志分析，一把好手
分布式事务	Seata	AT模式，对业务代码侵入小
容器化	Docker + K8s	微服务部署标配，弹性伸缩必备

1.3 项目整体架构设计：分层与模块

电商系统的架构，说白了就是「分而治之」。我习惯把系统拆成这几层：

嗯，这张图我画了好几次才满意。你看，从上到下分五层：

1. 客户端层：用户直接接触的界面，Web、App、小程序都有
2. API网关层：统一入口，做鉴权、限流、路由转发。我建议网关层只做通用逻辑，别掺和业务
3. 业务服务层：核心业务拆成独立微服务。每个服务自治，独立部署
4. 中间件层：缓存、消息、搜索、分布式事务，这些是微服务的「基础设施」
5. 数据层：MySQL存核心数据，ES做搜索，Redis做缓存

1.4 模块划分：每个模块做什么？

咱们这个电商项目，我规划了以下核心模块：

模块名称	核心功能	涉及技术点
用户模块	注册、登录、权限管理、地址管理	JWT鉴权、OAuth2.0、RBAC
商品模块	SPU/SKU管理、分类、属性、上下架	ES索引同步、缓存策略
订单模块	下单、订单状态机、超时取消	分布式事务、状态机模式
库存模块	库存扣减、预占、回滚	Redis原子操作、乐观锁
支付模块	支付对接、退款、对账	支付宝/SDK、回调处理
购物车模块	添加、删除、合并购物车	Redis存储、合并策略
搜索模块	商品搜索、筛选、排序	ES查询DSL、分词器

每个模块我都会带着你从零开始搭建。你想想看，把这些模块全部跑通，你的后端能力能上一个台阶。

1.5 避坑指南：我踩过的那些坑

最后，分享几个我亲身经历的教训：

• 数据库设计别太早分库分表：我见过一个项目，刚上线就分了16个库，结果业务逻辑复杂到没法维护。先单库，等真的扛不住了再分。
• 缓存别滥用：Redis不是万能的。我有个同事把所有查询都缓存了，结果数据不一致问题频发。缓存只适合读多写少的场景。
• 消息队列别当数据库用：RocketMQ的消息有有效期，过期就丢了。我曾经因为消息积压太久，导致订单状态丢失，最后只能手动补数据。
• 分布式事务能不用就不用：Seata虽然好用，但性能损耗不小。能用最终一致性解决的，就别强求强一致性。

好了，第一章就到这里。下一章咱们开始动手搭建开发环境，把Spring Boot项目跑起来。到时候见！