分布式的几个问题

引子

软件科学和软件工程发展的本质线索是“对公共逻辑抽取（抽象）”，这是一切软件思想、架构、方法、模式的根本出发点和归宿。从机器语言到汇编语言、 从汇编语言到高级语言、从数据文件到数据库、从面向过程到面向对象，甚至大到操作系统、C/S结构、网络协议、分布式计算、设计模式，小到数据类型、 类接口，概莫能外。

 

关于分布式计算的几个基本问题： 

1. 怎样理解企业计算？企业计算是和个人计算相对的。通过核心数据构成的关联性是企业计算的本质特征。  

2.  怎样分布？和C/S架构类似，分布式计算要实现的是业务逻辑的分布，但不是无原则的分布。例如，”在一个机器上计算出和，再在另一个机器上计算平均数” ，或者”在A机器上进行打印Preview，在B机器上打印出来”，这样的“分布计算”是毫无意义的。分布计算的理论线索，仍然是“对公共部分的抽取”，抽象出可 以在企业范围内可以被公共调用的部分，封装成Component。由于企业环境中业务的相关性，这种可供“抽取”的“公共部分”占据了业务逻辑的绝大部分，这就 是“分布计算”的现实意义。如果没有分布式计算，这些公共逻辑需要单独写在不同的调用模块里，并且运行在不同机器上。SQL的存储过程实现了一部分公共 逻辑的抽取，但公共逻辑远远不限于数据库领域。  

3.  和传统C/S架构、B/S、Socket的根本区别？传统的狭义的C/S结构，客户端和服务器是通过SQL语言在“数据”的级别上进行藕荷的，客户端程序只能通过“文本 ”向服务器传递命令；HTTP以及Socket的客户端和服务器仍然是通过“数据”进行耦合的，此处的“数据”就是通信协议，组成协议的命令、参数、和返回数据本 身都是数据。分布式计算模式下，客户端通过“过程调用”（对象调用本质上也是过程调用）的方法和服务器通信，客户端在自己的进程地址空间内透明使用 服务器提供的过程，就象使用本地过程一样。由于过程调用是程序运行的基本机制，因此分布式计算模式比狭义C/S结构更具有普遍意义。需要注意的是，正 是由于SQL/Socket/HTTP的“数据耦合”的本质，才使得这些东西可以做到客户端和服务器可以跨越异构平台。从另一方面讲，分布式计算在底层仍然是通过“ 数据”藕荷的，只是通过一定的系统机制做了封装。物理意义上“过程藕荷”在不同的地址空间内是无法实现的，即使在同一个CPU上也是如此。另外Borland的 MIDAS架构直接支持的仍然是“数据藕荷”，也就是说，客户端和中间服务器是通过DataSet进行联系的，我认为这是MIDAS架构没有被视作真正意义上的分布计 算体系、也没有能争夺MTS/COM+市场的重要原因之一。   以上之所以使用狭义C/S的概念，是因为从广义上讲，分布计算本身也是C/S结构。

4. 基本原理：最早的分布计算模式是RPC(Remote   Procedure   Call)，这是真正意义上的、最本质的分布式计算，同时也是所有其他分布计算模式的底层基础。在Java世界，RPC的同等概念是RMI(Remote   Method   Invocation)。以后出现的各种分布式计算模式都是基于OOP的：COM/DCOM/COM+,   Corba,   RMI,   EJB,   .NET   Remoting。所有这些模式的基本原理都是一样的：客户端使用一个在概念上属于系统层的代理，这个代理运行在客户程序进程空间内，作为本地过程体（徒 有架子，没有真正实现代码），接受客户端代码的调用，然后将调用封装成数据（无非参数、过程标识而已），传递给服务器端的对等“代理”，这个代理和 服务器程序运行在同一进程空间内，由它去根据客户端代理传递来的参数和过程标识，重新生成过程调用，在本地运行真正的过程实现代码，然后将返回参 数（同样还是“数据”）交给客户端代理，客户端代理在交给客户端调用者。这样的模式在现实生活中比比皆是！最好的例子是你钟爱的特快专递。总之，需 要4方，缺一不可。理解了这个问题，再去理解Java/COM/.NET的接口概念就迎刃而解。客户端代理呈现给客户的“空架子”，就是接口！第一、没有实现代码 ；第二、不改变调用方式。需要说明的是：客户端和服务器的代理代码，由于和应用本身有确定的映射关系，因此，可以通过工具自动（往往就是应用服务 器）生成；虽然它们不包含实际的过程实现代码，但包含了非常复杂的网络传输和转换代码。  

