Multi-dimensional traffic grayscale routing method and system based on traffic white list

Abstract

The invention provides a multi-dimensional traffic grayscale routing method and system based on a traffic white list, and belongs to the technical field of data processing, and the method comprises the steps: receiving client request data containing a user identifier, channel information and at least one custom scene attribute; performing legality verification on the user identifier, the channel information and the custom scene attribute; matching the request data passing the verification with a preset multi-dimensional white list rule, the multi-dimensional white list rule at least comprising a user white list, a channel white list and at least one extension type white list, and the white lists of different dimensions have priorities; determining a target service version according to the matching result and the priority; and executing a routing decision based on the determined target service version, and forwarding the request data to the corresponding server, thereby realizing accurate identification and controllable distribution of the gray traffic.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a multi-dimensional traffic grayscale routing method and system based on traffic whitelists. Background Technology

[0002] With the widespread adoption of microservice architecture and the deepening of digital transformation, modern enterprises' business systems are becoming increasingly complex, generally facing challenges such as parallel operation in multiple environments, rapid iteration of business versions, and differentiated service requirements. Against this backdrop, the API gateway, as a key entry point component of microservice architecture, has become crucial in terms of its traffic routing capabilities, especially its canary routing capabilities for smooth upgrades and functional verification.

[0003] Currently, the mainstream technical solutions for implementing canary traffic routing in the industry mainly include the following categories: First, percentage-based random traffic allocation schemes, which generate random numbers and compare them with preset percentage thresholds to guide traffic to different service versions according to probability. Second, request feature-based rule routing schemes, which extract specific information from requests (such as IP address and User-Agent) and configure corresponding rule engines to achieve condition-based routing. Third, traffic allocation schemes based on A / B testing frameworks, which hash and bucket user identifiers to assign users to different experimental groups for comparative effect analysis.

[0004] However, these existing technical solutions still have many limitations in practice. First, the granularity of traffic control is coarse, and random allocation cannot ensure that requests from specific users or test groups are stably and accurately routed to the target version, affecting the accuracy of testing and the core user experience. Summary of the Invention

[0005] This application provides a multi-dimensional traffic grayscale routing method and related apparatus based on traffic whitelists to improve the above-mentioned problems.

[0006] To achieve the above objectives, this application adopts the following technical solution:

[0007] Firstly, this application proposes a multi-dimensional traffic gray-scale routing method based on a traffic whitelist, including:

[0008] Receive client request data, which includes user identifier, channel information, and at least one custom scenario attribute;

[0009] Perform legality checks on user identifiers, channel information, and custom scenario attributes;

[0010] The verified request data is matched with the preset multi-dimensional whitelist rules. The multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, and there is a priority among the user whitelist, channel whitelist, and extended whitelist.

[0011] Determine the target service version based on the matching results and priorities;

[0012] Based on the determined target service version, a routing decision is made and the requested data is forwarded to the corresponding server.

[0013] In conjunction with the first aspect, optionally, the system receives client request data, which includes user identifier, channel information, and at least one custom scenario attribute, including:

[0014] The user identifier is determined based on the token or session information in the request data;

[0015] The channel information is determined based on the user agent field or the unique channel identifier in the request header;

[0016] Custom scene attributes are determined by extracting parameters related to the preset scene from the request data using a plug-in approach.

[0017] In conjunction with the first aspect, optionally, the legitimacy of user identifiers, channel information, and custom scenario attributes may be verified, including:

[0018] Verify the user's identity based on the user's identity information;

[0019] Permissions are determined based on the user's user level and user type;

[0020] The sliding window algorithm is used to limit the rate of request data; the user identity verification includes dual verification, that is, parsing and verifying the user token and verifying the authorization based on OAuth2.0.

[0021] Permission determination includes setting differentiated routing permissions based on user level and implementing hierarchical routing authorization by associating permission codes with the user table;

[0022] Rate limiting control includes setting differentiated rate limiting thresholds based on user level and performing a tiered processing flow for requests exceeding the limit.

[0023] In conjunction with the first aspect, optionally, the verified request data is matched against pre-defined multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, and the user whitelist, channel whitelist, and extended whitelist are prioritized, including:

[0024] The requested data is matched against the user whitelist, the channel whitelist, and at least one extended class whitelist in a fixed order.

[0025] If a matching conflict occurs with the user whitelist, channel whitelist, or at least one extended whitelist, arbitration will be conducted based on priority.

[0026] In conjunction with the first aspect, optionally, if a matching conflict occurs with the user whitelist, channel whitelist, and at least one extended class whitelist, arbitration shall be conducted based on priority, including:

[0027] When the requested data simultaneously satisfies multiple whitelist rules of different dimensions, and the routing targets indicated by the whitelist rules are mutually exclusive, the rule corresponding to the dimension with the highest priority is selected for output based on the fixed priority order among the dimensions.

[0028] In conjunction with the first aspect, optionally, the verified request data is matched against pre-defined multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, and prioritization is established among the user whitelist, channel whitelist, and extended whitelist, the following are also included:

[0029] Check if the local cache contains whitelist data associated with the requested data;

