对于"软件架构"的理解

1 「架构」是什么？ #

在 IT 领域，我们在日常工作中会提到一些相关的词，比如：整体架构、产品架构、业务架构、信息架构、技术架构、软件架构、系统架构、传统架构、云原生架构、服务架构、微服务架构、单体架构、服务网格架构、前端架构、部署架构、物理架构、逻辑架构、运行架构、开发架构、测试架构、存储架构、数据库架构、网络架构、通信架构、可观测性架构、备份容灾架构、安全架构、信息安全架构、分层架构、CS架构、BS架构、事件驱动架构、云架构、混合云架构、插件架构、高可用架构、应用架构、存算分离架构、中台架构、多租户架构、SaaS架构、运维架构、分布式架构、集群架构、大数据架构、人工智能架构、低代码架构、网关架构、认证架构、配置架构、开放架构、开放平台架构、元数据驱动架构、整洁架构、DDD领域模型架构、六边形架构、洋葱架构、插件架构、超融合架构、硬件架构、服务器架构、芯片架构、计算机体系结构(Computer Architecture)、企业架构、组织架构… 看起来「架构」是一个名词，前面加上不同的形容词或者名词，就组成了一个新的概念。似乎「架构」/ 「Architecture」就是一个神奇的词汇。

这么多「xx 架构」，概念上或者某些模式上都是一致的吗？或者说不同角色的人，说的同一个「xx 架构」是指的同一个含义吗？

不搞清楚这个问题，沟通和理解上难免会出现鸿沟。

1.1「架构」的隐喻来源 #

「架构」英文 Architecture，是由「建筑」隐喻而来。IT领域很多概念都是从其他领域隐喻而来，比如可观测性 Observability 源于控制理论。

从维基百科可以看到相关介绍，我简单总结如下。建筑作品以物质形式交付，比如房子、桥、城墙。主要有几个特征：实用、耐用和美感。同时在时代发展过程中，建筑还被认为是一种艺术形式，不仅包括实用、质量，还包括审美、心理和文化等维度。

Architecture(建筑)的含义包括：

描述建筑物和其他物理结构的通用术语。
建筑物和其他物理结构的设计风格和建造方法。
统一或连贯的形式或结构。
艺术、科学、技术和人文知识。
建筑师的设计活动，从宏观层面（城市设计、景观建筑）到微观层面（建筑细节和家具）
建筑师的实践，其中建筑意味着提供或提供与建筑物或建筑环境的设计和建造相关的专业服务。即描述建筑物、建筑物结构、建筑设计方法、建筑建造方法。

1.2 计算机体系架构(Computer Architecture) #

见《计算机发展史》

1.3 软件架构(Software Architecture)发展史 #

见《软件架构发展史》

2 软件架构是什么？ #

2.1 我之前混沌的碎碎念 #

软件架构的定义似乎从这个概念一出现就存在比较大的争议。有人认为架构是抽象的、软件架构就是一个系统的草图，在表现上，可能是以文档、架构图等方式描述系统的结构，也有人往建筑领域的概念上靠。

有几个定义，如下：

一个软件架构是一个软件系统在其操作的某个阶段的运行时(run-time)元素的抽象。一个系统可能由很多层抽象和很多个操作阶段组成，每个抽象和操作阶段都有自己的软件架构。
软件架构(software architecture) 是软件设计的高层部分，是用于支撑更细节的设计的框架。
架构也称为“系统架构/system architecture”、“高层设计/high-level design”或“顶层设计/top-level design”。通常会用一份独立的文档描述架构，这份文档称为“架构规格书/architecture specification”或者“顶层设计”
有些人对“架构”和“顶层设计”加以区分 – 架构指的是适用于整个系统范围的设计约束；而高层设计指的是适用于子系统层次或多个类的层次上的设计约束(但不是整个系统范围的设计)。
软件架构不是一个可实际操作的产品，它是一种可以帮助你：
1. 分析设计在满足既定需求方面的有效性
2. 在设计变更相对容易的阶段，考虑架构可能的选择方案
3. 降低与软件构建相关风险的方式

