視頻管理軟件技術分析報告(四)--基于SOA的VMS軟件架構設計

1. 設計原則

??VMS系統的開放性和擴展性特性非常適合使用SOA（面向服務的架構）方法來進行設計。
??服務作為物理上獨立無關的軟件程序而存在，每個服務被賦予其自身獨特的功能上下文環境，并由一系列與該環境相關的能力所組成。服務提供的能力通過服務接口（服務合約）來表達。
??根據服務的可復用性，可編排性，可自治，可組合性等特點，在設計服務時宜使用自頂向下的設計思路，在設計模型時可先設計頂層的服務，確定頂層的服務邊界后，再逐層設計下層的子服務。
??在服務類型上，宜將服務分為實體服務，任務服務，工具服務三種類型 。
??VMS中涉及到媒體、元數據、系統管理數據（用戶，權限）等實體的服務可歸類為實體服務；媒體會話，任務調度之類與控制器相關的服務可歸類于任務服務；網絡傳輸，安全加密，日志等基礎服務可歸類于工具服務。
??使用實體服務，任務服務，工具服務三種服務模型可構建邏輯服務抽象層，如圖 1所示。

2. VMS的服務設計

??使用SOA進行VMS的設計應首先聚焦于視頻監控系統的業務。以視頻數據為核心，一個視頻監控系統的基礎結構如圖 2所示：

??ONVIF作為基于Web service技術標準制定的安防設備開放操作接口，囊括了圖 2中包含的所有功能。其服務設計思想可作為VMS設計時的參考。
??分析一下ONVIF定義的服務，可歸為如下幾類：

• 設備管理服務（包含設備IO服務）：是ONVIF中定義的核心服務，對設備進行設備參數，設備狀態等信息的管理和配置。通過設備管理服務能夠獲取其它服務的地址。
• 媒體服務：提供對媒體設備相關元數據（視頻源、視頻參數等）的配置查詢功能。使用媒體服務能夠獲取視頻流的相關參數。
• 設備操控服務：ONVIF中主要提供了PTZ服務，用于完成對采集攝像設備的操控。
• 錄像服務：主要包括錄像控制和錄像查詢服務。
• 錄像回放服務：主要定義了錄像回放的相關參數的查詢與配置。
• 門禁服務：定義了門禁控制的相關操作。
• 視頻分析服務：定義了視頻分析的基礎模型與相關服務接口。
• 流服務：定義視音頻媒體、元數據流的控制協議，傳輸協議和交換方式。
  ??參考圖 2與ONVIF的服務模型，遵循第1節介紹的設計原則和思路，以視頻流的流動路徑為方向，相關的服務邊界與互操作關系可如圖 3所示。
  
  ??圖 3中，任務服務層與實體服務層定義的主要服務描述如下：
• 設備接入（發現與注冊）：實現物理設備的發現與注冊，使用與物理設備兼容的協議（方式）實現與物理設備的直接互聯，是物理設備的實際操作者。
• 設備管理：實現設備參數及其它系統數據的配置和查詢，與設備接入服務是雙向互操作的關系。
• 媒體配置：用于實現對于媒體設備（如攝像機與DVR）的媒體相關參數的配置與查詢，與設備管理服務是雙向互操作關系。
• 實時媒體流會話控制：實現與媒體設備的媒體會話控制，獲取媒體設備的實時媒體流數據并實現分發。媒體流會話控制服務在使用時會調用媒體配置和設備管理服務以獲取相關參數。
• 錄像：實現根據媒體流進行錄像的功能。錄像服務可根據錄像計劃進行錄像，也可根據用戶操作進行隨機錄像，同時錄像服務也提供錄像查詢功能。錄像服務需要調用媒體配置和設備管理服務獲取相關參數，調用媒體流會話控制服務獲取媒體流。
• 實時流瀏覽：提供實時監控功能，需要調用媒體流會話控制服務獲取實時媒體流。
• 錄像回放：錄像回放服務可調用錄像服務查詢錄像信息，并直接訪問錄像存儲介質獲取待回放的錄像數據。
• PTZ控制：PTZ控制服務調用設備管理服務（通過設備接入服務）向監控設備發送PTZ指令實現用戶的PTZ控制。
• 門禁控制：門禁控制調用設備管理服務（通過設備接入服務）向門徑設備發送門禁控制指令實現用戶對門禁的控制。
• 視頻分析：視頻分析服務實現對實時媒體流會話控制服務和錄像服務的調用，采集實時流或錄像數據進行視頻分析。
  ??圖 4顯示了服務架構中視頻流的流向以及服務與物理設備的關聯關系，其中帶紅色箭頭的粗線表示視頻流，藍色虛線表示與物理設備的關聯關系。
  
  ??圖 4中，設備接入服務與接入的物理設備直接打交道，使用物理設備所提供的傳輸交換協議。鑒于物理設備接入協議的多樣化(如SNMP，SIP,SOAP等)，建議對于不同的接入協議定義不同的子接入服務，設備接入服務可根據設備可接入的類型確定所調用的子接入服務實例。
  ??同設備接入服務一樣，實時媒體流會話控制服務與請求媒體流的物理設備通過物理設備支持的媒體會話協議進行交互。不同的設備支持的媒體會話協議可能不同（如SIP,RTSP等），建議對于不同的媒體會話協議定義不同的子會話控制服務， 實時媒體流會話控制服務根據請求設備支持的媒體會話協議選擇該調用的子會話控制服務。
  ??VMS服務架構中服務之間的互操作可使用服務操作原語來定義，如第3節所描述。

  3. 服務操作原語

  ??VMS中，將視頻流，錄像，設備參數，設備等視為不同的邏輯實體對象，系統功能即可視為對這些實體對象的操作。借鑒在電信管理網中使用的CMIP (Common Management Information Protocol，通用管理信息協議)所支持的CMIS服務，我們可在VMS中定義六種抽象出來的服務操作原語：

