基于微服務架構(gòu)的航天測控系統(tǒng)設計

操禮長 王小雨 申健 王小旗 鄧德鑫

摘要：傳統(tǒng)的航天測控系統(tǒng)監(jiān)控軟件采用單體式應用架構(gòu)，存在維護難度大、周期長、擴展性差等弊端，并且無法滿足資源可動態(tài)重構(gòu)擴展的需求?；贗ceGrid微服務架構(gòu)的系統(tǒng)監(jiān)控軟件具有良好的穩(wěn)定性與分布式能力，可以很好地解決上述問題。闡述了IceGrid微服務架構(gòu)的基礎(chǔ)框架，并提出基于Redis的服務主備仲裁機制與競爭分布式鎖的服務主備切換方式，實現(xiàn)各類服務自主切換，并且有效解決了系統(tǒng)網(wǎng)絡不穩(wěn)定或者單服務器死機等異常情況下系統(tǒng)出現(xiàn)嚴重卡頓甚至數(shù)據(jù)丟失的問題，提高了航天測控系統(tǒng)運行的穩(wěn)定性與可靠性。

關(guān)鍵詞：微服務架構(gòu)；Redis；主備切換；分布式鎖

中圖分類號：TP311文獻標志碼：A文章編號：1008-1739（2022）13-64-5

0引言

隨著航天測控系統(tǒng)監(jiān)控軟件的業(yè)務功能不斷擴展和復雜化，軟件生態(tài)系統(tǒng)中模塊與組件之間的調(diào)用依賴關(guān)系也變得越來越復雜，傳統(tǒng)單體式應用架構(gòu)存在維護難度大、周期長、擴展性差、升級難度高等弊端[1]，并且新組件的大量引入與迭代數(shù)據(jù)的快速更新，很容易導致軟件生態(tài)系統(tǒng)的不穩(wěn)定和不平衡[2]。另一方面，為了提高共用設備資源的利用率，實現(xiàn)測控設備快速接入能力，航天測控資源重組系統(tǒng)對監(jiān)控軟件提出可動態(tài)重構(gòu)擴展的需求，即資源重組系統(tǒng)不停機接入的需求。故由單體式應用架構(gòu)轉(zhuǎn)為微服務架構(gòu)是解決復雜問題，以及滿足資源重組系統(tǒng)不停機接入需求的必經(jīng)途徑[3]。

網(wǎng)絡通信引擎（Internet Communications Engine，ICE）是ZeroC公司開發(fā)的一款高效的開源中間件平臺，可以快速開發(fā)出高效的分布式軟件[4]。IceGrid服務是ICE中間件的服務注冊中心，客戶端的所有服務定位請求都需通過IceGrid進行處理，當IceGrid發(fā)生故障，整個服務集群將會處于癱瘓狀態(tài)，導致系統(tǒng)無法正常工作，雖然IceGrid實現(xiàn)了高可用，但是在進行故障切換時，主節(jié)點和從節(jié)點之間的關(guān)系轉(zhuǎn)換卻不是完全自動的，需要人工進行處理，對于大型的分布式系統(tǒng)是不現(xiàn)實的[5]。本文提出的基于Redis的主備服務仲裁及切換機制可以實現(xiàn)主備服務自主切換，并且在系統(tǒng)網(wǎng)絡不穩(wěn)定或者單服務器死機等異常情況下，仍能保證航天測控系統(tǒng)的正常運行。

1基于IceGrid的微服務架構(gòu)

1.1微服務架構(gòu)

微服務架構(gòu)是一種將單一應用拆分為多個子服務的系統(tǒng)服務架構(gòu)，采用輕量通信機制進行服務之間的相互通信、協(xié)調(diào)與配合，每個服務都對應一個獨立的業(yè)務模塊，能夠獨立運行、獨立部署、獨立升級，不同服務間既相互獨立又相互配合。故微服務之間高內(nèi)聚低耦合的特點，可極大地提高系統(tǒng)架構(gòu)的容錯性、靈活性與可擴展性，有效避免因單個服務更新導致整個系統(tǒng)升級的問題[6]。

1.2基于IceGrid的微服務架構(gòu)

