从Spring Cloud微服务到AI Agent：大厂Java面试连环问（含详细答案解析）

场景：某互联网大厂，主营音视频内容社区 + UGC + AIGC 推荐。小Y来面试 Java 研发，面试官以业务场景为主线，从基础到复杂，连环发问。

第一幕：音视频内容社区的基础服务

业务背景：公司有一个短视频 + 图文内容社区，用户可以上传视频、发表评论、点赞收藏，后续还会接入 AIGC 生成封面、标题推荐等功能。

第一轮提问（3-5 个问题）

问题 1：项目整体技术栈与分层

面试官：

小Y，你先简单介绍一下，你在类似内容社区场景下的项目整体技术栈和分层设计是怎样的？比如：用户服务、内容服务、推荐服务是怎么拆分的，用了哪些框架？

小Y（回答得还不错）：

呃，我们是 Spring Boot，微服务用 Spring Cloud，注册中心是 Eureka。按业务拆成 user-service、content-service、feed-service 之类。网关用 Spring Cloud Gateway，前端 REST 接口用 Spring MVC。持久层用 MyBatis + MySQL，连接池用 HikariCP。构建用 Maven，部署在 Kubernetes 上，CI/CD 用 Jenkins。

面试官（肯定 + 引导）：

嗯，思路还可以，典型的 Spring Cloud 微服务栈。那你们的内容上传这块，涉及大文件上传、转码、存储，你是怎么设计接口和后台任务的？

问题 2：大文件上传与接口设计（Spring MVC / WebFlux）

面试官：

视频上传一般体积大，你会怎么设计上传接口？是用 Spring MVC 还是 Spring WebFlux？如何避免阻塞线程？

小Y（回答一般）：

我们就用 Spring MVC 啊，@PostMapping，然后 MultipartFile 接收文件，上传到对象存储就好了。如果太大就分片呗……WebFlux…我没怎么用，听说是异步的？

面试官（略微失望，但仍温和）：

好，至少知道分片上传。那上传之后你们的转码任务是怎么触发的？是用消息队列吗？

问题 3：转码任务与消息队列（Kafka）

面试官：

视频上传成功后，要进行转码、截图、审核。你会如何用 Kafka 或 RabbitMQ 来设计这条链路？话题（topic）怎么规划？如何保证失败任务能重试？

小Y（开始有点心虚）：

嗯，我们……是有个 video-topic，生产者把消息发进去，然后消费者转码。如果失败就…重新发一条消息？或者写个重试…

面试官（微微皱眉）：

那消息有可能重复消费，你们是如何做到幂等的？消费失败后会不会一直重试把系统打爆？

问题 4：缓存与热点内容（Redis）

面试官：

内容社区里有热门视频、热门评论，你们如何用 Redis 做缓存？会选什么数据结构？如何避免缓存雪崩和缓存击穿？

小Y（略显慌张但还能答）：

Redis 我会用，常用字符串和 hash。热门视频就放在 Redis 里，比如 hot:video:123。雪崩的话可以加随机过期时间；击穿的话可以加互斥锁或者缓存空值……

面试官（点头）：

至少概念还行。那你们如何保证数据库和缓存的一致性？

问题 5：日志与链路追踪（ELK / Zipkin / Jaeger）

面试官：

微服务多了之后，一个请求会从网关到多个服务，比如 user-service、content-service、media-service。你们如何排查线上问题？有用到 ELK、Zipkin 或 Jaeger 吗？调用链怎么打？

小Y（开始迷糊）：

这个……我们日志就是 Logback 打日志，然后用 ELK 收集吧。链路追踪的话，好像是 Spring Cloud Sleuth 自动打 traceId 的，我们就…看一下 Kibana 面板……

面试官（温和收尾）：

好，先到这。你对链路追踪这块还需要系统补一补。

第二幕：AIGC 推荐与智能客服

业务背景：公司准备上 AIGC 功能。比如：

  • 用大模型自动生成视频标题、封面文案（AIGC）
  • 内容推荐使用 RAG（检索增强生成）解释为什么推荐
  • 引入智能客服，回答用户关于账单、会员、权益的问题

第二轮提问（3-5 个问题）

问题 1：AIGC 服务的微服务设计与调用

面试官：

