Spring Cloud 整体架构与模块总览
Spring Cloud 是一套构建在 Spring Boot 之上的微服务解决方案，把服务注册、负载均衡、网关、配置、消息等"分布式系统通用问题"沉淀为一组开箱即用的组件。理解它的整体架构，是驾驭后续每个模块的前提。
微服务要解决的问题
把单体拆成微服务后，每个分布式问题都变成了"标准问题"：
服务发现：实例在哪？ → 注册中心
负载均衡：选哪个实例？ → LoadBalancer
路由转发：请求怎么进门？ → Gateway
远程调用：怎么优雅调用？ → OpenFeign
配置管理：配置怎么统一？ → Config / Nacos
容错降级：服务挂了怎么办？ → Sentinel / Resilience4j
消息通信：异步怎么解耦？ → Bus / StreamSpring Cloud 的价值：把每个问题都变成"引入一个依赖 + 写几行配置"。
Netflix 时代 vs Alibaba 时代
Spring Cloud 经历了两次组件体系的更迭。
Netflix OSS 时代（2015 — 2019）
最早的 Spring Cloud 以 Netflix 开源组件为核心：
| 问题 | Netflix 组件 | 现状 |
|---|---|---|
| 服务发现 | Eureka | 2.0 停止维护，1.x 仅维护 |
| 负载均衡 | Ribbon | 进入维护模式 |
| 熔断降级 | Hystrix | 停止开发 |
| 网关 | Zuul 1.x | 被 Gateway 取代 |
| 配置中心 | Spring Cloud Config | 继续使用 |
| 分布式配置/服务总线 | Bus | 保留（部分） |
Netflix 组件大多"进入维护模式"：可用但不再演进。社区逐步转向两个替代方向——Spring 官方自研（LoadBalancer、Gateway、Resilience4j 生态）与 Alibaba 生态（Nacos、Sentinel）。
Alibaba 时代（2019 至今）
Spring Cloud Alibaba 成为国内微服务的主流选择：
| 问题 | Alibaba 组件 | 特点 |
|---|---|---|
| 服务发现 + 配置 | Nacos | 一体化：注册中心 + 配置中心，AP/CP 可切换 |
| 熔断限流 | Sentinel | 丰富的流控规则，与网关/Feign 深度整合 |
| RPC 调用 | Dubbo / OpenFeign | 阿里内部长期验证 |
| 分布式事务 | Seata | AT/TCC/SAGA/XA 多模式 |
| 定时任务 | XXL-Job / SchedulerX | 分布式调度 |
两代对比总结
| 维度 | Netflix 时代 | Alibaba 时代 |
|---|---|---|
| 注册中心 | Eureka（AP） | Nacos（AP/CP 可选，含配置中心） |
| 负载均衡 | Ribbon | Spring Cloud LoadBalancer |
| 熔断 | Hystrix | Sentinel / Resilience4j |
| 网关 | Zuul | Spring Cloud Gateway |
| 配置 | Config + Bus | Nacos Config |
| 活跃度 | 维护模式 | 活跃演进 |
选型结论：新项目主流是 Spring Cloud + Spring Cloud Alibaba（Nacos + Sentinel + OpenFeign + Gateway + Seata）。
Servlet 栈 vs Reactive 栈
Spring Cloud 同一套能力有两套实现路线：
Servlet 栈（阻塞式，默认主流）
Spring MVC + Tomcat
请求 → 线程池 → 阻塞处理 → 响应- 每请求占用一个线程，线程池大小受限
- 模型简单、生态成熟、调试容易
- Spring Cloud 传统组件（LoadBalancer 阻塞版、OpenFeign、Config）都在此栈
Reactive 栈（非阻塞）
Spring WebFlux + Netty
请求 → 事件循环 → 非阻塞处理 → 响应- 少量线程支撑高并发（事件驱动）
- 依赖全链路非阻塞（数据库、HTTP 客户端都要 Reactive 化）
- Gateway 本身基于 WebFlux/Netty 实现
对比表
| 对比项 | Servlet 栈 | Reactive 栈 |
|---|---|---|
| 编程模型 | 阻塞同步 | 响应式（Mono/Flux） |
| 高并发能力 | 依赖线程池（有上限） | 事件循环（吞吐更高） |
| 生态成熟度 | 最成熟 | 仍在补齐（JDBC 等阻塞点） |
| 学习成本 | 低 | 高（响应式思维） |
| Spring Cloud 支持 | 完整 | Gateway、LoadBalancer Reactive 版支持；OpenFeign 不支持 |
常见误区：Gateway 用 Reactive 栈不代表整个系统必须 Reactive。Gateway 是独立网关进程，业务服务仍可用 Servlet 栈，两边通过 HTTP 通信，互不影响。
模块全景图
┌─────────────────────┐
│ Spring Cloud │
│ Gateway │ ← 统一入口（Reactive）
└──────────┬──────────┘
│ 路由/限流
┌──────────────────────────┼──────────────────────────┐
▼ ▼ ▼
┌───────────────┐ ┌───────────────┐ ┌──────────────┐
│ OpenFeign │ │ Config │ │ Bus / Stream │
│ 声明式调用 │ │ 配置中心 │ │ 事件/消息 │
└──────┬────────┘ └──────┬────────┘ └──────────────┘
▼ ▼
┌───────────────┐ ┌───────────────┐
│ LoadBalancer │ │ Sentinel │
│ 负载均衡 │ │ 熔断限流 │
└──────┬────────┘ └──────────────┘
▼
┌─────────────────────────────────────┐
│ Nacos（注册中心 + 配置中心） │
└─────────────────────────────────────┘| 模块 | 能力 | 关键接口/组件 |
|---|---|---|
| spring-cloud-commons | 通用抽象 | DiscoveryClient、LoadBalancer、ServiceInstance |
| spring-cloud-loadbalancer | 客户端负载均衡 | ReactorLoadBalancer、ServiceInstanceListSupplier |
| spring-cloud-openfeign | 声明式 HTTP 调用 | @FeignClient、Feign.Builder |
| spring-cloud-gateway | 网关路由 | Route、Predicate、Filter |
| spring-cloud-config | 配置中心 | EnvironmentRepository、PropertySource |
| spring-cloud-bus | 消息总线 | BusBridge、远程事件 |
| spring-cloud-stream | 事件驱动 | Binder、MessageChannel |
| spring-cloud-commons 的 SPI | 扩展接入 | 各实现（Nacos/Eureka/Consul） |
一次请求的完整链路
客户端 → Gateway（路由+鉴权+限流）
→ OpenFeign（@FeignClient 动态代理）
→ LoadBalancer（从 Nacos 拉实例列表，选一个）
→ 目标服务实例
→ Sentinel 保护（限流/降级）
→ 业务逻辑 → 数据库/消息链路中每个环节都有对应组件与可替换实现，这也是 Spring Cloud "抽象 + SPI"设计的价值：换注册中心、换熔断组件，业务代码基本不动。
常见问题
- Spring Cloud 与 Spring Boot 版本如何对应？ 用 BOM 管理，见版本治理文档；错配会直接启动失败。
- Gateway 是 Reactive 的，业务服务必须 Reactive 吗？ 不必。Gateway 独立运行，与 Servlet 栈服务通过 HTTP 通信。
- Nacos 能同时替代 Eureka 和 Config 吗？ 能。Nacos 兼具注册中心与配置中心能力，是 Alibaba 方案的核心。
- Ribbon 还能用吗？ 可用但维护模式，新项目用 Spring Cloud LoadBalancer。