A method and apparatus for gray scale publishing

Abstract

This specification discloses a method and apparatus for canary deployment. The canary deployment system acquires traffic segmentation rules corresponding to a target microservice among multiple microservices. Then, based on the traffic received by the new version of the target microservice in the current time period, it obtains the operational data of the new version of the target microservice in the current time period. Finally, based on the operational data of the new version of the target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, it performs traffic segmentation on the traffic received by the target microservice to determine the traffic received by the new version of the target microservice in the next time period, and further obtains the operational data of the new version of the target microservice in the next time period, and so on, until the new version of the target microservice receives all the traffic, thus completing the canary deployment. This automatically adjusts the traffic ratio between the old and new versions of the code, avoiding errors caused by human operation, and improving the efficiency of canary deployment.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method and apparatus for grayscale publishing. Background Technology

[0002] Currently, many internet products have a massive number of active users. If product updates are released directly, it can cause immeasurable damage when product anomalies occur.

[0003] Therefore, before the product is officially launched, a canary release approach can be used to simultaneously deploy the new and old versions of the application code to the real business environment. Some users continue using the old version, while others begin using the new version. If no issues arise with the new version, the rollout can be gradually expanded until all users are using it. This allows for timely collection of user feedback, improvement of product features, enhancement of product quality, and minimization of the impact of product upgrades on the user base.

[0004] However, existing canary release processes often rely on technicians manually adjusting the traffic ratio between the old and new versions of the code. This approach is not only inefficient, but also increases the possibility of errors due to human intervention. Summary of the Invention

[0005] This specification provides a method, apparatus, storage medium, and electronic device for grayscale deployment to improve the efficiency of grayscale deployment.

[0006] The following technical solution is adopted in this specification:

[0007] This specification provides a method for canary deployment, which is applied to a canary deployment system. The canary deployment system is a microservice architecture system that deploys multiple microservices with calling relationships, including new version microservices and old version microservices. The method includes:

[0008] Retrieve the traffic splitting rules corresponding to the target microservice among multiple microservices;

[0009] Based on the traffic received by the new version of the target microservice corresponding to the target microservice in the current time period, the running data of the new version of the target microservice in the current time period is obtained;

[0010] Based on the operational data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented to determine the traffic received by the new version target microservice in the next time period. Furthermore, the operational data of the new version target microservice in the next time period is obtained. Based on the operational data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented again. This process is repeated until the new version target microservice receives all the traffic, thus completing the canary release of the new version target microservice.

[0011] Optionally, the runtime data includes: call duration;

[0012] Based on the operational data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented to determine the traffic received by the new version target microservice in the next time period. Furthermore, the operational data of the new version target microservice in the next time period is obtained, and based on the operational data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented again. This process is repeated until the new version target microservice receives all traffic, thus completing the canary release of the new version target microservice. This includes:

[0013] If the call duration of the preset TP metric for the new version target microservice in the current time period meets the traffic segmentation rule corresponding to the target microservice, the traffic received by the target microservice is segmented to determine the traffic received by the new version target microservice in the next time period. Furthermore, the call duration of the preset TP metric for the new version target microservice in the next time period is obtained. Based on the call duration of the preset TP metric for the new version target microservice in the next time period and the traffic segmentation rule corresponding to the target microservice, the traffic received by the target microservice is segmented again. This process is repeated until the new version target microservice receives all the traffic, thus completing the canary release of the new version target microservice.

[0014] Optionally, the operational data includes: status information;

[0015] Based on the operational data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented to determine the traffic received by the new version target microservice in the next time period. Furthermore, the operational data of the new version target microservice in the next time period is obtained, and based on the operational data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented again. This process is repeated until the new version target microservice receives all traffic, thus completing the canary release of the new version target microservice. This includes:

[0016] If the status information returned by the new version of the target microservice in the current time period satisfies the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, the traffic received by the new version of the target microservice in the next time period is determined, and the status information returned by the new version of the target microservice in the next time period is further obtained. Based on the status information returned by the new version of the target microservice in the next time period and the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, and so on, until the new version of the target microservice receives all the traffic, so as to complete the canary release of the new version of the target microservice.

[0017] Optionally, a first Envoy gateway is deployed between the grayscale release system and the external network;

[0018] Before obtaining the traffic splitting rules corresponding to the target microservice among multiple microservices, the method further includes:

[0019] Identify whether the multiple microservices are in the blacklist; if not, set a "to be deployed" label for the multiple microservices that are not in the blacklist.

[0020] Based on the deployment tags of the multiple microservices, a second Envoy gateway corresponding to the multiple microservices is deployed so that the multiple microservices can receive and send traffic based on the second Envoy gateway.

[0021] Optionally, before obtaining the traffic splitting rules corresponding to the target microservice among multiple microservices, the method further includes:

[0022] Add a traffic blocking flag to the new versions of the aforementioned microservices;

[0023] According to the preset initial traffic splitting ratio, the traffic received by the multiple microservices is split to determine the traffic received by the new version of the multiple microservices and the traffic received by the old version of the multiple microservices.

[0024] Retrieve the traffic splitting rules corresponding to the target microservice among multiple microservices, including:

[0025] Obtain the traffic splitting rules corresponding to the target microservice among multiple microservices, and remove the prohibited traffic flags on the new version of the multiple microservices.

[0026] Optionally, the method further includes:

[0027] After the new version of the target microservice receives all the traffic, the old version of the target microservice is suspended.

[0028] Check if the new version of the target microservice is abnormal. If so, redirect all traffic received by the target microservice to the old version of the target microservice.

[0029] Optionally, the microservice architecture is built on Kubernetes and uses Istio for traffic management.

[0030] This specification provides an apparatus for canary deployment, which is applied to a canary deployment system. The canary deployment system is a microservice architecture system that deploys multiple microservices with calling relationships, including new version microservices and old version microservices. The apparatus includes:

[0031] The acquisition module is used to acquire the traffic splitting rules corresponding to the target microservice among multiple microservices;

[0032] The module is used to obtain the running data of the new version of the target microservice in the current time period based on the traffic received by the new version of the target microservice corresponding to the target microservice in the current time period;

[0033] The calculation module is used to perform traffic segmentation on the traffic received by the target microservice based on the running data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, determine the traffic received by the new version target microservice in the next time period, and further calculate the running data of the new version target microservice in the next time period. Based on the running data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the module performs traffic segmentation on the traffic received by the target microservice, and so on, until the new version target microservice receives all the traffic, so as to complete the canary release of the new version target microservice.

[0034] This specification provides an electronic device, including a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus;

[0035] The memory stores machine-readable instructions, and the processor executes the above-described canary release method by invoking the machine-readable instructions.

[0036] This specification provides a machine-readable storage medium storing machine-readable instructions, which, when called and executed by a processor, implement the above-described canary release method.

[0037] The above-mentioned technical solutions adopted in this specification can achieve the following beneficial effects:

[0038] In this specification, the canary release system can automatically adjust the traffic ratio between the old and new versions of code based on the runtime data of the target microservice and the corresponding traffic splitting rules. This avoids errors caused by human intervention and improves the efficiency of canary releases. Attached Figure Description

[0039] The accompanying drawings, which are included to provide a further understanding of this specification and form part of this specification, illustrate exemplary embodiments and are used to explain this specification, but do not constitute an undue limitation thereof. In the drawings:

[0040] Figure 1 This is a flowchart illustrating an exemplary embodiment of a grayscale publishing method;

[0041] Figure 2 This is a schematic diagram illustrating a traffic segmentation method as an exemplary embodiment;

[0042] Figure 3 This is a schematic diagram illustrating a gateway deployment as an exemplary embodiment;

[0043] Figure 4 This is an exemplary embodiment illustrating a grayscale release flowchart;

[0044] Figure 5 This is a structural diagram of an electronic device containing a grayscale publishing device, as shown in an exemplary embodiment.

[0045] Figure 6 This is a structural diagram of an apparatus for grayscale publishing, as shown in an exemplary embodiment. Detailed Implementation

[0046] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0047] It should be noted that the steps of the corresponding methods are not necessarily performed in the order shown and described in this specification in other embodiments. In some other embodiments, the methods may include more or fewer steps than described in this specification. Furthermore, a single step described in this specification may be broken down into multiple steps in other embodiments; and multiple steps described in this specification may be combined into a single step in other embodiments.

[0048] To enable those skilled in the art to better understand the technical solutions in the embodiments of this specification, the relevant technologies involved in the embodiments of this specification will be briefly described below.