现在我们有一个 ai-service，对接 Spring AI 或 Google A2A。你会如何设计这个服务？例如：如何封装调用大模型的客户端？如何做超时与重试？

小Y（略显勉强）：

Spring AI 我听说过，可以封装成一个 @Service，里面注入一个 client 调用 OpenAI 或内部的大模型。超时就……设置下 HTTP 客户端的超时，还有重试可以用 Resilience4j……

面试官（给予肯定）：

知道用 Resilience4j 还不错。那你会用哪些能力？比如熔断、限流、舱壁隔离？

问题 2：RAG 与向量搜索（Milvus / Redis / Chroma）

面试官：

我们要解释「为什么推荐这个视频给你」，计划用 RAG（检索增强生成），把用户历史行为、视频标签等向量化存到 Milvus 或 Redis。你能说说一个 RAG 流程长什么样吗？你在 Java 里会怎么设计？

小Y（开始打糊涂仗）：

嗯……RAG 就是把文档向量化，然后…检索，再喂给大模型。Java 里可能用…呃…Spring AI 集成向量数据库？然后调用 embedding 模型，存到 Milvus……大概是这样……

面试官（略带严肃）：

那向量化是在线做还是离线批处理？向量库怎么更新？召回策略如何与现有推荐系统结合？

小Y（支支吾吾）：

这个……可以离线也可以在线吧，看场景……我们还没完全搞……

问题 3：Agentic RAG 与工具调用

面试官：

进一步，我们计划让 Agent 具备工具调用能力，比如：

  • 查询用户订单
  • 查询某个视频的详情
  • 调用推荐服务获取候选列表

你能描述一个 Java 后端如何支持 Agent 工具调用的架构吗？包括：工具标准化、会话内存、复杂工作流编排？

小Y（完全进入唬人模式）：

Agent……就是智能代理嘛，它可以自己调用工具。我们可以把每个工具写成一个接口，然后 Agent 调用不同的 REST API。会话内存就……存 Redis 或数据库里？工作流的话……可能用个状态机之类的？

面试官（不太满意）：

你说的是个大概，但缺少工程细节。比如：如何避免无意义反复调用？如何在多工具之间传递上下文？如何记录工具调用日志防止风控问题？

问题 4：AI 幻觉与风控

面试官：

AI 有幻觉问题。比如用户问「我昨天的充值记录」，大模型乱编一个数字，这在金融场景是灾难。你会用什么策略从系统架构层面减轻幻觉？

小Y（继续含糊）：

那就……多做一些检索增强，尽量从数据库查真实数据吧。或者在回答后面加一句「仅供参考」……

面试官（严肃）：

金融场景可不是「仅供参考」能解决的。我们需要严格的工具调用、结果校验和权限控制，这块你要补课。

问题 5：智能客服系统与微服务协同

面试官：

智能客服会牵涉很多后端服务：

  • 订单服务
  • 支付服务
  • 会员服务
  • 风控服务

你会如何设计一层「统一客服后端」来聚合这些微服务？用什么技术？怎么保证 SLA？

小Y（再次模糊）：

统一客服后端……可以搞一个 BFF（Backend For Frontend），用 Spring Boot 写一个聚合层，通过 OpenFeign 调用下游服务。SLA 就……加熔断、限流，还有监控面板……

面试官（点头但不完全满意）：

至少你知道 BFF 和 OpenFeign。更多细节你以后得多思考，比如超时级联、降级策略等等。

第三幕：高并发电商与支付风控

业务背景：公司准备上线电商能力：虚拟道具、会员订阅、广告投放。涉及支付、库存、风控、日志审计以及 Web3.0 / 区块链尝试。

第三轮提问（3-5 个问题）

问题 1：订单系统与分布式事务

面试官：

假设你负责电商订单服务。下单会调用：库存服务、支付服务、优惠券服务。你会如何设计这个分布式事务？例如：采用哪种模式（TCC、SAGA、消息最终一致性）？

小Y（心虚地笑）：

呃……我们以前就用本地事务……分布式的话，我听说可以用消息最终一致性。比如下单成功发消息，库存服务消费扣库存，失败就…回滚？

面试官（追问）：

那如果扣库存失败，你如何保证订单状态正确？消息丢了怎么办？幂等怎么做？

