作者：萧起|阿里云 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/docum…
[2] API 在线调试：
https://next.api.aliyun.com/a…
[3] 计费概述：
https://help.aliyun.com/docum…
点击 此处，理解函数计算 FC 更多功能详情！