从中间件请求数据的方法、系统及中间件客户端

摘要

本申请公开了一种从中间件请求数据的方法、系统及中间件客户端，其中该方法包括：获取与待加载网页相关的特征信息，并根据特征信息确定待加载网页所对应的待请求数据名称集合，其中待请求数据名称集合包括至少一个中间件对应的待请求数据名称；接收中间件数据请求，并根据中间件数据请求确定目标中间件；根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称；以及根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存，其中如果再次接收到向目标中间件发送的中间件数据请求则从缓存的中间件数据集合中提取并反馈对应的中间件数据。该方法解决了请求合并所带来的问题。

说明书

技术领域

本申请涉及互联网技术领域，尤其涉及一种从中间件请求数据的方法、系统及中间件客户端。

背景技术

随着互联网技术的快速发展，互联网网站已经逐渐形成规模化，当网站系统的规模大到一定程度后，系统就会趋于服务化，所以在大规模的网站系统中，一个网页往往需要多次请求多个中间件才能完成渲染。

相关技术中，当一个网页多次请求同一个中间件时，通常是通过中间件提供一个批量接口，请求方通过该批量接口进行请求合并。虽然批量接口能够解决多次调用的问题，但是，当将请求合并与请求方的业务代码耦合在一起时，会带来以下问题：(1)当需要增加一个新调用，或者删除一个不用的调用时，请求方必须改动请求合并的代码；(2)调用方需要在所有有合并需求的地方写上合并调用的逻辑；(3)在分层式的架构中，不同层的调用合并也会给调用结果的传递带来困难。

发明内容

本申请的目的旨在至少在一定程度上解决相关技术中的技术问题之一。

为此，本申请的第一个目的在于提出一种从中间件请求数据的方法。该方法通过中间件客户端的自学习来完成请求合并，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

本申请的第二个目的在于提出一种从中间件请求数据的系统。

本申请的第三个目的在于提出一种中间件客户端。

为了达到上述目的，本申请第一方面实施例的从中间件请求数据的方法，包括：获取与待加载网页相关的特征信息，并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合，其中，所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称；接收中间件数据请求，并根据所述中间件数据请求确定目标中间件；根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称；以及根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存，其中，如果再次接收到向所述目标中间件发送的中间件数据请求则从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据。

本申请实施例的从中间件请求数据的方法，在一次网页加载请求过后，中间件客户端将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

为了达到上述目的，本申请第二方面实施例的从中间件请求数据的系统，包括用户客户端、网页服务器、中间件客户端和至少一个中间件，其中，所述用户客户端，用于向所述网页服务器发送网页加载请求并接收所述网页服务器反馈的网页数据；所述网页服务器，用于根据所述网页加载请求构建待加载网页，并向所述中间件客户端发送中间件数据请求以从所述至少一个中间件获取中间件数据，以及将获取的中间件数据反馈至所述用户客户端；所述中间件客户端，用于获取与所述待加载网页相关的特征信息，并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合，以及根据中间件数据请求确定目标中间件，并根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称，以及根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存，并再次接收到向所述目标中间件发送的中间件数据请求时，从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据，其中，所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称。

本申请实施例的从中间件请求数据的系统，在一次网页加载请求过后，中间件客户端将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

为了达到上述目的，本申请第三方面实施例的中间件客户端，包括：待请求数据名称集合确定模块，用于获取与待加载网页相关的特征信息，并根据所述特征信息确定所述待加载网页所对应的待请求数据名称集合，其中，所述待请求数据名称集合包括至少一个中间件对应的待请求数据名称；目标中间件确定模块，用于接收中间件数据请求，并根据所述中间件数据请求确定目标中间件；待请求数据名称确定模块，用于根据所述目标中间件和所述待请求数据名称集合确定需要从所述目标中间件所获取的待请求数据名称；以及中间件数据提供模块，用于根据所述需要从所述目标中间件所获取的待请求数据名称从所述目标中间件获取对应的中间件数据集合并缓存，其中，如果再次接收到向所述目标中间件发送的中间件数据请求则从所述缓存的所述中间件数据集合中提取并反馈对应的中间件数据。

