Micro-service alive detection registration method and device

Abstract

The present specification relates to the technical field of cloud computing, and provides a micro-service live detection registration method and device. The method comprises: receiving a target micro-service live detection request; calling a registration state of a target micro-service according to the live detection request; performing live detection on the target micro-service through the live detection request to obtain a target micro-service live detection state; determining a target micro-service state by using the live detection state and the registration state; and registering the current target micro-service in a micro-service registration center if the target micro-service state is a down-to-live state. Through the embodiment of the present specification, the micro-service component can be adapted to various micro-service systems without accessing an SDK, and no error occurs when the micro-service component is online or offline, the problem of traffic loss is avoided, the development efficiency is improved, and the labor cost is reduced.

Description

Technical Field

[0001] This specification relates to the field of cloud computing technology, and in particular to a microservice activation and registration method and apparatus. Background Technology

[0002] Microservices (or microservice architecture) is a cloud-native architectural approach that includes numerous loosely coupled and independently deployable small components or services within a single application. Microservices allow for the addition of new features or functionalities without affecting the entire application, easier code updates, and the use of different technology stacks and programming languages ​​for different components. Components can scale independently of each other, thereby reducing the waste and costs associated with having to scale the entire application (because a single function may face excessive load).

[0003] The difference between microservices and monolithic architectures lies in the fact that microservices consist of many loosely coupled small services forming a single application, rather than the tightly coupled monolithic approach of large applications. However, microservices also imply greater management complexity. In a microservice architecture, there is typically more than one service provider node. The consumer selects a healthy node for execution based on a load balancing algorithm (a technique that distributes load or tasks across multiple servers). A healthy node is one that can respond normally to the consumer's requests, while an unhealthy node is one that cannot. The reasons for being unhealthy may include physical power outages, network outages, hardware failures, network latency, abnormal process exits, or a process's inability to handle requests. In short, the service provider node cannot process requests until the traffic is removed.

[0004] Only by determining whether the service provider's nodes are healthy or unhealthy can we ensure that the microservice system can process requests normally. Therefore, it is necessary to probe the liveness of the service provider's nodes. Existing microservice frameworks and service governance frameworks, such as Spring Cloud and Kubernetes, all provide liveness detection functions for microservice components. However, simply probing the liveness of microservice components can be problematic in some business scenarios when microservice components are being deployed or deactivated. For example, for a microservice component that requires initialization, if traffic comes in before all initialization actions are completed, in addition to traffic loss, the microservice component cannot be accessed normally, which may affect the user's experience of the entire microservice system.

[0005] Furthermore, mainstream microservice frameworks, such as Spring Cloud, require the integration of an intrusive SDK into native services to ensure the normal operation of microservice systems. This SDK enables microservice registration and liveness detection, which suffers from high development complexity, low development efficiency, and high labor costs. Therefore, there is an urgent need for a microservice liveness detection and registration method that can adapt microservice components to various microservice systems without integrating an SDK, and prevent errors when microservice components are taken offline or taken offline, thus avoiding traffic loss issues, improving development efficiency, and reducing labor costs. Summary of the Invention

[0006] Given that current microservice registration and activation methods suffer from high development complexity, low development efficiency, and high labor costs, this solution is proposed to overcome or at least partially solve these problems.

[0007] On the one hand, the purpose of some embodiments of this specification is to provide a microservice activation registration method, the method including: receiving a target microservice activation request;

[0008] The registration status of the target microservice is invoked based on the activation request;

[0009] The target microservice is probed for activity using the probe request to obtain the probe status of the target microservice.

[0010] The target microservice status is determined using the probe status and the registration status;

[0011] If the target microservice is in a state of being switched from downtime to live, then the current target microservice is registered in the microservice registry.

[0012] Furthermore, both the registered state and the target microservice state include a crash state, a live state, a crash-to-live state, and a live-to-crash state.

[0013] Further, the step of probing the target microservice through the probing request to obtain the probing status of the target microservice includes:

[0014] The probe request is used to send probe information to the target microservice cyclically at a first time interval;

[0015] The probe activity status of the target microservice is determined based on whether the target microservice responds to the probe information within a first time period.

