Open Application Programming Interface Gateway Management System and Method

Abstract

This application relates to the field of interface gateway management technology, and discloses an open application programming interface (API) gateway management system and method. The method includes: responding to a received API call request, extracting the caller's identity information and request context parameters, performing dynamic authentication on the call request, and obtaining the authentication result; obtaining the corresponding rate limiting rules, performing dynamic mixed-mode traffic control on the call request, and obtaining the traffic control result; forwarding the call request to the corresponding backend service, and monitoring the backend service's operating status data in real time during the forwarding process, performing circuit breaker analysis based on the operating status data and preset business semantic rules, and obtaining the circuit breaker control signal; executing the corresponding request processing action according to the circuit breaker control signal, and collecting full-link observable data such as call chain tracing data and network performance data in real time to manage interface calls; this application can effectively intercept replay attacks, abnormal logins from different locations, etc., and improve gateway throughput.

Description

Technical Field

[0001] This application relates to the field of interface gateway management technology, and more specifically to an open application interface gateway management system and method. Background Technology

[0002] Currently, with the popularization of enterprise microservice architecture and the rise of API economy, API gateways, as traffic entry points, bear the functions of security protection, traffic governance and service routing. In high-concurrency, distributed and complex business scenarios, traditional static and isolated management and control methods are no longer able to cope with dynamically changing attack methods, sudden traffic and complex business dependencies.

[0003] Existing technologies suffer from the following problems: authentication mechanisms are mostly statically bound, which cannot dynamically adjust permissions based on real-time context such as the request's geographical location, time, and device fingerprint, easily leaving security blind spots; traffic control mostly adopts a single mode, relying on local counting can lead to uncontrolled total cluster volume, relying on centralized storage can lead to high latency and performance bottlenecks, and rule updates have significant delays; circuit breaking mechanisms are based only on network timeouts or HTTP status codes, which cannot identify semantic anomalies in the business layer, leading to false circuit breaking or missed circuit breaking; to solve at least one of the above problems, this application proposes an open application programming interface gateway management system and method. Summary of the Invention

[0004] To address the shortcomings of existing technologies, the purpose of this application is to provide an open application programming interface (API) gateway management system and method, which can effectively solve the problems in the background technology. The specific technical solution of this application is as follows:

[0005] Open application programming interface gateway management methods include:

[0006] In response to a received API call request, the system extracts the caller's identity information and request context parameters, and performs dynamic authentication on the API call request based on a preset dynamic permission policy library to obtain the authentication result.

[0007] Based on the authorization command that has passed the authentication, obtain the corresponding rate limiting rule, and perform dynamic mixed-mode traffic control on the call request based on the rate limiting rule to obtain the traffic control result;

[0008] In response to the forwarding instruction that allows passage in the flow control result, the call request is forwarded to the corresponding backend service, and the running status data of the backend service is monitored in real time during the forwarding process. Based on the running status data and preset business semantic rules, circuit breaking analysis is performed to obtain the circuit breaking control signal.

[0009] Based on the circuit breaker control signal, the corresponding request processing action is executed, and throughout the entire lifecycle of the request processing, full-link observable data such as call chain tracing data and network performance data are collected in real time to manage and control interface calls.

[0010] Specifically, in response to a received API call request, the caller's identity information and request context parameters are extracted, and the API call request is dynamically authenticated based on a preset dynamic permission policy library to obtain the authentication result, including:

[0011] In response to a received API call request, extract the caller's identity information and request context parameters to obtain a set of access parameters;

[0012] The set of access parameters is input into the dynamic permission policy engine and matched with the preset dynamic permission policy library to perform dynamic authentication on the call request and obtain the authentication result.

[0013] Specifically, the step of inputting the access parameter set into the dynamic permission policy engine and matching it with a preset dynamic permission policy library to dynamically authenticate the call request and obtain the authentication result includes:

[0014] Input the set of access parameters into the dynamic permission policy engine, and match it with the preset dynamic permission policy library. If the match is successful, the permission scope and access level are obtained.

[0015] Extract the ticket identifier from the access token in the call request, query the local ticket status cache and match it to obtain the ticket validity signal;

[0016] The request context parameters are matched with a preset operation feature library to generate a release instruction;

[0017] The authentication result is obtained by integrating the permission scope, access level, ticket validity signal, and release instruction.

[0018] Specifically, the step of obtaining the corresponding rate limiting rule based on the approved permission instruction in the authentication result, and performing dynamic mixed-mode traffic control on the call request based on the rate limiting rule to obtain the traffic control result includes:

[0019] Based on the authorization command that has passed the authentication, extract the application identifier and request interface address of the caller to obtain the corresponding rate limiting rules;

[0020] The traffic control results are obtained by dynamically mixing the traffic of the call requests based on the rate limiting rules.

[0021] Specifically, based on the approved permission command in the authentication result, the caller's application identifier and request interface address are extracted to obtain the corresponding rate limiting rules, including:

[0022] Based on the authorization command that has been verified in the authentication result, extract the application identifier and request interface address of the caller, query the local rule cache, and obtain the first rule version;

[0023] Compare the first rule version with the second rule version pushed via a long connection to obtain the version status, which includes rule missing, rule delayed, and rule updated.

[0024] The rate limiting rules are determined based on the version status. The determination process includes: for rule updates, the first rule version is used as the rate limiting rule; for missing rules, a pull request is sent to the rule control center, and the returned rule is used as the rate limiting rule; for rule delays, the first rule version is used as the rate limiting rule for this request and the request is allowed.

[0025] Specifically, the dynamic mixed-mode traffic control of call requests based on rate limiting rules to obtain traffic control results includes:

[0026] Based on the rate limiting rules, using the caller's application identifier and the requested interface address as indexes, we query the number of the first token in the local token bucket and compare it with the number of the second token corresponding to this request.

[0027] If the number of first tokens is greater than or equal to the number of second tokens, the corresponding tokens are deducted from the local token bucket to generate a flow control result; if the number of first tokens is less than the number of second tokens, a batch token request is initiated to the distributed token bucket, the requested tokens are added to the local token bucket, and the corresponding tokens are deducted from the local token bucket to generate a flow control result.

[0028] Specifically, in response to the forwarding instruction allowed in the flow control result, the call request is forwarded to the corresponding backend service, and the running status data of the backend service is monitored in real time during the forwarding process. Based on the running status data and preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal, including:

[0029] In response to the forwarding instruction that is allowed in the flow control result, the target instance is selected and the call request is forwarded to the corresponding backend service;

[0030] During the forwarding process, the running status data of the backend service is monitored in real time. Based on the running status data and the preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal.

[0031] Specifically, the step of responding to the forwarding instruction allowed in the flow control result, filtering out the target instance, and forwarding the call request to the corresponding backend service includes:

[0032] In response to the forwarding instruction that is allowed in the flow control result, a matching subset of instances is filtered from the instance list, and the target instance is filtered from the instance subset according to the application identifier;

[0033] The call request is forwarded to the target instance, and the forwarding status information is recorded.

[0034] Specifically, the process of real-time monitoring of the backend service's operational status data during forwarding, and performing circuit breaker analysis based on the operational status data and preset business semantic rules to obtain the circuit breaker control signal, includes:

[0035] During the forwarding process, the running status data of the backend service is monitored and parsed in real time to obtain the processing result code. The processing result code is then matched against a preset business semantic rule library to obtain an exception marker.

[0036] Based on the anomaly markers, an anomaly score is calculated using a preset anomaly analysis model;

[0037] Based on the anomaly score and preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal;

[0038] The circuit breaker analysis process includes: if the current state is closed and the anomaly score is greater than or equal to the preset circuit breaker threshold, the trigger state transitions to the open state and generates a circuit breaker open signal to cut off the service request; if the current state is open and the difference between the current time and the circuit breaker start time is greater than the preset cooling time, the trigger state transitions to the half-open state; if the current state is half-open and the anomaly score is less than the circuit breaker threshold, the trigger state transitions to the closed state.

[0039] An Open Application Programming Interface (API) gateway management system is used to implement the aforementioned API gateway management method, including:

[0040] The authentication analysis module responds to received API call requests, extracts the caller's identity information and request context parameters, and performs dynamic authentication on the call request based on a preset dynamic permission policy library to obtain the authentication result.

