一、概述Spring Cloud Alibaba 是国产微服务一站式解决方案兼容 Spring Cloud 标准替代了原生 Netflix 套件Eureka/Ribbon/Hystrix 停更是国内生产环境主流方案。核心生态组件Nacos服务注册发现 配置中心双核心Sentinel流量控制、熔断降级、系统防护Seata分布式事务解决方案RocketMQ分布式消息队列异步解耦、最终一致性GatewayAPI 网关Spring Cloud 官方Alibaba 生态标配Dubbo高性能 RPC 调用可替代 OpenFeign生产标配Spring Cloud Alibaba Nacos Sentinel Seata Gateway。二、服务注册 Nacos1、 核心作用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 服务切换为 CPRaft 强一致保证配置不丢、不乱。(3)服务上下线实时性Eureka客户端30s 拉取一次注册表服务下线延迟90s容易引发调用失败Nacos主动下线 长轮询推送服务上下线秒级感知实时性极强(4)为什么生产环境抛弃 Eureka 用 NacosEureka 2.0 闭源1.0 停更无官方维护风险极高。Nacos 一套组件搞定注册 配置架构更简单。Nacos 集群部署比 Eureka 简单太多无需复杂配置。Nacos 支持权重路由、动态配置、环境隔离、灰度发布Eureka 做不到。国内云原生、微服务生态全面拥抱 Nacos。二、 高可用防护 Sentinel1、核心作用Sentinel是微服务高可用防护组件替代停更的 Hystrix实现限流、熔断降级、系统保护、热点参数限流是 Spring Cloud Alibaba 标配高可用方案。一句话总结防止服务雪崩、保护接口不被打垮、保证核心服务可用。2、核心功能流量控制限流QPS / 线程数限流、预热、排队、匀速排队熔断降级慢调用、异常比例、异常数熔断热点参数限流针对参数用户 ID / 商品 ID单独限流系统自适应保护Load/CPU 高了自动限流授权规则黑白名单控制3、底层核心原理(1) 滑动时间窗口高并发高性能关键无侵入式埋点滑动窗口统计请求高性能支持持久化规则Nacos/Push 模式生产必须用滑动时间窗口解决固定窗口临界突刺问题实现高精度、高性能的请求统计保证限流准确。(2) 限流算法计数器法简单 QPS 限制漏桶算法匀速排队削峰填谷令牌桶算法预热限流应对突发流量(3) 熔断降级策略Sentinel 是慢启动 慢恢复比 Hystrix 更平滑慢调用比例响应超时 阈值 → 熔断异常比例错误率过高 → 熔断异常数错误次数过多 → 熔断熔断后放半个探测请求恢复后慢慢放开三、分布式事务 Seata1、核心定位解决微服务跨库 / 跨服务事务一致性问题保证最终一致性 / 强一致性。2、三大角色TC事务协调器独立服务管理全局事务指挥提交 / 回滚TM事务管理器业务服务中的发起方开启 / 提交 / 回滚全局事务RM资源管理器管理每个事务的本地事务生成 undo_log 回滚日志执行分支提交 / 回滚3、三大模式重点(1) AT 模式最常用无侵入适用场景普通微服务、单库分表、同类型数据库MySQL/MySQL核心原理无代码入侵基于本地事务 undo_log二阶段提交一阶段执行提交二阶段确认 / 回滚优点简单、接入成本极低缺点必须同类型数据库有行锁高并发热点数据有性能损耗(2) TCC 模式高性能侵入强适用场景高并发、核心支付、库存、不同数据库核心原理手动写三个方法Try Confirm CancelTry资源预留 / 检查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 节点无状态Broker2 主 2 从异步刷盘 异步复制磁盘SSD消息量大扩容消息可靠性同步刷盘 同步双写金融级幂等性消费端必须实现防重复消费4、核心问题(1)消息重复消费一条消息消费多次导致数据重复 / 错误。出现该现象的原因是消费者超时 / 宕机未 ACKBroker 重发重试机制触发解决方案是必须做幂等性校验全局唯一 ID MySQL 去重表Redis 唯一ID去重状态机判断数据库唯一索引分布式锁(2)消息丢失消息丢失即生产者发了消息Broker 没收到 / 消费者没收到数据丢失。丢失的场景有生产者 → Broker网络闪断丢失Broker 自身宕机、未刷盘丢失Broker → 消费者未消费先 ACK 丢失解决方案如下生产者开启事务消息 / 同步发送 重试Broker开启同步刷盘 / 主从同步消费者业务执行成功后再手动 ACK(3)消息堆积消息堆积即消息堆积几十万、几百万消费跟不上。出现该现象的原因是消费者线程太少消费者内部慢调用SQL / 接口超时消费者死锁、异常生产流量暴增解决方案如下提高消费者线程数扩容消费者实例超过队列数无效优化消费逻辑异步化、慢 SQL 优化跳过非核心消息临时抢救排查死锁 / 异常(4)消息顺序错乱消息顺序错乱即需要顺序执行的消息订单创建→支付→发货乱序出现该现象的原因是多个队列多个消费者并发消费解决方案如下将同一业务 ID订单 IDhash 到同一个队列一个队列只配一个消费者线程使用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框架Dubbo1、核心定位高性能 Java RPC 框架面向微服务的服务治理远程调用方案。对比 FeignDubbo RPC 长连接、高性能、低延迟对比 HTTPDubbo 采用 TCP 序列化性能提升 5-10 倍在 SCA 中可完全替代 OpenFeign一句话微服务高性能调用首选 Dubbo2、核心运行流程① Provider 启动向 Registry 注册服务② Consumer 启动订阅服务列表③Registry 推送服务地址到 Consumer④Consumer基于负载均衡直接调用 Provider点对点直连⑤调用数据上报 Monitor3、核心原理长连接 Netty 二进制序列化(1) 为什么性能远超 Feign/HTTPTCP 长连接避免三次握手开销二进制序列化数据体积小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并行调用多个服务器