-
分佈式架構
鎖定
- 中文名
- 分佈式架構
- 外文名
- Distributed Architecture
- 形 成
- CORBA
- 使用的協議
- GIOP/IIOP協議
- 環 境
- 跨平台的優勢
- 應用前景
- 明朗
分佈式架構詳細説明
一、分佈式計算技術的形成
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標準的強壯的兼容性,也使這種技術在大型系統開發中會佔有一席之地。
關於作者
分佈式架構對比
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的順序分區分佈在各個模塊上。這樣做的結果就是所有的模塊都參與服務所有的卷,且單個模塊的故障不會導致數據丟失。
[1]
- 參考資料
-
- 1. 如何選擇:單片架構和模塊化架構 .TechTarget存儲[引用日期2015-07-17]