Spring Cloud服务治理核心链路：面试必问的注册、调用、容错与网关

前几天我参加了一场技术面试评估，一位候选人简历上写着"精通Spring Cloud微服务治理"，结果我在电话里刚问到"你项目里服务注册用的什么方案"，他答完Eureka之后，我顺口追问了一句"Eureka为什么选择AP而不是CP"，他沉默了两秒，然后开始背八股文："因为AP是可用性优先，CP是一致性优先……"之后就再也接不上了。

这个场景太典型了。我做了多年微服务方向的技术面试，也帮团队做过很多次候选人评估，发现Spring Cloud这块翻车率其实非常高。原因不是候选人不会用，而是很多人在项目里"能用就行"，对底层的权衡逻辑、组件之间的协作关系、以及面试官真正想听到的"为什么"缺乏系统梳理。

这篇文章是我计划中Spring Cloud面试题总结的第一篇，聚焦服务治理的最核心链路：注册发现、服务调用、负载均衡、容错降级、配置中心和网关适配。每一道题我都会从面试官视角告诉你考察点是什么，然后给出一个既能过面试、又能指导实战的回答思路。

1. 服务注册与发现：Eureka的血肉，不只是"AP架构"四个字

1.1 面试官为什么第一题就问你注册中心

微服务拆完之后，第一个要解决的问题就是：服务之间怎么找到彼此？以前单体应用直接调方法就行，拆成独立进程部署之后，每个服务实例的IP和端口都是动态的，扩容缩容随时变，不可能再把地址写死在配置文件里。这时候就需要一个"通讯录"，也就是注册中心。

这个"通讯录"的核心职责面试官通常不会直接问，但你要主动说出来：服务启动时把自身地址注册上去、服务运行中定期续约告诉注册中心"我还活着"、注册中心把健康的实例列表推给服务消费者，以及服务下线时负责移除。很多候选人只记得"注册"两个字，把后面三步忘了，这就是第一道扣分点。

我建议你在回答时把完整链路讲出来：服务提供者启动→注册到注册中心→注册中心接收并存储→服务消费者启动时拉取实例列表→之后定时刷新→消费者根据负载均衡策略选一个实例发起调用。这个过程串起来之后，面试官才能确认你不是只写过几行配置文件。

1.2 Eureka为什么坚持AP，Nacos为什么可以切换

这道题几乎必考。Eureka的设计哲学是"宁可拿到稍旧的实例列表，也不能让服务不可用"。它做的是AP选择：在分布式系统分区发生时，保证可用性，牺牲强一致性。注册信息短暂不一致是可以接受的，你拿到的是一个几分钟前的旧列表，至少还能找到某个实例发起请求；但如果你为了保证所有节点数据完全一致而拒绝服务，整个微服务系统就直接瘫痪了，那比拿到旧数据可怕得多。

ZooKeeper是反过来的CP模型。它用ZAB协议保证强一致，leader挂了会触发选举，选举期间整个集群无法对外提供读写服务。所以很多老项目用ZooKeeper做注册中心，遇到zk集群抖动时，服务发现基本就卡住了。Nacos比较灵活，临时实例走AP，持久实例走CP，可以根据业务场景切换。

面试官在这里通常会追加一问：Eureka的自我保护机制是怎么回事？这是一个非常高频的追问点。你要答出三个要素：最近15分钟内心跳成功率低于85%时会触发；触发后Eureka不会剔除"看起来过期"的实例，而是把所有实例都保留下来；目的是防止因网络分区导致的大规模误删。还要补一句：等网络恢复、心跳成功率回升之后，会自动退出自我保护。能答到这个颗粒度，说明你是真在线上环境遇到过而不是背概念。

1.3 Eureka的三级缓存，答出来直接加分

这是我特别想提醒的一点：Eureka Server并不是把注册表直接放在一个Map里让客户端读，它用了三级缓存结构。最底层是只读缓存ConcurrentHashMap（getReadOnlyCacheMap），中间是一级缓存（getReadOnlyCacheMap和getReadWriteCacheMap之间的gzip缓存？准确说是有readWriteCacheMap），最顶层是读写缓存readWriteCacheMap，注册、续约、下线都写readWriteCacheMap，然后定期同步到只读缓存。客户端拉取时优先读只读缓存。

为什么要做这么复杂的缓存？因为注册中心是极高并发读、相对低并发写的场景，直接用单一Map会遇到锁竞争和性能瓶颈。两级缓存可以降低锁粒度：读走只读副本，写走读写副本，后台定时同步。代价就是一致性延迟，新服务注册后客户端最长可能要几十秒才能感知。这也是为什么项目里经常出现"服务明明起来了，但调用方一直报找不到实例"的现象。

