CN112667457A

CN112667457A - Method and system for monitoring service call under micro-service architecture

Info

Publication number: CN112667457A
Application number: CN201910985808.2A
Authority: CN
Inventors: 熊飞
Original assignee: Wuhan Fiberhome Integration Technologies Co ltd; Fiberhome Telecommunication Technologies Co Ltd
Current assignee: Wuhan Fiberhome Integration Technologies Co ltd; Fiberhome Telecommunication Technologies Co Ltd
Priority date: 2019-10-16
Filing date: 2019-10-16
Publication date: 2021-04-16

Abstract

The invention discloses a method and a system for monitoring service invocation under a micro-service architecture, and relates to the field of micro-service architecture service management. The method comprises the following steps: deploying an independently operating acquisition module to communicate with the micro-service; collecting information called by interfaces among the micro-services, and refining the monitoring granularity of the micro-services to the interfaces; and carrying out statistics according to the collected information and analyzing the running state of the microservice. The invention can refine the monitoring granularity of the micro-service to the interface, can accurately position the interface with fault, has small invasion to the micro-service system and does not influence the operation of micro-service logic.

Description

Method and system for monitoring service call under micro-service architecture

Technical Field

The invention relates to the field of micro-service architecture service management, in particular to a method and a system for monitoring service invocation under a micro-service architecture.

Background

Microservices Architecture is an architectural style, with a large complex software application consisting of one or more Microservices. Each microservice in the system can be deployed independently, with loose coupling between each microservice. Each microservice is only concerned with completing one task and well completing the task.

A software system developed by adopting a micro-service architecture is divided into a plurality of micro-services, the services are independent from each other but have a calling relationship, when software runs, a large amount of calls can be generated among the micro-services, and monitoring the calling condition among the micro-services is an important content of micro-service operation and maintenance.

In the process of implementing the present invention, the inventor finds that the monitoring of the service invocation between the micro-services in the prior art currently has at least the following problems:

the existing independent monitoring systems, such as zabbix, Prometheus, etc., generally obtain the occupation information of services on hardware resources through communication with an operating system, or obtain the service quality information of services, databases, or other software middleware through monitoring a specific port, which can only obtain the overall operating state of the micro-service or indirectly obtain the operating conditions of some functions in the micro-service, and when the micro-service fails, it is difficult to accurately locate which specific link fails.

Disclosure of Invention

The present invention aims to overcome the defects of the background technology, and provides a method and a system for monitoring service invocation under a micro-service architecture, wherein the monitoring granularity of the micro-service can be detailed to an interface, the interface with a fault can be accurately positioned, meanwhile, the invasion to the micro-service system is small, and the operation of micro-service business logic is not influenced.

In a first aspect, a method for monitoring service invocation under a micro-service architecture is provided, which includes the following steps:

deploying an independently operating acquisition module to communicate with the micro-service;

collecting information called by interfaces among the micro-services, and refining the monitoring granularity of the micro-services to the interfaces;

and counting the collected information and analyzing the running state of the microservice.

According to the first aspect, in a first possible implementation manner of the first aspect, the collecting information of interface invocation between micro services, and refining the monitoring granularity of the micro services to the interfaces includes the following steps:

the micro-service initiating the interface calling communicates with the acquisition module twice each time the micro-service calls the interfaces between the micro-services, and information called by the interfaces between the micro-services is transmitted to the acquisition module.

According to the first possible implementation manner of the first aspect, in a second possible implementation manner of the first aspect, the micro-service initiating the interface call communicates with the acquisition module twice each time the inter-micro-service interface call is performed, and information of the inter-micro-service interface call is transferred to the acquisition module, including the following steps:

the micro-service initiating the interface call is communicated with the acquisition module through an asynchronous call or non-blocking message transfer mechanism, firstly, the call parameter is transferred to the acquisition module, and then, the interface is called; the acquisition module identifies interface calling among the micro services according to the calling parameters; after the interface calling is finished each time, the micro-service initiating the interface calling transfers the calling record to the acquisition module.