在以ICE中間件內(nèi)建的多種服務構(gòu)建的微服務框架中，IceGrid是整個框架的核心服務，為客戶端提供位置請求、應用部署、負載均衡等服務，為服務端提供服務管理和服務發(fā)現(xiàn)等[7]。IceGrid分布式部署如圖1所示，主要組件包括服務注冊中心、服務節(jié)點以及消息中心。IceGrid即為注冊中心Registry與Node服務器的集合，注冊中心和Node監(jiān)控服務器相互配合共同管理應用程序的服務進程。每一個應用程序都被分成了若干進程服務分別部署在不同的Node監(jiān)控服務器中，由Node監(jiān)控服務器對部署在該服務器中的所有服務進行管理。

服務注冊中心是分布式監(jiān)控系統(tǒng)的服務管理中心，為了監(jiān)控系統(tǒng)的可靠性，采用一主一從部署策略。注冊中心的信息寫在Node監(jiān)控服務器的配置文件中，Node監(jiān)控服務器啟動后向所有注冊中心進行動態(tài)注冊。服務節(jié)點為2臺監(jiān)控服務器，負責與注冊中心直接通信以及服務容器的生命周期管理。服務容器是ICE服務的管理容器，采取集中式的策略對服務進行加載、管理，各類服務被設計為可動態(tài)加載的組件以動態(tài)庫的形式按需配置到服務容器，該方式解耦了監(jiān)控服務器和服務，可以按照需要組合服務或分離服務。

注冊中心、Node服務器、服務容器的關(guān)系連接如圖2所示，在系統(tǒng)正常運行時，Node服務器會對服務容器進行全生命周期管理，包括啟動、檢測、故障重啟等。Node服務器會向所有注冊中心定時上報自身及服務容器的運行狀態(tài)，所有注冊中心都會自動感知各類服務的工作狀態(tài)。

1.3服務的發(fā)布與調(diào)用

微服務平臺的服務通信在底層都是基于網(wǎng)絡來完成，對應用層則主要有服務調(diào)用和消息發(fā)布2種方式。微服務平臺服務發(fā)布與調(diào)用流程如圖3所示。服務在發(fā)生調(diào)用時，服務消費者向注冊中心查詢服務提供者，注冊中心會向服務消費者提供一個可用的服務信息列表。

服務的發(fā)布流程所示：

①首先注冊中心根據(jù)IceGrid的配置信息將服務發(fā)布到對應的Node節(jié)點，并啟動對應的服務定位服務；

②在Node節(jié)點接收服務文件之后，根據(jù)服務配置文件啟動對應的服務程序。

完成上述部署過程后，整個分布式部署即完成，系統(tǒng)此時可對外提供服務。服務調(diào)用過程如下：

①監(jiān)控客戶端首先根據(jù)服務標識訪問服務定位服務；

②服務定位服務從注冊中心獲取對應的服務所在節(jié)點信息并將結(jié)果返回監(jiān)控客戶端；

③監(jiān)控客戶端收到查詢結(jié)果后，定位到服務所在網(wǎng)絡位置，操作對應的服務接口調(diào)用服務。

2服務主備仲裁及切換機制

Redis全名為遠程字典服務，是一個基于內(nèi)存的鍵—值數(shù)據(jù)庫，很大程度上彌補了內(nèi)存緩沖存儲的匱乏[8]。因其具有讀取速度快、支持發(fā)布/訂閱模式、高可用以及分布式等特點，在各大系統(tǒng)中廣泛應用。

監(jiān)控軟件的主備服務仲裁基本策略為：在系統(tǒng)初始化啟動后，監(jiān)控服務器根據(jù)仲裁機制首先選舉出主用Redis、備用Redis，每類服務向主用Redis申請分布式鎖，根據(jù)申請的狀態(tài)來決定每類服務的主備，并且在異常發(fā)生時自動開展服務主備切換。

2.1 Redis主備仲裁及切換機制

Redis內(nèi)存數(shù)據(jù)庫在監(jiān)控服務器A機、B機中各部署一套，互為主備關(guān)系。仲裁機制中對Redis的主備狀態(tài)進行決策仲裁的服務為Redis-Cache，以負載均衡的形式部署于監(jiān)控系統(tǒng)2臺服務器中，該服務與Redis共同組成分布式內(nèi)存數(shù)據(jù)庫集群，系統(tǒng)監(jiān)控軟硬件部署如圖4所示。

仲裁機制如圖5所示，監(jiān)控服務器中運行的所有服務會將各自內(nèi)部狀態(tài)信息每秒定時存入到主用Redis內(nèi)存數(shù)據(jù)庫中，存入的信息中包含時間標簽。Redis-Cache服務每秒從Redis內(nèi)存數(shù)據(jù)庫中獲取所有服務的信息，根據(jù)這些信息，按照仲裁策略進行服務仲裁。

