一种分布式数据管理中心软件架构设计

2022-07-18孟景涛王涛蒋浩孙婧徐朽辉

计算机与网络 2022年10期

孟景涛王涛蒋浩孙婧徐朽辉

摘要：随着国产化新研航天地面测控数传装备需求的爆发式增长，带来了更复杂多样的数据，传统单体数据库在此类数据面前明显吃力。为满足各型装备用户对高效、综合运维管理的客观需求，提出了一种基于国产化面向服务软件架构的多维数据管理平台，对吞吐数据进行统一管理，来完成测控数传设备的数据积累，形成良性循环，逐步提高测控数传设备可用度与可靠性。后续其他类似的项目数据中心部分建设，只需要对数据中心进行参数配置，即可实现数据管理功能。同时为项目的微服务化提供技术栈架构支撑。

关键词：分布式；数据管理；Linux；Zookeeper；

中图分类号：TP319文献标志码：A文章编号：1008-1739（2022）10-49-5

分布式数据管理中心软件[1]是航天地面测控数传装备的组成部分，作为整个系统的数据管理中心，担负着整个系统设备的数据存储和管理等功能[2]。现有系统中数据存储的形式主要有XML数据文件[3]、自定义格式数据文件和SQL Lite等，在数据安全性、扩展性和维护性上与现有应用场景和技术已不再匹配，并且现有系统架构不支持高并发和大批量的数据存储和数据检索，所以提出将系统中的业务数据、基础配置及其日志信息数据剥离出来，以数据库为支撑，建立数据中心，实现对数据存储和访问的集中化管理[4]。

对测控软件从整体架构上进行了全新的设计，实现对数据存储以数据库为基础，通过模块化将系统中的业务数据、配置数据和日志信息数据由之前的分散性和数据格式的多样性进行了数据存储的统一化、访问的规范化和数据的独立性。以此建立数据中心，实现数据和业务的隔离，在数据的管理和操作上方便、快捷、高效；在数据维护上简单、安全[5]；实现数据的集中控制、数据一致性和可维护性、数据共享、减少数据的冗余度、数据安全和数据的备份[6]。建立数据中心后，系统模块划分更加合理，降低了系统的耦合性，增强了系统访问的高效性、可维护性和可扩展性。

目标的项目架构在具有关系数据接口插件和ES（elasticsearch）数据接口插件上使用了Zookeeper，Kafka，Mycat等开源服务，通过对MySQL数据库、神通数据库、redis数据库和ES数据存储的使用，实现在不同场景下对于数据存储和检索的支持，项目架构如图1所示。

项目架构对于系统性能、可用性和数据安全性均有优化作用，能够支持当前的业务需求，对系统的易维护性也有很好的支持。经过实验验证，数据存储服务在国产环境中的效率评估也有不凡表现。

2.1服务之间接口访问设计

