3. 平台架构：PromServerless 整体架构图、控制面与数据面分离、函数运行时与调度器角色
PromServerless 平台采用控制面与数据面分离的经典云原生架构。控制面负责管理、调度与观测，数据面负责承载用户函数的实际执行。这种架构设计使得平台具备高弹性、多租户隔离以及独立扩缩容的能力，是容量调优与配额校准的基础。
3.1 整体架构总览
平台整体分为三大层级：入口网关层、控制面与数据面。入口网关统一接收函数调用请求，控制面完成身份认证、配额校验与调度决策，数据面由多个函数运行时节点组成，实际执行用户代码。
架构要点：控制面与数据面通过 gRPC 或消息队列通信。调度器不直接接触用户代码，所有函数执行都在数据面运行时节点中完成。这种分离使得控制面可以独立扩缩，数据面节点可以按需弹性伸缩。
3.2 控制面与数据面分离详解
控制面与数据面分离是 PromServerless 实现高可用与多租户隔离的核心设计原则。下表对比了两者的职责与关键差异：
| 维度 | 控制面 (Control Plane) | 数据面 (Data Plane) |
|---|---|---|
| 核心职责 | 请求路由、身份认证、配额校验、调度决策、观测采集 | 函数代码执行、资源隔离、冷启动优化、指标上报 |
| 扩缩容策略 | 按请求量 + 调度队列深度扩缩，通常保持 2~5 个副本 | 按函数并发 + 内存水位弹性伸缩，支持从 0 到数千节点 |
| 资源敏感度 | CPU 密集型，对延迟敏感，通常绑定固定资源 | 内存 + CPU 混合型，受用户函数行为影响大 |
| 故障影响范围 | 影响新请求调度，已有执行不受影响 | 仅影响所在节点上的函数实例 |
| 配额校准对象 | API 调用频率、并发调度上限、租户级配额 | 函数内存限制、CPU 限制、并发实例数、冷启动预留 |
容量调优视角：控制面瓶颈通常出现在调度器队列积压与配额校验延迟上；数据面瓶颈则集中在运行时节点的内存超分与 CPU 争抢。校准配额时，需要分别针对控制面与数据面设定不同的水位线。
3.3 函数运行时（Runtime）角色
函数运行时是数据面的核心执行单元，每个运行时节点承载多个函数实例。运行时的主要职责包括：
- 实例生命周期管理：创建、复用、销毁函数实例，支持冷启动与 warm 池机制。
- 资源隔离：基于 cgroup v2 实现内存与 CPU 的硬限制，防止函数间互相干扰。
- 指标采集：实时上报每个实例的 CPU 使用率、内存占用、请求延迟、并发数等指标。
- 健康检查：定期探测实例存活状态，异常实例自动摘除并重新调度。
运行时节点内部采用沙箱容器或微虚拟机（如 Firecracker）来执行用户函数，确保安全隔离。每个运行时节点可以同时运行多个函数实例，实例数量受节点资源上限与函数配额共同约束。
3.4 调度器（Scheduler）角色
调度器是控制面的决策核心，负责将函数调用请求分配到最合适的运行时节点。调度器的关键能力如下：
| 调度策略 | 说明 | 适用场景 |
|---|---|---|
| 最小并发优先 | 选择当前活跃实例数最少的节点 | 通用场景，负载均衡效果好 |
| 资源感知调度 | 根据节点剩余内存/CPU 进行加权选择 | 内存敏感型函数，避免 OOM |
| 亲和性调度 | 优先将请求调度到已有相同函数 warm 实例的节点 | 冷启动敏感场景，降低延迟 |
| 配额感知调度 | 检查租户/函数配额是否超限，超限则排队或拒绝 | 多租户配额校准场景 |
容量调优关键点：调度器的决策效率直接影响平台整体吞吐。当调度队列深度超过 1000 或调度延迟超过 50ms 时，需要优先排查控制面资源是否充足，以及配额校验逻辑是否存在性能瓶颈。建议为调度器配置独立的 CPU 资源池，避免与数据面争抢。
3.5 控制面与数据面的协作流程
一次完整的函数调用请求在控制面与数据面之间的流转过程如下：
- 入口网关接收请求，提取函数标识与调用方身份。
- 身份认证模块校验调用方权限，通过后进入配额校验。
- 配额校准模块检查该函数/租户的并发实例数、内存总量是否超限。若超限，返回 429 或加入等待队列。
- 调度器根据当前各运行时节点的负载、资源余量、亲和性策略，选择最优目标节点。
- 调度器将请求转发至目标运行时节点，节点上的函数实例执行代码并返回结果。
- 执行完成后，运行时节点上报指标数据（延迟、资源消耗、错误码）至观测模块，用于后续调度优化与配额校准。
实践建议：在 PromServerless 平台中，建议为每个租户设置独立的调度队列，避免某个租户的突发流量阻塞全局调度。同时，将配额校验前置到网关层，可以提前过滤无效请求，减轻调度器压力。