共计 2539 个字符，预计需要花费 7 分钟才能阅读完成。
作者 | 孔德慧（夏莞）阿里云函数计算开发工程师
什么是函数计算
大家都理解，Serverless 并不是没有服务器，而是开发者不再须要关怀服务器。下图是一个利用从开发到上线的比照图：
在传统 Serverful 架构下，部署一个利用须要购买服务器，部署操作系统，搭建开发环境，编写代码，构建利用，部署利用，配置负载平衡机制，搭建日志剖析与监控零碎，利用上线后，持续监控利用的运行状况。而在 Serverless 架构下，开发者只须要关注利用的开发构建和部署，无需关怀服务器相干操作与运维，在函数计算架构下，开发者只须要编写业务代码并监控业务运行状况。这将开发者从沉重的运维工作中解放出来，把精力投入到更有意义的业务开发上。
上图展现了函数计算的应用形式。从用户角度，他须要做的只是编码，而后把代码上传到函数计算中。上传代码就意味着利用部署。当有高并发申请涌入时，开发者也无需手动扩容，函数计算会依据申请量毫秒级主动扩容，弹性牢靠地运行工作，并内置日志查问、性能监控、报警等性能帮忙开发者发现问题并定位问题。
函数计算外围劣势
1. 麻利开发
- 应用函数计算时，用户只需聚焦于业务逻辑的开发，编写最重要的“外围代码”；
- 不再须要关怀服务器购买、负载平衡、主动伸缩等运维操作；
- 极大地升高了服务搭建的复杂性，无效晋升开发和迭代的速度。
2. 弹性扩容
- 函数计算依据申请量主动进行弹性扩容，无需任何手动配置；
- 毫秒级调度计算资源，轻松应答业务洪峰。
3. 稳固高可用
- 函数计算分布式集群化部署，反对多可用区；
- 如果某个可用区因自然灾害或电力故障导致瘫痪，函数计算会迅速切换到同区域其余可用区的基础设施运行函数，确保服务高可用。
4. 有竞争力的老本
- 函数计算提供了丰盛的计量模式，帮忙您在不同场景取得显著老本劣势；
- 后付费模型按理论应用计算资源计费，不占用计算资源则不计费，资源利用率高达 100%；
- 预付费模型依据业务负载估算提前预购计算力，单价更低，组合应用后付费和预付费形式将无效降低成本。
函数计算应用场景
从应用场景来说，次要有三类：
- Web 利用：能够是各种语言写的，这种能够是应用 Serverless 框架新编写的程序，也能够是已有的利用。比方可能是小程序后端，也可能是 Web API。
- 对计算能力有很强的弹性诉求的利用：比方 AI 推理、音视频解决、图文转换等。
- 事件驱动型的利用：比方通过其余阿里云产品驱动的场景，Web Hook、定时工作等。
函数计算曾经与很多产品进行了买通，比方对象存储、表格存储、定时器、CDN、日志服务、云监控等十几个产品，能够十分疾速地组装出一些业务逻辑。
函数计算工作原理
1. 函数计算调用链路
上图展现了函数计算残缺的申请和调用链路。函数计算是事件驱动的无服务器利用，事件驱动是说能够通过事件源主动触发函数执行，比方当有对象上传至 OSS 中时，主动触发函数，对新上传的图片进行解决。函数计算反对丰盛的事件源类型，包含日志服务、对象存储、表格存储、音讯服务、API 网关、CDN 等。
除了事件触发外，也能够间接通过 API/SDK 间接调用函数。调用能够分为同步调用与异步调用，当申请达到函数计算后，函数计算会为申请调配执行环境，如果是异步调用，函数计算会将申请事件存入队列中，期待生产。
2. 函数计算调用形式
同步调用的个性是，客户端期待服务端立刻返回计算结果。申请达到函数计算时，会立刻调配执行环境执行函数。
以 API 网关为例，API 网关同步触发函数计算，客户端会始终期待服务端的执行后果，如果执行过程中遇到谬误，函数计算会将谬误间接返回，而不会对谬误进行重试。这种状况下，须要客户端增加重试机制来做错误处理。
异步调用的个性是，客户端不急于立刻晓得函数后果，函数计算将申请丢入队列中即可返回胜利，而不会期待到函数调用完结。
函数计算会逐步生产队列中的申请，调配执行环境，执行函数。如果执行过程中遇到谬误，函数计算会对谬误的申请进行重试，对函数谬误重试三次，零碎谬误会以指数退却形式有限重试，直至胜利。
异步调用实用于数据的解决，比方 OSS 触发器触发函数解决音视频，日志触发器触发函数荡涤日志，都是对延时不敏感，又须要尽可能保障工作执行胜利的场景。如果用户须要理解失败的申请并对申请做自定义解决，能够应用 Destination 性能。
3. 函数计算执行过程
函数计算是 Serverless 的，这不是说无服务器，而是开发者无需关怀服务器，函数计算会为开发者调配实例执行函数。
如上图所示，当函数第一次被调用的时候，函数计算须要动静调度实例、下载代码、解压代码、启动实例，失去一个可执行函数的代码环境。而后才开始在零碎调配的实例中真正地执行用户的初始化函数，执行函数业务逻辑。这个调度实例启动实例的过程，就是零碎的冷启动过程。
函数逻辑执行完结后，不会立刻开释掉实例，会等一段时间，如果在这段时间内有新的调用，会复用这个实例，比方上图中的 Request 2，因为执行环境曾经调配好了，Request 2 能够间接应用，所以 Request 2 就不会遇到冷启动。
Request 2 执行完结后，期待一段时间，如果这段时间没有新的申请调配到这个实例上，那零碎会回收实例，开释执行环境。此实例开释后，新的申请 Request 3 来到函数计算，须要从新调度实例、下载代码、解压代码，启动实例，又会遇到冷启动。
所以，为了减小冷启动带来的影响，要尽可能防止冷启动，升高冷启动带来的延时。
应用预留实例能够完全避免冷启动，预留实例是在用户预留后就调配实例，筹备执行环境；申请完结后零碎也不会主动回收实例。
预留实例不禁零碎主动调配与回收，由用户管制实例的生命周期，能够长驻不销毁，这将彻底消除实例冷启动带来的延时毛刺，提供极致性能，也为在线利用迁徙至函数计算扫清阻碍。
如果业务场景不适宜应用预留实例，那就要设法升高冷启动的延时，比方升高代码包大小，能够升高下载代码包、解压代码包的工夫。Initializer 函数是实例的初始化函数，Initializer 在同一实例中执行且只执行一次，所以能够将一些耗时的公共逻辑放到 Initializer 中，比方在 NAS 中加载依赖、建设连贯等等。另外要尽量放弃申请间断稳固，防止突发的流量，因为零碎已启动的实例不足以撑持大量的突发流量，就会带来不可避免的冷启动。
