CN115514650A - 限流场景下的带宽管理方法、装置、介质及电子设备 - Google Patents

Abstract

本公开的实施方式提供了一种限流场景下的带宽管理方法、装置、介质及电子设备，该方法应用于网关时，包括步骤：接收终端发送的业务请求；其中，所述业务请求用于向服务器请求业务信息；基于所述服务器的业务承载量确定所述业务请求是否为超限请求；若所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。本公开的限流场景下的带宽管理方法使终端基于超限信息从本地获取目标提示信息，可减少超限信息的体量，降低带宽开销。

Description

限流场景下的带宽管理方法、装置、介质及电子设备

技术领域

本公开的实施方式涉及计算机技术领域，更具体地，本公开的实施方式涉及限流场景下的带宽管理方法、装置、介质及电子设备。

背景技术

终端的应用在向后端为服务器请求业务时，请求会先经过网关，然后再到达后端微服务，微服务在收到经网关的请求后，会基于请求执行业务逻辑。而在一些大流量高并发的场景下，如电商秒杀抢购等场景，为了保障后端微服务的稳定，超限的应用端请求会被网关限流掉并直接返回限流提醒，如网关为应用返回一个标识请求过多错误(429)页面。

网关在限流时所返回的限流提醒一般基于HTTP协议(Hyper Text TransferProtocol，超文本传输)实现，HTTP协议包括用于指示客户端如何处理的响应头以及表示发送到客户端的实际内容的响应体，客户端在接受到HTTP协议后，基于响应头与响应体可在页面展示相关内容。

在限流时，网关返回给不同应用的超限信息的响应体是完全一致和重复的，应用在收到超限每个超限信息的响应体均会占用几百bit(比特)的带宽，在百万级到千万级TPS(系统吞吐量)并发的场景下，占用的带宽会多达几十Gbps(交换带宽)之多，这产生了巨大的带宽成本；而带宽资源是非常宝贵和有限的，网关这种方式也会挤压其它正常用户请求，造成更高的响应延迟甚至直接导致网络拥塞，进而影响用户体验。

发明内容

为此，本公开提出一种限流场景下的带宽管理方法，终端基于超限信息从本地获取目标提示信息，可减少超限信息的体量，降低带宽开销。

在本上下文中，本公开的实施方式期望提供一种限流场景下的带宽管理方法、装置、介质及电子设备。

在本公开实施方式的第一方面中，提供了一种限流场景下的带宽管理方法，应用于网关，所述方法包括：接收终端发送的业务请求；其中，所述业务请求用于向服务器请求业务信息；基于所述服务器的业务承载量确定所述业务请求是否为超限请求；若所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

在本公开实施方式的第二方面中，提供了一种限流场景下的带宽管理方法，应用于终端，所述方法包括：向网关发送用于请求业务信息的业务请求；接收网关针对所述业务请求返回的超限信息；其中，所述超限信息为所述网关基于所述业务请求对应的服务器的业务承载量所生成的；基于所述超限信息从预先存储的提示信息中选择对应的目标提示信息，并将所述目标提示信息进行渲染展示。

在本公开实施方式的第三方面中，提供了一种限流场景下的带宽管理方法，包括：终端向网关发送用于向服务器请求业务信息的业务请求；所述网关基于所述服务器的业务承载量确定所述业务请求是否为超限请求；若所述业务请求为超限请求，所述网关则拦截所述业务请求，并向所述终端返回超限信息；所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

在本公开实施方式的第四方面中，提供了一种限流场景下的带宽管理装置，配置于网关，所述装置包括：业务请求接收模块，配置为接收终端发送的业务请求；其中，所述业务请求用于向服务器请求业务信息；超限判断模块，配置为基于所述服务器的业务承载量确定所述业务请求是否为超限请求；第一超限处理模块，配置为若所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

在本公开实施方式的第五方面中，提供了一种限流场景下的带宽管理装置，配置于终端，所述装置包括：业务请求发送模块，配置为向网关发送用于请求业务信息的业务请求；超限信息接收模块，配置为接收网关针对所述业务请求返回的超限信息；其中，所述超限信息为所述网关基于所述业务请求对应的服务器的业务承载量所生成的；第二超限处理模块，配置为基于所述超限信息从预先存储的提示信息中选择对应的目标提示信息，并将所述目标提示信息进行渲染展示。

在本公开实施方式的第六方面中，提供了一种限流场景下的带宽管理系统，包括：网关以及预先存储有提示信息的终端；其中，所述终端用于发送向服务器请求业务信息的业务请求；所述网关用于基于所述服务器的业务承载量确定所述业务请求是否为超限请求，当所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

在本公开实施方式的第七方面中，提供了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述所述的限流场景下的带宽管理方法。

在本公开实施方式的第八方面中，提供了一种电子设备，包括：处理器；以及存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如上述所述的限流场景下的带宽管理方法。

