一種國產化航天測控集中監控軟件架構設計

孟景濤 王松鶴 武鵬 郭濤 孫婧

摘要：隨著國產化新研航天測控軟件的規模越來越龐大，快速定制、代碼復用的需求越來越迫切。許多應用場景用戶都提出集中監控的需求，且系統監控軟件要采用微服務或多進程的思路進行設計。提出了一套以微服務平臺為基礎進行開發的集中監控軟件的架構設計方案，服務的進程之間相互隔離，獨立開發、部署和發布，支持多種客戶端訪問和跨平臺的國產化操作系統。通過這種微服務形態的軟件架構，可以實現測控領域各類軟件的快速定制，形成復用性高的產品或者功能，從而快速穩定地完成軟件開發過程。

關鍵詞：分布式；微服務；集中監控；國產化

中圖分類號：TP319文獻標志碼：A文章編號：1008-1739（2022）08-54-6

以往集中監控都以單體架構為設計，復雜性高，項目模塊也會隨著需求的變動不斷調整構建，因此對新增和修改的代碼都會重復做很多測試，擴展性、可靠性也較差。集中監控作為一個龐大復雜的應用服務，隨時都存在對新業務需求的依賴，應用程序各模塊之間耦合關系密切，對新業務的擴展帶來極大的不便。

對于集中監控這種包含大量業務的應用程序來說，單體架構面臨越來越多的挑戰，其改造與重構勢在必行。而微服務架構的誕生，是互聯網高速發展、虛擬化技術應用以及持續交付、DevOps深入人心的綜合產物。隨著用戶需求個性化、產品生命周期變短，微服務架構是未來軟件架構朝著靈活性、擴展性、伸縮性以及高可用性發展的必然方向。

微服務形態下，集中監控設計的基本思想在于圍繞監控業務組件來創建應用，這些應用可獨立地進行開發和運行[1]。一個微服務僅完成某些簡單的特定功能，降低了集中監控的開發難度。微服務之間可通過一些輕量級的通信機制進行通信，對于技術實現來說，可基于不限一種編程語言（C++，Java，C#，Python，Go等）來進行開發[2]。

微服務架構提供服務容器并制定服務接口描述規范，遵循該規范的服務可注冊到微服務框架中，同時提供給這些服務全生命周期管理與狀態監控，并且支持跨語言服務共存，提供服務間安全可靠通信機制，在部署方面支持分布式跨平臺[3]，從而能使業務服務具有高可靠性、高復用性部署及管理一體化的便利性[4]。

本項目微服務架構設計將單一應用程序劃分成一組小的服務[5]，服務之間互相協調、互相配合，為用戶提供應用價值。各個服務可運行在其獨立的進程中，服務與服務間可采用多種網絡通信機制互相溝通，也可通過消息總線進行信息的發布與訂閱。每個服務都圍繞具體業務進行構建，并且能夠被獨立部署到生產環境。

微服務架構平臺將具體業務細分成多個獨立的服務，獨立開發，獨立運行，獨立配置發布[6]。所有服務通過注冊中心進行動態注冊，自動發現服務并檢查狀態；用戶通過客戶端或瀏覽器遠程發起服務訪問請求，通過服務網關進行反向代理，負載均衡找到正確的服務，并將結果返回給用戶[7]。

微服務平臺采用“平臺+服務+網關+應用”的邏輯架構設計[8]，微服務平臺架構如圖1所示。

2.1服務注冊及配置管理器（Zookeeper）

使用Zookeeper中間件實現注冊中心，Zookeeper在遠程監控中心啟動服務時，服務會向指定注冊中心集群注冊相關服務信息及端口，服務調用可從服務注冊中心查看服務的信息，根據自身需求跟服務進行通信等功能。服務注冊中心采用Zookeeper管理各種服務功能，包括服務的注冊、發現和負載等。

使用Zookeeper中間件實現微服務架構的配置管理（服務啟停的腳本化管理、服務相關運行配置屬性、配置文件管理）能力。該技術解決了分布式集群中應用系統的一致性問題，提供類似于文件系統的目錄節點樹方式的數據存儲，Zookeeper作用主要是用來維護和監控存儲數據的狀態變化，通過監控這些數據狀態的變化，達到基于數據的集群管理。Zookeeper同時提供分布式鎖功能，為跨機器跨進程提供并發調用的支持。

Zookeeper集群配置管理配合Git完成配置的歸檔與更新，Zookeeper推送到所有觀察訂閱這個節點的服務器，服務器更新配置，所有服務器完成一次更新操作[9]。

2.2消息總線（RabbitMQ）

