CN115525533A - 信息处理方法、装置、计算机设备及存储介质 - Google Patents

Abstract

本申请提出一种信息处理方法、装置、计算机设备及存储介质，该信息处理方法包括：获取针对目标服务的流量请求，并根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，目标服务至少包括已完成测试的服务版本；获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。通过本申请，可以提高服务测试的灵活性。

Description

信息处理方法、装置、计算机设备及存储介质

技术领域

本发明涉及互联网技术领域，尤其涉及一种信息处理方法、装置、计算机设备及存储介质。

背景技术

灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式，采用灰度发布的思想，可以对相关产品进行灰度测试(或称之为A/B testing，A/B测试)，其中，灰度测试是指，在对已上线的产品中的一个或多个服务进行更新后，为了测试该产品中被更新服务的性能，可让一部分用户继续用产品特性A(即更新前的服务)，一部分用户开始用产品特性B(即更新后的服务)。而当前进行灰度测试时，需要对与该产品相关的全链路所涉及的每个服务进行规则配置，如该全链路涉及的服务包括服务1、服务2和服务3这三个服务，那么，开发人员则需要在开始灰度测试之前，分别在服务器1、服务2和服务3的入口服务进行规则配置，以及对非入口的服务进行规则配置等。由此可见，基于当前进行灰度测试的方式，存在灵活性较低的问题。

发明内容

本申请实施例提出了一种信息处理方法、装置、计算机设备及存储介质，可以提高服务测试的灵活性。

一方面，本申请实施例提供一种信息处理方法，该方法包括：

获取针对目标服务的流量请求，并根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，目标服务至少包括已完成测试的服务版本；

获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；

根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。

一方面，本申请实施例提供一种信息处理装置，该装置包括：

获取单元，用于获取针对目标服务的流量请求，目标服务至少包括已完成测试的服务版本；

确定单元，用于根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境；

获取单元，还用于获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；

处理单元，用于根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。

一方面，本申请实施例提供一种计算机设备，该计算机设备包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述的信息处理方法。

一方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被计算机设备的处理器读取并执行时，使得计算机设备执行上述的信息处理方法。

一方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的信息处理方法。

本申请实施例中，当获取针对目标服务的流量请求之后，可以根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境；其中，目标服务至少包括已完成测试的服务版本；接下来，可以获取目标服务的部署信息，该部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；最后，可以根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。本申请中，不同环境之间是相互隔离的，由此可以基于隔离出来的各个互不干扰的不同环境，灵活的适应各种复杂且繁琐的针对目标服务的不同版本下的测试场景。另外，可以基于请求标签统一管理流量请求，并可以将流量请求灵活切换到不同的环境，以此可以提高服务测试时的效率。

附图说明

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

图1是本申请实施例提供的一种数据处理系统的架构示意图；

图2是本申请实施例提供的一种信息处理方法的流程示意图；

图3是本申请实施例提供的一种部署环境的场景示意图；

图4是本申请实施例提供的一种下发约束规则的流程示意图；

图5a是本申请实施例提供的一种环境创建的场景示意图；

图5b是本申请实施例提供的另一种环境创建的场景示意图；

图6a是本申请实施例提供的一种规则配置界面的界面示意图；

图6b是本申请实施例提供的另一种规则配置界面的界面示意图；

图6c是本申请实施例提供的一种规则发布界面的界面示意图；

图7是本申请实施例提供的另一种信息处理方法的流程示意图；

图8是本申请实施例提供的一种信息处理装置的结构示意图；

图9是本申请实施例提供的一种计算机设备的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

本申请实施例提出一种信息处理方案，可以应用于服务网格中的全链路灰度发布，其中全链路是指一个流量请求所需要访问的所有服务构成的链路，例如一个请求当前访问链路为：服务1->服务2->服务3，该链路即为一个全链路，从而实现服务网格的全局路由，需要说明的是，本申请以任意两个服务之间的路由进行说明，可以理解的是，针对服务网格中的任意一个或多个服务，均可以参考本申请的信息处理方法的执行流程，从而在服务网格中实现全局路由。服务网格包括控制面和数据面，该方案主要具备如下特点：

(1)本方案重新设计全链路灰度发布的控制面和数据面，控制面引入环境和灰度发布的配置方式，数据面可以同步控制面所配置的相应规则。

①在控制面进行相应配置主要包括如下步骤：首先，在控制面上创建环境，将需要灰度发布的特定版本的应用部署组加入到相同环境中，并在环境中指定一个或多个部署组作为环境的入口；其次，在控制面上创建约束规则，通过设置请求参数来匹配环境入口的灰度流量，并将约束规则发布到目的环境，实现入口规则和具体环境的关联。

②数据面实时同步控制面设置的约束规则，通过服务网格的扩展机制实现全链路灰度发布的具体逻辑。

(2)通过统一的控制面配置全链路的约束规则，只需配置入口流量的约束规则和环境，操作成本低且一致性高；

(3)入口服务标识灰度流量的请求头无需要自行维护，数据面在应用部署组入口匹配到约束规则后，会自动生成和维护全局唯一的环境ID(IDentity，标识)，并将此环境ID传递到下游服务，不用的环境拥有各自唯一的环境ID，不会出现不同环境灰度流量混乱的情况。

(4)数据面优先匹配全链路约束规则，不会被其它的普通路由规则覆盖。

(5)当全链路灰度发布验证成功，恢复或完全升级业务系统，控制面通过约束规则一键删除或者更新全链路灰度发布方式，操作成本低，不易出错。

下面对本申请实施例涉及的技术术语进行介绍：

Service Mesh：译为服务网格，是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在实践中，Service Mesh通常以轻量级网络代理(称为Sidecar)阵列的形式实现，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。

sidecar：是从主应用进程中独立出来的单独进程，与主应用松散耦合，可以认为是一种代理。sidecar可以屏蔽不同编程语言的差异，统一实现微服务的可观察性、路由、全链路灰度、鉴权、限流、熔断器等功能。

部署组：执行应用批量部署的逻辑概念。一个部署组内包括多个应用实例，每个应用实例上运行相同的应用程序。

环境：环境是一组部署组的集合，是灰度发布(全局路由)规则的目的地。环境中的部署组属于不同的应用。可以认为用户通过划分环境划分出了灰度环境。

灰度发布：是软件上线过程中常见的上线方式，是指在发布过程中，将具有一定特征或者比例的流量分配到需要被验证的版本中，用来观察新的验证版本的线上运行状态。

