架构不完全是技术的艺术，但完全是决策的艺术。左手业务，右手技术，因地制宜。理性、专业的做出合适的决策，这样架构设计才坚如磐石~！



本篇为架构概述介绍的第二篇，这次咱们书接上回，展开来聊聊架构决策(Architecture decision)。整个架构设计，是通过一系列的决策活动，将不确定性转化为确定性。这一系列的决策活动，称之为架构决策。我个人觉得架构决策是整个架构设计的内核。架构决策不是一成不变的。它也会随着整个系统和设计的逐渐清晰，而逐渐演变。甚至在系统生命周期的不同阶段，同样一个问题可能会有完全不同的架构决策。这一切的一切，又回到了原点：我们为什么要做这样的决策~！



什么是架构决策

什么是架构决策？这个问题看似简单。随着设计所涉及的信息不断增多。这个问题会变得不大好回答。



一般来说，对于特定的架构问题(Architecture problem)通常有不同的解决方案。不同的解决方案会带来不同的组件(components)、组件之间关系、技术的选择以及相应的基础设施。这些不同的解决方案通常满足不同的功能需求、性能需求，也有相应的不同的成本。架构决策就是因地制宜，根据功能、性能以及预算的需求，为特定的架构问题选择合适的解决方案，来让所有的干系人(stakeholders)达成一致。



架构决策可以帮助架构师：

1. 正式的记录在整个架构设计过程中，所做的重要的决定。

2. 让所有人理解和同意为什么解决方案是如此设计的。



架构决策必须：

1. 明确的做出决策并给出理由~！

2. 帮助确保解决方案同时满足功能性需求和非功能性需求。如果不满足，则需要像向所有干系人说明并达成一致。

3. 在整个解决方案交付周期内，防止不必要的反攻。



咱们谈了这么多架构决策是什么。我觉得更重要的是聊聊架构决策不是什么？架构决策包含技术选型，但不是单纯的技术选型。架构设计是一个整体(overall)的设计。所以架构问题，一般也是一个整体性的问题。如果单纯的谈论技术，脱离的问题的背景和上下文，则不是架构设计。甚至架构问题也不一定是一个技术问题，不能因为咱们手里有技术这把大锤，就要就这把大锤敲所有的钉子。一个好的架构决策，一定是平衡了各种因素的架构决策。

架构原则



架构原则(Architecture principle)，按照我的理解，就是架构的架构。也就是架构决策的出发点。它是高度抽象的确定性，是企业级的。架构原则通常来自于企业架构。将企业定义为一个整体，并让所有的独立的解决方案可以互相适配。通常架构原则是架构设计的纲领，也是解决架构冲突的最终手段。一般来说，立项的时候，基本上就要想好架构原则。



例如在云上，我们经常说要满足日志系统中心化原则。基于此原则，咱们有ELK stack解决方案作为备选，也可以采用LogDNA 这种SaaS服务作为备选。但不管选择哪种方案，都要把所有的组件的log 都放进去。每个API 维护自己的ELK或者LogDNA 是不可以的。因为违背了日志中心化原则。这仅仅是一个简单的例子，通常一个架构决策所依赖的可能不止一条原则。甚至某些架构决策如果互相冲突的话，就需要依赖于架构原则来解决冲突。



架构决策的形式



架构决策需要正式的文档和确定的形式。通常，架构决策必须需要包含以下几个元素：



1. 架构决策的概述：描述了本次架构决策做了什么决定。

2. 唯一编号：在项目中唯一的编号，避免混淆。

3. 架构问题：所要解决的架构问题是什么。

4. 假设：在上下文中的一些确定性的假设。这也是架构决策依赖的重要组成部分。如果假设变了，那架构决策就不再成立。

5. 备选：该架构问题存在的备选方案。

6. 架构决策：选择了备选方案中的哪一个方案。

7. 决策理由：为什么选择该备选方案。

8. 架构含义：所采取的觉得对方案的其他元素的影响，或对后面的结果的影响。



为什么我们说架构设计是一个确定性的设计。就是因为所有的架构设计图上的元素，大多都需要经过架构决策的推敲和洗礼。其实大家可以想象到。架构决策通常都不是一个单一个的决策。而是一生二、二生三、三生万物的过程。一个架构决策套一个架构决策，形成一整套决策树，来构成了整个架构设计。这个架构决策树的根节点，就是架构原则，基于架构原则，开枝散叶，形成了整个架构设计。

分层思考与架构决策



洋洋洒洒讲了这么多。其实是希望大家明白，架构决策不是一个独立的活动。从原则到决策，是一整个树型的决策过程。当遍历了整棵树之后，整个的架构设计就应该是确定性的了。所以有经验的架构师，看到架构图上的元素或者图例，就会联想到它背后代表的决策树。如果只是复制粘贴几个图例，往往是讲不清楚这些图例背后的架构决策的。一般来说，一个架构设计也要经过数轮审查。能不能过，还取决于是否所有的元素是否都经过系统、严谨的决策。所有的元素都有的放矢，都站得住，才能挨得过其他架构师的暴风骤雨般的提问。这也是为什么，架构师讲话通常都落地有声，底气十足。



另外，决策也是有技巧的。那就是分层思考。人认知和思考是有局限的。通常一个人是没办法把所有的问题都一股脑的装进脑袋去思考。那么解决办法就是将问题分解，一次只做一个部分。就像架构决策的表达形式一样。一个架构决策要经过那几个过程，将问题分解开，才能逐步的得到确定性的解决。整个系统的设计，则是依照架构原则，将系统分解。每个模块专注以自己的功能和实现。再下一层，每个块，又根据需求，分解不同的架构问题，然后经过架构决策一一解开。这种自上而下，既能服务整体，又能将问题分而治之的思考模式，就是架构师思维。



所以架构并不是一种技术，而是一种思考方式。架构师，也不是一个title，具备了架构师思维的人，就是架构师~！