Spring Cloud Alibaba相关知识总结

一、概述

Spring Cloud Alibaba 是国产微服务一站式解决方案，兼容 Spring Cloud 标准，替代了原生 Netflix 套件（Eureka/Ribbon/Hystrix 停更），是国内生产环境主流方案。

核心生态组件：

• Nacos：服务注册发现 + 配置中心（双核心）
• Sentinel：流量控制、熔断降级、系统防护
• Seata：分布式事务解决方案
• RocketMQ：分布式消息队列（异步解耦、最终一致性）
• Gateway：API 网关（Spring Cloud 官方，Alibaba 生态标配）
• Dubbo：高性能 RPC 调用（可替代 OpenFeign）

生产标配：Spring Cloud Alibaba + Nacos + Sentinel + Seata + Gateway。

二、服务注册 Nacos

1、 核心作用

Spring Cloud Alibaba 一站式服务注册发现 + 配置中心，替代 Eureka/Config/Bus，是国内微服务标配。

2、核心功能

• 服务注册 / 发现：替代 Eureka、Consul
• 配置中心：替代 Config + Bus，支持动态刷新、灰度发布
• 分布式配置管理：命名空间、分组、数据隔离

3、关键原理

(1) CAP 理论支持

• 默认 AP 模型：保证服务可用性，适合服务发现
• 可切换 CP 模式：通过集群 Raft 保证一致性，适合配置中心 / CP 场景

(2) 服务注册与心跳机制

• 客户端5s 发送心跳
• 服务端15s 未收到心跳标记不健康
• 30s 未收到心跳剔除实例
• 支持主动下线（优雅停机），实时性远优于 Eureka

(3) 服务发现机制

• 客户端本地缓存服务列表，Nacos 宕机不影响运行
• 基于长轮询推送服务变更，实时性高
• 支持权重、集群、健康状态筛选

(4) 集群原理

• 至少 3 节点，Raft 协议选举 Leader
• 配置数据持久化到 MySQL，服务数据内存 + 磁盘
• 域名 / VIP 统一接入，保证高可用

4、Nacos VS Eureka

(1) 功能定位差异（最关键）

• Eureka：只干服务注册发现一件事。
• Nacos ：注册中心 + 配置中心一体化 。生产环境不用再搭 Config + Bus + RabbitMQ，减少组件、降低运维成本。

(2) CAP 灵活性差异

• Eureka：只能做 AP（高可用），无法保证一致性。
• Nacos ：
  • 服务发现默认 AP：保证服务可用，不雪崩。
  • 配置中心 / CP 服务：切换为 CP（Raft 强一致），保证配置不丢、不乱。

(3) 服务上下线实时性

• Eureka ：
  • 客户端30s 拉取一次注册表
  • 服务下线延迟90s+，容易引发调用失败
• Nacos ：
  • 主动下线 + 长轮询推送
  • 服务上下线秒级感知，实时性极强

(4) 为什么生产环境抛弃 Eureka 用 Nacos？

• Eureka 2.0 闭源，1.0 停更，无官方维护，风险极高。
• Nacos 一套组件搞定注册 + 配置，架构更简单。
• Nacos 集群部署比 Eureka 简单太多，无需复杂配置。
• Nacos 支持权重路由、动态配置、环境隔离、灰度发布，Eureka 做不到。
• 国内云原生、微服务生态全面拥抱 Nacos。

二、 高可用防护 Sentinel

1、核心作用

Sentinel是微服务高可用防护组件 ，替代停更的 Hystrix，实现：限流、熔断降级、系统保护、热点参数限流，是 Spring Cloud Alibaba 标配高可用方案。

一句话总结：防止服务雪崩、保护接口不被打垮、保证核心服务可用。

2、核心功能

• 流量控制（限流）：QPS / 线程数限流、预热、排队、匀速排队
• 熔断降级：慢调用、异常比例、异常数熔断
• 热点参数限流：针对参数（用户 ID / 商品 ID）单独限流
• 系统自适应保护：Load/CPU 高了自动限流
• 授权规则：黑白名单控制

3、底层核心原理

(1) 滑动时间窗口（高并发高性能关键）

• 无侵入式埋点
• 滑动窗口统计请求（高性能）
• 支持持久化规则（Nacos/Push 模式，生产必须用）

滑动时间窗口解决固定窗口临界突刺问题 ，实现高精度、高性能的请求统计，保证限流准确。

(2) 限流算法

• 计数器法：简单 QPS 限制
• 漏桶算法：匀速排队（削峰填谷）
• 令牌桶算法：预热限流（应对突发流量）