According to the second possible implementation manner of the first aspect, in a third possible implementation manner of the first aspect, the invoking parameter includes: the method comprises the following steps of initiating a micro-service name and an example identifier of interface calling, providing the micro-service name and the example identifier of the interface calling, calling the interface name and identifying the calling identifier of the calling; the call record includes: calling parameters and calling execution results;

the acquisition module identifies interface calling among the microservices according to the calling parameters, and comprises the following steps: the acquisition module adopts three parameters in the calling parameters to identify the calling object, and the three parameters are as follows: the micro-service name and the instance identifier of the initiating interface call, the micro-service name and the instance identifier of the providing interface call and the called interface name.

According to a third possible implementation manner of the first aspect, in a fourth possible implementation manner of the first aspect, the method for collecting information of interface invocation between micro services and refining the monitoring granularity of the micro services to the interfaces further includes the following steps:

the acquisition module records the calling information of each calling object each time, and the acquisition module comprises the following steps: calling the identifier, the calling start time, the calling end time and the calling execution result, and calculating and storing the calling duration;

the collection module periodically counts the service quality data of the calling object in the window period, and the method comprises the following steps: throughput, call success ratio, average call duration.

In a second aspect, a system for monitoring service invocation under a micro-service architecture is provided, which includes:

at least one independently operating acquisition module for: collecting information called by interfaces among the micro-services, and refining the monitoring granularity of the micro-services to the interfaces;

a supervision center for: and the micro-service monitoring module is communicated with the acquisition module, acquires the information called by the interface between the micro-services collected by the acquisition module, counts the acquired information and analyzes the running state of the micro-services.

According to the second aspect, in a first possible implementation manner of the second aspect, the acquiring module collects information of interface invocation between micro services, and refines the monitoring granularity of the micro services to the interfaces, including the following steps:

According to the first possible implementation manner of the second aspect, in a second possible implementation manner of the second aspect, the micro-service initiating the interface call communicates with the acquisition module twice each time the micro-service performs the interface call between the micro-services, and transmits information of the interface call between the micro-services to the acquisition module, which specifically includes the following steps:

According to a second possible implementation manner of the second aspect, in a third possible implementation manner of the second aspect, the invoking parameter includes: the method comprises the following steps of initiating a micro-service name and an example identifier of interface calling, providing the micro-service name and the example identifier of the interface calling, calling the interface name and identifying the calling identifier of the calling; the call record includes: calling parameters and calling execution results;

According to a third possible implementation form of the second aspect, in a fourth possible implementation form of the second aspect,

the acquisition module is further configured to: recording the calling information of each calling object each time, including: calling the identifier, the calling start time, the calling end time and the calling execution result, and calculating and storing the calling duration; periodically counting the service quality data of the calling object in the window period, wherein the service quality data comprises the following steps: throughput, calling success ratio and average calling duration;

the supervision center is specifically configured to: and periodically communicating with all the acquisition modules, acquiring the service quality data of all the calling objects counted by the acquisition modules in a window period, and counting, aggregating and analyzing the service quality data.

Compared with the prior art, the invention has the following advantages:

(1) the invention refines the monitoring granularity of the micro-services to the interfaces called between the micro-services, and the obtained monitoring data can directly represent the operation quality of each interface called between the micro-services. When the micro-service fails, the failed interface can be accurately positioned.

(2) The invention arranges an independently operated acquisition module which independently finishes the acquisition and calculation of data. For each calling, the acquisition module realizes the information acquisition of the called interface through two times of data transmission with the micro-service, the independently operated acquisition module does not intervene in the calling process of the interface between the micro-services, the micro-service does not depend on the acquisition module to finish the calling of the interface between the micro-services, the micro-service participating in the calling of the interface has no coupling relation with the acquisition module, and the influence on the respective operation performance is small. Therefore, the method has small invasion to the micro-service system and does not influence the operation of micro-service business logic.

(3) For the existing micro-service which does not provide the service calling monitoring function, when the invention is applied, the communication problem between the micro-service and the acquisition module is generally only needed to be solved, when the interface is called between the micro-services, the micro-service communicates with the acquisition module through an asynchronous calling or non-blocking message transmission mechanism, and the information called by the interface between the micro-services is transmitted to the acquisition module. The improved mode has universality, does not influence the original business logic, and has small transformation on the microservice.

