《大型網站技術架構核心原理與案例分析》讀書筆記（一）

1.1 大型網站軟件系統的特色

與傳統企業應用系統相比，大型互聯網應用系統有如下的特色。

高併發，大流量

須要面對高併發用戶，大流量訪問。Google日均PV數35億，日均IP訪問3億；騰旭QQ的最大在線用戶數1.4億（2011年）；

高可用

系統 7 * 24 小時不間斷服務。

海量數據

須要存儲，管理海量數據，須要使用大量服務器。

用戶分佈普遍，網絡狀況複雜

許多大型互聯網都是爲全球用戶提供服務的，用戶分佈範圍廣，各地網絡狀況千差萬別。

安全環境惡劣

因爲互聯網的開放性，使得互聯網站更容易受到攻擊，大型網站幾乎天天都會被黑客攻擊。

需求快速變動，發佈頻繁

和傳統軟件的版本發佈頻率不一樣，互聯網產品爲快速適應市場，知足用戶需求，其產品發佈頻率是極高的。通常的大型網站的產品每週都有新版本發佈上線。

漸進式發展

與傳統軟件產品或企業應用系統一開始就規劃好所有的功能和非功能的需求不一樣，幾乎全部的大型互聯網站都是從一個小網站開始的，漸進式發展起來的。Facebook是扎克伯格同窗在哈佛大學的宿舍裏開發的；Google的第一臺服務器補助在斯坦福大學的實驗室裏；阿里巴巴則是在馬雲家的客廳裏誕生的。

1.2 大型網站架構演化發展歷程

大型網站的技術挑戰主要來自於龐大的用戶，高併發的訪問和海量的數據，任何簡單的業務一旦須要處理數以P計的數據和麪對數以億計的用戶，問題就會變得既瘦。大型網站架構主要就是解決這類問題。

1.2.1 初始階段的網站架構

大型網站都是從小網站發展而來的，網站架構也是同樣，是從小型網站架構逐步演化而來。小型網站最開始時根本沒有太多人訪問，只須要一臺服務器就綽綽有餘，這是網站架構如圖1.1所示。

圖1.1 初始階段的網站架構

應用程序，數據庫，文件等全部資源都在一臺服務器上。一般服務器操做系統使用Linux，應用程序使用PHP開發，而後部署在Apache上，數據庫使用MySQL，聚集各類免費開源軟件及一臺廉價服務器就能夠開始網站的發展之路了。

1.2.2 應用服務和數據服務分離

隨着網站的業務發展，一臺服務器逐漸不能知足需求：愈來愈多的用戶訪問致使性能愈來愈差，愈來愈多的數據致使存儲空間不足。這是就須要將應用和數據分離。應用和數據分離後整個網站使用三臺服務器：應用服務器、文件服務器和數據庫服務器，如圖1.2所示。這三臺服務器對硬件資源的要求各不相同，應用服務器須要處理大量的業務邏輯，所以須要更快更強大的CPU；數據庫服務器須要快速磁盤檢索和數據緩存，所以須要更快的因公安和更大的內存；文件服務器須要存儲大量用戶上傳的文件，所以須要更大的硬盤。

圖1.2 應用服務和數據服務分離

應用和數據分離後，不一樣特性的服務器承擔不一樣的服務角色，網站的併發處理能力和數據存儲空間獲得了很大改善，支持網站業務進一步發展。可是隨着用戶逐漸增多，網站又一次面臨挑戰：數據庫壓力太大致使訪問延遲，進而影響整個網站的性能，用戶體驗受到影響。這是須要對網站架構進一步優化。

1.2.3 使用緩存改善網站性能

網站訪問特色和現實世界的財富分配同樣遵循二八定律：80%的業務訪問集中在20%的數據上。淘寶賣家瀏覽的商品集中在少部分紅交數多、評價良好的商品上；百度搜索關鍵詞集中在少部分熱門詞彙上；只有常常登陸的用戶在會發微博、看微博，這部分用戶也只佔總用戶數的一小部分。

若是把這一小部分數據緩存在內存中，是否是就能夠減小數據庫的訪問眼裏，提升整個網站的數據訪問速度，改善數據庫寫入性能了呢？

網站使用的緩存能夠分爲兩種：緩存在應用服務器上的本地緩存和緩存在專門的分佈式緩存服務器上的遠程緩存。本地緩存的訪問速度更快一些，可是受應用服務器內存的限制，其緩存數據量有限，並且會出現和應用程序徵用內存的狀況。遠程分佈式緩存可使用集羣的方式，部署大內存的服務器做爲專門的緩存服務器，能夠在理論上作到不受內存量限制的緩存服務，如圖1.3所示

圖1.3網站使用緩存

使用緩存後，數據訪問壓力獲得有效緩解，可是單一應用服務器可以處理的請求鏈接有限，在網站訪問高峯期，應用服務器成爲整個網站的瓶頸。

1.2.4 使用應用服務器集羣改善網站的併發處理能力

