背景 ：
1 互聯網跨越式發展爲人民帶來了巨大的便利
2 網民數量的日益劇增
3 不堪重負的網站架構
4 某些電商網站每逢促銷必宕機的現象，12306網站的頻繁故障與操作延遲以及娛樂圈出現特大新聞造成微博服務器宕機等等
目標 ： 打造一個高可用、高性能、易擴展、可伸縮的安全的網站
大型網站軟件系統的特點：
1 高併發，大流量
每一個大型網站無不需要面對高併發的用戶與大流量訪問。
2 高可用
系統需要7 * 24小時不間斷服務。
3 海量數據
要存儲與管理海量的數據。
4 用戶分佈廣泛，網絡情況複雜
因訪問應用的用戶身處天南地北，且各地網8絡的情況也不一致，還需面臨各大網絡運營商之間互通難的問題。 因此要解決如何保障大部分用戶能正常、穩定的訪問應用的問題，迫在眉睫。
5 安全環境惡劣
互聯網的開放性，在帶來便利的同時也使得互聯網中的網站更容易遭受到攻擊。
6 需求快速變更，發佈頻繁
和傳統軟件的版本發佈不同，互聯網產品的發佈的頻率是極高的，那麼要解決的就是如何平穩的發佈新產品、以及不同產品之間的回滾
7 漸進式發展
幾乎所有大網站都是從一個小網站逐漸發展而來，因此如何平穩的升級架構，提升架構的可擴展性與易伸縮性是我們需要解決的問題
大型網站的技術挑戰主要來自於：
龐大的與用戶、高併發的訪問、海量的數據
任何簡單業務一旦需要處理數以 P 計的數據和麪對數以億計的用戶，問題就會變得很棘手
（ 1PB = 1024 TB = 2^20 GB = 2^30 MB = 2^40 KB = 2^50 B = 2^53 bit )
網站演化流程
|
|
|
|
|
|
|
 |