[0041] The flow control module obtains the corresponding rate limiting rules based on the pass-through instructions verified in the authentication results, and performs dynamic mixed-mode flow control on the call request based on the rate limiting rules to obtain the flow control result;

[0042] The circuit breaker control module, in response to the forwarding instruction that allows passage in the flow control result, forwards the call request to the corresponding backend service, and monitors the running status data of the backend service in real time during the forwarding process. Based on the running status data and preset business semantic rules, it performs circuit breaker analysis to obtain the circuit breaker control signal.

[0043] The interface management module executes corresponding request processing actions based on the circuit breaker control signal, and collects full-link observable data such as call chain tracing data and network performance data in real time throughout the entire lifecycle of request processing to manage interface calls.

[0044] The beneficial effects of this application are as follows: By fusing caller identity information with request context parameters and inputting them into a dynamic permission policy engine for real-time matching; by comparing the version of local cached rules with the version pushed via long connections, it handles rule missing, delays, and updates, and adopts a layered collaborative mechanism of local token bucket and distributed token bucket, which has the advantages of low latency and precise cluster control; by parsing the processing result code returned by the backend service, matching it with a preset business semantic rule library, calculating anomaly scores and triggering circuit breaker state machine transitions, and collecting call chain tracing data and network performance data in real time, it manages and controls interface calls; it can effectively intercept replay attacks, abnormal logins from different locations, and other situations, thereby improving gateway throughput. Attached Figure Description

[0045] Figure 1 This is a flowchart illustrating the open application programming interface gateway management method in Embodiment 1 of this application;

[0046] Figure 2 This is a flowchart illustrating the authentication result analysis process in Embodiment 1 of this application;

[0047] Figure 3 This is a schematic diagram of the structure of the Open Application Programming Interface Gateway Management System in Embodiment 1 of this application. Detailed Implementation

[0048] The present application will be further described in detail below with reference to the accompanying drawings and embodiments.

[0049] In the embodiments of this application, the terms "exemplary" or "for example" are used to indicate that something is an example, illustration, or description. Any embodiment or design that is described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design. Specifically, the use of the terms "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0050] Hereinafter, the terms "first," "second," and other generic terms are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Therefore, a feature defined as "first" or "second" may explicitly or implicitly include one or more of that feature. In the description of the embodiments of this application, unless otherwise stated, "multiple" means two or more.

[0051] Example 1

[0052] refer to Figure 1 The diagram illustrates a specific implementation of the open application programming interface gateway management method of this application, including:

[0053] S101. In response to the received API call request, extract the caller's identity information and request context parameters, and perform dynamic authentication on the API call request based on the preset dynamic permission policy library to obtain the authentication result.

[0054] S102. Based on the authorization instruction that has been verified in the authentication result, obtain the corresponding rate limiting rule, and perform dynamic mixed-mode flow control on the call request based on the rate limiting rule to obtain the flow control result.

[0055] S103. In response to the forwarding instruction that allows passage in the flow control result, the call request is forwarded to the corresponding backend service, and the running status data of the backend service is monitored in real time during the forwarding process. Based on the running status data and the preset business semantic rules, circuit breaking analysis is performed to obtain the circuit breaking control signal.

[0056] S104. Execute the corresponding request processing action according to the circuit breaker control signal, and collect full-link observable data of call chain tracing data and network performance data in real time throughout the entire life cycle of request processing in order to manage and control interface calls.

[0057] In this embodiment, in response to a received API call request, the caller's identity information and request context parameters are extracted from the request. The identity information includes data that can uniquely identify the caller, such as the caller identifier, application identifier, and access token. The request context parameters include data reflecting the characteristics of the current calling environment, such as the internet protocol address of the call source, request timestamp, device fingerprint, geographical location, and request frequency. After integrating this information to form an access parameter set, it is input into a dynamic permission policy engine. This engine internally maintains a dynamic permission policy library, which stores permission rules defined in the form of conditional expressions, such as allowing an application to access a specific interface only during office hours and from the internal network.

[0058] Specifically, the dynamic permission policy engine matches the set of access parameters against rules in the dynamic permission policy library one by one. The matching process involves logically comparing real-time request context parameters against the dynamic permission policy library. It extracts the ticket identifier of the access token carried in the call request and queries the locally maintained ticket status cache to verify whether the ticket is valid, revoked, or expired. It then matches the request context parameters against a preset operation feature library, which records characteristics of common abnormal call patterns, such as high-frequency repeated requests within a short period and atypical parameter values. By integrating the permission scope, access level, ticket validity signals, and operation feature matching results, the authentication result is obtained.

[0059] It should be noted that the authentication mechanism enables environment-aware access control; the use of local ticket status caching reduces reliance on real-time queries to the authentication center, thus lowering authentication latency; the operation feature database can identify and intercept call behaviors with abnormal characteristics, effectively preventing replay attacks, credential theft, and other situations; and by integrating access token verification, context matching, and dynamic policy execution, the access security of open application programming interfaces is improved.

[0060] Specifically, the system receives the authentication result and extracts the approved access command, which allows the user to access the interface. Based on the access command, it obtains the caller's application identifier and the requested interface address. Using the application identifier and the requested interface address as a combined index, it queries the local rule cache to obtain the currently effective rate limiting rule and its corresponding first rule version number. It also receives rule update information pushed by the rule control center through a pre-established long-lived connection channel, which includes the latest second rule version number.

[0061] The first rule version number is compared with the second rule version number. Based on the comparison result, the specific rate limiting rule processing strategy is determined: if the versions match, it indicates that the rate limiting rule is up-to-date, and the local cached rule is used directly; if the local cached rule is missing, a pull request is immediately sent to the rule control center to retrieve the local cached rule and load it into the local cache; if a version delay is detected, i.e., the local rule version lags behind the pushed version, considering real-time requirements, the local rule is still used to process this request, and an asynchronous update operation is triggered to refresh the local cache. After determining the rate limiting rule, dynamic hybrid mode traffic control is executed.

[0062] Specifically, using the application identifier and the requested interface address as indexes, the system queries the number of first tokens currently stored in the locally maintained token bucket and compares this number with the number of second tokens required for this request. If there are sufficient local tokens, the system directly deducts the corresponding number of tokens from the local token bucket and generates an allowed flow control result. If there are insufficient local tokens, the system initiates a batch token request to the distributed token bucket, adds the requested tokens to the local token bucket, and then deducts the required tokens for this request from the local token bucket to generate the flow control result.

[0063] It's important to note that a version comparison mechanism enables real-time updates of rate limiting rules. A combination of local and distributed token buckets ensures high throughput and low latency for single-machine processing, while maintaining precise total token control across the cluster. When local tokens are insufficient, batch requests are made instead of individual requests, effectively reducing interactions with distributed storage and lowering network I / O overhead. A long-connection push mechanism ensures rule changes are quickly propagated to all gateway nodes, improving the speed at which rate limiting policies take effect, reducing reliance on centralized storage, and enhancing the overall processing performance and scalability of the gateway.

[0064] Specifically, the system receives the flow control result and extracts the allowed forwarding instructions. Based on the forwarding instructions, it selects a subset of instances that match the requested interface address from the instance list maintained by the service registry. Based on the application identifier, it selects the target instance that matches the call relationship from the instance subset, forwards the call request to the target instance, and records the forwarding status information, including the forwarding time and the target instance address.

[0065] Preferably, the process of extracting forwarding instructions from the flow control results includes: parsing the flow control results and using allowed values ​​as forwarding instructions; when the value of a field in the result is "deny," directly terminating the request processing flow and returning a rate-limiting warning message to the caller; the forwarding instruction is essentially a signal identifier that the decision status field in the flow control result is "allowed," and this signal triggers the subsequent forwarding process. The service registry is an independent distributed coordination service component, which can be implemented using Nacos or Consul; the instance list is a data structure obtained from the service registry, recording all available instances of the corresponding service.

[0066] During request forwarding and subsequent processing, the runtime status data of the backend service is continuously monitored in real time, including response time, processing result codes, connection status, and exception stack traces. The collected runtime status data is parsed, and the processing result codes are extracted and matched against a pre-defined business semantic rule base. This business semantic rule base predefines the business meanings of various processing result codes and their corresponding exception markers; for example, specific error codes indicating connection failure are marked as fatal exceptions, and specific error codes indicating business validation failures are marked as business exceptions.

