把同一个 Serverless 应用部署到三家云：FunctionGraph、函数计算、Lambda 的一次横向实测

我手里有个小工具，干的事很简单：接 GitHub webhook，解析 push/release 事件，转发到飞书和钉钉机器人。Python 写的，连依赖加起来两百来行，部署在 AWS Lambda 上跑了两年多，一直没管它。最近因为给一个国内客户做项目，开始频繁用国内云，顺手把这个小应用也搬到华为云 FunctionGraph 和阿里云函数计算上跑了一遍，想看看三家实际体验差多少。

这篇文章不是给哪家带货。是我自己选型过程的记录，所有数据都基于我这个具体的小应用——它流量极小、单次执行不到一秒、Python runtime、HTTP 触发。换成一个 Java 大应用或者事件驱动型的流水线，结论可能完全不一样。我尽量把测试方法和原始数据摆出来，你自己对照你的场景判断。

测试时间是 2025 年下半年。Serverless 这个领域三家都在快速迭代，文中数据大概率半年后就过时，这点我最后还会再强调一次。

一、被测应用和测试方法

应用逻辑不复杂，核心 handler 长这样（三家逻辑共用，只是入口签名不同）：

def handle_event(headers, body):
    event_type = headers.get("X-GitHub-Event", "")
    if event_type == "push":
        repo = body["repository"]["full_name"]
        pusher = body["pusher"]["name"]
        commits = len(body.get("commits", []))
        msg = f"{pusher} pushed {commits} commits to {repo}"
    elif event_type == "release":
        repo = body["repository"]["full_name"]
        tag = body["release"]["tag_name"]
        msg = f"New release {tag} on {repo}"
    else:
        return {"status": "ignored"}
    send_to_feishu(msg)   # 一个 HTTP POST
    send_to_dingtalk(msg) # 一个 HTTP POST
    return {"status": "ok"}

就这点东西。单次执行两个 HTTP 出调用，耗时主要花在飞书/钉钉 API 上，大概 200-400ms。

测五个维度：

1. 冷启动延迟——函数闲置后首次调用的响应时间
2. 热调用延迟——连续调用下的 p50 / p99
3. 部署体验——从改代码到上线要几步、工具链好不好用
4. 触发器与事件源——能接哪些云服务、配置复不复杂
5. 计费——我这个流量下每月花多少钱

压测用的是一个简单的并发脚本，对每家打 1000 次请求，先打 1 次触发冷启动（单独记录），剩下 999 次统计热调用分布。每家测三轮取中位数。

二、部署体验：差距比想象中大

先说结论：部署体验上，AWS 最成熟但最重，阿里云最顺手，华为云最直观但工具链文档偏薄。

AWS Lambda 我用了两年，工具链是三家里最完善的——SAM、CDK、Serverless Framework 都有一等支持。但完善不等于简单。如果你第一次用，要在 IAM 里配执行角色、配 API Gateway、处理一层层 ARN 引用，学习曲线确实陡。对一个老手这是灵活性，对一个新人这是门槛。

阿里云函数计算（FC） 的体验出乎我意料地好。控制台能直接在线编辑代码、一键部署，本地用 Serverless Devs（s CLI）也顺。文档是中文的，而且不是那种机翻中文，是有人写的，带完整示例。我半小时就把应用部署通了，这是三家里最快的。

华为云 FunctionGraph 的控制台是三家里可视化做得最直观的——函数、触发器、监控在一个页面里拖拽式配置，信息密度高，不用来回跳页面。但 CLI 和 IaC 工具链的文档偏薄。我试了用 Serverless Framework 的华为云插件部署，插件存在但文档示例少，遇到一个 credentials 配置的坑翻了半天 issue 才解决。后来直接用控制台部署，反而快。

每家都有让我吐槽的地方：

• Lambda 的 IAM 策略配置，对一个只读 webhook 的小函数来说，权限 YAML 写起来啰嗦得过分。
• FC 的日志默认查询界面卡，按 request ID 检索要等好几秒才出结果。
• FunctionGraph 的 Python runtime 版本更新比另外两家慢半拍，我想用 3.11 的时候它主推的还是 3.9，后来才支持上。

三、冷启动：Serverless 最有争议的一个数

冷启动是 Serverless 逃不开的话题，也是很多人不敢用的主要原因。我这个应用 Python runtime、128MB 内存，实测数据如下（三轮中位数）：

几个观察：

