引言
随着云计算发展的趋势，服务器Server架构成为云计算发展的产物，Sever服务器越来越成为软件开发的手段，但传统Server，在实现调度程序计算进程的同时，如果遇到进程资源过载、黑客入侵、数据量增多或者需要扩容服务器内存，这时候需要开发者对服务器进行管理处理，耗费大量时间。
而Serverless架构，无需开发者关心服务器管理的部分，Serverless由BaaS和FaaS组成，FaaS提供函数计算服务（如计算深度学习算法，机器学习算法）和BaaS提供后端服务（数据库存储，对象存储、API网关等），见下图。
Serverless简介
在了解Serverless架构是如何处理应用程序之前，先了解一下：软件工程的本质与次要的复杂度问题。
在软件开发中我们可以把开发任务分为本质和次要二部分，其中本质部分是指如何解决这个软件的业务功能，也称为本质复杂度，而次要部分是指如何把这个解决业务功能实施在系统上。（可以理解为算法开发与算法部署），也叫次要复杂度。
下面通过一个简单的文件处理程序应用，用本质复杂度和次要复杂度来对比传统的Serverful和Serverless区别，进一步了解Serverless的架构和特性。
任务：并行处理n个文件
传统Server：
本质复杂度（Essential Complexity）：
实现文件处理程序
次要复杂度（Accidental Comlexity）：
再实施系统解决方案之前，需要考虑一些问题，如下：
需要先考虑需要多少台Server
考虑如果文件大小不同，处理时长不同，让Server不负载过载
如果更多文件，是否考虑要对Server进行扩容 如果任务执行到一半，发觉处理的视频原文件是错误的，怎么能快速暂停或者终止任务？
Server宕机处理如何处理
怎么确保所有任务被可靠执行，没有任何遗漏
如果任务执行一半，发现处理视频原文件是错误的，怎么快速暂停或者终止
…
这些问题都是需要去进行考虑和处理的，如果发生，都会增加次要复杂度的工作量
Serverless：
编写文件处理程序代码（Task Submitters）
创建包含工作队列的线程池（Task Queue），提交任务给函数（Thread Pool），流程图见下图。
本质复杂度（Essential Complexity）：
实现文件处理程序
次要复杂度（Accidental Comlexity）：
实现和运行线程池
通过对比不难发现Serverless在次要复杂度这块只需要很简单的步骤就可以实现系统实施。效率提升10倍。
Serverless具有的特质
使用消息队列、函数、对象文件等更高抽象原语设计解决方案
使用Serverless计算服务，自动调度和启动实例，执行文件处理程序
使用全托管对象存储服务，用于存储源和结果文件
上传代码包/镜像，调用任务，查看结果
查看任务状态、实例、请求级别的日志，指示，随时暂停/终止任务
总结：Serverless是一个有弹性的服务架构，能结合不同的本质程序，自我的调节出最适合程序的系统解决方案，
Serverless的典型场景与技术挑战
Serverless最适用的就是异步处理数据的场景，面对数据量较大的情况，用同步数据读取，需要等到数据全部读取完，才能后续的代码执行，因此才用异步处理数据，处理方式见下图。
异步处理数据，这样的场景有很多比如：
长耗时，消耗大量资源，容易出错的逻辑，适合于从主请求链路拆分出来，异步执行
发送电子邮件/消息
文档处理（转换格式，导出，。。。。）
音视频，图片处理（生成缩略图，加水印，鉴黄，……）
调用外部三方服务
网页爬虫
数据清洗等
当前最理想的异步处理系统特性如下：
统一资源池：
不同类型应用共享资源池，提高利用率
覆盖延时十毫秒的在线业务，倒数十小时离线业务
完备的隔离/流控能力
弹性可扩展：
系统的每个环节都具备水平扩展的能力
完备的弹性伸缩的负载均衡能力，满足动态、不可预期峰值的负载能力
实例启动速度快
开箱即用：
定时/延时触发任务
暂停/终止任务
可观测完备
业务方只实现异步处理逻辑
但现实的异步处理系统远不及理想那样，Serverless在距离实现理想异步处理系统上面对着一些技术的挑战，作出了不同的改进。
Serverless异步系统技术挑战1 – 可扩展性
以Slack异步任务架构-pull模式为例，如下图所示，针对异步数据处理场景。会出现如下问题：
当任务入队速度持续超过出队速度，redis 实例内存有被打爆的风险。由于出队操作需要消耗redis 内存，所以没有手段让系统恢复正常
Worker 无法独立于redis 实例扩展。增加worker 将加重redis 实例的负载
受制于每个redis实例的处理能力，不同的worker 和不同的redis 实例连接，增加了负载均衡的难度
K8S HPA等伸缩模式难以满足异步任务的要求，用户需要根据排队任务数等指标伸缩的能力
针对这样的技术问题挑战，Serverless提出了三种可扩展性的方案：
1.解耦队列和Worker资源
引入请求分配器（dispatcher），解耦队列和Worker。Worker 的伸缩取决于待处理的异步请求数和用户的资源配额，不受队列能力限制，见下图所示。
队列/分配器资源管理
• 根据队列和分配器节点的负载高低，进行节点的扩缩容
• 扩缩容频率低
Worker 资源管理
• 扩容：实例并行处理请求数达到上限，CPU 利用率超过x
• 缩容：没有流量时先冻结实例，一段时间持续没有流量，则销毁实例
• 扩缩容频率高
2.自适应的请求分发
- 分配器需要根据下游处理能力动态调整分发能力。
- 将请求处理函数的流控错误作为满负荷处理的标志
- 自适应分发采用类似TCP 拥塞控制中的AIMD
算法，见下图
3.基于Partition的负载均衡
- 从资源和运维效率的角度，应用应当共享资源，因为大量应用都是长尾，稀疏调用的
- 多租环境对资源隔离提出了很高的要求。流量的路由和迁移能力非常重要！当应用流量快速增加时，
- 通过负载分片和调度实现负载均衡，见下图
Serverless异步系统技术挑战2 – GB级镜像实例秒级启动
典型负载模式：一次性提交大量任务，启动数百数千实例处理
共享存储带宽有限，大规模实例启动打满带宽
共享存储延时10-20ms，比块存储慢10X 以上
针对这样的技术问题挑战，Serverless提出了解决思路
镜像中存在大量冗余数据，按需加载远端数据
结合多种存储服务构建层次化的缓存体系
通过负载感知的方式最大化缓存效果
结果：块存储的性能，共享存储的成本，GB 级镜像启动开销～ 3 秒，业界领先，架构见下图所示。
Serverless的常见误解和解释
误解1 – Serverless 架构太新了，没有经过验证
Serverless 不是一项新技术
阿里云第一个云产品，对象存储，是Serverless 的存储服务
• 所有主要云厂商的产品体系在Serverless 化，数据库、中间件、大数据、……
• 当产品体系Serverless 化进展到一定程度后，通过使用多种云服务以搭积木的方式可以完成应用时，Serverless 计算开始成为一种新范式，成为主流
• 一半以上的AWS 用户使用AWS Lambda
• Google Cloud Run 部署数在2021增加了超过3倍
Serverless 在阿里集团和公有云经过大量实践
• Serverless 适合异步任务，事件驱动架构应用，API Serving，Web 单体应用，微服务架构后端服务
• 集团核心链路业务Serverless 落地，经受双十一考验。集团大量长尾应用使用函数计算，小规格实例，缩容到0特性，
大幅优化成本和运维效率
误解2 – Serverless 应用需要大量改造，迁移成本高
函数计算
支持容器镜像打包应用
• 业界限制最小的FaaS 服务，保持极致弹性的同时，支持最高10 GB 的镜像
• K8S 风格的custom runtime/container 协议，零代码改造迁移流行Web 框架应用
Serverless 应用引擎
• 支持容器镜像打包应用
• 零代码改造迁移Dubbo，SpringCloud 等传统微服务框架应用
• 完整的VM 存量应用平滑迁移方案
误解3 – Serverless 单价比ECS 贵太多，成本没有优势
Serverless 通过提高资源利用率来降低成本
• 绝大多数集群日平均CPU 利用率小于15%，甚至低于5%。周期性负载，峰谷明显的负载，长尾、低频的负载是资源效
率低下的主要原因，Serverless 架构对这类负载有明显优势
• Serverless 的单价贵，但是资源利用率高，且平台承担资源冗余成本
Serverless 降低TCO，而非单纯节省资源成本
• 降低基础平台开发和维护的复杂度
• 更快将功能推向市场
误解4 – Serverless 会导致供应商锁定
如何评估供应商锁定的程度？
数据存储
• 云产品功能/API 接口差异
• 应用运行时
阿里云Serverless 拥抱开放标准，融入开源生态
• 事件总线服务EventBridge 基于Cncf CloudEvents 1.0 标准
• 函数计算Custom Runtime/Container 协议和K8S 类似，零代码改造迁移Web 应用
• Serverless 应用引擎零代码改造迁移传统微服务应用
• 函数计算和Serverless 应用引擎支持容器镜像作为应用打包的方式
• 可观测性能力支持OpenTelemetry 标准
• 和Terraform 等流行IaC 工具集成，通过多云有好的开源工具部署Serverless 应用
• 开源Serverless Devs 工具服务，支持多云
总结
当前基于Serverless已经衍生出许多的产品，以Serverlss化形态的云产品越来越多，这样的变化能全面的降低用户使用云的成本，全面的提升开发者的研发效率，节约软件开发人员在服务器上部署系统方案上时间，基于大量使用系统资源的算法应用上，节约服务器资源使用，使其算法更能稳定的运行，开发者将会更加专注于业务逻辑的实现。
