網站的可用性描述網站可有效訪問的特性。相比於網站的其他非功能特性，網站的可用性更牽動著人們的神經，大型網站的不可用事故直接影響公司形象和利益，許多互聯網公司都將網站可用性列入了工程師的績效考核，與獎金升遷等利益掛鉤。

　　　網站不可用也被稱作網站故障，業界通常用多少個9來衡量網站的可用性，如QQ的可用性是4個9，即QQ服務99.99%可用，這意味著QQ服務器要保證其在所有運行時間中，只有0.01%的時間不可用，也就是一年中大約最多53分鐘不可用。由於可用性影響因素很多，對於網站整體而言，達到4個9，乃至5個9的可用性，處理過硬的技術，大量的設備資金投入和工程師的責任心，還要有個好運氣。

　　　可用性指標是網站架構設計的重要指標，對外是服務承諾，對內是考核指標。從管理層面，可用性指標是網站或者產品的整體考核指標，具體到每個工程師的考核，更多的是使用故障分。故障分=故障時間（分鐘）X 故障權重。有時候一個故障責任可能由多個部門或團隊來承擔，故障分也會相應按責任分攤到不同的團隊和個人。

　　　不同於其他架構指標，網站可用性更加看得見摸得著，跟技術、運營、相關各方的績效考核息息相關，因此在架構設計與評審會議上，關於系統可用性的討論與爭執總是最花費時間與精力的部分。

　　　通常企業級應用系統為提高系統可用性，會采用較昂貴的軟硬件設備。實現高可用架構的主要手段是數據和服務的榮譽備份及失效轉移，一旦某些服務器宕機，就將服務切換到其他可用的服務器上，如果磁盤損壞，則從備份到磁盤讀取數據。

網站升級的頻率一般都很高，大型網站一周發布一次，中小型網站一天發布幾次。每次網站發布都需要關閉服務，重新部署系統，整個過程相當於服務器宕機。因此網站的可用性架構設計不但要考慮實際的硬件故障引起的宕機，還要考慮網站審計發布引起的宕機，二後者更加頻繁，不能因為系統可以接受偶爾的停機故障就降低可用性設計的標準。

　　應用層主要處理網站應用的業務邏輯，因此有時也稱作業務邏輯層，應用的一個顯著特點就是應用的無狀態性。由於負載均衡在應用層實際上起到了系統高可用的作用，因此即使某個應用訪問量非常少，只用一臺服務器提供服務就綽綽有余，但如果需要保證該服務器高可用，也必須至少部署兩臺服務器，使用負載均衡技術個歐建一個小型的集群。

　　可復用的服務器模塊為業務產品提供基礎公共服務，大型網站中這些服務通常都獨立分布式部署，被具體應用遠程調用。可復用的服務和應用一樣，也是無狀態的服務，因此可以使用類似負載均衡的失效轉移策略實現高可用的服務。除此之外，具體實踐中，還有以下幾點高可用的服務策略。1）分級管理 2）超時設置 3）異步調用 4）服務降級 5）冪等性設計

　　回顧網站架構發展歷程，網站架構發展史就是一部不斷向網站添加服務器的歷史。只要工程師能向網站的服務器集群中添加新的機器，只要新添加的服務器能線性提高網站整體服務處理能力，網站就無需為不斷增長的用戶和訪問而焦慮。

　　將不同功能分離部署可以實現一定程度的伸縮性，但是隨著網站訪問量的逐步增加，即使分離到最小力度的獨立部署，單一的服務器也不能滿足業務規模的要求。因此必須使用服務器集群，即將相同服務部署在多態服務器上構成一個集群整體對外提供服務。具體來說，集群伸縮性又可分為應用服務器集群伸縮性和數據服務器集群伸縮性。

　　開發低耦合系統是軟件設計的終極目標之一，這一目標驅動著軟件開發技術的創新與發展，從軟件與硬件的第一次奮力到操作系統的誕生；從匯編語言到面向過程的開發語言，砸到面相對對象的編程語言。可以說，度量一個開發框架、設計模式、編程語言優劣的重要尺度就是衡量它是不是讓軟件開發過程和軟件產品更加低耦合。

可用性和可修改性戰術分析