你准备开一家线上点心铺，但不想租店面、雇厨师。你把招牌菜谱交给“云上私厨”平台——有人下单时，平台的师傅才把你的菜谱拿出来现做，没人下单就不开火、不收费；客人突然爆满，厨房还能自动多开几个灶台。这就是 Serverless（无服务器）的浪漫：你专心研究菜谱（业务代码），把灶台、燃气、洗碗工全部外包。如今市面上的云上私厨三足鼎立：AWS Lambda 是老牌连锁私厨，菜系最全、分店最多；Azure Functions 是企业行政厨房，和自家办公楼（微软生态）无缝衔接；Google Cloud Functions 是极客小厨房，玩转数据与容器。这篇指南会带你试吃三家：比菜单（功能）、比上菜速度（性能）、比账单（定价）、比候场策略（冷启动优化）、比做 AI 大菜（模型推理），最后教你怎么给自家铺子选厨房。

岗位关联

掌握三大 FaaS 平台的差异，你才能在真实项目中做出性价比最高的架构决策——这正是云原生工程师的核心竞争力。

目录
  1. 可视化演示
  2. 功能差异
  3. 性能基准
  4. 定价模型
  5. 冷启动优化
  6. AI推理部署
  7. 平台选型
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

对比AWS Lambda、Azure Functions、GCP Cloud Functions的触发器数量、冷启动时序与定价模型，切换模式查看不同维度。

本节配有交互动效（进入视口后自动加载，约 3KB）。

三大FaaS平台功能对比 AWS Lambda 30+触发器生态最丰富 Azure/GCP触发器较少但冷启动更优 triggers = f(platform) 触发器数量决定集成能力

功能差异

想象你要开一家线上点心铺，把菜谱交给云上私厨后，第一件事就是翻三家平台的“菜单”。AWS Lambda 是老牌连锁私厨，菜系最全，Node.js、Python、Java、Go、Ruby、.NET 等主流语言几乎通吃；Azure Functions 是企业行政厨房，对 .NET/C# 最友好，也支持 Node、Python、Java；Google Cloud Functions 则是极客小厨房，以 Node、Python、Go 为核心。菜单之外还要看“下单渠道”——也就是触发器（Trigger）。AWS 能接 S3 上传、API 请求、数据库变更、消息队列等上百种事件源；Azure 与自家 Office 365、Active Directory、Event Grid 深度绑定；GCP 则紧贴 Cloud Pub/Sub、存储桶和 GKE。

部署体验上，AWS 有 SAM 与 Serverless Framework 加持，社区模板最丰富；Azure 有 Visual Studio 全家桶，企业级 CI/CD 流水线顺滑；GCP 与 Cloud Build、Cloud Run 耦合紧密。配额限制也要留意：各家对函数包体积、账户函数总数、并发数都有不同上限，AWS 压缩包上限相对保守，而 GCP Gen2 借助 Cloud Run 内核可承载更厚的镜像。把需求列成清单，给每家打分，是最直观的选型起点。

所以，先看菜单再下馆子。假如你要做深度学习服务，语言支持就得重点考察；假如业务靠消息队列驱动，触发器生态就是命门。别被招牌菜吸引，要看自己常点的那几道菜，三家厨房谁做得最好。

Scoreplatform=∑i=1nwi×xi\displaystyle Score_{platform} = \sum_{i=1}^{n} w_i \times x_i
通俗解释：选平台就像给厨房打综合分：给每个功能项（菜单、渠道、部署、配额）按重要性定权重 w，再乘上它是否达标 x，最后全部加起来。
  1. 加权求和符 Σ从第 1 项加到第 n 项，把每个功能的得分都累计起来，得到平台最终总分。
    ∑i=1n\sum_{i=1}^{n}
  2. 权重 w_i每个功能对你业务的重要程度，比如“触发器生态”你给 0.4，其他项给 0.2，权重之和为 1。
    wiw_i
  3. 支持标记 x_i平台支持该功能记为 1，不支持记为 0；支持得越多、权重越大的项目被覆盖，总分越高。
    xi∈{0,1}x_i \in \{0, 1\}

