电商系统不是技术堆叠：LikeShop如何用分层Hold住复杂业务？

2026/6/30 13:54:41

很多电商系统介绍技术栈时，只会罗列框架和数据库，但真正有价值的问题是：这些技术如何协同解决“复杂电商业务”的？
本文不吹嘘“新技术”，而是从稳定性、分层设计、数据库优化、认证选型、前端多端等维度，拆解一套可落地的电商架构设计思路。

一、为什么这套架构不是“简单技术堆叠”？

随手打开一个电商项目的技术文档，常见画风是：

使用 Spring Boot
使用 MySQL
使用 Redis
前端用 Vue

然后……就没了。
这就像说“我造了一栋楼，用了钢筋水泥”，但没人知道承重结构怎么设计、水电如何走线、遇到地震会不会倒。

真正有经验的架构师会问：

这些技术是如何协同工作，来应对秒杀库存扣减、优惠券叠加、订单状态机、多端同步等复杂场景的？

LikeShop 单商户 Java 版的设计核心，不是“技术先进”，而是在可控复杂度下，支撑高频交易 + 营销规则 + 长期二开的能力。
下面我们就从后端到前端，逐一拆解每个选型背后的取舍逻辑。

二、后端技术栈：稳定优先，而不是激进升级

1. 核心框架与架构模式

基础框架：Spring Boot 2.7.5
开发语言：Java 1.8
项目管理：Maven
架构模式：多模块分层架构

为什么不是 Spring Boot 3.x + Java 17？

答案很现实：电商系统优先考虑“稳定性 + 生态成熟度”。

Spring Boot 2.7.x + Java 8 的组合，生态最成熟，兼容性最好，企业使用最广。
大量第三方库（支付、物流、短信等）在 Java 8 下经过长期考验，升级到 Java 17 可能引入不可预见的兼容性风险。
对于电商业务，减少不可控问题远比“追新”更重要。

👉 这意味着：部署运维风险更低，长期稳定性更高。

2. 多模块分层架构——主动控制复杂度

LikeShop 不是单体“代码堆”，而是通过模块化 + 分层来防止业务逻辑互相污染。典型分层如下：

api（接口层） → 接收 HTTP 请求，参数校验 ↓ application（应用编排）→ 组合多个领域服务，处理事务边界 ↓ domain（核心业务逻辑） → 订单、营销、库存等核心规则 ↓ infrastructure（数据与外部依赖）→ 数据库操作、RPC、缓存

关键收益：
当营销规则变更时，只需修改domain中的相关领域对象，不会波及api和infrastructure。
复杂业务被隔离在特定层级，整个系统不至于“牵一发动全身”。

三、数据库与数据访问：围绕“订单密集写入”优化

数据库：MySQL 5.7.49
ORM：MyBatis Plus 3.5.2

为什么不用 PostgreSQL 或 NoSQL？

单商户系统的瓶颈，通常不在数据库类型，而在访问模式。MySQL 5.7 足够成熟，运维成本低，且能支撑绝大多数电商场景（订单量级在百万至千万级别）。

MyBatis Plus 的价值：

相比 JPA/Hibernate，它更接近原生 SQL，开发人员对最终执行的 SQL 有完全控制权。
电商系统中经常需要复杂的统计查询、联表聚合，ORM 的自动映射容易产生性能坑，而 MyBatis Plus 允许精细调优。
提供基础的 CRUD 能力，减少重复代码，但不会强制抽象。

👉核心原则：在电商系统中，SQL 可控性 > ORM 抽象能力。

四、安全与认证：轻量但高性能的会话模型

权限框架：Sa-Token 1.32.0
缓存支持：Redis（集成 Sa-Token）

为什么不是 Spring Security？

这是一个典型的架构取舍问题：

Spring Security：功能强大，但体系复杂，学习成本高，配置繁琐。
Sa-Token：轻量、易扩展、注解驱动，更贴近业务开发习惯。

对于电商系统，认证授权不是核心业务，没必要引入一个“庞然大物”。Sa-Token 降低了认证系统的复杂度，让团队把精力集中在订单和营销上。

Redis 的作用：

存储会话信息，支持分布式登录态共享。
高并发下，基于内存的 Session 读写比传统 HttpSession 更高效。

五、工具层设计：不是“方便”，而是“降低系统噪音”

JSON处理：Fastjson2 2.0.16
对象简化：Lombok 1.18.24

这些工具表面上是“省代码”，实际目的是降低非业务复杂度，让核心逻辑更清晰。

Fastjson2：高性能 JSON 序列化/反序列化，减少接口交互时的 CPU 开销。
Lombok：消除 getter/setter/日志等样板代码，让业务代码更简洁。

但要注意，Lombok 需团队统一规范，否则会带来调试不便——这是“取舍”的一部分。

六、前端架构：统一多端，而不是重复开发

管理后台（Admin）

框架：Vue 3 + TypeScript
构建：Vite
UI库：Element Plus
状态管理：Pinia

👉 设计目标：快速开发、强类型约束、高可维护性。
管理后台面向运营人员，交互相对固定，但业务逻辑复杂（商品上下架、订单处理、报表），TypeScript 能有效减少运行时类型错误。

移动端（核心用户侧）

框架：UniApp + Vue 3 + TypeScript
支持平台：微信小程序、支付宝小程序、H5

为什么选择 UniApp？
不是因为“跨端”听起来酷，而是用一套业务代码覆盖多个流量入口。
对于电商而言，小程序（微信+支付宝）和 H5 是核心获客渠道，若每个端独立开发，成本翻倍且体验难以一致。UniApp 让我们能做到：

活动页面同步上线
购物车、订单状态逻辑统一
降低长期维护成本

七、真正的核心：复杂度如何被控制？

上面所有的技术选型，最终都指向一个目标：控制电商系统的复杂度增长。
LikeShop 采取了以下关键策略：

把复杂度集中在“订单 + 营销”
电商最易变的业务是价格计算、优惠券叠加、库存扣减。
将这些逻辑收拢在domain层，而不是分散在各个 Controller 或 Service 中。
用分层架构隔离变化
- 上层（api）负责协议适配
- 中层（application）负责流程编排
- 下层（infrastructure）负责数据持久化
  当支付通道更换时，只需调整 infrastructure 中的支付实现，核心业务不受影响。
用稳定技术栈降低风险
- 不追新版本
- 不堆砌“网红”技术
- 每个选型都有明确的“为什么”而非“别人也用”