分布式文件解析方法和解析系统 技术领域 本申请涉及一种分布式文件解析系统和解析方法， 尤其涉及一种基于 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 行业的增值业务系统， 银行的中间业务平台， 接入的合作伙伴越多， 开 展的业务越复杂， 需求变化越快， 该技术优势便会愈明显。
以上公开的仅为本申请的几个具体实施例， 但本申请并非局限于此， 任何本领域 的技术人员能思之的变化， 都应落在本申请的保护范围内。