谢飞机踏坑记：Java核心、Spring全家桶、Redis与Kafka在电商微服务面试中的灵魂拷问

谢飞机踏坑记：Java核心、Spring全家桶、Redis与Kafka在电商微服务面试中的灵魂拷问

上午十点，大厂面试间。阳光透过落地窗照在一张长桌上，面试官王工端着保温杯，眼神锐利。对面坐着一位头发凌乱的年轻人，谢飞机，背包上挂着一只黄澄澄的飞机挂件，嘴角还沾着没擦干净的煎饼渣。

王工放下保温杯，开口：“谢飞机是吧？简历写得挺满，那我们开始吧。先聊聊你最熟的 Java 基础。”

第一轮：Java 基础与 Spring 框架

王工： “你简历上写熟悉 Java 8 和 Java 11，那么说说看，Java 8 和 Java 11 的主要区别有哪些？”

谢飞机： “Java 8 有 Lambda 表达式、Stream 流、Optional，还有新的日期时间 API。Java 11 嘛……Java 11 是在 Java 9 之后嘛，Java 9 引入了模块化，Java 11 是 LTS 版本，有了 var 关键字，还能直接运行 .java 单文件。哦对，还加了 ZGC，但是那个……具体我怎么调没试过。”

王工： （点头） “基础还行。那 JVM 内存区域呢？堆和栈有什么区别？”

谢飞机： “堆是存对象的，栈是存引用的，还有方法区存类信息。堆是所有线程共享的，栈是线程私有的。局部变量在栈里，new 出来的对象在堆里。”

王工： “那 Minor GC 和 Full GC 一般发生在什么时候？”

谢飞机： “Minor GC 就是在伊甸园满了的时候……Full GC 就是老年代满了……还有 MetaSpace 满了也会……大概是这样。具体的我有点……背过，但不深。”

王工： （眉头微皱） “我们再回来看 Spring。Spring 的核心 IOC 和 AOP 你应该很清楚吧？”

谢飞机： “清楚清楚！IOC 就是控制反转，原本自己 new 对象，现在交给 Spring 容器管理。AOP 就是面向切面编程，可以把日志、事务这些横切逻辑抽取出来，用 @Aspect、@Before、@After 来切。”

王工： “那 Spring Boot 的自动配置原理呢？你知道吗？”

谢飞机： “这个我知道一点，就是启动类上的 @SpringBootApplication，里面包含了 @EnableAutoConfiguration，它通过 SpringFactoriesLoader 去加载 META-INF/spring.factories 文件里的配置类，然后根据 @ConditionalOnClass 之类的条件来做自动装配。”

王工： “哦？那 spring.factories 里配置的是什么？条件注解失效怎么办？”

谢飞机： “配置的是……各种 AutoConfiguration 类。失效的话……可能就是类路径下没有对应的类，就不生效。这个我实际开发中主要都是直接用，没太深究。”

王工： （喝着水） “好。最后一个问题，假设我们有一个电商系统，用户下单的接口，从 HTTP 请求进来，到你执行 SQL 更新库存，整个链路中你认为哪些环节可能出现性能问题？”

谢飞机： “网络延迟！数据库连接池不够！还有 SQL 没走索引！还有……呃，如果数据库太大了可能要分库分表。嗯……反正就是这些。”

王工： “嗯，回答得比较表面。我们换个话题，聊聊数据库和缓存吧。”

第二轮：缓存、消息队列与分布式事务

王工： “大促的时候，系统流量是平时的十倍。假设我们把商品信息放在 Redis 缓存里，怎么做才能避免缓存穿透、缓存击穿和缓存雪崩？”

谢飞机： “这个我熟！缓存穿透就是查一个不存在的 id，每次都会打到数据库，解决方法是把空值也缓存起来，或者用布隆过滤器。缓存击穿就是某个热点 key 失效，突然大量请求打到数据库，可以用互斥锁，让只有一个请求去重建缓存。缓存雪崩就是大量 key 同时失效，可以把过期时间加个随机值，避免集体失效。还可以用集群保证 Redis 高可用。”

