CN103581123A - 网络数据的处理方法及装置、网络数据的发布方法及系统 - Google Patents

Abstract

本发明提供了一种网络数据的处理方法及装置、网络数据的发布方法及系统，其中，该网络数据的处理方法包括：根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，第一配置信息包括：用于获取原始网络数据的来源信息；根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。本发明解决了相关技术中第三方客户端需要编写不同的代码来处理不同网络API数据的问题，从而在提高数据处理效率的同时，减少了代码编写人员的工作量。

Description

网络数据的处理方法及装置、网络数据的发布方法及系统

技术领域

本发明涉及通信领域，具体而言，涉及一种网络数据的处理方法及装置、网络数据的发布方法及系统。

背景技术

在网络的发展中，出现了网络应用程序接口（Application Program Interface，简称为API）即由数据提供者（网站）通过网络API发布数据，各种客户端（桌面客户端、移动终端客户端、第三方网站）通过网络API获得数据并再处理呈现给最终用户。即：数据被存储在它的提供者那里，用网络API获得，而数据的传播和呈现则由第三方负责。

网络API的形式是多种多样的，一般是提供一个统一资源定位符（Uniform ResourceLocator，简称为URL）地址，和约定传入参数，当使用者访问这个URL地址并传入正确的参数时，服务器将网络API的运算结果用可扩展标记语言（Extensible Markup Language，简称为XML），JSON等格式返给使用者。其他的可以作为网络API传递运算结果的格式还有RSSResource Sharing System资源共享系统RSS、SOAP（Simple Object Access Protocol，简单对象访问协议）SOAP等。RSS主要应用于新闻、博客等发布，是一种出现的较早的格式，有自己专用的阅读器。SOAP主要用于服务器之间的网络API调用，可以认为是服务器之间的“交互语言”。

网络API很好用，但是也有自己的不足。我们从以下方面来说：

一、站在数据提供者的角度来说，第三方（客户端）对它的服务器的并行访问压力很重。因此，建设一个能提供网络API的网站的门槛很高。

一方面，要让众多的第三方使用网络API，就需要数据提供者的服务器的并行访问能力非常出众，否则很容易死机。要构建起能支撑巨大并行访问量的服务器需要很多资金，这是普通网站建设者做不到的。所以现在能提供网络API的主要是大型网站。另一方面，如果普通网站建设者依靠购买大型网站提供的云计算服务来提供网络API，就必须将自己的代码和数据都存放在大型网站那里，一旦大型网站出现问题，对于普通网站自己是非常不利的。

二、站在第三方的角度来说，因为第三方客户端缺乏自动处理网络数据的手段，所以用网络API编写程序做的重复工作较多，编程压力重。

目前要使用网络API，第三方程序员就必须要编写代码。这是因为各种网络API的来源、数据格式定义和参数定义均不相同，所以每当需要使用一个新的网络API时，就必须编写相应的代码来访问和处理数据，这对程序员的压力很重。而且，如果需要将来自于多个网络API提供者的数据进行融合时，更是必须要编写代码来完成。

针对相关技术中上述至少之一的问题，目前尚未提出有效的解决方案。

发明内容

本发明提供了一种网络数据的处理方法及装置、网络数据的发布方法及系统，以至少解决相关技术中第三方客户端需要编写不同的代码来处理不同网络API数据的问题。

根据本发明的一个方面，提供了一种网络数据的处理方法，其包括：根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，第一配置信息包括：用于获取原始网络数据的来源信息；根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。

优选地，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据包括：根据来源信息从不同形式的网络API获取待发布的原始网络数据，其中，来源信息包括：原始网络数据的格式、获取原始网络数据的统一资源定位符URL、访问URL的预设参数。

优选地，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据包括：根据来源信息中定义的路径信息通过XML路径语言（XML Path Language，简称为XPATH）方式获取原始网络数据。

优选地，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据之后，上述网络数据的处理方法还包括：根据第一配置信息中的存储信息将原始网络数据存储到数据库中，其中，存储信息包括：原始网络数据将要存储在数据库中的数据库表的预表名、数据库表的版本号、原始网络数据在数据库中存储时的名称、原始网络数据的存储类型。

优选地，根据第一配置信息中的存储信息将原始网络数据存储到数据库中包括：预表名对应着至少两个数据库表，根据预表名从预表名与数据库表的真实表名的预设映射关系中确定出存储原始网络数据的数据库表的真实表名，其中，确定出的数据库表的真实表名为数据库表中未被映射的数据库表的真实表名；根据版本号和确定出的真实表名将原始网络数据文件存储到数据库中。

优选地，根据第一配置信息中的存储信息将原始网络数据存储到数据库中包括：在存储信息中的存储类型为时间类型的情况下，获取原始网络数据的原始时间格式；根据原始时间格式解析获得原始网络数据的时间；以预设时间格式将原始网络数据按照时间顺序存储到数据库中。

优选地，根据预设的第一配置信息从不同形式的网络API获取待发布的原始网络数据之后，上述网络数据的处理方法还包括：在原始网络数据为二进制文件的情况下，根据获取原始网络数据的链接地址获取原始网络数据；将原始网络数据存储在本地文件系统中，并存储发布原始网络数据的新链接地址。

优选地，根据预设的第二配置信息将原始网络数据处理为不同发布形式的网络数据文件包括：根据第二配置信息中的数据获取方式获取原始网络数据，其中，数据获取方式包括：从数据库中获取原始网络数据、通过指定的第一配置信息来获取原始网络数据；根据第二配置信息中的预设数据形式将原始网络数据处理为不同发布形式的网络数据文件。

优选地，根据第二配置信息从数据库中获取原始网络数据包括：根据第二配置信息中的参数获取方式获取用于获得原始网络数据的参数信息，其中，参数获取方式包括以下之一：接收携带有参数信息的请求消息，查询存储原始网络数据时的预设映射关系获取原始网络数据的存储信息，并作为参数信息；根据参数信息生成结构查询语言（Structured Query Language，简称为SQL）语句来从数据库中获取原始网络数据。

优选地，根据查询存储原始网络数据时的预设映射关系获取的参数信息来从数据库中获取原始网络数据包括：根据第二配置信息中的别名查询预设映射关系确定获取原始网络数据的数据库表的真实表名，其中，别名与存储原始网络数据时使用的预表名一致，在预设映射关系中与别名对应映射的数据库表的名称为获取原始网络数据的数据库表的真实表名；使用确定出的真实表名生成SQL语句来从数据库中获取原始网络数据。

