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

如今，分布式系統(tǒng)風靡一時。

每當我訪問 Internet 上的技術(shù)出版物時，我通常會發(fā)現(xiàn)一大堆關(guān)于分布式系統(tǒng)的好處的帖子。每個人似乎都對分布式系統(tǒng)的一般概念及其帶來的表面優(yōu)勢著迷。

雖然創(chuàng)建可以幫助人們學習的信息內(nèi)容沒有壞處，但我發(fā)現(xiàn)很多時候分布式應用程序被設(shè)計為易于構(gòu)建的東西。

然而，現(xiàn)實卻大不相同。

構(gòu)建和運行分布式系統(tǒng)很困難。否則不要讓別人告訴你。

創(chuàng)建分布式系統(tǒng)的任務(wù)充滿挑戰(zhàn)。具有諷刺意味的是，許多挑戰(zhàn)源于使這些系統(tǒng)首先具有吸引力的好處。在嘗試構(gòu)建分布式系統(tǒng)時，您不應忽視這些挑戰(zhàn)。如果你這樣做，你最終會陷入麻煩的世界。

但是，如果您接受這些挑戰(zhàn)并將它們納入您的設(shè)計中，您就可以獲得分布式系統(tǒng)的真正好處。讓我們一一看看這些挑戰(zhàn)。

溝通

分布式系統(tǒng)是分布式的。

多個節(jié)點。可能是地理上分開的。

沒有其各個節(jié)點之間的通信，任何分布式系統(tǒng)都無法運行。

即使是在 Web 瀏覽器中瀏覽網(wǎng)站這一看似簡單的任務(wù)，也需要不同進程之間進行大量通信。

當我們訪問一個 URL 時，我們的瀏覽器會聯(lián)系 DNS 來解析該 URL 的服務(wù)器地址。一旦獲得地址，它就會通過網(wǎng)絡(luò)向服務(wù)器發(fā)送 HTTP 請求。服務(wù)器處理請求并發(fā)回響應。

系統(tǒng)設(shè)計者應該問幾個關(guān)于通信方面的重要問題：

• 請求和響應消息是如何通過網(wǎng)絡(luò)表示的?
• 在網(wǎng)絡(luò)中斷的情況下會發(fā)生什么?
• 我們?nèi)绾伪ＷC安全免受窺探?

我們可以通過退回到 TCP 和 HTTPS 等抽象來應對其中的許多通信挑戰(zhàn)。

但是，抽象可能會泄漏。例如，TCP 試圖提供底層不可靠網(wǎng)絡(luò)的完整抽象。但如果網(wǎng)絡(luò)電纜被切斷或過載，TCP 將無能為力。當這種情況發(fā)生時，挑戰(zhàn)就落到了系統(tǒng)設(shè)計者身上。

協(xié)調(diào)

想象一下，有兩位將軍和他們各自的軍隊。他們需要相互配合才能同時進攻一座城市。只有同時進攻，才能攻下城池。為此，他們需要就攻擊時間達成一致。

由于軍隊在地理上是分開的，將軍們只能通過派遣使者來進行交流。不幸的是，信使必須穿過敵人的領(lǐng)土并可能被俘虜。

兩位將軍怎么能就進攻時間達成一致呢?

他們中的一個可以通過發(fā)送信使并等待響應來向另一個建議時間。但是，如果沒有響應怎么辦?會不會是信使被抓了?信使會不會受傷并且需要比預期更長的時間?將軍應該再派一個使者嗎?

這個問題不是微不足道的。

無論派出多少使者，兩位將軍都不能確定對方軍隊會在正確的時間攻城。派遣更多的使者可以增加協(xié)調(diào)成功的機會，但機會永遠不會達到 100%。

在分布式系統(tǒng)的上下文中，這個問題被稱為二一般問題。將軍就像分布式系統(tǒng)中的節(jié)點。為了使系統(tǒng)工作，節(jié)點應該相互協(xié)調(diào)。但是，節(jié)點隨時可能因故障而失效。

在開始時，每個開發(fā)人員都覺得他們將構(gòu)建一個無故障的系統(tǒng)。我以前也是這么想的。當然，這是一種天真的追求，注定要失敗。您無法構(gòu)建一個完全沒有錯誤的系統(tǒng)。分布式系統(tǒng)越大，出現(xiàn)故障的概率就越高。盡管存在一個或多個故障，容錯系統(tǒng)仍可以繼續(xù)運行。訣竅是使系統(tǒng)中的節(jié)點在出現(xiàn)故障時相互協(xié)調(diào)。

可擴展性

在構(gòu)建分布式系統(tǒng)時，可伸縮性通常會引起系統(tǒng)設(shè)計人員的最大關(guān)注。

在基本層面上，可伸縮性是衡量系統(tǒng)性能隨負載增加的指標。

但是我們?nèi)绾魏饬糠植际较到y(tǒng)的性能和負載呢?

