企业官网建设流程全解析

互联网大厂 Java 面试实录：Spring Boot、Kafka、Redis、K8s、Spring AI 与 RAG 的层层追问

场景：某互联网大厂 Java 岗终面。

面试官风格：严肃、追问到底。

小Y：嘴上很稳，脑子有点飘，但简单题能答对，复杂题开始“艺术性表达”。

第一轮：先看基础功，别一上来就飘

面试官把简历放到桌上，语气很平静。

面试官：先从你熟悉的部分开始。你说你做过电商订单系统，那你先讲讲 Java 8、11、17 这些版本里，哪些特性真的影响了你写业务代码？

小Y：嗯……Java 8 的 Lambda、Stream、Optional 用得最多。11 以后我主要感受是性能更稳、语法更顺手。17 我知道是 LTS，做技术选型的时候更安心。

面试官：还行，至少不是把 Stream 当数据库。那你说说 JVM 里，线上订单接口突然慢了，你会先看什么？

小Y：先看 GC、CPU、线程池、堆内存、锁竞争，还有是不是对象创建太猛。然后结合日志和监控定位。

面试官：这回答像个干过活的人。再往下说，Maven、Gradle 你怎么选？构建失败你怎么排？

小Y：Maven 适合规范化依赖管理，团队协作比较稳；Gradle 更灵活，构建脚本能力更强。排查时我会看依赖冲突、插件版本、仓库网络、profile 配置，还有本地缓存是不是脏了。

面试官：不错。那回到业务。假设这是一个内容社区的帖子详情页，Spring Boot + Spring MVC 你会怎么设计接口？

小Y：Controller 接收请求，Service 处理业务，Repository 或 Mapper 访问数据库。帖子详情可能包含帖子信息、作者、评论数、点赞数、是否关注等，我会把稳定数据和高频聚合数据拆开查，避免一个接口拖慢整页。

面试官：继续。你刚说到数据库，Hibernate、MyBatis、JPA 你在什么场景下会怎么选？

小Y：简单 CRUD、领域模型比较清晰时可以用 JPA 或 Hibernate；复杂 SQL、报表查询、关联多、需要精细调优时我更偏 MyBatis。很多项目里也会混用，核心写业务、复杂查询走 MyBatis。

面试官：最后一个问题。Redis 在帖子详情页里能做什么？别只说缓存。

小Y：可以做热点帖缓存、点赞计数、浏览计数、用户是否点过赞的状态位，还能做分布式锁或者限流。

面试官：这轮还可以，至少知道缓存不是“把东西塞进去就完了”。

第二轮：开始上分布式，别只会说“我用过”

面试官把电脑转向小Y，屏幕上是一个“电商秒杀 + 本地生活优惠券”的混合场景。

面试官：现在进入业务。假设你负责一个本地生活平台的秒杀券发放，流量很高。你会怎么做架构？

小Y：前面用网关和限流，后面服务水平扩展。请求进来先做资格校验、库存预扣、异步下单，热点数据放 Redis，消息用 Kafka 或 RabbitMQ 解耦，避免同步链路太长。

面试官：嗯，方向对。那如果我问你 Spring Cloud、Eureka、Consul、OpenFeign、Resilience4j 这套怎么串，你别只报菜名。

小Y：服务注册发现可以用 Eureka 或 Consul；服务间调用常用 OpenFeign；容错上可以用 Resilience4j 做超时、重试、熔断、限流；配置和健康检查也要配套。整体就是把服务治理能力标准化。

面试官：不错。那消息队列呢？Kafka、RabbitMQ、JMS 你怎么区分？

小Y：Kafka 更适合高吞吐日志、埋点、订单事件流；RabbitMQ 更适合业务异步、灵活路由和可靠投递；JMS 是规范，具体实现看 ActiveMQ 之类。秒杀场景里我会优先考虑 Kafka 或 RabbitMQ，看是偏吞吐还是偏业务路由。

面试官：那如果发券后要保证“不能超发，也不能重复发”，你怎么设计幂等和一致性？

