最近面试了几家公司，Serverless相关的问题被问了很多。本文整理了面试中被问到的Serverless面试题，包括概念原理、架构设计、性能优化、成本控制、安全问题、实际案例等，附上我的回答思路和经验，希望对准备面试的朋友有帮助。

一、概念和原理类

问题1：什么是Serverless？它和传统架构有什么区别？

这是最基础的问题，几乎每场面试都会问。

我的回答思路： Serverless（无服务器架构）是一种云计算执行模型，开发者不需要管理服务器，只需要写函数代码，部署到云平台，云平台自动管理资源的分配、扩缩容和运维。

Serverless主要包含两部分：

  • FaaS（Function as a Service，函数即服务）：把代码拆成一个个函数，按事件触发执行，比如AWS Lambda、阿里云函数计算
  • BaaS（Backend as a Service，后端即服务）：把后端能力封装成服务，直接调用，比如对象存储、数据库、消息队列、身份认证

和传统架构的区别：

  1. 服务器管理：传统架构需要自己买服务器、装环境、部署、运维；Serverless不需要管服务器，云平台全托管
  2. 扩缩容：传统架构需要手动或自动扩缩容，有延迟；Serverless自动扩缩容，毫秒级响应，请求来了自动分配资源
  3. 计费方式：传统架构按服务器规格和使用时长计费，不管有没有请求都要花钱；Serverless按实际执行时间和请求次数计费，没有请求不花钱
  4. 状态管理：传统架构可以在服务器内存中保存状态；Serverless函数是无状态的，状态需要存在外部存储（数据库、缓存）中
  5. 冷启动：传统架构服务器一直运行，没有冷启动问题；Serverless函数长时间没有请求会被回收，再次调用需要冷启动，有延迟

问题2：Serverless的优缺点是什么？

优点：

  1. 降低运维成本：不需要管理服务器，运维工作量大大减少
  2. 弹性伸缩：自动扩缩容，能应对突发流量，不需要提前规划容量
  3. 按需付费：按实际使用量计费，没有请求不花钱，成本低
  4. 快速上线：只需要写函数代码，不需要管基础设施，开发效率高
  5. 事件驱动：天然支持事件驱动架构，适合异步处理、数据管道等场景

缺点：

  1. 冷启动延迟：函数长时间不调用会被回收，再次调用需要冷启动，延迟从几十毫秒到几秒不等
  2. 执行时间限制：函数有最大执行时间限制（通常5-15分钟），不适合长任务
  3. 调试困难：本地调试和云端环境有差异，分布式调试比较困难
  4. 厂商锁定：不同云厂商的Serverless实现和API不同，迁移成本高
  5. 状态管理复杂：函数无状态，需要依赖外部存储，增加了架构复杂度
  6. 监控和可观测性：函数调用链路长，传统的监控工具不适用，需要专门的可观测性方案

问题3：什么是冷启动？怎么优化冷启动？

冷启动是Serverless最核心的问题之一，面试必问。

冷启动的过程：

  1. 平台收到函数调用请求
  2. 分配一个新的执行环境（容器或微虚拟机）
  3. 下载函数代码和依赖
  4. 启动运行时（Node.js、Python、Java等）
  5. 加载函数代码
  6. 执行函数初始化代码
  7. 处理请求

冷启动的时间从几十毫秒（简单的Node.js函数）到几秒（Java、.NET等重运行时）不等。

优化冷启动的方法：

  1. 减少代码包大小：只打包必要的依赖，删除无用文件，代码越小下载越快
  2. 选择轻量级运行时：Node.js、Python比Java、.NET冷启动快很多
  3. 预留实例/预置并发：云厂商提供预留实例功能，提前初始化好执行环境，避免冷启动，但要额外付费
  4. 定时预热：用定时任务定期调用函数，保持函数处于活跃状态，避免被回收
  5. 初始化代码优化：把耗时的初始化操作（如数据库连接）放在函数外部，只初始化一次，复用连接
  6. 分层部署：把不常变化的依赖打包成层（Layer），只在第一次下载，后续调用复用
  7. 选择合适的内存规格：内存越大，CPU越强，冷启动越快，但成本也越高，需要权衡

二、架构设计类

问题4：什么样的场景适合用Serverless？什么样的不适合？

