CN115757552A - 基于分布式微服务的银行历史数据管理系统 - Google Patents

Abstract

本发明提供了基于分布式微服务的银行历史数据管理系统，系统包括：数据源层用于实时提供银行系统的业务源数据；历史数据查询子系统用于对数据源层的业务源数据进行批次加工处理，并利用巨杉数据库的多副本机制进行存储管理，以及通过统一服务接口为数据应用层提供联机交易查询服务；数据应用层用于通过zookeeper注册中心管控历史数据查询子系统的统一服务接口的注册发布和各个消费方应用的服务订阅，并响应于各个消费方应用的联机交易查询请求，以及通过统一服务接口获取业务数据并发送至各个消费方应用；本发明实现集中管理银行历史数据，减少各应用的线上业务处理压力和系统间交互，增强交易可靠性，有效提升数据服务性能。

Description

基于分布式微服务的银行历史数据管理系统

技术领域

本发明涉及计算机技术领域，特别是涉及一种基于分布式微服务的银行历史数据管理系统。

背景技术

银行各个业务应用系统长期独自保留历史数据以满足相关业务处理、以及客户对各自历史数据查询的诉求，导致各个应用服务分散，不能形成统一的历史数据存储和服务，且各个业务应用系统长期运营后会产生大量业务数据，在一定程度上增加了业务应用系统的数据服务压力。亟需统筹规划历史数据服务体系建设，降低业务系统在线阶段的数据规模，提升业务系统联机查询服务的稳定性。

现有通过直接开放数据库表的JDBC连接访问，通过数据源接入程序，面向运维人员及业务人员提供自由查询、定制菜单查询功能，从而满足运维场景的需要，开展相应历史数据的采集、整合和存储的技术方案在一定程度上实现统筹历史数据服务的效果，但仍存在如下技术缺陷：1)大量的业务应用数据分散储存，没有统一管控历史数据以及数据链路的血缘关系；2)受限于各业务系统架构设计，对外提供查询方式包括命令行查询、菜单查询、jdbc直连查询等，缺乏统一的查询方式；3)面向对象仅包括运维人员或业务人员，无法实现业务系统间的历史数据交互；4)主要满足运维查询、数据提取等运维用途的数据诉求，缺少系统间近线数据联机查询服务；5)开放数据库表的JDB C连接访问，需开放数据库连接访问权限，系统稳定性较差。

发明内容

本发明的目的是提供一种基于分布式微服务的银行历史数据管理系统，通过定期批处理服务将各个业务应用系统的业务数据集中下发到历史数据查询子系统，由其采用SequoiaDB多副本机制进行数据读写分离、计算与存储分离，且为消费方应用交易查询的业务需求提供统一的高可用和低延时的联机交易服务接口，有效集中管理银行历史数据，减轻各个消费方应用线上业务处理压力，减少各个消费方应用系统间的交互，缩短交易链路，增强交易链路的可控性，提升数据服务性能和减轻系统运维压力，为业务扩展提供稳定性保障。

为了实现上述目的，有必要针对上述技术问题，提供了一种基于分布式微服务的银行历史数据管理系统。

第一方面，本发明实施例提供了一种基于分布式微服务的银行历史数据管理系统，所述系统包括数据源层、历史数据查询子系统和数据应用层；

所述数据源层，用于实时提供银行系统的业务源数据；

所述历史数据查询子系统，用于对所述数据源层的业务源数据进行批次加工处理，并利用巨杉数据库的多副本机制进行存储管理，以及通过统一服务接口为所述数据应用层提供联机交易查询服务；

所述数据应用层，用于通过zookeeper注册中心管控所述历史数据查询子系统的统一服务接口的注册发布和各个消费方应用的服务订阅，并响应于各个消费方应用的联机交易查询请求，以及通过统一服务接口从所述历史数据查询子系统获取所需业务数据并发送至各个消费方应用。

进一步地，所述消费方应用通过所述zookeeper注册中心与所述历史数据查询子系统建立socket长连接。

进一步地，所述历史数据查询子系统包括数据处理模块、数据存储模块、数据服务模块；

所述数据处理模块，用于采用定时日终批的方式从所述数据源层同步获取业务源数据，并对所述业务源数据进行多线程批次处理；所述多线程批次处理包括元数据检验、数据转码、数据加工、数据入库和数据清理；所述业务源数据包括数据文件和元数据文件；所述数据加工包括数据汇总统计和数据打平；

所述数据存储模块，用于将近线数据区划分为分布在不同物理机上的临时数据域、加工结果数据域和联机查询数据域，并通过巨杉数据库的多副本机制进行数据存储管理；

所述数据服务模块，用于响应于所述数据应用层的统一服务接口的调用请求，获取对应接口参数信息，并根据所述接口参数信息获取业务数据对象，以及将所述业务数据对象统一组装并返回至对应的各个消费方应用。

进一步地，所述临时数据域为数据核检、数据转码、数据入库和数据清理提供相应的近线数据存储；

