关于serverless:深入理解-Serverless-计算的并发度

4次阅读

共计 7105 个字符，预计需要花费 18 分钟才能阅读完成。

作者|西流（阿里云技术专家）

2019 年 Berkeley 预测 Serverless 将取代 Serverful 计算[1]，成为云计算的计算新范式。Serverless 为利用程序开发提供了一种全新的零碎架构，其凭借着弹性伸缩省事省心，按需付费更低成本、聚焦业务升高 OPS 这三大外围价值，将开发人员从沉重的手动资源管理和性能老本优化中解放出来，让工程师的生产力再次发生改革。

依据 CNCF 官网定义[2]：
“Serverless is a cloud native development model that allows developers to build and run applications without having to manage servers. There are still servers in serverless, but they are abstracted away from app development. A cloud provider handles the routine work of provisioning, maintaining, and scaling the server infrastructure. Developers can simply package their code in containers for deployment. Once deployed, serverless apps respond to demand and automatically scale up and down as needed. Serverless offerings from public cloud providers are usually metered on-demand through an event-driven execution model. As a result, when a serverless function is sitting idle, it doesn’t cost anything.”

从下面的定义能够看出，Severless != No Server，只是对于开发者来说，没有了 Server 去治理。而在云厂商提供的服务中，Serverless 架构应该是采纳 FaaS（Function as a service, 函数即服务）和 BaaS（后端服务）服务来解决问题的一种设计。

FaaS 服务的典型代表：AWS lambda、阿里云函数计算 FC、Azure Functions、Google Cloud Functions 等
BaaS 服务典型代表：AWS: S3、Dynamodb、SQS 等；阿里云：OSS、TableStore、MNS 等

Serverless 计算

当然随着需要和技术的倒退，业界呈现了一些 FaaS 以外的其它状态的 Serverless 计算服务，比方 Google Cloud Run、AWS App Runner、阿里云 Serverless 利用引擎 SAE、阿里云 Serverless Kubernetes ASK 等，这些服务也提供了弹性伸缩能力和按应用计费的免费模式，具备 Serverless 服务的状态，能够说进一步扩充了 Serverless 计算的营垒。

而在 Serverless 计算畛域最典型的两种产品状态代表 FaaS 和 Google Cloud Run, 都不谋而合采纳了并发度（Concurrency）这个指标作为扩缩容策略。接下来咱们重点分析下不同产品状态下并发的语义以及为什么这些风行的 Serverless 计算产品为什么采纳并发度作为扩缩容的策略。

并发是古代计算的外围准则之一，并发是指计算零碎同时解决多个工作的能力。例如，如果您的计算机同时运行多个程序，则具备多个并发过程 / 线程能够共享 CPU 工夫。如果单个应用程序过程同时解决多个网络申请，或者并行处理队列中的多个作业，则也能够认为该应用程序正在执行并发工作。

比方“世界第一语言 PHP”在 Web 畛域的实际，应用就是过程池，如下图中的 FastCGI 过程管理器。发送到服务器的 Web 申请将被调配给过程池中的 CGI 过程。该 CGI 过程将解决该单个申请。如果同时收到多个申请，则将启动多个 CGI 过程并行处理它们。然而，每个过程一次只能解决一个申请。服务器可能通过对 CGI 过程进行上下文切换来解决并发申请。操作系统调度程序将跟踪所有 CGI 过程，并在须要时切换正在 CPU 上运行的 CGI 过程，以使每个 CGI 过程在须要时都能取得属于本人的、偏心的 CPU 工夫份额。

PHP Web 运行原理图

现在，有更多用于并发的工具，这包含古代编程语言内置的弱小异步并发机制，以及帮忙简化并发的云计算服务。让咱们看看一些云计算服务如何设计和应用并发。

云厂商的 FaaS 服务的并发扩缩容原理根本大同小异，咱们以 AWS Lambda 官网文档[3] 为参考：

