更新时间：2023-05-23 09:13
分布式架构（Distributed Architecture）是分布式计算技术的应用和工具，成熟的技术包括J2EE, CORBA和.NET(DCOM)，这些技术牵扯的内容非常广，相关的技术，相关的书籍也非常多，本文不介绍这些技术的内容，也没有涉及这些技术的细节，只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。
一、分布式计算技术的形成
CORBA (Common Object Request Broker Architecture) 是在1992年由OMG(Open Management Group) 组织提出的。那时的分布式应用环境都采用Client/Server架构，CORBA的应用很大程度的提高了分布式应用软件的开发效率。
当时的另一种分布式系统开发工具是Microsoft的DCOM(Distributed Common Object Model)。Microsoft为了使在Windows平台上开发的各种应用软件产品的功能能够在运行时(Runtime)相互调用(比如在Microsoft Word中直接编辑Excel文件)，实现了OLE(Linked and Embedded Object)技术，后来这个技术衍生为COM(Common Object Model)。
随着Internet的普及和网络服务(Web Services)的广泛应用, Browser/Server架构的模式逐渐体现出它的优势。 于是，Sun公司在其Java技术的基础上推出了应用于B/S架构的J2EE的开发和应用平台;Microsoft也在其DCOM技术的基础上推出了主要面向B/S应用的.NET开发和应用平台。
二、使用的协议
.NET中涵盖的DCOM技术和CORBA一样，在网络传输层都采用TCP/IP协议;也都有自己的IDL规范。所不同的是，在TCP/IP之上，CORBA采用GIOP/IIOP协议，所有CORBA服务器以IIOP通信，形成了ORB软件通道;J2EE的RMI曾经采用独立的通信协议，已经改为RMI/IIOP，体现了J2EE的开放性;DCOM也有自己的通信协议(TCP在135端口的服务)，但微软没有公开这个协议的规范;同样，CORBA的IDL采用类C++的定义，是公开的规范;DCOM的IDL的文件虽然是文本形式的，微软没有正式公布它的规范，在使用中，.NET的IDL是由开发工具生成的。
三、应用的环境
关于.NET，比尔盖茨这样说:“简单地说，.NET是以微软的各种产品为开发工具和应用平台， 实现基于XML的网络服务。”由此也可以看出，.NET在Microsoft的世界里功能强大，但对于Unix和Linux这些在服务器市场占主要份额的系统，.NET显得束手无策。
因此，J2EE显示了它跨平台的优势，为网络服务商提供了很好的面向前端(front-end)的开发和应用平台, 随着网络服务进一步广泛应用和服务集成度的提高, 在网络服务提供商的后台会形成越来越庞大的分布式计算环境, CORBA模块结构更适合后台(back-end)的多种服务, 例如网络服务的计费程序等. 因此可以看出, J2EE和CORBA技术在网络服务(Web Services)这片蓝天下, 各自有自己的海洋和陆地。如果在前端(front-end)使用了.NET开发平台，那么在后端(back-end)的分布式结构中，DCOM就是理想的选择。
J2EE是纯Java技术，很多测试显示RMI(Java)服务器的响应速度远远低于非Java的CORBA服务器。因此，在一些对数据处理速度和响应时间要求较高的系统开发中，要对RMI和CORBA的性能进行测试对比后再做选择。
四、应用软件的开发和维护
从应用软件的开发过程的角度看, J2EE是完全开放式的平台, 体现为既面向设计人员, 也面向开发人员的规范; CORBA也是一种规范, 但更多体现为中间产品, CORBA产品的提供商才是这种规范的真正执行者, 对应用开发的程序员而言, 只要了解IDL语言的规范, 不必详细知道ORB/GIOP/IIOP的协议细节。.NET作为Microsoft在网络环境的主打, 体现为一系列产品化的开发工具, 比如C#, C++, 等。这些开发工具是直接针对应用开发人员的。其实Sun公司提供的J2EE也是由许多软件包(应用API)来面对开发人员的。
从软件开发成本与周期以及软件的维护角度看，J2EE比CORBA有以上优势。
五、应用前景
对于分布式计算技术的架构，不能绝对地说哪一个更好，只能说哪一个更合适。针对不同的软件项目需求，具体分析才是明智的选择。
从宏观市场看，CORBA产品的销售并没有想象那样给CORBA产品提供商带来可观的利润;而J2EE的呼声也高于.NET; 随着J2EE中RMI/IIOP与CORBA接口的完善，再加上开发费用的考虑和使用的方便性，J2EE一揽子开放的环境会是人们首先考虑的选择;但CORBA标准的强壮的兼容性，也使这种技术在大型系统开发中会占有一席之地。
关于作者
周斌 北京时力永联科技公司业务咨询和软件外包服务部经理，曾执教于复旦大学计算机科学系, 1994年赴美国Oracle总部参加合作项目, 后就读于加拿大哥伦比亚大学
EMC VMAX
VMAX架构包含1个到8个VMAX引擎（存储节点）。这些引擎相互连接在一起，被称为虚拟Matrix架构。每个引擎都可以当作存储阵列，拥有自己的前端主机端口连接、后端磁盘导向器、高速缓存（内部镜像化）和处理器。VMAX引擎使用Matrix接口主板封装器（MIBE）连接在一起。MIBE有副本以备冗余。虚拟Matrix可以进行引擎之间的记忆体访问。当主机访问端口和数据不在同一个引擎上的时候需要虚拟Matrix提供连接性。
3Par InServ
3Par由多个存储节点组成。这些存储节点汇集到一个高速连接上。3Par称之为InSpire架构。2到8个节点（按对配置）连接到一个被动背板，每个节点之间的带宽可高达1.6Gb/秒。3Par如图所示展示他们的8节点架构，连接的数量很容易就能看清楚。我还看到2节点、4节点、6节点和8节点部署下的连接是如何增加的。InServ阵列按对写入高速缓存数据，因此每个节点都有一个伴点。如果一个节点发生故障，伴点上的高速缓存可以马上写入另一个节点，从而保护高速缓存数据。
IBM XIV阵列采用的是另一种节点设置方式。节点直接连接到底层硬件的数据保护机制。XIV只使用RIAD-1类型的保护，采用的是1MB大小的数据块，也称为分区。数据以伪随机方式均匀分布在节点上，确保对任何LUN来说，数据都是写入在所有节点上。本文底部的XIV图片显示了这个架构。节点（在XIV中称为模块）分成接口模块和数据模块。接口模块有自己的高速缓存、处理器、数据磁盘和主机接口。数据模块没有主机接口，但是仍然有高速缓存、处理器和磁盘。每个模块有12个1TB SATA驱动器。当数据写入阵列的时候，这些1MB分区写入到所有驱动器和模块中，确保任意一个分区的两个镜像对不会都处在同一个模块上。LUN的顺序分区分布在各个模块上。这样做的结果就是所有的模块都参与服务所有的卷，且单个模块的故障不会导致数据丢失。