一次请求从网关到函数再返回，通常要经过DNS解析、接入层转发、网关校验、触发器调度、函数执行、响应回写这六个核心环节。其中任何一环出问题，都会直接表现为接口变慢或超时，这篇文章把这六个环节拆开，讲清每一站做了什么、花在哪、怎么排查。
一次请求从网关到函数再返回要走过哪些环节
先从一个具体的场景说起,你在浏览器里点了某个按钮，前端代码向 https://api.example.com/order/create 发起了一个请求，这个请求从点击到拿到结果，要经历下面这几个步骤。
DNS解析：每个请求的第一道闸口
请求发出前,首先要通过DNS把 api.example.com 解析成IP地址，这一步跟快递员查小区地图一样，查到了才知道往哪个门走，大多数客户端和运营商DNS都有缓存，所以这一步通常很快，但如果是首次访问或者缓存过期，就可能需要消耗几十到几百毫秒。
接入层建连：TCP和TLS握手
拿到IP之后,客户端要和服务器建立TCP连接，在HTTPS场景下还要完成TLS握手，这一步在长连接复用的场景下几乎不耗时，但如果连接断开重建，网络往返（RTT）的成本就会显现，跨地域调用时，RTT对请求耗时的贡献不容忽视。
API网关的校验与路由
请求到达网关之后,网关会按顺序做几件事：
- 识别这个请求对应的是哪个API
- 校验签名、Token或API Key
- 检查IP黑白名单和应用鉴权
- 判断当前是否触发限流或熔断规则
- 把请求头和参数做合法性校验
- 按路由规则把请求转发给后端服务
网关本身是纯逻辑处理,正常情况下耗时通常在几毫秒到十几毫秒之间，但如果配了复杂的鉴权逻辑或者访问了外部鉴权服务，这个环节就可能被拉长。
函数计算平台的触发器匹配
请求从网关转发出去后,到达函数计算平台，平台需要判断这个HTTP请求应该交给哪个函数处理，在简米云函数计算中，这一步是通过HTTP触发器或自定义域名映射来完成的（据简米云官方帮助文档），网关把HTTP请求翻译成函数的入参事件，这个转换过程很快，但涉及实例调度问题。
这里需要注意同步调用和异步调用的区别,它们的返回链路完全不同：
| 场景 | 调用方式 | 返回路径 |
|---|---|---|
| 前端调后端API | 同步调用 | 客户端→网关→函数→网关→客户端 |
| 事件触发任务 | 异步调用 | 网关→函数→写入结果存储，客户端另行查询 |
| 消息队列触发 | 异步调用 | 触发器直接调用函数，不经过API网关 |
同步调用才是你理解的“来回一遍”的模式，异步调用属于另说。
函数的冷启动与执行
函数计算平台收到调用请求后,会检查当前是否存在可复用的函数实例，如果有，直接执行；如果没有，需要拉起一个新的运行环境，也就是常说的冷启动。
冷启动要完成的事情包括：拉取代码包、启动运行时、初始化执行环境，这个过程涉及资源调度，所以耗时波动很大，函数执行完成后，结果再沿着原路返回客户端。
请求经过网关几次
正常情况下,一次同步请求从客户端到函数、再返回客户端，请求经过网关只有一次，网关处理完请求后，会把请求转发给函数计算平台，平台内部自行调度函数实例，不会再绕回网关。
但有些情况下你会看到同一个请求被网关处理了多次：
客户端超时重试
如果函数执行时间较长,超过客户端设置的超时时间，客户端会主动断开，然后发起重试，重试的请求会再次经过网关，对网关而言，这算两次独立请求，但来源是同一个业务动作。
5xx错误重试
部分客户端和服务框架默认会对5xx错误做重试,当函数返回异常，网关透传5xx状态码后，客户端自动发起第二次请求，这种场景在微服务架构中相当常见。
网关里的重定向逻辑
个别网关配置会返回302重定向,比如强制跳转到HTTPS或新域名，浏览器会自动重新发起一次请求，这一来一回就产生了两次网关调用。
遇到网关响应慢的具体场景
如果发现某个接口“走了两遍网关”，先不要怀疑架构问题，打开网关访问日志，按 requestId 和 clientIp 去过滤同一个时间窗口的请求记录，把重试前和重试后的两个请求关联起来看，一般能在几秒内定位到是哪一段触发了重试。
网关和函数计算如何分工
很多团队初次从服务器架构转向函数计算时,容易混淆网关和函数计算的职责边界。
API网关和函数计算的区别
一句话概括：API网关管流量入口，函数计算管业务逻辑
。
用物业来打个比方,API网关是小区大门口的保安和前台，负责核实身份、登记访客、指路、控制人流，函数计算是小区里各栋办公楼里具体办事的窗口，真正的工作是在这里完成的，前台不关心你进来办什么业务，只负责把人带对地方；办公楼也不关心你是谁，只处理递进来的材料。
具体区别可以看这张表：
| 对比项 | API网关 | 函数计算 |
|---|---|---|
| 核心职责 | 请求接入、鉴权、限流、路由 | 业务代码执行、运行环境管理 |
| 计量方式 | 按调用次数和公网流量 | 按资源规格和实际运行时间 |
| 扩容方式 | 网关层弹性伸缩 | 函数实例弹性伸缩 |
| 关注指标 | QPS、延迟、错误率、并发 | 冷启动、执行时长、内存使用 |
| 典型配置 | 域名、证书、签名密钥 | 运行环境、内存大小、超时时间 |
服务网格和API网关在入口层有部分功能重叠,但在函数计算架构中，API网关仍然是最主流的流量入口，服务网格更聚焦在东西向通信的治理上，二者互补但不冲突。
一次调用往返哪里最耗时
搞清楚了链路结构,下一步就是定位延迟，以同步调用为例，一次往返的耗时由以下几个部分相加：
- 客户端到网关的RTT
- 网关处理耗时
- 网关到函数计算平台的RTT
- 函数冷启动或实例调度耗时
- 函数代码实际执行耗时
- 函数返回结果到网关的RTT
- 网关返回响应给客户端的RTT
据信通院发布的云原生白皮书,多数在线业务的延迟瓶颈集中在网络往返和函数执行两个环节，其中网络往返相对固定，函数执行则因业务复杂度而异。
函数计算冷启动多久会让接口变慢
行业共识认为,冷启动是函数计算场景下最直接的性能变量，冷启动的耗时与几个因素相关：
- 函数代码包的大小,包越大拉取越慢
- 运行时类型,Java较重，Node.js和Python较轻
- 是否配置了VPC网络,进入VPC的初始化流程会更长
- 函数实例规格,内存越大启动通常越快
通常情况下,轻量运行时冷启动在几百毫秒量级，Java等重型运行时可能到秒级，如果对延迟敏感，预留实例或预置并发是主流解法提前把实例拉起，请求来了直接执行。
API网关响应慢怎么排查
具体排查操作,按照下面的路径走，可以快速定位问题出在哪一段：
- 登录云API网关控制台,找到目标API的“访问日志”或“调用日志”
- 按请求时间定位到具体那条调用,复制它的
requestId - 打开函数计算控制台的“日志查询”，按
requestId过滤函数日志 - 对比网关日志里记录的“后端耗时”和函数日志里记录的“执行耗时”
后端耗时小于函数执行耗时,说明瓶颈在网关到函数之间这跳网络上；两者接近，说明函数本身执行慢；后端耗时远大于函数执行耗时，大概率是函数实例冷启动或调度等待。
如果网关和后端日志都正常,但客户端体验依然很慢，那就得查客户端到网关这一段链路，打开链路追踪服务，把整个调用链拉出来，从接入层开始一段段看耗时分布，实际操作中，多数“很慢”的案例最后都落在函数执行逻辑或者冷启动上，网关本身反倒不太容易成为瓶颈。
关于请求和网关调用的常见问题
API网关日志怎么查？
在云控制台打开API网关服务,进入“调用日志”或“日志分析”页面，设置时间范围，输入API名称或请求路径，就能查出对应记录，每一条日志都包含完整的请求信息，包括 requestId、状态码、后端耗时、总耗时和错误信息，需要更长时间的日志存储，可以在日志服务中配置网关日志投递。
函数计算冷启动多久可以接受？
判断标准取决于业务对延迟要求,一般Web API接口的P99延迟目标大多在1秒以内，冷启动能控制在200毫秒以内，基本不影响体验；超过500毫秒，前端就能明显感知卡顿，对延迟敏感的生产业务，直接用预留实例，规避冷启动带来的波动。
请求经过网关返回慢，一定就是网关的问题吗？
不一定是网关卡住了,响应慢可能发生在链路的任意一段：DNS解析慢、客户端与服务端之间的网络RTT高、函数实例冷启动、业务代码执行久、返回包体过大都会导致整体耗时长，正确做法是用 requestId 串联网关日志和函数日志，分段对比耗时，先定位再优化。
理解一次请求从网关到函数再返回走过的完整链路,比背任何调优口诀都管用，下次遇到接口慢，直接按链路分段查日志，每一段耗时对上号，问题就藏不住。