Serverless 架构是云发展的产物，是一种去服务器化更加明显的架构。然而，细心的朋友可能会发现，有一个开发者工具也叫Serverless，那么Serverless到底是一个架构，还是一个开发者工具呢？这个开发者工具和Serverless架构又有什么关系呢？

初探Serverless开发者工具

Serverless架构开始发展没多久，就有一群人注册了serverless.com的域名，成立了一家叫Serverless的公司，同时还开发了一款同名工具。

Serverless架构和Serverless开发者工具是两个不同的东西，如果类比一下的话，就相当于中国电信，一方面指的是中国电信行业，另一方面也指的是中国电信运营商。

从Serverless的公司名称，我们也可以推断出其推出的产品与Serverless架构紧密相关。在各个云厂商都有自己函数计算业务的时候，Serverless团队做了一个类似多云管理平台的工具，可以认为是多Serverless管理的工具。利用这个工具，可以快速直接使用AWS的Lambda、Azure的Funtions以及腾讯云SCF等众多云厂商的函数计算相关服务，大体支持的功能如下：

通过这个上表，大家也可以感觉到这其实是个开发者工具，帮助用户快速使用多个云厂商的函数服务，打包、部署、回滚…当然，各个厂商也都推出类似的工具，例如AWS的SAM、腾讯云的SCFCLI等。

除了一个以函数计算为核心的多云开发者工具之外，Serverless公司还推出了组件化工具：Components。换句话说，Serverless开发者工具不仅仅关注Serverless中的FaaS，也要关注BaaS，将API网关、对象存储、CDN、数据库等众多的后端服务和函数计算有机集合，让用户可以一站式开发，一站式部署，一站式更新，一站式维。

Serverless Framework 开发者工具可以被一分为二：Plugin和Components。

如果说最初的Serverless Cli更多是一种以插件（Plugin）形式提供各个云厂商的函数计算功能，那么这个叫Components的功能更多就是以各个云厂商整体服务为基础，来帮助用户快速将项目部署到Serverless架构上。

所谓的Components可以认为是很多Component的组合，例如如果部署一个网站，可能会需要有以下部分：静态资源部分、函数计算部分、API网关部分、CDN部分、域名解析部分等，而Components就可以帮我们一站式部署这些资源，将静态资源部署到对象存储中，将函数计算部分部署到函数中，将API网关、CDN等业务部署到对应的产品或者服务中，如果有域名解析需求，会自动解析域名，同时将整个项目的所有资源进行关联。

除了一键部署、自动关联之外，Components还提供了若干的传统Web框架部署到Serverless架构的解决方案，用户可将自己已有的或者使用这些框架新开发的项目，直接一键部署到云端，对开发者来说这是一个巨大的便利。

用户如何使用Plugin和Components呢？其实这两个功能都是Serverless Cli作为承载，也就是说，只要我们安装了Serverless Framework这个开发者工具，就可以同时使用这两个功能。

安装Serverless Framework开发者工具的过程也很简单：

安装Nodejs，官方说的nodejs只需要6以上就好，但是在实际使用过程中，发现6不行，至少8以上才可以。
安装Serverless开发者工具：npm install -g serverless，安装完成之后可以通过serverless -v查看版本号，来确定是否成功的安装该工具。

至于如何使用Serverless Framework开发者工具，可以参考接下来的Plugin和Components部分。

什么是Serverless Plugin

首先，什么是Plugin，Serverless Framework 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下面的函数是可以被统一管理的，例如部署、删除、查看统计信息等。

Provider可以认为是供应商以及全局变量的定义场景，这里使用的是腾讯云的云函数，供应商是腾讯云，所以就要写tencent，同时在这里还可以定义全局变量，这样在部署的时候，会将这些全局变量分别配置到不同的函数中。

Plugin就是插件，Serverless团队提供了超级多的Plugin，例如上文提到的serverless-tencent-scf。

最后就是Functions，是定义函数的地方。

创建项目，完成代码编写和Yaml的配置之后，接下来就是安装Plugin：

	npm install

使用相关功能，例如部署服务：

	serverless deploy

在使用这个工具部署的时候，我们并没事先指定账号信息，所以它会自动唤起扫码登录，登陆之后会继续进行操作：