[0067] After obtaining the anomaly markers, they are input into a preset anomaly analysis model for calculation. The anomaly analysis model establishes a baseline through statistical analysis of historical operational data and can calculate anomaly scores based on dimensions such as the type, frequency, and consecutive occurrences of the anomaly markers. For each service instance, the distribution of various anomaly markers during normal operation, i.e., the time period without service crashes, is statistically analyzed. Specific statistical dimensions include: the average number of fatal anomalies occurring within a 10-second window, denoted as parameter A, for example, A's value is 0.5; the average number of network anomalies occurring within a 10-second window, denoted as parameter B, for example, B's value is 0.2; the average number of business anomalies occurring within a 10-second window, denoted as parameter C, for example, C's value is 5; and the consecutive occurrence pattern of anomaly markers, such as the maximum frequency of three consecutive anomalies, denoted as parameter D. These statistical values ​​constitute the baseline of the service instance.

[0068] Based on the anomaly score and preset business semantic rules, circuit breaker analysis is performed. The specific circuit breaker state machine transition process includes: if the current state is closed and the anomaly score is lower than the preset circuit breaker threshold, the trigger state transitions to the open state and generates a circuit breaker open signal to cut off subsequent business requests; if the current state is open and the difference between the current time and the circuit breaker start time is greater than the preset cooling time, the trigger state transitions to the half-open state, allowing a small number of probe requests to pass; if the current state is half-open and the anomaly score is still greater than the circuit breaker threshold, the trigger state transitions back to the closed state, and the circuit breaker continues to be active.

[0069] It should be noted that by extending the circuit breaker decision to the business layer semantics through the business semantic rule base, the accurate identification and differentiated handling of business anomalies can be achieved; the state machine-driven circuit breaker mechanism ensures the system's self-healing capability; by monitoring the running status data in real time and matching it with business rules, it can respond quickly when backend services encounter anomalies, effectively preventing the spread of faults and improving the system's security and reliability.

[0070] Specifically, based on the circuit breaker control signal, the corresponding request processing action is executed. If the circuit breaker control signal is in the open state, the system will block the continued execution of the current request and directly return a service unavailable degraded response to the caller. If the circuit breaker control signal is in the allow state, the system will continue to complete the normal request processing flow. Throughout the entire request processing lifecycle, from the moment the call request is received, end-to-end observable data is continuously collected in real time, including call chain tracing data and network performance data. Call chain tracing data is achieved by assigning a globally unique tracing identifier to each request. This identifier accompanies the request to each processing stage, and each stage records its own processing time, status information, and upstream and downstream call relationships, forming a complete call chain topology. Network performance data includes metrics such as network latency, bandwidth usage, connection establishment time, and data transmission volume at each stage of the request. The collected data is structured according to a unified format, associated with the corresponding request tracing identifier, and written to the observable data storage platform.

[0071] It should be noted that by continuously collecting call chain tracing data and network performance data, a complete observable view from client requests to backend services has been constructed. Network performance data can reflect bottlenecks and anomalies at the network level, providing data support for capacity planning and performance optimization. The correlation between observable data and control events such as authentication, rate limiting, and circuit breaking enhances the reliability of the system and improves its maintainability and troubleshooting efficiency.

[0072] This application integrates caller identity information with request context parameters and performs real-time matching; it handles rule missing, rule delay, and rule updates by comparing the local cache rule version with the long-connection pushed rule version; it adopts a layered collaborative mechanism of local token bucket and distributed token bucket, which has the benefits of low latency and precise cluster control; it parses the processing result code returned by the backend service, matches it with the preset business semantic rule library, calculates the exception score and triggers the circuit breaker state machine transition, and collects call chain tracing data and network performance data in real time to manage interface calls; it can effectively intercept replay attacks, abnormal logins from different locations, and other situations, thereby improving gateway throughput.

[0073] Furthermore, in response to a received API call request, the caller's identity information and request context parameters are extracted, and the API call request is dynamically authenticated based on a preset dynamic permission policy library to obtain the authentication result, including:

[0074] S201. In response to the received API call request, extract the caller's identity information and request context parameters to obtain the access parameter set;

[0075] S202. Input the set of access parameters into the dynamic permission policy engine and match it with the preset dynamic permission policy library to perform dynamic authentication on the call request and obtain the authentication result.

[0076] In this embodiment, in response to the received API call request, the caller's identity information and request context parameters are extracted from the call request to form an access parameter set. The extraction of identity information includes obtaining the access token from the request header, parsing the application identifier from the request context parameters, and extracting the caller identifier from the digital certificate. The access token is the credential information obtained by the caller after completing the previous identity authentication. It is usually encapsulated in JSON Web token format and contains the caller identifier, token issuance time, token expiration time, and signature information.

[0077] Specifically, the extraction of request context parameters includes obtaining the internet protocol address and port number of the calling source from the network layer, the protocol type from the transport layer, the request timestamp, request method, and requested resource path from the application layer, and device fingerprint information from the client environment. The device fingerprint information is a combination of hardware parameters collected by a probe script running on the client, including CPU model, memory size, operating system version, screen resolution, installed font list, time zone setting, and language preferences—features that uniquely identify the terminal device. The request context parameters also include geographical location information, including country, province, city, and network operator, converted from the internet protocol address using reverse geocoding technology. This data collected from different dimensions is then standardized according to a predefined data structure, and the caller identifier from the identity information is associated and combined with the various data in the request context parameters to obtain the access parameter set.

[0078] It should be noted that by comprehensively collecting the identity information and context parameters of the call request from multiple dimensions, a comprehensive and accurate set of access parameters is constructed, providing an accurate data foundation for subsequent dynamic authentication. The extraction of identity information ensures the identifiability of the caller's identity, and the collection of Internet Protocol addresses and geographical locations enables authentication to effectively identify abnormal cross-regional access, providing accurate data support for dynamic permission matching and improving the accuracy and reliability of authentication.

[0079] Specifically, the access parameter set is input into the dynamic permission policy engine and matched against a pre-defined dynamic permission policy library to dynamically authenticate the call request and obtain the authentication result. The rule-based dynamic permission policy engine improves the flexibility and response speed of permission management; the policy engine's condition matching comprehensively evaluates the context information of the call request, achieving environment-aware, fine-grained access control; local verification of the access token reduces the number of real-time interactions with the authentication center, lowers authentication latency, improves gateway throughput performance, and provides accurate data support for subsequent traffic control and request forwarding.

[0080] like Figure 2 As shown, the access parameter set is input into the dynamic permission policy engine and matched with the preset dynamic permission policy library to dynamically authenticate the call request, obtaining the authentication result, including:

[0081] S301. Input the set of access parameters into the dynamic permission policy engine and match it with the preset dynamic permission policy library. If the match is successful, the permission scope and access level are obtained.

[0082] S302. Extract the ticket identifier of the access token in the call request, query the local ticket status cache and match it to obtain the ticket validity signal;

[0083] S303. Match the request context parameters with the preset operation feature library to generate a release instruction;

[0084] S304. Integrate the permission scope, access level, ticket validity signal and release instruction to obtain the authentication result.

[0085] In this embodiment, the access parameter set is input into the dynamic permission policy engine. The engine matches this set against a preset dynamic permission policy library. When a match is found, the corresponding permission scope and access level are output. The dynamic permission policy library is a structured rule storage system, where each permission rule is defined using a conditional expression, specifically a combination of logical conditions. Each condition sets constraints on a specific field in the access parameter set. For example, a rule can be defined as: when the caller's role is equal to that of a finance personnel, the internet protocol address of the call source belongs to the company's intranet address range, the request time is between 9:00 AM and 5:00 PM, and the requested resource path begins with "financial reimbursement," access is permitted and read / write permissions are granted.

[0086] During matching, the access parameter set is parsed, and the field values ​​are extracted as factual basis. The rules in the policy library are traversed one by one, and the conditional parts of each rule are evaluated. The evaluation process uses standard rule engine algorithms, such as the Rete algorithm for efficient pattern matching. This algorithm caches intermediate matching results by constructing a condition network to avoid redundant calculations. When all conditions of a rule are met, the rule is marked as a successful match. Predefined permission scope parameters and access level parameters are extracted from the rule. The permission scope specifically represents the list of accessible interfaces, resource identifier patterns, or data field sets, while the access level specifically represents the operation permission type, such as read-only, read-write, administrative, or specific operations like export. If multiple rules match successfully, the engine judges them according to the preset priority order, generally with lower priority values ​​indicating higher priority. The rule with the highest priority is selected as the final decision basis, and the permission scope and access level are extracted from that rule. If no rule matches successfully, authentication fails, and an access denial decision is generated. The preset priority order can be set by the system administrator through access roles.

