短短幾十年國內互聯(lián)網發(fā)生了翻天覆地的變化，特別是國家支持互聯(lián)網發(fā)展，提出了“互聯(lián)網+”行動計劃，國內各行各業(yè)的互聯(lián)網更是日新月異。作為一個九零后小白沒有親身經歷互聯(lián)網的演變歷程，如今看的像淘寶、京東、騰訊這樣的大型網站充滿了無數(shù)的好奇心，這些網站是怎么運作的，如何處理大量用戶的請求，如何解決海量的數(shù)據(jù)庫處理···于是才有對于大型網站架構核心原理以及實例分析一系列的筆記記錄。所有筆記記錄參考《大型網站技術架構核心原理以及案例分析》，該系列文章沒有太多的代碼展示，著重是對理論知識的描述。

互聯(lián)網無處不在，人們的生活受互聯(lián)網的席卷發(fā)生了巨大的變化，從信息檢索到即時通信，從電子購物到文化娛樂，互聯(lián)網已近滲透生活的每個角落，在互聯(lián)網如此跨越式發(fā)展進程中，不堪負重的網站架構也帶來了負面的一面，網站頻繁宕機、請求操作延時、用戶信息泄漏等等現(xiàn)象演繹的淋漓盡致。

針對上述種種現(xiàn)象，如何打造一個高可用、高性能、易擴展、可伸縮以及安全的網站？如何讓網站隨業(yè)務需求所需而靈活變通？這些將是打造一個大型網站急需要考慮的問題根本所在，通過對《大型網站技術架構核心原理以及案例分析》這本書的學習將一層層揭開其中的面紗。

俗話說的好，“汝欲得之，必先知之”，換而言之也是一個道理，想要解決那些種種現(xiàn)象，你得先清楚大型網站的架構演化。

大型網站軟件系統(tǒng)的特點

相比之傳統(tǒng)的應用系統(tǒng)，大型網站系統(tǒng)有以下特點：

高并發(fā)，大流量：面臨高并發(fā)用戶，大流量訪問。像google、騰訊同時訪問量可能出現(xiàn)億單位次數(shù)。

高可用：系統(tǒng)支持每天24小時運作。

海量數(shù)據(jù)：需要存儲海量數(shù)據(jù)并管理，需要大量的服務器來支持。

用戶分布廣泛，網絡情況復雜：許多網站都是全球性服務的，用戶分布的范圍很廣。例如：淘寶網

安全性惡劣：互聯(lián)網追求開放性，因而易受到外界攻擊，大型知名網站受到攻擊更是家常便飯。

漸進式發(fā)展：幾乎所有的大型網站都是漸進式發(fā)展，慢慢壯大的，這也和互聯(lián)網架構的發(fā)展演化對應。

大型網站架構演化發(fā)展歷程

前面已經描述了大型網站系統(tǒng)的特點，而對一個大型網站系統(tǒng)，其架構也是重要的一個環(huán)節(jié)。

大型網站技術主要的挑戰(zhàn)來自于龐大的用戶、高并發(fā)以及海量的數(shù)據(jù)這三個方面。大型網站的形成就像一顆大樹的成長，歷盡長時間的磨練，最后枝繁葉茂，服務他人。

初始網站架構結構

起初的網站鑒于用戶量、訪問量較少，只需要一臺服務器足以，應用程序、數(shù)據(jù)庫、文件等其所有資源放在一太服務器上就已經足夠滿足此時的需求，這時候網站的架構就幾個簡單組成部分如下圖

應用和數(shù)據(jù)服務分離

隨著網站業(yè)務需求的發(fā)展，越來越多的用戶進行訪問，此時一臺服務器漸漸不能滿足需求，數(shù)據(jù)的存儲空間出現(xiàn)屏障。于是應用程序、數(shù)據(jù)庫、文件三者面臨分離，各自為首分配一臺服務器，這三臺服務器對硬件的要求各取所需，應用服務器處理大量的業(yè)務邏輯，需求更快更大的CPU；數(shù)據(jù)庫服務器對數(shù)據(jù)庫的處理需要快速搜索以及緩存，需求對內存更大，對硬盤讀寫能力更迅速；文件服務器需求放入大量的用戶資源，對硬盤空間要求更大。此時的網站的架構組成部分展示如下圖

使用緩存

