Gray release method and gray release system

Abstract

The embodiment of the invention provides a gray release method and a gray release system, and belongs to the technical field of network operation and maintenance. The gray release method applied to client equipment comprises the following steps: generating a first initial data acquisition request for target software of a gray version initiated to server equipment; marking the first initial data acquisition request by using a request identifier corresponding to the client device to obtain a first target data acquisition request; the first target data acquisition request is sent to server equipment, so that the server equipment sends the first target data acquisition request to a first service instance, and a release object identifier set corresponding to the first service instance comprises a request identifier carried by the first target data acquisition request; the first service instance is used for operating the target software of the gray version. In this way, accurate distribution of the data traffic in the gray release process is realized.

Description

Technical Field

[0001] This application relates to the field of network operation and maintenance, and particularly to a gray release method and a gray release system. Background Art

[0002] Currently, traditional gray release methods usually rely on complex configurations on the server side. For example, a part of the data traffic is allocated to the service instances of the new version through a random algorithm. Although this method can achieve the coexistence of the old and new versions, due to the lack of pertinence and precise control of traffic allocation, it may cause the same user to experience different versions of the service in a short period of time, affecting the continuity of use. If there are serious problems in the new version, it may also have a negative impact on a large number of users who are not the release targets. Therefore, the existing gray release methods have the risk of affecting the user experience due to inaccurate data traffic allocation. Summary of the Invention

[0003] The main purpose of the embodiments of this application is to propose a gray release method and a gray release system, aiming to achieve precise allocation of data traffic during the gray release process.

[0004] To achieve the above purpose, the first aspect of the embodiments of this application proposes a gray release method, which is applied to a client device. The method includes:

[0005] Generating a first initial data acquisition request for the target software of the gray version sent to the server device, where the server device includes multiple service instances, and the multiple service instances are used to run multiple versions of the target software, and the multiple versions include the gray version;

[0006] Marking the first initial data acquisition request with the request identifier corresponding to the client device to obtain a first target data acquisition request;

[0007] Sending the first target data acquisition request to the server device, so that the server device sends the first target data acquisition request to the first service instance; the set of release object identifiers corresponding to the first service instance includes the request identifier carried by the first target data acquisition request, and the first service instance is used to run the target software of the gray version.

[0008] In some embodiments, after sending the first target data acquisition request to the server device, the method further includes:

[0009] Determining the running state of the target software of the gray version according to the response status of the first service instance to the first target data acquisition request.

[0010] In some embodiments, marking the first initial data acquisition request with the request identifier corresponding to the client device to obtain a first target data acquisition request includes:

[0011] Generating the request identifier according to the data information obtained from the first initial data acquisition request, where the data information includes at least one of the following: the device type of the client device, the user identifier operating the client device, the device location of the client device, and the target access version;

[0012] Marking the first initial data acquisition request with the request identifier.

[0013] In some embodiments, marking the first initial data acquisition request with the request identifier includes:

[0014] Generating an identification field with the request identifier and adding the identification field to the first initial data acquisition request.

[0015] In some embodiments, the method further includes:

[0016] Generating a second initial data acquisition request for the target software of the non - grayscale version to be sent to the server device;

[0017] Marking the second initial data acquisition request with the request identifier corresponding to the client device to obtain a second target data acquisition request;

[0018] Sending the second target data acquisition request to the server device, so that the server device sends the second target data acquisition request to a second service instance; the set of release object identifiers corresponding to the second service instance includes the request identifier carried by the second target data acquisition request, and the second service instance is used to run the target software of the non - grayscale version;

[0019] Receiving the interaction data sent by the server device, where the interaction data is the data generated by the second service instance in response to the second target data acquisition request.

[0020] To achieve the above object, a second aspect of the embodiments of the present application proposes a gray - scale release method applied to a server device. The server device includes a plurality of service instances, and the plurality of service instances are used to run multiple versions of the target software, and the multiple versions include a gray - scale version. The method includes:

[0021] Receive a first target data acquisition request sent by a client device, where the first target data acquisition request is obtained by the client device marking a first initial data acquisition request with a request identifier corresponding to the client device, and the first initial data acquisition request is generated by the client device for the target software of the grayscale version;

[0022] Determine that the request identifier carried in the first target data acquisition request exists in the set of published object identifiers corresponding to a first service instance, where the first service instance is a service instance running the target software of the grayscale version;

[0023] Send the first target data acquisition request to the first service instance.

[0024] In some embodiments, after sending the first target data acquisition request to the first service instance, the method further includes:

[0025] Process the first target data acquisition request through the first service instance, so that the client device determines the running state of the target software of the grayscale version according to the response status of the first service instance to the first target data acquisition request.

[0026] In some embodiments, the method further includes:

[0027] Receive a second target data acquisition request sent by a client device, where the second target data acquisition request is obtained by the client device marking a second initial data acquisition request with a request identifier corresponding to the client device, and the second initial data acquisition request is generated by the client device for the target software of the non - grayscale version;

[0028] Determine that the request identifier carried in the second target data acquisition request exists in the set of published object identifiers corresponding to a second service instance, where the second service instance is a service instance running the target software of the non - grayscale version;

[0029] Send the second target data acquisition request to the second service instance;

[0030] Send interaction data to the client device, where the interaction data is data generated by the second service instance in response to the second target data acquisition request

[0031] To achieve the above object, a third aspect of the embodiments of the present application proposes a grayscale release system, where the system includes a client device and a server device, the server device includes a plurality of service instances, and the plurality of service instances are used to run a plurality of versions of the target software, and the plurality of versions include the grayscale version;

[0032] The client device is used to generate a first initial data acquisition request for the target software of the gray-scale version initiated to the server device, mark the first initial data acquisition request with the request identifier corresponding to the client device to obtain a first target data acquisition request, and send the first target data acquisition request to the server device;

[0033] The server device is used to receive the first target data acquisition request, and after determining that the request identifier carried by the first target data acquisition request exists in the set of release object identifiers corresponding to the first service instance, send the first target data acquisition request to the first service instance, where the first service instance is the service instance running the target software of the gray-scale version.

[0034] In some embodiments, the server device is further used to process the first target data acquisition request through the first service instance;

[0035] The client device is further used to determine the running state of the target software of the gray-scale version according to the response status of the first service instance to the first target data acquisition request.

