企业官网建设流程全解析

互联网大厂 Java 面试实录：Spring Boot、JVM、MyBatis、Redis、Kafka、Spring Security 到 AI/RAG

故事背景

面试官老周，表情严肃，讲话像在开生产事故复盘会。

候选人小Y，外号“水货程序员”，特点是：

• 简单题能答上来，而且答对了还会抖机灵
• 复杂题开始“先说结论”：我感觉、应该、差不多、可能
• 一旦被追问，就会进入“接口设计很灵活，具体看业务”的安全区

今天的场景是：一家互联网大厂的 Java 技术面，业务方向是内容社区 + 电商 + AI 智能客服。系统要支持：

• 用户发帖、评论、点赞、收藏
• 商品下单、支付回调、优惠券核销
• 消息通知、实时弹幕、异步审核
• 企业知识库问答、智能客服、RAG 检索增强生成

第一轮：基础功底和工程化能力

1）面试官：你先说说，Spring Boot 和 Spring MVC 的关系是什么？

小Y：Spring Boot 是“开箱即用”的脚手架，负责把 Spring 生态快速搭起来；Spring MVC 主要负责 Web 请求处理，比如DispatcherServlet、参数绑定、视图渲染这些。简单说，Boot 负责“启动快、配置少”，MVC 负责“接请求、干活”。

面试官：这个回答可以，至少不是把两个框架混成一个。

2）面试官：那你项目里为什么选 Maven，不选 Ant？Gradle 呢？

小Y：Ant 偏老，构建过程要手写很多步骤；Maven 是约定大于配置，依赖管理和生命周期都比较清晰；Gradle 更灵活，性能也不错，但团队如果更看重统一规范，Maven 会更稳。大厂里常见的做法是：老项目 Maven，新项目看团队熟悉度，也可能用 Gradle。

面试官：不错，知道是“团队协作成本”的问题，不只是工具喜好。

3）面试官：JVM 里，线上接口偶发变慢，你会先看什么？

小Y：我会先看是不是 GC 频繁、CPU 飙高、线程池打满、还是锁竞争严重。通常先从 GC 日志、线程 dump、jstat、jstack、top这些入口定位。比如 Full GC 频繁，可能是堆太小、对象晋升太快、或者缓存没控制住。

面试官：可以，至少知道先从“现象->证据->定位”入手。

4）面试官：那你说说 Java 8、11、17 有什么你在项目里最常用的差异？

小Y：Java 8 我最常用的是 Lambda、Stream、Optional、CompletableFuture。Java 11 我会关注新的 HTTP Client、字符串方法增强。Java 17 属于更现代的 LTS，很多公司会逐步升级，比较关注它的性能、语法演进和长期支持。

面试官：回答可以，说明你不是只会背“版本号”。

第二轮：数据访问、缓存、消息与安全

1）面试官：现在我们做内容社区，帖子详情页很热。你会怎么设计 Redis 缓存？

小Y：我会把热点帖子详情放 Redis，设置合理 TTL，防止永久热点。查询时先查缓存，miss 再查数据库回填。为了避免缓存击穿，可以加互斥锁或者逻辑过期；为了避免雪崩，TTL 加随机值；如果是热门排行榜，还可以用 Sorted Set 做实时排名。

面试官：很好，三个经典问题都答到了。

2）面试官：如果你用 MyBatis 和 JPA，你怎么选？

小Y：如果业务 SQL 比较复杂、查询条件变化多、需要精确控制 SQL，我更倾向 MyBatis；如果是简单 CRUD、领域模型比较清晰，JPA 能减少样板代码。很多团队会混用：写业务核心查询用 MyBatis，简单管理后台用 JPA 或 Spring Data。

面试官：这就对了，框架不是宗教。

3）面试官：商品下单后要发 Kafka 消息通知库存、积分、风控，你会怎么保证一致性？

小Y：我一般会先用本地事务保证订单落库成功，再通过消息队列做异步解耦。为了避免“订单成功但消息没发出去”，可以用事务消息、Outbox 表、或者定时补偿任务。消费者侧要做幂等，比如按业务单号去重。Kafka 适合高吞吐场景，RabbitMQ 更偏灵活路由，选型看业务侧重点。

面试官：不错，已经不是“发条消息就完了”。

4）面试官：安全怎么做？比如用户登录、接口鉴权、第三方接入。

小Y：内部系统常见是 Spring Security 做统一认证授权，外部接入可用 OAuth2 / JWT。JWT 适合无状态分布式场景，但要注意过期、刷新、注销问题。像企业统一身份认证，还可以接 Keycloak。敏感加解密如果涉及证书和算法实现，可能会碰到 Bouncy Castle。

