CN117472617B - 一种消息处理方法、装置、电子设备及可读存储介质 - Google Patents

Abstract

本申请提供一种消息处理方法、装置、电子设备及可读存储介质，该方法包括：在第一产品的灰度发布场景下接收第一业务请求消息；在确定第一业务请求消息对应的第一用户为灰度发布测试用户的情况下，基于第一业务请求消息和预设灰度头生成第一请求，将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费；在确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求，将第二请求传输至非灰度版的第一服务，以使非灰度版的第一服务消费。即可实现测试用户的第一请求被灰度版的第一服务消费，非测试用户的第二请求被非灰度版的第一服务消费，可提高灰度发布效果。

Description

一种消息处理方法、装置、电子设备及可读存储介质

技术领域

本申请涉及云计算技术领域，尤其涉及一种消息处理方法、装置、电子设备及可读存储介质。

背景技术

灰度发布又叫金丝雀发布，已越来越多的被企业在迭代式软件开发模式中应用，实现软件服务升级变更。运维人员在生产环境部署一套新版本服务，此时流量还没有切换，普通用户（可以理解是非测试用户）访问旧服务（即非灰度版服务），测试用户访问新服务（即灰度版的服务），新服务的流量较小，仅限测试用户。在新服务升级变更发现问题时可对新服务更新，待新服务完成功能测试和压力测试后切换流量到新服务，并停止旧服务，实现新旧服务的平滑过渡。

服务灰度发布场景下新旧服务并存且监听消息队列，新旧服务接收消息后进行消息消费（对消息进行消费可以理解是响应于消息执行相应的操作，例如，对于资源开通业务请求消息，消费消息即可以是进行资源开通等），然而，在服务灰度发布场景下，对于某一条消息，实际消费对象（新服务或旧服务）具有随机性，导致在服务灰度发布场景下消息消费对象容易出现混乱，导致服务灰度发布效果较差。

发明内容

本申请实施例提供一种消息处理方法、装置、电子设备及可读存储介质，以解决现有灰度发布效果较差的问题。

为解决上述技术问题，本申请是这样实现的：

第一方面，本申请实施例提供了一种消息处理方法，应用于第一产品的第一服务，所述方法包括：

在第一产品的灰度发布场景下，接收第一业务请求消息，其中，所述第一业务请求消息中包括第一用户的标识，在所述灰度发布场景下所述第一服务具有灰度版和非灰度版；

在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容；将所述第一请求传输至灰度版的第一服务，以使所述灰度版的第一服务消费所述第一请求；

在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，所述第二请求中包括所述第一业务请求消息中的消息内容；将所述第二请求传输至非灰度版的第一服务，以使所述非灰度版的第一服务消费所述第二请求。

第二方面，本申请实施例提供了一种消息处理方法，应用于灰度版的第一服务，所述方法包括：

接收第一请求，所述第一请求为基于预设灰度头以及第一业务请求消息生成的请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容，所述第一业务请求消息为在第一产品的灰度发布场景下的业务请求，所述第一业务请求消息中包括第一用户的标识，所述第一用户为所述灰度发布场景下的灰度发布测试用户，所述灰度版的第一服务为在所述灰度发布场景下所述第一服务的灰度版；

对所述第一请求进行消费。

第三方面，本申请实施例提供一种消息处理装置，应用于第一产品的第一服务，所述装置包括：

第一接收模块，用于在第一产品的灰度发布场景下，接收第一业务请求消息，其中，所述第一业务请求消息中包括第一用户的标识，在所述灰度发布场景下所述第一服务具有灰度版和非灰度版；

第一处理模块，用于：

在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容；将所述第一请求传输至灰度版的第一服务，以使所述灰度版的第一服务消费所述第一请求；

在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，所述第二请求中包括所述第一业务请求消息中的消息内容；将所述第二请求传输至非灰度版的第一服务，以使所述非灰度版的第一服务消费所述第二请求。

第四方面，本申请实施例提供一种消息处理装置，应用于灰度版的第一服务，所述装置包括：

第二接收模块，用于接收第一请求，所述第一请求为基于预设灰度头以及第一业务请求消息生成的请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容，所述第一业务请求消息为在第一产品的灰度发布场景下的业务请求，所述第一业务请求消息中包括第一用户的标识，所述第一用户为所述灰度发布场景下的灰度发布测试用户，所述灰度版的第一服务为在所述灰度发布场景下所述第一服务的灰度版；

第一消费模块，用于对所述第一请求进行消费。

第五方面，本申请实施例提供一种电子设备，包括收发机和处理器，

所述处理器，用于：

在第一产品的灰度发布场景下，通过收发机接收第一业务请求消息，其中，所述第一业务请求消息中包括第一用户的标识，在所述灰度发布场景下所述第一服务具有灰度版和非灰度版；

在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容；将所述第一请求传输至灰度版的第一服务，以使所述灰度版的第一服务消费所述第一请求；

在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，所述第二请求中包括所述第一业务请求消息中的消息内容；将所述第二请求传输至非灰度版的第一服务，以使所述非灰度版的第一服务消费所述第二请求。

第六方面，本申请实施例提供一种电子设备，包括收发机和处理器，

通过所述收发机接收第一请求，所述第一请求为基于预设灰度头以及第一业务请求消息生成的请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容，所述第一业务请求消息为在第一产品的灰度发布场景下的业务请求，所述第一业务请求消息中包括第一用户的标识，所述第一用户为所述灰度发布场景下的灰度发布测试用户，所述灰度版的第一服务为在所述灰度发布场景下所述第一服务的灰度版；

对所述第一请求进行消费。

第四方面，本申请实施例提供一种电子设备，包括：处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序，所述程序被所述处理器执行时实现上述第一方面所述的消息处理方法的步骤，或实现上述第二方面所述的消息处理方法的步骤。

第五方面，本申请实施例提供一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现上述第一方面所述的消息处理方法的步骤，或实现上述第二方面所述的消息处理方法的步骤。

在本实施例中，在第一产品的灰度发布场景下，接收第一业务请求消息，第一业务请求消息中包括第一用户的标识，在确定该第一用户为灰度发布测试用户的情况下，可生成包括预设灰度头的第一请求，另外，第一请求还包括第一业务请求消息中的消息内容，将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费第一请求，而在确定该第一用户为灰度发布非测试用户的情况下，生成第二请求，第二请求包括第一业务请求消息中的消息内容，而无需添加预设灰度头，将第二请求传输至非灰度版的第一服务，以使非灰度版的第一服务消费第二请求。也即是，本实施例可对消费对象进行控制，无论是灰度版的第一服务接收第一业务请求消息，还是非灰度版的第一服务接收第一业务请求消息，通过本实施例的方法，可使为非测试用户的第一用户对应的第二请求传输至非灰度版的第一服务，被非灰度版的第一服务消费，使为测试用户的第一用户对应的第一请求传输至灰度版的第一服务，被灰度版的第一服务消费，实现灰度发布场景下消息消费的对应性，可降低第一服务的灰度发布场景下消息消费对象出现混乱的情况发生，提高第一服务灰度发布效果。

