介绍下无服务器技术

无服务器技术（Serverless）

核心概念

Serverless 并不是”没有服务器”，而是开发者不需要管理服务器。你只需要写函数，平台负责运行、扩展、运维。

主要分两类：

FaaS（Function as a Service） — 最核心的 Serverless 形态

• AWS Lambda、Google Cloud Functions、Azure Functions
• 你上传一个函数，触发时运行，按实际执行时间计费

BaaS（Backend as a Service）

• 托管数据库（Firebase Firestore）、认证（Auth0）、存储（S3）
• 直接使用第三方服务，不写后端逻辑

Serverless vs 传统部署 vs 容器

最关键的问题：冷启动（Cold Start）

首次调用或长时间空闲后调用：
  平台分配容器 → 加载运行时 → 加载你的代码 → 执行
  ← 这段延迟就是 Cold Start，可能 100ms ~ 数秒 ←

已有运行实例时（Warm Start）：
  直接执行 → 几毫秒

对游戏后端的影响：冷启动是 Serverless 在游戏实时路径中的硬伤。玩家操作响应要求 <50ms，冷启动动辄几百毫秒，完全不可接受。

游戏后端中的适用场景

✅ 适合用 Serverless 的场景

1. 异步触发型任务
   - 玩家购买道具后触发邮件/推送通知
   - 赛季结束后批量结算排名奖励
   - 图片/头像上传后自动压缩处理

2. 低频管理操作
   - 运营后台的数据导出（每天跑一次）
   - 定时清理过期会话数据
   - A/B 测试配置热更新

3. Webhook 处理
   - 第三方支付回调（Apple Pay、Google Play）
   - 社交平台登录回调

4. LiveOps 活动触发
   - 定时开放限时副本（Cron 触发 Lambda）
   - 根据玩家行为触发个性化推送

❌ 不适合的场景

- 游戏实时战斗逻辑（有冷启动 + 无状态）
- WebSocket 长连接（Serverless 不支持保持连接）
- 需要本地缓存/内存状态的服务
- 高频低延迟 API（登录、匹配）

AWS Lambda 工作原理（面试常考）

触发器（API Gateway / SQS / S3 Event）
         ↓
    Lambda 调度器
         ↓
  ┌─── Warm Container ──→ 直接执行（快）
  └─── Cold Start ──────→ 初始化容器 → 加载代码 → 执行（慢）
         ↓
    执行完毕，容器保留一段时间（期待复用）
    超时无调用 → 容器销毁

缓解冷启动的方法：

• Provisioned Concurrency：预先保持 N 个 warm 实例（付费）
• Scheduled Ping：定时触发函数保持 warm（土办法）
• 减小包体积：Lambda 加载更快
• 选合适运行时：Go/Rust 冷启动比 Java/Python 快很多

与 Docker/Kubernetes 的关系

EA JD 把它们并列提到，因为它们是互补而非替代的关系：

Kubernetes 管理的服务（长期运行）：
  - 游戏匹配服务（需要内存状态）
  - WebSocket 网关（需要长连接）
  - 核心 API 服务（高频低延迟）

Serverless 处理的任务（事件驱动）：
  - 支付回调处理
  - 异步数据处理
  - 定时任务

现代游戏后端 = K8s 常驻服务 + Serverless 异步任务

EA 面试怎么答

如果被问到”什么时候用 Serverless”，记住这个判断框架：

“如果一个功能是事件触发、无状态、低频、延迟不敏感的，Serverless 是很好的选择，因为它免去了运维成本、自动伸缩、按需付费。但游戏的核心实时路径，比如匹配、战斗逻辑、长连接，由于冷启动延迟和无状态限制，必须用传统容器服务。”

这个回答体现了 Senior 级别的权衡判断力，而不是简单说”Serverless 好/不好”。

下一个想深挖什么？Docker/Kubernetes 本身？还是继续其他 EA 面试题？