小Y（有点乱）：

可以用事务消息吧，比如 RocketMQ 那种……Kafka 也行？幂等就……根据订单号做幂等 key……

问题 2：支付与安全（JWT / OAuth2 / Spring Security）

面试官：

支付涉及安全。你会如何用 Spring Security + JWT / OAuth2 来设计用户身份认证与权限控制？例如：

  • 用户登录获取 token
  • 后续请求如何校验
  • 如何刷新 token

小Y（还能答一点）：

可以用 Spring Security OAuth2，登录时发一个 JWT，里面有用户 ID 和权限。后续请求带 Authorization: Bearer xxx，Gateway 校验 token。刷新 token 可以用 refresh token 或者缩短有效期……

面试官（点头）：

那你会如何防止 token 被盗用？例如：使用 Keycloak 或统一认证中心时，你会做什么额外安全措施？

小Y（继续模糊）：

可以开启 HTTPS，token 加密……还有…单点登录时可以设置会话过期？

问题 3：风控与实时流处理（Flink / Kafka）

面试官：

我们希望对支付做实时风控。比如：

  • 检测同一 IP 短时间大量支付
  • 检测异常设备指纹
  • 检测高风险国家地区

你会如何用 Kafka + Flink 来做这套实时风控？数据流如何设计？

小Y（瞎画饼）：

Kafka 收集支付日志，Flink 消费做流处理，比如按 IP 做窗口统计。规则满足就发告警或调用风控服务。数据流就是：支付服务 -> Kafka -> Flink -> 风控服务 -> Redis 黑名单……差不多这样……

面试官（稍微认可）：

还行，至少能说出一条简单闭环。不过你得明白状态管理、Checkpoint、Exactly-once 等细节。

问题 4：监控与可观测性（Micrometer / Prometheus / Grafana）

面试官：

电商和支付对 SLA 要求极高。你会如何用 Micrometer + Prometheus + Grafana 做可观测性？比如监控：

  • QPS / 延迟
  • 错误率
  • 外部依赖（支付网关）的健康

小Y（略懂）：

我知道 Micrometer 可以打 metrics，Prometheus 拉数据，Grafana 画面板。我们在代码里打 Timer、Counter，监控接口耗时和错误量。外部依赖可以用 @Timed 和自定义指标……

面试官（鼓励）：

这一块你有实践的话就不错。记得要配合日志和追踪一起看，做全链路可观测。

问题 5：收尾问题——综合能力与成长

面试官：

综合来看，你对 Java 基础、Spring 生态、消息队列、缓存有一定了解，但在分布式事务、RAG / Agent、风控等复杂场景下经验不足。你认为什么是你当前最大的短板？打算怎么补？

小Y（略显尴尬）：

可能……实战经验少吧，很多只是知道名词。接下来我会多做一些 side project，比如用 Spring Cloud 搭一个完整的电商 + 内容系统，再接一个开源大模型做 RAG 和智能客服……

面试官（正式收尾）：

好的，今天就先聊到这里。我们会在一周内给你反馈，回去也可以整理一下今天遇到不会的问题，系统补一下相关知识。

面试题详细答案与场景解析（给小白看的部分）

下面是对上面问答的系统梳理，适合小白学习。按主题分块，结合业务场景和技术点。

一、微服务架构与基础技术栈

场景：音视频内容社区、UGC、AIGC 推荐、电商与支付。

常见技术组合：

  • 语言平台：Java 8/11/17，JVM 基础
  • Web 框架：Spring Boot + Spring MVC / Spring WebFlux
  • 微服务：Spring Cloud（Eureka、Gateway、OpenFeign）、部分场景可用 gRPC
  • 构建与部署：Maven / Gradle，Docker，Kubernetes，CI/CD 用 Jenkins / GitLab CI / GitHub Actions
  • 数据层：MySQL + Redis + Elasticsearch +（必要时）Cassandra
  • ORM 与数据访问：MyBatis、Hibernate / JPA、Spring Data，连接池 HikariCP
  • 消息队列：Kafka / RabbitMQ
  • 监控与可观测：Prometheus + Grafana + ELK +（可选）Zipkin / Jaeger