Nacos的注册中心实现思路不同，临时实例走distro协议，每个节点只负责一部分实例的写请求，然后异步复制给其他节点，客户端通过rpc长连接做心跳。Nacos的实例列表变更能被客户端更快感知，这也是它后来居上的重要原因。面试时能把Eureka和Nacos的存储结构差异讲出来，就已经超越了大多数竞争者。

2. OpenFeign高频连环问：从代理生成到超时设置的完整链路

2.1 面试必问：OpenFeign到底是干什么的

服务之间要发起HTTP调用，原来最原始的方式是用RestTemplate手写URL、拼参数、解析响应，代码又丑又难维护。OpenFeign做的就是"把远程调用伪装成本地方法调用"：你定义一个接口，加上Spring MVC注解，运行时框架自动生成动态代理。调用接口方法时，代理对象负责把方法签名解析成HTTP请求，发出去，再把响应解析回Java对象。

很多候选人能答出"动态代理"这四个字，但面试官接着问"代理生成之后做了什么"就卡住了。你要往下说：方法调用会被MethodHandler拦截，通过Contract解析FeignClient接口上的注解（类上的FeignClient、方法上的GetMapping、RequestParam等），生成一个RequestTemplate，包含URL、请求头、请求体；然后经过Encoder序列化请求体，经过Client执行HTTP请求；拿到响应后用Decoder反序列化。这个过程中还会被负载均衡组件和断路器拦截，所以Feign并不是一个单纯的HTTP客户端，它是一整条调用链的入口。

我见过很多线上问题就出在这个链路上。比如有人配了Feign的日志级别想排查请求参数，结果发现日志不输出，因为Feign的Logger.Level默认是NONE，只能通过FeignClient(configuration=...)指定配置类来开启，而且日志级别是框架自己控制的，不是logback的debug就能打开。

2.2 超时设置，最容易答错的一题

这道题踩坑率极高。OpenFeign本身的超时设置是spring.cloud.openfeign.client.config.default.connectTimeout和readTimeout，但如果你用的是老版本Spring Cloud整合Ribbon的方案，实际生效的可能是ribbon.ConnectTimeout和ribbon.ReadTimeout。Ribbon的默认连接超时只有1秒、读取超时1秒，这在很多业务场景下根本不够用，尤其是在网关转发链路里，一个下游接口稍微慢一点就直接TimeoutException了。

我自己的建议是分两层说：第一，OpenFeign的配置要显式设置，不要依赖默认值；第二，如果你项目里还在用Ribbon，需要理解Ribbon的超时配置会覆盖Feign的超时配置，两者通常会取一个严格的组合。我们当时排查过一个调用链上的超时问题，就是Feign配了5秒readTimeout，但Ribbon那边还是默认1秒，结果永远在1秒就挂了。

还有重试机制。Feign默认是不重试的，原因是重试会放大风险：如果下游接口不是幂等的，一个请求被重试两次，可能产生重复订单、重复扣款。所以设计上宁可快速失败，也不做盲目重试。如果真要重试，必须在业务层明确知道接口幂等，并且设置合理的重试次数和间隔。面试官问到这里，其实是在考察你对分布式系统里"幂等"这个概念的敏感度。

2.3 Fallback和FallbackFactory，细节差异别忽视

Feign整合Sentinel或Hystrix之后，熔断降级是常见考题。fallback和fallbackFactory这两个概念很多候选人分不清。简单说：fallback是实现了接口的降级类，被代理直接使用；fallbackFactory也是降级类，但它还实现了FallbackFactory接口，能在降级时拿到Throwable异常原因。能用FallbackFactory就尽量不用fallback，因为你在降级逻辑里需要记录到底是超时、连接拒绝还是业务异常导致的调用失败，否则排查问题无从下手。

还要补一个点：FallbackFactory里的异常信息并不一定准确反映真实故障，因为框架在熔断打开时触发fallback，并不会重新发起请求去拿真实异常，此时拿到的可能是熔断器自己包装的异常。这个细节如果你能在面试中主动讲出来，面试官会眼前一亮。

2.4 参数传递细节，现场手写别翻车

