前言

博主畢業(yè)后從事互聯(lián)網(wǎng)領(lǐng)域研發(fā)工作也有些年頭了，混跡過一些互聯(lián)網(wǎng)公司师幕，也參與過不少系統(tǒng)的研發(fā)专控。從本文開始抹凳，將對(duì)這些年的經(jīng)歷做一個(gè)回顧總結(jié)。同時(shí)結(jié)合自己多年電商領(lǐng)域經(jīng)驗(yàn)伦腐，嘗試完成從0到1的電商項(xiàng)目赢底，從單體應(yīng)用到逐步實(shí)現(xiàn)集群、分布式、再到微服務(wù)的架構(gòu)演變~希望能有所沉淀幸冻，溫故而知新粹庞，下面我們開始吧~

什么是大型網(wǎng)站？

有時(shí)候要下個(gè)定義挺難的洽损，那么就從具體來說吧庞溜。博主曾經(jīng)在京東工作過，大家都知道京東是個(gè)大型網(wǎng)站碑定，這點(diǎn)應(yīng)該沒有異議流码。那它有哪些特點(diǎn)呢？

第一延刘，用戶體系龐大漫试、活躍

幾年前，早就過億了碘赖，日活也至少幾千萬驾荣。

第二，擁有海量數(shù)據(jù)普泡，支持大數(shù)據(jù)分析

每天產(chǎn)生的用戶瀏覽播掷、收藏、訂單等數(shù)據(jù)撼班，存儲(chǔ)了不知道多少歧匈，背后大數(shù)據(jù)進(jìn)行離線、實(shí)時(shí)計(jì)算权烧、模型訓(xùn)練眯亦，得到用戶畫像、進(jìn)行個(gè)性化智能推薦般码，實(shí)現(xiàn)千人千面。

第三乱顾，高并發(fā)板祝、高可用、響應(yīng)速度快

這是必須的走净，618券时、11.11，都是購物狂歡節(jié)伏伯，不能影響用戶體驗(yàn)橘洞。

第四，安全

正所謂樹大招風(fēng)说搅，安全第一炸枣，需要有相應(yīng)團(tuán)隊(duì)來防范，用戶的各種數(shù)據(jù)，要防止攻擊和泄露适肠。

演變的那些事

在web1.0時(shí)代霍衫，用戶是通過瀏覽器，單向的訪問服務(wù)器上的靜態(tài)網(wǎng)頁資源的侯养。

到后來敦跌，出現(xiàn)了數(shù)據(jù)庫，用戶和服務(wù)器之間可以雙向交互逛揩，可以進(jìn)行一些增加柠傍、修改的操作，并保存到數(shù)據(jù)庫中辩稽，進(jìn)行持久化存儲(chǔ)携兵。

在早期，比如傳統(tǒng)的Java Web開發(fā)搂誉，使用MVC模式徐紧，通過把應(yīng)用打成一個(gè)war包部署到服務(wù)器上，注意到這樣的網(wǎng)站早期是沒有多少流量的炭懊，一般文件服務(wù)器和數(shù)據(jù)庫服務(wù)器也在應(yīng)用服務(wù)器上并级，即是一個(gè)單體應(yīng)用。

隨著業(yè)務(wù)的發(fā)展侮腹，我們知道單體應(yīng)用面臨諸多問題嘲碧，比如，由于文件服務(wù)器父阻、數(shù)據(jù)庫服務(wù)器和應(yīng)用服務(wù)器都部署在同一臺(tái)愈涩，會(huì)導(dǎo)致網(wǎng)站的并發(fā)能力、存儲(chǔ)能力受到限制加矛，而且一旦應(yīng)用服務(wù)器掛掉履婉，意味著文件服務(wù)器和數(shù)據(jù)庫服務(wù)器將無法訪問了。為了避免這樣的毀滅性打擊斟览，于是出現(xiàn)了分離的方式毁腿，也就是把上面的各個(gè)不同角色的服務(wù)器分離成不同節(jié)點(diǎn)，分開部署苛茂。

我們知道已烤，用戶的大部分請(qǐng)求如果都直接落到數(shù)據(jù)庫上，那么db的壓力將變大妓羊，請(qǐng)求延時(shí)將增加胯究，用戶體驗(yàn)會(huì)下降，并發(fā)也提不上去躁绸，導(dǎo)致用戶流失裕循。為了提高請(qǐng)求臣嚣、響應(yīng)速度，一定程度上保護(hù)db费韭，同時(shí)提升并發(fā)能力茧球，我們可以使用緩存中間件（比如redis）。

