Information processing method and device, computer device and storage medium

Abstract

The application provides an information processing method and device, computer equipment and a storage medium. The information processing method comprises the following steps: obtaining a traffic request for a target service, and determining a target environment matched with a request label carried by the traffic request according to the request label, wherein the target service at least comprises a service version that has completed testing; obtaining deployment information of the target service, wherein the deployment information is used for indicating the following information: whether there is a to-be-tested version of the target service, whether each to-be-tested version has been deployed to a corresponding environment, and a corresponding environment identifier after being deployed to the corresponding environment; determining a target test version of the target service deployed to the target environment according to the deployment information, and accessing the target service under the target test version in the target environment. Through the application, the flexibility of service testing can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of Internet, and in particular to an information processing method and device, computer equipment and a storage medium. BACKGROUND

[0002] Gray release refers to a release mode capable of smooth transition between black and white. The idea of gray release can be used for gray test (or A / B test) of related products. The gray test refers to, after one or more services in an online product are updated, to test the performance of the updated services in the product, a part of users continue to use product feature A (i.e. the service before the update), and a part of users start to use product feature B (i.e. the service after the update). When the gray test is performed, rules of each service involved in the whole link related to the product need to be configured. For example, the services involved in the whole link include service 1, service 2 and service 3. Therefore, before the gray test is started, the developer needs to configure rules in the entry services of service 1, service 2 and service 3, and configure rules for non-entry services. It can be seen that the current gray test method has the problem of low flexibility. SUMMARY

[0003] The embodiments of the present application provide an information processing method and device, computer equipment and a storage medium, which can improve the flexibility of service test.

[0004] In one aspect, the embodiments of the present application provide an information processing method, which includes:

[0005] Obtaining a traffic request for a target service, and determining a target environment matched with a request label carried in the traffic request according to the request label, the target service including at least a service version that has completed test;

[0006] Obtaining deployment information of the target service, the deployment information being used to indicate whether there is a version to be tested in the target service, whether each version to be tested has been deployed to a corresponding environment, and the corresponding environment identifier after being deployed to the corresponding environment;

[0007] Determining a target test version of the target service deployed to the target environment according to the deployment information, and accessing the target service under the target test version in the target environment.

[0008] In one aspect, the embodiments of the present application provide an information processing device, which includes:

[0009] An obtaining unit, configured to obtain a traffic request for a target service, the target service including at least a service version that has completed test;

[0010] The determining unit is used to determine the target environment that matches the request tag based on the request tag carried by the traffic request;

[0011] The acquisition unit is also used to acquire the deployment information of the target service. The deployment information is used to indicate the following: whether there is a version of the target service to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier after being deployed to the corresponding environment.

[0012] The processing unit is used to determine the target test version of the target service to be deployed to the target environment based on the deployment information, and to access the target service under the target test version in the target environment.

[0013] On one hand, embodiments of this application provide a computer device, which includes a memory and a processor. The memory stores a computer program, and when the computer program is executed by the processor, the processor performs the information processing method described above.

[0014] On one hand, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when read and executed by a processor of a computer device, causes the computer device to perform the aforementioned information processing method.

[0015] On one hand, embodiments of this application provide a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned information processing method.

[0016] In this embodiment, after obtaining a traffic request for a target service, the target environment matching the request tag can be determined based on the request tag carried by the traffic request. The target service includes at least a service version that has completed testing. Next, the deployment information of the target service can be obtained, which indicates whether a version of the target service exists to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier corresponding to its deployment. Finally, based on the deployment information, the target test version of the target service deployed to the target environment can be determined, and the target service under the target test version can be accessed in the target environment. In this application, different environments are isolated from each other, thus allowing for flexible adaptation to various complex and cumbersome testing scenarios for different versions of the target service based on these isolated, non-interfering environments. Furthermore, traffic requests can be uniformly managed based on request tags, and traffic requests can be flexibly switched to different environments, thereby improving the efficiency of service testing. Attached Figure Description

[0017] To more clearly illustrate the technical solutions of the embodiments of this application, the drawings used in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0018] Figure 1 This is a schematic diagram of the architecture of a data processing system provided in an embodiment of this application;

[0019] Figure 2 This is a flowchart illustrating an information processing method provided in an embodiment of this application;

[0020] Figure 3 This is a schematic diagram of a deployment environment provided in an embodiment of this application;

[0021] Figure 4 This is a schematic diagram of a process for issuing constraint rules provided in an embodiment of this application;

[0022] Figure 5a This is a schematic diagram of an environment creation scenario provided in an embodiment of this application;

[0023] Figure 5b This is a schematic diagram of another environment creation scenario provided in the embodiments of this application;

[0024] Figure 6a This is a schematic diagram of a rule configuration interface provided in an embodiment of this application;

[0025] Figure 6b This is a schematic diagram of another rule configuration interface provided in an embodiment of this application;

[0026] Figure 6c This is a schematic diagram of a rule publishing interface provided in an embodiment of this application;

[0027] Figure 7 This is a flowchart illustrating another information processing method provided in an embodiment of this application;

[0028] Figure 8 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application;

[0029] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. Detailed Implementation

[0030] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0031] This application proposes an information processing scheme that can be applied to full-link canary deployment in a service mesh. The full-link refers to the link consisting of all services accessed by a traffic request. For example, if a request's current access link is: Service 1 -> Service 2 -> Service 3, this link constitutes a full-link, thereby achieving global routing in the service mesh. It should be noted that this application describes routing between any two services; however, it can be understood that the execution flow of the information processing method in this application can be referenced for any one or more services in the service mesh to achieve global routing within the service mesh. The service mesh includes a control plane and a data plane. This scheme mainly has the following characteristics:

[0032] (1) This solution redesigns the control plane and data plane of the entire link canary release. The control plane introduces the configuration method of environment and canary release, and the data plane can synchronize the corresponding rules configured by the control plane.

[0033] ① The corresponding configuration on the control plane mainly includes the following steps: First, create an environment on the control plane, add the application deployment group of the specific version that needs to be released in the canary release to the same environment, and specify one or more deployment groups as the entry point of the environment; Second, create constraint rules on the control plane, match the canary traffic of the environment entry point by setting request parameters, and publish the constraint rules to the target environment to realize the association between the entry rules and the specific environment.

[0034] ② The constraint rules set by the control plane are synchronized in real time with the data plane, and the specific logic of the full-link canary release is realized through the service mesh expansion mechanism.

[0035] (2) By configuring the constraint rules of the entire link through a unified control plane, only the constraint rules and environment of the ingress traffic need to be configured, resulting in low operation cost and high consistency;

[0036] (3) The request header of the entry service identifier gray traffic does not need to be maintained by itself. After the data plane matches the constraint rules at the application deployment group entry, it will automatically generate and maintain a globally unique environment ID (IDentity) and pass this environment ID to the downstream service. Different environments have their own unique environment IDs, so there will be no situation of gray traffic confusion in different environments.

[0037] (4) Data plane prioritizes matching full-link constraint rules and will not be covered by other ordinary routing rules.

[0038] (5) When the full-link gray release verification is successful, the business system is restored or fully upgraded. The control plane can delete or update the full-link gray release method with one click through the constraint rules. The operation cost is low and it is not easy to make mistakes.

