一、網站的高可用架構

      2011年4月12曰，亞馬遜計算服務EC2 ( Elastic Computer Cloud )發生故障，其 ESB( Elastic Block Storage)服務不可用，故障持續了數天，最終還是有部分資料未能恢復。這一故障導致美國許多使用亞馬遜石服務的知名網站（如：Foursquare，Quora)受 到影響，並引發了人們對使用雲端計算安全性、可靠性的大規模討論。

• EC2 ( Elastic Computer Cloud ) :彈性計算機雲
• ESB( Elastic Block Storage):彈性塊儲存

      2010年1月12日，百度被黑客攻擊，其DNS域名被劫持

      網站的可用性（Availability )描述網站可有效訪問的特性（不同於另一個網站運營指標：Usability,通常也被譯作可用性，但是後者強調的是網站的有用性，即對終端使用者的 使用價值），相比於網站的其他非功能特性，網站的可用性更牽動人們的神經，大型網站 的不可用事故直接影響公司形象和利益，許多網際網路公司都將網站可用性列入工程師的 績效考核，與獎金升遷等利益掛鉤。

1.1、網站可用性的度量與考核

      網站的頁面能完整呈現在終端使用者面前，需要經過很多個環節，任何一個環節出了 問題，都可能導致網站頁面不可訪問。DNS會被劫持、CDN服務可能會掛掉、網站服務 器可能會宕機、網路交換機可能會失效、硬碟會損壞、網絡卡會鬆掉、甚至機房會停電、 空調會失靈、程式會有Bug、黑客會攻擊

