当前位置：首页 > news >正文

计算机基础知识（第四篇）

news 来源：原创 2025/6/6 10:17:18

计算机基础知识（第四篇）

架构设计

概述

软件架构的定义：软件架构（Software Architecture）或称软件体系结构，是指系统的一个或者多个结构，这些结构包括的构件（可能是程序模块、类或者是中间件）、构件的外部可见属性及其之间的相互关系。体系结构的设计包括数据库设计和软件结构设计，后者主要关注软件构件的结构、属性和交互作用，并通过多种视图全面描述。

简单理解软件架构：软件架构指从需求分析到软件设计之间的过渡过程。只要软件架构设计好了，整个软件就不会出现坍塌性的错误，即不会崩溃。

软件架构的详细解释：软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用（连接件）、指导构件集成的模以及这些模式的约束组成。

总结：在软件中，架构决策包括如何组织代码、模块和组件，如何处理数据流、用户界面和业务逻辑。好的软件架构能够确保软件具有良好的性能、可扩展性、可维护性和安全性，就像一个精心设计的大楼能够提供舒适和便捷的居住环境一样。所以，软件架构就是软件的总体设计方案，它决定了软件如何组织和工作，规定了软件系统的整体结构和各个部分之间的关系，以满足用户需求和业务目标。好的架构是构建可靠软件的基础。

软件体系结构设计：

数据设计：数据设计为软件体系结构设计提供了数据基础。它涉及数据的存储、组织和管理，确保数据能够高效地被访问和处理。
体系结构设计：体系结构设计为软件系统的整体结构提供了规划和设计。它涉及确定系统的主要组件及其交互方式，确保系统能够满足功能和非功能需求。

软件架构的定义：

构件的描述
构件的相互作用（连接件）
指导构件集成的模式
这些模式的约束

软件架构设计的生命周期

软件架构设计贯穿于软件开发生命周期的各个阶段。软件架构设计并非只在开发初期进行，而是贯穿于软件开发生命周期的各个阶段，包括需求分析、设计、实现、测试、部署和维护等。
需求分析阶段。需求分析和SA设计面临的是不同的对象：一个是问题空间；另一个是解空间。从软件需求模型向SA模型的转换主要关注两个问题：如何根据需求模型构建SA模型。如何保证模型转换的可追踪性。简单来说，该阶段关注的是如何将用户需求转换为软件架构模型，并确保模型的可追踪性。
设计阶段。是SA研究关注的最早和最多的阶段，这一阶段的SA研究主要包括：SA模型的描述、SA模型的设计与分析方法，以及对SA设计经验的总结与复用等。有关SA模型描述的研究分为3个层次：SA的基本概念（构件和连接件）、体系结构描述语言ADL、SA模型的多视图表示。简单来说，该阶段关注的是软件架构模型的描述、设计与分析方法，以及设计经验的总结与复用。
实现阶段。最初SA研究往往只关注较高层次的系统设计、描述和验证。为了有效实现SA设计向实现的转换，实现阶段的体系结构研究表现在对开发过程的支持、开发语言和构件的选择以及相关测试技术。简单来说，该阶段关注的是如何将软件架构设计转换为代码，以及如何进行测试。
构件组装阶段。在SA设计模型的指导下，可复用构件的组装可以在较高层次上实现系统，并能够提高系统实现的效率。在构件组装的过程中，SA设计模型起到了系统蓝图的作用。简单来说，该阶段关注的是如何在架构设计模型的指导下，进行可复用构件的组装，提高系统实现效率，并解决组装过程中的相关问题。
部署阶段。提供高层的体系结构视图来描述部署阶段的软硬件模型，以及基于SA模型可以分析部署方案的质量属性，
从而选择合理的部署方案。简单来说，该阶段关注的是如何根据软件架构模型进行部署，并分析部署方案的质量属性。
后开发阶段。是指软件部署安装之后的阶段。这一阶段的SA研究主要围绕维护、演化、复用等方面来进行。典型的研究方向包括动态软件体系结构、体系结构恢复与重建等。简单来说，该阶段关注的是如何根据软件架构模型进行维护和演化。

