分布式系統(tǒng)：常見(jiàn)陷阱和應(yīng)對(duì)復(fù)雜性的有效策略

作者：劉汪洋 2024-06-07 00:08:00

分布式系統(tǒng)的復(fù)雜性是一個(gè)重要挑戰(zhàn)。本文中，我們將探討你可能遇到的復(fù)雜性類型以及應(yīng)對(duì)這些復(fù)雜性的一些有效策略。

譯者 | 劉汪洋

審校 | 重樓

分布式系統(tǒng)的復(fù)雜性是工程師和開(kāi)發(fā)人員面臨的重大挑戰(zhàn)。隨著系統(tǒng)的迭代，復(fù)雜性往往會(huì)增加，因此提前做好準(zhǔn)備至關(guān)重要。接下來(lái)，我們將討論你可能遇到的復(fù)雜性類型，以及在工作中應(yīng)對(duì)這些復(fù)雜性的有效策略。

分布式系統(tǒng)與復(fù)雜性

在開(kāi)發(fā)過(guò)程中，分布式系統(tǒng)是由多個(gè)相互連接并協(xié)同完成任務(wù)的計(jì)算機(jī)組成的網(wǎng)絡(luò)。每臺(tái)計(jì)算機(jī)或節(jié)點(diǎn)都有自己的本地內(nèi)存和處理器，并運(yùn)行各自的進(jìn)程。然而，它們通過(guò)一個(gè)公共網(wǎng)絡(luò)進(jìn)行協(xié)調(diào)和集中管理。分布式系統(tǒng)具有高度的可靠性；單個(gè)組件的故障不會(huì)破壞整個(gè)網(wǎng)絡(luò)的運(yùn)作。

在集中式計(jì)算系統(tǒng)中，通常由一臺(tái)具有單個(gè)處理器和內(nèi)存的計(jì)算機(jī)負(fù)責(zé)解決問(wèn)題。雖然集中式系統(tǒng)也包含多個(gè)節(jié)點(diǎn)，但所有節(jié)點(diǎn)都訪問(wèn)一個(gè)中央節(jié)點(diǎn)，這可能導(dǎo)致網(wǎng)絡(luò)擁塞和速度減慢。集中式系統(tǒng)的一個(gè)顯著缺點(diǎn)是存在單點(diǎn)故障的風(fēng)險(xiǎn)。

復(fù)雜性

復(fù)雜性可以從不同的角度進(jìn)行定義，這里有兩個(gè)主要定義值得注意。

在系統(tǒng)理論中，復(fù)雜性描述了系統(tǒng)中不同獨(dú)立部分之間的相互作用和通信方式：它們?nèi)绾蜗嗷ザx、相互依賴，以及這些依賴關(guān)系的數(shù)量和性質(zhì)。

從軟件和技術(shù)的角度來(lái)看，復(fù)雜性指的是軟件架構(gòu)的細(xì)節(jié)，例如組件的數(shù)量和相互關(guān)系的復(fù)雜性。

單體架構(gòu)

單體架構(gòu)是集中式系統(tǒng)的一個(gè)典型代表。它通常表現(xiàn)為一個(gè)可部署和可執(zhí)行的整體。例如，這種架構(gòu)的組件可能包括一個(gè)用戶界面以及位于同一位置的多個(gè)模塊。

盡管單體架構(gòu)是傳統(tǒng)的軟件構(gòu)建方式，但它存在一些顯著的缺點(diǎn)：

模塊無(wú)法獨(dú)立擴(kuò)展
難以控制系統(tǒng)日益增長(zhǎng)的復(fù)雜性
無(wú)法獨(dú)立部署各模塊
維護(hù)龐大的代碼庫(kù)十分困難
技術(shù)和供應(yīng)商高度耦合

微服務(wù)架構(gòu)

微服務(wù)架構(gòu)是一種面向服務(wù)架構(gòu)的變體，旨在將系統(tǒng)拆分為一組松散耦合的服務(wù)。例如，公司、賬戶、客戶和用戶界面這些功能模塊，會(huì)作為獨(dú)立進(jìn)程部署在多個(gè)節(jié)點(diǎn)上。

雖然每個(gè)服務(wù)都有其獨(dú)立的數(shù)據(jù)庫(kù)，但這種做法有時(shí)可能不理想，甚至被視為反模式。

微服務(wù)架構(gòu)具有以下優(yōu)勢(shì)：

