工作知识库

Appearance

SpringCloud微服务架构面试题库 ​

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

【面试题】1. Nacos作为注册中心，如何实现服务的优雅上下线？ ​

【标准答案】优雅上下线核心是保证服务在变更过程中不影响正在处理的请求。

优雅上线： 服务启动后不立即注册，先完成预热（比如连接池初始化、缓存加载），通过spring.cloud.nacos.discovery.enabled=false延迟注册，等应用完全就绪再改为true。也可以用Nacos的weight=0机制，先注册权重为0，预热完成后再调整权重。

优雅下线： 调用Nacos API先注销服务实例，网关和消费者感知到下线后不再转发新请求，等待正在处理的请求完成（通常配置30秒缓冲期），然后再真正关闭服务。Spring Boot Actuator的/shutdown端点可以配合使用。

关键点：避免服务注册了但还未就绪、或者服务下线了但请求还在处理的情况。生产环境建议配合健康检查和负载均衡的权重调整机制一起用。

【面试题】2. Sentinel的熔断降级策略有哪些？分别适用于什么场景？ ​

【标准答案】Sentinel提供三种熔断策略：

慢调用比例： 统计单位时间内响应时间超过阈值的比例，超过设定比例则熔断。适合对延迟敏感的业务，比如支付、下单等核心链路，一旦慢调用比例升高说明下游可能有问题，提前熔断避免级联故障。

异常比例： 统计单位时间内异常请求的比例，超过阈值则熔断。适合对稳定性要求高的场景，比如调用第三方服务，异常比例飙升说明对方服务不可用，快速失败。

异常数： 统计单位时间内异常数量，超过阈值则熔断。适合低流量服务，用比例可能不够准确，用绝对数量更直观。

熔断后进入半开状态会尝试放一个请求探测，成功则恢复，失败则继续熔断。实际项目中我会根据业务特点选择：核心链路用慢调用比例防止雪崩，第三方依赖用异常比例快速降级，低频服务用异常数。

【面试题】3. Spring Cloud Gateway如何实现统一的JWT鉴权？ ​

【标准答案】网关统一鉴权是微服务安全的标准做法，避免每个服务都实现一遍认证逻辑。

实现方式： 在Gateway中定义一个全局过滤器（GlobalFilter），优先级设置为最高。请求到达时，过滤器从Header中提取Token，校验JWT的签名、过期时间、权限信息。校验通过后将用户ID、角色等信息解析出来，放入Header传递给下游服务；校验失败直接返回401。

关键技术点：

  • 使用jwt-parser库解析Token
  • 过滤器用@Order或getOrder()设置最高优先级，确保在路由之前执行
  • 下游服务从Header获取用户信息，无需再解析JWT
  • Refresh Token的刷新逻辑可以放在网关，也可以独立认证服务处理

安全增强： Token加入黑名单机制（Redis存储），用户登出或Token泄露时可以主动失效。网关层限流防刷，避免JWT校验成为性能瓶颈。

【面试题】4. Seata的AT模式和TCC模式有什么区别？各有什么优缺点？ ​

【标准答案】两种分布式事务模式各有适用场景。

AT模式（自动事务）： 基于数据库本地事务+全局锁实现，Seata自动拦截SQL，记录前后镜像实现回滚。优点是代码零侵入，像写本地事务一样写分布式事务，开发成本低。缺点是依赖数据库支持，性能相对较低，全局锁可能导致死锁风险。适合对性能要求不高、希望快速落地的业务。

TCC模式（Try-Confirm-Cancel）： 业务层面实现三个接口，Try预留资源，Confirm提交，Cancel回滚。优点是性能高、灵活性强，不依赖数据库，可以跨多种存储类型。缺点是代码侵入性强，每个业务都要写三套逻辑，开发成本高，还要考虑幂等性、空回滚、悬挂等问题。适合高并发、对性能要求高、业务逻辑复杂的场景。

我的选择： 一般业务用AT模式快速落地，核心高频业务用TCC优化性能。实际项目中，我会优先评估业务复杂度和性能需求，再决定用哪种模式。

【面试题】5. 如何解决OpenFeign调用超时问题？实际项目中如何配置？ ​

【标准答案】超时配置是微服务调用的关键，配置不当会导致用户体验差或雪崩效应。

配置层次：

  1. Feign级别： feign.client.config.default.connectTimeout=5000（连接超时）、readTimeout=10000（读取超时）
  2. Ribbon级别： ribbon.ReadTimeout=10000、ribbon.ConnectTimeout=5000（如果使用Ribbon）
  3. 服务级别： 可以针对特定服务配置不同超时，比如支付服务ribbon.ReadTimeout=30000

实际配置策略：

  • 连接超时设置较短（3-5秒），快速发现网络问题
  • 读取超时根据业务响应时间设置，核心链路可以长一点（10-30秒），非核心链路短一点（5-10秒）
  • 开启重试机制，但要控制重试次数（1-2次），避免雪崩

踩坑经验： 超时时间要小于下游服务的Hystrix/Sentinel熔断时间，否则熔断不生效。建议用配置中心统一管理超时配置，方便动态调整。

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

【标准答案】Gateway过滤器链采用责任链模式，理解执行顺序才能正确实现业务逻辑。

过滤器分类：

  • GlobalFilter： 全局过滤器，对所有路由生效
  • GatewayFilter： 局部过滤器，只对特定路由生效

执行顺序： 按getOrder()返回值从小到大执行，数值越小优先级越高。Spring Cloud Gateway内置的过滤器顺序：LoadBalancerClientFilter（10100）、NettyRoutingFilter（2147483647，最后执行）等。

自定义过滤器方式：

  1. 实现GlobalFilter和Ordered接口
  2. 在filter方法中编写业务逻辑，调用chain.filter(exchange)传递给下一个过滤器
  3. 前置逻辑在chain.filter()之前，后置逻辑在Mono.then()中处理

