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

摘要：隨著國(guó)產(chǎn)化新研航天測(cè)控軟件的規(guī)模越來(lái)越龐大，快速定制、代碼復(fù)用的需求越來(lái)越迫切。許多應(yīng)用場(chǎng)景用戶都提出集中監(jiān)控的需求，且系統(tǒng)監(jiān)控軟件要采用微服務(wù)或多進(jìn)程的思路進(jìn)行設(shè)計(jì)。提出了一套以微服務(wù)平臺(tái)為基礎(chǔ)進(jìn)行開發(fā)的集中監(jiān)控軟件的架構(gòu)設(shè)計(jì)方案，服務(wù)的進(jìn)程之間相互隔離，獨(dú)立開發(fā)、部署和發(fā)布，支持多種客戶端訪問(wèn)和跨平臺(tái)的國(guó)產(chǎn)化操作系統(tǒng)。通過(guò)這種微服務(wù)形態(tài)的軟件架構(gòu)，可以實(shí)現(xiàn)測(cè)控領(lǐng)域各類軟件的快速定制，形成復(fù)用性高的產(chǎn)品或者功能，從而快速穩(wěn)定地完成軟件開發(fā)過(guò)程。

關(guān)鍵詞：分布式；微服務(wù)；集中監(jiān)控；國(guó)產(chǎn)化

中圖分類號(hào)：TP319文獻(xiàn)標(biāo)志碼：A文章編號(hào)：1008-1739（2022）08-54-6

以往集中監(jiān)控都以單體架構(gòu)為設(shè)計(jì)，復(fù)雜性高，項(xiàng)目模塊也會(huì)隨著需求的變動(dòng)不斷調(diào)整構(gòu)建，因此對(duì)新增和修改的代碼都會(huì)重復(fù)做很多測(cè)試，擴(kuò)展性、可靠性也較差。集中監(jiān)控作為一個(gè)龐大復(fù)雜的應(yīng)用服務(wù)，隨時(shí)都存在對(duì)新業(yè)務(wù)需求的依賴，應(yīng)用程序各模塊之間耦合關(guān)系密切，對(duì)新業(yè)務(wù)的擴(kuò)展帶來(lái)極大的不便。

對(duì)于集中監(jiān)控這種包含大量業(yè)務(wù)的應(yīng)用程序來(lái)說(shuō)，單體架構(gòu)面臨越來(lái)越多的挑戰(zhàn)，其改造與重構(gòu)勢(shì)在必行。而微服務(wù)架構(gòu)的誕生，是互聯(lián)網(wǎng)高速發(fā)展、虛擬化技術(shù)應(yīng)用以及持續(xù)交付、DevOps深入人心的綜合產(chǎn)物。隨著用戶需求個(gè)性化、產(chǎn)品生命周期變短，微服務(wù)架構(gòu)是未來(lái)軟件架構(gòu)朝著靈活性、擴(kuò)展性、伸縮性以及高可用性發(fā)展的必然方向。

微服務(wù)形態(tài)下，集中監(jiān)控設(shè)計(jì)的基本思想在于圍繞監(jiān)控業(yè)務(wù)組件來(lái)創(chuàng)建應(yīng)用，這些應(yīng)用可獨(dú)立地進(jìn)行開發(fā)和運(yùn)行[1]。一個(gè)微服務(wù)僅完成某些簡(jiǎn)單的特定功能，降低了集中監(jiān)控的開發(fā)難度。微服務(wù)之間可通過(guò)一些輕量級(jí)的通信機(jī)制進(jìn)行通信，對(duì)于技術(shù)實(shí)現(xiàn)來(lái)說(shuō)，可基于不限一種編程語(yǔ)言（C++，Java，C#，Python，Go等）來(lái)進(jìn)行開發(fā)[2]。

微服務(wù)架構(gòu)提供服務(wù)容器并制定服務(wù)接口描述規(guī)范，遵循該規(guī)范的服務(wù)可注冊(cè)到微服務(wù)框架中，同時(shí)提供給這些服務(wù)全生命周期管理與狀態(tài)監(jiān)控，并且支持跨語(yǔ)言服務(wù)共存，提供服務(wù)間安全可靠通信機(jī)制，在部署方面支持分布式跨平臺(tái)[3]，從而能使業(yè)務(wù)服務(wù)具有高可靠性、高復(fù)用性部署及管理一體化的便利性[4]。

