基于微服務架構的航天測控系統設計

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

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

關鍵詞：微服務架構；Redis；主備切換；分布式鎖

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

0引言

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

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

1基于IceGrid的微服務架構

1.1微服務架構

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

1.2基于IceGrid的微服務架構

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

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

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

1.3服務的發布與調用

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

服務的發布流程所示：

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

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

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

①監控客戶端首先根據服務標識訪問服務定位服務；

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

③監控客戶端收到查詢結果后，定位到服務所在網絡位置，操作對應的服務接口調用服務。

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

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

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

2.1 Redis主備仲裁及切換機制

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

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

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

仲裁具體流程如下：

①監控系統初始啟動時，服務器A機、B機的“Redis主備狀態”均為備用。

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

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

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

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

2.2主備服務切換機制

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

2.2.1分布式鎖的申請

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

2.2.2分布式鎖的續約

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

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

2.2.3主備服務切換流程

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

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

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

3結束語

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

參考文獻

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

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

[3]田浩.基于SOA的高并發與高可用網站開發框架設計與實現[D].呼和浩特：內蒙古大學，2017.

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

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

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

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

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

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