實現近乎無限可擴充套件性的7種設計模式

來源：coderidea

本篇主要總結了來自Pat Helland的令人印象深刻的論文《Life beyond Distributed Transactions: an Apostate's Opinion》中的設計模式。

實體唯一標識

在構建大規模分散式系統時，為了確保資料的唯一性和一致性，每個代表著獨立資料集的實體都應該具有唯一的標識。這意味著我們需要為每個實體定義一個獨一無二的鍵，以便能夠有效地對其進行區分和操作。

多個不相交範圍的事務可序列化

分散式系統中的事務管理是一個複雜而關鍵的問題。為了實現可伸縮性，我們需要確保事務的作用範圍是有限的，不涉及多個不相交的資料實體。這樣可以避免跨實體的原子事務，從而提高系統的併發性和效能。

至少一次訊息傳遞

在分散式系統中，訊息傳遞是組成不同元件之間通訊的重要方式。應用程式必須具備至少一次訊息傳遞的能力，即能夠容忍訊息的重複傳送和訊息到達的無序性。這是確保系統魯棒性的關鍵因素之一。

訊息定址到實體

為了實現可擴充套件性，我們需要明確定義訊息是如何定址到特定實體的。這意味著我們不能將實體的唯一鍵的存在抽象化，而是需要在業務邏輯中考慮這些唯一鍵，以確保訊息能夠準確地定位到目標實體。

實體按參與方管理會話狀態

為了保證系統的冪等性，每個實體需要能夠管理與參與方的會話狀態。這涉及到實體必須記住先前已經處理過的訊息，以及在沒有原子事務的情況下，使用某種工作流能力來“協商”處理結果。

替代索引不能存在於單一範圍內

在分散式環境中，不能假設對實體的索引或引用可以原子地更新。由於存在併發操作，不同索引可能會出現不同步的情況。因此，在設計中需要考慮到這一點，以確保系統的一致性。

實體之間的訊息傳遞是臨時的

在分散式系統中，實體之間的訊息傳遞必須能夠容忍一定程度的不確定性。傳送的訊息應該被視為提交請求，但也可能會被取消。這種容錯性是確保系統在面對各種異常情況時能夠繼續執行的關鍵。

與此同時，以上設計原則與構建Amazon S3時採用的設計原則相比較：

1. 去中心化：採用完全去中心化的技術，消除系統的擴充套件瓶頸和單點故障，提高系統的可伸縮性。

2. 非同步性：確保系統在任何情況下都能取得進展，即使在非同步的通訊模式下也能夠保持高效的執行。

3. 自主性：每個元件都能夠基於本地資訊做出決策，實現系統的分散式自治，降低對全域性狀態的依賴。

4. 本地責任：每個元件都負責自身一致性的維護，不依賴於其他同行的幹預，從而提高系統的穩定性。

5. 受控併發：透過設計操作，避免或最小化併發控制的需求，提高系統的併發效能。

6. 容錯性：將元件故障看作是正常操作模式的一部分，系統能夠在元件失敗時繼續執行，保持高可用性。

7. 受控並行性：使用精細的抽象粒度，使系統能夠利用並行性以提高效能和系統的健壯性。

8. 分解成小而易理解的構建塊：避免設計一個單一服務嘗試做所有事情，而是構建小元件，它們可以作為其他服務的構建塊。

9. 對稱性：確保系統中的節點在功能上是相同的，減少節點特定的配置需求，提高系統的可維護性。

10. 簡單性：透過保持系統足夠簡單，但又不過於簡單，降低系統的複雜性，提高可理解性。

這些設計原則共同構建了一個強大而高效的分散式系統，旨在應對大規模和高複雜性的挑戰。透過理解和應用這些原則，開發者能夠更好地構建可靠、可伸縮、高效能的分散式應用。