[0036] The gray-scale release method and gray-scale release system proposed in this application achieve precise allocation of data traffic during the gray-scale release process. The client device generates a first initial data acquisition request and marks the first initial data acquisition request with a request identifier, so that the first initial data acquisition request carries a clear identifier and becomes a first target data acquisition request. After receiving the first target data acquisition request, the server device can determine whether the first target data acquisition request comes from the target release object of the gray-scale version by determining whether the request identifier it carries exists in the set of release object identifiers corresponding to the first service instance (i.e., the gray-scale service instance running the target software of the gray-scale version). When the server device determines that the request identifier carried by the first target data acquisition request exists in the set of release object identifiers corresponding to the first service instance, it sends the first target data acquisition request to the first service instance, ensuring that the data traffic (i.e., the first target data acquisition request) for the target software of the gray-scale version can be accurately distributed to the corresponding gray-scale service instance - the first service instance.

[0037] In this way, the server device can determine whether a request comes from the target release object of the gray release based on the request identifier previously marked by the client device for the data acquisition request, so as to achieve accurate distribution of data traffic during the gray release process. This is more accurate and controllable compared to the existing gray release methods that use random sampling or proportional traffic allocation, enabling targeted gray release, effectively reducing the risk of affecting the user experience due to inaccurate data traffic allocation, and ensuring the stability and reliability of the system composed of the server device and the client device. Description of the Drawings

[0038] Figure 1 is a schematic flowchart of the gray release method applied to the client device provided by an embodiment of the present application;

[0039] Figure 2 is a schematic interaction flowchart of the gray release method provided by an embodiment of the present application;

[0040] Figure 3 is a schematic flowchart of the gray release method applied to the server device provided by an embodiment of the present application;

[0041] Figure 4 is a schematic structural diagram of the gray release system provided by an embodiment of the present application;

[0042] Figure 5 is a schematic structural diagram of the gray release device applied to the client device provided by an embodiment of the present application;

[0043] Figure 6 is a schematic structural diagram of the gray release device applied to the server device provided by an embodiment of the present application;

[0044] Figure 7 is a schematic hardware structure diagram of the electronic device provided by an embodiment of the present application. Detailed Embodiments

[0045] In order to make the objectives, technical solutions, and advantages of the present application clearer, the present application will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain the present application and are not used to limit the present application.

[0046] It should be noted that although functional module division is performed in the device schematic diagram and the logical order is shown in the flowchart, in some cases, the steps shown or described can be executed in a different order from the module division in the device or the order in the flowchart. Terms such as "first" and "second" in the description, claims, and the above-mentioned drawings are used to distinguish similar objects and do not necessarily need to describe a specific order or sequence.

[0047] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those of ordinary skill in the technical field to which this application belongs. The terms used herein are for the purpose of describing embodiments of this application only and are not intended to limit this application.

[0048] First, several nouns involved in this application are analyzed as follows:

[0049] Grey Release: Grey Release is a software release strategy. Its purpose is to gradually open a new version of a function to users in a phased and partial-traffic manner when the new version function goes live, so as to verify and test the stability and performance of the new version within a limited range. Grey Release divides users into different groups to access the old and new versions respectively, ensuring that the new function is only open to a part of users and avoiding potential problems of the new version from affecting all users.

[0050] Currently, traditional grey release methods usually rely on complex configurations on the server side. For example, a part of the data traffic is allocated to the service instances of the new version through a random algorithm. Although this method can achieve the coexistence of the old and new versions, due to the lack of pertinence and precise control of traffic allocation, it may cause the same user to experience different versions of the service in a short period of time, affecting the usage coherence. If there are serious problems in the new version, it may also have a negative impact on a large number of users who are not the release targets. Therefore, the existing grey release methods have the risk of affecting user experience due to inaccurate data traffic allocation.

[0051] Based on this, the embodiments of this application provide a grey release method and a grey release system, aiming to achieve precise allocation of data traffic during the grey release process.

[0052] The grey release method and grey release system provided by the embodiments of this application are specifically described through the following embodiments. First, the grey release method in the embodiments of this application is described.

[0053] The embodiments of this application can obtain and process relevant data based on artificial intelligence technology. Among them, Artificial Intelligence (AI) is a theory, method, technology, and application system that uses digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use knowledge to obtain the best results.

[0054] The basic technologies of artificial intelligence generally include technologies such as sensors, dedicated artificial intelligence chips, cloud computing, distributed storage, big data processing technology, operation / interaction systems, and mechatronics. The software technologies of artificial intelligence mainly include several major directions such as computer vision technology, robotics technology, biometric technology, speech processing technology, natural language processing technology, and machine learning / deep learning.

[0055] The present application can be used in numerous general-purpose or special-purpose computer system environments or configurations. For example: personal computers, server computers, handheld or portable devices, tablet devices, multi-processor systems, microprocessor-based systems, set-top boxes, programmable consumer electronic devices, network PCs, minicomputers, mainframe computers, distributed computing environments including any of the above systems or devices, and so on. The present application can be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. The present application can also be practiced in a distributed computing environment where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules can be located in local and remote computer storage media including storage devices.

[0056] It should be noted that in each specific embodiment of the present application, when it comes to relevant processing based on data related to the user's identity or characteristics, such as user information, user behavior data, user historical data, and user location information, the user's permission or consent will be obtained first. Moreover, the collection, use, and processing of these data will comply with relevant laws, regulations, and standards. In addition, when the embodiments of the present application need to obtain the user's sensitive personal information, the user's separate permission or separate consent will be obtained through methods such as pop-up windows or redirecting to a confirmation page. After clearly obtaining the user's separate permission or separate consent, the necessary user-related data for the normal operation of the embodiments of the present application will be obtained.

[0057] Figure 1 It is a schematic flow chart of the gray release method applied to a client device provided by an embodiment of the present application. As Figure 1 shown, in the first aspect of the embodiment of the present application, a gray release method applied to a client device is provided, including steps S110 - S130.

[0058] Step S110: Generate a first initial data acquisition request for the target software of the gray version sent to the server device, where the server device includes multiple service instances, and the multiple service instances are used to run multiple versions of the target software, and the multiple versions include the gray version.

[0059] First, the client device generates a first initial data acquisition request for the target software in the grayscale version, which is to be sent to the server device. The client device initiates this first initial data acquisition request to obtain the interactive data of the response of the target software. The first initial data acquisition request is intended to access the service instance running the target software in the grayscale version, that is, the first service instance. The server device includes multiple service instances, which are used to run different versions of software, including the grayscale version and the official version (non-grayscale version).

