如何最优雅地部署 AWS Lambda？Lambda Version 与 Alias 的最佳实践

序言

在日常开发中，我们经常需要对 AWS Lambda 进行代码更新，最常见的方法是直接修改代码并点击"部署"按钮。这种方式虽然简单快捷，但存在诸多问题，比如无法追踪代码变更、容易误操作导致生产事故等。因此，我们需要一种更安全、更高效的 Lambda 部署方式。

本篇文章将介绍如何利用 Lambda Version 和 Lambda Alias 进行版本管理，并结合 Blue/Green 部署，实现更稳定的 Lambda 代码管理。

常见的 Lambda 部署方式及其问题

常见的 Lambda 部署方式

许多开发者习惯于以下方式部署 AWS Lambda：

在 AWS 控制台直接修改 Lambda 代码。
点击"部署"按钮。
进行测试，若无问题，则部署完成。

这种方式的缺陷

虽然这种方式简单直观，但存在以下问题：

代码版本不可追踪：没有版本管理，一旦代码被覆盖，很难回溯。
修改过于随意：任何人都可以直接修改代码，容易引入问题。
误操作风险大：不小心修改代码可能会导致线上故障，且难以回滚。

因此，我们需要一种更加 系统化、可追溯 的 Lambda 部署方式。

更优雅的 Lambda 部署方式：利用 Lambda Version 和 Alias

Lambda Version（版本管理）

AWS Lambda 允许我们为每个代码变更创建一个版本（Version），这样即使代码发生变化，旧版本仍然可以被调用。

Lambda Version 关键特性：

版本是不可变的（Immutable），一旦创建，无法修改。
版本号是递增的整数（v1, v2, v3...）。
每个版本都有唯一的 ARN（Amazon Resource Name）。
默认版本 $LATEST：表示最新代码，每次修改后都会更新。
版本包含代码和环境配置，但不能修改。
不会额外增加费用。

Lambda Alias（别名管理）

Lambda Alias 是 Lambda 版本的"指针"，可以指向特定版本，类似于数据库中的软链接。

Lambda Alias 关键特性：

Alias 可以指向不同的 Lambda 版本。
Alias 是可变的（Mutable），可以随时修改其指向的版本。
支持 Canary 部署（蓝绿部署） ：通过 weight 参数控制流量分配，例如 90% 指向 v1，10% 指向 v2。
每个 Alias 都有一个 ARN，可用于 API Gateway、EventBridge 等触发器。
不会额外增加费用。

Lambda Version + Alias 的优势

✅ 可回滚 ：遇到问题时可以快速切换回旧版本。 ✅ 避免误操作 ：直接修改 $LATEST 可能影响生产环境，而版本管理可避免此问题。 ✅ 实现蓝绿部署 ：可以逐步将流量切换到新版本，确保新代码稳定。 ✅ 支持 A/B 测试：可以将不同用户请求引导到不同版本进行测试。

实战：使用 Lambda Version 和 Alias 进行部署

1. 创建 Lambda 函数

在 AWS Lambda 控制台中，创建一个 Node.js 的 Lambda 函数，默认配置即可。

示例代码（v1 版本）：

javascript 复制代码

export const handler = async (event, context) => {
  const version = 1; // 初始版本
  return {
      statusCode: 200,
      body: JSON.stringify('API service version ' + version),
  };
};

部署后，测试是否能正确返回 API service version 1。

2. 创建 Lambda 版本（Version）

在 Lambda 控制台：

进入 Lambda 函数页面。
点击"版本"，选择"发布新版本"。
该版本会被分配一个版本号（例如 1）。

3. 创建新的 Lambda 版本（v2）

修改 Lambda 代码，更新 version = 2：

javascript 复制代码

export const handler = async (event, context) => {
  const version = 2;
  return {
      statusCode: 200,
      body: JSON.stringify('API service version ' + version),
  };
};

然后，再次创建一个新版本 （此时版本号应为 2）。