所述加工结果数据域为数据加工提供相应的近线数据存储；

所述联机查询数据域为数据服务模块的联机交易查询提供相应的近线数据存储。

进一步地，所述数据处理模块包括数据核验模块、数据同步管理模块、数据同步模块、SDB处理模块、数据导入导出模块；

所述数据核验模块，用于核验所述数据文件和元数据文件是否具备相应的获取条件，并在所述数据文件具备获取条件时，通过所述数据同步管理模块执行所述数据文件的数据同步，以及在所述元数据文件具备获取条件时，通过远程机器对所述元数据文件进行拷贝；

所述数据同步管理模块，用于根据配置文件和配置表管理数据同步任务，并监听所述数据同步模块执行各个数据同步任务的服务状态，以及对完成入库的数据同步任务对应的数据文件进行预设期限保存和超期后清理；

所述数据同步模块，用于定时从所述源数据层获取元数据结构，并根据所述元数据结构更新所述历史数据查询子系统本地的数据结构，以及拷贝对应的数据文件以完成数据入库；

所述SDB处理模块，用于根据所述数据同步管理模块全量下发的数据文件的表项，新建对应的SDB表和索引，并更新挂载对应的SDB表；

数据加工处理模块，用于通过spark框架对多表关联业务数据进行批量统计和数据打平处理；

所述数据导入导出模块，用于对数据文件和元数据文件进行转码处理，并将转码后的数据文件和元数据文件采用sdbimprt工具导入至SDB数据库或更新至对应的SDB表，以及对SDB数据库中的现有数据采用sdbexprt工具进行导出。

进一步地，所述数据服务模块包括应用接口服务模块、业务融合服务模块、独立业务服务模块、数据接口服务模块、公共服务模块；

所述应用接口服务模块，用于对接口参数信息进行校验，并根据接口参数信息识别接口调用场景，以及根据所述接口调用场景分发至业务融合服务模块或独立业务服务模块获取对应的业务数据对象，并将所述业务数据对象组装成响应报文返回至对应的各个消费方应用；所述接口调用场景包括单业务调用场景和复业务调用场景；

所述业务融合服务模块，用于根据所述复业务调用场景，识别对应的各个业务调用场景，并根据各个业务调用场景，通过所述独立业务服务模块获取对应的数据对象，以及对得到的数据对象统一组装成业务数据对象并发送至所述应用接口服务模块；

所述独立业务服务模块，用于根据所述单业务调用场景，通过所述公共服务模块向所述数据接口服务模块发送数据获取请求，并接收所述数据接口服务模块反馈的数据对象；

所述公共服务模块，用于根据所述数据获取请求，获取对应的SDB连接实例，并根据所述SDB连接实例向所述数据接口服务模块发送业务SQL查询请求，获取数据对象并反馈至所述独立业务服务模块；还用于提供所述数据服务模块内其他模块的基础功能服务；所述基础功能服务包括数据对象转换服务、监控报送接口服务和通用处理工具类服务；

所述数据接口服务模块，用于响应于所述业务SQL查询请求，并基于SDB基础工具类服务和MYSQL基础工具类服务返回数据对象至所述公共服务模块。

进一步地，所述业务融合服务模块，还用于将获取的各个单业务调用场景的数据对象通过所述数据处理模块进行日终批次数据入库处理，并将所述数据对象转换为sparksql口径数据，以及对所述spark sql口径数据进行计算汇总得到业务数据对象。

进一步地，所述数据服务模块还包括内管接口服务模块和基础服务模块；

所述内管接口服务模块，用于监控所述历史数据查询子系统的统一接口服务运行情况；所述统一接口服务运行情况包括交易查询服务调用统计、各个交易查询耗时统计以及交易查询服务性能；

所述基础服务模块，用于通过mybatis框架查询拦截器统一拦截数据接口服务模块的查询请求，以及通过spring框架统一拦截查询返回数据，并对拦截数据统一进行日志打印处理。

进一步地，所述历史数据查询子系统还包括管理平台；

所述管理平台，用于基于所述数据存储模块的SDB集群进行元数据管理、联机交易查询请求批次管理和系统运行监控管理；所述系统运行监控管理包括系统资源占用监控和联机交易查询负载均衡管理。

进一步地，所述数据源层包括银行核心数据源、卡核心数据源和外围系统数据源；所述历史数据查询子系统预先为各个数据源设置三个副本，并配置各个业务调用场景与各个数据源副本的数据源映射关系表，以及根据联机交易查询请求的对应业务调用场景查询所述数据源映射关系表，获取对应副本的连接数据源，并根据连接数据源的标识，通过数据库查询工具类获取联机查询数据域内对应的副本连接。

