An API monitoring method and device for an energy internet marketing service system and a storage medium

Abstract

The application provides an API monitoring method and device in an energy internet marketing service system and a storage medium, the method comprising: acquiring all APIs that can be called in the energy internet marketing service system, and constructing a two-dimensional dependency matrix based on the dependency relationship of the APIs; monitoring the calling of all the APIs, and generating a calling record for each calling; generating an API calling heat map based on the calling records of all the APIs, and marking the average value of the calling response time of each API in the API calling heat map; determining a bottleneck API affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API calling heat map, and processing the bottleneck API. The application determines the bottleneck API affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API calling heat map, solves the problem that the calculation resource for determining the bottleneck API is large and the accuracy is not high, and thus the system performance can be recovered as soon as possible.

Description

Technical Field

[0001] This invention relates to the field of computer system program control technology, and specifically to a method, device, and storage medium for monitoring APIs in an energy internet marketing service system. Background Technology

[0002] Energy Internet marketing service systems, such as those using power grid marketing systems, involve multiple sales channels, each with multiple sales terminals. The amount of transaction data per unit time (e.g., one day or one hour) is extremely large. Therefore, distributed databases are generally used to store transaction data. Due to the large number of database nodes, load balancing algorithms are needed when storing data. Furthermore, when the amount of data on a particular database node is large, data migration algorithms are required to migrate the data. These operations all require the use of scheduling nodes. Because of the large amount of power grid transaction data, the data processing load on scheduling nodes increases, and in extreme cases, this can lead to scheduling node downtime, affecting system performance.

[0003] In existing technologies, another approach uses multiple scheduling nodes. However, using multiple scheduling nodes makes the scheduling algorithm more complex, makes it difficult to find bugs, and increases maintenance costs. Summary of the Invention

[0004] In view of one or more technical defects in the prior art, the present invention proposes the following technical solution.

[0005] This invention proposes a method for monitoring APIs in an energy internet marketing service system, the method comprising:

[0006] The acquisition steps involve obtaining all callable APIs in the energy internet marketing service system and constructing a two-dimensional dependency matrix based on the API dependencies.

[0007] The monitoring steps involve monitoring all API calls and generating a call record for each call. The call record includes at least the following: the calling application, the ID of the API being called, the call time, and the call response time.

[0008] The generation step involves generating an API call heatmap based on all API call records, and marking the average call response time of each API in the API call heatmap.

[0009] The processing steps involve identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, and then processing these bottleneck APIs.

[0010] Furthermore, all APIs that can be called in the energy internet marketing service system include at least: financial payment channel APIs, non-financial payment channel APIs, government affairs channel APIs, database APIs, network service APIs, and system APIs.

[0011] Furthermore, the operation of identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap is as follows: At least one hot API is identified in the API call heatmap; among the at least one hot API, the ID of a first API whose average call response time is greater than a first threshold is identified; based on the API ID, the IDs of a second API dependent on the first API and a third API dependent on the first API are searched in the two-dimensional dependency matrix; it is then determined whether the second API is a hot API in the API call heatmap. If so, the number of times the second API is called is determined based on the API call heatmap; the average call response time of the third API is determined based on the ID of the third API; if the number of times the second API is called is greater than or equal to a second threshold, then the second API is a bottleneck API; if the average call response time of the third API is greater than or equal to a third threshold, then the third API is a bottleneck API; if the number of times the second API is called is less than the second threshold and the average call response time of the third API is less than the third threshold, then the first API is a bottleneck API.

[0012] Furthermore, the API calls the heatmap to highlight bottlenecks and issue alarm messages.

[0013] Furthermore, the alarm information includes at least: alarm sound, alarm indicator light, alarm SMS, alarm WeChat, and alarm email.

[0014] Furthermore, the operation of processing the bottleneck API includes:

[0015] If the first API is a bottleneck API, determine whether the throughput of the first API is greater than the fourth threshold. If so, construct a first call queue to buffer the services that call the first API. If not, determine whether the error rate of the first API is greater than the fifth threshold. If so, suspend the use of the first API and switch to the backup API of the first API.