小Y：用户请求需要唯一业务幂等键，比如用户ID+券ID；数据库层加唯一索引；消息消费端也要做去重。库存可以采用 Redis 预扣，再通过异步消息落库，失败要能补偿。

面试官：说到补偿，你对分布式事务是怎么想的？别一上来就说“用 Seata”。

小Y：我会先看业务能不能接受最终一致性。秒杀这种高并发场景，尽量避免强事务，更多用本地事务 + 事件消息 + 补偿机制。如果真有资金类强一致要求，再考虑更严格的方案。

面试官：可以。那监控呢？线上发券慢了，你怎么知道慢在哪？

小Y：Micrometer 接 Prometheus，Grafana 看指标；日志进 ELK；链路追踪用 Jaeger 或 Zipkin；如果有外部服务调用，可以看调用耗时、错误率、P99 延迟。

面试官：再加一道。你会怎么把系统部署到 Kubernetes？

小Y：容器化后用 Docker 打包，K8s 负责部署、伸缩、服务发现和滚动更新。应用健康检查、资源限制、配置注入、HPA 都要做好。

面试官：这轮比刚才更像个工程师了。

第三轮：AI 上场，开始看你的系统设计和边界感

面试官切到另一个场景：企业协同 + AI 知识库问答。

面试官：最后一轮。现在公司要做一个企业文档问答系统，给销售、客服、法务都能用。你会怎么把 Spring AI、RAG、向量数据库这些东西串起来？

小Y：先把企业文档做加载和切分，再做 embedding 向量化，存到向量数据库里。用户提问时，先做语义检索找到相关片段，再把检索结果和问题一起喂给大模型生成回答。这样比纯大模型更贴合企业知识。

面试官：那你说说为什么不能直接让大模型回答，非要 RAG？

小Y：因为大模型可能会幻觉，尤其企业内部知识更新快、权限复杂、文档很长。RAG 可以把答案约束在可检索的事实范围内，还能降低错误回答概率。

面试官：很好。那如果要做“客服助手 + 工单自动流转”，Agent 该怎么理解？

小Y：Agent 就是让模型不仅能回答，还能在规则约束下调用工具，比如查订单、查物流、创建工单、发消息。它更像有执行能力的智能代理，不只是聊天。

面试官：那工具调用怎么规范化？你说说 MCP、A2A、工具执行框架这些概念。

小Y：MCP 可以理解为一种标准化的工具和上下文接入方式，让模型更统一地访问外部能力；A2A 更偏多个 Agent 之间协作；工具执行框架则负责把模型的意图安全、可控地映射到实际调用上。

面试官：再深入一点。如果客服助手要连订单系统、知识库、IM、审批流，你怎么避免模型“乱调用”？

小Y：要做权限控制、白名单、参数校验、审计日志和人工兜底。模型只能在允许的工具集合里选择，敏感操作要二次确认。不能让模型一句“我觉得可以”就直接扣钱。

面试官：很好。那你把这个系统落到技术实现上，Spring Boot、WebFlux、WebSocket、gRPC、Redis、Elasticsearch 你怎么组合？

小Y：API 层用 Spring Boot 提供基础服务，实时推送可以用 WebSocket，内部高性能调用可用 gRPC。会话内存和热点上下文放 Redis，全文检索和审计搜索可用 Elasticsearch。若要高并发异步处理，部分链路可用 WebFlux。

面试官：最后一个问题。你觉得这个 AI 项目的难点是什么？

小Y：不是“接个模型 API”那么简单，难点在数据治理、权限隔离、知识更新、幻觉控制、工具安全、评估体系和成本控制。

面试官：嗯，今天就到这。你先回去等通知吧。

小Y：好的老师，我回去先把“我会”两个字，改成“我真的会”。

最后：把每道题的答案讲透

下面把三轮问题拆开讲，按“业务场景 + 技术点”的方式整理，方便直接学习和复盘。

第一轮答案解析：基础能力是否扎实

1. Java 8 / 11 / 17 哪些特性会影响业务开发

