开发者学堂课程【Serverless 技术进阶：【音频】如何保证Serverless业务部署更新的一致性】学习笔记，与课程紧密联系，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/995/detail/15037
【音频】如何保证Serverless业务部署更新的一致性
内容介绍：
一、让发布更安全的：线上异动感知
二、性能心中有数：一键压测函数计算
三、从工具看函数资源评估
四、Serverless Devs与Funcraft/Fcli的对比
一、让发布更安全的：线上异动感知
所谓一致性是指通过工具在本地进行项目部署，此时再有其他人通过其他途径（例如控制台等），对项目进行更新等操作。那么，此时再在本地进行项目部署，是不是会直接覆盖？
例如，当用户A在本地更新了业务，因为一些特殊情况，导致出现了一个线上异常x，此时用户B重新更新，将这个内容修复了，但是B没有及时同步给A这个事情，A又更新了新的功能，直接覆盖了B的内容，这个时候之前的异常x又出现了，如果此时在A更新的时候，可以感知到线上资源已经变动，那么这种事情就不会再次发生。
目前基于Serverless Devs的阿里云函数计算组件，已经支持了线上“异动”的感知能力。
如何进行部署前的检测：
1.部署前检测
当通过Serverless Devs开发者工具进行项目部署完成，再模拟其他用户在控制台对配置信息进行更新，完成之后，通过plan功能可以进行部署前的资源检测，可以看到，系统已经成功的感知到了变更。
2.部署异动感知
继续上面的例子，如果在部署的时候直接执行s deploy，系统同样会在部署的时候,告知代码内容发生了变化，并且让使用者主动选择use-remote或者use-local，进行继续部署。
3.在自动化流程中的策略
代码在其他场景被更新，需要在当前得到感知，这个事情其实是非常重要的，和代码的安全发布密不可分。而此时，通过Serverless Devs是可以做到的。
如果已经有了一个项目，想集成到cd流程，不想出现交互式操作，应该如何处理?此时提供一个--use-local/--use-remote参数，用来强行指定优先使用的配置，通过这样的指令就可以实现无交互的部署。例如:
优先使用本地配置: s deploy --use-local
优先使用线上配置: s deploy --use-remote
二、性能心中有数：一键压测函数计算
1.实现原理
stress命令原理是通过创建辅助函数，对目标函数进行压测，架构简图如下：
①stress start指令会根据组件内置配置，创建辅助函数
②辅助函数创建完成后，将会调用目标函数，压测参数放置在调用负载中，辅助函数被调用后就会基于Python Locust对目标函数发起压测试
③发起测试之后，将压测结果返回给本地
④本地收到结果后，会展示结果并生成html报告文件
2.操作案例
有资源描述文件(Yam1)时，可以直接执行s stress start开始目标函数压测;
在没有资源描述Yam1文件时，纯命令行格式，需要指定服务所在地区以及服务名称，函数等,并根据返回信息打开对应的压测报告，这里的操作案例在75-77页有展示（文本4-6页）。
三、从工具看函数资源评估
在Serverless领域内，通常会出现以下两种使用场景:
1.CPU密集型场景
对于CPU密集型场景，例如音视频处理、AI推理或图片处理等，一般会选择使用单实例单并发。由于该类场景的函数内存大小和 CPU能力成正比，因此需要根据函数是成本敏感型还是延迟敏感型选择合适的内存规格。
2.I/0密集型场景
对于I/0密集型场景，一般会选择使用单实例多并发。该类场景下由于函数内存和 CPU能力成正比，建议将函数内存规格设置足够大，但可能会出现浪费资源的现象，很难选择合适的单实例并发值。
针对在以上两种使用场景无法设置合适的参数规格的情况，ServerlessDevs为您提供了探测功能，可以实现内存探测和并发度探测，获取满足您需求的参数配置信息。eval命令是对函数进行探测的命令;通过eval指令，可以对函数探测内存(单实例单并发)或者探测并发度(单实例多并发)。例如给CPU 密集型场景的函数设置合适的内存，给I/0密集型场景的函数设置合适的并发值，根据探测结果，获取满足需求的最佳内存大小或最佳并发度值。
注意:这个命令只是针对开发上线前阶段的函数,不要对生产函数执行探测操作
在78-81页（文本7-9页）分别以探测CPU密集型场景事件函数为例，介绍如何实现内存模式探测，以I/O密集型场景的HTTP函数为例，介绍入河对函数实现并发度的探测。
四、Serverless Devs与Funcraft/Fcli的对比
Serverless Devs与Funcraft/Fcli等工具无论是在使用形式上还是在功能对比上，以及应用场景上都有有比较明显的区别。
1.形式对比
fc组件支持资源描述文件和纯命令行模式，而funcraft只依赖资源描述文件，fcli只支持纯命令行模式
2.功能对比
fc组件支持应用部署、应用移除、构建、远程调用、本地调用、查看日志、查看指标、NAS操作、同步操作、版本、别名、预留、按量资源、层、端云联调、一键压测、内存和并发度探测、远程调试、函数异动感知、端到端部署、多账号管理和API操作
funcraft只支持应用部署、构建、远程调用、本地调用、NAS操作
fcli支持应用部署、应用移除、API操作
3.场景对比
fc组件支持六个场景：
①用户可能同时有测试账号和线上账号，或者个人账号和公司账号,需要进行进行不同账号的切换。
②用户需要在一个项目的执行前后，进行其他相关的行为定义，例如部署前需要进行 build,部署后需要进行版本的发布，相关文件的上传，灰度的设置等。
③用户需要一键部署端到端的项目，例如将前端代码上传到对象存储，后端代码上传到函数计算,同时部署 API网关、CDN等相关业务。
④用户需要在本地进行调试，但是有一些网络环境时线上的VPC,此时需要在本地连接到线上的VPC环境,进行代码的调试等。
⑤在进行项目部署时,Yaml需要从环境变量获取一些敏感信息,或者从其他的文件获取信息,也或者从已经部署完成的项目获得返回值作为入参,进行项目的部署。
⑥不依赖 Yaml进行相关的原则性的操作，例如查看函数列表，服务列表,删除某个函数、服务,查看版本列表等。
fcli只支持一个场景
4.迁移案例
（1）从Funcraft迁移到Serverless Devs的方法
【推荐】Yaml格式切换:这种方法是将Funcarft规范的资源描述文档（例如template.yaml 文件），转换成符合Serverless Devs规范且使用FC组件的资源描述文档（例如 s.yaml 文件)。可以在 Funcraft项目目录下，通过fun2s命令，实现 Yaml规范转换，可以将原有的 Funcraft规范的template.yaml转换成支持 Serverless Devs规范的s.yaml。这里可以看一下转换前，转换后的对比。
资源信息重新同步:这种方法是将线上的函数资源，直接同步到本地，包括线上函数的代码和相关的配置（此时的配置是符合Serverless Devs规范且使用FC组件的资源描述文档）。指定好对应的服务名、函数名等。
（2）从Fcli迁移到Serverless Devs的方法
从Fcli迁移到Serverless Devs的项目，通常是进行函数管理或者是与自动化脚本集成的需求，此时可以考虑使用API直接进行迁移，FC组件的API能力是直接操作函数计算API的功能。
