在一個分布式系統中,一組獨立的計算機展現給使用者的是一個統一的整體,就好像是一個系統似的。系統擁有多種通用的實體和邏輯資源,可以動态的配置設定任務,分散的實體和邏輯資源通過計算機網絡實作資訊交換。系統中存在一個以全局的方式管理計算機資源的分布式作業系統。通常,對使用者來說,分布式系統隻有一個模型或範型。在作業系統之上有一層軟體中間件(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在内的一些廠商實作。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-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中總結了以上這些優點。
項目 | 描述 |
經濟 | 微處理機提供了比大型主機更好的性能價格比 |
速度 | 分布式系統總的計算能力比單個大型主機更強 |
固有的分布性 | 一些應用涉及到空間上分散的機器 |
可靠性 | 如果一個機器崩潰,整個系統還可以運轉 |
漸增 | 計算能力可以逐漸有所增加 |
從長遠的角度來看,主要的驅動力将是大量個人計算機的存在和人們共同工作與資訊共享的需要,這種資訊共享必需是以一種友善的形式進行的,而不受地理或人員、資料,機器的實體分布的影響。
與獨立PC比較
既然使用微處理機是一種節省開支的辦法,那麼為什麼不給每個人一台個人計算機,讓他們各自獨立地工作呢?一則,許多使用者需要共享資料。例如,機票預訂處的從業人員需要通路存儲航班以及現有座位資訊的主資料庫。假如給每個從業人員都備份整個資料庫,那麼在實際中這是無法工作的,因為沒有人知道其他從業人員已經賣出了哪些座位。共享的資料是上例和許多其它應用的基礎,是以計算機間必須互連。而計算機互連就産生了分布式系統。
共享并不隻是僅僅涉及資料。昂貴的外設,例如彩色雷射列印機,照相排版機以及大型儲存設備(如自動CD光牒點唱機)都是共享資源。
把一組孤立的計算機連成一個分布式系統的第三個原因是它可以增強人與人之間的溝通,電子郵件比信件、電話和傳真有更多的誘人之處。它比信件快的多,不像電話需要兩人同時都在,也不像傳真,它所産生的檔案可在計算機中進行編輯、重排和存儲,也可以由文本處理程式來處理。
最後,分布式系統可能比給每個使用者一個獨立的計算機更靈活。盡管一種可能的模式是給每個人一台個人計算機并把它們通過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小時全天候持續穩定地運作也就成為了一個重要課題。
源:
https://baike.baidu.com/item/%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F/4905336?fr=aladdin