优选地，根据第二配置信息从指定的第一配置信息来获取原始网络数据包括：根据参数信息从指定的第一配置信息中确定原始网络数据的来源信息；根据来源信息从不同形式的网络API获取原始网络数据。

优选地，预设数据形式包括以下之一：可扩展标记语言（Extensible Markup Language，简称为XML）形式、轻量级数据交换语言（JavaScript Object Notation，简称为JSON）形式、超文件标记语言（Hypertext Markup Language，简称为HTML）形式。

优选地，间隔预设时间周期根据第一配置信息从不同形式的网络API获取原始网络数据，并根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。

根据本发明的另一方面，提供了一种网络数据的发布方法，其包括：根据上述任一种方法网站的云服务器对不同形式的原始网络数据处理为不同发布形式的网络数据文件，并通过云服务器来发布网络数据文件，其中，云服务器使用的URL与网站的URL相关。

优选地，网络数据包括：网站从除网站之外的其他网站获得的网络数据。

根据本发明的又一方面，提供了一种网络数据的处理装置，其包括：获取模块，用于根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，第一配置信息包括：用于获取原始网络数据的来源信息；数据处理模块，用于根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。

优选地，上述网络数据的处理装置还包括：存储模块，用于根据第一配置信息中的存储信息将原始网络数据存储到数据库中，其中，存储信息包括：原始网络数据将要存储在数据库中的数据库表的预表名、数据库表的版本号、原始网络数据在数据库中存储时的名称、原始网络数据的存储类型。

优选地，数据处理模块包括：获取单元，用于根据第二配置信息中的数据获取方式获取原始网络数据，其中，数据获取方式包括：从数据库中获取原始网络数据、通过指定的第一配置信息来获取原始网络数据；数据处理单元，用于根据第二配置信息中的预设数据形式将原始网络数据处理为不同发布形式的网络数据文件。

根据本发明的又一方面，提供了一种网络数据的发布系统，其包括：网站根据上述任一种装置网站通过云服务器将不同形式的网络数据处理为不同发布形式的网络数据文件，并通过云服务器来发布网络数据文件，其中，云服务器使用的URL与网站的URL相关。

优选地，网络数据包括：网站从除网站之外的其他网站获得的网络数据。

在本发明中，通过预设的第一配置信息，该第一配置信息包括：用于获取原始网络数据的来源信息，并根据根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，然后，根据预设的第二配置信息将上述原始网络数据处理为不同发布形式的网络数据文件，实现可以对不同的网络API数据进行处理，并处理为不同形式的发布数据，避免在处理不同网络API数据时，编写相应的代码来完成数据的处理，从而在提高数据处理效率的同时，减少了代码编写人员的工作量。

附图说明

此处所说明的附图用来提供对本发明的进一步理解，构成本申请的一部分，本发明的示意性实施例及其说明用于解释本发明，并不构成对本发明的不当限定。在附图中：

图1是根据本发明实施例的网络数据的处理方法的流程图；

图2是根据本发明实施例的网络数据的处理装置的结构框图；

图3是根据本发明实施例的另一种网络数据的处理装置的结构框图；

图4是根据本发明实施例的网络数据的处理并发布的系统的功能示意图；

图5是根据本发明实施例的生产者配置文件的示意图；

图6是根据本发明实施例的生产者处理模块的处理流程的示意图；

图7是根据本发明实施例的消费者配置文件的示意图；

图8是根据本发明实施例的消费者处理模块的处理流程的示意图；

图9是根据本发明实施例的系统一的结构示意图；以及

图10是根据本发明实施例的系统二的结构示意图。

具体实施方式

下文中将参考附图并结合实施例来详细说明本发明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

本实施例提供了一种网络数据的处理方法，如图1所示，该网络数据的处理方法包括步骤S102至步骤S104。

步骤S102：根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，第一配置信息包括：用于获取原始网络数据的来源信息。

步骤S104：根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。

通过上述步骤，通过预设的第一配置信息，该第一配置信息包括：用于获取原始网络数据的来源信息，并根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，然后，根据预设的第二配置信息将上述原始网络数据处理为不同发布形式的网络数据文件，实现可以对不同的网络API数据进行处理，并处理为不同形式的发布数据，避免在处理不同网络API数据时，编写相应的代码来完成数据的处理，从而在提高数据处理效率的同时，减少了代码编写人员的工作量。

为了准确地获得原始网络数据，在本优选实施例中，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据包括：根据来源信息从不同形式的网络API获取待发布的原始网络数据，其中，来源信息包括：原始网络数据的格式、获取原始网络数据的统一资源定位符URL、访问URL的预设参数。即通过访问URL并输入相应的参数来获取原始网络数据，并对原始网络数据的格式进行解析。

为了提高获取原始网络数据的效率、准确性，在本优选实施例中，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据包括：根据上述来源信息中定义的路径信息通过XPATH方式获取上述原始网络数据。例如，该路径信息可以包括用XPATH指示的该原始网络数据在以XML格式表示的原始数据文件中的位置信息，供XPATH使用的命名空间和根路径。利用XPATH从原始数据文件获取上述原始网络数据的过程是：先通过根路径定义的XPATH把包含数据的多个节点提取出来，再对每个节点用每个表项的来源信息中位置信息的XPATH找到具体数据。组成这些XPATH语句需要用到命名空间。

为了对上述原始网络数据进行融合处理，在本优选实施例中，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据之后，根据第一配置信息中的存储信息将原始网络数据存储到数据库中，其中，存储信息包括：原始网络数据将要存储在数据库中的数据库表的预表名、上述数据库表的版本号、原始网络数据在数据库中存储时的名称、原始网络数据的存储类型。将获取的不同形式且拥有相同预表名的网络原始数据写入同一张数据表，做到数据的融合。

为了避免数据表中的读写冲突，在本优选实施例中，根据第一配置信息中的存储信息将原始网络数据存储到数据库中包括：预表名对应着至少两个数据库表，根据预表名从预表名与数据库表的真实表名的预设映射关系中确定出存储原始网络数据的数据库表的真实表名，其中，确定出的数据库表的真实表名为数据库表中未被映射的数据库表的真实表名；根据版本号和确定出的真实表名将原始网络数据文件存储到数据库中。即预表名并不是真实的表名，可以另外维护着一张映射表（相当于上述映射关系），该映射表以上述预表名为主键，记录了表的版本号和目前使用的真实表名，我们只需要用两张真实的表就可以达到目的了。例如：假设预表名为“Table1”，我们在其后加上“_A”、“_B”建立两张真实的表“Table1_A”、“Table1_B”。假设上次运行完成后，数据被存储在“Table1_A”，即目前使用的真实表名是“Table1_A”，即映射关系表中预表名“Table1”与“Table1_A”是对应映射的，则我们将这次运行得到的数据写入“Table1_B”，等到写入完成时，才将映射表中“Table1”项对应的目前使用的真实表名更换成“Table1_B”，而消费者处理模块取数据也是先查映射表，找到目前使用的真实表名再取数据，这样保证消费者处理模块永远都能取到准备好了的数据，圆满解决了等待写数据库而发生阻塞的问题，避免了读写冲突的问题。