面试官：回答不错，能区分“认证、授权、令牌、统一身份”。

第三轮：微服务、AI、可观测性与复杂业务联动

1）面试官：现在把内容社区升级成“AI 智能客服 + 企业知识库问答”，你怎么做 RAG？

小Y：我会先把企业文档做切分、清洗、向量化，存到向量数据库里，比如 Milvus、Chroma 或 Redis 向量能力。用户提问时，先做语义检索召回相关片段，再把上下文和问题一起拼给大模型生成答案。这样比纯大模型更适合企业文档问答，也能降低幻觉。

面试官：这个方向对了，说明你知道 RAG 解决的不是“生成”，而是“先找再答”。

2）面试官：那如果检索结果不准，或者模型开始胡说八道，你怎么处理？

小Y：我会从三层处理。第一层是检索层，优化切分策略、embedding 模型和召回 TopK；第二层是提示词层，限制模型只能基于检索内容回答；第三层是输出层，加置信度判断和拒答策略。对于企业客服，还要把高频问题做 FAQ 兜底，避免 AI 幻觉影响业务。

面试官：这次回答比很多“只会调 API”的人强。

3）面试官：微服务里，订单服务、库存服务、支付服务怎么做治理？

小Y：我会考虑注册发现、配置管理、限流熔断、链路追踪。老一点的方案会用 Eureka、Zuul，或者 Consul；现在更多会基于 Spring Cloud 体系和 Resilience4j 做熔断限流。调用链上可以接 Micrometer + Prometheus + Grafana，再用 Jaeger 或 Zipkin 做链路追踪，方便定位慢接口和跨服务延迟。

面试官：可以，知道“业务跑得动”之外还要“出问题能看见”。

4）面试官：最后一个问题，如果让你用 Java 体系搭一个“在线教育直播间 + 实时互动 + 课后知识问答”的平台，你会怎么串起来？

小Y：我大概会这么拆：

• 前台用 Spring Boot + WebSocket 做实时互动，必要时接 WebFlux 提升高并发连接能力
• 课程订单和支付用 Spring MVC + MyBatis/JPA 做核心交易链路
• 异步消息用 Kafka 做弹幕、通知、审核任务
• Redis 做会话、热点课件缓存和限流
• 用 Prometheus、Grafana、ELK 做监控和日志
• 课后问答用 Spring AI + RAG，把讲义、FAQ、课件向量化后检索回答
• 如果是企业级场景，还会加 SSO、OAuth2、JWT、权限体系和审计日志

面试官：整体思路是对的，说明你不是只会单点技术，而是会按业务拆系统。

面试官收尾

面试官：基础还行，方向也没跑偏，不过有些深入细节还不够扎实。今天先到这，你回去等通知吧。

小Y：好的周老师，我回去再把“会一点”和“会很多”之间的那条线补一补。

面试官：嗯，至少态度是对的。

详细答案解析：把每个问题讲透

1. Spring Boot、Spring MVC 的业务关系

Spring Boot 是应用启动和自动配置的入口，解决的是“怎么快速把项目跑起来”。Spring MVC 负责 Web 层请求处理，解决的是“请求来了怎么分发、怎么参数绑定、怎么返回结果”。

在电商、内容社区、SaaS 后台里，通常是：

• Spring Boot 负责装配依赖、自动配置数据源、Web 容器、日志、监控
• Spring MVC 负责 Controller、参数校验、异常处理、返回 JSON

小白记忆法：Boot 是“搭台子”，MVC 是“唱戏”。

2. Maven、Gradle、Ant 的选择

• Ant：更像“手工搭积木”，灵活但配置碎，适合早期老项目
• Maven：强约定、依赖传递、生命周期完整，适合大团队统一管理
• Gradle：DSL 更灵活，构建性能好，适合更复杂的工程组织

企业里最重要的不是“谁更潮”，而是：

• 团队是否统一
• CI/CD 是否稳定
• 多模块工程是否易维护
• 依赖冲突是否容易治理

3. JVM 性能排查思路

线上变慢，优先排查四类：

• GC：看是否频繁 Full GC、停顿时间长
• CPU：看是否有热点计算、死循环、序列化/反序列化过重
• 线程：看线程池是否满、是否有死锁、阻塞队列是否堆积
• 锁：看 synchronized、ReentrantLock、数据库锁竞争

常用手段：

• jstack看线程堆栈
• jstat看 GC 状态
• jmap看堆内存对象分布
• top/vmstat看系统负载

4. Java 8/11/17 的实际意义

