您現(xiàn)在的位置： 365建站網(wǎng) > 365文章 > 網(wǎng)站的高可用架構(gòu)之可用性度量與考核和應(yīng)用服務(wù)器集群Session管理

網(wǎng)站的高可用架構(gòu)之可用性度量與考核和應(yīng)用服務(wù)器集群Session管理

文章來源：365jz.com 點擊數(shù)：442 更新時間：2018-01-18 11:03 參與評論

網(wǎng)站的高可用架構(gòu)

2011年4月12日，亞馬遜云計算服務(wù)EC2（Elastic Computer
Cloud）發(fā)生故障，其ESB（Elastic Block Storage）服務(wù)不可用，故障持續(xù)了數(shù)天，最終還是有部分?jǐn)?shù)據(jù)未能恢復(fù)。這一故障導(dǎo)致美國許多使用亞馬遜云服務(wù)的知名網(wǎng)站（如：Foursquare，Quora）受到影響，并引發(fā)了人們對使用云計算安全性、可靠性的大規(guī)模討論。

2010年1月12日，百度被黑客攻擊，其DNS域名被劫持，導(dǎo)致百度全站長達數(shù)小時不可訪問。該事件一時成為新聞焦點，各種媒體爭相報道。

網(wǎng)站的可用性（Availability）描述網(wǎng)站可有效訪問的特性（不同于另一個網(wǎng)站運營指標(biāo)：Usability，通常也被譯作可用性，但是后者強調(diào)的是網(wǎng)站的有用性，即對最終用戶的使用價值），相比于網(wǎng)站的其他非功能特性，網(wǎng)站的可用性更牽動人們的神經(jīng)，大型網(wǎng)站的不可用事故直接影響公司形象和利益，許多互聯(lián)網(wǎng)公司都將網(wǎng)站可用性列入工程師的績效考核，與獎金升遷等利益掛鉤。

網(wǎng)站可用性的度量與考核

網(wǎng)站的頁面能完整呈現(xiàn)在最終用戶面前，需要經(jīng)過很多個環(huán)節(jié)，任何一個環(huán)節(jié)出了問題，都可能導(dǎo)致網(wǎng)站頁面不可訪問。DNS會被劫持、CDN服務(wù)可能會掛掉、網(wǎng)站服務(wù)器可能會宕機、網(wǎng)絡(luò)交換機可能會失效、硬盤會損壞、網(wǎng)卡會松掉、甚至機房會停電、空調(diào)會失靈、程序會有Bug、黑客會攻擊、促銷會引來大量訪問、第三方合作伙伴的服務(wù)會不可用……要保證一個網(wǎng)站永遠完全可用幾乎是一件不可能完成的使命。

網(wǎng)站可用性度量

網(wǎng)站不可用也被稱作網(wǎng)站故障，業(yè)界通常用多少個9來衡量網(wǎng)站的可用性，如QQ的可用性是4個9，即QQ服務(wù)99.99％可用，這意味著QQ服務(wù)要保證其在所有運行時間中，只有0.01％的時間不可用，也就是一年中大約最多53分鐘不可用。

網(wǎng)站不可用時間（故障時間）＝故障修復(fù)時間點網(wǎng)故障發(fā)現(xiàn)（報告）時間點網(wǎng)站年度可用性指標(biāo)＝（11網(wǎng)站不可用時間/年度總時間）年

100％對于大多數(shù)網(wǎng)站而言，2個9是基本可用，網(wǎng)站年度不可用時間小于88小時；3個9是較高可用，網(wǎng)站年度不可用時間小于9小時；4

個9是具有自動恢復(fù)能力的高可用，網(wǎng)站年度不可用時間小于53分鐘；

5個9是極高可用性，網(wǎng)站年度不可用時間小于5分鐘。

由于可用性影響因素很多，對于網(wǎng)站整體而言，達到4個9，乃至5個9的可用性，除了過硬的技術(shù)、大量的設(shè)備資金投入和工程師的責(zé)任心，還要有個好運氣。

常使用Twitter的用戶或多或少遇到過那個著名的服務(wù)不可用的鯨魚頁面，事實上，Twitter網(wǎng)站的可用性不足2個9。

網(wǎng)站可用性考核

可用性指標(biāo)是網(wǎng)站架構(gòu)設(shè)計的重要指標(biāo)，對外是服務(wù)承諾，對內(nèi)是考核指標(biāo)。從管理層面，可用性指標(biāo)是網(wǎng)站或者產(chǎn)品的整體考核指標(biāo)，具體到每個工程師的考核，更多的是使用故障分。

