慎用分布式对象

慎用分布式对象

 

0 引言

在网络开发和企业级应用中分布式对象使用十分广泛。但是，这其中也出现了很多问题。所以要求“慎用分布式对象”，能够不使用分布式对象，就尽量不使用。

使用分布式对象有一个基本原则：将对象放置于正确的位置上。如果没有将对象放置在正确的位置，就会付出昂贵的性能代价。

1 分布式对象常见问题

人们一创建对象，就想分发他们。然而，在对象的分发过程中，通常会犯很多错误。

1.1 设计者的梦想，开发者的恶梦

图1-1 采购系统设计图

 

通过在不同的节点放置不同的对象来发布应用程序听上去是个不错的想法，但是性能的代价是巨大的。这是一个分布式对象系统设计图，我们假设它是某种采购系统。这个设计中针对客户、订单、产品和递送都有分别的远程对象，每个远程对象放置在不同的进程节点处。在实际运行过程中，它的性能非常差。

也许，很多软件销售商所宣传的分布式对象的优点是：能够选取一些对象，随心所欲地将他们放置在进程节点。同时，他们强大的中间件提供了透明机制。

透明机制允许对象在一个进程内，或在两个进程之间互相调用，而不必知道被调用者是否在这个进程或另一个进程或在另一台机器上存在。

透明机制确实有价值，在分布式对象中很多东西能够实现透明机制，但是性能却不可能实现透明机制。尽管设计原型是为了性能的因素进行设计，但是实际上，其设计会削弱性能，使系统更加难以创建、更加难以实施。

1.2 本地接口和远程接口

计算机体系存在着这样一个基本事实：一个进程内部的程序调用非常快，但是两个不同的进程间的程序调用速度呈几何级数减慢。因此将一个进程运行在其他的机器上，就会增加一个或者两个数量级的复杂度，这与网络的拓扑结构有关。所以，本地对象接口和远程对象接口截然不同。

本地对象接口是细级度的。因此，如果有一个地址类，一个良好的接口应该有分别的方法来获取城市名、获取省名，设置城市名、设置省名等等。细级度的接口结构很好，因为它依循了一般的面向对象原则：大量的小块能够被组合在一起，以不同的方式重载，这样就可以扩展设计以适应将来的需要。

但是细级度接口处理远程任务时就不那么好用了。当方法调用速度减慢时，我们希望用一个调用，而不是用三个调用来获取或更新城市名、省名和邮编。因此需要的接口是粗级度的，它不是为了灵活性和扩展性而设计的，而是为了减少调用设计的，所以将看到一个有获取地址和更新地址功能的接口。也许粗级度接口看上去笨拙，但是为了性能，必须使用粗级度接口。

当然，软件销售商一般会说他们的中间件无论是对于远程调用还是本地调用都是适用的。如果是本地调用，它就拥有本地调用的速度；如果是远程调用，速度就会慢一些。因此，只需要在需要远程调用时付出远程调用的代价。这个说法在某种程度上是真实的，但是它并没有解决一个基本问题：任何被用于远程调用的对象都应该是粗级度的，而每个不是用于远程的对象应该有细级度的接口。当两个对象通信的时候，必须选择使用哪种接口。如果对象在不同的进程中，就必须使用粗级度接口，就必须为此付出更多的编程工作。显而易见，只有当必要的时候才使用粗级度接口，因此需要尽量减少进程间的协作。

因为这些原因，就不能只是在一个进程中采用一组类，然后提出CORBA，设计一个分布式模型。分布式设计决不是这样。如果分配策略是基于类的，那么就要面对一大堆远程调用以及粗级度接口。如此多的远程调用和粗级度接口会导致程序的崩溃；甚至当远程类有粗级度接口时，也会因为太多的远程调用而崩溃。

2 解决办法

  以下是解决分布式对象的三种方法，可以单独使用，也可以组合起来使用。

2.1 尽量不要分发对象

 

聚类方法是指将同一个应用的多份拷贝放置于不同的节点上。如果必须分发，这种方法会消除潜在的问题。

图2-1 聚类方法

 

在大多数情况下，采用聚类方法：将所有的类放在一个进程中，然后在不同节点运行该进程的拷贝。采用这种方法，每个进程都能够使用本地调用来完成工作，因此，速度会快一些。同样也可以在进程内部对所有的类使用细级度的接口，这样在一个更简单的程序模型中可以获得更好的可维护性。

 

在什么时候必须分发？

 

因此你希望能够最小化分发的边界，通过聚类方法尽可能地利用你的节点。可是矛盾在于对于聚类方法的使用范围是有限制的，在某些地方必须采用分布式对象，即进行进程分割。

一个明显的进程分割就是在传统的客户机和服务器上商业软件的分割。在不同用户桌面上的PC就是分享数据仓库的不同节点。既然他们是不同的机器，就必须分割彼此通信的进程。客户机/服务器分割是典型的跨进程分割。

进程分割经常发生在服务器端应用软件（应用服务器）和数据库服务器之间。当然，你可以在数据库进程中通过使用存储过程来运行你的所有的应用软件。但这是不实际的，因此必须要有分别的进程。他们也许在同一台机器上运行，但是一旦有了分别的进程，就马上会在远程调用中付出很大的开销。幸运的是， SQL被设计为远程接口，这样就可以经常灵活的安排事务以最小化开销。