[0016] Further, determining the corresponding probe activity status based on whether the target microservice responds to the probe information within a first time period includes:

[0017] If the target microservice responds to all the probe information within the first time period, then the probe liveness state is a liveness state;

[0018] If not all responses are received, the probe status is considered a downtime state.

[0019] Furthermore, determining the target microservice state using the probe state and the registration state includes:

[0020] If the probe status is alive and the storage status is not down, then the target microservice status is alive.

[0021] If the probe status is alive and the storage status is down, then the target microservice status is down-to-live.

[0022] If the probe status is a downtime state and the registration status is not a live state, then the target microservice status is a downtime state.

[0023] If the probe status is down and the registration status is alive, then the probe for the target microservice will be retried.

[0024] Furthermore, if the probe status is a downtime state and the registration status is a live state, then retrying the probe for the target microservice includes:

[0025] Record the number of probe information sent and the number of responses to the target microservice within the first time period;

[0026] The downtime rate of the target microservice is calculated based on the number of sends and the number of responses.

[0027] If the downtime rate is less than the first threshold, then probe information is sent to the current target microservice cyclically at a second time interval;

[0028] Determine whether the target microservices respond to the probe information within the second time period;

[0029] If all the target microservices respond to the probe information within the second time period, then the probe liveness status is a liveness status, and the current target microservice status is a liveness status.

[0030] If the target microservice fails to respond to all the probe information within the second time period, the probe status becomes a downtime state, and the current target microservice status changes from a live to a downtime state.

[0031] Furthermore, if the downtime rate is not less than the first threshold, the liveness detection state is still a downtime state, and the current target microservice state is a live-to-downtime state.

[0032] Furthermore, if the target microservice is in a state of being switched from downtime to live, then the current target microservice is registered in the microservice registry, including:

[0033] Receive registration request;

[0034] The microservice information of the target microservice is written to the microservice registry center according to the registration request.

[0035] Furthermore, when probing the target microservice using the probing request, communication is conducted using either the TCP or HTTP protocol.

[0036] Furthermore, if the target microservice is in a state of transition from downtime to live, then the current target microservice is registered in the microservice registry. This further includes, if the target microservice is in a state of transition from live to downtime, then the current target microservice is deregistered in the microservice registry.

[0037] Furthermore, if the target microservice is in a state of transitioning from live to downtime, then the current target microservice is deregistered in the microservice registry, including:

[0038] Receive cancellation request;

[0039] Obtain the cancellation time point corresponding to the cancellation request;

[0040] Determine the cancellation time interval after the third time interval from the aforementioned cancellation time point;

[0041] Deregister the current target microservice in the microservice registry within the specified deregistration time interval.

[0042] On the other hand, some embodiments of this specification also provide a microservice activation registration device, the device comprising:

[0043] The receiving module is used to receive liveness detection requests from the target microservice;

[0044] The calling module is used to call the storage status of the target microservice based on the liveness detection request;

[0045] The liveness detection module is used to detect the liveness of the target microservice through the liveness detection request in order to obtain the liveness detection status of the target microservice.

[0046] The determination module is used to determine the target microservice status using the detection status and the registration status;

[0047] The registration module is used to register the target microservice in the microservice registry if the target microservice is in a state of being switched from being down to being alive.

[0048] On the other hand, some embodiments of this specification also provide a computer device, including a memory, a processor, and a computer program stored in the memory, which, when run by the processor, executes instructions for the methods described above.

[0049] On the other hand, some embodiments of this specification also provide a computer storage medium having a computer program stored thereon, which, when run by the processor of a computer device, executes instructions for the methods described above.

[0050] On the other hand, some embodiments of this specification also provide a computer program product, which includes a computer program that, when run by the processor of a computer device, executes instructions for the methods described above.

[0051] Some embodiments of this specification provide one or more technical solutions, which have at least the following technical effects:

[0052] The embodiments in this specification automatically receive the target microservice liveness test request, call the registered status of the target microservice, and perform liveness test on the target microservice to obtain the liveness test status. Based on the registered status and the liveness test status, the target microservice status is determined, thereby improving the accuracy of the obtained target microservice status. The microservices corresponding to the target microservice status of being switched from downtime to liveness are registered to the microservice registry center, so that the traffic is not lost when the microservice goes online or offline.