(3) 熔断降级策略

Sentinel 是慢启动 + 慢恢复，比 Hystrix 更平滑：

• 慢调用比例：响应超时 > 阈值 → 熔断
• 异常比例：错误率过高 → 熔断
• 异常数：错误次数过多 → 熔断
• 熔断后放半个探测请求，恢复后慢慢放开

三、分布式事务 Seata

1、核心定位

解决 微服务跨库 / 跨服务事务一致性问题，保证最终一致性 / 强一致性。

2、三大角色

• TC（事务协调器）：独立服务，管理全局事务，指挥提交 / 回滚
• TM（事务管理器）：业务服务中的发起方，开启 / 提交 / 回滚全局事务
• RM（资源管理器）：管理每个事务的本地事务，生成 undo_log 回滚日志，执行分支提交 / 回滚

3、三大模式（重点）

(1) AT 模式（最常用，无侵入）

适用场景：普通微服务、单库分表、同类型数据库（MySQL/MySQL）

核心原理：

• 无代码入侵，基于本地事务 + undo_log
• 二阶段提交：一阶段执行提交，二阶段确认 / 回滚

优点：简单、接入成本极低

缺点：必须同类型数据库 ；有行锁，高并发热点数据有性能损耗

(2) TCC 模式（高性能，侵入强）

适用场景：高并发、核心支付、库存、不同数据库

核心原理：

• 手动写三个方法：Try + Confirm + Cancel
• Try：资源预留 / 检查
• Confirm：确认执行
• Cancel：取消回滚

优点：性能极高、无锁、跨库跨语言

缺点：代码入侵大、开发量高、要保证幂等

(3) SAGA 模式（长事务，业务编排）

适用场景：流程长、跨第三方服务、不能回滚的业务

核心：

• 一阶段提交
• 二阶段通过补偿逻辑回滚

优点：适合长事务

缺点：编程复杂、一致性弱

4、生产要点

• AT 模式不能跨不同数据库类型
• 必须建 undo_log 表
• 高并发下用最终一致性（RocketMQ） 替代 Seata 提升性能

四、消息队列 RocketMQ

阿里开源的分布式消息队列 ，微服务架构标配，解决：异步解耦、流量削峰、最终一致性、广播通知。

在 SCA 中：替代 Seata 做高并发最终一致性分布式事务。

1、核心架构

(1) NameServer（注册中心）

• 轻量级注册中心，管理 Broker 集群
• 无集群，单点部署，客户端随机连接

(2) Broker（消息服务器）

• 实际存储消息，主从架构（Master-Slave）
• 支持异步刷盘、同步刷盘

(3) Producer（生产者）

• 发送消息，支持负载均衡、故障延迟

(4) Consumer（消费者）

• 消费消息，支持集群 / 广播两种模式

2、核心特性

(1) 两种消费模式

• 集群模式（默认） ：一条消息只被一个消费者消费，用于负载均衡
• 广播模式 ：一条消息所有消费者都消费，用于通知刷新

(2) 三种消息类型

• 普通消息：异步解耦、削峰
• 顺序消息 ：保证消息严格按顺序消费（如订单状态）
• 事务消息 ：分布式事务最终一致性（面试核心）

(3) 延迟消息（生产神器）

• 支持 18 个固定延迟等级
• 场景：订单超时未支付自动取消
• 不用死循环轮询数据库

(4) 死信队列（DLQ）

• 消费失败 16 次后进入死信队列
• 人工排查处理，防止消息丢失

3、生产高可用部署方案

• NameServer：至少 2 节点，无状态
• Broker ：2 主 2 从，异步刷盘 + 异步复制
• 磁盘：SSD，消息量大扩容
• 消息可靠性：同步刷盘 + 同步双写（金融级）
• 幂等性：消费端必须实现（防重复消费）

4、核心问题

(1) 消息重复消费

一条消息消费多次，导致数据重复 / 错误。

出现该现象的原因是：

• 消费者超时 / 宕机未 ACK
• Broker 重发
• 重试机制触发

解决方案是：必须做幂等性校验

• 全局唯一 ID + MySQL 去重表
• Redis 唯一ID去重
• 状态机判断
• 数据库唯一索引
• 分布式锁

(2) 消息丢失

消息丢失即生产者发了消息，Broker 没收到 / 消费者没收到，数据丢失。

丢失的场景有：

• 生产者 → Broker：网络闪断丢失
• Broker 自身：宕机、未刷盘丢失
• Broker → 消费者：未消费先 ACK 丢失

解决方案如下：