还有一些定义，如下。

系统的软件架构是对系统进行推理所需的一组结构。这些结构包括软件元素、元素之间的关系以及两者的属性。架构是关于推理和赋能结构的。

架构是一组软件结构。一个结构是由关系维系在一起的一组元素。软件系统由许多结构组成，一个单一结构不能称为架构。结构可以分成不同的类别，这些类别本身提供了思考架构的有用方法。架构结构可以分为三个有用的类别，它们将在架构的设计、文档编写和分析中扮演重要的角色：组件及连接器结构、模块结构、分配结构。虽然软件包含无穷无尽的结构，但并不是所有的结构都与架构有关。如果一个结构支持关于系统和系统属性的推理，那么它才是架构。这个推理应该涉及利益相关者关注的某些重要系统属性。这些属性包括系统所实现的功能、系统在遇到故障或试图关闭时保持有效操作的能力、对系统进行特定更改的难易程度、系统对用户请求的响应能力等。架构结构的集合既不是固定的，也不是有限的。什么是架构取决于系统上下文的推理中什么是有用的。
架构是一种抽象。由于架构由结构组成，而结构由元素和关系组成，因此，架构由软件元素以及这些元素的关系组成。这意味着架构专门有意地省略了对系统推理无用的某些元素信息。因此，架构首先是对系统的抽象，它留意某些细节并忽略其他细节。在所有现代系统中，元素之间通过接口进行交互，接口将元素的细节划分为公共部分和私有部分。架构关注的是公共部分；元素的私有部分(仅与内部实现有关的细节)与架构无关。这种抽象对于控制架构的复杂性至关重要：我们不能，也不希望所有时间都在处理复杂性。我们希望且需要的是，理解系统的架构要比理解系统的每个细节容易很多个数量级。我们不可能在头脑中记住哪怕是一个中等规模系统的每个细节，架构的关键在于让我们不必这么做。
架构是设计，但并不是所有的设计都是架构。
每个软件系统都有一个软件架构。因为每个系统都有元素和关系，无论是否有文档描述这些元素和关系。
架构包括行为。每个元素的行为都是架构的一部分，并帮助我们进行系统推理。元素的行为体现了元素之间以及与环境之间如何相互作用。这显然是架构定义的一部分，并且对系统所展示的属性(比如运行时的性能)产生影响。架构师不必关注元素的所有行为。然而，当一个元素的行为影响了整个系统的可接受性时，这个行为必须被认为是系统架构设计的一部分，并被记录下来。

上面这些还只是冰山一角，《软件架构-理论与实践》里面提到，“目前存在100多个软件架构的定义”。如果算上人们的理解，那就数不胜数了。

2.2 软件架构定义的流派分类 #

从现存的100多个软件架构的定义来看，软件架构的定义大体上可以分成三大类：

组成派定义：关注软件本身，将软件架构看作组件和交互的集合。组成派定义的主要依据是软件架构主要反映系统由哪些部分组成，以及这些部分是如何组成的，强调软件系统的整体结构和配置。
决策派定义：关注软件架构中的实体(人)，将软件架构视为一系列重要设计决策的集合。决策派定义的主要依据是软件架构是软件设计的一部分，软件设计实际上是开发人员意志和决策在软件开发过程中的体现，软件架构更是高层领导和架构师意志和决策的体现，强调的是设计决策，所以更加注重架构风格和模式的选择。
其他定义：业界还存在一些软件架构的其他定义，它们从独特的角度诠释了软件架构。如，一些资深软件架构师根据他们的从业经历，给出的软件架构的描述性定义。

2.3 软件架构的代表性定义 #