[0060] Those skilled in the art can understand that the number of server devices can be multiple, forming a distributed data processing system, and the number of grayscale versions can also be multiple, that is, there are multiple grayscale versions to be released.

[0061] Optionally, each service instance among the multiple service instances is respectively used to run the target software of each version among the multiple versions. That is to say, there is a one-to-one correspondence between different service instances and different versions of the target software.

[0062] Specifically, the first initial data acquisition request is initiated by the user on the client device.

[0063] Exemplarily, an e-commerce platform is testing a grayscale version of a recommendation system. When the user opens the recommendation system on the client browser and performs operations, the client device generates a first initial data acquisition request, aiming to request relevant data of the grayscale version recommendation system, such as a product recommendation list.

[0064] Step S120: Mark the first initial data acquisition request with the request identifier corresponding to the client device to obtain a first target data acquisition request.

[0065] In this step, the client device marks the first initial data acquisition request with the request identifier corresponding to the client device to obtain a first target data acquisition request. The client device adds specific marking information, that is, the request identifier, to the first initial acquisition request. These marks can include at least one of the following: user identifier (i.e., user ID), target access version, device information, and geographical location, etc., which are used to indicate that the first target data acquisition request should be routed to the service instance (the first service instance) running the grayscale version. Specifically, the user identifier is used to uniquely represent the user who initiates the first initial data acquisition request, the target access version represents the version type or version number (grayscale version or non-grayscale version) that the client device hopes to access, the device information represents the device type (such as a mobile phone or a tablet computer) or device parameters of the client device, and the geographical location represents the geographical area where the client device is located. In this way, the data acquisition request marked by the client device, that is, the first target data acquisition request, can be recognized by the server device as a data acquisition request from the object of the grayscale version release.

[0066] Optionally, the gray release method provided in this embodiment can be implemented through the browser installed on the client device or through a plugin installed in the browser of the client device.

[0067] Exemplarily, a plugin for gray release management is installed in the browser of the client device. The browser plugin intercepts the first initial data acquisition request generated by the client device and adds a marker field, i.e., a request identifier, to the request header Header of the first initial data acquisition request. For example: env:grey (indicating the target access version is the gray version), usercode:12345 (indicating the user identifier of the user with user ID 12345), region:CN (indicating the geographical location where the client device is located is China). The browser plugin can determine or select the request identifier to be marked according to the instruction input by the user. These request identifiers together mark that the first initial data acquisition request is a request for the release object from the gray version.

[0068] Those skilled in the art can understand that the first initial data acquisition request is a data acquisition request for the target software of the gray version, and the defining subject of this definition can be at least one of the client device and the server device. For example, the user of the client device is a tester of the gray version, and the goal of this tester is to access the service instance of the gray version. The tester uses the above browser plugin to set the target access version as the gray version. In this way, the first initial data acquisition request is defined by the plugin as a data acquisition request for the target software of the gray version through the request identifier, that is, it is defined by the client device as a data acquisition request for the target software of the gray version;

[0069] Or, the user of the client device is not a tester, but only an ordinary user who needs to access the server device. After the above browser plugin intercepts the first initial data acquisition request, it automatically adds a request identifier to the first initial data acquisition request using the user ID and device information, and the request identifier corresponding to the user ID and device information exists in the release object identifier set corresponding to the service instance running the gray version. In this way, the first initial data acquisition request is defined by the server device as a data acquisition request for the target software of the gray version.

[0070] Step S130: Send the first target data acquisition request to the server device, so that the server device sends the first target data acquisition request to the first service instance; the release object identifier set corresponding to the first service instance includes the request identifier carried by the first target data acquisition request, and the first service instance is used to run the target software of the gray version.

[0071] The client device sends a first target data acquisition request to the server device. The first target data acquisition request is a data acquisition request for the target software of the grayscale version, and the request identifier carried therein exists in the set of release object identifiers corresponding to the service instance (i.e., the first service instance) running the target software of the grayscale version. After the server device confirms that its request identifier exists in the set of release object identifiers corresponding to the first service instance, it sends the first target data acquisition request to the first service instance. In other words, after receiving the first target data acquisition request with the request identifier, the server device determines whether the request comes from the target object of the grayscale release based on the request identifier (such as env:grey and usercode:12345). If the request identifier matches the preset grayscale release rule (existing in the set of release object identifiers corresponding to the first service instance), the server device will route the first target data acquisition request to the service instance running the grayscale version. It can be seen that technicians can flexibly set the grayscale release rule on the server device to achieve flexible changes to the grayscale release object.

[0072] Specifically, the set of release object identifiers may include identification fields of a group of specific identifiers, and these specific identifiers may include user identifiers (such as specific user IDs), device type identifiers (such as specific device types), target access version identifiers (such as the target access version being the grayscale version), etc. Those skilled in the art can understand that the specific identifiers in the set of release object identifiers can be a single type of identifier (such as a single user identifier) or a combination of multiple identifiers (such as a combination of a user identifier and a device type identifier).

[0073] When the server device receives a data acquisition request from the client device, it can extract the identification fields of the request identifier from the data acquisition request and match them with the identification fields in the set of release object identifiers. If the identification fields of the request identifier of a certain data acquisition request can be matched with a certain identification field in a certain set of release object identifiers (i.e., the identification fields of the request identifier carried by the data acquisition request exist in the set of release object identifiers), then the data acquisition request will be routed by the server device to the service instance associated with the set of release object identifiers. For example, for grayscale release, the set of release object identifiers of the first service instance running the grayscale version contains identification fields representing certain user IDs and device types. The identification fields of the request identifier carried by the first target data acquisition request can be matched with the identification fields in the set of release object identifiers of the first service instance. After the server device completes the matching verification process, it routes the first target data acquisition request to the first service instance.

[0074] Exemplarily, the server device uses the ALB (Application Load Balancer) belonging to the server device to resolve the request identifier in the first target data acquisition request. The ALB is a logical layer located at the entry position of the server device traffic and directly receives external traffic. In the preset canary release rule in the ALB, it is defined that env:grey belongs to the set of release object identifiers corresponding to the first service instance. If the request identifier contains env:grey, the ALB is used to route the request to the first service instance.