本項(xiàng)目微服務(wù)架構(gòu)設(shè)計(jì)將單一應(yīng)用程序劃分成一組小的服務(wù)[5]，服務(wù)之間互相協(xié)調(diào)、互相配合，為用戶提供應(yīng)用價(jià)值。各個(gè)服務(wù)可運(yùn)行在其獨(dú)立的進(jìn)程中，服務(wù)與服務(wù)間可采用多種網(wǎng)絡(luò)通信機(jī)制互相溝通，也可通過(guò)消息總線進(jìn)行信息的發(fā)布與訂閱。每個(gè)服務(wù)都圍繞具體業(yè)務(wù)進(jìn)行構(gòu)建，并且能夠被獨(dú)立部署到生產(chǎn)環(huán)境。

微服務(wù)架構(gòu)平臺(tái)將具體業(yè)務(wù)細(xì)分成多個(gè)獨(dú)立的服務(wù)，獨(dú)立開發(fā)，獨(dú)立運(yùn)行，獨(dú)立配置發(fā)布[6]。所有服務(wù)通過(guò)注冊(cè)中心進(jìn)行動(dòng)態(tài)注冊(cè)，自動(dòng)發(fā)現(xiàn)服務(wù)并檢查狀態(tài)；用戶通過(guò)客戶端或?yàn)g覽器遠(yuǎn)程發(fā)起服務(wù)訪問(wèn)請(qǐng)求，通過(guò)服務(wù)網(wǎng)關(guān)進(jìn)行反向代理，負(fù)載均衡找到正確的服務(wù)，并將結(jié)果返回給用戶[7]。

微服務(wù)平臺(tái)采用“平臺(tái)+服務(wù)+網(wǎng)關(guān)+應(yīng)用”的邏輯架構(gòu)設(shè)計(jì)[8]，微服務(wù)平臺(tái)架構(gòu)如圖1所示。

2.1服務(wù)注冊(cè)及配置管理器（Zookeeper）

使用Zookeeper中間件實(shí)現(xiàn)注冊(cè)中心，Zookeeper在遠(yuǎn)程監(jiān)控中心啟動(dòng)服務(wù)時(shí)，服務(wù)會(huì)向指定注冊(cè)中心集群注冊(cè)相關(guān)服務(wù)信息及端口，服務(wù)調(diào)用可從服務(wù)注冊(cè)中心查看服務(wù)的信息，根據(jù)自身需求跟服務(wù)進(jìn)行通信等功能。服務(wù)注冊(cè)中心采用Zookeeper管理各種服務(wù)功能，包括服務(wù)的注冊(cè)、發(fā)現(xiàn)和負(fù)載等。

使用Zookeeper中間件實(shí)現(xiàn)微服務(wù)架構(gòu)的配置管理（服務(wù)啟停的腳本化管理、服務(wù)相關(guān)運(yùn)行配置屬性、配置文件管理）能力。該技術(shù)解決了分布式集群中應(yīng)用系統(tǒng)的一致性問(wèn)題，提供類似于文件系統(tǒng)的目錄節(jié)點(diǎn)樹方式的數(shù)據(jù)存儲(chǔ)，Zookeeper作用主要是用來(lái)維護(hù)和監(jiān)控存儲(chǔ)數(shù)據(jù)的狀態(tài)變化，通過(guò)監(jiān)控這些數(shù)據(jù)狀態(tài)的變化，達(dá)到基于數(shù)據(jù)的集群管理。Zookeeper同時(shí)提供分布式鎖功能，為跨機(jī)器跨進(jìn)程提供并發(fā)調(diào)用的支持。

Zookeeper集群配置管理配合Git完成配置的歸檔與更新，Zookeeper推送到所有觀察訂閱這個(gè)節(jié)點(diǎn)的服務(wù)器，服務(wù)器更新配置，所有服務(wù)器完成一次更新操作[9]。

2.2消息總線（RabbitMQ）

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