组成派定义1：1992年，Dewayne 和 Alexander 给出了软件架构最早的定义之一，他们认为软件是由架构元素(element)、架构形式(form)和架构基本原理(rationale)组成的集合，也就是 "{elements, forms, rationale} = software architecture" 公式。其中：
- (架构)元素，是指具有一定形式的结构化元素，包括处理元素(processing element)、数据元素(data element)和连接元素(connecting element)。
  - 处理元素，负责对数据加工；
  - 数据元素，是被加工的信息；
  - 连接元素，把架构的不同部分组合连接起来。
- (架构)形式，由加权的属性(weighted property)和关系(weighted relationship)构成，其中：
  - 加权，是指下列两种情况之一：
    - 属性或关系的重要性；
    - 在多个候选项之间选择的必要性，因为某些候选项相比其他的可能更受青睐。
  - 属性，用来约束架构元素的选择；
  - 关系，用来约束架构元素的放置(placement)。
- (架构)基本原理，是软件架构的基础理论部分，用于指导在定义架构时面临的多种选择。
  - 基本原理指导如何准确捕获架构风格、架构元素和架构形式的选择动机。
  - 在构建软件架构时，基本原理解释了基本的哲学和美学思想，对架构师有很好的启发作用。
组成派定义2：1993年，Deavid 和 Mary 定义的软件架构包括组件(component)、连接器(connector)和约束(constraint)三大要素，认为软件架构是软件设计过程的层次之一，该层次超越计算过程中的算法设计和数据结构设计。
- 组件可以是一组代码，也可以是独立的程序；
- 连接器可以是过程调用、管道和消息等，用于表示组件之间的相互关系；
- 约束一般为组件连接时的条件。
组成派定义3：1994年，Jones 认为软件架构是组件以及组件之间交互规则的集合。
组成派定义4：1994年，波音公司(The Boeing Company)和DSG(Defense and Space Group) 给出了一个 CFRP 模型：
- 软件由一组元素(element)构成。这组元素分成处理元素和数据元素。
- 每个元素有一个接口(interface)，一组元素的互连(connection)构成系统的拓扑结构。
- 元素互联的语义包括静态互连语义(如数据元素的互连)、描述动态连接的信息转换协议(如过程调用、管道等)。
组成派定义5：1995年，Hayes 认为软件架构是一个抽象的系统规范，主要包括由其行为和接口来描述的功能组件以及组件之间的相互连接关系。
组成派定义6：1995年，David 和 Dewayne 认为软件架构即一个程序或系统各组件的结构、它们之间的相互关系以及进行设计的原则和随时间演化的指导方针等。该定义与系统的整体结构定义没有太大的区别，更加抽象，就是一种哲学思想而已。
组成派定义7：1995年，Cristina 等人认为一个软件架构包括软件系统的组件、互联和约束的集合，系统需求说明的集合，以及说明组件的基本原理等。
组成派定义8：1997年，Bass 等人认为一个程序或计算机系统的软件架构包括软件组件、软件组件外部可见特性及其相互关系。其中，软件组件外部的可见特性是指软件组件提供的服务、性能、错误处理、共享资源使用等。
组成派定义9：2003年，Fowler 在《Patterns of Enterprise Application Architecture》中对软件架构的定义如下：在较高的层次上将系统分解，其中的决策稳定不变，同一系统的架构可以多种多样，架构上的主要内容会影响整个系统的生命周期，架构归结为所有重要之物。
组成派定义10：2004年，张友生在《软件体系结构》一书中将软件架构定义为：为软件系统提供一个结构、行为和属性的高级抽象，由构成系统的元素的描述、这些元素的相互作用、指导元素集成的模式以及这些模式的约束组成。软件架构不仅指定了系统的组织结构和拓扑结构，而且显示了系统需求和构成系统的元素之间的对应关系，并提供了一些设计决策的基本原理。
组成派定义11：2011年，ISO/IEC/IEEE 标准中定义软件架构为某一系统的基本组织结构，其内容包括软件组件、组件间的联系、组件与其环境间的联系，以及指导上述内容设计与演化的原理。
决策派定义1：1995年，Booch 等人认为软件架构是一系列重要决策的集合，这些决策与以下内容有关：
- 软件系统的组织；
- 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；
- 如何组合这些元素，使它们逐渐合成为更大的子系统；
- 用于指导这个系统组织的架构风格。
决策派定义2：2005年，Jansen 等人认为软件架构是架构层次上所有设计决策的集合体，这些设计决策与以下内容有关：
- 架构改造的影响、原理、设计准则、设计约束以及附加需求；
- 架构改造，指的是对软件架构进行增加、删除和移动等操作；
- 原理，即说明为什么要对软件架构进行这样的修改；
- 设计准则，说明在设计中哪些操作可以做；
- 设计约束，说明设计中哪些操作不可以做；
- 附加需求，是指做出一个设计决策后可能会产生一些新需求。
决策派定义3：2006年，Kruchten 等人将软件架构简单地定义为 “设计决策 + 设计”，这里的设计指的是设计决策的推理过程。
其他定义1：Vivek Khare 认为软件架构是设计和构建软件应用的科学和艺术，这些软件应用满足生命周期中用户的各种需求。
其他定义2：Aakash Ahmad 则认为软件架构是包含设计、演化、组件配置和组件互联关系的高层抽象结构。
其他定义3：Andreas Rausch 认为软件架构是一个针对软件改变的框架。
其他定义4：Muthu Rajagopal 认为软件架构是能够有效组合在一起的软件和硬件组件的集合，这些组件组合后能满足预期需求。

