一种基于微服务的监管报送系统

摘要

本发明公开的基于微服务的监管报送系统，涉及计算机技术领域，包括基础平台模块、数据集市模块、指标类数据报送模块、明细类数据报送模块及血脉分析模块，基础平台模块用于对系统中涉及的公共信息进行统一维护；数据集市模块用于将加工好的金融基础数据存放于监管产品规范建立的主题模型表中；指标类数据报送模块用于将当前监管部门所列出的基于指标报送的各个监管子系统做归并；明细类数据报送模块用于报送金融机构的实际数据；血脉分析模块用于对于指标类数据进行分析及追溯时做辅助分析，获取报表中的指标，判断该指标来自于哪个主题表的哪个字段，追溯所述字段的加工逻辑，直到追溯至源端系统的具体信息，提高了系统的可靠性及吞吐率。

说明书

技术领域

本发明涉及计算机技术领域，具体涉及一种基于微服务的监管报送系统。

背景技术

监管报送系统作为金融行业普通使用的业务系统，其定位一直属于金融行业的末端非盈利系统，大部分金融机构对监管报送系统的要求主要是稳定、数据准确。所以，市面上常见的监管报送平台还在采用之前的MVC架构的单体应用。MVC框架为一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC框架用于映射传统的输入功能、处理功能和输出功能在一个逻辑的图形化用户界面的结构中。但是，单体的MVC架构会存在以下缺陷：

(1)复杂性高、部署慢,频率低、可靠性差、扩展能力受限、阻碍技术创新、视图与控制器耦合度过高；

(2)系统复杂性高，众多的业务逻辑处理全部集中在一起，任何一个逻辑出错都可能导致整个系统瘫痪，可靠性差；

(3)部署速度慢，由于所有服务均在单体应用中，部署时需要等待所有服务全部成功加载后才可以访问；

(4)扩展能力受阻，单体应用架构统一，采用的技术也比较单一，不能适应当前前沿新技术的创新；

(5)视图与控制器高耦合，前端页面和后端服务必须配套使用，后端服务报错那么前端页面也将无法访问；

(6)随着业务的增长，传统的单体架构即使配置F5做负载均衡，也很难满足高并发、大数据量的冲击。

发明内容

为解决现有技术的不足，本发明实施例提供了一种基于微服务的监管报送系统，该系统包括：

基础平台模块，用于对系统中涉及的公共信息进行统一维护，其中，所述公共信息包括机构、菜单、角色、用户、字典，机构为金融机构所管辖的各个网点及机构的管理机构，菜单为指向维护机构基本信息的功能界面的链接，角色用于限制用户操作的菜单及使用的功能，字典用于对功能界面中的公共参数信息进行集中管理；

数据集市模块，用于根据业务类型，划分与各个监管报送相关的金融基础数据并对划分后的金融基础数据进行抽取和逻辑加工，将加工好的金融基础数据存放于监管产品规范建立的主题模型表中；

指标类数据报送模块，用于将当前监管部门所列出的基于指标报送的各个监管子系统做归并；

明细类数据报送模块，用于利用报送接口，报送金融机构的实际数据；

血脉分析模块，用于对于指标类数据进行分析及追溯时做辅助分析，获取报表中的指标，判断所述指标来自于哪个主题表的哪个字段，追溯所述字段的加工逻辑，直到追溯至源端系统的具体信息。

优选地，所述基础平台模块还用于：

根据不同的权限，建立相应的角色；

将所述角色勾与相应的菜单关联；

分别将用户与对应的机构及角色关联。

优选地，所述数据集市模块还用于：

根据需求，通过ETL工具将业务数据按表级关系将所述业务数据迁移至数据集市模块。

优选地，所述数据集市模块还用于：

按业务逻辑汇总整理所述业务数据并存放于监管产品规范建立的主题模型表中。

优选地，所述监管子系统包括1104非现场监管报表系统、大集中金融监管信息系统、支付统计分析系统。

本发明实施例提供的基于微服务的监管报送系统，具有以下有益效果：

(1)由于拆分后的各个业务模块之间处于隔离状态，使得异常只会影响自身服务或其他少量服务而不会导致系统瘫痪，提高了系统的可靠性；

(2)可以在软件资源及硬件资源充足的情况下，尽可能地横向扩展以保证系统的性能，提高了系统的吞吐率。

附图说明

图1为本发明实施例提供的基于微服务的监管报送系统的结构示意图。

具体实施方式

以下结合附图和具体实施例对本发明作具体的介绍。

如图1所示，本发明提供的实施例提供的基于微服务的监管报送系统包括：

