API gateway service management method and system and medium

Abstract

The invention relates to the technical field of distributed systems, and particularly discloses an API gateway service management method and system of an HTTP protocol, and a storage medium. The method is used for solving the problem that service discovery delay is inconsistent with node states in a micro-service architecture. The method comprises the following steps: writing service information into a remote cache when an application service is started; configuring a gateway tool and appointing a request processing script path; preferentially obtaining the service list from the local shared memory through the script, and if the service list is empty, pulling the latest list from the remote cache; the HTTP request is forwarded by adopting a load balancing algorithm, the next service is automatically tried when the HTTP request fails, and a degradation response is returned if all the services fail; and executing the health examination script to traverse the service list, and synchronously rejecting the service of which the failure times exceed a threshold value from the remote cache and the shared memory.

Description

Technical Field

[0001] The present invention belongs to the field of microservice architecture technology, and in particular relates to an API gateway service management method, system and medium. Background Art

[0002] In a microservices architecture, the API gateway, as the core hub for service invocation, must dynamically manage the availability of backend services. Current mainstream solutions rely on registries (such as Consul or Eureka) to maintain a service list. Gateway nodes periodically pull the service list from the registry and cache it locally. However, this mechanism has significant drawbacks: First, frequent access to the registry can cause delays in service list updates due to network latency. Especially in large distributed systems, ensuring real-time synchronization between the local cache and the service registry is difficult. Second, when a gateway detects a faulty service through a health check, it typically only removes it from its local cache. However, other gateway nodes, unaware of this change, continue to route requests to the faulty service, resulting in repeated erroneous requests and wasted system resources. Furthermore, the failure to update the global registry promptly exacerbates inconsistent service status across nodes, significantly reducing system availability and request success rates. Therefore, a management method is urgently needed that can efficiently obtain a real-time service list while ensuring consistent service status across all nodes in a distributed environment. Summary of the Invention

[0003] The technical problem to be solved by the present invention is to provide an API gateway service management method, system and medium to address the deficiencies in the above-mentioned existing technologies, which can not only efficiently obtain a real-time service list, but also ensure the consistency of the service status of all nodes in a distributed environment.

[0004] The first aspect of the present invention discloses an API gateway service management method, comprising the following steps: After the application service is started, the service information is written to the remote cache; Configure the gateway tool and specify the script path for request processing; Get the service list from the local shared memory through the script. If the list is empty, pull the latest list from the remote cache. Uses a load balancing algorithm to select a service and forward HTTP requests. If a request fails, it tries the next service. If all else fails, it returns a degraded response. Execute the health check script, traverse the service list to detect availability, and remove the service from the remote cache and shared memory if the number of service failures exceeds the threshold.

[0005] In the above method, the load balancing algorithm includes a polling algorithm, a random selection algorithm, or an algorithm based on service weight.

[0006] In the above method, the health check step includes calling a preset interface of the service to detect the response status. If the response status is HTTP code 200, it is determined that the service is available.

[0007] The above method also includes triggering a health check step based on a scheduled task, and the interval of the scheduled task is configurable.

[0008] In the above method, the remote cache includes redis or memcached.

[0009] A second aspect of the present invention discloses an API gateway system, comprising: The service registration module is used to write the service information of the application service into the remote cache; Gateway configuration module, integrates openresty, configures location and specifies script path; The request processing module executes scripts to obtain a list of services from local shared memory, implements a load balancing algorithm to forward requests, and returns a degraded response if all services fail; The health check module executes scripts to obtain a list of services from a remote cache, detect service availability, and dynamically update the cache and shared memory.

[0010] In the above system, the health check module also includes a failure counter, which automatically removes the service if the number of service failures exceeds a configurable threshold.

[0011] The above system also includes a scheduled task module, which sets scheduled health checks based on the crontab mechanism.

[0012] In the above system, the request processing module supports multiple load balancing algorithms and implements request forwarding logic through scripts.

[0013] A third aspect of the present invention discloses a computer-readable storage medium having a computer program stored thereon, wherein the computer program implements the method described in the first aspect when the program is executed.

