Hello大家好，我们今天继续讨论AWS Lambda的内容。

Lambda函数的版本

Lambda函数的版本和别名是辅助资源，我们可以通过创建这些资源管理函数的部署和调用。

首先，让我们来看一下Lambda 函数版本的概念。您可以使用版本来管理函数的部署。例如，您现在生产环境上运行了一个函数，假设是V1版本，您可以发布一个这个函数的新版本，比如发布V2版本，以用于新版本测试，而不会影响生产环境V1版本的用户。

这里有一个**$LATEST的概念，$LATEST您可以理解成它是最新的“未发布版本”**，当您创建和使用Lambda函数时，您就是在处理$ LATEST版本，您可以一直修改$LATEST直到您满意为止。这是一个可变函数，因为您可以对其进行修改。

然后当修改完成后，您需要发布来使用Lambda函数，这个时候您就需要创建一个版本，比如V1版本。您每次发布函数时，Lambda 都会为函数创建一个新版本。

在您发布版本后，函数的代码和大多数设置都会被锁定，也就是不可改变的了，这也是为了给该版本的用户维持一致的体验，您无法在进行修改。比如一旦发布V1版本，V1版本就无法在修改了。

修改函数后可以通过将其发布为新的版本以投入使用，比如V2、V3等。每一个版本都有各自的ARN，所以您可以单独调用V1版本，也可以单独调用V2版本，或者$LATEST。

那函数版本都包括什么呢？**它包括您的代码以及所有关联的依赖项，调用函数的运行环境，函数的设置以及环境变量等等。**发布函数版本之后，这些都是不可变的，比如如果您想调整内存，您需要创建一个新版本如V2，然后进行发布。

您可以访问每个版本的Lambda函数，当您进行金丝雀测试时会非常有帮助。

Lambda 函数别名

接下来我们来讨论Lambda 函数别名，aliases。

Lambda 别名类似于指向特定函数版本的指针，您可以定义任何您想要使用的别名，比如一些比较常见的别名例子为：开发、测试、生成环境的别名。您可以定义这些别名然后分别将其指向不同的Lambda版本。

每个别名都有唯一的 ARN，而且别名是可以更改指向的，可以更新别名以便指向函数的新的或其他版本。

我们举个的例子，组织一般都会分为开发、生产、测试环境，比如对应我们的3个函数版本，LATEST、V1和V2。然后：

我们可以创建一个DEV的别名，将其指向LATEST版本；

在创建一个TEST别名，将其指向V2版本；

以及创建一个PROD别名，将其指向V1版本。

以上三个别名的ARN都是不同的，这样如果有用户访问DEV别名的ARN时，就会被重定向到LATEST函数版本；访问TEST别名时，就会重定向到V2版本，PROD别名同理。

对于用户的角度，可以访问DEV，TEST和PROD三个别名，重定向到对应的函数版本；然后我们可以更改这三个别名指向我们希望的其他的函数版本。

使用别名可以支持蓝绿部署，可以为Lambda函数分配权重，这样的话访问别名之后就不只是对应一个函数版本了。

比如访问PROD别名时，可以配置将访问的95%的流量指向V1，也就是生成环境的稳定版本；然后将5%的访问流量切到V2版本，用于测试新版本。这是通过配置权重来实现的。

函数别名与API网关

我们继续。

一般情况下，新版本发布都会遵循三个阶段，开发阶段、测试阶段及发布至生产环境。新版本会在开发环境做测试，如果测试确认没问题之后，会先发布到测试环境，通常测试环境会导入生成环境的部分访问流量做测试，如果测试确认没问题，在慢慢将更多的流量导入测试环境的新版本，最终完成新版本的发布。

接下来我们拿一个API网关的环境，来说明下针对不同的阶段函数别名的运用：

