A micro-service instance management method, device and computing device cluster

Abstract

Embodiments of the present application provide a micro-service instance management method, device and computing device cluster, which are used to reduce the situation that traffic is lost due to failure of a micro-service instance. In the method of the embodiments of the present application, after a registration device registers first information of a micro-service instance in a micro-service instance creation stage, the first information including a name of the micro-service instance, an IP of the micro-service instance and port information of the micro-service instance, the registration device sends a first health detection request to the micro-service instance, performs health detection on the micro-service instance, obtains a current health condition of the micro-service instance, and registers the micro-service instance in a registration center in a healthy condition of the micro-service instance. The registration of the micro-service instance in the registration center is ensured only when the health condition of the micro-service instance is healthy, avoiding the situation that the micro-service instance can still be normally called in the case that the health condition of the micro-service instance is uncertain, and improving the reliability of the scheme.

Description

Technical Field

[0001] This application relates to the Internet field, and more particularly to a microservice instance management method, apparatus, and computing device cluster. Background Technology

[0002] With the continuous development of internet technology, microservice technology is also constantly evolving. The registry center ensures the normal operation of microservice instances by monitoring their health. For example, the registry center receives heartbeat packets periodically sent by microservice instances to update their time-to-live (TTL) value. If no heartbeat packet is received from the microservice instance after the heartbeat sending cycle, the registry center determines that the microservice instance is offline. Alternatively, the registry center can send health check signals to the microservice instances at any time to ascertain their health status and perform subsequent operations.

[0003] However, not all microservice instances can directly transmit messages with the registry. In such cases, the registry cannot know the current running status of the microservice instance, and therefore cannot take offline microservice instances that are not working properly in a timely manner. As a result, traffic is lost in the access to microservice instances due to the failure of the microservice instance. Summary of the Invention

[0004] This application provides a microservice instance management method, apparatus, and computing device cluster to reduce traffic loss caused by microservice instance failures.

[0005] The first aspect of this application provides a microservice instance management method, comprising: obtaining first information, the first information carrying the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance; sending a first health check request to the microservice instance according to the port information of the microservice instance; obtaining a first health status of the microservice instance sent by the microservice instance; and if the first health status is healthy, sending a second registration message to a registration center, the second registration message carrying the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

[0006] In this embodiment, after obtaining the first information of the microservice instance, a first health check request is sent to the microservice instance to obtain its first health status. If the first health status is healthy, a second registration message is sent to the registration center. The first information carries the name, IP address, and port information of the microservice instance, while the second registration message carries the same information. After obtaining the first information, the registration device sends the first health check request to the microservice instance to perform a health check, obtain its current health status, and registers the microservice instance with the registration center if it is healthy. This ensures that the microservice instance is only invoked by other services from the registration center when its health status is healthy, avoiding situations where the microservice instance is invoked by other services when its health status is unclear, thus improving the reliability of the solution.

[0007] In one possible implementation of the first aspect, the method further includes: generating a microservice instance unhealthy signal if the first health condition is unhealthy. In this embodiment, generating a microservice instance unhealthy signal when the first health condition is unhealthy can, in specific scenarios, record the unhealthy status of the microservice instance in the logs of the registration device, and also send an unhealthy signal to the microservice instance, thereby achieving closed-loop management of the microservice instance's health status and improving the completeness of the solution.

[0008] In one possible implementation of the first aspect, the method further includes: after sending the first health check request for a first time period, sending a second health check request to the microservice instance; obtaining a second health status sent by the microservice instance; if the second health status is unhealthy, sending a shutdown request to the registry center, the shutdown request carrying the name of the microservice instance, the IP address of the microservice instance, and the port information of the microservice instance.

[0009] In this embodiment, after sending the first health check request for a first time period, a second health check request is sent to the microservice instance to obtain the second health status of the microservice instance. If the second health status is unhealthy, a shutdown request is sent to the registry center. The shutdown request carries the name, IP address, and port information of the microservice instance. By sending a shutdown request to the registry center when the second health status is unhealthy, the registry center will shut down the microservice instance upon receiving the shutdown request from the registration device. By promptly shutting down microservice instances with unhealthy health status, comprehensive management of microservice instances is achieved, and unhealthy microservice instances can be shut down in a timely manner, improving the reliability of the solution.

[0010] In one possible implementation of the first aspect, before sending the second health check request to the microservice instance, the method further includes: obtaining the first time period based on the user's operation on the operation interface, wherein the first time period is the interval between the first health check request and the second health request.

[0011] In this embodiment of the application, before sending the second health check request to the microservice instance, a first time period can be obtained based on the user's operation on the operation interface. The first time period is the interval between the first health check request and the second health check request. By allowing the user to set the time interval between the health check after the microservice instance is created and the subsequent health checks according to their needs, the flexibility and operability of the solution are improved.

[0012] In one possible implementation of the first aspect, the first information includes a first registration message sent by the microservice instance to the registry center.

[0013] In this embodiment, the first information includes the first registration message sent by the microservice instance to the registry center. In specific application scenarios, when a microservice instance is created and needs to register with the registry center, the first information is the first registration message sent by the microservice instance to the registry center. By querying the health status of the microservice instance after its creation and before registering with the registry center, and registering the microservice instance with the registry center when it is healthy, the system ensures that all microservice instances registered with the registry center are healthy, reducing the possibility that an unavailable microservice instance may be called by other microservices, thus improving the reliability of the solution.