[0075] Through the above steps S110 - S130, the precise allocation of data traffic in the canary release process is achieved. The client device generates the first initial data acquisition request and marks the first initial data acquisition request with the request identifier, making the first initial data acquisition request carry a clear identifier and become the first target data acquisition request. After receiving the first target data acquisition request, the server device can determine whether the first target data acquisition request comes from the target release object of the canary version by determining whether the request identifier carried by it exists in the set of release object identifiers corresponding to the first service instance (i.e., the canary service instance running the canary version of the target software). When the server device determines that the request identifier carried by the first target data acquisition request exists in the set of release object identifiers corresponding to the first service instance, it sends the first target data acquisition request to the first service instance, ensuring that the data traffic (i.e., the first target data acquisition request) for the canary version of the target software can be precisely distributed to the corresponding canary service instance - namely, the first service instance.

[0076] In this way, the server device can determine whether the request comes from the target release object of the canary release based on the request identifier pre - marked by the client device for the data acquisition request, thereby achieving the precise allocation of data traffic in the canary release process. Compared with the existing canary release methods that use random sampling or proportional traffic allocation, it is more accurate and controllable, enabling targeted canary release, effectively reducing the risk of affecting the user experience due to non - precise data traffic allocation, and ensuring the stability and reliability of the system composed of the server device and the client device.

[0077] In some embodiments, after sending the first target data acquisition request to the server device, the method further includes:

[0078] Determine the running state of the canary version of the target software according to the response status of the first service instance to the first target data acquisition request.

[0079] In this embodiment, the client device finally determines the running state of the target software gray version according to the response status of the first service instance to the first target data acquisition request. For example, the client device receives response data from the first service instance in the server device and judges the running state of the target software of the gray version by analyzing the content and performance indicators of the response data, such as whether the expected data is correctly returned, whether the performance meets the standard, or directly judges the running state of the target software of the gray version according to whether the response data is received. If a problem occurs during operation, the client device can record the error and give feedback; if the operation is normal, the client device can notify the server device to continue expanding the test scope or proceed to the next release.

[0080] Exemplarily, the client device receives response data from the target software of the gray version (such as the gray version of the recommendation system of an e-commerce platform) in the first service instance. The client device can automatically verify the data or directly present the data to the user and determine the verification result according to the user's input (such as: confirm whether the response time is within the specified range, confirm whether the returned data format conforms to the expected structure). If the verification result shows that the running state is normal, the client device will report to the server device or the management background that the gray version is running normally; if a problem is found, the problem log will be recorded and submitted to the developer issue tracking system or the server device.

[0081] In some embodiments, marking the first initial data acquisition request with the request identifier corresponding to the client device to obtain the first target data acquisition request includes:

[0082] Generating a request identifier according to the data information obtained from the first initial data acquisition request, where the data information includes at least one of the following: the device type of the client device, the user identifier operating the client device, the device location of the client device, and the target access version;

[0083] Marking the first initial data acquisition request with the request identifier.

[0084] In this embodiment, the client device marks the first initial data acquisition request by generating a request identifier, so that the server device can more accurately identify and distribute the requests of the client device. When generating the request identifier, the client device is based on the acquired data information, including at least one of the following: the device type of the client device (such as a mobile phone or a computer), the user identifier of the current user operating the client device (such as a user ID), the device location (such as a geographical location), and the target access version (such as a formal version or a gray version). These data information are used to generate the request identifier. Subsequently, the generated request identifier is used to mark the first initial data acquisition request, thereby converting it into a first target data acquisition request carrying the request identifier. In this way, the server device can parse and extract the request identifier from the first target data acquisition request, including the device type, user identifier, device location, and target access version, etc. According to the extracted request identifier, the server device matches it with the set of release object identifiers of the first service instance to determine whether the request belongs to the target user group for gray release. After successful matching, the server device accurately routes the first target data acquisition request to the first service instance running the gray version according to the preset routing rules. Through this accurate routing mechanism based on the request identifier, the server device can ensure that the gray release only affects the user group specified in the preset gray release rules, and the remaining users continue to use the formal version service, thus effectively isolating the potential problems that may occur in the gray service and ensuring the accuracy and stability of the gray release.

[0085] Exemplarily, a certain video streaming media platform is testing the content recommendation function of the gray version. The browser of the client device automatically installs a browser plugin for gray management after entering the streaming media platform interface. When the user opens the plugin, the plugin collects the following information: the user accesses the platform through an Android mobile phone, the user's unique account ID is user12345, and the user is located in Beijing. The plugin also collects the information that the user's target access version is the gray version through the user's selection instruction on the plugin.

[0086] Based on this information, the plugin generates a request identifier, for example: device:android; user:user12345; region:Beijing; env:grey. This request identifier is attached to the request header of the first initial data acquisition request, converting the original first initial data acquisition request into a first target data acquisition request. The server device accurately identifies that the request comes from user12345 on the Android device by parsing the tag information in these request identifiers and routes it to the service instance running the gray version recommendation system. Finally, the user obtains personalized content recommended by the gray version, and at the same time, the server device records the user's interaction data to evaluate the performance of the gray version and user feedback.

[0087] In some embodiments, marking the first initial data acquisition request with a request identifier includes:

[0088] Generating an identifier field using the request identifier and adding the identifier field to the first initial data acquisition request.

[0089] In this embodiment, the gray release method completes the marking by generating an identifier field of the request identifier and attaching it to the first initial data acquisition request. Specifically, the client device generates an identifier field using the request identifier. The identifier field can be a data string or key-value pair that contains key information identifying the client request, such as user identity identifier, device type, target access version, etc. After generating the identifier field, it is added as an additional request header field or parameter to the first initial data acquisition request. Through this marking method, the server device can effectively distinguish the request source based on the identifier field and make corresponding processing accordingly, routing the request to a specific service instance to ensure the accuracy and reliability of the gray release.

[0090] Exemplarily, an e-commerce platform is performing a gray release on a gray version of a product recommendation system. The user's browser is installed with a gray release plugin. When the user accesses the platform, the plugin automatically generates a request identifier field, for example: userID: user5678; env: grey, where "userID: user5678" indicates that the current request comes from user 5678, and "env: grey" indicates that the target of this request is the gray version of the product recommendation system. This identifier field is added to the header of the first initial data acquisition request to obtain the first target data acquisition request. After receiving the request, the server device parses the identifier field, identifies that the request comes from user 5678 and the target access version is the gray version, and thus routes the request to the service instance running the gray version of the product recommendation system. Finally, user 5678 obtains product recommendations based on the gray version of the product recommendation system without affecting the service experience of other official version users.

