What Is Architecture?
软件系统的架构是一个隐喻，类似于建筑物的架构。
存在着一个极为重要的特质，它是人、城市、建筑或荒野的生命与精神的根本准则。这种特质客观明确，但却无法命名。( C·亚历山大《The Timeless Way of Building》)
架构（Architecture）这个词来源于建筑学。
IT这个行业中的词汇许多都来源于传统行业。传统行业发展了很多年，有一套成熟的理论，而软件设计这个行业才几十年，在实践中，为了提高生产效率和品质，工程化是一个必然化的趋势，于是传统行业工程化的理论和实践就有了在软件设计这个行业移植的可能性。
在建筑行业或者机械设计行业，在建筑建造出来或者产品加工出来之前，设计人员用图纸来表达自己的设计意图。当然成熟的设计人员在取得认证之前，需要到施工单位或者到加工车间实习很长时间，以防止设计出来之后，无法建造或加工。
Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. 架构： 一个系统的基本组织，体现在它的组件中，它们之间的关系，以及与环境的关系，以及指导其设计和进化的原则。
“软件架构”一词直到 1990 年代才得到广泛使用。计算机科学领域自形成以来就遇到了与复杂性相关的问题。
开发人员通过选择正确的数据结构、开发算法和应用关注点分离的概念来解决早期的复杂性问题。尽管“软件架构”这个词对业界来说相对较新，但自 1980 年代中期以来，该领域的基本原则已被软件工程应用。
软件架构作为一个概念起源于1968 年的Edsger Dijkstra和1970 年代初的David Parnas的研究。这些科学家强调，软件系统的结构很重要，正确的结构至关重要。在 1990 年代，人们齐心协力定义和编纂该学科的基本方面，研究工作集中在架构风格（模式）、架构描述语言、架构文档和形式化方法上。
研究机构在推动软件架构作为一门学科方面发挥了重要作用。卡内基梅隆大学的Mary Shaw和 David Garlan在 1996 年写了一本名为《软件架构：新兴学科的观点》的书，其中推广了组件、连接器和样式等软件架构概念。加州大学欧文分校软件研究所在软件架构研究方面的工作主要针对架构风格、架构描述语言和动态架构。
IEEE 1471 -2000，“软件密集型系统架构描述的推荐实践”，是软件架构领域的第一个正式标准。它于 2007 年被 ISO 采用为ISO/IEC 42010:2007。2011 年 11 月，IEEE 1471–2000 被ISO/IEC/IEEE 42010:2011取代，“系统和软件工程 – 架构描述”（由 IEEE 和 ISO 联合发布）。
在IEEE 1471中，软件架构是关于“软件密集型系统”的架构，定义为“软件对整个系统的设计、构建、部署和演化产生重要影响的任何系统”，
2011 年版更进一步，包括ISO /IEC 15288和ISO/IEC 12207对系统的定义，这些定义不仅包括硬件和软件，还包括“人、流程、程序、设施、材料和自然发生的实体”。这反映了软件架构、企业架构和解决方案架构之间的关系。
架构的核心： 抽象模型（Abstraction Model）
我们所看到的大自然景象就是大自然的实物在我们脑海中的映像。抽象就是我们对某类事物共性的描述。
抽象化主要是为了使复杂度降低，以得到论域中较简单的概念，好让人们能够控制其过程或以纵观的角度来了解许多特定的事态。
做出了强有力的和深刻的抽象是一种艺术。它需要极大的能力深入事物的本质而得到真正深刻的抽象。在科学中，没有谁能告诉你如何去做，在设计中也没有谁能告诉你如何去做。( C·亚历山大《The Timeless Way of Building》)
抽象是计算机科学中最为重要的概念之一。比如我们为一组函数规定一个简单的应用程序接口（API）就是一个很好的编程习惯，程序员无需了解它内部的工作便可以使用这些代码。
计算机存储抽象模型
计算机系统是由硬件和系统软件组成，它们共同协作以运行应用程序，计算机内部的信息被表示为一组组位，它们依据上文有不同的解释方式，程序被其他程序翻译成不同形式，开始是ASCII文本，然后被编译器和链接器翻译成二进制可执行文件。处理器读取并解释存放在主存中的二进制指令。
由于计算机花费大量时间在内存、I/O设备和CPU寄存器之间复制数据。所以，现代计算机存储系统，为了解决存储器的速度、容量和价格之间的矛盾，最终被设计成一个多级分层架构体系。如下图所示：
从上图中可以看到，在存储体系中，自上而下速度越来越低，而容量越来越大，单位价格越来越低。分层结构的顶端是寄存器，速度最快、价格最高、容量最小。最底端是磁盘，速度最慢、价格最低、容量最大。从寄存器中访问数据的速度，是从内存访问数据速度的400倍，是从磁盘中访问数据速度的4000w倍（10ms = 10,000us = 10,000,000ns）。距离CPU越近，速度越快。
在层次模型中，位于更高层的存储设备比低层的存储设备要快，单位比特造价也更高。层次结构中较高层次的存储设备可作为较低层析的存储设备的告诉缓存。
操作系统中的抽象模型
计算机中几个抽象概念介绍：
- 文件：对I/O设备的抽象
- 虚拟内存：对程序存储器的抽象
- 进程：对一个正在运行的程序的抽象
- 虚拟机：对整个计算机的抽象，包括操作系统，处理器和程序
操作系统可以看做是硬件和应用软件之间的一层中介，它封装了底层硬件的细节，设计出统一的接口供上层软件使用，比如说读写文件。而文件其实是对所有IO的抽象，比如说键盘、显示器、硬盘、U盘等，都被看做文件来处理。正是这样的抽象，使得操作变得便捷。
我们平时使用电脑都会开启很多软件，比如用QQ聊天、用浏览器上网等，可是底层的硬件只有一套，该怎么办呢？抽象又帮了大忙。操作系统把物理内存和文件一起抽象成虚拟内存，给每个程序都分配一个，让他们以为自己拥有了所有的地址空间，可以随心所欲的使用，而其实操作系统在背后默默做了一些手脚，把虚拟内存映射到物理的设备上。
进程是操作系统对一个正在运行的程序的一种抽象。在一个系统上可以同时运行多个进程，而每个进程都好像是单独占使用硬件。并发运行是指一个进程的指令可以和另一个进程的指令交错执行。在大多数系统中，需要运行的进程数是多于可以运行他们的CPU个数的。传统系统在一个时刻只能执行一个程序，而先进的多核处理器同时能够执行多个程序，这是通过处理器在进程间切换来实现的。操作系统实现这种交错执行的机制称为上下文切换。
关于软件架构的范围
宏观系统结构：这是指架构作为软件系统的更高层次的抽象，它由一组计算组件以及描述这些组件之间交互的连接器组成。 识别关键问题：这是指软件架构师应该关心那些对系统及其利益相关者有重大影响的决策。 一组架构设计决策：软件架构不应仅被视为一组模型或结构，而应包括导致这些特定结构的决策及其背后的基本原理。 软件架构与设计和需求工程之间没有明显的区别，它们都是从高级意图到低级细节的“意图链”的一部分。
软件系统架构 概念框架
图中的方框表示架构设计文档中需要描述的要素，要素之间的连线表示这些要素之间的关系。整个图分五层：
第一层：Mission
第二层：Environment，System，Architecture
第三层：Stakeholder，Architectural Description，Rationale
第四层：Concern，Viewpoint，View
第五层：Library Viewpoint，Model
第一层：Mission
Mission, 翻译成中文就是任务，使命。也就是为什么我们要做这个系统。可能的原因是为了更大的赢利，市场占有率更高，完善产品系列等等。
第二层： System/Environment/Architecture
System, 翻译成中文就是系统。具体的定义是：一系列组件，组织在一起，相互作用从而完成一个或者一些特殊的功能。
Environment：系统不可能单独存在，它总是存在在一个环境之中。我们将系统范围之外的东西，对系统有影响，有交互的客观存在定义为环境（Environment）.有时也称为系统的上下文（context）。
Architecture：系统架构。每个系统有一个架构。无论你是有意设计而形成，或者自发形成。
第三层：System stakeholder/AD/Rationale
系统利益攸关方。（An individual, team, or organization with interests in, or concerns relative to, a system）。从图中我们可以看出一个系统有一个到多个利益攸关方。
Architectural Description：简称为AD。直译为系统描述。从图中我们可以看出，一个系统架构，有一个系统描述和它对应。系统描述是由stakeholder来识别出来并整理成文。
Rationale：从字典上查下来的含义是：基本原理，根本原因。那么在架构描述文件中要出现那些“基本原理”和“根本原因”呢？个人以为：
在设计软件架构时，我们做了许多取舍，选择。我们需要列出之所以选择A而不是B的理由 架构设计是如何满足功能性需求和非功能性需求。
第四层：Concern/Viewpoint/View
Concern：翻译成中文是关心点，关注点。从图中，我们可以看出concern是和stakeholder联系在一起。利益攸关方有一个或多个concern。通常不同的利益攸关方其关注点不尽相同。有时甚至是矛盾的。抄录一段英文：concerns are those interests which pertain to the system’s development , its operation or any other aspects that are critical or otherwise important to one or more stakeholders. Concerns include system considerations such as performance, reliability, distribution and evolvability.
Viewpoint：我将它直译成观察点。就是你站在什么地方来看这个系统。不同的stakeholder可能有不同的concern，从而导致不同的观察点。
View：我将它直译成视图。就是stakeholder站在某个观察点，他看到系统是个什么样子。视图和观察点一一对应。
第五层：Library Viewpoint/Model
Library Viewpoint：就是一个库，库中存放了前人正对各种系统，各种不同的stakeholder，各种不同的concern，总结出来的观察点。这样可以方便后人来参考使用。
Model：直译成模型。就是用来表达视图的方法。直白地说，就是系统中各种元素是如何组织在一起发挥作用。我们用图形化的表示把你看到的东西表达出来。
4 1 View Model
- design [logical] View
- process View
- implementation [development] View
- deployment [physical] View
- use case view(point)s, Scenarios ( Kruchten, Rational )
Project phases
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.13.3449&rep=rep1&type=pdf
架构模式和风格
有许多公认的架构模式和风格：
- 黑板
- 客户端-服务器（2-tier、3-tier、n - tier、云计算展示这种风格）
- 基于组件
- 以数据为中心
- 事件驱动（或隐式调用）
- 分层（或多层架构）
- 微服务架构
- 单片应用
- 点对点(P2P)
- 管道和过滤器
- 插件
- 反应式架构
- 表征状态转移(REST)
- 基于规则
- 以服务为导向
- 无共享架构
- 基于空间的架构
IEEE 1471 2000
如果描述软件的架构，在你对系统架构描述的过程中，需要出现那些要素（element）, 这些要素之间又有着怎样的关系？IEEE std 1471-2000这篇文档给出答案。
参考资料
https://en.wikipedia.org/wiki/Software_architecture
https://scholar.google.com/scholar?hl=en&as_sdt=0,5&q=IEEE 1471 2000&btnG=&oq=
https://andrei.clubcisco.ro/4isi/ISI_1.pdf
https://en.wikipedia.org/wiki/Abstraction_(computer_science)
https://linux-kernel-labs.github.io/refs/heads/master/lectures/arch.html
