1.1 http反向代理服務(wù)器

在web站點(diǎn)前端，我們需要搭建一個(gè)反向代理服務(wù)器，用于負(fù)責(zé)接受用戶的請(qǐng)求，請(qǐng)求包括動(dòng)態(tài)和靜態(tài)的內(nèi)容請(qǐng)求。一般反向代理服務(wù)器的部署方案有HAProxy和Nginx，這里將使用HAProxy來(lái)描述。

1.2 http代理服務(wù)器高可用

為了提高系統(tǒng)安全及高可用性，我們需要在前端的http反向代理服務(wù)器配置高可用，解決方案有HAProxy+Keepalived。

1.3 http代理服務(wù)器負(fù)載均衡

雖然我們有兩個(gè)節(jié)點(diǎn)的HAProxy，但是一般只有有一臺(tái)HAProxy可為用戶提供服務(wù)，而另外一臺(tái)將會(huì)空閑，這樣會(huì)造成資源浪費(fèi)，為了提高資源最大化，我們需要為HAProxy做負(fù)載均衡。操作方法就是在DNS上配置兩條A記錄，這樣就能實(shí)現(xiàn)將用戶請(qǐng)求通過(guò)DNS分發(fā)給兩個(gè)不同的節(jié)點(diǎn)，而每個(gè)節(jié)點(diǎn)都通過(guò)相同的方式向后端服務(wù)器發(fā)起調(diào)度。

1.4 動(dòng)態(tài)內(nèi)容服務(wù)器

如果我們打算部署一個(gè)動(dòng)態(tài)內(nèi)容，而且主站也是使用應(yīng)用程序來(lái)實(shí)現(xiàn)，那我們需要部署一套動(dòng)態(tài)內(nèi)容網(wǎng)站（例如LAMP），那么對(duì)其我們也需要對(duì)其考慮高可用性以及負(fù)載均衡以及高可用的問(wèn)題。那么當(dāng)用戶訪問(wèn)主頁(yè)，例如index.jsp，index.php等動(dòng)態(tài)網(wǎng)頁(yè)時(shí)，此時(shí)就應(yīng)該由動(dòng)態(tài)服務(wù)器基于響應(yīng)。

小知識(shí)：用戶在訪問(wèn)站點(diǎn)時(shí)，只是請(qǐng)求一個(gè)資源（主頁(yè)資源），而這個(gè)主頁(yè)資源包含了很多資源，有大多數(shù)都是靜態(tài)內(nèi)容，這些內(nèi)容都是位于當(dāng)前站點(diǎn)上或者是其他站點(diǎn)上一些靜態(tài)資源，比如圖片，CSS等。而這些信息需要被單獨(dú)的資源再次請(qǐng)求。所以打開(kāi)一個(gè)站點(diǎn)，訪問(wèn)主頁(yè)的那一刻，只是第一次請(qǐng)求的入口，后續(xù)他會(huì)在同一個(gè)站點(diǎn)或者是同一個(gè)站點(diǎn)的鏈接所指向的位置發(fā)起多次請(qǐng)求。

1.5 數(shù)據(jù)庫(kù)節(jié)點(diǎn)服務(wù)器

對(duì)于動(dòng)態(tài)內(nèi)容來(lái)講，如果其訪問(wèn)的是一個(gè)主頁(yè)，而這個(gè)主頁(yè)又包含一些動(dòng)態(tài)內(nèi)容，比如包含某些查詢，那么此時(shí)就需要查詢數(shù)據(jù)庫(kù)，所以我們還需要部署數(shù)據(jù)庫(kù)節(jié)點(diǎn)（常見(jiàn)的數(shù)據(jù)庫(kù)系統(tǒng)有MySQL、Mariadb、Oracle等）

備注說(shuō)明：

對(duì)于一個(gè)站點(diǎn)來(lái)講將，存儲(chǔ)有分為以下幾類

• 1、關(guān)系型數(shù)據(jù)，需要存儲(chǔ)在類似MySQL這種關(guān)系型數(shù)據(jù)庫(kù)中

• 2、文件數(shù)據(jù)，存儲(chǔ)在文件系統(tǒng)中

• 3、鍵值數(shù)據(jù)，一般存儲(chǔ)在緩存服務(wù)器中，或者類似NoSQL非關(guān)系型數(shù)據(jù)庫(kù)中