[0014] In one possible implementation of the first aspect, the first information includes business startup information of the microservice instance; obtaining the first information of the microservice instance includes: obtaining the business startup information of the microservice instance loaded when the microservice instance is created.

[0015] In this embodiment, when a microservice instance is created, if the microservice instance does not need to register with the registry center, since the microservice instance and the registration device reside in the same process, the registration device can obtain the business startup information of the microservice instance loaded by the microservice instance during creation. This first information is the business startup information of the microservice instance. By obtaining the business startup information loaded by the microservice instance during creation, and then checking whether the microservice instance is available after obtaining the business startup information, if it is available, a second registration message is sent to the registry center to complete the registration of the microservice instance. This avoids the problem of unmanageable microservice instance status caused by using microservice instances directly without registration, thus improving the reliability of the solution.

[0016] In one possible implementation of the first aspect, the method further includes: if the second health condition is healthy, sending a heartbeat message to the registry center, the heartbeat message indicating that the microservice instance can work normally. In this embodiment, if the second health condition is healthy, a heartbeat message is sent to the registry center. By sending health detection messages to the microservice instance through the registration device, the health status of the microservice instance is obtained, and after confirming that the microservice instance is healthy, a heartbeat message is promptly sent to the registry center, enabling the registry center to manage the microservice instance and allowing for more comprehensive monitoring of the microservice instance's health status.

[0017] A second aspect of this application provides a microservice instance management device, including:

[0018] The acquisition unit is used to acquire first information of the microservice instance, the first information carrying the name of the microservice instance, the Internet Protocol IP of the microservice instance, and the port information of the microservice instance;

[0019] The sending unit is configured to send a first health check request to the microservice instance based on the port information of the microservice instance;

[0020] The acquisition unit is further configured to acquire the first health status of the microservice instance sent by the microservice instance;

[0021] The sending unit is further configured to send a second registration message to the registration center if the first health status is healthy. The second registration message carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

[0022] In one possible implementation of the second aspect, the apparatus further includes a generation unit for generating a microservice instance unhealthy signal if the first health condition is unhealthy.

[0023] In one possible implementation of the second aspect, the sending unit is further configured to send a second health check request to the microservice instance after sending the first health check request for a first time period;

[0024] The acquisition unit is also used to acquire the second health status sent by the microservice instance;

[0025] The sending unit is further configured to send a shutdown request to the registration center if the second health condition is unhealthy. The shutdown request carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

[0026] In one possible implementation of the second aspect, the acquisition unit is further configured to acquire the first time period based on the user's operation on the operation interface, wherein the first time period is the interval between the first health detection request and the second health request.

[0027] In one possible implementation of the second aspect, the first information includes a first registration message sent by the microservice instance to the registry center.

[0028] In one possible implementation of the second aspect, the first information includes business startup information of the microservice instance;

[0029] The acquisition unit is specifically used to acquire the business startup information of the microservice instance loaded when the microservice instance is created.

[0030] In one possible implementation of the second aspect, the sending unit is further configured to send a heartbeat message to the registry center if the second health condition is healthy, the heartbeat message indicating that the microservice instance can work normally.

[0031] A third aspect of this application provides a microservice instance management device, including a processor and a memory. The memory is used to store instructions, and the processor is used to execute the instructions. When the processor executes the instructions, it performs the method described in the first aspect or any possible implementation of the first aspect.

[0032] A fourth aspect of this application provides a computing device cluster, comprising at least one computing device, each computing device including a processor and a memory, wherein the processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the computing device cluster to perform any of the possible methods of the first aspect.

[0033] A fifth aspect of this application provides a computer-readable storage medium including a program that, when run on a computer, causes the computer to perform the method described in the first aspect or any possible implementation thereof.

[0034] A sixth aspect of this application provides a computer program product containing instructions that, when run on a computer, cause the computer to perform the method described in the first aspect or any possible implementation thereof. Attached Figure Description

[0035] Figure 1 A schematic diagram of a microservice instance provided in an embodiment of this application;

[0036] Figure 2A flowchart illustrating a method for managing microservice instances provided in an embodiment of this application;

[0037] Figure 3a A schematic diagram illustrating the working process of the microservice instance registration phase provided in an embodiment of this application;

[0038] Figure 3b A schematic diagram illustrating the operation of a microservice instance during runtime, as provided in an embodiment of this application.

[0039] Figure 4 Another flowchart illustrating the microservice instance management method provided in this application embodiment;

[0040] Figure 5a Another schematic diagram illustrating the working process of the microservice instance registration phase provided in this application embodiment;

[0041] Figure 5b Another schematic diagram illustrating the operation of a microservice instance during its runtime phase, as provided in this application embodiment;

[0042] Figure 6 A schematic diagram of a microservice instance management apparatus provided in an embodiment of this application;

[0043] Figure 7 Another schematic diagram of the microservice instance management apparatus provided in the embodiments of this application;

[0044] Figure 8 This is a schematic diagram of a computing device cluster provided in an embodiment of this application;