RabbitMQ提供如點(diǎn)對(duì)點(diǎn)、RPC、訂閱發(fā)布和文件傳輸4種工作模式，包含了主動(dòng)獲取消息、被動(dòng)接收消息、執(zhí)行錯(cuò)誤代號(hào)和執(zhí)行錯(cuò)誤描述等多項(xiàng)定制接口特性。RabbitMQ運(yùn)行如圖2所示。

2.3服務(wù)網(wǎng)關(guān)

使用服務(wù)網(wǎng)關(guān)實(shí)現(xiàn)微服務(wù)架構(gòu)的部分分布式服務(wù)的路由轉(zhuǎn)發(fā)[11]。通過(guò)服務(wù)網(wǎng)關(guān)統(tǒng)一向外系統(tǒng)提供Rest API、RPC API或者自定義網(wǎng)絡(luò)協(xié)議接口。服務(wù)網(wǎng)關(guān)包含了對(duì)請(qǐng)求的路由和過(guò)濾2個(gè)最主要的功能。其中，路由功能負(fù)責(zé)將外部請(qǐng)求轉(zhuǎn)發(fā)到具體的微服務(wù)實(shí)例上，是實(shí)現(xiàn)外部訪問(wèn)統(tǒng)一入口的基礎(chǔ)[12]。而過(guò)濾器功能則負(fù)責(zé)對(duì)請(qǐng)求的處理過(guò)程進(jìn)行干預(yù)，是實(shí)現(xiàn)請(qǐng)求校驗(yàn)、服務(wù)聚合等功能的基礎(chǔ)。

服務(wù)網(wǎng)關(guān)和Zookeeper進(jìn)行整合，將服務(wù)網(wǎng)關(guān)自身注冊(cè)為Zookeeper服務(wù)治理下的應(yīng)用，同時(shí)從Zookeeper中獲得其他微服務(wù)的消息，即以后的訪問(wèn)微服務(wù)都是通過(guò)服務(wù)網(wǎng)關(guān)跳轉(zhuǎn)后獲得，服務(wù)網(wǎng)關(guān)代理設(shè)計(jì)如圖3所示。

2.4虛擬IP與服務(wù)容災(zāi)

使用開源路由軟件Keepalived實(shí)現(xiàn)微服務(wù)架構(gòu)的虛擬IP管理（服務(wù)高可用）能力。Keepalived是一種高性能的服務(wù)器高可用或熱備解決方案，用來(lái)防止服務(wù)器單點(diǎn)故障的發(fā)生，可以實(shí)現(xiàn)子設(shè)備監(jiān)控服務(wù)的高可用。

Keepalived以VRRP協(xié)議為實(shí)現(xiàn)基礎(chǔ)，用VRRP協(xié)議來(lái)實(shí)現(xiàn)高可用性。VRRP協(xié)議是用于實(shí)現(xiàn)節(jié)點(diǎn)冗余的協(xié)議，將2個(gè)或多個(gè)節(jié)點(diǎn)虛擬成一個(gè)節(jié)點(diǎn)，對(duì)外提供虛擬節(jié)點(diǎn)IP（一個(gè)或多個(gè)），而在節(jié)點(diǎn)組內(nèi)部，如果實(shí)際擁有這個(gè)對(duì)外IP的節(jié)點(diǎn)且工作正常的話就是Master，或者通過(guò)算法選舉產(chǎn)生，Master實(shí)現(xiàn)針對(duì)虛擬節(jié)點(diǎn)IP的各種功能，如設(shè)備監(jiān)控、監(jiān)控?cái)?shù)據(jù)的轉(zhuǎn)發(fā)等；其他節(jié)點(diǎn)不擁有該虛擬IP，狀態(tài)是Backup，除了接收Master的VRRP狀態(tài)通告信息外，不執(zhí)行對(duì)外的功能。當(dāng)主機(jī)失效時(shí)，Backup將接管原先Master的功能。VRRP協(xié)議使用多播數(shù)據(jù)來(lái)傳輸VRRP數(shù)據(jù)，VRRP數(shù)據(jù)使用特殊的虛擬源MAC地址而不是自身網(wǎng)卡的MAC地址發(fā)送數(shù)據(jù)，VRRP運(yùn)行時(shí)只有Master節(jié)點(diǎn)定時(shí)發(fā)送VRRP通告信息，表示Master工作正常以及虛擬節(jié)點(diǎn)IP（組）；Backup只接收VRRP數(shù)據(jù)，不發(fā)送數(shù)據(jù)。如果一定時(shí)間內(nèi)沒(méi)有接收到Master的通告信息，各Backup將宣告自己成為Master，發(fā)送通告信息，重新進(jìn)行Master選舉狀態(tài)。Keepalived架構(gòu)如圖4所示。

