微软 apache Android php linux nginx Python Ubuntu wordpress 编程 java centos shell google Firefox Windows mysql 开源 云计算 程序员

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

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

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

(一)、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之間所有的通訊都斷開了。

如果在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。

SNA

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:單個重負載的運算分擔到多臺節點設備上做並行處理,每個節點設備處理結束後,將結果匯總,返回給⽤戶,系統處理能⼒得到大幅度提高。

LB

 

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等)的定位,但同時也可以在系統或程序中用於負載均衡,該算法本來的意義就在於分散負載和快速定位。

推薦閱讀:截至目前看過的一致性Hash算法最佳介紹請猛擊這裏。


(4)、最少連接或請求數: (Weight)Least Connection/Request Scheduling

最小連接調度是一種動態調度算法,它通過服務器當前所活躍的連接數來估計服務器的負載情況。

算法主要邏輯是,調度設備或服務記錄後端服務器接受請求的計數,每次請求總是發給計數最小的服務器處理。


(5)、最大空閑:Most idle First(基於監控CPU,內存,帶寬等綜合評估)
(6)、平均最快響應:平均最快響應
(7)、最少流量:Least Traffic Scheduling

還有一種常見的就是基於會話的負載實現,但是嚴格來說Session(一般用於WEB)不能算是算法。Session實現負載均衡的主要過程為:首次請求記錄用戶的SessionID,然後再通過輪詢等算法選擇後端服務器,如果用戶後續使用同一SessionID發起請求,則無需再選擇服務器,直接轉發給前面根據SessionID找到的對應的後端服務器。

3、負載均衡模式

負載均衡模式主要是指在整體方案中選擇從服務網絡的哪個層次或哪個產品來實現負載均衡方案。

(1)、外部模式(RR-DNS)

RR-DNS,即DNS輪詢模式,它的原理是利用DNS服務器支持同一域名配置多個獨立IP指向,然後輪詢解析指向IP實現多次訪問的調度和分發,實現負載均衡。

它的主要特點為:

a、負載均衡實現與後端服務完全沒有關系,有DNS在本地解析指向實現輪詢調度。這個方面來看性能最佳效率最高。

b、DNS服務無法檢測到後端服務器是否正常,在TTL失效前,會一直指向失效的服務器,這就要求在實踐生成中,必須解決後端服務器的高可用問題。

c、一般的第三方DNS服務提供商都支持該功能,但如果更新頻率高或附帶更新邏輯,一般會在系統內自鍵DNS服務,然後在註冊為公共DNS服務。

(2)、應用層模式

a、什麽是正向和反向代理?

正向代理:用戶通過代理服務訪問internet, 把internet返回的數據轉發給用戶。正向代理對於整個網絡請求,它的角色實際是客戶端,代理客戶對外的訪問請求。
反向代理:接受internet上用戶的請求,轉發給內部的多臺服務器處理,完成後轉發後端服務器的返回給對應的用戶。反向代理對於整個網絡請求,它的角色實際是服務器,代理接受(accept)所有用戶的請求。

b、反向代理應用模式

常見的反向代理應用模式,比如通過 Apache, nginx等Web服務器軟件實現WEB應用的負載均衡和高可用。

利用反向代理軟件實現負載均衡是性價比較高的模式。

(3)、網絡層模式

a、IP轉換

IP轉換模式的負載均衡一般是在網絡的IP層實現,通過報文改寫的方式實現VIP到多個內部IP的轉發調度,以達到負載均衡的效果。 
它的主要特點包括:

網絡層方案,效率較高,穩定性較好;可與操作系統內核結合;工業級模式和方案;大部分商業設備和產品都以該方式為主;LVS的基本原理也類同。

b、IP轉換之LVS

LVS(Linux Virtual Server),是中國人(98年)寫的工業級的負載平衡調度解決方案,章文嵩博士是該開源軟件創始人。也是目前業界最流行的軟件方式實現負載均衡的模式之一。LVS也是利用IP轉發的原理實現大多數有商業產品實現的能力,並做了部分優化,主要有三種模式的應用。

(a)、通過NAT(Network Address Translation)實現虛擬服務器(VS/NAT) 
(b)、通過IP隧道實現虛擬服務器(VS/TUN)
(c)、通過直接路由實現虛擬服務器(VS/DR)

關於LVS的介紹文章非常多,這裏就不再詳細介紹了,推薦參考閱讀<<構建高性能web站點>>和<<大型網站技術架構>>這兩本書中關於負載均衡的部分章節。

c、IP轉換之負載均衡設備

F5等負載均衡設備同樣是在網絡層實現負載均衡,但一般而言造價較為昂貴,性價比較低。

三、高可用系統設計

1、系統可用性

系統可用性定義:MTTF/(MTTF+MTTR) * 100% 
MTTF: mean time to failure,平均失效前時間,也就是正常運行的時間 
MTTR: mean time to restoration, 平均恢復前時間,也就是故障時間

系統高可用性(High Availability)通常來描述一個IT系統經過專門的設計,減少計劃和非計劃停工時間,保持其服務的高度持續可用性。

影響系統可用性的因素很多,包括硬件、軟件、網絡和環境(比如機房溫度)等,除了常見的CPU、內存、IO、網絡、鎖等因素,還需要考慮各種支持設備和系統、非技術的因素,總之,系統可用性是一個綜合因素影響的結果。

2、高可用的模式

系統高可用性的常用設計模式包括三種,包括:

(1)、主備(Active-Standby)

工作原理:主機工作,備機處於監控準備狀況;當主機宕機時,備機接管主機的一切工作,待主機恢復正常後,按使用者的設定以自動(熱備)或手動(冷備)方式將服務切換到主機上運行。一般需要人工幹預才能回復初始狀態。

(2)、互備(Active-Active)

工作原理:兩臺主機(A標記為主,B標記為備)同時運行各自的服務工作且相互監測情況,當任一臺主機(A)宕機時,另一臺主機(B,啟用並標記為主)立即接管它的一切工作,保證工作實時可用

(3)、集群(Cluster)

工作原理:多臺具有相同能力的服務同時對外提供透明服務,所有服務之間都是Active-Active關系,並分擔處理服務請求,一般通過總控節點或集群軟件(例如zookeeper等)進行高可用的控制。

3、高可用的設計

高可用的設計沒有完美的標準答案。但是根據工程經驗,我們可以總結出高可用設計的一個重要指標:

不要有單點。

不要有單點。

不要有單點。

強調了三遍,現在記住了嗎?

如果是在設計開發實現和維護大中型web系統,通常我們會從互聯系統中最容易出現問題,同時也最不容易橫向擴展的節點下手(包括網絡和存儲系統),排查並解除系統中的薄弱環節,爭取保證整個系統中絕不出現單點這一死角,或者出現單點,但也可以通過成熟的優化手段(緩存、隊列、sharding、負載均衡和異地容災等)實現高可用。

你可能還是會有疑問:是不是系統中沒有單點了保證高可用了就一定不出事情了呢?

答案是,還是可能會出事,而且可能都是大事。今年的黑色五月份的幾起重大IT事故,無情地告訴我們,再高明的設計,碰到物理破壞或者權限控制不當而誤操作或者DDoS都有可能讓開發和設計人員的所有心血付之東流。

延伸阅读

    评论