[0045] Figure 9 This is a schematic diagram of another structure of the computing device cluster provided in an embodiment of this application. Detailed Implementation

[0046] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is only for explaining specific embodiments and is not intended to limit the application. Those skilled in the art will recognize that, with technological advancements and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0047] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0048] With the continuous development of internet technology, various system functions are constantly evolving, and the services provided are becoming increasingly diverse. For example, a purchasing system can offer multiple services, including order services, user services, product browsing services, and payment services. If these services are implemented using a monolithic architecture, the purchasing system will have extremely high coupling, and the development difficulty will gradually increase with the addition of functions. To reduce the coupling of the system and thus reduce the development difficulty, microservice development is used, where each service is developed as a monolithic application. In the aforementioned example, the order service, user service, product browsing service, and payment service are each developed as a separate microservice.

[0049] When developing various services as microservices, a single business function often requires multiple microservices to complete. For example, when a user shops on a shopping website, after browsing the product page, they initiate a purchase request. The purchase system then generates an order and initiates a payment request. In this scenario, the shopping system first calls the product browsing service, which in turn calls the order service, which then calls the payment service. As the business logic becomes more complex, the call relationships between these services become intricate. To manage the relationships and availability of microservices, a service registry emerges. The registry records the IP address, port, and functionalities of each microservice. When microservices need to call each other, they can query the registry to see if a microservice that meets their functional requirements is available.

[0050] During the management of microservices, the registry center needs to collect the health status of microservices in a timely manner to determine their availability. For example, the registry center can obtain heartbeat messages periodically sent by microservice instances to refresh their Time-To-Live (TTL). If no heartbeat message is received from the microservice instance after the TTL exceeds the heartbeat message sending cycle, the registry center determines that the microservice instance is offline. Alternatively, the registry center can send health check signals to microservice instances at any time to ascertain their health status. If the microservice instance is unhealthy, the registry center takes it offline; if the microservice instance is healthy, the registry center sends a health check signal to the microservice instance again after a period of time.

[0051] However, not all microservice instances can directly transmit messages with the registry. In such cases, the registry cannot know the current running status of the microservice instance, and therefore cannot take offline microservice instances that are not working properly in a timely manner. As a result, traffic is lost in the access to microservice instances due to the failure of the microservice instance.

[0052] To address the above issues, this application proposes setting up a registration mechanism for each microservice instance, the specific structure of which is as follows: Figure 1 As shown, Figure 1 This is a schematic diagram of a microservice instance provided in an embodiment of this application. A process includes a microservice instance and a registration device. The microservice instance exposes a health detection interface to a health detection module in the registration device. The registration device includes a registration module and a health detection module. The registration module intercepts registration messages or business startup information sent by the microservice instance. When the registration module obtains the first registration message or business startup information of the microservice instance, the health detection module calls the health detection interface of the microservice instance to determine its health status. If the microservice instance is healthy, the registration module sends a registration message to the registration center; if the microservice instance is unhealthy, the registration device records the unhealthy status of the microservice instance in its own and the microservice instance's runtime logs. In addition, the health detection module can periodically check the health status of the microservice instance according to a user-configured period. When the health detection module determines that the microservice instance is healthy, the registration device records the health status of the microservice instance in its runtime log; when the health detection module determines that the microservice instance is unhealthy, the registration module sends a request to the registration center to take the microservice instance offline.

[0053] Based on the above ideas, this paper first introduces the proposed solution by taking the scenario where a microservice instance needs to send a registration message to the registry center after creation as an example. Please refer to [link to relevant documentation]. Figure 2 , Figure 2 This is a flowchart illustrating a method for managing microservice instances provided in an embodiment of this application.

[0054] 201. The registration device obtains the first registration message sent by the microservice instance;

[0055] In cases where a microservice instance needs to send a message to the registry center after its creation, the registration module in the registration device intercepts the first registration message sent by the microservice instance to the registry center. The first registration message carries the name of the microservice instance, the Internet Protocol (IP) of the microservice instance, and the port information of the microservice instance.

[0056] 202. The registration device sends the first health check request to the microservice instance;

[0057] After the registration module in the registration device intercepts the first registration message sent by the microservice instance to the registration center, it sends a first health check request to the health check interface of the microservice instance based on the microservice instance's IP address and port information carried in the first registration message. The first health check request is used to obtain the health status of the microservice instance.

[0058] For example, the specific implementation of the registration device sending the first health check request to the microservice instance is as follows:

[0059] class ThreadClass {

[0060] public void run(){

[0061] / / T0D0: Health monitoring module detects the status of service instance.

[0062] }

[0063] }

[0064] It is understandable that the description here of the registration device sending the first health check request to the microservice instance and initiating the health check of the microservice instance is just an example. In actual applications, it can be combined with other code implementations, and there are no restrictions here.

[0065] 203. The registration device obtains the first health status sent by the microservice instance;

[0066] After the registration device sends the first health check request to the microservice instance, the microservice instance sends the first health status sent by the microservice instance to the health check module of the registration device.

