論文
2017屆
軟件體系架構質量屬性之可用性
姓 名：劉晨
學 號：20173672
院 系：信息科學與技術學院
專 業：軟件工程
指導教師：王建民
聯系方式：15614157932
軟件體系架構質量屬性之可用性
劉晨 石家庄鐵道大學 河北省石家庄市 050043
摘 要
本文講述了有關軟件質量屬性六大指標中的可用性，通過針對淘寶網工作流程的舉例和亞馬遜雲計算服務進行簡單的闡述，分析可用性在網站方面的重要性，其主要包含網站可用性的度量與考核，可用性的應用，保障數據的可用性三個方面。
關鍵詞 可用性，應用，數據
Availability of Software Architecture Quality Attributes
(LiuChen, ShiJiaZhuang TieDao University,Shijiazhuang, Hebei province,050043)
Abstract
This paper describes the usability of the six major indicators of software quality attributes. Through a simple exposition of Taobao workflow and Amazon cloud computing service, it analyzes the importance of usability in websites, which mainly includes the measurement and assessment of website usability, the application of usability and the guarantee of data usability.
KEY WORDS availability applicable data
前言
由於本學期開展了軟件體系架構課程，學習了有關軟件質量體系的六大屬性的內容，應老師要求，從而進一步對可用性的深入了解，也為了以后的工作過程中更加清晰。可用性分析所關注的方面包括：如何檢測系統故障，系統故障發生的頻度，出現故障時會發生什么情況，允許系統有多長時間非正常運行，什么時候可以安全地出現故障，如何防止故障的發生以及發生故障時要求進行哪種通知。對公司而言，可用性關系網站的生死存亡。對個人而言，可用性關系到自己的績效升遷。工程師對架構做了許多優化、對代碼做了很多重構，對性能、擴展性、伸縮性做了很多改善，但別人未必能直觀地感受到。但如果產品出了重大故障例如頁面無響應，用戶能很直觀的感受到。事物總是先求生存，然后求發展。
1. 網站可用性的度量與考核
1.1網站可用性度量
網站不可用也被稱作網站故障，在軟件系統的高可靠性（也稱為可用性，英文描述為HA，High Available）里有個衡量其可靠性的標准——X個9，這個X是代表數字3--5。X個9表示在軟件系統1年時間的使用過程中，系統可以正常使用時間與總時間（1年）之比。
網站不可用時間(故障時間) =故障修復時間點故障發現(報告)時間點
網站年度可用性指標= ( 1-網站不可用時間/年度總時間) x100%
如QQ的可用性是4個9,即QQ服務99%可用，這意味着QQ服務要保證其在所有運行時間中，只有0.01 %的時間不可用，其業務中斷時間也就是(1-99.99%)*365*24=0.876小時=52.6分鍾。
對於大多數網站而言，2個9是基本可用，網站年度不可用時間小於88小時; 3個9是較高可用，網站年度不可用時間小於9小時; 4個9是具有自動恢復能力的高可用，網站年度不可用時間小於53分鍾; 5個9是極高可用性,網站年度不可用時間小於5分鍾。
由於可用性影響因素很多，對於網站整體而言，達到4個9,乃至5個9的可用性，除了過硬的技術、大量的設備資金投入和工程師的責任心，還要有個好運氣。SLA可用性好幾個9的阿里雲也宕機過多次。要做到更多的9，就要不斷的監控自己的服務，服務掛掉能及時恢復服務。就像開車出遠門，首先得檢查輪胎，同時還得准備一個備胎一樣的道理。
1.2網站可用性考核
可用性指標是網站架構設計的重要指標，對外是服務承諾，對內是考核指標。從管理層面，可用性指標是網站或者產品的整體考核指標，具體到每個工程師的考核，更多的是使用故障分。
所謂故障分是指對網站故障進行分類加權計算故障責任的方法 。
| 分類 |
描述 |
權重 |
| 事故級故障 |
網站整體不可用 |
100 |
| A類故障 |
網站訪問不順暢或核心功能不可用 |
20 |
| B類故障 |
非核心功能不可用，或核心功能少數用戶不可用 |
5 |
| C類故障 |
以上故障以外的其他故障 |
1 |
表1 網站故障分類權重表示例
故障分的計算公式為:
故障分=故障時間(分鍾) x故障權重
下面我們假設雙十一導致淘寶用戶猛增的場景，進一步對故障分加以說明。
| 場景 |
雙十一導致淘寶用戶猛增 |
| 刺激源 |
淘寶用戶 |
| 故障 |
登錄人數過多，導致淘寶無法響應，淘寶頁面癱瘓 |
| 持續時間 |
30分鍾 |
| 制品 |
淘寶的處理器、通信通道、存儲器、進程 |
| 環境 |
用戶的正常瀏覽操作 |
| 響應 |
淘寶頁面呈現“網絡出現故障，重新刷新”等的提示信息 |
| 響應度量 |
系統降級模式下繼續運行，用戶刷新頁面或者重新登錄之后可繼續正常使用。 |
表2 雙十一導致淘寶用戶猛增場景
通過故障的描述可知此次屬於A類故障且持續了30分鍾，那么故障分應為30*20=600分。出現了故障那么必然會有處理機制，以下是應對上述場景的一個簡化的故障處理流程圖。
圖1 淘寶故障處理流程圖
在年初或者考核季度的開始，會根據網站產品的可用性指標計算總的故障分，然后根據團隊和個人的職責角色分攤故障分，這個可用性指標和故障分是管理預期。在實際發生故障的時候，根據故障分類和責任划分將故障產生的故障分分配給責任者承擔。
2. 可用性的應用
2.1通過負載均衡進行無狀態服務的失效轉移
不保存狀態的應用給高可用的架構設計帶來了巨大便利，既然服務器不保存請求的狀態，那么所有的服務器完全對等，當任意一台或多台服務器宕機，請求提交給集群中其他任意一台可用機器處理，這樣對終端用戶而言，請求總是能夠成功的，整個系統依然可用。對於應用服務器集群，實現這種服務器可用狀態實時監測、自動轉移失敗任務的機制是負載均衡。
負載均衡主要使用在業務量和數據量較高的情況下，當單台服務器不足以承擔所有的負載壓力時，通過負載均衡手段，將流量和數據分攤到一個集群組成的多台服務器上，以提高整體的負載處理能力。
由於負載均衡在應用層實際上起到了系統高可用的作用，因此即使某個應用訪問量非常少，只用一台服務器提供服務就綽綽有余，但如果需要保證該服務高可用，也必須至少部署兩台服務器，使用負載均衡技術構建一個小型的集群。
2.2應用服務器集群的Session管理
應用服務器的高可用架構設計主要基於服務無狀態這一特性， 但是事實上，業務總是有狀態的，在交易類的電子商務網站例如淘寶京東，需要有購物車記錄用戶的購買信息，用戶每次購買請求都是向購物車中增加商品，用戶每次刷新頁面都需要更新這些信息。
Web應用中將這些多次請求修改使用的上下文對象稱作會話( Session ),單機情況下，Session可由部署在服務器上的Web容器管理。在使用負載均衡的集群環境中，由於負載均衡服務器可能會將請求分發到集群任何一台應用服務器上，所以保證每次請求依然能夠獲得正確的Session比單機時要復雜很多。
集群環境下，Session管理主要有以下幾種手段：
1. Session復制
應用服務器開啟Web容器的Session復制功能，在集群中的幾台服務器之間同步Session 對象，使得每台服務器上都保存所有用戶的Session 信息，這樣任何一台機器宕機都不會導致Session數據的丟失，而服務器使用Session時，也只需要在本機獲取即可。
2. Session 綁定
Session綁定可以利用負載均衡的源地址Hash算法實現，負載均衡服務器總是將來源於同一IP的請求分發到同一台服務器上。這樣在整個會話期間，用戶所有的請求都在同一台服務器上處理，即Session綁定在某台特定服務器上，保證Session總能在這台服務器上獲取。這種方法又被稱作會話黏滯。
3.利用Cookie記錄Session
早期的企業應用系統使用C/S(客戶端/服務器)架構，一種管理Session的方式是將Session記錄在客戶端，每次請求服務器的時候，將Session放在請求中發送給服務器，服務器處理完請求后再將修改過的Session 響應給客戶端。網站沒有客戶端，但是可以利用瀏覽器支持的Cookie記錄Session。
4. Session 服務器
Session服務器。利用獨立部署的Session 服務器(集群)統一管理Session,應用服務器每次讀寫Session時，都訪問Session服務器。這種解決方案事實上是將應用服務器的狀態分離，分為無狀態的應用服務器和有狀態的Session服務器，然后針對這兩種服務器的不同特性分別設計其架構。
3. 保障數據的可用性
對許多網站而言，數據是其最寶貴的物質資產，硬件可以購買，軟件可以重寫，但是多年運營積淀下來的各種數據(用戶數據、交易數據、商品數據）一旦失去，對網站的打擊可以說是毀滅性的，因此可以說，保護網站的數據就是保護企業的命脈。
不同於高可用的應用和服務，由於數據存儲服務器上保存的數據不同，當某台服務器宕機的時候，數據訪問請求不能任意切換到集群中其他的機器上。
保證數據存儲高可用的手段主要是數據備份和失效轉移機制。數據備份是保證數據有多個副本，任意副本的失效都不會導致數據的永久丟失，從而實現數據完全的持久化。而失效轉移機制則保證當一個數據副本不可訪問時，可以快速切換訪問數據的其他副本,保證系統可用。
3.1 CAP原理
為了保證數據的高可用，網站通常會犧牲另一個也很重要的指標:數據一致性。高可用的數據有如下幾個層面的含義：
數據持久性
在寫入數據時需要寫入持久性存儲，還需要將數據備份一個或多 個副本，存放在不同的物理存儲設備上,在某個存儲故障或災害發生時，數據不會丟失。
數據可訪問性
在多份數據副本分別存放在不同存儲設備的情況下，如果一個數據存儲設備損壞，就需要將數據訪問切換到另一個數據存儲設備上，如果這個過程不能很快完成(終端用戶幾乎沒有感知)，或者在完成過程中需要停止終端用戶訪問數據，那么這段時間數據是不可訪問的。
數據一致性
在數據有多份副本的情況下，如果網絡、服務器或者軟件出現故障，會導致部分副本寫入成功，部分副本寫入失敗。這就會造成各個副本之間的數據不一致，數據內容沖突。
CAP原理認為，一個提供數據服務的存儲系統無法同時滿足數據一致性( Consistency).數據可用性( Availibility).分區耐受性( Patition Tolerance, 系統具有跨網絡分區的伸縮性)這三個條件。
在大型網站中，為了保證分布式處理系統的高可用性，通常會選擇強化分布式存儲系統的可用性(A)和伸縮性(P),而在某種程度上放棄一致性(C)。
2012年淘寶“雙十一”活動期間，在活動第一分鍾就涌入了1000萬獨立用戶訪問，這種極端的高並發場景對數據處理系統造成了巨大壓力，存儲系統較弱的數據一致性導致出現部分商品超賣現象(交易成功的商品數超過了商品庫存數)。CAP原理對於可伸縮的分布式系統設計具有重要意義。
3.2 數據備份
數據備份是一-種古老而有效的數據保護手段，早期的數據備份手段主要是數據冷備，即定期將數據復制到某種存儲介質上並物理存檔保管，如果系統存儲損壞，那么就從冷備的存儲設備中恢復數據。
冷備的優點是簡單和廉價，成本和技術難度都較低。缺點是不能保證數據最終一致，由於數據是定期復制，因此備份設備中的數據比系統中的數據陳舊，如果系統數據丟失，那么從上個備份點開始后更新的數據就會永久丟失，不能從備份中恢復。同時也不能保證數據可用性，從冷備存儲中恢復數據需要較長的時間，而這段時間無法訪問數據，系統也不可用。
因此，數據冷備作為一種傳統的數據保護手段，依然在網站日常運維中使用，同時在網站實時在線業務中，還需要進行數據熱備，以提供更好的數據可用性。數據熱備可分為兩種:異步熱備方式和同步熱備方式。
傳統的企業級關系數據庫系統幾乎都提供了數據實時同步備份的機制。而一開始就為大型網站而設計的各種NoSQL數據庫(如HBase)更是將數據備份機制作為產品最主要的功能點之一 。
3.3 失效轉移
若數據服務器集群中任何一台服務器宕機，那么應用程序針對這台服務器的所有讀寫操作都需要重新路由到其他服務器，保證數據訪問不會失敗，這個過程叫作失效轉移。
失效轉移操作由三部分組成:失效確認、訪問轉移、數據恢復。
3.3.1失效確認
判斷服務器宕機是系統進行失效轉移的第一步，系統確認一台服務器是否宕機的手段有兩種:心跳檢測和應用程序訪問失敗報告。
對於應用程序的訪問失敗報告，控制中心還需要再一次發送心跳檢測進行確認，以免錯誤判斷服務器宕機，因為一旦進行數據訪問的失效轉移，就意味着數據存儲多份副本不一致，需要進行后續一系列復雜的操作。
圖2 存儲服務器失效確認
3.3.2訪問轉移
確認某台數據存儲服務器宕機后，就需要將數據讀寫訪問重新路由到其他服務器上。對於完全對等存儲的服務器(幾台存儲服務器存儲的數據完全一樣，我們稱幾台服務器為對等服務器，比如主從結構的存儲服務器，其存儲的數據完全一樣)，當其中一台宕機后，應用程序根據配置直接切換到對等服務器上。如果存儲是不對等的，那么就需要重新計算路由，選擇存儲服務器。
3.3.3數據恢復
因為某台服務器宕機，所以數據存儲的副本數目會減少，必須將副本的數目恢復到系統設定的值，否則，再有服務器宕機時，就可能出現無法訪問轉移(所有副本的服務器都宕機了),數據永久丟失的情況。因此系統需要從健康的服務器復制數據，將數據副本數目恢復到設定值。
參考資料：
1. 《大型網站技術架構_核心原理與案例分析》李智慧
2. 什么是“5個9”(99.999%)的可靠性?
（https://blog.csdn.net/varyall/article/details/82592970）
3.SLA服務可用性4個9是什么意思？怎么達到？
4.session到底是做什么的？
（https://blog.csdn.net/h19910518/article/details/79348051）
5.Cookie/Session機制詳解
6.分布式系統中CAP理論的理解
7.熱備份和冷備份區別