Spring Cloud 常见面试题目录什么是微服务？单体架构和微服务架构的区别是什么？Spring Cloud 是什么？包含哪些核心组件？什么是服务注册与发现？Eureka 和 Nacos 有什么区别？Ribbon 和 LoadBalancer 的负载均衡策略有哪些？OpenFeign 的原理是什么？Hystrix 和 Sentinel 的熔断降级机制有什么区别？Spring Cloud Gateway 的过滤器有哪些？讲一下你用过哪些？什么是服务雪崩？怎么解决？Nacos 作为配置中心是怎么用的？动态刷新怎么实现？分布式事务怎么处理？Seata 的原理是什么？Spring Cloud 和 Spring Cloud Alibaba 有什么区别？服务间调用怎么保证安全？如何做链路追踪？Sleuth + Zipkin / SkyWalkingCAP 理论在微服务中怎么理解？实际项目中遇到过哪些坑？怎么解决的？1. 什么是微服务？单体架构和微服务架构的区别是什么？答：微服务说白了就是把一个大的应用，按照业务功能拆分成一个个独立的小服务。每个服务都有自己的数据库、自己的代码仓库、自己的部署流程，服务之间通过 HTTP 或者 RPC 来通信。举个例子：一个电商系统，单体架构就是把用户模块、商品模块、订单模块、支付模块全部写在一个项目里，打成一个 war 包部署到一台 Tomcat 上。而微服务架构呢，就是把用户、商品、订单、支付拆成四个独立的服务，每个服务都可以单独部署。对比维度单体架构微服务架构部署整体打包，牵一发而动全身每个服务独立部署，互不影响扩展只能整体扩展，无法针对热点模块可以针对性地扩展某个服务，比如双十一只扩订单服务开发效率初期开发快，但代码越来越大后难以维护团队可以并行开发不同服务，效率高技术栈技术栈统一，不好尝鲜每个服务可以用不同的技术栈，比如订单用 Java，推荐用 Python运维复杂度简单，就一个应用复杂，要管理一堆服务数据一致性本地事务就能搞定需要处理分布式事务，比较头疼口语总结：简单说就是——“拆”。拆开之后各管各的，好处是灵活、好扩展，但代价是运维变复杂了，而且原来一个本地事务就能搞定的事情，现在得搞分布式事务了。2. Spring Cloud 是什么？包含哪些核心组件？答：Spring Cloud 是一套微服务开发工具集，它不是重新造轮子，而是把市面上成熟的微服务框架封装了一层，让我们能用 Spring Boot 的开发习惯来快速搭建微服务。说白了它就是给你提供了一站式解决方案，帮你解决微服务里那些通用的问题。核心组件及作用：组件作用通俗理解Nacos / Eureka服务注册与发现就像一个通讯录，所有服务上线后都来登记，调用方从这个通讯录里找到对方Gateway / Zuul网关就像公司前台，所有请求先到前台，前台帮你分发到对应的工位OpenFeign声明式服务调用写 HTTP 调用就像写本地方法一样简单LoadBalancer / Ribbon客户端负载均衡一个服务有多个实例，帮你挑一个来调用Sentinel / Hystrix熔断降级某个服务挂了，我快速失败而不是一直死等Sleuth + Zipkin / SkyWalking链路追踪一次请求经过了 N 个服务，能看它每一步花了多长时间Spring Cloud Config / Nacos Config配置中心配置统一管理，改了不用重启口语总结：Spring Cloud 就是微服务全家桶，帮你把注册、发现、调用、熔断、网关、配置这些脏活累活都封装好了，你直接用就行。3. 什么是服务注册与发现？Eureka 和 Nacos 有什么区别？答：服务注册与发现其实就是解决一个问题——“我要调的服务在哪里？”在没有注册中心之前，我们调一个服务得写死 IP 和端口，当服务数量多了、IP 变了、扩缩容了，根本管理不过来。注册与发现流程（类比）：就好比你到一个大公司找人：每个员工入职时先去前台登记：我叫张三，我在 3 楼 301 室。（服务注册）你要找张三，先去前台问：张三在哪儿？（服务发现）前台告诉你 3 楼 301。（返回地址）如果张三离职了，前台会把他从名单上划掉。（服务剔除）Eureka vs Nacos 对比：对比维度EurekaNacos开发方Netflix（已停更，进入维护模式）阿里巴巴（还在活跃更新）CAP 模型AP（优先可用性，分区容错）支持 AP 和 CP 两种模式切换健康检查心跳机制，客户端定时上报支持临时实例心跳 + 持久实例主动探测配置中心不支持，需要配合 Spring Cloud Config自带配置中心，注册和配置二合一一致性协议无主从，每个节点平等临时实例用自研 Distro 协议，持久实例用 Raft保护机制自我保护模式：短时间内大量客户端失联时不会剔除下沉到客户端，由 Sentinel 做目前趋势已经停更，不建议新项目用Spring Cloud Alibaba 主推，新项目首选重点讲一下 Eureka 的自我保护机制：Eureka 有个特点，如果短时间内大量服务实例没有发送心跳，它不会立即剔除这些实例，而是进入“自我保护模式”。为什么这样设计呢？因为可能是网络抖动导致的，如果贸然剔除，会导致大量服务不可用。宁可保留可能已挂掉的服务，也不误删正常服务——宁愿保留错的，也不错杀对的。这体现了 AP 的设计理念。口语总结：新项目直接选 Nacos，既能注册又能配置，一个组件干两件事。面试时提一句“Eureka 2.x 已经停更了”能加分。4. Ribbon 和 LoadBalancer 的负载均衡策略有哪些？答：先说背景：Ribbon 是 Netflix 出品的老牌负载均衡组件，但 Spring Cloud 从 2020.0 版本开始，Ribbon 已经进入维护模式，官方推荐用 Spring Cloud LoadBalancer 来替代。但它们的使用思路是类似的。Ribbon 内置的负载均衡策略：策略规则适用场景举例轮询（RoundRobinRule）按顺序轮流分配各机器配置一样ABCABCABC…随机（RandomRule）随机挑一个请求量大的时候效果接近轮询纯随机加权响应时间（WeightedResponseTimeRule）响应越快的机器分到越多请求机器配置不均匀快机器多干活最小并发（BestAvailableRule）选当前积压请求最少的请求耗时差异大谁闲着找谁可用性过滤（AvailabilityFilteringRule）跳过熔断或并发高的实例需要熔断保护跳过“生病”的区域感知（ZoneAvoidanceRule）优先同区域的实例多机房部署（这个是默认策略）同机房优先再举个例子讲 ZoneAvoidanceRule：假设你的服务部署在北京和上海两个机房。一个北京的用户发来请求，如果北京机房有可用实例，就优先路由到北京，因为同城网络延迟低。只有北京都挂了才会去调上海的实例。Spring Cloud LoadBalancer：它的默认策略也是轮询。可以自定义负载均衡规则：// 自定义成随机策略，只需要注入一个 ReactorLoadBalancer Bean@BeanpublicReactorLoadBalancerServiceInstancerandomLoadBalancer(Environmentenvironment,LoadBalancerClientFactoryfactory){Stringname=environment.getProperty("loadbalancer.client.name");returnnewRandomLoadBalancer(factory.getLazyProvider(name,ServiceInstanceListSupplier.class),name);}口语总结：先讲 Ribbon 是客户端负载均衡，默认用 ZoneAvoidanceRule（同区域优先），然后补一句“新版本官方推荐 LoadBalancer 替代 Ribbon”，显得你跟上了版本。面试官很可能顺着问你“那你项目里用的哪个”，这时候再展开讲。5. OpenFeign 的原理是什么？答：OpenFeign 让你用声明式的方式来调用 HTTP 接口——你只需要写一个接口加几个注解，不用自己拼 URL、处理 JSON，它帮你把脏活都干了。核心原理（三个关键词）：动态代理 + 注解解析 + HTTP 调用具体流程：启动时扫描：@EnableFeignClients注解告诉 Spring 去扫描所有标记了@FeignClient的接口。生成动态代理：Spring 为每个@FeignClient接口创建 JDK 动态代理对象，注入到 Spring 容器中。调用时拦截：当你调用接口方法时，实际调用被代理拦截（MethodHandler）。解析注解：根据方法上的@RequestMapping、@GetMapping等注解，解析出请求路径、请求方式、参数等。负载均衡：如果用了服务名（而不是直接写 URL），会先通过 LoadBalancer 拿到一个可用的服务实例地址。编码发送：把方法参数编码成 HTTP 请求体（默认用 SpringEncoder），发 HTTP 请求。解码返回：收到响应后，用 SpringDecoder 把 JSON 转成你定义的返回类型。举个例子：@FeignClient(name="user-service",path=