[0067] For example, after receiving the first health check message from the registration device, the microservice instance sends its current health status to the registration device. For instance, if the microservice instance is healthy, it sends a health signal; if it is unhealthy, it sends an unhealthy signal. The specific content of the health and unhealthy signals is not limited here. Alternatively, if the microservice instance is healthy, it sends a signal to the registration device; if it is unhealthy, due to the disconnection between the microservice instance and the registration device, after the waiting period, the registration device determines the microservice instance to be unhealthy.

[0068] It is understood that the description of the registration device obtaining the first health status of the microservice instance here is only an example. In actual applications, it should be set according to the specific application scenario, and no restrictions are imposed here.

[0069] If the first health condition is healthy, proceed to step 204;

[0070] If the first health condition is unhealthy, proceed to step 205.

[0071] 204. The registration device sends a second registration message to the registration center;

[0072] When the first health status is healthy, the registration module of the registration device sends a second registration message to the registration center. The second registration message carries the name of the microservice instance, the IP address of the microservice instance, and the port information of the microservice instance.

[0073] Specifically, when the registration device detects that the health status of a microservice instance is healthy, the registration device sends a second registration message to the registration center as follows:

[0074] if {checkhealth() == health) {

[0075] / / T0D0: Registration Service Instance

[0076] }

[0077] It is understood that the description of the registration device sending the second registration message to the registration center here is only an example. In actual applications, it can be implemented in combination with other code, and there are no restrictions here.

[0078] After the registration center receives the second registration message sent by the registration device, other microservice instances can directly call the microservice instance by accessing the registration center.

[0079] It should be noted that the second registration message here has the same content as the first registration message. In practical applications, the second registration message can be the first registration message sent to the registration center by the registration device after setting a delay, or it can be the registration message generated by the registration device based on the name, IP address, and port information of the microservice instance. There are no restrictions here.

[0080] 205. The registration device generates an unhealthy signal for the microservice instance;

[0081] When the first health condition is unhealthy, the registration device does not need to report to the registration center. Instead, the registration device generates an unhealthy signal for the microservice instance so that technical personnel can verify it later.

[0082] For example, the registration device can record in its work log that a microservice instance is unhealthy in the first-time health check.

[0083] Optionally, the registration device can send an unhealthy signal to the microservice instance, enabling the microservice instance to record the health check result of the microservice instance in the microservice instance's working log at the first moment.

[0084] Furthermore, the registration device or microservice instance can also alert the user through the UI interface when the health check result of the microservice instance is unhealthy at the first moment.

[0085] It is understandable that, in the case where the first health condition is unhealthy, the registration device generates an unhealthy signal for the microservice instance and performs the corresponding subsequent operations only for the instance. In actual applications, these operations can be configured according to specific application scenarios, and no restrictions are imposed here.

[0086] 206. After sending the first health check request in the first time period, the registration device sends a second health check request to the microservice instance;

[0087] When the initial health status is healthy, the registration device sends a second health check request to the microservice instance after sending the first health check request for a first time period. The first time period can be a pre-set period length by the user through the interactive interface, such as performing a health check every 15 seconds after the microservice instance is created; alternatively, the first time period can be a system default period length, such as performing a health check every 30 seconds after the microservice instance is created.

[0088] For example, the specific implementation of the registration device sending a second health check request to the microservice instance is as follows:

[0089] class ThreadClass {

[0090] public void run(){

[0091] / / T0D0: Health monitoring module periodically checks the status of service instances.

[0092] }

[0093] }

[0094] It is understandable that the description here of the registration device sending a second health check request to the microservice instance and initiating a health check on the microservice instance is just an example. In actual applications, it can also be implemented in combination with other code, and there are no restrictions here.

[0095] 207. The registration device obtains the second health status sent by the microservice instance;

[0096] After the registration device sends a second health check request to the microservice instance, the microservice instance sends the second health status sent by the microservice instance to the health check module of the registration device.

[0097] If the second health condition is healthy, proceed to step 208;

[0098] If the second health condition is unhealthy, proceed to step 209.

[0099] 208. The registration device generates a health signal for the microservice instance;

[0100] When the second health condition is healthy, the registration device generates a health signal for the microservice instance.

[0101] For example, the registration device can record the health status of the microservice instance in the health check at a second time in the registration device's work log.

[0102] Optionally, the registration device can send a health signal to the microservice instance, enabling the microservice instance to record the health check result of the microservice instance at the second moment to the microservice instance's working log.

[0103] It is understandable that, when the second health condition is healthy, the registration device generates a microservice instance health signal and performs the corresponding subsequent operations only for the instance. In actual applications, these operations can be configured according to specific application scenarios, and no restrictions are imposed here.

[0104] 209. The registration device sends a deregistration request to the registration center.

[0105] When the second health condition is unhealthy, the registration module in the registration device sends a shutdown request to the registration center.

[0106] For example, the specific implementation of the registration device sending a deregistration request to the registration center is as follows:

[0107] if (checkhealth() == unhealthy) {

[0108] / / T0D0: Send a shutdown request to the registry center

[0109] }

[0110] It is understood that the description of the registration device sending a deregistration request to the registration center here is only an example. In actual applications, it can be implemented in combination with other code, and there are no restrictions here.