[0030] If the local cache contains relevant whitelist data, then the whitelist data in the local cache will be used directly for matching.

[0031] If the local cache does not contain the associated whitelist data, the distributed cache or database is queried, and the query results are synchronized to the local cache. The caching system is a three-level intelligent caching architecture, including a local cache, a distributed cache, and a database.

[0032] The system preloads the whitelist data of high-frequency users to the local cache when it starts up;

[0033] An incremental synchronization mechanism is used to update cached data, and MD5 hash verification is performed periodically to ensure data consistency.

[0034] When a cache query fails or data is inconsistent, a self-healing degradation mechanism is triggered, automatically switching to a fallback routing strategy.

[0035] In conjunction with the first aspect, optionally, after performing routing decisions and forwarding request data to the corresponding server based on the determined target service version, the method further includes:

[0036] During the process of forwarding request data to the corresponding server, if an anomaly is detected in the target service, the traffic is switched to the pre-configured backup server; if an anomaly is detected in the dependent service, fallback data in the local cache is used to perform degraded routing.

[0037] If the network is in a partitioned state, routing is performed based on the local node cache, and data consistency is restored through an incremental synchronization mechanism after the network recovers.

[0038] The anomalies include gray-scale service anomalies, dependent service anomalies, and network partition anomalies, and corresponding anomaly monitoring indicators and switching thresholds are set.

[0039] In conjunction with the first aspect, optionally, after performing routing decisions and forwarding request data to the corresponding server based on the determined target service version, the method further includes:

[0040] Acquire monitoring data of the requested data throughout the entire routing chain, and dynamically adjust the routing strategy based on preset indicator thresholds. The monitoring data includes at least routing success rate, response time, and system resource utilization. The routing strategy includes:

[0041] When the success rate of a route corresponding to any server falls below the first threshold, the weight of the corresponding route is automatically reduced.

[0042] When the overall throughput exceeds the second threshold, enable accelerated routing for high-frequency users.

[0043] Based on the same inventive concept, in a second aspect, this application also proposes a multi-dimensional traffic gray-scale routing system based on a traffic whitelist, wherein the multi-dimensional traffic gray-scale routing system based on a traffic whitelist is configured as follows:

[0044] Receive client request data, which includes user identifier, channel information, and at least one custom scenario attribute;

[0045] Perform legality checks on user identifiers, channel information, and custom scenario attributes;

[0046] The verified request data is matched with the preset multi-dimensional whitelist rules. The multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, and there is a priority among the user whitelist, channel whitelist, and extended whitelist.

[0047] Determine the target service version based on the matching results and priorities;

[0048] Based on the determined target service version, perform routing decisions and forward the request data to the corresponding server;

[0049] The system also includes an intelligent caching module, which is used to implement a three-level caching architecture, high-frequency data preloading, incremental synchronization and self-healing degradation;

[0050] The system also includes a unified exception handling module to support gray-scale service exception switching, dependent service degradation and network partition self-healing;

[0051] The system also includes a full-link monitoring and dynamic optimization module, which is used to collect monitoring data and dynamically adjust routing strategies based on thresholds.

[0052] In conjunction with the second aspect, optionally, the system is configured as follows:

[0053] The client requests data, which includes user identifier, channel information, and at least one custom scenario attribute, including:

[0054] The user identifier is determined based on the token or session information in the request data;

[0055] The channel information is determined based on the user agent field or the unique channel identifier in the request header;

[0056] Custom scene attributes are determined by extracting parameters related to the preset scene from the request data using a plug-in approach.

[0057] In conjunction with the second aspect, optionally, the system is configured as follows:

[0058] Perform validity checks on user identifiers, channel information, and custom scenario attributes, including:

[0059] Verify the user's identity based on the user's identity information;

[0060] Permissions are determined based on the user's user level and user type;

[0061] Rate limiting is implemented based on the sliding window algorithm for request data.

[0062] In conjunction with the second aspect, optionally, the system is configured as follows:

[0063] The validated request data is matched against pre-defined multi-dimensional whitelist rules. These rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, with priorities assigned among these rules:

[0064] The requested data is matched against the user whitelist, the channel whitelist, and at least one extended class whitelist in a fixed order.

[0065] If a matching conflict occurs with the user whitelist, channel whitelist, or at least one extended whitelist, arbitration will be conducted based on priority.

[0066] In conjunction with the second aspect, optionally, the system is configured as follows:

[0067] If a match conflict occurs with the user whitelist, channel whitelist, or at least one extended whitelist, arbitration will be conducted based on priority, including:

[0068] When the requested data simultaneously satisfies multiple whitelist rules of different dimensions, and the routing targets indicated by the whitelist rules are mutually exclusive, the rule corresponding to the dimension with the highest priority is selected for output based on the fixed priority order among the dimensions.

[0069] In conjunction with the second aspect, optionally, the system is configured as follows:

[0070] The validated request data is matched against pre-defined multi-dimensional whitelist rules. These rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, with priorities assigned among the user whitelist, channel whitelist, and extended whitelist. The system also includes:

[0071] Check if the local cache contains whitelist data associated with the requested data;

