Gray scale publishing method and apparatus

Abstract

This application discloses a canary release method and apparatus. The method includes: sending canary traffic policies to a client release platform and a gateway layer through a traffic policy management platform, wherein the canary traffic policies are used to indicate target users accessing the updated version; performing client canary release according to the canary traffic policies through the client release platform; and performing server-side canary release by tagging client service requests based on the canary traffic policies through the gateway layer. This can reduce the manpower cost of canary release and improve flexibility and release efficiency.

Description

Technical Field

[0001] This application relates to the field of software distribution technology, and in particular to a grayscale distribution method and apparatus. Background Technology

[0002] Canary release is a technique that gradually and controllably exposes updated software versions to a limited number of users to verify their functional stability and performance metrics, aiming to minimize the impact of potential problems. Its core value lies in balancing software release efficiency and system stability, effectively avoiding the risk of global failures that may be caused by full release, and is especially suitable for services with stringent high availability requirements.

[0003] Traditional canary releases rely on hard-coded switches embedded in the software. The on or off status of these hard-coded switches controls whether the functions or services of the updated software version are exposed (or released) to the target users. However, this method is labor-intensive and lacks flexibility. Summary of the Invention

[0004] In view of this, this application provides a gray-scale release method and apparatus to reduce the manpower cost of gray-scale release and improve flexibility and release efficiency.

[0005] This application provides the following solution: Firstly, a canary release method is provided, which includes: The traffic policy management platform sends gray-scale traffic policies to the client publishing platform and gateway layer respectively. The gray-scale traffic policies are used to indicate the target users who want to access the updated version. Canary deployments to clients are conducted through a client-side publishing platform based on a canary traffic strategy. By labeling client service requests using a canary traffic strategy at the gateway layer, server-side canary deployment can be performed.

[0006] Optionally, the canary traffic policy is sent to the client publishing platform and the gateway layer respectively through the traffic policy management platform, including: Obtain the current gray-scale traffic policy through the traffic policy management platform; Send canary traffic policies to the client publishing platform and gateway layer respectively.

[0007] Optionally, the client deployment platform includes a native application deployment platform, through which client canary deployments are performed according to a canary traffic strategy, including: The updated client package file is distributed to target users through the native application distribution platform according to the canary traffic strategy.

[0008] Optionally, the client deployment platform includes a web application deployment platform, through which client canary deployments are performed according to a canary traffic strategy, including: The network application publishing platform uses a gray-scale traffic strategy to label the access requests of target users with gray-scale tags. This enables the client gray-scale cluster to return updated client data to the target user and the original client data to users other than the target user, based on the gray-scale tags. The client gray-scale cluster includes both updated and original client data.

[0009] Optionally, the web application publishing platform labels the access requests of target users with gray-scale tags according to the gray-scale traffic strategy, so that the client gray-scale cluster returns updated client data to the target user and the original client data to users other than the target user based on the gray-scale tags, including: Receive user access requests through a web application publishing platform; When the web application publishing platform is in a gray-scale release state, it labels access requests according to the gray-scale traffic strategy and marks the access requests of target users with gray-scale tags. When the web application publishing platform is in a canary release state, it sends access requests to the client canary cluster. The client canary cluster then returns the updated version of the client data to the target user and the original version of the client data to users other than the target user, depending on whether the access request is labeled with a canary tag.

[0010] Optionally, the method further includes: When the web application publishing platform is in a non-canary release state, it sends an access request to the original client cluster, so that the original client cluster returns the original version of the client data to the user based on the access request.

[0011] Optionally, the service requests from clients can be tagged at the gateway layer based on a canary traffic strategy for server-side canary release, including: By labeling service requests with a gray-scale traffic strategy at the gateway layer, gray-scale labels are marked on the service requests corresponding to the target users. The gateway layer sends service requests to the server, enabling the server to respond to the service requests based on grayscale labels. The updated version of the service returns response data to the client corresponding to the service request labeled with grayscale labels, while the original version of the service returns response data to the client corresponding to the service request without grayscale labels.

[0012] Optionally, the server includes a link consisting of at least two service nodes. The server responds to service requests based on mutual calls between the service nodes in the link to return response data to the client. When the service nodes in the link call each other, they pass through grayscale tags based on the call request. The server responds to call requests with grayscale tags by updating the service node and responds to call requests without grayscale tags by the original version of the service node.

[0013] Optionally, if the service node to which the call request with the grayscale label is pointed does not have an updated version of the service node, then the call request with the grayscale label is responded to through the original version of the service node.

