引言

近年来，Serverless 成为云计算领域热门词汇。早在 2014 年，亚马逊就在 AWSre:Invent 2014 大会上推出了 AWSLambda，赢得了开发者的广泛好评。2018 年，国内云服务厂商相继开始跟进，阿里云、腾讯云也推出了自己的 Serverless 云服务。今天我们就通过国内云厂商的案例来了解，Serverless 是什么？为什么需要 Serverless？它是如何降低软件开发成本，同时增加软件开发效率的？

云函数的特性是，当 main 函数 return 时，执行进程会被立即冻结。这一点在官方文档Node.js 8 的异步行为中有提到。

对于异步函数，主流程执行完成后，函数实例进程会被冻结，进程中的所有异步任务会暂停执行，直到这个进程被再次唤起。
另一方面，如果函数实例进程由于某些原因没被复用（例如更新了函数代码），这个异步流程中的代码就永远不会被执行。

但是有些场景下，云函数需要很长的执行时间，例如，Twikoo 通过 Akismet 检测垃圾评论的过程。按照特性，在检测过程结束前，就不能异步检测，提前返回结果给前端，否则检测进程就会被冻结，导致检测失败。我们只能 await 同步检测，造成请求响应慢，用户体验差。

按照 Java 的习惯，我们会启动新的线程执行长时间的任务，在云函数中怎样实现？

背景

Twikoo 评论系统要实现导入功能，导入，就需要上传文件。

通过调用云函数，我们能够传递 string、number 等简单的参数，想要上传文件？不太行。

想到云开发环境有一块默认开通的 COS 空间，这块空间允许登录用户上传文件，只要利用这片空间，就可以实现将文件上传给云函数的功能了。

主要思路

1. 前端调用 js-sdk 上传文件，获取到 fileID
2. 前端将 fileID 作为参数，调用云函数
3. 云函数通过 fileID 获取到文件，并解析

腾讯云云开发云函数的文档中写道——

不同的云函数可以共用代码文件（目录）吗
未上线

如果是简单的云函数，这一点还能接受，在开发 Twikoo 评论系统的过程中，云函数要实现的 API 越来越多，逐渐让我发现了它的弊端：

1. 大量的代码复制！
2. 版本管理非常不便！
3. 依赖管理非常不便！
4. 一次要部署十来个云函数，很麻烦！
5. 每个云函数都有独立的冷启动时间，很慢！

显然违反了开发的 DRY 原则，这迫使我开始思考解决方案。

正常的思维是，一个 API 写一个云函数，如果将云函数合并，用一个云函数实现不同的功能，能否解决这样的问题呢？