如何用一个插件解决 Serverless 灰度发布难题？

导读

本文适合：

• 想了解 Serverless 灰度发布的同学。
• 认为当前 Serverless 灰度发布配置太复杂，寻求简洁版灰度发布流程的同学。
• 想了解 Serverless Devs 组件和插件之间关系的同学。

Serverless 灰度发布

什么是 Serverless ?

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

什么是 Serverless 灰度发布？

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

与此类似，在软件开发过程中，也有一只金丝雀，也就是灰度发布（Gray release）：开发者会先将新开发的功能对部分用户开放，当新功能在这部分用户中能够平稳运行并且反馈正面后，才会把新功能开放给所有用户。金丝雀发布就是从不发布，然后逐渐过渡到正式发布的一个过程。

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

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

灰度发布有一个流程，两种方式：

一个流程

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

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

• Service 中发布一个新版本。
• 创建或更新别名，配置别名关联新版本和稳定版本，新版本即为灰度版本。
• 将触发器 ( Trigger ) 关联到别名。
• 将自定义域名 ( Custom Domain ) 关联到别名。在调用函数中使用别名，流量会按配置比例发送到新版本和稳定版本。

传统做法有两种方式

阿里云控制台 web 界面：

发布版本

创建别名

关联触发器

关联自定义域名

使用 Serverless Devs cli

发布版本

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

创建别名并设置灰度

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

关联触发器

需要到控制台配置

关联自定义域名

需要到控制台配置

可以看到，使用控制台或 Serverless Devs 进行灰度发布流程中的每一步，都需要用户亲自操作。并且由于配置繁多，极易出错。 除了这些弊端以外，客户困扰的另一个问题是使用灰度发布策略非常不方便。

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

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-canary。

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-canary/tree/main/example/singleFunc-http

初始化配置

代码配置

yaml 配置

我们采用 canaryWeight 的灰度策略：灰度发布后，50%的流量到新版本，50%的流量到旧版本。

进行第一次发布

执行发布

在terminal中输入: s deploy --use-local

查看结果

命令行输出的 log 中可以看到：

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

修改代码，第二次发布

在第二次发布前，我们修改一下代码，让代码抛出错误。

执行发布

在terminal中输入: s deploy --use-local

结果

命令行输出 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

插件是什么？

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

举个例子：

使用 FC 组件 deploy 的功能部署函数，可以在部署结束后采用 FC-Canary 插件对部署的函数进行灰度发布。

使用 FC 组件 deploy 的功能部署函数，可以在部署开始前采用 layer-fc 插件来降低部署过程中上传代码的耗时：即 layer-fc 可以让函数直接使用公共依赖库（远程）中的依赖，从而在部署时不再需要上传这些远程存在的依赖。

组件和插件的关系？

在 Serverless Devs Model 中，组件是占据核心地位，插件是辅助地位，也就是说，插件的目的是提升组件能力，提供给组件一些可选的原子性功能。

Serverless Devs 管理组件和插件的生命周期，如果是 pre 插件，则会让其在组件执行前执行，反之，post 插件则会在组件后完成一些收尾工作。

一个组件可以同时使用多个插件, 其中组件插件的执行顺序是：

插件按照 yaml 顺序执行， 前一个插件的执行结果为后一个插件的入参

最后一个 pre 插件的输出作为组件的入参

组件的输出作为第一个 post 插件的入参

相关概念：

FC函数 (Function) 是系统调度和运行的单位，由函数代码和函数配置构成。FC函数必须从属于服务，同一个服务下的所有函数共享一些相同的设置，例如服务授权、日志配置。函数的相关操作，请参见 管理函数。函数计算支持事件函数和HTTP函数两种函数类型，关于二者的区别，请参见 函数类型

服务 (Service) 可以和微服务对标 ( 有版本和别名 )，多个函数可以共同组成服务单元。创建函数前必须先创建服务，同一个服务下的所有函数共享一些相同的设置，例如服务授权、日志配置。

触发器 (Trigger) 的作用是触发函数执行的。函数计算提供了一种事件驱动的计算模型。函数的执行可以通过函数计算控制台或SDK触发，也可以由其他一些事件源来触发。您可以在指定函数中创建触发器，该触发器描述了一组规则，当某个事件满足这些规则，事件源就会触发关联的函数。

自定义域名(Custom Domain) 是函数计算提供为Web应用绑定域名的能力。

版本 (Version) 是服务的快照，包括服务的配置、服务内的函数代码及函数配置，不包括触发器，当发布版本时，函数计算会为服务生成快照，并自动分配一个版本号与其关联，以供后续使用。

别名 (Alias) 结合版本，帮助函数计算实现软件开发生命周期中的持续集成和发布。

最后，欢迎大家一起来贡献更多的开源插件！

涉及链接汇总：

Serverless Devs：https://github.com/Serverless-Devs/Serverless-Devs/

FC 组件地址：https://github.com/devsapp/fc

FC-Canary 插件具体信息及其使用请参考：https://github.com/devsapp/fc-canary

FC 函数管理：https://help.aliyun.com/document_detail/73338.htm?spm

FC 函数类型：https://help.aliyun.com/document_detail/61009.htm?spm=