[0087] It should be noted that conditional matching can improve the flexibility and response speed of permission management; quickly complete matching calculations to ensure the high-performance processing capability of the gateway; resolve multi-rule conflicts through a priority mechanism to ensure the certainty and consistency of permission decisions; and provide accurate permission boundaries for subsequent request processing by outputting the permission scope and access level, thereby improving the security and flexibility of the system.

[0088] The system extracts the ticket identifier of the access token from the call request, queries the locally maintained ticket status cache, and verifies the ticket's validity by matching the identifier. The access token is a credential issued by the authentication authority after the caller completes initial authentication; it is typically in JSON Web Token format, and its ticket identifier can be a unique number or the token's hash value. Upon receiving a call request, the system retrieves the access token from the authorization field in the request header or from the request parameters, and parses out the ticket identifier. The local ticket status cache is a key-value store running in the gateway's memory. The key is the ticket identifier, and the value is the corresponding ticket status information, including valid, revoked, expired, and related metadata such as the expiration timestamp. This cache receives real-time ticket status change notifications by subscribing to the authentication authority's event bus. For example, when a user logs out or an administrator revokes a token, the authentication authority pushes a revocation event, and the gateway immediately updates the status of the corresponding ticket in its local cache upon receiving the event.

[0089] Specifically, when querying the cache, the corresponding status record is searched using the ticket identifier as the key. If not found, it indicates that the ticket has never been verified. A real-time verification request is then initiated to the authentication center, and the verification result is written to the cache with an expiration time set. The expiration time can be set according to the system's control precision requirements, such as five minutes. If a status record is found, the expiration timestamp in the record is further checked to see if it is later than the current system time and if the status flag is valid. Only when the ticket exists in the cache, the status flag is valid, and the expiration time has not expired is the ticket deemed valid, and a valid ticket signal is generated; otherwise, an invalid signal is generated.

[0090] It should be noted that caching the local ticket status can reduce reliance on real-time queries to the remote authentication center, reduce network latency and authentication center load during the authentication process, and improve the gateway's throughput. By subscribing to the authentication center's event bus to update the cache in real time, it is ensured that ticket status changes can be quickly propagated to all gateway nodes, improving the security and reliability of the token. And by using a ticket validity signal, it is ensured that the caller of the valid credentials can access subsequent resources.

[0091] The request context parameters are matched against a preset operation feature library. Based on the matching results, a release instruction is generated. The operation feature library is a dataset storing the characteristics of various abnormal call patterns. These characteristics are obtained by training with machine learning algorithms based on historical call data. Historical call data refers to the complete log record of every API call request recorded and persistently stored by the gateway system over a past period. Each log record contains at least the following fields: call timestamp, call source Internet Protocol address, request method, request path, request parameter content, device fingerprint, user agent string, response status code, response time, and a flag indicating whether rate limiting or circuit breaking has been triggered.

[0092] Specifically, the system pre-collects normal call request logs and confirmed malicious attack logs over a long period to form a training dataset. Normal call logs include various legitimate requests during peak and off-peak business periods, while malicious attack logs contain known attack samples such as web crawlers, hacking, replay attacks, and parameter tampering. Normal call request logs are a subset of historical call data, referring to request records that the system determines are legitimate and harmless. Confirmed malicious attack logs refer to request records that have been identified as attack behavior by the security system and successfully intercepted.

[0093] Specifically, request context parameters are extracted from each log entry, including internet protocol address, request frequency, request time distribution, request parameter pattern, device fingerprint, user agent string, and request path sequence, to obtain a feature vector. This feature vector, along with its corresponding label indicating normal or abnormal behavior, is then input into the Isolation Forest algorithm for training. This algorithm constructs multiple isolated trees by randomly selecting features and random split values. Outliers, being easily isolated, have shorter path lengths. During training, the main parameters of the algorithm include: the number of trees is set to 100, the sample subset size of each tree is set to 256, and the pollution parameter is set to the estimated proportion of outliers in the training data, for example, 0.1%. After training, each isolated tree records a specific split point, and all trees together constitute the Isolation Forest model.

[0094] During operation, feature vectors are extracted from the current request context parameters and input into the isolated forest model. The model calculates the path length of the sample in each tree and takes the average to obtain an anomaly score. The system presets an anomaly score threshold based on the required control precision, for example, 0.6. When the anomaly score output by the model exceeds this threshold, the request is determined to have abnormal operation characteristics, and a denial instruction is generated. If the anomaly score is below the threshold, it is determined to have normal operation characteristics, and a permission instruction is generated. By generating permission instructions, improper call requests can be identified and blocked in advance during the authentication process, reducing the risk of attacks on backend services and improving the overall system security.

[0095] Specifically, the process integrates the permission scope and access level, ticket validity signal, and grant command. It checks the ticket validity signal; if it's invalid, it generates a denied access authentication result and returns an invalid token message to the caller. If the ticket validity signal is valid, it checks the grant command; if the grant command is denied, it generates a denied access authentication result and logs the failed match of abnormal operation features. If the grant command is granted, it enters the permission matching result integration phase, where the authentication result is obtained.

[0096] Specifically, after extracting the ticket identifier from the access token in the call request, the local ticket status cache is queried. If there is no record corresponding to the ticket identifier in the cache, it is determined that the ticket has never been verified or has expired, and the ticket validity signal is invalid. If there is a record in the cache, but the status mark in the record is revoked or expired, or the expiration timestamp in the record is earlier than the current system time, the ticket validity signal is also determined to be invalid. The ticket validity signal is only determined to be valid when the ticket identifier exists, the status mark is valid, and the expiration time is later than the current time.

[0097] It should be noted that by integrating multi-dimensional verification results, the valid ticket signal ensures the caller's identity is trustworthy, the release instruction eliminates the risk of abnormal behavior, the scope of permission and access level limit the operation boundary, and the generation of comprehensive authentication results can accurately control the access permissions of each request, ensuring that only requests that pass multiple verifications can obtain the corresponding resource access capabilities, thus guaranteeing the data security and access compliance of the open platform.

[0098] Furthermore, based on the approved permission command in the authentication result, the corresponding rate limiting rule is obtained, and the call request is subjected to dynamic hybrid mode traffic control based on the rate limiting rule to obtain the traffic control result. The dynamic hybrid mode traffic control process includes:

[0099] S401. Based on the pass instruction verified in the authentication result, extract the application identifier and request interface address of the caller to obtain the corresponding rate limiting rule;

[0100] S402. Based on the rate limiting rules, perform dynamic mixed-mode flow control on the call request to obtain the flow control result.

[0101] In this embodiment, based on the approved permission command in the authentication result, the application identifier and request interface address of the caller are extracted to obtain the corresponding rate limiting rules. By querying the rules using the application identifier and request interface address as a combination, traffic control policies for different callers and different interfaces are isolated. Each business scenario can independently configure rate limiting parameters without affecting each other. By pushing version change notifications through long connections, rule updates can be quickly propagated to all gateway nodes, shortening the policy effectiveness delay. The obtained rate limiting rules provide a precise basis for subsequent traffic control, enabling traffic governance capabilities to flexibly adapt to business changes.

[0102] Specifically, based on rate limiting rules, dynamic mixed-mode traffic control is applied to call requests to obtain the traffic control results. By combining local token buckets and distributed token buckets, low latency, high throughput, and precise total quantity control at the cluster level can be guaranteed, reducing network latency and the load pressure on centralized services. Batch application reduces the number of accesses to centralized storage, improving overall efficiency and enhancing the gateway's processing capacity and resource utilization.

[0103] Furthermore, based on the approved permission command in the authentication result, the caller's application identifier and requested interface address are extracted to obtain the corresponding rate limiting rules, including:

[0104] S501. Based on the successful authorization instruction in the authentication result, extract the application identifier and request interface address of the caller, query the local rule cache, and obtain the first rule version.

[0105] S502. Compare the first rule version with the second rule version pushed through the long connection to obtain the version status, which includes rule missing, rule delayed and rule updated.

