微服务架构思想无人售货项目架构选型对比从一台柜子撑起一个生意到几百个服务跑满服务器微服务这趟水咱们趟得明明白白。一、单体架构 vs 微服务架构先搞清楚你在选什么做技术选型最忌讳的就是听说微服务很高级我们就上微服务。先看看两种架构到底差在哪。单体架构说白了就是把所有功能模块打成一个 jar/war部署在一个进程里。无人售货柜项目如果用单体架构设备管理、商品管理、订单、支付、用户全塞在一个工程里互相之间直接方法调用。单体架构的优点很直白开发简单调试方便IDE 里一个 main 方法跑起来部署轻松一个包扔上去就行没有分布式调用性能损耗小但缺点也很致命随着业务增长代码像滚雪球一样越滚越大改一个模块要重新部署整个系统某个模块内存泄漏拖垮全局技术栈被锁死在一种语言里。微服务架构则反其道而行——把一个大系统拆成多个独立的小服务每个服务负责单一业务能力独立部署、独立数据库、独立技术栈。对比维度单体架构微服务架构部署方式整体打包部署各服务独立部署技术栈单一语言/框架可异构按需选择数据库共享数据库每个服务独占数据库扩展性整体扩展按需对特定服务扩展故障影响一崩全崩故障隔离到单个服务开发协作容易冲突团队按服务拆分互不干扰运维成本低高需要容器化自动化适用阶段初创期、小团队业务复杂、团队规模大一句话总结单体架构适合活下去微服务架构适合活得久、长得大。二、微服务核心思想拆但要拆得有水平微服务不是简单地把代码拆成多个 Maven Module它的核心思想是以下几点单一职责SRP一个服务只做一件事做好一件事。订单服务就管订单别越界去操作商品库存。独立部署每个服务可以独立构建、测试、部署互不阻塞。独立数据库这是微服务最硬核的约束。服务之间不直连对方数据库只能通过 API 调用。这一条逼着你真正解耦。去中心化没有上帝服务统一管理一切每个服务自治。微服务拆分前单体 ┌─────────────────────────────┐ │ 无人售货系统一个进程 │ │ 设备 | 商品 | 订单 | 支付 | 用户 │ │ 共享一个数据库 │ └─────────────────────────────┘ 微服务拆分后 ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ ┌──────┐ │设备服务│ │商品服务│ │订单服务│ │支付服务│ │用户服务│ │ DB1 │ │ DB2 │ │ DB3 │ │ DB4 │ │ DB5 │ └──┬───┘ └──┬───┘ └──┬───┘ └──┬───┘ └──────┘ └────────┴────────┴────────┘ 通过注册中心互相发现调用三、无人售货柜项目微服务拆分思路无人售货柜这个场景涉及硬件设备控制、商品管理、订单流程、支付对接、用户管理五大模块。按照DDD领域驱动设计的思路来拆服务名职责边界数据库表device-service设备注册、在线状态、远程指令下发、故障告警device_info, device_status, command_logproduct-service商品 CRUD、分类、库存管理product, category, stockorder-service下单、订单状态流转、退款发起order_info, order_itempay-service微信/支付宝支付对接、支付回调处理pay_record, refund_recorduser-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活跃维护注册中心EurekaNacos配置中心Spring Cloud ConfigNacos二合一熔断限流HystrixSentinel网关Zuul 1.xSpring Cloud Gateway分布式事务无原生方案Seata消息队列无原生集成RocketMQ负载均衡RibbonLoadBalancer注意一点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 NetflixSpringCloud Alibaba注册中心无EurekaNacos配置中心无Config Server BusNacos一体熔断限流无HystrixSentinel网关无ZuulGateway分布式事务本地事务无原生方案Seata维护状态—停更活跃社区生态—缩减中蓬勃发展学习曲线低中中推荐指数★★★★★★★★★★七、版本选型版本不对全是泪SpringBoot 3.x 基于 Java 17是当前最稳定的长期支持版本。对应的版本组合如下# pom.xml 核心依赖版本parentgroupIdorg.springframework.boot/groupIdartifactIdspring-boot-starter-parent/artifactIdversion3.2.5/version!--SpringBoot 3.2.x--/parentpropertiesspring-cloud.version2023.0.1/spring-cloud.versionspring-cloud-alibaba.version2023.0.1.0/spring-cloud-alibaba.version/properties版本对应关系表重要SpringBootSpringCloudSpringCloud AlibabaJava版本2.7.x2021.0.x2021.0.xJava 83.0.x2022.0.x2022.0.xJava 173.2.x2023.0.x2023.0.xJava 17版本必须严格对齐否则会出现各种莫名其妙的BeanCreationException。踩过坑的都懂。八、总结无人售货柜项目的技术选型路线已经很清晰了SpringBoot 3.2.x SpringCloud 2023.0.x SpringCloud Alibaba 2023.0.x组件选 Nacos Sentinel Gateway Seata。微服务拆五个核心服务各自独占数据库通过 Nacos 注册发现、Gateway 统一入口。选型定好了接下来就是动手干。先从 Nacos 注册中心开始让服务之间能互相看见对方。