《大型網站技術架構》讀書筆記之五:萬無一失之網站的高可用架構

此篇已收錄至《大型網站技術架構》讀書筆記系列目錄貼,點擊訪問該目錄可獲取更多內容。html

1、可用性度量與考覈

  首先,不得不說:要保證一個網站永遠徹底可用幾乎是一件不可能完成的任務(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等),其計算公式爲:故障分=故障時間(分鐘)*故障權重。公司對技術團隊的考覈通常會參考故障分,例如某團隊今年發生了幾個事故級故障,那麼其績效考覈估計受到很大影響,年終獎什麼的就悲劇了。負載均衡

2、高可用的架構

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

  (1)設計的目的?

  保證服務器硬件故障服務依然可用,數據依然保存並可以被訪問

  (2)主要的手段?

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

  對於服務而言,一旦某個服務器宕機,就將服務切換到其餘可用的服務器上;

  對於數據而言,若是某個磁盤損壞,就從備份的磁盤(事先就作好了數據的同步複製)讀取數據。

3、高可用的應用

  應用層處理網站應用的業務邏輯,應用的一個最顯著的特色是:應用的無狀態性

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的存儲和訪問要求。

4、高可用的服務

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

  在具體實踐中,有如下幾點高可用的服務策略能夠參考:

  ①分級管理:核心應用和服務具備更高的優先級,好比用戶及時付款比可否評價商品更重要;

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

  ③異步調用:經過消息隊列等異步方式完成,避免一個服務失敗致使整個應用請求失敗的狀況。

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

  ④服務降級:網站訪問高峯期間,爲了保證核心應用的正常運行,須要對服務降級。

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

  ⑤冪等性設計:保證服務重複調用和調用一次產生的結果相同;

5、高可用的數據

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

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

  ①數據備份:又分爲冷備份和熱備份,冷備份是按期複製,不能保證數據可用性。熱備份又分爲異步熱備和同步熱備,異步熱備是指多份數據副本的寫入操做異步完成,而同步方式則是指多份數據副本的寫入操做同時完成。

  關係數據庫的熱備機制就是一般所說的主從同步機制,實踐中一般使用讀寫分離的方法來訪問Master和Slave數據庫,也就是說寫操做只訪問Master庫,讀操做均訪問Slave庫。

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

  ②失效轉移:若數據服務器集羣中任何一臺服務器宕機,那麼應用程序針對這臺服務器的全部讀寫操做都要從新路由到其餘服務器,保證數據訪問不會失敗。

6、高可用的QA

  ①網站發佈:在柔性的發佈過程當中,每次關閉的服務都是集羣中的一小部分,並在發佈完成後當即能夠訪問;

  ②自動化測試:使用自動測試工具或腳本完成測試;

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

  ④代碼控制:目前大多數網站採用SVN,分支開發,主幹發佈模式;另外,目前開源社區普遍採用Git做爲版本控制工具,正逐步取代SVN的地位;

7、網站運行監控

  」不容許沒有監控的系統上線「

  (1)監控數據採集

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

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

  ③運行數據報告:採集並報告,彙總後統一顯示,應用程序須要在代碼中處理運行數據採集的邏輯;

  (2)監控管理

  ①系統報警:配置報警閥值和值守人員聯繫方式,系統發生報警時,即便工程師在千里以外,也能夠被及時通知;

  ②失效轉移:監控系統在發現故障時,主動通知應用進行失效轉移;

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

8、學習小結

  本篇咱們經過書籍學習了爲了實現網站的高可用,可使用的策略和模式。書中做者有一句話說的十分好,」事務老是先求生存,而後求發展「。保證網站高可用,萬無一失,任重而道遠啊!今天的學習筆記就分享到這裏,洗洗睡了,麼麼嗒!對了,今天去影院看了老男孩之猛龍過江,看二傻大鬧牛喲可(New York),聽了小蘋果,頓時感受本身萌萌噠,有木有?不談夢想和劇情,裏面的幾首歌仍是蠻好聽的。

 

參考文獻

  (1)李智慧,《大型網站技術架構-核心原理與案例分析》,http://item.jd.com/11322972.html

本章思惟導圖

 

相關文章
相關標籤/搜索