文章目录
- 一、微服务基础（必问）
-
- [1.1 什么是微服务？与单体架构的区别？](#1.1 什么是微服务？与单体架构的区别？)
- [1.2 Spring Boot 和 Spring Cloud 的关系？](#1.2 Spring Boot 和 Spring Cloud 的关系？)
- [1.3 如何划分微服务边界？（架构设计高频题）](#1.3 如何划分微服务边界？（架构设计高频题）)
- [1.4 CAP 理论？实际如何取舍？](#1.4 CAP 理论？实际如何取舍？)
- 二、服务注册与发现（高频）
-
- [2.1 什么是服务注册与发现？为什么需要？](#2.1 什么是服务注册与发现？为什么需要？)
- [2.2 Nacos、Eureka、Consul 对比？（必问）](#2.2 Nacos、Eureka、Consul 对比？（必问）)
- [2.3 Nacos 3.0 的核心优势？](#2.3 Nacos 3.0 的核心优势？)
- [2.4 服务下线时，消费者如何感知？](#2.4 服务下线时，消费者如何感知？)
- [2.5 什么是服务雪崩？如何避免？](#2.5 什么是服务雪崩？如何避免？)
- 三、配置中心（中频）
-
- [3.1 为什么需要配置中心？](#3.1 为什么需要配置中心？)
- [3.2 Nacos 配置中心如何实现动态刷新？](#3.2 Nacos 配置中心如何实现动态刷新？)
- [3.3 bootstrap.yml 被废弃了？现在怎么配？](#3.3 bootstrap.yml 被废弃了？现在怎么配？)
- 四、API网关（必问）
-
- [4.1 API网关的作用？](#4.1 API网关的作用？)
- [4.2 Spring Cloud Gateway 工作原理？（必问）](#4.2 Spring Cloud Gateway 工作原理？（必问）)
- [4.3 如何在 Gateway 中实现限流？](#4.3 如何在 Gateway 中实现限流？)
- [4.4 网关如何实现灰度发布？](#4.4 网关如何实现灰度发布？)
- 五、服务熔断与限流（高频）
-
- [5.1 什么是熔断？什么是降级？](#5.1 什么是熔断？什么是降级？)
- [5.2 Sentinel 的核心概念？](#5.2 Sentinel 的核心概念？)
- [5.3 Sentinel 限流规则有哪些？](#5.3 Sentinel 限流规则有哪些？)
- [5.4 Sentinel 与 Resilience4j 对比？](#5.4 Sentinel 与 Resilience4j 对比？)
- 六、分布式事务（必问）
-
- [6.1 什么是分布式事务？为什么需要？](#6.1 什么是分布式事务？为什么需要？)
- [6.2 Seata 的三种事务模式？](#6.2 Seata 的三种事务模式？)
- [6.3 TCC 模式如何保证幂等性？](#6.3 TCC 模式如何保证幂等性？)
- [6.4 分布式事务选型策略？](#6.4 分布式事务选型策略？)
- 七、服务通信（高频）
-
- [7.1 OpenFeign 的原理？](#7.1 OpenFeign 的原理？)
- [7.2 Feign 超时如何配置？](#7.2 Feign 超时如何配置？)
- [7.3 负载均衡策略有哪些？](#7.3 负载均衡策略有哪些？)
- 八、实战场景题（加分项）
-
- [8.1 如何实现分布式锁？（高频）](#8.1 如何实现分布式锁？（高频）)
- [8.2 如何保证消息不丢失？](#8.2 如何保证消息不丢失？)
- [8.3 如何保证消息幂等性？](#8.3 如何保证消息幂等性？)
- [8.4 如何排查慢接口？](#8.4 如何排查慢接口？)
- 九、2026新增趋势题（面试官加分）
-
- [9.1 虚拟线程是什么？微服务如何应用？](#9.1 虚拟线程是什么？微服务如何应用？)
- [9.2 GraalVM 原生镜像是什么？](#9.2 GraalVM 原生镜像是什么？)
- [9.3 Spring AI 是什么？](#9.3 Spring AI 是什么？)
- [9.4 Service Mesh 是什么？](#9.4 Service Mesh 是什么？)
- [9.5 2026 年微服务架构趋势？](#9.5 2026 年微服务架构趋势？)
- 附录：速查表
- 总结
一、微服务基础（必问）
1.1 什么是微服务？与单体架构的区别？
答案 ：
微服务是一种架构风格，将一个应用拆分成多个小型服务，每个服务独立运行、独立部署、通过轻量级通信（HTTP/gRPC）协作。
与单体架构对比：
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 部署 | 一个应用整体部署 | 每个服务独立部署 |
| 技术栈 | 统一技术栈 | 服务可使用不同技术栈 |
| 扩展 | 整体扩展，资源浪费 | 按需扩展，资源利用高 |
| 故障影响 | 一个模块故障，整体崩溃 | 故障隔离，不影响其他服务 |
| 开发效率 | 初期快，后期慢 | 初期慢，后期快 |
| 团队协作 | 依赖强，协作难 | 独立开发，协作灵活 |
2026面试必答补充：
- 模块化单体正在回归中小团队（避免过度微服务）
- 微服务拆分原则：业务边界清晰、独立数据、独立部署
💡 记忆技巧：
单体 vs 微服务：整体拆分、统一独立、扩展按需、故障隔离
2026趋势：小团队用模块化单体，大团队用微服务
口诀：单整体，微独立，模块单体小团队1.2 Spring Boot 和 Spring Cloud 的关系？
答案：
- Spring Boot：快速开发单个微服务的框架，提供自动配置、嵌入式服务器
- Spring Cloud：构建分布式系统的工具集，基于 Spring Boot 实现服务发现、配置管理、熔断限流等
- 关系：Spring Boot 是基础，Spring Cloud 依赖 Spring Boot
2026版本对应：
- Spring Boot 4.x + Spring Cloud 2025.x/2026.x
- 最低 Java 21（推荐）
💡 记忆技巧：
Boot = 造砖瓦（单个服务）
Cloud = 盖房子（服务治理）
口诀：Boot造屋，Cloud管村1.3 如何划分微服务边界？（架构设计高频题）
答案 ：
遵循 DDD（领域驱动设计） 原则：
- 业务边界清晰：一个服务对应一个业务领域（如：订单服务、用户服务）
- 独立数据：每个服务有自己的数据库
- 高内聚低耦合：服务内部紧密，服务间松散
- 独立部署：修改一个服务不影响其他服务
拆分原则：
- 按业务能力拆分（推荐）
- 按数据子域拆分
- 避免按技术层拆分（如：服务层、DAO层）
2026新趋势：
- 避免"过度拆分"，导致运维复杂度爆炸
- 推荐模块化单体 → 微服务演进路径
💡 记忆技巧：
微服务拆分：业务能力、独立数据、高内聚低耦合、独立部署
原则：按业务不按技术
路径：模块单体 → 微服务（渐进式）
口诀：业务数据高内聚，独立部署不拆碎1.4 CAP 理论？实际如何取舍？
答案 ：
CAP 理论指出分布式系统最多同时满足两点：
- Consistency（一致性）：所有节点数据一致
- Availability（可用性）：每次请求都有响应
- Partition Tolerance（分区容错）：网络分区时系统仍可用
现实选择：
- CP：强一致性场景（如：金融、支付）→ 牺牲可用性
- AP：高可用场景（如：社交、电商）→ 牺牲强一致性（最终一致）
2026补充：
- AI 场景通常选 CP（模型训练需要一致数据）
- 用户交互选 AP（最终一致性即可）
💡 记忆技巧：
CAP三选二：CP保一致，AP保可用
金融选CP，电商选AP，AI选CP
口诀：CP一致AP可用，金融CP电商AP二、服务注册与发现（高频）
2.1 什么是服务注册与发现？为什么需要？
答案：
- 服务注册：服务启动时，将自己的地址（IP、端口）注册到注册中心
- 服务发现：服务消费者从注册中心获取服务提供者地址列表
- 作用：解决服务间 IP 动态变化问题，解耦服务调用
核心流程：
Provider启动 → 注册到注册中心
Consumer启动 → 从注册中心获取服务列表
Consumer调用 → 负载均衡选择一个实例
实例下线 → 注册中心通知Consumer更新💡 记忆技巧：
注册：我来了，地址是xxx
发现：谁在？我要调用xxx
流程：Provider注册→Consumer发现→负载均衡调用→下线通知
口诀：Provider注册Consumer发现，负载均衡选实例2.2 Nacos、Eureka、Consul 对比？（必问）
答案：
| 注册中心 | CAP | 一致性协议 | 健康检查 | 配置中心 | 2026状态 |
|---|---|---|---|---|---|
| Nacos 3.0 | AP/CP可切换 | Raft（CP） | HTTP/TCP/MySQL | ✅ 内置 | 主流推荐 |
| Eureka | AP | 最终一致 | 心跳 | ❌ 需集成 | 已淘汰 |
| Consul | CP | Raft | TCP/HTTP | ✅ 支持 | 备选 |
| Zookeeper | CP | ZAB | 心跳 | ❌ 不支持 | 旧项目存量 |
2026选型：
- 首选：Nacos 3.0（阿里生态、功能全、配置中心一体化）
- 备选：Consul（国际化项目、强一致性）
- 避免：Eureka（已停止维护）
💡 记忆技巧：
Nacos 3.0：AP/CP可切换、配置中心内置、gRPC支持（2026首选）
Eureka：已淘汰，不要再问
Consul：CP强一致，国际化备选
口诀：Nacos首选Eureka淘汰，Consul备选CP强2.3 Nacos 3.0 的核心优势？
答案：
- 服务注册 + 配置中心一体化（比 Eureka 强）
- gRPC 长连接推送（延迟从秒级降至毫秒级）
- 健康检查丰富：HTTP、TCP、MySQL、自定义
- 多环境隔离：命名空间 + 分组
- 自动故障转移：CP 模式下 Raft 保证一致性
2026新特性：
- 虚拟线程感知（按逻辑并发数而非线程数）
- 敏感配置自动脱敏（password、token 自动掩码）
- DNS-F 域名服务（与 K8s Service 集成）
💡 记忆技巧：
Nacos优势：注册配置一体、gRPC推送、多健康检查、命名空间隔离
2026新：虚拟线程感知、自动脱敏、DNS-F
口诀：注册配置一体推，gRPC延迟毫秒级2.4 服务下线时，消费者如何感知？
答案 ：
主动下线：
- 服务调用
NacosServiceRegistryRegistry.deregister() - Nacos 立即推送下线事件给消费者
被动下线（故障/崩溃）：
- Nacos 健康检查失败（如：HTTP 探测失败）
- 自动从注册表移除
- 推送下线事件
感知延迟：
- 传统 Eureka：30秒（缓存更新）
- Nacos 3.0：< 1秒（gRPC 推送）
💡 记忆技巧：
下线感知：主动注销→立即推送；故障下线→健康检查→推送
延迟：Eureka 30秒，Nacos < 1秒
口诀：主动下线立推送，故障下线健康查2.5 什么是服务雪崩？如何避免？
答案 ：
服务雪崩：因某个服务故障，导致级联故障，整个系统不可用。
原因：
- 服务响应慢 → 请求堆积 → 线程池满 → 级联失败
避免方案：
- 熔断：Sentinel/Resilience4j，失败率高时快速失败
- 限流：限制并发请求数
- 超时控制：设置合理超时时间（如 3 秒）
- 服务隔离：线程池/信号量隔离
- 异步解耦：消息队列缓冲
2026补充：
- 使用虚拟线程减少线程阻塞
- 事件驱动架构（EDA）降低同步依赖
💡 记忆技巧：
雪崩原因：服务慢→请求堆积→线程满→级联失败
避免：熔断限流超时隔离异步解
2026新：虚拟线程+事件驱动
口诀：超时熔断加限流，异步解耦保命符三、配置中心（中频）
3.1 为什么需要配置中心？
答案 ：
微服务配置管理痛点：
- 配置分散：每个服务一份配置文件，难以统一管理
- 环境差异：开发、测试、生产环境配置不同，易出错
- 动态更新：修改配置需重启服务，影响业务
- 敏感信息：数据库密码等明文存储，不安全
配置中心价值：
- 集中管理、动态刷新、版本控制、加密存储
💡 记忆技巧：
配置中心：集中管、动态更、版本控、安全存
解决：配置分散、环境差异、需重启、敏感明文
口诀：配置集中中心管，动态刷新不重启3.2 Nacos 配置中心如何实现动态刷新？
答案：
- 配置监听：客户端通过长轮询/长连接监听配置变化
- 变更推送：Nacos 配置变更时，主动推送变更事件
- Bean 重建 ：
@RefreshScope注解的 Bean 重新初始化 - 延迟：Nacos 3.0 延迟 < 1 秒（Boot 3.x 约 800ms，Boot 4.x 50ms）
代码示例：
java
@RestController
@RefreshScope // 配置刷新时重建该 Bean
public class ConfigController {
@Value("${app.title}")
private String title;
@GetMapping("/config")
public String getConfig() {
return title;
}
}💡 记忆技巧：
动态刷新三步：监听配置→推送变更→Bean重建
注解：@RefreshScope
延迟：Boot 4.x 50ms
口诀：RefreshScope注解，配置变更Bean重建3.3 bootstrap.yml 被废弃了？现在怎么配？
答案 ：
是的 ，Spring Boot 4.x 彻底移除了 bootstrap.yml，统一使用 spring.config.import。
旧方式（已废弃）：
yaml
# bootstrap.yml
spring:
application:
name: my-service
cloud:
nacos:
config:
server-addr: localhost:8848新方式（Boot 4.x）：
yaml
# application.yml
spring:
application:
name: my-service
config:
import:
- optional:nacos:my-service.yml?refreshEnabled=true
cloud:
nacos:
config:
server-addr: localhost:8848优势：单上下文启动更快（提升 30%），配置优先级更清晰
💡 记忆技巧：
Boot 4.x：bootstrap.yml废弃，使用spring.config.import
优势：启动快30%，优先级清晰
口诀：import替代bootstrap，单上下文启动快四、API网关（必问）
4.1 API网关的作用？
答案 ：
API网关是微服务的统一入口，承担以下职责：
- 路由转发：根据请求路径转发到对应服务
- 负载均衡：后端多实例负载均衡
- 统一鉴权：JWT 验证、权限校验
- 限流熔断：防止流量洪峰压垮后端
- 请求/响应处理：添加请求头、响应脱敏
- 监控日志：统一日志记录、监控指标
2026主流：Spring Cloud Gateway（基于 WebFlux，性能优）
💡 记忆技巧：
网关职责：路由、负载、鉴权、限流、处理、监控
价值：统一入口、集中治理
口诀：路由负载鉴权限，网关统一入口4.2 Spring Cloud Gateway 工作原理？（必问）
答案 ：
Gateway 基于三个核心概念：
- Route（路由）：路由规则（id、目标 URI、断言、过滤器）
- Predicate（断言）：匹配条件（路径、方法、请求头等）
- Filter（过滤器）：请求/响应处理逻辑
工作流程：
请求到达 → 匹配断言 → 执行前置过滤器 → 转发到后端服务 → 执行后置过滤器 → 返回响应代码示例：
yaml
spring:
cloud:
gateway:
routes:
- id: user-service
uri: lb://user-service
predicates:
- Path=/api/user/**
filters:
- StripPrefix=1
- name: CircuitBreaker💡 记忆技巧：
Gateway三要素：Route（路由）、Predicate（断言）、Filter（过滤器）
流程：请求→断言匹配→前滤→转发→后滤→响应
口诀：路由断言过滤器，匹配转发前后滤4.3 如何在 Gateway 中实现限流？
答案 ：
Gateway 使用 Redis + 令牌桶算法实现限流。
配置示例：
yaml
spring:
cloud:
gateway:
routes:
- id: order-service
uri: lb://order-service
filters:
- name: RequestRateLimiter
args:
# 令牌桶：每秒补充10个令牌，桶容量20
redis-rate-limiter.replenishRate: 10
redis-rate-limiter.burstCapacity: 20
# 限流键解析器
key-resolver: "#{@userKeyResolver}"限流策略：
- 按 IP：
#{@ipKeyResolver} - 按用户：
#{@userKeyResolver} - 按 API：
#{@apiKeyResolver}
💡 记忆技巧：
Gateway限流：Redis+令牌桶
配置：replenishRate（补充速率）、burstCapacity（桶容量）
维度：IP、用户、API
口诀：Redis令牌桶，补充速率桶容量4.4 网关如何实现灰度发布？
答案 ：
方案一：权重路由
yaml
spring:
cloud:
gateway:
routes:
# v1：80% 流量
- id: user-service-v1
uri: lb://user-service
predicates:
- Weight=user-service, 80
# v2：20% 流量
- id: user-service-v2
uri: lb://user-service-v2
predicates:
- Weight=user-service, 20方案二：基于 Header
yaml
predicates:
- Header=X-Gray-Tag, true方案三：Nacos 元数据
yaml
spring:
cloud:
nacos:
discovery:
metadata:
version: v2
gray: true💡 记忆技巧：
灰度发布三方案：权重路由、Header路由、Nacos元数据
权重：按比例分配
Header：根据请求头
元数据：根据Nacos标签
口诀：权重按比例，Header按特征，元数据按标签五、服务熔断与限流（高频）
5.1 什么是熔断？什么是降级？
答案 ：
熔断（Circuit Breaker）：
- 类似家里的保险丝，当错误率达到阈值时，"熔断"不再调用后端
- 避免级联故障
降级（Fallback）：
- 熔断后或服务不可用时，返回降级数据（如：缓存、默认值）
- 保证系统部分可用
关系：熔断触发降级
2026主流：Sentinel 2.0（阿里）或 Resilience4j（官方推荐）
💡 记忆技巧：
熔断：保险丝，错误率高断开
降级：熔断后返回降级数据
关系：熔断触发降级
口诀：熔断断开降级兜5.2 Sentinel 的核心概念？
答案：
- 资源 ：被保护的代码或接口（用
@SentinelResource标注） - 规则：限流、熔断、降级、热点规则
- 统计：实时统计 QPS、响应时间、错误率
- 流控策略：直接拒绝、Warm Up、排队等待
代码示例：
java
@GetMapping("/order")
@SentinelResource(value = "createOrder", fallback = "handleFallback")
public String createOrder() {
// 业务逻辑
}
// 降级兜底
public String handleFallback() {
return "服务繁忙，请稍后重试";
}💡 记忆技巧：
Sentinel四概念：资源、规则、统计、流控策略
资源：@SentinelResource标注
规则：限流熔断降级热点
口诀：资源规则统计流，Sentinel保护代码5.3 Sentinel 限流规则有哪些？
答案：
| 规则类型 | 说明 | 场景 |
|---|---|---|
| 流控规则 | 限制 QPS 或并发数 | 防止流量洪峰 |
| 熔断规则 | 慢调用/异常比例熔断 | 防止故障级联 |
| 降级规则 | 限流或熔断时降级 | 保证部分可用 |
| 热点规则 | 针对热点参数限流 | 如：商品 ID |
| 系统规则 | CPU、负载、QPS 限流 | 保护整个系统 |
流控策略：
- 直接拒绝：超出限制直接拒绝
- Warm Up：预热，慢慢增加限制（如：秒杀场景）
- 排队等待：匀速排队，超时拒绝
💡 记忆技巧：
Sentinel五规则：流控、熔断、降级、热点、系统
流控策略：直接拒绝、Warm Up、排队等待
口诀：流控熔断降级热，系统规则五保护5.4 Sentinel 与 Resilience4j 对比？
答案：
| 维度 | Sentinel 2.0 | Resilience4j 2.x |
|---|---|---|
| 控制台 | ✅ 强大 Dashboard | ❌ 无（需集成） |
| 规则持久化 | ✅ Nacos/Apollo 实时推送 | ❌ 需自己实现 |
| 热点限流 | ✅ 支持 | ❌ 不支持 |
| 集群限流 | ✅ 支持 | ❌ 不支持 |
| 虚拟线程 | ✅ 原生支持 | ⚠️ 需适配 |
| 性能开销 | 低（纳秒级） | 极低（纯函数） |
| 学习曲线 | 中等 | 简单 |
2026选型：
- 大型项目：Sentinel（功能全、控制台、持久化）
- 小型项目：Resilience4j（简单、轻量）
- 虚拟线程环境：Sentinel 2.0（原生支持）
💡 记忆技巧：
Sentinel：控制台、持久化、热点限流、集群限流
Resilience4j：简单、轻量、纯函数
选择：大项目选Sentinel，小项目选Resilience4j
口诀：Sentinel功能全，Resilience4j性能好六、分布式事务（必问）
6.1 什么是分布式事务？为什么需要？
答案 ：
分布式事务：跨多个数据库/服务的事务操作，保证要么全部成功，要么全部失败。
为什么需要：
- 订单服务扣减库存 → 库存服务扣减 → 账户服务扣款
- 任何一步失败，都要全部回滚
CAP困境：
- 传统 ACID 无法在分布式环境实现
- 只能追求最终一致性
💡 记忆技巧：
分布式事务：跨库跨服务，要么全成功要么全失败
困境：CAP理论无法强一致
解决：最终一致性
口诀：跨库跨服务事务，最终一致性保证6.2 Seata 的三种事务模式？
答案：
| 模式 | 说明 | 适用场景 | 侵入性 |
|---|---|---|---|
| AT 模式 | 基于 undo/redo 日志，自动回滚 | 简单 CRUD | 低 |
| TCC 模式 | Try-Confirm-Cancel 三阶段 | 复杂业务、高可靠 | 高 |
| Saga 模式 | 补偿事务，长事务支持 | 工作流、长流程 | 高 |
AT 模式流程：
1. 解析 SQL → 记录 before/after 镜像
2. 执行业务 SQL
3. 提交本地事务
4. 失败时 → 回滚 undo 日志💡 记忆技巧：
Seata三模式：AT、TCC、Saga
AT：自动回滚（简单）
TCC：三阶段手动（可靠）
Saga：补偿长事务（工作流）
口诀：AT自动TCC手动，Saga补偿长事务6.3 TCC 模式如何保证幂等性？
答案 ：
TCC 三阶段：
- Try：预留资源（如：冻结库存）
- Confirm：确认提交（如：扣减库存）
- Cancel：取消回滚（如：释放冻结库存）
幂等性保证：
- 业务幂等：数据库唯一约束（如：订单 ID）
- 状态检查：每次操作前检查状态（已处理则跳过）
- 幂等 Token：生成唯一 Token，防止重复提交
代码示例：
java
@LocalTCC
public interface InventoryService {
// Try：预留
@TwoPhaseBusinessAction(name = "deductInventory", commitMethod = "confirm", rollbackMethod = "cancel")
boolean deduct(@BusinessActionContextParameter(paramName = "orderId") String orderId, int count);
// Confirm：确认
boolean confirm(BusinessActionContext context);
// Cancel：取消
boolean cancel(BusinessActionContext context);
}💡 记忆技巧：
TCC三阶段：Try预留、Confirm确认、Cancel取消
幂等性：业务幂等（唯一约束）、状态检查、幂等Token
口诀：Try预留Confirm确认，Cancel取消保幂等6.4 分布式事务选型策略？
答案：
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 强一致性（银行转账） | Seata XA | 保证 ACID |
| 最终一致性（电商下单） | Seata AT | 自动回滚，侵入性低 |
| 高可靠场景（支付） | Seata TCC | 可控性强，适合核心业务 |
| 长事务（工作流） | Seata Saga | 支持长流程，可回滚 |
| 高性能（秒杀） | 本地事务 + 消息队列 | 性能优先，最终一致 |
2026补充：
- 优先考虑消息队列 + 本地事务（性能最优）
- 核心业务用 TCC（可靠性强）
- 一般业务用 AT（开发成本低）
💡 记忆技巧：
事务选型：强一致XA，最终一致AT，高可靠TCC，长事务Saga，高性能消息队列
2026：优先消息队列+本地事务
口诀：XA强AT最终，TCC可靠Saga长，消息队列性能优七、服务通信（高频）
7.1 OpenFeign 的原理？
答案 ：
OpenFeign 是声明式的 HTTP 客户端，基于动态代理实现。
工作原理：
- 定义接口，加
@FeignClient注解 - 编译时生成动态代理类
- 调用接口时，代理类处理：
- 服务发现（从注册中心获取地址）
- 负载均衡（选择一个实例）
- 发送 HTTP 请求
- 解码响应
代码示例：
java
@FeignClient(name = "user-service", fallback = UserServiceFallback.class)
public interface UserServiceClient {
@GetMapping("/api/user/{id}")
UserDTO getUserById(@PathVariable("id") Long id);
}💡 记忆技巧：
Feign原理：动态代理+服务发现+负载均衡+HTTP调用
流程：接口定义→代理生成→服务发现→负载均衡→HTTP调用
口诀：动态代理发现调用，声明式HTTP客户端7.2 Feign 超时如何配置？
答案 ：
全局配置：
yaml
feign:
client:
config:
default:
connectTimeout: 5000 # 连接超时
readTimeout: 10000 # 读取超时单个服务配置：
yaml
feign:
client:
config:
user-service:
connectTimeout: 3000
readTimeout: 6000代码配置：
java
@Configuration
public class FeignConfig {
@Bean
public Request.Options options() {
return new Request.Options(
3000, // 连接超时
6000 // 读取超时
);
}
}💡 记忆技巧：
Feign超时：connectTimeout（连接）、readTimeout（读取）
配置：全局default或单个服务名
口诀：连接读取两超时，全局服务两配置7.3 负载均衡策略有哪些？
答案 ：
Spring Cloud LoadBalancer（替代 Ribbon）支持以下策略：
| 策略 | 说明 | 适用场景 |
|---|---|---|
| RoundRobin | 轮询 | 默认策略 |
| Random | 随机 | 简单场景 |
| Weighted | 权重 | 服务器性能不同 |
| ZoneAware | 区域感知 | 多机房部署 |
2026默认：LoadBalancer（已移除 Ribbon）
💡 记忆技巧：
负载均衡四策略：轮询、随机、权重、区域感知
默认：RoundRobin轮询
2026：LoadBalancer替代Ribbon
口诀：轮询随机权重区域，默认轮询LoadBalancer八、实战场景题（加分项）
8.1 如何实现分布式锁？（高频）
答案：
方案一：Redis + Redisson
java
@Autowired
private RedissonClient redisson;
public void process() {
RLock lock = redisson.getLock("order:lock");
try {
// 尝试加锁，最多等待3秒，10秒后自动释放
boolean locked = lock.tryLock(3, 10, TimeUnit.SECONDS);
if (locked) {
// 业务逻辑
}
} finally {
if (lock.isHeldByCurrentThread()) {
lock.unlock();
}
}
}方案二：ZooKeeper + Curator
java
InterProcessMutex lock = new InterProcessMutex(curatorFramework, "/order/lock");
if (lock.acquire(3, TimeUnit.SECONDS)) {
try {
// 业务逻辑
} finally {
lock.release();
}
}选型：
- 高并发：Redis（性能高）
- 高可靠：ZooKeeper（一致性强）
💡 记忆技巧：
分布式锁：Redis高性能，ZooKeeper高可靠
实现：Redisson tryLock，Curator acquire
选择：高并发选Redis，高可靠选ZooKeeper
口诀：Redis高性能ZooKeeper可靠，Redisson Curator实现8.2 如何保证消息不丢失？
答案：
生产端：
- 开启 ACK 机制
- 同步发送（确保消息到达 Broker）
Broker 端：
- 消息持久化（刷盘策略）
- 集群部署（多副本）
消费端：
- 手动 ACK（消费成功后确认）
- 幂等性处理（防止重复消费）
代码示例：
yaml
spring:
cloud:
stream:
kafka:
binder:
auto-create-topics: true
auto-add-partitions: true
min-partition-count: 1
bindings:
output:
producer:
# 同步发送
sync: true
input:
consumer:
# 手动 ACK
acknowledge-mode: manual💡 记忆技巧：
消息不丢失三阶段：生产端ACK、Broker持久化、消费端手动ACK
生产：同步发送确保到达
Broker：持久化多副本
消费：手动ACK幂等处理
口诀：生产同步Broker持久，消费手动ACK保不丢8.3 如何保证消息幂等性？
答案：
方案一：唯一 ID + Redis
java
@KafkaListener(topics = "order-topic")
public void consume(OrderEvent event) {
String key = "order:idempotent:" + event.getOrderId();
// 检查是否已处理
Boolean isProcessed = redisTemplate.opsForValue()
.setIfAbsent(key, "1", 24, TimeUnit.HOURS);
if (!isProcessed) {
return; // 已处理，跳过
}
// 处理业务
orderService.create(event);
}方案二：数据库唯一约束
sql
CREATE TABLE `order` (
`id` bigint NOT NULL,
`order_id` varchar(64) NOT NULL,
PRIMARY KEY (`id`),
UNIQUE KEY `uk_order_id` (`order_id`)
);方案三：状态机
java
if (order.getStatus() != OrderStatus.PENDING) {
return; // 已处理
}
order.setStatus(OrderStatus.PROCESSING);💡 记忆技巧：
幂等性三方案：唯一ID Redis、数据库唯一约束、状态机
Redis：setIfAbsent
数据库：UNIQUE KEY
状态机：状态检查
口诀：Redis唯一数据库约束，状态机流转防重复8.4 如何排查慢接口？
答案：
步骤：
-
监控指标：查看 QPS、响应时间、错误率
-
链路追踪：SkyWalking/Micrometer 找出耗时最长的服务/方法
-
慢查询日志：数据库慢查询分析
-
Arthas 分析 ：
bash# 追踪方法耗时 trace com.example.service.UserService getUserById # 查看最耗时方法 dashboard -
JProfiler：CPU、内存分析
常见原因：
- 数据库慢查询（缺索引、SQL 优化）
- 第三方接口慢（超时配置、缓存）
- 死锁
- 内存泄漏
💡 记忆技巧：
慢接口排查：监控→追踪→慢查询→Arthas→JProfiler
工具：SkyWalking、Arthas、JProfiler
原因：数据库、第三方、死锁、内存泄漏
口诀：监控追踪慢查询，Arthas分析找瓶颈九、2026新增趋势题（面试官加分）
9.1 虚拟线程是什么？微服务如何应用？
答案 ：
虚拟线程（Project Loom）：Java 21+ 引入的轻量级线程，由 JVM 管理，可创建数百万个。
优势：
- 数量不限（平台线程受限于 OS）
- 切换快（微秒级 vs 毫秒级）
- 内存占用低（KB 级 vs MB 级）
微服务应用：
java
// Boot 4.x 配置
spring:
threads:
virtual:
enabled: true
// 使用虚拟线程
@Async("virtualTaskExecutor")
public CompletableFuture<OrderDTO> createOrderAsync(OrderRequest request) {
// 虚拟线程执行，不阻塞平台线程
return CompletableFuture.completedFuture(doCreateOrder(request));
}2026注意：
- Feign、Sentinel 2.0 原生支持虚拟线程
- 不要用 ThreadLocal（用 Scoped Values）
💡 记忆技巧：
虚拟线程：轻量级、数量不限、切换快、内存少
配置：spring.threads.virtual.enabled=true
应用：异步任务、高并发IO
注意：不用ThreadLocal
口诀：虚拟线程数量多，异步IO不阻塞9.2 GraalVM 原生镜像是什么？
答案 ：
GraalVM 原生镜像：将 Java 应用编译为本地二进制文件。
优势：
- 启动时间：< 50ms（JVM 3-10s）
- 内存占用：降低 70-90%
- 部署体积：降低 60-80%
构建命令：
bash
mvn -Pnative native:compile
./target/user-service2026应用：
- Serverless 场景
- 容器化部署
- 快速启动需求
💡 记忆技巧：
GraalVM：启动<50ms、内存降90%、体积降80%
构建：mvn -Pnative native:compile
应用：Serverless、容器化、快速启动
口诀：启动50ms内存降90，GraalVM原生快9.3 Spring AI 是什么？
答案 ：
Spring AI：Spring 官方推出的 AI 开发框架，统一大模型调用 API。
核心能力：
- ChatClient（聊天）
- EmbeddingClient（向量）
- ImageClient（图像）
- 向量数据库集成
- RAG（检索增强生成）
代码示例：
java
@Autowired
private ChatClient chatClient;
public String chat(String message) {
return chatClient.prompt()
.user(message)
.call()
.content();
}2026趋势：
- 微服务集成 AI 能力
- AI Agent 成为新范式
- RAG 架构普及
💡 记忆技巧：
Spring AI：Chat/Embedding/Image三Client，向量库集成
应用：AI聊天、RAG检索、Agent
2026：微服务+AI融合
口诀：Spring AI统一API，ChatEmbeddingImage9.4 Service Mesh 是什么？
答案 ：
Service Mesh：服务网格，基础设施层的微服务治理方案。
核心组件：
- 数据平面：Sidecar 代理（Envoy/MOSN），处理服务间通信
- 控制平面：Istio/Linkerd，管理 Sidecar
优势：
- 非侵入式（业务代码无需改动）
- 统一治理（流量管理、安全、可观测性）
- 多语言支持
2026趋势：
- 大型系统标配
- 与 Spring Cloud 混合架构
- MOSN 轻量级代理兴起
💡 记忆技巧：
Service Mesh：Sidecar代理+控制平面
优势：非侵入、统一治理、多语言
2026：大型系统标配，混合架构
口诀：Sidecar代理控制平面，非侵入统一治9.5 2026 年微服务架构趋势？
答案：
- 模块化单体回归：中小团队优先模块化单体，避免过度拆分
- AI 融合：Spring AI、RAG、AI Agent 普及
- 虚拟线程普及：高并发场景优先使用虚拟线程
- GraalVM 原生镜像：启动快、内存少，适合 Serverless
- Service Mesh 深化：大型系统标配，治理能力下沉
- 事件驱动架构（EDA）：从同步转向异步，降低耦合
- 可观测性增强：eBPF 无侵入监控、AI 驱动分析
💡 记忆技巧：
2026趋势：模块单体回归、AI融合、虚拟线程、GraalVM、Service Mesh、事件驱动、可观测性
小团队：模块化单体
大系统：Service Mesh + AI
技术：虚拟线程 + GraalVM
口诀：模块单体AI融合，虚拟线程GraalVM附录：速查表
常用端口号
| 组件 | 端口 |
|---|---|
| Nacos | 8848 |
| Sentinel Dashboard | 8080 |
| Seata | 8091 |
| Zipkin | 9411 |
| Kafka | 9092 |
| RocketMQ NameServer | 9876 |
常用注解
| 注解 | 作用 |
|---|---|
@EnableDiscoveryClient |
启用服务发现 |
@FeignClient |
声明 Feign 客户端 |
@SentinelResource |
Sentinel 资源定义 |
@RefreshScope |
配置动态刷新 |
@GlobalTransactional |
Seata 全局事务 |
@LocalTCC |
Seata TCC 事务 |
总结
高频考点排序：
- 微服务基础（CAP、拆分原则）
- 服务注册与发现（Nacos、Eureka 对比）
- API 网关（原理、限流、灰度）
- 服务熔断与限流（Sentinel、Resilience4j）
- 分布式事务（Seata 模式、选型）
- 服务通信（Feign、负载均衡）
- 实战场景（分布式锁、消息幂等、慢接口排查）
- 2026 新趋势（虚拟线程、GraalVM、Spring AI）
面试策略：
- 基础必答：微服务概念、CAP、注册中心对比
- 原理深挖：Gateway 工作原理、Feign 原理、Seata 模式
- 实战加分：分布式锁、消息幂等、慢接口排查
- 趋势加分：虚拟线程、GraalVM、Spring AI
最后建议：
- 理解原理，不要死记硬背
- 结合项目经验，举一反三
- 关注 2026 新技术，加分项