2. Oracle Cloud Serverless产品矩阵
Oracle Cloud 的 Serverless 能力并不是单一产品，而是一组职责清晰、可独立使用又能彼此编排的服务集合。理解这套产品矩阵的关键，不是记住每个服务的功能清单，而是弄清它们在一条真实请求链路中各自站在什么位置、承担什么职责、通过什么方式衔接。本节围绕 Functions、API Gateway、Events、Streaming、Object Storage、Autonomous Database 六个核心服务展开，先明确各自定位，再梳理它们之间的协作关系。
六个服务的定位
OCI Functions 是无服务器计算执行单元，基于 Fn Project 构建，以函数为最小部署粒度。它负责承载真正的业务逻辑：接收事件或 HTTP 请求，执行一段代码，返回结果。Functions 本身不保存状态，运行实例按需拉起、空闲回收，适合短时、事件驱动、突发性的处理任务。
API Gateway 是面向外部的统一入口与流量治理层。它对外暴露 HTTPS 端点，对内把请求路由到 Functions、HTTP 后端或其他 OCI 服务。它承担鉴权、限流、请求/响应转换、CORS 等横切关注点，使后端函数专注于业务本身，而不必重复实现安全与流量控制。
Events 是事件路由与分发服务，遵循“事件源产生事件、规则匹配事件、动作响应事件”的模型。它不存储业务数据，而是把 OCI 资源状态变化（如对象上传、数据库事件、资源创建）转化为可被消费的事件，并按规则推送到 Functions、Streaming、Notifications 等目标。
Streaming 是高吞吐、持久化的消息流服务，兼容 Apache Kafka API。它用于解耦生产者与消费者，缓冲流量峰值，支持多消费者按各自进度读取同一份数据流。与 Events 的“一次性分发”不同，Streaming 保留消息，允许重复消费和回溯。
Object Storage 是海量非结构化数据的持久化存储，桶（Bucket）是基本容器。它既是数据的最终落点，也是事件的常见来源——对象上传、删除都会触发事件，从而驱动后续处理链路。
Autonomous Database 是自治数据库服务，负责结构化数据的存储与查询。它自动完成打补丁、调优、扩缩容等运维工作，适合作为 Serverless 架构中的事务与分析数据底座，由函数通过连接或 REST 接口访问。
协作关系：从入口到落库的完整链路
这六个服务组合起来，可以形成一条典型的 Serverless 数据处理链路。下面这张图展示了它们之间的连接方向与数据流向：外部请求经 API Gateway 进入并路由到 Functions；Functions 处理后将结果写入 Autonomous Database 或 Object Storage；Object Storage 的对象变化触发 Events；Events 按规则把事件推送给 Functions 或 Streaming；Streaming 再被下游 Functions 消费，形成异步处理闭环。
Events 与 Streaming 的分工
初学者最容易混淆的是 Events 和 Streaming。两者的核心差异在于“是否保留消息”和“消费模型”。Events 是分发器：事件产生后按规则推送给目标，推送完成即结束，不保证重放。Streaming 是持久化日志：消息写入分区后保留指定时长（例如 24 小时或 7 天），多个消费者组可以各自按 offset 读取，互不影响，也支持从历史位置重新消费。
因此选择依据很明确：如果只是“资源状态变了，通知某个函数处理一下”，用 Events；如果是“大量数据需要缓冲、多个下游各自处理、需要回溯或重放”，用 Streaming。二者也常配合使用——Events 把对象事件推入 Streaming，再由多个 Functions 消费者并行处理，实现削峰与解耦。
一个可落地的示例链路
假设要构建一个图片上传后自动生成缩略图并记录元数据的 Serverless 应用，链路可以这样组织：
- 客户端通过 API Gateway 暴露的
/upload端点发起请求，API Gateway 完成 JWT 鉴权后路由到upload-image函数。 upload-image函数校验文件类型与大小，将原图写入 Object Storage 的raw-images桶，并把图片 ID、上传时间等元数据写入 Autonomous Database 的image_meta表。- Object Storage 的
raw-images桶配置了对象创建事件，事件进入 Events 服务。 - Events 规则匹配
ObjectCreate事件，将事件推送到generate-thumbnail函数。 generate-thumbnail函数从 Object Storage 读取原图，生成缩略图后写入thumb-images桶，并更新 Autonomous Database 中的缩略图状态字段。- 若缩略图生成量很大，可在 Events 与函数之间加入 Streaming：Events 把事件推入
thumbnail-tasks流，多个函数实例作为消费者组并行消费，实现水平扩展与流量缓冲。
这条链路中，API Gateway 负责入口安全，Functions 负责计算，Object Storage 负责文件持久化与事件源，Autonomous Database 负责结构化记录，Events 负责事件路由，Streaming 负责异步缓冲。六个服务各司其职，缺一不可，但也可以按需裁剪——例如没有异步需求时，Events 和 Streaming 可以暂时不引入。
协作中的关键约束
在实际组合这些服务时，有几个约束需要提前考虑。第一，Functions 有执行超时限制（默认 60 秒，可配置到 300 秒），长耗时任务应拆分为多个函数或改用 Streaming 异步处理。第二，API Gateway 与 Functions 之间的路由需要正确配置后端类型和路径映射，否则会出现 502 或 404。第三，Events 规则中的事件类型和条件必须与事件源实际产生的事件结构匹配，建议先用测试事件验证规则命中情况。第四，Autonomous Database 的连接应从函数通过连接池或 REST 方式管理，避免每次调用都新建连接造成开销。第五，Object Storage 的事件通知需要桶级别配置，且事件可能重复投递，下游函数应实现幂等处理。