AWS Lambda – 函数版本,别名,API网关,CodeDeploy协同

AWS Lambda – 函数版本,别名,API网关,CodeDeploy协同_第1张图片

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

Lambda函数的版本
AWS Lambda – 函数版本,别名,API网关,CodeDeploy协同_第2张图片

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

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

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

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

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

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

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

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

Lambda 函数别名
AWS Lambda – 函数版本,别名,API网关,CodeDeploy协同_第3张图片

接下来我们来讨论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网关
AWS Lambda – 函数版本,别名,API网关,CodeDeploy协同_第4张图片

我们继续。

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

接下来我们拿一个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
AWS Lambda – 函数版本,别名,API网关,CodeDeploy协同_第5张图片

最后,我们来看一下 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 – 第四部分的内容,希望能够给大家带来帮助。

你可能感兴趣的:(AWS,SAP认证,aws,云计算,aws认证,saa,sap,lambda)