分散式系統

在一個分散式系統中，一組獨立的計算機展現給用戶的是一個統一的整體，就好像是一個系統似的。系統擁有多種通用的物理和邏輯資源，可以動態的分配任務，分散的物理和邏輯資源通過計算機網路實現信息交換。系統中存在一個以全局的方式管理計算機資源的分散式操作系統。通常，對用戶來說，分散式系統只有一個模型或范型。在操作系統之上有一層軟體中間件（middleware）負責實現這個模型。一個著名的分散式系統的例子是萬維網（World Wide Web），在萬維網中，所有的一切看起來就好像是一個文檔（Web頁面）一樣。

在計算機網路中，這種統一性、模型以及其中的軟體都不存在。用戶看到的是實際的機器，計算機網路並沒有使這些機器看起來是統一的。如果這些機器有不同的硬體或者不同的操作系統，那麼，這些差異對於用戶來說都是完全可見的。如果一個用戶希望在一台遠程機器上運行一個程序，那麼，他必須登陸到遠程機器上，然後在那台機器上運行該程序。

分散式系統和計算機網路系統的共同點是：多數分散式系統是建立在計算機網路之上的，所以分散式系統與計算機網路在物理結構上是基本相同的。

他們的區別在於：分散式操作系統的設計思想和網路操作系統是不同的，這決定了他們在結構、工作方式和功能上也不同。網路操作系統要求網路用戶在使用網路資源時首先必須了解網路資源，網路用戶必須知道網路中各個計算機的功能與配置、軟體資源、網路文件結構等情況，在網路中如果用戶要讀一個共享文件時，用戶必須知道這個文件放在哪一台計算機的哪一個目錄下；分散式操作系統是以全局方式管理系統資源的，它可以為用戶任意調度網路資源，並且調度過程是“透明”的。當用戶提交一個作業時，分散式操作系統能夠根據需要在系統中選擇最合適的處理器，將用戶的作業提交到該處理程序，在處理器完成作業后，將結果傳給用戶。在這個過程中，用戶並不會意識到有多個處理器的存在，這個系統就像是一個處理器一樣。

內聚性是指每一個資料庫分佈節點高度自治，有本地的資料庫管理系統。透明性是指每一個資料庫分佈節點對用戶的應用來說都是透明的，看不出是本地還是遠程。在分散式資料庫系統中，用戶感覺不到數據是分佈的，即用戶不須知道關係是否分割、有無副本、數據存於哪個站點以及事務在哪個站點上執行等。

分散式軟體系統(Distributed Software Systems)是支持分散式處理的軟體系統，是在由通信網路互聯的多處理機體系結構上執行任務的系統。它包括分散式操作系統、分散式程序設計語言及其編譯(解釋)系統、分散式文件系統和分散式資料庫系統等。

負責管理分散式處理系統資源和控制分散式程序運行。它和集中式操作系統的區別在於資源管理、進程通信和系統結構等方面。

用於編寫運行於分散式計算機系統上的分散式程序。一個分散式程序由若干個可以獨立執行的程序模塊組成，它們分佈於一個分散式處理系統的多台計算機上被同時執行。它與集中式的程序設計語言相比有三個特點：分佈性、通信性和穩健性。

具有執行遠程文件存取的能力，並以透明方式對分佈在網路上的文件進行管理和存取。

由分佈於多個計算機結點上的若干個資料庫系統組成，它提供有效的存取手段來操縱這些結點上的子資料庫。分散式資料庫在使用上可視為一個完整的資料庫，而實際上它是分佈在地理分散的各個結點上。當然，分佈在各個結點上的子資料庫在邏輯上是相關的。

分散式郵件系統的部署設計，即同一域名下，跨地域部署的郵件系統。適用 於在各地設有分部的政府機構或者大型集團，有效管理各地的人員結構，同時提高了郵件伺服器應用效率。

分散式郵件系統由多個數據中心組成，大量分支機構或較小的分散站點與數據中心的連接。分支機構需要建立自己的郵件伺服器，來加快處理當地分支機構的郵件。承載相應的數據處理量。以提高郵件處理能力，郵件收發速度，郵件功能模塊化。