為了保證仲裁機制的可靠性，利用系統(tǒng)自帶的監(jiān)控網(wǎng)絡交換機作為第三方，通過實時監(jiān)測Redis與其他Redis、監(jiān)控網(wǎng)絡交換機的通斷狀態(tài)來進行主備Redis的仲裁和切換。其中Redis與監(jiān)控網(wǎng)絡交換機的通斷狀態(tài)判別方法為：系統(tǒng)運行過程中，監(jiān)控服務器與網(wǎng)絡交換機管理IP進行ping操作，如果交換機管理IP連續(xù)ping通，則認為Redis與網(wǎng)絡交換機狀態(tài)通，反之則不通。RedisA，RedisB間狀態(tài)通斷判別方法為：系統(tǒng)運行過程中，監(jiān)控服務器A機、B機一直互發(fā)心跳數(shù)據(jù)包，雙方收到則雙方狀態(tài)為通，否則為不通。心跳數(shù)據(jù)包內(nèi)容有：當前主用Redis的IP和端口（初始狀態(tài)下沒有主用Redis的情況下，IP和端口都填空）、本地服務器IP地址、本地Redis主備狀態(tài)、成為主用Redis的時間、與網(wǎng)絡交換機的通斷狀態(tài)。

仲裁具體流程如下：

①監(jiān)控系統(tǒng)初始啟動時，服務器A機、B機的“Redis主備狀態(tài)”均為備用。

②如果服務器A機、B機收到對方心跳數(shù)據(jù)包，根據(jù)“本地Redis主備狀態(tài)”判斷是否存在主用Redis，如果存在主用Redis，維持現(xiàn)有主備機狀態(tài)，否則選擇“服務器IP地址”較小的一方作為主機。

③如果連續(xù)10 s（可配置）沒有收到對方心跳數(shù)據(jù)包，則需要依據(jù)Redis與網(wǎng)絡交換機（第三方）的通斷狀態(tài)進行判斷。若主用Redis與網(wǎng)絡交換機不通則降自身為備用，否則維持當前狀態(tài)；若備用Redis與網(wǎng)絡交換機不通，則維持當前狀態(tài)，否則將自身升為主機。

④如果連續(xù)10 s（可配置）沒有收到對方心跳數(shù)據(jù)包，服務器A機、B機都與第三方設備斷開，則可能存在雙備Redis的狀態(tài)。后續(xù)在服務器A機、B機收到對方心跳后，根據(jù)“成為主Redis的時間”進行判斷，以成為主機時間最長的Redis優(yōu)先作為主機，如果成為主機時間相同，則以IP最小的Redis優(yōu)先作為主用。

⑤如果連續(xù)10 s（可配置）沒有收到對方心跳數(shù)據(jù)包，服務器A機、B機都與第三方設備連通，則可能存在雙主Redis的狀態(tài)。后續(xù)在服務器A機、B機收到對方心跳后，根據(jù)“成為主Redis的時間”判斷以成為主機時間最長的Redis優(yōu)先作為主機，如果成為主機時間相同則以IP最小的優(yōu)先作為主機。

2.2主備服務切換機制

主備服務根據(jù)預先配置部署在監(jiān)控服務器A機、B機中，每類服務向主用Redis采用競爭分布式鎖的方式來決定主備服務的控制權(quán)。分布式鎖是指在分布式的場景下，通過鎖機制使訪問某一共享資源的多個客戶端互斥的對資源進行訪問的一種方式[9]。分布式鎖的構(gòu)建規(guī)則為：同類型主備服務的鎖Key相同，不同類型的主備服務的鎖不相同，且相同Key的分布式鎖在集群中只存在一個，只能夠被集群內(nèi)的一個服務獲取并使用。每個服務根據(jù)該Key并附帶鎖的超時時間去申請該鎖，并根據(jù)申請的狀態(tài)來決定服務的主備，當異常發(fā)生時開展主備切換。

2.2.1分布式鎖的申請

系統(tǒng)監(jiān)控服務器程序啟動之后，所有主備類型的服務均默認為備用。主用Redis根據(jù)規(guī)則構(gòu)建分布式鎖，各類服務定時（每秒）申請Redis分布式鎖，如果申請到鎖，則將該服務升為主用，失去鎖則將該服務降為備用，服務申請鎖流程如圖6所示。

2.2.2分布式鎖的續(xù)約