[0016] If the second API is a bottleneck API, then determine whether the number of times the second API is called is greater than the maximum number of concurrent calls allowed for the second API. If yes, when the I / O utilization of the current system is less than the sixth threshold, increase the maximum number of concurrent calls allowed for the second API. If no, then build a second call queue to buffer the services that call the second API, and put the ID of the first API at the front of the second call queue.

[0017] If the third API is a bottleneck API, determine whether the third API depends on the second API based on the two-dimensional dependency matrix. If it does, prioritize the second API in processing calls to the third API. If not, restart the service that provides the third API.

[0018] This invention also proposes a monitoring device for APIs in an energy internet marketing service system, the device comprising:

[0019] The acquisition unit acquires all callable APIs in the energy internet marketing service system and constructs a two-dimensional dependency matrix based on the API dependencies.

[0020] The monitoring unit monitors all API calls and generates a call record for each call. The call record includes at least: the calling application, the ID of the API being called, the call time, and the call response time.

[0021] The generation unit generates an API call heatmap based on the call records of all APIs, and identifies the average call response time of each API in the API call heatmap;

[0022] The processing unit identifies bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, and processes the bottleneck APIs.

[0023] Furthermore, all APIs that can be called in the energy internet marketing service system include at least: financial payment channel APIs, non-financial payment channel APIs, government affairs channel APIs, database APIs, network service APIs, and system APIs.

[0024] Furthermore, the operation of identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap is as follows: At least one hot API is identified in the API call heatmap; among the at least one hot API, the ID of a first API whose average call response time is greater than a first threshold is identified; based on the API ID, the IDs of a second API dependent on the first API and a third API dependent on the first API are searched in the two-dimensional dependency matrix; it is then determined whether the second API is a hot API in the API call heatmap. If so, the number of times the second API is called is determined based on the API call heatmap; the average call response time of the third API is determined based on the ID of the third API; if the number of times the second API is called is greater than or equal to a second threshold, then the second API is a bottleneck API; if the average call response time of the third API is greater than or equal to a third threshold, then the third API is a bottleneck API; if the number of times the second API is called is less than the second threshold and the average call response time of the third API is less than the third threshold, then the first API is a bottleneck API.

[0025] Furthermore, the API calls the heatmap to highlight bottlenecks and issue alarm messages.

[0026] Furthermore, the alarm information includes at least: alarm sound, alarm indicator light, alarm SMS, alarm WeChat, and alarm email.

[0027] Furthermore, the operation of processing the bottleneck API includes:

[0028] If the first API is a bottleneck API, determine whether the throughput of the first API is greater than the fourth threshold. If so, construct a first call queue to buffer the services that call the first API. If not, determine whether the error rate of the first API is greater than the fifth threshold. If so, suspend the use of the first API and switch to the backup API of the first API.

[0029] If the second API is a bottleneck API, then determine whether the number of times the second API is called is greater than the maximum number of concurrent calls allowed for the second API. If yes, when the I / O utilization of the current system is less than the sixth threshold, increase the maximum number of concurrent calls allowed for the second API. If no, then build a second call queue to buffer the services that call the second API, and put the ID of the first API at the front of the second call queue.

[0030] If the third API is a bottleneck API, determine whether the third API depends on the second API based on the two-dimensional dependency matrix. If it does, prioritize the second API in processing calls to the third API. If not, restart the service that provides the third API.

[0031] The present invention also proposes a computer-readable storage medium storing computer program code, which, when executed by a computer, performs any of the methods described above.