创建Dbserver插件处理关系数据[7]，订阅消息cti/dbserver/ request/*（cti/dbserver/receive/接口命令字/交易流水号），返回消息发送cti/dbserver/response/*（cti/dbserver/response/请求时命令字/请求时交易流水号）。

Dbserver插件通过thrift提供的RPC接口通信方式作为与数据库服务间调用方式，调用方和服务提供方通过Thrift方式生成统一的方法string invoke（1：string para），入参和返回值均為json传输，这样保持具体接口方法增加和修改的稳定性。

出入参统一格式：

入参：{“reqtype”：“请求接口名”，“param”： “{param1”：“param2value”，“param1”：“param2value”}}

出参：{“restype”：“返回数据类型”，“param”：{“param1”：“param2value”，“param1”：“param2value”}}

ES插件部分与服务通信采用同样方式处理。

2.2关系数据服务插件

关系数据服务插件与系统其他模块间通过异步消息方式交互[8]，上节描述了交互的方式及报文格式，插件在加载时向zk读取可用关系数据服务列表，根据配置文件配置，可以采用主备方式优先调用主数据服务，当主数据服务异常时切换到备用服务；或者采用无主混合模式随机选用可用服务进行接口调用，当某一台数据服务异常后插件主动剔除异常服务的链接。

关系数据服务插件架构如图2所示，插件采用zk提供的对于节点观察的方式，通过zk的机制来进行及时的关系数据服务的主动断开或者加入；关系数据插件与关系数据服务之间通过Thrift框架进行接口调用，连接的维持方法调用细节通过框架透明，只需要关注业务即可。

2.3关系数据服务

关系数据服务模块由接口层、逻辑层和数据库操作层组成[4]，向上通过Thrift的RPC通信框架承接测控逻辑层的业务接口需求向下与Mycat交互，Mycat经过数据库代理对数据库的分布式进行透明化处理，关系数据服务模块如图3所示。

业务数据服务负责业务相关的配置报表等持久化数据，在逻辑划分上分为接口层、逻辑层和数据库连接层。各个层直接通过虚基类的方式向上提供功能，接口层承接上层对于功能的需求向外释放功能接口，逻辑层根据业务需要和数据库的设计进行数据加工，数据库操作层负责数据库的基础操作功能和数据库连接池的保持。

在数据库连接层可根据配置方式选择采用“读写都是MySQL”“写MySQL+神通读MySQL”“读写都是神通”的模式控制。

在数据连接层可根据配置文件配置主备2个Mycat组，连接层自检测链接的可用性，当主Mycat可用性异常时自动切换到备用Mycat连接，上层业务层无感知。

2.4 ES日志数据插件

ES日志数据服务插件与系统其他模块间通过异步消息方式交互，上文描述了交互的方式及报文格式，插件在加载时向zk读取可用ES日志数据服务列表，根据配置文件配置可以采用主备方式优先调用主ES服务，当主ES服务异常时切换到备用服务；或者采用无主混合模式随机选用可用服务进行接口调用，当某一台ES服务异常后插件主动剔除异常服务的链接，日志数据插件架构如图4所示。

ES日志数据服务插件采用zk提供的对于节点观察的方式，通过zk的机制来进行及时的ES数据服务的主动断开或者加入。ES数据插件与ES数据服务之间通过Thrift框架进行接口调用，连接的维持方法调用细节通过框架透明，只需要关注业务即可。

2.5日志模块服务

由于项目中日志的数据输出量比较大，所以不能不考虑对整个系统性能的影响。从另外一方面来看，大量的日志数据需要方便检索，增强日志的可阅读性和检索效率。模块基于使用方便，包括开发和信息检索；组织合理，日志内容被有效地组织起来。有助于基于日志内容的分析；过程重现，基于日志的分析，最重要的是重现当时运行的过程，日志模块服务架构如图5所示。

模块向上通过Thrift的RPC通信框架承接测控逻辑层的日志持久化需求，向下与消息中间件做对接将需要持久化的数据写入文件数据库ES。

项目对于消息中间件的引入在保证日志的完整性的同时，采用异步写入的方式降低了日志写入对业务系统性能的影响；另外，此部分增加日志异步写入服务，读取消息队列中的日志数据进行必要的数据加工，可以根据需要增加逻辑处理对日志进行格式化匹配业务日志场景，然后再写入ES进行持久化存储。功能划分上，日志模块只负责接收上层日志写入消息中间件，日志加工写入模块对日志数据进行格式化，或者根据业务场景进行日志数据的加工写入ES。

通过对项目目标的分析，结合以往成熟的项目经验，针对当前流行的相关技术和框架进行分析，系统采用如下技术栈进行架构实现：通过MySQL进行业务数据的存储；Mycat进行数据库和项目的隔离到达数据库的分布式部署和容灾自动切换；Redis作为缓存数据的存储提高系统的响应效率；ES作为日志存储，达到大数据的检索；Kafka作为消息中间件支持大并发数据的通信，通过异步方式降低系统调用延迟，对于后端数据持久化提供多服务支持；ZooKeeper[9]来实现微服务治理，保障系统的稳定性[10]，为系统的低耦合高内聚做稳定性支持[11]；Thrift+Json来完成服务间调用，并方便地达到对于语言的透明，在业务设计上采用业务提取属性的方式到达对业务配置化的支持。

运行环境采用银河麒麟Kylin V10 Liunx操作系统、 Phytium FT-2000/4（64位，4核）处理器、8 GB内存和银河麒麟飞腾PC机，开发环境为Qt集成开发环境[12]。针对目标架构中MySQL和ES在国产化机器设备中的存取效率测试评估如下：MySQL基础数据为102万条现有数据的基础上插入10万条数据做平均插入耗时计算；在银河麒麟飞腾PC机中，带有2个索引字段的MySQL表中以102万数据为原始数据，再增加10万条数据为计算依据，每秒可插入1 886条记录；数据查询单条查询耗时均在1 ms以下；以一亿数据为基准根据时间范围条件查询，每条查询用时4 ms，效率评估结果如图6所示。