根据本公开实施方式的技术方案，在确认业务请求为超限请求后，通过网关向终端返回超限信息，即可基于超限信息从终端本地存储的提示信息中提取与超限信息对应的目标提示信息，无需基于超限信息计算目标提示信息，可减少超限信息的体量，降低网关返回超限信息时所占用的带宽开销。

附图说明

通过参考附图阅读下文的详细描述，本公开示例性实施方式的上述以及其他目的、特征和优点将变得易于理解。在附图中，以示例性而非限制性的方式示出了本公开的若干实施方式，其中：

图1是本申请一示例性实施例示出的一种限流场景下的带宽管理方法的应用场景图；

图2是本申请的一示例性实施例示出的限流场景下的带宽管理方法流程图；

图3是本申请的另一示例性实施例示出的限流场景下的带宽管理方法流程图；

图4是图2所示实施例中的步骤S250在一示例性实施例中的流程图；

图5是图2所示实施例中的步骤S230在一示例性实施例中的流程图；

图6是是本申请的另一示例性实施例示出的限流场景下的带宽管理方法流程图；

图7是是本申请的另一示例性实施例示出的限流场景下的带宽管理方法流程图；

图8是本申请的一示例性实施例示出的限流场景下的带宽管理装置的结构示意图；

图9是本申请的另一示例性实施例示出的限流场景下的带宽管理装置的结构示意图；

图10示出了根据本公开的示例实施例的存储介质的结构示意图；

图11示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

具体实施方式

下面将参考若干示例性实施方式来描述本公开的原理和精神。应当理解，给出这些实施方式仅仅是为了使本领域技术人员能够更好地理解进而实现本公开，而并非以任何方式限制本公开的范围。相反，提供这些实施方式是为了使本公开更加透彻和完整，并且能够将本公开的范围完整地传达给本领域的技术人员。

本领域技术人员知道，本公开的实施方式可以实现为一种系统、装置、设备、方法或计算机程序产品。因此，本公开可以具体实现为以下形式，即：完全的硬件、完全的软件(包括固件、驻留软件、微代码等)，或者硬件和软件结合的形式。

根据本公开的实施方式，提出了一种限流场景下的带宽管理方法、装置、介质及电子设备。

此外，附图中的任何元素数量均用于示例而非限制，以及任何命名都仅用于区分，而不具有任何限制含义。

下面参考本公开的若干代表性实施方式，详细阐释本公开的原理和精神。

发明概述

终端中各应用业务的实现可通过应用向后端微服务发送业务请求，以使后端微服务相应于业务请求执行业务逻辑，当然，业务请求在发送过程中，需先经过API(Application Program Interface，应用程序界面)网关，然后到达后端微服务，当后端微服务的业务请求量过高时，网关则会开启限流，终端、网关与后端微服务之间的信息传输大多依赖于HTPP协议。

具体地，API网关简称网关，它代理微服务对外暴露的API，是所有服务访问的统一入口，用户请求都会先经过API网关，然后再到达后端微服务。一些微服务的通用能力，比如限流、鉴权、流量灰度等能力会前移下沉到API网关。

应用(Application)简称app，是指安装在手机等智能设备上的程序，一般需要与服务端互相配合运行。常见的应用主要分两类。一类是预装的系统应用，比如短信、照片、备忘录等；还有一类是第三方应用，比如资讯类的新闻应用、购物类的应用、社交类的应用等。

超文本传输协议(Hyper Text Transfer Protocol，HTTP)是一个简单的请求响应协议，它通常运行在TCP(Transmission Control Protocol，传输控制协议)之上，它指定了客户端可能发送给服务器什么样的消息以及得到什么样的响应。

HTTP协议中的响应头(Response Header)用于指示客户端如何处理响应体，告诉浏览器响应的类型、字符编码和字节大小等信息。

HTTP协议中的响应体(Response Body)是服务器发送到客户端的实际内容，除网页外，响应体还可以是诸如Word、Excel或PDF(一些不同文档的类型)等其他类型的文档，具体是哪种文档类型由Content-Type(告诉客户端实际返回的内容的内容类型)指定的MIME(Multipurpose Internet Mail Extensions，多用途互联网邮件扩展类型)类型决定。

后端微服务可能因为业务请求量过多了造成服务过载，服务过载就是服务的请求量超过服务所能承受的最大值，从而导致服务器负载过高，响应延迟加大，用户侧表现为无法加载或者加载缓慢，这回引起用户进一步的重试，服务一直在处理过去的无效请求，无法对其他请求进行处理，从而导致服务器所完成处理的有效请求数量为零，甚至导致整个系统产生雪崩，为了避免服务器过载，一般会有各种过载保护策略，最典型的就是限流。

限流即为对请求或并发数进行限制，通过对一个时间窗口内的请求量进行限制来保障系统的正常运行，如果服务资源有限、处理能力有限就需要对调用服务的上游请求进行限制，防止服务由于资源耗尽而停止服务。

常见的限流算法有计数限流、漏桶(Leaky Bucket)算法和令牌桶算法(TokenBucket)等。

