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

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

Info

Publication number
WO2022267175A1
WO2022267175A1 PCT/CN2021/109359 CN2021109359W WO2022267175A1 WO 2022267175 A1 WO2022267175 A1 WO 2022267175A1 CN 2021109359 W CN2021109359 W CN 2021109359W WO 2022267175 A1 WO2022267175 A1 WO 2022267175A1
Authority
WO
WIPO (PCT)
Prior art keywords
environment
target
service
version
tested
Prior art date
Application number
PCT/CN2021/109359
Other languages
English (en)
French (fr)
Inventor
张培培
Original Assignee
腾讯云计算（北京）有限责任公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 腾讯云计算（北京）有限责任公司 filed Critical 腾讯云计算（北京）有限责任公司
Publication of WO2022267175A1 publication Critical patent/WO2022267175A1/zh
Priority to US18/127,478 priority Critical patent/US20230236954A1/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3664—Environments for testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/71—Version control; Configuration management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3684—Test management for test design, e.g. generating new test cases

Definitions

  • the present application relates to the technical field of the Internet, and in particular to an information processing method, device, computer equipment and storage medium.
  • Grayscale publishing refers to a publishing method that can smoothly transition between black and white.
  • grayscale testing refers to the testing of one or more of the products that have been launched.
  • A/B testing A/B testing
  • Grayscale testing refers to the testing of one or more of the products that have been launched.
  • some users can continue to use product feature A (that is, the service before the update), and some users start to use product feature B (that is, the updated service).
  • the current grayscale test it is necessary to configure rules for each service involved in the full link related to the product. If the services involved in the full link include service 1, service 2, and service 3, then the developer needs to Before starting the grayscale test, configure the rules for Service 1, Service 2, and Service 3 respectively.
  • the embodiments of the present application provide an information processing method, device, computer equipment, and storage medium, which can improve the flexibility of service testing. Described technical scheme is as follows:
  • an embodiment of the present application provides an information processing method, the method including:
  • the deployment information of the target service is used to indicate the following information: whether there is a version to be tested in the target service, whether each version to be tested has been deployed to the corresponding environment, and the corresponding environment after being deployed to the corresponding environment logo;
  • the target service determines the target test version deployed to the target environment in the version to be tested;
  • an information processing device which includes:
  • An acquisition unit configured to acquire a traffic request for a target service, where the traffic request includes a request tag;
  • the obtaining unit is also used to obtain the deployment information of the target service, and the target service deployment information is used to indicate the following information: whether there is a version to be tested in the target service, whether each version to be tested has been deployed to the corresponding environment, and whether the version to be tested has been deployed to the corresponding The corresponding environment logo after the environment;
  • an embodiment of the present application provides a computer device, the computer device includes a memory and a processor, the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the above information processing method.
  • an embodiment of the present application provides a computer program product or computer program, where the computer program product or computer program includes computer instructions, and the computer instructions are stored in a computer-readable storage medium.
  • the processor of the computer device reads the computer instruction from the computer-readable storage medium, and the processor executes the computer instruction, so that the computer device executes the above-mentioned information processing method.
  • the target environment that matches the request tag carried in the traffic request; and, based on the deployment information of the target service, determine the target that is deployed in the target environment in the version to be tested that exists in the target service beta version to access the target service under the target beta version in the target environment.
  • the mutual isolation of different environments realizes the isolation and mutual non-interference between different versions to be tested, and can flexibly adapt to various complex and
  • the cumbersome gray-scale release scenario for different versions of the service to be tested effectively avoids the configuration of the service during the gray-scale test and improves the efficiency of the gray-scale test.
  • the embodiment of the present application can also uniformly manage the traffic requests based on the request tags, and can flexibly route the traffic requests to different environments, so as to further improve the efficiency of grayscale testing.
  • FIG. 1 is a schematic diagram of the architecture of a data processing system provided by an embodiment of the present application
  • FIG. 2 is a schematic flowchart of an information processing method provided in an embodiment of the present application.
  • FIG. 3 is a schematic diagram of a deployment environment scenario provided by an embodiment of the present application.
  • Fig. 4 is a schematic flow chart of issuing constraint rules provided by the embodiment of the present application.
  • FIG. 5 is a schematic diagram of an environment creation scenario provided by an embodiment of the present application.
  • FIG. 7 is a schematic flowchart of another information processing method provided by the embodiment of the present application.
  • FIG. 8 is a schematic structural diagram of an information processing device provided in an embodiment of the present application.
  • the embodiment of the present application proposes an information processing solution, which can be applied to full-link gray scale publishing in the service grid.
  • the full link refers to the link composed of all services that need to be accessed by a flow request.
  • the link formed by all the services that need to be accessed by a flow request is: service 1->service 2->service 3
  • the A link is a full link, which can realize the global routing of the service grid.
  • this application uses a route between any two services as an example for illustration. It can be understood that for any one or more services in the service grid, you can refer to the execution flow of the information processing method of this application , enabling global routing in the service mesh.
  • the service grid includes a control plane and a data plane, and the technical solution provided by this embodiment of the application mainly has the following characteristics:
  • control plane introduces the configuration methods of constraint rules, environment and grayscale release, and the data plane synchronizes the constraint rules configured on the control plane.
  • 1Configuration on the control plane mainly includes the following steps: First, create an environment on the control plane, add the deployment group of a specific version that needs to be grayscale released to the same environment, and specify one or more deployment groups in the environment as the environment secondly, create a constraint rule on the control plane, set request parameters to match the grayscale traffic of the environment entrance, and publish the constraint rule to the destination environment to realize the association between the entry rule and the environment.
  • the data plane synchronizes the constraint rules set by the control plane in real time, and realizes the specific logic of full-link gray scale release through the service grid expansion mechanism.
  • Service Mesh Translated as a service grid, it is an infrastructure layer that handles communication between services. It is responsible for the reliable delivery of requests for the complex service topology that forms modern cloud-native applications.
  • Service Mesh is implemented as an array of lightweight network proxies (called sidecars) that are deployed alongside application code without the application being aware of the presence of the proxies.
  • sidecar It is a separate process independent from the main application process, loosely coupled with the main application process, and can be considered as a proxy. Sidecar can shield the differences of different programming languages, and uniformly realize the observability, routing, full link gray scale, authentication, current limiting, fuse and other functions of microservices.
  • An environment is a collection of deployment groups and is the destination of grayscale publishing (global routing) rules. Deployment groups in an environment belong to different applications. It can be considered that the user divides the gray scale environment by dividing the environment.
  • Grayscale release It is a common online method in the software online process. It means that during the release process, traffic with certain characteristics or proportions is allocated to the version that needs to be verified, so as to observe the online operation status of the new verified version. .
  • Grayscale publishing rules The user configures the conditions that the request needs to meet on the grayscale publishing rules. When the request meets certain conditions, the traffic can be routed to a certain environment through grayscale publishing rules.
  • FIG. 1 is a schematic structural diagram of an information processing system provided by an embodiment of the present application.
  • the architecture diagram of the information processing system may include: a control plane 110 and a data plane 120 .
  • control plane 110 and the data plane 120 are respectively implemented as a computer device; in another example, the control plane 110 and the data plane 120 are integrated into the same computer device.
  • the computer equipment includes: terminal equipment such as vehicle-mounted equipment, smart phones, tablet computers, smart wearable devices, servers, and the like.
  • the control plane 110 and the data plane 120 communicate directly or indirectly through wired communication or wireless communication, which is not limited in this application.
  • the information processing system may be a Service Mesh (service grid), or a microservice framework system.
  • the microservice framework system includes but is 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) ), grpc (a microservice system with strict interface constraints), etc.
  • each agent included in the control plane 110 is used for service-related configuration (ie service configuration), for example, configuration environment, and configuration Constraint rules associated with the environment, etc.; each agent included in the data plane 120 is used for service discovery, and the service discovery is used to indicate that according to the environment synchronized from the control plane 110 and the constraint rules associated with the environment, the service test or gray degree test etc.
  • service A and service B in the data plane 120 may be different services in the same application program, or may be different services in different application programs.
  • the information processing method provided by the embodiment of the present application is combined with blockchain technology, for example, the constraint rule set, service deployment information, etc. can be uploaded to the blockchain for storage, so as to ensure that The data is not easily tampered with.
  • Blockchain is a new application model of computer technologies such as distributed data storage, point-to-point transmission, consensus mechanism, and encryption algorithm.
  • the devices involved in the information processing system provided by the embodiment of the present application are deployed in the blockchain network and serve as node devices in the blockchain network.
  • both the control plane 110 and the data plane 120 are used as zone
  • the node devices in the block chain network together form the block chain network.
  • the relevant process of information processing for traffic requests in this application can be executed on the blockchain, which not only ensures the fairness and justice of the information processing process, but also makes the information processing process traceable and improves the security of the information processing process sex.
  • the constraint rule set and service involved in this application All deployment information is implemented by cloud storage technology in cloud technology. That is, the blockchain is stored on the “cloud” through cloud storage technology, and when data such as constraint rule sets and service deployment information need to be stored in the blockchain, these data are uploaded to the "cloud” through cloud storage technology. In the blockchain on the "cloud”, and in the case of needing to read these data, you can also read data from the blockchain on the "cloud” at any time. Through cloud storage technology, the storage requirements for terminal equipment are reduced, and the application scope of blockchain is expanded.
  • cloud storage is a new concept extended and developed on the concept of cloud computing; distributed cloud storage system (hereinafter referred to as storage system) refers to the storage system through cluster application, grid technology and distributed storage file system, etc. It is a storage system that integrates a large number of different types of storage devices (storage devices are also called storage nodes) in the network to work together through application software or application interfaces, and jointly provide data storage and service access functions.
  • the information processing method provided by the embodiment of the present application is executed by the agent in the data plane 120.
  • the agent in the data plane 120 executes the The information processing method provided in the embodiment of this application.
  • the agent in the data plane 120 obtains the traffic request for the target service (such as service B), and based on the request tag carried in the traffic request, determines the target environment matching the request tag, and the target service includes the service version that has been tested ;
  • the agent in the data plane 120 obtains the deployment information of the target service, and the deployment information of the target service is used to indicate at least one of the following information: whether there is a version to be tested in the target service, whether the version to be tested is deployed to the corresponding environment, and the corresponding environment.
  • Environment identification based on the deployment information, the agent in the data plane 120 determines the target test version that is deployed to the target environment among the versions to be tested that exist in the target service, and accesses the target service under the target test version in the target environment.
  • FIG. 2 is a schematic flowchart of an information processing method provided in an embodiment of the present application.
  • the information processing method can be applied to a computer device.
  • the computer device is a device corresponding to the data plane 120 in the information processing system shown in FIG. 1 , such as a proxy device corresponding to the data plane 120 .
  • the information processing method provided by the embodiment of the present application includes steps S210-S250.
  • the information processing method provided in the embodiment of the present application may be applicable to gray-scale publishing scenarios. That is to say, during the application or program release process, the information processing method provided by the embodiment of the present application can be used to distribute traffic with certain characteristics or proportions to the new service version that needs to be tested, so as to observe the performance of the new service version. Live running status to enable reliable release of new service versions of the application.
  • a traffic request is taken as an example for illustration.
  • this application is also applicable to any traffic request in a batch or a large number of traffic requests, wherein each traffic request in a batch of traffic requests is parallel
  • the technical solutions provided by the embodiments of the present application are executed, or the technical solutions provided by the embodiments of the present application are executed successively (serially) according to the order in which traffic requests are received, which is not limited in this application.
  • the data plane obtains traffic requests for target services.
  • the target service refers to the downstream service to be accessed by the traffic request initiated by the user
  • the downstream service refers to the service accessed after the current service
  • the current service refers to the service currently accessed by the traffic request.
  • the target service is service B.
  • the target service has a service version that has been tested, so that it can be ensured that when the traffic request cannot successfully access the target service under the version to be tested (service version to be tested), the traffic request can access the tested version.
  • the target service under the service version is used to ensure the routeability of the traffic request when the traffic request cannot successfully access the target service under the service version that needs to be tested.
  • routability means that traffic requests will not be terminated when they arrive, and business access can continue.
  • the traffic request carries a request tag.
  • the request tag includes, but is not limited to: at least one tag name, a tag value corresponding to each tag name, and a logical relationship between the tag name and its corresponding tag value.
  • the logical relationship between a tag name and its corresponding tag value includes, but is not limited to: equal to, not equal to, contains, does not contain, regular expressions, and the like. Exemplarily, if the logical relationship between a tag name and its corresponding tag value is inclusion, then the tag name includes its corresponding tag value.
  • An environment may be a collection of target services that contain one or more versions under test.
  • different environments are isolated from each other, that is, environment A and environment B cannot interact or communicate.
  • the environment corresponds to an environment identifier to uniquely identify the environment.
  • the data plane can determine the target environment that matches the request label.
  • the request tag includes but is not limited to: at least one tag name, tag value corresponding to each tag name, and the logical relationship between the tag name and its corresponding tag value; based on this, optionally, the request tag The matching includes: matching the at least one tag name included in the request tag, the tag value corresponding to the at least one tag name, and the logical relationship between each tag name and its corresponding tag value.
  • step S220 includes steps S222-S226.
  • a set of constraint rules includes at least one constraint rule, where one constraint rule is associated with one environment.
  • one constraint rule is associated with one environment.
  • one environment is associated with one constraint rule; or, there is a multi-pair relationship between constraint rules and environments
  • An associative relationship that is, a constraint rule is associated with an environment, and an environment is associated with one or more constraint rules.
  • the embodiment of the present application implements policy control between multiple constraint rules and multiple environments through the association between constraint rules and environments; moreover, multiple different environments that do not interfere with each other are isolated through constraint rules, which can be flexibly adapted to Various complex grayscale publishing scenarios.
  • the constraint rule set includes at least one constraint rule. Based on the request label of the traffic request, the data plane determines a target constraint rule matching the request label from at least one constraint rule included in the constraint rule set.
  • the data plane can obtain the priorities corresponding to the multiple constraint rules (wherein each constraint rule corresponds to The priority of can be configured by the control plane and synchronized to the data plane), and then, among the priorities corresponding to multiple constraint rules, the constraint rule corresponding to the highest priority is determined as the target constraint rule. That is to say, in the case that multiple constraint rules are matched based on the request label, the target constraint rule is determined according to the priority of the constraint rule.
  • a constraint rule is associated with an environment, so when the target constraint rule matching the request label is determined, the environment associated with the target constraint rule can be used as the target environment matching the request label.
  • environment description information may be added to the traffic request, where the environment description information is used to indicate the target environment.
  • the environment description information includes an environment identifier corresponding to the target environment.
  • steps S221-S223 are further included.
  • Step S221 determine the deployment information of the current service.
  • the current service is the service the traffic request is currently accessing.
  • the deployment information of the current service includes but is not limited to: namespace type, namespace, application identifier, deployment group, and so on.
  • the ingress service is obtained synchronously by the data plane from the control plane of the service grid.
  • the deployment information of the entry service includes but is not limited to: namespace type, namespace, application identifier, deployment group, and so on.
  • the above-mentioned deployment information based on the current service determines whether the current service is an entry service, including: based on one of namespace type, namespace, application identifier, and deployment group Or various information to determine whether the current service is an entry service.
  • step S224 is executed, that is, the step of determining a target constraint rule matching the request tag among at least one constraint rule is continued.
  • the data plane acquires environment description information from the traffic request, which is added after determining the environment that matches the request tag carried in the traffic request ; Then, the data plane routes the traffic request based on the obtained result of the environment description information.
  • the acquisition result of the environment description information includes: the environment description information is acquired or the environment description information is not acquired.
  • routing the traffic request includes: taking the environment indicated by the environment description information as the target environment; if the environment description information is not obtained, it means that the target service does not exist
  • the test version, or any version to be tested that exists in the target service is not deployed to the target environment (but is deployed to an environment other than the target environment), so that routing traffic requests includes: access to the service that has completed the test version of the target service.
  • the deployment information of the target service is used to indicate the following information: whether there is a version to be tested in the target service, whether each version to be tested has been deployed to the corresponding environment, and the corresponding environmental label.
  • the control plane may deploy some or all of the versions to be tested in the target service to the corresponding environment.
  • only one version to be tested of the target service can be deployed in an environment.
  • FIG. 3 is a schematic diagram of a deployment environment scenario provided by an embodiment of the present application.
  • the target service is service B
  • there are three versions of service B to be tested namely B1, B2, and B3, and B1, B2, and B3 are deployed in environment 1, environment 2, and environment 3 respectively.
  • the tested service version of service B can be B0, and B0 is deployed on the main link.
  • Environment 1, Environment 2, and Environment 3 are isolated from each other, and the main link is not deployed in any environment.
  • the deployment information of the target service is used to indicate: the target service does not have a version to be tested; the target service has a version to be tested and the version to be tested has not been deployed to the corresponding environment
  • the deployment information of the target service is used to indicate: the target service has a version to be tested, and the version to be tested has not been deployed to the corresponding environment; in the case of the target service, the version to be tested has been deployed to the corresponding environment
  • the deployment information of the target service is used to indicate: the target service has a version to be tested, and the version to be tested is deployed to a corresponding environment, and the environment ID corresponding to the environment to which the version to be tested is deployed.
  • the target service According to the deployment information of the target service, if the target service has a version to be tested, determine a target test version deployed to the target environment in the version to be tested.
  • the deployment information of the target service is used to indicate: the target service has a version to be tested, whether the version to be tested is deployed to the corresponding environment, and the environment identifier corresponding to each environment. Therefore, based on the target The deployment information of the service can obtain whether each version to be tested is deployed to the corresponding environment, and if the version to be tested is deployed to the corresponding environment, the environment to which the version to be tested is deployed can be further determined.
  • the data plane determines the target environment matching the traffic request; and in the above step S230, obtains the deployment information of the target service. Based on this, if the target service has a version to be tested, the data plane can determine the version to be tested that is deployed to the target environment (ie, the target test version) based on the deployment information of the target service.
  • the target service is service B
  • service B has two versions to be tested: version V1 to be tested and version V2 to be tested.
  • version V1 to be tested is deployed to environment 1
  • version V2 is deployed to environment 2.
  • the deployment information of service B under the version V1 to be tested includes test001
  • the deployment information of service B under the version V2 to be tested includes test002.
  • the environment identifier corresponding to the target environment is test001
  • the target deployment information matching the environment identifier corresponding to the target environment is the deployment information of service B under the version V1 to be tested
  • the version to be tested corresponding to the target deployment information (target version to be tested) is the version to be tested V1.
  • Step S250 in the target environment, access the target service under the target test version.
  • the data plane After the data plane obtains the target test version based on step S240, it can access the target service under the target test version in the target environment, so as to achieve the purpose of gray scale release.
  • the version to be tested existing in the target service is not necessarily deployed in the target environment, or in other words, the version to be tested existing in the target service is not necessarily deployed in the target environment.
  • the version to be tested existing in the target service is deployed to an environment other than the target environment; or, the version to be tested existing in the target service is not deployed to any environment.
  • the data plane cannot access the target service in the target environment.
  • this embodiment of the present application provides a method for accessing the target service, as shown below.
  • any version to be tested exists in the target service, it is deployed to an environment other than the target environment (neither of which is deployed to the target environment), access the target under the service version that has been tested Serve.
  • the target service is service B
  • service B has two versions to be tested: version V1 to be tested and version V2 to be tested, and a service version V0 that has been tested.
  • the target environment is environment 1
  • the two versions to be tested in service B are deployed in environments other than environment 1. If they are deployed in environment 2 and environment 3 respectively, they cannot be in the target environment (environment 1).
  • Access service B under the version V1 and version V2 to be tested but access service B under the service version V0 that has been tested.
  • the target service under the version to be tested is accessed.
  • the target service may not have any version to be tested, but only a service version that has been tested.
  • the data plane accesses the target service under the service version that has been tested.
  • the embodiment of the present application by deploying the version to be tested that exists in the target service to different environments, the isolation and non-interference between different versions to be tested is realized by the mutual isolation between different environments, and it can flexibly adapt to various
  • the complex and cumbersome grayscale release scenario for different versions of the service to be tested effectively avoids the configuration of the service during the grayscale test and improves the efficiency of the grayscale test.
  • the embodiment of the present application can also uniformly manage the traffic requests based on the request tags, and can flexibly route the traffic requests to different environments, so as to further improve the efficiency and flexibility of grayscale testing.
  • FIG. 4 is a schematic flow chart of issuing constraint rules provided by an embodiment of the present application.
  • the embodiment of the present application mainly describes the process of generating any constraint rule in the constraint rule set on the control plane of the service grid, and the process of synchronizing the generated constraint rules to the data plane of the service grid.
  • the embodiments of the present application can be applied to the full-link grayscale release scenario in the service grid.
  • the flowchart may include the following steps S410 - S480 .
  • the environment contains the deployment groups in the application that need to be grayscale tested. Users can create environments through the Web (web page) console. In addition, creating an environment includes but is not limited to: configuring basic information related to the environment (such as environment name, environment identifier, etc.) and selecting a corresponding deployment group.
  • FIG. 5 is a schematic diagram of an environment creation scenario provided by an embodiment of the present application.
  • the environment name created by the user can be "test001", and the created environment name needs to meet certain conditions, for example: the longest character is 60, and it can only include lowercase letters and numbers and separators.
  • the specific conditions that the environment name needs to meet can also be changed or set.
  • the administrator can change the specific conditions to: the maximum number of characters is 30, and only uppercase letters, numbers, and separators can be included.
  • related remarks can also be made, and the content of the remarks can be used to indicate the purpose or function of the created environment, etc., for example, the content of the remarks can be "test”.
  • the environment entry is a gateway (gateway), which is used to verify the traffic request that wants to enter the environment, so as to judge whether the traffic request should enter the environment.
  • the method for configuring the environment entry includes: randomly selecting one or more deployment groups from among the deployment groups added to the environment as entry deployment groups.
  • Step S420 creating constraint rules.
  • the data plane of the service mesh can synchronize constraint rule sets from the control plane of the service mesh.
  • the constraint rule set includes at least one constraint rule, and one constraint rule is associated with one environment. Based on this, after any constraint rule in the constraint rule set is configured by the user on the control plane of the service grid, the data plane of the service grid is synchronized based on the user's configuration on the control plane.
  • the service grid can first display the rule configuration interface through the display device, and generate corresponding constraint rules based on the configuration parameters entered in the rule configuration interface; where the configuration parameters include but are not limited to : At least one tag name, the tag value corresponding to each tag name, and the logical relationship between the tag name and its corresponding tag value.
  • the logical relationship between a tag name and its corresponding tag value includes, but is not limited to: equal to, not equal to, contains, does not contain, regular expressions, etc., which are not specifically limited in this embodiment of the present application.
  • full-link gray release supports multiple constraint rules to take effect at the same time, and supports configuring priorities for constraint rules. When the same request satisfies multiple constraint rules at the same time, the high priority constraint rule will be matched first.
  • the embodiment of the present application introduces the constraint rule matching method based on the label form.
  • the constraint rule matching method can also be extended to be based on other forms, such as host (file) format, URL (Uniform Resource Locator, uniform resource locator) form or cookie (plain text file) form, etc.
  • the user creates a gray release rule (ie, a constraint rule) through the web console, including: the user passes in the relevant parameters required for configuring the constraint rule to the web console, and the web console generates corresponding binding rules.
  • creating a constraint rule includes, but is not limited to: configuring basic information related to the constraint rule (such as a rule name), configuring request parameter rules, and publishing destination configuration.
  • the configuration request parameter rules include, but are not limited to: configuration tag names, tag values, logical relationships, and rule validation conditions.
  • the tag name can be up to 32 bytes
  • the tag value can be up to 128 characters.
  • the logical relationship configured when configuring the request parameter rule includes, but is not limited to: equal to, not equal to, contains, does not contain, regular expressions, and the like. Among them, when the logical relationship is configured as equal to and not equal to, the tag value can only be filled in as a single value; when the logical relationship is configured as include and not included, the tag value can fill in multiple values, separated by commas.
  • the effective condition of the rule refers to: the above-mentioned several logical relationships, or (satisfy any logical relationship), and (satisfy all logical relationships).
  • Method 1 Convert the requested parameters into labels through the microservice gateway. For example, through the tag (tag) plug-in of the microservice gateway, the business parameters contained in the requested path (channel), query (question), and header (request header) are converted into tags.
  • Method 2 The user configures the label in the code.
  • Step S430 issuing rules.
  • the configured constraint rules can be delivered to the OSS (Object Storage Service, object storage service) control module.
  • the method of issuing constraint rules can be as follows: the Web console calls the global routing configuration API (Application Program Interface, application program interface) of the OSS control module to issue full-link constraint rules.
  • the OSS control module After the OSS control module receives the full link constraint rules issued by the web console, it can reassemble the configuration according to the format of the Service Mesh global routing data model.
  • the reassembly configuration can include format conversion.
  • the OSS control module converts the format of the full link constraint rules into a format that the Service Mesh global routing data model can understand.
  • the OSS control module calls the restful API interface of the apiserver (interface service) module of the Service Mesh control plane, and issues the full link constraint rules.
  • Step S450 saving the rules.
  • the Mesh apiserver module After the apiserver module of the Service Mesh control plane (referred to as the Mesh apiserver module) obtains the full-link constraint rules issued by the OSS control module.
  • the Mesh apiserver module saves the rules to the Consul module according to the format of the global routing data model of the pilot-discovery (service discovery and configuration) module of the Mesh control plane. That is, the Mesh apiserver module converts the format of the full link constraint rules into a format that the pilot-discovery global routing data model of the Mesh control plane can understand.
  • Step S460 adding, modifying or deleting monitoring rules.
  • the pilot-discovery module of the Service Mesh control plane establishes a long connection with the Consul module when it starts, and monitors the addition, deletion or modification of the configuration of the full-link constraint rules in the Consul module.
  • Step S470 rule pushing.
  • step S460 when there is a change in the whole link constraint rule (environmental configuration or constraint rule), the Consul module will synchronize the changed content to the pilot-discovery module of the Service Mesh control plane in real time by means of rule push.
  • step S480 the grayscale extension configuration is issued.
  • the pilot-discovery module of the Service Mesh control plane After the pilot-discovery module of the Service Mesh control plane receives the full-link constraint rules pushed by the Consul module, it can assemble the full-link constraint rules into the xDS gray scale extended configuration format and send them to the sidecar (agent) of the Service Mesh data plane . After the sidecar is synchronized to the xDS grayscale extension configuration of the full link constraint rule, it can take effect in real time on the Service Mesh and realize grayscale release according to the corresponding release rules.
  • the technical solution provided by the embodiment of this application associates the environment with the constraint rules by configuring the environment and constraint rules on the control plane of the service grid; the control plane configures the environment and the corresponding After constraining the rules, it can be synchronized to the data plane, such as to the proxy (such as sidecar) in the data plane; the proxy on the data plane can perform corresponding grayscale tests on traffic requests according to the environment and corresponding constraint rules.
  • the embodiment of the present application realizes full-link gray scale publishing without application perception, which improves the flexibility of full-link publishing.
  • FIG. 7 is a schematic flowchart of an information processing method provided by an embodiment of the present application. The method can be executed by the above-mentioned computer device. As shown in FIG. 7, the information processing method can include steps S701-S712.
  • Step S701 acquiring traffic requests.
  • the data plane obtains a traffic request for the target service, and the traffic request includes a request label.
  • the request tag includes: at least one tag name, a tag value corresponding to each tag name, and a logical relationship between the tag name and its corresponding tag value.
  • Step S702 judging whether the current service is an entry service.
  • the method for judging whether the current service is an ingress service includes: determining deployment information of the current service, and determining whether the current service is an ingress service based on the deployment information.
  • the current service refers to the service currently accessed by the traffic request.
  • the deployment information of the current service includes, but is not limited to: namespace type, namespace, application identifier, deployment group, etc.
  • the deployment information of the entry service includes but is not limited to: namespace type, namespace, application identifier, deployment group, etc. Therefore, based on the deployment information of the current service, determining whether the current service is an entry service includes: determining whether the current service belongs to the entry service based on one or more information in namespace type, namespace, application identifier, and deployment group.
  • step S703 If it is determined that the current service is an ingress service, then execute from the following step S703; if it is determined that the current service is not an ingress service, then execute from the following step S710.
  • Step S703 matching constraint rules.
  • the constraint rule may be matched based on the request tag carried in the traffic request.
  • the manner of matching constraint rules includes: matching corresponding target constraint rules from a large number of constraint rules based on the request tag carried by the traffic request.
  • matching the request tag includes: matching each tag name in the request tag, the tag value corresponding to each tag name, and the logical relationship between each tag name and its corresponding tag value.
  • the number of constraint rules that match the request label determined from the constraint rule set may be multiple.
  • the priority of the constraint rules can be matched, and the constraint rules with higher priority are matched first. . That is to say, respectively obtain the priorities corresponding to the plurality of constraint rules matching the request label (wherein, the priority corresponding to each constraint rule can be configured by the control plane), and the highest among the multiple priorities
  • the constraint rule corresponding to the priority is determined as the target constraint rule.
  • Step S704 determining the target environment.
  • the environment associated with the target constraint rule may be used as the target environment matching the request label.
  • the ingress matching can be performed on the traffic request according to the ingress service, and after the ingress service is matched, the target environment matching the request tag can be determined according to the environment associated with the ingress service.
  • the entry service and the corresponding constraint rules it will automatically generate and maintain the unique environment ID of the global service, and pass this environment ID to the downstream service. Different environments have their own unique environment IDs, so there will be no differences The chaotic situation of environmental traffic requests ensures the efficiency and accuracy of testing services.
  • Step S705 adding environment description information to the traffic request.
  • Step S706 judging whether there is a version to be tested in the target service.
  • Step S707 judging whether there is target deployment information matching the environment identifier corresponding to the target environment.
  • step S712 If there are one or more versions to be tested in the target service, continue to determine whether there is target deployment information matching the environment identifier corresponding to the target environment. If any version to be tested of the target service has not been deployed to the target environment, access the target service under the service version that has been tested (that is, execute the following step S712).
  • Step S708 determining the target test version to be deployed to the target environment.
  • the target test version deployed to the target environment in the version to be tested is determined. For example, suppose there are two versions to be tested in target service B: version V1 to be tested and version V2 to be tested, version V1 to be tested is deployed in environment 1, and version to be tested V2 is deployed in environment 2; assuming the target environment is environment 1, Then it can be determined that the target test version deployed to the target environment is the version V1 to be tested.
  • Step S709 in the target environment, access the target service under the target test version.
  • step S708 the target service under the target test version is accessed in the target environment.
  • Step S710 judging whether the flow request carries environment description information.
  • step S702 When it is determined in step S702 that the current service is not an ingress service, the environment description information is obtained from the traffic request. Wherein, the environment description information is added after the environment matching the request tag in the traffic request is determined. Then, based on the obtained result of the environment description information, the traffic request is routed.
  • step S711 If it is determined that the traffic request carries environment description information (that is, the environment description information can be obtained), the following step S711 is performed; if it is determined that the traffic request does not carry the environment description information (that is, the environment description information fails to be obtained), the following step S712 is performed.
  • Step S711 taking the environment indicated by the acquired environment description information as the target environment.
  • step S709 is executed.
  • Step S712 accessing the target service under the service version that has been tested.
  • the target service does not have a version to be tested, or any version to be tested that exists has not been deployed to the target environment (such as deployed to other environments other than the target environment), Then access the target service under the service version that has been tested.
  • the technical solution provided by the embodiment of the present application uniformly manages traffic requests based on request tags, and can flexibly route traffic requests to different environments.
  • the service grid data plane implements the definition and delivery of traffic requests based on global routing, and can perform full-link grayscale release without application perception. For users, they only need to focus on how to define traffic requests and divide them. Environmental, understanding and operating costs are low.
  • the embodiment of the present application implements policy control between multiple constraint rules and multiple environments, and flexibly adapts to various complex grayscale publishing scenarios by isolating multiple different environments that do not interfere with each other.
  • the data plane independently implements global routing to control full-link gray scale release, which is completely isolated from ordinary routing rules, and matches global routing first, without being interfered by ordinary routing rules.
  • FIG. 8 is a schematic structural diagram of an information processing device provided by an embodiment of the present application.
  • the information processing apparatus 800 can be applied to the computer equipment in the method embodiments shown in FIG. 2 , FIG. 4 and FIG. 7 .
  • 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.
  • the information processing apparatus 800 is configured to execute corresponding steps in the method provided by the embodiment of the present application.
  • the information processing apparatus 800 includes: an acquiring unit 801 , a determining unit 802 and a processing unit 803 .
  • An acquisition unit 801 configured to acquire a traffic request for a target service, where the traffic request includes a request tag;
  • a determining unit 802 configured to determine a target environment matching the request tag
  • the obtaining unit 801 is also used to obtain the deployment information of the target service.
  • the deployment information of the target service is used to indicate the following information: whether there is a version to be tested in the target service, whether each version to be tested has been deployed to the corresponding environment, and whether the version to be tested has been deployed.
  • the corresponding environment mark after arriving at the corresponding environment;
  • the determining unit 802 when determining the target environment matching the request tag, is specifically configured to:
  • the constraint rule set includes at least one constraint rule, and each constraint rule is associated with an environment;
  • any constraint rule in the constraint rule set is obtained synchronously from the control plane of the service grid; the information processing apparatus 800 further includes: a display unit 804 and a sending unit 805 .
  • a display unit 804 configured to display a rule configuration interface, and generate constraint rules based on configuration parameters input in the rule configuration interface;
  • the display unit 804 is further configured to display the rule issuing interface, and associate the constraint rule with the environment indicated by the environment identifier based on the environment identifier input on the rule issuing interface;
  • the sending unit 805 is configured to send the generated constraint rules and the association relationship between the generated constraint rules and the associated environments to the control plane.
  • the determining unit 802 when determining the target environment matching the request tag, is specifically configured to:
  • the current service refers to the service currently accessed by the traffic request
  • the target service has a service version that has been tested; the determining unit 802 is further configured to perform the following operations:
  • the environment description information After determining that the current service is not an ingress service, obtain the environment description information from the traffic request; the environment description information is added after determining the environment that matches the request tag in the traffic request;
  • Traffic requests are routed according to the environment description information obtained from the traffic requests.
  • the determining unit 802 is specifically configured to: when routing the traffic request according to the environment description information obtained from the traffic request:
  • the environment description information is obtained from the traffic request, the environment indicated by the obtained environment description information is used as the target environment, and the test version for the target service deployed in the target environment is used as the target test version to be used in the target environment Access the target service under the test version of the target;
  • the target service does not have a version to be tested, or any version to be tested that exists has not been deployed to the target environment, and access the target service under the service version that has been tested.
  • the request tag includes: at least one tag name, the tag value corresponding to the tag name, and the logical relationship between the tag name and the tag value; matching the request tag includes: at least one tag name, tag name The corresponding tag values and logical relationships all match.
  • a version to be tested is deployed in an environment, and the deployment information of the target service under the version to be tested includes: the environment identifier corresponding to the environment to which the version to be tested is deployed; the processing unit 803 determines The target test version deployed to the target environment in the version to be tested is specifically used for:
  • the version to be tested corresponding to the target deployment information is used as the target test version.
  • the embodiment of the present application After obtaining the traffic request for the target service, determine the target environment that matches the request tag carried in the traffic request; and, based on the deployment information of the target service, determine the target that is deployed in the target environment in the version to be tested that exists in the target service beta version to access the target service under the target beta version in the target environment.
  • the embodiment of the present application by deploying the version to be tested that exists in the target service into different environments, and the different environments are isolated from each other, the isolation and mutual non-interference between different versions to be tested are realized, and it can flexibly adapt to various complex and cumbersome For the grayscale release scenario under different versions of the service to be tested, it effectively avoids the configuration of the service during the grayscale test and improves the efficiency of the grayscale test.
  • the embodiment of the present application can also uniformly manage the traffic requests based on the request tags, and can flexibly route the traffic requests to different environments, so as to further improve the efficiency of grayscale testing.
  • the embodiment of the present application also provides a computer storage medium, and the computer storage medium stores the computer program executed by the aforementioned information processing device 800, and the computer program includes program instructions,
  • the processor executes the above program instructions, it can execute the methods in the above embodiments corresponding to FIG. 2 , FIG. 4 and FIG. 7 , so details will not be repeated here.
  • the technical details not disclosed in the embodiments of the computer storage medium involved in the present application please refer to the description of the method embodiments of the present application.
  • a computer program product or computer program comprising computer instructions stored in a computer readable storage medium.
  • the processor of the computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device can execute the methods in the embodiments corresponding to the preceding figures 2, 4 and 7. Therefore, here No further description will be given.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Software Systems (AREA)
  • Computer Security & Cryptography (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

一种信息处理方法、装置、计算机设备及存储介质，涉及互联网技术领域。该信息处理方法包括：获取针对目标服务的流量请求，流量请求包括请求标签（S210）；确定与请求标签匹配的目标环境（S220）；获取目标服务的部署信息，目标服务的部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识（S230）；根据目标服务的部署信息，在目标服务存在待测试版本的情况下，确定被部署到目标环境中的目标服务的目标测试版本（S240）；在目标环境中，访问目标测试版本下的目标服务（S250）。通过该方法，可以提高灰度测试的灵活性。

Description

信息处理方法、装置、计算机设备及存储介质
本申请要求于2021年6月24日提交的申请号为202110715643.4、发明名称为“信息处理方法、装置、计算机设备及存储介质”的中国专利申请的优先权，其全部内容通过引用结合在本申请中。
技术领域
本申请涉及互联网技术领域，特别涉及一种信息处理方法、装置、计算机设备及存储介质。
背景技术
灰度发布，是指在黑与白之间，能够平滑过渡的一种发布方式。
采用灰度发布的思想，可以对产品进行灰度测试(或称之为A/B testing，A/B测试)，其中，灰度测试是指，在对已上线的产品中的一个或多个服务进行更新后，为了测试该产品中被更新服务的性能，可让一部分用户继续用产品特性A(即更新前的服务)，一部分用户开始用产品特性B(即更新后的服务)。而当前进行灰度测试时，需要对与产品相关的全链路所涉及的每个服务进行规则配置，如该全链路涉及的服务包括服务1、服务2和服务3，那么，开发人员需要在开始灰度测试之前，分别对服务1、服务2和服务3进行规则配置。
由此可见，基于当前进行灰度测试的方式，存在灵活性较低的问题。
发明内容
本申请实施例提供了一种信息处理方法、装置、计算机设备及存储介质，可以提高服务测试的灵活性。所述技术方案如下：
一方面，本申请实施例提供一种信息处理方法，该方法包括：
获取针对目标服务的流量请求，流量请求包括请求标签；
确定与请求标签匹配的目标环境；
获取目标服务的部署信息，目标服务的部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；
根据目标服务的部署信息，在目标服务存在待测试版本的情况下，确定待测试版本中被部署到目标环境的目标测试版本；
在目标环境中，访问目标测试版本下的目标服务。
一方面，本申请实施例提供一种信息处理装置，该装置包括：
获取单元，用于获取针对目标服务的流量请求，流量请求包括请求标签；
确定单元，用于确定与请求标签匹配的目标环境；
获取单元，还用于获取目标服务的部署信息，目标服务部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应 环境后对应的环境标识；
处理单元，用于根据目标服务的部署信息，在目标服务存在待测试版本的情况下，确定待测试版本中被部署到目标环境的目标测试版本，并在目标环境中，访问目标测试版本下的目标服务。
一方面，本申请实施例提供一种计算机设备，该计算机设备包括存储器和处理器，存储器存储有计算机程序，计算机程序被处理器执行时，使得处理器执行上述的信息处理方法。
一方面，本申请实施例提供一种计算机可读存储介质，该计算机可读存储介质存储有计算机程序，该计算机程序被计算机设备的处理器读取并执行时，使得计算机设备执行上述的信息处理方法。
一方面，本申请实施例提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备执行上述的信息处理方法。
本申请实施例提供的技术方案可以带来如下有益效果：
在获取针对目标服务的流量请求之后，确定与流量请求携带的请求标签匹配的目标环境；并且，基于目标服务的部署信息，确定目标服务存在的待测试版本中，被部署到目标环境中的目标测试版本，以在目标环境中访问目标测试版本下的目标服务。本申请实施例通过将目标服务存在的待测试版本部署到不同的环境中，由不同环境的相互隔离，实现了不同待测试版本之间的隔离和互不干扰，能够灵活地适应各种复杂且繁琐的、针对服务的不同待测试版本下的灰度发布场景，有效避免了灰度测试时对服务的配置，提升了灰度测试的效率。另外，本申请实施例还可以基于请求标签统一管理流量请求，并可以将流量请求灵活路由到不同的环境，以此进一步提升灰度测试时的效率。
附图说明
为了更清楚地说明本申请实施例技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。
图1是本申请实施例提供的一种数据处理系统的架构示意图；
图2是本申请实施例提供的一种信息处理方法的流程示意图；
图3是本申请实施例提供的一种部署环境的场景示意图；
图4是本申请实施例提供的一种下发约束规则的流程示意图；
图5是本申请实施例提供的一种环境创建的场景示意图；
图6是本申请实施例提供的一种规则配置界面的界面示意图；
图7是本申请实施例提供的另一种信息处理方法的流程示意图；
图8是本申请实施例提供的一种信息处理装置的结构示意图；
图9是本申请实施例提供的一种计算机设备的结构示意图。
具体实施方式
这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。
本申请实施例提出一种信息处理方案，可以应用于服务网格中的全链路灰度发布。其中，全链路是指一个流量请求所需要访问的所有服务构成的链路，例如，一个流量请求所需访问的所有服务构成的链路为：服务1->服务2->服务3，该链路即为一个全链路，能够实现服务网格的全局路由。需要说明的是，本申请以任意两个服务之间的路由进行举例说明，可以理解的是，针对服务网格中的任意一个或多个服务，均可以参考本申请的信息处理方法的执行流程，从而在服务网格中实现全局路由。在一个示例中，服务网格包括控制面和数据面，本申请实施例提供的技术方案主要具备如下特点：
(1)重新设计全链路灰度发布的控制面和数据面，控制面引入约束规则、环境和灰度发布等的配置方式，数据面同步控制面所配置的约束规则。
①在控制面进行配置主要包括如下步骤：首先，在控制面上创建环境，将需要灰度发布的特定版本的部署组加入到相同环境中，并在环境中指定一个或多个部署组作为环境的入口；其次，在控制面上创建约束规则，通过设置请求参数来匹配环境入口的灰度流量，并将约束规则发布到目的环境，实现入口规则和环境之间的关联。
②数据面实时同步控制面设置的约束规则，通过服务网格的扩展机制实现全链路灰度发布的具体逻辑。
(2)通过统一的控制面配置全链路的约束规则，只需配置入口流量的约束规则和环境，操作成本低且一致性高。
(3)入口服务标识灰度流量的请求头无需自行维护，数据面在部署组入口匹配到约束规则后，会自动生成和维护全局唯一的环境ID(IDentity，标识)，并将此环境ID传递到下游服务，不同的环境拥有各自唯一的环境ID，不会出现不同环境的灰度流量混乱的情况。
(4)数据面优先匹配全链路约束规则(或称为全局路由规则)，不会被其它的普通路由规则覆盖。
(5)当全链路灰度发布验证成功，恢复或完全升级业务系统，控制面通过约束规则一键删除或者更新全链路灰度发布方式，操作成本低，不易出错。
下面，结合几个实施例对本申请提供的技术方案进行介绍。
首先，对本申请实施例涉及的技术术语进行介绍。
Service Mesh：译为服务网格，是处理服务间通信的基础设施层。它负责构成现代云原生应用程序的复杂服务拓扑来可靠地交付请求。在一些示例中，Service Mesh实现为轻量级网络代理(称为Sidecar)阵列，这些代理与应用程序代码部署在一起，对应用程序来说无需感知代理的存在。
sidecar：是从主应用进程中独立出来的单独进程，与主应用进程松散耦合，可以认为是一种代理。sidecar可以屏蔽不同编程语言的差异，统一实现微服务的可观察性、路由、全链路灰度、鉴权、限流、熔断器等功能。
部署组：执行应用批量部署的逻辑概念。一个部署组内包括多个应用实例，且这多个应 用实例上运行相同的应用程序。
环境：环境是一组部署组的集合，是灰度发布(全局路由)规则的目的地。环境中的部署组属于不同的应用。可以认为用户通过划分环境划分出了灰度环境。
灰度发布：是软件上线过程中常见的上线方式，是指在发布过程中，将具有一定特征或者比例的流量分配到需要被验证的版本中，用来观察新的验证版本的线上运行状态。
灰度发布规则：用户在灰度发布规则上配置请求需要满足的条件。当请求满足一定条件后，可以通过灰度发布规则将流量路由到某一个环境中。
请参考图1，图1是本申请实施例提供的一种信息处理系统的架构示意图。该信息处理系统的架构图可以包括：控制面110和数据面120。
在一个示例中，控制面110和数据面120分别实现为一台计算机设备；在另一个示例中，控制面110和数据面120集成于同一台计算机设备。可选地，计算机设备包括：车载设备、智能手机、平板电脑、智能可穿戴设备等终端设备、服务器等。控制面110与数据面120之间通过有线通信方式或无线通信方式进行直接或间接地通信，本申请在此不做限制。
本申请实施例中，信息处理系统可以为Service Mesh(服务网格)，也可以为微服务框架系统。其中，微服务框架系统包括但不限于：Spring Cloud(一种分布式的微服务系统)、Dubbo(一种高性能的轻量级服务系统)、Thrift(一种基于远程过程调用的微服务系统)、grpc(一种严格接口约束的微服务系统)等。
以本申请中的控制面110和数据面120分别实现为一台计算机设备为例，控制面110所包括的各个代理用于进行服务相关的配置(即服务配置)，例如，配置环境，以及配置与环境相关联的约束规则等；数据面120所包括的各个代理用于服务发现，服务发现用于指示根据从控制面110所同步的环境以及与环境相关联的约束规则，进行服务测试或者灰度测试等等。另外，数据面120中的服务A与服务B可以为同一个应用程序中的不同服务，也可以为不同应用程序中的不同服务。
在一个示例中，本申请实施例提供的信息处理方法与区块链技术相结合，例如，可以将约束规则集、服务的部署信息等上传至区块链中进行保存，以确保区块链上的数据不易被篡改。其中，区块链(Blockchain)是分布式数据存储、点对点传输、共识机制、加密算法等计算机技术的新型应用模式。
在一个示例中，本申请实施例提供的信息处理系统中涉及的设备部署在区块链网络中，并作为区块链网络中的节点设备，例如，将控制面110和数据面120均作为区块链网络中的节点设备，以共同构成区块链网络。基于此，本申请中针对流量请求进行信息处理的相关流程能够在区块链上执行，这样既保证了信息处理流程的公平公正，也使得信息处理流程具备可追溯性，提升信息处理流程的安全性。
在一个示例中，由于区块链中涉及到大量的数据计算以及数据存储服务，而大量的数据计算以及数据存储服务需要花费大量的计算机运营成本，因此，本申请所涉及的约束规则集、服务的部署信息均由云技术中的云存储技术进行实现。也即，将区块链通过云存储技术存储在“云”上，在需要将约束规则集、服务的部署信息等数据存储至区块链的情况下，通过云存储技术将这些数据上传到“云”上的区块链中，且在需要读取这些数据的情况下，也可以随时从“云”上的区块链中读取数据。通过云存储技术，降低了对终端设备的存储要求，扩 大了区块链的应用范围。
其中，云存储(cloud storage)是在云计算概念上延伸和发展出来的一个新的概念；分布式云存储系统(以下简称存储系统)是指通过集群应用、网格技术以及分布存储文件系统等功能，将网络中大量不同类型的存储设备(存储设备也称为存储节点)通过应用软件或应用接口集合起来协同工作、共同对外提供数据存储和业务访问功能的存储系统。
在一个示例中，本申请实施例提供的信息处理方法由数据面120中的代理执行，可选地，数据面120中的代理在同步了用户在控制面110上所配置的约束规则之后，执行本申请实施例提供的信息处理方法。示例性地，数据面120中的代理获取针对目标服务(如服务B)的流量请求，并基于流量请求携带的请求标签，确定与请求标签匹配的目标环境，目标服务包括已完成测试的服务版本；数据面120中的代理获取目标服务的部署信息，目标服务的部署信息用于指示以下至少一个信息：目标服务是否存在待测试版本、待测试版本是否被部署到相应的环境、以及环境对应的环境标识；数据面120中的代理基于部署信息，确定目标服务存在的待测试版本中被部署到目标环境的目标测试版本，并在目标环境中访问目标测试版本下的目标服务。
应理解，本申请实施例描述的系统架构示意图是为了更加清楚地说明本申请实施例的技术方案，并不构成对本申请实施例提供的技术方案的限定，本领域技术人员可知，随着系统架构的演变和新业务场景的出现，本申请实施例提供的技术方案对于类似的技术问题，同样适用。
请参考图2，图2是本申请实施例提供的一种信息处理方法的流程示意图。该信息处理方法可以应用于计算机设备，可选地，计算机设备为上述图1所示信息处理系统中的数据面120对应的设备，如数据面120对应的代理设备。如图2所示，本申请实施例提供的信息处理方法包括步骤S210～S250。
S210，获取针对目标服务的流量请求，流量请求包括请求标签。
本申请实施例提供的信息处理方法可以适用于灰度发布场景。也就是说，在应用或者程序发布的过程中，可以通过本申请实施例提供的信息处理方法，将具有一定特征或者比例的流量分配到需要测试的新服务版本中，用来观察新服务版本的线上运行状态，以实现应用的新服务版本的可靠发布。在下述实施例中，以一个流量请求为例进行说明，应理解，本申请针对一批或者大量的流量请求中的任意一个流量请求同样适用，其中，一批流量请求中的每个流量请求并行执行本申请实施例提供的技术方案，或者按照流量请求的接收顺序先后(串行)执行本申请实施例提供的技术方案，本申请在此不做限定。
数据面获取针对目标服务的流量请求。目标服务是指用户发起的流量请求即将访问的下游服务，下游服务是指当前服务之后访问的服务，该当前服务是指流量请求当前访问的服务。例如，当前服务为服务A，服务A的下游服务包括：服务B、服务C、服务D、服务E、服务F等等，则目标服务为服务B。
在一个示例中，目标服务存在已完成测试的服务版本，由此可以确保在流量请求不能成功访问待测试版本(待测试的服务版本)下的目标服务时，该流量请求能够访问已完成测试的服务版本下的目标服务。换句话说，已完成测试的服务版本下的目标服务用于在流量请求不能成功访问需要测试的服务版本下的目标服务时，保证流量请求的可路由性。其中，可路 由性是指流量请求到达时不会被终止，可以继续进行业务访问。
本申请实施例中，流量请求携带请求标签。可选地，请求标签包括但不限于：至少一个标签名、每个标签名对应的标签值，以及标签名和其对应的标签值之间的逻辑关系。可选地，标签名和其对应的标签值之间的逻辑关系包括但不限于：等于、不等于、包含、不包含、正则表达式等。示例性地，标签名和其对应的标签值之间的逻辑关系为包含，则标签名包含其对应的标签值。
S220，确定与请求标签匹配的目标环境。
环境可以是包括了一个或者多个待测试版本下的目标服务的聚集地。可选地，本申请实施例中，不同的环境之间是相互隔离的，也就是说，环境A与环境B之间是不能进行交互或者通信的。可选地，环境对应有环境标识，以唯一标识环境。
数据面基于流量请求携带的请求标签，可以确定与请求标签匹配的目标环境。在一个示例中，请求标签包括但不限于：至少一个标签名、每个标签名对应的标签值，以及标签名和其对应的标签值之间的逻辑关系；基于此，可选地，与请求标签匹配包括：与请求标签包括的至少一个标签名、至少一个标签名分别对应的标签值、每个标签名和其对应的标签值之间的逻辑关系均匹配。
本申请实施例对确定目标环境的方式不作限定。在一个示例中，请求标签与目标环境之间预先建立有关联关系，数据面获取到请求标签，即可基于请求标签获取与之关联的目标环境；在另一个示例中，数据面基于请求标签的内容，获取与请求标签的内容匹配的环境标识，该环境标识对应的环境即为目标环境；在又一个示例中，环境对应的环境标识可以由请求标签计算得到，则数据面获取到请求标签后，基于请求标签计算环境标识，计算得到的环境标识对应的环境即为目标环境。下面，对一种确定目标环境的方式展开介绍。
在一个示例中，上述步骤S220包括步骤S222～S226。
S222，获取约束规则集。
约束规则集包括至少一个约束规则，其中，一个约束规则与一个环境相关联。可选地，约束规则与环境之间是一一关联的关系，也即，一个约束规则与一个环境相关联，且一个环境与一个约束规则相关联；或者，约束规则与环境之间是多对一关联的关系，也即，一个约束规则与一个环境相关联，且一个环境与一个或多个约束规则相关联。
本申请实施例通过约束规则与环境之间的关联，实现了多个约束规则和多个环境之间的策略控制；并且，通过约束规则隔离出多个互不干扰的不同环境，可以灵活地适应各种复杂的灰度发布场景。
S224，确定至少一个约束规则中与请求标签匹配的目标约束规则。
约束规则集包括至少一个约束规则，数据面基于流量请求的请求标签，从约束规则集包括的至少一个约束规则中，确定与请求标签匹配的目标约束规则。
可选地，至少一个约束规则中与请求标签匹配的约束规则的数量为多个，在这种情况下，数据面可以获取这多个约束规则分别对应的优先级(其中，每个约束规则对应的优先级可以由控制面进行配置，并同步至数据面)，然后，将多个约束规则分别对应的优先级中，最高优先级对应的约束规则确定为目标约束规则。也就是说，在基于请求标签匹配到多个约束规则的情况下，按照约束规则对应的优先级的高低来确定目标约束规则。
S226，将目标约束规则关联的环境，作为目标环境。
一个约束规则与一个环境相关联，从而，在确定了与请求标签匹配的目标约束规则的情况，可以将目标约束规则关联的环境，作为与请求标签匹配的目标环境。
可选地，在确定出与请求标签匹配的目标环境之后，可以为流量请求添加环境描述信息，该环境描述信息用于指示目标环境，可选地，环境描述信息包括目标环境对应的环境标识。通过这种方式，可以为流量请求进行标记处理，以确保该流量请求只能在目标环境中路由，而不能流入到其他环境中，实现了不同环境之间的隔离，有效避免了不同环境的流量请求混乱的情况，且便于后续进行流量的追溯。
在一个示例中，上述步骤S224之前，还包括步骤S221～S223。
步骤S221，确定当前服务的部署信息。
当前服务是流量请求当前访问的服务。可选地，当前服务的部署信息包括但不限于：命名空间类型、命名空间、应用标识、部署组等。
步骤S223，基于当前服务的部署信息，确定当前服务是否为入口服务。
入口服务是数据面从服务网格的控制面同步得到的。可选地，入口服务的部署信息包括但不限于：命名空间类型、命名空间、应用标识、部署组等。
基于当前服务的部署信息和入口服务的部署信息的介绍，上述基于当前服务的部署信息，确定当前服务是否为入口服务，包括：基于命名空间类型、命名空间、应用标识、部署组中的一种或者多种信息，确定当前服务是否为入口服务。
在基于上述步骤S223确定当前服务为入口服务的情况下，执行上述步骤S224，即继续执行确定至少一个约束规则中与请求标签匹配的目标约束规则的步骤。
在基于上述步骤S223确定当前服务不是入口服务的情况下，可选地，数据面从流量请求中获取环境描述信息，该环境描述信息是在确定与流量请求携带的请求标签匹配的环境后添加的；然后，数据面基于环境描述信息的获取结果，对流量请求进行路由。可选地，环境描述信息的获取结果包括：获取到环境描述信息或者未获取到环境描述信息。基于此，在获取到环境描述信息的情况下，对流量请求进行路由包括：将环境描述信息指示的环境，作为目标环境；在未获取到环境描述信息的情况下，则表示目标服务不存在待测试版本，或者目标服务存在的任一待测试版本均未被部署到目标环境(而是被部署到目标环境之外的其他环境)中，从而对流量请求进行路由包括：访问已完成测试的服务版本下的目标服务。
S230，获取目标服务的部署信息，目标服务的部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识。
本申请实施例中，目标服务存在多个服务版本，并且，这多个服务版本中至少包括已完成测试的服务版本，还可以包括至少一个待测试的服务版本(本申请实施例中又称为待测试版本)。可选地，控制面可以将目标服务存在的待测试版本中的部分或者全部待测试版本部署到相应的环境中。可选地，一个环境中只能部署目标服务的一个待测试版本。
示例性地，请参见图3，图3是本申请实施例提供的一种部署环境的场景示意图。如图3所示，假设目标服务为服务B，服务B存在3个待测试的版本，分别为B1、B2、B3，并且B1、B2、B3分别被部署于环境1、环境2以及环境3中。服务B存在的已完成测试的服务版本可以为B0，B0部署于主链路中。环境1、环境2以及环境3之间相互隔离，主链路不署于任何一个环境。
由于不同的环境对应不同的环境标识，从而，不同待测试版本被部署到相应环境后对应的环境标识也不同。例如，目标服务为服务B，服务B存在2个待测试版本：待测试版本V1和待测试版本V2，可以将待测试版本V1部署到环境1、将待测试版本V2部署到环境2；其中，环境1对应的环境标识与环境2对应的环境标识不同。
数据面可以获取目标服务的部署信息，该目标服务的部署信息用于指示以下信息：目标服务是否存在待测试版本、待测试版本是否被部署到相应的环境、以及环境对应的环境标识。应理解，在目标服务不存在待测试版本的情况下，目标服务的部署信息用于指示：目标服务不存在待测试版本；在目标服务存在待测试版本且待测试版本未被部署到相应的环境的情况下，目标服务的部署信息用于指示：目标服务存在待测试版本，且待测试版本未被部署到相应环境；在目标服务存在待测试版本且待测试版本被部署到相应的环境的情况下，目标服务的部署信息用于指示：目标服务存在待测试版本、且待测试版本被部署到相应的环境，且待测试版本被部署到的环境对应的环境标识。
S240，根据目标服务的部署信息，在目标服务存在待测试版本的情况下，确定待测试版本中被部署到目标环境的目标测试版本。
由于在目标服务存在待测试版本的情况下，目标服务的部署信息用于指示：目标服务存在待测试版本、待测试版本是否被部署到相应的环境、各个环境对应的环境标识，因此，基于目标服务的部署信息，可以获取各个待测试版本是否被部署到相应的环境，如果待测试版本被部署到相应的环境，则可以进一步确定待测试版本被部署到的环境。
本申请实施例中，数据面在上述步骤S220中，确定了与流量请求匹配的目标环境；且在上述步骤S230中，获取了目标服务的部署信息。基于此，在目标服务存在待测试版本的情况下，数据面基于目标服务的部署信息，可以确定目标服务存在的待测试版本中，被部署到目标环境的待测试版本(即目标测试版本)。
在一个示例中，假设目标服务的部署信息用于指示：目标服务存在待测试版本，且待测试版本被部署到相应的环境；则确定待测试版本中被部署到目标环境的待测试版本包括：基于待测试版本下目标服务的部署信息，确定与目标环境对应的环境标识匹配的目标环境信息；将目标部署信息对应的待测试版本，作为目标待测试版本。其中，一个待测试版本被部署到一个环境中，且待测试版本下的目标服务的部署信息包括：待测试版本被部署到的环境对应的环境标识。基于此，不同的待测试版本下的目标服务的部署信息中包括的环境标识不同。
示例性地，目标服务为服务B，服务B存在2个待测试版本：待测试版本V1和待测试版本V2。基于服务B的部署信息可以确定待测试版本V1被部署到环境1、待测试版本V2被部署到环境2。假设环境1对应的环境标识为test001、环境2对应的环境标识为test002，则待测试版本V1下的服务B的部署信息包括test001、待测试版本V2下的服务B的部署信息包括test002。假设目标环境对应的环境标识为test001，由于待测试版本V1下的服务B的部署信息包括test001，则与目标环境对应的环境标识匹配的目标部署信息为待测试版本V1下的服务B的部署信息，且目标部署信息对应的待测试版本(目标待测试版本)为待测试版本V1。
步骤S250，在目标环境中，访问目标测试版本下的目标服务。
数据面在基于步骤S240获取到目标测试版本后，可以在目标环境中，访问目标测试版本下的目标服务，从而实现灰度发布的目的。
当然，在一些示例中，目标服务存在的待测试版本并不一定被部署在目标环境中，或者说，目标环境中并不一定部署有目标服务存在的待测试版本。例如，目标服务存在的待测试版本被部署到目标环境之外的其他环境中；或者，目标服务存在的待测试版本未被部署到任何环境中。此时，数据面不能在目标环境中访问目标服务，为确保流量请求的可路由性，本申请实施例针对这一情况，提供访问目标服务的方式，如下所示。
在一个示例中，在目标服务存在的任一待测试版本，均被部署到目标环境之外的其他环境(均未被部署到目标环境)的情况下，访问已完成测试的服务版本下的目标服务。示例性地，目标服务为服务B，服务B存在2个待测试版本：待测试版本V1和待测试版本V2，以及存在一个已完成测试的服务版本V0。假设目标环境为环境1，服务B存在的2个待测试版本均被部署到环境1之外的环境中，如被分别部署到环境2和环境3中，则不能在目标环境(环境1)中访问待测试版本V1和待测试版本V2下的服务B，而是访问已完成测试的服务版本V0下的服务B。在另一个示例中，在目标服务存在的任一所述待测试版本，均未被部署到任何环境的情况下，访问待测试版本下的目标服务。
当然，在另一些示例中，目标服务可能并不存在任何待测试版本，而只存在已完成测试的服务版本。此时，为确保流量请求的可路由性，数据面访问的是已完成测试的服务版本下的目标服务。
综上所述，本申请实施例提供的技术方案，在获取针对目标服务的流量请求之后，确定与流量请求携带的请求标签匹配的目标环境；并且，基于目标服务的部署信息，确定目标服务存在的待测试版本中，被部署到目标环境中的目标测试版本，以在目标环境中访问目标测试版本下的目标服务。本申请实施例通过将目标服务存在的待测试版本部署到不同的环境中，由不同环境之间的相互隔离，实现了不同待测试版本之间的隔离和互不干扰，能够灵活地适应各种复杂且繁琐的、针对服务的不同待测试版本下的灰度发布场景，有效避免了灰度测试时对服务的配置，提升了灰度测试的效率。另外，本申请实施例还可以基于请求标签统一管理流量请求，并可以将流量请求灵活路由到不同的环境，以此进一步提升灰度测试时的效率和灵活性。
请参见图4，图4是本申请实施例提供的一种下发约束规则的流程示意图。本申请实施例主要对在服务网格的控制面生成约束规则集中的任一约束规则的过程，以及将生成的约束规则同步到该服务网格的数据面的过程进行说明。本申请实施例可以应用于服务网格中的全链路灰度发布场景。如图4所示，该流程示意图可以包括下述步骤S410～S480。
步骤S410，创建环境。
使用全链路灰度发布之前，需要先配置环境。环境包含应用中需要进行灰度测试的部署组。用户可以通过Web(网页)控制台创建环境。另外，创建环境包括但不限于：配置与环境相关的基本信息(例如环境名称、环境标识等)以及选择相应的部署组。
示例性地，请参考图5，图5是本申请实施例提供的一种环境创建的场景示意图。如图5(a)所示，用户所创建的环境名称可以为“test001”，并且，所创建的环境名称需要满足特定条件，例如：最长字符为60个，并且只能包括小写字母、数字以及分隔符。当然，环境名称需要满足的特定条件也可以进行更改或者设置，例如，管理员可以将该特定条件更改为：最长字符为30个，并且只能包括大写字母、数字以及分隔符等等。进一步地，还可以进行相 关的备注，备注内容可以用于指示创建的该环境的用途或者作用等等，例如，备注的内容可以为“测试”。
在完成环境创建之后，可以选择需要灰度发布的部署组加入环境，同时设置环境入口(即入口服务)。如图5(b)所示，用户在选择相应部署组的过程中，可以根据部署组的命名空间、命名空间类型等进行相应部署组的筛选。例如，用户需要将服务1的版本1进行灰度发布，则用户可以找到与服务1相关的部署组，然后将服务1的版本1的部署组添加至该环境中。另外，将需要灰度发布的部署组加入环境之后，可以为该环境设置环境入口。通常，环境入口是一个网关(gateway)，用于对想要进入该环境的流量请求进行校验，以此来判断该流量请求是否应该进入到该环境中。同一个环境中支持多个环境入口，在请求经过每一个入口部署组时，都会判断请求是否应该进入环境中。配置环境入口的方法包括：在添加至该环境的部署组中，随机选择一个或者多个部署组作为入口部署组。
步骤S420，创建约束规则。
服务网格的数据面可以从服务网格的控制面同步约束规则集。其中，约束规则集包括至少一个约束规则，且一个约束规则与一个环境相关联。基于此，约束规则集中的任一约束规则由用户在服务网格的控制面上配置后，服务网格的数据面基于用户在该控制面的配置进行同步。
在用户通过服务网格配置任意约束规则时，该服务网格可先通过显示设备显示规则配置界面，并基于在规则配置界面输入的配置参数生成相应的约束规则；其中，配置参数包括但不限于：至少一个标签名、每个标签名对应的标签值，以及标签名和其对应的标签值之间的逻辑关系。可选地，标签名和其对应的标签值之间的逻辑关系包括但不限于：等于、不等于、包含、不包含、正则表达式等，本申请实施例对此不作具体限定。可选地，全链路灰度发布支持同时生效多条约束规则，并支持为约束规则配置优先级。当同一条请求同时满足多条约束规则时，会优先匹配高优先级的约束规则。
进一步地，显示设备可显示规则发布界面，并基于在规则发布界面输入的环境标识，将生成的约束规则与环境标识指示的环境相关联。其中，环境标识是环境的唯一表示，可选地，环境标识包括但不限于：字母、符号、数字中的一种或者多种。之后，显示设备可将生成的约束规则，以及约束规则和环境之间的关联关系发送到控制面。其中，将生成的约束规则发布至相应的环境中，即可建立约束规则和环境之间的关联关系，之后，基于约束规则即可确定与该约束规则关联的环境。
需要说明的一点是，本申请实施例以基于标签形式的约束规则匹配方式进行介绍，在一些示例中，约束规则匹配方式还可以扩展为基于其它形式，如host(文件)形式、URL(Uniform Resource Locator，统一资源定位符)形式或者cookie(纯文本文件)形式等。
在一个示例中，用户通过Web控制台创建灰度发布规则(即约束规则)，包括：用户向Web控制台传入配置约束规则时所需的相关参数，Web控制台接收到这些相关参数后生成相应的约束规则。可选地，创建约束规则包括但不限于：配置与约束规则相关的基本信息(例如规则名称)、配置请求参数规则以及发布目的地配置等。
示例性地，请参考图6，其示出了本申请一个实施例提供的规则配置界面的示意图。首先，是约束规则的基本设置。如图6(a)所示，用户所创建的约束规则的规则名称可以为“lane-test-rule001”，并且，所创建的约束规则的规则名称需要满足特定条件，例如：支持中 英文字符，不超过60字符等等。当然，约束规则的规则名称需要满足的特定条件也可以进行更改或者设置，例如，管理员可以将该特定条件更改为：最长字符为30个、只能包括大写字母、数字以及分隔符等等。此外，还可以进行相关的备注，备注用于指示创建的约束规则的用途或者作用等等，例如，备注的内容可以为“测试”。
在完成约束规则的基本设置之后，可以进行请求参数规则的配置。如图6(b)所示，配置请求参数规则包括但不限于：配置标签名、标签值、逻辑关系以及规则生效条件等等。可选地，标签名最多为32字节，标签值最多为128字符。可选地，配置请求参数规则时所配置的逻辑关系包括但不限于：等于、不等于、包含、不包含、正则表达式等。其中，当逻辑关系配置为等于和不等于时，标签值只能填写为单个值；当逻辑关系配置为包含和不包含时，标签值可以填写多个值，并使用英文半角逗号分隔。此外，规则生效条件是指：上述几种逻辑关系，或(满足任一逻辑关系)、与(满足全部逻辑关系)。
如图6(b)所示，约束规则可以为：aaa等于123、bbb不等于456，约束规则可以为多条。可选地，标签名是用户业务中的自定义标签，自定义标签是指用户自定义的业务参数转换为用户业务中使用的标签。在一个示例中，自定义标签的来源包括如下两种方式：
方式一：通过微服务网关将请求的参数转换为标签。例如，通过微服务网关的tag(标签)插件，将请求的path(通道)、query(问题)、header(请求头)中包含的业务参数，转换为标签。
方式二：用户在代码中配置标签。
在约束规则的基本设置以及请求参数规则的配置之后，就可以选择在目的环境中发布。如图6(c)所示，用户可以为所配置的约束规则配置相应的发布目的地(目的环境)，例如，设置目的环境为“test001”，从而，可以将规则名称为“lane-test-rule001”的约束规则与环境名称为“test001”的环境之间进行关联。
步骤S430，规则下发。
用户在Web控制台完成环境创建以及约束规则创建之后，可以将所配置的约束规则下发至OSS(Object Storage Service，对象存储服务)控制模块。约束规则下发的方式可以为：Web控制台调用OSS控制模块的全局路由配置API(Application Program Interface，应用程序接口)，来下发全链路约束规则。
步骤S440，规则下发。
OSS控制模块在接收到Web控制台下发的全链路约束规则之后，可以按照Service Mesh全局路由数据模型的格式重新组装配置。其中，重新组装配置可以包括格式转换，例如，OSS控制模块将全链路约束规则的格式转换为Service Mesh全局路由数据模型可以理解的格式。然后，OSS控制模块调用Service Mesh控制面的apiserver(接口服务)模块的restful API接口，下发全链路约束规则。
在一个示例中，约束规则的下发可以由Web控制台在配置好约束规则之后，通过Consul(服务发现)模块发送至控制面的apiserver模块。在另一个示例中，约束规则的下发可以由Web控制台在配置好约束规则之后，直接发送至控制面的apiserver模块。
步骤S450，保存规则。
Service Mesh控制面的apiserver模块(简称Mesh apiserver模块)在获取到OSS控制模块下发的全链路约束规则之后。Mesh apiserver模块按照Mesh控制面的pilot-discovery(服务 发现和配置)模块全局路由数据模型的格式将规则保存至Consul模块。也即，Mesh apiserver模块将全链路约束规则的格式转换为Mesh控制面的pilot-discovery全局路由数据模型可以理解的格式。
步骤S460，监听规则的新增、修改或删除。
Service Mesh控制面的pilot-discovery模块启动时与Consul模块之间建立长连接，并监听Consul模块中全链路约束规则配置的新增、删除或修改。
步骤S470，规则推送。
通过步骤S460的监听，当有全链路约束规则(环境配置或约束规则)变更时，Consul模块实时将变更内容通过规则推送的方式同步给Service Mesh控制面的pilot-discovery模块。
步骤S480，灰度扩展配置下发。
Service Mesh控制面的pilot-discovery模块接收到来自Consul模块推送的全链路约束规则之后，可以将全链路约束规则组装成xDS灰度扩展配置格式下发给Service Mesh数据面的sidecar(代理)。sidecar同步到全链路约束规则的xDS灰度扩展配置之后，可以在Service Mesh实时生效并根据相应的发布规则实现灰度发布。
需要说明的一点是，本申请实施例中，Web控制台、对象存储服务模块(OSS控制模块)、Consul模块，可以是与控制面的apiserver模块和pilot-discovery模块集成于同一台计算机设备中的模块；Web控制台、OSS控制模块、Consul模块，也可以是与控制面的apiserver模块和pilot-discovery模块之间建立通信连接的外接设备。
综上所述，本申请实施例提供的技术方案，通过在服务网格的控制面进行环境以及约束规则的相关配置，以将环境与约束规则之间关联起来；控制面配置好环境和相应的约束规则后，可以同步到数据面中，如同步到数据面中的代理(如sidecar)中；数据面的代理可以根据环境和相应的约束规则，对流量请求进行相应的灰度测试。本申请实施例实现了在应用无感知的情况下进行全链路灰度发布，提升了全链路发布的灵活性。
下面，以一个示例性实施例对本申请提供的信息处理方法进行介绍。
请参见图7，图7是本申请实施例提供的信息处理方法的流程示意图，该方法可由上述的计算机设备执行，如图7所示，该信息处理方法可包括步骤S701～S712。
步骤S701，获取流量请求。
数据面获取针对目标服务的流量请求，该流量请求中包括请求标签。其中，请求标签包括：至少一个标签名、每个标签名对应的标签值，以及标签名和其对应的标签值之间的逻辑关系。例如，请求标签可以为：aaa＝123。其中，“aaa”为标签名，123为标签名对应的标签值，“＝”为标签名与其对应的标签值之间的逻辑关系。
步骤S702，判断当前服务是否为入口服务。
本申请实施例判断当前服务是否为入口服务的方式包括：确定当前服务的部署信息，并基于部署信息，确定当前服务是否为入口服务。其中，当前服务是指流量请求当前访问的服务。当前服务的部署信息包括但不限于：命名空间类型、命名空间、应用标识、部署组等。入口服务的部署信息包括但不限于：命名空间类型、命名空间、应用标识、部署组等。因此，基于当前服务的部署信息，确定当前服务是否为入口服务，包括：基于命名空间类型、命名空间、应用标识、部署组中的一种或者多种信息，确定当前服务是否隶属于入口服务。
若确定当前服务为入口服务时，则从下述步骤S703开始执行；若确定当前服务不是入口服务时，则从下述步骤S710开始执行。
步骤S703，匹配约束规则。
在确定当前服务为入口服务的情况下，可以基于流量请求所携带的请求标签匹配约束规则。其中，匹配约束规则的方式包括：基于流量请求所携带的请求标签，从大量的约束规则中匹配相应的目标约束规则。可选地，与请求标签匹配包括：与请求标签中的每个标签名、每个标签名对应的标签值、以及每个标签名和其对应的标签值之间的逻辑关系均匹配。
在匹配约束规则的过程中，从约束规则集中确定出来的与请求标签匹配的约束规则的数量可能为多个，此时，可以按照约束规则的优先级进行匹配，优先级高的约束规则优先匹配。也即，分别获取与请求标签匹配的多个约束规则分别对应的优先级(其中，每个约束规则对应的优先级可以由控制面进行优先级的配置)，并将多个优先级中的最高优先级对应的约束规则确定为目标约束规则。
步骤S704，确定目标环境。
在确定了目标约束规则之后，可以将目标约束规则关联的环境，作为与请求标签匹配的目标环境。通过这种方式，可以根据入口服务对流量请求进行入口匹配，然后匹配到入口服务之后，再根据与入口服务关联的环境，确定出与请求标签匹配的目标环境。在匹配到入口服务以及相应的约束规则之后，会自动生成和维护全局服务的唯一的环境标识，并将此环境标识传递到下游服务，不同的环境拥有各自唯一的环境标识，从而不会出现不同环境流量请求混乱的情况，保证了测试服务的高效性和准确性。
步骤S705，在流量请求中添加环境描述信息。
在确定了流量请求所在的目标环境之后，可以对该流量请求进行染色处理。其中，染色处理是指在流量请求中添加与该流量请求所匹配到的目标环境对应的环境描述信息，以实现对该流量请求进行标记处理。例如，添加的环境描述信息包括但不限于目标环境对应的环境标识等。换句话说，在流量请求中添加环境描述信息后，该流量请求被染色为目标环境。从而，可以确保该流量请求只能在目标环境中路由，并且还可以方便后续进行流量的追溯。
步骤S706，判断目标服务是否存在待测试版本。
在流量请求中添加环境描述信息之后，需要进一步判断目标服务是否存在一个或者多个待测试版本，以及各待测试版本被部署到的环境。
若目标服务存在待测试版本，则执行下述步骤S707；若目标服务不存在任何待测试版本，则执行下述步骤S712。
步骤S707，判断是否存在与目标环境对应的环境标识匹配的目标部署信息。
若目标服务存在一个或者多个待测试版本，则继续判断是否存在与目标环境对应的环境标识匹配的目标部署信息。若目标服务存在的任一待测试版本均未被部署到目标环境，则访问已完成测试的服务版本下的目标服务(也即执行下述步骤S712)。
步骤S708，确定被部署到目标环境的目标测试版本。
基于目标服务存在的待测试版本被部署到的环境，确定待测试版本中被部署到目标环境的目标测试版本。例如，假设目标服务B存在两个待测试版本：待测试版本V1、待测试版本V2，待测试版本V1被部署于环境1、待测试版本V2被部署于环境2；假设目标环境为环境1，则可以确定被部署到目标环境的目标测试版本为待测试版本V1。
步骤S709，在目标环境中，访问目标测试版本下的目标服务。
通过步骤S708确定出目标测试版本之后，在目标环境中，访问目标测试版本下的目标服务。
步骤S710，判断流量请求是否携带环境描述信息。
在通过步骤S702确定当前服务不是入口服务时，则从流量请求中获取环境描述信息。其中，环境描述信息是在确定出与流量请求中的请求标签匹配的环境后添加的。然后，基于环境描述信息的获取结果，对流量请求进行路由。
若判断流量请求携带环境描述信息(即可以获取到环境描述信息)，则执行下述步骤S711；若判断流量请求不携带环境描述信息(即环境描述信息获取失败)，则执行下述步骤S712。
步骤S711，将获取到的环境描述信息指示的环境作为目标环境。
若从流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境。之后，执行上述步骤S709。
步骤S712，访问已完成测试的服务版本下的目标服务。
若从流量请求中获取环境描述信息失败，则确定目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到目标环境(如被部署到目标环境之外的其它环境)，则访问已完成测试的服务版本下的目标服务。
综上所述，本申请实施例提供的技术方案，基于请求标签统一管理流量请求，并可以将流量请求灵活路由到不同的环境。并且，服务网格数据面基于全局路由的方式实现流量请求的定义和传递，能够在应用无感知的情况下进行全链路灰度发布，对于用户来说，只需要关注如何定义流量请求和划分环境，理解和操作成本低。另外，本申请实施例实现了多个约束规则和多个环境之间的策略控制，通过隔离出多个互不干扰的不同环境，灵活地适应了各种复杂的灰度发布场景。最后，数据面独立实现全局路由来控制全链路灰度发布，与普通路由规则实现完全隔离，并优先匹配全局路由，不会被普通路由规则所干扰。
请参见图8，图8是本申请实施例提供的一种信息处理装置的结构示意图。该信息处理装置800可应用于图2、图4和图7所示的方法实施例中的计算机设备。信息处理装置800可以是运行于轻量节点中的一个计算机程序(包括程序代码)，例如该信息处理装置800为一个应用软件。该信息处理装置800用于执行本申请实施例提供的方法中的相应步骤。该信息处理装置800包括：获取单元801、确定单元802和处理单元803。
获取单元801，用于获取针对目标服务的流量请求，流量请求包括请求标签；
确定单元802，用于确定与请求标签匹配的目标环境；
获取单元801，还用于获取目标服务的部署信息，目标服务的部署信息用于指示下述信息：目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；
处理单元803，用于根据目标服务的部署信息，在所述目标服务存在所述待测试版本的情况下，确定待测试版本中被部署到目标环境的目标测试版本，并在目标环境中，访问目标测试版本下的目标服务。
在一种可能的实现方式中，确定单元802在确定与请求标签匹配的目标环境时具体用于：
获取约束规则集，约束规则集包括至少一个约束规则，且每个约束规则与一个环境相关 联；
确定至少一个约束规则中与请求标签匹配的目标约束规则，并将目标约束规则关联的环境，作为目标环境。
在一种可能的实现方式中，约束规则集中的任一约束规则是从服务网格的控制面同步得到的；该信息处理装置800还包括：显示单元804和发送单元805。
显示单元804，用于显示规则配置界面，并基于在规则配置界面输入的配置参数生成约束规则；
显示单元804，还用于显示规则发布界面，并基于在规则发布界面输入的环境标识，将约束规则与环境标识指示的环境相关联；
发送单元805，用于将生成的约束规则，以及生成的约束规则和关联的环境之间的关联关系发送到控制面。
在一种可能的实现方式中，确定单元802在确定与请求标签匹配的目标环境时具体用于：
确定当前服务的部署信息，当前服务是指流量请求当前访问的服务；
基于当前服务的部署信息，确定当前服务是否为入口服务；
其中，在当前服务为入口服务的情况下，执行确定所述至少一个约束规则中与所述请求标签匹配的目标约束规则的步骤。
在一种可能的实现方式中，所述目标服务存在已完成测试的服务版本；确定单元802还用于执行以下操作：
在确定当前服务不是入口服务，从流量请求中获取环境描述信息；环境描述信息是在确定出与流量请求中的请求标签匹配的环境后添加的；
根据从流量请求中获取的环境描述信息，对流量请求进行路由。
在一种可能的实现方式中，确定单元802在根据从流量请求中获取的环境描述信息，对流量请求进行路由时具体用于：
若从流量请求中获取到环境描述信息，则将获取到的环境描述信息指示的环境作为目标环境，并将在目标环境中部署的针对目标服务的测试版本作为目标测试版本，以在目标环境中访问目标测试版本下的目标服务；
若从流量请求中获取环境描述信息失败，则确定目标服务不存在待测试版本，或存在的任一待测试版本均未被部署到目标环境，并访问已完成测试的服务版本下的目标服务。
在一种可能的实现方式中，请求标签包括：至少一个标签名、标签名对应的标签值，以及标签名和标签值之间的逻辑关系；与请求标签匹配包括：与至少一个标签名、标签名对应的标签值、以及逻辑关系均匹配。在一种可能的实现方式中，一个待测试版本被部署到一个环境中，且待测试版本下的目标服务的部署信息包括：待测试版本被部署到的环境对应的环境标识；处理单元803确定待测试版本中被部署到目标环境的目标测试版本时具体用于：
基于待测试版本下的目标服务的部署信息，确定与目标环境对应的环境标识匹配的目标部署信息；
将目标部署信息对应的待测试版本，作为目标测试版本。
在一种可能的实现方式中，所述目标服务存在已完成测试的服务版本；在目标服务存在的任一待测试版本，均被部署到目标环境之外的其他环境的情况下，处理单元803访问已完成测试的服务版本下的目标服务；在目标服务存在的任一待测试版本，均未被部署到任何环 境的情况下，处理单元803访问待测试版本下的目标服务。
在获取针对目标服务的流量请求之后，确定与流量请求携带的请求标签匹配的目标环境；并且，基于目标服务的部署信息，确定目标服务存在的待测试版本中，被部署到目标环境中的目标测试版本，以在目标环境中访问目标测试版本下的目标服务。本申请实施例通过将目标服务存在的待测试版本部署到不同的环境中，由不同环境相互隔离，实现了不同待测试版本之间的隔离和互不干扰，能够灵活地适应各种复杂且繁琐的、针对服务的不同待测试版本下的灰度发布场景，有效避免了灰度测试时对服务的配置，提升了灰度测试的效率。另外，本申请实施例还可以基于请求标签统一管理流量请求，并可以将流量请求灵活路由到不同的环境，以此进一步提升灰度测试时的效率。
请参见图9，图9是本申请实施例提供的一种计算机设备的结构示意图，该计算机设备900用于执行图2、图4和图7对应的方法实施例中计算机设备所执行的步骤，该计算机设备900包括：一个或多个处理器910；一个或多个输入设备920，一个或多个输出设备930和存储器940。上述处理器910、输入设备920、输出设备930和存储器940通过总线950连接。存储器940用于存储计算机程序，所述计算机程序包括程序指令，处理器910用于调用存储器940存储的程序指令，执行前文图2～图7所对应实施例中对信息处理方法。
应当理解，本申请实施例中所描述的计算机设备可执行前文图2～图7所对应实施例中对信息处理方法的描述，也可执行前文图8所对应实施例中对信息处理装置800的描述，在此不再赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。
此外，这里需要指出的是：本申请实施例还提供了一种计算机存储介质，且计算机存储介质中存储有前文提及的信息处理装置800所执行的计算机程序，且该计算机程序包括程序指令，当处理器执行上述程序指令时，能够执行前文图2、图4和图7所对应实施例中的方法，因此，这里将不再进行赘述。对于本申请所涉及的计算机存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。作为示例，程序指令可以被部署在一个计算机设备上，或者在位于一个地点的多个计算机设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算机设备上执行，分布在多个地点且通过通信网络互连的多个计算机设备可以组成区块链系统。
根据本申请的一个方面，提供了一种计算机程序产品或计算机程序，该计算机程序产品或计算机程序包括计算机指令，该计算机指令存储在计算机可读存储介质中。计算机设备的处理器从计算机可读存储介质读取该计算机指令，处理器执行该计算机指令，使得该计算机设备可以执行前文图2、图4和图7所对应实施例中的方法，因此，这里将不再进行赘述。
本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(Random Access Memory，RAM)等。
以上所揭露的仅为本申请可选实施例而已，当然不能以此来限定本申请之权利范围，因此依本申请权利要求所作的等同变化，仍属本申请所涵盖的范围。

Claims (11)

  1. 一种信息处理方法，由计算机设备执行，所述方法包括：
    获取针对目标服务的流量请求，所述流量请求包括请求标签；
    确定与所述请求标签匹配的目标环境；
    获取所述目标服务的部署信息，所述目标服务的部署信息用于指示下述信息：所述目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；
    根据所述目标服务的部署信息，在所述目标服务存在所述待测试版本的情况下，确定所述待测试版本中被部署到所述目标环境的目标测试版本；
    在所述目标环境中，访问所述目标测试版本下的所述目标服务。
  2. 根据权利要求1所述的方法，其中，所述确定与所述请求标签匹配的目标环境，包括：
    获取约束规则集，所述约束规则集包括至少一个约束规则，每个所述约束规则与一个环境相关联；
    确定所述至少一个约束规则中与所述请求标签匹配的目标约束规则；
    将所述目标约束规则关联的环境，作为所述目标环境。
  3. 根据权利要求2所述的方法，其中，所述确定所述至少一个约束规则中与所述请求标签匹配的目标约束规则之前，还包括：
    确定当前服务的部署信息，所述当前服务是指所述流量请求当前访问的服务；
    基于所述当前服务的部署信息，确定所述当前服务是否为入口服务；
    其中，在所述当前服务为所述入口服务的情况下，执行确定所述至少一个约束规则中与所述请求标签匹配的目标约束规则的步骤。
  4. 根据权利要求3所述的方法，其中，所述目标服务存在已完成测试的服务版本；所述方法还包括：
    在所述当前服务不是所述入口服务的情况下，从所述流量请求中获取环境描述信息；
    在获取到所述环境描述信息的情况下，将所述环境描述信息指示的环境，作为所述目标环境；
    在未获取到所述环境描述信息的情况下，访问所述已完成测试的服务版本下的所述目标服务。
  5. 根据权利要求2所述的方法，其中，所述请求标签包括：至少一个标签名、所述标签名对应的标签值，以及所述标签名和所述标签值之间的逻辑关系；
    所述与所述请求标签匹配包括：与所述至少一个标签名、所述标签名对应的标签值、以及所述逻辑关系均匹配。
  6. 根据权利要求2所述的方法，其中，所述方法还包括：
    显示规则配置界面；
    基于在所述规则配置界面输入的配置参数，生成所述约束规则；
    显示规则发布界面；
    基于在所述规则发布界面输入的环境标识，将所述约束规则与所述环境标识指示的环境相关联。
  7. 根据权利要求1所述的方法，其中，一个所述待测试版本被部署到一个环境中，所述待测试版本下的所述目标服务的部署信息包括：所述待测试版本被部署到的环境对应的环境标识；
    所述确定所述待测试版本中被部署到所述目标环境的目标测试版本，包括：
    基于所述待测试版本下的所述目标服务的部署信息，确定与所述目标环境对应的环境标识匹配的目标部署信息；
    将所述目标部署信息对应的所述待测试版本，作为所述目标测试版本。
  8. 根据权利要求1所述的方法，其中，所述目标服务存在已完成测试的服务版本；所述方法还包括：
    在所述目标服务存在的任一所述待测试版本，均被部署到所述目标环境之外的其他环境的情况下，访问所述已完成测试的服务版本下的所述目标服务；
    在所述目标服务存在的任一所述待测试版本，均未被部署到任何环境的情况下，访问所述待测试版本下的所述目标服务。
  9. 一种信息处理装置，所述装置包括：
    获取单元，用于获取针对目标服务的流量请求，所述流量请求包括请求标签；
    确定单元，用于确定与所述请求标签匹配的目标环境；
    所述获取单元，还用于获取所述目标服务的部署信息，所述目标服务的部署信息用于指示下述信息：所述目标服务是否存在待测试版本、各待测试版本是否已被部署到相应的环境、以及被部署到相应环境后对应的环境标识；
    处理单元，用于根据所述目标服务的部署信息，在所述目标服务存在所述待测试版本的情况下，确定所述待测试版本中被部署到所述目标环境的目标测试版本，并在所述目标环境中，访问所述目标测试版本下的所述目标服务。
  10. 一种计算机设备，包括：
    处理器，适于执行计算机程序；
    计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被所述处理器执行时，实现如权利要求1～8任一项所述的信息处理方法。
  11. 一种计算机可读存储介质，所述计算机可读存储介质存储有计算机程序，所述计算机程序适于由处理器加载并执行如权利要求1～8任一项所述的信息处理方法。
PCT/CN2021/109359 2021-06-24 2021-07-29 信息处理方法、装置、计算机设备及存储介质 WO2022267175A1 (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/127,478 US20230236954A1 (en) 2021-06-24 2023-03-28 Information processing method and apparatus, computer device, and storage medium

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202110715643.4A CN115525533A (zh) 2021-06-24 2021-06-24 信息处理方法、装置、计算机设备及存储介质
CN202110715643.4 2021-06-24

Related Child Applications (1)

Application Number Title Priority Date Filing Date
US18/127,478 Continuation US20230236954A1 (en) 2021-06-24 2023-03-28 Information processing method and apparatus, computer device, and storage medium

Publications (1)

Publication Number Publication Date
WO2022267175A1 true WO2022267175A1 (zh) 2022-12-29

Family

ID=84543926

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/109359 WO2022267175A1 (zh) 2021-06-24 2021-07-29 信息处理方法、装置、计算机设备及存储介质

Country Status (3)

Country Link
US (1) US20230236954A1 (zh)
CN (1) CN115525533A (zh)
WO (1) WO2022267175A1 (zh)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115914395B (zh) * 2023-01-30 2023-05-23 禾多科技（北京）有限公司 微服务开发方法、装置、设备及介质
CN116893977B (zh) * 2023-09-08 2024-01-16 中国空气动力研究与发展中心计算空气动力研究所 分布式仿真测试环境自动部署方法、装置、设备及介质
CN117149264B (zh) * 2023-10-31 2024-01-30 山东浪潮科学研究院有限公司 一种多泳道研发环境构建方法、装置、设备及存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103095743A (zh) * 2011-10-28 2013-05-08 阿里巴巴集团控股有限公司 一种灰度发布的处理方法及系统
CN110399142A (zh) * 2019-07-26 2019-11-01 四川新网银行股份有限公司 一种灰度与生产环境版本隔离的方法及系统
US10791044B1 (en) * 2019-03-29 2020-09-29 Oracle International Corporation Methods, system, and computer readable media for handling multiple versions of same service provided by producer network functions (NFs)
CN112214224A (zh) * 2020-07-31 2021-01-12 银盛支付服务股份有限公司 一种dubbo应用级全链路灰度发布方法及系统

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN103095743A (zh) * 2011-10-28 2013-05-08 阿里巴巴集团控股有限公司 一种灰度发布的处理方法及系统
US10791044B1 (en) * 2019-03-29 2020-09-29 Oracle International Corporation Methods, system, and computer readable media for handling multiple versions of same service provided by producer network functions (NFs)
CN110399142A (zh) * 2019-07-26 2019-11-01 四川新网银行股份有限公司 一种灰度与生产环境版本隔离的方法及系统
CN112214224A (zh) * 2020-07-31 2021-01-12 银盛支付服务股份有限公司 一种dubbo应用级全链路灰度发布方法及系统

Also Published As

Publication number Publication date
US20230236954A1 (en) 2023-07-27
CN115525533A (zh) 2022-12-27

Similar Documents

Publication Publication Date Title
WO2022267175A1 (zh) 信息处理方法、装置、计算机设备及存储介质
US10776104B2 (en) Systems and methods for tracking configuration file changes
JP5288334B2 (ja) 仮想アプライアンス配備システム
US9110884B2 (en) Message publishing and subscribing method and apparatus
US11159390B2 (en) Systems and methods for service-aware mapping of a system infrastructure
CN107800565B (zh) 巡检方法、装置、系统、计算机设备和存储介质
US10171294B2 (en) Information processing device and system design support method
JP2008294717A (ja) 仮想ネットワーク構成方法及びネットワークシステム
CN107707557B (zh) 匿名访问方法、装置、网络设备及可读存储介质
CN111258627A (zh) 一种接口文档生成方法和装置
CN110809048B (zh) 一种数据中转方法、装置和计算机可读存储介质
KR20160061306A (ko) 펌웨어 가상화를 위한 방법 및 장치
CN113709810A (zh) 一种网络服务质量的配置方法、设备和介质
CN112667601A (zh) 区块链标识的管理方法、终端设备及计算机可读存储介质
CN114650223B (zh) 一种Kubernetes集群的网络配置方法、装置及电子设备
CN104320347A (zh) 一种主动更新lldp的方法及设备
CN114401319B (zh) 一种请求处理方法、装置、服务器及存储介质
JPWO2014167790A1 (ja) 情報処理装置、及び、配備方法
US9686149B2 (en) Information processing system, relay device, and information processing method
Zhang et al. An optimal container update method for edge‐cloud collaboration
CN113342456A (zh) 一种连接方法、装置、设备和存储介质
US20220078158A1 (en) Processing system and processing method
CN115277641A (zh) 地址共享方法及装置、电子设备、存储介质
CN110891239B (zh) Pnf配置及pnfd tosca实现方法和装置
CN114760199B (zh) 基于sdn的网络配置信息下发方法、系统和存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21946662

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 14/02/2024)