[0049] Kubernetes: Kubernetes is a portable, scalable, open-source platform for managing containerized workloads and services, facilitating declarative configuration and automation. Kubernetes boasts a large and rapidly growing ecosystem. Kubernetes services, support, and tools are widely available.

[0050] Istio: An open-source service mesh that provides the essential operational and management elements needed for distributed microservice architectures.

[0051] Sidecar: Istio injects a sidecar into a specified service to act as a network proxy and intercept incoming and outgoing traffic.

[0052] Envoy is an L7 proxy and communication bus designed specifically for large-scale modern SOA (Service-Oriented Architecture) architectures. It is small in size and high in performance.

[0053] Currently, we use a canary release approach, deploying both the new and old versions of the application code simultaneously to the real business environment. Some users continue using the old version, while others start with the new one. If no issues arise with the new code, the rollout is gradually expanded until all users are using it. This allows us to gather timely user feedback, improve product functionality and quality, and minimize the impact of product upgrades on the user base.

[0054] However, existing canary release processes often rely on technicians manually adjusting the traffic ratio between the old and new versions of the code. This approach is not only inefficient, but also increases the possibility of errors due to human intervention.

[0055] Based on this, this specification proposes a technical solution to automatically adjust the traffic ratio between the old and new versions of code according to the runtime data of the new version of the target microservice and the corresponding traffic splitting rules. This avoids errors caused by human intervention and improves the efficiency of canary releases.

[0056] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0057] Figure 1 This is a flowchart illustrating an exemplary embodiment of a canary release method, which specifically includes the following steps:

[0058] S100: Retrieves the traffic splitting rules corresponding to the target microservice among multiple microservices.

[0059] S102: Based on the traffic received by the new version of the target microservice corresponding to the target microservice in the current time period, obtain the running data of the new version of the target microservice in the current time period.

[0060] S104: Based on the running data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, perform traffic segmentation on the traffic received by the target microservice, determine the traffic received by the new version target microservice in the next time period, and further calculate the running data of the new version target microservice in the next time period. Based on the running data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, perform traffic segmentation on the traffic received by the target microservice, and so on, until the new version target microservice receives all the traffic, so as to complete the canary release of the new version target microservice.

[0061] In the embodiments described in this specification, the canary release system is a system employing a microservice architecture, which can be built on Kubernetes. Kubernetes can be deployed in a microserver cluster, which consists of multiple microserver hardware units, each with an operating system installed.

[0062] The canary release system deploys multiple microservices with call relationships. For example, there is a chained call between microservices A, B, and C; microservices A and B must be called sequentially before microservice C can be called. Furthermore, the microservices include both new and old versions. For instance, microservice A includes old version V1 and new version V2. Similarly, microservice B includes old version V1 and new version V2. Microservice C includes both old version V1 and new version V2.

[0063] In practice, existing canary release processes often rely on technicians manually adjusting the ratio of traffic between the old and new versions of the code. This approach is not only inefficient, but also increases the possibility of errors due to human intervention.

[0064] In the embodiments described in this specification, the canary release system can obtain the traffic splitting rules corresponding to the target microservice among multiple microservices. The traffic splitting rules mentioned here can refer to the allocation of a proportion of traffic to the new version microservice according to the set rules when the running data of the new version microservice meets the set rules.

[0065] Then, the canary release system can obtain the runtime data of the new version of the target microservice during the current time period based on the traffic received by the new version of the target microservice during the current time period. The runtime data mentioned here can include data such as call duration and status information.

[0066] Next, the canary release system can segment the traffic received by the target microservice based on its operational data in the current time period and the corresponding traffic segmentation rules. This determines the traffic received by the target microservice in the next time period. Furthermore, it obtains the operational data of the target microservice in the next time period and segments the traffic received by it again based on this data and the corresponding traffic segmentation rules. This process continues until the target microservice receives all traffic, thus completing the canary release of the target microservice. Specifically, as follows... Figure 2 As shown.

[0067] Figure 2 This is a schematic diagram illustrating a grayscale release, as shown in an exemplary embodiment.

[0068] exist Figure 2 In this example, there is a chain of calls between microservices A, B, and C. Microservice A includes: old version A-V1 and new version A-V2. Similarly, microservice B includes: old version B-V1 and new version B-V2. Microservice C includes: old version C-V1 and new version C-V2.

