📚 课程目录第4章 CI/CD服务目录架构总览

4. CI/CD 服务目录架构总览：整体架构分层、核心组件、数据流与交互关系

在平台工程视角下，CI/CD 服务目录并非一个单体应用，而是一个由多个层次、组件和管道构成的有机系统。本章从宏观视角出发，拆解其整体架构分层、定义核心组件职责，并梳理数据流与交互关系，为后续章节的深度设计奠定基础。

我们将 CI/CD 服务目录架构划分为四个核心层次，每一层解决特定的关注点，并通过明确的接口与上下层交互。

层次	名称	核心职责	典型组件
L4	交互与体验层	面向开发者与平台工程师的自助服务门户，提供目录浏览、模板选择、参数配置、状态可视化。	Web UI、CLI 工具、API Gateway、Backstage 插件
L3	编排与策略层	服务目录的核心大脑，负责模板解析、策略校验、工作流编排、资源配额管理及审批流触发。	Catalog Engine、Policy Engine、Workflow Engine、Approval Service
L2	CI/CD 执行层	对接底层基础设施，执行具体的构建、测试、部署任务，并反馈执行状态与制品信息。	CI Runner (Jenkins/GitHub Actions)、CD Operator (ArgoCD/Flux)、Artifact Registry
L1	基础设施与资源层	提供计算、存储、网络等运行时资源，以及集群、命名空间、云服务账号等底层抽象。	Kubernetes 集群、Terraform Providers、云服务 API、Vault

架构原则： 每一层仅依赖其直接下层提供的抽象接口，禁止跨层直接调用。例如，交互层不能直接调用执行层的 API，必须经过编排层进行策略校验与资源准备。

下图展示了服务目录在接收到一次“创建微服务”请求时的核心组件交互与数据流向。

基于上述架构图，我们将关键交互关系拆解为以下步骤，并明确每个环节的输入与输出。

请求提交与解析： 开发者通过门户选择“微服务”模板，填写参数（如服务名、语言栈、团队）。API Gateway 将请求转发至 Catalog Engine。
策略校验： Catalog Engine 调用 Policy Engine，校验命名规范、资源配额、安全基线等。若校验失败，直接返回错误。
工作流编排： 校验通过后，Workflow Engine 根据模板定义生成执行计划，包括：创建代码仓库、初始化 CI 流水线、配置 CD 部署策略。
CI 执行与制品产出： Workflow Engine 触发 CI Runner 执行构建与单元测试。CI 完成后将容器镜像或 Jar 包推送至 Artifact Registry。
CD 部署与基础设施配置： CD Operator 监听新的制品版本，结合 Approval Service 的审批结果，将应用部署至目标 Kubernetes 集群，并调用云服务 API 创建数据库或缓存实例。
状态聚合与反馈： 执行层将部署状态、资源地址、日志链接回写至 Catalog Engine，最终在开发者门户上呈现完整的服务卡片。

  关键设计决策： 所有跨层数据流必须携带 Correlation ID（关联 ID），以便在分布式追踪中串联一次完整的服务创建请求。Catalog Engine 作为唯一的状态聚合点，负责维护服务目录的最终一致性。

服务目录的核心数据模型围绕“服务实例”展开，其状态机定义了从请求到运行的全生命周期。

注意： 状态流转必须幂等。例如，当 Deploying 状态因网络闪断未能及时更新时，Catalog Engine 应通过定时补偿任务重新查询执行层状态，避免服务实例永久卡在中间状态。

本章从分层、组件、数据流与状态四个维度，完整呈现了 CI/CD 服务目录的宏观架构。核心要点如下：