CN112787708B - 基于微服务的卫星地面站监控管理架构 - Google Patents

Abstract

本申请公开了一种基于微服务的卫星地面站监控管理架构，所述架构包括：应用层，用于提供各类应用，完成地面任务的创建和管理、设备的监控和实时报警，查看任务执行状态，完成系统配置管理、数据查询维护，统计地面站运行情况；网关层，用于为外部提供统一访问服务端的负载均衡协调及数据转发功能；服务层，由完成系统业务所需的各类基础服务应用接口API组件封装，用于为应用服务提供服务组件支撑，服务层对各个业务功能进行化管理。本申请使微服务中的每个服务之间可以配置拥有不同的开发环境，开发速度快，部署简单，能够加快产品上线的速度，具有较好的扩展性。

Description

基于微服务的卫星地面站监控管理架构

技术领域

本申请实施例涉及卫星地面站监控管理技术，尤其涉及一种基于微服务的卫星地面站监控管理架构。

背景技术

随着国内遥感卫星地面系统的快速发展和建设，传统架构的地面系统已经无法满足未来发展的需要，同时技术人员在升级和维护时，需要耗费巨大的精力。

在卫星地面站监控管理软件设计和开发过程中，依据传统的单体软件架构设计模式，不具备资源动态弹性扩展的能力，软件研发效率低，更新速度慢，扩展难度高，运维成本代价大。

发明内容

有鉴于此，本申请实施例提供一种基于微服务的卫星地面站监控管理架构。

根据本申请的第一方面，提供一种基于微服务的卫星地面站监控管理架构，微服务采用面向对象中间件(ICE，Internet Communications Engine)作为服务中间件，实现跨平台的接口访问服务和高效数据传输；微服务包括以下至少之一：实时通信微服务、文件通信微服务、任务调度微服务、设备监控微服务、轨道微服务，故障处理微服务、页面展示微服务、应用微服务；所述架构包括：

应用层，用于提供各类应用，完成地面任务的创建和管理、设备的监控和实时报警，查看任务执行状态，完成系统配置管理、数据查询维护，统计地面站运行情况；

网关层，用于为外部提供统一访问服务端的负载均衡协调及数据转发功能；

服务层，由完成系统业务所需的各类基础服务应用接口API组件封装，用于为应用服务提供服务组件支撑，服务层对各个业务功能进行化管理。

资源层是系统的基础支撑层，用于提供系统运行所需的全部操作系统资源和环境。

作为一种实现方式，所述应用层提供的各类应用中包括以下至少之一：任务管理、设备监控、轨道应用、故障诊断、值班统计；所述网关层为外部提供统一访问服务端的负载均衡协调及数据转发功能；

所述服务层包括以下至少之一：服务通信、任务管理服务、设备监控服务、轨道服务、通用服务、服务管理中心；所述服务通信支持以下的通信方式：文件传输协议(FTP，FileTransfer Protocol)、消息队列(MQ，Message Queue)、远程过程调用(RPC，RemoteProcedure Call)、表述性状态传递(REST， Representational State Transfer)；所述任务管理服务包括：计划创建、任务管理、调度管理；所述设备监控服务包括设备控制、状态监视、宏管理；所述轨道服务包括进出站计算、点位计算、轨道管理；所述通用服务包括报警管理、用户管理、日志管理；所述服务管理中心包括配置管理、监控管理、日志管理、注册发现；

所述资源层包括任务数据库、监控数据库、轨道数据库和基本数据库。

作为一种实现方式，所述服务管理中心对每个应用软件服务进行集中式管理，提供新服务的注册发现、服务发布、服务配置管理以及服务动态管理功能；

所述任务管理微服务应用将任务创建、任务管理、任务调度管理封装为微服务；

所述轨道微服务用于提供卫星轨道的管理，提供卫星进出站计算服务以及跟踪点位计算服务；

所述通用微服务用于提供应用运行的通用功能服务，包括用户管理服务、日志管理服务、故障报警服务；

所述设备监控微服务用于提供设备的参数状态监视、命令控制以及宏参数管理组下发功能；

所述服务通信微服务应用提供应用内部各个微服务的通信服务。

作为一种实现方式，微服务之间的业务数据交互基于专用数据总线进行；业务数据交互包含通信与传输、消息分发与订阅、外部通信接口的功能；

