后端项目面试怎么讲？从项目介绍到技术难点和故障复盘

Guide约 4771 字大约 16 分钟

“介绍一下你做的项目。”

“这是一个基于 Spring Boot 开发的微服务项目，使用了 MySQL、Redis、Kafka、Elasticsearch……”

很多项目介绍到这里就说不下去了。面试官再问一句“为什么要用 Kafka”，回答很容易卡住。Java、MySQL、Redis 的常见面试题可以提前背熟，项目追问却会一直落到真实的业务约束、代码实现和验证结果，背一段固定稿子只能应付开场。

面试官想从项目里了解什么？

面试官会从项目里确认几件事：你是否理解项目服务的业务，一条请求如何流转；你具体负责哪些代码、数据和上下游；遇到问题时怎样定位原因、比较方案并验证结果；简历里的技术和指标能不能经得起追问。

校招面试不会要求每个项目都达到大型生产系统的复杂度。一个自己做过、能够讲透的单体项目，通常比照着教程搭出的微服务项目更稳。社招会继续追问流量、容量、故障、灰度、回滚以及团队协作，回答时需要提供更多生产证据。

面试前先整理一张项目底稿

给简历上的每个重点项目单独整理一份底稿，不必写成文章，自己能看懂、面试前能快速回忆即可。

要整理的内容	需要回答的问题
业务背景	项目给谁用？解决什么问题？最重要的业务链路是什么？
系统范围	有哪些模块？依赖哪些外部系统？数据从哪里来、到哪里去？
个人职责	哪些需求、接口或模块由你负责？参与到什么程度？
核心链路	一次请求会经过哪些服务、缓存、数据库和消息队列？
技术选型	为什么使用当前方案？比较过哪些方案？付出了什么代价？
难点与故障	遇到过什么具体问题？怎么定位、修复和验证？
项目指标	流量、延迟、错误率、数据量、资源消耗和优化结果有哪些可靠记录？

底稿最后留一栏，专门写自己没有参与的部分。例如数据库表由你设计，部署和容量规划由基础架构团队负责，就按实际情况回答。面试官通常能接受职责范围有限，编造参与经历的风险反而更大。

项目介绍应该怎么讲？

30 秒和 3 分钟两个版本都要准备。面试官只想快速了解时使用短版本；对方让你详细介绍时，再补充架构、职责和重点工作。

30 秒版本

30 秒版本只保留四项内容：项目解决的问题、主要用户或业务、你的职责、一项准备深入讲的工作。

例如：

这是一个面向企业内部采购人员的订单系统，主要覆盖商品查询、下单、审批和订单履约。我在项目中负责订单创建和超时关闭两条链路，包括表结构设计、接口开发、幂等处理和监控接入。项目里投入时间最多的是订单创建链路的性能优化，后面我可以详细介绍当时如何定位慢请求。

这段话没有罗列所有中间件，但给面试官留下了几个可以继续问的点：订单状态、幂等、超时关闭和性能优化。

3 分钟版本

3 分钟版本按下面的顺序展开：

项目的业务背景和用户。
系统包含哪些主要模块，核心请求如何流转。
自己负责的模块和职责范围。
一两个有证据的难点或结果。

仍然以订单系统为例：

系统主要给采购和财务人员使用，负责商品查询、订单创建、审批、支付状态同步和履约查询。后端按订单、库存和审批模块拆分，订单创建时会先校验请求和价格，再创建订单并预占库存；成功后发送消息，由下游完成审批通知等异步任务。
我负责订单创建和超时关闭。订单创建需要处理重复提交、库存不足以及消息发送失败；超时关闭需要避免关闭已经支付的订单。我主要完成了接口、状态流转、幂等和补偿任务，并接入了相关监控。后来一次版本上线后，订单查询接口的长尾延迟上升，我参与了问题定位和优化。我们根据 Trace 和慢 SQL 找到查询条件与联合索引不匹配的问题，调整索引后又做了相同数据量下的对比压测。

这是一个示例，不要直接把里面的职责和故障换个项目名放进简历。自己的项目没有消息队列，就讲同步调用；没有真实压测数据，也可以说明测试环境和验证方法，不要临时编一个 QPS。

架构图怎么讲？

项目架构图适合按一次真实请求来讲。用户请求从网关进入，经过哪个服务，读取哪些缓存和数据库，什么任务进入消息队列，失败后怎么处理。讲完主链路，再补一条异常链路。

架构里每出现一个组件，最好都能回答三个问题：

它在这条链路里承担什么工作？
去掉它会发生什么？
它不可用时，系统怎样处理？

如果项目使用 Redis 缓存商品信息，还要准备缓存未命中后的数据库查询、缓存过期策略、热点数据、数据一致性以及 Redis 故障时的降级方式。只回答“Redis 性能高，所以用 Redis”，通常很快就会进入知识盲区。

架构图也不要画得太大。一张图塞进网关、注册中心、配置中心、十几个微服务和所有中间件，介绍时很难找到重点。面试用架构图保留项目范围和一条核心链路就够了，复杂项目可以再准备一张模块图或时序图。

怎么说明自己的职责？

“负责订单模块开发”提供的信息很少。继续说清需求范围、代码范围和协作范围：

需求范围：订单创建、取消、超时关闭，还是整个订单域。
代码范围：接口、表结构、状态机、定时任务、消息消费分别参与到什么程度。
协作范围：是否参与方案评审，和库存、支付、测试、运维如何配合。
结果范围：上线、灰度、监控和后续维护是否由自己跟进。