[0069] The canary release system can allocate traffic to microservices A, B, and C according to a preset initial traffic allocation ratio. For example, the traffic allocation for old versions A-V1, B-V1, and C-V1 is 90%, while the traffic allocation for new versions A-V2, B-V2, and C-V2 is 10%.

[0070] If the running data of the new version microservices A-V2 in the next time period meets the traffic splitting rules corresponding to microservice A, the traffic ratio of the new version microservices A-V2 can be adjusted to 30%. Similarly, the traffic ratio of the new version microservices B-V2 and C-V2 can be adjusted, and so on, until the new version target microservice receives all the traffic, thus completing the canary release of the new version target microservice.

[0071] As demonstrated by the above embodiments, the canary release system can automatically adjust the traffic ratio between the old and new versions of code based on the runtime data of the target microservice and the traffic splitting rules corresponding to the target microservice. This avoids errors caused by human intervention and improves the efficiency of canary releases.

[0072] It's important to note that when traffic passes through a new version of a microservice, a tag corresponding to that new version is added to the traffic. This tagging allows for traffic tracking, facilitating traffic management and monitoring. For example, when traffic passes through new version microservice A-V2, a tag corresponding to new version microservice A-V2 is added. Then, when the traffic passes through new version microservice B-V2, a tag corresponding to new version microservice B-V2 is added. Finally, the traffic received by new version microservice C-V2 includes tags corresponding to both new version microservices A-V2 and B-V2, thus indicating that the traffic has passed through both new version microservices A-V2 and B-V2.

[0073] In the embodiments described in this specification, the runtime data may include: call duration.

[0074] If the call duration of the new version target microservice in the current time period meets the traffic segmentation rules corresponding to the target microservice, the canary release system can segment the traffic received by the target microservice to determine the traffic received by the new version target microservice in the next time period, and further obtain the call duration of the new version target microservice in the next time period based on the call duration of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice. This process is repeated until the new version target microservice receives all traffic, thus completing the canary release of the new version target microservice.

[0075] The TP metric describes a value that exceeds a specified percentage in a set of data. For example, TP90 refers to the 90th percentile of call durations sorted from smallest to largest within a statistical period. Similarly, TP50 refers to the 50th percentile of call durations sorted from smallest to largest within a statistical period. Total number of calls * number of metrics = corresponding TP metric value.

[0076] For example, when the preset TP metric is TP99, the traffic splitting rules can include: if the call duration of the new version target microservice's TP99 metric is between (10, 50) ms, allocate 50% of the traffic to the new version target microservice. If the call duration of the new version target microservice's TP99 metric is between (0, 10) ms, allocate 100% of the traffic to the new version target microservice.

[0077] If the call duration of the new version target microservice in the current time period is 23ms according to the TP99 metric, which meets the traffic splitting rules, then 50% of the traffic will be allocated to the new version target microservice.

[0078] If we further obtain that the TP99 call duration of the new version target microservice in the next time period is 9ms, which meets the traffic splitting rules, we will allocate 100% of the traffic to the new version target microservice to complete the canary release of the new version target microservice.

[0079] In the embodiments described in this specification, the operating data may further include: status information.

[0080] If the status information returned by the new version of the target microservice in the current time period meets the traffic splitting rules corresponding to the target microservice, the canary release system can perform traffic splitting on the traffic received by the target microservice, determine the traffic received by the new version of the target microservice in the next time period, and further obtain the status information returned by the new version of the target microservice in the next time period. Based on the status information returned by the new version of the target microservice in the next time period and the traffic splitting rules corresponding to the target microservice, the system can perform traffic splitting on the traffic received by the target microservice, and so on, until the new version of the target microservice receives all the traffic, thus completing the canary release of the new version of the target microservice.

[0081] The status information can refer to status codes, such as 200 indicating a successful request, 404 indicating a resource not found, and 500 indicating a server error.

[0082] For example, traffic splitting rules could include: if the percentage of successful requests returned by the new version of the target microservice exceeds 90%, allocate 50% of the traffic to the new version of the target microservice. If the percentage of successful requests returned by the new version of the target microservice exceeds 99%, allocate 100% of the traffic to the new version of the target microservice.

[0083] If the percentage of status codes returned by the new version target microservice in the current time period that indicate a successful request exceeds 90%, thus meeting the traffic splitting rules, then 50% of the traffic will be allocated to the new version target microservice.

