为什么 Serverless 能提升资源利用率？-阿里云开发者社区

作者：木吴阿里云智能高级技术专家

业务的负载往往不是一成不变的，而是随着时间呈现一定的上下波动。传统的应用构建方式一般是备足充分的资源以保障业务可用性，造成资源利用率不高的现象。随着容器技术的普及，应用可以通过弹性伸缩或者应用混部的方式来提升资源利用率，但由于资源管理的复杂度，难以在业务可用性和资源利用率上取得较好的平衡。

Serverless 平台的出现，将资源管理的责任从用户侧转移到平台侧。这种责任转移能够让用户专注在业务开发上，而平台本身利用其资源规模和负载多样性的优势，专注在资源利用率的提升上。业务使用 Serverless 平台能够大幅提升资源利用率，实现降本提效的效果。

利用率的问题

业务的负载是动态变化的，而资源的弹性往往跟不上负载变化，所以会出现资源利用率不高的情况。为了简化部署运维的复杂度，一般应用在部署时往往指定固定的实例数，此时资源和负载的变化如下图所示：

可以看到，有大量的时间存在资源的浪费，按日平均资源利用率来计算不到 30%。而资源利用率直接关系到成本，如果资源利用率提升一倍，成本就能下降 50%。最理想的情况是资源完全贴合负载，如下图所示：

但现实的情况是很难做到，原因有两个：

负载的变化可以是很快的，但是资源的创建却需要更长的时间
资源的弹性成功率不是 100%，出于稳定性考虑需要预留资源 Buffer

因此，实际的资源状况是介于上述两种情况之间，业务开发者可以通过一些手段来提升资源利用率，使其逼近 100%。接下来我们看一下一些常用的提升资源利用率的手段。

提升利用率：弹性伸缩

容器化的应用通常会使用弹性伸缩来提升资源利用率。最典型的是使用 K8s 的 HPA 策略^[^1]，设置一个 CPU 利用率阈值，当容器的 CPU 利用率超过阈值时自动增加容器，低于阈值时自动减少容器。使用 HPA 后业务负载和资源变化情况如下：

可以看到，在新增的资源创建完成之前，已有的资源要留有一些余量以缓冲负载的上升。在上面这种阶梯形的资源变化情况下利用率是多少呢？让我们来定量地分析一下。

可以看到，需要预留的资源和负载的上升幅度以及扩容时间有关。假设在扩容时间 T 内，负载从 A 上升到 B，实际需要的资源从 xA 扩容到 xB。为了在资源创建完成之前能够接住负载，当负载为 A 时需要有的资源量是 xB，则资源利用率是负载增长斜率和扩容时间的一个函数。当负载的增长比例 K 确定时，资源利用率 Util 是一个关于扩容时间 T 的反向函数，扩容时间越短，则资源利用率越高。

例如在负载每分钟增加 100% 的情况下，资源利用率和扩容时间的关系。

当扩容时间为 1 分钟时，资源利用率为 50%
当扩容时间为 5 分钟时，资源利用率为 17%

扩容时间是提升资源利用率的关键。从负载开始上升，到新容器创建完成，整个扩容时间可以分解成如下图所示：

反应时间

指标采集时间：例如 CPU 指标的采集需要取一段时间内的 CPU 平均利用率
决策时间：例如 CPU 指标的采集需要连续 N 次大于阈值才会触发扩容

启动时间

系统冷启动：系统准备机器和容器环境的时间
应用冷启动：容器启动后应用的初始化时间，例如 JVM 的启动，初始化中间件，加载数据等等

如何缩短扩容时间？下面对比 K8s 和函数计算 FC^[^2]在各个阶段的优化：

时间	K8s	函数计算 FC
指标采集时间	15s	0并发度根据请求实时计算
决策时间	0K8s 默认的 Stabilization window^[^3]为 0	0并发度根据请求实时计算
系统冷启动	镜像：~30s管控+调度+容器启动	代码包：200ms镜像：3s容器池化、代码包/镜像加速
应用冷启动	10ms ~ 10min	10ms ~ 10min

函数计算 FC 通过请求级别的调度，将反应时间缩短到 0；通过代码包和镜像加速，将冷启动时间优化到最低 200ms。在应用冷启动时间相同的情况下，函数计算 FC 的扩容时间比 K8s 快 1 分钟。若应用冷启动较快(10s)，则函数计算 FC 的资源利用率会大幅优于 K8s；若应用冷启动较慢(1min)，则 K8s 的利用率和函数计算 FC 差距变小。如下图所示：

应用冷启动时间的优化，在函数计算 FC 场景下能够大幅提升资源利用率。但是由于应用冷启动和具体的应用逻辑相关，比较难做通用的优化。一些可能的优化方向有：

应用改造：将 Java 应用改造成 Nodejs/Python 等轻量的函数，将镜像改造成代码包方式，但改造代价较大。
函数快照：将已经初始化完成的函数实例做成镜像，通过镜像快速拉起新的实例。但镜像打破了实例的独特性，例如一些应用初始化生成的 UUID 在同一镜像拉起的实例中会冲突。
数据加载加速：一些应用在初始化时需要从 OSS 加载大量数据，系统可以通过 Cache/P2P 等方式加速数据的加载

