CN101989294A - 分布式文件解析方法和解析系统 - Google Patents

Abstract

一种分布式文件解析方法和解析系统，用以本端对发送端发送的各种类型数据进行解析。该方法包括，(1)设置用以对文件进行解析的脚本文件，脚本文件中保存至少一种类型文件的解析程序；(2)将该些脚本文件以文本方式导入数据存储空间中；(3)接收到发送端发送的某一文件时，核心系统通过该文件所属的类型从数据存储空间中找到对应的脚本文件；(4)核心系统利用脚本引擎加载并运行脚本文件，完成对所述文件的解析。当有文件类型发生变化时，只需要将对应的脚本文件进行修改即可，无需要整个系统进行测试，提升了系统的稳定性和安全性，而且也节省了修改的时间。

Description

分布式文件解析方法和解析系统

技术领域

本申请涉及一种分布式文件解析系统和解析方法，尤其涉及一种基于JVM(Java Virtual Machine，java虚拟机)和动态脚本语言的分布式文件解析方法和解析系统。

背景技术

大型企业IT应用系统都面临着与合作方的系统有互相通信的需求，尤其像业务规模量庞大的电信、金融、证券等国家经济基础相关的行业。这些通信都存在两大特点，其一，面临着需要交互的数据量大；其二，交互频繁。

第三方支付系统属于金融行业的清算机构，需要和它进行数据传输的清算机构多达数十家，开展的业务更是上百种，包括国内外银行、物流系统、保险、跨国企业等等，由于各行业的信息技术平台大相径庭，采用传统的信息交换方式来传输数据仍然是第三方支付系统和清算机构之间所主要采用的手段。现在就以第三方支付系统接收银行的文件传输为例，来说明现有技术针对接收到的文件进行处理的方法。

通常，不同清算机构的数据格式是不同的，甚至是同一清算机构的数据格式都不同。但是，以银行为例，同一款产品所包含的数据格式通常是相同的。何为产品，即是指银行提供给消费者的某一服务。我们把具有相同数据格式的文件称之为同一类型文件。同一类型文件所包含的字段信息、每个字段对应的属性信息相同。

第三方支付系统接收不同类型文件，需要从文件中获得数据进行处理。第三方支付系统至少包括数据库11和若干个服务器12组成的处理子系统13。服务器12上安装对应的软件(假设称该些软件为核心系统)，第三方支付系统接收到银行传送的某一文件时，核心系统需对其完成解析操作和处理操作，解析操作是指按照预先设定的格式进行解析出对应的数据，并将之保存至对应的数据库11，处理操作是指在核心系统中完成预先设定的操作。比如，对该银行当日的支出总额与本支付系统对与该银行相关的支出总额汇总后的比对是否一致等。由于获得该些文件后的处理操作是相同的，为此，核心系统对如何从接收到的文件中解析出需要的数据，再对该些数据如何进行操作等进行编程。这样，核心系统对接收到的文件即可按照预先编好的程序进行运行。

但是，现有方式在实际运行过程中存在以下的缺陷：

首先，当文件中某一数据格式发生变化时，以及当对获得的文件中的数据进行的操作发生变化时，都需要修改程序。系统中的程序一旦发生变化，就需要进行发布、测试等一系列系统升级时的操作，等这些操作通过后，系统才能将修改后的程序上线使用。在实际运行过程中，发明人发现文件中数据格式发生变化的频率极高。还是以第三方支付系统作为接收方为例，接收银行发送的数据包，解析后获得对应的数据。在实现操作过程中，第三方支付系统可能存在几百种甚至更多种类型文件。接收方定期或事件触发式地接收银行发送的数据包，经解析获得的数据，当文件中某一数据格式发生变化时，就要将发布、测试等系统升级操作流程再走一次，非常浪费时间。特别是，数据格式发生变化后，当天或第二天就要以修改后的数据格式进行解析，但是，新的核心系统程序需要经发布、测试等操作处理后才能正式上线，所花费的时间长，不能满足要求。

其次，不同类型文件的数量极多，导致无论哪种类型文件中的数据格式发生变化，都需要修改软件程序，增加系统的不稳定性。

也就是说，随着业务高速发展，如何快速安全的修改这些文件格式，且还希望尽可能小的影响核心系统的高可用性是摆在面前的一项难题。

发明内容

