企业官网建设流程全解析

前阵子帮团队做面试复盘，我发现一个很有意思的现象：候选人聊到请求链路时，翻车率最高的地方，往往不是分布式事务、不是高并发方案，而是很多人天天在写、却从没完整“看见”过的两段路径。第一段是请求进入服务端之前的接入层，第二段是服务内部跨模块协作的调用时序。尤其在一个 54 人共创的中大型项目里，这两段几乎是被不同小组分头维护的，新人手上只有自己负责的那一小块，面试官一问整体链路，就明显接不上。这篇文章我想把这两段的完整走法、常见追问和表达方式都拆开讲一遍，希望能帮正在准备面试、或者刚进大项目组还没串过链路的同学少踩几个坑。

1. 54 人共创项目里的链路痛点：为什么写接口的人讲不清请求去哪了

1.1 团队协作让链路天然缺失“全局图”

54 个人的项目，通常不是按“一个服务从头写到尾”来分工的，而是按业务域切成用户、订单、支付、商品、数据、基建等若干小组。每个小组只维护自己那部分服务，连代码仓库都是分开的。基建组管网关和统一鉴权，交易组管下单核心链路，数据组管异步同步和报表计算，客户端和服务端之间还隔着网关、负载均衡这一大坨基础设施。

在这种组织结构下，链路视角天然就是“残缺”的。你写完一个 Controller 接口，本地启动服务一点就通，因为 IDE 里根本没有 DNS、没有网关、没有注册中心，也不会让你感知到请求在外面转了几圈。我见过不少工作两三年、代码写得也挺利索的同学，被问到“一条请求从浏览器发起，到最后落库，中间到底经过哪些节点”时，只能答出自己那段的 Controller -> Service -> Mapper 三步。这不是技术能力问题，是项目协作方式决定了多数人只拿到了拼图里的一小块。

1.2 面试官真正想验证的不是背诵，是故障定位能力

为什么面试官偏偏爱问请求链路？因为这个问题最能暴露候选人有没有“系统级视野”。在一个几十人的项目里，线上问题往往不是单服务内部 bug，而是跨服务、跨组件的协作问题。用户下单超时，你至少得先判断是浏览器到网关慢了、网关路由出问题了、还是订单服务自身慢、再或者是下游库存服务把请求拖住了。如果脑子里没有一张完整的链路地图，线上出问题时就只能在自己的一亩三分地里瞎猜，定位效率会差很多。

所以面试官听你讲链路时，真正在验证的是三件事：你知不知道请求经过哪些节点；每个节点各自负责什么、可能出现什么问题；出了异常时你靠什么手段去快速定位。背不背得出网关用的什么框架反而没那么重要，关键是你有没有那个“全局排查”的思维习惯。这也是为什么 54 人项目里出来的候选人，如果能把链路讲清楚，通常会被高看一眼——因为这意味着他能跨组协作、能独立处理复杂问题。

1.3 统计下来，大家最容易卡的其实是这两段

我把最近一段时间面试记录翻了一下，最容易让候选人卡住、说不上来、或者开始含糊其辞的，集中在两段：

• 接入层：从浏览器输入 URL，到请求真正到达业务服务之间的那段路，包括 DNS 解析、负载均衡、网关路由、鉴权限流。很多后端同学天天跟 Controller 打交道，但这段完全在 SpringBoot 的视野之外，他们没碰过，也没有动机主动去了解。
• 服务间协作层：请求到了一个服务之后，如果需要跨模块调用其他服务，完整时序是什么——注册中心怎么拿到实例、连接怎么复用、超时和重试怎么处理、什么时候走同步 RPC、什么时候丢消息队列、熔断降级在什么环节生效。很多人只会告诉你要调这个接口，但说不清调用的完整生命周期和取舍逻辑。

后面的内容，我就把这两段一条一条拆开讲。都是我在真实项目和面试复盘里反复见到的细节，不是理论堆砌。

2. 第一段卡壳：请求从浏览器到服务端，接入层链路是怎么走的

2.1 浏览器侧：从地址栏回车到建立连接，DNS 这环就有人含糊