[0053] The above description is merely an overview of some embodiments of the technical solutions in this specification. In order to better understand the technical means of some embodiments of this specification and to implement them in accordance with the content of the specification, and to make the above and other objects, features and advantages of some embodiments of this specification more apparent and understandable, specific implementation methods of some embodiments of this specification are given below. Attached Figure Description

[0054] To more clearly illustrate some embodiments or technical solutions in the prior art of this specification, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are merely some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without any creative effort. In the drawings:

[0055] Figure 1 The following is a schematic diagram of an implementation system for the microservice activation and registration method in some embodiments of this specification;

[0056] Figure 2 A flowchart of a microservice activation registration method is shown in some embodiments of this specification;

[0057] Figure 3a This is a schematic diagram illustrating the steps for determining the state of a target microservice in some embodiments of this specification;

[0058] Figure 3b This is a flowchart illustrating the process of determining the state of a target microservice in some embodiments of this specification;

[0059] Figure 4 This is a schematic diagram illustrating the steps of reactivating the target microservice in some embodiments of this specification;

[0060] Figure 5 This document provides schematic diagrams illustrating the steps for unregistering the current target microservice in some embodiments.

[0061] Figure 6 This is a schematic diagram of the structure of a microservice activation registration device in some embodiments of this specification;

[0062] Figure 7 This is a schematic diagram of the computer device structure provided in some embodiments of this specification.

[0063] [Explanation of Labels in the Attached Image]

[0064] 1. Microservice exploration and registration system;

[0065] 101. Terminal;

[0066] 102. Server;

[0067] 61. Receiving module;

[0068] 62. Call the module;

[0069] 63. Detection module;

[0070] 64. Determine the module;

[0071] 65. Registration module;

[0072] 702. Computer equipment;

[0073] 704, Processor;

[0074] 706. Memory;

[0075] 708. Drive mechanism;

[0076] 710. Input / output interfaces;

[0077] 712. Input devices;

[0078] 714. Output devices;

[0079] 716. Presentation equipment;

[0080] 718. Graphical User Interface;

[0081] 720. Network interface;

[0082] 722. Communication link;

[0083] 724. Communication bus. Detailed Implementation

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

[0085] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings herein are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, apparatus, product, or device that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or devices. It should be noted that the acquisition, storage, use, and processing of data in the technical solutions of this application comply with the relevant provisions of national laws and regulations.

[0086] like Figure 1The diagram illustrates an implementation system for a microservice activation and registration method according to an embodiment of the present invention. The system may include: a microservice activation and registration system 1, a terminal 101, and a server 102. The terminal 101 and server 102 communicate via a network, which may include a Local Area Network (LAN), a Wide Area Network (WAN), the Internet, or a combination thereof, and is connected to a website, user equipment (e.g., a computing device), and a backend system. A user can send a target microservice activation request to the server 102 via the terminal 101. Upon receiving the request, the server 102 retrieves the registered status of the target microservice, performs calculations to obtain the activation status, and feeds back the result to the terminal 101, enabling the microservice to go online or offline based on the result.

[0087] In the embodiments of this specification, the server 102 may be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDN), and big data and artificial intelligence platforms.

[0088] In an optional embodiment, terminal 101 may be an electronic device, including but not limited to self-service terminal equipment, desktop computers, tablet computers, laptops, smart wearable devices, etc. Optionally, the operating system running on the electronic device may include, but is not limited to, Android, iOS, Linux, Windows, etc. Of course, terminal 101 is not limited to the aforementioned physical electronic devices; it may also be software running on the aforementioned electronic devices.

[0089] In addition, it should be noted that, Figure 1 The example shown is merely one application environment provided by this disclosure. In practical applications, it may include multiple terminals 101, and this specification does not impose any restrictions.

