分散式架構的演進過程
一、計算機的基石——馮諾依曼模型
馮·諾依曼於1946年提出儲存程式原理,把程式本身當作資料來對待,程式和該程式處理的資料用同樣的方式儲存。 馮·諾依曼體系結構馮·諾依曼理論的要點是:計算機的數制採用二進位制;計算機應該按照程式順序執行。人們把馮·諾依曼的這個理論稱為馮·諾依曼體系結構。
直到現在我們的計算機都屬於這個體系結構,只不過效能大大提升。
二、bigger than bigger——計算機的產生 大型主機時代
世界上第一臺通用計算機“ENIAC”於1946年在美國賓夕法尼亞大學誕生。發明人是美國人莫克利(JohnW.Mauchly)和艾克特(J.PresperEckert)。美國國防部用它來進行彈道計算。它是一個龐然大物,用了18000個電子管,佔地170平方米,重達30噸,耗電功率約150千瓦,每秒鐘可進行5000次運算。 ENIAC之後,電子計算機進入了由IBM這位藍色巨人主導的大型機時代。
大型機之父 吉恩 阿姆達爾在1964年4月7日,製造出第一臺IBM大型機SYSTEM/360,使得IBM在20世紀50-60年代統治整個大型計算機工業。
由於大型機高可靠性和超強的計算能力,即使在X86架構和雲端計算飛速發展的情況下,IBM大型機仍然牢牢佔據著一定的高階市場份額。
在20世紀80年代時,計算機架構同時向兩個方向發展:
(1) 以CISC(微處理器執行的計算機語言指令集)CPU為架構 價格比較便宜 面向個人的計算機(PC)
(2)以RISC(精簡指令集計算機)CPU為架構 架構昂貴 面向企業的小型UNIX 伺服器
之後,雖然大型主機具備超強的計算和I/O處理能力,並且擁有很好的穩定性和安全性。
但是,這種架構日益難以適應人們的需求:
(1)大型機的複雜性,使得其運維人員的培養成本很高
(2)大型機很貴,一般人或者企業根本玩不起,基本上只有政府或者大型國企才能弄一臺
(3)單點問題 一臺大型主機故障,則整個系統癱瘓
(4)PC的效能不斷提升,許多企業完全不必要再使用大型機來搭建系統架構
三、分散式的意義和常見概念
分散式系統的意義
1、升級單機處理效能的價效比越來越低
單機處理能力主要依靠CPU、記憶體和磁碟,通過更換硬體做垂直擴充套件來提升效能的代價越來越高
2、單機處理能力存在瓶頸
3、單機系統存在穩定性和可用性問題
下面以飯店為例,來解釋常見概念
叢集
從前有一個小飯店,客少店小,因此只有一個廚師,而且除了炒菜,洗菜切菜也得自己來,然後客人逐漸多了起來,這時候就多招了兩個廚師,這個廚師也是炒菜洗菜切菜什麼都幹,這三個廚師的關係,就叫做叢集。
分散式
小飯店生意越來越好了,為了增加效率,專人幹專事,給每一位廚師配一個配菜員一個切菜員,這個時候廚師和配菜師 切菜員是分散式的關係,而配菜師與配菜師之間的關係還是叢集
在這個過程中,一個配菜師因故請假了,但是其餘的配菜師還是該啥就幹啥,可能沒請假的配菜師任務會被均勻的加量了,但是他們的任務和職責是不變的
節點
節點是指一個可以獨立按照分散式完成一組邏輯的程式個體。在具體的專案中,一個節點表示的是一個作業系統上的程序。
副本機制
副本(replica/copy)指在分散式系統中為資料或服務提供的冗餘。
資料副本指在不同的節點上持久化同一份資料,當出現某一個節點的資料丟失時,可以從副本上讀取到資料。資料副本是分散式系統中解決資料丟失問題的唯一手段。
服務副本表示多個節點提供相同的服務,通過主從關係來實現服務的高可用方案
中介軟體
中介軟體位於作業系統提供的服務之外,又不屬於應用,他是位於應用和系統層之間為開發者方便的處理通訊,輸入輸出的一類軟體,能夠讓使用者關心自己應用的部分。
即:分散式:一個業務拆分為多個子業務,部署在不同的伺服器上
叢集:同一個業務,部署在多個伺服器上
分散式結構:將一個完整的系統,按照業務功能,拆分成一個個獨立的子系統,在分散式結構中,每個子系統就被稱為"服務"。這些子系統能夠獨立執行在web容器中,他們之間通過RPC方式通訊。
下面我們將電商系統為例,詳細介紹分散式發展過程
假設我們的電商系統中只有三個模組:使用者模組,交易模組和商品模組
階段一:單應用架構
在網站建立初期,經常把所有的東西都在一臺機器上部署,這個時候的架構是單應用架構,優點是效率非常高
階段二:應用伺服器和資料庫伺服器分離
網站上線了,隨著時間推移,訪問量開始逐漸增大,伺服器逐漸的就扛不住了,這個時候就要考慮加機器了,這就進入了第二階段。
這個階段增加機器的主要目的是將web伺服器和資料庫伺服器進行拆分,這樣不僅提高了單機的負載能力,也提高了容災能力
第三階段:應用伺服器叢集
然而隨著訪問量的持續增加,單臺伺服器已經無法滿足需求。假設資料庫伺服器的還未遇到效能問題
此時可以增加應用伺服器,這就進入第三階段——應用伺服器叢集。
在這個階段有些問題就逐漸顯現出來了,比如:
(1)使用者的請求該由哪一臺機器進行處理? ——負載均衡(F5/apache/nginx)
(2)如果使用者每次請求的機器不同,那麼session如何維護?
1、session同步
2、通過第三方儲存(redis等)儲存session
3、跳過容器物件
這樣架構就變為了以下模式。
階段四:資料庫讀寫分離
隨著業務量進一步增加,資料庫伺服器的I/O能力會存在瓶頸。
首先考慮的是加機器,但是如果直接一分為二,每次讀寫還要額外判斷資料應該在哪臺機器上。
基於電商系統資料庫讀多寫少的特點,可以將一個伺服器作為寫庫,另一個庫設為讀庫,並設定主從同步進行複製。
這樣也會帶來資料庫不一致的問題
1.主從資料庫之間的資料同步;可以使用mysql自帶的master-slave方式實現主從複製
2.對應資料來源的選擇;採用第三方資料庫中介軟體,例如mycat
實際上,如果讀庫的量遠大於寫庫的訪問量,需要設定多個讀庫時,可以採取以下的結構
階段五:使用搜索引擎緩解讀庫的壓力
資料庫做讀庫的話,常常對模糊查詢效率不是特別好,像電商類的網站,搜尋是非常核心的功能,即便是做了讀寫分離,這個問題也不能有效的解決。那麼這個時候就需要引入搜尋引擎了。
使用搜索引擎能夠大大提高我們的查詢速度,但是同時也會帶來一些附加的問題,比如維護索引構建。
階段六:引入快取機制
隨著訪問量的持續增加,逐漸出現許多使用者訪問統一部分內容的情況,對於這些熱點資料,沒必要每次都從資料庫去讀取,我們可以使用快取技術,比如memcache,redis來作為我們應用層的快取;另外在某寫場景下,比如我們對使用者的某些IP的訪問頻率做限制,那這個放記憶體中又不合適,放資料庫又太麻煩,這個時候可以使用Nosql的方式比如mongDB來代替傳統的關係型資料庫。
至此,分散式架構的基本框架已經形成。
階段七:資料庫的水平、垂直拆分
資料庫永遠是最容易造成瓶頸的地方之一,例如阿里巴巴09年“去IOE運動”就是為了解決資料庫擴充套件性瓶頸問題。
在整個架構的編號過程中,所有的資料還是在同一個資料庫中的,因此我們可以考慮對資料進行拆分
其中:
垂直拆分就是把不同業務的資料拆分到不同的資料庫中
水平拆分則是把同一個表中的資料拆分到兩個甚至更多的資料庫中,有些公司的資料庫是按照日期分為31*N個數據庫
階段七:應用拆分階段
隨著需求的不斷提出,應用的體量也越來越大,因此需要按照領域對業務進行拆分