王工： （难得露出微笑） “不错。那数据库和缓存的数据一致性呢？比如更新商品价格，你怎么保证 Redis 里的数据和 MySQL 里的一致？”

谢飞机： “先更新数据库，再删缓存！这样下次查询的时候会 miss，再加载到缓存里。”

王工： “那如果更新数据库成功了，但是删缓存失败了，怎么办？”

谢飞机： “……” （挠头） “这个……可以重试吧……用消息队列？或者设置比较短的过期时间？我觉得最终一致嘛，过期了就一致了。”

王工： （不置可否） “好，下一个。用户下单之后，我们要异步给下游系统发一条 Kafka 消息。如何保证消息不丢？”

谢飞机： “生产者设置 acks=all，这样 leader 和副本都写成功才返回。消费者呢，要手动提交 offset，等业务处理完再提交。然后 Kafka 本身可以把副本因子设成 3，这样 broker 挂了也有副本。”

王工： “那 Kafka 消息如何做到不重复消费呢？尤其是消费者处理完业务但还没来得及提交 offset，就挂了，重启后就会重复消费。”

谢飞机： “这个……可以用幂等性。就是 consumer 处理消息时，把消息的 id 存到业务表里，数据库唯一约束，重复插入就报错，然后 catch 掉。或者用 Redis setnx。”

王工： “那如果下单和扣库存不在一个服务里，一个在订单服务，一个在库存服务，怎么保证分布式事务？”

谢飞机： “可以用分布式事务框架，比如 Seata 的 AT 模式。也可以……用本地消息表？就是先写一个消息表，然后发送消息，下游消费再处理。但是 Seata 的实现原理我记不太清了。”

王工： “记不清没关系。那你觉得本地消息表的最终一致性方案，和 Seata 的 AT 模式，各自有什么优缺点？”

谢飞机： “本地消息表实现简单，但是业务和消息表要在同一个数据库里，而且会有消息积压。Seata 的话……AT 模式会对数据库加锁，性能有损耗。其他的……我说不太出来。”

王工： “嗯，你的知识有点散。没关系，我们再往上层走，聊聊微服务。”

第三轮：微服务、网关与云原生

王工： “你已经提到了 Seata，那我们先说说服务发现。你们微服务用什么做注册中心？Eureka、Consul 还是 Nacos？”

谢飞机： “我们现在用的 Nacos。Eureka 已经不更新了。Nacos 还带配置中心，方便。”

王工： “为什么 Eureka 不更新了？Nacos 跟 Eureka 在 CAP 上有什么区别？”

谢飞机： “Eureka 是 AP 的，就是保证可用性和分区容错性，不保证一致性。Nacos 的话……它好像是可以选择 AP 和 CP？具体怎么切换我忘了。”

王工： “切到微服务之间调用，你们用 OpenFeign 吧？Feign 的超时和熔断怎么做？”

谢飞机： “Feign 可以设置连接超时和读取超时，在配置文件里。熔断的话用 Resilience4j，在客户端加 @CircuitBreaker 注解。然后指定 fallback 方法。参数嘛……超时时间设个 2 秒，失败率阈值 50%，滑动窗口大小是 100？大概……嗯。”

王工： “好，那网关这一层，你怎么理解 JWT 和 OAuth2 的区别？如果让做一个 API 网关的登录鉴权，你会怎么设计？”

谢飞机： “JWT 是一种 token 格式，OAuth2 是一种授权框架。JWT 里面可以放用户信息，无状态，网关验签就行。OAuth2 有 Authorization Code、Client Credentials 几种模式，适合第三方授权。如果网关做登录鉴权的话，我可以用 JWT，然后通过 Spring Security 的过滤器来校验 token。至于 OAuth2 怎么对接 Keycloak，我大概知道流程，但具体的代码……”

王工： （摆摆手） “不用展开代码了。再问你 Kubernetes。一个 Pod 在更新或者重启的时候，流量是瞬间切走还是等它退出？为什么？”

谢飞机： “应该……集群会自动处理吧？Pod 退出时，Endpoint 会摘掉？然后流量就不会打过来了。”

王工： “如果业务服务需要做优雅停机，比如等正在处理的请求完成，Kubernetes 的哪种探针能保证？”