網站的架構進一步改進后可以滿足了業(yè)務的發(fā)展，但是隨著網站知名度提升，用戶量的進一步增加，訪問數(shù)據(jù)相比之前愈加頻繁，數(shù)據(jù)庫壓力急劇上升導致網站訪問出現(xiàn)延遲，用戶的性能體驗出現(xiàn)下滑，面臨此時網站出現(xiàn)的性能問題，網站架構設計需要再一次的進化，鑒于網站訪問也遵循二八定律，例如：新浪微博，只有經常登錄的用戶才會發(fā)微博，看微博，而這些用戶對于總用戶數(shù)只是冰山一角。既然出現(xiàn)這一現(xiàn)象，那么緩存這部分的數(shù)據(jù)是不是可以解決這現(xiàn)象呢？網站緩存可以分為本地緩存和分布式緩存這兩種，二者的區(qū)別是本地緩存速度快但是受服務器內存限制緩存的數(shù)量有限，而分布式緩存采用的是集群處理，理論上是可以避免內存瓶頸。此時網站的架構組成部分如下圖

應用服務器集群改善網站并發(fā)能力

使用緩存后，數(shù)據(jù)庫的壓力得到緩解，但是在面臨網站高峰期時，應用服務器處理單一的請求連接出現(xiàn)瓶頸，萬事都有解決的辦法，只是看你愿不愿去想，愿不愿去嘗試做，采用集群，集群多臺應用程序服務器分布原有的應用程序服務器，從而實現(xiàn)了系統(tǒng)的可伸縮性，網站架構此時演化成這樣如下圖

#p#

數(shù)據(jù)庫讀寫分離

使用緩存，雖然使用戶請求數(shù)據(jù)操作大部分不直接通過數(shù)據(jù)庫，但是仍有一部分數(shù)據(jù)（緩存過期、緩存數(shù)據(jù)沒有命中）讀寫操作需要訪問數(shù)據(jù)庫，面對這部分數(shù)據(jù)，可能出現(xiàn)數(shù)據(jù)訪問負載壓力，把數(shù)據(jù)庫讀寫操作分離性能效果理當會如何呢？效果無言而喻。

CDN和反向代理加速網站響應

網絡覆蓋范圍地區(qū)廣泛，造就了網絡環(huán)境復雜，從而用戶訪問網站性能體現(xiàn)也各有差異，鑒于這問題，網站架構使用CDN和反向代理以技術加速網站響應，二者原理都是緩存，CDN可以從距離用戶最近網絡提供點獲取數(shù)據(jù)；反向代理則是首先從反向代理服務器中獲取數(shù)據(jù)。

分布式文件、數(shù)據(jù)庫系統(tǒng)

任何單一的服務器最后都是滿足不了業(yè)務需求發(fā)展。雖然前面數(shù)據(jù)庫讀寫分離能夠改善數(shù)據(jù)庫負載壓力但是隨著業(yè)務不斷壯大最終還是難以維持此時使用分布式數(shù)據(jù)庫，該技術不到不得以建議不使用，而對于這個技術解決方案更常用的使用業(yè)務拆分，將不同的業(yè)務數(shù)據(jù)庫部署在不同的物理服務器上。

NoSQL和搜索引擎

該技術對于可伸縮的分布式提供更好的支持，減輕應用程序管理諸多數(shù)據(jù)源的麻煩。

業(yè)務拆分

大型網站日益發(fā)展壯大，業(yè)務需求越來越復雜，使用分而治之手段分離整個網站的業(yè)務變成不同的產品線。具體到技術上，將一個網站拆分成許多不同的應用，每個應用獨立部署，而應用與應用之間通過超鏈接關聯(lián)，不過最多的還是通過訪問同一個數(shù)據(jù)存儲來構成一個關聯(lián)的完整系統(tǒng)。

分布式服務

一個應用系統(tǒng)需要執(zhí)行相同業(yè)務操作，那么可以將共同的業(yè)務提取出來，獨立部署，由這些可復用的業(yè)務連接數(shù)據(jù)庫，提供共用業(yè)務服務，而應用系統(tǒng)只需要管理用戶界面，通過分布式調用共用業(yè)務服務完成具體業(yè)務操作。

大型網站結構演化到這里，基本上大多數(shù)的技術問題都得以解決了，但是事物發(fā)展到一定的階段就會擺脫初衷向更強的方向發(fā)展。目前許多的大型網站都建立自己的云平臺，將計算作為一種資源進行出售。

大型網站架構演化歷經了長時間磨練才發(fā)展如此，在過程中也是出現(xiàn)一些易步入的誤區(qū)

一味的追隨大公司解決方案，大公司的經驗和成功固然重要，但是不能盲目的追從，要與實際的具體業(yè)務需求有所改動；

 為了技術而技術，網站技術是為業(yè)務而存在的，但是一味的追求新技術，可能會導致結構技術之路越走越難；

企圖用技術解決所有問題，技術雖是解決業(yè)務問題的，但也不是萬能鑰匙，有些業(yè)務的問題也是可以通過業(yè)務手段解決。