這篇文章是參考李智慧的《大型網(wǎng)站技術架構：核心原理與案例分析》和現(xiàn)蘑菇街CTO曽憲杰的《大型網(wǎng)站系統(tǒng)與Java中間件實踐》寫的一篇讀書筆記。
前言
何謂大型網(wǎng)站？大型網(wǎng)站的特點是什么？大型網(wǎng)站架構發(fā)生演變的源動力是什么？大型網(wǎng)站的架構演變經(jīng)歷了哪些階段？在演變的某個具體階段使用到常用技術有哪些，為什么要使用這些技術，同時這些技術又解決了什么問題？筆者在初次接觸大型網(wǎng)站時思考了以上幾個問題，本著緣木求魚的方式，我打算詳細的扒一扒大型網(wǎng)站的演變史。如果對以上的幾個問題都理解透徹了，那么可以說對大型網(wǎng)站也有一個基本的認識和理解了，但是我寫這篇文章卻不局限于此，在文章的后面會從一個中高級程序員的角度去思考，從大型網(wǎng)站的演變史可以得到哪些方法論和技術棧。由于筆者工作時間不長，所以我覺得思考這個問題是很有意思的。
下面將分別從以下幾個方面談談大型網(wǎng)站：
大型網(wǎng)站的特點
從20世紀90年代第一個Web服務的出現(xiàn)，現(xiàn)在互聯(lián)網(wǎng)的普及，也就短短20來年的時間?；ヂ?lián)網(wǎng)極大的改變了人們的生活、學習、生活等方方面面，筆者清晰地記得在2011年剛上大學那會，用著中國移動龜速的2G怨聲載道，到現(xiàn)在三大運營商大力推廣并普及4G網(wǎng)絡，再一次掀起了新一輪的互聯(lián)網(wǎng)革命，當我們享受著網(wǎng)頁秒開，看視頻再也不卡的暢快時，卻不知道背后的技術人員所付出的巨大努力。舉個例子，現(xiàn)在大家人手必裝的支付寶、淘寶等軟件無不從一個小網(wǎng)站發(fā)展起來的，然后逐漸成為一個大型網(wǎng)站。那么大型網(wǎng)站的特點有哪些呢？
主要是指這類網(wǎng)站需要面對高并發(fā)、大流量訪問。騰訊QQ的最大在線人數(shù)為1.4億（2011年數(shù)據(jù)）。
因為高并發(fā)的訪問，會使得服務器承受巨大的壓力，一旦服務器出現(xiàn)過載那么很可能直接掛掉，然后，就沒有然后了??。因此，高可用就顯得尤為重要，需要保證網(wǎng)站7*24小時不間斷提供服務。
主要是指需要存儲、管理海量數(shù)據(jù)。百度收錄的網(wǎng)頁數(shù)據(jù)有數(shù)百億，Google有將近百萬臺服務器在提供服務。
源動力
既然大型網(wǎng)站是從小型網(wǎng)站發(fā)展起來的，那么是什么力量在推動著小網(wǎng)站逐漸向大型網(wǎng)站發(fā)展呢？
主要力量是業(yè)務的發(fā)展。從來沒有哪個網(wǎng)站生來就是大型網(wǎng)站，業(yè)務驅(qū)動技術變革，技術變革反作用于業(yè)務，從而使得網(wǎng)站可以支撐業(yè)務的快速發(fā)展。所以，從CEO（CTO）的角度看，網(wǎng)站的價值在于它所為用戶帶來了什么，而不是網(wǎng)站是怎么形成的。需要為用戶帶來價值是因，網(wǎng)站的形成是果，這個因果關系是需要認清楚的。所以，技術從來不是單純的技術（從價值的角度看），技術雖然可以解決大部分問題，但卻不一定能夠解決所有的問題。就12306網(wǎng)站售票的例子，如果早點使用分時段售票的做法，就沒必要投入大量的技術人員解決這個問題。業(yè)務設計也是關乎網(wǎng)站價值的重要方面，所以不要為了技術而技術！
演變階段
階段一：單臺服務器搞定一切
由于早期用戶量不多，所以使用一臺服務器就可以支撐業(yè)務。應用、數(shù)據(jù)、文件都在一臺機器上完成。這個階段的典型架構就是LAMP（Linux + Apache + MySQL + PHP（Java））。搞過開發(fā)的應該都經(jīng)歷過這個階段。操作系統(tǒng)采用Linux，使用Java或者PHP作為開發(fā)語言，使用MySQL作為數(shù)據(jù)庫，開發(fā)完后部署在Apache上。淘寶早期的架構也是這樣的。
那會阿里因為開發(fā)資源不足，所以就購買了外國的一個網(wǎng)上商城，把源碼和版權都買下了（花了大概幾十萬吧），那會的淘寶的架構就是LAMP架構。
階段二：應用服務與數(shù)據(jù)隔離
隨著業(yè)務量的增長，存儲的數(shù)據(jù)越來越多而造成存儲空間的不足。這時候就把應用和數(shù)據(jù)拆分，分別部署在應用服務器、數(shù)據(jù)庫服務器和文件服務器。應用服務器由于需要處理復雜的業(yè)務邏輯，因此需要更強大的CPU，數(shù)據(jù)庫由于需要快速讀寫數(shù)據(jù)，因此需要更快的磁盤和更大的內(nèi)存，文件服務器由于需要存儲大量的數(shù)據(jù)，因此需要更大容量的硬盤。需要注意的是，雖然三臺服務器承擔了不同的角色，同時也大大改善了網(wǎng)站的性能，但是在整個應用中，需要的服務都是通過直連的方式完成的。直連的意思是指，當需要讀寫數(shù)據(jù)庫的數(shù)據(jù)時，是直接訪問的。雖然有壓測數(shù)據(jù)表明，在不使用任何第三方組件直接使用MySQL的并發(fā)可以達到10000多。所以，如果并發(fā)數(shù)小于這個值，直連的方式也沒有什么問題。所以，如果并發(fā)數(shù)超過了10k，那么數(shù)據(jù)庫的壓力就比較大了，造成的問題就是訪問時延增大，進而影響整個網(wǎng)站的性能。
階段三：使用緩存改善性能
根據(jù)“二八定律”：80%的業(yè)務訪問集中在20%的數(shù)據(jù)上，也就是說這20%的數(shù)據(jù)是熱點數(shù)據(jù)，訪問頻率相比其他數(shù)據(jù)大數(shù)倍甚至更多。所以，如果把這小部分的數(shù)據(jù)緩存在內(nèi)存中，用戶訪問的時候直接從內(nèi)存中取，就不需要通過數(shù)據(jù)庫，從而大大降低數(shù)據(jù)庫的訪問壓力。
通常而言，緩存可以分為本地緩存和部署在分布式服務器上的遠程緩存。本地緩存存在于應用服務器所在的內(nèi)存中，可能于應用數(shù)據(jù)發(fā)生爭用的情況，而遠程緩存則不會存在這種情況，因為所有的數(shù)據(jù)都是熱點數(shù)據(jù)，沒有干擾。本地緩存又可以分為瀏覽器緩存（Cookie）、操作系統(tǒng)緩存（如CPU的L1、L2和L3）、應用服務器的緩存（本地內(nèi)存中）。通?？梢允褂胑hcache作為本地緩存、Redis或者Memocached作為分布式緩存
階段四：搭建應用服務器集群改善并發(fā)
截至目前的演變，應用服務器仍然是單兵作戰(zhàn)，雖然以上的演變大大改善額網(wǎng)站的性能，但是隨著業(yè)務量的進一步上升，單臺服務器的瓶頸就顯現(xiàn)出來了，因為很可能因為負載過高導致應用服務器直接掛掉。這種情況下，更好的做法是使用增加服務器的方式水平擴展，這樣就可以實現(xiàn)彈性伸縮，當負載過高的時候增加服務器，當負載降下來的時候，減少服務器。是不是很優(yōu)雅？阿里在2012年提出的去“IOE”的原因之一就與這點有關。
IOE分別是指IBM、Oracle、EMC
雖然很優(yōu)雅，但是應用服務器采用集群部署后，原來的請求過來的時候，如何知道調(diào)用哪臺服務器完成請求呢？這就需要使用到負載均衡服務器了，干嘛的呢？就是負責將請求轉(zhuǎn)發(fā)給某臺服務器。負載均衡又包括硬負載和軟負載。硬負載是硬件解決方案，比如F5，但是通常成本比較高，更常用的解決方案是軟負載，就是通常軟件實現(xiàn)負載均衡，比如LVS。
階段五：數(shù)據(jù)庫讀寫分離減輕數(shù)據(jù)讀寫壓力
雖然之前使用緩存將熱點數(shù)據(jù)緩存起來了，但是也存在緩存不命中的情況，這個時候又會直接訪問數(shù)據(jù)庫了，當緩存不命中的情況增大到一定規(guī)模的時候數(shù)據(jù)庫的壓力就又是一個問題了。我們知道都數(shù)據(jù)庫進行的操作無非兩種：讀和寫。由于數(shù)據(jù)庫（比如MySQL）存在事務隔離級別和鎖的機制，可能會導致讀和寫互相阻塞，那么如何實現(xiàn)數(shù)據(jù)庫的讀寫分離呢？目前的思路將數(shù)據(jù)庫進行主從拆分，所有的寫操作操作主庫，所有的讀操作操作從庫，對主庫的更新操作會通過binlog同步到從庫上，從而在從庫也可以拿到最新的數(shù)據(jù)。如此一來，讀寫不再互相阻塞，性能至少提升1倍以上。就MySQL而言，主從熱備的功能可以通過cobar、mycat之類的框架來完成。
階段六：使用CDN和反向代理改善網(wǎng)站響應
網(wǎng)站的響應又一個直觀的指標（從用戶的角度）—— 訪問的快慢。這點直接關系到用戶體驗，因為如果用戶執(zhí)行一個請求老半天都沒有響應，很可能就直接失去了這個用戶，然后通過口啤效應，后果很嚴重。CDN和反向代理一種提高網(wǎng)站響應的手段。其基本原理都是緩存。CDN是部署再網(wǎng)絡提供商所在的機房，當用戶發(fā)起一個請求的時候，優(yōu)先從距離其較近的網(wǎng)絡提供商完成請求，而反向代理則是部署再網(wǎng)站的中心機房，當請求到達中心機房時，會首先由反向代理服務器完成請求，如果反向代理服務器存在請求的數(shù)據(jù)，那么直接返回數(shù)據(jù)給用戶。
階段七：使用分布式文件系統(tǒng)和分布式數(shù)據(jù)庫進一步改善讀寫壓力
當單表的數(shù)據(jù)量達到一定規(guī)模的時候，比如過千萬，即使使用數(shù)據(jù)庫索引進行優(yōu)化，完成的性能提升也是有限的。因為當單表的數(shù)據(jù)量達到千萬的時候受限于執(zhí)行SQL的數(shù)據(jù)庫引擎（比如MySQL的InnoDB），所以需要進行分庫分表。通常的做法時根據(jù)業(yè)務進行分庫（垂直拆分），根據(jù)單表的數(shù)據(jù)量限制做分表（水平拆分）。業(yè)務分庫需要根據(jù)具體的業(yè)務場景進行確定，相對來說比較好完成，分表就不是這樣了。因為在代碼中寫的SQL就是一張表，現(xiàn)在要分表，那原來的SQL肯定有問題。這個可以通過merge引擎來完成。
階段八：使用NoSQL和搜索引擎優(yōu)化檢索性能
使用NoSQL和搜索引擎時為了解決數(shù)據(jù)查詢的需求，比如在淘寶搜索一件商品的時候，總不能使用SQL的like進行匹配吧，效率太低！而搜索引擎可以利用倒排索引這種數(shù)據(jù)結(jié)構很好支持數(shù)據(jù)查詢。常用的解決方案時Lucene/Solr。
階段九：業(yè)務拆分讓網(wǎng)站維護更簡單
隨著業(yè)務場景的復雜化，將不同的業(yè)務分成不同的產(chǎn)品，就是把一個網(wǎng)站原來一個項目的情況拆分為根據(jù)不同的業(yè)務拆分為不同的項目。如果在項目中需要依賴其他項目的服務，比如在Maven工程中可以通過添加依賴的方式獲取。
階段十：抽取公共服務
這點很好理解，比如在不同的業(yè)務（項目）中都需要使用用戶管理這個業(yè)務，那么可以把這個業(yè)務抽取出來作為公共服務，需要的時候直接添加依賴即可。
技術點整理
雖然大型網(wǎng)站演變到現(xiàn)在，架構已經(jīng)非常復雜，但是仍然可以歸為以下的架構模型：
前端 ——> 應用層 ——> 服務層 ——> 存儲層 ——> 后臺架構
大型網(wǎng)站架構要素可以總結(jié)為5點：高性能、高可用、伸縮性、可擴展性、安全性。
高性能
主要關注以下幾個指標：響應時間（一個請求從發(fā)出請求到接收到響應數(shù)據(jù)需要的時間，是網(wǎng)站最重要的性能指標）、并發(fā)數(shù)（網(wǎng)站能夠同時處理請求的請求數(shù)）、吞吐量（單位時間內(nèi)系統(tǒng)處理的請求數(shù)，反映了網(wǎng)站的整體性能）。比如TPS是指每秒的事務數(shù)、QPS是指每秒的查詢數(shù)。并發(fā)數(shù)在逐漸增大的過程中，系統(tǒng)的吞吐量會先逐漸增加，到達一個極限后，隨著并發(fā)數(shù)的繼續(xù)增大反而下降，直至系統(tǒng)資源后耗盡，吞吐量為0。這是因為并發(fā)數(shù)增大的過程實際上系統(tǒng)資源消耗增大的過程。而在這個過程中，響應時間會先保持小幅的上升，到達吞吐量極限后，快速上升，資源耗盡后，系統(tǒng)失去響應。
高可用
高可用就是在網(wǎng)站發(fā)生故障的時候能夠迅速處理，保證網(wǎng)站服務依然可用、數(shù)據(jù)依然能夠被訪問。這里包括兩點：服務的高可用和數(shù)據(jù)的高可用。服務的高可用的通常處理策略是分級管理（核心業(yè)務使用更好的硬件資源）、超時設置（服務調(diào)用超時使用服務超時策略，比如繼續(xù)重試和服務調(diào)用轉(zhuǎn)移，由其他可用的服務提供服務）、異步調(diào)用（能晚則晚）、服務降級（在性能下降或者服務宕機的時候，使用拒絕服務以及關閉服務的策略，即使是失敗也要迅速返回，而不要讓請求一直hung著）、冪等性（保證在重復調(diào)用的情況下返回和調(diào)用一次的結(jié)果相同）。數(shù)據(jù)的高可用包括數(shù)據(jù)備份和失效轉(zhuǎn)移（某臺服務器宕機，能夠路由到其他機器繼續(xù)提供服務），在分布式環(huán)境，數(shù)據(jù)會被多個節(jié)點操作，如何保證數(shù)據(jù)的一致性是數(shù)據(jù)高可用的前提，這里涉及的核心技術點是CAP、BASE理論。
伸縮性
在不改變現(xiàn)有系統(tǒng)架構的前提下，僅僅通過增加或者減少機器就可以改變網(wǎng)站的處理能力。
可擴展性
指的是在對現(xiàn)有系統(tǒng)影響最小的情況下，系統(tǒng)功能的可持續(xù)擴展或者提升的能力。通常表現(xiàn)在應用之間較少的耦合、對需求變更敏捷響應，符合開閉原則。
安全性
保護網(wǎng)站不受惡意訪問和攻擊，保護網(wǎng)站的數(shù)據(jù)不被竊取和篡改。
技術點
下面是我整理的各個要素的核心技能點，更詳細的技能圖譜將在下篇博客中給出（思維導圖）。
高性能：分布式緩存（Redis）、異步調(diào)用（NIO/AIO + MQ（消息隊列） + JVM + 代碼優(yōu)化）、HDFS
高可用：分布式Session、異步調(diào)用 + 服務降級 + 冪等性保證、數(shù)據(jù)備份 + 失效轉(zhuǎn)移
伸縮性：負載均衡算法、一致性hash、cobar集群、Hbase
可擴展性：分布式消息隊列（RabbitMQ、ActiveMQ、ZeroMQ、Kafka）、分布式服務（dubbo、gRPC）
安全性：MD5，SHA（單項散列加密）、DES（對稱加密）、RSA，HTTPS（非對稱加密）
程序員價值觀
可以發(fā)現(xiàn)在大型網(wǎng)站的演變中每個階段需要解決的問題都是圍繞業(yè)務進行，而這點是直接與產(chǎn)生的價值掛鉤的。不過這都是大的方面了，因為作為一個程序員，我們更關心的技術本身以及技術所帶給我們的成長與增值空間。雖然我還不是一個有豐富經(jīng)驗的程序員，但是作為程序員很重要的一點就是保持學習、保持進步。我對自己的目標是三到五年內(nèi)能夠具有獨立架構設計能力，具有獨當一面的能力（包括人脈和自身能力（技能和知識儲備））。而我對自己設定的目標是在每天的上班之余堅持看書，不在于能看多少，重要的是有收獲，得到了成長。說來懺愧，這點并沒有很好的貫徹下去，但是自己以后會慢慢適應這種節(jié)奏的。
也許每天上班本來就很累，晚上下班回來還要抽空看書是痛苦的，但如果沒有這種毅力如何實現(xiàn)三年目標、五年目標呢？至少現(xiàn)在自己還年輕，有拼搏的本錢，所以就更應該好好珍惜時間，不斷地提升自我，爭取早日實現(xiàn)目標。
回到主題，首先需要認識到，掌握上述的技能點不是一朝一夕的，這就需要不斷在空閑時間升華自己，一點一滴積累。而且，掌握技能僅僅是第一步，真正牛逼的程序員是能夠把上述相關知識與技能進行重組，并且很好的解決業(yè)務問題，謂之“最佳實踐”。而且對每個技能點與知識一定要進行體系化學習，因為體系化的學習可以了解到技術的全貌，而不是僅僅在工作需要時Google就可以的。謂之技術的深度。牛逼的程序員的牛逼之處在于能夠?qū)夹g的實現(xiàn)細節(jié)了然于胸，這樣當系統(tǒng)出問題時才能迅速定位問題所在，并快速解決問題。而體系化的學習公認的最佳實踐就是看書了，所以千萬不要吝嗇買書的錢，因為買了，書的價值就在那，一切就等你去挖掘了！
我覺得可以先設立一個小目標，比如每個月至少4篇博客。道阻且長，我心向往之?。?/p>