谢飞机： “优雅停机？用 PreStop？然后配合……ReadinessProbe？LivenessProbe是探测存活的，ReadinessProbe是探测是否就绪的。具体到优雅停机，应该是靠终止信号和 PreStop hook，ReadinessProbe 提前将流量摘掉……然后 JVM 的 ShutdownHook 处理剩余请求？”

王工： “哦？你还知道 ShutdownHook。那最后一个问题，你们生产环境怎么做监控和告警？”

谢飞机： “用 Prometheus 抓取指标，Grafana 展示，Micrometer 暴露 JVM 指标。Spring Boot 有 actuator，可以暴露 /actuator/prometheus 端口。然后告警规则在 Prometheus 里配置 Alertmanager，发到钉钉……”

王工： “Zipkin 和 Jaeger 是用在什么场景的？”

谢飞机： “链路追踪。就是……一个请求经过多个服务，可以用 traceId 串起来，看每个服务耗时。”

王工： （放下保温杯，站起来） “好了，谢飞机，今天面试就到这儿吧。你回去等通知，我们还有几个候选人要聊。出门的时候帮我把门带上，顺便让门口的保洁阿姨也进来一趟。”

谢飞机： “好的好的，谢谢王工！那个……我是有机会进入下一轮吗？”

王工： “下不下轮不知道，但保洁阿姨是真的需要。”

附：面试问题详细答案与技术点讲解

以上所有问题的答案，这里给出系统性的讲解。以下内容适合 Java 求职者作为学习笔记，按三轮面试的顺序展开。

第一轮：Java 基础与 Spring 框架

1. Java 8 与 Java 11 的主要区别

• Java 8（2014 年 LTS）带来的核心能力：Lambda 表达式、Stream API、Optional、新的日期时间 API（java.time）、接口默认方法和静态方法、方法引用、CompletableFuture 等。
• Java 11（2018 年 LTS）在 Java 9/10 基础上新增/完善了：
  • var 局部变量类型推断：var list = new ArrayList<String>();，注意只能用于局部变量，不能用于成员变量、方法参数（Java 10 就支持了，Java 11 是 LTS）。
  • 直接运行单文件 Java 源码：java HelloWorld.java，无需先 javac。
  • ZGC 垃圾收集器（实验性）：超低停顿，但 JDK 11 中还不能用于生产环境，JDK 15 才转正，JDK 17 后逐渐成熟。
  • String 类新增 isBlank()、strip()、lines()、repeat() 等方法。
  • HttpClient 替代旧的 HttpURLConnection。
• 另外，从 Java 9 开始引入模块系统（Project Jigsaw），Java 11 模块化已经完整，但企业级 Spring Boot 项目很少直接依赖模块文件，多数仍按 classpath 运行。

2. JVM 内存区域（运行时数据区）

JVM 的内存区域分为线程共享和线程私有两大类：

• 线程私有：
  • 程序计数器：记录当前线程执行的字节码行号。如果执行 native 方法，其值为空（undefined）。不会 OOM。
  • 虚拟机栈：存放栈帧，每个方法调用对应一个栈帧。栈帧里有局部变量表、操作数栈、动态链接、返回地址。局部变量表中存基本类型、对象引用、returnAddress。栈深不足会抛 StackOverflowError。
  • 本地方法栈：为 native 方法服务，HotSpot 中与虚拟机栈合并。
• 线程共享：
  • 堆：几乎所有的对象实例和数组都在堆上分配。堆是垃圾回收的主要区域，进一步分为新生代（Eden、Survivor 0、Survivor 1）和老年代。堆可以是不连续内存。
  • 方法区：存储已被 JVM 加载的类型信息、常量、静态变量、即时编译器编译后的代码缓存。JDK 8 以后方法区实现为元空间（MetaSpace），使用本地内存，不再容易 OOM，但还是可能因为加载类过多而 OOM。

3. Minor GC 和 Full GC 触发条件