[0014] Optionally, the service node can pass through the grayscale label in the call request through the software development kit (SDK) integrated into the microservice framework.

[0015] Optionally, the service node can pass grayscale labels through bytecode instrumentation in the call request.

[0016] Optionally, the gateway layer includes an ingress gateway and a business gateway. The gateway layer labels service requests based on a gray-scale traffic strategy, assigning gray-scale labels to service requests corresponding to target users, including: By labeling service requests based on the gray-scale traffic strategy through the ingress gateway and the business gateway, gray-scale labels are marked on the service requests corresponding to the target users.

[0017] Secondly, a grayscale publishing device is provided, the device comprising: The traffic policy management platform is used to send canary traffic policies to the client publishing platform and the gateway layer respectively. The canary traffic policies are used to indicate the target users who want to access the updated version. A client deployment platform used for canary deployment of clients based on canary traffic strategies; The gateway layer is used to label client service requests based on a canary traffic strategy for server-side canary release.

[0018] Thirdly, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the steps of the method described in any one of the first aspects above.

[0019] Fourthly, an electronic device is provided, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any one of the first aspects above.

[0020] According to the specific embodiments provided in this application, the following technical effects are disclosed: In this application, a traffic policy management platform can be used to uniformly configure and manage corresponding canary traffic policies. This allows the traffic policy management platform to send a unified canary traffic policy to both the client deployment platform and the gateway layer, enabling the client deployment platform and the gateway layer to implement corresponding client-side and server-side canary deployments based on the received canary traffic policies. This allows client-side and server-side canary deployments to be performed in parallel and collaboratively based on a unified canary traffic policy, improving the efficiency of software canary deployments.

[0021] In addition, this application eliminates the hard-coded switch and uses a gray-scale traffic strategy for client-side and server-side gray-scale releases. This allows for convenient and quick control over the release scope of updated versions by adjusting the gray-scale traffic strategy in real time, thereby reducing the manpower cost of gray-scale releases and improving flexibility.

[0022] Of course, any product implementing this application does not necessarily need to achieve all of the advantages described above at the same time. Attached Figure Description

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

[0024] Figure 1 This is a system architecture diagram applicable to the embodiments of this application.

[0025] Figure 2 This is a flowchart illustrating the grayscale release method provided in an embodiment of this application.

[0026] Figure 3 This is a schematic diagram of the traffic policy management platform provided in an embodiment of this application.

[0027] Figure 4 This is a schematic diagram of the presentation layer of the traffic strategy management platform provided in an embodiment of this application.

[0028] Figure 5 This is one of the schematic diagrams of client-side grayscale release provided in the embodiments of this application.

[0029] Figure 6 This is the second schematic diagram of client-side grayscale release provided in the embodiments of this application.

[0030] Figure 7This is a schematic diagram of server-side grayscale publishing provided in an embodiment of this application.

[0031] Figure 8 This is a schematic diagram of the grayscale publishing device provided in an embodiment of this application.

[0032] Figure 9 A schematic block diagram of an electronic device provided in an embodiment of this application. Detailed Implementation

[0033] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of this application are within the scope of protection of this application.

[0034] The terminology used in the embodiments of this invention is for the purpose of describing particular embodiments only and is not intended to limit the invention. The singular forms “a,” “the,” and “the” as used in the embodiments of this invention and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise.

[0035] It should be understood that the term "and / or" used in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. Additionally, the character " / " in this article generally indicates that the preceding and following related objects have an "or" relationship.

[0036] Depending on the context, the word "if" as used here can be interpreted as "when," "when," "in response to determination," or "in response to detection." Similarly, depending on the context, the phrase "if determination" or "if detection (of the stated condition or event)" can be interpreted as "when determination," "in response to determination," "when detection (of the stated condition or event)," or "in response to detection (of the stated condition or event)."

[0037] Canary release is a technique that gradually and controllably exposes updated software versions to a limited number of users to verify their functional stability and performance metrics, aiming to minimize the impact of potential problems. Its core value lies in balancing software release efficiency and system stability, effectively avoiding the risk of global failures that may be caused by full release, and is especially suitable for services with stringent high availability requirements.

[0038] Traditional canary releases rely on hard-coded switches embedded in the software. The on or off status of these hard-coded switches controls whether the functions or services of the updated software version are exposed (or released) to the target users. However, this method is labor-intensive and lacks flexibility.

