Service version updating method and device, electronic equipment and storage medium

Abstract

The present disclosure provides a service version updating method and device, electronic equipment and storage medium, relates to the technical field of computers, and particularly relates to micro-service technology. The implementation scheme is as follows: a service version updating method based on blue-green publishing comprises the following steps: in response to updating a first service version deployed on a blue instance set currently undertaking traffic to a second service version, creating a green instance set to synchronize the first service version on the green instance set; updating the first service version deployed on the blue instance set to the second service version by using the green instance set as a transit instance set for temporarily undertaking traffic; and in response to determining that the updating of the second service version is successful, removing the green instance set.

Description

Technical Field

[0001] This disclosure relates to the field of computer technology, and more particularly to microservice technology, specifically to a service version update method, apparatus, electronic device, computer-readable storage medium, and computer program product based on blue-green publishing. Background Technology

[0002] In recent years, the development of cloud-native microservice architecture has brought greater efficiency to software or application development. High deployment efficiency directly impacts this efficiency. Blue-green deployment is a solution proposed in recent years to improve deployment efficiency. Currently, research on blue-green deployment remains a focus of the industry, and improvements are still needed in many aspects such as generality, efficiency, and observability.

[0003] The methods described in this section are not necessarily methods that had been previously conceived or adopted. Unless otherwise specified, no method described in this section should be assumed to be prior art simply because it is included in this section. Similarly, unless otherwise specified, the issues mentioned in this section should not be considered to be accepted in any prior art. Summary of the Invention

[0004] This disclosure provides a service version update method, apparatus, electronic device, computer-readable storage medium, and computer program product based on blue-green publishing.

[0005] According to one aspect of this disclosure, a service version update method based on blue-green deployment is provided, comprising: in response to updating a first service version deployed on a blue instance set currently handling traffic to a second service version, creating a green instance set to synchronize the first service version on the green instance set; updating the first service version deployed on the blue instance set to the second service version by using the green instance set as a relay instance set for temporarily handling traffic; and in response to determining that the update of the second service version is successful, removing the green instance set.

[0006] According to another aspect of this disclosure, a service version update apparatus based on blue-green deployment is provided, comprising: a green instance creation module configured to create a green instance set to synchronize the first service version on the green instance set in response to updating a first service version deployed on a set of blue instances currently handling traffic to a second service version; a service version update module configured to update the first service version deployed on the blue instance set to the second service version by using the green instance set as a relay instance set for temporarily handling traffic; and a green instance removal module configured to remove the green instance set in response to determining that the update of the second service version is successful.

[0007] According to another aspect of this disclosure, an electronic device is provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the method described above.

[0008] According to another aspect of this disclosure, a non-transitory computer-readable storage medium is provided storing computer instructions, wherein the computer instructions are used to cause a computer to perform the methods described above.

[0009] According to another aspect of this disclosure, a computer program product is provided, including a computer program, wherein the computer program, when executed by a processor, implements the method described above.

[0010] According to one or more embodiments of this disclosure, the efficiency of updating service versions can be improved.

[0011] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0012] The accompanying drawings exemplify embodiments and form part of the specification, serving together with the textual description to explain exemplary implementations of the embodiments. The illustrated embodiments are for illustrative purposes only and do not limit the scope of the claims. Throughout the drawings, the same reference numerals refer to similar but not necessarily identical elements.

[0013] Figure 1 A schematic diagram of an exemplary system in which various methods described herein may be implemented according to embodiments of this disclosure is shown;

[0014] Figure 2 A flowchart of a service version update method according to an embodiment of this disclosure is shown;

[0015] Figure 3 A flowchart illustrating the process of updating a first service version deployed on a blue instance set to a second service version according to an embodiment of this disclosure is shown;

[0016] Figure 4 A schematic diagram of a service version update method according to an embodiment of the present disclosure is shown;

[0017] Figure 5 A schematic diagram illustrating an example of a monitoring curve at the instance granularity according to an embodiment of the present disclosure is shown;

[0018] Figure 6A structural block diagram of a service version update apparatus according to an embodiment of the present disclosure is shown;

[0019] Figure 7 A structural block diagram of a service version update apparatus according to another embodiment of the present disclosure is shown;

[0020] Figure 8 A structural block diagram of an exemplary electronic device that can be used to implement embodiments of the present disclosure is shown. Detailed Implementation

[0021] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0022] In this disclosure, unless otherwise stated, the use of terms such as "first," "second," etc., to describe various elements is not intended to limit the positional, temporal, or importance relationships of these elements; such terms are merely used to distinguish one element from another. In some examples, the first element and the second element may refer to the same instance of that element, while in other cases, based on the context, they may refer to different instances.

[0023] The terminology used in the description of the various examples described in this disclosure is for the purpose of describing particular examples only and is not intended to be limiting. Unless the context explicitly indicates otherwise, an element may be one or more unless the number of elements is specifically limited. Furthermore, the term "and / or" as used in this disclosure covers any one of the listed items and all possible combinations thereof.

[0024] In blue-green deployment technologies, a traditional approach involves instance-based horizontal scaling, cycling between blue and green instance sets. For example, for the first update, with the current service version and traffic residing in the blue instance set, the next service version is deployed to the newly expanded green instance set, and traffic is switched from the blue instance set to the green instance set. Afterward, the blue instance set is scaled down so that no service version is deployed on it. For the second update, a similar approach is used: the next service version is deployed to the blue instance set, and traffic is switched from the green instance set to the blue instance set. Then, the green instance set is scaled down so that no service version is deployed on it. This cycle continues between the blue and green instance sets.

