CN116916259A - 一种信息转发方法、装置、设备及计算机可读存储介质 - Google Patents

Abstract

本申请公开了一种信息转发方法、装置、设备及计算机可读存储介质，该信息转发方法包括：获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中；接收各个客户端发送的待转发信息；从所述远程字典服务中获取所述各个客户端的限流模型的限流参数，并基于所述各个客户端的限流模型的限流参数转发所述各个客户端的待转发信息。如此，能够基于各个客户端的限流模型来对各个客户端发送的待转发信息进行限流，有效管控客户端的流量，避免转发信息时的拥堵现象，提升信息转发的成功率。

Description

一种信息转发方法、装置、设备及计算机可读存储介质

技术领域

本申请涉及互联网(Internet Technology，IT)技术领域，涉及但不限于一种信息转发方法、装置、设备及计算机可读存储介质。

背景技术

目前，IT系统发送短信主要包括如下两种方式，一种是基于各种各样的短信通道供应商，每个系统通过单独调用短信通道供应商提供的应用程序界面(ApplicationProgram Interface，API)，定制化的开发对应的获取发送短信的请求参数和发送短信的接口，以实现短信消息的发送；第二种是基于对接好的多个短信通道供应商和消息中间件Redis、Kafka等，实现消息转发服务，各个IT系统对接消息转发公共服务，短信消息发送的准确性和安全性则完全依赖于这个公共的消息服务，对消息服务的能力有着很高的要求。

上述相关技术均没有高效的高并发情境下的解决方案，针对短信通道供应商的每秒事务数(Transaction Per Second，TPS)，无法有效管控接入的IT系统客户端的流量，从而导致消息发送拥堵甚至发送失败。

发明内容

有鉴于此，本申请实施例提供一种信息转发方法、装置、设备及计算机可读存储介质。

本申请实施例的技术方案是这样实现的：

本申请实施例提供一种信息转发方法，所述方法包括：

获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中；

接收各个客户端发送的待转发信息；

从所述远程字典服务中获取所述各个客户端的限流模型的限流参数，并基于所述各个客户端的限流模型的限流参数转发所述各个客户端的待转发信息。

本申请实施例提供一种信息转发装置，所述信息转发装置包括：

第一获取模块，用于获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中；

接收模块，用于接收各个客户端发送的待转发信息；

第一转发模块，用于从所述远程字典服务中获取所述各个客户端的限流模型的限流参数，并基于所述各个客户端的限流模型的限流参数转发所述各个客户端的待转发信息。

本申请实施例提供一种信息转发设备，所述信息转发设备包括：

处理器；以及

存储器，用于存储可在所述处理器上运行的计算机程序；

其中，所述计算机程序被处理器执行时实现上述的信息转发方法。

本申请实施例提供一种计算机可读存储介质，所述计算机存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行上述信息转发方法。

本申请实施例提供一种信息转发方法、装置、设备及计算机可读存储介质，该信息转发方法包括：先获取多个客户端的限流模型，再将各个限流模型的限流参数存储至远程字典服务中；接着，接收各个客户端发送的待转发消息；然后，从远程字典服务中获取各个客户端的限流模型的限流参数；最后，基于各个客户端的限流模型的限流参数转发各个客户端的待转发信息。这样一来，每个客户端均有对应的限流模型，则能够基于各个客户端的限流模型来对各个客户端发送的待转发信息进行针对性的限流，有效管控各个客户端的流量，避免转发信息时的拥堵现象，提升信息转发的成功率。针对各个客户端执行有针对性的合理限流，还能够节约网络带宽资源。

附图说明

在附图(其不一定是按比例绘制的)中，相似的附图标记可在不同的视图中描述相似的部件。附图以示例而非限制的方式大体示出了本文中所讨论的各个实施例。

图1为本申请实施例提供的信息转发方法的第一种实现流程示意图；

图2为本申请实施例提供的构建限流模型的一种实现流程示意图；

图3为本申请实施例提供的信息转发方法的第二种实现流程示意图；

图4为本申请实施例提供的信息转发方法的第三种实现流程示意图；

图5为本申请实施例提供的群发的一种实现流程示意图；

图6为本申请实施例提供的应用服务侧在使用消息转发服务的一种实现流程示意图；

图7为本申请实施例提供的权限校验的一种实现流程示意图；

图8为本申请实施例提供的消息服务侧进行消息处理的一种实现流程示意图；

图9为本申请实施例提供的模板模式下更换新的短信网关的一种实现流程示意图；

图10为本申请实施例提供的配置消息转发服务的一种实现流程示意图；

图11为本申请实施例提供的利用漏斗算法对客户端进行流控的一种实现流程示意图；

图12为本申请实施例提供的不同通道下短信群发的实现策略的一种实现流程示意图；

图13为本申请实施例提供的短信上行工作的一种实现流程示意图；

图14为本申请实施例提供的信息转发装置的一种组成结构示意图；

图15为本申请实施例提供的信息转发设备的一种组成结构示意图。

具体实施方式

为了使本申请的目的、技术方案和优点更加清楚，下面将结合附图对本申请作进一步地详细描述，所描述的实施例不应视为对本申请的限制，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例，都属于本申请保护的范围。

在以下的描述中，涉及到“一些实施例”，其描述了所有可能实施例的子集，但是可以理解，“一些实施例”可以是所有可能实施例的相同子集或不同子集，并且可以在不冲突的情况下相互结合。

在以下的描述中，所涉及的术语“第一\第二\第三”仅仅是区别类似的对象，不代表针对对象的特定排序，可以理解地，“第一\第二\第三”在允许的情况下可以互换特定的顺序或先后次序，以使这里描述的本申请实施例能够以除了在这里图示或描述的以外的顺序实施。

除非另有定义，本文所使用的所有的技术和科学术语与属于本申请的技术领域的技术人员通常理解的含义相同。本文中所使用的术语只是为了描述本申请实施例的目的，不是旨在限制本申请。

为了更好地理解本申请实施例提供的信息转发方法，首先对以下两种相关技术中的信息转发方法以及存在的缺点进行说明。