软件架构设计贯穿于软件开发生命周期的各个阶段，每个阶段都有其特定的关注点和研究内容。通过这些阶段的研究和实践，可以确保软件架构设计在开发、实现、部署和维护过程中发挥其应有的作用，从而提高软件系统的质量和可维护性。

构件

在架构设计中，构件（Component）是指系统的重要部分，它们是功能上独立且可以被替代或扩展的模块或单元。外界通过接口访问其提供的服务，构件通常用来划分系统的不同功能或责任，以便更容易管理、维护和扩展整个系统。构件是系统架构的基本构建块，可以包括软件模块、类、库、服务等。

类 (Class)

类是面向对象编程中的基本概念，它描述了一种对象的属性和行为。类定义了对象的结构和行为模板，可以包括属性（数据成员）和方法（函数成员）。

模块 (Module)

模块是一组相关的函数、类、变量或代码块的集合，用于将代码组织成更小的可管理单元。模块可以是一个单独的文件或一组相关文件。

构件 (Component)

构件是指软件系统中的可复用组件。构件可以是代码、数据、文档或其他任何类型的软件资产。构件通常是松散耦合的，并且可以组合起来形成更大的软件系统。构件的典型示例包括类、模块、组件和框架。

服务 (Service)

服务是指提供特定功能的软件单元。服务通常是独立的、可复用的，并且可以通过网络进行访问。服务的典型示例包括 Web 服务、REST API 和微服务。

构件的组装方式：

基于功能组装：通过子程序调用实现功能模块集成
基于数据组装：围绕核心数据结构构建框架（如Jackson方法）
面向对象组装：通过继承、多态实现复用

组装过程中的关键点：

接口匹配：确保构件接口的输入／输出兼容性（如协议、数据格式）
语境适配：调整构件对运行环境的依赖（如数据库连接配置）
异常处理：解决组装失配问题（如通信协议不一致、数据模型冲突）

构件的作用：

构件技术是利用编程手段，将一些复杂的细节进行封装，并实现各种业务逻辑规则，用于处理用户的内部操作细节。构件技术使得复杂系统的开发和维护变得更加便捷和高效，避免了最终用户直接操作底层细节。目前，国际上常用的构件标准主要有三大流派：EJB、COM、DCOM、COM+和CORBA。

EJB

EJB 规范由 Sun 公司制定，主要用于 Java 平台的企业级应用开发。EJB 有三种类型：

会话 Bean (Session Bean)：用于管理会话和业务逻辑，有不同的类型适应不同的需求。
实体 Bean (Entity Bean)：用于与持久化数据交互，将对象映射到数据库表。
消息驱动 Bean (Message-driven Bean)：用于异步消息处理，响应来自消息队列的消息。

COM、DCOM、COM+

这些技术由微软公司提出：

COM (Component Object Model)：微软公司的一种组件标准，用于创建可重用的软件组件。
DCOM (Distributed Component Object Model)：COM 的扩展，增加了位置独立性和语言无关性，支持分布式计算。
COM+：并不是 COM 的新版本，而是 COM 的进一步发展，提供了更高层次的应用功能。

CORBA

CORBA 标准由 OMG (Object Management Group) 制定，分为三个层次：

对象请求代理 (ORB)：最底层，规定了分布对象的定义（接口）和语言映射，实现对象间的通讯和互操作，是分布对象系统中的“软总线”。
公共对象服务：在 ORB 之上定义了很多公共服务，可以提供诸如并发服务、名字服务、事务（交易）服务、安全服务等各种服务。
公共设施：最上层，定义了组件框架，提供可直接为业务对象使用的服务，规定业务对象有效协作所需的协定规则。

微服务架构标准

核心规范：RESTful接口描述标准（替代CORBA IDL)
技术栈：Spring Cloud Alibaba、Quarkus、Micronaut

云原生构件标准

容器镜像标准（Docker/Containerd兼容）
运行时规范（Kubernetes CRI标准）

跨平台互操作标准

GraphQL：替代传统SOAP/WSDL，实现前后端解耦
Apache Arrow：内存数据交换格式（跨语言／组件高效通

软件架构风格