灰度发布规则：用户在灰度发布规则上配置请求需要满足的条件。当请求满足一定条件后，可以通过灰度发布规则将流量路由到某一个环境中。

请参考图1，图1是本申请实施例提供的一种信息处理系统的架构示意图。该服务测试系统的架构图可以包括：控制面110以及数据面120。控制面110和数据面120可以分别为一台计算机设备，控制面110和数据面120也可以集成于同一台计算机设备，计算机设备可以为终端设备或者服务器。其中，该服务测试系统可以为Service Mesh(服务网格)、服务测试系统也可以为微服务框架系统，微服务框架系统包括但不限于Spring Cloud(一种分布式的微服务系统)、Dubbo(一种高性能的轻量级服务系统)、Thrift(一种基于远程过程调用的微服务系统)、grpc(一种严格接口约束的微服务系统)等。控制面110与数据面120之间可以通过有线或无线通信方式进行直接或间接地连接，本申请在此不做限制。

其中，以本申请中的控制面110和数据面120分别为一台独立的计算机设备为例进行说明，控制面110所包括的各个代理可以用于进行服务相关的配置，例如配置环境以及与所配置的环境相关联的约束规则等，数据面120所包括的各个代理可以用于服务发现，服务发现具体用于指示根据从控制面110所同步的环境以及与环境相关联的约束规则，并根据这些约束规则进行服务测试或者灰度测试等等。另外，数据面120中的服务A与服务B可以为同一个应用程序中的不同服务，也可以为不同应用程序中的不同服务。

在一种可能的实现方式中，本申请的信息处理方法可与区块链技术相结合，例如可以将约束规则集、服务的部署信息等上传至区块链中进行保存，可以保证区块链上的数据不易被篡改。其中，区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。

在一种可能的实现方式中，可以将本申请实施例提供的信息处理系统中涉及的设备可部署在区块链网络中，并作为区块链网络中的节点设备，例如可将控制面110和数据面120均当成区块链的节点设备，共同构成区块链网络。因此本申请中针对流量请求进行信息处理的相关流程可以在区块链上执行，这样既可以保证信息处理流程的公平公正化，同时可以使得信息处理流程具备可追溯性，提升信息处理流程的安全性。

在一种可能的实现方式中，由于区块链中涉及到大量的数据计算以及数据存储服务，大量的数据计算以及数据存储服务需要花费大量的计算机运营成本，因此本申请所涉及到约束规则集、服务的部署信息均可以由云技术中的云存储技术进行实现。即可将区块链通过云存储技术存储在“云”上，当需要将约束规则集、服务的部署信息存储至区块链时，可以通过云存储技术将这些数据上传到“云”上的区块链中，且当需要读取这些数据时，也可以随时从“云”上的区块链中读取数据，可以降低对终端设备的存储要求，扩大区块链的应用范围。

其中，云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念，分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量各种不同类型的存储设备(存储设备也称之为存储节点)通过应用软件或应用接口集合起来协同工作，共同对外提供数据存储和业务访问功能的一个存储系统。

在一种可能的实现方式中，本方案所提供的信息处理方法具体可以由数据面120中的代理在同步到用户在控制面110上所配置的约束规则之后来执行。数据面120中的代理获取针对目标服务(如服务B)的流量请求，并根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，目标服务至少包括已完成测试的服务版本；数据面120中的代理获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；数据面120中的代理根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。

可以理解的是，本申请实施例描述的系统架构示意图是为了更加清楚的说明本申请实施例的技术方案，并不构成对于本申请实施例提供的技术方案的限定，本领域普通技术人员可知，随着系统架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。

基于以上分析，下面结合图2对本申请的信息处理方法进行描述。请参见图2，图2是本申请实施例提供的一种信息处理方法的流程示意图。其中，该信息处理方法可以应用于计算机设备，计算机设备例如可以是车载设备、智能手机、平板电脑、智能可穿戴设备等等智能设备，计算机设备还可以为服务器，其中，该计算机设备为上述图1所示系统中的数据面对应的设备，并具体可以是该数据面中的代理设备。如图2所示，该信息处理方法可包括步骤S210～S230。其中：

S210，获取针对目标服务的流量请求，并根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，目标服务至少包括已完成测试的服务版本。

本申请中的信息处理方法可以适用于灰度发布场景。也就是说，在某一应用或者程序发布的过程中，可以通过本方案的信息处理方法，将具有一定特征或者比例的流量分配到需要被验证的版本中，用来观察新的验证版本的线上运行状态，从而完成应用的新版本的可靠发布。接下来，本申请以一个流量请求为例进行详细说明，可以理解的是，本申请针对一批或者大量的流量请求中的任意一个流量请求同样适用，其中，一批流量请求中的每个流量请求可以并行执行本申请所述的方案或者按照流量请求的接收顺序先后执行，本申请在此不做具体限定。

其中，目标服务是指用户发起的流量请求接下来即将访问的下游服务。所谓下游服务是指该流量请求当前访问的当前服务之后需要访问的服务。例如，当前服务为A，服务A的下游服务可以包括：服务B、C、D、E、F等等，而目标服务可以为服务B。另外，本申请中的环境可以为包括了一个或者多个待测试版本的目标服务的聚集地。可以理解的是，本申请中的不同环境之间是相互隔离的，也就是说环境A与环境B之间是不能进行交互或者通信的。

当然，目标服务至少包括已完成测试的服务版本，由此可以保证在流量请求不能成功访问需要被测试的服务版本下的目标服务时，该流量请求可以访问已完成测试的服务版本下的目标服务。已完成测试的服务版本下的目标服务用于在流量请求不能成功访问待测试的版本下的目标服务时，保证流量请求的可路由性，所谓的可路由性是指流量请求到达时不会被终止，可以继续进行业务访问。

本申请中，流量请求可以携带请求标签。其中，请求标签包括至少一个标签名、每个标签名对应的标签值，以及每个标签名和对应标签值之间的逻辑关系。计算机设备根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，可以包括如下流程：

获取约束规则集。其中，约束规则集包括至少一个约束规则，且一个约束规则与一个环境相关联；

从约束规则集中确定出与请求标签匹配的目标约束规则，并将目标约束规则关联的环境，作为与请求标签匹配的目标环境；

其中，与请求标签匹配包括：与请求标签中的每个标签名、对应的标签值、以及每个标签名和对应标签值之间的逻辑关系均匹配。

