Method and system for fine flow control of interconnection and intercommunication of charging platforms based on operation identification

Abstract

The application discloses a charging platform interconnection fine flow limiting method and system based on operation identification, comprising the following steps: receiving an interconnection request sent by a first charging platform to a second charging platform; analyzing the request to obtain the operation identification of the first charging platform initiating the request; checking whether the operation identification exists in a preset legal identification set, and if not, rejecting the request; if the operation identification is legal, generating a unique flow limiting key value according to at least the operation identification, the uniform resource identifier of the request and current time window information. Advantage: the same interface request of different platform operators is independently counted, the high-frequency request initiated by a malicious platform only triggers self-flow limiting and does not affect the normal business request of a legal cooperative platform, thereby avoiding the "misuse" problem caused by interface-level fusing, and significantly improving the business fairness and service availability in the charging platform interconnection scene.

Description

Technical Field

[0001] This invention relates to the field of new energy charging technology, and in particular to a method and system for dynamically freezing the amount of charging piles for vehicle fleets. Background Technology

[0002] With the rapid development of the new energy vehicle industry, charging piles, as critical infrastructure, need to be connected to charging platforms for network management, supporting users to complete functions such as scanning codes for charging, payment settlement, and order inquiry through mobile applications or mini-programs. Since charging piles are typically embedded systems, their hardware resources (such as computing power, storage, and network bandwidth) are limited, generally allowing only a single charging platform to be directly connected. To maximize resource utilization, charging platforms need to be interconnected, meaning that platform A, directly connected to the charging pile, can receive requests from other platforms B and forward them to the charging pile to complete operations such as charging control and status inquiry.

[0003] In interconnected scenarios, requests between platforms frequently involve resource-intensive operations, such as verifying account balances, querying real-time order data, and updating charging status. These operations often require frequent locking and unlocking of database row locks. Furthermore, the concurrency processing capabilities of embedded charging pile systems are relatively weak. If request traffic is not effectively managed, it can easily lead to database overload or even system crashes.

[0004] Existing technologies for rate limiting of service requests mainly include IP-based circuit breaking and interface-based circuit breaking. However, these solutions have significant drawbacks in scenarios involving interconnected charging platforms:

[0005] IP-based circuit breaker rate limiting solutions face the challenge of dynamically changing request initiators, especially when Platform B employs a distributed cluster deployment, leading to frequent IP address changes. Furthermore, in a microservice architecture, the original IP information is easily lost after multiple layers of relay. Additionally, the frequency of "charging start / stop requests" and "charging pile status query requests" under the same IP differs significantly, and IP-based rate limiting cannot distinguish these differences, easily resulting in the accidental blocking of low-frequency core requests.

[0006] The rate limiting scheme based on interface circuit breaking only counts the number of requests by request URI, without distinguishing the source of the requests. High-frequency requests initiated by malicious platforms may trigger interface circuit breaking, causing the same interface requests from legitimate partner platforms to be blocked as well, severely impacting normal charging services.

[0007] Insufficient security protection: Existing solutions do not adequately consider the risk of cyberattacks. Hackers can forge illegal operator IDs (OperatorId) to launch a large number of requests, causing distributed cache memory overflow; or impersonate the operator IDs of legitimate platforms to launch high-frequency requests, attacking the business links of normal cooperating platforms, further exacerbating system stability risks. Summary of the Invention

[0008] Purpose of the invention: The purpose of this invention is to solve the technical problems in the prior art and provide a refined current limiting method and system for interconnection and interoperability of charging platforms based on operation identification.

[0009] Technical Solution: Firstly, this application proposes a refined current limiting method for interconnection and interoperability of charging platforms based on operational identifiers, including the following steps:

[0010] Receive the interconnection request sent from the first charging platform to the second charging platform;

[0011] Parse the request to obtain the operation identifier of the first charging platform that initiated the request;

[0012] Verify whether the operation identifier exists in the preset set of valid identifiers; if it does not exist, reject the request.

[0013] If the operation identifier is valid, then a unique rate limiting key value is generated based at least on the operation identifier, the requested Uniform Resource Identifier, and the current time window information;

[0014] Obtain the rate limiting threshold corresponding to the Uniform Resource Identifier; based on the rate limiting key value, obtain the number of requests processed within the current time window from the distributed cache; and determine whether the number of requests exceeds the rate limiting threshold.

