大家好，我是 CodeStats。
一个在底层技术上“考古”了四年的硬核爱好者，也是 WWAIC（全周项目AI编程） 范式的提出者和实践者。我曾手写过一个完整的 Java Web 框架（从 IoC 容器到嵌入式 Tomcat，代码全开源），也喜欢用通俗的语言拆解 CPU、JVM、操作系统的运行本质。
💡 我的技术信条：所有高深的技术，最后都能用大白话讲清楚。如果讲不清楚，说明还没真正理解。
📖 读完后你能收获什么？
-
清晰的答题逻辑：每个问题给出面试可直接复述的“标准答案”
-
底层的原理认知：不背八股，理解 Spring 为什么这样设计
-
微服务的全景图：从 Boot 到 Cloud Alibaba，从服务注册到网关治理，形成完整体系
📑 目录
-
一、Spring Boot 基础篇
-
二、Spring IoC 与生命周期篇
-
三、Spring Boot 原理篇
-
四、微服务架构篇
-
五、服务治理与调用篇
-
六、流量治理与网关篇
-
七、总结与加餐
一、Spring Boot 基础篇
1. @SpringBootApplication 注解的本质是什么？它由哪些子注解组成？
面试回答：
@SpringBootApplication 是一个组合注解，它由三个核心注解组合而成：
@SpringBootConfiguration：本质上是 @Configuration，标注当前类是配置类，表明它是一个 Spring 的配置类。
@EnableAutoConfiguration：这是最核心的注解，用于开启 Spring Boot 的自动配置机制。它通过 @Import(AutoConfigurationImportSelector.class) 导入选择器，读取 META-INF/spring.factories 或 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件中配置的所有自动配置类，并根据条件注解（如 @ConditionalOnClass）进行过滤，按需加载。
@ComponentScan：开启组件扫描，默认扫描启动类所在包及其子包。这保证了位于根包下的所有 @Component、@Service、@Repository、@Controller 等注解标注的类能被自动注册为 Spring Bean。
2. Spring Boot 的“自动配置”是如何实现的？请描述完整流程。
面试回答：
自动配置是 Spring Boot 的灵魂，其完整流程如下：
入口：应用启动时，@SpringBootApplication 注解中的 @EnableAutoConfiguration 生效。
导入选择器：@EnableAutoConfiguration 通过 @Import(AutoConfigurationImportSelector.class) 导入一个 ImportSelector 实现类。
读取配置文件：AutoConfigurationImportSelector 会从类路径下读取 META-INF/spring.factories 文件（Spring Boot 2.7 以上版本部分迁移到 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports），该文件中以键值对形式列出了所有自动配置类的全限定名。
条件过滤：Spring 会逐一处理这些自动配置类，通过 @Conditional 系列注解（如 @ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty 等）进行条件匹配。例如，RedisAutoConfiguration 只有在类路径中存在 RedisOperations 类时才会生效。
实例化与注册：满足所有条件后，自动配置类会被实例化，其中的 @Bean 方法会被执行，创建相应的 Bean 并注册到 Spring 容器中。
关键理解：自动配置的核心理念是“基于条件的智能推断”，即根据当前应用的类路径、已定义的 Bean、配置属性等上下文信息，自动决定哪些配置应该生效。
3. Spring Boot 的启动流程核心步骤有哪些？
面试回答：
Spring Boot 的启动流程本质上是 Spring 容器 ApplicationContext 的 refresh() 过程，一共包含 12 个核心步骤：
| 准备 | prepareRefresh() | 设置启动状态，验证必要属性 |
| 准备 | obtainFreshBeanFactory() | 创建 DefaultListableBeanFactory |
| 准备 | prepareBeanFactory() | 配置类加载器、表达式解析器、忽略特定接口 |
| 增强 | postProcessBeanFactory() | 模板方法，Web 环境添加 request/session Scope |
| 增强 | invokeBeanFactoryPostProcessors() | 执行 BeanFactoryPostProcessor（ConfigurationClassPostProcessor 解析 @Configuration 类） |
| 增强 | registerBeanPostProcessors() | 注册 BeanPostProcessor（为 Bean 生命周期拦截做准备） |
| 能力 | initMessageSource() | 初始化国际化资源 |
| 能力 | initApplicationEventMulticaster() | 初始化事件广播器 |
| 能力 | onRefresh() | 模板方法，Spring Boot 在此启动嵌入式 Tomcat |
| 能力 | registerListeners() | 注册事件监听器 |
| 实例化 | finishBeanFactoryInitialization() | 实例化所有非懒加载单例 Bean（最重的一步） |
| 完成 | finishRefresh() | 发布 ContextRefreshedEvent，启动 Lifecycle 组件 |
面试加分点：onRefresh() 是 ServletWebServerApplicationContext 重写的模板方法，内部调用 createWebServer() 启动内嵌的 Tomcat、Jetty 或 Undertow。这正是 Spring Boot 应用可以“一键启动”独立运行的底层原因。
4. Spring Boot 的配置文件加载顺序是什么？
面试回答：
Spring Boot 的配置读取遵循优先级从高到低的原则，高优先级的配置会覆盖低优先级的配置：
命令行参数（最高）：如 –server.port=8081 具有最高优先级。
Java 系统属性：System.getProperties()。
操作系统环境变量。
当前目录下的 application-{profile}.yml/properties（如 application-dev.yml）。
类路径下的 application-{profile}.yml/properties（打包在 jar 内的）。
当前目录下的 application.yml/properties。
类路径下的 application.yml/properties（最低）。
补充：bootstrap.yml（Spring Cloud 引入）的优先级高于 application.yml，用于配置中心连接参数。
二、Spring IoC 与生命周期篇
5. Spring Bean 的完整生命周期包含哪些阶段？
面试回答：
Spring Bean 的生命周期可以分为 “四步走”，按顺序为：
实例化（Instantiation）：容器通过构造器或工厂方法创建 Bean 的原始对象，此时对象内部的属性均为空。
属性填充（Populate）：容器根据 @Autowired、@Resource 或 XML 配置，完成依赖注入（DI）。如果存在循环依赖，Spring 会在此处利用三级缓存暴露半成品对象。
初始化（Initialization）：这是最复杂的阶段，严格按以下顺序执行：
-
Aware 接口回调：BeanNameAware → BeanClassLoaderAware → ApplicationContextAware
-
BeanPostProcessor.postProcessBeforeInitialization：@PostConstruct 注解的方法在此阶段被触发
-
InitializingBean.afterPropertiesSet()
-
自定义 init-method（XML 或 @Bean(initMethod = "xxx")）
-
BeanPostProcessor.postProcessAfterInitialization：AOP 代理在此生成
销毁（Destruction）：容器关闭时，执行 @PreDestroy → DisposableBean.destroy() → 自定义 destroy-method。
6. Spring 如何解决循环依赖？三级缓存是什么？
面试回答：
Spring 通过三级缓存机制解决单例 Bean 的属性循环依赖问题。三级缓存定义在 DefaultSingletonBeanRegistry 类中：
| 一级缓存 | singletonObjects | 成品池，存放完全初始化完成的单例 Bean |
| 二级缓存 | earlySingletonObjects | 半成品池，存放提前暴露的、尚未完全初始化的 Bean |
| 三级缓存 | singletonFactories | 工厂池，存放 ObjectFactory，可生成提前暴露的 Bean 引用 |
以 A 依赖 B、B 依赖 A 的循环依赖场景为例：
创建 A 实例，暴露其 ObjectFactory 到三级缓存。
填充 A 属性时发现依赖 B，去创建 B。
创建 B 实例，暴露其 ObjectFactory 到三级缓存。
填充 B 属性时发现依赖 A，从三级缓存获取 A 的 ObjectFactory，调用 getObject() 获取 A 的提前引用（半成品），放入二级缓存，从三级缓存移除。
将半成品 A 注入 B，B 完成初始化，成品 B 放入一级缓存。
回到 A，将成品 B 注入 A，A 完成初始化，成品 A 放入一级缓存。
局限性：仅支持 singleton 作用域 + 字段注入/Setter 注入的循环依赖；构造器注入无法解决，Spring Boot 2.6+ 默认禁止循环依赖。
7. Spring 的事件机制是如何设计的？
面试回答：
Spring 的事件机制基于观察者模式设计，由四个核心角色组成：
| 事件 | ApplicationEvent | 信息的载体，自定义事件需继承此类 |
| 发布者 | ApplicationEventPublisher | 发布事件，ApplicationContext 本身实现了该接口 |
| 监听器 | ApplicationListener / @EventListener | 订阅事件并处理业务逻辑 |
| 广播器 | ApplicationEventMulticaster | 管理所有监听器，在事件发布时将事件分发给匹配的监听器 |
工作流程：
容器启动时，initApplicationEventMulticaster() 初始化广播器。
registerListeners() 将所有 ApplicationListener Bean 注册到广播器。
开发者调用 publishEvent()，容器将事件委托给广播器。
广播器根据事件类型查找匹配的监听器，逐一回调 onApplicationEvent()。
关键理解：监听器是 Bean（被容器管理），事件是普通 POJO（用 new 创建），事件不会被容器管理。默认同步执行，添加 @Async 可改为异步。
8. BeanFactoryPostProcessor 和 BeanPostProcessor 的区别是什么？
面试回答：
这是 Spring 面试中的高频区分题，两者的本质区别在于作用对象和执行时机：
| 作用对象 | BeanFactory 本身 | Bean 实例 |
| 执行时机 | 在 Bean 实例化之前执行 | 在 Bean 实例化之后、初始化阶段执行 |
| 核心能力 | 修改 Bean 的定义（BeanDefinition），如修改属性值、作用域、甚至添加新的 Bean 定义 | 拦截 Bean 的初始化过程，对 Bean 实例进行包装、代理、增强 |
| 典型应用 | ConfigurationClassPostProcessor（解析 @Configuration）、PropertySourcesPlaceholderConfigurer（解析 ${…} 占位符） | AutowiredAnnotationBeanPostProcessor（处理 @Autowired）、AnnotationAwareAspectJAutoProxyCreator（AOP 代理生成） |
面试加分点：AOP 代理的生成发生在 BeanPostProcessor.postProcessAfterInitialization 阶段，所以最终注入到其他 Bean 中的可能是代理对象而非原始对象。
三、Spring Cloud 基础篇
9. Spring Boot 和 Spring Cloud 是什么关系？
面试回答：
-
Spring Boot 是一个快速构建单个 Spring 应用的框架，其核心能力是自动配置和起步依赖，极大简化了应用开发。
-
Spring Cloud 是一套构建分布式系统的工具集，提供了服务注册与发现、配置管理、网关、熔断降级等微服务治理能力。
关系：Spring Cloud 建立在 Spring Boot 之上，所有 Spring Cloud 组件都以 Spring Boot Starter 的形式提供，利用 Spring Boot 的自动配置实现“开箱即用”。
一句话总结：Spring Boot 是“盖房子的砖瓦”，Spring Cloud 是“社区规划图”。Spring Boot 可以独立使用，但 Spring Cloud 离不开 Spring Boot。
10. Spring Cloud Netflix 和 Spring Cloud Alibaba 的区别是什么？
面试回答：
Spring Cloud Alibaba 是 Spring Cloud 的子项目，遵循 Spring Cloud 标准规范，但提供了更符合国内企业需求、更成熟的组件替换方案：
| 服务注册与发现 | Eureka（已宣布停止维护） | Nacos（功能更强大） |
| 配置中心 | Spring Cloud Config | Nacos Config（配置与管理一体化） |
| 服务容错 | Hystrix（已停止维护） | Sentinel（功能更丰富、更成熟） |
| 远程调用 | Feign（集成 Ribbon） | OpenFeign + Dubbo（双协议支持） |
| 网关 | Zuul 1.x（阻塞式） | Spring Cloud Gateway（异步非阻塞） |
选型建议：目前国内企业生产环境几乎都选择 Spring Cloud Alibaba 体系，原因包括：Nacos 兼具注册中心和配置中心双重职能、Sentinel 比 Hystrix 功能强大且维护活跃、阿里巴巴大规模生产验证的稳定性。
四、服务治理篇
11. Nacos 的服务注册与发现流程是怎样的？
面试回答：
Nacos 的服务注册与发现涉及三个角色，完整流程如下：
服务注册：服务提供者启动时，通过 Nacos Client SDK 的 namingService.registerInstance() 向 Nacos Server 发送注册请求，携带服务名、IP、端口、权重等信息。
健康检查：注册成功后，Nacos Client 会启动一个心跳线程，定期（默认 5 秒）向 Nacos Server 发送心跳包，证明服务实例“存活”。Nacos Server 根据心跳更新服务状态，若长时间未收到心跳，则将该实例标记为不健康并可能剔除。
服务发现：服务消费者通过 Nacos Client 向 Nacos Server 查询目标服务的实例列表。Nacos 支持拉取模式（轮询查询）和推送模式（变更时主动通知），后者更新更及时。
负载均衡：消费者获取实例列表后，由 Spring Cloud LoadBalancer 根据策略（如轮询、随机）选择一个实例发起调用。
Nacos 区别于 Eureka 的关键点：支持两种健康检查模式——客户端心跳（临时实例，AP 模式）和服务端主动探测（非临时实例，CP 模式）。
12. Nacos 的 CAP 模式如何切换？分别适用于什么场景？
面试回答：
Nacos 是业界唯一一个同时支持 AP 和 CP 两种模式的注册中心：
| AP 模式（可用性优先） | ✅ 默认 | 保证最终一致性，允许数据短暂不一致 | 服务发现场景：服务实例随时注册/下线，短暂不一致不影响调用，需保证高可用 |
| CP 模式（一致性优先） | ❌ 需配置切换 | 强一致性，写入必须同步到大多数节点后才返回 | 配置管理场景：配置数据必须严格一致，如分布式锁、选主 |
配置方式：通过 spring.cloud.nacos.discovery.ephemeral=true（临时实例，AP）或 false（永久实例，CP）来切换。
13. 什么是服务雪崩？如何防止？
面试回答：
服务雪崩是指在微服务调用链中，一个服务不可用导致上游服务请求积压、线程阻塞，最终引发整个系统瘫痪的连锁反应现象。其根本原因是故障的传播性和资源的有限性。
防止服务雪崩的核心手段（Sentinel 提供完整解决方案）：
| 限流 | 控制进入系统的请求速率，防止被突发流量冲垮 | 滑动窗口算法（默认）/ 令牌桶算法（预热模式） |
| 熔断 | 当依赖服务故障率达到阈值时自动“跳闸”，后续请求快速失败 | 断路器状态机：CLOSED → OPEN → HALF_OPEN |
| 降级 | 熔断或调用失败后提供备选方案（Fallback），返回兜底数据 | 实现 fallback 方法，返回默认值或缓存数据 |
| 线程隔离 | 为每个依赖服务分配独立的线程池，防止一个服务故障耗尽所有线程 | Sentinel 支持信号量隔离和线程池隔离 |
五、服务调用篇
14. OpenFeign 的工作原理是什么？
面试回答：
OpenFeign 是一个声明式的 HTTP 客户端，其核心是基于动态代理：
定义接口：开发者定义一个 Java 接口并添加 @FeignClient(name = "service-name") 注解。
动态代理：Spring Cloud 在启动时，FeignClientsRegistrar 会扫描所有 @FeignClient 接口，通过 Feign.Builder 为每个接口生成一个动态代理对象（JDK 动态代理）。
方法调用：当调用接口方法（如 orderClient.getOrder(1L)）时，代理对象拦截调用，执行以下转换：
-
解析方法上的 @GetMapping、@PostMapping 等注解，构建 HTTP 请求 URL、请求头、请求体。
-
通过服务发现从注册中心获取目标服务的实例列表。
-
通过负载均衡（默认 LoadBalancer）选出一个实例。
-
使用内置的 HTTP 客户端（默认 Apache HttpClient 或 OkHttp）发起请求。
-
接收响应，反序列化为方法的返回类型。
15. 负载均衡有哪些策略？如何自定义？
面试回答：
Spring Cloud 2020 版本之后，默认使用 Spring Cloud LoadBalancer 替代 Netflix Ribbon。
内置策略：
| 轮询 | RoundRobinLoadBalancer | 默认策略，按顺序轮流选择实例 |
| 随机 | RandomLoadBalancer | 从实例列表中随机选择 |
| 权重 | WeightedLoadBalancer | 根据实例的权重值分配流量（需配合 Nacos 权重配置） |
自定义策略：实现 ReactorLoadBalancer 接口，重写 choose() 方法，并通过 @Bean 将其注入容器，使用 @LoadBalancerClient(name = "service-name", configuration = CustomConfig.class) 指定。
16. Spring Cloud 中如何实现远程调用的超时控制？
面试回答：
在 Spring Cloud Alibaba 体系中，远程调用超时控制可以从三个层面配置：
1. OpenFeign 层面：
yaml
feign:
client:
config:
default:
connectTimeout: 5000 # 连接超时 5 秒
readTimeout: 10000 # 读取超时 10 秒
2. LoadBalancer 层面：
yaml
spring:
cloud:
loadbalancer:
clients:
default:
connect-timeout: 5000
read-timeout: 10000
3. 配合 Sentinel 熔断：配置慢调用比例熔断规则，当响应时间超过设定阈值（如 2 秒）的请求比例达到指定百分比时，触发熔断降级。
六、流量治理篇
17. 限流、熔断、降级三者的区别和联系是什么？
面试回答：
这是 Sentinel/Hystrix 面试中的必考核心题，三者定义和关系如下：
| 限流 | 控制请求速率，超过阈值则拒绝 | 主动防御——设卡盘查 | 流量达到设定阈值 | 防止系统被突发流量冲垮 |
| 熔断 | 故障率过高时自动“跳闸”，切断调用 | 被动止损——跳闸断电 | 异常比例/慢调用比例超过阈值 | 防止故障扩散，避免服务雪崩 |
| 降级 | 熔断或失败后执行兜底逻辑 | 备选方案——走备用通道 | 熔断器打开或调用异常 | 返回友好提示或缓存数据，保障用户体验 |
三者的协作关系：
-
限流是前置防护，在流量入口处控制总量。
-
熔断是中置保护，在调用链路中隔离故障节点。
-
降级是后置补偿，在调用失败时提供替代结果。
18. Sentinel 的限流算法有哪些？滑动窗口和令牌桶的区别是什么？
面试回答：
Sentinel 默认采用滑动窗口算法进行精准计数，但也内置了基于令牌桶思想的限流效果：
| 滑动窗口 | 精准统计实时 QPS，拒绝突发流量 | 快速失败模式（默认） |
| 令牌桶 | 允许突发流量，阈值从低到高缓慢提升 | Warm Up 模式（冷启动预热） |
| 漏桶 | 严格匀速处理请求，不处理突发 | 排队等待模式 |
滑动窗口与令牌桶的核心区别：
| 设计目的 | 精准计数，统计当前时间段的请求量 | 速率控制，均匀放行并允许突发 |
| 数据结构 | 环形数组，时间片随时间滑动 | 桶 + 时间戳差值计算 |
| 突发处理 | 不允许，窗口内计数硬上限 | 允许，桶内积攒的令牌可一次性消耗 |
| 实现开销 | 低，仅维护数组指针和计数器 | 稍高，需维护桶内令牌数 |
一句话总结：滑动窗口是“计数工具”，解决的是“当前到底有多少请求”的问题；令牌桶是“整形策略”，解决的是“请求该以什么速率放行”的问题。
19. Sentinel 的熔断降级原理是什么？断路器状态机如何工作？
面试回答：
Sentinel 的熔断降级基于断路器模式实现，维护了一个三态状态机：
text
CLOSED（闭合）→ 统计指标超过阈值 → OPEN（打开）→ 经过时间窗口 → HALF_OPEN（半开）
→ 请求成功 → CLOSED
→ 请求失败 → OPEN
三种熔断策略：
| 慢调用比例 | 响应时间 > 设定阈值（如 2s）的请求比例超过设定比例 | 依赖服务响应变慢的场景 |
| 异常比例 | 异常请求占总请求数的比例超过设定比例 | 依赖服务抛出大量异常的场景 |
| 异常数 | 异常请求数超过设定阈值（如 10 个） | 关注绝对故障数量的场景 |
核心配置参数：
-
statIntervalMs：统计时长（默认 1 秒）
-
slowRatioThreshold：慢调用比例阈值
-
timeWindow：熔断时间窗口（熔断后多久进入半开状态）
-
minRequestAmount：触发熔断的最小请求数（防止样本太少误判）
20. Spring Cloud Gateway 的三大核心组件是什么？为什么它的性能极高？
面试回答：
三大核心组件：
| 路由（Route） | 由 ID、目标 URI、断言集合和过滤器集合组成，定义“什么请求去往哪里” | 交通路线图 |
| 断言（Predicate） | 匹配 HTTP 请求的条件（路径、方法、Header、参数等），满足则路由生效 | 交通规则判断 |
| 过滤器（Filter） | 在请求路由之前（Pre）和之后（Post）进行加工处理 | 关卡检查站 |
高性能的根本原因：
Gateway 基于 Spring WebFlux + Netty，采用异步非阻塞的 I/O 模型：
| 线程模型 | 一个请求占用一个线程 | 少量 EventLoop 线程处理所有请求 |
| I/O 等待 | 线程阻塞等待后端响应，无法复用 | 线程立即释放，响应回来时通过回调通知 |
| 内存占用 | 每线程 ~1MB 栈空间，高并发下内存爆炸 | 线程数极少，内存占用极低 |
| 并发能力 | 受限于线程数（通常 200-1000） | 理论上无上限，可轻松支撑数万并发 |
面试加分点：Gateway 本身是“请求转发代理”，几乎不涉及 CPU 密集型计算，属于典型的 I/O 密集型场景。异步非阻塞模型能最大化利用系统资源，这就是它比传统同步网关（如 Zuul 1.x）性能高出 2-3 倍的根本原因。
七、总结与加餐
以上 20 个问题覆盖了 Spring Boot 和 Spring Cloud Alibaba 面试中最核心的知识点。掌握这些内容，你将具备应对绝大多数微服务面试的信心。
| 基础层 | 自动配置原理、IoC 容器、生命周期 | Spring Boot |
| 服务治理层 | 注册发现、配置管理、CAP 选型 | Nacos |
| 通信层 | 远程调用、负载均衡、超时控制 | OpenFeign + LoadBalancer |
| 流量治理层 | 限流、熔断、降级、算法原理 | Sentinel |
| 网关层 | 路由、断言、过滤器、高性能原理 | Spring Cloud Gateway |
点赞 + 收藏 + 关注，是对我“技术考古”四年最大的支持！
私信回复 “微服务面试” ，可获取完整思维导图 + 面试真题手册。
更多底层拆解文章，持续更新中……
作者：一个手写过 Java Web 框架的硬核爱好者，WWAIC 范式提出者。坚信“只有拆到底层，才能站在高处”