[0032] The technical advantages of this invention are as follows: The present invention provides a method, apparatus, and storage medium for monitoring APIs in an energy internet marketing service system. The method includes: an acquisition step S101, acquiring all callable APIs in the energy internet marketing service system and constructing a two-dimensional dependency matrix based on API dependencies; a monitoring step S102, monitoring all API calls and generating a call record for each call, the call record including at least: the calling application, the ID of the called API, the call time, and the call response time; a generation step S103, generating an API call heatmap based on all API call records and marking the average call response time of each API in the API call heatmap; and a processing step S104, identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, and processing these bottleneck APIs.The key inventive concept of this invention is to solve the problem of identifying bottleneck APIs in the system, as described in the prior art. First, all callable APIs in the energy internet marketing service system are obtained, and a two-dimensional dependency matrix is ​​constructed based on the API dependencies. Then, calls to all APIs are monitored, generating a call record for each call and creating an API call heatmap. The average response time of each API call is displayed in the API call heatmap. Based on the two-dimensional dependency matrix and the API call heatmap, bottleneck APIs affecting the performance of the energy internet marketing service system are identified, and these bottleneck APIs are then addressed. In other words, this invention identifies bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, overcoming the shortcomings of existing technologies that require large computational resources and have low accuracy when identifying bottleneck APIs using dependency trees, artificial intelligence, etc. Because this invention first constructs the two-dimensional dependency matrix of APIs and then constructs the API call heatmap, the hot APIs can be identified based on the heatmap. The bottleneck API is then determined based on a two-dimensional dependency matrix. This method has lower computational complexity, provides more accurate bottleneck API identification, and expands the application of heatmaps. This invention proposes different methods for identifying bottleneck APIs based on their dependent and dependent API characteristics. This allows for quick and accurate identification of bottleneck APIs, providing a basis for improving system performance. Furthermore, this invention proposes different handling methods for different bottleneck APIs. When the API itself is the bottleneck, calls are buffered or switched to a backup API based on throughput and error rate. If the second API is the bottleneck, its concurrency is increased as much as possible, if the system allows, to speed up processing. When the third API is the bottleneck, it is necessary to determine whether the third API depends on the second API. If it does, it indicates that the dependency relationship between the first, second, and third APIs forms a closed loop. In this case, only by prioritizing the second API in processing calls to the third API can the bottleneck problem be resolved as quickly as possible. Additionally, the service providing the third API is restarted. This invention proposes different handling methods for different bottleneck APIs, thereby restoring system performance as quickly as possible. Attached Figure Description

[0033] Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings.

[0034] Figure 1 This is a flowchart of an API monitoring method in an energy internet marketing service system according to an embodiment of the present invention.

[0035] Figure 2This is a structural diagram of an API monitoring device in an energy internet marketing service system according to an embodiment of the present invention. Detailed Implementation

[0036] The present application will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, only the parts relevant to the invention are shown in the accompanying drawings.

[0037] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0038] Figure 1 This invention illustrates a method for monitoring APIs in an energy internet marketing service system, the method comprising:

[0039] In step S101, obtain all callable APIs in the Energy Internet Marketing Service System and construct a two-dimensional dependency matrix based on the API dependencies.

[0040] In monitoring step S102, all API calls are monitored, and a call record is generated for each call. The call record includes at least: the calling application, the ID of the API being called, the call time, and the call response time.

[0041] In step S103, an API call heatmap is generated based on the call records of all APIs, and the average call response time of each API is marked in the API call heatmap.

[0042] In processing step S104, the bottleneck APIs affecting the performance of the energy internet marketing service system are identified based on the two-dimensional dependency matrix and the API call heatmap, and the bottleneck APIs are processed.

[0043] The key inventive concept of this invention is to solve the problem of identifying bottleneck APIs in the system described in the background art. First, all callable APIs in the energy internet marketing service system are obtained, and a two-dimensional dependency matrix is ​​constructed based on the API dependencies. Then, all API calls are monitored, and a call record is generated for each call, along with an API call heatmap. The average response time of each API call is marked on the API call heatmap. Based on the two-dimensional dependency matrix and the API call heatmap, bottleneck APIs affecting the performance of the energy internet marketing service system are identified, and these bottleneck APIs are then processed. In other words, this invention identifies bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, overcoming the shortcomings of existing technologies that require large computational resources and have low accuracy when identifying bottleneck APIs using dependency trees, artificial intelligence, etc. Because this invention first constructs the two-dimensional dependency matrix of APIs and then the API call heatmap, the hot APIs can be identified based on the heatmap, and then the bottleneck APIs are determined based on the two-dimensional dependency matrix. This method has lower computational requirements, identifies more accurate bottleneck APIs, and expands the application of heatmaps. This is one of the key inventive points of this invention.