[0111] In this embodiment, when a microservice instance needs to send a registration message to the registry center after creation, the registration device intercepts the microservice creation and sends a first registration message to the registry center. Based on the microservice instance's port information, it sends a first health check request to the microservice instance and obtains the first health status of the microservice instance. If the first health status is healthy, it sends a second registration message to the registry center, enabling the microservice instance to complete its registration. If the first health status is unhealthy, it generates an unhealthy signal for the microservice instance. During the microservice instance's runtime phase, the registration device sends a second health check request and obtains the second health status of the microservice instance. If the second health status is healthy, it generates a healthy signal for the microservice instance. If the second health status is unhealthy, it sends a shutdown notification to the registry center, carrying the microservice instance's name, IP address, and port information. The registration device enables communication between microservice instances and the registry center. During the microservice instance startup phase, once it is confirmed that the microservice instance can work normally, a second registration message is sent to the registry center, allowing other microservice instances to call the microservice instance through the registry center. Furthermore, during the normal operation phase of the microservice, the registration device queries the health status of the microservice instance and promptly takes the microservice instance offline when a health failure occurs, thereby improving the reliability of the microservice instance.

[0112] To facilitate understanding the above Figure 2 The relationship between microservice instances, registration devices, and registration centers is explained below in conjunction with... Figure 3a and Figure 3b A brief introduction, Figure 3a This is a schematic diagram illustrating the working process of the microservice instance registration phase provided in an embodiment of this application. Figure 3b This is a schematic diagram illustrating the operation of a microservice instance during its runtime phase, as provided in an embodiment of this application.

[0113] Depend on Figure 3aAs can be seen, during the microservice instance registration phase, after the registration module obtains the registration message sent by the microservice instance, the health check module generates a first health check request and sends this first health check request to the health check interface to obtain the first health status of the microservice instance. Based on the first health status, it determines whether to send a second registration message to the registration center. If the first health status is healthy, then the second registration message is sent to the registration center.

[0114] Depend on Figure 3b As can be seen, during the microservice instance's runtime phase, the health check module periodically sends a second health check request to the health check interface to obtain the microservice instance's second health status. Based on this second health status, it determines whether to send a shutdown request to the registry center. If the second health status is unhealthy, a shutdown request is sent to the registry center. Simultaneously, the microservice instance periodically sends heartbeat messages to the registry center to assist the registry center in managing the microservice instance's runtime.

[0115] Based on the aforementioned approach, this paper introduces the proposed solution by taking the scenario of running a microservice instance directly after creation as an example. Please refer to [link / reference]. Figure 4 , Figure 4 This is another flowchart illustrating the method for managing microservice instances provided in an embodiment of this application.

[0116] 401. The registration device obtains the business startup information of the microservice instance;

[0117] When a microservice instance is run directly after creation, since the registration device and the microservice instance are in the same process, after the microservice instance is created, the registration device obtains the business startup information loaded by the microservice instance. The business startup information includes the name of the microservice instance, the IP address of the microservice instance, and the port information of the microservice instance.

[0118] 402. The registration device sends the first health check request to the microservice instance;

[0119] After obtaining the business startup information of the microservice instance, the registration device sends a first health check request to the health check interface of the microservice instance based on the port information of the microservice instance. The first health check request is used to obtain the health status of the microservice instance.

[0120] The specific implementation of the registration device sending the first health check request to the microservice instance is as described above. Figure 2 Step 202 is similar and will not be repeated here.

[0121] 403. The registration device obtains the first health status sent by the microservice instance;

[0122] After sending the first health check request to the microservice instance, the health check module of the registration device obtains the first health status sent by the health check interface of the microservice instance.

[0123] For example, after receiving the first health check message from the registration device, the microservice instance sends its current health status to the registration device. For instance, if the microservice instance is healthy, it sends a health signal; if it is unhealthy, it sends an unhealthy signal. The specific content of the health and unhealthy signals is not limited here. Alternatively, if the microservice instance is healthy, it sends a signal to the registration device; if it is unhealthy, due to the disconnection between the microservice instance and the registration device, after the waiting period, the registration device determines the microservice instance to be unhealthy.

[0124] It is understood that the description of the registration device obtaining the first health status of the microservice instance here is only an example. In actual applications, it should be set according to the specific application scenario, and no restrictions are imposed here.

[0125] If the first health condition is healthy, proceed to step 404;

[0126] If the first health condition is unhealthy, proceed to step 405.

[0127] 404. The registration device sends a second registration message to the registration center;

[0128] When the first health status is healthy, the registration module of the registration device generates a second registration message based on the name, IP address, and port information of the microservice instance, and sends the second registration message to the registration center. The second registration message carries the name, IP address, and port information of the microservice instance.

[0129] The specific implementation of the registration device sending the second registration message to the registration center is as described above. Figure 2 Step 204 is similar and will not be repeated here.

[0130] After the registration center receives the second registration message sent by the registration device, other microservice instances can directly call the microservice instance by accessing the registration center.

[0131] 405. The registration device generates an unhealthy signal for the microservice instance;

[0132] When the first health condition is unhealthy, the registration device does not need to report to the registration center. Instead, the registration device generates an unhealthy signal for the microservice instance so that technical personnel can verify it later.

[0133] For example, the registration device can record in its work log that a microservice instance is unhealthy in the first-time health check.