[0025] However, this traditional blue-green deployment method still has shortcomings that urgently need improvement. On one hand, because each version involves both new instance deployment and traffic switching, the monitoring curve for a specific instance will terminate during the update process. For example, for the first update as described above, when the next service version is deployed to the green instance set and traffic is switched from the blue instance set to the green instance set, the monitoring curve for the blue instance will terminate, while the monitoring curve for the green instance will begin. This inconsistency in the monitoring curve may make it impossible to verify whether the updated service version is safe or stable. Furthermore, because blue and green instances are alternately scaled down during the update process, log data loss can occur. Additionally, deploying a new instance requires downloading the service version data to the new instance's local hard drive and then loading it into its memory. These two processes are time-consuming and affect the overall update speed.

[0026] Another traditional blue-green deployment approach involves alternating replacements between two processes on the same instance. However, this approach requires the support of a management process to host the business processes, which necessitates architectural modifications to the business modules. This intrusive method is costly and lacks versatility.

[0027] To address the problems existing in the traditional blue-green deployment method, this disclosure provides a service version update method based on blue-green deployment.

[0028] Before describing the method according to embodiments of this disclosure in detail, firstly, in conjunction with Figure 1 The description includes exemplary systems in which the various methods and apparatuses described herein may be implemented.

[0029] Figure 1 A schematic diagram of an exemplary system 100 in which the various methods and apparatus described herein can be implemented according to embodiments of this disclosure is shown. Reference Figure 1 The system 100 includes one or more client devices 101, 102, 103, 104, 105 and 106, a server 120, and one or more communication networks 110 coupling the one or more client devices to the server 120. The client devices 101, 102, 103, 104, 105 and 106 can be configured to execute one or more applications.

[0030] In embodiments of this disclosure, server 120 may run one or more services or software applications that enable the execution of a service version update method according to embodiments of this disclosure.

[0031] In some embodiments, server 120 may also provide other services or software applications, which may include non-virtual and virtual environments. In some embodiments, these services may be provided as web-based services or cloud services, such as to users of client devices 101, 102, 103, 104, 105, and / or 106 under a Software as a Service (SaaS) model.

[0032] exist Figure 1 In the configuration shown, server 120 may include one or more components that implement the functions performed by server 120. These components may include software components, hardware components, or combinations thereof that can be executed by one or more processors. Users operating client devices 101, 102, 103, 104, 105, and / or 106 can sequentially interact with server 120 using one or more client applications to utilize the services provided by these components. It should be understood that various different system configurations are possible and may differ from system 100. Therefore, Figure 1 This is an example of a system used to implement the various methods described herein, and is not intended to be limiting.

[0033] Users can access the services provided by various service versions according to embodiments of this disclosure via client devices 101, 102, 103, 104, 105 and / or 106. The client devices can provide an interface enabling users of the client devices to interact with them. The client devices can also output information to users via this interface. Although... Figure 1 Only six client devices are described, but those skilled in the art will understand that this disclosure can support any number of client devices.

[0034] Client devices 101, 102, 103, 104, 105, and / or 106 may include various types of computer devices, such as portable handheld devices, general-purpose computers (such as personal computers and laptops), workstation computers, wearable devices, smart screen devices, self-service terminal devices, service robots, gaming systems, thin clients, various messaging devices, sensors, or other sensing devices. These computer devices can run various types and versions of software applications and operating systems, such as Microsoft Windows, Apple iOS, UNIX-like operating systems, Linux or Linux-like operating systems (such as Google Chrome OS); or include various mobile operating systems, such as Microsoft Windows Mobile OS, iOS, Windows Phone, and Android. Portable handheld devices may include cellular phones, smartphones, tablets, personal digital assistants (PDAs), etc. Wearable devices may include head-mounted displays (such as smart glasses) and other devices. Gaming systems may include various handheld gaming devices, internet-enabled gaming devices, etc. Client devices are capable of executing various applications, such as various internet-related applications, communication applications (such as email applications), short message service (SMS) applications, and can use various communication protocols.

[0035] Network 110 can be any type of network well known to those skilled in the art, and can use any of a variety of available protocols (including but not limited to TCP / IP, SNA, IPX, etc.) to support data communication. By way of example only, one or more networks 110 can be a local area network (LAN), an Ethernet-based network, a token ring network, a wide area network (WAN), the Internet, a virtual network, a virtual private network (VPN), an intranet, an extranet, a blockchain network, a public switched telephone network (PSTN), an infrared network, a wireless network (e.g., Bluetooth, WIFI), and / or any combination of these and / or other networks.

[0036] Server 120 may include one or more general-purpose computers, special-purpose server computers (e.g., PC (personal computer) servers, UNIX servers, mid-range servers), blade servers, mainframe computers, server clusters, or any other suitable arrangement and / or combination. Server 120 may include one or more virtual machines running a virtual operating system, or other computing architectures involving virtualization (e.g., one or more flexible pools of logical storage devices that can be virtualized to maintain virtual storage devices for servers). In various embodiments, server 120 may run one or more services or software applications that provide the functionality described below.

[0037] The computing unit in server 120 can run one or more operating systems, including any of the aforementioned operating systems and any commercially available server operating system. Server 120 can also run any of a variety of additional server applications and / or middleware applications, including HTTP servers, FTP servers, CGI servers, JAVA servers, database servers, etc.

