京东云开发者|探寻软件架构的本质,到底什么是架构?

时间:2022-10-27 15:09:33
不论是开发人员还是架构师,我们都一直在跟软件系统打交道,架构是在工作中出现最频繁的术语之一。那么,到底什么是架构?你可能有自己的答案,也有可能没有答案。对“架构”的理解需要我们不断在实践中思考、归纳、演绎,形成自己的认知。

“ 是件非常困难的事情,不同的组织对于软件架构有不同的定义,每个人心中也有自身对于系统架构定义的认知。就好比我们无法百分之百表述模型而只能产出模型不同维度的视图,对架构进行完备的定义是不可能的。

“道可道,非常道。名可名,非常名”。

行业内不同的组织和个人从不同的视角对 “什么是架构” 进行了定义或阐述。

IEEE 关于架构的定义

governing its design and evolution --ANSI/IEEE

的组合。通过图形化的形式表述该架构定义如下图所示,这是一个非常简洁、概念清晰的定义,其言简意赅的表达了架构的几个核心要素:

:表达系统的宏观结构
:组件化的思维,同时突出了环境要素。组件表达了系统的模块化,组件相互之间及组件与环境之间的关联表达元素间的相互作用。
:用于指导设计和系统演进的原则

 


 

。架构设计是关于权衡的艺术,架构设计过程中充满了各种各样的决策,这些决策也终将反应系统架构。

Martin Fowler

软件架构就是重要的东西,不论它是什么!

Ralph Johnson

以上的定义从高层抽象视角对什么是架构给予了自己的回答,相比之下,Neil Ford 从架构组成元素入手,从更偏向实践的角度对架构进行了阐述。核心思想是软件系统的架构包括以下组合元素:

:应用系统所选择的架构风格,比如微服务架构、单体架构还是SOA等
:系统的非功能性属性,比如性能、可用性、可维护性等
:系统设计过程中重要的架构决策
:设计过程中的指导性原则

 


 

结构

结构是系统架构的重要组成部分,其从宏观上表述了系统的结构组成。架构设计的核心任务之一是为系统选择合适的架构风格。比如,架构师基于上下文的权衡,可以选择模块化单体架构风格,也可以选择微服务架构风格。

 


 

架构属性

 


 

架构决策

。比如对架构风格的选择对系统存在重要影响,其改变的成本较高,理当属于架构决策的范畴。比较典型架构决策包括但不限于:

高优先级的架构属性
•修改对外接口:对外提供的接口修改往往需要进行充分影响分析
:依赖的加入和移除往往标示着组件能力的引进和废弃
:工程结构是应用架构的重要维度之一
迫使研发人员改变开发方式
:重构影响较大的技术债往往对现有系统会有较大影响

》一文

设计原则

比如,设计原则可能是:在可能的情况下,跨系统间的通信尽可能使用异步消息机制以提高性能和降低耦合。


 

以上对架构的定义各有特点:

•IEEE定义更加结构化和规范化
Martin Fowler的定义侧重架构决策的重要性
Ralph Johnson 则更加泛化,突出 “重要” 这一核心因子
Neil Ford则更具象化

Ralph Johnson 对于架构的抽象化定义,简单却不失对架构本质的阐述,这也是我在工作中判断架构边界的准则之一。

2 架构设计的边界

•系统的架构应该设计到什么粒度?
•架构设计是否要足够详细以便能直接指导开发人员开展编码工作?

,涵盖了实现的 “细枝末节”,自己除了CRUD没有发挥的空间
,基于设计方案根本无法指导开发,自己还得重新设计

 


 

会出现架构设计边界放大的情况:

架构师把架构设计当作详细的技术方案设计,牢牢把控系统实现的所有细节,产出大量的设计文档,然后交由核心开发人员做代码实现的执行工作。

这种现象会导致如下问题:

不利于其技术水平及认知的提升
•作为架构师你真的能讲所有的细节都Cover住吗?即使耗费巨大精力完成了 “完备” 的设计,来自一线开发所面临的各种场景是否能够提前预知和捕获?
•如果需求迭代持续如此,作为核心开发人员多半会有所 “怨言”
•作为团队的架构师精力有限,持续的细节输出会耗费巨大精力,而无法关注更加宏观的层面
•.......

不能明确架构设计的边界!