第一，三家的冷启动都在可接受范围。 我这个 webhook 应用，用户感知的是 GitHub 那边重试间隔（默认是立即，失败后递增），800ms 的冷启动完全不会丢事件。很多人对冷启动的恐惧是被早期数据吓出来的，2025 年三家的冷启动对 Python 小函数来说已经不是大问题。

第二，阿里云 FC 冷启动最快。 我没有内部数据解释原因，猜测和它的实例调度策略有关。但这个优势在我的场景下意义不大——冷启动只发生在闲置后首次调用，我的应用白天调用频繁，基本不冷。

第三，要彻底消除冷启动，三家都有"预留实例"机制，但叫法和配置方式不同。 AWS 叫 Provisioned Concurrency，阿里云叫预留实例，华为云 FunctionGraph 叫预留实例。开了之后冷启动消失，但要为预留的实例持续付费，对小流量应用不划算。我这个应用没开。

压测脚本核心就这几行：

import asyncio, aiohttp, time

async def hit(session, url, idx):
    t0 = time.perf_counter()
    async with session.post(url, json=PAYLOAD) as r:
        await r.text()
    return time.perf_counter() - t0

async def main(url, n=1000):
    async with aiohttp.ClientSession() as s:
        # 第 1 次单独跑，算冷启动
        cold = await hit(s, url, 0)
        # 剩下并发打
        times = await asyncio.gather(*[hit(s, url, i) for i in range(1, n)])
        times.sort()
        print(f"cold={cold*1000:.0f}ms p50={times[n//2]*1000:.0f}ms p99={times[int(n*0.99)]*1000:.0f}ms")

asyncio.run(main(URL))

四、触发器与事件源：生态差距是真实存在的

这一项差距最明显，而且不是靠单产品努力能追上的——触发器生态取决于你整朵云有多少服务能和函数计算联动。

AWS Lambda 能直连的服务最多：S3、DynamoDB Streams、Kinesis、SQS、SNS、EventBridge、CloudWatch、API Gateway、ALB……几十种。基本上 AWS 每出一个新服务，都会带一个 Lambda 触发器集成。这是先发优势和生态规模的体现。

阿里云 FC 主流触发器都有：OSS 事件、日志服务 SLS、定时器、HTTP、MNS、EventBridge。覆盖 90% 的常见场景没问题。我用到的是 HTTP 触发器，配置简单。

华为云 FunctionGraph 支持 OBS 事件、DIS、Timer、SMN、APIG（API 网关）、DMS。主流场景够用，但长尾服务的集成数量不如前两家。如果你的架构里用了某个相对小众的华为云服务，想让它触发函数，可能得自己写一层轮询。

对我的应用来说，GitHub webhook 是纯 HTTP 触发，三家零差异。但如果我要做的是"OBS 上传图片后自动转码"这种事件驱动场景，三家都能做，配置复杂度也差不多。真正有差距的是那种"用一个冷门服务的事件触发函数"的场景——AWS 几乎一定支持，国内两家要看具体服务。

五、计费：别只看单价，看计费粒度和免费额度

三家的计费模型结构相似：按请求次数 + 按执行时长 × 配置内存。但免费额度和计费粒度有差异，对小流量应用影响很大。

• AWS Lambda：每月前 100 万次请求免费，之后 $0.20/百万请求；计算部分 $0.00001667/GB-second。没有长期免费层级之外的额外赠送。
• 阿里云 FC：有免费额度（按月，请求次数和执行时长都有赠送），超出后单价和 Lambda 接近，按人民币计价对国内用户友好。
• 华为云 FunctionGraph：也有免费额度，计费粒度到毫秒。

我的应用每月大概 3000 次调用，单次执行约 300ms，128MB 内存。算下来：

我这个流量三家都白嫖。这说明一个反直觉的点：对于流量极小的应用，三家的实际花费都是零，选型不该被单价主导，而该被免费额度和开发体验主导。 真正拉开花费差距的是中高流量场景——月调用百万次以上时，单价的微小差异和计费粒度（有的按 100ms 向上取整，有的按 1ms）才会体现出来。

我另外算了一笔账：如果月调用涨到 500 万次、单次 500ms、256MB 内存，三家月费用都在几十块到一百多块人民币量级，差距在 20%-30% 之间，没有数量级差异。所以"哪家 Serverless 便宜"这个问题，在 2025 年的答案不是"哪家单价低"，而是"你的用量落在哪个区间、免费额度怎么用最划算"。

六、可观测性：排查问题时的体感

Serverless 应用排查问题全靠日志和链路追踪，因为你看不到机器进不去容器。这一项体感差异不小。

