4. 混沌工程基线核验接口总体架构:系统分层、组件交互、数据流、接口分类
本章从平台工程视角出发,将混沌工程基线核验接口体系拆解为四层架构。每一层承载明确的职责边界,通过标准化的接口契约完成组件间交互,最终形成从配置下发到报告归档的完整数据闭环。理解这一架构是后续设计具体接口规范的前提。
4.1 系统分层架构
基线核验接口体系自上而下分为四层:编排层、执行层、观测层和存储层。每层内部包含若干核心组件,层与层之间通过 RESTful API 或 gRPC 进行解耦通信。
| 层次 | 核心组件 | 职责说明 | 对外接口类型 |
|---|---|---|---|
| 编排层 | 实验编排引擎、基线配置中心、调度器 | 定义实验场景、管理基线参数、触发执行流程 | 配置类接口、调度类接口 |
| 执行层 | 故障注入代理、探针控制器、沙箱管理器 | 执行故障注入、控制探针生命周期、隔离实验环境 | 执行类接口 |
| 观测层 | 指标采集器、日志聚合器、链路追踪器 | 实时采集系统状态、聚合观测数据、生成时间序列 | 观测类接口 |
| 存储层 | 时序数据库、对象存储、报告生成器 | 持久化实验数据、存储基线快照、产出核验报告 | 报告类接口 |
架构原则:每一层只依赖其直接下层提供的接口,禁止跨层调用。编排层不可直接访问存储层,必须通过执行层或观测层的中介接口完成数据流转。
4.2 组件交互与数据流
一次完整的基线核验流程包含六个关键步骤,数据在四层组件之间按顺序流转。理解数据流有助于定位接口调用的时序依赖关系。
- 配置下发:编排层从基线配置中心读取基线参数,通过配置类接口下发至执行层。
- 环境准备:执行层沙箱管理器创建隔离环境,探针控制器部署观测探针。
- 故障注入:故障注入代理根据实验场景执行注入操作,同时向观测层注册事件。
- 数据采集:观测层指标采集器按预设频率拉取系统状态,日志聚合器收集运行时日志。
- 基线比对:观测层将实时数据与基线配置中的预期阈值进行比对,生成偏差标记。
- 报告归档:存储层接收比对结果,时序数据库保存指标快照,报告生成器产出核验报告。
数据流关键约束:观测层的数据采集接口必须支持
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 并发时,必须将两类接口拆分到独立服务,避免配置变更阻塞执行链路。