進(jìn)入互聯(lián)網(wǎng)行業(yè)做后臺(tái)研發(fā)工作，也將近兩年了，一直以來對(duì)譬如騰訊、淘寶這樣的大型互聯(lián)網(wǎng)架構(gòu)沒有全面的認(rèn)識(shí)，可能頂多只是比較了解當(dāng)中的一些點(diǎn)。
這樣的情況，其實(shí)是比較危險(xiǎn)的，就如同，生活在一個(gè)城市的路盲，只了解自己家附近的幾條街巷、或者只了解常去商業(yè)區(qū)域周邊的話，一旦你身處這些區(qū)域之外（面臨的問題超出了自己所掌握技術(shù)點(diǎn)的解決范疇），那基本寸步難行，哪怕尋找路人幫助或者看導(dǎo)航地圖，也常少不了走彎路。
本文主要簡(jiǎn)要匯總下大型互聯(lián)網(wǎng)技術(shù)架構(gòu)的演變過程，希望給出一個(gè)全面的認(rèn)識(shí)。
對(duì)于每一次演變著重從以下三點(diǎn)介紹：
- 演變背后的驅(qū)動(dòng)力（每一次演變主要矛盾）
- 解決（緩解）矛盾的套路
- 每一次套路背后的考量
S1 初始階段的網(wǎng)站架構(gòu)
起步階段用戶不多，通常只需要一臺(tái)服務(wù)器即可滿足，應(yīng)用程序、文件及數(shù)據(jù)庫均部署在一臺(tái)物理機(jī)器上。
S2 應(yīng)用服務(wù)與數(shù)據(jù)服務(wù)分離
隨著業(yè)務(wù)發(fā)展，用戶漸增，服務(wù)器負(fù)載高居不下，站點(diǎn)響應(yīng)變慢，同時(shí)數(shù)據(jù)增多導(dǎo)致存儲(chǔ)空間捉襟見肘。
考慮到應(yīng)用、數(shù)據(jù)、文件三種服務(wù)對(duì)硬件資源的要求存在差異，物理上分離部署（分層套路），可以緩解因一臺(tái)服務(wù)器資源吃緊導(dǎo)致的性能問題。
如此一來，應(yīng)用服務(wù)器配備更高性能的CPU以滿足業(yè)務(wù)邏輯處理，數(shù)據(jù)庫服務(wù)器配備高性能磁盤及大容量?jī)?nèi)存以滿足快速的磁盤檢索與數(shù)據(jù)緩存，文件服務(wù)器配備大容量磁盤來滿足用戶上傳文件的存儲(chǔ)。
S3 DB不行，緩存來扛
用戶漸增，網(wǎng)站并發(fā)請(qǐng)求數(shù)增加，直接導(dǎo)致數(shù)據(jù)庫并發(fā)處理壓力過大，再一次面臨站點(diǎn)響應(yīng)緩慢而影響用戶體驗(yàn)。
考慮到用戶訪問的數(shù)據(jù)并非均勻分布，而是類似于“二八定律”，80%的用戶集中訪問20%的數(shù)據(jù)，所以，緩存少部分熱點(diǎn)數(shù)據(jù)，直接大幅降低數(shù)據(jù)庫的并發(fā)壓力。
S4 使用應(yīng)用服務(wù)器集群，水平線性擴(kuò)展網(wǎng)站并發(fā)處理能力
緩解了數(shù)據(jù)庫的訪問壓力后，網(wǎng)站高峰期的并發(fā)數(shù)接近單一應(yīng)用服務(wù)器的處理上限，此時(shí)應(yīng)用服務(wù)器成為瓶頸。
負(fù)載均衡+應(yīng)用服務(wù)器集群是非常有效的解決方案（集群套路），在一定規(guī)模內(nèi)（達(dá)到負(fù)載均衡單點(diǎn)能力上限之前），可以實(shí)現(xiàn)線性的服務(wù)能力伸縮（靈活的伸縮性）。
除此之外，企圖更換更強(qiáng)性能的應(yīng)用服務(wù)器是徒勞的，因?yàn)橐慌_(tái)機(jī)器無論如何都無法支撐持續(xù)高速增長(zhǎng)的業(yè)務(wù)。
S5 數(shù)據(jù)庫讀寫分離
盡管S3階段中數(shù)據(jù)層新增的緩存層頂住了相當(dāng)比例的DB訪問請(qǐng)求，但仍然有小比例的讀操作、全部的寫操作到達(dá)DB，當(dāng)用戶到達(dá)一定規(guī)模，這部分比例的DB讀寫請(qǐng)求仍會(huì)到達(dá)數(shù)據(jù)庫并發(fā)上限，尤其高峰時(shí)段。
這個(gè)階段，常用套路就是數(shù)據(jù)庫讀寫分離，把相當(dāng)比例的讀請(qǐng)求剝離到從庫，分擔(dān)主庫壓力。
S6 CDN加速網(wǎng)站響應(yīng)
繼數(shù)據(jù)庫讀寫分離后，整個(gè)網(wǎng)站的通常情況下響應(yīng)尚可。
但在大促/活動(dòng)場(chǎng)景下，某些業(yè)務(wù)的高并發(fā)訪問（比如秒殺），仍然對(duì)應(yīng)用服務(wù)器的網(wǎng)絡(luò)/磁盤IO有不小壓力，妨害用戶體驗(yàn)。
對(duì)于靜態(tài)資源（圖片及js文件等）可以部署到CDN，快速返回給用戶端，提高頁面加載速度，同時(shí)降低應(yīng)用服務(wù)器壓力（更少的機(jī)器支撐更多業(yè)務(wù)，同時(shí)也降低成本了）。
注：一般說還可以搭配反向代理緩存靜態(tài)內(nèi)容，但尚未搞清楚CDN與反向代理的區(qū)別是什么，這里暫且不提。
S7 業(yè)務(wù)拆分與分布式服務(wù)
隨著業(yè)務(wù)的發(fā)展，面向用戶的產(chǎn)品也呈現(xiàn)多樣性，為有效地組織與管理公司業(yè)務(wù)，
通常將整個(gè)網(wǎng)站業(yè)務(wù)劃分成不同產(chǎn)品線（公司組織架構(gòu)層面也作相應(yīng)的調(diào)整），交由不同業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)，這是業(yè)務(wù)層面的拆分。
另一個(gè)，在業(yè)務(wù)拆分的背后，需要有分布式服務(wù)的支撐，以支持靈活的伸縮性。
因?yàn)闃I(yè)務(wù)拆分過程，伴隨著公共業(yè)務(wù)（用戶管理、支付等）的獨(dú)立，以及不同體量業(yè)務(wù)間的分離，
公共業(yè)務(wù)及大體量的業(yè)務(wù)訪問量非常之大，為了避免不同體量的業(yè)務(wù)采用一刀切的方式伸縮（控制成本），分布式服務(wù)成為必要的選擇，可以實(shí)現(xiàn)不同業(yè)務(wù)按需部署，靈活伸縮。
問題：為什么采用分布式服務(wù)？為什么采用的微服務(wù)架構(gòu)？
S8 數(shù)據(jù)層最后的殺手锏：分布式文件系統(tǒng)、分布式數(shù)據(jù)庫系統(tǒng)
自業(yè)務(wù)拆分后，在體量龐大的業(yè)務(wù)系統(tǒng)中，讀寫分離的數(shù)據(jù)庫架構(gòu)仍然存在壓力。
一方面，不同體量的業(yè)務(wù)數(shù)據(jù)庫混合部署于同一物理機(jī)器上，互相影響，常用解決手段是按業(yè)務(wù)維度，單獨(dú)部署數(shù)據(jù)庫（水平拆分）；
另一方面，體量大的業(yè)務(wù)數(shù)據(jù)庫存在并發(fā)瓶頸、龐大單表讀寫操作效率低下等問題，常用的解決手段是按數(shù)據(jù)的某個(gè)維度（比如UID、商品）分庫分表（垂直拆分）。
對(duì)于文件服務(wù)，也是類似的。
S9 NoSQL與搜索引擎
隨著網(wǎng)站業(yè)務(wù)越來越復(fù)雜，對(duì)數(shù)據(jù)存儲(chǔ)與搜索的需求也變得復(fù)雜（數(shù)據(jù)庫的分庫分表也是造成搜索困難的原因之一），網(wǎng)站需要非關(guān)系數(shù)據(jù)庫NoSQL與搜索引擎的支撐。
大型的網(wǎng)站架構(gòu)演化到這里，基本上大多數(shù)的技術(shù)問題都得以解決。
但這只是，基本上T_T
一方面，一個(gè)大型網(wǎng)站架構(gòu)進(jìn)化至此，web層、服務(wù)層、數(shù)據(jù)層均是靈活的伸縮性架構(gòu)，水平擴(kuò)展加機(jī)器就能解決問題。但當(dāng)中仍然存在不少組件（中間件）并非分布式，而是集中式，例如常見的master-slave架構(gòu)的服務(wù)注冊(cè)中心，隨著業(yè)務(wù)體量的增長(zhǎng)，早晚也會(huì)超出這些組件的性能上限。
另一方面，整個(gè)網(wǎng)站部署于同一機(jī)房，規(guī)模本身也會(huì)受限于機(jī)房固有的物理空間。
對(duì)于前面的兩個(gè)問題，阿里基于單元化（超級(jí)體量的業(yè)務(wù)）與中心化（一般體量業(yè)務(wù)）的異地多活架構(gòu)是一個(gè)解決方案。