使用季軍是網站解決高併發，海量數據問題的經常使用手段。當一臺服務器的處理能力，存儲空間不足時，不要企圖去換更強大的服務器，對於大型網站而言，無論多麼強大的服務器，都知足不了網站持續增加的業務需求，這種狀況下，更恰當的作法是增長一臺服務器分擔原有服務器的訪問及存儲壓力。

對網站架構而言，只要能經過增長一臺服務器的方式改善負載壓力，就能夠以一樣的方式持續增長服務器不斷改善系統的性能，從而實現系統的可伸縮性。應用服務器實現集羣是網站可伸縮集羣架構設計中較爲簡單成熟的一種，如圖1.4所示。

圖1.4 應用服務器集羣部署

經過負載均衡調度服務器，可未來自用戶瀏覽器的訪問請求分發到應用服務器集羣中的任何一臺服務器上，若是有更多的用戶，就在集羣中加入更多的應用服務器，使應用服務器的負載壓力不在成爲整個網站的瓶頸。

1.2.5 數據庫讀寫分離

網站在使用緩存後，使絕大部分數據的讀操做訪問均可以不經過數據庫就能完成，可是仍有一部分讀操做和所有的寫操做須要訪問數據庫，在網站的用戶達到必定規模後，數據庫由於負載壓力太高而成爲網站的瓶頸。

目前大部分的主流數據庫都是主從熱備功能，經過配置兩臺數據庫的主從關係，能夠將一臺數據庫服務器的數據更新同步到另外一臺服務器上。網站利用數據庫的這一功能，實現數據庫讀寫分離，從而改善數據庫負載壓力，如圖1.5所示

圖1.5 數據庫讀寫分離

應用服務器在寫數據的時候，訪問主數據庫，主數據庫經過主從複製機制將數據更新同步到從數據庫，這樣當應用服務器讀數據的時候，就能夠經過從數據庫得到數據。爲了便於應用程序訪問讀寫分離後的數據庫，一般在應用服務器端使用專門的數據訪問模塊，使數據庫讀寫分離對應用透明。

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

隨着網站業務不斷髮展，用戶規模愈來愈大，因爲中國複雜的網絡環境，不一樣地區的用戶訪問網站時，速度差異也極大。有研究表名，網站訪問延遲和用戶流失率正相關，網站訪問越慢，用戶越容易失去耐心而離開。爲了提供更好的用戶體驗，留住用戶，網站須要加速網站訪問速度。主要手段有使用CDN和反向代理，如圖1.6所示。

圖1.6 網站使用反向代理和CDN加速訪問

CDN和反向代理的基本原理都是緩存，區別在於CDN部署在網絡提供商的機房，使用戶在請求網站服務時，能夠從距離本身最近的網絡提供商機房獲取數據；而反向代理則部署在網站的中心機房，當用戶請求到達中心機房後，首先訪問的服務器是反向代理服務器，若是反向代理服務器中緩存着用戶請求的資源，就將其直接返回給用戶。

使用CDN和反向代理的目的都是儘早返回數據給用戶，一方面加快用戶訪問速度，另外一方面也減輕後端服務器的負載壓力。

1.2.7 使用分佈式文件系統和分佈式數據庫系統

任何強大的單一服務器都知足不了大型網站持續增加的業務需求。數據庫通過讀寫分離後，從一臺服務器拆分紅兩臺服務器，可是隨着網站業務的發展依然不能知足需求，這時須要使用分佈式數據庫。文件系統也是同樣，須要使用分佈式文件系統，如圖1.7所示。

分佈式數據庫是網站數據庫拆分的最後手段，只有在單表數據規模很是龐大的時候才使用。不到萬不得已時，網站更經常使用的數據庫拆分手段是業務分庫，將不一樣業務的數據庫部署在不一樣的物理服務器上。

圖1.7 使用分佈式文件和分佈式數據庫系統

1.2.8 使用NoSQL和搜索引擎

隨着網站業務愈來愈複雜，對數據存儲和檢索的需求也愈來愈複雜，網站須要採用一些非關係數據庫和技術如NoSQL和非數據庫查詢技術如搜索引擎，如圖1.8所示。

圖1.8 使用NoSQL和搜素引擎

NoSQL和搜索引擎都是源自互聯網的技術手段，對可伸縮的分佈式特性具備更好的支持。應用服務器則經過一個統一數據訪問模塊訪問各類數據，減輕應用程序管理諸多數據源的麻煩。

1.2.9 業務拆分

大型網站爲了應對日益複雜的業務場景，經過使用分而治之的手段將整個網站業務分紅不一樣的產品線，如大型購物交易網站就會將首頁、商鋪、訂單、賣家、買家等拆分紅不一樣的產品線，分歸不一樣的業務團隊負責。

具體到技術上，也會根據蟾皮年劃分，將一個網站拆分紅許多不一樣的應用，每一個應用獨立部署維護。應用之間能夠經過一個超連接創建關係，也能夠經過消息隊列進行數據分發，固然最多的仍是經過訪問同一個數據存儲系統來構成一個關聯的完整系統，如圖1.9所示。

圖1.9 應用拆分