本申请的第一目的在于提供一种分布式文件解析方法，以解决现有技术中在文件格式发生改变后为了解析该些类型文件需要升级整个系统，导致时间长、系统不稳定的技术问题。

本申请的第二目的在于提供一种分布式文件解析系统，以解决现有技术中在文件格式发生改变后为了解析该些类型文件需要升级整个系统，导致时间长、系统不稳定的技术问题。

一种分布式文件解析方法，用以本端对发送端发送的各种类型文件进行解析，包括：

(1)设置用以对文件进行解析的脚本文件，脚本文件中保存至少一种类型文件的解析程序；

(2)将该些脚本文件以文本方式导入数据存储空间中；

(3)接收到发送端发送的某一文件时，核心系统通过该文件所属的类型从数据存储空间中找到对应的脚本文件；

(4)核心系统利用脚本引擎加载并运行脚本文件，完成对所述文件的解析。

当某一类型的文件格式发生变化时，修改并保存脚本文件中对应的程序，并导入数据存储空间中对应存储位置。

一种分布式文件解析系统，用以本端对发送端发送的各种类型数据进行解析，包括：

数据存储空间：用于存储用动态脚本文件语言编写的用以对文件进行解析的脚本文件；

工作平台：将该些脚本文件以文本方式导入数据存储空间中；

核心系统：用于接收到发送端发送的某一文件时，通过该文件所属的类型从数据存储空间中找到对应的脚本文件，再利用脚本引擎加载并运行脚本文件，完成对所述文件的解析。

一种分布式文件解析方法，用以本端对发送端发送的各种类型文件数据进行解析，包括：

(1)用动态脚本语言编写的用以对文件进行解析的脚本，脚本中保存至少一类型文件的解析程序；

(2)将该些脚本以文本方式导入数据存储空间中；

(3)核心系统通过脚本引擎加载脚本后执行生效；

(4)接收到发送端发送的文件时，核心系统按照该文件所属的类型将其解析。

本方法还包括：当某一类型的文件格式发生变化时，修改并保存脚本文件中对应的程序，并导入数据存储空间中对应存储位置。

与现有技术相比，通过第三方支付系统使用网银的业务量每天有几十万笔，日终需要对当日支付的流水进行对账，对账流水数据均以文件的方式由银行传给第三方支付提供商，由于金融行业市场的周期性非常强，业务产品规则随时需要因市场变化而快速升级，文件格式也必须随业务变化而修改，解析文件的脚本程序是通过工作平台的WEB页面所见即所得的方式编辑并存储在数据库，所以在不需要修改，编译，部署任何核心系统前提下完成对业务系统升级，因此解析这些文件无需要整个修改系统，进而无需要进行系统升级，由此使得处理速度快，也不影响系统的稳定性。

还有，这种技术不仅适合第三方支付行业，尤其适合接入了大量的外部IT系统的应用平台，像电信3G行业的增值业务系统，银行的中间业务平台，接入的合作伙伴越多，开展的业务越复杂，需求变化越快，该技术优势便会愈明显。

附图说明

图1为现有的文件解析系统原理图；

图2为本申请文件解析系统原理图；

图3为处理子系统的原理结构示意图；

图4为本申请文件解析流程示意图；

图5为另一实施例的分布式文件解析方法的流程图。

具体实施方式

以下结合附图，具体说明本申请。

本申请的核心思想是，由于现有技术中不管哪个文件格式发生变化都需要引起整个系统测试后才能升级使用。为此，本申请人将对不同类型文件的解析程序分解成不同的脚本文件，每个脚本文件可以用以解析至少一种类型的文件，预先将脚本文件保存在数据存储空间，整个核心系统在运行时都需要将这些脚本文件从数据存储空间中加载至系统内后生效。当有文件类型发生变化时，只需要将对应的脚本文件进行修改即可，无需要对整个系统进行测试，提升了系统的稳定性和安全性，而且也节省了修改的时间。或者，本申请在接收到发送端发送的某一文件时，找到对应的脚本文件后加载生效，完成对所述文件的解析。

实施例一

请参阅图2，其为本申请分布式文件解析系统的原理结构示意图。它是用以本端对发送端发送的各种类型数据进行解析，其包括：终端21、工作平台22、数据存储空间23和若干服务器24组成的核心系统25。终端21、工作平台22和数据存储空间23可以直接连接，也可以通过网络连接。

