工作知识库

Appearance

SpringCloud微服务架构面试题库 ​

生成时间：2026-05-21 22:13

本轮 SpringCloud微服务架构面试题库（带答案） ​

【面试题】1. Eureka自我保护机制是什么？生产环境要不要关闭？ ​

【标准答案】自我保护机制是Eureka Server在短时间内丢失大量客户端心跳时，进入保护模式，不再剔除过期的服务实例，防止网络分区导致的误剔除。具体来说，当每分钟续约数低于阈值（默认85%）时触发。

生产建议：保留开启。 原因是网络抖动常见，关闭会导致服务被错误剔除。正确做法是优化心跳间隔和阈值，配合健康检查做细粒度控制，而不是简单关闭。

【面试题】2. Nacos作为注册中心，AP和CP模式怎么选？ ​

【标准答案】Nacos默认AP模式，强调可用性，允许分区内注册数据不一致，适合服务注册发现场景。CP模式用Raft协议保证一致性，但性能有损耗，适合对数据一致性要求高的场景，比如配置中心。

选择原则： 注册中心选AP（服务列表允许短暂不一致，但服务不能停）；配置中心选CP（配置错了会出大问题）。Nacos 2.x后配置默认用Raft，注册用Distro协议，各司其职。

【面试题】3. Ribbon和Spring Cloud LoadBalancer有什么区别？ ​

【标准答案】Ribbon进入维护状态，Spring Cloud LoadBalancer是官方推荐替代品。核心区别：

  • Ribbon：Netflix出品，功能丰富但长期不维护，支持自定义规则、ping、重试
  • LoadBalancer：Spring官方，基于Reactor响应式，代码轻量，默认轮询策略，易于扩展

迁移要点： LoadBalancer用@LoadBalanced注解同样生效，去掉Ribbon依赖，引入spring-cloud-starter-loadbalancer。自定义策略实现ReactorServiceInstanceLoadBalancer接口即可。

【面试题】4. OpenFeign的超时重试怎么配置？怎么避免无限重试？ ​

【标准答案】配置分两块：

yaml
feign:
  client:
    config:
      default:
        connectTimeout: 5000  # 连接超时
        readTimeout: 10000    # 读取超时

避免无限重试：

  1. Ribbon的超时必须大于Feign的readTimeout，否则Ribbon先超时触发重试
  2. 配置重试次数：ribbon.MaxAutoRetriesNextServer=1（换实例重试1次）
  3. 幂等接口才开启重试，非幂等操作直接返回错误

生产建议：连接超时短一些（2-5秒），读取超时根据业务最长耗时设置，重试次数控制在1-2次。

【面试题】5. Sentinel和Hystrix的核心区别是什么？ ​

【标准答案】两者定位类似但有本质区别：

  • 架构： Hystrix基于线程池隔离，资源消耗大；Sentinel基于信号量+滑动窗口，轻量高效
  • 限流： Hystrix只做熔断；Sentinel有QPS、并发线程数、热点参数等多种限流策略
  • 控制台： Hystrix监控弱；Sentinel有实时监控、动态规则推送、集群流控的完整Dashboard
  • 维护状态： Hystrix已停更；Sentinel是Alibaba维护，持续迭代

选型建议： 新项目用Sentinel，老项目迁移成本不高。Sentinel对Spring Cloud Alibaba集成好，配置更灵活。

【面试题】6. 熔断器的三个状态是什么？怎么流转的？ ​

【标准答案】熔断器状态机三态：

  1. 关闭状态（Closed）： 正常请求放行，统计失败率
  2. 打开状态（Open）： 快速失败，直接返回降级响应，持续一段时间（冷却期）
  3. 半开状态（Half-Open）： 放少量请求试探，成功则关闭，失败则重新打开

流转逻辑： 失败率超过阈值（如50%）且请求数达最小阈值 → 打开；冷却期后 → 半开；探测成功 → 关闭，失败 → 打开。

关键配置：失败率阈值、最小请求数、冷却时间。生产中冷却时间设长一点（30-60秒），避免频繁抖动。

【面试题】7. Spring Cloud Gateway的核心组件有哪些？请求处理流程是怎样的？ ​

【标准答案】三大核心组件：

  1. Route（路由）： ID、目标URI、断言集合、过滤器集合
  2. Predicate（断言）： 匹配条件，如路径、时间、Header、Cookie
  3. Filter（过滤器）： 请求/响应处理，分GatewayFilter（单路由）和GlobalFilter（全局）

处理流程：

  1. 客户端请求到达Gateway Handler Mapping
  2. 根据断言匹配路由，找到Handler
  3. 经过过滤器链（pre阶段处理请求）
  4. 转发到下游服务
  5. 响应返回，经过过滤器链（post阶段处理响应）
  6. 返回客户端

开发重点：自定义GlobalFilter做鉴权、限流、日志，注意过滤器Order顺序。

【面试题】8. Seata的AT模式原理是什么？有什么缺点？ ​

【标准答案】AT模式是Seata默认模式，核心原理：

  1. 一阶段： 执行业务SQL，解析SQL生成前后镜像，写入undo_log表，获取全局锁
  2. 二阶段提交： 删除undo_log，释放全局锁
  3. 二阶段回滚： 根据undo_log反向生成SQL，恢复数据

缺点：

  • 性能损耗：要写undo_log，有SQL解析开销
  • 脏写问题：需要全局锁，与非AT事务并发时可能死锁
  • 大事务风险：undo_log可能过大，回滚慢
  • 数据库侵入：每个库都要建undo_log表

适用场景： 对性能要求不是极致、能接受最终一致性的业务。高性能场景考虑TCC模式。

【面试题】9. Redis分布式锁怎么实现？Redisson解决了什么问题？ ​

【标准答案】基础实现用SET key value NX EX seconds，NX保证互斥，EX保证过期自动释放。

Redisson解决的经典问题：

  1. 锁续期： 看门狗机制，自动续约，防止业务未完成锁过期
  2. 锁释放： 只有锁持有者能释放，Lua脚本保证原子性
  3. 可重入： 支持同一线程多次加锁
  4. 集群安全： RedLock算法解决主从切换丢锁问题

生产建议： 不要自己造轮子，直接用Redisson。关键配置：waitTime（等待时间）、leaseTime（租约时间）、lock()失败是否立即返回。

【面试题】10. Spring Cloud Stream怎么保证消息可靠性投递？ ​

【标准答案】可靠性分三段保证：

  1. 生产端： 开启事务或Confirm机制，消息落库后发送，失败重试+报警
  2. Broker端： 多副本同步复制，配置min.insync.replicas保证至少写入几个副本
  3. 消费端： 手动ACK，消费成功后提交offset，失败重试或死信队列

Stream配置要点：

yaml
spring:
  cloud:
    stream:
      bindings:
        output:
          destination: myTopic
          producer:
            required-acks: 1  # 确认模式
        input:
          consumer:
            ack-mode: manual  # 手动确认
            max-attempts: 3   # 重试次数

防消息积压： 增加消费者实例数、开启并发消费、优化消费逻辑、设置合理的预取数量。

总结 ​

本轮覆盖考点：服务注册发现、负载均衡、服务调用、熔断限流、API网关、分布式事务、分布式锁、消息队列。

建议复习重点：

  • Nacos AP/CP选择策略
  • Sentinel限流算法与规则配置
  • Gateway过滤器链与自定义实现
  • Seata AT模式原理与缺陷
  • Redisson分布式锁最佳实践

生成系统：QClaw Cron Job (cdc404be-a5a1-41b0-a514-3cb8ba97551d)生成时间：2026-05-21 22:13:00