一篇了解 Serverless 云开发高阶应用
发布时间：2021-06-05 19:49:19 所属栏目：大数据 来源：互联网
导读：在我们的代码中，是将整个后端应用的全部业务能力写进了一个函数中。这样做的好处就是方便管理，毕竟在一个应用下只有一个云函数。但是单个云函数的并发是有限的，并行的函数实例个数由云厂商决定，而超过限制后，事件队列就需要等待其他函数实例执行完毕后
|
在我们的代码中，是将整个后端应用的全部业务能力写进了一个函数中。这样做的好处就是方便管理，毕竟在一个应用下只有一个云函数。但是单个云函数的并发是有限的，并行的函数实例个数由云厂商决定，而超过限制后，事件队列就需要等待其他函数实例执行完毕后，再生成新的函数实例。
那可能就有人问了，不是说 Serverless 是弹性伸缩的吗?不是说会根据业务处理的需求自动调配资源嘛?为什么还会有函数的并发限制呢?
要搞清楚这一点，我们需要了解 FaaS 的运行机制。
FaaS 的运行机制
在 FaaS 平台中，函数默认是不运行的，也不会分配任何资源，甚至 FaaS 中都不会保存函数代码。只有当 FaaS 接收到触发器的事件后，才会启动并运行函数。前面我们就是使用 HTTP 的触发器来执行函数代码的，整个函数的运行过程实际上可以分为四个阶段：
代码下载：FaaS 平台本身不会存储代码，而是将代码放在对象存储中，需要执行函数的时候，再从对象存储中将函数代码下载下来并解压，因此 FaaS 平台一般都会对代码包的大小进行限制，通常代码包不能超过 50MB。
启动容器：代码下载完成后，FaaS 会根据函数的配置，启动对应容器，FaaS 使用容器进行资源隔离。
初始化运行环境：分析代码依赖、执行用户初始化逻辑、初始化入口函数之外的代码等。
运行代码：调用入口函数执行代码。
当函数第一次执行时，会经过完整的四个步骤，前三个过程统称为“冷启动”，最后一步称为“热启动”。
整个冷启动流程耗时可能达到百毫秒级别。函数运行完毕后，运行环境会保留一段时间，这个时间在几分钟到几十分钟不等，这和具体云厂商有关。如果这段时间内函数需要再次执行，则 FaaS 平台就会使用上一次的运行环境，这就是“执行上下文重用”，也叫做 “实例复用”，函数的这个启动过程也叫“热启动”。“热启动” 的耗时就完全是启动函数的耗时了。当一段时间内没有请求时，函数运行环境就会被释放，直到下一次事件到来，再重新从冷启动开始初始化。
考虑下面这个云函数:
在第一次调用该云函数的时候，函数返回值为 1，这是符合预期的。
但如果连续调用这个云函数，其返回值有可能是从 2 递增，也有可能变成 1，这便是实例复用的结果：
当热启动时，执行函数的 Node.js 进程被复用，进程的上下文也得到了保留，所以变量 i 自增。
当冷启动时，Node.js 进程是全新的, 代码会从头完整的执行一遍，此时返回 1。
下面是一个函数的请求示意图，其中 “请求1” “请求3” 是冷启动，“请求2” 是热启动。
函数执行完毕后销毁运行环境，虽然对首次函数执行的性能有损耗，但极大提高了资源利用效率，只有需要执行代码的时候才初始化环境、消耗硬件资源。并且如果你的应用请求量比较大，则大部分时候函数的执行可能都是热启动。
从函数运行的生命周期中你可以发现，如果函数每分钟都执行，则函数几乎都是热启动的，也就是会重复使用之前的执行上下文。执行上下文就包括函数的容器环境、入口函数之外的代码。
云平台会根据当前负载情况，自动控制云函数实例的数量，并且均衡地分发请求。连续的多次请求有可能由同一实例处理，也可能不是。这就是我们在上面的代码中看到的，i 的值非常放肆，根本就找不到规律。所以，我们在编写云函数时，应注意保证云函数是无状态的、幂等的，即当次云函数的执行不依赖上一次云函数执行过程中在运行环境中残留的信息。
再次回到我们的 Todo 案例中，因为我们将全部的业务逻辑放到了一个云函数中，因此，处理的并发量会受到极大的限制。当并发量达到一定的程度时，无法创建更多的函数实例，也就无法分配更多的服务器资源。更好的方式是对我们的业务逻辑进行拆分，一个云函数就对应一个独立的业务逻辑处理。这在小程序的云开发中就有体现，默认给我们的小程序云开发模板中，就是一个小程序应用对应对个云函数的处理方式。
 （编辑：南通站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