(4) The operation logic of the acquisition module is irrelevant to the specific service logic, and the method has good universality.

Drawings

Fig. 1 is a flowchart of a method for monitoring service invocation under a micro service architecture in an embodiment of the present invention.

Fig. 2 is a general structural diagram of a system for monitoring service invocation under the micro service architecture in the embodiment of the present invention.

FIG. 3 is a diagram illustrating service invocation statistics in an embodiment of the invention.

FIG. 4 is a flow diagram of a notification collection module prior to inter-microservice invocation in an embodiment of the present invention.

FIG. 5 is a flow diagram of a post notification collection module after an inter-microservice call in an embodiment of the invention.

FIG. 6 is a flow chart of the collection module counting service invocation data in an embodiment of the present invention.

Detailed Description

In order that those skilled in the art will better understand the present invention, the following detailed description of the invention is provided in conjunction with the accompanying drawings and the detailed description of the invention.

Note that: the example to be described next is only a specific example, and does not limit the embodiments of the present invention necessarily to the following specific steps, values, conditions, data, orders, and the like. Those skilled in the art can, upon reading this specification, utilize the concepts of the present invention to construct more embodiments than those specifically described herein.

Referring to fig. 1, an embodiment of the present invention provides a method for monitoring service invocation under a micro-service architecture, including the following steps:

s1, deploying an independently operated acquisition module to communicate with the micro-service;

s2, collecting information of interface calling among the micro-services, and refining the monitoring granularity of the micro-services to the interface;

and S3, counting the collected information and analyzing the running state of the microservice.

In a preferred embodiment, collecting information of interface call between micro services, and refining the monitoring granularity of the micro services to the interfaces comprises the following steps:

the micro service initiating the interface calling carries out twice communication with the acquisition module when carrying out the interface calling between the micro services each time, and the method comprises the following steps: and transferring the calling parameters to the acquisition module before the calling execution, transferring the calling records to the acquisition module after the calling execution is finished, and transferring the information called by the interface between the micro-services to the acquisition module.

As a preferred embodiment, the micro-service initiating the interface call communicates with the acquisition module twice each time the micro-service performs the interface call between the micro-services, and transfers the information of the interface call between the micro-services to the acquisition module, including the following steps:

the micro-service communicates with the acquisition module through an asynchronous calling or non-blocking message transmission mechanism, and transmits information called by an interface between the micro-services to the acquisition module. The micro-service initiating the interface calling firstly transmits calling parameters to the acquisition module and then calls the interface; the acquisition module identifies interface calling among the micro services according to the calling parameters; after the interface calling is finished each time, the micro-service initiating the interface calling transfers the calling record to the acquisition module.

As a preferred embodiment, the invoking parameter includes: the method comprises the following steps of initiating a micro-service name and an example identifier of interface calling, providing the micro-service name and the example identifier of the interface calling, calling the interface name and identifying the calling identifier of the calling; the calling identifier is dynamically generated by the micro service initiating the calling before calling the interface each time, the calling identifier called by each interface is consistent before and after execution, and the identifier should have uniqueness.

The call record includes: and calling parameters and calling an execution result. The call execution results are generally classified as call success and call failure.

As a preferred embodiment, collecting information of interface call between micro services, and refining the monitoring granularity of the micro services to the interface, further comprises the following steps:

The embodiment of the invention monitors the calling of the interface between the micro-services to obtain the information of the calling of the interface between the micro-services.

The acquisition module records the calling information of each calling for each calling object. The collection module periodically counts the service quality information of the calling object in the window period.

When the acquisition module receives a calling parameter transmitted by the microservice, whether a calling object corresponding to the calling parameter exists is searched according to the calling parameter, if not, a calling object is newly established, and a table is established for the calling object to store calling information (the table refers to a data structure established for storing the calling information, and the same is applied below); if the calling object exists, the calling object is not newly built.

