一、可用性度量與考核

　　首先，不得不說：要保證一個網站永遠完全可用幾乎是一件不可能完成的任務（Mission Impossible，是不是有點碟中諜的感覺）。

　　（1）如何度量網站可用性？

　　一個神奇的數字—9！你有幾個9，就代表了你的可用性。例如QQ可用性達到了4個9：99.99%

　　①2個9=基本可用　　②3個9=較高可用　　③4個9=具有自動恢復能力的高可用　　④5個9=極高可用->理想狀態

　　那麽，可用性的9又是怎麽計算出來的呢：

　　①網站不可用時間=故障修復時間點-故障發現時間點

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

　　（2）如何考核網站可用性？

　　廣泛采用故障分的，它是對網站故障進行分類加權計算故障責任的方法。一般會給每個分類的故障設置一個權重（例如事故級故障權重為100，A類為20等），其計算公式為：故障分=故障時間（分鐘）*故障權重。公司對技術團隊的考核一般會參考故障分，例如某團隊今年發生了幾個事故級故障，那麽其績效考核估計受到很大影響，年終獎什麽的就悲劇了。

二、高可用的架構

　　目前，通常企業級應用系統（特別是政府部門和大企業的應用系統）一般會采用安規的軟硬件設備，如IOE（IBM的小型機、Oracle數據、EMC存儲設備）系列。而一般互聯網公司更多地采用PC級服務器（x86），開源的數據庫（MySQL）和操作系統（Linux）組建廉價且高容錯（硬件故障是常態

　　（1）設計的目的？

　　保證服務器硬件故障服務依然可用，數據依然保存並能夠被訪問。

　　（2）主要的手段？

　　數據和服務的①冗余備份以及②失效轉移：

　　對於服務而言，一旦某個服務器宕機，就將服務切換到其他可用的服務器上；

　　對於數據而言，如果某個磁盤損壞，就從備份的磁盤（事先就做好了數據的同步復制）讀取數據。

三、高可用的應用

　　應用層處理網站應用的業務邏輯，應用的一個最顯著的特點是：應用的無狀態性。

PS：提到無狀態特性，不得不說下Http協議。我們常常聽到說，Http是一個無狀態協議，同一個會話的連續兩個請求互相不了解，他們由最新實例化的環境進行解析，除了應用本身可能已經存儲在全局對象中的所有信息外，該環境不保存與會話有關的任何信息。之所以我們在使用ASP.NET WebForm開發中會感覺不到Http的無狀態特性，完全是因為Microsoft幫我們實現了ViewState

，它是ASP.NET WebForm中保存頁面信息的基本單位，本質是一個HTML中的隱藏域，回調時會將這個隱藏域中的數據提交到服務器端。 　

　　（1）通過負載均衡進行無狀態服務的失效轉移

　　（2）應用服務器集群的Session管理

　　首先，不得不說的是：Web應用中將上下文對象稱為會話（Session），單機情況下由部署在服務器上得Web容器（如IIS、Tomcat、JBoss等）管理。在使用了負載均衡的集群環境中，由於請求的分發是隨機的，所以保證每次請求依然能夠獲得正確的Session比單機時要復雜得多。

　　其次，我們來看看在集群環境中，Session管理的幾種常見手段。

　　①Session復制：該方案簡單易行，集群中的幾臺服務器之間同步Session對象，任何一臺服務器宕機都不會導致Session對象的丟失，服務器也只需要從本機獲取即可。但是，該方案只適合集群規模較小的情況下。當規模較大時，大量的Session復制操作會占用服務器和網絡的大量資源，系統不堪重負。

　　②Session綁定：利用負載均衡的源地址Hash算法，總是將源於同一IP地址的請求分發到同一臺服務器上。這樣的話，在整個會話期間，用戶所有的請求都在同一臺服務器上進行處理，即Session綁定在某臺特定服務器上，保證Session總能在這臺服務器上獲取。（這種方案又叫做會話粘滯）。

　　但是，這種方案不符合高可用的需求。因為一旦某臺服務器宕機，那麽該機器上得Session也就不復存在了，用戶請求切換到其他機器後因為沒有Session而無法完成業務處理。因此，很少有網站采用此方案進行Session管理。

　　③Cookie記錄Session：利用瀏覽器支持的Cookie記錄Session簡單易行，可用性高，並且支持服務器的線性伸縮，因此，許多網站都或多或少地使用了Cookie來記錄Session。但是Cookie記錄Session有缺點：比如受Cookie大小限制、每次請求響應都要傳輸Cookie影響性能、用戶關閉了Cookie會造成訪問不正常等。

