函数计算的并发上限没有固定数字，它由单实例并发度、内存规格、超时时间和业务耗时四个参数共同决定，评估的核心方法是先测出单实例能扛住的并发量，再用峰值请求数除以它就得到实例数，最后对照账号配额确认是否够用。
函数计算并发上限怎么评估？先拆解这五个关键参数
很多人一上来就问“函数计算最高支持多少并发”，这其实把问题问窄了，函数计算的并发模型和传统服务器不同，它不是一个常驻进程被动接受连接，而是每个请求都会驱动平台拉起一个实例来执行，真正决定并发上限的，是你如何配置这五个参数。
单实例并发度：你给每个实例分配了几个“工位”
函数计算允许一个实例同时处理多个请求,这个数就是单实例并发度，默认值通常是1，意味着一个实例同一时刻只处理一个请求，如果你把它调到10，那一个实例就能同时服务10个请求。
评估并发上限时,单实例并发度是乘法因子，假设你有100个实例，并发度是1，那并发上限就是100；并发度调到10，上限就变成1000，但要注意，并发度不是越高越好，你写的代码得支持并发安全，如果函数内部有共享变量或者非线程安全的库，调高并发度反而会引入隐患。
内存规格与CPU分配：并发能力的“硬约束”
函数计算的实例规格由内存决定,常见的有128MB、256MB、512MB、1GB、2GB、3GB，内存越大，分配的CPU性能也越强，单实例能承载的并发请求数就越高。
行业共识认为,在同等代码逻辑下，1GB内存实例的并发处理能力通常是128MB实例的3到5倍，这直接影响你的成本模型：用大内存实例加高并发度，往往比用小内存实例加低并发度更省钱，因为实例数量更少，闲置开销更低。
超时时间：被大多数人在评估时忽略的“隐藏变量”
函数计算对单次请求有超时限制,一般默认60秒，最大可调到600秒（不同云厂商略有差异），很多人算并发的时候忘记把超时时间算进去，导致压测结果和线上表现严重不符。
超时时间影响的是长尾请求的并发堆积，假设你的函数平均耗时200毫秒，但偶发出现几秒甚至几十秒的慢请求，慢请求会占据实例的工位直到超时被强制结束，这意味着，评估并发上限时，需要预留一定比例的弹性空间来容纳慢请求，不然正常流量就会被异常请求“饿死”。
业务耗时：最基础也最容易被错误估算的量
单次请求的业务耗时,是评估并发上限的入手点，评估公式其实是小学级别的：
单实例能承载的并发 = 单实例并发度 ×（1000ms ÷ 平均耗时）
这条公式的准确度取决于你对耗时的估计准不准,建议不要拍脑袋，直接在函数里打日志，统计线上真实的P50、P99耗时，用P99作为计算基数更稳，因为P50算出来的结果在流量波动时大概率不够用。
账号配额：云厂商给你画的天花板
每个云厂商账号都有函数计算的并发配额限制,比如默认按量实例数上限可能是1000个，预留实例数上限可能是200个（具体数值以控制台配额页面为准），如果你的评估结果超过这个限额，需要提前在控制台申请提额，否则流量突增时新请求会被限流返回错误。
函数计算并发评估的实际操作流程：从压测到监控
原理讲完了,具体怎么操作？这里给出一套可以直接照着做的路径。
第一步：确定核心业务指标
先回答自己三个问题：峰值QPS是多少？单次请求平均耗时是多少？允许的失败率或延迟上限是多少？
这三个数字的来源建议从历史监控里捞,不要拍脑袋，如果是新业务没有历史数据，就参考同类系统的经验值，同时在系统上线初期把配额调得宽松一些，等有真实流量后再逐步收紧。
第二步：压测出单实例的真实承载能力
不需要搞很复杂的压测工具,直接用云厂商自带的压测功能，或者用开源的wrk、hey等工具对着函数URL发起请求就行。
具体操作路径：
- 在函数计算控制台把单实例并发度调到一个固定值,比如10。
- 用压测工具以不同的RPS（每秒请求数）打流量，从低到高逐级增加。
- 观察函数的平均耗时和错误率,当错误率开始上升或平均耗时显著膨胀时，就说明单实例达到承载极限了。
- 记录这个临界点的QPS,它就是该配置下单实例的真实并发承载能力。
业内专家指出,压测时不要只测平均值，要观察P99延迟曲线的拐点，拐点出现后继续加压，会换来大量超时错误。
第三步：根据压测结果反推实例数
用第一步得到的峰值QPS除以第二步得到的单实例承载QPS,就得到所需的并发实例数，公式如下：
所需实例数 = 峰值QPS ÷ 单实例承载QPS（向上取整）
然后把这个实例数和你账号的按量配额、预留配额分别对比，如果超出，要么优化代码降低耗时，要么申请提额，要么调高单实例并发度。
第四步：监控和自动扩缩容策略调优
函数计算平台自带弹性伸缩,默认会根据请求量自动增加或减少实例，你不需要手动管理实例数量，但需要为平台设置合理的扩容触发阈值和缩容保护时间。
建议开启按量实例的CPU使用率监控,当CPU使用率持续高于70%时，意味着实例接近饱和，需要增加并发度或申请更高配额，缩容保护时间建议设置在5到10分钟，避免流量抖动导致实例频繁销毁重建，反而增加冷启动开销。
函数计算预留并发和按量实例的权衡：成本与冷启动
评估并发上限时,光看数量还不够，还要看这些并发的来源是预留给你的，还是临时拉起来的。
预留并发是什么？池子里提前放好“热水”
预留并发是指你在函数计算控制台预先申请一批常驻实例,平台会提前把代码加载好、容器初始化好，请求来了直接复用，它的好处是没有冷启动延迟，响应非常稳定，坏处是你要为这些闲置的预热实例付费，不管有没有流量。
按量实例是什么？有活才干，没活睡觉
按量实例则由平台根据请求量动态创建,有流量时自动扩容，没流量时缩容到零，费用按实际执行时间和次数计算，不用不花钱，缺点就是冷启动：当流量突然增加，平台需要新拉起实例，这个过程可能要一秒钟甚至几秒钟，对延迟敏感的请求不友好。
怎么选？按业务容忍度来
举个例子：
- 一个面向外部用户的Web API，平均延迟要求低于200毫秒，必须用预留并发兜底，预留的实例数量通常设为峰值的60%到80%，剩余的靠按量实例弹性兜住突发流量。
- 一个分析用户上传文件的异步任务,处理耗时几十秒，用户不感知中间延迟，用按量实例就足够，还能节省相当一部分成本。
大部分只处理内部定时任务或消息队列消费的场景,其实不需要预留任何实例，如果用户体验没那么敏感，预留反而是浪费。
函数计算并发上限和成本的关系：怎么算才不心疼
并发上限升高,最直观的影响是费用增加，函数计算的计费主要由三部分组成：调用次数、执行时间、预留实例时长。
调用次数按万次计费,价格很低，通常一亿次调用费用在几百到上千元级别，执行时间按GB-秒计费，也就是内存大小乘以执行时长再乘以单价，预留实例则需要按实例规格和小时数付费，即使没有请求也要付钱。
国内主要云厂商的函数计算价格差异不大,但华东、华北、华南的不同地域节点在计费单价上可能略有不同，选择部署地域时也要把这一层因素纳入考虑。
拿一个具体场景算一笔账：
你的函数内存设为512MB,平均耗时500毫秒，峰值QPS是1000，单实例并发度为5，那么单实例承载约10QPS，总共需要100个实例。
- 全部用按量实例：费用等于调用次数费用加上执行时间费用，按市场常规定价，一天累计几万个GB-秒的消耗，折合人民币每天几十到上百元。
- 其中50个用预留实例,覆盖峰值流量的50%：预留部分按实例规格包小时计费，每天固定成本比按量高出一些，但延迟表现会好看很多。
多数情况下,小规模业务用纯按量实例就好，真正需要预留并发的是那些对延迟有硬性要求的生产级服务。
Q&A：函数计算并发上限和预留并发相关的常见疑问
函数计算并发上限和预留并发有什么区别？
并发上限是平台允许你同时运行的实例总数上限,它限制你最多能有多大的吞吐能力，预留并发是你从并发上限中划出的一部分固定常驻实例，专门用来保证低延迟和稳定响应，打个比方，并发上限是你能租的最多工位数，预留并发是你提前租下来并付了钱的固定工位，按量实例则是有人来了才临时加座的工位。
函数计算价格怎么算？并发评估越保守就越贵吗？
价格按调用次数、执行时间和预留实例时长三部分结算，并发评估得越保守，意味着你预留的实例越多，固定成本就越高，合理的思路是先用按量实例跑一段时间，积累真实监控数据后再决定要不要预留以及预留多少，简化成本的关键在于调大单实例并发度，用更少的实例承载更多请求，执行时间总量相同的情况下费用更低。
大流量突然涌入时，函数计算会直接崩掉吗？
不会直接崩掉,平台会立即创建新的按量实例来承接流量，直到达到账号配额上限，如果配额不够，新来的请求会被限流并返回429或503错误，而不是整个服务宕机，因此你只需要确保自己的配额评估留有合理余量，并且为关键业务申请足够的额度即可，一个实例从创建到就绪的冷启动过程通常需要一秒左右，期间延迟会短暂升高，但系统仍会持续尝试扩容来消化积压的请求。