0

我已经使用 SAM 部署了 API 的 v1。堆栈是 API Gateway、Lambda 和 DynamoDB 表。

Lambda 函数通过该AutoPublishAlias属性进行版本控制。别名是“Live”。每次我部署 v1 的新版本时，我都会获得一个新的 Lambda 版本，并且“Live”别名会更改为指向新版本，例如：

发布前：

Lambda version:
              3 <--- Alias: Live <--- v1 API
              2
              1

发布后：

Lambda version:
              4 <--- Alias: Live <--- v1 API
              3
              2
              1

现在我想部署 v2 但保持部署 v1。

我已经考虑过修改我的招摇以创建具有 /v1 和 /v2 基本路径的路径的方法。我还将创建一个指向 v1 最新版本的“v1”别名，并将该别名用于 /v1 API，例如：

Lambda version:
              5 <--- Alias: Live <--- v2 API
              4 <--- Alias: v1   <--- v1 API
              3
              2
              1

然后AutoPublishAlias将继续在每个新版本上移动“Live”别名，但“v1”别名将保留在原来的位置，例如：

新的 v2 版本

Lambda version:
              6 <--- Alias: Live <--- v2 API
              5
              4 <--- Alias: v1   <--- v1 API
              3
              2
              1

这似乎是合理的，但对 v1 进行错误修复会很困难。我很惊讶我没有在互联网上找到任何关于使用 SAM 进行 API 版本控制（不是 Lambda 版本控制）的讨论。有处理这个的约定吗？

4

1 回答 1

1

我认为没有惯例，每个人都根据自己的需要做自己的事情。

您可以做的一件事是将Lambda Alias资源添加到 SAM 模板并手动将 v1 固定到函数的版本 4：

MyLambdaV1Version:
  Type: AWS::Lambda::Alias
  Properties:
    FunctionName: !Ref MyLambda
    FunctionVersion: 4
    Name: v1

但是，您正确地指出将错误修复版本推送到 v1 会有问题。我建议将 v1 和 v2 拆分为独立的 Cloudformation 堆栈。似乎这可能是可行的，因为您的函数位于 API 网关后面，而且我假设除了提到的错误修复版本之外，v1 的进一步开发已被冻结。

于 2019-01-16T13:40:00.807 回答