总结下 HPA 存在的一些问题：

弹性速度问题：弹性速度慢导致 buffer 留得多，利用率低
缩容速度问题：缩容速度慢，有观察窗口
CPU 阈值难以设置：靠业务经验，往往过低

提升利用率：混部超卖

容器化的应用提升资源利用率的另一种方式是混部和超卖。容器集群的使用模式有两种：

经典 K8s 模式：有节点池，Pod 创建在节点上，需要关注容器利用率和节点资源分配率
Serverless K8s 模式：无节点池，Pod 由 Serverless Container 承载，只需要关注容器资源利用率

在经典 K8s 模式下，容器的弹性伸缩并没有提升资源利用率，即使将容器删除掉了，节点也还在。而节点的弹性伸缩不如容器灵活。在这种情况下，混部和超卖是提升资源利用率的常见做法。

在 K8s 里面通过 resource.request^[^4]< resource.limit 来实现超卖：K8s 在调度时根据 resource.request 来分配容器，但是根据 resource.limit 来限制容器的资源使用。

可以看到，一个节点上的容器的最大使用资源加起来，会超过节点的资源限制。能这样做的假设是每个容器的资源使用不会同时达到 resource.limit，否则就会产生资源竞争，导致性能下降甚至 OOM。但这样的假设并不总是成立的，每个容器的资源使用是动态变化的，这样就有一定的概率会出现资源竞争。混部超卖要达到较好的效果并不容易，影响混部效果的因素包括资源池大小，负载多样性，性能稳定性，超载迁移策略等。

首先是资源池大小，资源池越大，发生资源竞争的概率就越小。让我们来定量分析一下竞争的概率：假设有 4 个应用，每个应用的资源使用量有 50% 概率是 1，50% 概率是 2。我们来对比将它们放在一个大的资源池和两个小的资源池的发生竞争的概率：

可以看到大资源池的概率要明显低于小资源池。最直观的，A和C同时为2的时候，在小资源池模式下必然产生竞争，但是在大资源池下未必会产生竞争。对于具体的业务应用来说，由于负载规模不大，资源池也就比较小，混部产生竞争的概率就会较大。

其次是负载的多样性，负载越多样越互补，混部的效果就越好，资源利用率就越高。这种多样性既包括资源需求的多样性，例如有的负载是 CPU 密集型而有的是 IO 型的；也包括时间波动的多样性，例如有的负载是早高峰而有的是晚高峰。

对于具体的业务应用来说，负载的多样性不够，资源利用率难以进一步提高。

最后是超载迁移，当节点的负载过高时，需要将一部分容器迁移到其他的节点。这个迁移过程需要是平滑的，不影响业务。在 K8s 中调度器是不感知应用请求流量的，因此在超载迁移时，需要应用层通过健康检查、优雅上下线等机制配合进行迁移。如果没有及时迁移就会导致请求失败影响服务质量。

总结下混部存在的一些问题：

资源池不够大：资源竞争概率高
负载多样性不够：资源竞争概率高，利用率不高
超载迁移不平滑：节点超载时流量迁移不平滑

提升利用率：Serverless

弹性伸缩和混部超卖是提升资源利用率的有效方式，但由于其固有的复杂度属性，业务开发者往往需要投入较大的精力才能取得较好的效果，而这些基础设施相关的工作，往往不是业务开发者的核心竞争力。业务开发者之所以需要想尽方法来提升资源利用率，最根本的问题是机器是属于业务开发者的。能否将业务开发者从机器运维中解放出来呢？Serverless 提供了一种产品形态，将资源管理的责任从用户侧转移到平台侧。这样，业务开发者只需要为业务请求付费，而无需关注资源利用率，专注在业务创新上。

Serverless 并不是没有服务器了，而是将服务器的管理、运维和利用率提升这些工作集中到平台侧，发挥平台在资源规模、负载多样性上的优势，提升机器的资源利用率。下图是 Serverless 系统的内部架构，通过系统侧的流量管理、弹性伸缩和混部超卖，提升集群的资源利用率：

通过深度垂直优化，提升冷启动速度，做到弹得快
通过吸收不同的业务负载，扩大资源池规模，增加负载多样性，提升混部效率

从用户侧来看，利用 Serverless 平台提供的能力来提升业务侧的资源利用率：

a. 请求调度^[^5]：按请求时间计费，闲置时间不计费，实例的时间利用率为 100%

b. 闲置计费^[^6]：应对应用冷启动慢的业务，提供预留实例闲置计费，当实例没有请求时，费用降低到 1/10

c. 动态并发度：针对 CPU 阈值设置过低的问题，系统根据实际流量动态决定最佳并发度，寻找吞吐拐点

结论

由于负载的动态变化，资源的容量评估和利用率提升，是困扰业务开发者的问题。通过弹性伸缩和混部超卖来提升资源利用率的方式由于其固有的复杂度，实施的效果并不理想。Serverless 平台将资源管理的责任从用户侧转移到平台侧，让业务开发者专注在业务开发上，而平台本身利用其资源规模和负载多样性的优势，专注在资源利用率的提升上，实现共赢。

对于业务开发者而言，根据应用的特点，可以采取如下的选型路径：