1.6 MySQL主從架構(gòu)

如果我們查詢的請(qǐng)求比較多，一臺(tái)MySQL服務(wù)器將無(wú)法支撐這么龐大的查詢請(qǐng)求，那么此時(shí)為提高查詢能力，我們需要部署主從架構(gòu)，實(shí)現(xiàn)一主多從模型

1.7 緩存服務(wù)器

我們了解到MySQL本身具有緩存功能，但由于前端應(yīng)用服務(wù)器不止一臺(tái)，而MySQL也已部署成為一主多從架構(gòu)，因?yàn)榇嬖诙鄠€(gè)MySQL從節(jié)點(diǎn)，從而導(dǎo)致前端應(yīng)用程序無(wú)法命中MySQL緩存的問(wèn)題，那么此時(shí)就需要增加緩存服務(wù)器（例如：Memcache服務(wù)器）
如果我們只有一臺(tái)MySQL讀節(jié)點(diǎn)，那么只需使用MySQL本地的緩存即可，而無(wú)需額外增加緩存服務(wù)器。

使用MySQL主從架構(gòu)添加緩存時(shí)，使用的是緩存模式中的“旁路”緩存模式（下面有介紹緩存的工作模式），而在此處緩存的內(nèi)容主要是緩存MySQL的查詢對(duì)象，也就是MySQL對(duì)象查詢的緩存結(jié)果。

1.8 關(guān)于緩存工作模式介紹

緩存工作模式有兩種

• 1、基于代理模式的工作

• 2、基于旁路的工作模式

1.8.1 代理（例如HAProxy，Nginx）

用戶向緩存服務(wù)器請(qǐng)求資源，如果緩存服務(wù)器發(fā)現(xiàn)本地并沒(méi)有對(duì)應(yīng)緩存記錄，會(huì)由自己向后端服務(wù)器請(qǐng)求資源，將請(qǐng)求到的結(jié)果先緩存在本地，緩存完成之后再響應(yīng)給用戶。

1.8.2 旁路（例如Memcache）

用戶首先向緩存服務(wù)器請(qǐng)求，如果緩存服務(wù)器未有緩存記錄會(huì)立即響應(yīng)用戶。這時(shí)客戶端會(huì)自行去找后端服務(wù)器，那么后端服務(wù)器無(wú)論有無(wú)資源都會(huì)響應(yīng)給客戶端。假設(shè)此時(shí)有對(duì)應(yīng)緩存記錄，那么后端服務(wù)器會(huì)將結(jié)果返回給客戶端?？蛻舳藭?huì)根據(jù)需要來(lái)判定是否這個(gè)數(shù)據(jù)緩存到緩存服務(wù)器中。所以數(shù)據(jù)緩不緩存并不取決于緩存服務(wù)器，而取決于請(qǐng)求方（也就是客戶端）

1.9 MySQL主從架構(gòu)讀寫(xiě)分離

由于MySQL已經(jīng)部署成為主從架構(gòu)，那么又衍生另一個(gè)問(wèn)題，如果用戶請(qǐng)求發(fā)送到MySQL服務(wù)器，應(yīng)如何區(qū)分讀和寫(xiě)的請(qǐng)求，應(yīng)使用哪個(gè)節(jié)點(diǎn)去響應(yīng)客戶端請(qǐng)求呢？此時(shí)我們需要解決讀寫(xiě)分離的問(wèn)題。這里給出兩種方法供大家參考：

• 1、前端應(yīng)用程序配置

在前端應(yīng)用程序做設(shè)定來(lái)做讀寫(xiě)分離，設(shè)定寫(xiě)操作發(fā)送到主節(jié)點(diǎn)，讀操作發(fā)至各從節(jié)點(diǎn)上。但是這樣會(huì)存在一個(gè)問(wèn)題，如今互聯(lián)網(wǎng)發(fā)展速度之快，我們很有可能為了滿足業(yè)務(wù)擴(kuò)展需求，會(huì)改變架構(gòu)規(guī)劃調(diào)整，此時(shí)就需要在前端應(yīng)用程序端進(jìn)行代碼修改，而且這樣要求前端應(yīng)用程序開(kāi)發(fā)工程師的技術(shù)水平，對(duì)于系統(tǒng)的擴(kuò)展性不高，所以一般也不建議使用這樣地方。