在介绍了本公开的基本原理之后，下面具体介绍本公开的各种非限制性实施方式。

应用场景总览

首先参考图1，图1示出了可以应用本公开实施例的一种限流场景下的带宽管理方法的应用场景图，该应用场景包括终端100、网关200以及服务器300。

终端100中设置有多个应用，不同的应用可基于网关200向服务器300发送业务请求，服务器300为对应与不同应用的微服务器，可基于业务请求执行表达正常业务逻辑。

终端100、网关200以及服务器300之间通过有线或无线传输，应该理解，图1中的终端100、网关200以及服务器300之间通过有线或无线传输的数目仅仅是示意性的。根据实现需要，可以具有任意数目的终端100、网关200以及服务器300。比如服务器300可以是多个服务器组成的服务器集群等。

其中，终端100可以是智能手机、平板、笔记本电脑、计算机等任意能够实现数据可视化的电子设备，本处不进行限制。服务器300可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式系统，其中多个服务器可组成一区块链，而服务器为区块链上的节点，服务器300还可以是提供云服务、云数据库、云计算、云函数、云存储、网络服务、云通信、中间件服务、域名服务、安全服务、CDN(Content Delivery Network，内容分发网络)以及大数据和人工智能平台等基础云计算服务的云服务器，本处也不对此进行限制。

本公开实施例所提供的限流场景下的带宽管理方法可由终端100或网关200执行，相应地，限流场景下的带宽管理装置一般设置于终端100或网关200中。

举例而言，在一种示例性实施例中，终端100中的应用向网关200发送业务请求，该业务请求用于向服务器请求业务信息，网关200在收到业务信息后，基于服务器的业务承载量确定业务请求是否为超限请求，如果业务请求为超限请求，则拦截业务请求，即网关200不向服务器300发送该业务请求，而向终端返回超限信息，该超限信息的响应体设置为空，响应头设置为与业务请求对应的状态码，终端100在收到超限信息后，其应用会基于超限信息的响应头从预先存储的提示信息中提取对应的目标提示信息，并将目标提示信息进行渲染展示。

本实施例中的不同响应头的状态码在终端100本地会存储有对应提示信息，在收到超限信息后，即可通过状态码在本地获取目标提示信息，及超限信息的响应体为空，通过响应头即可在终端100的界面展示目标提示信息。

应该理解的是，图1所示的应用场景仅是本公开的实施例可以在其中得以实现的一个示例。本公开实施例的适用范围不受到该应用场景任何方面的限制。

示例性方法

下面结合图1的应用场景，参考图2来描述根据本公开示例性实施方式的用于限流场景下的带宽管理方法。需要注意的是，上述应用场景仅是为了便于理解本公开的精神和原理而示出，本公开的实施方式在此方面不受任何限制。相反，本公开的实施方式可以应用于适用的任何场景。

参考图2，图2为一实施例中公开的一种限流场景下的带宽管理方法，该方法应用于图1中的网关200，该方法包括步骤S210至步骤S250，具体描述如下：

步骤S210：接收终端发送的业务请求，业务请求用于向服务器请求业务信息。

本实施例中的限流场景下的带宽管理方法可参考图3所示的流程图，在一实施例中，用户通过控制终端上的应用软件发起业务请求，如抢购业务请求、网页获取业务请求等。

该业务请求为向对应服务器请求业务信息，如在一实施例中，终端发送抢购的业务请求，在服务器响应于业务请求执行表达业务逻辑后，即可在终端界面显示购买成功信息。

应用的业务请求会先到达网关，网关接收业务请求后即可通过网关内部的限流引擎来判断业务请求是否超限。

步骤S230：基于服务器的业务承载量确定业务请求是否为超限请求。

本实施例中，判断业务请求是否为超限请求可通过网关内预设的限流引擎完成。

具体地，在设置网关时，可基于服务器的业务承载量以及限流算法在限流引擎中配置限流规则，当业务请求到达网关后，网关内的限流引擎即基于业务请求、限流规则、限流算法计算该业务请求是否超限，即是否为超限请求。

本实施例中，对于终端中的某个应用应，存在至少一个微服务为该应用提供服务，不同的业务请求对应提供服务的服务器不同，因此，可通过经验参数预测某个应用的整体流量，然后将整体流量拆解为每个服务器需承担的流量，如此，基于该服务器所需承受的流量，即可得到各服务器的最大业务承载量。

基于各服务器的最大业务承载量，合并该服务器的处理业务性能以及限流算法可以配置限流规则，具体可为，根据限流算法，配置对应限流算法下的各服务器处理业务请求额度，最大业务承载量和处理业务性能越高，处理业务请求额度则越大，直至服务器在某段时间内所处理的业务请求量超过该请求额度，则视为超限请求。

当然，在其他实施例中，还可直接基于服务器的最大业务承载量和当前业务处理量来确定业务请求是否超限，以上为示例性的提出两种判断业务请求是否超限的方法，不作为判断业务请求是否超限的方式的限制。

