Stable service upgrading method and system under large-scale micro-service system

Abstract

The invention relates to the technical field of micro-services, and provides a stable service upgrading method and system under a large-scale micro-service system.The method comprises the steps that the number N of formal service nodes carrying a formal service version is calculated, user traffic is divided into N parts according to the number N of the formal service nodes, and one part of traffic is distributed to each formal service node; dividing lanes of the formal service nodes, wherein the number of the formal service nodes of each lane is not greater than the number of the gray service nodes; switching the traffic of the formal service node of one lane into the gray service node, and upgrading the formal service node of the lane from which the traffic is switched; and when the formal service node of the lane of which the flow is cut out is completely upgraded, switching in the flow of the formal service node of the next lane, and iteratively executing until the formal service nodes of all lanes are completely upgraded, thereby completing the service upgrading process. Smooth upgrading and efficient resource utilization of the system are realized through smooth switching of user traffic and improvement of a load balancing algorithm.

Description

Technical Field

[0001] The present disclosure relates to the technical field related to microservices, and more specifically, to a method and system for smoothly upgrading services in a large-scale microservice system. Background Art

[0002] The statements in this section merely provide background information related to the present disclosure and do not necessarily constitute prior art.

[0003] With the widespread application of large-scale microservice architecture in modern enterprises, the version management and upgrade mechanism of microservice system has become the key for enterprises to maintain high availability and high-performance services. In order to achieve non-stop upgrades, most enterprises adopt a two-layer architecture with a formal layer (production environment) and a grayscale verification layer (verification environment). The formal layer is used to provide stable and reliable services for most users, while the grayscale verification layer is used for version verification of small-scale users. Usually, grayscale verification guides some user requests to the grayscale service node through selective coloring to test and verify the stability and compatibility of the new version. The conventional upgrade process is that the enterprise runs the current stable service version on the formal service node and updates the grayscale verification layer service to the new version. In order to avoid affecting the user experience, the grayscale verification layer service will switch user traffic to the formal layer before upgrading. After the upgrade is completed, part of the user traffic will be cut into the grayscale service node through selective coloring to test the stability of the new version in a small range. Once the grayscale layer is verified to be correct, the system will switch user traffic from the formal service node to the grayscale service node and start the version upgrade of the formal service node. After the upgrade is complete, user traffic is switched back from the grayscale service node to the official service node to ensure that all users are running on the new version. This strategy is more efficient in small-scale microservice systems because traffic fluctuations are small and the switching process resource overhead is low.

[0004] According to the conventional upgrade method, it is only applicable to the situation where there are relatively few product microservices and the resource usage is not high. If there are many product modules and the user access QPS is high, in order to support user access, the gray service resources often need to be aligned with the formal service resources to avoid service instability caused by traffic carrying differences, but it will relatively bring higher financial pressure to the enterprise. Regarding the update and upgrade of major versions of products under the microservice system, in order to maintain the consistency of service versions, when upgrading the overall gray version, all user traffic will be switched to the formal service node. When upgrading the formal service version, all user traffic will be switched to the gray service node. In this upgrade process, there will often be sudden changes in user traffic of gray or formal service nodes. Especially when upgrading the formal service version, the gray service node service has a sudden increase in access traffic in a short period of time, resulting in a backlog of service requests and slow system. Although the number of gray service nodes can be expanded, it will inevitably consume more resources, resulting in low resource utilization. Summary of the invention

[0005] In order to solve the above problems, the present disclosure proposes a method and system for smooth service upgrade in a large-scale microservice system, which realizes smooth upgrade of the system and efficient resource utilization through smooth switching of user traffic and improvement of load balancing algorithm, and solves the problems of sudden traffic flow and low resource utilization during version upgrade in large-scale microservice system.

[0006] In order to achieve the above objectives, the present disclosure adopts the following technical solutions:

[0007] One or more embodiments provide a method for smoothly upgrading services in a large-scale microservice system, including the following steps:

[0008] Calculate the number of official service nodes N equipped with the official service version, divide the user traffic into N parts according to the number of official service nodes N, and allocate one part of the traffic to each official service node;