使用RabbitMQ消息中間件實現微服務架構的總線消息管理（消息傳輸管理、消息監視、消息治理）的能力[10]，主要解決應用耦合、異步消息和流量削峰等問題，以實現高性能、高可用、可伸縮和最終一致性架構，是大型分布式系統中不可缺少的消息中間件，為整個系統提供異步數據交換通道。

RabbitMQ提供如點對點、RPC、訂閱發布和文件傳輸4種工作模式，包含了主動獲取消息、被動接收消息、執行錯誤代號和執行錯誤描述等多項定制接口特性。RabbitMQ運行如圖2所示。

2.3服務網關

使用服務網關實現微服務架構的部分分布式服務的路由轉發[11]。通過服務網關統一向外系統提供Rest API、RPC API或者自定義網絡協議接口。服務網關包含了對請求的路由和過濾2個最主要的功能。其中，路由功能負責將外部請求轉發到具體的微服務實例上，是實現外部訪問統一入口的基礎[12]。而過濾器功能則負責對請求的處理過程進行干預，是實現請求校驗、服務聚合等功能的基礎。

服務網關和Zookeeper進行整合，將服務網關自身注冊為Zookeeper服務治理下的應用，同時從Zookeeper中獲得其他微服務的消息，即以后的訪問微服務都是通過服務網關跳轉后獲得，服務網關代理設計如圖3所示。

2.4虛擬IP與服務容災

使用開源路由軟件Keepalived實現微服務架構的虛擬IP管理（服務高可用）能力。Keepalived是一種高性能的服務器高可用或熱備解決方案，用來防止服務器單點故障的發生，可以實現子設備監控服務的高可用。

Keepalived以VRRP協議為實現基礎，用VRRP協議來實現高可用性。VRRP協議是用于實現節點冗余的協議，將2個或多個節點虛擬成一個節點，對外提供虛擬節點IP（一個或多個），而在節點組內部，如果實際擁有這個對外IP的節點且工作正常的話就是Master，或者通過算法選舉產生，Master實現針對虛擬節點IP的各種功能，如設備監控、監控數據的轉發等；其他節點不擁有該虛擬IP，狀態是Backup，除了接收Master的VRRP狀態通告信息外，不執行對外的功能。當主機失效時，Backup將接管原先Master的功能。VRRP協議使用多播數據來傳輸VRRP數據，VRRP數據使用特殊的虛擬源MAC地址而不是自身網卡的MAC地址發送數據，VRRP運行時只有Master節點定時發送VRRP通告信息，表示Master工作正常以及虛擬節點IP（組）；Backup只接收VRRP數據，不發送數據。如果一定時間內沒有接收到Master的通告信息，各Backup將宣告自己成為Master，發送通告信息，重新進行Master選舉狀態。Keepalived架構如圖4所示。

2.5 RPC通信中間件

使用開源消息通信中間件框架ICE實現微服務架構算法服務之間的RPC調用與服務指令控制管理，以及統一算法接口標準能力。

2.6服務代理守護進程

服務代理守護進程實現微服務架構的服務啟停、服務監控、服務腳本維護、服務部署和卸載等能力，對整個微服務架構中的支撐服務和業務服務進行管控。

服務代理守護進程以獨立的進程運行在各個物理機節點或虛擬機節點上，守護進程與平臺管理中心服務端以TCP的方式進行通信，作為框架的基礎功能部分，通過接口暴露及消息訂閱方式對指定微服務進行啟停控制。代理守護進程如圖5所示。

2.7微服務管理中心

微服務管理中心實現微服務架構的服務治理、服務監控、服務配置、日志管理和用戶權限能力，服務管理中心提供可視化的Web頁面對服務器軟硬件進行管理。

服務管理中心集成了服務注冊、服務部署、服務卸載、服務啟停和服務主備切換等功能，為已存在或正在開發的應用或服務，以及復雜網絡環境的組件化和服務化軟件系統提供部署、運行和管理的支撐和基礎環境。服務管理中心可動態地在微服務架構平臺中注冊（新增）和注銷（卸載）業務服務，服務管理中心能最大限度地擴展服務數量（僅僅受限于服務器硬件資源環境）。

管理中心軟件本身帶有失效重啟功能，負責跟所有服務節點機器的守護進程進行通信，實現遠程監控微服務進程的功能。

基于微服務架構形態下的集中監控采用B/S與C/S兼容的架構模式，服務器端開發語言使用Java，C++及少量Python，客戶端使用瀏覽器或者基于Qt開發的桌面程序進行展示。

為了可靈活構建集中監控中的業務應用，微服務架構的服務器端在數據持久化時，使用數據去中心化的思想，將微服務所對應的服務模塊持久數據進行分庫設計，多個服務之間的設計保持相互獨立，數據也保持獨立性。每個微服務都有自己對應的私有數據庫，其他微服務不能直接訪問，而基于多個微服務形成的上層業務數據通過對應的業務形態去任意組合數據。微服務架構主要包含以下關鍵技術設計。

