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

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

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

雖然創(chuàng)建可以幫助人們學(xué)習(xí)的信息內(nèi)容沒(mé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)?？赡苁堑乩砩戏珠_(kāi)的。

沒(méi)有其各個(gè)節(jié)點(diǎn)之間的通信，任何分布式系統(tǒng)都無(wú)法運(yùn)行。

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

當(dāng)我們?cè)L問(wèn)一個(gè) URL 時(shí)，我們的瀏覽器會(huì)聯(lián)系 DNS 來(lái)解析該 URL 的服務(wù)器地址。一旦獲得地址，它就會(huì)通過(guò)網(wǎng)絡(luò)向服務(wù)器發(fā)送 HTTP 請(qǐng)求。服務(wù)器處理請(qǐng)求并發(fā)回響應(yīng)。

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

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

我們可以通過(guò)退回到 TCP 和 HTTPS 等抽象來(lái)應(yīng)對(duì)其中的許多通信挑戰(zhàn)。

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

協(xié)調(diào)

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

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

兩位將軍怎么能就進(jìn)攻時(shí)間達(dá)成一致呢?

他們中的一個(gè)可以通過(guò)發(fā)送信使并等待響應(yīng)來(lái)向另一個(gè)建議時(shí)間。但是，如果沒(méi)有響應(yīng)怎么辦?會(huì)不會(huì)是信使被抓了?信使會(huì)不會(huì)受傷并且需要比預(yù)期更長(zhǎng)的時(shí)間?將軍應(yīng)該再派一個(gè)使者嗎?

這個(gè)問(wèn)題不是微不足道的。

無(wú)論派出多少使者，兩位將軍都不能確定對(duì)方軍隊(duì)會(huì)在正確的時(shí)間攻城。派遣更多的使者可以增加協(xié)調(diào)成功的機(jī)會(huì)，但機(jī)會(huì)永遠(yuǎn)不會(huì)達(dá)到 100%。

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

在開(kāi)始時(shí)，每個(gè)開(kāi)發(fā)人員都覺(jué)得他們將構(gòu)建一個(gè)無(wú)故障的系統(tǒng)。我以前也是這么想的。當(dāng)然，這是一種天真的追求，注定要失敗。您無(wú)法構(gòu)建一個(gè)完全沒(méi)有錯(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ù)載呢?

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

性能和負(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ù)增長(zhǎng)超過(guò)容量，它最終會(huì)達(dá)到大多數(shù)操作失敗或超時(shí)的程度。吞吐量下降，響應(yīng)時(shí)間猛增。此時(shí)，系統(tǒng)不再具有可擴(kuò)展性。請(qǐng)參見(jiàn)下圖，該圖顯示了這種情況。

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

如果負(fù)載超出容量是導(dǎo)致性能下降的原因，我們可以通過(guò)增加容量來(lái)使系統(tǒng)具有可擴(kuò)展性。增加容量的一種快速簡(jiǎn)便的方法是購(gòu)買具有更好性能指標(biāo)的更昂貴的硬件。這種方法稱為放大。

盡管在紙面上聽(tīng)起來(lái)不錯(cuò)，但這種方法遲早會(huì)碰壁。

更可持續(xù)的方法是通過(guò)向系統(tǒng)添加更多機(jī)器來(lái)進(jìn)行擴(kuò)展。

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

彈性

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

• 首先，向外擴(kuò)展會(huì)增加失敗的可能性。由于系統(tǒng)中的每個(gè)組件都有發(fā)生故障的內(nèi)在概率，因此添加更多部件會(huì)增加總體故障概率。
• 其次，更多的組件意味著更多的操作。這增加了系統(tǒng)中故障的絕對(duì)數(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ī)制)來(lái)提高系統(tǒng)的彈性。然而，這不是零和游戲。沒(méi)有分布式系統(tǒng)可以 100% 有彈性。在某些時(shí)候，故障會(huì)削弱系統(tǒng)的可用性。

可用性是一個(gè)重要指標(biāo)。它是應(yīng)用程序可以為請(qǐng)求提供服務(wù)的時(shí)間除以測(cè)量的持續(xù)時(shí)間。

組織通常使用 9 的概念以百分比形式推銷其系統(tǒng)的可用性。三個(gè)九 (99.9%) 通常被認(rèn)為對(duì)大量系統(tǒng)來(lái)說(shuō)是可以接受的。任何超過(guò)四個(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)歷開(kāi)發(fā)、測(cè)試、部署和運(yùn)行的軟件開(kāi)發(fā)生命周期。

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

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

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

結(jié)論

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