为了满足不同应用场景的需求，在本优选实施例中，根据第一配置信息中的存储信息将原始网络数据存储到数据库中包括：在存储信息中的存储类型为时间类型的情况下，获取原始网络数据的原始时间格式；根据原始时间格式解析获得原始网络数据的时间；以预设时间格式将原始网络数据按照时间顺序存储到数据库中。例如，在实际使用中，经常需要将来自于不同来源的数据以时间顺序排序，这就要求统一它们的时间格式，所以在存储信息中，如果存储类型是时间，就要给出数据来源中的时间格式（例如：yyyy-MM-ddHH:mm），就可以根据这个格式解析数据的时间，并用统一的时间格式（例如：yyyy-MM-dd HH:mm:ss）以时间为顺序将数据存储到数据库中。

为了满足不同应用需求，在本实施例中，根据预设的第一配置信息从不同形式的网络API获取待发布的原始网络数据之后，在原始网络数据为二进制文件的情况下，根据获取原始网络数据的链接地址获取原始网络数据；将原始网络数据存储在本地文件系统中，并存储发布原始网络数据的新链接地址。即原始网络数据为二进制文件的情况下，最典型的例子是图片，原始数据文件给出的图片一般是URL链接字串，如果需要将二进制文件从原始数据源取来并通过上述方法对数据进行处理，就要在第一配置信息中给出指示以及获取数据的URL链接字串，在实施时就可以根据指示将二进制文件取回到本地文件系统，并生成指向处理后的数据文件地址的URL链接字串存储在第一配置信息中。为了节省流量，在取二进制文件时要支持HTTP304原因值的处理，这样就不会重复地取内容未改变的文件了。

为了提高本实施例的灵活性，在本优选实施例中，根据预设的第二配置信息将原始网络数据处理为不同发布形式的网络数据文件包括：根据第二配置信息中的数据获取方式获取原始网络数据，其中，数据获取方式包括：从数据库中获取原始网络数据、通过指定的第一配置信息来获取原始网络数据；根据第二配置信息中的预设数据形式将原始网络数据处理为不同发布形式的网络数据文件。即除了可以从数据库中获取上述原始网络数据之外，还可以指定一个第一配置信息，根据该指定的第一配置信息直接从原始数据文件中获得数据并填入新生成文件的相应位置。不经过数据库中转，这种方式的好处是省下了数据库的开销，但是缺点是不能利用数据库做较复杂的排序，只能按照数据在原始文件中的顺序排序，但是因为一般原始文件中的数据就已经是排了序的，所以新生成的文件仍然是有序的。

从数据库中获取原始网络数据可以通过以下步骤来实现，根据第二配置信息从数据库中获取原始网络数据包括：根据第二配置信息中的参数获取方式获取用于获得原始网络数据的参数信息，其中，参数获取方式包括以下之一：接收携带有参数信息的请求消息，查询存储原始网络数据时的预设映射关系获取原始网络数据的存储信息，并作为参数信息；根据参数信息生成SQL语句来从数据库中获取原始网络数据。

为了准确地从数据库中获取数据，在本优选实施例中，根据查询存储原始网络数据时的预设映射关系获取的参数信息来从数据库中获取原始网络数据包括：根据第二配置信息中的别名查询预设映射关系确定获取原始网络数据的数据库表的真实表名，其中，别名与存储原始网络数据时使用的预表名一致，在预设映射关系中与别名对应映射的数据库表的名称为获取原始网络数据的数据库表的真实表名；使用确定出的真实表名生成SQL语句来从数据库中获取原始网络数据。

还可以根据第二配置信息从指定的第一配置信息来获取原始网络数据，例，根据参数信息从指定的第一配置信息中确定原始网络数据的来源信息；根据来源信息从不同形式的网络API获取原始网络数据。

为满足不同的应用场景，上述预设数据形式包括以下之一：XML形式、JSON形式、HTML形式。可以将上述原始网络数据处理为上述形式的数据文件。

为了实时地根据最新的配置信息来处理网络数据，在本优选实施例中，间隔预设时间周期根据第一配置信息从不同形式的网络API获取原始网络数据，并根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。

为了降低对提供数据的网站的访问量，本优选实施例提供了一种网络数据的发布方法，该网络数据的发布方法包括：根据上述网络数据的处理方法网站的云服务器对不同形式的原始网络数据处理为不同发布形式的网络数据文件，并通过所述云服务器来发布所述网络数据文件，其中，所述云服务器使用的URL与所述网站的URL相关。

通过上述步骤，网站通过云服务器对不同形式的原始网络数据进行处理，生成不同发布形式的网络数据文件，并通过云服务器来发布网络数据文件，使得客户端通过访问云服务器来获得发布数据，大大地避免了客户端对网站的访问，以降低网站的并行访问压力，同时，可以实现网站的数据和代码都存放在自身上，提高了网站自身的数据和代码的安全性和保密性。例如，数据提供者的服务器提供的原始数据位置为URL1（不向用户公开），处理后的数据文件的位置为URL2（向用户公开），用户只知道并访问URL2，可见URL1几乎没有访问压力。所有的访问压力都在URL2上，因此，普通网站建设者只需要搭建一个普通性能的服务器，然后购买一家云计算服务，上传这两个配置文件，并告诉用户访问URL2即可。其代码和数据都存放在网站建设者自己的服务器中，保密性很好，而且，一旦购买的云计算服务出现问题，可以很快的换另一家云计算服务，不影响URL2的访问。

在上述系统的使用场景中，对于大网站来说，通过可以视为一种云计算服务的提供方式，可以在保证网站自身的数据和代码的安全性和保密性的前提下，通过购买第三方云计算服务达到网站的快速扩容。在这种情况下，复杂计算和数据生成发生在己方服务器，通过动态DNS负载均衡技术和第三方云服务器建立起CDN（内容分发网络）。对于普通网站而言，在可以在保证网站自身的数据和代码的安全性和保密性的前提下，降低了提供网络API的难度。

为了提高本优选实施例的灵活性，在本优选实施例中，上述网络数据包括：网站从除该网站之外的其他网站获得的网络数据。