[0038] In some implementations, server 120 may include one or more applications to analyze and merge data feeds and / or event updates received from users of client devices 101, 102, 103, 104, 105 and / or 106. Server 120 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client devices 101, 102, 103, 104, 105 and / or 106.

[0039] In some implementations, server 120 can be a server for a distributed system or a server integrated with blockchain. Server 120 can also be a cloud server, or an intelligent cloud computing server or intelligent cloud host with artificial intelligence technology. A cloud server is a host product in the cloud computing service system, designed to address the shortcomings of traditional physical hosts and Virtual Private Server (VPS) services, such as high management difficulty and weak business scalability.

[0040] System 100 may also include one or more databases 130. In some embodiments, these databases may be used to store data and other information. For example, one or more of the databases 130 may be used to store information such as audio files and video files. Databases 130 may reside in various locations. For example, a database used by server 120 may be local to server 120, or it may be located away from server 120 and may communicate with server 120 via a network-based or dedicated connection. Databases 130 may be of different types. In some embodiments, the database used by server 120 may be, for example, a relational database. One or more of these databases may store, update, and retrieve data from and from the databases in response to commands.

[0041] In some embodiments, one or more of the databases 130 may also be used by an application to store application data. The databases used by the application may be of different types, such as key-value stores, object stores, or regular stores supported by a file system.

[0042] Figure 1The system 100 can be configured and operated in various ways to enable the application of the various methods and apparatus described in this disclosure.

[0043] The following describes in detail a service version update method based on blue-green publishing according to embodiments of this disclosure.

[0044] Figure 2 A flowchart of a service version update method 200 according to an embodiment of this disclosure is shown. Figure 2 As shown, the service version update method 200 includes steps S202, S204 and S206.

[0045] In step S202, in response to updating the first service version deployed on the blue instance set currently handling traffic to the second service version, a green instance set is created to synchronize the first service version on the green instance set.

[0046] In the example, each of the blue and green instances can include a server, for example, implemented through a computer cluster. The log data of each of the blue and green instances can be persistently stored on a remote cloud storage device, such as a cloud disk, to prevent data loss. The set of blue instances can include at least one blue instance, and the set of green instances can include a number of green instances equal to the number of the at least one blue instance. The first service version and the second service version can be different service versions of software or applications (e.g., instant messaging tools, search engines, etc.) provided to users via a server, wherein the second service version can be an updated version compared to the first service version. Each service version can have its own version number, and the version number of the updated service version can be incremented. For example, the version number of the initial service version can be V0, and the version number of the next service version can be V1, and so on.

[0047] In the example, taking the initial state where an initial service version (e.g., version number V0, hereinafter referred to as initial service version V0) is deployed on the blue instance collection and is handling traffic as an example, the traffic handled by the blue instance collection can include usage traffic generated by users using services provided by initial service version V0. Initial service version V0 can be a secure or stable service version. At this point, due to reasons such as periodic or irregular software or application updates, it is necessary to update the initial service version V0, which is the first service version, to a second service version (e.g., version number V1, hereinafter referred to as new service version V1). This process can also be called the deployment of the new service version. Since the security or stability of the new service version V1 is unknown, it needs to be verified during the deployment process.

[0048] In the example, creating a collection of green instances may include requesting server resources for the collection. This process can also be referred to as green instance onboarding. Synchronizing the first service version on the collection of green instances may include deploying the same first service version on the collection as that deployed on the blue instances.

[0049] Here, "synchronization" of green instances in step S202 means deploying the same service version on the green instance set as on the blue instance set. Unlike the conventional methods described above, in the service version update method 200 according to embodiments of this disclosure, the green instance set acts as a relay instance set. This means that during the update process, the updated service version is not deployed on the green instance set, but rather used to temporarily take over traffic from the blue instance set to assist in the service version update on the blue instance set.

[0050] In step S204, by using the green instance set as a relay instance set for temporarily accepting traffic, the first service version deployed on the blue instance set is updated to the second service version.

[0051] In the example, taking the initial service version V0 currently deployed on the blue instance set as an example, during the update process, since the green instance set synchronized the initial service version V0 in step S202, the green instance set can be used as a relay instance set to temporarily switch the traffic on the blue instance set to the green instance set, so that the initial service version V0 deployed on the blue instance set can be updated to the new service version V1.

[0052] In the example, the update process may include verifying the security or stability of the second service version after updating the first service version deployed on the blue instance set to the second service version. For example, the success of the second service version update can be verified by comparing the metrics reflected in the instance-level monitoring curves for the blue instances before and after the update. For instance, the monitoring curves may reflect changes in metrics such as traffic volume, response time, or CPU usage over time. If the verification passes, it indicates that the second service version update is successful, and the green instance set is no longer needed; if the verification fails, it indicates that the second service version may be an insecure or unstable service version, and therefore it may be necessary to stop the deployment of this service version.

[0053] For reference, in the traditional method described above, because the service versions deployed on the blue instance set and the traffic handled are migrated to the green instance set, the monitoring curves also change from monitoring curves for blue instances to monitoring curves for green instances, making the monitoring curves inconsistent. In some cases, if the blue instances include slower servers and the green instances include faster servers, if the actual response speed slows down after an update, this slowdown might be offset by the faster servers in the green instances, making it impossible to see the actual slowdown in response speed from the monitoring curve metrics. Therefore, it is desirable to achieve consistency in the monitoring curves at the instance-level granularity.

