你好，我是何恺铎。

和前一讲提到的容器和云原生一样，毫无疑问，“无服务器”（Serverless）是近年来的又一个技术潮流，它也是伴随着云计算的兴起而获得了迅猛的发展。这一讲，我们就一起来游览和认知无服务器的世界。

什么是无服务器计算？

**“无服务器”是云计算中资源抽象的极致体现。**从它的命名上你就可以看出，所谓“无服务器”就是想让用户感觉不到服务器的存在，这是因为有一朵巨大的云在底层进行着支撑。这样你可以完全专注于业务逻辑的编写，而不再关心任何基础设施。

我们在前面课程的讨论中，其实已经接触到了一些广义上的无服务器 PaaS 服务，比如第 13 讲中的无服务器查询服务和第 14 讲中的无服务器容器服务。甚至第 9 讲中的对象存储服务，它理论上来说也是符合无服务器特征的，因为你不用关心究竟是什么样的机器和多少机器在背后支撑它。

今天我们要来专门讨论的，是经典的无服务器计算服务（Serverless Computing）。“无服务器”这个名称，就是从这种灵活的计算服务起源的。

如果把无服务器计算和容器类服务一起比较的话，这两种云上计算类服务有着共同的优势和特点，比如说，它们都支持细粒度封装和易于大规模扩展。但这两者也有很不一样的地方。

如果说容器是给予了我们很大的定制空间，让你更加容易地按照自己的需要，来进行应用程序的拆分和封装；那么无服务器则是完全屏蔽了计算资源，它是在真正地引导你不再去关心底层环境，你只要遵循标准方式来直接编写业务代码就可以了。

而且在粒度上，无服务器会允许你拆分得更细致、更轻量。你甚至可以把每一个具有独立功能的函数，来作为一个单独的服务进行部署和运行。这也是为什么，在有些云计算的分类方法下，无服务器计算能够单独“开宗立派”，被称为函数即服务（Function-as-a-Service，FaaS）的原因。

你的第一个 Serverless 应用

百闻不如一见，我们就先直接通过实践来认识一下无服务器计算。

我们还是沿用前面几讲中的计算斐波那契数列的例子，因为它简单纯粹的特点，其实也非常适合利用无服务器的云函数来进行实现。所以接下来，我们就尝试把之前的 Node.js 程序迁移到无服务器环境上来。

各大云厂商现在都已经推出了各自的无服务器计算服务，比如 AWS 的 Lambda、阿里云的函数计算，和微软 Azure 的 Azure Functions。在国内的云厂商中，腾讯云也是在无服务器计算上投入较早、产品较为成熟的厂商。今天我们就以腾讯云的云函数为例，来运行我们的斐波那契计算服务。

首先，我们来到腾讯云的云函数产品中，在函数服务菜单下选择“新建”。这里需要填写一下函数名称，我们命名为 fibo，然后运行环境选择 Node.js。

小提示：这里我们选择的是空白函数模板。你也可以选择系统内置的一些常用模板作为基础，以获得一些上手帮助。

然后，我们简单地填写描述，并选取云函数所运行的角色（角色定义了云函数的一些访问权限，如是否能够访问对象存储等），然后选择“完成”即可创建函数。

函数实例建立后，我们点击进入，来到它的代码编辑模块。我们就直接在内置的代码编辑器中进行代码输入，只需要把前几讲的代码略作改动就可以适配云函数了：

补充：这里你可能会惊奇地发现，内嵌在云产品界面中的代码在线编辑并不是一个“花瓶”，包括智能提示在内的功能其实还相当好用。是的，现在云 IDE 的发展也很迅速，在云端直接进行代码编写已经不是痴人说梦了。

图中完整的代码详情我把它贴出来，如下所示：

‘use strict’;
exports.main_handler = (event, context, callback) => {
var input = parseInt(event.path.split(’/’).pop());
return Fibo(${input}) = ${fibo(input)};
};
function fibo (n) {
return n > 1 ? fibo(n-1) + fibo(n-2) : 1;
}

可以看到，用云函数表达的代码逻辑非常简洁。这里主要是遵循腾讯云的规范，以标准的形式定义和暴露了一个 main_handler 方法，它也就是云函数的执行入口了。

另外，这里你需要注意的是重要的输入参数 event，因为以后具体访问请求的详细信息，就会体现在这个 event 参数的各个字段中。这里我们主要取出 path 字段，来获得 fibo 函数输入参数 n 的值。

为了让这个云函数能够对外服务，我们接下来就需要为它添加一个 API 网关触发器，这样当 API 被外界访问时，这个云函数就会被触发执行并返回结果给网关。

我们可以直接在“触发方式”Tab 下选择“新建 API 服务”，这样云函数会为我们创建一个配套的 API 网关实例。