面试官偶尔会让你现场写一个Feign接口，考察你对参数传递的掌握。常见写法：GET请求用@RequestParam逐个传参，不能直接传对象；POST用@RequestBody传JSON；传请求头用@RequestHeader。还有一个容易被问到的坑：Feign传文件怎么办？用@PostConsumer配合MultipartFile，并且FeignClient需要配置Encoder为SpringFormEncoder。

另外一个很常见的需求是透传Token。服务A通过Feign调用服务B时，如果B需要校验请求头里的token，默认Feign不会自动携带上游请求头，你需要写一个RequestInterceptor，把当前请求上下文里的Authorization头拷贝到Feign模板里。这个回答非常实战，面试官一听就知道你处理过真实的跨服务鉴权场景。

3. 负载均衡的核心考点：选型对比、策略逻辑、自定义规则

3.1 你用的负载均衡到底是谁提供的

很多人以为OpenFeign自带负载均衡，其实不是。Feign只是个HTTP客户端，它负责把请求发出去，但"发给哪个实例"是由负载均衡组件决定的。老项目里通常是Ribbon，Spring Cloud 2020年之后Ribbon进入维护模式，官方推荐Spring Cloud LoadBalancer，但面试题还是会问Ribbon，因为存量项目太多了。

这里要答出几个关键的类：IRule是负载均衡策略的接口，ServerList是获取可用服务实例列表的接口，ServerListUpdater负责动态更新实例列表。Ribbon的核心流程是：先通过ServerList拿到可用实例列表，然后根据IRule选出一个Server，最后发起请求。默认策略是ZoneAvoidanceRule，它会先过滤掉故障zone，再在剩余zone里使用轮询策略。很多面试答案说Ribbon默认是RoundRobin，这个其实不严谨，要纠正过来。

3.2 常见负载均衡策略，适用场景要分清

我在表格里整理一下最常见的几种策略和它们的适用场景，面试时直接照着这个思路说就行：

面试官问到这里一般还会加一句：实际项目中你们怎么选的？不要只说"我们用的默认策略"。你可以分享一下：如果服务部署的机器配置有差异，就优先用WeightedResponseTimeRule，因为慢的机器自然分到的流量少；如果所有机器规格一致，RoundRobin就够了，复杂策略反而增加排查成本。

3.3 自定义负载均衡策略，灰度发布的敲门砖

自定义策略是面试加分项。最朴实的方式是继承AbstractLoadBalancerRule，重写choose方法。choose里面拿到LoadBalancer，先获取所有服务器列表，然后按你的规则筛选。最常见的自定义场景是灰度发布：从配置中心读取当前请求的用户属于金丝雀分组，如果匹配则只选择带有"gray=true"标签的实例，否则选择普通实例。

但这里有一个容易忽视的坑：自定义规则里如果查配置中心或者Redis，每次choose都会走一次远程IO，那你的负载均衡性能就废了。正确做法是加本地缓存，配置变更时通过监听器刷新缓存。这个点说出来，面试官会知道你真的做过灰度方案，而不是背了个模板。

还有一点建议：在Spring Cloud LoadBalancer中，自定义方式略有不同，需要实现Reactor的ServiceInstanceListSupplier接口，属于响应式写法，如果你面试时主动提一句"两种组件的自定义方式都了解"，会显得知识面更全面。

4. 服务容错的底层逻辑：熔断、降级、隔离三件套

4.1 雪崩是怎么发生的，为什么必须有三件套

服务A调用服务B，服务B出问题了响应变慢，A的线程就被占住了。如果大量请求同时卡在等B响应，A自己的线程池就满了，A也变得不可用，然后C来调A也挂掉。这就是服务雪崩。而熔断、降级、隔离三件套分别对应三个层面的问题：熔断是"下游挂了就别再往里打"，降级是"拿不到真实结果就返回一个兜底结果"，隔离是"某个下游的故障只影响它自己的线程资源，不许拖垮整个服务"。

面试官问"你们怎么防止雪崩"时，一定要把这三者的分工说清楚，而不是笼统地说"我们用了Sentinel"。很多人把熔断和降级混为一谈，一开口就露馅了。

4.2 线程池隔离 vs 信号量隔离，怎么选

以Hystrix为例，它提供了两种隔离方式。线程池隔离为每个依赖服务分配一个独立的线程池，调用下游的请求在这个独立线程池中执行，即使这个依赖崩溃，主线程池也不会被占满。代价是线程切换有额外开销，每个依赖都要占资源，线程池数量多了之后内存和上下文切换压力都大。