2.5 RPC通信中間件

使用開源消息通信中間件框架ICE實(shí)現(xiàn)微服務(wù)架構(gòu)算法服務(wù)之間的RPC調(diào)用與服務(wù)指令控制管理，以及統(tǒng)一算法接口標(biāo)準(zhǔn)能力。

2.6服務(wù)代理守護(hù)進(jìn)程

服務(wù)代理守護(hù)進(jìn)程實(shí)現(xiàn)微服務(wù)架構(gòu)的服務(wù)啟停、服務(wù)監(jiān)控、服務(wù)腳本維護(hù)、服務(wù)部署和卸載等能力，對(duì)整個(gè)微服務(wù)架構(gòu)中的支撐服務(wù)和業(yè)務(wù)服務(wù)進(jìn)行管控。

服務(wù)代理守護(hù)進(jìn)程以獨(dú)立的進(jìn)程運(yùn)行在各個(gè)物理機(jī)節(jié)點(diǎn)或虛擬機(jī)節(jié)點(diǎn)上，守護(hù)進(jìn)程與平臺(tái)管理中心服務(wù)端以TCP的方式進(jìn)行通信，作為框架的基礎(chǔ)功能部分，通過(guò)接口暴露及消息訂閱方式對(duì)指定微服務(wù)進(jìn)行啟?？刂?。代理守護(hù)進(jìn)程如圖5所示。

2.7微服務(wù)管理中心

微服務(wù)管理中心實(shí)現(xiàn)微服務(wù)架構(gòu)的服務(wù)治理、服務(wù)監(jiān)控、服務(wù)配置、日志管理和用戶權(quán)限能力，服務(wù)管理中心提供可視化的Web頁(yè)面對(duì)服務(wù)器軟硬件進(jìn)行管理。

服務(wù)管理中心集成了服務(wù)注冊(cè)、服務(wù)部署、服務(wù)卸載、服務(wù)啟停和服務(wù)主備切換等功能，為已存在或正在開發(fā)的應(yīng)用或服務(wù)，以及復(fù)雜網(wǎng)絡(luò)環(huán)境的組件化和服務(wù)化軟件系統(tǒng)提供部署、運(yùn)行和管理的支撐和基礎(chǔ)環(huán)境。服務(wù)管理中心可動(dòng)態(tài)地在微服務(wù)架構(gòu)平臺(tái)中注冊(cè)（新增）和注銷（卸載）業(yè)務(wù)服務(wù)，服務(wù)管理中心能最大限度地?cái)U(kuò)展服務(wù)數(shù)量（僅僅受限于服務(wù)器硬件資源環(huán)境）。

管理中心軟件本身帶有失效重啟功能，負(fù)責(zé)跟所有服務(wù)節(jié)點(diǎn)機(jī)器的守護(hù)進(jìn)程進(jìn)行通信，實(shí)現(xiàn)遠(yuǎn)程監(jiān)控微服務(wù)進(jìn)程的功能。

基于微服務(wù)架構(gòu)形態(tài)下的集中監(jiān)控采用B/S與C/S兼容的架構(gòu)模式，服務(wù)器端開發(fā)語(yǔ)言使用Java，C++及少量Python，客戶端使用瀏覽器或者基于Qt開發(fā)的桌面程序進(jìn)行展示。

