SpringCloud 是什么？核心解决什么问题？
SpringCloud 是基于 SpringBoot 的微服务全家桶，封装了各种微服务组件。
核心解决：服务注册发现、负载均衡、熔断降级、网关路由、配置中心、链路追踪等微服务架构的核心问题。
常用的 SpringCloud 组件有哪些？各自作用？
Eureka：原生服务注册发现组件，功能单一，已停更，被 Nacos 替代；
Spring Cloud Config：原生配置中心，需配合 Bus 实现配置热更新，被 Nacos 替代；
Hystrix：原生熔断限流组件，已停更，被 Sentinel 替代；
Zuul：原生网关，性能不如 Gateway，被 Gateway 替代；
Feign：原生声明式远程调用， OpenFeign 是其增强版，兼容 Spring MVC 注解
Spring Cloud Alibaba 是什么？核心优势是什么？
是阿里开源的微服务框架，基于 SpringCloud 标准，整合了阿里自研的中间件。
Spring Cloud Alibaba 核心组件有哪些？各自作用？
Nacos：一站式注册中心 + 配置中心，替代 Eureka+Config；
Sentinel：熔断降级 + 限流，替代 Hystrix；
Seata：分布式事务解决方案，解决微服务跨库事务问题；
RocketMQ：消息队列，做异步通信、削峰填谷；
Dubbo：高性能 RPC 框架，替代 OpenFeign（适合高性能服务调用）；
Gateway：和 SpringCloud Gateway 一致，做微服务网关。
OpenFeign:负责服务通信
CAP是什么?
CAP 定理指分布式系统中，一致性、可用性、分区容错性三者不可同时满足。
分布式系统必须保证 P（分区容错），所以实际只能在 AP 和 CP 之间选择：
AP：保证可用性，牺牲强一致性，保证最终一致（比如 Eureka、Nacos 默认）
CP：保证强一致性，牺牲部分可用性（比如 Zookeeper、Nacos 切 CP）
Nacos 和 Eureka 区别？
功能：Nacos 同时支持注册中心 + 配置中心，Eureka 只有注册发现
CAP：Nacos 支持 AP/CP 切换，Eureka 只支持 AP
维护状态：Eureka 已停更，Nacos 阿里维护，活跃
配置刷新：Nacos 自带动态刷新，Eureka 不支持配置中心
负载均衡机制
我记得有好多种;常用的有两种
一种是轮询机制,就是1,2,3;这样一个一个调用,完了再次循环调用
还有就是随机的方式,这种就是随机选个服务调用
熔断机制
它是微服务架构中用于防止系统雪崩的机制
熔断的工作流程分为三个状态
闭合状态（Closed）
正常情况，请求正常调用下游服务。
若失败次数超过阈值（如连续5次失败），触发熔断，进入打开状态。打开状态（Open）
直接拒绝所有请求，返回错误或降级结果。
经过一段时间后（如5秒），进入半开状态。半开状态（Half-Open）
允许少量请求尝试调用下游服务。
若请求成功，则关闭熔断，恢复正常；若失败，则重新打开熔断
OpenFeign 是什么？和 RestTemplate 区别？
OpenFeign 底层负载均衡是 Spring Cloud LoadBalancer，默认策略是轮询
RestTemplate：需要手动拼 URL、调方法，代码繁琐；
OpenFeign：只需要写接口加注解（@FeignClient），像调本地方法一样调远程服务，更简洁。
Ribbon 负载均衡策略有哪些？默认是什么？
常用策略：轮询（默认）、随机；
默认是轮询，可以自定义策略（比如按权重分配请求）。
什么是服务雪崩？怎么避免？
服务雪崩是指某个微服务故障，导致调用方阻塞、线程耗尽，逐级传导拖垮整个微服务体系。
解决方案：熔断、降级、限流、超时控制、线程池隔离。
Nacos 配置中心实现动态刷新的原理？
① 服务启动时从 Nacos 拉取配置，同时和 Nacos 建立长连接；
② 配置修改后，Nacos 主动推送配置变更给服务；
③ 服务收到通知后，重新加载配置，配合 @RefreshScope 注解，Bean 属性动态更新，不用重启服务。
微服务之间如何实现远程调用？
常用两种方式：
① RestTemplate + Ribbon：RestTemplate 做 HTTP 调用，Ribbon 做负载均衡；
② OpenFeign：声明式调用，底层还是 Ribbon，代码更简洁，推荐用这个。
微服务调用超时怎么处理？
答：给 OpenFeign 设置调用超时时间；通过 Sentinel 配置降级规则，超时返回兜底数据，防止服务雪崩
OpenFeign 执行流程
OpenFeign 执行流程（高频）
启动类开启 @EnableFeignClients
定义接口加 @FeignClient (服务名)
调用时，Feign 通过动态代理生成实现类
结合 LoadBalancer 做负载均衡，发起 HTTP 请求
结果封装返回，像调用本地方法一样
微服务调用超时，怎么排查？
① 查网络：是否能 ping 通目标服务，端口是否开放；
② 查注册中心：目标服务是否注册成功，实例状态是否正常；
③ 查日志：看调用方和提供方的日志，是否有报错（比如数据库慢查询、接口抛异常）；
④ 查配置：是否设置了合理的超时时间（Feign/Hystrix 超时）。
如何做微服务的限流？
① 网关层限流：Gateway 结合 Sentinel/Nacos，按 IP / 接口限流（比如每秒最多 100 个请求）；
② 服务端限流：Sentinel 注解（@SentinelResource），对具体接口限流，触发后返回降级结果。
Gateway
Gateway 核心原理？
Gateway 是基于 WebFlux 的网关，核心是路由 + 过滤器链：
路由：匹配请求路径，转发到对应服务；
过滤器：分全局过滤器（所有请求生效）和局部过滤器（指定路由生效），能做鉴权、限流、日志、修改请求 / 响应；
异步非阻塞，性能比 Zuul 好。
如何实现微服务接口的统一鉴权？
在 Gateway 网关层做统一鉴权：
① 前端请求带 token，网关拦截所有请求；
② 校验 token 合法性（比如查 Redis、调认证服务）；
③ 合法则转发请求，不合法直接返回 401，不用每个服务都写鉴权逻辑。
微服务统一鉴权
放在 Gateway 网关层统一处理：
前端请求携带 Token，网关全局过滤器校验 Token 合法性，校验通过转发，不通过直接返回 401，下游服务无需重复鉴权。
Gateway 路由转发失败，怎么排查？
① 查路由配置：路径匹配规则是否正确（比如路径少写 /）；
② 查服务地址：转发的服务名是否在注册中心存在；
③ 查过滤器：是否有过滤器拦截了请求（比如鉴权失败）；
④ 查日志：开启 Gateway 日志，看转发的具体地址和错误信息。
Nacos
Nacos 服务注册发现的原理？
① 服务启动时，通过 Nacos Client 向 Nacos Server 注册（提交服务名、IP、端口）；
② Nacos Server 将服务信息存在注册表，同时和客户端建立长连接；
③ 服务消费者拉取注册表，本地缓存；
④ 服务上下线时，Nacos Server 主动推送变更给消费者，保证数据实时性。
Nacos 配置中心如何保证配置不丢失？
① 单机模式：配置存在本地文件；
② 集群模式：配置持久化到 MySQL，同时 Nacos 节点间同步配置；
③ 客户端本地缓存：服务拉取配置后，本地会缓存一份，即使 Nacos 宕机，服务也能读取本地缓存启动。
微服务如何接入 Nacos 配置中心？
只需要引入 nacos-config 依赖，配合 bootstrap.yml + @RefreshScope 即可。
Sentinel
什么是服务熔断、服务降级？区别是什么？
熔断：调用方的自我保护，下游服务异常时，暂时切断调用，防止雪崩（被动触发）
降级：全局策略，高并发下主动放弃非核心接口，返回兜底数据（主动触发）
关系：熔断后一定会执行降级逻辑
Sentinel 核心概念有哪些？
资源：被保护的对象（接口、方法）；
规则：限流 / 熔断 / 降级规则（比如 QPS 限流、异常比例熔断）；
插槽链（Slot Chain）：Sentinel 的核心执行链路，负责规则校验、统计、限流等；
兜底策略：触发规则后返回的结果（默认、自定义、降级调用）。
基于插槽链设计，请求依次经过：
资源定位→统计 QPS / 异常→校验限流 / 熔断规则→通过则放行，不通过则执行降级兜底。
Sentinel 如何做熔断降级？
① 配置熔断规则（比如异常比例 > 50%、异常数 > 10，熔断时长 5s）；
② 服务调用异常触发规则后，进入熔断状态，期间不调用目标服务；
③ 熔断时长结束后，进入半开状态，放少量请求测试，若正常则恢复，否则继续熔断。
如何用 Sentinel 实现接口限流？
① 引入 sentinel-spring-cloud-starter 依赖；
② 启动类加 @EnableDiscoveryClient（注册到 Nacos）；
③ 接口上加 @SentinelResource（指定资源名、兜底方法）；
④ 登录 Sentinel 控制台，给该资源配置限流规则（比如 QPS=10）；
⑤ 触发限流时，自动执行兜底方法返回结果。
Seata分布式事务
微服务如何实现分布式事务？
主流方案：
① 最终一致性：Seata（AT 模式，无侵入，适合大多数场景）；
② 补偿机制：TCC（Try-Confirm-Cancel，手动写补偿逻辑，适合核心业务）；
③ 消息队列：本地消息表 + MQ，异步补偿，保证最终一致。
Seata 三种核心模式：
AT、TCC、SAGA，最常用的是 AT 模式。
AT 模式（自动模式，无侵入）
最常用、最简单，不用写业务代码，只加注解就能用。
原理就是自动拦截 SQL，帮你记录 undo_log，出问题自动回滚。
适合：单库分服务、普通业务场景，比如订单、库存、支付。
TCC 模式（手动模式，高性能）
一阶段 Try、二阶段 Confirm/Cancel，需要自己写三个接口。
性能高、控制最细，但开发量大。
适合：不支持事务的数据库、Redis、第三方接口。
SAGA 模式（长事务模式）
适合流程很长、跨多个系统、耗时很久的业务，比如财务结算、跨企业流程。
靠补偿机制来回滚，不用锁资源。
项目里怎么使用
搭建 Seata Server（TC 事务协调器）
单独部署，负责全局事务的提交与回滚，管理所有分支事务。
每个微服务引入 Seata 依赖，配置数据源代理
Seata 会自动代理数据源，无侵入式接管事务。
在发起方方法上加 @GlobalTransactional
比如开立医嘱这个接口，作为全局事务入口。
执行流程
开启全局事务，生成 XID；
调用订单、药品、收费服务，自动传递 XID；
所有服务执行成功 → 全局提交；
任意一个服务失败 / 异常 → 全局回滚。
如何解决 Seata 分布式事务中的 XID 透传问题？
XID 是全局事务 ID，必须在微服务调用间透传，否则 Seata 无法识别全局事务：
① 用 OpenFeign 调用时，自定义拦截器，把 XID 从 ThreadLocal 取出来，放到请求头；
② 服务提供方拦截请求，从请求头取出 XID，设置到 ThreadLocal；
③ Dubbo 调用时，通过 Dubbo 的上下文传递 XID，原理和 Feign 一致。
微服务调用时，XID 会通过 RequestAttributes、RequestHeader 传递，OpenFeign/Dubbo 都有自带的拦截器透传，一般不用自己手写。
