Micro-service health state maintenance method and device, storage medium and computer program product

Abstract

The invention discloses a micro-service health state maintenance method and device, a storage medium and a computer program product, and relates to the technical field of micro-service architectures, and the method comprises the steps: obtaining micro-service detection data based on a distributed streaming platform; integrating the micro-service detection data and preset off-hook decision standardization parameters into an off-hook unit data structure; performing sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision; and performing automatic off-hook isolation operation on a pre-constructed off-hook unit according to the off-hook decision. And automatic off-hook isolation operation is realized according to the off-hook decision, so that the uncertainty of manual operation is avoided, and automatic and efficient maintenance of the micro-service health state is realized.

Description

Technical Field

[0001] The present application relates to the field of microservice architecture technology, and in particular to a microservice health status maintenance method, device, storage medium, and computer program product. Background Art

[0002] The banking application APP is a large-scale open service application software composed of multiple microservices for the mobile Internet. The maintenance of the health status of the application microservices mainly relies on F5 load balancing technology to ensure that the microservice units receiving traffic are all available. However, the heartbeat detection function of F5 load balancing technology cannot detect the health status of all microservices of the application and automatically off-hook the microservices in abnormal status. At the same time, the maintenance of the health status of microservices is affected by uncontrollable factors such as external dependency conditions such as computer room hardware and electricity and server operation status, resulting in an inability to respond to abnormal microservices in a timely manner, resulting in a high risk during the maintenance process.

[0003] Therefore, how to automatically and efficiently maintain the health status of microservices in a timely manner has become an urgent problem to be solved in this application.

[0004] The above contents are only used to assist in understanding the technical solution of the present application and do not constitute an admission that the above contents are prior art. Summary of the invention

[0005] The main purpose of this application is to provide a microservice health status maintenance method, device, storage medium and computer program product, aiming to solve the technical problem of how to automatically and efficiently maintain the health status of microservices in a timely manner.

[0006] To achieve the above objectives, the present application proposes a method for maintaining the health status of microservices, the method comprising:

[0007] Obtain microservice detection data based on the distributed streaming platform;

[0008] Integrate the microservice detection data and preset off-hook decision standardized parameters into an off-hook unit data structure;

[0009] Performing a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision;

[0010] An automatic off-hook isolation operation is performed on a pre-built off-hook unit according to the off-hook decision.

[0011] In one embodiment, before the step of integrating the microservice detection data and the preset off-hook decision standardized parameters into an off-hook unit data structure, the step further includes:

[0012] Build an off-hook unit based on the server group deployment method of microservices;

[0013] Synchronize microservice configuration data and server configuration data regularly according to the preset synchronization time;

[0014] The off-hook decision standardized parameters of the off-hook unit are designed according to the server configuration data and the microservice configuration data.

[0015] In one embodiment, the step of integrating the microservice detection data and the preset off-hook decision standardized parameters into an off-hook unit data structure includes:

[0016] Parsing the status code of the microservice detection data;

[0017] Filter the microservice detection data based on the status code to obtain filtered microservice detection data;

[0018] Obtain decision condition parameters according to the cluster to which the off-hook unit to which the filtered microservice detection data belongs;

[0019] Creating an off-hook unit control object according to the decision condition parameters;

[0020] Recording the filtered microservice detection data into the off-hook unit control object;

[0021] The off-hook unit control object and the off-hook decision standardized parameters are integrated into an off-hook unit data structure.

[0022] In one embodiment, the step of performing a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision comprises:

[0023] Perform a decision algorithm traversal detection on the microservice status under the off-hook unit according to the off-hook unit data structure to obtain a detection result;

[0024] storing the off-hook unit into a decision queue according to the detection result;

[0025] Query the preset off-hook quantity threshold limit and decision window time span;

[0026] The decision queue is operated in a sliding window according to the off-hook quantity threshold limit and the decision window time span to obtain an off-hook decision.

[0027] In one embodiment, the step of performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision comprises:

[0028] Based on the off-hook decision, determining whether the login module function of the off-hook unit is abnormal;

[0029] If the login module functions abnormally, an automatic off-hook isolation operation is performed on the off-hook unit according to the off-hook decision;

[0030] If the login module functions normally, the other micro-service modules of the off-hook unit are judged, and the off-hook unit is automatically isolated according to the off-hook decision and the judgment result.

[0031] In one embodiment, after the step of performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision, the step further includes:

[0032] Calling a query interface to query an off-hook result according to the off-hook decision;

[0033] When the off-hook result is a failure, the automatic off-hook isolation operation is re-initiated according to the off-hook decision.

[0034] In one embodiment, after the step of performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision, the step further includes:

[0035] The off-hook unit is monitored in real time according to preset overview monitoring indicators.

[0036] In addition, to achieve the above-mentioned objectives, the present application also proposes a microservice health status maintenance device, which includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the microservice health status maintenance method as described above.

[0037] In addition, to achieve the above-mentioned purpose, the present application also proposes a storage medium, which is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by the processor, the steps of the microservice health status maintenance method described above are implemented.

[0038] In addition, to achieve the above-mentioned purpose, the present application also provides a computer program product, which includes a computer program, and when the computer program is executed by a processor, the steps of the microservice health status maintenance method as described above are implemented.

[0039] One or more technical solutions proposed in this application have at least the following technical effects:

[0040] The microservice detection data is obtained based on the distributed streaming platform. The microservice detection data is used to evaluate the health status, performance, and resource usage of the microservices. The microservice detection data and the preset static off-hook decision standardized parameters are integrated into the off-hook unit data structure. The off-hook unit data structure is logically operated with the sliding window decision algorithm to obtain the off-hook decision. The off-hook decision determines to automatically isolate the off-hook units that have abnormalities in the application to maintain the health status of the microservices. The off-hook unit data structure is logically operated with the sliding window decision algorithm to efficiently respond to microservice failures. The automatic off-hook isolation operation is performed according to the off-hook decision to achieve automatic off-hook, avoid the uncertainty of manual operation, and achieve automatic and efficient maintenance of the health status of the microservices. BRIEF DESCRIPTION OF THE DRAWINGS

[0041] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0042] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0043] Figure 1 A flowchart of the first embodiment of the microservice health status maintenance method provided in this application;

[0044] Figure 2 A flowchart of the second embodiment of the microservice health status maintenance method provided in this application;

[0045] Figure 3 Standardize parameter tables for off-hook decisions;

[0046] Figure 4 It is a schematic diagram comparing the detection data status code, scenario description, and detection results;

[0047] Figure 5 It is the logic diagram of the off-hook decision algorithm;

[0048] Figure 6 A schematic diagram of a process for automatically performing off-hook isolation operation on an off-hook unit according to an off-hook decision;

[0049] Figure 7 A flowchart of the sixth embodiment of the microservice health status maintenance method of the present application is provided;

[0050] Figure 8 A flowchart of the seventh embodiment of the microservice health status maintenance method of the present application is provided;

[0051] Fig. 9 This is a schematic diagram of the module structure of the microservice health status maintenance device in the embodiment of the present application;

[0052] Fig.10 A schematic diagram of the device structure of the hardware operating environment involved in the microservice health status maintenance method in the embodiment of the present application;

[0053] The purpose, features and advantages of this application will be further described in conjunction with the embodiments and with reference to the accompanying drawings. DETAILED DESCRIPTION

[0054] It should be understood that the specific embodiments described herein are only used to explain the technical solutions of the present application and are not used to limit the present application.

[0055] In order to better understand the technical solution of the present application, a detailed description will be given below in conjunction with the accompanying drawings and specific implementation methods.

[0056] The main solution of the embodiment of the present application is: consume the microservice detection data obtained by the distributed flow platform, build an off-hook unit according to the server group deployment method in the microservice, integrate the microservice detection data and the decision standardization parameters into an off-hook unit data structure, and perform a sliding window decision algorithm logic operation on the data in the off-hook unit data structure to obtain an off-hook decision. The off-hook decision determines which abnormal off-hook unit to perform an automatic off-hook isolation operation on, and after the abnormal off-hook unit is off-hook, maintain the healthy status of the microservice.

[0057] The embodiment of this application takes into account that the mobile banking APP is a large-scale microservice application open 24 hours a day for the mobile Internet, which is composed of multiple microservices. In order to ensure that the application can be used normally and provide services, it is necessary to remove the abnormal microservice components that appear in the application to avoid affecting the normal function of the application. At present, the heartbeat detection function of the F5 load balancing technology is mainly relied on to ensure that the application units receiving the traffic are all in an available state, but the F5 heartbeat detection cannot detect the health status of all microservices of the mobile banking and perform off-hook operations on the abnormal microservices. The operation and maintenance personnel need to go to the computer room to perform manual off-hook isolation.

[0058] Therefore, the present application provides a solution to obtain the detection data of microservices by consuming a distributed streaming platform. The microservice detection data is used to evaluate the health status, performance and resource usage of microservices. Since the bank application APP server is divided into four clusters, each area cluster is composed of 6 groups of Pools, and each Pool constitutes the smallest service unit server group of the application, providing traffic support for multiple microservices in the application. Therefore, according to the server group deployment method of the microservice, an off-hook unit based on the Pool server group is constructed. The microservice detection data and the preset static off-hook decision standardized parameters are integrated into an off-hook unit data structure, and the off-hook unit data structure is logically operated by the sliding window decision algorithm to obtain the off-hook decision. The off-hook decision determines to automatically isolate the off-hook unit in the application that has an abnormality, so as to maintain the health status of the microservice. The off-hook unit data structure is logically operated by the sliding window decision algorithm to efficiently respond to the failure of the microservice, and the automatic off-hook isolation operation is realized according to the automatic off-hook decision to avoid the uncertainty of manual operation.

[0059] It should be noted that the execution subject of this embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, an automatic off-hook platform, etc. The following takes the automatic off-hook platform as an example to illustrate this embodiment and the following embodiments.

[0060] Based on this, the present application embodiment provides a microservice health status maintenance method, referring to Figure 1 , Figure 1 This is a flowchart of the first embodiment of the microservice health status maintenance method of the present application.

[0061] In this embodiment, the microservice health status maintenance method includes steps S10 to S40:

[0062] Step S10, obtaining microservice detection data based on the distributed streaming platform;

[0063] Kafka is selected as the distributed streaming platform. In the microservice architecture of the application, the automatic off-hook platform reads microservice detection data from the Kafka distributed streaming platform cluster. Microservice detection data is data collected in the microservice architecture to monitor, understand and optimize the performance, health status and behavior of each microservice component.

[0064] Choosing Kafka as a distributed streaming platform allows microservices to be decoupled and a loosely coupled architecture design to be implemented. At the same time, the reliability and real-time nature of the detection data can be ensured through Kafka's distributed and fault-tolerant features.