　　④Session服務器：利用獨立部署的Session服務器（集群）統一管理Session，應用服務器每次讀寫Session時，都訪問Session服務器。這種方案實際上是將應用服務器的狀態分離，分為無狀態的應用服務器和有狀態的Session服務器。

　　對於，有狀態的Session服務器，一種較簡單的方法是利用分布式緩存（如Memcached、Redis等，有關Redis的簡單介紹可以閱讀我的博文：NoSQL初探之人人都愛Redis）、數據庫等，在這些產品的基礎上進行封裝，使其符合Session的存儲和訪問要求。

四、高可用的服務

　　高可用的服務模塊為業務產品提供基礎公共服務，在大型站點中這些服務通常都獨立分布式部署，被具體應用遠程調用。

　　在具體實踐中，有以下幾點高可用的服務策略可以參考：

　　①分級管理：核心應用和服務具有更高的優先級，比如用戶及時付款比能否評價商品更重要；

　　②超時設置：設置服務調用的超時時間，一旦超時後，通信框架拋出異常，應用程序則根據服務調度策略選擇重試or請求轉移到其他服務器上；

　　③異步調用：通過消息隊列等異步方式完成，避免一個服務失敗導致整個應用請求失敗的情況。

PS：不是所有服務都可以異步調用，對於獲取用戶信息這類調用，采用異步方式會延長響應時間，得不償失。對於那些必須確認服務調用成功後才能繼續進行下一步的操作的應用也不適合異步調用。有關具體使用消息隊列實現異步調用的案例，請閱讀我的博文：《使用Redis作為消息隊列服務場景的應用案例》。

　　④服務降級：網站訪問高峰期間，為了保證核心應用的正常運行，需要對服務降級。

　　降級有兩種手段：一是拒絕服務，拒絕較低優先級的應用的調用，減少服務調用並發數，確保核心應用的正常運行；二是關閉功能，關閉部分不重要的服務，或者服務內部關閉部分不重要的功能，以節約系統開銷，為核心應用服務讓出資源；

　　⑤冪等性設計：保證服務重復調用和調用一次產生的結果相同；

五、高可用的數據

　　對於大多數網站而言，數據是其最寶貴的物質資產。

　　保證數據高可用的主要手段有兩種：一是數據備份，二是失效轉移機制；

　　①數據備份：又分為冷備份和熱備份，冷備份是定期復制，不能保證數據可用性。熱備份又分為異步熱備和同步熱備，異步熱備是指多份數據副本的寫入操作異步完成，而同步方式則是指多份數據副本的寫入操作同時完成。

　　關系數據庫的熱備機制就是通常所說的主從同步機制，實踐中通常使用讀寫分離的方法來訪問Master和Slave數據庫，也就是說寫操作只訪問Master庫，讀操作均訪問Slave庫。

PS：在MS SQL Server中，可以通過發布訂閱功能實現主從分離。關於發布訂閱，可以參考MSDN的這篇文章：http://technet.microsoft.com/zh-cn/ff806143.aspx

　　②失效轉移：若數據服務器集群中任何一臺服務器宕機，那麽應用程序針對這臺服務器的所有讀寫操作都要重新路由到其他服務器，保證數據訪問不會失敗。

六、高可用的QA

　　①網站發布：在柔性的發布過程中，每次關閉的服務都是集群中的一小部分，並在發布完成後立即可以訪問；

　　②自動化測試：使用自動測試工具或腳本完成測試；

　　③預發布驗證：引入預發布服務器，與正式服務器幾乎一致，只是沒有配置在負載均衡服務器上，外部用戶無法訪問；

　　④代碼控制：目前大多數網站采用SVN，分支開發，主幹發布模式；另外，目前開源社區廣泛采用Git作為版本控制工具，正逐步取代SVN的地位；

七、網站運行監控

　　”不允許沒有監控的系統上線“

　　（1）監控數據采集

　　①用戶行為日誌收集：服務器端的日誌收集和客戶端的日誌收集；目前許多網站逐步開發基於實時計算框架Storm的日誌統計與分析工具；

　　②服務器性能監控：收集服務器性能指標，如系統Load、內存占用、磁盤IO等，及時判斷，防患於未然；

　　③運行數據報告：采集並報告，匯總後統一顯示，應用程序需要在代碼中處理運行數據采集的邏輯；

　　（2）監控管理

　　①系統報警：配置報警閥值和值守人員聯系方式，系統發生報警時，即使工程師在千裏之外，也可以被及時通知；

　　②失效轉移：監控系統在發現故障時，主動通知應用進行失效轉移；

　　③自動優雅降級：為了應付網站訪問高峰，主動關閉部分功能，釋放部分系統資源，保證核心應用服務的正常運行；—>網站柔性架構的理想狀態

本章思維導圖

高可用架構(轉載）