性能基准

点完单，食客最关心的就是“多久能吃上”。云上私厨有个尴尬之处：没单时厨房是冷清的，第一单客人来了，大师傅才从家里被叫来、系围裙、开火热身——这段“从下单到开炒”的耽搁，业内叫冷启动（Cold Start）。试想，高峰期同时来一百桌客人，厨房就要临时从人才市场叫一百个师傅，速度自然千差万别。

端到端延迟 = 冷启动 + 执行 + 网络传输。AWS Lambda 用 Python/Node 时冷启动通常 100~400ms，Java 可能到 1~2 秒；Azure Functions 在 .NET 场景表现扎实，整体中规中矩；GCP Cloud Functions 冷启动常在 100~500ms，Gen2 基于 Cloud Run 后更稳定。并发扩展上，三家默认都能扛上千并发，AWS 默认账户级 1000（可申请调高），Azure 消费计划动态扩容，GCP 默认约 1000 并可配额调节。超时上限方面，AWS 最长 15 分钟，Azure 消费计划默认 5 分钟、上限约 10 分钟，GCP Gen1 为 9 分钟、Gen2 的 HTTP 函数可达 60 分钟。内存范围 AWS 从 128MB 到 10GB 最宽，跑 AI 负载更有发挥空间。

冷启动就像新客到店时厨师的“手生”期。经常被点单的店会留几个“候场师傅”随叫随到，这就是后面要讲的预留并发。而真正的高手，会从赶路、颠勺、端菜三个环节同时下手，把总延迟压到最低。

Latencytotal=Latencycold+Latencycompute+Latencytransfer\displaystyle \text{Latency}_{total} = \text{Latency}_{cold} + \text{Latency}_{compute} + \text{Latency}_{transfer}
通俗解释：总上菜时间 = 厨子赶路（冷启动）+ 颠勺翻炒（执行）+ 服务员端菜（网络传输）。想快，三环都得省。
  1. 冷启动 Latency_cold平台从容器池拉出新实例、初始化运行时的耗时，是用户感知最明显的部分，也是优化重点。
    Latencycold\text{Latency}_{cold}
  2. 计算耗时 Latency_compute函数业务代码真正运行的时间，受分配的内存与 CPU 影响，调大配置通常能缩短。
    Latencycompute\text{Latency}_{compute}
  3. 传输耗时 Latency_transfer请求从网关到函数、结果再返回客户端的网络开销，函数部署地域应尽量贴近用户。
    Latencytransfer\text{Latency}_{transfer}

定价模型

月底对账时，私厨平台按两把尺子收钱：接了“多少单”（请求数），以及每单“占着灶台多久、用了多大锅”（内存 × 时长，单位 GB-秒）。大锅贵、小锅便宜；没人点单，灶台就不计费。好比你去食堂打菜，既按菜的数量收钱，又按你占着餐盘的时间收“翻台费”。

请求计量上，AWS 与 Azure 都是每百万请求约 0.2 美元级别，GCP 每百万请求 0.4 美元但免费额度最慷慨（每月 200 万次）。计算时长上，三家 GB-秒单价大致在同一数量级（约每百万 GB-秒 10~20 美元），AWS 按 1ms 粒度计费最精细，短任务不吃亏；Azure 与 GCP 按 GB-秒累计。免费额度：AWS 每月 100 万请求 + 40 万 GB-秒；Azure 同样 100 万 + 40 万 GB-秒；GCP 给 200 万请求 + 40 万 GB-秒。隐含成本千万别忽略：出网流量费、VPC/NAT 网关费、预留并发固定费、日志监控费——这些“附加小菜”往往让账单悄悄变胖。