[0065] Step S20, integrating the microservice detection data and preset off-hook decision standardized parameters into an off-hook unit data structure;

[0066] The off-hook unit data structure is a comprehensive data model that includes microservice detection data and a series of off-hook decision standardized parameters related to the off-hook decision. The microservice detection data and the preset off-hook decision standardized parameters are integrated into the off-hook unit data structure. The microservice detection data can be directly embedded into the off-hook unit data structure, and the microservice detection data can be directly integrated with the standardized parameters in parallel or nested. The direct integration method is simple and intuitive, and the final off-hook unit data structure has high flexibility to meet the needs of different service types and detection data.

[0067] Integrating the microservice detection data and the preset off-hook decision standardized parameters into the off-hook unit data structure can also adopt an indirect association data integration method, which associates the microservice detection data with the standardized parameters through identifiers such as service ID, timestamp, etc., instead of directly integrating them into the same data structure. The indirect association data integration method can maintain the simplicity of the final off-hook unit data structure.

[0068] Step S30, performing a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision;

[0069] Sliding window is an algorithm technology commonly used to process array or string data. It defines two pointers (usually called left pointer and right pointer) to represent a "window" that can slide on the data. The decision algorithm logic is run through this window to traverse the data stored in the off-hook unit data structure, find abnormal data, locate the off-hook unit in abnormal state, and obtain the off-hook decision.

[0070] Step S40: performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision.

[0071] The off-hook decision is a decision information whose data type is a list and contains off-hook units in abnormal status. The abnormal off-hook units in the off-hook decision are automatically isolated from each other to remove the abnormal off-hook units from the normal application process, thereby preventing the abnormal off-hook units from continuing to affect other units that are working normally, and ensuring the stability and reliability of the application functions.

[0072] This embodiment provides a method for maintaining the health status of microservices, which obtains microservice detection data based on a distributed streaming platform. The microservice detection data is used to evaluate the health status, performance, and resource usage of microservices. The microservice detection data and preset static off-hook decision standardized parameters are integrated into an off-hook unit data structure, and the off-hook unit data structure is logically operated with a sliding window decision algorithm to obtain an off-hook decision. The off-hook decision determines to automatically perform off-hook isolation operations on off-hook units that have abnormalities in the application to maintain the health status of the microservices. The off-hook unit data structure is logically operated with a sliding window decision algorithm to efficiently respond to microservice failures. Automatic off-hook is achieved based on the automatic off-hook isolation operation of the off-hook decision, thereby avoiding the uncertainty of manual operations and achieving automatic and efficient maintenance of the health status of microservices.

[0073] Based on the first embodiment of the present application, the second embodiment of the present application is proposed. In the second embodiment of the present application, the same or similar contents as those of the above-mentioned embodiment 1 can be referred to the above introduction, and will not be repeated in the following.

[0074] On this basis, please refer to Figure 2 , before step S20 of integrating the microservice detection data and the preset off-hook decision standardized parameters into an off-hook unit data structure, the method further includes steps S1 to S3:

[0075] Step S1, constructing an off-hook unit according to the server group deployment mode of the microservice;

[0076] The mobile banking Nginx server is divided into four clusters, and each cluster consists of 6 groups of pools. Each pool constitutes the smallest service unit server group of mobile banking, and each pool is basically composed of 24 servers. Therefore, the configurations of different types of servers are not completely consistent. According to the CPU and memory, the servers are named SA, SB, SC, MA, MB, LA, and LB. The microservices deployed on servers with different configurations are different. The server deployment is mainly based on the traffic of the microservices. Combined with the architectural characteristics of the above microservices, the Pool server group is designed as the off-hook unit.

[0077] Step S2, regularly synchronizing microservice configuration data and server configuration data according to a preset synchronization time;

[0078] The microservice configuration data and Nginx server configuration data of the banking application APP are synchronized from the Internet resource management platform according to the preset synchronization time. The Nginx server of the banking application APP is divided into four clusters, each cluster contains 6 groups of pools, and each group of pools consists of 24 servers. Servers are divided into different types according to CPU and memory configuration, such as SA, SB, SC, MA, MB, LA, LB, etc. The synchronized Nginx server configuration data may include information such as server type, cluster, IP address, and running status.

[0079] The microservice configuration data includes information such as the microservice name, the Pool server group to which it belongs, and the operating status. The configuration data of the mobile banking Nginx server and microservices are synchronized from the Internet resource management platform to facilitate subsequent detection data integration and off-hook decisions.

[0080] Step S3, designing off-hook decision standardized parameters of the off-hook unit according to the server configuration data and the microservice configuration data.

[0081] Since the microservices deployed on servers with different configurations are different, they are deployed according to the traffic of the microservices. Therefore, the standardized parameters for off-hook decision are designed and constructed with the Pool server group as the off-hook unit. When designing the standardized parameters for off-hook decision of the off-hook unit, the characteristics of server data and microservice data are considered, and the standardized parameters for off-hook decision are designed according to the server configuration data and microservice configuration data, such as Figure 3 As shown, Figure 3 is an off-hook decision standardized parameter table, which contains multiple off-hook decision standardized parameters. For example, cluster_name indicates the cluster to which the off-hook unit belongs, and threshold is the maximum number of off-hook units allowed.

[0082] In this embodiment, an off-hook unit is constructed according to the server group deployment method of the microservice, and the microservice configuration data and the server configuration data are periodically synchronized according to the preset synchronization time. Standardized off-hook decision parameters are constructed according to the microservice configuration data and the server configuration data. The standardized off-hook decision parameters are used to automatically identify the unit that needs to perform the off-hook operation, thereby reducing manual intervention and decision-making time, and helping to quickly respond to microservice failures and anomalies.