脚本编写工程师在终端21上编写脚本文件类型，一个脚本文件用来解析一种产品或者一种业务类型。产品中可以包括若干种类型数据。产品或业务类型比较多导致需要编写的脚本文件较多。工作平台22通常是指公司内部财务或者管理人员管理公司业务的后台支持系统，一般是一套软件平台。终端一般来说是硬件，比如显示器终端，POS终端，后台支持系统通常是运行在某一设备上，供脚本编写工程师等使用。为了后续说明的方便，我们将运行后台支持系统的设备称之为工作平台。工作平台22将编写好的脚本文件导入数据存储空间23中时，还需要配置好脚本文件的相应参数，参数包括脚本文件名称、对应的类型文件或对应的产品、存储地址、属性等。

数据存储空间23：用于存储脚本文件。数据存储空间23可以是数据库，也可以是NFS文件系统(Network File System，网络文件系统)。由于数据库需要存储的数据实在太多，在本实例中，将脚本文件存储在NFS文件系统中。工作平台22可以是直接与数据库连接，也可以是直接将脚本文件存储至NFS文件系统中。

核心系统25，其可以运行在若干服务器24上，当核心系统25运行时，都需要将数据存储空间中的脚本文件通过脚本引擎加载后生效。这样，接收到发送端发送的文件时，按照该文件所属的类型将其解析。在本实施例中，核心系统25可以定期或事件触发式运行，每一次运行，都需要将所有的脚本文件或已修改的脚本文件通过脚本引擎加载后生效。当接收到发送端发送的文件时，再利用已生效的脚本对其进行解析。

核心系统25一般是指企业的关键业务处理系统，像银行的账务、交易系统，电信行业的相关计费、通讯认证系统。核心系统25通常是指具体的软件。

本实例中，脚本引擎主要完成的功能为：通过JVM的classload将脚本文件加载到JVM机内部，然后再通过groovy的内部编译器对脚本文件实时运行，无需产生java字节码，以达到加载即运行的目的。另外，为了方便管理，脚本引擎还可以将数据存储空间23存储的所有脚本文件先合并成一个总脚本文件，这样后续加载时只需要加载一个总脚本文件即可。

请参阅图3，其为核心系统25的原理结构示意图。

核心系统25包括JVM机31和脚本引擎32，脚本引擎32进一步包括：

合并处理单元321，用于将数据存储空间23存储的所有脚本文件合并成一个总脚本文件；

加载处理单元322，用于通过JVM的classload将脚本文件加载到JVM机内部；

运行单元323，用于通过groovy的内部编译器对脚本文件实时运行。

脚本引擎32可以设置在JVM机31的外部，也可以设置在JVM机31的内部，作为JVM机的一个组成部分。另外，还需要说明的是，上述涉及到的JVM机31和脚本引擎32通常是用软件来实现的，但是也不能排除将其硬件化。

在本实例中，当有某一类型的文件格式发生改变时，修改脚本文件中的程序，并将该脚本文件导入数据存储空间23中对应存储位置，这样，当核心系统25运行时，就把修改好的脚本文件通过脚本引擎加载后生效了。核心系统是在每一次运行时重新加载所有脚本文件或上一次运行后重新修改的脚本文件。当然，核心系统也可在每一次启动时重新加载所有脚本文件类型。

参阅图4，其为一种分布式文件解析方法的流程示意图。它用以本端对发送端发送的各种类型数据进行解析，包括：

S110：用动态脚本语言编写用以对文件进行解析的脚本文件。

S120：将该些脚本文件以文本方式导入数据存储空间中。

本实例中，可以将核心系统所涉及的所有文件类型都设置一个脚本文件，其上保存对应类型文件的解析程序。也可以根据产品设置一个脚本文件，脚本文件中包含多个多种类型的解析程序。在本例中，由于动态脚本语言是一种区别传统静态类型如C、C++、JAVA的编程语言，它无需单独编译和链接，可以做到动态加载，即时运行，包括Python，javascript，groovy等，在本实例中，主要是使用JAVA平台上原生的动态脚本语言groovy。并将该些脚本配置参数后，保存至数据存储空间对应的位置。当后续某一类型的文件格式发生变化时，只需要修改对应的脚本文件，并将之保存至数据存储空间对应位置即可。

