Apache OpenWhisk 如何按事件执行函数?
Apache OpenWhisk 是一个开源的无服务器云平台，核心行为是：在事件发生时执行函数，并按规模自动调度。你不需要自己管理服务器，只需把函数代码和触发规则交给平台，事件一到，平台负责运行与扩展。它适合事件驱动、负载波动大、希望按执行而非按机器计费的场景；如果你的任务需要长时间常驻进程或对底层环境有强控制需求，则不适合。
事件驱动执行的基本流程
OpenWhisk 的模型可以拆成四个角色：
- Action（动作）：你写的函数代码，是实际被执行的单元。
- Trigger（触发器）：代表一类事件，比如一次 HTTP 请求、一条消息到达。
- Rule（规则）：把 Trigger 和 Action 关联起来，声明“当这个事件发生，执行那个函数”。
- Feed（事件源）：把外部系统的事件接入 Trigger，例如消息队列、定时器或 Webhook。
一次典型执行按以下顺序发生：
- 外部系统产生事件，Feed 将其投递到对应的 Trigger。
- Trigger 被触发后，匹配到关联的 Rule。
- 平台根据 Rule 调用目标 Action。
- Action 在平台管理的运行环境中执行，返回结果。
- 平台按需创建或回收执行资源。
关键点在于：你只声明“什么事件触发什么函数”，不声明“在哪台机器上跑、跑几个实例”。调度和扩缩由平台完成。
为什么不需要管理服务器
传统部署里，你要先准备服务器或容器，再考虑进程常驻、健康检查、扩容阈值。OpenWhisk 把这层抽象掉了：
- 函数只在被触发时运行，空闲时不占用你管理的实例。
- 平台根据事件量决定并发执行的数量。
- 执行环境由平台提供，你交付的是函数本身。
这带来两个直接结果：一是运维面变小，二是计费与资源模型通常围绕“执行”而非“常驻机器”。具体计费方式取决于你使用的部署或托管服务，官网本身未给出价格信息，需要以实际提供方为准。
一个具体例子
假设你要在图片上传后生成缩略图：
- 事件源：对象存储的“文件上传”通知。
- Trigger：接收到上传事件。
- Rule：把该 Trigger 绑定到
makeThumbnail这个 Action。 - Action：读取图片、生成缩略图、写回存储。
用户上传一张图片，事件到达，函数被调用一次；同时上传一千张，平台就按需并发执行，你不需要提前扩容，也不需要在上传结束后手动缩容。
适合与不适合的场景
| 场景特征 | 是否适合 | 原因 |
|---|---|---|
| 事件触发、执行时间短 | 适合 | 与事件驱动模型天然匹配 |
| 负载波动大、有明显峰值 | 适合 | 平台按需调度与扩展 |
| 不想管理服务器 | 适合 | 执行环境由平台负责 |
| 长时间常驻进程 | 不适合 | 模型以事件触发的函数执行为主 |
| 需要强底层控制 | 不适合 | 抽象层减少了环境控制能力 |
上手前需要确认的事
- 你的事件源是否能通过 Feed 接入，或能否用 HTTP 触发。
- 函数是否有执行时长和资源上限要求，是否落在平台允许范围内。
- 你使用的是自托管 OpenWhisk 还是某个托管服务，两者的部署、配额和计费方式不同。
- 官网定位是“开源无服务器云平台”，开源意味着可自行部署，但自托管需要你承担集群运维，这与“无需管理服务器”的托管体验不是一回事，选择时要区分。