[0083] Based on the first embodiment and / or the second embodiment of the present application, the third embodiment of the present application is proposed. In the third embodiment of the present application, the same or similar contents as those of the above-mentioned first and second embodiments can be referred to the above introduction, and will not be repeated in the following.

[0084] In this embodiment, step S20 of integrating the microservice detection data and the preset off-hook decision standardized parameters into an off-hook unit data structure may include steps S201 to S206:

[0085] Step S201, parsing the status code of the microservice detection data;

[0086] The microservice periodically sends a detection request to the Kafka cluster and stores the detected data in the form of messages. The automatic off-hook platform reads the microservice detection data from the Kafka cluster. Since the detection request is usually performed by sending an HTTP request to the microservice interface and obtaining the response status code, the microservice detection data includes the HTTP response status code. The status code can be obtained by parsing the microservice detection data, such as Figure 4 As shown, Figure 4 The following is a comparison diagram of the detection data status code, scenario description, and detection results. Among them, the status code 200 indicates a normal detection result, and the status codes 503 and 500 indicate abnormal detection results. Figure 4 By comparing the scenario description and application mode in the data, you can further know which pool server group and microservice the microservice detection data belongs to. The pool server group and microservice are parsed, and the off-hook unit belonging to the pool server group is not processed by default for lost or long-interrupted data.

[0087] Step S202, filtering the microservice detection data based on the status code to obtain filtered microservice detection data;

[0088] The microservice detection data is further filtered according to the scenario, application mode, and detection result represented by the status code. First, it is determined whether the off-hook unit to which the microservice detection data belongs is included in the pre-set off-hook platform management list. If the off-hook unit is not within the management scope, the detection data is filtered.

[0089] Further, it is determined whether the microservice to which the microservice detection data belongs is included in a preset off-hook platform management list, and if the microservice is not within the management scope, the detection data is filtered.

[0090] Step S203, obtaining decision condition parameters according to the cluster to which the off-hook unit to which the filtered microservice detection data belongs belongs;

[0091] It is understandable that the filtered microservice detection data still belongs to multiple different off-hook units, and the clusters to which different off-hook units belong are not consistent, and the decision condition parameters finally obtained are also different. The decision condition parameters include the number of data checks, data expiration time, and the time span that the data needs to meet when off-hook in order to comprehensively evaluate the status of the cluster and the off-hook unit in order to make a reasonable off-hook decision.

[0092] Step S204, creating an off-hook unit control object according to the decision condition parameters;

[0093] According to the decision condition parameters obtained from the cluster to which the off-hook unit belongs, the server type is distinguished and an off-hook unit control object is created. The off-hook unit control object defines which operations or commands can be executed on the off-hook unit, including possible management activities such as start, stop, restart, and configuration change.

[0094] Step S205, recording the filtered microservice detection data into the off-hook unit control object;

[0095] The filtered microservice detection data is recorded in the off-hook unit control object. If the off-hook unit control object has been created, the microservice detection data is directly recorded in the off-hook unit control object.

[0096] Step S206: Integrate the off-hook unit control object and the off-hook decision standardized parameter into an off-hook unit data structure.

[0097] The off-hook unit control object and the off-hook decision standardization parameters are integrated into the off-hook unit data structure. The off-hook unit data structure is based on the Pool server group, that is, the unit that allows the maximum number of detection data anomalies under the decision window time configured with the off-hook unit.

[0098] In this embodiment, the microservice detection data is filtered by parsing the status code obtained from the microservice detection data to reduce the amount of data for subsequent processing and improve overall efficiency. The decision condition parameters are obtained according to the cluster to which the off-hook unit to which the filtered data belongs, and a control object is created according to the decision condition parameters. The creation of the control object is the key to responsive maintenance. The off-hook unit control object contains all the necessary information and control logic for a specific off-hook unit so that appropriate operations can be performed when necessary. The filtered microservice detection data is counted into the off-hook unit control object, and the off-hook unit control object and the off-hook decision standardized parameters are integrated into the off-hook unit data structure. The automated and standardized process reduces the possibility of human error and improves the overall operation and maintenance efficiency, thereby automatically and efficiently maintaining the health status of the microservices in a timely manner.

[0099] Based on the above embodiments of the present application, a fourth embodiment of the method of the present application is proposed. In the fourth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction, and will not be repeated in the following.

[0100] In this embodiment, the step S30 of performing a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision may include steps S301 to S304:

[0101] Step S301, performing a decision algorithm traversal detection on the microservice status under the off-hook unit according to the off-hook unit data structure to obtain a detection result;

[0102] It is understandable that a bank application APP is composed of multiple microservices. The Nginx server of the bank application APP is divided into four clusters, and each area cluster is composed of 6 groups of Pools. Each Pool constitutes the smallest service unit server group of mobile banking. The off-hook unit is composed of Pool server groups. Each Pool server is composed of 24 servers. Servers with different configurations are deployed as microservices. Therefore, an off-hook unit may include multiple microservices, and a microservice is composed of multiple servers.

[0103] The off-hook unit data structure stores filtered detection data and off-hook decision standardization parameters. According to the off-hook unit data structure, each microservice state under the off-hook unit and the server constituting the microservice are detected to determine whether the off-hook unit has an abnormal state.