[0039] In view of this, this application provides a canary release method. The corresponding canary traffic policies can be uniformly configured and managed through a traffic policy management platform. Thus, the traffic policy management platform can send a unified canary traffic policy to both the client release platform and the gateway layer, enabling the client release platform and the gateway layer to implement corresponding client-side and server-side canary releases based on the received canary traffic policies. This allows client-side and server-side canary releases to be performed in parallel and collaboratively based on a unified canary traffic policy, improving the efficiency of software canary releases. Furthermore, the method of this application eliminates hard-coded switches, and by using canary traffic policies for both client-side and server-side canary releases, the scope of updated version releases can be easily and quickly controlled through real-time adjustments to the canary traffic policies, thereby reducing the manpower costs of canary releases and increasing flexibility.

[0040] The canary release method provided in this application allows for canary releases of software to both the client and server sides. For example, Figure 1 A schematic diagram of the system architecture provided in an embodiment of this application is shown. For example... Figure 1 As shown, the system architecture can include terminal devices and servers, which can communicate with each other via a network. The software client can be deployed on the terminal device, allowing users to interact with the client through the terminal. The software server can be deployed on the server, allowing the client to call the server-side component through the terminal device to collaborate and achieve corresponding functions. The server can be a single server or a server cluster based on distributed technology; there are no restrictions here.

[0041] In this embodiment, the traffic policy management platform, client publishing platform, and gateway layer involved in the above-mentioned canary release method can also be deployed on the aforementioned server to execute the canary release method provided in this application through the server. Alternatively, the traffic policy management platform, client publishing platform, and gateway layer can also be deployed on different electronic devices based on distributed technology to work together to execute the canary release method provided in this application. Here, there are no restrictions on the deployment strategy of the traffic policy management platform, client publishing platform, and gateway layer.

[0042] The aforementioned terminal devices may include, but are not limited to, smart mobile terminals, wearable devices, PCs (Personal Computers), and smart home devices. Smart mobile terminals may include devices such as mobile phones, tablets, laptops, PDAs (Personal Digital Assistants), and connected car terminals. Wearable devices may include devices such as smartwatches, smart glasses, smart bracelets, VR (Virtual Reality) devices, AR (Augmented Reality) devices, and mixed reality devices (devices that support both virtual and augmented reality). Smart home devices may include devices such as smart TVs and AI assistants.

[0043] It should be understood that Figure 1 The number of terminal devices and servers shown is merely illustrative. Depending on implementation needs, any number can be used; no limit is imposed here.

[0044] Figure 2 This is a flowchart illustrating the grayscale release method provided in an embodiment of this application. Figure 2 As shown, the method may include the following S201-S203.

[0045] S201: Send gray-scale traffic policies to the client publishing platform and gateway layer respectively through the traffic policy management platform.

[0046] The canary release strategy is used to indicate the target users who need to access the updated version. In other words, the canary release strategy can be used to indicate the target users on both the client and server sides who need the updated version during the canary release process.

[0047] For example, a gray-scale traffic strategy can be formulated based on user identity, user type, user behavior data, etc., to target users who meet specific identity, type, or behavior data requirements.

[0048] Of course, in some possible implementations, a canary traffic strategy can be formulated for different types or identities of users, based on the required traffic allocation ratio, to control the proportion of target users who can access the updated version among different types or identities. For example, for users of identity 1, the canary traffic strategy could be that the target users accessing the updated version and the users accessing the original version each account for 50%. For users of identity 2, the canary traffic strategy could be that the target users accessing the updated version account for 1% of users of identity 2, and so on.

[0049] In this embodiment, the traffic policy management platform can be a platform capable of creating and managing gray-scale traffic policies. For example, such as... Figure 3As shown, the traffic policy management platform can include a presentation layer to allow users to interact and perform operations such as adding, deleting, and modifying gray-scale traffic policies. Within this platform, corresponding gray-scale traffic policy management capabilities can be implemented based on configured functional modules. For example, a policy query module can be used to query policy information or perform operations such as adding, deleting, and modifying policy information. A policy change message module can also be used to perform operations such as adding, deleting, and modifying policy information or binding relationships. Gray-scale traffic policies can be stored in a database (DB) to support operations such as policy information querying, adding, deleting, and modifying policy information and binding relationships. Message queues (MQ) can also be used to support operations such as adding, deleting, and modifying policy information and binding relationships. This traffic policy management platform can send gray-scale traffic policies to the client publishing platform and gateway layer by configuring client publishing platform interfaces and gateway layer interfaces.