[0009] Divide the lanes of official service nodes. The number of official service nodes in each lane should not exceed the number of grayscale service nodes.

[0010] Cut the traffic of the formal service node of a lane to the grayscale service node, and upgrade the formal service node of the lane that cuts out the traffic;

[0011] When the official service node of the lane that cuts out traffic is upgraded, the traffic of the official service node of the next lane is cut in, and the official service node of the next lane is upgraded. The iterative execution is carried out until the official service nodes of all lanes are upgraded, completing the service upgrade process.

[0012] One or more embodiments provide a system for smoothly upgrading services in a large-scale microservice system, including:

[0013] The traffic division module is configured to calculate the number N of official service nodes equipped with the official service version, divide the user traffic into N parts according to the number N of official service nodes, and allocate one part of the traffic to each official service node;

[0014] The node division module is configured to divide the lanes of the formal service nodes, and the number of formal service nodes in each lane is not greater than the number of grayscale service nodes;

[0015] The traffic control module is configured to switch the traffic of the formal service node of a lane to the grayscale service node, and upgrade the formal service node of the lane from which the traffic is switched out;

[0016] The iterative control module is configured to cut in the traffic of the formal service node of the next lane and upgrade the formal service node of the next lane when the formal service node of the lane that cuts out the traffic is upgraded. The iterative execution is performed until the formal service nodes of all lanes are upgraded, thus completing the service upgrade process.

[0017] An electronic device includes a memory and a processor, and computer instructions stored in the memory and running on the processor. When the computer instructions are run by the processor, the steps of the above-mentioned method for smooth service upgrade in a large-scale microservice system are completed.

[0018] A computer-readable storage medium is used to store computer instructions. When the computer instructions are executed by a processor, the steps in the above-mentioned method for smooth service upgrade in a large-scale microservice system are completed.

[0019] Compared with the prior art, the present invention has the following beneficial effects:

[0020] The present invention divides system services into different lanes according to service versions, upgrades each lane one by one, and chooses a suitable opportunity to change grayscale traffic users according to the completion of the upgrade to achieve the purpose of smooth traffic switching. During the upgrade process, production resources are fully utilized, and it is not required that all user traffic be switched to grayscale service nodes or formal service nodes. Instead, reasonable resources of the entire environment are fully utilized. During the entire upgrade process, traffic is switched layer by layer according to the number of divided versions, and the overall traffic switching is relatively smooth. At the same time, during the upgrade of a single version, services that have not been upgraded and services that have completed the upgrade continue to provide services to the outside world. By dividing the lanes to control traffic switching, the traffic is controlled within the service carrying limit, which avoids resource waste on the one hand, and prevents traffic surges that exceed the service bearing capacity on the other hand, thereby improving service utilization efficiency.

[0021] The advantages of the present disclosure and the advantages of additional aspects will be described in detail in the following specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings constituting a part of the present disclosure are used to provide a further understanding of the present disclosure. The exemplary embodiments of the present disclosure and the description thereof are used to explain the present disclosure but do not constitute a limitation of the present disclosure.

[0023] Figure 1 is a flowchart of the upgrade method of Embodiment 1 of the present disclosure;

[0024] Figure 2 is a schematic diagram of the starting state of the upgrade method in the example of Embodiment 1 of the present disclosure;

[0025] Figure 3 is a schematic diagram of an intermediate state of an upgrade method in an example of Embodiment 1 of the present disclosure;

[0026] Figure 4 is a schematic diagram of the end state of the upgrade method in the example of Embodiment 1 of the present disclosure;

[0027] Figure 5 This is a deployment example diagram of the upgrade method of Embodiment 1 of the present disclosure. DETAILED DESCRIPTION

[0028] The present disclosure is further described below in conjunction with the accompanying drawings and embodiments.

[0029] It should be noted that the following detailed descriptions are exemplary and are intended to provide further explanation of the present disclosure. Unless otherwise specified, all technical and scientific terms used herein have the same meanings as those commonly understood by those skilled in the art to which the present disclosure belongs.

