合适原则

1. 合适优于业界领先。合适自己业务要优先于使用业务领先的方案。

2. 不“脚踏实地”的架构的三类失败原因

3. 人手资源不足，却硬要干更多的活。将军不能打无兵之仗

4. 在没有充足基础设施和平台的时候就想做“大”系统

5. 不积跬步无以至千里

6. 没有那么大的业务场景却想着使用业务领先的方案

7. 业界的领先方案是业务发展到一定程度，为解决所要面临的各种新问题而“逼”出来的

8. BAT有很多优秀的架构师，但这些架构师在中小企业或初创团队中却不一定能做出好成绩。在BAT内部有大量资源、基建、各种各样的平台，但中小企业很少有这样完备的环境，生搬硬套大公司的套路往往会导致大概率的失败。

简单原则

1. 简单由于复杂。架构设计就是应对复杂性的艺术。
2. 复杂性的体现。

结构方面的复杂性：

1. 复杂的系统

2. 组件之间的关联多

3. 组件数量庞大

4. 结构复杂性带来的问题

5. 组件越多，某个组件出现故障的概率越高

6. 假设组件的故障率是 10%（有 10% 的时间不可用），那么有 3 个组件的系统可用性是（1-10%）×（1-10%）×（1-10%）= 72.9%，有 5 个组件的系统可用性是（1-10%）×（1-10%）×（1-10%）×（1-10%）×（1-10%）=59%，两者的可用性相差 13%。

7. 某一组件的变动可能会对所有关联的组件产生影响。而这些影响可能会顺着关联链路扩散出去，对更多的组件产生影响。

8. 组件 A 修改或者异常时，会影响组件 B/C/E，D 又会影响 E。这个问题会影响整个系统的开发效率，因为一旦变更涉及外部系统，需要协调各方统一进行方案评估、资源协调、上线配合。

9. 要在一个复杂的系统中对一个问题进行定位会变得非常困难。

      组件越多，每个组件都有可能产生问题，需要一个个进行排查。组件间的关系复杂，有可能某一个足见的表现出故障，但问题的根源并不是这个足见。

逻辑方面的复杂性。

1. 架构复杂性。

2. 算法复杂性。

3. 算法复杂体现的主要是难以理解，进而导致难以实现、难以修改，并且出了问题难以快速解决。

4. 架构的复杂性会贯穿系统的整个生命周期。

5. 系统投入使用后会有源源不断的需求，需要不断修改系统，新的复杂性会不断被引入。

演化原则

1. 用演化发展的眼光看到架构。

软件领域没有一成不变，需要根据业务的发展情况不断调整。

架构设计与生物相似，也需要通过演化发展来适应外部环境（业务变化），物竞天择，适者生存。

首先，设计出来的架构要满足当时的业务需要。

其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。

第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。

演化原则非常重要，在做架构设计时需要时刻牢记。快速落地以满足需求，在后续发展中不断完善整体架构，跟随业务发展而不断演化。