分散式部署方案適合以下情況

1、公司有不同分支機構或較小的分散站點與公司總部的網路連接通常是低帶寬、高滯后或不可靠的。

2、公司總部網路無法處理中心位置的服務流量。

3、分支機構有自己的伺服器、企業網路、域控制器和系統管理員，包含數目不定的用戶。

4、用戶要求有更快的郵箱訪問速度、更佳的用戶體驗和可用性。

5、郵箱用戶數量大，併發線程多。

6、對於安全要求高，需要把郵件伺服器不同的功能分開部署。

分散式郵件系統方案情況

1、異地同域名分散式

此方案適用於集團郵件系統，各個下屬子公司為了提高郵件收發速度，降低郵件負載而提出的方案。分為同域名不同用戶數分散式和同域名同用戶數分散式。

2、功能分散式

郵件負載比較重，對於某一些功能要求比較高，需要郵件伺服器功能分開部署的客戶。

3、用戶分散式

郵箱用戶數巨大，單機郵件伺服器無法承載，伺服器做集群。

分散式系統，最簡單的例子是Browser--Server結構，這兩者結合起來就成了最簡單的分散式系統，或者可以這樣理解：基於網路的軟體系統大多都是分散式系統，只不過在系統的複雜程度上有所區別而已。

分散式系統被用在許多不同類型的應用中。以下列出了一些應用。對這些應用而言，使用分散式系統要比其他體系結構如處理機和共享存儲器多處理機更優越：

原則上，并行應用也可以在共享存儲器多處理機上運行，但共享存儲器系統不能很好地擴大規模以包括大量的處理機。HPCC（高性能計算和通信）應用一般需要一個可伸縮的設計，這種設計取決於分散式處理。

因為每個PE是自治的，所以分散式系統更加可靠。一個單元或資源（軟體或硬體）的故障不影響其他資源的正常功能。

許多應用是固有分散式的。這些應用是突發模式（burstmode）而非批量模式（bulk mode）。這方面的實例有事務處理和Internet Javad,程序。

這些應用的性能取決於吞吐量（事務響應時間或每秒完成的事務數）而不是一般多處理機所用的執行時間。

對於一組用戶而言，分散式系統有一個特別的應用稱為計算機支持的協同工作（Computer Supported Cooperative Working，CSCW）或群件（groupware），支持用戶協同工作。另一個應用是分散式會議，即通過物理的分散式網路進行電子會議。同樣，多媒體遠程教學也是一個類似的應用。

為了達到互操作性，用戶需要一個標準的分散式計算環境，在這個環境里，所有系統和資源都可用。

DCE（分散式計算環境）是OSF（開放系統基金會）開發的分散式計算技術的工業標準集。它提供保護和控制對數據訪問的安全服務、容易尋找分散式資源的名字服務、以及高度可伸縮的模型用於組織極為分散的用戶、服務和數據。D C E可在所有主要的計算平台上運行，並設計成支持異型硬體和軟體環境下的分散式應用。

DCE已經被包括TRANSVARL在內的一些r一商實現。TRANSVARL是最早的多廠商組（multi vendor team）的成員之一，它提出的建議已成為DCE體系結構的基礎。在中可以找到利用DCE開發分散式應用的指南。

一些其它標準基於一個特別的模型，比如CORBA（公用對象請求代理程序體系結構），它是由OMG （對象管理組）和多計算機廠商聯盟開發的一個標準。CORBA使用面向對象模型實現分散式系統中的透明服務請求。

工業界有自己的標準，比如微軟的分散式構件對象模型（DCOM）和Sun Microsystem公司的Java Beans。

系統傾向於分散式發展潮流的真正驅動力是經濟。25年前，計算機權威和評論家Herb Grosch指出CPU的計算能力與它的價格的平方成正比，後來成為Grosch定理。也就是說如果用戶付出兩倍的價錢，就能獲得四倍的性能。這一論斷與當時的大型機技術非常吻合，因而使得許多機構都盡其所能購買最大的單個大型機。