[0039] The technical terms used in the embodiments of this application are described below:

[0040] Service Mesh is an infrastructure layer that handles communication between services. It is responsible for reliably delivering requests across the complex service topologies of modern cloud-native applications. In practice, Service Mesh is typically implemented as an array of lightweight network proxies (called Sidecars), which are deployed alongside the application code and whose existence is unknown to the application.

[0041] A sidecar is a separate process independent of the main application process, loosely coupled to the main application, and can be considered a proxy. Sidecars can shield the differences between different programming languages, uniformly implementing microservice observability, routing, end-to-end canary deployments, authentication, rate limiting, circuit breakers, and other functionalities.

[0042] Deployment Group: A logical concept for performing batch deployments of applications. A deployment group contains multiple application instances, each running the same application.

[0043] Environment: An environment is a collection of deployment groups and serves as the destination for canary deployment (global routing) rules. Deployment groups within an environment belong to different applications. It can be considered that users create canary environments by dividing them into different groups.

[0044] Gray release: This is a common deployment method in the software launch process. It refers to the distribution of traffic with certain characteristics or proportions to the version that needs to be verified during the release process, in order to observe the online running status of the new verification version.

[0045] Canary release rules: Users configure the conditions that requests must meet in canary release rules. Once a request meets certain conditions, traffic can be routed to a specific environment through canary release rules.

[0046] Please refer to Figure 1 , Figure 1This is a schematic diagram of the architecture of an information processing system provided in an embodiment of this application. The architecture of this service testing system may include a control plane 110 and a data plane 120. The control plane 110 and data plane 120 can each be a separate computer device, or they can be integrated into the same computer device, which can be a terminal device or a server. The service testing system can be a Service Mesh or a microservice framework system. Microservice framework systems include, but are not limited to, Spring Cloud (a distributed microservice system), Dubbo (a high-performance lightweight service system), Thrift (a microservice system based on remote procedure calls), and gRPC (a microservice system with strict interface constraints). The control plane 110 and data plane 120 can be directly or indirectly connected via wired or wireless communication, which is not limited herein.

[0047] Taking the control plane 110 and data plane 120 as separate computer devices as an example, the agents included in the control plane 110 can be used for service-related configurations, such as configuring the environment and the constraint rules associated with the configured environment. The agents included in the data plane 120 can be used for service discovery. Service discovery specifically instructs the use of the environment synchronized from the control plane 110 and the constraint rules associated with the environment, and performs service testing or canary testing based on these constraint rules. Furthermore, service A and service B in the data plane 120 can be different services within the same application, or different services in different applications.

[0048] In one possible implementation, the information processing method of this application can be combined with blockchain technology. For example, constraint rule sets and service deployment information can be uploaded to the blockchain for storage, ensuring that the data on the blockchain is not easily tampered with. Blockchain is a novel application model of computer technologies such as distributed data storage, peer-to-peer transmission, consensus mechanisms, and encryption algorithms.

[0049] In one possible implementation, the devices involved in the information processing system provided in this application embodiment can be deployed in a blockchain network and used as node devices in the blockchain network. For example, both the control plane 110 and the data plane 120 can be used as blockchain node devices to jointly constitute the blockchain network. Therefore, the relevant processes for processing traffic requests in this application can be executed on the blockchain, which can ensure the fairness and impartiality of the information processing process, while also making the information processing process traceable and improving the security of the information processing process.

[0050] In one possible implementation, since blockchain involves a large amount of data computation and storage services, which require significant computer operating costs, the constraint rule sets and service deployment information involved in this application can be implemented using cloud storage technology. That is, the blockchain can be stored on the "cloud" using cloud storage technology. When it is necessary to store the constraint rule sets and service deployment information on the blockchain, this data can be uploaded to the blockchain on the "cloud" using cloud storage technology. Furthermore, when it is necessary to retrieve this data, it can be retrieved from the blockchain on the "cloud" at any time, reducing the storage requirements of terminal devices and expanding the application scope of blockchain.

[0051] Among them, cloud storage is a new concept that has been extended and developed from the concept of cloud computing. A distributed cloud storage system (hereinafter referred to as a storage system) refers to a storage system that uses cluster applications, grid technology and distributed storage file systems to bring together a large number of storage devices of various types in the network (storage devices are also called storage nodes) to work together through application software or application interfaces to provide data storage and business access functions to the outside world.

[0052] In one possible implementation, the information processing method provided by this solution can be executed by the proxy in data plane 120 after synchronizing with the constraint rules configured by the user on control plane 110. The proxy in data plane 120 obtains traffic requests for a target service (such as service B) and determines the target environment matching the request tags based on the request tags carried by the traffic requests. The target service includes at least a service version that has completed testing. The proxy in data plane 120 obtains the deployment information of the target service. The deployment information indicates the following: whether there is a version of the target service to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier corresponding to the deployment to the corresponding environment. Based on the deployment information, the proxy in data plane 120 determines the target test version of the target service deployed to the target environment and accesses the target service under the target test version in the target environment.

[0053] It is understood that the system architecture diagrams described in the embodiments of this application are for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and do not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture and the emergence of new business scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0054] Based on the above analysis, the following will combine... Figure 2 The information processing method described in this application is explained. Please refer to [link / reference]. Figure 2 , Figure 2This is a flowchart illustrating an information processing method provided in an embodiment of this application. The information processing method can be applied to a computer device, such as an in-vehicle device, smartphone, tablet computer, smart wearable device, or other intelligent device. The computer device can also be a server. Figure 1 The device corresponding to the data plane in the system shown, and specifically, it can be a proxy device within that data plane. For example... Figure 2 As shown, the information processing method may include steps S210 to S230. Wherein:

[0055] S210: Obtain traffic requests for the target service, and determine the target environment that matches the request tags based on the request tags carried by the traffic requests. The target service includes at least the service version that has been tested.

[0056] The information processing method in this application is applicable to canary release scenarios. That is, during the release of an application or program, the information processing method of this solution can be used to allocate traffic with certain characteristics or proportions to the version that needs to be verified, in order to observe the online running status of the new verification version, thereby completing the reliable release of the new version of the application. Next, this application will use a traffic request as an example for detailed explanation. It is understood that this application is also applicable to any single traffic request in a batch or a large number of traffic requests. Each traffic request in a batch can execute the solution described in this application in parallel or sequentially according to the order in which the traffic requests are received; this application does not make specific limitations here.

[0057] In this context, the target service refers to the downstream service that the user's traffic request will access next. A downstream service is the service that the traffic request needs to access after the current service it currently accesses. For example, if the current service is A, the downstream services of service A can include services B, C, D, E, F, etc., and the target service can be service B. Furthermore, the environment in this application can be a cluster containing one or more target services to be tested. It is understood that the different environments in this application are isolated from each other; that is, environment A and environment B cannot interact or communicate with each other.

[0058] Of course, the target service must include at least a service version that has completed testing. This ensures that if a traffic request cannot successfully access the target service under the service version to be tested, the traffic request can still access the target service under the service version that has completed testing. The target service under the service version that has completed testing is used to ensure the routable nature of the traffic request when the traffic request cannot successfully access the target service under the version to be tested. Routable nature means that the traffic request will not be terminated when it arrives, and business access can continue.

