最近很久没有更新该专辑内容了。由于种种原因，没有报名今年11月的架构师考试。多了一年的复习时间，可以让我有更多的时间反思自己多年的架构师工作。我会把知识点总结的更加细致，希望能够给计划参加软考的同道中人以启迪。也祝愿各位考生都能顺利通过考试。

按照考纲描述，【系统架构概论】一般不出知识点，出于知识总结的完整性考虑，仍然整理了这部分的重点

系统架构的定义及发展历程

系统架构定义

Architecture IEEE 1471-2000（IEEE's Recommand Practice for Architectual Description of Software-Intensive Systems）：

架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展原则。

系统是组织起来完成某一特定功能或一组功能的组件集。系统用于完成其环境中的一个或多个任务。系统包括：

环境或者上下文决定了系统的开发、运作、政策以及对系统造成影响的环境和设置。

任务是由一个或多个利益相关者通过系统达到的目标的系统的一个用途或操作。

【通俗解读】系统架构（System Architecture）是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。开发的一些列抽象，用于知道各系统方面的设计与实现。架构设计的优劣决定系统的健壮性与生命周期的长短。

架构设计的作用

• 解决相对负责的需求分析问题；
• 解决非功能属性在系统占据重要位置的设计问题；
• 解决什么周期长、扩展性要求高的系统整体结构问题；
• 解决系统基于组件需要的集成问题；
• 解决业务流程再造难得问题。

系统架构的发展历程

20世纪60年代软件工程解决软件危机。1995年再度爆发软件危机，通过软件重用、组件化化解。

第二次软件危机解决过程中，人们关注：

1. 软件复杂、易变，其行为特征难以预见，软件开发过程中需求和设计之间缺乏有效转换，导致软件开发过程困难和不可控。
2. 随着软件系统的规模增大，复杂度提升，整个系统的结构和规格说明越来越重要。
3. 对于大规模复杂软件系统，相较于对计算算法和数据结构的选择，系统的整体结构设计和规格说明已经变得非常重要。
4. 对于软件系统结构的深入研究将会成为提高软件生产驴和解决软件维护问题的最有希望的新途径。

于是软件架构应运而生。

1）基础研究阶段（1968~1994年）软件架构的雏形期。模块化开发方法，把一个待开发软件分解成若干个小且简单的部分，采用对负责事物分而治之的经典原则。将系统分解成模块，分别进行开发，最终再组合成完整软件。分解时按照一定规约分解，得到模块系统结构的方法有：数据结构设计法、功能分解法、数据流设计、面向对象设计等。分解时的规则：

1. 最高模块内聚；
2. 最低耦合；
3. 模块大小适度；
4. 模块调用链的深度（嵌套层次）不可过多；
5. 接口简单、精炼（扇入扇出数不宜太大），具有信息隐蔽能力；
6. 尽可能地复用已有模块。

模块化通过抽象、封装、分解、层次化等基本科学方法（面向对象思想），对软件组件和软件应用进行打包；另一方面，基于模块化思想，提出SOA（Service-Oriented Architecture，面向服务架构）思想，提供一组基于标准的方法和技术，通过有效整合和重用现有的应用系统和各种资源实现服务组件化，并基于服务组件实现各种新业务应用的快速组装，帮助企业应对业务的灵活性要求。

20世纪90年代末期，管理信息系统（MIS Management Information System）得到广泛使用。架构如下：

2）概念体系和核心技术形成阶段（1999~2000年）。2000年，IEEE 1471-2000首次定义软件架构形式化标准，软件架构理论体系建立。最重要的概念是软件组件化。组件具有可组装性和可插拔性。

• 组件VS模块：模块化开发只是逻辑上切分，物理上（代码）通常并没有真正意义上的隔离。组件则是完全物理上隔离。
• 组件VS应用集成：应用集成将一些基于不同平台或不同方案的应用软件集成到一个无缝、并列的、易于访问的单一系统中，建立一个同意的综合应用。
• 组件化比模块化更独立，比应用集成结合得更加紧密。

3）理论体系完善与发展阶段（1996年至今），软件工程领域为研究重点，主要包括：软件架构描述与表示、软件架构分析、设计与测试、软件架构发现、演化与重用、基于软件架构开放方法、软件架构风格、动态软件架构等。

