1. 从“管理服务器”到“管理并发”Serverless计算的核心范式转变如果你和我一样在云计算领域摸爬滚打了几年从早期的虚拟主机到后来的容器编排再到现在的Serverless一个最直观的感受是我们关心的东西变了。以前我们总在琢磨“我的服务器需要多少核CPU、多少G内存”现在尤其是在使用像AWS Lambda、阿里云函数计算或者Google Cloud Run这类服务时我们更多地在思考“我的函数或应用能同时处理多少个请求”。这个“同时处理请求的能力”就是并发度。为什么这些主流的Serverless计算产品不约而同地选择了并发度而不是我们更熟悉的CPU利用率或内存使用率作为自动扩缩容的黄金指标这背后其实是一场从“资源视角”到“请求视角”的深刻范式转移。今天我就结合自己踩过的坑和做过的架构设计来拆解一下并发度在Serverless世界里的核心地位以及我们该如何用好它。2. 并发度的本质从操作系统到云服务的抽象跃迁要理解Serverless为什么用并发度首先得抛开云服务的概念回到计算机科学的基础——并发本身。2.1 并发的底层逻辑从进程到请求的封装并发简单说就是系统同时处理多个任务的能力。这个“任务”的粒度在不同层面有不同的体现。在操作系统层面是进程和线程在Web服务器层面是HTTP请求在函数计算层面是一个个触发事件。Serverless计算所做的正是将“并发”这个底层概念封装成了一个面向开发者、更贴近业务逻辑的上层指标。回想一下用PHP-FPMFastCGI进程管理器部署Web应用的日子。我们会配置pm.max_children参数它定义了PHP-FPM进程池中最多可以有多少个子进程。每一个进来的HTTP请求都会由一个独立的PHP进程来处理。这里的“并发度”本质上就是同时活跃的PHP进程数。作为开发者我们需要预估流量手动设置这个值并且还要操心底层有多少台ECS服务器来承载这些进程。这里存在两个经典难题一是进程间的资源隔离与争抢一个写坏了的脚本可能拖垮整台机器二是扩容不敏捷流量突增时需要手动增加服务器并调整负载均衡。Serverless计算特别是FaaS可以看作是对这种“单进程单请求”模型的现代化、托管化升级。FaaS平台接管了所有底层基础设施的管理包括安全隔离、资源调度和自动扩缩容。它向开发者暴露的抽象不再是服务器或容器而是函数实例。一个函数实例在典型的FaaS模型单实例单并发下一次只处理一个请求。当并发请求数超过现有实例数时平台会自动、快速地创建新的实例。此时对开发者而言系统的“并发能力”就等于函数实例数。这个模型极其简洁开发者只需要关注业务代码和单个请求的处理逻辑无需关心背后有多少台机器在跑。2.2 并发度作为扩缩容指标的天然优势为什么是并发度而不是CPU使用率这得从Serverless的两个核心承诺说起极致弹性和按需付费。首先冷启动与0-1扩容。Serverless允许实例缩容到0。当第一个请求到来时需要从零启动一个全新的实例冷启动。在这个过程中CPU使用率是0内存使用率也是0因为实例还没创建。任何基于资源利用率的监控指标在这个从0到1的关键时刻都是失效的。唯一能触发这次扩容的就是“有一个请求需要被处理”这个事件本身。而“并发请求数”正是对这个事件最直接的度量。平台监控到当前活跃请求数或待处理请求数超过了现有实例的处理能力就会立即触发扩容。这种基于请求驱动的扩缩容响应速度是最快的因为它直接对接了业务的流量信号。其次资源利用与成本优化。在传统的基于CPU利用率的扩缩容策略如Kubernetes HPA中我们通常会设置一个目标值比如CPU利用率70%。当平均利用率超过70%就扩容低于50%就缩容。这个模型在常驻服务中很有效但在Serverless的按执行时长计费模型下就可能产生浪费。假设一个函数处理单个请求只需要0.1秒的CPU burst但请求间隔有0.9秒。在单实例单并发模型下这个实例在0.9秒内是空闲的但为了随时响应下一个请求它必须保持“热”状态虽然可能不计费或按更低标准计费。如果采用CPU利用率来判断这10%的平均利用率远低于缩容阈值实例会一直保留造成资源闲置。而基于并发度的扩缩容可以更精确地匹配请求的到达模式。没有并发请求时实例可以更快地回收请求并发数上升时立即按需增加实例。注意这里说的“资源闲置”在FaaS计费中可能不产生计算费用但平台仍需为这些“热实例”预留底层资源从全局资源效率看仍有优化空间。这也是催生“单实例多并发”模型的重要动力之一。3. 单实例单并发FaaS的经典模型及其挑战以AWS Lambda、早期的阿里云函数计算为代表的经典FaaS服务采用的就是“单实例单并发”模型。这个模型理解起来非常简单一个函数实例同一时间只处理一个请求。就像银行的一个服务窗口一次只接待一位客户。3.1 工作原理与资源视图当事件触发函数执行时FaaS平台会寻找一个空闲的、已初始化的“热实例”。如果找到请求立即被处理这就是“热启动”延迟极低。如果所有热实例都在忙或者根本没有热实例冷状态平台就会启动一个新容器来创建函数实例加载你的代码和运行时这个过程就是“冷启动”会带来几百毫秒到几秒不等的额外延迟。从资源视角看这个模型对CPU密集型任务非常友好。因为一个实例100%的时间都在为一个请求进行纯计算CPU资源被充分利用没有在等待I/O上浪费时间。计费也清晰明了从请求开始处理到返回结果这期间的CPU时间通常精确到毫秒就是计费时长。3.2 面临的现实挑战I/O密集型场景的困境然而现代应用大量的是I/O密集型操作查询数据库、调用第三方API、读写对象存储、处理消息队列等。这些操作的特点是CPU发出一个I/O指令后就需要等待外部系统的响应这个等待时间可能比CPU处理时间长几个数量级。在单实例单并发模型下问题就凸显了严重的资源空闲与浪费实例在等待数据库返回数据时CPU是空闲的但该实例却被这个请求独占无法处理其他请求。如下图所示蓝色块是CPU工作时间红色块是I/O等待时间大量空白区域意味着资源未被有效利用。请求1: [CPU工作|---I/O等待-------------------|] 请求2: [CPU工作|---I/O等待---|] 时间线|----------------------------------------------------在并发请求高峰期为了维持低延迟平台不得不创建大量实例。每个实例大部分时间都在“空转”等待I/O从整体资源利用率角度看这是巨大的浪费。对下游共享资源的压力最典型的例子是数据库连接。传统应用服务器使用数据库连接池来复用连接比如一个服务实例维持10个数据库连接可以高效地服务上百个并发请求请求在连接池队列中等待可用连接。但在单实例单并发的FaaS模型下一个请求就对应一个实例也倾向于建立一个独立的数据库连接。如果瞬间有1000个并发请求就可能试图建立1000个数据库连接这很容易超过数据库的最大连接数限制导致数据库被压垮或拒绝服务形成“连接风暴”。实操心得早期我们在Lambda上运行一个需要频繁查询RDS MySQL的服务时就遭遇过“连接风暴”。解决方案是在函数层面前置一个RDS ProxyAWS的数据库代理服务它作为连接池将函数实例的大量短连接汇聚成较少的长连接与数据库通信有效缓解了数据库压力。如果你的Serverless应用严重依赖关系型数据库一定要提前规划好连接管理策略。4. 单实例多并发Serverless的进化与Google Cloud Run的实践为了解决上述痛点Serverless计算演进出了“单实例多并发”模型。Google Cloud Run是这一模型的典型代表它允许一个容器实例同时处理多个请求默认最多80个可配置至1000个。这就像银行的一个窗口现在可以同时处理多位客户的简单业务比如填单咨询但复杂的业务如大额转账仍需排队或占用更多时间。4.1 如何实现与核心优势在技术上这通常要求你的应用代码是并发友好的。对于Web应用这意味着使用支持多线程或多进程模型的框架如Go的net/http、Java的Servlet容器、Python的Gunicorn多Worker等。当请求到达Cloud Run实例时容器内的Web服务器会分配一个线程或子进程来处理它。这个模型带来了两大核心优势大幅提升资源利用率降低成本I/O等待不再是资源的“杀手”。当一个请求在等待数据库时同一个实例内的其他线程可以处理新的请求CPU时间被更充分地利用。从计费角度看由于单个实例能处理更多请求完成相同工作量所需的实例总数可能减少从而降低了总体成本虽然单个实例的运行时间可能变长但Cloud Run等按请求处理时长计费整体更划算。平滑下游压力连接池得以复用由于单个实例可以处理多个请求我们可以在实例内部重建传统的“数据库连接池”。例如一个Cloud Run实例配置一个最大10个连接的数据库连接池。即使该实例同时收到80个请求也只有最多10个请求能同时持有数据库连接进行查询其余请求会在连接池队列中等待。这样下游数据库面对的不是海量的瞬时连接而是可控的、持续的连接压力。假设有10个这样的实例数据库面对的就是约100个连接而不是单实例单并发模型下可能出现的800个连接。4.2 FaaS的跟进与混合形态看到单实例多并发的优势传统的FaaS厂商也开始跟进。例如阿里云函数计算允许设置“实例并发度”一个函数实例可以连续或并行处理多个请求取决于运行时和函数配置。Google Cloud Functions第二代也支持了类似的特性。这带来了一种有趣的混合形态函数本身可以是单线程的但平台通过快速复用同一个实例来处理序列化的请求流。对于某些语言运行时如Python、Node.js虽然函数处理程序本身是单线程的但平台可以在一个请求结束后、实例销毁前迅速将下一个请求路由给它实现了请求的“准并发”处理同样提升了实例的利用率。5. 并发度配置的艺术从手动调优到智能推荐无论是单实例单并发还是多并发一个无法回避的问题是这个并发度到底该设置为多少这成了Serverless架构师一个新的调优维度。5.1 配置不当的后果并发度设置过低在流量波峰时会导致大量请求排队等待响应延迟Latency增加甚至因超时而失败。对于单实例多并发模型设置过低也浪费了实例的资源潜力。并发度设置过高在单实例多并发模型中过高的并发度可能导致单个实例内存耗尽每个请求都占用一些内存或者线程/进程切换开销过大反而降低整体吞吐。更重要的是它会放大下游依赖的压力。如果每个实例的并发度是100那么只需10个实例就能产生1000个对下游服务的并发请求可能瞬间击垮未做好防护的后端服务如数据库、第三方API。5.2 手动调优方法论业界通常的建议是进行压力测试。你需要基准测试测量单个请求在目标实例规格CPU/内存下的平均响应时间、峰值内存消耗。递增负载测试逐步增加并发请求数观察响应时间、错误率的变化曲线。找到响应时间开始显著上升或错误率出现的拐点。考虑下游依赖评估下游服务如数据库、API的承受能力。你的实例并发度设置应确保在最大预期实例数下对下游的并发请求总量不超过其容量。设置安全边界通常不会将并发度设置为压测得到的极限值而是留出一定的缓冲空间例如极限值的70%以应对流量波动和意外情况。这个过程耗时耗力并且当应用逻辑或依赖发生变化时需要重新进行。5.3 自动化与智能化探索正因为手动调优的复杂性领先的云厂商开始探索自动化方案。例如阿里云函数计算推出了智能并发度推荐功能。其原理大致是监控与学习平台在函数运行时持续监控每个请求的CPU使用率、内存使用量、执行时长、I/O等待时间等指标。分析与建模通过分析这些指标判断函数是CPU密集型还是I/O密集型。对于I/O密集型函数平台可以识别出CPU空闲的时段从而建议提高实例并发度让CPU在等待I/O时去处理其他请求。推荐与验证平台会给出一个并发度建议值并可以在安全的环境如预发环境或小比例流量上进行自动验证观察效果后再全量推广。这代表了Serverless运维的未来方向从手动配置静态参数转向由平台基于实时负载进行动态、智能的调优。未来的“智能动态并发度”可能会根据每分钟甚至每秒的负载特征自动调整实例的并发处理能力在性能、成本和稳定性之间找到最佳平衡点。6. 如何选择单并发 vs 多并发场景化决策指南面对两种模型我们该如何选择这没有银弹需要根据具体的应用场景来决定。特性/场景单实例单并发 (经典FaaS)单实例多并发 (Cloud Run/支持并发的FaaS)资源隔离与安全性极高。每个请求在完全隔离的实例中运行故障、安全漏洞或资源超用完全不影响其他请求。较高。依赖容器/进程级别的隔离同一实例内请求共享OS资源一个出错的请求可能影响同实例的其他请求如耗尽内存。CPU密集型任务绝佳选择。资源独占无竞争性能可预测。例如视频转码、图像处理、科学计算。不推荐。多个CPU密集型任务在同一个实例内会激烈竞争CPU资源导致所有任务都变慢。I/O密集型任务效率较低。等待I/O时资源闲置需要更多实例成本可能较高。理想选择。充分利用I/O等待时间处理其他请求资源利用率高成本更优。例如大多数Web API、数据查询服务。有状态或长时连接挑战大。实例可能随时被回收状态难以维持。WebSocket等长连接实现复杂。相对容易。实例生命周期更长可以在内存中维持一定状态更适合WebSocket等场景。冷启动影响更敏感。每个新并发都可能触发冷启动。影响较小。一个实例服务多个请求分摊了冷启动开销平均延迟可能更低。下游连接管理复杂。容易导致下游连接数激增需要借助代理或Serverless数据库。简单。可在实例内使用连接池有效管理下游连接保护后端服务。个人经验与建议选择单实例单并发当你需要最强的隔离性和可预测性时比如处理支付交易、运行不受信任的第三方代码、或者执行对CPU和内存有稳定要求的批处理任务。最近大火的AIGC应用就是典型例子。一个Stable Diffusion模型在A10 GPU上推理一次只能处理个位数请求。如果采用多并发请求会在GPU上排队延迟变得不可控。而FaaS的单并发模型每个请求独享一个GPU实例延迟稳定完美匹配。选择单实例多并发当你构建标准的Web服务或API时绝大多数面向用户的Web应用、微服务都是I/O密集型的。使用Cloud Run或配置了并发度的函数计算可以获得更好的资源利用率、更低的成本和更简单的下游依赖管理。这也是为什么在阿里云函数计算应用中心Web应用和API网关触发的函数部署量巨大的原因。采用混合架构不要试图用一个模型解决所有问题。在一个系统中可以将CPU密集型的模块如视频缩略图生成拆分成独立的单并发函数而将I/O密集型的业务逻辑如用户信息查询API部署在多并发的服务中。通过消息队列或事件总线将它们连接起来各取所长。Serverless计算用并发度作为扩缩容的核心指标绝不是偶然。它精准地捕捉了Serverless“事件驱动、按需执行”的本质将开发者的心智从繁琐的资源管理拉回到了业务逻辑本身。理解单并发与多并发模型的差异并能够根据业务场景熟练配置和调优并发度已经成为现代云架构师的一项关键技能。从手动压测到智能推荐平台正在努力降低这项技能的掌握门槛但背后的原理和权衡始终值得我们深入思考。毕竟最好的工具永远在懂得其原理的人手中才能发挥最大威力。