2. 标准模板总体架构:模板分层设计、核心组件介绍、输入输出规范
标准模板总体架构是《平台工程自助目录Collector管道移植适配标准模板》的核心骨架。它通过清晰的分层设计、可复用的核心组件以及严格的输入输出规范,确保不同数据源(如Jenkins、GitLab CI、Argo Workflows)的管道定义能够以统一的方式被采集、解析并输出为标准化的资源模型。本章将详细阐述该架构的三个核心维度:分层设计、组件构成与接口契约。
2.1 模板分层设计
标准模板采用经典的三层架构,自底向上分为:基础适配层、管道解析层和资源输出层。每一层职责单一,层间通过明确定义的接口进行通信,从而降低耦合度,提升模板的可移植性与可维护性。
设计原则: 每一层只依赖其下一层提供的抽象接口,不跨层调用。这使得替换底层数据源或修改上层输出格式时,不会引发连锁变更。
2.2 核心组件介绍
在分层架构的基础上,标准模板定义了六个核心组件,它们协同工作以完成从原始数据到标准资源的完整转换。下表列出了每个组件的名称、所属层级及核心职责。
| 组件名称 | 所属层级 | 核心职责 |
|---|---|---|
| DataSourceAdapter | 基础适配层 | 封装与CI/CD系统的API通信,处理认证、分页、限流和错误重试,输出统一的 DataSourceContext。 |
| ContextNormalizer | 基础适配层 | 对原始数据进行字段映射、类型转换和缺失值填充,确保下游组件获得结构一致的数据源上下文。 |
| PipelineParser | 管道解析层 | 解析管道定义文件(如 .gitlab-ci.yml、Jenkinsfile),提取阶段、作业、步骤、触发条件和环境变量。 |
| DependencyResolver | 管道解析层 | 分析作业间的依赖关系(如 needs、depends_on),构建有向无环图(DAG)并验证其合法性。 |
| ModelMapper | 资源输出层 | 将解析后的 PipelineInternalModel 映射为平台工程目录的标准资源实体,如 Workflow、Task、Artifact。 |
| ResourceValidator | 资源输出层 | 对生成的资源实体进行合规性校验,确保必填字段完整、引用关系正确、命名符合规范。 |
组件复用建议: 在移植适配新管道时,通常只需替换 DataSourceAdapter 和 PipelineParser 两个组件,其余四个组件可在不同适配器间直接复用,从而大幅降低开发成本。
2.3 输入输出规范
为了保证模板的可移植性和可测试性,标准模板对每一层的输入输出都制定了严格的规范。这些规范以接口契约的形式定义,所有组件实现都必须遵守。
2.3.1 输入规范
标准模板的输入分为两个层次:适配器输入和解析器输入。
- 适配器输入(AdapterInput): 包含连接目标系统所需的全部配置信息。
{ "sourceType": "gitlab", // 数据源类型标识 "endpoint": "https://gitlab.example.com", "authToken": "${GITLAB_}", // 支持环境变量引用 "projectId": "12345", "pipelineId": "67890", "options": { // 可选参数,如超时、分页大小 "timeoutSeconds": 30, "pageSize": 100 } } - 解析器输入(ParserInput): 经过标准化的数据源上下文,包含原始管道定义和元数据。
{ "rawDefinition": "stages:\n - build\n - test\n...", // 原始YAML/JSON字符串 "sourceMetadata": { "projectName": "my-service", "branch": "main", "commitSha": "abc123def456", "triggerType": "push" }, "contextId": "ctx-20250321-001" }
2.3.2 输出规范
标准模板的最终输出是平台工程目录可消费的标准资源实体列表。每个实体必须包含以下核心字段:
| 字段名 | 类型 | 必填 | 说明 |
|---|---|---|---|
resourceType |
string | 是 | 资源类型标识,如 workflow、task、artifact |
resourceId |
string | 是 | 全局唯一标识,格式:{sourceType}:{projectId}:{pipelineId}:{localId} |
name |
string | 是 | 资源名称,用于在目录中展示 |
properties |
map[string]any | 否 | 资源属性键值对,包含阶段、依赖、环境变量等结构化信息 |
relations |
list[Relation] | 否 | 资源间关系列表,如 depends_on、produces |
sourceRef |
string | 是 | 指向原始数据源的引用,用于审计和回溯 |
2.4 架构优势与适用场景
标准模板的总体架构设计带来了以下关键优势:
- 高可移植性: 分层设计使得适配新CI/CD系统时,只需关注基础适配层和管道解析层的定制开发,其余部分可直接复用。
- 强一致性: 严格的输入输出规范确保了无论数据源如何变化,最终输出的资源实体结构一致,平台工程目录无需感知底层差异。
- 可测试性: 每一层都有明确的接口契约,可以针对每一层独立编写单元测试和集成测试,提升整体交付质量。
- 可观测性: 核心组件均内置日志和指标埋点,便于在移植适配过程中进行问题定位和性能分析。
常见误区: 在移植适配时,不要试图在基础适配层中直接进行业务逻辑解析。请严格遵循分层职责,将API通信与管道解析分离,否则会导致模板难以维护和复用。