作者：萧起｜阿里云 Serverless 高级开发工程师
听说你也做过这样的技术选型
小王是一名程序员，公司的应用是跑在自建机房的服务器上，所有的底层服务和运维都需要自己亲自下手来做，每次升级、机器扩容都带来比较大的运维压力，同时为了能及时扩容堆了不少闲置的机器，机器成本一直比较高。最近公司新开发了两个应用系统，小王在做技术选型，打算拥抱云计算，把新应用部署在云上，设计一套高弹性、低成本、运维简单，能轻松应对业务突发流量上涨的架构方案，让自己可以把更多精力投入到业务开发中，减轻自己的运维负担。
这两个应用有几个共同的特点：
- 两个应用都属于在线应用，对调用延迟、服务稳定性有比较高的要求。
- 应用流量随业务变化比较大，而且很难提前预估业务量会上涨多少，对弹性有比较高的要求。
- 有明显的业务低峰期，低峰期调用量比较低，预计低峰期主要集中于晚上。
- 应用启动时间长：一个是 Java SpringBoot 的订单系统，一个是基于大规格镜像的 AI 图片识别系统，启动时间将近 1 分钟。
小王的需求总结起来有三个：
- 一是希望在运维上省事省心，交付 jar 包或者镜像后，只需简单的配置应用就能运行起来，不用专门花费精力搞运维、监控、告警。
- 二是弹性能力要好，业务流量上涨时，可以自动地及时扩容，流量下降后，再自动缩容。
- 三是通过使用云计算，提高资源利用率，在成本上更有优势。
下面就拆开看小王是如何一步一步进行技术选型的。
服务高度集成，免运维，高弹性
在做技术选型时，小王考虑过三种技术架构：SLB + 云服务器 + 弹性伸缩的传统架构、K8s 架构、函数计算 （FC） 架构。
传统架构需要自己搞 SLB 负载均衡；配置弹性伸缩服务，不断调试找到合适的伸缩策略；还要自己采集日志来创建告警和监控大盘。这一套下来运维和部署成本其实不是很低，有没有更省事的方案呢？
小王进一步调研了 K8s 架构，K8s 的 Services 与 Ingress 规则可以管理到应用层的访问，这样就不用自己搞 SLB 负载均衡了，同时使用 HPA 来根据应用水位来水平伸缩。这样看似很不错，但真正测试时发现，HPA 的伸缩是分钟级别的，缩容慢一点倒是问题不大，但流量上涨快的时候，扩容总是延后几分钟，会导致部分请求延时增高或失败，影响了服务可用性。如果把扩容的指标阈值调低些，倒是能够解决这个问题，但同时降低了资源利用率，成本上涨了不少。另外还需要自己搞日志采集、告警和监控大盘，运维成本也有不少。而且小王之前没有接触过 K8s，K8s 繁多的各种概念理解起来着实也有不少的成本。
基于 FC 的架构能够很好的解决上面几个问题。首先，FC 支持预留模式和基于实例指标的自动伸缩能力，这种模式下能够做到更灵敏和快速的扩缩容能力，并保证在扩缩容期间请求延时保持平稳；其次，FC 高度集成了众多开箱即用的功能，体验丝滑又省心，如：提供 http 触发器，省去对接网关、SLB 的工作；控制台提供完整的可观测能力，轻松查看请求、实例状态和运行日志。最后，FC 只需要为调用和调用时使用的活跃资源付费，无调用时不产生费用，能够充分提高资源利用率，减低成本。
下面我们来具体介绍下预留模式的使用，以及如何通过闲置计费来降低预留的使用成本。
预留模式，完美解决冷启动
FC 支持按量和预留两种使用模式，按量模式是通过请求自动触发实例的创建和扩缩容，在调用量增加时创建实例，在请求减少后销毁实例。按量模式充分提高了资源利用率，但对于小王这种启动时间比较长的应用，按量模式创建实例时会有明显的冷启动现象。
为了解决这种冷启动问题，FC 提供了预留的使用模式。用户配置预留后，FC 会创建指定数量的预留实例常驻于系统中，直到用户更新预留配置将其释放。当有请求时，会优先调度上预留实例上，预留实例用满后，新请求会触发按量实例的创建。同时为了使预留实例量更好地贴合业务曲线，还提供了预留定时伸缩和按指标伸缩能力，来提高预留实例的利用率。文末附录弹性管理[1]查看更多详情。
通过这样的方式，即解决了应用冷启动时间长的问题，又保证了预留实例维持在比较高的利用率水平。即使偶尔有比较大的流量波动，也可以临时扩容出按量实例来响应请求，尽量保证流量快速上涨情况下服务的质量。
闲置计费，降本大杀器
在真实的使用场景中，为了保证应用请求的低延时，即使在没有请求时，也要保持一定数量的预留实例，这就造成了成本的上升。有没有办法既做到低延时，又做到低成本呢？函数计算为了帮助用户降低这种场景下的使用成本，推出了预留实例的闲置计费功能，下面我们来具体了解下这个功能。
闲置计费
根据预留实例是否在处理请求，我们将实例区分为闲置、活跃两种状态，并为两种状态分别设置了计费单价。活跃计费单价与原有的资源使用单价保持一致，闲置计费单价是活跃计费单价的 20%，开启闲置计费后能够帮助您节省大量的成本。
默认情况下，闲置计费功能处于关闭状态，此时预留模式的实例无论是否正在处理请求，FC 都会为其分配 CPU，并让实例始终处于活跃状态，以保证实例在无请求时依然可以正常运行后台任务。开启闲置计费功能后，当预留模式的实例无请求时，FC 会将实例上的 CPU 冻结，使该实例进入闲置状态。
通过增加闲置计费，对于预留实例也做到了只为真正使用的 CPU 资源付费。当预留实例处于闲置时，只需支付 20% 的费用，就能应对实例冷启动的问题。这将帮助用户明显降低预留实例的使用成本，同时用户也可以更少的关心预留实例的利用率问题，放心大胆的使用预留实例。
我们以上图为例，假设预留实例的利用率为 60%，原有的使用成本为 1。使用闲置计费后费用为 60% * 1 + 40% * 20% *1 = 0.68，能够带来 32% 的费用下降。
配置方式
可以通过控制台和 SDK 两种方式进行预留实例和闲置计费的配置。
登录函数计算控制台，在首页->弹性管理页面选择创建规则，即可进行【闲置计费】的配置。同时可以使用 SDK 进行配置，支持 Java、Go、Node.js 等多种语言，详情可以参考 API 在线调试[2]。
开启闲置计费后，可以在费用中心-账单详情-明细账单中查到弹性实例和性能实例的闲置资源使用费用（计费账单一般延时 3~6 小时产出）。
结语
函数计算 （FC） 一直致力于为用户提供高弹性、免运维、低成本的全托管计算服务。本次闲置计费功能的发布，能够帮助用户进一步降低使用预留实例的成本，让用户只为真实使用的预留资源付费。函数计算会逐步释放更多 Serverless 的技术红利，在性能、成本、体验上不断为用户提供更极致的表现。
参考文档链接：
[1] 弹性管理：
https://help.aliyun.com/document_detail/185038.html
[2] API 在线调试：
https://next.api.aliyun.com/api/FC-Open/2021-04-06/PutProvisionConfig?
[3] 计费概述：
https://help.aliyun.com/document_detail/54301.html
点击此处，了解函数计算 FC 更多功能详情！
