页面数据获取方法、装置、设备和计算机可读存储介质与流程

本公开的实施例一般涉及互联网技术领域，并且更具体地，涉及页面数据获取方法、装置、设备和计算机可读存储介质。

背景技术：

目前，很多前端都需要获取复杂数据结构的数据来渲染app或者服务器页面的ui视图，且复杂的数据可能同时来自不同的数据源，即前端需要获取很多碎片化数据然后进行整合，从而实现页面的渲染。而现有的数据获取方式通常为前端直接向后台发出批量请求，从而通过批量请求来分别获取碎片化数据然后完成页面的渲染，这种做法会导致前端压力比较大，同时外网请求次数多；或者前端只向后台发出一个数据请求，进行一次性数据拉取，这样会导致服务吞吐量严重下降。

技术实现要素：

根据本公开的实施例，提供了一种页面数据获取方案。

在本公开的第一方面，提供了一种页面数据获取方法。该方法包括：

接收来自客户端的页面数据请求；

根据所述页面数据请求生成若干个子数据请求；

将所述若干个子数据请求异步发送至多个任务服务，以通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据，并得到所述页面数据请求所请求的目标页面数据；

将所述目标页面数据发送至所述客户端。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述根据所述页面数据请求生成若干个子数据请求，包括：

按照所述页面数据请求所请求的目标页面数据所占用的一个或多个页面视图，为每个页面视图生成对应的子数据请求。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述根据所述页面数据请求生成若干个子数据请求，包括：

根据所述页面数据请求所请求的目标页面数据中各部分数据的关联度，将所述页面数据请求拆分成所述若干个子数据请求，其中，所述若干个子数据请求中不同子数据请求所请求的数据的关联度低于预设关联度。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述将所述若干个子数据请求异步发送至多个任务服务，包括：

根据所述多个任务服务中各任务服务的历史测试响应时长，将所述若干个子数据请求分配至不同任务服务，其中，历史测试响应时长越长的任务服务接收到的子数据请求的个数越少。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述方法还包括：

在通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据时，确定所述不同任务服务的数据获取响应时长；

当所述多个任务服务中任一任务服务的数据获取响应时长大于预设响应时长时，将所述任一任务服务接收到的子数据请求重新进行拆分，并为所述任一任务服务分配拆分后的数据请求。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述将所述若干个子数据请求异步发送至多个任务服务，以通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据，并得到所述页面数据请求所请求的目标页面数据，包括：

通过网关服务将所述若干个子数据请求异步发送至多个任务服务；

通过网关服务接收所述不同任务服务的数据响应，所述数据响应为所述不同任务服务所获取的对应的子数据请求所请求的数据；

通过网关服务将所述对应的子数据请求所请求的数据进行封装，以得到所述目标页面数据。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述方法还包括：

通过负载均衡服务接收所述网关服务发送的所述目标页面数据；

通过负载均衡服务将所述目标页面数据进行压缩；

所述将所述目标页面数据发送至所述客户端，包括：

通过负载均衡服务将压缩后的所述目标页面数据发送至所述客户端。

如上所述的方面和任一可能的实现方式，进一步提供一种实现方式，所述方法还包括：

所述负载均衡服务根据自身的负载情况调整压缩比例；

所述通过负载均衡服务将所述目标页面数据进行压缩，包括：

所述负载均衡服务按照调整后的压缩比例将所述目标页面数据进行压缩。

在本公开的第二方面，提供了一种页面数据获取装置。该装置包括：

接收模块，用于接收来自客户端的页面数据请求；

生成模块，用于根据所述页面数据请求生成若干个子数据请求；

处理模块，用于将所述若干个子数据请求异步发送至多个任务服务，以通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据，并得到所述页面数据请求所请求的目标页面数据；

发送模块，用于将所述目标页面数据发送至所述客户端。

在本公开的第三方面，提供了一种电子设备。该电子设备包括：存储器和处理器，所述存储器上存储有计算机程序，所述处理器执行所述程序时实现如以上所述的方法。

在本公开的第四方面，提供了一种计算机可读存储介质，其上存储有计算机程序，所述程序被处理器执行时实现如根据本公开的第一方面和/或第二发面的方法。

应当理解，发明内容部分中所描述的内容并非旨在限定本公开的实施例的关键或重要特征，亦非用于限制本公开的范围。本公开的其它特征将通过以下的描述变得容易理解。

附图说明

结合附图并参考以下详细说明，本公开各实施例的上述和其他特征、优点及方面将变得更加明显。在附图中，相同或相似的附图标记表示相同或相似的元素，其中：