[0104] like Figure 5 As shown, Figure 5 The following is the logic diagram of the off-hook decision algorithm. Figure 5 The process of determining whether the off-hook unit is in an abnormal state is described in detail.

[0105] First, all microservices under the off-hook unit are traversed. In order to determine whether each microservice under the off-hook unit has an abnormal state, all servers under the microservice are traversed.

[0106] Furthermore, in the process of traversing the servers under a certain microservice, various scenarios such as publishing, scheduled restart, startup failure, application stop, detection timeout, etc. are considered, and the data results of each server are detected according to the off-hook unit data structure. If the detection record queue length is empty or less than the preset length threshold, it means that the microservice instance is normal, and continue to traverse other microservices; otherwise, continue to traverse the servers of this microservice.

[0107] Furthermore, if the most recent record in the detection record has expired during the process of detecting the data results of each server according to the off-hook unit data structure, the detection record queue is cleared, the microservice instance is normal, and other microservices continue to be traversed; otherwise, the server of this microservice continues to be traversed.

[0108] Furthermore, if the time span between the first record and the last record in the detection record queue does not reach the specified value during the process of detecting the data results of each server according to the off-hook unit data structure, it means that the microservice instance is normal and continues to traverse other microservices; otherwise, continues to traverse the servers of this microservice.

[0109] Further, determine whether there are normal records in the detection record queue. If so, it means that the microservice instance is normal, and continue to traverse other microservices; otherwise, it means that this microservice instance is abnormal, and repeat the above steps to traverse other servers of the microservice.

[0110] By traversing the microservice and all servers included in the microservice, running the decision algorithm, judging whether the off-hook unit is abnormal, and obtaining the detection result.

[0111] Step S302, storing the off-hook unit into a decision queue according to the detection result;

[0112] According to the off-hook unit data structure, each microservice status under the off-hook unit is detected. If a microservice abnormal detection result occurs, the off-hook unit is marked with an abnormal label and stored in the decision queue.

[0113] Step S303, querying the preset off-hook quantity threshold limit and decision window time span;

[0114] In order to avoid all server groups in a cluster going off-hook, if the threshold is not reached, the off-hook component is notified to query the preset off-hook quantity threshold limit and decision window time span, so as to further improve the accuracy of the off-hook decision.

[0115] Step S304: performing a sliding window operation on the decision queue according to the off-hook quantity threshold limit and the decision window time span to obtain an off-hook decision.

[0116] If the microservice detection status is normal within the decision window, the off-hook unit is removed from the decision queue. Slide to the next window to continue making decisions. The number of detection failures of a microservice within the decision window must be greater than or equal to the maximum allowed number of consecutive failures. Otherwise, continue making decisions. If the time span of the detection statistics exceeds the time span of the decision window that allows off-hook, a decision is made that the microservice needs to be off-hook. Otherwise, continue making decisions. The off-hook unit makes a decision that is normal or abnormal, depending on whether the query reaches the threshold limit on the number of off-hook calls, to avoid causing all server groups in a cluster to be off-hook. If the threshold is not reached, the off-hook component is notified.

[0117] In this embodiment, the decision algorithm is conveniently detected for the status of all microservices under the off-hook unit according to the off-hook unit data structure to obtain the detection result; the off-hook unit is stored in the decision queue according to the detection result, and the preset off-hook data threshold limit and decision window time span are queried to avoid causing all server groups under a certain cluster to go off-hook; the decision queue is logically operated with a sliding window in combination with the off-hook data volume threshold limit and the decision window time span to obtain the off-hook decision. Through the standardized configuration process of the off-hook decision, the health status of the microservice is efficiently maintained.

[0118] Based on the above embodiments of the present application, a fifth embodiment of the method of the present application is proposed. In the fifth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction, and will not be repeated in the following.

[0119] In this embodiment, the step S40 of performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision may include steps S401 to S403:

[0120] Step S401, judging whether the login module function of the off-hook unit is abnormal based on the off-hook decision;

[0121] The off-hook decision includes an off-hook list, which records the off-hook units that need to be automatically isolated from the off-hook. Since the off-hook operation of the automatic off-hook platform may be affected by the offline off-hook operation of the operation and maintenance personnel, and the off-hook units in the off-hook list may return to normal, whether the off-hook units in the off-hook list need to be further determined.

[0122] like Figure 6 As shown, Figure 6 The flowchart of automatic off-hook isolation operation of the off-hook unit according to the off-hook decision is shown in FIG. Figure 6 , the process of automatically performing off-hook isolation operation on the off-hook unit according to the off-hook decision is described in detail.

[0123] Whether the login module function of the off-hook unit is abnormal is determined based on the off-hook decision, and whether the off-hook unit in the off-hook decision needs to perform an automatic off-hook isolation operation is further determined based on the result of the determination of whether the login module function of the off-hook unit is normal.

[0124] Step S402, if the login module functions abnormally, automatically performing an off-hook isolation operation on the off-hook unit according to the off-hook decision;

[0125] If the off-hook unit login module is abnormal and is not in the off-hook list of the off-hook decision, it means that the off-hook unit has been manually off-hook offline, and the automatic off-hook platform does not need to perform automatic off-hook isolation operation;

[0126] If the off-hook unit login module is abnormal, and the off-hook unit is in the off-hook list of the off-hook decision, and the cluster does not exceed the upper threshold, and the sliding window time of this decision is valid, then the automatic off-hook isolation operation is triggered.

[0127] Step S403: If the login module functions normally, the other microservice modules of the off-hook unit are judged, and the off-hook unit is automatically isolated according to the off-hook decision and the judgment result.