[0084] If, in the next time period, the percentage of status codes indicating successful requests in the new version of the target microservice exceeds 90%, and the traffic splitting rules are met, 100% of the traffic will be allocated to the new version of the target microservice to complete the canary release of the new version of the target microservice.

[0085] It should be noted that this manual does not impose any restrictions on the rules for splitting traffic.

[0086] In practical applications, north-south traffic typically refers to traffic entering the system from the external network and traffic flowing from the system to the external network. This usually involves requirements such as security, authentication, and authorization. East-west traffic typically refers to traffic between various microservices within the system. This usually involves requirements such as service discovery, load balancing, fault recovery, and fine-grained traffic control.

[0087] Therefore, microservice architectures typically employ different technologies to manage north-south and east-west traffic. For example, NGINX might be used to manage north-south traffic, while Kong API Gateway manages east-west traffic. Alternatively, NGINX could be used for north-south traffic, and Kafka for east-west traffic. However, combining different technologies increases development difficulty and operational complexity, and seamless collaboration between them is often challenging. Furthermore, these technologies require developers to modify existing code, increasing development time and resource consumption.

[0088] In the embodiments described in this specification, the canary release system can use Istio for traffic management. Istio can protect communication between microservices through authentication and authorization, and configure and control communication between microservices through failover, fault injection, and routing rules.

[0089] Istio can deploy a first Envoy gateway between the canary release system and the external network, and deploy a second Envoy gateway corresponding to each of the multiple microservices within the canary release system. Specifically, as follows... Figure 3 As shown.

[0090] Figure 3 This is a schematic diagram illustrating a gateway deployment as an exemplary embodiment.

[0091] exist Figure 3 In this system, traffic management between the old version microservice A-V1, the new version microservice A-V2, the old version microservice B-V1, the new version microservice B-V2, the old version microservice C-V1, and the new version microservice C-V2 is all handled through the second Envoy gateway. Traffic management between the canary release system and the external network is handled through the first Envoy gateway.

[0092] As can be seen from the above embodiments, the second Envoy gateway corresponding to each microservice manages the traffic between the microservices to control their communication. This eliminates the need for code modifications to the microservices themselves, reducing development time and resource consumption. Furthermore, both north-south and east-west traffic utilize the Envoy gateway, lowering development difficulty and operational complexity, and enabling seamless collaboration.

[0093] It's important to note that Istio is platform-independent, meaning it can run in various environments, including cloud, on-premises, and Kubernetes. Examples include microservice deployments on Kubernetes and microservices running on a single virtual machine.

[0094] In practical applications, core microservices often carry critical service logic, and any changes can have a significant impact on the operation of the entire system. Updating core microservices may introduce new risks. Therefore, it is advisable to include core microservices in a blacklist. This approach ensures that these core microservices are not affected by untested updates, thereby protecting the entire system from potential negative impacts.

[0095] Of course, technical staff can also determine other microservices that need to be added to the blacklist based on the service logic.

[0096] In the embodiments described in this specification, the canary deployment system can identify whether multiple microservices are in a blacklist. If not, it sets a "to be deployed" label for multiple microservices that are not in the blacklist.

[0097] Then, the canary deployment system can deploy a second Envoy gateway corresponding to multiple microservices based on the deployment tags of multiple microservices, so that multiple microservices can receive and send traffic based on the second Envoy gateway.

[0098] As can be seen from the above embodiments, managing the traffic of microservices through the second Envoy gateway reduces the risk of new versions of microservices and improves the stability and reliability of the system.

[0099] In practical applications, new versions of microservices may have undiscovered problems or defects. If a new version of a service receives traffic without sufficient testing and verification, it may lead to system instability and affect user experience.

[0100] In the embodiments described in this specification, the canary release system can add a traffic-blocking flag to a new version of a microservice across multiple microservices.

[0101] Then, the canary release system can divide the traffic received by multiple microservices according to the preset initial traffic division ratio, and determine the traffic received by the new version of the multiple microservices and the traffic received by the old version of the multiple microservices.

[0102] Next, the canary release system can remove the prohibited traffic flags on the new version of the microservices after obtaining the traffic splitting rules corresponding to the target microservices in multiple microservices.

[0103] As can be seen from the above embodiments, the canary release system can control the initial traffic ratio received by new and old versions of microservices, reducing the risks that new versions of microservices may bring.

