一种流控计费方法、装置、系统、电子设备、介质及产品与流程

1.本公开涉及计算机技术领域，尤其涉及流量计费技术领域。


背景技术：

2.随着当下互联网人工智能(artificial intelligence，ai)技术的不断发展，ai产品形态也日新月异，越来越多的场景具有流控计费(flow control and billing)需求。流控计费，即流量控制与计费，指的是对用户的访问进行控制并计费，也就是根据用户访问所消耗的计费对象情况，允许用户访问或禁止用户访问，并按照用户访问所消耗的计费对象情况进行计费。
3.流控计费场景应用非常广泛。例如，当前的流控计费场景包括：ai语音识别流控计费场景、ai语音合成流控计费场景、ai文本翻译字符流控计费场景、ai视频直播审核流控计费场景和手机流量流控计费场景等。


技术实现要素：

4.本公开提供了一种流控计费方法、装置、系统、电子设备、介质及产品。
5.本公开实施例的第一方面，提供了一种流控计费方法，应用于流控计费模块，包括：
6.接收代理服务发送的开始begin请求，所述begin请求为所述代理服务在接收到终端发送的业务请求后发送，所述begin请求包括触发所述业务请求的用户标识和处理所述业务请求的本次预计费量；
7.判断所述本次预计费量、所述用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果；所述用户标识对应的已预计费量为所述用户标识对应的正在被处理的各业务请求的本次预计费量总和；
8.基于判断结果，确定是否响应所述业务请求，并基于所述业务请求的响应结果累加所述用户标识对应的已用量。
9.本公开实施例的第二方面，提供了一种流控计费方法，应用于代理服务，包括：
10.接收终端发送的业务请求，所述业务请求中包括触发所述业务请求的用户标识；
11.确定所述业务请求的本次预计费量；
12.向所述流控计费模块发送携带所述用户标识和所述预计费量的开始begin请求，以使得所述流控计费模块判断所述本次预计费量、所述用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果，基于判断结果，确定是否响应所述业务请求，并基于所述业务请求的响应结果累加所述用户标识对应的已用量，所述用户标识对应的已预计费量为所述用户标识对应的正在被处理的各业务请求的本次预计费量总和。
13.本公开实施例的第三方面，提供了一种流控计费装置，应用于流控计费模块，包括：
14.第一接收模块，用于接收代理服务发送的开始begin请求，所述begin请求为所述
代理服务在接收到终端发送的业务请求后发送，所述begin请求包括触发所述业务请求的用户标识和处理所述业务请求的本次预计费量；
15.判断模块，用于判断所述本次预计费量、所述用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果；所述用户标识对应的已预计费量为所述用户标识对应的正在被处理的各业务请求的本次预计费量总和；
16.累加模块，用于基于判断模块的判断结果，确定是否响应所述业务请求，并基于所述业务请求的响应结果累加所述用户标识对应的已用量。
17.本公开实施例的第四方面，提供了一种流控计费装置，应用于代理服务，包括：
18.第二接收模块，用于接收终端发送的业务请求，所述业务请求中包括触发所述业务请求的用户标识；
19.本次预计费量确定模块，用于确定所述业务请求的本次预计费量；
20.第二发送模块，用于向所述流控计费模块发送携带所述用户标识和所述预计费量的开始begin请求，以使得所述流控计费模块判断所述本次预计费量、所述用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果，基于判断结果，确定是否响应所述业务请求，并基于所述业务请求的响应结果累加所述用户标识对应的已用量，所述用户标识对应的已预计费量为所述用户标识对应的正在被处理的各业务请求的本次预计费量总和。
21.本公开实施例的第五方面，提供了一种流控计费系统，包括代理服务、流控计费模块和算子服务；
22.所述流控计费模块，用于执行第一方面中任一项所述的方法；
23.所述代理服务，用于执行第二方面中任一项所述的方法；
24.所述算子服务，用于处理业务请求。
25.本公开实施例的第六方面，提供了一种电子设备，包括：
26.至少一个处理器；以及
27.与所述至少一个处理器通信连接的存储器；其中，
28.所述存储器存储有可被所述至少一个处理器执行的指令，所述指令被所述至少一个处理器执行，以使所述至少一个处理器能够执行第一方面或者第二方面中任一项所述的方法。
29.本公开实施例的第七方面，提供了一种存储有计算机指令的非瞬时计算机可读存储介质，其中，所述计算机指令用于使所述计算机执行第一方面或者第二方面中任一项所述的方法。
30.本公开实施例的第八方面，提供了一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现第一方面或者第二方面中任一项所述的方法。
31.应当理解，本部分所描述的内容并非旨在标识本公开的实施例的关键或重要特征，也不用于限制本公开的范围。本公开的其它特征将通过以下的说明书而变得容易理解。
附图说明
32.附图用于更好地理解本方案，不构成对本公开的限定。其中：
33.图1是本公开实施例提供的一种流控计费方法的流程图；
34.图2a是相关技术中流控计费过程的示例性示意图；
35.图2b是本公开实施例中流控计费过程的示例性示意图；
36.图3是本公开实施例提供的一种doing心跳刷新方法的流程图；
37.图4是本公开实施例提供的一种处理定时任务的方法的流程图；
38.图5是本公开实施例提供的另一种流控计费方法的流程图；
39.图6是本公开实施例提供的另一种doing心跳刷新方法的流程图；
40.图7是本公开实施例提供的一种处理begin请求过程的示例性示意图；
41.图8是本公开实施例提供的一种处理end请求过程的示例性示意图；
42.图9是本公开实施例提供的一种处理doing请求过程的示例性示意图；
43.图10是本公开实施例提供的一种处理定时任务过程的示例性示意图；
44.图11是本公开实施例提供的一种流控计费装置的结构示意图；
45.图12是本公开实施例提供的另一种流控计费装置的结构示意图；
46.图13是本公开实施例提供的一种流控计费系统的结构示意图；
47.图14是用来实现本公开实施例的流控计费方法的电子设备的框图。
具体实施方式
48.以下结合附图对本公开的示范性实施例做出说明，其中包括本公开实施例的各种细节以助于理解，应当将它们认为仅仅是示范性的。因此，本领域普通技术人员应当认识到，可以对这里描述的实施例做出各种改变和修改，而不会背离本公开的范围和精神。同样，为了清楚和简明，以下的描述中省略了对公知功能和结构的描述。
49.随着当下互联网人工智能(artificial intelligence，ai)技术的不断发展，ai产品形态也日新月异，越来越多的场景具有流控计费需求。流控计费，即流量控制与计费，指的是对用户的访问进行控制并计费，也就是根据用户访问所消耗的计费对象情况，允许用户访问或禁止用户访问，并按照用户访问所消耗的计费对象情况进行计费。
50.流控计费场景应用非常广泛。例如，当前的流控计费(flow control and billing)场景包括：ai语音识别流控计费场景、ai语音合成流控计费场景、ai文本翻译字符流控计费场景、ai视频直播审核流控计费场景和手机流量流控计费场景等。
51.不同的流控计费场景下的计费对象不同，例如，搜索功能需要按搜索次数进行流控计费、音视频处理功能需要按音视频的时长进行流控计费、文本文档处理需要按文档包括的字数进行流控计费、手机流量的使用需要按字节流进行流控计费等。
52.虽然各种场景下的计费对象不同，但各计费对象都可以用数值表示，因此传统的流控计费方式是累加计费对象。
53.例如，当计费对象为次数时，传统的流控计费方式为：每次接收到用户发送的请求，将访问次数加1，并将当前的访问次数与上限额度进行比较。若达到上限额度，则禁止访问；否则允许访问，并生成一条访问次数加1的计费数据。
54.当计费对象为时长、字数、字节流等非次数的对象时，传统的流控计费方式为：每次接收到用户发送的请求，将计费对象用量加n，其中n为请求消耗的计费对象数量，并将计费对象用量与上限额度进行比较。若达到上限额度，则禁止访问；否则允许访问，并生成一条计费对象用量加n的计费数据。
55.这两种流控计费方式虽然能满足流控计费的基本需求，但是在高并发场景下难以保证流控计费的准确性，这是由于在高并发场景中，受限于网络的抖动以及处理用户发送的请求的算子服务的稳定性，难以保证算子服务每次处理请求都能处理成功，因此如何避免算子服务处理失败的情况仍进行了计费成为流控计费的难点。
56.为了应对该问题，目前有两种解决方案：
57.方案一为先行流控：流控计费模块在接收到用户发送的请求后，预估处理该请求所需消耗的计费对象数量是否满足额度要求，若满足则直接处理请求，并将预估的计费对象数量累加到已用计费对象数量中，并生成计费账单。后续发现用户发送的该请求处理失败时，再进行数据回滚操作，或者删除生成的计费账单。该方案既存在数据累加逻辑又存在数据回滚逻辑，导致整体逻辑复杂，使得流控计费模块的计算压力大，因此难以应用在高并发场景。而且用户可感知到请求处理失败产生的异常账单，因此一般场景均不适用。
58.方案二为后行流控：流控计费模块在接收到用户发送的请求后，判断用户是否为正常可用用户，其中正常可用用户为已用计费对象数量未超限的用户。若是正常可用用户，则直接处理请求，之后在请求处理成功后，再将处理请求所消耗的计费对象数量与已用计费对象数量进行累加，并生成计费账单。然后再判断已用计费对象数量是否超过上限额度，若超过，则将该用户设置为无额度不可用用户。若不超过，则保持用户为正常可用用户。该方案只针对已成功处理的请求进行计费，可以避免出现异常账单的情况，但是在高并发场景下，由于后行扣费对计费对象累加的滞后性，难以做到及时地流量控制，可能产生用户超额使用计费对象的情况。
59.可见，上述两种方案均不适用于高并发场景。为了在高并发场景下进行准确地流量控制，本公开实施例提供了一种流控计费方法。
60.首先对本公开实施例涉及的名词进行说明：
61.本次预计费量，表示若算子服务处理本次接收到的业务请求，预计需要消耗的计费对象数量。
62.已预计费量，表示算子服务正在处理的各业务请求的本次预计费量总和。
63.实际计费量，表示算子服务处理本次接收到的业务请求实际消耗的计费对象数量。
64.已成功计费量，表示算子服务处理本次接收到的业务请求的过程中，当前已成功消耗的计费对象数量。
65.可用额度，表示用户可以使用的计费对象数量上限。
66.本公开实施例提供的流控计费方法，可以应用于流控计费模块，如图1所示，该方法包括如下步骤：
67.s101、接收代理服务发送的开始(begin)请求。
68.其中，begin请求为代理服务在接收到终端发送的业务请求后发送，begin请求包括触发业务请求的用户标识和处理业务请求的本次预计费量。
69.一种实现方式中，用户通过终端向代理服务发送业务请求，代理服务接收到业务请求后，从业务请求中提取流量类型，其中，流量类型可以是音视频类型、文本类型或者搜索类型等。然后根据流量类型和计费方式之间的预设对应关系，确定提取的流量类型对应的计费方式。并按照确定的计费方式，确定业务请求的本次预计费量。例如，计费方式为按
照时长计费时，将业务请求包括的音视频数据的时长作为本次预计费量；又例如，计费方式为按照次数计费时，将确定本次预计费量为1。然后代理服务生成begin请求，其中，begin请求具体包括：触发业务请求的用户标识、本次预计费量、代理服务与终端之间的会话的会话号(session number，sn)、计费方式和计费接口身份标识号(identity document，id)。之后代理服务向流控计费模块发送begin请求。其中，会话号也可称为会话标识。
70.在本公开实施例中，代理服务用于代替流控计费模块与终端以及与算子服务交互。算子服务用于处理业务请求。
71.在本公开实施例中，算子服务可以存在多个，不同的算子服务用于实现不同的处理逻辑，计费接口id为调用算子服务的接口id，即每个算子服务对应一个计费接口id，代理服务可以从业务请求中提取计费接口id。
72.s102、判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果。其中，用户标识对应的已预计费量为用户标识对应的正在被处理的各业务请求的本次预计费量总和。
73.由于在高并发场景下，同一个用户可能发送多个业务请求，业务请求可并行处理，而且已用量在业务请求处理成功后才会累计。如果针对每个业务请求，都仅判断该业务请求的本次预计费量与已用量的总和是否超过可用额度，那么在并行处理多个业务请求时，由于业务请求未处理完成，不会累计已用量，使得每个业务请求的本次预计费量与已用量的总和不超过可用额度，各业务请求均会被正常处理。但是在处理完成后，累计已用量时，各业务请求的实际计费量均累加到已用量中，此时已用量可能超过可用额度，导致实际使用额度超限问题。
74.因此，本公开实施例中，针对每个业务请求，判断处理该业务请求的预计费量、正在处理的该用户的其他业务请求所需消耗的已预计费量以及该用户的已用量的总和是否超过可用额度，该方式下，即使同时处理的各业务请求均处理成功，累加已用量时，也不会导致已用量超过可用额度，从而减少实际使用额度超限的问题。
75.例如，假设按照次数计费，一个用户发送两个业务请求，该用户的可用额度为5，已用量为4，流控计费模块接收到第一个请求时，正常处理。但接收到第二个请求时，如果第一个请求正在处理，此时未累加已用量，使得已用量仍为4，那么对于第二个请求，仍利用本次预计费量1与已用量4的总和与可用额度5比较，得到不超过可用额度的结果，使得这第二个请求也会被处理，但是如果这两个请求均处理成功，则已用量累加到6，超过可用额度。
76.而本公开实施例中，流控计费模块接收到第一个请求时，正常处理。接收到第二个请求时，如果第一个请求正在处理，那么已预计量为1，此时判断本次预计费量1、已预计费量1和已用量4的总和是否超过可用额度5，得到超过可用额度的结果，使得第二个请求不会被处理。从而减少高并发场景下的超额使用的问题。
77.s103、基于判断结果，确定是否响应业务请求，并基于业务请求的响应结果累加用户标识对应的已用量。
78.一种实现方式中，在判断结果为是时，确定拒绝终端的业务请求，并对用户标识对应的已用量累加0，即对用户标识对应的已用量保持不变。在判断结果为否时，确定响应终端的业务请求，并按照业务请求的处理情况累加用户标识对应的已用量。
79.如图2a所示，传统的流控计费方案采用直路策略，即流控计费模块负责接收用户
发送的业务请求，并调用算子服务处理业务请求，将处理结果返回给用户，同时还需要进行流量控制和计费。可见这种方式中，流控计费模块负责的处理逻辑较多，因此所承载的处理压力较大，在高并发场景下随着流量压力的增大，难以保障流控计费模块的稳定性。
80.由图1所示的方法可以看出，本公开实施例将流量收发和流控计费分离，即如图2b所示，本公开实施例增加了代理服务，由代理服务代替流控计费模块与终端和算子服务交互，即由代理服务负责简单的逻辑处理，不做复杂的逻辑计算。由流控计费模块负责流量控制和计费。由于本公开实施例减少了流控计费模块的处理逻辑，即减少了流控计费模块承载的压力，从而能够适用于高并发场景。
81.而且，在本公开实施例中，流控计费模块在处理业务请求之前，先判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度，即判断处理业务请求是否会产生超额的问题，此时并未直接累加可用额度，而是后续根据业务请求的响应结果累加可用额度。因此即使业务请求处理失败，也不需要进行数据回滚或删除，即解决了先行流控的过早计费所造成的需要数据回滚或删除的问题。此外，由于本公开实施例在处理业务请求之前，先判断处理业务请求是否会产生超额问题，因此解决了后行流控超额判定的滞后性，从而能够适用于高并发场景。
82.在本公开的一个实施例中，上述s103基于判断结果，确定是否响应业务请求，并基于业务请求的响应结果累加用户标识对应的已用量的方式，包括以下步骤：
83.步骤一、若判断结果为是，则向代理服务发送begin失败响应，以使得代理服务向终端发送请求失败响应。
84.当本次预计费量、用户标识对应的已预计费量和已用量的总和大于可用额度，说明该用户当前正在被处理的业务请求如果均处理成功，可用额度与累加后的已预计量之间的差额小于本次预计费量，即处理当前的业务请求可能导致已用额度超限，因此拒绝该业务请求，向终端反馈请求失败。
85.步骤二、若判断结果为否，则将本次预计费量加入用户标识对应的已预计费量，并向代理服务发送begin成功响应，以使得代理服务调用算子服务处理业务请求，并在确定算子服务处理完成时向流控计费模块发送结束(end)请求。其中，end请求包括处理业务请求所消耗的实际计费量。
86.在本公开实施例中，当本次预计费量、用户标识对应的已预计费量和已用量的总和不大于可用额度，说明该用户当前正在被处理的业务请求如果均处理成功，可用额度与累加后的已预计量之间的差额大于等于本次预计费量，即处理当前的业务请求一般不会使得已用额度超限，因此可以处理接收到的业务请求。由于此时已判断出可以处理业务请求，业务请求即将被转发至算子服务处理，因此需要将该业务请求的本次预计费量累加到已预计费量中。
87.其中，流控计费模块针对begin请求的响应中可以包括状态标记，用于表示begin请求是否成功，方便代理服务通过该状态标记识别begin请求是否成功。例如，状态标记为1时表示begin请求成功，此时的响应称为begin成功响应；状态标记为0时表示begin请求失败，此时的响应称为begin失败响应。
88.代理服务接收到begin成功响应时，向算子服务转发接收到的业务请求，由算子服务处理业务请求，并向代理服务转发处理结果。其中，处理结果具体包括对业务请求的响应
结果以及处理业务请求所消耗的实际计费量。代理服务接收到算子服务的处理结果时，确定算子服务处理完成，并向流控计费模块发送end请求。而且，代理服务在接收到算子服务的处理结果时，还可以向终端反馈对业务请求的响应结果。
89.步骤三、接收代理服务发送的end请求，将实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
90.当流控计费模块接收到end请求时，表示算子服务当前已对业务请求处理完成，因此实际计费量需要累加到该用户的已用量中。同时，由于该业务请求已经处理完成，因此需要从该用户的已预计费量中删除本次预计费量。
91.采用上述方法，本公开实施例中，流控计费模块在处理业务请求之前，先基于本次预计费量进行流量控制，且本次预计费量没有直接累加到已用量中，而是在业务请求处理完成之后，才将实际计费量累加到已用量中。即本公开实施例结合了先行流控和后行流控，且先行流控时没有累加已用量，因此即使业务请求处理失败，也不需要进行数据回滚或删除，即解决了先行流控的过早计费所造成的需要数据回滚或删除的问题。后行流控可以按照请求处理成功时所消耗的实际计费量进行已用量的累加，而且在后行流控之前进行了先行流控，而先行流控可以减少流量超额使用的情况，即在准确地进行流量控制的基础上，解决了后行流控容易导致流量超额使用的问题。因此本公开实施例能够在高并发场景下进行准确地流量控制。
92.在本公开的一个实施例中，由于算子服务对业务请求可能处理成功，也可能处理失败。而无论处理成功还是失败，都可以统计算子服务处理业务请求的过程中所实际消耗的计费量，以便后续对算子服务的处理结果进行分析统计。因此，无论算子服务是否处理成功，处理结果中都需要包括处理业务请求所消耗的实际计费量。而为了让流控计费模块将处理成功的业务请求的实际计费量累加到已用量中，避免将处理失败的业务请求的实际计费量累加到已用量中，需要对实际计费量是否需要累加进行区分。本公开实施例设置了状态码(status_code)，状态码用于表示业务请求是否处理成功。代理服务可以从算子服务针对业务请求反馈的处理结果中提取状态码，并生成包括状态码的end请求。
93.因此，流控计费模块在接收到end请求后，需要判断是否需要累加实际计费量，包括以下步骤：判断end请求中的状态码是否表示业务请求处理成功，其中，end请求包括状态码。若否，则确定处理业务请求所消耗的实际计费量为0，并保持用户标识对应的已用量不变。若是，则从end请求中获取实际计费量，并执行步骤三中将实际计费量累加到用户标识对应的已用量中的步骤。
94.例如，当状态码为-1时，表示算子服务内部错误，即业务请求处理失败；当状态码为0时，表示算子服务对业务请求的计算正常，即业务请求处理成功。
95.本公开实施例中，通过状态码区分业务请求是否处理成功，从而使得流控计费模块能够通过状态码，区分实际计费量是否需要累加到已用量中。而且无论业务请求是否处理成功，end请求中均可以包括实际计费量，使得流控计费模块能够存储各业务请求的实际计费量，方便后续进行统计分析。
96.在本公开的一个实施例中，由于代理服务与流控计费模块之间的通信可能存在不稳定的情况，如果流控计费模块接收到至少两次代理服务针对同一个业务请求发送的end请求，那么流控计费模块可能错误地将end请求中的实际计费量连续多次累加到已用量中，
导致计费错误的情况。
97.为了减少这种错误，本公开实施例设置了begin请求和end请求中均包括代理服务与终端之间的会话的会话标识。
98.在s102判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度之前，流控计费模块还可以记录begin请求中的会话标识。
99.具体的，流控计费模块在接收到begin请求后，可以对begin请求进行数据解析及预处理，包括：从begin请求提取触发业务请求的用户标识、本次预计费量、sn、计费方式和计费接口id等数据，并将提取的各项数据对应存储。本公开实施例将从begin请求中提取的数据、已预计费量、已成功计费量、实际计费量和已用量统称为计费数据。
100.可选的，流控计费模块的存储方式可以为分布式远程字典服务(remote dictionary server，redis)，分布式redis中包括多个分片，流控计费模块可以基于用户标识，将同一个用户的计费数据存储在分布式redis的同一个分片中。这使得流控计费模块在查找计费数据时，方便从同一个分片中查找同一个用户的计费数据，相比于从多个分片中查找同一个用户的计费数据的方式，本公开实施例能够提高查找效率，从而适用于高并发场景。
101.在s102判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度之后，流控计费模块还可以在判断结果为是时，删除记录的会话标识。可以理解的，由于流控计费模块在判断出本次预计费量、用户标识对应的已预计费量和已用量的总和大于可用额度时，返回begin失败响应，此时业务请求不会被处理，因此删除记录的该会话标识。
102.在步骤三将实际计费量累加到用户标识对应的已用量中之前，流控计费模块还可以查询是否已记录end请求中的会话标识；若是，则删除记录的会话标识；若否，则忽略end请求。
103.可以理解的，当流控计费模块接收到end请求后，如果未记录end请求包括的会话标识，说明该会话标识对应的业务请求未被处理或者已处理结束，因此可以忽略该end请求。如果记录有end请求包括的会话标识，说明该会话标识对应的业务请求目前处理完成，需要进行计费，因此流控计费模块将实际计费量累加到用户标识对应的已用量中的同时，删除会话标识，避免对该会话标识对应的业务请求重复计费。
104.采用上述方法，流控计费模块通过会话标识，识别会话标识对应的业务请求的处理情况，从而减少对已处理结束的业务请求重复计费的情况。
105.在本公开的一个实施例中，为了进一步提升流控计费的准确性，本公开实施例基于长会话要求，在结合先行流控和后行流控的基础上，在begin请求和end请求之间增加doing心跳刷新。如图3所示，流控计费模块在上述步骤二中向代理服务发送begin成功响应之后，且在步骤三接收end请求之前，还可以执行以下步骤：
106.s301、接收代理服务发送的处理中(doing)请求。其中，doing请求包括算子服务当前处理业务请求所消耗的已成功计费量。
107.一种实现方式中，代理服务可以从算子服务中实时获取业务请求的已成功计费量，并周期性地向流控计费模块发送doing请求，以使得流控计费模块及时获得已成功计费量。
108.s302、从doing请求中获取已成功计费量，将用户标识对应的已预计费量中的本次预计费量更新为获取的已成功计费量，并判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度。若否，则执行s303；若是，则执行s304。
109.由于首次确定的本次预计费量是预估的使用量，并不是真实的使用量，而已成功计费量是真实的使用量，因此流控计费模块获取到已成功计费量时，可以将本次预计费量更新为已成功计费量，从而基于真实的使用量进行流量控制。且后续继续接收到doing请求时，可以再将本次预计费量更新为最新接收到的doing请求中包括的已成功计费量，从而实时地根据真实使用量进行流量控制。
110.即流控计费模块中记录的本次预计量为begin请求包括的预计费量，或者最新接收到的doing请求中包括的已成功计费量。
111.s303、向代理服务发送doing成功响应，以使得代理服务在确定算子服务处理完成时向流控计费模块发送end请求。其中end请求包括的实际计费量为算子服务对业务请求从开始处理到处理完成时总共消耗的计费量。
112.其中，流控计费模块针对doing请求的响应中可以包括doing状态标记，用于表示doing请求是否成功，方便代理服务通过doing状态标记识别doing请求是否成功。例如，doing状态标记为1时表示doing请求成功，此时的响应称为doing成功响应；doing状态标记为0时表示doing请求失败，此时的响应称为doing失败响应。
113.代理服务接收到doing成功响应时，表示当前处理业务请求还未出现超额问题，因此可以保持业务请求继续执行。
114.s304、向代理服务发送doing失败响应，以使得代理服务终止算子服务处理业务请求，并确定实际计费量为算子服务当前处理业务请求所消耗的已成功计费量，并发送携带确定的实际计费量的end请求。
115.代理服务接收到doing失败响应时，表示当前处理业务请求已出现了超额问题，需要终止处理业务请求，因此代理服务可以向算子服务发送终止通知消息，以使得算子服务停止处理业务请求，并将停止处理业务请求时，当前处理业务请求消耗的已成功计费量发送至代理服务。代理服务基于表示业务请求处理失败的状态码、以及接收到的已成功计费量，生成end请求，并向流控计费模块发送end请求。
116.流控计费模块接收到end请求后，按照上述步骤三中的相关步骤进行流量控制和计费。
117.采用上述方法，流控计费模块可以通过doing心跳机制，实时获取到算子服务处理业务请求的已成功计费量，而已成功计费量为真实的使用量，因此流量计费模块可以实时的根据真实使用量进行流量控制和计费。
118.需要说明的是，代理服务在发送doing请求之前，还可以判断计费方式是否为按照次数计费。当计费方式为按照次数计费时，终端与代理服务之间的会话为短连接会话，此时可以不执行图3所示的doing心跳机制，或者，在执行doing心跳机制时，设置每次传输的已成功计费量为1。
119.当计费方式不为按照次数计费时，终端与代理服务之间的会话一般为长连接会话，因此可以执行图3所示的doing心跳机制。
120.在本公开的一个实施例中，由于算子服务开始处理业务请求时，已成功计费量较
少，随着处理时长的增加，已成功计费量也会增加。因此流控计费模块在业务请求的处理前期接收到的已成功计费量较小，为了减少超额使用问题，还可以在已成功计费量较小时，暂不更新本次预计费量。即流控计费模块在s302从doing请求中获取已成功计费量之后，还可以执行以下步骤：
121.判断已成功计费量是否大于本次预计费量。若是，则执行s302中将用户标识对应的已预计费量中的本次预计费量更新为获取的已成功计费量的步骤。若否，则保持已预计费量不变，并执行s302中判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度的步骤。
122.采用上述方法，流控计费模块在已成功计费量小于等于本次预计费量时，暂不更新本次预计费量，即在已成功计费量较小时，不更新本次预计费量。如果已预计费量中的本次预计费量较小，可能导致当前基于已预计费量进行流量控制不准确，从而导致超额使用问题。因此本公开实施例在已成功计费量大于本次预计费量时，才将已预计费量中的本次预计费量更新为已成功计费量，减少超额使用的问题。而且业务请求的实际计费量可能大于预计费量，因此在已成功计费量大于本次预计费量时，对本次预计费量进行及时更新，也能减少预估的本次预计费量小于实际计费量而导致的超额使用问题。
123.在本公开的一个实施例中，由于网络或其他问题可能导致代理服务发送的end请求丢失，流控计费模块如果没有接收到end请求，则会一直保存通过begin请求获取的本次预计费量，而且也无法对业务请求进行正确地计费。
124.为了解决该问题，本公开实施例中在流控计费模块中设置定时垃圾回收(garbage collection，gc)任务，如图4所示，流控计费模块还可以执行以下步骤：
125.s401、若持续预设时长未接收到doing请求或者end请求，则判断是否获取过doing请求中携带的已成功计费量。若是，则执行s402；若否，则执行s403。
126.一种实现方式中，在上一次接收到begin请求或者doing请求开始，如果持续预设时长仍未接收到doing请求或者end请求，可以认为会话异常结束。此时可以判断之前是否从doing请求中获取过已成功计费量。
127.s402、确定实际计费量为最近一次从doing请求中获取的已成功计费量。
128.如果获取过doing请求中携带的已成功计费量，则最近一次从doing请求中获取的已成功计费量最接近处理业务请求所消耗的实际计费量，因此将实际计费量确定为最近一次从doing请求中获取的已成功计费量。
129.s403、确定实际计费量为0。
130.如果未获取过doing请求中携带的已成功计费量，则说明业务请求可能未被处理，因此确定实际计费量为0。
131.s404、将确定的实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
132.由于持续预设时长未接收到doing请求或者end请求，此时确定会话异常结束，且确定业务请求停止处理，因此需要进行计费，即将实际计费量累加到用户标识对应的已用量中。而且由于业务请求已停止处理，因此需要从用户标识对应的已预计费量中删除本次预计费量。
133.采用上述方法，流控计费模块可以通过定时gc任务，在会话异常结束时，进行及时
地计费，并及时清理本次预计费量，减少无效的预扣用量占用的存储资源。
134.在本公开的一个实施例中，在上述步骤三或者s404从用户标识对应的已预计费量中删除本次预计费量之后，流控计费模块还可以在实际计费量大于零时，基于实际计费量生成本次计费账单。
135.其中，计费账单包括：实际计费量、基于实际计费量计算得到的费用、以及时间戳等。其中时间戳可以是代理服务接收到业务请求的时间，或者业务请求处理完成的时间等。
136.本公开实施例可以在业务请求处理完成且实际计费量不为0时，再生成本次计费账单，即业务请求处理失败时，实际计费量为0，此时不会生成计费账单。因此避免了先行流控方案中先行生成计费账单，而导致业务请求出错后需要删除原本生成的计费账单的问题。
137.基于相同的发明构思，对应于图1所示的方法实施例，本公开实施例还提供了一种流控计费方法，应用于代理服务，如图5所示，该方法包括如下步骤：
138.s501、接收终端发送的业务请求。其中，业务请求中包括触发业务请求的用户标识。
139.s502、确定业务请求的本次预计费量。
140.其中，s501和s502的具体实现方式可参考上述s101中的描述，此处不再赘述。
141.s503、向流控计费模块发送携带用户标识和预计费量的begin请求，以使得流控计费模块判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果，基于判断结果，确定是否响应业务请求，并基于业务请求的响应结果累加用户标识对应的已用量。其中，用户标识对应的已预计费量为用户标识对应的正在被处理的各业务请求的本次预计费量总和。
142.其中，s503的具体实现方式可参考上述s102中的描述，此处不再赘述。
143.由图5所示的方法可以看出，本公开实施例将流量收发和流控计费分离，即如图2b所示，本公开实施例增加了代理服务，由代理服务代替流控计费模块与终端和算子服务交互，即由代理服务负责简单的逻辑处理，不做复杂的逻辑计算。由流控计费模块负责流量控制和计费。由于本公开实施例减少了流控计费模块的处理逻辑，即减少了流控计费模块承载的压力，从而能够适用于高并发场景。
144.而且，在本公开实施例中，流控计费模块在处理业务请求之前，先判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度，即判断处理业务请求是否会产生超额的问题，此时并未直接累加可用额度，而是后续根据业务请求的响应结果累加可用额度。因此即使业务请求处理失败，也不需要进行数据回滚或删除，即解决了先行流控的过早计费所造成的需要数据回滚或删除的问题。此外，由于本公开实施例在处理业务请求之前，先判断处理业务请求是否会产生超额问题，因此解决了后行流控超额判定的滞后性，从而能够适用于高并发场景。
145.在本公开的一个实施例中，在上述s503之后，代理服务还可以执行如下步骤：
146.步骤1、识别接收到的流控计费模块针对begin请求发送的响应是begin失败响应还是begin成功响应。
147.步骤2、若接收到流控计费模块发送的begin失败响应，则向终端发送请求失败响应。
148.如果接收到流控计费模块发送的begin失败响应，表示处理业务请求可能导致额度超限问题，因此向终端发送请求失败响应。
149.其中，步骤2的具体实现方式可参考上述步骤一中的描述，此处不再赘述。
150.步骤3、若接收到流控计费模块发送的begin成功响应，则向算子服务转发业务请求，以使得算子服务处理业务请求。
151.如果接收到流控计费模块发送的begin成功响应，表示处理业务请求一般不会导致额度超限问题，因此可以控制算子服务处理业务请求。
152.其中，步骤3的具体实现方式可参考上述步骤二中的描述，此处不再赘述。
153.步骤4、在确定算子服务对业务请求处理完成时，向流控计费模块发送end请求，以使得流控计费模块将end请求包括的处理业务请求所消耗的实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
154.其中，步骤4的具体实现方式可参考上述步骤二中的描述，此处不再赘述。
155.采用上述方法，本公开实施例中流控计费模块在处理业务请求之前，先基于本次预计费量进行流量控制，且本次预计费量没有直接累加到已计费量中，而是在业务请求处理完成之后，才将实际计费量累加到已计费量中。即本公开实施例结合了先行流控和后行流控，且先行流控时没有累加已计费量，因此即使业务请求处理失败，也不需要进行数据回滚或删除，既解决了先行流控的过早计费所造成的需要数据回滚或删除的问题。后行流控可以按照请求处理成功时所消耗的实际计费量进行已用量的累加，而且在后行流控之前进行了先行流控，而先行流控可以减少流量超额使用的情况，即在准确地进行流量控制的基础上，解决了后行流控容易导致流量超额使用的问题。因此本公开实施例能够在高并发场景下进行准确地流量控制。
156.在本公开的一个实施例中，为了进一步提升流控计费的准确性，在上述步骤3向算子服务转发业务请求之后，如图6所示，代理服务还可以执行以下步骤：
157.s601、实时从算子服务中获取当前处理业务请求所消耗的已成功计费量。
158.一种实现方式中，算子服务可以在处理业务请求的过程中，实时向代理服务发送前处理业务请求所消耗的已成功计费量。
159.s602、周期性地向流控计费模块发送携带已成功计费量的doing请求，以使得流控计费模块从doing请求中获取已成功计费量，将用户标识对应的已预计费量中的本次预计费量更新为获取的已成功计费量，并判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度，若否，则向代理服务发送doing成功响应，若是，则向代理服务发送doing失败响应。
160.其中，s602的具体实现方式可参考上述s302-s304中的描述，此处不再赘述。
161.s603、若接收到流控计费模块发送的doing失败响应，则终止算子服务处理业务请求，并确定实际计费量为算子服务当前处理业务请求所消耗的已成功计费量，基于确定的实际计费量生成end请求，并向流控计费模块发送生成的end请求。
162.在本公开实施例中，若接收到流控计费模块发送的doing成功响应，则表示当前处理业务请求还未出现超额问题，因此可以继续处理业务请求。
163.其中，s603的具体实现方式可参考上述s304中的描述，此处不再赘述。
164.采用上述方法，通过doing心跳机制，流控计费模块可以实时获取到算子服务处理
业务请求的已成功计费量，而已成功计费量为真实的使用量，因此流量计费模块可以实时的根据真实使用量进行流量控制和计费。
165.应用于代理服务的流控计费方法和应用于流控计费模块的流控计费方法中，相同的步骤的实现方式可相互参照。
166.以下结合应用场景，对本公开实施例提供的流控计费方法的具体过程进行说明：
167.参见图7，流控计费模块接收到begin请求后，对begin请求进行数据解析及预处理，具体为：从begin请求提取触发业务请求的用户标识、本次预计费量、sn、计费方式和计费接口id等数据，并将提取的各项数据对应记录。然后调用begin的lua脚本，begin的lua脚本的处理过程为图7中虚线框内的步骤。其中，lua是一个小巧的脚本语言，能够灵活地嵌入应用程序中，从而为应用程序提供灵活地扩展和定制功能。
168.通过调用begin的lua脚本，对该路会话的会话标识进行加锁，即记录sn，并判断加锁是否成功。若未成功，则向代理服务返回begin失败响应。若成功，则判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度。若大于，则进行锁释放，即删除记录的sn，并向代理服务返回begin失败响应。若不大于，则将本次预计费量加入已预计费量。存储会话数据信息，具体为将从begin请求中提取的数据存储到分布式redis。之后向代理服务返回begin成功响应。
169.参见图8，流控计费模块接收到end请求后，对end请求进行数据解析及预处理，具体为：从end请求中提取sn、status_code和实际计费量，并对应记录。然后判断status_code是否为0；若否，则设置实际计费量为0，若是，则调用end的lua脚本。end的lua脚本的处理过程为图8中虚线框内的步骤。
170.通过调用end的lua脚本，对该路会话的sn进行锁释放，并判断锁释放是否成功，若不成功，则删除sn对应的会话数据信息。若成功，则将提取的实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
171.然后判断实际计费量是否为非0，若否，则删除sn对应的会话数据信息。若是，则根据实际计费量生成本次计费账单，然后删除sn对应的会话数据信息。之后向代理服务返回end响应，表示对本次会话计费完成。
172.参见图9，流控计费模块接收到doing请求后，对doing请求进行数据解析和预处理，具体为：提取sn和已成功计费量，并对应记录。然后调用doing的lua脚本，doing的lua脚本的处理过程为图9中虚线框内的步骤。
173.通过调用doing的lua脚本，判断会话标识的锁是否存在，即是否记录有该sn。若不存在，则向代理服务返回doing失败响应。若存在，则更新最新处理时间为当前时间，并判断已成功计费量是否大于本次预计费量。若大于，则将用户标识对应的已预计费量中的本次预计费量更新为已成功计费量。若不大于，则保持已预计费量不变。之后判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度。若大于，则向代理服务返回doing失败响应。若不大于，则向代理服务返回doing成功响应。
174.参见图10，流控计费模块实时检测是否存在超时会话，即针对每个sn，判断上一次接收到该sn的begin或者doing请求后，是否持续预设时长未接收到包括该sn的doing请求或者end请求。若否，则返回继续检测。若是，则判断超时会话是否被doing标记过已成功计费量，即是否获取过doing请求中携带的已成功计费量。若未标记过，则设置实际计费量为
0。若标记过，则设置实际计费量为最近一次从doing请求中获取的已成功计费量。然后调用end的lua脚本。
175.通过调用end的lua脚本，对该路会话的sn进行锁释放，并判断锁释放是否成功，若不成功，则删除sn对应的会话数据信息。若成功，则将提取的实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
176.然后判断实际计费量是否为非0，若否，则删除sn对应的会话数据信息。若是，则根据实际计费量生成成本次计费账单，之后删除sn对应的会话数据信息。之后返回继续检测是否存在超时会话。
177.图7-图10的具体实现方式可参考上述相关描述。
178.基于相同的发明构思，对应于上述方法实施例，本公开实施例提供了一种流控计费装置，应用于流控计费模块，如图11所示，该装置包括：第一接收模块1101、判断模块1102和累加模块1103；
179.第一接收模块1101，用于接收代理服务发送的begin请求，begin请求为代理服务在接收到终端发送的业务请求后发送，begin请求包括触发业务请求的用户标识和处理业务请求的本次预计费量；
180.判断模块1102，用于判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果；用户标识对应的已预计费量为用户标识对应的正在被处理的各业务请求的本次预计费量总和；
181.累加模块1103，用于基于判断模块1102的判断结果，确定是否响应业务请求，并基于业务请求的响应结果累加用户标识对应的已用量。
182.在本公开的一个实施例中，累加模块1103，具体用于：
183.若判断模块1102的判断结果为是，则向代理服务发送begin失败响应，以使得代理服务向终端发送请求失败响应；
184.若判断模块1102的判断结果为否，则将本次预计费量加入用户标识对应的已预计费量，并向代理服务发送begin成功响应，以使得代理服务调用算子服务处理业务请求，并在确定算子服务处理完成时向流控计费模块发送结束end请求，end请求包括处理业务请求所消耗的实际计费量；
185.接收代理服务发送的end请求，将实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
186.在本公开的一个实施例中，end请求包括状态码，状态码用于表示业务请求是否处理成功；该装置还可以包括：实际计费量确定模块和获取模块；
187.判断模块1102，还用于在接收代理服务发送的end请求之后，判断end请求中的状态码是否表示业务请求处理成功；
188.实际计费量确定模块，用于若判断模块1102的判断结果为否，则确定处理业务请求所消耗的实际计费量为0，并保持用户标识对应的已用量不变；
189.获取模块，用于若判断模块1102的判断结果为是，则从end请求中获取实际计费量，并执行将实际计费量累加到用户标识对应的已用量中的步骤。
190.在本公开的一个实施例中，begin请求和end请求中均包括代理服务与终端之间的会话的会话标识；该装置还可以包括：记录模块、删除模块和查询模块；
191.记录模块，用于在判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度之前，记录begin请求中的会话标识；
192.删除模块，用于在判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度之后，若是，则删除记录的会话标识；
193.查询模块，用于在将实际计费量累加到用户标识对应的已用量中之前，查询是否已记录end请求中的会话标识；若是，则删除记录的会话标识；若否，则忽略end请求。
194.在本公开的一个实施例中，该装置还可以包括：第一发送模块；
195.第一接收模块1101，还用于在向代理服务发送begin成功响应之后，且在接收代理服务发送的end请求之前，接收代理服务发送的处理中doing请求，doing请求包括算子服务当前处理业务请求所消耗的已成功计费量；
196.判断模块1102，还用于从doing请求中获取已成功计费量，将用户标识对应的已预计费量中的本次预计费量更新为获取的已成功计费量，并判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度；
197.第一发送模块，用于若判断模块1102的判断结果为否，则向代理服务发送doing成功响应，以使得代理服务在确定算子服务处理完成时向流控计费模块发送end请求；
198.第一发送模块，还用于若判断模块1102的判断结果为是，则向代理服务发送doing失败响应，以使得代理服务终止算子服务处理业务请求，并确定实际计费量为算子服务当前处理业务请求所消耗的已成功计费量，并发送携带确定的实际计费量的end请求。
199.在本公开的一个实施例中，该装置还可以包括：调用模块；
200.判断模块1102，还用于在从doing请求中获取已成功计费量之后，判断已成功计费量是否大于本次预计费量；
201.调用模块，用于若判断模块1102的判断结果为是，则调用判断模块1102执行将用户标识对应的已预计费量中的本次预计费量更新为获取的已成功计费量的步骤；
202.调用模块，还用于若判断模块1102的判断结果为否，则保持已预计费量不变，并调用判断模块1102执行判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度的步骤。
203.在本公开的一个实施例中，该装置还可以包括：实际计费量确定模块和删除模块；
204.判断模块1102，还用于若持续预设时长未接收到doing请求或者end请求，则判断是否获取过doing请求中携带的已成功计费量；
205.实际计费量确定模块，用于若判断模块1102的判断结果为是，则确定实际计费量为最近一次从doing请求中获取的已成功计费量；
206.实际计费量确定模块，还用于若判断模块1102的判断结果为否，则确定实际计费量为0；
207.删除模块，用于将实际计费量确定模块确定的实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
208.在本公开的一个实施例中，该装置还可以包括：生成模块；
209.生成模块，用于在从用户标识对应的已预计费量中删除本次预计费量之后，在实际计费量大于零时，基于实际计费量生成本次计费账单。
210.基于相同的发明构思，对应于上述方法实施例，本公开实施例提供了一种流控计
费装置，应用于代理服务，如图12所示，该装置包括：第二接收模块1201、本次预计费量确定模块1202和第二发送模块1203；
211.第二接收模块1201，用于接收终端发送的业务请求，业务请求中包括触发业务请求的用户标识；
212.本次预计费量确定模块1202，用于确定业务请求的本次预计费量；
213.第二发送模块1203，用于向流控计费模块发送携带用户标识和预计费量的begin请求，以使得流控计费模块判断本次预计费量、用户标识对应的已预计费量和已用量的总和是否大于可用额度，得到判断结果，基于判断结果，确定是否响应业务请求，并基于业务请求的响应结果累加用户标识对应的已用量，用户标识对应的已预计费量为用户标识对应的正在被处理的各业务请求的本次预计费量总和。
214.在本公开实施例中，该装置还可以包括：识别模块；
215.识别模块，用于在向流控计费模块发送携带用户标识和预计费量的begin请求之后，识别接收到的流控计费模块针对begin请求发送的响应是begin失败响应还是begin成功响应；
216.第二发送模块1203，还用于若接收到流控计费模块发送的begin失败响应，则向终端发送请求失败响应；
217.第二发送模块1203，还用于若接收到流控计费模块发送的begin成功响应，则向算子服务转发业务请求，以使得算子服务处理业务请求；
218.第二发送模块1203，还用于在确定算子服务对业务请求处理完成时，向流控计费模块发送结束end请求，以使得流控计费模块将end请求包括的处理业务请求所消耗的实际计费量累加到用户标识对应的已用量中，并从用户标识对应的已预计费量中删除本次预计费量。
219.在本公开的一个实施例中，该装置还可以包括：获取模块；
220.获取模块，用于在向算子服务转发业务请求之后，实时从算子服务中获取当前处理业务请求所消耗的已成功计费量；
221.第二发送模块1203，还用于周期性地向流控计费模块发送携带已成功计费量的doing请求，以使得流控计费模块从doing请求中获取已成功计费量，将用户标识对应的已预计费量中的本次预计费量更新为获取的已成功计费量，并判断当前的已预计费量与用户标识对应的已用量的总和是否大于可用额度，若否，则向代理服务发送doing成功响应，若是，则向代理服务发送doing失败响应；
222.第二发送模块1203，还用于若接收到流控计费模块发送的doing失败响应，则终止算子服务处理业务请求，并确定实际计费量为算子服务当前处理业务请求所消耗的已成功计费量，基于确定的实际计费量生成end请求，并向流控计费模块发送生成的end请求。
223.基于相同的发明构思，对应于上述方法实施例，本公开实施例提供了一种流控计费系统，如图13所示，该系统包括代理服务1301、流控计费模块1302和算子服务1303；
224.流控计费模块1302，用于执行上述方法实施例中由流控计费模块执行的方法步骤；
225.代理服务1301，用于执行上述方法实施例中由代理服务执行的方法步骤；
226.算子服务1303，用于处理业务请求。
227.本公开的技术方案中，所涉及的计费数据的收集、存储、使用、加工、传输、提供和公开等处理，均符合相关法律法规的规定，且不违背公序良俗。
228.需要说明的是，本实施例中的业务请求并不是针对某一特定用户的请求，并不能反映出某一特定用户的个人信息。
229.根据本公开的实施例，本公开还提供了一种电子设备、一种可读存储介质和一种计算机程序产品。
230.图14示出了可以用来实施本公开的实施例的示例电子设备1400的示意性框图。电子设备旨在表示各种形式的数字计算机，诸如，膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置，诸如，个人数字处理、蜂窝电话、智能电话、可穿戴设备和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例，并且不意在限制本文中描述的和/或者要求的本公开的实现。
231.如图14所示，电子设备1400包括计算单元1401，其可以根据存储在只读存储器(rom)1402中的计算机程序或者从存储单元1408加载到随机访问存储器(ram)1403中的计算机程序，来执行各种适当的动作和处理。在ram 1403中，还可存储电子设备1400操作所需的各种程序和数据。计算单元1401、rom 1402以及ram 1403通过总线1404彼此相连。输入/输出(i/o)接口1405也连接至总线1404。
232.电子设备1400中的多个部件连接至i/o接口1405，包括：输入单元1406，例如键盘、鼠标等；输出单元1407，例如各种类型的显示器、扬声器等；存储单元1408，例如磁盘、光盘等；以及通信单元1409，例如网卡、调制解调器、无线通信收发机等。通信单元1409允许电子设备1400通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
233.计算单元1401可以是各种具有处理和计算能力的通用和/或专用处理组件。计算单元1401的一些示例包括但不限于中央处理单元(cpu)、图形处理单元(gpu)、各种专用的人工智能(ai)计算芯片、各种运行机器学习模型算法的计算单元、数字信号处理器(dsp)、以及任何适当的处理器、控制器、微控制器等。计算单元1401执行上文所描述的各个方法和处理，例如流控计费方法。例如，在一些实施例中，流控计费方法可被实现为计算机软件程序，其被有形地包含于机器可读介质，例如存储单元1408。在一些实施例中，计算机程序的部分或者全部可以经由rom1402和/或通信单元1409而被载入和/或安装到电子设备1400上。当计算机程序加载到ram 1403并由计算单元1401执行时，可以执行上文描述的流控计费方法的一个或多个步骤。备选地，在其他实施例中，计算单元1401可以通过其他任何适当的方式(例如，借助于固件)而被配置为执行流控计费方法。
234.本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(fpga)、专用集成电路(asic)、专用标准产品(assp)、芯片上系统的系统(soc)、复杂可编程逻辑设备(cpld)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括：实施在一个或者多个计算机程序中，该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释，该可编程处理器可以是专用或者通用可编程处理器，可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令，并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
235.用于实施本公开的方法的程序代码可以采用一个或多个编程语言的任何组合来编写。这些程序代码可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器或控制器，使得程序代码当由处理器或控制器执行时使流程图和/或框图中所规定的功能/操作被实施。程序代码可以完全在机器上执行、部分地在机器上执行，作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
236.在本公开的上下文中，机器可读介质可以是有形的介质，其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的程序。机器可读介质可以是机器可读信号介质或机器可读储存介质。机器可读介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备，或者上述内容的任何合适组合。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(ram)、只读存储器(rom)、可擦除可编程只读存储器(eprom或快闪存储器)、光纤、便捷式紧凑盘只读存储器(cd-rom)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
237.为了提供与用户的交互，可以在计算机上实施此处描述的系统和技术，该计算机具有：用于向用户显示信息的显示装置(例如，crt(阴极射线管)或者lcd(液晶显示器)监视器)；以及键盘和指向装置(例如，鼠标或者轨迹球)，用户可以通过该键盘和该指向装置来将输入提供给计算机。其它种类的装置还可以用于提供与用户的交互；例如，提供给用户的反馈可以是任何形式的传感反馈(例如，视觉反馈、听觉反馈、或者触觉反馈)；并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
238.可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如，作为数据服务器)、或者包括中间件部件的计算系统(例如，应用服务器)、或者包括前端部件的计算系统(例如，具有图形用户界面或者网络浏览器的用户计算机，用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如，通信网络)来将系统的部件相互连接。通信网络的示例包括：局域网(lan)、广域网(wan)和互联网。
239.计算机系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端-服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器，也可以为分布式系统的服务器，或者是结合了区块链的服务器。
240.应该理解，可以使用上面所示的各种形式的流程，重新排序、增加或删除步骤。例如，本公开中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行，只要能够实现本公开公开的技术方案所期望的结果，本文在此不进行限制。
241.上述具体实施方式，并不构成对本公开保护范围的限制。本领域技术人员应该明白的是，根据设计要求和其他因素，可以进行各种修改、组合、子组合和替代。任何在本公开的精神和原则之内所作的修改、等同替换和改进等，均应包含在本公开保护范围之内。