[0050] In some possible implementations, the traffic policy management platform can also be configured with an approval module to execute approval processes related to the creation and management of gray-scale traffic policies. Alternatively, a permission management module can be configured to authenticate management users using the traffic policy management platform, preventing unauthorized users from creating and managing gray-scale traffic policies, thereby improving the security of the traffic policy management platform. The approval module and permission management module can be configured according to relevant technologies, and no restrictions are placed here. For example, the approval module can be configured based on specific internal approval processes, and the permission management module can be configured based on required permission verification logic.

[0051] The traffic policy management platform can also be configured with API and RPC interfaces required to execute corresponding capabilities, such as calling approval and authentication processes through the configured API and RPC interfaces to achieve corresponding approval process capabilities and permission management capabilities.

[0052] For example, the presentation layer of a traffic policy management platform can be built on the Cyber ​​Builder low-code platform, such as... Figure 4 As shown, models and operations can be defined sequentially to construct the elements and operations contained in the page. This generates metadata, and based on the metadata, corresponding ProtoBuf files are generated. Pages are then generated and adjusted to construct the corresponding front-end. Finally, publishing is performed to complete the relevant service registration / parameter mapping, so that when users access the presentation layer, they can request the corresponding page through the business rendering container via HTTP requests. Of course, in this embodiment, the presentation layer can also be constructed in any other way to allow users to interact with the traffic policy management platform based on the presentation layer.

[0053] In this embodiment of the application, as an example, when sending gray-scale traffic policies to the client publishing platform and the gateway layer through the traffic policy management platform, specifically, the current gray-scale traffic policy can be obtained through the traffic policy management platform, and then the obtained gray-scale traffic policy can be sent to the client publishing platform and the gateway layer respectively. In this way, the latest gray-scale traffic policy can be synchronized to the client publishing platform and the gateway layer based on the dynamic adjustments made by the developers to the gray-scale traffic policy through the traffic policy management platform, thereby realizing convenient real-time dynamic adjustment of the gray-scale release scope.

[0054] S202. Perform client-side canary deployments based on the canary traffic strategy through the client-side deployment platform.

[0055] The client deployment platform can be any client deployment or management platform with canary deployment capabilities; there are no restrictions here.

[0056] In this embodiment, the client publishing platform may include a native application publishing platform or a web application publishing platform.

[0057] For native application distribution platforms, updated client packages can be distributed to target users according to a canary deployment strategy, thereby achieving canary deployment of the native application client. For example, Figure 5 As shown, the native application deployment platform can use the rules engine service to match target users according to the gray-scale traffic strategy, thereby sending the updated version of the client package file (such as Bundle-V1) to the target users, while other users still use the original version of the client package file (such as Bundle-V0).

[0058] Among them, the native application publishing platform can identify users based on their unique identifiers, such as user ID, developer ID, order ID, etc., and then match target users based on the gray-scale traffic strategy.

[0059] For web application deployment platforms, when deploying a client canary cluster that includes both updated and original versions of client data, the platform can label target user access requests with canary tags according to a canary traffic strategy. This allows the client canary cluster to return the updated client data to the target user and the original client data to other users based on the canary tags. Thus, the platform can match target users according to the canary traffic strategy, sending the updated client data to the target user and the original client data to other users, ensuring that the target user uses the updated client while other users use the original client.

[0060] As an example, a grayscale switch can be configured in the web application deployment platform to indicate the grayscale deployment status. The switching on and off of the grayscale switch indicates whether the application is currently in a grayscale deployment or not. Therefore, when in a grayscale deployment state, the web application deployment platform can label access requests according to the grayscale traffic policy, marking the target user's access request with a grayscale label. During the grayscale deployment, the platform sends access requests to the client grayscale cluster, which then returns the updated version of the client data to the target user and the original version of the client data to other users, depending on whether the access request is labeled with a grayscale label. This allows for control over whether the web application deployment platform performs grayscale deployments according to the grayscale traffic policy through the grayscale switch, improving the controllability and flexibility of client grayscale deployments for web applications.

[0061] For example, such as Figure 6 As shown, when in a canary release state, after receiving an access request, the web application deployment platform can first label the access request according to the canary traffic policy. Then, based on gateway conditions, the access request is routed to the client canary cluster. The client canary cluster then returns the updated version of the client data (such as V1-html) to the target user and the original version of the client data (such as V0-html) to other users, depending on whether the access request is labeled with a canary tag.

