第2章 整体架构概览：系统分层、模块划分与关键依赖

在模块损坏回滚方案中，架构设计的首要任务是明确系统边界与分层职责。一个清晰的架构分层能够将“正常业务逻辑”与“异常降级逻辑”解耦，使得回滚操作在故障发生时成为一条可独立执行的快照路径，而非侵入式的大范围修改。本章将从系统分层、模块划分、核心依赖关系三个维度展开，并给出整体架构示意图。

2.1 系统分层架构

整个方案采用四层架构，自底向上依次为：基础资源层、故障注入层、回滚决策层、业务接入层。每层有明确的职责边界，层间通过标准化接口通信，不允许跨层直接调用。

2.2 关键模块划分与职责

除了分层结构外，以下6个核心模块直接决定了回滚方案的成败，需要重点设计其生命周期与故障边界。

• 回滚编排引擎：接收故障信号后，生成回滚DAG（有向无环图），决定模块回滚的并行度与顺序。该引擎必须支持暂停、取消、回退操作，以防止回滚过程本身引发二次故障。
• 状态快照管理器：在模块每次灰度升级前，自动创建全量状态快照（代码制品、数据库Schema、配置项、依赖版本锁）。快照采用增量+全量混合存储策略，控制存储成本。
• 版本差异对比器：比较当前运行版本与目标回滚版本之间的差异，输出差异报告，用于决策层判断回滚是否安全（例如：若存在不可兼容的数据库变更，则中断回滚并告警）。
• 熔断隔离器：在检测到模块异常时，立即将故障模块从调用链路中摘除，并返回降级响应（如缓存数据、默认值、错误提示）。隔离器不负责修复，只负责止损。
• 配置中心（回滚专有）：独立于业务配置中心，专门存储每个模块版本的回滚上下文，包括依赖版本锁、环境变量、动态参数覆盖。此配置中心必须支持版本级快照和原子切换。
• 硬隔离沙箱：用于快速拉起上个版本的模块实例，并与生产环境做网络隔离。回滚期间，新模块和旧版本模块可以短暂共存，待流量验证完成后才正式切换。

2.3 关键依赖关系

模块间的依赖关系决定了回滚的范围和顺序。依赖分为编译依赖（代码层面）、运行时依赖（RPC调用）、数据依赖（数据库Schema、缓存Key结构）。

2.4 架构示意图

下图展示了四层架构及模块之间的关键交互关系。请注意，回滚决策层与故障注入层之间的通信采用异步事件总线，避免故障注入层的高并发写入阻塞决策流程。

2.5 落地步骤与验收标准

基于以上架构图，落地本章内容的核心步骤及验收标准如下：

落地步骤

1. 定义各层之间的接口契约（gRPC IDL 或 HTTP OpenAPI），确保层间调用不可绕过。
2. 实现故障注入层的事件总线，支持至少10,000 TPS的故障事件吞吐量。
3. 在回滚决策层内完成依赖图谱的构建，支持至少200个节点的DAG解析。
4. 对基础资源层做容量规划：配置中心需支持1000个模块版本的快照存储，恢复时间目标(RTO)小于5秒。

验收标准

• 分层隔离验证：任意一层模块发生故障时，其他三层不应出现级联崩溃。
• 事件总线可靠性：在模拟单节点宕机后，故障事件不丢失，最多延迟3秒被决策层消费。
• 架构可扩展性：新增一个业务模块时，无需修改现有层的核心代码，只需注册到配置中心并声明依赖关系即可。