当首次调用一个函数时，FaaS 服务会创立一个函数实例，并运行处理程序办法以处理事件。实现后，函数会在一段时间内放弃可用状态，以解决后续的事件。如果在函数繁忙时有其余事件达到，FaaS 会创立更多的函数实例来同时解决这些申请。

从文档中咱们能够看出，每个函数实例一次只能解决一个事件申请（即 one concurrent request per instance，也称为单实例单并发）。在处理事件申请时，函数被认为是忙碌的，因而任何并发事件都必须转到另一个函数实例。每次必须创立函数的新实例时，都会呈现短暂的“冷启动”(Cold Start)提早。这个冷启动的持续时间取决于您的代码大小和应用的运行时 Runtime。下图 [4] 显示了当有多个并发申请须要进行并行处理时，FaaS 如何实时扩大函数实例的数量：

Tips: 只有绿色局部是毫秒计费，黄色和空白局部均不会计费，真正 100% 为计算资源付费。

FaaS scaling and concurrency

这使得 FaaS 的并发模型在某些方面相似于那些老式的 PHP 过程管理器。在这两种状况下：1). PHP 过程管理器通过并行启动更多过程来实现并发。单个过程一次只能解决一个事件申请。2). FaaS 通过并行启动更多的执行环境容器实例来实现并发，单个实例一次只能解决一个事件申请。但应用 PHP 过程管理器那样的过程级别的并发有两个经典难题须要解决：

过程之间的平安隔离：您必须在操作系统调配 CPU 工夫和系统资源给过程时做出正确的决策。一个过程可能会耗费过多的资源，影响在同一台机器上运行的其余过程的性能。
主动扩缩容：以 PHP 应用程序为例，您必须治理每个服务器上的 PHP CGI 过程数量，并且必须对运行这些过程的服务器数量进行手动扩缩容。

FaaS 能很好解决上述两个难题，FaaS 显著有一些现代化的特点, 以函数计算执行环境容器的平安隔离为例[5]:

阿里云 FC 计算节点平安隔离
虚拟化级别平安隔离
- 神龙裸金属计算节点可运行来自不同用户的函数实例，应用阿里云平安沙箱提供函数级别虚拟化及容器隔离，ECS 虚拟机只容许运行同用户的函数实例，借助 ECS 隔离提供用户级别虚拟化隔离，应用 Runc 等容器技术实现函数级别的容器隔离。
函数实例网络拜访受限，用户决定网络外访权限
- 函数实例配置公有 IP 地址，用户不可间接拜访，且实例间网络不可达，网络隔离应用 open vSwitch、iptables 和 routing tables 实现。
函数实例资源受限函数 CPU/ 内存设置的配额
函数计算负责函数实例沙箱容器的破绽修复及平安降级

应用 FaaS 这种事件驱动的全托管计算服务，您将主动取得隔离的执行环境实例，FaaS 服务主动治理执行环境实例的数量和容量。您所要做的事件就是提供您的代码到 FaaS 服务，并向 FaaS 服务发送事件以触发该代码执行即可。

FaaS 简略概览

从上面对 FaaS 并发扩缩容的探讨中，置信大家很快 get 到单个实例一个并发的能力对 CPU 密集型的逻辑十分敌对。而古代的许多工作负载都充斥了 I/O 操作，如果咱们采纳 FaaS 经典的 one concurrent request per instance 模式，会有如下痛点问题：

重大的资源节约

IO-intensive workload[11]

蓝色方框示意程序正在工作时的工夫，红色方框示意期待 IO 操作实现所破费的工夫。因为 IO 申请可能比 CPU 指令破费的工夫长几个数量级，因而您的程序可能会破费大部分工夫期待，实例资源节约重大。并且随着并并发数目的变大，节约的资源也呈线性增长，如上面红色局部即为节约的计算资源：

FaaS IO-intensive workload

可能会对共享资源造成意想不到的结果