1.2.10 分佈式服務

隨着業務拆分愈來愈小，存儲系統愈來愈大，應用系統的總體複雜度呈指數級增長，部署維護愈來愈困難。因爲全部應用要和全部數據庫系統鏈接，在數萬臺服務器規模的網站中，這些鏈接的數目是服務器規模的平方，致使數據庫鏈接資源不足，拒絕服務。

既然每一個應用系統都須要執行許多相同的業務操做，好比用戶管理、商品管理等，那麼能夠將這些共用的業務提取出來獨立部署。由這些可複用的業務鏈接數據庫，提供共用業務服務，而應用系統只須要管理用戶界面，經過分佈式服務調用共用業務服務完成具體業務操做，如圖1.10所示。

圖1.10 分佈式服務

大型網站的架構演化到這裏，基本上大多數的技術問題都得以解決，諸如跨數據中心的實時數據同步和具體網站業務相關的問題也均可以經過組合改進現有技術架構來解決。

但事物發展到必定階段，就會擁有自身的發展衝動，擺脫其初衷，向着使本身更強大的方向發展。既然大型網站架構解決了海量數據的管理和高併發事務的處理，那麼就能夠把這些解決方案應用到網站自身之外的業務上去。咱們看到目前許多大型網站都開始建設雲計算平臺，將計算做爲一種基礎資源出售，中小網站不須要再關心技術架構問題，只須要按需付費，就可使網站隨着業務的增加逐漸得到更大的存儲空間和更多的計算資源。

1.3 大型網站架構演化的價值觀

這個世界沒有哪一個網站從誕生起就是大型網站；網站的價值在於它能爲用戶提供什麼價值，在於網站能作什麼，而不在於怎麼作的。小型網站最須要作的就是爲客戶提供好的服務來創造價值，獲得用戶的承認，活下去，野蠻生長。

1.3.1 大型網站架構技術核心價值是隨網站所需靈活應對

大型網站架構技術的核心價值不是從無到有搭建一個大型網站，而是可以伴隨小型網站業務的逐步發展，慢慢演化成一個大型網站。在漫長的技術演化過程當中，不須要放棄什麼，不須要推翻什麼，不須要劇烈的革命，就那麼潤物細無聲的把一個只有一臺服務器，幾百個用戶的小網站演化成一個幾十萬臺服務器，數十億用戶的大網站。

1.3.2 驅動大型網站技術發展的主要力量是網站業務的發展

創新的業務發展模式對網站架構逐步提出更高要求，才使得建立的網站架構得以發展成熟。是業務成就了技術，是事業成就了人，而不是相反。

1.4 網站架構的設計誤區

在大型網站架構發展過程當中有以下幾個容易出現的誤區

1.4.1 一味追求大公司的解決方案

因爲大公司巨大陳宮的光環效應，再加上從大公司挖來的技術高手的影響，網站在討論架構決策時，最有說服力的一句話就成了「淘寶就是這麼搞得」或者「Facebook就是這麼搞得」。

大公司的經驗和成功的模式當然重要，值得學習借鑑，但若是所以變得盲從，就失去了堅持自個人勇氣，在架構演化的道路上遲到會迷路。

1.4.2 爲了技術而技術

網站技術是爲業務而存在的，除此毫無心義。在技術選型和架構設計中，脫離網站業務發展的實際，一味追求時髦的新技術，可能會將網站技術發展引入崎嶇小道，架構之路越走越難。

1.4.3 企圖用技術解決全部問題

最典型的例子就是2012年年初12306故障事件後，軟件開發技術屆的反應。

各路專業和非專業人士衆說紛紜的幫12306技術架構出謀劃策，甚至有人提議幫12306寫個開源的網站，解決其大規模併發訪問的問題。

12306真正的問題其實不在於技術架構，而在於業務架構；後來12306在售票的方式上引入了排隊機制、整點售票調整爲分時段售票。其實若是能控制住併發訪問的量，不少技術的技術問題也就不是什麼問題了。

1.5 小結

時至今日，大型網站的架構演化方案已經很是成熟，各類技術方案也逐漸產品化。許多小型網站已經慢慢不須要在經歷大型網站經歷過的架構演化之路就能夠逐步發展壯大，由於如今愈來愈多的網站從創建之初就是搭建在大型網站提供的雲計算服務基礎之上，所須要的一切技術資源：計算，存儲，網絡均可以按需購買，線性伸縮，不須要本身一點一點拼湊各類資源，綜合使用各類技術方案，逐步去完善本身的網站架構了。

因此能親身經歷一個網站從小到大的架構演化過程的網站架構師愈來愈少，雖然過去有這種經歷的架構師也不多，可是未來可能真就沒有了。

但也正由於網站架構技術演化過程難以重現，因此網站架構師更應該對這個過程深入瞭解，理解已成熟的網站架構技術方案的前因後果和歷史淵源，在技術選型和架構決策時纔能有的放矢，直擊要害。

---

免責：

只是想將學過的知識用另外一種方式輸出，若是侵權請聯繫本人刪帖。