閱讀《大型網站技術架構：核心原理與案例分析》第5、6、七章，結合《XXX重大技術需求徵集系統》，列舉實例分析採用的可用性和可修改性戰術，將上述內容撰寫成一篇1500字左右的博客闡述你的觀點。

　　這三章主要講述的是網站的可用性、伸縮性和可擴展性。

　　首先，網站的可用性描述網站可有效訪問的特性，相比於網站的其餘非功能特性，網站的可用性更容易引發人們的注意，尤爲是大型網站的可用性，若是大公司的網站出現錯誤或者不能登陸上去，不但會影響人們的瀏覽，並且也會給公司帶來不可想象的經濟損失。可是要保證一個網站永遠徹底可用幾乎是一件不可能完成的任務。咱們經過一個神奇的數字9來度量網站可用性，採用故障分來考覈網站可用性。可用性指標是網站架構設計的重要指標，網站可用性看得見，摸得着，跟技術、運營、相關各方的績效考覈息息相關。一個典型的網站設計遵循基本分層架構模型即應用層、服務層、數據層。應用層主要負責具體業務邏輯處理；服務層負責提供可複用的服務；數據層負責數據的存儲和訪問。網站的可用性架構設計不但考慮實際的硬件故障引發的宕機，還要考慮網站升級發佈引發的宕機。高可用的服務策略包括分級管理、超時設置、服務降級（關閉非核心服務）等。高可用的數據是最寶貴的資產，保證數據存儲高可用的手段主要是數據備份和失效轉換機制。數據備份能夠實現數據徹底的持久化，失效轉換機制是爲了保證系統可用。保證網站高可用，萬無一失，是一個艱難的過程，還須要更多努力。

　　相比較咱們在去年的軟件工程概論的課程中所編寫的《XXX重大技術需求徵集系統》來講，可用性基本爲0，所編寫的這個系統，只是咱們我的的成果而已，對於其中的聯網、測試、發佈等並無進行相應的操做，總的來講就是一個空殼子系統，並無很大的實際應用。同時，自身的系統還須要不斷的完善，良好的界面風格，簡單便捷的操做，合理的結構佈局，以及適當的錯誤信息提示和網站的反應速度都要進一步的優化。

　　其次，描述的就是網站的伸縮性。所謂網站的伸縮性，指不須要改變網站的軟硬件設計，僅僅經過改變部署的服務器數量就能夠擴大或者縮小網站的服務處理能力。要實現網站的可伸縮性，關鍵技術就在於如何構建良好的服務器集羣。要達到良好的目標，就要求每次擴容和減小服務器時，對整個網站的影響是最小的。CAP原理就是選擇強化分佈式存儲系統的可用性和伸縮性，而在某種程度上放棄一致性。CAP原理對於可伸縮的分佈式系統設計具備重要意義，不恰當地迎合各類需求，可能會使設計進入兩難境地，難覺得繼。咱們的系統有大量的統計數據。咱們的網站隨時都有可能進行修改，好比發佈新功能，這時就須要在服務器上關閉原有的應用，從新部署新的應用，整個過程要求不影響用戶的使用。爲了把對用戶的影響下降到最小，一般使用發佈腳原本完成發佈。通過嚴格的測試，軟件部署到服務器仍是會出現問題，主要緣由就是測試環境和線上環境並不相同，因此咱們在網站發佈時，要把測試經過的代碼先發布到預發佈機器上，確認系統沒有問題後才正式發佈。

　　《XXX重大技術需求徵集系統》的伸縮性爲0，其中涉及到了服務器的數量，基本就是在我的機上來運行的，沒有嘗試過在多臺服務器上運行，因此對於網站的伸縮性瞭解的很少。

　　最後，講解的是網站的可擴展性。對於可擴展性來講，是隨需而變的。有的網站能夠隨時發佈，新功能隨時快速上線，而有的必須規定發佈日，究其緣由，則依賴於網站的擴展性架構設計。擴展性和伸縮性不一樣。擴展性是指對現有系統影響最小的狀況下，系統功能可持續擴展或提高的能力。它符合系統架構設計層面的開閉原則，架構設計考慮到了系統將來的功能擴展，即當系統須要增長新的功能時，不須要對系統的原有代碼進行編輯和修改或者不須要對源代碼進行較大的改動。其設計的核心思想是模塊化，並在此基礎上，下降模塊的耦合性，提供模塊的複用性。

　　這一特性對於所寫的《XXX重大技術需求徵集系統》來講，仍是有一些熟悉的，由於在編寫的過程當中，對系統進行了屢次的修改，頁面的設計、功能的增長、角色的管理、按鍵以及相應的提示信息都根據所給的編寫文檔進行了屢次的修改，每次都儘可能使新增和修改的代碼在少數，能最大程度的減小本身的工做量。

　　網站的可用性、伸縮性和可擴展性，在不少方面影響着網站的質量，一個優秀的網站，不只能給用戶帶來很好的體驗，也能夠爲公司創造出巨大的利潤，可是要想把網站維護的更加完美，還須要不斷的去努力，公司的資金投入、工程師認真負責的態度以及相應的運氣，都是必不可少的條件。