数据库是一个典型的例子。当应用传统的关系型数据库（如 mysql）时，数据库有一个最大并发连接数。传统常驻型服务器通常应用“数据库连接池”进行优化。“数据库连接池”限度了单个服务器实例对数据库的最大并发连接数，同时容许并发的申请能无效地共享“数据库连接池”的连贯。然而，如果每个实例只能解决一个申请并维持与数据库的凋谢连贯，则申请的数量与到数据库的连接数之间存在一对一的关系。后果是在负载顶峰期间，数据库可能会因过多连贯而打满，并最终回绝新连贯。如果一个数据库实例的最大连接数为 100，应用 FaaS，示意图如下：

FaaS with DB

因而，就 FaaS 畛域的 one concurrent request per instance 的痛点问题，Google Cloud Run 提供了 multi concurrent requests per instance 的能力[6]，这就很好解决咱们上文探讨的单实例单并发扩缩容模型的痛点：

Google Cloud Run 单个实例默认最大并发度 (即单个实例的并发申请数下限) 为 80，最大可调整到 1000

IO 期待期间不再是资源节约

Google Cloud Run IO-Intensive workload

对共享资源造成影响可预期：进步数据库连贯吞吐

Google Cloud Run With DB

如果每个实例配置了数据库连接池大小为 10，那么每个实例能够容许 10 个并行申请到数据库。因为每个实例可能会接管高达 80 个并发申请，“数据库连接池”将在期待数据库连贯被开释并返回到池中时，主动阻止传入的申请。通过应用 10 个数据库连贯响应 80 个申请，实践上能够在数据库达到其最大连贯限度之前将数据库的吞吐量进步 10 倍。

乏味的是，一些 FaaS 厂商怯懦做出了 multi concurrent requests per instance 的尝试，比方阿里云函数计算设置实例并发度 , Google Cloud Functions 第 2 代也开始反对设置实例并发度。旨在解决古代很重要的 IO 密集型工作负载问题。

FaaS 和 Google Cloud Run 采纳实例并发度 (即实例的并发申请数下限) 这个指标进行扩缩容，而不是采纳 CPU 指标等 HPA 策略，是因为在 Serverless 畛域，实例并发度是“基于申请解决 / 事件驱动进行扩缩容”表白最好的一个形式。

FaaS 和 Google Cloud Run 都有实例缩至为 0 和有申请进来能够拉起一个新实例的能力，在实例 0-1 过程中无奈应用 CPU 或内存等指标进行扩容。
更好地匹配申请解决：并发度可能更好地匹配理论申请的数量，因而能够更好地利用计算资源，同时确保申请可能疾速失去响应。以阿里云函数计算和 K8S 做一个资源匹配申请速度的比照[7]:

更好的资源利用率：实例并发度策略能够更好地利用计算资源，能够在申请顶峰期间疾速扩容，而在申请较少时放弃最小的实例数量，从而缩小资源节约。FaaS 和 Google Cloud Run 容许用户运行任何语言的代码，并主动扩大以匹配流量：并发度总数 = 同时解决申请的实例数量 * 每个实例的最大并发申请数下限

当然，引入的并发度的概念也给习惯了 CPU 指标等扩缩容的开发者带来的新的纳闷，对于 IO 密集型的利用，基于 CPU 指标的 HPA 扩容策略很简略就能够进步应用程序的可用性、性能和可靠性，并使资源更高效地利用。反而单个实例的最大并发度的正当值怎么去设置是一个比拟头疼的问题？这个问题，业界通常都是建议您依据本人的负载状况做压测迭代出适合的并发度值。阿里云函数计算为此做了一个业界最前沿的摸索，提供了自动化举荐能力：从青铜到王者，揭秘 Serverless 自动化函数最佳配置[8], 并由此瞻望智能动静并发度：在这种模式下，用户不须要通过手动配置参数，而是在函数运行时动静调整，依据实例 CPU 负载的衰弱指标主动调整到最佳值。

基于上文对并发度的探讨，对于单实例单并发（云产品代表 FaaS）和单实例多并发（云产品代表 Google Cloud Run）这两种状态的 Serverless 产品，我应该抉择哪个产品来托管我的应用程序呢？以下是一些情景是我集体会抉择哪种产品的倡议：

