关于架构的几件小事:架构决策

用户头像
北风
关注
发布于: 2020 年 07 月 26 日
关于架构的几件小事:架构决策

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



本篇为架构概述介绍的第二篇,这次咱们书接上回,展开来聊聊架构决策(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,具备了架构师思维的人,就是架构师~!

发布于: 2020 年 07 月 26 日 阅读数: 336
用户头像

北风

关注

不想当咖啡师的架构师,不是好摄影师 2019.03.26 加入

斜杠中年

评论 (1 条评论)

发布
用户头像
666~
2020 年 07 月 27 日 11:05
回复
没有更多了
关于架构的几件小事:架构决策