嘉宾 | 杨皓然 整理 | 姜君泽
出品 | CSDN云原生
2022年6月14日，在CSDN云原生系列在线峰会第9期"Serverless峰会"上，阿里云Serverless研发负责人杨皓然分享了云的下一个十年，表示Serverless将会让用户以更小成本、更少代码，实现更高效率的开发迭代。
(资料图)
传统Server架构，在实现调度程序计算进程的同时，如果遇到进程资源过载、黑客入侵、数据量增多或者需要扩容服务器内存时，往往需要开发者对服务器进行管理处理，耗费大量时间。
而Serverless架构，开发者无需关心服务器管理的部分。Serverless由BaaS和FaaS组成，BaaS提供后端服务（如数据库存储、对象存储、API网关等），FaaS提供函数计算服务（如计算深度学习算法、机器学习算法等）。
在介绍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最适用的就是异步处理数据的场景，面对数据量较大的情况，用同步数据读取，需要等到数据全部读取完，才能后续的代码执行，而用异步处理数据的处理方式如图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：函数计算异步任务架构
典型负载模式：一次性提交大量任务，启动数百甚至数千实例处理
共享存储带宽有限，大规模实例启动打满带宽
共享存储延时10-20ms，比块存储慢10倍以上
针对这样的技术挑战，Serverless提出了解决思路：
镜像中存在大量冗余数据，按需加载远端数据
结合多种存储服务，构建层次化的缓存体系
通过负载感知的方式，最大化缓存效果
GB级镜像实例秒级启动的架构如图7所示。
图7：GB级镜像实例秒级启动架构
问题1–Serverless架构新颖？
Serverless不是一项新技术，阿里云很早就将其广泛应用于数据库、大数据等，同时在阿里集团、在公有云有大量实践
问题2–Serverless应用需要大量改造，成本高
Serverless支持容器镜像打包应用
有完整的微服务框架应用和迁移方案，实现零代码改造，迁移成本低
Serverless资源利用率高，能很好地降低成本
当前，Serverlss化形态的云产品越来越多，从而全面降低了用户使用云的成本，提升了开发者的研发效率，节约了软件开发人员花在服务器上部署系统方案上的时间，从而更加专注于业务逻辑的实现。
关键词：
营业执照公示信息