[0054] Here, unlike the conventional methods described above, in the service version update method 200 according to embodiments of this disclosure, since the green instance set is used as a transit instance set to temporarily handle traffic, it can be ensured that the updated service version and the final state of the traffic always reside on the blue instance set. This ensures that the monitoring curve at the instance granularity for the blue instances does not terminate during the update process, thereby providing the continuity of the monitoring curve. This continuity, in turn, ensures that the updated service version can be correctly analyzed to determine whether it possesses security or stability.

[0055] In step S206, in response to the confirmation that the update of the second service version was successful, the green instance set is removed.

[0056] In the example, removing the green instance set may include releasing the server resources requested in step S202 for creating the green instance set. This process may also be referred to as green instance deprecation.

[0057] Therefore, in the service version update method according to the embodiments of this disclosure, by changing the status of the green instance set in the update process and using it as a relay instance set for temporarily accepting traffic, it can be ensured that the updated service version and the final state of the traffic are always on the blue instance set. This ensures the consistency of the monitoring curve at the instance granularity for blue instances, thereby ensuring that the updated service version can be correctly analyzed for security or stability based on the consistent monitoring curve, thus improving the efficiency of updating the service version.

[0058] Furthermore, in the service version update method according to the embodiments of this disclosure, since the non-intrusive method of scaling instances is used, the architecture of the business process can be maintained without changing it, thereby ensuring the versatility of the method.

[0059] According to some embodiments, in step S202, creating a green instance set to synchronize the first service version on the green instance set may include: loading the image data of the first service version from the cloud storage device onto the memory of the corresponding green instance in the green instance set to start the service corresponding to the first service version.

[0060] In the example, image data for each service version (e.g., from a unified image repository) can be pre-stored on a remote cloud storage device such as a cloud disk. Therefore, the green instance collection can directly load the image data for the first service version from the cloud disk into memory for execution.

[0061] This method avoids the process of downloading image data to the local hard drive when synchronizing the first service version of the green instance collection, thus saving time in the overall update process. This provides additional time efficiency when the image data is large.

[0062] The following will combine Figure 3 A detailed description of an embodiment of the method for updating the first service version deployed on the blue instance set to the second service version in step S204.

[0063] Figure 3 A flowchart illustrating a method 300 for updating a first service version deployed on a blue instance set to a second service version according to an embodiment of this disclosure is shown. According to some embodiments, method 300 may correspond to a combination of... Figure 1 Step S204.

[0064] like Figure 3 As shown, method 300 may include steps S302, S304, S306, S308 and S310.

[0065] According to some embodiments, in step S302, a first update operation may be performed for a portion of the blue instances in the blue instance set. In step S304, it may be determined whether the first update operation was successful. In step S306, in response to determining that the first update operation was successful, a second update operation may be performed for the remaining blue instances in the blue instance set.

[0066] In the example, in step S302, the subset of blue instances used for the first update operation may include canary instances. The first update operation can also be referred to as a low-volume switching operation, therefore the subset of blue instances can also be referred to as low-volume instances. These blue instances can be selected randomly or through a specific method. For example, all blue instances in the blue instance set can be named and sorted alphabetically. Then, a certain percentage (e.g., 30%) of these sorted blue instances can be selected as canary instances for the first update operation.

[0067] In the example, the second update operation in step S306 can also be called a full flow switching operation, so the remaining blue instances can also be called full (all) instances.

[0068] In this embodiment, by dividing the overall update process into two separate update operations, it is possible to conduct a small-scale test on the updated second service version, so as to avoid excessive losses due to the lack of security or stability of the second service version.

[0069] According to some embodiments, in step S302, performing the first update operation for a portion of the blue instances in the blue instance set may further include steps S3022, S3024, and S3026. In step S3022, traffic on the portion of the blue instances can be switched to a portion of the green instances in the green instance set (e.g., a portion of the green instances in the green instance set corresponding to the number of the portion of the blue instances). In step S3024, a second service version can be deployed on the portion of the blue instances. In step S3026, traffic switched to the portion of the green instances can be switched back to the portion of the blue instances.

[0070] In the example, the traffic switching process performed in steps S3022 and S3026 can be implemented using a naming service. This naming service can be used to switch traffic from one IP port to another; that is, it can be used to switch traffic from some blue instances to some green instances, and to switch traffic from those green instances back to those blue instances. This traffic switching process can achieve instantaneous switching without any time delay.

[0071] In the example, in step S3024, deploying the second service version on a subset of blue instances may include loading the image data of the second service version from the cloud disk into memory for execution. As mentioned earlier, the image data for each service version can be pre-stored on the cloud disk. Furthermore, if the subset of blue instances includes multiple blue instances, the multiple blue instances can concurrently load the image data of the second service version from the cloud disk into memory for execution to save loading time.

[0072] In this embodiment, by using a subset of blue instances as the basis for small-scale testing to perform small-scale updates, it is helpful to conduct preliminary verification of the security or stability of the updated service version, thereby avoiding excessive losses due to the lack of security or stability of the second service version.

[0073] According to some embodiments, determining whether the first update operation was successful in step S304 may include steps S3042 and S3044. In step S3042, based on the metrics reflected by the first monitoring curve used to monitor a subset of blue instances, it can be determined whether there is a difference between deploying the second service version on the subset of blue instances and deploying the first service version, or whether the difference is less than a predetermined threshold. In step S3044, in response to determining that there is no difference or the difference is less than the predetermined threshold, the first update operation can be determined to be successful.