在第一种相关技术中，通过配置实现多短信平台调用，面对开放者，基于多种短信平台，通过数据库配置调用多短信平台以提升短信业务的健壮性。首先确定短信平台调用地址和方式，然后通过数据库配置参数和调用方式，最后通过配置根据优先级确定短信平台调用顺序。该通过配置实现多短信平台调用的方法，不仅能通过简单的数据库配置实现对多家第三方短信平台的调用，减少了代码修改过程和工作量，还能够整合多短信平台，配置优先级，控制平台使用顺序，进而保障了短信业务的准确性和稳定性。但该方法并没有提供高效的高并发情境下的解决方案。

在第二种相关技术中，会获取各网络短信平台对应的配置文档数据，建立数据分析算法，根据数据分析算法对该配置文档数据进行计算，将计算结果作为文档分析数据，根据该文档分析数据生成各网络短信平台对应的配置文档模板；根据应用服务指令确定网络短信平台，根据该网络短信平台选择对应的配置文档模板，通过该配置文档模板对该网络短信平台进行配置；将待发送短信发送至短信平台，记录短信的发送结果。该发明通过对市面上的各短信平台对应的配置文档进行分析，根据分析结果来生成不同网络短信平台的配置文档模板，通过这个配置文档模板，技术人员可以快速对接短信平台。但该方法依旧存在上述无法有效管控接入的客户端的流量。

基于相关技术所存在的问题，本申请实施例提供一种信息转发方法，本申请实施例提供的方法可以通过计算机程序来实现，该计算机程序在执行的时候，完成本申请实施例提供的信息转发方法。在一些实施例中，该计算机程序可以在信息转发设备中的处理器执行，其中，该信息转发设备可以为服务器，该服务器可以包括多个网关。图1为本申请实施例提供的信息转发方法的一种实现流程，如图1所示，该信息转发方法包括：

步骤S101，获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务(REmote DIctionary Server，Redis)中。

这里，每个客户端均对应有各自的限流模型，服务器会提前构建好各个客户端的限流模型。在进行信息转发的时候，可触发模型获取指令，并基于该模型获取指令获取提前构建好的各个客户端的限流模型。

在本申请实施例中，多个客户端的数量一般至少为两个，也即服务器与至少两个客户端相连，用于转发至少两个客户端发出的信息。示例性的，多个客户端的数量可以为17个、18个、19个等。

在实际实现的时候，限流模型可以为基于漏斗算法(Leaky Bucket)的模型、基于令牌桶算法的模型等。

在本申请实施例中，限流模型包括限流参数，服务器正是按照限流模型中的限流参数转发信息，为了提升存取速度，本申请实施例是将各个限流模型的限流参数存储至Redis中。

步骤S102，接收各个客户端发送的待转发信息。

这里，服务器与各个客户端之间建立有通信连接，基于此，服务器能够基于已建好的通信连接来接收各个客户端发送的待转发信息。

在实际实现的时候，待转发信息可以为字符类型的信息、图片类型的信息、音频类型的信息等。

在一些实施例中，各个客户端还与服务器中的网关完成关联配置，其中，一个客户端可以与一个网关进行关联，一个客户端还可以与多个网关进行关联。

步骤S103，从远程字典服务中获取各个客户端的限流模型的限流参数，并基于各个客户端的限流模型的限流参数转发各个客户端的待转发信息。

这里，远程字典服务中的键值与各个客户端一一对应，可先确定出客户端对应的键值，再基于键值获取各个客户端的限流模型的限流参数。

在本申请实施例中，限流参数可以包括转发速率，基于此，服务器在实际转发各个客户端的待转发信息的时候，是基于各个客户端的限流模型的转发速率，转发各个客户端的待转发信息。

示例性的，假设A客户端对应的限流模型的转发速率为10个/秒，B客户端对应的限流模型的转发速率为12个/秒，则针对A客户端发送的待转发信息，服务器以10个/秒的速率来转发待转发信息；而针对B客户端发送的待转发信息，服务器则以12个/秒的速率来转发待转发信息。

在实际实现的时候，服务器能够并行转发各个客户端的待转发信息。

本申请实施例提供一种信息转发方法，该信息转发方法包括：先获取多个客户端的限流模型，再将各个限流模型的限流参数存储至远程字典服务中；接着，接收各个客户端发送的待转发消息；然后，从远程字典服务中获取各个客户端的限流模型的限流参数；最后，基于各个客户端的限流模型的限流参数转发各个客户端的待转发信息。这样一来，每个客户端均有对应的限流模型，则能够基于各个客户端的限流模型来对各个客户端发送的待转发信息进行针对性的限流，有效管控各个客户端的流量，避免转发信息时的拥堵现象，提升信息转发的成功率。针对各个客户端执行有针对性的合理限流，还能够节约网络带宽资源。

在一些实施例中，限流参数还包括总容量个初始转发速率，在执行上述步骤S101“获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中”之前，服务器会提前基于限流参数构建各个客户端的限流模型，图2为本申请实施例提供的构建限流模型的一种实现流程，如图2所示，构建限流模型包括以下步骤S001至步骤S003：

步骤S001，初始化各个客户端的总容量。

这里，可结合客户端的性能指标以及与客户端相关联的网关的性能指标，从预设的总容量中选取各个客户端的总容量，示例性的，总容量可以为200、300等。

在本申请实施例中，总容量是指限流模型所能容纳的最大容量。

步骤S002，获取各个客户端的历史运行信息，并基于各个客户端的历史运行信息确定各个客户端的初始转发速率。

这里，可从各个客户端的运行日志中获取各个客户端的历史运行信息，该历史运行信息可以包括客户端发送信息的历史类型、历史速率等，也即，该历史运行信息能够反应客户端在历史时段的实际运行状况。

在本申请实施例中，可从历史速率中确定出最大历史速率，再将最大历史速率确定为初始转发速率；也可将历史速率对应的平均速率确定为初始转发速率；还可以将最大历史速率与第一预设系数的乘积确定为初始转发速率。

