问题
- 什么是Serverless Framework Cli（Plugin）
- 什么是Serverless Framework Component
什么是Serverless Plugin
关注我账号的小伙伴应该看过我之前发的文章，名字叫《Serverless与Serverless》给大家讲了什么是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
就可以看到这样的图案生成：
image
这其中，-t指的是模板，-p指的是路径，在Serverless Plugin操作下，你可以在任何指令中使用-h查看帮助信息，例如查看Serverless Plugin的全部指令，可以直接：
image
如果想查看Create的帮助：
image
其实这样看还是比较方便的。接下来继续说我们刚才的部分，创建完Serverless Plugin的项目之后，我们可以看一下他的Yaml长什么样子：
image
通过这个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
image
然后就可以进行功能的使用，例如部署服务：
serverless deploy
在我们使用这个工具部署的时候，我们并没事先指定我们的账号信息，所以它会自动唤起扫码登录：
image
我们只需要扫一扫就可以完成登陆，登陆之后会继续进行操作：
image
操作完成会看到我们的Service信息，这里要注意，如果我们走CICD的时候，是没办法扫码的，那么这个时候我们就可以手动配置这个账户信息，格式是：
[default]
tencent_appid = appid
tencent_secret_id = secretid
tencent_secret_key = secretkey
配置完成之后，在Yaml中指定这个文件路径就好：
image
完成部署之后，我们可以触发函数：
image
还可以服务信息：
image
很多操作，大家有兴趣的都可以试一下：
创建服务
打包服务
部署服务
部署函数
云端调用
查看日志
回滚服务
删除服务
获取部署列表
获取服务详情
获取统计数据
......
可以说是把函数的管理和操作是做的淋漓尽致，非常不错。但是大家也注意下，这里只是对函数资源的管理（触发器除外），不包括API网关，不包括COS，不包括数据库，不包括CDN.....只是函数。是的，Plugin就是函数开发者工具。
另外，这里要注意，虽然在腾讯云函数中只有命名空间和函数的概念，但是在Serverless Framework Plugin中却有Service、Stage以及函数的三层概念，同时云函数在Plugin这里不支持命名空间，所以可以认为是云函数只有函数的概念，而工具却有服务，阶段和函数的三层概念，这就会产生问题：
Service和Stage是什么？在函数中怎么体现？
以我们刚才部署的hello_world而言：
image
可以看到，在两个地方体现，一个函数名：服务名-阶段-函数名，另一个是标签，这里我对标签的体现没有太多的想法，但是对这个函数名的变化就要额外提醒：可能我们在简单使用的时候没有影响，但是如果涉及到函数间调用，或者通过云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
image
移除操作：
serverless remove --debug
image
所以相对于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上面，是没有全局变量这一说法，这点我觉得很坑。
image
网友评论