在一种可能的实现方式中，在确定出与请求标签匹配的目标环境之后，可以为该流量请求添加相应的环境描述信息，添加的环境描述信息可以包括目标环境的环境标识。通过这种方式，可以在确定了流量请求进入目标环境之后，为该流量请求进行标记处理，保证在该流量请求只能在目标环境中路由，而不能流入到其他环境中，并且还可以方便后续进行流量的追溯。

在一种可能的实现方式中，从约束规则集中确定出来的与请求标签匹配的目标约束规则的数量为多个。进一步地，可以分别获取多个目标约束规则分别对应的优先级(其中，每个目标约束规则对应的优先级可以在控制面进行优先级的配置)，然后，将多个优先级中的最高优先级对应的目标约束规则确定为目标约束规则。意思是说，当根据请求标签匹配到多条约束规则时，按照优先级的高低来确定最终的目标约束规则，从而确定出与请求标签相匹配的目标环境。通过这种方式，实现了多个约束规则和多个环境之间的策略控制，并采用优先级的方式来匹配多个约束规则，通过隔离出多个互不干扰的不同环境，从而可以灵活的适应各种复杂的灰度发布场景。

在一种可能的实现方式中，约束规则的配置可以包括：配置与发布规则相关的基本信息(例如规则名称)、配置请求参数规则以及发布目的地配置等。

在一种可能的实现方式中，根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，还包括如下流程：

确定流量请求当前访问的当前服务对应的部署信息，并根据部署信息，确定当前服务是否为入口服务；

在确定当前服务为入口服务时，确定与入口服务关联的环境，并根据请求标签，确定请求标签是否与入口服务关联的环境匹配。

其中，入口服务同样是从服务网格的控制面同步得到的。当前服务对应的部署信息可以包括但不限于：命名空间类型、命名空间、应用标识、部署组等。入口服务的部署信息同样包括：命名空间类型、命名空间、应用标识、部署组等，那么，根据部署信息，确定当前服务是否为入口服务意思是说，根据命名空间类型、命名空间、应用标识、部署组中的一种或者多种信息，确定当前服务是否隶属于入口服务。

在一种可能的实现方式中，若根据部署信息，确定当前服务不是入口服务，则从流量请求中获取环境描述信息；其中，环境描述信息是在确定出与流量请求中的请求标签匹配的环境后添加的。然后，根据从流量请求中获取的环境描述信息，对流量请求进行路由。

在一种可能的实现方式中，根据从流量请求中获取的环境描述信息，对流量请求进行路由，可以包括如下流程：

若从流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境，并将在目标环境中部署的针对目标服务的测试版本作为目标测试版本，以在目标环境中访问目标测试版本下的目标服务；

若从流量请求中获取环境描述信息失败，则确定目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到目标环境，并访问目标服务中已完成测试的服务版本。

通过这种方式，可以根据入口服务对流量请求进行入口匹配，然后匹配到入口服务之后，再根据与入口服务关联的环境，确定出与请求标签匹配的目标环境。在匹配到入口服务以及相应的约束规则之后，会自动生成和维护全局服务的唯一的环境标识，并将此环境标识传递到下游服务，不用的环境拥有各自唯一的环境标识，从而不会出现不同环境流量请求混乱的情况，保证了测试服务的高效性和准确性。

S220，获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识。

本申请中，目标服务可以包括多个服务版本，并且，多个服务版本中至少包括已完成测试的服务版本，还可以包括至少一个待测试的服务版本。可以将至少一个待测试的服务版本中的部分或者全部服务版本部署到相应的环境中。当然，一个环境中只可以部署目标服务的一个待测试的服务版本，并且，不同待测试的服务版本被部署到相应环境后对应的环境标识不同。例如，目标服务为B，服务B存在2个待测试的服务版本V1和V2，然后，可以将服务版本V1部署到环境1，以及将服务版本V2部署到环境2。其中，环境1对应的环境标识与环境2对应的环境标识不同。

S230，根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。

本申请中，目标服务的部署可以包括以下几种情况：

1、目标服务的目标测试版本与目标环境匹配，即被部署到目标环境；

2、目标服务的目标测试版本未被部署到任何环境；

3、目标服务的目标测试版本被部署到其他环境。

其中，针对情况1和情况2，本申请均可以访问目标测试版本下的目标服务。具体来说，针对情况1，则在目标环境中访问目标测试版本下的目标服务；针对情况2，则直接访问目标测试版本下的目标服务。

举例来说，请参见图3，图3是本申请实施例提供的一种部署环境的场景示意图。如图3所示，假设目标服务为服务B，其中服务B包括3个待测试的版本，分别为B1、B2、B3，并且B1、B2、B3分别被部署于环境1、环境2以及环境3中。服务B对应的已完成测试的服务版本可以为B0，B0部署于主链路中。环境1、环境2以及环境3之间相互隔离，主链路不署于任何一个环境。

在一种可能的实现方式中，根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，可以包括如下流程：首先，根据部署信息，确定目标服务是否存在一个或多个待测试版本，以及各待测试版本被部署到的环境；然后，确定出被部署到目标环境的待测试版本，并将确定出的待测试版本作为目标测试版本。

在一种可能的实现方式中，若根据部署信息，确定目标服务存在一个或者多个待测试的版本，并且相应待测试版本下的目标服务的部署信息中将携带对应环境的环境标识。那么，确定出被部署到目标环境的待测试版本的流程可以为：根据各待测试版本的目标服务的部署信息，确定出与目标环境对应的环境标识相同的目标部署信息；与目标部署信息对应的待测试版本，为确定出的被部署在目标环境的待测试版本。

举例来说，各待测试版本下的目标服务的部署信息中所携带的环境标识不同。例如，目标服务为B，服务B存在2个待测试的服务版本V1和V2，然后，根据服务B的部署信息可以确定服务版本V1下的服务B被部署到环境1，以及服务版本V2下的服务B被部署到环境2。假设环境1对应的环境标识为test001，环境对应的环境标识为test002，以及目标环境对应的环境标识为test001。那么，根据目标服务的部署信息，即可确定与目标环境对应的环境标识相同的目标部署信息。目标部署信息即为服务版本V1下的服务B被部署到环境1对应的环境信息，该被部署到环境1对应的环境信息携带的环境标识为test001。那么，可以确定与目标部署信息对应的待测试版本(即服务版本V1)，为确定出的被部署在目标环境的待测试版本。

在一种可能的实现方式中，若目标服务存在的任一待测试版本，均未被部署到目标环境，则对目标服务的已完成测试的服务版本进行访问。举例来说，目标服务B包括的2个待测试的服务版本V1和V2，均未被部署于环境1(假设环境1为目标环境)中，则不能在目标环境中对目标服务的待测试版本进行访问，而是对目标服务的已完成测试的服务版本进行访问。

