進(jìn)入互聯(lián)網(wǎng)行業(yè)做后臺(tái)研發(fā)工作，也將近兩年了掏膏，一直以來(lái)對(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ù)庫(kù)均部署在一臺(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)致的性能問題组底。
如此一來(lái)，應(yīng)用服務(wù)器配備更高性能的CPU以滿足業(yè)務(wù)邏輯處理筐骇，數(shù)據(jù)庫(kù)服務(wù)器配備高性能磁盤及大容量?jī)?nèi)存以滿足快速的磁盤檢索與數(shù)據(jù)緩存债鸡，文件服務(wù)器配備大容量磁盤來(lái)滿足用戶上傳文件的存儲(chǔ)。
S3 DB不行拥褂，緩存來(lái)扛
用戶漸增娘锁，網(wǎng)站并發(fā)請(qǐng)求數(shù)增加，直接導(dǎo)致數(shù)據(jù)庫(kù)并發(fā)處理壓力過大饺鹃，再一次面臨站點(diǎn)響應(yīng)緩慢而影響用戶體驗(yàn)莫秆。
考慮到用戶訪問的數(shù)據(jù)并非均勻分布，而是類似于“二八定律”悔详，80%的用戶集中訪問20%的數(shù)據(jù)镊屎，所以，緩存少部分熱點(diǎn)數(shù)據(jù)茄螃，直接大幅降低數(shù)據(jù)庫(kù)的并發(fā)壓力缝驳。
S4 使用應(yīng)用服務(wù)器集群，水平線性擴(kuò)展網(wǎng)站并發(fā)處理能力
緩解了數(shù)據(jù)庫(kù)的訪問壓力后，網(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ī)器無(wú)論如何都無(wú)法支撐持續(xù)高速增長(zhǎng)的業(yè)務(wù)咏连。
S5 數(shù)據(jù)庫(kù)讀寫分離
盡管S3階段中數(shù)據(jù)層新增的緩存層頂住了相當(dāng)比例的DB訪問請(qǐng)求，但仍然有小比例的讀操作祟滴、全部的寫操作到達(dá)DB，當(dāng)用戶到達(dá)一定規(guī)模歌溉，這部分比例的DB讀寫請(qǐng)求仍會(huì)到達(dá)數(shù)據(jù)庫(kù)并發(fā)上限垄懂，尤其高峰時(shí)段。
這個(gè)階段研底，常用套路就是數(shù)據(jù)庫(kù)讀寫分離埠偿，把相當(dāng)比例的讀請(qǐng)求剝離到從庫(kù)，分擔(dān)主庫(kù)壓力榜晦。
S6 CDN加速網(wǎng)站響應(yīng)
繼數(shù)據(jù)庫(kù)讀寫分離后，整個(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，快速返回給用戶端脑融，提高頁(yè)面加載速度喻频，同時(shí)降低應(yīng)用服務(wù)器壓力（更少的機(jī)器支撐更多業(yè)務(wù)，同時(shí)也降低成本了）肘迎。
注：一般說(shuō)還可以搭配反向代理緩存靜態(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ù)庫(kù)系統(tǒng)
自業(yè)務(wù)拆分后涧尿，在體量龐大的業(yè)務(wù)系統(tǒng)中，讀寫分離的數(shù)據(jù)庫(kù)架構(gòu)仍然存在壓力檬贰。
一方面姑廉，不同體量的業(yè)務(wù)數(shù)據(jù)庫(kù)混合部署于同一物理機(jī)器上，互相影響翁涤，常用解決手段是按業(yè)務(wù)維度桥言，單獨(dú)部署數(shù)據(jù)庫(kù)（水平拆分）；
另一方面葵礼，體量大的業(yè)務(wù)數(shù)據(jù)庫(kù)存在并發(fā)瓶頸号阿、龐大單表讀寫操作效率低下等問題，常用的解決手段是按數(shù)據(jù)的某個(gè)維度（比如UID鸳粉、商品）分庫(kù)分表（垂直拆分）扔涧。
對(duì)于文件服務(wù)，也是類似的届谈。
S9 NoSQL與搜索引擎
隨著網(wǎng)站業(yè)務(wù)越來(lái)越復(fù)雜枯夜，對(duì)數(shù)據(jù)存儲(chǔ)與搜索的需求也變得復(fù)雜（數(shù)據(jù)庫(kù)的分庫(kù)分表也是造成搜索困難的原因之一），網(wǎng)站需要非關(guān)系數(shù)據(jù)庫(kù)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è)解決方案俏让。