[0072] If the local cache contains relevant whitelist data, then the whitelist data in the local cache will be used directly for matching.

[0073] If the local cache does not contain the associated whitelist data, then query the distributed cache or database and synchronize the query results to the local cache.

[0074] In conjunction with the second aspect, optionally, the system is configured as follows:

[0075] Based on the determined target service version, after performing routing decisions and forwarding the request data to the corresponding server, the process also includes:

[0076] If an anomaly is detected in the target service during the process of forwarding the request data to the corresponding server, the traffic will be switched to a pre-set backup server.

[0077] In conjunction with the second aspect, optionally, the system is configured as follows:

[0078] Based on the determined target service version, after performing routing decisions and forwarding the request data to the corresponding server, the process also includes:

[0079] Acquire monitoring data of the requested data throughout the entire routing chain, and dynamically adjust the routing strategy based on preset indicator thresholds. The monitoring data includes at least routing success rate, response time, and system resource utilization. The routing strategy includes:

[0080] When the success rate of a route corresponding to any server falls below the first threshold, the weight of the corresponding route is automatically reduced.

[0081] When the overall throughput exceeds the second threshold, enable accelerated routing for high-frequency users.

[0082] A third aspect of this invention provides an electronic device, which includes:

[0083] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor to enable the at least one processor to perform the method proposed in the first aspect of the present invention.

[0084] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method as described in the first aspect of the present invention.

[0085] In summary, the above method has the following technical effects:

[0086] This application proposes a multi-dimensional traffic gray-scale routing method based on a traffic whitelist. The method includes: receiving client request data containing user identifier, channel information, and at least one custom scenario attribute; validating the user identifier, channel information, and custom scenario attribute; matching the validated request data with pre-defined multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended class whitelist, and different dimensions of whitelists are prioritized; determining the target service version based on the matching results and priorities; performing routing decisions based on the determined target service version, and forwarding the request data to the corresponding server. This application proposes a multi-dimensional traffic gray-scale routing method based on a traffic whitelist, achieving accurate identification and controllable distribution of gray-scale traffic. Attached Figure Description

[0087] Figure 1 This is a flowchart illustrating a multi-dimensional traffic grayscale routing method based on a traffic whitelist proposed in an embodiment of this application. Detailed Implementation

[0088] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0089] This application proposes a multi-dimensional traffic grayscale routing method based on a traffic whitelist. Please refer to [link / reference]. Figure 1 The method includes steps S101-S105:

[0090] S101: Receive client request data, which includes user identifier, channel information, and at least one custom scenario attribute.

[0091] Understandably, a traffic gray-scale routing gateway or system receives a complete request from an external client, such as a web browser, mobile application, or third-party service, through a network interface. This received object is the request data. In this embodiment, the request data is a carrier containing the original information needed for routing decisions.

[0092] User identifiers are information that uniquely identifies the request initiator within the system, such as user ID, account name, OpenID, or session token. Channel information identifies the source channel or terminal type of the request; for example, this information may come from the User-Agent field in the request header, a dedicated channel code (such as "iOS_App", "PC_Web"), or a specific entry point identifier. Custom scenario attributes represent dimensional information that is flexibly expanded to adapt to specific business scenarios, such as the current promotional activity ID, the user's geolocation code, and security risk control level tags. Their specific content and format can be defined and expanded according to business needs and are not limited in this application.

[0093] Therefore, specifically, in this embodiment, as a feasible implementation method, the user identifier can be determined based on the token or session information in the request data; the channel information can be determined based on the user agent field or exclusive channel identifier in the request data header; and the custom scene attributes can be determined by extracting parameters related to the preset scene from the request data in a plug-in manner. Of course, other methods can also be used in other embodiments, and are not limited here. The processor chain supports hot-swappable expansion:

[0094] When adding a new processor, it is only necessary to develop a new processor that conforms to the standardized interface and configure its execution order in the database, without modifying the existing processor code.

[0095] S102: Perform legality verification on user identifiers, channel information, and custom scenario attributes.

[0096] Understandably, upon receiving multi-dimensional request data, a preliminary security and compliance review is required. This involves verifying the authenticity, validity, and compliance of the user identifier, channel information, and custom scenario attributes, respectively, to ensure that subsequent routing decisions are based on legitimate and trustworthy requests, thereby guaranteeing the system's security and stability.

[0097] Specifically, user identifiers can be determined based on tokens or session information in the request data, channel information can be determined based on user agent fields or exclusive channel identifiers in the request data header, and custom scene attributes can be determined by extracting parameters related to preset scenarios from the request data in a plug-in manner.

[0098] Of course, in other embodiments, for user identifiers, the system verifies their authenticity and validity, such as checking whether the token has expired, whether the signature is correct, or whether the session is legitimate, to prevent requests with forged or invalid identities from entering the routing process. For channel information, the system verifies whether its format is standardized and whether the source is within the allowed range, such as identifying whether the channel code belongs to a registered legitimate terminal, to block access from unknown or illegal channels. For custom scene attributes, the system verifies whether their values ​​conform to predefined business rules or data formats, such as confirming whether the promotional activity ID exists and whether the geolocation code is valid, to ensure that the scene information is legitimate and can be processed. Specific verification methods are not specifically limited in this embodiment.