[0014] Compared with the prior art, the present invention has the following advantages: 1. A script prioritizes obtaining the service list from local shared memory; if the list is empty, the latest list is pulled from the remote cache. This creates a two-tiered architecture of local shared memory (for high-speed access) and remote cache (for persistent storage). This optimizes service list retrieval speed (avoiding frequent access to remote resources) while ensuring data real-time availability through remote caching. Compared to traditional service discovery mechanisms that rely solely on a registry or local cache (e.g., Eureka, which only periodically pulls data from the registry), this resolves the conflict between response latency and data consistency.

[0015] 2. When the number of service health check failures exceeds a threshold, the service is synchronously removed from the remote cache and shared memory. Traditionally, health checks typically only update the local cache or notify the central registry, leaving other gateway nodes potentially able to access the failed service. This invention ensures that all gateway nodes are aware of service status changes in real time by synchronously updating the remote cache (global state) and local shared memory (node ​​state), resolving the issue of inconsistent service status in distributed environments.

[0016] In summary, the present invention combines a two-layer service list acquisition mechanism with a distributed consistency service elimination mechanism, ensuring efficient acquisition of the service list while achieving real-time synchronization and distributed consistency of service status by collaboratively updating local shared memory and remote cache. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 This is a diagram of the operating principle of the API gateway service of the present invention.

[0018] Figure 2 This is a module diagram of the API gateway system of the present invention. DETAILED DESCRIPTION

[0019] Explanation of terms: API (Application Programming Interface): Application programming interface refers to the standardized interface for communication between services in a microservice architecture. The gateway implements unified entry routing by managing API requests of the HTTP protocol.

[0020] HTTP (Hypertext Transfer Protocol): Hypertext Transfer Protocol; the basis of network protocols used for gateway forwarding requests.

[0021] Redis: A high-performance key-value database used as a remote cache storage service list.

[0022] API Gateway.lua: API gateway script.

[0023] health_check.lua: health check script.

[0024] Open Resty Service: OpenResty service (processes client requests, manages local service cache; when there is no local service list, pulls data from Redis).

[0025] Http Client: HTTP client.

[0026] Backend Service: Backend service.

[0027] The technical solution of the present invention is further described in detail below through the accompanying drawings and embodiments.

[0028] Example 1 See Figure 1 As shown, an API gateway service management method includes the following steps: After the application service is started, the service information is written to the remote cache; Configure the gateway tool and specify the script path for request processing; Get the service list from the local shared memory through the script. If the list is empty, pull the latest list from the remote cache. Uses a load balancing algorithm to select a service and forward HTTP requests. If a request fails, it tries the next service. If all else fails, it returns a degraded response. Execute the health check script, traverse the service list to detect availability, and remove the service from the remote cache and shared memory if the number of service failures exceeds the threshold.

