[读书笔记]架构设计原则

架构设计面向的是不确定性，需要面对多种可能性时进行选择。

选择的前提是知识和经验，知识是指有哪些技术、可用组件、实现思路等，这个决定了可选的范围。经验是对当前的业务、情形进行分析，能识别对当前的工作最有效的要素，能从选择空间里做出选择。

多学习：扩大可选择的空间和范围
多实践、思考：做出选择的依据和原则。

做选择的原则：合适原则、简单原则、演化原则

合适原则

合适优于业界领先

有多少人做多少事

结合自己团队的规模和能力，评估哪些事自己做，哪些事复用已有的工具。评估过程可以保守一点，即更多的复用，更少的自己做，以确保目标的达成。

涉及的选择：能做多少事？要做哪些事？要做的事情怎么做？要复用的工具复用哪些？
在选择的时候要结合自己的业务，不是因为哪个更先进而选择哪个，而是因为它合适而选择它。

优秀的系统是逐渐演进的

优秀的系统不是一次做出来，而是随着业务发展、踩坑、复盘、优化逐渐演进的，妄想一步登天的做法，且不说开发周期更长，项目复杂度和风险更高，还会有更多的无效投资。即 基于对未来的预期而做出的额外投入，却因为预期本身是不成立的，导致这部分投入是无法获益的。演进的思路，则是在每个关键点能更有把握的看到不远的未来，进行针对性的优化提升，有更大概率的兑现。

业务场景是架构的土壤

不同的业务场景适合不同的系统，优秀的系统都源自对应的业务场景和需求。业务的发展倒逼架构的演进，没有对应的业务和规模，妄想创建超越当前业务根基的系统，是会水土不服的。

简单原则

简单优于复杂

在软件领域，复杂代表的是“问题”。

软件领域的复杂性体现在结构的复杂性和逻辑的复杂性。

结构的复杂性是指组成系统的组件数量比较多，组件之间有复杂的相互关系。

结构复杂的问题是：

• 组件越多，越有可能出现系统故障（假设每个组件的故障概率一致）
• 某个组件的改动，会影响到相关的组件，需要协调各方进行方案评估、资源协调、上线配合，影响系统开发效率
• 问题的定位更加难

逻辑的复杂性，如一个组件承担了太多的功能，导致这个组件很难被理解和维护，牵一发而动全身。组件过于庞大、臃肿，编译时间太长，影响调试、上线的效率。

再如采用了复杂的算法，导致难以理解、难以实现、难以修改，出了问题难以快速解决。比如ZooKeeper采用了ZAB协议，比采用Raft协议的etcd更加复杂。

《UNIX编程艺术》总结的KISS：Keep It Simple， Stupid！

演化原则

演化优于一步到位。

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

• 古埃及的吉萨大金字塔，4000多年前完成的，到现在还是当初的架构
• 中国的明长城，600多年前完成的，现在保存下来的长城还是当年的结构

作为对比：

windows从1985年1.0版本，92年推出3.1版本，95年推出95版本，2001年推出xp版本，2006年推出Vista版本，09年推出win7，12年推出win8。

软件架构，要根据业务发展不断变化。

妄想一步到位的设计一个架构，会投入巨大的成本到不确定的事情上，落地遥遥无期，且很多预测因为没有兑现，导致没有价值的投入。

天气预报也不能预测未来几年的天气；能快速落地，灵活演进的架构才有生存的空间，每一次落地都可以在业务中见证投入的价值兑现。

软件架构设计类似于生物进化：

• 首先，生物要适应当时的环境
• 其次，生物需要不断地迭代繁衍，将有利的基因传递下去，将不利的基因剔除或修复
• 最后，当环境变化时，生物要能快速适应变化，否则被淘汰；新生物会保留一部分原来的基因

软件架构有类似的过程：

• 首先，架构要满足当前的业务需要
• 其次，架构要不断在应用过程中迭代，保留优秀的设计，修复有缺陷的设计，去掉无用的设计，使得架构逐渐完善
• 最后，当业务发生变化，架构要扩展甚至重构，但是有价值的经验、教训、逻辑、设计等在新架构中延续

《从零开始学架构》第2章 架构设计原则