2.4 对于软件架构观点的趋势 #

由组成派观点到决策派观点。

软件架构兴起初期，研究者对于软件架构的定义大都倾向于组成派的观点，但随着软件架构的应用和发展，组成派观点的一些缺陷逐渐暴露出来，由于软件开发者只注重软件本身，特别是组件本身，开发过程中经常会出现违背原始设计的现象，导致软件成品不能完全满足需求，软件架构形成之后的评价和演化也面临困难。

在这样的条件下，决策派的观点引起了重视，即以人的决策为描述对象，从设计决策的角度来指导软件开发。然而决策派观点也有其不足之处，即对设计决策的优化程度要求很高，修改代价大。

2.5 为什么软件架构定义没有一个框架来统一？ #

这么多架构的定义，之所以同时存在，是因为还很难利用某个架构定义框架来统一它们。

一方面，学术界和工业界的联系不紧密、甚至脱节，导致他们对软件架构的认识不一致。

研究人员一般认为：

软件架构就是一个系统的草图：软件架构描述的对象是直接构成系统的抽象组件，各个组件之间的连接则表明和相对细致地描述组件之间的通信。
在实现阶段，这些抽象组件被细化为实际的组件，比如，在面向对象领域中，组件就是具体某个类或者对象，而组件之间的连接通常用接口来实现。
与建筑师设定建筑项目的设计原则和目标作为绘图员画图的基础一样，一个软件架构师或者系统架构师对软件架构的陈述作为满足不同客户需求的实际系统设计方案的基础。

业界人士虽然也认同研究人员对软件架构概念的描述，但鉴于现实系统，特别是遇到的现实问题，很多时候很难用某个软件架构定义来进行系统、全面、准确的刻画，解决遇到的问题时也很难达到满意的程度，导致业界人士面对五花八门的软件架构定义时经常感到困惑，甚至刻意回避一些学术界认为比较好的做法。

另外，从事软件架构工作的人缺少系统的专业训练，虽然很多人是从程序员、工程师的队伍中发展起来的，具有良好的软件系统开发经验和解决实际问题的能力，但是缺少很好的问题抽象能力，所以他们谈论的软件架构往往与真正的架构师、研究人员心目中的软件架构不一样，他们非常注重细节问题，而这些细节问题往往使得软件架构师，特别是研究人员比较迷惑。