If the micro service does not transmit the call record, the call record is the call parameter transmitted before the interface is called once, the acquisition module takes out the call identifier in the call parameter, records the call identifier in a table, and takes the current time as the starting time of the call.

If the micro service transmits the call record, which indicates that the call record is information transmitted after the call interface is finished, the acquisition module takes out the call identifier in the call record, searches the call information which is the same as the call identifier in a table by using the call identifier, uses the current time as the end time of the call, and calculates and records the time length of the call and the call execution result.

When periodically counting each calling object, the acquisition module selects data in a time window in a table corresponding to the calling object to count, wherein the time window refers to a time length traced back for a period of time from the current time, and the calling start time of the calling information used for counting is included in the time window, so that the counting timeliness can be ensured.

And the acquisition module counts the service quality information of the calling object, such as throughput, calling success ratio, average calling duration and the like in the specified time.

The calculation formula of the throughput, the calling success ratio and the average calling duration is as follows:

throughput is the total number of calls within a time window/time window;

the calling success ratio is the calling success times in the time window/the total calling times in the time window;

the average call duration is the total call duration in the time window/the total number of calls in the time window, and the total call duration in the time window is obtained by adding the durations of each call.

The acquisition module periodically counts the acquired data, but only stores the latest statistical result; both the statistical period and the time window can be set.

The acquisition module regularly clears the calling information which is in the form of the calling object record calling information and has long time, but does not delete the calling object, and the calling object always exists during the operation period of the acquisition module once being generated.

The embodiment of the invention can also set a monitoring index for calling the service, compare the acquired service quality data with the set index, generate the service quality alarm when the condition that the index exceeds the limit is found, record the alarm occurrence time, the numerical value and the index value, and display the alarm to the front end or report the alarm to the operation and maintenance personnel.

If the service quality is recovered to normal from the alarm, the alarm module records the time of the alarm recovery and modifies the alarm state.

In the embodiment of the invention, the acquisition module which runs independently is deployed, the acquisition module can be deployed together with the micro-service or can be deployed independently, and the acquisition module and the micro-service run in independent processes respectively in any deployment mode, but can be communicated with each other.

In the process of calling the interface between the micro-services each time, the micro-service initiating the interface calling communicates with the acquisition module twice, and the method specifically comprises the following steps: and transmitting the calling parameters to the acquisition module before the calling interface, and transmitting the calling record to the acquisition module after the calling interface is finished. The micro-service initiating the interface call transmits a call parameter to the acquisition module, informs the acquisition module to initiate one interface call, then initiates the interface call, and simultaneously the acquisition module calls an object according to the call parameter identifier and searches whether call information of the call object exists in a cache, namely the information of the micro-service initiating interface call and the information of the acquisition module collecting the interface call are two independent processes which do not influence each other and are not coupled, so that the synchronous operation can be understood. The embodiment of the invention realizes the acquisition of the calling information through two times of communication between the micro-service and the acquisition module, has small invasion to the micro-service system and does not influence the operation of micro-service business logic.

The monitoring object of the embodiment of the invention is interface calling among micro services, wherein the meaning of the interface refers to a callable interface provided by the micro services for other micro services, generally, one interface completes a specific function, the monitoring granularity of the micro services is refined to the extent that the interface can more accurately obtain the quality data of micro service operation, and the bottleneck or fault of the micro service operation is more accurately positioned.

The interface call between the micro-services is monitored, some open-source components can be considered to be integrated, and the open-source components are used for monitoring in the calling process, but in the mode, the monitoring function is generally arranged in the micro-services and is in the same process with other business logics of the micro-services, so that the coupling of the monitoring function and the business function is brought. The existing microservice does not consider the statistical function of recording service call at the beginning of development, and the existing microservice needs to be incorporated into service call monitoring at present, so a solution with low modification cost and low invasiveness is needed.

The embodiment of the invention monitors the calling of the interface between the micro-services to obtain the information of the calling of the interface between the micro-services, refines the monitoring granularity of the micro-services to the interface, analyzes the running state of the micro-services through the collected information data, is favorable for accurately positioning the problems in the running of the micro-services, has small invasion to the micro-service system and does not influence the running of the logic of the micro-services.

