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

  《大型網站技術架構:核心原理與案例分析》的第5、6、七章主要講述一個系統的可用性、伸縮性和可擴展性。而根據文中所講述的，一個系統的可用性主要是體如今這個系統的系統服務不中斷運行時間佔實際運行時間的比例，系統的伸縮性則是指在不改變系統軟硬件設計，僅僅經過新增服務器的狀況下，就能提高系統的處理能力，而系統的可擴展性是指該系統適應變化的能力。

   網站的可用性戰術是網站有效運行的根本保障，一個網站的高可用性可以給用戶很大的安全感，最大限度的保障用戶的利益、隱私不被侵犯。因爲經費有限，硬件設備在節約成本的同時也下降了可用性，因此硬件故障就發生的比較頻繁，所以，網站的高可用架構設計的主要目的就是保證服務器硬件故障時服務依然可用、數據依然保存並可以被訪問。典型的網站設計一般遵循三層架構模型，應用層、服務層、數據層，各層之間具備相對獨立性，應用層主要負責具體業務邏輯處理；服務層負責提供可複用的服務；數據層負責數據的存儲與訪問。中小型網站在具體部署時，一般將應用層和服務層部署在一塊兒，而數據層則另外部署。應用層主要處理網站應用的業務邏輯，應用的一個顯著特色是應用的無狀態性。不保存狀態的應用給高可用的架構設計帶來了巨大便利，既然服務器不保存請求的狀態，那麼全部的服務器徹底對等，當任意一臺或多臺服務器宕機，請求提交給其餘任意一臺可用機器處理，這樣對終端用戶而言，請求老是可以成功的，整個系統依然可用。CAP原理就是選擇強化分佈式存儲系統的可用性和伸縮性，而在某種程度上放棄一致性。CAP原理對於可伸縮的分佈式系統設計具備重要意義，不恰當地迎合各類需求，可能會使設計進入兩難境地，難覺得繼。咱們的系統有大量的統計數據。咱們的網站隨時都有可能進行修改，好比發佈新功能，這時就須要在服務器上關閉原有的應用，從新部署新的應用，整個過程要求不影響用戶的使用。爲了把對用戶的影響下降到最小，一般使用發佈腳原本完成發佈。通過嚴格的測試，軟件部署到服務器仍是會出現問題，主要緣由就是測試環境和線上環境並不相同，因此咱們在網站發佈時，要把測試經過的代碼先發布到預發佈機器上，確認系統沒有問題後才正式發佈。 網站的可擴展架構是隨需而變的。網站的擴展性架構設計，是對現有系統影響最小的狀況下，系統功能可持續擴展及提高的能力。擴展性是指對現有系統影響最小的狀況下，系統功能可持續擴展或提高的能力。它是系統架構設計層面的開閉原則，架構設計考慮將來功能擴展，當系統增長新功能時，不須要對現有系統的結構和代碼進行修改。設計網站可擴展架構的核心思想是模塊化，並在此基礎上，下降模塊間的耦合性，提供模塊的複用性。模塊經過分佈式部署，獨立的模塊部署在獨立的服務器上集羣從物理上分離模塊之間的耦合關係。

關於《河北省重大技術需求徵集》系統中對用戶的需求管理是可用的，該系統能完整錄入需求，能把提交的需求進行展現、查看。其中徵集模塊以及分類瀏覽、樹形結構能是可以切合可用性的原則， 可是對錯誤的恢復仍是不夠完善，當用戶的需求在各類外界因數干擾下沒有提交成功，系統對數據的恢復仍是作不到。《XXX重大技術需求徵集系統》的伸縮性爲0，其中涉及到了服務器的數量，基本就是在我的機上來運行的，沒有嘗試過在多臺服務器上運行，因此對於網站的伸縮性瞭解的很少。