[架构之路-109]-《软考-系统架构设计师》-软件架构设计-2-软件架构概述：架构风格

引言

建筑风格指建筑设计中在内容和外貌方面所反映的特征，主要在于建筑的平面布局、形态构成、艺术处理和手法运用等方面所显示的独创和完美的意境。建筑风格因受时代的政治、社会、经济、建筑材料和建筑技术等的制约以及建筑设计思想、观点和艺术素养等的影响而有所不同。如外国建筑史中古希腊、古罗马有多立克、爱奥尼克和科林斯等代表性建筑柱式风格；中古时代有哥特建筑的建筑风格；文艺复兴后期有运用矫揉奇异手法的巴洛克和纤巧烦琐的洛可可等建筑风格。我国古代宫殿建筑，其平面严谨对称，主次分明，砖墙木梁架结构，飞檐、斗栱、藻井和雕梁画栋等形成中国特有的建筑风格。

第2节 架构风格

备注：

不同的架构风格展现系统不同侧面的信息，因此，一个软件系统可以采用多种不同风格展现软件的架构。

不同风格的系统或子系统，需要使用不同的架构图来展现。

一个大的系统，通常有根据不同业务的特点，采用不同的风格。

软件架构反应了业务领域中众多系统所有的公有的几个和语义特征，并指导如何将各个构建有效地组织成一个完整的系统。

2.1 数据流风格：数据流动=> 适合描述数据在不同节点/组件/模块之间的串行流动

数据流图（Data Flow Diagram）：简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。

深度学习的数学模型的数据流图，实际上就是数据流风格的架构图，它展现了数据是如何经过一个个环节以及每个环节是如何处理数据的。

批处理：数据必须是完整的、以整体的方式传递。

管道：支持每个构建之间进行流式数据处理。

备注：

• 数据流图非常适合于展现大量数据的数据流在不同组件之间的流转和处理过程！！！

• 数据流图同时适合由多个SOC芯片或多个硬件单元协同处理数据的硬件系统架构！！！

• 如果一个软件系统的不同组件之间，需要串行处理高速数据流，就需要通过数据流图的风格展现软件的架构。因此，数据流图的架构非常适合数据面、控制面、管理面整体的传输流程！！！

• 每个节点通常是独立的执行单元，不同节点之间的输入和输出有依赖关系。

2.2 调用/返回风格：上下层协议栈 =>适合描述数据在上下服务层之间的串行流动

备注：

• 层次图的优点：有利于不同功能的解耦、隔离和分工，除了软件系统，公司的组织架构通常也是层级架构爱。

• 层次图的缺点：增加了系统的延时和系统效率，因此，很多大公司，为了提升组织的执行效率，通常会采用偏平的组织架构，降低决策和执行在组织内流转的时间，从而提升整个组织的执行效率。

• 层次之间的关系（函数调用或线程间通信）：不同层次之间，通常是同步调用的方式传递数据的，因此上下层的代码通常在同一个线程中执行。当然，有时候，也可以通过线程间通信来完成数据的传递。

2.3 独立构件风格：并行进程执行单元 => 适合描述独立自主的单元并行处理数据的场合

备注：

事件是一个种特殊的消息，是包含少量数据信息的消息，在控制面的流程中被广泛使用。

消息是一个更加广泛的概念，可用于传送数据，也可以用于传送事件，也可以传递命令等等。

2.4 虚拟机风格：中央执行单元 =》适合需要动态、实时改变系统行为的软件系统

虚拟机风格的基本思想是人为构建一个运行环境，在这个环境之上，可以解析与运行自定义的一些语言，这样来增加架构的灵活性，虚拟机风格主要包括解释器和规则为中心两种 架构风格。具有运行时系统行为 (自)定义与改变能力 。

备注：需要动态、实时改变系统行为的软件系统，就可以构建虚拟机风格的软件架构！！！

Python执行环境的软件就是基于解释器，如果要描述python执行环境，就可以通过解释器风格的架构来展现或规划。

Linux IP table就是一种规则的软件系统，可以动态地向软件系统添加或删除规则，软件系统就会按照定义的规则执行相关的逻辑。

DSS: 决策支持系统（Decision Support System）是一个基于计算机用于支持业务或组织决策活动的信息系统。 DSS服务于组织管理、运营和规划管理层（通常是中级和高级管理层），并帮助人们对可能快速变化并且不容易预测结果的问题做出决策。决策支持系统可以全计算机化、人力驱动或二者结合。