在互联网业务里，版本特性不只是“语法好不好看”，还会影响代码质量、运行稳定性和团队效率。

• Java 8：Lambda、Stream、Optional、CompletableFuture 是最常用的能力。
• Java 11：更好的性能表现，HTTP Client 等新特性逐步可用，适合中长期 LTS 选型。
• Java 17：现代 Java 的主流 LTS 之一，适合新项目，安全性和长期维护更好。

业务上最常见的收益：

• 集合处理更简洁，减少样板代码。
• 异步编排更自然，适合调用多个下游接口。
• 版本统一后，运维和依赖治理更简单。

2. JVM 排查线上慢请求看什么

线上接口变慢，不要只盯着代码，要先从 JVM 和系统层面看整体。

重点排查项：

• GC 是否频繁，是否有长时间 Stop-The-World。
• CPU 是否打满，是否存在热点循环或序列化开销。
• 线程池是否耗尽，是否发生任务堆积。
• 锁竞争是否严重，是否有 synchronized、ReentrantLock 或数据库锁等待。
• 堆内存是否异常增长，是否存在内存泄漏。

常见思路是：先看监控，再看日志，再做线程 dump 和 heap dump，最后结合业务代码定位。

3. Maven 和 Gradle 怎么选

• Maven 更适合规范、稳定、团队协作强的项目。
• Gradle 更灵活，适合复杂构建和性能更敏感的场景。

排查构建失败时常见检查项：

• 依赖冲突和版本树。
• 插件版本不兼容。
• 本地缓存损坏。
• 私服或网络问题。
• profile 激活是否正确。

4. Spring Boot + Spring MVC 怎么做帖子详情页

内容社区的帖子详情页，一般不是单表查询，而是“聚合页”。

建议拆分思路：

• Controller 负责接收请求和参数校验。
• Service 负责整合帖子、作者、评论、点赞、关注等数据。
• DB 层避免一次大联表把系统拖慢。
• 热点数据通过缓存或预聚合提升性能。

关键是把“读模型”设计好，别把所有逻辑压在一个 SQL 里。

5. Hibernate / MyBatis / JPA 怎么选

• JPA / Hibernate：适合标准 CRUD、领域模型明显的场景。
• MyBatis：适合复杂 SQL、性能优化、报表查询、可控性高的场景。

大厂常见做法是混用：

• 核心业务写领域模型或 ORM。
• 复杂查询、批量处理、统计报表走 MyBatis。

6. Redis 在详情页的作用

Redis 不只是“缓存对象”。在内容社区场景里常见用途：

• 热点帖子缓存，降低数据库压力。
• 点赞数、浏览数等计数器。
• 用户是否点赞的状态位。
• 分布式锁、限流、去重。

核心原则：把高频、可容忍短暂不一致的数据放进去。

第二轮答案解析：分布式与高并发

7. 秒杀券发放怎么设计

秒杀类业务要处理三个问题：高并发、库存正确性、用户体验。

常见方案：

• 网关做流量入口控制。
• Redis 做库存预热和预扣。
• 消息队列异步下单，削峰填谷。
• 数据库最终落库保证可追溯。

这类系统最怕同步链路太长，所以通常是“前台快拦截，后台慢处理”。

8. Spring Cloud / Eureka / Consul / Feign / Resilience4j 怎么配合

服务治理的核心就是四件事：

• 服务注册发现：Eureka 或 Consul。
• 服务调用：OpenFeign。
• 容错：Resilience4j 处理超时、重试、熔断、限流。
• 配置与健康检查：保证实例可观测。

实际项目里，关键不是“用了哪些组件”，而是“每个组件解决什么问题”。

9. Kafka / RabbitMQ / JMS 的区别

• Kafka：高吞吐，适合事件流、日志、埋点、订单流水。
• RabbitMQ：路由灵活，适合业务异步、任务分发。
• JMS：消息规范，不是具体产品。

如果是秒杀场景，通常优先考虑 Kafka 或 RabbitMQ，取决于是更重吞吐还是更重投递灵活性。