[0015] If the time limit is not exceeded, the request is allowed to proceed to the backend business logic of the second charging platform for processing; if the time limit is exceeded, the request is rejected.

[0016] After completing the backend business logic processing, the processing result is returned to the first charging platform that initiated the request.

[0017] Preferably, the interconnection request is received by an interceptor deployed on the second charging platform.

[0018] Preferably, obtaining the operation identifier of the first charging platform that initiated the request includes:

[0019] If the request is a non-login request to obtain an access token, then the operation identifier is extracted from the request parameters according to the China Electricity Council T / CEC 102 or the national standard GB / T44130.

[0020] If the request is a logged-in request that carries a valid token, then the token is extracted from the specified field in the request header, the token is decrypted, and the operation identifier is extracted from it.

[0021] Preferably, extracting the operation identifier from the token after decryption includes:

[0022] The token is decrypted using the AES symmetric encryption algorithm to obtain the original string, which is composed of an operation identifier, a timestamp, a random number, and a signature.

[0023] The operation identifier is extracted from the original string; and the validity of the token is verified by verifying the signature information in the token.

[0024] Preferably, the process involves verifying whether the operation identifier exists in a pre-set set of valid identifiers; if it does not exist, the request is rejected, including:

[0025] The preset set of legal identifiers is a local cache maintained by the second charging platform. This local cache is updated by loading the signed charging platform operation identifiers from the database at a frequency of minutes.

[0026] If the operation identifier does not exist in the set of valid identifiers, the request is rejected directly and no request counting is performed.

[0027] Preferably, the unique rate limiting key value is generated by concatenating the microservice name, the fixed rate limiting prefix, the operation identifier, the standardized unified resource identifier, and the minute-level time window;

[0028] The minute-level time window is determined by the number of minutes converted from the current timestamp.

[0029] Preferably, the requested Uniform Resource Identifier is obtained through an interoperability request, and the method further includes standardizing and cleaning the extracted Uniform Resource Identifier by removing the type extension at the end, so that requests with different extensions for the same business interface are counted uniformly.

[0030] Specifically, the standardized cleaning includes:

[0031] Locate the position of the last forward slash and the position of the last period in the Uniform Resource Identifier. If the period is after the forward slash and the suffix after the period is a single letter, then remove the period and the suffix.

[0032] Preferably, obtaining the rate limiting threshold corresponding to the Uniform Resource Identifier includes: the rate limiting threshold is read from the Nacos distributed configuration center, and the reading priority is:

[0033] First, read the custom threshold configured for a specific Uniform Resource Identifier. If the custom threshold does not exist, read the general threshold applicable to all interfaces.

[0034] Preferably, retrieving the number of requests processed within the current time window from the distributed cache includes two modes:

[0035] Verification-only mode: When a request is intercepted for the first time, only the request count corresponding to the rate limiting key value is read and not modified, which is used to quickly determine whether rate limiting is triggered;

[0036] Counting mode: The request count is incremented only when the request's validity is verified and the requested resource exists.

[0037] On the other hand, this application proposes a refined current limiting system for interconnection and interoperability of charging platforms based on operational identification, including:

[0038] The receiving unit is used to receive the interconnection request sent from the first charging platform to the second charging platform;

[0039] The parsing unit is used to parse the request and obtain the operation identifier of the first charging platform that initiated the request;

[0040] The verification unit is used to verify whether the operation identifier exists in a preset set of valid identifiers. If it does not exist, the request is rejected. If the operation identifier is valid, a unique rate limiting key value is generated based on at least the operation identifier, the request's Uniform Resource Identifier, and the current time window information.

[0041] The comparison unit is used to obtain the rate limiting threshold corresponding to the Uniform Resource Identifier, obtain the number of requests processed within the current time window from the distributed cache based on the rate limiting key value, and determine whether the number of requests exceeds the rate limiting threshold.

[0042] If the time limit is not exceeded, the request is allowed to proceed to the backend business logic of the second charging platform for processing; if the time limit is exceeded, the request is rejected.

[0043] The return unit is used to return the processing result to the first charging platform that initiated the request after completing the backend business logic processing.

[0044] Beneficial effects:

[0045] To achieve refined rate limiting and ensure the normal operation of legitimate businesses, this invention generates rate limiting key-value pairs using "OperatorId" + standardized Uniform Resource Identifier (URI) as the core dimension, replacing the traditional coarse-grained rate limiting method based on IP or interface. Requests to the same interface from different platform operators are counted independently. High-frequency requests initiated by malicious platforms only trigger their own rate limiting and do not affect normal business requests from legitimate partner platforms. This avoids the "collateral damage" problem caused by interface-level circuit breakers, significantly improving business fairness and service availability in charging platform interconnection scenarios.