橫向擴(kuò)展：可以對(duì)數(shù)據(jù)庫(kù)和服務(wù)進(jìn)行橫向擴(kuò)展。理論上，任何基礎(chǔ)設(shè)施組件都可以通過(guò)克隆進(jìn)行擴(kuò)展，但這也需要解決許多挑戰(zhàn)。
高可用性和容錯(cuò)性：由于多個(gè)副本的存在，可以采用一些技術(shù)來(lái)避免因崩潰、內(nèi)存泄漏或停電等問(wèn)題導(dǎo)致的停機(jī)。
地理分布：如果我們?cè)诿绹?guó)、歐洲或亞洲有客戶，為了提供最佳用戶體驗(yàn)，我們需要將這些服務(wù)分布在全球，并采用復(fù)雜的數(shù)據(jù)復(fù)制技術(shù)。
技術(shù)選擇自由：可以根據(jù)需求自由選擇技術(shù)方案。

質(zhì)量屬性

任何系統(tǒng)都具有以下三個(gè)主要質(zhì)量屬性：

可靠性：系統(tǒng)在面對(duì)挑戰(zhàn)時(shí)仍能正常運(yùn)行，表現(xiàn)出容錯(cuò)性或彈性。即使當(dāng)前系統(tǒng)運(yùn)行可靠，也不能保證未來(lái)的可靠性。常見(jiàn)的性能下降原因包括負(fù)載增加，例如系統(tǒng)從 1 萬(wàn)并發(fā)用戶擴(kuò)展到 10 萬(wàn)，或從 100 萬(wàn)擴(kuò)展到1000 萬(wàn)。
可擴(kuò)展性：描述系統(tǒng)處理增加負(fù)載能力的術(shù)語(yǔ)。系統(tǒng)的可擴(kuò)展性通常取決于其最薄弱的組件。
可維護(hù)性：指的是使工程和運(yùn)維團(tuán)隊(duì)的工作變得更輕松。良好的穩(wěn)定的抽象有助于減少?gòu)?fù)雜性，使系統(tǒng)更易于修改和適應(yīng)新功能。

主要問(wèn)題是什么？

“任何可能出錯(cuò)的事情都會(huì)出錯(cuò)，并且會(huì)在最糟糕的時(shí)候?！?——墨菲定律

不可靠的網(wǎng)絡(luò)

網(wǎng)絡(luò)的不可靠性有多種原因，例如：

請(qǐng)求可能會(huì)丟失。
請(qǐng)求可能在隊(duì)列中等待，需要稍后傳送。
遠(yuǎn)程節(jié)點(diǎn)可能已經(jīng)故障（如崩潰或斷電）。
遠(yuǎn)程節(jié)點(diǎn)可能暫時(shí)停止響應(yīng)。
遠(yuǎn)程節(jié)點(diǎn)可能已處理請(qǐng)求，但響應(yīng)在網(wǎng)絡(luò)中丟失。
遠(yuǎn)程節(jié)點(diǎn)可能已處理請(qǐng)求，但響應(yīng)被延遲，需要稍后傳送。

策略：超時(shí)

最簡(jiǎn)單的解決方案是在調(diào)用方設(shè)置超時(shí)邏輯。例如，如果調(diào)用方在一段時(shí)間內(nèi)沒(méi)有收到響應(yīng)，就會(huì)拋出錯(cuò)誤并向用戶顯示錯(cuò)誤信息。

策略：重試

在大規(guī)模系統(tǒng)中，我們不能因?yàn)槊總€(gè)網(wǎng)絡(luò)問(wèn)題都拋出異常，從而讓用戶不滿或延遲系統(tǒng)的執(zhí)行。因此，如果響應(yīng)出現(xiàn)了問(wèn)題，只需重試即可。但如果請(qǐng)求已被服務(wù)器處理，只是響應(yīng)丟失了呢？在這種情況下，重試可能會(huì)導(dǎo)致嚴(yán)重后果，如多次下單、支付或交易等。

策略：冪等性

為避免這種情況，可以使用冪等性技術(shù)。

冪等性指多次執(zhí)行相同操作的效果與執(zhí)行一次相同。為了實(shí)現(xiàn)精準(zhǔn)的“一次性語(yǔ)義”，可以在請(qǐng)求中附加冪等鍵。重試相同請(qǐng)求時(shí)，如果附帶相同的冪等鍵，服務(wù)器會(huì)驗(yàn)證該鍵對(duì)應(yīng)的請(qǐng)求是否已被處理，并直接返回之前的響應(yīng)。這樣，無(wú)論重試多少次，相同的鍵都不會(huì)對(duì)系統(tǒng)行為產(chǎn)生不良影響。

策略：斷路器

斷路器是另一種有效的模式，尤其適用于防止服務(wù)器過(guò)載和完全崩潰的情況。