微服务拆分示例：

  • user-service：用户注册、登录、账号信息
  • content-service：视频、图文内容的 CRUD
  • media-service：大文件上传、转码、存储（对接对象存储，如 S3 / OSS）
  • feed-service：推荐流（关注、热门、AI 推荐）
  • order-service：电商订单
  • payment-service：支付对接
  • ai-service：AIGC、RAG、Agent 工具接口
  • cs-service：智能客服聚合后端（BFF）

网关：

  • api-gateway：基于 Spring Cloud Gateway，负责路由、限流、认证、灰度发布等。

二、大文件上传与异步处理（Spring MVC / WebFlux + Kafka）

业务场景：用户上传短视频，需要：

  1. 接收大文件（分片上传）
  2. 上传完成后触发转码、截图、内容审核
  3. 最终把处理结果（转码 URL、封面图）写回数据库

接口设计要点：

  1. 上传方式：

    • 简单场景：Spring MVC + MultipartFile
    • 大文件/高并发：
      • 分片上传：前端切片，后端提供分片上传 + 合并接口
      • 或采用直传对象存储（前端拿上传凭证直传），后端只接收回调

  2. 阻塞 vs 非阻塞：

    • Spring MVC（Servlet）：适合中小规模，线程阻塞模型
    • Spring WebFlux（Reactive）：基于 Reactor，适合高并发、IO 密集场景，能节省线程资源

  3. 异步转码：

    • 上传完成后通过 Kafka 发送消息：
      • Topic 示例：media-uploaded、media-transcode、media-audit
    • 消费者（media-service）：
      • 订阅 media-uploaded，触发转码
      • 转码完成后发送 media-transcoded 事件

  4. 幂等与重试：

    • 消息重复消费是常态
    • 幂等设计：
      • 使用业务主键（例如 mediaId）控制状态机
      • 状态表：UPLOADED -> TRANSCODING -> SUCCESS / FAILED
    • 重试策略：
      • 限制最大重试次数
      • 将多次失败的任务路由到死信队列（DLQ），人工或后台任务处理

三、Redis 缓存与热点内容

业务场景：热门视频、热门评论、用户主页常被访问。

常用数据结构：

  • String：简单 KV，如 video:123 -> JSON
  • Hash：存储对象属性，如 user:123 的 profile
  • ZSet：排行榜，如 hot:video 按播放量排序

典型使用模式：

  1. 缓存模式：

    • Cache Aside（旁路缓存）：
      • 读：先查缓存，没命中再查 DB，写回缓存
      • 写：写 DB 后删除缓存（避免脏数据）

  2. 缓存雪崩（大量 key 同时过期）：

    • 解决：
      • 设置随机过期时间（例如 baseTTL + random(0, 5min)）
      • 对热点 key 做缓存预热

  3. 缓存击穿（热点 key 突然失效，大量请求打到 DB）：

    • 解决：
      • 加互斥锁（例如 Redis 分布式锁）
      • 对不存在的数据缓存空值，短期内避免重复查 DB

  4. 缓存穿透（大量恶意查不存在数据）：

    • 解决：
      • 缓存空值
      • 使用布隆过滤器过滤明显不存在的 key

  5. 一致性问题：

    • 常见策略：写 DB 成功后删除缓存，避免写缓存再写 DB 导致顺序问题
    • 对于强一致性要求较高的场景，要控制更新流程，配合消息队列做异步同步

四、日志、链路追踪与可观测性

业务场景：一个请求可能跨多个微服务：

  • api-gateway -> user-service -> content-service -> media-service

工具链：

  • 日志：Logback / Log4j2 + SLF4J
  • 日志集中：ELK（Elasticsearch + Logstash + Kibana）
  • 指标：Micrometer + Prometheus + Grafana
  • 链路追踪：Spring Cloud Sleuth + Zipkin / Jaeger

关键点：

  1. 每个请求携带 traceId / spanId，网关注入，服务间传递
  2. 在日志中打印 traceId，便于关联多服务日志
  3. 配置 Micrometer 指标：
    • QPS：接口调用次数
    • Latency：响应时间
    • Error Rate：错误率
  4. 使用 Prometheus 抓取指标，Grafana 展示仪表盘

五、AIGC、RAG 与 Agentic RAG

1. AIGC 服务设计

场景：为短视频生成标题、封面文案，为用户写推荐语。

