分层架构

分层架构将整个系统视为一个层次结构,其中软件系统被分解为层次结构中不同级别的逻辑模块或子系统。这种方法通常用于设计系统软件,例如网络协议和操作系统。

在系统软件层次结构设计中,低级子系统为其相邻的上级子系统提供服务,这些子系统调用下级中的方法。下层提供更具体的功能,例如 I/O 服务、事务、调度、安全服务等。中间层提供更多领域相关功能,例如业务逻辑和核心处理服务。而上层则以用户界面的形式提供更抽象的功能,例如 GUI、shell 编程工具等。

它还用于在命名空间层次结构中组织类库,例如 .NET 类库。所有设计类型都可以实现这种分层架构,并且经常与其他架构风格相结合。

分层架构风格分为 −

  • 主-子程序
  • 主-从
  • 虚拟机

主-子程序

这种风格的目的是重用模块并自由开发单个模块或子程序。在这种风格中,软件系统根据系统所需的功能,通过自上而下的细化被划分为子程序。

这些细化垂直引导,直到分解后的模块足够简单,可以拥有其独有的独立职责。功能可以被上层的多个调用者重用和共享。

数据作为参数传递给子程序有两种方式,即 −

  • 按值传递 − 子程序仅使用过去的数据,但不能修改它。

  • 按引用传递 −子程序使用并更改参数引用的数据的值。

Main-subroutine

优点

  • 易于根据层次细化分解系统。

  • 可用于面向对象设计的子系统。

缺点

  • 由于包含全局共享数据,因此存在漏洞。

  • 紧密耦合可能会导致更多变化的连锁反应。

主从

此方法应用"分而治之"原则,支持故障计算和计算准确性。它是对主子程序架构的修改,可提供系统可靠性和容错能力。

在此架构中,从属程序为主程序提供重复服务,主程序通过某种选择策略在从属程序中选择特定结果。从属程序可能通过不同的算法和方法或完全不同的功能执行相同的功能任务。它包括并行计算,其中所有从属都可以并行执行。

Master-Slave

主从模式的实现遵循五个步骤 −

  • 指定如何将任务的计算划分为一组相等的子任务,并确定处理子任务所需的子服务。

  • 指定如何借助处理各个子任务获得的结果来计算整个服务的最终结果。

  • 为步骤 1 中确定的子服务定义一个接口。它将由从属实现,并由主服务器用于委托处理各个子任务。

  • 根据上一步中制定的规范实现从属组件步骤。

  • 根据步骤 1 至 3 中制定的规范实现主服务器。

应用

  • 适用于软件可靠性至关重要的应用。

  • 广泛应用于并行和分布式计算领域。

优点

  • 计算速度更快,易于扩展。

  • 由于从服务器可以复制,因此具有稳定性。

  • 从服务器可以以不同的方式实现,以最大限度地减少语义错误。

缺点

  • 通信开销。

  • 并非所有问题都可以划分。

  • 难以实现和可移植性问题。

虚拟机架构

虚拟机架构假装某些功能,这些功能不是其实现的硬件和/或软件所固有的。虚拟机建立在现有系统之上,并提供虚拟抽象、一组属性和操作。

在虚拟机架构中,主服务器使用来自从服务器的"相同"子服务,并执行拆分工作、调用从服务器和合并结果等功能。它允许开发人员模拟和测试尚未构建的平台,并模拟"灾难"模式,这些模式过于复杂、成本高昂或危险,无法用实际系统进行测试。

在大多数情况下,虚拟机将编程语言或应用程序环境与执行平台分开。主要目标是提供可移植性。通过虚拟机解释特定模块可能被视为−

  • 解释引擎从正在解释的模块中选择一条指令。

  • 根据指令,引擎更新虚拟机的内部状态并重复上述过程。

下图显示了单个物理机上标准 VM 基础架构的架构。

虚拟机架构

虚拟机管理程序,也称为虚拟机监视器,在主机操作系统上运行,并为每个客户操作系统分配匹配的资源。当客户操作系统发出系统调用时,虚拟机管理程序会拦截并将其转换为主机操作系统支持的相应系统调用。虚拟机管理程序控制每个虚拟机对 CPU、内存、持久存储、I/O 设备和网络的访问。

应用

虚拟机架构适用于以下领域 −

  • 适用于在没有直接解决方案的情况下通过模拟或翻译解决问题。

  • 示例应用包括微编程解释器、XML 处理、脚本命令语言执行、基于规则的系统执行、Smalltalk 和 Java 解释器类型编程语言。

  • 虚拟机的常见示例是解释器、基于规则的系统、语法 shell 和命令语言处理器。

优点

  • 可移植性和机器平台独立性。

  • 软件开发简单。

  • 通过中断和查询程序的能力提供灵活性。

  • 模拟灾难工作模型。

  • 在运行时。

缺点

  • 由于解释器的特性,解释器的执行速度很慢。

  • 由于执行过程中涉及额外的计算,因此存在性能成本。

分层样式

在这种方法中,系统被分解为层次结构中的多个较高和较低的层,并且每个层在系统中都有自己的唯一职责。

  • 每个层都由一组相关类组成,这些类封装在包中、部署的组件中,或作为方法库或头文件格式的一组子例程。

  • 每个层都为其上层提供服务,并作为下层的客户端,即对第 i +1 层的请求将通过接口调用第 i 层提供的服务层 i。如果任务完成,响应可能会返回到层 i +1;否则,层 i 会继续调用下面层 i -1 的服务。

应用

分层样式适用于以下领域 −

  • 涉及可分层组织的不同服务类别的应用程序。

  • 任何可分解为特定于应用程序和特定于平台的部分的应用程序。

  • 在核心服务、关键服务和用户界面服务等之间有明确划分的应用程序。

优点

  • 基于增量抽象级别的设计。

  • 提供增强独立性,因为对一个层的功能的更改最多会影响其他两个层。

  • 标准接口与其实现的分离。

  • 使用基于组件的技术实现,使系统更容易实现新组件的即插即用。

  • 每个层都可以是一个独立部署的抽象机器,支持可移植性。

  • 根据任务定义以自上而下的细化方式轻松分解系统

  • 同一层的不同实现(具有相同的接口)可以互换使用

缺点

  • 许多应用程序或系统不易以分层方式构建。

  • 运行时性能较低,因为客户端的请求或对客户端的响应必须经过潜在的多层。

  • 每个层的数据编组和缓冲开销也存在性能问题。

  • 打开层间通信可能导致死锁,"桥接"可能导致紧密耦合。

  • 异常和错误处理是分层架构中的一个问题,因为一层中的故障必须向上传播到所有调用层