[0001] 本申请涉及信息技术领域，尤其涉及一种流量控制方法以及设备。

[0002] 随着业务系统的扩展和增多，会出现对业务系统进行改造的需求，在改造过程中一般需要过滤出一部分流量进行对改造后的业务系统进行灰度测试，以验证新系统是否存在问题。目前在灰度测试时进行流量控制的方式较为单机，一般都是对流量单纯的按照过滤规则进行控制，即符合过滤规则的直接转发至新系统处理，而不符合过滤规则的仍然转发旧版本系统处理。

[0003] 但是，这种方式并不适用于所有的互联网业务场景。如在订单业务系统中，由于订单的整个履约是有过程的，包括下单，支付，分拣，发货，收货，订单确认等。整个过程周期很长，由此在同时存在两套系统的情况下，就要需要确保订单从头到尾都走一套系统中。若订单在新系统中创建，则后续的关于该订单的消息都需要由新系统处理，反之，若订单在旧系统中创建，则后续的关于该订单的消息都需要由旧系统处理。而目前单纯基于过滤规则的流量控制方式，相当于仅在新旧系统的入口处进行一次简单的分类，将有可能会使得在旧系统中已创建了订单的后续订单消息被转入新系统，而新系统中由于缺少关于该订单的必要信息而导致无法处理转入的后续订单消息。

[0004] 综上所述，目前用于灰度测试时的流量控制方式并不适用于同源流量存在前后关联的业务场景，可能导致新系统无法处理部分流量。

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

[0036] 在本申请一个典型的配置中，终端、服务网络的设备均包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

[0037] 内存可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。