The indexes such as the load condition, the response state and the like of each micro service are obtained in time, operation and maintenance personnel can judge the operation state of the micro service, the micro service fault can be diagnosed, and dynamic adjustment of the micro service can be facilitated. The existing granularity of monitoring the micro-service is the overall operating parameters for the micro-service, such as: the monitoring granularity is not fine enough, although the data of the whole operation of the microservice can indicate the operation state of the microservice to a certain extent, the calling condition of each interface in the microservice cannot be accurately indicated.

The embodiment of the invention refines the indexes to the specific interface of the micro-service, can more accurately analyze the operation state of the micro-service, locate the fault, or make more accurate adjustment and improvement.

Taking throughput as an example, a conventional monitoring system may obtain the total throughput of a certain micro service by reading network I/O, but cannot obtain the specific throughput of each interface in the micro service, for example, there are interfaces for creating, deleting, modifying, etc. in the micro service, which interface is called is high in throughput and which is low, and in the micro service, the situation that often has a problem is concentrated on a few interfaces, so it is necessary to specifically locate which interface has a problem from monitoring data, for example: calling pressure is overlarge or response delay is overlarge, so that operation and maintenance personnel can accurately position faults and take measures, and developers can improve micro-services.

The embodiment of the invention also provides a system for monitoring service invocation under the micro-service architecture, which comprises the following steps:

As a preferred embodiment, the acquisition module collects information of interface invocation between micro services, and refines the monitoring granularity of the micro services to the interface, and includes the following steps:

As a preferred embodiment, the micro service initiating the interface call communicates with the acquisition module twice each time the micro service performs the interface call between the micro services, and transfers the information of the interface call between the micro services to the acquisition module, which specifically includes the following steps:

the micro-service communicates with the acquisition module through an asynchronous calling or non-blocking message transmission mechanism, and transmits information called by an interface between the micro-services to the acquisition module.

The micro-service initiating the interface calling firstly transmits calling parameters to the acquisition module and then calls the interface; the acquisition module identifies interface calling among the micro services according to the calling parameters; after the interface calling is finished each time, the micro-service initiating the interface calling transfers the calling record to the acquisition module.

As a preferred embodiment, the invoking parameter includes: the method comprises the following steps of initiating a micro-service name and an example identifier of interface calling, providing the micro-service name and the example identifier of the interface calling, calling the interface name and identifying the calling identifier of the calling; the call record includes: calling parameters and calling execution results;

As a preferred embodiment, the acquisition module is further configured to: recording the calling information of each calling object each time, including: calling the identifier, the calling start time, the calling end time and the calling execution result, and calculating and storing the calling duration; periodically counting the service quality data of the calling object in the window period, wherein the service quality data comprises the following steps: throughput, call success ratio, average call duration.

Referring to fig. 2, the system further includes a separately deployed supervision center, and the supervision center records address information of all the acquisition modules. The monitoring center comprises a front end and a background, the front end provides data display and user interaction, and the background comprises a statistic module and an alarm module.

The statistics module is to: periodically communicating with all the acquisition modules, acquiring statistical information of calling objects stored in the acquisition modules, and storing the statistical information into a file or a database. The statistical module performs aggregation analysis on the statistical information after acquiring the statistical information, and aggregates the service quality statistical data of the interfaces belonging to the same micro service instance together to obtain the total service quality data of the service provider.

The statistics module is further to: and setting a monitoring index for service calling, comparing the acquired service quality data with the set index, and triggering an alarm module to work when the condition that the index is out of limit is found.

The alarm module is used for: and generating a service quality alarm, recording alarm occurrence time, numerical value and index value, and displaying the alarm to the front end or reporting the alarm to operation and maintenance personnel.

After the alarm module generates the service quality alarm, if the service quality is recovered to normal from the alarm, the alarm module records the recovery time of the alarm and modifies the alarm state.

