结构复杂性：组件数量增加带来的三重代价

简单原则宣言”简单优于复杂”，其中结构的复杂性专指组件数量更多、组件之间关系也更复杂这两个特征叠加带来的问题，具体表现为三重代价。第一重代价是可用性随组件数量增加而衰减，且衰减幅度比直觉预期更明显：假设每个组件的故障率是10%（即10%的时间不可用），3个组件串联的系统整体可用性是(1-10%)³=72.9%，5个组件则是(1-10%)⁵≈59%，仅仅多了2个组件，可用性就下降了约13个百分点——因为整体可用性是各组件可用性的乘积，组件越多，”没有任何一个组件出故障”的概率越低。第二重代价是改动的影响会沿组件间的依赖关系递归扩散：某个组件被修改或出现异常，会波及所有和它有直接关联的组件，被波及的组件又会继续影响与它们相关联的组件，一旦变更涉及外部系统，就需要多方协调评估、协调资源、协调上线，直接拖慢整体开发效率。第三重代价是故障定位的难度随组件数量和关系复杂度同步上升：组件越多，每个组件都有嫌疑，需要逐一排查；组件间关系越复杂，表现出故障症状的组件往往并不是真正的问题根源，容易在排查过程中被误导。这三重代价共同说明，架构设计不是”组件越多、结构越精细就越先进”，如果简单方案和复杂方案都能满足业务需求，应该优先选择组件更少、结构更简单的那一个。

结构图：

flowchart TB
  A["结构复杂性来源：组件数量多+组件间关系复杂"]
  A --> B["代价①可用性衰减<br/>3组件×90%可用性≈72.9%<br/>5组件×90%可用性≈59%（组件越多整体可用性乘积越低）"]
  A --> C["代价②改动影响递归扩散<br/>组件A异常→波及关联的B/C/E→继续波及更多组件<br/>拖慢协调评估与上线效率"]
  A --> D["代价③故障定位更难<br/>组件多→每个都有嫌疑需逐一排查<br/>关系复杂→表现故障的组件未必是真正根源"]
  B --> E["结论：简单方案能满足需求时<br/>应优先于复杂方案（KISS原则）"]
  C --> E
  D --> E