分布式架构


在分布式架构中,组件呈现在不同的平台上,并且多个组件可以通过通信网络相互协作,以实现特定的目的或目标。

  • 在这种架构中,信息处理并不局限于一台机器,而是分布在几台独立的计算机上。

  • 分布式系统可以通过客户端-服务器架构来演示,该架构构成了多层架构的基础;替代方案是代理架构(例如 CORBA)和面向服务的架构(SOA)。

  • 有多种技术框架支持分布式架构,包括.NET、J2EE、CORBA、.NET Web 服务、AXIS Java Web 服务和 Globus Grid 服务。

  • 中间件是适当支持分布式应用程序的开发和执行的基础设施。它在应用程序和网络之间提供缓冲区。

  • 它位于系统的中间,管理或支持分布式系统的不同组件。例如事务处理监视器、数据转换器和通信控制器等。

中间件作为分布式系统的基础设施

概念分布式架构

分布式架构的基础是其透明性、可靠性和可用性。

下表列出了分布式系统中不同形式的透明度 -

先生。 透明度和描述
1

使用权

隐藏了资源的访问方式和数据平台的差异。

2

地点

隐藏资源所在位置。

3

技术

对用户隐藏不同的技术,例如编程语言和操作系统。

4

迁移/搬迁

隐藏可能被移动到另一个正在使用的位置的资源。

5

复制

隐藏可以在多个位置复制的资源。

6

并发性

隐藏可能与其他用户共享的资源。

7

失败

对用户隐藏资源的故障和恢复。

8

坚持

隐藏资源(软件)是在内存还是磁盘中。

优点

  • 资源共享- 硬件和软件资源共享。

  • 开放性- 灵活使用不同供应商的硬件和软件。

  • 并发- 并发处理以提高性能。

  • 可扩展性- 通过添加新资源来提高吞吐量。

  • 容错能力- 发生故障后继续运行的能力。

缺点

  • 复杂性- 它们比集中式系统更复杂。

  • 安全性- 更容易受到外部攻击。

  • 可管理性- 系统管理需要更多努力。

  • 不可预测性- 不可预测的响应取决于系统组织和网络负载。

集中式系统与分布式系统

标准 集中式系统 分布式系统
经济学 低的 高的
可用性 低的 高的
复杂 低的 高的
一致性 简单的 高的
可扩展性 贫穷的 好的
技术 同质 异质
安全 高的 低的

客户端-服务器架构

客户端-服务器架构是最常见的分布式系统架构,它将系统分解为两个主要子系统或逻辑进程 -

  • 客户端- 这是向第二个进程(即服务器)发出请求的第一个进程。

  • 服务器- 这是接收请求、执行请求并向客户端发送回复的第二个进程。

在此体系结构中,应用程序被建模为由服务器和使用这些服务的一组客户端提供的一组服务。服务器不需要知道客户端,但客户端必须知道服务器的身份,并且处理器到进程的映射不一定是 1:1

两层客户端服务器架构

根据客户端的功能,客户端-服务器架构可以分为两种模型 -

瘦客户端模型

在瘦客户端模型中,所有的应用程序处理和数据管理都由服务器承担。客户端只负责运行演示软件。

  • 当遗留系统迁移到客户端服务器架构时使用,其中遗留系统本身充当服务器,并在客户端上实现图形界面

  • 一个主要缺点是它会给服务器和网络带来沉重的处理负载。

厚客户端模型

在胖客户端模型中,服务器只负责数据管理。客户端软件实现应用逻辑以及与系统用户的交互。

  • 最适合预先知道客户端系统功能的新型 C/S 系统

  • 比瘦客户端模型更复杂,尤其是对于管理而言。必须在所有客户端上安装该应用程序的新版本。

厚客户端模型

优点

  • 用户界面呈现和业务逻辑处理等职责分离。

  • 服务器组件的可重用性和并发潜力

  • 简化分布式应用程序的设计和开发

  • 它可以轻松地将现有应用程序迁移或集成到分布式环境中。

  • 当大量客户端访问高性能服务器时,它还能有效地利用资源。

缺点

  • 缺乏异构基础设施来应对需求变化。

  • 安全问题。

  • 服务器可用性和可靠性有限。

  • 可测试性和可扩展性有限。

  • 胖客户端将演示和业务逻辑结合在一起。

多层架构(n层架构)

多层体系结构是一种客户端-服务器体系结构,其中表示、应用程序处理和数据管理等功能在物理上是分离的。通过将应用程序分为多个层,开发人员可以选择更改或添加特定层,而不是重新设计整个应用程序。它提供了一个模型,开发人员可以通过该模型创建灵活且可重用的应用程序。

N 层架构

多层架构最常用的是三层架构。三层架构通常由表示层、应用层和数据存储层组成,并且可以在单独的处理器上执行。

表示层

表示层是应用程序的最顶层,用户可以通过它直接访问,例如网页或操作系统GUI(图形用户界面)。该层的主要功能是将任务和结果转换为用户可以理解的内容。它与其他层进行通信,以便将结果发送到浏览器/客户端层以及网络中的所有其他层。

