阿里云杨皓然：Serverless或将引领云的下一个时代

嘉宾 | 杨皓然   整理 | 姜君泽

出品 | CSDN云原生

2022年6月14日，在CSDN云原生系列在线峰会第9期"Serverless峰会"上，阿里云Serverless研发负责人杨皓然分享了云的下一个十年，表示Serverless将会让用户以更小成本、更少代码，实现更高效率的开发迭代。

传统Server架构，在实现调度程序计算进程的同时，如果遇到进程资源过载、黑客入侵、数据量增多或者需要扩容服务器内存时，往往需要开发者对服务器进行管理处理，耗费大量时间。

而Serverless架构，开发者无需关心服务器管理的部分。Serverless由BaaS和FaaS组成，BaaS提供后端服务（如数据库存储、对象存储、API网关等），FaaS提供函数计算服务（如计算深度学习算法、机器学习算法等）。

Serverless入门

在介绍Serverless架构如何处理应用程序之前，先了解一下：软件工程的本质与次要的复杂度问题。

在软件开发中，我们可以把开发任务分为本质和次要两部分，其中本质部分是指如何解决这个软件的业务功能，称为本质复杂度；而次要部分是指如何把这个解决业务功能实施在系统上，可以理解为算法开发与算法部署，也叫次要复杂度。

下面通过一个简单的文件处理程序应用，用本质复杂度和次要复杂度来对比传统的Serverful和Serverless区别，进一步了解Serverless的架构和特性。

【任务：并行处理n个文件】

Serverful：

本质复杂度（Essential Complexity）

• 实现文件处理程序

次要复杂度（Accidental Comlexity）

• 在实施系统解决方案之前，需要考虑一些问题：

• 需要多少台Server

• 如果文件大小不同、处理时长不同，如何让Server负载不过载

• 如果有更多文件，是否考虑要对Server进行扩容

• 如果任务执行到一半，发觉处理的视频原文件是错误的，如何快速暂停或者终止任务

• Server宕机如何处理

• 如何确保所有任务被可靠执行，没有任何遗漏

• ......

这些问题都需要考虑和处理，如果发生，会增加次要复杂度的工作量。

Serverless：

Serverless能帮助我们更容易实现分布式应用。如图1所示，在单机环境可以使用多线程并发处理多个文件。而在云的环境中，可以使用Serverless实现同样简洁的分布式并行任务处理。首先，编写文件处理程序代码（处理程序将在云函数的实例上执行，对应图1 Thread Pool 中的一个 thread）。然后，创建包含工作队列的云函数（Task Queue + Thread Pool），后续只需提交任务给云函数即可。

图1：线程池流程图

本质复杂度（Essential Complexity）：

• 实现文件处理程序

次要复杂度（Accidental Comlexity）：

• 实现和运行线程池

通过对比不难发现，Serverless在次要复杂度上，只需要很简单的步骤就可以实现系统实施，效率提升10倍。

Serverless的特质：

• 使用消息队列、函数、对象文件等更高抽象原语设计解决方案

• 使用Serverless计算服务，自动调度和启动实例，执行文件处理程序

• 使用全托管对象存储服务，用于存储源和结果文件

• 上传代码包/镜像，调用任务，查看结果

• 查看任务状态、实例、请求级别的日志和指示，随时暂停/终止任务

总之，Serverless是一个弹性的服务架构，通过Serverless计算服务结合各种类型的后端服务，实现弹性、高可用、低成本的解决方案。

Serverless的典型场景与技术挑战

Serverless最适用的就是异步处理数据的场景，面对数据量较大的情况，用同步数据读取，需要等到数据全部读取完，才能后续的代码执行，而用异步处理数据的处理方式如图2所示。

图2：同步与异步处理数据方式

异步处理数据的场景有很多，比如：

• 长耗时，消耗大量资源，容易出错的逻辑，适合于从主请求链路拆分出来，异步执行

• 发送电子邮件/消息

• 文档处理（转换格式，导出，……）

