作業04之《大型網站技術架構：核心原理與案例分析》閱讀筆記

標籤：今天   度量   意義   誤區   時間   例子   考核   增強   工作   

      在這一節課上，我們學習了系統品質屬性其中的可用性和易用性。那麼品質屬性是什麼呢，品質屬性是高於對系統功能（即對系統能力、服務和行為）的基本的要求的。系統品質屬性講重點放在了可用性、可修改性、效能、安全性、可測試性和易用性。從設計師方面，系統品質屬性一般存在三個問題：（1）為屬性提供的定義並不是可操作的。（2）重點通常是一個特定的方面屬於哪個品質屬性。（3）每個屬性團隊都開發了其自己的詞彙。

      今天我們就根據《大型網站技術架構：核心原理與案例分析》將重點放在可用性和易用性的學習討論上以及將其方法和實發項目結合起來，來增強我們實際系統的可用性和易用性。

      先來瞭解一下可用性。可用性與系統故障及其相關後果有關。當系統不再提供其規範中所說明的服務時，就出現了系統故障。系統的使用者（人或其他系統）可以觀察到此類故障。系統可用性是系統正常啟動並執行時間比例。一般將系統可用性定義為：α=平均正常工作時間/（平均正常工作時間+平均修複時間）。有兩個著名的例子。2011年4月12日，亞馬遜雲端運算服務EC2發生故障，其ESB服務不可用，故障持續了數天，最終還是有部分資料未能恢複。這一故障導致美國許多使用亞馬遜服務的知名網站受到影響，並引發了人們對使用雲端運算安全性、可靠性的大規模討論。2010年1月12日，百度被駭客攻擊，其DNS網域名稱被劫持，導致百度全站長達數小時不可訪問。

      網站不可用也被稱為網站故障，業界通常用多少個9來衡量網站的可用性，對於大多數網站而言，2個9是基本可用，網站年度不可用時間小於88小時；3個9是較高可用，網站年度不可用時間小於9小時；4個9是具有自動回復能力的高可用，網站的年度不可用時間小於53分鐘，比如QQ就是4個9；5個9是極高可用性，網站年度不可用時間小於5分鐘。可用性指標是網站架構設計的重要指標，是網站或者產品的整體考核指標。網站可用性是更加看得見摸得著的品質屬性，所以在架構設計上，系統可用性的部分就需要花費更多的時間和精力了。而實現高可用架構的主要手段是資料和服務的冗餘備份及失效轉移，一旦某些伺服器宕機，就將服務切換到其他可用的伺服器上，如果磁碟損壞，則從備份的磁碟讀取資料。所以就我們的《XXX系統》來說，不是只要完成系統的功能就等於完成了這個系統，根據系統的可用性，做好資料的備份與還原是最重要的保障之一。但是我們在設計和開發這個系統時，卻把大部分精力放在了功能的實現上，這是一個很大的誤區。在資料庫的設計方面也是很重要的，加密儲存、及時備份、儲存日誌都不失為是一個好的方法。保證資料的可持久儲存，資料的可訪問性，在資料有多份副本的情況下的一致性，都可以更好的維護我們的系統，提高我們系統的可用性。在伺服器宕機時，進行失效轉移可以保證資料訪問不會失敗，失效確認、訪問轉移、資料恢複都可以保證網站的資料不會丟失。對於我們的這個系統，為了保障高可用運行，我們還可以使用發布指令碼來完成網站的更新發布，可以減少重啟伺服器和重新部署，而且不會影響使用者使用。

      我們都在使用，但是恐怕不清楚從發布到擁有一億使用者，僅僅用了一年時間。而且據說搖一搖功能是兩個實習生用一個星期就開發完成的。那麼他們是如何做到輕易地開發新產品，快速地實現一個新功能的呢？答案就是有賴於網站的擴充性架構設計，也就是指在對現有系統影響最小的情況下，系統功能可持續擴充及提升的能力。這樣在系統增加新功能時，不需要對現有系統的結構和代碼進行修改。也就是說我們的系統在開發時同樣有一個目標就是開發低耦合系統，這是度量一個系統、一個開發架構的重要尺度。我們現在做的系統還比較小，可能不會有太大體會，但是對於一個大型網站來說，功能複雜，產品眾多，更新也非常迅速。如果不分割模組管理的話，不久網站的維護就會變得很困難。所以我們的系統眼下需要做的一個修改就是功能的封裝。將小功能封裝在不同的類裡，再進行調用，系統結構就會清晰的多。也不用擔心功能的增加帶來的影響。資料庫的表結構也需要實現低耦合的關聯。

      現如今的網站，想要引人矚目，在激烈的競爭市場上生存下來取決於誰能更快更好地推出新產品。也就是意味著我們需要一個更具有擴充性的網站架構實現一個效率更高、可用性更好的網站。這也就是網站架構的意義所在。

作業04之《大型網站技術架構：核心原理與案例分析》閱讀筆記