[0046] Perfectly adapted to the business specifications of charging platform interconnection, this invention strictly adheres to charging facility interconnection standards such as China Electricity Council T / CEC 102 and national standard GB / T 44130. It supports operation identifier parsing in both logged-in scenarios (such as the query_token interface for obtaining a token) and logged-in scenarios (such as charging start / stop and order query). By accurately extracting the OperatorId from request parameters or the decrypted token, it ensures seamless integration between the rate limiting mechanism and the actual business processes of the charging platform, demonstrating strong scenario adaptability.

[0047] To construct a multi-layered security protection system and effectively resist malicious attacks, this invention designs a four-layer security protection mechanism: Operation ID legality verification: Only requests that exist in the set of legal IDs that are updated every minute and cached locally are allowed to proceed to subsequent processing, while illegal requests with forged IDs are rejected to prevent the distributed cache from being maliciously filled.

[0048] Request legitimacy verification: Verify the token's signature and validity period to ensure the request originates legitimately;

[0049] URI standardization: Eliminate suffix differences to prevent hackers from bypassing rate limiting or exhausting cache resources by changing the extension;

[0050] Count only non-404 responses: Requests are counted only when the resource corresponding to the request exists and the response is normal, preventing attackers from maliciously consuming counted resources by constructing non-existent URIs.

[0051] The above mechanisms work together to effectively resist various network attacks such as forged identifiers, misuse of legitimate identifiers, and illegal URI traversal, ensuring the safe and stable operation of the system.

[0052] Supporting distributed deployment and boasting strong system scalability, this invention employs Redis distributed caching to store request counts and utilizes Nacos distributed configuration center to manage rate limiting thresholds, making it naturally compatible with the distributed cluster deployment environment of charging platforms. By setting a reasonable expiration time (120 seconds, set only when the count is ≤3) for rate limiting keys, it avoids long-term memory occupation of cached keys, reducing system memory overhead while ensuring rate limiting accuracy and supporting stateless horizontal scaling among cluster nodes.

[0053] Significantly improving system stability and protecting backend resources, this invention effectively avoids performance bottlenecks in the charging platform database caused by frequent locking and unlocking by fine-grained rate limiting of interconnection requests for high-resource-intensive tasks. It also prevents the charging pile embedded system from crashing due to sudden traffic overload. This not only improves the utilization rate of charging piles and the reliability of charging services but also provides charging platform operators with predictable and stable service quality assurance. Attached Figure Description

[0054] Figure 1 A schematic diagram of the method framework for this invention is provided;

[0055] Figure 2 A system framework diagram is provided for this invention;

[0056] Figure 3 This is a flowchart of the rate limiting process for this application.

[0057] Figure 4 This is a flowchart of the process for verifying and updating the legality of the operating identifier in this application. Detailed Implementation

[0058] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0059] Example 1:

[0060] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions in the embodiments of this 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 this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention. Unless otherwise defined, the technical or scientific terms used herein should have the ordinary meaning understood by those skilled in the art. The terms "including" and similar expressions used herein mean that the element or object preceding the term covers the element or object listed after the term and its equivalents, but do not exclude other elements or objects.

[0061] In response to the problems existing in the current technology, such as Figure 1-4 As shown, a refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers is proposed, including the following steps:

[0062] S101. Receive the interconnection request sent from the first charging platform to the second charging platform;

[0063] In some specific embodiments, the interconnection request is received by an interceptor deployed by the second charging platform.

[0064] The interconnection request is received by an interceptor deployed on the second charging platform. The second charging platform configures a custom interceptor (e.g., named CecFilter) in the gateway layer or filter chain to uniformly intercept all requests from external charging platforms. The interceptor is independent of business logic and can perform rate limiting checks before the request enters the business layer, thereby efficiently filtering malicious or excessive requests. The interceptor's function is to intervene in the early stages of request processing, reducing unnecessary load on the business layer and improving system throughput.

[0065] S102. Parse the request and obtain the operation identifier of the first charging platform that initiated the request;

[0066] In some specific embodiments, obtaining the operation identifier of the first charging platform that initiated the request includes:

[0067] If the request is a request to obtain an access token without being logged in, the operation identifier is extracted from the request parameters according to the China Electricity Council T / CEC 102 or the national standard GB / T44130; the interceptor reads the request body (e.g., JSON format), parses it, and obtains the platform operation identifier. This follows industry standards, ensuring compatibility with existing charging platform interconnection protocols without requiring additional modifications (corresponding to the first half of claim 3).

[0068] If the request is a logged-in request that carries a valid token, then the token is extracted from the specified field in the request header, the token is decrypted, and the operation identifier is extracted from it.

[0069] In some specific embodiments, extracting the operation identifier from the token after decryption includes:

[0070] The token is decrypted using the AES symmetric encryption algorithm to obtain the original string, which is composed of an operation identifier, a timestamp, a random number, and a signature.

[0071] The operation identifier is extracted from the original string; and the validity of the token is verified by verifying the signature information in the token. The token is decrypted using the AES symmetric encryption algorithm. The original string is composed of "operation identifier + timestamp + random number + signature". Simultaneously, the validity of the token is verified by checking the signature information (e.g., checking if the timestamp is within its validity period and if the signature matches). This prevents token forgery, ensuring that only legitimately logged-in platforms can pass the rate limiting check; and securely extracts the operation identifier from the token to prevent request parameters from being tampered with.

[0072] S103. Verify whether the operation identifier exists in the preset set of valid identifiers. If it does not exist, reject the request. If the operation identifier is valid, generate a unique rate limiting key value based at least on the operation identifier, the Uniform Resource Identifier of the request, and the current time window information.

[0073] In some specific embodiments, verifying whether the operation identifier exists in a preset set of valid identifiers, and rejecting the request if it does not exist, includes:

[0074] The pre-set set of legal identifiers is a local cache maintained by the second charging platform. This local cache is updated by loading the signed charging platform operation identifiers from the database at a frequency of minutes.

[0075] If the operational identifier does not exist in the set of legitimate identifiers, the request is directly rejected without any request counting. This prevents hackers from forging illegal operational identifiers to launch a large number of requests, causing Redis memory overflow; it also avoids illegal requests consuming rate limiting and counting resources, protecting the backend system. The minute-level update mechanism ensures data freshness while avoiding frequent database queries, improving verification efficiency.

[0076] In some specific embodiments, the unique rate limiting key value is generated by concatenating the microservice name, a fixed rate limiting prefix, the operation identifier, the standardized unified resource identifier, and a minute-level time window;

[0077] The minute-level time window is determined by the number of minutes converted from the current timestamp.

[0078] In some specific embodiments, the requested Uniform Resource Identifier is obtained through an interoperability request, and the method also includes standardizing and cleaning the extracted Uniform Resource Identifier by removing the type extension at the end, so that requests with different extensions for the same business interface are counted uniformly.

[0079] Specifically, the standardized cleaning includes:

[0080] Locate the position of the last forward slash and the position of the last period in the Uniform Resource Identifier. If the period is after the forward slash and the suffix after the period is a single letter, then remove the period and the suffix.

[0081] For example: nevcs:reqLimit:321895837: / v1.0.0 / query_token:29606817. Here, the minute-level time window is obtained by dividing the current timestamp by 60000 (milliseconds) and rounding down, ensuring that a unique counter key is generated every minute.

[0082] Furthermore, to eliminate statistical distortion caused by different request URI extensions, this invention performs standardization cleaning on the original URI: It searches for the position of the last forward slash " / " and the position of the last period "." in the URI. If the period is after the forward slash and the suffix after the period is a pure letter (such as ".do" or ".html"), then the period and the suffix are removed. For example, / v1.0.0 / query_token.do is cleaned to / v1.0.0 / query_token.

[0083] The key-value pair contains the operation identifier and URI, enabling independent rate limiting for different platforms and interfaces; the minute-level time window supports short-cycle traffic control to prevent sudden bursts of traffic from overwhelming the backend;

[0084] URI standardization prevents hackers from bypassing rate limiting or consuming different counting keys by changing extensions (such as query_token.do, query_token.action), ensuring that requests to the same business interface are counted uniformly.

[0085] In some specific embodiments, obtaining the rate limiting threshold corresponding to the Uniform Resource Identifier includes: the rate limiting threshold is read from the Nacos distributed configuration center, and the reading priority is:

[0086] First, read the custom threshold configured for a specific Uniform Resource Identifier. If the custom threshold does not exist, read the general threshold applicable to all interfaces.