但最终还是须要依据您具体的业务需要做取舍，抉择最合适的产品和计划。
注：FaaS 中的函数计算 FC 和 Google Cloud Functions V2 也反对单实例多并发

场景	抉择	理由
定期 / 事件触发的后台作业	FaaS	异步工作，不关怀冷启动时的提早，典型的事件驱动
非预期的工夫流量波峰和波谷切换	FaaS	函数实例将扩容以解决流量激增，并在波峰完结时进行缩减。与 burst 流量所带来的高提早相比，冷启动可能会对性能产生较小的影响。
每个申请必须互相隔离或者 CPU 密集型工作，例如:

Puppeteer 对 HTML 页面截图
Word 转 PDF 等文档转换
前端畛域 SSR 渲染
音视频转码、录屏等解决
机器学习 AI 推理，AIGC
…
| 单实例单并发 FaaS | 每个申请隔离个性非常适合将这些潜在的歹意作业彼此隔离开来，同时每个实例保障了确定的 CPU 和内存的配额。
某个申请执行工夫超过函数设置的 timeout 主动被 kill
某个申请导致实例的 OOM 不会扩散，只会影响这个一次申请
…
|
| 可预期流量的 IO 密集型利用 | 单实例多并发云产品 | 防止资源节约，更好爱护上游比方 mysql 数据库 |
| 非 HTTP 协定利用 | 单实例多并发云产品 | FaaS 厂商大多不反对，或者像阿里云 FC 反对 WebScoket 这种非 HTTP 协定，然而老本不占优势 |

上述表格中的倡议是基于阿里云函数计算利用核心 [9] 中的用户对于利用的偏好部署次数【见下图】以及客户落地案例【见参考 12】来佐证的，尤其对于每个申请必须互相隔离或者 CPU 密集型工作，FaaS 具备无可比拟的劣势：

对于存量利用，将 CPU 密集型工作从利用中抽离进去，晋升服务的稳定性，这个文章 PDF Generation With AWS Lambda[10] 深刻探讨了这种实际的收益。
对于新业务 CPU/GPU 密集型利用，如音视频解决以及最近大火的大模型 AIGC(AI generated content) 利用，是 FaaS 人造符合的场景。

在 AI 场景中申请和后端资源的调度比传统的微服务场景的要求会更高，次要起因是 AI 场景的申请对资源的耗费特地大。比方一个 Stable Diffusion 应用 A10 GPU 卡部署，一块 A10 卡(ecs.gn7i-c8g1.2xlarge) 启动 Stable Diffusion 服务一次只能解决个位数的文本绘图申请。一旦同时进来申请过多，就会呈现计算资源竞争从而导致申请超时的状况。而 FaaS 的 “one concurrent request per instance” 人造符合这个场景，几乎就是绝配。

函数计算 FC 利用核心文件解决利用部署状况图

函数计算 FC 利用核心音视频解决利用部署状况图

函数计算 FC 利用核心 AI 利用部署状况图

https://www2.eecs.berkeley.edu/Pubs/TechRpts/2019/EECS-2019-3.pdf
https://glossary.cncf.io/serverless/
https://docs.aws.amazon.com/lambda/latest/operatorguide/scaling-concurrency.html
https://nathanpeck.com/concurrency-compared-lambda-fargate-app-runner/files/Concurrency%20Compared.pptx
https://help.aliyun.com/document_detail/438853.html
https://cloud.google.com/run/docs/about-concurrency?hl=zh-cn
https://developer.aliyun.com/article/1243681
https://developer.aliyun.com/article/1161868
https://help.aliyun.com/document_detail/606948.html
https://medium.com/1mgofficial/pdf-generation-with-aws-lambda-627b8dd07c77
https://realpython.com/python-concurrency/
基于函数计算利用核心落地案例参考
1. 网易云音乐音视频算法的 Serverless 摸索之路
2. 聚焦弹性问题，杭州铭师堂的 Serverless 之路
3. 优化 20% 资源老本，新东方的 Serverless 实际之路
4. 当 Rokid 遇上函数计算
5. 多家游戏公司 apk 实时打渠道包 repackAPK
6. …