技术点：

  • Spring AI / Google A2A 作为统一大模型调用抽象
  • 提示填充（Prompt Templating）：比如 "请为这个视频生成 3 个吸引人的中文标题，视频标签为：{tags}"
  • 工程实践：
    • 统一 ai-service，封装调用 OpenAI / 内部大模型
    • 做好超时、重试、熔断、限流（Resilience4j）
2. RAG（检索增强生成）

典型流程：

  1. 文档/数据准备：
    • 将业务文档（视频描述、标签、用户行为摘要）切分为 chunks
    • 使用 Embedding 模型（如 OpenAI / 本地模型）向量化
  2. 向量存储：
    • Milvus / Chroma / Redis 向量索引
  3. 查询流程：
    • 用户问题（或推荐解释） -> 生成 query embedding
    • 在向量库中做相似度搜索（semantic search）
    • 取 top-k 结果拼到 Prompt 中，交给大模型生成答案

Java 实现要点：

  • 使用 Spring Boot + Spring AI 作为框架
  • 设计 VectorStoreService 接口：
    • saveEmbedding(docId, vector)
    • searchSimilar(queryVector, topK)
  • 向量库实现：
    • Redis：使用 Redis Stack / module 支持向量
    • Milvus / Chroma：通过官方 Java SDK / gRPC
3. Agentic RAG 与工具调用

业务场景：智能客服或推荐解释需要调用多种工具：

  • 查询订单：order-service
  • 查询支付状态：payment-service
  • 获取推荐候选：feed-service
  • 查询用户画像：profile-service

后端需要做的：

  1. 工具标准化描述：
    • 每个工具定义：名称、输入 schema、输出 schema、调用方式（REST/gRPC）
  2. 工具执行框架：
    • 在 Java 后端提供统一 ToolExecutor，接收 Agent 的工具调用请求
    • 负责参数校验、调用下游服务、返回结构化结果
  3. 会话内存：
    • 存储用户查询历史、工具调用结果、上下文状态
    • 可用 Redis / 数据库 + 缓存
  4. 复杂工作流：
    • 简单可用状态机 / 规则引擎
    • 复杂可以结合编排引擎（如 Camunda、Temporal），但这在大厂也不一定是标配
  5. 风控审计：
    • 记录每一次工具调用日志（谁、什么时候、查询了什么）
    • 对敏感数据访问做权限校验

六、AI 幻觉与安全风控

问题：大模型可能胡编乱造，尤其在：

  • 金融支付
  • 医疗健康
  • 互联网医疗、医疗供应链

架构层面缓解策略：

  1. 禁止大模型「想象」核心事实：
    • 所有关键数据必须通过工具调用真实系统（订单、支付、医疗记录）
    • 大模型只负责生成自然语言表达，不负责「算数」
  2. 结果校验：
    • 工具返回的数据需要进行格式、范围校验
    • 对异常结果进行降级处理（例如要求人工审核）
  3. 权限控制：
    • 使用 Spring Security / OAuth2 / Keycloak 控制接口访问
    • 对每个工具定义访问 scope与角色
  4. 合规提示：
    • 在部分场景增加免责声明，但不能代替真实风控

七、电商订单、分布式事务与支付

1. 分布式事务模式

场景：下单需要同时操作：

  • order-service：创建订单
  • inventory-service：扣减库存
  • payment-service：发起支付
  • coupon-service：核销优惠券

常见模式：

  1. 本地消息表 + 最终一致性：

    • 在本地事务中同时写业务记录和消息表
    • 后台任务将消息发送到 MQ
    • 下游消费并更新各自状态

  2. TCC（Try-Confirm-Cancel）：

    • Try：预留资源（如锁定库存）
    • Confirm：确认并扣减
    • Cancel：回滚预留

  3. SAGA：

    • 多步操作，每步都有补偿动作
    • 失败时按相反顺序执行补偿

工程实践：

  • 大厂更多使用「消息驱动的最终一致性」+严谨的状态机
  • 需要设计清晰的订单状态流转和幂等处理
2. 支付安全与认证

技术栈：

  • Spring Security
  • JWT / OAuth2
  • Keycloak / 自研统一认证中心