另外，若目标服务不存在任何待测试的版本，则同样不能在目标环境中对目标服务进行访问，而是对目标服务的已完成测试的服务版本进行访问。

需要说明的是，已完成测试的服务版本下的目标服务用于在流量请求不能成功访问待测试的版本下的目标服务时，保证流量请求的可路由性，所谓的可路由性是指流量请求到达时不会被终止，可以继续进行业务访问。由于本申请中会根据流量请求优先匹配约束规则，当未成功匹配到约束规则或者匹配到相应约束规则后仍不能在目标环境中成功访问待测试版本下的目标服务时，才会进行针对目标服务的已完成测试的服务版本的访问。意思是说，本身其中红所设置的约束规则与普通约束规则之间可以实现完全隔离，并优先匹配本申请的约束规则进行服务访问，不会被普通约束规则所干扰，从而提高了服务测试的准确性以及效率。

本申请实施例中，当获取针对目标服务的流量请求之后，可以根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境；其中，目标服务至少包括已完成测试的服务版本；接下来，可以获取目标服务的部署信息，该部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；最后，可以根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。本申请中，不同环境之间是相互隔离的，由此可以基于隔离出来的各个互不干扰的不同环境，灵活的适应各种复杂且繁琐的针对目标服务的不同版本下的测试场景。另外，可以基于请求标签统一管理流量请求，并可以将流量请求灵活路由到不同的环境，以此可以提高服务测试时的效率和灵活性。

基于图2实施例对本申请信息处理方法的相关介绍，接下来，请参见图4，图4是本申请实施例提供的一种下发约束规则的流程示意图。本发明实施例主要用于对在服务网格的控制面生成约束规则集中的任一约束规则的过程，以及将生成的约束规则同步到该服务网格的数据面的过程进行详细说明。本申请可以应用于服务网格中的全链路灰度发布场景。如图4所示，该流程示意图可以包括步骤S410～S480。其中：

S410，创建环境。

本申请中，Web(网页)控制台、对象存储服务(Object Storage Service，OSS)模块(后续简称OSS控制模块)、Consul模块(服务发现模块)可以是与控制面的apiserver模块(接口服务模块)和pilot-discovery模块(服务发现和配置模块)集成于同一台计算机设备中的模块，Web控制台、OSS控制模块、Consul模块也可以是与控制面的apiserver模块和pilot-discovery模块之间建立通信连接的外接设备。

在一种可能的实现方式中，使用全链路灰度发布之前，需要先配置环境。灰度环境中包含应用中需要进行灰度测试的部署组。具体实现时，用户可以通过Web控制台创建环境。另外，创建环境可以包括但不限于：配置与环境相关的基本信息(例如环境名称)以及选择相应的部署组。

举例来说，如图5a所示，图5a是本申请实施例提供的一种环境创建的场景示意图。其中，用户所创建的环境名称可以为“test001”，并且，所创建的环境名称需要满足特定条件，例如：最长字符为60个，并且只能包括小写字母、数字以及分隔符。当然，环境名称需要满足的特定条件也可以认为更改或者设置，例如管理员可以将该条件更改为：最长字符为30个，并且只能包括大写字母、数字以及分隔符等等。进一步地，还可以进行相关的备注，备注内容可以用于指示创建的该环境的用途或者作用等等，例如备注的内容可以为“测试”。

进一步地，在完成环境创建之后，可以选择需要灰度发布的部署组加入环境，同时设置环境入口(即入口服务)。如图5b所示，图5b是本申请实施例提供的另一种环境创建的场景示意图。用户在选择相应部署组的过程中，可以根据部署组的命名空间、命名空间类型等进行相应部署组的筛选。例如用户需要将服务1的版本1进行灰度发布，则用户首先可以找到与服务1相关的部署组，然后将服务1的版本1的部署组添加至该环境中。另外，将需要灰度发布的部署组加入环境之后，可以为该环境设置环境入口。通常情况下，环境入口是一个网关(gateway)，环境入口用于对想要进入该环境的流量请求进行校验，以此来判断该流量请求是否应该进入到该环境中。同一个环境中支持多个环境入口，在请求经过每一个入口部署组时，都会判断请求是否应该进入环境中。配置环境入口的方法可以为在添加至该环境的部署组中，随机选择一个或者多个部署组作为入口部署组。

S420，创建约束规则。

在一种可能的实现方式中，服务网格的数据面可以从服务网格的控制面获取约束规则集，其中，约束规则集包括至少一个约束规则，且一个约束规则与一个环境相关联。

其中，约束规则集中的任一约束规则是从服务网格的控制面同步得到的。意思是说，约束规则集中的任一约束规则是用户在服务网格的控制面上配置后，服务网格的数据面根据用户在该控制面的配置同步得到的。在用户通过服务网格配置任意约束规则时，该服务网格可先通过显示设备显示规则配置界面，并根据在规则配置界面输入的配置参数生成相应的约束规则；其中，配置参数包括但不限于：至少一个标签名、每个标签名对应的标签值，以及每个标签名和对应标签值之间的逻辑关系。其中，逻辑关系可以包括但不限于：等于、不等于、包含、不包含、正则表达式等，本申请实施例对此不作具体限定。进一步地，可显示规则发布界面，并根据在规则发布界面输入的环境标识，将生成的约束规则，与环境标识指示的环境相关联；其中，环境标识可以为一个环境的唯一表示，环境标识可以包括但不限于：字母、符号、数字中的一种或者多种。进而该显示设备可将生成的约束规则，以及生成的约束规则和关联的环境之间的关联关系发送到控制面。其中，可以将生成的约束规则发布至相应的环境中，即可建立约束规则和环境之间的关联关系。意思是说，根据约束规则即可确定相应的环境。

在一种可能的实现方式中，用户还可以通过Web控制台创建灰度发布规则(即约束规则)，具体可以为，用户向Web控制台传入配置约束规则时所需的相关参数，然后Web控制台接收到这些相关参数后，可以生产相应的约束规则。同样的，另外，创建约束规则可以包括但不限于：配置与发布规则相关的基本信息(例如规则名称)、配置请求参数规则以及发布目的地配置等。