• 2、搭建讀寫(xiě)分離服務(wù)器（例如：Amoeba服務(wù)器）

搭建讀寫(xiě)分離服務(wù)器，告訴前端應(yīng)用程序，無(wú)論是讀請(qǐng)求還是寫(xiě)請(qǐng)求都發(fā)至讀寫(xiě)分離服務(wù)器，由此服務(wù)器負(fù)責(zé)代理區(qū)分讀寫(xiě)操并做好讀寫(xiě)分離，轉(zhuǎn)發(fā)至各對(duì)應(yīng)的主從節(jié)點(diǎn)上。

1.10 對(duì)存在多個(gè)從節(jié)點(diǎn)緩存情況

如果架構(gòu)中存在多個(gè)從節(jié)點(diǎn)（讀節(jié)點(diǎn)），我們需要做好讀節(jié)點(diǎn)的負(fù)載均衡。雖然多從節(jié)點(diǎn)能分?jǐn)傋x操作壓力，但同時(shí)也降低了緩存命中的幾率，我們前面說(shuō)明MySQL的前端Memcache是使用旁路的工作模式進(jìn)行緩存的，雖可以做到部分緩存，但是當(dāng)Memcache沒(méi)有對(duì)應(yīng)緩存條目的時(shí)候，應(yīng)用程序會(huì)向后端的MySQL查詢，MySQL自身也有緩存功能，但是由于存在對(duì)個(gè)從節(jié)點(diǎn)，而每個(gè)從節(jié)點(diǎn)之間做了負(fù)載均衡，所以應(yīng)用程序可能查詢同一條數(shù)據(jù)的時(shí)候無(wú)法定位到同一個(gè)MySQL從節(jié)點(diǎn)，這樣就很難緩存命中，從而造成MySQL從節(jié)點(diǎn)的資源浪費(fèi)，為了提高M(jìn)ySQL本地緩存可以得到有力的應(yīng)用，進(jìn)一步提到緩存的命中，那么一般有下面兩種的模式

• 1、簡(jiǎn)單的取模方式

前端應(yīng)用在向后端發(fā)起數(shù)據(jù)請(qǐng)求時(shí)，某個(gè)語(yǔ)句如果發(fā)往同一個(gè)節(jié)點(diǎn)，那么他就始終發(fā)往同一個(gè)節(jié)點(diǎn)。所以可以根據(jù)語(yǔ)句做均衡，以后只要是這個(gè)語(yǔ)句，就會(huì)發(fā)送到這個(gè)節(jié)點(diǎn)上（做法：使用取語(yǔ)法就行了，每個(gè)語(yǔ)句在在向后段發(fā)起請(qǐng)求時(shí)。只需要在應(yīng)用程序中，對(duì)這個(gè)查詢語(yǔ)句做hash計(jì)算，取得他的校驗(yàn)碼，對(duì)服務(wù)器的個(gè)數(shù)做取模計(jì)算。所以某語(yǔ)句特征碼一樣，那么他的取模計(jì)算也是一樣的。因此同一條語(yǔ)句將會(huì)始終發(fā)往同一個(gè)服務(wù)器。）

這種方案存在問(wèn)題：萬(wàn)一某個(gè)節(jié)點(diǎn)掛了，那么你剩下的將會(huì)需要重新取模，那么程序可能被調(diào)整。而且有可能導(dǎo)致之前的緩存全部失效了。所以這種方案并不理想

• 2、一致性hash

這種算法很獨(dú)特，他不是對(duì)服務(wù)器節(jié)點(diǎn)數(shù)取模，而是把服務(wù)器每個(gè)節(jié)點(diǎn)都計(jì)算hash類似，對(duì)2^32取模，把每個(gè)服務(wù)器節(jié)點(diǎn)順時(shí)針?lè)植荚谝粋€(gè)虛擬環(huán)上。然后當(dāng)客戶端請(qǐng)求數(shù)據(jù)的時(shí)候，就會(huì)根據(jù)順時(shí)針的來(lái)去查找節(jié)點(diǎn)，如果真的有一個(gè)節(jié)點(diǎn)掛了，也只是影響那段區(qū)域的緩存數(shù)據(jù)。

