CN114185717A - Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product - Google Patents

Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product Download PDF

Info

Publication number
CN114185717A
CN114185717A CN202111539032.5A CN202111539032A CN114185717A CN 114185717 A CN114185717 A CN 114185717A CN 202111539032 A CN202111539032 A CN 202111539032A CN 114185717 A CN114185717 A CN 114185717A
Authority
CN
China
Prior art keywords
information
micro
registration
node
state
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202111539032.5A
Other languages
Chinese (zh)
Inventor
刘亚
黄坤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
China Construction Bank Corp
Original Assignee
China Construction Bank Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by China Construction Bank Corp filed Critical China Construction Bank Corp
Priority to CN202111539032.5A priority Critical patent/CN114185717A/en
Publication of CN114185717A publication Critical patent/CN114185717A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1415—Saving, restoring, recovering or retrying at system level
    • G06F11/1438—Restarting or rejuvenating
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/366—Software debugging using diagnostics

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • Debugging And Monitoring (AREA)

Abstract

The present disclosure provides a method, apparatus, device, medium, and program product for handling micro-service exceptions for a registry, the method comprising: monitoring the states of M micro services, wherein the M micro services are registered to the registry by N nodes; and under the condition that the first micro service is in an abnormal state, notifying the first node of the running information of the first micro service, wherein the running information comprises the information of the abnormal state. The first node is configured to: obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node; and calling a corresponding exception handling script to process the first micro service based on the information of the exception state. The disclosure also provides a micro-service exception handling method, device, equipment, medium and program product applied to the first node.