本申请实施例的中间件客户端，在一次网页加载请求过后，可将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

本申请附加的方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本申请的实践了解到。

附图说明

本申请上述的和/或附加的方面和优点从下面结合附图对实施例的描述中将变得明显和容易理解，其中，

图1是根据本申请一个实施例的从中间件请求数据的方法的流程图；

图2是根据本申请一个实施例的从中间件请求数据的方法在第一次用户访问页面时所操作流程的示例图；

图3是根据本申请一个实施例的从中间件请求数据的方法在第二次用户访问页面时所操作流程的示例图；

图4是根据本申请一个实施例的从中间件请求数据的系统的结构示意图；

图5是根据本申请一个实施例的中间件客户端的结构示意图；

图6是根据本申请另一个实施例的中间件客户端的结构示意图。

具体实施方式

下面详细描述本申请的实施例，所述实施例的示例在附图中示出，其中自始至终相同或类似的标号表示相同或类似的元件或具有相同或类似功能的元件。下面通过参考附图描述的实施例是示例性的，旨在用于解释本申请，而不能理解为对本申请的限制。

下面参考附图描述本申请实施例的从中间件请求数据的方法、系统及中间件客户端。

图1是根据本申请一个实施例的从中间件请求数据的方法的流程图。如图1所示，该从中间件请求数据的方法可以包括：

S101，获取与待加载网页相关的特征信息，并根据特征信息确定待加载网页所对应的待请求数据名称集合，其中，待请求数据名称集合包括至少一个中间件对应的待请求数据名称。

此外，在本申请的实施例中，特征信息可为待加载页面的地址信息、请求待加载页面的用户的会员类型信息、待加载页面的名称(如list(目录)页面、detail(详情)页面等)、请求待加载页面的客户端信息(如所用浏览器信息、操作系统信息等)、请求待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数等。

另外，在本申请的实施例中，待加载网页所对应的待请求数据名称集合可通过以下步骤生成：当待加载网页被第一次加载时，记录向至少一个中间件发送的中间件数据请求及与待加载网页相关的特征信息；以及根据记录的中间件数据请求生成待请求数据名称集合，并建立特征信息与待请求数据名称集合之间的关联关系。

具体地，当用户客户端向网页服务器发送网页加载请求时，网页服务器可根据网页加载请求构建待加载网页，中间件客户端可获取与该待加载网页相关的特征信息，如该待加载网页的地址信息(如URL(Uniform Resource Locator，统一资源定位符))或者上述用户客户端所属用户的会员类型信息等，之后可根据上述特征信息确定上述待加载网页所对应的待请求数据名称集合，可以理解，上述待加载网页所对应的待请求数据名称集合是在该待加载网页被第一次加载的过程中生成的。

S102，接收中间件数据请求，并根据中间件数据请求确定目标中间件。

具体地，在网页服务器根据用户发送的网页加载请求构建待加载网页之后，中间件客户端可接收网页服务器发送的中间件数据请求，并根据该中间件数据请求找到与该中间件数据请求对应的中间件作为目标中间件。

S103，根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称。

应当理解，由于上述待请求数据名称集合包括中间件对应的待请求数据名称，所以，中间件客户端在接收到中间件数据请求之后，根据目标中间件和待请求数据名称集合即可确定需要从目标中间件中所要获取的待请求数据名称。

S104，根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存，其中，如果再次接收到向目标中间件发送的中间件数据请求则从缓存的中间件数据集合中提取并反馈对应的中间件数据。

综上所述，本申请实施例的从中间件请求数据的方法是通过中间件客户端自学习来完成请求合并，自动请求合并的基本思路为：在一次网页加载请求过后，中间件客户端将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端中，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可。

进一步的，在本申请的一个实施例中，所述方法还可包括：在将待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后，清空缓存。可以理解，在本申请的实施例中，缓存的生命周期为一次网页加载请求，并且缓存的结果只对本次网页加载请求可见。由此，在本次网页加载请求结束后将缓存清空，一方面可以释放服务器资源，另一方面，不同网页加载请求之间不会造成缓存中中间件数据的紊乱。

可选的，在本申请的一个实施例中，待加载页面可以需要调用多个中间件，待请求数据名称集合可包括多个中间件分别对应的待请求数据名称。也就是说，本申请实施例的从中间件请求数据的方法也适用于从多个中间件请求数据，当待加载页面需要调用多个中间件时，上述待请求数据名称集合则可包括该多个中间件分别对应的待请求数据名称。当中间件客户端接收到哪个中间件对应的中间件数据请求时，则根据该中间件对应的中间件数据请求进行上述步骤S102-S104的处理，以获取该待加载页面中所需要调用的所有中间件对应的中间件数据。

为了使得本领域的技术人员更加清楚地了解本申请，下面将以单个中间件为例对本申请作进一步描述。

举例而言，假设现在有一个权限管理的中间件，所有用户的权限都存在于这个中间件中，当一个用户登录网站后，该用户的网页页面上将要展示多少内容由内容区域的权限所控制。例如，以URL地址为/admin/monitor.jsp的网页为例，假设该网页页面上有4个区域，每一个区域的权限分别为featureA，featureB，featureC，featureD，那么当要渲染这个网页时，将需要向权限中间件请求4次以完成页面中4个区域的渲染。其中，一次对权限中间件的调用示例为：boolean isAllowed＝service.isAllowed(personID,featureA)，这个调用会向远程的权限中间件询问当前personID是否拥有featureA这个功能，如果有这个功能，就在页面上展示featureA对应的内容。

在上面的例子中，可假定一个网页上将要请求的权限是相同的，那么可以以待加载网页的URL为维度，来分类请求的资源。在第一次用户访问页面时，如图2所示，中间件客户端可从网页服务器获取并记录与待加载网页相关的特征信息URL，同时中间件客户端可接收向中间件发送的中间件数据请求(如booleanisAllowed＝service.isAllowed(personID,featureA))，并根据该中间件数据请求从目标中间件获取对应的中间件数据并反馈至网页服务器，网页服务器根据这些中间件数据对待加载网页进行渲染并反馈给用户，其中，中间件客户端根据接收到的中间件数据请求生成待请求数据名称集合并记录下来，以及建立特征信息URL与待请求数据名称集合之间的对应关系，同时中间件客户端要求网页服务器将变量personID传入到中间件客户端中。在上面例子中，特征信息URL与待请求数据名称集合之间的对应关系，如下：

URL:/admin/monitor.jsp-[featureA,featureB,featureC,featureD]

变量:personID。

当第二次和以后所有的网页请求到来时，如图3所示，中间件客户端可根据网页服务器传入的URL来查找对应的待请求数据名称集合，在上面例子中，待请求数据名称集合为[featureA,featureB,featureC,featureD]，同时再根据网页服务器传入的变量(personID)来做数据预热。数据预热将调用批量接口，向中间件请求上述待请求数据名称集合对应的所有资源，并缓存起来。接下去网页服务器对中间件的调用将会从缓存中获取数据。当完成业务(即缓存中待请求数据名称对应的中间件数据全部反馈给网页服务器)后，清空缓存，其中，缓存生命周期为一次用户的网页请求，并且缓存的结果只对本次网页请求可见。

应当理解，相关技术中，当一个网页多次请求同一个中间件时，通常是通过中间件提供一个批量接口，请求方通过该批量接口进行请求合并。虽然批量接口能够解决多次调用的问题，但是，当将请求合并与请求方的业务代码耦合在一起时，会带来以下问题：(1)当需要增加一个新调用，或者删除一个不用的调用时，请求方必须改动请求合并的代码；(2)调用方需要在所有有合并需求的地方写上合并调用的逻辑；(3)在分层式的架构中，不同层的调用合并也会给调用结果的传递带来困难。

通过本申请实施例的从中间件请求数据的方法，通过中间件客户端的自学习来完成请求合并，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

为了实现上述实施例，本申请还提出了一种从中间件请求数据的系统。

图4是根据本申请一个实施例的从中间件请求数据的系统的结构示意图。如图4所示，该从中间件请求数据的系统可以包括：用户客户端10、网页服务器20、中间件客户端30和至少一个中间件40。

具体地，用户客户端10可用于向网页服务器20发送网页加载请求并接收网页服务器20反馈的网页数据。

网页服务器20可用于根据网页加载请求构建待加载网页，并向中间件客户端30发送中间件数据请求以从至少一个中间件40获取中间件数据，以及将获取的中间件数据反馈至用户客户端10。

中间件客户端30可用于获取与待加载网页相关的特征信息，并根据特征信息确定待加载网页所对应的待请求数据名称集合，以及根据中间件数据请求确定目标中间件，并根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称，以及根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存，并再次接收到向目标中间件发送的中间件数据请求时，从缓存的中间件数据集合中提取并反馈对应的中间件数据，其中，待请求数据名称集合包括至少一个中间件对应的待请求数据名称。

其中，在本申请的实施例中，中间件客户端30还可用于在待加载网页被第一次加载时记录向至少一个中间件40发送的中间件数据请求及与待加载网页相关的特征信息，并根据记录的中间件数据请求生成待请求数据名称集合，并建立特征信息与待请求数据名称集合之间的关联关系。

此外，特征信息可为待加载页面的地址信息、请求待加载页面的用户的会员类型信息、待加载页面的名称(如list页面、detail页面等)、请求待加载页面的客户端信息(如所用浏览器信息、操作系统信息等)、请求待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数等。

更具体地，当用户客户端10向网页服务器20发送网页加载请求时，网页服务器20可根据网页加载请求构建待加载网页，中间件客户端30可获取与该待加载网页相关的特征信息，如该待加载网页的地址信息(如URL)或者上述用户客户端10所属用户的会员类型信息等，之后可根据上述特征信息确定上述待加载网页所对应的待请求数据名称集合，可以理解，上述待加载网页所对应的待请求数据名称集合是在该待加载网页被第一次加载的过程中生成的。同时，网页服务器20可向中间件客户端30发送中间件数据请求以从至少一个中间件40获取中间件数据，中间件客户端30在接收到中间件数据请求之后，可根据该中间件数据请求找到与该中间件数据请求对应的中间件作为目标中间件，并可根据目标中间件和待请求数据名称集合即可确定需要从目标中间件中所要获取的待请求数据名称，以及根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存，并再次接收到向目标中间件发送的中间件数据请求时，从缓存的中间件数据集合中提取并反馈对应的中间件数据。

进一步的，在本申请的一个实施例中，中间件客户端30还可用于在将待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后，清空缓存。可以理解，在本申请的实施例中，缓存的生命周期为一次网页加载请求，并且缓存的结果只对本次网页加载请求可见。由此，在本次网页加载请求结束后将缓存清空，一方面可以释放服务器资源，另一方面，不同网页加载请求之间不会造成缓存中中间件数据的紊乱。

可选的，在本申请的一个实施例中，待加载页面可以需要调用多个中间件，待请求数据名称集合可包括多个中间件分别对应的待请求数据名称。也就是说，本申请实施例的从中间件请求数据的系统也适用于从多个中间件请求数据，当待加载页面需要调用多个中间件时，上述待请求数据名称集合则可包括该多个中间件分别对应的待请求数据名称。当中间件客户端接收到哪个中间件对应的中间件数据请求时，则根据该中间件对应的中间件数据请求进行上述的相应处理，以获取该待加载页面中所需要调用的所有中间件对应的中间件数据。

本申请实施例的从中间件请求数据的系统，在一次网页加载请求过后，中间件客户端将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

为了实现上述实施例，本申请还提出了一种中间件客户端。

图5是根据本申请一个实施例的中间件客户端的结构示意图。如图5所示，该中间件客户端可以包括：待请求数据名称集合确定模块31、目标中间件确定模块32、待请求数据名称确定模块33和中间件数据提供模块34。

具体地，待请求数据名称集合确定模块31可用于获取与待加载网页相关的特征信息，并根据特征信息确定待加载网页所对应的待请求数据名称集合，其中，待请求数据名称集合包括至少一个中间件对应的待请求数据名称。此外，在本申请的实施例中，特征信息可为待加载页面的地址信息、请求待加载页面的用户的会员类型信息、待加载页面的名称(如list页面、detail页面等)、请求待加载页面的客户端信息(如所用浏览器信息、操作系统信息等)、请求待加载页面的Cookie信息或者是网页服务器调用中间件客户端时的调用接口或参数等。

进一步的，在本申请的实施例中，待请求数据名称集合确定模块31还可用于当待加载网页被第一次加载时，记录向至少一个中间件发送的中间件数据请求及与待加载网页相关的特征信息，并根据记录的中间件数据请求生成待请求数据名称集合，并建立特征信息与待请求数据名称集合之间的关联关系。

更具体地，在用户客户端向网页服务器发送网页加载请求时，网页服务器可根据网页加载请求构建待加载网页，待请求数据名称集合确定模块31可获取与该待加载网页相关的特征信息，如该待加载网页的地址信息或者上述用户客户端所属用户的会员类型信息等，之后可根据上述特征信息确定上述待加载网页所对应的待请求数据名称集合，可以理解，上述待加载网页所对应的待请求数据名称集合是在该待加载网页被第一次加载的过程中生成的。

目标中间件确定模块32可用于接收中间件数据请求，并根据中间件数据请求确定目标中间件。更具体地，在网页服务器根据用户发送的网页加载请求构建待加载网页之后，目标中间件确定模块32可接收网页服务器发送的中间件数据请求，并根据该中间件数据请求找到与该中间件数据请求对应的中间件作为目标中间件。

待请求数据名称确定模块33可用于根据目标中间件和待请求数据名称集合确定需要从目标中间件所获取的待请求数据名称。应当理解，由于上述待请求数据名称集合包括中间件对应的待请求数据名称，所以，在接收到中间件数据请求之后，待请求数据名称确定模块33根据目标中间件和待请求数据名称集合即可确定需要从目标中间件中所要获取的待请求数据名称。

中间件数据提供模块34可用于根据需要从目标中间件所获取的待请求数据名称从目标中间件获取对应的中间件数据集合并缓存，其中，如果再次接收到向目标中间件发送的中间件数据请求则从缓存的中间件数据集合中提取并反馈对应的中间件数据。

综上所述，本申请实施例的中间件客户端是通过自学习来完成请求合并，自动请求合并的基本思路为：在一次网页加载请求过后，中间件客户端将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在中间件客户端第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可。

进一步的，在本申请的一个实施例中，如图6所示，所述中间件客户端还可包括缓存管理模块35，缓存管理模块35可用于在将待加载网页所对应的待请求数据名称集合中全部待请求数据名称对应的中间件数据均反馈完毕之后，清空缓存。可以理解，在本申请的实施例中，缓存的生命周期为一次网页加载请求，并且缓存的结果只对本次网页加载请求可见。由此，在本次网页加载请求结束后将缓存清空，一方面可以释放服务器资源，另一方面，不同网页加载请求之间不会造成缓存中中间件数据的紊乱。

可选的，在本申请的一个实施例中，在待加载页面需要调用多个中间件时，待请求数据名称集合可包括多个中间件分别对应的待请求数据名称。也就是说，本申请实施例的中间件客户端也适用于从多个中间件请求数据，当待加载页面需要调用多个中间件时，上述待请求数据名称集合则可包括该多个中间件分别对应的待请求数据名称。当中间件客户端接收到哪个中间件对应的中间件数据请求时，则根据该中间件对应的中间件数据请求进行上述的相应处理，以获取该待加载页面中所需要调用的所有中间件对应的中间件数据。