• VM-CREATE：創建相關的邏輯實體對象，如視頻流，媒體配置實體，安全邏輯實體（如keystore），網絡接口，錄像文件等對象。
• VM-CREATE：刪除已經創建的邏輯實體對象，如視頻流，媒體配置實體，安全邏輯實體（如keystore）等對象。
• VM-GET：獲取邏輯實體對象的相關參數與屬性。
• VM-SET：設置邏輯實體對象的相關參數與屬性。
• VM-ACTION：執行邏輯實體對象可執行的一個動作，如進行媒體會話，進行解碼動作等。
• VM-EVENT-REPORT:服務實例在運行過程中發送被觸發的事件消息。

  4. 實施策略

  ??自martin fowler發表了那篇著名的微服務博客文章之后，微服務架構在近幾年間在軟件界著實火了一把，在國內軟件界似乎出現了一種不談微服務的軟件架構設計就不夠高大上的現象。其實仔細剖析微服務的模式，我個人更認為微服務是SOA在實現層次的細化和擴充。微服務在分解服務為更細粒度時，同時也為分解的服務間關系帶來更多的復雜性。因此在使用面向服務的思路來實施VMS時也要根據實際場景和規模來選擇合適的方案。

  4.1 服務要多大

  ??在前面的軟件架構中，設備接入，實時媒體流會話控制服務，錄像服務這三個系統中的核心服務在部署上，每個服務建議設計為服務集群（最簡單的方式是在一堆服務實例前加一個負載均衡器），可根據項目的實際規模進行配置伸縮。

  4.2 數據如何存儲

  ??VMS中，我將數據分為控制面數據與媒體數據，視頻流這些媒體數據在規模大時可考慮選型如HDFS這樣的開源分布式存儲系統，在規模小時可使用單獨的磁陣即可。
  ??對于控制面的數據，如設備信息，媒體配置信息等數據，由于會被多個服務實例訪問，可考慮使用ElasticSearch, etcd這樣分布式協同系統。

  4.3 服務原語的實現形式

  ??VMS中，我建議服務原語以Rest Api的形式定義，這樣在服務實例之間基于HTTP的restful接口就可實現服務原語在服務間的互操作（比如使用spring cloud作為服務實現框架）。

  4.4 如何選擇消息服務器

  ??同樣，消息服務器根據項目的規模來確定，在系統規模較小的場景下，使用輕量級的消息服務器（如使用redis就可以），系統規模較大的場景下，可以考慮kafka這樣的消息集群服務。

  4.5 如何選擇流媒體中間件

  ??VMS中涉及到RTSP,SDP，SIP，RTP/RTCP等多種流媒體相關協議，幸運的是，現在github上各種語言的流媒體中間件都可以找到，如果實在要我推薦，在我用過的產品中，我覺得gstreamer就很好。

  4.6 基于Web的視頻瀏覽

    傳統的VMS中，在瀏覽器中對視頻進行瀏覽需要借助自己編寫的控件，隨著WebRTC技術的出現，主流瀏覽器已經逐步支持WebRTC的規范，因而使用WebRTC實現免插件的視頻瀏覽成為可能。需要注意，目前瀏覽器的支持視頻編碼格式有限，在服務端可能要轉碼，另外也需要構建WebRTC的服務端作為視頻源。