实际应用： 比如鉴权过滤器order设为-100，限流过滤器设为-50，日志过滤器设为100。这样鉴权最先执行，限流在鉴权之后，日志在路由转发前后记录。建议自定义过滤器的order值使用有意义的数字，便于后续维护。

【面试题】7. Nacos配置中心如何实现配置的热更新？有哪些注意事项？ ​

【标准答案】配置热更新是配置中心的核心能力，Nacos通过长轮询机制实现。

实现原理： 客户端定时向Nacos Server发送请求检查配置变更，默认30秒一次。如果配置有变化，Nacos立即返回最新配置；如果没有变化，Nacos会hold住请求（长轮询），等到有变更或超时再返回。客户端收到变更通知后，动态刷新Bean的属性值。

使用方式：

  • 在配置类上加@RefreshScope注解
  • 使用@Value("${key}")注入配置
  • 配置变更后，Spring Cloud自动销毁并重建Bean，加载新值

注意事项：

  1. Bean重建问题： @RefreshScope会导致Bean重建，如果Bean有状态会丢失，需要配合@ConfigurationProperties使用
  2. 配置回滚： Nacos支持配置历史版本，可以一键回滚
  3. 多环境管理： 用Namespace隔离不同环境（dev/test/prod），用Group隔离不同项目
  4. 配置加密： 敏感配置要加密存储，Nacos支持内置加密或自定义加密插件

生产建议： 配置变更前先在测试环境验证，关键配置加审批流程，避免配置错误导致生产事故。

【面试题】8. Redisson实现的分布式锁如何解决锁续期和锁释放问题？ ​

【标准答案】Redisson是Redis分布式锁的主流实现，自动解决了续期和释放的核心问题。

锁续期（看门狗机制）： Redisson加锁时默认过期时间30秒，同时启动一个后台线程（看门狗），每10秒（1/3过期时间）检查锁是否还持有。如果持有则自动续期30秒。这样既避免了锁永久不释放，又防止业务未执行完锁就过期。

锁释放：

  • 正常释放：业务执行完调用lock.unlock()，Redisson删除锁的key
  • 异常释放：如果客户端宕机，看门狗线程也停止，锁到期自动删除
  • 防误删：Redisson用Lua脚本保证原子性，删除锁时校验线程ID，避免误删其他线程的锁

实际使用：

java
RLock lock = redisson.getLock("myLock");
lock.lock(); // 自动续期
try {
    // 业务逻辑
} finally {
    lock.unlock();
}

注意点：

  • 如果手动指定过期时间lock.lock(10, TimeUnit.SECONDS)，看门狗机制不生效
  • 高并发场景建议用tryLock()带等待时间，避免无限等待
  • 集群环境用RedLock算法保证高可用

【面试题】9. 微服务架构下如何实现灰度发布？Spring Cloud支持哪些方案？ ​

【标准答案】灰度发布是新版本上线的关键手段，降低发布风险。

核心思路： 通过流量标记（Header、Cookie、权重等）将部分请求路由到新版本服务，逐步验证稳定性后再全量发布。

Spring Cloud实现方案：

1. 网关层路由（推荐）： Spring Cloud Gateway + Nacos元数据实现。网关根据请求Header（如version=v2）匹配路由规则，转发到对应版本的服务。Nacos服务注册时添加version=v2元数据，网关动态感知。

2. Ribbon自定义负载均衡： 根据服务实例的元数据（version标签），结合请求上下文选择对应版本实例。适合服务间调用的灰度。

3. Istio Service Mesh： 将流量治理下沉到Sidecar，支持更丰富的路由策略（权重、Header匹配、百分比流量）。Spring Cloud应用只需集成Istio，无需修改代码。

实际流程：

  • 新版本服务注册时打上version=v2标签
  • 网关配置路由规则：Header含gray=true的请求走v2版本
  • 灰度用户比例从5%逐步提升到50%再到100%
  • 监控灰度版本的错误率、延迟，异常则快速回滚

关键点： 灰度发布要配合监控告警，实时观察新版本表现，出问题立即切回旧版本。

【面试题】10. 如何排查微服务调用链路慢的问题？Sleuth+Zipkin如何使用？ ​

【标准答案】链路慢是微服务常见问题，需要系统性排查。

排查思路：

1. 链路追踪定位： 使用Sleuth+Zipkin或SkyWalking，每个请求生成全局TraceId，自动传递到下游服务。通过TraceId在Zipkin UI查看完整调用链，直观看到每个服务的耗时分布，快速定位慢的服务。

2. Sleuth+Zipkin集成：

  • 引入spring-cloud-starter-sleuth和spring-cloud-starter-zipkin依赖
  • 配置spring.zipkin.base-url=http://zipkin-server:9411
  • 配置采样率spring.sleuth.sampler.probability=1.0（生产环境建议0.1~0.3）
  • 日志自动打印TraceId和SpanId：[app-name,traceId,spanId]

3. 性能分析维度：

  • 数据库慢： 检查SQL执行计划、索引、连接池配置
  • 网络延迟： 检查服务间调用耗时，优化内网带宽或服务部署位置
  • GC频繁： 分析JVM GC日志，调整堆内存和GC策略
  • 线程阻塞： 通过线程Dump分析锁等待、IO阻塞

实际经验：

  • Zipkin默认存储在内存，生产环境改用Elasticsearch或MySQL持久化
  • 高并发场景采样率不要100%，否则性能损耗大
  • 配合日志平台（ELK）通过TraceId关联日志和链路信息，方便深度排查

优化策略： 定位到慢服务后，根据原因选择优化方案：加缓存、异步化、分库分表、服务拆分等。