分布式计算的基本原理

版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/absurd/article/details/881787

分布式计算的基本原理

转载时请注明出处:http://blog.csdn.net/absurd

 

从最近几次MMI设计会议讨论的结果来看,嵌入式程序员对于分布式计算知之甚少。他们对分布式计算有种恐惧,所以对分布式架构极力排斥。而他们的人数又占绝对优势,讨论N次,MMI的架构还是没有确定下来。分布式计算已经进入桌面环境,不是企业应用的专利了,像GNOME(GNU Network Object Model Environment)的名字本身就暗示着分布式计算了。本文介绍一下分布式的基本原理,揭开分布式神秘的面纱,让嵌入式程序员熟悉一下。

 

分布式计算可以分为以下几类:

 

传统的C/S模型。HTTP/FTP/SMTP/POP/DBMS等服务器。客户端向服务器发送请求,服务器处理请求,并把结果返回给客户端。客户端处于主动,服务器处于被动。这种调用是显式的,远程调用就是远程调用,本地调用就是本地调用,每个细节你都要清楚,一点都含糊不得。

 

集群技术。近年来PC机的计算能力飞速发展,而服务器的计算能力,远远跟不上客户端的要求。这种多对一的关系本来就不公平,人们已经认识到靠提高单台服务器的计算能力,永远满足性能上的要求。一种称集群的技术出现了,它把多台服务器连接起来,当成一台服务器来用。这种技术的好处就是,不但对客户来说是透明的,对服务器软件来说也是透明的,软件不用做任何修改就可以在集群上运行。集群技术的应用范围也仅限于此,只能提高同一个软件的计算能力,而对于多个不同的软件协同工作无能为力。

 

通用型分布式计算环境。CORBA/DCOM/ RMI/ DBUS等,这些技术(规范)差不多都有具有网络透明性,被调用的方法可能在另外一个进程中,也可能在另外一台机器上。调用者基本上不用关心是本地调用还是远程调用。当然正是这种透明性,造成了分布式计算的滥用,分布式计算用起来方便,大家以为它免费的。实际上,分布式计算的代价是可观的,据说跨进程的调用,速度可能会降低一个数量级,跨机器的调用,速度可能降低两个数量级。一些专家都建议减少使用分布式计算,即使要使用,也要使用粗粒度的调用,以减少调用的次数。

 

还其一些混合形式(SOAP?),这里不再多说。我们主要介绍第三种分布式模型,这类分布式模型即适用于企业级应用,也适用于桌面应用。有的专注于企业级应用(如CORBA),有的专注于桌面环境(如DBUS)。它们的实现原理都差不多,基本上都基于传统的RPC或者仿RPC实现的,下面介绍一下它们的基本原理。

 

我们先看一下分布式的最简模型:

model

在传统的方法中,调用一个对象的函数很简单:创建这个对象,然后调用它的函数就行了。而在分布式的环境中,对象在另外一个进程中,完全在不同的地址空间里,要调用它的函数可能有点困难了。

 

看看传统的C/S模型的请求方式,客户端把参数通过网络发给服务器,服务器根据参数要求完成相应的服务,然后把结果返回给客户端,客户端拿到结果了,一次请求算完成。由此看来,调用远程对象似乎并不难,问题在于这种方式不是网络透明的,每一个细节你都要自己处理,非常复杂。

 

要简化软件的设计,当然是网络操作透明化,调用者和实现者都无需关心网络操作。要做到这一点,我们可以按下列方法:

 

在客户端要引入一个代理(Proxy)对象。它全权代理实际对象,调用者甚至都不知道它是一个代理,可以像调用本地对象一样调用这个对象。当调用者调用Proxy的函数时,Proxy并不做实际的操作,而是把这些参数打包成一个网络数据包,并把这个数据包通过网络发送给服务器。

 

在服务器引入一个桩(Stub)对象,Stub收到Proxy发送的数据包之后,把数据包解开,重新组织为参数列表,并用这些参数就调用实际对象的函数。实际对象执行相关操作,把结果返回给StubStub再把结果打包成一个网络数据包,并把这个数据包通过网络发送给客户端的Proxy

 

Proxy收到结果数据包后,把数据包解开为返回值,返回给调用者。至此,整个操作完成了。怎么样,简化吧。

 

Proxy隐藏了客户端的网络操作,Stub隐藏了服务器端的网络操作,这就实现了网络透明化。你也许会说,根本没有简化,只是把网络操作隔离开了,仍然要去实现ProxyStub两个对象,一样的麻烦。

 

没错。不过仔细研究一下ProxyStub的功能,我们会发现,对于不同对象,这些操作都差不多,无非就是打包和解包而已,单调重复。单调重复的东西必然有规律可循,有规律可循就可以用代码产生器自动产生代码。

 

DCOMCORBA等也确实是这样做的,先用IDL语言描述出对象的接口,然后用IDL编译器自动产生ProxyStub代码,整个过程完全不需要开发人员操心。

 

打包和解包的专业术语叫做marshalunmarshal,中文常用翻译为列集和散集。不过这两个词太专业了,翻译成中文之后更加让人不知所云。我想还是用打包和解包两个词更通俗一点。

 

在以上模型中,调用对象的方法,确实做到了网络透明化。读者可以会问,我要访问对象的属性怎么办呢?对象的属性就是变量,变量就一块内存区域,内存区域在不同的进程里完全是独立的,这看起来确实是一个问题。还记得很多关于软件设计书籍里面讲过的吗:不要暴露对象属性,调用者若要访问对象的属性,通过get/set方法去访问。这样不行了吗,对属性的访问转换为对对象方法的调用。

 

OK,调用对象的方法和访问对象的属性都解决了。还有重要的一点,如何创建对象呢。因为实际的对象并不固定在某台机器上,它的位置可能是动态的。甚至Proxy本身也不知道Stub运行在哪里。如果要让调用者来指定,创建对象的过程仍未达到网络透明化。通常的做法是引入一个第三方中介,这个第三方中介是固定的,可以通过一定的方法找到它。第三方中介负责在客户端的Proxy和服务器的Stub之间穿针引线。第三方中介通常有两种:一种是只负责帮客户端找到服务器,之后客户端与服务器直接通信。另外一种就是不但负责找到服务器,而且负责转发所有的请求。

 

以上的模型仍然不完整,因为现实中的对象并不是一直处理于被动的地位。而是在一定的条件下,会主动触发一些事件,并把这些事件上报给调用者。也就是说这是一个双向的动作,单纯的C/S模型无法满足要求,而要采用P2P的方式。原先的客户端同时作为一个服务器存,接受来自己服务器的请求。像COM里就是这样做的,客户端要注册对象的事件,就要实现一个IDispatch接口,给对象反过来调用。

 

自己实现时还要考虑以下几点:

 

l         传输抽象层。分布可能是跨进程也可能是跨机器。在不同的情况下,采用不同的通信方式,性能会有所不同。做一个传输抽象层,在不同的情况下,可选用不同的传输方式,是一种好的设计。

 

l         文本还是二进制。把数据打包成文本还是二进制?打包成文本的好处是,可移植性好,由于人也可以看懂,调试方便。坏处是速度稍慢,打包后的数据大小会明显变大。采用二进制的好处是,速度快,打包后的数据大小与打包前相差不大。坏处是不易调试,可移植性较差。

 

l         字节顺序和字节对齐。若采用二进制方式传输,可移植性是个问题。因为不同的机器上,字节顺序和字节对齐的方式都有些差异,在数据包中要加入这些说明,以提高可移植性。

 

 

 

没有更多推荐了,返回首页