[0106] S503. Determine the rate limiting rule based on the version status. The determination process includes: for rule updates, using the first rule version as the rate limiting rule; for missing rules, sending a pull request to the rule control center and using the returned rule as the rate limiting rule; for rule delays, using the first rule version as the rate limiting rule for this request and allowing it to proceed.

[0107] In this embodiment, based on the approved release instruction in the authentication result, the caller's application identifier and the requested interface address are extracted from the release instruction. Based on these two pieces of information, the local rule cache is queried to obtain the corresponding first rule version. Specifically, the release instruction in the authentication result is generated after successful authentication. The data structure of this instruction includes a caller identity information field, where the application identifier is a unique identifier assigned to the caller application during platform registration, such as a string composed of hexadecimal characters. The requested interface address is parsed from the Uniform Resource Identifier path of the original Hypertext Transfer Protocol request. The application identifier and the requested interface address are concatenated to obtain a composite key, which is used as the query condition to access the local rule cache. The local rule cache is a hash table structure maintained in the gateway node's memory, stored in a key-value pair manner. The key is the aforementioned composite key, and the value is an object containing detailed information about the rate limiting rule, including the type parameter of the rate limiting algorithm. The version number is a monotonically increasing integer, initially set to one. Whenever the rule content changes, a new version number is generated for the rule, typically incremented by one from the original version number. When the system performs a query operation, it searches for the corresponding entry in the hash table based on the composite key. If found, the version number field is extracted from the entry as the first rule version; if not found, an empty value is returned to indicate that the rule does not exist in the local cache.

[0108] It should be noted that by combining the application identifier and the request interface address as the cache key, the rate limiting rules for each application accessing each interface can be stored independently and located quickly, avoiding interference between rules of different businesses and reducing memory usage and network overhead.

[0109] The system compares the first rule version with the second rule version pushed via a persistent connection. Based on the comparison result, the version status is determined, including three possibilities: missing rule, delayed rule, and updated rule. Specifically, upon system startup, a persistent connection is established with the rule control center using a custom persistent connection protocol based on the Transmission Control Protocol (TCP). This connection is persistent and used by the rule control center to proactively push rule change notifications to gateway nodes. The rule control center internally maintains the master data storage for all rate limiting rules. When operations personnel modify a rate limiting rule through the management interface, the rule control center generates a change event. This event includes the affected composite key and the updated second rule version number. The rule control center then broadcasts this change event to all connected gateway nodes via the persistent connection.

[0110] Specifically, each gateway node maintains a version mapping table locally, recording the second rule version number corresponding to each recently received composite key. This mapping table is updated in real time with each received push notification. The results of checking the local rule cache are as follows: If the first rule version is empty, meaning the rule does not exist in the local cache, the version status is directly determined to be rule missing; if the first rule version exists, the corresponding second rule version number is queried from the locally maintained version mapping table using the same composite key; if the version mapping table does not contain the second rule version corresponding to the composite key, or if the second rule version is equal to the first rule version, it indicates that the local rule is consistent with the latest rule, and the version status is determined to be rule updated, meaning the local rule is now up-to-date; if the second rule version exists and its value is greater than the first rule version, it indicates that the locally cached rule version lags behind the latest pushed version, and the version status is determined to be rule delayed; the consistency status of the current rule is identified through comparison.

[0111] It should be noted that the long-connection push mechanism can record rule changes in real time, improving the speed at which traffic control policies take effect; the version mapping table can accurately identify version differences, and the three states of missing rules, updated rules, and delayed rules can take corresponding processing strategies for different situations, ensuring that all gateway nodes can quickly and accurately converge to the same rule state, avoiding traffic control deviations caused by inconsistent rules.

[0112] Based on the version status, an appropriate strategy is adopted to determine the rate limiting rule used for the request. Specifically, for the rule update status, i.e., the first rule version is the same as the second rule version, it indicates that the rule in the local cache is already the latest version, and the rate limiting rule object stored in the local cache is directly used as the rate limiting rule for this request. For the rule missing status, i.e., the rule does not exist in the local cache, the complete rule definition is immediately retrieved, a rule retrieval request is constructed, and the request contains composite key information, i.e., application identifier and request interface address. A synchronous call is initiated to the rule retrieval interface of the rule control center via the Hypertext Transfer Protocol. After receiving the request, the rule control center queries the corresponding complete rate limiting rule from the main data storage, including algorithm type, parameter configuration, and latest version number, and encapsulates this information into a response and returns it to the gateway node. After receiving the response, the gateway node stores the rule in the local rule cache, records the returned version number as the first rule version, and uses this rule object as the rate limiting rule for this request.

[0113] For rule delay status, i.e., the local rule version is behind the latest pushed version, considering the real-time requirements of this request, the old rules in the local cache will continue to be used to process this request, generate traffic control results and allow the request, trigger an asynchronous update task in the background, send a rule pull request to the rule control center, obtain the latest rules and update the local rule cache and version number so that subsequent requests can use the latest rules.

[0114] It should be noted that different processing strategies are set for different version states. In the rule update state, the local cache is used directly to maintain the efficiency of request processing. In the rule missing state, the rules are fetched synchronously to ensure that the newly launched interface can immediately obtain the correct traffic control and avoid the risk of requests being incorrectly allowed or rejected due to missing rules. In the rule delay state, the strategy of allowing the old rules and asynchronous updates is adopted to avoid blocking the request thread while waiting for the rule update and to ensure that the rules can be updated to the latest version, thereby improving the stability and reliability of the system.

[0115] Furthermore, based on the rate limiting rules, dynamic mixed-mode traffic control is applied to the call requests to obtain the traffic control results, including:

[0116] S601. Based on the rate limiting rules, using the caller's application identifier and the requested interface address as indexes, query the number of the first token in the local token bucket and compare it with the number of the second token corresponding to this request.

[0117] S602. If the number of first tokens is greater than or equal to the number of second tokens, deduct the corresponding tokens from the local token bucket and generate a flow control result; if the number of first tokens is less than the number of second tokens, initiate a batch token application to the distributed token bucket, add the applied tokens to the local token bucket, deduct the corresponding tokens from the local token bucket, and generate a flow control result.

[0118] In this embodiment, based on the rate limiting rules, the system queries the number of first tokens currently stored in the local token bucket using the caller's application identifier and the requested interface address as a combined index, and compares this number with the number of second tokens corresponding to this request. Specifically, the rate limiting rules explicitly specify the use of the token bucket algorithm as a traffic control method, and preset token generation rate parameters and bucket capacity parameters based on the processing capacity of the backend service and the importance of the business. The system maintains an independent local token bucket instance in memory for each application identifier plus the requested interface address as a key. This instance is a data structure that includes the number of currently available first tokens and the timestamp of the last token replenishment.

[0119] For example, system administrators use load testing tools to obtain the maximum processing capacity (e.g., the number of requests per second) of the backend service corresponding to each interface, and set the token generation rate to 70% to 80% of this maximum processing capacity to reserve a safety margin to avoid backend overload. The bucket capacity parameter is usually set to two to five times the token generation rate to cope with sudden traffic surges. For example, if a certain order creation interface is confirmed by load testing to be able to stably handle 100 requests per second, then the token generation rate is preset to 80 tokens per second, and the bucket capacity is preset to 240 tokens per second.

[0120] When a request arrives, the local bucket is preprocessed according to the token bucket algorithm's replenishment logic: the time difference between the current time and the last replenishment time is calculated, this time difference is multiplied by the token generation rate to obtain the number of tokens to be replenished, the replenished token number is compared with the bucket capacity, and the smaller value is taken as the updated first token number, and the last replenishment timestamp is updated to the current time. After completing the replenishment logic, the second token number required for this request is obtained. For ordinary requests, this number defaults to 1. For batch operations or resource-intensive operations such as batch data export or file upload, the request parameters can carry an identifier for the number of tokens consumed. The system parses this identifier to obtain the second token number, for example, set to 5. The updated first token number and the second token number are compared numerically, and different processing branches are entered according to the comparison result.

[0121] It should be noted that by maintaining the token bucket instance in local memory, the network latency overhead caused by accessing remote storage for each request can be avoided, thereby improving the gateway's processing throughput. Setting different token consumption amounts for different request types allows for accurate traffic control of resource-intensive operations, avoiding data contention issues caused by concurrent updates in high-concurrency scenarios and improving the gateway's high-performance processing capabilities.