信号量隔离不创建独立线程池，只是用信号量计数器限制并发数，超过阈值的请求直接拒绝。它更轻量，但无法解决慢调用堆积的问题：如果下游很慢，大量线程还是阻塞在等待响应上，信号量只能限制入口数量，控制不了线程被占用的时间。

实际项目怎么选？追求高隔离性、下游不稳定的场景用线程池隔离；调用量极大、下游相对可靠的场景用信号量隔离。另外现在主流已经是Sentinel，它默认通过流量控制来防止线程堆积，你可以说"我们在Sentinel中配置了并发线程数限制来实现信号量隔离效果"，这样既体现你对旧技术的理解，又体现你对新技术的应用。

4.3 熔断状态机，半开状态是重头戏

熔断器是一个状态机：关闭（Closed）、打开（Open）、半开（Half-Open）。关闭状态下正常放行请求，但统计失败率和请求量；当满足熔断条件时，状态变为Open，此时所有请求快速失败，不进真实调用；经过一个窗口时间后，进入半开状态，允许少量探测请求通过，观察这些探测请求的成功率。如果成功，熔断器重新关闭；如果失败，继续打开。

默认参数要记准：以Hystrix为例，requestVolumeThreshold是20（10秒内请求数达到20才可能熔断），errorThresholdPercentage是50（错误率超过50%触发熔断），sleepWindow是5000毫秒（打开后经过5秒进入半开）。Sentinel里则是通过熔断规则配置，支持慢调用比例、异常比例、异常数三种模式。

面试官追问"为什么需要半开状态"，答案是：完全打开后可能下游已经恢复了，但你还是一刀切地拒绝，会造成不必要的请求失败。半开就是给下游一个"试恢复"的机会。这个状态机考察的是你对分布式系统容错设计的理解深度，值得仔细说。

4.4 降级策略设计，别只答一个"返回默认值"

降级不是简单的try-catch。好的降级设计要有层次：第一层优先尝试缓存数据，缓存里也没有就返回空集合或者友好提示；还要区分触发原因——是超时降级、异常降级还是熔断触发降级，不同原因要有不同的日志记录，方便事后分析。这里可以提一句业务上最怕的是"静默降级"：线上大量请求走了降级逻辑，但监控没有告警，业务方以为服务正常，实际上体验已经在崩坏。

降级结果的格式也要考虑对齐。我们项目里统一封装了一个Result对象，降级走ResponseCode枚举中专门的"服务不可用"码，前端拿到这个码会显示对应的兜底页面，而不是解析一堆空值把自己搞挂。面试时能讲出这种细节，比背十遍"降级就是fallback"得分高得多。

5. 配置中心的配置哲学：动态刷新到底怎么动

5.1 配置中心解决的第一件事是"环境分离"

微服务少则十几个，多则几十个，每个服务有dev、test、prod多套环境，如果配置文件散落在各个服务里，改一个数据库地址要重新打包部署，效率极低。配置中心就是把"配置"从"应用"中剥离出来统一管理，应用启动时从配置中心拉取，运行时还能动态刷新。

这个问题的考察点在于：你要说清楚配置中心的三大价值——集中管理（一处修改全部生效）、环境隔离（不同环境不同配置）、动态刷新（无需重启即可变更）。很多人上来就讲"我们的注册中心是Nacos"，然后又说"配置中心也是Nacos"，但没有分清楚注册和配置是两个不同的模块，面试官会怀疑你概念不清晰。

5.2 Nacos配置动态刷新，原理要讲透

Nacos配置中心之所以能实现动态刷新，核心是长轮询机制：客户端向服务端发起一个长时间挂起的请求，服务端在配置变更时立即返回响应，客户端拿到变更通知后重新拉取配置。这个机制既是推也是拉，服务端有变更就响应，没有变更就挂着等超时重新连，避免了频繁建连。

但这里有一个关键点：配置变了，Spring容器里的Bean不一定会自动更新。你需要用@RefreshScope标注那些希望动态刷新的Bean，框架会为它们创建代理，配置变更时销毁旧Bean并重新创建。这个原理面试官经常追问，因为很多人只知道加注解，不知道为什么加。你可以解释：如果Bean是普通单例，创建时已经把配置值固化到属性里了，外面改配置也不会变；@RefreshScope就是把这个Bean放入一个可刷新的作用域中，refresh事件发生时让旧实例失效。

同理，Spring Cloud Config的老方案是通过Spring Cloud Bus连消息总线，调用/actuator/bus-refresh端点向所有实例广播刷新事件。面试时可以把Nacos的长轮询改成这样——"Nacos这种方式更灵活，不需要额外引入消息中间件"。