• Minor GC（新生代 GC）：当 Eden 区空间不足时，触发 Minor GC。将 Eden 和一个 Survivor 区中还存活的对象复制到另一个 Survivor 区（或晋升到老年代），清理 Eden 和原 Survivor。Minor GC 非常频繁，通常速度较快。
• Full GC（老年代 GC）：指对整个堆（新生代、老年代、方法区/元空间）进行垃圾收集。触发条件包括：
  • 老年代空间不足（比如大对象直接进入老年代、晋升失败、长期存活对象过多）。
  • 元空间/永久代空间不足。
  • 调用 System.gc() 时，JVM 只是建议触发 Full GC，不保证立即执行。
  • 晋升对象大小超过老年代剩余空间，或者 CMS 遇到并发模式失败（G1 也一样）。
• 生产环境常用 G1，通过 -XX:+UseG1GC。G1 将堆划分为 Region，用混合回收避免 Full GC，但如果回收速度跟不上分配速度，还是会"Full GC（Serial）"。

4. Spring IOC 与 AOP

• IOC（Inversion of Control，控制反转）：将对象的创建和依赖关系的管理交给 Spring 容器。原来的程序主动 new 对象，现在是容器注入。核心容器是 BeanFactory 和 ApplicationContext。依赖注入（DI）是 IOC 的一种实现方式，支持构造器注入、Setter 注入、字段注入（不推荐字段注入，避免隐藏依赖）。
• AOP（Aspect Oriented Programming，面向切面编程）：通过动态代理将横切逻辑（事务、日志、权限、性能监控）织入业务方法。Spring AOP 默认使用 JDK 动态代理（目标类实现了接口）和 CGLIB 代理（目标类没有接口，或通过 proxyTargetClass 强制使用 CGLIB）。关键注解：@Aspect、@Before、@After、@Around、@AfterReturning、@AfterThrowing、@Pointcut。

5. Spring Boot 自动配置原理

• 核心注解 @SpringBootApplication 是一个组合注解，包含 @SpringBootConfiguration、@EnableAutoConfiguration、@ComponentScan。
• @EnableAutoConfiguration 通过 @Import(AutoConfigurationImportSelector.class) 导入选择器。
• AutoConfigurationImportSelector 会扫描依赖中 META-INF/spring.factories（旧版本）或 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports（Spring Boot 2.7+）文件。
• 文件中列出所有候选的 AutoConfiguration 类，然后通过条件注解（如 @ConditionalOnClass、@ConditionalOnMissingBean、@ConditionalOnProperty、@ConditionalOnWebApplication）判断是否生效。
• 例如：引入了 spring-boot-starter-web 后，DispatcherServletAutoConfiguration 会生效，自动配置 Spring MVC 的前端控制器；如果用户自己定义了 WebMvcConfigurer 或 DispatcherServlet，自动配置会通过 @ConditionalOnMissingBean 让位。

6. 用户下单接口的性能风险点

从 HTTP 请求到数据库更新，典型的链路是：

• 客户端 → Nginx/LB → API 网关 → Spring Boot 应用（Servlet 线程池）→ Controller → Service → DAO → MyBatis → 数据库连接池 → MySQL。
• 性能风险包括：
  1. 网络带宽与 DNS 解析：请求体过大、连接数过多。
  2. 网关/负载均衡：转发规则复杂、连接池不够。
  3. 应用线程池：Tomcat 默认最大线程数 200（Spring Boot 2 中 server.tomcat.threads.max=200），并发过高时线程排队导致请求变慢。
  4. 对象序列化/反序列化：JSON 转换性能。
  5. 业务代码中的串行调用：如多个远程服务 RPC 串行调用，应并行化或异步化。
  6. 数据库连接池：HikariCP 默认 maximumPoolSize=10，连接池打满就等。
  7. SQL 性能：没建索引、回表、锁竞争、慢 SQL。
  8. Redis/缓存：缓存穿透、击穿、雪崩都会让请求打到数据库。
  9. 外部接口：支付、短信等第三方 RPC 超时拖垮线程。
  10. GC 问题：频繁 Full GC 导致应用暂停。

第二轮：缓存、消息队列与分布式事务

1. 缓存穿透、缓存击穿、缓存雪崩