The acquisition module in the embodiment of the invention is responsible for acquiring service calling data of each micro service, the statistical module acquires the data from the acquisition module at regular time for statistics and storage, the alarm module judges whether the service calling has problems according to the acquired data and by combining an alarm strategy and sends out an alarm, and the front end is responsible for displaying the data and interacting with a user, and the specific implementation steps are as follows:

1. and independently deploying an acquisition module in each micro-service deployment environment, wherein the acquisition module is operated in an independent process to monitor and count the calling condition among the micro-services.

The existing micro-service is reformed, so that the micro-service can communicate with the acquisition module when being called among services, and parameters are transmitted. The invocation within the microservice does not require the acquisition module to be notified.

The acquisition module provides the following interfaces to the outside: 1. acceptable parameters record the beginning and end of a service invocation; 2. the recorded service invocation statistics may be returned in response to the request.

In practice, the microservice communicates with the collection module in a non-blocking call manner, which is implemented by an interface provided by the collection module (or in a message notification manner, but this requires the addition of message middleware).

2. Referring to fig. 3, when a call interface between micro services occurs, the micro service initiating the call notifies the acquisition module in a non-blocking call mode before the call occurs and when the call ends and returns a result.

The microservice notifies the acquisition module before calling other microservices, transfers calling parameters to the acquisition module, and specifically comprises: the calling method comprises the following steps of initiating a micro-service name and an instance identifier of an interface call, providing the micro-service name and the instance identifier of the interface call, calling the interface name and identifying the calling identifier of the call.

It should be noted here that if the micro service is deployed in a multi-instance, the name of the micro service needs to be accompanied by the identifier of the instance. In practical application, when the micro-service is deployed for a single instance, the name of the micro-service is also provided with the identifier of the instance. Thus, to distinguish between microservices, either single-instance or multi-instance deployments, microservice names are accompanied by instance identifiers.

3. Referring to fig. 4, the microservice a initiating the call transfers the call parameter to the acquisition module, notifies the acquisition module to initiate an interface call, and then the microservice a initiates the interface call. After receiving the calling parameter, the acquisition module searches whether a calling object corresponding to the parameter exists according to the calling parameter, and if the calling object does not exist, the acquisition module creates the calling object; if the calling object exists, the calling object is directly referred to without creating the calling object. Therefore, the information of the interface call initiated by the micro-service A and the information of the interface call collected by the collection module are two independent processes which do not influence each other, and the two processes are not coupled and can be understood as synchronous operation. Therefore, the embodiment of the invention has small invasion to the micro-service system and does not influence the operation of micro-service business logic.

4. Referring to fig. 4, the collection module adds a record to the "table" for storing the call information of the call object created or found in the previous step, uses the call identifier of the call transmitted in step 2 as the identifier of the record, and uses the current time as the start time of the call.

For example, the collection module maintains a sequence for storing call information (each call object has such a sequence corresponding to the "table" described above) in the call objects created or located in the previous step, the sequence has a length limitation, stores 100 times of call information by default, and when the number of records exceeds a default value, covers the earliest record, adds a record in the sequence for each service call, and the record should include the call identifier and the call start time (the current time is used as the start time of the call) transmitted by the micro service.

5. Referring to fig. 3, after receiving a return result of the service call, the microservice initiating the interface call notifies the acquisition module again, and transmits a call record to the acquisition module, which specifically includes: and calling parameters and calling an execution result.

6. Referring to fig. 5, the micro service initiating the call transfers the call parameter to the collection module, and after receiving the call parameter transferred by the micro service, the collection module searches for the call information with the call identifier same as the call identifier in the "table" of the call object, and calculates and stores the call duration, the call execution result, and the call end time (with the current time as the end time of the call).

7. Referring to fig. 6, the collection module periodically counts the service quality data of each monitored calling object within the time window, including: and the throughput, the calling success ratio and the average calling time are updated to the cache of the acquisition module after the completion.

For example, the acquisition module completes the statistical operation every 1 second and updates the statistical result in the cache, the time window refers to a statistical time period which is backward-pushed for a period of time from the current time point, the default window period is 10 seconds, namely, when each time is counted, all call information in the time period which is backward traced for 10 seconds from the current time point is counted, and the statistical interval and the size of the time window can be modified.

