[[442158]]

本文轉(zhuǎn)載自微信公眾號(hào)「Cone的編程屋」，作者Cone。轉(zhuǎn)載本文請(qǐng)聯(lián)系Cone的編程屋公眾號(hào)。

你好，我是Cone。

最近在讀大型互聯(lián)網(wǎng)架構(gòu)這本書(shū)，今天想你一起嘮嗑嘮嗑架構(gòu)，你可能耳熟能詳?shù)母卟l(fā)、大流量、海量數(shù)據(jù)、分布式等等這些詞匯，但是每個(gè)詞匯背后其實(shí)都是為了解決當(dāng)前所出現(xiàn)的問(wèn)題所總結(jié)出的一套架構(gòu)范式，今天一起來(lái)扒一扒架構(gòu)。

讀完本文，能夠讓你理解單一應(yīng)用到大型應(yīng)用的架構(gòu)演進(jìn)歷程。

文本大綱

單一應(yīng)用服務(wù)階段

所有的大型網(wǎng)站都是由最小型的網(wǎng)站架構(gòu)演變而來(lái)的?；叵胍幌履阕铋_(kāi)始寫服務(wù)端代碼，是不是數(shù)據(jù)庫(kù)MySQL在本地，服務(wù)器也是本地，那最初階段也是這樣的，網(wǎng)站的流量也不大，通常就將應(yīng)用服務(wù)、數(shù)據(jù)服務(wù)、文件資源等所有資源都放在一臺(tái)服務(wù)器上，比如我們學(xué)java web的時(shí)候，都是利用Tom??等Web容器開(kāi)始運(yùn)行應(yīng)用服務(wù)程序，比如JSP，然后需要數(shù)據(jù)庫(kù)的時(shí)候用JDBC去連接本地Mysql Server。一圖勝千言：

應(yīng)用與數(shù)據(jù)服務(wù)分離階段

經(jīng)過(guò)業(yè)務(wù)發(fā)展迭代增加，用戶量、日活的上升，簡(jiǎn)單的一臺(tái)服務(wù)器就搞不定了。比如可能由于用戶產(chǎn)生的數(shù)據(jù)量過(guò)多導(dǎo)致存儲(chǔ)空間不夠，而一臺(tái)服務(wù)器同時(shí)得處理數(shù)據(jù)服務(wù)和用戶的應(yīng)用web響應(yīng)，CPU資源有限的情況下，是無(wú)法滿足用戶想要快速響應(yīng)需求的，網(wǎng)站的訪問(wèn)數(shù)據(jù)變得越來(lái)越慢，而數(shù)據(jù)服務(wù)和應(yīng)用服務(wù)所對(duì)計(jì)算機(jī)資源的需求是不一樣的，比如應(yīng)用服務(wù)器需要更多的CPU資源，給這臺(tái)服務(wù)器配上多幾核的CPU，數(shù)據(jù)服務(wù)可能需要與磁盤打交道，配備更多的閃存。

這時(shí)候就將應(yīng)用服務(wù)和數(shù)據(jù)服務(wù)進(jìn)行分離。將應(yīng)用服務(wù)器單獨(dú)出來(lái)，專注于響應(yīng)web請(qǐng)求，提高用戶的訪問(wèn)速度，將數(shù)據(jù)庫(kù)單獨(dú)放在一臺(tái)服務(wù)器，專注于處理與應(yīng)用服務(wù)器打過(guò)來(lái)的數(shù)據(jù)請(qǐng)求，將文件資源放在一臺(tái)服務(wù)器上，與應(yīng)用服務(wù)器打交道，為其提供文件服務(wù)，一圖勝千言：

利用緩存提高性能階段

隨著用戶的再增加，業(yè)務(wù)的再次升級(jí)。網(wǎng)站有面臨了一個(gè)數(shù)據(jù)庫(kù)服務(wù)的壓力太大而導(dǎo)致整體的訪問(wèn)效率下降，再次影響用戶的訪問(wèn)體驗(yàn)。

你可以想象，我們?nèi)粘５奈⒉?、抖音那些熱點(diǎn)數(shù)據(jù)，是幾個(gè)每個(gè)打開(kāi)這些應(yīng)用的人會(huì)請(qǐng)求到的。所以二八定律永遠(yuǎn)存在，80%的請(qǐng)求在20%的數(shù)據(jù)上。所以這個(gè)時(shí)候?qū)⑦@20%的數(shù)據(jù)進(jìn)行高校的緩存起來(lái)，這樣網(wǎng)站整體的性能又可以提升了。

緩存可以分為兩種：一種的直接緩存在應(yīng)用服務(wù)器上，另外是一種開(kāi)一臺(tái)緩存服務(wù)器進(jìn)行緩存。后者可以進(jìn)行很好的彈性伸縮，而前者會(huì)受到本地容量的限制。我們稱后者服務(wù)器為：分布式緩存服務(wù)器。

目前筆者寫的后端程序也在這個(gè)階段，也在嘗試往后續(xù)集群方向演進(jìn)。一圖勝千言：

應(yīng)用服務(wù)集群階段

當(dāng)使用緩存后，數(shù)據(jù)庫(kù)的訪問(wèn)壓力得到有效緩解。再次隨著業(yè)務(wù)的增加，單一應(yīng)用服務(wù)器能夠并發(fā)處理的請(qǐng)求連接有限，在流量的高峰期，應(yīng)用服務(wù)器開(kāi)始成為整個(gè)系統(tǒng)的性能瓶頸。

