[发明专利]一种处理请求信息的方法、装置、介质和电子设备

说明书

本公开提供了一种处理请求信息的方法、装置、介质和电子设备。所述方法包括：获取多个第一请求信息；所述第一请求信息间包括相互关联的第一请求关系；基于第一请求数据合并规则和第一请求关系描述规则合并所述第一请求信息，生成第二请求信息；根据所述第二请求信息生成第二请求消息，并向服务端的应用程序接口网关发送所述第二请求消息。在一次信息交互过程中将发送的多个请求消息减少到一个，有效的减少了耗时，提升了用户体验；且减少了API网关负载，提升API网关吞吐量。

技术领域

本公开涉及计算机技术领域，具体而言，涉及一种处理请求信息的方法、装置、介质和电子设备。

背景技术

应用程序一般由客户端和服务端两部分组成。客户端向服务端发送请求；服务端接收请求后从数据库获取数据，并将数据进行处理后返回给客户端；客户端根据返回的数据更新用户界面。

当前，客户端功能变得越来越复杂，一个用户界面可能包含多个模块。为了获取多个模块的数据，在一次信息交互过程中，客户端需要向服务端发送多请求消息。但是，客户端对并发请求消息的数量是有限制的。当同时发送请求消息的数目超过限制的数量时，超出的请求消息就会被暂时阻塞，等已经发送的请求消息返回之后才会被发送。另外，多个请求消息之间可能存在依赖关系。当一个请求消息的请求数据依赖于另一个请求消息的响应数据时，需要等另外一个请求返回之后才能发送。也就是说，存在依赖关系的请求消息必需串行发送。对于超出并发请求消息数量限制或存在依赖关系的多个请求消息，需要耗费多个请求时间，相应的用户界面刷新也需要等待多个请求时间。如果首屏渲染时发送的多个请求消息超出并发请求数量限制或存在依赖关系，会造成比较长的白屏时间，严重损害用户体验。而服务端一般采用微服务架构，即服务端的服务由多个功能单一的微服务组成。多个微服务通过一个应用程序接口(英文全称Application Programming Interface，简称API)网关对客户端提供服务。

客户端发送的请求消息先经过API网关，API网关再分发给各个微服务。由于当前的硬件功能非常强，数据库的读写和业务逻辑运算耗时非常少。而且API网关和微服务通常部署在同一个机房或比较近的多个机房，从API网关到微服务的请求时间也非常短。因此，请求消息的耗时瓶颈主要集中在客户端与API网关之间的信息传输过程。

发明内容

提供该发明内容部分以便以简要的形式介绍构思，这些构思将在后面的具体实施方式部分被详细描述。该发明内容部分并不旨在标识要求保护的技术方案的关键特征或必要特征，也不旨在用于限制所要求的保护的技术方案的范围。

本公开的目的在于提供一种处理请求信息的方法、装置、介质和电子设备，能够解决上述提到的至少一个技术问题。具体方案如下：

根据本公开的具体实施方式，第一方面，本公开提供一种处理请求信息的方法，应用于客户端，包括：

获取多个第一请求信息；所述第一请求信息间包括相互关联的第一请求关系；

基于第一请求数据合并规则和第一请求关系描述规则合并所述第一请求信息，生成第二请求信息；

根据所述第二请求信息生成第二请求消息，并向服务端的应用程序接口网关发送所述第二请求消息。

根据本公开的具体实施方式，第二方面，本公开提供一种处理请求信息的装置，应用于客户端，包括：

获取第一请求信息单元，用于获取多个第一请求信息；所述第一请求信息间包括相互关联的第一请求关系；

生成第二请求信息单元，用于基于第一请求数据合并规则和第一请求关系描述规则合并所述第一请求信息，生成第二请求信息；

生成第二请求消息单元，用于根据所述第二请求信息生成第二请求消息，并向服务端的应用程序接口网关发送所述第二请求消息。