[0099] Furthermore, the request data can be rate-limited based on a sliding window algorithm; wherein, the verification of user identity includes dual verification, that is, simultaneously parsing and verifying the user token and verifying authorization based on OAuth2.0;

[0100] Permission determination includes setting differentiated routing permissions based on user level and implementing hierarchical routing authorization by associating permission codes with the user table;

[0101] Rate limiting control includes setting differentiated rate limiting thresholds based on user level and performing a tiered processing flow for requests exceeding the limit.

[0102] S103: Match the verified request data with the preset multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist and at least one extended whitelist, and there is a priority among the user whitelist, channel whitelist and extended whitelist.

[0103] Understandably, to achieve precise traffic targeting, validated request data can be compared and mapped against a pre-defined, structured rule system. The request data is matched against the user whitelist, the channel whitelist, and at least one of the extended class whitelists in a preset order. If the request data simultaneously satisfies multiple whitelist rules across different dimensions, and the routing targets indicated by these whitelist rules are mutually exclusive, then based on priority arbitration, the rule corresponding to the dimension with the highest priority is selected for output. The multi-dimensional whitelist rules support nested configuration of AND / OR / NOT logical operators, and rule changes are synchronized to the gateway node within seconds by monitoring incremental logs in the database.

[0104] In this embodiment, the rule system consists of at least three independent whitelists or rule sets:

[0105] The user whitelist records the specific user identifiers that are allowed to perform special routes (such as directing to new versions);

[0106] The channel whitelist defines the routing strategy that requests from specific channels or platforms should follow.

[0107] And at least one extended whitelist, which represents an additional rule dimension that can be flexibly adapted to business needs, such as a promotional activity whitelist, a geographic location whitelist, or a risk level whitelist.

[0108] Understandably, these whitelist rules across different dimensions are not equal and parallel; they have different priorities. When multiple dimensions of requested data, such as user ID, channel type, and associated activity, simultaneously match different whitelist rules, the system examines these rules according to a preset, fixed hierarchy, such as user > channel > extension, providing a basis for adjudicating potential rule conflicts. It supports nested AND / OR / NOT logical operations for multi-dimensional rule combinations; and achieves second-level effectiveness without requiring a service restart by monitoring incremental logs in the database to synchronize rule changes.

[0109] Specifically, in this embodiment, step S103 may include the following steps:

[0110] S1031: Match the requested data with the user whitelist, the channel whitelist, and at least one extended class whitelist in a fixed order.

[0111] Understandably, regardless of changes in the request content, the system follows the same standard check sequence, avoiding uncertainty in results that might result from unclear matching order. Secondly, this sequential matching method, in its logical structure, prepares for and complements the subsequent priority arbitration mechanism that may be triggered (although this step does not involve the arbitration action itself).

[0112] S1032: If a matching conflict occurs with the user whitelist, channel whitelist, and at least one extended class whitelist, arbitration shall be conducted based on the order of priority.

[0113] Understandably, when a matching conflict occurs after the requested data is matched against the user whitelist, channel whitelist, and extended whitelist in sequence, the system will initiate an arbitration procedure. It should be noted that a matching conflict specifically refers to a situation where the same requested data successfully matches in whitelists of different dimensions, but the subsequent routing targets or processing actions indicated by these matching results are mutually exclusive and cannot coexist. For example, the user whitelist indicates routing to version A, while the channel whitelist indicates routing to version B.

[0114] When this conflict condition is met, the system will initiate an arbitration procedure. The arbitration is based on a priority order, that is, a predefined fixed hierarchy between different whitelist dimensions, such as user whitelist > channel whitelist > extended category whitelist. The system will review and adjudicate all conflicting matching results according to this priority order to determine which dimension's matching result will ultimately be adopted as the valid output.

[0115] Understandably, when requested data simultaneously satisfies multiple whitelist rules across different dimensions, and the routing targets indicated by these whitelist rules are mutually exclusive, the rule corresponding to the highest-priority dimension is selected for output based on a fixed priority order among the dimensions. Selecting the rule corresponding to the highest-priority dimension means iterating through all conflicting rules, identifying the one with the highest priority in its respective dimension, and unconditionally adopting the routing target indicated by that rule, while ignoring rules from other lower-priority dimensions.

[0116] S104: Determine the target service version based on the matching results and priority.

[0117] Understandably, if the matching result indicates that the requested data matches only one dimension's whitelist rule, or matches multiple dimensions simultaneously but the routing targets indicated by their rules are consistent, then this unambiguous matching result will be used as the target service version. If the matching result indicates a rule conflict, a preset priority order will be invoked to adjudicate the conflicting matching results, and the service version indicated by the rule corresponding to the dimension with the highest priority will ultimately be determined.

[0118] S105: Based on the determined target service version, perform routing decisions and forward the request data to the corresponding server.

[0119] The routing decision is implemented through a dynamically orchestrated processor chain, which includes at least one processor. Each processor implements a standardized interface, which includes an initialization method, an execution method, and a destruction method.