在一些实施例中，在确定各个客户端的初始转发速率的时候，还可结合客户端所关联的网关的转发性能，以使得网关能够支持该初始转发速率。

步骤S003，基于各个客户端的总容量和各个客户端的初始转发速率，构建各个客户端的限流模型。

这里，将初始化后各个客户端的总容量赋值于各个客户端对应的限流模型的总容量，将各个客户端的初始转发速率赋值于各个客户端对应的限流模型的转发速率。如此，完成对各个客户端的限流模型的构建。

在本申请实施例中，通过上述步骤S001至步骤S003，可通过初始化各个客户端的总容量，还可通过各个客户端的历史运行信息确定各个客户端的初始转发速率，从而完成对各个客户端的限流模型的构建。以便基于各个客户端的限流模型实现对各个客户端的限流。

基于上述实施例，限流参数还包括针对各个客户端的上次转发时刻，服务器在进行信息转发的时候，如图3所示，可基于以下步骤S1031至步骤S1039进行信息转发，也即，上述步骤S103中的“基于各个客户端的限流模型的限流参数转发各个客户端的待转发信息”可通过以下步骤S1031至步骤S1039实现。

步骤S1031，获取当前时刻和各个客户端的上次转发时刻。

这里，服务器中包括时钟装置，可从时钟装置中获取当前时刻。此外，还可从服务器运行日志中获取针对各个客户端的上次转发时刻，也即，服务器上一次转发各个客户端对应的信息的时刻。

步骤S1032，确定当前时刻和各个上次转发时刻之间的时间间隔。

这里，分别对当前时刻与各个上次转发时刻进行作差处理，得到当前时刻和各个转发时刻之间的时间间隔，也即，当前时刻距离上一次转发的时长。

步骤S1033，基于各个客户端的初始转发速率确定各个客户端的间隔阈值。

这里，可分别对单位时间与各个初始转发速率进行做商处理，得到各个客户端的间隔阈值，也即各个客户端进行两次信息转发之间的时间间隔，也可认为各个客户端进行一次信息转发所用的时长。

示例性的，假设A客户端对应的限流模型的转发速率为10个/秒，B客户端对应的限流模型的转发速率为12个/秒，则A客户端的间隔阈值为1/12秒，B客户端的间隔阈值为0.1秒。

步骤S1034，当第一目标客户端的时间间隔达到第一目标客户端对应的间隔阈值时，基于第一目标客户端的初始转发速率，转发第一目标客户端的待转发信息。

这里，会判断各个客户端的时间间隔与对应的客户端的间隔阈值之间的大小关系，如果判断出第一目标客户的时间间隔达到第一目标客户端对应的间隔阈值，则表征当前达到转发第一目标客户端的信息，也即，此时可以转发第一目标客户端发送的待转发信息。

在本申请实施例中，是基于该第一目标客户端的初始转发速率来转发第一目标客户端发出的待转发信息。也即，是通过恒定的第一目标客户端的初始转发速率来转发信息，从而实现对第一目标了客户端的信息限流。

步骤S1035，更新远程字典服务中的第一目标客户端的当前剩余容量。

在本申请实施例中，由于转发是将限流模型中存储队列或者限流模型中存储池中的待转发信息转发出去，则会引起限流模型中当前剩余容量的变化，则会及时利用变化后的当前剩余容量，来更新远程字典服务中的第一目标客户端对应的当前剩余容量。

步骤S1036，从远程字典服务中获取当前剩余容量。

这里，可从远程字典服务中实时读取各个客户端的当前剩余容量。

步骤S1037，基于各个客户端的初始转发速率确定各个客户端的单次转发量。

这里，可分别对各个客户端的初始转发速率与预设转发次数进行做商处理，得到各个客户端的单次转发量。

示例性的，假设A客户端的初始转发速率为10个/秒，且A客户端每秒转发5次，则可确定A客户端的单次转发量为2个。

步骤S1038，当存在大于当前剩余容量的目标单次转发量时，确定目标单次转发量对应的第二目标客户端。

这里，可比较各个客户端的当前剩余容量和对应的各个客户端的单次转发量，如果存在大于当前剩余容量的目标单次转发量时，表征限流模型中存储队列或者限流模型中存储池的空间即将全部放置信息，则确定目标单次转发量对应的第二目标客户端。

步骤S1039，向第二目标客户端发送超限提醒消息。

此时，第二目标客户端的当前剩余容量大于第二目标客户端的目标单次转发量，表征如果第二目标客户端继续发送待转发信息，则第二目标客户端的限流模型中的存储队列(或者限流模型中存储池)中的信息将发送外溢现象，则向第二目标客户端发送超限提醒消息，以使得第二目标客户端及时了解服务器的转发情况，使得第二目标客户端减缓或者延后发送待转发信息，从而避免待转发消息发生外溢。

在本申请实施例中，通过上述步骤S1031至步骤S1039，可确定出当前时刻与各个上次转发时刻之间的时间间隔，当第一目标客户端的时间间隔达到第一目标客户端的间隔阈值的时候，则基于第一目标客户端的初始转发速率转发其发送的待转发信息，并且实时更新远程字典服务中第一目标客户端的当前剩余容量。此外，还确定各个客户端的单次转发量，当第二目标客户端的当前剩余容量小于第二目标客户端的目标单次转发量的时候，表征第二目标客户端发送待转发信息速度较高，即将引发信息外溢，则及时向第二目标客户端发送超限提醒消息，以使得第二目标客户端及时了解服务器的转发情况，使得第二目标客户端减缓或者延后发送待转发信息，从而避免待转发消息发生外溢。

在一些实施例中，还可通过调大转发速率的方式来避免待转发信息发生外溢，也即在上述步骤S1038“当存在大于当前剩余容量的目标单次转发量时，确定目标单次转发量对应的第二目标客户端”之后，如图4所示，还可以执行以下步骤S1039’至步骤S10311’：

步骤S1039’，当第二目标客户端的初始转发速率小于速率阈值时，基于当前剩余容量的和目标单次转发量生成速率调整指令。