[0091] In a typical implementation scenario, technicians developed a gray release support tool based on a browser plugin to dynamically add an identifier field to the data acquisition requests initiated by the client device, so that the server device can identify the data acquisition requests and accurately distribute them to the corresponding service instances.

[0092] After the user installs the plugin in the browser, the plugin will be embedded in the browser's request process to intercept each data acquisition request to be sent (i.e., the initial data acquisition request). Through the plugin's user interface, the user can set and select the information contained in the request identifier (the user can set it by entering in the plugin's form or selecting a button), such as the target access version (e.g., the official version, the gray version), the user identifier, and the device location. After setting, it will be dynamically stored as the internal state of the plugin.

[0093] When the user accesses the target application service in the browser, the plugin will intercept the data acquisition request before it is sent and read the information contained in the request identifier set by the user. For example: env: grey - the target access version is the gray version, usercode: 12345 - the current request comes from user 12345, region: NA - the client device is in North America). The plugin generates the corresponding request identifier field according to the above parameters and writes it into the request header of the data acquisition request.

[0094] After the data acquisition request with the identifier field (i.e., the target data acquisition request) is sent to the server device, the server device will read and parse the env, usercode, and region fields in the request header. Based on these fields, the server matches the preset rule set and distributes the data acquisition request to the corresponding service instance (such as the service instance running the gray version).

[0095] In some embodiments, the method further includes:

[0096] Generating a second initial data acquisition request for the target software of the non-gray version to be sent to the server device;

[0097] Marking the second initial data acquisition request with the request identifier corresponding to the client device to obtain a second target data acquisition request;

[0098] Sending the second target data acquisition request to the server device, so that the server device sends the second target data acquisition request to the second service instance; the set of release object identifiers corresponding to the second service instance includes the request identifier carried by the second target data acquisition request, and the second service instance is used to run the target software of the non-gray version;

[0099] Receiving the interaction data sent by the server device, where the interaction data is the data generated by the second service instance in response to the second target data acquisition request.

[0100] In this embodiment, the gray release method is extended to support the request processing of non-gray versions (formal versions) simultaneously. The client device generates an initial request (second initial data acquisition request) for the target software of the non-gray version to be sent to the server device. Similarly, this request also needs to be marked with the request identifier of the client device to generate a second target data acquisition request containing the request identifier. Subsequently, the client device sends the second target data acquisition request to the server device.

[0101] The second target data acquisition request is a data acquisition request for the target software of the non-gray version, and the request identifier it carries exists in the set of release object identifiers corresponding to the service instance (i.e., the second service instance) running the target software of the non-gray version. After the server device confirms that its request identifier exists in the set of release object identifiers corresponding to the second service instance, it sends the second target data acquisition request to the second service instance. In other words, the server device confirms whether the request belongs to the target users of the non-gray version by matching the request identifier with the set of release object identifiers of the second service instance. If the match is successful, the request is routed to the second service instance running the target software of the non-gray version for processing. Finally, the server device returns the interaction data, that is, the interaction data generated by the service instance running the non-gray version. In this way, it can be ensured that the requests of non-gray users are processed normally without being affected by the gray release.