為了可靈活構(gòu)建集中監(jiān)控中的業(yè)務(wù)應(yīng)用，微服務(wù)架構(gòu)的服務(wù)器端在數(shù)據(jù)持久化時(shí)，使用數(shù)據(jù)去中心化的思想，將微服務(wù)所對(duì)應(yīng)的服務(wù)模塊持久數(shù)據(jù)進(jìn)行分庫(kù)設(shè)計(jì)，多個(gè)服務(wù)之間的設(shè)計(jì)保持相互獨(dú)立，數(shù)據(jù)也保持獨(dú)立性。每個(gè)微服務(wù)都有自己對(duì)應(yīng)的私有數(shù)據(jù)庫(kù)，其他微服務(wù)不能直接訪問(wèn)，而基于多個(gè)微服務(wù)形成的上層業(yè)務(wù)數(shù)據(jù)通過(guò)對(duì)應(yīng)的業(yè)務(wù)形態(tài)去任意組合數(shù)據(jù)。微服務(wù)架構(gòu)主要包含以下關(guān)鍵技術(shù)設(shè)計(jì)。

3.1服務(wù)與設(shè)備監(jiān)控設(shè)計(jì)

服務(wù)與設(shè)備監(jiān)控實(shí)現(xiàn)對(duì)服務(wù)節(jié)點(diǎn)運(yùn)行資源和服務(wù)健康狀態(tài)的監(jiān)視，包括軟件和硬件環(huán)境、虛擬機(jī)資源及其運(yùn)行狀態(tài)等[14]。3.1.1功能設(shè)計(jì)

通過(guò)實(shí)現(xiàn)SNMP代理（AGENT）和自陷（TRAP）的方式，支持配置相關(guān)監(jiān)視參數(shù)，對(duì)故障進(jìn)行告警等功能，服務(wù)監(jiān)視流程如圖6所示。

監(jiān)控服務(wù)通過(guò)SNMP協(xié)議獲取服務(wù)節(jié)點(diǎn)信息和服務(wù)運(yùn)行狀態(tài)，同時(shí)可以向SNMP代理發(fā)送配置參數(shù)，配置服務(wù)故障告警門限、TRAP地址等。SNMP TRAP通過(guò)監(jiān)聽162端口，接收 SNMP AGENT發(fā)送的TRAP事件。

3.1.2監(jiān)控內(nèi)容設(shè)計(jì)

服務(wù)節(jié)點(diǎn)資源監(jiān)控主要針對(duì)物理機(jī)資源進(jìn)行監(jiān)視，包含服務(wù)監(jiān)控、服務(wù)信息上報(bào)、服務(wù)監(jiān)控信息收集、服務(wù)調(diào)用信息獲取和服務(wù)調(diào)用信息緩存等模塊。服務(wù)監(jiān)控模塊主要提供服務(wù)信息上報(bào)和服務(wù)監(jiān)控信息緩存的功能；服務(wù)信息上報(bào)模塊可對(duì)調(diào)用服務(wù)的信息做記錄，框架會(huì)自動(dòng)收集這些信息，并集中緩存；服務(wù)監(jiān)控信息收集模塊從服務(wù)域的角度收集服務(wù)域內(nèi)所有服務(wù)的監(jiān)控信息并緩存；服務(wù)調(diào)用信息獲取模塊從框架的角度收集所有服務(wù)的監(jiān)控信息，并主動(dòng)上報(bào)監(jiān)控異常信息。

設(shè)備監(jiān)控主要針對(duì)虛擬機(jī)設(shè)備進(jìn)行啟動(dòng)、停止、狀態(tài)上報(bào)和資源信息監(jiān)視等功能。

交換機(jī)監(jiān)視采用SNMP網(wǎng)絡(luò)和資源管理技術(shù)監(jiān)視網(wǎng)絡(luò)交換機(jī)，因此交換機(jī)需要支持SNMP協(xié)議。通過(guò)交換機(jī)提供的MIB信息來(lái)獲取需要監(jiān)視的信息，主要包括交換機(jī)的CPU使用率、內(nèi)存使用率、接口狀態(tài)和接口流量等信息。

3.2負(fù)載均衡設(shè)計(jì)

