工作知识库

Appearance

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

生成时间：2026-05-22 22:53

【面试题】1. Eureka的自我保护机制是什么？为什么要这样设计？ ​

【标准答案】 自我保护机制是Eureka为了防止网络分区故障导致服务被错误剔除而设计的保护策略。

当Eureka Server在短时间内丢失超过85%的心跳时，会触发自我保护，不再剔除任何服务实例。即使有服务真的挂了，也保留在注册表中。

设计原因：网络抖动比服务宕机更常见。如果因为短暂的网络问题就把服务剔除，会导致大面积服务不可用——这比保留几个僵尸实例的危害更大。自我保护本质上是"宁可保留错误数据，也不删除正确数据"的AP模型体现。

关闭方式：eureka.server.enable-self-preservation=false（生产环境不建议关闭）

【面试题】2. Nacos作为注册中心，与Eureka的核心区别是什么？ ​

【标准答案】 核心区别有三点：

  1. CAP模型支持：Eureka只支持AP（高可用优先），Nacos支持AP和CP可切换，通过nacos.core.protocol.raft.data配置，CP模式基于Raft协议保证一致性。

  2. 功能范围：Nacos = 注册中心 + 配置中心，Eureka只是注册中心。Nacos同时支持服务发现和动态配置管理。

  3. 健康检查：Eureka依赖客户端心跳，Nacos支持主动健康检查（TCP/HTTP/MySQL多种探活方式），检测更准确。

  4. 性能：Nacos基于长连接推送变更，Eureka客户端定时拉取注册表。Nacos实时性更好，Eureka有30秒延迟。

【面试题】3. Spring Cloud Gateway如何实现灰度发布？ ​

【标准答案】 灰度发布通过Gateway的动态路由和过滤器实现，核心方案：

方案一：基于请求头路由

