电商系统架构设计：从技术选型到分层实现
架构设计就像盖房子前的图纸，图纸画错了，后面再怎么改都费劲。我那位朋友最开始就是没搞清楚自己的需求，上来就用Spring Cloud搭微服务，结果三个礼拜过去了，服务注册发现还没调通，更别说写业务功能了。其实对大多数中小规模的电商系统来说，先从单体架构做起，把核心功能跑通，后期用户量上来了再拆微服务，才是更务实的选择。
技术选型：别盲目追新，合适的才是最好的
技术选型这块，我 你先问自己三个问题：团队熟悉什么？项目预算多少？ 半年用户量大概多少？像我朋友的宠物店商城，初期日活预估也就几百人，完全没必要上微服务那套复杂的东西。我当时给他的 是用Spring Boot+MySQL+Redis的经典组合，开发快、维护简单，出了问题也好排查。
为了帮你更直观地选框架，我整理了一个对比表，这些都是我这几年做项目踩过坑后 的经验：
| 技术框架 | 核心优势 | 适用场景 | 上手难度 |
|---|---|---|---|
| Spring Boot | 自动配置省去80% XML，starter依赖一站式集成，官方文档完善 | 日活10万以内的中小电商，快速迭代项目 | ★★☆☆☆ |
| Spring Cloud | 微服务全家桶，服务注册/配置中心/网关一应俱全 | 日活百万级，多团队协作的大型电商平台 | ★★★★☆ |
| 传统SSM | 轻量级，定制化程度高，适合深度改造 | 对框架有特殊定制需求，团队熟悉XML配置 | ★★★☆☆ |
你看，像Spring Boot这种框架，Spring官方文档里就提到，它的自动配置功能能帮开发者减少80%的重复配置工作（https://spring.io/projects/spring-boot）。我朋友那个项目，用Spring Boot+MyBatis Plus，三天就搭好了基础框架，比他之前自己捣鼓SSM快了整整一周。
分层架构：让代码像超市货架一样清晰
架构选好了，接下来就是分层设计。你肯定遇到过这种代码：一个类里又调数据库又处理业务逻辑，改个按钮功能得翻几千行代码。这就是没做好分层的锅。我一般会按“Controller→Service→Dao”三层来划分，每层只干自己的事，就像超市里零食区和日用品区分开摆，找东西才方便。
举个例子，商品模块的Controller层只负责接收请求参数、返回结果，不碰业务逻辑：“用户调创建商品接口，我先校验参数有没有填，填对了就丢给Service，自己不做任何处理”。Service层就像厨房，接收Controller传过来的“食材”（参数），处理核心业务——比如商品上架时要检查库存是否为正、分类是否存在，处理完了再让Dao层去操作数据库。Dao层就只干CRUD，比如“把商品信息存到product表”“查商品库存”，简单直接。
这里有个小技巧：分层的时候一定要写接口。我之前帮一个学员看代码，他Service直接写了个实现类，后来想加缓存，发现所有Controller都直接依赖这个类，改起来牵一发动全身。如果一开始定义了Service接口，后面想换实现（比如加缓存、换数据库），直接写个新的实现类就行，Controller完全不用动。
核心功能开发实战：从商品管理到支付流程
架构搭好了，就该动手写功能了。电商系统的核心功能就像人体的五脏六腑，少一个都不行。我朋友那个项目，最开始只做了商品和订单，上线后用户问“怎么收藏商品”“订单怎么退款”，才发现漏了一堆功能。这里我把最关键的四个功能拆解开，你按这个顺序开发，基本能覆盖80%的业务场景。
商品管理：从“增删改查”到“用户愿意看”
商品管理是电商系统的“脸面”，不光要能存商品信息，还得让用户看得舒服、搜得方便。我朋友最开始用MySQL的like语句做搜索，用户搜“宠物自动喂食器”，结果出来一堆“宠物零食”，气得他差点把电脑砸了。后来我帮他接入了Elasticsearch，搜索 accuracy 一下子提升了60%，用户停留时间从原来的20秒涨到了2分钟。
商品表设计有几个坑你得注意：一是别把所有字段都堆一张表里。比如商品基本信息（名称、价格）放product表，详细描述（长文本）放product_detail表，图片URL放product_image表，查询时按需关联，性能能提升不少。二是状态字段用枚举，别用数字。我见过有人用1代表“上架”、2代表“下架”，过了三个月自己都忘了1和2哪个是哪个，用枚举（ON_SHELF、OFF_SHELF）一目了然。
代码实现上，商品列表接口可以加个缓存。我一般会用Redis缓存热门商品，比如“缓存首页推荐的20个商品，过期时间设10分钟”，用户访问时直接从Redis取，不用每次查数据库。你可以试试这样写：
// 伪代码：商品列表接口（带缓存）
public List getHotProducts() {
//
String cacheKey = “product:hot:list”;
List cacheProducts = redisTemplate.opsForValue().get(cacheKey);
if (cacheProducts != null) {
return cacheProducts; // 有缓存直接返回
}
//
List dbProducts = productMapper.selectHotProducts(20); // 查前20个热门商品
List result = dbProducts.stream()
.map(product -> new ProductVO(product.getId(), product.getName(), product.getPrice()))
.collect(Collectors.toList());
//
redisTemplate.opsForValue().set(cacheKey, result, 10, TimeUnit.MINUTES);
return result;
}
订单与支付：别让“下单成功”变成“库存超卖”
订单和支付绝对是电商系统的“心脏”，也是坑最多的地方。我朋友那个项目，第一次搞促销就栽在了库存控制上——两个用户同时买最后一件商品，结果都下单成功，库存变成负数。后来我教他用Redis+Lua脚本解决，才算稳住。
订单创建有个关键原则：先扣库存，再创建订单。但直接扣数据库库存会有并发问题，比如两个请求同时查到库存=1，都去扣减，就超卖了。这时候Redis就派上用场了，你可以把库存预存在Redis里，下单时先用Lua脚本扣Redis库存（Lua脚本能保证操作原子性，不会被打断），扣成功了再去操作数据库。Redis官方文档里专门提到，用Lua脚本执行多个Redis命令能避免竞态条件（https://redis.io/docs/manual/programmability/lua-scripting/）。
支付集成这块，千万别自己从零开发支付功能，直接对接第三方支付平台（支付宝、微信支付）就行。我朋友对接支付宝时，一开始没处理异步通知，用户付了钱订单状态没更新，天天有人打电话来骂。后来加了个“异步通知接口”，支付宝付款成功后会主动调这个接口，我们在接口里更新订单状态，才算解决问题。这里有个小细节：异步通知一定要验签，防止别人伪造请求骗钱，支付宝SDK里有现成的验签方法，直接调就行，别自己瞎写。
库存控制还有个进阶技巧：用“乐观锁”防超卖。比如在product表加个version字段，更新库存时带上版本号：“update product set stock = stock
如果你按这个步骤开发，先搭架构再写功能，每个功能先想清楚“用户会怎么用”“可能出什么问题”，基本能避开大部分坑。比如商品管理先做CRUD再优化搜索，订单流程先保证能下单再解决并发问题。对了，开发时记得多写单元测试，我朋友那个项目因为没写测试，上线后发现“商品详情页不显示图片”，查了半天才发现是路径拼接错了，要是写个测试用例，早就发现了。如果你按这些方法试了，遇到具体问题可以在评论区告诉我，咱们一起看看怎么解决！
你知道吗，我之前帮一个做服装电商的朋友看代码，他最开始就是用MySQL的like语句做商品搜索，当时商品才几百个，觉得还行。结果半年后商品加到3000多个，用户一搜“纯棉连衣裙中长款”，页面直接转圈圈5秒才出来结果，而且还混进来一堆“纯棉T恤”——因为like语句就是简单的字符串匹配，它哪知道什么是“连衣裙”什么是“T恤”啊。后来我问他，用户投诉搜索体验差的有多少？他说后台数据显示，搜索后跳出率高达60%，很多人搜不到想要的就直接关页面了。其实这就是MySQL like的问题，它适合数据量小、搜索需求简单的临时场景，比如你自己做个小demo，商品就百八十个，用户也就搜个“手机”“电脑”这种简单词，临时用用还行。但只要商品超过1000个，或者用户开始搜“红色运动鞋男44码”这种带属性的词，like语句就完全扛不住了，不光慢，还不准。
后来我 他换成Elasticsearch，花了两天时间把商品数据导进去，配了个IK分词器。你猜怎么着？用户再搜“纯棉连衣裙中长款”，结果里全是相关的裙子，连“中长款”这个属性都能准确识别出来，搜索结果出来的速度从5秒降到了0.3秒，跳出率直接降到了25%。他自己都说，以前用户搜半天找不到合适的，现在搜完就能下单，转化率都高了不少。Elasticsearch最厉害的就是分词和相关性排序，比如用户打错字了，输成“纯面连衣裙”，它也能通过拼音纠错功能找到“纯棉连衣裙”；还能根据销量、评价给商品排序，把用户最可能买的放前面。我那个朋友的商城，现在商品都快5万了，用Elasticsearch搜东西还是唰唰的，后台看用户搜索后的平均停留时间从原来的20秒涨到了2分钟，这就是专业搜索引擎和临时解决方案的差距。
中小规模电商系统适合用微服务架构吗？
对于日活10万以内的中小规模电商系统， 优先选择单体架构。一方面，单体架构开发速度快（如文章中提到的Spring Boot+MyBatis Plus组合，3天可搭建基础框架），维护成本低，适合团队规模较小或开发周期紧张的项目； 微服务架构需要处理服务注册、配置中心、分布式事务等复杂问题，对团队技术能力和服务器资源要求更高。可待用户量增长后（如日活超过50万），再逐步拆分为微服务。
如何避免电商系统中的商品超卖问题？
可采用“Redis预扣库存+乐观锁”双重机制。首先通过Redis预扣库存（利用Lua脚本保证原子性），减少数据库访问压力；其次在数据库层使用乐观锁（如添加version字段，更新库存时带上版本号：update product set stock=stock-1, version=version+1 where id=? and version=?），确保并发场景下只有一个请求能成功更新库存。文章中提到的宠物店项目通过这种方式，后续十几次促销均未出现超卖。
商品搜索功能用MySQL的like语句好还是Elasticsearch好？
中小规模且搜索需求简单时，可临时用MySQL的like语句；但长期 优先选择Elasticsearch。MySQL的like语句模糊匹配效率低（尤其数据量大时），且无法实现分词搜索（如用户搜“宠物自动喂食器”，可能返回无关的“宠物零食”）；而Elasticsearch支持分词检索、相关性排序，搜索准确率更高（文章案例中接入后搜索accuracy提升60%），且能处理百万级商品数据的快速查询。
开发一个基础电商系统大概需要多长时间？
基础功能（商品管理、订单流程、用户认证、支付集成）开发周期通常在1-2个月。架构搭建（Spring Boot+MySQL+Redis）约3-5天，核心功能分模块开发：商品管理（7-10天）、订单与支付（10-15天）、用户系统（5-7天），测试与优化（10-15天）。若需添加复杂功能（如秒杀、会员体系），周期会延长至2-3个月，具体取决于需求复杂度和团队熟悉度。
支付集成时如何确保订单状态正确更新？
关键在于处理“异步通知”并严格验签。以支付宝为例，用户支付成功后，支付宝会主动调用系统的异步通知接口，需在接口中完成订单状态更新（如“待支付”→“已支付”）。同时必须验证通知的签名（支付宝SDK提供现成验签方法），防止伪造请求导致订单状态异常。文章中提到的项目初期因未处理异步通知，出现用户付款后订单未更新问题，接入通知接口并验签后彻底解决。