微服务容器启动后，服务注册器通过控制台或者界面向服务管理器发送注册消息，完成对外提供的业务服务的微服务注册，同时服务发现器从服务注册中心中获取该微服务调用的服务列表，并缓存到微服务运行时容器的服务提供者列表中。

作为一种实现方式，所述架构还包括微服务调用接口，以实现跨平台的接口访问服务和数据传输，通过客户端访问发布与服务架构节点上的服务进行调用，以进行服务动态构建，基于微服务调用接口的定义文件和接口描述文件，进行服务的开发和部署；

所述服务管理中心采用面向服务的方式，为微服务调用接口提供服务实现：通过对现有服务进行组合，基于第三方服务的封装操作并借助流程定义文件，进行服务之间的流程跳转。

根据本申请实施例的基于微服务的卫星地面站监控管理架构，将微服务的架构方式应用到卫星地面站监控管理软件架构，将传统的抽象、封装为微服务；将功能类似相关的微服务，封装为微服务组，设计了通用微服务组，轨道微服务组，设备监控微服务组，任务管理微服务组等4个微服务组，覆盖了实时通信，文件通信、任务调度、设备监控、轨道计算管理，故障处理、页面展示、应用服务等功能；本申请实施例中的API接口网关负责服务请求路由、组合及协议转换；每个服务之间可以配置拥有不同的开发环境，开发速度快，部署简单，能够加快产品上线的速度，具有较好的扩展性。

附图说明

图1为本申请实施例提供的基于微服务的卫星地面站监控管理架构的组成结构示意图；

图2为本申请实施例提供的微服务架构核心功能示意图；

图3为本申请实施例提供的微服务关联示意图；

图4为本申请实施例提供的接口网关工作流程示意图。

具体实施方式

本申请实施例所要解决的技术问题是，在卫星地面站监控管理软件设计和开发过程中，依据传统的单体软件架构设计模式，不具备资源动态弹性扩展的能力，软件研发效率低，更新速度慢，扩展难度高，运维成本代价大。而近年来微服务架构的广泛应用，提供了能够适应快速开发、迭代升级和灵活部署要求的技术途径。通常地，一个大型的、单体的、复杂的应用系统，按照业务功能或者独立性原则进行组件化、服务化分离，将其拆分成一系列微小的应用服务。微服务架构中，每一个微服务只完成一个特定的功能，服务间通过服务发现的方式相互通信。当需要增加某些功能时，只需要在特定的服务中增加相应的功能即可。此外，微服务架构的服务间独立性较好，可用的开发语言比较灵活，不同的服务甚至可以采用不同的编程语言来实现。本申请实施例基于微服务架构的特点，将其应用到卫星地面站监控管理架构中，以实现卫星地面站监控管理系统的灵活多变、应用增加去除的便捷性。

图1为本申请实施例提供的基于微服务的卫星地面站监控管理架构的组成结构示意图，如图1所示，本申请实施例设计了一种基于微服务的卫星地面站监控管理架构，该架构由应用层、网关层、服务层、资源层组成，同时设计了实时通信微服务，文件通信微服务、任务调度微服务、设备监控微服务、轨道微服务，故障处理微服务、页面展示微服务、应用微服务，每个服务能够独立开发，独立运行，以及独立配置发布。

卫星地面站监控管理架构采用微服务架构进行设计实现，能够将主体业务功能拆分成可独立运行的应用软件服务，借助微服务管理平台能够对每个应用软件服务进行集中式管理。当需要进行业务功能的扩充时，可以通过扩充应用软件服务实现新的业务需求即可，并通过微服务管理平台完成新服务的注册、发布以及启动，实现系统业务功能的在线扩充。

所述应用层提供各类应用，完成地面任务的创建和管理，设备的监控和实时报警，查看任务执行状态，完成系统配置管理、数据查询维护，统计地面站运行情况等功能。

所述网关层为外部提供统一访问服务端的负载均衡协调及数据转发功能。

所述服务层主要由完成系统业务所需的各类基础服务API组件封装，为应用服务提供服务组件支撑，服务层对各个业务功能进行化管理。服务层中包括服务管理中心，通用微服务，轨道微服务，设备监控微服务，任务管理微服务，服务通信。