1. 软件架构描述与表示：软件描述语言：基于组件和消息的软件架构描述语言C2SADL；分布/并发类型的架构描述语言Wright；架构互换语言ACME；基于组件和连接的架构描述语言UniCon；基于事件的架构描述语言Rapide；其他较有影响力的描述语言：Darwin、MetaH、Aesop、Weaves、SADL、xADL等；
2. 软件架构分析、设计和测试

• 架构分析：结构分析、功能分析、非功能分析。分析的目的是开发落地前预测架构的质量属性。常用方法：

1. 软件架构分析方法SAAM；
2. 架构权衡分析法ATAM；
3. 成本效益分析法CBAM；
4. 基于场景的架构再工程SBAR；
5. 架构层次的软件可维护性预测ALPSM；
6. 软件架构评估模型SAEM。

• 架构设计：生成一个满足用户需求的软件架构过程。常用方法有：

1. 从工件描述中提取架构描述的工件驱动（artifact-driven）方法；
2. 从用例导出架构抽象的用例驱动（use-case-driven）方法；
3. 从模式导出架构抽象的模式驱动（pattern-driven）方法；
4. 从领域模型导出架构抽象的域驱动（domain-driven）方法；
5. 设计过程中获得质量属性需求的属性驱动设计（attribute-driven design）方法。

• 架构测试：着重仿真系统模型、解决架构层的主要问题。策略分为：

1. 单元；
2. 子系统；
3. 集成；
4. 验收测试等。

测试方法包括：

• 软件架构发现、演化与重用

1. 软件发现：从已有软件系统中提取软件架构，属于逆向工程。
2. 软件架构演化：由于系统需求、环境和分布等因素的变化而最终导致软件架构的变动。包括：
1. 架构动态性：系统在运行时架构的变化；
2. 架构扩展：架构的静态修改。
3. 架构复用：设计重用，比代码重用抽象。架构模式是架构复用的一种成果。

• 基于软件架构的开发方法

通常软件开发模型可分为三种：

架构风格（架构模式）：针对给定场景出现的问题提供一般性可重用方案，反映了领域中众多系统所有的结构和语义特征，并指导各模块和子系统组合成完整的系统。通常分为5类：

4）普及应用阶段（2000年至今）

关注：软件产品线架构，产品线架构表示一组具有公共的系统需求集的软件系统，根据基本的用户需求对标准产品线架构进行定制，将可重用组件与系统独立的部分集成而得到。

软件架构是软件生命周期产物，影响软件开发的各个阶段。

• 需求阶段：引入软件架构，有助于保证需求规约和系统设计之间的可追踪性和一致性。

• 设计阶段：该阶段软件架构主要包括：

1. 软件架构描述；
2. 软件架构模型设计与分析；
3. 对软件架构设计经验总结与复用。

• 实现阶段：将设计的算法、数据类型用程序设计语言进行表示，满足设计、架构和需求分析的要求，从而得到满足设计需求的目标系统。

• 维护阶段：架构针对维护性目标进行分析时，需要对维护属性（可扩展性、可替代性）进行规定，当架构经过一定的开发过程实现和形成软件系统时，这些属性也相应反映了软件的可维护性。

软件架构的未来发展趋势会沿着下述的路线技术发展。

软件架构常用分类及建模方法

1 分层架构

分层架构（Layered Architecture），这种架构将软件分成若干个水平层，每层有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口进行通信。分层架构通常明确约定软件分多少层，最常见的为四层结构。

1. 表现层（Presentation Layer）：用户界面，负责视觉和用户互动；
2. 业务层（Business Layer）：实现业务逻辑；
3. 持久层（Persistence Layer）：提供数据，SQL语句在此层执行；
4. 数据库层（Database Layer）：提供数据的存储。
5. 有的项目在业务层与持久层之间增加服务层（Service Layer），提供不同业务路基需要的一些通用接口。

用户请求依次通过上述的四层或五层结构进行处理，不能跳过其中任意一层直接处理。

2 事件驱动架构

事件（Event）是状态发生变化时软件发出的通知。

事件驱动架构（Event-driven Architecture）通过实践进行通信的软件架构，分为四部分。