斷路器充當(dāng)代理，以防止調(diào)用系統(tǒng)進(jìn)入維護(hù)狀態(tài)，可能會(huì)失敗，或者正在嚴(yán)重失敗。失敗的原因可能有很多：內(nèi)存泄漏、代碼錯(cuò)誤或外部依賴故障。在這種情況下，快速失敗比冒著級(jí)聯(lián)故障的風(fēng)險(xiǎn)要好得多。

并發(fā)和丟失寫入

并發(fā)是分布式系統(tǒng)中最復(fù)雜的挑戰(zhàn)之一。并發(fā)意味著多個(gè)計(jì)算同時(shí)進(jìn)行。

那么，當(dāng)試圖同時(shí)從不同操作更新賬戶余額時(shí)會(huì)發(fā)生什么？如果沒(méi)有防護(hù)機(jī)制，很可能會(huì)發(fā)生競(jìng)爭(zhēng)條件，導(dǎo)致寫入丟失和數(shù)據(jù)不一致。在這個(gè)例子中，兩個(gè)操作試圖同時(shí)更新賬戶余額。由于它們是并行運(yùn)行的，最后一個(gè)完成的操作將獲勝，從而導(dǎo)致嚴(yán)重問(wèn)題。為避免這種問(wèn)題，可以采用多種技術(shù)。

策略：快照隔離

ACID 是原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持久性（Durability）的縮寫。所有流行的 SQL 數(shù)據(jù)庫(kù)都實(shí)現(xiàn)了這些屬性。

原子性 原子性確保事務(wù)中的所有操作要么全部執(zhí)行，要么全部不執(zhí)行。事務(wù)的原子性保證了系統(tǒng)在出現(xiàn)故障時(shí)，不會(huì)部分執(zhí)行事務(wù)，從而避免數(shù)據(jù)的不一致性。
一致性 一致性確保事務(wù)在執(zhí)行前后，數(shù)據(jù)庫(kù)始終處于一致的狀態(tài)。換句話說(shuō)，事務(wù)執(zhí)行完成后，數(shù)據(jù)庫(kù)從一個(gè)有效狀態(tài)轉(zhuǎn)換到另一個(gè)有效狀態(tài)，保持?jǐn)?shù)據(jù)的完整性和正確性。
隔離性 隔離性確保并發(fā)執(zhí)行的事務(wù)彼此獨(dú)立，不會(huì)互相干擾。不同的事務(wù)之間的操作是隔離的，避免了數(shù)據(jù)競(jìng)爭(zhēng)、臟讀、不可重復(fù)讀和幻讀等問(wèn)題。
持久性 持久性確保一旦事務(wù)提交，其結(jié)果將永久保存在數(shù)據(jù)庫(kù)中，即使系統(tǒng)崩潰或發(fā)生故障，也不會(huì)丟失已提交的事務(wù)結(jié)果。

快照隔離的關(guān)鍵思想是數(shù)據(jù)庫(kù)會(huì)跟蹤已記錄的版本，并且不會(huì)提交那些在當(dāng)前事務(wù)之外已被修改的事務(wù)。

策略：CAS

大多數(shù) NoSQL 數(shù)據(jù)庫(kù)選擇 BASE（基本可用、軟狀態(tài)、最終一致性）時(shí)不提供 ACID 屬性，但廣泛使用比較并設(shè)置（Compare and Set, CAS）。這種操作旨在避免更新丟失，僅在值自上次讀取后未更改時(shí)才允許更新。如果當(dāng)前值與之前讀取的值不匹配，更新不會(huì)生效，必須重試讀取-修改-寫入循環(huán)。

例如，Cassandra 提供輕量級(jí)事務(wù)，允許使用各種 IF、IF NOT EXISTS 和 IF EXISTS 條件來(lái)避免并發(fā)問(wèn)題。

策略：租約機(jī)制

另一種解決方案是租約機(jī)制。例如，當(dāng)需要獨(dú)占更新某個(gè)資源時(shí)，租約機(jī)制要求首先為資源獲取一個(gè)帶有到期時(shí)間的租約，然后進(jìn)行更新，最后歸還租約。

在發(fā)生故障的情況下，租約會(huì)自動(dòng)到期，從而允許另一個(gè)線程訪問(wèn)資源。盡管這種技術(shù)非常有用，但存在進(jìn)程暫停和時(shí)鐘不同步的風(fēng)險(xiǎn)，這可能導(dǎo)致并行資源訪問(wèn)的問(wèn)題。

雙寫問(wèn)題