負(fù)載管理模塊用于統(tǒng)計(jì)和分析集群中各服務(wù)節(jié)點(diǎn)的服務(wù)負(fù)載信息，利用平臺(tái)的分布式協(xié)調(diào)功能監(jiān)控服務(wù)并獲取服務(wù)的調(diào)用信息，計(jì)算出每個(gè)服務(wù)節(jié)點(diǎn)的每個(gè)服務(wù)在一定時(shí)間內(nèi)的觸發(fā)次數(shù)、平均執(zhí)行時(shí)間等負(fù)載信息，并且將這些信息緩存在平臺(tái)監(jiān)控模塊中，供負(fù)載均衡算法使用。

集群負(fù)載管理是集群管理的重要功能，其負(fù)載管理效果直接影響負(fù)載均衡算法的準(zhǔn)確性和整個(gè)集群的處理能力，集群負(fù)載管理能夠真實(shí)反映集群中各服務(wù)的運(yùn)行負(fù)載情況。

3.2.1功能設(shè)計(jì)

負(fù)載均衡協(xié)調(diào)模塊用于為微服務(wù)平臺(tái)集群提供負(fù)載均衡算法和協(xié)調(diào)集群中服務(wù)調(diào)用的功能。微服務(wù)平臺(tái)的負(fù)載均衡協(xié)調(diào)的目標(biāo)是使服務(wù)集群中各服務(wù)節(jié)點(diǎn)盡可能均衡地處理服務(wù)請(qǐng)求，發(fā)揮集群的綜合處理能力，提高服務(wù)效率并且減少等待時(shí)間，避免協(xié)調(diào)不當(dāng)導(dǎo)致部分服務(wù)節(jié)點(diǎn)忙碌、部分服務(wù)節(jié)點(diǎn)閑置的情況。

負(fù)載均衡協(xié)調(diào)模塊負(fù)責(zé)將集群負(fù)載管理模塊緩存的服務(wù)負(fù)載信息收集，并生成可供負(fù)載均衡算法使用的數(shù)據(jù)對(duì)象。負(fù)載均衡算法運(yùn)行時(shí)，直接從已生成的數(shù)據(jù)對(duì)象中計(jì)算，提高計(jì)算效率。

負(fù)載均衡協(xié)調(diào)模塊為服務(wù)集群提供3種負(fù)載均衡算法，供服務(wù)調(diào)用配置模塊選擇。3種算法如下：

①輪詢算法：假設(shè)所有服務(wù)器的處理性能都相同，不關(guān)心每臺(tái)服務(wù)器的當(dāng)前連接數(shù)和響應(yīng)速度，把請(qǐng)求輪流分配給內(nèi)部的服務(wù)器。

②時(shí)間最小算法：服務(wù)調(diào)用時(shí)，考慮各節(jié)點(diǎn)的負(fù)載情況和服務(wù)的平均處理時(shí)間，按照處理比例和概率的優(yōu)化算法對(duì)已生成的數(shù)據(jù)對(duì)象進(jìn)行計(jì)算，為服務(wù)調(diào)用分配一個(gè)適當(dāng)?shù)姆?wù)節(jié)點(diǎn)進(jìn)行調(diào)用。

③通信頻次算法：服務(wù)調(diào)用時(shí)，根據(jù)服務(wù)通信的次數(shù)來(lái)進(jìn)行均勻分配調(diào)用請(qǐng)求。

3.2.2流程設(shè)計(jì)

在負(fù)載均衡協(xié)調(diào)模塊收到負(fù)載協(xié)調(diào)請(qǐng)求時(shí)，負(fù)載均衡協(xié)調(diào)流程開始。首先將集群負(fù)載管理在注冊(cè)表的服務(wù)負(fù)載信息進(jìn)行收集，生成需要調(diào)用的服務(wù)的負(fù)載計(jì)算對(duì)象，再調(diào)用負(fù)載均衡算法，對(duì)對(duì)象進(jìn)行計(jì)算，根據(jù)計(jì)算結(jié)果選擇服務(wù)節(jié)點(diǎn)。服務(wù)端調(diào)用算法服務(wù)的負(fù)載管理流程設(shè)計(jì)如圖7所示。

