微服务架构思想：无人售货项目架构选型对比
从"一台柜子撑起一个生意"到"几百个服务跑满服务器"，微服务这趟水，咱们趟得明明白白。
一、单体架构 vs 微服务架构：先搞清楚你在选什么
做技术选型，最忌讳的就是"听说微服务很高级，我们就上微服务"。先看看两种架构到底差在哪。
单体架构，说白了就是把所有功能模块打成一个 jar/war，部署在一个进程里。无人售货柜项目如果用单体架构，设备管理、商品管理、订单、支付、用户全塞在一个工程里，互相之间直接方法调用。
单体架构的优点很直白：
- 开发简单，调试方便，IDE 里一个 main 方法跑起来
- 部署轻松，一个包扔上去就行
- 没有分布式调用，性能损耗小
但缺点也很致命：随着业务增长，代码像滚雪球一样越滚越大，改一个模块要重新部署整个系统，某个模块内存泄漏拖垮全局，技术栈被锁死在一种语言里。
微服务架构则反其道而行——把一个大系统拆成多个独立的小服务，每个服务负责单一业务能力，独立部署、独立数据库、独立技术栈。
| 对比维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署方式 | 整体打包部署 | 各服务独立部署 |
| 技术栈 | 单一语言/框架 | 可异构，按需选择 |
| 数据库 | 共享数据库 | 每个服务独占数据库 |
| 扩展性 | 整体扩展 | 按需对特定服务扩展 |
| 故障影响 | 一崩全崩 | 故障隔离到单个服务 |
| 开发协作 | 容易冲突 | 团队按服务拆分，互不干扰 |
| 运维成本 | 低 | 高，需要容器化+自动化 |
| 适用阶段 | 初创期、小团队 | 业务复杂、团队规模大 |
一句话总结：单体架构适合"活下去"，微服务架构适合"活得久、长得大"。
二、微服务核心思想：拆，但要拆得有水平
微服务不是简单地把代码拆成多个 Maven Module，它的核心思想是以下几点：
- 单一职责（SRP）：一个服务只做一件事，做好一件事。订单服务就管订单，别越界去操作商品库存。
- 独立部署：每个服务可以独立构建、测试、部署，互不阻塞。
- 独立数据库：这是微服务最硬核的约束。服务之间不直连对方数据库，只能通过 API 调用。这一条逼着你真正解耦。
- 去中心化：没有"上帝服务"统一管理一切，每个服务自治。
微服务拆分前（单体）： ┌─────────────────────────────┐ │ 无人售货系统（一个进程） │ │ 设备 | 商品 | 订单 | 支付 | 用户 │ │ 共享一个数据库 │ └─────────────────────────────┘ 微服务拆分后： ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │设备服务│ │商品服务│ │订单服务│ │支付服务│ │用户服务│ │ DB1 │ │ DB2 │ │ DB3 │ │ DB4 │ │ DB5 │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──────┘ └────────┴────────┴────────┘ 通过注册中心互相发现调用三、无人售货柜项目微服务拆分思路
无人售货柜这个场景，涉及硬件设备控制、商品管理、订单流程、支付对接、用户管理五大模块。按照DDD（领域驱动设计）的思路来拆：
| 服务名 | 职责边界 | 数据库表 |
|---|---|---|
| device-service | 设备注册、在线状态、远程指令下发、故障告警 | device_info, device_status, command_log |
| product-service | 商品 CRUD、分类、库存管理 | product, category, stock |
| order-service | 下单、订单状态流转、退款发起 | order_info, order_item |
| pay-service | 微信/支付宝支付对接、支付回调处理 | pay_record, refund_record |
| user-service | 用户注册、登录、会员积分 | user_info, member_point |
拆分原则三条铁律：
- 高内聚低耦合：订单服务需要扣库存？调商品服务的 API，别直接操作 product 表。
- 数据库独占：每个服务有自己的 schema，物理隔离。想共享数据？走接口。
- 领域边界清晰：设备归设备域，商品归商品域，别搞混。"商品在哪个设备上"这个问题，归属设备服务管，因为设备知道自己的货道布局。
四、SpringCloud Netflix vs SpringCloud Alibaba：时代的选择
早些年搞微服务，SpringCloud Netflix 是标配——Eureka 做注册中心、Hystrix 做熔断、Zuul 做网关、Ribbon 做负载。但 2018 年以后，Netflix 那套组件陆续进入维护模式（Maintenance Mode），不再更新新功能了。
SpringCloud Alibaba 横空出世，阿里把自己经过双十一锤炼的一套中间件贡献给了开源社区，成为了 SpringCloud 生态的新主力：
| 功能 | Netflix（已停更） | Alibaba（活跃维护） |
|---|---|---|
| 注册中心 | Eureka | Nacos |
| 配置中心 | Spring Cloud Config | Nacos（二合一） |
| 熔断限流 | Hystrix | Sentinel |
| 网关 | Zuul 1.x | Spring Cloud Gateway |
| 分布式事务 | 无原生方案 | Seata |
| 消息队列 | 无原生集成 | RocketMQ |
| 负载均衡 | Ribbon | LoadBalancer |
注意一点：Spring Cloud Gateway 是 Spring 官方出品，不算 Alibaba 组件，但和 SpringCloud Alibaba 配套使用是当前主流。
SpringCloud Alibaba 全家桶一览：
┌─────────────────────────────────────────┐ │ Spring Cloud Gateway │ ← 统一入口 ├─────────────────────────────────────────┤ │ Nacos (注册中心 + 配置中心) │ ← 服务发现 & 配置管理 ├─────────────────────────────────────────┤ │ Sentinel (熔断限流) │ Seata (分布式事务) │ ← 容错 & 事务 ├─────────────────────────────────────────┤ │ RocketMQ (消息驱动) │ Dubbo (RPC通信) │ ← 异步 & 高性能调用 └─────────────────────────────────────────┘五、微服务带来的挑战：不是拆完就万事大吉
拆成微服务后，你会遇到单体架构里不存在的问题：
- 分布式事务：下单扣库存涉及订单服务和商品服务两个数据库，怎么保证数据一致性？→ Seata 来解决。
- 服务间通信：HTTP 调用还是 RPC？超时怎么设？重试策略怎么定？→ OpenFeign / Dubbo。
- 链路追踪：一个请求经过 5 个服务，哪一步慢了？→ SkyWalking。
- 配置管理：几十个服务的配置文件怎么管？改一个配置要重新部署吗？→ Nacos 配置中心热更新。
六、架构选型对比总表
把三种方案放一起对比，一目了然：
| 维度 | 单体架构 | SpringCloud Netflix | SpringCloud Alibaba |
|---|---|---|---|
| 注册中心 | 无 | Eureka | Nacos |
| 配置中心 | 无 | Config Server + Bus | Nacos（一体） |
| 熔断限流 | 无 | Hystrix | Sentinel |
| 网关 | 无 | Zuul | Gateway |
| 分布式事务 | 本地事务 | 无原生方案 | Seata |
| 维护状态 | — | 停更 | 活跃 |
| 社区生态 | — | 缩减中 | 蓬勃发展 |
| 学习曲线 | 低 | 中 | 中 |
| 推荐指数 | ★★★ | ★★ | ★★★★★ |
七、版本选型：版本不对，全是泪
SpringBoot 3.x 基于 Java 17，是当前最稳定的长期支持版本。对应的版本组合如下：
# pom.xml 核心依赖版本<parent><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-parent</artifactId><version>3.2.5</version><!--SpringBoot 3.2.x--></parent><properties><spring-cloud.version>2023.0.1</spring-cloud.version><spring-cloud-alibaba.version>2023.0.1.0</spring-cloud-alibaba.version></properties>版本对应关系表（重要！）：
| SpringBoot | SpringCloud | SpringCloud Alibaba | Java版本 |
|---|---|---|---|
| 2.7.x | 2021.0.x | 2021.0.x | Java 8+ |
| 3.0.x | 2022.0.x | 2022.0.x | Java 17+ |
| 3.2.x | 2023.0.x | 2023.0.x | Java 17+ |
版本必须严格对齐，否则会出现各种莫名其妙的BeanCreationException。踩过坑的都懂。
八、总结
无人售货柜项目的技术选型路线已经很清晰了：SpringBoot 3.2.x + SpringCloud 2023.0.x + SpringCloud Alibaba 2023.0.x，组件选 Nacos + Sentinel + Gateway + Seata。微服务拆五个核心服务，各自独占数据库，通过 Nacos 注册发现、Gateway 统一入口。
选型定好了，接下来就是动手干。先从 Nacos 注册中心开始，让服务之间能互相看见对方。