但是這個(gè)有可能導(dǎo)致不均衡，但是這個(gè)是在所難免的。但是我們可以使用虛擬節(jié)點(diǎn)機(jī)制，這樣節(jié)點(diǎn)就能分布到不同區(qū)域下，每個(gè)虛擬節(jié)點(diǎn)都是單獨(dú)計(jì)算的，所以他們落的地方就不同，這樣就容易均衡。

當(dāng)做好MySQL從節(jié)點(diǎn)之間的緩存取模配對(duì)，當(dāng)用戶請(qǐng)求時(shí)會(huì)先去查詢Memcache中的緩存，有緩存命中則會(huì)立即返回，如果未命中，客戶端會(huì)向后端從節(jié)點(diǎn)發(fā)起查詢請(qǐng)求，此時(shí)從節(jié)點(diǎn)會(huì)查詢自身本地的緩存記錄，如有有命中，將記錄返回給客戶端，若沒(méi)有命中緩存，則會(huì)查看查詢數(shù)據(jù)庫(kù)表中的數(shù)據(jù)信息。

1.11 主節(jié)點(diǎn)單點(diǎn)瓶頸

在主從模型中，寫(xiě)節(jié)點(diǎn)成為了整個(gè)架構(gòu)單點(diǎn)故障所在，那么我們需要做到MySQL的部署成雙主模型，來(lái)實(shí)現(xiàn)主節(jié)點(diǎn)的高可用。這種解決方案有： MySQL+Proxy，MySQL-MMM, DRBD等技術(shù)，建議使用MySQL-MMM技術(shù)。

額外說(shuō)明：除了上面介紹的方法，我們還可以有一個(gè)思路，就是做雙寫(xiě)模型，就是在應(yīng)用程序?qū)用孀鲈O(shè)置，當(dāng)收到寫(xiě)操作時(shí)，將寫(xiě)操作在兩個(gè)主節(jié)點(diǎn)都寫(xiě)一份，而其他從節(jié)點(diǎn)只需要同步其中一臺(tái)主節(jié)點(diǎn)，當(dāng)一個(gè)主節(jié)點(diǎn)故障后，立即將從節(jié)點(diǎn)同步到新的主節(jié)點(diǎn)上完成同步即可，但是這些設(shè)置都必須在前端應(yīng)用程序?qū)用嫔献霾僮?，道理和上面介紹的一樣，這種方式對(duì)于以后系統(tǒng)架構(gòu)擴(kuò)展性不高，不建議使用這樣的方法，所以這里僅僅是給一個(gè)思路。

1.12 上傳文件存儲(chǔ)

在應(yīng)用程序當(dāng)中，我們需要存儲(chǔ)的可能不單單是結(jié)構(gòu)化數(shù)據(jù)（也就是MySQL數(shù)據(jù)）。例如用戶通過(guò)應(yīng)用程序上傳數(shù)據(jù)，而這些數(shù)據(jù)應(yīng)該存儲(chǔ)在文件系統(tǒng)中，能夠提供文件系統(tǒng)的有類似NAS設(shè)備，如果用戶需要上傳數(shù)據(jù)，這個(gè)上傳請(qǐng)求就會(huì)給予http請(qǐng)求中的put方法上傳的數(shù)據(jù)保存在文件系統(tǒng)中，通過(guò)應(yīng)用程序向文件系統(tǒng)發(fā)起數(shù)據(jù)請(qǐng)求，通過(guò)調(diào)用文件服務(wù)的API接口（或服務(wù)）來(lái)完成存儲(chǔ)。

1.13 用戶的讀請(qǐng)求