隨著微處理機技術的發展，Grosch定理不再適用了。到了二十一世紀初期，人們只需花幾百美元就能買到一個CPU晶元，這個晶元每秒鐘執行的指令比80年代最大的大型機的處理機每秒鐘所執行的指令還多。如果你願意付出兩倍的價錢，將得到同樣的CPU，但它卻以更高的時鐘速率運行。因此，最節約成本的辦法通常是在一個系統中使用集中在一起的大量的廉價CPU。所以，傾向於分散式系統的主要原因是它可以潛在地得到比單個的大型集中式系統好得多的性價比。實際上，分散式系統是通過較低廉的價格來實現相似的性能的。

與這一觀點稍有不同的是，發現微處理機的集合不僅能產生比單個大型主機更好的性能價格比，而且還能產生單個大型主機無論如何都不能達到的絕對性能。例如，按二十一世初期的技術，能夠用10000個現代CPU晶元組成一個系統，每個CPU晶元以50 MIPS（每秒百萬指令）的速率運行，那麼整個系統的性能就是500,000 MIPS。而如果單個處理機（即CPU）要達到這一性能，就必須在2×10 秒（2 微微秒，0.002納秒）的時間內執行一條指令，然而沒有一個現存的計算機能接近這個速度，從理論上和工程上考慮都認為能達到這一要求的計算機都是不可能存在的。理論上，愛因斯坦的相對論指出光的傳播速度最快，它能在2 微微秒內傳播0.6毫米。實際上，一個包含於邊長為0.6 毫米大小的立方體內的具有上面所說的計算速度的計算機產生大量的熱量就能將它自己立即熔掉。所以，無論是要以低價格獲得普通的性能還是要以較高的價格獲得極高的性能，分散式系統都能夠滿足。

另一方面，一些作者對分散式系統和并行系統進行了區分。他們認為分散式系統是設計用來允許眾多用戶一起工作的，而并行系統的唯一目標就是以最快的速度完成一個任務，就像 的速度為500,000MIPS的計算機那樣。認為，上述的區別是難以成立的，因為實際上這兩個設計領域是統一的。更願意在最廣泛的意義上使用“分散式系統”一詞來表示任何一個有多個互連的CPU協同工作的系統。

建立分散式系統的另一原因在於一些應用本身是分散式的。一個超級市場連鎖店可能有許多分店，每個商店都需要採購當地生產的商品（可能來自本地的農場）、進行本地銷售，或者要對本地的哪些蔬菜因時間太長或已經腐爛而必須扔掉作出決定。因此，每個商店的本地計算機能明了存貨清單是有意義的，而不是集中於公司總部。畢竟，大多數查詢和更新都是在本地進行的。然而，連鎖超級市場的高層管理者也會不時地想要了解他們還有多少甘藍。實現這一目標的一種途徑就是將整個系統建設成對於應用程序來說就像一台計算機一樣，但是在實現上它是分佈的，像 前面所描述的一個商店有一台機器。這就是一個商業分散式系統。

另一種固有的分散式系統是通常被稱為計算機支持下的協同工作系統（CSCW，Computer Supported Cooperative Work）。在這個系統中，一組相互之間在物理上距離較遠的人員可以一起進行工作，例如，寫出同一份報告。就計算機工業的長期發展趨勢來說，人們可以很容易的想像出一個全新領域--計算機支持的協同遊戲（CSCG：Computer Supported Cooperative Games）。在這個遊戲中，不在同一地方的遊戲者可以實時的玩遊戲。你可以想像，在一個多維迷宮中玩電子捉迷藏，甚至是一起玩一場電子空戰，每個人操縱自己的本地飛行模擬器去試著擊落別的遊戲者，每個遊戲者的屏幕上都顯示出其飛機外的情況，包括其它飛入它的視野的飛機。

同集中式系統相比較，分散式系統的另一個潛在的優勢在於它的高可靠性。通過把工作負載分散到眾多的機器上，單個晶元故障最多只會使一台機器停機，而其它機器不會受任何影響。理想條件下，某一時刻如果有5%的計算機出現故障，系統將仍能繼續工作，只不過損失5%的性能。對於關鍵性的應用，如核反應堆或飛機的控制系統，採用分散式系統來實現主要是考慮到它可以獲得高可靠性。