3.1服務與設備監控設計

服務與設備監控實現對服務節點運行資源和服務健康狀態的監視，包括軟件和硬件環境、虛擬機資源及其運行狀態等[14]。3.1.1功能設計

通過實現SNMP代理（AGENT）和自陷（TRAP）的方式，支持配置相關監視參數，對故障進行告警等功能，服務監視流程如圖6所示。

監控服務通過SNMP協議獲取服務節點信息和服務運行狀態，同時可以向SNMP代理發送配置參數，配置服務故障告警門限、TRAP地址等。SNMP TRAP通過監聽162端口，接收 SNMP AGENT發送的TRAP事件。

3.1.2監控內容設計

服務節點資源監控主要針對物理機資源進行監視，包含服務監控、服務信息上報、服務監控信息收集、服務調用信息獲取和服務調用信息緩存等模塊。服務監控模塊主要提供服務信息上報和服務監控信息緩存的功能；服務信息上報模塊可對調用服務的信息做記錄，框架會自動收集這些信息，并集中緩存；服務監控信息收集模塊從服務域的角度收集服務域內所有服務的監控信息并緩存；服務調用信息獲取模塊從框架的角度收集所有服務的監控信息，并主動上報監控異常信息。

設備監控主要針對虛擬機設備進行啟動、停止、狀態上報和資源信息監視等功能。

交換機監視采用SNMP網絡和資源管理技術監視網絡交換機，因此交換機需要支持SNMP協議。通過交換機提供的MIB信息來獲取需要監視的信息，主要包括交換機的CPU使用率、內存使用率、接口狀態和接口流量等信息。

3.2負載均衡設計

負載管理模塊用于統計和分析集群中各服務節點的服務負載信息，利用平臺的分布式協調功能監控服務并獲取服務的調用信息，計算出每個服務節點的每個服務在一定時間內的觸發次數、平均執行時間等負載信息，并且將這些信息緩存在平臺監控模塊中，供負載均衡算法使用。

集群負載管理是集群管理的重要功能，其負載管理效果直接影響負載均衡算法的準確性和整個集群的處理能力，集群負載管理能夠真實反映集群中各服務的運行負載情況。

3.2.1功能設計

負載均衡協調模塊用于為微服務平臺集群提供負載均衡算法和協調集群中服務調用的功能。微服務平臺的負載均衡協調的目標是使服務集群中各服務節點盡可能均衡地處理服務請求，發揮集群的綜合處理能力，提高服務效率并且減少等待時間，避免協調不當導致部分服務節點忙碌、部分服務節點閑置的情況。

負載均衡協調模塊負責將集群負載管理模塊緩存的服務負載信息收集，并生成可供負載均衡算法使用的數據對象。負載均衡算法運行時，直接從已生成的數據對象中計算，提高計算效率。

負載均衡協調模塊為服務集群提供3種負載均衡算法，供服務調用配置模塊選擇。3種算法如下：

①輪詢算法：假設所有服務器的處理性能都相同，不關心每臺服務器的當前連接數和響應速度，把請求輪流分配給內部的服務器。

②時間最小算法：服務調用時，考慮各節點的負載情況和服務的平均處理時間，按照處理比例和概率的優化算法對已生成的數據對象進行計算，為服務調用分配一個適當的服務節點進行調用。

③通信頻次算法：服務調用時，根據服務通信的次數來進行均勻分配調用請求。

3.2.2流程設計

在負載均衡協調模塊收到負載協調請求時，負載均衡協調流程開始。首先將集群負載管理在注冊表的服務負載信息進行收集，生成需要調用的服務的負載計算對象，再調用負載均衡算法，對對象進行計算，根據計算結果選擇服務節點。服務端調用算法服務的負載管理流程設計如圖7所示。

服務端服務組合流程調用分成2類服務調用：分布式服務和主從服務調用。分布式服務將自身注冊到服務注冊中心，在組合服務調用時，分布式服務代理通過注冊中心獲取當前的服務信息，并按照負載策略獲取一個滿足要求的服務節點發起RPC請求并獲取結果；主從服務將虛擬IP配置信息持久化在數據庫中，主從服務代理通過數據庫獲取當前服務對應的虛擬IP，并通過虛擬IP發起RPC請求獲取結果；組合服務執行引擎匯總分布式服務B代理和主從服務C代理的結果數據，最后將數據作為算法服務D代理的輸入參數發起RPC調用并得到最終結果。

3.3消息總線設計