[0044] In one embodiment, all APIs that can be invoked in the energy internet marketing service system include at least: financial payment channel APIs, non-financial payment channel APIs, government affairs channel APIs, database APIs, network service APIs, and system APIs.

[0045] For example, financial payment channel APIs include APIs for online banking payments and bill inquiries from various banks; non-financial payment channel APIs include APIs for WeChat Pay and Alipay; government channel APIs mainly include APIs for applying for electricity, changing electricity service, and warranty; database APIs mainly include APIs related to database operations, such as searching, inserting, and deleting; network service APIs are mainly network-related APIs; and system APIs are system-level APIs.

[0046] In one embodiment, the operation of identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap is as follows: At least one hot API is identified in the API call heatmap; among the at least one hot API, the ID of a first API whose average call response time is greater than a first threshold is identified; based on the API ID, the IDs of a second API dependent on the first API and a third API dependent on the first API are searched in the two-dimensional dependency matrix; it is then determined whether the second API is a hot API in the API call heatmap. If so, the number of times the second API is called is determined based on the API call heatmap; the average call response time of the third API is determined based on the ID of the third API; if the number of times the second API is called is greater than or equal to a second threshold, then the second API is a bottleneck API; if the average call response time of the third API is greater than or equal to a third threshold, then the third API is a bottleneck API; if the number of times the second API is called is less than the second threshold and the average call response time of the third API is less than the third threshold, then the first API is a bottleneck API.

[0047] In this invention, to accurately identify the bottleneck API, firstly, hot APIs are identified in the API call heatmap. Among these hot APIs, the ID of the first API whose average call response time is greater than a first threshold is searched. Then, based on this ID, the IDs of the second APIs that depend on the first API and the IDs of the third APIs that the first API depends on are searched in the two-dimensional dependency matrix. It is then determined whether the second API is a hot API in the API call heatmap. If so, the number of times the second API is called is determined based on the API call heatmap. If the number of times the second API is called is greater than or equal to a second threshold, then the second API is the bottleneck API. The basis for this operation is that if the number of calls to the first API is too high, it may be because another API depends on the first API. Therefore, based on the dependency graph, the second API that calls the first API is identified, and it is further determined whether the second API is a hot API. Furthermore, if its number of calls is greater than the second threshold, then the second API is the cause of the high number of calls to the first API. In other words, the reason for the frequent calls to the first API is actually the second API, i.e., the second API is the bottleneck API. This is another aspect of the inventive concept of this invention.

[0048] Then, based on the ID of the third API, the average response time of the third API call is determined. If the average response time of the third API call is greater than or equal to a third threshold, then the third API is a bottleneck API. If the number of times the second API is called is less than a second threshold and the average response time of the third API call is less than a third threshold, then the first API is a bottleneck API. The first API depends on the third API. If the response time of the third API is slow, that is, the performance of the third API is low, then the third API is a bottleneck API. That is, whether it is a bottleneck API can be determined by the response time of the third API. If neither the second nor the third API is the API causing the bottleneck, then the first API itself is the bottleneck API. That is, this invention proposes different ways to determine the bottleneck API for dependent and dependent APIs. It is determined according to the characteristics of dependent and dependent APIs, so that the bottleneck API can be quickly and accurately determined, providing a basis for improving system performance. This is another important inventive concept of this invention.