[0062] In some possible implementations, the client canary cluster can be a separate cluster deployed independently of the original client cluster, containing only the original client data, based on both the original and updated client data when canary releases are needed. In this case, the web application deployment platform can send access requests to the original client cluster while in a non-canary release state, causing the original client cluster to return the original client data to the user based on the access request. This allows the web application deployment platform to switch to a non-canary release state when the updated client data in the canary release has functional or operational issues. In this non-canary release state, all access requests can be redirected to the original client cluster, enabling rapid version rollback for the target user's client and preventing the problematic updated client from continuously affecting the target user.

[0063] For example, continue as Figure 6 As shown, when in a non-canary release state, after receiving an access request, the web application publishing platform can redirect the access request to the original client cluster based on gateway conditions, so that the original client cluster can return the original version of the client data (such as V0-html) to all users according to the access request.

[0064] As an example, in this embodiment of the application, the network application publishing platform can obtain the user's unique identifier, such as user ID, developer ID, order ID, etc., by parsing the HTTP request header, query parameters, gateway authentication information, or by the gateway intercepting the request body content. Then, the platform can identify the user based on the unique identifier and mark the access request corresponding to the target user with a grayscale label according to the identification result.

[0065] S203. The service requests from clients are labeled using a gray-scale traffic strategy at the gateway layer to enable gray-scale deployment on the server side.

[0066] For example, a gateway layer can label client service requests based on a canary traffic strategy, assigning canary tags to service requests corresponding to target users, and then sending these requests to the server. This allows the server to respond to service requests based on the canary tags, returning response data to clients with canary tags using updated versions of the service, and returning response data to clients with unlabeled service requests using the original versions of the service. In other words, the gateway layer can label service requests sent to target users' clients based on a canary traffic strategy, enabling the server to respond to the target user's clients with updated versions of the service to implement the corresponding business, and to respond to other users' clients with the original versions of the service to implement the corresponding business, thereby achieving server-side canary deployment.

[0067] In some possible implementations, the gateway layer may include an ingress gateway and a business gateway. In this case, the ingress gateway and business gateway can respectively label service requests based on a canary traffic strategy, thus labeling service requests corresponding to target users with canary tags. In this way, even when the ingress gateway on the entire server cannot match the target user and label service requests based on the canary traffic strategy, more precise and granular labeling of service requests can be performed based on the business gateway, thereby improving the accuracy of traffic control for service requests during the canary release process.

[0068] As an example, in this embodiment of the application, the gateway layer can obtain the user's unique identifier, such as user ID, developer ID, order ID, etc., by parsing the HTTP request header, query parameters, gateway authentication information, or by intercepting the request body content. Then, the user is identified based on the unique identifier, and grayscale labels are marked on the service requests corresponding to the target user according to the identification results.

[0069] Optionally, the server in this embodiment may include a link consisting of at least two service nodes. The server can respond to service requests and return response data to the client based on the mutual calls between the service nodes in the link. When the service nodes in the link call each other, they can pass through grayscale tags on the call request. This allows the updated version of the service node to respond to call requests with grayscale tags, and the original version of the service node to respond to call requests without grayscale tags. Therefore, through the grayscale tag passing mechanism, accurate traffic control can be achieved for each service node during the call process to perform canary deployments.

[0070] When a service node passes grayscale tags based on a call request, it can do so through the Software Development Kit (SDK) integrated into the microservice framework corresponding to the server. For example, the SDK can integrate the corresponding pass-through capability. When a service request received at the server entry point is marked with a grayscale tag, the server's response to that request allows the SDK to add the corresponding grayscale tag to the call requests sent by each service node in the chain when calling the next service node, thus achieving the pass-through of grayscale tags between service nodes. This allows for the direct and quick addition of grayscale tags to each call request through the integrated SDK, achieving high flexibility and reducing system complexity.

[0071] Alternatively, when service nodes pass through grayscale tags based on call requests, the grayscale tags can be passed through the call requests via bytecode instrumentation. For example, by embedding a Java Agent, when a service request received at the server entry point is marked with a grayscale tag, the Java Agent, during the server-side response to that service request, adds the corresponding grayscale tag to the call requests sent by each service node when calling the next service node through bytecode instrumentation, thereby achieving the pass-through of grayscale tags between service nodes. In this way, grayscale tag pass-through with low business intrusion can be achieved based on Java Agent without modifying the microservice framework's SDK.

[0072] Of course, the above is only an exemplary example of how to achieve the transparent transmission of grayscale labels in various service nodes. In practical applications, the transparent transmission of grayscale labels can also be achieved based on other related technologies, and there are no restrictions here.

