文章大綱
一、演變過程思路圖
二骂删、何為大型網(wǎng)站
三掌动、架構(gòu)體系演進(jìn)
四四啰、架構(gòu)總結(jié)
五宁玫、參考文章
一、演變過程思路圖
二柑晒、何為大型網(wǎng)站
1. 大型網(wǎng)站特性
既然說的是大型網(wǎng)站架構(gòu)欧瘪，那么架構(gòu)的背后自然是解決人因面對大型網(wǎng)站特性而帶來的問題。這樣可以先給大家說下大型網(wǎng)站的特性匙赞，這些特性帶來的問題就是人要解決的問題：
（1）高并發(fā)佛掖、大流量：PV 量巨大；
（2）高可用：7*24 小時(shí)不間斷服務(wù)涌庭；
（3）海量數(shù)據(jù)：文件數(shù)目分分鐘 xxTB芥被；
（4）用戶分布廣泛，網(wǎng)絡(luò)情況復(fù)雜：網(wǎng)絡(luò)運(yùn)營商坐榆；
（5）安全環(huán)境惡劣：黑客的攻擊拴魄；
（6）需求快速變更，發(fā)布頻繁：快速適應(yīng)市場席镀，滿足用戶需求匹中；
（7）漸進(jìn)式發(fā)展：慢慢地運(yùn)營出大型網(wǎng)站；
2. 大型網(wǎng)站架構(gòu)理解
大型網(wǎng)站架構(gòu)的概念對于每一個(gè)開發(fā)者來說很籠統(tǒng)豪诲、很模糊顶捷，正如盲人摸象，看到的屎篱、了解到的只是很小的一部分服赎，大部分情況下我們只是負(fù)責(zé)架構(gòu)中的一小塊內(nèi)容，所以很難清晰地給出具體定義交播。這就是所謂“不識廬山真面目 只緣身在此山中”的尷尬吧重虑。所以我們要跳出來，站在宏觀的角度堪侯，從整體到細(xì)節(jié)實(shí)現(xiàn)來認(rèn)識大型網(wǎng)站架構(gòu)嚎尤。
那么從宏觀的角度怎么去認(rèn)識大型網(wǎng)站架構(gòu)呢？正如前面幾篇《細(xì)品架構(gòu)系列》所描述對架構(gòu)的認(rèn)識伍宦，按照問題識別—>概念認(rèn)知—>架構(gòu)切分的思路芽死，來分析大型網(wǎng)站架構(gòu)的誕生：
- 問題識別：當(dāng)前什么問題乏梁、誰的問題、問題邊界关贵；
- 概念認(rèn)知：通過分析問題遇骑，會(huì)產(chǎn)生哪些概念，統(tǒng)一概念認(rèn)知揖曾，達(dá)成溝通交流規(guī)范落萎；
- 架構(gòu)切分：根據(jù)概念來解決問題，如何架構(gòu)切分炭剪，產(chǎn)生哪些架構(gòu)练链，提出具體解決方案；
PS：上面的三個(gè)步驟具體如何識別奴拦、認(rèn)知媒鼓、切分，請?jiān)敿?xì)參考前面幾篇《細(xì)品架構(gòu)系列》文章错妖，可能使你會(huì)對架構(gòu)有重新的認(rèn)識绿鸣。
在進(jìn)行分析大型網(wǎng)站架構(gòu)的演進(jìn)之路前，首先我們要明確的兩個(gè)價(jià)值觀：
- 核心價(jià)值：隨網(wǎng)站所需靈活應(yīng)對暂氯；大型網(wǎng)站不是從無到有一步就搭建好一個(gè)大型網(wǎng)站潮模，而是能夠伴隨小型網(wǎng)站業(yè)務(wù)的漸進(jìn)發(fā)展，慢慢地演化成一個(gè)大型網(wǎng)站痴施；
- 驅(qū)動(dòng)力量：網(wǎng)站的業(yè)務(wù)發(fā)展— 業(yè)務(wù)成就了技術(shù)擎厢，事業(yè)成就了人，而不是相反晾剖；
還有锉矢，大型網(wǎng)站架構(gòu)演進(jìn)必須避免的幾個(gè)誤區(qū)：
- 一味追隨大公司的解決方案；
- 為了技術(shù)而技術(shù)-->常見問題齿尽；
- 企圖用技術(shù)解決所有問題：技術(shù)是用來解決業(yè)務(wù)問題的沽损，而業(yè)務(wù)的問題，也可以通過業(yè)務(wù)的手段去解決循头；
三绵估、架構(gòu)體系演進(jìn)
1. 單機(jī)時(shí)代
草根時(shí)期，快速開發(fā)網(wǎng)站并上線卡骂。當(dāng)然国裳，通常只是先試水，用戶規(guī)模也沒有形成全跨，經(jīng)濟(jì)能力和投入也非常有限缝左。應(yīng)用程序、數(shù)據(jù)庫、文件等所有資源都集中在一臺(tái) Server上渺杉，典型案例：基于 LAMP 架構(gòu)的 PHP 網(wǎng)站蛇数；
優(yōu)點(diǎn)：簡單、快速迭代達(dá)成業(yè)務(wù)目標(biāo)是越；
缺點(diǎn)：存在單點(diǎn)耳舅、談不上高可用；
技術(shù)點(diǎn)：應(yīng)用設(shè)計(jì)要保證可擴(kuò)展倚评；
2. 緩存出場
有一定的業(yè)務(wù)量和用戶規(guī)模了浦徊，想提升網(wǎng)站速度，于是天梧，緩存出場了盔性。
優(yōu)點(diǎn)：簡單有效、方便維護(hù)腿倚；
缺點(diǎn)：存在單點(diǎn)纯出、談不上高可用蚯妇；
技術(shù)點(diǎn)：客戶端（瀏覽器）緩存敷燎、前端頁面緩存、頁面片段緩存箩言、本地?cái)?shù)據(jù)緩存/數(shù)據(jù)庫緩存硬贯、遠(yuǎn)程緩存；
如上圖陨收，緩存可以分為：
- 頁面緩存：客戶端緩存饭豹，減少對網(wǎng)站的訪問；
- 本地緩存：訪問速度快务漩，但數(shù)據(jù)量有限拄衰，減少對DB查詢；
- 遠(yuǎn)程緩存：遠(yuǎn)程訪問饵骨，可以集群翘悉，因此容量不受限制；
3. 數(shù)據(jù)服務(wù)與應(yīng)用分離
市場反響還不錯(cuò)居触，用戶量每天在增長妖混，數(shù)據(jù)庫瘋狂讀寫，逐漸發(fā)現(xiàn)一臺(tái)服務(wù)器快撐不住了轮洋。于是制市，決定把數(shù)據(jù)服務(wù)和APP做分離。
優(yōu)點(diǎn)：簡單有效弊予、方便維護(hù)祥楣、提高不同Server對硬件資源的利用率；
缺點(diǎn)：存在單點(diǎn)、談不上高可用误褪；
技術(shù)點(diǎn)：文件服務(wù)器部署床未、數(shù)據(jù)庫服務(wù)器，擴(kuò)展數(shù)據(jù)訪問模塊振坚；
分離后三臺(tái) Server 對硬件資源的需求各不相同：
- 應(yīng)用服務(wù)器：需要更快更強(qiáng)大的 CPU薇搁；
- 數(shù)據(jù)庫服務(wù)器：需要更快的硬盤和更大的內(nèi)存；
- 文件服務(wù)器：需要更大的硬盤渡八；
4. 數(shù)據(jù)庫讀寫分離
單臺(tái)數(shù)據(jù)庫也感覺快撐不住了啃洋，一般都會(huì)嘗試做“讀寫分離”。由于大部分互聯(lián)網(wǎng)“讀多寫少”的特性所決定的屎鳍。Salve的臺(tái)數(shù)宏娄，取決于按業(yè)務(wù)評估的讀寫比例。
優(yōu)點(diǎn)：簡單有效逮壁、降低數(shù)據(jù)庫單臺(tái)壓力孵坚；
缺點(diǎn)：讀寫分離，增加程序難度窥淆，架構(gòu)變復(fù)雜卖宠，維護(hù)難度增加；
技術(shù)點(diǎn)：數(shù)據(jù)庫主從同步部署忧饭，擴(kuò)展數(shù)據(jù)訪問模塊扛伍，實(shí)現(xiàn)讀寫分離；
5. 應(yīng)用服務(wù)集群
數(shù)據(jù)庫層面是緩解了词裤，但是應(yīng)用程序?qū)用嬉渤霈F(xiàn)了瓶頸刺洒，由于訪問量增大，加上早期程序員水平有限寫的代碼也很爛吼砂，人員流動(dòng)性也大逆航，很難去維護(hù)和優(yōu)化。所以渔肩，很常用的辦法還是“堆機(jī)器”因俐。
優(yōu)點(diǎn)：增加服務(wù)器和HA機(jī)制，系統(tǒng)性能及可用性得到保證赖瞒；
缺點(diǎn)：應(yīng)用之間緩存女揭、Session一致性問題；
技術(shù)點(diǎn)：負(fù)載均衡栏饮；
通過集群解決高并發(fā)吧兔、海量數(shù)據(jù)問題的常用手段，實(shí)現(xiàn)系統(tǒng)的可伸縮性袍嬉。通過負(fù)載均衡調(diào)度器境蔼，可將用戶訪問分發(fā)到集群中的某臺(tái) Server 上灶平，應(yīng)用服務(wù)器的負(fù)載壓力不再成為整個(gè)網(wǎng)站的瓶頸。
6. 集中式緩存箍土、Session集中存儲(chǔ)
加機(jī)器誰都會(huì)加逢享，關(guān)鍵是加完之后得有效果，加完之后可能會(huì)引發(fā)一些問題吴藻。例如非常常見的：集群應(yīng)用之間頁面輸出緩存和本地緩存一致性的問題瞒爬，Session保存的問題......。
優(yōu)點(diǎn)：應(yīng)用之間緩存沟堡、Session一致侧但，存儲(chǔ)無限制，可以擴(kuò)展航罗；
缺點(diǎn)：不如本地緩存訪問快禀横，緩存服務(wù)器、Session服務(wù)器等仍存在單點(diǎn)問題粥血；
技術(shù)點(diǎn)：緩存服務(wù)器部署柏锄、Session集中存儲(chǔ)方案；
7. 動(dòng)靜分離
動(dòng)靜分離也是提高網(wǎng)站響應(yīng)速度的一種常用方式复亏。將動(dòng)態(tài)請求與靜態(tài)請求分離開趾娃，盡量減少對應(yīng)用服務(wù)器的壓力。同時(shí)蜓耻，可以再進(jìn)一步對靜態(tài)請求茫舶，進(jìn)行緩存，以加快響應(yīng)速度刹淌。可以需要開發(fā)人員配合（把靜態(tài)資源放獨(dú)立站點(diǎn)下）讥耗，也可以不需要開發(fā)人員配合（利用7層反向代理來處理有勾，根據(jù)后綴名等信息來判斷資源類型）。
優(yōu)點(diǎn)：減輕應(yīng)用負(fù)載壓力古程，針對靜態(tài)文件緩存蔼卡；
缺點(diǎn)：靜態(tài)文件緩存更新失效問題；
技術(shù)點(diǎn)：動(dòng)靜分離挣磨、靜態(tài)文件緩存方案雇逞；
8. 反向代理和CDN加速網(wǎng)站響應(yīng)
使用反向代理和CDN加速網(wǎng)站響應(yīng)：CDN 和反向代理的基本原理都是緩存，區(qū)別在于：
- CDN部署在網(wǎng)絡(luò)提供商的機(jī)房茁裙；
- 反向代理則部署在網(wǎng)站的中心機(jī)房塘砸；
使用 CDN 和反向代理的目的都是盡早返回?cái)?shù)據(jù)給用戶，一方面加快用戶訪問速度晤锥，另一方面也減輕后端服務(wù)器的負(fù)載壓力掉蔬。
優(yōu)點(diǎn)：減輕應(yīng)用負(fù)載壓力廊宪，異地緩存有效解決不同地方用戶訪問過慢的問題；
缺點(diǎn)：成本大幅增加女轿，架構(gòu)進(jìn)一步復(fù)雜化箭启，也維護(hù)難度進(jìn)一步增大，靜態(tài)文件緩存更新失效問題蛉迹；
技術(shù)點(diǎn)：CDN傅寡、反向代理方案；
9. 使用NoSQL和搜索引擎
到這里北救，已經(jīng)基本做到了DB層面和應(yīng)用層面的橫向擴(kuò)展了赏僧，可以開始關(guān)注一些其它方面，例如：站內(nèi)搜索的精準(zhǔn)度扭倾，對DB的依賴淀零，開始引入全文索引、NoSQL膛壹。
NoSQL和搜索引擎都是源自互聯(lián)網(wǎng)的技術(shù)手段驾中，對可伸縮的分布式特性具有更好的支持。應(yīng)用服務(wù)器則通過一個(gè)統(tǒng)一數(shù)據(jù)訪問模塊訪問各種數(shù)據(jù)模聋，減輕應(yīng)用程序管理諸多數(shù)據(jù)源的麻煩肩民。
優(yōu)點(diǎn)：降低DB依賴；
缺點(diǎn)：單點(diǎn)問題链方，談不上高可用持痰；
技術(shù)點(diǎn)：NoSQL、搜索引擎祟蚀、分布式工窍；
到目前為止，一個(gè)能夠承載日均百萬級訪問量的中型網(wǎng)站架構(gòu)基本介紹完了前酿。
10. 如何保證高可用
在做擴(kuò)展?jié)M足了基本的性能需求后患雏，我們會(huì)逐漸關(guān)注“可用性”（也就是我們通常聽別人吹牛時(shí)說的SLA、幾個(gè)9）罢维。如何保證真正“高可用”淹仑，也是個(gè)難題。
對關(guān)鍵應(yīng)用/服務(wù)肺孵，做集群冗余負(fù)載匀借，這也是保證高可用比較常用的手段：
- 文件系統(tǒng)、數(shù)據(jù)庫系統(tǒng)集群平窘；
- 靜態(tài)內(nèi)容服務(wù)器集群吓肋；
- CDN服務(wù)器集群；
- 反向代理服務(wù)器集群初婆；
- 負(fù)載均衡調(diào)度器集群蓬坡；
- 分布式NoSQL服務(wù)器集群猿棉；
- 搜索引擎服務(wù)器集群；
- 分布式緩存服務(wù)器集群屑咳；
- 分布式Session服務(wù)器集群萨赁；
優(yōu)點(diǎn)：集群負(fù)載，保證高可用兆龙；
缺點(diǎn)：數(shù)據(jù)一致性杖爽、數(shù)據(jù)有狀態(tài)問題；
技術(shù)點(diǎn)：負(fù)載調(diào)度器紫皇、集群方案慰安；
截止目前為止，都沒有怎么去改動(dòng)應(yīng)用程序的架構(gòu)聪铺，或者說通俗點(diǎn)化焕，都不怎么需要大面積的修改代碼。
如果上面那些手段都用光了铃剔，還是支撐不住怎么辦撒桨？不停的加機(jī)器也不是辦法啊键兜？
11. 應(yīng)用垂直拆分
隨著業(yè)務(wù)越來越復(fù)雜凤类，網(wǎng)站的功能越來越多，雖然部署層面是采用的集群普气，但是應(yīng)用程序架構(gòu)層面還是“集中式”的谜疤，這樣會(huì)導(dǎo)致很多耦合，不便于開發(fā)现诀、維護(hù)夷磕，而且容易“一榮俱損”。所以赶盔，通常會(huì)把網(wǎng)站拆分出不同的子站點(diǎn)來單獨(dú)宿主企锌。
通過分而治之的手段將整個(gè)網(wǎng)站業(yè)務(wù)分成不同的產(chǎn)品線，如首頁于未、商鋪、訂單陡鹃、賣家烘浦、買家等 拆分成不同的產(chǎn)品線，分歸不同的業(yè)務(wù)團(tuán)隊(duì)負(fù)責(zé)萍鲸。各個(gè)應(yīng)用之間可以通過建立一個(gè)超鏈接建立關(guān)系闷叉，也可以通過消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)。
優(yōu)點(diǎn)：降低耦合脊阴、分壓握侧；
缺點(diǎn)：應(yīng)用架構(gòu)復(fù)雜蚯瞧；
技術(shù)點(diǎn)：業(yè)務(wù)抽取拆分；
12. 業(yè)務(wù)垂直分庫
應(yīng)用都拆了品擎，由于單個(gè)數(shù)據(jù)庫的連接埋合，QPS，TPS萄传，I/O處理能力都非常有限甚颂，DB層面也可以去做垂直分庫操作。
優(yōu)點(diǎn)：降低DB耦合秀菱、分壓DB振诬；
缺點(diǎn)：數(shù)據(jù)訪問模塊復(fù)雜；
技術(shù)點(diǎn)：業(yè)務(wù)抽取拆分衍菱；
13. 分布式服務(wù)化
拆分應(yīng)用和DB之后赶么，其實(shí)還是會(huì)有很多問題。不同的站點(diǎn)脊串，里面可能會(huì)有相同邏輯和功能的代碼辫呻。當(dāng)然，對于一些基礎(chǔ)的功能我們可以封裝DLL或者Jar包去到處提供引用洪规，但是這種強(qiáng)依賴也很容易造成一些問題（版本問題印屁、依賴關(guān)系等處理起來非常麻煩）。
既然每一個(gè)應(yīng)用系統(tǒng)都需要執(zhí)行許多相通的業(yè)務(wù)操作斩例，比如用戶管理雄人、商品管理等，那么可以將這些共用的業(yè)務(wù)提取出來念赶，獨(dú)立部署础钠。這樣，傳說中的SOA的價(jià)值就得到體現(xiàn)了叉谜。
優(yōu)點(diǎn)：服務(wù)統(tǒng)一管理旗吁，提供重用度；
缺點(diǎn)：應(yīng)用架構(gòu)更復(fù)雜停局；
技術(shù)點(diǎn)：業(yè)務(wù)抽取拆分很钓、服務(wù)化技術(shù)方案；
14. 消息隊(duì)列
應(yīng)用董栽、服務(wù)之間還是會(huì)出現(xiàn)一些依賴問題宾毒，這時(shí)候杉畜，高吞吐量的解耦利器出現(xiàn)了腻惠。
優(yōu)點(diǎn)：提高吞吐量分唾、應(yīng)用、服務(wù)之間解耦擒抛；
缺點(diǎn)：存在消息消費(fèi)延遲問題推汽；
技術(shù)點(diǎn)：消息隊(duì)列技術(shù)方案补疑；
15. 分庫分表
最后，再介紹一個(gè)大型互聯(lián)網(wǎng)公司都用的絕技--分庫分表歹撒。個(gè)人經(jīng)驗(yàn)莲组，不是業(yè)務(wù)發(fā)展和各方面非常迫切，不要輕易走這一步栈妆。
因?yàn)榉謳旆直碚l都會(huì)干胁编，關(guān)鍵是拆完之后怎么辦。目前鳞尔，市面上還沒有完全開源免費(fèi)的方案嬉橙，能讓你一勞永逸地解決數(shù)據(jù)庫拆分問題。
分庫分表：
橫向拆分寥假；
縱向拆分市框；
分布式數(shù)據(jù)庫訪問層；
數(shù)據(jù)庫中間件（代理）糕韧；
四枫振、架構(gòu)總結(jié)
上面講述了在網(wǎng)站業(yè)務(wù)發(fā)展的不同階段，會(huì)面臨不同的問題萤彩，針對不同的問題粪滤，會(huì)選擇不同的架構(gòu)。大型網(wǎng)站架構(gòu)就是在不同階段時(shí)解決不同問題的過程中慢慢演進(jìn)來的雀扶。
最后幾句話杖小，送給有緣的你：
一切以解決業(yè)務(wù)目標(biāo)為首要任務(wù)；
沒有以業(yè)務(wù)為目標(biāo)的任何架構(gòu)愚墓、技術(shù)予权，都是毫無意義的耍流氓；
再牛逼的架構(gòu)浪册、再牛逼的技術(shù)扫腺，不能夠解決業(yè)務(wù)的問題，你也只能算是會(huì)架構(gòu)村象、會(huì)技術(shù)的工匠笆环，而不能算是真正意義上的架構(gòu)師；
業(yè)務(wù)成就了技術(shù)厚者，平臺(tái)成就了人咧织，事業(yè)成就了人，而不是相反籍救；