[0120] The processor types include environment matching processors, load balancing processors, and exception circuit breaker processors, and the execution order of the processor chain is dynamically defined by database configuration information.

[0121] As one implementation, prior to this, the format identifier field in the request header is parsed using a uniform response format adapter;

[0122] Based on the format identifier field, the response data of the target service version is converted into a preset target format, which includes JSON, XML and custom formats; wherein, the format conversion rules are defined through a field mapping table configured in the database, and adding a new format adaptation does not require modification of the gateway core code.

[0123] This is understandable. In this embodiment, when performing routing decisions, the decision is not a reselection, but rather the resolution of operable network path information based on the determined target service version. Typically, this involves service discovery and instance selection. For example, this might involve querying a list of all healthy server instances belonging to the target service version from the service registry, and possibly selecting a specific server address based on load balancing strategies such as round-robin or minimum connection count. Then, the original client request data is sent through the internal network to the target server address selected in the previous step. This signifies that the request has successfully completed canary routing allocation, leaving the gateway and entering the downstream business processing system.

[0124] Optionally, to minimize high-latency data source queries and thus accelerate overall routing decisions, some implementations may include the following steps before matching validated request data with pre-defined multi-dimensional whitelist rules:

[0125] S201: Check if the local cache stores whitelist data associated with the requested data.

[0126] Specifically, the local cache refers to high-speed storage located in the same server memory as the gateway process, used to store recently used or frequently used whitelist data fragments. The system extracts key identifiers (such as user ID and channel ID) from the request data and combines them into a query key to retrieve whether the corresponding complete whitelist rule set has been pre-stored in the local cache.

[0127] S202: If there is associated whitelist data in the local cache, then the whitelist data in the local cache is used directly for matching.

[0128] Understandably, if the local cache is hit, the process enters an efficient path. The existing whitelist data in the cache is used directly for subsequent matching. This approach bypasses network calls to remote data sources, effectively reducing data retrieval latency.

[0129] S203: If the local cache does not contain the associated whitelist data, query the distributed cache or database and synchronize the query results to the local cache.

[0130] Understandably, if the local cache is not hit, the process switches to a backup path. This can involve querying the distributed cache or the database sequentially. Typically, the faster distributed cache is queried first; if that also fails, the database, acting as the authoritative data source, is ultimately queried. Regardless of which backup data source yields the result, the system will synchronize the query results to the local cache. This serves two purposes: firstly, to immediately satisfy the matching requirement of the current request; and secondly, to pre-warm the data in the local cache so that subsequent requests with the same characteristics can directly hit the local cache.

[0131] Understandably, the caching system is a three-tier intelligent caching architecture, including local caching, distributed caching, and a database;

[0132] The system preloads the whitelist data of high-frequency users to the local cache when it starts up;

[0133] An incremental synchronization mechanism is used to update cached data, and MD5 hash verification is performed periodically to ensure data consistency.

[0134] When a cache query fails or data is inconsistent, a self-healing degradation mechanism is triggered, automatically switching to a fallback routing strategy.

[0135] Optionally, in some implementations, if an anomaly is detected in the target service during the forwarding of request data to the corresponding server, traffic can be switched to a pre-configured backup server. If an anomaly is detected in a dependent service, fallback data in the local cache can be used to perform degraded routing.

[0136] If the network is in a partitioned state, routing is performed based on the local node cache, and data consistency is restored through an incremental synchronization mechanism after the network recovers.

[0137] The anomalies include gray-scale service anomalies, dependent service anomalies, and network partition anomalies, and corresponding anomaly monitoring indicators and switching thresholds are set.

[0138] Understandably, when the monitoring system detects an anomaly in the target service—for example, multiple consecutive request timeouts or a sudden spike in the error rate—this mechanism will immediately trigger the pre-defined failover logic. For requests currently being processed and detected as failed, as well as all subsequent new requests that should have been routed to the faulty service, the gateway will automatically redirect their forwarding paths to another functionally equivalent backup server. This ensures business continuity and prevents widespread user request failures due to backend service issues.

[0139] To automatically adjust its behavior based on real-time operational status to achieve optimal performance, optionally, in some implementations, monitoring data of the requested data throughout the entire routing chain can be acquired, and the routing strategy can be dynamically adjusted according to preset indicator thresholds. The monitoring data includes at least routing success rate, response time, and system resource utilization. The routing strategy includes:

[0140] When the success rate of a route corresponding to any server falls below the first threshold, the weight of the corresponding route is automatically reduced.

[0141] When the overall throughput exceeds the second threshold, enable accelerated routing for high-frequency users.

[0142] Understandably, in this embodiment, routing success rate directly reflects the final business effect of routing decisions and service calls. Response time is a key performance indicator used to measure system processing efficiency and user experience. System resource utilization reflects the load health of the gateway itself and downstream services.

[0143] Understandably, when the quality of a target service version or cluster deteriorates, the system automatically reduces the proportion of traffic allocated to it and directs more traffic to healthier services, thereby achieving automatic fault isolation and improving the overall success rate.

[0144] When the overall throughput exceeds the second threshold, under high load pressure, the system prioritizes the experience of core users, i.e., high-frequency users, by enabling more efficient paths for them (such as faster cached routes and better implementations) to ensure that critical business is not affected by the overall traffic surge and to achieve intelligent allocation of resources.