2.5 仓库风格：中央数据库=》适合围绕集中式数据为中心的软件系统

在仓库风格中，有两种不同的构件:

• 仓库：中央数据结构说明当前状态

• 外购独立构件：在中央数据存贮上执行

仓库与外构件间的相互作用在系统中会有大的变化。

按控制策略的选取分类，可以产生两个主要的子类。

若输人流中某类时间触发进程执行的选择，则仓库是传统型数据库;

另一方面，若中央数据结构的当前状态触发进程执行的选择，则仓库是黑板系统。

黑板模型是一种典型而流行的专家系统结构模式。黑板模型首先于1973-1976年在美国Carnegie-Mellon大学开发的HEARSAY-Ⅱ系统中创立，又在HEARSAY-Ⅲ中得到发展，后来由许多系统所效仿和采用，已是一种十分流行的知识系统结构模式。

多个人类专家或主体专家协同求解一个问题，黑板是一个共享的问题求解工作空间，多个专家都能“看到”黑板。当问题和初始数据记录到黑板上，求解开始。所有专家通过“看”黑板寻求利用其专家经验知识求解问题的机会。当一个专家发现黑板上的信息足以支持他进一步求解问题时，他就将求解结果记录在黑板上。新增加的信息有可能使其他专家继续求解。重复这一过程直到问题彻底解决，获得最终结果 [1] 。黑板充当了共享数据库的作用，并且黑板数据库的内容，随着计算过程的演进，不断的得到更新。

2.6 闭环控制架构： 自动控制=》过程控制

当软件被用来操作一个物理系统时，软件与硬件之间可以粗略是表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态。

适合于嵌入式系统，涉及连续的动作与状态。

空调制冷，定速巡航。对应也有一个开环控制系统，没有反馈循环。

2.7 C2并行架构风格

C2是一种基于构件和消息的架构风格，可用于创建灵活的、可伸缩的软件系统。

一个C2构架可以看成是按照一定规则由连接件连接的许多组件组成的层次网络：系统中的构件和连接件都有一个“顶部”和“底部”；一个构件的“顶部”或“底部”可以连接到一个连接件的“底部”或“顶部”；对于一个连接件，和其相连的构件或连接件的数量没有限制，但是构件和构件之间不能直接相连。

C2风格具有以下特点：

(1)系统中的构件可实现应用需求，并能将任意复杂度的功能封装在一起;

(2)所有构件之间的通讯是通过以连接件为中介的异步消息交换机制来实现的;

(3)构件相对独立，构件之间依赖性较少。系统中不存在某些构件将在同一地址空间内执行，或某些构件共享特定控制线程之类的相关性假设

C2架构风格最重要的特性就是“底层无关性”，这在构件的可替代性和可重用性方面具有显著的作用；另外，C2架构引入了“事件转化”的概念，域解释器把构件的请求转化为接收方能够接收的特定形式，同时也把通知转化为该构件能够理解的形式。

我们要设计的是一个教务点名软件，其中分为3方，学生、教师、以及教务。每方之前可以互相通信，比如学生可以给教师留言、教务可以给学生通知等等。每一方又有不同的功能。根据我们的设计，C2架构风格对我们的软件并不适用。C2架构风格可以概括为：通过连接件绑定在一起的并行构件网络。系统中必须要有构件和连接件。对我们的系统来说，构件和连接件不好确定。我觉得C2更适合那种分工明确的软件，每个构件有具体的分工。而且我们设计的系统3方之间可以相互通信，如果我们把教师、学生、教务封装成3个构件 按照C2的风格，这3方之间无法直接连接，必须通过连接件，所以有多少互动的功能就要设计多少连接件，造成系统复杂度提升。所以我觉得我们的软件不太适合C2风格。

2.8 网络层次架构风格

2.8.1 两层C/S架构

C/S（Client/Server）：客户端=服务器结构。

C/S结构在技术上很成熟，它的主要特点是交互性强、具有安全的存取模式、网络通信量低、响应速度快、利于处理大量数据。因为客户端要负责绝大多数的业务逻辑和UI展示，又称为胖客户端。

它充分利用两端硬件，将任务分配到Client 和Server两端，降低了系统的通讯开销。

C/S结构的软件需要针对客户端不同的操作系统系统开发不同版本的软件，加之产品的更新换代十分快，已经很难适应百台电脑以上局域网用户同时使用。

2.8.2 三层C/S架构