[0074] In the example, the first monitoring curve used in step S3042 to monitor a subset of blue instances can be an instance-level monitoring curve for each blue instance. In other words, each blue instance can have its own monitoring curve. This monitoring curve can reflect changes in metrics such as traffic volume, response time, or CPU usage over time. According to the method of this embodiment, since the consistency of the monitoring curves can be ensured, it is possible to correctly analyze whether the updated second service version has security or stability. For example, it is possible to determine the difference between the traffic volume reflected by the monitoring curve when deploying the second service version on a subset of blue instances and the traffic volume reflected by the monitoring curve when deploying the first service version. A predetermined threshold for this difference can be set according to actual conditions and requirements.

[0075] In the example, in response to the determination in step S3042 that a difference exists and the difference is greater than a predetermined threshold, it can be determined that the first update operation was unsuccessful. In this case, the entire update process can be stopped. Accordingly, combined with Figure 2 The method 200 can be stopped at step S204, therefore step S206 is not executed.

[0076] In this embodiment, by using a monitoring curve with consistent instance granularity to determine whether the indicators before and after the update meet the predetermined conditions, it is possible to correctly analyze whether the updated second service version has security or stability, thereby helping to improve update efficiency.

[0077] According to some embodiments, in step S306, performing a second update operation for the remaining blue instances in the blue instance set may further include steps S3062, S3064, and S3066. In step S3062, traffic on the remaining blue instances can be switched to the remaining green instances in the green instance set. In step S3064, a second service version can be deployed on the remaining blue instances. In step S3066, traffic switched to the remaining green instances can be switched back to the remaining blue instances.

[0078] In the example, the traffic switching process performed in steps S3062 and S3066 can also be implemented through a naming service. This traffic switching process can also achieve instantaneous switching without any time delay.

[0079] In the example, step S3064, deploying the second service version on the remaining blue instance may also include the remaining blue instance loading the image data of the second service version from the cloud disk into memory for execution. Alternatively, if the remaining blue instance includes multiple blue instances, the multiple blue instances can concurrently load the image data of the second service version from the cloud disk into memory for execution to save loading time.

[0080] In this embodiment, by performing updates on the remaining blue instances after ensuring successful updates on some blue instances, the reliability of the update service version can be improved, thereby avoiding excessive losses due to the lack of security or stability of the second service version.

[0081] According to some embodiments, in step S308, it can be determined whether the second update operation was successful. In step S310, in response to determining that the second update operation was unsuccessful, the update of the second service version can be determined to be unsuccessful.

[0082] In the example, if the update to the second service version is determined to be unsuccessful in step S310, the entire update process can be stopped. Accordingly, combined with... Figure 2 The method 200 can be stopped at step S204, therefore step S206 is not executed.

[0083] In this embodiment, by setting an additional verification mechanism after the second update operation, excessive losses due to the lack of security or stability of the second service version can be further avoided.

[0084] According to some embodiments, step S308 can be performed in a similar manner to step S304. Therefore, based on the metrics reflected by the second monitoring curve used to monitor the remaining blue instances, it can be determined whether there is a difference between deploying the second service version and deploying the first service version on the remaining blue instances, and whether the difference is greater than or equal to a predetermined threshold. In response to the existence of a difference greater than or equal to the predetermined threshold, it can be determined that the second update operation was unsuccessful.

[0085] In the example, if it is determined that deploying the second service version on the remaining blue instances is no different from deploying the first service version, or the difference is less than a predetermined threshold, then the second update operation can be considered successful, and the combination can then be executed. Figure 2 Step S206 involves removing the green instance.

[0086] In the example, comparisons can also be made between a subset of blue instances and the remaining blue instances. For instance, the metrics reflected in the monitoring curve for a subset of blue instances (such as canary blue instances) can be compared with the metrics reflected in the monitoring curve for the remaining blue instances (such as full blue instances) to determine whether the second update operation was successful.

[0087] In this embodiment, by using a monitoring curve with consistent instance granularity to determine whether the indicators before and after the update meet the predetermined conditions, it is possible to correctly analyze whether the updated second service version has security or stability, thereby helping to improve update efficiency.

[0088] The following combination Figure 4 An example describing a service version update method according to an embodiment of this disclosure.

[0089] Figure 4 A schematic diagram of a service version update method according to an embodiment of this disclosure is shown.