• Java 8：Lambda、Stream、Optional、时间 API，很多老系统仍是主力
• Java 11：更成熟的 LTS，常用于企业升级过渡
• Java 17：更现代的 LTS，适合新项目和逐步升级

面试里真正要表达的是：你能理解版本演进带来的代码风格、运行时性能和长期维护成本变化。

5. Redis 缓存设计

内容社区里最常见的缓存对象：

• 帖子详情
• 用户主页摘要
• 热门榜单
• 登录态、验证码、限流计数器

常见问题和方案：

• 缓存击穿：热点 key 失效，用互斥锁或逻辑过期
• 缓存雪崩：TTL 加随机值，分散过期时间
• 缓存穿透：空值缓存、布隆过滤器

如果是排行榜、点赞数、热度值，Redis 的 Sorted Set 很常见。

6. MyBatis 和 JPA 的取舍

• MyBatis：适合复杂 SQL、报表、动态查询、强控制场景
• JPA：适合标准 CRUD、领域对象驱动开发，减少模板代码

在真实项目中，经常不是“二选一”，而是“按场景共存”。

7. Kafka 消息一致性

订单系统里，最怕的是“数据库写成功了，消息没发出去”或者“消息重复消费”。

常用做法：

• 本地事务 + 消息表 Outbox
• 事务消息
• 消费者幂等设计
• 重试 + 死信队列 + 补偿任务

Kafka 更适合高吞吐日志流、业务事件流；RabbitMQ 更适合复杂路由、灵活投递；ActiveMQ/JMS 偏传统企业集成。

8. Spring Security、JWT、OAuth2、Keycloak

• Spring Security：Java 生态里最常见的认证授权框架
• JWT：无状态令牌，适合分布式服务
• OAuth2：第三方授权标准协议
• Keycloak：统一身份认证与 SSO 平台

典型场景：

• App 登录后拿 JWT 调接口
• 企业内部用 Keycloak 做统一登录
• 不同服务根据权限控制接口访问

9. RAG 与 AI 智能客服

RAG 的核心不是“让模型更聪明”，而是“让模型先看到正确材料”。

流程通常是：

1. 文档加载：导入 PDF、Word、网页、FAQ
2. 切分：按段落、标题、语义切块
3. 向量化：调用 Embedding 模型生成向量
4. 存储：放到 Milvus、Chroma 或 Redis 向量库
5. 检索：通过语义搜索找相关片段
6. 生成：把检索结果与问题一起交给大模型回答

在企业文档问答、智能客服、知识库搜索中，这套方案非常常见。

10. AI 幻觉的处理

模型会“编”，所以必须加约束：

• 检索增强，减少凭空生成
• 提示词限定，只能基于知识库回答
• 置信度阈值，不足则拒答或转人工
• FAQ 与规则引擎兜底

这就是企业 AI 和“聊天玩具”的最大区别。

11. 微服务治理与可观测性

微服务不是拆完就结束了，真正难的是治理。

常见能力：

• 注册发现：Eureka、Consul
• 网关：Zuul 或现代网关方案
• 容错：Resilience4j
• 指标：Micrometer + Prometheus
• 可视化：Grafana
• 日志：ELK Stack
• 链路追踪：Jaeger、Zipkin

如果没有这些，系统一旦慢了，只能靠“感觉排查”。

12. WebSocket 和 WebFlux 的适用场景

• WebSocket：适合实时互动、弹幕、在线客服、协作编辑
• WebFlux：适合高并发、非阻塞 I/O 场景，比如大量长连接、实时通知

在线教育直播间、游戏大厅、虚拟互动空间，都可能用到这两类能力。

13. 一个完整业务系统的组合思路

比如“在线教育 + AI 问答”平台，可以这样组合：

• 登录鉴权：Spring Security + JWT
• 核心业务：Spring Boot + Spring MVC
• 实时互动：WebSocket
• 异步解耦：Kafka
• 缓存：Redis
• 数据持久化：MyBatis / JPA + Flyway / Liquibase
• 监控：Micrometer + Prometheus + Grafana
• AI 问答：Spring AI + RAG + 向量数据库

这类题面试官真正想看的是：你是否能把技术栈和业务场景串起来，而不是单点背诵。

结语

如果把这场面试看成一次实战训练，最重要的不是“背了多少框架名”，而是：

• 能不能把业务说清楚
• 能不能把技术选型说清楚
• 能不能把问题定位思路说清楚

小Y虽然有点“水”，但至少每轮都在进步。真正的大厂面试也是这样：先看基础，再看思路，最后看你能不能把系统讲成一张完整的图。