后端面试必问：54人项目请求链路从网关到事务全解析-北京尧图网络

你简历上写着“54 人共创的项目”面试官点了点头然后突然问了一句“那你给我讲讲一个请求从浏览器发出来到页面拿到数据这条请求链路是怎么走的”这个场景我太熟了我自己面过也陪朋友模拟面过。说句实话在几十人规模的项目里待过的人十有八九被这个问题问倒。倒不是没写过代码而是这类项目的链路实在太长从 Nginx 到网关从网关到拦截器从 Controller 到 Service再从 Service 到 Mapper中间还穿插着 Redis、MQ、跨服务 RPC。平时大家各管各的模块开发时只盯着自己那一小段很少有人会把整条链路从头到尾捋一遍。面试官专挑这种问题问就是想看你有没有全局视野。我复盘了一下54 人共创项目里最容易被问住的其实就两段一段在入口一段在出口。入口那一段是从请求到达服务器、到进入 Controller 之前的“前置管道”出口那一段是 Service 开始处理业务、到数据真正落库成功的“事务与一致性链路”。这两段都是多人协作时容易被改乱、被忽视但面试官非常爱深挖的地方。这篇文章就围绕这两段给你掰开揉碎地讲覆盖原理、代码位置、面试话术和真实排障经验适合正在准备面试的后端开发也适合想把自己项目讲清楚的团队负责人。1. 先搞清楚54 人共创项目里的请求链路到底有多长1.1 什么才算“请求链路”很多人对请求链路的理解停留在“浏览器发请求后端查数据库返回 JSON”。这没错但太粗了。站在后端面试的角度请求链路指的是一个请求从进入系统边界开始到响应完全返回期间经历的所有处理节点、组件调用和数据读写路径。我一般习惯把它拆成四段来看接入段DNS、Nginx、网关Gateway负责流量接入、路由、限流、跨域等前置段Filter、Interceptor、参数解析、鉴权、日志、TraceID 注入负责在业务代码执行前做公共处理业务段Controller、Service、Mapper以及 RPC 调用、消息发送、缓存读写负责真正的业务逻辑出口段事务提交、缓存生效、消息确认、数据落库负责保证数据最终一致。前面两段是“过滤器式”的横向链路后面两段是“业务处理式”的纵向链路。面试官说“链路怎么走”他想听到的不仅仅是 Controller 到 Mapper而是这四段里的关键节点、每一层做了什么、在哪一层做了什么事、出了问题怎么排查。1.2 54 人共同开发为什么链路会失控人一多链路复杂度就不是线性增长而是指数增长。我见过最典型的情况一个请求要经过 7 个 Filter、3 个 Interceptor、2 次 RPC 调用、1 次 MQ 发送才真正走到业务方法。问团队里任何一个人都说不全到底经过了多少节点。原因无非这么几个模块边界模糊54 个人分 8 个小组网关和基础组件是公共的谁都可以改但谁都不“拥有”它链路被人为拉长A 组在 Filter 里加了签名校验B 组在 Interceptor 里加了权限逻辑C 组又在网关里加了黑白名单本来一段简单的链路被叠了好几层文档严重滞后架构图停留在两年前接口文档只写了入参出参链路上的节点全靠人肉问责任不清晰请求走到一半超时了大家第一反应是“不是我这段的问题”链路断裂了没人认领。这种环境下面试官问链路怎么走如果你只回答“请求先进 Controller再进 Service”他立刻知道你对项目全局没有概念。反之你能把链路画成一张有节点、有顺序、有职责说明的图那基本就赢了一半。1.3 最容易被问住的两段前置管道和事务出口结合我自己的面试经历和帮别人模拟面试的经验54 人共创项目里最容易被问住的不是 Controller 也不是 Mapper而是这两段第一段入口前置链路从请求到 Controller 之前。这一段涉及网关、Filter、Interceptor 三者的职责边界和执行顺序还涉及 token 解析、TraceID 注入、限流、跨域等一堆公共逻辑。面试官往深了问很多人就分不清 Filter 和 Interceptor 到底谁先执行说不清网关校验和业务层校验为什么同时存在。第二段业务处理与数据一致性链路从 Service 开始到数据真正落库。这一段涉及事务边界、缓存读写、消息发送、分布式一致性。面试官特别喜欢追问“你的事务注解加在哪一层”“如果缓存写失败怎么办”“RPC 超时了数据怎么保持一致”。大部分人的回答到这里就含糊了。把这两段讲清楚你基本就能扛住“请求链路怎么走”的完整追问。2. 第一段入口前置链路——网关、Filter、Interceptor 这条“看不见的管道”2.1 这段链路里到底排队了些什么先说结论在大多数 Java 后端项目里一个请求进入系统后依次通过接入层、Filter、Interceptor最后才进入 Controller。这一段链路很容易被忽略因为它往往不写业务代码但它决定了请求是否有资格进入业务层。拿一个典型的微服务项目举例请求处理顺序是这样Nginx 负载均衡负责 SSL 终止、静态资源、基础限流网关Spring Cloud Gateway / Zuul负责路由、统一鉴权、限流、跨域、灰度Servlet Filter 链如果是 Spring Boot 内置容器负责编码、CORS、日志、安全相关Spring MVC Interceptor负责登录态校验、权限判断、Controller 方法级拦截AOP 切面Aspect负责埋点、Idempotent 校验、操作日志。面试官让你“讲链路”你必须把这一段按顺序讲出来并且能说出每个节点的职责。比如 Nginx 做的是网络层负载均衡网关做的是应用层路由和鉴权Filter 是 Servlet 规范Interceptor 是 Spring MVC 规范AOP 是针对方法级别的拦截。四者听起来都在“拦截”但层级完全不同。2.2 Filter 和 Interceptor 的边界是第一个分水岭我在模拟面试时发现近一半的人在这里卡壳。Filter 和 Interceptor 到底有什么区别关键在于它们属于不同规范、作用于不同阶段对比项FilterInterceptor规范归属Servlet 规范Spring MVC 规范作用范围所有请求包括静态资源只拦截进入 Spring MVC 处理的请求依赖容器依赖 Servlet 容器Tomcat依赖 Spring 容器可以使用 Spring 管理的 Bean执行时机请求进入 Servlet 容器时先执行DispatcherServlet 分发到 Handler 时执行典型用途编码、CORS、日志、压缩登录校验、权限校验、Controller 前置处理执行顺序上也有讲究Filter 一定在 Interceptor 之前执行。因为 Filter 工作在 Servlet 容器层面请求还没有进入 Spring MVC 的世界而 Interceptor 工作在 DispatcherServlet 分发之后hasPermission、preHandle、postHandle、afterCompletion 这些方法都围绕 Handler 执行。在 54 人项目里这个顺序容易被改乱。我见过一个真实案例有人在 Filter 里做了用户权限校验因为某些接口没通过校验导致请求还没进入 Controller 就被拦截了。排查了很久才发现Interceptor 里的校验逻辑根本没执行到因为 Filter 把请求提前“枪毙”了。面试时千万别只说“Filter 和 Interceptor 都是拦请求的”。你要能说出“Filter 先执行Interceptor 后执行Filter 在容器层Interceptor 在 Spring MVC 层Filter 无法获取 HandlerMethodInterceptor 可以精确到方法和注解”。这几点说出来面试官基本就会放行。2.3 鉴权和限流到底应该在哪一层做这一段有个高频追问“既然网关能做鉴权为什么 Filter 和 Interceptor 里还做一遍”答案很现实网关鉴权是粗粒度的业务层的鉴权是细粒度的。网关只能知道请求有没有带 token、token 是否过期但它很难知道这个用户有没有权限操作某个订单。后者往往依赖具体业务数据只有到 Service 层甚至拿到业务对象之后才能判断。我推荐的分层方案是Nginx/网关层做 IP 黑白名单、简单限流、非法 Header 过滤Filter 层做请求日志、TraceID 注入、CORS 处理Interceptor 层做登录态校验、按钮级权限校验、接口幂等性检查AOP 层做方法级埋点、数据权限拦截、操作审计。这个分层不是拍脑袋定的而是遵循“公共能力尽量前置、业务能力尽量后置”的原则。网关层做不了细粒度权限硬塞进去会导致网关变成巨型不可维护的组件业务权限放在 Service 里又太散所以放 Interceptor 和 AOP 比较合适。面试被问“为什么这里放、那里不放”你就按这个逻辑回答基本站得住脚。2.4 这段链路在 54 人项目里特别容易翻车的几个细节第一个是 TraceID 的注入位置。如果 TraceID 是在某个 Filter 里注入那 Filter 之前的链路日志就没有 TraceID排查问题时只能靠时间硬凑。正确做法是在网关层就生成或者透传 TraceID然后用 MDC 把它塞进日志上下文这样整条链路从接入到出口都有同一个标识。第二个是跨域配置的位置。很多人把 CORS 配置写在 Interceptor 或 Controller 里结果发现请求被 Filter 拦了才报跨域。实际 CORS 应该放在 Filter 或者网关这层因为浏览器发起跨域预检请求 OPTIONS 时请求还没有进入 Spring MVC 流程。第三个是参数解析的位置。RequestBody、RequestParam 的解析发生在 HandlerAdapter 里。如果你在 Filter 里读了 body 流到 Controller 里再取 RequestBody 就会报流已关闭的错误。我见过有人为了让 Filter 能解析签名把请求流包装成了自定义 BodyReader结果在 54 人项目里因为没写清注释后面接手的人误删了包装逻辑线上接口直接挂掉。这一段链路方法论就一句话先搞清楚请求在哪些节点被“消费”过再决定在哪一层做公共处理。面试官问得多细你都能接上。3. 第二段事务与一致性链路——从业务方法到数据真正落库3.1 请求走到 Service 之后链路才刚开始如果说前置链路是“请求的入口关卡”那业务处理链路就是“数据的生死线”。面试官问到 Service 层通常会继续追问你的事务加在哪一层缓存是先写还是先删接口幂等怎么实现消息发送失败怎么处理这三连问很考验人因为日常开发里大家经常只关注“功能实现”不关注“链路边界”。我给你一个真实场景用户下单接口Controller 接收请求后调用 OrderService.createOrder()。createOrder 方法上加了 Transactional里面做了三件事扣库存、插入订单、发送订单创建消息。看起来逻辑很清晰但面试官问你“如果扣库存成功了发送消息失败了会发生什么”如果你回答“事务会回滚”那你要再想想——事务回滚只能保证数据库操作回滚但消息如果已经发出去了事务提交失败时 MQ 里已经有一条消息消费者早就开始处理了。这就是典型的分布式事务问题。这条“业务链路”从 Service 方法开始其实已经不只通向 Mapper 了。它同时通向数据库、Redis、MQ、下游服务。链路从“线”变成了“网”这就是第二段最容易被问住的原因。3.2 事务边界定错整个链路都是隐患Transactional 的边界面试必问。经验少的人会把事务注解加到 Controller 方法上或者在 Service 内部方法之间直接调用时发现事务不生效然后一脸懵。先说结论事务注解应该加在业务边界最完整的 Service 公共方法上不要加在 Controller 上也不建议加在私有方法上。原因有几个Spring 事务是基于 AOP 代理实现的只有通过代理对象调用方法时事务注解才会生效Controller 层是接收参数和组装响应的入口把事务放这里会让 Controller 变重还会导致一个控制器方法里包含多步业务操作时事务范围过大Service 内部方法直接调用this.method()不会经过代理对象事务失效。我见过最经典的翻车现场有人在一个事务方法里做了远程 RPC 调用响应特别慢导致整个事务时长被拖到 3 秒以上数据库连接被长期占用最终连接池被打满。这是事务边界过大导致的典型事故。正确的做法是事务方法只包含必须保证原子性的数据库操作像 RPC 调用、MQ 发送这类外部 IO要么放到事务提交之后执行要么放到事务外。面试时你能说出“事务内不做远程 IO外部调用要放事务后”这就比很多人都强。3.3 缓存、消息和 RPC 加进来后链路从“线”变成“网”一个请求到了 Service通常不只是“查库返回”。它会先查 Redis缓存没有再去查库查完写缓存它可能会通过 Feign 调订单服务它可能会向 MQ 发一条消息让下游服务异步处理。这时候链路就开始变得复杂了。面试官最爱问的是缓存和数据库的时序问题。比如更新数据的正确顺序应该是先更新数据库再删除缓存而不是先删缓存再更新数据库。因为先删缓存后更新数据库在高并发下会出现缓存击穿请求 A 删了缓存还没更新库请求 B 查缓存没有就去查库拿到了旧数据回填缓存请求 A 更新库成功。后面所有请求都读到旧缓存数据一致性直接崩了。再比如消息发送在事务里先发消息还是事务提交后发消息如果先发消息事务回滚了下游已经消费了这条消息这就是数据不一致。我建议用事务消息或者事务提交后的发布事件的方案把“发送消息”挂到事务提交成功的回调里保证不会出现“消息发出去了数据库却没改”的情况。RPC 加入链路后还要处理超时和重试。下游服务超时你是直接失败还是重试如果不做幂等重试会导致下游重复扣款、重复下单。所以链路上每个跨服务调用都要考虑幂等键、超时时间、重试次数。这一段你能讲清楚“为什么先更库再删缓存”“为什么消息要在事务提交后发送”“RPC 重试必须配幂等”面试官基本就会觉得你真正处理过复杂项目。3.4 分布式场景下面试官真正想听的是什么说实话两三个服务的场景其实都算不上严格意义的分布式。面试官问你链路他真正想听到的是你对以下问题的理解数据一致性本地事务消息最终一致性怎么配合还是用 Seata 这类分布式事务框架链路可观测TraceID 如何在服务之间透传日志怎么串联故障隔离下游服务挂了你的线程会不会被耗尽熔断器怎么生效幂等设计重复请求进来接口怎么保证只执行一次。“请求链路”这个面试题表面问的是“一条请求怎么走”实际考察的是“你对整个系统边界和稳定性的理解”。所以你在准备的时候不要只准备“Controller 调 ServiceService 调 Mapper”要把事务边界、消息时序、缓存一致性、幂等设计全部纳入“链路”这个叙事框架里。4. 实操三天时间把自己项目的请求链路彻底画清楚4.1 用日志和 TraceID 反推链路很多人说自己项目链路太乱不知道从哪入手。我的办法是不要读代码先看日志。第一步选一个你业务里最有代表性的核心接口比如“用户下单”“创建订单”“提交支付”在测试环境打一次完整请求。第二步在日志系统里按 TraceID 搜索把这次请求的所有日志按时间排出来。你会发现一次请求可能产出了几百条日志它们分布在不同的微服务里但因为共享同一个 TraceID可以被串成一条完整的“时间线”。第三步根据日志里打出的类名和方法名逆向整理出调用顺序。比如日志里先出现 OrderController.createOrder然后是 AuthInterceptor.preHandle再是 OrderServiceImpl.create再是 StockClient.deductStock最后是 OrderMapper.insert。顺着日志走你就得到了真实的链路而不是“我以为的链路”。这一步比看代码效率高非常多尤其适用于 54 人的项目——代码可能已经经过了 N 手修改但日志不会骗你。4.2 一张能扛住追问的链路图画法画链路图有个常见误区画得太宏观只有 Nginx → Gateway → Service → DB 四个框。面试官追问细节你就答不上来。我更推荐“三层穿透画法”。第一层是物理节点第二层是应用节点第三层是代码节点。以“用户下单”为例物理节点浏览器 → Nginx 集群 → 网关服务 → 订单服务节点 → MySQL 集群 / Redis 集群 / MQ 集群应用节点网关路由 → 订单服务的 Filter → Interceptor → Controller → Service → Mapper代码节点JwtTokenInterceptor.preHandle → OrderController.createOrder → OrderServiceImpl.createOrder事务方法 → OrderMapperImpl.insert → RedisTemplate.deleteCache → MqProducer.sendOrderMessage。画完这三层链路里每个环节你都能说出“做了什么事、为什么在这里做、失败怎么处理”面试官基本就没法从通用维度问倒你。4.3 讲链路时的面试表达模板面试回答链路问题时最怕的是东一句西一句。我提供一个可以直接套用的表达结构先讲整体再讲细节最后讲风险和优化。整体请求首先经过 Nginx 和网关完成路由与统