[0059] In this application, traffic requests may carry request tags. Each request tag includes at least one tag name, a tag value corresponding to each tag name, and a logical relationship between each tag name and its corresponding tag value. The computer device determines the target environment matching the request tag based on the request tag carried in the traffic request, which may include the following process:

[0060] Obtain the constraint rule set. The constraint rule set includes at least one constraint rule, and each constraint rule is associated with an environment.

[0061] The target constraint rule that matches the request tag is determined from the set of constraint rules, and the environment associated with the target constraint rule is taken as the target environment that matches the request tag.

[0062] Matching with request tags includes matching each tag name, its corresponding tag value, and the logical relationship between each tag name and its corresponding tag value in the request tags.

[0063] In one possible implementation, after identifying the target environment that matches the request tag, corresponding environment description information can be added to the traffic request. This added environment description information can include the environment identifier of the target environment. In this way, after determining that a traffic request has entered the target environment, it can be marked to ensure that the traffic request can only be routed within the target environment and cannot flow into other environments. This also facilitates subsequent traffic tracing.

[0064] In one possible implementation, the number of target constraint rules matching the request tag determined from the constraint rule set is multiple. Further, the priorities corresponding to each of the multiple target constraint rules can be obtained separately (where the priority of each target constraint rule can be configured in the control plane). Then, the target constraint rule corresponding to the highest priority among the multiple priorities is determined as the target constraint rule. This means that when multiple constraint rules are matched based on the request tag, the final target constraint rule is determined according to its priority, thereby determining the target environment matching the request tag. In this way, policy control between multiple constraint rules and multiple environments is achieved, and multiple constraint rules are matched using a priority-based approach. By isolating multiple non-interfering environments, it can flexibly adapt to various complex canary release scenarios.

[0065] In one possible implementation, the configuration of constraint rules may include: configuring basic information related to the publishing rule (such as the rule name), configuring request parameter rules, and configuring the publishing destination, etc.

[0066] In one possible implementation, determining the target environment that matches the request tag based on the request tag carried by the traffic request also includes the following process:

[0067] Determine the deployment information corresponding to the current service accessed by the traffic request, and determine whether the current service is the entry service based on the deployment information;

[0068] When the current service is determined to be an entry service, the environment associated with the entry service is identified, and the request tag is used to determine whether the request tag matches the environment associated with the entry service.

[0069] The entry service is also synchronized from the control plane of the service mesh. The deployment information corresponding to the current service may include, but is not limited to: namespace type, namespace, application identifier, deployment group, etc. The deployment information of the entry service also includes: namespace type, namespace, application identifier, deployment group, etc. Therefore, determining whether the current service is an entry service based on the deployment information means determining whether the current service belongs to the entry service based on one or more of the namespace type, namespace, application identifier, and deployment group.

[0070] In one possible implementation, if the deployment information determines that the current service is not the ingress service, then environment description information is obtained from the traffic request; this environment description information is added after determining that the environment matches the request tag in the traffic request. Then, the traffic request is routed based on the environment description information obtained from the traffic request.

[0071] In one possible implementation, routing traffic requests based on environment description information obtained from the traffic request may include the following process:

[0072] If environment description information is obtained from the traffic request, the environment indicated by the obtained environment description information is taken as the target environment, and the test version of the target service deployed in the target environment is taken as the target test version, so as to access the target service under the target test version in the target environment;

[0073] If obtaining environment description information from traffic requests fails, it is determined that the target service does not have a version to be tested, or that any existing version to be tested has not been deployed to the target environment, and the service version that has been tested in the target service is accessed.

[0074] In this way, traffic requests can be matched to entry points based on the entry service. After a matching entry service is found, the target environment that matches the request tag is determined based on the environment associated with that entry service. After matching the entry service and the corresponding constraint rules, a unique environment identifier for the entire service is automatically generated and maintained, and this identifier is passed to downstream services. Different environments have their own unique environment identifiers, thus preventing traffic requests from different environments from becoming mixed up, and ensuring the efficiency and accuracy of the testing service.

[0075] S220, Obtain the deployment information of the target service. The deployment information is used to indicate the following: whether there is a version of the target service to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier after being deployed to the corresponding environment.

[0076] In this application, the target service may include multiple service versions, and these multiple service versions may include at least one service version that has completed testing, and may also include at least one service version to be tested. Some or all of the service versions to be tested can be deployed to the corresponding environment. Of course, only one service version to be tested of the target service can be deployed in a single environment, and the environment identifiers corresponding to different service versions to be tested are different after deployment to the corresponding environments. For example, if the target service is B, and service B has two service versions to be tested, V1 and V2, then service version V1 can be deployed to environment 1, and service version V2 can be deployed to environment 2. The environment identifiers corresponding to environment 1 and environment 2 are different.

[0077] S230: Based on the deployment information, determine the target test version of the target service to be deployed to the target environment, and access the target service under the target test version in the target environment.

[0078] In this application, the deployment of the target service may include the following scenarios:

[0079] 1. The target test version of the target service matches the target environment, meaning it is deployed to the target environment;

[0080] 2. The target test version of the target service has not been deployed to any environment;

[0081] 3. The target test version of the target service was deployed to another environment.

[0082] In both scenarios 1 and 2, this application can access the target service under the target test version. Specifically, in scenario 1, the target service under the target test version is accessed within the target environment; in scenario 2, the target service under the target test version is accessed directly.

[0083] For example, please see Figure 3 , Figure 3 This is a schematic diagram of a deployment environment provided in an embodiment of this application. For example... Figure 3 As shown, assume the target service is service B, which includes three versions to be tested: B1, B2, and B3. B1, B2, and B3 are deployed in environments 1, 2, and 3, respectively. The service version that has completed testing for service B can be B0, which is deployed in the main pipeline. Environments 1, 2, and 3 are isolated from each other, and the main pipeline is not deployed in any of these environments.

[0084] In one possible implementation, determining the target test version of the target service deployed to the target environment based on the deployment information may include the following process: First, based on the deployment information, determine whether the target service has one or more versions to be tested, and the environment in which each version to be tested is deployed; then, determine the versions to be tested deployed to the target environment, and use the determined versions to be tested as the target test version.

[0085] In one possible implementation, if based on the deployment information, it is determined that the target service has one or more versions to be tested, and the deployment information of the target service under the corresponding version to be tested carries the environment identifier of the corresponding environment, then the process for determining the version to be tested deployed to the target environment can be as follows: based on the deployment information of the target service for each version to be tested, determine the target deployment information that has the same environment identifier as the target environment; the version to be tested corresponding to the target deployment information is the determined version to be tested deployed in the target environment.

[0086] For example, the environment identifiers carried in the deployment information of the target service under each version to be tested are different. For instance, the target service is B, and service B has two versions to be tested, V1 and V2. Based on the deployment information of service B, it can be determined that service B under version V1 is deployed to environment 1, and service B under version V2 is deployed to environment 2. Assume that the environment identifier corresponding to environment 1 is test001, the environment identifier corresponding to environment 2 is test002, and the environment identifier corresponding to the target environment is test001. Then, based on the deployment information of the target service, the target deployment information with the same environment identifier as the target environment can be determined. The target deployment information is the environment information corresponding to service B under version V1 being deployed to environment 1, and the environment identifier carried by this environment information is test001. Therefore, it can be determined that the version to be tested corresponding to the target deployment information (i.e., service version V1) is the version to be tested that has been deployed in the target environment.

