1. 程式人生 > >大型網際網路技術架構1-架構概述

大型網際網路技術架構1-架構概述

上圖座標指向矽谷,最近開始研究網際網路分散式架構,風口浪尖,高大上;特與極客朋友們分享,共勉。

網際網路架構

近些年來,網際網路的高速發展,大資料時代,Booming Years,我們作為技術極客,需要跟得上節奏,趨勢。

1 大型網站特性

大型網站,無論是電商還是社交網站等通常都具有以下特性,如高併發,低延遲,海量資料,可擴充套件性,HA 7*24;用資料來說明的話就是:Google日均UV數3億,日均PV高達35+億;Facebook週上傳圖片10億以上;淘寶雙十一,第一分鐘UV高達1000萬。而這些都是我們傳統應用無法想象,無法望其項背的。

2 架構演化

還記得一位美國老闆說過,"Project is evolutionary not revolutionary!

". 網際網路領域也是一樣的。隨著業務的發展,併發量,資料儲存量等;系統開始演進,分而治之。其實,計算機世界包括硬體,網路,軟體無不是引入新的層,物件,服務;從而分而治之來化繁為簡解決問題的;而真實世界的事又何嘗不是如此呢?當然,分而治之,拆分解決了一些問題,但是又會引入另外一種複雜/互動的問題。當然,分而治之,拆分解決了一些問題,但是又會引入另外一種複雜/互動的問題。

1.一臺伺服器: 曾經記得若干年前的網際網路,或者其實現在的小型網站都是以經典的LAMP組合即搞定,即Linux, Apache, MySQL, PHP,甚至應用+檔案 + 資料庫全部在一臺伺服器搞定。

2.三臺伺服器: 隨著業務發展,

併發量,資料儲存量等都不能滿足時,開始拆分;首先將應用與資料分離;拆成三臺伺服器:應用伺服器,檔案伺服器和資料庫伺服器。其中,應用伺服器需要計算,因此需要更強大CPU;資料庫伺服器則需要快速磁碟與資料快取;而檔案伺服器則需要更大硬碟。 

3.引入快取:繼續改進,引入快取機制改進訪問解決熱門業務。目前架構:


4. 叢集:到了步驟3,看起來一切不錯。可隨著業務量,訪問量的繼續飆升,正所謂快樂的煩惱,應用伺服器吃不消,直接宕機,導致所有業務癱瘓,正所謂單點問題。我們引入叢集,解決單點問題,提供可擴充套件性。我們稍微看一下目前的架構:

注意,此時我們需要引入負載均衡器來協呼叫戶訪問哪一個應用伺服器;如果有錢的主可以選擇F5, 或者LVS, Nginx等。至此,一起看起來都是那麼完美。

5.資料庫讀寫分離:隨後而來的是,網站的訪問瓶頸在高併發下繼續存在。究其原因,雖然引入快取解決了大部分資料讀訪問,讓然會有一部分讀操作如快取麼有命中,或者快取過期之類的需要訪問資料庫,當然,所有的寫操作都需要直接訪問資料庫;如何解決?繼續分而治之了。目前主流資料庫都已經提供了主從熱備功能,自動備份同步;我們正好可以利用此功能。讀都走從資料庫,寫走主資料庫。如此,巧妙的解決了讀寫分離。


6.引入反向代理與CDN:繼續提升訪問速度,提供更好使用者體驗。這裡強調一下,網站訪問速度/延遲與使用者流失率正相關。目前主要主流手段為CDN與反向代理;二者原理都是基於快取機制。區別在於,CDN是部署在網路供應商機房,而反向代理則不熟在自己網站機房。

可以看出,引入CDN與反向代理都是希望儘早返回資料給使用者。科普一下:CDN(Content Delivery Network是個古老的東西,在網際網路發展之初就已經出現了。一群MIT的精英份子發現如果要讓任何地方的人都可以很快的開啟自己的網站的話,就需要象在世界各地蓋教堂一樣,把自己的網頁釋出到離信眾最近的地方去。所以,他們用一種簡單的快取映象的辦法實現了這種釋出。最早的入主這個教堂網路的是Yahoo!CDN在利用DNS的轉授權來引導最終訪問者找到最理想的快取或者映象站點,它是基於域名的一種服務。反向代理:反向代理(Reverse Proxy)方式是指以代理伺服器來接受internet上的連線請求,然後將請求轉發給內部網路上的伺服器,並將從伺服器上得到的結果返回給internet上請求連線的客戶端,此時代理伺服器對外就表現為一個反向代理伺服器。目前用的最廣的要算是Nginx,出自俄羅斯人Igor Sysoev之手筆。

7.分散式檔案/資料庫系統:繼續開刀,當然所用的變革都是因為時機到了,業務發展,我們的系統從而隨著演進,可不是為了演進而演進啊。檔案系統比較簡單,引入分散式檔案伺服器。資料庫則較難,不得已才拆分。拆分資料庫後,需要引入統一資料訪問模組。

8 . NoSQL與搜尋引擎:著名的NoSQL終於登場,關係型資料再怎麼拆分,隨著資料量的增加,仍然面臨效能瓶頸,如多表關聯,全表掃描等棘手問題。NoSQL表示無壓力,如HBase,源自網際網路,天然為網際網路而生,天生俱有分散式,可伸縮性。

9.業務分拆:好吧,能想的技術架構都已經用了,都已經8板斧了,沒轍了。只好開刀業務,哈哈。其實,業務包括業務條線,業務流程,如果能把業務規劃的很好,包括流程,可以解決很多問題,包括效能;比如分時搶購促銷等。回到業務拆分,通常根據業務場景,如電商業務包括了首頁,商鋪,訂單,交易,購物車等產品線來拆分。可拆分之後,如何串聯起來呢? 應用之間通常採用幾種辦法,如通過超連結;訊息佇列;又或者是通過同一個資料庫來關聯共享。


10. 分散式服務:出大招了,正所謂分久必合。拆了這麼多,這麼細,必然造成複雜度指數級提升,部署,維護越來越困難,而且一定是有很多共同的功能,如使用者管理,登陸管理,產品管理,交易支付等公共業務。好吧,整合服務,通過分散式服務呼叫業務服務。

到此,此架已經可以解決絕大多數網際網路問題,當然,看圖容易,真實實現架構則需耗費大量人力,物力,財力。阿里當年也經過了數十年的演變才至此。

3. 網際網路架構

我們來看一張完整的分散式網際網路架構圖吧:


清楚麼?可以看出,創新的業務產生了創新的技術,是業務與技術的完美結合。此處提一點,不要本末倒置,有些在業務方向還沒有搞清楚的情況下,就盲目搭建大型網際網路架構,可謂有錢 + 燒錢。還有一些小型初創,為了技術而技術,盲目模仿Facebook, BAT,得不償失。

另外,網際網路技術發展到此處,已經進入雲端計算,容器服務階段;中小企業再野不用,也不需要從新造輪子,直接用大公司提供的雲端計算,容器服務可,從而專心業務發展。

好了,拋磚引玉,簡單聊了一下,小朋友醒了,要開始“三陪”了。注:很多想法參考自網上,以及技術叢書。


公眾號:技術極客TechBooster