接入层的第一步其实在浏览器里就开始了。你在地址栏输入域名回车，浏览器不会直接发起 HTTP 请求，它得先知道这个域名对应哪台服务器。这个过程叫 DNS 解析。

解析顺序大致是：浏览器缓存 -> 操作系统 hosts / 系统 DNS 缓存 -> 本地 DNS 服务器 -> 权威 DNS 服务器，逐级递归查询。每一个环节都有缓存，TTL 就是缓存的有效时间。很多候选人知道 DNS 会解析出 IP，但说不出项目里通常不是直接拿 IP 访问，而是解析出一个“入口 VIP”。在 54 人这种规模的项目里，公网域名一般解析到云负载均衡或者机房入口的 VIP，内网服务之间则走内部域名，解析到内网负载均衡的地址。

真实项目里，DNS 这里是有坑的。比如 DNS 缓存时间设置太长，线上切 IP 时用户会一直访问旧地址；设置太短，又会导致解析压力大。一般在入口切换场景下，我们会先调低 TTL 等流量自然切换，再改 DNS 记录。这个细节面试官如果追问“你们怎么平滑切流量”，答得上来说明你是真处理过，不是背流程。

紧接着是 TCP 连接和 HTTPS 握手。HTTP 本身跑在 TCP 之上，HTTPS 又多了一层 TLS 握手。TLS 1.2 一次完整握手通常要两三个 RTT，TLS 1.3 优化成一个 RTT 左右。这也解释了为什么很多前端优化要做会话复用、TLS 握手缓存——因为每多一个网络往返，在弱网环境下都是肉眼可见的延迟。这一段看起来偏网络基础，但实际上它就是请求链路的第一公里，讲不清楚后面全白搭。

2.2 入口负载：静态资源走 CDN，动态请求先过四层还是七层？

请求拿到入口 IP 之后，第一个进入的往往是负载均衡层。这里很多人开始混淆：CDN、四层负载、七层转发到底是什么分工。

先分清静态和动态。像图片、JS、CSS 这类静态资源，通常不会每次都打到后端服务，而是由 CDN 在全国各地节点缓存，用户就近取。CDN 缓存没命中时才回源到中心。动态接口这类不能被缓存的内容，才走完整的负载均衡链路到后端服务。

负载均衡层本身又分两段。四层负载工作在传输层，只管连接级别转发，它不看 HTTP 内容，只看 IP 和端口，典型代表是 LVS 这类方案。四层的好处是吞吐高、转发快，缺点是没法做更细粒度的路由。七层负载工作在应用层，能解析 HTTP 报文，按照域名、URL、Header 做更聪明的转发，典型代表是 Nginx。大流量项目通常是四层在前、七层在后，先快速分发连接，再细粒度路由到不同服务集群。

这些组件在项目里往往不是你写的，但面试官问“请求到了机房/云环境后第一跳是什么”，你不能只说“经过负载均衡”。你要能说清楚为什么四层在前、七层在后：四层只看网络层的四元组，性能开销小，适合扛住海量新建连接；七层要解析协议，能做的事情多，但并发能力弱一些，需要放在后面做精细化分流。一前一后，各有分工，这才是完整理解。

2.3 网关的“最后一公里”：路由、鉴权、限流谁先谁后

网关是接入层里业务属性最重的一环，也是后端同学相对容易感知到的部分。很多人知道网关能做路由，但网关的处理逻辑不止路由一项。典型顺序一般是：先做身份认证，再做资源鉴权，然后才是限流，最后路由转发。为什么这个顺序有讲究？因为认证和鉴权是安全前置，不能让未登录的请求打到下游去消耗业务资源；限流要放在路由之前，否则流量已经转发到业务服务再限流就晚了。

真实项目里网关还会承担不少杂活：灰度发布按用户标签路由、Body 大小限制、请求头清洗、统一超时设置、记录访问日志。这里经常被问住的一个点是“限流怎么做”。本地限流和分布式限流是不同的，单机版拿 Guava RateLimiter 只能每台实例单独记数，集群场景下发压时流量会不均匀地分摊到每台，必须依靠 Redis 计数器或网关集中式限流才能在集群维度生效。面试官想听的往往不只是“用了什么组件”，而是你理解限流需要全局视角，也要知道限流的阈值要根据下游承受能力来定，不是随便拍脑袋写个 1000 QPS。