[0102] Exemplarily, a certain social media platform is testing a new interface (gray version), while some users still need to access the old interface (non-gray version). When user A accesses the platform, the browser plugin generates a request identifier: userID: user1234; env: pro. This request identifier indicates that user A is a formal version user and the target access version is the non-gray version. The identifier field corresponding to the request identifier is attached to the second initial data acquisition request to form a second target data acquisition request. After receiving the request, the server device identifies that user A belongs to the target users of the formal version and routes the request to the second service instance running the old interface for processing. The second service instance generates interaction data (such as the user's message list and friend dynamics) according to the request and returns the result to user A, ensuring a consistent experience for using the old interface while being completely isolated from the release object users of the gray version.

[0103] In a typical implementation scenario, a technician can design traffic allocation rules according to actual requirements. For example, if a technician wants to allocate traffic according to device type, data acquisition requests with the device type (deviceType) included in the request identifier set on the server device being mobile devices (deviceType: mobile) can be allocated to service instances running the gray-scale version, and data acquisition requests with the device type (deviceType) included in the request identifier being host devices (deviceType: desktop) can be allocated to service instances running the non-gray-scale version. Those skilled in the art can understand that this traffic allocation rule can be implemented by setting the set of release object identifiers for each service instance.

[0104] After the user installs and enables the plug-in, the interactive interface of the plug-in displays various optional identifier types, including but not limited to: device location (region), device type (deviceType), user identifier (userID), and target access version (env). When the user accesses the target service in the browser, the plug-in automatically intercepts and adds an identifier field to each data acquisition request sent. For example, the plug-in adds an identifier field representing the device type to the request header according to the user's settings.

[0105] After the server device receives a data acquisition request, it determines from which release object of a service instance it comes based on the identifier field in the request header (determines in which set of release object identifiers of a service instance this identifier field exists), and routes it to that service instance. For example:

[0106] If deviceType is "mobile", it means that this data acquisition request comes from the release object of a service instance running the gray-scale version, and this data acquisition request is routed to the service instance running the gray-scale version;

[0107] If deviceType is "desktop", it means that this data acquisition request comes from the release object of a service instance running the non-gray-scale version, and this data acquisition request is routed to the service instance running the non-gray-scale version.

[0108] In this way, the marking of data acquisition requests by the plug-in enables the server device to determine the service instance to which a data acquisition request should be sent according to the preset traffic allocation rules, and a technician can dynamically change the traffic allocation rules according to the requirements of the actual application scenario. In this way, fine-grained traffic differentiation is achieved on the client side, which not only makes the division of the target user groups of the gray-scale version and the non-gray-scale version more accurate, but also enables the traffic allocation rules to be flexibly changed to meet the requirements of different application scenarios.

[0109] Figure 2 It is a schematic diagram of the interaction process of the gray release method provided by the embodiments of the present application. As Figure 2 shown, combining the above-mentioned multiple embodiments, the gray release method provided by the embodiments of the present application can be described as follows:

[0110] This solution proposes a gray release method based on client devices, aiming to achieve efficient management and gray verification of multi-version services by accurately marking user requests and intelligently distributing traffic. Specifically, when a client device generates an initial data acquisition request, it generates a request identifier based on information such as device type, user identifier, device location, and target access version, and uses this identifier to add an identification field to the request to form a marked target data acquisition request. After the client device sends the request to the server device, the server device uses the ALB belonging to the server device to parse the request identifier in the target data acquisition request, and the ALB then matches the request to the corresponding set of release object identifiers and routes it to the service instance running a specific target version (such as a gray version or a non-gray version) (the service instance running the gray version is S1, and the service instance running the non-gray version is S2), completing precise traffic distribution.

[0111] The client can use tools such as browser plugins to assist in generating and adjusting the request identifier, and use the browser plugin for marking and sending the target data acquisition request. When the user uses the client device to open the browser and aims to access the target software, the browser plugin intercepts the generated initial data acquisition request (q1) and marks q1 with the request identifier to obtain the target data acquisition request (q2).

[0112] The user can easily switch the target version through the plugin interface. The plugin selects the request identifier such as env: grey according to the user's operation to indicate access to the gray version, and selects the request identifier env: pro to indicate access to the official version (non-gray version), thus realizing flexible gray strategy settings. After the service instance processes the request and returns the interaction data, the client verifies the running status and user experience of the gray version based on these data and dynamically adjusts the gray release strategy. Compared with the traditional gray release method, this solution realizes precise traffic control through fine-grained marking fields, reduces the negative impact on user experience that may be caused by randomly allocating traffic, and simplifies the gray configuration through the intuitive operation of the plugin, improving the efficiency and security of the release process.

[0113] Figure 3 It is a schematic diagram of the process of the gray release method applied to the server device provided by the embodiments of the present application. As Figure 3 shown, the second aspect of the embodiments of the present application provides a gray release method applied to a server device, including steps S310 - step S330.

[0114] Step S310: Receive a first target data acquisition request sent by a client device. The first target data acquisition request is obtained by the client device marking a first initial data acquisition request with a request identifier corresponding to the client device. The first initial data acquisition request is generated by the client device for the target software of the grayscale version.

[0115] Step S320: Determine that the request identifier carried in the first target data acquisition request exists in the set of published object identifiers corresponding to the first service instance. The first service instance is the service instance running the target software of the grayscale version.

[0116] Step S330: Send the first target data acquisition request to the first service instance.

[0117] Corresponding to the above Step S110 - Step S130, the client device sends the first target data acquisition request to the server device. After receiving the first target data acquisition request, the server device, after confirming that its request identifier exists in the set of published object identifiers corresponding to the first service instance, sends the request to the first service instance (the instance running the grayscale version).

[0118] In other words, after receiving the first target data acquisition request with a request identifier, the server device determines whether the request comes from the target object of the grayscale release based on the request identifier. If the request identifier matches the preset grayscale release rule (exists in the set of published object identifiers corresponding to the first service instance), the server device will route the first target data acquisition request to the service instance running the grayscale version. Exemplarily, the server device uses the ALB belonging to the server device to parse the request identifier in the first target data acquisition request. The preset grayscale release rule in the ALB defines that env:grey belongs to the set of published object identifiers corresponding to the first service instance. If the request identifier contains env:grey, the ALB is used to route the request to the first service instance.

[0119] The technical effects achieved by the above Step S310 - Step S330 are the same as those achieved by the above Step S110 - Step S130, and will not be elaborated here.

[0120] In some embodiments, after sending the first target data acquisition request to the first service instance, the method further includes:

[0121] Process the first target data acquisition request through the first service instance, so that the client device determines the running state of the target software of the grayscale version of the target software according to the response status of the first service instance to the first target data acquisition request.

[0122] In this embodiment, the first service instance in the server device processes the first target data acquisition request. When the target software in the gray-scale version runs normally, it returns interaction data or response data to the client device. The client device receives the response data from the first service instance in the server device and determines the running state of the target software in the gray-scale version by analyzing the content and performance metrics of the response data, such as whether the expected data is correctly returned, whether the performance meets the standard, or directly determines the running state of the target software in the gray-scale version based on whether the response data is received.

[0123] In some embodiments, the method further includes:

[0124] Receiving a second target data acquisition request sent by the client device, where the second target data acquisition request is obtained by the client device marking the second initial data acquisition request with the request identifier corresponding to the client device, and the second initial data acquisition request is generated by the client device for the target software in the non-gray-scale version;

[0125] Determining that the request identifier carried in the second target data acquisition request exists in the set of published object identifiers corresponding to the second service instance, where the second service instance is the service instance running the target software in the non-gray-scale version;

[0126] Sending the second target data acquisition request to the second service instance;

[0127] Sending interaction data to the client device, where the interaction data is data generated by the second service instance in response to the second target data acquisition request.

[0128] In this embodiment, the gray-scale release method is extended to support the request processing of the non-gray-scale version at the same time. The client device sends the second target data acquisition request to the server device. After receiving the second target data acquisition request, the server device, after matching the request identifier with the set of published object identifiers of the second service instance (the service instance running the target software in the non-gray-scale version) and confirming that the second target data acquisition request comes from a non-gray-scale target user, routes the request to the second service instance running the target software in the non-gray-scale version for processing. Finally, the server device returns the interaction data, that is, the interaction data generated by the service instance running the non-gray-scale version, so as to ensure that the requests of non-gray-scale users are properly processed and not affected by the gray-scale release.

[0129] Please refer to Figure 4 , this application embodiment also provides a gray-scale release system 400. The system 400 includes a client device 401 and a server device 402. The server device 402 includes multiple service instances, and the multiple service instances are used to run multiple versions of the target software, and the multiple versions include the gray-scale version;

[0130] The client device 401 is used to generate a first initial data acquisition request for the target software of the gray-scale version initiated to the server device 402, and mark the first initial data acquisition request with the request identifier corresponding to the client device 401 to obtain a first target data acquisition request, and send the first target data acquisition request to the server device 402;

[0131] The server device 402 is used to receive the first target data acquisition request, and after determining that the request identifier carried in the first target data acquisition request exists in the set of release object identifiers corresponding to the first service instance, send the first target data acquisition request to the first service instance, where the first service instance is a service instance running the target software of the gray-scale version.

[0132] In some embodiments, the server device 402 is further used to process the first target data acquisition request through the first service instance;

[0133] The client device 401 is further used to determine the running state of the target software of the gray-scale version according to the response status of the first service instance to the first target data acquisition request.

[0134] The specific implementation manner of the gray-scale release system 400 is basically the same as the specific embodiments of the gray-scale release method provided in the first aspect and the second aspect of the embodiments of the present application, and will not be elaborated here.

[0135] Please refer to Figure 5 , the embodiments of the present application further provide a gray-scale release device 50 applied to a client device, which can implement the gray-scale release method provided in the first aspect of the embodiments of the present application. The device 50 includes:

[0136] A request generation module 51, configured to generate a first initial data acquisition request for the target software of the gray-scale version initiated to the server device, where the server device includes a plurality of service instances, and the plurality of service instances are used to run a plurality of versions of the target software, and the plurality of versions include the gray-scale version;

[0137] A marking module 52, configured to mark the first initial data acquisition request with the request identifier corresponding to the client device to obtain a first target data acquisition request;

[0138] A sending module 53, configured to send the first target data acquisition request to the server device, so that the server device sends the first target data acquisition request to the first service instance; the set of release object identifiers corresponding to the first service instance includes the request identifier carried in the first target data acquisition request, and the first service instance is used to run the target software of the gray-scale version;

[0139] The specific implementation manner of the gray release device 50 is substantially the same as the specific embodiment of the gray release method provided in the first aspect of the embodiments of the present application, and will not be described herein again.

[0140] Please refer to Figure 6 , the embodiments of the present application further provide a gray release device 60 applied to a server device, which can implement the gray release method provided in the second aspect of the embodiments of the present application. The device 60 includes:

[0141] A receiving module 61, configured to receive a first target data acquisition request sent by a client device. The first target data acquisition request is obtained by the client device marking a first initial data acquisition request with a request identifier corresponding to the client device. The first initial data acquisition request is generated by the client device for the target software of the gray version;

[0142] A determining module 62, configured to determine that the request identifier carried in the first target data acquisition request exists in a release object identifier set corresponding to a first service instance. The first service instance is a service instance running the target software of the gray version;

[0143] A sending module 63, configured to send the first target data acquisition request to the first service instance.

[0144] The specific implementation manner of the gray release device 60 is substantially the same as the specific embodiment of the gray release method provided in the second aspect of the embodiments of the present application, and will not be described herein again.

[0145] The embodiments of the present application further provide an electronic device. The electronic device includes a memory and a processor. The memory stores a computer program, and when the processor executes the computer program, the above-mentioned gray release method is implemented. The electronic device can be any intelligent terminal including a tablet computer, an in-vehicle computer, etc.

[0146] Please refer to Figure 7 , Figure 7 illustrates the hardware structure of an electronic device in another embodiment. The electronic device includes:

[0147] A processor 701, which can be implemented in a general-purpose CPU (Central Processing Unit), a microprocessor, an application-specific integrated circuit (ASIC), or one or more integrated circuits, etc., and is configured to execute relevant programs to implement the technical solutions provided in the embodiments of the present application;

[0148] The memory 702 can be implemented in the form of a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM), etc. The memory 702 can store an operating system and other application programs. When implementing the technical solutions provided in the embodiments of this specification through software or firmware, the relevant program codes are stored in the memory 702 and are called by the processor 701 to execute the gray release method provided in the first aspect or the second aspect of the embodiments of this application;