1.1.1、網站可用性度量

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

      網站不可用時間（故障時間）=故障修復時間點-故障發現（報告）時間點

      網站年度可用性指標=(1-網站不可用時間/年度總時間）x 100%

      對於大多數網站而目，2個9是基本可用，網站年度不可用時間小於88小時；3個9 是較高可用，網站年度不可用時間小於9小時；4個9是具有自動恢復能力的高可用，網 站年度不可用時間小於53分鐘；5個9是極高可用性，網站年度不可用時間小於5分鐘。

      由於可用性影響因素很多，對於網站整體而言，達到4個9,乃至5個9的可用性， 除了過硬的技術、大量的裝置資金投入和工程師的責任心，還要有個好運氣。

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

1.1.2、網站可用性考核

      可用性指標是網站架構設計的重要指標，對外是服務承諾，對內是考核指標。從管 理層面，可用性指標是網站或者產品的整體考核指標，具體到每個工程師的考核，更多 的是使用故障分。

      所謂故障分是指對網站故障進行分類加權計算故障責任的方法。

      在年初或者考核季度的開始，會根據網站產品的可用性指標計算總的故障分，然後根據團隊和個人的職責角色分攤故障分，這個可用性指標和故障分是管理預期。在實際發生故障的時候，根據故障分類和責任劃分將故障產生的故障分分配給責任者承擔。等年末或者考核季度末的時候，個人及團隊實際承擔的故障分如果超過了年初分攤的故障分，績效考核就會受到影響。

      有時候一個故障責任可能由多個部門或團隊來承擔，故障分也會相應按責任分攤到 不同的團隊和個人。

      不同於其他架構指標，網站可用性更加看得見摸得著，跟技術、運營、相關各方的 績效考核息息相關，因此在架構設計與評審會議上，關於系統可用性的討論與爭執總是 最花費時間與精力的部分。

      當然，不同的公司有不同的企業文化和市場策略，這些因素也會影響到系統可用性 的架構決策，崇尚創新和風險的企業會對可用性要求稍低一些；業務快速增長的網站忙 於應對指數級增長的使用者，也會降低可用性的標準；服務於收費使用者的網站則會比服務 於免費使用者的網站對可用性更加敏感，服務不可用或關鍵使用者資料丟失可能會導致收費 使用者的投訴甚至引來官司。

1.2、網站的高可用架構

      通常企業級應用系統為提高系統可用性，會採用較昂貴的軟硬體裝置，如IBM的小 型機乃至中型機大型機及專有作業系統、Oracle資料庫、EMC儲存裝置等。網際網路公司 更多地採用PC級伺服器、開源的資料庫和作業系統，這些廉價的裝置在節約成本的同時 也降低了可用性，特別是伺服器硬體裝置，低價的商業級伺服器一年宕機一次是一個大 概率事件，而那些高強度頻繁讀寫的普通硬碟，損壞的概率則要更高一些。

      既然硬體故障是常態，網站的高可用架構設計的主要目的就是保證伺服器硬體故障 時服務依然可用、資料依然儲存並能夠被訪問。

      實現上述高可用架構的主要手段是資料和服務的冗餘備份及失效轉移，一旦某些服 務器宕機，就將服務切換到其他可用的伺服器上，如果磁碟損壞，則從備份的磁碟讀取 資料。
一個典型的網站設計通常遵循如圖：

      典型的分層模型是三層，即應用層、服務層、資料層；各層之間具有相對獨立性， 應用層主要負責具體業務邏輯處理；服務層負責提供可複用的服務；資料層負責資料的 儲存與訪問。中小型網站在具體部署時，通常將應用層和服務層部署在一起，而資料層 則另外部署

      在複雜的大型網站架構中，劃分的粒度會更小、更詳細，結構更加複雜，伺服器規 模更加龐大，但通常還是能夠把這些伺服器劃分到這三層中

      不同的業務產品會部署在不同的伺服器叢集上，如某網站的文庫、貼吧、百科等屬 於不同的產品，部署在各自獨立的伺服器叢集上，互不相干。這些產品又會依賴一些共 同的複用業務，如註冊登入服務、Session管理服務、賬戶管理服務等，這些可複用的業 務服務也各自部署在獨立的伺服器叢集上。至於資料層，資料庫服務、檔案服務、快取 服務、搜尋服務等資料儲存與訪問服務都部署在各自獨立的伺服器叢集上。

      大型網站的分層架構及物理伺服器的分散式部署使得位於不同層次的服務 器具有不同的可用性特點。關閉服務或者伺服器巖機時產生的影響也不相同， 尚可用的解決方案也差異甚大。

      位於應用層的伺服器通常為了應對高併發的訪問請求，會通過負載均衡裝置將一組 伺服器組成一個叢集共同對外提供服務，當負載均衡裝置通過心跳檢測等手段監控到某 臺應用伺服器不可用時，就將其從叢集列表中剔除，並將請求分發到叢集中其他可用的 伺服器上，使整個叢集保持可用，從而實現應用高可用。

      位於服務層的伺服器情況和應用層的伺服器類似，也是通過叢集方式實現高可用， 只是這些伺服器被應用層通過分散式服務呼叫框架訪問，分散式服務呼叫框架會在應用 層客戶端程式中實現軟體負載均衡，並通過服務註冊中心對提供服務的伺服器進行心跳檢 測，發現有服務不可用，立即通知客戶端程式修改服務訪問列表，剔除不可用的伺服器。

      位於資料層的伺服器情況比較特殊，資料伺服器上儲存著資料，為了保證伺服器宕 機時資料不丟失，資料訪問服務不中斷，需要在資料寫入時進行資料同步複製，將資料 寫入多臺伺服器上，實現資料冗餘備份。當資料伺服器宕機時，應用程式將訪問切換到 有備份資料的伺服器上。

      網站升級的頻率一般都非常高，大型網站一週釋出一次，中小型網站一天釋出幾次。 每次網站釋出都需要關閉服務，重新部署系統，整個過程相當於伺服器宕機。因此網站 的可用性架構設計不但要考慮實際的硬體故障引起的宕機，還要考慮網站升級釋出引起 的宕機，而後者更加頻繁，不能因為系統可以接受偶爾的停機故障就降低可用性設計的標準。

1.3、高可用的應用

      應用層主要處理網站應用的業務邏輯，因此有時也稱作業務邏輯層，應用的一個顯 著特點是應用的無狀態性。

      所謂無狀態的應用是指應用伺服器不儲存業務的上下文資訊，而僅根據每次請求提 交的資料進行相應的業務邏輯處理，多個服務例項（伺服器）之間完全對等，請求提交

1.3.1、通過負載均衡進行無狀態服務的失效轉移

      不儲存狀態的應用給高可用的架構設計帶來了巨大便利，既然伺服器不儲存請求的 狀態，那麼所有的伺服器完全對等，當任意一臺或多臺伺服器宕機，請求提交給叢集中 其他任意一臺可用機器處理，這樣對終端使用者而言，請求總是能夠成功的，整個系統依 然可用。對於應用伺服器叢集，實現這種伺服器可用狀態實時監測、自動轉移失敗任務 的機制是負載均衡。

      負載均衡，顧名思義，主要使用在業務量和資料量較高的情況下，當單臺伺服器不 足以承擔所有的負載壓力時，通過負載均衡手段，將流量和資料分攤到一個叢集組成的 多臺伺服器上，以提高整體的負載處理能力。目前，不管是幵源免費的負載均衡軟體還 是昂貴的負載均衡硬體，都提供失效轉移功能。在網站應用中，當叢集中的服務是無狀 態對等時，負載均衡可以起到事實上高可用的作用

      當Web伺服器叢集中的伺服器都可用時，負載均衡伺服器會把使用者傳送的訪問請求 分發到任意一臺伺服器上進行處理，而當伺服器10.0.0.1宕機時，負載均衡伺服器通過心 跳檢測機制發現該伺服器失去響應，就會把它從伺服器列表中刪除，而將請求傳送到其 他伺服器上，這些伺服器是完全一樣的，請求在任何一臺伺服器中處理都不會影響最終 的結果。

      由於負載均衡在應用層實際上起到了系統高可用的作用，因此即使某個應用訪問量 非常少，只用一臺伺服器提供服務就綽綽有餘，但如果需要保證該服務高可用，也必須 至少部署兩臺伺服器，使用負載均衡技術構建一個小型的叢集。

1.3.2、應用伺服器叢集的Session管理

      應用伺服器的高可用架構設計主要基於服務無狀態這一特性，但是事實上，業務總 是有狀態的，在交易類的電子商務網站，需要有購物車記錄使用者的購買資訊，使用者每次 購買請求都是向購物車中增加商品；在社交類的網站中，需要記錄使用者的當前登入狀態、 最新發布的訊息及好友狀態等，使用者每次重新整理頁面都需要更新這些資訊。

      Web應用中將這些多次請求修改使用的上下文物件稱作會話（Session )，單機情況下， Session可由部署在伺服器上的Web容器（如JBoss )管理。在使用負載均衡的叢集環境 中，由於負載均衡伺服器可能會將請求分發到叢集任何一臺應用伺服器上，所以保證每次請求依然能夠獲得正確的Session比單機時要複雜很多。

      叢集環境下，Session管理主要有以下幾種手段。