最後，漸增式的增長方式也是分散式系統優於集中式系統的一個潛在的重要的原因。通常，一個公司會買一台大型主機來完成所有的工作。而當公司繁榮擴充、工作量就會增大，當其增大到某一程度時，這個主機就不能再勝任了。僅有的解決辦法是要麼用更大型的機器（如果有的話）代替現有的大型主機，要麼再增加一台大型主機。這兩種做法都會引起公司運轉混亂。相比較之下，如果採用分散式系統，僅給系統增加一些處理機就可能解決這個問題，而且這也允許系統在需求增長的時候逐漸進行擴充。表1中總結了以上這些優點。

從長遠的角度來看，主要的驅動力將是大量個人計算機的存在和人們共同工作與信息共享的需要，這種信息共享必需是以一種方便的形式進行的，而不受地理或人員、數據，機器的物理分佈的影響。

既然使用微處理機是一種節省開支的辦法，那麼為什麼不給每個人一台個人計算機，讓他們各自獨立地工作呢？一則，許多用戶需要共享數據。例如，機票預訂處的工作人員需要訪問存儲航班以及現有座位信息的主資料庫。假如給每個工作人員都備份整個資料庫，那麼在實際中這是無法工作的，因為沒有人知道其他工作人員已經賣出了哪些座位。共享的數據是上例和許多其它應用的基礎，所以計算機間必須互連。而計算機互連就產生了分散式系統。

共享並不只是僅僅涉及數據。昂貴的外設，例如彩色激光印表機，照相排版機以及大型存儲設備（如自動光碟點唱機）都是共享資源。

把一組孤立的計算機連成一個分散式系統的第三個原因是它可以增強人與人之間的溝通，電子郵件比信件、電話和傳真有更多的誘人之處。它比信件快的多，不像電話需要兩人同時都在，也不像傳真，它所產生的文件可在計算機中進行編輯、重排和存儲，也可以由文本處理程序來處理。

最後，分散式系統可能比給每個用戶一個獨立的計算機更靈活。儘管一種可能的模式是給每個人一台個人計算機並把它們通過LAN聯在一起，但這種方式並不是唯一的。另外還存在一種模式是將個人計算機和共享計算機混合連接在一起（這些機器的型號可能並不完全相同），使工作能夠在最合適的計算機上完成，而並不總是在自己的計算機上完成。這種方式可以使工作負荷能更有效地在計算機系統中進行分配。系統中某些計算機的失效也可以通過使其工作在其它計算機上進行而得到補償。表2總結了以上所介紹的各點。

儘管分散式系統有許多優點，但也有缺點。本節就將指出其中的一些缺點。前面已經提到了最棘手的問題：軟體。就目前的最新技術發展水平，在設計、實現及使用分散式系統上都沒有太多的經驗。什麼樣的操作系統、程序設計語言和應用適合這一系統呢？用戶對分散式系統中分散式處理又應該了解多少呢？系統應當做多少而用戶又應當做多少呢？專家們的觀點不一（這並不是因為專家們與眾不同，而是因為對於分散式系統他們也很少涉及）。隨著更多的研究的進行，這些問題將會逐漸減少。但是不應該低估這個問題。

第二個潛在的問題是通信網路。由於它會損失信息，所以就需要專門的軟體進行恢復。同時，網路還會產生過載。當網路負載趨於飽和時，必須對它進行改造替換或加入另外一個網路擴容。在這兩種情況下，一個或多個建築中的某些部分必須花費很高的費用進行重新布線，或者更換網路介面板（例如用光纖）。一旦系統依賴於網路，那麼網路的信息丟失或飽和將會抵消 通過建立分散式系統所獲得的大部分優勢。

最後，上面 作為優點來描述的數據易於共享性也是具有兩面性的。如果人們能夠很方便地存取整個系統中的數據，那麼他們同樣也能很方便地存取與他們無關的數據。換句話說，經常要考慮系統的安全性問題。通常，對必須絕對保密的數據，使用一個專用的、不與其它任何機器相連的孤立的個人計算機進行存儲的方法更可取。而且這個計算機被保存在一個上鎖的十分安全的房間中，與這台計算相配套的所有軟盤都存放在這個房間中的一個保險箱中。分散式系統的缺點如表3所示。

