📚 课程目录第1章微服务架构与Spring Cloud工程全景

1. 微服务架构与Spring Cloud工程全景

在讨论 Spring Cloud 之前，需要先明确一个前提：微服务不是“把代码拆小”，而是围绕业务能力建立一组可独立开发、独立部署、独立扩缩容、独立演进的服务，并通过轻量协议完成协作。单体应用在早期具备开发简单、调用直接、事务一致等优势，但当代码规模、团队人数和发布频率同时增长时，构建时间、回归范围、故障爆炸半径和数据库耦合会迅速成为瓶颈。微服务的价值，正是用分布式复杂度换取组织与交付上的可扩展性。

从单体到微服务：演进不是一步到位

典型的演进路径可以概括为四个阶段。第一阶段是单体应用：所有模块共享一个进程和一个数据库，模块间通过方法调用协作。第二阶段是垂直拆分：按业务域把系统切成若干较粗粒度的应用，例如商品、订单、库存，各自拥有独立数据库，但服务治理能力仍然薄弱。第三阶段是服务化：引入注册中心、配置中心、网关、负载均衡和熔断限流，服务之间通过 HTTP 或 RPC 通信。第四阶段是平台化：在服务化基础上补齐可观测性、链路追踪、灰度发布、容器编排和持续交付，使微服务真正具备工程化落地能力。

需要强调的是，拆分粒度并非越细越好。一个可操作的判断标准是：一个服务应当由一个小团队（通常 5～9 人）独立负责，具备清晰的业务边界、独立的数据存储和独立的发布节奏。如果两个模块必须同时修改、同时发布、共享同一张表，那么它们更适合放在同一个服务内。

Spring Cloud 核心组件生态

Spring Cloud 并不是单一框架，而是一组面向分布式系统的工程化解决方案集合。它通过 Spring Boot 的自动装配机制，把服务注册发现、配置管理、网关路由、负载均衡、容错保护、链路追踪等能力以“起步依赖 + 注解 + 配置”的方式提供给开发者。其核心组件可以按职责划分为以下几类：

服务注册与发现：Nacos、Eureka、Consul。服务启动时注册自身地址，调用方通过服务名而非 IP 获取实例列表，从而实现位置透明。
配置中心：Nacos Config、Spring Cloud Config。把配置从代码中剥离，支持按环境、按服务、按灰度维度动态刷新。
API 网关：Spring Cloud Gateway。统一入口，承担路由转发、鉴权、限流、跨域和协议适配。
负载均衡：Spring Cloud LoadBalancer。在客户端侧选择目标实例，支持轮询、随机、权重等策略。
容错与限流：Sentinel、Resilience4j。通过熔断、降级、隔离和限流，防止局部故障扩散为雪崩。
链路追踪：Micrometer Tracing + Zipkin/SkyWalking。为跨服务调用生成统一 TraceId，定位延迟与异常。
消息与事件：Spring Cloud Stream。用 Binder 抽象屏蔽 Kafka、RabbitMQ 等中间件差异，支撑异步解耦。

这些组件并非必须全部启用。工程实践中更推荐“按需引入、逐步补齐”：先解决注册发现与配置管理，再引入网关与容错，最后完善可观测性与消息驱动。

版本选型：先对齐 Spring Boot，再对齐 Spring Cloud

Spring Cloud 的版本兼容性由 Spring Boot 决定，而不是由 Spring Cloud 自身独立决定。工程上应遵循“先定 Spring Boot，再选 Spring Cloud，最后选组件版本”的顺序。以当前主流组合为例：Spring Boot 3.2.x 对应 Spring Cloud 2023.0.x（代号 Leyton），要求 JDK 17 及以上；Spring Boot 2.7.x 对应 Spring Cloud 2021.0.x，可运行在 JDK 8/11。若使用 Nacos，需要同时确认 Nacos Server 版本与 spring-cloud-alibaba 版本的对应关系，例如 Spring Cloud Alibaba 2022.0.0.0 适配 Spring Cloud 2022.0.x 与 Spring Boot 3.0.x。

版本选型时建议遵循三条原则：第一，优先选择仍在官方支持周期内的版本，避免使用已停止维护的分支；第二，同一工程内所有服务的 Spring Boot 与 Spring Cloud 版本必须一致，避免因依赖冲突导致注册失败或序列化异常；第三，组件版本以官方兼容矩阵为准，不要凭经验混搭。下面给出一个可参考的依赖管理片段：

<properties>
  <java.version>17</java.version>
  <spring-boot.version>3.2.5</spring-boot.version>
  <spring-cloud.version>2023.0.1</spring-cloud.version>
  <spring-cloud-alibaba.version>2023.0.1.0</spring-cloud-alibaba.version>
</properties>

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>org.springframework.boot</groupId>
      <artifactId>spring-boot-dependencies</artifactId>
      <version>${spring-boot.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
    <dependency>
      <groupId>org.springframework.cloud</groupId>
      <artifactId>spring-cloud-dependencies</artifactId>
      <version>${spring-cloud.version}</version>
      <type>pom</type>
      <scope>import</scope>
    </dependency>
  </dependencies>
</dependencyManagement>

这段配置的作用是统一锁定依赖版本，子模块只需声明 groupId 和 artifactId，无需重复写版本号。若启动时出现 NoSuchMethodError 或 ClassNotFoundException，通常说明版本矩阵未对齐，应优先检查 Spring Boot 与 Spring Cloud 的对应关系。

工程化落地路线

一个可执行的落地路线通常分为五步。第一步，建立父工程与统一依赖管理，约定 JDK、编码、打包插件和公共依赖版本。第二步，搭建注册中心与配置中心，建议先在本机以单机模式启动 Nacos，确认服务能注册、配置能拉取。第三步，抽取公共模块，把统一返回体、异常处理、日志切面、Feign 拦截器等放入 common 模块，避免各服务重复实现。第四步，引入网关与容错组件，把外部流量统一收口到 Gateway，并为关键依赖配置 Sentinel 规则。第五步，补齐可观测性，接入 Micrometer、Zipkin 和日志聚合，使问题可定位、可回溯。

落地初期不必追求组件齐全。建议先跑通“注册 + 配置 + 网关 + 一个业务服务”的最小闭环，再逐步叠加容错、消息和可观测性。每引入一个组件，都要明确它解决的具体问题，避免为了技术而技术。

微服务拆分后，原本单体中的本地事务会变成分布式事务。不要默认所有场景都需要强一致，应优先考虑最终一致性、幂等设计和补偿机制。数据库层面坚持“一个服务一个库”，禁止跨服务直接访问对方数据库。

综上，微服务架构的本质是用工程化手段管理分布式复杂度，而 Spring Cloud 提供了这套手段的标准化实现。理解演进路径、组件职责、版本约束和落地顺序，是后续所有工程实践的基础。