• 缓存穿透：查询一个数据库中不存在的数据，缓存里也没有，每次请求都直接打到 DB。攻击者可以用不存在的 ID 频繁请求。
  • 解决：将空值也缓存，但设置较短的过期时间；使用布隆过滤器，先在布隆过滤器中判断 ID 是否存在，不存在直接返回；增强参数校验。
• 缓存击穿：某一个热点 key 过期，大量并发请求同时查询该 key，全部打到 DB。
  • 解决：互斥锁（Redis SETNX），只让一个线程去 DB 查并重建缓存，其他线程等待；逻辑过期策略，即把过期时间写入 value，后台异步刷新热点 key；对热点 key 设置永不过期，但要注意手动更新。
• 缓存雪崩：大量 key 在同一时间集中过期，或者 Redis 实例宕机，请求全部打到 DB 导致系统崩溃。
  • 解决：过期时间增加随机值（如 5 分钟 ± 随机 1~3 分钟）；使用 Redis 集群/哨兵模式；设置多级缓存（本地缓存 + Redis）；提前做流量控制与熔断降级。

2. 数据库与缓存一致性

主流做法：Cache Aside Pattern（旁路缓存）

• 读：先读缓存，命中就返回；未命中则读 DB，再写回缓存，并返回。
• 写：先更新数据库，然后删除缓存。
• 为什么删除而不是更新缓存？因为直接更新缓存可能产生脏数据（先更新 DB，再更新缓存，如果两个请求并发，后发的缓存可能覆盖先发的，但 DB 顺序可能相反）。删除缓存后，下一次读会去 DB 拉最新值，更稳妥。
• 如果删缓存失败，如何保证最终一致？
  • 重试机制：把删除失败的 key 丢进消息队列，后台线程重试。
  • 订阅 MySQL binlog（如 Canal），基于 binlog 异步删除缓存。
  • 给缓存设置合理的过期时间，即使暂时不一致，也会在过期后回填最新数据。
  • 注意：出现"先删缓存，后更数据库"的方式在并发时更容易出问题，所以通常不推荐。

3. Kafka 消息不丢失

Kafka 消息不丢失分为三个方面：

• 生产者端：
  • acks=all（或 acks=-1），要求所有 ISR 副本都确认写入后才算成功。
  • retries 设置一个较大值（如 Integer.MAX_VALUE），并开启 enable.idempotence=true（幂等性）。
  • 使用带回调的 send() 方法，如果发送失败要进行重试或落盘。
• Broker 端：
  • 设置 replication.factor >= 3，确保有多个副本。
  • min.insync.replicas >= 2，表示最少有两个副本同步成功才算写入成功。
  • unclean.leader.election.enable=false，避免选举落后过多的副本成为 leader 导致数据丢失。
• 消费者端：
  • enable.auto.commit=false，手动提交 offset。
  • 在业务逻辑处理完成后再提交 offset，确保消费不丢。但要注意重复消费问题，需要幂等。

4. Kafka 重复消费与幂等

重复消费的根本原因：消费者已经处理了消息，但还没来得及提交 offset，进程崩溃/重启，Kafka 从旧的 offset 重新拉取消息。

解决方案：

• 业务幂等：消费时判断消息是否已经处理过。例如：
  • 在数据库表中使用业务唯一键（订单号、消息 ID）做唯一约束，插入时冲突则忽略。
  • 使用 Redis SETNX，如果消息 ID 已经存在则跳过。
  • 在数据库中先查后插，但最好依赖唯一索引。
• 消费者使用事务：如将 offset 的提交与业务数据的增删改放在同一个本地事务中（Spring Kafka 的 KafkaTemplate 配合 @Transactional），或者使用 Kafka 的 read_committed 隔离级别，但这是跨系统的一致性，实现复杂。

实际生产中最常用的是：手动提交 + 消费幂等。

5. 分布式事务：Seata AT 模式 vs 本地消息表

本地消息表方案：

• 将"业务操作"和"写消息表"放在同一个本地事务中（同一个数据库）。
• 事务提交后，通过定时任务或异步线程将消息表中的消息发送给 MQ。
• 下游消费者收到消息后处理自己的业务，处理成功后向消息表发送确认（通过另一个 MQ 或调用接口）。
• 上游定时扫描未确认的消息，重新发送。