[0134] Optionally, the registration device can send an unhealthy signal to the microservice instance, enabling the microservice instance to record the health check result of the microservice instance in the microservice instance's working log at the first moment.

[0135] Furthermore, the registration device or microservice instance can also alert the user through the UI interface when the health check result of the microservice instance is unhealthy at the first moment.

[0136] It is understandable that, in the case where the first health condition is unhealthy, the registration device generates an unhealthy signal for the microservice instance and performs the corresponding subsequent operations only for the instance. In actual applications, these operations can be configured according to specific application scenarios, and no restrictions are imposed here.

[0137] 406. After sending the first health check request in the first time period, the registration device sends a second health check request to the microservice instance;

[0138] When the initial health status is healthy, the registration device sends a second health check request to the microservice instance after sending the first health check request for a first time period. The first time period can be a pre-set period length by the user through the interactive interface, such as performing a health check every 15 seconds after the microservice instance is created; alternatively, the first time period can be a system default period length, such as performing a health check every 30 seconds after the microservice instance is created.

[0139] The specific implementation of the registration device sending a second health check request to the microservice instance after sending the first health check request in the first time period is as described above. Figure 2 Step 206 is similar and will not be repeated here.

[0140] 407. The registration device obtains the second health status sent by the microservice instance;

[0141] After the registration device sends a second health check request to the microservice instance, the microservice instance sends the second health status sent by the microservice instance to the health check module of the registration device.

[0142] If the second health condition is healthy, proceed to step 408;

[0143] If the second health condition is unhealthy, proceed to step 409.

[0144] 408. The registration device sends a heartbeat message to the registration center;

[0145] After obtaining the second health test result, if the second health result is healthy, the registration device sends a heartbeat message to the registration center.

[0146] Optionally, the registration device can also send a heartbeat message to the registration center at a preset time. The preset time is the time set by the user through the interactive interface. In some possible cases, the preset time can be a periodic time point, and there is no restriction here.

[0147] Specifically, the registration device sends heartbeat messages to the registration center as follows:

[0148] while(isRunning{

[0149] / / Has the timeout period for sending heartbeat messages been reached?

[0150] if(startTime-lastHeartbeat>heartBeatInterval){

[0151] / / T0D0: Send heartbeat message to the registry center

[0152] }

[0153] }

[0154] It is understood that the description of the registration device sending messages to the registration center here is only an example. In actual applications, it can be combined with other code implementations, and there are no restrictions here.

[0155] 409. The registration device sends a deregistration request to the registration center.

[0156] After obtaining the second health check result, if the second health check result is unhealthy, the registration device sends a deregistration request to the registration center.

[0157] The specific implementation details of the registration device sending a deregistration request to the registration center are as described above. Figure 2 Step 209 is similar and will not be repeated here.

[0158] In this embodiment, in scenarios where microservice instance creation does not require sending a registration message to the registry center, the registration device intercepts the business startup information sent to the business after the microservice instance is created, sends a first health check request to the microservice instance, and obtains the first health status sent by the microservice instance. If the first health status is healthy, a second registration message is sent to the registry center, enabling the microservice instance to complete its registration with the registry center; if the first health status is unhealthy, an unhealthy signal for the microservice instance is generated. During the microservice instance's runtime phase, the registration device sends a second health check request and obtains the second health status sent by the microservice instance. When the second health status is healthy, a heartbeat message is sent to the registry center; when the second health status is unhealthy, a shutdown notification is sent to the registry center. The registration device achieves information synchronization between the microservice instance and the registry center, providing the registry center with the possibility to manage microservice instances without changing the existing microservice instance operation method, thus improving the manageability of microservice instances.

[0159] To facilitate understanding the above Figure 4 The relationship between microservice instances, registration devices, and the registration center in [the context of the system] is explained below in conjunction with [other methods]. Figure 5a and Figure 5b Let me give you a brief introduction. Figure 5a This is another schematic diagram illustrating the working process of the microservice instance registration phase provided in the embodiments of this application. Figure 5b This is another schematic diagram illustrating the working process of a microservice instance during its runtime phase, as provided in the embodiments of this application.

[0160] Depend on Figure 5a As can be seen, during the microservice instance registration phase, after the registration module obtains the business startup information sent by the microservice instance, the health detection module generates a first health detection request and sends this request to the health detection interface to obtain the first health status of the microservice instance. Based on the first health status, it determines whether to send a second registration message to the registration center. If the first health status is healthy, the second registration message is sent to the registration center.

[0161] Depend on Figure 5b It can be seen that during the microservice instance's runtime phase, the health detection module periodically sends a second health detection request to the health detection interface to obtain the second health status of the microservice instance. If the second health status is unhealthy, it sends a shutdown request to the registry center; if the second health status is healthy, it sends a heartbeat message to the registry center.

[0162] The microservice instance management method provided in this application has been described above. The microservice instance management device provided in this application will now be described in conjunction with the accompanying drawings:

[0163] Please see Figure 6 , Figure 6This is a schematic diagram of a microservice instance management device provided in an embodiment of this application.

[0164] Microservice instance management device, including:

[0165] The acquisition unit 601 is used to acquire first information of the microservice instance, the first information carrying the name of the microservice instance, the Internet Protocol IP of the microservice instance and the port information of the microservice instance;

[0166] Sending unit 602 is used to send a first health check request to the microservice instance based on the port information of the microservice instance;

[0167] The acquisition unit 601 is further configured to acquire the first health status of the microservice instance sent by the microservice instance;

[0168] The sending unit 602 is further configured to send a second registration message to the registration center if the first health status is healthy. The second registration message carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

[0169] Optionally, the apparatus further includes a generation unit 603, configured to generate a microservice instance unhealthy signal if the first health condition is unhealthy.

[0170] Optionally, the sending unit 602 is further configured to send a second health check request to the microservice instance after sending the first health check request for a first time period;

[0171] The acquisition unit 601 is also used to acquire the second health status sent by the microservice instance;

[0172] The sending unit 602 is further configured to send a shutdown request to the registration center if the second health condition is unhealthy. The shutdown request carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

[0173] Optionally, the acquisition unit 601 is further configured to acquire the first time period based on the user's operation on the operation interface, wherein the first time period is the interval between the first health detection request and the second health request.

[0174] Optionally, the first information includes the first registration message sent by the microservice instance to the registration center.

[0175] Optionally, the first information includes the business startup information of the microservice instance;

[0176] The acquisition unit 601 is specifically used to acquire the business startup information of the microservice instance loaded when the microservice instance is created.

[0177] Optionally, the sending unit 602 is further configured to send a heartbeat message to the registry center if the second health status is healthy, the heartbeat message indicating that the microservice instance can work normally.

[0178] In addition, this application also provides a microservice instance management apparatus, please refer to [link to relevant documentation]. Figure 7 , Figure 7 This is another schematic diagram of the apparatus for managing microservice instances provided in the embodiments of this application.

[0179] The microservice instance management device 700 includes a bus 702, a processor 704, a memory 706, and a communication interface 708. The processor 704, memory 706, and communication interface 708 communicate via the bus 702. The microservice instance management device 700 can be a server or a terminal device. It should be understood that this application does not limit the number of processors and memory in the microservice instance management device 700.

[0180] The 702 bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. Buses can be categorized as address buses, data buses, control buses, etc. For ease of representation, Figure 7 The bus 702 is represented by a single line, but this does not mean that there is only one bus or one type of bus. The bus 702 may include a path for transmitting information between various components of the microservice instance management device 700 (e.g., memory 706, processor 704, communication interface 708).

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

[0182] The memory 706 may include volatile memory, such as random access memory (RAM). The processor 704 may also include non-volatile memory, such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid state drive (SSD).

[0183] The memory 706 stores executable program code, and the processor 704 executes the executable program code to implement the functions of the aforementioned acquisition unit 601, transmission unit 602, and generation unit 603, thereby implementing any one of the methods in the data storage method. That is, the memory 706 stores instructions for executing any one of the methods in the data storage method.

[0184] Alternatively, the memory 706 stores executable code, which the processor 704 executes to implement the functions of the aforementioned access points, thereby implementing any one of the methods in the data storage method. That is, the memory 706 stores instructions for executing any one of the methods in the data storage method.

[0185] The communication interface 708 uses transceiver modules such as, but not limited to, network interface cards and transceivers to enable communication between the computing microservice instance management device 700 and other devices or communication networks.

[0186] Please see Figure 8 , Figure 8 This is a schematic diagram of a computing device cluster provided in an embodiment of this application.

[0187] The computing device cluster includes at least one computing device. This computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smartphone.

[0188] like Figure 8 As shown, the computing device cluster includes at least one microservice instance management device 700. The memory 706 in one or more microservice instance management devices 700 within the computing device cluster may store the same instructions for executing any of the methods in the data storage method.

[0189] In some possible implementations, the memory 706 of one or more microservice instance management devices 700 in the computing device cluster may also store partial instructions for executing any one of the methods in the data storage method. In other words, a combination of one or more microservice instance management devices 700 can jointly execute the instructions for executing any one of the methods in the data storage method.

[0190] It should be noted that the memory 706 in different microservice instance management devices 700 within the computing device cluster can store different instructions, each used to execute a portion of the cloud management platform's functions. That is, the instructions stored in the memory 706 of different microservice instance management devices 700 can implement the functions of one or more units among the acquisition unit 601, the sending unit 602, and the generation unit 603.

[0191] In some possible implementations, the devices managing one or more microservice instances within a computing device cluster can be connected via a network. This network can be a wide area network (WAN), a local area network (LAN), or similar.

[0192] Please see Figure 9 , Figure 9 This is a schematic diagram of another structure of the computing device cluster provided in an embodiment of this application.

[0193] like Figure 9 As shown, the two microservice instance management devices 700A and 700B are connected via a network. Specifically, they are connected to the network through communication interfaces in each computing device. In this possible implementation, the memory 706 of the microservice instance management device 700A stores instructions for executing the functions of the acquisition unit 601. Simultaneously, the memory 706 of the microservice instance management device 700B stores instructions for executing the functions of the sending unit 602 and the generating unit 603.

[0194] It should be understood that Figure 9 The functions of the microservice instance management device 700A shown can also be performed by multiple microservice instance management devices 700. Similarly, the functions of the microservice instance management device 700B can also be performed by multiple microservice instance management devices 700.

[0195] This application also provides another computing device cluster. The connection relationships between the computing devices in this computing device cluster can be similarly referred to... Figure 8 and Figure 9 The connection method of the computing device cluster is different in that the memory 706 in one or more microservice instance management devices 700 in the computing device cluster can store the same instructions for executing any of the methods in the data storage method.

[0196] In some possible implementations, the memory 706 of one or more microservice instance management devices 700 in the computing device cluster may also store partial instructions for executing any one of the methods in the data storage method. In other words, a combination of one or more microservice instance management devices 700 can jointly execute the instructions for executing any one of the methods in the data storage method.

[0197] It should be noted that the memory 706 in the different microservice instance management devices 700 in the computing device cluster can store different instructions for performing some functions of the data storage method.

[0198] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0199] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be an indirect coupling or communication connection between apparatuses or units through some interfaces, and may be electrical, mechanical, or other forms.

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