Description

Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product
Technical Field
The present disclosure relates to the field of micro services, and more particularly, to a method, an apparatus, a device, a medium, and a program product for handling micro service exception.
Background
The micro-service architecture refers to the splitting of a complex large application into a group of small micro-services, and the micro-services coordinate and cooperate with communication. Each microservice is built around a specific business and can be deployed independently to production environments, production-like environments, and the like.
Often during microservice operation, an abnormal condition may occur. When a micro service is abnormal, the application to which the micro service belongs cannot normally provide the corresponding service. Then the abnormal condition of the micro service needs to be handled manually to make the application to which the micro service belongs recover the service.
In implementing the disclosed concept, the inventors found that there are at least the following problems in the related art: it is necessary to schedule the relevant personnel on duty to prevent possible abnormal situations. In addition, the time for manually finding the exception is delayed, and exception handling cannot be performed in time. Therefore, the method for manually handling the micro-service exception wastes labor cost and has the problem of low exception handling efficiency.
Disclosure of Invention
In view of the above, the present disclosure provides a micro-service exception handling method, apparatus, device, medium, and program product for automatically handling exceptions and improving processing efficiency.
One aspect of the embodiments of the present disclosure provides a method for handling a micro-service exception, which is applied to a registration center, and includes: monitoring the states of M micro services, wherein the M micro services are registered to the registration center by N nodes, and N and M are integers which are greater than or equal to 1 respectively; when a first micro service is in an abnormal state, notifying a first node of running information of the first micro service, wherein the running information comprises the information of the abnormal state, the first node is any one of the N nodes, and the first micro service is any one of the M micro services; wherein the first node is configured to: obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node; and calling a corresponding exception handling script to process the first micro service based on the information of the exception state.
According to an embodiment of the present disclosure, notifying the first node of the running information of the first microservice when the first microservice is in an abnormal state includes: sending the running information to message middleware to enable the first node to obtain the information of the abnormal state based on a first abnormal message acquired from the message middleware, wherein the first abnormal message corresponds to the running information.
According to an embodiment of the present disclosure, the abnormal state includes a mis-registration state, and the monitoring the states of the M micro services includes monitoring the state of the first micro service, which specifically includes: obtaining registration information of the first microservice; and under the condition that the registration information meets the registration alarm condition, determining that the first micro service is in the mis-registration state.
According to an embodiment of the present disclosure, the registration information includes at least one of node information for registering the first micro service, identification information of the first micro service, and registration times, and the registration information meeting a registration alarm condition includes: an alarm field exists in the node server information; or determining that the identification information does not have a corresponding relationship with the node server information based on a preset alarm table, wherein the preset alarm table comprises a corresponding relationship between any node server in the N nodes and at least one micro service; or determining that the registration times of the first micro service exceed the limit times based on the preset alarm table, wherein the preset alarm table comprises the limit times of the first micro service.
According to an embodiment of the present disclosure, when the first microservice is in a misregistration state, the sending the running information of the first microservice to the message middleware includes: and sending the information of the mis-registration state to the message middleware so that the first node calls a corresponding mis-registration processing script to process based on the information of the mis-registration state, wherein the information of the mis-registration state comprises registration alarm condition information which is met by the registration information.
According to an embodiment of the present disclosure, the abnormal state includes an offline state, and when the first micro service is in the offline state, the sending the running information of the first micro service to the message middleware includes: and sending the information of the offline state to the message middleware so that the first node calls an offline processing script based on the information of the offline state to restart the first micro service.
Another method of the embodiments of the present disclosure provides a method for handling exception of a micro service, which is applied to a first node, where the first node is any one of N nodes, and the N nodes are used to register M micro services to a registry server, and the method includes: obtaining, from the registry, operating information of a first microservice, wherein the first microservice is any one of the M microservices, the registry configured to: monitoring the states of the M micro services, and notifying the running information to the first node when the first micro service is in an abnormal state, wherein the running information comprises the information of the abnormal state; obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node; and calling a corresponding exception handling script to process the first micro service based on the information of the exception state.
According to an embodiment of the present disclosure, the obtaining the operation information of the first microservice from the registry includes: acquiring a first exception message from message middleware, wherein the first exception message corresponds to the running information; the registry is configured to: and sending the running information to the message middleware under the condition that the first micro service is in an abnormal state.
According to an embodiment of the present disclosure, the exception state includes a mis-registration state, and the invoking a corresponding exception handling script to process the first micro service based on the information of the exception state includes: determining the type of the mis-registration state based on the information of the mis-registration state, wherein the type of the mis-registration state comprises at least one of node type mis-registration and micro service type mis-registration; and calling a corresponding mis-registration processing script for processing based on the type of the mis-registration state.
According to an embodiment of the present disclosure, the calling a corresponding mis-registration processing script for processing based on the type of the mis-registration state includes: calling a corresponding node mis-registration processing script under the condition that the type of the mis-registration state is node mis-registration so as to log off the first node from the registration center; or calling the corresponding micro-service mis-registration processing script to close the first micro-service under the condition that the type of the mis-registration state is micro-service mis-registration.
According to an embodiment of the present disclosure, the exception status includes an offline status, and invoking a corresponding exception handling script to process the first microservice based on information of the exception status includes: and calling an offline processing script to restart the first micro service based on the information of the offline state.
Another aspect of the disclosed embodiments provides a micro-service exception handling apparatus applied to a registry, including: the state monitoring module is used for monitoring the states of M micro services, wherein the M micro services are registered to the registration center by N nodes, and N and M are integers which are greater than or equal to 1 respectively; an information notification module, configured to notify a first node of running information of a first micro service when the first micro service is in an abnormal state, where the running information includes information of the abnormal state, the first node is any one of the N nodes, and the first micro service is any one of the M micro services; wherein the first node is configured to: obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node; and calling a corresponding exception handling script to process the first micro service based on the information of the exception state.
Another aspect of the disclosed embodiments provides a micro-service exception handling apparatus applied to a first node, where the first node is any one of N nodes, and the N nodes are used to register M micro-services to a registry server, and the apparatus includes: a first obtaining module, configured to obtain, from the registry, operation information of a first microservice, where the first microservice is any one of the M microservices, and the registry is configured to: monitoring the states of the M micro services, and notifying the running information to the first node when the first micro service is in an abnormal state, wherein the running information comprises the information of the abnormal state; a second obtaining module, configured to obtain information of the abnormal state if it is determined that the first microservice is registered by the first node; and the exception handling module is used for calling a corresponding exception handling script to handle the first micro service based on the information of the exception state.
Another aspect of the disclosed embodiments provides an electronic device, including: one or more processors; memory for storing one or more programs, wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method as described above.
Yet another aspect of the embodiments of the present disclosure provides a computer-readable storage medium having stored thereon executable instructions, which when executed by a processor, cause the processor to perform the method as described above.
Yet another aspect of the disclosed embodiments provides a computer program product comprising a computer program that when executed by a processor implements the method as described above.
One or more of the above embodiments have the following advantageous effects: the registration center monitors the states of the M micro-services, can determine the first micro-service in an abnormal state in time, and accordingly informs the first node of the running information of the first micro-service, so that the first node determines whether the first micro-service runs locally, and if so, calls a corresponding abnormal processing script in time to process. Therefore, intelligent abnormity diagnosis and abnormity recovery are carried out on the premise of no need of manual intervention, the project is enabled to run stably, high availability of products is improved, user experience is enhanced, manpower cost waste is avoided, and micro-service abnormity processing efficiency is improved.
Drawings
The foregoing and other objects, features and advantages of the disclosure will be apparent from the following description of embodiments of the disclosure, which proceeds with reference to the accompanying drawings, in which:
fig. 1 schematically illustrates an application scenario diagram of a micro-service exception handling method according to an embodiment of the present disclosure;
FIG. 2 schematically illustrates a flow chart of a micro-service exception handling method applied to a registry according to an embodiment of the present disclosure;
FIG. 3 schematically illustrates a flow diagram of listening for a state of a first microservice according to an embodiment of the disclosure;
FIG. 4 schematically illustrates a flow chart of a microservice exception handling method applied to a first node, in accordance with an embodiment of the present disclosure;
FIG. 5 schematically illustrates a flow diagram for processing the first microservice according to an embodiment of the disclosure;
FIG. 6 schematically illustrates a flow chart of a microservice exception handling method according to an embodiment of the present disclosure;
fig. 7 is a block diagram schematically illustrating a structure of a micro-service exception handling apparatus applied to a registry according to an embodiment of the present disclosure;
fig. 8 is a block diagram schematically illustrating a structure of a micro-service exception handling apparatus applied to a first node according to an embodiment of the present disclosure;
fig. 9 schematically illustrates a block diagram of an electronic device adapted to implement a microservice exception handling method in accordance with an embodiment of the present disclosure.
Detailed Description
Hereinafter, embodiments of the present disclosure will be described with reference to the accompanying drawings. It should be understood that the description is illustrative only and is not intended to limit the scope of the present disclosure. In the following detailed description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the embodiments of the disclosure. It may be evident, however, that one or more embodiments may be practiced without these specific details. Moreover, in the following description, descriptions of well-known structures and techniques are omitted so as to not unnecessarily obscure the concepts of the present disclosure.
The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The terms "comprises," "comprising," and the like, as used herein, specify the presence of stated features, steps, operations, and/or components, but do not preclude the presence or addition of one or more other features, steps, operations, or components.
All terms (including technical and scientific terms) used herein have the same meaning as commonly understood by one of ordinary skill in the art unless otherwise defined. It is noted that the terms used herein should be interpreted as having a meaning that is consistent with the context of this specification and should not be interpreted in an idealized or overly formal sense.
Where a convention analogous to "at least one of A, B and C, etc." is used, in general such a construction is intended in the sense one having skill in the art would understand the convention (e.g., "a system having at least one of A, B and C" would include but not be limited to systems that have a alone, B alone, C alone, a and B together, a and C together, B and C together, and/or A, B, C together, etc.).
Fig. 1 schematically shows an application scenario diagram of a micro-service exception handling method according to an embodiment of the present disclosure.
As shown in fig. 1, the application scenario 100 according to this embodiment may include N node servers 111, 112, 113 … … 11N, a registry server 120, a message server 130, terminal devices 151, 152, 153, and a network 140. Network 140 serves as a medium for providing communication links between terminal devices 151, 152, 153 and any of the N node servers. Network 140 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few. It should be noted that the network 140 may also be disposed between the N node servers, the registry server 120 and the message server 130, and the disclosure is not limited thereto.
A user may interact with any of the N node servers over network 140 using end devices 151, 152, 153 to receive or send messages, etc. The terminal devices 151, 152, 153 may have installed thereon various messenger client applications such as, for example only, a shopping-like application, a web browser application, a search-like application, an instant messaging tool, a mailbox client, social platform software, and the like. It should be noted that the user may use the terminal devices 151, 152, 153 to interact with the registry server 120 and the message server 130, and the disclosure is not limited in particular.
The terminal devices 151, 152, 153 may be various electronic devices having a display screen and supporting web browsing, including but not limited to smart phones, tablet computers, laptop portable computers, desktop computers, and the like.
The N node servers, the registry server 120 and the message server 130 may be the same or different servers, and when the N node servers, the registry server 120 and the message server 130 are the same servers, they may be servers providing various services, such as a background management server (for example only) providing support for websites browsed by users using the terminal devices 151, 152 and 153. The background management server may analyze and perform other processing on the received data such as the user request, and feed back a processing result (e.g., a webpage, information, or data obtained or generated according to the user request) to the terminal device.
According to an embodiment of the present disclosure, each of the N node servers may be a node. The same microservice of the same application can be deployed in each node server, so that the redundancy of the application is improved. Different micro-services with different applications can be deployed, and all node servers can call the required micro-services mutually. The registry server 120 may be deployed with a registry in the micro-service framework, and the N node servers are N node servers registered in the registry, respectively, and each node server may have a client corresponding to the registry installed therein. Message middleware is deployed in the message server 130 to provide message queue functionality. In other embodiments, the message middleware may be deployed in the registry server 120, and the message server 130 is eliminated. The micro-service framework may be, for example, a Spring Cloud framework, and the registry thereof may be Eureka or Dubbo framework, and the registry may be Zookeeper. It should be understood that the micro service framework may also be other frameworks that can implement monitoring of the micro service state, and the disclosure is not limited thereto. Message server 130 may implement the functionality of message middleware using Redis or Kafka, etc.
It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation.
The microservice exception handling method according to the embodiment of the present disclosure will be described in detail below with reference to fig. 2 to 6 based on the scenario described in fig. 1.
Fig. 2 schematically shows a flowchart of a micro-service exception handling method applied to a registry according to an embodiment of the present disclosure.
As shown in fig. 2, the micro-service exception handling method of this embodiment is applied to the registry, and may include operations S210 to S220.
In operation S210, states of M micro services are monitored, where the M micro services are registered to a registry by N nodes, and N and M are integers greater than or equal to 1, respectively.
Taking the example of Eureka, it may include a Eureka-server component and a Eureka-client component. Each node in the N nodes may register the running microservices with a Eureka-server (installed at the registry server) through a locally installed Eureka-client (installed at the node server). And the micro-service state monitoring function can be realized through related events in the Eureka-server, such as registration (eurekanegisterevent), offline (eurekanencecantevent), and appointment (eurekanenewedevent) events.
In operation S220, in a case that the first micro service is in an abnormal state, the first node is notified of running information of the first micro service, where the running information includes information of the abnormal state, the first node is any one of the N nodes, and the first micro service is any one of the M micro services.
Wherein the first node is configured to: in a case where it is determined that the first microservice is registered by the first node, information of an abnormal state is obtained. And calling the corresponding exception handling script to process the first micro service based on the information of the exception state.
The running information of the first micro service may include an application name (App name) to which the first micro service belongs, an IP address of a node server that registers the first micro service, identification information (such as a name or a thread ID) of the first micro service, information of an abnormal state, and the like, where the information of the abnormal state may include specific information of the abnormal state or abnormal performance, and the like.
In some embodiments, notifying the first node of the running information of the first microservice in operation S220 may include notifying based on a watcher mode. The first node may subscribe to listen for the status of its registered microservices. The first node may be notified when the state changes.
In some embodiments, notifying the first node of the execution information of the first microservice in operation S220 may include event mode based notification. The first node may subscribe to snoop related events (e.g., offline events). For example, some events are generated due to the state change of the micro service registered by the micro service, and the first node is informed of the events.
In some embodiments, notifying the first node of the running information of the first microservice in operation S220 includes: and sending the running information to the message middleware to enable the first node to obtain the information of the abnormal state based on a first abnormal message acquired from the message middleware, wherein the first abnormal message corresponds to the running information. After receiving the running information, the message middleware can correspondingly generate a first abnormal message and place the first abnormal message into a message queue.
An alternative way to obtain exception messages from the message middleware is to push each exception message to the corresponding node server based on a message queue in the message middleware. And pushing the abnormal message to the corresponding node server according to the IP address of the node server of the first micro service. The node server then determines an application name from the exception message, along with identification information, for locating to the first microservice. And finally, calling the corresponding script to process based on the information of the abnormal state.
Another optional way to obtain the exception message from the message middleware is that each node in the N nodes takes the exception message from the message queue, where the taking may be a timing taking, or a taking may be performed when a new message is monitored in the message queue. For example, after obtaining the first abnormal message, the first node determines whether the IP address is a self address, if so, locates the first microservice based on the application name and the identification information, and calls a corresponding script to process based on the information of the abnormal state. And finally deleting the first abnormal message from the message queue. If not, the first abnormal message is continuously kept in the message queue to wait for consumption of other node servers.
According to the embodiment of the disclosure, the message middleware is used as the connection between the registration center and the nodes, and abnormal messages are notified in time. The message queue mode can play the roles of asynchronous processing and traffic cutting, and the N nodes can consume each message in the message queue mode of pulling the message from the message queue, so that the condition of processing local exception loss can be avoided.
According to the embodiment of the disclosure, the state of the M micro-services is monitored by the registration center server, the first micro-service in an abnormal state can be determined in time, so that the running information of the first micro-service is notified to the first node, the first node determines whether the first micro-service runs in the local, and if so, the corresponding abnormal processing script is called in time for processing. Therefore, intelligent abnormity diagnosis and abnormity recovery are carried out on the premise of no need of manual intervention, the project is enabled to run stably, high availability of products is improved, user experience is enhanced, manpower cost waste is avoided, and micro-service abnormity processing efficiency is improved.
FIG. 3 schematically illustrates a flow diagram of listening for a state of a first microservice according to an embodiment of the disclosure.
As shown in fig. 3, listening to the states of the M micro services in operation S210 includes listening to the state of the first micro service, which may include operations S310 to S320. Wherein the abnormal state comprises a mis-registration state.
In operation S310, registration information of a first microservice is obtained.
For example, when the first micro service is registered to the Eureka-server, a registration (Eureka instanceregister event) event of the first micro service may be listened to, and registration information of the first micro service may be obtained from the registration event.
In operation S320, in case that the registration information meets the registration alarm condition, it is determined that the first microservice is in a mis-registration state.
According to the embodiment of the disclosure, the node or the micro-service which is wrongly registered can be timely processed by monitoring the wrongly registered state, and adverse effects on a test or production environment are avoided.
According to the embodiment of the present disclosure, the registration information includes at least one of node information (such as a server IP address) of registering the first micro service, identification information of the first micro service, and the number of registrations.
In an alternative embodiment, the step of meeting the registration alarm condition in operation S320 includes that an alarm field exists in the node server information. For example, the node server information includes an IP address, and if a Localhost field appears in the IP address, it indicates that this node is a node that is misregistered by a local developer, but not a node that normally comes online (for example only). Therefore, one or more alarm fields can be set as the registration alarm condition A for different situations, and whether the registration information meets the registration alarm condition or not can be detected in time.
Another optional implementation manner is that the step of determining that the registration information meets the registration alarm condition in operation S320 includes determining that the identification information does not have a correspondence with the node server information based on a preset alarm table, where the preset alarm table includes a correspondence between any node server in the N nodes and at least one microservice. For example, writing an IP address and identification information in a preset alarm table, and corresponding the IP address of each node server to the identification information of at least one micro service, so as to indicate the micro service allowed to operate by each IP address. The registration alarm condition B may be that if the identification information or the IP address is not in the preset alarm table, it is determined that the identification information or the IP address does not have a correspondence relationship. The registration alarm condition B may be that although the identification information and the IP address are both in the preset alarm table, the identification information and the IP address do not correspond to each other, and obviously do not have a corresponding relationship.
In yet another alternative embodiment, the matching of the registration information with the registration alarm condition in operation S320 includes determining that the registration number of the first micro service exceeds the limit number based on a preset alarm table, wherein the preset alarm table includes the limit number of the first micro service. The limit number is, for example, the maximum number of registrations per unit time. The registration alarm condition C may be that the number of registrations of the first microservice per unit time exceeds a maximum number of registrations. If the registration alarm condition C is met, it indicates that the first micro service is frequently registered, and may not operate normally, and the registration is determined as a false registration.
According to an embodiment of the present disclosure, in a case that the first microservice is in a mis-registration state, sending the running information of the first microservice to the message middleware includes: and sending the information of the mis-registration state to a message middleware so that the first node calls a corresponding mis-registration processing script to process based on the information of the mis-registration state, wherein the information of the mis-registration state comprises registration alarm condition information which is met by the registration information. Any of the registration alarm conditions A, B or C described above may be included in the information of the misregistration status.
According to the embodiment of the disclosure, the abnormal state includes an offline state, and the sending of the running information of the first micro service to the message middleware includes: and sending the information of the offline state to message middleware so that the first node calls an offline processing script based on the information of the offline state to restart the first micro service.
For example, when a first micro service is invoked in the process of providing a service by an application and is considered to be down, the registry may be notified, the state of the first micro service is set to be down, and a running message is sent. For another example, after the first micro service is registered with the Eureka-server, the heartbeat message may be periodically transmitted through the Eureka-client. And if the Eureka-server does not receive the heartbeat message within a certain time, setting the state of the first micro service to be a down state, and generating a down event. Therefore, the running message can be acquired from the offline event and sent.
Fig. 4 schematically shows a flowchart of a microservice exception handling method applied to a first node according to an embodiment of the present disclosure.
As shown in fig. 4, the micro-service exception handling method of this embodiment includes operations S410 to S430. The first node is any one of N nodes, and the N nodes register M micro-services to a registration center server.
In operation S410, operation information of a first microservice is obtained from a registry, wherein the first microservice is any one of M microservices, and the registry is configured to: monitoring the states of the M micro services, and notifying the running information to the first node under the condition that the first micro service is in an abnormal state, wherein the running information comprises the information of the abnormal state.
In operation S420, in case that it is determined that the first micro service is registered by the first node, information of an abnormal state is obtained.
In operation S430, based on the information of the exception state, a corresponding exception handling script is called to handle the first microservice.
Compared with a mode of manually processing the micro-service exception through manual work, the first node can respond to the first exception information, and if the first micro-service is determined to be registered locally, the exception handling script is called to automatically handle the exception, so that the automatic handling of the micro-service exception is realized, the exception handling efficiency is improved, and the labor cost is saved.
According to an embodiment of the present disclosure, the obtaining the operation information of the first microservice from the registry in operation S410 includes: and acquiring a first exception message from the message middleware, wherein the first exception message corresponds to the running information. Wherein the registry is configured to: and sending the running information to the message middleware under the condition that the first micro service is in an abnormal state.
FIG. 5 schematically shows a flow diagram for processing a first microservice according to an embodiment of the disclosure.
As shown in fig. 5, invoking the corresponding exception handling script to process the first micro-service based on the information of the exception state in operation S430 may include operations S510 to S520. Wherein the abnormal state comprises a mis-registration state.
In operation S510, a type of a mis-registration state is determined based on information of the mis-registration state, wherein the type of the mis-registration state includes at least one of a node type mis-registration and a micro service type mis-registration.
The node type misregistration may be a node locally misregistered by the developer, for example, the registry server is registered in the Eureka-server as a node server, which may affect the micro service management and even cause a call error.
The node-like misregistration may also be that a node server that is not within the range of the registry server, such as a server other than the N nodes, is registered in. The micro-service management may also be affected, adding to the burden of the registry server, resulting in a wrong call.
The microservice class misregistration may be that N nodes will not register for scheduled microservices. For example, the kind of applications that the N nodes run, and the microservices in each application are the planned content. The preset alarm table may include identification information of micro services in the plan, and if redundant micro services are not in the plan, the possibility of abnormal occurrence may be increased.
The microservice-like misregistration may also be a microservice for which each node server is not registered within the plan. For example, the preset alarm table may include a correspondence between any node server of the N nodes and at least one microservice. If the micro-service registered by the first node does not belong to the corresponding micro-service, the first node registers the micro-service which is not in the plan.
According to the embodiment of the disclosure, corresponding to the specific type of the node class mis-registration or the micro-service class mis-registration, the corresponding exception handling script can be set in a targeted manner, so that the problem can be solved in time.
In operation S520, a corresponding mis-registration processing script is called for processing based on the type of the mis-registration status.
According to the embodiment of the disclosure, the first exception message includes a registration alarm condition that the registration information meets, for example, if the registration alarm condition a is included, it indicates that the node class is mis-registered. If the registration alarm condition B is that the IP address is not in the preset alarm table, the node type is indicated to be wrongly registered. If the identification information of the micro service including the registration alarm condition B is not in the preset alarm table or the identification information and the IP address are not corresponding in the preset alarm table, the micro service class is indicated as error registration. If the registration alarm condition C is included, the micro-service class is indicated to be wrongly registered.
In some embodiments, the invoking the corresponding mis-registration processing script for processing in operation S520 based on the type of the mis-registration status includes: and under the condition that the type of the mis-registration state is the node type mis-registration, calling a corresponding node mis-registration processing script to log off the first node from the registration center.
In other embodiments, when the type of the mis-registration state is micro-service type mis-registration, a corresponding micro-service mis-registration processing script is called to close the first micro-service.
One or more mis-registration processing scripts and a corresponding relationship between each mis-registration processing script and a processing mis-registration state may be set in advance in the first node. For example, after the first node determines the type of the mis-registration status, the corresponding script may be invoked based on the correspondence.
According to an embodiment of the present disclosure, the exception status in operation S430 includes an offline status, and based on the information of the exception status, invoking a corresponding exception handling script to process the first micro service includes: and calling the offline processing script to restart the first micro service based on the information of the offline state.
And after the registration center server detects that the first micro service is in the offline state, the first node is notified through message middleware. Therefore, the first node can automatically restart the first micro service, so that the first micro service can continue to operate normally, and the processing efficiency of micro service abnormity is improved.
Fig. 6 schematically shows a flowchart of a microservice exception handling method according to an embodiment of the present disclosure.
Referring to fig. 1 and 6, the micro-service exception handling method of this embodiment includes operations S601 to S606. Wherein the message middleware is provided by a message server.
In operation S601, each node server of the N node servers registers the running micro service with the registry server.
In operation S602, the registry server listens for the state of the microservice by way of a listening event.
In operation S603, if a micro service is in an abnormal state (e.g., offline state or mis-registration state), the running information of the micro service is stored in the message middleware. The running information of the micro-service may include information of the node server (e.g., IP address), application name, identification information of the micro-service (e.g., micro-service name or thread ID).
In operation S604, each node server may periodically access to the message middleware, and obtain each exception message from the message queue by pulling the message.
In operation S605, the message middleware returns each exception message to each node server.
In operation S606, each node server parses the obtained exception message, and obtains operation information. And if the micro service in the abnormal message is determined to be operated locally, deleting the abnormal message from the message queue, which indicates that the consumption is successful. If the micro service in the abnormal message is determined not to be operated locally, the micro service is not deleted, which indicates that the consumption is failed. The exception message waits for the other node server to consume successfully.
In addition, in operation S606, information of the abnormal state may be obtained, whether the abnormal state is the offline state or the mis-registration state is determined, and if the abnormal state is the offline state, the offline processing script is called to restart the computer. If the registration state is wrong, calling a corresponding script for processing based on node type registration or micro-service type registration. Reference may be made to the embodiments of operations S510 to S520, which are not described herein.
According to the embodiment of the disclosure, taking the realization of the message middleware function by using the Redis server as an example, for micro-services such as downtime abnormality and mis-registration abnormality, the appName corresponding to the abnormal micro-service can be obtained and stored in the Redis. And simultaneously reading the key (such as an IP address or an appName) stored in the redis on the corresponding node, and restarting if the key can be read, indicating that abnormal micro-service exists.
In some embodiments, after processing the abnormal state of the micro service, the node server may further execute a mail notification script and a short message notification script to notify related personnel. For example, the exception handling log may be forwarded to a mail server and a short message server, and the mail server and the short message server generate a mail and a short message for forwarding.
Based on the micro-service exception handling method, the disclosure also provides a micro-service exception handling device applied to the registry and a micro-service exception handling device applied to the first node. The apparatus will be described in detail below with reference to fig. 7 and 8.
Fig. 7 schematically shows a block diagram of a micro-service exception handling apparatus 700 applied to a registry according to an embodiment of the present disclosure.
As shown in fig. 7, the microservice exception handling apparatus 700 applied to the registry of the embodiment includes a status listening module 710 and an information notifying module 720.
The status monitoring module 710 may perform operation S210 for monitoring statuses of M micro services, where the M micro services are registered to the registry by N nodes, and N and M are integers greater than or equal to 1, respectively.
The information notification module 710 may perform operation S220, configured to notify the first node of the running information of the first micro service when the first micro service is in an abnormal state, where the running information includes information of the abnormal state, the first node is any one of N nodes, and the first micro service is any one of M micro services. Wherein the first node is configured to: in a case where it is determined that the first microservice is registered by the first node, information of an abnormal state is obtained. And calling the corresponding exception handling script to process the first micro service based on the information of the exception state.
Fig. 8 schematically shows a block diagram of a micro-service exception handling apparatus 800 applied to a first node according to an embodiment of the present disclosure.
As shown in fig. 8, the micro-service exception handling apparatus 800 applied to the first node of this embodiment includes a first obtaining module 810, a second obtaining module 820, and an exception handling module 830. The first node is any one of N nodes, and the N nodes are used for registering M micro services to a registration center server.
The first obtaining module 810 may perform operation S410, for example, to obtain running information of a first micro-service from a registry, wherein the first micro-service is any one of M micro-services, and the registry is configured to: monitoring the states of the M micro services, and notifying the running information to the first node under the condition that the first micro service is in an abnormal state, wherein the running information comprises the information of the abnormal state.
The second obtaining module 820 may perform operation S420, for example, to obtain information of the abnormal state in case it is determined that the first microservice is registered by the first node.
The exception handling module 830 may, for example, perform operation S430 for invoking a corresponding exception handling script to handle the first microservice based on the information of the exception status.
According to the embodiment of the present disclosure, any plurality of modules in the micro service exception handling apparatus 700 or the micro service exception handling apparatus 800 may be combined into one module to be implemented, or any one of the modules may be split into a plurality of modules. Alternatively, at least part of the functionality of one or more of these modules may be combined with at least part of the functionality of the other modules and implemented in one module.
According to an embodiment of the present disclosure, at least one module in the micro service exception handling device 700 or the micro service exception handling device 800 may be implemented at least partially as a hardware circuit, such as a Field Programmable Gate Array (FPGA), a Programmable Logic Array (PLA), a system on a chip, a system on a substrate, a system on a package, an Application Specific Integrated Circuit (ASIC), or may be implemented in hardware or firmware in any other reasonable manner of integrating or packaging a circuit, or in any one of three implementations of software, hardware, and firmware, or in any suitable combination of any of them. Alternatively, at least one module of the micro service exception handling apparatus 700 or the micro service exception handling apparatus 800 may be at least partially implemented as a computer program module, which when executed may perform a corresponding function.
Fig. 9 schematically illustrates a block diagram of an electronic device adapted to implement a microservice exception handling method in accordance with an embodiment of the present disclosure.
As shown in fig. 9, an electronic apparatus 900 according to an embodiment of the present disclosure includes a processor 901 which can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)902 or a program loaded from a storage portion 908 into a Random Access Memory (RAM) 903. Processor 901 may comprise, for example, a general purpose microprocessor (e.g., a CPU), an instruction set processor and/or associated chipset, and/or a special purpose microprocessor (e.g., an Application Specific Integrated Circuit (ASIC)), among others. The processor 901 may also include on-board memory for caching purposes. The processor 901 may comprise a single processing unit or a plurality of processing units for performing the different actions of the method flows according to embodiments of the present disclosure.
In the RAM 903, various programs and data necessary for the operation of the electronic apparatus 900 are stored. The processor 901, the ROM 902, and the RAM 903 are connected to each other through a bus 904. The processor 901 performs various operations of the method flows according to the embodiments of the present disclosure by executing programs in the ROM 902 and/or the RAM 903. Note that the program may also be stored in one or more memories other than the ROM 902 and the RAM 903. The processor 901 may also perform various operations of the method flows according to embodiments of the present disclosure by executing programs stored in the one or more memories.
Electronic device 900 may also include input/output (I/O) interface 905, input/output (I/O) interface 905 also connected to bus 904, according to an embodiment of the present disclosure. The electronic device 900 may also include one or more of the following components connected to the I/O interface 905: an input section 906 including a keyboard, mouse, and the like. Including an output portion 907 such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker and the like. A storage section 908 including a hard disk and the like. And a communication section 909 including a network interface card such as a LAN card, a modem, or the like. The communication section 909 performs communication processing via a network such as the internet. The drive 910 is also connected to the I/O interface 905 as necessary. A removable medium 911 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 910 as necessary, so that a computer program read out therefrom is mounted into the storage section 908 as necessary.
The present disclosure also provides a computer-readable storage medium, which may be embodied in the devices/apparatuses/systems described in the above embodiments. Or may exist separately and not be assembled into the device/apparatus/system. The computer-readable storage medium carries one or more programs which, when executed, implement the method according to an embodiment of the disclosure.
According to embodiments of the present disclosure, the computer-readable storage medium may be a non-volatile computer-readable storage medium, which may include, for example but is not limited to: a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present disclosure, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. For example, according to embodiments of the present disclosure, a computer-readable storage medium may include the ROM 902 and/or the RAM 903 described above and/or one or more memories other than the ROM 902 and the RAM 903.
Embodiments of the present disclosure also include a computer program product comprising a computer program containing program code for performing the method illustrated in the flow chart. When the computer program product runs in a computer system, the program code is used for causing the computer system to realize the item recommendation method provided by the embodiment of the disclosure.
The computer program performs the above-described functions defined in the system/apparatus of the embodiments of the present disclosure when executed by the processor 901. The systems, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.
In one embodiment, the computer program may be hosted on a tangible storage medium such as an optical storage device, a magnetic storage device, or the like. In another embodiment, the computer program may also be transmitted, distributed in the form of a signal on a network medium, and downloaded and installed through the communication section 909 and/or installed from the removable medium 911. The computer program containing program code may be transmitted using any suitable network medium, including but not limited to: wireless, wired, etc., or any suitable combination of the foregoing.
In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 909, and/or installed from the removable medium 911. The computer program, when executed by the processor 901, performs the above-described functions defined in the system of the embodiment of the present disclosure. The systems, devices, apparatuses, modules, units, etc. described above may be implemented by computer program modules according to embodiments of the present disclosure.
In accordance with embodiments of the present disclosure, program code for executing computer programs provided by embodiments of the present disclosure may be written in any combination of one or more programming languages, and in particular, these computer programs may be implemented using high level procedural and/or object oriented programming languages, and/or assembly/machine languages. The programming language includes, but is not limited to, programming languages such as Java, C + +, python, the "C" language, or the like. The program code may execute entirely on the user computing device, partly on the user device, partly on a remote computing device, or entirely on the remote computing device or server. In the case of a remote computing device, the remote computing device may be connected to the user computing device through any kind of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or may be connected to an external computing device (e.g., through the internet using an internet service provider).
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
Those skilled in the art will appreciate that various combinations and/or combinations of features recited in the various embodiments and/or claims of the present disclosure can be made, even if such combinations or combinations are not expressly recited in the present disclosure. In particular, various combinations and/or combinations of the features recited in the various embodiments and/or claims of the present disclosure may be made without departing from the spirit or teaching of the present disclosure. All such combinations and/or associations are within the scope of the present disclosure.
The embodiments of the present disclosure have been described above. However, these examples are for illustrative purposes only and are not intended to limit the scope of the present disclosure. Although the embodiments are described separately above, this does not mean that the measures in the embodiments cannot be used in advantageous combination. The scope of the disclosure is defined by the appended claims and equivalents thereof. Various alternatives and modifications can be devised by those skilled in the art without departing from the scope of the present disclosure, and such alternatives and modifications are intended to be within the scope of the present disclosure.