上述本申请提供了一种基于分布式微服务的银行历史数据管理系统，所述系统包括在内部局域网内通过socket长连接进行交互的数据源层、历史数据查询子系统和数据应用层，实现了由数据源层实时提供银行系统的业务源数据，由历史数据查询子系统对数据源层的业务源数据进行批次加工处理，并利用巨杉数据库的多副本机制进行存储管理，以及通过统一服务接口为数据应用层提供联机交易查询服务，且由数据应用层通过zookeeper注册中心管控历史数据查询子系统的统一服务接口的注册发布和各个消费方应用的服务订阅，并响应于各个消费方应用的联机交易查询请求，以及通过统一服务接口从历史数据查询子系统获取所需业务数据并发送至各个消费方应用的技术方案。与现有技术相比，该基于分布式微服务的银行历史数据管理系统，能定期批处理服务将各个业务应用系统的业务数据集中下发到历史数据查询子系统，由其采用SequoiaDB多副本机制进行数据读写分离、计算与存储分离，且为消费方应用交易查询的业务需求提供统一的高可用和低延时的联机交易服务接口，有效集中管理银行历史数据，减轻各个消费方应用线上业务处理压力，减少各个消费方应用系统间的交互，缩短交易链路，增强交易链路的可控性，提升数据服务性能和减轻系统运维压力，为银行业务扩展提供稳定性保障。

附图说明

图1是本发明实施例中基于分布式微服务的银行历史数据管理系统的结构示意图；

图2是本发明实施例中基于分布式微服务的银行历史数据管理系统的交互流程示意图；

图3是图1中历史数据查询子系统2的结构示意图；

图4是图3中数据存储模块22的近线数据区管理使用示意图；

图5是图3中数据存储模块21的数据批次处理流程示意图；

图6是图3中数据服务模块23的对外提供交易查询服务的流程示意图；

图7是图1中历史数据查询子系统2的另一结构示意图；

图8是本发明实施例中基于分布式微服务的银行历史数据管理系统的详细架构示意图。

具体实施方式

为了使本申请的目的、技术方案和有益效果更加清楚明白，下面结合附图及实施例，对本发明作进一步详细说明，显然，以下所描述的实施例是本发明实施例的一部分，仅用于说明本发明，但不用来限制本发明的范围。基于本发明中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明基于现有银行历史数据存储管理的技术缺陷，采用数据分层处理思想，集中管理银行历史数据，并引入SequoiaDB(巨杉数据库)的多副本机制实现对银行业务数据的读写分离、计算与存储分离，设计得到基于分布式微服务的银行历史数据管理系统。下述实施例将对本发明的基于分布式微服务的银行历史数据管理系统进行详细描述。

在一个实施例中，如图1所示，提供了一种基于分布式微服务的银行历史数据管理系统，所述系统包括数据源层1、历史数据查询子系统2和数据应用层3；

所述数据源层1，用于实时提供银行系统的业务源数据，可根据实际应用需求从银行核心、信用卡核心、企业网银、财务系统、支付系统和信贷系统等数据源中进行选取组合得到；

所述历史数据查询子系统2，用于对所述数据源层的业务源数据进行批次加工处理，并利用巨杉数据库的多副本机制进行存储管理，以及通过统一服务接口为所述数据应用层提供联机交易查询服务；

所述数据应用层3，用于通过zookeeper注册中心管控所述历史数据查询子系统的统一服务接口的注册发布和各个消费方应用的服务订阅，并响应于各个消费方应用的联机交易查询请求，以及通过统一服务接口从所述历史数据查询子系统获取所需业务数据并发送至各个消费方应用。

在本实施例中，如图2所示，历史数据查询子系统2按照配置中心动态配置的配置文件和数据表项等同步存储数据源层的业务源数据；数据应用层3管理多个消费方应用，以zookeeper为注册中心管控历史数据查询子系统2的统一服务接口注册发布、各个消费方应用的服务接口订阅，以及节点服务集群管理；历史数据查询子系统2的联机交易查询服务通过spring boot方式启动加载连接配置中心和注册中心后，联机交易查询服务与注册中心通过长连接的方式持续维持一个心跳，并将fundService或funMethon注解的统一服务接口向注册中心注册发布，且与配置中心维持一个长连接，由配置中心根据自身配置项的变更动态更新相关配置信息至历史数据查询子系统2，联机交易查询服务通过连接数据库的方式及时保存服务运行时的各项参数；消费方应用服务向数据应用层3的注册中心订阅服务接口，消费方应用与注册中心保持长连接，当消费方应用触发交易行为时与历史数据查询子系统2以内部的RPC-dubbo方式进行局域网内通讯，消费方应用经过数据报文的编码和协议组装在与注册中心已建立的socket长连接基础上，由注册中心按照负载均衡策略分配交易查询请求转接到历史数据查询子系统2，由历史数据查询子系统经过数据解码和协议解析，并以内部虚拟机的内部对象服务接口方式交由其提供联机交易查询服务的一个节点处理并将处理结果原路返回给消费方应用。消费方应用由注册中心与历史数据查询子系统2以内部局域网socket技术建立长连接，减少各个消费方应用服务和历史数据查询子系统服务的连接耗时，减少系统与系统之间的数据传输耗时成本，减少服务交互时间，提高系统的访问效率。