AWS CloudWatch 最完善——结构化日志、Metrics、X-Ray 链路追踪一整套，而且和 Lambda 集成最深，函数日志自动进 CloudWatch。缺点是贵。CloudWatch Logs 的存储和查询费用在 AWS 账单里是个常被吐槽的项，我这个小应用每月日志费比计算费还高。

阿里云 FC 接日志服务 SLS，查询能力不弱，支持按 request ID 检索整条调用链。但前面说过控制台查询界面响应偏慢，急的时候让人烦躁。

华为云 FunctionGraph 的日志走 LTS（日志服务），函数执行日志默认采集，能按请求 ID 过滤。链路追踪这块接 APM，配置要额外开。整体够用，但链路追踪的自动埋点深度不如 X-Ray——X-Ray 对下游 HTTP 调用能自动记一段，华为云这边我要手动在出调用前后加 span 才能看全。

对我的应用，排查体验排序是 AWS > 阿里云 ≈ 华为云。但 AWS 的优势是用钱堆出来的，不是纯体验优势。

七、所以到底选哪家

到这了，给明确结论，不和稀泥。

如果你符合以下任一条件，留在 AWS Lambda：

• 已经在 AWS 生态里，函数要和 S3/DynamoDB/Kinesis 等服务深度联动
• 流量大、对可观测性要求高、预算能接受 CloudWatch 的费用
• 团队已经熟悉 SAM/CDK，不想再学一套工具

如果你符合以下任一条件，选阿里云 FC：

• 业务在国内、用户在国内、要低延迟
• 依赖中文文档和中文工单支持
• 主流触发器够用，不碰长尾服务集成

如果你符合以下任一条件，选华为云 FunctionGraph：

• 已经在华为云生态里（用了 OBS、ECS、ModelArts 等），函数和这些服务联动
• 偏好控制台可视化操作，团队对 IaC 不熟
• 有华为云的免费额度或代金券可用

我自己的这个小应用，最后留在了阿里云 FC。 原因很具体：我的 webhook 源是 GitHub，从国内函数调 GitHub API 偶尔会超时，但飞书/钉钉这两个下游在国内，函数放国内整体延迟更低；阿里云 FC 的部署体验和中文文档对我这个偶尔才改一次代码的小工具最友好；华为云 FunctionGraph 体验也不差，但我手头阿里云账号更现成。这个选择和"哪家技术更好"关系不大，和"我现有的资源在哪"关系很大——这点我觉得是大多数 Serverless 选型的真实逻辑。

八、几点超出选型本身的感受

写完这篇，有几个感受不局限于这三家产品。

第一，Serverless 选型本质是选生态，不是选函数计算这个单产品。 函数计算本身的能力，三家在 2025 年已经高度趋同——冷启动、runtime、触发器、计费，核心维度拉不开代差。真正决定你用哪家舒服的，是你其他服务在哪：你的存储用谁、你的消息队列用谁、你的监控用谁。函数计算是生态里的一环，单独评估它意义有限。

第二，国内云在 Serverless 上的差距，不在核心能力，在工具链和长尾集成。 控制台体验、核心 runtime 性能、主流触发器，华为云和阿里云都不差，部分维度还比 AWS 顺手。但 IaC 工具链的成熟度、文档的完整度、冷门服务的事件集成，和 AWS 还有距离。这个差距在缩小，但不是一两年能抹平的，因为生态是靠时间和用户量堆出来的。

第三，独立评测的局限性要讲清楚。 我这篇文章的样本是一个应用、一种语言、一个流量级别、一次测试时间点。Serverless 平台更新很快——冷启动优化、runtime 版本、计费规则都在变，我测出来的数字半年后未必成立。如果你要做正式选型，别拿我的数据当依据，自己用你的真实应用测一遍。评测文的价值不是给结论，是给测试方法和思考维度——你照着我的维度测你自己的场景，结论才有意义。

第四，"哪家便宜"是最不该问的问题。 至少在 2025 年的 Serverless 领域，三家单价没有数量级差异，免费额度又都能覆盖小流量。真正该问的是"我的用量结构下哪家计费模型更划算"“我的技术栈和哪家生态更贴合”“我的团队能高效维护哪家”。单价是选型里最不重要的维度之一，却是最常被拿来对比的，本末倒置。

最后一句：如果你也维护着类似的小工具，别纠结选型太久。流量没到一定量级之前，三家用起来都是白嫖，选一个你账号现成、文档看得顺、部署最省事的就行。等流量真涨上来了、痛点真出现了，再迁移不迟——Serverless 的好处之一就是函数本身可移植性还行，迁移成本没有想象中高。