架构原则

架构设计我我们平时写代码不一样，两者的差异主要体现在“不确定性”上。对于编程来说，本质上是确定的，对于同样一段代码，不管是谁写的，不管什么时候执行，执行的结果应该都是确定的；而对于架构设计来说，本质上是不确定，并没有像编程语言那样的语法来进行约束，更多的时候是面对多种可能性时进行选择。

示例：

• 是要选择业界最先进的技术，还是选择团队目前最熟悉的技术？
• 是要选 MySQL 还是 MongoDB？团队对 MySQL 很熟悉，但是 MongoDB 更加适合业务场景？
• 淘宝的电商网站架构很完善，我们新做一个电商网站，是否简单地照搬淘宝就可以了？

1.合适原则

合适优于业界领先。

在进行架构设计的同时，需要考虑自身业务，而不是一味的去参照业界顶尖的规模，如：QQ、微信、淘宝架构。真正优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地。

2.简单原则

简单优于复杂。

软件架构设计是一门技术活，当我们进行架构设计时，会自然而然地想把架构做精美、做复杂，这样才能体现我们的技术实力，也才能够将架构做成一件艺术品。然而，“复杂”在制造领域代表先进，在建筑领域代表领先，但在软件领域，却恰恰相反，代表的是“问题”。

软件复杂度的体现，主要有以下两个方面：

结构的复杂性
– 组成复杂系统的组件数量更多；
– 组件之间的关系也更加复杂。

其问题主要有：

• （1）组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。
• （2）某个组件改动，会影响关联的所有组件。
• （3）定位一个复杂系统中的问题总是比简单系统更加困难。

逻辑的复杂性

逻辑的复杂性来源于一个组件集中了太多的功能，修改协作困难；并且，其中某些业务还可能使用了一些复杂的算法，导致难以理解、修改困难。

一个组件集中了太多功能，就会表现出一些逻辑复杂性的特征，为了解决这个问题，一般的手段是进行组件的拆分，但随着组件的细化，又会引入结构复杂性的一些特征，所以，在做结构设计的时候，需要权衡这两者。

3.演化原则

演化优于一步到位。

维基百科对“软件架构”的定义如下：

从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。

这个定义中，将建筑和软件架构做了一个比较，但是，两者之间是有一个本质区别的：对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。
也就是说，软件架构的本质是：软件架构需要根据业务发展不断变化，所以，我们在做软件架构设计的时候，不要试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。

架构设计的过程基本上可以总结为下面三个历程：

• 首先，设计出来的架构要满足当时的业务需要。
• 其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。--
  小重构
• 最后，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。--
  大重构

我们在做架构设计的时候，切勿贪大求全，或者盲目的照搬大公司的做法，而是要牢记软件架构的本质（软件架构需要根据业务发展不断变化）。认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。