5.  应用服务器的根本用途是什么？一切分布式计算都存在事务控制、负载均衡、安全验证、资源缓冲。解决这些问题的复杂度，远远超过了一般业务逻辑本身 ，同时完善地解决这些问题，又是任何分布计算系统能具备实际意义的前提。比如事务控制，即使在C/S结构中，没有事务控制的代码也是非常危险的，但在 分布式系统中，事务控制的难度更大，必须解决基于SQL的事务处理模式所不能解决的跨不同数据库服务器以及非数据库的事物控制问题。由于应用服务器代 理客户端去访问数据库，加上缓冲池机制，成数量级地降低了对数据库服务器的并发连接数量，大大改进了性能。虽然增加了一层，但是，在大多数情况下 ，和客户端数据库建立连接的时间大于实际的数据处理时间、服务器用于维持客户端连接所耗费的内存资源远远大于处理数据和返回结果集的内存需求、数 据库系统客户端驱动所占据的磁盘空间和安装维护复杂度远远大于应用程序本身！应用服务器到底通过什么原理介入？从前面一节的分析可以看出，从物理 意义上说，对服务代码的调用是由服务器端的“代理”执行的，而代理又是可以由服务器生成的，因此，服务器有权在这个环节上插入必要的逻辑，扮演自己 的角色，而这些实现细节都不需要客户端知道。只需要以极其简单的形式（甚至不必通过编程，只需在配置文件里声明一下），就可以让应用服务器做到“过 程A和过程B要么都成功，要么恢复原状相当于没执行”，即非数据库的事务处理。和数据库服务器不同的是，应用服务器仅提供这种“默默无闻”的服务，使你 的代码更健壮、更有效、更安全，不提供也无法提供API让前台直接调用以实现某种业务逻辑。后者完全由你提供的Component实现。Delphi   MIDAS没有任何应用服务器的关键特征，所有这些问题，必须由程序员提供代码，这是MIDAS没有被广泛接受的另一个原因。然而Delphi提供了MTS/COM+编程 的强大支持。目前流行的应用服务器，在Windows平台上是COM+（过去是MTS,   Microsoft   Transaction   Server），在J2EE上是BEA   Weblogic，IBM   Websphere，几乎所有的数据库厂商都提供了各自的J2EE服务器。.NET仍然使用COM+服务器。  

6.  什么是面向Component的编程？Component是运行在应用服务器里面的业务逻辑代码。第一、它必须是可执行代码（exe/dll/ocx/class等）；第二、它不能独 立执行，必须通过应用服务器间接调用。Delphi的Component本质上属于源代码的范畴，是编译器级别的概念，和普通的OOP的class没有本质区别，因此和分 布计算里面的Component是完全不同的概念。符合这些条件的，有COM对象，.NET   组块，EJB构件和Corba对象。  

7. Web   Service是什么？在Internet环境中，上面谈到的分布计算模式存在两个重要限制：第一、必须有客户端支持，比如，EJB客户端需要JVM，DCOM客户端需要DC OM库等等；第二、无法穿越防火墙。Web   Service作为一种最新的分布计算架构，就是为解决这些问题而出现的。由于分布过程调用本质上是通过交换数据实现的，通过HTTP协议交换XML数据就可以 完全胜任这个工作！这就是SOAP协议！Web   Service的根本原理就在这里。作为应用层协议，HTTP和SOAP是不需要安装的，而是由程序员在应用程序里实现（非常简单）。因此，Web   Service客户所需要的全部系统支持就是：TCP/IP。这就说明了一切！   Web   Service已经大红大紫，.NET提供了Web   Service的最早也最简洁的支持，J2EE只是在目前略逊一筹。  

8. 分布计算和Web的关系如何？从广义上讲，Web服务器也是一种应用服务器，而且Web   Service的Container也往往是通过Web服务器。Web服务器通过扩展机制（主要是DLL和JVM延伸），将HTTP请求转交给扩展代码，例如cgi   code/asp/jsp/servlet等，由这些扩展代码做任意处理（例如数据库查询），然后将产生的结果页面归还给Web服务器，再由Web服务器传递到客户端。由于 扩展机制的存在，Web程序员可以通过全功能的代码去作为客户，调用应用服务器或数据库服务器。浏览器+Web服务+应用服务+数据库服务这就是典型的4层 结构。而在这个基础上，层次的再次细分是任意的，因为应用服务可以作为客户调用其他的应用服务。但无论怎么分，都不是随意的，本质上要作到“公共逻 辑的抽取”。