[0128] If the login module of the off-hook unit is normal, but other microservice modules of the off-hook unit except the login module are abnormal, the automatic off-hook isolation operation will be triggered only when the off-hook unit is not in the off-hook list, the cluster does not exceed the maximum off-hook upper limit threshold, and the decision sliding window time is valid. In other cases, the automatic off-hook isolation operation will not be triggered.

[0129] If the login module of the off-hook unit is normal and the other microservices of the off-hook unit are normal, if it is in the off-hook list, it means that the off-hook unit has returned to normal and there is no need to perform automatic off-hook isolation operation.

[0130] It should be noted that after the automatic off-hook platform performs the automatic off-hook operation, since the overall traffic architecture of the application APP changes, it is necessary to perform traffic isolation operation on the Pool server to achieve a complete automatic off-hook isolation operation.

[0131] After changing the server group configuration file of the off-hook unit through the UCD interface call, the SelfStatus mode of the mobile banking GLogin login microservice of the LA machine under the Pool corresponding to the off-hook unit is switched to the Maintenance mode. The F5 load balancing traffic will not be distributed to this Pool server group, but only to the mobile banking Pool server group in the SelfStatus mode Success of the GLogin login microservice under LA, thereby isolating the problem Pool server group traffic, effectively ensuring the overall high availability of the application, and completing the complete off-hook isolation operation.

[0132] In this embodiment, the off-hook unit is automatically isolated according to the off-hook decision. The automatic off-hook isolation operation can quickly identify the microservice instance or off-hook unit with problems and isolate it from the service cluster in a short time. This rapid response mechanism helps to reduce the impact of problematic services on the overall system and prevent the spread of faults, thereby ensuring the overall stability and availability of the application and achieving timely and efficient maintenance of the health status of microservices.

[0133] Based on the above embodiments of the present application, a sixth embodiment of the method of the present application is proposed. In the sixth embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction, and will not be repeated in the following.

[0134] On this basis, please refer to Figure 7 , Figure 7 A flowchart of the sixth embodiment of the microservice health status maintenance method provided in this application.

[0135] In this embodiment, after step S40 of performing automatic off-hook isolation operation on the pre-built off-hook unit according to the off-hook decision, steps S50 to S60 are also included;

[0136] Step S50, calling a query interface to query an off-hook result according to the off-hook decision;

[0137] For the off-hook list in the off-hook decision, within the set frequency range, a query request is sent to the UCD interface, and the request includes the service instance or unit information in the off-hook list. Receive the response from the UCD interface, parse the off-hook result, and update the status of the off-hook list based on the result, recording which off-hook units have successfully picked up the phone and which off-hook units have failed to pick up the phone.

[0138] Step S60: When the off-hook result is a failure, the automatic off-hook isolation operation is re-initiated according to the off-hook decision.

[0139] When the off-hook result is a failure, the retry mechanism is started. The automatic off-hook isolation operation is re-initiated according to the off-hook decision. According to the preset retry strategy (such as the number of retries, retry interval, etc.), the automatic off-hook isolation operation is re-performed, and the result of each retry is recorded until the off-hook is successfully completed or the upper limit of the number of retries is reached.

[0140] After the automatic off-hook isolation operation (including retry) is completed, query the UCD interface again to obtain the latest off-hook unit operation status. Update the status record inside the automatic off-hook platform to ensure that it is consistent with the actual situation.

[0141] In this embodiment, in order to ensure the success of the off-hook operation, the UCD interface is called, and the off-hook result of the UCD interface is queried within the upper limit frequency of the UCD interface query. If the off-hook operation fails, a retry mechanism is initiated, and then the operation status of the off-hook unit is queried and updated. Through the automated off-hook decision and retry mechanism, human errors and interventions are reduced, and the operation and maintenance efficiency and response speed are improved, so as to realize timely and efficient and automatic maintenance of the health status of microservices.

[0142] Based on the above embodiments of the present application, a seventh embodiment of the method of the present application is proposed. In the seventh embodiment of the present application, the same or similar contents as those in the above embodiments can be referred to the above introduction, and will not be described in detail later.

[0143] On this basis, please refer to Figure 8 , Figure 8 A flowchart of the seventh embodiment provided for maintaining the health status of microservices in this application.

[0144] In this embodiment, after step S40 of performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision, step A10 is further included:

[0145] The off-hook unit is monitored in real time according to preset overview monitoring indicators.

[0146] The preset overview monitoring indicators include: Current off-hook server: real-time monitoring of the server that is currently off-hook; Current server to be off-hook: real-time monitoring of the server currently serving off-hook; Current unknown status server: server status that is not in the monitoring data of the off-hook platform, the main purpose is to troubleshoot server problems with abnormal locations; Currently included in management servers: display servers that are currently included in the off-hook platform management; Currently included in decision-making microservices: display microservices that are currently included in the off-hook platform management; Currently awaiting review microservices and servers: display servers and microservices that are not included in the off-hook platform management; Off-hook trend: visualize the regularity of servers that have been off-hook recently. Since the server that constitutes the application will perform an off-hook operation before going online during the online release process, the online release pictures can intuitively reflect the changing regularity of off-hook; Current off-hook overview: At the current time point, the decision-making system is off-hook or has completed off-hook and the server has not returned to normal. Real-time monitoring will be carried out, and an alarm notification will be sent to the notification personnel through the prophet platform.

[0147] Among them, the data analysis from the perspective of mobile banking server group and microservices is mainly based on two dimensions:

[0148] The running status of microservices can be analyzed to see which servers a microservice has abnormal running from a time perspective, and whether there is a regularity in the time and server of the abnormality, so as to assist development and operation and maintenance personnel in locating problems. The server status includes abnormal status, off-hook status, unknown status, unavailable status, and other status. The off-hook status is for a single server, and the unavailable status is for the Nginx server.

[0149] The running status of the off-hook unit is analyzed. From the perspective of time, it can be seen which microservices of an off-hook unit have abnormal running status. Whether there is a regularity between the time and microservices of the abnormality can help development and operation and maintenance personnel locate the problem. The microservice status counted includes abnormal status, off-hook status, unknown status, unavailable status, and other status.

[0150] In this embodiment, the off-hook unit that completes the automatic off-hook isolation operation is monitored through preset monitoring indicators. If the microservice abnormal state continues to occur later, the health status of the microservice can be maintained in time. Continuous monitoring and timely maintenance help to discover and resolve potential risks in the application, thereby preventing the risk from further deteriorating and affecting the overall stability of the system, and timely and automatically and efficiently maintaining the health status of the microservice.

[0151] It should be noted that the above examples are only used to understand the present application and do not constitute a limitation on the microservice health status maintenance method of the present application. More simple transformations based on this technical concept are all within the scope of protection of the present application.

[0152] This application also provides a microservice health status maintenance device, please refer to Fig. 9 , the microservice health status maintenance device includes:

[0153] A detection data acquisition module 10, which acquires microservice detection data based on a distributed streaming platform;

[0154] Kafka is selected as the distributed streaming platform. In the microservice architecture of the application, the automatic off-hook platform reads the microservice detection data from the Kafka distributed streaming platform cluster.

[0155] An off-hook unit data structure building module 20, used to integrate the microservice detection data and preset off-hook decision standardization parameters into an off-hook unit data structure;

[0156] Integrating the microservice detection data and the preset off-hook decision standardized parameters into the off-hook unit data structure can be achieved by directly embedding the microservice detection data into the off-hook unit data structure in parallel or nested with the standardized parameters.

[0157] The off-hook decision generating module 30 is used to perform a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision.

[0158] The decision algorithm logic is run through the sliding window to traverse the data stored in the off-hook unit data structure, find the abnormal data, locate the off-hook unit in the abnormal state, and obtain the off-hook decision.

[0159] The automatic off-hook isolation operation module 40 is used to perform an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision.

[0160] Automatically isolate the abnormal off-hook unit in the off-hook decision, remove the abnormal off-hook unit from the normal application process, prevent the abnormal off-hook unit from continuing to affect other normal working units, and ensure the stability and reliability of the application function.

[0161] The microservice health status maintenance device provided by the present application adopts the microservice health status maintenance method in the above embodiment, which can solve the technical problem of microservice health status maintenance. Compared with the prior art, the beneficial effects of the microservice health status maintenance device provided by the present application are the same as the beneficial effects of the microservice health status maintenance method provided by the above embodiment, and other technical features in the microservice health status maintenance device are the same as the features disclosed in the above embodiment method, which will not be repeated here.

[0162] The present application provides a microservice health status maintenance device, which includes: at least one processor; and a memory connected to the at least one processor in communication; wherein the memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the microservice health status maintenance method in the above-mentioned embodiment 1.

[0163] Reference below Fig.10 , which shows a schematic diagram of the structure of a microservice health status maintenance device suitable for implementing the embodiment of the present application. The microservice health status maintenance device in the embodiment of the present application may include but is not limited to mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Descriptions), PMPs (Portable Media Players), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), etc., and fixed terminals such as digital TVs, desktop computers, etc. Fig.10 The microservice health status maintenance device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present application.

[0164] like Fig.10As shown, the microservice health maintenance device may include a processing device 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM: Read Only Memory) 1002 or a program loaded from a storage device 1003 to a random access memory (RAM: Random Access Memory) 1004. Various programs and data required for the operation of the microservice health maintenance device are also stored in RAM1004. The processing device 1001, ROM1002, and RAM1004 are connected to each other via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following systems can be connected to the I / O interface 1006: input devices 1007 including, for example, a touch screen, a touchpad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; storage devices 1003 including, for example, a magnetic tape, a hard disk, etc.; and communication devices 1009. The communication device 1009 can allow the microservice health maintenance device to communicate wirelessly or wired with other devices to exchange data. Although the figure shows a microservice health maintenance device with various systems, it should be understood that it is not required to implement or have all the systems shown. More or fewer systems may be implemented or have instead.

[0165] In particular, according to the embodiments disclosed in the present application, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present application include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network through a communication device, or installed from a storage device 1003, or installed from a ROM 1002. When the computer program is executed by the processing device 1001, the above-mentioned functions defined in the method of the embodiment disclosed in the present application are executed.

[0166] The microservice health status maintenance device provided by the present application adopts the microservice health status maintenance method in the above embodiment, which can solve the technical problem of microservice health status maintenance. Compared with the prior art, the beneficial effects of the microservice health status maintenance device provided by the present application are the same as the beneficial effects of the microservice health status maintenance method provided by the above embodiment, and other technical features in the microservice health status maintenance device are the same as the features disclosed in the method of the previous embodiment, which will not be repeated here.

[0167] It should be understood that the various parts disclosed in this application can be implemented by hardware, software, firmware or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any one or more embodiments or examples in a suitable manner.

