关于阿里云:如何用一个插件解决-Serverless-灰度发布难题

导读

本文适宜：

想理解 Serverless 灰度公布的同学。

认为以后 Serverless 灰度公布配置太简单，寻求简洁版灰度公布流程的同学。

想理解 Serverless Devs 组件和插件之间关系的同学。

Serverless 灰度公布

什么是 Serverless ?

Serverless 顾名思义就是无服务器，它是一种“来了就用，功能齐全，用完即走”的全新计算提供形式，用户无需预制或治理服务器即可运行代码，只需将代码从部署在服务器上，转换到部署到各厂商 Serverless 平台上；同时享受 Serverless 按需付费，高弹性，低运维老本，事件驱动，降本提效等劣势。

什么是 Serverless 灰度公布？

灰度公布又称为金丝雀公布 (Canary Deployment)。过来，矿工们下矿井前，会先放一只金丝雀到井内，如果金丝雀在矿井内没有因缺氧、气体中毒而死亡后，矿工们才会下井工作，能够说金丝雀爱护了工人们的生命。

与此相似，在软件开发过程中，也有一只金丝雀，也就是灰度公布（Gray release）：开发者会先将新开发的性能对局部用户凋谢，当新性能在这部分用户中可能安稳运行并且反馈侧面后，才会把新性能凋谢给所有用户。金丝雀公布就是从不公布，而后逐步过渡到正式公布的一个过程。

那么对于部署在 Serverless 平台上的函数应该怎么进行灰度公布呢？

下文将以阿里云函数计算 FC 为例，为各位开展介绍。

灰度公布有一个流程，两种形式。

一个流程

Serverless 灰度公布是通过配置别名来实现的，别名能够配置灰度版本和主版本的流量比例，在调用函数时应用配置好的别名即可将流量按比例发送到相应版本。

配置灰度公布的流程如下：

1. Service 中公布一个新版本。
2. 创立或更新别名，配置别名关联新版本和稳固版本，新版本即为灰度版本。
3. 将触发器 (Trigger) 关联到别名。
4. 将自定义域名 (Custom Domain) 关联到别名。
5. 在调用函数中应用别名，流量会按配置比例发送到新版本和稳固版本。

传统做法的两种形式

1、阿里云控制台 web 界面：

a. 公布版本

b. 创立别名

c. 关联触发器

d. 关联自定义域名

2、应用 Serverless Devs cli

a. 公布版本

s cli fc version publish --region cn-hangzhou --service-name fc-deploy-service --description "test publish version"

b. 创立别名并设置灰度

s cli fc alias publish --region cn-hangzhou --service-name fc-deploy-service --alias-name pre --version-id 1 --gversion 3 --weight 20

c. 关联触发器

须要到控制台配置

d. 关联自定义域名

须要到控制台配置能够看到，应用控制台或 Serverless Devs 进行灰度公布流程中的每一步，都须要用户亲自操作。并且因为配置繁多，极易出错。除了这些弊病以外，客户困扰的另一个问题是应用灰度公布策略十分不不便。

常见的灰度公布策略有 5 种：

1. 1. CanaryStep: 灰度公布，先灰度指定流量，距离指定工夫后再灰度残余流量。
   2. LinearStep：分批公布，每批固定流量，距离指定工夫后再开始下一个批次。
   3. CanaryPlans：自定义灰度批次，每批次设定灰度流量和间隔时间，距离指定工夫后依照设定的流量进行灰度。
   4. CanaryWeight：手动灰度，间接对灰度版本设置对应的权重。
   5. FullWeight: 全量公布，全量公布到某一版本。

这些灰度策略中，前三项都须要配置间隔时间，而用户在控制台或者应用 Serverless Devs 工具去配置灰度都没有方法通过主动程序来配置间隔时间，不得不通过闹钟等形式揭示用户手动进行下一步灰度流程，这个体验是十分不敌对的。上面咱们介绍个可能帮您一键灰度公布函数的插件：FC-Canary。

