記錄一下個人看了一些大型網站架構文章后的理解，目錄如下，
0. Overview
1. 大型網站系統的特點
- 高并發，大流量
- 高可用
- 海量數據
- 用戶分布廣泛、網絡情況復雜
- 安全環境惡劣
- 需求快速變更，發布頻繁
- 漸進式發展
2. 大型網站架構技術一覽
- 前端架構
- 應用層架構
- 服務層架構
- 存儲層架構
- 后臺架構
- 數據采集與監控
- 網站安全架構
- 數據中心機房架構
3. 大型網站架構的演進
- 單機網站架構
- 應用與數據服務器分離架構
- 應用服務器熱點數據緩存架構
- 應用服務器集群的可伸縮架構
- 數據庫讀寫分離架構
- 網站前端快速響應架構
- 分布式文件、數據庫架構
- Advanced Data Access架構
- 業務拆分架構
- 分布式服務調用架構
4. 大數據系統的架構
5. 待讀書單
6. Reference
Overview
- 衡量一個網站是否為
大型網站，訪問量和數據量二者缺一不可。除了海量數據和高并發的訪問量，本身業務和系統的復雜度也是考察的方面 - 大型網站的技術挑戰主要來自于龐大的用戶，高并發的訪問和海量的數據，任何簡單的業務一旦需要處理數以PB計的數據和面對數以億計的用戶，問題就會變的很棘手
- 大型網站架構主要就是解決這類問題
1. 大型網站系統的特點
1.1 高并發High Concurrency，大流量
需要面對高并發用戶，大流量訪問。Google日均PV數35億，日均IP訪問數3億；騰訊QQ的最大在線用戶數1.4億（2011年數據）；淘寶2012年“雙十一”活動一天交易額超過192億，活動開始第一分鐘獨立訪問用戶達1000萬。
1.2 高可用High Availability
系統7*24小時不間斷服務。
1.3 海量數據
需要存儲、管理海量數據，需要使用大量服務器。Facebook每周上傳的照片數據接近10億，百度收錄的網頁數目數百億，Google有近百萬臺服務器為全球用戶提供服務。
1.4 用戶分布廣泛、網絡情況復雜
許多大型互聯網都是為全球用戶提供服務的，用戶分布范圍廣，各地網絡情況千差萬別。在國內，還有各個運營商網絡互通難的問題。而中美光纜的數次故障，也讓一些對國內外用戶依賴較大的網站不得不考慮在海外建立數據中心。
1.5 安全環境惡劣
由于互聯網的開放性，使得互聯網站更容易受到攻擊，大型網站幾乎每天都會被黑客攻擊。
1.6 需求快速變更，發布頻繁
和傳統軟件的版本發布頻率不同，互聯網產品為快速適應市場，滿足用戶需求，其產品發布頻率極高。一般大型網站的產品每周都有新版本發布上線，中小型網站的發布更頻繁，有時候一天會發布幾十次。
1.7 漸進式發展
幾乎所有的大型互聯網網站都是從一個小網站開始，漸進地發展起來的。Facebook是扎克伯格同學在哈佛大學的宿舍里開發的；Google的第一臺服務器部署在斯坦福大學的實驗室；阿里巴巴是在馬云家的客廳誕生的。好的互聯網產品都是慢慢運營出來的，不是一開始就開發好的，這也正好與網站架構的發展演化過程對應。
2. 大型網站架構技術一覽
2.1 前端架構
前端指用戶請求到達網站應用服務器之前經歷的環節，通常不包含網站業務邏輯，不處理動態內容。
2.1.1 瀏覽器優化技術
并不是優化瀏覽器，而是通過優化響應頁面，加快瀏覽器頁面的加載和顯示，常用的有頁面緩存、合并HTTP減少請求次數、使用頁面壓縮等。
2.1.2 CDN
內容分發網絡，部署在網絡運營商機房，通過將靜態頁面內容分發到離用戶最近最近的CDN服務器，使用戶可以通過最短路徑獲取內容。
2.1.3 反向代理
部署在網站機房，在應用服務器、靜態資源服務器、圖片服務器之前，提供頁面緩存服務。
2.1.4 動靜分離，靜態資源獨立部署
靜態資源，如JS、CSS等文件部署在專門的服務器集群上，與Web應用動態內容服務分離，并使用專門的（二級）域名。
2.1.5 圖片服務
圖片不是指網站Logo、按鈕圖標等，這些文件屬于上面提到的靜態資源，應該和JS、CSS部署在一起。這里的圖片指用戶上傳的圖片，如產品圖片、用戶頭像等，圖片服務同樣適用獨立部署的圖片服務器集群，并使用獨立（二級）域名。
2.1.6 DNS
域名服務，將域名解析成IP地址，利用DNS可以實現DNS負載均衡，配置CDN也需要修改DNS，使域名解析后指向CDN服務器。
2.2 應用層架構
應用層是處理網站主要業務邏輯的地方。
2.2.1 開發框架
網站業務是多變的，網站的大部分軟件工程師都是在加班加點開發網站業務，一個好的開發框架至關重要。一個好的開發框架應該能夠分離關注面，使美工、開發工程師可以各司其事，易于協作。同時還應該內置一些安全策略，預防Web攻擊。
2.2.2 頁面渲染
將分別開發維護的動態內容和靜態頁面模板集成起來，組合成最終顯示給用戶的完整頁面。
2.2.3 負載均衡
將多臺應用服務器組成一個集群，通過負載均衡技術將用戶請求分發到不同的服務器上，以應對大量用戶同時訪問時產生的高并發負載壓力。
2.2.4 Session管理
為了實現高可用的應用服務器集群，應用服務器通常設計為無狀態，不保存用戶請求上下文信息。但是網站業務通常需要保持用戶會話信息（記錄用戶行為軌跡），需要專門的機制管理Session，使集群內甚至跨集群的應用服務器可以共享Session。
2.2.5 動態頁面靜態化
對于訪問量特別大而更新又不很頻繁的動態頁面，可以將其靜態化，即生成一個靜態頁面，利用靜態頁面的優化手段加速用戶訪問，如CDN、反向代理、瀏覽器緩存等。
2.2.6 業務拆分
將復雜而龐大的業務拆分開來，形成多個規模較小的產品，獨立開發、部署、維護，除了降低系統耦合度，也便于數據庫業務分庫。按業務對關系數據庫進行拆分，技術難度相對較小，而效果又相對較好。
2.2.7 虛擬化服務器
將一臺物理服務器虛擬化成多臺虛擬服務器，對于并發訪問較低的業務，更容易用較少的資源搭建出高可用的應用服務器集群。
2.3 服務層架構
提供基礎服務給應用層調用，完成網站業務。
2.3.1 分布式消息
利用消息隊列機制，實現業務和業務、業務和服務之間的異步消息發送及低耦合的業務關系。
2.3.2 分布式服務
提供高性能、低耦合、易復用、易管理的分布式服務，在網站實現面向服務SOA架構或者微服務Microservice架構。
2.3.3 分布式緩存
通過可伸縮的服務器集群提供大規模熱點數據的緩存服務，是網站性能優化的重要手段。
2.3.4 分布式配置
系統運行需要配置許多參數，如果這些參數需要修改，比如分布式緩存集群加入新的緩存服務器，需要修改應用程序客戶端的緩存服務器列表配置，并重啟應用程序服務器。分布式配置在系統運行期提供配置動態推送服務，將配置修改實時推送到應用系統，無需重啟服務器。
這里有兩個點，
2.4 存儲層架構
提供數據、文件的持久化存儲訪問與管理服務。
2.4.1 分布式文件
網站在線業務需要存儲的文件大部分都是圖片、網頁、視頻等比較小的文件，但是這些文件的數量非常龐大，而且通常都在持續增加，需要伸縮性設計比較好的分布式文件系統。
2.4.2 關系數據庫
大部分網站的主要業務是基于關系數據庫開發的，但是關系數據庫對集群伸縮性的支持表較差。通過在應用程序的數據訪問層增加數據庫訪問的路由功能，根據業務配置將數據庫訪問路由到不同的物理數據庫上，從而實現關系數據庫的分布式訪問。
2.4.3 NoSQL數據庫
目前各種NoSQL數據庫層出不窮，在內存管理、數據模型、集群分布式管理等方面各有優勢。
2.4.4 數據同步
擁有多個數據中心的網站必須在多個數據中心之間進行數據同步（CAP），以保證每個數據中心都擁有完整的數據。在實踐中，為了減輕數據庫壓力，將數據庫的事務/動作日志（或者NoSQL的寫操作Log）同步到其他數據中心，根據Log進行數據重演，實現數據同步，即同步動作，而非同步動作后的數據。
2.5 后臺架構
網站應用中，除了要處理用戶的實時訪問請求外，還有一些后臺非實時數據分析要處理。
2.5.1 搜索引擎
對數據進行全量、增量的更新，構建索引等。這些操作通過后臺系統定時執行。
2.5.2 數據倉庫
根據離線數據，提供數據分析OLAP與數據挖掘服務。
2.5.3 推薦系統
社交網站及購物網站通過挖掘人與人之間的關系，人和商品之間的關系，發展潛在的人際關系和購物興趣，為用戶提供個性化推薦服務。
2.6 數據采集與監控
監控網站訪問情況與系統運行情況，為網站運營決策和運維管理提供支持保障。
2.6.1 瀏覽器數據采集
通過在網站頁面中嵌入JS腳本采集用戶瀏覽器環境與操作記錄，分析用戶行為。
2.6.2 服務器業務數據采集
服務器業務數據包括兩種，一種是采集在服務器端記錄的用戶請求操作日志，如query記錄；一種是采集應用程序運行期業務數據，如待處理消息數目等。
2.6.3 服務器性能數據采集
采集服務器性能數據，如系統負載、內存使用率、網卡進、出流量等。
2.6.4 系統監控
將前述采集的數據以圖表的方式展示，以便運營和運維人員監控網站運行狀況，做到這一步僅僅是系統監視。更先進的做法是根據采集的數據進行自動化運維，自動處理系統異常狀況，實現自動化控制。
2.6.5 系統報警
如果采集來的數據超過預設的正常情況的閥值，比如系統負載過高，就通過郵件、短信、語音電話等方式發出警報信號，等待工程師人工干預。
2.7 網站安全架構
保護網站免遭攻擊及敏感信息的泄露。
2.7.1 Web攻擊
以HTTP請求的方式發起的攻擊，危害最大的就是XSS和SQL注入攻擊。但是只要措施得當，這兩種攻擊都是比較容易防范的。
2.7.2 數據保護
敏感信息加密傳輸與存儲，保護網站和用戶資產。
2.8 數據中心機房架構
大型網站需要的服務器規模數以十萬計，機房物理架構也需要關注。
2.8.1 機房架構
對于一個擁有十萬臺服務器的大型網站，每臺服務器耗電（包括服務器本身耗電及空調耗電）每年大約需要人民幣2000元，那么網站每年機房電費就需要兩億人民幣。數據中心能耗問題日趨嚴重，Google、Facebook選擇數據中心地理位置的時候趨向選擇散熱良好，供電充裕的地方。
2.8.2 機柜架構
包括機柜大小，網線布局、指示燈規格、不間斷電源、電壓規格（是48V直流電還是220V民用交流電）等一系列問題。
2.8.3 服務器架構
大型網站由于服務器采購規模龐大，大都采用定制服務器的方式代替購買服務器整機。根據網站應用需求，定制硬盤、內存、甚至CPU，同時去除不必要的外設接口（顯示器輸出接口，鼠標、鍵盤輸入接口），并使空間結構利于散熱。
3. 大型網站架構的演進
3.1 單機網站：初始階段的網站架構
小型網站最開始沒有太多人訪問，只需要一臺服務器就綽綽有余，應用程序、數據庫、文件等所有資源都在一臺服務器上（于小型博客類似），常見的LAMP(Linux+apache+mysql+php)架構。
3.2 單機負載告警，應用服務與數據服務分離
隨著網站業務的發展，一臺服務器逐漸不能滿足需求。越來越多的用戶訪問導致性能越來越差，越來越多的數據導致存儲空間不足。這時就需要將應用和數據分離。應用和數據分離后整個網站使用3臺服務器：應用服務器、文件服務器和數據庫服務器。這3臺服務器對硬件資源的要求各不相同。
- 應用服務器需要處理大量的業務邏輯，因此需要更快更強大的
CPU- 數據庫服務器需要快速磁盤
檢索和數據緩存，因此需要更快的磁盤和更大的內存- 文件服務器需要存儲大量用戶上傳的文件，因此需要更大的
硬盤
應用和數據分離后，不同特性的服務器承擔不同的服務角色，網站的并發處理能力和數據存儲空間得到了很大改善，支持網站業務進一步發展。
但是隨著用戶逐漸增多，網站又一次面臨挑戰：數據庫壓力太大導致訪問延遲，進而影響整個網站的性能，用戶體驗受到影響。這時需要對網站架構進一步優化。
3.3 數據庫壓力太大導致訪問延遲，使用緩存改善網站性能
網站訪問的特點和現實世界的財富分配一樣遵循二八定律：80%的業務訪問集中在20%的數據上(熱點數據hot data)。
既然大部分業務訪問集中在一小部分數據上，那么如果把這一小部分數據緩存在內存中，就可以減少數據庫的訪問壓力，提高整個網站的數據訪問速度，改善數據庫的寫入性能了。
網站使用的緩存可以分為兩種：緩存在應用服務器上的本地緩存和緩存在專門的分布式緩存服務器上的遠程緩存。
- 本地緩存的訪問速度更快一些，但是受應用服務器內存限制，其緩存數據量有限，而且會出現和應用程序爭用內存的情況
- 遠程分布式緩存可以使用集群的方式，部署大內存的服務器作為專門的緩存服務器，可以在理論上做到不受內存容量限制的緩存服務
使用緩存后，數據訪問壓力得到有效緩解（大部分request被cache攔截了，不會再深入到DB中檢索），但是單一應用服務器能夠處理的請求連接有限，在網站訪問高峰期，應用服務器成為整個網站的瓶頸。
3.4 應用服務器負載告警，使用應用服務器集群改善網站的并發處理能力
使用集群是網站解決高并發、海量數據問題的常用手段。
當一臺服務器的處理能力、存儲空間不足時，不要企圖去更換更強大的服務器，對大型網站而言，不管多么強大的服務器，都滿足不了網站持續增長的業務需求。這種情況下，更恰當的做法是增加一臺服務器來分擔原有服務器的訪問及存儲壓力。
對網站架構而言，只要能通過增加一臺服務器的方式來改善負載壓力，就可以以同樣的方式持續增加服務器不斷改善系統性能，從而實現系統的可伸縮性。
應用服務器實現集群是網站可伸縮架構設計中較為簡單成熟的一種。
通過負載均衡(Nginx)調度服務器，可以將來自用戶瀏覽器的訪問請求分發到應用服務器集群中的任何一臺服務器上，如果有更多用戶，就在集群中加入更多的應用服務器，使應用服務器的壓力不再成為整個網站的瓶頸。
3.5 數據庫壓力變大，數據庫讀寫分離
網站在使用緩存后，使對大部分數據讀操作訪問都可以不走數據庫就能完成，但是仍有一部分讀操作（緩存訪問不命中、緩存過期）和全部的寫操作都需要訪問數據庫。
在網站的用戶達到一定規模后，數據庫因為負載壓力過高而成為網站的瓶頸。 目前大部分的主流數據庫都提供主從熱備功能，通過配置兩臺數據庫主從關系，可以將一臺數據庫服務器的數據更新同步到另一臺服務器上。網站利用數據庫的這一功能，實現數據庫讀寫分離，從而改善數據庫負載壓力，即主寫從讀，然后主從同步復制。
應用服務器在寫數據的時候，訪問主數據庫，主數據庫通過主從復制機制將數據更新同步到從數據庫，這樣當應用服務器讀數據的時候，就可以通過從數據庫獲得數據。
為了便于應用程序訪問讀寫分離后的數據庫，通常在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。
提到讀寫分離，我們更多的是想到數據庫層面。事實上，廣義的讀寫分離可以擴展到更多的場景。例如搜索引擎其實是一個讀庫。搜索引擎的技術解決了站內搜索時某些場景下讀的問題，提供了更好的查詢效率。緩存系統和搜索引擎、讀庫的定位是很類似的。
3.6 使用反向代理和CDN加速網站響應
隨著網站業務不斷發展，用戶規模越來越大，由于國內復雜的網絡環境，不同地區的用戶訪問網站時，訪問速度有時候差別很大。有研究表明，網站訪問延遲和用戶流失率正相關，網站訪問越慢，用戶越容易失去耐心而離開。為了提供更好的用戶體驗，留住用戶，網站需要加速網站訪問速度。主要手段有使用CDN和反向代理。
CDN 和反向代理的基本原理都是緩存，
- CDN 部署在網絡提供商的機房，使用戶在請求網站服務時，可以從距離自己最近的
網絡提供商機房獲取數據- 反向代理則部署在網站的中心機房，當用戶請求到達中心機房后，首先訪問的服務器是反向代理服務器，如果反向代理服務器中緩存著用戶請求的資源，就將其直接返回給用戶
使用 CDN 和反向代理的目的都是盡早返回數據給用戶，一方面加快用戶訪問速度，另一方面也減輕后端服務器的負載壓力。
3.7 使用分布式文件系統和分布式數據庫系統
任何強大的單一服務器都滿足不了大型網站持續增長的業務需求。
數據庫經過讀寫分離后，從一臺服務器拆分成兩臺服務器，但是隨著網站業務的發展依然不能滿足需求，這時需要使用分布式數據庫。文件系統也一樣，需要使用分布式文件系統。
分布式數據庫是網站數據庫拆分的最后手段，只有在單表數據規模非常龐大的時候才使用。不到不得已時，網站更常用的數據庫拆分手段是業務分庫，將不同業務的數據部署在不同的物理服務器上（分庫分表）。
3.8 彌補關系型數據庫的不足，使用NoSQL和搜索引擎
隨著網站業務越來越復雜，對數據存儲和檢索的需求也越來越復雜，網站需要采用一些非關系數據庫技術如NoSQL和非數據庫查詢技術如搜索引擎。
NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分布式特性具有更好的支持。應用服務器則通過一個統一數據訪問模塊訪問各種數據，減輕應用程序管理諸多數據源的麻煩。
3.9 業務拆分
大型網站為了應對日益復雜的業務場景，通過使用分而治之的手段將整個網站業務分成不同的產品線。如大型購物交易網站都會將首頁、商鋪、訂單、買家、賣家等拆分成不同的產品線，分歸不同的業務團隊負責。
具體到技術上，也會根據產品線劃分，將一個網站拆分成許多不同的應用，每個應用獨立部署。應用之間可以通過一個超鏈接建立關系（在首頁上的導航鏈接每個都指向不同的應用地址），也可以通過消息隊列進行數據分發，當然最多的還是通過訪問同一個數據存儲系統來構成一個關聯的完整系統。
3.10 分布式服務調用
隨著業務拆分得越來越小，存儲系統越來越龐大，應用系統的整體復雜度呈指數級增加，部署維護越來越困難。由于所有應用要和所有數據庫系統連接，在數萬臺服務器規模的網站中，這些連接的數目是服務器規模的平方，導致數據庫連接資源不足，拒絕服務。
既然每一個應用系統都需要執行許多相同的業務操作，比如用戶管理、商品管理、訂單管理等，那么可以將這些共用的業務提取出來，獨立部署。由這些可復用的業務連接數據庫，提供共用業務服務，而應用系統只需要管理用戶界面，通過分布式服務調用共用業務服務完成具體業務操作。
大型網站的架構演化到這里，基本上大多數的技術問題都得以解決，諸如跨數據中心的實時數據同步、事務特性支持和具體網站業務相關的問題也都可以通過組合改進現有技術架構解決。
在以上十個架構組織當中，有些單個的架構優化之路就很長，如果再多個組合起來，那么模塊的兼容耦合銜接都會有不少的challenge。
大數據系統的架構
TODO
Reference
- 大型網站架構演化歷程
- 大型網站架構技術一覽
- 大型網站架構的演化
- 漫談《大型網站技術架構》
- 大型網站技術架構csdn專題
- 大數據處理的關鍵層次架構
- 大數據軟件系統架構設計
- 后Hadoop時代的大數據架構