雙寫問(wèn)題是在分布式系統(tǒng)中需要同步多個(gè)數(shù)據(jù)源或數(shù)據(jù)庫(kù)時(shí)的一個(gè)常見(jiàn)挑戰(zhàn)。例如，假設(shè)一個(gè)場(chǎng)景需要將新數(shù)據(jù)存儲(chǔ)到數(shù)據(jù)庫(kù)并發(fā)送消息到 Kafka。由于這兩個(gè)操作不是原子的，因此在發(fā)布新消息時(shí)可能會(huì)失敗。

如果在發(fā)送消息時(shí)嘗試進(jìn)行事務(wù)操作，情況會(huì)更加復(fù)雜。如果事務(wù)未能提交，外部系統(tǒng)可能已經(jīng)收到實(shí)際上并未發(fā)生的更改信息。

策略：事務(wù)性發(fā)件箱

一種潛在的解決方案是實(shí)施事務(wù)性發(fā)件箱。這種方法是在與操作本身相同的事務(wù)中，將事件存儲(chǔ)在 "OutboxEvents" 表中。由于過(guò)程的原子性，如果事務(wù)失敗，將不會(huì)存儲(chǔ)任何數(shù)據(jù)。

另一個(gè)必要組件是 Relay，它定期輪詢 OutboxEvents 表并將消息發(fā)送到目標(biāo)。這種方法可以實(shí)現(xiàn)至少一次交付保證。由于網(wǎng)絡(luò)不可靠，所有消費(fèi)者都必須具有冪等性，因此這并不是一個(gè)問(wèn)題。

策略：Log Tailing

構(gòu)建自定義事務(wù)性外發(fā)箱的另一種替代方案是利用數(shù)據(jù)庫(kù)事務(wù)日志和自定義連接器直接從日志中讀取并將更改發(fā)送到目標(biāo)。

這種方法有其自身的優(yōu)點(diǎn)和缺點(diǎn)。例如，它需要與數(shù)據(jù)庫(kù)解決方案耦合，但允許在應(yīng)用程序中編寫更少的代碼。

不可靠的時(shí)鐘

時(shí)間跟蹤是任何軟件或基礎(chǔ)設(shè)施的基本方面，因?yàn)樗軌驁?zhí)行超時(shí)、到期和收集指標(biāo)。然而，在分布式系統(tǒng)中，時(shí)鐘的可靠性是一個(gè)重大挑戰(zhàn)，因?yàn)闀r(shí)間的準(zhǔn)確性取決于各個(gè)計(jì)算機(jī)的性能，而這些計(jì)算機(jī)的時(shí)鐘可能快于或慢于其他時(shí)鐘。

計(jì)算機(jī)使用的主要有兩種類型的時(shí)鐘：日歷時(shí)鐘和單調(diào)時(shí)鐘。日歷時(shí)鐘根據(jù)特定日歷返回日期和時(shí)間，通常與網(wǎng)絡(luò)時(shí)間協(xié)議（NTP）同步。然而，延遲和網(wǎng)絡(luò)問(wèn)題可能會(huì)影響同步過(guò)程，導(dǎo)致時(shí)鐘不同步。單調(diào)時(shí)鐘則是連續(xù)推進(jìn)的，適合測(cè)量持續(xù)時(shí)間。

然而，單調(diào)遞增值是每臺(tái)計(jì)算機(jī)獨(dú)有的，限制了它們?cè)诙喾?wù)器之間日期和時(shí)間比較中的使用。實(shí)現(xiàn)高度準(zhǔn)確的時(shí)鐘同步是一項(xiàng)挑戰(zhàn)性任務(wù)。在大多數(shù)情況下，這種解決方案的必要性并不明顯。然而，在需要遵守法規(guī)的情況下，可以使用精確時(shí)間協(xié)議（PTP），但這將需要大量投入。

可用性和一致性

CAP 定理指出，任何分布式數(shù)據(jù)存儲(chǔ)系統(tǒng)只能同時(shí)滿足以下三個(gè)保證中的兩個(gè)：一致性（Consistency）、可用性（Availability）和分區(qū)容錯(cuò)性（Partition Tolerance）。由于網(wǎng)絡(luò)的不可靠性是一個(gè)無(wú)法顯著改變的因素，在網(wǎng)絡(luò)分區(qū)的情況下，必須在可用性和一致性之間進(jìn)行選擇。

考慮以下場(chǎng)景：兩個(gè)客戶端分別從不同的節(jié)點(diǎn)讀取數(shù)據(jù)，一個(gè)從主節(jié)點(diǎn)讀取，另一個(gè)從從節(jié)點(diǎn)讀取。復(fù)制配置在 leader 更改后更新 follower 節(jié)點(diǎn)。但是，如果由于某種原因 leader 停止響應(yīng)會(huì)發(fā)生什么？