所謂故障分是指對網(wǎng)站故障進行分類加權(quán)計算故障責(zé)任的方法。

表5.1為某網(wǎng)站故障分類權(quán)重表。

表5.1 網(wǎng)站故障分類權(quán)重表示例

故障分的計算公式為：

故障分＝故障時間（分鐘）（故障權(quán)重在年初或者考核季度的開始，會根據(jù)網(wǎng)站產(chǎn)品的可用性指標(biāo)計算總的故障分，然后根據(jù)團隊和個人的職責(zé)角色分?jǐn)偣收戏郑@個可用性指標(biāo)和故障分是管理預(yù)期。在實際發(fā)生故障的時候，根據(jù)故障分類和責(zé)任劃分將故障產(chǎn)生的故障分分配給責(zé)任者承擔(dān)。等年末或者考核季度末的時候，個人及團隊實際承擔(dān)的故障分如果超過了年初分?jǐn)偟墓收戏?，績效考核就會受到影響?/span>

一個簡化的故障處理流程如圖5.1所示。

圖5.1 網(wǎng)站故障處理流程示例

有時候一個故障責(zé)任可能由多個部門或團隊來承擔(dān)，故障分也會相應(yīng)按責(zé)任分?jǐn)偟讲煌膱F隊和個人。

不同于其他架構(gòu)指標(biāo)，網(wǎng)站可用性更加看得見摸得著，跟技術(shù)、

運營、相關(guān)各方的績效考核息息相關(guān)，因此在架構(gòu)設(shè)計與評審會議上，關(guān)于系統(tǒng)可用性的討論與爭執(zhí)總是最花費時間與精力的部分。

當(dāng)然，不同的公司有不同的企業(yè)文化和市場策略，這些因素也會影響到系統(tǒng)可用性的架構(gòu)決策，崇尚創(chuàng)新和風(fēng)險的企業(yè)會對可用性要求稍低一些；業(yè)務(wù)快速增長的網(wǎng)站忙于應(yīng)對指數(shù)級增長的用戶，也會降低可用性的標(biāo)準(zhǔn)；服務(wù)于收費用戶的網(wǎng)站則會比服務(wù)于免費用戶的網(wǎng)站對可用性更加敏感，服務(wù)不可用或關(guān)鍵用戶數(shù)據(jù)丟失可能會導(dǎo)致收費用戶的投訴甚至引來官司。

高可用的網(wǎng)站架構(gòu)

通常企業(yè)級應(yīng)用系統(tǒng)為提高系統(tǒng)可用性，會采用較昂貴的軟硬件設(shè)備，如IBM的小型機乃至中型機大型機及專有操作系統(tǒng)、Oracle數(shù)據(jù)庫、EMC存儲設(shè)備等?；ヂ?lián)網(wǎng)公司更多地采用PC級服務(wù)器、開源的數(shù)據(jù)庫和操作系統(tǒng)，這些廉價的設(shè)備在節(jié)約成本的同時也降低了可用性，特別是服務(wù)器硬件設(shè)備，低價的商業(yè)級服務(wù)器一年宕機一次是一個大概率事件，而那些高強度頻繁讀寫的普通硬盤，損壞的概率則要更高一些。

既然硬件故障是常態(tài)，網(wǎng)站的高可用架構(gòu)設(shè)計的主要目的就是保證服務(wù)器硬件故障時服務(wù)依然可用、數(shù)據(jù)依然保存并能夠被訪問。

實現(xiàn)上述高可用架構(gòu)的主要手段是數(shù)據(jù)和服務(wù)的冗余備份及失效轉(zhuǎn)移，一旦某些服務(wù)器宕機，就將服務(wù)切換到其他可用的服務(wù)器上，如果磁盤損壞，則從備份的磁盤讀取數(shù)據(jù)。

一個典型的網(wǎng)站設(shè)計通常遵循如圖5.2所示的基本分層架構(gòu)模型。

圖5.2 網(wǎng)站架構(gòu)基本分層模型

典型的分層模型是三層，即應(yīng)用層、服務(wù)層、數(shù)據(jù)層；各層之間具有相對獨立性，應(yīng)用層主要負(fù)責(zé)具體業(yè)務(wù)邏輯處理；服務(wù)層負(fù)責(zé)提供可復(fù)用的服務(wù)；數(shù)據(jù)層負(fù)責(zé)數(shù)據(jù)的存儲與訪問。中小型網(wǎng)站在具體部署時，通常將應(yīng)用層和服務(wù)層部署在一起，而數(shù)據(jù)層則另外部署，如圖5.3所示（事實上，這也是網(wǎng)站架構(gòu)演化的第一步）。

