作者：萧起｜阿里云 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] 弹性办理：
help.aliyun.com/document_de…
[2] API 在线调试：
next.api.aliyun.com/api/FC-Open…
[3] 计费概述：
help.aliyun.com/document_de…
点击此处，了解函数核算 FC 更多功用概况！