服务管理中心管理平台能够对每个应用软件服务进行集中式管理。提供新服务的注册发现、服务发布、服务配置管理以及服务动态管理功能。

任务管理微服务将任务创建、任务管理、任务调度管理等封装为微服务；

轨道微服务提供卫星轨道的管理，提供卫星进出站计算服务以及跟踪点位计算服务；

通用微服务提供软件运行的通用功能服务，包括用户管理服务、日志管理服务、故障报警服务等；

设备监控微服务提供设备的参数状态监视、命令控制以及宏参数管理组下发功能；

服务通信微服务提供软件内部各个微服务的通信服务，包括FTP协议、 MQ消息队列协议、RPC远程调用协议、REST协议等。

所述资源层是系统的基础支撑层，提供系统运行所需的全部操作系统资源和环境，包括计算资源、存储资源和服务运行环境等，实现对资源的充分利用，实现外部资源的资源抽象控制层，以及资源调用的透明化。资源层中包括任务数据库、监控数据库、轨道数据库、基本数据库。

任务数据库存储卫星测控接收任务信息以及执行情况，为服务层提供数据支撑；监控数据库存储地面站设备属性，设备状态参数，宏参数；轨道数据库存储卫星轨道参数，卫星星下点信息，卫星过境时间等；基本数据库存储用户信息、日志信息、故障信息、微服务配置信息等。

本申请实施例的基于微服务的卫星地面监控架构能够保证各应用软件服务端独立运行，相互之间不会造成影响。同时，架构为关键的应用软件服务端提供分布式部署与主备管理能力，能够在出现故障时自动完成主备服务节点的切换。

图2为本申请实施例提供的微服务架构核心功能示意图，如图2所示，在微服务容器启动后，服务注册器通过控制台或者界面向服务管理器发送注册消息，完成对外提供的业务服务的微服务注册，同时服务发现器从服务注册中心中获取该微服务调用的服务列表，并缓存到微服务运行时容器的服务提供者列表中。流程队列中包含有待处理的流程队列，服务管理调用流程队列中的队列并进行服务实例化，服务处理基于服务实例化结果进行有状态服务；服务监控对相关服务进行监控，对服务状态进行采集。服务管理中还包括服务发现、服务调用及服务注册中心；服务注册中心负责服务的注册，服务注册包括控制台注册及界面注册等。微服务中还包括服务部署，主要包括服务代理生成、服务组装，服务发布等功能，服务部署将组装或生成的服务向服务管理发送，由服务管理进行服务调用等处理。

本申请实施例中，卫星地面监控架构提供服务调用接口，采用ICE作为服务中间件。实现跨平台的接口访问服务和高效的数据传输，通过ICE客户端访问发布与服务架构节点上ICE服务进行调用，支持ICE服务动态构建，基于ICE 接口的定义文件和接口描述文件，即可实现服务的快速开发和部署。

本申请实施例的基于微服务的卫星地面站监控管理架构中的服务实现及管理，采用面向服务的思想，为ICE接口提供服务实现。实现服务的动态发布和初始化。通过对现有服务的组合，结合第三方服务的封装，借助流程定义文件，进而可以实现复杂的流程跳转要求。

卫星地面监控架构中的微服务之间的业务数据交互，采用专门的数据总线进行处理。数据总线包含通信与传输、消息分发与订阅、外部通信接口等三大类功能。

本申请实施例中，通信与传输类包含协议处理、数据传输、连接调用、连接管理等；消息分发与订阅包含配置管理、主题管理、分发管理、补发管理等。外部通信接口负责各个微服务与外部系统之间的通信协议交互，包括FTP、 TCP、UDP、PDXP、SNMP、消息中间件等协议。

图3为本申请实施例提供的微服务关联示意图，如图3所示，本申请实施例的基于微服务的卫星地面站监控管理架构能够将软件功能中类似相关的一组微服务，封装为微服务组，为此，本申请实施例设计了实时通信微服务，文件通信微服务、任务调度微服务、设备监控微服务、轨道微服务、故障处理微服务、页面展示微服务、应用微服务共8个微服务。具体功能如下：