步骤S120进一步包括：将该些脚本文件以文本方式导入数据库；再由数据库加载并发布至NFS系统上，NFS系统中的脚本文件是以文本文件方式存储，或将该些脚本文件直接加载并发布至NFS系统上，NFS系统中的脚本文件是以文本文件方式存储。

S130：核心系统通过脚本引擎加载脚本文件后执行生效。

核心系统可以在每一次运行时，对数据存储空间上所有脚本文件通过脚本引擎加载脚本文件生效。核心系统也可以在每一次启动时，对数据存储空间上所有脚本文件通过脚本引擎加载。在本实例中，核心系统采用在每一次运行时重新加载，考虑到若将所有的脚本文件都重新加载，所花费的时间长。还可以在数据存储空间中设置一张脚本文件修改表，只加载上一次未加载的新修改脚本文件。

在本实例中，是先将数据存储空间23存储的所有脚本文件先合并成一个总脚本文件；再通过JVM的classload将脚本文件加载到JVM机内部；最后再通过groovy的内部编译器对脚本文件实时运行。

S140：接收到发送端发送的文件时，核心系统按照该文件所属的类型将其解析。脚本文件上保存的就是某一类型文件或某几种类型的解析程序，当脚本文件生效后，接收到文件时，判断出文件类型，即可根据对应的解析程序解析出数据来。

举一个简单的实例，分布式文件解析系统中的服务器24的前端设置若干个通信端口，每一个通信端口接收一种产品，每一种产品的解析程序设置在同一个脚本文件中，通信端口与产品建立起对应关系，产品又和脚本文件建立起对应关系。这样，通信端口通过产品和脚本文件建立起对应关系。接收到文件时，即可判断出文件类型，以及对应的脚本文件。

假设某家银行借记卡原有的打款数据格式为“打款时间、地址、银行代码、币种、汇款方账户、收款方账户、金额”。脚本文件中的脚本程序主要做的工作是，对接收到的文件中的数据按照预先设定的解析方式将数据解析出来，现有的文件中数据是按照打款格式组织的，比如“20090730杭州......”，需要利用脚本文件解析出“20090730”为打款时间，“杭州”为打款地址等。

若该打款格式发生了变化，变化为“打款时间、地址、银行代码、币种、汇款方账户、汇款方名称、收款方账户、收款方名称、金额”，此时对应的脚本文件对应的程序也要发生变化，这样接收到打款数据时，就能解析出对应数据是什么数据，什么内容了。

实施例二

请参阅图5，其为本实施例2的一种分布式文件解析方法的流程图。用以本端对发送端发送的各种类型文件进行解析，包括：

S210：设置用以对文件进行解析的脚本文件，脚本文件中保存至少一种类型文件的解析程序；

S220：将该些脚本文件以文本方式导入数据存储空间中；

S230：接收到发送端发送的某一文件时，核心系统通过该文件所属的类型从数据存储空间中找到对应的脚本文件；

S240：核心系统利用脚本引擎加载并运行脚本文件，完成对所述文件的解析。

与实施例一最大的不同在于，核心系统不是一次将所有的脚本文件进行加载运行，而是每接收到发送端发送的某一文件时，再找到对应的脚本文件，运行该脚本文件，完成对该文件中的所有数据的解析。

比如，分布式文件解析系统中的服务器24的前端设置若干个通信端口，每一个通信端口接收一种产品，每一种产品的解析程序设置在同一个脚本文件中，通信端口与产品建立起对应关系，产品又和脚本文件建立起对应关系。这样，通信端口通过产品和脚本文件建立起对应关系。

一种比较常见的对应关系为，通信端口保存与之有对应关系的脚本文件的存储地址信息。当接收到某一文件时，通过该接收文件的通信端口，即可获知脚本文件的存储地址信息(存储地址信息或者称之为找到该脚本文件的路径)。根据解析程序如何解析出数据来，是现有技术，在此不再详细说明。

以第三方支付系统为例，使用本申请的解析系统和解析方法，使得核心系统的稳定性大大增加。这种技术不仅适合第三方支付行业，尤其适合接入了大量的外部IT系统的应用平台，像电信3G行业的增值业务系统，银行的中间业务平台，接入的合作伙伴越多，开展的业务越复杂，需求变化越快，该技术优势便会愈明显。

