Spring Boot Kafka Redis OAuth2 Kubernetes互联网大厂 Java 面试实战对话场景互联网大厂面试现场面试官严肃克制候选人是人称“水货程序员燕双非”的求职者。第一轮本地生活服务下单链路面试官你做过本地生活服务吗比如用户在 App 上下单团购券服务端用 Spring Boot 怎么设计一个核心下单接口燕双非做过一点。一般就是 Controller 接收参数Service 里做校验然后调用 MyBatis 或 JPA 落库最后返回成功。简单场景的话我会把订单表、优惠券表、支付表拆开。面试官思路还可以。那如果用户疯狂点按钮重复下单怎么办燕双非嗯……可以加个 Redis 去重或者前端按钮点一次后置灰。后端再用订单号幂等避免重复写库。面试官这个方向对。再深入一点Redis 幂等和数据库唯一索引一起用你会怎么配合燕双非先在 Redis 里放一个请求标识短时间内重复请求直接拦掉数据库订单号上加唯一索引防止极端情况下重复插入。这样双保险。面试官不错。那订单创建后要发 Kafka 消息给核销、短信、营销系统你怎么保证消息不丢燕双非这个……可以先落库再发消息或者用事务消息。Kafka 的话我知道有分区和消费者组消息丢失要看 ack 和重试配置。面试官回答得有点飘但大方向没错。继续看下一轮。第二轮支付、风控与权限面试官支付链路里服务之间通常会用什么方式通信为什么有些团队会选 gRPC而不是纯 REST燕双非REST 简单直观gRPC 性能更好适合内部服务之间高频调用。它基于 Protobuf体积小兼容性也还行。面试官可以。那如果支付成功后需要同步通知商家系统和风控系统且其中一个系统挂了你怎么做降级燕双非可以用 Resilience4j 做熔断和限流超时了就走兜底逻辑。比如商家通知失败先记一条待补偿任务后面定时重试。面试官那风控系统怎么识别异常支付你会关注哪些维度燕双非会看设备、IP、用户历史行为、地理位置、支付频率还有订单金额是否异常。然后可以把规则引擎和机器学习模型结合。面试官如果接口需要 OAuth2 登录态和 JWT 鉴权你怎么设计 Spring Security 里的权限控制燕双非登录后签发 JWT把用户身份和角色放进去。Spring Security 通过过滤器解析 token再按接口路径和角色做授权。比如商家接口和用户接口分开控制。面试官不错至少这个说清楚了。那 JWT 放什么字段什么不能放燕双非一般放 userId、角色、过期时间、租户信息。不能放敏感信息比如密码、身份证明文因为 token 本身可被解码。面试官很好开始像样了。第三轮云原生、观测与 AI 能力面试官现在公司准备把这套本地生活系统上 Kubernetes。你怎么处理 Spring Boot 的配置、健康检查和弹性伸缩燕双非配置可以放 ConfigMap 和 Secret健康检查用 readinessProbe、livenessProbe。弹性伸缩可以配 HPA根据 CPU 或自定义指标扩容。面试官如果高峰期订单量暴涨怎么观测系统瓶颈燕双非可以接 Prometheus 和 Grafana 看 QPS、延迟、错误率再用 Micrometer 打埋点。链路排查还可以上 Jaeger 或 Zipkin看一次请求经过哪些服务。面试官很好。那如果你要给运营同学做一个“自然语言语义搜索”比如“查最近三天退款率高的门店”怎么结合 AI 做燕双非可以用 Spring AI 接一个 Embedding 模型把门店、订单、退款规则文档向量化存到向量数据库里比如 Milvus。用户提问后先做语义检索再把检索结果交给大模型生成答案。如果是企业文档问答还可以做 RAG避免模型胡说八道。面试官那你说说 Agent 和普通聊天机器人区别是什么燕双非Agent 会自己规划步骤还能调用工具比如查订单、查库存、发工单。普通聊天机器人更多是单轮回答。Agent 还要有会话记忆、工具调用标准化不然上下文容易乱。面试官最后一个问题如果让你设计一个智能客服系统怎么防止 AI 幻觉燕双非这个……主要还是限制它别乱编。比如让它只基于检索到的知识回答答案里加引用来源高风险问题必须转人工同时对提示词做约束减少它自由发挥。面试官嗯今天先到这。你回家等通知吧。面试题详细解析1. Spring Boot 下单接口如何设计在本地生活服务中下单接口的核心目标是保证高并发下的正确性和用户体验。常见设计是 Controller 负责参数接收Service 负责业务校验Repository/Mapper 负责数据持久化。推荐对订单号、请求幂等键建立唯一约束防止重复提交。结合业务场景用户可能连续点击“立即购买”因此可以用 Redis 存储请求标识设置短 TTL 做快速拦截数据库层再通过唯一索引兜底。这样即使应用重启或缓存失效也能通过数据库保证最终正确性。2. Kafka 消息如何保证不丢在订单创建后常常需要把事件发送到核销、短信、营销等下游系统。最稳妥的方式是使用本地事务 消息表或事务消息方案先将业务数据与待发送消息写入同一个事务提交后由后台任务补偿发送。在 Kafka 中还要关注生产者的 ack 策略、重试次数、幂等生产者、消费者手动提交 offset 等细节。业务上要区分“至少一次”和“恰好一次”的语义要求很多场景其实接受最终一致性。3. gRPC 为什么适合内部服务通信gRPC 基于 HTTP/2 和 Protobuf适合服务间高频调用尤其是内部微服务之间。相比 JSON REST它的序列化体积更小、性能更高、接口契约更清晰支持流式调用适合支付、风控、库存等低延迟场景。在大厂系统中如果接口需要强契约和跨语言支持gRPC 往往比手写 REST 更稳定但对外开放接口仍然经常保留 REST以便于第三方接入和排查。4. Resilience4j 如何做熔断降级支付通知、商家回调、风控查询这类依赖外部系统的调用很容易因为下游慢而拖垮整体链路。Resilience4j 可以提供熔断、限流、超时、重试等能力当错误率或延迟达到阈值时自动熔断直接返回兜底结果。业务上常见做法是支付主链路优先保证成功非核心链路如短信、画像同步、埋点上报可异步化失败后进入补偿队列。这样能避免“一个外部系统故障拖垮整个平台”。5. Spring Security OAuth2 JWT 怎么组合OAuth2 负责授权流程JWT 负责令牌承载Spring Security 负责认证与授权落地。用户登录后认证服务签发 JWT前端后续请求携带 token后端过滤器解析 token构建 Authentication再基于角色、权限或租户信息进行访问控制。注意 JWT 不适合放敏感明文信息且要设置过期时间、刷新机制和黑名单策略。对于高安全场景常结合 Keycloak、Spring Security 或网关统一做认证。6. Kubernetes 上如何做健康检查与弹性伸缩在云原生部署中readinessProbe 用于判断实例是否可以接流量livenessProbe 用于判断进程是否需要重启。配置好这两个探针可以有效避免未就绪实例接单或僵死进程长期占用资源。弹性伸缩通常通过 HPA 根据 CPU、内存或自定义指标扩缩容。对于订单、支付等高峰波动明显的业务可结合 Prometheus 指标与业务 QPS 做更精准的伸缩策略。7. Prometheus、Grafana、Jaeger 怎么帮助排障Prometheus 负责采集指标Grafana 负责可视化。通过 QPS、P95/P99 延迟、错误率、线程池队列长度等指标可以快速发现瓶颈。Jaeger 或 Zipkin 则用于链路追踪能定位请求在多个微服务之间的耗时分布。在本地生活服务中若用户投诉“下单很慢”可以先看指标发现是否是支付服务、库存服务或风控服务延迟升高再通过链路追踪确认到底是哪一跳出了问题。8. Spring AI RAG 向量数据库怎么做企业问答企业文档问答的关键不在于“大模型会不会说”而在于“答案是否来自可信知识”。RAG 的核心流程是文档加载、切分、向量化、存储到向量数据库、检索相关片段、再把片段喂给大模型生成回答。Spring AI 可以帮助整合 Embedding 模型、工具调用和对话上下文。对于“查最近三天退款率高的门店”这种问题系统可以先检索相关业务规则和数据说明再结合结构化数据生成可解释答案。这样能显著降低 AI 幻觉。9. Agent 和普通聊天机器人有什么区别普通聊天机器人主要是输入一句、输出一句Agent 则会根据目标自动拆解任务必要时调用外部工具比如查订单、查库存、发工单、调用审批流。它强调的是规划能力、工具执行能力和多步推理能力。在智能客服系统里Agent 可以先判断问题类型再决定调用搜索、知识库、订单系统还是人工转接。为了稳定通常需要工具调用标准化、会话记忆管理和权限边界控制。10. 如何降低 AI 幻觉最有效的思路是让模型少编、让知识可追溯、让高风险问题可兜底。具体做法包括限定回答范围、采用 RAG、回答时附来源、增加规则校验、对高风险问题转人工、对关键结论进行二次验证。例如智能客服回答退款政策时不应让模型凭空发挥而应该仅基于知识库中的政策条款生成答案如果知识库没有命中就明确提示“需要人工核实”。结语感谢阅读希望这篇互联网大厂 Java 面试实战文章能够帮助大家在技术面试中更从容地表达思路、梳理架构并真正把知识转化为业务能力。祝大家面试顺利拿到理想 offer。