[0049] It should be noted that the first, second, and third APIs refer to APIs of the corresponding types. There can be multiple APIs. For example, there can be multiple second APIs that depend on the first API. Similarly, there can be multiple third APIs. Moreover, for those skilled in the art, the dependency relationship changes for different monitoring APIs.

[0050] In one embodiment, the API calls the heatmap bottleneck highlighting API and issues an alarm message. In one embodiment, the alarm message includes at least: an alarm sound, an alarm indicator light, an alarm SMS, an alarm WeChat, and an alarm email. Alarms can be issued in a tiered manner; for example, emergency alarms will issue an alarm sound and an alarm indicator light, general alarms will be notified via alarm SMS and alarm WeChat, and low-level alarms will be notified via email. And so on.

[0051] In one embodiment, the operation of processing the bottleneck API includes: if the first API is a bottleneck API, then determining whether the throughput of the first API is greater than a fourth threshold; if so, then constructing a first call queue to buffer the services that call the first API; if not, then determining whether the error rate of the first API is greater than a fifth threshold; if so, suspending the use of the first API and switching to a backup API of the first API.

[0052] If the second API is a bottleneck API, then determine whether the number of times the second API is called is greater than the maximum number of concurrent calls allowed for the second API. If yes, when the I / O utilization of the current system is less than the sixth threshold, increase the maximum number of concurrent calls allowed for the second API. If no, then build a second call queue to buffer the services that call the second API, and put the ID of the first API at the front of the second call queue.

[0053] If the third API is a bottleneck API, determine whether the third API depends on the second API based on the two-dimensional dependency matrix. If it does, prioritize the second API in processing calls to the third API. If not, restart the service that provides the third API.

[0054] This invention also proposes different handling methods for different bottleneck APIs. Specifically, when the API itself is the bottleneck, calls are buffered or switched to a backup API based on throughput and error rate. If the second API is the bottleneck, its concurrency should be increased as much as possible, if the system allows, to speed up processing. When the third API is the bottleneck, it is necessary to determine whether the third API depends on the second API. If it does, it indicates that the dependency relationship between the first, second, and third APIs forms a closed loop. In this case, only by prioritizing the second API in processing calls to the third API can the bottleneck problem be resolved as quickly as possible. In addition, the service providing the third API should be restarted. This invention proposes different handling methods for different bottleneck APIs, thereby restoring system performance as quickly as possible, which is one of the important inventions of this invention.

[0055] Figure 2 This invention illustrates an API monitoring device in an energy internet marketing service system, the device comprising:

[0056] Unit 201 retrieves all callable APIs in the Energy Internet Marketing Service System and constructs a two-dimensional dependency matrix based on the API dependencies.

[0057] The monitoring unit 202 monitors all API calls and generates a call record for each call. The call record includes at least: the calling application, the ID of the API being called, the call time, and the call response time.

[0058] The generation unit 203 generates an API call heatmap based on the call records of all APIs, and marks the average call response time of each API in the API call heatmap;

[0059] Processing unit 204 determines the bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, and processes the bottleneck APIs.

[0060] The key inventive concept of this invention is to solve the problem of identifying bottleneck APIs in the system described in the background art. First, all callable APIs in the energy internet marketing service system are obtained, and a two-dimensional dependency matrix is ​​constructed based on the API dependencies. Then, all API calls are monitored, and a call record is generated for each call, along with an API call heatmap. The average response time of each API call is marked on the API call heatmap. Based on the two-dimensional dependency matrix and the API call heatmap, bottleneck APIs affecting the performance of the energy internet marketing service system are identified, and these bottleneck APIs are then processed. In other words, this invention identifies bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, overcoming the shortcomings of existing technologies that require large computational resources and have low accuracy when identifying bottleneck APIs using dependency trees, artificial intelligence, etc. Because this invention first constructs the two-dimensional dependency matrix of APIs and then the API call heatmap, the hot APIs can be identified based on the heatmap, and then the bottleneck APIs are determined based on the two-dimensional dependency matrix. This method has lower computational requirements, identifies more accurate bottleneck APIs, and expands the application of heatmaps. This is one of the key inventive points of this invention.

