玩转 serverless devs 的三种部署方式
serverless-devs是一个开源的Serverless应用全生命周期管理工具。
笔者作为一名Serverless应用开发者，对国内的阿里云FC，腾讯云SCF都有一定的了解。接下来我将在此文中介绍:如何使用这个工具，来把同一个应用，通过不同的方式，部署到阿里云函数计算中。
文章中使用的示例项目为一个nestjs应用，运行环境为nodejs，源代码见附录。这三种部署方式，由于部署目标平台都为阿里云，统一使用阿里云函数计算（FC）组件。
预置Runtime部署
这个部署方式是最简单直接的，假如你只是想搭建一个简单的webservice或者处理做一些batchjob，不需要依赖一些额外的系统库或者软件，往往使用这个方式部署就够了。主要的yml配置也很简单:
这种方式最大的特点，就是runtime需要从预置的枚举值中配置一个具体值，比如nodejs12,nodejs14,python2.7,python3,java8,java11,php7.2,dotnetcore2.1等等。一旦你指定了具体的运行时，那么函数动态扩容伸缩所使用的镜像就已经确定了下来。接下来就是把你的代码放入镜像创建容器中，去执行了。此时就需要codeUri和handler这些配置项了，用它们来指定，执行代码入口。
同时除了对外暴露的handler中的代码会被执行外，在函数实例的生命周期中，也存在着一些回调方法。就以initialize这个回调方法名为例，我们在函数配置中设置函数的Initializer回调程序为index.initialize，那么exports.initialize这个方法会在实例初始化时被执行，其他生命周期亦然。
CustomRuntime部署
自定义运行环境部署，与预置Runtime部署方式，最大的特点就是可自定义语言和运行时了。
我们为啥需要这种部署方式？当然是因为预置的Runtime不够用了。通过这种方式，我们可以自定义运行时的语言和版本。比如使用rust和nodejs2048。而它主要的yml配置也很简单:
其中customRuntimeConfig中声明了启动命令和参数，直接执行便可。
需要注意的是，这种部署方式，需要你上传运行环境的解析器/运行时，再和你的代码文件，一起打包部署到函数计算。这往往很大，比如我下载的node-v16.15.0-linux-x64解压后足足有100M，所以可以找一种方式来复用运行时的包来加快你的部署速度。
CustomRuntime部署这种方式，要求你的代码是一个HTTPServer并监听指定的caPort端口。而且你的函数实例生命周期回调也是由HTTPServer中指定路由来完成的,比如/initialize,/pre-freeze,/pre-stop这类。
总的来说，它比起预置Runtime部署有了更多的可操作性，相比来说它的速度也差一些，毕竟代码包的体积变大了，每次都要下载解压，这个速度肯定是慢一点的。所以灵活的代价无非就是性能差一点，我们在选择部署方式的时候也要根据情况，斟酌损益。
CustomContainer部署
刚刚我们已经通过CustomRuntime部署来自定义代码的运行时了，但是即使通过那种方式，我们也无法改变代码运行的容器环境。比如我有一段代码，只有在Windows的IIS上才能运行，怎么办?显然CustomRuntime部署固定的容器环境，是不满足我们的需求的。
这时候我们就需要在本地，构建我们自己的容器镜像，并把它推送到阿里云的镜像仓库里去。所以启用CustomContainer部署，最重要的先决条件是什么？
安装docker并开通阿里云容器镜像服务
它对应的serverless-devs也非常简单：
customContainerConfig#image就是你的镜像仓库的地址(我示例中用的公网地址，最佳实践为函数计算同地域的VPC镜像地址)，复制粘贴即可。
fcbuild–use-docker–dockerfile./code/Dockerfile这个命令，你可以理解成一堆docker构建发布的命令脚本。
而Dockerfile就是构建镜像的核心了，在这里我们可以任意的配置我们的系统环境。比如我们要转化操作图集变成pdf文件，则预先安装好ghostscript。
我们要在nodejsruntime中构建类似Canvas实现，额外安装build-essentiallibcairo2-devlibpango1.0-devlibjpeg-devlibgif-devlibrsvg2-dev…..
这里给出一个Dockerfile示例参考:
这种部署方式最灵活，能做到很多上述2个部署方式做不到的事情，但是它的冷启动速度也是最慢的。原因在于，容器镜像依赖的基础环境和应用很容易臃肿，这带来了额外的数据下载和解压的时间。所以这种部署方式上生产环境，往往很多措施来辅助，比如镜像启动加速，预留实例和单实例多并发等等功能，同时自己在构建时也要做一定的优化，详见冷启动优化最佳实践
结论
灵活性(从低到高)
单语言&普通的CRUD->预置Runtime部署
自定义语言or运行版本->CustomRuntime部署
自定义容器环境->CustomContainer部署
冷启动速度(从慢到快)/优化成本(从高到低)
CustomContainer
CustomRuntime
预置Runtime部署
扩展阅读(友商对比)
前面主要讲了，利用serverlessdevs的部署的三种方式。
现在，让我们先回到预置NodejsRuntime部署这种方式，在部署时，开发者们应该都注意过。我们在传统web框架部署到FC时，需要安装一个额外包:@serverless-devs/fc-http来包裹我们的框架实例。这个包是干啥用的呢？
@serverless-devs/fc-http本质上是一个阿里云FC兼容传统web框架的适配层，和友商的tencent-serverless-http一样，它们都源自于serverless-http。
不过同样是proxy，阿里云和腾讯云的实现方式有所不同。
阿里云的@serverless-devs/fc-http负责做一些FC的http函数上下文和传统web框架上下文相互转化的适配。
腾讯云的tencent-serverless-http本质上是一个SCF事件函数与腾讯云的API网关的适配层。
它负责把用户请求API网关后，传给云函数event，转化为函数内部包裹的web框架(express,koa…)能够处理的http上下文(req,res,ctx…)，经过中间件的处理后，再把响应值转化为API网关要求的响应格式，来响应用户的请求。
一图以蔽之：
Image
腾讯云的事件函数部署web框架，和web函数部署webserver区别主要在于上图的proxy层，是在用户代码内，还是在SCF云函数环境中。
这个不同，本质上源自于2个云厂商实现云函数的方式不同。所以阿里云的事件请求处理程序(EventHandler)和HTTP请求处理程序(HTTPHandler)和腾讯云的事件函数还有Web函数不能直接进行类比。
阿里云的EventHandler和HTTPHandler更像是不同的函数种类。这个种类的不同，也体现在了函数的入参和响应方式上。
腾讯云的事件函数则和阿里云的EventHandler比较相似，而Web函数个人感觉其实更接近于阿里云的CustomRuntime的部署方式。区别主要在，阿里云要自己去下载Runtimebinary，腾讯云则内置了一些Runtime。
同时相比于腾讯云，阿里云目前没有开放在线安装依赖的功能。当然这避免了用户想要自定义安装包的源这类的问题。同时也在一定程度上变相倡导了在容器中开发的方式。
附录
官网
@serverless-devs/fc-http
源码
bootstrap示例如下所示
主题测试文章，只做测试使用。发布者：最新稳定辅助网，转转请注明出处：https://www.744broad.com/15121.html