附图说明

为了更清楚地说明本申请实施例的技术方案，下面将对本申请实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种消息处理方法的流程图之一；

图2是本申请实施例提供的一种消息处理方法的流程图之二；

图3是本申请实施例提供的一种消息处理方法的流程图之三；

图4是本申请实施例提供的一种平台架构图；

图5是本申请实施例提供的一种消息处理原理图；

图6是本申请实施例提供的一种消息处理方法的流程图之四；

图7是本申请实施例提供的一种消息处理方法的流程图之五；

图8是本申请实施例提供的一种消息处理装置的模块示意图之一；

图9是本申请实施例提供的一种消息处理装置的模块示意图之二；

图10是本申请实施例提供的一种消息处理装置的模块示意图之三；

图11是本申请实施例提供的一种电子设备的结构示意图之一；

图12是本申请实施例提供的一种电子设备的结构示意图之二；

图13是本申请实施例提供的一种电子设备的结构示意图之三。

具体实施方式

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

参见图1，图1是本申请实施例提供的一种消息处理方法的流程图。如图1所示，本实施例提供的消息处理方法包括以下步骤：

步骤101：在第一产品的灰度发布场景下，接收第一业务请求消息，其中，第一业务请求消息中包括第一用户的标识，在灰度发布场景下第一服务具有灰度版和非灰度版。

第一服务可以是第一平台中第一产品的服务，第一平台中可包括至少一个产品，各产品能实现相应的功能，第一产品是第一平台的产品中进行灰度发布的产品。本实施例的方法可应用于第一平台的第一服务。在第一产品的灰度发布场景下，第一产品中的服务具有灰度版和非灰度版，其中，第一服务具有灰度版和非灰度版，灰度版的第一服务与非灰度版的第一服务均可进行消息消费，消息生产者（例如，第一平台的订单微服务）可生成业务请求消息并向第一服务发送，是发送给灰度版的第一服务还是非灰度版的第一服务具有随机性，上述第一业务请求消息可以理解是与第一服务关联的业务请求消息，可以是灰度版的第一服务接收的业务请求消息，也可以是非灰度版的第一服务接收的业务请求消息。

步骤102：在确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求，将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费第一请求；

第一请求中包括预设灰度头以及第一业务请求消息中的消息内容；

步骤103：在确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求；将第二请求传输至非灰度版的第一服务，以使非灰度版的第一服务消费第二请求；

第二请求中包括第一业务请求消息中的消息内容。

在本实施例中，用户的类型可包括测试用户（即灰度发布测试用户/灰度用户）和非测试用户（灰度发布非测试用户/非灰度用户），第一业务请求消息中包括第一用户的标识，在接收第一业务请求消息后，需确定第一用户的类型，在第一用户为不同类型的用户的情况下，需执行不同的操作。示例性地，可根据第一用户的标识确定第一用户的类型。

在本实施例中，在确定第一用户为灰度发布测试用户的情况下，可生成第一请求，第一请求中不但包括第一业务请求消息中的消息内容，而且还包括预设灰度头，然后将第一请求传输至灰度版的第一服务，由灰度版的第一服务对第一请求进行消息消费，即消费对象是灰度版的第一服务；而在确定第一用户为灰度发布非测试用户的情况下，无需添加预设灰度头，生成第二请求，第二请求中不包括预设灰度头，第二请求中包括第一业务请求消息中的消息内容，将第二请求传输至非灰度版的第一服务，由非灰度版的第一服务对第二请求进行消息消费，即消费对象是非灰度版的第一服务。一个示例中，消息内容可包括业务订单信息，业务订单信息可包括业务订单标识（订单项标识），另外还可包括但不限于订单类型等。

需要说明的是，本申请实施例中的消息消费可以理解是执行相应的操作，例如，对于第一业务请求消息为资源开通业务请求消息，根据第一用户的类型生成的第一请求或第二请求后，对第一请求或第二请求进行消费消息即可以是执行资源开通。又例如，对于第一业务请求消息为转账业务请求消息，根据第一用户的类型生成的第一请求或第二请求后，对第一请求或第二请求进行消费消息即可以是执行转账操作。上述消费第一请求即可以理解是响应于第一请求执行相应的业务操作，上述消费第二请求即可以理解是响应于第二请求执行相应的业务操作，应理解的是，消费第一请求或消费第二请求，执行的业务操作是与第一业务请求消息相关的，例如，对于资源开通业务请求消息，执行的操作则是资源开通，对于转账业务请求消息，执行的操作是转账操作。

另外，需要说明的是，上述预设灰度头中可包括预设灰度值，该预设灰度值可以在第一服务的灰度发布之前预先设定，上述预设灰度头包括键（字段）以及对应的值，键是固定的，键的值可以变更（本申请实施例键的值即可以是上述预设灰度值），上述预设灰度值可以理解是灰度字段的值。

在本实施例中，在第一产品的灰度发布场景下，接收第一业务请求消息，第一业务请求消息中包括第一用户的标识，在确定该第一用户为灰度发布测试用户的情况下，可生成包括预设灰度头的第一请求，另外，第一请求还包括第一业务请求消息中的消息内容，将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费第一请求，而在确定该第一用户为灰度发布非测试用户的情况下，生成第二请求，第二请求包括第一业务请求消息中的消息内容，而无需添加预设灰度头，将第二请求传输至非灰度版的第一服务，以使非灰度版的第一服务消费第二请求。也即是，本实施例可对消费对象进行控制，无论是灰度版的第一服务接收第一业务请求消息，还是非灰度版的第一服务接收第一业务请求消息，通过本实施例的方法，可使为非测试用户的第一用户对应的第二请求传输至非灰度版的第一服务，被非灰度版的第一服务消费，使为测试用户的第一用户对应的第一请求传输至灰度版的第一服务，被灰度版的第一服务消费，实现灰度发布场景下消息消费的对应性，可降低第一服务的灰度发布场景下消息消费对象出现混乱的情况发生，提高第一服务灰度发布效果。

在一个实施例中，将第一请求传输至灰度版的第一服务，包括：通过中间件将第一请求转发至灰度版的第一服务；

将第二请求传输至非灰度版的第一服务，包括：通过中间件将第二请求转发至非灰度版的第一服务。

可以理解，在生成第一请求后，可将第一请求发送给中间件（该中间件可以第一产品的中间件），由中间件将第一请求转发给灰度版的第一服务。在生成第二请求后，可将第二请求发送给中间件，由中间件将第二请求转发给非灰度版的第一服务服。这样，通过中间件可将第一请求转发给灰度版的第一服务消费，通过中间件可将第二请求转发至非灰度版的第一服务消费，实现对消费对象的控制。