2.4 这一段的 30 秒口述版本，背下来就能救场

如果面试官让你简单说下“请求到后端之前发生了啥”，我建议你用固定结构：一层一层往下走，每层一句话职责加一个关键参数。按我这个模板来：

浏览器先做 DNS 解析拿到入口 VIP，TTL 控制缓存时间；请求进入四层负载均衡，按连接分发到一组 Nginx；Nginx 根据域名识别业务，转发到对应网关集群；网关完成鉴权、限流后，从注册中心拿到下游服务实例列表；最后通过 RPC 客户端选择一台实例发起调用。

这段话讲完大约三十秒，但已经把接入层的全部关键节点都覆盖了。如果面试官再追问每个节点的细节，你再往里填参数和坑。最怕的是开口就跳进 Controller，直接把前面那一整段给省略了。

3. 第二段卡壳：一次跨服务调用，完整的时序与取舍是什么

3.1 RPC 调用的完整时序：服务发现、连接复用、超时重试

接入层讲完，请求终于进到业务服务内部了。但如果这个业务需要调用另一个团队的服务，新的一段又开始了。很多候选人对“调用接口”的理解简化成了四个字：发出请求、拿到响应。但实际上，现代微服务架构里一次正常的 RPC 调用远不止这一步。

以服务 A 调用服务 B 为例，完整时序是这样的：A 先从注册中心获取 B 的服务实例列表，这个列表通常会缓存到本地并定时拉取，不会每次调用都问一次注册中心；拿到列表后，客户端要选择一个实例发起调用，这一步叫客户端负载均衡，常见的策略有随机、轮询、一致性哈希，也可以按机房优先；选定实例后，如果连接池里没有可用连接，要先建连，建完的连接会复用；然后才是真正发送请求、等待响应。

这里面最容易答不上来的是超时和重试。超时时间设多少？设太短，下游慢一点的正常请求就被误杀；设太长，线程池会被卡死的调用占满，拖垮整个服务。重试策略更讲究，如果是查询类接口，重试一两次通常安全；如果是下单、支付这类非幂等写操作，盲目重试就可能造成重复订单。真实项目里我就见过因为默认开了重试，导致下游超时时同一条请求被执行两次的线上事故。讲链路时把这个例子带出来，面试官会觉得你对“链路”不是停留在图画层面，而是真被它咬过。

3.2 不是所有调用都是同步的：RPC、HTTP 与 MQ 的取舍

只有同步调用，不能叫完整的请求链路。一个中型业务请求里，往往是同步调用和异步投递混在一起。

比如用户下单这个场景：订单服务的核心逻辑里，扣减库存是同步 RPC，因为必须当场确定有没有库存；发送短信通知是异步的，即使通知失败也不影响用户下单成功；记录审计日志可以丢到消息队列里，甚至可以允许它失败重推。这种混合模式的设计意图，是把实时性强、必须等待结果的环节留在同步链路里，把时效性要求低、允许异步的环节用 MQ 削峰解耦。

面试官追问“为什么这里用 MQ 不用直接调接口”时，核心要答出三点：解耦、削峰、失败缓冲。如果不经过 MQ，订单服务和下游一堆系统直接耦合，每加一个订阅方就要改订单服务代码；大促高峰期瞬间流量打到下游，下游服务很可能扛不住；MQ 天然把消息暂存在队列里，消费方按自己的节奏处理，即使某一瞬间消费不过来也没关系。

3.3 大流量下的保护机制：限流、熔断、降级各自的归属

链路长了之后，任意一个环节挂了都可能拖垮上游。所以面试里关于链路的高频追问一定是：你这条链路拿什么机制保护自己。

限流最常见的落点是在接入层和网关层，因为这里看得见全量流量，适合在入口处挡住过载。熔断则是调用方的自我保护，比如服务 A 调 B，连续错误率达到阈值，A 就快速失败不再发请求给 B，让 B 有时间缓过来。降级是业务层面的兜底，比如推荐服务挂了，可以用热门榜单顶上；支付渠道超过预期时，可以禁用非核心支付方式，保证主流程可用。