1、Session複製

      Session複製是早期企業應用系統使用較多的一種伺服器叢集Session管理機制。應用 伺服器開啟Web容器的Session複製功能，在叢集中的幾臺伺服器之間同步Session物件， 使得每臺伺服器上都儲存所有使用者的Session資訊，這樣任何一臺機器宕機都不會導致 Session資料的丟失，而伺服器使用Session時，也只需要在本機獲取即可。

      這種方案雖然簡單，從本機讀取Session資訊也很快速，但只能使用在叢集規模比較 小的情況下。當叢集規模較大時，叢集伺服器間需要大量的通訊進行Session複製，佔用 伺服器和網路的大量資源，系統不堪負擔。而且由於所有使用者的Session資訊在每臺服務 器上都有備份，在大量使用者訪問的情況下，甚至會出現伺服器記憶體不夠Session使用的情況。

2、Session繫結

      Session繫結可以利用負載均衡的源地址Hash演算法實現，負載均衡伺服器總是將來源 於同一 IP的請求分發到同一臺伺服器上（也可以根據Cookie資訊將同一個使用者的請求總 是分發到同一臺伺服器上，當然這時負載均衡伺服器必須工作在HTTP協議層上這樣在整個會話期間，使用者所有的請 求都在同一臺伺服器上處理，即Session繫結在某臺特定伺服器上，保證Session總能在 這臺伺服器上獲取。這種方法又被稱作會話黏滯

      但是Session繫結的方案顯然不符合我們對系統高可用的需求，因為一旦某臺伺服器 宕機，那麼該機器上的Session也就不復存在了，使用者請求切換到其他機器後因為沒有 Session而無法完成業務處理。因此雖然大部分負載均衡伺服器都提供源地址負載均衡算 法，但很少有網站利用這個演算法進行Session管理。

3、利用Cookie記錄Session

      早期的企業應用系統使用C/S (客戶端/伺服器）架構，一種管理Session的方式是將 Session記錄在客戶端，每次請求伺服器的時候，將Session放在請求中傳送給伺服器，服 務器處理完請求後再將修改過的Session響應給客戶端。

      網站沒有客戶端，但是可以利用瀏覽器支援的Cookie記錄Session

      利用Cookie記錄Session也有一些缺點，比如受Cookie大小限制，能記錄的資訊有 限；每次請求響應都需要傳輸Cookie，影響效能；如果使用者關閉Cookie，訪問就會不正 常。但是由於Cookie的簡單易用，可用性高，支援應用伺服器的線性伸縮，而大部分應 用需要記錄的Session資訊又比較小。因此事實上，許多網站都或多或少地使用Cookie 記錄 Session

4、Session伺服器

      那麼有沒有可用性高、伸縮性好、效能也不錯，對資訊大小又沒有限制的伺服器叢集Session管理方案呢？

      答案就是Session伺服器。利用獨立部署的Session伺服器（叢集）統一管理Session， 應用伺服器每次讀寫Session時，都訪問Session伺服器，如圖

      這種解決方案事實上是將應用伺服器的狀態分離，分為無狀態的應用伺服器和有狀 態的Session伺服器，然後針對這兩種伺服器的不同特性分別設計其架構。

      對於有狀態的Session伺服器，一種比較簡單的方法是利用分散式快取、資料庫等， 在這些產品的基礎上進行包裝，使其符合Session的儲存和訪問要求。如果業務場景對 Session管理有比較高的要求，比如利用Session服務整合單點登入（SSO )、使用者服務等 功能，則需要開發專門的Session服務管理平臺。

宣告：以上內容來自：《大型網站技術架構：核心原理與案例分析書籍》
下一章：網站的高可用架構（下）