在一个实施例中，方法还包括以下至少一项：

在缓存中查询到第一用户的标识的情况下，确定第一用户为灰度发布测试用户；其中，缓存用于存储灰度发布场景下测试用户的标识；

在缓存中未查询到第一用户的标识的情况下，确定第一用户为灰度发布非测试用户。

即可将灰度发布场景下测试用户的标识存储于缓存中，一个示例中，该缓存可以是但不限于Redis缓存等。可利用第一用户的标识查询缓存，在缓存中查询到第一用户的标识的情况下，表示第一用户属于灰度发布测试用户，即可确定第一用户为灰度发布测试用户，否则确定第一用户为灰度发布非测试用户。

在本实施例中，可通过查询缓存的方式确定第一用户的类型，即通过查询缓存的方式即可确定第一用户为灰度发布测试用户还是灰度发布非测试用户，这样可提高确定第一用户的类型的便利性，后续可根据第一用户的类型进行相应的处理，若第一用户为测试用户，则生成包括预设灰度头和第一业务请求消息中的消息内容的第一请求，并传输至灰度版的第一服务，由灰度版的第一服务消费，若第一用户为非测试用户，则生成包括第一业务请求消息中的消息内容的第二请求，无需添加预设灰度头，将第二请求传输至非灰度版的第一服务，由非灰度版的第一服务消费，实现对消费对象的控制，这样可提高灰度发布场景下消息的消费对象的合理性，提高灰度发布效果。

在一个实施例中，接收第一业务请求消息之前，方法还包括：

通过第一产品的第二服务接收业务订购请求消息，业务订购请求消息中包括第二用户的标识；

在业务订购请求消息中包括预设灰度头的情况下，通过第二服务将第二用户的标识存储到缓存中，预设灰度头用于指示第二用户为测试用户。

需要说明的是，第二服务可以是第一产品中不同于第一服务的服务，例如，第二服务可以是业务订购服务。业务订购请求消息可以前端服务发送的消息，即前端服务响应于第二用户（可以是任意用户）的订购请求可生成业务订购请求消息，并发送至第二服务，通过第二服务接收业务订购请求消息。需要说明的是，前端服务可选择该第二用户作为测试用户还是非测试用户，在选择第二用户作为测试用户的情况下，生成的业务订购消息中会添加预设灰度头，即业务订购消息中包括预设灰度头，预设灰度头可以指示第二用户为测试用户。在选择第二用户作为非测试用户的情况下，业务订购消息中无需添加预设灰度头，即业务订购消息中不包括预设灰度头。应理解的是，可通过第二服务接收多个业务订购请求消息，可对每个业务订购请求消息是否包括预设灰度头进行判断，一旦某个业务订购请求包括预设灰度头，可确定该业务订购请求消息对应的用户为测试用户，则可将该业务订单请求消息中包括的第二用户的标识存储到缓存中。另外，若业务订购请求消息中的第二用户为第一用户，在业务订购请求消息中包括预设灰度头的情况下，表征第一用户为测试用户，可将第一用户的标识存入缓存，后续在接收第一业务请求消息后，可在缓存中查询到第一用户的标识，即刻确定第一用户为测试用户。

在本实施例中，通过第二服务接收业务订购请求消息后，判断业务订购请求消息中是否包括预设灰度头，若包括，则可明确第二用户是作为测试用户的，即可将第二用户的标识存储到缓存中，通过缓存存储灰度发布场景下测试用户的标识，以便于后续通过查询缓存判断用户是否为测试用户。

在一个实施例中，在确定第一用户为灰度发布测试用户的情况下，还包括：

将预设灰度头放入上下文中；

基于预设灰度头以及第一业务请求消息生成第一请求，包括：

在上下文中读取到预设灰度头的情况下，根据预设灰度头以及第一业务请求消息生成第一请求。

对于测试用户，对应的业务订购请求消息中可包括预设灰度头，可将测试用户的标识存储于缓存中，在接收第一业务请求消息后，通过查询缓存确定第一用户为测试用户的情况下，可将预设灰度头塞入上下文，这样，可读取上下文，在上下文中读取到预设灰度头的情况下，可根据预设灰度头以及第一业务请求消息生成第一请求，将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费第一请求。

在一个实施例中，接收第一业务请求消息之后，还包括：

在历史消息消费记录中查询是否包括第一业务请求消息中业务订单信息对应的消费记录；

在确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求，包括：在历史消息消费记录中未查询到第一请求对应的消费记录，且确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求；

在确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求，包括：在历史消息消费记录中未查询到第一请求对应的消费记录，且确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求。

即可先在历史消息消费记录中查询第一业务请求消息中业务订单信息对应的消费记录，在历史消息消费记录中未查询到第一请求对应的消费记录，

可以理解，每消费一条消息均可生成对应的一条消费记录，由于第一业务请求消息中包括业务订单信息，可以理解，生成的消费记录与业务订单信息对应的。在本实施例中，可先在历史消息消费记录中查询第一业务请求消息中业务订单信息对应的消费记录，在历史消息消费记录中未查询到第一业务请求消息中业务订单信息对应的消费记录的情况下，可表示第一业务请求消息未被灰度版的第一服务消费过，方可进行后续的消息消费，以确保消息幂等性。例如，在历史消息消费记录中未查询到第一业务请求消息中业务订单信息对应的消费记录的情况下，可基于第一业务请求消息生成第一请求或第二请求，若第一用户为灰度发布测试用户，基于预设灰度头以及第一业务请求消息生成第一请求，将其传输至灰度版的第一服务消费，若第一用户为灰度发布非测试用户，基于第一业务请求消息生成第二请求，无需添加预设灰度头，将其传输至非灰度版的第一服务消费。

一个示例中，在历史消息消费记录中查询到第一业务请求消息中业务订单信息对应的消费记录的情况下，表示第一业务请求消息已被第一服务消费过，则可丢弃第一业务请求消息，不进行后续的消息消费，即过滤掉该消息不做处理，以确保消息的幂等性。

在一个实施例中，缓存中存储有多个请求消息中每个请求消息中的业务订单信息，且缓存中已为每个业务订单信息加锁，多个请求消息中包括第一业务请求消息；

在历史消息消费记录中查询是否包括第一业务请求消息中业务订单信息对应的消费记录，包括：

在获取第一业务请求消息中业务订单信息的锁成功的情况下，根据第一业务请求消息中业务订单信息查询历史消息消费记录。

需要说明的是，缓存不但可存储第一产品的灰度发布场景下测试用户的标识，还可存储业务订单信息。在请求消息并发的场景下，第一服务需逐一对消息进行消费，这种情况下，可将请求消息的业务订单信息存储到缓存中，且在缓存中可为每个业务订单信息加锁，也即是需要获取相应的锁成功方可利用业务订单信息进行给后续的查询操作。即在消息处理过程中，首先需要获取第一业务请求消息中业务订单信息的锁，在获取锁成功的情况下，方可利用该业务订单信息查询历史消息消费记录，在历史消息消费记录中未查询到第一业务请求消息对应的消费记录的情况下，方可进行后续的消息消费，以确保消息幂等性。