• 對于性能，我們可以使用兩個優(yōu)秀的參數(shù)：吞吐量和響應時間。吞吐量表示每秒處理的操作數(shù)。響應時間是客戶端請求和響應之間經(jīng)過的總時間。
• 系統(tǒng)負載的測量更具體到系統(tǒng)用例。例如，系統(tǒng)負載可以通過并發(fā)用戶數(shù)、通信鏈路或?qū)懭肱c讀取的比率來衡量。

性能和負載本質(zhì)上是相互關(guān)聯(lián)的。隨著負載的增加，最終會達到系統(tǒng)的容量。容量可能取決于系統(tǒng)的物理限制，例如：

• 節(jié)點的內(nèi)存大小或時鐘周期
• 網(wǎng)絡(luò)鏈路的帶寬和延遲

當負載達到容量時，系統(tǒng)的性能要么停滯不前，要么惡化。

如果系統(tǒng)上的負載繼續(xù)增長超過容量，它最終會達到大多數(shù)操作失敗或超時的程度。吞吐量下降，響應時間猛增。此時，系統(tǒng)不再具有可擴展性。請參見下圖，該圖顯示了這種情況。

我們?nèi)绾问瓜到y(tǒng)具有可擴展性?

如果負載超出容量是導致性能下降的原因，我們可以通過增加容量來使系統(tǒng)具有可擴展性。增加容量的一種快速簡便的方法是購買具有更好性能指標的更昂貴的硬件。這種方法稱為放大。

盡管在紙面上聽起來不錯，但這種方法遲早會碰壁。

更可持續(xù)的方法是通過向系統(tǒng)添加更多機器來進行擴展。

如果您有興趣，我還對分布式系統(tǒng)中的可擴展性有更詳細的了解。

彈性

故障在分布式系統(tǒng)中很常見。有幾個原因：

• 首先，向外擴展會增加失敗的可能性。由于系統(tǒng)中的每個組件都有發(fā)生故障的內(nèi)在概率，因此添加更多部件會增加總體故障概率。
• 其次，更多的組件意味著更多的操作。這增加了系統(tǒng)中故障的絕對數(shù)量。
• 最后，失敗不是獨立的。一個組件的故障會增加其他組件發(fā)生故障的可能性。

當系統(tǒng)大規(guī)模運行時，任何可能發(fā)生的故障最終都會發(fā)生。理想的分布式系統(tǒng)必須接受故障并以彈性方式運行。當一個系統(tǒng)即使在發(fā)生故障時也能繼續(xù)工作時，就被認為是有彈性的。

我們可以使用多種技術(shù)(例如冗余和自我修復機制)來提高系統(tǒng)的彈性。然而，這不是零和游戲。沒有分布式系統(tǒng)可以 100% 有彈性。在某些時候，故障會削弱系統(tǒng)的可用性。

可用性是一個重要指標。它是應用程序可以為請求提供服務(wù)的時間除以測量的持續(xù)時間。

組織通常使用 9 的概念以百分比形式推銷其系統(tǒng)的可用性。三個九 (99.9%) 通常被認為對大量系統(tǒng)來說是可以接受的。任何超過四個九 (99.99%) 的東西都是高可用的。關(guān)鍵任務(wù)系統(tǒng)可能需要更多的 9。

這是一個方便的圖表，它展示了實際停機時間的可用性百分比。

操作

在所有其他挑戰(zhàn)中，操作分布式系統(tǒng)可能是最困難的。但我也看到了這一領(lǐng)域發(fā)生的最重要的創(chuàng)新。就像任何其他軟件系統(tǒng)一樣，分布式系統(tǒng)也需要經(jīng)歷開發(fā)、測試、部署和運行的軟件開發(fā)生命周期。

然而，過去由兩個獨立的團隊或部門來開發(fā)和操作軟件的日子已經(jīng)一去不復返了。分布式系統(tǒng)的復雜性催生了DevOps。現(xiàn)在，設(shè)計和開發(fā)系統(tǒng)的同一個團隊有望在生產(chǎn)環(huán)境中運行它。這給開發(fā)團隊帶來了一些他們之前忽略的困難。

• 需要以安全的方式不斷推出新的部署。
• 系統(tǒng)需要是可觀察的。
• 當服務(wù)水平目標有被破壞的風險時，需要發(fā)出警報。

這種變化也有積極的一面。對于開發(fā)人員來說，沒有比提供隨叫隨到的支持更好的方法來找出系統(tǒng)的不足之處了。只要確保為破壞你的周末而得到適當?shù)膱蟪?

結(jié)論

構(gòu)建分布式系統(tǒng)并非易事。它充滿了圍繞通信、協(xié)調(diào)、可擴展性、彈性和 運營領(lǐng)域的多重挑戰(zhàn)。但解決這些挑戰(zhàn)是有益的。當分布式系統(tǒng)按計劃工作時，它會創(chuàng)造出一種特殊的組件舞蹈，令人賞心悅目。