[0104] In practical applications, there is still a risk of anomalies after the new version of the microservice receives all traffic. If the old version of the microservice is removed, the entire service may be interrupted if the new version of the microservice encounters a problem, which will affect the user experience.

[0105] In the embodiments described in this specification, the canary release system can suspend the old version of the target microservice after the new version of the target microservice has received all traffic.

[0106] Then, the canary release system can detect whether the new version of the target microservice is abnormal. If so, it will redirect all traffic received by the target microservice to the old version of the target microservice.

[0107] As demonstrated by the above embodiments, when a new version of the microservice encounters an anomaly, traffic can be switched back to the old version of the microservice. This avoids a decline in user experience due to service interruption.

[0108] Figure 4 This is an exemplary embodiment illustrating a flowchart of a grayscale release.

[0109] exist Figure 4 In the context of canary deployment systems, traffic restriction flags can be added to new versions of multiple microservices.

[0110] Secondly, according to the preset initial traffic splitting ratio, the traffic received by multiple microservices is split to determine the traffic received by the new version of multiple microservices and the traffic received by the old version of multiple microservices, and the prohibited traffic flags on the new version of multiple microservices are removed.

[0111] Then, the traffic splitting rules corresponding to the target microservice among the multiple microservices are obtained and distributed to the Collector in the second Envoy gateway corresponding to the multiple microservices. The Collector can be a plugin running in Envoy to collect request metrics.

[0112] Next, the canary release system can automatically adjust the traffic ratio between the new and old versions of the code based on the runtime data of the target microservice in the new version and the traffic splitting rules corresponding to the target microservice.

[0113] Finally, the canary release system can suspend the old version of the target microservice after the new version has received all traffic. If the new version of the microservice encounters an anomaly, traffic can be switched back to the old version.

[0114] As can be seen from the above methods, the canary release system can automatically adjust the traffic ratio between the old and new versions of code based on the runtime data of the target microservice and the corresponding traffic splitting rules. This avoids errors caused by human intervention and improves the efficiency of canary releases.

[0115] Furthermore, Istio can deploy a first Envoy gateway between the canary release system and the external network, and deploy a second Envoy gateway corresponding to each microservice within the canary release system. This eliminates the need to modify the code of the microservices themselves, reducing development time and resource consumption. Moreover, both north-south and east-west traffic utilize the Envoy gateway, reducing development difficulty and operational complexity, and enabling seamless collaboration.

[0116] Corresponding to the embodiments of the grayscale publishing method described above, this specification also provides an embodiment of a grayscale publishing apparatus.

[0117] Please see Figure 5 , Figure 5 This is a structural diagram of an electronic device containing a grayscale release device, as illustrated in an exemplary embodiment. At the hardware level, the device includes a processor 502, an internal bus 504, a network interface 506, memory 508, and non-volatile memory 510, and may also include other necessary hardware. One or more embodiments of this specification can be implemented in software, for example, the processor 502 reads the corresponding computer program from the non-volatile memory 510 into memory 508 and then runs it. Of course, besides software implementation, one or more embodiments of this specification do not exclude other implementation methods, such as logic devices or a combination of hardware and software, etc. That is to say, the execution entity of the following processing flow is not limited to individual logic units, but can also be hardware or logic devices.

[0118] Please see Figure 6 , Figure 6 This is a structural diagram illustrating an exemplary embodiment of a grayscale publishing apparatus. This grayscale publishing apparatus can be microserviced as... Figure 5 The electronic device shown implements the technical solution of this specification. The device may include:

[0119] The acquisition module 600 is used to acquire the traffic splitting rules corresponding to the target microservice among multiple microservices;

[0120] The module 602 is used to obtain the running data of the new version of the target microservice in the current time period based on the traffic received by the new version of the target microservice corresponding to the target microservice in the current time period.

[0121] The calculation module 604 is used to perform traffic segmentation on the traffic received by the target microservice based on the running data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, determine the traffic received by the new version target microservice in the next time period, and further calculate the running data of the new version target microservice in the next time period. Based on the running data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented again, and so on, until the new version target microservice receives all the traffic, so as to complete the canary release of the new version target microservice.