[0090] like Figure 4 As shown, box 410 represents the initial state, in which the initial service version V0 is deployed on the blue instance set 402, and the blue instance set 402 is currently handling traffic 404 (in Figure 4 (The arrows in the image indicate the traffic being handled). At this point, the initial service version V0 deployed on the blue instance collection 402 needs to be updated to the new service version V1. For illustrative purposes, Figure 4 The blue instance set 402 shown only includes three blue instances, but those skilled in the art will understand that this is only an example and in practice there may be more or fewer blue instances.

[0091] The process can proceed from the initial state in box 410 to the green instance initiation operation represented by box 420. In the green instance initiation operation in box 420, a green instance set 406 can be created to synchronize the initial service version V0 on the green instance set 406. For illustrative purposes, Figure 4 The green instance set 406 is shown to include three green instances, but those skilled in the art will understand that this is only an example and in practice there may be more or fewer green instances corresponding to blue instances.

[0092] like Figure 4 As shown, the update process of updating the initial service version V0 deployed on the blue instance set 402 to the new service version V1 may include a small-traffic switching operation represented by box 430 and a full-traffic switching operation represented by box 440.

[0093] In the small-scale traffic switching operation in box 430, traffic 404-1 on blue instance 402-1 can be switched to green instance 406-1 in the green instance set 406. Then, the new service version V1 can be deployed on blue instance 402-1. Afterwards, traffic 404-1 switched to green instance 406-1 can be switched back to blue instance 402-1.

[0094] If the small-flow switching operation in box 430 is confirmed to be successful, the process can proceed from the small-flow switching operation in box 430 to the full-flow switching operation in box 440. The full-flow switching operation in box 440 can be performed in a similar manner to the small-flow switching operation in box 430.

[0095] In the full traffic switch operation (box 440), traffic 404-2 and 404-3 on blue instances 402-2 and 402-3 can be switched to green instances 406-2 and 406-3 in the green instance set 406. Then, the new service version V1 can be deployed on blue instances 402-2 and 402-3. Afterwards, traffic 404-2 and 404-3 switched to green instances 406-2 and 406-3 can be switched back to blue instances 402-2 and 402-3.

[0096] If the full traffic switching operation in box 440 is confirmed to be successful, the process can proceed from the full traffic switching operation in box 440 to the green instance decommissioning operation represented by box 450. In the green instance decommissioning operation in box 450, the green instance set 460 can be removed.

[0097] In such Figure 4 In the described service version update method, since the green instance set 460 is used as a temporary relay instance set to handle traffic, it can be ensured that after the update process, the new service version V1 and the final state of the traffic always reside on the blue instance set 420. This ensures that the monitoring curve at the instance granularity for the blue instances does not terminate during the update process, thus providing the continuity of the monitoring curve. This continuity, in turn, ensures that the security or stability of the new service version V1 can be correctly analyzed.

[0098] Figure 5 A schematic diagram illustrating an example of a monitoring curve 500 at the instance granularity according to an embodiment of the present disclosure is shown.

[0099] like Figure 5 As shown, the monitoring curve 500 can reflect changes in metrics (such as traffic volume, response time, or CPU usage) over time. The monitoring curve 500 may include a first monitoring curve portion 510, a second monitoring curve portion 520, and a relay monitoring curve portion 530.

[0100] In the example, the first monitoring curve portion 510 and the second monitoring curve portion 520 can be combined. Figure 4 The small-traffic switching operations shown in box 430 were monitored for deploying the initial service version V0 on blue instance 402-1 and the new service version V1 on blue instance 402-1, respectively. The relay monitoring curve 530 can be obtained by monitoring the temporary traffic 404-1 received by green instance 406-1.

[0101] Therefore, both the first monitoring curve portion 510 and the second monitoring curve portion 520 are monitoring curves obtained from monitoring the blue instance 402-1. Thanks to this consistency, it can be ensured that the security or stability of the new service version V1 can be correctly analyzed.

[0102] According to another aspect of this disclosure, a service version update device based on blue-green publishing is also provided.

[0103] Figure 6 A structural block diagram of a service version update apparatus 600 according to an embodiment of the present disclosure is shown.

[0104] like Figure 6 As shown, the service version update device 600 includes a green instance creation module 602, a service version update module 604, and a green instance removal module 606.

[0105] The green instance creation module 602 is configured to create a green instance set to synchronize the first service version on the green instance set in response to updating the first service version deployed on the blue instance set currently handling traffic to the second service version;

[0106] Service version update module 604 is configured to update the first service version deployed on the blue instance set to the second service version by using the green instance set as a relay instance set for temporarily taking over traffic.

[0107] The Green Instance Removal Module 606 is configured to remove the set of green instances in response to a successful update of the second service version.

[0108] Since the green instance creation module 602, service version update module 604, and green instance removal module 606 in the service version update device 600 can respectively correspond to the combination Figure 2 Steps S202, S204, and S206 are described above, so the details of each aspect will not be repeated here.

[0109] Additionally, the service version update device 600 and its included green instance creation module 602, service version update module 604, and green instance removal module 606 may also include further sub-modules, which will be combined as follows Figure 7 Please provide a detailed explanation.

[0110] Figure 7 A structural block diagram of a service version update apparatus 700 according to another embodiment of the present disclosure is shown.

[0111] like Figure 7 As shown, the service version update device 700 may include a green instance creation module 702, a service version update module 704, and a green instance removal module 706. These modules can correspond to a combination of... Figure 6 The green instance creation module 602, service version update module 604, and green instance removal module 606 are mentioned above.

[0112] According to some embodiments, the green instance creation module 702 may include a service version synchronization module 7022, which is configured to load the image data of the first service version from the cloud storage device into the memory of the corresponding green instance in the green instance set, so as to start the service corresponding to the first service version.

[0113] According to some embodiments, the service version update module 704 may include: a first update execution module 7042, configured to perform a first update operation for a portion of the blue instances in the blue instance set; a first update result determination module 7044, configured to determine whether the first update operation was successful; and a second update execution module 7046, configured to perform a second update operation for the remaining blue instances in the blue instance set in response to determining that the first update operation was successful.

[0114] According to some embodiments, the first update execution module 7042 may include: a first traffic switching module 7042-1, configured to switch traffic on a portion of the blue instances to a portion of the green instances in the green instance set; and after the second service version is deployed to a portion of the blue instances, switch the traffic switched to the portion of the green instances back to the portion of the blue instances; and a first update processing module 7042-2, configured to deploy the second service version on the portion of the blue instances.

[0115] According to some embodiments, the first update result determination module 7044 may include: a first indicator judgment module 7044-1, configured to determine whether there is a difference between deploying the second service version on the partial blue instances and deploying the first service version, or whether the difference is less than a predetermined threshold, based on the indicator reflected by the first monitoring curve used to monitor the partial blue instances; and a first result determination module 7044-2, configured to determine that the first update operation is successful in response to the determination that there is no difference or the difference is less than a predetermined threshold.

[0116] According to some embodiments, the second update execution module 7046 may include: a second traffic switching module 7046-1, configured to switch traffic on the remaining blue instances to the remaining green instances in the green instance set; and after the second service version is deployed to the remaining blue instances, switch the traffic switched to the remaining green instances back to the remaining blue instances; and a second update processing module 7046-2, configured to deploy the second service version on the remaining blue instances.

[0117] According to some embodiments, the service version update module 704 may include: a second update result determination module 7048, configured to determine whether the second update operation is successful; and an update stop module 7050, configured to determine the update of the second service version as unsuccessful in response to determining that the second update operation is unsuccessful.

[0118] According to some embodiments, the second update result determination module 7048 may include: a second indicator judgment module 7048-1, configured to determine, based on the indicator reflected by the second monitoring curve used to monitor the remaining blue instances, whether there is a difference between deploying the second service version and deploying the first service version on the remaining blue instances and whether the difference is greater than or equal to a predetermined threshold; and a second result determination module 7048-2, configured to determine that the second update operation is unsuccessful in response to the existence of a difference and the difference being greater than or equal to the predetermined threshold.

[0119] The 704 error in the service version update module can be associated with... Figure 3 The method described in 300. Accordingly, the operations of the first update execution module 7042, the first update result determination module 7044, the second update execution module 7046, the second update result determination module 7048, and the update stop module 7050 can respectively correspond to the combined... Figure 3 Steps S302, S304, S306, S308, and S310 in method 300.

[0120] According to another aspect of this disclosure, an electronic device is also provided, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method described above.

[0121] According to another aspect of this disclosure, a non-transitory computer-readable storage medium storing computer instructions is also provided, wherein the computer instructions are used to cause a computer to perform the methods described above.

[0122] According to another aspect of this disclosure, a computer program product is also provided, including a computer program, wherein the computer program implements the method described above when executed by a processor.

[0123] refer to Figure 8 The present invention describes a structural block diagram of an electronic device 800 that can serve as a server of the present disclosure, which is an example of a hardware device that can be applied to various aspects of the present disclosure. The electronic device is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0124] like Figure 8 As shown, the electronic device 800 includes a computing unit 801, which can perform various appropriate actions and processes according to a computer program stored in a read-only memory (ROM) 802 or a computer program loaded from a storage unit 808 into a random access memory (RAM) 803. The RAM 803 may also store various programs and data required for the operation of the electronic device 800. The computing unit 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0125] Multiple components in electronic device 800 are connected to I / O interface 805, including: input unit 806, output unit 807, storage unit 808, and communication unit 809. Input unit 806 can be any type of device capable of inputting information to electronic device 800. Input unit 806 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of electronic device, and can include, but is not limited to, a mouse, keyboard, touchscreen, trackpad, trackball, joystick, microphone, and / or remote control. Output unit 807 can be any type of device capable of presenting information, and can include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. Storage unit 808 can include, but is not limited to, a hard disk and an optical disk. Communication unit 809 allows electronic device 800 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks, and can include, but is not limited to, modems, network cards, infrared communication devices, wireless communication transceivers, and / or chipsets, such as Bluetooth™ devices, 802.11 devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0126] The computing unit 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 801 performs the various methods and processes described above, such as the service version update method. For example, in some embodiments, the service version update method may be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 808. In some embodiments, part or all of the computer program may be loaded and / or installed on the electronic device 800 via ROM 802 and / or communication unit 809. When the computer program is loaded into RAM 803 and executed by the computing unit 801, one or more steps of the service version update method described above may be performed. Alternatively, in other embodiments, the computing unit 801 may be configured to perform the service version update method by any other suitable means (e.g., by means of firmware).