[0090] Figure 2 This is a flowchart of a microservice activation and registration method provided by an embodiment of the present invention. This specification provides the operational steps of the method described in the embodiments or flowchart, but based on conventional or non-inventive methods, more or fewer operational steps may be included. The order of steps listed in the embodiments is merely one possible execution order among many and does not represent the only execution order. In actual system or device products, the methods can be executed sequentially or in parallel according to the embodiments or accompanying drawings. Specifically, as shown in the flowchart... Figure 2 As shown, the method, executed by the server side described above, may include:

[0091] S201: Receive the liveness probe request for the target microservice;

[0092] S202: Inquire about the registration status of the target microservice according to the activation request;

[0093] S203: Use the liveness probe request to probe the target microservice to obtain the liveness probe status of the target microservice;

[0094] S204: Determine the target microservice status using the probe status and the registration status;

[0095] S205: If the target microservice is in a state of being switched from downtime to live, then register the current target microservice in the microservice registry.

[0096] The embodiments in this specification automatically receive the target microservice liveness test request, call the registered status of the target microservice, and perform liveness test on the target microservice to obtain the liveness test status. Based on the registered status and the liveness test status, the target microservice status is determined, thereby improving the accuracy of the obtained target microservice status. The microservices corresponding to the target microservice status of being switched from downtime to liveness are registered to the microservice registry center, so that the traffic is not lost when the microservice goes online or offline.

[0097] Specifically, in some embodiments, microservices, also known as microservice architecture, are a software architecture approach that builds an application into a series of small, autonomous services divided into modules based on business domains. In a microservice architecture, each service is self-contained and implements a single business function. Different microservices can be implemented using different programming languages ​​and different storage technologies. During liveness testing, the health of a microservice is assessed. Health can be understood as the ability to respond normally to consumer requests, while unhealthiness means the inability to respond normally. A liveness test request is a request to check whether a microservice can communicate normally or operate normally (i.e., whether it is healthy). Registered state refers to the microservice's state at the time of the last liveness test; it's a historical state that may remain unchanged or change during subsequent liveness tests. Liveness test state refers to the response state of the target microservice detected under the current liveness test request. The registered state corresponding to a crash-to-live state is a crash state, and the liveness test state is a live state. The microservice registry can be understood as the "address book" in a microservice architecture, recording the mapping relationship between multiple microservices and their addresses. In a distributed system, microservices register with the microservice registry. When a microservice needs to call other microservices, it looks up the address of the target microservice in the registry and makes the call. Furthermore, the microservice registry also solves the problem of microservices being discoverable by all microservices in the system after registration and the problem of microservices going offline after a crash.

[0098] In some embodiments, the registered state and the target microservice state can both include a crash state, a live state, a crash-to-live state, and a live-to-crash state.

[0099] In some embodiments, the registered state can be understood as the target microservice state obtained from the last detection. Therefore, both the registered state and the target microservice state can include four states: downtime, live, downtime-to-live, and live-to-downtime. The downtime state means that the current microservice is offline, unable to respond to consumer requests, and not registered in the microservice registry. The live state means that the current microservice is online, can respond to consumer requests, and has been registered in the microservice registry. The downtime-to-livetime state means that the current microservice has gone from offline to online but has not yet been registered in the microservice registry. The live-to-downtime state means that the current microservice has gone from online to offline but has not yet been deregistered in the microservice registry.

[0100] In some embodiments, the step of probing the target microservice using the probe request to obtain the probe status of the target microservice may include:

[0101] The probe request is used to send probe information to the target microservice cyclically at a first time interval;

[0102] The probe activity status of the target microservice is determined based on whether the target microservice responds to the probe information within a first time period.

[0103] It can be understood that, in some embodiments, the probe information is used to detect whether the microservice is healthy. The probe information is sent to the target microservice cyclically at a first time interval. Then, the probe status of the target microservice can be determined based on the response of the target microservice within the first time period. It should be noted that the first time period is not less than the first time interval, and the first time period may include one or more first time intervals.

[0104] In some embodiments, determining the corresponding probe activity status based on whether the target microservice responds to the probe information within a first time period may include:

[0105] If the target microservice responds to all the probe information within the first time period, then the probe liveness state is a liveness state;

[0106] If not all responses are received, the probe status is considered a downtime state.