[0073] Based on the above example, in some possible implementations, when the service node to which the call request with the grayscale label is pointed does not have an updated version, the call request with the grayscale label can be responded to through the original version of the service node. This ensures that when the called service node does not have an updated version, the original version of the service node is used to respond to all service requests, avoiding situations where service requests sent by the target user's client experience response errors due to interruptions in the server's response based on the connection.

[0074] In this embodiment, a corresponding grayscale identifier can be configured for each updated version of the service node to indicate the corresponding updated version. Therefore, a service node with a grayscale identifier can be invoked based on a service request labeled with a grayscale tag or a call request that transmits a grayscale tag, and a service node without a grayscale identifier can be invoked based on a service request without a grayscale tag or a call request that does not transmit a grayscale tag. Of course, in some possible implementations, if a call request with a grayscale tag points to a service node without a grayscale identifier, then the corresponding service node without a grayscale identifier can also be invoked.

[0075] For example, based on the previous example, consider a server consisting of three service nodes: A, B, and C. Service node A includes both the original version of the service node (service A) and the updated version (service A'). Service node B only includes the original version of the service node (service B). Service node C includes both the original version of the service node (service C) and the updated version (service C'). Then, when the gateway layer receives a service request, such as... Figure 7As shown, service requests can be tagged based on a grayscale traffic strategy, marking the service requests corresponding to the target user with grayscale labels (such as pre-gray). The gateway layer can then send the service requests to the server. For service requests without grayscale labels, the original version of service node A can first respond. Then, service A can call the original version of service node B through a call request without grayscale labels to respond. Finally, service B can call the original version of service node C through a call request without grayscale labels to respond, thus returning response data to the client of the service request without grayscale labels. For service requests labeled with grayscale, the updated version of service node service A' can respond first. Then, service A' can pass through the grayscale label (such as pre-gray) in the call request, thereby calling service node B through the call request with the grayscale label. Since service node B only has the original version of service node service B, service A' can call the original version of service node service B through the call request with the grayscale label to respond. Then, service B passes through the grayscale label (such as pre-gray) in the call request, and calls the updated version of service node service C' through the call request with the grayscale label to respond, thereby returning response data to the client that made the service request labeled with grayscale.

[0076] In this embodiment of the application, two or more different update versions can be released simultaneously. This allows for the configuration of gray-scale traffic strategies for different update versions based on the aforementioned example. These strategies are then sent to the client publishing platform and the gateway layer. The client publishing platform then performs client-side gray-scale releases of different update versions based on each gray-scale traffic strategy. The gateway layer then labels the service requests of the target users for different update versions with corresponding tags based on each gray-scale traffic strategy (i.e., labels different gray-scale tags for different update versions) to perform server-side gray-scale releases.

[0077] In this embodiment of the application, for server-side canary releases, a dual availability zone deployment architecture can be adopted, and an updated version of the service can be built by deploying one or two or more instances in each availability zone, so as to improve the system's disaster recovery capability.

[0078] In this embodiment of the application, the stability and functionality of the updated client and / or the updated server can also be verified by the monitoring platform based on logs. This makes it easier to prevent target users from accessing the updated client and / or server again and accessing the original client and / or server when the updated client and / or server is abnormal. This can be achieved by adjusting the gray-scale traffic strategy or one-click rollback in related technologies, thus avoiding continuous impact on target users when the updated version is abnormal.

[0079] The canary release method provided in this application, compared to full release, allows for the release of an updated version within a specific scope during the canary release process, and its functionality can be verified. This facilitates subsequent full releases only after the updated version has passed verification. Consequently, the impact on users when update releases encounter anomalies can be reduced.

[0080] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0081] According to another embodiment, a grayscale publishing device is provided. Figure 8 An exemplary schematic diagram of a grayscale publishing device is shown. Figure 8 As shown, the device includes: a traffic policy management platform 801, used to send gray-scale traffic policies to the client publishing platform and the gateway layer respectively, the gray-scale traffic policies being used to indicate target users accessing the updated version; a client publishing platform 802, used to perform client gray-scale publishing according to the gray-scale traffic policies; and a gateway layer 803, used to label the client's service requests based on the gray-scale traffic policies for server-side gray-scale publishing.

[0082] Optionally, the traffic policy management platform 801 is specifically used to obtain the current grayscale traffic policy and send the grayscale traffic policy to the client publishing platform and the gateway layer respectively.

[0083] Optionally, the client distribution platform 802 is specifically used to distribute updated client package files to target users through the native application distribution platform according to the gray-scale traffic strategy.