这三者的触发逻辑面试官尤其爱深挖。随口说“我们有熔断”是扣分的；你要能说清楚熔断状态机是怎么流转的：正常态 -> 熔断态 -> 半开态，半开状态下放少量请求去试探下游是否恢复，成功了重新回到正常态。阈值怎么设，一般按错误比例和时间窗口来定，也要结合下游的真实承受能力。这里面最加分的表述是：熔断保护的不只是自己的系统，也保护下游不被继续压垮，是一种团队协作层面的容错设计。

3.4 事务边界与数据一致性问题：链路里最容易被忽略的一环

很多人画链路图画的是节点和箭头，画到数据库就停了。但真正在生产环境里，链路走到数据层才是事故最密集的地方。跨服务之后，本地数据库事务管不到别人的数据库，分布式事务就成了必须面对的问题。

这里不需要把两阶段提交、Seata 那一整套都背出来，但你得知道常见取舍。简单可靠的方案是本地消息表或基于 MQ 的事务消息：把本地业务操作和发消息放在同一个本地事务里，消息发出后由订阅方异步执行后续操作，最终达到一致。相比之下，同步 RPC 加分布式事务方案的实时性强，但实现复杂、性能损耗大，适合对一致性要求极高的极少数场景。

我在讲链路时一般会特意加一句话：从 A 到 B 调用，不一定意味着两步写入必须同时成功，要看你最在意的是实时一致还是最终一致。这句话一出来，面试官就知道你对数据层的链路思考过，而不是只盯着接口通没通。

4. 面试里加分的链路细节：traceId 贯穿全链路与线程上下文传递

4.1 traceId 是怎么贯穿整条链路的

前面讲的还都是“静态链路”，真正的生产级链路还必须有一套“动态追踪”手段。最常见的实现就是 traceId。一个请求从进入系统开始，会被分配一个全局唯一的请求号，然后在同一条请求链路的每一次服务调用、每一次日志打印、每一次中间件访问中，都把这个请求号带在身上。这样出了问题，用这个 ID 就能把散落在几十台机器上的日志拼成一张完整的调用时序图。

traceId 的传递有两层。跨服务时，它靠 RPC 框架自动把上下文塞进请求头，服务端接住后继续往下传。在服务内部，它放进 ThreadLocal 或日志框架的 MDC 里，当前线程的每行日志都会自动带上这个 ID。实现起来倒不难，难点在于边界场景，特别是线程池切线程的时候。

下面是一个自定义线程池包装器的核心思路，我简化过，实际工程里通常用统一的“链路上下文透传”工具类来封装：

public class TraceThreadPoolExecutor extends ThreadPoolExecutor { @Override public void execute(Runnable command) { String traceId = TraceContext.get(); super.execute(() -> { try { TraceContext.set(traceId); command.run(); } finally { TraceContext.clear(); } }); } }

关键点是：把父线程的 traceId 在提交任务那一刻取出来，子线程执行前再放进去，执行完清掉。如果不做这一层包装，线程池里异步执行的代码日志就没有 traceId，整条链路在日志平台里就断了。这也是“看起来接入了全链路监控，但实际链路还是断的”最常见原因之一。

4.2 一次真实的线上排查：靠 traceId 十分钟定位 vs 没有 tag 查半天

我印象很深的一次线上事故，用户反馈下单流程偶发超时。直接在日志平台按用户维度搜索，只能看到一个成功、一个失败，无法判断到底哪一环拖慢了。后来根据请求 Header 里的 traceId 查调用关系，才发现链路里有一步调用下游 Redis 集群的耗时有 800 多毫秒，而正常值不到 5 毫秒。顺着这个 traceId 再查，发现那一分钟的 Redis 节点网络出现了抖动，连带着把整个下单链路拖慢了。

这种问题在 54 人共创的项目里尤其难查，因为日志分布在几十个服务里，每个服务各自维护数据库和日志索引，没有 traceId 串联就只能靠猜。所以链路不只是“面试题”，它更是大规模团队的生存工具。你讲链路的时候，如果能主动提到 traceId 对故障定位的价值，面试观感会立刻不同。

4.3 链路治理的落地细节：光接入监控还远远不够