圖5.3 應(yīng)用和數(shù)據(jù)分離部署的網(wǎng)站架構(gòu)

在復(fù)雜的大型網(wǎng)站架構(gòu)中，劃分的粒度會更小、更詳細，結(jié)構(gòu)更加復(fù)雜，服務(wù)器規(guī)模更加龐大，但通常還是能夠把這些服務(wù)器劃分到這三層中。如圖5.4所示。

不同的業(yè)務(wù)產(chǎn)品會部署在不同的服務(wù)器集群上，如某網(wǎng)站的文庫、貼吧、百科等屬于不同的產(chǎn)品，部署在各自獨立的服務(wù)器集群上，互不相干。這些產(chǎn)品又會依賴一些共同的復(fù)用業(yè)務(wù)，如注冊登錄服務(wù)、

Session管理服務(wù)、賬戶管理服務(wù)等，這些可復(fù)用的業(yè)務(wù)服務(wù)也各自部署在獨立的服務(wù)器集群上。至于數(shù)據(jù)層，數(shù)據(jù)庫服務(wù)、文件服務(wù)、緩存服務(wù)、搜索服務(wù)等數(shù)據(jù)存儲與訪問服務(wù)都部署在各自獨立的服務(wù)器集群上。

大型網(wǎng)站的分層架構(gòu)及物理服務(wù)器的分布式部署使得位于不同層次的服務(wù)器具有不同的可用性特點。關(guān)閉服務(wù)或者服務(wù)器宕機時產(chǎn)生的影響也不相同，高可用的解決方案也差異甚大。

位于應(yīng)用層的服務(wù)器通常為了應(yīng)對高并發(fā)的訪問請求，會通過負(fù)載均衡設(shè)備將一組服務(wù)器組成一個集群共同對外提供服務(wù)，當(dāng)負(fù)載均衡設(shè)備通過心跳檢測等手段監(jiān)控到某臺應(yīng)用服務(wù)器不可用時，就將其從集群列表中剔除，并將請求分發(fā)到集群中其他可用的服務(wù)器上，使整個集群保持可用，從而實現(xiàn)應(yīng)用高可用。

位于服務(wù)層的服務(wù)器情況和應(yīng)用層的服務(wù)器類似，也是通過集群方式實現(xiàn)高可用，只是這些服務(wù)器被應(yīng)用層通過分布式服務(wù)調(diào)用框架訪問，分布式服務(wù)調(diào)用框架會在應(yīng)用層客戶端程序中實現(xiàn)軟件負(fù)載均衡，并通過服務(wù)注冊中心對提供服務(wù)的服務(wù)器進行心跳檢測，發(fā)現(xiàn)有服務(wù)不可用，立即通知客戶端程序修改服務(wù)訪問列表，剔除不可用的服務(wù)器。

位于數(shù)據(jù)層的服務(wù)器情況比較特殊，數(shù)據(jù)服務(wù)器上存儲著數(shù)據(jù)，為了保證服務(wù)器宕機時數(shù)據(jù)不丟失，數(shù)據(jù)訪問服務(wù)不中斷，需要在數(shù)據(jù)寫入時進行數(shù)據(jù)同步復(fù)制，將數(shù)據(jù)寫入多臺服務(wù)器上，實現(xiàn)數(shù)據(jù)冗余備份。當(dāng)數(shù)據(jù)服務(wù)器宕機時，應(yīng)用程序?qū)⒃L問切換到有備份數(shù)據(jù)的服務(wù)器上。

網(wǎng)站升級的頻率一般都非常高，大型網(wǎng)站一周發(fā)布一次，中小型網(wǎng)站一天發(fā)布幾次。每次網(wǎng)站發(fā)布都需要關(guān)閉服務(wù)，重新部署系統(tǒng)，整個過程相當(dāng)于服務(wù)器宕機。因此網(wǎng)站的可用性架構(gòu)設(shè)計不但要考慮實際的硬件故障引起的宕機，還要考慮網(wǎng)站升級發(fā)布引起的宕機，而后者更加頻繁，不能因為系統(tǒng)可以接受偶爾的停機故障就降低可用性設(shè)計的標(biāo)準(zhǔn)。

