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 驱动整个校验流程。
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错误。
通过严格遵循上述目录结构与文件规范,发布包可以在生命周期的早期阶段暴露配置错误,避免将不完整的包部署到生产环境。