进程分割发生在Web系统中Web服务器和应用服务器之间。如果所有事件相同的话，最好在一个进程中运行Web服务器和应用服务器—但是不幸的是，并不是所有的事情总是相同。

由于软件销售商的不同也必须分割进程。如果你使用一个软件包，它常常运行在自有的进程中，分发时也是如此。一个好的软件包应该至少有一个粗级度的接口。

还有其它原因造成应用服务器软件分割。你也许会尽可能地去避免它们，但是情况还是会出现。所以你必须将你的软件分割为远程、粗级度的部分。

 

“谨慎对待对象分发”，尽可能采用其它办法，这是高于一切的主题。

2.2 使用分发边界

远程正面和数据传输对象是使远程结构工作的两个重要概念。

 

当设计系统的时候，尽可能地限制分布式的范围，但在有分布式对象的地方，必须考虑它这个因素。系统中的所有部分都必须改变以减少远程调用。不过，你仍然可以通过使用细级度对象来在单一进程中进行设计。这里的关键在于在系统内部使用细级度对象，在分发边界处放置粗级度对象，粗级度对象的作用只是为细级度对象提供接口。粗级度对象并不做任何事情，但他们是细级度对象的正面，这种正面仅仅用于分发目的—所以叫做远程正面。

使用远程正面可以最小化粗级度接口引入的困难。所以，只有真正需要远程服务的对象才能使用粗级度方法，因为对开发者来说，很显然，他们要为粗级度接口付出昂贵的代价。透明机制确实有它的优点，但在远程调用时并不需要透明机制。

通过将粗级度对象仅仅作为正面，只要人们确定细级度对象运行在同一个进程中，就可以使用他们，这使整个分发策略更加清楚。

与远程正面同时起作用的是数据传输对象。因为不仅需要粗级度方法，同样也需要传输粗级度对象。当寻找一个地址的时候，需要将这个信息在放置在一个信息块里面传输。因为通常不可能传输域对象本身，因为它被捆绑在一个细级度的本地对象网络中。于是将所有客户端需要的数据打包在一个特殊的用于传输的对象中—即数据传输对象。数据传输对象出现在传输链的两端，因此它排除了不在这个传输链上的其他任何东西。这样就保证了数据传输对象只与其他数据传输对象以及象序列这样的基本对象作用。

2.3 使用分发接口

只有当直接的方法行不通时才使用Web服务。

 

传统意义上分布式对象的接口是基于远程过程调用的，要么通过全局过程，要么通过对象方法。然而，在最近一两年，我们开始看见基于HTTP上XML的接口。SOAP可能是这种接口形式最常见的一种，其实许多人已经使用这项技术已经很多年了。

基于XML的HTTP通信是非常便利的，因为以下几点原因：

ü         XML是一种公有的格式，许多平台上都有它的解析器，这就允许不同平台上的系统相互通信，就像HTTP的通用性一样；

ü         XML允许大量的数据很便利地传送；

ü         XML具有结构化的形式；

ü         XML只需要一个环程；

ü         XML是基于文本的，就容易看清是什么通过了传输链；

ü         HTTP很容易通过防火墙，因为安全和政治因素经常造成其他端口不能开放，所以这一点对于信息传输是非常有用的。

因为需要最小化远程调用，基于XML的HTTP通信是一件很好的事情。

 

虽然如此，类和方法的面向对象接口也有其存在价值。将所有的传输数据都转移进入XML结构和序列会给远程调用增加相当可观的负担。当然，如果用基于XML的接口替换远程调用，应用程序的性能会得到显著的改善。如果传输链的两端使用同样的二进制机制，XML接口只会给你提供一个混乱的缩写词集合。如果两个系统建立在同一个平台上，最好使用建立在该平台上的远程调用机制。当希望不同的平台互相对话，Web服务就很便利。所以只有当更加直接的方法不可能时，再使用XML Web 服务。

当然，可以博采两者之长，建立基于面向对象接口的HTTP接口。所有对Web服务器的调用都会被其解释成对底层的面向对象接口的调用。在某种程度上来说，这能够综合两者的优点，但是增加了复杂性，因为同时需要针对Web服务器和远程OO界面的部件。所以，只有当你同时需要HTTP和远程OO API（应用程序接口），或相对于使用非远程对象，远程OO API针对安全性和事务处理的能力使其易于处理这些问题时，才采取两者结合的方式。

3 结束语

本文介绍了同步、基于RPC的接口。然而，尽管我描述了这种方法，但我并不认为这是处理分布式系统的最好办法。我优先选择基于消息的方法，因为其本质就是不同步的，而且，我认为这是处理WEB服务的最好办法。对于分布式对象的使用，必须小心、慎重。

 

(特别注意：此文章已在计算机世界网www.ccw.cn发表，如果转载请直接与计算机世界网联系，非法转载将受到《著作权法》的严厉制裁！)

更多信息见中国软考联盟：www.cnitunion.com  中国软考联盟