[0087] In one possible implementation, if none of the test versions of the target service are deployed to the target environment, then access is granted to the tested versions of the target service. For example, if target service B includes two test versions, V1 and V2, neither of which are deployed in environment 1 (assuming environment 1 is the target environment), then access is not granted to the test versions of the target service in the target environment; instead, access is granted to the tested versions of the target service.

[0088] Additionally, if the target service does not have any versions to be tested, then the target service cannot be accessed in the target environment; instead, access will be made to the tested version of the target service.

[0089] It should be noted that the target service under the tested version is used to ensure the routableness of traffic requests when they cannot successfully access the target service under the version under test. Routableness means that the traffic request will not be terminated upon arrival and business access can continue. Because this application prioritizes matching constraint rules based on traffic requests, access to the tested version of the target service will only be attempted when a constraint rule is not successfully matched, or when matching the corresponding constraint rule still fails to access the target service under the version under test in the target environment. This means that the constraint rules set by the application itself are completely isolated from ordinary constraint rules, and the application's constraint rules are prioritized for service access, without being interfered with by ordinary constraint rules, thereby improving the accuracy and efficiency of service testing.

[0090] In this embodiment, after obtaining a traffic request for a target service, the target environment matching the request tag can be determined based on the request tag carried by the traffic request. The target service includes at least a service version that has completed testing. Next, the deployment information of the target service can be obtained, which indicates whether a version of the target service exists to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier corresponding to its deployment. Finally, based on the deployment information, the target test version of the target service deployed to the target environment can be determined, and the target service under the target test version can be accessed in the target environment. In this application, different environments are isolated from each other, thus allowing for flexible adaptation to various complex and cumbersome testing scenarios for different versions of the target service based on these isolated, non-interfering environments. Furthermore, traffic requests can be uniformly managed based on request tags, and traffic requests can be flexibly routed to different environments, thereby improving the efficiency and flexibility of service testing.

[0091] based on Figure 2 The embodiments provide a related description of the information processing method of this application. Please refer to the following examples.Figure 4 , Figure 4 This is a flowchart illustrating the process of issuing constraint rules according to an embodiment of this application. This embodiment mainly provides a detailed description of the process of generating any constraint rule from the constraint rule set on the control plane of a service mesh, and the process of synchronizing the generated constraint rule to the data plane of the service mesh. This application can be applied to end-to-end canary deployment scenarios in a service mesh. Figure 4 As shown in the diagram, this process diagram may include steps S410 to S480. Wherein:

[0092] S410, Creating the Environment.

[0093] In this application, the Web console, the Object Storage Service (OSS) module (hereinafter referred to as the OSS control module), and the Consul module (service discovery module) can be modules integrated into the same computer device as the apiserver module (interface service module) and the pilot-discovery module (service discovery and configuration module) of the control plane. The Web console, the OSS control module, and the Consul module can also be external devices that establish communication connections with the apiserver module and the pilot-discovery module of the control plane.

[0094] In one possible implementation, an environment needs to be configured before using end-to-end canary deployment. The canary environment contains deployment groups within the application that require canary testing. Specifically, users can create environments through a web console. Creating an environment may include, but is not limited to, configuring basic environment-related information (such as the environment name) and selecting the appropriate deployment group.

[0095] For example, such as Figure 5a As shown, Figure 5a This is a schematic diagram illustrating an environment creation scenario provided in an embodiment of this application. The environment name created by the user can be "test001," and the created environment name must meet specific conditions, such as a maximum length of 60 characters and the inclusion of only lowercase letters, numbers, and separators. Of course, these specific conditions can be changed or set; for example, an administrator can change them to a maximum length of 30 characters and the inclusion of only uppercase letters, numbers, and separators. Furthermore, related notes can be added, indicating the purpose or function of the created environment, such as "test."

[0096] Furthermore, after completing environment creation, you can select deployment groups that require canary releases to join the environment, and simultaneously set the environment entry point (i.e., the entry service). For example...Figure 5b As shown, Figure 5b This is a schematic diagram of another environment creation scenario provided by the embodiments of this application. When selecting a deployment group, the user can filter the deployment group based on its namespace, namespace type, etc. For example, if a user needs to perform a canary release of version 1 of service 1, the user can first find the deployment group related to service 1, and then add the deployment group for version 1 of service 1 to that environment. Additionally, after adding the deployment group that needs to be canary released to the environment, an environment entry point can be set for that environment. Typically, the environment entry point is a gateway, used to verify traffic requests wanting to enter the environment, thereby determining whether the traffic request should enter the environment. Multiple environment entry points are supported in the same environment; when a request passes through each entry deployment group, it will determine whether the request should enter the environment. The method for configuring an environment entry point is to randomly select one or more deployment groups from the deployment groups added to the environment as the entry deployment group.

[0097] S420, Create constraint rules.

[0098] In one possible implementation, the data plane of the service mesh can obtain a set of constraint rules from the control plane of the service mesh, wherein the set of constraint rules includes at least one constraint rule, and each constraint rule is associated with an environment.

[0099] In this system, any constraint rule in the constraint rule set is synchronized from the control plane of the service mesh. This means that any constraint rule in the constraint rule set is synchronized from the data plane of the service mesh based on the user's configuration on the control plane. When a user configures any constraint rule through the service mesh, the service mesh can first display a rule configuration interface on a display device and generate corresponding constraint rules based on the configuration parameters entered in the rule configuration interface. These configuration parameters include, but are not limited to, at least one tag name, a tag value corresponding to each tag name, and the logical relationship between each tag name and its corresponding tag value. The logical relationship may include, but is not limited to, equality, inequality, inclusion, exclusion, regular expressions, etc., and this embodiment does not specifically limit this. Further, a rule publishing interface can be displayed, and the generated constraint rules are associated with the environment indicated by the environment identifier entered in the rule publishing interface. The environment identifier can be a unique representation of an environment and may include, but is not limited to, one or more of letters, symbols, and numbers. The display device can then send the generated constraint rules, and the association between the generated constraint rules and the associated environment, to the control plane. The generated constraint rules can be published to the corresponding environment, thus establishing the relationship between the constraint rules and the environment. This means that the corresponding environment can be determined based on the constraint rules.

[0100] In one possible implementation, users can also create canary release rules (i.e., constraint rules) through a web console. Specifically, the user passes the relevant parameters required for configuring the constraint rules to the web console, and the web console, upon receiving these parameters, can generate the corresponding constraint rules. Similarly, creating constraint rules may include, but is not limited to: configuring basic information related to the release rules (e.g., rule name), configuring request parameter rules, and configuring the release destination.

[0101] For example, regarding the basic setup process for creating constraint rules, please refer to [link / reference]. Figure 6a , Figure 6a This is a schematic diagram of a rule configuration interface provided in an embodiment of this application. The constraint rule created by the user can be named "lane-test-rule001," and the name of the created constraint rule must meet specific conditions, such as supporting Chinese and English characters, and not exceeding 60 characters. Of course, the specific conditions that the constraint rule name must meet can be changed or set. For example, the administrator can change the condition to: a maximum of 30 characters, and only uppercase letters, numbers, and separators, etc. Furthermore, related comments can be added. The comments can be used to indicate the purpose or function of the created constraint rule, such as the comment "test."