服務(wù)端服務(wù)組合流程調(diào)用分成2類服務(wù)調(diào)用：分布式服務(wù)和主從服務(wù)調(diào)用。分布式服務(wù)將自身注冊(cè)到服務(wù)注冊(cè)中心，在組合服務(wù)調(diào)用時(shí)，分布式服務(wù)代理通過(guò)注冊(cè)中心獲取當(dāng)前的服務(wù)信息，并按照負(fù)載策略獲取一個(gè)滿足要求的服務(wù)節(jié)點(diǎn)發(fā)起RPC請(qǐng)求并獲取結(jié)果；主從服務(wù)將虛擬IP配置信息持久化在數(shù)據(jù)庫(kù)中，主從服務(wù)代理通過(guò)數(shù)據(jù)庫(kù)獲取當(dāng)前服務(wù)對(duì)應(yīng)的虛擬IP，并通過(guò)虛擬IP發(fā)起RPC請(qǐng)求獲取結(jié)果；組合服務(wù)執(zhí)行引擎匯總分布式服務(wù)B代理和主從服務(wù)C代理的結(jié)果數(shù)據(jù)，最后將數(shù)據(jù)作為算法服務(wù)D代理的輸入?yún)?shù)發(fā)起RPC調(diào)用并得到最終結(jié)果。

3.3消息總線設(shè)計(jì)

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

3.3.1管理流程設(shè)計(jì)

消息總線管理流程設(shè)計(jì)如圖8所示。

客戶端調(diào)用消息總線客戶端SDK庫(kù)，初始化發(fā)布端和訂閱端程序（創(chuàng)建交換器和隊(duì)列，并將二者進(jìn)行邏輯綁定），創(chuàng)建TCP連接，消息發(fā)布者和消息訂閱者都是通過(guò)TCP連接到消息總線的服務(wù)端。

TCP連接建立之后需要建立虛擬連接（Channel），Channel建立在上述TCP連接中，數(shù)據(jù)流動(dòng)都是在Channel中進(jìn)行的。對(duì)于操作系統(tǒng)來(lái)說(shuō)，建立和關(guān)閉TCP連接是有代價(jià)的，頻繁地建立關(guān)閉TCP連接對(duì)于系統(tǒng)的性能有很大的影響，而且TCP的連接數(shù)也有限制，這也限制了系統(tǒng)處理高并發(fā)的能力。但是，在TCP連接中建立Channel是沒(méi)有上述代價(jià)的。對(duì)于發(fā)布端或者訂閱端來(lái)說(shuō)，可以并發(fā)地使用多個(gè)Channel進(jìn)行消息的發(fā)布或者訂閱。

3.3.2性能設(shè)計(jì)

在RabbitMQ的訂閱/發(fā)布主題且數(shù)據(jù)持久化的測(cè)試過(guò)程中，隨著單節(jié)點(diǎn)訂閱用戶數(shù)的增多，網(wǎng)絡(luò)帶寬使用率也會(huì)隨之增加，直至壓滿（現(xiàn)有環(huán)境為千兆網(wǎng)絡(luò)和千兆網(wǎng)卡，在速度達(dá)到110 Mbps及以上之后網(wǎng)絡(luò)使用率達(dá)到最大值，即已壓滿），同時(shí)同等訂閱數(shù)條件下，網(wǎng)絡(luò)帶寬的使用率會(huì)隨著訂閱主題數(shù)據(jù)量的增加而增加，直至壓滿。故在現(xiàn)有場(chǎng)景下的性能場(chǎng)景測(cè)試瓶頸來(lái)自于網(wǎng)絡(luò)，通過(guò)節(jié)點(diǎn)擴(kuò)展（增加RabbitMQ節(jié)點(diǎn)數(shù)）可以得到更大的數(shù)據(jù)承擔(dān)流量。

為了使網(wǎng)絡(luò)帶寬的利用率達(dá)到最大，對(duì)消息隊(duì)列的傳輸情況進(jìn)行了測(cè)試（發(fā)布者100，訂閱者100的情況下），測(cè)試結(jié)果如表1所示。

根據(jù)該性能測(cè)試數(shù)據(jù)分析，在用戶所攜消息數(shù)據(jù)包大小為24 KB時(shí)網(wǎng)絡(luò)帶寬使用率已經(jīng)達(dá)到峰值，為保持服務(wù)器的穩(wěn)定性和可靠性，服務(wù)框架內(nèi)各服務(wù)間傳輸?shù)膯蝹€(gè)數(shù)據(jù)包攜帶數(shù)據(jù)不應(yīng)超過(guò)24 KB。