架构设计与设计(实现相关)的边界或粒度问题
团队架构师与开发人员间的职责边界

判断架构边界的前提之一是:明确架构和设计的关系!

所有的架构都是设计,但设计不一定是架构!

从架构的定义看架构设计的边界,选取两个视角:

架构是系统中重要的东西!无论它是什么(之所以重要,是因为改变的成本高)
架构设计涵盖系统中重要的架构决策

所以,架构设计应该涵盖系统中重要的东西,这些 “重要的东西” 可能是:

应用架构风格的选择
子系统间信息通信的方式
工程采取的分层以及层间约束
工程应该遵循的开发规范
工程引入的三方类库,或者三方框架
:比如某次需求建设非常关注系统的性能,或者扩展性等架构属性

架构设计涵盖了系统所需的重要的架构决策,从宏观层面对系统实现予以指引。而详细的设计则为具体的开发实现提供指导,比如,详细的E-R图设计、具体的代码级别的模式选择、某个组件的具体实现等等。

架构设计信息要高效的同步至开发人员
实现过程中的变更同样也要回向反馈至架构,以便对架构设计进行调整

 


 

上下文!!!以上的判断准则必须要给定的上下文中才有价值。

 


 

如果当前上下文,我们非常关注系统的扩展性,该架构属性是我们高优先级的架构属性,那么,核心模块的策略模式的应用可以看作是架构设计的范畴。而如果上下文中扩展性不是我们关注的高优先级的架构属性,相比我们更关注性能,那么,这种代码级的设计模式选择应该属于架构设计的范畴之外了,而需要划分到实现设计层面,交由核心开发自主决定。

3 架构模式(Patterns)与架构风格(Styles)

是极容易混淆的两个概念,很多开发人员将其理解为同一事物,而实际上二者有本质区别。

,从宏观视角表述我们的系统组成。更进一步,架构风格聚焦于系统的分层、模块以及交互形式。
重复出现问题提供解决方案

二者概念不同,并不存在冲突,其联系如下图所示:

,在同一架构风格上下文内可以应用一或多种架构模式
以产生新的架构风格

 


 

:CQRS本身是一种模式,将命令和查询的职责在不同维度进行分离。该模式我们可以在单体架构风格中使用,也可以在微服务架构风格中使用,当然也可以在SOA架构风格中使用。

 


 

4 为什么要做架构设计 ?

。但,在此不做展开过多说明,通过一句话来进行概括:

重要 !

收益高
成本高

5 开发人员和架构师的知识模型

作为开发人员,更加关注知识的深度,以便有足够的知识储备满足工作需要。开发人员在职业生涯的早期,应该关注于自身知识储备的增长,并保持技术深度。

 


 

。系统架构设计是关于权衡的艺术,在特定的问题域上下文下,架构师需要在诸多可行的解决方案间进行权衡和决策,这也对其技术广度提出了要求。开发人员成长为架构师,应该更加关注知识的广度,并在几个特定领域深耕,以便有足够的知识支撑架构决策。

 


 

。该模型将认知层次划分为逐步递进的六个层次:

:识别和回溯事实性知识
:理解事实的内涵
:将事实、规则、概念、思想加以应用
:将信息分解、关联、区分、实验、测试
:将信息或思想的价值进行评价
:整合不同的信息形成新的知识体系

 


 

不论是架构师还是开发人员,Bloom认知层次模型都适用。通过不断的学习扩展自身的知识体系,在识记、理解和应用的同时,要持续的培养分析、评估和创造的能力,逐步向高层次的认知水平提升。

。知识是无限的,没有人能够以有限的精力去学习无限的知识。不论是开发人员还是架构师,又或者其他角色,不应该只将精力投入在知识边界的扩充,而应该注重从知识到认知提升的转变。

吾生也有涯,而知也无涯。以有涯随无涯,殆矣!已而为知者,殆而已矣! ----《庄子》

。这种认知层次由下及上的跃升有两种方式:

:由内向外,通过不断积累、持续思考,由量变到质变,直至 “开悟”
:自外向内,高层次或不同的思想输入碰撞,加速认知层次的突破

 


 

 

为学日益,为道日损。损之又损,以⾄于⽆为。⽆为⽽⽆不为。 --《道德经》

6 结语

大道至简,殊途同归,格物致知,与君共勉!

作者:倪新明