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。正确的做法是:修复代码 → 发布新版本 → 更新别名指向新版本。这保证了版本链的完整性。
版本与别名关系架构图 版本与别名关系架构 函数 myFunc 版本 1 (v1) 版本 2 (v2) 版本 3 (v3) 别名: prod 别名: staging 别名: canary 别名是可变指针,可指向单个版本或按权重分配流量到多个版本

2.4 流量路由基础

别名支持权重路由,允许将一定比例的流量导向不同版本。这是实现灰度发布、A/B 测试、蓝绿部署的基础能力。

权重路由示例

假设函数当前有版本 3(稳定版)和版本 5(新功能版),通过别名 prod 配置如下权重:

# 别名 prod 的流量路由配置
版本 3: 90% 权重
版本 5: 10% 权重

此时,每 100 次调用中,约 90 次命中版本 3,10 次命中版本 5。平台根据请求 ID 的哈希值进行一致性路由,确保同一用户的请求始终路由到同一版本(如果用户 ID 参与哈希)。

关键指标:权重总和必须为 100%。如果只配置一个版本,则默认为 100% 流量。
别名流量路由流程 别名流量路由流程 客户端请求 别名: prod 权重 版本 3 (90%) 版本 5 (10%) 权重路由基于请求哈希,保证同一用户请求的一致性

2.5 版本与别名对比总结

对比维度 版本(Version) 别名(Alias)
可变性 不可变 可变(可随时切换指向)
标识方式 数字编号(1, 2, 3…) 自定义名称(prod, staging…)
流量路由 不支持 支持权重路由
使用场景 发布历史、回滚基线 环境管理、灰度发布
调用方式 funcName:1 funcName:prod