[0127] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), complex programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0128] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0129] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. A machine-readable medium can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0130] To provide interaction with a user, the systems and techniques described herein can be implemented on a computer having: a display device for displaying information to the user (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor); and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0131] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), the Internet, and blockchain networks.

[0132] Computer systems can include clients and servers. Clients and servers are generally located far apart and typically interact via communication networks. Client-server relationships are created by computer programs running on the respective computers and having a client-server relationship with each other. Servers can be cloud servers, servers in distributed systems, or servers incorporating blockchain technology.

[0133] It should be understood that the various forms of processes shown above can be used to rearrange, add, or delete steps. For example, the steps described in this disclosure can be performed in parallel, sequentially, or in a different order, as long as the desired result of the technical solution disclosed in this disclosure can be achieved, and this is not limited herein.

[0134] While embodiments or examples of this disclosure have been described with reference to the accompanying drawings, it should be understood that the methods, systems, and devices described above are merely exemplary embodiments or examples, and the scope of the invention is not limited by these embodiments or examples, but only by the granted claims and their equivalents. Various elements in the embodiments or examples may be omitted or replaced by their equivalents. Furthermore, the steps may be performed in a different order than that described in this disclosure. Further, various elements in the embodiments or examples may be combined in various ways. Importantly, as the technology evolves, many elements described herein can be replaced by equivalents that appear after this disclosure.

Claims

