何為大型網站
大型網站特性
既然說的是大型網站架構，那麼架構的背後自然是解決人因面對大型網站特性而帶來的問題。這樣可以先給大家說下大型網站的特性，這些特性帶來的問題就是人要解決的問題：
- 高併發、大流量：PV 量巨大；
- 高可用：7*24 小時不間斷服務；
- 海量資料：檔案數目分分鐘 xxTB；
- 使用者分佈廣泛，網路情況複雜：網路運營商；
- 安全環境惡劣：黑客的攻擊；
- 需求快速變更，釋出頻繁：快速適應市場，滿足使用者需求；
- 漸進式發展：慢慢地運營出大型網站；
大型網站目標
既然說到了大型網站的特性，那麼**解決這些特性帶來的問題要達到什麼目標呢？**如下：
每個目標背後面臨著技術、設計、維護等諸多方面的挑戰； 而目標本身的期望值也會根據實際情況進行調整，這也意味著網站架構建設是個不斷調整的過程。
有了問題，也定了偉大的目標，那麼網站在不同階段面對不同的問題，是如何解決的？又是如何一步步成長為大型網站架構，實現這些偉大的目標呢？
如何大型網站架構
大型網站架構的概念對於每一個開發者來說很籠統、很模糊，正如盲人摸象，看到的、瞭解到的只是很小的一部分，大部分情況下我們只是負責架構中的一小塊內容，所以很難清晰地給出具體定義。這就是所謂“不識廬山真面目 只緣身在此山中”的尷尬吧。所以我們要跳出來，站在巨集觀的角度，從整體到細節實現來認識大型網站架構。
那麼從巨集觀的角度怎麼去認識大型網站架構呢？正如前面幾篇《細品架構系列》所描述對架構的認識，按照問題識別—>概念認知—>架構切分的思路，來分析大型網站架構的誕生：
- 問題識別：當前什麼問題、誰的問題、問題邊界；
- 概念認知：通過分析問題，會產生哪些概念，統一概念認知，達成溝通交流規範；
- 架構切分：根據概念來解決問題，如何架構切分，產生哪些架構，提出具體解決方案；
PS：上面的三個步驟具體如何識別、認知、切分，請詳細參考前面幾篇《細品架構系列》文章，可能使你會對架構有重新的認識。
在進行分析大型網站架構的演進之路前，首先我們要明確的兩個價值觀：
- 核心價值：隨網站所需靈活應對；大型網站不是從無到有一步就搭建好一個大型網站，而是能夠伴隨小型網站業務的漸進發展，慢慢地演化成一個大型網站；
- 驅動力量：網站的業務發展— 業務成就了技術，事業成就了人，而不是相反；
還有，大型網站架構演進必須避免的幾個誤區：
- 一味追隨大公司的解決方案；
- 為了技術而技術-->常見問題；
- 企圖用技術解決所有問題：技術是用來解決業務問題的，而業務的問題，也可以通過業務的手段去解決；
架構體系演進
單機時代
草根時期，快速開發網站並上線。當然，通常只是先試水，使用者規模也沒有形成，經濟能力和投入也非常有限。應用程式、資料庫、檔案等所有資源都集中在一臺 Server上，典型案例：基於 LAMP 架構的 PHP 網站；
優點：簡單、快速迭代達成業務目標；
缺點：存在單點、談不上高可用；
技術點：應用設計要保證可擴充套件；
快取出場
有一定的業務量和使用者規模了，想提升網站速度，於是，快取出場了。
優點：簡單有效、方便維護； 缺點：存在單點、談不上高可用； 技術點：客戶端（瀏覽器）快取、前端頁面快取、頁面片段快取、本地資料快取/資料庫快取、遠端快取；
如上圖，快取可以分為：
- 頁面快取：客戶端快取，減少對網站的訪問；
- 本地快取：訪問速度快，但資料量有限，減少對DB查詢；
- 遠端快取：遠端訪問，可以叢集，因此容量不受限制；
資料服務與應用分離
市場反響還不錯，使用者量每天在增長，資料庫瘋狂讀寫，逐漸發現一臺伺服器快撐不住了。於是，決定把資料服務和APP做分離。
優點：簡單有效、方便維護、提高不同Server對硬體資源的利用率；
缺點：存在單點、談不上高可用；
技術點：檔案伺服器部署、資料庫伺服器，擴充套件資料訪問模組；
分離後三臺 Server 對硬體資源的需求各不相同：
- 應用伺服器：需要更快更強大的 CPU；
- 資料庫伺服器：需要更快的硬碟和更大的記憶體；
- 檔案伺服器：需要更大的硬碟；
資料庫讀寫分離
單臺資料庫也感覺快撐不住了，一般都會嘗試做“讀寫分離”。由於大部分網際網路“讀多寫少”的特性所決定的。Salve的臺數，取決於按業務評估的讀寫比例。
優點：簡單有效、降低資料庫單臺壓力；
缺點：讀寫分離，增加程式難度，架構變複雜，維護難度增加；
技術點：資料庫主從同步部署，擴充套件資料訪問模組，實現讀寫分離；
應用服務叢集
資料庫層面是緩解了，但是應用程式層面也出現了瓶頸，由於訪問量增大，加上早期程式設計師水平有限寫的程式碼也很爛，人員流動性也大，很難去維護和優化。所以，很常用的辦法還是“堆機器”。
優點：增加伺服器和HA機制，系統效能及可用性得到保證；
缺點：應用之間快取、Session一致性問題；
技術點：負載均衡；
通過叢集解決高併發、海量資料問題的常用手段，實現系統的可伸縮性。通過負載均衡排程器，可將使用者訪問分發到叢集中的某臺 Server 上，應用伺服器的負載壓力不再成為整個網站的瓶頸。
集中式快取、Session集中儲存
加機器誰都會加，關鍵是加完之後得有效果，加完之後可能會引發一些問題。例如非常常見的：叢集應用之間頁面輸出快取和本地快取一致性的問題，Session儲存的問題......。
優點：應用之間快取、Session一致，儲存無限制，可以擴充套件；
缺點：不如本地快取訪問快，快取伺服器、Session伺服器等仍存在單點問題；
技術點：快取伺服器部署、Session集中儲存方案；
動靜分離
動靜分離也是提高網站響應速度的一種常用方式。將動態請求與靜態請求分離開，儘量減少對應用伺服器的壓力。同時，可以再進一步對靜態請求，進行快取，以加快響應速度。可以需要開發人員配合（把靜態資源放獨立站點下），也可以不需要開發人員配合（利用7層反向代理來處理，根據字尾名等資訊來判斷資源型別）。
優點：減輕應用負載壓力，針對靜態檔案快取；
缺點：靜態檔案快取更新失效問題；
技術點：動靜分離、靜態檔案快取方案；
反向代理和CDN加速網站響應
使用反向代理和CDN加速網站響應：CDN 和反向代理的基本原理都是快取，區別在於：
- CDN部署在網路提供商的機房；
- 反向代理則部署在網站的中心機房；
使用 CDN 和反向代理的目的都是儘早返回資料給使用者，一方面加快使用者訪問速度，另一方面也減輕後端伺服器的負載壓力。
優點：減輕應用負載壓力，異地快取有效解決不同地方使用者訪問過慢的問題；
缺點：成本大幅增加，架構進一步複雜化，也維護難度進一步增大，靜態檔案快取更新失效問題；
技術點：CDN、反向代理方案；
使用NoSQL和搜尋引擎
到這裡，已經基本做到了DB層面和應用層面的橫向擴充套件了，可以開始關注一些其它方面，例如：站內搜尋的精準度，對DB的依賴，開始引入全文索引、NoSQL。
NoSQL和搜尋引擎都是源自網際網路的技術手段，對可伸縮的分散式特性具有更好的支援。應用伺服器則通過一個統一資料訪問模組訪問各種資料，減輕應用程式管理諸多資料來源的麻煩。
優點：降低DB依賴；
缺點：單點問題，談不上高可用；
技術點：NoSQL、搜尋引擎、分散式；
到目前為止，一個能夠承載日均百萬級訪問量的中型網站架構基本介紹完了。
如何保證高可用
在做擴充套件滿足了基本的效能需求後，我們會逐漸關注“可用性”（也就是我們通常聽別人吹牛時說的SLA、幾個9）。如何保證真正“高可用”，也是個難題。
對關鍵應用/服務，做叢集冗餘負載，這也是保證高可用比較常用的手段：
- 檔案系統、資料庫系統叢集；
- 靜態內容伺服器叢集；
- CDN伺服器叢集；
- 反向代理伺服器叢集；
- 負載均衡排程器叢集；
- 分散式NoSQL伺服器叢集；
- 搜尋引擎伺服器叢集；
- 分散式快取伺服器叢集；
- 分散式Session伺服器叢集；
優點：叢集負載，保證高可用；
缺點：資料一致性、資料有狀態問題；
技術點：負載排程器、叢集方案；
截止目前為止，都沒有怎麼去改動應用程式的架構，或者說通俗點，都不怎麼需要大面積的修改程式碼。
如果上面那些手段都用光了，還是支撐不住怎麼辦？不停的加機器也不是辦法啊？
應用垂直拆分
隨著業務越來越複雜，網站的功能越來越多，雖然部署層面是採用的叢集，但是應用程式架構層面還是“集中式”的，這樣會導致很多耦合，不便於開發、維護，而且容易“一榮俱損”。所以，通常會把網站拆分出不同的子站點來單獨宿主。
通過分而治之的手段將整個網站業務分成不同的產品線，如首頁、商鋪、訂單、賣家、買家等 拆分成不同的產品線，分歸不同的業務團隊負責。各個應用之間可以通過建立一個超連結建立關係，也可以通過訊息佇列進行資料分發。
優點：降低耦合、分壓；
缺點：應用架構複雜；
技術點：業務抽取拆分；
業務垂直分庫
應用都拆了，由於單個資料庫的連線，QPS，TPS，I/O處理能力都非常有限，DB層面也可以去做垂直分庫操作。
優點：降低DB耦合、分壓DB；
缺點：資料訪問模組複雜；
技術點：業務抽取拆分；
分散式服務化
拆分應用和DB之後，其實還是會有很多問題。不同的站點，裡面可能會有相同邏輯和功能的程式碼。當然，對於一些基礎的功能我們可以封裝DLL或者Jar包去到處提供引用，但是這種強依賴也很容易造成一些問題（版本問題、依賴關係等處理起來非常麻煩）。
既然每一個應用系統都需要執行許多相通的業務操作，比如使用者管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。這樣，傳說中的SOA的價值就得到體現了。
優點：服務統一管理，提供重用度；
缺點：應用架構更復雜；
技術點：業務抽取拆分、服務化技術方案；
訊息佇列
應用、服務之間還是會出現一些依賴問題，這時候，高吞吐量的解耦利器出現了。
優點：提高吞吐量、應用、服務之間解耦；
缺點：存在訊息消費延遲問題；
技術點：訊息佇列技術方案；
分庫分表
最後，再介紹一個大型網際網路公司都用的絕技--分庫分表。個人經驗，不是業務發展和各方面非常迫切，不要輕易走這一步。
因為分庫分表誰都會幹，關鍵是拆完之後怎麼辦。目前，市面上還沒有完全開源免費的方案，能讓你一勞永逸地解決資料庫拆分問題。
分庫分表：
- 橫向拆分；
- 縱向拆分；
- 分散式資料庫訪問層；
- 資料庫中介軟體（代理）；
網站架構總結
上面講述了在網站業務發展的不同階段，會面臨不同的問題，針對不同的問題，會選擇不同的架構。大型網站架構就是在不同階段時解決不同問題的過程中慢慢演進來的。
最後幾句話，送給有緣的你：
- 一切以解決業務目標為首要任務；
- 沒有以業務為目標的任何架構、技術，都是毫無意義的耍流氓；
- 再牛逼的架構、再牛逼的技術，不能夠解決業務的問題，你也只能算是會架構、會技術的工匠，而不能算是真正意義上的架構師；
- 業務成就了技術，平臺成就了人，事業成就了人，而不是相反；
本文思維導圖，如下：
