分散式應用系統研究(2) (轉)
一、分散式應用研究
1、 對目標系統進行全面分析的理由
我們的開發人員在進行系統開發時必須掌握自己的工具,包括相關概念理論和實際工具。越來越多的高階機制能夠被我們所使用包括多執行緒和顯式動態;同時面向的方法、語言、和技術也得到越來越廣泛的應用,所有的這些都為我們重新審視和修正我們在分散式應用開發中使用的傳統方法和技術提供了機會。
系統的分析與開發實現是一個漸進的,不斷反饋改進的過程,它能夠系統的考查一個應用領域來發現系統開發和設計中的一些關鍵挑戰(問題),這樣能夠得到一個經過時間考驗的解決方法。通常一個應用需要考慮圖形介面GUI,關係、、作業系統和各種不同型別的物件導向的中介軟體。對一個待開發應用領域的完整徹底分析能夠帶來以下好處:
1. 他能夠有助於分辨和精確定義在該領域的關鍵抽象的物件空間,進而使得系統的開發人員能夠更加有效的通訊和交流。實際中,對問題空間(problem space)的清晰認識能夠大大簡化從問題空間到合適模式、模式語言、中介軟體的解決空間(solution space)的 對映。
2. 它使我們對系統的考慮分為對通用問題的考慮和特定應用的特定考慮。把注意力集中在領域內系統共有的設計問題上有助於幫助程式設計師看見應用和開發可重用類的機會
2、 分散式應用系統分析包括五個方面的問題:與服務、通訊、服務端體系結構、併發性和可性。下面詳細介紹:
協議和服務:namespace prefix = o ns = "urn:schemas--com::office" />
定義:協議是規定通訊實體之間控制和資料資訊如何互動地一系列規則。這些通訊實體可能包括一個或多個客戶、服務端或者在一個網路操作環境中對等實體的互動。服務,由服務端對外提供的、定義良好的服務能力。
關係:網路服務的互動基於協議,協議為應用程式遮蔽底層通訊細節。服務協議能被一個或多個服務使用,同時他們又基於更低一層的服務協議。
我們定義的協議和服務定義所基於的協議和服務的不同會給我們的應用開發帶來不同的影響。在一個分散式應用中,開發者可以考慮和選擇以下協議和服務:這一部分包括一下五個方面的內容:
l 無連線 、面向連線和請求/響應協議
無連線協議:
特點: 提供了面向訊息的服務,這裡每條訊息都能被獨立傳送。
無連線協議基於“最努力”原則,對訊息是否按順序到達目的地址或者是否全部到達目的地址不提供保證。
例項:使用者報(User Datagram Protocol)和IP(Inte Protocol)都是無連線協議的典型。
應用原則:這些協議一般應用於那些需要能夠容忍一定程度訊息丟失的應用,比如voice-over-IP和流影片。
面向連線協議:
特點:提供了一種可靠的、順序的、無重複傳送的服務。為了增強並確保可靠,面向連線協議在傳送端和接收端間和保持狀態資訊。
例項:傳輸控制協議(Transmission Control Protocol)也就是TCP就是一種面向連線的協議,它構成了整個 Internet的基礎。TCP提供了重傳機制以確保較面向無連線的IP協議更可靠的資料傳輸。
應用原則:這些協議特別適合那些無法容忍資料丟失的應用。
請求/響應協議
提供了一種可靠的、面向事務處理的服務,這裡處理都是以單步加鎖保護的形式進行。請求/響應協議通常用於在諸如高速這種低時延環境下短時長訊息的互動。
l 短時 與 長時服務
短時服務的時間非常短而且相對比較固定。
通常採用請求響應協議Request/Response協議或無連線協議比如UDP。
長時服務的執行時間較長而且是變化的。長時服務的例子包括透過或HTTP傳輸一個大,透過訪問主機資源。為了提供和可靠性,這些服務通常是基於面向連線協議來實現的
應該注意的是:當每一個客戶請求特別是傳送特別頻繁的請求都建立和撤銷套接字連線,會使系統(時間)開銷變大而且十分浪費應該採用長時服務型別。
l 內部 與外部服務
內部服務:在收到請求時,在相同的地址空間執行
外部服務在不同程式地址空間中處理執行。舉例來說,一個主服務分發器程式監視一系列的通訊埠。當一個連線請求從客戶端到達主伺服器時,這個分發程式接收該連線然後分發新的程式在外部來處理請求服務。
應該注意的是:內部服務會為應用系統帶來潛在的不穩定性。在一個程式中的多個服務沒有得到應有的保護,因為系統的相關共享資源容易收到不應該的破壞。
l 有狀態服務 無狀態服務
有狀態服務快取了一些確定的資訊,比如任務狀態,金鑰,認證數目和I/O控制程式碼等。這些有助於在服務端減少通訊和計算的開銷。
無狀態服務在伺服器上不保留每個連線的狀態資訊。
應該注意的是:有狀態服務和無狀態服務在效率和可靠性之間尋找折衷點,一個好的選擇依賴於很多因素比如主機和網路故障發生的可能性和帶來的影響。一些通用的網路應用服務,比如說FTP和TELNET,不需要在連續的服務呼叫之間保留永久狀態資訊。這些無狀態服務通常配置和重配置非常簡單而可靠。相反,一些服務比如的Naming Service管理著一些必須保留狀態資訊的繫結,即使這些繫結伺服器已經崩潰。
l 分層的/模組化服務 與 集中式服務
分層/模組化服務將服務分解為一系列的與層次有關的服務,在各層之間交換控制和資料訊息。
集中式服務將個服務緊密包容,他可以將各個服務模組分離好像分層一樣,但是絕大多數的資料透過共享和全域性變數集中擁有。這種系統很難以理解、維護和擴充套件。集中式服務比較適合那些短生命週期的原型系統。
選擇兩種服務分佈體系來構造自己的網路應用必須在效率、擴充套件性和模組化程度上予以折衷考慮。為你的服務選擇分層/模組化設計,有如下優勢:
1. 分層增強了系統的可重用性。因為更高層的應用元件能夠共享使用這些較低層的服務
2. 分層的服務使應用能夠透明的增強或增加系統的服務功能。
3. 分層/模組化的體系結構方便透過有選擇的去掉非必須服務來獲得宏觀層次的效能提高。
4. 模組化設計有效的提高網路應用程式的開發實現、測試和維護的效率。
同時,這種服務方式在應用到網路應用中時也有一些缺陷:
1. 分層實現的模組化為系統帶來的額外開銷較大。比如,在各層互動介面緩衝區大小的不匹配將會降低系統的效率,而且可能導致額外的分解組裝或者通訊延遲。
2. 各層間通訊必須設計合理實現優良,否則容易引起難以識別的錯誤。
由各層遮蔽的相關資訊使得在實時系統和容錯系統中定位和管理整個分散式環境下資源變得非常困難。來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/10752043/viewspace-990476/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 分散式應用系統研究(3) (轉)分散式
- 分散式應用系統研究(1) (轉)分散式
- 分散式應用系統研究(5) (轉)分散式
- 分散式系統2:分散式系統中的時鐘分散式
- Windows 2000分散式檔案系統分析和應用(轉)Windows分散式
- 分散式系統–>(關於系統應用的基本概念)分散式
- DAPP——分散式應用系統開發分析APP分散式
- 分散式應用追蹤系統 - Skywalking分散式
- Event Sourcing在分散式系統中應用分散式
- J2EE分散式應用分散式
- 集團多應用系統分散式處理自動資料流機制研究分散式
- 大型分散式網站架構:快取在分散式系統中的應用分散式網站架構快取
- Alluxio在多級分散式快取系統中的應用UX分散式快取
- .Net Core應用搭建的分散式郵件系統設計分散式
- CAP定理在分散式系統設計中的最新應用分散式
- 分散式系統分散式
- DCOM實現分散式應用(二) (轉)分散式
- 分散式系統理論基礎2 :CAP分散式
- 分散式系統:系統模型分散式模型
- 分散式 - 分散式系統的特點分散式
- 分散式系統(三)——分散式事務分散式
- [分散式]分散式計算系統淺析分散式
- Redis 應用-分散式鎖Redis分散式
- 企業應用架構研究系列三:應用系統整合應用架構
- 過去2 - 3年發表的重要的分散式系統研究論文是什麼?分散式
- 初識用.NET Remoting來開發分散式應用(轉)REM分散式
- 分散式KVM坐席協作管控 無壓損分散式坐席在中石油資訊系統整合應用分散式
- 鴻蒙系統系列教程2-鴻蒙OS系統分散式操作講解鴻蒙分散式
- 分散式系統的跟蹤系統分散式
- 分散式圖片系統分散式
- 分散式系統(二)——GFS分散式
- 分散式系統基礎分散式
- 分散式檔案系統分散式
- 冰激凌和分散式系統分散式
- 關於分散式系統分散式
- 【分散式】Zookeeper應用場景分散式
- 向分散式應用進軍分散式
- 大型分散式系統現場,阿里大牛帶你實戰分散式系統分散式阿里