day05-微服务03 学习总结

一、微服务保护

1. 为什么要服务保护？

• 业务健壮性：部分服务故障不影响整体功能（如商品查询失败，购物车仍可展示）
• 防止雪崩：避免单个服务故障导致整个集群不可用（级联失败）

2. 服务保护方案

方案	作用	类比
请求限流	控制接口并发流量，避免流量激增导致故障	水电站大坝
线程隔离	限定每个接口可用线程数，避免故障扩散	轮船舱壁
服务熔断	统计异常/慢请求比例，超过阈值直接降级	电路断路器

3. Sentinel

3.1 介绍

• 核心库：引入依赖，实现限流、隔离、熔断
• 控制台：Dashboard，管理规则、监控

3.2 整合步骤

1. 引入sentinel依赖
2. 配置控制台地址
3. 可选：开启请求方式前缀（区分GET/POST等）

4. 请求限流

• QPS限流：限制每秒请求数
• 配置：簇点链路 → 流控 → 设置QPS阈值
• 效果：超出阈值的请求被拒绝

5. 线程隔离

• 场景：保护购物车服务，避免商品服务故障影响
• 配置：Feign整合Sentinel → 对FeignClient设置并发线程数限制
• 效果：限定线程资源，不影响其他接口

6. 服务熔断

6.1 降级逻辑

• FallbackFactory：为FeignClient编写降级处理
  • 查询失败返回空集合（友好体验）
  • 扣减库存失败抛出异常（触发回滚）

6.2 熔断配置

• 慢调用比例：RT超过阈值 → 统计慢调用比例 → 触发熔断
• 状态机：closed（关闭）→ open（打开）→ half-open（半开）
• 效果：故障接口直接走降级，避免拖垮调用方

---

二、分布式事务

1. 问题产生

• 场景：下单业务涉及订单、购物车、商品三个服务
• 原因：跨服务、跨数据库，本地事务互不知晓
• 结果：部分失败无法回滚（购物车被清空但订单失败）

2. Seata架构

角色	全称	作用
TC	事务协调者	维护全局和分支事务状态，协调提交/回滚
TM	事务管理器	定义全局事务范围，发起提交/回滚
RM	资源管理器	管理分支事务，与TC交互

3. 部署TC服务

• 准备数据库表（seata-tc.sql）
• 准备配置文件
• Docker部署

4. 微服务集成Seata

1. 引入seata、nacos-config依赖
2. 添加bootstrap.yaml，加载共享配置（shared-seata.yaml）
3. 添加undo_log表（AT模式需要）
4. 使用@GlobalTransactional标记事务入口

5. XA模式

5.1 原理

• 一阶段：执行SQL但不提交，持有锁 → 报告状态
• 二阶段：全部成功则提交，否则回滚

5.2 优缺点

优点	缺点
强一致性，满足ACID	资源锁定周期长，性能差
数据库原生支持，无代码侵入	依赖关系型数据库

5.3 配置

seata:
  data-source-proxy-mode: XA

6. AT模式（推荐）

6.1 原理

• 一阶段：记录undo-log快照 → 执行SQL并提交 → 释放锁
• 二阶段提交：删除undo-log
• 二阶段回滚：根据undo-log恢复数据

6.2 与XA对比

对比项	XA	AT
资源锁定	一阶段不提交，持有锁	一阶段提交，释放锁
回滚机制	数据库回滚	undo-log恢复
一致性	强一致	最终一致
性能	差	好
业务侵入	无	无

---

三、今日核心知识点

模块	技术点	作用
服务保护	Sentinel	限流、隔离、熔断
服务保护	线程隔离	限定接口线程数
服务保护	FallbackFactory	降级处理
服务保护	熔断	故障接口自动切断
分布式事务	Seata	解决跨服务事务
分布式事务	XA模式	强一致，性能差
分布式事务	AT模式	最终一致，性能好
分布式事务	@GlobalTransactional	标记全局事务

---

微服务03 校招面试常问问题总结

一、服务保护类

1. 什么是雪崩问题？怎么解决？

• 问：微服务中什么是雪崩效应？如何避免？
• 答：一个服务故障导致调用方也故障，层层传递最终整个集群不可用。解决方案：限流、线程隔离、熔断降级。