|
|
|
|
|
單機架構 ： 背景： 沒太多人訪問的小型網站，只需要一臺服務器就夠了。 方案： 網站的應用程序、數據庫、文件等所有的資源都集中在這一臺服務器上。通常在一臺廉價的操作服務器上搭建LNMP環境或者LAMP環境。（操作系統採用Linux，應用程序使用PHP開發，然後部署在Apache或Nginx上，數據庫使用MariaDB或MySQL。 特點： 廉價、性能差適合小型網站 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
應用服務和數據服務分離： 背景： 隨着網站業務的發展，一臺服務器逐漸不能滿足需求：越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足。這時就需要應用服務與數據分離。 改進： 應用服務器需要處理大量業務邏輯，因此需要更快更強大的CPU；數據庫服務器需要快速磁盤檢索和數據緩存因此需要更快的磁盤和更大的內存；文件服務器需要存儲大量用戶上傳的文件，因此需要更大的磁盤。 特點： 不同特性的服務器承擔不同的服務角色，網站的併發處理能力和數據存儲空間得到了很大改善，支持網站業務進一步發展。 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
使用緩存改善網站性能： 背景： 隨着業務的進一步增多，網站將又一次面臨挑戰：數據庫壓力太大導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響，這時需要進一步對網站架構進一步優化。 依據： 網站的訪問特點同樣遵循二八定律：80%的業務訪問集中在20%的數據上。如： 百度搜索關鍵詞集中在少部分熱門詞彙上；淘寶買家瀏覽商品集中在少部分成交數多、評價良好的商品上。 改進： 遵循這一特性，我們將這小部分經常訪問的數據緩存在內存中，即可減少數據庫的訪問壓力，提高整個網站數據訪問速度，改善數據庫的寫入性能。 緩存方案： 網站使用的緩存可以分爲兩種：緩存在應用服務器上的本地緩存服務器和緩存在專門的分佈式緩存服務器的遠程緩存。本地緩存固然更快，但受應用程序內存限制，其緩存數據有限，同樣容易出現和應用程序爭用緩存的情況。遠程分佈式緩存可以使用集羣的方式，部署大內存的服務器作爲專門的緩存服務器，可以在理論上做到不受內存容量限制的緩存服務。 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
使用應用服務器集羣改善網站的併發處理能力 背景： 使用緩存後，數據訪問壓力得到有效緩解，但是單一應用服務器能夠處理的請求連接有限，在網站訪問高峯期，應用服務器成爲整個網站的瓶頸。 依據： 當一臺服務器的處理能力不足時，不要試圖更換強大的服務器，對大型網站而言，不管多麼強大的服務器都無法支撐網站持續增長的業務需求，而使用集羣則是網站解決高併發、海量數據的常用手段。 改進： 增加一臺或多臺應用程序服務器分攤網站負載壓力，然後通過一臺負載均衡調度服務器來對用戶瀏覽器的訪問請求分發到不同可以以同樣的方式持續增加服務器不斷改善系統性能，從而實現系統的可伸縮性。 特點： 應用程序服務器的負載壓力不再成爲整個網站的瓶頸。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
數據讀寫分離 背景： 網站在使用緩存後，使絕大部分數據讀操作部分都可以不通過數據庫就可以完成，但仍有一部分讀操作（緩存訪問不命中、緩存過期）和全部的寫操作需要訪問數據庫，在網站的用戶達到一定規模後，數據庫因爲負載壓力過高而成爲網站的瓶頸。 方案： 目前大部分的主流數據庫都提供主從熱備功能，通過配置兩臺數據庫主從關係，可以將一臺數據庫服務器的數據更新同步到另一臺服務器上。網站利用數據庫的這一功能，實現數據庫讀寫分離，從而改善數據負載壓力。 應用服務器通過數據訪問模塊訪問數據庫，當應用服務器在寫數據時，訪問主數據庫，主服務器通過主從複製機制將數據更新同步到從服務器庫，這樣當應用服務器讀數據的時候，就可以通過從服務器訪問到數據。 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
使用反向代理和CDN加速網站響應 背景： 隨着網站業務不斷髮展，用戶規模越來越大，就要面對用戶處於不同地區帶來的複雜網絡環境問題，不同地區訪問網站時，速度差別也不一樣。而有研究表明：網站訪問延遲和用戶流失率正相關。 方案： 爲了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度。主要手段是使用CDN和反向代理。 目的： 儘早返回數據給用戶，一方面加快用戶訪問速度 |
|
|
|
|
|
|
|
|
|
CDN與反向代理 CDN和反向代理的基本原理都是緩存。 區別在於CDN部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的網絡提供商機房獲取數據。 而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。 CDN加速 CDN（Content Distribute Network ， 內容分發網絡）的本質仍然是一個緩存，而且是將數據緩存在距離用戶最近的地方，使用戶以最快的速度獲取數據，即所謂網絡訪問下一跳。 CDN能夠緩存的一般是靜態資源，如圖片、文件CSS、Script腳本、靜態網頁等。但是這些文件訪問頻率很高，將這些文件緩存在CDN可極大改善網頁的打開速度。
|
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
使用分佈式文件系統和分佈式數據庫系統 背景 任何強大的單一服務器都滿足不了大型網站持續增長的業務需求。數據庫經過讀寫分離後，從一臺服務器拆分成了兩臺服務器，但是隨着網站業務的發展依然不能滿足需求，這時需要使用分佈式數據庫，同樣文件系統也一樣，需要使用分佈式文件系統。 方案： 分佈式數據庫 分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模非常龐大的時候才使用。不到不得已時，才採用。 網站更常用的數據拆分手段是業務分庫，將不同業務的數據庫部署在不同的物理服務器上。 分佈式文件系統 分佈式文件系統是將文件按一定規則分佈的存儲在不同服務器上。 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
使用NoSQL和搜索引擎 背景 隨着網絡業務越來越複雜，對數據存儲和檢索的需求也越來越複雜，網站需要採用一些非關係型數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎。 特點 NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具有更好的支持。 應用服務器則通過一個統一的數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
業務拆分 背景： 大型網站爲了應對日益複雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線，如大型購物交易網站就會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。 方案： 在技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署維護。 應用之間可以通過一個超鏈接建立關係（在首頁的導航鏈接每個都指向不同的應用地址），也可以通過消息隊列進行數據分發，當然最多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。 |
|
|
|
|
|
|
|
|
|
|
|
|
 |
|
|
|
|
|
分佈式服務 背景： 隨着業務拆分越來越小，存儲系統越來越大，應用系統的整體複雜度呈指數級增加，部署維護越來越困難。 由於所有應用要和數據庫系統連接，在數萬臺服務器規模的網站中，這些連接的數目是服務器規模的平方，導致數據庫連接資源不足，拒絕服務。 方案： 既然每一個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理等，那麼可以將這些共用的業務提取出來，獨立部署。由這些可複用的業務連接數據庫，提供共用業務服務完成具體業務操作 |
|
|
|
|
|