3. 发布包结构:标准目录、元数据与资源定义

发布包是 Serverless Eventing 生命周期校验的载体。一个结构清晰、约定一致的发布包,能够确保校验工具、运行时环境和持续交付流水线对事件函数进行无歧义的解析与验证。本章定义发布包的标准目录结构、元数据文件 metadata.yaml 以及资源定义文件 resources.yaml 的规范。

3.1 标准目录结构

发布包采用扁平化与分层化相结合的目录布局,所有核心文件位于包根目录下,避免深层嵌套带来的解析歧义。标准结构如下:

eventing-package/
├── metadata.yaml          # 包元数据(必选)
├── resources.yaml         # 资源定义(必选)
├── functions/             # 函数代码目录(可选)
│   ├── order-processor/
│   │   ├── main.py
│   │   └── requirements.txt
│   └── payment-handler/
│       ├── index.js
│       └── package.json
├── schemas/               # 事件模式定义(可选)
│   ├── order.created.json
│   └── payment.failed.json
├── tests/                 # 本地测试用例(可选)
│   └── test_handlers.py
└── README.md              # 包说明文档(推荐)
命名约束:目录名和文件名仅允许使用小写字母、数字、连字符(-)和下划线(_),禁止使用空格或大写字母。函数目录名称必须与 resources.yaml 中定义的函数名称一致。

3.2 元数据文件(metadata.yaml)

metadata.yaml 是发布包的身份证明,声明包的基本信息、版本、依赖关系以及校验策略。校验器在加载包时首先解析此文件,若格式或必填字段缺失,则直接拒绝整个包。

字段定义表:

字段 类型 必填 说明
apiVersion string 是 元数据格式版本,当前为 eventing.io/v1
name string 是 发布包名称,全局唯一,符合 DNS-1123 子域名规范
version string 是 语义化版本号,格式 MAJOR.MINOR.PATCH
description string 否 包功能简述,建议不超过 200 字符
maintainer object 是 维护者信息,包含 name 和 email
dependencies array 否 依赖的其他发布包列表,每个条目包含 name 和 version
lifecycle object 是 生命周期策略,定义校验阶段与钩子

示例文件:

apiVersion: eventing.io/v1
name: order-processing-package
version: 1.2.0
description: "订单处理与支付事件联动包"
maintainer:
  name: "Eventing Team"
  email: "eventing@example.com"
dependencies:
  - name: common-event-schemas
    version: ">=0.5.0"
lifecycle:
  phases:
    - validate
    - deploy
    - verify
  hooks:
    pre-validate: "scripts/pre-validate.sh"
    post-deploy: "scripts/post-deploy.sh"
校验规则:version 字段必须严格遵循语义化版本规范,不允许使用 latest 或 v1.2 等非标准格式。lifecycle.phases 至少包含一个阶段,且阶段名称必须为预定义枚举值(validate、deploy、verify、rollback)。

3.3 资源定义文件(resources.yaml)

resources.yaml 描述发布包中包含的所有可部署资源,包括事件函数、触发器、事件源绑定以及目标服务。校验器依据此文件生成资源依赖图,并逐项检查资源定义的合法性。

资源类型与必填属性:

资源类型 必填属性 说明
Function name, runtime, handler, source 事件处理函数,source 指向 functions/ 下的目录
Trigger name, eventSource, targetFunction 事件源到函数的绑定关系
EventSource name, type, config 外部事件源定义,如 Kafka、S3、HTTP
Service name, endpoint, protocol 函数调用的下游目标服务

示例文件:

apiVersion: eventing.io/v1
kind: ResourceSet
resources:
  - type: Function
    name: order-processor
    runtime: python3.11
    handler: main.handle_order
    source: functions/order-processor
    environment:
      DB_CONNECTION_STRING: "${DB_CONNECTION_STRING}"
  - type: EventSource
    name: order-events
    type: Kafka
    config:
      topic: orders
      brokers:
        - kafka-1:9092
        - kafka-2:9092
      consumerGroup: eventing-group
  - type: Trigger
    name: order-trigger
    eventSource: order-events
    targetFunction: order-processor
    filters:
      - eventType: order.created
      - eventType: order.updated
  - type: Service
    name: inventory-service
    endpoint: http://inventory-svc:8080/api
    protocol: HTTP
    timeout: 30s

3.4 发布包结构关系图

下图展示了发布包内各文件与目录之间的逻辑关系,以及校验器如何通过 metadata.yaml 和 resources.yaml 驱动整个校验流程。

发布包结构关系与校验流程 发布包根目录 metadata.yaml 版本 / 依赖 / 生命周期 resources.yaml 函数 / 触发器 / 事件源 functions/ 函数代码与依赖 生命周期校验器 解析 metadata → 加载 resources → 校验依赖 → 执行钩子 校验结果报告 通过 / 警告 / 错误详情 校验顺序 ① metadata.yaml 格式校验 → ② resources.yaml 资源定义校验 → ③ 函数代码完整性校验

3.5 校验规则与常见错误

校验器在解析发布包结构时,会执行以下三类检查:

  • 结构完整性检查:确认 metadata.yaml 和 resources.yaml 存在于根目录,且文件内容为合法的 YAML 格式。
  • 字段合法性检查:验证必填字段是否存在、类型是否正确、枚举值是否在允许范围内。
  • 资源引用一致性检查:确保 resources.yaml 中引用的函数名称在 functions/ 目录下有对应的代码目录,且触发器引用的事件源和函数均已定义。
常见错误示例:
  • metadata.yaml 中 apiVersion 拼写错误或版本号不匹配 → 校验器返回 INVALID_METADATA_VERSION 错误。
  • resources.yaml 中 Trigger 的 targetFunction 指向一个不存在的函数名称 → 校验器返回 RESOURCE_REFERENCE_NOT_FOUND 错误。
  • functions/ 目录下缺少与资源定义对应的函数目录 → 校验器返回 FUNCTION_SOURCE_MISSING 错误。

通过严格遵循上述目录结构与文件规范,发布包可以在生命周期的早期阶段暴露配置错误,避免将不完整的包部署到生产环境。