步骤S250：若业务请求为超限请求，则拦截业务请求，并向终端返回超限信息，以使终端基于超限信息从预先存储的提示信息中提取对应的目标提示信息，并将目标提示信息进行渲染展示。

本实施例中，网关通过获取服务器的最大业务承载量，以及在收到业务请求时，服务器的当前处理的业务处理量，然后通过比对最大业务承载量和业务处理量来判断业务请求是否超限。

当然，在其他实施例中，也可通过限流规则，确定该业务请求进入服务器是否超过服务器的处理业务请求额度，如果超过该额度，则视为超限请求。

当业务请求为超限请求时，网关则会拦击该业务请求，并基于该业务请求生成一个超限信息，该超限信息为http协议格式，即包括响应体与响应头。

一般情况下，基于超限信息中的响应体与响应头可在终端的界面展示目标提示信息，如在终端界面展示“该服务器已崩溃，请稍后再试”等限流文案或限流界面，当然，不同的业务请求所对应的目标提示信息不同，如购物相关的业务请求，其目标提示信息应与购物服务器无法提供服务的信息相关，即目标提示信息可以随着业务请求的变化而不同，由于响应体与响应头包含有目标提示信息的所有数据，因此在网关发送超限信息时，会占用较大的带宽。

本实施例中，为了减少网关在返回超限信息时所带来的带宽消耗，设置服务器返回的响应体为空，响应头设置状态码，并在终端的本地存储有多个提示信息，不同的提示信息对应不同的业务请求，且不同的状态码对应不同的提示信息，可通过超限信息中的状态码在存储的多个提示信息中确定对应的提示信息。

以此，在网关返回超限信息时，由于超限信息的响应体为空，可减少超限信息交互所占用的带宽，且终端可基于超限信息中的响应头，在本地预先存储的多个提示信息中确定响应头的状态码所对应的目标提示信息。

当然，对于终端中所存在的多个应用，不同应用所需要的提示信息可存在该应用在终端中所划分的存储空间内。

进一步地，该状态码可以是现有的HTTP所规定的状态码，如消息类的状态码100、101等，重定向状态码300、301等，此处不进行限制，还其他实施例中，还可以自定义设置字符或字符串作为状态码，该状态码与对应终端中本地存储的各提示信息对应即可。

若业务请求不是超限请求，则将业务请求发送至服务器，以使服务器基于业务请求执行表达正常业务逻辑，并可返回业务信息，终端在收到业务信息后，则可在应用界面显示业务信息，如购买成功等页面。

本实施例中，被限流的业务请求在终端界面所展示的内容不再由网关返回的超限信息中生成，而由终端的应用根据超限信息的响应头选择本地的页面或文案直接展示，对应超限信息中的响应体则可设置为空，在用户无感知的情况下，通过对响应体瘦身大幅降低了下行带宽消耗，带来了极大的带宽成本的节省，同时提升了用户体验，提高了用户留存。

图4是图2所示实施例中步骤S250在一示例性实施例中的流程图。如图4所示，在一示例性实施例中，该拦截业务请求，并向终端返回超限信息，以使终端基于超限信息从预先存储的本地界面中提取对应的超限界面，并对超限界面进行渲染展示的过程可以包括步骤S410至步骤S450，详细介绍如下：

步骤S410：构建初始信息。

本实施例中的初始信息可以为初始化的HTTP信息，即初始信息包括初始响应头与初始响应体，在将所需传送至终端的信息写入初始响应头与初始响应体之后，即可得到用于传送的HTTP信息。

步骤S430：将初始响应头设置为与业务请求所对应的状态码，并将初始响应体设置为空，以得到超限信息。

本实施例中，基于业务请求设置初始响应头的状态码(status code)，不同的状态码对应不同的提示信息，多个提示信息存储在终端本地，后续可通过状态码在多个提示信息中确定该状态码所对应的目标提示信息。

同时由于终端本地存储有提示信息，即可设置响应体为空，通过对响应体瘦身达到减少带宽占用的目的。

具体地，设置响应体为空，可在网关内核层面设置相关代码以及在网关插件层面设置相关代码，以指示响应体为空，以下示出在网关内核层面设置响应体为空的代码示例：

在网关内核层面：error_page 429/429_error_handle；location＝/429_error_handle{internal；return 429""；}。

当然，上述的代码中相关代表式均为程序常用表达释义，此处不具体阐述，且以使仅为示例性的提出一些程序方法，并不是对设置响应体为空方式的具体限制，还可通过其他方式设置响应体为空。

步骤S450：将超限信息返回至终端，以使终端依据状态码提取对应的目标提示信息进行渲染展示。

在网关生成超限信息后，即可将超限信息返回至终端，终端会根据超限信息中的状态码提取对应的目标提示信息进行渲染展示。

