1. 课程导论

1.1 从单体到分布式：架构演进的必然挑战

企业业务系统从单体架构向分布式、微服务架构演进的过程中，模块边界拆分与故障恢复成为决定系统成败的两大核心能力。单体架构下，所有功能耦合在同一个进程中，虽然开发简单，但任何局部故障都可能导致整个系统不可用，且团队协作效率随代码量增长急剧下降。

分布式架构通过将系统拆分为多个独立模块，带来了以下收益与挑战：

1.2 模块边界拆分：架构设计的“第一性原理”

模块边界拆分不是简单的“把大项目拆成小项目”，而是基于业务领域、数据一致性和变更频率三个维度进行的系统性设计。错误的边界拆分会导致以下典型问题：

• 分布式单体（Distributed Monolith）：模块间过度依赖同步调用，本质上仍是耦合系统，却承担了分布式带来的所有复杂度。
• 数据一致性灾难：跨模块事务缺乏有效协调机制，导致数据不一致。
• 团队协作瓶颈：模块边界与团队组织不匹配，导致沟通成本激增（康威定律的反面案例）。

下图展示了模块边界拆分的核心决策维度与评估框架：

1.3 故障恢复：分布式系统的“生存底线”

在分布式系统中，故障是常态，而非异常。网络延迟、机器宕机、磁盘损坏、内存泄漏、依赖服务超时……任何环节都可能随时出现故障。故障恢复能力直接决定了系统的可用性（Availability）和数据持久性（Durability）。

故障恢复的核心目标可以概括为三个层次：

1. 故障检测（Detection）：快速发现异常，避免故障扩散。典型手段包括健康检查、超时机制、熔断器状态监控。
2. 故障隔离（Isolation）：将故障限制在最小范围内，防止级联效应。典型手段包括舱壁隔离（Bulkhead）、线程池隔离、异步消息队列。
3. 故障恢复（Recovery）：自动或半自动地将系统恢复到正常状态。典型手段包括重试机制、幂等性设计、补偿事务（Saga）、主从切换。

1.4 模块边界与故障恢复的关联

模块边界拆分与故障恢复并非独立的设计活动，而是相互影响、互为约束的：

• 边界影响恢复范围：合理的模块边界可以将故障隔离在单个模块内，避免“雪崩效应”。例如，订单模块的故障不应影响库存模块的正常服务。
• 恢复策略影响边界设计：如果两个模块之间存在强一致性要求，且无法通过补偿事务实现最终一致性，则它们可能不适合拆分为独立模块。
• 通信方式决定恢复复杂度：同步调用（如HTTP/RPC）的故障恢复比异步消息（如Kafka/RabbitMQ）更复杂，需要引入超时、重试、熔断等机制。

下图展示了模块边界与故障恢复策略之间的典型映射关系：

1.5 课程目标与学习路径

本课程旨在帮助架构师和技术负责人系统掌握模块边界拆分与故障恢复的方法论、设计模式和工程实践。通过30章的系统学习，你将能够：

• 掌握模块边界拆分的核心原则：基于DDD（领域驱动设计）、数据一致性、变更频率等维度进行科学拆分。
• 构建完整的故障恢复体系：从故障检测、隔离到自动恢复，覆盖同步调用、异步消息、分布式事务等场景。
• 落地工程化实践：结合真实案例，学习熔断器、舱壁隔离、Saga事务、主从切换等模式的具体实现。
• 建立架构评估能力：能够对现有系统进行架构评审，识别模块边界和故障恢复的薄弱环节。

课程学习路径分为四个阶段：