[0102] Next, after completing the basic settings for the constraint rules, you need to configure the "request parameter rules." For example, please refer to... Figure 6b , Figure 6b This is a schematic diagram of another rule configuration interface provided in an embodiment of this application. The configuration request parameter rules include, but are not limited to: tag name, logical relationship, tag value, and logical relationship, etc. Figure 6b The constraints shown can be: aaa equals 123, bbb does not equal 456, and multiple constraints are allowed. It should be noted that the tag names here are custom tags from the user's business logic. Custom tags refer to user-defined business parameters converted into tags used in the user's business logic. Furthermore, parameter names can be up to 32 bytes, and parameter values ​​can be up to 128 characters. Custom tags can come from two sources:

[0103] Method 1: Convert request parameters into tags through a microservice gateway: such as business parameters contained in the request path, query, and header, which are converted into tags through the tag plugin of the microservice gateway.

[0104] Method 2: Users configure tags in the code.

[0105] In addition, the configuration request parameter rules support five logical relationships: equal to, not equal to, contain, not contain, and regular expression. When selecting equal to or not equal to, the tag value can only be a single value; when selecting contain or not contain, multiple tag values ​​can be entered, separated by commas. The rule's effectiveness relationship refers to the logical relationship of the above conditions: OR (satisfying any rule) or AND (satisfying all rules).

[0106] Finally, after setting the basic constraint rules and configuring the request parameter rules, you can select the destination environment for publication. For example... Figure 6c As shown, Figure 6c This is a schematic diagram of a rule publishing interface provided in an embodiment of this application. Users can configure the corresponding publishing destination for the configured constraint rules, for example, setting the destination environment to "test001". This completes the mapping between the constraint rule named "lane-test-rule001" and the environment named "test001".

[0107] In one possible implementation, end-to-end canary deployment supports the simultaneous activation of multiple rules and allows configuring priorities for those rules. When the same request satisfies multiple rules simultaneously, the rule with the highest priority will be matched first.

[0108] In addition, the constraint rule matching method based on tags in this application can be extended to other rule matching methods in one possible implementation, such as host (file), url (Uniform Resource Locator), or cookie (plain text file).

[0109] S430, rules issued.

[0110] In one possible implementation, after creating the environment and constraint rules in the web console, the user can distribute the configured constraint rules to the OSS control module. The rule distribution can be achieved by the web console calling the OSS control module's global routing configuration API (Application Program Interface) to distribute end-to-end constraint rules.

[0111] S440, rules issued.

[0112] In one possible implementation, after receiving the end-to-end constraint rules from the web console, the OSS control module can reassemble the configuration according to the format of the Service Mesh global routing data model. This reassembly may include format conversion; for example, the OSS control module might convert the format of the end-to-end constraint rules into a format understandable by the Service Mesh global routing data model. Then, the OSS control module calls the RESTful API interface of the apiserver module in the Service Mesh control plane to issue the end-to-end constraint rules.

[0113] In one possible implementation, the constraint rules in this application can be issued by the Web console after the constraint rules are configured, and then sent to the apiserver module of the control plane via the Consul module. Alternatively, the constraint rules can be issued directly by the Web console after the constraint rules are configured; this embodiment of the application does not limit the implementation in this way.

[0114] S450, Save Rules.

[0115] In one possible implementation, after receiving the end-to-end constraint rules from the OSS control module, the Mesh apiserver module of the Service Mesh control plane saves the rules to the Consul module according to the format of the pilot-discovery global routing data model of the Mesh control plane. This means that the Mesh apiserver module converts the format of the end-to-end constraint rules into a format that the pilot-discovery global routing data model of the Mesh control plane can understand.

[0116] S460, adding, modifying, or deleting monitoring rules.

[0117] When the pilot-discovery module of the Service Mesh control plane starts, it establishes a long connection with the Consul module and listens for the addition, deletion or modification of end-to-end constraint rule configurations in the Consul module. When there are changes to end-to-end constraint rules (environment configuration or constraint rules), the Consul module will synchronize the changes to the pilot-discovery module of the Service Mesh control plane in real time.

[0118] S470, rule push.

[0119] Specifically, when there are changes to end-to-end constraint rules (environment configuration or constraint rules), the Consul module will synchronize the changes to the pilot-discovery module of the Service Mesh control plane in real time through rule push.

[0120] S480, grayscale extended configuration distributed.

[0121] In one possible implementation, after the pilot-discovery module of the Service Mesh control plane receives the end-to-end constraint rules pushed by the Consul module, it can assemble the end-to-end constraint rules into an xDS canary deployment configuration format and send it to the sidecar (proxy) of the Service Mesh data plane. After the sidecar synchronizes with the xDS canary deployment configuration of the end-to-end constraint rules, it can take effect in real time in the Service Mesh and realize canary deployment according to the corresponding release rules.

[0122] In this embodiment, the environment and swimlanes are configured in the control plane of the service mesh, linking the environment with constraint rules. The configured environment and corresponding constraint rules in the control plane are then synchronized to the data plane, specifically to the proxy (such as a sidecar) within the data plane. Subsequently, the data plane proxy can perform canary deployment testing on traffic requests based on the environment and corresponding constraint rules. This achieves end-to-end canary deployment without application awareness, thereby improving the flexibility of information processing in this application.

[0123] Based on the foregoing analysis, please refer to Figure 7 , Figure 7 This is a flowchart illustrating another testing method provided in an embodiment of this application. This method can be specifically executed by the aforementioned computer equipment, such as... Figure 7 As shown, the information processing method may include steps S701 to S712. Wherein:

[0124] S701: Get traffic request.

[0125] Specifically, during implementation, traffic requests for the target service are obtained, and these traffic requests carry request tags. Further, request tags can include at least one tag name, a tag value corresponding to each tag name, and the logical relationship between each tag name and its corresponding tag value. For example, a request tag could be: aaa=123. Here, "aaa" can be the tag name, 123 can be the tag value corresponding to the tag name, and "=" represents the logical relationship between the tag name and its corresponding tag value.

[0126] S702: Determine whether the current service is an entry service.

[0127] In one possible implementation, the method by which this application determines whether the current service is an entry service can be: determining the deployment information corresponding to the current service accessed by the traffic request, and determining whether the current service is an entry service based on the deployment information.

[0128] The deployment information may include, but is not limited to, namespace type, namespace, application identifier, and deployment group. The deployment information for the entry service also includes: namespace type, namespace, application identifier, and deployment group. Therefore, determining whether the current service is an entry service based on the deployment information means determining whether the current service belongs to the entry service based on one or more of the following: namespace type, namespace, application identifier, and deployment group.

[0129] S703: Matching constraint rules.

[0130] In one possible implementation, when the current service is determined to be the ingress service based on deployment information, constraint rules can be matched based on the request tags carried by the traffic requests. The method for matching constraint rules can be: matching the corresponding target constraint rule from a large number of constraint rules based on the request tags carried by the traffic requests. Matching with request tags includes: matching each tag name, its corresponding tag value, and the logical relationship between each tag name and its corresponding tag value.

