CN110225114A

CN110225114A - 文件传输与管理系统

Info

Publication number: CN110225114A
Application number: CN201910504406.6A
Authority: CN
Inventors: 顾斌; 刘丽; 戴文婷; 谭胜均; 胡及宇; 郑位威; 陈棣
Original assignee: SHANGHAI BANKS CO Ltd
Current assignee: SHANGHAI BANKS CO Ltd
Priority date: 2019-06-12
Filing date: 2019-06-12
Publication date: 2019-09-10

Abstract

本发明提供了一种文件传输与管理系统，具有中心侧和应用侧，所述中心侧作为管理监控的中心应用，负责展示文件传输的过程、文件传输配置并实时监控任务状态，所述中心侧具有管理模块、信息展示模块、统计分析模块和系统维护模块；所述应用侧部署于需要传输文件功能的应用端，是以应用用户权限运行的独立进程，所述应用侧具有管理模块和文件处理模块。本发明在文件传输的基础功能之上，建立可以被管理的文件传输体系与相应的技术框架与具体服务。使应用之间的数据文件交换服务更加可控、安全、稳定、高效地运行，且整个文件传输过程、传输任务配置、API调用、服务版本更新等，可被有效地监控与管理。

Description

文件传输与管理系统

技术领域

本发明涉及文件传输技术领域，尤其是涉及一种文件传输与管理系统。

背景技术

随着金融业各类应用的规模不断扩大，应用之间的关联性越来越紧密的背景下，应用之间使用数据文件进行信息交互的场景也越来越多。

为了使应用之间的数据文件交换服务更加可控、安全、稳定、高效地运行，且整个文件传输过程、传输任务配置、API调用、服务版本更新等，可被有效地监控与管理，故需要该文件传输及其管理系统。

发明内容

本发明的目的在于提供一种文件传输与管理系统，以解决现有的问题。

为了达到上述目的，本发明提供了一种文件传输与管理系统，所述文件传输与管理系统具有中心侧和应用侧，

所述中心侧作为管理监控的中心应用，负责展示文件传输的过程、文件传输配置并实时监控任务状态，所述中心侧具有管理模块、信息展示模块、统计分析模块和系统维护模块；

所述应用侧部署于需要传输文件功能的应用端，所述应用侧具有管理模块和文件处理模块；

中心侧的管理模块接收注册信息，发布版本，干预任务，监控应用侧任务的健康状态；

中心侧的信息展示模块展示应用侧任务的实时工作状态、异常；

中心侧的统计分析模块提供运维情况报告、服务健康状况统计、分析报告；

中心侧的系统维护模块负责中心侧多机多活状态控制与维护，系统启停、应用技术的参数维护；

应用侧的管理模块向中心侧注册服务、汇报状态，接受中心侧的指令；

应用侧的文件处理模块负责文件的发送和接收，管理模块异常时，接受中心侧指令与执行必要的动作。

可选的，中心侧的管理模块还包含文件传输地图、PASO信息维护与使用、任务变更。

可选的，所述中心侧的应用双活部署。

可选的，所述中心侧面向决策支持与管理层、技术支持层，所述应用侧面向渠道接入层、交互控制层、业务处理层。

可选的，应用侧的管理模块与文件处理模块相互独立，进程上相互守护。

可选的，应用侧的管理模块与文件处理模块为两个相互独立的Java虚拟机。

可选的，应用侧的管理模块向其文件处理模块发送管理指令，应用侧的文件处理模块向其管理模块发送任务状态，应用侧的文件处理模块与API之间相互发送文件传输指令；应用侧的管理模块与中心侧管之间相互发送状态汇报、版本更新，当应用侧的管理模块异常时，中心侧对应用侧的文件处理模块进行强制干预。

为了达到上述目的，本发明还提供了一种文件传输与管理方法，采用上述文件传输与管理系统，所述文件传输与管理方法包括：

(1)发送方和接收方均使用本地存储，指定一个发送节点传输文件给另外一个指定的接收节点；