[0061] In one embodiment, all APIs that can be invoked in the energy internet marketing service system include at least: financial payment channel APIs, non-financial payment channel APIs, government affairs channel APIs, database APIs, network service APIs, and system APIs.

[0062] For example, financial payment channel APIs include APIs for online banking payments and bill inquiries from various banks; non-financial payment channel APIs include APIs for WeChat Pay and Alipay; government channel APIs mainly include APIs for applying for electricity, changing electricity service, and warranty; database APIs mainly include APIs related to database operations, such as searching, inserting, and deleting; network service APIs are mainly network-related APIs; and system APIs are system-level APIs.

[0063] In one embodiment, the operation of identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap is as follows: At least one hot API is identified in the API call heatmap; among the at least one hot API, the ID of a first API whose average call response time is greater than a first threshold is identified; based on the API ID, the IDs of a second API dependent on the first API and a third API dependent on the first API are searched in the two-dimensional dependency matrix; it is then determined whether the second API is a hot API in the API call heatmap. If so, the number of times the second API is called is determined based on the API call heatmap; the average call response time of the third API is determined based on the ID of the third API; if the number of times the second API is called is greater than or equal to a second threshold, then the second API is a bottleneck API; if the average call response time of the third API is greater than or equal to a third threshold, then the third API is a bottleneck API; if the number of times the second API is called is less than the second threshold and the average call response time of the third API is less than the third threshold, then the first API is a bottleneck API.

[0064] In this invention, to accurately identify the bottleneck API, firstly, hot APIs are identified in the API call heatmap. Among these hot APIs, the ID of the first API whose average call response time is greater than a first threshold is searched. Then, based on this ID, the IDs of the second APIs that depend on the first API and the IDs of the third APIs that the first API depends on are searched in the two-dimensional dependency matrix. It is then determined whether the second API is a hot API in the API call heatmap. If so, the number of times the second API is called is determined based on the API call heatmap. If the number of times the second API is called is greater than or equal to a second threshold, then the second API is the bottleneck API. The basis for this operation is that if the number of calls to the first API is too high, it may be because another API depends on the first API. Therefore, based on the dependency graph, the second API that calls the first API is identified, and it is further determined whether the second API is a hot API. Furthermore, if its number of calls is greater than the second threshold, then the second API is the cause of the high number of calls to the first API. In other words, the reason for the frequent calls to the first API is actually the second API, i.e., the second API is the bottleneck API. This is another aspect of the inventive concept of this invention.

[0065] Then, based on the ID of the third API, the average response time of the third API call is determined. If the average response time of the third API call is greater than or equal to a third threshold, then the third API is a bottleneck API. If the number of times the second API is called is less than a second threshold and the average response time of the third API call is less than a third threshold, then the first API is a bottleneck API. The first API depends on the third API. If the response time of the third API is slow, that is, the performance of the third API is low, then the third API is a bottleneck API. That is, whether it is a bottleneck API can be determined by the response time of the third API. If neither the second nor the third API is the API causing the bottleneck, then the first API itself is the bottleneck API. That is, this invention proposes different ways to determine the bottleneck API for dependent and dependent APIs. It is determined according to the characteristics of dependent and dependent APIs, so that the bottleneck API can be quickly and accurately determined, providing a basis for improving system performance. This is another important inventive concept of this invention.

[0066] It should be noted that the first, second, and third APIs refer to APIs of the corresponding types. There can be multiple APIs. For example, there can be multiple second APIs that depend on the first API. Similarly, there can be multiple third APIs. Moreover, for those skilled in the art, the dependency relationship changes for different monitoring APIs.

[0067] In one embodiment, the API calls the heatmap bottleneck highlighting API and issues an alarm message. In one embodiment, the alarm message includes at least: an alarm sound, an alarm indicator light, an alarm SMS, an alarm WeChat, and an alarm email. Alarms can be issued in a tiered manner; for example, emergency alarms will issue an alarm sound and an alarm indicator light, general alarms will be notified via alarm SMS and alarm WeChat, and low-level alarms will be notified via email. And so on.