C/S系统快速开发平台采用三层逻辑架构(3-Tier Architecture)，由界面层(UI-User Interface Layer)、业务逻辑层(BLL-Business Logic Layer)，数据访问层(DAL-Data Access Layer)三层组成。在软件体系架构设计中，分层次是最常见也是最重要的一种设计思路，目的是实现“高内聚，低耦合”设计思想。

所谓三层逻辑架构，是在客户端与数据库之间加入一个“中间层”，介于界面层与数据层中间部分的逻辑处理。通常用于处理界面的数据，如数据采集、数据合法性检验、基本数据运算，或界面组件生成、组件状态管理等。基于处理过程封装而成的中间层称为业务逻辑层（BLL - Business Logic Layer）,业务逻辑层没有严格定义和规范，采用三层结构设计符合高内聚，低耦合设计理念，也是研发软件产品最常见的设计方式一。

三层逻辑架构不是指物理上的三层，比如三台联网的机器不是三层逻辑结构或三层体系架构，或者支持B/S应用的才是三层体系结构，所以定义和概念要区分清楚。三层是指逻辑上的三层，即把这三个逻辑层封装在一个软件项目内，是一个整体，缺一不可。三层体系的应用程序将业务规则、数据访问、合法性校验等工作放到了中间层处理，通常情况下，客户端不直接与数据库进行交互，而是通过中间层与数据库进行交互。

现在大量的智能手机的App就是典型的三层CS结构：

• 客户端：手机端App

• 服务器端：业务或应用服务

• 数据库服务器：数据存储

2.8.3 三层B/S架构

B/S结构（Browser/Server，浏览器/服务器模式），是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。客户机上只要安装一个浏览器，如Chrome、Safari、Microsoft Edge、Netscape Navigator或Internet Explorer，服务器安装SQL Server、Oracle、MYSQL等数据库。浏览器通过Web Server 同数据库进行数据交互。

2.8.4 混合架构

CS框架与BS框架各有优缺点，

CS交互性强，响应速度快，安全性强，一般应用于局域网中，对硬件的要求高，但是开发维护成本高；

BS交互性相对弱些，响应速度相对慢，安全性相对低，一般应用于广域网中，可以实现跨平台，客户端零维护。

现在两者的边界是很模糊的，很难完全区分开来，特别是现在做物联网，一个完整的系统里这两种架构应该都会涉及到。

2.8.5 MVC架构

2.8.6 MVP架构

2.8.7 MVVM架构

2.8.8 富互联网架构

2.8.9 基于服务的架构SOA

2.8.9.1 SOA概述

2.8.9.2 SOA实现方式

2.8.9.2.1 SOA实现方式- Web Service

2.8.9.3 SOA实现方式- ESB

2.8.9.4 SOA实现方式- 注册表

2.8.9.3 SOA关键技术

2.8.9.2.1 SOA关键技术 - REST

2.8.10 微服务

2.9 模型驱动架构MDA

模型驱动架构是指一种用于应用系统开发的软件设计方法（信息系统开发的重点是应用软件的设计），它提供了一套软件设计的指导规范，这套指导规范是用模型来表示的。模型驱动架构是由一个名叫OMG(Object Management Group，即对象管理组织)的国际联盟于2001年颁布的。

为了解决软件开发中出现的种种问题，全球最大的软件工业标准化组织国际对象管理组织(OMG，Object Management Group)，在2001年7月提出了模型驱动架构(MDA，Model Driven Architecture)。MDA是一种基于诸如统一建模语言(UML)、可扩展标记语言(XML)，和公共对象请求代理体系结构(CORBA)等一系列业界开放标准的框架，因此，它具备软件设计和模型的可视化、存储和交换的功能。

MDA能够创建出机器可读和高度抽象的模型，这些模型独立于实现技术，以标准化的方式储存。MDA把建模语言用做一种编程语言而不仅仅是设计语言。MDA是为应对业务和技术的快速变化提出的一种开放、中立的系统开发方法和一组建模语言标准的集合，其最终目的是构建可执行模型，实现软件的工厂化生产。MDA是软件开发模式从以代码为中心向以模型为中心转变的里程碑，被面向对象技术界预言为未来最重要的方法学。

模型驱动架构是以模型为核心并由模型映射驱动开发的过程。MDA环境下的系统开发方式就是在开发活动中通过创建各种模型精确描述不同的问题域，并利用模型转换来驱动包括分析、设计和实现等在内的整个软件开发过程。