[0201] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0202] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

Claims

1. A microservice instance management method, characterized in that, Applied to a registration device, wherein the registration device and the microservice instance reside in the same process, the method includes: Obtain first information about the microservice instance, the first information carrying the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance; A first health check request is sent to the microservice instance based on the port information of the microservice instance; Obtain the first health status of the microservice instance sent by the microservice instance; If the first health status is healthy, a second registration message is sent to the registration center. The second registration message carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

2. The method according to claim 1, characterized in that, The method further includes: If the first health condition is unhealthy, an unhealthy signal for the microservice instance is generated.

3. The method according to claim 1, characterized in that, The method further includes: After sending the first health check request for a first time period, a second health check request is sent to the microservice instance; Obtain the second health status sent by the microservice instance; If the second health condition is unhealthy, a shutdown request is sent to the registry center. The shutdown request carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

4. The method according to claim 3, characterized in that, Before sending the second health check request to the microservice instance, the method further includes: Based on the user's actions on the interface, the first time period is obtained, which is the interval between the first health check request and the second health check request.

5. The method according to any one of claims 1 to 4, characterized in that, The first information includes the first registration message sent by the microservice instance to the registration center.

6. The method according to any one of claims 1 to 4, characterized in that, The first information includes the business startup information of the microservice instance; The first information obtained about the microservice instance includes: Obtain the business startup information of the microservice instance loaded when the microservice instance is created.

7. The method according to any one of claims 3 or 4, characterized in that, The method further includes: If the second health status is healthy, a heartbeat message is sent to the registry center, indicating that the microservice instance can work normally.

8. A microservice instance management device, characterized in that, The microservice instance management device is a registration device, which resides in the same process as the microservice instance, and includes: The acquisition unit is used to acquire first information of the microservice instance, the first information carrying the name of the microservice instance, the Internet Protocol IP of the microservice instance, and the port information of the microservice instance; The sending unit is configured to send a first health check request to the microservice instance based on the port information of the microservice instance; The acquisition unit is further configured to acquire the first health status of the microservice instance sent by the microservice instance; The sending unit is further configured to send a second registration message to the registration center if the first health status is healthy. The second registration message carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

9. The apparatus according to claim 8, characterized in that, The device further includes a generation unit, used to generate an unhealthy signal for the microservice instance if the first health condition is unhealthy.

10. The apparatus according to claim 8, characterized in that, The sending unit is further configured to send a second health check request to the microservice instance after sending the first health check request for a first time period; The acquisition unit is also used to acquire the second health status sent by the microservice instance; The sending unit is further configured to send a shutdown request to the registration center if the second health condition is unhealthy. The shutdown request carries the name of the microservice instance, the Internet Protocol IP address of the microservice instance, and the port information of the microservice instance.

11. The apparatus according to claim 10, characterized in that, The acquisition unit is further configured to acquire the first time period based on the user's operation on the interface, wherein the first time period is the interval between the first health detection request and the second health detection request.

12. The apparatus according to any one of claims 8 to 11, characterized in that, The first information includes the first registration message sent by the microservice instance to the registration center.

13. The apparatus according to any one of claims 8 to 11, characterized in that, The first information includes the business startup information of the microservice instance; The acquisition unit is specifically used to acquire the business startup information of the microservice instance loaded when the microservice instance is created.

14. The apparatus according to any one of claims 10 or 11, characterized in that, The sending unit is further configured to send a heartbeat message to the registration center if the second health status is healthy, the heartbeat message indicating that the microservice instance can work normally.

15. A microservice instance management device, characterized in that, It includes a processor and a memory, the memory being used to store instructions, the processor being used to execute the instructions, and when the processor executes the instructions, it performs the method as described in any one of claims 1 to 7.

16. A computing device cluster, characterized in that, It includes at least one computing device, each computing device including a processor and memory; The processor of the at least one computing device is configured to execute instructions stored in the memory of the at least one computing device to cause the cluster of computing devices to perform the method as described in any one of claims 1 to 7.

17. A computer-readable storage medium, characterized in that, Includes a program that, when run on a computer, causes the computer to perform the method as described in any one of claims 1 to 7.

18. A computer program product containing instructions, characterized in that, When the instruction is executed by the computing device cluster, the computing device cluster causes the computing device cluster to perform the method as described in any one of claims 1 to 7.

Images