软件架构风格的概念：是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义一个系统家族，即一个架构定义、一个词汇表和一组约束。架构定义描述了系统的整体结构和组织方式。词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。简单来说，软件体系结构风格就是一个模板，它规定了特定应用领域中软件系统应该如何构建。

软件架构风格的作用：反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。对软件架构风格的研究和实践促进对设计的重用，一些经过实践证实的解决方案也可以可靠地用于解决新的问题。

架构设计的一个核心问题是能否达到架构级的软件复用，强调对架构设计的重用。

架构风格定义了用于描述系统的术语表和一组指导构建系统的规则。

数据流风格

面向数据流，按照一定的顺序从前向后执行程序。

数据-批处理
批处理序列是一种架构风格，其构件是一系列按照固定顺序执行的计算单元。多个任务按照同步顺序执行，构件之间通过数据传递进行交互。每个处理步骤是一个独立的程序，必须在前一步结束后才能开始。数据以整体的方式传递，必须是完整的。典型的例子包括批量图像处理，如一次性处理大量图像，执行调整大小、添加水印或转换格式等操作。

管道-过滤器
管道-过滤器是一种架构风格，每个构件都有一组输入和输出。构件读取输入的数据流，经过内部处理，产生输出数据流。前一个构件的输出作为后一个构件的输入，前后数据流相互关联。过滤器是构件，连接件是管道。典型的例子包括文本处理管道，在文本分析中，可以将文本处理划分为分词、词干提取、情感分析等多个阶段，每个阶段都是一个过滤器。早期编译器也采用这种架构，需要一步一步处理。

区别：

批处理序列：通常一次性处理大量数据，离线执行，适用于批量处理任务。例如，批量图像处理。
管道-过滤器：将任务分解为多个阶段，每个阶段逐个处理数据，通常是实时或近实时执行，适用于可组合和可扩展的任务。例如，文本处理管道。

调用/返回风格

构件之间存在互相调用的关系，一般是显式的调用。

主程序/子程序

在这种架构中，系统按照单线程控制的方式，将问题划分为若干个处理步骤。构件包括主程序和子程序，且子程序通常可以合成为模块。过程调用作为交互机制，充当连接件的角色。主要特点是通过调用来实现各处理步骤的顺序执行和数据传递。

面向对象

在面向对象的架构中，构件是对象。对象是抽象数据类型的实例，连接件即是对象间交互的方式。对象通过函数和过程的调用来进行交互。这种方法强调数据封装、继承和多态性，通过对象之间的消息传递实现系统功能。

层次结构

层次结构架构将系统构件分组成一个层次结构。连接件通过定义层间交互的协议来决定层间的互动。每层为上一层提供服务，并使用下一层的服务，只能看到与自己邻接的层。修改某一层最多影响相邻的两层（通常只能影响上层）。其优点是可以将一个复杂问题分解为一个增量步骤序列来实现，但缺点是并不是每个系统都可以轻易划分为分层模式，并且层次调用会影响效率。

客户端服务器 (C/S)

早期的两层C/S架构模式由三个部分组成：数据库服务器、客户端服务器和网络。服务器负责数据管理，客户端完成用户交互，称之为“胖客户端、瘦服务器”。后来，演变为三层C/S架构，增加了一个应用服务器，分别是表示层、功能层和数据层。表示层负责用户交互，功能层负责业务逻辑处理，数据层负责数据库处理。以上三层独立，互不干扰。

独立构件风格

构件之间是互相独立的，不存在显式的调用关系，而是通过某个事件触发、异步的方式来执行。

进程通信

定义：构件：独立的进程、连接件：消息传递

特性：

构件通常是命名的过程。
消息传递的方式可以是点对点、异步或同步方式，以及远程过程（方法）调用等。
涉及不同进程或线程之间的通信和数据共享。
这些进程可以运行在同一台计算机上，也可以分布在不同的计算机上。

事件驱动系统（隐式调用）

定义：

构件不直接调用一个过程，而是触发或广播一个或多个事件。
构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。

优点：

为软件复用提供了强大的支持。
为构件的维护和演化带来了方便。

缺点：

构件放弃了对系统计算的控制，只能被动地控制。

虚拟机风格