别只看“免费额度第一名”。点单频繁、单次又长的重型 AI 任务，免费额度很快就用完，之后每 GB-秒 都在滴血。挑厨房前，先按自家客流量算一遍总账，再决定把招牌菜交给谁。

Costmonth=Nreq×Preq+Gtotal×PGBs,Gtotal=∑iTi×Mi\displaystyle \text{Cost}_{month} = N_{req} \times P_{req} + G_{total} \times P_{GBs}, \quad G_{total} = \sum_{i} T_i \times M_i
通俗解释：月账单 = 单量 × 每单手续费 + 总占用灶台时间 × 每 GB-秒 的价。G_total 就是把每次执行的时长 T 和内存 M 乘起来再累加。
  1. 请求费 N_req × P_req调用次数乘以每百万请求单价，小流量时几乎可以忽略，高并发时是主要账单项之一。
    Nreq×PreqN_{req} \times P_{req}
  2. GB-秒总量 G_total每次执行的内存（GB）乘时长（秒），再对所有调用求和。内存 1GB 跑 1 秒就是 1 GB-秒。
    Gtotal=∑iTi×Mi\textstyle G_{total} = \sum_{i} T_i \times M_i
  3. 单价 P_GBs每百万 GB-秒的价格，三家都在 10~20 美元区间浮动，具体以官方定价页为准。
    PGBsP_{GBs}

冷启动优化

顾客最烦“前面没厨子”，私厨平台应对冷启动有两大招：派“长期值班员”（预留并发），或者让厨子轻装快跑（精简依赖）。高手做菜前还会把常用调料提前摆上灶台（惰性初始化），而不是等点单了才手忙脚乱地翻找。冷启动就像厨师从家里赶来的过程，哪一段路堵车，上菜就晚几分钟。

冷启动有三段工序：下载代码包 → 解压并初始化运行时 → 执行全局初始化代码。对应的优化方向是：压缩依赖让包更小；换用启动快的语言（Python/Go/Node 优于 Java/.NET 冷启动）；用 Provisioned Concurrency（AWS 预留并发）或 Azure Premium 常驻实例让容器提前热好；把数据库连接、模型加载等重活从全局代码搬到首次使用时再偷偷完成，即“惰性初始化”。依赖打包也讲究：能合并的库就合并、删掉不必要的包、用层（Layer）缓存公共依赖，AWS 的层机制、Azure 的绑定扩展、GCP 的构建包都能减少解压负担。

和厨房一样，值班师傅的工资（预留并发费用）是固定的。只有当你的客流确实稳定时，雇值班员才划算；一天只有零星几单，不如让厨子随叫随到，把省下的钱投在优化菜谱（代码质量）上。

Coldratio=NcoldNtotal\displaystyle \text{Cold}_{ratio} = \frac{N_{cold}}{N_{total}}
通俗解释：冷启动比例 = 冷启动次数 ÷ 总调用次数。预留并发把分母变大、分子压低，比值无限趋近 0，就像每家店门口永远有师傅候着。
  1. 冷启动次数 N_cold调用发生时容器是新建的、需要初始化运行时的次数，通常出现在突发流量后的扩容阶段。
    NcoldN_{cold}
  2. 总调用次数 N_total函数一个计费周期内的全部调用，分母越大，单个冷启动的平均影响越小。
    NtotalN_{total}
  3. 比例趋近 0预留并发让活跃实例常驻，冷启动只发生在新建扩容实例时，Cold_ratio 大幅下降。
    Coldratio→0\text{Cold}_{ratio} \to 0

AI推理部署

把 AI 推理搬进云上私厨，等于备了一冰箱“昂贵食材”——模型权重动辄几百 MB 到数 GB。每次冷启动，后厨都要重新“洗菜切菜”（加载权重）；如果内存不够，菜还没下锅，锅就装不下了。轻量模型（500MB 以内）最适合 FaaS：把模型打进函数包或用层加载，内存选 1GB 以上，首轮推理稍慢，后续热路径就很快。

