優點
相比較而言的優點
系統傾向于分布式發展潮流的真正驅動力是經濟。25年前，計算機權威和評論家HerbGrosch指出CPU的計算能力與它的價格的平方成正比，後來成為Grosch定理。也就是說如果你付出兩倍的價錢，就能獲得四倍的性能。這一論斷與當時的大型機技術非常吻合，因而使得許多機構都盡其所能購買最大的單個大型機。以分布式系統在數據庫方面應用的優勢和在網絡方面的漏洞及其對應措施為中心,深入探讨了分布式系統的工作原理,研究對比了分布式系統和其它系統的性能差異,同時在理論上分析了分布式系統受到攻擊的危害性。
随着微處理機技術的發展，Grosch定理不再适用了。到了二十一世紀初期，人們隻需花幾百美元就能買到一個CPU芯片，這個芯片每秒鐘執行的指令比80年代最大的大型機的處理機每秒鐘所執行的指令還多。如果你願意付出兩倍的價錢，将得到同樣的CPU，但它卻以更高的時鐘速率運行。因此，最節約成本的辦法通常是在一個系統中使用集中在一起的大量的廉價CPU。所以，傾向于分布式系統的主要原因是它可以潛在地得到比單個的大型集中式系統好得多的性價比。實際上，分布式系統是通過較低廉的價格來實現相似的性能的。
另一方面，一些作者對分布式系統和并行系統進行了區分。他們認為分布式系統是設計用來允許衆多用戶一起工作的，而并行系統的唯一目标就是以最快的速度完成一個任務，就像我們的速度為500,000MIPS的計算機那樣。我們認為，上述的區别是難以成立的，因為實際上這兩個設計領域是統一的。我們更願意在最廣泛的意義上使用“分布式系統”一詞來表示任何一個有多個互連的CPU協同工作的系統。
同集中式系統相比較，分布式系統的另一個潛在的優勢在于它的高可靠性。通過把工作負載分散到衆多的機器上，單個芯片故障最多隻會使一台機器停機，而其它機器不會受任何影響。理想條件下，某一時刻如果有5%的計算機出現故障，系統将仍能繼續工作，隻不過損失5%的性能。對于關鍵性的應用，如核反應堆或飛機的控制系統，采用分布式系統來實現主要是考慮到它可以獲得高可靠性。
最後，漸增式的增長方式也是分布式系統優于集中式系統的一個潛在的重要的原因。通常，一個公司會買一台大型主機來完成所有的工作。而當公司繁榮擴充、工作量就會增大，當其增大到某一程度時，這個主機就不能再勝任了。僅有的解決辦法是要麼用更大型的機器（如果有的話）代替現有的大型主機，要麼再增加一台大型主機。這兩種作法都會引起公司運轉混亂。相比較之下，如果采用分布式系統，僅給系統增加一些處理機就可能解決這個問題，而且這也允許系統在需求增長的時候逐漸進行擴充。表1-1中總結了以上這些優點。
從長遠的角度來看，主要的驅動力将是大量個人計算機的存在和人們共同工作與信息共享的需要，這種信息共享必需是以一種方便的形式進行的，而不受地理或人員、數據，機器的物理分布的影響。
與獨立PC機相比較的優點
既然使用微處理機是一種節省開支的辦法，那麼為什麼不給每個人一台個人計算機，讓他們各自獨立地工作呢？一則，許多用戶需要共享數據。例如，機票預訂處的工作人員需要訪問存儲航班以及現有座位信息的主數據庫。假如給每個工作人員都備份整個數據庫，那麼在實際中這是無法工作的，因為沒有人知道其他工作人員已經賣出了哪些座位。共享的數據是上例和許多其它應用的基礎，所以計算機間必須互連。而計算機互連就産生了分布式系統。
共享并不隻是僅僅涉及數據。昂貴的外設，例如彩色激光打印機，照相排版機以及大型存儲設備（如自動光盤點唱機）都是共享資源。
把一組孤立的計算機連成一個分布式系統的第三個原因是它可以增強人與人之間的溝通，電子郵件比信件、電話和傳真有更多的誘人之處。它比信件快的多，不像電話需要兩人同時都在，也不像傳真，它所産生的文件可在計算機中進行編輯、重排和存儲，也可以由文本處理程序來處理。
最後，分布式系統可能比給每個用戶一個獨立的計算機更靈活。盡管一種可能的模式是給每個人一台個人計算機并把它們通過LAN聯在一起，但這種方式并不是唯一的。另外還存在一種模式是将個人計算機和共享計算機混合連接在一起（這些機器的型号可能并不完全相同），使工作能夠在最合适的計算機上完成，而并不總是在自己的計算機上完成。這種方式可以使工作負荷能更有效地在計算機系統中進行分配。系統中某些計算機的失效也可以通過使其工作在其它計算機上進行而得到補償。表1-2總結了以上所介紹的各點。
測試
在測試執行過程中，對測試結果的分析是一個需要進行深入思考的重點問題。分布式系統測試的重點在于對後端服務器集群的測試，而判定系統中是否存在Bug則是我們需要解決的重要問題。那麼應該如何确定是否存在Bug呢？
對于測試結果的分析，我們通常觀察下面幾種情況。
觀察前端應用的返回結果。這裡需要分兩種情況來考慮：第一，按照前端應用業務功能點及流程進行操作，觀察返回結果是否符合業務方的需求預期；第二，操作後端的服務器（通常是重啟、宕機、斷網等操作），觀察前端應用的返回結果是否符合系統的設計需求。
分析服務器日志。在功能測試過程中，當我們在啟動服務器的時候，需要将日志級别定義為Debug級别（最低級别）。這樣做的主要目的是為了能便于測試工程師來分析日志和定位問題。為了能更好地定位問題，常常需要在服務器程序代碼中進行日志打樁，把程序中的一些重要數據通過日志的方式展現出來。通常情況下，我們需要對日志的格式進行約定，在日志行中增加一些關鍵字來進行分類，這将便于測試工程師進行日志分析，也有利于開展分布式系統的自動化測試。另外，值得注意的是，我們盡可能地将打樁代碼放在Debug代碼中，避免影響系統代碼，引入新問題。
分析操作系統的一些重要信息。我們測試的分布式系統絕大多數是基于Linux操作系統開發的，在測試的過程中，除了詳細分析程序日志以外，還需要對操作系統的一些重要數據信息進行分析，從而來診斷服務器程序是否存在異常。以Linux操作系統為例，我們常常會使用top命令、netstat命令及sar命令來查看操作系統的一些數據信息。例如，可以通過netstat命令檢查服務器程序是否正确地監聽了指定的端口等。
借助其他分析工具。例如，如何判斷服務器程序是否産生了内存洩漏？通常需要借助于内存檢測工具來進行分析。在Linux環境下，我們常用Valgrind來進行内存檢測。這是一款非常好用、功能強大的分析工具，可以幫助測試或者開發工程師快速發現很多隐藏的程序Bug，尤其是在内存檢測方面（同時它還具有很多其他優秀的功能，讀者可以自己查看官網中的使用手冊）。
壓力測試與性能測試
對于分布式系統而言，壓力測試和性能測試非常重要。在進行壓力測試和性能測試的時候，可能會碰到下面一些難點。
自動化測試
自動化測試是測試行業發展的必然趨勢，對于分布式系統測試而言也不例外。在實施分布式系統自動化測試的過程中，我們可能會碰到下面兩個難點問題。
涉及平台多且硬件雜，測試流程控制困難。在實施自動化測試的過程中，測試腳本需要控制的操作系統和應用程序很多，而且存在跨平台的特性，同時還有可能需要控制一些網絡設備。因此，選擇一個優秀的自動化測試框架成為了非常重要的工作之一。以我們的實踐經驗來看，STAF是一個不錯的選擇，它的平台（Windows及Linux各版本）支持及開發語言的支持都很全面。
測試結果驗證複雜。對于分布式系統的自動化測試來說，我們需要通過測試腳本來收集各種測試結果數據以驗證測試結果的正确性。在實施自動化測試的過程中，我們可以将測試結果數據收集部分模塊化，通過各子模塊來檢測各項數據是否正确。例如，我們會設計一個日志分析模塊，主要負責從服務器應用程序的日志中收集相應數據進行對比驗證（本文前面提到的在打樁日志中增加關鍵字部分就顯得格外重要）。
随着互聯網的發展，大型分布式系統也越來越多、越來越複雜、越來越重要。如何有效地保證大型分布式系統7×24小時全天候持續穩定地運行也就成為了一個重要課題。