[0087] In some specific embodiments, the configuration format of the custom threshold is "Uniform Resource Identifier: Threshold", which is used to set a rate limiting threshold separately for high-frequency interfaces; the general threshold is the default rate limiting standard for all Uniform Resource Identifiers that have not been configured with a custom threshold.

[0088] The configuration item for custom thresholds is nevcs.customUriReqLimit, with the format "URI1:threshold1,URI2:threshold2", for example / v1.0.0 / query_token:200, / v1.0.0 / start_charge:500. This is used to set stricter rate limiting standards for high-frequency interfaces.

[0089] The general threshold configuration item is `nevcs.uriReqLimit` (e.g., 200), which serves as the default rate limiting value for all URIs without a configured custom threshold. This enables differentiated rate limiting at the interface level; critical or expensive interfaces (such as charging start / stop) can have lower thresholds, while lightweight interfaces like status queries can have higher thresholds, flexibly adapting to business needs. Furthermore, through dynamic configuration with Nacos, rate limiting parameters can be adjusted without restarting the service, improving operational convenience.

[0090] In some specific embodiments, retrieving the number of requests processed within the current time window from the distributed cache includes two modes:

[0091] Verification-only mode: When intercepting a request for the first time, only the request count corresponding to the rate limiting key value is read without modification, which is used to quickly determine whether rate limiting has been triggered. This mode is used to quickly determine whether rate limiting has been triggered. If the threshold has been exceeded, the request is rejected directly to avoid unnecessary consumption of subsequent resources.

[0092] Counting mode: The request count is incremented only when the request's validity is verified and the requested resource exists. This prevents unwarranted consumption of rate limiting quotas due to illegal requests (such as forged tokens or maliciously constructed URIs), ensuring the accuracy of rate limiting for legitimate requests.

[0093] S104. Obtain the rate limiting threshold corresponding to the Uniform Resource Identifier. Based on the rate limiting key value, obtain the number of requests processed within the current time window from the distributed cache, and determine whether the number of requests exceeds the rate limiting threshold. If it does not exceed the threshold, allow the request to be processed by the backend business logic of the second charging platform. If it exceeds the threshold, reject the request.

[0094] S105. After completing the backend business logic processing, the processing result is returned to the first charging platform that initiated the request.

[0095] In some specific embodiments, the increment operation of the counting mode is performed only when the following conditions are met simultaneously in the current limiting decision step:

[0096] The validity of the request was verified; and the response status code of the request was not a 404 error code.

[0097] In some specific embodiments, the rate limiting decision step further includes:

[0098] For requests that fail to pass validity checks, the request count will not be incremented to prevent illegal requests from exhausting the rate limit.

[0099] In some specific embodiments, the method further includes attack protection steps:

[0100] For requests forged by hackers using Uniform Resource Identifiers, if the response status code is 404, the request count will not be incremented to prevent cache resources from being exhausted.

[0101] If any of the above conditions are not met, the count will not be incremented. Specifically:

[0102] For requests that fail to validate their legitimacy (such as signature errors or expired tokens), the rate limit count will not increase even if the request reaches the business layer, thus preventing illegal requests from exhausting the rate limit quota of the legitimate platform.

[0103] URIs that are forged by hackers and point to non-existent resources (resulting in a 404 response) are not counted, thus preventing attackers from exhausting the Redis cache or triggering fake rate limits by traversing URIs. This builds multi-layered security protection and significantly improves the system's ability to resist malicious attacks.

[0104] In some specific embodiments, the method further includes a cache expiration management step:

[0105] When the request count after the auto-increment operation in the counting mode is less than or equal to a preset value, an expiration time is set for the rate limiting key value to prevent it from occupying the distributed cache memory for a long time.

[0106] In some specific embodiments, the preset value is 3, and the expiration time needs to be set multiple times to avoid configuration failure due to a single network anomaly.

[0107] To prevent rate-limiting keys from occupying Redis memory for extended periods, this invention implements a cache expiration management strategy: when the request count after an increment operation in counting mode is ≤3, a 120-second expiration time is set for the rate-limiting key. Furthermore, to improve reliability, the expiration time is attempted multiple times (e.g., 2-3 consecutive attempts after incrementing) to prevent expiration time configuration failure due to a single network fluctuation.

[0108] For low-frequency interfaces, the rate limiting key value will be automatically released after two minutes, effectively reducing the memory usage of the distributed cache; at the same time, redundant settings ensure that the expiration time takes effect, avoiding cache accumulation.