在一个实施例中，如图3所示，历史数据查询子系统2，包括数据处理模块21、数据存储模块22、数据服务模块23；

所述数据处理模块21，用于采用定时日终批的方式从所述数据源层同步获取业务源数据，并对所述业务源数据进行多线程批次处理；所述多线程批次处理包括元数据检验、数据转码、数据加工、数据入库和数据清理；所述业务源数据包括数据文件和元数据文件；所述数据加工包括数据汇总统计和数据打平；其中，数据汇总统计可理解为针对数据应用层3的复杂业务交易查询场景(复业务调用场景)需要对涉及的单业务交易对应的业务数据进行批量统计汇总；

具体地，数据处理模块21采用定时日终批的方式启动服务根据从配置中心动态获取的应用配置表实现动态加载表数据文件解析并以多线程任务实现并行处理入库；数据批次处理以组件流水线方式实现入库流程；数据加工采用spark框架支持Spark SQL(特殊的查询语句)，实现服务业务数据及多表关联的计算汇总成复业务交易查询结果单表，用于为统一服务接口查询提供反馈，支持大数据量的数据处理，解决少量必要的数据加工问题，以有效提升联机交易查询效率。

所述数据存储模块22，用于将近线数据区划分为分布在不同物理机上的临时数据域、加工结果数据域和联机查询数据域，并通过巨杉数据库的多副本机制进行数据存储管理；其中，临时数据域为数据核检、数据转码、数据入库和数据清理提供相应的近线数据存储，供数据批次处理服务连接使用，日终批次服务启动时会连接该数据域；加工结果数据域为数据加工提供相应的近线数据存储，供数据加工服务连接使用，数据加工的数据源为从数据源层同步得到的离线日终入库数据；联机查询数据域为数据服务模块的联机交易查询提供相应的近线数据存储，为联机交易查询提供7*24全天候的实时服务；

SequoiaDB(巨杉数据库)API为历史数据查询子系统的联机交易查询(数据服务)和数据批处理加工提供仓储查询服务；巨杉数据库的结构分为协调节点、编目节点和数据节点，而数据域即为数据组，数据组是对数据节点的逻辑划分，其中，协调节点作为转发请求，编目节点存储数据节点进行数据汇总所用的元数据信息，实际数据存储在数据节点；通过连接协调节点将连接的数据组属性设为当前系统连接池连接，联机交易查询、批处理和数据加工均连接巨杉数据库的实例，批次处理服务启动或数据加工服务启动时会根据不同数据源设置的数据组控制协调节点转发到不同数据节点；数据域和数据节点是一对多的关系，一个数据节点只能归属一个数据域，一个数据域可以配置多个数据节点；

所述数据服务模块23，用于响应于所述数据应用层3的统一服务接口的调用请求，获取对应接口参数信息，并根据所述接口参数信息获取业务数据对象，以及将所述业务数据对象统一组装并返回至对应的各个消费方应用；

本实施例基于上述不同数据域的划分，各数据域分布在不同的物理机，实现CPU/磁盘/内存等物理资源隔离，保障对外服务与数据加工彼此隔离，互不影响，有效解决了不同服务处理业务时所需资源的争夺问题，结合巨杉数据库的存储管理，通过设置协调节点连接的不同数据域达到服务使用物理资源的隔离，从而保障了联机交易查询系统服务稳定输出。

在一个实施例中，所述数据处理模块21包括数据核验模块、数据同步管理模块、数据同步模块、SDB处理模块、数据加工处理模块和数据导入导出模块；

其中，所述数据核验模块，用于核验所述数据文件和元数据文件是否具备相应的获取条件，并在所述数据文件具备获取条件时，通过所述数据同步管理模块执行所述数据文件的数据同步，以及在所述元数据文件具备获取条件时，通过远程机器对所述元数据文件进行拷贝；

所述数据同步管理模块，用于根据配置文件和配置表管理数据同步任务，并监听所述数据同步模块执行各个数据同步任务的服务状态，以及对完成入库的数据同步任务对应的数据文件进行预设期限保存和超期后清理；

所述数据同步模块，用于定时从所述源数据层获取元数据结构，并根据所述元数据结构更新所述历史数据查询子系统本地的数据结构，以及拷贝对应的数据文件以完成数据入库；

所述SDB处理模块，用于根据所述数据同步管理模块全量下发的数据文件的表项，新建对应的SDB表和索引，并更新挂载对应的SDB表；

数据加工处理模块，用于通过spark框架对多表关联业务数据进行批量统计和数据打平处理；如图4所示，当涉及复业务查询场景时会触发数据加工处理任务，数据加工处理任务将读取临时域的表数据作为基础数据进行计算和汇总，并将结果数据打平或插入到临时域加工结果表中，且加工结果表以交易时间作为主表分区键交易流水号作为子表分区键打散在联机查询数据域中不同的数据节点中存储，当触发联机交易查询请求时直接查询加工结果表的数据；