(2)一对多发送，每个应用只有一个节点参与文件的发送或接收；

(3)发送方多节点共享存储，接收方为指定的某一个接收节点；

(4)发送方多节点共享存储，接收方亦为多节点共享储存。

为了达到上述目的，本发明还提供了一种文件传输与管理方法，采用上述文件传输与管理系统，应用A与部署在应用A的文件处理模块之间设有API作为信息交互接口，应用A把文件信息通过API传送给应用A的文件处理模块，部署在应用A的文件处理模块向部署在应用B的文件处理模块发送文件。

为了达到上述目的，本发明还提供了一种文件传输与管理方法，采用上述文件传输与管理系统，应用B与部署在应用B的文件处理模块之间设有API，应用A将文件信息通过交易报文发送给应用B，应用B通过API使用文件处理模块主动获取应用A上的文件。

由于采用了上述技术方案，本发明与现有技术相比，具备如下有益效果：

(1)按(文件发送方)设定的文件传出任务的要求，为各类应用提供可靠的数据文件的发送与接收(技术)服务。

(2)根据在线应用场景的实际需要，为应用提供能进行点到点文件快速传输的API,并根据应用的需要，给予文件发送方以本次文件传输是否安全到达目的地的明确的结果应答。

(3)上述行为，均可在中心侧，被统一监控、管理以及进行异常干预和处置。

(4)文件传输任务的设置，由文件发送方在其应用侧，按照约定的规则，使用相关配置工具进行设置，在中心侧进行人工审核后生效(后续根据管理要求，也可按照文件重要性的等级要求，设置为人工审核或自动审核)。

附图说明

图1为简单的轮询(定时)工作模式图。

图2为一对多发送的轮询(定时)工作模式图。

图3为发送方多节点共享存储(要求多活)，接收方为指定的某一个接收节点的轮询(定时)工作模式图。

图4为发送方多节点共享存储(要求多活)，接收方亦为多节点共享储存(要求多活)的轮询(定时)工作模式图。

图5为主动发送的API模式示意图。

图6为主动接收的API模式示意图。

图7为应用侧模块关系示意图。

图8为免编程框架工作原理示意图。

图9为总体逻辑架构图。

图10为中心侧的应用双活部署图。

具体实施方式

下面将结合示意图对本发明的具体实施方式进行更详细的描述。根据下列描述，本发明的优点和特征将更清楚。需说明的是，附图均采用非常简化的形式且均使用非精准的比例，仅用以方便、明晰地辅助说明本发明实施例的目的。

本发明在文件传输的基础功能之上，建立起可以被管理的文件传输体系与相应的技术框架与具体服务。从整体应用架构看，本发明分为应用侧的服务与中心侧的服务两大部分。应用侧的服务(工具)、API等，由中心侧的服务进行统一管理。

应用侧：部署于需要传输文件功能的应用端，以应用用户权限运行的独立进程。

应用侧具有管理模块、文件处理模块。其中，管理模块向中心侧注册服务、汇报状态，接受中心侧指令等。文件处理模块负责文件的发送/接收，管理模块异常时，接受中心侧指令与执行必要的动作。管理模块与文件处理模块为两个独立的Java虚拟机(JVM)，进程上相互守护。

中心侧：作为管理监控的中心应用，负责展示整个文件传输的过程，文件传输配置，并能实时监控当前在传输任务状态。

中心侧具有管理模块、信息展示模块、统计分析模块、系统维护模块。其中，管理模块接收注册信息，发布版本，干预任务，监控应用侧服务的健康状态，文件传输地图、PASO信息维护与使用、任务变更等。信息展示模块展示应用侧已启动任务的实时工作状态、异常等。统计分析模块提供运维情况报告、服务健康状况统计、其它特定分析报告。系统维护模块负责中心侧多机多活状态控制与维护，系统启停、应用技术的参数维护等。

轮询(定时)工作模式

