1.1 http反向代理服務器

在web站點前端，我們需要搭建一個反向代理服務器，用于負責接受用戶的請求，請求包括動態(tài)和靜態(tài)的內容請求。一般反向代理服務器的部署方案有HAProxy和Nginx，這里將使用HAProxy來描述。

1.2 http代理服務器高可用

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

1.3 http代理服務器負載均衡

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

1.4 動態(tài)內容服務器

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

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

1.5 數(shù)據(jù)庫節(jié)點服務器

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

備注說明：

對于一個站點來講將，存儲有分為以下幾類

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

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

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

1.6 MySQL主從架構

如果我們查詢的請求比較多，一臺MySQL服務器將無法支撐這么龐大的查詢請求，那么此時為提高查詢能力，我們需要部署主從架構，實現(xiàn)一主多從模型

1.7 緩存服務器

我們了解到MySQL本身具有緩存功能，但由于前端應用服務器不止一臺，而MySQL也已部署成為一主多從架構，因為存在多個MySQL從節(jié)點，從而導致前端應用程序無法命中MySQL緩存的問題，那么此時就需要增加緩存服務器（例如：Memcache服務器）
如果我們只有一臺MySQL讀節(jié)點，那么只需使用MySQL本地的緩存即可，而無需額外增加緩存服務器。

使用MySQL主從架構添加緩存時，使用的是緩存模式中的“旁路”緩存模式（下面有介紹緩存的工作模式），而在此處緩存的內容主要是緩存MySQL的查詢對象，也就是MySQL對象查詢的緩存結果。

1.8 關于緩存工作模式介紹

緩存工作模式有兩種

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

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

1.8.1 代理（例如HAProxy，Nginx）

用戶向緩存服務器請求資源，如果緩存服務器發(fā)現(xiàn)本地并沒有對應緩存記錄，會由自己向后端服務器請求資源，將請求到的結果先緩存在本地，緩存完成之后再響應給用戶。

1.8.2 旁路（例如Memcache）

用戶首先向緩存服務器請求，如果緩存服務器未有緩存記錄會立即響應用戶。這時客戶端會自行去找后端服務器，那么后端服務器無論有無資源都會響應給客戶端。假設此時有對應緩存記錄，那么后端服務器會將結果返回給客戶端。客戶端會根據(jù)需要來判定是否這個數(shù)據(jù)緩存到緩存服務器中。所以數(shù)據(jù)緩不緩存并不取決于緩存服務器，而取決于請求方（也就是客戶端）

1.9 MySQL主從架構讀寫分離

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

• 1、前端應用程序配置

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

• 2、搭建讀寫分離服務器（例如：Amoeba服務器）

搭建讀寫分離服務器，告訴前端應用程序，無論是讀請求還是寫請求都發(fā)至讀寫分離服務器，由此服務器負責代理區(qū)分讀寫操并做好讀寫分離，轉發(fā)至各對應的主從節(jié)點上。

1.10 對存在多個從節(jié)點緩存情況

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

• 1、簡單的取模方式

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

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

• 2、一致性hash

這種算法很獨特，他不是對服務器節(jié)點數(shù)取模，而是把服務器每個節(jié)點都計算hash類似，對2^32取模，把每個服務器節(jié)點順時針分布在一個虛擬環(huán)上。然后當客戶端請求數(shù)據(jù)的時候，就會根據(jù)順時針的來去查找節(jié)點，如果真的有一個節(jié)點掛了，也只是影響那段區(qū)域的緩存數(shù)據(jù)。

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

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

1.11 主節(jié)點單點瓶頸

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

額外說明：除了上面介紹的方法，我們還可以有一個思路，就是做雙寫模型，就是在應用程序層面做設置，當收到寫操作時，將寫操作在兩個主節(jié)點都寫一份，而其他從節(jié)點只需要同步其中一臺主節(jié)點，當一個主節(jié)點故障后，立即將從節(jié)點同步到新的主節(jié)點上完成同步即可，但是這些設置都必須在前端應用程序層面上做操作，道理和上面介紹的一樣，這種方式對于以后系統(tǒng)架構擴展性不高，不建議使用這樣的方法，所以這里僅僅是給一個思路。

1.12 上傳文件存儲

在應用程序當中，我們需要存儲的可能不單單是結構化數(shù)據(jù)（也就是MySQL數(shù)據(jù)）。例如用戶通過應用程序上傳數(shù)據(jù)，而這些數(shù)據(jù)應該存儲在文件系統(tǒng)中，能夠提供文件系統(tǒng)的有類似NAS設備，如果用戶需要上傳數(shù)據(jù)，這個上傳請求就會給予http請求中的put方法上傳的數(shù)據(jù)保存在文件系統(tǒng)中，通過應用程序向文件系統(tǒng)發(fā)起數(shù)據(jù)請求，通過調用文件服務的API接口（或服務）來完成存儲。

1.13 用戶的讀請求

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

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

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

1.15 CDN技術

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

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

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

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

②    自動化運維工具

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

③    備份工具

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

1.17 總結

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

原創(chuàng)作者看過來：馬哥Linux原創(chuàng)作品征集

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

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

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