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

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

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

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

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

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

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

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

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

优势

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

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

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

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

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

缺点

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

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

• 可管理性 - 系统管理需要更多的工作。

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

集中式系统与分布式系统

客户端-服务器体系结构

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

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

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

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

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

瘦客户端模型

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

• 当旧系统迁移到客户端服务器体系结构时使用，在该体系结构中，旧系统本身充当服务器，并在客户端上实现图形界面

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

胖客户端模型

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

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

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

优势

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

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

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

• 它使将现有应用程序迁移或集成到分布式环境中变得容易。

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

缺点

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

• 安全复杂功能。

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

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

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

多层体系结构（n-tier 体系结构）

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

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

表示层

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

应用层（业务逻辑层、逻辑层或中间层）

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

数据层

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

优势

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

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

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

• 提供可维护性和灵活性

缺点

• 由于缺乏测试工具，可测试性不令人满意。

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

Broker 架构风格

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

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

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

• CORBA（Common Object Request Broker Architecture）是代理架构的一个很好的实现示例。

Broker 架构样式的组件

代理架构风格的组成部分通过以下标题进行讨论 -

代理

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

• 它负责代理服务请求、找到适当的服务器、传输请求以及将响应发送回客户端。

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

• 它为客户端请求、服务器响应、注册或注销服务器组件、传输消息和查找服务器提供 API。

存根

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

代理在协议级别隐藏 IPC（进程间通信），并执行参数值的封送处理和来自服务器的结果的取消封送。

骨架

骨架由服务接口编译生成，然后部署到服务器端，作为服务器端的代理。服务器端代理封装了低级系统特定的网络功能，并提供高级 API 来调解服务器和代理。

它接收请求，解压缩请求，取消封送方法参数，调用合适的服务，并在将结果发送回客户端之前封送结果。

桥

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

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

CORBA 中的代理实现

CORBA 是对象请求代理的国际标准，对象请求代理是一种中间件，用于管理 OMG（对象管理组）定义的分布式对象之间的通信。

面向服务的体系结构 （SOA）

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

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

SOA 的特性

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

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

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

• 互操作性 - 在网络中共享功能并重用共享服务，而不考虑底层协议或实现技术。

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

SOA 操作

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

优势

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

• 由于无状态服务功能，每个服务组件都独立于其他服务。

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

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

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

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

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

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

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

• 为开发人员简化复杂性，并激发更接近最终用户的业务流程。