问题
- 什么是Serverless Framework Cli(Plugin)
- 什么是Serverless Framework Component
什么是Serverless Plugin
关注我账号的小伙伴应该看过我之前发的文章,名字叫《云计算:Serverless Framework与Serverless CLI》给大家讲了什么是Serverless架构,也说了Serverless这个公司做了一个叫Serverless的工具,但是实际上,并没有和大家详细的说明Serverless这个工具中Plugin和Component的区别。
首先大家要明确,在目前而言,我们所接触的Serverless Framework这个工具,实际上是由Plugin和Component两个部分。对Plugin而言,更多的是对函数的使用;对Component而言,更多的是对云产品的使用。
首先,什么是Plugin,Serverless Framework Plugin实际上是一个函数的管理工具,无论针对AWS还是腾讯云,Plugin的目标都是对函数进行管理。使用这个工具,你可以很轻松的部署函数/删除函数/触发函数/查看函数信息/查看函数日志/回滚函数/查看函数数据等。
Plugin的使用时比较简单的,你可以直接使用Serverlss Framework进行创建,例如:
serverless create -t tencent-python -p mytest
就可以看到这样的图案生成:
这其中,-t指的是模板,-p指的是路径,在Serverless Plugin操作下,你可以在任何指令中使用-h查看帮助信息,例如查看Serverless Plugin的全部指令,可以直接:
如果想查看Create的帮助:
其实这样看还是比较方便的。接下来继续说我们刚才的部分,创建完Serverless Plugin的项目之后,我们可以看一下他的Yaml长什么样子:
通过这个Yaml,我们可以看到,从上到下实际上它包括了几个主要的Key:Service、Provider、Plugins以及Functions。
Service可以认为是一个服务,也可以认为是一个分组,就是说在一个Service下面的函数,是可以被统一管理的,例如部署/删除/查看统计信息等,都是可以按照这个Service层面来统一进行的。
Provider可以认为是供应商以及全局变量的定义场景,这里使用的是腾讯云的云函数,供应商是腾讯云,所以就要写tencent,同时在这里还可以定义全局变量,这样在部署的时候,会将这些全局变量分别配置到不同的函数中。
Plugin就是插件的意思,就是说你在这个项目下,你会用到那些Plugin,因为Serverless团队提供了超级多的Plugin,当然这个例子里面是需要使用serverless-tencent-scf这个Plugin,因为我们要部署腾讯云的云函数,你要使用其他厂商的可能就要替换上面Provider中的name和这里Plugin了。
最后就是Functions,这就是我们定义函数的地方,这里可以定义很多函数。
接下来继续体验,我们创建项目之后,完成代码编写和Yaml的配置,我们可以继续操作,接下来就是要安装Plugin(是的,就是我们刚才在Yaml中写的Plugin):
npm install
然后就可以进行功能的使用,例如部署服务:
serverless deploy
在我们使用这个工具部署的时候,我们并没事先指定我们的账号信息,所以它会自动唤起扫码登录:
我们只需要扫一扫就可以完成登陆,登陆之后会继续进行操作:
操作完成会看到我们的Service信息,这里要注意,如果我们走CICD的时候,是没办法扫码的,那么这个时候我们就可以手动配置这个账户信息,格式是:
[default]
tencent_appid = appid
tencent_secret_id = secretid
tencent_secret_key = secretkey
配置完成之后,在Yaml中指定这个文件路径就好:
完成部署之后,我们可以触发函数:
还可以服务信息:
很多操作,大家有兴趣的都可以试一下:
创建服务
打包服务
部署服务
部署函数
云端调用
查看日志
回滚服务
删除服务
获取部署列表
获取服务详情
获取统计数据
......
可以说是把函数的管理和操作是做的淋漓尽致,非常不错。但是大家也注意下,这里只是对函数资源的管理(触发器除外),不包括API网关,不包括COS,不包括数据库,不包括CDN.....只是函数。是的,Plugin就是函数开发者工具。
另外,这里要注意,虽然在腾讯云函数中只有命名空间和函数的概念,但是在Serverless Framework Plugin中却有Service、Stage以及函数的三层概念,同时云函数在Plugin这里不支持命名空间,所以可以认为是云函数只有函数的概念,而工具却有服务,阶段和函数的三层概念,这就会产生问题:
Service和Stage是什么?在函数中怎么体现?
以我们刚才部署的hello_world而言:
可以看到,在两个地方体现,一个函数名:服务名-阶段-函数名,另一个是标签,这里我对标签的体现没有太多的想法,但是对这个函数名的变化就要额外提醒:可能我们在简单使用的时候没有影响,但是如果涉及到函数间调用,或者通过云API使用函数的时候,那么这里面就要注意,我们的函数名并不是我们在Yaml中的函数名!这也导致另外一个问题,如果你已经有一个函数,且不是按照这种三段式命名的函数,那么你可能没办法很好的使用Plugin进行部署,除非说把函数进行迁移,将原函数删掉,使用Serverless重新进行部署。
什么是Serverless Component
刚才说了Plugin主要是对函数的管理,那么Component呢?可以认为Component是云产品的工具,因为通过Componnt你可以对你所有的组件进行组合使用,甚至你还可以很简单的开发出自己的Component来满足自己的需求。
Component的Yaml是一段一段的,刚才可以看到Plugin的Yaml是一个整体,从上到下实际上是一个Service里面的内容。但是Component完全可能是前后的两个组件没有任何关系,例如:
test1:
component: "@gosls/tencent-website"
inputs:
code:
src: ./public
index: index.html
error: index.html
region: ap-shanghai
bucketName: test1
test2:
component: "@gosls/tencent-website"
inputs:
code:
src: ./public
index: index.html
error: index.html
region: ap-shanghai
bucketName: test2
通过这样的一个Yaml我们可以看到,实际上这里是两部分,是把一个网站的代码放到了不同的Bucket。目前腾讯云的Component的基础组件包括:
@serverless/tencnet-scf
@serverless/tencnet-cos
@serverless/tencnet-cdn
@serverless/tencnet-apigateway
@serverless/tencnet-cam-role
@serverless/tencnet-cam-policy
封装的上层Component包括:
@serverless/tencnet-express
@serverless/tencnet-bottle
@serverless/tencnet-django
@serverless/tencnet-egg
@serverless/tencnet-fastify
@serverless/tencnet-flask
@serverless/tencnet-koa
@serverless/tencnet-laravel
@serverless/tencnet-php-slim
@serverless/tencnet-pyramid
@serverless/tencnet-tornado
@serverless/tencnet-website
基础Component就是说,你可通过相关的Component部署相关的资源,例如tencent-scf就可以部署云函数,tencent-cos就可以部署一个存储桶;上层的Component实际上就是对底层Component的组合,并且增加一些额外的逻辑,实现一些高阶功能,例如tencent-django就通过对请求的WSGI转换,将Django框架部署到云函数上,其底层依赖了tencent-scf/tencent-apigateway等组件。
相对于Plugin而言,Component并没有那么多的操作,他只有两个:部署和移除。例如部署操作:
serverless --debug
移除操作:
serverless remove --debug
所以相对于Plugin而言,Component的产品纬度是增加了,但是实际功能数量是缩减了。
当然,我觉得这些都不是什么问题,毕竟我们可以Plugin和Component混用,但是问题来了:他们的Yaml长的不一样,我怎么混用?确实很尴尬的问题,我相信Serverless团队在不久的将来应该会解决这个问题吧。
总结
接下来说一下我的个人想法:
Plugin部署到线上的函数,会自动变更名字,例如我的函数是myFunction,我的服务和阶段是myService-Dev,那么函数部署到线上就是myService-Dev-myFunction,这样的函数名,很可能会让我的函数间调用等部分产生很多不可控因素。例如我现在的环境是Dev,我函数间调用就要写函数名是myService-Dev-myFunction,如果是我的环境是Test,此时就要写myService-Test-myFunction,我始终觉得,我更改环境应该只需要更改配置,而不是更深入的代码逻辑。所以我对Plugin的这个换名字问题很烦躁;
Plugin也是有优势的,例如他有Invoke、Remove以及部署单个函数的功能,同时Plugin也有全局变量,我觉得这个更像一个开发者工具,我可以开发、部署、调用、查看一些信息、指标以及删除回滚等操作,都可以通过Plugin完成,这点很给力,我喜欢;
Components可以看作是一个组件集,这里面包括了很多的Components,可以有基础的Components,例如cos、scf、apigateway等,也有一些拓展的Components,例如在cos上拓展出来的website,可以直接部署静态网站等,还有一些框架级的,例如Koa,Express,这些Components说实话,真的蛮方便的,腾讯官方也是有他们的最佳实践;
Components除了刚才所说的支持的产品多,可以部署框架之外,对我来说,最大吸引力在于这个东西,部署到线上的函数名字就是我指定的名字,不会出现额外的东西,这个我非常看重;
Components相对Plugin在功能上略显单薄,除了部署和删除,再没有其他,例如Plugin的Invoke,Rollback等等一切都没有,同时,我们如果有多个东西要部署,写到了一个Components的yaml上,那么我们每次部署都要部署所有的,如果我们认为,我们只修改了一个函数,并且不想重新部署其他函数从而注释掉其他函数,那么很抱歉告诉你,不行!他会看到你只有一个函数,并且帮你把你注释掉的函数在线上删除;
Components更多的定义是组件,所以每个组件就是一个东西,所以在Components上面,是没有全局变量这一说法,这点我觉得很坑。