系統架構設計理論與原則、負載均衡及高可用系統設計速記

一、系統架構設計理論與原則

這裡主要介紹幾種常見的架構設計理論和原則，常見於大中型互聯繫統架構設計。

（一）、CAP理論1、什麼是CAP

著名的CAP理論是由Brewer提出的，所謂CAP，即一致性（Consistency）、可用性（Availability）和分區容錯性（Partition Tolerance）。

（1）、Consistency（一致性）：更新操作成功並返回客戶端完成後,分布式的所有節點在同一時間的數據完全一致（All nodes see the same data at the same time）。

這裡的一致性，一定要和傳統的RDBMS中的事務一致性區分開。

在傳統的RDBMS中，事務具有ACID4個屬性，即原子性（Atomicity），一致性（Consistency），隔離性（Isolation）和持久性（Durable）。

ACID是關係型資料庫的最基本原則，遵循ACID原則強調一致性，對成本要求很高，對性能影響很大。

a、原子性（Atomicity）：事務是一個原子操作單元，其對數據的修改，要麼全都執行，要麼全都不執行。

b、一致性（Consistency）：在事務開始和完成時，數據都必須保持一致狀態。這意味著所有相關的數據規則都必須應用於事務的修改，以保持數據的完整性；事務結束時，所有的內部數據結構（如B樹索引或雙向鏈表）也都必須是正確的。

c、隔離性（Isolation）：資料庫系統提供一定的隔離機制，保證事務在不受外部並發操作影響的「獨立」環境執行。這意味著事務處理過程中的中間狀態對外部是不可見的，反之亦然。

d、持久性（Durability）：事務完成之後，它對於數據的修改是永久性的，即使出現系統故障也能夠保持。

MIT的Gilbert和Lynch在證明CAP的過程中改變了Consistency的概念，也就是將Consistency轉化為Atomic。Gilbert認為這裡所說的Consistency其實就是資料庫系統中提到的ACID的另一種表述：一個用戶請求要麼成功、要麼失敗，不能處於中間狀態（Atomic）；一旦一個事務完成，將來的所有事務都必須基於這個完成後的狀態（Consistent）；未完成的事務不會互相影響（Isolated）；一旦一個事務完成，就是持久的（Durable）。

（2）、Availability（可用性）：讀和寫操作都能成功（Reads and writes always succeed）。

可用性是說服務能一直保證是可用的狀態，當用戶發出一個請求，服務能在有限時間內返回結果，所有的請求都能「成功」拿到對應的響應。

（3）、Partition Tolerance（分區容錯性）：在出現網路故障導致分布式節點間不能通信時，系統能否繼續服務（The system continues to operate despite arbitrary message loss or failure of part of the system）。

直觀感受就是系統中節點crash或者網路分片都不應該導致一個分布式系統停止服務。

2、如何證明CAP？

CAP的證明很簡單：

假設兩個節點集，由於網路分片導致G1和G2之間所有的通訊都斷開了。

如果在G1中寫，在G2中讀剛寫的數據， G2中返回的值不可能是剛剛在G1中的寫值。

對於分布式數據系統而言，分區容錯性（Partition Tolerance）是基本要求，否則就不稱其為分布式系統。

由於可用性（Availability）的要求，G2一定要返回這次讀請求，因為分區容錯性（Partition Tolerance）的存在，導致一致性（Consistency）一定是不可滿足的。

CAP理論告訴我們，一個分布式系統不可能同時滿足一致性，可用性和分區容錯性這三個需求，三個要素中最多只能同時滿足兩點。

顯然,任何橫向擴展策略都要依賴於數據分區，軟體架構通常必須在一致性（Consistency）與可用性（Availability）之間做出選擇。

3、CAP的延伸BASE

BASE是Basically Available、Soft state、Eventually consistent三個片語的簡寫，是對CAP中C 和A的延伸。

（1）Basically Available：基本可用，即數據一致性能夠基本滿足二八定律，即至少保證80%一致性，剩下20%就不要過於糾結。

（2）Soft-state：軟狀態/柔性事務，即狀態可以有一段時間的不同步。

在不過分追求數據一致性（強一致性）前提下可考慮軟狀態策略，例如把數據（State）緩存在客戶端一段時間，在一段時間過後，如果客戶端沒有再次刷新狀態的請求的話，就清除此緩存（Soft），這個狀態就會消失。

（3）Eventual consistency：最終一致性，即在某一段短時間內允許數據不一致，但經過一段較長時間（這裡的一段時間多數是業務能夠容忍的延遲），等所有節點上數據的拷貝都整合在一起的時候，數據會最終達到完全一致。我用自己的經驗和親身實踐證明，最終一致性貫穿著互聯網尤其是電子商務類型的主要應用的生命周期。

BASE來自於互聯網的電子商務領域的實踐，它是基於CAP理論逐步演化而來，核心思想是即便不能達到強一致性(Strong Consistency)，但可以根據應用特點採用適當的方式來達到最終一致性(Eventual consistency)的效果。BASE是反ACID的，它完全不同於ACID模型，犧牲強一致性，獲得基本可用性和柔性可靠性並要求達到最終一致性。

CAP、BASE理論是當前在互聯網領域非常流行的NoSQL的理論基礎。

（二）、無共享架構1、什麼是無共享架構

無共享架構SNA（Shared Nothing Architecture），維基百科中的說明是：

「A shared nothing architecture (SN) is a distributed computing architecture in which each node is independent and self-sufficient, and there is no single point of contention across the system. More specifically, none of the nodes share memory or disk storage. People typically contrast SN with systems that keep a large amount of centrally-stored state information, whether in a database, an application server, or any other similar single point of contention.」