这里有一个开发Stage（开发阶段），指向DEV的别名，然后向$LATEST的Lambda函数路由100%的流量。还有一个测试Stage（测试阶段），指向TEST别名，向Lambda函数的V2版本路由100%的流量。生产Stage（生产阶段），指向PROD别名，向Lambda函数的V1版本路由100%的流量。

V2是我们的新版本，假设目前内部已经测试确认了，我们需要将V2版本发布到生产环境，也就是PROD别名。可以通过配置权重将生产的访问量慢慢切换到V2版本。比如配置PROD别名，将95%的流量指向V1，然后将5%的流量指向V2版本。

我们在这个例子中要注意的是，上面这个切换版本的步骤，是发生在Lambda别名级别，我们调整的是PROD别名；

在API网关这一侧，指向的别名一直没有改变，我们不必修改API网关配置。

所以，在上面这种或者类似的场景中，如果我们需要部署和切换不同的函数版本，使用函数别名来进行配置的话就会非常的方便；当有新的函数版本时，我们只需要通过别名配置将流量慢慢切换到新的函数版本，而不需要每次发布时调整API网关的配置。

通过这个例子，希望大家对于函数别名的功能和使用场景有所了解，发布新版本时，使用别名只需要调整别名的指向，而不需要调整其前面的，对于上面这个例子的API网关的配置。

Lambda与CodeDeploy

最后，我们来看一下 Lambda和CodeDeploy。

CodeDeploy可以帮助您实现自动化的Lambda别名的流量转移功能，也就是Traffic shifting功能，如果您使用SAM无服务器应用程序模型来创建，这个功能是直接内置的。

我们来看一下整个的流程：这里有一个PROD别名，以及两个函数版本，V1和V2。V1是当前线上的版本，V2是您刚刚发布的新版本。

假设目前线上都是在访问函数的V1版本，而V2版本0%没有访问量，您希望将V1的访问量慢慢转移到新版本V2，这样完成新版本的上线使用。

注意这里说的不是手动一下切到V2版本，而是通过配置，自动将当前V1版本的100%的访问量，慢慢的按一定百分比转移到新版本V2上。逐步将访问量切换到新版本而不是立刻切换，也是为了当新版本有问题时将影响降到最低。

CodeDeploy就可以帮您实现这个过程。

那多久且每次转移多少百分比的访问量到新的版本呢？这就需要定义部署策略，我们来看一下都有哪些策略： 第一种部署策略为线性的方式，也就是您可以定义每隔N分钟，增加10%的流量，直到100%。比如，Linear10PercentEvery1Minute，定义每1分钟转移10%的访问量到V2版本直到100% 。以及 Linear10PercentEvery2Minutes，定义每2分钟转移10%的访问量到V2版本直到100%， 或者配置为每3分钟以及每10分钟转移10%流量直到100%，以上这些就是线性的方式。

第二种部署的策略为金丝雀方式，您可以选择：Canary10Percent5Minutes ，5分钟切换10%的流量，然后如果没有收到任何错误，切换剩下的所有流量到新版本V2。Canary10Percent10Minutes，或者10分钟切换10%的流量，然后如果没有收到任何错误，切换剩下的所有流量到新版本V2。以及定义15、30分钟，切换10%的流量，然后在切换剩下的所有流量到新版本V2。

第三种部署的策略为All-at-once，这种方式就不会在按照一定的百分比切换访问量了，而是将所有的流量从原来的版本一次性切换到新的版本。

最后我们可以配置Hooks挂钩,在流量转换开始到新版本之前 和 流量转换完成后运行健康检查。

比如我们如果配置了转移前的hook，在部署V2版本时测试此版本函数是否正常；然后当流量转移到新版本V2之后，还会运行一个流量转移后的Hook，确保一切正常，当测试时发现问题时，自动对版本进行回滚，所以这个Hooks挂钩的作用是非常大的。

好的，以上就是我们今天课时的内容，我们讨论了AWS Lambda – 第四部分的内容，希望能够给大家带来帮助。