1. A service version update method based on blue-green deployment, comprising: In response to the need to update the first service version deployed on the blue instance set currently handling traffic to the second service version, a green instance set is created to synchronize the first service version on the green instance set. By using the green instance set as a relay instance set to temporarily handle the traffic, while the blue instance set continues to handle at least a portion of the traffic, the first service version deployed on the blue instance set is updated to the second service version, and the second service version is not deployed on the green instance set, including: Performing a first update operation for a subset of blue instances in the blue instance set includes: Switch the traffic on some of the blue instances to some of the green instances in the green instance set; Deploy the second service version on the aforementioned blue instances; The traffic that was switched to the green instances will be switched back to the blue instances. Determine whether the first update operation was successful; In response to determining that the first update operation was successful, a second update operation is performed for the remaining blue instances in the blue instance set, including: Switch the traffic on the remaining blue instances to the remaining green instances in the green instance set; Deploy the second service version on the remaining blue instances; The traffic that was switched to the remaining green instance will be switched back to the remaining blue instance; Based on the metrics reflected by the monitoring curves used to monitor the blue instance set, it is determined whether there is a difference between deploying the second service version on the blue instance set and deploying the first service version, or whether the difference is less than a predetermined threshold. In response to determining that the difference does not exist or the difference is less than a predetermined threshold, the second service version update is determined to be successful; and In response to the confirmation that the second service version update was successful, the green instance set is removed.

2. The method according to claim 1, wherein, The step of creating a collection of green instances to synchronize the first service version on the collection of green instances includes: The image data of the first service version is loaded from the cloud storage device into the memory of the corresponding green instance in the green instance set to start the service corresponding to the first service version.

3. The method according to claim 1, wherein, Determining whether the first update operation was successful includes: Based on the metrics reflected by the first monitoring curve used to monitor the subset of blue instances, determine whether there is a difference between deploying the second service version and deploying the first service version on the subset of blue instances, or whether the difference is less than a predetermined threshold; and In response to determining that the difference does not exist or the difference is less than a predetermined threshold, the first update operation is determined to be successful.

4. The method according to claim 1 or 3, wherein, The step of updating the first service version deployed on the blue instance set to the second service version also includes: Determine whether the second update operation was successful; and In response to the determination that the second update operation was unsuccessful, the update of the second service version is determined to be unsuccessful.

5. The method according to claim 4, wherein, Determining whether the second update operation was successful includes: Based on the metrics reflected by the second monitoring curve used to monitor the remaining blue instances, determine whether there is a difference between deploying the second service version and deploying the first service version on the remaining blue instances, and whether the difference is greater than or equal to the predetermined threshold; and In response to the existence of the difference and the difference being greater than or equal to the predetermined threshold, it is determined that the second update operation was unsuccessful.

6. A service version update device based on blue-green deployment, comprising: The green instance creation module is configured to create a green instance set to synchronize the first service version on the green instance set in response to updating the first service version deployed on the blue instance set that is currently handling traffic to the second service version. The service version update module is configured to use the green instance set as a relay instance set for temporarily handling the traffic, and while the blue instance set continues to handle at least a portion of the traffic, update the first service version deployed on the blue instance set to the second service version, while the second service version is not deployed on the green instance set. The service version update module includes: The first update execution module is configured to perform a first update operation for a subset of blue instances in the blue instance set, including: Switch the traffic on some of the blue instances to some of the green instances; Deploy the second service version on the aforementioned blue instances; Switch the traffic back; The first update result determination module is configured to determine whether the first update operation was successful. The second update execution module is configured to, in response to determining that the first update operation was successful, perform a second update operation for the remaining blue instances in the same manner as the first update execution module. The indicator judgment module is configured to determine, based on the indicators reflected by the monitoring curve used to monitor the blue instance set, whether there is a difference between deploying the second service version on the blue instance set and deploying the first service version, or whether the difference is less than a predetermined threshold. The update result determination module is configured to determine that the second service version update was successful in response to determining that the difference does not exist or the difference is less than a predetermined threshold; and The green instance removal module is configured to remove the set of green instances in response to a successful update of the second service version.

7. The apparatus according to claim 6, wherein, The green instance creation module includes: The service version synchronization module is configured to load the image data of the first service version from the cloud storage device into the memory of the corresponding green instance in the green instance set, so as to start the service corresponding to the first service version.

8. The apparatus according to claim 6, wherein the first update result determination module comprises: The first indicator judgment module is configured to determine, based on the indicator reflected by the first monitoring curve used to monitor the partial blue instances, whether there is a difference between deploying the second service version on the partial blue instances and deploying the first service version, or whether the difference is less than a predetermined threshold. as well as The first result determination module is configured to determine that the first update operation is successful in response to determining that the difference does not exist or the difference is less than a predetermined threshold.

9. The apparatus according to claim 6 or 8, wherein, The service version update module also includes: The second update result determination module is configured to determine whether the second update operation was successful; and The update stop module is configured to determine that the update of the second service version was unsuccessful in response to the determination that the second update operation was unsuccessful.

10. The apparatus according to claim 9, wherein, The second update result determination module includes: The second indicator judgment module is configured to determine, based on an indicator reflected by a second monitoring curve used to monitor the remaining blue instances, whether there is a difference between deploying the second service version and deploying the first service version on the remaining blue instances, and whether the difference is greater than or equal to a predetermined threshold; and The second result determination module is configured to determine that the second update operation is unsuccessful in response to the existence of the difference and the difference being greater than or equal to the predetermined threshold.

11. An electronic device, comprising: At least one processor; as well as A memory that is communicatively connected to the at least one processor; in The memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method according to any one of claims 1-5.

12. A non-transitory computer-readable storage medium storing computer instructions, wherein, The computer instructions are used to cause the computer to perform the method according to any one of claims 1-5.

13. A computer program product comprising a computer program, wherein, The computer program, when executed by a processor, implements the method according to any one of claims 1-5.

Images