2. 版本与别名基础
在 Serverless 应用交付与运维中,版本(Version)与别名(Alias)是控制函数代码稳定性和流量路由的核心抽象。理解这两个概念及其不可变性原理,是进行版本差异校验的前提。
2.1 版本(Version)概念
版本是函数代码与配置在某一时刻的不可变快照。每次发布新版本时,平台会为函数生成一个递增的数字版本号(如 1、2、3…),并锁定该版本的代码、环境变量、运行时、内存大小等所有配置。
| 属性 | 说明 | 示例 |
|---|---|---|
| 版本号 | 自动递增的整数,从 1 开始 | 1、2、3 |
| 不可变性 | 发布后代码与配置不可修改 | 版本 2 的代码永远不变 |
| 独立 ARN | 每个版本拥有唯一资源标识符 | arn:xxx:function:myFunc:2 |
| 生命周期 | 可长期保留,无自动过期 | 版本 1 可保留数年 |
最佳实践:每次通过 CI/CD 流水线部署新代码时,都应生成一个新版本。不要覆盖已有版本,以保留完整的发布历史。
2.2 别名(Alias)概念
别名是指向特定版本或版本组合的可变指针。通过别名,团队可以在不修改调用方代码的情况下,切换函数指向的版本。别名通常用于环境标识(如 dev、staging、prod)或灰度发布。
| 别名 | 指向版本 | 流量权重 | 用途 |
|---|---|---|---|
prod |
版本 3 | 100% | 生产环境稳定版本 |
staging |
版本 4 | 100% | 预发布验证 |
canary |
版本 3(90%)+ 版本 5(10%) | 90% / 10% | 灰度测试新版本 |
2.3 版本不可变性原理
版本不可变性是 Serverless 平台保证可追溯性与可复现性的核心机制。一旦版本发布,其代码、依赖、配置均被冻结,任何修改都必须通过创建新版本实现。
- 代码冻结:版本发布后,函数代码包被哈希锁定,无法原地更新。
- 配置锁定:环境变量、超时时间、内存大小等配置随版本固化。
- 依赖快照:运行时与层(Layer)的版本也被记录,确保环境一致。
- 审计溯源:每个版本对应一次部署事件,可精确回滚到任意历史版本。
常见误区:不要试图通过修改已有版本来修复 Bug。正确的做法是:修复代码 → 发布新版本 → 更新别名指向新版本。这保证了版本链的完整性。
2.4 流量路由基础
别名支持权重路由,允许将一定比例的流量导向不同版本。这是实现灰度发布、A/B 测试、蓝绿部署的基础能力。
权重路由示例
假设函数当前有版本 3(稳定版)和版本 5(新功能版),通过别名 prod 配置如下权重:
# 别名 prod 的流量路由配置
版本 3: 90% 权重
版本 5: 10% 权重
此时,每 100 次调用中,约 90 次命中版本 3,10 次命中版本 5。平台根据请求 ID 的哈希值进行一致性路由,确保同一用户的请求始终路由到同一版本(如果用户 ID 参与哈希)。
关键指标:权重总和必须为 100%。如果只配置一个版本,则默认为 100% 流量。
2.5 版本与别名对比总结
| 对比维度 | 版本(Version) | 别名(Alias) |
|---|---|---|
| 可变性 | 不可变 | 可变(可随时切换指向) |
| 标识方式 | 数字编号(1, 2, 3…) | 自定义名称(prod, staging…) |
| 流量路由 | 不支持 | 支持权重路由 |
| 使用场景 | 发布历史、回滚基线 | 环境管理、灰度发布 |
| 调用方式 | funcName:1 |
funcName:prod |