Claims (16)

1. A micro-service exception handling method is applied to a registration center and comprises the following steps:
monitoring the states of M micro services, wherein the M micro services are registered to the registration center by N nodes, and N and M are integers which are greater than or equal to 1 respectively;
when a first micro service is in an abnormal state, notifying a first node of operation information of the first micro service, wherein the operation information comprises the information of the abnormal state, the first node is any one of the N nodes, and the first micro service is any one of the M micro services;
wherein the first node is configured to:
obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node;
and calling a corresponding exception handling script to process the first micro service based on the information of the exception state.
2. The method of claim 1, wherein the notifying the first node of the running information of the first microservice if the first microservice is in an abnormal state comprises:
sending the running information to message middleware to enable the first node to obtain the information of the abnormal state based on a first abnormal message acquired from the message middleware, wherein the first abnormal message corresponds to the running information.
3. The method according to claim 2, wherein the abnormal state includes a mis-registration state, and the monitoring the states of the M micro services includes monitoring the state of the first micro service, which specifically includes:
obtaining registration information of the first microservice;
and under the condition that the registration information meets the registration alarm condition, determining that the first micro service is in the mis-registration state.
4. The method of claim 3, wherein the registration information comprises at least one of node information for registering the first micro service, identification information of the first micro service, and registration times, and the registration information meeting a registration alarm condition comprises:
an alarm field exists in the node server information; or
Determining that the identification information does not have a corresponding relationship with the node server information based on a preset alarm table, wherein the preset alarm table comprises a corresponding relationship between any node server in the N nodes and at least one micro service; or
And determining that the registration times of the first micro service exceed the limit times based on the preset alarm table, wherein the preset alarm table comprises the limit times of the first micro service.
5. The method of claim 4, wherein in the case that the first microservice is in a misregistration state, the sending the running information of the first microservice to the message middleware comprises:
and sending the information of the mis-registration state to the message middleware so that the first node calls a corresponding mis-registration processing script to process based on the information of the mis-registration state, wherein the information of the mis-registration state comprises registration alarm condition information which is met by the registration information.
6. The method of claim 2, wherein the abnormal state comprises a down state, and in the case that the first microservice is in the down state, the sending the running information of the first microservice to the message middleware comprises:
and sending the information of the offline state to the message middleware so that the first node calls an offline processing script based on the information of the offline state to restart the first micro service.
7. A micro-service exception handling method is applied to a first node, wherein the first node is any one of N nodes, and the N nodes are used for registering M micro-services to a registry server, and the method comprises the following steps:
obtaining, from the registry, operating information of a first microservice, wherein the first microservice is any one of the M microservices, the registry configured to: monitoring the states of the M micro services, and notifying the running information to the first node when the first micro service is in an abnormal state, wherein the running information comprises the information of the abnormal state;
obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node;
and calling a corresponding exception handling script to process the first micro service based on the information of the exception state.
8. The method of claim 7, wherein the obtaining operational information for the first microservice from the registry comprises:
acquiring a first exception message from message middleware, wherein the first exception message corresponds to the running information;
the registry is configured to: and sending the running information to the message middleware under the condition that the first micro service is in an abnormal state.
9. The method of claim 7, wherein the exception state comprises a misregistration state, and wherein invoking a corresponding exception handling script to process the first microservice based on information of the exception state comprises:
determining the type of the mis-registration state based on the information of the mis-registration state, wherein the type of the mis-registration state comprises at least one of node type mis-registration and micro service type mis-registration;
and calling a corresponding mis-registration processing script for processing based on the type of the mis-registration state.
10. The method of claim 9, wherein invoking a corresponding mis-registration processing script for processing based on the type of the mis-registration status comprises:
calling a corresponding node mis-registration processing script under the condition that the type of the mis-registration state is node mis-registration so as to log off the first node from the registration center; or
And calling a corresponding micro-service mis-registration processing script to close the first micro-service under the condition that the type of the mis-registration state is micro-service mis-registration.
11. The method of claim 7, wherein the exception status comprises a down status, and invoking a corresponding exception handling script to process the first microservice based on information of the exception status comprises:
and calling an offline processing script to restart the first micro service based on the information of the offline state.
12. A micro-service exception handling device applied to a registration center comprises:
the state monitoring module is used for monitoring the states of M micro services, wherein the M micro services are registered to the registration center by N nodes, and N and M are integers which are greater than or equal to 1 respectively;
an information notification module, configured to notify a first node of running information of a first micro service when the first micro service is in an abnormal state, where the running information includes information of the abnormal state, the first node is any one of the N nodes, and the first micro service is any one of the M micro services;
wherein the first node is configured to:
obtaining information of the abnormal state if it is determined that the first microservice is registered by the first node;
and calling a corresponding exception handling script to process the first micro service based on the information of the exception state.
13. A micro-service exception handling device applied to a first node, wherein the first node is any one of N nodes, and the N nodes are used for registering M micro-services to a registry server, and the device comprises:
a first obtaining module, configured to obtain, from the registry, operation information of a first microservice, where the first microservice is any one of the M microservices, and the registry is configured to: monitoring the states of the M micro services, and notifying the running information to the first node when the first micro service is in an abnormal state, wherein the running information comprises the information of the abnormal state;
a second obtaining module, configured to obtain information of the abnormal state if it is determined that the first microservice is registered by the first node;
and the exception handling module is used for calling a corresponding exception handling script to handle the first micro service based on the information of the exception state.
14. An electronic device, comprising:
one or more processors;
a storage device for storing one or more programs,
wherein the one or more programs, when executed by the one or more processors, cause the one or more processors to perform the method of any of claims 1-11.
15. A computer readable storage medium having stored thereon executable instructions which, when executed by a processor, cause the processor to perform the method of any one of claims 1 to 11.
16. A computer program product comprising a computer program which, when executed by a processor, implements a method according to any one of claims 1 to 11.
CN202111539032.5A 2021-12-15 2021-12-15 Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product Pending CN114185717A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202111539032.5A CN114185717A (en) 2021-12-15 2021-12-15 Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202111539032.5A CN114185717A (en) 2021-12-15 2021-12-15 Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product

