新聞中心
通過接受挑戰(zhàn)并將其納入您的設(shè)計(jì)中,您可以獲得分布式系統(tǒng)的真正好處。讓我們一一看看這些挑戰(zhàn)。

創(chuàng)新互聯(lián)建站專業(yè)為企業(yè)提供紅橋網(wǎng)站建設(shè)、紅橋做網(wǎng)站、紅橋網(wǎng)站設(shè)計(jì)、紅橋網(wǎng)站制作等企業(yè)網(wǎng)站建設(shè)、網(wǎng)頁設(shè)計(jì)與制作、紅橋企業(yè)網(wǎng)站模板建站服務(wù),十余年紅橋做網(wǎng)站經(jīng)驗(yàn),不只是建網(wǎng)站,更提供有價(jià)值的思路和整體網(wǎng)絡(luò)服務(wù)。
如今,分布式系統(tǒng)風(fēng)靡一時(shí)。
每當(dāng)我訪問 Internet 上的技術(shù)出版物時(shí),我通常會(huì)發(fā)現(xiàn)一大堆關(guān)于分布式系統(tǒng)的好處的帖子。每個(gè)人似乎都對分布式系統(tǒng)的一般概念及其帶來的表面優(yōu)勢著迷。
雖然創(chuàng)建可以幫助人們學(xué)習(xí)的信息內(nèi)容沒有壞處,但我發(fā)現(xiàn)很多時(shí)候分布式應(yīng)用程序被設(shè)計(jì)為易于構(gòu)建的東西。
然而,現(xiàn)實(shí)卻大不相同。
構(gòu)建和運(yùn)行分布式系統(tǒng)很困難。否則不要讓別人告訴你。
創(chuàng)建分布式系統(tǒng)的任務(wù)充滿挑戰(zhàn)。具有諷刺意味的是,許多挑戰(zhàn)源于使這些系統(tǒng)首先具有吸引力的好處。在嘗試構(gòu)建分布式系統(tǒng)時(shí),您不應(yīng)忽視這些挑戰(zhàn)。如果你這樣做,你最終會(huì)陷入麻煩的世界。
但是,如果您接受這些挑戰(zhàn)并將它們納入您的設(shè)計(jì)中,您就可以獲得分布式系統(tǒng)的真正好處。讓我們一一看看這些挑戰(zhàn)。
溝通
分布式系統(tǒng)是分布式的。
多個(gè)節(jié)點(diǎn)??赡苁堑乩砩戏珠_的。
沒有其各個(gè)節(jié)點(diǎn)之間的通信,任何分布式系統(tǒng)都無法運(yùn)行。
即使是在 Web 瀏覽器中瀏覽網(wǎng)站這一看似簡單的任務(wù),也需要不同進(jìn)程之間進(jìn)行大量通信。
當(dāng)我們訪問一個(gè) URL 時(shí),我們的瀏覽器會(huì)聯(lián)系 DNS 來解析該 URL 的服務(wù)器地址。一旦獲得地址,它就會(huì)通過網(wǎng)絡(luò)向服務(wù)器發(fā)送 HTTP 請求。服務(wù)器處理請求并發(fā)回響應(yīng)。
系統(tǒng)設(shè)計(jì)者應(yīng)該問幾個(gè)關(guān)于通信方面的重要問題:
- 請求和響應(yīng)消息是如何通過網(wǎng)絡(luò)表示的?
- 在網(wǎng)絡(luò)中斷的情況下會(huì)發(fā)生什么?
- 我們?nèi)绾伪WC安全免受窺探?
我們可以通過退回到 TCP 和 HTTPS 等抽象來應(yīng)對其中的許多通信挑戰(zhàn)。
但是,抽象可能會(huì)泄漏。例如,TCP 試圖提供底層不可靠網(wǎng)絡(luò)的完整抽象。但如果網(wǎng)絡(luò)電纜被切斷或過載,TCP 將無能為力。當(dāng)這種情況發(fā)生時(shí),挑戰(zhàn)就落到了系統(tǒng)設(shè)計(jì)者身上。
協(xié)調(diào)
想象一下,有兩位將軍和他們各自的軍隊(duì)。他們需要相互配合才能同時(shí)進(jìn)攻一座城市。只有同時(shí)進(jìn)攻,才能攻下城池。為此,他們需要就攻擊時(shí)間達(dá)成一致。
由于軍隊(duì)在地理上是分開的,將軍們只能通過派遣使者來進(jìn)行交流。不幸的是,信使必須穿過敵人的領(lǐng)土并可能被俘虜。
兩位將軍怎么能就進(jìn)攻時(shí)間達(dá)成一致呢?
他們中的一個(gè)可以通過發(fā)送信使并等待響應(yīng)來向另一個(gè)建議時(shí)間。但是,如果沒有響應(yīng)怎么辦?會(huì)不會(huì)是信使被抓了?信使會(huì)不會(huì)受傷并且需要比預(yù)期更長的時(shí)間?將軍應(yīng)該再派一個(gè)使者嗎?
這個(gè)問題不是微不足道的。
無論派出多少使者,兩位將軍都不能確定對方軍隊(duì)會(huì)在正確的時(shí)間攻城。派遣更多的使者可以增加協(xié)調(diào)成功的機(jī)會(huì),但機(jī)會(huì)永遠(yuǎn)不會(huì)達(dá)到 100%。
在分布式系統(tǒng)的上下文中,這個(gè)問題被稱為二一般問題。將軍就像分布式系統(tǒng)中的節(jié)點(diǎn)。為了使系統(tǒng)工作,節(jié)點(diǎn)應(yīng)該相互協(xié)調(diào)。但是,節(jié)點(diǎn)隨時(shí)可能因故障而失效。
在開始時(shí),每個(gè)開發(fā)人員都覺得他們將構(gòu)建一個(gè)無故障的系統(tǒng)。我以前也是這么想的。當(dāng)然,這是一種天真的追求,注定要失敗。您無法構(gòu)建一個(gè)完全沒有錯(cuò)誤的系統(tǒng)。分布式系統(tǒng)越大,出現(xiàn)故障的概率就越高。盡管存在一個(gè)或多個(gè)故障,容錯(cuò)系統(tǒng)仍可以繼續(xù)運(yùn)行。訣竅是使系統(tǒng)中的節(jié)點(diǎn)在出現(xiàn)故障時(shí)相互協(xié)調(diào)。
可擴(kuò)展性
在構(gòu)建分布式系統(tǒng)時(shí),可伸縮性通常會(huì)引起系統(tǒng)設(shè)計(jì)人員的最大關(guān)注。
在基本層面上,可伸縮性是衡量系統(tǒng)性能隨負(fù)載增加的指標(biāo)。
但是我們?nèi)绾魏饬糠植际较到y(tǒng)的性能和負(fù)載呢?
- 對于性能,我們可以使用兩個(gè)優(yōu)秀的參數(shù):吞吐量和響應(yīng)時(shí)間。吞吐量表示每秒處理的操作數(shù)。響應(yīng)時(shí)間是客戶端請求和響應(yīng)之間經(jīng)過的總時(shí)間。
- 系統(tǒng)負(fù)載的測量更具體到系統(tǒng)用例。例如,系統(tǒng)負(fù)載可以通過并發(fā)用戶數(shù)、通信鏈路或?qū)懭肱c讀取的比率來衡量。
性能和負(fù)載本質(zhì)上是相互關(guān)聯(lián)的。隨著負(fù)載的增加,最終會(huì)達(dá)到系統(tǒng)的容量。容量可能取決于系統(tǒng)的物理限制,例如:
- 節(jié)點(diǎn)的內(nèi)存大小或時(shí)鐘周期
- 網(wǎng)絡(luò)鏈路的帶寬和延遲
當(dāng)負(fù)載達(dá)到容量時(shí),系統(tǒng)的性能要么停滯不前,要么惡化。
如果系統(tǒng)上的負(fù)載繼續(xù)增長超過容量,它最終會(huì)達(dá)到大多數(shù)操作失敗或超時(shí)的程度。吞吐量下降,響應(yīng)時(shí)間猛增。此時(shí),系統(tǒng)不再具有可擴(kuò)展性。請參見下圖,該圖顯示了這種情況。
我們?nèi)绾问瓜到y(tǒng)具有可擴(kuò)展性?
如果負(fù)載超出容量是導(dǎo)致性能下降的原因,我們可以通過增加容量來使系統(tǒng)具有可擴(kuò)展性。增加容量的一種快速簡便的方法是購買具有更好性能指標(biāo)的更昂貴的硬件。這種方法稱為放大。
盡管在紙面上聽起來不錯(cuò),但這種方法遲早會(huì)碰壁。
更可持續(xù)的方法是通過向系統(tǒng)添加更多機(jī)器來進(jìn)行擴(kuò)展。
如果您有興趣,我還對分布式系統(tǒng)中的可擴(kuò)展性有更詳細(xì)的了解。
彈性
故障在分布式系統(tǒng)中很常見。有幾個(gè)原因:
- 首先,向外擴(kuò)展會(huì)增加失敗的可能性。由于系統(tǒng)中的每個(gè)組件都有發(fā)生故障的內(nèi)在概率,因此添加更多部件會(huì)增加總體故障概率。
- 其次,更多的組件意味著更多的操作。這增加了系統(tǒng)中故障的絕對數(shù)量。
- 最后,失敗不是獨(dú)立的。一個(gè)組件的故障會(huì)增加其他組件發(fā)生故障的可能性。
當(dāng)系統(tǒng)大規(guī)模運(yùn)行時(shí),任何可能發(fā)生的故障最終都會(huì)發(fā)生。理想的分布式系統(tǒng)必須接受故障并以彈性方式運(yùn)行。當(dāng)一個(gè)系統(tǒng)即使在發(fā)生故障時(shí)也能繼續(xù)工作時(shí),就被認(rèn)為是有彈性的。
我們可以使用多種技術(shù)(例如冗余和自我修復(fù)機(jī)制)來提高系統(tǒng)的彈性。然而,這不是零和游戲。沒有分布式系統(tǒng)可以 100% 有彈性。在某些時(shí)候,故障會(huì)削弱系統(tǒng)的可用性。
可用性是一個(gè)重要指標(biāo)。它是應(yīng)用程序可以為請求提供服務(wù)的時(shí)間除以測量的持續(xù)時(shí)間。
組織通常使用 9 的概念以百分比形式推銷其系統(tǒng)的可用性。三個(gè)九 (99.9%) 通常被認(rèn)為對大量系統(tǒng)來說是可以接受的。任何超過四個(gè)九 (99.99%) 的東西都是高可用的。關(guān)鍵任務(wù)系統(tǒng)可能需要更多的 9。
這是一個(gè)方便的圖表,它展示了實(shí)際停機(jī)時(shí)間的可用性百分比。
操作
在所有其他挑戰(zhàn)中,操作分布式系統(tǒng)可能是最困難的。但我也看到了這一領(lǐng)域發(fā)生的最重要的創(chuàng)新。就像任何其他軟件系統(tǒng)一樣,分布式系統(tǒng)也需要經(jīng)歷開發(fā)、測試、部署和運(yùn)行的軟件開發(fā)生命周期。
然而,過去由兩個(gè)獨(dú)立的團(tuán)隊(duì)或部門來開發(fā)和操作軟件的日子已經(jīng)一去不復(fù)返了。分布式系統(tǒng)的復(fù)雜性催生了DevOps?,F(xiàn)在,設(shè)計(jì)和開發(fā)系統(tǒng)的同一個(gè)團(tuán)隊(duì)有望在生產(chǎn)環(huán)境中運(yùn)行它。這給開發(fā)團(tuán)隊(duì)帶來了一些他們之前忽略的困難。
- 需要以安全的方式不斷推出新的部署。
- 系統(tǒng)需要是可觀察的。
- 當(dāng)服務(wù)水平目標(biāo)有被破壞的風(fēng)險(xiǎn)時(shí),需要發(fā)出警報(bào)。
這種變化也有積極的一面。對于開發(fā)人員來說,沒有比提供隨叫隨到的支持更好的方法來找出系統(tǒng)的不足之處了。只要確保為破壞你的周末而得到適當(dāng)?shù)膱?bào)酬!
結(jié)論
構(gòu)建分布式系統(tǒng)并非易事。它充滿了圍繞通信、協(xié)調(diào)、可擴(kuò)展性、彈性和 運(yùn)營領(lǐng)域的多重挑戰(zhàn)。但解決這些挑戰(zhàn)是有益的。當(dāng)分布式系統(tǒng)按計(jì)劃工作時(shí),它會(huì)創(chuàng)造出一種特殊的組件舞蹈,令人賞心悅目。
當(dāng)前標(biāo)題:構(gòu)建分布式系統(tǒng)的五個(gè)挑戰(zhàn)
鏈接地址:http://m.fisionsoft.com.cn/article/dhegeoj.html


咨詢
建站咨詢