[0084] Optionally, the client publishing platform 802 is specifically used to mark the access requests of target users with gray-scale tags according to the gray-scale traffic strategy through the network application publishing platform, so that the client gray-scale cluster returns updated version client data to the target user and returns the original version client data to users other than the target user according to the gray-scale tags. The client gray-scale cluster includes updated version client data and original version client data.

[0085] Optionally, the client publishing platform 802 is specifically used to receive user access requests through the web application publishing platform; when the web application publishing platform is in a gray-scale release state, it tags the access requests according to the gray-scale traffic strategy, marking the access requests of the target users with gray-scale labels; when the web application publishing platform is in a gray-scale release state, it sends access requests to the client gray-scale cluster, so that the client gray-scale cluster returns updated client data to the target user and returns the original client data to users other than the target user, depending on whether the access request is marked with a gray-scale label.

[0086] Optionally, the client publishing platform 802 is also used to send an access request to the original client cluster through the web application publishing platform when it is in a non-canary release state, so that the original client cluster returns the original version of the client data to the user according to the access request.

[0087] Optionally, the gateway layer 803 is specifically used to label service requests based on a grayscale traffic strategy, label service requests corresponding to target users with grayscale tags, send service requests to the server so that the server responds to the service requests according to the grayscale tags, return response data to the client corresponding to the service request labeled with grayscale tags through an updated version of the service, and return response data to the client corresponding to the service request without grayscale tags through the original version of the service.

[0088] Optionally, the server includes a link consisting of at least two service nodes. The server responds to service requests based on mutual calls between the service nodes in the link to return response data to the client. When the service nodes in the link call each other, they pass through grayscale tags based on the call request. The server responds to call requests with grayscale tags by updating the service node and responds to call requests without grayscale tags by the original version of the service node.

[0089] Optionally, if the service node to which the call request with the grayscale label is pointed does not have an updated version of the service node, then the call request with the grayscale label is responded to through the original version of the service node.

[0090] Optionally, the service node can pass through the grayscale label in the call request through the software development kit (SDK) integrated into the microservice framework.

[0091] Optionally, the service node can pass grayscale labels through bytecode instrumentation in the call request.

[0092] Optionally, the gateway layer 803 is specifically used to label service requests based on the grayscale traffic strategy through the ingress gateway and the business gateway respectively, and to label the service requests corresponding to the target user with grayscale labels.

[0093] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for system or device embodiments, since they are basically similar to method embodiments, the description is relatively simple, and relevant parts can be referred to the description of the method embodiments. The system and device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0094] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0095] In addition, embodiments of this application also provide a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0096] And an electronic device, comprising: One or more processors; and A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method described in any of the foregoing method embodiments.

[0097] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the method described in any of the foregoing method embodiments.

[0098] in, Figure 9An exemplary architecture of an electronic device is illustrated, which may specifically include a bus 901, a processor 902, a memory 903, and a communication interface 904. The processor 902, memory 903, and communication interface 904 communicate via the bus 901. The memory 903 stores computer program code, including computer instructions. When these instructions are executed by the processor 902, the electronic device performs the methods provided in the foregoing embodiments. It should be understood that this application does not limit the number of processors 902 and memories 903 in the electronic device.

[0099] The 901 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The 901 bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 9 The bus 901 may be represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 901 may include a path for transmitting information between various components of an electronic device (e.g., memory 903, processor 902, communication interface 904).

[0100] Processor 902 may include any one or more processors such as a central processing unit, a graphics processing unit, a microprocessor (MP), or a digital signal processor (DSP).

[0101] Memory 903 may include volatile memory, such as random access memory (RAM). Memory 903 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0102] The communication interface 904 uses a command distribution module, such as, but not limited to, a network interface card or transceiver, to enable communication between the device and other devices or communication networks.

[0103] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a computer program product. This computer program product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in various embodiments or some parts of the embodiments of this application.

[0104] The technical solutions provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this application. Furthermore, those skilled in the art will recognize that, based on the ideas of this application, there will be changes in the specific implementation methods and application scope. Therefore, the content of this specification should not be construed as a limitation of this application.

Claims

1. A grayscale release method, characterized in that, include: The traffic policy management platform sends gray-scale traffic policies to the client publishing platform and the gateway layer respectively. The gray-scale traffic policies are used to indicate the target users who want to access the updated version. The client can be deployed in a canary manner according to the canary traffic strategy through the client deployment platform; The gateway layer tags the client's service requests based on the gray-scale traffic policy to enable server-side gray-scale deployment.