自定义了一套规则供使用者使用，使用者基于这个规则来开发构件，能够跨平台适配。解释器、基于规则的系统

解释器

组成部分：

解释引擎：完成解释工作的核心组件。
代码存储区：包含将被解释的代码。
工作状态数据结构：记录解释引擎当前的工作状态。
进度数据结构：记录源代码的解释执行进度。

功能：

解析和执行一系列指令或命令。
将文本或代码解析成可执行的操作。

缺点：

执行效率较低。

基于规则的系统

组成部分：

规则集：预定义的一组规则或条件。
规则解释器：解析和执行规则的组件。
规则/数据选择器：选择适用的规则或数据。
工作内存：存储当前工作的状态和数据。

应用领域：人工智能领域、决策支持系统（DSS）。

功能：

根据一组事先定义的规则或条件来控制系统的行为。
实现灵活的业务规则和决策逻辑。

数据为中心系统

以数据为中心风格以数据为中心，所有的操作都是围绕建立的数据中心进行的。

仓库风格的架构

定义：

将数据存储在一个中央仓库或数据库中。
各个组件可以从仓库中读取和写入数据。
组件之间通过共享数据仓库进行通信和协作。

黑板风格的架构

定义：

类似于一个黑板或公告板，多个独立的组件称为“专家”共享一个公共存储区（黑板）。
专家可以读取和写入数据。
专家根据黑板上的信息进行推断和决策，适用于解决复杂的非结构化问题。

比较总结：

仓库风格：强调数据的集中存储和共享，组件通过访问共享的仓库来交互。
黑板风格：侧重于多个独立的组件共享一个中央知识存储区，根据共享的信息进行推断和决策。

闭环过程控制

闭环控制：当软件被用来操作一个物理系统时，软件与硬件之间可以粗略的表示为一个反馈循环，这个反馈循环通过接受一定的输入，确定一系列的输出，最终使环境达到一个新的状态，适合于嵌入式系统，涉及连续的动作与状态。比如开空调，不会一调到某个温度就马上能到该温度，是逐渐接收室内的温度来变化输出空调的冷气。

C2风格

C2体系结构风格可以概括为：通过连接件绑定在一起的按照一组规则运作的并行构件网络。

C2风格中的系统组织规则如下：

系统中的构件和连接件都有一个顶部和一个底部；
构件的顶部应连接到某连接件的底部，构件的底部则应连接到某连接件的顶部，而构件与构件之间的直接连接是不
允许的；
一个连接件可以和任意数目的其它构件和连接件连接；
当两个连接件进行直接连接时，必须由其中一个的底部到另一个的顶部。

软件架构复用

软件产品线

软件产品线是指一组软件密集型系统，它们共享一个公共的、可管理的特性集，满足某个特定市场或任务的具体需要，以规定的方式用公共的核心资产集成开发出来的。即围绕核心资产库进行管理、复用、集成新的系统。

软件架构复用

机会复用：在开发过程中，只要发现有可复用的资产，就对其进行复用。
系统复用：在开发之前进行规划，以决定哪些需要复用。

可复用的资产包括以下内容：

需求：可重复使用的需求文档或需求规范。
架构设计：可重复使用的系统架构或设计模式。
元素：代码模块、库或组件。
建模与分析：模型、分析工具和方法。
测试：测试用例、测试脚本和测试环境。
项目规划：项目计划、时间表和资源分配。
过程方法和工具：开发过程、方法论和支持工具。
人员：具备特定技能和经验的开发人员。
样本系统：过去开发的原型或样本系统。
缺陷消除：已识别和修复的缺陷及其对应的解决方案。

复用的基本过程

复用的基本过程主要包括以下三个阶段：

构造/获取可复用的软件资产：创建或获取可复用的代码、设计文档、测试用例等。
管理这些资产：将这些资产放入到构件库中进行管理，以便组织和检索。
选择和复用：针对特定需求，从构件库中选择可复用的部分，以开发满足需求的应用系统。

层次架构风格

两层C/S架构：客户端和服务器都有处理功能，现在已经不常用，原因有：开发成本较高、客户端程序设计复杂、信息内容和形式单一、用户界面风格不一、软件移植困难、软件维护和升级困难、新技术不能复制易应用、安全性问题、服务器端压力大难以复用。