[0030] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit exemplary embodiments according to the present disclosure. As used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form. In addition, it should be understood that when the terms "comprising" and / or "including" are used in this specification, it indicates the presence of features, steps, operations, devices, components and / or combinations thereof. It should be noted that, in the absence of conflict, the various embodiments in the present disclosure and the features in the embodiments can be combined with each other. The embodiments will be described in detail below in conjunction with the accompanying drawings.

[0031] Technical term explanation:

[0032] Formal layer: refers to the system environment that is officially running in the production environment, which is used to provide stable services for all real users. The formal layer handles normal daily user traffic. Because it is directly facing users, it requires high stability and fast response speed. The version will not be changed easily, and it is usually updated to the formal layer after the function has been fully verified.

[0033] Grayscale verification layer: It is a service environment for testing new versions. It is mainly used for small-scale user traffic testing to find potential failures before the official release. The grayscale verification layer is an independent environment from the official layer, but can be selectively accessed by some users. When developers want to launch a new version, they first allocate a small amount of user traffic to the grayscale verification layer. If a problem occurs, they can immediately switch back to the official layer.

[0034] Tagging: is the process of marking user traffic, that is, marking (labeling) the access requests of some users so that the system can distinguish which requests will be routed to the grayscale verification layer and which requests will be routed to the formal layer. Through tagging, the system can divert the traffic of some users.

[0035] Grayscale service node: a specific service instance or server deployed in the grayscale verification layer. Each grayscale service node runs a new version of the service under test. During the grayscale test, part of the colored user traffic will be directed to these grayscale service nodes.

[0036] Formal service nodes: refers to specific service instances or servers running in the formal layer. These nodes are responsible for processing requests from real users.

[0037] Service instance: refers to the running unit of a microservice. Each instance is usually an independent application process responsible for processing user requests. For example, a microservice may run multiple instances on multiple servers to carry high concurrent user traffic.

[0038] Microservices: refers to splitting an application into multiple independent services, each of which is independently deployed, upgraded, and run.

[0039] Example 1

[0040] In the technical solutions disclosed in one or more embodiments, Figures 1 to 5 As shown, a method for smoothly upgrading services in a large-scale microservice system includes the following steps:

[0041] Step 1: Calculate the number of official service nodes N equipped with the official service version, divide the user traffic into N parts according to the number of official service nodes N, and allocate one part of the traffic to each official service node;

[0042] Step 2: Divide the lanes of formal service nodes. The number of formal service nodes in each lane should not be greater than the number of grayscale service nodes.

[0043] Step 3: Cut the traffic of the formal service node of a lane to the grayscale service node, and upgrade the formal service node of the lane that cuts out the traffic;

[0044] Step 4: When the official service node of the lane that cuts out traffic is upgraded, the traffic of the official service node of the next lane is cut in, and the official service node of the next lane is upgraded. The process is iterated until the official service nodes of all lanes are upgraded, completing the service upgrade process.

[0045] In this embodiment, system services are divided into different lanes according to service versions, and are upgraded one by one according to the lanes. According to the completion of the upgrade, the appropriate opportunity is selected to change the grayscale traffic users to achieve the purpose of smooth traffic switching. During the upgrade process, production resources are fully utilized, and it is not required that all user traffic be switched to grayscale service nodes or formal service nodes. Instead, reasonable resources of the entire environment are fully utilized. During the entire upgrade process, traffic is switched layer by layer according to the number of divided versions, and the overall traffic switching is relatively smooth. At the same time, during the upgrade of a single version, services that have not been upgraded and services that have completed the upgrade continue to provide services to the outside world. By dividing the lanes to control traffic switching, the traffic is controlled within the service carrying limit. On the one hand, resource waste is avoided, and on the other hand, traffic surges that exceed the service bearing capacity are prevented, thereby improving service utilization efficiency.

[0046] In step 1, the number of official service nodes N equipped with the official service version is obtained, and the user traffic is divided into N parts according to the number of official service nodes N, and each official service node is allocated one part of the traffic;

[0047] Step 1 is to perform version preprocessing on the overall environment service instance, and divide the request traffic into N equal parts by taking the modulus of the user ID hash;