参见图2，图2是本申请实施例提供的一种消息处理方法的流程图，由灰度版的第一服务执行，如图2所示，本实施例提供的消息处理方法包括以下步骤：

步骤201：接收第一请求，第一请求为基于预设灰度头以及第一业务请求消息生成的请求，第一请求中包括预设灰度头以及第一业务请求消息中的消息内容，第一业务请求消息为在第一产品的灰度发布场景下的业务请求，第一业务请求消息中包括第一用户的标识，第一用户为灰度发布场景下的灰度发布测试用户，灰度版的第一服务为在灰度发布场景下第一服务的灰度版；

步骤202：对第一请求进行消费。

在本实施例中，灰度版的第一服务对为测试用户的第一用户对应的第一请求进行消费，避免灰度版的第一服务对非测试用户的请求的消费，实现消费对象的对应性，以提升灰度发布效果。

在一个实施例中，对第一请求进行消费之后，还包括：

在历史消息消费记录中添加第一请求中业务订单信息对应的消费记录。

即对第一请求进行消费后，可生成其对应的消费记录，更新到历史消息消费记录中，以确保历史消息消费记录的及时性，以便后续消息的消费记录的查询。

参见图3，图3是本申请实施例提供的一种消息处理方法的流程图，由非灰度版的第一服务执行，如图3所示，本实施例提供的消息处理方法包括以下步骤：

步骤301：接收第二请求，第二请求为基于第一业务请求消息生成的请求，第二请求中包括第一业务请求消息中的消息内容，第一业务请求消息为在第一产品的灰度发布场景下的业务请求，第一业务请求消息中包括第一用户的标识，第一用户为灰度发布场景下的灰度发布非测试用户，非灰度版的第一服务为在灰度发布场景下第一服务的非灰度版；

步骤302：对第二请求进行消费。

在一个实施例中，对第二请求进行消费之后，还包括：

在历史消息消费记录中添加第二请求中业务订单信息对应的消费记录。

即对第二请求进行消费后，可生成其对应的消费记录，更新到历史消息消费记录中，以确保历史消息消费记录的及时性，以便后续消息的消费记录的查询。

下面以一个具体实施例对上述方法的具体过程进行详细说明。

随着互联网和电子商务的发展，平台提供一站式服务。一个平台包含多个服务系统，服务功能细化降低单个服务更新升级造成的影响。为了降低平台系统服务间的耦合性和提升服务的稳定性，系统服务之间交互通过消息中间件实现。平台中的服务由消息生产者和消息消费者组成，某服务可能既是生产者又是消费者。由于网络延迟等因素，消息生产者可能重复发送同一条消息，消息消费者如果不对接收的消息进行幂等处理，对重要资源开通和资金等业务会产生破坏性影响，造成系统数据混乱和企业资产损失。另外，灰度发布场景下新旧服务并存且监听消息队列，一条消息可能被灰度版的服务（新服务）消费，也有可能被非灰度版的服务（旧服务）消费，消息实际消费对象具有随机性。容易导致灰度发布场景消息的消费对象不对应产生混乱，导致灰度发布效果较差。因此，需要对消息的消费对象进行控制，灰度发布场景消息消费的对应性是指对消息的消费对象进行控制，使非灰度用户对应的消息被非灰度工程消费，灰度用户对应的消息被灰度工程消费。在本实施例中，可使用MySQL数据库持久化消息队列消息的消费记录、引入灰度头和请求转发消息使灰度发布消息队列消息具有幂等性和对应性，灰度发布变更实现端到端。

举例说明，本申请实施例中服务为微服务，灰度发布场景在平台（例如，上述第一平台）上订购资源为例实现消息队列消息幂等性和对应性。平台包含基础模块、平台中间件、产品A和产品B等，其中基础模块包含用户及订单模块等，每个产品有对应的前端服务、业务1微服务、业务2微服务、业务N微服务和产品中间件等，图4为平台框架示意图。

订单微服务是平台中间件消息队列的生产者，产品A业务1微服务是平台产品A生成订单业务，产品A业务1微服务对用户创建订单参数校验并调用订单微服务提供的接口生成订单，订单生成后由订单微服务给产品A业务2微服务发送开通资源消息。产品A业务2微服务是平台中间件消息队列的消费者，产品A业务2微服务根据消息开通对应的资源，消息唯一标识选取订单项。

在灰度发布场景下，平台中产品业务微服务有灰度和非灰度两种版本（形式），如产品灰度发布场景下，A产品A业务2微服务在灰度发布变更时由灰度版的产品A业务2微服务和非灰度版的产品A业务2微服务组成。平台用户有两种，分别是普通用户（非灰度用户/非测试用户）和灰度发布测试用户（灰度用户），两种用户通过平台提供的产品订购页订购产品。产品服务更新升级接入灰度发布后，测试人员通过灰度发布测试账号进行新功能测试。两种用户订购差别主要是产品订购页发送的请求是否携带灰度头（即上述预设灰度头），其中普通用户的业务订购请求不带灰度头，灰度发布测试用户的业务订购请求带有灰度头。发送的请求经过中间件（Ingress）转发，通过在Ingress中配置转发规则，根据请求消息是否携带灰度头定义，带灰度头的请求消息转到灰度版的微服务，不带灰度头的请求消息转到非灰度版的服务。灰度头由键和值构成，一般灰度头的键是固定的，灰度头的值是可变更的，为确保安全性可在每次灰度发布前约定灰度头的值，涉及的前后端工程进行适配即可完成灰度发布。对订购产品A生成订单业务，带灰度头的请求消息转发到产品A业务1灰度微服务，不带灰度头的请求消息转发到产品A业务1非灰度微服务，如图5所示。

消息消费记录中可包括但不限于业务订单标识、订单类型、消费时间、答复时间字段，业务订单标识全局唯一，消费时间和答复时间标识消息记录创建时间和应答时间。为了保证消息队列消息幂等性，本申请中消息消费记录持久化选用关系型数据库MySQL实现。

产品A业务2微服务接收业务请求消息并获取消息内容，消息内容可包括但不限于业务订单标识（订单项标识）、订单类型等，消息并发场景下，通过Redis缓存对业务订单标识加锁。因此，在消费者消费消息时，首先获取业务订单标识锁，若获取锁成功，根据业务订单标识查询MySQL数据库中的消息消费记录（即查询MySQL数据库消息幂等表）是否有该业务订单标识对应的记录，如果没有查询到对应的消费记录，说明是新订单，消息消费记录中插入该业务订单标识对应的一条记录，进行数据的持久化，然后消费消息开通对应的资源，最后更新消息应答时间；如果在MySQL数据库的消息消费记录查询到对应的消费记录，说明该条消息是重复消息，直接过滤该消息不做处理，从而保证消息的幂等性。图6为消息队列实现消息幂等性流程示意图。