[0107] In some embodiments, assuming the target microservice is healthy, it can respond to all probe messages sent within a first time period. The probe messages may include numbered tags. Based on the numbered tags, it can be determined which probe messages are responded to, thereby determining the number of probe messages responded to within the first time period. This number is then compared with the total number of probe messages sent within the first time period to determine whether the target microservice has responded to all probe messages. If so, the probe liveness status is a live state; if not all probe messages are responded to, the probe liveness status is a down state.

[0108] See attached document Figure 3a In some embodiments, determining the target microservice state using the probe state and the registration state may include:

[0109] S301: If the probe state is alive and the registration state is not down, then the target microservice state is alive.

[0110] S302: If the probe state is alive and the registration state is down, then the target microservice state is from down to alive.

[0111] S303: If the probe state is a downtime state and the registration state is not a live state, then the target microservice state is a downtime state;

[0112] S304: If the probe status is down and the registration status is alive, then the probe for the target microservice is retried.

[0113] Specifically, in some embodiments, reference is made to the appendix. Figure 3b When the registered state is not in a down state (i.e., STILL_DOWN), meaning the registered state is in a live state (i.e., STILL_UP), or a down state transitioning to a live state (i.e., DOWN_TO_UP), or a live state transitioning to a down state (i.e., UP_TO_DOWN), if the probe status is live, then the target microservice is in a live state. When the registered state is not live, meaning the registered state is in a down state, or a down state transitioning to a live state, or a live state transitioning to a down state, if the probe status is down, then the target microservice is in a down state. When the registered state is down and the probe status is live, then the target microservice is in a down state transitioning to a live state. When the registered state is live but the probe status is down, the target microservice is not directly considered to be in a live state transitioning to a down state. Instead, the probe status is retried, because sometimes a brief network error may cause the probe status to appear as down, while the actual target microservice status remains live.

[0114] See attached document Figure 4 In some embodiments, the step of retrying the liveness probe on the target microservice if the probe status is down and the registration status is live may include:

[0115] S401: Record the number of probe information sent and the number of responses to the target microservice within the first time period;

[0116] S402: Calculate the downtime rate of the target microservice based on the number of sends and the number of responses;

[0117] S403: If the downtime rate is less than the first threshold, then probe information is sent to the current target microservice cyclically at a second time interval;

[0118] S404: Determine whether the current target microservice has responded to all the probe information within the second time period;

[0119] S405: If all the current target microservices respond to the probe information within the second time period, then the probe liveness state is the liveness state, and the current target microservice state is the liveness state;

[0120] S406: If the current target microservice does not fully respond to the probe information within the second time period, the probe status is a downtime state, and the current target microservice status is a live-to-downtime state.

[0121] Specifically, in some embodiments, if the result of a retry to reactivate the target microservice is a live state, it indicates that the previous live state was unreliable, and the current target microservice state is live. If the result of a retry to reactivate the target microservice is a down state, it indicates that the previous live state was reliable, and the current target microservice state is a transition from live to down. Specifically, how to perform a live retry: First, record the number of probe messages sent and the number of responses to the target microservice within a first time period. Subtract the number of responses from the number of sends to obtain the number of unresponded messages. Calculate the downtime rate based on the ratio of unresponded messages to sent messages. If the downtime rate is less than a first threshold, it indicates that the proportion of the target microservice not responding to probe messages within the first time period is not too high. In this case, a live reactivation is required. In some embodiments, during the reactivation, probe messages are sent to the current target microservice cyclically at a second time interval, and the corresponding live state is determined based on the response status of the current target microservice.

[0122] In some embodiments, if the downtime rate is not less than a first threshold, the liveness detection state is still a downtime state, and the current target microservice state is a live-to-downtime state.

[0123] It can be understood that, in some embodiments, if the downtime rate is not less than the first threshold, it means that the proportion of the target microservice that does not respond to the probe information is relatively high within the first time period. The downtime state can be directly regarded as the probe live state. Accordingly, the current state of the target microservice is the live-to-downtime state.

[0124] In some embodiments, if the target microservice is in a state of being switched from downtime to live, registering the current target microservice in the microservice registry may include:

[0125] Receive registration request;

[0126] The microservice information of the target microservice is written to the microservice registry center according to the registration request.

[0127] In some embodiments, the target microservice is only registered in the microservice registry when its state changes from downtime to live. This is because when the target microservice is live, it is already registered in the microservice registry, so there is no need to repeat the registration process and waste resources. When the target microservice is down, it does not need to be registered in the microservice registry because there is no need to call or register it, thus avoiding resource consumption. When the target microservice changes from live to down, it is already registered in the microservice registry and there is no need to call or register it. Furthermore, microservice information refers to the information needed for calling, registering, and discovering microservices, which may include the microservice name, Internet Protocol address, port name, service instance metadata, etc. When registering a target microservice, its microservice information needs to be written to the microservice registry. In addition, registering the target microservice when its state changes from downtime to live ensures that traffic is not wasted and microservice call requests can be responded to.

[0128] In some embodiments, the probe request is used to probe the target microservice using either TCP or HTTP protocols.

[0129] In some embodiments, microservices can communicate with each other using either TCP or HTTP protocols. Similarly, when probing the activity of a target microservice, either TCP or HTTP protocols can be used. HTTP, also known as Hypertext Transfer Protocol, is an application layer protocol used in distributed, collaborative, and hypermedia information systems. TCP, also known as Transmission Control Protocol, is a connection-oriented, reliable, byte-stream-based transport layer communication protocol. When probing the activity of a target microservice, TCP-based probing can generally detect the status of the microservice process, while HTTP-based probing can detect not only the liveness of the microservice process but also whether the microservice process can provide services normally.

[0130] Furthermore, in some embodiments, if the target microservice is in a state of transition from downtime to live, then the current target microservice is registered in the microservice registry. This may further include, if the target microservice is in a state of transition from live to downtime, then the current target microservice is deregistered in the microservice registry.

[0131] Specifically, in some embodiments, when the target microservice is in a state of transition from live to down, the target microservice has already been registered in the microservice registry and has no need to be called or registered. In this case, it is necessary to deregister the current target microservice in the microservice registry to avoid wasting resources.

[0132] See attached document Figure 5In some embodiments, the step of deregistering the current target microservice in the microservice registry if the target microservice's status is transitioning from live to downtime may include:

[0133] S501: Receive cancellation request;

[0134] S502: Obtain the cancellation time point corresponding to the cancellation request;

[0135] S503: Determine the cancellation time interval after the third time interval from the cancellation time point;

[0136] S504: Deregister the current target microservice in the microservice registry within the specified deregistration time interval.

[0137] In some embodiments, when deregistering the current target microservice, directly deregistering the microservice information written to the microservice registry after receiving the deregistration request may cause some requests to be interrupted and some microservices that are being called to fail, resulting in the corresponding microservice running failure or termination. Therefore, the deregistration action is performed on the microservice after receiving the deregistration request for a period of time (i.e., the third time interval) so that the microservice can complete the final process. At the same time, when performing the deregistration action, it is necessary to complete the deregistration action within the deregistration time interval after the third time interval, because it is not advisable to wait too long before deregistering to avoid occupying resources.

[0138] It should be noted that although the operation of the method of the present invention has been described in a specific order in the above embodiments and figures, this does not require or imply that the operations must be performed in that specific order, or that all the operations shown must be performed to achieve the desired result. Additionally or alternatively, certain steps may be omitted, multiple steps may be combined into one step, and / or one step may be broken down into multiple steps.

[0139] Corresponding to the microservice liveness detection and registration method described above, some embodiments of this specification also provide a microservice liveness detection and registration apparatus, see reference. Figure 6 As shown, in some embodiments, the apparatus may include:

[0140] Receiver module 601 is used to receive the liveness detection request of the target microservice;

[0141] Calling module 602 is used to call the storage status of the target microservice according to the liveness detection request;

[0142] The liveness detection module 603 is used to detect the liveness of the target microservice through the liveness detection request in order to obtain the liveness detection status of the target microservice;

[0143] Determining module 604 is used to determine the target microservice status using the detection status and the registration status;

