作者:萧起|阿里云 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 更多功能详情!