灰度发布场景下产品A业务2微服务的灰度版和产品A业务2微服务的非灰度版同时存在，两者随机收到订单微服务发送的第一业务请求消息，收到第一业务请求消息后如果不做处理直接消费，产品A业务2微服务的灰度版和产品A业务2微服务的非灰度版均可能消费消息，即出现产品A业务2微服务的非灰度版消费测试用户订购的消息和产品A业务2微服务额灰度版消费非测试账号订购的消息，消息的最终消费对象不确定，无法保证消息的消费对象具有对应性。本申请实施例中，灰度发布消息队列消息对应性通过引入灰度头和Feign形式调用实现，保留初始请求（业务订购请求消息）的灰度头和请求转发，在SpringBoot微服务中通过Controller层的接口实现。

产品A后端微服务有多个，如产品A业务1微服务、产品A业务2微服务、产品A业务N微服务等，产品服务间调用一般通过Feign形式调用或RestTemplate形式调用。产品A关联灰度发布的业务微服务可配置一个过滤器，过滤器名称为IsGrayHeaderFilter，该过滤器拦截服务请求，并判断请求中是否有灰度头，如果带有灰度头，则可认为对应的用户为灰度用户，可将该用户的标识存储至缓存中，如果不带灰度头则可认为该用户为灰度用户为非灰度用户。Feign形式调用通过IsGrayFeignInterceptor拦截器拦截业务请求消息并在请求头中塞入灰度头，RestTemplate形式调用通过IsGrayRestTemplateInterceptor拦截器拦截请求并在请求头中塞入灰度头，从而保证产品A业务微服务间请求消息调用保留初始请求灰度头。

灰度发布场景下，产品A业务1微服务可将测试用户的标识存储在Redis缓存，产品A业务2微服务灰度版（灰度工程）和产品A业务2微服务非灰度版（非灰度工程）都有可能接收到消息，无论哪个工程收到消息先根据用户信息去Redis缓存查询是否存在消息中用户的标识。如果查询到，则将业务订购请求消息中的灰度头对应的预设灰度值塞记录到上下文，然后以Feign形式调用转发请求，IsGrayFeignInterceptor拦截器拦截第一业务请求消息后添加头信息，可基于第一业务请求消息和灰度头生成第一请求（包括第一业务请求消息中的消息内容和灰度头，即添加了头信息）；如果没有查询到该用户的标识，则以Feign形式调用转发请求，拦截器拦截第一业务请求消息后不添加头信息，可基于第一业务请求消息生成第二请求（包括第一业务请求消息中的消息内容，无需添加头信息）。被转发的请求经过Ingress，若转发的请求有头信息则转到产品A业务2微服务灰度工程，否则转到产品A业务2微服务非灰度工程。最终消息消费通过产品A业务2微服务的Controller层接口实现，使灰度发布消息队列消息消费的对应性，流程如图7所示。

本申请实施例提供了了一种消息队列消息消费者端实现消息幂等性方法，通过过滤重复发送的消息，提高了重要资源开通和资金转账等业务数据的正确性。也提供了一种基于灰度发布消息队列对应性方法，在发送请求消息中引入灰度头，收到请求消息后将灰度头塞入到上下文中，通过请求转发保留初始请求灰度头，使非灰度用户对应的消息被非灰度工程消费，灰度用户对应的消息被灰度工程消费，实现消息的精准消费。与相关技术相比，本申请提案的优点包括但不限于：

相比Redis持久化消息队列消息消费记录，使用MySQL数据库持久化更适用于消息重复消息限制要求高场景，如重要资源开通和资金等业务，避免多次消费消息造成数据混乱和企业资产流失；在持久化消息队列消息消费记录数据库出现问题，如安装Redis的主机出现断电等情况数据易丢失，MySQL相比Redis数据恢复完整性更高；

本申请是在灰度发布中引入灰度头和请求转发消息，请求转发消息可在现有应用工程内实现，无需引入其他工程和中转服务器，增强了服务的可靠性；本申请引入的灰度头由键和值构成，一般灰度头的键是固定的，灰度头的值是可变更的，可在每次灰度发布前动态调整灰度头的值，防止用户通过伪造灰度头访问灰度服务，提升了安全性；本申请提出的基于灰度发布消息队列对应性方法引入灰度头和请求转发消息，通过拦截器、过滤器和上下文保留初始请求灰度头，效率较高，使灰度发布消息队列消息具有对应性，提升企业软件服务升级效率。

如图8所示，图8是本申请实施例提供的一种消息处理装置800的结构示意图，可应用于第一产品的第一服务，如图8所示，消息处理装置800包括：

第一接收模块801，用于在第一产品的灰度发布场景下，接收第一业务请求消息，其中，第一业务请求消息中包括第一用户的标识，在灰度发布场景下第一服务具有灰度版和非灰度版；

第一处理模块802，用于：

在确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求，第一请求中包括预设灰度头以及第一业务请求消息中的消息内容；将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费第一请求；

在确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求，第二请求中包括第一业务请求消息中的消息内容；将第二请求传输至非灰度版的第一服务，以使非灰度版的第一服务消费第二请求。

在一个实施例中，将第一请求传输至灰度版的第一服务，包括：通过中间件将第一请求转发至灰度版的第一服务；

将第二请求传输至非灰度版的第一服务，包括：通过中间件将第二请求转发至非灰度版的第一服务。

在一个实施例中，消息处理装置800还包括以下至少一项：

第一确定单元，用于在缓存中查询到第一用户的标识的情况下，确定第一用户为灰度发布测试用户；其中，缓存用于存储灰度发布场景下测试用户的标识；

第二确定单元，用于在缓存中未查询到第一用户的标识的情况下，确定第一用户为灰度发布非测试用户。

在一个实施例中，消息处理装置800还包括：

订购请求消息接收模块，用于通过第一产品的第二服务接收业务订购请求消息，业务订购请求消息中包括第二用户的标识；

存储模块，用于在业务订购请求消息中包括预设灰度头的情况下，通过第二服务将第二用户的标识存储到缓存中，预设灰度头用于指示第二用户为测试用户。

在一个实施例中，在确定第一用户为灰度发布测试用户的情况下，装置还包括：

存放模块，用于将预设灰度头放入上下文中；

第一处理模块802，包括：

第一生成模块，用于在上下文中读取到预设灰度头的情况下，根据预设灰度头以及第一业务请求消息生成第一请求。

在一个实施例中，装置还包括：

查询模块，用于在历史消息消费记录中查询是否包括第一业务请求消息中业务订单信息对应的消费记录；