本优选实施例提供了一种网络数据的处理装置，如图2所示，该网络数据的处理装置包括：获取模块202，用于根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，第一配置信息包括：用于获取原始网络数据的来源信息；数据处理模块204，连接至获取模块202，用于根据第二配置信息将原始网络数据处理为不同发布形式的网络数据文件。

为了对上述原始网络数据进行融合处理，在本优选实施例中，如图3所示，上述网络数据的处理装置还包括：存储模块206，用于根据第一配置信息中的存储信息将原始网络数据存储到数据库中，其中，存储信息包括：原始网络数据将要存储在数据库中的数据库表的预表名、上述数据库表的版本号、原始网络数据在数据库中存储时的名称、原始网络数据的存储类型。

为了提高本实施例的灵活性，在本优选实施例中，上述数据处理模块204包括：获取单元，用于根据第二配置信息中的数据获取方式获取原始网络数据，其中，数据获取方式包括：从数据库中获取原始网络数据、通过指定的第一配置信息来获取原始网络数据；数据处理单元，用于根据第二配置信息中的预设数据形式将原始网络数据处理为不同发布形式的网络数据文件。

为了降低对提供数据的网站的访问量，本优选实施例提供了一种网络数据的发布系统，网站通过云服务器将不同形式的网络数据处理为不同发布形式的网络数据文件，并通过云服务器来发布网络数据文件，其中，云服务器使用的URL与网站的URL相关。

为了提高本优选实施例的灵活性，在本优选实施例中，上述网络数据包括：网站从除该网站之外的其他网站获得的网络数据。

以下结合附图对上述各个优选实施例进行详细地描述。

在以下实施例，上述第一配置信息以“数据生产者”配置文件为例，上述第二配置信息以“数据消费者”配置文件为例，来详细地描述上述各个优选实施例。

以下提供一种使用配置文件自动的对来自于不同来源的多种格式的网络数据进行融合、再处理，生成可用多种格式呈现的新文件的方法，以及利用该方法实现的两个系统。

定义一个“数据生产者”配置文件，这个配置文件是用于将原始数据取回并存储在数据库中。在其中要说明数据来源的格式、URL和应传入参数；以及要存入的数据库的表名、表项名、表项存储类型、默认值（以及其他必要参数），并说明表项内容的值应该在原始数据文件中哪个位置获得。特别重要的，“数据生产者”可以说明多个数据来源，将它们不同格式不同名字但具有相同意义的数据归一到同一个数据表的同一个表项下，这就做到了数据的融合。

定义一个“数据消费者”配置文件。这个配置文件用于从数据库中取出之前由“数据生产者”存入的原始数据，并按配置文件指定的顺序进行排序，然后生成新的格式的文件。在其中要说明查询数据库的SQL语句，以及语句中应该替换的参数（如表名、排序参数等）。还要说明新生成文件的格式和应将数据填入新生成文件的哪个位置。“数据消费者”完成了数据的再处理。

“数据消费者”配置文件中说明的取数据的方式除了从数据库取之外，还有另一种方式，就是指定一个“数据生产者”配置文件，直接从原始数据文件中获得数据并填入新生成文件的相应位置。不经过数据库中转。这种方式的好处是省下了数据库的开销，但是缺点是不能利用数据库做较复杂的排序，只能按照数据在原始文件中的顺序排序，但是因为一般原始文件中的数据就已经是排了序的，所以新生成的文件仍然是有序的。

基于上述方案实现如下两个系统：

系统一：

将上述两个配置文件写好后，存储在并行访问能力强大的云服务器上，定时运行，生成新文件放在云服务器上供用户访问。我们说数据提供者的服务器提供的原始数据位置为URL1（不向用户公开），新文件的位置为URL2（向用户公开），用户只知道并访问URL2，可见URL1几乎没有访问压力。所有的压力都在URL2上。普通网站建设者只需要搭建一个普通性能的服务器，然后购买一家云计算服务，上传这两个配置文件，并告诉用户访问URL2即可。其代码和数据都存放在网站建设者自己的服务器中，保密性很好，而且，一旦购买的云计算服务出现问题，可以很快的换另一家云计算服务，不影响URL2的访问。

系统一可视为一种云计算服务的提供方式，它不仅对普通网站建设者是有用的，同样对于大型网站也是有用的：因为它可以在保证己方数据和代码不外泄的情况下，通过购买第三方云计算服务达到网站的快速扩容。在这种情况下，复杂计算和数据生成发生在己方服务器，通过动态DNS负载均衡技术和第三方云服务器建立起CDN（内容分发网络）。

系统二：

同样的，第三方程序员也可以利用上述两个配置文件来自动处理数据。他们可以把能处理上述配置文件的模块链接进程序中，之后就可以只修改配置文件而不用重写代码来获得融合后再处理的网络数据，能大大提升工作效率。

图4是根据本发明实施例的网络数据的处理并发布的系统的功能示意图，如图4所示，101是多来源多格式的原始数据源；102是生产者处理模块；103是生产者配置文件；104是数据库；105是文件系统；106是消费者处理模块；107是消费者配置文件；108代表多种输出格式的新文件；109是系统一中的云服务器；110是系统一的最终用户；111是系统二中的第三方应用。

通过上述系统可以实现以下的数据处理并发布的过程：102先读入103，然后按照该配置文件从101读入原始数据，存入到由104和105组成的中间存储模块中。106读入107，按照该配置文件从102、104、105读入融合后的数据，再处理成108。最终，利用109将108发布给110（系统一）；或者将108提供给111（系统二）。

图5是根据本发明实施例的生产者配置文件的示意图，如图5所示，生产者配置文件是由1个或多个表定义组成的，每个表定义由表名、版本号、来源和表项组组成。

表名是数据应该存入的数据库表的名字（相当于上述存储信息）。

版本号是该数据库表目前的版本号（相当于上述存储信息）。

来源（相当于上述来源信息）用于说明原始数据源，包括：格式、访问用URL和参数。有了这三项信息就可以获取原始数据。本发明能够解析的原始数据格式有XML（包含HTML格式，下同）、JSON、SOAP、RSS四种。其中通过XML、SOAP、RSS获得的原始数据文件本身就是XML格式的，本发明把JSON格式也转化成XML格式。这样原始数据文件就全部统一成XML格式的了（这样就可以利用XPATH进行查找了）。

表项组说明数据库表中有哪些表项。每一项表项要说明名称（相当于上述存储信息）、存储类型（相当于上述存储信息）、来源（相当于上述路径信息）和默认值（以及其他必要参数）。这其中，表项中的来源是用XPATH指示的该表项数据在以XML格式表示的原始数据文件中的位置。为此，表项组中还定义了供XPATH使用的命名空间和根路径。