表 3.分散式系統的缺點

儘管存在這些潛在的問題，許多人還是認為分散式系統的優點多於缺點，並且普遍認為分散式系統在未來幾年中會越來越重要。實際上，在幾年之內許多機構會將他們的大多數計算機連接到大型分散式系統中，為用戶提供更好、更廉價和更方便的服務。而在十年之後，中型或大型商業或其它機構中可能將不再存在一台孤立的計算機了。

分散式系統被用在許多不同類型的應用中。以下列出了一些應用。對這些應用而言，使用分散式系統要比其他體系結構如處理機和共享存儲器多處理機更優越：

原則上，并行應用也可以在共享存儲器多處理機上運行，但共享存儲器系統不能很好地擴大規模以包括大量的處理機。HPCC(高性能計算和通信)應用一般需要一個可伸縮的設計，這種設計取決於分散式處理。

因為每個P E是自治的，所以分散式系統更加可靠。一個單元或資源(軟體或硬體)的故障不影響其他資源的正常功能。

許多應用是固有分散式的。這些應用是突發模式(burstmode)而非批量模式(bulk mode)。這方面的實例有事務處理和Internet Javad,程序。

這些應用的性能取決於吞吐量(事務響應時間J或每秒完成的事務數)而不是一般多處理機所用的執行時間。

對於一組用戶而言，分散式系統有一個特別的應用稱為計算機支持的協同工作(computer supported Cooperati veworking，CSCW)或群件(groupware)，支持用戶協同工作。另一個應用是分散式會議，即通過物理的分散式網路進行電子會議。同樣，多媒體遠程教學也是一個類似的應用。由於在不同的平台上如：Pc、工作站、區域網和廣域網上可獲得非常多樣的應用，用戶希望能超出他fliP c的限制以獲得更廣泛的特十牛、功能和性能。不同網路和環境(包括分散式系統環境)下的q 操作性變得越來越重要。為了達到互操作性，用戶需要一個標準的分散式計算環境，在這個環境里，所有系統和資源都可用。

DCE（分散式計算環境）是OSF （開放系統基金會）開發的分散式計算技術的工業標準集。它提供保護和控制對數據訪問的安全服務、容易尋找分散式資源的名字服務、以及高度可伸縮的模型用於組織極為分散的用戶、服務和數據。D C E可在所有主要的計算平台上運行，並設計成支持異型硬體和軟體環境下的分散式應用。

DCE已經被包括TRANSVARL在內的一些r一商實現。TRANSVARL是最早的多廠商組（multi vendor team）的成員之一，它提出的建議已成為DC E體系結構的基礎。在中可以找到利用DCE開發分散式應用的指南。具有標準介面和協議的系統也叫做開放系統。一些其它標準基於一個特別的模型，比如CORBA （公用對象請求代理程序體系結構），它是由OMG （對象管理組）和多計算機廠商聯盟開發的一個標準。CORBA使用面向對象模型實現分散式系統中的透明服務請求。工業界有自己的標準，比如微軟的分散式構件對象模型（DCOM）和Sun Microsystem公司的Java Beans。

在測試執行過程中，對測試結果的分析是一個需要進行深入思考的重點問題。分散式系統測試的重點在於對後端伺服器集群的測試，而判定系統中是否存在Bug則是 需要解決的重要問題。那麼應該如何確定是否存在Bug呢？

對於測試結果的分析，通常觀察下面幾種情況。

觀察前端應用的返回結果。這裡需要分兩種情況來考慮：第一，按照前端應用業務功能點及流程進行操作，觀察返回結果是否符合業務方的需求預期；第二，操作後端的伺服器（通常是重啟、宕機、斷網等操作），觀察前端應用的返回結果是否符合系統的設計需求。

