合适原则
简单原则
- 复杂的系统
组件之间的关联多
组件数量庞大
结构复杂性带来的问题
组件越多,某个组件出现故障的概率越高
假设组件的故障率是 10%(有 10% 的时间不可用),那么有 3 个组件的系统可用性是(1-10%)×(1-10%)×(1-10%)= 72.9%,有 5 个组件的系统可用性是(1-10%)×(1-10%)×(1-10%)×(1-10%)×(1-10%)=59%,两者的可用性相差 13%。
某一组件的变动可能会对所有关联的组件产生影响。而这些影响可能会顺着关联链路扩散出去,对更多的组件产生影响。
组件 A 修改或者异常时,会影响组件 B/C/E,D 又会影响 E。这个问题会影响整个系统的开发效率,因为一旦变更涉及外部系统,需要协调各方统一进行方案评估、资源协调、上线配合。
要在一个复杂的系统中对一个问题进行定位会变得非常困难。
组件越多,每个组件都有可能产生问题,需要一个个进行排查。组件间的关系复杂,有可能某一个足见的表现出故障,但问题的根源并不是这个足见。
- 架构复杂性。
演化原则
架构设计与生物相似,也需要通过演化发展来适应外部环境(业务变化),物竞天择,适者生存。
其次,架构要不断地在实际应用过程中迭代,保留优秀的设计,修复有缺陷的设计,改正错误的设计,去掉无用的设计,使得架构逐渐完善。
第三,当业务发生变化时,架构要扩展、重构,甚至重写;代码也许会重写,但有价值的经验、教训、逻辑、设计等(类似生物体内的基因)却可以在新架构中延续。
演化原则非常重要,在做架构设计时需要时刻牢记。快速落地以满足需求,在后续发展中不断完善整体架构,跟随业务发展而不断演化。