分布式鎖申請均附帶了超時時間，即超時時間到達后，該鎖自動釋放。續(xù)鎖只針對主服務，備服務主要負責申請鎖。續(xù)鎖機制主要為了保證在獲得鎖的服務異常退出后，系統(tǒng)可以將該鎖回收。主服務續(xù)鎖流程如圖7所示。

主用服務申請到鎖之后，在每秒定時時鐘周期申請續(xù)鎖，如果續(xù)鎖失敗，則進行累計續(xù)鎖計數(shù)（累計續(xù)鎖次數(shù)可配置，本系統(tǒng)配置為5次）。如果連續(xù)續(xù)鎖累計失敗次數(shù)超過閾值，則降低自身服務為備用。如果在閾值時間內(nèi)有續(xù)鎖成功，則清空失敗累計計數(shù)值，并維持自身主用的狀態(tài)。若主用服務續(xù)鎖失敗，則分布鎖將被釋放，由于備用服務也在定時申請分布式鎖，因此備用服務將會申請到鎖并提升自身作為主用服務來執(zhí)行業(yè)務運行。

2.2.3主備服務切換流程

主備服務切換流程如圖8所示，系統(tǒng)初始化運行后，會自動啟動Redis，若Redis工作不正?；蛭磫?，由Redis-Cache保證對Redis的重啟工作；若Redis工作正常，各類服務開始向Redis申請分布鎖，申請到鎖的服務為主用服務，未申請到鎖的服務為備用服務，后續(xù)主用服務定時開展續(xù)鎖，保證系統(tǒng)運行的穩(wěn)定性。

系統(tǒng)采用基于Redis的分布式鎖申請與續(xù)鎖機制，使各個服務自主完成主備競爭，在網(wǎng)絡發(fā)生高頻率短間隔的閃爍時，可由分布式鎖的續(xù)約機制來維持現(xiàn)有主備狀態(tài)不會發(fā)生變化。若網(wǎng)絡前后通斷間隔時間超過鎖的續(xù)約時間，服務可自行完成主備切換操作，對系統(tǒng)的自動化運行與穩(wěn)定性無影響。

若單臺服務器出現(xiàn)故障，并且故障服務器上運行主用Redis，根據(jù)Redis仲裁機制，主用Redis降為備用，另一臺服務器中運行的備用Redis自動升為主用，在Redis主備仲裁完成后，各類服務向主用Redis申請分布式鎖進行主備切換。故障服務器恢復正常后，保持運行狀態(tài)不變。

3結(jié)束語

該監(jiān)控軟件平臺已通過測試驗證，并在多套航天測控系統(tǒng)中得以應用，有效規(guī)避了系統(tǒng)網(wǎng)絡不穩(wěn)定或者單服務器死機等異常情況下監(jiān)控系統(tǒng)運行不穩(wěn)定的情況，為航天測控任務的成功執(zhí)行提供保證。隨著技術(shù)的進步，微服務平臺與Redis的發(fā)展必將更加成熟，并應用于各式各樣的系統(tǒng)中。

參考文獻

[1]趙磊，王運成，王娟.微服務在人臉識別考勤系統(tǒng)中的應用[J].電子技術(shù)與軟件工程，2021（13）：30-31.

[2]馮志勇，徐硯偉，薛霄，等.微服務技術(shù)發(fā)展的現(xiàn)狀與展望[J].計算機研究與發(fā)展，2020，57（5）：1103-1122.

[3]田浩.基于SOA的高并發(fā)與高可用網(wǎng)站開發(fā)框架設計與實現(xiàn)[D].呼和浩特：內(nèi)蒙古大學，2017.

[4]江卓逞，黃瑋，曾加剛.基于ICE中間件的分布式應用開發(fā)研究[J].信息與電腦（理論版），2017（9）：38-40.

[5]馮戰(zhàn)勝.基于ICE中間件的改進與實現(xiàn)[D].北京：中國電子科技集團公司電子科學研究院，2019.

[6]鄭文靖，王婷.微服務架構(gòu)研究方法[J].現(xiàn)代信息科技，2019，3（15）：72-73，77.

[7]馮戰(zhàn)勝，張激，彭宏，等.基于Zookeeper的分布式ICE中間件研究[J].計算機系統(tǒng)應用，2018，27（12）：222-226.

[8]王嫣如.Redis消息推送機制應用技術(shù)研究[J].科技廣場， 2016（8）：41-44.

[9]陳鵬.基于分布式緩存和消息中間件的選課系統(tǒng)的設計與實現(xiàn)[D].重慶：重慶大學，2019.