本实施例中，当超限的业务请求被网关限流后，网关通过返回空响应体，以及在响应头设置状态码，另一方面展示给用户的页面或文案由终端本地存储，终端则根据网关返回的响应头选择相应的本地页面或文案进行渲染展示，从而避免服务端往前端的大量重复页面文案的传输，大幅降低带宽成本。

图5是图2所示实施例中步骤S230在一示例性实施例中的流程图。如图5所示，在一示例性实施例中，该基于所述服务器的业务承载量确定所述业务请求是否为超限请求的过程可以包括步骤S510至步骤S550，详细介绍如下：

步骤S510：获取服务器的最大业务承载量，以及服务器当前处理的业务处理量。

本实施例中提出一种超限判断方式，即通过获取服务器的最大业务承载量，以及网关收到业务请求时，服务器的当前处理的业务处理量，然后通过比对最大业务承载量和业务处理量来判断业务请求是否超限。

该最大业务承载量可通过流量预估、流量分解、压测摸高等流程具体确认。

在一具体实施例中，流量预估则为基于行业调研分析、历史经验、业务模型等预估终端中某个应用的整体流量；流量分解则为对预估的整体流量进行拆解，以得到每个微服务需要承担的流量大小(对一个应用提供服务至少需要一个微服务，如在一实施例中，支撑某个应用业务的服务器可以包括用户微服务、营销微服务、交易微服务等)，并对每个微服务不是能够支撑其流量预估大小的资源(服务器、数据库、缓存等)；压测摸高是指模拟用户流量进行整体压测，发现性能瓶颈，摸高系统能真实承担的流量大小，并按需优化或通过扩容提升容量，得到最终满足业务流量需求的性能基线，即可认为得到各微服务(服务器)的最大业务承载量。

步骤S530：若业务处理量大于或等于最大业务承载量，则业务请求为超限请求。

若业务处理量大于或等于最大业务承载量，则业务请求为超限请求，即执行图2中的步骤S250。

步骤S550：若业务处理量小于最大业务承载量，则业务请求为非超限请求。

当业务请求为非超限请求时，则将业务请求发送至服务器，以使服务器基于业务请求执行表达正常业务逻辑，并可返回业务信息，终端在收到业务信息后，则可在应用界面显示业务信息，如购买成功等页面。

当然，在其他实施例中，为保证限流的准确性，还基于性能基线配置各微服务的限流规则，该限流规则中包括微服务的性能、限流算法等参数，以此基于该限流规则来判断业务请求是否超限。

不同的限流算法所对应的限流规则不同，首先可则基于最大业务承载量和处理业务性能配置各服务器处理业务请求额度，最大业务承载量和处理业务性能越高，处理业务请求额度则越大，而不同的限流算法，处理业务请求额度设置不同。

如在一实施例中，使用计数限流的限流算法来配置限流规则，则处理业务请求额度即为该服务器基于该最大业务承载量和业务性能所给出在一时间段内可处理业务请求的总额度，在该时间段内，每收到一个业务请求，计数加“1”，直到达到该总额度，后续在该时间段内的业务请求均视为超限请求；而又如使用令牌桶算法的限流算法来配置限流规则，则处理业务请求额度即为该服务器生成令牌的速率以及服务器内存储令牌的桶的大小，最大业务承载量和处理业务性能越高，生成令牌的速率以及桶的容量则越大，当网关收到业务请求后，若无法从桶中得到令牌，则视为该业务请求为超限请求。

当然，以上仅为示例性的提出两种设置限流规则的方式，在其他实施例中，还可根据需求设置不同的限流规则，此处不进行具体限制。

本实施例中通过设置超限判断，保证服务器业务的正常运行，并在判断超限后，可基于上述方式减少超限交互所占用的带宽。

参考图6，图6为另一实施例中公开的一种限流场景下的带宽管理方法，该方法应用于图1中的终端100，该方法包括步骤S610至步骤S650，具体描述如下：

步骤S610：向网关发送用于请求业务信息的业务请求。

本示例中所提出的限流场景下的带宽管理方法可参考图3，在一实施例中，终端通过其上的应用向服务器发出业务请求，业务请求会先到达网关，以使网关对业务请求进行判断，确定该业务请求是否为超限请求。

步骤S630：接收网关针对业务请求返回的超限信息。

其中，超限信息为网关基于业务请求对应的服务器的业务承载量所生成的。

本实施例中，网关在收到业务请求后，会基于业务请求所请求的服务器的业务承载量判断是否超限，如果超限，网关则会拦截业务请求，并向终端返回超限信息。

本实施例中的超限信息基于HTTP协议生成，其包括响应体与响应头，为减少超限时网关交互的带宽，设置响应体为空，响应头设置与业务请求所对应的状态码，状态码与终端的本地存储有多个提示信息相互对应，即一个确定的状态码能对应确定的提示信息。

若网关判断为不超限，则将业务请求发送至服务器，以使服务器基于业务请求执行表达正常业务逻辑，并可返回业务信息。

步骤S650：基于超限信息从预先存储的提示信息中选择对应的目标提示信息，并将目标提示信息进行渲染展示。

本实施例中，终端在收到超限信息后，基于超限信息中的状态码，匹配本地保存的多个提示信息，然后将匹配成功的目标提示信息在终端界面进行渲染展示。

本实施例中，通过对响应体瘦身大幅降低了下行带宽消耗，带来了极大的带宽成本的节省，同时提升了用户体验，提高了用户留存。

参考图7，图7为另一实施例中公开的一种限流场景下的带宽管理方法，该方法可应用于图6中的步骤S610之前，该方法包括步骤S710至步骤S730，具体描述如下：

步骤S710：向网关发送提示信息获取请求，以使网关基于提示信息获取请求向终端返回超限提示页面与超限提示文案。

本实施例中，在进行限流场景下的带宽管理方法之前，可通过向网关发送提示信息获取请求，得到超限提示页面与超限提示文案。

具体地，网关内部设置有超限提示页面或超限提示文案，一般情况下，在终端向服务器发送业务请求时，网关将超限提示页面或超限提示文案生成为HTTP格式返回至终端，终端基于返回的HTTP格式数据在终端页面展示对应信息。

而本实施例中，则直接通过向网关发送提示信息获取请求，以使网关将其保存的超限提示页面与超限提示文案返回至终端，终端将其作为提示信息保存，后续网关在判断超限时，即可设置HTTP中的响应体为空，响应头包括状态码即可，大大减少带宽消耗，终端即可基于状态码从保存的提示信息中提取目标提示信息进行展示。

步骤S730：将超限提示页面与超限提示文案作为提示信息存储于本地。

本实施例中，网关基于提示信息获取请求向终端返回超限提示页面与超限提示文案同样通过HTTP协议实现，如此，网关基于提示信息获取请求返回的HTTP协议中的响应头应当也存在状态码，在将超限提示页面与超限提示文案作为提示信息存储于本地时，将该状态码与对应的提示信息进行关系映射，后续则可直接通过超限信息中的状态码在保存的多个提示信息中获取对应目标提示信息。

本实施例中，通过在终端中保存超限提示页面与超限提示文案的提示信息，网关在返回超限信息时可设置响应体为空，大大减少带宽成本。

示例性装置

在介绍了本公开示例性实施方式的方法之后，接下来，参考图8至图9对本公开示例性实施例的限流场景下的带宽管理装置进行说明。

参考图8，图8为一示例性实施例中所提出的限流场景下的带宽管理装置的结构图，该装置配置于图1中的网关200，具体包括：

业务请求接收模块810，配置为接收终端发送的业务请求；其中，业务请求用于向服务器请求业务信息；

超限判断模块830，配置为基于服务器的业务承载量确定业务请求是否为超限请求；

第一超限处理模块850，配置为若业务请求为超限请求，则拦截业务请求，并向终端返回超限信息，以使终端基于超限信息从预先存储的提示信息中提取对应的目标提示信息，并将目标提示信息进行渲染展示。

本实施例中公开的配置于图1中的网关200的限流场景下的带宽管理装置可减少网关所发送的超限信息的体量，降低带宽开销。

在本公开的一个实施例中，第一超限处理模块包括：

初始信息构建单元，配置为构建初始信息；其中，初始信息包括初始响应头与初始响应体；

超限信息获取单元，配置为将初始响应头设置为与业务请求所对应的状态码，并将初始响应体设置为空，以得到超限信息；其中，不同的状态码对应不同的提示信息；

目标提示信息展示单元，配置为将超限信息返回至终端，以使终端依据状态码提取对应的目标提示信息进行渲染展示。

在本公开的一个实施例中，超限判断模块包括：

业务量获取单元，配置为获取服务器的最大业务承载量，以及服务器当前处理的业务处理量；

第一超限判断单元，配置为若业务处理量大于或等于最大业务承载量，则业务请求为超限请求；

第一超限判断单元，配置为若业务处理量小于最大业务承载量，则业务请求为非超限请求。

在本公开的一个实施例中，超限判断模块包括：

业务信息发送单元，配置为若业务请求为非超限请求，则将业务请求发送至服务器，以使服务器基于业务请求返回业务信息。

参考图9，图9为一示例性实施例中所提出的限流场景下的带宽管理装置的结构图，该装置配置于图1中的终端100，具体包括：

业务请求发送模块910，配置为向网关发送用于请求业务信息的业务请求；

超限信息接收模块930，配置为接收网关针对业务请求返回的超限信息；其中，超限信息为网关基于业务请求对应的服务器的业务承载量所生成的；

第二超限处理模块950，配置为基于超限信息从预先存储的提示信息中选择对应的目标提示信息，并将目标提示信息进行渲染展示。

本实施例中公开的配置于图1中的终端100的限流场景下的带宽管理装置可基于超限信息从本地获取目标提示信息，减少网关所发送的超限信息的体量，降低带宽开销。

在本公开的一个实施例中，该配置于图1中的终端100的限流场景下的带宽管理装置还包括：

