這三章主要強調了網站架構應具備高可用性、伸縮性和可擴展性。java
第5章主要講述了網站的架構的高可用性。要保證一個網站永遠徹底可用幾乎是一件不可能完成的任務。業界經過一個多少個9來度量網站可用性,採用故障分來考覈網站可用性。可用性指標是網站架構設計的重要指標,網站可用性看得見,摸得着,跟技術、運營、相關各方的績效考覈息息相關。一個典型的網站設計遵循基本分層架構模型即應用層、服務層、數據層。應用層主要負責具體業務邏輯處理;服務層負責提供可複用的服務;數據層負責數據的存儲和訪問。網站的可用性架構設計不但考慮實際的硬件故障引發的宕機,還要考慮網站升級發佈引發的宕機。高可用的服務策略包括分級管理、超時設置、服務降級(關閉非核心服務)等。高可用的數據是最寶貴的資產,保證數據存儲高可用的手段主要是數據備份和失效轉換機制。數據備份能夠實現數據徹底的持久化,失效轉換機制是爲了保證系統可用。對公司而言,可用性關係到網站的生死存亡,對我的而言,可用性關係到我的績效升遷。因此保證網站可用,任重而道遠。數據庫
對於咱們正在設計的系統,就可用性方面而言,我以爲能夠添加一個刪除以後能夠恢復的功能。新建一個日誌功能,方便用戶或者設計者找到網站的缺陷。而後,就易用性方面而言。我覺首先應該優化一下填報界面得javaScript代碼。保證代碼的準確性。並使其處理速度更快。服務器
第6章主要講了網站架構的伸縮性,所謂網站架構的伸縮性,就是指不須要改變網站的軟硬件設計,僅僅經過改變部署的服務器數量就能夠擴大或者縮小網站的服務處理能力。要實現網站的可伸縮性,關鍵技術就在於如何構建良好的服務器集羣。要達到良好的目標,就要求每次擴容和減小服務器時,對整個網站的影響是最小的。CAP原理就是選擇強化分佈式存儲系統的可用性和伸縮性,而在某種程度上放棄一致性。CAP原理對於可伸縮的分佈式系統設計具備重要意義,不恰當地迎合各類需求,可能會使設計進入兩難境地,難覺得繼。咱們的系統有大量的統計數據。咱們的網站隨時都有可能進行修改,好比發佈新功能,這時就須要在服務器上關閉原有的應用,從新部署新的應用,整個過程要求不影響用戶的使用。爲了把對用戶的影響下降到最小,一般使用發佈腳原本完成發佈。通過嚴格的測試,軟件部署到服務器仍是會出現問題,主要緣由就是測試環境和線上環境並不相同,因此咱們在網站發佈時,要把測試經過的代碼先發布到預發佈機器上,確認系統沒有問題後才正式發佈。數據結構
一個具備良好伸縮性架構設計的網站,其設計老是走在業務發展前面,在業務須要處理更多訪問和服務之間,就已經作好充足準備,當業務須要時,只須要購買和租用服務器簡單部署實施便可,技術團隊亦能夠高枕無憂。架構
就咱們的系統而言,因爲訪問的用戶不會太多。因此可伸縮的設計在這裏不作過多的闡述。分佈式
第7章主要講了網站架構的可擴展性,所謂可擴展性,是指對現有系統響最小的狀況下,系統功能可持續擴展或提高的能力。表如今系統基礎設施穩定不須要常常變動,應用之間較少依賴和耦合,對需求變動能夠敏捷響應。咱們想要是網站架構具備可擴展性。開發的低耦合是必要的條件。低耦合的系統更容易擴展,低耦合的模塊更容易服用,一個低耦合的系統設計也會讓開發也會讓開發過程和維護變得更加輕鬆和容易管理。大型網站一般使用分佈式消息隊列下降系統的耦合性。並利用分佈式服務打造可複用的業務平臺。在數據庫的使用上,使用的是支持ColumnFamily結構的NoSQL數據庫,建立表的時候,只須要制定ColumnFamily的名字,無需制定字段,能夠再數據寫入再指定,經過這種方式,數據表能夠包含數百萬的字段,使用應用程序數據結構能夠隨意擴展。而在查詢時,能夠經過指定任意字段的名稱和值進行查詢。測試
一個具備擴展性架構的網站,能夠更快的開發新產品。開發的效率大大的提升。優化
就咱們本身的系統而言,可擴展性的設計主要就是讓每一個文件的所要實現功能單一。即一個文件只負責一個功能。並將它單獨封裝在一個類中。這樣咱們須要什麼功能,直接調用封裝好的類就能夠。不只提升了效率。並且讓咱們的源代碼更加有序。網站