[0131] Furthermore, during the constraint rule matching process, if there are multiple target constraint rules identified from the constraint rule set that match the request tag, then matching can be performed according to the priority of the constraint rules, with higher priority constraint rules being matched first. This can include obtaining the priorities corresponding to multiple target constraint rules separately (where the priority of each target constraint rule can be configured in the control plane), and then determining the target constraint rule corresponding to the highest priority among the multiple priorities as the target constraint rule.

[0132] S704: Determine the target environment.

[0133] In practice, after determining the target constraint rules, the environment associated with the target constraint rules can be used as the target environment that matches the request tag.

[0134] In this way, traffic requests can be matched to entry points based on the entry service. After a matching entry service is found, the target environment that matches the request tag is determined based on the environment associated with that entry service. After matching the entry service and the corresponding constraint rules, a unique environment identifier for the entire service is automatically generated and maintained, and this identifier is passed to downstream services. Different environments have their own unique environment identifiers, thus preventing traffic requests from different environments from becoming mixed up, and ensuring the efficiency and accuracy of the testing service.

[0135] S705: Add environment description information to traffic requests.

[0136] In one possible implementation, after determining the target environment of the traffic request, the traffic can be colored. Coloring the traffic means adding environment description information associated with the target environment matched by the request traffic to the request traffic, thus marking the traffic request. For example, the added environment description information may include, but is not limited to, the environment identifier of the target environment. Therefore, after adding environment description information to the traffic request, the traffic request is colored as belonging to the target environment. This ensures that the traffic request can only be routed within the target environment and also facilitates subsequent traffic tracing.

[0137] S706: Determine if the target service has a version to be tested.

[0138] In practice, after adding environment description information to the traffic request, it is necessary to further determine whether the target service has one or more versions to be tested, and the environment in which each version to be tested is deployed.

[0139] If the target service does not have any versions to be tested, then access the target service under the version of the service that has been tested.

[0140] S707: Determine if there is target deployment information that has the same environment identifier as the target environment.

[0141] In one possible implementation, if the target service has one or more versions to be tested, then it is further determined whether there is target deployment information with the same environment identifier as the target environment.

[0142] If none of the test versions of the target service have been deployed to the target environment, then access the target service under the tested service version.

[0143] S708: Determine the target test version of the target service to be deployed to the target environment.

[0144] In one possible implementation, the target test version of the target service deployed in the target environment is determined based on the environment in which each version of the target service to be tested is deployed. For example, assuming that target service B has two versions to be tested, V1 and V2, and version V1 is deployed in environment 1, and version V2 is deployed in environment 2, and the target environment is environment 1, then the target test version of the target service deployed in the target environment can be determined to be V1.

[0145] S709: Access the target service under the target test version.

[0146] In practice, the determined version to be tested is used as the target test version, and then the target service under the target test version is accessed in the target environment.

[0147] S710: Determine whether the traffic request carries environment description information.

[0148] In one possible implementation, when determining whether the current service is an ingress service in step S802, if it is determined that the current service is not an ingress service, environment description information is obtained from the traffic request. This environment description information is added after determining the environment that matches the request tag in the traffic request. Then, the traffic request is routed based on the environment description information obtained from the traffic request.

[0149] S711: The environment indicated by the obtained environment description information is taken as the target environment, and the test version of the target service deployed in the target environment is taken as the target test version.

[0150] In one possible implementation, if environment description information is obtained from the traffic request, the environment indicated by the obtained environment description information is taken as the target environment, and the test version of the target service deployed in the target environment is taken as the target test version, so as to access the target service under the target test version in the target environment.

[0151] S712: Access the target service under the service version that has completed testing.

[0152] In one possible implementation, if obtaining environment description information from the traffic request fails, it is determined that the target service does not have a version to be tested, or that any existing version to be tested has not been deployed to the target environment, and the target service under the service version that has been tested is accessed.

[0153] In this embodiment of the invention, based on the overall design of the control plane for end-to-end canary release, the concepts of environment and constraint rules are defined in the service mesh and decoupled from each other. The environment allows for unified management of deployment groups, enabling the addition or deletion of deployment groups and the one-click configuration of one or more entry services. Constraint rules allow for unified management of request traffic based on tags and the flexible switching of request traffic to different environments. Secondly, the service mesh data plane defines and transmits request traffic based on global routing, enabling end-to-end canary releases without application awareness. For users, the focus is only on defining request traffic and dividing environments, resulting in low understanding and operational costs. Furthermore, it implements policy control between multiple constraint rules and multiple environments, using a priority-based approach to match constraint rules. By isolating multiple non-interfering environments, it flexibly adapts to various complex canary release scenarios. Finally, the data plane independently implements global routing to control end-to-end canary releases, completely isolated from ordinary routing rules, and prioritizes matching global routes, avoiding interference from ordinary routing rules.

[0154] Please see Figure 8 , Figure 8 This is a schematic diagram of the structure of an information processing device provided in an embodiment of this application. The information processing device 800 can be applied to... Figure 2 , Figure 4 and Figure 7 The computer device in the illustrated method embodiment. The information processing device 800 may be a computer program (including program code) running on a lightweight node; for example, the information processing device 800 is an application software. This device can be used to perform the corresponding steps in the method provided in the embodiments of this application. The information processing device 800 may include:

[0155] Acquisition unit 801 is used to acquire traffic requests for a target service, the target service including at least a service version that has completed testing;

[0156] The determining unit 802 is used to determine the target environment that matches the request tag based on the request tag carried by the traffic request;

[0157] The acquisition unit 801 is also used to acquire the deployment information of the target service. The deployment information is used to indicate the following information: whether there is a version of the target service to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier after being deployed to the corresponding environment.

[0158] The processing unit 803 is used to determine the target test version of the target service to be deployed to the target environment based on the deployment information, and to access the target service under the target test version in the target environment.

[0159] In one possible implementation, the request tag includes at least one tag name, a tag value corresponding to each tag name, and a logical relationship between each tag name and its corresponding tag value; the determining unit 802, when determining the target environment matching the request tag based on the request tag carried by the traffic request, is specifically used for:

[0160] Obtain a set of constraint rules, which includes at least one constraint rule, and each constraint rule is associated with an environment;

[0161] The target constraint rule that matches the request tag is determined from the set of constraint rules, and the environment associated with the target constraint rule is taken as the target environment that matches the request tag.

[0162] Matching with request tags includes matching each tag name, its corresponding tag value, and the logical relationship between each tag name and its corresponding tag value in the request tags.

[0163] In one possible implementation, any constraint rule in the constraint rule set is obtained synchronously from the control plane of the service mesh; the information processing device 800 also includes a display unit 804 and a sending unit 805.

[0164] Display unit 804 is used to display the rule configuration interface and generate corresponding constraint rules based on the configuration parameters entered in the rule configuration interface;

[0165] The display unit 804 displays the rule publishing interface and associates the generated constraint rules with the environment indicated by the environment identifier entered in the rule publishing interface.

[0166] The sending unit 805 is used to send the generated constraint rules, as well as the relationship between the generated constraint rules and the associated environment, to the control plane.