提示信息获取请求发送模块，配置为向服务器发送提示信息获取请求，以使服务器基于提示信息获取请求向终端返回超限提示页面与超限提示文案；

提示信息存储模块，配置为将超限提示页面与超限提示文案作为提示信息存储于本地。

需要说明的是，上述实施例所提供的限流场景下的带宽管理装置与上述实施例所提供的限流场景下的带宽管理方法属于同一构思，其中各个模块和单元执行操作的具体方式已经在方法实施例中进行了详细描述，此处不再赘述。

示例性介质

在介绍了本公开示例性实施方式的装置之后，接下来，参考图10对本公开示例性实施例的存储介质进行说明。

在一些实施例中，本公开的各个方面还可以实现为一种介质，其上存储有程序代码，当程序代码被设备的处理器执行时用于实现本说明书上述“示例性方法”部分中描述的根据本公开各种示例性实施例的限流场景下的带宽管理方法中的步骤。

参考图10所示，描述了根据本公开的实施例的用于实现上述限流场景下的带宽管理方法的程序产品1000，其可以采用便携式紧凑盘只读存储器(CD-ROM)并包括程序代码，并可以在终端设备，例如个人电脑上运行。然而，本公开的程序产品不限于此。

程序产品可以采用一个或多个可读介质的任意组合。可读介质可以是可读信号介质或者可读存储介质。可读存储介质例如可以为但不限于电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。可读存储介质的更具体的例子(非穷举的列表)包括：具有一个或多个导线的电连接、便携式盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。

计算机可读信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了可读程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。可读信号介质还可以是可读存储介质以外的任何可读介质。

可以以一种或多种程序设计语言的任意组合来编写用于执行本公开操作的程序代码，程序设计语言包括面向对象的程序设计语言—诸如Java、C++等，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中，远程计算设备可以通过任意种类的网络，包括局域网(LAN)或广域网(WAN)，连接到用户计算设备。

示例性计算设备

在介绍了本公开示例性实施方式的限流场景下的带宽管理方法、用于限流场景下的带宽管理方法装置以及存储介质之后，接下来，参考图11对本公开示例性实施方式的电子设备进行说明。

所属技术领域的技术人员能够理解，本公开的各个方面可以实现为系统、方法或程序产品。因此，本公开的各个方面可以具体实现为以下形式，即：完全的硬件实施例、完全的软件实施例(包括固件、微代码等)，或硬件和软件方面结合的实施例，这里可以统称为“电路”、“模块”或“系统”。

图11示出了适于用来实现本申请实施例的电子设备的计算机系统的结构示意图。

需要说明的是，图11示出的电子设备的计算机系统1100仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

如图11所示，计算机系统1100包括中央处理单元(Central Processing Unit，CPU)1101，其可以根据存储在只读存储器(Read-Only Memory，ROM)1102中的程序或者从存储部分1108加载到随机访问存储器(Random Access Memory，RAM)1103中的程序而执行各种适当的动作和处理，例如执行上述实施例中的方法。在RAM 1103中，还存储有系统操作所需的各种程序和数据。CPU 1101、ROM 1102以及RAM 1103通过总线1104彼此相连。输入/输出(Input/Output，I/O)接口1105也连接至总线1104。

以下部件连接至I/O接口1105：包括键盘、鼠标等的输入部分1106；包括诸如阴极射线管(Cathode Ray Tube，CRT)、液晶显示器(Liquid Crystal Display，LCD)等以及扬声器等的输出部分1107；包括硬盘等的存储部分1108；以及包括诸如LAN(Local AreaNetwork，局域网)卡、调制解调器等的网络接口卡的通信部分1109。通信部分1109经由诸如因特网的网络执行通信处理。驱动器1110也根据需要连接至I/O接口1105。可拆卸介质1111，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器1110上，以便于从其上读出的计算机程序根据需要被安装入存储部分1108。

特别地，根据本申请的实施例，上文参考流程图描述的过程可以被实现为计算机软件程序。例如，本申请的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的计算机程序。在这样的实施例中，该计算机程序可以通过通信部分1109从网络上被下载和安装，和/或从可拆卸介质1111被安装。在该计算机程序被中央处理单元(CPU)1101执行时，执行本申请的系统中限定的各种功能。