这里，速率阈值即为转发速率的上限值，该速率阈值可由服务器的性能参数来确定。

在本申请实施例中，可先通过大小比较的方法比较第二目标客户端的初始转发速率与速率阈值之间的大小关系，如果第二目标客户端的初始转发速率小于速率阈值，则可触发生成速率调整指令。

在生成速率调整指令的时候，确定第二目标客户端的目标单次转发量与第二目标客户端的当前剩余容量之间的差值，再将差值与第二预设系数的乘积作为第二目标客户端的初始转发速率对应的增大量；最后生成携带该第二目标客户端的初始转发速率对应的增大量的调整指令。

在一些实施例中，如果第二目标客户端的初始转发速率等于速率阈值，则表征此时第二目标客户端的初始转发速率已经为转发速率的上限值，无法再调大第二目标客户端的初始转发速率，则直接结束流程。

步骤S10310’，基于调整指令调整第二目标客户端的初始转发速率，得到第二目标客户端的更新后的转发速率。

这里，可通过解析调整指令来获得第二目标客户端的初始转发速率对应的增大量，再基于增大量来调大第二目标客户端的初始转发速率，从而得到第二目标客户端的调大后的转发速率，也即第二目标客户端的更新后的转发速率。

步骤S10311’，利用第二目标客户端的更新后的转发速率更新远程字典服务。

这里，在任一客户端对应的转发速率发生变化或者更新的时候，则会利用变化后或者更新后的转发速率更新远程字典服务中对应的信息，以确保远程字典服务中的信息保持最新。

在本申请实施例中，通过上述步骤S1039’至步骤S10311’，在第二目标客户端的目标单次转发量大于第二目标客户端的当前剩余容量，且第二目标客户端的初始转发速率小于速率阈值的时候，可调大第二目标客户端的初始转发速率，得到第二目标客户端的更新后的转发速率，从而避免待转发信息发生外溢，确保平稳、高效地转发待转发信息。

在一些实施例中，该信息转发方法还支持转发群发信息，基于此，在待转发信息为向至少两个目的地址发送的信息时，也即待转发信息为群发信息的时候，如图5所示，可执行以下步骤S501至步骤S504：

步骤S501，当待转发信息为向至少两个目的地址发送的信息时，获取至少两个目的地址的数量。

这里，待转发信息中携带有目的地址，可通过解析待转发信息来获取其中携带的目的地址；接着，来确定目的地址的数量。

步骤S502，判断至少两个目的地址的数量是否大于数量阈值。

这里，数量阈值可以为默认值，也可以为自定义设置值，示例性的，数量阈值可以为100、200、300等，该数量阈值的设置范围可以为100至500。

在本申请实施例中，可通过大小比较的方法确定至少两个目的地址的数量与数量阈值的大小关系，在至少两个目的地址的数量小于或者等于数量阈值的情况下，表征群发数量在设置值之内，进入步骤S503；而在至少两个目的地址的数量大于数量阈值的情况下，表征群发数量超出设置值，则进入步骤S504；

步骤S503，向目的地址转发待转发信息。

这里，至少两个目的地址的数量小于或者等于数量阈值，则向所有目的地址转发待转发信息。

步骤S504，从目的地址中确定出选中目的地址，并向选中目的地址转发待转发信息。

这里，至少两个目的地址的数量大于数量阈值，此时并不支持向所有目的地址转发待转发信息，则可从目的地址中随机选择出选中目的地址，也可按照顺序将前数量阈值个目的地址确定为选中目的地址，其中，选中目的地址的数量等于数量阈值。

在一些实施例中，服务器还可对选中目的地址进行拆分，拆分为多个组，并按照分组结果进行转发。

在本申请实施例中，通过上述步骤S501至步骤S504，能够支持群发信息的转发，在两个目的地址的数量小于或者等于数量阈值的情况下，直接向所有目的地址转发待转发信息；否则先确定数量等于数量阈值的选中目的地址，再向选中目的地址转发待转发信息，从而提升转发的灵活性。

在一些实施例中，在上述步骤S102“接收各个客户端发送的待转发信息”的同时，还会对各个客户端发送的所有信息进行进行权限校验和预设字段过滤，并将通过权限校验且不包含预设字段的信息确定为待转发信息，而将其他信息可以确定为不转发信息，那么，在执行上述步骤S102的同时或者执行上述步骤S102之前，还存在对信息的识别，在实际实现的时候，可通过以下步骤S01至步骤S03来实现对信息的识别：

步骤S01，获取各个客户端发送的信息。

这里，是指接收各个客户端发送的所有信息。

步骤S02，依次对信息进行权限校验和预设字段过滤，得到校验通过且不包含预设字段的信息。

这里，会对每个信息分别进行权限校验及预设字段过滤，其中，权限校验可以包括白名单过滤、地址过滤、认证信息过滤、入参拦截过滤、客户端流量校验等。预设字段可以为预设敏感字段。

在本申请实施例中，在信息通过权限校验之后，可对该信息进行预设字段过滤，如果该信息中不包含预设字段，则得到校验通过且不包含预设字段的信息，此时进入步骤S03。

在一些实施例中，如果信息没有通过权限校验或者信息包括预设字段，表征该信息不符合规则，则直接结束流程。

步骤S03，将校验通过且不包含预设字段的信息确定为待转发信息。

这里，校验通过且不包含预设字段的信息为符合规则的信息，能够进行转发，基于此，则将其确定为待转发信息。

在本申请实施例中，通过上述步骤S01至步骤S03，会对各个客户端发送的信息进行权限校验及预设字段过滤，会舍弃没有通过权限校验或者包括预设字段的信息；而将校验通过且不包含预设字段的信息确定为待转发信息，并转发待转发信息。如此，提升系统的安全性。

基于上述实施例，本申请实施例再提供一种信息转发方法，该信息转发方法的实现可以基于消息中间件消息队列(RabbitMQ)与Leaky Bucket算法结合的、利用模板模式的消息转发微服务模型。以待转发信息为短信为例，该方法结合开发模式中的模板模式，对短信对接代码进行了结构化的解耦，可在不影响原有代码的基础上实现短信网关替换，解决了当接入短信通道厂商发生变更时，需要更换大量消息转发平台代码以适配新的短信通道的问题；该消息转发模型不仅实现了消息服务在大流量下的服务端错峰流控，同时增加了基于Leaky Bucket的客户端流控算法，利用Redis缓存中间件，实现对“消息转发”服务调用方客户端的流量控制，能够避免因用户请求次数超出限制导致的异常问题，避免当出现短信或者邮件发送不成功时用户无感知，提高了“消息服务”的稳定性，提供了高并发情境下提供消息转发服务的解决方案。

本申请实施例提供的模型还引入了模板短信发送和邮件转发服务，实现了多类型消息的转发功能，提高了代码复用能力，降低了人工成本；同时该模型提供了短信上行能力，增加了虚拟(Mock)账号发送方式，新增客户端签名管理和模板文件管理，接入本消息服务的系统能够通过管理员账号查询全部的消息发送记录和消息发送状态，使得消息发送状态可追溯，极大的提高了消息发送的安全性。

本申请实施例的信息转发方法是基于消息中间件RabbitMQ与Leaky Bucket，下面首先对应用服务侧发送短信的基本流程进行说明，图6与图7分别描述了应用服务侧使用发送信息接口流程与服务侧进行消息处理流程。其中，应用服务侧对应上述客户端，服务侧对应上述服务器。

图6描述了应用服务侧在使用消息转发服务时的流程图，本申请实施例采用了RabbitMQ消息队列，实现了请求的异步处理，加快了响应速度，提高了接口请求响应性能，图6包括以下步骤S601至步骤S606：

步骤S601，消息发送请求。

步骤S602，请求消息转发服务接口。

这里，应用服务侧调用消息转发服务中的消息发送接口，实现消息的发送，这里以短信为例，需要应用服务侧提供安全校验码以及手机号、短信内容、报备过的系统签名等内容。

步骤S603，权限校验。

这里，应用服务侧请求信息到达服务侧后，服务侧需根据应用服务侧提供的安全校验信息对请求的安全性进行校验，本申请实施例的服务请求头部(header)需要携带分配应用标识(application identification，AppId)、通用唯一识别码(Universally UniqueIdentifier，UUID)、当前时间(time)和信息摘要算法(Message Digest Algorithm MD5，MD5)，如校验失败，则返回应用服务侧，也即进入步骤S606；如校验成功则继续后续操作，也即进入步骤S604。其中，UUID一次有效，MD5为分配的32位令牌(token)+UUID+时间前8位。

在本申请实施例中，图7描述了请求本申请实施例中消息服务的权限控制流程，包括请求客户端的网际互连协议(Internet Protocol，IP)校验、请求地址的校验、认证信息有无校验、如上所述的请求header参数校验以及Tps校验，当以上全部校验无误后，客户端方可正常请求发送消息的服务API，进行消息的发送。其中，请求客户端的IP校验即为步骤S6032白名单过滤；请求地址的校验即为步骤S6033地址过滤；认证信息有无校验即为步骤S6034认证信息过滤；请求header参数校验即为步骤S6035入参拦截校验；Tps校验即为步骤S6036客户端流控。此外，权限检验流程还包括：步骤S6031客户端发送消息请求，以及步骤S6037处理结束。

步骤S604，敏感字段过滤。

这里，消息转发服务侧提供敏感字段过滤功能，对应用服务侧的消息发送内容进行敏感字段过滤，提高了消息内容的安全性，如消息内容被检测到存在敏感字段，则返回应用服务侧。其中，敏感字段对应上述预设字段。如此，实现敏感信息过滤、黑白名单过滤和权限控制，提高安全保障。

在本申请实施例中，如果请求消息中不包含敏感字段，也即通过敏感字段过滤，则进入步骤S605；否则进入步骤S606。

步骤S605，存至消息队列。

这里，消息转发服务侧将应用服务侧的请求内容推入对应的消息队列中，本申请实施例共使用了4个消息队列，分别处理普通验证码短信、普通非验证码短信、上行短信和邮件，实现请求异步解耦，提高了接口响应速度。其中，消息转发服务侧对应上述服务器。

在一些实施例中，可也使用多个消息队列，该多个消息队列的数量可以为6个、7个、8个等，该多个消息队列的数量是根据实际的业务情况来确定。

步骤S606，返回结束。

这里是指返回应用服务侧，结束流程。

在本申请实施例中，通过上述步骤S601至步骤S606，引入消息队列中间件RabbitMQ实现处理解耦，设置多个消息队列提高了接口响应效率。

图8为本申请实施例提供的消息服务侧进行消息处理时的流程图，包括以下步骤S801至步骤S806：

步骤S801，消息队列捕获到请求队列内容。

这里，程序实时监控消息队列的状态，若消息队列中存在未处理的队列元素，则开始进入本处理流程。

步骤S802，多线程处理队列内容。

这里，为了提高并发处理消息效率，此处采用多线程进行消息处理，可根据服务器性能动态调整线程数量，提高消息处理速度。

步骤S803，获取应用服务消息配置信息.

这里，根据应用服务侧提供的安全校验码获取应用服务侧的消息配置信息，既第二步应用服务侧配置的消息配置信息。

步骤S804，按配置信息进行信息处理.

这里，根据步骤S803得到的配置信息，进行消息发送配置。此处以短信发送为例进行说明，若获取到用户存在“测试消息网关”的配置，根据相关依赖取得t_message_config_sm表中“测试消息网关”的对应配置类名“smsTestService”，消息服务侧依据“smsTestService”获取动态实例化消息发送实现类SmsTestService，调用SmsTestService类中的sendShortMessage()方法实现消息发送，若消息发送失败可按应用服务配置的其他短信网关进行发送尝试。

步骤S805，记录发送结果。

这里，用来记录消息发送成功或者失败的历史记录，用来进行记录查询与其他数据分析工作。经统计分析后，还可生成可视化显示界面。

步骤S806，处理结束。

在本申请实施例中，通过以上步骤S801至步骤S806，在消息处理时利用多线程技术提高了消息转发服务的并行处理能力，提出了互联网模式下高并发场景中高效的解决方案。还支持消息发送记录的查询，能够为业务系统的消息发送提供统一安全保障

本申请实施例将软件开发中模板模式与微服务能力二者高度结合，提出了基于模板模式的消息转发服务能力平台。下面说明实现轻量级短信对接与应用服务消息配置的操作，本申请实施例利用模板模式对短信发送配置类进行了抽象，可轻量级的实现短信网关厂商对接，图9展示了模板模式下更换新的短信网关的主要流程，包括：

步骤S901，增加新短信网关。

步骤S902，编写Service类实现SmBaseService接口。

这里，SmBaseService接口定义了通用短信发送的基本方法，新增短信通道厂商接口配置实现类需编写对接接口类并且要实现SmBaseService接口的节本方法。

步骤S903，实现sendShortMessage()接口。

这里，实现了SmBaseService接口的实现类需要实现sendShortMessage()方法，此方法入参为HashMap类型，内容包括短信发送的手机号、内容等信息，新增的对接实现类需要根据厂商对接接口的要求实现接口对接，实现sendShortMessage发送短信方法。

步骤S904，添加数据库短信网关配置。

在本申请实施例中，需在数据库t_message_config_sm表中增加短信网关厂商类型，包括短信厂商名称，以及实现类名等，其中smClassName为新增实现类名，首字母小写，此字段用来实现与程序中对接实现类的关联。

步骤S905，结束。

在申请实施例中，结合开发模式中的模板模式，对短信对接代码进行了结构化的解耦，可实现轻量级短信网关对接，在不影响原有代码的基础上实现短信网关新增与替换。

在一些实施例中，应用服务在使用消息网关时需要执行操作步骤，图10为配置消息转发服务的主要流程，包括：

步骤S1001，客户个性化配置消息网关。

步骤S1002，查找可用的短信网关配置。

这里，查找t_message_config_sm表共有多少可选择的短信网关，可供应用服务进行选择。

步骤S1003，进行关联配置。

这里，对于选中的网关，可填写服务商提供的账号密码，实现自主结算，也可选择不填账号密码，实现消息转发服务平台结算；这里可选择多个短信网关进行配置；每个短信网关可配置优先级，实现按优先级发送短信。

步骤S1004，配置邮箱信息。

这里，消息转发服务也可提供邮件发送接口，这里需要应用服务填写发送邮件相关的配置，如发送邮箱账号、密码、协议等。

步骤S1005，结束。

本申请实施例引入邮件转发服务和模板消息发送服务，根据客户端上传的模板获取消息内容，后期也可引入其他类型消息的转发，实现了多类型消息的转发功能，提高了代码复用能力，降低了人工消耗。

本申请实施例基于消息中间件RabbitMQ与Leaky Bucket实现高并发情况下的消息转发服务模型，图11为Leaky Bucket对客户端流控的算法流程。包括以下步骤S1101至步骤S1106：

步骤S1101，Java编码实现漏斗(Funnel)。

这里，定义漏斗容量capability、漏斗流水速率leakingRate、漏斗剩余空间leftQuota和上次漏斗流水时间leakingTs，实现Leaky Bucket。

步骤S1102，Redis参数存取。

这里，为准确记录每个客户端的漏斗参数，设置合理限流，从Redis获取leftQuota和leakingT，剩余空间处理完成后将参数值重新放置于Redis。

步骤S1103，剩余空间处理.

这里，获取系统当前时间，根据从Redis获取的leakingTs，做差获取到时间间隔，再根据流水速率得到漏斗腾出的空间，并作边界值处理。

步骤S1104，流水设置。

这里，根据Redis中客户端键值(Key)，进行剩余空间的处理，只要剩余空间大于每次流水量，剩余空间则去除每次流水量，同时返回客户端标识true，标识可以流量正常可以请求，反之提示客户端调用流量超出限制。

步骤S1105，定义isActionAllowed方法。

这里，以客户端AppId为key，配合参数capability和leakingRate实现Funnel定义isActionAllowed方法，用于客户端请求限制。

步骤S1106，客户端调用。

本申请实施例根据不同的客户端发送短信的要求设置不同的Tps，通过设置数据库参数大小和redis缓存读取的方式实现客户端流控限制。利用实现的该算法即可完成对客户端的流量控制，当超出限制，会提示给客户端，避免流量超限导致问题。通过实现LeakyBucket算法，同时结合缓存中间件Redis和数据库设置不同客户端的Tps大小，实现对请求消息服务的客户端的流量控制。

在一些实施例中，基于消息中间件RabbitMQ与Leaky Bucket，可以设置多个短信通道供应商，同时可以支持对应不同的群发短信发送方法并实现不同的控制策略，图12为本申请实施例提供的不同通道下短信群发的实现策略，包括：

步骤S1201，群发短信请求。

步骤S1202，获取短信通道类型。

这里，首先根据数据库中配置的短信通道，按照优先级通过反射的方法获取当前执行的通道类型。

步骤S1203，内部通道限制单次群发数量.

这里，以公司内部短信通道为例，内部手机号发送单次不超过100人，超出部分无法发送。

步骤S1204，外部通道拆分号码发送。

这里，以外部短信通道联动优势为例，限制群发数量单次为10人，则将该类型下群发的短信进行每10人拆分，依次进行群发短信发送，即把超出10人的数量拆分为多个10人，逐次进行发送。

步骤S1205，群发结束。

在本申请实施例中，通过上述步骤S1201至步骤S1205，能够支持不同短信通道通过特定算法实现不同的短信群发策略。

在一些实施例中，本方法支持短信上行功能，满足特定场景下的移动端审批等功能，图13为本申请实施例提供的一种短信上行工作的流程图，包括：

步骤S1301，上行请求。

这里，上行请求是指应用服务侧向服务侧发送请求。

步骤S1302，短信下行发送请求码。

这里，发送上行回复短信的前提是下行短信发送了上行请求码code，通过本发明的下行接口生成对应的4位随机码发送至用户手机，并经处理存至上行中间表up_middle，用于后续处理。

步骤S1303，上行回复。

这里，该步骤由用户通过手机回复对应的短信，请求消息服务的传送(deliver)接口，用于处理后续逻辑。

步骤S1304，判断是否为特殊回复。

这里，通过回复内容在特殊回复表up_special查询记录，若可以查询到记录则判断为上行特殊回复，然后根据查询到的回调地址进行请求和消息发送，也即进入步骤S1305；若查不到特殊记录内容，则判断为非特殊回复，根据上行中间表up_middle存储的回调地址进行请求和消息发送，也即进入步骤S1306。

步骤S1305，使用特殊回调地址发送短信。

步骤S1306，使用上行中间表回调地址发送短信。

步骤S1307，保存发送记录。

这里，请求结束后即时保存发送的消息记录，同时更新消息上行中间表up_middle中对应的回调状态，0为初始化，1为回调成功，2为回调失败，同时更新时间信息，完成上行处理。

步骤S1308，上行结束。

如此，能够支持短信上行和文件管理，能够为业务系统的消息发送提供统一安全保障。

基于前述的实施例，本申请实施例提供一种信息转发装置，该装置包括的各模块、以及各模块包括的各单元，可以通过计算机设备中的处理器来实现；当然也可通过相应的逻辑电路实现；在实施的过程中，处理器可以为中央处理器(Central Processing Unit，CPU)、微处理器(Microprocessor Unit，MPU)、数字信号处理器(Digital SignalProcessing，DSP)或现场可编程门阵列(Field Programmable Gate Array，FPGA)等。

本申请实施例再提供一种信息转发装置，图14为本申请实施例提供的信息转发装置的组成结构示意图，如图14所示，所述信息转发装置1400包括：

第一获取模块1401，用于获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中；

接收模块1402，用于接收各个客户端发送的待转发信息；

第一转发模块1403，用于从所述远程字典服务中获取所述各个客户端的限流模型的限流参数，并基于所述各个客户端的限流模型的限流参数转发所述各个客户端的待转发信息。

在一些实施例中，所述限流参数包括总容量和初始转发速率，所述信息转发装置1400还包括：

初始化模块，用于初始化所述各个客户端的总容量；

第二获取模块，用于获取所述各个客户端的历史运行信息，并基于所述各个客户端的历史运行信息确定所述各个客户端的初始转发速率；

构建模块，用于基于所述各个客户端的总容量和所述各个客户端的初始转发速率，构建所述各个客户端的限流模型。

在一些实施例中，所述限流参数还包括上次转发时刻，所述第一转发模块1403包括：

第一获取子模块，用于获取当前时刻和所述各个客户端的上次转发时刻；

第一确定子模块，用于确定所述当前时刻和各个上次转发时刻之间的时间间隔；

第二确定子模块，用于基于所述各个客户端的初始转发速率确定所述各个客户端的间隔阈值；

第一转发子模块，用于当第一目标客户端的时间间隔达到所述第一目标客户端对应的间隔阈值时，基于所述第一目标客户端的初始转发速率，转发所述第一目标客户端的待转发信息。

在一些实施例中，所述限流参数还包括剩余容量，所述第一转发模块1403还包括：

第二获取子模块，用于从所述远程字典服务中获取当前剩余容量；

第三确定子模块，用于基于所述各个客户端的初始转发速率确定所述各个客户端的单次转发量；

第四确定子模块，用于当存在大于所述当前剩余容量的目标单次转发量时，确定所述目标单次转发量对应的第二目标客户端；

发送子模块，用于向所述第二目标客户端发送超限提醒消息。

在一些实施例中，所述第一转发模块1403还包括：

生成子模块，用于当所述第二目标客户端的初始转发速率小于速率阈值时，基于所述当前剩余容量的和所述目标单次转发量生成速率调整指令；

调整子模块，用于基于所述调整指令调整所述第二目标客户端的初始转发速率，得到所述第二目标客户端的更新后的转发速率；

更新子模块，用于利用所述第二目标客户端的更新后的转发速率更新所述远程字典服务。

在一些实施例中，所述信息转发装置1400还包括：

第三获取模块，用于当所述待转发信息为向至少两个目的地址发送的信息时，获取所述至少两个目的地址的数量；

第二转发模块，用于当所述至少两个目的地址的数量小于或者等于数量阈值时，向所述目的地址转发所述待转发信息；

第三转发模块，用于当所述目的地址的数量大于所述数量阈值时，从所述目的地址中确定出选中目的地址，并向所述选中目的地址转发所述待转发信息，其中，所述选中目的地址的数量等于所述数量阈值。

在一些实施例中，所述信息转发装置1400还包括

第四获取模块，用于获取所述各个客户端发送的信息；

校验模块，用于依次对所述信息进行权限校验和预设字段过滤，得到校验通过且不包含预设字段的信息；

确定模块，用于将所述校验通过且不包含预设字段的信息确定为所述待转发信息。

需要说明的是，本申请实施例信息转发装置的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本装置实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

需要说明的是，本申请实施例中，如果以软件功能模块的形式实现上述的信息转发方法，并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：U盘、移动硬盘、只读存储器(Read OnlyMemory，ROM)、磁碟或者光盘等各种可以存储程序代码的介质。这样，本申请实施例不限制于任何特定的硬件和软件结合。

相应地，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现上述实施例中提供的信息转发方法。

本申请实施例提供一种信息转发设备，图15为本申请实施例提供的信息转发设备的组成结构示意图，如图15所示，所述信息转发设备1500包括：一个处理器1501、至少一个通信总线1502、用户接口1503、至少一个外部通信接口1504和存储器1505。其中，通信总线1502配置为实现这些组件之间的连接通信。其中，用户接口1503可以包括显示屏，外部通信接口1504可以包括标准的有线接口和无线接口。其中，所述处理器1501配置为执行存储器中存储的信息转发方法的程序，以实现以上述实施例提供的信息转发方法。

