平安城市運維管理軟件架構

1. 平安城市運維管理挑戰

??平安城市是一個由各式軟硬件組成的復雜網絡系統，視頻業務是其核心業務。在平安城市網絡中部署著眾多視頻圖像信息采集、傳輸、處理設備和應用軟件系統。這些設備與應用軟件系統在滿足治安管理、城市管理、交通管理、應急指揮等多樣化需求的同時，也對運維管理提出了新的要求與挑戰。
??平安城市的運維管理所面對的挑戰如圖1所示。

??針對平安城市的運維管理挑戰，平安城市運維管理系統(以下簡稱運維管理系統)的功能和范圍定義如圖2所示。

??不同于電信網絡、計算機網絡的運維管理系統，平安城市的運維管理系統所管理的管理單元更為多樣化與復雜化，在功能上聚焦為用戶提供多層次價值。
??圖3以蘇州科達建設的一個典型平安城市項目為例，描述了運維管理系統與平安城市中各類管理單元間的關系。

2. 平安城市運維管理思路

??我們將運維管理系統涉及到的管理單元分為兩類：一類為設備，包含通用設備、視頻圖像信息采集設備等設備；一類為應用軟件系統，包括視頻圖像信息應用系統、視頻監控平臺、視圖庫等軟件系統。
??對于設備的運維管理，可充分參考電信等工程領域的運維管理標準和實踐，本文不再贅述。
??對于應用軟件系統的運維管理，是一個新課題，面臨的主要問題有以下三點：
??1. 平安城市項目建設周期較長，持續采購的應用軟件由不同廠家提供，差異性較大：不只在技術架構上存在較大差異（如有的軟件是單體（monothetic）設計，有的軟件是面向服務的設計），對外提供的接口也具有較大差異（缺乏相應的標準約束是主要原因）。
??2. 平安城市中的應用軟件系統能夠提供用戶關注的價值（如數據采集、統計、分析等），這些價值需要在運維管理系統中體現，提供更良好的用戶體驗。
??3. 避免“重復造輪子”，對于平安城市中的應用軟件系統已經提供的診斷測試、統計分析等功能，運維管理系統應盡量引用這些功能，而不是重新開發。

3. 平安城市運維管理架構

3.1. 邏輯結構

??針對應用軟件系統運維管理面臨的挑戰，我們首先將應用軟件系統做邏輯上的抽象：
??將應用軟件系統抽象為軟件服務的容器，表示為S={e}：S表示為一個應用軟件系統， e表示軟件系統S能夠提供的軟件服務。
??將軟件服務e抽象定義為三元組，則e=(o,d,i) :其中o表示該軟件服務提供的操作；d表示該軟件服務提供的數據；i表示該軟件服務提供的交互接口。
??經過上述邏輯抽象，應用軟件系統的運維管理轉換為運維管理系統對每個e的管理。
??根據圖2的功能范圍定義及平安城市建設中的實踐經驗，我們將e歸納為以下幾類服務：