优点：实现简单，不依赖额外中间件（除了已有的 DB 和 MQ）；最终一致性有保证。 缺点：业务表与消息表耦合在同一个库；消息表可能成为性能瓶颈；需要自行处理消息重复和乱序。

Seata AT 模式：

• 基于两阶段提交的变体。
• 一阶段：生成 undo log，执行业务 SQL，并快速提交本地事务，同时将资源锁住。
• 二阶段：如果全局事务提交，异步删除 undo log；如果回滚，根据 undo log 反向补偿生成反向 SQL（例如 insert 变成 delete，update 变回原值）。
• 事务协调者（TC）负责全局事务的提交与回滚决策。

优点：对业务代码侵入小，只需要在业务方法上标注 @GlobalTransactional；在数据库层面实现了完整的一致性，且支持跨库、跨服务。 缺点：性能有额外开销（协调者通信、全局锁）；需要额外的 TC 服务部署；对数据库连接池和 SQL 有一定要求（避免使用 LIMIT、JOIN 等无法反解析的语句）。

其他方案：TCC（Try-Confirm-Cancel）、Saga（长事务，适合涉及外部系统）、最大努力通知等。面试中要能说出取舍。

第三轮：微服务、网关与云原生

1. Eureka vs Consul vs Nacos 与 CAP

• Eureka：Netflix 开源的服务注册中心。属于 AP 架构，优先保证可用性，各节点平等，只要有一个 Eureka 存活就能注册/发现，但注册信息可能不一致。Spring Cloud Netflix 体系中大量使用。从 Netflix 官方宣布维护模式后，新项目多转向 Nacos/Consul。
• Consul：HashiCorp 出品，属于 CP 架构，通过 Raft 协议保证强一致性，提供注册、发现、健康检查、KV 存储、多数据中心能力。
• Nacos：阿里开源，同时支持 AP 和 CP，可以切换（默认 AP）。在服务发现场景下使用 AP，保证注册可用；在配置中心场景下支持 CP 保证配置一致。它的优点是集注册中心和配置中心于一体，中文社区活跃。

CAP 理论：分布式系统无法同时满足一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。P 是必选，所以通常要么是 AP 要么是 CP。

2. OpenFeign 超时与熔断，Resilience4j

• OpenFeign 是一种声明式 REST 客户端。默认超时可配置：

  feign:
    client:
      config:
        default:
          connectTimeout: 2000
          readTimeout: 5000
  

  也可以为指定服务名配置。

• 熔断：Spring Cloud 早期集成 Netflix Hystrix，现在官方推荐 Resilience4j。

  • 使用 @CircuitBreaker(name = "inventoryService", fallbackMethod = "fallback")。
  • 核心参数：
    • failureRateThreshold：失败率阈值，默认 50。
    • slidingWindowSize：滑动窗口大小，默认 100。
    • minimumNumberOfCalls：最少调用次数，默认 100。
    • waitDurationInOpenState：熔断打开后等待多久进入半开状态。
    • permittedNumberOfCallsInHalfOpenState：半开时允许的调用数量。
  • 熔断状态机：关闭（Closed）→ 打开（Open）→ 半开（Half-Open） → 关闭或打开。当调用失败率达到阈值，熔断器打开，所有请求快速失败；过一段时间后进入半开状态，放少量请求试探，如果恢复正常则关闭熔断。

3. JWT vs OAuth2，网关鉴权设计

• JWT（JSON Web Token）：是一种紧凑的、URL 安全的令牌格式，由 Header、Payload、Signature 三部分组成。签名用于防止篡改，可以由接收方用密钥或公钥验签，因此是无状态、可验证的。通常用于单点会话令牌、API 鉴权。
• OAuth2：是一种授权框架，解决"第三方应用如何安全地代表用户访问资源"的问题。涉及资源所有者、客户端、授权服务器、资源服务器四个角色。常见授权模式：Authorization Code（授权码）、Client Credentials（客户端凭证）、Password（密码模式，已废弃）、Implicit（隐式，已废弃）。OAuth2 颁发的 token 可以是 JWT 格式，也可以是不透明的随机字符串。
• 网关鉴权设计：
  • 客户端携带 JWT 访问网关。
  • 网关的认证过滤器先解析 JWT（或用公钥验签），校验签名、过期时间、issuer、audience。
  • 校验通过后，将用户信息放入请求头（如 X-User-Id）转发给下游服务。
  • 若涉及刷新 token、动态权限，可以结合 OAuth2 + Keycloak 等统一认证中心。网关只做 token 校验，权限判断可以在网关（简单）或各微服务（复杂）中实现。
  • 注意：JWT 无法主动失效，所以如果需要踢人/改权，请配合 Redis 黑名单或改用有状态 session。