基础平台模块，用于对系统中涉及的公共信息进行统一维护，其中，所述公共信息包括机构、菜单、角色、用户、字典，机构为金融机构所管辖的各个网点及机构的管理机构，菜单为指向维护机构基本信息的功能界面的链接，角色用于限制用户操作的菜单及使用的功能，字典用于对功能界面中的公共参数信息进行集中管理。

数据集市模块，用于根据业务类型，划分与各个监管报送相关的金融基础数据并对划分后的金融基础数据进行抽取和逻辑加工，将加工好的金融基础数据存放于监管产品规范建立的主题模型表中。

指标类数据报送模块，用于将当前监管部门所列出的基于指标报送的各个监管子系统做归并。

明细类数据报送模块，用于利用报送接口，报送金融机构的实际数据。

其中，对明细类数据的加工需要根据不同的报送接口做逻辑处理，所以代码逻辑也差异较大，因此将其独立为明细类数据。

作为一个本发明具体的实施例，明细类数据报送模块是相对于非指标类监管系统，主要包括监管数据标准化、征信系统、存贷综合统计、个人结算账户等子系统。

血脉分析模块，用于对于指标类数据进行分析及追溯时做辅助分析，获取报表中的指标，判断该指标来自于哪个主题表的哪个字段，追溯所述字段的加工逻辑，直到追溯至源端系统的具体信息。

其中，血脉分析模块主要是通过图形化的方式供指标系统端作为服务调用，所以为单独的模块。

可选地，基础平台模块还用于：

根据不同的权限，建立相应的角色；

将角色勾与相应的菜单关联；

分别将用户与对应的机构及角色关联。

可选地，数据集市模块还用于：

根据需求，通过ETL工具将业务数据按表级关系将业务数据迁移至数据集市模块。

其中，数据迁移的原因是因为业务数据分散在不同的数据库中。

可选地，数据集市模块还用于：

按业务逻辑汇总整理业务数据并存放于监管产品规范建立的主题模型表中。

其中，由于数据隔离和数据库差异等原因不利于做数据加工分析。

可选地，监管子系统包括1104非现场监管报表系统、大集中金融监管信息系统、支付统计分析系统。

其中，该类系统的功能实现逻辑完全一致，公用一套处理逻辑，针对不同的监管子系统纳入不同的系统菜单，仅仅使用系统标志区分不同子系统，这样将不需要为每个子系统单独编写一套系统功能，方便后续系统维护并极大地提高了交付效率。该类系统的主要特点是每条报送数据都有一个确定的指标来唯一定位，每个报表的总条数都是监管发文规定的，这类系统的数据加工需要对每个指标在业务数据中做逻辑映射生成公共的指标结果表，因而代码逻辑处理相似，所以将指标类模块作为独立的模块。

特别地，对每个启动的业务模块，统一注册到注册中心Eureka中，注册中心Eureka采用集群部署，服务列表会相互注册，当注册中心Eureka服务端失效后会从注册中心Eureka客户端中随机找一个替代为服务端，注册中心Eureka的高可用性使得只需关注业务逻辑的实现。

服务调用者在调用时为了能够将请求均衡的分散到服务提供者，现采用Ribbon组件来做负载均衡处理，Ribbon客户端组件提供一系列完善的配置项如连接超时，重试等基于某种规则(如简单轮询，随即连接等)去连接注册中心Eureka中的服务列表。

微服务之间的服务调用采用Restful接口，通过Feign客户端实现，Feign客户端是一个声明式的web服务客户端，使得编写web服务客户端变得更加容易，其底层集成了Ribbon微服务和Hystrix微服务，分别用于跨服务调用的负载均衡和服务熔断。

本发明实施例提供的基于微服务的监管报送系统包括基础平台模块、数据集市模块、指标类数据报送模块、明细类数据报送模块及血脉分析模块，其中，基础平台模块用于对系统中涉及的公共信息进行统一维护；数据集市模块用于根据业务类型，划分与各个监管报送相关的金融基础数据并对划分后的金融基础数据进行抽取和逻辑加工，将加工好的金融基础数据存放于监管产品规范建立的主题模型表中；指标类数据报送模块用于将当前监管部门所列出的基于指标报送的各个监管子系统做归并；明细类数据报送模块用于利用报送接口，报送金融机构的实际数据；血脉分析模块用于对于指标类数据进行分析及追溯时做辅助分析，获取报表中的指标，判断该指标来自于哪个主题表的哪个字段，追溯所述字段的加工逻辑，直到追溯至源端系统的具体信息，提高了系统的可靠性及吞吐率。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的系统，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述，构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

此外，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本领域内的技术人员应明白，本申请的实施例可提供为方法、系统、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

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

本领域技术人员应明白，本申请的实施例可提供为方法、系统或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。