1. 事件队列（Event Queue）：接收事件的入口；
2. 分发器（Event Mediator）：将不同额事件分发到不同的业务逻辑单元；
3. 事件通道（Event Channel）：分发器与处理器之间的联系渠道；
4. 事件处理器（Event Processor）：实现业务逻辑，处理完成后会发出事件，触发下一步操作。

简单的项目，事件队列、分发器和事件通道可以合为一体，整个软件仅分成事件代理和事件处理器两部分。

3 微核架构

微核架构（Microkernel Architecture）又称插件架构（Plug-in Architecture），软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（Core）通常只包含系统运行的最小功能。插件是相互独立的，插件之间通信应该减少到最低，避免出现互相依赖的问题。

4 微服务架构

微服务架构（Microservice Architecture）是面向服务架构（Service-Oriented Architecture，SOA）的升级。每个服务都是一个独立的部署单元（Seperately Deployed Unit），它们分布式部署，相互解耦，通过远程协议进行通信（如：RESTFul、SOAP、RPC等）。

微服务架构有三种实现模式：

1. RESTFul API模式：服务通过API提供，云服务属于这类；
2. RESTFul应用模式：服务通过传统网络系诶或应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部；
3. 集中消息模式：采用消息代理（Message Brokeer）可以实现消息队列、负载均衡、统一日志和异常处理。消息代理需要做成集群，否则会出现单点故障。

5 云架构

云架构（Cloud Architecture）主要解决扩展性和并发问题，是最易于扩展的架构。

采用去中心化技术，采用本地化技术增加数据的副本，以增强扩展性与吞吐量。系统能够按照访问量弹性扩容或缩容。

云架构主要分为两个部分：

1. 处理单元（Processing Unit）；
2. 虚拟机中间件（Virtuallized Middleware）。

处理单元：实现业务逻辑。

虚拟中间件：负责通信、保持会话控制（Session）、数据复制、分布式处理和处理单元部署等工作。虚拟机中间件通常包括四个组件：

1. 消息中间件（Messaging Grid）：管理供货请求和会话，当请求进入系统，它决定分配给哪个处理单元。
2. 数据中间件（Data Grid）：将数据复制当每个处理单元，即数据同步。保证每个处理单元都得到同样的数据。
3. 处理中间件（Processing Grid）：可选，如果一个请求涉及不同类型的处理单元，该中间件负责协调。
4. 部署中间件（Deployment Manager）：负责处理单元的启动和关闭，监控负载和响应时间，当负载增加就启动处理单元；负载减少就关闭处理单元。

系统架构的常用建模方法

软件架构模型可分为4种：结构模型、框架模型、动态模型和过程模型。

1 结构模型

以架构的组件、连接件和其他概念来刻画结构。用结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。核心是架构描述语言。

2 框架模型

与结构模型类，但更侧重整体的结构。主要以一些特殊问题为目标建立针对和适应问题的结构。

3 动态模型

是1、2的补充，主要研究系统的“大颗粒”行为的性质。如：描述系统重新配置或演化。这里的动态可以指系统总体结构的配置、建立或拆除通信或计算的过程。

4 过程模型

研究构造系统的步骤和过程，其结构遵循某些过程脚本的结果。

上述4种模型并非独立存在，通常需要结合起来才能刻画软件架构。

另外，还有一种基于UML的视图模型来描述软件架构也非常常见，就是Philippe Kruchten的“4+1”模型。即：

• 逻辑视图（Logical View）
• 过程视图（Process View）
• 物理视图（Physical View）
• 开发视图（Development View）
• 场景视图（Scenarios View）

上述5个视图结合起来也能够反映系统软件架构的全部内容。

软件架构的应用场景

软件架构 风格在实践中被反复使用，不同架构风格具有各自的优缺点和应用场景：

• 管道-过滤器风格：适用于将系统分成若干独立的步骤；
• 主程序/子系统和面向对象架构风格：适用于对组件对组件内部进行设计；
• 虚拟机风格：适用于狗仔解释器或专家系统；
• C/S或B/S风格：适用于数据和处理分布在一定范围，通过网络连接构成系统；
• 平台/插件风格：适用于具有插件扩展功能的应用；
• C2风格：适用于GUI软件开发，用以构建灵活和可扩展的应用系统；
• MVC风格：适用于用户交互程序设计；
• SOA风格：适用于企业集成等场景。