[0048] In the above scheme, the range of the modulo result R is [0, N-1], and each value corresponds to a traffic group. User request traffic is evenly distributed. According to the hash value of the user ID, each user is stably assigned to a group. Since the hash function has the characteristic of uniform distribution, the distribution of users in N groups will also be as uniform as possible.

[0049] In one achievable implementation method, the number of official service nodes N of the official service version is the minimum number of single nodes deployed for a single service;

[0050] For example, if a product has three microservices, then each service can be deployed with one node in production to provide all product functions to the outside world. However, this single-node mode is unstable, and the production environment is often deployed with multiple nodes. Assuming that each service is deployed with three instances, it is equivalent to deploying three single-node products to form a cluster, where each single-node version is a completed product, so the traffic can be divided into three parts. When the traffic is switched to formal switching, the production node is divided into N parts according to versioning. If each service of the formal node is deployed with three single nodes, then N is 3. If some have three single nodes and some have two single nodes, then N is 2. N takes the maximum number of parts that can be divided according to the "versioning" idea, that is, the minimum value of a single service deployed with a single node;

[0051] In step 2, the lanes of the formal service nodes are divided. The number of formal service nodes in a specific lane can be 1 to n, where n is the number of grayscale service nodes;

[0052] The preferred technical solution is to set the number of service nodes in a single lane to be the same as the number of grayscale service nodes, that is, n;

[0053] For example, in the versioning of the upgrade environment, suppose the microservice system has 100 microservices, and each microservice deploys 2 official service nodes to just carry the access requests of all current users. In order to be able to perform grayscale verification on the pre-release version of the product, each microservice node needs to deploy at least one additional grayscale node, so 100 grayscale nodes are required, so the total number of instances in the service environment is 300. The 300 services are versioned, each version contains 100 services, and each service contains only one instance, so there are 3 service versions, two official service versions, and one grayscale service version, and each version can provide overall services to the outside world. The grayscale version can carry 50% of user requests. The nodes of the official service version are allocated into two lanes, and the number of nodes in each lane is 100;

[0054] In step 3, the traffic of the formal service node of a lane is cut into the grayscale service node, and the formal service node of the lane that cuts out the traffic is upgraded. The specific upgrade method can adopt any of the following methods:

[0055] Method 1: Upgrade the official service nodes in the lane one by one according to the version. When one official service node is upgraded, the traffic of the official service nodes in the lane that has not been upgraded is cut in;

[0056] Specifically, initially, one portion of traffic is forwarded to the grayscale version service of the grayscale service node, and N-1 portions of traffic are forwarded to the formal version service of the formal service node; when upgrading the formal version, multiple microservice formal versions are upgraded serially, and after each version is upgraded, 1 / N of the traffic is switched to the grayscale version, where the grayscale version is the microservice version to be updated;

[0057] Method 2: When upgrading the official service nodes in the lane, all the official service nodes in the lane are upgraded in parallel according to the version, and the traffic of the official service nodes in the lane that have not been upgraded is cut into the upgraded official service nodes;

[0058] A further technical solution is to improve the instance discovery algorithm of the load balancer, ignore the gray version identifier of the service during the upgrade, distinguish the gray version from the official version according to the version level, determine the version to be upgraded, and add all services of the same version to the service selection list (choose list) for routing selection;

[0059] In this embodiment, during the upgrade, the instance discovery algorithm of the load balancer is rewritten so that it can dynamically perceive the service version when requesting routing, and distinguish between grayscale versions and official versions based on the version level. In this way, the system no longer relies on fixed grayscale identification, but automatically identifies grayscale and official services based on the level of service versions.

[0060] A further technical solution is to shield user traffic during the upgrade of a single node service, and take the service instance offline from the registration center before the upgrade. When it is detected that there is no service instance of the corresponding node in the load balancer cache, the service is stopped and the upgrade is performed after a set delay.

[0061] Optionally, the delay time is determined according to the specific system and can be set to seconds. Different systems have different requirements for service request time in production environments. Taking 2 seconds as an example, in order to ensure that the upgraded service no longer provides services to the outside world, the service upgrade can be delayed for 2 seconds after the service goes offline.