8. The acquisition module regularly clears the calling information which is in the form of the calling object record calling information and has long time, but does not delete the calling object, and the calling object always exists during the operation period of the acquisition module once being generated. For example, the acquisition module checks every 1 second for all invocations of the "table" and deletes the record in the "table" that is before the time window.

9. A monitoring center is independently deployed and comprises a front end and a background, the front end provides data display and user interaction, the background comprises a statistic module and an alarm module, and the monitoring center needs to record address information of all acquisition modules.

And starting a periodic task on the supervision center, wherein the statistical module periodically communicates with all the acquisition modules to acquire the latest service quality data stored in the acquisition modules, and the data are stored in a file or/and a database.

The statistical module can also process the collected data to obtain different statistical data, and the processing content comprises the following steps:

(1) data aggregation is performed under specified conditions, for example: the total times of the specified service which is called by other services are counted, so that the load condition of the service can be known more intuitively; and aggregating the call data corresponding to the same provided call service to obtain the total throughput, the call success ratio and the average call duration of the provided call service.

(2) And under the condition that multiple instances exist, comparing the call data of different instances of the same service to obtain the load sharing data.

(3) And carrying out TOP-N statistics on the throughput, the call success ratio and the average call duration.

And after the statistical module processes the data, storing the obtained service quality data and the data after statistical analysis in a database.

The supervision center also needs to provide a data viewing function to present the statistical data in the form of charts and time sequence charts.

10. The monitoring center can set monitoring indexes of service calling, the indexes respectively correspond to throughput, calling success ratio and average calling duration, the indexes are a group of threshold values, a group of default indexes can be prefabricated, and different indexes can be set for different services.

After the service quality data is obtained each time, the data is compared with the index, the service quality alarm is generated when the out-of-limit condition is found, the alarm occurrence time, the value and the index value are recorded, and the alarm is displayed to the front end or reported to operation and maintenance personnel. In addition, if the service quality is recovered to normal from the alarm, the alarm module records the time of the alarm recovery and modifies the alarm state.

The front end provides the configuration and modification functions of the alarm indexes, provides the display function of statistical data, and presents the data in the form of graphs, tables or timing diagrams when maintenance personnel view the monitoring and alarm data.

The embodiment of the invention provides an effective solution for monitoring the calling condition between services under the micro-service architecture, and has the main advantages that:

1. the embodiment of the invention can effectively monitor the calling condition among the micro-services, the monitoring granularity is refined to the interface level, the problems of the micro-services in the aspects of load sharing, execution results and response speed can be found in time, the problem positions can be accurately positioned, and the fault diagnosis and dynamic adjustment of the services are facilitated.

2. The acquisition module is deployed independently, the calling process among services is not involved, the results are recorded only before and after calling, the micro-service does not depend on the module to complete service calling, and the calling logic of the original system is not influenced.

3. For the existing micro-service which does not provide the service call monitoring function, when the achievement of the invention is applied, the communication problem between the micro-service and the acquisition module is generally only needed to be solved, two times of non-blocking calls (or message transmission) are added when the micro-service is called, the improvement mode has universality, the original service logic is not influenced, and the micro-service is little modified.

4. The embodiment of the invention adopts the micro-service name and the instance identifier which initiate the call plus the micro-service name and the instance identifier which provide the call plus the interface name of the call to identify a monitored call object, can meet the deployment scene of a single instance and multiple instances of the micro-service, and refines the monitoring granularity to the interface.

5. The embodiment of the invention provides a service quality alarm function, obtains the alarm of out-of-limit index by setting the index value and comparing the index value with the acquired value, and can inform operation and maintenance personnel to observe and maintain the service in time.

Based on the same inventive concept, the embodiments of the present application further provide a computer-readable storage medium, on which a computer program is stored, and the computer program, when executed by a processor, implements all or part of the method steps of the above method.