5.3 高可用的應(yīng)用

應(yīng)用層主要處理網(wǎng)站應(yīng)用的業(yè)務(wù)邏輯，因此有時也稱作業(yè)務(wù)邏輯層，應(yīng)用的一個顯著特點是應(yīng)用的無狀態(tài)性。

所謂無狀態(tài)的應(yīng)用是指應(yīng)用服務(wù)器不保存業(yè)務(wù)的上下文信息，而僅根據(jù)每次請求提交的數(shù)據(jù)進行相應(yīng)的業(yè)務(wù)邏輯處理，多個服務(wù)實例（服務(wù)器）之間完全對等，請求提交到任意服務(wù)器，處理結(jié)果都是完全一樣的。

5.3.1 通過負(fù)載均衡進行無狀態(tài)服務(wù)的失效轉(zhuǎn)移

不保存狀態(tài)的應(yīng)用給高可用的架構(gòu)設(shè)計帶來了巨大便利，既然服務(wù)器不保存請求的狀態(tài)，那么所有的服務(wù)器完全對等，當(dāng)任意一臺或多臺服務(wù)器宕機，請求提交給集群中其他任意一臺可用機器處理，這樣對終端用戶而言，請求總是能夠成功的，整個系統(tǒng)依然可用。對于應(yīng)用服務(wù)器集群，實現(xiàn)這種服務(wù)器可用狀態(tài)實時監(jiān)測、自動轉(zhuǎn)移失敗任務(wù)的機制是負(fù)載均衡。

負(fù)載均衡，顧名思義，主要使用在業(yè)務(wù)量和數(shù)據(jù)量較高的情況下，當(dāng)單臺服務(wù)器不足以承擔(dān)所有的負(fù)載壓力時，通過負(fù)載均衡手段，將流量和數(shù)據(jù)分?jǐn)偟揭粋€集群組成的多臺服務(wù)器上，以提高整體的負(fù)載處理能力。目前，不管是開源免費的負(fù)載均衡軟件還是昂貴的負(fù)載均衡硬件，都提供失效轉(zhuǎn)移功能。在網(wǎng)站應(yīng)用中，當(dāng)集群中的服務(wù)是無狀態(tài)對等時，負(fù)載均衡可以起到事實上高可用的作用，如圖5.5所示。

圖5.5 利用負(fù)載均衡服務(wù)器實現(xiàn)高可用的應(yīng)用服務(wù)

當(dāng)Web服務(wù)器集群中的服務(wù)器都可用時，負(fù)載均衡服務(wù)器會把用戶發(fā)送的訪問請求分發(fā)到任意一臺服務(wù)器上進行處理，而當(dāng)服務(wù)器

10.0.0.1宕機時，負(fù)載均衡服務(wù)器通過心跳檢測機制發(fā)現(xiàn)該服務(wù)器失去響應(yīng)，就會把它從服務(wù)器列表中刪除，而將請求發(fā)送到其他服務(wù)器上，這些服務(wù)器是完全一樣的，請求在任何一臺服務(wù)器中處理都不會影響最終的結(jié)果。

由于負(fù)載均衡在應(yīng)用層實際上起到了系統(tǒng)高可用的作用，因此即使某個應(yīng)用訪問量非常少，只用一臺服務(wù)器提供服務(wù)就綽綽有余，但如果需要保證該服務(wù)高可用，也必須至少部署兩臺服務(wù)器，使用負(fù)載均衡技術(shù)構(gòu)建一個小型的集群。

5.3.2 應(yīng)用服務(wù)器集群的Session管理

應(yīng)用服務(wù)器的高可用架構(gòu)設(shè)計主要基于服務(wù)無狀態(tài)這一特性，但是事實上，業(yè)務(wù)總是有狀態(tài)的，在交易類的電子商務(wù)網(wǎng)站，需要有購物車記錄用戶的購買信息，用戶每次購買請求都是向購物車中增加商品；在社交類的網(wǎng)站中，需要記錄用戶的當(dāng)前登錄狀態(tài)、最新發(fā)布的消息及好友狀態(tài)等，用戶每次刷新頁面都需要更新這些信息。

Web應(yīng)用中將這些多次請求修改使用的上下文對象稱作會話（Session），單機情況下，Session可由部署在服務(wù)器上的Web容器（如JBoss）管理。在使用負(fù)載均衡的集群環(huán)境中，由于負(fù)載均衡服務(wù)器可能會將請求分發(fā)到集群任何一臺應(yīng)用服務(wù)器上，所以保證每次請求依然能夠獲得正確的Session比單機時要復(fù)雜很多。