全链路追踪不是把 SDK 引进去就完事了。我见到过不少项目，traceId 在正常同步链路中传递良好，但一遇到异步就断：HTTP 调用时上游忘了把 traceId 写进 Header，事件监听消费时没有把消息体里的 traceId 还原进 MDC，日志打印不规范导致同一链路里的关键步骤没有输出埋点。这些都是要踩过坑才知道的。

比较务实的建议是：接入全链路监控后，自己先拿一个真实请求从头到尾在日志平台里点名一遍，看跟踪视图是不是连续的、每跳耗时是否清晰、异步分支有没有断点。这个动作非常简单，但绝大多数项目没人做。面试时如果你能说出“我们专门验证过异步线程池场景下的 traceId 透传”，对面基本就知道你是真正参与过链路治理的人。

5. 把链路讲得“避坑且加分”的口述方法：我复盘出的三个层面

5.1 三层链路记忆法：接入层、服务间层、数据层

对于没完整参与过全链路的同学，我建议用“三层记忆法”来组织回答，不管项目多复杂，都把链路拆成接入层、服务间层、数据层。接入层讲 DNS、CDN、负载均衡、网关；服务间层讲服务发现、RPC、MQ、缓存、限流熔断降级；数据层讲数据库、Redis、搜索引擎以及事务边界。

每一层不要贪多，秉持“职责 + 选型 + 一个坑”的小结构。比如接入层的网关，一句话说明职责是统一入口处理鉴权限流，选型可以是自研也可以是成熟网关框架，坑就是限流必须考虑分布式而非本地单机。这样一段一段讲下来，层次清楚、信息量大，面试官也容易跟。

这个方法还有一个好处：即使你确实只熟悉其中一层，其他两层不熟，你也可以诚实地把不熟的地方标记出来，然后基于“最可能怎么设计”做合理推断。面试官要的往往不是你全都会，而是你有逻辑、有体系、知道每一层应该承担什么职责。

5.2 面试前怎么快速补齐自己团队的链路盲区

如果时间有限，推荐三个动作。第一，找到你们项目的入口配置和网关代码，哪怕不细读，也要搞清楚请求从域名进来以后，经过了哪几个组件才到业务服务。第二，挑一个你自己业务里最核心的接口，从日志平台里拉一次完整调用的 traceId，把这次调用的每一跳都记录下来，遇到不认识的节点就问对应团队的人。第三，把这条链路用文字写出来，每个箭头旁边标一个潜在的失败点。

我给团队做过一个简单的 onboarding 任务：新人入职第一周，要求独立口述一遍“用户下单请求的完整链路”，说不清的地方就是要补齐的文档盲区。这个做法效果意外地好，因为链路一旦被真的追问到底，很长一群人会发现自己并不懂自己参与的系统的全貌。

5.3 最常见的踩坑点：只讲正常路径，不提失败场景

回答链路问题时，一个很大的败笔是全程只讲“一路畅通”的情况。真实系统里绝大多数链路问题都发生在异常分支：下游超时怎么办、缓存穿透怎么办、MQ 消费失败重试几次、熔断后是否走降级逻辑。面试官后面往往跟着一句“这里挂了怎么办”，其实就是想把你从正常路径拉进异常路径看看反应。

所以讲链路的正确方式，是每走一段都主动附一句“这里有坑”。说到网关就提限流拦截，说到 RPC 就提超时重试的幂等风险，说到缓存就提穿透击穿的兜底策略。这比到最后被问一句再尴尬地补上要高好几个档次。我见过一个候选人，链路讲得并不比其他人快，但每到一个节点都会自然地加一句“这个地方我们之前出过什么事故、怎么修的”，面试官全程都在点头。

回顾这些年带人和被面试的经历，我越来越觉得请求链路不是一道“八股题”，而是一面照妖镜，照出你对自己所在系统的掌控程度。54 人共创的项目里，没有人天生掌握全局，但能不能通过主动追问、看文档、跑 traceId 把缺失的链路拼完整，很大程度上决定了一个人在大项目里能走多远。如果你也想验证自己，挑一个核心接口，拿 traceId 在日志平台里从头到尾点名一遍，然后试着不用看笔记，把这条链路讲给旁边的人听。卡住的地方，就是你需要补课的地方。