后端面试必问：54人项目请求链路从网关到事务全解析

相关推荐

计算机毕业设计|基于springboot + vue购物商城系统(源码+数据库+文档)

fast-element 的 TrustedTypesPolicy 类型：借助 Trusted Types 筑牢 DOM 安全边界

PHP8 安全开发四大基线实战：口令哈希、SQL 注入防护、XSS 转义与 CSRF 校验全实测

更多资讯

工业电源路径保护：eFuse与TVS阵列协同设计实战

银河麒麟离线安装QGis：依赖闭环与批量部署实战

Kettle实战：学生成绩导入清洗与排名自动化全流程解析

Grok Bot：轻量级数字员工的落地实践与架构设计

Hoppscotch自部署实战：Docker Compose与源码安装详解

华为云AgentArts实战：信贷预审智能体从搭建到调优全链路

今日更新

Agent Skills 完全指南：原理、写法、安装与实战避坑

Agent Skills 实战：从 Genkit 定义到 GKE 部署与排查

Agent Skills 实战：从设计到调试的完整指南

本周精选

CMOS设计三大物理效应：体效应、沟道长度调制与亚阈值导电

微信小程序在线阅读毕设全解析：Java后端+MySQL+避坑实战

Android音频问题五层分析法：从App到Codec的系统化诊断

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？