yaml
spring:
  cloud:
    gateway:
      routes:
        - id: user-service-v2
          uri: lb://user-service-v2
          predicates:
            - Header=gray, true
        - id: user-service-v1
          uri: lb://user-service-v1
          predicates:
            - Path=/user/**

带gray: true请求头的流量走v2版本，其他走v1。

方案二：基于权重路由

yaml
predicates:
  - Weight=group1, 80  # 80%流量走v1

方案三：结合Nacos动态配置 通过Nacos配置中心实时调整路由规则，无需重启网关。

配合负载均衡策略，可以让灰度更精细化，比如按用户ID哈希分流，保证同一用户始终访问同一版本。

【面试题】4. Sentinel和Hystrix在熔断机制上有什么区别？ ​

【标准答案】 主要有四点区别：

  1. 熔断状态机：两者都是三态（关闭→打开→半开），但Sentinel的半开状态可以配置探测请求数和比例阈值，更灵活。

  2. 限流能力：Hystrix只有熔断和隔离，Sentinel内置多种限流算法（QPS、并发线程数、滑动窗口、令牌桶）。Sentinel是熔断+限流一体化方案。

  3. 资源隔离：Hystrix依赖线程池隔离，Sentinel支持线程池和信号量两种模式，且信号量模式性能更高。

  4. 监控可视化：Sentinel有完善的Dashboard，实时监控、动态规则配置一站式完成；Hystrix需要整合Turbine或Dashboard。

  5. 维护状态：Hystrix已进入维护模式，官方推荐使用Resilience4j或Sentinel。

【面试题】5. 解释Seata的AT模式实现原理，它如何保证分布式事务一致性？ ​

【标准答案】 AT模式是Seata的核心方案，全称是Automatic Transaction模式，核心原理：

一阶段（本地事务执行）：

  • 执行业务SQL，记录前后镜像（before image、after image）到undo_log表
  • 生成行锁，防止并发修改
  • 本地事务提交，释放本地锁

二阶段（全局提交/回滚）：

  • 提交：异步删除undo_log，性能高
  • 回滚：根据undo_log反向生成SQL恢复数据

关键设计：

  • 全局锁：保证全局事务间的写隔离，防止脏写
  • 一阶段本地提交：不阻塞，性能接近本地事务
  • 补偿机制：通过undo_log实现数据回滚

AT模式适合对一致性要求高、但可以接受短暂中间状态的场景，如电商下单、库存扣减等。缺点是不支持复杂业务逻辑的补偿。

【面试题】6. Redis分布式锁如何实现？Redisson的看门狗机制是什么？ ​

【标准答案】 基础实现（SET NX EX）：

java
// 加锁
SET lock_key unique_value NX EX 30
// 释放锁（Lua保证原子性）
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("del", KEYS[1])
end
return 0

Redisson看门狗机制： 问题：锁过期时间设置30秒，业务执行50秒，锁提前释放怎么办？

解决：Redisson默认启动后台线程（看门狗），每隔锁过期时间的1/3（默认10秒）检查一次，如果持有锁的线程还在运行，自动续期到30秒。

java
RLock lock = redisson.getLock("myLock");
lock.lock(); // 启动看门狗
try {
    // 业务逻辑，即使超过30秒也不会丢失锁
} finally {
    lock.unlock();
}

RedLock方案：多Redis节点，多数派成功才算加锁成功，防止单点故障。

【面试题】7. 微服务架构中，如何保证消息队列的可靠性投递？ ​

【标准答案】 可靠性投递的核心是保证"消息不丢失"，分三阶段：

生产端：

  1. 开启事务消息或确认机制（confirm callback）
  2. 消息持久化到本地消息表，定时任务重试
  3. RocketMQ的事务消息：半消息+本地事务+提交/回滚

Broker端：

  1. 同步刷盘（性能换可靠性）
  2. 多副本同步复制（主从同步）
  3. 消息确认机制返回ACK

消费端：

  1. 手动ACK，业务处理成功后确认
  2. 消费失败进入重试队列或死信队列
  3. 幂等性设计：消息ID去重，防止重复消费

完整方案：

生产者 → 本地消息表 → MQ Broker → 消费者 → ACK
   ↑           ↓
   └───── 定时重试 ←────┘

【面试题】8. 链路追踪中TraceId和SpanId是如何传递的？跨线程如何处理？ ​

【标准答案】 传递机制：

  • HTTP调用：通过请求头传递（如X-Trace-Id、X-Span-Id）
  • RPC调用：通过RPC框架的隐式传参（如Dubbo的Attachment）
  • MQ调用：通过消息属性传递

SpanId编码规则：采用层级编码，如0.1.2表示第三个服务的第二个调用的第一个子调用。

跨线程处理： Sleuth使用Tracer在创建新线程时手动传递：

java
// 方式一：手动传递
Span span = tracer.currentSpan();
executor.submit(() -> {
    try (Tracer.SpanInScope ws = tracer.withSpan(span)) {
        // 子线程中能获取到父线程的TraceId
    }
});

// 方式二：使用@Async + Sleuth自动包装
@Async
public void asyncMethod() {
    // TraceContext自动传播
}

注意事项：线程池需要包装为LazyTraceExecutor，否则TraceId会丢失。

【面试题】9. Spring Cloud Stream如何实现消费者的负载均衡？ ​

【标准答案】 Stream通过consumer group实现消费者负载均衡：

核心配置：

yaml
spring:
  cloud:
    stream:
      bindings:
        input:
          group: order-group  # 同一group的消费者形成竞争关系
          destination: order-topic

负载均衡原理：

  • 同一group的多个消费者订阅同一Topic，消息只会被其中一个消费
  • 不同group的消费者会各自收到完整消息副本（广播）

分区消费：

yaml
bindings:
  input:
    consumer:
      partitioned: true
      instanceCount: 3  # 总实例数
      instanceIndex: 0  # 当前实例索引

消息按key哈希分配到固定分区，保证同一key的消息顺序性。

重平衡机制：消费者上下线时，Rebalance重新分配分区，类似Kafka的协调器机制。

【面试题】10. 如何设计一个高可用的微服务网关架构？ ​

【标准答案】 高可用网关架构设计要点：

1. 网关集群部署

  • 多实例部署，前面挂Nginx或SLB做负载均衡
  • 无状态设计，任意实例可替换

2. 注册中心联动

  • 网关注册到注册中心，支持动态发现
  • 客户端通过注册中心发现网关实例

3. 限流熔断

  • 网关层面限流（令牌桶、漏桶）
  • 集成Sentinel对下游服务熔断保护

4. 灰度发布

  • 网关路由规则动态配置
  • 支持权重分流、蓝绿部署

5. 安全防护

  • JWT/OAuth2统一鉴权
  • 黑名单、防刷、WAF集成

6. 监控告警

  • 接口耗时、QPS、错误率实时监控
  • 接入Prometheus + Grafana

7. 故障降级

  • 网关自身故障时，Nginx兜底返回降级页面
  • 下游服务故障时，返回缓存或默认响应

架构图：

Client → Nginx/SLB → Gateway集群 → 后端微服务
              ↓
        注册中心(Nacos)
              ↓
        配置中心 + Sentinel Dashboard

本轮题目覆盖：服务注册、配置中心、API网关、熔断限流、分布式事务、分布式锁、消息队列、链路追踪、负载均衡、高可用架构设计