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

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

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

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

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

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

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

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

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

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

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

传统架构需要自己搞 SLB 负载均衡；配置弹性伸缩服务，不断调试找到合适的伸缩策略；还要自己采集日志来创建告警和监控大盘。这一套下来运维和部署成本其实不是很低，有没有更省事的方案呢？小王进一步调研了 K8s 架构，k8s 的 Services 与 Ingress 规则可以管理到应用层的访问，这样就不用自己搞SLB负载均衡了，同时使用HPA来根据应用水位来水平伸缩。这样看似很不错，但真正测试时发现，HPA的伸缩是分钟级别的，缩容慢一点倒是问题不大，但流量上涨快的时候，扩容总是延后几分钟，会导致部分请求延时增高或失败，影响了服务可用性。如果把扩容的指标阈值调低些，倒是能够解决这个问题，但同时降低了资源利用率，成本上涨了不少。另外还需要自己搞日志采集、告警和监控大盘，运维成本也有不少。而且小王之前没有接触过k8s，k8s繁多的各种概念理解起来着实也有不少的成本。基于FC的架构能够很好的解决上面几个问题。首先，FC 支持预留模式和基于实例指标的自动伸缩能力，这种模式下能够做到更灵敏和快速的扩缩容能力，并保证在扩缩容期间请求延时保持平稳；其次，FC高 度集成了众多开箱即用的功能，体验丝滑又省心，如：提供* 1 + 40% * 20% *1 = 0.68，能够带来32%的费用下降。

配置方式

可以通过控制台和SDK两种方式进行预留实例和闲置计费的配置。登录函数计算控制台，在首页->弹性管理页面选择创建规则，即可进行『闲置计费』的配置。同时可以使用SDK进行配置，支持Java、Go、Node.js等多种语言，详情可以参考​​API在线调试​​。

开启闲置计费后，可以在费用中心-账单详情-明细账单中查到弹性实例和性能实例的闲置资源使用费用（计费账单一般延时3~6小时产出）。

结语

函数计算（FC）一直致力于为用户提供高弹性、免运维、低成本的全托管计算服务。本次闲置计费功能的发布，能够帮助用户进一步降低使用预留实例的成本，让用户只为真实使用的预留资源付费。函数计算会逐步释放更多serverless 的技术红利，在性能、成本、体验上不断为用户提供更极致的表现。文档链接:_弹性管理：_​​_https://help.aliyun.com/document_detail/185038.html_​​

_计费概述：_​​_https://help.aliyun.com/document_detail/54301.html_​​

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。