在当今的互联世界中，越来越多的企业应用程序跨多个服务器分布和运行、连接到远程数据源和 Web Service，并可通过 Internet 访问。分布式计算功能强大，但也并非没有面临挑战。网络在本质上并不可靠，同本地的进程间通信相比，与远程服务器的通信速度较慢。另外，同时在多台计算机 上运行一个程序可能会导致许多并发和同步问题。
按照 Business Component Factory（业务组件工厂）的说，分布式计算可以基于两个截然不同的体系结构样式：
基于实例的协作基于服务的协作基于实例的协作跨网络边界扩展了面向对象的计算模型。组件可以实例化远程对象实例、四处传递对这些远程对象的引用、调用远程对象的方法以及取消对它们的分配。此方法的优点在于，可以将应用程序内使用的同一个面向对象的编程模型应用于分布式组件。大多数运行时平台都包含对基于实例的协作的支持，以便开发人员 在访问远程对象时不必提供特殊内容，或者相对于访问本地对象，只需提供极少的特殊内容。这就大大简化了分布式解决方案的开发，通常会简化到如下程度：以前位于相同位置的对象可以在部署时进行分布，而无需对应用程序进行任何代码更改。基于实例的协作还使远程对象的使用者能够更加精细地控制远程对象的生存期， 从而让用户更有效地使用远程资源。
但是，基于实例的协作在带来易用性的同时，还因复杂的交互模型以及用户和提供商之间的紧密联系而导致成本增加。基于实例的交互要求远程对象的特定实例可以通过网络找到，这将复杂的生存期和实例管理引入了通信协议中。因此，大多数支持基于实例的协作的平台都 不提供与其他平台的互操作性。
基于服务的协作通过只向潜在使用者公开“类似于管理器”或“类似于协调器”的接口来解决其中的一些挑战。用户可以调用该接口上的方法，但是他们不能控制任何远程对象的生存期。这大大简化了交互，并允许使用支持跨平台互操作的标准协议。
但是，基于服务的协作不能为本地对象和远程对象提供使用面向对象的编程模型时所具备的连续性。这意味着您必须明确跟踪对象之间的会话状态，而在使用基于实例的协作时就不必担心这些。同样，尽管基于标准的协议改善了互操作性，但是它们要求应用程序将应用程序内部数据类型转换成每个通信终端都能够理解的通用格式，而这可能涉及其他转换逻辑。
考虑分布式系统的另一种方式就是将每个系统视为通过链接连在一起的处理节点的集合。这些节点代表实际的服务器计算机，而链接代表将这些计算机连在一起的网络。系统内的链接分成两类：近链接或远链接。
近 链接驻留在同一个信任区域中、同一个企业内，它们以可靠方式连接而且不涉及互操作性。远链接包括所有其他链接（包括跨越 Internet 的任何链接）。 如果您的分布式系统仅跨越近链接，则最好使用基于实例的协作。使用基于实例的协作，可以跨计算机边界扩展面向对象的开发能力，同时利用平台的基础结构来优 化速度、导航类型系统并为您操作封送处理细节。此处的技术选项将包括 Microsoft? .NET Framework 中的 .NET Remoting 和 Enterprise Services。
另一方面，如果您的分布式系统跨越远链接，则基于服务的协作通常是较好 的选择。如果与提供“类似于协调器”的接口的服务进行交互，则允许该服务负责实现，而不必让服务用户了解实现细节。服务接口通常返回消息，这比远程过程调 用提供的耦合性要少。最好的消息是那些既包含头信息又包括正文的消息，这允许接收者针对收到的消息自发执行操作。此处的技术选项包括诸如 Web Services 这样的功能。
本章的其余部分将描述通常与基于实例的协作和近链接相关联的模式。第 6 章“服务模式”将进一步介绍通常与基于服务的协作和远链接相关联的模式。
分布式体系结构的核心是能够调用对象上的方法或者与驻留在不同进程中甚至有可能在不同计算机上的服务进行通信。看起来这似乎不难，但是您必须解决非常多的问题：
如何实例化远程对象？如果您希望调用现有对象上的方法，那么如何获取对该对象的引用？网络协议仅传输字节流，而不传输对象。如何才能通过字节流调用方法？安全性如何？是否每个人都能够调用远程对象上的方法？大多数网络在本质上都不可靠。如果无法访问远程对象，会出现什么情况？如果远程对象收到方法调用，但是因网络问题而无法发送响应，该怎么办？调用远程对象比调用本地方法慢得多。您是否希望异步调用远程方法，以便在远程对象处理请求的同时可以继续在本地处理？问 题不胜枚举。幸运的是，.NET Framework 中的功能解决了其中的大多数问题，使得开发人员在创建分布式应用程序时不必处理太多的细枝末节。这些功能使得远程调用对于程序员几乎是透明的（至少在句法 级别是如此）。但是，这种简化可能存在一定的欺骗性，因为开发人员还必须了解远程通信的一些基本原理，才能写出强大而高效的分布式应用程序。分布式系统模 式群集有助于开发人员在实现分布式应用程序时作出明智的设计决策。
为分布式系统创建易用的基础结构的秘诀是Layered Application 。分布式服务层依赖较低层（如 TCP/IP 堆栈和套接字通信层），但是较低层的细节不会显示在包含应用程序和业务逻辑层的较高层中。这种安排使得应用程序开发人员在较高抽象级别工作时不必考虑诸如 TCP/IP 数据包和网络字节排序之类的细节。它还可以在替换较低层时不对较高层造成任何影响。例如，您不必在应用程序层更改代码，即可切换到另一个传输协议（例如， 使用 HTTP 代替直接使用 TCP/IP）。
便于开发人员进行远程调用的一种方法就是使用 Proxy（代理）[Gamma95]。代理是与客户端对象通信的本地替身。当客户端创建远程对象的实例时，基础结构就会创建一个代理对象，该对象在客户 端看来与远程类型完全相同。当客户端调用该代理对象上的方法时，该代理就会调用远程处理基础结构。远程处理基础结构将请求路由到服务器进程，然后调用服务 器对象，并将结果返回给客户端代理，最后客户端代理将结果传递给客户端对象。由于所有这些操作都是在后台进行的，因此客户端对象可能完全不知道另一个对象 驻留在其他计算机上。这不仅方便了分布式应用程序的开发，而且还允许您在程序开发出来之后再分布对象，而只需对应用程序代码进行很小的改动。
分布式系统模式群集强调两个主要概念：远程调用和粗粒度接口。
图 1 分布式系统群集中的模式
远程调用
Broker （代理程序）模式描述如何查找远程对象并调用它的一个方法，而不会将通过网络进行通信的复杂性引入应用程序。此模式为大多数分布式体系结构（包括 .NET Remoting）奠定了基础。
.NET Framework 的指导原则之一就是简化复杂的编程任务，同时不会夺走程序员的控制权。按照该原则，.NET Remoting 提供了大量远程处理模型供开发人员选择，如下面的段落所述。
本地副本
最简单的远程处理模型涉及到按值将对象的副本传递给客户端。以后针对该对象进行的所有方法调用都是真正的本地调用。此模型避免了分布式计算中固有的许多复杂 性，但同时也存在许多缺点。首先，由于您是在自己的进程空间中运行对象的本地副本，因此计算不是真正的分布式计算。其次，由于对对象状态进行的所有更新仅发生在本地，因此它们会丢失。最后，由于对象需要远程资源或者远程对象的提供商希望保护对其内部资源的访问，因此对象通常是远程的。将对象实例复制到本地 进程不仅无法实现这两个目标，而且还会增加因通过远程通道传送整个对象而带来的开销。由于存在上述限制，因此本章仅讨论对象复制的唯一应用：Data Transfer Object （数据传输对象）模式。
服务器激活的对象
与使用远程对象的本地副本相比，直接调用远程对象上的方法是更好的选择。但是，只有当您拥有对远程对象的引用时，才能调用其上的方法。获取对远程对象的引用 要求首先实例化该对象。客户端要求服务器提供该对象的实例，然后服务器返回对远程实例的引用。如果远程对象可被视为服务，则上述过程可以顺畅地工作。例 如，假设有一个用来验证信用卡号的服务。客户端对象提交一个信用卡号并收到一个正的或负的响应，具体情况取决于客户的消费（和偿还）习惯。在本例中，您并 不真正关心远程对象的实例。您只管提交某些数据、接收结果并继续操作。这是“无状态服务”的一个很好的例子。在无状态服务中，每个请求都会使对象继续保持 此前所处的状态。
但是，并非所有远程对象协作都遵循此模型。有时，您希望调用远程对象，以便检索某些可在以后进行远程调用时访问的数据。 您必须确保在随后的调用过程中调用的是同一个对象实例。而且，当您检查完数据后，您将希望取消对该对象的分配以节省服务器内存。利用服务器激活的对象，无 法对对象实例实现这种级别的控制。服务器激活的对象为实例生存期管理仅提供两个替换选项：
针对每次调用创建对象的新实例。对于所有客户端仅使用远程对象的单个实例（使该对象有效地成为 Singleton)。如果您希望通过几次功能调用来访问同一远程实例，然后将其扔到垃圾回收器中，则上述任一选项都不合适。
客户端激活的对象
客户端激活的对象使 客户端能够控制远程对象的生存期。客户端几乎可以像实例化本地对象那样实例化远程对象，在客户端删除对该对象实例的所有引用之后，垃圾回收器会删除远程对 象。但是，这种级别的控制成本较高。要使用客户端激活功能，必须复制可由客户端进程访问的程序集。这与各种客户端应该无需进一步设置即可访问远程对象的想 法存在冲突。
但是，您可以通过创建一个服务器激活的对象（作为服务器对象的工厂对象）来达到最佳平衡。此工厂对象创建其他对象的实例。工 厂本身是没有状态的，因此，您可以很方便地将它作为服务器激活的 Singleton 来实现它。随后，所有客户端请求都共享该工厂的同一个实例。因为该工厂对象在远程运行，所以它所实例化的所有对象都是远程对象，但是客户端可以决定在何时 以及在何处实例化它们。
粗粒度接口
跨进程和网络边界调用方法比调用同一操作系统进程中对象上的方法慢得多。
许 多面向对象的设计做法通常倾向于设计带有细粒度接口的对象。这些对象可以拥有许多带有相关 getter 和 setter 的字段以及大量方法，每种方法都封装了一小块粘合在一起的功能。由于这种细粒度特性，所以必须调用大量方法才能实现所需的结果。因为这种细粒度接口方法支 持许多令人满意的应用程序特征（如可维护性、可重复使用性和可测试性），所以对于独立应用程序，这是一种理想选择。
如果使用公开细粒度接 口的对象，则会大大影响应用程序的性能，这是由于细粒度接口要求跨进程和网络边界进行多次方法调用。为了改善性能，远程对象必须公开一个粒度更大的接口。 粗粒度接口公开一组相对较小的独立方法。每种方法通常都代表一段高级功能（如下订单或更新客户）。因为某个方法所需的全部数据都以参数形式传入该方法中， 所以这些方法都被视为独立方法。
Data Transfer Object
The Data Transfer Object 模式将粗粒度接口概念应用于如下问题：在由进程和网络边界隔开的组件之间传递数据。它建议将许多参数替换为一个对象，在该对象中存储远程方法所需的全部数据。该技术对于远程方法返回的数据也非常适用。
有 多种选项可以用来实现数据传输对象 (DTO)。一种方法是为解决方案所需的每种不同类型的 DTO 分别定义一个单独的类。针对所包含的每种数据元素，这些类通常有一个强类型的公共字段（或属性）。为了跨网络或进程边界传输这些对象，这些类都要序列化。 序列化对象被跨边界封送处理，然后在接收端重新建立。此方法的主要优点是性能和类型安全。此方法的封送处理开销最小，DTO 的强类型字段确保类型错误在编译时（而非运行时）即可被捕获。此方法的缺点是需要为每个 DTO 创建一个新类。如果解决方案需要大量 DTO，则与编写和维护这些类相关的工作会非常艰巨。
创建 DTO 的第二种方法是使用一般容器类来保存数据。此方法的常见实现是将类似于 ADO.NET DataSet 的类用作一般容器类。此方法需要两次额外转换。第一次转换发生在发送端，它将应用程序数据转换为适用于DataSet 的形式。第二次转换发生在接收端，它将数据从DataSet 中提取出来以用于客户端应用程序。在某些应用程序中，这些额外的转换可能会影响性能。此方法的另一个不足之处是缺乏类型安全性。如果将客户对象放在发送端 的 DataSet 中，则在接收端上尝试提取顺序对象时会导致运行时错误。此方法的主要优点是不必编写、测试或维护任何额外的类。
ADO.NET 提供了第三个可选选项 - 类型化 DataSet。ADO.NET 提供一种自动生成包装 DataSet 的类型安全包装器的机制。此方法存在与DataSet 方法同样的潜在性能问题，但是应用程序可以受益于类型安全这一优点，并且开发人员不必为每个 DTO 都开发、测试和维护一个单独的类。
转载于:https://www.cnblogs.com/ljf10223063/p/4625914.html