[0167] In one possible implementation, when determining the target environment that matches the request tag carried by the traffic request, the determining unit 802 is specifically used for:

[0168] Determine the deployment information corresponding to the current service accessed by the traffic request, and determine whether the current service is the entry service based on the deployment information;

[0169] When the current service is determined to be an entry service, the environment associated with the entry service is identified, and the request tag is used to determine whether the request tag matches the environment associated with the entry service.

[0170] In one possible implementation, the determining unit 802 is further configured to perform the following operations:

[0171] If the deployment information determines that the current service is not the entry service, then the environment description information is obtained from the traffic request; the environment description information is added after the environment that matches the request tag in the traffic request is determined.

[0172] The traffic request is routed based on the environment description information obtained from the traffic request.

[0173] In one possible implementation, when determining the traffic request based on the environment description information obtained from the traffic request, the determining unit 802 is specifically used for:

[0174] If environment description information is obtained from the traffic request, the environment indicated by the obtained environment description information is taken as the target environment, and the test version of the target service deployed in the target environment is taken as the target test version, so as to access the target service under the target test version in the target environment;

[0175] If obtaining environment description information from traffic requests fails, it is determined that the target service does not have a version to be tested, or that any existing version to be tested has not been deployed to the target environment, and the target service under the service version that has been tested is accessed.

[0176] In one possible implementation, when processing unit 803 determines the target test version of the target service deployed to the target environment based on deployment information, it specifically performs the following:

[0177] Based on the deployment information, determine whether the target service has one or more versions to be tested, and the environment in which each version to be tested is deployed;

[0178] Identify the version to be tested that will be deployed to the target environment, and use the identified version as the target test version.

[0179] In one possible implementation, the target service includes a version to be tested that is deployed to an environment, and the deployment information of the target service under the corresponding version to be tested will carry the environment identifier of the corresponding environment; when the processing unit 803 determines the version to be tested that has been deployed to the target environment, it is specifically used for:

[0180] Based on the deployment information of the target service for each version to be tested, determine the target deployment information that is identical to the environment identifier corresponding to the target environment;

[0181] The version to be tested corresponding to the target deployment information is the version to be tested that has been determined to be deployed in the target environment.

[0182] In one possible implementation, if no version of the target service to be tested has been deployed to the target environment, the processing unit 803 accesses the tested version of the target service.

[0183] In this embodiment, after obtaining a traffic request for a target service, the target environment matching the request tag can be determined based on the request tag carried by the traffic request. The target service includes at least a service version that has completed testing. Next, the deployment information of the target service can be obtained, which indicates whether a version of the target service exists to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier corresponding to its deployment. Finally, based on the deployment information, the target test version of the target service deployed to the target environment can be determined, and the target service under the target test version can be accessed in the target environment. In this application, different environments are isolated from each other, thus allowing for flexible adaptation to various complex and cumbersome testing scenarios for different versions of the target service based on these isolated, non-interfering environments. Furthermore, traffic requests can be uniformly managed based on request tags, and traffic requests can be flexibly switched to different environments, thereby improving the efficiency of service testing.

[0184] Please see Figure 9 , Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of this application. The computer device 900 is used to perform... Figure 2 , Figure 4 and Figure 7The steps performed by the computer device in the corresponding method embodiment, the computer device 900 includes: one or more processors 910; one or more input devices 920; one or more output devices 930; and a memory 940. The processors 910, input devices 920, output devices 930, and memory 940 are connected via a bus 950. The memory 940 is used to store computer programs, the computer programs including program instructions, and the processor 910 is used to call the program instructions stored in the memory 940 to perform the following operations:

[0185] Obtain traffic requests for the target service, and determine the target environment that matches the request tags based on the request tags carried by the traffic requests. The target service must include at least the service version that has been tested.

[0186] Obtain the deployment information of the target service. The deployment information is used to indicate the following: whether there is a version of the target service to be tested, whether each version to be tested has been deployed to the corresponding environment, and the corresponding environment identifier after being deployed to the corresponding environment.

[0187] Based on the deployment information, determine the target test version of the target service to be deployed to the target environment, and access the target service under the target test version in the target environment.

[0188] In one possible implementation, the request label includes at least one label name, a label value corresponding to each label name, and a logical relationship between each label name and its corresponding label value; when the processor 910 determines the target environment matching the request label based on the request label carried by the traffic request, it calls the program instructions stored in the memory 940 to perform the following operations:

[0189] Obtain a set of constraint rules, which includes at least one constraint rule, and each constraint rule is associated with an environment;

[0190] The target constraint rule that matches the request tag is determined from the set of constraint rules, and the environment associated with the target constraint rule is taken as the target environment that matches the request tag.

[0191] Matching with request tags includes matching each tag name, its corresponding tag value, and the logical relationship between each tag name and its corresponding tag value in the request tags.

[0192] In one possible implementation, any constraint rule in the constraint rule set is obtained from the control plane of the service mesh; the processor 910 is also used to perform the following operations:

[0193] Display the rule configuration interface and generate corresponding constraint rules based on the configuration parameters entered in the rule configuration interface;

[0194] The rule publishing interface is displayed, and the generated constraint rules are associated with the environment indicated by the environment identifier entered in the rule publishing interface.

[0195] The generated constraint rules, along with the relationships between the generated constraint rules and the associated environment, are sent to the control plane.

[0196] In one possible implementation, when the processor 910 determines the target environment matching the request tag carried by the traffic request, it calls the program instructions stored in the memory 940 to perform the following operations:

[0197] Determine the deployment information corresponding to the current service accessed by the traffic request, and determine whether the current service is the entry service based on the deployment information;

[0198] When the current service is determined to be an entry service, the environment associated with the entry service is identified, and the request tag is used to determine whether the request tag matches the environment associated with the entry service.

[0199] In one possible implementation, processor 910 is also used to perform the following operations:

[0200] If the deployment information determines that the current service is not the entry service, then the environment description information is obtained from the traffic request; the environment description information is added after the environment that matches the request tag in the traffic request is determined.

[0201] The traffic request is routed based on the environment description information obtained from the traffic request.

[0202] In one possible implementation, when the processor 910 routes the traffic request based on the environment description information obtained from the traffic request, it calls the program instructions stored in the memory 940 to perform the following operations:

[0203] If environment description information is obtained from the traffic request, the environment indicated by the obtained environment description information is taken as the target environment, and the test version of the target service deployed in the target environment is taken as the target test version, so as to access the target service under the target test version in the target environment;

[0204] If obtaining environment description information from traffic requests fails, it is determined that the target service does not have a version to be tested, or that any existing version to be tested has not been deployed to the target environment, and the target service under the service version that has been tested is accessed.

[0205] In one possible implementation, when the processor 910 determines the target test version of the target service to be deployed to the target environment based on deployment information, it calls the program instructions stored in the memory 940 to perform the following operations:

[0206] Based on the deployment information, determine whether the target service has one or more versions to be tested, and the environment in which each version to be tested is deployed;

[0207] Identify the version to be tested that will be deployed to the target environment, and use the identified version as the target test version.