中大型模型的思路要换：AWS 上可用 Lambda + EFS 挂载权重，或用容器镜像自定义运行时；Azure 的 Premium 计划支持常驻实例，模型常驻内存后延迟更稳定；GCP 的 Gen2（Cloud Run 内核）支持更大内存与 GPU，适合批量推理。推理框架打包要克制：TensorFlow Lite、ONNX Runtime、TorchScript 都能显著缩小镜像；开启量化把 FP32 压成 INT8，模型体积可缩到四分之一；避免把训练代码与推理代码混装。函数最好异步化：把推理结果写回对象存储或消息队列，别让客户端干等——这正好发挥 FaaS 事件驱动的优势。

轻食小模型像快餐，云厨房端着走；大模型像佛跳墙，普通灶台真接不住——得找能挂“大冰箱”的厨房（大内存、EFS、GPU）。认清自家菜的重量，再挑灶，才是 AI 落地的正确姿势。

Throughputserve=Ninstances×1000Linfer(ms)\displaystyle \text{Throughput}_{serve} = N_{instances} \times \frac{1000}{L_{infer}(\mathrm{ms})}
通俗解释：服务吞吐 = 同时开火的灶台数 × 每口灶每秒出菜数。想让外卖窗口排队短，要么多开灶，要么加快每道菜。
  1. 实例数 N_instancesFaaS 自动扩出的同时执行实例数，受账户并发配额约束，配额越高能同时开的“灶台”越多。
    NinstancesN_{instances}
  2. 单实例速率 1000/L一次推理耗时 L 毫秒，1000 毫秒除以 L，就是每秒能完成的推理次数。
    1000Linfer(ms)\frac{1000}{L_{infer}(\mathrm{ms})}
  3. 乘积求总吞吐并发实例数与单实例速率相乘得到系统总吞吐，平台扩缩容能力决定了 N 能有多大。
    Ninstances×1000LinferN_{instances} \times \frac{1000}{L_{infer}}

平台选型

三家厨房都能做菜，但你的店开在哪条街上，早已决定了一大半。现有业务在 AWS 生态里，选 Lambda 最顺；公司全面拥抱微软 Office 365 与 Active Directory，Azure Functions 如虎添翼；团队天天和 Kubernetes、BigQuery 打交道，GCP 更对味。这就像选铺面：菜品可以换，但“位置”（云生态）很难平移。

团队技能是另一张底牌：会 C#/.NET 的团队上 Azure 几乎零学习成本；熟悉 Python/Node 的团队在三家都吃得开；懂 Go 的团队在 GCP 更丝滑。成本预算要按前文公式拉真实流量算 TCO，而不是只比免费额度；突发流量大、执行短、事件驱动明确的任务，FaaS 成本优势最大。别被“生态绑架”吓退，也别盲目押注单一平台。用 Serverless Framework 这类抽象层，把 AWS 与 GCP 的函数同时部署，可以按成本与延迟动态路由；多平台并跑还能获得容灾冗余，代价是监控与排障的双份复杂度。

选厨房不是选“最好吃的”，而是选“最顺路的”。老牌连锁 AWS 全能兜底，企业行政厨房 Azure 与微软生态咬合严密，极客小厨房 GCP 在数据与容器上更灵巧——按自己的客源、厨师和预算点菜，才是靠谱的决策。

TCO=Ccompute+Cops+Cmigration\displaystyle \text{TCO} = C_{compute} + C_{ops} + C_{migration}
通俗解释：总拥有成本 = 灶台燃气费（计算）+ 厨师管理费（运维）+ 搬厨房的费用（迁移）。很多人只算第一项，忽略了后两项才是无底洞。
  1. 计算成本 C_compute请求费、GB-秒费、出网流量费、预留并发费，属于“看得见的账单”，最容易精确估算。
    CcomputeC_{compute}
  2. 运维成本 C_ops监控、日志、CI/CD 链路的搭建与维护，跨平台部署时这套成本要乘以平台数量。
    CopsC_{ops}
  3. 迁移成本 C_migration改触发器、换 SDK、调配额，从一家平台搬到另一家的人工与风险成本，常被低估。
    CmigrationC_{migration}