[0109] For example:

[0110] Example 1:

[0111] This example uses "Platform B requests Platform A to obtain an access token" as an example. Platform A deploys the rate limiting method of this invention, and the specific execution steps are as follows:

[0112] 1. URI standardization:

[0113] Platform A's CecFilter interceptor receives a request from Platform B, extracts the URI as " / v1.0.0 / query_token.do", and calls FlowLimitUtil's removeSuffix method to process the URI: it finds the position of the last forward slash ( / ) at 11, the position of the last period (.) at 19, and the suffix "do" after the period is a pure letter and is located after the last forward slash, so the suffix is ​​removed, and the normalized URI is " / v1.0.0 / query_token".

[0114] 2. Operation Identifier Resolution:

[0115] The request was a "get token" request made by someone who was not logged in. CecFilter used HttpServletRequestWrapper to read the request body content, parsed the JSON format request body and extracted the OperatorId as "321895837", which was used as the operation identifier of platform B.

[0116] 3. Verification of the legality of the operation logo:

[0117] FlowLimitUtil calls the getAllOperatorIDs method of TcbPartnerServiceImpl to read the set of valid OperatorIds updated every minute ({321895837,321895838,...}); it verifies that "321895837" exists in the set and determines it to be a valid identifier.

[0118] 4. Rate limiting key generation:

[0119] The rate limiting key value is generated according to the formula: “microservice name + fixed rate limiting prefix + operation identifier + standardized URI + minute-level time window”: “nevcs:reqLimit:321895837: / v1.0.0 / query_token:29606817”.

[0120] 5. Obtaining the rate limiting threshold:

[0121] FlowLimitUtil calls the getCfgReqLimit method to read the configuration from Nacos: the custom threshold configuration nevcs.customUriReqLimit is " / v1.0.0 / query_token:200, / evcs / v1.0.0 / query_station_status:1200", and the custom threshold matching " / v1.0.0 / query_token" is 200, so there is no need to read the general threshold nevcs.uriReqLimit.

[0122] 6. Distributed counting (for verification-only scenarios):

[0123] FlowLimitUtil reads the key-value pair “nevcs:reqLimit:321895837: / v1.0.0 / query_token:29606817” from Redis via JedisUtil. The count is 1, which does not exceed the threshold of 200, so the request is allowed.

[0124] 7. Traffic limiting decision-making and security protection:

[0125] The `chain.doFilter(requestWrapper,wrappedResponse)` method allows requests to pass through to the token generation logic, and then the response results are analyzed. The counter is only incremented when a legitimate request receives a normal response, to prevent hackers from launching illegal requests that could cause the counter to overflow and render legitimate requests unusable.

[0126] 8. Results returned:

[0127] Return the newly generated token to Platform B to complete the processing of this request; if the subsequent query_token request count of Platform B exceeds 200 within this minute, it will be rejected directly.

[0128] Example 2:

[0129] This example uses "Platform B sending a charging request (start_charge) to Platform A with a valid token" as an example. Platform A deploys the rate limiting method of this invention, and the specific execution steps are as follows:

[0130] 1. URI standardization:

[0131] Platform A's CecFilter interceptor receives a charging request from Platform B, extracts the request URI as " / v1.0.0 / start_charge.do", and calls FlowLimitUtil's removeSuffix method to standardize the URI: it finds the position of the last forward slash ( / ) in the URI as 11, the position of the last period (.) as 22, and removes the suffix "do" which is a pure letter after the last forward slash. The standardized URI is " / v1.0.0 / start_charge".

[0132] 2. Token Verification:

[0133] Extract the token (the value after the prefix) from the "Authorization" header of the request, and call the checkUserValid method to verify the token: query the key information of platform B through TcbPartnerServiceImpl, decrypt the token using the Aes symmetric encryption algorithm, and verify the validity of the token by verifying the signature information in the token.

[0134] 3. Operation Identifier Resolution:

[0135] CecFilter uses the Aes algorithm to decrypt the token, and then extracts the OperatorId from the concatenated string as "321895837" (the original string is the result of concatenating OperatorId, timestamp, random number, and signature), which serves as the unique operating identifier for platform B.

[0136] 4. Verification of the legality of the operation logo:

[0137] FlowLimitUtil calls the getAllOperatorIDs method of TcbPartnerServiceImpl to read the set of valid OperatorIds updated every minute ({321895837,321895838,...}); it verifies that “321895837” exists in the valid set and determines it as a valid operation identifier.