图1示出了根据本公开的实施例的一种页面数据获取方法的流程图；

图2示出了根据本公开的实施例的另一种页面数据获取方法的流程图；

图3示出了根据本公开的实施例的页面数据获取装置的方框图；

图4示出了能够实施本公开的实施例的示例性电子设备的方框图。

具体实施方式

为使本公开实施例的目的、技术方案和优点更加清楚，下面将结合本公开实施例中的附图，对本公开实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本公开一部分实施例，而不是全部的实施例。基于本公开中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的全部其他实施例，都属于本公开保护的范围。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，a和/或b，可以表示：单独存在a，同时存在a和b，单独存在b这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。

本公开中，可基于客户端发送的页面数据请求生成若干个子数据请求，然后将这些子数据请求分发至不同的任务服务，以通过不同的任务服务分别获取不同的碎片化数据，最终得到网页数据请求所请求的完整的目标页面数据，这样可在避免客户端前端批量请求基础上，依据后端的批量请求来高效地获取页面数据，如此既兼顾了效率也减少了前端请求次数，而且也解决了前端对碎片化数据采用了一次性数据拉取方式而导致的服务吞吐量严重下降的问题。

图1示出了根据本公开实施例的用于页面数据获取方法100的流程图。该方法100包括：

步骤110，接收来自客户端的页面数据请求；

步骤120，根据所述页面数据请求生成若干个子数据请求；

步骤130，将所述若干个子数据请求异步发送至多个任务服务，以通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据，并得到所述页面数据请求所请求的目标页面数据；

通过不同任务服务获取对应的子数据请求所请求的数据即通过不同任务服务获取为其分配的子数据请求所请求的数据。

每个任务服务可以被分配一个或多个子数据请求。

不同的子数据请求用于请求目标页面数据中的不同部分的数据。

步骤140，将所述目标页面数据发送至所述客户端。客户端可以是app或者浏览器。

在接收到来自客户端的页面数据请求后，通过根据该页面数据请求可生成若干个子数据请求，然后将这些子数据请求分发至不同的任务服务，从而通过对不同任务服务获取的对应的子数据请求所请求的数据进行整合等各种处理，可得到该页面数据请求所请求的完整的目标页面数据，进而将目标页面数据发送至该客户端，即可在避免客户端前端批量请求基础上，依据后端的批量请求来高效地获取页面数据，如此既兼顾了效率也减少了前端请求次数即外网请求数量，而且也解决了前端对碎片化数据采用了一次性数据拉取方式而导致的服务吞吐量严重下降的问题。

在一个实施例中，所述根据所述页面数据请求生成若干个子数据请求，包括：

按照所述页面数据请求所请求的目标页面数据所占用的一个或多个页面视图，为每个页面视图生成对应的子数据请求。一个页面视图即一个view控件。

通过按照目标页面数据所占用的一个或多个页面视图，可为每个页面视图都生成一个对应的子数据请求，如此，不同的子数据请求可请求不同的页面视图中的数据，而这种后台将原始的页面数据请求拆分成多个子数据请求的方式，可通过减少前端的请求次数来减少前端的请求压力；同时也可避免将复杂的数据一次性进行数据拉取而导致的服务吞吐量严重下降。

在一个实施例中，所述根据所述页面数据请求生成若干个子数据请求，包括：

根据所述页面数据请求所请求的目标页面数据中各部分数据的关联度，将所述页面数据请求拆分成所述若干个子数据请求，其中，所述若干个子数据请求中不同子数据请求所请求的数据的关联度低于预设关联度。

在生成子数据请求时，还可按照前端的页面数据请求所请求的目标页面数据中各部分数据的关联度，将所述页面数据请求拆分成所述若干个子数据请求，这样，可保证不同的子数据请求所请求的数据的关联度较低，独立性较高，从而避免重复请求相同的数据，如此，也可提高数据获取效率。

另外，本实施例这种依赖关联度生成子请求的方式可以与上个实施例中依赖视图生成子请求的方式相结合，且优选地，本实施例可以为辅，即在依赖视图生成子请求的基础上，结合关联度对视图的颗粒进行调整或者直接对生成的子请求进行拆分或者整合等优化。

在一个实施例中，所述将所述若干个子数据请求异步发送至多个任务服务，包括：

根据所述多个任务服务中各任务服务的历史测试响应时长，将所述若干个子数据请求分配至不同任务服务，其中，历史测试响应时长越长的任务服务接收到的子数据请求的个数越少。

由于不同任务服务的性能会有所差异，因而，可事先对各不同任务服务的响应时长进行测试，然后生成该若干个子数据请求之后，依据各任务服务的历史测试响应时长，将所述若干个子数据请求分配至不同任务服务，如此，可具体结合不同任务服务的性能对子数据请求进行合理分配，如历史测试响应时长越长的任务服务接收到的子数据请求的个数就可以越少，从而尽可能最大化所有任务服务的性能，这样可进一步提高数据获取效率。

任务服务实质上就是一个进程，不同任务服务可以分布在不同的服务器上，即任务服务的数量可以等于服务器的数量或者大于服务器的数量，且这些服务器之间的距离都很近，基本在同一个机房内，如此，即可避免采用cdn(contentdeliverynetwork，内容分发网络)这种就近获取页面数据的方式，且这种cdn获取方式通常适用于服务器上存储的都是公共数据而非个性化数据，因而，采用本公开的获取方式有利于提高个性化数据获取效率。

在一个实施例中，所述方法还包括：

在通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据时，确定所述不同任务服务的数据获取响应时长；

当所述多个任务服务中任一任务服务的数据获取响应时长大于预设响应时长时，将所述任一任务服务接收到的子数据请求重新进行拆分，并为所述任一任务服务分配拆分后的数据请求。预设响应时长可自由设定，如可以时50毫秒。

在通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据时，若多个任务服务中某个任务服务的数据获取响应时长大于预设响应时长时，说明该任一任务服务当前比较卡性能不好数据获取效率低，因而，可将所述任一任务服务接收到的子数据请求重新进行拆分，并为所述任一任务服务分配拆分后的数据请求，从而可实时结合任务服务的性能动态调整子数据请求，以充分提高碎片化数据的获取效率。

另外，通过将子数据请求重新进行拆分，可优化响应时长大于预设响应时长的该任一任务服务的性能，当然进一步优化方案可以是扩容，即确定该任一任务服务的服务类型，然后增加相同类型的任务服务的数量，这相当于采用木桶原理，并能够指向性地不断进行性能优化，使得性能可以优化到极致。例如：任务服务的类型可以是会员类服务(如用于请求跟账户、余额有关的数据的任务服务)、用户类服务(如用于请求个性化收藏、个性化播放资源等个性化数据的任务服务)，而若该任一任务服务的服务类型为用户类服务，则增加用户类服务的数量即可实现扩容。

在一个实施例中，所述将所述若干个子数据请求异步发送至多个任务服务，以通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据，并得到所述页面数据请求所请求的目标页面数据，包括：

通过网关服务将所述若干个子数据请求异步发送至多个任务服务；

通过网关服务接收所述不同任务服务的数据响应，所述数据响应为所述不同任务服务所获取的对应的子数据请求所请求的数据；网关服务也是一个进程，可以是网关上的进程。

通过网关服务将所述对应的子数据请求所请求的数据进行封装，以得到所述目标页面数据。

通过该网关服务将若干个子数据请求发送至多个任务服务，可基于该网关服务接收不同任务服务的数据响应，然后将不同任务服务所获取的对应的子数据请求所请求的数据进行封装，即可得到前端客户端所请求的完整的目标页面数据，从而实现通过后台网关将请求进行拆分与封装，进而实现了碎片化数据的高效获取。

在一个实施例中，所述方法还包括：

通过负载均衡服务接收所述网关服务发送的所述目标页面数据；

通过负载均衡服务将所述目标页面数据进行压缩；

负载均衡服务可以是负载均衡服务器上的一个进程。

所述将所述目标页面数据发送至所述客户端，包括：

通过负载均衡服务将压缩后的所述目标页面数据发送至所述客户端。

通过负载均衡服务将所述目标页面数据进行自动压缩，可减少目标页面数据所占用的空间，这样，在负载均衡服务将压缩后的所述目标页面数据发送至所述客户端时，也可提高数据传输效率。

在一个实施例中，所述方法还包括：

所述负载均衡服务根据自身的负载情况调整压缩比例；

所述通过负载均衡服务将所述目标页面数据进行压缩，包括：

所述负载均衡服务按照调整后的压缩比例将所述目标页面数据进行压缩。

负载均衡服务还可根据自身的负载情况动态调整压缩比例，然后利用调整后的压缩比例将目标页面数据进行自动压缩，从而既避免由于数据压缩而给负载均衡服务造成很大压力，又可以动态地将压缩比例合理化。

下面将结合图2进一步说明本发明的技术方案：

本公开是一种高效提供个性化复杂数据结构的方法，首先按视图(即页面中每个块，每个view)进行数据分区块；

