Spring Cloud技术演进与选型
Spring Cloud 不是一个单独组件，而是一套微服务治理能力的集合。学习它时，最容易犯的错误是只背组件名：Eureka、Ribbon、Feign、Hystrix、Zuul、Gateway、Nacos、Sentinel。真正要掌握的是每类组件解决什么问题、老技术和新技术为什么替换、替换以后原理有没有变化。
先记住一句话：
Spring Cloud 的核心问题一直没变：服务怎么发现、请求怎么调用、流量怎么进入、故障怎么隔离、配置怎么管理、调用链怎么排查。变化的是实现这些能力的组件。
Spring Cloud 解决的微服务问题
mermaid
flowchart TD
A["微服务数量变多"] --> B["服务地址会变化"]
A --> C["服务之间要调用"]
A --> D["外部流量要统一入口"]
A --> E["下游故障会扩散"]
A --> F["配置要集中管理"]
A --> G["跨服务问题要排查"]
B --> H["注册中心"]
C --> I["OpenFeign / HTTP Client"]
C --> J["负载均衡"]
D --> K["Gateway / Zuul"]
E --> L["Sentinel / Resilience4j / Hystrix"]
F --> M["Config / Nacos / Apollo"]
G --> N["Micrometer Tracing / OpenTelemetry / SkyWalking"]学习顺序应该按问题推进，而不是按组件名字推进。
经典技术栈和当前技术栈
经典 Netflix 体系
早期 Spring Cloud 常见组合：
text
Eureka + Ribbon + Feign + Hystrix + Zuul + Spring Cloud Config + Sleuth这套组合奠定了微服务治理的基本模型：
- Eureka：服务注册发现。
- Ribbon：客户端负载均衡。
- Feign：声明式 HTTP 调用。
- Hystrix：熔断、隔离、降级。
- Zuul：API 网关。
- Spring Cloud Config：配置中心。
- Sleuth：链路追踪埋点。
当前主流技术栈
现在项目更常见的组合：
text
Nacos / Eureka / Consul
+ Spring Cloud LoadBalancer
+ OpenFeign / WebClient
+ Spring Cloud Gateway
+ Sentinel / Resilience4j
+ Nacos Config / Spring Cloud Config / Apollo
+ Micrometer Tracing / OpenTelemetry / SkyWalking如果是 Spring Cloud Alibaba 体系，常见是：
text
Nacos + OpenFeign + Spring Cloud LoadBalancer + Gateway + Sentinel + Nacos Config如果是偏 Spring 官方生态，常见是：
text
Eureka / Consul + OpenFeign + Spring Cloud LoadBalancer + Gateway + Resilience4j + Spring Cloud Config新旧组件对照表
| 能力 | 经典技术 | 当前常用技术 | 为什么会变化 |
|---|---|---|---|
| 服务注册发现 | Eureka | Nacos、Consul、Eureka、Spring Cloud Kubernetes | 部署形态从虚拟机走向容器和云原生，注册中心需要配置管理、命名空间、集群、元数据治理 |
| 远程调用 | Feign | OpenFeign、WebClient、RestClient | Feign 思想仍常用，但底层 HTTP 客户端、可观测性、响应式支持在变化 |
| 负载均衡 | Ribbon | Spring Cloud LoadBalancer | Ribbon 属于 Netflix 老体系，新项目使用 Spring Cloud 官方负载均衡抽象 |
| 网关 | Zuul 1.x | Spring Cloud Gateway | Gateway 基于 WebFlux/Reactor Netty，适合非阻塞入口流量治理 |
| 熔断降级 | Hystrix | Sentinel、Resilience4j | Hystrix 停止活跃维护，Sentinel 更偏流量治理，Resilience4j 更轻量模块化 |
| 配置中心 | Spring Cloud Config | Nacos Config、Apollo、Spring Cloud Config | 配置中心从“拉 Git 配置”演进到配置治理、灰度、权限、审计、动态推送 |
| 链路追踪 | Spring Cloud Sleuth | Micrometer Tracing、OpenTelemetry、SkyWalking | 观测体系统一到 metrics、tracing、logging，并向 OpenTelemetry 标准靠拢 |
| 消息事件 | Spring Cloud Bus、Stream | Spring Cloud Stream、Kafka/RabbitMQ、事件驱动架构 | 微服务除了同步调用，也需要异步事件和配置刷新广播 |
| 部署治理 | 传统 VM + 注册中心 | Kubernetes、Service Mesh、Spring Cloud Kubernetes | 云原生环境下，服务发现和流量治理可能部分下沉到平台层 |
注意：新技术不是把旧原理推翻了。比如 Ribbon 换成 LoadBalancer，核心仍然是“从实例列表里选一个”；Zuul 换成 Gateway，核心仍然是“匹配路由、执行过滤器、转发请求”。
服务注册发现对比
注册中心的共同原理
注册中心都解决一个问题：服务实例地址不能写死。
mermaid
flowchart TD
A["服务提供者启动"] --> B["注册服务名、IP、端口、元数据"]
B --> C["注册中心保存实例列表"]
D["服务消费者"] --> E["按服务名查询实例"]
E --> F["本地缓存实例列表"]
F --> G["负载均衡选择实例"]共同概念：
- Service：逻辑服务名，例如
order-service。 - Instance：服务实例，例如
192.168.1.10:8081。 - Heartbeat：心跳，证明实例还活着。
- Metadata：元数据，例如版本、机房、权重、灰度标识。
- Health Check：健康检查，判断实例是否可用。
Eureka、Nacos、Consul、Zookeeper 比较
| 对比项 | Eureka | Nacos | Consul | Zookeeper |
|---|---|---|---|---|
| 定位 | Spring Cloud Netflix 注册中心 | 注册中心 + 配置中心 + 服务治理 | 服务发现 + KV + 健康检查 | 分布式协调组件 |
| 一致性倾向 | 偏 AP，可用性优先 | 支持临时/持久实例，不同场景策略不同 | 偏 CP，健康检查能力强 | CP，强一致协调 |
| 配置中心 | 不提供 | 提供 | KV 能力可做配置 | 不适合作为业务配置中心 |
| 健康检查 | 客户端心跳为主 | 心跳、健康状态、服务订阅 | 健康检查成熟 | 临时节点感知会话 |
| Spring Cloud 适配 | 经典老项目常见 | Spring Cloud Alibaba 常见 | 官方生态可用 | 现在较少作为 Spring Cloud 注册中心 |
| 适合场景 | 老 Spring Cloud Netflix 项目 | 国内微服务、注册配置一体化 | 多语言、基础设施治理 | 分布式锁、选主、协调 |
选型建议：
- 老项目已有 Eureka：理解并维护，不必为了换而换。
- 新项目使用 Spring Cloud Alibaba：优先 Nacos。
- 多语言基础设施治理：可以评估 Consul。
- Zookeeper 更适合协调类场景，不建议新项目把它当主要微服务注册中心。
远程调用技术对比
Spring Cloud 里的服务调用本质大多是 HTTP 调用。
mermaid
flowchart TD
A["业务代码"] --> B{"调用方式"}
B -->|"OpenFeign"| C["接口代理生成 HTTP 请求"]
B -->|"RestTemplate"| D["手写命令式 HTTP 请求"]
B -->|"WebClient"| E["响应式非阻塞 HTTP 请求"]
C --> F["服务发现和负载均衡"]
D --> F
E --> F
F --> G["HTTP Client 发请求"]| 调用方式 | 特点 | 优点 | 风险 |
|---|---|---|---|
| RestTemplate | 命令式 HTTP 客户端 | 简单直观，老项目常见 | 手写 URL 和参数较多，维护成本高 |
| OpenFeign | 声明式 HTTP 客户端 | 像接口一样调用，适合微服务内部调用 | 容易被误当成本地方法，忽略超时和批量 |
| WebClient | 响应式 HTTP 客户端 | 非阻塞，适合高并发和流式场景 | 对响应式编程理解要求更高 |
| Dubbo/gRPC | RPC 框架，不属于 Spring Cloud HTTP 主线 | 性能和契约能力强 | 技术栈不同，治理方式不同 |
新手最重要的是理解：Feign 不是本地调用。它只是把 HTTP 调用包装成接口形式。
负载均衡技术对比
负载均衡解决的是“实例列表中选哪个”。
mermaid
flowchart TD
A["实例列表"] --> B["实例 1"]
A --> C["实例 2"]
A --> D["实例 3"]
E["LoadBalancer"] --> F{"选择策略"}
F --> G["轮询"]
F --> H["随机"]
F --> I["权重"]
F --> J["同机房优先"]| 对比项 | Ribbon | Spring Cloud LoadBalancer |
|---|---|---|
| 时代 | 经典 Spring Cloud Netflix | 当前 Spring Cloud 推荐 |
| 核心职责 | 客户端选择实例 | 客户端选择实例 |
| 常见算法 | 轮询、随机、重试、区域优先等 | 轮询、随机、自定义策略 |
| 扩展方式 | IRule | ServiceInstanceListSupplier、ReactorServiceInstanceLoadBalancer |
| 适合项目 | 老项目维护 | 新项目选型 |
无论用 Ribbon 还是 LoadBalancer，调用链路里的位置都一样：
text
服务名 -> 实例列表 -> 选择实例 -> HTTP 调用网关技术对比
网关解决外部流量入口问题。
mermaid
flowchart TD
A["客户端"] --> B["网关"]
B --> C["鉴权"]
C --> D["限流"]
D --> E["路由匹配"]
E --> F["转发到后端服务"]| 对比项 | Zuul 1.x | Spring Cloud Gateway | Nginx / Ingress |
|---|---|---|---|
| 类型 | Java 网关，Servlet 阻塞模型 | Java 网关，WebFlux 非阻塞模型 | 通用反向代理/入口 |
| Spring Cloud 集成 | 经典 Netflix 体系 | 当前主流 Spring Cloud 网关 | 偏基础设施层 |
| 路由能力 | 支持服务名路由 | Route、Predicate、Filter 更系统 | 强大的代理能力 |
| 扩展方式 | Zuul Filter | GlobalFilter、GatewayFilter | Lua、模块、Ingress 规则 |
| 适合场景 | 老项目维护 | 微服务网关、鉴权、限流、灰度 | 静态资源、七层代理、K8s 入口 |
新项目通常用 Gateway；老项目遇到 Zuul 要理解 Filter 思想。Nginx 和 Gateway 不是非此即彼，常见部署是：
text
公网 -> Nginx / Ingress -> Spring Cloud Gateway -> 后端微服务容错治理技术对比
容错治理解决的是下游慢、失败、流量过大时如何保护系统。
mermaid
flowchart TD
A["请求进入"] --> B{"是否超过限流阈值"}
B -->|"是"| C["直接拒绝"]
B -->|"否"| D{"熔断器是否打开"}
D -->|"打开"| E["快速降级"]
D -->|"关闭"| F["调用下游"]
F --> G{"是否超时或异常"}
G -->|"是"| H["记录失败并触发降级"]
G -->|"否"| I["正常返回"]| 对比项 | Hystrix | Sentinel | Resilience4j |
|---|---|---|---|
| 定位 | 熔断、隔离、降级 | 流量治理、限流、熔断、热点参数、系统保护 | 轻量熔断、限流、重试、隔离组件库 |
| 时代 | Netflix 老方案 | Spring Cloud Alibaba 常见 | Spring Cloud CircuitBreaker 常见 |
| 隔离方式 | 线程池隔离、信号量隔离 | 并发线程数、规则控制 | Bulkhead、ThreadPoolBulkhead |
| 限流能力 | 弱 | 强 | 有 RateLimiter |
| 控制台 | Hystrix Dashboard | Sentinel Dashboard | 通常结合 Actuator/Micrometer |
| 适合场景 | 老项目维护 | 国内微服务、流量治理要求强 | Spring 官方生态、轻量组合 |
要理解的是思想：
- 限流：流量太多，先挡住。
- 熔断：下游不健康，暂时别调用。
- 降级：失败时返回兜底。
- 隔离：一个依赖出问题，不要拖垮全部线程。
- 重试：只处理短暂失败，并且必须限制次数。
配置中心技术对比
配置中心解决多服务、多环境配置集中管理。
| 对比项 | Spring Cloud Config | Nacos Config | Apollo | Consul KV |
|---|---|---|---|---|
| 存储方式 | Git 仓库常见 | 数据库 | 数据库 | KV 存储 |
| 动态刷新 | 配合 Bus/Actuator | 原生推送和监听 | 原生推送和灰度能力强 | Watch 机制 |
| 权限审计 | 依赖外部平台和流程 | 管理端支持 | 比较完善 | 依赖 Consul 管理 |
| 适合场景 | Spring 官方生态、GitOps 思路 | 注册配置一体化 | 大型配置治理、灰度发布 | 基础设施 KV |
配置中心要重点关注：
- 配置命名规范。
- 环境隔离。
- 权限控制。
- 审计和回滚。
- 动态刷新边界。
- 敏感配置加密。
链路追踪技术对比
链路追踪解决“请求经过多个服务后怎么排查”的问题。
mermaid
flowchart TD
A["Gateway 生成 traceId"] --> B["order-service"]
B --> C["user-service"]
B --> D["payment-service"]
C --> E["日志和链路平台按 traceId 聚合"]
D --> E| 对比项 | Sleuth | Micrometer Tracing | OpenTelemetry | SkyWalking |
|---|---|---|---|---|
| 定位 | Spring Cloud 老链路追踪方案 | Spring Boot 3 后更常见的观测门面 | 开放标准，跨语言 | APM 平台，探针能力强 |
| 关注点 | traceId/spanId 自动传播 | 和 Micrometer 观测体系整合 | 标准化采集、导出、跨语言 | 调用链、拓扑、指标、告警 |
| 适合项目 | 老 Spring Boot 2 项目 | 新 Spring Boot/Spring Cloud 项目 | 多语言、云原生 | 需要完整 APM 平台 |
链路追踪不是业务功能，但它决定系统出问题时能不能快速定位。
消息事件技术对比
微服务之间不只有同步 HTTP 调用，也会有异步事件。
| 技术 | 作用 | 例子 |
|---|---|---|
| Spring Cloud Stream | 抽象消息中间件，屏蔽 Kafka/RabbitMQ 细节 | 订单事件发送到 Kafka |
| Spring Cloud Bus | 用消息总线广播事件 | 配置刷新广播 |
| Kafka/RabbitMQ/RocketMQ | 真正的消息中间件 | 事件流、业务消息、事务消息 |
异步事件适合：
- 订单创建后通知多个系统。
- 配置刷新广播。
- 数据同步。
- 审计日志。
- 削峰填谷。
不适合：
- 必须立即拿到结果的强同步查询。
- 没有幂等设计的写操作。
- 无法接受最终一致性的业务。
迁移和选型建议
老项目维护
如果项目已经稳定使用：
text
Eureka + Ribbon + Feign + Hystrix + Zuul不要盲目一口气全部替换。先补齐：
- 超时配置。
- 熔断降级。
- 链路追踪。
- 注册中心高可用。
- 网关限流。
- 配置变更流程。
然后按风险逐步迁移。
新项目推荐
如果是新 Spring Cloud Alibaba 项目：
text
Nacos Discovery + Nacos Config
+ OpenFeign
+ Spring Cloud LoadBalancer
+ Spring Cloud Gateway
+ Sentinel
+ Micrometer Tracing / SkyWalking如果是偏 Spring 官方生态：
text
Eureka / Consul
+ Spring Cloud Config
+ OpenFeign
+ Spring Cloud LoadBalancer
+ Spring Cloud Gateway
+ Resilience4j
+ Micrometer Tracing / OpenTelemetry一张图总结
mermaid
flowchart TD
A["经典 Spring Cloud Netflix"] --> B["Eureka"]
A --> C["Ribbon"]
A --> D["Hystrix"]
A --> E["Zuul"]
A --> F["Sleuth"]
G["当前 Spring Cloud"] --> H["Nacos / Consul / Eureka"]
G --> I["Spring Cloud LoadBalancer"]
G --> J["Sentinel / Resilience4j"]
G --> K["Spring Cloud Gateway"]
G --> L["Micrometer Tracing / OpenTelemetry"]
B --> H
C --> I
D --> J
E --> K
F --> L本章小结
Spring Cloud 技术演进的主线不是“哪个组件名字更新了”，而是微服务治理能力的演进。经典 Netflix 技术栈帮助我们理解注册、调用、负载、熔断、网关的基本思想；当前技术栈在云原生、配置治理、流量治理、可观测性方面更完善。学习时要先理解问题和原理，再记组件和配置。