在确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求，包括：在历史消息消费记录中未查询到第一请求对应的消费记录，且确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求；

在确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求，包括：在历史消息消费记录中未查询到第一请求对应的消费记录，且确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求。

在一个实施例中，缓存中存储有多个请求消息中每个请求消息中的业务订单信息，且缓存中已为每个业务订单信息加锁，多个请求消息中包括第一业务请求消息；

在历史消息消费记录中查询是否包括第一业务请求消息中业务订单信息对应的消费记录，包括：

在获取第一业务请求消息中业务订单信息的锁成功的情况下，根据第一业务请求消息中业务订单信息查询历史消息消费记录。

本实施例提供的消息处理装置800能实现上述应用于消息处理方法的各实施例的各个过程，技术特征一一对应，且能达到相同的技术效果，为避免重复，这里不再赘述。

参见图9，图9是本申请实施例提供的一种消息处理装置900的结构示意图，应用于灰度版的第一服务，如图9所示，消息处理装置900包括：

第二接收模块901，用于接收第一请求，第一请求为基于预设灰度头以及第一业务请求消息生成的请求，第一请求中包括预设灰度头以及第一业务请求消息中的消息内容，第一业务请求消息为在第一产品的灰度发布场景下的业务请求，第一业务请求消息中包括第一用户的标识，第一用户为灰度发布场景下的灰度发布测试用户，灰度版的第一服务为在灰度发布场景下第一服务的灰度版；

第一消费模块902，用于对第一请求进行消费。

在一个实施例中，消息处理装置900还包括：

第一添加模块，用于第一消费模块902对第一请求进行消费之后，在历史消息消费记录中添加第一请求中业务订单信息对应的消费记录。

本实施例提供的消息处理装置900为能实现上述应用于灰度版的第一服务的消息处理方法的各实施例的各个过程，技术特征一一对应，且能达到相同的技术效果，为避免重复，这里不再赘述。

参见图10，图10是本申请实施例提供的一种消息处理装置1000的结构示意图，如图10所示，消息处理装置1000包括：

第三接收模块1001，用于接收第二请求，第二请求为基于第一业务请求消息生成的请求，第二请求中包括第一业务请求消息中的消息内容，第一业务请求消息为在第一产品的灰度发布场景下的业务请求，第一业务请求消息中包括第一用户的标识，第一用户为灰度发布场景下的灰度发布非测试用户，非灰度版的第一服务为在灰度发布场景下第一服务的非灰度版；

第二消费模块1002，用于对第二请求进行消费。

在一个实施例中，消息处理装置1000还包括：

第二添加模块，用于第二消费模块1002对第二请求进行消费之后，在历史消息消费记录中添加第二请求中业务订单信息对应的消费记录。

本实施例提供的消息处理装置1000为能实现上述应用于非灰度版的第一服务的消息处理方法的各实施例的各个过程，技术特征一一对应，且能达到相同的技术效果，为避免重复，这里不再赘述。

本申请实施例还提供了一种电子设备，包括：处理器、存储器及存储在存储器上并可在处理器上运行的程序，程序被处理器执行时实现上述消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

具体的，参见图11，本申请实施例还提供了一种电子设备，可应用于第一产品的第一服务，该电子设备包括总线1101、收发机1102、天线1103、总线接口1104、处理器1105和存储器1106。

其中，处理器1105，用于：

在第一产品的灰度发布场景下，通过收发机接收第一业务请求消息，其中，第一业务请求消息中包括第一用户的标识，在灰度发布场景下第一服务具有灰度版和非灰度版；

在确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求，第一请求中包括预设灰度头以及第一业务请求消息中的消息内容；将第一请求传输至灰度版的第一服务，以使灰度版的第一服务消费第一请求；

在确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求，第二请求中包括第一业务请求消息中的消息内容；将第二请求传输至非灰度版的第一服务，以使非灰度版的第一服务消费第二请求。

在一个实施例中，将第一请求传输至灰度版的第一服务，包括：通过中间件将第一请求转发至灰度版的第一服务；

将第二请求传输至非灰度版的第一服务，包括：通过中间件将第二请求转发至非灰度版的第一服务。

在一个实施例中，处理器1105，还用于：

在缓存中查询到第一用户的标识的情况下，确定第一用户为灰度发布测试用户；其中，缓存用于存储灰度发布场景下测试用户的标识；

在缓存中未查询到第一用户的标识的情况下，确定第一用户为灰度发布非测试用户。

在一个实施例中，处理器1105，还用于：

通过第一产品的第二服务接收业务订购请求消息，业务订购请求消息中包括第二用户的标识；

在业务订购请求消息中包括预设灰度头的情况下，通过第二服务将第二用户的标识存储到缓存中，预设灰度头用于指示第二用户为测试用户。

在一个实施例中，在确定第一用户为灰度发布测试用户的情况下，处理器1105，还用于：

将预设灰度头放入上下文中；

处理器1105，具体用于：

在上下文中读取到预设灰度头的情况下，根据预设灰度头以及第一业务请求消息生成第一请求。

在一个实施例中，处理器1105，还用于：

在历史消息消费记录中查询是否包括第一业务请求消息中业务订单信息对应的消费记录；

处理器1105，具体用于：在历史消息消费记录中未查询到第一请求对应的消费记录，且确定第一用户为灰度发布测试用户的情况下，基于预设灰度头以及第一业务请求消息生成第一请求；

处理器1105，具体用于：在历史消息消费记录中未查询到第一请求对应的消费记录，且确定第一用户为灰度发布非测试用户的情况下，基于第一业务请求消息生成第二请求。

在一个实施例中，缓存中存储有多个请求消息中每个请求消息中的业务订单信息，且缓存中已为每个业务订单信息加锁，多个请求消息中包括第一业务请求消息；

处理器1105，具体用于：在获取第一业务请求消息中业务订单信息的锁成功的情况下，根据第一业务请求消息中业务订单信息查询历史消息消费记录。

在图11中，总线架构（用总线1101来代表），总线1101可以包括任意数量的互联的总线和桥，总线1101将包括由处理器1105代表的一个或多个处理器和存储器1106代表的存储器的各种电路链接在一起。总线1101还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口1104在总线1101和收发机1102之间提供接口。收发机1102可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1105处理的数据通过天线1103在无线介质上进行传输，进一步，天线1103还接收数据并将数据传送给处理器1105。

处理器1105负责管理总线1101和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1106可以被用于存储处理器1105在执行操作时所使用的数据。

可选的，处理器1105可以是中央处理器（Central Processing Unit，CPU）、专用集成电路（Application Specific Integrated Circuit，ASIC）、现场可编程门阵列（Field－Programmable Gate Array，FPGA）或复杂可编程逻辑器件（Complex Programmable LogicDevice，CPLD）。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，的计算机可读存储介质，如只读存储器（Read-Only Memory，ROM）、随机存取存储器（Random Access Memory，RAM）、磁碟或者光盘等。