需要说明的是，本申请实施例所示的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读存储介质例如可以是电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(Erasable Programmable Read Only Memory，EPROM)、闪存、光纤、便携式紧凑磁盘只读存储器(Compact Disc Read-Only Memory，CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读存储介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的计算机程序。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的计算机程序可以用任何适当的介质传输，包括但不限于：无线、有线等等，或者上述的任意合适的组合。

附图中的流程图和框图，图示了按照本申请各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。其中，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

描述于本申请实施例中所涉及到的单元可以通过软件的方式实现，也可以通过硬件的方式来实现，所描述的单元也可以设置在处理器中。其中，这些单元的名称在某种情况下并不构成对该单元本身的限定。

本申请的另一方面还提供了一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如前的限流场景下的带宽管理方法。该计算机可读存储介质可以是上述实施例中描述的电子设备中所包含的，也可以是单独存在，而未装配入该电子设备中。

本申请的另一方面还提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述各个实施例中提供的限流场景下的带宽管理方法。

上述内容，仅为本申请的较佳示例性实施例，并非用于限制本申请的实施方案，本领域普通技术人员根据本申请的主要构思和精神，可以十分方便地进行相应的变通或修改，故本申请的保护范围应以权利要求书所要求的保护范围为准。

Claims (12)

1.一种限流场景下的带宽管理方法，其特征在于，应用于网关，所述方法包括：

接收终端发送的业务请求；其中，所述业务请求用于向服务器请求业务信息；

基于所述服务器的业务承载量确定所述业务请求是否为超限请求；

若所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

2.根据权利要求1所述的方法，其特征在于，所述拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的本地界面中提取对应的超限界面，并对所述超限界面进行渲染展示，包括：

构建初始信息；其中，所述初始信息包括初始响应头与初始响应体；

将所述初始响应头设置为与所述业务请求所对应的状态码，并将所述初始响应体设置为空，以得到所述超限信息；其中，不同的状态码对应不同的提示信息；

将所述超限信息返回至所述终端，以使所述终端依据所述状态码提取对应的目标提示信息进行渲染展示。

3.根据权利要求1所述的方法，其特征在于，所述基于所述服务器的业务承载量确定所述业务请求是否为超限请求，包括：

获取所述服务器的最大业务承载量，以及所述服务器当前处理的业务处理量；

若所述业务处理量大于或等于所述最大业务承载量，则所述业务请求为超限请求；

若所述业务处理量小于所述最大业务承载量，则所述业务请求为非超限请求。

4.根据权利要求3所述的方法，其特征在于，所述方法还包括：

若所述业务请求不是超限请求，则将所述业务请求发送至所述服务器，以使所述服务器基于所述业务请求返回业务信息。

5.一种限流场景下的带宽管理方法，其特征在于，应用于终端，所述方法包括：

向网关发送用于请求业务信息的业务请求；

接收所述网关针对所述业务请求返回的超限信息；其中，所述超限信息为所述网关在判断所述业务请求为超限请求所返回的，所述网关基于所述业务请求对应服务器的业务承载量确定所述业务请求是否为超限请求；

基于所述超限信息从预先存储的提示信息中选择对应的目标提示信息，并将所述目标提示信息进行渲染展示。

6.根据权利要求5所述的方法，其特征在于，在所述基于所述超限信息从预先存储的提示信息中选择对应的目标提示信息，并将所述目标提示信息进行渲染展示之前，所述方法还包括：

向所述服务器发送提示信息获取请求，以使所述服务器基于所述提示信息获取请求向所述终端返回超限提示页面与超限提示文案；

将所述超限提示页面与超限提示文案作为提示信息存储于本地。

7.一种限流场景下的带宽管理方法，其特征在于，包括：

终端向网关发送用于向服务器请求业务信息的业务请求；

所述网关基于所述服务器的业务承载量确定所述业务请求是否为超限请求；

若所述业务请求为超限请求，所述网关则拦截所述业务请求，并向所述终端返回超限信息；

所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

8.一种限流场景下的带宽管理装置，其特征在于，配置于网关，所述装置包括：

业务请求接收模块，配置为接收终端发送的业务请求；其中，所述业务请求用于向服务器请求业务信息；

超限判断模块，配置为基于所述服务器的业务承载量确定所述业务请求是否为超限请求；

第一超限处理模块，配置为若所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

9.一种限流场景下的带宽管理装置，其特征在于，配置于终端，所述装置包括：

业务请求发送模块，配置为向网关发送用于请求业务信息的业务请求；

超限信息接收模块，配置为接收网关针对所述业务请求返回的超限信息；其中，所述超限信息为所述网关基于所述业务请求对应的服务器的业务承载量所生成的；

第二超限处理模块，配置为基于所述超限信息从预先存储的提示信息中选择对应的目标提示信息，并将所述目标提示信息进行渲染展示。

10.一种限流场景下的带宽管理系统，其特征在于，包括：网关以及预先存储有提示信息的终端；其中，

所述终端用于发送向服务器请求业务信息的业务请求；

所述网关用于基于所述服务器的业务承载量确定所述业务请求是否为超限请求，当所述业务请求为超限请求，则拦截所述业务请求，并向所述终端返回超限信息，以使所述终端基于所述超限信息从预先存储的提示信息中提取对应的目标提示信息，并将所述目标提示信息进行渲染展示。

11.一种电子设备，其特征在于，包括：

处理器；以及

存储器，所述存储器上存储有计算机可读指令，所述计算机可读指令被所述处理器执行时实现如权利要求1-7中任意一项所述的方法。

12.一种计算机可读介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现1-7中任意一项所述的方法。

Images