本設計中，消息總線以微服務的方式提供消息隊列功能，包括提供隊列以及訂閱/發布2種方式。其中普通的日志以及數據信息將以隊列方式傳輸消息，故障消息以及異常通知都以訂閱/發布方式推送數據。

3.3.1管理流程設計

消息總線管理流程設計如圖8所示。

客戶端調用消息總線客戶端SDK庫，初始化發布端和訂閱端程序（創建交換器和隊列，并將二者進行邏輯綁定），創建TCP連接，消息發布者和消息訂閱者都是通過TCP連接到消息總線的服務端。

TCP連接建立之后需要建立虛擬連接（Channel），Channel建立在上述TCP連接中，數據流動都是在Channel中進行的。對于操作系統來說，建立和關閉TCP連接是有代價的，頻繁地建立關閉TCP連接對于系統的性能有很大的影響，而且TCP的連接數也有限制，這也限制了系統處理高并發的能力。但是，在TCP連接中建立Channel是沒有上述代價的。對于發布端或者訂閱端來說，可以并發地使用多個Channel進行消息的發布或者訂閱。

3.3.2性能設計

在RabbitMQ的訂閱/發布主題且數據持久化的測試過程中，隨著單節點訂閱用戶數的增多，網絡帶寬使用率也會隨之增加，直至壓滿（現有環境為千兆網絡和千兆網卡，在速度達到110 Mbps及以上之后網絡使用率達到最大值，即已壓滿），同時同等訂閱數條件下，網絡帶寬的使用率會隨著訂閱主題數據量的增加而增加，直至壓滿。故在現有場景下的性能場景測試瓶頸來自于網絡，通過節點擴展（增加RabbitMQ節點數）可以得到更大的數據承擔流量。

為了使網絡帶寬的利用率達到最大，對消息隊列的傳輸情況進行了測試（發布者100，訂閱者100的情況下），測試結果如表1所示。

根據該性能測試數據分析，在用戶所攜消息數據包大小為24 KB時網絡帶寬使用率已經達到峰值，為保持服務器的穩定性和可靠性，服務框架內各服務間傳輸的單個數據包攜帶數據不應超過24 KB。

本文研究并實現了一種國產化航天測控集中監控軟件架構，其基于微服務架構進行設計，將緊耦合的系統劃分為面向業務的、粗粒度、松耦合、無狀態的服務，并提供了一種屏蔽了復雜技術細節的標準開發框架，使得研發人員只需要關注業務代碼的編寫和微服務的配置即可。同時采用統一化的平臺標準及規范，制定服務接口規范與交互規范標準，從而監控和約束軟件的質量，確保軟件的通用性、伸縮性、魯棒性以及穩定性。依賴該微服務框架，可以快速建立起一個高內聚、低耦合的基于微服務架構的集中監控軟件，從而可以快速實現軟件定制，提高產品序列、豐富服務倉庫，形成復用性高的產品或者功能，從而快速滿足和響應客戶的需求。

參考文獻

[1]王文龍.分布式軟件開發平臺的設計與實施[D].北京：北京郵電大學，2011.

[2]李春霞.微服務架構研究概述[J].軟件導刊，2019，18（8）：1-3.

[3]崔方園.支持分布式協同開發的軟件配置管理系統研究[D].大連：大連海事大學，2009.

[4]林旭新，陳文吉，鄭大鵬.一種面向服務的跨平臺實時信息發布及交流軟件架構[J].現代計算機（專業版），2014（8）： 77-80.

[5]史俊.分布式軟件技術及其應用研究[J].無線互聯科技， 2012，12：68.

[6]王義.微服務架構特點、技術趨勢及在行業應用中關鍵問題研究[J].軟件，2020，41（6）：132-136.

[7]周家昊.微服務架構關鍵技術研究與通用框架實現[D].廣州：廣東工業大學，2019.

[8]徐西岳.分布式系統中微服務架構的研究及應用[D].青島：山東科技大學，2019.

[9]苗凡，閻志遠，戴琳琳.基于Zookeeper的配置管理中心設計與實現[J].鐵路計算機應用，2018，27（10）：26-29.

[10]胡雪婧.基于ZooKeeper的分布式系統的消息發送機制的設計與實現[D].長春：吉林大學，2016.

[11]周國興.基于ZooKeeper的服務集成框架研究[D].南京：東南大學，2019.

[12]董龍成.基于ZooKeeper的配置中心系統設計與實現[D].西安：西安電子科技大學，2018.

[13]黃毅斐.基于ZooKeeper的分布式同步框架設計與實現[D].杭州：浙江大學，2012.

[14]孫婧，劉瑩，孟景濤，等.基于XML的軟件通用程序框架[J].無線電工程，2015，45（6）：25-27.