分佈系統

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

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

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

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

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

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

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

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

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

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

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

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

分佈系統

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

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

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

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

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

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

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

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

分佈系統

表 1-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小時全天候持續穩定地運行也就成為了一個重要課題。