[0122] Specifically, two different processing flows are executed to generate flow control results based on the comparison results. When the comparison results satisfy that the number of first tokens is greater than or equal to the number of second tokens, it indicates that there are sufficient token resources in the local token bucket. The number of second tokens required for this request is directly deducted from the local token bucket, the number of first tokens in the local bucket is updated to the original number minus the number of second tokens, and a flow control result that allows passage is generated. This result contains the pass instruction and the token consumption record of this request.

[0123] When the number of tokens in the first token is less than the number of tokens in the second token, it indicates that there are not enough tokens locally, and the distributed token bucket replenishment mechanism is activated. The distributed token bucket is stored in a centralized key-value storage service, such as using Redis's sorted set or string type implementation. Each combination of application identifier and requested interface address corresponds to a distributed bucket key. A batch token request is constructed, carrying the combination key and the request quantity. The request quantity is determined according to a preset strategy. The batch request quantity is dynamically calculated based on the current state and capacity of the local token bucket. The system sets a high watermark percentage, such as 80% of the bucket capacity. The batch request quantity is equal to the number of tokens corresponding to the high watermark minus the number of tokens currently remaining in the local bucket. Atomic operations are initiated to the distributed token bucket by executing a pre-loaded Lua script. This script, executed on the server side, contains complete logic for reading the current remaining token quantity in the distributed bucket, determining whether it is sufficient, deducting the requested quantity, and resetting the expiration time. This ensures that the entire process is atomic and avoids concurrent contention. If the distributed token bucket returns a success response, the requested token quantity is added to the local token bucket, increasing the first token quantity. The second token quantity required for this request is deducted from the local token bucket, generating a flow control result that allows the request to pass. If the distributed token bucket returns a failure response due to insufficient quota, a flow control result that rejects the request is generated, and service rate limiting response information is returned to the caller.

[0124] It should be noted that by combining local token buckets and distributed token buckets, the high throughput performance of the gateway is guaranteed; when local tokens are insufficient, batch requests are used to reduce the frequency of access to distributed storage and reduce remote call overhead; and a balance is achieved between performance, accuracy and resource utilization through a hybrid traffic control mechanism.

[0125] Furthermore, in response to the forwarding instruction allowed in the flow control result, the call request is forwarded to the corresponding backend service, and the running status data of the backend service is monitored in real time during the forwarding process. Based on the running status data and preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal, including:

[0126] S701. In response to the forwarding instruction that allows passage in the flow control result, the target instance is selected and the call request is forwarded to the corresponding backend service;

[0127] S702. During the forwarding process, monitor the running status data of the backend service in real time, and perform circuit breaker analysis based on the running status data and preset business semantic rules to obtain the circuit breaker control signal.

[0128] In this embodiment, in response to the forwarding instruction that allows passage in the flow control result, the call request is forwarded to the corresponding backend service; through dynamic service instance filtering and load balancing, the request can be distributed among multiple backend instances, avoiding single point overload, improving the system's processing capacity and resource utilization, and enhancing the gateway's concurrent processing capability.

[0129] Specifically, during the forwarding process, the system monitors the operational status data of backend services in real time. Based on this operational status data and pre-defined business semantic rules, it performs circuit breaker analysis to obtain circuit breaker control signals. By monitoring the operational status data of backend services in real time, service anomalies can be quickly detected and circuit breaker measures can be taken, effectively preventing the spread of faults. By calculating anomaly scores, the system can reflect real-time changes in the service status, avoiding misjudgments caused by instantaneous fluctuations and enabling rapid response to persistent anomalies.

[0130] Furthermore, in response to the forwarding instruction allowed in the flow control result, the target instance is filtered out, and the call request is forwarded to the corresponding backend service, including:

[0131] S801. In response to the forwarding instruction that is allowed in the flow control result, filter out a matching subset of instances from the instance list, and filter out the target instance from the instance subset according to the application identifier;

[0132] S802. Forward the call request to the target instance and record the forwarding status information.

[0133] In this embodiment, in response to the forwarding instruction allowed in the traffic control result, a subset of instances matching the requested interface address is selected from the instance list maintained by the service registry. The target instance is then selected from this subset based on the application identifier. The forwarding instruction in the traffic control result includes the requested interface address and the caller application identifier determined during the authentication process. The name of the backend service to be called is determined based on the requested interface address. The locally maintained service instance cache is accessed. This cache is updated in real-time through subscription to event pushes from the service registry and stores dynamic information of all currently available service instances, including each instance's Internet Protocol address, port number, health status, weight value, and the application identifier or version tag to which it belongs.

[0134] Specifically, the system retrieves a complete list of instances for a service from the cache based on the service name. Then, it filters a subset of matching instances from this list according to a pre-defined load balancing strategy. This load balancing strategy can be a round-robin algorithm (selecting instances sequentially), a least-connections algorithm (selecting the instance with the fewest active connections), or a consistent hashing algorithm (calculating hash values ​​based on request characteristics such as caller identifiers to ensure requests with the same characteristics are always routed to the same instance). Within the selected instance subset, a second filtering is performed based on application identifiers. For example, some instances may be specifically marked to handle requests from a particular application, or, according to a canary release strategy, requests carrying specific application identifiers may be routed to instances in the canary release version. After filtering, a unique target instance is determined, and the address information of that instance is encapsulated.

[0135] It should be noted that by maintaining the dynamic instance list through the service registry, the backend service instances are automatically discovered and their status is monitored. When an instance is scaled up or down or goes offline due to a failure, the gateway can detect this in real time and adjust the routing target, improving the system's elasticity and maintainability. The configurability of various load balancing algorithms allows the system to select the appropriate strategy according to different business scenarios, ensuring data freshness while maintaining the gateway's high throughput performance and ensuring that requests are accurately delivered to the corresponding service instances.

[0136] Specifically, the call request is forwarded to the target instance, and forwarding status information is recorded during the forwarding process; the complete address information of the target instance is obtained, including the Internet Protocol address and port number. Based on this address, a Hypertext Transfer Protocol request is constructed. This request inherits the request method, request header, request body and request parameters of the original call request, and attaches the context information generated by the gateway itself. The request is sent using an asynchronous non-blocking input / output model. Each request is encapsulated as an asynchronous task and sent when the connection is available. After sending, the thread is immediately released to handle other requests without blocking and waiting for a response.

[0137] While sending the request, the system records the start timestamp of the forwarding. When the backend service returns a response or a connection error occurs, the system captures the result through a callback function and records information such as the response status code, response time (i.e., the total time from sending to receiving the response), and response body size. After forwarding is completed, the backend service's response is returned to the original caller. If forwarding fails, the corresponding error response is returned.

[0138] It should be noted that the gateway does not block worker threads when forwarding requests. A single thread can handle multiple waiting connections simultaneously, improving the gateway's concurrency processing capabilities and resource utilization, and avoiding system crashes caused by thread exhaustion in high-concurrency scenarios. By associating forwarding time, status codes, and exception information with tracking identifiers, the forwarding performance of each request can be accurately analyzed. Based on this data, real-time monitoring metrics can be generated, providing an accurate data foundation for capacity planning and performance optimization.

[0139] Furthermore, during the forwarding process, the operational status data of the backend service is monitored in real time. Based on the operational status data and preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal, including:

[0140] S901. During the forwarding process, monitor and parse the running status data of the backend service in real time to obtain the processing result code. Match the processing result code with the preset business semantic rule library to obtain the anomaly marker.

[0141] S902. Calculate the anomaly score based on the anomaly marker using a preset anomaly analysis model;

[0142] S903. Based on the anomaly score and preset business semantic rules, perform circuit breaker analysis to obtain a circuit breaker control signal; wherein, the circuit breaker analysis process includes: if the current state is closed and the anomaly score is greater than or equal to the preset circuit breaker threshold, the trigger state transitions to the open state and generates a circuit breaker open signal to cut off the service request; if the current state is open and the difference between the current time and the circuit breaker start time is greater than the preset cooling time, the trigger state transitions to the half-open state; if the current state is half-open and the anomaly score is less than the circuit breaker threshold, the trigger state transitions to the closed state.

[0143] In this embodiment, runtime status data is continuously monitored in real time throughout the entire process of request forwarding to the backend service. The collected data is parsed to extract the processing result code, which is then input into a preset business semantic rule base for matching to obtain anomaly markers. A runtime status monitor is maintained for each backend service instance. This monitor collects data by intercepting the request response stream. When the request forwarding is complete and a response is received from the backend service, the monitor parses the response header to obtain the Hypertext Transfer Protocol status code and parses the response body to extract the processing result code defined at the business layer. The system integrates this collected raw data, including response time, response size, status code, and processing result code, to obtain runtime status data.