所述数据导入导出模块216，用于对数据文件和元数据文件进行转码处理，并将转码后的数据文件和元数据文件采用sdbimprt工具导入至SDB数据库或更新至对应的SDB表，以及对SDB数据库中的现有数据采用sdbexprt工具进行导出。

具体地，数据处理模块21根据配置中心配置的配置文件和相关表项，维护同步配置表(存储每个数据同步任务的配置说明，每次数据同步都需要读取相关信息)、同步结果当前表(数据同步过程中，写入同步任务的状态和运行信息)、同步结果历史表(将数据同步状态为成功的当前表记录存储到同步结果历史表中，便于回溯)、同步资源配置表(存储部分数据同步批次处理需要使用到的配置信息)、Spark当前执行状态表(存储数据加工运行过程状态数据)、Spark执行状态历史表(存储数据加工流程结束状态数据)、元数据信息表(存储每张表的元数据结构，包括字段名和类型，在数据导入时需要指定相关信息)和元数据信息历史表(存储上游系统的元数据信息，用于更新SDB的元数据结构，确保元数据与上游系统一致)，按照图5所示的处理流程实现数据文件和元数据文件的同步存储，数据加工处理以及定时批次处理；

在一个实施例中，所述数据服务模块23包括应用接口服务模块、业务融合服务模块、独立业务服务模块、数据接口服务模块、公共服务模块；

其中，所述应用接口服务模块，用于对接口参数信息进行校验，并根据接口参数信息识别接口调用场景，以及根据所述接口调用场景分发至业务融合服务模块或独立业务服务模块获取对应的业务数据对象，并将所述业务数据对象组装成响应报文返回至对应的各个消费方应用；所述接口调用场景包括单业务调用场景和复业务调用场景；

所述业务融合服务模块，用于根据所述复业务调用场景，识别对应的各个业务调用场景，并根据各个业务调用场景，通过所述独立业务服务模块获取对应的数据对象，以及对得到的数据对象统一组装成业务数据对象并发送至所述应用接口服务模块；还用于将获取的各个单业务调用场景的数据对象通过所述数据处理模块进行日终批次数据入库处理，并将所述数据对象转换为spark sql口径数据，以及对所述spark sql口径数据进行计算汇总得到业务数据对象；

所述独立业务服务模块，用于根据所述单业务调用场景，通过所述公共服务模块向所述数据接口服务模块发送数据获取请求，并接收所述数据接口服务模块反馈的数据对象；

所述公共服务模块，用于根据所述数据获取请求，获取对应的SDB连接实例，并根据所述SDB连接实例向所述数据接口服务模块发送业务SQL查询请求，获取数据对象并反馈至所述独立业务服务模块；还用于提供所述数据服务模块内其他模块的基础功能服务；所述基础功能服务包括数据对象转换服务、监控报送接口服务和通用处理工具类服务；

所述数据接口服务模块，用于响应于所述业务SQL查询请求，并基于SDB基础工具类服务和MYSQL基础工具类服务返回数据对象至所述公共服务模块；

其中，巨杉数据库的MYSQL引擎实例需要建立关系型表结构映射原生巨杉数据库的集合空间和集合名称，数据真正存储在原生巨杉数据库底层，MYSQL引擎只做开发简洁映射处理，历史数据查询子系统以消费方应用为单位建立原生巨杉数据库的集合空间，实际应用的表作为巨杉数据库的集合名称，历史数据查询子系统按照消费方应用的级别划分巨杉数据库MYSQL连接实例，联机交易查询服务和批处理加工服务通过不同用户和不同的实例连接，控制用户访问表的权限，在实际巨杉数据库MYSQL应用中的sql语句必需带上实例名称+表名；巨杉数据库的MYSQL引擎实例可以支持多表关联的sql查询语句，即可实现多表关联查询。

具体地，历史数据查询子系统根据各个业务需求场景设计对应的一个全行唯一的服务码，并按照业务需求场景定义接口的请求报文字段、请求数据格式(XML/JSON)、请求协议(HTTP、HTTPS、socket)和响应报文字段；历史数据查询子系统的联机交易查询服务启动时加载连接全行的一级注册中心并通过注解@RpcService将服务码往注册中心发布，消费方应用向历史数据查询子系统申请服务码调用并且在消费者应用服务启动时连接全行的一级注册中心订阅已经过历史数据查询子系统审批通过的服务码，若消费方应用的服务码审批不通过，则在服务启动时就会报消费的服务码无权限错误，若审批通过，则可基于数据服务模块23上述各个功能模块按照图6所示的下述流程实现实时交易查询处理：

1)消费方应用发送交易查询请求至服务化网关，由服务化网关经过统一服务接口RPC调用转接请求至历史数据查询子系统的应用接口服务模块；

2)应用接口服务模块调用公共处理模块的统一参数校验服务，接口参数校验失败则原路返回应用接口服务模块，由接口服务模块统一组装异常响应参数原路返回至消费方应用；参数校验成功则判断是否是复业务调用接口，若是，则请求融合业务服务模块完成服务组装，否则请求独立业务服务模块；其中，接口参数包括请求报文字段、请求数据格式(XML/JSON)、请求协议(HTTP、HTTPS、socket)和响应报文字段等；