[0138] 5. Rate limiting key generation:

[0139] The Redis key value for generating distributed rate limiting is “nevcs:reqLimit:321895837: / v1.0.0 / start_charge:29606916”, where “nevcs:reqLimit” is a fixed rate limiting prefix, “321895837” is the OperatorId of platform B, “ / v1.0.0 / start_charge” is the normalized URI, and “29606916” is the number of minutes converted from the current timestamp (1776414982238) (1776414982238 / 60000=29606916), ensuring that an independent counter key is generated every minute.

[0140] 6. Obtaining the rate limiting threshold:

[0141] FlowLimitUtil calls the getCfgReqLimit method to read the rate limiting threshold from the Nacos configuration center: First, it reads the custom threshold configuration nevcs.customUriReqLimit (configuration value is " / v1.0.0 / query_token:200, / v1.0.0 / start_charge:500, / evcs / v1.0.0 / query_station_status:1200"). The custom rate limiting threshold matching " / v1.0.0 / start_charge" is 500 times / minute, so there is no need to read the general threshold nevcs.uriReqLimit.

[0142] 7. Distributed counting (for verification-only scenarios):

[0143] FlowLimitUtil reads the current count of the key-value pair “nevcs:reqLimit:321895837: / v1.0.0 / start_charge:29606916” from Redis via JedisUtil. The count is 180, which does not exceed the threshold of 500. Therefore, it is determined that the current request has not triggered rate limiting and is allowed to proceed to the validity verification stage.

[0144] 8. Traffic limiting decision-making and security protection:

[0145] Using `chain.doFilter(requestWrapper, wrappedResponse)`, `CecFilter` allows the request to proceed to the business layer for charging logic processing. After the business layer issues the charging command, it returns a response. `FlowLimitUtil` checks the response status code in its `finally` block to be 200 (not a 404 error) and calls the `JedisUtil.incr` method to increment the count of that key-value pair in Redis to 181. Since the count 181 is greater than 3, there is no need to set an expiration time for this Redis key-value pair.

[0146] Request processing and result return: Return the result of whether the charging was successful or not to platform B, and complete the processing of this request; if the start_charge request count of platform B in this minute exceeds 500, the subsequent request will be directly rejected until a new count key is generated in the next minute.

[0147] On the other hand, combining Figure 2 This application proposes a refined current limiting system for interconnection and interoperability of charging platforms based on operational identification, comprising:

[0148] The receiving unit is used to receive the interconnection request sent from the first charging platform to the second charging platform;

[0149] The parsing unit is used to parse the request and obtain the operation identifier of the first charging platform that initiated the request;

[0150] The verification unit is used to verify whether the operation identifier exists in a preset set of valid identifiers. If it does not exist, the request is rejected. If the operation identifier is valid, a unique rate limiting key value is generated based on at least the operation identifier, the request's Uniform Resource Identifier, and the current time window information.

[0151] The comparison unit is used to obtain the rate limiting threshold corresponding to the Uniform Resource Identifier, obtain the number of requests processed within the current time window from the distributed cache based on the rate limiting key value, and determine whether the number of requests exceeds the rate limiting threshold.

[0152] If the time limit is not exceeded, the request is allowed to proceed to the backend business logic of the second charging platform for processing; if the time limit is exceeded, the request is rejected.

[0153] The return unit is used to return the processing result to the first charging platform that initiated the request after completing the backend business logic processing.

[0154] The above description is merely a specific implementation of the embodiments of the present invention, but the protection scope of the embodiments of the present invention is not limited thereto. Any changes or substitutions within the technical scope disclosed in the embodiments of the present invention should be covered within the protection scope of the embodiments of the present invention. Therefore, the protection scope of the embodiments of the present invention should be determined by the protection scope of the claims.

Claims

1. A refined current limiting method for interconnection and interoperability of charging platforms based on operational identifiers, characterized in that, Including the following steps: Receive the interconnection request sent from the first charging platform to the second charging platform; Parse the request to obtain the operation identifier of the first charging platform that initiated the request; Verify whether the operation identifier exists in the preset set of valid identifiers; if it does not exist, reject the request. If the operation identifier is valid, then a unique rate limiting key value is generated based at least on the operation identifier, the requested Uniform Resource Identifier, and the current time window information; Obtain the rate limiting threshold corresponding to the Uniform Resource Identifier; based on the rate limiting key value, obtain the number of requests processed within the current time window from the distributed cache; and determine whether the number of requests exceeds the rate limiting threshold. If the time limit is not exceeded, the request is allowed to be processed by the backend business logic of the second charging platform. If the number exceeds the limit, the request is rejected. After completing the backend business logic processing, the processing result is returned to the first charging platform that initiated the request.

