2. 标准模板总体架构:模板分层设计、核心组件介绍、输入输出规范

标准模板总体架构是《平台工程自助目录Collector管道移植适配标准模板》的核心骨架。它通过清晰的分层设计、可复用的核心组件以及严格的输入输出规范,确保不同数据源(如Jenkins、GitLab CI、Argo Workflows)的管道定义能够以统一的方式被采集、解析并输出为标准化的资源模型。本章将详细阐述该架构的三个核心维度:分层设计、组件构成与接口契约。

2.1 模板分层设计

标准模板采用经典的三层架构,自底向上分为:基础适配层、管道解析层和资源输出层。每一层职责单一,层间通过明确定义的接口进行通信,从而降低耦合度,提升模板的可移植性与可维护性。

设计原则: 每一层只依赖其下一层提供的抽象接口,不跨层调用。这使得替换底层数据源或修改上层输出格式时,不会引发连锁变更。
标准模板三层架构 基础适配层 (Foundation Adapter Layer) 职责:封装与具体CI/CD系统的API交互、认证、分页、原始数据拉取 输出:统一的数据源上下文对象 (DataSourceContext) 管道解析层 (Pipeline Parsing Layer) 职责:解析管道YAML/JSON定义,提取阶段、任务、依赖、环境变量等元数据 输出:标准化的管道内部模型 (PipelineInternalModel) 资源输出层 (Resource Output Layer) 职责:将内部模型映射为平台工程目录的标准资源实体(如 Workflow, Task, Artifact) 输出:标准资源实体列表 (List<CatalogResource>) 数据源适配器 解析器引擎 资源映射器

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 是 指向原始数据源的引用,用于审计和回溯
输入输出数据流与规范 适配器输入 AdapterInput (连接配置 + 凭证) 标准模板 Collector 管道 (解析 + 映射 + 校验) 标准资源实体 CatalogResource (Workflow/Task/Artifact) 输入输出规范要点 1. 输入必须包含 sourceType 和 endpoint,用于路由到正确的 DataSourceAdapter。 2. 输出必须包含 resourceType 和 resourceId,确保资源在目录中可唯一寻址。 3. 所有时间字段统一使用 ISO 8601 格式,所有标识符使用小写连字符命名法 (kebab-case)。

2.4 架构优势与适用场景

标准模板的总体架构设计带来了以下关键优势:

  • 高可移植性: 分层设计使得适配新CI/CD系统时,只需关注基础适配层和管道解析层的定制开发,其余部分可直接复用。
  • 强一致性: 严格的输入输出规范确保了无论数据源如何变化,最终输出的资源实体结构一致,平台工程目录无需感知底层差异。
  • 可测试性: 每一层都有明确的接口契约,可以针对每一层独立编写单元测试和集成测试,提升整体交付质量。
  • 可观测性: 核心组件均内置日志和指标埋点,便于在移植适配过程中进行问题定位和性能分析。
常见误区: 在移植适配时,不要试图在基础适配层中直接进行业务逻辑解析。请严格遵循分层职责,将API通信与管道解析分离,否则会导致模板难以维护和复用。