[0168] The above is only a specific implementation of the present application, but the protection scope of the present application is not limited thereto. Any person skilled in the art who is familiar with the present technical field can easily think of changes or substitutions within the technical scope disclosed in the present application, which should be included in the protection scope of the present application. Therefore, the protection scope of the present application should be based on the protection scope of the claims.

[0169] The present application provides a computer-readable storage medium having computer-readable program instructions (ie, computer programs) stored thereon, and the computer-readable program instructions are used to execute the microservice health status maintenance method in the above-mentioned embodiment.

[0170] The computer-readable storage medium provided in the present application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, systems or devices, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, system or device. The program code contained on the computer-readable storage medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination of the above.

[0171] The computer-readable storage medium may be included in the microservice health status maintenance device; or may exist independently without being assembled into the microservice health status maintenance device.

[0172] The above-mentioned computer-readable storage medium carries one or more programs. When the above-mentioned one or more programs are executed by the microservice health status maintenance device, the microservice health status maintenance device: obtains microservice detection data based on a distributed streaming platform; integrates the microservice detection data and preset off-hook decision standardized parameters into an off-hook unit data structure; performs a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision; and performs an automatic off-hook isolation operation on the pre-built off-hook unit according to the off-hook decision.

[0173] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0174] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0175] The modules involved in the embodiments described in this application may be implemented by software or hardware, wherein the name of the module does not constitute a limitation on the unit itself in some cases.

[0176] The readable storage medium provided in this application is a computer-readable storage medium, which stores computer-readable program instructions (i.e., computer programs) for executing the above-mentioned microservice health status maintenance method, and can solve the technical problems of microservice health status maintenance. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as the beneficial effects of the microservice health status maintenance method provided in the above-mentioned embodiment, and will not be repeated here.

[0177] The present application also provides a computer program product, including a computer program, which implements the steps of the microservice health status maintenance method as described above when the computer program is executed by a processor.

[0178] The computer program product provided in this application can solve the technical problem of maintaining the health status of microservices. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as the beneficial effects of the microservice health status maintenance method provided in the above embodiment, which will not be repeated here.

[0179] The above descriptions are only some embodiments of the present application, and are not intended to limit the patent scope of the present application. All equivalent structural changes made using the contents of the present application specification and drawings under the technical concept of the present application, or direct / indirect applications in other related technical fields are included in the patent protection scope of the present application.

Claims

1. A method for maintaining the health status of a microservice, characterized in that: The method comprises: Obtain microservice detection data based on the distributed streaming platform; Integrate the microservice detection data and preset off-hook decision standardized parameters into an off-hook unit data structure; Performing a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision; An automatic off-hook isolation operation is performed on a pre-built off-hook unit according to the off-hook decision.

2. The method according to claim 1, characterized in that Before the step of integrating the microservice detection data and the preset off-hook decision standardized parameters into an off-hook unit data structure, the step further includes: Build an off-hook unit based on the server group deployment method of microservices; Synchronize microservice configuration data and server configuration data regularly according to the preset synchronization time; The off-hook decision standardized parameters of the off-hook unit are designed according to the server configuration data and the microservice configuration data.

3. The method according to claim 2, characterized in that The step of integrating the microservice detection data and the preset off-hook decision standardized parameters into an off-hook unit data structure comprises: Parsing the status code of the microservice detection data; Filter the microservice detection data based on the status code to obtain filtered microservice detection data; Obtain decision condition parameters according to the cluster to which the off-hook unit to which the filtered microservice detection data belongs; Creating an off-hook unit control object according to the decision condition parameters; Recording the filtered microservice detection data into the off-hook unit control object; The off-hook unit control object and the off-hook decision standardized parameters are integrated into an off-hook unit data structure.

4. The method according to claim 2, characterized in that The step of performing a sliding window decision algorithm logic operation according to the off-hook unit data structure to obtain an off-hook decision comprises: Perform a decision algorithm traversal detection on the microservice status under the off-hook unit according to the off-hook unit data structure to obtain a detection result; storing the off-hook unit into a decision queue according to the detection result; Query the preset off-hook quantity threshold limit and decision window time span; The decision queue is operated in a sliding window according to the off-hook quantity threshold limit and the decision window time span to obtain an off-hook decision.

5. The method according to claim 1, characterized in that The step of performing an automatic off-hook isolation operation on a pre-built off-hook unit according to the off-hook decision comprises: Based on the off-hook decision, determining whether the login module function of the off-hook unit is abnormal; If the login module functions abnormally, an automatic off-hook isolation operation is performed on the off-hook unit according to the off-hook decision; If the login module functions normally, the other micro-service modules of the off-hook unit are judged, and the off-hook unit is automatically isolated from the off-hook unit according to the off-hook decision and the judgment result.

6. The method according to claim 1, characterized in that After the step of performing an automatic off-hook isolation operation on the pre-built off-hook unit according to the off-hook decision, the step further includes: Calling a query interface to query an off-hook result according to the off-hook decision; When the off-hook result is a failure, the automatic off-hook isolation operation is re-initiated according to the off-hook decision.

7. The method according to claim 1, characterized in that After the step of performing an automatic off-hook isolation operation on the pre-built off-hook unit according to the off-hook decision, the step further includes: The off-hook unit is monitored in real time according to preset overview monitoring indicators.

8. A microservice health status maintenance device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the microservice health status maintenance method according to any one of claims 1 to 7.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the microservice health status maintenance method according to any one of claims 1 to 7 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the microservice health status maintenance method according to any one of claims 1 to 7 are implemented.

Images