2. The method according to claim 1, characterized in that, The step of sending gray-scale traffic policies to the client publishing platform and gateway layer through the traffic policy management platform includes: Obtain the current grayscale traffic policy through the traffic policy management platform; The grayscale traffic policy is sent to both the client publishing platform and the gateway layer.

3. The method according to claim 1, characterized in that, The client deployment platform includes a native application deployment platform, and the step of performing client canary deployments through the client deployment platform according to the canary traffic strategy includes: The updated client package file is distributed to target users through the native application distribution platform according to the gray-scale traffic strategy.

4. The method according to claim 1, characterized in that, The client deployment platform includes a web application deployment platform, and the step of performing client canary deployments through the client deployment platform according to the canary traffic strategy includes: The network application publishing platform labels the access requests of target users with gray-scale tags according to the gray-scale traffic strategy, so that the client gray-scale cluster returns updated version client data to the target user and original version client data to users other than the target user according to the gray-scale tags. The client gray-scale cluster includes updated version client data and original version client data.

5. The method according to claim 4, characterized in that, The step of labeling access requests from target users with gray-scale tags according to the gray-scale traffic strategy through the network application publishing platform, so that the client gray-scale cluster returns updated client data to the target user and the original client data to users other than the target user, based on the gray-scale tags, includes: The network application publishing platform receives user access requests. When the network application publishing platform is in a gray-scale release state, it tags the access requests according to the gray-scale traffic strategy and marks the access requests of the target users with the gray-scale tags. When the network application publishing platform is in a gray-scale release state, it sends the access request to the client gray-scale cluster, so that the client gray-scale cluster returns the updated version of the client data to the target user and the original version of the client data to users other than the target user, depending on whether the access request is marked with the gray-scale label.

6. The method according to claim 5, characterized in that, The method further includes: When the network application publishing platform is in a non-canary release state, it sends the access request to the original client cluster, so that the original client cluster returns the original version of the client data to the user based on the access request.

7. The method according to claim 1, characterized in that, The step of tagging client service requests based on the gray-scale traffic policy through the gateway layer for server-side gray-scale release includes: The gateway layer labels the service requests based on the gray-scale traffic strategy, and labels the service requests corresponding to the target users with gray-scale tags. The gateway layer sends the service request to the server, so that the server responds to the service request according to the grayscale label, returns response data to the client corresponding to the service request labeled with the grayscale label through the updated version of the service, and returns response data to the client corresponding to the service request without the grayscale label through the original version of the service.

8. The method according to claim 7, characterized in that, The server includes a link consisting of at least two service nodes. The server responds to the service request based on the mutual calls between the service nodes in the link to return response data to the client. When the service nodes in the link call each other, they pass through the grayscale label based on the call request. The server responds to the call request with the grayscale label through the updated version of the service node, and responds to the call request without the grayscale label through the original version of the service node.

9. The method according to claim 8, characterized in that, When the service node to which the transparently transmitted grayscale tag points does not have an updated version of the service node, the transparently transmitted grayscale tag call request is responded to through the original version of the service node.

10. The method according to claim 8, characterized in that, The service node transmits the grayscale label in the call request through the software development kit (SDK) integrated into the microservice framework.

11. The method according to claim 8, characterized in that, The service node transmits the grayscale label in the call request through bytecode instrumentation.

12. The method according to any one of claims 7-11, characterized in that, The gateway layer includes an ingress gateway and a service gateway. The step of tagging service requests based on the gray-scale traffic policy through the gateway layer, and tagging service requests corresponding to target users with gray-scale labels, includes: The ingress gateway and the service gateway respectively label the service requests based on the grayscale traffic policy, and label the service requests corresponding to the target user with the grayscale label.

13. A grayscale publishing device, characterized in that, include: A traffic policy management platform is used to send gray-scale traffic policies to the client publishing platform and the gateway layer respectively. The gray-scale traffic policies are used to indicate the target users who want to access the updated version. The client deployment platform is used to perform client canary deployments according to the canary traffic strategy; The gateway layer is used to label the client's service requests based on the gray-scale traffic strategy in order to perform server-side gray-scale release.

14. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the steps of the method according to any one of claims 1 to 12.

15. An electronic device, characterized in that, include: One or more processors; as well as A memory associated with the one or more processors, the memory being used to store program instructions that, when read and executed by the one or more processors, perform the steps of the method according to any one of claims 1 to 12.

16. A computer program product, comprising a computer program, characterized in that, When executed by a processor, the computer program implements the steps of the method according to any one of claims 1 to 12.

Images