[0122] Optionally, the runtime data includes: call duration; the calculation module 604 is specifically used to perform traffic segmentation on the traffic received by the target microservice if the call duration of the preset TP indicator of the new version target microservice in the current time period meets the traffic segmentation rule corresponding to the target microservice, determine the traffic received by the new version target microservice in the next time period, and further obtain the call duration of the preset TP indicator of the new version target microservice in the next time period. Based on the call duration of the preset TP indicator of the new version target microservice in the next time period and the traffic segmentation rule corresponding to the target microservice, the traffic received by the target microservice is segmented, and so on, until the new version target microservice receives all traffic, so as to complete the canary release of the new version target microservice.

[0123] Optionally, the runtime data includes: status information; the calculation module 604 is specifically used to perform traffic segmentation on the traffic received by the target microservice if the status information returned by the new version of the target microservice in the current time period satisfies the traffic segmentation rules corresponding to the target microservice, determine the traffic received by the new version of the target microservice in the next time period, and further obtain the status information returned by the new version of the target microservice in the next time period. Based on the status information returned by the new version of the target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented, and so on, until the new version of the target microservice receives all the traffic, so as to complete the canary release of the new version of the target microservice.

[0124] Optionally, the acquisition module 600, which deploys a first Envoy gateway between the canary release system and the external network, is further configured to identify whether the multiple microservices are in the blacklist; if not, set a deployment tag for the multiple microservices not in the blacklist; and based on the deployment tags of the multiple microservices, deploy a second Envoy gateway corresponding to the multiple microservices, so that the multiple microservices receive and send traffic based on the second Envoy gateway.

[0125] Optionally, the acquisition module 600 is further configured to add a traffic prohibition flag to the new version of the multiple microservices; perform traffic segmentation on the traffic received by the multiple microservices according to a preset initial traffic segmentation ratio, determine the traffic received by the new version of the multiple microservices and the traffic received by the old version of the multiple microservices; acquire the traffic segmentation rule corresponding to the target microservice among the multiple microservices, and remove the traffic prohibition flag from the new version of the multiple microservices.

[0126] Optionally, the calculation module 604 is further configured to suspend the old version target microservice after the new version target microservice receives all traffic; detect whether the new version target microservice is abnormal, and if so, allocate all traffic received by the target microservice to the old version target microservice.

[0127] Optionally, the microservice architecture is built on Kubernetes and uses Istio for traffic management.

[0128] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0129] Based on the same concept as the methods described above, this specification also provides an electronic device, including: a processor; a memory for storing processor-executable instructions; wherein the processor performs the steps of the method as described in any of the above embodiments by executing the executable instructions.

[0130] Based on the same concept as the methods described above, this specification also provides a computer-readable storage medium having computer instructions stored thereon that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0131] Based on the same concept as the methods described above, this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the methods as described in any of the above embodiments.

[0132] It should be understood that although the terms first, second, third, etc., may be used to describe various information in one or more embodiments of this specification, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first information may also be referred to as second information without departing from the scope of one or more embodiments of this specification, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "in response to a determination," or "when," or "in the event of a determination."

[0133] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the protection scope of one or more embodiments of this specification.

Claims

1. A method for canary deployment, the method being applied to a canary deployment system, the canary deployment system being a microservice architecture system, the canary deployment system deploying multiple microservices with calling relationships, the microservices including new version microservices and old version microservices; the method comprising: Retrieve the traffic splitting rules corresponding to the target microservice among multiple microservices; Based on the traffic received by the new version of the target microservice corresponding to the target microservice in the current time period, the running data of the new version of the target microservice in the current time period is obtained; Based on the running data of the new version target microservice in the current time period and the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, the traffic received by the new version target microservice in the next time period is determined, and the running data of the new version target microservice in the next time period is further obtained. Based on the running data of the new version target microservice in the next time period and the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, and so on, until the new version target microservice receives all the traffic, so as to complete the canary release of the new version target microservice. The operational data includes: call duration; The step of segmenting traffic received by the target microservice based on the running data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice includes: If the call duration of the new version target microservice in the current time period meets the traffic splitting rule corresponding to the target microservice, the target traffic ratio corresponding to the time interval is obtained according to the time interval of the traffic splitting rule that the call duration of the preset TP indicator in the current time period meets, and the traffic received by the target microservice is split based on the target traffic ratio.

2. The method as described in claim 1, characterized in that, The step involves dividing the traffic received by the target microservice based on its operational data in the next time period and the corresponding traffic division rules, and so on, until the target microservice receives all the traffic, thus completing the canary release of the target microservice. This includes: Based on the call duration of the new version target microservice in the next time period according to the preset TP indicator and the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, and so on, until the new version target microservice receives all the traffic, so as to complete the canary release of the new version target microservice.

