《XXX重大技術需求徵集系統》的可用性和可修改性戰術分析

在網站的界面完整有效的呈如今最終用戶面前前，其中經歷的每一環節出現問題都會致使網站頁面不可訪問。緣由如，如DNS被劫持、網站交換機失效，硬盤損壞，網卡鬆掉，機房停電等均可能致使網站不可用(網站故障)狀況出現。一般用多少個9來度量網站可用性，如QQ可用性99.99%，就意味着在一年中約有53分鐘是不可用的。對於多數網站2個9是最基本的要求，即一年中要求不可用時間得小於88個小時。考覈可用性一般用故障分類加權計算而得。具體參照「網站故障分類權重表示例」表。

可用性的做用是顯而易見的，在上學期製做的XXX重大技術需求徵集系統中，當應對快速增加的用戶數量，以及業務數量是，並不能很好的應對，甚至是處理能力很低。當應對這樣的狀況，也會發生數據丟失，服務不可用的狀況，因此個人網站可用性是很低了。在預防數據丟失方面，能夠在數據寫入是同時進行復制同步將數據寫入多臺服務器實現冗餘備份，固然目前實現是有困難的。

高可用性，一方面須要較高配置的軟硬件設備如服務器、操做系統等，不一樣的產品部署到不一樣的服務集羣上、互不相干，一些可複用的業務服務也各自部署在獨立的服務集羣上，這樣實現高可用性，使得軟件負載均衡，發現服務異常時會剔除掉不可用服務器。另外一方面也須要有數據和服務的冗餘備份和失效轉移技術方面，在個人系統中並無考慮數據備份相關問題，因此若是直接投入使用，用戶定會丟失數據；在另外一方面我使用的是jsp+servlet的mvc模式，各層之間具備至關的獨立性，可是同時在項目的中後期我發現本身的dao層顯得有些許混亂，每一個函數劃分得不夠精確，結構顯得複雜。閱讀過程當中，發現大型網站架構劃分的粒度會更小、更詳細，一樣結構也會更復雜，因此我認爲以後的練習過程當中，應當嚴格要求本身多作一點多想一點。

在第一個方面，經過負載均衡使流量和數據分攤到一個集羣的多臺服務器上提升總體的負載處理能力，來處理服務無狀態時的狀況。如一個服務集羣上的服務器均可用時，負載均衡服務器會將用戶發送的訪問請求發送到任意一個服務器上進行處理，當一個服務器發生宕機時，負載均衡服務器會經過心臟檢測機制發現這臺服務器已經失去了響應，則把它從服務器列表中剔除，將請求發送給別的服務器，這些服務器是徹底同樣的，發送給任何一臺都不會影響結果。而在業務有狀態時，使用服務器集羣的SESSION管理。1.session複製，我認爲和數據冗餘備份同樣，將session信息複製同步到集羣中的幾臺服務器中，可是不足之處當集羣規模較大時，大量複製會致使佔用資源，這就顯得不夠優秀哦。2. session綁定，我認爲就像學校郵件處理室同樣，信息學院想要的信件就放在信息院櫃中；負載均衡服務器將源於同一IP的請求分發到同一臺服務器上，這樣用戶的全部請求都在這臺服務器上處理，保證了session總能在這臺服務器上獲取。可是若是信息院櫃子滿了或者壞了，信息院信件就會找不到，一樣，若是該服務器發生宕機，該服務器上的session也就不存在了，仍是不夠優秀哦。3.利用cookie記錄session，在網站中利用瀏覽器支持的cookie記錄session，雖然在信息量和性能方面不優秀可是簡單易用，也能使用。

前3個辦法中，個人系統中關於服務器的每個有，因此性能！！很不可觀！！惟有cookie這個方便簡單，仍是有的。基於上面的不完美，閱讀得知，session服務器能夠達到對信息量大小和延展性等方面都不錯的管理。第一種session複製不能處理有狀態時的狀況，因此如今將服務器狀態分離，分爲有狀態和無狀態。第二個方面，保護網站數據。經過保證數據備份和失效轉移機制，即失效轉移機制，保證數據有多個備份，任意副本丟失失效都不會致使數據永久都是，實現數據的徹底持久化。

 

------------------------分割線----------------------

今天進行了答辯，針對個人系統，有以下分析：

 

六大屬性：安全性，可修改性，可測試性，易用性，安全性，性能

 

一 可用性--指的是應對故障和相關後果

錯誤被人看到時就升級爲故障，引出修復時間--錯誤發生到用戶看不到故障前的糾正錯誤的時間。

戰術：從源頭上預防錯誤，錯誤一發生就被檢測到，檢測到就立刻去進行錯誤恢復。

舉例：

1.try-catch機制，避免錯誤被檢測

 

二 可修改性--指的是進行變動所帶來的成本問題

主要討論2個方面  有誰來進行什麼樣的變動

戰術：減小變動直接影響到的模塊數量---局部化修改，限制變動模塊---防止連鎖反應。

舉例：

1.鏈接數據庫的方法--減小變動代價--局部化修改中的泛化該模塊，經過輸入參數來通用   2.MVC模式--減小各部分之間的依賴關係--局部化修改--維持語義的一致性

 

三 性能--指的是當源達到必定數量時的響應，一般用時間來衡量

戰術：1.環境上資源的消耗如CPU/內存/寬帶  2.對資源爭用或等依賴的事件

舉例：

1.審覈成功的報表不能進行修改----閉鎖時間--依賴於一個結果致使不可用某個資源

2.未實現~~~~~如限制上限人數，加大內存等

3.緩存器/排隊

 

四 安全性--指的是1.提供合法用戶的服務 2.非受權操做

安全性指的是承認、機密性、完整性和正確性

戰術：因爲主動讓攻擊不進行，因此在抵抗攻擊，檢測攻擊和從攻擊中恢復三個方面

抵抗攻擊---防護：如用戶密碼加密，身份驗證，受權，重要數據加密，維護數據完整性(備

份），限制暴露信息，限制訪問

舉例：

1.用戶未登陸限制行爲   2.用戶密碼MD5加密   3不一樣角色/用戶受權不一樣行爲

 

五 可測試性--指的是經過測試發現缺陷的容易度

目的是容許開發了一個增量後，可輕鬆的進行軟件測試

戰術：1.輸入輸出（記錄回放   將接口與實現分離   特化訪問路線/接口）  2.內部監視器

舉例：

1.在dao與servlet的調用之間使用多個print輸出傳遞和接收的數據---記錄/回放--捕獲跨接口的信息

 

六易用性--對用戶來講 1.主動完成任務的難易度  2.系統所提供的用戶的種類

戰術：

使用時-從用戶使用來看系統幫助用戶處理事務，如用戶模型（抓住用戶特色信息，如看書速度滾動），系統模型（基於系統信息，肯定了指望的系統行爲給用戶反饋），任務模型（試圖經過一個任務上下文，肯定用戶想要作什麼）

設計時-從開發人員來看不但願在修改內部時不但願還要改變用戶界面---分離用戶接口和應用部分（模型-視圖-控制器 / 表示層-抽象層-控制）

舉例：

1.用戶填寫時自動獲取幾個基本信息--用戶模型

2.提示用戶填報規則----便於完成填報

3.填寫取消---支持用戶主動