到這里星持，我們會(huì)發(fā)現(xiàn)抢埋，不論是我們的應(yīng)用服務(wù)器，還是文件督暂、緩存服務(wù)器揪垄，都是單點(diǎn)的，如果掛了的話逻翁，對(duì)我們的網(wǎng)站將是災(zāi)難性的饥努，因此，又走向了集群的方式：

雖然八回，我們使用到了緩存中間件酷愧，但是一部分讀操作、全部的更新操作缠诅，依然會(huì)落到數(shù)據(jù)庫這邊溶浴。當(dāng)我們的網(wǎng)站用戶達(dá)到千萬級(jí)別以上的時(shí)候，數(shù)據(jù)庫負(fù)載能力就成為了瓶頸管引。既然數(shù)據(jù)庫同時(shí)進(jìn)行讀士败、寫操作壓力很大，那么我們可以考慮進(jìn)行讀寫分離褥伴。

用戶的大概20%的是寫操作谅将，80%的是查詢操作，即“二八原則”重慢。通過采用數(shù)據(jù)庫讀寫分離模式饥臂，主庫負(fù)責(zé)寫請(qǐng)求，從庫負(fù)責(zé)讀請(qǐng)求伤锚，這樣2波不同類型的流量被分配到不同節(jié)點(diǎn)上擅笔，從而改善了數(shù)據(jù)庫的負(fù)載能力。需要重點(diǎn)注意的是屯援，主從之間需要數(shù)據(jù)同步。

到這里念脯，就結(jié)束了么狞洋？不是的，大型網(wǎng)站隨著業(yè)務(wù)越來越多绿店，越來越復(fù)雜吉懊，數(shù)據(jù)量也很大庐橙，如果采用上面的架構(gòu)，顯然一旦db扛不住了借嗽，那就over了态鳖。于是，又需要對(duì)db進(jìn)行分庫分表操作了恶导。

所謂分庫分表浆竭，即把同一張表的數(shù)據(jù)，根據(jù)一定的規(guī)則算法惨寿，散列到不同庫上邦泄，有點(diǎn)分布式數(shù)據(jù)庫的味道，這也是我們對(duì)db進(jìn)行拆分的一種手段裂垦。這里需要特別注意的是顺囊，進(jìn)行分庫分表的話，每一張表的主鍵問題蕉拢，不可以自增長特碳，而是需要使用全局主鍵，也就是分布式全局id晕换。

到這里午乓，我們還可以想一下，如何為db繼續(xù)減負(fù)呢届巩？我們知道硅瞧，用戶的搜索請(qǐng)求其實(shí)蠻多的，如果利用緩存中間件和db來實(shí)現(xiàn)的話恕汇，其實(shí)比較費(fèi)勁的腕唧。

通過使用es/solor等搜索引擎，能讓海量搜索變的簡單易用瘾英，也保護(hù)了db枣接。

讓我們繼續(xù)，如果我們的網(wǎng)站是一個(gè)電商類的缺谴，那么會(huì)有商品業(yè)務(wù)但惶、訂單業(yè)務(wù)、庫存業(yè)務(wù)湿蛔、物流業(yè)務(wù)等等膀曾。那我們應(yīng)該將這些業(yè)務(wù)獨(dú)立拆分成產(chǎn)品線，成為一個(gè)個(gè)獨(dú)立的子系統(tǒng)（or 服務(wù)）阳啥，交給不同團(tuán)隊(duì)進(jìn)行維護(hù)添谊。

到這里，其實(shí)我們的網(wǎng)站察迟，就處于一個(gè)微服務(wù)的階段了斩狱。由于用戶的一些請(qǐng)求耳高，需要到達(dá)多個(gè)業(yè)務(wù)系統(tǒng)來完成，所以這里又出現(xiàn)分布式事務(wù)的問題所踊。在不同的服務(wù)集群進(jìn)行通信的時(shí)候泌枪，可能涉及到一些分布式中間件，比如mq秕岛，zookeeper等碌燕。在演變的過程中，除了架構(gòu)的調(diào)整瓣蛀，我們還可能涉及到一些調(diào)優(yōu)陆蟆，比如JVM/db調(diào)優(yōu)等。

小結(jié)

到這里惋增，我們可以看到大型網(wǎng)站叠殷，并非一蹴而就，而是逐步演變诈皿、迭代升級(jí)的林束。朋友們，下篇見（詳情可以參見稽亏，我的公眾號(hào)：豐哲同學(xué) ）~