FaaS（函数即服务）上手指南：从 0 到上云

发表于 更新于 分类于 ， 阅读次数： 本文字数： 5.5k 阅读时长 ≈ 10 分钟

这篇文章会带你一起，从 FaaS 的诞生背景聊起，彻底搞懂它的核心概念、真实应用场景，并手把手教你把第一个函数部署上云。

一、FaaS 的诞生：我们为何需要它？

要理解 FaaS 为何会横空出世，我们得先坐上时光机，回顾一下应用部署方式的“进化史”。

第一站：物理服务器时代

在遥远的“刀耕火种”年代，我们要部署一个网站，得先去机房买一台（或几台）物理服务器。这意味着漫长的采购周期、高昂的硬件成本，以及复杂的机器运维。最头疼的是，为了应对业务高峰，我们必须按最高标准购买硬件，导致服务器在大部分时间里都处于“摸鱼”状态，造成了巨大的资源浪费。

第二站：虚拟机 (IaaS) 时代

云计算的出现带来了转机。以 AWS EC2 为代表的虚拟机服务，让我们告别了实体硬件，可以在云端“租”服务器。这极大地提高了灵活性，几分钟内就能创建一台虚拟机。但问题并没有完全解决：我们依然要为整台虚拟机买单，哪怕上面的应用空闲着。同时，操作系统的维护、安全补丁的更新，这些运维工作一样也没少。

第三站：容器 (PaaS/CaaS) 时代

Docker 和 Kubernetes 的风靡，让部署进入了容器化时代。我们将应用和它的依赖打包成一个轻量的“集装箱”，实现了环境的标准化和交付的敏捷性。但新的“烦恼”也随之而来：为了运行这些容器，我们得维护一个庞大而复杂的 Kubernetes 集群。容量规划、节点扩容、网络配置... 我们似乎从“应用运维”的坑，跳进了“集群运维”的坑。

兜兜转转，开发者们始终有一个终极梦想：我们能只关心业务代码，而彻底不用管服务器吗？

FaaS 响亮地回答了：“能！”

它的核心思想简单而彻底：让开发者回归最纯粹的编程，将服务器及相关的一切运维工作，都交给云平台。无论是操作系统、运行时环境，还是弹性伸缩、高可用，你通通不用管。你的世界里，只剩下你的“函数”——那段实现核心业务逻辑的代码。

简单来说，FaaS 将付费模式从“为服务器资源付费”，进化到了“为代码的实际执行付费”。这不只是一次技术升级，更是一场开发思想的革命。

二、拨开云雾：FaaS 核心概念详解

理解了 FaaS 的“初心”，我们再来拆解几个围绕着它的核心概念。

  • FaaS (Function-as-a-Service, 函数即服务) 这是我们要掌握的核心。我喜欢用一个比喻：租厨房，而不是租公寓。 在传统模式下，为了做顿饭，你得先租下一整套公寓（服务器），自己装修（配环境）、打扫（运维）。而 FaaS 就像一个共享厨房，你只需带着菜谱（代码）进去，锅碗瓢盆（运行环境）一应俱全。你只为炒菜的几分钟付费，完事就走，绝不为厨房的闲置时间买单。

  • Serverless (无服务器架构) 这是一个更宏大的理念，FaaS 只是它最广为人知的“代言人”。Serverless 并非真的没有服务器，而是强调一种开发者无需关心服务器的架构思想。 如果说 FaaS 是共享厨房，那 Serverless 就是整个美食广场。这个广场里除了厨房（FaaS），还有现成的食材超市（BaaS - 数据库服务）、统一的安保系统（BaaS - 身份验证服务）等等。Serverless 的目标，就是让你作为大厨，能心无旁骛地专注于“炒菜”这一件事上。

  • 事件驱动 (Event-Driven) 这是 FaaS 的灵魂。你的函数并非 24 小时待命，而是像个“懒汉”，“有事才干，没事歇着”。 你可以把函数想象成一个装了门铃的房间。只有当“事件”发生时——比如有人按门铃（HTTP 请求）、信箱里有新信件（文件上传）、手机闹钟响了（定时任务）——它才会被唤醒去开门（执行函数）。这种模式确保了资源不会被空耗。

  • 冷启动 (Cold Start) 这是 FaaS 的一个独特挑战。如果你的函数长时间没被调用（没人按门铃），平台为了节约资源，会把它“请回家休息”（回收实例）。当下一个请求突然到来时，平台需要重新给它分配资源、加载代码、初始化环境... 这个过程就像大冬天里发动一台冷了很久的汽车，会有一个明显的延迟，这就是“冷启动”。 一旦启动完毕，后续的连续请求就会非常快（这叫“热启动”），直到它再次因为“没人理”而进入休眠。

  • BaaS (Backend-as-a-Service, 后端即服务) 前面提到，这是 Serverless 美食广场的另一半。它提供了各种开箱即用的后端能力，比如数据库 (Firebase)、对象存储 (AWS S3)、用户认证 (Auth0) 等。FaaS 函数通常和 BaaS 服务配合，一个主内（负责无状态的计算逻辑），一个主外（负责有状态的数据存储），共同构建出一个完整的 Serverless 应用。