基于 Serverless Devs 插件 FC-Canary 的灰度公布

为了应答以上问题，基于 Serverless Devs 的插件 FC-Canary 应运而生，该插件能够帮忙您通过 Serverless-Devs 工具和 FC 组件实现函数的灰度公布能力，无效解决灰度公布时参数配置繁冗、须要开发人员亲自操作以及可用策略少等问题。

（内容配置及注意事项 - 局部截图）

具体流程请见：https://github.com/devsapp/fc…。

FC-Canary 的劣势

1、FC-Canary 反对超简配置

用户最短只需在 s.yaml 中减少 5 行代码代码即可开启灰度公布性能。

2、FC-Canary 配置指引简略清晰:

3、FC-Canary 反对多种灰度策略

• 灰度公布，先灰度指定流量，距离指定工夫后再灰度残余流量。

此时流量变动为：20% 流量到新版本，10 分钟后 100% 流量到新版本

• 手动灰度，指定时间接将灰度版本设置对应的权重。

此时为 10% 流量到新版本，90% 到稳固版本

• 自定义灰度，以数组的形式配置灰度变动。

此时流量变动为：10% 到新版本 -> (5 分钟后) 30% 流量到新版本 -> (10 分钟后) 100% 流量到新版本

• 分批公布，一直累加灰度比例直到 100% 流量到新版本。

流量变动：40% 到新版本 -> (10 分钟后) 80% 流量到新版本 -> (再 10 分钟后) 100% 流量到新版本

• 全量公布，100% 流量发到新版本

FC-Canary 插件反对上述 5 种灰度策略，用户抉择所需策略并进行简略配置，即可体验一键灰度公布。

4、FC-Canary 灰度阶段提醒清晰

插件对每一个里程碑都会以 log 的形式展示进去，给开发者足够的信念。

5、FC-Canary 反对钉钉群组机器人揭示

配置钉钉机器人即可在群中收到相干揭示，例如：

FC-Canary 最佳实际

应用 FC-Canary 插件灰度公布 nodejs 12 的函数。

代码仓库：

https://github.com/devsapp/fc…

初始化配置

• 代码配置

• yaml 配置

咱们采纳 canaryWeight 的灰度策略：灰度公布后，50% 的流量到新版本，50% 的流量到旧版本。

进行第一次公布

1. 执行公布

在 terminal 中输出: s deploy –use-local

2. 查看后果

命令行输入的 log 中能够看到：

因为是第一次公布，我的项目中不存在历史版本，所以即便配置了灰度公布策略，FC-Canary 插件也会进行全量公布，即流量都发送到版本 1。

批改代码，第二次公布

1. 在第二次公布前，咱们批改一下代码，让代码抛出谬误。

2. 执行公布

在 terminal 中输出: s deploy –use-local

3. 后果

命令行输入 log 中能够看到：

第二次公布，利用了灰度公布策略，即  50% 流量发送到版本 1, 50% 的流量发送到版本 2。

测试

获取 log 中输入的 domain，拜访 domain 100 次后查看控制台监控大盘。

能够看到调用了函数 100 次，谬误的函数有 49 次，正确的函数有 100 – 49 = 51 次，正确和谬误的函数都约占总调用数的 50%。

剖析：函数版本 1 为正确函数，函数版本 2 为谬误函数，咱们的灰度配置为流量 50% 到版本 1，50% 到版本 2，所以调用过程中，谬误函数和正确函数应该各占 50%，图中后果合乎咱们的假如，这证实咱们的灰度策略是胜利的。

总结

咱们能够发现相比应用控制台进行灰度公布，应用 FC-Canary 插件免去了用户手动创立版本、公布别名、关联触发器和治理自定义域名的麻烦，应用起来十分不便。

引申浏览

Serverless Devs 组件和插件的关系