本申请实施例还提供了一种电子设备，包括：处理器、存储器及存储在存储器上并可在处理器上运行的程序，程序被处理器执行时实现上述应用于灰度版的第一服务的消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

具体的，参见图12所示，本申请实施例还提供了一种电子设备，可应用于灰度版的第一服务，该电子设备包括总线1201、收发机1202、天线1203、总线接口1204、处理器1205和存储器1206。

其中，处理器1205，用于：

通过收发机接收第一请求，第一请求为基于预设灰度头以及第一业务请求消息生成的请求，第一请求中包括预设灰度头以及第一业务请求消息中的消息内容，第一业务请求消息为在第一产品的灰度发布场景下的业务请求，第一业务请求消息中包括第一用户的标识，第一用户为灰度发布场景下的灰度发布测试用户，灰度版的第一服务为在灰度发布场景下第一服务的灰度版；

对第一请求进行消费。

在一个实施例中，处理器1205，还用于：

对第一请求进行消费之后，在历史消息消费记录中添加第一请求中业务订单信息对应的消费记录。

在图12中，总线架构（用总线1201来代表），总线1201可以包括任意数量的互联的总线和桥，总线1201将包括由处理器1205代表的一个或多个处理器和存储器1206代表的存储器的各种电路链接在一起。总线1201还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口1204在总线1201和收发机1202之间提供接口。收发机1202可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1205处理的数据通过天线1203在无线介质上进行传输，进一步，天线1203还接收数据并将数据传送给处理器1205。

处理器1205负责管理总线1201和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1206可以被用于存储处理器1205在执行操作时所使用的数据。

可选的，处理器1205可以是CPU、ASIC、FPGA或CPLD。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述应用于灰度版的第一服务的消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，的计算机可读存储介质，如ROM、RAM、磁碟或者光盘等。

本申请实施例还提供了一种电子设备，包括：处理器、存储器及存储在存储器上并可在处理器上运行的程序，程序被处理器执行时实现上述应用于非灰度版的第一服务的消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。

具体的，参见图13所示，本申请实施例还提供了一种电子设备，包括总线1301、收发机1302、天线1303、总线接口1304、处理器1305和存储器1306。

其中，处理器1305，用于：

通过收发机1302接收第二请求，第二请求为基于第一业务请求消息生成的请求，第二请求中包括第一业务请求消息中的消息内容，第一业务请求消息为在第一产品的灰度发布场景下的业务请求，第一业务请求消息中包括第一用户的标识，第一用户为灰度发布场景下的灰度发布非测试用户，非灰度版的第一服务为在灰度发布场景下第一服务的非灰度版；

对第二请求进行消费。

在一个实施例中，处理器1305，还用于：

对第二请求进行消费之后，在历史消息消费记录中添加第二请求中业务订单信息对应的消费记录。

在图13中，总线架构（用总线1301来代表），总线1301可以包括任意数量的互联的总线和桥，总线1301将包括由处理器1305代表的一个或多个处理器和存储器1306代表的存储器的各种电路链接在一起。总线1301还可以将诸如外围设备、稳压器和功率管理电路等之类的各种其他电路链接在一起，这些都是本领域所公知的，因此，本文不再对其进行进一步描述。总线接口1304在总线1301和收发机1302之间提供接口。收发机1302可以是一个元件，也可以是多个元件，比如多个接收器和发送器，提供用于在传输介质上与各种其他装置通信的单元。经处理器1305处理的数据通过天线1303在无线介质上进行传输，进一步，天线1303还接收数据并将数据传送给处理器1305。

处理器1305负责管理总线1301和通常的处理，还可以提供各种功能，包括定时，外围接口，电压调节、电源管理以及其他控制功能。而存储器1306可以被用于存储处理器1305在执行操作时所使用的数据。

可选的，处理器1305可以是CPU、ASIC、FPGA或CPLD。

本申请实施例还提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，该计算机程序被处理器执行时实现上述应用于非灰度版的第一服务的消息处理方法实施例的各个过程，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，的计算机可读存储介质，如ROM、RAM、磁碟或者光盘等。

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

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件，但很多情况下前者是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质（如ROM/RAM、磁碟、光盘）中，包括若干指令用以使得一台终端（可以是手机，计算机，服务器，空调器，或者网络设备等）执行本申请各个实施例的方法。

上面结合附图对本申请的实施例进行了描述，但是本申请并不局限于上述的具体实施方式，上述的具体实施方式仅仅是示意性的，而不是限制性的，本领域的普通技术人员在本申请的启示下，在不脱离本申请宗旨和权利要求所保护的范围情况下，还可做出很多形式，均属于本申请的保护之内。

Claims (13)

1.一种消息处理方法，其特征在于，应用于第一产品的第一服务，所述方法包括：

在第一产品的灰度发布场景下，接收第一业务请求消息，其中，所述第一业务请求消息中包括第一用户的标识，在所述灰度发布场景下所述第一服务具有灰度版和非灰度版；

在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容；将所述第一请求传输至灰度版的第一服务，以使所述灰度版的第一服务消费所述第一请求；

在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，所述第二请求中包括所述第一业务请求消息中的消息内容；将所述第二请求传输至非灰度版的第一服务，以使所述非灰度版的第一服务消费所述第二请求；

其中，所述接收第一业务请求消息之后，还包括：

在历史消息消费记录中查询是否包括所述第一业务请求消息中业务订单信息对应的消费记录；

所述在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，包括：在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布测试用户的情况下，基于所述预设灰度头以及所述第一业务请求消息生成所述第一请求；

所述在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，包括：在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求；

其中，缓存中存储有多个请求消息中每个请求消息中的业务订单信息，且所述缓存中已为每个业务订单信息加锁，所述多个请求消息中包括所述第一业务请求消息；

所述在历史消息消费记录中查询是否包括所述第一业务请求消息中业务订单信息对应的消费记录，包括：

在获取所述第一业务请求消息中业务订单信息的锁成功的情况下，根据所述第一业务请求消息中业务订单信息查询所述历史消息消费记录。

2.根据权利要求1所述的方法，其特征在于，所述将所述第一请求传输至灰度版的第一服务，包括：通过中间件将所述第一请求转发至所述灰度版的第一服务；

所述将所述第二请求传输至非灰度版的第一服务，包括：通过所述中间件将所述第二请求转发至所述非灰度版的第一服务。

3.根据权利要求1所述的方法，其特征在于，所述方法还包括以下至少一项：

在缓存中查询到所述第一用户的标识的情况下，确定所述第一用户为灰度发布测试用户；其中，所述缓存用于存储所述灰度发布场景下测试用户的标识；

在所述缓存中未查询到所述第一用户的标识的情况下，确定所述第一用户为灰度发布非测试用户。

4.根据权利要求3所述的方法，其特征在于，所述接收第一业务请求消息之前，所述方法还包括：