AI 应用场景

图片上传自动处理流水线

阶段：数据预处理与事件驱动

解决的问题：传统方案要常驻一台服务器盯着对象存储，流量波谷时机器空转浪费钱，波峰时又容易积压。用 FaaS 后，对象存储的上传事件直接触发函数，自动裁剪、压缩，并调用 AI 图像分类模型打标签，按次计费、自动扩缩。

具体案例：某电商每天上传几十万张商品图，AWS S3 上传事件触发 Lambda 做缩略图生成与违规图片初筛，高峰期自动扩展到上千并发，低谷期零计算成本。

轻量 NLP 情感分析 API

阶段：模型部署与推理

解决的问题：单独托管一个情感分析模型服务，月费高且利用率低。把量化后的 ONNX 模型打进函数包，用预留并发压制冷启动，即可获得毫秒级热启动的推理 API。

具体案例：某客服系统把工单文本实时送入 GCP Cloud Functions，配合 Pub/Sub 异步处理与 Cloud Storage 结果回写，每百万次调用成本仅为传统 GPU 服务的零头。

多平台容灾与成本路由

阶段：架构选型与混合部署

解决的问题：单一 FaaS 平台故障会导致业务中断，且各家定价与延迟随地域波动。用抽象层把同一套审核模型同时部署到 AWS Lambda 与 GCP Functions，按实时价格与延迟路由流量，获得成本与可用性的双赢。

具体案例：某内容社区把文本审核服务双跑在两家平台，平时 70% 流量走价格低的平台，故障时秒级切流，全年节省约 35% 推理成本。

Python 演示

python39 行
#!/usr/bin/env python3# -*- coding: utf-8 -*-"""模拟三大 Serverless 平台的月成本与平均延迟对比"""  def monthly_cost(requests, gb_seconds, price_per_million_req, price_per_million_gbs):    """按月请求数与 GB-秒总量估算账单(美元)"""    return requests / 1e6 * price_per_million_req + gb_seconds / 1e6 * price_per_million_gbs  def avg_latency_ms(cold_ratio, cold_ms, warm_ms):    """按冷启动比例加权估算平均延迟"""    return cold_ratio * cold_ms + (1 - cold_ratio) * warm_ms  def main():    # 假设: 每月 200 万次调用, 平均内存 512MB, 每次执行 0.2 秒    requests_per_month = 2_000_000    memory_gb = 0.5    duration_s = 0.2    gb_seconds = requests_per_month * memory_gb * duration_s     # 字段: 名称, 冷启动比例, 冷启动延迟ms, 每百万请求美元, 每百万GB-秒美元    # 价格为示例值, 实际以各家官方定价页为准    platforms = [        ("AWS Lambda", 0.10, 450, 0.20, 16.67),        ("Azure Functions", 0.15, 520, 0.20, 16.00),        ("GCP Functions", 0.12, 480, 0.40, 13.10),    ]     print("平台               平均延迟(ms)  月成本(USD)")    for name, cold_ratio, cold_ms, p_req, p_gbs in platforms:        latency = avg_latency_ms(cold_ratio, cold_ms, 80)        cost = monthly_cost(requests_per_month, gb_seconds, p_req, p_gbs)        print(f"{name:<18}{latency:>12.1f}{cost:>14.2f}")  if __name__ == "__main__":    main()
目的：给定调用量、内存与时长，估算 AWS/Azure/GCP 三家的平均延迟与月账单，帮助你在选型前用数据说话。
  1. def monthly_cost(requests, gb_seconds, ...)把账单拆成“请求费 + GB-秒费”两部分，对应正文的定价公式。
  2. gb_seconds = requests_per_month * memory_gb * duration_s估算一个月累计消耗的 GB-秒总量，是计费的核心变量。
  3. platforms = [...]每家平台的冷启动比例、冷启动延迟、每百万请求价、每百万 GB-秒价，构成对比数据集。
  4. avg_latency_ms(cold_ratio, cold_ms, 80)冷启动占比越高，平均延迟越接近冷启动值，直观反映优化的紧迫性。
  5. print(f"{name:<18}...")格式化对齐输出对比表，读起来一目了然。