分析伺服器日誌。在功能測試過程中，當 在啟動伺服器的時候，需要將日誌級別定義為Debug級別（最低級別）。這樣做的主要目的是為了能便於測試工程師來分析日誌和定位問題。為了能更好地定位問題，常常需要在伺服器程序代碼中進行日誌打樁，把程序中的一些重要數據通過日誌的方式展現出來。通常情況下，需要對日誌的格式進行約定，在日誌行中增加一些關鍵字來進行分類，這將便於測試工程師進行日誌分析，也有利於開展分散式系統的自動化測試。另外，值得注意的是，儘可能地將打樁代碼放在Debug代碼中，避免影響系統代碼，引入新問題。

分析操作系統的一些重要信息。測試的分散式系統絕大多數是基於Linux操作系統開發的，在測試的過程中，除了詳細分析程序日誌以外，還需要對操作系統的一些重要數據信息進行分析，從而來診斷伺服器程序是否存在異常。以Linux操作系統為例，常常會使用top命令、netstat命令及sar命令來查看操作系統的一些數據信息。例如，可以通過netstat命令檢查伺服器程序是否正確地監聽了指定的埠等。

藉助其他分析工具。例如，如何判斷伺服器程序是否產生了內存泄漏？通常需要藉助於內存檢測工具來進行分析。在Linux環境下，常用Valgrind來進行內存檢測。這是一款非常好用、功能強大的分析工具，可以幫助測試或者開發工程師快速發現很多隱藏的程序Bug，尤其是在內存檢測方面（同時它還具有很多其他優秀的功能，讀者可以自己查看官網中的使用手冊）。

對於分散式系統而言，壓力測試和性能測試非常重要。在進行壓力測試和性能測試的時候，可能會碰到下面一些難點。

數據準備。如何準備海量的測試數據並保證模擬數據的真實性？以一個分散式的文件系統為例，預先存入100GB的數據還是存入100TB的數據、存入的文件是大小基本一致差別不大還是各不相同甚至差異很大（例如，從幾十位元組至幾十兆位元組不等），這些因素對於分散式系統的性能影響是有很大差異的。另外，如果需要預先存入100TB的數據，若按每秒寫入100MB數據來計算，寫入100TB數據需要100×1024×1024/100=1048576秒=291.27小時=12天。是否能忍受這麼長時間的數據準備工作？為了解決這樣的問題，需要對系統架構設計進行深入分析，設計好測試場景，並提前進行測試用例的設計，以儘早開始準備測試數據。

性能或壓力測試工具。通常來說，分散式系統的測試需要開發一些測試工具來滿足性能測試的需求。如果可以的話，建議這樣的測試工具最好由測試工程師自己來實現，因為測試工程師更清楚自己的測試需求。當需要自己開發測試工具的時候，有兩個關鍵問題需要重點關註：第一，一些關鍵數據的收集方式與計算將成為性能測試工具的關鍵，例如，TPS（每秒請求數）、Throughput（吞吐量）計算的準確性；第二，要保證性能測試工具的性能，如果工具本身的性能不好，將無法給予分散式系統足夠強大的壓力來進行測試。另外，當考慮到多併發（例如有10萬客戶端同時併發連接）時，如果性能測試工具在一台測試機器上只能運行50個或者更少的話，那麼需要的測試機器數量也將會很龐大（例如2000台測試機），這個成本或許是許多公司不能承受的。因此，性能測試工具本身的性能必須要足夠好才能滿足需求、降低測試成本。

自動化測試是測試行業發展的必然趨勢，對於分散式系統測試而言也不例外。在實施分散式系統自動化測試的過程中，可能會碰到下面兩個難點問題。

涉及平台多且硬體雜，測試流程式控制制困難。在實施自動化測試的過程中，測試腳本需要控制的操作系統和應用程序很多，而且存在跨平台的特性，同時還有可能需要控制一些網路設備。因此，選擇一個優秀的自動化測試框架成為了非常重要的工作之一。以 的實踐經驗來看，STAF是一個不錯的選擇，它的平台（Windows及Linux各版本）支持及開發語言的支持都很全面。