[0062] Specifically, in this embodiment, method 1 can be used, and the process of upgrading the methods one by one is as follows: Figures 2 to 4 As shown, assuming that the official service version is upgraded, that is, the official service version of each official service node is upgraded to be consistent with the gray version. According to the user information carried by the front-end request, the user ID is modulo the number of official versions, and the traffic is divided into N groups according to possible values. One group of traffic is forwarded to the gray version service, and the traffic of group N-1 is forwarded to the official version service. Initially, the official version services of the two lanes carry 50% of the traffic respectively, and then the official service nodes are upgraded one by one according to the version. When upgrading one of the official service versions, the traffic carrying limit of the official version of the production service at this time decreases from 100% to 50%, while the traffic carrying limit of the gray service version increases from 0% to 100%. At the same time, due to the version assimilation characteristics of the load balancer, the upgrade of the entire version is gradual and smooth. Every time a formal version is upgraded, an additional traffic is forwarded to the gray version, and the traffic of the formal version is reduced by one group. That is, after the formal version of a lane is upgraded (version 1.59 in the figure), the formal version is upgraded to the gray version (version 1.60 in the figure), and 50% of the traffic on the formal version is forwarded to the gray version. At this time, there are two lanes for the gray version, with a carrying capacity of 100% and actual user traffic of 100%; there is one formal version with a carrying capacity of 50% and actual user traffic of 0%. Finally, the remaining formal versions are upgraded, and the gray version traffic carrying capacity increases from 100% to 150%.

[0063] In the above scheme of this embodiment, the services are divided into lanes, and different lanes carry a part of the user traffic. The upgrade only affects the lane being upgraded, and other lanes will not stop providing services. This solves the traffic mutation caused by the switching of all user traffic to grayscale or formal nodes. At the same time, the services in the upgraded lanes are not all unavailable, but only the services being upgraded are unavailable. Due to the influence of version assimilation, the service instances that have not been upgraded or have been upgraded can still be added to the matching list of the load balancer to continue to provide services to the outside world. Therefore, the entire upgrade process only reaches the critical point at a certain moment of traffic switching but is still within the load limit. After that, the entire upgrade process tends to be stable.

[0064] Optionally, when upgrading microservices on a single node, the number of upgraded services processed concurrently on a single server does not exceed the number of CPU cores.

[0065] In this embodiment, when upgrading services in batches, it is necessary to consider the discreteness of the upgraded services to avoid the concentration of service upgrades on a single server and prevent excessive service upgrades on one server from causing excessive CPU utilization in a short period of time, resulting in reduced stability of other microservices.

[0066] A specific implementation method is to install the above-mentioned service stable upgrade method under a large-scale microservice system on the operation and maintenance platform, and the operation and maintenance platform operates the cloud service assets through a springboard, such as Figure 5 As shown;

[0067] Access the jump server through a dedicated operation and maintenance platform, and execute relevant script commands on the jump server to achieve the purpose of upgrading microservices. In this way, the control logic of service upgrade is moved to the operation and maintenance platform for processing;

[0068] like Figures 2 to 4 For a specific example, services with the same version will be treated as the same group. Suppose the product version is upgraded from 1.59 to 1.60. At the beginning, the grayscale node is version 1.60 and the official node is version 1.59. The official nodes are divided into N groups. The upgraded version of each group is consistent with the grayscale node service version. At this time, when the traffic requests grayscale, it will automatically find the official node of the same version, and then all of them are regarded as "grayscale nodes". When the official traffic monitors the version difference, it will automatically eliminate the upgraded official nodes. That is, with the version upgrade, the actual number of grayscale nodes increases, and the allocated traffic increases step by step. The actual number of official nodes decreases, and the allocated traffic also decreases step by step. Finally, all services are upgraded to the same version. At this time, regardless of grayscale traffic or official traffic, they all exist as a whole.

[0069] like Figure 2As shown, it is a schematic diagram of the initial state of the stable upgrade of the microservice in this embodiment. Before the service upgrade, the service instance is versioned. The current official version service carries 100% of the requests, and the gray node service has no requests;

[0070] like Figure 3 As shown, at the beginning of the upgrade, the user traffic is divided according to the number of service nodes of the official version. The divided user traffic is equal to the number of official versions. First, a portion of the traffic is migrated to the grayscale service node, and then the official versions are upgraded one by one. Both the grayscale service version and the official service version services carry user traffic. The service being upgraded does not participate in traffic distribution, but other non-upgraded services or upgraded service instances of the version where the upgraded service is located still participate in traffic distribution;

[0071] like Figure 4 As shown in the figure, after upgrading a formal version, switch another portion of traffic to the grayscale node. The current grayscale version traffic carries 100% of the requests, and the remaining formal versions have no requests. Then, the remaining formal versions are upgraded in batches.

[0072] The key to the overall solution of this embodiment is to divide the service traffic into equal proportions and versions to achieve smooth switching of production traffic. It is foreseeable that the larger the microservice group, the more service instance nodes, the finer the granularity of the divided traffic, and the smoother the traffic switching. The more microservice instances there are, the finer the granularity of the traffic division, thereby achieving smoother traffic switching and a more stable upgrade process. In principle, a large scale of microservices means a large number of microservice instances (number of nodes), and user traffic is usually divided according to the number of microservice instances. For example, if there are 100 instances, each instance can theoretically carry 1% of the traffic; if there are 10 instances, each instance needs to carry 10% of the traffic. The more instances there are, the smaller the proportion of traffic carried by a single instance, so the impact on the entire system during traffic switching is smaller, and the upgrade is smoother.

[0073] When the number of instances is small, when traffic is migrated to the grayscale node, the traffic migrated each time accounts for a large proportion. For example, if there are 10 instances and 1 instance is migrated each time, it is equivalent to migrating 10% of the traffic. Sudden fluctuations in traffic may cause service performance fluctuations and even exceed the carrying capacity of the grayscale node.

[0074] When the number of instances is large, for example, there are 1,000 instances, and one instance is migrated each time, only 0.1% of the traffic is migrated.

[0075] In this way, the system impact caused by a single traffic migration is very small, the user experience is hardly affected, and the traffic switching process is smoother.

[0076] Example 2

[0077] Based on Example 1, this embodiment provides a service stable upgrade system in a large-scale microservice system, including:

[0078] The traffic division module is configured to calculate the number N of official service nodes equipped with the official service version, divide the user traffic into N parts according to the number N of official service nodes, and allocate one part of the traffic to each official service node;

[0079] The node division module is configured to divide the lanes of the formal service nodes, and the number of formal service nodes in each lane is not greater than the number of grayscale service nodes;

[0080] The traffic control module is configured to switch the traffic of the formal service node of a lane to the grayscale service node, and upgrade the formal service node of the lane from which the traffic is switched out;

[0081] The iterative control module is configured to cut in the traffic of the formal service node of the next lane and upgrade the formal service node of the next lane when the formal service node of the lane that cuts out the traffic is upgraded. The iterative execution is performed until the formal service nodes of all lanes are upgraded, thus completing the service upgrade process.

[0082] It should be noted here that the various modules in this embodiment correspond one-to-one to the various steps in Example 1, and the specific implementation process is the same, which will not be repeated here.

[0083] Example 3

[0084] This embodiment provides an electronic device, including a memory and a processor, and computer instructions stored in the memory and running on the processor. When the computer instructions are executed by the processor, the steps of the method for smooth service upgrade in a large-scale microservice system in Example 1 are completed.

[0085] Example 4

[0086] This embodiment provides a computer-readable storage medium for storing computer instructions. When the computer instructions are executed by a processor, the steps of the method for smooth service upgrade in a large-scale microservice system in Embodiment 1 are completed.

[0087] The above description is only a preferred embodiment of the present disclosure and is not intended to limit the present disclosure. For those skilled in the art, the present disclosure may have various modifications and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present disclosure shall be included in the protection scope of the present disclosure.