集群環(huán)境下，Session管理主要有以下幾種手段。

1．Session復(fù)制

Session復(fù)制是早期企業(yè)應(yīng)用系統(tǒng)使用較多的一種服務(wù)器集群

Session管理機制。應(yīng)用服務(wù)器開啟Web容器的Session復(fù)制功能，在集群中的幾臺服務(wù)器之間同步Session對象，使得每臺服務(wù)器上都保存所有用戶的Session信息，這樣任何一臺機器宕機都不會導(dǎo)致

Session數(shù)據(jù)的丟失，而服務(wù)器使用Session時，也只需要在本機獲取即可。如圖5.6所示。

這種方案雖然簡單，從本機讀取Session信息也很快速，但只能使用在集群規(guī)模比較小的情況下。當(dāng)集群規(guī)模較大時，集群服務(wù)器間需要大量的通信進行Session復(fù)制，占用服務(wù)器和網(wǎng)絡(luò)的大量資源，系統(tǒng)不堪負(fù)擔(dān)。而且由于所有用戶的Session信息在每臺服務(wù)器上都有備份，在大量用戶訪問的情況下，甚至?xí)霈F(xiàn)服務(wù)器內(nèi)存不夠Session使用的情況。

而大型網(wǎng)站的核心應(yīng)用集群就是數(shù)千臺服務(wù)器，同時在線用戶可達千萬，因此并不適用這種方案。

2．Session綁定

Session綁定可以利用負(fù)載均衡的源地址Hash算法實現(xiàn)，負(fù)載均衡服務(wù)器總是將來源于同一IP的請求分發(fā)到同一臺服務(wù)器上（也可以根據(jù)Cookie信息將同一個用戶的請求總是分發(fā)到同一臺服務(wù)器上，當(dāng)然這時負(fù)載均衡服務(wù)器必須工作在HTTP協(xié)議層上，關(guān)于負(fù)載均衡算法的更多信息請參考本書第6章內(nèi)容。這樣在整個會話期間，用戶所有的請求都在同一臺服務(wù)器上處理，即Session綁定在某臺特定服務(wù)器上，保證Session總能在這臺服務(wù)器上獲取。這種方法又被稱作會話黏滯，如圖5.7所示。

圖5.7 利用負(fù)載均衡的會話黏滯機制將請求綁定到特定服務(wù)器

但是Session綁定的方案顯然不符合我們對系統(tǒng)高可用的需求，因為一旦某臺服務(wù)器宕機，那么該機器上的Session也就不復(fù)存在了，

用戶請求切換到其他機器后因為沒有Session而無法完成業(yè)務(wù)處理。

因此雖然大部分負(fù)載均衡服務(wù)器都提供源地址負(fù)載均衡算法，但很少有網(wǎng)站利用這個算法進行Session管理。

3．利用Cookie記錄Session

早期的企業(yè)應(yīng)用系統(tǒng)使用C/S（客戶端/服務(wù)器）架構(gòu)，一種管理

Session 的方式是將Session記錄在客戶端，每次請求服務(wù)器的時候，將Session放在請求中發(fā)送給服務(wù)器，服務(wù)器處理完請求后再將修改過的Session響應(yīng)給客戶端。

網(wǎng)站沒有客戶端，但是可以利用瀏覽器支持的Cookie記錄

Session，如圖5.8所示。

圖5.8 利用Cookie記錄Session信息

利用Cookie記錄Session也有一些缺點，比如受Cookie大小限制，能記錄的信息有限；每次請求響應(yīng)都需要傳輸Cookie，影響性能；如果用戶關(guān)閉Cookie，訪問就會不正常。但是由于Cookie的簡單易用，可用性高，支持應(yīng)用服務(wù)器的線性伸縮，而大部分應(yīng)用需要記錄的

Session信息又比較小。因此事實上，許多網(wǎng)站都或多或少地使用Cookie記錄Session。

4．Session服務(wù)器

那么有沒有可用性高、伸縮性好、性能也不錯，對信息大小又沒有限制的服務(wù)器集群Session管理方案呢？答案就是Session服務(wù)器。利用獨立部署的Session服務(wù)器（集群）統(tǒng)一管理Session，應(yīng)用服務(wù)器每次讀寫Session時，都訪問Session服務(wù)器，如圖5.9所示。