[0208] In one possible implementation, a test version of the target service is deployed to an environment, and the deployment information of the target service under the corresponding test version will carry the environment identifier of the corresponding environment; when the processor 910 determines that the test version has been deployed to the target environment, it calls the program instructions stored in the memory 940 to perform the following operations:

[0209] Based on the deployment information of the target service for each version to be tested, determine the target deployment information that is identical to the environment identifier corresponding to the target environment;

[0210] The version to be tested corresponding to the target deployment information is the version to be tested that has been determined to be deployed in the target environment.

[0211] In one possible implementation, if no version of the target service to be tested has been deployed to the target environment, the processor 910 accesses the tested version of the target service.

[0212] It should be understood that the computer device described in the embodiments of this application can perform the foregoing... Figure 2 to Figure 7 The description of the information processing method in the corresponding embodiments can also be performed as described above. Figure 8 The description of the information processing device 800 in the corresponding embodiments will not be repeated here. Furthermore, the beneficial effects of using the same method will also not be repeated here.

[0213] Furthermore, it should be noted that this application embodiment also provides a computer storage medium, which stores a computer program executed by the aforementioned information processing device 800. This computer program includes program instructions, and when the processor executes these program instructions, it can execute the aforementioned... Figure 2 , Figure 4 and Figure 7 The methods described in the corresponding embodiments are therefore not repeated here. For technical details not disclosed in the computer storage medium embodiments involved in this application, please refer to the description of the method embodiments of this application. As an example, program instructions can be deployed on a computer device, or executed on multiple computer devices located in one location, or executed on multiple computer devices distributed in multiple locations and interconnected through a communication network. Multiple computer devices distributed in multiple locations and interconnected through a communication network can constitute a blockchain system.

[0214] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the aforementioned... Figure 2 , Figure 4 and Figure 7 The methods described in the corresponding embodiments are therefore not repeated here.

[0215] Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0216] The above-disclosed embodiments are merely preferred embodiments of this application and should not be construed as limiting the scope of this application. Therefore, any equivalent variations made in accordance with the claims of this application shall still fall within the scope of this application.

Claims

1. An information processing method, characterized in that, The method includes: The process involves acquiring traffic requests for a target service and determining a target environment that matches the request tags carried by the traffic requests. The target service includes at least a service version that has completed testing. The request tags include at least one tag name, a tag value corresponding to each tag name, and a logical relationship between each tag name and its corresponding tag value. Determining the target environment that matches the request tags includes: acquiring a set of constraint rules, which includes at least one constraint rule, and each constraint rule is associated with an environment; determining a target constraint rule that matches the request tag from the set of constraint rules, and using the environment associated with the target constraint rule as the target environment that matches the request tag. Matching the request tag includes matching each tag name, its corresponding tag value, and the logical relationship between each tag name and its corresponding tag value in the request tag. Obtain the deployment information of the target service, which is used to indicate the following information: whether there is a version of the target service to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier corresponding to the deployment to the corresponding environment; Based on the deployment information, determine the target test version of the target service to be deployed to the target environment, and access the target service under the target test version in the target environment.

2. The method as described in claim 1, characterized in that, Any constraint rule in the constraint rule set is obtained from the control plane of the service mesh through synchronization; the method further includes: Display the rule configuration interface and generate corresponding constraint rules based on the configuration parameters entered in the rule configuration interface; The rule publishing interface is displayed, and the generated constraint rules are associated with the environment indicated by the environment identifier entered in the rule publishing interface. The generated constraint rules, and the association between the generated constraint rules and the associated environment, are sent to the control plane.

3. The method as described in claim 1, characterized in that, The step of determining the target environment matching the request tag based on the request tag carried by the traffic request includes: Determine the deployment information corresponding to the current service accessed by the traffic request, and determine whether the current service is an entry service based on the deployment information; When the current service is determined to be the entry service, the environment associated with the entry service is determined, and the request tag is determined to match the environment associated with the entry service.

4. The method as described in claim 3, characterized in that, The method further includes: If, based on the deployment information, it is determined that the current service is not the entry service, then environment description information is obtained from the traffic request; the environment description information is added after determining the environment that matches the request tag in the traffic request. The traffic request is routed based on the environment description information obtained from the traffic request.

5. The method as described in claim 4, characterized in that, The step of routing the traffic request based on the environment description information obtained from the traffic request includes: If environment description information is obtained from the traffic request, the environment indicated by the obtained environment description information is taken as the target environment, and the test version of the target service deployed in the target environment is taken as the target test version, so as to access the target service under the target test version in the target environment; If obtaining environment description information from the traffic request fails, it is determined that there is no version of the target service to be tested, or that any existing version to be tested has not been deployed to the target environment, and the target service under the service version that has completed testing is accessed.

6. The method as described in claim 1, characterized in that, The step of determining the target test version of the target service deployed to the target environment based on the deployment information includes: Based on the deployment information, determine whether the target service has one or more versions to be tested, and the environment in which each version to be tested is deployed; The version to be tested, which will be deployed to the target environment, is determined and used as the target test version.

7. The method as described in claim 6, characterized in that, The target service includes a version to be tested that is deployed in an environment, and the deployment information of the target service under the corresponding version to be tested will carry the environment identifier of the corresponding environment. The process of determining the version to be tested and deployed to the target environment includes: Based on the deployment information of the target service for each version to be tested, the target deployment information that is the same as the environment identifier corresponding to the target environment is determined; The version to be tested corresponding to the target deployment information is the determined version to be tested that is deployed in the target environment.

8. The method as described in claim 6, characterized in that, The method further includes: If none of the test versions of the target service have been deployed to the target environment, then the tested versions of the target service are accessed.

9. An information processing device, characterized in that, The device includes: An acquisition unit is used to acquire traffic requests for a target service, wherein the target service includes at least a service version that has completed testing. A determining unit is configured to determine a target environment matching the request tag carried by the traffic request; the request tag includes at least one tag name, a tag value corresponding to each tag name, and a logical relationship between each tag name and its corresponding tag value; determining the target environment matching the request tag based on the request tag carried by the traffic request includes: obtaining a constraint rule set, the constraint rule set including at least one constraint rule, and each constraint rule being associated with an environment; determining a target constraint rule matching the request tag from the constraint rule set, and using the environment associated with the target constraint rule as the target environment matching the request tag; wherein matching the request tag includes: matching each tag name, its corresponding tag value, and the logical relationship between each tag name and its corresponding tag value in the request tag; The acquisition unit is further configured to acquire the deployment information of the target service, wherein the deployment information is used to indicate the following information: whether the target service has a version to be tested, whether each version to be tested has been deployed to the corresponding environment, and the environment identifier corresponding to the deployment to the corresponding environment; The processing unit is configured to determine the target test version of the target service to be deployed to the target environment based on the deployment information, and access the target service under the target test version in the target environment.

10. A computer device, characterized in that, include: A processor, adapted to execute computer programs; A computer-readable storage medium storing a computer program, which, when executed by the processor, implements the information processing method as described in any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program adapted to be loaded by a processor and executed as described in any one of claims 1 to 8.

12. A computer program product comprising computer instructions stored in a computer-readable storage medium; a processor of a computer device reading the computer instructions from the computer-readable storage medium, the processor executing the computer instructions to cause the computer device to perform the information processing method as described in any one of claims 1 to 8.

Images