利用XPATH从原始数据文件取表项数据的过程是：先通过根路径定义的XPATH把包含数据的多个节点提取出来，再对每个节点用每个表项的来源定义的XPATH找到具体数据。组成这些XPATH语句需要用到命名空间。

在讲述生产者处理模块（相当于上述获取模块202）的具体处理流程前，需要说明与该流程相关的几个概念：

1）生产者处理模块定时运行，每次运行时都读取生产者配置文件，这样一旦修改了生产者配置文件，下次运行时会使用新的配置文件工作；

2）双缓冲机制：将原始数据写入数据库需要一定时间t，为了保证在时间t内消费者处理模块仍能正常工作而不会因为等待生产者写数据库而发生驻塞，生产者处理模块使用了一种双缓冲机制，即表定义中的表名并不是真实的表名，它另外维护着一张映射表，该映射表以表定义中的表名为主键，记录了表的版本号和目前使用的真实表名，我们只需要用两张真实的表就可以达到目的了。例如：假设表定义中的表名为“Table1”，我们在其后加上“_A”、“_B”建立两张真实的表“Table1_A”、“Table1_B”。假设上次运行完成后，数据被存储在“Table1_A”，即目前使用的真实表名是“Table1_A”，则我们将这次运行得到的数据写入“Table1_B”，等到写入完成时，才将映射表中“Table1”项对应的目前使用的真实表名更换成“Table1_B”，而消费者处理模块取数据也是先查映射表，找到目前使用的真实表名再取数据，这样保证消费者处理模块永远都能取到准备好了的数据，圆满解决了等待写数据库而发生驻塞的问题；

3）表的自动重建：数据表在生产者处理模块的第一次运行时就自动建好了，一般不需要重新建表。但是，因为表是根据配置文件中的表项组来建立的，如果表项组中的每一项表项的名称和存储类型不变，就不需要重建表；如果一旦发生变化了，就需要通知生产者处理模块重建数据表。这是利用版本号来实现的，比较从映射表读出的版本号和配置文件中的版本号，如果不一致，就重建表；

4）取SOAP数据：获取XML、JSON、RSS数据都是用URL带上参数即可获得，只有SOAP特殊，它是用HTTP POST方法带上特定的内容发送到服务器端去获取数据，因此对于SOAP格式的数据来源，需要在来源中定义SOAP的POST请求应带上的内容soapbody和属性值SOAPAction；

5）把JSON格式获得的原始数据文件也转化成XML格式：本发明能够解析的原始数据格式有XML、JSON、SOAP、RSS四种。其中通过XML、SOAP、RSS获得的原始数据文件本身就是XML格式的，本发明把JSON格式也转化成XML格式。这样获得的原始数据文件格式就都是XML的了。为了之后XPATH语句的书写，必须强制规定从JSON转化成的XML文件的根节点名、数组名、元素名、对象名，例如：规定根节点名为ztejson2xml，数组名为array，元素名为elem，对象名为object；

6）时间格式归一化：在实际使用中，经常需要把来自于不同来源的数据以时间顺序排序，这就要求统一它们的时间格式，所以在表项组的表项说明中，如果该表项类型是时间，就要给出数据来源中的时间格式（例如：yyyy-MM-dd HH:mm）。生产者处理模块会根据这个格式解析数据为时间，用内部统一的时间格式（例如：yyyy-MM-ddHH:mm:ss）存储进数据库；

7）用URL代表的二进制文件的存取：最典型的例子是图片，原始数据文件给出的图片一般是URL链接字串，如果需要将二进制文件从原始数据源取来通过本发明再发布，就要在表项说明中给出指示，生产者处理模块会根据指示将二进制文件取回到本地文件系统，生成指向新文件地址的URL链接字串作为表项值存储进对应的表项。为了节省流量，在取二进制文件时要支持HTTP304原因值的处理，这样就不会重复地取内容未改变的文件了。

图6是根据本发明实施例的生产者处理模块的处理流程的示意图，如图6所示：该处理流程包括如下步骤：

步骤S301：读取生产者配置文件；

步骤S302：根据表定义N，检查是否需要创建或重建数据表；

步骤S303：从映射表中获取本次操作可以写入的（即双缓冲中未使用）的真实表名A；

步骤S304：读取原始数据源并解析数据；

步骤S305：将解析后的数据写入表A。但是要注意，在本次运行的第一次写入时要清空A里原来的旧内容，但是之后的写入就不清空了，这样做就能将从多个拥有相同表名的表定义获取的解析后的数据写入同一张数据表，做到数据的融合；

步骤S306：检查是否还有未处理完的表定义，如果有，转到步骤S302继续处理；如果没有，说明数据更新工作已经全部完成，转到步骤S307；

步骤S307：更新映射表中目前正在使用的真实表名为A。这样消费者处理模块就会从A中获取融合后的新数据了。

图7是根据本发明实施例的消费者配置文件的示意图，如图7所示，消费者配置文件是由数据来源（相当于上述数据获取方式），参数表（相当于上述参数信息）和输出说明组成。

数据来源有两种：一种是SQL语句（使用数据库）；另一种是生产者配置文件（不使用数据库直接取原始数据）。但是注意，无论是SQL语句还是生产者配置文件都必须配合参数表使用，因为其中的参数变量是由参数表确定的。

参数表是由很多个参数项组成的，每个参数项要说明参数值名称、来源、别名和默认值（其中默认值可省略）。参数值来源有两种，一种是来自于用户的请求消息（REQ），例如HTTPGET请求的URL中所带参数；另一种是来自于前述的数据库映射表，例如表名，实际上该表是不存在的，为了组成可以执行的SQL语句，只要指出其来源是数据库，消费者处理模块就会自动将这个表名去查映射表，获得SQL语句真正需要查询的真实表名组成完整的SQL语句。

注意：

1）在数据来源的SQL语句和生产者配置文件中，使用参数项的别名来占位（即：说明该处参数值需要根据参数表来替换）；

2）如果该参数项在指定的参数值来源中找不到，就使用默认值。否则必须使用所找到的值。

输出说明由输出文件类型和输出项组成。输出文件类型有但不限于XML，JSON，HTML三种（这是三种最常用类型，但是可以根据需要使用其他格式输出）。输出项由名称、别名和默认值组成（可以没有默认值），名称对应着生产者配置文件表项组中那些表项的名称，别名是用于输出文件中的名称。（为什么要在这里将名称做转化呢？这是为了缩短名称，以便缩小输出文件的大小，如果不愿意改名，将表项名和别名写成一致即可）。

