架构设计原则 - 合适、简单、演化

合适原则

合适优于业界领先

现在互联网时代，技术的迭代非常快。很多架构师在设计架构的时候的希望用最新的技术来进行设计，以期望达到更好的效果。

但是，最新的技术往往不是最优的选择，哪怕新技术的效果很卓越(例如，谷歌，阿里，腾讯等企业的一些设计方案和技术)。对于大公司而言，很多时候效率和用户体验是第一位，用户量级也是亿级为单位，不得不自主研发内部的系统、架构和中间件，而且需要长期维护和更新。而这些对公司来说，都需要消耗时间、人力和金钱，小公司的话应该优先考虑使用现成成熟的技术，而不是什么模块都自主研发。

对于架构师而言，不是一定要设计出最牛逼的架构，而是要结合当前环境，公司成本，业务场景等因素设计出最合适最合理的架构方案。基于这种考虑，选择不那么新，但是系统稳定，社区活跃，文档丰富的技术来进行架构设计显然要合适合理得多。

简单原则

简单优于复杂

软件领域的复杂性体现在两个方面：

结构的复杂性

结构复杂的系统几乎毫无例外具备两个特点：

组成复杂系统的组件数量更多；
- 组件越多，越有可能某个组件出现故障，从而导致系统故障。
  - 例如，组件的故障率为10%，三个组件系统的可靠性为(1-10%)^3=72.9%，而五个组件系统的可靠性为(1-10%)^5=59%，性能相差13%
同时这些组件之间的关系也更加复杂。
- 某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件
- 定位复杂系统问题比简单系统困难得多。

逻辑的复杂性
- 意识到结构的复杂性后，第一反应可能就是“降低组件数量”，毕竟组件数量越少，系统结构越简。最简单的结构当然就是整个系统只有一个组件，即系统本身，所有的功能和逻辑都在这一个组件中实现。

架构师的视角：在能够实现功能要求的条件下，采用更高效更低成本得解决问题。

对于架构而言，是“房屋的框架”，开发都是基于架构设计开发的。架构复杂度每增加1分，开发的复杂度可能就会增加10分，对了，开发完成后还需要考虑运维的成本。所以架构设计在满足高可用、高性能、高扩展等等的前提下，一定要尽量简单。

演化原则

演化优于一步到位

对于建筑来说，永恒是主题；而对于软件来说，变化才是主题

这个原则不只是适用于架构设计，还适用于产品设计。

再厉害的架构师或者产品经理都不可能一步登天，一下子就设计出完美的架构和产品。而事实上，优秀的架构和产品都是一步一步迭代出来的。比如：每天使用的微信，微信2011年推出至今，已经十年了，但是在十年前推出的微信和现在的微信天差地别，因为微信这十年一直在根据用户的使用情况和市场的发展等因素做着更新迭代，以满足用户使用。

而且产品的不断迭代更加说明了产品活跃的生命力。如果产品不迭代了，那么在这高速发展的社会下，将很快就会被淘汰掉。

产品如此，架构设计也一样，架构设计也需要根据技术的发展，用户量的增大，业务的扩展进行不断地迭代升级，最终演化成优秀的架构。