分布式架构

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

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

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

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

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

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

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

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

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

优点

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

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

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

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

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

缺点

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

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

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

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

集中式系统与分布式系统

客户端-服务器架构

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

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

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

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

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

瘦客户端模型

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

• 用于将旧系统迁移到客户端服务器架构，其中旧系统本身充当服务器，并在客户端上实现图形界面

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

厚/胖客户端模型

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

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

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

优点

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

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

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

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

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

缺点

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

• 安全问题。

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

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

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

多层架构（n 层架构）

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

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

表示层

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

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

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

数据层

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

优点

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

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

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

• 提供可维护性和灵活性

缺点

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

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

代理架构风格

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

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

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

• CORBA（通用对象请求代理体系结构）是代理体系结构的一个很好的实现示例。

代理体系结构样式的组件

通过以下标题讨论代理体系结构样式的组件−

代理

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

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

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

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

存根

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

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

Skeleton

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

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

桥接

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

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

CORBA 中的代理实现

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

面向服务的架构 (SOA)

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

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

SOA 的功能

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

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

• 可组合性 − 通过定义明确、已发布且符合标准的接口，从以所需粒度公开的现有服务中组装新流程。

• 互操作性 − 跨网络共享功能并重用共享服务，而不管底层协议或实施技术如何。

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

SOA 操作

下图说明了 SOA 如何操作 −

优势

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

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

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

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

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

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

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

• 高效、有效地使用"业务服务"。

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

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