简介本资源是一套基于Spring Boot的电商后端系统源码面向Java初学者与中小型电商项目开发者聚焦后端接口开发实践覆盖购物车、客服、用户地址、商品评论等核心业务模块助力快速搭建可运行的商城服务骨架。压缩包共772个文件含121个Java后端逻辑类Controller/Service/Mapper、153个JS前端交互脚本、46个Vue组件、44个CSS样式文件及1个SQL建表脚本辅以bat批处理启动脚本与多个.bak备份文件整体14.62MB结构完整、模块解耦清晰便于理解分层架构与MyBatis Plus实战用法。已有87人学习下载读者可直接导入IDE运行获取全套RESTful接口定义、分页与条件查询实现、默认地址/购物车提醒等通用功能代码以及典型电商后端的目录组织范式与配置规范。1. 项目背景与核心价值为什么选择Spring Boot重构电商后端在电商行业摸爬滚打了十几年我经手过从单体应用到微服务再到如今云原生的各种架构。每次技术选型尤其是后端框架都直接关系到项目的生死存亡。最近我把自己过去几年为一个中型垂直电商平台重构后端系统的核心经验整理成了一个完整的、可运行的Spring Boot项目源码。这个项目不是一个简单的“Hello World”级Demo而是一个涵盖了商品、订单、用户、支付等核心模块并融入了大量生产级考量的实战工程。你可能会问市面上Spring Boot的教程和开源项目不是一抓一大把吗我这个有什么不同最大的区别在于“取舍”和“细节”。很多教程为了追求“全”把各种时髦的技术栈都堆砌上去却忽略了在真实业务压力下哪些是核心必须的哪些是“过度设计”。我这个项目就是从一个真实、稳定运行了数年的系统中剥离出最核心、最通用的部分并针对Spring Boot 2.x的特性进行了现代化重构。它不追求技术的“炫”而是追求架构的“稳”和代码的“洁”。对于想从零搭建一个可靠电商后端或者想深入理解Spring Boot在复杂业务场景下最佳实践的开发者来说这份源码和背后的设计思路或许能帮你避开很多我当年踩过的坑。2. 技术栈选型深度解析不止于Spring Boot一个健壮的电商后端Spring Boot只是起点是那个优秀的“胶水”和“脚手架”。围绕它我们需要构建一整套技术生态。我的选型原则很明确社区活跃、生态成熟、学习曲线平缓、与Spring Boot集成无缝。下面这张表清晰地展示了核心技术栈及其承担的职责技术组件选用版本在项目中的核心职责选型理由与替代方案对比Spring Boot2.7.x (LTS版本)项目基石提供自动配置、依赖管理、嵌入式容器等。理由约定大于配置极大提升开发效率拥有最庞大的Java生态。对比相比传统的Spring MVC XML配置Boot的自动化是质的飞跃相比更新的Quarkus/MicronautBoot的生态和人才储备仍是绝对优势。Spring Data JPA随Boot版本数据持久层ORM框架处理与MySQL的交互。理由基于JPA标准方法名解析查询非常便捷与Hibernate集成好。注意点复杂查询仍需配合Query注解或QueryDSL。对于超高并发场景可考虑MyBatis-Plus以获得更灵活的SQL控制。MySQL8.0核心业务数据存储用户、商品、订单。理由关系型数据库的绝对主流事务支持完善生态工具多。关键配置使用了utf8mb4字符集支持完整表情符表引擎统一为InnoDB。Redis6.x缓存商品详情、用户会话、分布式锁、秒杀库存计数。理由性能极高数据结构丰富。生产经验一定要做缓存穿透缓存空值和雪崩随机过期时间的防护。Spring Security JWT随Boot版本用户认证与授权。理由Spring嫡系功能强大且可定制性高。JWT用于构建无状态令牌适合分布式部署。避坑JWT的令牌刷新机制和注销黑名单需要自行实现。RabbitMQ3.9异步解耦处理订单创建后的后续流程如发短信、更新统计。理由AMQP协议实现消息可靠性强。对比Kafka更适合日志、流处理RabbitMQ在业务消息队列领域更成熟。Elasticsearch7.x商品搜索服务。理由全文检索的标杆。集成方式并未使用Spring Data Elasticsearch的Repository模式而是直接使用RestHighLevelClient以获得更灵活的控制权。Docker Docker Compose-本地开发环境一键部署。理由保证环境一致性新人上手只需一条命令。注意这里没有引入过多的“时髦”组件例如服务网格Istio、链路追踪SkyWalking等。我的考虑是对于一个初始的或中型的电商项目首要目标是快速、稳定地实现核心业务闭环。这些高级的观测和治理工具可以在业务量增长、服务拆分后再逐步引入。避免“为了技术而技术”是架构设计的第一课。2.1 为什么坚持使用Spring Boot 2.7.x而不是3.x这是一个很实际的问题。Spring Boot 3.x基于Spring Framework 6和Java 17带来了诸如GraalVM原生镜像等前瞻特性。但我仍然选择2.7.x这个长期支持版本原因有三生态稳定性绝大多数主流中间件MyBatis, ShardingSphere等对Spring Boot 2.x的支持度最高、最稳定。冒然升级3.x可能会在集成某些组件时遇到兼容性问题消耗不必要的排查时间。Java版本要求Boot 3.x要求最低Java 17而国内很多企业生产环境可能仍停留在Java 8或11。使用2.7.x可以保持对Java 8的兼容团队技术升级压力更小。学习资源2.x的教程、问题解决方案Stack Overflow数量远多于3.x对于团队学习和问题排查更友好。项目的pom.xml中我明确定义了Spring Boot的父工程版本并统一管理了所有子模块的依赖版本这是管理多模块项目的基石。3. 项目架构设计清晰的分层与模块化我采用了经典的多模块Maven项目结构这不仅仅是物理上的代码分离更是职责的清晰划分。整个项目结构如下mall-backend (父工程聚合模块) ├── mall-common -- 通用工具模块 │ ├── constant -- 全局常量定义 │ ├── util -- 工具类日期、加密、字符串处理等 │ └── exception -- 自定义异常体系 ├── mall-domain -- 领域模型模块可选DDD思想 │ ├── entity -- 核心领域实体与数据库表对应但不止于表字段 │ └── vo -- 值对象 ├── mall-repository -- 数据持久层模块 │ └── repository -- JPA Repository接口 ├── mall-service -- 业务逻辑层模块 │ ├── api -- 服务接口定义 │ └── impl -- 服务接口实现 ├── mall-web -- Web控制层模块 │ ├── controller -- RESTful API控制器 │ ├── dto -- 数据传输对象API入参/出参 │ ├── converter -- 实体与DTO转换器 │ └── config -- Web层配置拦截器、参数解析器等 ├── mall-security -- 安全认证模块可独立 └── mall-job -- 定时任务模块处理对账、数据归档等这样设计的好处是什么高内聚低耦合service模块不依赖webrepository不依赖service。你可以轻松替换Web框架比如换成Spring WebFlux或者持久层框架而不会牵一发而动全身。编译隔离修改web模块的代码不会触发service或repository模块的重新编译加快本地构建速度。部署灵活初期可以打包成一个单体应用mall-web依赖所有其他模块。后期业务膨胀可以轻松将service模块拆分成独立的Jar包通过RPC调用为微服务化做准备。关于领域模型mall-domain的特别说明我引入了这个模块是尝试融入一些领域驱动设计的思想。这里的Entity不仅仅是JPA的Entity注解类它更强调“贫血模型”的丰富化可能会包含一些具有业务含义的方法。而VO则用于承载复杂的查询结果或特定视图的数据。这只是一个开始旨在引导大家思考业务逻辑的归属避免所有逻辑都堆砌在Service中。4. 核心业务模块实现精讲4.1 用户认证与安全Spring Security JWT安全无小事。我采用Spring SecurityJWT的方案实现了基于令牌的无状态认证。核心流程用户登录调用/auth/login接口提交用户名密码。服务端验证UserDetailsService加载用户信息PasswordEncoder验证密码。生成令牌验证通过后使用JJWT库生成一个包含用户ID、角色等信息的JWT。返回令牌将JWT放在HTTP响应头的Authorization: Bearer中返回给客户端。后续请求客户端在请求头中携带此令牌。令牌校验自定义的JwtAuthenticationFilter会拦截请求解析并验证JWT将认证信息设置到SecurityContextHolder中。权限控制在Controller方法上使用PreAuthorize(“hasRole(‘ADMIN’)”)等注解进行细粒度权限控制。关键代码与避坑点// 在 WebSecurityConfig 中配置 Configuration EnableGlobalMethodSecurity(prePostEnabled true) // 启用方法级安全注解 public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() // 对于REST API通常禁用CSRF .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) // 无状态会话 .and() .authorizeRequests() .antMatchers(“/auth/login”, “/products/public/**”).permitAll() // 公开接口 .anyRequest().authenticated() // 其他所有接口都需要认证 .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); // 添加JWT过滤器 } Bean public JwtAuthenticationFilter jwtAuthenticationFilter() { return new JwtAuthenticationFilter(); } } // 自定义的JWT过滤器 public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String authHeader request.getHeader(“Authorization”); if (authHeader ! null authHeader.startsWith(“Bearer “)) { String token authHeader.substring(7); try { // 解析JWT获取用户信息 String username jwtUtil.extractUsername(token); if (username ! null SecurityContextHolder.getContext().getAuthentication() null) { UserDetails userDetails userDetailsService.loadUserByUsername(username); if (jwtUtil.validateToken(token, userDetails)) { // 构建Authentication对象并存入SecurityContext UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } } } catch (Exception e) { // 令牌无效记录日志但继续过滤器链后续会被权限校验拦截 logger.error(“JWT token validation failed”, e); } } chain.doFilter(request, response); } }避坑经验JWT的密钥管理密钥(Secret)绝对不能硬编码在代码中。我将其放在application.yml中并通过环境变量注入。生产环境应使用KMS或Vault等密钥管理服务。令牌过期与刷新JWT一旦签发在过期前无法废止。我设计了双令牌机制access_token短有效期如30分钟和refresh_token长有效期如7天。客户端用过期的access_token配合有效的refresh_token来获取新的access_token。refresh_token可以存入Redis并设置过期时间方便实现“注销即失效”。权限注解的粒度PreAuthorize非常强大但不要滥用。建议在Service层的方法上也进行权限校验形成纵深防御。4.2 商品系统的设计与缓存策略商品模块是电商的核心读多写少对性能要求极高。数据库设计要点product表存储商品基本属性名称、价格、主图等。product_sku表库存量单位表存储具体规格如颜色、尺寸对应的价格、库存。这是实现多规格商品的关键。product_category表类目树使用parent_id实现无限级分类并通过path字段如,1,3,来优化查询效率。缓存策略Redis商品详情缓存Key设计为product:detail:{productId}Value为商品信息的JSON字符串。设置一个合理的TTL如1小时并采用“延时双删”策略保证数据库与缓存的一致性。更新时先删除缓存 - 再更新数据库 - 休眠一小段时间如500ms- 再次删除缓存。第二次删除是为了清除在“更新数据库”这个间隙内可能被其他请求写入的旧缓存。商品列表缓存由于列表查询条件多变分页、排序、筛选直接缓存整个结果集不现实。我采用的方式是缓存“筛选条件对应的商品ID集合”。例如查询“手机类目下价格在2000-3000元的所有商品ID”将这个ID集合缓存起来。获取列表时先从缓存取ID集合再进行分页最后根据ID去查询商品详情详情本身有缓存。这大大减少了数据库的复杂查询压力。库存缓存秒杀场景下库存校验是性能瓶颈。我将热门SKU的库存数量预加载到Redis中Key如stock:sku:{skuId}下单时先对Redis库存进行decr原子操作。如果结果0则预扣成功再异步去数据库进行最终扣减。如果Redis库存不足则直接返回售罄避免穿透到数据库。4.3 订单系统的状态机与幂等性订单系统是电商最复杂的模块之一核心在于状态流转和防止重复请求。订单状态机 我使用枚举Enum来定义订单状态并内嵌状态流转逻辑。这比在代码中写一堆if-else清晰得多。public enum OrderStatus { PENDING_PAYMENT(1, “待支付”) { Override public boolean canTransitionTo(OrderStatus nextStatus) { return nextStatus PAID || nextStatus CANCELLED; } }, PAID(2, “已支付”) { Override public boolean canTransitionTo(OrderStatus nextStatus) { return nextStatus SHIPPED || nextStatus REFUNDING; } }, // ... 其他状态 SHIPPED, COMPLETED, CANCELLED, REFUNDED等 private final int code; private final String desc; // 抽象方法每个状态实现自己的流转规则 public abstract boolean canTransitionTo(OrderStatus nextStatus); } // 在Service中调用 public void changeOrderStatus(Long orderId, OrderStatus newStatus) { Order order orderRepository.findById(orderId).orElseThrow(...); if (!order.getStatus().canTransitionTo(newStatus)) { throw new BusinessException(“订单状态流转非法”); } order.setStatus(newStatus); orderRepository.save(order); // 触发状态变更事件用于通知、日志记录等 applicationEventPublisher.publishEvent(new OrderStatusChangedEvent(this, orderId, newStatus)); }幂等性设计 网络抖动可能导致客户端重复提交“创建订单”或“支付回调”请求。我采用“幂等令牌”机制。客户端在创建订单前先请求后端获取一个唯一的幂等令牌UUID该令牌与当前用户会话关联并存入Redis设置较短有效期如5分钟。客户端提交订单时必须携带此令牌。服务端收到请求先检查Redis中是否存在该令牌存在则删除令牌并继续处理业务不存在则认为是重复请求直接返回之前已创建成功的订单结果。对于支付回调这种外部系统调用的接口除了幂等令牌还需要结合数据库唯一索引如order_nopay_channel来确保同一笔支付只处理一次。4.4 异步化与消息队列RabbitMQ的应用电商系统中很多操作不需要实时完成或者需要保证最终一致性。例如用户下单成功后需要扣减库存已在前端和缓存校验这里是最终扣减。发送订单创建成功短信/站内信。更新用户的购物车。触发可能的营销活动结算。如果所有这些操作都在下单接口的主线程中同步执行接口响应会非常慢且任何一个步骤失败都会导致整个下单失败。我的做法是核心操作同步周边操作异步。同步操作生成订单、扣减真实库存数据库、生成支付流水。这些是交易的核心必须强一致。异步操作将“发送通知”、“更新购物车”等任务封装成消息发送到RabbitMQ。消息处理独立的消费者服务监听队列处理这些任务。即使消费者暂时挂掉消息也会在队列中持久化等待恢复后处理。// 在OrderService中 Transactional public OrderDTO createOrder(OrderCreateRequest request) { // 1. 校验参数、库存等 // 2. 生成订单号、保存订单主信息同步 Order order buildOrder(request); orderRepository.save(order); // 3. 扣减数据库库存同步 reduceStock(order); // 4. 发送异步消息 rabbitTemplate.convertAndSend(“order.exchange”, “order.created”, order.getId()); // 5. 返回订单DTO return convertToDTO(order); } // 监听订单创建消息的消费者 Component RabbitListener(queues “order.created.queue”) public class OrderCreatedMessageConsumer { Autowired private NotificationService notificationService; Autowired private CartService cartService; RabbitHandler public void handleMessage(Long orderId) { // 根据orderId查询订单信息注意这里可能读到未提交的事务数据需要根据业务容忍延迟或做特殊处理 // 发送通知 notificationService.sendOrderCreatedMsg(orderId); // 清理购物车对应商品 cartService.clearItemsAfterOrder(orderId); // ... 其他异步任务 } }经验之谈使用消息队列时一定要考虑消息的可靠性。我配置了生产者确认Publisher Confirm和消费者手动确认Manual Ack确保消息不丢失。同时为重要队列设置了死信交换机DLX将处理失败的消息转移到死信队列方便人工介入排查。5. 生产环境部署与监控考量源码跑起来只是第一步如何让它稳定地运行在生产环境才是真正的挑战。1. 配置文件分离 使用Spring Boot的application-{profile}.yml多环境配置。application.yml定义公共配置application-dev.yml、application-prod.yml分别定义开发和生产环境的数据库地址、Redis地址、日志级别等。通过启动参数--spring.profiles.activeprod来激活。2. 健康检查与监控 Spring Boot Actuator是必备的。我暴露了/actuator/health健康检查、/actuator/metrics指标和/actuator/prometheus供Prometheus拉取数据端点。在Kubernetes中/actuator/health的liveness和readiness探针是服务自愈和流量管理的关键。3. 日志规范化 使用Logback或Log4j2并集成logstash-logback-encoder将日志输出为JSON格式。这样可以直接被ELKElasticsearch, Logstash, Kibana或类似日志平台收集、检索和分析。在日志中统一加入traceId通过MDC或Sleuth实现可以在分布式系统中追踪一个请求的完整链路。4. 数据库连接池与慢SQL 默认的HikariCP性能很好但需要根据实际压力调整maximum-pool-size、connection-timeout等参数。同时开启Druid的监控功能如果使用Druid或利用p6spy这样的组件打印SQL执行时间及时发现并优化慢查询。5. 关于JVM和SQL执行超时 你提到的“JVM或者Spring Boot会设置一个sql执行10秒自动关闭吗”这是一个很好的问题。Spring Boot或JVM本身不会自动关闭长时间运行的SQL。SQL执行超时通常由以下层面控制数据库层面MySQL有wait_timeout、interactive_timeout参数控制连接空闲超时但不会主动杀死正在执行的查询。对于执行时间过长的查询需要DBA手动KILL。连接池层面HikariCP有connection-timeout获取连接超时和max-lifetime连接最大存活时间但不控制单次SQL执行时间。应用层面这是主要控制点。可以在MyBatis的Mapper方法上使用Options(timeout 10)设置秒级超时。或者在JDBC层面通过DataSource配置spring.datasource.hikari.connection-init-sqlSET SESSION MAX_EXECUTION_TIME10000MySQL 5.7.8来设置会话级别的最大执行时间。更常见的做法是在业务代码中将数据库查询操作提交到独立的线程池执行并使用Future.get(timeout, TimeUnit)来设置超时超时后可以尝试取消或进行降级处理。这个项目源码是我多年电商后端开发经验的凝结。它展示的不仅仅是Spring Boot各个组件的用法更是一个完整的、有生产意识的系统架构思路。从模块划分、技术选型到缓存设计、异步解耦再到安全、监控每一个环节都经过了实际业务的考验。希望这份源码和这些文字能为你构建自己的系统提供一份可靠的蓝图和避坑指南。真正的学习始于将代码运行起来然后尝试去修改它、打破它、再修复它。祝你编码愉快。本文还有配套的精品资源点击获取
Spring Boot电商后端实战：从架构设计到生产部署的完整指南
简介本资源是一套基于Spring Boot的电商后端系统源码面向Java初学者与中小型电商项目开发者聚焦后端接口开发实践覆盖购物车、客服、用户地址、商品评论等核心业务模块助力快速搭建可运行的商城服务骨架。压缩包共772个文件含121个Java后端逻辑类Controller/Service/Mapper、153个JS前端交互脚本、46个Vue组件、44个CSS样式文件及1个SQL建表脚本辅以bat批处理启动脚本与多个.bak备份文件整体14.62MB结构完整、模块解耦清晰便于理解分层架构与MyBatis Plus实战用法。已有87人学习下载读者可直接导入IDE运行获取全套RESTful接口定义、分页与条件查询实现、默认地址/购物车提醒等通用功能代码以及典型电商后端的目录组织范式与配置规范。1. 项目背景与核心价值为什么选择Spring Boot重构电商后端在电商行业摸爬滚打了十几年我经手过从单体应用到微服务再到如今云原生的各种架构。每次技术选型尤其是后端框架都直接关系到项目的生死存亡。最近我把自己过去几年为一个中型垂直电商平台重构后端系统的核心经验整理成了一个完整的、可运行的Spring Boot项目源码。这个项目不是一个简单的“Hello World”级Demo而是一个涵盖了商品、订单、用户、支付等核心模块并融入了大量生产级考量的实战工程。你可能会问市面上Spring Boot的教程和开源项目不是一抓一大把吗我这个有什么不同最大的区别在于“取舍”和“细节”。很多教程为了追求“全”把各种时髦的技术栈都堆砌上去却忽略了在真实业务压力下哪些是核心必须的哪些是“过度设计”。我这个项目就是从一个真实、稳定运行了数年的系统中剥离出最核心、最通用的部分并针对Spring Boot 2.x的特性进行了现代化重构。它不追求技术的“炫”而是追求架构的“稳”和代码的“洁”。对于想从零搭建一个可靠电商后端或者想深入理解Spring Boot在复杂业务场景下最佳实践的开发者来说这份源码和背后的设计思路或许能帮你避开很多我当年踩过的坑。2. 技术栈选型深度解析不止于Spring Boot一个健壮的电商后端Spring Boot只是起点是那个优秀的“胶水”和“脚手架”。围绕它我们需要构建一整套技术生态。我的选型原则很明确社区活跃、生态成熟、学习曲线平缓、与Spring Boot集成无缝。下面这张表清晰地展示了核心技术栈及其承担的职责技术组件选用版本在项目中的核心职责选型理由与替代方案对比Spring Boot2.7.x (LTS版本)项目基石提供自动配置、依赖管理、嵌入式容器等。理由约定大于配置极大提升开发效率拥有最庞大的Java生态。对比相比传统的Spring MVC XML配置Boot的自动化是质的飞跃相比更新的Quarkus/MicronautBoot的生态和人才储备仍是绝对优势。Spring Data JPA随Boot版本数据持久层ORM框架处理与MySQL的交互。理由基于JPA标准方法名解析查询非常便捷与Hibernate集成好。注意点复杂查询仍需配合Query注解或QueryDSL。对于超高并发场景可考虑MyBatis-Plus以获得更灵活的SQL控制。MySQL8.0核心业务数据存储用户、商品、订单。理由关系型数据库的绝对主流事务支持完善生态工具多。关键配置使用了utf8mb4字符集支持完整表情符表引擎统一为InnoDB。Redis6.x缓存商品详情、用户会话、分布式锁、秒杀库存计数。理由性能极高数据结构丰富。生产经验一定要做缓存穿透缓存空值和雪崩随机过期时间的防护。Spring Security JWT随Boot版本用户认证与授权。理由Spring嫡系功能强大且可定制性高。JWT用于构建无状态令牌适合分布式部署。避坑JWT的令牌刷新机制和注销黑名单需要自行实现。RabbitMQ3.9异步解耦处理订单创建后的后续流程如发短信、更新统计。理由AMQP协议实现消息可靠性强。对比Kafka更适合日志、流处理RabbitMQ在业务消息队列领域更成熟。Elasticsearch7.x商品搜索服务。理由全文检索的标杆。集成方式并未使用Spring Data Elasticsearch的Repository模式而是直接使用RestHighLevelClient以获得更灵活的控制权。Docker Docker Compose-本地开发环境一键部署。理由保证环境一致性新人上手只需一条命令。注意这里没有引入过多的“时髦”组件例如服务网格Istio、链路追踪SkyWalking等。我的考虑是对于一个初始的或中型的电商项目首要目标是快速、稳定地实现核心业务闭环。这些高级的观测和治理工具可以在业务量增长、服务拆分后再逐步引入。避免“为了技术而技术”是架构设计的第一课。2.1 为什么坚持使用Spring Boot 2.7.x而不是3.x这是一个很实际的问题。Spring Boot 3.x基于Spring Framework 6和Java 17带来了诸如GraalVM原生镜像等前瞻特性。但我仍然选择2.7.x这个长期支持版本原因有三生态稳定性绝大多数主流中间件MyBatis, ShardingSphere等对Spring Boot 2.x的支持度最高、最稳定。冒然升级3.x可能会在集成某些组件时遇到兼容性问题消耗不必要的排查时间。Java版本要求Boot 3.x要求最低Java 17而国内很多企业生产环境可能仍停留在Java 8或11。使用2.7.x可以保持对Java 8的兼容团队技术升级压力更小。学习资源2.x的教程、问题解决方案Stack Overflow数量远多于3.x对于团队学习和问题排查更友好。项目的pom.xml中我明确定义了Spring Boot的父工程版本并统一管理了所有子模块的依赖版本这是管理多模块项目的基石。3. 项目架构设计清晰的分层与模块化我采用了经典的多模块Maven项目结构这不仅仅是物理上的代码分离更是职责的清晰划分。整个项目结构如下mall-backend (父工程聚合模块) ├── mall-common -- 通用工具模块 │ ├── constant -- 全局常量定义 │ ├── util -- 工具类日期、加密、字符串处理等 │ └── exception -- 自定义异常体系 ├── mall-domain -- 领域模型模块可选DDD思想 │ ├── entity -- 核心领域实体与数据库表对应但不止于表字段 │ └── vo -- 值对象 ├── mall-repository -- 数据持久层模块 │ └── repository -- JPA Repository接口 ├── mall-service -- 业务逻辑层模块 │ ├── api -- 服务接口定义 │ └── impl -- 服务接口实现 ├── mall-web -- Web控制层模块 │ ├── controller -- RESTful API控制器 │ ├── dto -- 数据传输对象API入参/出参 │ ├── converter -- 实体与DTO转换器 │ └── config -- Web层配置拦截器、参数解析器等 ├── mall-security -- 安全认证模块可独立 └── mall-job -- 定时任务模块处理对账、数据归档等这样设计的好处是什么高内聚低耦合service模块不依赖webrepository不依赖service。你可以轻松替换Web框架比如换成Spring WebFlux或者持久层框架而不会牵一发而动全身。编译隔离修改web模块的代码不会触发service或repository模块的重新编译加快本地构建速度。部署灵活初期可以打包成一个单体应用mall-web依赖所有其他模块。后期业务膨胀可以轻松将service模块拆分成独立的Jar包通过RPC调用为微服务化做准备。关于领域模型mall-domain的特别说明我引入了这个模块是尝试融入一些领域驱动设计的思想。这里的Entity不仅仅是JPA的Entity注解类它更强调“贫血模型”的丰富化可能会包含一些具有业务含义的方法。而VO则用于承载复杂的查询结果或特定视图的数据。这只是一个开始旨在引导大家思考业务逻辑的归属避免所有逻辑都堆砌在Service中。4. 核心业务模块实现精讲4.1 用户认证与安全Spring Security JWT安全无小事。我采用Spring SecurityJWT的方案实现了基于令牌的无状态认证。核心流程用户登录调用/auth/login接口提交用户名密码。服务端验证UserDetailsService加载用户信息PasswordEncoder验证密码。生成令牌验证通过后使用JJWT库生成一个包含用户ID、角色等信息的JWT。返回令牌将JWT放在HTTP响应头的Authorization: Bearer中返回给客户端。后续请求客户端在请求头中携带此令牌。令牌校验自定义的JwtAuthenticationFilter会拦截请求解析并验证JWT将认证信息设置到SecurityContextHolder中。权限控制在Controller方法上使用PreAuthorize(“hasRole(‘ADMIN’)”)等注解进行细粒度权限控制。关键代码与避坑点// 在 WebSecurityConfig 中配置 Configuration EnableGlobalMethodSecurity(prePostEnabled true) // 启用方法级安全注解 public class SecurityConfig extends WebSecurityConfigurerAdapter { Override protected void configure(HttpSecurity http) throws Exception { http.csrf().disable() // 对于REST API通常禁用CSRF .sessionManagement().sessionCreationPolicy(SessionCreationPolicy.STATELESS) // 无状态会话 .and() .authorizeRequests() .antMatchers(“/auth/login”, “/products/public/**”).permitAll() // 公开接口 .anyRequest().authenticated() // 其他所有接口都需要认证 .and() .addFilterBefore(jwtAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class); // 添加JWT过滤器 } Bean public JwtAuthenticationFilter jwtAuthenticationFilter() { return new JwtAuthenticationFilter(); } } // 自定义的JWT过滤器 public class JwtAuthenticationFilter extends OncePerRequestFilter { Override protected void doFilterInternal(HttpServletRequest request, HttpServletResponse response, FilterChain chain) throws ServletException, IOException { String authHeader request.getHeader(“Authorization”); if (authHeader ! null authHeader.startsWith(“Bearer “)) { String token authHeader.substring(7); try { // 解析JWT获取用户信息 String username jwtUtil.extractUsername(token); if (username ! null SecurityContextHolder.getContext().getAuthentication() null) { UserDetails userDetails userDetailsService.loadUserByUsername(username); if (jwtUtil.validateToken(token, userDetails)) { // 构建Authentication对象并存入SecurityContext UsernamePasswordAuthenticationToken authentication new UsernamePasswordAuthenticationToken(userDetails, null, userDetails.getAuthorities()); authentication.setDetails(new WebAuthenticationDetailsSource().buildDetails(request)); SecurityContextHolder.getContext().setAuthentication(authentication); } } } catch (Exception e) { // 令牌无效记录日志但继续过滤器链后续会被权限校验拦截 logger.error(“JWT token validation failed”, e); } } chain.doFilter(request, response); } }避坑经验JWT的密钥管理密钥(Secret)绝对不能硬编码在代码中。我将其放在application.yml中并通过环境变量注入。生产环境应使用KMS或Vault等密钥管理服务。令牌过期与刷新JWT一旦签发在过期前无法废止。我设计了双令牌机制access_token短有效期如30分钟和refresh_token长有效期如7天。客户端用过期的access_token配合有效的refresh_token来获取新的access_token。refresh_token可以存入Redis并设置过期时间方便实现“注销即失效”。权限注解的粒度PreAuthorize非常强大但不要滥用。建议在Service层的方法上也进行权限校验形成纵深防御。4.2 商品系统的设计与缓存策略商品模块是电商的核心读多写少对性能要求极高。数据库设计要点product表存储商品基本属性名称、价格、主图等。product_sku表库存量单位表存储具体规格如颜色、尺寸对应的价格、库存。这是实现多规格商品的关键。product_category表类目树使用parent_id实现无限级分类并通过path字段如,1,3,来优化查询效率。缓存策略Redis商品详情缓存Key设计为product:detail:{productId}Value为商品信息的JSON字符串。设置一个合理的TTL如1小时并采用“延时双删”策略保证数据库与缓存的一致性。更新时先删除缓存 - 再更新数据库 - 休眠一小段时间如500ms- 再次删除缓存。第二次删除是为了清除在“更新数据库”这个间隙内可能被其他请求写入的旧缓存。商品列表缓存由于列表查询条件多变分页、排序、筛选直接缓存整个结果集不现实。我采用的方式是缓存“筛选条件对应的商品ID集合”。例如查询“手机类目下价格在2000-3000元的所有商品ID”将这个ID集合缓存起来。获取列表时先从缓存取ID集合再进行分页最后根据ID去查询商品详情详情本身有缓存。这大大减少了数据库的复杂查询压力。库存缓存秒杀场景下库存校验是性能瓶颈。我将热门SKU的库存数量预加载到Redis中Key如stock:sku:{skuId}下单时先对Redis库存进行decr原子操作。如果结果0则预扣成功再异步去数据库进行最终扣减。如果Redis库存不足则直接返回售罄避免穿透到数据库。4.3 订单系统的状态机与幂等性订单系统是电商最复杂的模块之一核心在于状态流转和防止重复请求。订单状态机 我使用枚举Enum来定义订单状态并内嵌状态流转逻辑。这比在代码中写一堆if-else清晰得多。public enum OrderStatus { PENDING_PAYMENT(1, “待支付”) { Override public boolean canTransitionTo(OrderStatus nextStatus) { return nextStatus PAID || nextStatus CANCELLED; } }, PAID(2, “已支付”) { Override public boolean canTransitionTo(OrderStatus nextStatus) { return nextStatus SHIPPED || nextStatus REFUNDING; } }, // ... 其他状态 SHIPPED, COMPLETED, CANCELLED, REFUNDED等 private final int code; private final String desc; // 抽象方法每个状态实现自己的流转规则 public abstract boolean canTransitionTo(OrderStatus nextStatus); } // 在Service中调用 public void changeOrderStatus(Long orderId, OrderStatus newStatus) { Order order orderRepository.findById(orderId).orElseThrow(...); if (!order.getStatus().canTransitionTo(newStatus)) { throw new BusinessException(“订单状态流转非法”); } order.setStatus(newStatus); orderRepository.save(order); // 触发状态变更事件用于通知、日志记录等 applicationEventPublisher.publishEvent(new OrderStatusChangedEvent(this, orderId, newStatus)); }幂等性设计 网络抖动可能导致客户端重复提交“创建订单”或“支付回调”请求。我采用“幂等令牌”机制。客户端在创建订单前先请求后端获取一个唯一的幂等令牌UUID该令牌与当前用户会话关联并存入Redis设置较短有效期如5分钟。客户端提交订单时必须携带此令牌。服务端收到请求先检查Redis中是否存在该令牌存在则删除令牌并继续处理业务不存在则认为是重复请求直接返回之前已创建成功的订单结果。对于支付回调这种外部系统调用的接口除了幂等令牌还需要结合数据库唯一索引如order_nopay_channel来确保同一笔支付只处理一次。4.4 异步化与消息队列RabbitMQ的应用电商系统中很多操作不需要实时完成或者需要保证最终一致性。例如用户下单成功后需要扣减库存已在前端和缓存校验这里是最终扣减。发送订单创建成功短信/站内信。更新用户的购物车。触发可能的营销活动结算。如果所有这些操作都在下单接口的主线程中同步执行接口响应会非常慢且任何一个步骤失败都会导致整个下单失败。我的做法是核心操作同步周边操作异步。同步操作生成订单、扣减真实库存数据库、生成支付流水。这些是交易的核心必须强一致。异步操作将“发送通知”、“更新购物车”等任务封装成消息发送到RabbitMQ。消息处理独立的消费者服务监听队列处理这些任务。即使消费者暂时挂掉消息也会在队列中持久化等待恢复后处理。// 在OrderService中 Transactional public OrderDTO createOrder(OrderCreateRequest request) { // 1. 校验参数、库存等 // 2. 生成订单号、保存订单主信息同步 Order order buildOrder(request); orderRepository.save(order); // 3. 扣减数据库库存同步 reduceStock(order); // 4. 发送异步消息 rabbitTemplate.convertAndSend(“order.exchange”, “order.created”, order.getId()); // 5. 返回订单DTO return convertToDTO(order); } // 监听订单创建消息的消费者 Component RabbitListener(queues “order.created.queue”) public class OrderCreatedMessageConsumer { Autowired private NotificationService notificationService; Autowired private CartService cartService; RabbitHandler public void handleMessage(Long orderId) { // 根据orderId查询订单信息注意这里可能读到未提交的事务数据需要根据业务容忍延迟或做特殊处理 // 发送通知 notificationService.sendOrderCreatedMsg(orderId); // 清理购物车对应商品 cartService.clearItemsAfterOrder(orderId); // ... 其他异步任务 } }经验之谈使用消息队列时一定要考虑消息的可靠性。我配置了生产者确认Publisher Confirm和消费者手动确认Manual Ack确保消息不丢失。同时为重要队列设置了死信交换机DLX将处理失败的消息转移到死信队列方便人工介入排查。5. 生产环境部署与监控考量源码跑起来只是第一步如何让它稳定地运行在生产环境才是真正的挑战。1. 配置文件分离 使用Spring Boot的application-{profile}.yml多环境配置。application.yml定义公共配置application-dev.yml、application-prod.yml分别定义开发和生产环境的数据库地址、Redis地址、日志级别等。通过启动参数--spring.profiles.activeprod来激活。2. 健康检查与监控 Spring Boot Actuator是必备的。我暴露了/actuator/health健康检查、/actuator/metrics指标和/actuator/prometheus供Prometheus拉取数据端点。在Kubernetes中/actuator/health的liveness和readiness探针是服务自愈和流量管理的关键。3. 日志规范化 使用Logback或Log4j2并集成logstash-logback-encoder将日志输出为JSON格式。这样可以直接被ELKElasticsearch, Logstash, Kibana或类似日志平台收集、检索和分析。在日志中统一加入traceId通过MDC或Sleuth实现可以在分布式系统中追踪一个请求的完整链路。4. 数据库连接池与慢SQL 默认的HikariCP性能很好但需要根据实际压力调整maximum-pool-size、connection-timeout等参数。同时开启Druid的监控功能如果使用Druid或利用p6spy这样的组件打印SQL执行时间及时发现并优化慢查询。5. 关于JVM和SQL执行超时 你提到的“JVM或者Spring Boot会设置一个sql执行10秒自动关闭吗”这是一个很好的问题。Spring Boot或JVM本身不会自动关闭长时间运行的SQL。SQL执行超时通常由以下层面控制数据库层面MySQL有wait_timeout、interactive_timeout参数控制连接空闲超时但不会主动杀死正在执行的查询。对于执行时间过长的查询需要DBA手动KILL。连接池层面HikariCP有connection-timeout获取连接超时和max-lifetime连接最大存活时间但不控制单次SQL执行时间。应用层面这是主要控制点。可以在MyBatis的Mapper方法上使用Options(timeout 10)设置秒级超时。或者在JDBC层面通过DataSource配置spring.datasource.hikari.connection-init-sqlSET SESSION MAX_EXECUTION_TIME10000MySQL 5.7.8来设置会话级别的最大执行时间。更常见的做法是在业务代码中将数据库查询操作提交到独立的线程池执行并使用Future.get(timeout, TimeUnit)来设置超时超时后可以尝试取消或进行降级处理。这个项目源码是我多年电商后端开发经验的凝结。它展示的不仅仅是Spring Boot各个组件的用法更是一个完整的、有生产意识的系统架构思路。从模块划分、技术选型到缓存设计、异步解耦再到安全、监控每一个环节都经过了实际业务的考验。希望这份源码和这些文字能为你构建自己的系统提供一份可靠的蓝图和避坑指南。真正的学习始于将代码运行起来然后尝试去修改它、打破它、再修复它。祝你编码愉快。本文还有配套的精品资源点击获取