大型互連網技術架構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.引入反向 Proxy與CDN:繼續提升訪問速度，提供更好使用者體驗。這裡強調一下，網站訪問速度/延遲與使用者流失率正相關。目前主要主流手段為CDN與反向 Proxy；二者原理都是基於緩衝機制。區別在於，CDN是部署在網路供應商機房，而反向 Proxy則不熟在自己網站機房。

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

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

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

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

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

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

3. 互連網架構

我們來看一張完整的分布式互連網架構圖吧：

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

另外，互連網技術發展到此處，已經進入雲端運算，Container Service階段；中小企業再野不用，也不需要從新造輪子，直接用大公司提供的雲端運算，Container Service可，從而專心業務發展。

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

公眾號：技術極客TechBooster