以上公开的仅为本申请的几个具体实施例，但本申请并非局限于此，任何本领域的技术人员能思之的变化，都应落在本申请的保护范围内。

Claims (15)

1.一种分布式文件解析方法，用以本端对发送端发送的各种类型文件进行解析，其特征在于，包括：

(1)设置用以对文件进行解析的脚本文件，脚本文件中保存至少一种类型文件的解析程序；

(2)将该些脚本文件以文本方式导入数据存储空间中；

(3)接收到发送端发送的某一文件时，核心系统通过该文件所属的类型从数据存储空间中找到对应的脚本文件；

(4)核心系统利用脚本引擎加载并运行脚本文件，完成对所述文件的解析。

2.如权利要求1所述的分布式文件解析方法，其特征在于，还包括：

当某一类型的文件格式发生变化时，修改并保存脚本文件中对应的程序，并导入数据存储空间中对应存储位置。

3.如权利要求2所述的分布式文件解析方法，其特征在于，步骤(2)进一步包括：

将该些脚本文件以文本方式导入数据库；

再通过数据库加载并发布至NFS系统上，NFS系统中的脚本文件是以文本文件方式存储。

4.如权利要求1或2所述的分布式文件解析方法，其特征在于，步骤(2)进一步包括：

将该些脚本文件直接加载并发布至NFS系统上，NFS系统中的脚本文件是以文本文件方式存储。

5.如权利要求1所述的分布式文件解析方法，其特征在于，所述脚本文件是通过动态脚本语言编写的。

6.如权利要求5所述的方法，其特征在于，步骤(4)进一步包括：

用于通过JVM的classload将脚本文件加载到核心系统的JVM机内部；

通过groovy的内部编译器对脚本文件实时运行。

7.如权利要求6所述的方法，其特征在于，步骤(2)还包括：

先将数据存储空间存储的所有脚本文件先合并成一个总脚本文件。

8.如权利要求1所述的方法，其特征在于，

步骤(3)之前还包括，预先设置用来接收每一种类型文件对应的通信端口，建立各个通信端口和脚本文件存储地址的对应关系，所述脚本文件为包含通信端口对应的类型文件的解析程序的脚本文件；

步骤(3)进一步包括，接收到发送端发送的某一文件时，获知接收该文件的通信端口，根据通信端口来获知脚本文件存储地址，从而找到脚本文件。

9.一种分布式文件解析系统，用以本端对发送端发送的各种类型数据进行解析，其特征在于，包括：

数据存储空间：用于存储用动态脚本文件语言编写的用以对文件进行解析的脚本文件；

工作平台：将该些脚本文件以文本方式导入数据存储空间中；

核心系统：用于接收到发送端发送的某一文件时，通过该文件所属的类型从数据存储空间中找到对应的脚本文件，再利用脚本引擎加载并运行脚本文件，完成对所述文件的解析。

10.如权利要求9所述的系统，其特征在于，还包括：

若干终端，提供利用脚本文件编辑器用动态脚本文件语言编写的用以对文件进行解析的脚本文件，每一脚本文件中保存至少对一种类型文件的解析程序。

11.如权利要求9所述的系统，其特征在于，数据存储空间为NFS系统。

12.如权利要求11所述的系统，其特征在于，还包括数据库，其分别连接工作平台和NFS系统。

13.如权利要求9所述的系统，其特征在于，核心系统进一步包括JVM

机和脚本引擎，脚本引擎进一步包括：

合并处理单元，用于将数据存储空间存储的所有脚本文件先合并成一个总脚本文件；

加载处理单元，用于通过JVM的classload将脚本文件加载到JVM机内部；

运行单元，用于通过groovy的内部编译器对脚本文件实时运行。

14.一种分布式文件解析方法，用以本端对发送端发送的各种类型文件数据进行解析，其特征在于，包括：

(1)用动态脚本语言编写的用以对文件进行解析的脚本，脚本中保存至少一种类型文件的解析程序；

(2)将该些脚本以文本方式导入数据存储空间中；

(3)核心系统通过脚本引擎加载脚本后执行生效；

(4)接收到发送端发送的文件时，核心系统按照该文件所属的类型将其解析。

15.如权利要求14所述的分布式文件解析方法，其特征在于，还包括：

当某一类型的文件格式发生变化时，修改并保存脚本文件中对应的程序，并导入数据存储空间中对应存储位置。

Images