Serverless 生态下的开发者工具

Serverless ，按中文翻译，称为无服务器。这究竟是一种什么样的形态或产品呢？无服务器，就是真的没有服务器吗？其实，在行业内，目前对于 Serverless 有几种解读方法：在某些场景可以解读为一种软件系统架构方法，通常称为 Serverless 架构；而在有些情况下，又可以代表一种产品形态，称为 Serverless 产品。

在说起 Serverless 架构时，Serverless 代表的是利用 Serverless 形态的产品实现的应用架构，这种架构完全依托于云厂商或云平台提供产品完成系统的组织及构建。在这种架构中，用户无需关注支撑应用服务运行的主机，而将关注点投入在系统架构，业务开发，业务支撑运维上。

而说起 Serverless 产品时，代表的是无需理解、管理服务器，按需使用，按使用付费的产品。Serverless 产品中，其实也可以包含存储、计算等多种类型的产品，而典型的计算产品，就是云函数这种形态。

云函数，或者称为函数即服务 Function as a Service，它和后端即服务 Backend as a Service 一起，都可以称为 Serverless 产品；而通过组合使用这些产品，开发者可以构建自身的业务 Serverless 架构。

Serverless 技术为什么会获得越来越多的关注？我们可以从几个角度来看。

首先，从开发者使用的来说，不用更多的去考虑服务器的相关内容，无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题；同时，也无需再对服务器进行运维了，无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。

其次，Serverless 产品是完全自动化的弹性扩缩容的；在业务高峰时，产品的计算能力、容量自动扩容，承载更多的用户请求，而在业务下降时，所使用的资源也会同时收缩，避免资源浪费。

再次，跟随着完全自动化的弹性所带来的，是全新的计量计费模式；开发者仅需根据使用量来付费，而在深夜无业务量的情况下，不会有空闲资源占用，因此也不会有费用产生。

随着如上提到的特性，Serverless 给开发者或用户带来了具体的商业价值：

• Serverless 使得应用与服务器解耦，业务上线前无需预估资源，无需进行服务器购买、配置；

• Serverless 也使得底层运维工作量进一步降低，业务上线后，也无需担忧服务器运维，而是全部交给了云平台或云厂商；

• Serverless 的应用是按需执行的。应用只在有请求需要处理或者事件触发时才会被加载运行，在空闲状态下 Serverless 架构的应用本身并不占用计算资源；

• 而在使用 Serverless 产品时，用户只需要为处理请求的计算资源付费，而无须为应用空闲时段的资源占用付费；

• Serverless 架构带来的是进一步的业务解耦，应用功能被解构成若干个细颗粒度的无状态函数，开发可以聚焦在单功能的快速开发和上线上；

• 同时拆解后的云函数，也都可以进行独立的迭代升级，更快速的实现业务迭代，缩减功能的上市时间；

• 利用 Serverless 架构的简单运维、低成本及快速上线能力，可以来快速尝试业务的新形态、新功能；

• 利用 Serverless 产品的强弹性扩容能力，在业务获得成功时，也无需为资源扩容而担心；

面向 Serverless 开发的挑战

从一个开发者的角度而言，Serverless 开发和传统的开发方式相比发生了很大的改变。开发者习惯了在本地进行开发，调试，测试和持续集成，持续部署等流程，在面向 Serverless 进行开发时，免不了会有很多疑问：

• 怎样本地开发一个 Serverless 项目？

• 怎样对 Serverless 函数进行本地调试？

• 开发过程中打印的日志是否可以方便的检索并用于 debug？

• 如何保证本地环境和云端环境的一致？

• 发布时怎样将多个函数一次性发布到云环境中？

面向 Serverless 的工具建设逻辑

面临开发过程中的种种挑战，开发者工具将从开发者的视角出发，使 Serverless 的项目开发更贴近用户习惯。下面是一张项目开发的生命周期流程图，可以看到，在项目的开发过程中，至少要经历需求、编码、构建、测试、发布、部署和运维等几个阶段。在代码的编码和构建阶段通过持续集成完成代码的自动构建，成为持续集成 CI（Continuous Integration）；在代码的发布和部署阶段，通过配置灰度策略，告警和回滚计划等，从而可以完成代码的持续交付 CD（Continuous Delivery）。此外，在开发者的开发过程中，也会遇到编码、调试和单元测试，集成测试等场景，这些功能的支持也是面向 Serverless 架构进行开发中必不可少的一环。对开发者工具的建设，则会重点解决在整个生命周期中的痛点。