三、身手初试：FaaS 的真实应用场景

理论听起来很棒，那 FaaS 在实际工作中到底能用来做什么呢？

场景一：网站或小程序的后端 API

这是 FaaS 最经典的用法。假设你要为个人博客或小程序开发一个后端，但又不想为了偶尔的访问量，而去维护一台 24 小时开机的服务器。

  • 实例：一个“用户注册”接口。当用户在前端页面提交注册信息后，会调用一个 API 网关，这个网关会触发我们的 FaaS 函数。函数接收到用户信息，执行数据校验、写入数据库等操作，然后返回结果。整个过程可能只花费几百毫秒，你就只需要为这短暂的计算付费，经济又省心。

场景二：自动化的数据处理

FaaS 的事件驱动特性，让它成为自动化工作流的“神器”，尤其适合“当 A 发生时，自动执行 B”这类任务。

  • 实例：图片自动生成缩略图。在社交或电商网站，用户上传一张高清原图后，我们往往需要大、中、小等不同尺寸的缩略图。通过 FaaS，我们可以设定一个规则：每当有图片上传到指定的存储桶（如 AWS S3），就自动触发一个函数。这个函数会读取原图，批量生成所需的缩略图，再存回存储桶。整个流程全自动，无需人工干预。

场景三：轻量级的定时任务 (Cron Job)

几乎每个系统都需要一些定期执行的任务，比如每日数据备份、定时发送报表等。

  • 实例：生成每日运营报表。你可以设置一个定时触发器，比如每天凌晨 2 点，准时调用一个 FaaS 函数。这个函数会自动连接数据库，抓取前一天的用户增长、订单量等数据，生成一份精美的报表，并通过邮件发送给相关同事。

场景四：物联网 (IoT) 数据处理

在物联网场景中，成千上万的设备可能会在瞬间产生海量数据，对后端的弹性伸缩能力是极大的考验。

  • 实例：共享单车位置上报。每辆单车上的 GPS 设备会定时将位置信息发送到一个消息队列中。FaaS 函数可以订阅这个队列，每当有新消息进入，就触发一次执行，将最新的单车位置解析并更新到地图数据库中。FaaS 的自动伸缩能力，能完美应对早晚高峰期的并发洪流。

通过这些场景，不难发现 FaaS 特别适合那些无状态、短执行、事件触发类型的任务。

四、庖丁解牛：FaaS 架构与上线实战

理论和场景都清楚了，是时候深入 FaaS 平台的内部，看看它究竟是如何工作的，并亲手上线一个函数了。

架构解剖（以 AWS Lambda 为例）

我们以目前最流行的 FaaS 平台 AWS Lambda 为例，看看一个典型的 FaaS 调用流程包含哪些组件。 



graph LR
EVT["事件源<br/>S3 / API Gateway / MQ"] --> TRG("触发器")
TRG --> LBD["Lambda 托管 Runtime"]
LBD --> ENI[("弹性网络")]
LBD --> LOG["CloudWatch Logs"]
LBD --> DLQ["死信队列<br/>(可选)"]

  • 事件源：触发函数执行的“扳机”，可以是 S3 的文件上传、API Gateway 的 HTTP 请求，或是消息队列里的新消息。
  • 触发器：连接事件源和函数的“遥控器”，负责监听事件并调用目标函数。
  • Runtime：函数的运行环境，平台内置了 Node.js, Python, Go 等多种语言环境，也支持通过自定义镜像（Custom Runtime）运行任何语言。
  • 弹性网络 (ENI)：如果函数需要访问你私有网络（VPC）里的数据库等资源，平台会为其挂载一个弹性网络接口。
  • 监控与日志 (CloudWatch Logs)：函数运行期间产生的日志（比如 console.log）和各项指标（调用次数、执行时长等）会被自动收集起来，方便排查问题。

解密冷启动：从上面的流程可以看出，一次冷启动的耗时主要来自：拉取代码镜像 → 启动 Runtime 容器 → 初始化你的代码 → (如果需要)挂载网络。

开发到上线：五步法