API 网关是一个独立的 PaaS 服务，它可以和云函数联动使用。它的作用是为外界访问提供一个端点，并引流到我们的后台计算服务。这有点类似第 7 讲中使用过的传输层负载均衡，但 API 网关是工作在网络的应用层，它的后端可以连接指向云函数等多种服务。另外，API 网关还能够提供不少应用层的实用功能，比如访问鉴权、限流熔断、版本控制等等。

OK，回到我们的实验当中。网关自动建立并和云函数关联后，我们就可以请求网关提供的访问路径，来触发调用云函数了：

client@clientVM:~$ curl https://service-8h29d5wp-1258170967.sh.apigw.tencentcs.com/release/fibo/35
“Fibo(35) = 14930352”

好，通过上面的测试，我们获得了正确的结果，迁移到云函数的工作就这样轻松地完成了。

你看，对于我们的斐波那契数列应用来说，是从 IaaS 篇使用负载均衡和虚拟机搭建，到改为使用应用托管服务和容器封装，再到这一讲使用无服务器计算。我们所经历的这个过程，可以说是从底层到高层，从具体到抽象，同时相应的实现也越来越简单，有一种腾云而上、渐入佳境的感觉。

值得注意的一点，在上面创建过程中，我们可没有指定任何像 CPU 核数这样的计算资源，因为我们根本不需要操心和感知这些问题。这是真正的“无服务器”计算，它会根据我们的负载情况，依托云端庞大的规模自动地进行支撑和扩展。

补充：你不需要为云函数事先划定资源池，但对于单个函数执行单元的计算资源，还是能够进行一定控制的。最常见的是可以根据云函数的需要来选择运行环境的内存大小。

也正因为底层没有固化的资源，无服务器计算的计费机制是与众不同的。它一般会按照调用次数和调用时长这两个指标来计费。这其实是非常灵活轻量的一种计费方式（部分云厂商计时已经可以精确到毫秒了），从成本上来看尤其适合那些偶尔触发、短时间运行的工作。这会比专门设立一台虚拟机来做同样的事情要划算很多。

另外，现在很多厂商为了鼓励用户去尝试使用无服务器计算，一般也都会提供每月的免费使用额度。对于一些轻量的任务，一个月下来可能都不需要你花一分钱。

从开发模式的角度来说，如果你对在网页上直接开发 Serverless 程序的方式还不太习惯，或者考虑到这样不方便进行代码管理的话，你当然也可以采用本地编辑代码然后上传的方式。而且，在本地可以配合厂商支持的 IDE 工具，会让你的无服务器计算的开发体验更加顺滑高效。

举个例子来说，对于腾讯云的云函数，你可以配合使用 Visual Studio Code 和腾讯云 Serverless 插件，来实现在本地编写、运行云函数，还可以一键和云端进行同步。如下图所示：

使用 VSCode 和腾讯云 Serverless 插件开发云函数

为什么说无服务器计算是多面手？

无服务器计算所能做的，可远远不止充当快速的 Web 开发工具。事件模型是无服务器的核心编程模型和运行逻辑，所以它非常适合相当广泛的事件驱动开发场景。

事件的起始，要依靠触发器。

云上 Serverless 服务一般都配套提供了多种多样的触发器，包括 API 触发器、对象存储触发器、队列触发器等等。比如上面的实验中，我们用的就是API 触发器，它的触发条件为 API 网关带来的外部 Web 请求。

较为常用的还有对象存储触发器。比如当用户上传了一个文件，后台程序把它保存到对象存储中，这时相应的无服务器函数会被这个新对象触发，你就能对这个新上传的文件进行必要的处理了。

此外，你还值得了解相当实用的定时触发器，它可以按照设置的条件周期性触发。通过它和云函数的配合，可以在一定程度上代替操作系统中 crontab 类工具起到的作用，也许能帮你节省一台专门触发运行定时任务的虚拟机。

如果说触发器是无服务器计算的上游的话，**那么各种各样的外部交互方式，也让无服务器计算能够对外访问，并向下游输出。**云端的 Serverless 环境中，一般都能够提供一系列重要类库和 SDK，让你能够在函数内访问其他云服务，尤其是像数据库、消息队列这样的外部存储。

比如说，你可以改进我们上面的实验代码，引入外部 Redis 作为缓存层，在函数中通过对 Redis 的读写，实现数列计算结果的复用。有兴趣的话，你可以动手试试看。

补充：无服务器计算本身是无状态的，所有的持久化需求都要借助外部存储来实现，所以经常需要和数据库、对象存储等服务配合，这既是常用手法，也是必然选择。

所以，在云端，一个常见的场景和架构范式是，云函数可以和消息队列服务形成一对黄金搭档：当队列中有新的消息进入，队列触发器就会触发云函数，并将消息作为事件参数传递给云函数；然后云函数进行及时处理，处理结果还能够再写入另外一个队列；队列又可以触发下一个云函数。如此层层传递，就可以形成一个流式数据的处理管道，实现数据的实时处理和分发。