在 Serverless 技术趋势大热的今天，已经涌现出很多面向开发者的解决方案和工具，例如开源的 Serverless Framework，Zappa 和  ClaudiaJS 等工具。开发者工具大部分都通过调用云厂商中 Serverless 产品的 API/SDK，封装底层能力，并提供给客户更加直观便捷的使用方式。目前比较常见的开发工具中，主要分为 CLI 命令行工具以及 IDE 插件这两种形态。虽然展现方式不同，但本质上都是降低了本地开发 Serverless 项目的门槛，并在云平台提供的基础能力上，封装了更多组织和编排的方式。

由于篇幅有限，本文会以腾讯云的云函数为例，介绍较为典型的开发工具：

腾讯云 Serverless 本地开发工具（SCF CLI）以开源项目的形式维护，目的在于让用户方便的实现函数打包、部署、本地调试，也可以方便的生成云函数的项目并基于 demo 项目进一步的开发。SCF CLI 通过一个函数模板配置文件，完成函数及相关周边资源的描述，并基于配置文件实现本地代码及配置部署到云端的过程。

下面我们以一个 Serverless 项目为例，展示 Serverless 开发工具的使用流程：

（1）函数开发和编码

首先，安装并配置了 SCF CLI 后，可以通过 --help 命令查看所支持的命令，之后通过 scf init 命令快速生成一个函数 demo。在创建完毕后，可以看到生成了 index.js 文件和 template.yaml 文件。其中，index.js 是函数的入口文件，tempate.yaml 则是通过特定的格式记录了函数的配置信息，如内存大小，超时时间等信息。tempate.yaml 也是后续对函数进行编排和组织的关键。除了简单的 init 命令之外，SCF CLI 也支持从 git 拉取代码和一些已有的函数模板，便于客户基于特定的场景快速开发。

（2）代码调试

在开发过程中，开发者会选取自己熟悉的 IDE 代码编辑器进行代码编写。为了便于更快速直观的进行本地开发和调试，通过腾讯云 VS Code 插件支持了一键调试的能力。首先，可以打开刚创建函数的文件目录，在插件中会自动识别这个函数。之后可以通过 F9 进行断点，F5 启动调试能力。函数调试过程中的输出会打印在 terminal 中，并且支持单步调试，查看变量和堆栈等信息。

（3）代码发布

完成了开发和测试后，也可以分别通过 VS Code 插件或 CLI 进行代码的发布。目前分别支持了 zip 打包发布，通过 COS（对象存储）上传并发布，以及通过 git 仓库发布，每次只提交增量修改的文件。在发布完毕后，还可以通过插件中的云端调试，来查看在云端的运行状况和返回日志。

（4）多函数部署

在 VS Code 插件及 CLI 中，可以很方便的将单函数部署在云端，那么如果希望快速发布多个函数时，应该怎样操作呢？目前也可以直接通过 SCF CLI 的 deploy 命令来实现。只需要通过一个 template.yaml 来维护多个函数的信息即可。除了发布之外，还可以通过 template.yaml 文件中的 Global 字段来定义一些函数的通用配置，从而解决开发过程中，希望多个函数共用相同配置的痛点（例如共用相同的环境变量，超时时间和内存等，不需要重复配置）

例如，在我的工作空间下，有两个函数「hellotinatest234」以及「testscflinux」需批量部署上传，并且两个函数使用公共配置。则可以在 template.yaml 中分别定义两个函数的属性，并且定义 Global 字段指定公共配置。部署过程和 yaml 的样式如下：

（5）异常排查 - 日志能力

除了开发流程之外，在生产环境异常时，也可以通过 CLI 的 logs --tail 等命令，快速灵活地进行日志查询等，并且可以配合 grep awk 等工具使用。当发布新版本时，采用 tail 模式可以实时打印云端日志，方便开发者快速查看问题。

（6）DevOps 能力

最后是云函数的 DevOps 能力。目前已经支持了和 Jenkins，Coding 和蓝鲸平台等对接。并且还在持续对 Coding 平台做更深度的整合，提供开箱即可用的 DevOps 能力。在一个经典 DevOps 的 pipeline 中，注意包含了代码检查，依赖安装，测试，审批，发布上线等环境。因此在 Serverless 的架构下，除了测试环节，这些环节和传统的方式并无不同。因此可以依赖命令行工具中的原子能力，方便的接入到各个 DevOps 平台。

例如，SCF CLI 工具规范了错误码和对应输出，从而可以便捷的支持脚本来识别输出，完成自动化的测试及发布流程。