[0144] The registration module 605 is used to register the current target microservice in the microservice registry if the target microservice is in a state of being switched from a crashed to a live state.

[0145] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware components.

[0146] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in the embodiments of this specification are all information and data authorized and agreed upon by the user and fully authorized by all parties.

[0147] Embodiments of this specification also provide a computer device. For example... Figure 7 As shown, in some embodiments of this specification, the computer device 702 may include one or more processors 704, such as one or more central processing units (CPUs) or graphics processing units (GPUs), each processing unit implementing one or more hardware threads. The computer device 702 may also include any memory 706 for storing information of any kind, such as code, settings, data, etc. In one specific embodiment, a computer program is stored on the memory 706 and can run on the processor 704. When the computer program is run by the processor 704, it can execute instructions described in any of the above embodiments. Non-limitingly, for example, the memory 706 may include any type of RAM, any type of ROM, flash memory, hard disk, optical disk, etc. More generally, any memory can use any technology to store information. Further, any memory can provide volatile or non-volatile retention of information. Further, any memory can represent a fixed or removable component of the computer device 702. In one case, when the processor 704 executes associated instructions stored in any memory or combination of memories, the computer device 702 can perform any operation of the associated instructions. The computer device 702 also includes one or more drive mechanisms 708 for interacting with any memory, such as a hard disk drive mechanism, an optical disk drive mechanism, etc.

[0148] Computer device 702 may also include an input / output interface 710 (I / O) for receiving various inputs (via input device 712) and providing various outputs (via output device 714). A specific output mechanism may include a presentation device 716 and an associated graphical user interface 718 (GUI). In other embodiments, the input / output interface 710 (I / O), input device 712, and output device 714 may be omitted, and the device may function solely as a computer device within a network. Computer device 702 may also include one or more network interfaces 720 for exchanging data with other devices via one or more communication links 722. One or more communication buses 724 couple the components described above together.

[0149] Communication link 722 can be implemented in any way, such as via a local area network, a wide area network (e.g., the Internet), a point-to-point connection, or any combination thereof. Communication link 722 may include any combination of hardwired links, wireless links, routers, gateway functions, name servers, etc., governed by any protocol or combination of protocols.

[0150] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), computer-readable storage media, and computer program products according to some embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processor to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processor, create a mechanism for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0151] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processor to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0152] These computer program instructions may also be loaded onto a computer or other programmable data processor, causing a series of operational steps to be performed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0153] In a typical configuration, a computer device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0154] Computer-readable media, including both permanent and non-permanent, removable and non-removable media, can store information using any method or technology. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by computer equipment. As defined in this specification, computer-readable media does not include transient media, such as modulated data signals and carrier waves.

[0155] Those skilled in the art will understand that the embodiments of this specification can be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, the embodiments of this specification can take the form of computer program products implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0156] The embodiments described in this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. The embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processors connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

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

[0158] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0159] In the description of this specification, the references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of the embodiments of this specification. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of different embodiments or examples.

[0160] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A microservice activation registration method, characterized in that, The method includes: Receive the liveness probe request for the target microservice; The registration status of the target microservice is invoked based on the activation request; The target microservice is probed using the probe request to obtain its probe status. The probe includes detecting the liveness of the microservice process and whether the microservice process can provide services normally. Specifically, the probe involves sending probe information to the target microservice cyclically at a first time interval using the probe request. If the target microservice responds to all probe information within the first time period, the probe status is live; otherwise, the probe status is down. The target microservice state is determined using the probe liveness status and the registered state; wherein, both the registered state and the target microservice state include a crash state, a live state, a crash-to-live state, and a live-to-crash state; if the probe liveness status is live and the registered state is not crashed, then the target microservice state is live; if the probe liveness status is live and the registered state is crashed, then the target microservice state is a crash-to-live state; if the probe liveness status is crashed and the registered state is not live, then the target microservice state is crashed; if the probe liveness status is crashed and the registered state is live, then the probe liveness retry is performed on the target microservice. The liveness retry includes: recording the number of probe messages sent and the number of responses to the target microservice within a first time period; calculating the downtime rate of the target microservice based on the number of sends and the number of responses; if the downtime rate is less than a first threshold, sending probe messages to the current target microservice cyclically at a second time interval; determining whether the current target microservice responds to all probe messages within the second time period; if the current target microservice responds to all probe messages within the second time period, the liveness status is live, and the current target microservice status is live; if the current target microservice does not respond to all probe messages within the second time period, the liveness status is downtime, and the current target microservice status is transitioning from live to downtime. If the target microservice is in a state of being switched from downtime to live, then the current target microservice is registered in the microservice registry. If the target microservice is in a state of transition from live to down, then the current target microservice is deregistered in the microservice registry. The process of deregistering the current target microservice in the microservice registry includes: receiving a deregistration request; obtaining the deregistration time point corresponding to the deregistration request; determining a deregistration time interval after a third time interval from the deregistration time point; and deregistering the current target microservice in the microservice registry within the deregistration time interval.

