互联网大厂 Java 面试实录：Spring Boot、Kafka、Redis、JWT、Kubernetes 与 AI 架构深挖
场景：某互联网大厂招聘Java 后端工程师，业务方向为本地生活服务 + 智能客服 + 企业协同。面试官严肃、追问连环；候选人燕双非嘴上“问题不大”，实战一到复杂处就开始含糊其辞。
第一轮：基础架构与核心栈
面试官：先说说你们线上 Java 服务为什么选择Spring Boot + JUnit 5 + Mockito + Lombok，而不是一堆手写配置？
燕双非：因为……它比较快，开箱即用，少写 XML，单测也方便，嗯，挺适合大厂。
面试官：回答得还行。那你说说Spring Boot的自动配置原理，为什么能根据依赖自动装配？
燕双非：它应该是启动时扫描了很多配置类，按条件加载吧，具体我平时主要看效果……
面试官：好，继续。你们服务里用了Redis + Caffeine + Spring Cache做两级缓存，怎么避免缓存击穿和脏数据？
燕双非：这个我们一般会加锁，或者设置过期时间，至于脏数据嘛……尽量同步更新？
面试官：再问一个偏业务的。你们本地生活场景的优惠券系统，为什么要引入Kafka做异步解耦，而不是直接同步写库？
燕双非：因为用户抢券嘛，流量很大，Kafka 可以削峰填谷，避免主链路被打爆。
面试官点点头：这个方向对，说明你至少知道高并发场景的基本解法。
第二轮：微服务、网关与安全
面试官：你们做多服务拆分后，服务间调用怎么设计？为什么不用纯 HTTP，反而引入gRPC + OpenFeign？
燕双非：Feign 好写，gRPC 速度快，适合内部高频调用。一个偏简单，一个偏性能。
面试官：不错。那如果某个下游服务波动，怎么做限流、熔断、降级？你会怎么用Resilience4j？
燕双非：我会给接口加熔断器，失败多了就快速失败，降级返回兜底数据，别让用户一直等。
面试官：可以。那你说说Spring Security + JWT + OAuth2 + Keycloak在企业协同 SaaS 里怎么配合？
燕双非：登录的时候走 OAuth2，拿到 token 后带 JWT，Spring Security 负责鉴权，Keycloak 主要管统一身份认证和权限中心。
面试官：嗯，方向正确。最后一个问题：如果你们做的是企业协同平台，多租户隔离怎么做，权限模型怎么落？
燕双非：这个一般会按租户 ID 做数据隔离，权限的话可能是 RBAC，再细一点加资源维度控制。
面试官：回答还算完整，至少没把“多租户”说成“多开几个库”那么离谱。
第三轮：AI、可观测性与复杂业务落地
面试官：现在很多业务都在上 AI。假设你的智能客服系统要接入Spring AI + RAG + 向量数据库，你会怎么设计？
燕双非：先把知识库文档切片，做 Embedding，再存到向量库里。用户提问时先语义检索，再把相关片段拼进提示词，让大模型回答。
面试官：很好。那如果客服回答出现AI 幻觉，你怎么控制？
燕双非：……可以加检索约束，限制模型只基于知识库回答；再加提示词规范和答案置信度判断。
面试官：继续。你们系统如果要把 AI 流程做成多步任务，比如“检索文档—调用订单系统—生成工单—通知人工”，你会怎么理解Agent / 工具调用标准化 / 复杂工作流？
燕双非：就是让 AI 不只会聊天，还能按步骤调用工具。先规划，再执行，工具调用要统一协议，不然对接太乱。
面试官：最后说下线上排障。你怎么用Micrometer + Prometheus + Grafana + Jaeger/Zipkin + ELK排查链路问题？
燕双非：指标看 Prometheus，图表看 Grafana，日志看 ELK，调用链看 Jaeger 或 Zipkin。先看慢在哪，再定位到具体服务和 SQL 或外部依赖。
面试官：行，今天先到这。你回去等通知吧。
问题详解与参考答案
1. Spring Boot 自动配置为什么能工作？
Spring Boot 的核心是约定优于配置。它通过启动类、自动配置类、条件注解（如@ConditionalOnClass、@ConditionalOnMissingBean）以及spring.factories/AutoConfiguration.imports等机制，根据类路径依赖和当前环境动态装配 Bean。业务上，这意味着你在本地生活优惠券服务中只要引入 Redis、Kafka、Web 相关依赖，框架就会自动初始化大部分基础设施，显著减少样板代码。
2. 两级缓存如何防击穿与保证一致性？
两级缓存通常是Caffeine 本地缓存 + Redis 分布式缓存。Caffeine 承担热点数据快速读取，Redis 作为共享缓存。防击穿常见手段包括：热点 Key 永不过期或逻辑过期、互斥锁/单飞、预热。保证一致性时，可采用先更新数据库，再删除缓存或延迟双删策略。对券库存这类强一致场景，还要结合消息队列异步补偿和乐观锁，避免超卖。
3. 为什么高并发业务要用 Kafka 异步解耦？
在抢券、下单、支付回调等场景中，主链路不能被下游非核心动作拖慢。Kafka 适合高吞吐、可水平扩展的消息处理：请求先快速入队，后续库存扣减、风控、通知、埋点等异步消费。这样既削峰填谷，也便于重试和补偿。相比同步 RPC，消息队列更能保护核心交易链路。
4. gRPC 和 OpenFeign 怎么选？
OpenFeign适合内部 REST 风格调用，开发体验好，结合 Spring Cloud 很方便；gRPC基于 Protobuf，二进制传输、高性能、强约束，更适合低延迟、高频、强类型的内部调用。比如企业协同中的审批流、消息通知、实时状态同步，若接口频繁且对性能敏感，可优先考虑 gRPC。
5. Resilience4j 如何做熔断、限流和降级？
它可用于给外部依赖加保护：统计失败率、慢调用比例达到阈值后自动熔断；通过限流器控制并发；在异常时返回兜底数据。业务上如第三方地图、短信、支付网关波动时，系统应快速失败并给出可接受的替代结果，防止级联故障。
6. Spring Security + JWT + OAuth2 + Keycloak 如何协作？
Keycloak 充当统一身份认证和授权服务器，负责用户登录、令牌签发、角色与权限管理；OAuth2 定义授权协议；JWT 作为无状态 token 承载用户身份和权限信息；Spring Security 则在资源服务器侧完成 token 校验和接口鉴权。对于企业协同 SaaS，多租户通常还要在 token 中携带 tenantId，并在数据库层、缓存层、业务层做租户隔离。
7. 智能客服里的 RAG 为什么比“直接问大模型”更靠谱？
RAG（检索增强生成）先从企业文档、FAQ、工单系统中检索相关知识，再将结果注入提示词给模型生成答案。这样模型回答受控、可追溯、更新快，能显著降低幻觉。对客服系统来说，知识库更新后无需频繁微调模型，只要更新文档和向量索引即可。
8. 如何抑制 AI 幻觉？
常见做法：检索约束（要求回答必须基于检索结果）、提示词模板（明确禁止编造）、答案校验（置信度、引用来源、规则校验）、工具调用（需要实时数据时调用订单、库存、工单系统）。在复杂业务流程中，AI 更适合作为编排层，而不是“凭空生成一切”。
9. Agent、工具调用标准化、复杂工作流怎么理解？
Agent 可以理解为“会规划、会调用工具、会根据结果继续决策的智能体”。当客服机器人要完成“查订单—查物流—生成工单—通知人工”时，不只是一次问答，而是一个多步骤工作流。工具调用标准化则是用统一协议描述工具名称、输入输出、鉴权方式，便于不同模型和不同服务接入。
10. 可观测性如何支撑大厂线上排障？
Micrometer负责埋点指标，Prometheus抓取并存储时序数据，Grafana负责可视化看板，ELK用于日志检索，Jaeger/Zipkin用于分布式链路追踪。排障时通常先看告警，再看指标趋势，接着定位慢链路，最后结合日志和 SQL 解释根因。对大厂而言，可观测性是稳定性治理的基础。
结语
以上就是本次互联网大厂 Java 面试实录与详细解析。希望这篇文章能帮助大家更好地理解 Spring、Kafka、Redis、安全、AI 与可观测性等核心知识，并在面试和实战中更有底气。感谢阅读，愿这篇内容真的能帮到你。