• 音视频，图片处理（生成缩略图，加水印，鉴黄，……）

• 调用外部三方服务

• 数据清洗等

当前，理想的异步处理系统特性如下：

• 统一资源池：

不同类型应用共享资源池，提高利用率

覆盖延时十毫秒的在线业务，倒数十小时离线业务

完备的隔离/流控能力

弹性可扩展：

系统的每个环节都具备水平扩展的能力

完备的弹性伸缩的负载均衡能力，满足动态、不可预期峰值的负载能力

实例启动速度快

开箱即用：

定时/延时触发任务

暂停/终止任务

可观测完备

业务方只实现异步处理逻辑

但现实的异步处理系统远不及理想那样，面对挑战，Serverless做出了应对和改进。

Serverless异步系统技术挑战1--可扩展性

以Slack异步任务架构pull模式为例，如图3所示，针对异步数据处理场景，会出现多个问题。

图3：pull模式

• 当任务入队速度持续超过出队速度，Redis实例内存有被打爆的风险。由于出队操作需要消耗Redis内存，所以没有手段让系统恢复正常

• Worker无法独立于Redis实例扩展，增加Worker将加重Redis实例的负载

• 受制于每个Redis实例的处理能力，不同的Worker和不同的Redis实例连接，增加了负载均衡的难度

• K8s HPA等伸缩模式难以满足异步任务的要求，用户需要根据排队任务数等指标伸缩的能力

针对这些技术挑战，Serverless提出了三种可扩展性的方案。

 1. 解耦队列和Worker资源

引入请求分配器（dispatcher），解耦队列和Worker。Worker的伸缩取决于待处理的异步请求数和用户的资源配额，不受队列能力限制，如图4所示。

图4：函数计算异步任务架构-push模式

队列/分配器资源管理

• 根据队列和分配器节点的负载高低，进行节点的扩缩容

• 扩缩容频率低

Worker资源管理

• 扩容：实例并行处理请求数达到上限，CPU利用率超过一定阈值

• 缩容：没有流量时先冻结实例，若一段时间持续没有流量，则销毁实例

• 扩缩容频率高

 2. 自适应的请求分发

• 分配器需要根据下游处理能力动态调整分发能力

• 将请求处理函数的流控错误作为满负荷处理的标志

• 自适应分发采用类似TCP拥塞控制中的AIMD算法，如图5所示

图5：自适应分发模式

3. 基于Partition的负载均衡

• 从资源和运维效率的角度，应用应当共享资源，因为大量应用都是长尾、稀疏调用的

• 多租户环境对资源隔离提出了很高的要求，流量的路由和迁移能力非常重要。当应用流量快速增加时，通过负载分片和调度实现负载均衡，如图6所示

图6：函数计算异步任务架构

Serverless异步系统技术挑战2--GB级镜像实例秒级启动

• 典型负载模式：一次性提交大量任务，启动数百甚至数千实例处理

• 共享存储带宽有限，大规模实例启动打满带宽

• 共享存储延时10-20ms，比块存储慢10倍以上

针对这样的技术挑战，Serverless提出了解决思路：

• 镜像中存在大量冗余数据，按需加载远端数据

• 结合多种存储服务，构建层次化的缓存体系

• 通过负载感知的方式，最大化缓存效果

GB级镜像实例秒级启动的架构如图7所示。

图7：GB级镜像实例秒级启动架构

Serverless常见问题

问题1–Serverless架构新颖？

Serverless不是一项新技术，阿里云很早就将其广泛应用于数据库、大数据等，同时在阿里集团、在公有云有大量实践

问题2–Serverless应用需要大量改造，成本高

• Serverless支持容器镜像打包应用

• 有完整的微服务框架应用和迁移方案，实现零代码改造，迁移成本低

• Serverless资源利用率高，能很好地降低成本

总结

当前，Serverlss化形态的云产品越来越多，从而全面降低了用户使用云的成本，提升了开发者的研发效率，节约了软件开发人员花在服务器上部署系统方案上的时间，从而更加专注于业务逻辑的实现。