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

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

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

[[405312]]

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

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

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

創(chuàng)造設計模式在構建新對象時提供基準。結構圖案定義了解決方案的整體結構。行為模式描述了對象以及它們如何互相通信。

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

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

分布式設計模式的類型

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

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

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

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

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

好處：

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

缺點：

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

用例：

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

2. 兩階段提交(2PC)

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

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

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

好處：

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

缺點：

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

用例：

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

3. SAGA

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

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

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

好處：

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

缺點：

• 異步自主權使得難以跟蹤哪些服務正在進行各個任務。
• 由于復雜的編排難以調試。
• 比以前的模式更少的服務隔離。

用例：

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

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

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

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

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

好處：

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

缺點：

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

用例：

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

5. 分片服務

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

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

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

好處：

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

缺點：

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

用例：

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