API (Application Program Interface) request implementation method and device, electronic equipment and storage medium

Abstract

The invention provides an API request implementation method and device, electronic equipment and a storage medium, and the method comprises the steps: after receiving an API request sent by a client, determining a first API path of which the access frequency is higher than a set frequency by analyzing the API request frequency in a log record; determining a first routing table corresponding to the first API path; the first routing table is loaded into an internal memory from persistent storage, the API request is forwarded to a list of service instances through the first routing table in the internal memory, and the persistent storage is provided with a full quantity of routing tables. According to the invention, the processing speed of the common API path can be accelerated.

Description

Technical Field

[0001] The present application relates to the field of API gateway technology, and in particular to a method, device, electronic device and storage medium for implementing an API request. Background Art

[0002] Traditional API gateways usually use static routing tables. When processing routing tables, they usually do not have the ability to dynamically adapt. When the API path is accessed frequently, it means that there are more API requests pointing to the same resource, which will cause the corresponding routing table to be used frequently. Because each request needs to go through the routing table to determine which specific backend service the request should be sent to. If the access frequency is extremely high and the routing table does not have the ability to dynamically adapt, it may cause performance problems, such as increased processing time and slower response speed. Summary of the invention

[0003] In order to solve the above technical problems or at least partially solve the above technical problems, the present application provides a method, device, electronic device and storage medium for implementing an API request.

[0004] In a first aspect, the present application provides a method for implementing an API request, the method comprising:

[0005] After receiving the API request sent by the client, determine the first API path whose access frequency is higher than the set frequency by analyzing the API request frequency in the log record;

[0006] Determine a first routing table corresponding to the first API path;

[0007] The first routing table is loaded from the persistent storage into the memory, and the API request is forwarded to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full set of routing tables.

[0008] Optionally, after analyzing the API request frequency in the log record, the method further includes:

[0009] extracting from the memory a second API path with an access frequency lower than a preset frequency;

[0010] Determine a second routing table corresponding to the second API path;

[0011] The second routing table is unloaded from the memory using a cache elimination algorithm.

[0012] Optionally, the method further comprises:

[0013] Record relevant request information based on multiple API requests, where the request information includes request path, request time, processing time, cache hit rate, and request status;

[0014] generating request frequency distribution data by analyzing the request information;

[0015] The loading and unloading strategies of the routing table are dynamically adjusted according to the request frequency distribution data.

[0016] Optionally, after loading the first routing table from persistent storage into memory, the method further includes:

[0017] Determine the target routing table to be used according to the HTTP request sent by the client;

[0018] searching the target routing table in the memory;

[0019] If the target routing table is not found in the memory, loading the target routing table from the persistent storage into the memory;

[0020] The target service is responded to through the target routing table in the memory.

[0021] Optionally, after searching the target routing table from the memory, the method further includes:

[0022] If the target routing table is found in the memory, the target service is responded to through the target routing table in the memory.

[0023] In a second aspect, the present application provides a device for implementing an API request, the device comprising:

[0024] An analysis module is used to determine a first API path whose access frequency is higher than a set frequency by analyzing the API request frequency in the log record after receiving the API request sent by the client;

[0025] A first determining module, used to determine a first routing table corresponding to the first API path;

[0026] The first loading module is used to load the first routing table from the persistent storage into the memory, and forward the API request to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full set of routing tables.

[0027] Optionally, the device further comprises:

[0028] An extraction module, used for extracting a second API path having an access frequency lower than a preset frequency from the memory;

[0029] A second determining module, used to determine a second routing table corresponding to the second API path;

[0030] An unloading module is used to unload the second routing table from the memory by using a cache elimination algorithm.

[0031] Optionally, the device is also used for:

[0032] Record relevant request information based on multiple API requests, where the request information includes request path, request time, processing time, cache hit rate, and request status;

[0033] generating request frequency distribution data by analyzing the request information;

[0034] The loading and unloading strategies of the routing table are dynamically adjusted according to the request frequency distribution data.

[0035] Optionally, the device further comprises:

[0036] A third determination module is used to determine a target routing table to be used according to an HTTP request sent by a client;

[0037] A search module, used for searching the target routing table in the memory;

[0038] A second loading module, configured to load the target routing table from the persistent storage into the memory if the target routing table is not found in the memory;

[0039] The response module is used to respond to the target service through the target routing table in the memory.

[0040] Optionally, the device is also used for:

[0041] If the target routing table is found in the memory, the target service is responded to through the target routing table in the memory.

[0042] In a third aspect, an electronic device is provided, comprising a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other via the communication bus;

[0043] Memory, used to store computer programs;

[0044] The processor is used to implement any of the aforementioned methods and steps for implementing the API request when executing the program stored in the memory, including the following contents:

[0045] After receiving the API request sent by the client, determine the first API path whose access frequency is higher than the set frequency by analyzing the API request frequency in the log record;

[0046] Determine a first routing table corresponding to the first API path;

[0047] The first routing table is loaded from the persistent storage into the memory, and the API request is forwarded to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full set of routing tables.

[0048] In a fourth aspect, a computer-readable storage medium is provided, wherein a computer program is stored in the computer-readable storage medium, and when the computer program is executed by a processor, the steps of implementing any of the aforementioned API request methods are implemented.

[0049] The above technical solution provided by the embodiment of the present application has the following advantages compared with the prior art:

[0050] The method provided in the embodiment of the present application determines the frequently accessed API path and the routing table corresponding to the API path by analyzing the API request frequency in the log, and the frequently accessed routing table can be stored through a cache mechanism, so that each time an API request arrives, the routing table can be quickly found from the memory, thereby reducing the routing search time and speeding up the processing speed of commonly used API paths. BRIEF DESCRIPTION OF THE DRAWINGS

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

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

[0053] Figure 1 A schematic diagram of a hardware environment for implementing an API request provided in an embodiment of the present application;

[0054] Figure 2 A flowchart of a method for implementing an API request provided in an embodiment of the present application;

[0055] Figure 3 A flowchart of unloading a routing table from a memory is provided for an embodiment of the present application;

[0056] Figure 4 A signaling diagram of a method for implementing an API request provided in an embodiment of the present application;

[0057] Figure 5An overall flow chart of a method for implementing an API request provided in an embodiment of the present application;

[0058] Figure 6 A schematic diagram of the structure of an implementation device for an API request provided in an embodiment of the present application;

[0059] Figure 7 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0061] In the subsequent description, the suffixes such as "module", "component" or "unit" used to represent elements are only used to facilitate the description of the present application and have no specific meaning. Therefore, "module" and "component" can be used interchangeably.

[0062] In order to solve the problems mentioned in the background technology, according to one aspect of an embodiment of the present application, an embodiment of a method for implementing an API request is provided.

[0063] Optionally, in the embodiment of the present application, the implementation method of the above API request can be applied to Figure 1 In the hardware environment composed of the terminal 101 and the server 103 shown in FIG. Figure 1 As shown, the server 103 is connected to the terminal 101 via a network, and can be used to provide services for the terminal or a client installed on the terminal. A database 105 can be set on the server or independently of the server to provide data storage services for the server 103. The above-mentioned network includes but is not limited to: a wide area network, a metropolitan area network or a local area network, and the terminal 101 includes but is not limited to a PC, a mobile phone, a tablet computer, etc.

[0064] A method for implementing an API request in an embodiment of the present application can be executed by server 103 to speed up the processing speed of commonly used API paths.

[0065] The following will describe in detail a method for implementing an API request provided in an embodiment of the present application in conjunction with a specific implementation method. Figure 2 As shown, the specific steps are as follows:

[0066] Step 201: after receiving an API request sent by a client, determine a first API path whose access frequency is higher than a set frequency by analyzing the API request frequency in the log record.

[0067] Step 202: Determine a first routing table corresponding to the first API path.

[0068] Step 203: Load the first routing table from the persistent storage into the memory, and forward the API request to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full set of routing tables.

[0069] In the client-server architecture, an API request refers to a client requesting data or performing an operation from a server by sending HTTP messages, and these requests are usually handled by an API gateway. One of the core functions of an API gateway is to process API paths and routing tables to ensure that requests are correctly forwarded to the target server or service instance.

[0070] The API path refers to the address of the target resource or endpoint of an API request, such as a specific page or functional module in a Web service. Each API path usually corresponds to a specific backend service or operation, and the routing table is a key data structure used to define which API paths should be forwarded to which specific server or service instance. In traditional implementations, whenever the API gateway receives an API request, it needs to traverse the entire routing table to determine the correct backend service. This process may involve complex search and matching algorithms, resulting in increased processing time and slower response speeds.

[0071] In order to solve the problem of slow system response time, the API gateway in this application adopts a strategy of dynamically loading the routing table. This strategy automatically identifies frequently accessed API paths based on the analysis of the frequency of API requests in the log records, and loads the routing table items corresponding to these high-frequency paths into the memory in advance. In this way, when the corresponding API request arrives, the API gateway can quickly find the corresponding backend service information from the memory without traversing the entire routing table each time.

[0072] This application provides a dynamic adaptive preheating mechanism, which can significantly improve the performance of API gateways in high-concurrency scenarios, speed up the processing of commonly used API paths by reducing route lookup time, and thus improve the overall user experience of clients. In addition, this dynamic adaptive method can also adjust the preheating strategy according to actual traffic and usage patterns to ensure optimal use of gateway resources.

[0073] The memory in the embodiment of the present application can use Redis or memory data structures (such as red-black trees, hash tables) to implement high-speed caching, which is used to quickly find high-frequency access routing table items and improve request processing efficiency. Persistent storage can use a database such as MySQL, PostgreSQL, or use a file storage system to persistently store all routing information, ensure the persistence and consistency of the system, and have the ability to recover routing information.

[0074] In this application, by analyzing the API request frequency in the log, the frequently accessed API path and the routing table corresponding to the API path are determined, and the frequently accessed routing table can be stored through a cache mechanism, so that each time an API request arrives, the routing table can be quickly found from the memory, reducing the routing search time and speeding up the processing speed of commonly used API paths.

[0075] This application improves the processing efficiency of the API gateway, shortens the system response time, and improves the user experience through efficient large-scale API management. In addition, it optimizes system performance so that the same hardware resources can support a larger scale of concurrent requests and reduce the need for hardware expansion.

[0076] As an optional implementation, after analyzing the API request frequency in the log record, the method further includes the following steps: Figure 3 shown.

[0077] Step 301: extracting from the memory a second API path whose access frequency is lower than a preset frequency.

[0078] Step 302: Determine a second routing table corresponding to the second API path.

[0079] Step 303: Use a cache elimination algorithm to unload the second routing table from the memory.

[0080] In order to optimize the utilization of memory resources and improve system efficiency, a dynamic unloading mechanism can be used to manage infrequently used routing table entries. This mechanism can achieve its purpose by implementing the LRU (Least Recently Used) algorithm, the LFU (Least Frequently Used) algorithm or a custom strategy.

[0081] The LRU algorithm is a time-based cache elimination algorithm that tracks the usage of each routing table item. When the memory resource reaches a certain threshold, the least recently used routing table item will be unloaded from the memory. The basis for this is that if a routing table item has not been frequently used in the past period of time, it is less likely to be used in the future. In this way, the LRU algorithm can ensure that the most recently used routing table items are retained in the memory, thereby improving memory utilization and system response speed.

[0082] Unlike LRU, the LFU algorithm decides which routing table entries should be unloaded based on the frequency of use. It maintains a counter for each routing table entry to record the number of times the entry has been accessed. When it is necessary to unload routing table entries to free up memory, LFU will prioritize those entries with the least number of accesses. This strategy believes that in the long run, routing table entries with low access frequencies are not important to the system, so they can be removed first.

[0083] In addition to these two classic algorithms, you can also design custom offloading strategies based on actual business needs and scenarios. For example, you can combine the importance of routing table items, the changing trend of network traffic, and even the time period to develop more refined and personalized offloading logic.

[0084] The routing table entries after uninstallation are not simply discarded, but need to be persistently stored, which means that they will be saved to disk or other types of persistent storage devices so that they can be quickly restored when needed in the future. This persistence operation not only ensures the integrity of the data, but also enables the cache content to be dynamically updated, thereby improving the cache hit rate.

[0085] In general, by implementing a dynamic unloading mechanism and using LRU, LFU algorithms or custom strategies during the unloading process, the routing table entries in the memory can be effectively managed, which can not only release valuable memory resources, but also reduce memory overhead and improve the system's response speed and resource utilization.

[0086] As an optional implementation, the method also includes the following contents: recording relevant request information based on multiple API requests, wherein the request information includes request path, request time, processing time, cache hit rate and request status; generating request frequency distribution data by analyzing the request information; dynamically adjusting the loading and unloading strategies of the routing table according to the request frequency distribution data.

[0087] Information about each API request is recorded, including but not limited to the request path, request time, processing time, cache hit rate, and request status. These data provide a basis for in-depth analysis. The processing time refers to the specific processing time of the HTTP request through each stage of the device, which can be used to analyze which stage takes longer; the request status refers to the status code indicating whether the request is successful or failed.

[0088] By analyzing a large amount of API request information, we can generate request frequency distribution data. This distribution data reveals the access frequency of different API paths within a specific time period, thereby identifying which paths are "hot paths" that users frequently visit. The system can then dynamically adjust the loading and unloading strategies of the routing table based on the request frequency distribution data.

[0089] Dynamic adjustment means ensuring that the routing table of hot paths can always be loaded first in the cache, which means that the system will allocate more cache resources to these hot paths according to the request frequency to ensure that when users initiate requests, they can be responded to as quickly as possible. At the same time, for those "cold paths" with low access frequency, the system may adopt different cache strategies, and even actively unload these routing table items from the cache in some cases to make room for more frequently accessed resources.

[0090] In addition to dynamically adjusting the cache strategy, you can also combine the log monitoring module to analyze the request situation in real time. The log monitoring module can provide instant data analysis to help administrators understand the performance of the current system, including key performance indicators such as cache hit rate and request processing time. Through real-time analysis, the system can quickly respond to various changes and further adjust the routing table in the cache to adapt to the ever-changing request pattern.

[0091] This dynamic adjustment mechanism not only reduces the fluctuation of response time, but also improves the overall user experience. Through dynamic adjustment, the routing table of the hot path is always loaded first in the cache. Users will feel a significant speed improvement when accessing popular APIs, and the system resources are used more effectively. In addition, by reducing the cache of unpopular routing tables, the system can save storage space and reduce memory overhead, thereby improving the cost-effectiveness of the entire network service.

[0092] In summary, by recording and analyzing API request information, we can generate request frequency distribution data, dynamically adjust the loading and unloading strategies of the routing table based on this data, adjust the routing table in the cache, reduce system response fluctuations, and improve user experience.

[0093] In addition, the dynamic adaptive preheating mechanism enables the API gateway to automatically adjust the routing table management under high concurrency conditions, realize load balancing and optimization based on monitoring data, and improve the system's scalability. Log monitoring and dynamic adjustment are combined to realize automated routing table management, use the monitoring module to record and analyze request data, dynamically update and optimize the routing table, reduce manual operations, improve the system's self-management capabilities, reduce maintenance costs, and avoid human errors.

[0094] As an optional implementation, after loading the first routing table from persistent storage into memory, the method also includes: determining a target routing table to be used based on an HTTP request sent by a client; searching for the target routing table in memory; if the target routing table is not found in memory, loading the target routing table from persistent storage into memory; responding to the target service through the target routing table in memory; if the target routing table is found in memory, responding to the target service through the target routing table in memory.

[0095] The HTTP request sent by the client contains the target resource requested and the type of service required. After receiving the request, the server will determine the target routing table to be used based on the specific information of the request. The server will search in the memory to see if there is a ready-made target routing table available. The memory is used as the preferred location for storing commonly used routing tables due to its fast access speed to speed up the response. If the server successfully finds the target routing table in the memory, the server will directly use this routing table to respond to the client's request and provide the required service.

[0096] If the server does not find the target routing table in memory, it means that the routing table may not be frequently used or has been unloaded before to save memory resources. In this case, the server will load the required target routing table from persistent storage into memory. Persistent storage is a stable storage medium, such as a hard disk, which ensures that the routing table information will not be lost even if the server is restarted or fails. The loading process involves reading the data, rebuilding the structure of the routing table, and loading it into memory for use. Once the loading is complete, the server can respond and provide services through the newly loaded target routing table in memory.

[0097] Whether it is found directly in memory or loaded from persistent storage, the server can efficiently process client requests and provide stable and timely responses for both frequently accessed resources and occasionally required routing information. This dynamic resource management strategy not only improves system performance, but also enhances user experience, making the entire service process smoother and more efficient.

[0098] Based on the same technical concept, an embodiment of the present application also provides an API request implementation system, including the following modules.

[0099] 1. Request receiving and parsing module.

[0100] The main function of this module is to receive HTTP requests from users, analyze them in depth, and extract key request features, such as request path and request header information. This information not only helps with subsequent request processing, but also serves as the basis for performance optimization and security protection. After the analysis is completed, the request information is passed to the routing decision module.

[0101] 2. Routing decision module.

[0102] This module is a key component that determines the flow of requests. It searches for the corresponding routing table entry in the cache based on the parsed request path. If the corresponding routing information is found in the cache, it directly uses this routing information to forward the request; if not found, it triggers the routing loading and unloading module to dynamically load the required routing table from the persistent storage into the cache to ensure that the request can be processed correctly and promptly.

[0103] 3. Routing loading and unloading modules.

[0104] This module implements strategies based on LRU, LFU or custom algorithms, and dynamically determines which routing tables need to be loaded or unloaded. This module is responsible for maintaining data consistency between memory and persistent storage, ensuring that frequently accessed routing information can be quickly loaded into the cache, and that infrequently used routing tables are unloaded in a timely manner to release memory resources, while ensuring that the unloaded routing information can be saved in persistent storage.

[0105] 4. Cache module.

[0106] This module is a powerful tool for improving system performance. By using Redis or memory data structures (such as red-black tables and hash tables), the cache module provides extremely fast search and access capabilities for frequently accessed routing table items, significantly improving the efficiency and speed of request processing.

[0107] 5. Routing table storage module.

[0108] This module is responsible for persistently storing all routing information, ensuring the persistence and consistency of the system. Whether it is a database such as MySQL, PostgreSQL, or a file storage system, it can ensure the security and reliability of data.

[0109] 6.Log monitoring module.

[0110] This module records and analyzes system operation in real time, including but not limited to key performance indicators such as request processing time and cache hit rate. By monitoring and analyzing these data, it can automatically adjust the routing loading and unloading strategies in a timely manner to achieve adaptive optimization and ensure that the system always runs in the best state.

[0111] Based on the same technical concept, the embodiment of the present application also provides a signaling diagram for implementing an API request, such as Figure 4 As shown, including the following:

[0112] The user sends an HTTP request through the client. The request receiving and parsing module parses the HTTP request, extracts the API request path and the corresponding routing table, and sends the parsed information to the routing decision module. The routing decision module searches for the required routing table in the cache module. If the cache hits the routing table, the HTTP request is directly forwarded to the target service. If the cache does not hit the routing table, the routing table is searched in the persistent storage and loaded into the cache. After the cache is updated, the routing table can be hit, and the HTTP request can be forwarded to the target service. In addition, the system can also trigger an unloading strategy to unload infrequently used routing tables from the cache through the LRU algorithm or the LFU algorithm, and check whether there is already a copy of the routing table in the persistent storage to ensure data integrity and consistency.

[0113] The contents of the above signaling diagram are explained in detail below.

[0114] When a user initiates an HTTP request through a client (such as a browser, mobile application, etc.), the request is first captured by the system's request receiving and parsing module, which is responsible for in-depth parsing of the HTTP request, including but not limited to parsing the request method (such as GET, POST), request headers (Headers), request body (Body) and API request path. By accurately parsing the API request path, the system can identify the specific resources or services that the user intends to access.

[0115] After the parsing is completed, the routing decision module will first quickly search the cache module to see whether there is a routing table entry that matches the current request path. Due to its high-speed access characteristics, the cache module can significantly improve the efficiency of routing lookup and reduce request response time. Among them, the routing table is a mapping table maintained internally by the system, which defines the mapping relationship from a specific API path to the backend service address.

[0116] If the cache hits, that is, a matching routing table entry is found, the routing decision module will directly forward the HTTP request to the corresponding target service based on the information in the routing table. This process does not require further access to the potentially slower persistent storage, thereby achieving fast processing of the request.

[0117] However, if the cache misses, that is, the current request path does not find the corresponding routing table entry in the cache, the routing decision module will turn to the persistent storage (such as a database, file system, or distributed storage system, etc.) to initiate a query. As the ultimate source of data, the persistent storage stores all the routing table information in the system. Once a matching routing table is found in the persistent storage, the routing table entry will be loaded into the cache so that subsequent requests can be accessed directly through the cache, reducing dependence on persistent storage and access latency.

[0118] In addition, in order to maintain the effectiveness and performance of the cache, the system will trigger the unloading strategy periodically or according to specific conditions. This strategy uses algorithms such as Least Recently Used (LRU) or Least Frequently Used (LFU) to identify and remove infrequently accessed routing table items in the cache to free up cache space for more active data. During the unloading process, the system will also check whether a copy of the routing table to be unloaded has been saved in the persistent storage to ensure redundant storage of data and the fault tolerance of the system. This mechanism not only optimizes the efficiency of cache usage, but also ensures the integrity and consistency of data. Even in the case of partial cache failure, it can ensure the continuity and stability of the service.

[0119] The method flow chart of API request implementation is shown in Figure 5 The following steps are included:

[0120] 1. User sends HTTP request.

[0121] When a user clicks a link, submits a form, or triggers an API call, the client builds and sends an HTTP request to the server.

[0122] 2. Request reception and analysis.

[0123] Once an HTTP request reaches the server, it is first captured by the request receiving and parsing module, which is the entry point of the server and is responsible for receiving all incoming HTTP requests. The request receiving and parsing module parses the request and extracts key information from it, especially the API request path. The API request path is the part of the URL that identifies a specific resource or service, which is crucial for subsequent routing decisions. At the same time, the request receiving and parsing module may also parse other information such as the request header and request body for subsequent processing.

[0124] 3. Routing decision.

[0125] After parsing the HTTP request, the routing decision module finds the corresponding backend service or processing logic according to the API request path. In order to improve the search efficiency, the routing decision module will first try to find the required routing table in the cache module.

[0126] 4. Determine whether the cache hits the required routing table.

[0127] When searching the routing table in the cache module, the routing decision module checks whether there is a routing table entry that matches the current API request path. If a matching routing table entry is found (i.e., a cache hit), it means that this routing table entry has been recently accessed and its corresponding backend service information is still valid.

[0128] 5. Cache hit.

[0129] If the cache hits, the routing decision module will directly use the routing table information in the cache to forward the HTTP request to the target service. Since the cache access speed is faster than the persistent storage access speed, the response time of the request can be reduced.

[0130] 6. Cache miss.

[0131] If no matching routing table entry is found in the cache (i.e., a cache miss), the routing decision module will turn to persistent storage (such as a database, file system, or distributed storage system, etc.), which contains a complete copy of all routing tables in the system. Finding a routing table in persistent storage may be much slower than cache access, but it is key to ensuring data integrity and consistency.

[0132] Once a matching routing table is found in the persistent storage, the routing decision module will load it into the cache so that future requests can access it faster. After the cache is updated, the routing decision module will search the cache again for the required routing table. At this time, since the cache has been updated, it can hit the target, and the routing decision module will forward the HTTP request to the target service, completing the entire request processing process. This process step outlines the entire process from the user sending an HTTP request to the server processing the request, and performing routing decisions, cache management, and persistent storage through various modules.

[0133] From the perspective of the overall technical concept, the embodiment of the present application includes the following four key components: dynamic loading and unloading mechanism, log and monitoring system, cache strategy and routing table management, which together ensure that the API gateway can efficiently and flexibly handle a large number of API requests. The following is a detailed description of these aspects:

[0134] 1. Dynamic loading and unloading mechanism

[0135] 1. Record request frequency

[0136] Monitoring Module: The monitoring module in the API Gateway continuously tracks and records the frequency of each API request, which involves capturing detailed information about each request, such as the requested API path, request timestamp, and target service.

[0137] 2. Analyze request data

[0138] Data analysis: The system conducts in-depth analysis of the data collected by the monitoring module, using data mining techniques to identify frequently accessed API paths (high-frequency access) and infrequently accessed paths (low-frequency access).

[0139] 3. Dynamic loading

[0140] Memory loading: Based on the analysis results, the system dynamically loads the frequently accessed API routing table into the memory. In this way, for subsequent requests, if their routing information is already in the memory, they can be directly obtained from the memory, greatly improving the access speed.

[0141] Persistent storage loading: When the requested routing table is not in memory, the system immediately loads the required routing table from persistent storage (such as a database or file system) into memory.

[0142] 4. Dynamic Uninstallation

[0143] Cache replacement strategy: Using the LRU (least recently used) or LFU (least frequently used) algorithm, the system removes routing tables that are infrequently accessed or have not been accessed for a long time from the memory to free up space for more frequently used routing tables. The uninstalled routing tables will be persistently stored again to ensure that information is not lost.

[0144] 2. Log and Monitoring System

[0145] 1. Request Records

[0146] Log module: Each request passing through the API gateway will have key information recorded by the log module, including but not limited to the requested API path, request time, processing time, cache hit rate, request status, etc.

[0147] 2. Data Storage and Analysis

[0148] Analysis and reporting: Log data is stored regularly and analyzed in depth to generate distribution results such as request frequency and performance indicators.

[0149] 3. Strategy Adjustment

[0150] Dynamic policy adjustment: Based on the results of log analysis, the system automatically adjusts the routing loading and unloading strategies to optimize the cache hit rate and improve system response speed.

[0151] 3. Cache Strategy

[0152] 1. Cache implementation

[0153] Efficient data structure: In the API gateway's memory, use efficient data structures (such as hash tables or linked lists) to implement cache to support fast lookups and updates.

[0154] 2. Preheating mechanism

[0155] Preloading: Based on the request frequency analysis provided by the monitoring module, the system will preload the frequently accessed routing tables into the cache to shorten the API access latency.

[0156] 3. Cache Update

[0157] Dynamic update: Based on cache replacement strategies such as LRU or LFU, the cache content is dynamically updated. For missed requests, the system will load the corresponding routing table from persistent storage and update the cache.

[0158] 4. Routing Table Management

[0159] 1. Data structure selection

[0160] Efficient query and update: Select appropriate data structures (such as red-black trees, hash tables) to store and manage routing tables to ensure efficient query, update, and persistence operations.

[0161] 2. Persistent Storage

[0162] Stable data storage: All routing tables are persistently stored in stable storage media, such as databases or file systems, to ensure data persistence and system recovery capabilities.

[0163] 3. Memory loading

[0164] Demand-based loading: According to the dynamic loading mechanism, only the frequently accessed routing tables are loaded into the memory, which can reduce the memory usage while ensuring that the frequently accessed routing tables can be accessed quickly.

[0165] Optionally, the present application may also introduce advanced algorithms and machine learning techniques to further predict the usage of routing tables, and analyze request patterns and trends through machine learning to make the process of dynamically adjusting routing tables more accurate and intelligent, which not only improves the performance of the API gateway, but also enhances its ability to cope with complex scenarios.

[0166] The beneficial effects that can be achieved by this application include:

[0167] 1. Dynamically load high-frequency routing table

[0168] This application uses a cache module to dynamically load those routing tables that are frequently accessed, thereby identifying those frequently accessed API paths. In addition, once the frequently accessed API paths are identified, the system will load the routing tables corresponding to these paths into the cache in advance. This preloading mechanism significantly reduces the time for routing lookups, thereby speeding up the processing of commonly used API paths and improving the overall system responsiveness.

[0169] 2. Automatically unload low-frequency routing tables

[0170] Cache elimination algorithms, such as the Least Recently Used (LRU) or Least Frequently Used (LFU) algorithms, are used to implement dynamic unloading mechanisms for routing table entries. These algorithms help the system identify routing tables that have not been accessed for a long time or are accessed less frequently. Infrequently used routing table entries will be removed from memory and persistently stored in stable storage media. This process not only optimizes the use of memory resources, reduces the system's memory overhead, but also improves overall efficiency.

[0171] 3. Response time optimization

[0172] The system makes dynamic adjustments to ensure that the routing tables of high-frequency paths are loaded first in the cache, thereby shortening the response time of hot paths and improving the user experience when accessing these paths. Combined with the real-time data analysis of the log monitoring module, the system can dynamically adjust the routing tables in the cache according to the current request situation, which helps to reduce fluctuations in response time and further improve the user experience.

[0173] 4. Improved system scalability

[0174] The dynamic adaptive preheating mechanism enables the API gateway to automatically adjust its routing table management strategy under high concurrency conditions, which means that the system can dynamically preload or unload routing tables according to the actual load conditions, thereby improving the system's scalability and elasticity.

[0175] 5. Automated maintenance

[0176] The combination of log monitoring and dynamic adjustment realizes the automated management of routing tables. The monitoring system will continuously record and analyze request data, and based on this data, the system will automatically update and optimize the routing table. In addition, the automated process in this application reduces the reliance on manual operations, improves the self-management capabilities of the system, and thus reduces maintenance costs. At the same time, this also avoids problems that may be caused by human errors and ensures the stability and reliability of the system.

[0177] Based on the same technical concept, the embodiment of the present application also provides a device for implementing an API request, such as Figure 6 As shown, the device comprises:

[0178] The analysis module 601 is used to determine a first API path whose access frequency is higher than a set frequency by analyzing the API request frequency in the log record after receiving the API request sent by the client;

[0179] A first determining module 602, configured to determine a first routing table corresponding to a first API path;

[0180] The first loading module 603 is used to load the first routing table from the persistent storage into the memory, and forward the API request to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full routing table.

[0181] Optionally, the device further comprises:

[0182] An extraction module, used for extracting a second API path having an access frequency lower than a preset frequency from the memory;

[0183] A second determining module, used to determine a second routing table corresponding to a second API path;

[0184] The unloading module is used to unload the second routing table from the memory by using a cache elimination algorithm.

[0185] Optionally, the device is also used for:

[0186] Record relevant request information based on multiple API requests, where the request information includes request path, request time, processing time, cache hit rate, and request status;

[0187] Generate request frequency distribution data by analyzing request information;

[0188] Dynamically adjust the loading and unloading strategies of the routing table based on request frequency distribution data.

[0189] Optionally, the device further comprises:

[0190] A third determination module is used to determine a target routing table to be used according to an HTTP request sent by a client;

[0191] A search module, used to search the target routing table in memory;

[0192] The second loading module is used to load the target routing table from the persistent storage into the memory if the target routing table is not found in the memory;

[0193] The response module is used to respond to the target service through the target routing table in memory.

[0194] Optionally, the device is also used for:

[0195] If the target routing table is found in the memory, the target service is responded to through the target routing table in the memory.

[0196] Based on the same technical concept, an embodiment of the present invention further provides an electronic device, such as Figure 7 As shown, it includes a processor 701, a communication interface 702, a memory 703 and a communication bus 704, wherein the processor 701, the communication interface 702, and the memory 703 communicate with each other through the communication bus 704.

[0197] Memory 703, used for storing computer programs;

[0198] The processor 701 is used to implement the above steps when executing the program stored in the memory 703.

[0199] The communication bus mentioned in the above electronic device can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. The communication bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus.

[0200] The communication interface is used for communication between the above electronic device and other devices.

[0201] The memory may include a random access memory (RAM) or a non-volatile memory (NVM), such as at least one disk memory. Optionally, the memory may also be at least one storage device located away from the aforementioned processor.

[0202] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0203] In another embodiment of the present invention, a computer-readable storage medium is provided, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above methods are implemented, including the following contents.

[0204] After receiving the API request sent by the client, determine the first API path whose access frequency is higher than the set frequency by analyzing the API request frequency in the log record;

[0205] Determine a first routing table corresponding to the first API path;

[0206] The first routing table is loaded from the persistent storage into the memory, and the API request is forwarded to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full amount of the routing table.

[0207] Optionally, after analyzing the API request frequency in the log record, the method further includes:

[0208] extracting from the memory a second API path with an access frequency lower than a preset frequency;

[0209] Determine a second routing table corresponding to the second API path;

[0210] The second routing table is unloaded from the memory using a cache elimination algorithm.

[0211] Optionally, the method further comprises:

[0212] Record relevant request information based on multiple API requests, where the request information includes request path, request time, processing time, cache hit rate, and request status;

[0213] Generate request frequency distribution data by analyzing request information;

[0214] Dynamically adjust the loading and unloading strategies of the routing table based on request frequency distribution data.

[0215] Optionally, after loading the first routing table from the persistent storage into the memory, the method further includes:

[0216] Determine the target routing table to be used according to the HTTP request sent by the client;

[0217] Look up the destination routing table in memory;

[0218] If the target routing table is not found in the memory, the target routing table is loaded from the persistent storage into the memory;

[0219] Respond to the target service through the target routing table in memory.

[0220] Optionally, after searching the target routing table from the memory, the method further includes:

[0221] If the target routing table is found in the memory, the target service is responded to through the target routing table in the memory.

[0222] In another embodiment of the present invention, a computer program product including instructions is provided, which enables the computer to execute any one of the methods in the above embodiments when the computer program product is executed on the computer.

[0223] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function according to the embodiment of the present invention is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website site, a computer, a server or a data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) mode to another website site, computer, server or data center. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or a data center that includes one or more available media integration. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0224] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0225] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A method for implementing an API request, characterized in that: The method comprises: After receiving the API request sent by the client, determine the first API path whose access frequency is higher than the set frequency by analyzing the API request frequency in the log record; Determine a first routing table corresponding to the first API path; The first routing table is loaded from the persistent storage into the memory, and the API request is forwarded to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full set of routing tables.

2. The method according to claim 1, characterized in that After analyzing the API request frequency in the log records, the method further includes: extracting from the memory a second API path with an access frequency lower than a preset frequency; Determine a second routing table corresponding to the second API path; The second routing table is unloaded from the memory using a cache elimination algorithm.

3. The method according to claim 1 or 2, characterized in that: The method further comprises: Record relevant request information based on multiple API requests, where the request information includes request path, request time, processing time, cache hit rate, and request status; generating request frequency distribution data by analyzing the request information; The loading and unloading strategies of the routing table are dynamically adjusted according to the request frequency distribution data.

4. The method according to claim 1, characterized in that: After loading the first routing table from persistent storage into memory, the method further includes: Determine the target routing table to be used according to the HTTP request sent by the client; searching the target routing table in the memory; If the target routing table is not found in the memory, loading the target routing table from the persistent storage into the memory; The target service is responded to through the target routing table in the memory.

5. The method according to claim 4, characterized in that After searching the target routing table from the memory, the method further includes: If the target routing table is found in the memory, the target service is responded to through the target routing table in the memory.

6. A device for implementing an API request, characterized in that: The device comprises: An analysis module is used to determine a first API path whose access frequency is higher than a set frequency by analyzing the API request frequency in the log record after receiving the API request sent by the client; A first determining module, used to determine a first routing table corresponding to the first API path; The first loading module is used to load the first routing table from the persistent storage into the memory, and forward the API request to the list of service instances through the first routing table in the memory, wherein the persistent storage has a full set of routing tables.

7. The device according to claim 6, characterized in that The device also includes: An extraction module, used for extracting a second API path having an access frequency lower than a preset frequency from the memory; A second determining module, used to determine a second routing table corresponding to the second API path; An unloading module is used to unload the second routing table from the memory by using a cache elimination algorithm.

8. The device according to claim 6, characterized in that The device also includes: A third determination module is used to determine a target routing table to be used according to an HTTP request sent by a client; A search module, used for searching the target routing table in the memory; A second loading module, configured to load the target routing table from the persistent storage into the memory if the target routing table is not found in the memory; The response module is used to respond to the target service through the target routing table in the memory.

9. An electronic device, characterized in that: It includes a processor, a communication interface, a memory and a communication bus, wherein the processor, the communication interface and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, for implementing the method steps described in any one of claims 1 to 5 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method steps described in any one of claims 1 to 5 are implemented.

Images