[0088] Although the above describes the specific implementation methods of the present disclosure in conjunction with the accompanying drawings, it is not intended to limit the scope of protection of the present disclosure. Technical personnel in the relevant field should understand that on the basis of the technical solution of the present disclosure, various modifications or variations that can be made by those skilled in the art without creative work are still within the scope of protection of the present disclosure.

Claims

1. A method for stable service upgrade in a large-scale microservice system, characterized in that: The steps include: Calculate the number of official service nodes N equipped with the official service version, divide the user traffic into N parts according to the number of official service nodes N, and allocate one part of the traffic to each official service node; Divide the lanes of official service nodes. The number of official service nodes in each lane should not exceed the number of grayscale service nodes. Cut the traffic of the formal service node of a lane to the grayscale service node, and upgrade the formal service node of the lane that cuts out the traffic; When the official service node of the lane that cuts out traffic is upgraded, the traffic of the official service node of the next lane is cut in, and the official service node of the next lane is upgraded. The iterative execution is carried out until the official service nodes of all lanes are upgraded, completing the service upgrade process.

2. The method for smoothly upgrading services in a large-scale microservice system according to claim 1, characterized in that: The request traffic is divided into N equal parts by taking the modulus of the user ID hash.

3. The method for smoothly upgrading services in a large-scale microservice system according to claim 1, characterized in that: Set the number of service nodes for a single lane to be the same as the number of grayscale service nodes.

4. The method for smoothly upgrading services in a large-scale microservice system according to claim 1, characterized in that: When upgrading the official service nodes in the lane, they will be upgraded one by one according to the version. When one official service node is upgraded, the traffic of the official service nodes in the lane that has not been upgraded will be cut in.

5. The method for smoothly upgrading services in a large-scale microservice system according to claim 1, characterized in that: When upgrading the formal service nodes in the lane, all formal service nodes in the lane will be upgraded in parallel according to the version, and the traffic of the formal service nodes in the lane that have not been upgraded will be cut into the upgraded formal service nodes.

6. The method for smoothly upgrading services in a large-scale microservice system according to claim 1, characterized in that: Improve the instance discovery algorithm of the load balancer, ignore the grayscale version identification of the service during the upgrade, distinguish the grayscale version and the official version according to the version level, determine the version to be upgraded, and add all services of the same version to the service selection list for routing selection.

7. The method for smoothly upgrading services in a large-scale microservice system according to claim 1, characterized in that: For the upgrade of a single node service, user traffic is blocked during the upgrade. The service instance is taken offline from the registration center before the upgrade. When it is detected that there is no service instance of the corresponding node in the load balancer cache, the service is stopped and the upgrade is performed after a set delay. When upgrading microservices on a single node, the number of concurrently processed upgrade services on a single server should not exceed the number of CPU cores.

8. A service stable upgrade system in a large-scale microservice system, characterized in that: include: The traffic division module is configured to calculate the number N of official service nodes equipped with the official service version, divide the user traffic into N parts according to the number N of official service nodes, and allocate one part of the traffic to each official service node; The node division module is configured to divide the lanes of the formal service nodes, and the number of formal service nodes in each lane is not greater than the number of grayscale service nodes; The traffic control module is configured to switch the traffic of the formal service node of a lane to the grayscale service node, and upgrade the formal service node of the lane from which the traffic is switched out; The iterative control module is configured to cut in the traffic of the formal service node of the next lane and upgrade the formal service node of the next lane when the formal service node of the lane that cuts out the traffic is upgraded. The iterative execution is performed until the formal service nodes of all lanes are upgraded, thus completing the service upgrade process.

9. An electronic device, characterized in that: The invention comprises a memory and a processor, and computer instructions stored in the memory and executed on the processor. When the computer instructions are executed by the processor, the steps of the method for smoothly upgrading services in a large-scale microservice system described in any one of claims 1 to 7 are completed.

10. A computer-readable storage medium, characterized in that: Used to store computer instructions, which, when executed by a processor, complete the steps of a method for smooth service upgrade in a large-scale microservice system as described in any one of claims 1 to 7.

Images