測試結果驗證複雜。對於分散式系統的自動化測試來說，需要通過測試腳本來收集各種測試結果數據以驗證測試結果的正確性。在實施自動化測試的過程中，可以將測試結果數據收集部分模塊化，通過各子模塊來檢測各項數據是否正確。例如，會設計一個日誌分析模塊，主要負責從伺服器應用程序的日誌中收集相應數據進行對比驗證（本文前面提到的在打樁日誌中增加關鍵字部分就顯得格外重要）。

隨著網際網路的發展，大型分散式系統也越來越多、越來越複雜、越來越重要。如何有效地保證大型分散式系統7×24小時全天候持續穩定地運行也就成為了一個重要課題。

分散式計算機系統與計算機網路既有類似之處又有不同點，其主要的異同如下：

(1)在計算機網路中，每個用戶或任務通常只使用一台計算機，若要利用網路中的另一台計算機，則需要遠程註冊。在分散式計算機系統中，用戶進程在系統內各個計算機上動態調度，並根據運行情況由分散式操作系統動態地、透明地將機器分配給用戶進程或任務。

(2)在計算機網路中，用戶知道它們的文件存放在何處，並用顯示的文件傳輸命令在機器之間傳送文件。在分散式計算機系統中，文件的放置由操作系統管理，用戶可用相同方式訪問系統中的所有文件而不管它們位於何處。

(3)在計算機網路中，各結點計算機均有自己的操作系統，資源歸局部所有並被局部控制，網路內的進程調度是通過進程遷移和數據遷移實現的。在分散式計算機系統中，每個場點上運行一個局部操作系統，執行的任務可以是獨立的，可以是某任務的一個部分，也可以是其他場點上的(部分)任務，且各場點相互協同，合作平衡系統內的負載。

(4)在計算機網路中，系統幾乎無容錯能力。在分散式計算機系統中有系統自動重構、適度降級使用及錯誤恢復功能。

(5徠)兩者透明性的程度和級別不同。

(6)就資源共享而言，計算機網路和分散式計算機系統是類似的。

雖然分散式系統具有很多優點，然而由於分散式系統自身的特點及應用環境的複雜性，分散式系統設計有如下的很多難題需要解決:

1.部分失效問題

由於分散式系統通常由若干部分組成，各個部分由於各種原因可能發生故障，如硬體故障、軟體錯誤及錯誤操作等。如果一個分散式系統不對這些故障進行有效的處理，系統某一組成部分的故障可能導致整個系統的癱瘓。

2.性能和可靠性過分依賴於網路

由於分散式系統是建立在網路之上的，而網路本身是不可靠的，可能經常發生故障，網路故障可能導致系統服務的終止。另外，網路超負荷會導致性能的降低，增加系統的響應時間。

3.缺乏統一控制

一個分散式系統的控制通常是一個典型的分散控制，沒有統一的中心控制。因此，分散式系統通常需要相應的同步機制來協調系統中各個部分的工作。設計與實現一個對用戶來說是透明的且具有容錯能力的分散式系統是一項具有挑戰性的工作，而且所需的機制和策略尚未成熟。因此什麼樣的程序設計模型、什麼樣的控制機制最適合分散式系統仍是需要繼續研究的課題。

4.難以合理設計資源分配策略

在集中式系統中，所有的資源都由操作系統管理和分配，但在分散式系統中，資源屬於各節點，所以調度的靈活性不如集中式系統，資源的物理分佈可能與用戶請求的分佈不匹配，某些資源可能空閑，而另一些資源可能超載。

5.安全保密性問題

開放性使得分散式系統中的許多軟體介面都提供給用戶，這樣的開放式結構對於開發人員非常有價值，但同時也為破壞者打開了方便之門。

針對分散式系統存在的上述難點，要保證一個分散式系統的正常運行，就必須對系統資源進行有效的管理，對計算機之間的通信、故障、安全等問題提供有效的處理手段和支持機制。

用戶對分散式系統的要求是透明性、安全性、靈活性、簡單性、可靠性，也要求方便在局部失效時重構系統，以及集成不均勻子系統的能力。

資源的分佈性、缺乏全局狀態信息及傳輸延遲，意味著集中式操作系統的某些方法和技術不能應用於分散式系統中。即使集中式系統中的某些技術滿足上面的要求，其實現通常也是要付出很大代價的。