如果用戶的操作是讀請(qǐng)求的話，此時(shí)我們應(yīng)該做到動(dòng)態(tài)與靜態(tài)服務(wù)器的分離，通過(guò)HAProxy來(lái)完成動(dòng)靜分離，此前我們已經(jīng)有動(dòng)態(tài)應(yīng)用服務(wù)器，那么此處我們需要構(gòu)建靜態(tài)服務(wù)器（一般會(huì)使用Nginx來(lái)構(gòu)建靜態(tài)服務(wù)器）并且我們需要對(duì)靜態(tài)服務(wù)器配置高可用，那么可用的方案有 Nginx + Keepalived。使用HAProxy來(lái)完成動(dòng)態(tài)內(nèi)容和靜態(tài)內(nèi)容分離，通過(guò)靜態(tài)內(nèi)容服務(wù)器所請(qǐng)求的內(nèi)容一般都是文件系統(tǒng)里的內(nèi)容，靜態(tài)內(nèi)容服務(wù)器會(huì)向后端的文件系統(tǒng)拿到用戶請(qǐng)求的內(nèi)容后，會(huì)構(gòu)建成http響應(yīng)報(bào)文，然后響應(yīng)給HAProxy，然后HAProxy再次構(gòu)建響應(yīng)報(bào)文發(fā)回給用戶

1.14 靜態(tài)內(nèi)容緩存

考慮到文件檢索的速率，那么對(duì)于靜態(tài)服內(nèi)容也需要構(gòu)建緩存，雖然我們可以使用動(dòng)態(tài)部分的Memcache緩存服務(wù)器的，但是對(duì)于文件靜態(tài)內(nèi)容緩存，使用Varnish或Squid相比之下更有優(yōu)勢(shì)，其中Varnish可以直接響應(yīng)HAProxy請(qǐng)求，當(dāng)Varnish沒(méi)有數(shù)據(jù)時(shí)，會(huì)去趙Nginx，Nginx會(huì)從后端檢索數(shù)據(jù)，然后返回給Varnish，Varnish會(huì)將檢索到的數(shù)據(jù)緩存下來(lái)，然后在響應(yīng)給HAProxy，最后構(gòu)建http響應(yīng)報(bào)文返回給客戶端。當(dāng)然，Nginx本身也存在本地緩存功能，所以可以開(kāi)啟Nginx本地的緩存功能，所以如果Varnish向Nginx發(fā)來(lái)請(qǐng)求時(shí)，Nginx會(huì)先查詢Nginx本地自己的緩存，如果命中將直接返回給Varnish，否者會(huì)向后端服務(wù)器檢索數(shù)據(jù)。

1.15 CDN技術(shù)

對(duì)于中型的web站點(diǎn)，上面架構(gòu)還是足以應(yīng)付業(yè)務(wù)的需要，但是如果對(duì)于類似淘寶，京東等這一類大型的網(wǎng)購(gòu)站點(diǎn)還不不夠，而且還需要注意，對(duì)于一些網(wǎng)購(gòu)站點(diǎn)，訪問(wèn)高峰時(shí)間段，甚至出現(xiàn)搶購(gòu)這類活動(dòng)，業(yè)務(wù)流量將成數(shù)倍的增長(zhǎng)，所以現(xiàn)在的架構(gòu)是無(wú)法滿足需要，考慮到這些大型的web站點(diǎn)，我們需要借助于CDN機(jī)制，CDN（Content Delivery Network）內(nèi)容分發(fā)網(wǎng)絡(luò)，簡(jiǎn)單理解是各地搭建緩存服務(wù)器，將這些緩存服務(wù)器分布到用戶訪問(wèn)相對(duì)密集的區(qū)域或網(wǎng)絡(luò)中，利用全局負(fù)載均衡技術(shù)（GSLB），將用戶訪問(wèn)的距離指向最近的緩存服務(wù)器中，然后由緩存服務(wù)器直接響應(yīng)用戶請(qǐng)求，而且各地緩存服務(wù)器還能之間相互進(jìn)行查找，直到CDN的緩存服務(wù)器上都沒(méi)有記錄，那么就會(huì)向web站點(diǎn)主服務(wù)器去查詢資源，我們知道熱點(diǎn)的關(guān)系，其實(shí)用戶訪問(wèn)的將近20%數(shù)據(jù)（估測(cè)）都是經(jīng)常被訪問(wèn)的數(shù)據(jù)，所以使用CDN技術(shù)能大大的降低主服務(wù)器的查詢請(qǐng)求，而且加快用戶的訪問(wèn)速度已經(jīng)用戶體驗(yàn)，在選擇CDN方面，我們應(yīng)該選擇至少2個(gè)以上的CDN服務(wù)提供商，目的也是為了提供線路的可用性。

1.16 監(jiān)控系統(tǒng)、自動(dòng)化運(yùn)維、備份等工具

