**Availability**：描述網站可有效訪問的特性(不同于另一個網站運營指標，`Usability`通常也被譯作可用性。后者強調的是網站的有用性，即對最終用戶的使用價值)。 相比于網站的其他非功能特性，網站的可用性更牽動人們的神經，大型網站的不可用事故直接影響公司形象和利益，許多互聯網公司都將網站可用性列入工程師的績效考核，與獎金升遷等利益掛鉤。 * 對公司而言，可用性關系網站的生死存亡。 * 對個人而言，可用性關系到自己的績效升遷。 工程師對架構做了許多優化、 對代碼做了很多重構, 對性能、 擴展性、 伸縮性做了很多改善，但別人未必能直觀地感受到，也許你的直接領導都不知道你做的這些意義何在。 但如果你負責的產品出了重大故障，CEO 都會知道你的名字。 事物總是先求生存，然后求發展。保證網站可用，萬無一失，任重而道遠。 [TOC] ## 2.1 高可用性架構 ### 2.1.1 企業級應用系統 為提高系統可用性，會采用較昂貴的軟硬件設備，如 * IBM的小型機乃至中型機大型機及專有操作系統 * Oracle 數據庫 * EMC 存儲設備等。 ### 2.1.2 互聯網公司 更多地采用 * PC級服務器 * 開源的數據庫 * 開源的操作系統 上述廉價的設備在節約成本的同時也降低了可用性。 特別是服務器硬件設備，低價的商業級服務器一年宕機一次是一個大概率事件，而那些高強度頻繁讀寫的普通硬盤，損壞的概率則要更高一些。 既然硬件故障是常態，網站的高可用架構設計的主要目的就是保證服務器硬件故障時服務依然可用、 數據依然保存并能夠被訪問。 實現上述高可用架構的主要手段是**數據和服務的*冗余備份*及*失效轉移***。一旦某些服務器宕機，就將服務切換到其他可用的服務器上，如果磁盤損壞，則從備份的磁盤讀取數據。 典型的網站架構通常遵循三層分層模型： * 應用層：負責具體的業務邏輯； * 服務層：負責提供可復用的服務； * 數據層：負責數據的存儲于訪問。 中小型網站在具體部署時，通常把應用層和服務層部署在一起，數據層則另外部署。 復雜的大型網站，則在各層中有更細的劃分粒度，更大的服務器規模。  :-: 分層按模塊分割的網站架構模型 大型網站的分層架構及物理服務器的分布式部署使得位于不同層次的服務器具有不同的可用性特點。 關閉服 務或者服務器宕機時產生的影響也不相同，高可用的解決方案也差異甚大。 1. **應用層服務器** 通常為了應對高并發的訪問請求，通過集群方式實現高可用 - 通過*負載均衡設備*將一組服務器組成一個*集群*共同對外提供服務； - 負載均衡設備通過*心跳檢測*等手段監控到某臺應用服務器不可用時，就將其從集群列表中剔除，并將請求分發到集群中其他可用的服務器上；保持整個集群保持可用。 2. **服務層服務器** 也是通過集群方式實現高可用。這些服務器被應用層通過*分布式服務調用框架*訪問，分布式服務調用框架 - 會在應用層客戶端程序中實現軟件負載均衡； - 通過服務注冊中心對提供服務的服務器進行心跳檢測, 發現有服務不可用, 立即通知客戶端程序修改服務訪問列表,剔除不可用的服務器。 3. **數據層服務器** 位于數搌層的服務器情況比較特殊，數據服務器上存儲著數據，為了保證服務器宕機時數據不丟失，數據訪問服務不中斷，需要 - 在數據寫入時進行數據同步復制，將數據寫入多臺服務器上，實現數據冗余備份。 - 當數據服務器宕機時，應用程序將訪問切換到有備份數據的服務器上。 ### 2.1.3 網站升級 網站升級的頻率一般都非常高，大型網站一周發布一次，中小型網站一天發布幾次。 每次網站發布都需要關閉服務，重新部署系統，整個過程相當于服務器宕機。 因此網站的可用性架構設計不但要考慮實際的硬件故障引起的宕機，還要考慮網站升級發布引起的宕機，而后者更加頻繁，不能因為系統可以接受偶爾的停機故障就降低可用性設計的標準。 ## 2.2 高可用的應用 應用層主要處理網站應用的業務邏輯，也稱為業務邏輯層。要實現高可用性，主要基于應用的無狀態性來實現。 ### 2.2.1 通過負載均衡進行無狀態服務的失效轉移  :-: 利用負載均衡服務器實現高可用的應用服務 **無狀態的應用**：是指應用服務器不保存業務的上下文信息，而僅根據每次請求提交的數據進行相應的業務邏輯處理，多個服務實例 (服務器) 之間完全對等，請求提交到任意的服務器，處理的結果都一樣。 無狀態的應用的好處： * 對于終端用戶，其請求總是能被系統成功處理。 * 對于應用服務器集群，通過負載均衡來實現服務器可用狀態實時監測、自動轉移失敗任務。 **負載均衡**： 主要使用在業務量和數據量較高的情況下，當單臺服務器不足以承擔所有的負載壓力時，通過負載均衡手段，將流量和數據分攤到一個集群組成的多臺服務器上，以提高整體的負載處理能力。 目前，不管是開源免費的負載均衡軟件還是昂貴的負載均衡硬件，都提供失效轉移功能。 在網站應用中，當集群中的服務是無狀態對等時，負載均衡可以起到事實上高可用的作用，如上圖所示。 ### 2.2.2 應用服務器集群的SESSION管理 但業務總是有狀態的。 交易類的電子商務網站，需要有購物車記錄用戶的購買信息，用戶每次購買請求都是向購物車中增加商品； 社交類的網站，需要記錄用戶的當前登錄狀態、最新發布的消息及好友狀態等，用戶每次刷新頁面都需要更新這些信息。 Web應用中將這些多次請求修改使用的上下文對象稱作`會話（SESSION）`。 單機情況，`SESSION`可由部署在服務器上的Web容器（`JBoss`）管理； 負載均衡的集群中，由于負載均衡服務器會把請求發到集群的任意一臺應用服務器上，所以保證每次請求依然能獲取正確的`SESSION`要比單機復雜很多。主要的方法有： 1. SESSION復制 Session復制是早期企業應用系統使用較多的一種服務器集群Session管理機制。 具體為： 應用服務器開啟Web 容器的Session 復制功能，在集群中的幾臺服務器之間同步 Session 對象，使得每臺服務器上都保存所有用戶的 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  :-: 利用Cookie記錄SESSION * 優點 Cookie 的簡單易用，可用性高，支持應用服務器的線性伸縮，而大部分應用需要記錄的 Session 信息又比較小。 * 缺點 Cookie有大小限制，能記錄的信息有限；每次請求響應都需要傳輸 Cookie，影響性能；如果用戶關閉 Cookie，訪問就會不正常。 事實上, 許多網站都或多或少地使用 Cookie記錄 Session. 4. 使用SESSION服務器 利用獨立部署的Session服務器(集群)統一管理Session，應用服務器每次讀寫 Session時，都訪問 Session服務器，如下圖所示。  :-: 利用SESSION服務器共享SESSION 這種解決方案事實上是將應用服務器的狀態分離，分為無狀態的應用服務器和有狀態的Session服務器，然后針對這兩種服務器的不同特性分別設計其架構。 有狀態的Session服務器 * 一種比較簡單的方法：是利用分布式緩存，數據庫等，在這些產品的基礎上進行包裝，使其符合 Session 的存儲和訪問要求。 * 專門的Session 服務管理平臺：應對業務場景對Session 管理有比較高的要求，比如利用 Session 服務集成單點登錄(SSO)、用戶服務等功能。 ## 2.3 高可用的服務 ## 2.4 高可用的數據 ## 2.5 高可用網站的軟件質量 ### 2.5.1 網站發布 ### 2.5.2 自動化測試 ### 2.5.3 預發布驗證 ### 2.5.4 代碼控制 ### 2.5.5 自動化發布 ### 2.5.6 灰度發布 ## 2.1 監控數據 ### 2.1.1 用戶行為日志 用戶行為日志：指用戶在瀏覽器上所做的所有操作及其所在的操作環境。包括用戶的 * 操作系統版本信息 * 瀏覽器版本信息 * IP地址 * 頁面訪問路徑 * 頁面停留時間等 這些數據對統計網站PV/UV指標、分析用戶行為、優化網站設計、個性化營銷與推薦等非常重要。 具體用戶行為日志收集手段有兩種： * 服務器端日志收集。 Apache等幾乎所有Web服務器都具備日志記錄功能，可以記錄大部分用戶行為日志，開啟 Web 服務器的日志記錄功能即可。 其缺點是可能會出現信息失真，如IP地址是代理服務器地址而不是用戶真實IP，無法識別訪問路徑等。 * 客戶端瀏覽器日志收集。 利用頁面嵌入專門的 JavaScript 腳本可以收集用戶真實的操作行為,因此比服務器日志收集更加精準。其缺點是比較麻煩,需要在頁面嵌入特定的JavaScript腳本來完成。 ### 2.1.2 服務器性能 網站的運維人員可以在初始化系統時進行統一的部署，對服務器性能指標數據進行收集。主要的指標有： * 系統Load * 內存占用 * 磁盤I/O * 網絡I/O等 盡早做出故障預警，及時判斷應用狀況，防患于未然，將故障扼殺在萌芽時期非常重要。 此外根據性能監控數據 * 運維工程師，可以合理安排服務器集群規模。 * 架構師，及時改善系統性能及調整系統伸縮性策略。 ### 2.1.3 運行數據報告 與具體業務場景相關的技術和業務指標，例如 * 緩存命中率 * 平均響應延遲時間 * 每分鐘發送郵件數目 * 待處理任務總數 上述的運行數據需要在具體的應用程序中采集并報告，匯總后統一顯示，需要應用程序在代碼中處理運行數據采集的邏輯。 ## 2.2 監控管理 監控數據采集后，除了用作系統性能評估、集群規模伸縮性預測等，還可以根據實時監控數據進行風險預警， 并對服務器進行失效轉移，自動負載調整，最大化利用集群所有機器的資源。 ### 2.2.1 系統報警 監控管理系統配置報警閾值和值守人員的聯系方式，報警方式除了郵件，即時通信工具，還可以配置手機短信，語音報警。 相關人員接到報警后需要及時采取措施，在故障還未發生時就消除隱患防患于未然。 ### 2.2.2 失效轉移 除了應用程序訪問失敗時進行失效轉移，監控系統還可以在發現故障的情況下主動通知應用，進行失效轉移。 ### 2.2.3 自動優雅降級 優雅降級是指網站為了應付突然爆發的訪問高峰，主動關閉部分功能，釋放部分系統資源，保證網站核心功能正常訪問的一個手段。 例如：淘寶每年一次的 “雙十一” 促銷活動主動關閉“評價”、“確認收貨”等非核心功能，以保證交易功能的正常進行，就可以看作是一種優雅降級。 網站在監控管理基礎之上實現自動優雅降級，是網站柔性架構的理想狀態：監控系統實時監控所有服務器的運行狀況, 根據監控參數判斷應用訪問負載情況 * 如果發現部分應用負載過高，而部分應用負載過低，就會適當卸載低負載應用部分服務器，重新安裝啟動部分高負載應用，使應用負載總體均衡； * 如果所有應用負載都很高，而且負載壓力還在繼續增加，就會自動關閉部分非重要功能，保證核心功能正常運行. ## 2.3 監控工具 ### 2.3.1 實時日志統計與分析——`Storm` 大型網站的用戶日志數據量驚人，數據存儲與計算壓力很大，目前許多網站逐步開發基于實時計算框架`Storm`的日志統計與分析工具。 ### 2.3.2 實時性能監控——`Ganglia` 開源性能監控工具是`Ganglia`，它支持大規模服務器集群，并支持以圖形的方式在瀏覽器展示實時性能曲線。 ## 2.2 優化方法