1. 课程导学与项目全景

大家好，我是这门课的主讲人。

做后端十几年了，我踩过不少坑。尤其是库存系统，看着简单，拆起来真要命。今天咱们先聊聊全景，让你心里有个底。

1.1 库存管理系统业务全景

库存系统，说白了就是管货的。但别小看它，业务场景其实挺复杂。

我参与过几个电商平台的库存项目，核心业务无非这几块：

• 商品库存管理：入库、出库、盘点、调拨。这是基础。
• 库存查询与预警：实时库存、安全库存、超卖预警。嗯，超卖是电商大忌。
• 库存锁定与释放：下单锁库存、支付扣库存、取消释放。这里最容易出并发问题。
• 库存同步：多仓、多门店、多平台之间的库存同步。我曾经被这个搞到凌晨三点。
• 库存报表与分析：周转率、滞销品、缺货分析。老板最爱看这个。

你想想看，一个订单进来，要查库存、锁库存、扣库存，还要同步给各个渠道。如果系统是单体的，压力一大，直接就崩了。

1.2 单体架构痛点

很多团队起步时都用单体架构。说实话，小规模时挺爽的，开发快、部署简单。但业务一复杂，问题就来了。

我经历过一个真实的项目：库存系统刚开始只有几千个SKU，单体跑得挺好。后来业务扩张到几十万SKU，每天几百万订单，单体就扛不住了。

具体痛点有哪些？我列一下：

• 耦合严重：库存查询、锁定、同步全在一个进程里。改一个功能，整个系统都要重新部署。有一次我改了个日志级别，结果把库存锁定模块搞挂了，被老板骂了一顿。
• 扩展性差：流量大了只能垂直扩展（加机器），但数据库还是单点。你想想看，加再多应用服务器，数据库一挂全完蛋。
• 发布风险高：一个小改动，需要全量回归测试。我曾经因为一个库存同步的bug，导致线上超卖了几千单，赔了不少钱。
• 技术栈锁定：单体通常用一套技术栈。你想引入新的缓存方案或消息队列？得，整个系统都得改。
• 团队协作困难：几十个人在一个代码库里改，合并冲突能让你崩溃。我记得有一次合并代码花了整整两天。

1.3 微服务拆分收益

为什么要拆？说白了，就是为了让系统能「扛得住、改得快、跑得稳」。

我个人习惯把收益分成三个维度：

维度	单体架构	微服务架构
扩展性	只能整体扩展，资源浪费	按需扩展，库存查询服务可以单独加机器
开发效率	一个团队改一个代码库，互相等待	多个团队并行开发，互不干扰
故障隔离	一个模块挂了，整个系统不可用	库存查询挂了，库存锁定还能继续工作
技术多样性	只能用一种技术栈	不同服务可以用不同的语言和数据库
部署频率	一周一次大版本发布	每天可以多次独立部署

我参与的一个项目，拆分后库存查询的响应时间从500ms降到了50ms。为什么？因为我们可以单独给查询服务加缓存、加索引，不用考虑对其他模块的影响。

1.4 课程技术栈概览

这门课我们用的技术栈，都是我在实际项目中验证过的。说白了，就是「能打」的组合。

核心技术栈如下：

• Spring Cloud Alibaba：服务注册与发现（Nacos）、配置管理（Nacos Config）、服务调用（Feign）、负载均衡（Ribbon）、熔断降级（Sentinel）。这套组合拳，我在三个项目里用过，稳得很。
• Docker：容器化部署。每个微服务一个容器，环境一致，部署简单。我记得第一次用Docker部署库存服务，从打包到上线只用了10分钟，以前手动部署至少要半小时。
• Kubernetes（K8s）：容器编排。自动扩缩容、服务发现、滚动更新。嗯，这个有点复杂，但学会了真香。
• MySQL + Redis：库存数据存储。MySQL存主数据，Redis做缓存和分布式锁。库存扣减的并发控制，全靠Redis的原子操作。
• RocketMQ：异步消息。库存同步、库存释放这些操作，用消息队列解耦，系统瞬间变得清爽。
• Seata：分布式事务。库存扣减和订单创建需要保证一致性，Seata的AT模式我用下来感觉最顺手。

这套技术栈，我用了两年多。说实话，刚开始学K8s的时候我也头疼，但一旦上手，你会发现运维效率提升不是一星半点。

举个例子：以前上线一个新版本，要手动备份、停服、替换、重启，至少半小时。现在用K8s的滚动更新，零停机，几分钟搞定。

好了，第一章就到这里。全景图已经给你画好了，接下来我们会一步步深入每个模块。记住，库存系统拆分的核心就三个字：解耦、扩展、稳定。