校招项目就直接说明这是个人项目或课程项目，以及哪些部分参考了教程。自己在教程基础上增加过功能、补过测试、改过表结构，就重点讲这些改动。面试官关注的是你有没有真正动手和思考，不需要把个人项目包装成大厂生产系统。

技术选型怎么回答？

回答技术选型时，把问题、约束、候选方案和验证结果说全。

假设面试官问：“订单超时关闭为什么使用延迟消息？”

回答时需要交代：

订单创建后需要在指定时间检查支付状态，任务量和延迟精度有什么要求。
定时扫描数据库、Redis 过期通知、时间轮和延迟消息分别有什么限制。
当前项目为什么选择延迟消息，现有基础设施、运维成本和团队经验是否影响决策。
消息重复、延迟、丢失或者消费者故障时如何处理。

离开项目条件，选型没有标准答案。小型项目用定时任务扫描待支付订单，配合合适的索引和分片处理，可能已经够用；团队已有成熟的消息队列，订单量又比较大时，可以考虑延迟消息。面试回答应说明当前条件下为什么这样选，同时承认方案的限制。

引入 Redis、Kafka 或 Elasticsearch 只能说明项目使用了这些组件。能够解释下面这些问题，才说明你掌握了这部分工作：

Redis 缓存的是哪些数据，Key 怎么设计，过期时间怎么定。
Kafka 的 Topic 和分区怎么设计，生产失败和重复消费怎么处理。
Elasticsearch 里的文档如何建模，索引如何更新，查询结果为什么可信。
分库分表以后如何选择分片键，扩容和跨分片查询怎么处理。

项目没有达到相应规模时，可以把某项技术作为学习和实验说明，不要声称它解决了并不存在的生产瓶颈。

项目难点怎么讲？

“时间比较紧”“需求经常变”确实会增加工作难度，但技术面试通常希望听到一个能够继续追问的工程问题。

从自己确实做过的事情里找材料，常见的有：

正确性问题：重复下单、库存超卖、状态错乱、金额精度、数据不一致。
性能问题：慢 SQL、缓存命中率下降、锁竞争、线程池堆积、GC 停顿。
稳定性问题：依赖超时、消息积压、连接池耗尽、发布故障、流量突增。
工程问题：历史代码改造、灰度迁移、兼容旧数据、跨团队接口变更。

一个难点至少应该讲清下面这条过程：

现象和影响 → 已知约束 → 排查或分析 → 方案比较
→ 实施过程 → 验证结果 → 遗留问题

例如“查询接口很慢”还不是完整难点。继续说明哪些请求慢、从什么时候开始、P95/P99 如何变化、数据库扫描了多少行、最终改了索引还是查询逻辑、相同数据和流量下如何验证。没有留存当时的数字，就说明观察过哪些指标以及结论来自什么证据。

性能优化怎么讲？

项目中的性能优化很容易被追问，因为“接口耗时从 2 秒降到 200 ms”后面还跟着很多问题：

2 秒和 200 ms 分别在哪里测量？
数据量、并发数和机器配置是否相同？
看的是平均耗时还是 P95/P99？
瓶颈究竟在应用、数据库、缓存还是下游服务？
优化以后有没有增加数据一致性风险和维护成本？

准备性能优化案例时，保留一组可核对的材料：优化前后的 Trace、执行计划、GC 日志、压测配置、监控截图或者测试报告。公司材料不方便带走，可以记录经过脱敏的结论和排查过程。

回答时把这些信息连起来：

某接口在什么流量和数据量下出现什么问题；我根据哪些指标把问题缩小到哪个环节；比较过哪些方案，最后改了什么；使用什么环境和指标验证；上线后继续观察了什么；这个改动带来了哪些成本。

缓存、异步和并行处理经常能改善响应时间，也会引入缓存一致性、消息可靠性、线程安全和下游压力。把这些代价说出来，比单独强调性能数字更可信。

线上故障怎么讲？

一次故障按时间顺序回答：

发现问题：告警、用户反馈或者发布观察发现了什么。
确认影响：哪些接口、用户和实例受到影响，错误率和延迟如何变化。
紧急止血：回滚、摘除实例、限流、降级或关闭功能。
保留证据：日志、Trace、线程栈、Heap Dump、GC 日志以及变更记录。
定位根因：提出过哪些假设，怎么排除错误方向，最后用什么证据确认。
修复验证：代码或配置改了什么，怎样测试、灰度和观察。
避免复发：补了哪些监控、测试、容量限制或发布检查。

排障时采取过临时措施，也要说明它的副作用。例如重启实例能够暂时恢复服务，但会丢失现场；盲目扩容可能把压力继续传给数据库。完整的排查方法可以参考：Java 后端线上问题排查。

项目指标怎么准备？

指标要能说明项目规模、问题影响或改动结果，不需要为了显得项目大而堆数字。

指标	适合说明什么	常见误区
QPS/TPS	流量和系统吞吐	只报峰值，不说明统计位置和时间范围
P95/P99	长尾请求体验	只看平均响应时间
错误率	请求失败情况	把业务拒绝和系统错误混在一起
数据量	查询、存储和迁移规模	只说总量，不说明增长速度和冷热分布
CPU、内存、GC	应用资源与 JVM 状态	只报优化后的数字，没有对照条件
队列积压、连接池等待	系统内部排队	只扩容，不确认下游处理能力