3)独立业务服务模块将交易查询请求转发至公共服务模块获取SDB连接实例；

4)公共处理模块根据获取到SDB连接实例查询访问数据接口服务模块获取数据对象；

5)数据接口服务模块返回查询响应数据至独立业务服务模块，由其统一组装业务数据对象返回至应用接口服务模块或融合业务服务模块；

6)融合业务服务处理层统一组合单一业务服务对应的数据对象并返回应用接口服务模块；

7)基础服务模块统一拦截数据接口服务模块的查询求并将请求报文和数据返回报文进行统一日志打印处理；

8)应用接口服务模块组装统一的响应报文原路返回至各个消费方应用。

本实施例通过服务化接口实现面向银行各个消费方应用的应用系统间的单一业务和复合业务的历史数据明细查询服务，通过巨杉数据库MYSQL(数据库)引擎实例的权限管理，实现业务数据的访问安全。

在一个实施例中，所述数据服务模块23还包括内管接口服务模块和基础服务模块；

所述内管接口服务模块，用于监控所述历史数据查询子系统的统一接口服务运行情况；所述统一接口服务运行情况包括交易查询服务调用统计、各个交易查询耗时统计以及交易查询服务性能；

所述基础服务模块，用于通过mybatis框架查询拦截器统一拦截数据接口服务模块的查询请求，以及通过spring框架统一拦截查询返回数据，并对拦截数据统一进行日志打印处理。

本实施例通过对历史数据查询子系统的查询交易请求的相关处理进行日志记录便于系统运维，通过监控历史数据查询子系统的统一即可服务运行情况，为注册中心分配交易查询请求的负载均衡策略制定提供有效依据，进而为历史数据查询子系统的稳定运行提供可靠保证。

在一个实施例中，如图7所示，所述历史数据查询子系统2还包括管理平台24；

所述管理平台24，用于基于所述数据存储模块22的SDB集群进行元数据管理、联机交易查询请求批次管理和系统运行监控管理；所述系统运行监控管理包括系统资源占用监控和联机交易查询负载均衡管理；

如图8所示，管理平台24的功能实现依托于与数据存储模块22的交互；其中，元数据管理可理解为实现对数据存储模块22设计的表结构以及表之间的关联关系进行维护，实现表数据生命周期管理维护，以及实现元数据变更的统一维护；联机交易查询请求批次管理可理解实现消费方应用相关表接入的批次处理的配置管理，实现批次运行的结果统计以及异常记录；系统运行监控管理可理解为根据相关配置参数开启监控服务参数收集，实现对系统内部署的各个服务器的CPU、内存以及磁盘的使用率的统一采集，当前服务器的CPU和内存使用率超过对应的预设阈值后触发告警，如联机交易查询执行和数据批注加工时会定时采集当前系统资源的代理服务以5秒的频率实时采集当前服务器的磁盘、内存和CPU使用的数据放到redis缓存中，内管系统的后台服务每隔3秒的频率查询redis缓存的资源使用，并且根据资源使用阀值模型(系统的磁盘空间使用率是否超过80％、CPU、内存使用率是否超过80％，且维持10分钟不降)判断是否触发邮件告警通知。日终批次数据加工时，若出现处理失败时会实时将结果写入redis缓存中，内管系统后台服务以10秒的频率查询一次redis缓存的批次异常信息，若异常信息存在则触发告警通知。

此外，该管理平台还包括如下所示的质量管理及安全管理：

质量管理：维护版本概要设计、总体方案设计和详细设计的评审管理，针对开发人员设计的方案的合理性和可实施性进行管控；维护版本代码的评审管理，针对开发人员开发的功能模块代码按照：代码规范、代码实现的逻辑处理风险识别、打印的日志信息是否进行脱敏处理、高并发场景是否会出现OOM和查询数据量的控制等规约进行评判；维护投产版本总结管理，针对版本投产过程所出现的问题总结登记维护，形成投产维护的经验资产积累；

安全管理：维护投产流程的规范性操作管理，研发过程的文档常规检查管理；维护表数据量存储的评估风险。

具体地，管理平台24采用前后分离的方式实现，前端采用vue框架，通过Nginx作为前端部署的web服务器，内管后台接口采用自研框架通过内管接口服务模块实现服务接口对消费方应用的暴露，前端web通过http方式与内管后台接口进行数据交互。管理平台24与数据存储模块22的交互关系，其监控管理结果可通过数据服务模块21的内管接口服务模块提供给数据应用层的注册中心使用，不仅用于更好地实现消费方应用交易查询服务的负载均衡以及对历史数据查询子系统运行的监管和维护，而且通过元数据管理实现对历史数据链路的血缘关系的统一维护；