總結起來說，無共享架構是一種分布式計算架構，這種架構中不存在集中存儲的狀態，系統中每個節點都是獨立自治的，整個系統中沒有資源競爭，這種架構具有非常強的擴張性，目前在web應用中被廣泛使用。

無共享架構的一個重要實踐指導原則就是避免在互聯繫統中使用Session，因為實踐已經證明，在一個集群分布式計算環境中，若Session狀態維護在各個節點伺服器上，為了保證狀態一致性，節點間Session數據需要互相拷貝同步，嚴重影響性能，我們需要儘可能的改造現有架構不要使用Session。

2、對比

shared-nothing、shared-memory、shared-disk是並行系統最常使用的模式。

shared-memory：多個cpu共享同一片內存，cpu之間通過內部通訊機制進行通訊

shared-disk：每一個cpu使用自己的私有內存區域，通過內部通訊機制直接訪問所有磁碟系統

和shared-memory、shared-disk相比，shared-nothing優勢明顯，在針對多用戶並行訪問的時候，通過橫向擴充資源，能夠大大減少響應時間，提升整體吞吐量和效率。

3、分片

shared noting需要確立一種分片策略，使得依據不同的分片策略，減少資源競爭。

三種基本的分片策略結構：

（1）、 功能分片

根據多個功能互相不重疊的特點進行分片，這種方式已經在ebay取得巨大成功。缺點也很明顯，即技術人員需要深入理解應用領域，才能更好地分片。

（2）、 鍵值分片

在數據中找到一個可以均勻分布到各個分片中的鍵值。

（3）、 查表

在集群中有一個節點充當目錄角色，用於查詢哪個節點擁有用戶要訪問的數據。缺點在於這個表可能成為整個系統的瓶頸及單點失效點。

常見的開源DAL（如CobarClient、Fastser-DAL、Uncode-DAL等）實現的「路由」功能就有查表的影子。

4、現狀

SNA目前廣泛存在，重要的常見的應用包括Map-reduce、BigTable、Cassandra、MongoDB等。

（三）、ED-SOA架構

這種架構已經成為各種大中型企業的標配，尤其是業務和關係複雜的互聯繫統，沒有ED-SOA的組織和調度，應用很可能經常面臨著各種問題。

ED-SOA（Event Driven-Service Oriented Architecture），即事件驅動的面向服務架構。

SOA是系統組件化和模塊化構建性理論，它的核心是暴露然後處理（expose and handle）。

EDA是以事件為核心，直觀理解就是負責什麼時候觸發，然後做什麼。

SOA使事件（Event）跨系統流動，系統組件之間通常是同步通信，可以採取事件機制使通信非同步化，提高響應速度。

基於ED-SOA構建松耦合系統可以顯著改善網站可伸縮性。

關於ED-SOA的理論和實踐文章實在太多，本文就不再重複贅述了。

二、負載均衡1、什麼是負載均衡？

負載均衡（Load Balance），顧名思義，是把服務的並發請求均衡地負載到後端多個具有相同能力的服務進行處理分擔，以廉價有效透明的方式擴展網路設備或服務的帶寬，增加吞吐量，增強服務的整體處理能力，提供服務的靈活性和可用性。

常見的典型的負載均衡應用場景：

（1）、web集群：將大量的並發訪問或數據流量分擔到多台節點設備上分別處理，減少用戶等待響應的時間。

（2）、MapReduce：單個重負載的運算分擔到多台節點設備上做並行處理，每個節點設備處理結束後，將結果匯總，返回給?戶，系統處理能?得到大幅度提高。

2、負載均衡演算法

負載均衡演算法是負載均衡設備（包括虛擬設備或相關軟體）在執行負載均衡調度，選擇具體處理的後端服務的時候使用的調度和分發的邏輯。

負載均衡的演算法只是規定了調度和分發的邏輯，在不同的負載均衡方案中都可能使用相同和（或）類似的演算法，它只是負載均衡方案的一部分。

常見的主流負載均衡演算法包括：

（1）、輪詢演算法：Round Robin/Weight Round Robin Scheduling

輪詢演算法通過依次輪叫的方式依次將請求調度不同的後端伺服器(Real Server)。通常可以分為普通輪詢和加權輪詢兩種方式。演算法的優點是簡潔且無狀態。

演算法簡單表示為：i = ( i + 1 ) mod n

（2）、Hash演算法: 隨機數Hash，Sources Hashing Scheduling

Hash演算法，又叫取余演算法。一般是對請求報文中的某項數據(key，一般常用客戶端來源IP)計算Hash值，然後按機器數量(n)取模。

演算法簡單表示為：idx = Hash(key) % n

Hash演算法中，Key的選擇常用實踐如下：

a、請求時間或隨機數

特點是簡單，具有一定分散性，但不穩定，一般用於要求不高的負載均衡場景。

b、來源IP

特點是簡單。如果客戶的分布比較廣，這種方式分散性較好。但如果較多的客戶請求來源於同一IP（公司網路通過路由器上網），分散效果較差。

大多負載均衡設備都支持這種演算法，著名的nginx和LVS等軟體也支持。

（3）、一致性Hash演算法：Consistency Hash Scheduling

一致性Hash演算法最常用於分布式緩存（如memcached、redis等）的定位，但同時也可以在系統或程序中用於負載均衡，該演算法本來的意義就在於分散負載和快速定位。

點擊展開全文

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！