举例来说，首先针对创建约束规则过程中的基本设置流程，请参见图6a，图6a是本申请实施例提供的一种规则配置界面的界面示意图。其中，用户所创建的约束规则名称可以为“lane-test-rule001”，并且，所创建的约束规则的名称需要满足特定条件，例如：支持中英文字符，不超过60字符等等。当然，约束规则的名称需要满足的特定条件也可以认为更改或者设置，例如管理员可以将该条件更改为：最长字符为30个，并且只能包括大写字母、数字以及分隔符等等。进一步地，还可以进行相关的备注，备注内容可以用于指示创建的该约束规则的用途或者作用等等，例如备注的内容可以为“测试”。

接下来，在完成约束规则的基本设置之后，需要进行“请求参数规则的配置。举例来说，请参见图6b，图6b是本申请实施例提供的另一种规则配置界面的界面示意图。其中，配置请求参数规则包括但不限于：标签名、逻辑关系、标签值以及逻辑关系等等。如图6b所示的约束规则可以为：aaa等于123、bbb不等于456，约束规则可以为多条。需要说明的是，这里的标签名是用户业务中的自定义标签，自定义标签是指用户自定义的业务参数转换为用户业务中使用的标签。并且，参数名最多可以为32字节，参数值最多可以为128字符。自定义标签的来源有两种：

方式一：通过微服务网关将请求的参数转换为标签：如请求的path(通道)、query(问题)、header(请求头)中包含的业务参数，通过微服务网关的tag(标签)插件转换为标签。

方式二：用户在代码中配置标签。

另外，配置请求参数规则所对应的逻辑关系：支持等于、不等于、包含、不包含、正则表达式五种逻辑关系。其中，当选择等于和不等于时，标签值只能填写为单个值；当选择包含和不包含时，标签值可以填写多个，使用英文半角逗号分隔。规则生效关系是指：上述条件的生效逻辑关系，或(满足任一规则)、与(满足全部规则)。

最后，在约束规则的基本设置以及请求参数规则的配置之后，就可以选择目的地环境发布。如图6c所示，图6c是本申请实施例提供的一种规则发布界面的界面示意图。用户可以为所配置的约束规则配置相应的发布目的地，例如设置目的地环境为“test001”。即可完成将规则名称为“lane-test-rule001”的约束规则与环境名称为“test001”的环境之间进行对应。

在一种可能的实现方式中，全链路灰度发布支持同时生效多条规则，并支持为规则配置优先级。当同一条请求同时满足多条规则时，会优先匹配高优先级的规则。

另外，本申请时基于标签形式的约束规则匹配方式，在一种可能的实现方式中，可以扩展为基于其它形式的规则匹配方式，比如host(文件)、url(Uniform ResourceLocator，统一资源定位符)或者cookie(纯文本文件)等。

S430，规则下发。

在一种可能的实现方式中，用户在Web控制台完成环境创建以及约束规则创建之后，可以将所配置的约束规则下发至OSS控制模块。规则下发的方式可以为：Web控制台调用OSS控制模块的全局路由配置API(Application Program Interface，应用程序接口)，下发全链路约束规则。

S440，规则下发。

在一种可能的实现方式中，OSS控制模块在接收到Web控制台下发的全链路约束规则之后，OSS控制模块可以按照Service Mesh全局路由数据模型的格式重新组装配置，所谓重新组装配置可以包括格式转换，例如，OSS控制模块将全链路约束规则的格式转换为Service Mesh全局路由数据模型可以理解的格式。然后，OSS控制模块调用Service Mesh控制面的apiserver模块的restful API接口，下发全链路约束规则。

在一种可能的实现方式中，本申请中约束规则的下发可以由Web控制台在配置好约束规则之后，通过Consul模块发送至控制面的apiserver模块。约束规则的下发也可以由Web控制台在配置好约束规则之后，直接发送至控制面的apiserver模块，本申请实施例对此不作限定。

S450，保存规则。

在一种可能的实现方式中，Service Mesh控制面的apiserver模块(简称Meshapiserver模块)在获取到OSS控制模块下发的全链路约束规则之后。Mesh apiserver模块按照Mesh控制面的pilot-discovery全局路由数据模型的格式将规则保存至Consul模块。意思是说，Mesh apiserver模块将全链路约束规则的格式转换为Mesh控制面的pilot-discovery全局路由数据模型可以理解的格式。

S460，监听规则的新增、修改或删除。

其中，Service Mesh控制面的pilot-discovery模块启动时与Consul模块之间建立长连接，并监听Consul模块中全链路约束规则配置的新增、删除或修改，当有全链路约束规则(环境配置或约束规则)变更时Consul模块实时将变更内容同步给Service Mesh控制面的pilot-discovery模块。

S470，规则推送。

其中，当有全链路约束规则(环境配置或约束规则)变更时Consul模块实时将变更内容通过规则推送的方式同步给Service Mesh控制面的pilot-discovery模块。

S480，灰度扩展配置下发。

在一种可能的实现方式中，Service Mesh控制面的pilot-discovery模块接收到来自Consul模块推送的全链路约束规则之后，可以将全链路约束规则组装成xDS灰度扩展配置格式下发给Service Mesh数据面的sidecar(代理)。sidecar同步到全链路约束规则的xDS灰度扩展配置之后，可以在Service Mesh实时生效并根据相应的发布规则实现灰度发布。

本申请实施例中，在服务网格的控制面进行环境以及泳道的相关配置，将环境与约束规则之间关联起来，然后控制面配置好的环境和相应的约束规则后，可以同步到数据面中，具体为同步到数据面中的代理(如sidecar)中。后续，数据面的代理可以根据环境和相应的约束规则，对流量请求进行相应的灰度测试处理。因此实现了在应用无感知的情况下进行全链路灰度发布，从而提高了本申请信息处理的灵活性。

基于前述分析，请参见图7，图7是本申请实施例提供的另一种测试方法的流程示意图，该方法可具体由上述的计算机设备执行，如图7所示，该信息处理方法可包括步骤S701～S712。其中：

S701：获取流量请求。

具体是实现时，获取针对目标服务的流量请求，并且，流量请求中携带有请求标签。进一步地，请求标签可以包括至少一个标签名、每个标签名对应的标签值，以及每个标签名和对应标签值之间的逻辑关系。例如，请求标签可以为：aaa＝123。其中，“aaa”可以为标签名，123可以为标签名对应的标签值，“＝”可以为标签名与对应标签值之间的逻辑关系。

S702：判断当前服务是否为入口服务。

在一种可能的实现方式中，本申请判断当前服务是否为入口服务的方式可以为：确定流量请求当前访问的当前服务对应的部署信息，并根据部署信息，确定当前服务是否为入口服务。