每一个区块(即view上的数据)对应一个返回结果中的一个数据根节点；数据根节点为每个区块的标识；

基于一个请求访问网关服务，根据区块分配任务到对应的微服务上去实现，按约定数据结构返回给网关服务；

基于上述方案，网关服务负责异步分发任务到每一个微服务上去；

网关服务最后负责进行数据节点的组装；

通过nginx等web容器进行数据压缩，网络传输到app端；

app端按数据节点，渲染每一个子ui；

客户端(app)发起请求到负载均衡(例如nginx服务器，压缩比例可动态调整，如根据压缩后耗费的cpu等负载情况，选择压缩比例)；负载均衡把请求转到后端网关服务；网关服务根据业务场景，并发异步发送请求到后端任务服务(微服务，是个服务器上进程)；任务服务陆续返回结果到网关服务；网关服务封装结果，然后输出结果到负责均衡；负载均衡负责压缩后，发送到客户端，到此请求的全过程完成。

需要说明的是，对于前述的各方法实施例，为了简单描述，故将其都表述为一系列的动作组合，但是本领域技术人员应该知悉，本公开并不受所描述的动作顺序的限制，因为依据本公开，某些步骤可以采用其他顺序或者同时进行。其次，本领域技术人员也应该知悉，说明书中所描述的实施例均属于可选实施例，所涉及的动作和模块并不一定是本公开所必须的。

以上是关于方法实施例的介绍，以下通过装置实施例，对本公开所述方案进行进一步说明。

图3示出了根据本公开的实施例的页面数据获取装置300的方框图。

如图3所示，装置300包括：

接收模块310，用于接收来自客户端的页面数据请求；

生成模块320，用于根据所述页面数据请求生成若干个子数据请求；

处理模块330，用于将所述若干个子数据请求异步发送至多个任务服务，以通过所述多个任务服务中不同任务服务获取对应的子数据请求所请求的数据，并得到所述页面数据请求所请求的目标页面数据；

发送模块340，用于将所述目标页面数据发送至所述客户端。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，所述描述的模块的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

图4示出了可以用来实施本公开的实施例的电子设备400的示意性框图。设备400可以用于实现图2的页面数据获取装置。如图4所示，设备400包括cpu401，其可以根据存储在rom402中的计算机程序指令或者从存储单元408加载到ram403中的计算机程序指令，来执行各种适当的动作和处理。在ram403中，还可以存储设备400操作所需的各种程序和数据。cpu401、rom402以及ram403通过总线404彼此相连。i/o接口405也连接至总线404。

设备400中的多个部件连接至i/o接口405，包括：输入单元406，例如键盘、鼠标等；输出单元407，例如各种类型的显示器、扬声器等；存储单元408，例如磁盘、光盘等；以及通信单元409，例如网卡、调制解调器、无线通信收发机等。通信单元409允许设备400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。

处理单元401执行上文所描述的各个方法和处理，例如方法100、200。例如，在一些实施例中，方法100、200可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元408。在一些实施例中，计算机程序的部分或者全部可以经由rom402和/或通信单元409而被载入和/或安装到设备400上。当计算机程序加载到ram403并由cpu401执行时，可以执行上文描述的方法100、200的一个或多个步骤。备选地，在其他实施例中，cpu401可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行方法100、200。

本文中以上描述的功能可以至少部分地由一个或多个硬件逻辑部件来执行。例如，非限制性地，可以使用的示范类型的硬件逻辑部件包括：场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、片上系统(soc)、复杂可编程逻辑器件(cpld)等等。

用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。

在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、ram、rom、eprom、光纤、cd-rom、光学储存设备、磁储存设备、或上述内容的任何合适组合。

此外，虽然采用特定次序描绘了各操作，但是这应当理解为要求这样操作以所示出的特定次序或以顺序次序执行，或者要求所有图示的操作应被执行以取得期望的结果。在一定环境下，多任务和并行处理可能是有利的。同样地，虽然在上面论述中包含了若干具体实现细节，但是这些不应当被解释为对本公开的范围的限制。在单独的实施例的上下文中描述的某些特征还可以组合地实现在单个实现中。相反地，在单个实现的上下文中描述的各种特征也可以单独地或以任何合适的子组合的方式实现在多个实现中。

尽管已经采用特定于结构特征和/或方法逻辑动作的语言描述了本主题，但是应当理解所附权利要求书中所限定的主题未必局限于上面描述的特定特征或动作。相反，上面所描述的特定特征和动作仅仅是实现权利要求书的示例形式。