<menu id="guoca"></menu>
<nav id="guoca"></nav><xmp id="guoca">
  • <xmp id="guoca">
  • <nav id="guoca"><code id="guoca"></code></nav>
  • <nav id="guoca"><code id="guoca"></code></nav>

    信息技術服務管理工具數據交互消息處理機制

    B.1概述

    B.1.1框架

    本機制的技術要求提供了一個開放式框架,能夠有效支撐4.3規定的三個管理域之間實現可靠高效的數據交互的需求。本框架為各管理工具對外提供自身數據共享服務和從外部獲取數據服務,規定了詳細的數據生產、數據消費和數據交互管理機制,包括了相關的數據定義、方法定義和組件協作機制定義。

    信息技術服務管理工具數據交互消息處理機制

    B.1.2總體要求

    工具間的數據交互消息機制應遵循如下總體要求:

    a)數據交互主體應通過消息機制實現數據交互。

    b)監控管理作為數據生產者提供的數據應包含:

    1)配置數據;

    2)對象告警數據;

    3)性能數據。

    c)監控管理作為數據消費者獲得的數據應包含:

    配置過程管理對監控對象形成的配置項屬性數據。

    d)過程管理作為數據生產者提供的數據應包含:

    1)事件管理數據;

    2)問題管理數據;

    3)變更管理數據;

    4)發布管理數據;

    5)配置管理數據;

    6)服務級別管理數據;

    7)服務臺管理數據;

    8)容量管理數據;

    9)業務關系管理數據。

    e)過程管理作為數據生產者提供的數據宜包含:

    1)可用性管理數據;

    2)連續性管理數據;

    3)服務報告管理數據;

    4)信息安全管理數據;

    5)預算與核算管理數據。

    f)過程管理作為數據生產者提供的數據可包含:

    1)知識管理數據;

    2)供應商管理數據;

    3)任務管理數據。

    g)過程管理作為數據消費者獲得的數據應包含:

    1)監控管理生產的配置數據、告警數據和性能數據;

    2)決策支撐生產的各項決策數據。

    h)決策支撐作為數據生產者提供的數據應包含:

    1)服務運營水平分析數據;

    2)服務運營要素分析數據。

    i)決策支撐作為數據消費者獲得的數據應包含:

    1)監控管理生產的對象管理數據,包括對象的配置、告警和性能數據;

    2)過程管理生產的各項狀態和屬性數據。

    j)信息技術服務管理工具應遵循本規范實現與其他工具的管理數據共享;

    k)消息機制的實現應保證所傳遞數據的可靠、完整和一致;

    l)消息機制的實現應當考慮安全措施,如采用認證授權、加密傳輸等方式完成數據交互。

    B.2要求

    B.2.1消息數據格式

    工具間實現消息傳遞,其數據格式的確定應遵循如下技術要求:

    a)信息技術服務管理工具的消息數據格式應支持信息技術服務管理所需的多種交互數據,包括:

    1)告警數據;

    2)性能數據;

    3)配置數據;

    4)服務過程數據;

    5)服務決策支撐數據。

    b)數據交互的消息處理機制采用消息主題數據結構實現對B.2.1a)中羅列的各類信息技術服務交互數據的分類支持。

    c)對于復雜的多字段數據對象,如性能數據、配置數據、服務過程數據和服務決策支撐數據,應采用數據模式對數據字段的鍵和值,以及數據字段的數據類型進行描述。

    示例:舉一個網絡交換機“CPU利用率”性能數據對象的數據模式描述的例子。

    {“namespace”:“switch Performance.app”,
    “type”:“record”.
    “code”:“0101021”,
    “name”:“cpu Usage”,
    “fields”:[
        {“name”:“switch ID”, “type”:“string”, “desc”:”交換機標識”}{“name”:“cpuID”, “type”:“int”, “desc”:“中央處理器標識”}{“name”:“timeStamp”, “type”:“double”, ”dese”:“時戳”}{“name”:“usage”, “type”:“int”, ”dese”:“利用率數據”}
    ]
    }

    B.2.2數據模式注冊機制

    消息機制中的生產者與消費者之間的交互為松耦合模式,數據格式問題成為互聯互通的核心問題之一,本部分要求采用數據模式注冊表機制解決數據格式識別與協商問題,其技術要求如下:

    a)所有描述數據對象格式的數據模式應通過模式注冊表機制面向其應用范圍發布;

    b)注冊表管理機構應維護每一個消息主題所有已注冊數據模式的版本信息;

    c)注冊表應提供一個RESTful接口以支持對數據模式的訪問;

    d)應為每一個數據模式版本分配一個模式標識;

    e)生產者使用數據模式注冊機制向消息服務器發送記錄時,應發送模式標識和記錄內容,消息服務器的序列化器從數據模式注冊表中查詢對應的數據模式詳細信息,并按照數據模式內容完成消息數據記錄的序列化;

    f)消費者應使用模式標識讀取從消息主題中獲取的記錄內容,消息服務器應使用模式標識從數據模式注冊表中獲取數據模式詳細信息,并按照數據模式內容完成消息數據的解序列化。

    B.2.3數據生產機制

    數據生產機制用于保證多數據源在消息架構上實現數據消息的寫入、發布與網絡傳輸,組件如圖B.2所示,技術要求如下:

    a)應創建使用消息架構的生產者對象實例;

    b)生產者對象應包含消息主題和要發送的數據內容;

    c)應使用對象序列化處理將數據內容的鍵和值對象轉變成為易于網絡傳輸的數據結構;

    d)應使用B.2.1和B.2.2描述的數據模式和模式注冊表機制提升對象序列化處理的易用性和標準化;

    e)對象序列化處理可采用成熟的序列化框架實現, 如JSON, Avro, Thrift或Proto buf等, 或是在這些成熟框架上通過二次開發形成自定義序列化器;

    f)應通過數據分區技術實現同一個消息主題下數據的分布式處理能力;

    h)消息機制應支持同步發送、異步發送和發送并忘記這三種不同的消息發送機制;

    i)應支持配置多種參數控制數據生產機制的行為,如:內存緩沖區大小、消息隊列容量、消息重發次數等。

    信息技術服務管理工具數據交互消息處理機制

    B.2.4數據消費機制

    數據消費機制用于支持從消息框架中接收消息、獲取數據,其技術要求如下:

    a)應支持數據消費者訂閱消息主題;

    b)應支持消費者群組對象,實現多個數據消費者從同一個主題獲取消息數據的模式;

    c)數據消費者訂閱消息主題的行為應包括加入該主題對應的消費者群組,輪詢獲取消息數據,通過心跳發送與監測技術維持其與群組的從屬關系以及消費者對分區的所有權關系等;

    d)應支持一個數據消費者群組對象僅對應一個消息主題;

    e)應支持一個消息主題可對應多個數據消費者群組對象;

    f)一個數據消費者群組的消費者數量宜等于或少于對應消息主題的分區數量;

    g)應支持消費者在訂閱一個主題后取得對主題中一個或多個分區的所有權;

    h)應支持群組協調器機制來維護一個消費者群組對象的穩定運行和異常處理;

    i)消費者應通過向消息機制提交所處理記錄在主題分區中的偏移量的方式,來保證其數據處理的有效性;

    j)應支持使用偏移量的同步提交、異步提交和同步異步組合提交模式;

    k)應支持使用解序列化技術實現消費者對消息框架中序列化的數據記錄進行處理,以獲得元數據;

    I)應使用B.2.1和B.2.2描述的數據模式和模式注冊表機制提升解序列化處理的易用性和標準化。

    B.2.5數據交互管理機制

    B.2.5.1復制管理

    復制管理為消息框架提供了在個別節點失效時保證框架可用性和持久性的機制,其技術要求如下:

    a)應為每個分區提供多個數據副本;

    b)數據副本應支持領導副本和追隨者副本,數據讀寫發生在領導副本上,追隨者副本保證與領導副本實現內容同步,當領導副本發生異常,從追隨者副本中選擇一個成為新的領導副本;

    c)應提供機制實現領導副本驗證追隨者副本是否實現了內容同步;

    d)宜支持分區建立時確定的領導副本成為首選領導,當首選領導副本保持同步時,宜觸發領導副本選舉,讓首選領導成為當前領導。

    B.2.5.2請求處理

    消息框架的工作核心是處理客戶端、分區副本和消息控制器發送給分區領導副本的請求,這些請求處理的技術要求如下:

    a)應明確請求消息的類型和格式;

    b)應定義消息框架對請求作出響應的方式,包括處理請求成功和遇到錯誤時的行為;

    c)消息框架應按照請求到達的順序進行處理;

    d)應支持處理多種請求,如元數據請求、生產請求、獲取請求等;

    e)消息框架的客戶端應通過元數據請求獲取該客戶端感興趣的主題列表、主題分區信息、分區副本信息,以及分區的領導副本信息;

    f)消息框架實例收到生產請求時,應當進行根據請求中攜帶的參數,將請求數據寫人分區領導副本,并根據請求參數,確定返回響應的模式;

    g)消息框架實例收到獲取請求時,應當進行根據請求中攜帶的參數,將從分區領導副本中獲取制定消息,并根據請求參數,確定返回響應的模式。

    B.2.5.3存儲管理

    消息框架的基本存儲單元是分區,技術要求如下:

    a)分區分配

    1)創建消息主題時,應定義該主題的分區分配機制,如在分布式系統間平均分布分區的副本、確保每個分區的每個副本分布于通過的消息框架實例等要求;

    2)應當為分區和副本分配所使用的文件系統目錄。

    b)文件管理

    1)應設定消息數據的保留期限;

    2)應提供機制限制每一個數據文件的大小;

    3)應提供當前數據文件的可靠性保證機制;

    4)分區所在操作系統應針對打開的文件句柄數量提供優化機制。

    c)索引管理

    1)應為每個分區維護一個索引,索引能夠把消息記錄的偏移量映射到實際的數據文件和偏移量在文件里的位置;

    2)應提供機制限制每一個索引文件的大小;

    3)消息框架應支持自動重新生成索引。

    本文章首發在 網安wangan.com 網站上。

    上一篇 下一篇
    討論數量: 0
    只看當前版本


    暫無話題~
    亚洲 欧美 自拍 唯美 另类