无服务器函数们，还可以用另一种方式联合起来，发挥出它更大的威力，这也是现在无服务器业界发展的又一个热点：即允许你按照业务逻辑的控制处理流程，以工作流的方式，进行云函数等事件处理单元的组合和编排。

AWS 的 Step Functions 和 Azure 的 Logic Apps，以及阿里云的函数工作流，都是这种类型的云服务的代表。它们能够让你用配置文件或图形化的方式，来设置表达一个复杂的事件处理步骤和逻辑，这是架构在云函数之上的更高层调度框架。

**你可以不用把 if/else、顺序执行、并发等调度控制逻辑写在一个臃肿的函数中，而是可以分开解耦，通过工作流进行组装。**这时，每一个 Serverless 函数，作为处理流程的一个环节，可以只专注做一件事情。

一个用于出行订票的函数工作流示例

（来自阿里云内置示例项目）

工作流服务会来负责事件响应的回收、条件的判断和下一步的触发执行。为了做到这一点，这类服务每次的运行其实都自动维护了一个状态机，来帮助你记录和跟踪状态。

这种通过工作流组合使用云函数的方式，进一步拓展了无服务器应用的场景，让它能够轻松表达和应对更加复杂的事件处理逻辑。比如通过工作流服务，你可以无服务器化你的后端 ETL 流程。

重要提示：你应当注意这里云函数工作流服务，和前面基于队列的流式处理的区别。工作流服务构建的是控制流，定义事件发生的先后次序和条件依赖；而队列流式处理是数据流，是数据的传递和流向。

综上所述，在事件机制和工作流服务的加持下，无服务器计算就成为了一个真正的多面手。它在很多环节都能够扮演恰当的角色，除了自己承担的计算任务之外，它还擅长串联很多云端组件，成为系统组件间的胶水层。

课堂总结与思考

通过技术上的推陈出新，不断提高研发效率，是业界一个永恒的话题，也值得我们永无止境地努力。无服务器计算技术，以其简洁、易用、高效的特点，通过极致的抽象，完全屏蔽了底层基础设施，让用户可以专注业务逻辑的实现，所以成功脱颖而出，成为了亮眼的新星。

不需要指定硬件配置、完全按需服务，这个产品逻辑说起来简单，但绝非所有的运行环境都可以这样“托大”的，只有云才有可能做到这一点。云端巨大的规模是无服务器函数可以稳定可靠运行的有力保障，无愧于是无服务器诞生和发展的最佳土壤。

你可能想问，就目前而言，究竟能否在实际生产场景中全面应用无服务器技术？

我觉得，问题的答案取决于你业务的性质和形态。无服务器计算的技术成熟度已经没有问题，而且它的灵活轻量、便于迭代，都是显而易见的好处，所以非常适合中小公司或创新业务，你不妨大胆一试。比较可行的方式是，前期你可以先小规模使用，摸清它的脾性，如果一切顺利，再逐步加大应用的范围。

当然，说了无服务器计算这么多好话，我们还是要记得恪守冷静客观的原则。所以，你一定不要忽略了 Serverless 服务的限制，毕竟它的本质是受限的环境。冷启动的延时、内存的限制、云函数的运行时长、并发数上限等等，这些都是你大规模深入应用之前需要评估考虑的问题。虽然云厂商一直在改进，这些客观限制在当下对于你的场景是否造成了实质性障碍，也是你目前是否选择 Serverless 计算的一个重要依据。

还有一个你应当小心的地方，在于应用的可迁移性。如果我们看看腾讯云的云函数、阿里云的函数计算和 AWS 的 Lambda，它们的编写形式虽然大体相同，但在接口定义、参数结构、SDK 设计等各方面，还是会有不少的细节差异。所以除非你对于厂商绑定不敏感，否则代码的复用性也会是你不得不考虑的一个因素。

拓展：为了解决厂商绑定问题，业界也涌现出了像 Serverless Framework 这样的厂商中立的第三方技术框架。通过和多个主流云厂商合作和集成，实现“一套代码，多处运行”，对于无服务器计算来说也不是梦想了。你可以重点关注一下它的后续发展。

有人说，无服务器计算将是继虚拟机、容器之后的第三代通用计算技术，它代表着未来的发展趋势，这个说法不无道理。随着生态的不断成熟，和运行限制的不断改善，无服务器计算技术接下来很可能迎来爆发，前景令人期待。

今天，我留给你的思考题是：

  1. 我们实验中使用的 JavaScript 是解释型语言，非常轻量，能够在云 IDE 中编程并作为云函数直接执行。那么，对于 Java/C# 这样的编译型语言，无服务器计算能够支持吗？
  2. 从编程模型上来看，云函数一般都支持同步或者异步两种模式，我们实验中使用的是同步模式。那么，异步模式在使用上有什么区别？适合什么样的场景呢？

好了，这一讲就到这里。欢迎你在专栏下方留言，我非常愿意和你一起探讨。如果觉得有收获，也欢迎把这篇文章分享给你的朋友。

感谢阅读，我们下期再见。