基于微服务架构的航天测控系统设计

2022-05-30操礼长王小雨申健王小旗邓德鑫

计算机与网络 2022年13期

操礼长王小雨申健王小旗邓德鑫

摘要：传统的航天测控系统监控软件采用单体式应用架构，存在维护难度大、周期长、扩展性差等弊端，并且无法满足资源可动态重构扩展的需求。基于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申请分布式锁进行主备切换。故障服务器恢复正常后，保持运行状态不变。