互联网大厂 Java 面试实录：Spring Cloud + Kafka + Redis + Docker/Kubernetes + Spring AI 场景深挖
互联网大厂 Java 面试实录：Spring Cloud + Kafka + Redis + Docker/Kubernetes + Spring AI 场景深挖
场景：企业协同与 SaaS / 智能客服 / 云原生与 AIGC 落地
面试官：严肃、追问细节。
候选人：水货程序员燕双非，简单题能答，难题开始“有点印象”。
第一轮：基础架构与日常业务
1）面试官：如果你负责一个企业协同 SaaS 的任务中心，前端每天会拉取大量待办数据，你会怎么设计后端接口？
燕双非：我会先用 Spring Boot 搭接口，再做分页查询，尽量只返回列表页需要的字段，减少网络传输。数据量大一点的话，我会加缓存，比如 Redis，热点待办可以先查缓存，没命中再查数据库。
面试官：不错，至少知道“少查少传”。那缓存失效怎么办？
燕双非：嗯……可以设置过期时间，或者更新任务状态时主动删缓存，避免旧数据一直显示。
面试官：可以，方向对了。
2）面试官：如果待办列表要支持“我发起的”“我审批的”“抄送我的”三种视图，你会怎么建模？
燕双非：我会在任务表里加业务类型和用户关联关系，比如 task_type、owner_id、approver_id、cc_id 之类，再配合索引做查询。视图层做统一 DTO，避免一个接口返回太多复杂字段。
面试官：还行，知道分层。那如果审批链路经常变，怎么处理？
燕双非：可以把流程配置化，审批节点不要写死在代码里，最好能通过配置或数据库驱动。
第二轮：消息、可靠性与云原生
3）面试官：现在任务中心要和消息通知系统联动，用户审批后要推送站内信、邮件、IM。你怎么做异步化？
燕双非：我会用 Kafka 做消息队列。审批成功后先落库，再发消息到 Kafka，由通知服务消费，分别处理站内信、邮件、IM。这样主流程不会被通知拖慢。
面试官：那如果消息重复消费了呢？
燕双非：嗯……通知服务要做幂等，比如消息表记录业务唯一键，消费前先判断是否处理过，处理过就直接跳过。
面试官：这就对了，异步系统里幂等是基本功。
4）面试官：如果 Kafka 突然积压，用户投诉“审批完很久没收到通知”，你怎么排查？
燕双非：先看消费者有没有挂，消费组是否正常，再看分区是否足够、是否有慢消费者。然后检查监控，比如 Prometheus 和 Grafana 看消费延迟、堆积量，必要时扩容消费者实例。
面试官：思路不错。那你会怎么防止扩容后仍然堆积？
燕双非：可能要优化消费逻辑，减少单条消息处理时间，或者把大任务拆小；如果外部依赖慢，还可以做重试和降级。
5）面试官：你们服务上 Kubernetes 后，如何保证配置和发布安全？
燕双非：配置用 ConfigMap 和 Secret 分开管理，敏感信息放 Secret。发布时用滚动更新，配合健康检查，避免新版本一上来就把旧流量全切掉。
面试官：还可以，至少不是“手动 ssh 上去改配置”那一派。
第三轮：AI 赋能与复杂系统设计
6）面试官：现在老板要求在 SaaS 里加一个智能客服，基于企业文档自动回答问题。你会怎么设计？
燕双非：我会先把企业文档做加载和切分，再做向量化，存到向量数据库里，比如 Milvus 或 Redis 向量能力。用户提问后先做语义检索，召回相关片段，再交给大模型生成答案，这就是 RAG。
面试官：不错，知道 RAG 的基本链路。那为什么不直接让大模型回答？
燕双非：因为它容易幻觉，尤其企业知识更新快，直接答可能乱编。先检索再生成，可以把答案尽量约束在可信资料里。
面试官：说得对。那如果要让客服能调用工单系统、订单系统呢？
燕双非：可以做工具调用，把工单查询、订单查询、用户信息查询封装成标准工具。Agent 根据用户意图决定调用哪个工具，再把结果整理给用户。
面试官：继续说，Agent 怎么避免乱调用？
燕双非：这个……可以加权限控制和工具白名单吧。还有提示词里明确边界，别让它什么都能干。
7）面试官：如果智能客服要接企业内部多个系统，既有 REST，也有 gRPC，你怎么统一接入？
燕双非：可以在服务层做适配器。对外统一成一个服务接口，对内分别调用 REST 或 gRPC。这样上层业务不用关心协议细节。
面试官：还不错。那调用失败怎么办？
燕双非：加超时、重试、熔断和降级。像 Resilience4j 这种组件就挺适合，避免一个下游挂了拖垮整个客服链路。
8）面试官：最后一个问题：如果这套智能客服上线后，用户说“答非所问”，你先查什么？
燕双非：我会先看检索结果准不准，召回的文档片段是不是相关；再看 embedding 和向量库是否有问题；然后看提示词是否太宽泛、上下文是否太长被截断。要是还不行，就怀疑文档切分策略不对。
面试官：行，今天先到这。你回去等通知吧。
问题详解：结合企业协同与 SaaS / 智能客服场景深入理解
1. 任务中心接口为什么要分页、裁剪字段、结合缓存
在企业协同 SaaS 中，待办列表通常访问频繁，且前端只需要展示少量字段。分页可以避免一次性加载过多数据；字段裁剪可以减少网络传输和 JSON 序列化开销；Redis 缓存则适合热点任务或用户常用列表。常见做法是“先查缓存，未命中再查库”，同时在任务状态变更后主动失效缓存，保证一致性。
2. 任务视图如何建模
“我发起的”“我审批的”“抄送我的”本质上是不同的查询维度。工程上通常会通过任务主表 + 关系表来建模，再用索引提升查询效率。展示层最好返回统一 DTO，避免前端强绑定数据库结构。审批链路变化频繁时，流程配置化比写死在代码里更灵活，适合企业协同类场景。
3. 为什么审批后要异步通知
站内信、邮件、IM 通知都属于外部依赖，延迟和失败率不稳定。把它们放到 Kafka 后异步消费，可以把主交易链路和通知链路解耦，提升接口响应速度和系统稳定性。这里的关键点是：消息不能只“发出去”，还要保证消费者幂等、可重试、可追踪。
4. Kafka 积压怎么排查
先看消费者是否存活、消费组是否正常，再看分区是否均衡、消费速率是否低于生产速率。监控上重点关注堆积量、消费延迟、失败率、重试次数。优化方向通常包括：增加消费者实例、提升单条消息处理效率、拆分大消息、减少外部调用阻塞、为慢任务设置隔离队列。
5. Kubernetes 上如何做配置与发布
非敏感配置放 ConfigMap，密码、Token 等敏感信息放 Secret。发布时用滚动更新配合探针，避免实例未就绪就接流量。对于 SaaS 多环境部署，还要注意配置隔离、镜像版本可追溯，以及回滚策略。若配合 CI/CD 工具，如 Jenkins 或 GitHub Actions，可以实现自动化构建、测试、镜像发布与部署。
6. 智能客服为什么需要 RAG
企业知识变化快，单纯依赖大模型容易出现幻觉。RAG 的核心是“先检索再生成”：将企业文档切分、向量化、存入向量数据库；用户提问时先做语义检索，拿到最相关的文档片段，再结合上下文让模型生成答案。这样能显著提升答案的准确性和可追溯性，更适合企业客服、知识库问答和内部助手。
7. Agent 和工具调用的作用
当智能客服不只是回答问题，还要查询订单、创建工单、查看库存时，就需要 Agent 具备工具调用能力。工具调用标准化后，模型可以根据意图选择合适工具。工程上一定要有权限控制、工具白名单、输入校验和审计日志，避免模型“想当然”地执行高风险操作。
8. 如何接入 REST 与 gRPC
对上层业务统一抽象，对下层协议做适配。REST 适合开放接口和简单查询，gRPC 更适合内部高性能通信。若调用链路长，必须设置超时、重试、熔断和降级，避免下游抖动放大到整条链路。Resilience4j 在限流、熔断和隔离方面很实用。
9. 智能客服“答非所问”怎么排查
排查顺序通常是：检索是否准确、召回文档是否相关、向量化模型是否匹配、文档切分是否合理、提示词是否过宽、上下文是否过长。很多时候不是模型不行，而是检索链路和知识治理出了问题。要想提升质量，通常要从文档清洗、切分策略、embedding 选择、召回排序和提示模板几个维度一起优化。
10. 面试中的答题思路总结
在大厂 Java 面试里，面试官通常希望你不仅知道“用什么”，还要说清楚“为什么这么用”“出了问题怎么办”“怎么监控和演进”。回答时最好围绕业务场景展开：先说目标，再说方案，然后说风险和兜底措施。这样更像一个能落地的工程师，而不是只会背名词。
感谢阅读，希望这篇文章能帮助你在 Java 面试中更有思路、更有底气，顺利拿到心仪的 offer！