• 生产者：开启事务消息 / 同步发送 + 重试
• Broker：开启同步刷盘 / 主从同步
• 消费者：业务执行成功后再手动 ACK

(3) 消息堆积

消息堆积即消息堆积几十万、几百万，消费跟不上。

出现该现象的原因是：

• 消费者线程太少
• 消费者内部慢调用（SQL / 接口超时）
• 消费者死锁、异常
• 生产流量暴增

解决方案如下：

• 提高消费者线程数
• 扩容消费者实例（超过队列数无效）
• 优化消费逻辑（异步化、慢 SQL 优化）
• 跳过非核心消息（临时抢救）
• 排查死锁 / 异常

(4) 消息顺序错乱

消息顺序错乱即需要顺序执行的消息（订单创建→支付→发货）乱序

出现该现象的原因是：

• 多个队列
• 多个消费者并发消费

解决方案如下：

• 将同一业务 ID（订单 ID）hash 到同一个队列
• 一个队列只配一个消费者线程
• 使用 RocketMQ 顺序消息

(5) 消费者内部慢调用

消费逻辑本身执行太慢，导致消费速度远低于生产速度，引发消息堆积。典型慢调用：

• 慢 SQL（未加索引、连表查询）
• 同步调用第三方 HTTP 接口
• 调用其他微服务接口超时
• 写文件、导出报表等重操作

优化思路是能异步就异步，能缓存就缓存，能批处理就批处理，能剥离就剥离。

具体优化方案如下：

① 同步逻辑 改为 异步化（最有效）

把非核心、非阻塞 的逻辑丢到线程池执行，不阻塞主线程消费

// 坏：同步执行，慢
consumer();
thirdPartyApi();  // 慢接口
saveLog();       // 慢日志

// 好：异步执行
consumer();
executor.submit(() -> thirdPartyApi()); // 丢线程池
executor.submit(() -> saveLog());

② 慢 SQL 优化（最常见）------ 消费逻辑禁止任何慢查询

• 加索引
• 禁止连表查询
• 禁止大事务
• 查询结果丢 Redis 缓存

③ 批量消费（BatchListener）

如果业务允许，批量拉取、批量处理。

• 批量插入 DB
• 批量调用接口

④ 剥离第三方强依赖

不要在消费时同步调用第三方接口：

• 第三方接口也发 MQ 异步调用
• 或者先存库，后台任务慢慢执行

⑤ 调整消费线程数（治标，但必须配）

rocketmq:
  consumer:
    thread-number: 20~64  # 根据CPU核数调整

五、高性能RPC框架Dubbo

1、核心定位

高性能 Java RPC 框架 ，面向微服务的服务治理 + 远程调用方案。

• 对比 Feign：Dubbo = RPC 长连接、高性能、低延迟
• 对比 HTTP：Dubbo 采用 TCP + 序列化，性能提升 5-10 倍
• 在 SCA 中：可完全替代 OpenFeign

一句话：微服务高性能调用首选 Dubbo

2、核心运行流程

• ① Provider 启动，向 Registry 注册服务
• ② Consumer 启动，订阅服务列表
• ③Registry 推送服务地址到 Consumer
• ④ Consumer 基于负载均衡 直接调用 Provider（点对点直连）
• ⑤调用数据上报 Monitor

3、核心原理（长连接 + Netty + 二进制序列化）

(1) 为什么性能远超 Feign/HTTP？

• TCP 长连接，避免三次握手开销
• 二进制序列化，数据体积小
• NIO 异步非阻塞，Netty 实现
• 服务端直接暴露接口，无需解析 HTTP

(2) 动态代理

• Consumer 调用接口时，Dubbo 生成动态代理
• 封装请求数据 → 网络传输 → Provider 执行 → 返回结果

(3) 服务暴露与引用

• Provider：把接口方法暴露为网络服务
• Consumer：把远程接口伪装成本地接口

4、核心特性

(1) 支持的注册中心：Nacos（生产首选，SCA 标配）、Zookeeper、Redis

(2) 传输协议：Dubbo 协议（默认，TCP 长连接，高性能）、HTTP 协议、gRPC 协议

(3) 负载均衡策略

• RandomLoadBalance：随机（默认）
• RoundRobinLoadBalance：轮询
• LeastActiveLoadBalance：最少活跃调用（最优）
• ConsistentHashLoadBalance：一致性哈希（同参数路由同一服务）

(4) 集群容错策略

• Failover ：失败自动切换，重试其他服务器（默认，读接口用）
• Failfast ：快速失败，只发一次（写接口用）
• Failsafe：安全失败，忽略异常
• Failback：失败重试
• Forking：并行调用多个服务器