[0145] This application proposes a multi-dimensional traffic gray-scale routing method based on a traffic whitelist. The method includes: receiving client request data containing user identifier, channel information, and at least one custom scenario attribute; validating the user identifier, channel information, and custom scenario attribute; matching the validated request data with pre-defined multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended class whitelist, and different dimensions of whitelists are prioritized; determining the target service version based on the matching results and priorities; performing routing decisions based on the determined target service version, and forwarding the request data to the corresponding server. This application proposes a multi-dimensional traffic gray-scale routing method based on a traffic whitelist, achieving accurate identification and controllable distribution of gray-scale traffic.

[0146] Based on the same inventive concept, this application proposes a multi-dimensional traffic gray-scale routing system based on a traffic whitelist, which is configured as follows:

[0147] Receive client request data, which includes user identifier, channel information, and at least one custom scenario attribute;

[0148] Perform legality checks on user identifiers, channel information, and custom scenario attributes;

[0149] The verified request data is matched with the preset multi-dimensional whitelist rules. The multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, and there is a priority among the user whitelist, channel whitelist, and extended whitelist.

[0150] Determine the target service version based on the matching results and priorities;

[0151] Based on the determined target service version, perform routing decisions and forward the request data to the corresponding server;

[0152] The system also includes an intelligent caching module, which is used to implement a three-level caching architecture, high-frequency data preloading, incremental synchronization and self-healing degradation;

[0153] The system also includes a unified exception handling module to support gray-scale service exception switching, dependent service degradation and network partition self-healing;

[0154] The system also includes a full-link monitoring and dynamic optimization module, which is used to collect monitoring data and dynamically adjust routing strategies based on thresholds.

[0155] Optionally, the system is configured as follows:

[0156] The client requests data, which includes user identifier, channel information, and at least one custom scenario attribute, including:

[0157] The user identifier is determined based on the token or session information in the request data;

[0158] The channel information is determined based on the user agent field or the unique channel identifier in the request header;

[0159] Custom scene attributes are determined by extracting parameters related to the preset scene from the request data using a plug-in approach.

[0160] Optionally, the system is configured as follows:

[0161] Perform validity checks on user identifiers, channel information, and custom scenario attributes, including:

[0162] Verify the user's identity based on the user's identity information;

[0163] Permissions are determined based on the user's user level and user type;

[0164] Rate limiting is implemented based on the sliding window algorithm for request data.

[0165] Optionally, the system is configured as follows:

[0166] The validated request data is matched against pre-defined multi-dimensional whitelist rules. These rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, with priorities assigned among these rules:

[0167] The requested data is matched against the user whitelist, the channel whitelist, and at least one extended class whitelist in a fixed order.

[0168] If a matching conflict occurs with the user whitelist, channel whitelist, or at least one extended whitelist, arbitration will be conducted based on priority.

[0169] Optionally, the system is configured as follows:

[0170] If a match conflict occurs with the user whitelist, channel whitelist, or at least one extended whitelist, arbitration will be conducted based on priority, including:

[0171] When the requested data simultaneously satisfies multiple whitelist rules of different dimensions, and the routing targets indicated by the whitelist rules are mutually exclusive, the rule corresponding to the dimension with the highest priority is selected for output based on the fixed priority order among the dimensions.

[0172] Optionally, the system is configured as follows:

[0173] The validated request data is matched against pre-defined multi-dimensional whitelist rules. These rules include at least a user whitelist, a channel whitelist, and at least one extended whitelist, with priorities assigned among the user whitelist, channel whitelist, and extended whitelist. The system also includes:

[0174] Check if the local cache contains whitelist data associated with the requested data;

[0175] If the local cache contains relevant whitelist data, then the whitelist data in the local cache will be used directly for matching.

[0176] If the local cache does not contain the associated whitelist data, then query the distributed cache or database and synchronize the query results to the local cache.

[0177] Optionally, the system is configured as follows:

[0178] Based on the determined target service version, after performing routing decisions and forwarding the request data to the corresponding server, the process also includes:

[0179] If an anomaly is detected in the target service during the process of forwarding the request data to the corresponding server, the traffic will be switched to a pre-set backup server.

[0180] Optionally, the system is configured as follows:

[0181] Based on the determined target service version, after performing routing decisions and forwarding the request data to the corresponding server, the process also includes:

[0182] Acquire monitoring data of the requested data throughout the entire routing chain, and dynamically adjust the routing strategy based on preset indicator thresholds. The monitoring data includes at least routing success rate, response time, and system resource utilization. The routing strategy includes:

[0183] When the success rate of a route corresponding to any server falls below the first threshold, the weight of the corresponding route is automatically reduced.

[0184] When the overall throughput exceeds the second threshold, enable accelerated routing for high-frequency users.