在一个实施例中，数据源层包括银行核心数据源、卡核心数据源和外围系统数据源；所述历史数据查询子系统预先为各个数据源设置三个副本(全库数据域皆采用3副本)，并配置各个业务调用场景与各个数据源副本的数据源映射关系表，即将联机查询数据域采用SequoiaDB(巨杉数据库)的多副本访问隔离机制，实现不同查询场景访问不同的副本；在实际的联机交易查询请求处理中，根据联机交易查询请求的对应业务调用场景查询所述数据源映射关系表，获取对应副本的连接数据源，并根据连接数据源的标识，通过数据库查询工具类获取联机查询数据域内对应的副本连接；根据消费方应用的重要程度以及服务保障级别不一样，根据一份数据是否有多个消费方应用使用，以及使用数据的消费方应用重要程度的服务保障级别，设置不同的副本，进而达到稳定可控地为某些重点消费应用提供服务，为业务服务扩展提供了可靠保障。

本申请实施例基于RTP平台框架实现历史数据统一集中管控，利用大数据分布式存储技术，实现近线数据的读写分离，计算分离，保障系统运行高可靠、历史数据查询高效率，为各应用提供统一的历史数据服务，以及通过对复杂业务数据(一次业务查询中需要关联多个大表才能查出数据，数据特点是离线的数据，而多个大表通过sql关联查询时会出现耗时过久的问题)采用日终启动数据加工形成单一形式的结果数据存储，为联机交易查询提供直接查询加工后的单表，不仅系统层次分明，服务之间资源相互独立，交易链路可控，服务高可用低延迟，而且通过数据集中管控处理和交易查询功能下放，有效减轻消费方应用的线上业务处理压力，提升数据访问性能和数据赋能的服务，增强数据价值面向全行服务，还能通过集中式的系统监控减轻运维人员的压力，系统自动告警主动发现异常，为银行业务扩展提供稳定性保障。

上述一种基于分布式微服务的银行历史数据管理系统中的各个模块可全部或部分通过软件、硬件及其组合来实现。上述各模块可以硬件形式内嵌于或独立于计算机设备中的处理器中，也可以以软件形式存储于计算机设备中的存储器中，以便于处理器调用执行以上各个模块对应的操作。

本说明书中的各个实施例均采用递进的方式描述，各个实施例直接相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。尤其，对于系统实施例而言，由于其基本相似于方法实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。需要说明的是，上述实施例的各技术特征可以进行任意的组合，为使描述简洁，未对上述实施例中的各个技术特征所有可能的组合都进行描述，然而，只要这些技术特征的组合不存在矛盾，都应当认为是本说明书记载的范围。

以上所述实施例仅表达了本申请的几种优选实施方式，其描述较为具体和详细，但并不能因此而理解为对发明专利范围的限制。应当指出的是，对于本技术领域的普通技术人员来说，在不脱离本发明技术原理的前提下，还可以做出若干改进和替换，这些改进和替换也应视为本申请的保护范围。因此，本申请专利的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种基于分布式微服务的银行历史数据管理系统，其特征在于，所述系统包括数据源层、历史数据查询子系统和数据应用层；

所述数据源层，用于实时提供银行系统的业务源数据；

所述历史数据查询子系统，用于对所述数据源层的业务源数据进行批次加工处理，并利用巨杉数据库的多副本机制进行存储管理，以及通过统一服务接口为所述数据应用层提供联机交易查询服务；

所述数据应用层，用于通过zookeeper注册中心管控所述历史数据查询子系统的统一服务接口的注册发布和各个消费方应用的服务订阅，并响应于各个消费方应用的联机交易查询请求，以及通过统一服务接口从所述历史数据查询子系统获取所需业务数据并发送至各个消费方应用。

2.如权利要求1所述的银行历史数据管理系统，其特征在于，所述消费方应用通过所述zookeeper注册中心与所述历史数据查询子系统建立socket长连接。

3.如权利要求1所述的银行历史数据管理系统，其特征在于，所述历史数据查询子系统包括数据处理模块、数据存储模块、数据服务模块；

所述数据处理模块，用于采用定时日终批的方式从所述数据源层同步获取业务源数据，并对所述业务源数据进行多线程批次处理；所述多线程批次处理包括元数据检验、数据转码、数据加工、数据入库和数据清理；所述业务源数据包括数据文件和元数据文件；所述数据加工包括数据汇总统计和数据打平；

所述数据存储模块，用于将近线数据区划分为分布在不同物理机上的临时数据域、加工结果数据域和联机查询数据域，并通过巨杉数据库的多副本机制进行数据存储管理；

所述数据服务模块，用于响应于所述数据应用层的统一服务接口的调用请求，获取对应接口参数信息，并根据所述接口参数信息获取业务数据对象，以及将所述业务数据对象统一组装并返回至对应的各个消费方应用。

4.如权利要求3所述的银行历史数据管理系统，其特征在于，所述临时数据域为数据核检、数据转码、数据入库和数据清理提供相应的近线数据存储；

所述加工结果数据域为数据加工提供相应的近线数据存储；