特别的，对于输出文件类型为HTML的情况，还要定义html_header，html_body和html_footer。下面是一个例子：

html_body中使用了输出项的别名an_title，an_description，an_newsLink，an_time。生成HTML时将根据查询出来的记录的多少，循环生成html_body。将真实值填入别名的位置。比如说记录有10条，html_body会被复制10次，每次填入不同的记录值，因此html_body中一般是定义<tr>表项。

因为上述生成的HTML文件格式较简单，表现形式不丰富，所以主要作为frame内嵌进主要网页中。

另外，在上述例子中，html_footer使用了约定好的变量zte_crc，zte_total_page和zte_current_page。为什么要有这3个变量呢，是因为有可能查询出来的记录非常多，比如说有100条，而我们希望每次生成的HTML只含10条记录，并且可以翻页，而且可以自检在翻页过程中整个数据集是否有变化。所以我们加入了这3个变量。与之配套的在HTTP GET请求中也约定了对应的指示翻页的参数：num（每页返回的最大记录条数），page（指定要看第几页），mark（对100条记录做的32位CRC校验码）。为节省HTTP GET请求的URL长度，将上述3个参数缩写为n，p，m。每当消费者处理模块收到来自用户的HTTP GET请求时，会将本次查询出的记录集作为一个整体做32位CRC校验，比较校验码和请求中的参数m是否一致。如果一致，说明从上次用户获得数据到本次查询这段时间内原始数据未发生改变，于是按照n和p的指示，生成第p页最多载有n条记录的新文件（并带有对应CRC码）返回给用户（注意最后一页的记录有可能不足n条，如果P大于总页数，则生成最大页数对应的新文件）；否则，说明原始数据发生了改变，生成第1页最多载有n条记录的新文件（并带有对应CRC码）返回给用户，用户可以根据CRC码判断是否数据发生了改变。

对于XML，JSON这两种格式来说：CRC校验码、总页数和当前页数可以嵌在文件中返给用户，名称分别固定为crc，total和page；

对于HTML格式来说：我们定义了固定的别名zte_crc，zte_total_page和zte_current_page供HTML文件生成时做替换。

上述例子中还有一个时间的例子：

<column name="time"date_format="yyyy-MM-dd HH:mm"anothername="an_time"/>

这是将之前在生产者处理模块运行时归一化的时间按照新的指定格式"yyyy-MM-ddHH:mm"输出写入到新文件中。

对于存储在本地文件系统的二进制文件，因为生产者处理模块在存入时就已经转换成新的URL链接地址，所以在消费者配置文件中没有特殊处理。

与生产者处理模块类似，消费者处理模块每次运行时都要读取消费者配置文件，这样一旦修改了消费者配置文件，下次运行时会使用新的配置文件工作。

图8是根据本发明实施例的消费者处理模块的处理流程的示意图，如图8所示：该处理流程包括如下步骤：

步骤S501：读取消费者配置文件；

步骤S502：解析参数表，从指定来源获得每个参数项的值，如果没有值，使用配置文件中的默认值；

步骤S503：从HTTP Get请求中获得n,p,m参数（注意：Get请求的参数中可以没有这些参数）；如果数据来源是数据库，转到步骤S504，如果数据来源是另一份生产者配置文件，转到步骤S505；

步骤S504：用参数的实际值替换掉SQL中由参数别名所占据的位置，生成可执行的SQL语句，执行之，获得结果集，转向步骤S506；

步骤S505：用参数的实际值替换掉生产者配置文件中的来源说明中由参数别名所占据的位置，执行生产者处理程序，不经过数据库直接获得结果集，转向步骤S506；

步骤S506：对结果集做32位CRC校验；

步骤S507：判断HTTP Get请求中是否有n,p,m全部参数。如果缺少n,m,p参数中的某一个，转向步骤S506，否则转向步骤S509；

步骤S508：准备好生成含全部记录的新文件（并带有对应CRC码）的数据集，转向步骤S511；

步骤S509：比较S506所计算出的CRC值与m参数所带CRC值是否一致，如果一致，转向步骤S510，否则转向步骤S511；

步骤S510：准备好按照n和p的指示，生成第p页最多载有n条记录的新文件（并带有对应CRC码）的数据集，如果P大于总页数，则准备好生成最大页数对应的新文件的数据集，转向步骤S511；

步骤S511：准备好生成第1页最多载有n条记录的新文件（并带有对应CRC码）的数据集；

步骤S512：按指示生成XML、JSON、HTML等多种格式新文件。

图9是根据本发明实施例的系统一的结构示意图，如图9所示：该系统包括：610是普通服务器，掌握在作为数据提供者的普通网站建设者手中；611是用于生成612数据的代码，它被保存在610中，保密性很好；612是普通服务器生成并以URL1地址进行发布的数据，URL1保密；613是本发明定义的配置文件；620是云服务器，它具有支撑几十万次/分钟并发访问的能力，在这个系统中作为“倍增器”；621是前述的本发明定义的融合再处理模块，它能阅读配置文件并自动对多来源多格式的网络数据进行融合、再处理生成多种格式新文件；622是配置文件库，由610将配置文件613上传到这里，621从这里取相应的配置文件，然后根据配置文件从URL1读取612数据；623是数据库和文件系统，在621的运行中需要用到它们作中间存储；624是云服务器的发布模块，由它将621生成的新文件通过地址URL2发布给最终用户（注意：URL2是与610所申请的域名相关的地址，该域名被610设置指向620的IP地址）；630是最终用户，通过访问URL2获得由610生成的数据。

在这个系统一中，610受到的访问压力极小，并且611代码和612数据都存放在610自己这里，安全性较高；而620不需要为融合再处理610的数据做特别的事情，更容易作为一项资源对610进行出租，这就是云计算出租计算能力的本意；当某个620提供的云服务出现问题时，610可以立即换另一家620为自己做“倍增器”（更改路由器中URL2域名对应的IP地址），不影响最终用户的访问。当610出现问题时，按照前述处理流程，620能保留从610获得的最后一批数据供用户访问（数据在双缓冲正在使用的那张表中），这样就给610提供了解决问题的时间，也不影响最终用户的访问。特别的，610提供的数据还可以不在610上，而是通过配置文件让620从其他多个数据源获取数据融合再处理提供给最终用户（例如，融合从多个新闻数据源获得的数据再处理提供给最终用户）。