5.3 配置优先级，版本差异是个坑

配置优先级在Spring Cloud Alibaba的Nacos场景下比较微妙。在较新的版本中，本地配置文件（application.yml）的优先级默认高于Nacos的远程配置，而早期版本里bootstrap加载的远程配置优先级更高。这种差异会导致一个现象：本地配了一个key，Nacos里也配了同一个key，不同版本的项目跑出来的结果完全不一样。

面试里如果你能主动说一句"这个优先级在不同版本上有变化，我一般在Nacos的配置管理中调整加载顺序，并且会在启动日志里打印当前生效的配置源"，就能体现出你真的踩过这个坑。生产环境上我强烈建议：统一团队依赖的Spring Cloud Alibaba版本，并且把配置中心里每个服务的"配置来源说明"写清楚，否则排查配置不生效的问题会花掉大半天。

还有个很经典的实战坑：数据源连接串放在Nacos里，用@RefreshScope刷新了，但连接池没有重建，新配置不生效。原因是DataSource在被创建时连接池已经初始化了，单纯改变量值不会重建连接。要么不用@RefreshScope硬刷，要么在配置变更后通过监听器调用连接池的重建方法。这个问题非常高频，答上这句就赢了。

6. 网关适配：GateWay常见考点与动态路由

6.1 GateWay和Zuul 1.x，本质是线程模型的差别

网关题目几乎必问Spring Cloud Gateway和Zuul的区别。Zuul 1.x基于Servlet构建，采用阻塞式I/O模型，每个请求独占一个线程，线程等待下游响应时被白白占用。并发量一上来，线程数激增，上下文切换开销暴涨。Spring Cloud Gateway基于Spring WebFlux和Netty，是响应式非阻塞模型，少量线程配合事件循环就能处理大量并发请求，吞吐量高很多。

回答时最好加一个自己的理解：响应式模型也不是万能的。如果你的路由过滤器中做了阻塞操作，比如同步的JDBC访问、锁等待，那么Netty的事件循环线程就被卡住了，整个网关吞吐骤降。所以网关里尽量用异步操作，真需要查数据库也走异步客户端。这个点能讲出来，比单纯背"Zuul是阻塞的，Gateway是非阻塞的"高一个层次。

6.2 路由、断言、过滤器的三角关系

