閱讀《大型網站技術架構：核心原理與案例分析》第5、6、七章

 題目：閱讀《大型網站技術架構：核心原理與案例分析》第5、6、七章，結合《XXX需求徵集系統》，分析如何增長相應的功能，提升系統的可用性和易用性，撰寫一篇1500字左右的博客闡述你的觀點

 

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

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

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

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

      高可用架構是萬無一失的。要保證一個網站永遠徹底可用幾乎是一件不可能完成的任務。咱們經過一個神奇的數字9來度量網站可用性，採用故障分來考覈網站可用性。可用性指標是網站架構設計的重要指標，網站可用性看得見，摸得着，跟技術、運營、相關各方的績效考覈息息相關。一個典型的網站設計遵循基本分層架構模型即應用層、服務層、數據層。應用層主要負責具體業務邏輯處理；服務層負責提供可複用的服務；數據層負責數據的存儲和訪問。網站的可用性架構設計不但考慮實際的硬件故障引發的宕機，還要考慮網站升級發佈引發的宕機。高可用的服務策略包括分級管理、超時設置、服務降級（關閉非核心服務）等。高可用的數據是最寶貴的資產，保證數據存儲高可用的手段主要是數據備份和失效轉換機制。數據備份能夠實現數據徹底的持久化，失效轉換機制是爲了保證系統可用。保證網站高可用，萬無一失，是一個艱難的過程，還須要更多努力。

      對於咱們的系統來講，友好的界面風格，簡單便捷的操做，合理的結構佈局，良好的提示是必要的，對提升易用性非常有幫助。表格的設計須要提供給使用者好的視覺效果，減小給操做者帶來視覺疲勞，操做提示應易於理解，使用準確恰當的語言。三級菜單的實現算法要以時間複雜度爲標準，顯示快，無需等待。

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

     咱們的系統面向的用戶多，範圍廣，經過不斷地向集羣中添加服務器來加強整個集羣的處理能力，這就是網站系統的伸縮性架構，網站以此手段不斷提高本身的規模，這個演化過程整體來講是漸進式的。網站的伸縮性設計可分爲兩類，一類是根據功能進行物理分離實現伸縮、一類是單一功能經過集羣實現伸縮。其中HTTP請求分發配置即負載均衡服務器，實現負載均衡的基礎技術主要有HTTP重定向、DNS域名解析、反向代理、IP、數據鏈路層負載均衡。伸縮性和可用性、正確性、性能等耦合在一塊兒。伸縮性是複雜的，沒有通用的、完美的解決方案和產品，但有不少這方面的案例可供借鑑。一個具備良好伸縮性的網站，其設計老是走在業務發展的前面，在業務須要處理更多訪問和處理以前，就已經作好了充分的準備，當業務須要時，只須要增長服務器並簡單部署就能夠了，技術團隊即可輕鬆應對了。

     可擴展架構是隨需而變的。有的網站能夠隨時發佈，新功能隨時快速上線，而有的必須規定發佈日，究其緣由，則依賴於網站的擴展性架構設計。擴展性和伸縮性不一樣。相比之下就發現上學期本身作的網站。。。。唉，學了mvc模式和三大框架後更加以爲本身作的差了，所謂越是無知越是看不清本身，越是廣識越是以爲本身眇小就是這樣吧。。。。