[0185] This application proposes a multi-dimensional traffic gray-scale routing system based on a traffic whitelist. The system is configured to: receive client request data containing user identifier, channel information, and at least one custom scenario attribute; perform legality verification on the user identifier, channel information, and custom scenario attribute; match the verified request data with pre-defined multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules include at least a user whitelist, a channel whitelist, and at least one extended class whitelist, and different dimensions of whitelists are prioritized; determine the target service version based on the matching results and priorities; perform routing decisions based on the determined target service version, and forward the request data to the corresponding server. This application proposes a multi-dimensional traffic gray-scale routing system based on a traffic whitelist, which achieves accurate identification and controllable distribution of gray-scale traffic.

[0186] Based on the same inventive concept, embodiments of this application also propose an electronic device, which includes:

[0187] At least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the automatic overheat protection method based on the universal testing machine according to the embodiments of this application.

[0188] In addition, to achieve the above objectives, embodiments of this application also propose a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the automatic overheat protection method based on a universal testing machine according to embodiments of this application.

[0189] The following is a detailed introduction to the various components of the electronic device:

[0190] In this context, the processor is the control center of the electronic device. It can be a single processor or a collective term for multiple processing elements. For example, a processor can be one or more central processing units (CPUs), an application-specific integrated circuit (ASIC), or one or more integrated circuits configured to implement embodiments of the present invention, such as one or more digital signal processors (DSPs), or one or more field-programmable gate arrays (FPGAs).

[0191] Alternatively, the processor can perform various functions of the electronic device by running or executing software programs stored in memory, and by calling data stored in memory.

[0192] The memory is used to store the software program that executes the solution of the present invention, and the execution is controlled by the processor. The specific implementation method can be referred to the above method embodiment, which will not be repeated here.

[0193] Optionally, the memory can be read-only memory (ROM) or other types of static storage devices capable of storing static information and instructions, random access memory (RAM) or other types of dynamic storage devices capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), compact disc read-only memory (CD-ROM) or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto. The memory can be integrated with the processor or exist independently and coupled to the processor through the interface circuit of the electronic device; the embodiments of the present invention do not specifically limit this.

[0194] A transceiver is used to communicate with network devices or with terminal devices.

[0195] Optionally, the transceiver may include a receiver and a transmitter. The receiver is used to implement the receiving function, and the transmitter is used to implement the sending function.

[0196] Optionally, the transceiver can be integrated with the processor or exist independently and coupled to the processor through the router's interface circuit. This embodiment of the invention does not specifically limit this.

[0197] Furthermore, the technical effects of the electronic device can be referred to the technical effects of the data transmission method in the above method embodiments, and will not be repeated here.

[0198] It should be understood that the processor in the embodiments of the present invention can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.

[0199] It should also be understood that the memory in the embodiments of the present invention can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. The non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. The volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of random access memory (RAM) are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM).

[0200] The above embodiments can be implemented, in whole or in part, by software, hardware (such as circuits), firmware, or any other combination thereof. When implemented using software, the above embodiments can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions or computer programs. When the computer instructions or computer programs are loaded or executed on a computer, all or part of the flow or function according to the embodiments of the present invention is generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. Computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., infrared, wireless, microwave, etc.) means. A computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more sets of available media. Available media can be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media. Semiconductor media can be solid-state drives.

[0201] It should be understood that the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. A and B can be singular or plural. Additionally, the character " / " in this article generally indicates an "or" relationship between the preceding and following related objects, but it can also represent an "and / or" relationship. Please refer to the context for a more accurate understanding.

[0202] In this invention, "at least one" means one or more, and "more than one" means two or more. "At least one of the following" or similar expressions refer to any combination of these items, including any combination of a single item or a plurality of items. For example, at least one of a, b, or c can represent: a, b, c, ab, ac, bc, or abc, where a, b, and c can be a single item or multiple items.

[0203] It should be understood that, in various embodiments of the present invention, the order of the above-mentioned process numbers does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0204] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

Claims

1. A method for multi-dimensional traffic gray route based on traffic white list, characterized in that, The method comprises the following steps: receiving client request data, the request data comprising a user identifier, channel information and at least one custom scenario attribute; verifying the legitimacy of the user identifier, the channel information and the custom scenario attribute; matching the request data that passes the verification with preset multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules comprise at least a user whitelist, a channel whitelist and at least one extended whitelist, and the user whitelist, the channel whitelist and the extended whitelist are provided with priorities; determining a target service version according to the matching result and the priorities; performing routing decision and forwarding the request data to a corresponding server based on the determined target service version; wherein the routing decision is implemented through a dynamically arranged processor chain, the processor chain comprising at least one processor, each processor implementing a standardized interface comprising an initialization method, an execution method and a destruction method; the processor types comprise an environment matching processor, a load balancing processor and an exception fuse processor, and the execution order of the processor chain is dynamically defined by database configuration information.

