互联网大厂 Java 面试实录：Spring Boot、MyBatis、Kafka、Redis、Spring Cloud、JWT、Kubernetes 的三轮追问-平芜编程栈

互联网大厂 Java 面试实录：Spring Boot、MyBatis、Kafka、Redis、Spring Cloud、JWT、Kubernetes 的三轮追问

场景：互联网大厂 Java 求职面试，业务方向为企业协同与 SaaS + 大数据与 AI 服务，面试官严肃，候选人是搞笑的水货程序员燕双非。

面试官：今天聊一个 SaaS 平台的核心后端，你先说说你在 Java 8/11/17 里，平时最常用的是哪个版本？为什么？

燕双非：我最常用的是 8，因为……大家都在用，17 也挺好，LTS 吗，生命周期长，面试时说出来显得很稳。

面试官：那你说得不算差。Java 17 除了语法层面，还有哪些你会关注的点？

燕双非：嗯……比如 GC、性能、还有模块化……再就是一些更现代的语法糖，能少写点代码。

面试官：可以，至少方向是对的。那我们进入业务场景。

第一轮：SaaS 订单与用户体系

问题 1：如果你负责一个企业协同 SaaS 系统的用户注册接口，Spring Boot 里你会怎么组织 Controller、Service、DAO？

问题 2：数据库层你会优先用 MyBatis 还是 JPA？为什么？如果用户注册要写入多张表，你怎么处理事务？

问题 3：为了保证注册接口高并发下不把数据库打爆，你会怎么做限流、缓存和连接池优化？

问题 4：如果要把“注册成功欢迎消息”异步发送到消息队列，你会选 Kafka 还是 RabbitMQ？为什么？

燕双非：Controller 接收参数，Service 做业务，DAO 负责查库，这个比较经典。MyBatis 和 JPA……我都用过一点点，MyBatis 更灵活，JPA 更省事。事务的话就加个 @Transactional，基本稳了。限流可以用 Redis，缓存一些热点数据，连接池我会调大一点，别让它太容易满。消息队列嘛，Kafka 听起来更大厂，吞吐高，欢迎消息这种异步场景可以上它。

面试官：基础结构清楚，选型也不算离谱。你至少知道该先保住主链路。再往下问。

第二轮：认证、风控与服务治理

问题 1：企业 SaaS 有多租户隔离需求，登录后你会如何设计 JWT + Spring Security 的认证与授权？

问题 2：如果有一个“审批流服务”需要调用“组织架构服务”，你会怎么做服务发现、容错和降级？

问题 3：如果审批服务需要对外暴露 REST API，你会怎么设计接口版本、错误码和幂等性？

问题 4：当服务调用变多以后，你会如何监控链路、定位慢请求和消息堆积问题？

燕双非：JWT 就是登录后发个 token，前端带着走。Spring Security 主要负责拦一下没登录的人。多租户的话，我觉得可以把租户信息放到 token 里，然后每次查询都带上 tenantId。服务发现嘛，Spring Cloud 或者 Eureka 都能搞，容错就 Resilience4j，失败了就熔断一下。REST API 版本我一般放到 URL 里，比如 /v1/。幂等性就是别重复提交。链路监控的话，Prometheus、Grafana、Zipkin 这些都挺常见，慢请求和消息堆积看一下图就知道了。

面试官：你这个回答有点“会用名词”，但框架思路基本能串起来。尤其是多租户和幂等，知道问题在哪，值得继续往下聊。

第三轮：AI 助手与平台化能力

问题 1：如果 SaaS 平台要加一个“智能客服助手”，你会怎么基于 Spring AI、RAG、向量数据库做企业文档问答？

问题 2：如果要做 Agent，让它能自动查订单、查工单、查知识库，你会怎么设计工具调用和会话记忆？

问题 3：面对 AI 幻觉，你怎么在业务上控制风险，保证回答尽量可靠？

问题 4：如果这个系统要部署到 Kubernetes，并要求支持灰度发布、弹性扩缩容，你会怎么配合 CI/CD 做交付？

燕双非：智能客服助手我会先把公司文档、FAQ、工单知识这些做文档加载，然后切分、向量化，放到 Milvus 或 Redis 这种向量库里。用户提问时先做语义检索，再把相关内容拼到提示词里，让模型基于资料回答，这就是 RAG。Agent 的话，可以给它查订单、查工单这些工具，带会话记忆，避免每次都像失忆一样重新问。AI 幻觉嘛，我觉得要尽量让它“有据可依”，检索结果不够就直接提示不确定，不要瞎编。Kubernetes 部署的话，Docker 打包，CI/CD 自动构建镜像，K8s 做发布和扩缩容，灰度可以分流一部分流量，稳一点。

