布式應(yīng)用是現(xiàn)代軟件開發(fā)行業(yè)的主食。它們是云存儲服務(wù)的關(guān)鍵，并允許大規(guī)模的Web應(yīng)用來保持反應(yīng)。隨著程序員構(gòu)建這些系統(tǒng)，它們需要基本構(gòu)建塊，它們可以用作起點并在共享詞匯中通信。

這是分布式系統(tǒng)設(shè)計模式變得非常寶貴的地方。雖然它們有時過度使用，但了解如何使用它們是一個關(guān)鍵的技能招聘人員正在尋找，并且在先進的系統(tǒng)設(shè)計訪談中脫穎而出至關(guān)重要。

今天，我們將探討五個優(yōu)秀分布式系統(tǒng)設(shè)計模式，以幫助您了解其優(yōu)缺點，何時使用它們。

[[405312]]

什么是分布式系統(tǒng)設(shè)計模式?

設(shè)計模式是驗證的，并測試了每個符合特定用例的系統(tǒng)的方法。它們不是實現(xiàn)，而是抽象的結(jié)構(gòu)化系統(tǒng)。多年來，許多不同的開發(fā)人員已經(jīng)開發(fā)和更新了大多數(shù)設(shè)計模式，這意味著它們通常是非常有效的起點。

設(shè)計模式是構(gòu)建塊，允許程序員從現(xiàn)有知識中拉出，而不是從每個系統(tǒng)開始從頭開始。他們還為系統(tǒng)設(shè)計創(chuàng)建了一組標準模型，幫助其他開發(fā)人員看到其項目如何與給定系統(tǒng)接口。

創(chuàng)造設(shè)計模式在構(gòu)建新對象時提供基準。結(jié)構(gòu)圖案定義了解決方案的整體結(jié)構(gòu)。行為模式描述了對象以及它們?nèi)绾位ハ嗤ㄐ拧?/p>

分布式系統(tǒng)設(shè)計模式是開發(fā)分布式系統(tǒng)時使用的設(shè)計模式，這些系統(tǒng)基本上是計算機和數(shù)據(jù)中心的集合，充當最終用戶的一臺計算機。這些分布式設(shè)計模式概述了一個軟件架構(gòu)，了解不同的節(jié)點如何彼此通信，節(jié)點處理每個任務(wù)，以及用于不同任務(wù)的過程流程。

在設(shè)計大規(guī)模云計算和可擴展的微服務(wù)軟件系統(tǒng)的分布式系統(tǒng)架構(gòu)時廣泛使用這些模式。

分布式設(shè)計模式的類型

大多數(shù)分布式的設(shè)計模式基于與他們一起工作的功能的三個類別之一：

• 對象通信：描述要通信的系統(tǒng)的不同組件的消息傳遞協(xié)議和權(quán)限。
• 安全性：處理機密性，完整性和可用性問題，以確保系統(tǒng)從未經(jīng)授權(quán)的訪問中獲得安全。
• 事件驅(qū)動：描述生產(chǎn)，檢測，消費和對系統(tǒng)事件的響應(yīng)的模式。

1. 命令和查詢責任分離(CQRS)

CQRS模式側(cè)重于分離分布式系統(tǒng)的讀寫操作以提高可擴展性和安全性。此模型使用命令將數(shù)據(jù)寫入持久存儲和查詢以定位和獲取數(shù)據(jù)。

這些由從用戶接收請求的命令中心處理。然后命令中心獲取數(shù)據(jù)并進行必要的修改，保存數(shù)據(jù)，并通知讀取服務(wù)。然后，讀取服務(wù)更新讀取模型以顯示對用戶的更改。

好處：

• 通過委派任務(wù)來降低系統(tǒng)復(fù)雜性。
• 在業(yè)務(wù)邏輯和驗證之間執(zhí)行明確的分離。
• 幫助通過他們的工作進行分類。
• 減少共享數(shù)據(jù)的意外更改的數(shù)量。
• 減少具有修改對數(shù)據(jù)訪問的實體數(shù)。

缺點：

• 在命令和讀取模型之間需要恒定的前后通信。
• 發(fā)送高吞吐量查詢時會導(dǎo)致延遲增加。
• 沒有溝通服務(wù)進程之間的手段。

用例：

CQRS最適合像SQL或NoSQL數(shù)據(jù)庫管理系統(tǒng)等數(shù)據(jù)密集型應(yīng)用程序。它對數(shù)據(jù)沉重的微服務(wù)架構(gòu)也有助于。對于處理有狀態(tài)申請非常重要，因為作者/讀者區(qū)別有助于不可變態(tài)。

2. 兩階段提交(2PC)

2PC與CQR類似于其交易方法和依賴核心命令，但分區(qū)由它們的類型處理，并且它們的完成階段。這兩個階段是準備階段(中央控制告訴服務(wù)準備數(shù)據(jù))和提交階段(其向服務(wù)發(fā)送服務(wù)發(fā)送準備的數(shù)據(jù))。

默認情況下，2PC系統(tǒng)中的所有服務(wù)都被鎖定，這意味著它們無法發(fā)送數(shù)據(jù)。鎖定時，服務(wù)填寫準備階段，因此他們已準備好發(fā)送一次解鎖。協(xié)調(diào)器逐個解鎖服務(wù)并請求其數(shù)據(jù)。如果服務(wù)未準備好提交其數(shù)據(jù)，則協(xié)調(diào)器將繼續(xù)進行另一個服務(wù)。一旦發(fā)送了所有準備的數(shù)據(jù)，所有服務(wù)都會解鎖以等待協(xié)調(diào)員的新任務(wù)。