The present invention can implement all or part of the processes of the above methods, and can also be implemented by using a computer program to instruct related hardware, where the computer program can be stored in a computer-readable storage medium, and when the computer program is executed by a processor, the steps of the above method embodiments can be implemented. Wherein the computer program comprises computer program code, which may be in the form of source code, object code, an executable file or some intermediate form, etc. The computer readable medium may include: any entity or device capable of carrying computer program code, recording medium, U.S. disk, removable hard disk, magnetic disk, optical disk, computer Memory, Read-Only Memory (ROM), Random Access Memory (RAM), electrical carrier wave signals, telecommunications signals, software distribution media, and the like. It should be noted that the computer readable medium may contain other components which may be suitably increased or decreased as required by legislation and patent practice in jurisdictions, for example, in some jurisdictions, in accordance with legislation and patent practice, the computer readable medium does not include electrical carrier signals and telecommunications signals.

Based on the same inventive concept, an embodiment of the present application further provides an electronic device, which includes a memory and a processor, where the memory stores a computer program running on the processor, and the processor executes the computer program to implement all or part of the method steps in the method.

The Processor may be a Central Processing Unit (CPU), other general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic, discrete hardware components, etc. The general purpose processor may be a microprocessor or the processor may be any conventional processor or the like, the processor being the control center of the computer device and the various interfaces and lines connecting the various parts of the overall computer device.

The memory may be used to store computer programs and/or modules, and the processor may implement various functions of the computer device by executing or executing the computer programs and/or modules stored in the memory, as well as by invoking data stored in the memory. The memory may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required by at least one function (e.g., a sound playing function, an image playing function, etc.); the storage data area may store data (e.g., audio data, video data, etc.) created according to the use of the cellular phone. In addition, the memory may include high speed random access memory, and may also include non-volatile memory, such as a hard disk, a memory, a plug-in hard disk, a Smart Media Card (SMC), a Secure Digital (SD) Card, a Flash memory Card (Flash Card), at least one magnetic disk storage device, a Flash memory device, or other volatile solid state storage device.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, server, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, optical storage, and the like) having computer-usable program code embodied therein.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), servers and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

It will be apparent to those skilled in the art that various changes and modifications may be made in the present invention without departing from the spirit and scope of the invention. Thus, if such modifications and variations of the present invention fall within the scope of the claims of the present invention and their equivalents, the present invention is also intended to include such modifications and variations.

Claims

1. A method for monitoring service invocation under a micro-service architecture is characterized by comprising the following steps:

2. The method of claim 1, wherein: the method for monitoring the micro-services comprises the following steps of collecting information of interface calling between the micro-services and refining the monitoring granularity of the micro-services to the interfaces:

3. The method of claim 2, wherein: the method comprises the following steps that the micro-service initiating interface calling communicates with the acquisition module twice when the micro-service calls the interfaces between the micro-services each time, and information called by the interfaces between the micro-services is transmitted to the acquisition module, and the method comprises the following steps:

4. The method of claim 3, wherein: the calling parameters comprise: the method comprises the following steps of initiating a micro-service name and an example identifier of interface calling, providing the micro-service name and the example identifier of the interface calling, calling the interface name and identifying the calling identifier of the calling; the call record includes: calling parameters and calling execution results;

5. The method of claim 4, wherein: collecting the information of interface calling between the micro-services, and refining the monitoring granularity of the micro-services to the interface, and further comprising the following steps:

6. A system for monitoring service invocation under a microservice architecture, comprising:

7. The system of claim 6, wherein: the acquisition module collects information called by interfaces among the micro-services and refines the monitoring granularity of the micro-services to the interfaces, and the acquisition module comprises the following steps:

8. The system of claim 7, wherein: the method comprises the following steps that the micro-service initiating interface calling communicates with the acquisition module twice when the micro-service calls the interfaces between the micro-services each time, and information called by the interfaces between the micro-services is transmitted to the acquisition module, and the method specifically comprises the following steps:

9. The system of claim 8, wherein: the calling parameters comprise: the method comprises the following steps of initiating a micro-service name and an example identifier of interface calling, providing the micro-service name and the example identifier of the interface calling, calling the interface name and identifying the calling identifier of the calling; the call record includes: calling parameters and calling execution results;

10. The system of claim 9, wherein: