API request processing method, system and device and storage medium
By aggregating multiple monolithic applications into microservice applications and judging and managing cached data for API requests in the cache management center, the problem of excessive server processing burden under massive users' concurrent access is solved, and the server delay and improvement is achieved. The effect of user experience.
Patent Information
- Application Number
- CN202411326900.5
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-09-23
- Publication Date
- 2025-02-14
AI Technical Summary
When the existing technology handles massive user concurrent access, the server needs to process a large number of duplicate API requests, resulting in increased system response delays and exhaustion of resources. The existing cache strategy is not effective in the face of the diversity and dynamics of requests. It can easily cause cache overflow.
By aggregating multiple monolithic applications into microservice applications, the cache management center is used to determine whether the target data requested by the API has been cached. If it has been cached, it will be sent directly to the microservice application. If it is not cached, it will be sent to the server and cache the response data. Manage cached data based on preset thresholds and cleaning rules.
Reduce dependence and latency on servers, improve user experience, and reduce operating costs through effective cache management.
Smart Images
Figure CN119441327A_ABST
Abstract
Description
Technical Field
[0001] The present application relates to the field of data processing technology, and in particular to a method, system, device and storage medium for processing API requests. Background Art
[0002] With the rapid development of the Internet, facing massive concurrent access from users, servers need to process a large number of repeated API requests, which not only increases the processing burden of the server, but may also lead to increased system response delays and even crashes due to resource exhaustion.
[0003] Existing technologies reduce the processing burden of servers by implementing server-side caching strategies. However, when faced with frequent and repeated requests from clients, the effectiveness of this strategy is often limited by the cache hit rate and the effectiveness of the caching strategy. In particular, when the caching strategy fails to fully consider the diversity and dynamic nature of requests, the utilization and effectiveness of the cache will be greatly reduced.
[0004] Moreover, although a few technologies have attempted to perform refined cache management of API requests and their return values to reduce the burden on the server, when the cached data is not cleaned up in a timely and effective manner, although the response speed of data access can be significantly improved in the short term, it may also gradually approach the capacity limit due to the accumulation of cached data, thereby causing the risk of cache overflow and continuing to send requests to the server.
[0005] In summary, developing a cache management solution that can operate efficiently is of great significance for improving system performance and reducing operating costs. Summary of the Invention
[0006] In order to solve the above technical problems, the present application provides a method, system, device and storage medium for processing API requests, which can reduce dependence on servers and reduce server delays, thereby improving user experience.
[0007] The technical solution provided in this application is described below:
[0008] In a first aspect, the present application provides a method for processing an API request, which is applied to a cache management center and includes:
[0009] Aggregate multiple monolithic applications to form microservice applications;
[0010] Obtaining API requests initiated by a microservice application, wherein the microservice application is formed by aggregating multiple monolithic applications;
[0011] Determine whether the target data requested by the API request has been cached;
[0012] If it has been cached, sending the target data to the microservice application;
[0013] If not cached, the API request is sent to the server;
[0014] The target data returned by the server in response to the API request is cached.
[0015] Optionally, the caching the target data returned by the server in response to the API request includes:
[0016] Receiving the target data returned by the server in response to the API request;
[0017] Determine whether the current cache capacity has reached a preset threshold;
[0018] If the preset threshold is not reached, the target data is cached.
[0019] Optionally, the processing method further includes:
[0020] If the preset threshold is reached, the cached data is cleaned up according to the preset cleaning rules;
[0021] When the cache capacity after data cleaning does not reach the preset threshold, the target data is cached.
[0022] Optionally, the cleaning of cached data according to a preset cleaning rule includes:
[0023] Determine first data that has not been called for the longest time among the cached data, and clear the first data.
[0024] Optionally, the cleaning of cached data according to a preset cleaning rule includes:
[0025] Determine second data in the cached data that meets the requirement of having a call count lower than a preset number of times and a non-call time length greater than a preset time length, and clear the second data.
[0026] Optionally, after caching the target data, the method further includes:
[0027] Setting a timeout period for the target data;
[0028] When it is detected that the cache time of the target data reaches the timeout time, the target data is cleared.
[0029] Optionally, after caching the target data returned by the server in response to the API request, the method further includes:
[0030] If the API request is received again, the target data is sent to the microservice application.
[0031] A second aspect of the present application provides an API request processing system, including:
[0032] An acquisition unit, configured to acquire an API request initiated by a microservice application, wherein the microservice application is formed by aggregating multiple monolithic applications;
[0033] a determination unit, configured to determine whether the target data requested by the API request has been cached;
[0034] A first sending unit, configured to send the target data to the microservice application if the target data has been cached;
[0035] A second sending unit, configured to send the API request to the server if it is not cached;
[0036] A cache unit is used to cache the target data returned by the server in response to the API request.
[0037] Optionally, the cache unit includes:
[0038] A receiving module, configured to receive the target data returned by the server in response to the API request;
[0039] A judgment module is used to judge whether the current cache capacity has reached a preset threshold;
[0040] The first cache module is configured to cache the target data if the preset threshold is not reached.
[0041] Optionally, the cache unit further includes:
[0042] A first cleaning module, configured to clean up cached data according to a preset cleaning rule if the preset threshold is reached;
[0043] The second cache module is configured to cache the target data when the cache capacity after data cleaning does not reach the preset threshold.
[0044] Optionally, the first cleaning module includes:
[0045] The first cleaning submodule is configured to determine first data that has not been called for the longest time in the cached data, and clean up the first data.
[0046] Optionally, the first cleaning module includes:
[0047] The second cleaning submodule is configured to determine second data in the cached data that has a call count lower than a preset number of times and a non-call time length greater than a preset time length, and clean the second data.
[0048] Optionally, the cache unit further includes:
[0049] A setting module, used for setting a timeout period for the target data;
[0050] The second cleaning module is configured to clean up the target data when it is detected that the cache time of the target data reaches the timeout time.
[0051] Optionally, the API request processing system also includes:
[0052] The third sending unit is configured to send the target data to the microservice application if the API request is received again.
[0053] A third aspect of the present application provides a cross-application API data management device, including:
[0054] processor, memory, input and output units, and buses;
[0055] The processor is connected to the memory, the input and output unit, and the bus;
[0056] The memory stores a program, and the processor calls the program to execute the above-mentioned first aspect and any optional API request processing method in the first aspect.
[0057] In a fourth aspect, the present application provides a computer-readable storage medium having a program stored thereon. When the program is executed on a computer, the program executes the method for processing the API request according to the first aspect and any optional item in the first aspect.
[0058] It can be seen from the above technical solutions that this application has the following advantages:
[0059] This application is applied to the cache management center, which obtains the API request initiated by the microservice application and determines whether the target data requested by the API request has been cached. If it has been cached in the cache management center, the target data is sent to the microservice application. If it has not been cached, the API request is sent to the server, and the cache server responds to the target data returned by the API request. Therefore, when obtaining the target data, if the target data has been cached, it can be obtained directly in the cache management center, reducing the number of visits to the server. The cache management center can reduce dependence on the server and reduce server latency, thereby improving user experience. BRIEF DESCRIPTION OF THE DRAWINGS
[0060] In order to more clearly illustrate the technical solutions in this application, the following briefly introduces the drawings required for use in the description of the embodiments. Obviously, the drawings described below are only some embodiments of this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.
[0061] Figure 1 A schematic diagram of an embodiment of a method for processing an API request provided by this application;
[0062] Figure 2 A schematic diagram of another embodiment of a method for processing an API request provided by this application;
[0063] Figure 3 A schematic diagram of an embodiment of a system for processing API requests provided by this application;
[0064] Figure 4 A schematic diagram of another embodiment of a system for processing API requests provided by this application;
[0065] Figure 5 A schematic diagram of an API request processing device provided in this application. DETAILED DESCRIPTION
[0066] It should be noted that the cross-application API request processing method provided in this application is applied to the cache management center, which can reduce dependence on the server and reduce server latency, thereby improving user experience.
[0067] See also Figure 1 , the present application first provides an embodiment of a method for processing an API request, the embodiment comprising:
[0068] 101. The cache management center obtains the API request initiated by the microservice application. The microservice application is formed by aggregating multiple monolithic applications.
[0069] In this embodiment, the microservice application is aggregated by multiple existing monolithic applications. Specifically, multiple monolithic applications are aggregated according to the microservice architecture principle. The multiple monolithic applications that need to be aggregated are analyzed to identify which functions can be independently transformed into services. Then, a microservice is defined for each independent function or business domain. An independent code base, database, and deployment environment are used for each microservice to ensure that each microservice can be run and tested independently.
[0070] In order to improve data access efficiency and reduce database load, a cache management center is configured on the front end to complete data mobilization on the front end and reduce the number of visits to the back-end server. The cache management center is responsible for storing and managing data copies from various microservices. When microservice applications need to call data, they can obtain it directly from the cache management center. The cache used in the cache management center can be an in-memory data structure or a simple local storage (such as the browser's LocalStorage or SessionStorage, etc.), depending on the needs and scale. By designing a cache management center, data requests can be responded to quickly, reducing the number of visits to the original data source, thereby improving overall performance. To maintain data consistency, when the data in the server is updated, the data in the cache management center needs to be updated accordingly.
[0071] The user initiates an API request on the microservice application, and the microservice application accesses the cache management center through the API request to query the target data corresponding to the API request.
[0072] 102. The cache management center determines whether the target data requested by the API request has been cached.
[0073] The cache management center first determines the requested target data based on the API request, and then queries the cache to see if the target data exists. If so, it means it has been cached; if not, it means it has not been cached.
[0074] During the specific judgment process, a global cache object can be created to store the response data (target data) of the API request. This object can use the request URL or a specific identifier as the key and the response data as the value. If the key exists in the cache management center, it means that the target data has been cached in the cache management center.
[0075] If the judgment result is that the cache management center has cached the target data, step 103 is executed; if the judgment result is that the cache management center has not cached the target data, steps 104 and 105 are executed.
[0076] 103. The cache management center sends the target data to the microservice application.
[0077] When the target data is found in the cache management center, the cache management center directly sends the target data to the microservice application. While ensuring the timely response of the microservice application, there is no need to access the server, which reduces dependence on the server and improves performance and response speed.
[0078] 104. The cache management center sends the API request to the server.
[0079] When the target data does not exist in the cache management center, the cache management center sends the API request of the microservice application to the server, so that the server queries the required target data according to the API request, and specifically retrieves the required target data from the database or other data source. At this time, the server directly sends the target data to the microservice application.
[0080] 105. The cache management center cache server responds to the target data returned by the API request.
[0081] When the server sends the target data to the microservice application through the cache management center, the target data will first arrive at the cache management center, and then be sent to the microservice application through the cache management center;
[0082] When the target data arrives at the cache management center, the cache management center caches the target data so that when the same API request is received later, the target data can be directly obtained from the cache management center, thereby reducing the number of visits to the server.
[0083] At the end of this embodiment, because the cache management center has cached the target data, if it receives this API request again, the cache management center directly sends the target data to the microservice application to reduce the number of calls to the server and improve data response time.
[0084] In this embodiment, the cache management center obtains API requests initiated by microservice applications, which are formed by the aggregation of multiple monolithic applications. The cache management center then determines whether the target data requested by the API request has been cached. If it has been cached, the cache management center sends the target data to the microservice application. If the target data has not been cached, the cache management center sends the API request to the server and caches the target data returned by the server in response to the API request. This reduces dependence on the server, reduces the number of server accesses, and reduces server latency, thereby improving user experience. In addition, when there are too many repeated API requests from the same source in multiple monolithic applications, access efficiency is further improved by directly accessing the data in the cache management center.
[0085] For the target data returned from the server, the server not only returns the target data to the target single application, but also returns the target data to the cache management center to ensure that it is directly called from the cache management center next time, further improving efficiency. After receiving the target data returned by the server, the cache management center performs the following steps:
[0086] See also Figure 2 , the present application first provides another embodiment of a method for processing an API request, the embodiment comprising:
[0087] 201. The cache management center receives the target data returned by the server in response to the API request.
[0088] When the cache management center does not contain the target data, an API request is sent to the server. The server queries the target data according to the API request and returns the target data to the target single application through the cache management center. At this time, the cache management center caches the target data so that the target data can be obtained directly from the cache management center when the API request is received again in the future.
[0089] 202. The cache management center determines whether the current cache capacity reaches a preset threshold.
[0090] Insufficient space means the target data cannot be stored. Therefore, before attempting to store new data in the cache, the cache management center determines whether the current cache capacity has reached the preset threshold and checks whether there is sufficient remaining space. The preset threshold is a value set based on demand to prevent the cache from being completely filled, thereby avoiding performance degradation or data loss.
[0091] For example, if the preset threshold is 10% of the total cache capacity, the remaining space in the cache management center is checked, and if the remaining space is greater than 10% of the total capacity, it is considered that there is enough space to store new data.
[0092] In this step, if it is determined that the cache capacity has not reached the threshold / the remaining space is sufficient, steps 203-205 are executed; if it is determined that the remaining space is insufficient, steps 206-207 are executed.
[0093] 203. The cache management center caches the target data.
[0094] If the cache capacity of the cache management center does not reach the threshold or there is enough free space, the cache management center will store the target data in the cache. When storing the target data, it will associate the target data with a key for quick retrieval later.
[0095] 204. The cache management center sets a timeout period for the target data.
[0096] 205. When it is detected that the cache time of the target data reaches the timeout time, the cache management center clears the target data.
[0097] To ensure data timeliness and accuracy and prevent data obsolescence, the cache management center sets a timeout period for target data when storing it. Data exceeding this timeout period will be considered obsolete and removed from the cache. The timeout period can be 1 hour, 1 day, 10 days, etc. The specific time limit is not limited and is subject to actual achievable conditions.
[0098] After storing the target data in the cache management center, the cache management center monitors the storage time corresponding to each cached data and compares the monitored storage time with the timeout time corresponding to the data. Once the storage time of a certain data exceeds its set timeout time, the cache management center will remove the data from the cache.
[0099] For example, for data A, B, and C, when they are stored in the cache management center, the time limit for A data is set to 3 days, the time limit for B data is set to 10 days, and the time limit for C data is set to 12 hours. Then, the storage time of these three data is monitored in real time. When it is detected that the storage time of A data exceeds 3 days, A data will be removed from the cache management center.
[0100] Steps 203-205 provide a method for the cache management center to clean up the storage space. The storage space may also be cleaned up in other ways.
[0101] 206. The cache management center cleans up the cached data according to preset cleaning rules.
[0102] In addition to automatic cleanup based on time limits, more complex memory cleanup operations can be performed based on preset rules. Preset rules include cleanup strategies based on data access frequency, data unused time, and least recently used (LRU) algorithms.
[0103] Among them, in the cleaning strategy based on data access frequency, the cache management center monitors the number of times each data has been accessed since it was stored, and determines the data with the least number of accesses to clean up.
[0104] Secondly, in the cleaning strategy based on non-call time, the cache management center records the time when each cached data was most recently called, compares the time when each data was most recently called to determine the data that has not been called for the longest time (first data), and removes the first data that has not been called for the longest time in the cache. Specifically: first, the data is tracked. The cache management center tracks the last access time of each data item. This can be achieved by attaching a timestamp to the data item, which is updated each time the data is accessed; then a scheduled check or event-triggered check is performed. A timer can be set to perform checks regularly, or a check can be triggered based on a specific event (such as the cache space is close to full load). The purpose of the check is to find data items that have not been accessed for a long time; finally, the data that has not been called for the longest time is determined and removed. The cache management center will traverse all cached data items and compare the last access timestamps of these data. Through this process, the data item that has not been called for the longest time, namely the "first data", can be determined. After determination, the first data cache management center will be removed to ensure that there is sufficient storage space in the cache management center.
[0105] In addition, the second data can be cleaned by determining the second data in the cached data that meets the requirements of the call count less than the preset count and the non-call time longer than the preset time. Specifically, the cache management center records the call count of each cached data and the time that each data is not called. Combining the preset count and the preset time, the cache management center searches for the second data that meets the requirements of the call count less than the preset count and the call time longer than the preset time. The call count and the call time are combined to search for the second data for cleaning. The preset time and the preset count are set according to actual needs, and the count is not specifically limited.
[0106] This application also provides another cleaning method, which is to clean up the memory by combining the number of data accesses and the data access time. Specifically:
[0107] First, each data item in the cache management center is assigned a label. The label consists of the number of times it has been called and the time since the last call. In the cache management center, each cached data item is assigned a label. The assigned label is a composite structure, usually consisting of two parts: the number of times it has been called (count) and the time since the last call (lastAccessedTime). The purpose of the label is to enable rapid evaluation of the usage and activity level of each data item.
[0108] Secondly, obtain the call status of each data in the cache management center and update the label according to the call status. It is necessary to obtain the call status of each data in the cache management center in real time or periodically. Whenever a data item is accessed, the label of the data item will be updated, that is, the count will increase by 1, and the lastAccessedTime will be updated to the current timestamp.
[0109] Then, the probability of each data being called again is determined based on the label. Based on the label of each data item, the probability of each data item being called again can be calculated. The probability of being called again can be a composite evaluation based on multiple factors, which can usually be simplified to a function based on count and lastAccessedTime. For example, a simple method is to give count a higher weight, because data with more calls is more likely to be called again. At the same time, considering lastAccessedTime, data that was accessed more recently is more likely to be active. For example, a simple weighted formula can be used to calculate the probability, such as probability = (count*recentnessFactor) / totalCalls, where recentnessFactor is a decay factor based on lastAccessedTime (the closer the time value, the higher the value), and totalCalls is the total number of calls for all cached data items.
[0110] Finally, the third data item with the lowest probability of being called again in the cache management center is removed. After calculating the probability of each data item being called again, these probabilities are used to determine which data items are the "least active," meaning they have the lowest probability of being called again. The data item with the lowest probability is set as the third data item and removed from the cache management center to free up cache space. It should be noted that if there are multiple identical third data items with the lowest probability, they will all be removed. A probability threshold can also be set, and when the probability of a data item being called falls below the threshold, the data item will be removed.
[0111] 207. When the cache capacity after data cleaning does not reach a preset threshold, the cache management center caches the target data.
[0112] After performing a memory cleanup, the Cache Management Center will check the cached capacity / remaining space again. If the cached capacity does not reach the preset threshold, it means that there is enough remaining space, and the Cache Management Center will continue to cache new target data.
[0113] See also Figure 3 The present application first provides an embodiment of a system for processing an API request, the embodiment comprising:
[0114] The acquisition unit 301 is used to acquire an API request initiated by a microservice application, where the microservice application is formed by aggregating multiple monolithic applications;
[0115] The determining unit 302 is configured to determine whether the target data requested by the API request has been cached;
[0116] The first sending unit 303 is configured to send the target data to the microservice application if the target data has been cached;
[0117] The second sending unit 304 is configured to send the API request to the server if it is not cached;
[0118] The cache unit 305 is used to cache the target data returned by the server in response to the API request.
[0119] In this embodiment, the cache management center first obtains the API request initiated by the microservice application through the acquisition unit 301. The microservice application is formed by the aggregation of multiple monomer applications. Then, the judgment unit 302 is used to judge whether the target data requested by the API request has been cached in the cache pipeline center. When the judgment result is that the cache already exists, the target data is sent to the microservice application through the first sending unit 303. When the judgment result is that it has not been cached, the API request is sent to the server through the second sending unit 304. Finally, the target data returned by the server in response to the API request is cached through the cache unit 305. In this way, the target data is sent directly from the cache management center to the microservice application, which can reduce the participation of the server and the number of visits to the server. The cache management center can reduce dependence on the server and reduce server delays, thereby improving user experience.
[0120] See also Figure 4 The present application first provides another embodiment of a system for processing an API request, the embodiment comprising:
[0121] The acquisition unit 401 is used to acquire an API request initiated by a microservice application, where the microservice application is formed by aggregating multiple monolithic applications;
[0122] The determination unit 402 is used to determine whether the target data requested by the API request has been cached;
[0123] The first sending unit 403 is configured to send the target data to the microservice application if the target data has been cached;
[0124] The second sending unit 404 is configured to send the API request to the server if it is not cached;
[0125] Cache unit 405, used to cache target data returned by the server in response to the API request;
[0126] The cache unit 405 includes:
[0127] Receiving module 4051, used to receive target data returned by the server in response to the API request;
[0128] The judgment module 4052 is used to judge whether the current cache capacity has reached a preset threshold;
[0129] A first cache module 4053 is configured to cache target data if the preset threshold is not reached;
[0130] A first cleaning module 4054 is configured to clean up cached data according to a preset cleaning rule if a preset threshold is reached;
[0131] The first cleaning module 4054 includes:
[0132] A first cleaning submodule 40541 is configured to determine first data that has not been called for the longest time among the cached data, and clean up the first data;
[0133] The second cleaning submodule 40542 is configured to determine, in the cached data, second data that has a call count less than a preset number of times and a non-call time greater than a preset time, and clean the second data;
[0134] The second cache module 4055 is configured to cache target data when the cache capacity after data cleaning does not reach a preset threshold;
[0135] Setting module 4056, used to set a timeout period for target data;
[0136] The second cleaning module 4057 is used to clean up the target data when it is detected that the cache time of the target data reaches the timeout period;
[0137] The third sending unit 406 is configured to send the target data to the microservice application if the API request is received again.
[0138] See also Figure 5 , the present application also provides an API request processing device, including:
[0139] Processor 501, memory 502, input and output unit 503, bus 504;
[0140] The processor 501 is connected to the memory 502, the input and output unit 503 and the bus 504;
[0141] The memory 502 stores a program, and the processor 501 calls the program to execute the following Figure 1-Figure 2 Any method in the embodiments.
[0142] The present application also relates to a computer-readable storage medium having a program stored thereon, wherein when the program is run on a computer, the computer is caused to execute the following Figure 1-Figure 2 Any method in the embodiments.
[0143] Those skilled in the art will clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.
[0144] In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are merely schematic. For example, the division of the units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.
[0145] The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.
[0146] In addition, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units.
[0147] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk, and other media that can store program code.
Claims
1. A method for processing an API request, characterized in that: Applied to a cache management center, the processing method includes: Obtaining an API request initiated by a microservice application, wherein the microservice application is formed by aggregating multiple monomer applications; Determine whether the target data requested by the API request has been cached; If it has been cached, sending the target data to the microservice application; If not cached, sending the API request to the server; The target data returned by the server in response to the API request is cached.
2. The processing method according to claim 1, characterized in that: The caching the target data returned by the server in response to the API request includes: Receiving the target data returned by the server in response to the API request; Determine whether the current cache capacity has reached a preset threshold; If the preset threshold is not reached, the target data is cached.
3. The processing method according to claim 2, characterized in that: The processing method also includes: If the preset threshold is reached, the cached data is cleaned up according to the preset cleaning rules; When the cached capacity after data cleaning does not reach the preset threshold, the target data is cached.
4. The processing method according to claim 3, characterized in that: The cleaning of cached data according to preset cleaning rules includes: Determine first data that has not been called for the longest time among the cached data, and clear the first data.
5. The processing method according to claim 3, characterized in that: The cleaning of cached data according to preset cleaning rules includes: Determine second data in the cached data that has a call count lower than a preset number of times and a non-call time length greater than a preset time length, and clear the second data.
6. The processing method according to claim 2 or 3, characterized in that: After caching the target data, the method further includes: Setting a timeout period for the target data; When it is detected that the cache time of the target data reaches the timeout time, the target data is cleared.
7. The processing method according to claim 1, characterized in that: After caching the target data returned by the server in response to the API request, the method further includes: If the API request is received again, the target data is sent to the microservice application.
8. A system for processing API requests, characterized in that: include: An acquisition unit, used to acquire an API request initiated by a microservice application, wherein the microservice application is formed by aggregating multiple monomer applications; A determination unit, used to determine whether the target data requested by the API request has been cached; A first sending unit, configured to send the target data to the microservice application if the target data has been cached; A second sending unit, configured to send the API request to the server if it is not cached; A cache unit is used to cache the target data returned by the server in response to the API request.
9. A device for processing an API request, characterized in that: include: Processor, memory, input-output unit, and bus; The processor is connected to the memory, the input and output unit, and the bus; The memory stores a program, and the processor calls the program to execute the processing method according to any one of claims 1 to 7.
10. A computer-readable storage medium having a program stored thereon, wherein the program, when executed on a computer, performs the processing method according to any one of claims 1 to 7.