134 lines
12 KiB
Markdown
134 lines
12 KiB
Markdown
---
|
||
title: 软件架构风格
|
||
tags:
|
||
- 架构知识
|
||
- 软件架构
|
||
- 软件设计理论
|
||
- 架构风格
|
||
- 体系结构风格
|
||
- 管道和过滤器
|
||
- 事件驱动
|
||
- 分层系统
|
||
- C2架构
|
||
- CS架构
|
||
- BS架构
|
||
categories:
|
||
- - 架构知识
|
||
- 软件设计理论
|
||
date: 2021-04-25 18:24:17
|
||
keywords: 软件架构,设计理论,架构风格,体系结构风格,管道,过滤器,事件驱动,分层系统,c2,cs,bs,体系结构
|
||
---
|
||
|
||
软件体系结构设计的核心目标就是构建可重用的体系结构模式，也就是加强软件的复用。<!--more-->软件架构风格是从众多的软件体系结构中提取出来的模式化的体系结构模型。体系结构风格定义的不是某一个或者某一类特定软件的体系结构，而是定义的具备相同特点的一类软件的体系风格。对这类软件的体系结构设计，如果直接采用与其适配的体系结构风格，可以直接达到体系结构级的软件重用。
|
||
|
||
> 软件体系结构实际上就是软件架构，这两个词汇只是文案不同而已。
|
||
|
||
软件体系结构风格是描述某一特定领域中系统组织方式的惯用模式。体系结构风格定义的是一个系统家族。体系结构风格反应了领域中众多系统所共有的结构和语义特性，并且具备指导将各个模块和子系统有效点组织成一个完整系统的能力。虽然软件架构风格的词语看起来十分的书面，但是软件架构风格的内容却是日常软件架构设计中经常会用到的，并且还会十分的熟悉。
|
||
|
||
## 经典软件体系结构风格
|
||
|
||
### 管道和过滤器架构
|
||
|
||
在管道和过滤器风格的软件体系结构中，每一个构件都有一组输入和输出。数据输入构件以后，经过构件处理，产生数据输出。在这个风格中，构件就被称为过滤器，而构件之间的连接就形成了数据传输的管道，将数据从一个构件传输到另一个构件。
|
||
|
||
管道和过滤器架构通常用于分解执行复杂处理，将复杂处理活动变成一系列可重复使用的分离构件，并且允许执行的处理活动可以独立部署和独立缩放。管道和过滤器架构要求其组成构件具备幂等性和相当的可靠性，并且能够处理重复消息，能够对上下文及状态进行有效的管理。
|
||
|
||
### 数据抽象和面向对象组织
|
||
|
||
目前面向对象编程的概念已经成为一个软件开发的事实标准。数据抽象和面向对象组织风格就建立在数据抽象和面向对象的基础上，在这种风格中，数据的表示和操作都被封装在一个抽象数据类型或者一个对象中。
|
||
|
||
在数据抽象和面向对象组织风格中，构件就是对象，也就是抽象数据类型的实例。
|
||
|
||
### 事件驱动系统
|
||
|
||
在事件驱动系统中，构件不能直接调用一个过程，而是触发一个广播或者多个事件。系统中构件的过程都在一个或者多个事件中注册，当一个事件被触发，系统就会自动调用在这个事件中注册的所有过程。在这种风格中，构件之间不相互直接通信，仅通过标准化的事件或者信号来进行通信，这就实现了构件之间的解耦，增强了构建的独立性。
|
||
|
||
### 分层系统
|
||
|
||
层次系统中是由一个层次结构组成的，每一层都只为了其上面一层服务，同时也作为下面一层的客户。在层次系统中，除了特殊设计的输出过程，每一层的接口都只对相邻的层可见。
|
||
|
||
在分层模式中，层是用来隔离业务关注点的，并且还可以隔离技术复杂度和业务复杂度。层与层之间是正交的，互相没有关联，位于同一层的构件拥有相同的抽象层次。连接件决定了层之间如何交互，并且定义了层之间交互的协议。只要符合层之间的交互接口，每层都可以使用各自不同的方法去实现，这也就为软件的复用和构件的复用提供的了强大的支持。
|
||
|
||
### 仓库系统及知识库
|
||
|
||
在仓库风格中，有两种不同的构件：中央数据结构和独立构件。其中中央数据结构持有当前的状态，独立构件在中央存储上执行业务功能。
|
||
|
||
在很多文章中会将这种体系结构风格成为黑板模式或者黑板系统。这种描述虽然不那么准确，但是也足可以说明仓库系统的特点。仓库系统的特点就是使用数据去影响其他构件的功能，多个业务构件都使用共享的数据。其实在仓库系统中，仓库的角色是会根据不同的控制方向发生变化的。如果构件控制共享数据，那么仓库就会以数据库的形式出现；而如果中央数据结构的状态变化控制独立构件的运作，那么仓库就会以黑板系统的形式出现。
|
||
|
||
仓库系统在处理启发式求解、数据重用性高的软件时十分有效，而且在向系统中添加新软件时非常容易，但是另一方面，仓库系统还具有效率低，不支持并行等缺点。
|
||
|
||
### C2风格
|
||
|
||
C2体系结构比较与众不同，是一个通过连接件绑定在一起按照一组规则运作的并行构件网络。从C2风格的特点看起来这种风格与分层系统十分相似，但是C2风格还是有其非常严格的组织形式的。
|
||
|
||
要组成一个C2体系结构，系统必须严格按照以下规则组织：
|
||
|
||
1. 系统中的构件和连接件都有一个顶部和一个底部。
|
||
1. 构件的顶部连接到一个连接件的底部，构件的底部则应该连接到另一个连接件的顶部，构件和构件之间不允许直接连接。
|
||
1. 两个连接件可以直接连接，但是其中一个的底部必须连接到领一个的顶部。
|
||
1. 一个连接件可以和任意数目的其他构件和连接件连接。
|
||
|
||
在C2体系结构中，非常强调连接件的作用，这与在其他的体系结构中在比较强调构件不同。所有的体系结构中都存在构件和连接件的概念，但是大多都允许构件和构件相互连接，从而使连接件的作用弱化了。实际上，相互连接的构件构成了一种强耦合的关联，这对于复杂系统的构建来说并不是一种好的实践。
|
||
|
||
> 对于**连接件**，大部分情况下可能会将其理解为一个构件，但是事实上并不是这样，连接件是构件间的互联机制，是构件之间交互规则的模型。与构件不同，连接件并不需要编译，它实际上更加像是一个协议。
|
||
|
||
## C/S风格
|
||
|
||
客户端/服务器（Client/Server）风格可能是一个几乎所有开发人员都比较熟悉的体系结构风格了。C/S体系结构是基于资源不对等并且需要实现共享的需求提出的，是一项成熟于20世纪90年代的技术。在C/S体系结构中定义了工作站如何与服务器相连，如何实现部分数据和应用分部到多个处理设备上。所以C/S体系结构中有三个重要的组成部分：数据库服务器、客户应用程序和网络。
|
||
|
||
> C/S体系结构下，客户端是直接远程访问数据库的，不要对此表示惊讶。在客户端和数据库之间存在隔离的是三层C/S体系结构。
|
||
|
||
在C/S风格下，服务器主要用于管理系统的资源，主要执行以下任务：
|
||
|
||
1. 保证数据库安全性。
|
||
1. 控制数据库的并发访问。
|
||
1. 保证客户应用程序的全局数据完整性。
|
||
1. 备份数据库和恢复数据库。
|
||
|
||
相对的，客户端就主要用于业务处理了，主要执行以下任务：
|
||
|
||
1. 提供用户与数据库的交互界面。
|
||
1. 向数据库服务器发出请求和接收来自数据库服务器的数据信息。
|
||
1. 执行业务应用逻辑。
|
||
|
||
C/S体系结构的优点在于系统中的用户应用程序和服务器构件分别运行在不同的计算机上，这对于硬件和软件的变化提供了很大的适应性和灵活性，并且的系统的扩容和减容方面也十分容易。虽然C/S结构的模型思想十分简单，易于理解和接受，但是随着软件规模和复杂度的提高，C/S体系结构的以下缺点会变得越来越显著。
|
||
|
||
1. 开发成本高。随着客户端功能和体积的增加，对于客户端软硬件配置的要求也越来越高。
|
||
1. 客户端程序设计复杂。由于服务器上主要完成数据库的管理工作，所以几乎所有的业务逻辑就都集中在了客户端上。
|
||
1. 信息内容和形式单一。客户端的界面设计是随数据库结构预定的，不容易进行变化。
|
||
1. 用户界面风格不统一。如果客户端运行在不同的系统上，那么很难使用户界面风格统一起来。
|
||
1. 软件移植困难。针对不同的平台需要使用不同的开发平台或者开发工具，这些平台和工具间通常难以相互兼容。
|
||
1. 软件维护和升级困难。C/S体系结构的软件在升级时，开发人员必须要抵达现场进行操作。
|
||
|
||
## 三层C/S风格
|
||
|
||
针对二层C/S体系结构风格的缺点，三层C/S体系结构风格在客户端和数据库服务器之间增加了一个应用服务器。这不仅是在客户端和数据库之间增加了一个隔离，而且还把原来集中在客户端上的许多业务逻辑提取了出来，使客户端大大的“减负”。
|
||
|
||
在二层C/S体系结构中，客户端因为集成了全部的业务逻辑，所以被称为“胖客户端”；而在三层C/S体系结构中，由于业务逻辑被提取到了应用服务器上，所以客户端就只剩下了表现层，体积大大缩减，也就变成了“瘦客户端”。所以在三层C/S体系结构中，系统是分为表现层、功能层和数据层三个部分的。
|
||
|
||
> 三层C/S体系结构的分层已经与目前十分流行的MVC体系结构十分相像了。
|
||
|
||
表现层是应用的用户接口部分，上面承载着与应用逻辑间交互的功能。它仅从用户处接收输入数据，并向用户展示经过应用服务器处理后的数据。当变更用户界面的时候，只需要更改显示控制和数据检查，并不需要修改业务逻辑。
|
||
|
||
功能层是应用的本体，负责具体的业务逻辑。在表现层和功能层之间的数据交互一般都会设计的尽可能简洁，因为复杂的数据交互可能会带来比较高的网络依赖。
|
||
|
||
数据层与二层C/S体系结构中的数据库服务器功能是一致的，只是在三层C/S体系结构中，数据库服务器将只与位于功能层的应用服务器交互。
|
||
|
||
## B/S风格
|
||
|
||
B/S体系结构风格实际上是在三层C/S体系结构风格基础上发展来的，是三层C/S体系结构风格的一种实现。在B/S体系结构风格中，浏览器替代了三层C/S体系结构中的客户端，Web服务器替代了原来的应有的服务器。基于浏览器技术和脚本语言，通用浏览器实现了原本需要复杂的专用客户端才能够实现的功能，并且抹平了不同平台和系统之间客户端的差异，节约了开发成本。虽然B/S体系结构风格是从三层C/S体系结构风格发展而来，但是从一定程度上来说，B/S体系结构的确是一种全新的软件体系结构。
|
||
|
||
在B/S体系结构中，除了数据库服务器以外，应用程序都是以网页的形式存放在Web服务器上的。用户在需要运行应用程序的时候，只需要在浏览器上键入相应的URL调用Web服务器上的应用程序即可。基于B/S体系结构的软件，其系统安装、修改、维护全都在服务器端解决，用户无需特意准备专用的客户端，所以对用户来说，B/S风格的软件基本上达到了“零客户端”的感受，而且业务功能的升级变得完全自动化。
|
||
|
||
但是采用B/S体系结构风格的软件与C/S体系结构风格相比，还是有许多缺点的：
|
||
|
||
1. 系统扩展能力差，安全性较难以控制。
|
||
1. 在数据查询的响应速度上，远远低于C/S体系结构。
|
||
1. 数据提交一般以页面（或者表单）为单位，数据动态交互性弱，不利于在线事务处理应用。
|
||
|
||
## C/S、B/S混合风格
|
||
|
||
虽然B/S体系结构风格的应用具有非常多的优势，但是C/S体系结构的成熟性和对于网络负载较小的优势，使得B/S和C/S混合应用形式诞生了。这种更加复杂饿体系结构常常用在满足不同客户需要的场景中。例如对应用的实时性要求较高的系统部分可以采用C/S体系结构，对于一些普通业务，则可以采用B/S体系结构。
|
||
|
||
这种混合的体系结构风格充分发挥了两者体系结构风格各自的优势，使不同用户的需求都能够得到比较好的满足。
|