2. The refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers as described in claim 1, characterized in that, The interconnection request is received by an interceptor deployed by the second charging platform.

3. The refined current limiting method for interconnection and interoperability of charging platforms based on operation identification as described in claim 1, characterized in that, Obtaining the operation identifier of the first charging platform that initiated the request includes: If the request is a non-login request to obtain an access token, then the operation identifier is extracted from the request parameters according to the China Electricity Council T / CEC 102 or the national standard GB / T44130. If the request is a logged-in request that carries a valid token, then the token is extracted from the specified field in the request header, the token is decrypted, and the operation identifier is extracted from it.

4. The refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers as described in claim 3, characterized in that, Extracting the operation identifier from the token after decryption includes: The token is decrypted using the AES symmetric encryption algorithm to obtain the original string, which is composed of an operation identifier, a timestamp, a random number, and a signature. The operation identifier is extracted from the original string; and the validity of the token is verified by verifying the signature information in the token.

5. The refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers as described in claim 1, characterized in that, Verify whether the operation identifier exists in a preset set of valid identifiers. If it does not exist, reject the request, including: The preset set of legal identifiers is a local cache maintained by the second charging platform. This local cache is updated by loading the signed charging platform operation identifiers from the database at a frequency of minutes. If the operation identifier does not exist in the set of valid identifiers, the request is rejected directly and no request counting is performed.

6. The refined current limiting method for interconnection and interoperability of charging platforms based on operation identification as described in claim 1, characterized in that, The unique rate limiting key is generated by concatenating the microservice name, the fixed rate limiting prefix, the operation identifier, the standardized unified resource identifier, and the minute-level time window. The minute-level time window is determined by the number of minutes converted from the current timestamp.

7. A refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers as described in claim 1, characterized in that, The requested Uniform Resource Identifier is obtained through an Interoperability Request, and the process also includes standardizing and cleaning the extracted Uniform Resource Identifier by removing the type extension at the end, so that requests with different extensions for the same business interface are counted uniformly. Specifically, the standardized cleaning includes: Locate the position of the last forward slash and the position of the last period in the Uniform Resource Identifier. If the period is after the forward slash and the suffix after the period is a single letter, then remove the period and the suffix.

8. The refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers as described in claim 1, characterized in that, Obtaining the rate limiting threshold corresponding to the Uniform Resource Identifier includes: the rate limiting threshold is read from the Nacos Distributed Configuration Center, and the reading priority is: First, read the custom threshold configured for a specific Uniform Resource Identifier. If the custom threshold does not exist, read the general threshold applicable to all interfaces.

9. A refined current limiting method for interconnection and interoperability of charging platforms based on operation identifiers as described in claim 1, characterized in that, Retrieving the number of requests processed within the current time window from the distributed cache includes two modes: Verification-only mode: When a request is intercepted for the first time, only the request count corresponding to the rate limiting key value is read and not modified, which is used to quickly determine whether rate limiting is triggered; Counting mode: The request count is incremented only when the request's validity is verified and the requested resource exists.

10. A refined current limiting system for interconnection and interoperability of charging platforms based on operational identifiers, characterized in that, include: The receiving unit is used to receive the interconnection request sent from the first charging platform to the second charging platform; The parsing unit is used to parse the request and obtain the operation identifier of the first charging platform that initiated the request; The verification unit is used to verify whether the operation identifier exists in a preset set of valid identifiers. If it does not exist, the request is rejected. If the operation identifier is valid, a unique rate limiting key value is generated based on at least the operation identifier, the request's Uniform Resource Identifier, and the current time window information. The comparison unit is used to obtain the rate limiting threshold corresponding to the Uniform Resource Identifier, obtain the number of requests processed within the current time window from the distributed cache based on the rate limiting key value, and determine whether the number of requests exceeds the rate limiting threshold. If the time limit is not exceeded, the request is allowed to be processed by the backend business logic of the second charging platform. If the number exceeds the limit, the request is rejected. The return unit is used to return the processing result to the first charging platform that initiated the request after completing the backend business logic processing.

Images