图10是根据本发明实施例的系统二的结构示意图，如图10所示：该系统包括：710是应用程序；711是本发明所述的融合再处理模块；712是组成应用程序的其他模块；720是应用程序所在操作系统的文件系统；721是本发明定义的配置文件；730是提供给应用程序数据的服务器（730代表提供给应用程序数据的多来源多格式的多个服务器）；在这个系统二中，对再处理模块的输入不再是URL的参数（因为根本不是用户访问URL触发的），而是直接给出参数（例如，向再处理模块传入装有参数的哈希表），再处理模块的输出也可以不是文件，而是放在内存中比较好处理的数据结构（例如，输出XML DOM树）。

系统二的优点是：

1、在编写应用程序时，程序员可以只修改配置文件而不用重写代码来获得融合后再处理的网络数据，能大大提升工作效率；

2、在应用程序发布后，可以依靠升级配置文件而不是下载新的版本来方便的为用户提供新的功能（例如：一个向用户提供新闻的应用程序，可以自动升级配置文件，为用户增加新的数据来源或删除已不存在的数据来源，而不让用户下载新的版本。这种做法比起之前用配置文件单纯记录URL地址来更新数据来源的做法更好。表现在：无论新的数据来源是何种格式，都不需要改变代码，而之前的做法需要保证新的数据来源的数据格式定义和参数定义与旧的数据来源一致）。

实例

以下是一个实现了本发明的实例中的使用的配置文件、用户访问所使用的URL的具体例子。该实例利用本发明为某项目编写了一个自动化服务器框架，使用这个自动化服务器框架编写网络应用的效率极高，编写过程中不需要写代码，仅需配置文件即可。一个新应用大约能在半小时内完成。该实例使用的服务器软件是Tomcat，使用的数据库软件是Oracle：

生产者配置文件

在这个例子中，为了展示本发明对“多来源多格式”的原始数据来源的融合能力，于是在同一个生产者配置文件中给出了多个表定义，分别使用了SOAP，RSS，JSON，XML四种格式从原始数据源获取数据。

其中有几个地方是专门给出的例子，提醒注意：

SinaNews这张数据表中的数据是由两处原始数据来源得到并融合的，展示了本发明的融合能力；

SOAPAction属性是有一定规则可以自行生成的（可由soapbody的namespace-uri与其属性名组合而成），所以在SOAP来源的配置中省略了SOAPAction的定义（注释掉的部分），如果有特殊的对SOAPAction的定义，可以把它显式配置出来供处理模块使用；

两个SinaNews表定义使用了同一个表项组定义。后出现的一个表定义用该表项组的别名news_from_sina_rss进行引用；

利用XPATH从原始数据文件取数据的过程是：先通过rootpath（根路径）定义的XPATH把包含数据的多个节点提取出来，再对每个节点用每个column的source属性定义的XPATH找到具体数据。

消费者配置文件

生成XML格式新文件示例

在这个例子中举了两个可用的SQL语句的例子，从中：

可以看到参数表中的参数与SQL语句进行替换的过程：以被注释掉的“SELECT*FROMan_SinaNewsTest WHERE id='an_id′AND city='an_city′”为例，假设映射表记录的双缓冲中目前正在使用的表名是SinaNewsTest_A，通过用户请求的URL参数传来的id号是12345，没有传city参数，默认为chengdu。则替换后的真实SQL语句是“SELECT*FROM SinaNewsTest_AWHERE id='12345'AND city='chengdu'”；

zte_insert_id是本实例定义的按照记录插入表时的顺序赋值的id号，便于按照插入顺序排序。

生成HTML格式新文件示例

以上是生成HTML格式新文件的消费者配置文件的例子，对于它已经在前文中有详细讲述，这里就不赘述了。

利用数据库排序的例子

生产者配置文件

这个生产者配置文件将取得的新闻的内容存储进YicaiNews表中，注意：

<column name="publisht"type="DATE"date_format="yyyy年MM月dd日HH:mm:ss"source="ns1:publisht"/>，这是在说明从原始数据源读取的时间的解析格式；

<column name="cid"type="CHAR(30)"value="12170"/>，说明cid的值并不是从原始数据文件中读取的，而是直接写成12170。

消费者配置文件

这个消费者配置文件是从YicaiNews表中读取数据，生成JSON格式的新文件。

不经过数据库，直接获取网络数据的例子

消费者配置文件

这个消费者配置文件说明的数据来源是一个指定的生产者配置文件yicai_news_detail_productor.xml，就放在与本文件相同的文件夹下。

上述消费者配置文件中指定的生产者配置文件

这个在消费者配置文件中指定的生产者配置文件与一般的生产者配置文件的区别在于：

它用于访问原始数据源的参数定义是来自于消费者配置文件的。

其中an_cid和an_id来自于：

用户访问所使用的URL的例子

同一来源自动生成XML、JSON、HTML三种格式的例子：

XML格式：http://127.0.0.1:8080/sinanews

JSON格式：http://127.0.0.1:8080/sinanews/json

HTML格式：http://127.0.0.1:8080/sinanews/html

分页例子

如需分页，用n指代每页应有n条记录，用p指代第p页。

例子：http://127.0.0.1:8080/news?n=10&p=1

说明：每页应有10条记录，返回第1页。

分页并且自检的例子

如果带上m参数，服务器会自检，如有更新，则返回新的记录列表的第1页信息。m是上次获取记录列表时同时获得的对应的mark值。

例子：http://127.0.0.1:8080/news?n=10&p=2&m=2448204741

在本例子中，如果在获取第2页新闻时，服务器端存储的记录列表已经更新了，则会返回最新的记录列表的第1页，而不是要求的第2页。

显然，本领域的技术人员应该明白，上述的本发明的各模块或各步骤可以用通用的计算装置来实现，它们可以集中在单个的计算装置上，或者分布在多个计算装置所组成的网络上，可选地，它们可以用计算装置可执行的程序代码来实现，从而，可以将它们存储在存储装置中由计算装置来执行，并且在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤，或者将它们分别制作成各个集成电路模块，或者将它们中的多个模块或步骤制作成单个集成电路模块来实现。这样，本发明不限制于任何特定的硬件和软件结合。

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

Claims (20)

1.一种网络数据的处理方法，其特征在于，包括：

根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，所述第一配置信息包括：用于获取所述原始网络数据的来源信息；

根据第二配置信息将所述原始网络数据处理为不同发布形式的网络数据文件。

2.根据权利要求1所述的方法，其特征在于，根据第一配置信息从不同形式的网络API获取待发布的原始网络数据包括：

根据所述来源信息从不同形式的网络API获取待发布的所述原始网络数据，其中，所述来源信息包括：所述原始网络数据的格式、获取所述原始网络数据的统一资源定位符URL、访问所述URL的预设参数。

