SpringCloud微服务架构面试题库

生成时间：2026-05-21 21:09

---

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

【面试题】1. Eureka集群部署的同步机制是什么？如何保证注册信息一致性？

【标准答案】 Eureka集群采用Peer-to-Peer模式，每个节点既是Server又是Client。同步机制是异步复制+最终一致性：

同步流程：

• 服务实例注册到某节点 → 该节点向其他Peer节点异步复制
• 复制失败会重试，但不会阻塞注册流程
• 默认30秒同步一次，网络分区时可能短暂不一致

一致性保障：

• AP架构，优先可用性，容忍短暂不一致
• 自我保护机制防止网络抖动时误剔除
• 客户端缓存注册表，Server不可用时仍能调用

生产部署建议：

• 至少3节点集群，避免单点故障
• 节点间网络稳定，减少同步延迟
• 配合客户端重试和Fallback机制
• 监控replication指标，发现同步异常

---

【面试题】2. Consul和Nacos作为注册中心，选型时怎么对比？

【标准答案】 两者都是主流注册中心，但定位和功能有差异：

对比项	Consul	Nacos
模式	CP强一致	AP/CP可切换
配置中心	需Consul KV，功能有限	原生支持，热更新
健康检查	TCP/HTTP/Script	心跳+TCP+HTTP
服务发现	DNS + HTTP API	HTTP API
多语言	SDK支持多语言	Java生态强
界面	Web UI	控制台更丰富

选型建议：

• Nacos：Java生态、Spring Cloud Alibaba、配置中心一体化、AP场景首选
• Consul：多语言混合架构、需要强一致性、已有Consul基础设施

实际经验：

• 国内项目大多选Nacos，生态成熟、文档齐全
• 金融、核心系统用Consul的CP模式更稳妥
• 迁移成本：从Eureka到Nacos平滑，到Consul需适配

---

【面试题】3. 客户端负载均衡和服务端负载均衡有什么区别？各适用什么场景？

【标准答案】 核心区别：负载均衡逻辑执行位置不同。

类型	客户端负载均衡	服务端负载均衡
执行位置	调用方应用内	网关/Nginx等中间层
代表组件	Ribbon/LoadBalancer	Nginx/F5/Gateway
灵活性	可自定义策略、感知服务状态	配置统一、策略固定
性能	无额外跳转，延迟低	多一层转发，增加延迟
维护成本	客户端需集成SDK	集中管理，业务无感知
适用规模	中小规模、服务间调用	大规模、入口流量分发

适用场景：

• 客户端：微服务内部调用、需要细粒度策略（如版本路由）、服务实例较少
• 服务端：统一入口流量分发、大规模部署、需要SSL卸载、静态资源加速

生产实践：

• API网关做入口负载均衡 + 服务间用客户端负载均衡
• 异构集群用客户端负载均衡的加权策略
• 金丝雀发布用客户端负载均衡按版本分发

---

【面试题】4. OpenFeign如何配置日志级别？请求压缩有什么作用？

【标准答案】 日志级别配置：

feign:
  client:
    config:
      default:
        loggerLevel: FULL  # NONE/BASIC/HEADERS/FULL
logging:
  level:
    com.example.feign.Client: DEBUG

级别	输出内容
NONE	无日志（默认）
BASIC	请求方法、URL、响应状态、耗时
HEADERS	BASIC + 请求/响应头
FULL	HEADERS + 请求/响应体

请求压缩配置：

feign:
  compression:
    request:
      enabled: true
      mime-types: text/xml,application/xml,application/json
      min-request-size: 2048
    response:
      enabled: true

作用：

• 减少网络传输体积，提升带宽利用率
• 适合大JSON/XML响应、移动端调用
• 压缩阈值2048字节，避免小请求反而增加开销

生产建议：

• 开发环境用FULL日志排查问题
• 生产环境用BASIC或HEADERS，避免日志过大
• 响应体敏感时慎用FULL，防止日志泄露数据

---

【面试题】5. Sentinel的滑动窗口算法如何实现限流统计？

【标准答案】 Sentinel用滑动窗口统计请求数，核心原理：

实现机制：

• 将时间窗口划分为多个小格（如1秒分10格，每格100ms）
• 每格独立计数，请求进入对应格
• 统计时取最近N格的总和，窗口随时间滑动

对比固定窗口：

• 固定窗口在边界有突刺问题（如第59秒和第1秒各100请求，实际瞬间200）
• 滑动窗口平滑过渡，边界问题大幅缓解

Sentinel优化：

• 用环形数组存储，减少内存分配
• 指标类统计用ArrayMetric，支持多种维度
• 可配置窗口大小和格数，平衡精度和内存

生产配置：

• 默认1秒窗口、1000ms格数，适合大多数场景
• 高精度场景减小格大小，如100ms
• 监控dashboard展示实时滑动窗口数据

---

【面试题】6. Hystrix的线程池隔离和信号量隔离有什么区别？怎么选择？

【标准答案】 两种资源隔离方式，适用场景不同：

对比项	线程池隔离	信号量隔离
原理	每个依赖独立线程池	主线程直接调用，计数器限流
开销	线程切换、队列排队	无额外线程，开销小
超时控制	支持超时强制中断	不支持超时，调用方阻塞
熔断	可熔断等待中的请求	只能熔断正在执行的
适用场景	远程调用、耗时操作	本地缓存、轻量计算

选择依据：

