本轮 SpringCloud微服务架构面试题库（带答案）
生成时间：2026-05-21 23:08
【面试题】1. Eureka的自我保护机制是什么？为什么需要它？生产环境到底该不该开？
【标准答案】自我保护机制是Eureka Server在运行期间统计心跳失败比例，如果15分钟内超过85%的节点都没有正常心跳，Eureka Server就会进入自我保护模式——不再剔除服务实例。核心思想是"宁可保留可能不健康的服务，也不盲目剔除可能健康的服务"，因为Eureka采用的是AP模型，可用性优先于一致性。如果网络抖动导致大面积心跳失败，关闭自我保护会把大量实际可用的服务踢掉，造成雪崩。生产环境建议开启自我保护，但要做好配套措施：客户端配置缓存、重试、熔断，不能完全依赖注册中心的实时性。同时调整心跳间隔和续约时间（lease-renewal-interval-in-seconds、lease-expiration-duration-in-seconds），让感知速度和稳定性达到平衡。
【面试题】2. Sentinel的限流算法有哪些？令牌桶和漏桶有什么区别？Sentinel默认用的是什么？
【标准答案】Sentinel支持多种限流算法，核心是滑动窗口（统计时间窗口内的请求数），还支持排队等待（匀速器，本质是漏桶思想）和预热冷启动（令牌桶思想）。令牌桶和漏桶的关键区别：令牌桶允许一定程度的突发流量——桶里有令牌就可以立即消费，所以短时间突发请求可以通过；漏桶是匀速流出，不管你进来多猛，出去永远是固定速率，适合做平滑限流。Sentinel默认使用滑动窗口算法做直接限流（QPS统计），配合控制台配置规则。实际项目中，对突发流量有容忍的场景用令牌桶思路（warm-up），对需要严格匀速的场景用排队等待（漏桶思路）。
【面试题】3. Seata的AT模式工作原理是什么？它和TCC模式各适用什么场景？
【标准答案】AT模式是Seata的自动分布式事务模式，对业务零侵入。核心流程：一阶段——拦截业务SQL，执行前先查询修改前的数据生成before-image，执行SQL后再查询修改后的数据生成after-image，组成undo-log一起提交；二阶段提交——异步删除undo-log；二阶段回滚——根据undo-log的before-image反向补偿，恢复数据。AT模式适合大多数常规业务（订单、库存、账户），因为侵入低、开发简单。TCC模式需要业务方自己实现Try/Confirm/Cancel三个方法，侵入性强，但灵活性高，适合需要精细化控制资源的场景——比如库存预扣不能简单回滚，而是要记录冻结数量；或者涉及第三方接口无法通过SQL回滚的场景。一句话：AT简单通用，TCC灵活可控，选型先试AT，搞不定再上TCC。
【面试题】4. Spring Cloud Gateway的过滤器链是怎么工作的？如何实现统一鉴权？
【标准答案】Gateway的过滤器分两类：Global Filter和Gateway Filter。Gateway Filter是路由级别的，配置在具体路由上；Global Filter是全局的，所有路由都生效。请求进来后经过路由断言匹配，然后按顺序执行Pre过滤器链，转发到后端服务，响应回来再逆序执行Post过滤器链。统一鉴权的标准做法：自定义一个GlobalFilter，实现Ordered接口设为最高优先级（如Ordered.HIGHEST_PRECEDENCE），在filter方法中从请求头提取Token，校验JWT签名和过期时间，校验通过则放行（chain.filter继续），校验失败则设置响应状态码401并return。Gateway做鉴权的核心优势是所有微服务不用各自实现鉴权逻辑，网关层统一拦截，后端服务只做业务。但要注意：网关鉴权后需要把用户信息（userId、角色等）通过请求头传递给下游服务，通常放在header里透传。
【面试题】5. Nacos作为配置中心，配置热更新的原理是什么？和Spring Cloud Config比有什么优势？
【标准答案】Nacos配置热更新的原理：客户端启动时用长轮询（Long Polling）机制监听配置变化——客户端发起HTTP请求到Nacos Server，带上当前配置的md5值和服务端对比，如果一致则挂起连接（默认30秒超时），期间有配置变更立即返回；如果不一致立刻返回新配置。客户端收到变更后触发RefreshEvent，Spring Cloud刷新@RefreshScope标注的Bean和@Value标注的属性。对比Spring Cloud Config的优势：（1）Config依赖Git存储，变更要推送Git再触发Webhook通知，链路长；Nacos自建存储，改了即生效；（2）Config Server本身无高可用，要借助Git仓库做版本管理；Nacos自带集群和持久化（内嵌Derby或MySQL）；（3）Config没有管理界面，Nacos有完整的控制台；（4）Config需要配合Bus做批量通知，Nacos天然支持长轮询推送。实际选型上，Spring Cloud Alibaba全家桶下Nacos是标配。
【面试题】6. Redis分布式锁用SET NX EX实现有什么问题？Redisson是怎么解决的？
【标准答案】SET NX EX的核心问题有三个：第一，锁续期问题——如果业务执行时间超过锁的过期时间，锁自动释放，其他线程拿到锁，导致并发安全问题；第二，锁误删——线程A的锁过期后，线程B加锁成功，线程A执行完去删锁，把B的锁删了；第三，单点故障——Redis主节点宕机，锁数据可能未同步到从节点。Redisson的解决方案：锁续期用看门狗（Watchdog）机制——默认锁30秒，后台线程每10秒（1/3过期时间）自动续期，业务没执行完就一直续，执行完释放锁就停止续期。锁误删问题通过锁的value设为唯一标识（UUID+线程ID），释放时用Lua脚本判断value一致才删除，保证原子性。单点故障用RedLock算法——向多个独立Redis实例同时加锁，超过半数成功才算获取锁。实际项目中用Redisson开箱即用，不建议自己手写分布式锁。
【面试题】7. OpenFeign的超时和重试怎么配置？有什么坑需要注意？
【标准答案】OpenFeign的超时分两层：连接超时（connectTimeout）和读超时（readTimeout）。配置方式有两种：全局配置通过feign.client.config.default.connectTimeout和readTimeout；指定服务配置通过feign.client.config.<service-name>.connectTimeout。重试默认关闭（Retryer.NEVER_RETRY），需要自定义Retryer开启。坑主要有三个：第一，Ribbon也有超时配置（ConnectTimeout和ReadTimeout），如果同时配置了Ribbon和Feign的超时，Feign优先使用自己的；如果没配Feign的超时则走Ribbon的——容易搞混。第二，重试要小心非幂等接口（POST等），默认重试会对所有请求重试，必须配置只对GET重试或者关闭非幂等请求重试。第三，超时时间不能一刀切，不同接口设置不同超时——快速接口（如检查状态）短超时，慢接口（如报表导出）长超时，避免全局长超时拖垮整个链路。
【面试题】8. 链路追踪中TraceId是怎么跨服务传递的？Sleuth是怎么实现的？
【标准答案】TraceId跨服务传递的核心是把它塞进HTTP请求头里。Sleuth的实现：服务A发起调用时，Sleuth通过拦截器（RestTemplate用LazyTracingClientHttpRequestInterceptor，Feign用TracingFeignClient）在请求头中注入traceId（X-B3-TraceId）、spanId（X-B3-SpanId）、parentSpanId（X-B3-ParentSpanId）等信息。服务B收到请求后，Sleuth的Filter（如TracingFilter）从请求头中提取这些值，绑定到当前线程的Span上下文中，继续传递给下游调用。整个传递链路是透明的，业务代码无需关心。关键细节：异步场景（线程池、@Async）下ThreadLocal会丢失，Sleuth提供LazyTraceExecutor包装线程池，确保TraceId传递到子线程。如果用消息队列，Sleuth也在消息头中注入/提取TraceId。Zipkin收集到数据后按TraceId聚合，就能看到完整的调用链拓扑。
【面试题】9. 微服务灰度发布怎么做？Spring Cloud Gateway怎么配合实现？
【标准答案】灰度发布的核心是流量按规则路由到不同版本的服务实例。实现方案分两层：网关层路由和注册中心元数据路由。网关层方案：在Gateway中自定义Predicate或Filter，根据请求头（如gray-tag=v2）、Cookie、UID取模等条件，将流量路由到灰度版本的服务实例。注册中心元数据方案：Nacos支持实例metadata，灰度实例打上version=gray标签，Gateway或LoadBalancer根据标签做实例过滤——灰度请求只选gray实例，正常请求只选stable实例。具体实现：Nacos实例注册时配置metadata: {version: "gray"}；自定义ReactorLoadBalancerClientFilter或ServiceInstanceListSupplier，根据请求标记筛选实例。更成熟的方案是结合Istio做Service Mesh层面的流量管理，支持按权重、按Header精确路由。灰度策略上一般先内部测试→小流量（1%-5%）→逐步扩大→全量，配合监控和快速回滚机制。
【面试题】10. Spring Cloud Alibaba全家桶的组件怎么选型？Nacos+Sentinel+Seata+RocketMQ这套组合的优势是什么？
【标准答案】Spring Cloud Alibaba全家桶的选型逻辑：注册中心+配置中心选Nacos（一个组件搞定两个功能，自带管理界面和集群方案）；流量防护选Sentinel（比Hystrix更活跃、功能更全，支持流控、熔断、热点限流、系统保护）；分布式事务选Seata（AT模式低侵入，TCC/Saga/XA按需选择）；消息队列选RocketMQ（高可靠、支持事务消息和顺序消息，和Seata事务消息方案天然配合）；RPC选Dubbo（高性能二进制协议，适合内部服务间高频调用）。这套组合的优势：第一，组件之间深度整合——Sentinel可以给Dubbo和Gateway做流控，Seata的事务消息模式依赖RocketMQ，Nacos同时做注册和配置中心减少运维成本；第二，中文社区活跃，阿里大规模生产验证，文档和案例丰富；第三，统一的技术栈降低了版本冲突和兼容性问题，spring-cloud-alibaba-dependencies统一管理版本。对比Netflix OSS（Eureka+Hystrix+Zuul），Netflix组件大多停止维护，Alibaba全家桶是当前Java微服务的主流选择。