3.根据权利要求1所述的方法，其特征在于，根据第一配置信息从不同形式的网络API获取待发布的所述原始网络数据包括：

根据所述来源信息中定义的路径信息通过XML路径语言XPATH方式获取所述原始网络数据。

4.根据权利要求1至3中任一项所述的方法，其特征在于，根据所述第一配置信息从不同形式的网络API获取待发布的原始网络数据之后，还包括：

根据所述第一配置信息中的存储信息将所述原始网络数据存储到数据库中，其中，所述存储信息包括：所述原始网络数据将要存储在所述数据库中的数据库表的预表名、所述数据库表的版本号、所述原始网络数据在所述数据库中存储时的名称、所述原始网络数据的存储类型。

5.根据权利要求4所述的方法，其特征在于，根据所述第一配置信息中的存储信息将所述原始网络数据存储到所述数据库中包括：

所述预表名对应着至少两个所述数据库表，根据所述预表名从所述预表名与所述数据库表的真实表名的预设映射关系中确定出存储所述原始网络数据的数据库表的真实表名，其中，确定出的数据库表的真实表名为所述数据库表中未被映射的数据库表的真实表名；

根据所述版本号和确定出的真实表名将所述原始网络数据文件存储到数据库中。

6.根据权利要求4所述的方法，其特征在于，根据所述第一配置信息中的存储信息将所述原始网络数据存储到数据库中包括：

在所述存储信息中的存储类型为时间类型的情况下，获取所述原始网络数据的原始时间格式；

根据所述原始时间格式解析获得所述原始网络数据的时间；

以预设时间格式将所述原始网络数据按照时间顺序存储到数据库中。

7.根据权利要求1至3中任一项所述的方法，其特征在于，根据预设的第一配置信息从不同形式的网络API获取待发布的原始网络数据之后，还包括：

在所述原始网络数据为二进制文件的情况下，根据获取所述原始网络数据的链接地址获取所述原始网络数据；

将所述原始网络数据存储在本地文件系统中，并存储发布所述原始网络数据的新链接地址。

8.根据权利要求4所述的方法，其特征在于，根据预设的第二配置信息将所述原始网络数据处理为不同发布形式的网络数据文件包括：

根据所述第二配置信息中的数据获取方式获取所述原始网络数据，其中，所述数据获取方式包括：从所述数据库中获取所述原始网络数据、通过指定的第一配置信息来获取所述原始网络数据；

根据所述第二配置信息中的预设数据形式将所述原始网络数据处理为不同发布形式的网络数据文件。

9.根据权利要求8所述的方法，其特征在于，根据所述第二配置信息从所述数据库中获取所述原始网络数据包括：

根据所述第二配置信息中的参数获取方式获取用于获得所述原始网络数据的参数信息，其中，所述参数获取方式包括以下之一：接收携带有所述参数信息的请求消息，查询存储所述原始网络数据时的预设映射关系获取所述原始网络数据的存储信息，并作为所述参数信息；

根据所述参数信息生成结构查询语言SQL语句来从所述数据库中获取所述原始网络数据。

10.根据权利要求9所述的方法，其特征在于，根据查询存储所述原始网络数据时的预设映射关系获取的参数信息来从所述数据库中获取所述原始网络数据包括：

根据所述第二配置信息中的别名查询所述预设映射关系确定获取所述原始网络数据的数据库表的真实表名，其中，所述别名与存储所述原始网络数据时使用的预表名一致，在所述预设映射关系中与所述别名对应映射的数据库表的名称为获取所述原始网络数据的数据库表的真实表名；

使用确定出的真实表名生成SQL语句来从所述数据库中获取所述原始网络数据。

11.根据权利要求9所述的方法，其特征在于，根据所述第二配置信息从指定的第一配置信息来获取所述原始网络数据包括：

根据所述参数信息从所述指定的第一配置信息中确定所述原始网络数据的来源信息；

根据所述来源信息从不同形式的网络API获取所述原始网络数据。

12.根据权利要求8所述的方法，其特征在于，预设数据形式包括以下之一：可扩展标记语言XML形式、轻量级数据交换语言JSON形式、超文件标记语言HTML形式。

13.根据权利要求1至3中任一项所述的方法，其特征在于，间隔预设时间周期根据所述第一配置信息从不同形式的网络API获取所述原始网络数据，并根据所述第二配置信息将所述原始网络数据处理为不同发布形式的网络数据文件。

14.一种网络数据的发布方法，其特征在于，根据权利要求1至13中任一项所述的方法网站的云服务器对不同形式的原始网络数据处理为不同发布形式的网络数据文件，并通过所述云服务器来发布所述网络数据文件，其中，所述云服务器使用的URL与所述网站的URL相关。

15.根据权利要求14所述的方法，其特征在于，所述网络数据包括：所述网站从除所述网站之外的其他网站获得的网络数据。

16.一种网络数据的处理装置，其特征在于，包括：

获取模块，用于根据第一配置信息从不同形式的网络应用程序接口API获取待发布的原始网络数据，其中，所述第一配置信息包括：用于获取所述原始网络数据的来源信息；

数据处理模块，用于根据第二配置信息将所述原始网络数据处理为不同发布形式的网络数据文件。

17.根据权利要求16所述的装置，其特征在于，还包括：

存储模块，用于根据所述第一配置信息中的存储信息将所述原始网络数据存储到数据库中，其中，所述存储信息包括：所述原始网络数据将要存储在所述数据库中的数据库表的预表名、所述数据库表的版本号、所述原始网络数据在所述数据库中存储时的名称、所述原始网络数据的存储类型。

18.根据权利要求16或17所述的装置，其特征在于，所述数据处理模块包括：

获取单元，用于根据所述第二配置信息中的数据获取方式获取所述原始网络数据，其中，所述数据获取方式包括：从所述数据库中获取所述原始网络数据、通过指定的第一配置信息来获取所述原始网络数据；

数据处理单元，用于根据所述第二配置信息中的预设数据形式将所述原始网络数据处理为不同发布形式的网络数据文件。

19.一种网络数据的发布系统，其特征在于，网站根据权利要求16至18中任一项所述的装置网站通过云服务器将不同形式的网络数据处理为不同发布形式的网络数据文件，并通过所述云服务器来发布所述网络数据文件，其中，所述云服务器使用的URL与所述网站的URL相关。

20.根据权利要求19所述的系统，其特征在于，所述网络数据包括：所述网站从除所述网站之外的其他网站获得的网络数据。

Images