08-架构设计三原则
前言
成为架构师是每个程序员的梦想，但是程序员和架构师之间有一个巨大的鸿沟，需要程序员去跨域方能成为架构师，那就是“不确认性”。
对于编程而言，其结果是确定的，但是对于架构是不确定的。架构没有编程那么的的约束，可以使用这种方式去实现，而对各种选择，我们就容易迷茫，到底是选择业务最先进的技术，还是开源、商业的...,面对各种选择，架构师可以遵循下面三个原则来做出选择，那就是：
- 合适原则
- 简单原则
- 演化原则
合适原则
合适原则的宣言:"合适优于业界领先"
很多技术人员有很强的技术情节，每次都想挑战自己，想达到甚至超越业界领先水平。但是一般这样做下去的结果就是失败。几个人的团队想要做出QQ、微信这个体量的应用，那是不可能的，为什么呢?
将军不打无兵之仗
大公司分工很细，一个小系统可能就有十几个人负责，整个研发团队有上百人，但是小公司的话，整个团队才十几个人。十几个想做几十人的活，并且还想做的更好，不能说绝对不可能，但是难度会非常大。
没那么多个却想干那么多人的活，是失败的主要原因。
罗马不是一天建成的
业界领先的方案并不是某个天才忽然间想到的，而是经过不断的发展才不断完善的。阿里中间件团队 2008 年成立，发展到现在已经有十年了。我们只知道他们抗住了多少次“双 11”，做了多少优秀的系统，但经历了什么样的挑战、踩了什么样的坑，只有他们自己知道。！这些挑战和踩坑，都是架构设计非常关键的促进因素，单纯靠拍脑脑袋或者头脑风暴，是不可能和真正实战相比的。
没有那么多的积累，却想一步登天，是失败的第二个原因。
冰山下面才是关键 业务领先方案不是天才想出来的，而是业务倒逼出来的。业务发展到一定阶段，旧的方案已经不适合于现在的业务场景,需要一个新的方案来满足业务。通过创新和尝试才会有新的方案。
没有那么卓越的业务场景，却幻想灵光一现成为天才，是失败的第三个原因。
所以说，真正优秀的架构是在公司现有人才、业务、条件等约束下，能够合理的整合资源，发挥出最大的功效，并且能够快速落地。
简单原则
简单原则的宣言：简单优于复杂
软件架构的一门技术活，很多人都会把软件架构与传统的建筑做对比，它们二者间有很多的相似之处。但是它们有很大的区别，建筑追求的是不变，可以追求复杂，而软件追求的是变。建筑建好以后，几十年上百年都可能不会发生改变，但是软件的话，会跟着需求不段的发生变化。复杂在建筑领域代表的是先进，但是在软件领域代表的则是问题。 软件领域的复杂主要体现在下面几个方面：
结构复杂性
- 组成复杂系统的组件多
- 组件间的关系复杂
逻辑复杂性
意识到结构复杂性后，我们的第一反应就是减小组件，但是减小组件会有另外一个问题，那就是组件逻辑复杂。假如我们把电商的所有模块(登录、注册、购物车、商品、支付、订单)放在一个组件，那就是典型的逻辑复杂性。 把这些放在一起会有什么样的问题呢？
- 代码体量大，每次clone代码都要好久
- 每次部署都花费很久、每次修改都要重新部署
- 生产定位问题困难，并且每次出问题都要拉上所有的小伙伴。
- 需求满天飞，因为所有的业务都在一个系统里，每天都在开会、开会中。
- 版本太多，每天都要上线很多个版本，系统每天要重启十几次。
不用多想，出现这样的问题，每个人都会受不了。 功能复杂的另一个特点，就是算法复杂。算法复杂的一个问题就是定位问题困难。
无论是结构复杂还是逻辑复杂，都会改系统带来很大问题，所有在做架构时，在有复杂方案和简单方案可以选择时，尽量选择简单方案。
演化原则
演化原则的原则是：演化优于一步到位。
上文提到过，建筑是不变的，而软件是不断变的。我们不可能在现在就设计出十年后的系统，就像window操作系统不可能一开始就做出win10来，而是从win1.0慢慢演化而来的。 软件架构的设计应该遵循一个这样的规律：
- 首先，设计出一个满足现有业务的架构
- 架构要在实际应用中不断的优化，保留其优秀的部分,修改有缺陷的设计、改正错误的设计、去掉无用的设计，使得架构不断完善。
- 当业务发展时，旧的架构可以要重构、甚至重写。但是有价值的经验、教训却会在新的架构中体现。
小结
本文主要讲了架构设计的三原则：合适优于业界领先、简单优于复杂、演化优于一步到位。
注：文章内容总结于极客时间08 | 架构设计三原则