所述联机查询数据域为数据服务模块的联机交易查询提供相应的近线数据存储。

5.如权利要求3所述的银行历史数据管理系统，其特征在于，所述数据处理模块包括数据核验模块、数据同步管理模块、数据同步模块、SDB处理模块、数据导入导出模块；

所述数据核验模块，用于核验所述数据文件和元数据文件是否具备相应的获取条件，并在所述数据文件具备获取条件时，通过所述数据同步管理模块执行所述数据文件的数据同步，以及在所述元数据文件具备获取条件时，通过远程机器对所述元数据文件进行拷贝；

所述数据同步管理模块，用于根据配置文件和配置表管理数据同步任务，并监听所述数据同步模块执行各个数据同步任务的服务状态，以及对完成入库的数据同步任务对应的数据文件进行预设期限保存和超期后清理；

所述数据同步模块，用于定时从所述源数据层获取元数据结构，并根据所述元数据结构更新所述历史数据查询子系统本地的数据结构，以及拷贝对应的数据文件以完成数据入库；

所述SDB处理模块，用于根据所述数据同步管理模块全量下发的数据文件的表项，新建对应的SDB表和索引，并更新挂载对应的SDB表；

数据加工处理模块，用于通过spark框架对多表关联业务数据进行批量统计和数据打平处理；

所述数据导入导出模块，用于对数据文件和元数据文件进行转码处理，并将转码后的数据文件和元数据文件采用sdbimprt工具导入至SDB数据库或更新至对应的SDB表，以及对SDB数据库中的现有数据采用sdbexprt工具进行导出。

6.如权利要求3所述的银行历史数据管理系统，其特征在于，所述数据服务模块包括应用接口服务模块、业务融合服务模块、独立业务服务模块、数据接口服务模块、公共服务模块；

所述应用接口服务模块，用于对接口参数信息进行校验，并根据接口参数信息识别接口调用场景，以及根据所述接口调用场景分发至业务融合服务模块或独立业务服务模块获取对应的业务数据对象，并将所述业务数据对象组装成响应报文返回至对应的各个消费方应用；所述接口调用场景包括单业务调用场景和复业务调用场景；

所述业务融合服务模块，用于根据所述复业务调用场景，识别对应的各个业务调用场景，并根据各个业务调用场景，通过所述独立业务服务模块获取对应的数据对象，以及对得到的数据对象统一组装成业务数据对象并发送至所述应用接口服务模块；

所述独立业务服务模块，用于根据所述单业务调用场景，通过所述公共服务模块向所述数据接口服务模块发送数据获取请求，并接收所述数据接口服务模块反馈的数据对象；

所述公共服务模块，用于根据所述数据获取请求，获取对应的SDB连接实例，并根据所述SDB连接实例向所述数据接口服务模块发送业务SQL查询请求，获取数据对象并反馈至所述独立业务服务模块；还用于提供所述数据服务模块内其他模块的基础功能服务；所述基础功能服务包括数据对象转换服务、监控报送接口服务和通用处理工具类服务；

所述数据接口服务模块，用于响应于所述业务SQL查询请求，并基于SDB基础工具类服务和MYSQL基础工具类服务返回数据对象至所述公共服务模块。

7.如权利要求6所述的银行历史数据管理系统，其特征在于，所述业务融合服务模块，还用于将获取的各个单业务调用场景的数据对象通过所述数据处理模块进行日终批次数据入库处理，并将所述数据对象转换为spark sql口径数据，以及对所述spark sql口径数据进行计算汇总得到业务数据对象。

8.如权利要求6所述的银行历史数据管理系统，其特征在于，所述数据服务模块还包括内管接口服务模块和基础服务模块；

所述内管接口服务模块，用于监控所述历史数据查询子系统的统一接口服务运行情况；所述统一接口服务运行情况包括交易查询服务调用统计、各个交易查询耗时统计以及交易查询服务性能；

所述基础服务模块，用于通过mybatis框架查询拦截器统一拦截数据接口服务模块的查询请求，以及通过spring框架统一拦截查询返回数据，并对拦截数据统一进行日志打印处理。

9.如权利要求6所述的银行历史数据管理系统，其特征在于，所述历史数据查询子系统还包括管理平台；

所述管理平台，用于基于所述数据存储模块的SDB集群进行元数据管理、联机交易查询请求批次管理和系统运行监控管理；所述系统运行监控管理包括系统资源占用监控和联机交易查询负载均衡管理。

10.如权利要求3所述的银行历史数据管理系统，其特征在于，所述数据源层包括银行核心数据源、卡核心数据源和外围系统数据源；所述历史数据查询子系统预先为各个数据源设置三个副本，并配置各个业务调用场景与各个数据源副本的数据源映射关系表，以及根据联机交易查询请求的对应业务调用场景查询所述数据源映射关系表，获取对应副本的连接数据源，并根据连接数据源的标识，通过数据库查询工具类获取联机查询数据域内对应的副本连接。

Images