接下来，我们用一个经典的 "Hello World" 示例，走完从开发到上线的完整流程。

  1. 初始化工程 首先，在本地创建一个项目目录，并编写一个简单的 Node.js 函数。 

    1
    2
    3
    4
    5
    mkdir hello-faas && cd $_
    # 创建一个 index.js 文件，内容如下
    echo 'exports.handler = async (event) => "Hello from FaaS!";' > index.js
    # 将项目打包成 zip 文件
    zip -r function.zip .

  2. 创建函数 登录云厂商控制台（或使用命令行工具），创建一个新函数。 

    1
    2
    3
    4
    5
    6
    7
    # 以 AWS CLI 为例
    aws lambda create-function \
        --function-name hello-world \
        --runtime nodejs20.x \
        --handler index.handler \
        --zip-file fileb://function.zip \
        --role <your-lambda-execution-role-arn>
    这里需要指定函数名、运行时、入口文件 (index.js里的handler方法)，并上传代码包。

  3. 配置触发器 函数创建好了，但还不知道“听谁的号令”。我们需要为它配置一个触发器，比如一个公开的 HTTP 访问地址。 

    1
    2
    3
    # 以 AWS API Gateway v2 为例，此步骤在控制台操作更直观
    aws apigatewayv2 create-api --name hello-api --protocol-type HTTP
    # ... 此处省略若干步骤，建议在控制台界面完成 API Gateway 与 Lambda 的集成

  4. 版本与灰度 在生产环境中，直接更新线上代码是危险的。FaaS 平台通常支持版本管理和别名（Alias）功能，你可以先发布一个新版本，然后让 10% 的流量指向新版本，90% 的流量留在稳定版，以此实现平滑的灰度发布。

  5. 监控与告警 函数上线后，我们需要时刻关注它的健康状况。平台会自动监控调用次数、执行时长、错误率等核心指标。你可以基于这些指标设置告警，例如“当错误率连续 5 分钟超过 1% 时，立即发短信通知我”。

五、精打细算：计费模型与常见问题

FaaS 的一大魅力在于其极致的成本效益，让我们来看看它是如何计费的，以及在使用中会遇到哪些“坑”。

计费模型对比

各大云厂商的 FaaS 计费方式大同小异，通常都包含两个维度：

厂商 最小计量（时长/内存） 每月免费额度（调用/资源） 计费维度 关键备注
AWS Lambda 1 ms / 128 MB 100 万次 / 40 万 GB-秒 调用次数 + GB-秒 ARM 架构单价更低
Azure Functions 1 ms / 128 MB 100 万次 / 40 万 GB-秒 同上 分为多种计划 (Plan)
GCP Cloud Functions 100 ms / 256 MB 200 万次 / 40 万 GB-秒 同上 Gen2 冷启动优化明显
阿里云函数计算 1 ms / 128 MB 100 万次 / 40 万 CU-秒 调用次数 + CU-秒 CU 是资源的综合单位

通用计费公式：总费用 = 调用次数 × 次数单价 + (函数执行总时长 × 内存配置) × 资源单价

可以看出，厂商们都在用慷慨的免费额度吸引开发者，对于个人项目或小型应用来说，很可能一个月都花不了几块钱。

常见“坑”与对策

在享受 FaaS 带来的便利时，也要小心避开下面这些常见的“坑”。

症状 可能根因 应对策略
冷启动太慢 (1-3s) 代码包过大、依赖库复杂、VPC 网络挂载 1. 瘦身：精简代码和依赖。
2. 选型：选择 Go, Rust 等编译型语言。
3. 预热：开启预置并发（Provisioned Concurrency）。
并发被限流 达到账户并发上限或突发流量过大 1. 提额：联系云厂商提高并发额度。
2. 预留：为核心函数配置“预留并发”（Reserved Concurrency）。
本地调试困难 依赖云端服务，难以模拟触发事件 使用官方模拟工具，如 AWS SAM, LocalStack, Midway FaaS 等。
配置管理混乱 多函数间配置散落，难以维护 1. IaC：使用 Terraform, CDK 等工具进行“基础设施即代码”管理。
2. 环境变量：将配置统一存储在环境变量或配置中心。

友情提示：FaaS 虽好，但非万能。它特别适合短平快、无状态的计算任务。对于需要长连接（如 WebSocket）、或对延迟极其敏感（如实时对战游戏）的应用，传统的容器或虚拟机方案可能依然是更好的选择。

✨ 小结

让我们回到最初的问题：FaaS 究竟是什么？

现在，我们可以更自信地回答：它是一种将应用拆解为微小、独立的函数，并由云平台全权负责其运行、伸缩和计费的现代化架构模式。

它继承了 Serverless 的核心思想，让开发者从繁重的服务器运维中彻底解放出来，将宝贵的精力聚焦于业务创新本身。

当然，它也有冷启动这样的挑战，但通过合理的架构设计和优化手段，我们完全可以扬长避短。如果你正准备开启一个新项目，或希望重构一个老旧的单体应用，不妨给 FaaS 一个机会，它很可能会给你带来意想不到的惊喜。