[0029] like Figure 1 As shown in the figure, after the application service (Backend Service) is started, its service information (including the registered IP address and port number, which come from the backend service) is written to the remote Redis cache through the service registration module, establishing a global, unified service list storage source. When a client (Http Client) initiates an HTTP request, Open Resty Service, acting as the gateway core, receives the request and triggers the execution of the APIGateway.lua script. This script preferentially reads the service list from local shared memory (such as OpenResty's lua_shared_dict). If the list is empty, it immediately pulls the latest service list from Redis and caches it in shared memory. This local caching mechanism significantly reduces remote access latency. The script dynamically selects the target service based on a preset load balancing algorithm (such as round-robin) and forwards the request to the corresponding application service (BackendService) through the internal Http Client component. If the request fails (for example, the response HTTP status code is not 200), the script automatically switches to the next available service node. When all service nodes are unavailable, a preset degradation response is returned (for example, a JSON-formatted error message "Service temporarily unavailable") to ensure the ultimate fault tolerance of the request link.

[0030] The health check process is driven by the health_check.lua script, which periodically retrieves a list of services from Redis and iterates through each service's preset health interface (PORT) and registered IP (Register IP). When a service responds with a status code of 200, the failure counter for that service is reset; if the check fails (e.g., due to a connection timeout or a non-200 response), the failure count is incremented. Once the cumulative failure count for a particular service exceeds a configurable threshold (e.g., three), the script simultaneously removes the failed service node from Redis and local shared memory, ensuring that all gateway nodes share a consistent view of the service status in real time. This bidirectional removal mechanism completely resolves the inconsistent request routing issues inherent in traditional solutions, caused by out-of-sync status between the local cache and the registry. Furthermore, Redis's persistence ensures global, real-time synchronization of fault information.

[0031] During implementation, those skilled in the art can implement it based on open source tools such as openresty (a Lua extension of nginx) and redis. First, when the application service starts, its own IP address and port information are automatically written to the redis cache. For example, when an e-commerce application starts, it calls the registration API to add "192.168.1.1:8080" to the redis list. In the gateway configuration step, add a location rule to the nginx.conf file of openresty, specifying content_by_lua_file to point to the api-gateway.lua script path, so that all requests are routed to the script for processing. Script logic: api-gateway.lua first obtains the service list from openresty's shared memory (such as using lua_shared_dict); if the list is empty (for example, when it is just started), it connects to redis to pull the latest list and stores it in shared memory to speed up subsequent access. The load balancing algorithm uses a round-robin algorithm (for example, if a list contains services A, B, and C, A is selected in turn to handle requests). If a request fails (e.g., an HTTP status code other than 200), the script automatically switches to service B or C. If all requests fail, a downgraded response is returned (e.g., a JSON message stating "No service available, please try again later"). Health checks are performed by the health_check.lua script, which periodically iterates through the service list: it retrieves the list from Redis, checks each service (e.g., by calling its / ping endpoint), and resets the failure count if the response is an HTTP 200. If the failure count exceeds three, the counter is incremented. If a payment service fails to respond to a / ping request three times in a row, the script automatically removes it from Redis and shared memory, preventing subsequent requests from being routed to it. This entire process requires no manual intervention and is easy to deploy on Linux servers.

[0032] The above method can shorten the request link (reduce the middle layer compared to the traditional nginx reverse proxy), improve the overall stability (as long as the cluster has available services, it can provide external services); and avoid the accumulation of unavailable services by dynamically updating the service list.

[0033] In this embodiment, the load balancing algorithm includes a round-robin algorithm, a random selection algorithm, or an algorithm based on service weight.

[0034] By specifying the load balancing algorithm type, such as polling (selection in sequence), random (random selection), or weighted (requests are distributed according to the service configuration weight), flexibility can be enhanced to adapt to different business scenarios (for example, high-traffic services can be assigned higher weights), optimize resource utilization, and reduce the risk of single points of failure.

[0035] During implementation, implement the algorithm logic in the api-gateway.lua script. Round-robin algorithm: Use a counter to record the index of the last selected service. The next request selects the service with the index incremented by 1 (for example, if the service list is [A, B, C], select A the first time and B the second time). Random selection algorithm: Generate a random number to select a service (for example, select A with a random number of 1 and select B with a random number of 2). Weighted algorithm: Assign a weight value to each service (for example, service A has a weight of 50%, service B has a weight of 30%, and service C has a weight of 20%). The script then selects a service based on the weight ratio (for example, select A with a random number between 0 and 0.5 and select B with a random number between 0.5 and 0.8). Those skilled in the art can easily modify the script variables to configure the algorithm type without rewriting the code.

[0036] In this embodiment, the health check step includes calling a preset interface of the service to detect a response status. If the response status is HTTP code 200, it is determined that the service is available.

[0037] It's important to note that in the health_check.lua script, the detection interface for each service is defined as / ping (other interfaces, such as / health, can be configured). As the script iterates through the service list, it sends an HTTP GET request to the service's IP:Port (e.g., "http: / / 192.168.1.1:8080 / ping"). If the response status code is 200, the service is marked as available and the failure count is reset. For example, a logistics service provides a / ping interface, which the health check script calls; if the response is normal, the counter is reset. If the interface responds slowly or fails, the script logs the failure. Those skilled in the art only need to implement a simple / ping handler on the server. This standardized detection method ensures accurate and reliable health checks, avoids misjudgments, and improves system credibility.

[0038] This embodiment also includes triggering a health check step based on a scheduled task, and the scheduled task interval is configurable.

[0039] By implementing automated periodic checks, the service list can be kept up to date; the interval can be configured to suit different environments (e.g., high-frequency checks for critical systems).

[0040] During implementation, use crontab on a Linux server to schedule tasks. For example, editing the crontab file and adding " / 30 * * * * curlhttp: / / localhost / health_check" will execute the health check script every 30 minutes. The curl command calls the access path of health_check.lua, triggering the check logic. The interval is configurable (for example, changing it to " / 10 * * * *" for every 10 minutes). Technicians can easily adjust the interval by modifying the crontab entry without restarting the service. For example, in an e-commerce system, setting a check every 1 minute ensures service availability during peak hours.

[0041] In this embodiment, the remote cache includes redis or memcached.

[0042] During implementation, choose Redis or Memcached as the remote cache. Redis is more commonly used, using its list data structure to store service information (for example, calling the Redis LPUSH command to add a service at application startup). If Memcached is chosen, its key-value pair storage service list is used. Technicians simply specify the cache type in the configuration file (for example, setting the Redis connection URL), and the script automatically adapts. For example, the startup script reads the configuration and decides whether to use the Redis or Memcached client library.

[0043] Example 2 See Figure 2 and Figure 1 As shown, an API gateway system includes: The service registration module is used to write the service information of the application service into the remote cache; The gateway configuration module integrates openresty (a Lua extension platform based on Nginx, the core operating tool of the gateway), configures the location and specifies the script path; The request processing module executes scripts to obtain a list of services from local shared memory, implements a load balancing algorithm to forward requests, and returns a degraded response if all services fail; The health check module executes scripts to obtain a list of services from a remote cache, detect service availability, and dynamically update the cache and shared memory.

[0044] During implementation, the system is deployed on a server. The service registration module is the API provided by the application (such as a Java or Python library). It is called upon application startup to write to Redis (for example, an e-commerce application calls the register_service() function). The gateway configuration module uses Openresty and configures location rules (e.g., "location / {content_by_lua_file / path / api-gateway.lua;}") in the nginx.conf file, specifying the script path. The request processing module runs api-gateway.lua: This script reads a list from shared memory (if empty, it queries Redis) and uses a round-robin algorithm to forward requests to backend services (for example, forwarding user query requests to product services). If all services fail, a degraded page is returned. The health check module runs health_check.lua: This script periodically pulls a list from Redis, iterates through the service call / ping interface, and automatically deletes any service from Redis and shared memory if it fails beyond a threshold (e.g., three times). For example, in an order system, the health check module runs every five minutes to remove unavailable payment services. Those skilled in the art can integrate these modules using standard tools without the need for custom hardware.

[0045] In this embodiment, the health check module further includes a failure counter, and if the number of service failures exceeds a configurable threshold, the service is automatically removed.

[0046] The health check module adds a failure counter with a configurable threshold (such as setting it to 3). Services that exceed the limit will be automatically removed. It can provide a fault-tolerant mechanism to avoid false removal due to transient failures. The threshold can be adjusted to adapt to different network environments and improve accuracy.

[0047] During implementation, the health_check.lua script maintains a failure count variable for each service (initially set to 0). Each time a check fails, the counter is incremented by 1; upon success, it is reset to 0. The threshold is stored in the configuration file (e.g., threshold=3). The script reads and compares the count: if the count exceeds the threshold, it removes the key from Redis. Technicians can modify the threshold (e.g., to 5) by editing the configuration file without modifying the script code. For example, in the weather API gateway, a threshold of 4 is set to mitigate the impact of network fluctuations.

[0048] This embodiment also includes a scheduled task module, which sets scheduled health checks based on the crontab mechanism.

[0049] It should be noted that the system adds a scheduled task module (such as crontab) to trigger health checks at regular intervals, which can achieve unattended operation and ensure that the list is continuously updated; the interval time can be configured to optimize performance.

[0050] During implementation, the scheduled task module is implemented through the operating system's crontab (or similar systems such as systemd timer). Edit the crontab file and add a task (e.g., " / 15 * * * * curlhttp: / / localhost / health_check") to execute the health check script every 15 minutes. Technicians can modify the interval (e.g., " / 5 * * * *" for every 5 minutes) to automatically schedule the task. For example, a social media gateway might be configured to check every 10 minutes to promptly address service changes.

[0051] In this embodiment, the request processing module supports multiple load balancing algorithms and implements request forwarding logic through scripts.

[0052] It should be noted that the request processing module supports polling, random and other algorithms, and scripts are used to implement forwarding; it can enhance module flexibility and support diverse business needs; and scripting simplifies maintenance.

[0053] During implementation, define algorithm selection parameters (e.g., algorithm="round_robin") in the api-gateway.lua script. The script applies different logic based on these parameters: incrementing the index for round-robin; using a random function for random selection. Forwarding logic: The script receives HTTP requests, parses them, and proxies them to the selected service (e.g., using the Lua socket library to send the request). Technicians specify the algorithm type in the configuration file, and the script is dynamically loaded. For example, in a video streaming gateway, switching to a random algorithm for load balancing can be done.

[0054] Example 3 A computer-readable storage medium stores a computer program, which implements the method described in Example 1 when the program is executed.

[0055] During implementation, script files (such as api-gateway.lua and health_check.lua) are stored on a storage medium (such as a hard drive or SSD). Technicians insert the media into the server, install Openresty and Redis, and then run the program to automatically execute the method steps. For example, the Lua script and crontab configuration can be packaged as a Docker image. Loading the image during deployment will run the complete gateway logic.

[0056] The above description is only a preferred embodiment of the present invention and does not limit the present invention in any way. Any simple modification, change and equivalent structural change made to the above embodiment based on the technical essence of the present invention shall still fall within the scope of protection of the technical solution of the present invention.

Claims

1. An API gateway service management method, characterized in that: The following steps are involved: After the application service is started, the service information is written to the remote cache; Configure the gateway tool and specify the script path for request processing; Get the service list from the local shared memory through the script. If the list is empty, pull the latest list from the remote cache. Uses a load balancing algorithm to select a service and forward HTTP requests. If a request fails, it tries the next service. If all else fails, it returns a degraded response. Execute the health check script, traverse the service list to detect availability, and remove the service from the remote cache and shared memory if the number of service failures exceeds the threshold.

2. The method according to claim 1, wherein The load balancing algorithm includes a polling algorithm, a random selection algorithm, or an algorithm based on service weight.

3. The method according to claim 1, wherein The health check step includes calling a preset interface of the service to detect the response status. If the response status is HTTP code 200, it is determined that the service is available.

4. The method according to claim 1, wherein It also includes health check steps triggered based on scheduled tasks, and the interval between scheduled tasks is configurable.

5. The method according to claim 1, wherein The remote cache includes redis or memcached.

6. An API gateway system, characterized in that: include: The service registration module is used to write the service information of the application service into the remote cache; Gateway configuration module, integrates openresty, configures location and specifies script path; The request processing module executes scripts to obtain a list of services from local shared memory, implements a load balancing algorithm to forward requests, and returns a degraded response if all services fail; The health check module executes scripts to obtain a list of services from a remote cache, detect service availability, and dynamically update the cache and shared memory.

7. The system according to claim 6, wherein: The health check module also includes a failure counter, which automatically removes the service if the number of service failures exceeds a configurable threshold.

8. The system according to claim 6, wherein: It also includes a scheduled task module that sets scheduled health checks based on the crontab mechanism.

9. The system according to claim 6, wherein: The request processing module supports multiple load balancing algorithms and implements request forwarding logic through scripts.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed, the method according to any one of claims 1 to 5 is implemented.

Images