4. Kubernetes 中 Pod 重启与优雅停机

• 当 Pod 被删除或滚动更新时，Kubernetes 会从 Service 的 Endpoints（或 EndpointSlice）中移除该 Pod 的 IP，新的流量不再转发给该 Pod。但已建立的连接（如果 Service 是 TCP 四层负载）仍然会存在，直到连接关闭或超时。
• 优雅停机需要应用配合：
  • 在 Pod 删除时，Kubernetes 向容器发送 SIGTERM 信号（默认 30 秒宽限期，可通过 terminationGracePeriodSeconds 调整）。
  • 应用收到 SIGTERM 后应停止接收新请求，处理完正在执行的请求，关闭连接池和线程池，最后退出。Spring Boot 应用可以通过 server.shutdown=graceful 配合 Spring Boot 2.3+ 实现，也可以自定义 ShutdownHook。
  • PreStop hook 可用于在容器停止前执行一些操作，比如 sleep 几秒，等待负载均衡器摘除节点。
• ReadinessProbe（就绪探针）：探测 Pod 是否能够接收流量。如果失败，Kubernetes 会从 Service Endpoints 中移除该 Pod，不转发流量。LivenessProbe（存活探针）：探测 Pod 是否还活着。如果失败，Kubernetes 会重启容器。
• 优雅停机的正确姿势：先让 ReadinessProbe 失败（比如通过 actuator 的 health 状态改为 DOWN），再从 Endpoints 摘除，然后发送 SIGTERM，最后完成已有请求处理并退出。

5. Prometheus、Micrometer、Grafana、Zipkin/Jaeger

• Micrometer 是一个指标门面库，相当于 SLF4J 之于日志。Spring Boot 2 中依赖 micrometer-registry-prometheus 后，Actuator 会自动暴露 /actuator/prometheus 端点，输出 Prometheus 格式的指标，比如 JVM 内存、GC 次数、线程数、HTTP 请求耗时等。
• Prometheus 是一个监控系统，采用拉取模型，定期从目标端点抓取指标。它通过服务发现来找到应用实例，并支持 PromQL 查询和告警规则。
• Grafana 负责可视化，从 Prometheus 数据源读取数据，生成仪表盘。
• Zipkin/Jaeger 是分布式链路追踪系统。一次请求经过多个微服务时，在入口生成一个 TraceID，在各个服务中生成 SpanID，并把调用父子关系和时间戳上报到 Collector。通过链路追踪可以看到请求在哪个服务耗时最大，是否出现错误。
• 典型组合：Micrometer + Prometheus + Grafana 解决监控+告警+可视化；OpenTelemetry + Jaeger/Zipkin 解决链路追踪。

写在最后

面试官王工的问题，从源码到架构，从单机到分布式，从开发到运维，层层递进。很多候选人像谢飞机一样，背过八股文，但经不起追问。上面的答案不是为了让你死记硬背，而是帮你建立知识网络。尤其是像"缓存一致性""消息可靠性""分布式事务""优雅停机"这类问题，光知道名词没用，必须理解它们为什么是这样，以及各自的取舍。

如果你也准备参加大厂 Java 面试，建议按照这个思路，把上面的每个点都用自己的话复述一遍，再结合项目实践做几个实验。真正的掌握，是能接住面试官连续的"为什么"。

至于谢飞机最终有没有等到通知呢？他回家后，打开电脑，默默翻开了《Java 并发编程的艺术》。而保洁阿姨确实进了会议室，把工位底下一个落灰的键盘捡走了。

（完）