常见误区

误区听说 Serverless 叫“无服务器”，以为完全没有服务器在跑，甚至觉得它应该免费，毕竟“服务器都没有了”。

正解实际上“无服务器”指的是你不需要管理服务器，平台一直在用别人的虚拟机替你运行函数。账单依然存在，只是计费方式变成了“按请求次数 + 按 GB-秒资源量”，没人调用时确实零费用，有调用就得付钱。

为何常见：名字里的 “less“ 太容易让人望文生义，加上营销材料总强调”免运维“，初学者就把”免运维“脑补成了”免费用”。

误区我在博客上看到冷启动 100ms 级别，觉得对业务没什么影响，安心把函数跑起来就行。

正解那是轻量语言在理想集群下的数值；换成 Java/.NET 加上重型依赖，冷启动可能飙到 1~2 秒，而且每次实例回收后再扩容都会重新出现。对毫秒级 API 网关场景，这可能是致命的超时。

为何常见：基准测试往往展示最优场景，忽略了真实流量中实例回收、并发突刺和依赖体积带来的方差。

误区我担心任务跑不完，干脆把超时调到平台上限 15 分钟，这样最保险。

正解长超时会掩盖设计缺陷，比如代码里出现慢查询、死循环，费用也会随执行时长膨胀。Serverless 的哲学是“短小无状态”，长任务应该拆分成多个函数、用队列接力，或转用容器/工作流服务。

为何常见：新手把 FaaS 当成通用虚拟机来用，不理解超时上限其实是平台对“事件型短任务”的约定。

误区三家都支持 Node.js/Python，把代码原封不动复制过去，改改配置就能跑通。

正解触发器、SDK、环境变量、配额机制差异巨大：S3 事件换成 Blob 事件要重写粘合层，AWS 的 Layer 换成 GCP 的构建包也要调整。语言相同只代表“菜谱能看懂”，不等于“厨房设备一样”。

为何常见：语法一致容易造成“代码可移植”的错觉，忽略了平台 API 与事件模型的深层耦合。

面试题

Q1. FaaS 平台的核心特征是什么？

单选题 · easy

  • A.始终运行常驻的云服务器
  • B.按事件触发并自动计费执行← 正确答案
  • C.必须由手动配置伸缩机器
  • D.只支持少数静态编程语言

答案：B。FaaS 的核心是事件驱动、按调用计费、平台自动扩缩容。A 是传统服务器的特征，C 违背了“自动伸缩”的初衷，D 与事实相反——主流 FaaS 都支持多语言。

Q2. AWS Lambda 单个函数最长可执行多久？

单选题 · easy

  • A.最长能执行三十秒左右
  • B.最长能执行五分钟上下
  • C.最长能执行十五分钟左右← 正确答案
  • D.最长能执行一小时封顶

答案：C。AWS Lambda 的超时上限官方为 15 分钟（900 秒）。A 和 B 接近历史早期或默认配置的时长，D 是 GCP Gen2 对 HTTP 函数的上限，并非 Lambda 的。

Q3. 函数冷启动延迟主要来自哪一环节？

单选题 · mid

  • A.网络带宽传输的限制
  • B.运行时初始化与代码加载← 正确答案
  • C.数据库查询响应过于缓慢
  • D.函数业务代码逻辑报错