[0144] Specifically, the extracted processing result code is used as the query key and input into the business semantic rule base for matching. The business semantic rule base is a pre-defined knowledge base by business experts, where each rule clearly defines the business meaning and severity of the anomaly corresponding to a specific processing result code. The rule base is constructed by: performing statistical analysis based on historical data; identifying processing result codes that are strongly correlated with subsequent service crashes and marking them as high-risk anomalies by analyzing historical call data. The rule base uses an efficient key-value storage structure, with the processing result code as the key and the anomaly marker object as the value. The anomaly marker object contains an anomaly type field, such as fatal anomaly, business anomaly, network anomaly, and a weight field. The matching process directly searches for the corresponding anomaly marker using the processing result code; if no match is found, it is marked as normal by default.

[0145] It should be noted that by parsing the response body to extract the processing result code at the business layer, the dimension of circuit breaker decision-making is expanded from the network layer Hypertext Transfer Protocol status code to the business semantic layer, which can analyze the service health status; the fast mapping from processing result code to anomaly marker ensures the efficiency of the matching process; and by parsing the running status data into anomaly markers, accurate data support is provided for subsequent quantitative analysis.

[0146] Specifically, based on the anomaly markers, an anomaly score within the current time window is calculated using a pre-defined anomaly analysis model. A sliding time window is maintained for each backend service instance; for example, the window length is set to sixty seconds, divided into six ten-second sub-windows. After each request is processed and an anomaly marker is obtained, the marker, along with the current timestamp, is recorded in the corresponding sub-window. The anomaly analysis model uses a weighted cumulative algorithm to calculate the anomaly score. This algorithm assigns different weight values ​​to different types of anomaly markers. The model counts the occurrence frequency of each type of anomaly in each sub-window within the current complete sliding window and calculates the weighted sum to obtain the anomaly score.

[0147] Preferably, the anomaly analysis model employs machine learning algorithms to improve prediction accuracy. A Long Short-Term Memory (LSTM) network is used to analyze the time series data. The network's input is a time series, with each time point corresponding to a sub-window containing various anomaly count vectors. The output is the predicted anomaly score for the future time window. The training dataset is derived from historical operational status data, collecting operational status records of all backend services over the past few months, including the processing result code for each request, the corresponding anomaly label, and whether a service crash occurred. During training, mean squared error (MSE) is used as the loss function to measure the difference between the predicted anomaly score and the actual anomaly occurrence. Model parameters include a hidden layer dimension of 128 for the LSE network, a time step of 10 sub-windows, a batch size of 32, optimization using backpropagation, and 50 training epochs until the loss converges.

[0148] It should be noted that the sliding time window can smoothly reflect abnormal trends and avoid misjudgments caused by single anomalies. The exponential decay factor makes the anomaly score more focused on the recent state and more sensitive to the real-time health status of the service, which helps to respond quickly to sudden service failures. The calculated anomaly score serves as a standardized risk indicator, providing accurate data support for circuit breaker decisions.

[0149] Specifically, based on anomaly scores and a pre-defined business semantic rule base, circuit breaker state machine analysis is performed to generate circuit breaker control signals. A circuit breaker state machine is maintained for each backend service instance, containing three states: closed, open, and half-open, and recording the current state and timestamps related to state transitions. At the start of circuit breaker analysis, the anomaly score of the current service instance is obtained; this score is the calculated value within the most recent sliding window. The system sets pre-defined circuit breaker thresholds and cooling-off periods according to the required control precision; for example, the circuit breaker threshold is set to 30 and the cooling-off period to 60 seconds.

[0150] Specifically, the circuit breaker analysis logic handles three scenarios based on the current state: First, if the current state is closed, indicating the circuit breaker is off and requests are forwarded normally, the system compares the anomaly score with the circuit breaker threshold. If the anomaly score is greater than or equal to the threshold, it indicates the service anomaly risk has reached the trigger condition, and the system transitions to the open state, recording the circuit breaker start time as the current timestamp and generating a circuit breaker open signal to cut off subsequent service requests. If the anomaly score is lower than the threshold, the closed state remains. Second, if the current state is open, indicating the circuit breaker is on, all requests are quickly failed. The system calculates the difference between the current time and the circuit breaker start time. If this difference is greater than the preset cooldown time, it indicates the circuit breaker duration is sufficient, and the system transitions to the half-open state, generating a circuit breaker half-open signal that allows a small number of probe requests to pass. If the difference does not exceed the cooldown time, the open state remains, and a circuit breaker open signal continues to be generated. In the third scenario, the current state is half-open, indicating that the circuit breaker is in the experimental phase, allowing a limited number of probe requests to pass through to test whether the service has recovered. The system maintains a probe request counter. When the number of probe requests does not exceed a preset probe request limit, for example, set to ten, for each probe request, it is judged based on the returned anomaly score. If the anomaly score is less than the circuit breaker threshold, it indicates that the service has recovered, the system triggers the state to transition back to the closed state, and generates a circuit breaker closing signal. If the anomaly score exceeds the circuit breaker threshold, it indicates that the service has not yet recovered, the triggers the state to transition back to the open state, restarts the cooldown timer, and generates a circuit breaker opening signal.

[0151] It should be noted that the circuit breaker analysis mechanism driven by the state machine generates circuit breaker control signals that provide accurate execution basis for interface management, realizes the separation of circuit breaker decision and execution action, and can perform fault review and root cause analysis by recording circuit breaker events and state transition logs, thereby improving the security and reliability of the system.

[0152] like Figure 3 As shown, the Open Application Interface Gateway Management System is used to implement the Open Application Interface Gateway Management Method, including:

[0153] The authentication analysis module responds to received API call requests, extracts the caller's identity information and request context parameters, and performs dynamic authentication on the API call requests based on a preset dynamic permission policy library to obtain the authentication results.

[0154] The flow control module obtains the corresponding rate limiting rules based on the pass-through instructions verified in the authentication results, and performs dynamic mixed-mode flow control on the call request based on the rate limiting rules to obtain the flow control result;

[0155] The circuit breaker control module, in response to the forwarding instruction that allows passage in the flow control result, forwards the call request to the corresponding backend service, and monitors the running status data of the backend service in real time during the forwarding process. Based on the running status data and preset business semantic rules, it performs circuit breaker analysis to obtain the circuit breaker control signal.

[0156] The interface management module executes corresponding request processing actions based on the circuit breaker control signal, and collects full-link observable data such as call chain tracing data and network performance data in real time throughout the entire lifecycle of request processing to manage interface calls.

[0157] Example 2

[0158] The following describes a technical solution for managing the order creation interface during a major e-commerce promotional event. Assume an e-commerce platform faces a massive influx of concurrent requests to its order creation interface during a promotional period. The platform employs this technical solution to manage the entire interface call chain, specifically including:

[0159] When a user initiates an order creation request via the mobile app, the API gateway extracts the user's identity information (user ID, access token) and request context parameters (source IP address, device fingerprint, request time). The dynamic permission policy engine matches these parameters against the policy library: the user is a regular member, and the policy library stipulates that regular members cannot create orders between 00:00 and 06:00 daily; the current time is 10:00 AM, so the match is successful, granting the "create order" permission scope and "read / write" access level. Simultaneously, the gateway queries the local ticket cache to confirm the access token's validity. The operation feature library detects that the request's IP address and device fingerprint match the user's historical behavior, generating a permission command. The integrated authentication result is "allowed."

[0160] After successful authentication, the gateway obtains the user's application identifier and the rate limiting rules corresponding to the order interface address: the token generation rate is 200 tokens per second, and the bucket capacity is 500 tokens. The local token bucket currently has 150 tokens. This request consumes 1 token, which is sufficient, so the local token is deducted and allowed to pass. At this time, another user initiates a batch export order request, consuming 155 tokens. The local tokens are insufficient, so the gateway requests 50 tokens from the distributed token bucket (Redis storage). The request is successful and added to the local token bucket, then 5 tokens are deducted, and the request is allowed. If the distributed token bucket quota is exhausted, a rate limiting response is returned.

