微服务与 Spring Cloud 概览：版本列车、组件地图

微服务把单体应用拆成一组可以独立部署、独立扩容的小服务，服务之间用网络通信协作。拆分解决了一部分问题，也带来一批新问题：服务地址怎么找、配置怎么管、流量怎么进、调用失败怎么办、一次请求跨多个服务怎么排查。Spring Cloud 就是针对这批问题的"通用解法集合"。本章先建立全局认知，并确定整本教程的版本锚点。

微服务化之后，新增了哪些问题

拆分后基础设施层面的问题大致有八类：服务注册与发现（知道谁在哪）、远程调用（如何优雅互调）、负载均衡、统一网关（路由、鉴权、限流）、配置中心、容错（超时、重试、熔断、降级）、可观测性（日志、指标、链路追踪）、消息与分布式事务。任何一个环节没有统一方案，团队就会各自发明轮子，链路一长便难以维护。

Spring Cloud 是什么

Spring Cloud 是构建在 Spring Boot 之上的微服务工具集，核心思路是"约定优于配置"：引入对应 starter、写少量配置，就能获得某项能力，并且组件之间通过抽象接口协作，可以替换实现。组件按来源分两类：一是 Spring 官方主线组件（OpenFeign、Gateway、LoadBalancer、Stream、Config 等）；二是由 Alibaba 开源并贡献到社区生态的组件（Nacos、Sentinel、Seata 等），后者通过 Spring Cloud Alibaba 项目与官方线做集成，两者合起来构成国内最主流的技术栈。

版本列车与 Spring Boot 对应关系

Spring Cloud 用"版本列车（Release Train）"管理组件版本，命名形如 2024.0.x、2025.0.x，小版本号以官方发布页为准。列车号与 Spring Boot 有严格对应，不能随意混搭，选型前务必先查官方兼容矩阵：

Spring Cloud	Spring Boot	说明
2023.0.x	3.2.x	上一代稳定线
2024.0.x	3.3.x / 3.4.x	支持两个 Boot 小版本
2025.0.x	3.5.x	本教程主线
2025.1.x	4.0.x	首次引入"年份.小版本"命名，配套 Boot 4.0

2025.1 之后的新列车与 Spring Boot 的对应关系，写作时以 spring.io 官方发布页为准；不同大版本线（Boot 3 与 Boot 4）之间的 API 差异也要以官方迁移文档为准。

本教程版本锚点

统一采用：JDK 17 或 21、Spring Boot 3.5.x、Spring Cloud 2025.0.x、spring-cloud-alibaba 2025.0.0.x（版本命名与本线 Spring Cloud 对齐）。配套中间件：Nacos Server 3.x（写作时官方最新，2.x 也可运行示例）、Sentinel Dashboard 1.8.8、Seata Server 2.3.x、RabbitMQ、Redis、Zipkin，均以各项目官方版本说明为准。引入依赖时一律用 BOM（spring-cloud-dependencies 与 spring-cloud-alibaba-dependencies）统一管理版本，不要手写组件版本号。

依赖管理：用 BOM 锁版本

工程里不要再为 OpenFeign、Gateway、Nacos 等组件逐个手写版本号，统一由两个 BOM 管理。在父 pom 的 dependencyManagement 中引入：

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-dependencies</artifactId>
            <version>2025.0.x</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-alibaba-dependencies</artifactId>
            <version>2025.0.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

两个 BOM 中的小版本号以官方发布页为准，升级时只改 BOM 一处，业务模块只声明 artifactId 即可。版本升级遵循固定顺序：先升 Spring Boot，再按兼容矩阵升 Spring Cloud，最后核对 Spring Cloud Alibaba 对应线，避免"只升 Boot 导致组件行为漂移"的隐性风险。

组件地图速览

注册与发现：Nacos Discovery（主流），Consul、Eureka（见第 04 章对比）。远程调用：OpenFeign 声明式接口 + LoadBalancer 负载均衡。网关：Spring Cloud Gateway，反应式（WebFlux）实现为主，2024.0 起官方另提供基于 Spring MVC 的网关模块。配置中心：Nacos Config。流控与熔断降级：Sentinel，也可用 Resilience4j。链路追踪：Micrometer Tracing + Zipkin（第 16 章）。消息：Spring Cloud Stream 抽象 RabbitMQ/Kafka 等 Binder。分布式事务：Seata（第 17、18 章）。

一次典型调用长什么样

把组件串起来看一次"下单"的外部请求（箭头表示调用方向）：

浏览器 --> API 网关（鉴权/限流/路由）
              --> order-service（注册在 Nacos）
                     --> user-service（OpenFeign + LoadBalancer 选实例）
                     --> inventory-service（OpenFeign）
全程：traceId 随请求头传播，Micrometer Tracing 埋点，Zipkin 汇总展示

网关只处理外部流量；服务之间用"服务名 + 负载均衡"互调，不再经过网关。Nacos 里能看到各服务注册的实例与各自的客户端缓存；任何一环变慢或报错，由超时、重试、Sentinel 兜底；排查故障时按 traceId 把散落在各服务的日志与调用片段拼回一次完整请求。这张图是整本教程的地图：后续每一章都是在为图上的一环补齐工程细节，建议学习时随时回看本章。

示例服务约定

后续章节沿用两个示例服务：order-service 调用 user-service，通过 http://localhost 本地运行验证；示例站点类占位地址统一写作 https://example.com。各章节配置均基于上文版本锚点，若你的工程落在其他版本线，先核对官方兼容矩阵再套用。

小结

本章明确了两个关键认知：第一，微服务的复杂度要靠一组标准化组件收敛，Spring Cloud 负责把这组组件统一装配；第二，版本必须成体系，Boot、Cloud、Cloud Alibaba 三者要按官方矩阵对齐。从下一章起，我们按"先让服务互相找得到、叫得动，再做网关、容错、可观测性"的顺序逐步搭建。