其中，部署信息可以包括但不限于：命名空间类型、命名空间、应用标识、部署组等。入口服务的部署信息同样包括：命名空间类型、命名空间、应用标识、部署组等，那么，根据部署信息，确定当前服务是否为入口服务意思是说，根据命名空间类型、命名空间、应用标识、部署组中的一种或者多种信息，确定当前服务是否隶属于入口服务。

S703：匹配约束规则。

在一种可能的实现方式中，在根据部署信息，确定当前服务为入口服务时，可以根据流量请求所携带的请求标签匹配约束规则。其中，匹配约束规则的方式可以为：根据流量请求所携带的请求标签从大量的约束规则中匹配相应的目标约束规则。其中，与请求标签匹配包括：与请求标签中的每个标签名、对应的标签值、以及每个标签名和对应标签值之间的逻辑关系均匹配。

进一步地，在匹配约束规则的过程中，从约束规则集中确定出来的与请求标签匹配的目标约束规则的数量为多个，则可以按照约束规则的优先级进行匹配，优先级高的约束规则优先匹配。可以包括，分别获取多个目标约束规则分别对应的优先级(其中，每个目标约束规则对应的优先级可以在控制面进行优先级的配置)，然后，将多个优先级中的最高优先级对应的目标约束规则确定为目标约束规则。

S704：确定目标环境。

具体实现时，在确定了目标约束规则之后，可以将目标约束规则关联的环境，作为与请求标签匹配的目标环境。

通过这种方式，可以根据入口服务对流量请求进行入口匹配，然后匹配到入口服务之后，再根据与入口服务关联的环境，确定出与请求标签匹配的目标环境。在匹配到入口服务以及相应的约束规则之后，会自动生成和维护全局服务的唯一的环境标识，并将此环境标识传递到下游服务，不用的环境拥有各自唯一的环境标识，从而不会出现不同环境流量请求混乱的情况，保证了测试服务的高效性和准确性。

S705：在流量请求中添加环境描述信息。

在一种可能的实现方式中，确定了该流量请求所在的目标环境之后，可以将该流量进行染色处理，所谓对流量进行染色处理是指在请求流量中添加与该请求流量所匹配到的目标环境相关联的环境描述信息，为该流量请求进行标记处理，例如，添加的环境描述信息可以包括但不限于目标环境的环境标识等。因此在流量请求中添加环境描述信息后，该流量请求被染色为目标环境。从而可以保证在该流量请求只能在目标环境中路由，并且还可以方便后续进行流量的追溯。

S706：判断目标服务是否存在待测试版本。

具体实现时，在流量请求中添加环境描述信息之后，需要进一步判断目标服务是否存在一个或者多个待测试版本，以及各待测试版本被部署到的环境。

若目标服务不存在任何待测试版本，则访问已完成测试的服务版本下的目标服务。

S707：判断是否存在与目标环境对应的环境标识相同的目标部署信息。

在一种可能的实现方式中，若目标服务存在一个或者多个待测试版本，则继续判断是否存在与目标环境对应的环境标识相同的目标部署信息。

若目标服务存在的任一待测试版本均未被部署到目标环境，则访问已完成测试的服务版本下的目标服务。

S708：确定被部署到目标环境中的目标服务的目标测试版本。

在一种可能的实现方式中，根据目标服务的各待测试版本被部署到的环境，确定被部署到目标环境中的目标服务的目标测试版本。例如，假设目标服务B存在两个待测试版本V1、V2，则待测试版本V1被部署于环境1，待测试版本V2被部署于环境2，目标环境为环境1，则可以确定被部署到目标环境中的目标服务的目标测试版本为V1。

S709：访问目标测试版本下的目标服务。

具体实现时，将确定出的待测试版本作为目标测试版本，然后在目标环境中访问目标测试版本下的目标服务。

S710：判断流量请求是否携带环境描述信息。

在一种可能的实现方式中，在步骤S802判断当前服务是否为入口服务时，若确定当前服务不是入口服务，则从流量请求中获取环境描述信息。其中，环境描述信息是在确定出与流量请求中的请求标签匹配的环境后添加的。然后，根据从流量请求中获取的环境描述信息，对流量请求进行路由。

S711：将获取到的环境描述信息指示的环境作为目标环境，并将在目标环境中部署的针对目标服务的测试版本作为目标测试版本。

在一种可能的实现方式中，若从流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境，并将在目标环境中部署的针对目标服务的测试版本作为目标测试版本，以在目标环境中访问目标测试版本下的目标服务。

S712：访问已完成测试的服务版本下的目标服务。

在一种可能的实现方式中，若从流量请求中获取环境描述信息失败，则确定目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到目标环境，并访问已完成测试的服务版本下的目标服务。

在本发明实施例中，基于本申请整体设计全链路灰度发布的控制面，在服务网格中定义了环境和约束规则的概念，并将两者解耦，通过环境可以统一管理部署组，对部署组进行增加或者删除，并可以一键设置一个或者多个入口服务，通过约束规则可以基于标签统一管理请求流量，并可以将请求流量灵活切换到不同的环境。其次，服务网格数据面基于全局路由的方式实现请求流量的定义和传递，在应用无感知的情况下进行全链路灰度发布，对于用户来说，只需要关注如何定义请求流量和划分环境，理解和操作成本低。另外，实现了多个约束规则和多和环境之间的策略控制，并采用优先级的方式来匹配约束规则，通过隔离出多个互不干扰的不同环境，灵活的适应了各种复杂的灰度发布场景。最后，数据面独立实现全局路由来控制全链路灰度发布，与普通路由规则实现完全隔离，并优先匹配全局路由，不会被普通路由规则所干扰。

请参见图8，图8是本申请实施例提供的一种信息处理装置的结构示意图。该信息处理装置800可应用于图2、图4和图7所示的方法实施例中的计算机设备。信息处理装置800可以是运行于轻量节点中的一个计算机程序(包括程序代码)，例如该信息处理装置800为一个应用软件；该装置可以用于执行本申请实施例提供的方法中的相应步骤。该信息处理装置800可包括：

获取单元801，用于获取针对目标服务的流量请求，目标服务至少包括已完成测试的服务版本；

确定单元802，用于根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境；

获取单元801，还用于获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；

处理单元803，用于根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。

在一种可能的实现方式中，请求标签包括至少一个标签名、每个标签名对应的标签值，以及每个标签名和对应标签值之间的逻辑关系；确定单元802在根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境时具体用于：

获取约束规则集，约束规则集包括至少一个约束规则，且一个约束规则与一个环境相关联；

