闲置计费 | Serverless 冷启动与成本间的最优解

2022 年 5 月 05 日
本文字数：2701 字
阅读完需：约 9 分钟

作者：萧起｜阿里云 Serverless 高级开发工程师

听说你也做过这样的技术选型

小王是一名程序员，公司的应用是跑在自建机房的服务器上，所有的底层服务和运维都需要自己亲自下手来做，每次升级、机器扩容都带来比较大的运维压力，同时为了能及时扩容堆了不少闲置的机器，机器成本一直比较高。最近公司新开发了两个应用系统，小王在做技术选型，打算拥抱云计算，把新应用部署在云上，设计一套高弹性、低成本、运维简单，能轻松应对业务突发流量上涨的架构方案，让自己可以把更多精力投入到业务开发中，减轻自己的运维负担。

这两个应用有几个共同的特点：

两个应用都属于在线应用，对调用延迟、服务稳定性有比较高的要求。
应用流量随业务变化比较大，而且很难提前预估业务量会上涨多少，对弹性有比较高的要求。
有明显的业务低峰期，低峰期调用量比较低，预计低峰期主要集中于晚上。
应用启动时间长：一个是 Java SpringBoot 的订单系统，一个是基于大规格镜像的 AI 图片识别系统，启动时间将近 1 分钟。

小王的需求总结起来有三个：

一是希望在运维上省事省心，交付 jar 包或者镜像后，只需简单的配置应用就能运行起来，不用专门花费精力搞运维、监控、告警。
二是弹性能力要好，业务流量上涨时，可以自动地及时扩容，流量下降后，再自动缩容。
三是通过使用云计算，提高资源利用率，在成本上更有优势。

下面就拆开看小王是如何一步一步进行技术选型的。

服务高度集成，免运维，高弹性

在做技术选型时，小王考虑过三种技术架构：SLB + 云服务器 + 弹性伸缩的传统架构、K8s 架构、函数计算（FC）架构。

1.png

传统架构需要自己搞 SLB 负载均衡；配置弹性伸缩服务，不断调试找到合适的伸缩策略；还要自己采集日志来创建告警和监控大盘。这一套下来运维和部署成本其实不是很低，有没有更省事的方案呢？

小王进一步调研了 K8s 架构，K8s 的 Services 与 Ingress 规则可以管理到应用层的访问，这样就不用自己搞 SLB 负载均衡了，同时使用 HPA 来根据应用水位来水平伸缩。这样看似很不错，但真正测试时发现，HPA 的伸缩是分钟级别的，缩容慢一点倒是问题不大，但流量上涨快的时候，扩容总是延后几分钟，会导致部分请求延时增高或失败，影响了服务可用性。如果把扩容的指标阈值调低些，倒是能够解决这个问题，但同时降低了资源利用率，成本上涨了不少。另外还需要自己搞日志采集、告警和监控大盘，运维成本也有不少。而且小王之前没有接触过 K8s，K8s 繁多的各种概念理解起来着实也有不少的成本。

基于 FC 的架构能够很好的解决上面几个问题。首先，FC 支持预留模式和基于实例指标的自动伸缩能力，这种模式下能够做到更灵敏和快速的扩缩容能力，并保证在扩缩容期间请求延时保持平稳；其次，FC 高度集成了众多开箱即用的功能，体验丝滑又省心，如：提供 http 触发器，省去对接网关、SLB 的工作；控制台提供完整的可观测能力，轻松查看请求、实例状态和运行日志。最后，FC 只需要为调用和调用时使用的活跃资源付费，无调用时不产生费用，能够充分提高资源利用率，减低成本。

下面我们来具体介绍下预留模式的使用，以及如何通过闲置计费来降低预留的使用成本。

预留模式，完美解决冷启动

FC 支持按量和预留两种使用模式，按量模式是通过请求自动触发实例的创建和扩缩容，在调用量增加时创建实例，在请求减少后销毁实例。按量模式充分提高了资源利用率，但对于小王这种启动时间比较长的应用，按量模式创建实例时会有明显的冷启动现象。

为了解决这种冷启动问题，FC 提供了预留的使用模式。用户配置预留后，FC 会创建指定数量的预留实例常驻于系统中，直到用户更新预留配置将其释放。当有请求时，会优先调度上预留实例上，预留实例用满后，新请求会触发按量实例的创建。同时为了使预留实例量更好地贴合业务曲线，还提供了预留定时伸缩和按指标伸缩能力，来提高预留实例的利用率。文末附录弹性管理 [ 1] 查看更多详情。

通过这样的方式，即解决了应用冷启动时间长的问题，又保证了预留实例维持在比较高的利用率水平。即使偶尔有比较大的流量波动，也可以临时扩容出按量实例来响应请求，尽量保证流量快速上涨情况下服务的质量。