• 组件是什么？

依据 Serverless Devs Model v0.0.1 中阐明，组件 Component: 是由 Package developer 开发并公布的合乎 Serverless Package Model 标准的一段代码，通常这段代码会在利用中被援用，并在 Serverless Devs 开发者工具中被加载，并依照预约的规定进行执行某些动作。例如，将用户的代码部署到 Serverless 平台；将 Serverless 利用进行构建和打包；对 Serverless 利用进行调试等。

举个例子：

如果想要应用 Serverless Devs 治理阿里云函数计算的函数计算资源，则须要在 yaml 配置文件中申明阿里云 FC 组件，之后便能够应用阿里云 FC 组件的能力。

FC 组件能够提供治理阿里云函数计算资源的能力，包含：治理服务、函数、版本、别名 等性能。组件地址：https://github.com/devsapp/fc

• 插件是什么？

插件作为组件的补充，提供组件的原子性功能。

举个例子：

1. 应用 FC 组件 deploy 的性能部署函数，能够在部署完结后采纳 FC-Canary 插件对部署的函数进行灰度公布。
2. 应用 FC 组件 deploy 的性能部署函数，能够在部署开始前采纳 layer-fc 插件来升高部署过程中上传代码的耗时：即 layer-fc 能够让函数间接应用公共依赖库（近程）中的依赖，从而在部署时不再须要上传这些近程存在的依赖。

• 组件和插件的关系？

• 在 Serverless Devs Model 中，组件是占据外围位置，插件是辅助位置，也就是说，插件的目标是晋升组件能力，提供给组件一些可选的原子性功能。
• Serverless Devs 治理组件和插件的生命周期，如果是 pre 插件，则会让其在组件执行前执行，反之，post 插件则会在组件后实现一些收尾工作。
• 一个组件能够同时应用多个插件, 其中组件插件的执行程序是：

1. 1. 插件依照 yaml 程序执行，前一个插件的执行后果为后一个插件的入参
   2. 最初一个 pre 插件的输入作为组件的入参
   3. 组件的输入作为第一个 post 插件的入参

相干概念

• FC 函数 (Function) 是系统调度和运行的单位，由函数代码和函数配置形成。FC 函数必须从属于服务，同一个服务下的所有函数共享一些雷同的设置，例如服务受权、日志配置。函数的相干操作，请参见 治理函数。函数计算反对事件函数和 HTTP 函数两种函数类型，对于二者的区别，请参见 函数类型。
• 服务 (Service) 能够和微服务对标 (有版本和别名)，多个函数能够独特组成服务单元。创立函数前必须先创立服务，同一个服务下的所有函数共享一些雷同的设置，例如服务受权、日志配置。
• 触发器 (Trigger) 的作用是触发函数执行的。函数计算提供了一种事件驱动的计算模型。函数的执行能够通过函数计算控制台或 SDK 触发，也能够由其余一些事件源来触发。您能够在指定函数中创立触发器，该触发器形容了一组规定，当某个事件满足这些规定，事件源就会触发关联的函数。
• 自定义域名 (Custom Domain) 是函数计算提供为 Web 利用绑定域名的能力。
• 版本 (Version) 是服务的快照，包含服务的配置、服务内的函数代码及函数配置，不包含触发器，当公布版本时，函数计算会为服务生成快照，并主动调配一个版本号与其关联，以供后续应用。
• 别名 (Alias) 联合版本，帮忙函数计算实现软件开发生命周期中的继续集成和公布。

最初，欢送大家一起来奉献更多的开源插件！

参考链接：

Serverless Devs：

https://github.com/Serverless…

FC 组件地址：

https://github.com/devsapp/fc

FC-Canary 插件具体信息及其应用请参考：

https://github.com/devsapp/fc…

FC 函数治理：

https://help.aliyun.com/docum…

FC 函数类型：

https://help.aliyun.com/docum…