从约束规则集中确定出与请求标签匹配的目标约束规则，并将目标约束规则关联的环境，作为与请求标签匹配的目标环境；

其中，与请求标签匹配包括：与请求标签中的每个标签名、对应的标签值、以及每个标签名和对应标签值之间的逻辑关系均匹配。

在一种可能的实现方式中，约束规则集中的任一约束规则是从服务网格的控制面同步得到的；该信息处理装置800还包括：显示单元804和发送单元805。

显示单元804，用于显示规则配置界面，并根据在规则配置界面输入的配置参数生成相应的约束规则；

显示单元804显示规则发布界面，并根据在规则发布界面输入的环境标识，将生成的约束规则，与环境标识指示的环境相关联；

发送单元805，用于将生成的约束规则，以及生成的约束规则和关联的环境之间的关联关系发送到控制面。

在一种可能的实现方式中，确定单元802根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境时具体用于：

确定流量请求当前访问的当前服务对应的部署信息，并根据部署信息，确定当前服务是否为入口服务；

在确定当前服务为入口服务时，确定与入口服务关联的环境，并根据请求标签，确定请求标签是否与入口服务关联的环境匹配。

在一种可能的实现方式中，确定单元802还用于执行以下操作：

若根据部署信息，确定当前服务不是入口服务，则从流量请求中获取环境描述信息；环境描述信息是在确定出与流量请求中的请求标签匹配的环境后添加的；

根据从流量请求中获取的环境描述信息，对流量请求进行路由。

在一种可能的实现方式中，确定单元802根据从流量请求中获取的环境描述信息，对流量请求进行路由时具体用于：

若从流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境，并将在目标环境中部署的针对目标服务的测试版本作为目标测试版本，以在目标环境中访问目标测试版本下的目标服务；

若从流量请求中获取环境描述信息失败，则确定目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到目标环境，并访问已完成测试的服务版本下的目标服务。

在一种可能的实现方式中，处理单元803根据部署信息，确定被部署到目标环境中的所述目标服务的目标测试版本时具体用于：

根据部署信息，确定目标服务是否存在一个或多个待测试版本，以及各待测试版本被部署到的环境；

确定出被部署到目标环境的待测试版本，并将确定出的待测试版本作为目标测试版本。

在一种可能的实现方式中，目标服务包括的一个待测试版本被部署到一个环境中，且相应待测试版本下的目标服务的部署信息中将携带对应环境的环境标识；处理单元803确定出被部署到目标环境的待测试版本时具体用于：

根据各待测试版本的目标服务的部署信息，确定出与目标环境对应的环境标识相同的目标部署信息；

与目标部署信息对应的待测试版本，为确定出的被部署在目标环境的待测试版本。

在一种可能的实现方式中，若目标服务存在的任一待测试版本，均未被部署到目标环境，则处理单元803对目标服务的已完成测试的服务版本进行访问。

本申请实施例中，当获取针对目标服务的流量请求之后，可以根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境；其中，目标服务至少包括已完成测试的服务版本；接下来，可以获取目标服务的部署信息，该部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；最后，可以根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。本申请中，不同环境之间是相互隔离的，由此可以基于隔离出来的各个互不干扰的不同环境，灵活的适应各种复杂且繁琐的针对目标服务的不同版本下的测试场景。另外，可以基于请求标签统一管理流量请求，并可以将流量请求灵活切换到不同的环境，以此可以提高服务测试时的效率。

请参见图9，图9是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备900用于执行图2，图4和图7对应的方法实施例中计算机设备所执行的步骤，该计算机设备900包括：一个或多个处理器910；一个或多个输入设备920，一个或多个输出设备930和存储器940。上述处理器910、输入设备920、输出设备930和存储器940通过总线950连接。存储器940用于存储计算机程序，所述计算机程序包括程序指令，处理器910用于调用存储器940存储的程序指令，执行以下操作：

获取针对目标服务的流量请求，并根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境，目标服务至少包括已完成测试的服务版本；

获取目标服务的部署信息，部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；

根据部署信息，确定被部署到目标环境中的目标服务的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。

在一种可能的实现方式中，请求标签包括至少一个标签名、每个标签名对应的标签值，以及每个标签名和对应标签值之间的逻辑关系；处理器910在根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境时，调用存储器940存储的程序指令，执行以下操作：

获取约束规则集，约束规则集包括至少一个约束规则，且一个约束规则与一个环境相关联；

从约束规则集中确定出与请求标签匹配的目标约束规则，并将目标约束规则关联的环境，作为与请求标签匹配的目标环境；

其中，与请求标签匹配包括：与请求标签中的每个标签名、对应的标签值、以及每个标签名和对应标签值之间的逻辑关系均匹配。

在一种可能的实现方式中，约束规则集中的任一约束规则是从服务网格的控制面同步得到的；处理器910还用于执行以下操作：

显示规则配置界面，并根据在规则配置界面输入的配置参数生成相应的约束规则；

显示规则发布界面，并根据在规则发布界面输入的环境标识，将生成的约束规则，与环境标识指示的环境相关联；

将生成的约束规则，以及生成的约束规则和关联的环境之间的关联关系发送到控制面。

在一种可能的实现方式中，处理器910在根据流量请求携带的请求标签，确定出与请求标签匹配的目标环境时，调用存储器940存储的程序指令，执行以下操作：

确定流量请求当前访问的当前服务对应的部署信息，并根据部署信息，确定当前服务是否为入口服务；

在确定当前服务为入口服务时，确定与入口服务关联的环境，并根据请求标签，确定请求标签是否与入口服务关联的环境匹配。

在一种可能的实现方式中，处理器910还用于执行以下操作：

若根据部署信息，确定当前服务不是入口服务，则从流量请求中获取环境描述信息；环境描述信息是在确定出与流量请求中的请求标签匹配的环境后添加的；

根据从流量请求中获取的环境描述信息，对流量请求进行路由。

在一种可能的实现方式中，处理器910在根据从流量请求中获取的环境描述信息，对流量请求进行路由时，调用存储器940存储的程序指令，执行以下操作：

若从流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境，并将在目标环境中部署的针对目标服务的测试版本作为目标测试版本，以在目标环境中访问目标测试版本下的目标服务；

若从流量请求中获取环境描述信息失败，则确定目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到目标环境，并访问已完成测试的服务版本下的目标服务。

在一种可能的实现方式中，处理器910在根据部署信息，确定被部署到目标环境中的所述目标服务的目标测试版本时，调用存储器940存储的程序指令，执行以下操作：