以上信息转发设备和存储介质实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请信息转发设备和存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

这里需要指出的是：以上存储介质和信息转发设备实施例的描述，与上述方法实施例的描述是类似的，具有同方法实施例相似的有益效果。对于本申请存储介质和信息转发设备实施例中未披露的技术细节，请参照本申请方法实施例的描述而理解。

应理解，说明书通篇中提到的“一个实施例”或“一实施例”意味着与实施例有关的特定特征、结构或特性包括在本申请的至少一个实施例中。因此，在整个说明书各处出现的“在一个实施例中”或“在一实施例中”未必一定指相同的实施例。此外，这些特定的特征、结构或特性可以任意适合的方式结合在一个或多个实施例中。应理解，在本申请的各种实施例中，上述各过程的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。上述本申请实施例序号仅仅为了描述，不代表实施例的优劣。

需要说明的是，在本文中，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者装置不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者装置所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括该要素的过程、方法、物品或者装置中还存在另外的相同要素。

在本申请所提供的几个实施例中，应该理解到，所揭露的设备和方法，可以通过其它的方式实现。以上所描述的设备实施例仅仅是示意性的，例如，所述单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，如：多个单元或组件可以结合，或可以集成到另一个系统，或一些特征可以忽略，或不执行。另外，所显示或讨论的各组成部分相互之间的耦合、或直接耦合、或通信连接可以是通过一些接口，设备或单元的间接耦合或通信连接，可以是电性的、机械的或其它形式的。

上述作为分离部件说明的单元可以是、或也可以不是物理上分开的，作为单元显示的部件可以是、或也可以不是物理单元；既可以位于一个地方，也可以分布到多个网络单元上；可以根据实际的需要选择其中的部分或全部单元来实现本申请实施例方案的目的。

另外，在本申请各实施例中的各功能单元可以全部集成在一个处理单元中，也可以是各单元分别单独作为一个单元，也可以两个或两个以上单元集成在一个单元中；上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

或者，本申请上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本申请实施例的技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台AC执行本申请各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、ROM、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本申请的实施方式，但本申请的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本申请揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本申请的保护范围之内。因此，本申请的保护范围应以所述权利要求的保护范围为准。

Claims (10)

1.一种信息转发方法，其特征在于，所述方法包括：

获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中；

接收各个客户端发送的待转发信息；

从所述远程字典服务中获取所述各个客户端的限流模型的限流参数，并基于所述各个客户端的限流模型的限流参数转发所述各个客户端的待转发信息。

2.根据权利要求1中所述的方法，其特征在于，所述限流参数包括总容量和初始转发速率，所述方法还包括：

初始化所述各个客户端的总容量；

获取所述各个客户端的历史运行信息，并基于所述各个客户端的历史运行信息确定所述各个客户端的初始转发速率；

基于所述各个客户端的总容量和所述各个客户端的初始转发速率，构建所述各个客户端的限流模型。

3.根据权利要求2中所述的方法，其特征在于，所述限流参数还包括上次转发时刻，所述方法还包括：

获取当前时刻和所述各个客户端的上次转发时刻；

确定所述当前时刻和各个上次转发时刻之间的时间间隔；

基于所述各个客户端的初始转发速率确定所述各个客户端的间隔阈值；

当第一目标客户端的时间间隔达到所述第一目标客户端对应的间隔阈值时，基于所述第一目标客户端的初始转发速率，转发所述第一目标客户端的待转发信息。

4.根据权利要求2中所述的方法，其特征在于，所述限流参数还包括剩余容量，所述方法还包括：

从所述远程字典服务中获取当前剩余容量；

基于所述各个客户端的初始转发速率确定所述各个客户端的单次转发量；

当存在大于所述当前剩余容量的目标单次转发量时，确定所述目标单次转发量对应的第二目标客户端；

向所述第二目标客户端发送超限提醒消息。

5.根据权利要求4中所述的方法，其特征在于，当存在大于所述当前剩余容量的目标单次转发量时，所述方法还包括：

当所述第二目标客户端的初始转发速率小于速率阈值时，基于所述当前剩余容量的和所述目标单次转发量生成速率调整指令；

基于所述调整指令调整所述第二目标客户端的初始转发速率，得到所述第二目标客户端的更新后的转发速率；

利用所述第二目标客户端的更新后的转发速率更新所述远程字典服务。

6.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

当所述待转发信息为向至少两个目的地址发送的信息时，获取所述至少两个目的地址的数量；

当所述至少两个目的地址的数量小于或者等于数量阈值时，向所述目的地址转发所述待转发信息；

当所述目的地址的数量大于所述数量阈值时，从所述目的地址中确定出选中目的地址，并向所述选中目的地址转发所述待转发信息，其中，所述选中目的地址的数量等于所述数量阈值。

7.根据权利要求1至5中任一项所述的方法，其特征在于，所述方法还包括：

获取所述各个客户端发送的信息；

依次对所述信息进行权限校验和预设字段过滤，得到校验通过且不包含预设字段的信息；

将所述校验通过且不包含预设字段的信息确定为所述待转发信息。

8.一种信息转发装置，其特征在于，所述信息转发装置包括：

第一获取模块，用于获取多个客户端的限流模型，并将各个限流模型的限流参数存储至远程字典服务中；

接收模块，用于接收各个客户端发送的待转发信息；

第一转发模块，用于从所述远程字典服务中获取所述各个客户端的限流模型的限流参数，并基于所述各个客户端的限流模型的限流参数转发所述各个客户端的待转发信息。

9.一种信息转发设备，其特征在于，所述信息转发设备包括：

处理器；以及

存储器，用于存储可在所述处理器上运行的计算机程序；

其中，所述计算机程序被处理器执行时实现权利要求1至7任一项所述的信息转发方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质中存储有计算机可执行指令，该计算机可执行指令配置为执行上述权利要求1至7任一项所述的信息转发方法。