尚硅谷SpringCloud教程2024版笔记
什么是 SpringCloud
Spring Cloud是基于Spring Boot的微服务架构开发工具，旨在简化分布式系统的开发。它提供了一站式解决方案，涵盖微服务开发中的常见问题，包括：
- 服务注册与发现：实现服务的动态注册与调用，支持 Eureka、Consul 等。
- 配置管理：集中管理微服务配置，支持配置的热加载。
- 负载均衡：支持客户端负载均衡（Ribbon、Spring Cloud LoadBalancer）和网关负载均衡。
- 断路器：提高系统的稳定性，防止级联故障（Hystrix、Resilience4j）。
- 智能路由与 API 网关：提供统一的请求入口与路由控制（Spring Cloud Gateway）。
- 分布式消息传递：实现微服务间异步通信（Spring Cloud Stream、RabbitMQ、Kafka）。
SpringCloud 通过这些模块组合，帮助开发者快速构建可扩展、可维护的微服务系统。
SpringCloud 的版本选型
在使用
Spring Cloud与Spring Cloud Alibaba时，版本选型的正确性直接决定了项目的兼容性与稳定性。不同版本之间的依赖关系错配，可能导致启动异常、依赖冲突、注解失效等问题。因此在选型时应遵循以下顺序：
首先确定 JDK 版本
确定 Spring Boot 版本
根据 Spring Boot 版本选择 Spring Cloud
最后确定 Spring Cloud Alibaba 版本
版本选择总结这里先说一下最终确定的版本，后面的内容可以略过。
⚠️ 注意：这里的版本与视频教程所用的版本不太一样，我是直接使用的官网推荐的版本。
组件 推荐版本 说明 Java 21 长期支持版本，兼容 Spring Boot 3.x Maven 3.9.9 兼容新版依赖管理 Spring Boot 3.2.4 稳定成熟的生产可用版本 Spring Cloud 2023.0.1 (Leyton) 与 Boot 3.2.x 匹配 Spring Cloud Alibaba 2023.0.1.0 官方推荐版本 MySQL 9.2.0 支持新 JDBC 驱动 JDK 版本选择
- 新版 Spring Boot 与 Spring Cloud 对 JDK 要求较高。
- Spring Boot 3.x 开始仅支持 JDK 17 及以上，推荐使用 JDK 21 作为长期支持版本。
Spring Boot 版本选择
- Spring Boot 是所有微服务的基础，其他框架均需与之兼容。
- 可通过以下渠道查看最新版本及支持情况
- GitHub 地址：Spring Boot Releases
- Spring官网地址：Spring Boot
- 官方推荐：Spring Boot 3.0 Release Notes
- 结论：建议使用 JDK 17+，Spring Boot 3.x 以上版本。
Spring Cloud 版本选择
- Spring Cloud 版本以 “Release Train（发行列车）” 命名，例如
2023.0.x (Leyton)、2024.0.x (Moorgate)等。- 每个 Release Train 都只兼容特定的 Spring Boot 版本。
- 官方兼容版本：兼容版本
- 官网地址：
- GitHub 地址：Spring Cloud
- Spring官网地址：Spring Cloud
Spring Cloud Alibaba 版本选择
- Spring Cloud Alibaba 在 Spring Cloud 之上扩展了 Nacos、Sentinel、Seata、RocketMQ 等组件的支持，因此必须匹配其底层 Spring Cloud 版本。
- Spring官网地址：Spring Cloud Alibaba（注意官网可能未更新到最新版本）
- GitHub 地址：Spring Cloud Alibaba
- SpringCloud Alibaba官网版本说明：Spring Cloud Alibaba 版本说明
组件的停更、升级与替换
SpringCloud 各组件主要功能包括服务发现、配置管理、负载均衡、网关、消息总线等。随着版本迭代，有些组件会被弃用或替换为更优方案。
例如，Spring Cloud Greenwich 及以前版本的某些组件在新版本中已停止维护，官方推荐迁移到更新的替代方案以获得更好的性能和安全性。
官方说明参考：Spring Cloud Blog
组件的功能组件的选择
- 老版本选择（不再推荐）
- 新版本选择（推荐）
Base工程模块构建
- 本节主要搭建学习
SpringCloud的基础模块，包含：服务提供者和服务调用者。- 项目结构说明：
- 一个工程：首先创建一个Maven项目（
cloud2025）作为父工程，用来聚合子模块并统一管理依赖版本。- 两个子模块：
- 微服务提供者—支付模块：
cloud-provider-payment8001- 微服务调用者—订单模块：
cloud-consumer-order80- 需求：客户端请求订单服务，创建订单；订单服务调用支付服务，完成支付。
创建父工程
Mapper一键生成
Rest通用Base工程构建
为什么引入微服务
controller中的硬编码问题
在传统单体或简单服务调用中，Controller 中常将服务的 IP 地址和端口号硬编码，例如：订单微服务直接调用支付微服务时指定固定地址。这样做存在诸多问题：
- 服务不可用风险
- 如果支付微服务的 IP 或端口发生变化，订单微服务将无法访问，需要手动修改硬编码信息。
- 无法实现负载均衡
- 当系统存在多个订单或支付实例时，硬编码无法支持请求均衡分发，影响系统性能和可靠性。
- 运维与扩展复杂
系统需要扩展更多实例以支持高并发时，硬编码服务地址会增加维护成本，增加出错风险。
解决方案在微服务架构中，引入服务发现（Service Discovery） 功能，使服务能够动态注册与发现。
- 调用方不再依赖硬编码地址
- 自动支持负载均衡
- 系统可动态扩展和缩减服务实例，提高可靠性与可维护性
服务注册与发现
CAP理论
CAP 理论指出：在一个分布式系统中，
一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）三者无法同时完美满足，系统在网络分区发生时，最多只能同时保证其中两项。
C（Consistency）强一致性：所有节点在同一时刻看到的数据是一致的。
A（Availability）可用性：每个请求都能在有限时间内获得非错误响应。
P（Partition tolerance）分区容错性：系统在出现网络分区或节点故障时，仍能继续提供服务。
注意
- 网络分区：指分布式系统中，部分节点之间由于网络中断或延迟无法通信，形成孤立分区。
- 分区容错性：即使系统发生网络分区，也能保证整体服务不崩溃，或在策略允许范围内继续运行（如选择保证 C 或 A）。
- CAP 并非三选二，而是“分区发生时在 C 与 A 之间取舍”。在分布式系统中，P 是必须的前提，因为网络分区无法避免。CAP 的真正含义是：当系统出现分区（P）时，你必须在 一致性（C） 和 可用性（A） 之间做出权衡。
根据 CAP 原理，注册中心的架构可以分为三类。虽然理论上分布式系统必须满足 P，但在教学或架构对比中，通常仍将系统分为三类，以便说明 CAP 的取舍关系。
CA（强一致性 + 可用性）
- 系统在任意时刻都能保证数据一致，同时确保服务可用。
- 这种架构仅存在于没有分区问题的理想环境（如单机系统或强一致的集中式系统）。一旦出现网络分区，CA 系统将无法同时保持一致性与可用性，因此不适用于分布式系统。
- 示例（单机场景）：银行柜台系统
- 在同一数据库中处理账户存取款，所有操作立即生效（强一致性）
- 用户请求能即时响应（可用性）
- 不存在网络分区问题（因此能同时满足 CA）
CP（强一致性 + 分区容错性）
- 系统在出现网络分区时，仍然保证数据一致性，不返回错误或过期数据。
- 可能为了保证一致性而暂时降低可用性（部分请求被拒绝或延迟）。
- 示例：合同签署系统
- 各地节点需保持合同状态一致
- 当网络分区时，不允许节点独立修改合同，防止数据冲突
- 系统可能暂时无法响应部分用户请求
AP（可用性 + 分区容错性）
- 系统在网络分区时仍能响应请求，保持高可用性。
- 为保证持续服务，可能暂时放弃强一致性，允许短时间的数据差异。
- 示例：电商网站库存系统
- 即使节点间通信异常，用户仍可下单或查询库存
- 不同节点的库存数据可能短暂不一致，但整体服务不受影响
注意在 CAP 理论中，P（Partition tolerance）是必须满足的，这是 CAP 理论的核心之一。
为什么必须满足 P（分区容错性）？
- 网络分区不可避免
- 在分布式系统中，节点间通信总可能出现网络延迟、丢包、宕机等问题
- 这种网络分区在大型系统中是正常现象，无法完全避免
- 系统必须有策略应对分区
- 如果不考虑分区（P），系统在节点网络中断时就可能崩溃或出现不可预测行为
- 因此，CAP 理论认为分布式系统至少必须保证分区容错性（P）
各注册中心异同点
- 特点：保证系统可用性和分区容错性，但牺牲强一致性
- 行为：
- 网络分区时，每个 Eureka 节点可能有不同的注册信息
- 调用服务可能在某些节点查不到，但在其他节点能查到
- 保证服务可用，但数据不完全一致
- 特点：保证强一致性和分区容错性，但可用性可能降低
- 行为：
- 网络分区时必须拒绝请求以保证一致性
- Consul 使用 Raft 算法，写入注册信息必须超过半数节点成功才能生效
- Leader 选举期间可能导致注册中心暂不可用
- 默认模式：AP（可用性 + 分区容错性），保证系统可用
- 可切换模式：CP（强一致性 + 分区容错性），满足特定业务场景对一致性要求高的需求
- 优势：
- 使用简单、灵活
- 同时支持服务注册与配置管理
- 支持动态切换架构模式，适应不同业务需求
Eureka- 停止维护
- 官方文档：Eureka Wiki
- Eureka 已经停止活跃更新，存在安全与兼容性问题。
- 初学者门槛高
- 配置和部署复杂，不够友好。
- 耦合度高
- Eureka 本身也是一个微服务，需要开发者自行部署和管理。
- 阿里巴巴 Nacos 的崛起
- Nacos 提供了更易用、更灵活的服务注册与配置管理方案，逐渐成为国内微服务注册中心首选。
Consul
Nacos
服务负载均衡
什么是负载均衡
负载均衡（Load Balancing）是一种常见的系统设计策略，用于将请求或任务合理分配到多个服务器或实例上，以提升系统的性能、可用性和稳定性。
在微服务架构中，负载均衡分为两种类型：
服务端负载均衡（Server-Side Load Balancing）
请求先到达一个负载均衡服务器（如 Nginx、HAProxy），由它根据规则（轮询、权重、最少连接数等）将请求分发到后端服务实例。
客户端负载均衡（Client-Side Load Balancing）
客户端（如微服务 A）在调用另一个服务（如微服务 B）时，自己从注册中心获取所有可用实例信息，并通过算法（如随机、轮询）决定调用哪一个实例。Spring Cloud 的
LoadBalancer就属于这一类。
LoadBalancer
配置中心
分布式下的配置问题
- 微服务架构意味着将单体应用拆分为多个独立的小型服务，每个服务只负责特定业务功能。随着服务数量的增加，系统中的服务实例可能成百上千。
- 每个服务都需要独立的配置信息（如数据库、注册中心、消息队列等）才能正常运行。如果每个服务都维护自己的配置文件，不仅冗余严重，而且维护成本极高。尤其是当多个服务使用相同的技术栈（如相同数据库或中间件）时，大部分配置内容完全一致，只有少量差异。
- 以数据库配置为例，假设多个服务都连接同一个数据库，当数据库主机或密码变更时，我们希望只修改一次配置，就能让所有服务同时生效。
- 然而，在传统方式中，每个微服务都带有自己的
application.yml或application.properties文件。这种方式在少量服务时还能接受，但当系统规模扩大到上百个微服务时，分散管理这些配置文件将变得异常复杂且容易出错。因此，微服务架构中必须引入一种集中化、动态化的配置管理机制——配置中心（Configuration Center）。它可以统一存储、动态刷新、集中管理系统中的所有配置项，从而实现“一处修改，全局生效”的效果。
Consul
Nacos
远程服务调用
为什么使用OpenFeign替代RestTemplate
在微服务架构中，服务之间通常通过 HTTP 进行通信。虽然
RestTemplate能够实现服务调用，但其使用方式较为繁琐、可维护性较差。Spring Cloud 推荐使用OpenFeign来替代RestTemplate，原因主要包括以下几点：
简化代码，提升可读性
使用
RestTemplate时，开发者需要手动构造 URL、设置请求头、序列化参数并处理异常，代码冗长且容易出错。而*OpenFeign采用声明式调用方式，只需定义一个接口并通过注解（如@FeignClient、@GetMapping、@PostMapping）标明请求信息即可*。框架会自动生成底层 HTTP 调用逻辑，大幅减少模板化代码，让服务调用更直观、清晰。提高开发效率与可维护性
OpenFeign 对
RestTemplate与Ribbon进行了高度封装，不仅保留了 HTTP 调用的灵活性，还实现了服务发现与负载均衡。这种面向接口编程的方式使得服务间依赖更解耦，开发者只需关注业务逻辑本身，无需手动维护服务地址或处理复杂的网络请求细节。内置负载均衡支持
OpenFeign内置整合了Ribbon（在新版本中则使用 Spring Cloud LoadBalancer），能够自动从注册中心拉取可用服务列表，并在客户端实现请求的负载均衡。相比之下，RestTemplate需要手动配置@LoadBalanced并注入负载均衡逻辑，而 OpenFeign 在声明层即可自动完成，使用更优雅。统一的服务调用体验
OpenFeign支持通过配置文件或拦截器统一设置请求头、超时策略、重试机制、日志级别等，便于在分布式系统中统一规范服务间调用行为，增强系统的可维护性与可观测性。
OpenFeign
服务熔断和降级
分布式系统面临的问题：复杂分布式体系结构中的应用程序有数十个依赖关系，每个依赖关系在某些时候将不可避免地失败。
基础概念
- 多个微服务之间调用的时候，假设微服务A调用微服务B和微服务C，微服务B和微服务C又调用其它的微服务，这就是所谓的“扇出”。
- 如果扇出的链路上某个微服务的调用响应时间过长或者不可用，对微服务A的调用就会占用越来越多的系统资源，进而引起系统崩溃，所谓的“雪崩效应”。
- 对于高流量的应用来说，单一的后端依赖可能会导致所有服务器上的所有资源都在几秒钟内饱和。比失败更糟糕的是，这些应用程序还可能导致服务之间的延迟增加，备份队列，线程和其他系统资源紧张，导致整个系统发生更多的级联故障。这些都表示需要对故障和延迟进行隔离和管理，以便单个依赖关系的失败，不能取消整个应用程序或系统。
- 所以，通常当你发现一个模块下的某个实例失败后，这时候这个模块依然还会接收流量，然后这个有问题的模块还调用了其他的模块，这样就会发生级联故障，或者叫雪崩。
- 服务降级，说白了就是一种服务托底方案，如果服务无法完成正常的调用流程，就使用默认的托底方案来返回数据。
- 例如，在商品详情页一般都会展示商品的介绍信息，一旦商品详情页系统出现故障无法调用时，会直接获取缓存中的商品介绍信息返回给前端页面。
- 在分布式与微服务系统中，如果下游服务因为访问压力过大导致响应很慢或者一直调用失败时，上游服务为了保证系统的整体可用性，会暂时断开与下游服务的调用连接。这种方式就是熔断。
- 类比保险丝达到最大服务访问后，直接拒绝访问，拉闸限电，然后调用服务降级的方法并返回友好提示。
- 服务限流就是限制进入系统的流量，以防止进入系统的流量过大而压垮系统。其主要的作用就是保护服务节点或者集群后面的数据节点，防止瞬时流量过大使服务和数据崩溃（如前端缓存大量失效），造成不可用；还可用于平滑请求，类似秒杀高并发等操作，严禁一窝蜂的过来拥挤，大家排队，一秒钟N个，有序进行。
- 限流算法有两种，一种就是简单的请求总量计数，一种就是时间窗口限流（一般为1s），如令牌桶算法和漏牌桶算法就是时间窗口的限流算法。
- 有点类似于系统的垂直拆分，按照一定的规则将系统划分成多个服务模块，并且每个服务模块之间是互相独立的，不会存在强依赖的关系。如果某个拆分后的服务发生故障后，能够将故障产生的影响限制在某个具体的服务内，不会向其他服务扩散，自然也就不会对整体服务产生致命的影响。
- 互联网行业常用的服务隔离方式有：线程池隔离和信号量隔离。
- 整个系统采用分布式和微服务架构后，系统被拆分成一个个小服务，就会存在服务与服务之间互相调用的现象，从而形成一个个调用链。
- 形成调用链关系的两个服务中，主动调用其他服务接口的服务处于调用链的上游，提供接口供其他服务调用的服务处于调用链的下游。服务超时就是在上游服务调用下游服务时，设置一个最大响应时间，如果超过这个最大响应时间，下游服务还未返回结果，则断开上游服务与下游服务之间的请求连接，释放资源。
如何解决服务雪崩
- 有问题的节点，快速熔断（快速返回失败处理或者返回默认兜底数据【服务降级】）。
- “断路器”本身是一种开关装置，当某个服务单元发生故障之后，通过断路器的故障监控（类似熔断保险丝），向调用方返回一个符合预期的、可处理的备选响应(FallBack)，而不是长时间的等待或者抛出调用方无法处理的异常，这样就保证了服务调用方的线程不会被长时间、不必要地占用，从而避免了故障在分布式系统中的蔓延，乃至雪崩。
Hystrix
- Hystrix是一个用于处理分布式系统的延迟和容错的开源库。在分布式系统里，许多依赖不可避免的会调用失败，比如：超时、异常等。
- Hystrix能够保证在一个依赖出问题的情况下，不会导致整体服务失败，避免级联故障，以提高分布式系统的弹性。目前也进入维护模式。