三层C/S架构：将处理功能独立出来，表示层和数据层都变得简单。表示层在客户机上，功能层在应用服务器上，数据层在数库务器上。即将两层C/S架构中的数据从服务器中独立出来了。其优点下面四点：

各层在逻辑上保持相对独立，整个系统的逻辑结构更为清晰，能提高系统和软件的可维护性和可扩展性；
允许灵活有效的选用相应的平台和硬件系统，具有良好的可升级性和开放性；
各层可以并行开发，各层也可以选择各自最适合的开发语言；
功能层有效的隔离表示层与数据层，为严格的安全管理奠定了坚实的基础，整个系统的管理层次也更加合理和可控制。

三层C/S架构设计的关键在于各层之间的通信效率，要慎重考虑三层间的通信方法、通信频度和数据量，否则即使分配给各层的硬件能力很强，性能也不高。

三层B/S架构：是三层C/S架构的变种，将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构，虽然不用开发客户端，但有很多缺点：

使用浏览器作为客户端的话安全性难以控制；
在数据查询等响应速度上，要远远低于C/S架构，因为C/S架构有部分数据储在本地；
数据提交一般以页面为单位，数据的动态交互性不强。

混合架构风格：

内外有别模型：企业内部使用C/S，外部人员访问使用B/S。
查改有别模型：采用B/S查询，采用C/S修改。
混合架构实现困难，且成本高。

富互联网应用RIA：弥补三层B/S架构存在的问题，RIA是一种用户接口，比用HTML实现的接口更加健壮，且有可视化内容，本质还是网站模式，其优点如下：

RIA结合了C/S架构反应速度快、交互性强的优点与B/S架构传播范围广及容易传播的特性；
RIA简化并改进了B/S架构的用户交互；
数据能够被缓存在客户端，从而可以实现一个比基于HTML的响应速度更快且数据往返于服务器的次数更少的用户界面。
本质还是0客户端，借助于高速网速实现必要插件在本地的快速缓存，增强页面对动态页面的支持能力，典型的如小程序。

MVC架构

控制器（Controller)：是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

模型（Model)：是应用程序用于处理应用程序数据逻辑部分。通常模型对象负责在数据库中存取数据。模型表示业务数据和业务逻辑。

视图（View)：是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。是用户看到并与之交互的界面。视图向用户显示相关的数据，并能接收用户的输入数据，但是它并不进行在何实际的业务处理：

MVP架构

MVP（Model-View-Presenter）架构模式是MVC（Model-View-Controller）架构的一种变体，将MVC中的Controller替换为Presenter（呈现器）。其目的是为了完全切断View（视图）与Model（模型）之间的联系，由Presenter充当桥梁，实现View和Model之间通信的完全隔离。

MVP特点：

双向通信：

M（Model）、V（View）、P（Presenter）之间是双向通信。

Presenter作为桥梁：

View与Model不直接通信，所有通信都通过Presenter进行。
Presenter完全把Model和View分离开，主要的程序逻辑在Presenter中实现。

被动视图（Passive View）

View非常薄，不包含任何业务逻辑，被称为“被动视图”，即没有主动性。
Presenter非常厚，所有的逻辑都在Presenter中实现。

接口交互

Presenter与具体的View没有直接关联，而是通过定义好的接口进行交互。
这种设计使得在变更View时，可以保持Presenter的不变，从而实现重用。

MVVM架构

MVVM:MVVM模式和MVC模式类似，主要目的是分离视图（View）和模型（Model)，实现双向绑定，有几大优点：

低耦合，视图（View）可以独立于Model变化和修改，一个ViewModel可以绑定到不同的"View"上，当View变化的时
候Model可以不变，当Model变化的时候View也可以不变。
可重用性，可以把一些视图逻辑放在一个ViewModel里面，让很多view重用这段视图逻辑。
独立开发，开发人员可以专注于业务逻辑和数据的开发（ViewModel)，设计人员可以专注于页面设计。
可测试，界面向来是比较难于测试的，而现在测试可以针对ViewModel来写。