[0068] In one embodiment, the operation of processing the bottleneck API includes: if the first API is a bottleneck API, then determining whether the throughput of the first API is greater than a fourth threshold; if so, then constructing a first call queue to buffer the services that call the first API; if not, then determining whether the error rate of the first API is greater than a fifth threshold; if so, suspending the use of the first API and switching to a backup API of the first API.

[0069] If the second API is a bottleneck API, then determine whether the number of times the second API is called is greater than the maximum number of concurrent calls allowed for the second API. If yes, when the I / O utilization of the current system is less than the sixth threshold, increase the maximum number of concurrent calls allowed for the second API. If no, then build a second call queue to buffer the services that call the second API, and put the ID of the first API at the front of the second call queue.

[0070] If the third API is a bottleneck API, determine whether the third API depends on the second API based on the two-dimensional dependency matrix. If it does, prioritize the second API in processing calls to the third API. If not, restart the service that provides the third API.

[0071] This invention also proposes different handling methods for different bottleneck APIs. Specifically, when the API itself is the bottleneck, calls are buffered or switched to a backup API based on throughput and error rate. If the second API is the bottleneck, its concurrency should be increased as much as possible, if the system allows, to speed up processing. When the third API is the bottleneck, it is necessary to determine whether the third API depends on the second API. If it does, it indicates that the dependency relationship between the first, second, and third APIs forms a closed loop. In this case, only by prioritizing the second API in processing calls to the third API can the bottleneck problem be resolved as quickly as possible. In addition, the service providing the third API should be restarted. This invention proposes different handling methods for different bottleneck APIs, thereby restoring system performance as quickly as possible, which is one of the important inventions of this invention.

[0072] One embodiment of the present invention provides a computer storage medium storing a computer program. When the computer program on the computer storage medium is executed by a processor, the above-described method is implemented. The computer storage medium may be a hard disk, DVD, CD, flash memory, or other storage device.

[0073] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0074] As can be seen from the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the apparatus described in various embodiments or some parts of the embodiments of this application.

[0075] Finally, it should be noted that the above embodiments are for illustration only and not for limiting the technical solutions of the present invention. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the present invention without departing from the spirit and scope of the present invention. Any modifications or partial substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A method for monitoring API in an energy internet marketing service system, characterized in that, The method includes: The acquisition steps involve obtaining all callable APIs in the energy internet marketing service system and constructing a two-dimensional dependency matrix based on the API dependencies. The monitoring steps involve monitoring all API calls and generating a call record for each call. The call record includes at least the following: the calling application, the ID of the API being called, the call time, and the call response time. The generation step involves generating an API call heatmap based on all API call records, and marking the average call response time of each API in the API call heatmap. The processing steps involve identifying the bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, and then processing the bottleneck APIs. The operation of identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap involves different methods for identifying bottleneck APIs for dependent and dependent APIs: At least one hot API is identified in the API call heatmap; among the at least one hot API, the ID of the first API whose average call response time is greater than a first threshold is identified; based on the API ID, the ID of the second API that depends on the first API and the ID of the third API that the first API depends on are searched in the two-dimensional dependency matrix; it is determined whether the second API is a hot API in the API call heatmap; if so, the number of times the second API is called is determined based on the API call heatmap; the average call response time of the third API is determined based on the ID of the third API; if the number of times the second API is called is greater than or equal to a second threshold, then the second API is a bottleneck API; if the average call response time of the third API is greater than or equal to a third threshold, then the third API is a bottleneck API; if the number of times the second API is called is less than the second threshold and the average call response time of the third API is less than the third threshold, then the first API is a bottleneck API. The operations for processing the bottleneck API include: If the first API is a bottleneck API, determine whether the throughput of the first API is greater than the fourth threshold. If so, construct a first call queue to buffer the services that call the first API. If not, determine whether the error rate of the first API is greater than the fifth threshold. If so, suspend the use of the first API and switch to the backup API of the first API. If the second API is a bottleneck API, then determine whether the number of times the second API is called is greater than the maximum number of concurrent calls allowed for the second API. If yes, when the I / O utilization of the current system is less than the sixth threshold, increase the maximum number of concurrent calls allowed for the second API. If no, then build a second call queue to buffer the services that call the second API, and put the ID of the first API at the front of the second call queue. If the third API is a bottleneck API, determine whether the third API depends on the second API based on the two-dimensional dependency matrix. If it does, prioritize the second API in processing calls to the third API. If not, restart the service that provides the third API.