2. 限流、隔离、熔断的区别？

• 问：说说服务保护的几种方式及区别
• 答：
  • 限流：控制流量大小，预防过载
  • 隔离：限定资源使用，控制故障范围
  • 熔断：故障时自动切断，走降级逻辑

3. Sentinel用过吗？怎么用？

• 问：你们项目怎么做服务保护的？
• 答：使用Sentinel，配置限流规则（QPS）、线程隔离（并发线程数）、熔断规则（慢调用比例）

4. 降级逻辑怎么写？

• 问：服务调用失败怎么办？
• 答：编写FallbackFactory，返回默认数据或友好提示，关键业务抛出异常触发回滚

5. 熔断器的状态机？

• 问：熔断器有几个状态？怎么切换？
• 答：closed（放行并统计）→ open（熔断）→ half-open（尝试放行）→ 成功则closed，失败则open

---

二、分布式事务类

6. 什么是分布式事务？什么情况会产生？

• 问：什么情况下会产生分布式事务问题？
• 答：业务跨多个服务、跨多个数据库，本地事务互不知晓，无法保证ACID

7. Seata是什么？有哪些角色？

• 问：Seata是怎么解决分布式事务的？
• 答：Seata是分布式事务框架，有三个角色：TC（协调者）、TM（事务管理器）、RM（资源管理器）

8. XA模式和AT模式的区别？

• 问：Seata的XA和AT有什么区别？
• 答：
  • XA：一阶段不提交，持有锁，强一致，性能差
  • AT：一阶段提交，记录快照，最终一致，性能好

9. AT模式原理能讲讲吗？

• 问：AT模式是怎么实现回滚的？
• 答：一阶段记录undo-log快照，执行SQL并提交；二阶段回滚时根据快照恢复数据

10. @GlobalTransactional作用？

• 问：怎么标记一个分布式事务？
• 答：在业务方法上加@GlobalTransactional，TM会基于此定义全局事务范围

---

三、项目实践类

11. 你们项目哪些地方用了分布式事务？

• 问：举例说明你们项目中的分布式事务场景
• 答：下单业务（订单、购物车、商品）、支付业务（支付、用户余额、订单状态更新）

12. 下单失败购物车却被清空了怎么解决？

• 问：遇到过分布式事务问题吗？怎么解决的？
• 答：用Seata的AT模式，@GlobalTransactional标记下单方法，保证三个服务同时成功或失败

13. Feign调用失败怎么处理？

• 问：远程调用失败会影响主业务吗？怎么处理？
• 答：用FallbackFactory做降级，非核心数据返回空集合，核心业务抛异常触发回滚

14. Sentinel和Hystrix的区别？

• 问：为什么选Sentinel而不是Hystrix？
• 答：Sentinel功能更丰富（限流、隔离、熔断），控制台更强大，Hystrix已停更

---

四、常见坑点

15. 线程隔离和限流混淆？

• 注意：限流控制QPS（请求量），隔离控制并发线程数（资源占用），别搞混

16. 降级逻辑抛出异常？

• 注意：查询类降级返回空数据，写操作降级要抛异常，否则事务无法回滚

17. AT模式需要什么表？

• 注意：每个业务库都要有undo_log表，否则AT模式无法工作

18. XA模式性能问题？

• 注意：XA锁资源时间长，高并发场景慎用，推荐AT模式

---

五、校招微服务考察重点排序（最终版）

1. 雪崩问题及解决方案 ⭐⭐⭐⭐⭐
2. 限流、隔离、熔断的区别 ⭐⭐⭐⭐⭐
3. Sentinel使用场景 ⭐⭐⭐⭐
4. 降级逻辑编写 ⭐⭐⭐⭐
5. 分布式事务产生原因 ⭐⭐⭐⭐
6. Seata AT模式原理 ⭐⭐⭐
7. XA与AT对比 ⭐⭐⭐
8. @GlobalTransactional作用 ⭐⭐⭐

总结：校招面试微服务，核心考察概念理解和设计思想。你能把今天学的：

• 为什么要服务保护（雪崩）
• 怎么保护（限流、隔离、熔断）
• 分布式事务是什么（跨服务数据一致）
• 怎么解决（Seata AT模式）

讲清楚逻辑，再结合项目举例，完全足够！