根据部署信息，确定目标服务是否存在一个或多个待测试版本，以及各待测试版本被部署到的环境；

确定出被部署到目标环境的待测试版本，并将确定出的待测试版本作为目标测试版本。

在一种可能的实现方式中，目标服务包括的一个待测试版本被部署到一个环境中，且相应待测试版本下的目标服务的部署信息中将携带对应环境的环境标识；处理器910在确定出被部署到目标环境的待测试版本时，调用存储器940存储的程序指令，执行以下操作：

根据各待测试版本的目标服务的部署信息，确定出与目标环境对应的环境标识相同的目标部署信息；

与目标部署信息对应的待测试版本，为确定出的被部署在目标环境的待测试版本。

在一种可能的实现方式中，若目标服务存在的任一待测试版本，均未被部署到目标环境，则处理器910对目标服务的已完成测试的服务版本进行访问。

应当理解，本申请实施例中所描述的计算机设备可执行前文图2～图7所对应实施例中对信息处理方法的描述，也可执行前文图8所对应实施例中对信息处理装置800的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。

此外，这里需要指出的是：本申请实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的信息处理装置800所执行的计算机程序，且该计算机程序包括程序指令，当处理器执行上述程序指令时，能够执行前文图2，图4和图7所对应实施例中的方法，因此，这里将不再进行赘述。对于本申请所涉及的计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可以被部署在一个计算机设备上，或者在位于一个地点的多个计算机设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算机设备上执行，分布在多个地点且通过通信网络互连的多个计算机设备可以组成区块链系统。

根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备可以执行前文图2，图4和图7所对应实施例中的方法，因此，这里将不再进行赘述。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random AccessMemory，RAM)等。

以上所揭露的仅为本申请较佳实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (12)

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

获取针对目标服务的流量请求，并根据所述流量请求携带的请求标签，确定出与所述请求标签匹配的目标环境，所述目标服务至少包括已完成测试的服务版本；

获取所述目标服务的部署信息，所述部署信息用于指示下述信息：所述目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；

根据所述部署信息，确定被部署到所述目标环境中的所述目标服务的目标测试版本，并在所述目标环境中访问所述目标测试版本下的目标服务。

2.如权利要求1所述的方法，其特征在于，所述请求标签包括至少一个标签名、每个标签名对应的标签值，以及每个标签名和对应标签值之间的逻辑关系；所述根据所述流量请求携带的请求标签，确定出与所述请求标签匹配的目标环境，包括：

获取约束规则集，所述约束规则集包括至少一个约束规则，且一个约束规则与一个环境相关联；

从所述约束规则集中确定出与所述请求标签匹配的目标约束规则，并将所述目标约束规则关联的环境，作为与所述请求标签匹配的目标环境；

其中，与所述请求标签匹配包括：与所述请求标签中的每个标签名、对应的标签值、以及每个标签名和对应标签值之间的逻辑关系均匹配。

3.如权利要求2所述的方法，其特征在于，所述约束规则集中的任一约束规则是从服务网格的控制面同步得到的；所述方法还包括：

显示规则配置界面，并根据在所述规则配置界面输入的配置参数生成相应的约束规则；

显示规则发布界面，并根据在所述规则发布界面输入的环境标识，将生成的约束规则，与所述环境标识指示的环境相关联；

将生成的约束规则，以及所述生成的约束规则和关联的环境之间的关联关系发送到所述控制面。

4.如权利要求1所述的方法，其特征在于，所述根据所述流量请求携带的请求标签，确定出与所述请求标签匹配的目标环境，包括：

确定所述流量请求当前访问的当前服务对应的部署信息，并根据所述部署信息，确定所述当前服务是否为入口服务；

在确定所述当前服务为所述入口服务时，确定与所述入口服务关联的环境，并根据所述请求标签，确定所述请求标签是否与所述入口服务关联的环境匹配。

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

若根据所述部署信息，确定所述当前服务不是所述入口服务，则从所述流量请求中获取环境描述信息；所述环境描述信息是在确定出与所述流量请求中的请求标签匹配的环境后添加的；

根据从所述流量请求中获取的环境描述信息，对所述流量请求进行路由。

6.如权利要求5所述的方法，其特征在于，所述根据从所述流量请求中获取的环境描述信息，对所述流量请求进行路由，包括：

若从所述流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境，并将在所述目标环境中部署的针对所述目标服务的测试版本作为目标测试版本，以在所述目标环境中访问所述目标测试版本下的目标服务；

若从所述流量请求中获取环境描述信息失败，则确定所述目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到所述目标环境，并访问已完成测试的服务版本下的目标服务。

7.如权利要求1所述的方法，其特征在于，所述根据所述部署信息，确定被部署到所述目标环境中的所述目标服务的目标测试版本，包括：

根据所述部署信息，确定所述目标服务是否存在一个或多个待测试版本，以及各待测试版本被部署到的环境；

确定出被部署到所述目标环境的待测试版本，并将确定出的待测试版本作为目标测试版本。

8.如权利要求7所述的方法，其特征在于，所述目标服务包括的一个待测试版本被部署到一个环境中，且相应待测试版本下的目标服务的部署信息中将携带对应环境的环境标识；所述确定出被部署到所述目标环境的待测试版本，包括：

根据各待测试版本的目标服务的部署信息，确定出与所述目标环境对应的环境标识相同的目标部署信息；

与所述目标部署信息对应的待测试版本，为确定出的被部署在所述目标环境的待测试版本。

9.如权利要求7所述的方法，其特征在于，所述方法还包括：

若所述目标服务存在的任一待测试版本，均未被部署到所述目标环境，则对所述目标服务的已完成测试的服务版本进行访问。

10.一种信息处理装置，其特征在于，所述装置包括：

获取单元，用于获取针对目标服务的流量请求，所述目标服务至少包括已完成测试的服务版本；

确定单元，用于根据所述流量请求携带的请求标签，确定出与所述请求标签匹配的目标环境；

所述获取单元，还用于获取所述目标服务的部署信息，所述部署信息用于指示下述信息：所述目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；

处理单元，用于根据所述部署信息，确定被部署到所述目标环境中的所述目标服务的目标测试版本，并在所述目标环境中访问所述目标测试版本下的目标服务。

11.一种计算机设备，其特征在于，包括：

处理器，适于执行计算机程序；

计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1～9任一项所述的信息处理方法。

12.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于由处理器加载并执行如权利要求1～9任一项所述的信息处理方法。

Images