1、简单模式(该模式的通用度较高)，即发送/接收方均使用本地存储，指定一个发送节点传输文件给另外一个指定的接收节点。

如图1所示，应用A(或B)中一个指定的节点，按文件传输任务的要求，把文件发送给应用B(或A)中的一个指定节点。过程中，发送、接收双方，均将本节点文件处理的过程与结果状态，汇报给中心侧的管理服务。

2、一对多发送，即每个应用只有一个节点参与文件的发送/接收。

如图2所示，根据应用的要求，可设置在一方接收失败后，整个任务回滚或容忍。

3、发送方多节点共享存储(要求多活)，接收方为指定的某一个接收节点。

如图3所示，应用A(01/02)节点共享存储，文件由A-01(或A-02)节点产生，部署在A-01与A-02上的文件传输服务，根据任务设定的要求，发现有需要传输给应用B的文件时，在共享存储上的“待传文件所在的目录”下，产生隐含的控制文件，以阻止另外一个节点也启动本次任务的输送动作。即，在应用A的文件传输服务多节点多活的状态下，同一任务只能由一个发送节点进行。A-01、A-02其中一台异常时，文件传输功能不受影响(中心侧可监测到服务异常的情况，在中心侧尝试自动/人工恢复服务)。

4、发送方多节点共享存储(要求多活)，接收方亦为多节点共享储存(要求多活)。

如图4所示，根据应用需要，应用A-01在锁定文件传输任务后，使用内部负载均衡算法，获取应用B的其中一个可用节点，进行文件传输，应用B有一个节点异常，不影响文件接收。

API模式

1、主动发送

如图5所示，API作为应用的一个jar包资源(或动态库，提供给使用C语言编程的应用)，本身并无文件传输的功能，只是应用与部署在该应用侧的文件处理模块之间的信息交互接口。应用A，把目的地参数、文件名等信息，通过API传送给文件处理模块，文件传输动作共享体系中的基础服务功能。

API返回文件到达结果信息。应用可按需同步接收传输结果、只是B端在启动接收任务后即刻返回的回执，或异步获得传输结果。

2、主动接收

如图6所示，应用A将文件在A端的信息(IP地址、文件名、存储路径等)，通过交易报文发送给应用B(备注：应用之间约定的流程，非文件传输服务之间的通讯)，应用B通过API，使用文件处理模块功能，主动获取应用A上的文件(应用B获取文件成功后，是否要实时通过应用之间的交易报文告知A，由双方应用根据自身的业务处理流程要求而定)。

应用侧模块关系

如图7所示，应用侧的管理模块向文件处理模块发送管理指令等，文件处理模块向管理模块发送任务状态等，文件处理模块与API之间相互发送文件传输指令。应用侧的管理模块与中心侧管理服务之间相互发送状态汇报、版本更新等，当应用侧的管理模块异常时，中心侧对应用侧的文件处理模块进行强制干预等。

中心侧服务的技术框架

如图8所示，动作解析与处理引擎是后续免编程或尽量减少编程的基础模块，应用的总入口。在现实环境中，文件传输所涉的所有场景，可被穷举。因此，具备可归纳与抽象的基础，使得后续变更动作或流程时，免编程成为确切的可能。

总体逻辑架构设计

从整体应用架构看，文件传输与管理系统分为应用侧的服务与中心侧的服务两大部分。

应用侧的服务(工具)、API等，由中心侧的服务进行统一管理。

如图9所示，业务数据的流向：

部署在中心侧服务与部署在应用侧服务之间的信息(或指令)传递(状态汇报、版本管理、健康检查等等)，如(4)、(5)、(6)、(7)、(8)。

文件传输(由部署在各应用侧节点上文件传输服务的“文件处理”功能模块之间进行)，如(1)、(2-3)、(3)。

在API的调用模式中(主动获取或主动发送)，应用之间(非本应用的模块之间)有通知报文或结果状态的信息交换(属于业务系统本身的流程，见前述章节)，如(2-2)。