雖然我們?yōu)槊總€(gè)節(jié)點(diǎn)都部署高可用，但是隨著業(yè)務(wù)的不斷增長(zhǎng)，傳統(tǒng)型的服務(wù)器運(yùn)維工作已經(jīng)無(wú)法適應(yīng)業(yè)務(wù)需求。為了提高業(yè)務(wù)的穩(wěn)定性、運(yùn)維人員工作效率等，我們還需要在部署監(jiān)控系統(tǒng)、自動(dòng)化運(yùn)維工作、備份等工具
① 監(jiān)控系統(tǒng)

在各節(jié)點(diǎn)中部署監(jiān)控客戶端，監(jiān)控各節(jié)點(diǎn)的性能指標(biāo)、服務(wù)狀態(tài)、硬件狀態(tài)，實(shí)時(shí)的將監(jiān)控?cái)?shù)據(jù)發(fā)送到監(jiān)控服務(wù)器端，若出現(xiàn)數(shù)據(jù)異?；蛘吖?jié)點(diǎn)故障，監(jiān)控服務(wù)器會(huì)立即通知運(yùn)維人員，這樣就能在業(yè)務(wù)未中斷的條件下預(yù)先知道業(yè)務(wù)中存在威脅，從而立即響應(yīng)處理故障，保證業(yè)務(wù)正常穩(wěn)定的運(yùn)行。
常用的監(jiān)控系統(tǒng)開(kāi)源解決方案：Nagios、Zabbix

②    自動(dòng)化運(yùn)維工具

隨著業(yè)務(wù)不斷增長(zhǎng)，所需的服務(wù)器節(jié)點(diǎn)設(shè)備不斷增多，運(yùn)維人員不可能在一步步重新部署操作系統(tǒng)。而且當(dāng)業(yè)務(wù)需要發(fā)布更新，我們需要將所有的更新腳本文件分發(fā)至各對(duì)應(yīng)節(jié)點(diǎn)，并同步執(zhí)行更新，而這些操作簡(jiǎn)單卻繁瑣，僅僅重復(fù)相同操作。類似這種情況，我們需要部署自動(dòng)化運(yùn)維工具，將這些操作通過(guò)自動(dòng)化運(yùn)維工具部署完成，從而增加運(yùn)維人員的工作效率。
常見(jiàn)的自動(dòng)化運(yùn)維工具開(kāi)源解決方案：Ansible、Puppet、Cobbler

③    備份工具

數(shù)據(jù)對(duì)于企業(yè)而言是十分重要，雖然現(xiàn)在存儲(chǔ)技術(shù)可以使用RAID技術(shù)來(lái)保障數(shù)據(jù)的安全性，由于可能不可控因素，或者是系統(tǒng)出現(xiàn)操作失誤或系統(tǒng)故障導(dǎo)致數(shù)據(jù)丟失，將有可能導(dǎo)致不可預(yù)估的損失。而這就是備份的重要性，所以保證數(shù)據(jù)的安全性，也防范于未然。
常見(jiàn)的備份工具開(kāi)源解決方案：Bacula

1.17 總結(jié)

本文主要介紹了從一個(gè)基本的Web站點(diǎn)部署所需組件，到根據(jù)業(yè)務(wù)需要一步步不斷的擴(kuò)展完善整個(gè)Web站點(diǎn)的架構(gòu)，這篇文章在學(xué)習(xí)中總結(jié)匯總，由于本人能力有限，其中有些地方寫(xiě)的不足還有待完善，如果您有好的建議，歡迎您的指教。謝謝。

原創(chuàng)作者看過(guò)來(lái)：馬哥Linux原創(chuàng)作品征集

如果你有好的原創(chuàng)文章
如果你想增加自己的影響力
如果你想造福更多的小伙伴
那就給馬哥Linux運(yùn)維公眾號(hào)投稿吧！

你的運(yùn)維經(jīng)驗(yàn)、運(yùn)維感悟、運(yùn)維心得、運(yùn)維策略、運(yùn)維技能、運(yùn)維遇到的坑、學(xué)習(xí)心得等等，都可以給我們投稿！

一經(jīng)采用，除了特別的獎(jiǎng)勵(lì)外，還能增加自己的知名度哦~快來(lái)投稿吧！