关键点：

  1. 登录获取 token：
    • 用户密码 / 第三方登录（OAuth2） -> 颁发 JWT
  2. 请求校验：
    • Gateway 验证签名和过期时间
    • 提取用户身份和权限
  3. 防止 token 被盗：
    • 强制 HTTPS
    • 缩短有效期 + Refresh Token
    • 绑定设备信息 / IP 白名单
    • 黑名单机制：支持注销 / 踢下线

八、实时风控与大数据处理

场景：支付风控、广告反作弊、内容风控。

技术栈：

  • Kafka：日志与事件总线
  • Flink / Spark：流式 / 批处理
  • Elasticsearch：检索与分析
  • Redis：黑名单 / 限流

典型风控流程：

  1. 支付服务把交易日志写入 Kafka（Topic：payment-log）
  2. Flink 作业消费：
    • 按用户 / IP / 设备窗口统计支付次数和金额
    • 识别异常行为（规则 / ML 模型）
  3. 将高风险用户写入 Redis / DB 决策表
  4. 下游服务（支付、订单）在处理时同步查询风控结果，做拒绝 / 人工审核 / 限额处理

Flink 关键点：

  • 使用事件时间（Event Time）
  • 定义窗口（如 5 分钟滚动窗口）
  • 做好 Checkpoint 和状态管理，保证故障恢复

九、监控、运维与可观测性

技术栈：

  • Micrometer：指标采集
  • Prometheus：时序数据库
  • Grafana：可视化
  • ELK：日志
  • Zipkin / Jaeger：链路追踪

指标设计：

  • 应用层：
    • QPS、RT（响应时间）、错误率
  • 业务层：
    • 下单成功率、支付成功率
    • AI 服务调用成功率、平均延迟
  • 资源层：
    • JVM 内存、GC 次数
    • 线程池使用情况

落地实践：

  1. 在 Spring Boot 项目中引入 micrometer-registry-prometheus
  2. 暴露 /actuator/prometheus 指标
  3. Prometheus 抓取这个 endpoint
  4. Grafana 配置面板展示业务指标

十、给初学者的建议

  1. 不要只背技术名词，要结合业务场景：
    • 内容社区：上传、转码、推荐、评论
    • 电商：订单、库存、支付、风控
    • 智能客服：多服务聚合、RAG、Agent
  2. 建议做一个自己的练手项目：
    • 使用 Spring Boot + Spring Cloud 搭微服务
    • 用 Kafka 做异步
    • 用 Redis 做缓存与会话
    • 用 Elasticsearch 做搜索
    • 去接一个开源大模型，尝试 RAG 和简单 Agent
  3. 在每个技术点上思考：
    • 为什么要用它？（业务痛点）
    • 它解决了什么问题？
    • 有什么局限？

把今天这篇「面试剧情 + 答案解析」当成一张路线图，逐块攻克，比盲目刷题更有效。

完：如果你也是准备去大厂面试的 Java 同学，可以根据这篇文章把自己的项目好好「故事化」和「场景化」，而不是只会背「我用 Spring Boot + MyBatis + Redis + Kafka」。

# 微服务 # AI
Logo
AtomGit开源社区

AtomGit 是由开放原子开源基金会联合 CSDN 等生态伙伴共同推出的新一代开源与人工智能协作平台。平台坚持“开放、中立、公益”的理念，把代码托管、模型共享、数据集托管、智能体开发体验和算力服务整合在一起，为开发者提供从开发、训练到部署的一站式体验。

更多推荐

入门大模型工程师第十课----学习总结

通过前面课程的学习，你已经从认识大模型开始，一步步知道怎么把任务讲清楚，怎么给 AI 补资料，怎么让 Agent 读文件、用工具、沉淀 Skill，也知道复杂任务做完后还要核对结果、守住安全边界。这门课的主线可以概括成一句话：从“让大模型回答问题”，走向“让大模型帮你完成任务”。最后这一课会把前面学过的能力串起来，再向你介绍一套分析思路，看一看为什么有的 AI 场景能落地，有的却做不下去。AI 任

avatar AtomGit开源社区
cover

Gemini 3.5 上下文窗口实测：200 万 token 到底能装下多少代码？

avatar AtomGit开源社区
cover

硅谷大厂集体涨价割韭菜，全球前十AI Lab却把三大模型全免费了

avatar AtomGit开源社区