2PC基本上確保只有一個服務(wù)可以一次操作，這使得該過程更具抵抗和始終如一的CQRS。

好處：

• 由于缺乏并發(fā)請求而持續(xù)和抵抗錯誤。
• 可擴展 - 可以輕松處理大數(shù)據(jù)池，因為它可以從單個機器處理數(shù)據(jù)。
• 允許同時隔離和數(shù)據(jù)共享。

缺點：

• 由于其同步性質(zhì)，不容易容易容易出現(xiàn)瓶頸和阻塞。
• 需要比其他設(shè)計模式更多的資源。

用例：

2PC最適合分布式系統(tǒng)，該系統(tǒng)處理高賭注交易操作，以滿足資源效率的準確性。它是抵抗錯誤，即使在比例下也很容易跟蹤錯誤。

3. SAGA

SAGA是一種異步模式，不使用中央控制器，而是完全在服務(wù)之間進行通信。這克服了先前覆蓋了同步模式的一些缺點。

SAGA使用活動總線允許服務(wù)在微服務(wù)系統(tǒng)中彼此通信。總線發(fā)送和接收服務(wù)之間的請求，每個參與服務(wù)都會創(chuàng)建本地事務(wù)。然后，參與服務(wù)每次都會發(fā)出其他服務(wù)的活動。其他服務(wù)所有人都聽事件。接收該活動的第一個服務(wù)將執(zhí)行所需的操作。如果該服務(wù)無法完成操作，則會發(fā)送到其他服務(wù)。

這種結(jié)構(gòu)類似于2PC設(shè)計，因為如果一個人無法完成任務(wù)，則服務(wù)是循環(huán)的。但是，Saga刪除了中央控制元素，以更好地管理流量并減少所需的前后通信量。

好處：

• 個人服務(wù)可以處理更長的交易。
• 偉大的分布式系統(tǒng)由于分散化。
• 由于服務(wù)與服務(wù)之間的對等通信減少了瓶頸。

缺點：

• 異步自主權(quán)使得難以跟蹤哪些服務(wù)正在進行各個任務(wù)。
• 由于復(fù)雜的編排難以調(diào)試。
• 比以前的模式更少的服務(wù)隔離。

用例：

SAGA的分散方法非常適合可擴展的無服務(wù)器功能，可立即處理許多并行請求。AWS在許多功能中使用基于SAGA的設(shè)計，如步驟和LAMBDA函數(shù)。

4. 復(fù)制負載平衡服務(wù)(RLB)

RLBS模式是最簡單，最常用的設(shè)計模式。在最基本的級別，它由多個相同的服務(wù)組成所有向中央負載均衡器報告。每個服務(wù)都能夠處理任務(wù)，如果失敗，可以復(fù)制。負載均衡器從最終用戶接收請求，并以循環(huán)方式或有時使用更復(fù)雜的路由算法將其分發(fā)給服務(wù)。

重復(fù)的服務(wù)確保應(yīng)用程序為用戶請求維護高可用性，并且如果服務(wù)的一個實例應(yīng)該失敗，則可以重新分發(fā)工作。

RLBS通常與Azure Kubernetes一起使用，它是Microsoft的開源容器編排技術(shù)，提供基于工作流程的自動服務(wù)縮放。

好處：

• 來自最終用戶的視圖的一致性。
• 可以快速從失敗的服務(wù)中恢復(fù)。
• 高度可擴展，提供更多服務(wù)。
• 非常適合并發(fā)。

缺點：

• 基于負載均衡器算法的不一致性能。
• 資源密集型管理服務(wù)。

用例：

RLBS非常適合全面的工作負載不一致，但必須保持低延遲，例如Netflix或亞馬遜Prime等娛樂Web應(yīng)用程序。

5. 分片服務(wù)

基于副本的設(shè)計的替代方案是創(chuàng)建各種服務(wù)，每個服務(wù)只能完成某種請求。這被稱為“分片”，因為您將請求流拆分為多個不相等的部分。例如，您可能有一個接受所有緩存請求的碎片服務(wù)，并且另一個僅處理高優(yōu)先級請求。負載平衡器在進入并將其分發(fā)到適當?shù)乃槠瑫r，請評估每個請求。

分叉服務(wù)通常用于構(gòu)建狀態(tài)服務(wù)，因為狀態(tài)的大小通常太大，對于單個無狀態(tài)容器通常太大。分片允許您縮放單個碎片以滿足國家的大小。

分叉服務(wù)還允許您更快地處理高優(yōu)先級請求。致力于高優(yōu)先級請求的碎片始終可用于處理它們進入的那一刻而不是將它們放在隊列中的請求。

好處：

• 允許您為公共請求進行分級碎片。
• 易于優(yōu)先考慮請求。
• 由于自然排序而調(diào)試簡單。

缺點：

• 可以是資源密集的，以維護許多碎片。
• 如果碎片不成比例地使用碎片，則會導(dǎo)致性能損失。

用例：

當系統(tǒng)在請求類型中收到可預(yù)測的不平衡時，碎片服務(wù)是最好的，但有些請求有優(yōu)先級。