创脉思 Logo

AWS Lambda Bref 层冷启动优化

解读

在国内一线/二线互联网公司的 PHP 面试中，Serverless 话题已从“加分项”变成“必答题”。面试官抛出“Bref 冷启动优化”，并不是想听你背诵官方文档，而是考察四层能力：

  1. 是否真正用 Bref 在生产环境落地过 PHP on Lambda；
  2. 对冷启动（Cold Start）成因的拆解是否体系化；
  3. 能否给出可量化、可落地的优化方案，并权衡成本；
  4. 对国内合规、网络、成本敏感度的认知（如 VPC 内网、CN 区域特性、镜像拉取带宽费用）。

回答时要体现“现象 → 根因 → 指标 → 手段 → 结果”的闭环，最好自带数据（例如“把 3.8 s 降到 680 ms”），并主动提及国内常见的坑：如广州/北京区域 Lambda 镜像仓库出网计费、Bref 运行时层被 GFW 间歇性拉取失败、VPC NAT 流量突增费用等。

知识点

  1. Bref 架构
    • 两层自定义运行时：function 层（bootstrap）+ 扩展层（php-fpm 或 console）
    • 冷启动路径：下载层 → 启动 bootstrap → 拉起 php-fpm → 加载 Composer 自动加载 → 连接数据库/Redis
  2. 冷启动 vs 热启动
    • 冷启动：新容器创建，代码、层、运行时全部重新初始化
    • 热启动：容器复用，仅 request 级别初始化
  3. 国内冷启动主要瓶颈
    • 层 ZIP/容器镜像过大（> 150 MB 解压慢）
    • VPC+NAT 首次建连耗时（TLS 握手+连接池空）
    • 广州/北京区域镜像仓库出网带宽 0.8 元/GB，导致团队倾向把镜像压到最小，反而牺牲缓存命中率
    • 部分公司强制走自建 GitLab Runner 构建，层上传跨 Region 被限速
  4. 优化维度
    • 包体积：bref/bref 层只保留生产扩展，剔除 xdebug、mongodb 等无用扩展；使用 bref-extra 单独打扩展层
    • 预加载：PHP 7.4+ preload 脚本，把 800 个类合并到 1 个 preload.php，实测减少 220 ms
    • 容器镜像：改用 aws/codebuild/standard:5.0 构建 distroless 镜像，最终 38 MB，冷启动 620 ms → 380 ms
    • 预置并发（Provisioned Concurrency，PC）：对 /api/order 等核心接口开 10 个 PC，费用 0.015 美元/小时，国内换算约 80 元/月，可接受
    • 快照加速（Lambda SnapStart）：仅支持 Java，但可借鉴思路：把 php-fpm 父进程 fork 之前的状态做成“伪快照”，通过 tmpfs 缓存 OPcache 文件
    • 连接池预热：在 bootstrap 阶段异步建立 2 条 MySQL 长连接，放入静态数组，首次请求直接复用，减少 90 ms
    • 国内合规：若走金融云，Lambda 尚未上线，需改用函数计算 FC；此时可把 Bref 层思路迁移到 FC Custom Runtime，优化手段同理
  5. 监控指标
    • Init Duration（Lambda Logs）
    • Bref 自定义指标：bref_cold_start=1|0，通过 CloudWatch Embedded Metric Format 上报
    • 国内若用阿里云 SLS，可在 stdout 打印 JSON，再配置日志加工规则，把 cold_start 字段提取成指标

答案

“我在上一家公司用 Bref 把 Laravel 微服务搬到 Lambda，核心接口冷启动 3.8 s，经过三轮优化降到 680 ms，过程如下：

第一轮，瘦身层包。把原本 217 MB 的完整 PHP 镜像拆成两层：运行时层 42 MB，业务代码层 18 MB，合计 60 MB，Init Duration 从 3.8 s 降到 2.1 s。

第二轮，开启 PHP preload。Laravel 800 个类预加载到 OPcache，预热后冷启动再降 220 ms；同时把 bootstrap 阶段的数据库初始化改为异步非阻塞，MySQL 连接耗时从 110 ms 降到 20 ms。

第三轮，对支付接口购买 10 个 Provisioned Concurrency，费用每月 80 元，冷启动直接归零；其余低频接口保留 On-Demand，通过定时事件每 5 分钟触发一次保活，把容器池温度维持在 50%，平均冷启动降到 680 ms。

此外，我们在北京区域遇到镜像拉取被限速的问题，最终把构建流水线迁到宁夏 Region，层上传走内网 S3 Endpoint，彻底解决了层下载超时导致的 10% 冷启动失败率。”

拓展思考

  1. 如果公司预算紧张，无法长期使用 Provisioned Concurrency，如何设计“弹性预热”策略？（提示：结合 CloudWatch 指标+Lambda 异步调用，实现池大小动态调节）
  2. 在国内金融云区域 Lambda 尚未上线的情况下，如何用阿里云函数计算 FC 的 Custom Runtime 复刻 Bref 的优化思路？关键差异点在哪？
  3. PHP 8.4 即将推出 JIT 默认开启，JIT 预热对冷启动是正向还是负向？如何在 bootstrap 阶段把 JIT 缓存序列化到 /tmp，实现跨调用复用？
  4. 当业务需要常驻连接 Kafka/RMQ，Lambda 本身定位“无状态”，如何权衡“连接池”与“冷启动”的矛盾？是否考虑把 Bref 只当作弹性入口，再把耗时任务转给 SQS+EC2 消费组？
题目导航
上一题：阿里云函数计算 PHP 自定义运行时下一题：事件总线 EventBridge 集成