[0149] The input / output interface 703 is used to implement information input and output;

[0150] The communication interface 704 is used to implement communication and interaction between this device and other devices. It can communicate through a wired manner (such as USB, network cable, etc.) or through a wireless manner (such as mobile network, WIFI, Bluetooth, etc.);

[0151] The bus 705 transmits information between the various components of the device (such as the processor 701, the memory 702, the input / output interface 703, and the communication interface 704);

[0152] Among them, the processor 701, the memory 702, the input / output interface 703, and the communication interface 704 are communicatively connected to each other inside the device through the bus 705.

[0153] The embodiments of this application also provide a computer-readable storage medium. The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the gray release method provided in the first aspect or the second aspect of the embodiments of this application.

[0154] As a non-transitory computer-readable storage medium, the memory can be used to store non-transitory software programs and non-transitory computer-executable programs. In addition, the memory can include a high-speed random access memory, and can also include non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state storage devices. In some embodiments, the memory optionally includes a memory remotely set relative to the processor, and these remote memories can be connected to the processor through a network. Examples of the above networks include but are not limited to the Internet, an enterprise intranet, a local area network, a mobile communication network, and combinations thereof.

[0155] The gray release method and gray release system provided by the embodiments of the present application achieve precise allocation of data traffic during the gray release process. The client device generates a first initial data acquisition request and marks the first initial data acquisition request with a request identifier, so that the first initial data acquisition request carries a clear identifier and becomes a first target data acquisition request. After receiving the first target data acquisition request, the server device can determine whether the first target data acquisition request comes from the target release object of the gray version by determining whether the request identifier carried by it exists in the set of release object identifiers corresponding to the first service instance (i.e., the gray service instance running the target software of the gray version). When the server device determines that the request identifier carried by the first target data acquisition request exists in the set of release object identifiers corresponding to the first service instance, the server device sends the first target data acquisition request to the first service instance, ensuring that the data traffic (i.e., the first target data acquisition request) for the target software of the gray version can be accurately distributed to the corresponding gray service instance - that is, the first service instance.

[0156] In this way, the server device can determine whether the request comes from the target release object of the gray release based on the request identifier pre-marked by the client device for the data acquisition request, thereby achieving precise allocation of data traffic during the gray release process. This is more accurate and controllable compared to the random sampling or proportional traffic allocation methods used in existing gray release methods, enabling targeted gray release, effectively reducing the risk of affecting the user experience due to non-precise data traffic allocation, and ensuring the stability and reliability of the system composed of the server device and the client device.

[0157] The embodiments described in the embodiments of the present application are for more clearly illustrating the technical solutions of the embodiments of the present application and do not constitute a limitation on the technical solutions provided by the embodiments of the present application. Those skilled in the art know that with the evolution of technology and the emergence of new application scenarios, the technical solutions provided by the embodiments of the present application are equally applicable to similar technical problems.

[0158] Those skilled in the art can understand that the technical solutions shown in the figures do not constitute a limitation on the embodiments of the present application, and may include more or fewer steps than those shown in the figures, or combine some steps, or different steps.

[0159] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separated, that is, they may be located in one place, or may be distributed to multiple network units. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0160] Those of ordinary skill in the art will understand that all or some of the steps in the methods disclosed above, and the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or a suitable combination thereof.

[0161] As used in the specification of this application and the above-mentioned drawings, the terms "first", "second", "third", "fourth", etc. (if any) are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchanged under appropriate circumstances so that the embodiments of this application described here can be implemented in an order different from those illustrated or described here. In addition, the terms "comprising" and "having" and any variations thereof are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that comprises a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units not clearly listed or inherent to these processes, methods, products, or devices.