• 遠程診斷、測試操作服務：平安城市中的應用軟件系統，有些是獨立的設備管理系統，能夠提供一系列針對設備的遠程診斷、遠程測試功能，將這些功能抽取出來、包裝為軟件服務提供給運維管理系統，便于用戶在運維管理系統中實施一站式對多種類型設備的遠程診斷、測試操作功能。
• 數據統計展示服務：平安城市中的應用軟件系統，有些提供完整的數據統計，挖掘，展示功能(如常用的報表系統)。這些飽含分析價值的數據圖表可抽取出來作為數據展示服務提供給運維管理系統。便于用戶在運維管理系統中方便地在各類數據報表間切換。
• 數據導出服務：平安城市中的應用軟件系統，有些包含數據倉庫。構建數據導出服務將這些數據倉庫中的數據導出到運維管理系統，便于用戶在運維管理系統中對于多領域的數據進行綜合分析。
  ??除上述三類主要服務外，還有一些通用軟件服務，如系統狀態、異常信息上報，服務治理等。這些通用軟件服務的管理可參考微服務架構系統的運維管理思路，本文不作深入探討。

  3.2. 軟件架構

  ??為便于描述，本文約定涉及的軟件系統均為B/S架構。
  ??平安城市中存在著大量已服役多年的應用軟件系統，運維管理系統需要的軟件服務依賴于這些遺留的應用軟件系統。很顯然，通過對遺留應用軟件系統進行大幅改造來提供軟件服務的方法不可取。遵循軟件設計的“開-閉”原則，對于這些應用軟件系統，我們將系統可提供給運維管理系統的軟件服務進行抽取、包裝，增加Microgateway (微網關)作為應用軟件系統與運維管理系統之間的橋梁（有沒有一瞬間讓你想到電信網管的北向接口），為運維管理系統提供軟件服務，平安城市運維管理的整體軟件架構如圖4所示。
  
  ??圖4的架構是一個典型的類微服務架構（portal好比apigateway,運維管理系統和各應用軟件系統好比各微服務，其它一些部件(如服務注冊)被省略），根據圖4，我們梳理一下用戶的操作流程：
  ??1. 用戶通過平安城市的portal進入門戶頁面，向平安城市中的統一授權服務器（authorization server）使用SSO(單點)登錄進行身份驗證，并獲取訪問令牌(access token)。
  ??2. 用戶從門戶頁面跳轉到運維管理系統，重定向請求中攜帶訪問令牌。
  ??3. 運維管理系統驗證訪問令牌確定用戶身份，返回操作頁面。
  ??4. 用戶在運維管理系統中消費目的應用軟件系統軟件服務。操作請求中攜帶訪問令牌，被發送到目的應用軟件系統對應的Microgateway。
  ??5. Microgateway驗證訪問令牌確定用戶身份，根據請求選擇對應的服務路由，調用目的應用軟件系統的相應服務，并將調用結果返回給運維管理系統。

  3.2.1. 關于系統安全

  ??系統安全是軟件設計中永恒的話題。在平安城市中，我們設計了統一的授權服務器，如果平安城市中已建設好PKI（Public Key Infrastructure），授權服務器應充分利用已有的PKI，同時作為一個SSO服務器，支持OAuth3協議，用戶可從portal,運維管理系統和其它應用軟件系統中任意一個系統登錄進行驗證，并獲取授權服務器頒布的訪問令牌，訪問令牌建議使用JWT(Java Web Token)格式，用于在系統的各個服務之間調用時驗證身份。
  ??如果JWT使用了簽名方式，如使用的是“RS256”這樣的PKI簽名方式，平安城市中的各個系統(服務)需要向統一授權服務器申請用于驗證簽名的公鑰證書。
  ??需要注意的是，JWT是有期限的，對于JWT過期的情況，各系統(服務)需要重新申請。
  ??對于系統資源的訪問控制，如果已有建設好的PMI（Privilege Management Infrastructure），應優先使用已有的PMI用于訪問控制，當使用JWT表示身份驗證結果時，可在JWT的payload中攜帶PMI屬性證書中的部分內容（如用戶所屬群組與所屬角色），這樣做法的好處是將待實施訪問控制系統去PMI平臺獲取用戶屬性證書的過程省略了，提升了效率，但如果系統中用戶的群組和角色變換頻繁，則不宜使用這種方式。如果沒有可用的PMI，各系統需要自建自身的訪問控制體系，對于攜帶訪問令牌的訪問請求，各系統可利用自身建設的訪問控制體系識別用戶身份進行訪問控制。
  ??從系統一致性的角度，我還是強烈建議在平安城市中建立統一的PKI/PMI體系，達到統一認證、授權、鑒權的目標，提供完美的用戶體驗。

  3.2.2. 關于Microgateway

  ??Microgateway的定義了解一下，美國CA公司對于Microgateway的定義如下：
  ??CA Microgateway is a lightweight, containerized gateway, designed to scale within highly decentralized environments. It supports common microservices patterns by providing service-discovery, routing, rate-limiting and last-mile security, and is easily deployable and configurable by developers at design time using provided policy templates.
  ??由定義可以看到，Microgateway可視為一個局部gateway,用于解決“最后一公里”的問題。Microgateway又提供靈活可配置的模板供用戶在設計時使用，用戶可在運行時通過修改模板的配置數據使得Microgateway不需要修改代碼及重新編譯部署就能實現新的功能。
  ??平安城市中應用軟件由不同廠家提供，應用軟件的更新升級可能導致提供的接口也發生變化，如果運維管理系統針對每次應用軟件的升級更新導致的接口變更都做修改的話，那么工作量是巨大的。Microgateway可以通過靈活可配的策略模板來將這種變化封裝在Microgateway內。
  ??如針對應用軟件系統的數據庫，Microgateway對運維管理系統提供Restful的查詢接口，查詢應用軟件系統的數據庫對應數據。可在Microgateway中編寫數據庫查詢模板，在模板配置文件中設置待查詢的數據庫表、字段以及Restful接口的URI以及返回數據格式。當運維管理系統需要增加查詢接口時，只需要在模板配置文件中增加對應條目即可；當應用系統的數據庫發生變化時（如表字段發生變化時），修改模板配置文件中對應字段即可。模板配置文件使得運維管理系統不感知所管理應用軟件系統的接口變化。
  ??針對應用軟件系統的HTTP接口，Microgateway同樣可編寫路由模板，在模板配置文件中設置HTTP請求的路由規則，將來自運維管理系統的請求根據路由規則路由到應用軟件系統提供的軟件服務(是不是有點像spring cloud的zuul)。
  ??需要注意的是，Microgateway并非silverbullet，Microgateway所實現的柔性擴展也是基于約束的，這個約束用于指導模板的設計。

  4. 示例DEMO

  ??本節介紹一個示例DEMO，模擬演示第3節提到的運維管理架構。該DEMO的代碼存放位置為：https://github.com/solarkai/IomsSimu/ 。該示例中沒有涉及系統安全(以后考慮補上)。
  ??此DEMO中，分別模擬了一個運維管理系統、一個交通管控平臺中的報表服務和一個針對該報表服務的Microgateway。
  ??模擬交通管控平臺中的報表服務使用spring-boot框架編寫，提供了一個Restful接口提供簡單的報表數據（數據格式為JSON格式）。
  ??報表服務的Microgateway使用Node.js和Express框架編寫，使用“http-proxy-middleware”中間件定義了一個HTTP路由模板，處理來自運維管理系統的操作請求。路由模板的配置文件由gateway.json文件定義，內容示例如下：

  {
  "gatewayList": [
  {
    "path": "/chart1",
    "method": "get",
    "proxy": {
      "target": "http://127.0.0.1:8082",
      "pathRewrite": {
        "^/reports/chart1": "/loadChart1"
      }
    }
  }
  ]
  }

  ??Microgateway提供一個報表展示頁面，數據來自于模擬交通管控平臺中的報表服務。圖5是報表展示頁面。
  
  ??模擬運維管理系統使用Node.js和Express框架編寫，該運維管理模塊的模擬運維管理系統的應用軟件系統管理界面是長這樣的。
  
  ??在模擬運維管理系統，可配置Microgateway提供的軟件服務信息，并消費這些軟件服務。圖7顯示了對Microgateway提供的報表服務的消費。
  

  5. 小結

  ??平安城市系統具有多樣性和復雜性，對運維管理提出了極高要求。本文針對平安城市系統的特點，針對平安城市中應用軟件系統的運維管理設計了平安城市的運維管理軟件架構，并給出示例DEMO。該軟件架構強調了Microgateway的作用，以實現運維管理的柔性擴展。