面试官：这轮回答比前面更像干过事的人了。特别是你知道 RAG 的核心是“先检索再生成”，也知道不能让模型自由发挥太过头。

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

详细解析：每道问题怎么答

一、Spring Boot、MyBatis、Kafka、Redis、事务与连接池

1）Controller / Service / DAO 分层：Controller 负责 HTTP 入参、出参和协议转换；Service 承担业务规则、事务控制和领域编排；DAO/Mapper 负责持久化访问。SaaS 场景里这一层次非常重要，因为后续常会扩展租户隔离、审计日志、审批流等能力，分层清晰有利于演进。

2）MyBatis vs JPA：MyBatis 更适合复杂 SQL、强控制力和性能调优；JPA 更适合领域模型清晰、CRUD 占比较高的场景。企业协同 SaaS 常常存在多表联查、动态查询、报表统计，因此 MyBatis 很常见。若用 JPA，也要理解懒加载、脏检查和级联的影响。

3）事务处理：注册时写用户表、租户表、角色表等，一般在 Service 层加 @Transactional，保证同一事务边界内要么全部成功，要么全部回滚。分布式场景下如果跨服务，就不能只靠本地事务，需要考虑最终一致性、消息事务或 Saga。

4）限流、缓存、连接池：高并发注册接口可以使用 Redis 做验证码、频次限制和热点数据缓存；接入网关做限流；数据库侧通过 HikariCP 调整连接池大小、超时和泄漏检测。核心原则不是“调大就行”，而是根据 CPU、数据库承载和请求模式综合压测。

5）Kafka / RabbitMQ 选型：欢迎消息、用户行为埋点、日志汇聚这类吞吐优先的场景，Kafka 很合适；而订单状态变更、任务路由、需要更灵活路由能力的业务，RabbitMQ 常更合适。面试时最好结合业务说，而不是只说“哪个更火”。

二、JWT、Spring Security、Spring Cloud、Resilience4j、API 设计与监控

1）JWT + Spring Security：登录后签发 JWT，把用户身份、租户 ID、角色、权限摘要等放入 token claims 中。请求进入后由过滤器解析 token，构造 Authentication 放入 SecurityContext。多租户隔离不能只靠前端传参，最好由后端从 token 中取租户上下文并贯穿到查询层。

2）服务发现与容错：Spring Cloud 体系下可以通过注册中心做服务发现，调用方通过服务名访问服务实例。Resilience4j 用于熔断、限流、隔离和重试，避免下游异常级联扩散。这里的重点是“保护系统整体稳定”，不是单个请求一定成功。

3）REST API 设计：版本号可放在 URL 或 Header 中，通常企业内部更常见 URL 方式，便于演进。错误码要体系化，区分参数错误、权限不足、资源不存在、系统异常。幂等性尤其重要，比如创建审批单、提交订单，建议通过业务唯一键、幂等 token 或数据库唯一约束来兜底。

4）监控与链路追踪：Prometheus 负责采集指标，Grafana 负责可视化，Zipkin/Jaeger 负责分布式链路追踪，Micrometer 负责统一指标采集埋点。排查慢请求时，先看接口耗时分布，再看下游依赖耗时，最后定位是 SQL、缓存、网络还是线程池问题。消息堆积则看消费速率、分区、消费者数量和处理耗时。

三、Spring AI、RAG、Agent、向量检索、Kubernetes 与 CI/CD

1）企业文档问答：核心链路通常是“文档加载 → 切分 → 向量化 → 入库 → 语义检索 → 组装上下文 → 大模型生成”。向量数据库可以是 Milvus、Chroma 或 Redis Vector。关键不是把所有文档都塞给模型，而是先检索最相关的片段，再让模型回答，这样能提升准确率并降低成本。

2）Agent 与工具调用：Agent 不是单纯聊天，而是能根据任务决定调用什么工具。比如“查我的审批进度”，它先识别意图，再调用工单系统、订单系统、知识库接口，最后组合结果回答。会话记忆用于保留上下文，工具执行框架则负责标准化输入输出和权限控制。

3）AI 幻觉治理：最常见的做法是加强检索质量、限定回答范围、加入引用来源、对关键结论做规则校验，并在低置信度时明确提示“不确定”。在企业场景里，宁可少答，也不要瞎答。尤其是客服、财务、医疗、合同等领域，幻觉风险必须控制。

4）Kubernetes + CI/CD：Docker 负责镜像构建，Jenkins/GitHub Actions/GitLab CI 负责编译、测试、制品生成和发布；Kubernetes 负责部署、扩缩容、滚动更新和故障自愈。灰度发布通常通过 Service、Ingress、Istio 或流量分配策略实现。对于 SaaS 平台，这种方式能显著降低发布风险。