10. 如何做幂等和一致性

高并发场景里，幂等是刚需。

常见方案：

• 业务幂等键：用户ID + 活动ID + 请求ID。
• 数据库唯一索引兜底。
• 消费端去重表或去重缓存。
• 失败补偿和对账机制。

对于高并发秒杀，一般优先最终一致性，而不是强事务硬扛。

11. 怎么监控和排障

推荐的监控链路：

• Micrometer 采集指标。
• Prometheus 拉取指标。
• Grafana 展示图表。
• ELK 收集日志。
• Jaeger / Zipkin 做链路追踪。

排障时重点关注：

• P95 / P99 延迟。
• 错误率。
• 消息堆积。
• 下游依赖耗时。

12. Kubernetes 部署要关注什么

K8s 的价值是把应用交给平台调度。

要关注：

• Docker 镜像瘦身。
• 健康检查 readiness/liveness。
• 资源 requests/limits。
• 配置注入和密钥管理。
• HPA 自动扩缩容。
• 滚动更新和回滚策略。

第三轮答案解析：AI、RAG 与 Agent

13. 为什么企业知识问答要用 RAG

纯大模型的问题是：它不一定知道你公司的最新制度、合同、产品说明、故障处理手册。

RAG 的价值：

• 先检索再生成，答案更贴近事实。
• 可以接入内部知识库。
• 能降低幻觉概率。
• 可以做权限隔离和审计。

简单说，RAG 让大模型“先看资料再回答”。

14. 向量化、语义检索、向量数据库怎么理解

• 文档先切分成片段。
• 每个片段通过 embedding 模型转成向量。
• 用户问题也转成向量。
• 通过相似度搜索找最相关的片段。
• 最后把片段交给模型生成答案。

向量数据库可选 Milvus、Chroma、Redis 等，关键是支持向量检索和过滤。

15. Agent 是什么

Agent 不是单纯聊天，它能“思考 + 调用工具 + 执行动作”。

比如客服助手可以：

• 查询订单状态。
• 查物流。
• 创建工单。
• 给用户发通知。

但要注意：Agent 必须有边界，不能让模型自由发挥到“误扣款”。

16. MCP、A2A、工具执行框架怎么理解

• MCP：更偏标准化的工具和上下文接入方式。
• A2A：多个 Agent 之间的协作通信。
• 工具执行框架：把模型意图变成真实、安全、可审计的动作。

本质上都是为“模型如何可靠使用外部能力”服务。

17. 如何控制幻觉和风险

企业 AI 系统最怕“说得很对，实际是错的”。

防护手段：

• 让模型基于检索结果回答。
• 敏感操作增加人工确认。
• 工具白名单与参数校验。
• 审计日志全量记录。
• 输出置信度不足时拒答或转人工。

18. Spring Boot、WebFlux、WebSocket、gRPC、Redis、Elasticsearch 怎么组合

一个常见企业 AI 客服平台可以这么搭：

• Spring Boot：业务 API 和管理后台。
• WebSocket：实时推送回答和状态。
• gRPC：内部高性能调用。
• Redis：会话记忆、热点上下文、限流。
• Elasticsearch：全文搜索、审计检索。
• WebFlux：用于高并发异步流式接口。

19. AI 项目的真正难点是什么

不是接模型接口，而是：

• 数据治理。
• 权限隔离。
• 知识更新。
• 幻觉控制。
• 工具安全。
• 评估体系。
• 成本控制。

这也是为什么很多 AI 项目看起来“能跑”，但真正上线后很难稳定服务业务。

复盘建议

如果你准备互联网大厂 Java 面试，建议按这条线复习：

• Java 基础与 JVM。
• Spring Boot / Spring MVC / ORM。
• Redis、MQ、分布式治理、监控。
• K8s、CI/CD、可观测性。
• 最后补 AI/RAG/Agent 这类新方向。

真正能打动面试官的，不是“我会很多框架”，而是“我能把业务问题和技术方案讲清楚”。