本申请实施例的中间件客户端，在一次网页加载请求过后，可将多个中间件数据请求所请求的资源记录下来，当下一次网页加载请求到来时，在第一次接收到向目标中间件发送的中间件数据请求时，按上一次网页加载请求的过程中记录下来的多次对资源的中间件数据请求，做自动的合并，即通过提供一个批量接口，并通过批量接口向目标中间件请求合并后的资源，同时将请求结果缓存在中间件客户端，如果在本次网页加载请求的过程中，中间件客户端再次接收到向目标中间件发送的中间件数据请求时，则从缓存的请求结果中提取并反馈对应的中间件数据即可，不但解决了上述相关技术中请求合并所带来的问题，同时请求方不需要了解整个请求合并的过程，简化了请求方的操作。

在本说明书的描述中，参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本申请的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

此外，术语“第一”、“第二”仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。由此，限定有“第一”、“第二”的特征可以明示或者隐含地包括至少一个该特征。在本申请的描述中，“多个”的含义是至少两个，例如两个，三个等，除非另有明确具体的限定。

流程图中或在此以其他方式描述的任何过程或方法描述可以被理解为，表示包括一个或更多个用于实现特定逻辑功能或过程的步骤的可执行指令的代码的模块、片段或部分，并且本申请的优选实施方式的范围包括另外的实现，其中可以不按所示出或讨论的顺序，包括根据所涉及的功能按基本同时的方式或按相反的顺序，来执行功能，这应被本申请的实施例所属技术领域的技术人员所理解。

在流程图中表示或在此以其他方式描述的逻辑和/或步骤，例如，可以被认为是用于实现逻辑功能的可执行指令的定序列表，可以具体实现在任何计算机可读介质中，以供指令执行系统、装置或设备(如基于计算机的系统、包括处理器的系统或其他可以从指令执行系统、装置或设备取指令并执行指令的系统)使用，或结合这些指令执行系统、装置或设备而使用。就本说明书而言，"计算机可读介质"可以是任何可以包含、存储、通信、传播或传输程序以供指令执行系统、装置或设备或结合这些指令执行系统、装置或设备而使用的装置。计算机可读介质的更具体的示例(非穷尽性列表)包括以下：具有一个或多个布线的电连接部(电子装置)，便携式计算机盘盒(磁装置)，随机存取存储器(RAM)，只读存储器(ROM)，可擦除可编辑只读存储器(EPROM或闪速存储器)，光纤装置，以及便携式光盘只读存储器(CDROM)。另外，计算机可读介质甚至可以是可在其上打印所述程序的纸或其他合适的介质，因为可以例如通过对纸或其他介质进行光学扫描，接着进行编辑、解译或必要时以其他合适方式进行处理来以电子方式获得所述程序，然后将其存储在计算机存储器中。

应当理解，本申请的各部分可以用硬件、软件、固件或它们的组合来实现。在上述实施方式中，多个步骤或方法可以用存储在存储器中且由合适的指令执行系统执行的软件或固件来实现。例如，如果用硬件来实现，和在另一实施方式中一样，可用本领域公知的下列技术中的任一项或他们的组合来实现：具有用于对数据信号实现逻辑功能的逻辑门电路的离散逻辑电路，具有合适的组合逻辑门电路的专用集成电路，可编程门阵列(PGA)，现场可编程门阵列(FPGA)等。

本技术领域的普通技术人员可以理解实现上述实施例方法携带的全部或部分步骤是可以通过程序来指令相关的硬件完成，所述的程序可以存储于一种计算机可读存储介质中，该程序在执行时，包括方法实施例的步骤之一或其组合。

此外，在本申请各个实施例中的各功能单元可以集成在一个处理模块中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个模块中。上述集成的模块既可以采用硬件的形式实现，也可以采用软件功能模块的形式实现。所述集成的模块如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。

上述提到的存储介质可以是只读存储器，磁盘或光盘等。尽管上面已经示出和描述了本申请的实施例，可以理解的是，上述实施例是示例性的，不能理解为对本申请的限制，本领域的普通技术人员在本申请的范围内可以对上述实施例进行变化、修改、替换和变型。