2. The method according to claim 1, characterized in that, The energy internet marketing service system includes at least the following APIs that can be called: financial payment channel API, non-financial payment channel API, government affairs channel API, database API, network service API, and system API.

3. The method of claim 2, wherein, The API calls the heatmap to highlight bottlenecks and issues an alarm message.

4. The method of claim 3, wherein, The alarm information includes at least: alarm sound, alarm indicator light, alarm SMS, alarm WeChat and alarm email.

5. An API monitoring device in an energy internet marketing service system, characterized by, The device includes: The acquisition unit acquires all callable APIs in the energy internet marketing service system and constructs a two-dimensional dependency matrix based on the API dependencies. The monitoring unit monitors all API calls and generates a call record for each call. The call record includes at least: the calling application, the ID of the API being called, the call time, and the call response time. The generation unit generates an API call heatmap based on the call records of all APIs, and identifies the average call response time of each API in the API call heatmap; The processing unit identifies the bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap, and processes the bottleneck APIs. The operation of identifying bottleneck APIs affecting the performance of the energy internet marketing service system based on the two-dimensional dependency matrix and the API call heatmap involves different methods for identifying bottleneck APIs for dependent and dependent APIs: At least one hot API is identified in the API call heatmap; among the at least one hot API, the ID of the first API whose average call response time is greater than a first threshold is identified; based on the API ID, the ID of the second API that depends on the first API and the ID of the third API that the first API depends on are searched in the two-dimensional dependency matrix; it is determined whether the second API is a hot API in the API call heatmap; if so, the number of times the second API is called is determined based on the API call heatmap; the average call response time of the third API is determined based on the ID of the third API; if the number of times the second API is called is greater than or equal to a second threshold, then the second API is a bottleneck API; if the average call response time of the third API is greater than or equal to a third threshold, then the third API is a bottleneck API; if the number of times the second API is called is less than the second threshold and the average call response time of the third API is less than the third threshold, then the first API is a bottleneck API. The operations for processing the bottleneck API include: If the first API is a bottleneck API, determine whether the throughput of the first API is greater than the fourth threshold. If so, construct a first call queue to buffer the services that call the first API. If not, determine whether the error rate of the first API is greater than the fifth threshold. If so, suspend the use of the first API and switch to the backup API of the first API. If the second API is a bottleneck API, then determine whether the number of times the second API is called is greater than the maximum number of concurrent calls allowed for the second API. If yes, when the I / O utilization of the current system is less than the sixth threshold, increase the maximum number of concurrent calls allowed for the second API. If no, then build a second call queue to buffer the services that call the second API, and put the ID of the first API at the front of the second call queue. If the third API is a bottleneck API, determine whether the third API depends on the second API based on the two-dimensional dependency matrix. If it does, prioritize the second API in processing calls to the third API. If not, restart the service that provides the third API.

6. The apparatus of claim 5, wherein, The energy internet marketing service system includes at least the following APIs that can be called: financial payment channel API, non-financial payment channel API, government affairs channel API, database API, network service API, and system API.

7. The apparatus of claim 6, wherein, The API calls the heatmap to highlight bottlenecks and issues an alarm message.

8. A computer storage medium, characterized in that, The computer storage medium stores a computer program, which, when executed by a processor, implements the method described in any one of claims 1-4.

Images