通过所述第一产品的第二服务接收业务订购请求消息，所述业务订购请求消息中包括第二用户的标识；

在所述业务订购请求消息中包括所述预设灰度头的情况下，通过所述第二服务将所述第二用户的标识存储到所述缓存中，所述预设灰度头用于指示所述第二用户为测试用户。

5.根据权利要求4所述的方法，其特征在于，在确定所述第一用户为灰度发布测试用户的情况下，还包括：

将所述预设灰度头放入上下文中；

所述基于预设灰度头以及所述第一业务请求消息生成第一请求，包括：

在所述上下文中读取到所述预设灰度头的情况下，根据所述预设灰度头以及所述第一业务请求消息生成所述第一请求。

6.一种消息处理方法，其特征在于，应用于灰度版的第一服务，所述方法包括：

接收第一请求，所述第一请求为基于预设灰度头以及第一业务请求消息生成的请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容，所述第一业务请求消息为在第一产品的灰度发布场景下的业务请求，所述第一业务请求消息中包括第一用户的标识，所述第一用户为所述灰度发布场景下的灰度发布测试用户，所述灰度版的第一服务为在所述灰度发布场景下所述第一服务的灰度版；其中，所述第一请求为在获取所述第一业务请求消息中业务订单信息的锁成功的情况下，根据所述第一业务请求消息中业务订单信息查询历史消息消费记录，在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布测试用户的情况下，基于所述预设灰度头以及所述第一业务请求消息生成的请求；

对所述第一请求进行消费。

7.根据权利要求6所述的方法，其特征在于，所述对所述第一请求进行消费之后，还包括：

在历史消息消费记录中添加所述第一请求中业务订单信息对应的消费记录。

8.一种消息处理装置，其特征在于，应用于第一产品的第一服务，所述装置包括：

第一接收模块，用于在第一产品的灰度发布场景下，接收第一业务请求消息，其中，所述第一业务请求消息中包括第一用户的标识，在所述灰度发布场景下所述第一服务具有灰度版和非灰度版；

第一处理模块，用于：

在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容；将所述第一请求传输至灰度版的第一服务，以使所述灰度版的第一服务消费所述第一请求；

在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，所述第二请求中包括所述第一业务请求消息中的消息内容；将所述第二请求传输至非灰度版的第一服务，以使所述非灰度版的第一服务消费所述第二请求；

所述装置还包括：

查询模块，用于在历史消息消费记录中查询是否包括所述第一业务请求消息中业务订单信息对应的消费记录；

所述在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，包括：在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布测试用户的情况下，基于所述预设灰度头以及所述第一业务请求消息生成所述第一请求；

所述在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，包括：在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求；

其中，缓存中存储有多个请求消息中每个请求消息中的业务订单信息，且所述缓存中已为每个业务订单信息加锁，所述多个请求消息中包括所述第一业务请求消息；

所述在历史消息消费记录中查询是否包括所述第一业务请求消息中业务订单信息对应的消费记录，包括：

在获取所述第一业务请求消息中业务订单信息的锁成功的情况下，根据所述第一业务请求消息中业务订单信息查询所述历史消息消费记录。

9.一种消息处理装置，其特征在于，应用于灰度版的第一服务，所述装置包括：

第二接收模块，用于接收第一请求，所述第一请求为基于预设灰度头以及第一业务请求消息生成的请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容，所述第一业务请求消息为在第一产品的灰度发布场景下的业务请求，所述第一业务请求消息中包括第一用户的标识，所述第一用户为所述灰度发布场景下的灰度发布测试用户，所述灰度版的第一服务为在所述灰度发布场景下所述第一服务的灰度版；其中，所述第一请求为在获取所述第一业务请求消息中业务订单信息的锁成功的情况下，根据所述第一业务请求消息中业务订单信息查询历史消息消费记录，在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布测试用户的情况下，基于所述预设灰度头以及所述第一业务请求消息生成的请求；

第一消费模块，用于对所述第一请求进行消费。

10.一种电子设备，其特征在于，用于第一产品的第一服务，所述电子设备包括收发机和处理器，

所述处理器，用于：

在第一产品的灰度发布场景下，通过收发机接收第一业务请求消息，其中，所述第一业务请求消息中包括第一用户的标识，在所述灰度发布场景下所述第一服务具有灰度版和非灰度版；

在确定所述第一用户为灰度发布测试用户的情况下，基于预设灰度头以及所述第一业务请求消息生成第一请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容；将所述第一请求传输至灰度版的第一服务，以使所述灰度版的第一服务消费所述第一请求；

在确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求，所述第二请求中包括所述第一业务请求消息中的消息内容；将所述第二请求传输至非灰度版的第一服务，以使所述非灰度版的第一服务消费所述第二请求；

所述处理器，还用于：

在历史消息消费记录中查询是否包括所述第一业务请求消息中业务订单信息对应的消费记录；

所述处理器，具体用于：在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布测试用户的情况下，基于所述预设灰度头以及所述第一业务请求消息生成所述第一请求；

所述处理器，具体用于：在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布非测试用户的情况下，基于所述第一业务请求消息生成第二请求；

其中，缓存中存储有多个请求消息中每个请求消息中的业务订单信息，且所述缓存中已为每个业务订单信息加锁，所述多个请求消息中包括所述第一业务请求消息；

所述处理器，具体用于：在获取所述第一业务请求消息中业务订单信息的锁成功的情况下，根据所述第一业务请求消息中业务订单信息查询所述历史消息消费记录。

11.一种电子设备，其特征在于，应用于灰度版的第一服务，所述电子设备包括收发机和处理器，

所述处理器，用于：

通过所述收发机接收第一请求，所述第一请求为基于预设灰度头以及第一业务请求消息生成的请求，所述第一请求中包括所述预设灰度头以及所述第一业务请求消息中的消息内容，所述第一业务请求消息为在第一产品的灰度发布场景下的业务请求，所述第一业务请求消息中包括第一用户的标识，所述第一用户为所述灰度发布场景下的灰度发布测试用户，所述灰度版的第一服务为在所述灰度发布场景下所述第一服务的灰度版；其中，所述第一请求为在获取所述第一业务请求消息中业务订单信息的锁成功的情况下，根据所述第一业务请求消息中业务订单信息查询历史消息消费记录，在所述历史消息消费记录中未查询到所述第一业务请求消息中业务订单信息对应的消费记录，且确定所述第一用户为灰度发布测试用户的情况下，基于所述预设灰度头以及所述第一业务请求消息生成的请求；

对所述第一请求进行消费。

12.一种电子设备，其特征在于，包括：处理器、存储器及存储在所述存储器上并可在所述处理器上运行的程序，所述程序被所述处理器执行时实现如权利要求1至5中任一项所述的方法的步骤，或实现如权利要求6至7中任一项所述的方法的步骤。

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