[0038] 计算机可读介质包括永久性和非永久性、可移动和非可移动媒体，可以由任何方法或技术来实现信息存储。信息可以是计算机程序指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘(CD‑ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。

[0039] 本申请实施例提供的一种流量控制方法，该方法应用于灰度测试时新系统和旧系统之间的流量控制。在一部分业务场景中，业务系统所需要处理的多条消息之间可能具有相同的来源，例如在电商领域中，进行灰度测试时的新、旧订单业务系统可能会收到关于某一订单的不同阶段的处理消息，如订单创建消息、订单取消消息、订单支付消息、订单出货消息等，这些消息的共同点在于都是针对同一订单的处理，可以认为其来源相同，均是基于同一订单，属于同源消息。还如，在数据存储领域中，进行灰度测试时的新、旧数据库系统同样可能会收到关于某一数据的不同阶段的处理消息，例如创建数据记录的消息、修改数据记录的消息、删除数据记录的消息等，这些消息的共同点在于都是针对同一个数据记录，同样可以其来源相同，属于同源消息。

[0040] 由于新系统和旧系统之间相互独立，因此对于消息处理过程而言，属于一种隔离环境，若不同处理阶段的同源消息在新、旧系统中分别处理，将会导致系统在处理阶段在后的同源消息时，会因缺少前置的数据而导致处理失败。以简单的过滤规则的方式对订单业务系统进行流量控制为例，若根据过滤规则将某一订单的创建消息分配至旧系统进行处理，或者是在该订单在进行灰度测试之间已经在旧系统中完成了订单的创建，而当该订单的订单支付消息产生时，被分配至了新系统中进行处理，此时新系统中会因为缺少关于订单创建的相关数据而导致处理失败。

[0041] 而本申请实施例中的方案所需要处理的消息即为类同源消息，通过在流量进入到新、旧系统的入口处设置合理的控制逻辑，可以确保灰度测试的流量分配的同时，避免同源流量被分配至不同的系统中导致新系统无法处理部分流量的问题。

[0042] 在实际场景中，该方法的执行主体可以是用户设备、网络设备或用户设备与网络设备通过网络相集成所构成的设备，或者也可以是运行于上述设备的应用程序。所述用户设备包括但不限于计算机、手机、平板电脑等各类终端设备；所述网络设备包括但不限于如网络主机、单个网络服务器、多个网络服务器集或基于云计算的计算机集合等实现。在此，云由基于云计算(Cloud Computing)的大量主机或网络服务器构成，其中，云计算是分布式计算的一种，由一群松散耦合的计算机集组成的一个虚拟计算机。此外，该方法的执行主体也可以是运行于上述设备中的程序，例如可以实现为流量控制组件、模块等。图1示出了本申请实施例提供的一种流量控制方法的处理流程，该方法应用于灰度测试时新系统和旧系统之间的流量控制，至少包括了以下的步骤：

[0043] 步骤S101，获取待处理消息，在缓存中查询关于所述待处理消息的流量控制结果。其中，所述待处理消息是指在一次流量控制过程中需要处理的消息，以订单业务场景为例，所述待处理消息可以是订单创建、订单支付、订单修改、订单出货、订单完成等消息，对应于订单处理的各个阶段。这些消息在进入到订单业务系统之前，可以在入口处进行流量控制，实现待处理消息的分配。在实际场景中，待处理消息可以基于消息队列的机制实现交互。

[0044] 所述缓存中保存了关于所述待处理消息的流量控制结果，关于所述待处理消息的流量控制结果可以是该条待处理消息的同源消息的分配结果，例如若本次获取到的待处理消息为关于订单a1的支付消息，则其同源消息可能是订单a1的创建消息，缓存中可能保存有订单a1的创建消息的流量控制结果，即订单a1的创建消息的分配结果。若缓存中保存了订单a1的创建消息的分配结果，即可命中缓存，在缓存中查询到关于所述待处理消息的流量控制结果，反之，则无法查询到，对于不同的查询结果，可以采用不同的方式进行后续处理。

[0045] 步骤S102，若未查询到所述关于所述待处理消息的流量控制结果，判断所述待处理消息的类型是否为创建类型。

[0046] 未查询到所述关于所述待处理消息的流量控制结果时，表示本次的待处理消息没有同源消息通过本实施的方案进行过流量控制，即本次的待处理消息是所有同源消息中第一条通过本方案进行流量控制的消息。其可能的原因至少包括两种：1、待处理消息的类型是创建类型，即是同源消息中第一阶段的创建消息；2、所述待处理消息并非是创建类型，但是该条待处理消息之前阶段的同源消息达到之前，还未接入进行灰度测试的新系统，所有之前阶段的同源消息均已经由旧系统处理。

[0047] 由此，本步骤需要对这两种情况进行区分，因此需要进一步判断待处理消息的类型是否为创建类型。以前述订单业务场景为例，所述待处理消息为订单消息，创建类型的订单消息包括用于在目标系统中创建订单的订单创建消息，所述非创建类型的订单消息包括除订用于在目标系统中对已创建的订单进行二次操作的其他消息。当未在缓存中查询到关于订单a1的支付消息的流量控制结果时，需要进一步判断订单a1的支付消息的类型是否非创建类型，显然订单a1的支付消息的类型是支付类型，属于非创建类型，而不是创建类型。对于不同的判断结果，可以分别执行后续的步骤S103和步骤S104中的处理过程。

[0048] 步骤S103，若所述待处理消息的类型为创建类型，则根据预设的过滤规则分配所述待处理消息的目标系统，将分配结果作为所述待处理消息的流量控制结果写入所述缓存，并将所述待处理消息发送至目标系统。

[0049] 在根据预设的过滤规则分配所述待处理消息的目标系统时，可以获取所述待处理消息的关联信息，并将所述关联信息与预设的过滤规则匹配，若命中所述过滤规则，将新系统确定为所述待处理消息的目标系统，若未命中所述过滤规则，将旧系统确定为所述待处理消息的目标系统。然后，可以将待处理消息发送给所确定的目标系统，由目标系统对待处理消息进行处理，例如，当确定的目标系统为新系统时，会将待处理消息发送至新系统进行处理，而当确定的目标系统为旧系统时，会将待处理消息发送至旧系统进行处理。

[0050] 所述待处理消息的关联信息可以是任意与该条待处理消息具有关联的、能够用于进行规则匹配的信息，可以来自于待处理消息自身所携带的信息，如订单号等订单标识、订单的用户标识，还可以待处理消息所参与流量控制过程的当前状态相关，如当前已通过本实施例的方案分配至新系统或系统的消息的数量等。由此，本申请实施例中的预设的过滤规则可以包括以下至少任一项：

[0051] 订单消息的订单标识的取模结果符合第一预设条件，例如当订单标识为数字形式的订单号时，可以将订单号取2的模，然后将取模结果为1设定为第一预设条件，由此，订单号202107272134771的订单将命中该过滤规则，反之订单号202107272135668的订单由于其取模结果为0，则未命中该条过滤规则。

[0052] 已分配至目标系统的消息的数量符合第二预设条件，在本实施例中用于分配流量的目标系统包括了新系统和旧系统，可以基于已分配至某一目标系统(如新系统)的消息的数量来判断是否符合第二预设条件。若本实施中所设定的第二预设条件为小于等于1000，则当已分配至目标系统的消息的数量小于1000时，本次的待处理消息均会命中该条过滤规则。

[0053] 订单消息的用户标识符合第三预设条件，所述用户标识可以是用户名、用户编号等，通过该条过滤规则可以指定一部分用户所产生的订单进入到新系统，如用户编号的末位为指定数字、用户名中包含某一指定字符等。

[0054] 在此，本领域技术人员应当理解过滤规则的具体内容仅为举例，现有或今后出现的基于类似原理的其它形式如果能够适用于本申请，也应该包含在本申请的保护范围内，并以引用的形式包含于此。

[0055] 在根据预设的过滤规则分配所述待处理消息的目标系统之后，即可将分配结果作为所述待处理消息的流量控制结果写入所述缓存，从而更新缓存中的内容，以用于前述步骤S101中的查询处理。为了使得查询时可以更加高效、准确，本申请实施例的方案在将分配结果作为所述待处理消息的流量控制结果写入所述缓存时，可以先确定所述待处理消息的来源标识，将所述待处理消息及其分配的目标系统写入所述缓存，以建立所述待处理消息的来源标识与目标系统之间的映射关系。例如，对于订单业务场景，其来源标识可以设定为订单标识，由此具有相同订单标识的消息可以认为是同源消息，如订单a2的创建消息、支付消息、出货消息等。

[0056] 通过将所述待处理消息及其分配的目标系统写入所述缓存，以建立所述待处理消息的来源标识与目标系统之间的映射关系。例如，若本次的待处理消息是订单a2的创建消息，且根据预设的过滤规则分配所述待处理消息的目标系统为新系统，可以获取订单a2的订单号202107272134771，然后可以将订单a2的创建消息与其分配的目标系统写入到缓存中，建立订单a2的来源标识202107272134771与新系统之间的映射关系。由此，在前述步骤S101中，关于订单号为202107272134771的订单的所有后续的同源消息，都可以在缓存中查询到对应的流量控制结果。

[0057] 在实际场景中，缓存可以在用市场上已有的任意缓存工具实现，如Redis(Remote Dictionary Server，远程字典服务)等，并且所述缓存可以单独封装于工具包中，无须由该方案的调用方进行配置，由此可以使得方案的实现更加便捷。

[0058] 步骤S104，若所述待处理消息的类型为非创建类型，则将所述待处理消息对应的同源系统确定为目标系统，并将所述待处理消息发送至目标系统。

[0059] 其中，所述同源系统为所述待处理消息所对应的同源消息已发送的系统，所述同源消息为与所述待处理消息来源相同的消息。若一条待处理消息未在缓存中查询到对应的流量控制结果，且类型为非创建类型，则需要将该条待处理消息发送至处理其同源消息的系统进行处理，以确保目标系统在处理消息时，不会有必要数据不会缺失，避免无法处理消息的情况出现。例如对于前述的订单a1的支付消息，若其同源消息(订单a1的创建消息)由旧系统处理，即同源系统为旧系统，则可以旧系统确定为目标系统，将所述待处理消息发送至旧系统，由旧系统进行处理。

[0060] 步骤S105，若查询到所述关于所述待处理消息的流量控制结果，从所述流量控制结果中确定所述待处理消息的目标系统，并将所述待处理消息发送至目标系统。

[0061] 当查询到所述关于所述待处理消息的流量控制结果时，即可确定之前已经进行过流量控制的同源消息的分配结果，由此可以按照该分配结果之间确定待处理消息的目标系统。例如，以前述的订单a1的支付消息为例，若缓存中存储了“订单号为202107272199832的订单a1的创建消息已经由流量控制被分配至新系统”的分配结果，该分配结果即为关于订单a1的支付消息的流量控制结果。此时，也会将新系统确定为订单a1的支付消息的目标系统，并将其发送至新系统中处理。反之，若缓存中存储的信息指向旧系统为订单a1的支付消息的目标系统，则将订单a1的支付消息发送至旧系统，由旧系统进行处理。

[0062] 由此，通过上述控制逻辑，可以在确保灰度测试的流量分配的同时，避免同源流量被分配至不同的系统中导致新系统无法处理部分流量的问题，确保业务系统在灰度测试时的正常运作。

[0063] 图2示出了将本申请实施例提供的方案应用于订单业务场景时的构架，其中，订单消息基于参与交易的用户行为产生，例如订单创建消息对应于买方用户的下单行为，订单支付消息对应于买方用户的支付行为，订单取消消息对应于买方用户的取消订单行为，订单出货消息对应于卖方用户的发货行为等，订单消息采用MQ(Message Queue，消息队列)的机制实现传输。

[0064] 本申请实施例中的流量控制方案可以实现为一流量控制组件，该流量控制组件包括规则管理器、流量控制器和缓存管理器，其中规则管理器用于管理预设的过滤规则，实现过滤规则的配置以及判断等功能，流量控制器用于控制订单消息的流向，实现流量分配，缓存管理器用于管理中存储的内容以及实现缓存查询等功能。可供处理订单消息的目标系统包括了新系统和旧系统，两者均可以包括了实现订单业务处理所需要的各个子系统，如接单系统、订单中心、出库系统、支付系统、订单生产系统等。

[0065] 该构架的系统在实现订单消息的流量控制时，其流程如图3所示，至少包括了以下的步骤：

[0066] 步骤S301，订单消息的流量进入流量控制组件。

[0067] 步骤S302，流量控制组件在缓存中查询是否已经存在关于该订单消息的流量控制结果。

[0068] 步骤S303，流量控制组件判断是否命中缓存，如果命中了缓存，则根据缓存中存储的信息，执行步骤S307，由新系统或旧系统进行处理；如果未命中缓存，执行步骤S304。

[0069] 步骤S304，流量控制组件判断订单消息是否为创建类型。如果是创建类型，则继续执行步骤S305；如果是非创建类型，则执行步骤S307，由旧系统进行处理。

[0070] 步骤S305，基于订单消息的关联信息，由规则管理器根据过滤规则进行匹配，确定是分配至新系统或者是旧系统，执行对应的步骤，由新系统或旧系统进行处理。

[0071] 步骤S306，将分配结果作为该订单消息的流量控制结果写入所述缓存。

[0072] 步骤S307，控制订单消息进入新系统或旧系统，由新系统或旧系统处理订单消息，并返回处理结果。

[0073] 在应用于订单业务场景中时，订单消息在进入业务系统之前，先经过流量控制组件确定需要进入的系统，如果是同一订单的消息，即使过滤规则发生了变更，也不会影响到订单后续的消息的处理。此外，此种处理方式，也可以应用于订单业务之外的其它场景，如任意同源数据的环境隔离场景中。

[0074] 本申请实施例还提供了一种流量控制设备，该设备包括用于存储计算机程序指令的存储器和用于执行计算机程序指令的处理器，其中，当该计算机程序指令被该处理器执行时，触发所述设备实现前述本申请的多个实施例的方法和/或技术方案。

[0075] 特别地，本申请实施例中的方法和/或实施例可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在该计算机程序被处理单元执行时，执行本申请的方法中限定的上述功能。

[0076] 需要说明的是，本申请所述的计算机可读介质可以是计算机可读信号介质或者计算机可读存储介质或者是上述两者的任意组合。计算机可读介质例如可以是——但不限于——电、磁、光、电磁、红外线、或半导体的系统、装置或器件，或者任意以上的组合。计算机可读存储介质的更具体的例子可以包括但不限于：具有一个或多个导线的电连接、便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、光纤、便携式紧凑磁盘只读存储器(CD‑ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本申请中，计算机可读介质可以是任何包含或存储程序的有形介质，该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。

[0077] 而在本申请中，计算机可读的信号介质可以包括在基带中或者作为载波一部分传播的数据信号，其中承载了计算机可读的程序代码。这种传播的数据信号可以采用多种形式，包括但不限于电磁信号、光信号或上述的任意合适的组合。计算机可读的信号介质还可以是计算机可读存储介质以外的任何计算机可读介质，该计算机可读介质可以发送、传播或者传输用于由指令执行系统、装置或者器件使用或者与其结合使用的程序。计算机可读介质上包含的程序代码可以用任何适当的介质传输，包括但不限于：无线、电线、光缆、RF等等，或者上述的任意合适的组合。

[0078] 可以以一种或多种程序设计语言或其组合来编写用于执行本申请的操作的计算机程序代码，所述程序设计语言包括面向对象的程序设计语言—诸如Java、Smalltalk、C++，还包括常规的过程式程序设计语言—诸如“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算机上执行、部分地在用户计算机上执行、作为一个独立的软件包执行、部分在用户计算机上部分在远程计算机上执行、或者完全在远程计算机或服务器上执行。在涉及远程计算机的情形中，远程计算机可以通过任意种类的网络——包括局域网(LAN)或广域网(WAN)—连接到用户计算机，或者，可以连接到外部计算机(例如利用因特网服务提供商来通过因特网连接)。

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

[0080] 作为另一方面，本申请还提供了一种计算机可读介质，该计算机可读介质可以是上述实施例中描述的设备中所包含的；也可以是单独存在，而未装配入该设备中。上述计算机可读介质承载有一个或者多个计算机程序指令，所述计算机程序指令可被处理器执行以实现前述本申请的多个实施例的方法和/或技术方案。

[0081] 需要注意的是，本申请可在软件和/或软件与硬件的组合体中被实施，例如，可采用专用集成电路(ASIC)、通用目的计算机或任何其他类似硬件设备来实现。在一些实施例中，本申请的软件程序可以通过处理器执行以实现上文步骤或功能。同样地，本申请的软件程序(包括相关的数据结构)可以被存储到计算机可读记录介质中，例如，RAM存储器，磁或光驱动器或软磁盘及类似设备。另外，本申请的一些步骤或功能可采用硬件来实现，例如，作为与处理器配合从而执行各个步骤或功能的电路。

[0082] 对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其他的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化涵括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。此外，显然“包括”一词不排除其他单元或步骤，单数不排除复数。装置权利要求中陈述的多个单元或装置也可以由一个单元或装置通过软件或者硬件来实现。第一，第二等词语用来表示名称，而并不表示任何特定的顺序。