答案：B。冷启动指新容器从下载代码、初始化运行时到执行全局代码的过程，B 是主因。A 属于网络传输环节，C 是业务层性能，D 是代码缺陷，都与“冷启动”定义无关。

Q4. 以下哪些措施可以有效降低 Serverless 冷启动？

多选题 · mid

  • A.开启预留并发实例调度← 正确答案
  • B.精简函数依赖包体积← 正确答案
  • C.无限调大超时时间上限
  • D.惰性初始化全局状态对象← 正确答案

答案：ABD。预留并发让容器常驻，精简依赖减少下载与解压耗时，惰性初始化推迟重活到首次调用，三者都直击冷启动痛点。C 调大超时只影响执行上限，与容器初始化速度无关。

Q5. 关于三家平台免费额度的说法，正确的是？

单选题 · mid

  • A.三家平台每月都提供免费额度← 正确答案
  • B.只有亚马逊云提供免费额度
  • C.免费额度可以自动无限循环
  • D.免费额度仅仅用来购买虚拟机

答案：A。AWS、Azure、GCP 的 FaaS 都提供每月免费请求数与免费 GB-秒额度。B 明显错误，C 的“无限循环”不成立（额度按月刷新而非无限累积），D 把免费额度跟虚拟机绑定更是张冠李戴。

Q6. 在 FaaS 上部署 AI 推理，最合理的做法是？

单选题 · hard

  • A.把大模型直接打进函数包里
  • B.把模型放对象存储并预热加载← 正确答案
  • C.在函数内部启动区块链数据
  • D.让每次请求都重新进行训练

答案：B。模型放对象存储、配合预热加载与预留并发，能在包体积和冷启动之间取得平衡。A 会使包超限且冷启动极慢，C 与推理无关，D 完全违背推理场景的基本常识。

Q7. 关于 Serverless 计费模型，正确的说法有哪些？

多选题 · hard

  • A.无请求时就不会产生计算费用← 正确答案
  • B.费用与内存和执行时长都相关← 正确答案
  • C.Serverless 完全没有任何隐藏费用
  • D.高并发下预留并发也会产生费用← 正确答案

答案：ABD。A 是无请求零计算费的基本特征，B 对应 GB-秒计费公式，D 中预留并发按实例时长收费，都是对的。C 忽略了出网流量、NAT 网关、日志监控等隐含成本，因此错误。

Q8. FaaS 与传统服务器的核心区别是什么？

单选题 · easy

  • A.需要自行维护底层服务器硬件
  • B.平台按需自动扩缩容并计费← 正确答案
  • C.无法处理任何外部网络请求
  • D.不能连接到任何外部数据库

答案：B。FaaS 由平台接管基础设施，按请求与资源用量计费并自动伸缩，B 正确。A 是传统自建的特征，C 和 D 与事实不符，函数完全可以处理 HTTP 请求并连接数据库。

Q9. Azure Functions 在选型中的独特优势是什么？

单选题 · mid

  • A.与微软生态体系深度集成← 正确答案
  • B.提供所有平台中最长超时上限
  • C.完全不支持任何事件类触发器
  • D.本身不提供任何免费的使用量

答案：A。Azure Functions 与 Office 365、Active Directory、Event Grid 等微软生态深度绑定，是其差异化卖点。B 不准确（超时上限并非最长），C 和 D 都与事实相反。

Q10. 多平台混合部署 Serverless 架构的常见挑战有哪些？

多选题 · extreme

  • A.各平台触发事件生态存在差异← 正确答案
  • B.监控排障工具链存在显著不同← 正确答案
  • C.平台间迁移成本普遍比较低
  • D.各平台配额限制规定各不相同← 正确答案

答案：ABD。多平台最大的麻烦正是触发器模型不一致（A）、可观测性工具栈割裂（B）以及配额与限制各异（D）。C 说迁移成本低与正文结论相反，属于常见误判。