因此這個(gè)時(shí)候就開(kāi)始組件應(yīng)用服務(wù)器集群，不僅應(yīng)用服務(wù)器有集群，緩存服務(wù)器等也可以組成集群。那么既然有了服務(wù)器集群，那對(duì)于這些請(qǐng)求，到底應(yīng)該有哪臺(tái)服務(wù)器響應(yīng)呢。所以負(fù)載均衡調(diào)度服務(wù)器就出現(xiàn)了。

通過(guò)負(fù)載均衡調(diào)度服務(wù)器，可將來(lái)自瀏覽器的訪問(wèn)請(qǐng)求分發(fā)到應(yīng)用的集群中的任何一臺(tái)服務(wù)器上。使用服務(wù)器集群也有個(gè)好處，Web 應(yīng)用程序更新可以做到用戶無(wú)感知，當(dāng)有一個(gè)節(jié)點(diǎn)的服務(wù)器宕機(jī)之后，也不影響整體的請(qǐng)求。

一圖勝千言：

數(shù)據(jù)庫(kù)讀寫分離階段

雖然增加了數(shù)據(jù)緩存這一層。比如利用redis緩存，但是隨著用戶量的不斷增加?？傆幸恍┦菬o(wú)法通過(guò)緩存提高的，比如還可能出現(xiàn)緩存過(guò)期、緩存沒(méi)有命中等情況。那么這些請(qǐng)求全部會(huì)打到數(shù)據(jù)庫(kù)服務(wù)器上，這個(gè)時(shí)候數(shù)據(jù)庫(kù)服務(wù)成為了整個(gè)系統(tǒng)的瓶頸。所以數(shù)據(jù)讀寫分離就出現(xiàn)了。

目前大部分的數(shù)據(jù)庫(kù)都提供了一個(gè)主從熱備的功能。通過(guò)配置主從兩臺(tái)服務(wù)器，當(dāng)應(yīng)用服務(wù)器往主服務(wù)器寫入詩(shī)句時(shí)，利用主從復(fù)制機(jī)制將數(shù)據(jù)更新同步到從數(shù)據(jù)庫(kù)上。讀寫分離之后，數(shù)據(jù)庫(kù)的性能瓶頸就解決了。一圖勝千言：

反向代理與CDN加速階段

當(dāng)網(wǎng)站業(yè)務(wù)再次升級(jí)，用戶規(guī)模再次擴(kuò)大，為了滿足不同地區(qū)的用戶訪問(wèn)速度，提高響應(yīng)速度，CDN和反向代理就出現(xiàn)了，兩者基本原因都是緩存。

CDN就是內(nèi)容分發(fā)網(wǎng)絡(luò)，你的請(qǐng)求響應(yīng)服務(wù)器會(huì)從距離你最近的一個(gè)服務(wù)器集群上響應(yīng)回來(lái)，比如你在云南，可能就從云南的機(jī)房響應(yīng)。

而反向代理則部署在中心機(jī)房，當(dāng)請(qǐng)求來(lái)到中心機(jī)房后，首先訪問(wèn)的時(shí)候反向代理服務(wù)器，看看是否名字緩存，如果命中則直接返回。一圖勝千言：

分布式數(shù)據(jù)庫(kù)階段

分布式數(shù)據(jù)庫(kù)是系統(tǒng)數(shù)據(jù)庫(kù)拆分的最后手段，這只有在單表數(shù)據(jù)規(guī)模非常大的時(shí)候才會(huì)用，一般的數(shù)據(jù)庫(kù)拆分都是對(duì)業(yè)務(wù)拆分后將不同的業(yè)務(wù)數(shù)據(jù)部署在不同的服務(wù)器上。如下圖：

NoSQL與搜索引擎階段

當(dāng)成為大型系統(tǒng)的時(shí)候，搜索成為了日常需求，這時(shí)會(huì)采用NoSQL和搜索引擎來(lái)提高搜索效率，緩存的時(shí)候redis也是NoSQL類型的。如下圖：

業(yè)務(wù)拆分階段

當(dāng)業(yè)務(wù)日漸的增多，可能團(tuán)隊(duì)人員也不利于管理，這個(gè)時(shí)候大型的系統(tǒng)都會(huì)進(jìn)行業(yè)務(wù)拆分，比如抖音就拆了很多很多業(yè)務(wù)線。每條業(yè)務(wù)線服務(wù)不同的服務(wù)，每個(gè)服務(wù)都單獨(dú)進(jìn)行部署，可以通過(guò)消息隊(duì)列進(jìn)行數(shù)據(jù)分發(fā)。如下圖：

分布式服務(wù)階段

隨著業(yè)務(wù)拆分越來(lái)越小，存儲(chǔ)系統(tǒng)越來(lái)越龐大，應(yīng)用系統(tǒng)的整體復(fù)雜度呈指數(shù)級(jí)增加，部署維護(hù)越來(lái)越困難。

既然每一個(gè)應(yīng)用系統(tǒng)都需要執(zhí)行許多相同的業(yè)務(wù)操作，比如用戶管理、商品管理等，那么可以將這些共用的業(yè)務(wù)提取出來(lái)，獨(dú)立部署。由這些可復(fù)用的業(yè)務(wù)連接數(shù)據(jù)庫(kù)，提供共用業(yè)務(wù)服務(wù)，而應(yīng)用系統(tǒng)只需要管理用戶界面，通過(guò)分布式服務(wù)調(diào)用共用業(yè)務(wù)服務(wù)完成具體業(yè)務(wù)操作。如下圖：

總結(jié)

目前很少有人能經(jīng)歷上面的系統(tǒng)演進(jìn)，大部分大型的系統(tǒng)已經(jīng)成型，而小系統(tǒng)可能又很可能撐不到成為大系統(tǒng)，所以很少有人能經(jīng)歷這些，不過(guò)了解這些，我們對(duì)于整個(gè)系統(tǒng)架構(gòu)的理解非常有幫助。