a)实时通信微服务主要完成网络实时通信的功能，采用Java Socket NIO技术、串口通信技术、简单网络管理协议(SNMP，Simple Network Management Protocol)通信和Web通信技术完成系统与遥感卫星地面站中不同类型、不同品牌、不同型号、不同通信协议的设备之间的通信。包括数据的采集、协议的解析、数据帧格式的校验和加解密等功能，使用Redis非关系型数据库存储数据，同时对外提供Restful接口，供设备监控微服务组等其他微服务使用。

b)文件通信微服务完成卫星地面站内外部的文件交互服务，能够实时扫描不同格式的文件，接收外部系统发送的接收计划、卫星根数文件、测试计划等任务文件，经严格格式校验后，转化为软件内部识别的元数据。同时能够为任务调度微服务组提供文件生成、文件处理和文件发送的接口服务。

c)任务调度微服务包括任务冲突检测服务、任务处理服务、任务执行调度服务。任务冲突检测服务主要对卫星数据的任务计划和测试计划，在判断时间、设备等资源是否存在冲突后，对其进行分解，并入库。任务执行调度服务组织各类任务的实施，能够自动调用轨道服务组的引导文件计算服务，调用设备监控服务组的宏管理服务，文件通信服务组的文件发送服务，同时实时监视任务的状态，记录任务的状态信息。

d)设备监控微服务是地面站监控软件的核心服务。由状态采集服务、设备控制服务、设备状态发布服务、设备宏参数管理服务组成。状态采集服务能够基于设备参数模型，借助实时通信微服务组提供的各类通信服务，完成对天线设备、信道变频器设备、开关设备、基带设备的实时状态采集，工程值的量化转换，阈值的判断，设备状态故障的识别等。同样，设备控制服务能够调用实时通信服务，完成对设备的参数控制。宏参数管理服务能够为用户提供一组设备工作参数的管理，及参数的下发控制。设备状态发布服务能够通过Restful 接口，对外提供设备状态查询和控制的API，方便进行界面展示和扩展。

e)轨道微服务能够完成地面站轨道根数的接收和管理服务、卫星轨道的预报外推服务、卫星的进出站时间计算服务、卫星过境期间的天线引导文件计算服务、卫星星下点计算服务。

f)故障处理微服务为地面站监控软件提供全方位的故障识别、报警和处理。能够支持数字量报警、模拟量报警、多数字量报警、时间戳报警和高级报警。故障处理能够对报警分类，把有相似特征的报警标签放到一个报警分类中，能够给这些标签设定相同的显示特征，以及根据不同的报警类型配置相应的报警处理方式，如：界面报警、声光报警、短信报警和语音报警。

g)页面展示微服务为地面站监控软件提供页面展示功能。为地面站值班用户提供地面站设备状态实时监视，卫星接收任务执行状况，以及系统各参数配置界面。

h)应用微服务作为地面站监控软件中的核心服务，能够建立统一的信息标准化处理方式，统一管理其他各个微服务组，以满足上下级之间、同级之间数据信息流转的需求。具备系统软硬件的集中监视与系统配置中心管理能力，完成系统应用软件、设备固件的版本集中管理与快速部署，以及部署环境虚拟机的集中管理以及微服务消息队列的管理。

图4为本申请实施例提供的接口网关工作流程示意图，如图4所示，本申请实施例的API接口网关负责服务请求路由、组合及协议转换。客户端的所有请求都首先经过API网关，然后由它将请求路由到合适的微服务。在本文中，API接口网关主要有两个功能：1)用户的身份认证和鉴别；2)转发客户端HTTP请求到对应的微服务中进行处理。网关的处理流程如图所下示。

API接口网关负在收到HTTP请求时，首先会判断该请求是否为登录用户的验证请求，如果是，则直接解析请求URL，并转发请求到服务层验证；如果验证通过，则生成token令牌，并保存到系统缓存中，然后将token添加到响应头部返回；如果验证未通过，则直接返回禁止访问错误。

如果API网关判断该请求不是登录用户验证请求，则对请求头部携带的 token进行验证。如果验证不通过，则直接返回未经授权的错误；如果验证通过，则解析请求的URL地址。API网关在服务注册中心中查找相应服务的IP地址和端口号。如果找到相应的服务信息，则使用查找到的IP地址和端口号以及服务层URL将请求转发到服务层对应服务中进行处理；否则，直接返回文件找不到错误。