适合的场景：

  1. 事件驱动的异步处理：比如消息队列消费、文件上传处理、定时任务、Webhook处理
  2. API后端：RESTful API、GraphQL API，尤其是请求量波动大的场景
  3. 数据管道：数据ETL、流处理、日志处理、数据清洗
  4. 物联网后端：设备消息处理、规则引擎、告警通知
  5. 聊天机器人和技能：对话处理、意图识别、回复生成
  6. 图片和视频处理：图片压缩、缩略图生成、视频转码、水印添加
  7. 定时任务和CRON：定时报表、数据备份、定时清理

不适合的场景：

  1. 长任务：函数有执行时间限制，超过限制的任务不适合，比如超过15分钟的批量处理
  2. 高并发低延迟要求：对延迟非常敏感的场景，冷启动可能无法满足要求
  3. 有状态的长连接：WebSocket、长轮询等需要保持连接的场景，Serverless函数执行完就结束了，不适合
  4. 需要常驻内存的应用：比如需要在内存中缓存大量数据的应用，函数无状态，不适合
  5. 传统的单体应用：大型的、复杂的单体应用，不适合拆成函数，迁移成本高，收益小
  6. 对厂商锁定敏感的场景：如果需要多云部署或随时迁移，Serverless的厂商锁定问题需要慎重考虑

问题5：怎么设计一个Serverless架构的系统？

这是一个开放性问题，考察架构设计能力。

我的回答思路： 设计Serverless架构，要遵循以下原则：

  1. 函数粒度要合理

- 不要把所有逻辑都放在一个函数里，也不要拆得太细 - 一个函数做一件事，职责单一 - 按业务领域拆分，比如用户函数、订单函数、支付函数 - 粒度太粗，冷启动慢，部署影响大；粒度太细，调用链长，调试困难

  1. 无状态设计

- 函数本身不保存状态，状态存在外部存储 - 数据库连接要复用，不要每次调用都新建连接 - 用Redis等缓存存储会话和临时状态 - 函数执行环境可能被复用，要注意全局变量的清理

  1. 事件驱动设计

- 用事件解耦各个函数，函数之间通过消息队列、事件总线通信 - 同步调用链不要太长，尽量用异步处理 - 设计好事件的格式和版本，便于扩展

  1. API网关统一入口

- 用API网关统一管理API，负责路由、鉴权、限流、缓存 - 函数只负责业务逻辑，不处理通用的横切关注点 - API网关可以做请求聚合，减少前端调用次数

  1. 数据存储选择

- 结构化数据用云数据库（RDS、云原生数据库） - 非结构化数据用对象存储（S3、OSS） - 缓存用Redis - 搜索用Elasticsearch - 根据数据特点选择合适的存储，不要什么都存在一个数据库里

  1. 错误处理和重试

- 函数要设计成幂等的，重复执行不会产生副作用 - 异步调用要有重试机制，但要注意重试风暴 - 设计死信队列，处理失败的消息 - 要有降级和熔断机制，避免级联失败

  1. 可观测性

- 完善的日志记录，每个函数的入参、出参、执行时间都要记录 - 分布式追踪，跟踪请求在多个函数之间的调用链路 - 监控指标：调用次数、错误率、执行时间、冷启动次数 - 告警机制，异常情况及时通知

举个例子，设计一个电商订单系统的Serverless架构：

  • API网关接收下单请求
  • 鉴权函数验证用户身份
  • 订单函数创建订单，写入数据库
  • 发送消息到消息队列
  • 库存函数消费消息，扣减库存
  • 支付函数消费消息，发起支付
  • 通知函数消费消息，发送订单确认短信和邮件
  • 数据分析函数消费消息，写入数据仓库做统计

这样的架构，每个函数职责单一，通过事件解耦，弹性伸缩，按需付费。

三、性能优化类

问题6：Serverless函数的性能怎么优化？

这是高频问题，考察实际优化经验。

我的回答思路：

  1. 冷启动优化（前面已经详细讲过，这里简要提一下）

- 减少代码包大小 - 选择轻量级运行时 - 预留实例和定时预热 - 优化初始化代码

  1. 执行性能优化