Gateway里Route是路由规则，指定了"什么请求转发到哪个目标地址"；Predicate是断言条件，例如Path=/api/user/**、Method=GET、Header=X-Token等于某个值；Filter是过滤器，在请求转发前后做处理。三者组合之后就是一条完整路由：满足断言条件的请求，先经过过滤器链处理，再转发到目标地址。

GlobalFilter和GatewayFilter的区别一定要说清：GatewayFilter是绑定在某个路由上的，写路由配置时通过filters指定；GlobalFilter对所有路由全局生效。常见的鉴权、日志记录、限流、跨域处理都通过GlobalFilter实现。另外Gateway的过滤器分pre和post两类，pre在转发前修改请求，post在响应返回后处理。顺序问题也很重要，Order值小的先执行，全局过滤器默认Order是MAX_VALUE，可以用@Order调整。

6.3 动态路由，面试加分项

路由配置通常写在application.yml里，但生产环境想改路由规则不能重启网关。这时可以把路由数据存到Nacos或数据库中，然后实现RouteDefinitionRepository接口，自定义一个repository来加载路由定义。常见的做法是用监听器监听配置变更事件，变更时重新拉取路由列表并更新RouteDefinition。

这里可以顺带提一下：网关路由是瞬时的，刷新时要考虑并发情况，别在请求高峰期把路由全量替换，最好做灰度切换。而且新增路由时要校验目标地址连通性，否则配置一个拼写错误的URI，所有匹配这个路由的请求都会打到不存在的地址上。面试官听到这些细节，基本就能判断你不是只写过demo。

6.4 网关层的常见坑：跨域、限流、鉴权

跨域是网关问题榜单上的常客。CORS配置中有两个要点：allowedOrigin不要设置成""，因为""和allowCredentials(true)不能同时使用，浏览器会直接拒绝；建议配置具体的域名白名单。预检请求OPTIONS也记得要放行，不要被鉴权过滤器拦截，否则前端跨域请求会先死在预检上。

限流在网关层通常用RequestRateLimiter过滤器工厂，配合Redis实现令牌桶限流，通过KeyResolver自定义限流维度，比如按用户ID、按IP、按请求路径。面试时可以给出一个实际配置片段的思路："

spring: cloud: gateway: routes: - id: demo-route uri: lb://demo-service predicates: - Path=/demo/** filters: - name: RequestRateLimiter args: redis-rate-limiter.replenishRate: 10 redis-rate-limiter.burstCapacity: 20 key-resolver: "#{@userKeyResolver}"

这个配置里replenishRate表示每秒往桶里放10个令牌，burstCapacity是桶容量20，超过20的直接被限掉。合适吗？一般网关层做粗粒度限流可以这么配，细粒度限流建议在业务服务里另行控制。

鉴权一般通过GlobalFilter做JWT校验，维护一个白名单列表，登录接口、健康检查接口直接放行，其他接口在校验通过后把用户信息放入请求头透传给下游服务。注意透传时header的命名要统一，避免和下游业务参数冲突。

7. 面试话术与现场避坑：怎样把"知道"变成"会说"

7.1 高频翻车点：概念混淆

我在面试里发现的第一个高频翻车点是把注册中心和配置中心搞混。两者都叫"中心"，但职责完全不同：注册中心管服务实例的地址和健康状态，配置中心管应用的配置内容和动态刷新。很多人在Nacos里创建了服务列表，又建了配置文件，但让他说清楚数据存储和心跳机制时，显然没分清。

第二个高频翻车点是把Ribbon和Feign的关系说反。正确的是：Feign负责发起HTTP请求并解析响应，Ribbon负责从服务列表中选一个目标实例。注意Ribbon不是Feign里的一部分，是Feign整合了Ribbon。Spring Cloud LoadBalancer同理。

第三个高频翻车点是熔断、降级、限流三件事混在一起说。我用最简短的表述帮你理清：熔断是"下游不行了，我主动断开"，降级是"断开后返回兜底结果"，限流是"我快扛不住了，控制一下入口流量"。三者有联系但出发点不同。

7.2 回答问题的"先结论，再展开，后举例"结构

面试不是笔试，面试官考察的是你能不能有逻辑地表达。我建议每次回答都用这个结构：第一句直接给结论，比如"Eureka是AP架构，注册中心选择AP是因为可用性比强一致更关键"；然后展开两到三句话解释为什么；最后举一个项目里的实例。例如：

"Eureka是AP架构，因为注册中心在分布式环境下分区出现时，选择保留可用性，让服务间还能互相调用，而不是拒绝服务等待数据同步。我们之前有过一次网络抖动，某机房和其他机房断开，Eureka因为自我保护保留了所有实例列表，服务照样能调，虽然拿到的实例列表稍微旧一点，但整体没挂。"

这样回答，面试官不需要从你的长篇大论里提取重点，他只需要听你的第一句话就已经能给你打分了。而且这个结构天然避免了你被追问时逻辑混乱——你已经把结论、原因、案例都讲完了，追问只会往更深的地方走。

7.3 我总结的几条实战心得

第一，面试前一定要把自己项目里用到的组件版本列出来。Spring Cloud的版本迭代非常频繁，不同版本的默认行为和配置项差异很大。你说"我们用的Spring Cloud版本是2021.0.3，底层负载均衡是Spring Cloud LoadBalancer"比"我们用的Ribbon"更准确，也体现出你关注技术演进。

第二，回答容错相关问题时，尽量提到"我们线上遇到过……"的真实案例。哪怕你只是协助排查过，只要你能把现象、定位过程、最终方案讲出来，面试官就不会觉得你在背书。有一次候选人讲到他们的服务在促销高峰期被下游慢接口拖垮，然后通过Sentinel配置了线程数限流和熔断规则，让故障范围只限于一个下游时，全场面试官都明显更专注了。

第三，不要硬聊自己没碰过的东西。面试官问"你用过Hystrix吗"，你如果只做过Sentinel，就说"我们项目用的是Sentinel，Hystrix我了解它的线程池隔离和熔断模型，但生产环境没跑过"，然后把话题导向Sentinel的具体实践。面试官更反感的是编造经验，而不是诚实。

这篇先讲到这里。服务治理主链路——注册、调用、负载均衡、容错、配置、网关——是目前Spring Cloud面试中出现频率最高、也是实战价值最大的部分。后续我会继续整理源码层面的经典追问，比如Eureka缓存一致性、Feign生成代理的具体流程、Gateway过滤器链的装配顺序，以及链路追踪和分布式事务相关的高频问题。如果你正在准备微服务方向的面试，建议先把这篇里的追问都自己对着镜子讲一遍，讲到能不看笔记说顺为止。