• 线程池：依赖网络调用、响应时间不可控、需要超时熔断（如RPC、HTTP）
• 信号量：本地计算、响应快、无需超时控制（如缓存读取、内部方法）

配置示例：

@HystrixCommand(
    threadPoolKey = "userService",
    threadPoolProperties = {
        @HystrixProperty(name="coreSize", value="10"),
        @HystrixProperty(name="maxQueueSize", value="20")
    },
    executionIsolationStrategy = ExecutionIsolationStrategy.THREAD
)

注意：Hystrix已停止维护，新项目建议用Sentinel或Resilience4j。

---

【面试题】7. Spring Cloud Gateway的过滤器链执行顺序是怎样的？如何自定义全局过滤器？

【标准答案】 Gateway过滤器链按优先级顺序执行，类似拦截器链。

过滤器类型：

• Pre过滤器：请求转发前执行（鉴权、参数校验）
• Post过滤器：响应返回后执行（日志、响应头修改）
• Global过滤器：全局生效，对所有路由
• Gateway过滤器：绑定特定路由

执行顺序：

• 按Order值排序，数字越小越先执行（Pre阶段）
• Post阶段按相反顺序执行
• Global过滤器默认Order值由getOrder()方法返回

自定义全局过滤器：

@Component
public class CustomGlobalFilter implements GlobalFilter, Ordered {
    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        // Pre逻辑：鉴权、日志
        ServerHttpRequest request = exchange.getRequest();
        // 处理...
        return chain.filter(exchange).then(Mono.fromRunnable(() -> {
            // Post逻辑：响应处理
            ServerHttpResponse response = exchange.getResponse();
        }));
    }
    
    @Override
    public int getOrder() {
        return -100; // 优先级高，先执行
    }
}

生产实践：

• 鉴权过滤器Order设负数，最先执行
• 日志过滤器Order设正数，最后执行
• 异常处理用全局过滤器统一返回格式

---

【面试题】8. Spring Cloud Config如何实现多环境管理和配置加密？

【标准答案】 多环境管理： Config Server通过application-{profile}.yml区分环境：

# Config Server配置
spring:
  cloud:
    config:
      server:
        git:
          uri: https://github.com/xxx/config-repo
          searchPaths: '{application}/{profile}'  # 按应用+环境分目录

客户端请求配置：

GET /{application}/{profile}/{label}
如：/order-service/prod/master

配置加密： 敏感配置（密码、密钥）用JCE加密：

# 加密配置
curl -X POST http://config-server/encrypt -d "my-password"
# 返回：{cipher}AQA...加密串

# 配置文件中使用
spring.datasource.password: '{cipher}AQA...'

解密配置：

# Config Server
encrypt:
  key: my-secret-key  # 或用keystore

生产要点：

• 环境隔离：dev/test/prod独立仓库或分支
• 加密密钥妥善保管，生产环境用keystore
• 配置变更审计：Git提交记录追踪
• 备用方案：Config Server不可用时用本地缓存

---

【面试题】9. Sleuth + Zipkin如何配置采样策略？链路追踪的性能影响怎么优化？

【标准答案】 采样策略配置：

spring:
  sleuth:
    sampler:
      probability: 0.1  # 采样率10%（默认全量）

或自定义采样器：

@Bean
public Sampler sampler() {
    return Sampler.create(0.1f); // 10%采样
}

采样策略选择：

策略	采样率	适用场景
全量采样	100%	开发环境、问题排查
降采样	10%-20%	生产环境常规监控
错误全采样	错误请求100%	关键链路、异常追踪

性能优化：

• 降低采样率，减少Trace数据量
• 异步上报：Sleuth用异步发送，不阻塞业务
• 报告器优化：spring.sleuth.web.skipPattern跳过静态资源
• Zipkin存储优化：用Elasticsearch/Cassandra替代MySQL
• 采样决策下沉：Agent端采样，减少传输

性能影响：

• 全量采样约增加5-10%延迟
• 10%采样影响可忽略（<2%）
• Span数量与拦截点数量正相关

---

【面试题】10. Seata的TCC模式原理是什么？和AT模式相比有什么优缺点？

【标准答案】 TCC模式原理： 三阶段：Try（预留资源）、Confirm（确认提交）、Cancel（回滚释放）

执行流程：

• Try阶段：冻结库存（库存-10，冻结+10），不真正扣减
• Confirm阶段：真正扣减，冻结清零
• Cancel阶段：冻结回滚到库存，释放预留

与AT模式对比：

对比项	AT模式	TCC模式
侵入性	零侵入，自动代理	业务需写Try/Confirm/Cancel
性能	一阶段提交，性能高	两阶段，性能较低
一致性	最终一致，有脏写风险	强一致，业务控制回滚
适用场景	一般业务、对一致性要求不高	金融、核心链路、强一致性
开发成本	低，无需改造	高，需设计三阶段逻辑

TCC设计要点：

• Try阶段预留资源，不能真正执行
• Confirm/Cancel必须幂等，支持重试
• Cancel要处理Try失败场景（空回滚）
• 业务活动日志记录状态，支持补偿

生产选择：

• 一般业务用AT，性能好、开发简单
• 资金、库存等核心用TCC，强一致性保障
• 混合使用：核心链路TCC + 边缘业务AT

---

本轮题目覆盖：Eureka集群同步、注册中心选型、负载均衡对比、Feign日志压缩、滑动窗口算法、Hystrix隔离策略、Gateway过滤器链、Config多环境加密、采样策略优化、Seata TCC模式