- 数据库连接池：在函数外部初始化连接池，复用连接，避免每次调用新建连接。注意连接池大小要合适，避免连接数过多压垮数据库 - 缓存优化：用Redis缓存热点数据，减少数据库查询。函数执行环境复用时，可以用内存缓存，但要注意缓存失效 - 并发处理：IO密集型操作用异步并发处理，比如同时调用多个接口、同时查询多个数据，用Promise.all或asyncio.gather - 代码优化：优化算法，减少不必要的计算，避免阻塞事件循环 - 内存规格选择：内存越大，CPU越强，执行越快，但成本越高。要做性能测试，找到性价比最高的内存规格

  1. 架构层面优化

- 函数拆分：把耗时的操作拆成异步函数，主函数快速返回 - 边缘计算：把静态资源和简单逻辑放到CDN边缘节点，减少回源 - 请求聚合：在API网关层做请求聚合，减少函数调用次数 - 批量处理：把多个小请求合并成一个批量请求，减少函数调用次数和冷启动次数

  1. 数据库优化

- 合理设计索引，避免慢查询 - 读写分离，读请求走从库 - 分库分表，应对大数据量 - 用云原生数据库，自动扩缩容

问题7：Serverless的并发限制是怎么回事？怎么应对？

云厂商对Serverless函数有并发限制，比如单个函数最大并发数是1000，账号总并发数是某个值。超过并发限制的请求会被限流（返回429错误）。

并发限制的原因：

  • 保护云平台的资源，避免单个用户占用过多资源
  • 保护下游服务，避免函数并发过高把数据库或其他服务打垮

应对并发限制的方法：

  1. 申请提高配额：如果业务需要更高的并发，可以向云厂商申请提高并发限制
  2. 排队和限流：在API网关层做排队和限流，平滑请求，避免突发流量打满并发
  3. 异步处理：把非实时的请求改成异步处理，先返回接受，后台慢慢处理
  4. 批量处理：把多个小请求合并成批量请求，减少并发数
  5. 预留并发：购买预留并发，保证一定的并发能力
  6. 多函数拆分：把流量分散到多个函数，避免单个函数并发打满
  7. 下游保护：对数据库和其他下游服务做连接池限制和熔断，避免被打垮

四、成本控制类

问题8：Serverless的成本怎么计算？怎么优化成本？

Serverless的成本主要包括：

  1. 函数执行费用：按请求次数和执行时间（GB-秒）计费，执行时间 = 内存规格 × 执行时长
  2. 触发源费用：API网关、消息队列、对象存储等触发源的费用
  3. 数据传输费用：出网流量费用，不同云厂商定价不同
  4. 其他服务费用：数据库、缓存、日志服务等配套服务的费用

成本优化的方法：

  1. 优化执行时间：执行时间越短，费用越低。优化代码、减少不必要的操作、用缓存减少计算
  2. 选择合适的内存规格：内存越大，单位时间费用越高，但执行可能更快。要测试不同内存规格的总费用，找到最优解。有时候内存大一点，执行快很多，总费用反而更低
  3. 减少冷启动：冷启动的执行时间也算费用，减少冷启动能降低成本
  4. 代码包优化：代码包小，下载快，冷启动快，也能节省费用
  5. 合理使用免费额度：大部分云厂商有免费额度，小流量应用可能完全免费
  6. 避免重复调用：设计幂等函数，用缓存和去重，避免重复执行
  7. 异步处理：非实时的任务用异步处理，可以用更低的优先级和更便宜的资源
  8. 监控和分析：分析函数的调用次数、执行时间、费用分布，找到费用高的函数，针对性优化
  9. 预留实例：稳定的负载可以用预留实例，比按需调用便宜，但要根据实际负载选择，避免浪费

五、安全类

问题9：Serverless的安全问题有哪些？怎么防护？

Serverless虽然不需要管理服务器，但安全问题依然存在，而且有其特殊性。

常见的安全问题：

  1. 函数代码漏洞：代码中的注入漏洞、XSS、反序列化漏洞等，和传统应用一样
  2. 依赖包漏洞：函数依赖的第三方包可能有漏洞，需要定期扫描和更新
  3. 权限过大：函数的执行角色权限过大，一旦被入侵，能访问过多资源
  4. 事件注入：恶意构造的事件数据，可能导致函数执行非预期操作
  5. 敏感信息泄露：代码中硬编码密钥、密码，或者日志中打印敏感信息
  6. 拒绝服务：恶意调用函数，导致费用暴增（经济拒绝服务）
  7. 多租户隔离：云平台的多租户环境，可能存在侧信道攻击的风险

