重構信息領域熱詞分析

 

1可用性

可用性與系統故障及其相關後果有關。當系統不再提供其規範中所說明的服務時,就出現了系統故障。

所關注的方面有:

(1)如何檢測系統故障

(2)系統故障發生的頻度

(3)出現故障時會發生什麼情況

(4)允許系統有多長時間非正常運行

(5)什麼時候可以安全地出現故障

(6)如何防止故障的發生以及故障時要求進行哪種通知

一般將系統可用性定義爲:可用性在ISO9241/11中的定義是:一個產品可以被特定的用戶在特定的境況中,有效、高效並且滿意得達成特定目標的程度。

維持可用性的方法包括:

(1)錯誤檢測——用來檢測故障的某種類型的健康監視,包括我們在系統運行中可能出現一些未知錯誤,造成的數據庫丟失等問題;

(2)未能鏈接服務器:通過URL測試服務器是否可連接(服務是否開啓,網絡問題),提示錯誤信息,人工檢測服務開啓狀態

(3)未能鏈接數據庫服務:利用java的異常處理機制檢測Driver正常連接,並提示錯誤信息,建立自定義的異常類, 根據錯誤信息人工檢測服務開啓狀況

(4)自動恢復——檢測到故障時某種類型的恢復;

(5)錯誤預防——阻止錯誤演變爲故障

在去除服務器維護時間以外,基本可以保證每天24小時均是可用。服務器的維護時間,每次維護從檢測到服務器故障到服務重啓進行正常提供服務。滿足可用性的要求。

可用性戰術。可用性戰術的目標是阻止錯誤發展成故障,至少能夠把錯誤的影響限制在一定範圍內,從而使修復成爲可能。戰術分爲:錯誤檢測、錯誤恢復、錯誤預防。

① 錯誤檢測

命令/響應:一個構件發出一個命令,並希望在預定義的時間內收到一個來自審查構件的響應,例如遠程錯誤的檢測。

心跳(計時器):一個構件定期發出一個心跳消息,另一個構件收聽到消息,如果未收到心跳消息,則假定構件失敗,並通知錯誤糾正構件。

異常:當出現異常時,異常處理程序開發執行。

② 錯誤恢復

表決:通過冗餘構件(或處理器)與表決器連接,構件按相同的輸入及算法計算輸出值交給表決器,由表決器按表決算法(如多數規則)確定是否有構件出錯,表決通常用在控制系統中。

主動冗餘(熱重啓、熱備份):所有的冗餘構件都以並行的方式對事件做出響應。它們都處在相同的狀態,但僅使用一個構件的響應,丟棄其餘構件的響應。錯誤發生時通過切換的方式使用另一個構件的響應。

被動冗餘(曖重啓/雙冗餘/三冗餘):一個構件(主構件)對事件做出響應,並通知其他構件(備用的)必須進行的狀態更新(同步)。當錯誤發生時,備用構件從最新同步點接替主構件的工作。

備件:備件是計算平臺配置用於更換各種不同的故障構件。

狀態再同步:主動和被動冗餘戰術要求所恢復的構件在重新提供服務前更新其狀態。更新方法取決於可以承受的停機時間、更新的規模及更新的內容多少。

檢查點/回滾:檢查點就是使狀態一致的同步點,它或者是定期進行,或者是對具體事件做出響應。當在兩檢查點之間發生故障時,則以這個一致狀態的檢查點(有快照)和之後發生的事務日誌來恢復系統(數據庫中常使用)。

③ 錯誤預防

從服務中刪除:如刪除進程再重新啓動,以防止內存泄露導致故障的發生。

事務:使用事務來保證數據的一致性,即幾個相關密切的步驟,要麼全成功,要麼都不成功。

進程監視器:通過監視進程來處理進程的錯誤。

 

try {

        Class.forName("com.mysql.jdbc.Driver");

        conn = DriverManager.getConnection(db_url, db_user, db_password);

    } catch (Exception e) {

        e.printStackTrace();

    }

利用報警函數對系統運行進行監控

2可修改性

可修改性戰術:包括局部化修改、防止連鎖反應、推遲綁定時間。

(1)局部化修改:在設計期間爲模塊分配責任,以便把預期的變更限制在一定的範圍內,從而降低修改的成本。

維持語義的一致性:語義的一致性指的是模塊中責任之間的關係,使這些責任能夠協同工作,不需要過多地依賴其他模塊。耦合和內聚指標反映一致性,應該根據一組預期的變更來度量語義一致性。使用“抽象通用服務”(如應用框架的使用和其他中間軟件的使用)來支持可修改性是其子戰術。

預期期望的變更:通過對變更的預估,進行預設、準備,從而使變更的影響最小。

泛化該模塊:使一個模塊更通用、更廣泛的功能。

限制可能的選擇:如在更換某一模塊(如處理器)時,限制爲相同家族的成員。

(2)防止連鎖反應:由於模塊之間有各種依賴性,因此,修改會產生連鎖反應。

(3)推遲綁定時間:系統具備在運行時進行綁定並允許非開發人員進行修改(配置)。

運行時註冊:支持即插即用。

配置文件:在啓動時設置參數。

多態:在方法調用的後期綁定。

構件更換:允許載入時綁定。

3性能

 

3.1性能戰術:性能與時間相關,影響事件的響應時間有兩個基本因素。

性能的戰術有如下幾種。

(1)資源需求::減少處理事件流所需的資源:提高計算效率(如改進算法)、減少計算開銷(如在可修改性與性能之間權衡,減少不必要的代理構件)。

(2)減少所處理事件的數量:管理事件率、控制採樣頻率。

(3)控制資源的使用:限制執行時間(如減少迭代次數)、限制隊列大小。

在熱詞展示一頁,爬取到的熱詞能夠達到秒級的相應

 

熱詞目錄自動生成,速度更快

 

 4安全性

 

5.可測試性

可測試性戰術:包括輸入/輸出和內部監控。

測試連接數據庫,並監控狀態

public class DBUtil {

    public  static  Connection getConnection() {

        try {

            Class.forName("com.mysql.jdbc.Driver").newInstance();

        } catch (InstantiationException | IllegalAccessException | ClassNotFoundException e) {

            e.printStackTrace();

  }

        String user = "root";

        String password = "root";

        String url = "jdbc:mysql://localhost:3306/pachong";

        Connection connection = null;

        try {

             connection = DriverManager.getConnection(url,user,password);

             System.out.println("ok");

        } catch (SQLException e) {

            e.printStackTrace();

        }

        return connection;

    }

public static void close(Connection connection ) {

        try {

            if (connection != null) {

                connection.close();

            }

        } catch (SQLException e) {

            e.printStackTrace();

        }

    }

public static void close(PreparedStatement preparedStatement ) {

        try {

            if (preparedStatement != null) {

                preparedStatement.close();

            }

        } catch (SQLException e) {

                  e.printStackTrace();

        }

    }

    public static void close(ResultSet resultSet ) {

        try {

            if (resultSet != null) {

                resultSet.close();

            }

        } catch (SQLException e) {

            e.printStackTrace();

        }

    }

6.易用性

易用性戰術:包括運行時戰術、設計時戰術和支持用戶主動操作。

(1)運行時戰術:任務的模型:維護任務的信息,使系統瞭解用戶試圖做什麼,並提供各種協助;

(2)設計時戰術:將用戶接口與應用的其餘部分分離開來,預計用戶接口會頻繁發生變化,因此,單獨維護用戶接口代碼將實現變更局部化。這與可修改性相關。

點擊目錄能自動爬取熱詞

 

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章