這可能是由于崩潰、網(wǎng)絡(luò)分區(qū)或其他問(wèn)題。在高可用系統(tǒng)中，必須指定一個(gè)新的 leader ，但如何選擇現(xiàn)有的 follower 節(jié)點(diǎn)呢？為了解決這個(gè)問(wèn)題，必須采用一種分布式共識(shí)算法。然而，在深入探討這種算法之前，有必要全面了解各種類型的一致性。

一致性類型

一致性保證主要分為兩類：

弱一致性（最終一致性）：意味著如果停止對(duì)領(lǐng)導(dǎo)者進(jìn)行更改，數(shù)據(jù)將在一段時(shí)間后在所有從節(jié)點(diǎn)上同步。
強(qiáng)一致性：確保系統(tǒng)中的所有節(jié)點(diǎn)在同一時(shí)間看到相同的數(shù)據(jù)，無(wú)論它們?cè)L問(wèn)的是哪個(gè)節(jié)點(diǎn)。

策略：分布式共識(shí)算法（例如 Raft）

回到 leader 崩潰的問(wèn)題，需要選舉一個(gè)新的 leader 。這個(gè)問(wèn)題乍看之下很簡(jiǎn)單，但實(shí)際上在選擇合適的方法時(shí)需要考慮許多條件和權(quán)衡。

根據(jù) Raft 協(xié)議，如果 follower 在指定時(shí)間內(nèi)沒(méi)有收到來(lái)自 leader 的數(shù)據(jù)或心跳信號(hào)，則會(huì)開(kāi)始新的 leader 選舉過(guò)程。每個(gè)復(fù)制單元（單體寫節(jié)點(diǎn)或多個(gè)分片）都與一組 Raft 日志和操作系統(tǒng)進(jìn)程相關(guān)聯(lián)，這些進(jìn)程維護(hù)日志并將更改從 leader 復(fù)制到 follower 節(jié)點(diǎn)。

Raft 協(xié)議保證 follower 節(jié)點(diǎn)按照 leader 生成的順序接收日志記錄。當(dāng)一半的 follower 節(jié)點(diǎn)確認(rèn)收到提交記錄并將其寫入 Raft 日志時(shí)，用戶事務(wù)便在 leader 上提交。

策略：從 leader 讀取

一種可能的有效且簡(jiǎn)單的策略是由剛剛保存新數(shù)據(jù)的用戶從 leader 讀取，以避免復(fù)制延遲。

結(jié)論

從單體架構(gòu)到微服務(wù)架構(gòu)，每種方法都有其優(yōu)點(diǎn)和挑戰(zhàn)。雖然單體架構(gòu)提供了簡(jiǎn)潔性，但它們通常在可擴(kuò)展性和可維護(hù)性方面表現(xiàn)不佳，這推動(dòng)開(kāi)發(fā)人員向更加模塊化和可擴(kuò)展的微服務(wù)架構(gòu)發(fā)展。

討論的核心是復(fù)雜性的管理，這種復(fù)雜性以各種形式表現(xiàn)出來(lái)，從網(wǎng)絡(luò)不可靠到并發(fā)問(wèn)題再到雙寫問(wèn)題。諸如超時(shí)、重試、冪等性和斷路器等策略為減輕網(wǎng)絡(luò)不可靠帶來(lái)的風(fēng)險(xiǎn)提供了有效的工具，而快照隔離、比較并設(shè)置以及租約等技術(shù)則解決了并發(fā)和丟失寫入的挑戰(zhàn)。

此外，不可靠時(shí)鐘的關(guān)鍵問(wèn)題強(qiáng)調(diào)了在分布式系統(tǒng)中準(zhǔn)確時(shí)間同步的重要性，從 NTP 同步到精確時(shí)間協(xié)議（PTP），都提供了相應(yīng)的解決方案。此外，CAP 定理提醒我們?cè)诳捎眯院鸵恢滦灾g固有的權(quán)衡，迫使我們深入了解諸如 Raft 之類的分布式共識(shí)算法。

總之，掌握分布式系統(tǒng)中的復(fù)雜性需要多方面的方法，需要理論與實(shí)踐相結(jié)合。通過(guò)采用這些策略并不斷適應(yīng)不斷變化的分布式計(jì)算領(lǐng)域，工程師和開(kāi)發(fā)人員可以應(yīng)對(duì)這些復(fù)雜性挑戰(zhàn)，確保其系統(tǒng)在面對(duì)不斷變化的挑戰(zhàn)時(shí)的可靠性、可擴(kuò)展性和可維護(hù)性。