本申请实施例将微服务的架构方式应用到卫星地面站监控管理软件架构，将传统的抽象、封装为微服务；将功能类似相关的微服务，封装为微服务组，设计了通用微服务组，轨道微服务组，设备监控微服务组，任务管理微服务组等4个微服务组，覆盖了实时通信，文件通信、任务调度、设备监控、轨道计算管理，故障处理、页面展示、应用服务等功能；本申请实施例中的API接口网关负责服务请求路由、组合及协议转换；每个服务之间可以配置拥有不同的开发环境，开发速度快，部署简单，能够加快产品上线的速度，具有较好的扩展性。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本发明的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本发明的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本发明实施例的实施过程构成任何限定。上述本发明实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本实施例方案的目的。

另外，在本发明各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

以上所述，仅为本发明的实施方式，但本发明的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本发明揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本发明的保护范围之内。因此，本发明的保护范围应以所述权利要求的保护范围为准。

Claims (4)

1.一种基于微服务的卫星地面站监控管理架构，其特征在于，微服务采用面向对象中间件ICE作为服务中间件，实现跨平台的接口访问服务和高效数据传输；所述架构包括：

应用层，用于提供各类应用，完成地面任务的创建和管理、设备的监控和实时报警，查看任务执行状态，完成系统配置管理、数据查询维护，统计地面站运行情况；

网关层，用于为外部提供统一访问服务端的负载均衡协调及数据转发功能；

服务层，由完成系统业务所需的各类基础服务应用接口API组件封装，用于为应用服务提供服务组件支撑，服务层对各个业务功能进行化管理；

资源层是系统的基础支撑层，用于提供系统运行所需的全部操作系统资源和环境；

其中，所述应用层提供的各类应用中包括：任务管理、设备监控、轨道应用、故障诊断、值班统计；所述服务层包括：服务通信微服务、任务管理微服务、设备监控微服务、轨道微服务、通用微服务、服务管理中心；所述服务通信微服务支持以下的通信方式：文件传输协议FTP、消息队列MQ、远程过程调用RPC、表述性状态传递REST；所述任务管理微服务包括：计划创建、任务管理、调度管理；所述设备监控微服务包括设备控制、状态监视、宏管理；所述轨道微服务包括进出站计算、点位计算、轨道管理；所述通用微服务包括报警管理、用户管理、日志管理；所述服务管理中心包括配置管理、监控管理、日志管理、注册发现；所述资源层包括任务数据库、监控数据库、轨道数据库和基本数据库。

2.根据权利要求1所述的架构，其特征在于，所述服务管理中心对每个应用软件服务进行集中式管理，提供新服务的注册发现、服务发布、服务配置管理以及服务动态管理功能；

所述任务管理微服务将任务创建、任务管理、任务调度管理封装为微服务；

所述轨道微服务用于提供卫星轨道的管理，提供卫星进出站计算服务以及跟踪点位计算服务；

所述通用微服务用于提供应用运行的通用功能服务，包括用户管理服务、日志管理服务、故障报警服务；

所述设备监控微服务用于提供设备的参数状态监视、命令控制以及宏参数管理组下发功能；

所述服务通信微服务提供应用内部各个微服务的通信服务。

3.根据权利要求1所述的架构，其特征在于，微服务之间的业务数据交互基于专用数据总线进行；业务数据交互包含通信与传输、消息分发与订阅、外部通信接口的功能；

微服务容器启动后，服务注册器通过控制台或者界面向服务管理器发送注册消息，完成对外提供的业务服务的微服务注册，同时服务发现器从服务注册中心中获取该微服务调用的服务列表，并缓存到微服务运行时容器的服务提供者列表中。

4.根据权利要求3所述的架构，其特征在于，所述架构还包括微服务调用接口，以实现跨平台的接口访问服务和数据传输，通过客户端访问发布与服务架构节点上的服务进行调用，以进行服务动态构建，基于微服务调用接口的定义文件和接口描述文件，进行服务的开发和部署；

所述服务管理中心采用面向服务的方式，为微服务调用接口提供服务实现：通过对现有服务进行组合，基于第三方服务的封装操作并借助流程定义文件，进行服务之间的流程跳转。

Images