一種告警數據處理方法及裝置與流程
2023-10-05 11:01:24 1
本申請涉及數據處理技術領域，更具體地說，涉及一種告警數據處理方法及裝置。
背景技術：
告警模型用來描述物理或邏輯設備的異常，主要包括故障的位置信息、設備的配置信息、故障的類型、故障維護建議等。
現有技術中一般採用XML可擴展標記語言來進行告警模型的描述。但是，XML語言描述的告警模型存在以下問題：模型體積大並且序列化速度慢，進而降低了利用告警模型進行告警數據處理的效率。
技術實現要素：
有鑑於此，本申請提供了一種告警數據處理方法及裝置，用於解決現有XML語言描述的告警模型存在體積大、序列化速度慢，告警數據處理效率低下的問題。
為了實現上述目的，現提出的方案如下：
一種告警數據處理方法，包括：
接收告警原始數據；
在緩存的告警元資料庫中獲取告警元數據，所述告警元數據為預先對protocol buffer格式定義的描述告警對象的屬性信息的告警模型進行解析後得到的告警元數據；
利用所述告警元數據對所述告警原始數據進行解析處理。
優選地，所述告警模型包括版本信息欄位和描述告警對象的屬性信息的告警對象欄位，該方法還包括：
在確定模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型；
將告警模型中的告警對象欄位解析為告警元數據；
將告警模型的版本信息與所述告警元數據相關聯，並存儲在告警元資料庫中。
優選地，所述在確定模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型，包括：
接收模型存儲伺服器發送的版本變更通知，所述版本變更通知包括用戶上傳的新版本告警模型在模型存儲伺服器中的存儲位置；
訪問所述模型存儲伺服器，獲取所述存儲位置處保存的新版本告警模型；
或，
對所述模型存儲伺服器進行監聽，在監聽到用戶向模型存儲伺服器中上傳了新版本告警模型時，獲取該新版本告警模型。
優選地，所述告警原始數據為攜帶有版本號的告警原始數據，所述在緩存的告警元資料庫中獲取告警元數據，包括：
在告警元資料庫中查找是否存在版本信息與所述告警原始數據的版本號相同的告警元數據，若是，則獲取查找到的告警元數據。
優選地，若在告警元資料庫中未查找到版本信息與所述告警原始數據的版本號相同的告警元數據，該方法還包括：
在告警元資料庫中獲取預先指定版本的告警元數據；
或，
獲取告警元資料庫中最高版本的告警元數據；
則，所述利用所述告警元數據對所述告警原始數據進行解析處理，包括：
按照獲取的告警元數據的解析規則，對所述告警原始數據進行解析，對於所述告警原始數據中無法解析的數據進行丟棄。
一種告警數據處理裝置，包括：
告警原始數據接收單元，用於接收告警原始數據；
告警元數據獲取單元，用於在緩存的告警元資料庫中獲取告警元數據，所述告警元數據為預先對protocol buffer格式定義的描述告警對象的屬性信息的告警模型進行解析後得到的告警元數據；
數據處理單元，用於利用所述告警元數據對所述告警原始數據進行解析處理。
優選地，所述告警模型包括版本信息欄位和描述告警對象的屬性信息的告警對象欄位，該裝置還包括：
新版本模型獲取單元，用於在確定模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型；
元數據解析單元，用於將告警模型中的告警對象欄位解析為告警元數據；
元數據存儲單元，用於將告警模型的版本信息與所述告警元數據相關聯，並存儲在告警元資料庫中。
優選地，所述新版本模型獲取單元包括：
變更通知接收單元，用於接收模型存儲伺服器發送的版本變更通知，所述版本變更通知包括用戶上傳的新版本告警模型在模型存儲伺服器中的存儲位置；
伺服器訪問單元，用於訪問所述模型存儲伺服器，獲取所述存儲位置處保存的新版本告警模型；
伺服器監聽單元，用於對所述模型存儲伺服器進行監聽，在監聽到用戶向模型存儲伺服器中上傳了新版本告警模型時，獲取該新版本告警模型。
優選地，所述告警原始數據為攜帶有版本號的告警原始數據，所述告警元數據獲取單元包括：
第一告警元數據獲取子單元，用於在告警元資料庫中查找是否存在版本信息與所述告警原始數據的版本號相同的告警元數據；
第二告警元數據獲取子單元，用於在所述第一告警元數據獲取子單元查找到版本信息與所述告警原始數據的版本號相同的告警元數據時，獲取查找到的告警元數據。
優選地，所述告警元數據獲取單元還包括：
第三告警元數據獲取子單元，用於在所述第一告警元數據獲取子單元未查找到版本信息與所述告警原始數據的版本號相同的告警元數據時，在告警元資料庫中獲取預先指定版本的告警元數據，或者，獲取告警元資料庫中最高版本的告警元數據；
所述數據處理單元包括：
第一數據處理子單元，用於按照獲取的告警元數據的解析規則，對所述告警原始數據進行解析，對於所述告警原始數據中無法解析的數據進行丟棄。
從上述的技術方案可以看出，本申請實施例提供的告警數據處理方法，利用protocol buffer格式定義了描述告警對象的屬性信息的告警模型，並預先對告警模型進行解析得到告警元數據，存儲在告警元資料庫中，進而在接收到告警原始數據時，讀取告警元數據，利用告警元數據對告警原始數據進行解析處理。相比於xml而言，protocol buffer的信息表示更加緊湊，因此定義的告警模型的體積也會更小。並且，protocol buffer以高效的二進位方式進行存儲，其序列化的速度比xml更快，因此利用protocol buffer格式定義的告警模型解析後得到的元數據進行告警原始數據處理時，其處理效率也更高；同時，本申請中告警模型將版本信息欄位和告警對象的屬性信息分離保存，及內外層結構，模型中內層的告警對象屬性信息支持變更，內層模型變化不影響外層，這樣即實現了根據最新版本告警模型可以解析兼容高低版本的告警原始數據，又保證了告警模型更新的靈活性。
附圖說明
為了更清楚地說明本申請實施例或現有技術中的技術方案，下面將對實施例或現有技術描述中所需要使用的附圖作簡單地介紹，顯而易見地，下面描述中的附圖僅僅是本申請的實施例，對於本領域普通技術人員來講，在不付出創造性勞動的前提下，還可以根據提供的附圖獲得其他的附圖。
圖1為本申請實施例公開的一種告警數據處理方法流程圖；
圖2為本申請實施例公開的另一種告警數據處理方法流程圖；
圖3為本申請實施例公開的又一種告警數據處理方法流程圖；
圖4為本申請實施例公開的一種告警數據處理裝置結構示意圖；
圖5為本申請實施例公開的另一種告警數據處理裝置結構示意圖；
圖6為本申請實施例公開的一種告警元數據獲取單元結構示意圖；
圖7為本申請實施例公開的另一種告警元數據獲取單元結構示意圖；
圖8為本申請實施例公開的一種數據處理單元結構示意圖；
圖9為本申請實施例公開的一種新版本模型獲取單元結構示意圖；
圖10為本申請實施例公開的另一種新版本模型獲取單元結構示意圖。
具體實施方式
下面將結合本申請實施例中的附圖，對本申請實施例中的技術方案進行清楚、完整地描述，顯然，所描述的實施例僅僅是本申請一部分實施例，而不是全部的實施例。基於本申請中的實施例，本領域普通技術人員在沒有做出創造性勞動前提下所獲得的所有其他實施例，都屬於本申請保護的範圍。
首先，我們從應用程式處理告警數據的角度對本申請方案進行介紹，參見圖1，圖1為本申請實施例公開的一種告警數據處理方法流程圖。
如圖1所示，該方法包括：
步驟S100、接收告警原始數據；
具體地，客戶側將告警原始數據上傳給應用程式，告警原始數據為二進位格式描述的告警信息。
步驟S110、在緩存的告警元資料庫中獲取告警元數據；
具體地，應用程式本地緩存有告警元資料庫，用於存儲告警元數據。告警元數據為預先對protocol buffer格式定義的描述告警對象的屬性信息的告警模型進行解析後得到的告警元數據。告警模型包含了描述告警對象的屬性信息的告警對象欄位，屬性信息可以包括多個，如省份、ID等。通過對告警對象欄位進行解析，將其按照規定格式存儲到應用程式中，作為告警元數據。
步驟S120、利用所述告警元數據對所述告警原始數據進行解析處理。
具體地，告警元數據描述了告警對象的屬性信息，利用告警元數據對告警原始數據進行解析處理，最終得到解析後的數據。
本申請實施例提供的告警數據處理方法，利用protocol buffer格式定義了描述告警對象的屬性信息的告警模型，並預先對告警模型進行解析得到告警元數據，存儲在告警元資料庫中，進而在接收到告警原始數據時，讀取告警元數據，利用告警元數據對告警原始數據進行解析處理。相比於xml而言，protocol buffer的信息表示更加緊湊，因此定義的告警模型的體積也會更小。並且，protocol buffer以高效的二進位方式進行存儲，其序列化的速度比xml更快，因此利用protocol buffer格式定義的告警模型解析後得到的元數據進行 告警原始數據處理時，其處理效率也更高。
進一步，告警模型描述的是設備或業務的故障信息，而隨著設備和業務的變化，告警模型中描述告警對象的屬性信息會產生一些變化，例如新增某些屬性信息或刪除某些屬性信息，這就會產生不同版本的告警模型。而在同一套系統中，如果某些設備升級使用新版本告警模型，某些設備沒有升級，仍需要使用舊版本告警模型，這就會存在不同版本告警模型的兼容問題。
為此，本申請通過protocol buffer格式定義的告警模型包括版本信息欄位和描述告警對象的屬性信息的告警對象欄位。參考下述樣例：
上述樣例所示的模型中包含兩個欄位，分別為模型版本信息欄位和屬性 信息欄位。其中，ZipPbAlarm是最外層的模型，通過descVersion描述了屬性信息的版本，以及屬性信息的數據類型為bytes。ProtoAlarmObject為內層的模型，該模型描述了告警對象的屬性信息，這部分支持變更，也即可以在該部分增減屬性信息，內層模型的變動是不會影響到外層模型的。
進一步，用戶在變更了ProtoAlarmObject內層模型中告警對象的屬性信息之後，會對descVersion所描述的屬性信息的版本進行變更，從而生成新版本的模型。用戶生成的模型均可以存儲到模型存儲伺服器中，應用程式可以從模型存儲伺服器中讀取各版本的模型，並解析得到告警元數據及對應版本信息，後續接收到告警原始數據後依據告警原始數據的版本號選取版本信息匹配的告警元數據進行處理。
其中，內層模型可以包括多個告警對象的屬性信息，達到壓縮傳輸的目的。
上述屬性信息描述時使用到的optional欄位表示該欄位為一個可選欄位，對於發送方，在發送消息時可以選擇設置或者不設置該欄位的值；對於接收方，如果能夠識別可選欄位就進行相應的處理，如果無法識別，則忽略該欄位。
用戶在創建了一個新版本的告警模型後，可以將告警模型上傳至模型存儲伺服器中。參見圖2，圖2為本申請實施例公開的另一種告警數據處理方法流程圖。
如圖2所示，該方法包括：
步驟S200、在確定模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型；
具體地，模型存儲伺服器中的告警模型為用戶上傳的，告警模型包括版本信息欄位和描述告警對象的屬性信息的告警對象欄位。
步驟S210、將告警模型中的告警對象欄位解析為告警元數據；
告警對象欄位描述了告警對象的屬性信息，例如告警對象的ID、省份等信息。通過對告警對象欄位進行解析，得到告警元數據，告警元數據為告警對象的屬性信息在應用程式中的名稱。
可選的，告警模型中的告警對象可以是多個，將多個告警對象的屬性信息記錄在同一告警模型中，達到壓縮傳輸的目的。
步驟S220、將告警模型的版本信息與所述告警元數據相關聯，並存儲在告警元資料庫中；
具體地，告警元數據與版本信息對應存儲在應用程式的告警元資料庫中，以便應用程式後續選擇對應版本的告警元數據進行數據處理。
步驟S230、接收攜帶有版本號的告警原始數據；
具體地，客戶側將告警原始數據上傳給應用程式，該告警原始數據攜帶有版本號。版本號用於指明該告警原始數據解析處理時所依賴的告警元數據的版本。
步驟S240、在告警元資料庫中獲取版本信息與所述告警原始數據的版本號相同的告警元數據；
告警元資料庫中存儲了告警元數據及與之關聯的版本信息。應用程式在告警元資料庫中查找是否存在版本信息與所述告警原始數據的版本號相同的告警元數據，如果能夠查找到，則調取查找到的告警元數據。
步驟S250、利用所述告警元數據對所述告警原始數據進行解析處理。
具體地，告警元數據描述了告警對象的屬性信息，利用告警元數據對告警原始數據進行解析處理，最終得到解析後的數據。
本實施例提供的告警數據處理方法中，應用程式在確定模型存儲伺服器中有新版本告警模型時，及時獲取該新版本的告警模型，並解析為告警元數據，同版本號關聯存儲在告警元資料庫中。進而，在接收到攜帶有版本號的告警原始數據時，選取版本信息與該版本號相同的告警元數據，對告警原始數據進行解析處理。按照本實施例的方法，實現了多版本告警模型的兼容。
可選的，上述步驟S200-S220與其餘步驟之間並不存在必然的先後順序，圖2僅僅示例了一種可選方式而已。
可以理解的是，上述步驟S240僅僅介紹了在告警元資料庫中能夠查找到版本信息與告警原始數據的版本號相同的告警元數據的情況。除此之外，如果在告警元資料庫中未查找到版本信息與所述告警原始數據的版本號相同的告警元數據，則可以在告警元資料庫中獲取預先指定版本的告警元數據，或者，獲取告警元資料庫中最高版本的告警元數據，進而按照獲取的告警元數據的解析規則，對告警原始數據進行解析。
這裡需要說明的是，當告警原始數據的版本號與獲取的告警元數據版本不同時，應用程式在利用告警元數據對告警原始數據進行解析時，有可能存在無法解析的數據。而參見上文可知，告警模型中屬性信息在描述時使用了optional欄位，對應屬性信息在解析為告警元數據後，若無法識別某個optional欄位描述的屬性信息時，可以直接忽略，也即直接丟棄該部分數據。實現了不同版本告警模型共存的目的。
在本申請的又一個實施例中，介紹了又一種告警數據處理方法，參見圖3，圖3為本申請實施例公開的又一種告警數據處理方法流程圖。
如圖3所示，該方法包括：
步驟S300、接收模型存儲伺服器發送的版本變更通知；
具體地，所述版本變更通知包括用戶上傳的新版本的告警模型在模型存儲伺服器中的存儲位置。模型存儲伺服器可以在收到用戶上傳的新版本的告警模型時，向應用程式發送版本變更通知。
步驟S310、訪問所述模型存儲伺服器，獲取所述存儲位置處保存的告警模型；
其中，告警模型包括版本信息欄位和描述告警對象的屬性信息的告警對象欄位。
步驟S320、將告警模型中的告警對象欄位解析為告警元數據；
告警對象欄位描述了告警對象的屬性信息，例如告警對象的ID、省份等信息。通過對告警對象欄位進行解析，得到告警元數據，告警元數據為告警對象的屬性信息在應用程式中的名稱。
可選的，告警模型中的告警對象可以是多個，將多個告警對象的屬性信息記錄在同一告警模型中，達到壓縮傳輸的目的。
步驟S330、將告警模型的版本信息與所述告警元數據相關聯，並存儲在告警元資料庫中；
具體地，告警元數據與版本信息對應存儲在應用程式的告警元資料庫中，以便應用程式後續選擇對應版本的告警元數據進行數據處理。
步驟S340、接收攜帶有版本號的告警原始數據；
具體地，客戶側將告警原始數據上傳給應用程式，該告警原始數據攜帶有版本號。版本號用於指明該告警原始數據解析處理時所依賴的告警元數據的版本。
步驟S350、在告警元資料庫中獲取版本信息與所述告警原始數據的版本號相同的告警元數據；
告警元資料庫中存儲了告警元數據及與之關聯的版本信息。進而，查詢與所述告警原始數據的版本號相同的版本信息，調取該版本信息的告警元數據。
步驟S360、利用所述告警元數據對所述告警原始數據進行解析處理。
具體地，告警元數據描述了告警對象的屬性信息，利用告警元數據對告警原始數據進行解析處理，最終得到解析後的數據。
本實施例中提供了一種獲取模型存儲伺服器中存儲的新版本告警模型的可選方式，具體為由模型存儲伺服器在收到新版本告警模型時主動向應用程式發送版本變更通知，由應用程式主動從模型存儲伺服器中獲取新版本的告警模型。
當然，除此之外還可以存在其它可選方式，例如在模型存儲伺服器中設置監聽接口，當監聽到用戶向模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型。
下面對本申請實施例提供的告警數據處理裝置進行描述，下文描述的告警數據處理裝置與上文描述的告警數據處理方法可相互對應參照。
參見圖4，圖4為本申請實施例公開的一種告警數據處理裝置結構示意圖。
如圖4所示，該裝置包括：
告警原始數據接收單元41，用於接收告警原始數據；
具體地，告警原始數據接收單元41接收客戶側上傳的告警原始數據，告警原始數據為二進位格式描述的告警信息。
告警元數據獲取單元42，用於在緩存的告警元資料庫中獲取告警元數據，所述告警元數據為預先對protocol buffer格式定義的描述告警對象的屬性信息的告警模型進行解析後得到的告警元數據；
具體地，告警元資料庫預先獲取定義好的告警模型，該告警模型為protocol buffer格式定義的描述告警對象的屬性信息的告警模型。告警元資料庫在獲取到告警模型後對告警模型進行解析，得到告警元數據，存儲到告警元資料庫中。
數據處理單元43，用於利用所述告警元數據對所述告警原始數據進行解析處理。
告警元數據描述了告警對象的屬性信息，利用告警元數據對告警原始數據進行解析處理，得到解析後的數據。
本申請實施例提供的告警數據處理裝置，利用protocol buffer格式定義了描述告警對象的屬性信息的告警模型，並預先對告警模型進行解析得到告警元數據，存儲在告警元資料庫中，進而在接收到告警原始數據時，讀取告警元數據，利用告警元數據對告警原始數據進行解析處理。相比於xml而言，protocol buffer的信息表示更加緊湊，因此定義的告警模型的體積也會更小。並且，protocol buffer以高效的二進位方式進行存儲，其序列化的速度比xml更快，因此利用protocol buffer格式定義的告警模型解析後得到的元數據進行告警原始數據處理時，其處理效率也更高。
可選的，用戶定義好的告警模型可以存儲在模型存儲伺服器中，進而通過模型存儲伺服器與告警元資料庫進行溝通，將告警模型傳輸給告警元資料庫。
可選的，所述告警模型可以包括版本信息欄位和描述告警對象的屬性信息的告警對象欄位，則結合圖4和圖5可知，該裝置還可以包括：
新版本模型獲取單元45，用於在確定模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型；
具體地，用戶將編輯好的新版本的告警模型上傳到模型存儲伺服器中。新版本模型獲取單元45在確定模型存儲伺服器中上傳了新版本的告警模型時，可以從模型存儲伺服器中獲取該新版本的告警模型。
元數據解析單元46，用於將告警模型中的告警對象欄位解析為告警元數據；
告警對象欄位描述了告警對象的屬性信息，例如告警對象的ID、省份等信息。通過對告警對象欄位進行解析，得到告警元數據，告警元數據為告警對象的屬性信息在應用程式中的名稱。
元數據存儲單元47，用於將告警模型的版本信息與所述告警元數據相關聯，並存儲在告警元資料庫中。
具體地，告警元數據與版本信息對應存儲在應用程式的告警元資料庫中，以便應用程式後續選擇對應版本的告警元數據進行數據處理。
進一步可選的，所述告警原始數據可以攜帶有版本號，則參照圖6所示，所述告警元數據獲取單元42可以包括：
第一告警元數據獲取子單元421，用於在告警元資料庫中查找是否存在版本信息與所述告警原始數據的版本號相同的告警元數據；
具體地，在接收到告警原始數據之後，確定該告警原始數據的版本號。進而在告警元資料庫中查找是否存在相同版本號的告警元數據。
第二告警元數據獲取子單元422，用於在所述第一告警元數據獲取子單元421查找到版本信息與所述告警原始數據的版本號相同的告警元數據時，獲取查找到的告警元數據。
如果確定第一告警元數據獲取子單元421找到了相同版本號的告警元數據，則獲取該查找到的告警元數據，以便利用相同版本號的告警元數據對告警原始數據進行解析處理。
進一步，結合圖6和圖7可知，告警元數據獲取單元42還可以進一步包括：
第三告警元數據獲取子單元423，用於在所述第一告警元數據獲取子單元421未查找到版本信息與所述告警原始數據的版本號相同的告警元數據時，在告警元資料庫中獲取預先指定版本的告警元數據，或者，獲取告警元資料庫中最高版本的告警元數據。
可以理解的是，如果告警原始數據的版本號太高，在告警元資料庫中不存在相同版本的告警元數據時，則可以查找預先指定版本的告警元數據，或者查找告警元資料庫中最高版本的告警元數據，獲取查找到的告警元數據。
在此基礎上，如圖8所示，所述數據處理單元43可以包括：
第一數據處理子單元431，用於按照獲取的告警元數據的解析規則，對所述告警原始數據進行解析，對於所述告警原始數據中無法解析的數據進行丟棄。
具體地，參見上文相關介紹，告警模型中屬性信息在描述時使用了optional欄位，optional表示該欄位為一個可選欄位，optional欄位描述的屬性信息在解析為告警元數據後，若無法識別某個optional欄位描述的屬性信息時，可以直接忽略，也即直接丟棄該部分數據。實現了不同版本告警模型共存的目的。
可選的，本申請提供了兩種獲取模型存儲伺服器中存儲的新版本告警模型的可選方式，分別參照圖9和圖10所示。
如圖9所示，所述新版本模型獲取單元45可以包括：
變更通知接收單元451，用於接收模型存儲伺服器發送的版本變更通知，所述版本變更通知包括用戶上傳的新版本的告警模型在模型存儲伺服器中的存儲位置；
模型存儲伺服器可以在收到用戶上傳的新版本的告警模型時，向應用程式發送版本變更通知，由應用程式中的變更通知接收單元451進行接收。
伺服器訪問單元452，用於訪問所述模型存儲伺服器，獲取所述存儲位置處保存的告警模型。
伺服器訪問單元452在確定變更通知接收單元451收到了版本變更通知後，訪問模型存儲伺服器，並且參考版本變更通知中的存儲位置，在模型存儲伺服器中獲取所述存儲位置處保存的新版本告警模型。
如圖10所示，所述新版本模型獲取單元45可以包括：
伺服器監聽單元453，用於對所述模型存儲伺服器進行監聽，在監聽到用戶向模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型。
圖9示例的新版本模型獲取單元是依靠模型存儲伺服器向應用程式發送版本變更通知，進而訪問模型存儲伺服器獲取相應的新版本告警模型。本實施例圖10示例的新版本模型獲取單元在模型存儲伺服器中設置有監聽線程，在監聽到用戶向模型存儲伺服器中上傳了新版本的告警模型時，獲取該新版本的告警模型。
當然，上述變更通知接收單元451、伺服器訪問單元452和伺服器監聽單 元453可以整合到一個新版本模型獲取單元之中。
最後，還需要說明的是，在本文中，諸如第一和第二等之類的關係術語僅僅用來將一個實體或者操作與另一個實體或操作區分開來，而不一定要求或者暗示這些實體或操作之間存在任何這種實際的關係或者順序。而且，術語「包括」、「包含」或者其任何其他變體意在涵蓋非排他性的包含，從而使得包括一系列要素的過程、方法、物品或者設備不僅包括那些要素，而且還包括沒有明確列出的其他要素，或者是還包括為這種過程、方法、物品或者設備所固有的要素。在沒有更多限制的情況下，由語句「包括一個……」限定的要素，並不排除在包括所述要素的過程、方法、物品或者設備中還存在另外的相同要素。
本說明書中各個實施例採用遞進的方式描述，每個實施例重點說明的都是與其他實施例的不同之處，各個實施例之間相同相似部分互相參見即可。
對所公開的實施例的上述說明，使本領域專業技術人員能夠實現或使用本申請。對這些實施例的多種修改對本領域的專業技術人員來說將是顯而易見的，本文中所定義的一般原理可以在不脫離本申請的精神或範圍的情況下，在其它實施例中實現。因此，本申請將不會被限制於本文所示的這些實施例，而是要符合與本文所公開的原理和新穎特點相一致的最寬的範圍。