[0161] The request is forwarded to the order service backend instance. During the forwarding process, the gateway monitors the operational status in real time, including response time and processing result code. Assuming an order service database connection failure, a processing result code "5001" is returned. The business semantic rule base marks this processing result code as "abnormal". The anomaly analysis model calculates an anomaly score of 85 (out of 100) based on the frequency and consecutive occurrences of anomalies within the past 60 seconds. The preset circuit breaker threshold is 60. The current state is closed; since 85 ≥ 60, the circuit breaker state machine transitions to the open state, generating a circuit breaker open signal.

[0162] Upon receiving the circuit breaker activation signal, the gateway directly rejects subsequent requests and returns a "service busy" degraded response, while simultaneously recording the circuit breaker event. Throughout the entire lifecycle, the system collects real-time call chain tracing data (request ID, time consumed at each stage) and network performance data (latency, bandwidth), reporting it to the observability platform. Operations personnel can identify order service anomalies through a visual interface and immediately intervene to repair them. This solution ensures the stability of the core transaction chain during peak promotional periods, avoiding a cascading failure effect caused by backend service failures. Furthermore, dynamic authentication intercepts abnormal requests, and end-to-end data supports rapid fault location.

[0163] The above description is merely a preferred embodiment of this application. The scope of protection of this application is not limited to the above embodiments. All technical solutions falling within the scope of this application's concept are within the scope of protection of this application. It should be noted that for those skilled in the art, any improvements and modifications made without departing from the principles of this application should also be considered within the scope of protection of this application.

Claims

1. An open application programming interface (API) gateway management method, characterized in that, include: In response to a received API call request, the system extracts the caller's identity information and request context parameters, and performs dynamic authentication on the API call request based on a preset dynamic permission policy library to obtain the authentication result. Based on the authorization command that has been verified in the authentication result, the corresponding rate limiting rule is obtained, and the call request is dynamically mixed mode traffic control is performed based on the rate limiting rule to obtain the traffic control result; In response to the forwarding instruction that allows passage in the flow control result, the call request is forwarded to the corresponding backend service, and the running status data of the backend service is monitored in real time during the forwarding process. Based on the running status data and preset business semantic rules, circuit breaking analysis is performed to obtain the circuit breaking control signal. Based on the circuit breaker control signal, the corresponding request processing action is executed, and throughout the entire lifecycle of the request processing, full-link observable data such as call chain tracing data and network performance data are collected in real time to manage and control interface calls.

2. The open application programming interface gateway management method according to claim 1, characterized in that, The process of responding to a received API call request involves extracting the caller's identity information and request context parameters, and dynamically authenticating the API call request based on a preset dynamic permission policy library to obtain the authentication result, including: In response to a received API call request, extract the caller's identity information and request context parameters to obtain a set of access parameters; The set of access parameters is input into the dynamic permission policy engine and matched with the preset dynamic permission policy library to perform dynamic authentication on the call request and obtain the authentication result.

3. The open application programming interface gateway management method according to claim 2, characterized in that, The process of inputting the access parameter set into the dynamic permission policy engine and matching it with a preset dynamic permission policy library to dynamically authenticate the call request and obtain the authentication result includes: Input the set of access parameters into the dynamic permission policy engine, and match it with the preset dynamic permission policy library. If the match is successful, the permission scope and access level are obtained. Extract the ticket identifier from the access token in the call request, query the local ticket status cache and match it to obtain the ticket validity signal; The request context parameters are matched with a preset operation feature library to generate a release instruction; The authentication result is obtained by integrating the permission scope, access level, ticket validity signal, and release instruction.

4. The open application programming interface gateway management method according to claim 1, characterized in that, The step involves obtaining the corresponding rate limiting rule based on the approved authorization command in the authentication result, and performing dynamic mixed-mode traffic control on the call request based on the rate limiting rule to obtain the traffic control result, including: Based on the authorization command that has passed the authentication, extract the application identifier and request interface address of the caller to obtain the corresponding rate limiting rules; The traffic control results are obtained by dynamically mixing the traffic of the call requests based on the rate limiting rules.

5. The open application programming interface gateway management method according to claim 4, characterized in that, The step involves extracting the caller's application identifier and request interface address based on the approved permission command in the authentication result to obtain the corresponding rate limiting rules, including: Based on the authorization command that has been verified in the authentication result, extract the application identifier and request interface address of the caller, query the local rule cache, and obtain the first rule version; Compare the first rule version with the second rule version pushed via a long connection to obtain the version status, which includes rule missing, rule delayed, and rule updated. The rate limiting rules are determined based on the version status. The determination process includes: for rule updates, the first rule version is used as the rate limiting rule; for missing rules, a pull request is sent to the rule control center, and the returned rule is used as the rate limiting rule; for rule delays, the first rule version is used as the rate limiting rule for this request and the request is allowed.

6. The open application programming interface gateway management method according to claim 5, characterized in that, The dynamic mixed-mode traffic control of call requests based on rate limiting rules, resulting in traffic control results, includes: Based on the rate limiting rules, using the caller's application identifier and the requested interface address as indexes, we query the number of the first token in the local token bucket and compare it with the number of the second token corresponding to this request. If the number of first tokens is greater than or equal to the number of second tokens, the corresponding tokens are deducted from the local token bucket to generate a flow control result; if the number of first tokens is less than the number of second tokens, a batch token request is initiated to the distributed token bucket, the requested tokens are added to the local token bucket, and the corresponding tokens are deducted from the local token bucket to generate a flow control result.

7. The open application programming interface gateway management method according to claim 1, characterized in that, In response to the forwarding instruction allowed in the flow control result, the call request is forwarded to the corresponding backend service. During the forwarding process, the running status data of the backend service is monitored in real time. Based on the running status data and preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal, including: In response to the forwarding instruction that is allowed in the flow control result, the target instance is selected and the call request is forwarded to the corresponding backend service; During the forwarding process, the running status data of the backend service is monitored in real time. Based on the running status data and the preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal.

8. The open application programming interface gateway management method according to claim 7, characterized in that, The process of responding to the forwarding instruction allowed in the flow control result, filtering out the target instance, and forwarding the call request to the corresponding backend service includes: In response to the forwarding instruction that is allowed in the flow control result, a matching subset of instances is filtered from the instance list, and the target instance is filtered from the instance subset according to the application identifier; The call request is forwarded to the target instance, and the forwarding status information is recorded.

9. The open application programming interface gateway management method according to claim 8, characterized in that, The process of real-time monitoring of the backend service's operational status data during forwarding, and performing circuit breaker analysis based on the operational status data and preset business semantic rules to obtain circuit breaker control signals, includes: During the forwarding process, the running status data of the backend service is monitored and parsed in real time to obtain the processing result code. The processing result code is then matched against a preset business semantic rule library to obtain an exception marker. Based on the anomaly markers, an anomaly score is calculated using a preset anomaly analysis model; Based on the anomaly score and preset business semantic rules, circuit breaker analysis is performed to obtain the circuit breaker control signal; The circuit breaker analysis process includes: if the current state is closed and the anomaly score is greater than or equal to the preset circuit breaker threshold, the trigger state transitions to the open state and generates a circuit breaker open signal to cut off the service request; if the current state is open and the difference between the current time and the circuit breaker start time is greater than the preset cooling time, the trigger state transitions to the half-open state; if the current state is half-open and the anomaly score is less than the circuit breaker threshold, the trigger state transitions to the closed state.

10. An open application programming interface (API) gateway management system, characterized in that: The method for implementing the open application programming interface gateway management method as described in any one of claims 1 to 9 includes: The authentication analysis module responds to received API call requests, extracts the caller's identity information and request context parameters, and performs dynamic authentication on the call request based on a preset dynamic permission policy library to obtain the authentication result. The flow control module obtains the corresponding rate limiting rules based on the pass-through instructions verified in the authentication results, and performs dynamic mixed-mode flow control on the call request based on the rate limiting rules to obtain the flow control result; The circuit breaker control module, in response to the forwarding instruction that allows passage in the flow control result, forwards the call request to the corresponding backend service, and monitors the running status data of the backend service in real time during the forwarding process. Based on the running status data and preset business semantic rules, it performs circuit breaker analysis to obtain the circuit breaker control signal. The interface management module executes corresponding request processing actions based on the circuit breaker control signal, and collects full-link observable data such as call chain tracing data and network performance data in real time throughout the entire lifecycle of request processing to manage interface calls.

Images