3. The method as described in claim 1, characterized in that, The operational data includes: status information; Based on the operational data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented to determine the traffic received by the new version target microservice in the next time period. Furthermore, the operational data of the new version target microservice in the next time period is obtained, and based on the operational data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the traffic received by the target microservice is segmented again. This process is repeated until the new version target microservice receives all traffic, thus completing the canary release of the new version target microservice. This includes: If the status information returned by the new version of the target microservice in the current time period satisfies the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, the traffic received by the new version of the target microservice in the next time period is determined, and the status information returned by the new version of the target microservice in the next time period is further obtained. Based on the status information returned by the new version of the target microservice in the next time period and the traffic splitting rules corresponding to the target microservice, the traffic received by the target microservice is split, and so on, until the new version of the target microservice receives all the traffic, so as to complete the canary release of the new version of the target microservice.

4. The method as described in claim 1, characterized in that, The canary release system is connected to the external network via a first Envoy gateway. Before obtaining the traffic splitting rules corresponding to the target microservice among multiple microservices, the method further includes: Identify whether the multiple microservices are in the blacklist; if not, set a "to be deployed" label for the multiple microservices that are not in the blacklist. Based on the deployment tags of the multiple microservices, a second Envoy gateway corresponding to the multiple microservices is deployed so that the multiple microservices can receive and send traffic based on the second Envoy gateway.

5. The method as described in claim 1, characterized in that, Before obtaining the traffic splitting rules corresponding to the target microservice among multiple microservices, the method further includes: Add a traffic blocking flag to the new versions of the aforementioned microservices; According to the preset initial traffic splitting ratio, the traffic received by the multiple microservices is split to determine the traffic received by the new version of the multiple microservices and the traffic received by the old version of the multiple microservices. Retrieve the traffic splitting rules corresponding to the target microservice among multiple microservices, including: Obtain the traffic splitting rules corresponding to the target microservice among multiple microservices, and remove the prohibited traffic flags on the new version of the multiple microservices.

6. The method as described in claim 1, characterized in that, The method further includes: After the new version of the target microservice receives all the traffic, the old version of the target microservice is suspended. Check if the new version of the target microservice is abnormal. If so, redirect all traffic received by the target microservice to the old version of the target microservice.

7. The method as described in claim 1, characterized in that, The microservice architecture is built on Kubernetes and uses Istio for traffic management.

8. A device for grayscale publishing, characterized in that, The device is applied to a canary release system, which is a microservice architecture system. The canary release system deploys multiple microservices with calling relationships, including new version microservices and old version microservices. The device includes: The acquisition module is used to acquire the traffic splitting rules corresponding to the target microservice among multiple microservices; The module is used to obtain the running data of the new version of the target microservice in the current time period based on the traffic received by the new version of the target microservice corresponding to the target microservice in the current time period; The calculation module is used to perform traffic segmentation on the traffic received by the target microservice based on the running data of the new version target microservice in the current time period and the traffic segmentation rules corresponding to the target microservice, determine the traffic received by the new version target microservice in the next time period, and further calculate the running data of the new version target microservice in the next time period. Based on the running data of the new version target microservice in the next time period and the traffic segmentation rules corresponding to the target microservice, the module performs traffic segmentation on the traffic received by the target microservice, and so on, until the new version target microservice receives all the traffic, so as to complete the canary release of the new version target microservice. The operational data includes: call duration; The calculation module is specifically used to: if the call duration of the new version target microservice in the current time period meets the traffic splitting rule corresponding to the target microservice, obtain the target traffic ratio corresponding to the time interval according to the time interval of the traffic splitting rule that the call duration of the preset TP indicator in the current time period meets, and split the traffic received by the target microservice based on the target traffic ratio.

9. An electronic device, characterized in that, It includes a communication interface, a processor, a memory, and a bus, wherein the communication interface, the processor, and the memory are interconnected via the bus; The memory stores machine-readable instructions, and the processor executes the method according to any one of claims 1 to 7 by invoking the machine-readable instructions.

10. A machine-readable storage medium, characterized in that, The machine-readable storage medium stores machine-readable instructions, which, when invoked and executed by a processor, implement the method described in any one of claims 1 to 7.

Images