Publications (1)

Publication Number Publication Date
CN114185717A true CN114185717A (en) 2022-03-15

Family

ID=80605223

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202111539032.5A Pending CN114185717A (en) 2021-12-15 2021-12-15 Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product

Country Status (1)

Country Link
CN (1) CN114185717A (en)

Similar Documents

Publication Publication Date Title
CN107016480B (en) Task scheduling method, device and system
CN111694674B (en) Message distribution processing method, device, equipment and storage medium
US11061669B2 (en) Software development tool integration and monitoring
CN113900834B (en) Data processing method, device, equipment and storage medium based on Internet of things technology
CN107896172B (en) Monitoring fault processing method and device, storage medium and electronic equipment
CN111526049B (en) Operation and maintenance system, operation and maintenance method, electronic device and storage medium
CN111371898B (en) Message monitoring method, device, equipment and storage medium
US9092329B2 (en) Process integration alerting for business process management
CN113377626B (en) Visual unified alarm method, device, equipment and medium based on service tree
CN110896362B (en) Fault detection method and device
CN112860504A (en) Monitoring method and device, computer storage medium and electronic equipment
CN114827280A (en) Request processing method, device, equipment and medium
CN113434323A (en) Task flow control method of data center station and related device
CN111240760B (en) Application publishing method, system, storage medium and equipment based on registry
CN115951923B (en) Subscription event management method, display system, device and storage medium
CN114968636A (en) Fault processing method and device
CN114185717A (en) Microservice exception handling method, microservice exception handling apparatus, microservice exception handling device, microservice exception handling medium, and program product
CN112953769B (en) Data transmission method, device, computer system and readable storage medium
CN110875832A (en) Abnormal service monitoring method, device and system and computer readable storage medium
CN111290873B (en) Fault processing method and device
CN112783730B (en) Interface monitoring method, device, medium and electronic equipment
CN114257632A (en) Disconnection reconnection method and device, electronic equipment and readable storage medium
US20100269052A1 (en) Notifying of an unscheduled system interruption requiring manual intervention and adjusting interruption specifics reactive to user feedback
CN113656239A (en) Monitoring method and device for middleware and computer program product
CN112445597A (en) Timing task scheduling method and device

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination