一种国产化航天测控集中监控软件架构设计

孟景涛 王松鹤 武鹏 郭涛 孙婧

摘要：随着国产化新研航天测控软件的规模越来越庞大，快速定制、代码复用的需求越来越迫切。许多应用场景用户都提出集中监控的需求，且系统监控软件要采用微服务或多进程的思路进行设计。提出了一套以微服务平台为基础进行开发的集中监控软件的架构设计方案，服务的进程之间相互隔离，独立开发、部署和发布，支持多种客户端访问和跨平台的国产化操作系统。通过这种微服务形态的软件架构，可以实现测控领域各类软件的快速定制，形成复用性高的产品或者功能，从而快速稳定地完成软件开发过程。

关键词：分布式；微服务；集中监控；国产化

中图分类号：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.