操作完成会看到Service信息，这里要注意，如果是使用CICD，就没办法扫码了，必须手动配置账户信息，格式是：

    [default]
    tencent_appid = appid
    tencent_secret_id = secretid
    tencent_secret_key = secretkey

配置完成之后，在Yaml中指定这个文件路径：

完成部署之后，触发函数：

服务信息：

除此之外，还有很多其它操作，大家有兴趣可以都试一下：

创建服务
打包服务
部署服务
部署函数
云端调用
查看日志
回滚服务
删除服务
获取部署列表
获取服务详情
获取统计数据

…

需要注意的是，Plugin是函数开发者工具，只针对对函数资源的管理（触发器除外），不包括API网关、COS、数据库、CDN等。另外，在腾讯云函数中只有命名空间和函数的概念，但是在Serverless Framework Plugin中却有Service、Stage以及函数的三层概念，同时云函数在Plugin不支持命名空间，所以我们可以理解为，云函数只有函数的概念，而工具却有服务、阶段和函数的三层概念，这就会产生问题：Service和Stage是什么？在函数中怎么体现？

以我们刚才部署的hello_world为例：

从上图可以看到，Service 和 Stage 体现在函数名和标签两个地方。函数名在简单使用时可能没有影响，但如果涉及到函数间调用或者是云API使用函数时，就要注意，这里的函数名并不是在Yaml中的函数名！

当然，这里也会出现另一个问题，即如果用户已经有一个函数，且这个函数不是按照三段式命名的，那么可能没有办法使用Plugin进行部署，除非把函数进行迁移，将原函数删掉，使用Serverless重新进行部署。

什么是Serverless Component

Plugin主要是对函数的管理，那么Component呢？Component可以认为是云产品的工具，因为通过Componnt可以对所有的组件进行组合使用，甚至还可以很简单开发出自己的Component来满足需求。

Component的Yaml是一段一段的，而Plugin的Yaml是一个整体，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不一样，如何混用？

总结

Plugin部署到线上的函数，会自动变更名字，例如函数是myFunction，服务和阶段是myService-Dev，那么函数部署到线上就是myService-Dev-myFunction，这样的函数名，很可能会让函数间调用产生很多不可控因素：如果环境是Dev，函数间调用就要写函数名是myService-Dev-myFunction，如果环境是Test，此时就要写myService-Test-myFunction。在我看来，环境更改只需要更改配置，无需更改更深入的代码逻辑，因此这一点会让我觉得不友好；
Plugin也是有优势的，例如如果有Invoke、Remove以及部署单个函数的功能，同时Plugin也有全局变量，它像是一个开发者工具，可以进行开发、部署、调用、查看信息、指标以及删除回滚等操作；
Components可以看作是一个组件集，这里面包括了很多的Components，有基础的Components，例如cos、scf、apigateway等，也有一些拓展的Components，例如在cos上拓展出来的website，可以直接部署静态网站等，还有一些框架级的，例如Koa，Express；
Components除了支持的产品多，可以部署框架之外，对我来说，最大吸引力在于其部署到线上的函数名字就是指定的名字，不会出现额外的东西；
Components相对Plugin在功能上略显单薄，除了部署和删除，再没有其他功能。当你需要部署多个东西，并写在了某个Components的yaml上，那么即使你只修改了一个函数，它都需要全部重新部署一遍；
Components更多的定义是组件，所以在Components中是没有全局变量的。

作者介绍

刘宇，腾讯Serverless团队后台研发工程师。毕业于浙江大学，硕士研究生学历，曾在滴滴出行、腾讯科技做产品经理，本科开始有自主创业经历，是Anycodes在线编程的负责人（该软件累计下载量超100万次）。目前投身于Serverless架构研发，著书《Serverless架构：从原理、设计到项目实战》，参与开发和维护多个Serverless组件，是活跃的Serverless Framework的贡献者，也曾多次公开演讲和分享Serverless相关技术与经验，致力于Serverless的落地与项目上云。

相关阅读：

入门 Serverless：如何实现 Hello World？

创作场景

入门 Serverless ：Serverless Framework 开发者工具