用电商与AI客服场景串起 Java 技术栈一场互联网大厂面试的灵魂拷问场景某互联网大厂电商事业部招聘 Java 后端工程师。 角色面试官X 老师严肃、业务技术都很懂。候选人水货程序员小 Y自称“全栈、懂 AI”其实基础一般遇到难题容易含糊其辞。第一轮电商下单链路与基础服务场景方向电商场景 支付与金融服务 技术主线Spring Boot、Spring MVC、MyBatis、Redis、Kafka、事务、日志面试官今天我们聊一个典型电商场景用户在 APP 上下单买鞋。先从简单的开始。Q1请你用 Spring Boot 设计一个“创建订单”的接口大致说说URL 怎么设计用到哪些注解Controller 层和 Service 层怎么分工小 Y嗯这个我做过很多次我一般这么写URLPOST /api/orders就很 RESTful。Controller 上用RestController、RequestMapping(/api/orders)方法上PostMapping。入参用一个OrderCreateRequest用RequestBody接一下。Controller 里就简单调一下orderService.createOrder()。Service 里写业务逻辑比如校验库存、计算价格啥的。面试官还不错。那我们继续深入。Q2订单数据落库你打算用 MyBatis 或 JPA说说你的表结构设计和 DAO 层怎么写。小 Y我们公司一般用 MyBatis。表的话就搞一个t_order字段有id、user_id、status、total_amount、created_at差不多就这样。DAO 就是一个OrderMapper接口里面写insertOrder(Order order)这种方法。SQL 就用 XML 写或者Insert注解都行我都用过。面试官可以。那订单场景肯定涉及并发与性能我们来看缓存和消息。Q3下单成功后你会不会用 Redis 做一些缓存比如订单详情或用户购物车你会怎么设计 key 和过期策略小 YRedis 我很熟经常SET和GET。比如订单详情我可以用 keyorder:detail:{orderId}。value 就存一个 JSON。过期时间可以设置个一两小时或者干脆不设看情况吧。用户购物车就用cart:{userId}用 hash 或 list 都行主要看业务需求。面试官好那我们再往后一点。Q4订单创建成功后如果要异步发送消息到 Kafka触发“库存中心”和“短信通知服务”你怎么保证消息不丢在 Spring Boot 里大概怎么实现小 YKafka 我也接触过就是发个消息嘛。下单成功后我在 Service 里直接发 Kafka 消息kafkaTemplate.send(order-created, orderJson)。至于消息不丢嘛Kafka 本身就很可靠吧只要集群搭好就行我以前好像没遇到过丢消息问题。面试官嗯……回答有点泛。最后一个基础问题。Q5高并发下单场景你会怎么设计日志使用哪些框架如何方便后期排查问题小 Y日志的话肯定是SLF4J Logback或者Log4j2。我一般private static final Logger logger LoggerFactory.getLogger(...)。然后关键地方打 info 和 error 日志。至于排查问题就是看日志文件嘛必要的时候可以打一下请求参数和订单号。面试官小结基础还行不过 Kafka 保证不丢消息、事务这些你说得比较含糊等会我们详细聊。第二轮微服务拆分与监控链路场景方向电商 智慧物流 供应链金融 技术主线Spring Cloud、注册发现、Feign、Resilience4j、ELK、Prometheus、链路追踪面试官现在假设你的电商系统已经拆成多个微服务订单服务、库存服务、物流服务、支付服务。我们从服务之间调用开始。Q6在 Spring Cloud 里如果订单服务需要调用库存服务的接口你会用什么技术栈大概怎么写小 Y这个很简单我们都用 Feign。先搞一个FeignClient(name inventory-service)的接口。里面写个PostMapping(/api/inventory/reserve)方法。然后订单服务的 Service 里直接注入这个 FeignClient调用就好了。面试官不错。那调用失败怎么办Q7如果库存服务偶尔超时或挂了你会如何做熔断和重试说说 Resilience4j 或 Spring Cloud CircuitBreaker 怎么用。小 Y熔断嘛以前用过 Hystrix现在不是都说用 Resilience4j 吗。我印象里是加个注解比如CircuitBreaker(name inventory, fallbackMethod fallback)。重试的话好像有个Retry注解。至于参数配置……一般就是抄公司现有的配置阈值啥的运维会帮忙调。面试官回答有点“照配方做菜”的感觉。我们换个角度。Q8线上出现“用户下单成功但物流单没有生成”的问题你会怎么用 ELKElasticsearch Logstash Kibana和链路追踪比如 Zipkin 或 Jaeger来排查小 YELK 我知道是用来搜日志的链路追踪也知道有 traceId。我以前就是在日志里打上订单号和 traceId然后在 Kibana 搜索。追踪的话就是在调用链中带着 traceId可以在 Zipkin 里看到一条调用链看哪个服务报错之类的。具体怎么埋点嘛好像 Spring Cloud Sleuth 自动就搞好了我们啥也不用干基本开箱即用。面试官还能说到 traceId不错。那监控指标呢Q9高峰期下单量猛增你会在系统里用 Prometheus Micrometer 暴露哪些关键指标这些指标怎么帮助你做容量预估小 YPrometheus 我知道是抓指标的Micrometer 是打指标的。关键指标的话有 QPS、接口耗时、错误率。Micrometer 好像自动帮我们打这些指标暴露一个/actuator/prometheus就行。容量预估就是看 QPS 和 CPU用经验判断要不要加机器。面试官还算有概念。我们做一点难度升级。Q10假设订单服务再调用支付服务支付服务调用第三方支付渠道比如某支付公司整个链路有多个系统。你会怎么设计日志和链路追踪让风控团队可以复盘每一笔支付的完整路径小 Y这个嘛……日志肯定要打得详细一点比如订单号、支付流水号。链路追踪就是 traceId 一路传下去。然后风控那边就可以通过这些 ID 查到相关日志。至于具体设计规范嘛我们公司有“统一日志规范”我一般照着写。面试官小结微服务这块你停留在“用过”的层面缺少深入理解不过至少知道核心工具的用途。第三轮AI 智能客服与 RAG 场景场景方向AI 智能客服系统 企业协同与 SaaS 大数据与 AI 服务 技术主线Spring AI、RAG、向量化、向量数据库、语义检索、Agentic RAG、Redis、Kafka、ElasticSearch面试官我们电商现在在做“AI 智能客服系统”帮助用户查询订单、物流、退款等问题。你不是说自己懂 AI 吗我们聊聊这块。Q11在后端架构里用 Spring 体系接入大模型服务你会怎么设计比如用 Spring Boot Spring AI 去调用 OpenAI 或企业自研模型大致说说架构。小 YSpring AI 我有关注过博客大概是写一个 Service里面用 Spring AI 提供的客户端去调大模型接口。配置里写上 API Key 和模型名字。前端把用户问题发到后端后端再丢给大模型处理。然后返回回答给用户。整体结构跟普通的 HTTP 调用差不多嘛。面试官只调用大模型是不够的容易胡说八道。我们需要 RAG。Q12请你用自己的理解解释什么是 RAG检索增强生成在“电商订单问答”业务里它解决了什么问题小 YRAG 我知道就是先检索再生成先从知识库里找相关文档再把这些文档给大模型让它参考着回答。在电商订单问答场景比如用户问“我的订单为什么还没发货”就从订单和物流数据里查一下再给模型用。这样回答就更准确一点不会乱说。面试官还可以那我们聊聊向量化和向量数据库。Q13如果我们用向量数据库比如 Milvus 或 Redis 向量做语义检索把“退款规则、物流说明、商品介绍”这些文档给 AI 用你会怎么设计数据流包括文档加载、向量化、存储、查询。小 Y这个流程我大概知道文档加载先从数据库或文件系统里读出这些文档。向量化用 Embedding 模型比如 OpenAI 的 embedding 或别的把文本转成向量。存储把向量存到 Milvus 或 Redis也存一下原文内容和 ID。查询用户提问时把问题也向量化然后在向量库里做相似度搜索拿到几个相关文档给模型参考。面试官那在实际业务中我们还会引入 Agent 和复杂工作流。Q14如果我们要做“企业文档问答 工具执行”的智能客服比如 AI 不仅能查订单还能主动调用退款接口你能不能说说 Agent 的作用它和普通 RAG 有什么区别小 YAgent 我感觉就是更聪明一点的 AI它能根据对话决定调用哪个工具比如“查订单服务”、“退款服务”。普通 RAG就只检索文档Agent 则能执行动作。复杂工作流的话Agent 能把多步操作串起来比如先查订单再查物流再决定要不要发短信。至于具体怎么实现我知道有些框架已经封装好了我们只要配置工具就行。面试官最后一个问题我们回到工程实践。Q15在这个“AI 智能客服系统”里涉及到 Kafka、Redis、ElasticSearch、向量数据库、各种微服务。请你从整体上描述一下前端到后端的调用链数据是怎么流动的哪些地方容易出现 AI 幻觉Hallucination你会怎么降低风险小 Y这个就比较复杂了……我大概说一下前端调用用户在页面上提问前端调后端一个聊天接口。后端先通过 Redis 查一下用户上下文会话内存那种然后可能发消息到 Kafka 做异步分析。向量数据库那块就负责语义检索ElasticSearch 负责结构化数据搜索。最后把结果交给大模型生成回答。AI 幻觉嘛……就是回答不准确我们可以多给模型一点上下文或者让它不要胡编。还有就是增加一些规则校验吧。面试官小结你对 AI 和 RAG 有基本概念但细节还是很模糊。整体来看你在电商和微服务场景里用到的技术比较全面但很多只是“听过、用过”缺少深入实践和系统性思考。面试官今天先到这里吧我们内部再评估一下你回去等通知。 小 Y心里默念又是熟悉的“等通知”……附录面试问题详解给小白的技术业务学习笔记下面按问题顺序对业务场景和技术点做系统梳理方便刚入门的同学学习。一、电商下单基础链路Q1 ~ Q51. Spring Boot 订单接口设计Q1业务场景用户在电商 APP 上点击“立即购买”需要创建一笔订单。技术实现使用Spring Boot Spring MVC开 REST 接口。路由设计POST /api/orders表示“创建订单”。关键注解RestController声明这是一个返回 JSON 的控制器。RequestMapping(/api/orders)指定根路径。PostMapping表示 HTTP POST 请求。RequestBody将请求体 JSON 转成 Java 对象。分层思想Controller 层负责接收 HTTP 请求、参数校验、返回响应。不写复杂业务逻辑只做“转发和组装”。Service 层负责核心业务逻辑校验库存、计算价格、生成订单号等。DAO/Repository 层与数据库交互做 CRUD。示例结构RestController RequestMapping(/api/orders) public class OrderController { private final OrderService orderService; PostMapping public OrderCreateResponse createOrder(RequestBody OrderCreateRequest request) { return orderService.createOrder(request); } }这种分层既符合电商业务复杂度又方便后期维护和测试。2. MyBatis 表结构与数据访问Q2业务场景每一笔订单都需要持久化到数据库便于后续支付、发货、售后和风控。典型表设计t_orderid主键通常为雪花 ID 或 UUID。user_id用户 ID。status订单状态待支付、已支付、已发货、已取消等。total_amount订单总金额。created_at创建时间。视业务复杂度还会有pay_time、delivery_time等。MyBatis DAO 示例public interface OrderMapper { int insertOrder(Order order); Order selectById(Long id); }对应 XMLinsert idinsertOrder parameterTypeOrder INSERT INTO t_order(user_id, status, total_amount, created_at) VALUES(#{userId}, #{status}, #{totalAmount}, #{createdAt}) /insert关键点表结构要能支撑后续物流、支付、风控等场景。DAO 层要与业务解耦尽量只关注数据操作。3. Redis 缓存设计订单详情与购物车Q3业务场景订单详情用户下单后频繁查看订单状态如果每次都查数据库会有压力。购物车用户可能多次进入购物车读写频繁适合放缓存。Redis key 设计订单详情order:detail:{orderId}value订单详情 JSON 或序列化后的对象。过期时间可设置 1~2 小时或者根据业务策略例如最近一周订单缓存。购物车cart:{userId}结构用 hash 存商品 ID - 数量。或 list 存购物车条目。设计原则key 要有前缀方便按业务维度管理。value 尽量避免过大合理设置过期时间。读写路径先查 Redis命中则直接返回。未命中再查数据库并写入 Redis。4. Kafka 消息与“消息不丢”Q4业务场景订单创建成功后需要通知多个系统库存中心扣减或预留库存。短信通知服务给用户发短信。基本技术使用 Kafka 做异步消息通知。在 Spring Boot 中使用KafkaTemplate发送消息。可靠性设计要点事务一致性订单写数据库成功但消息发送失败会导致“订单有但下游不知道”。常见解决方案本地消息表 定时投递订单和“消息记录”在一个数据库事务中写入。定时任务扫描未发送的消息投递到 Kafka。或使用 Kafka 事务transactional.id将数据库操作和消息发送做协调实现复杂度较高需谨慎。消息确认与重试Producer 开启acksall保证消息被所有副本写入才算成功。配置重试机制避免网络抖动导致消息丢失。小 Y的回答只停留在“发送消息”但大厂会非常关注消息与数据库的整体一致性。5. 日志设计与排查能力Q5业务场景高频下单期双 11、618问题多发。需要快速定位是哪一笔订单、在哪个节点出了问题。技术方案使用SLF4J Logback 或 Log4j2统一日志接口。关键日志内容订单号、用户 ID、traceId链路 ID。请求参数谨慎记录敏感信息。异常栈、状态变更例如订单状态由“待支付”变“已支付”。日志级别设计INFO记录正常重要行为如订单创建成功。WARN记录可疑但未影响整体的事件。ERROR记录异常和失败。排查方式通过订单号和 traceId 快速在日志系统中定位完整操作路径。二、微服务架构与监控排障Q6 ~ Q106. Spring Cloud 下的服务调用FeignQ6业务场景订单服务需要调用库存服务进行库存预留。技术方案使用Spring Cloud OpenFeign实现服务间 HTTP 调用。示例FeignClient(name inventory-service) public interface InventoryClient { PostMapping(/api/inventory/reserve) ReserveResponse reserve(RequestBody ReserveRequest request); }在订单 Service 中注入InventoryClient并调用即可。注意点需要配合服务注册发现Eureka、Consul、Nacos 等才能通过服务名访问。7. 熔断与重试Resilience4jQ7业务场景库存服务可能因流量突增、部署异常而短暂不可用。订单服务不能一直傻等需要快速失败或降级。核心概念熔断器Circuit Breaker监控调用失败率超过阈值后直接阻断请求避免拖垮系统。重试Retry对暂时性错误进行多次重试例如网络抖动。Resilience4j 使用示例CircuitBreaker(name inventory, fallbackMethod reserveFallback) Retry(name inventory) public ReserveResponse reserve(...) { return inventoryClient.reserve(...); } public ReserveResponse reserveFallback(ReserveRequest request, Throwable t) { // 降级策略 // 1. 告知用户“系统繁忙请稍后再试” // 2. 或写入补偿队列后续异步处理。 }真正难点在于如何选择熔断阈值、重试次数和超时时间。如何设计合理的业务降级方案。8. ELK 和链路追踪定位“订单有物流单无”Q8业务问题用户下单成功但物流系统没有建立运单对用户体验影响很大。排查思路日志维度ELK在订单服务和物流服务的日志中都记录订单号和 traceId。使用 Kibana 搜索订单号查看订单服务是否调用了物流服务接口。调用结果、响应码、异常栈。链路维度Zipkin/Jaeger通过 traceId 查看完整调用链user - 订单服务 - 物流服务。找出哪一段出错或耗时异常。技术点Spring Cloud Sleuth 自动添加 traceId 和 spanId 到日志和调用链。Zipkin/Jaeger 展示请求调用拓扑和每段耗时。9. Prometheus Micrometer容量预估Q9业务场景大促峰值时需要提前预估系统是否能撑住。技术方案使用Micrometer将指标暴露到Prometheus。指标采集接口 QPS每秒请求数。响应耗时分布p99、p95。错误率。JVM 指标GC 次数、堆内存、线程数。流程Spring Boot 引入 Actuator Micrometer。暴露/actuator/prometheus指标。Prometheus 定时抓取数据Grafana 可视化。根据指标做容量计划根据 QPS 和响应时间估算每台机器承载能力。结合 CPU、内存使用率决定是否扩容。10. 支付全链路与风控复盘Q10业务场景一笔支付涉及多个系统订单服务 - 支付服务 - 第三方支付渠道 - 回调通知。风控团队需要能追踪每一笔支付完整路径。技术要点统一 ID订单号orderId。支付流水号paymentId。traceId链路 ID。日志规范每个参与服务必须记录这些 ID。日志中包含关键状态变更支付请求发起、渠道响应、回调处理结果。链路追踪使用 traceId 串起调用链。第三方渠道通常是“黑盒”但可通过回调和自方日志补全路径。三、AI 智能客服与 RAG 体系Q11 ~ Q1511. Spring AI 接入大模型服务Q11业务场景电商需要智能客服回答“订单、物流、退款规则”等问题。技术方案使用Spring Boot Spring AI封装调用大模型的逻辑。基本架构Controller 接收用户问题。Service 层调用 Spring AI 客户端配置模型OpenAI、企业自研模型等。传入 prompt问题 上下文。返回模型生成的答案给前端。注意仅靠大模型本身容易产生不准确回答幻觉需要结合企业数据下一节 RAG。12. RAG检索增强生成在订单问答中的作用Q12概念RAG Retrieval Augmented Generation。“先检索后生成”从企业知识库检索相关内容。再让模型基于这些内容生成答案。电商订单问答场景用户问“我的订单为什么还没发货”传统大模型不知道你的业务系统只能猜。RAG 流程从订单系统和物流系统查询该用户订单的真实状态。从“发货规则”文档如节假日延迟检索相关条款。将这些信息组合成上下文传给大模型让它用自然语言解释。效果回答不再胡编而是基于真实业务数据和规则。13. 向量化与向量数据库数据流Q13业务场景需要支持用户自然语言问“如何退款包裹丢了怎么办”不仅是精确关键词而是语义理解。关键组件Embedding 模型把文本转成向量。向量数据库Milvus、Chroma、Redis 向量、或其他。数据流设计文档加载来源退款规则、物流说明、商品介绍、客服 SOP 等。从数据库或文件系统读出文本。向量化对每一段文本chunk调用 Embedding 模型得到高维向量。存储将向量 文本片段 元数据文档 ID、标题等存入向量数据库。查询用户提问时对问题文本做向量化。在向量库中做相似度搜索Top-K。返回与问题最相关的文档片段给大模型参考。好处支持“模糊语义搜索”而非简单的关键词匹配。14. Agent 与 Agentic RAG从回答到“能动手”Q14传统 RAG只检索文档并生成答案不会主动调用业务系统。Agent 概念Agent 能够“思考 决策 调用工具”的智能体。可以根据用户需求自动选择调用哪些工具查询订单、发起退款、创建工单等。将多步操作串起来形成“工作流”。Agentic RAG 在电商客服中的例子用户说“我想取消还未发货的订单并退回到原支付方式。”Agent 行为可能是检索退款规则文档RAG。调用“订单查询工具”确认订单状态。如果满足可取消条件调用“订单取消工具”和“退款工具”。将整个操作结果以自然语言反馈给用户。技术要点需要定义一套标准化的“工具接口”输入输出结构清晰。权限控制到位避免越权操作。需要设计“安全策略”防止 Agent 做出违规操作。15. 全链路数据流与 AI 幻觉风险Q15整体架构示意前端聊天界面用户输入问题。网关 / Chat API接收请求进行身份认证、限流。会话服务用 Redis 或其他存储保存聊天上下文和用户会话信息。检索模块Elasticsearch用于结构化数据搜索订单记录、物流信息。向量数据库用于语义检索规则文档、知识库。大模型服务Spring AI 封装调用。将检索到的内容和用户问题一起传入模型。Agent 工具执行根据模型“决策”调用具体业务工具订单查询、退款操作等。异步通道Kafka记录重要操作、事件供风控和审计分析。监控与日志Prometheus、Grafana、ELK、链路追踪保障系统稳定性和可观测性。AI 幻觉Hallucination风险点模型可能编造不存在的订单或规则。给出错误的退款或发货承诺。降低幻觉的策略严格基于检索内容回答明确提示模型“只能根据提供的文档回答如果没有答案要说不知道。”结果校验对关键业务动作如退款金额做规则校验不直接相信模型输出。分角色设计大模型只做“语言生成”最终决策由后端逻辑或风控规则确定。记录与审计所有关键回答和动作经过 Kafka/日志系统记录便于事后审查和优化。总结这篇文章通过一个“电商 AI 智能客服”的大厂面试故事把以下技术点串联在一起基础Spring Boot、Spring MVC、MyBatis、Redis、Kafka、日志框架。微服务与监控Spring Cloud、Feign、Resilience4j、ELK、Prometheus、链路追踪。AI 与 RAGSpring AI、Embedding 模型、向量数据库、RAG、Agentic RAG、AI 幻觉治理。对于刚入门的同学可以先从电商下单的基础接口和数据表设计入手再逐步理解微服务、监控体系最后接触 AI 和 RAG 在实际业务中的落地方式。这样比直接看零散的技术文档更容易形成整体认知。