应用层(业务逻辑、逻辑层或中间层)

应用程序层协调应用程序、处理命令、做出逻辑决策、评估并执行计算。它通过执行详细处理来控制应用程序的功能。它还在两个周围层之间移动和处理数据。

数据层

在这一层中,信息从数据库或文件系统中存储和检索。然后信息被传回进行处理,然后返回给用户。它包括数据持久性机制(数据库服务器、文件共享等),并向应用层提供 API(应用程序编程接口),应用层提供管理存储数据的方法。

数据层

优点

  • 比瘦客户端方法性能更好,并且比胖客户端方法更易于管理。

  • 增强可重用性和可扩展性——随着需求的增加,可以添加额外的服务器。

  • 提供多线程支持并减少网络流量。

  • 提供可维护性和灵活性

缺点

  • 由于缺乏测试工具,可测试性不理想。

  • 更关键的是服务器的可靠性和可用性。

经纪商架构风格

Broker 架构风格是一种用于分布式计算的中间件架构,用于协调和启用注册服务器和客户端之间的通信。这里,对象通信是通过称为对象请求代理(软件总线)的中间件系统进行的。

  • 客户端和服务器不直接交互。客户端和服务器与其代理直接连接,该代理与中介代理进行通信。

  • 服务器通过向代理注册和发布其接口来提供服务,客户端可以通过查找静态或动态地向代理请求服务。

  • CORBA(通用对象请求代理架构)是代理架构的一个很好的实现示例。

Broker 架构风格的组成部分

经纪人架构风格的组成部分通过以下部分进行讨论 -

经纪人

Broker负责协调通信,例如转发和分派结果和异常。它可以是面向调用的服务、客户端向其发送消息的文档或面向消息的代理。

  • 它负责代理服务请求、定位适当的服务器、传输请求并将响应发送回客户端。

  • 它保留服务器的注册信息,包括其功能和服务以及位置信息。

  • 它提供API供客户端请求、服务器响应、注册或取消注册服务器组件、传输消息以及定位服务器。

存根

存根在静态编译时生成,然后部署到客户端,作为客户端的代理。客户端代理充当客户和经纪商之间的中介,并在他们和客户之间提供额外的透明度;远程对象看起来就像本地对象。

代理在协议级别隐藏 IPC(进程间通信),并执行参数值的编组和来自服务器的结果的解组。

骨骼

通过服务接口编译生成Skeleton,然后部署到服务器端,作为服务器的代理。服务器端代理封装低级系统特定的网络功能,并提供高级 API 在服务器和代理之间进行中介。

它接收请求,解包请求,解组方法参数,调用合适的服务,并在将结果发送回客户端之前对其进行编组。

网桥可以连接两个基于不同通信协议的不同网络。它协调不同的代理,包括 DCOM、.NET 远程和 Java CORBA 代理。

桥是可选组件,当两个代理互操作并以一种格式获取请求和参数并将其转换为另一种格式时,它会隐藏实现细节。

经纪商模式

CORBA 中的代理实现

CORBA 是对象请求代理的国际标准,对象请求代理是管理 OMG(对象管理组)定义的分布式对象之间通信的中间件。

CORBA架构

面向服务的架构(SOA)

服务是业务功能的一个组件,它是定义明确的、自包含的、独立的、已发布的并且可通过标准编程接口使用。服务之间的连接是通过通用的、通用的面向消息的协议(例如SOAP Web服务协议)进行的,它可以松散地传递服务之间的请求和响应。

面向服务的体系结构是一种客户端/服务器设计,支持业务驱动的 IT 方法,其中应用程序由软件服务和软件服务消费者(也称为客户端或服务请求者)组成。

面向服务架构

SOA的特点

面向服务的架构提供以下功能 -

  • 分布式部署- 将企业数据和业务逻辑公开为松散、耦合、可发现、结构化、基于标准、粗粒度、无状态的功能单元,称为服务。

  • 可组合性- 从现有服务中组装新流程,通过明确定义、发布和标准的投诉接口以所需的粒度公开。

  • 互操作性- 在网络中共享功能并重用共享服务,无论底层协议或实现技术如何。

  • 可重用性- 选择服务提供商并访问作为服务公开的现有资源。

面向服务架构运营

下图说明了 SOA 是如何运作的 -

SOA运营

优点

  • 面向服务的松耦合为企业提供了极大的灵活性,可以不受平台和技术的限制,利用所有可用的服务资源。

  • 由于无状态服务特性,每个服务组件都独立于其他服务。

  • 只要不改变暴露的接口,服务的实现就不会影响该服务的应用。

  • 客户端或任何服务都可以访问其他服务,无论其平台、技术、供应商或语言实现如何。

  • 资产和服务的可重用性,因为服务的客户端只需要知道其公共接口、服务组合。

  • 基于 SOA 的业务应用程序开发在时间和成本方面更加高效。

  • 增强可扩展性并提供系统之间的标准连接。

  • 高效且有效地使用“商业服务”。

  • 集成变得更加容易,并且提高了内在的互操作性。

  • 为开发人员抽象复杂性,并使业务流程更加贴近最终用户。