2. The method according to claim 1, characterized in that, If the downtime rate is not less than the first threshold, the liveness detection state is still a downtime state, and the current target microservice state is a live-to-downtime state.

3. The method according to claim 1, characterized in that, If the target microservice is in a state of transition from downtime to liveness, then register the current target microservice in the microservice registry, including: Receive registration request; The microservice information of the target microservice is written to the microservice registry center according to the registration request.

4. The method according to claim 1, characterized in that, When probing a target microservice using the aforementioned probing request, communication is conducted using either the TCP or HTTP protocol.

5. A microservice activation registration device, characterized in that, The device includes: The receiving module is used to receive liveness detection requests from the target microservice; The calling module is used to call the storage status of the target microservice based on the liveness detection request; The liveness detection module is used to perform liveness detection on the target microservice through the liveness detection request to obtain the liveness status of the target microservice. The liveness detection includes detecting the liveness status of the microservice process and detecting whether the microservice process can provide services normally. Specifically, it is used to send detection information to the target microservice cyclically at a first time interval through the liveness detection request. If the target microservice responds to all the detection information within the first time period, the liveness status is a live state; if it does not respond to all of them, the liveness status is a down state. A determination module is used to determine the state of a target microservice using the probe liveness status and the registered state; wherein, both the registered state and the target microservice state include a crash state, a live state, a crash-to-live state, and a live-to-crash state; if the probe liveness status is a live state and the registered state is not a crash state, then the target microservice state is a live state; if the probe liveness status is a live state and the registered state is a crash state, then the target microservice state is a crash-to-live state; if the probe liveness status is a crash state and the registered state is not a live state, then the target microservice state is a crash state; if the probe liveness status is a crash state and the registered state is a live state, then the probe liveness retry is performed on the target microservice; The liveness retry includes: recording the number of probe messages sent and the number of responses to the target microservice within a first time period; calculating the downtime rate of the target microservice based on the number of sends and the number of responses; if the downtime rate is less than a first threshold, sending probe messages to the current target microservice cyclically at a second time interval; determining whether the current target microservice responds to all probe messages within the second time period; if the current target microservice responds to all probe messages within the second time period, the liveness status is live, and the current target microservice status is live; if the current target microservice does not respond to all probe messages within the second time period, the liveness status is downtime, and the current target microservice status is transitioning from live to downtime. The registration module is used to register the target microservice in the microservice registry if the target microservice is in a state of being switched from being down to being alive. The registration module is also used to deregister the current target microservice in the microservice registry if the target microservice is in a state of transition from live to down. Specifically, the registration module is used to: receive a deregistration request; obtain the deregistration time point corresponding to the deregistration request; determine the deregistration time interval after a third time interval from the deregistration time point; and deregister the current target microservice in the microservice registry within the deregistration time interval.

6. A computer device comprising a memory, a processor, and a computer program stored in the memory, characterized in that, When the computer program is run by the processor, it executes the instructions of the method according to any one of claims 1-4.

7. A computer storage medium having a computer program stored thereon, characterized in that, When the computer program is run by the processor of the computer device, it executes the instructions of the method according to any one of claims 1-4.

8. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, performs instructions according to any one of claims 1-4.

Images