需求驅動驅動;而高可用與高性能，是架構設計中兩個非常重要的決策因素。因此，面對不同業務系統的不同需求，對高可用與高性能也會有不同的決策結論，其實現的複雜度也各不相同。支 付寶業務，對於可用性和性能就會有很高的要求，在可用性方面希望能提供7*24不間斷服務，在高性能方面則希望能實時收付款;而對於一個學生管理系統，在可用性與性能方面就不一定要有 多高的要求，比如晚上可關機，幾秒內能查詢到信息也可接受。為此，高可用性與高性能的複雜度討論需要結合業務需求。
1 WHAT - 什麼是可用性? 定義可用性，可以先定義什麼是不可用。需要經歷若干環節，網站的頁面才能呈現在最終的用戶面前;而其中的任何一個環節出現了故障，都可能會導致網站的頁面不可訪問，也就是出現了網 站不可用的情況。昨夜iOS版本QQ出現大面積閃退就是一個系統不可用的典型案例。
我們可以利用百分比來對網站可用性進行度量: 網站不可用時間=完成故障修復的時間點 - 故障發現的時間點 網站年度可用時間=年度總時間 - 網站不可用時間 網站年度可用性=(網站年度可用時間/年度總時間) x 100%
舉例:一些知名大型網站的可用性可達到99.99%(俗稱4個9)，我們可以算一下一年下來留給處理故障的時間有多少? 年度總時間=365*24*60=525600分鐘
網站不可用時間=525600*(1-99.99%)=52.56分鐘 也就是，如果網站要達到4個9的可用性，一年下來網站不可用時間最多53分鐘(也就是不足1個小時)。
可見，高可用性就是技術實力的象徵，高可用性就是競爭力。
2 WHY - 為什麼會出現不可用? 硬件故障。網站多運行在普通的商用服務器，而這些服務器本身就不具備高可用性，再加之網站系統背後有數量眾多服務器，那麼一定時間內服務器宕機是大概率事件，直接導致部署在該服務 器上的服務受影響。
軟件BUG或網站更新升級發佈。BUG不能消滅，只能減少;上線後的系統在運行過程中，難免會出現故障，而這些故障同樣直接導致某些網站服務不可用;此外，網站更新升級發佈也會引起相 對較頻繁的服務器宕機。
不可抗拒力。如地震、水災、戰爭等。
3 HOW - 如何做到高可用 核心思想:網站高可用的主要技術手段是服務與數據的冗餘備份與失效轉移。同一服務組件部署在多臺服務器上;數據存儲在多臺服務器上互相備份。通過上述技術手段，當任何一臺服務器宕 機或出現各種不可預期的問題時，就將相應的服務切換到其他可用的服務器上，不影響系統的整體可用性，也不會導致數據丟失。
從架構角度看可用性:當前網站系統多采用經典的分層模型，從上到下為:應用層、服務層與數據層。應用層主要實現業務邏輯處理;服務層提供可複用的服務;數據層負責數據讀寫;在部署
架構上常採用應用和數據分離部署，應用會部署到不同服務器上，這些服務器被稱為應用層的服務器;這些可複用的服務也會各自部署在不同服務器上，稱為服務層的服務器;而各類數據庫系
統、文件櫃等數據則部署在數據層的服務器。
硬件故障方面引起不可用的技術解決措施:(1)應用服務器。可通過負載均衡設備將多個應用服務器構建為集群對外提供服務(前提是這些服務需要設計為無狀態，即應用服務器不保存業務的上 下文信息，而僅根據每次請求提交的數據進行業務邏輯的操作響應)，當均衡設備通過心跳檢測手段檢測到應用服務器不可用時，則將其從集群中移除，並將請求切換到其他可用的應用服務 上。(2)服務層服務器。這些服務器被應用層通過分佈式服務框架(如Dubbo)訪問，分佈式服務框架可在應用層客戶端程序中實現軟件負載均衡，並通過服務註冊中心提供服務的服務器進行心 跳檢測，當發現有服務器不可用時，立即通知客戶端程序修改服務列表，同時移除響應的服務器。(3)數據服務器。需要在數據寫入時進行數據同步複製，將數據寫入多臺服務器上，實現數據冗 餘備份;當數據服務器宕機時，應用程序將訪問切換到有備份數據的服務器上。
軟件方面引起不可用的技術解決措施:通過軟件開發過程進行質量保證。通過預發佈驗證、嚴格測試、灰度發佈等手段，儘量減少上線服務的故障。
閱讀更多 愛分享de螢火蟲 的文章
