4. 混沌工程基线核验接口总体架构:系统分层、组件交互、数据流、接口分类

本章从平台工程视角出发,将混沌工程基线核验接口体系拆解为四层架构。每一层承载明确的职责边界,通过标准化的接口契约完成组件间交互,最终形成从配置下发到报告归档的完整数据闭环。理解这一架构是后续设计具体接口规范的前提。

4.1 系统分层架构

基线核验接口体系自上而下分为四层:编排层、执行层、观测层和存储层。每层内部包含若干核心组件,层与层之间通过 RESTful API 或 gRPC 进行解耦通信。

层次 核心组件 职责说明 对外接口类型
编排层 实验编排引擎、基线配置中心、调度器 定义实验场景、管理基线参数、触发执行流程 配置类接口、调度类接口
执行层 故障注入代理、探针控制器、沙箱管理器 执行故障注入、控制探针生命周期、隔离实验环境 执行类接口
观测层 指标采集器、日志聚合器、链路追踪器 实时采集系统状态、聚合观测数据、生成时间序列 观测类接口
存储层 时序数据库、对象存储、报告生成器 持久化实验数据、存储基线快照、产出核验报告 报告类接口
架构原则:每一层只依赖其直接下层提供的接口,禁止跨层调用。编排层不可直接访问存储层,必须通过执行层或观测层的中介接口完成数据流转。
混沌工程基线核验接口 — 四层架构 编排层 实验编排引擎 基线配置中心 | 调度器 执行层 故障注入代理 探针控制器 | 沙箱管理器 观测层 指标采集器 日志聚合器 | 链路追踪器 存储层 时序数据库 | 对象存储 | 报告生成器

4.2 组件交互与数据流

一次完整的基线核验流程包含六个关键步骤,数据在四层组件之间按顺序流转。理解数据流有助于定位接口调用的时序依赖关系。

  1. 配置下发:编排层从基线配置中心读取基线参数,通过配置类接口下发至执行层。
  2. 环境准备:执行层沙箱管理器创建隔离环境,探针控制器部署观测探针。
  3. 故障注入:故障注入代理根据实验场景执行注入操作,同时向观测层注册事件。
  4. 数据采集:观测层指标采集器按预设频率拉取系统状态,日志聚合器收集运行时日志。
  5. 基线比对:观测层将实时数据与基线配置中的预期阈值进行比对,生成偏差标记。
  6. 报告归档:存储层接收比对结果,时序数据库保存指标快照,报告生成器产出核验报告。
数据流关键约束:观测层的数据采集接口必须支持 at-least-once 语义,避免因网络抖动导致基线数据缺失。执行层与观测层之间的数据传输建议使用 protobuf 序列化以降低延迟。
基线核验数据流与组件交互 编排层 基线配置中心 执行层 故障注入代理 观测层 指标采集器 存储层 报告生成器 ① 配置下发 ② 故障注入 ③ 采集 ④ 基线比对结果 ⑤ 报告归档

4.3 接口分类体系

根据职责边界,基线核验接口划分为四大类:配置类、执行类、观测类、报告类。每一类接口对应架构中的特定层次,并遵循统一的命名与版本规范。

接口分类 所属层次 典型接口示例 调用方向 协议偏好
配置类 编排层 POST /v1/baselines、PUT /v1/scenarios/{id} 编排层 → 执行层 RESTful JSON
执行类 执行层 POST /v1/experiments/run、DELETE /v1/experiments/{id} 编排层 → 执行层 gRPC
观测类 观测层 GET /v1/metrics/query、POST /v1/traces/collect 执行层 → 观测层 gRPC / HTTP2
报告类 存储层 GET /v1/reports/{id}、POST /v1/reports/export 观测层 → 存储层 RESTful JSON
接口设计红线:执行类接口必须支持幂等性,避免因重试导致多次故障注入。观测类接口的查询参数必须包含时间范围(start_time / end_time),防止全量扫描引发性能问题。

4.4 接口分类与架构映射总结

将四类接口映射回四层架构,可以清晰看到每一层对外暴露的接口集合。编排层是唯一同时调用配置类与执行类接口的层次;观测层作为数据枢纽,同时接收执行层的事件推送并向存储层写入报告数据。

  • 编排层 — 对外暴露配置类接口(供平台前端/CLI 调用),对内调用执行类接口。
  • 执行层 — 对外暴露执行类接口(供编排层调用),对内调用观测类接口完成数据采集。
  • 观测层 — 对外暴露观测类接口(供执行层调用),对内调用报告类接口完成数据持久化。
  • 存储层 — 对外暴露报告类接口(供观测层及外部审计系统调用)。
架构演进建议:在平台工程初期,配置类与执行类接口可以合并部署以降低延迟;当实验规模超过 1000 并发时,必须将两类接口拆分到独立服务,避免配置变更阻塞执行链路。