2. The multi-dimensional traffic gray routing method based on traffic whitelist according to claim 1, wherein receiving client request data, the request data comprising a user identifier, channel information and at least one custom scenario attribute, comprising: determining the user identifier based on a token or session information in the request data; determining the channel information based on a user agent field or a dedicated channel identifier in the request data header; determining the custom scenario attribute based on the parameters related to the preset scenario extracted from the request data in a plug-in manner. 3.The multi-dimensional traffic gray route method based on traffic white list according to claim 1, characterized in that, verifying the legitimacy of the user identifier, the channel information and the custom scenario attribute, comprising: verifying the identity of the user based on the user's identity information; determining the user's authority based on the user's user level and user type; controlling the flow of the request data based on a sliding window algorithm; wherein the verification of the user's identity comprises double verification, i.e. simultaneous analysis and verification of the user token and authorization verification based on OAuth2.0; the authority determination comprises setting differentiated routing authority according to the user level and realizing hierarchical routing authorization through the association of the user table with the authority code; the flow control comprises setting differentiated flow threshold values according to the user level and performing a step-by-step processing procedure for the over-limit request.

4. The multi-dimensional traffic gray route method based on traffic white list according to claim 1, characterized in that, matching the request data that passes the verification with preset multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules comprise at least a user whitelist, a channel whitelist and at least one extended whitelist, and the user whitelist, the channel whitelist and the extended whitelist are provided with priorities, comprising: matching the request data with the user whitelist, the channel whitelist and at least one extended whitelist in a fixed order; if a matching conflict occurs between the user whitelist, the channel whitelist and at least one extended whitelist, arbitrating based on the order of the priorities.

5. The multi-dimensional traffic gray route method based on traffic white list according to claim 4, characterized in that, If a match conflict occurs among the user whitelist, the channel whitelist, and at least one of the extension class whitelists, arbitration is performed based on the order of the priorities, including: When the request data satisfies multiple different dimension whitelist rules at the same time, and the routing targets indicated by the whitelist rules are mutually exclusive, the rule corresponding to the highest priority dimension is selected based on the fixed order of the priorities between the dimensions.

6. The multi-dimensional traffic gray route method based on traffic white list according to any one of claims 1-5, characterized in that, The request data that passes the verification is matched with preset multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules at least include a user whitelist, a channel whitelist, and at least one extension class whitelist, and the user whitelist, the channel whitelist, and the extension class whitelist are provided with priorities in advance, and further including: Querying whether the local cache stores whitelist data associated with the request data; If the local cache has the associated whitelist data, the whitelist data in the local cache is directly used for matching; If the local cache does not have the associated whitelist data, a distributed cache or a database is queried, and the query result is synchronized to the local cache; wherein the cache system is a three-level intelligent cache architecture, including a local cache, a distributed cache, and a database; High-frequency user whitelist data is preloaded into the local cache when the system starts; Incremental synchronization mechanism is used to update cache data, and MD5 hash check is performed regularly to ensure data consistency; When cache query is abnormal or data is inconsistent, a self-healing degradation mechanism is triggered to automatically switch to a fallback routing strategy.

7. The multi-dimensional traffic gray route method based on traffic white list according to claim 1, characterized in that, After determining the target service version, performing routing decision and forwarding the request data to the corresponding server, further including: During the process of forwarding the request data to the corresponding server, if a target service exception is detected, the traffic is switched to a preset backup server; If a dependent service exception is detected, fallback data in the local cache is used to perform degraded routing; If in a network partition state, routing is performed based on the local node cache, and data consistency is repaired through an incremental synchronization mechanism after network recovery; The exceptions include gray service exceptions, dependent service exceptions, and network partition exceptions, and corresponding exception monitoring indicators and switching thresholds are provided. 8.The multi-dimensional traffic gray route method based on traffic white list according to claim 1, characterized in that, After determining the target service version, performing routing decision and forwarding the request data to the corresponding server, further including: Obtaining monitoring data of the request data in the routing full link, and dynamically adjusting the routing strategy according to the preset index threshold, the monitoring data at least including routing success rate, response time, and system resource utilization, wherein the routing strategy includes: When the routing success rate of any of the servers is lower than a first threshold, the corresponding routing weight is automatically reduced; When the overall throughput is higher than a second threshold, an accelerated routing is enabled for high-frequency users. 9.A multi-dimensional traffic gray route system based on traffic white list, characterized in that, The multi-dimensional traffic gray routing system based on traffic whitelist is configured to: Receive client request data, the request data including user identification, channel information, and at least one custom scenario attribute; The user identifier, the channel information and the custom scene attribute are subjected to legality verification; The request data that passes the verification is matched with preset multi-dimensional whitelist rules, wherein the multi-dimensional whitelist rules at least include a user whitelist, a channel whitelist and at least one extended class whitelist, and the user whitelist, the channel whitelist and the extended class whitelist are provided with priorities; According to the matching result and the priorities, a target service version is determined; Based on the determined target service version, a routing decision is made and the request data is forwarded to a corresponding server; The system further includes an intelligent cache module for implementing a three-level cache architecture, high-frequency data preloading, incremental synchronization and self-recovery degradation; The system further includes a unified exception handling module for supporting gray service exception switching, dependent service degradation and network partition self-recovery; The system further includes a full-link monitoring and dynamic optimization module for collecting monitoring data and dynamically adjusting routing strategies based on thresholds.

10. An electronic device, comprising: Comprise: At least one processor; And the memory connected in communication with the at least one processor; Wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the multi-dimensional traffic gray routing method based on traffic whitelist of any one of claims 1-8.

Images