[0162] It should be understood that in this application, "at least one (item)" means one or more, and "a plurality" means two or more. "And / or" is used to describe the association relationship of associated objects and indicates that there can be three relationships. For example, "A and / or B" can mean: only A exists, only B exists, and both A and B exist at the same time. Here, A and B can be singular or plural. The character " / " generally means that the associated objects before and after are in an "or" relationship. "At least one (one) of the following" or a similar expression means any combination of these items, including any combination of single items (ones) or plural items (ones). For example, at least one (one) of a, b, or c can mean: a, b, c, "a and b", "a and c", "b and c", or "a and b and c", where a, b, and c can be single or multiple.

[0163] In several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the above-mentioned unit division is only a logical function division, and there can be other division methods in actual implementation. For example, multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the displayed or discussed coupling or direct coupling or communication connection to each other can be through some interfaces, and the indirect coupling or communication connection of the devices or units can be in an electrical, mechanical, or other form.

[0164] The units described above as separate components may or may not be physically separated. The components shown as units may or may not be physical units, that is, they may be located in one place or distributed over multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0165] In addition, the functional units in various embodiments of the present application can be integrated into a processing unit, or each unit can exist physically alone, or two or more units can be integrated into one unit. The above integrated unit can be implemented in the form of hardware or in the form of a software functional unit.

[0166] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, in essence, or the part that contributes to the prior art, or all or part of this technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes multiple instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods in various embodiments of the present application. The foregoing storage medium includes: USB flash drives, mobile hard disks, read-only memories (ROM), random access memories (RAM), magnetic disks, or optical discs and other various media that can store programs.

[0167] The preferred embodiments of the embodiments of the present application have been described above with reference to the accompanying drawings, but this does not limit the scope of the rights of the embodiments of the present application. Any modification, equivalent replacement, and improvement made by those skilled in the art without departing from the scope and essence of the embodiments of the present application shall be within the scope of the rights of the embodiments of the present application.

Claims

1. A grayscale release method, characterized in that: Applied to a client device, the method comprises: Generate a first initial data acquisition request for a grayscale version of target software initiated to a server device, wherein the server device includes multiple service instances, and the multiple service instances are used to run multiple versions of the target software, and the multiple versions include the grayscale version; Marking the first initial data acquisition request using the request identifier corresponding to the client device to obtain a first target data acquisition request; The first target data acquisition request is sent to the server-side device, so that the server-side device sends the first target data acquisition request to a first service instance; the publishing object identifier set corresponding to the first service instance includes the request identifier carried by the first target data acquisition request, and the first service instance is used to run the grayscale version of the target software.

2. The method according to claim 1, characterized in that After sending the first target data acquisition request to the server device, the method further includes: The running status of the grayscale version of the target software is determined according to the response status of the first service instance to the first target data acquisition request.

3. The method according to claim 1, characterized in that The step of marking the first initial data acquisition request by using the request identifier corresponding to the client device to obtain a first target data acquisition request includes: Generate the request identifier according to the data information obtained from the first initial data acquisition request, the data information including at least one of the following: the device type of the client device, the user identifier of operating the client device, the device location of the client device, and the target access version; The first initial data acquisition request is marked using the request identifier.

4. The method according to claim 3, characterized in that The using the request identifier to mark the first initial data acquisition request includes: An identification field is generated using the request identification, and the identification field is added to the first initial data acquisition request.

5. The method according to claim 1, characterized in that The method further comprises: Generating a second initial data acquisition request for the non-grayscale version of the target software initiated to the server device; Marking the second initial data acquisition request using the request identifier corresponding to the client device to obtain a second target data acquisition request; Sending the second target data acquisition request to the server device, so that the server device sends the second target data acquisition request to a second service instance; the publishing object identifier set corresponding to the second service instance includes the request identifier carried by the second target data acquisition request, and the second service instance is used to run the non-grayscale version of the target software; Receive interaction data sent by the server device, where the interaction data is data generated by the second service instance in response to the second target data acquisition request.

6. A grayscale release method, characterized in that: Applied to a server device, the server device includes multiple service instances, the multiple service instances are used to run multiple versions of target software, the multiple versions include grayscale versions, the method includes: Receiving a first target data acquisition request sent by a client device, where the first target data acquisition request is obtained by the client device marking a first initial data acquisition request using a request identifier corresponding to the client device, where the first initial data acquisition request is generated by the client device for the grayscale version of the target software; Determining that the request identifier carried by the first target data acquisition request exists in the publishing object identifier set corresponding to the first service instance, where the first service instance is a service instance running the grayscale version of the target software; The first target data acquisition request is sent to the first service instance.

7. The method according to claim 6, characterized in that After sending the first target data acquisition request to the first service instance, the method further includes: The first target data acquisition request is processed by the first service instance, so that the client device determines the running status of the grayscale version of the target software according to the response status of the first service instance to the first target data acquisition request.

8. The method according to claim 6, characterized in that The method further comprises: receiving a second target data acquisition request sent by a client device, where the second target data acquisition request is obtained by the client device marking a second initial data acquisition request using a request identifier corresponding to the client device, where the second initial data acquisition request is generated by the client device for the non-grayscale version of the target software; Determining that the request identifier carried by the second target data acquisition request exists in the publishing object identifier set corresponding to the second service instance, where the second service instance is a service instance running the non-grayscale version of the target software; Sending the second target data acquisition request to the second service instance; Sending interaction data to the client device, where the interaction data is data generated by the second service instance in response to the second target data acquisition request.

9. A grayscale release system, characterized in that: The system includes a client device and a server device, the server device includes multiple service instances, the multiple service instances are used to run multiple versions of the target software, the multiple versions include the grayscale version; The client device is used to generate a first initial data acquisition request for the grayscale version of the target software initiated to the server device, and use the request identifier corresponding to the client device to mark the first initial data acquisition request to obtain a first target data acquisition request, and send the first target data acquisition request to the server device; The server-side device is used to receive the first target data acquisition request, and after determining that the request identifier carried by the first target data acquisition request exists in the publishing object identifier set corresponding to the first service instance, send the first target data acquisition request to the first service instance, wherein the first service instance is a service instance running the grayscale version of the target software.

10. The system according to claim 9, characterized in that The server device is further used to process the first target data acquisition request through the first service instance; The client device is further configured to determine a running status of the grayscale version of the target software according to a response status of the first service instance to the first target data acquisition request.

Images