防护措施：

  1. 最小权限原则：给函数分配最小必要的权限，只允许访问需要的资源
  2. 输入验证：对所有输入（事件数据、API参数）做严格的验证和过滤
  3. 依赖管理：定期扫描依赖包的漏洞，及时更新有漏洞的版本
  4. 敏感信息管理：用密钥管理服务（KMS、Secrets Manager）存储敏感信息，不要硬编码在代码中
  5. 代码安全审计：上线前做代码安全审计，用SAST工具扫描漏洞
  6. 限流和配额：设置函数的并发限制和调用配额，防止恶意调用导致费用暴增
  7. WAF防护：在API网关前加WAF，防护SQL注入、XSS等常见攻击
  8. 日志审计：记录所有函数调用，定期审计，发现异常行为
  9. 加密：传输用HTTPS，存储用加密，敏感数据加密存储

六、实际案例和经验类

问题10：你在实际项目中用过Serverless吗？遇到过什么坑？

这是考察实际经验的问题，要结合自己的经历回答。

我分享几个我遇到过的坑：

坑1：数据库连接数打满

我们用Serverless做API后端，函数里连接MySQL数据库。刚开始没注意连接池的问题，每个函数实例都建了几个连接，高并发的时候，函数实例数暴增，数据库连接数瞬间打满，导致数据库崩溃。

解决方法：

  • 用数据库代理（如RDS Proxy），管理连接池，函数连接代理，代理连接数据库
  • 减小函数内的连接池大小，每个实例只建1-2个连接
  • 对数据库做读写分离，读请求走从库
  • 用Redis缓存热点数据，减少数据库查询

坑2：冷启动导致接口超时

我们有一个接口，用Java写的函数，冷启动时间要3-4秒。用户第一次调用的时候经常超时，体验很差。

解决方法：

  • 把Java函数改成Node.js，冷启动时间降到几百毫秒
  • 配置预留实例，保证一定数量的实例始终处于活跃状态
  • 用定时任务预热，每分钟调用一次函数，保持活跃
  • 优化初始化代码，减少启动时的操作

坑3：函数执行超时

我们有一个批量处理数据的函数，数据量大的时候，执行时间超过了15分钟的限制，函数被强制终止，导致数据处理不完整。

解决方法：

  • 把大任务拆成小任务，用消息队列分批处理
  • 用状态机（Step Functions）编排多个函数，处理长流程
  • 把批量处理改成流处理，数据来一条处理一条
  • 对于确实需要长时间运行的任务，用容器服务（ECS、K8s）而不是Serverless

坑4：本地调试和云端不一致

本地用模拟器调试的时候一切正常，部署到云端后出现各种问题：路径不对、权限不够、环境变量缺失、依赖版本不一致。

解决方法：

  • 用云厂商提供的官方CLI和本地调试工具，尽量模拟云端环境
  • 用Docker容器做本地调试，保证环境一致
  • CI/CD流水线中加入测试环节，部署前自动测试
  • 完善的日志和监控，出问题能快速定位

坑5：厂商锁定

我们最开始用了某云厂商的Serverless，深度集成了他们的消息队列、数据库、对象存储等服务。后来因为成本和业务原因，想迁移到另一个云，发现迁移成本非常高，几乎要重写一遍。

解决方法：

  • 尽量用开源的、标准化的技术，减少对厂商专有服务的依赖
  • 用框架抽象层，比如Serverless Framework，把函数代码和厂商-specific的配置分离
  • 设计时考虑可移植性，业务逻辑和云服务解耦
  • 如果确定要长期用某朵云，可以深度集成，享受平台红利，但要清楚锁定的代价

七、写在最后

Serverless是云计算的发展趋势，越来越多的公司在采用。面试中Serverless的问题也越来越多，从基础概念到架构设计，从性能优化到成本控制，从安全防护到实际经验，都可能被问到。

准备Serverless面试，不能只背概念，还要有实际项目经验，理解Serverless的优势和局限，知道什么场景该用、什么场景不该用，遇到问题能分析和解决。

希望这篇面试题整理能帮到正在准备面试的你。如果你有其他Serverless面试题或者更好的回答思路，欢迎在评论区交流。

最后想说，技术面试不只是考察知识，更是考察思维方式和解决问题的能力。理解了原理，有了经验，不管遇到什么问题，都能从容应对。