而在研究人员的心目中，软件架构只是软件系统的一个比较高层次的抽象，也可以说是软件系统的骨架，这个骨架可支撑软件系统稳定、可靠、安全和高质量地运行。如果某一天这个骨架出现问题，软件系统就可能变得不稳定、不可靠、不安全，甚至不能有效地运行了。所以研究人员花费大量的人力、物力和财力研究软件架构如何建模、描述、验证和确认等，也研究出大量的软件架构建模方法、软件架构描述语言(ADL)，以及各种软件质量度量、评估、分析、测试、验证的方法和工具。但是这些成果对于业界人士来说，很多都是纸上谈兵、难以落地，研究人员在业界很难找到认同感。

究其原因，很多研究人员并没有多少工程实践，甚至没有从工程实践出发来提炼问题，所以给出的软件架构定义太过学术化，在此基础上获得的研究成果势必与实际需求存在比较大的差异，也很难在工程实践中推广使用。

另一方面，也是根本原因在于：软件架构与软件系统的应用领域有很大的关联，不同应用领域的软件架构师在强调软件架构共性的同时也热衷于强调个性化。所以出现有些架构定义难以理解，有些架构定义太过简单抽象的情况。

2.6 我对软件架构的定义 #

虽然，软件架构本身难以统一定义，但在个人理解和团队协作中，对于软件架构的概念的理解需要一致，否则难免出现沟通和认知的鸿沟。我基于过往的经历以及对软件架构的理解，并结合决策派和组成派的观点，也做了一个软件架构概念的定义，以此作为认知的起点，后续可以持续迭代。

软件架构是软件的灵魂和骨架、是软件开发沟通协作的基础。

用公式来描述我的定义：

软件架构 = {特征, 决策, 结构}
特征 = {目标, 价值, 优势}
决策 = {原则, 架构风格, 架构模式/个性化处理-场景}
结构 = {元素, 属性, 关系}

架构特征是定义解决什么问题、应对什么风险、提升了多少效率、增加了多少价值、产生了什么优势等。
架构决策是定义如何构建系统的规则：
- 原则包括准则和约束，准则定义哪些能做，约束定义哪些不能做
- 选择合适的架构风格
- 以及如何考虑设计应对要求的场景？选择合适的架构模式或者定义个性化方案处理。
结构是定义系统的组成。

面向不同类别的人群，需要“沟通”的软件架构的内容不一样：

面向建造者或者说软件系统的设计、开发人员，是以造物者的视角，向他们定义：

软件架构 = {特征, 决策, 结构}

面向非建造者的其他利益相关者，如用户、客户，则是以观察者的视角，向他们描述：

软件架构 = {特征, 结构}

3 为何需要软件架构？ #

3.1 软件架构设计的目的 #

我认为软件架构设计的主要目的是为了解决复杂性带来的问题，即管理复杂性，主要包括提升质量、提升效率、降低风险。

从软件架构的起源大致可以看出这点，见《软件架构发展史》。

4 软件架构相关的概念 #

4.1 Architectural Style 架构风格 #

Architectural Style，架构风格，也有翻译成体系结构风格。 Component，组件，也有翻译成构建。

架构风格就是施加在整个系统设计上的一种变换，目的是为系统中所有组件建立一个结构。

基于计算机系统构造的软件会表现出众多架构风格中的一种。每个架构风格都描述了一种系统类别，包括：

一组执行系统所需功能的组件(例如，数据库、计算模块)
一组实现组件间“通信、合作和协调”的连接件
定义组件如何集成为系统的约束
能够使设计者通过分析系统组成元素的已知属性来理解系统整体性质的语义模型[Bas12]

4.2 Architectual Pattern 架构模式 #

架构模式和架构风格一样，也对架构设计施加一种变换。架构模式和架构风格在许多基本方面存在不同：

架构模式涉及的范围更窄一些，它更多地关注架构的一个方面而不是架构的整体
架构模式为架构定义规则，描述了软件是如何在基础功能层次(如并发)上处理某些功能性方面的问题
架构模式倾向于解决架构环境中特定的行为问题(例如，实时应用如何处理同步和中断)

架构模式可以与架构风格相结合来更好地确定系统的整体结构。