本文研究并實(shí)現(xiàn)了一種國(guó)產(chǎn)化航天測(cè)控集中監(jiān)控軟件架構(gòu)，其基于微服務(wù)架構(gòu)進(jìn)行設(shè)計(jì)，將緊耦合的系統(tǒng)劃分為面向業(yè)務(wù)的、粗粒度、松耦合、無(wú)狀態(tài)的服務(wù)，并提供了一種屏蔽了復(fù)雜技術(shù)細(xì)節(jié)的標(biāo)準(zhǔn)開發(fā)框架，使得研發(fā)人員只需要關(guān)注業(yè)務(wù)代碼的編寫和微服務(wù)的配置即可。同時(shí)采用統(tǒng)一化的平臺(tái)標(biāo)準(zhǔn)及規(guī)范，制定服務(wù)接口規(guī)范與交互規(guī)范標(biāo)準(zhǔn)，從而監(jiān)控和約束軟件的質(zhì)量，確保軟件的通用性、伸縮性、魯棒性以及穩(wěn)定性。依賴該微服務(wù)框架，可以快速建立起一個(gè)高內(nèi)聚、低耦合的基于微服務(wù)架構(gòu)的集中監(jiān)控軟件，從而可以快速實(shí)現(xiàn)軟件定制，提高產(chǎn)品序列、豐富服務(wù)倉(cāng)庫(kù)，形成復(fù)用性高的產(chǎn)品或者功能，從而快速滿足和響應(yīng)客戶的需求。

參考文獻(xiàn)

[1]王文龍.分布式軟件開發(fā)平臺(tái)的設(shè)計(jì)與實(shí)施[D].北京：北京郵電大學(xué)，2011.

[2]李春霞.微服務(wù)架構(gòu)研究概述[J].軟件導(dǎo)刊，2019，18（8）：1-3.

[3]崔方園.支持分布式協(xié)同開發(fā)的軟件配置管理系統(tǒng)研究[D].大連：大連海事大學(xué)，2009.

[4]林旭新，陳文吉，鄭大鵬.一種面向服務(wù)的跨平臺(tái)實(shí)時(shí)信息發(fā)布及交流軟件架構(gòu)[J].現(xiàn)代計(jì)算機(jī)（專業(yè)版），2014（8）： 77-80.

[5]史俊.分布式軟件技術(shù)及其應(yīng)用研究[J].無(wú)線互聯(lián)科技， 2012，12：68.

[6]王義.微服務(wù)架構(gòu)特點(diǎn)、技術(shù)趨勢(shì)及在行業(yè)應(yīng)用中關(guān)鍵問(wèn)題研究[J].軟件，2020，41（6）：132-136.

[7]周家昊.微服務(wù)架構(gòu)關(guān)鍵技術(shù)研究與通用框架實(shí)現(xiàn)[D].廣州：廣東工業(yè)大學(xué)，2019.

[8]徐西岳.分布式系統(tǒng)中微服務(wù)架構(gòu)的研究及應(yīng)用[D].青島：山東科技大學(xué)，2019.

[9]苗凡，閻志遠(yuǎn)，戴琳琳.基于Zookeeper的配置管理中心設(shè)計(jì)與實(shí)現(xiàn)[J].鐵路計(jì)算機(jī)應(yīng)用，2018，27（10）：26-29.

[10]胡雪婧.基于ZooKeeper的分布式系統(tǒng)的消息發(fā)送機(jī)制的設(shè)計(jì)與實(shí)現(xiàn)[D].長(zhǎng)春：吉林大學(xué)，2016.

[11]周國(guó)興.基于ZooKeeper的服務(wù)集成框架研究[D].南京：東南大學(xué)，2019.

[12]董龍成.基于ZooKeeper的配置中心系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[D].西安：西安電子科技大學(xué)，2018.

[13]黃毅斐.基于ZooKeeper的分布式同步框架設(shè)計(jì)與實(shí)現(xiàn)[D].杭州：浙江大學(xué)，2012.

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