部署在中心侧的应用提供运维界面：(9)

应用双活架构设计

如图10所示，中心侧的应用双活部署(数据库主备)。

数据库：UpSql，主从模式

应用高可用：张江中心双服务器双活；应用侧服务(管理模块、文件处理模块)使用内置的负载均衡算法(含可用性推测)访问中心侧服务。

参与运维管理的相关人员，通过URL1(服务器APP1)或URL2(服务器APP-2)访问中心侧的管理应用(无须部署Apache服务器、F5等)。

B类应用，石泉中心做数据级备份(带库)。

说明：

中心侧的服务(B类应用)不参与文件传输动作；一旦中心侧的主数据库故障，可以切到备库；双数据库均损坏时，可以重新安装数据库，应用侧的服务，根据中心侧的指令，上送指令要求的信息。因此，中心侧的服务，可以再次收集应用侧的所有传输任务的配置等信息；其余相对静态的管理信息(如PASO映射等)，可以使用中心侧的应用定期备份的文本数据导入数据库。

同时，因为中心侧的应用节点之间，需共享一致的管理与控制信息(有些管理与控制信息是在动态更新的)，文件传输过程中，中心侧的应用不是关键路径，本应用也不涉及大数据量更新与查询，因此，不使用分库(分表)的方式，以忽略应用关于数据分布路径计算的复杂度。

因此，中心侧的应用，采用极简的部署方式，在满足本应用需要的前提下，节省基础设施的投入。

上述仅为本发明的优选实施例而已，并不对本发明起到任何限制作用。任何所属技术领域的技术人员，在不脱离本发明的技术方案的范围内，对本发明揭露的技术方案和技术内容做任何形式的等同替换或修改等变动，均属未脱离本发明的技术方案的内容，仍属于本发明的保护范围之内。

Claims

1.一种文件传输与管理系统，其特征在于，所述文件传输与管理系统具有中心侧和应用侧，

2.如权利要求1所述的文件传输与管理系统，其特征在于，中心侧的管理模块还包含文件传输地图、PASO信息维护与使用、任务变更。

3.如权利要求1所述的文件传输与管理系统，其特征在于，所述中心侧的应用双活部署。

4.如权利要求1所述的文件传输与管理系统，其特征在于，所述中心侧面向决策支持与管理层、技术支持层，所述应用侧面向渠道接入层、交互控制层、业务处理层。

5.如权利要求1所述的文件传输与管理系统，其特征在于，应用侧的管理模块与文件处理模块相互独立，进程上相互守护。

6.如权利要求5所述的文件传输与管理系统，其特征在于，应用侧的管理模块与文件处理模块为两个相互独立的Java虚拟机。

7.如权利要求1所述的文件传输与管理系统，其特征在于，应用侧的管理模块向其文件处理模块发送管理指令，应用侧的文件处理模块向其管理模块发送任务状态，应用侧的文件处理模块与API之间相互发送文件传输指令；应用侧的管理模块与中心侧管之间相互发送状态汇报、版本更新，当应用侧的管理模块异常时，中心侧对应用侧的文件处理模块进行强制干预。

8.一种文件传输与管理方法，其特征在于，采用权利要求1～7任一项所述的文件传输与管理系统，所述文件传输与管理方法包括：

(4)发送方多节点共享存储，接收方亦为多节点共享储存。

9.一种文件传输与管理方法，其特征在于，采用权利要求1～7任一项所述的文件传输与管理系统，应用A与部署在应用A的文件处理模块之间设有API作为信息交互接口，应用A把文件信息通过API传送给应用A的文件处理模块，部署在应用A的文件处理模块向部署在应用B的文件处理模块发送文件。

10.一种文件传输与管理方法，其特征在于，采用权利要求1～7任一项所述的文件传输与管理系统，应用B与部署在应用B的文件处理模块之间设有API，应用A将文件信息通过交易报文发送给应用B，应用B通过API使用文件处理模块主动获取应用A上的文件。