A charging platform pushing method and system for hierarchical fusing and non-parameter health detection

Abstract

The application discloses a charging platform pushing method and system for hierarchical fusing and non-parameter health detection, obtains a plurality of target platforms of a message to be pushed and initiates an HTTP pushing request, retries according to a corresponding strategy after failure, judges whether a pushing interface belongs to a preset core interface set when still failing after retrying, does not fuse and continues to push if belonging, and sets a corresponding pushing direction as fusing silence and suspends pushing if not belonging; a non-parameter detection request is constructed by stripping a service parameter of a URL of an original failed request according to the fusing silent pushing direction and a detection period, and detection is initiated by reusing a timeout parameter of the original request; the fusing silence is removed and pushing is recovered if an HTTP response is received, and otherwise, the fusing silence is maintained until the next detection period. The application isolates abnormal nodes on the premise of guaranteeing that core business pushing is not interrupted, accurately detects and does not interfere with the business of a counterpart, and improves the stability of a pushing system.

Description

Technical Field

[0001] This invention belongs to the field of data communication technology, specifically relating to a charging platform push method and system with graded circuit breaking and parameterless health detection. Background Technology

[0002] With the development of interconnectivity in the new energy vehicle charging industry, charging operation platforms directly connected to a large number of charging piles need to synchronously push charging pile status, real-time charging data, and order settlement information to hundreds of third-party platforms, including cooperative charging platforms, government regulatory platforms, and gate systems. These pushes are all initiated by the platforms themselves via HTTP requests, characterized by large volumes of data and high real-time requirements, with significant differences in the stability of the connected parties. Tens of thousands of charging piles report data every 30 seconds, and a single data entry needs to be synchronously pushed to hundreds of directions, generating millions of HTTP requests per minute. The instability and slow response of some third-party platforms can consume a large amount of push threads and connection resources, leading to message consumption backlog and ultimately slowing down the push timeliness in all directions. Abnormal nodes can easily trigger service avalanches. Meanwhile, the importance of charging business data varies significantly: real-time data is sensitive to timeliness and has a high tolerance for availability, while orders and start / stop commands have extremely high availability requirements. Missed pushes can cause third-party platforms to be unable to settle accounts and display incorrect charging pile status, directly impacting the driver's user experience and merchant payment settlement. Existing push architectures typically apply uniform circuit breaker handling to all failed interfaces, interrupting the delivery of core business data as well. Furthermore, they lack the ability to set differentiated retry, timeout, and circuit breaker policies for different business types. In addition, existing health check methods have shortcomings: TCP port checks can only verify network connectivity and cannot confirm the normality of the other party's HTTP service; check requests with business parameters can inject invalid data into the other party's system, causing business interference; and inconsistencies between health check parameters and actual business parameters can lead to discrepancies between check results and the actual push experience. The strategy of triggering a circuit breaker upon a single failure and immediately reopening it after recovery can also cause frequent switching of the circuit breaker state during network fluctuations, further exacerbating system instability.

[0003] Existing patent CN122152515A discloses a microservice proactive circuit breaker method, system, computer device, and storage medium. This solution monitors its own hardware resource usage and triggers tiered circuit breaking when resource usage reaches a pressure condition, interrupting secondary services while preserving core services. The circuit breaker signal is automatically cleared after the resource pressure condition is relieved. However, this solution's circuit breaker triggering relies on its own hardware resource pressure, representing an internal system resource perspective. In external push scenarios, resource exhaustion stems from abnormal responses from external interfacing partners, and this solution cannot isolate anomalies from individual external interfacing partners. Furthermore, the clearing of the circuit breaker signal is passively contingent on the relief of resource pressure, failing to proactively detect changes in the service status of interfacing partners, resulting in delayed recovery and potentially affecting push timeliness. It applies a uniform recovery logic to all services, lacking state stabilization measures for network fluctuations. When interfacing services experience repeated fluctuations, frequent switching between circuit breaking and recovery can exacerbate system instability. Summary of the Invention

[0004] In scenarios where charging operation platforms push data to third-party platforms, the following problems frequently arise: large push volumes and significant differences in the stability of the interfacing platforms; some third-party platforms are unstable and slow to respond, consuming a large amount of push threads and connection resources, leading to message consumption backlog, and abnormal nodes can easily trigger service avalanches; existing circuit breaker mechanisms uniformly circuit breaker all failed interfaces, interrupting the push of core business data such as charging start / stop results and order settlement, resulting in missed pushes causing third-party platforms to be unable to settle accounts and incorrect charging pile status displays, directly impacting driver user experience and merchant fund settlement; in existing health detection methods, TCP port detection can only verify network connectivity and cannot confirm whether the other party's HTTP service is normal; detection requests with business parameters may inject invalid data into the other party's system, and inconsistencies between detection parameters and actual business parameters will lead to detection results that do not match the actual push experience; the strategy of circuit breaking upon a single failure and immediately releasing it after recovery can cause frequent switching of the circuit breaker state during network fluctuations, which can exacerbate system instability.

[0005] To solve the above-mentioned technical problems, the technical solution provided by the present invention is: a charging platform push method with graded fuse breaking and parameterless health detection, comprising the following steps: S1. Obtain multiple target platforms for the message to be pushed, initiate HTTP push requests to each target platform, and retry according to the corresponding strategy if the request fails. S2. If the retry still fails, determine whether the push interface belongs to the preset core interface set. If it does, continue pushing without circuit breaking. If it does not, set the corresponding push direction to circuit breaking silence and pause push. S3. Based on the detection cycle, push the direction of the circuit breaker silence, extract the business parameters from the URL of the original failed request to construct a parameterless probe request, and reuse the timeout parameters of the original request to initiate the probe. S4. If an HTTP response is received, the circuit breaker will be lifted and push notifications will resume. If no response is received, the circuit breaker will remain inactive until the next detection cycle.

[0006] Specifically, in step S2, the core interface set includes the start charging result interface, the stop charging result interface, and the charging order information interface; the charging pile status interface and the real-time charging data interface are not part of the core interface set.

[0007] Specifically, in step S1, push interfaces belonging to the core interface set are retried according to the multiple retry strategy; real-time data push interfaces not belonging to the core interface set are not retried, and after a push failure, they directly proceed to the determination in step S2.

[0008] Specifically, in step S1, the connection timeout and read / write timeout for each target platform are configured independently; the connection timeout and read / write timeout for real-time data pushes are shorter than those for charging order pushes.

[0009] Specifically, in step S2, the combination of the target platform and the push interface is used as the circuit breaker unit, and the target address corresponding to the failed request is written into the failure cache list; different push interfaces of the same target platform independently determine whether to enter the circuit breaker silence.

[0010] Specifically, in steps S3 and S4, the business parameters are stripped by parsing the URL of the original failed request and removing the question mark and all subsequent request parameter fields; the probe only determines whether an HTTP response has been received and whether a connection error or read / write error has occurred, without verifying the business correctness of the response content.

[0011] Specifically, in step S4, after a single push direction enters the circuit breaker silence, it will be silent for at least one complete detection cycle, during which no probes or pushes will be initiated for that push direction.

[0012] Specifically, in step S3, the detection cycle is set according to the service stability level of the target platform. The detection cycle for the target platform with poor service stability is longer than that for the target platform with good service stability.

[0013] Specifically, in step S3, the connection timeout, write timeout, and read timeout of the parameterless probe request are consistent with the connection timeout, write timeout, and read timeout of the original failed push request, respectively.

[0014] This invention also provides a charging platform push system with tiered circuit breaking and parameterless health detection, including a message push module. The message push module initiates HTTP push requests to multiple target platforms to which the message is to be pushed, and the failure result is output to the circuit breaking determination module. The circuit breaking determination module determines whether the push interface that still fails after retry belongs to the core interface set. If it does, the push continues without circuit breaking; otherwise, the push direction is set to circuit breaking silence and output to the health detection module. The health detection module takes the URL of the original failed request according to the detection cycle, strips the business parameters, and initiates parameterless detection with the original request timeout parameters. The detection result is output to the circuit breaking recovery module. When the circuit breaking recovery module detects and receives an HTTP response, it releases the circuit breaking silence and resumes push; otherwise, it maintains the circuit breaking silence until the next detection cycle.

[0015] Compared with existing technologies, the beneficial effects of this invention are as follows: Key interfaces such as charging start / stop and order settlement never experience circuit breakers, always striving to push data, ensuring settlement accuracy and user experience, meeting the strong time-series and financial requirements of the charging business, with zero impact on core business; Automatic circuit breaking occurs in non-core business directions after anomalies, releasing thread and connection resources, preventing a few bad nodes from dragging down the entire push service, ensuring timely pushes in normal directions, and effectively isolating abnormal nodes; Parameterless HTTP detection with the same URL and timeout ensures detection results are highly consistent with the actual business push experience, and does not inject invalid data into the other party's system, thus not interfering with the other party's business, making health detection accurate and secure; Circuit breaking only after multiple failures and detection only at fixed intervals effectively avoids the back-and-forth swings between circuit breaking and recovery caused by network jitter, resulting in more stable system operation; Fully configurable, allowing for differentiated strategies to be set for different interface platforms and different business interfaces, adapting to hundreds of interconnection partners with varying stability, demonstrating strong adaptability. Attached Figure Description

[0016] Figure 1 This is an overall architecture diagram of the charging platform push system provided in an embodiment of the present invention.

[0017] Figure 2 The flowchart below shows the overall process of the tiered circuit breaker push method provided in this embodiment of the invention.

[0018] Figure 3 The flowchart for determining push failure and circuit breaker is provided for embodiments of the present invention.

[0019] Figure 4 A flowchart illustrating the circuit breaker shutdown and health recovery process provided in this embodiment of the invention. Detailed Implementation

[0020] The present invention will now be described in detail with reference to the accompanying drawings and embodiments.

[0021] Example 1: This example focuses on the interconnection and push service of a new energy vehicle charging platform. This platform directly connects to tens of thousands of charging piles and simultaneously interfaces with hundreds of third-party platforms, including partner charging platforms, government regulatory platforms, and gate systems. It needs to synchronously push charging pile status, real-time charging data, and order settlement information to each interface party. The technical capabilities and service quality of these interface parties vary, with some platforms frequently experiencing slow response times or service interruptions. Furthermore, the push service has limited available threads and connection resources; prolonged resource occupation in a few abnormal directions can slow down the push timeliness of all directions.

[0022] like Figure 1 and Figure 2 As shown, this embodiment provides a charging platform push method with graded fuse failure and parameterless health detection, including the following steps: S1. Obtain multiple target platforms for the message to be pushed, initiate HTTP push requests to each target platform, and retry according to the corresponding strategy if the request fails. S2. If the retry still fails, determine whether the push interface belongs to the preset core interface set. If it does, continue pushing without circuit breaking. If it does not, set the corresponding push direction to circuit breaking silence and pause push. S3. Based on the detection cycle, push the direction of the circuit breaker silence, extract the business parameters from the URL of the original failed request to construct a parameterless probe request, and reuse the timeout parameters of the original request to initiate the probe. S4. If an HTTP response is received, the circuit breaker will be lifted and push notifications will resume. If no response is received, the circuit breaker will remain inactive until the next detection cycle.

[0023] The specific implementation process of each step will be explained in further detail below.

[0024] In step S1, the push service consumes the status, real-time data, and order pending push messages reported by charging piles from the message queue, iterates through all third-party platform push targets corresponding to the message, and initiates HTTP requests to each one. The message queue buffers the reported data, smoothing out the traffic peaks caused by the concentrated reporting of charging piles, and ensuring that the push service consumes the data smoothly according to its processing capacity. When a push fails, it automatically retryes according to the corresponding configured retry count; real-time data pushes are retried without retries, and directly enter the judgment stage after failure; important interfaces are retried multiple times to ensure delivery as much as possible.

[0025] The strategies for each push direction are pre-configured in the configuration center for all connected platforms and push interfaces. The configuration center maintains a whitelist of important interfaces, including notification_start_charge_result (charging start result), notification_stop_charge_result (charging stop result), and notification_charge_order_info (charging order information). Interfaces on the whitelist will never trigger circuit breakers. These interfaces carry charging start / stop results and order settlement information, which are core business data. Missing pushes will cause third-party platforms to be unable to settle accounts and incorrect charging pile status displays, directly affecting the driver's user experience and merchant fund settlement. Therefore, regardless of the service status of the connected party, every effort must be made to deliver the data. The default number of retries is 3. Real-time data pushes are configured to 0 retries, while important interfaces can be configured to 3-5 retries. Real-time data is sensitive to timeliness and has a high tolerance for availability. After a failure, it should be abandoned immediately and the next round of new data should be waited for. Retrying will only crowd out the push resources for subsequent data. Important interfaces have extremely high availability requirements, and multiple retries are used to ensure delivery as much as possible. Regarding timeout parameters, the default timeout for real-time data push connections and read / write operations is 2 seconds, while for other pushes it's 5 seconds. Each target platform can be individually adjusted. Real-time data pushes are high-volume and time-sensitive; a shorter timeout allows for quick identification of anomalies and release of thread resources. Order-type data pushes are smaller in volume but require high reliability; a longer timeout tolerates brief processing delays from the interfacing platform. The default circuit breaker detection period is 1 minute, which can be shortened to 30 seconds for important partners and extended to 5 minutes for platforms with poor stability. A shorter detection period results in more timely service recovery, but more frequent probe requests from interfacing platforms lead to a longer detection period, resulting in more thorough resource release for long-term anomalies. Therefore, settings should be differentiated based on the importance of the partnership and the stability of the platform. Configuration changes take effect immediately without requiring a service restart; operations personnel can adjust strategies at any time based on the actual operating conditions of each interfacing platform.

[0026] Taking policy adjustments as an example: A government regulatory platform, a key partner, had its circuit breaker detection cycle shortened from the default 1 minute to 30 seconds by operations and maintenance personnel, enabling faster detection and recovery from anomalies. A small gate system suffered from poor service stability and was chronically in an abnormal state; its detection cycle was extended to 5 minutes to reduce the pressure on its push service and the gate system from invalid probes. A newly integrated charging platform had slow interface response; its order push timeout was appropriately lengthened from the default 5 seconds. All these adjustments were completed in the configuration center and took effect immediately without requiring a service restart.

[0027] In step S2, such as Figure 3As shown, requests that still fail after retrying are subject to circuit breaker checks. The circuit breaker check matches the current push interface name to determine if it belongs to the critical interface whitelist. If it is in the whitelist, the process ends directly without any circuit breaker action, and subsequent messages continue to be pushed normally. Even if pushes in this direction continue to fail, retrying is still performed according to the configuration, and pushes continue, ensuring the core business data push chain is never interrupted. If it is not in the whitelist, the URL corresponding to that platform is added to the local failure cache list, and this direction enters a circuit breaker silence; subsequent messages will no longer be pushed to it, releasing thread and connection resources. The failure cache list is recorded by URL; different interfaces on the same platform correspond to different URLs. Therefore, on the same platform, only the abnormal interface direction can be circuit-broken, while pushes in other interface directions remain unaffected, achieving fine-grained exception isolation. Automatic circuit breaking after an exception in a non-core interface direction releases the thread and connection resources occupied by the abnormal interface, preventing a few bad nodes from dragging down the entire push service and ensuring the timeliness of pushes in other normal directions.

[0028] In step S3, such as Figure 4 As shown, the background scheduled task runs periodically, traversing all URLs in the failure cache list, obtaining the complete URL address of the original failed request, removing all business request parameters, and constructing an empty parameter HTTP request. Specifically, it parses the URL of the original failed request, removes all request parameter fields after the question mark, and only retains the protocol, host, and path parts. Since the probe request does not carry any business parameters, it will not generate invalid orders, invalid statuses, or other business data in the other party's system, and will not interfere with the business of the other party. The probe request reuses the connection timeout, write timeout, and read timeout parameters corresponding to the original business push of the URL. The probe request and the real business push use the same URL and timeout configuration. If the probe can receive a response, it means that the real push can also be delivered. The detection results are highly consistent with the actual push experience. The detection request only focuses on whether the HTTP response can be received normally and whether there is a timeout or connection abnormality. It does not verify the business correctness of the returned content. Compared with TCP port detection, which can only verify network connectivity, HTTP probe can confirm whether the other party's HTTP service is responding normally, and the judgment result is more accurate. At the same time, since it does not parse the business content of the returned message, the detection logic is lightweight and will not be misjudged due to differences in the other party's return format.

[0029] The parameterless health check in this embodiment has significant advantages over existing detection methods: TCP port detection can only verify network connectivity; if the target HTTP service process is abnormal but the port is still accessible, it will result in a false positive, making it impossible to confirm whether the target HTTP service is normal; detection requests carrying business parameters will inject invalid data into the target system, which may generate invalid orders or invalid status records, causing business interference; when the detection parameters are inconsistent with the actual business parameters, even if the detection passes, it does not mean that the actual push can be delivered, and the detection result does not match the actual push experience. The detection request in this embodiment uses the same URL and timeout as the actual push and does not carry business parameters, thus avoiding the above three types of defects.

[0030] In step S4, if the detection request successfully receives an HTTP response without throwing a connection or read / write exception, it is determined that the other party's service has recovered. The URL is then removed from the failure cache list, the circuit breaker is lifted, and normal push resumes. If the detection fails, the circuit breaker remains silent, waiting for the next detection cycle to attempt another detection. After a circuit breaker is broken in one direction, it remains silent for at least one complete detection cycle to avoid frequent state switching due to network jitter. Considering the precondition of circuit breaker breaking only after multiple failed retries, this embodiment incorporates anti-jitter measures on both the circuit breaker entry point and the recovery exit point: the entry point is not mistakenly broken due to an occasional single failure, and the exit point is not mistakenly judged to have recovered due to an occasional single successful probe, resulting in smooth circuit breaker state switching and stable system operation.

[0031] Taking a complete push lifecycle as an example: A cooperative charging platform A's real-time data receiving interface service malfunctions. The push service attempts to send real-time charging pile data to it, but the request times out. Since real-time data pushes are configured for zero retries, this request directly enters the circuit breaker process. This interface is not on the critical interface whitelist, so the URL corresponding to this interface on platform A is added to the failure cache list. This direction enters a circuit breaker silence, and subsequent real-time data is no longer pushed to platform A. Threads and connection resources are released to other normal directions. A background scheduled task initiates a parameterless probe on this URL every 1 minute, reusing the connection timeout, write timeout, and read timeout parameters from the original push. Before platform A's service recovers, the probe continues to fail, and this direction remains circuit breaker silent. In the first detection cycle after platform A's service recovers, the probe request successfully receives an HTTP response, the URL is removed from the failure cache list, the circuit breaker for this direction is lifted, and real-time data push resumes. Throughout this process, platform A's order-related interfaces, being on the whitelist, are unaffected by pushes; even if a push fails, it continues to retry until delivery.

[0032] Example 2: Figure 1 As shown, this embodiment provides a charging platform push system with graded circuit breaking and parameterless health detection. The system is divided into five layers from top to bottom: data source layer, push core layer, circuit breaking control layer, docking target layer, and support configuration layer.

[0033] The data source layer includes charging pile terminals and message queues. Charging pile terminals report pile status, real-time charging data, and order data at fixed intervals. The message queue caches data to be pushed, provides a buffer for peak traffic reported, and delivers messages to be pushed to the core push layer in order.

[0034] The core push layer comprises a message push module and a circuit breaker module, responsible for executing push and circuit breaker logic. The message push module consumes messages from the message queue, iterates through all third-party platform push targets corresponding to the message, and initiates HTTP push requests one by one. If a push fails, it automatically retryes according to the configured retry count for that push direction. Real-time data pushes have zero retries; upon failure, they directly enter the circuit breaker stage. Important interfaces are retried multiple times to ensure delivery as much as possible. The message push module outputs the push results that still fail after retrying to the circuit breaker module. Upon receiving the push failure result, the circuit breaker module matches the current push interface name and determines whether the interface belongs to the important interface whitelist. If it belongs to the whitelist, the process ends directly without any circuit breaker processing, instructing the message push module to continue pushing subsequent messages in that direction normally. If it does not belong to the whitelist, the URL corresponding to the platform is added to the local failure cache list, and the push direction is set to circuit breaker silence; the message push module will no longer push messages in that direction, thus releasing thread and connection resources. The circuit breaker module outputs the circuit breaker information to the health detection module of the circuit breaker management layer.

[0035] The circuit breaker management layer includes a health check module and a circuit breaker recovery module, responsible for managing the silent period and determining service recovery. The health check module is driven by a background scheduled task, iterating through all URLs in the failure cache list according to a check cycle: obtaining the complete URL address of the original failed request, removing all business request parameters, and constructing an HTTP request with empty parameters; reusing the connection timeout, write timeout, and read timeout parameters corresponding to the original business push for that URL; initiating a check request, focusing only on whether the request can receive a normal HTTP response and whether a timeout or connection exception occurs, without verifying the business correctness of the returned content, and outputting the probe results to the circuit breaker recovery module. The circuit breaker recovery module receives the probe results: if the probe request successfully receives an HTTP response and no connection or read / write exception is thrown, it determines that the other party's service has recovered, removes the URL from the failure cache list, releases the circuit breaker silence, and notifies the message push module to resume normal pushes in that direction; if the probe fails, it maintains the circuit breaker silence and waits for the next check cycle to check again. Once a single push direction enters the circuit breaker silence, it remains silent for at least one complete check cycle to avoid frequent state switching due to network jitter.

[0036] The target layer for integration includes various third-party interconnection platforms, such as cooperative charging platforms, government regulatory platforms, and gate systems. The service stability of each target varies significantly. The system implements circuit breaking and recovery at the granularity of the combination of the target platform and the push interface; an anomaly in one direction does not affect normal push notifications in other directions.

[0037] The supporting configuration layer includes a hierarchical configuration module that maintains all policy configurations. The specific policy configurations maintained by the hierarchical configuration module include: a whitelist of important interfaces, recording the interface names of three types of interfaces: charging start result, charging stop result, and charging order information; retry count configuration, recorded separately according to business type and target platform, with a default of 3 times, 0 times for real-time data pushes, and 3-5 times for important interfaces; timeout configuration, recording the connection timeout and read / write timeout for real-time data pushes and other pushes from each target platform, with a default of 2 seconds for real-time data pushes and 5 seconds for others; and detection cycle configuration, recording the circuit breaker detection cycle for each target platform, with a default of 1 minute, which can be shortened to 30 seconds for important partners and extended to 5 minutes for platforms with poor stability. The hierarchical configuration module distributes the policy configurations to the push core layer and the circuit breaker control layer. Configuration changes take effect immediately without requiring a service restart.

[0038] Taking the cooperative charging platform A as an example, the collaboration process of each layer is illustrated as follows: The message queue of the data source layer continuously caches the real-time data reported by the charging piles; after consuming the message, the push module of the push core layer sends an HTTP push request to platform A. If the request times out and fails, and real-time data pushes are retried without exception, the failure result enters the circuit breaker determination module; after matching the interface name, the circuit breaker determination module confirms that the interface is not in the important interface whitelist, adds the URL corresponding to platform A to the local failure cache list, and the push direction enters the circuit breaker silence, and the message push module will no longer push in this direction; the health detection module of the circuit breaker control layer initiates a parameterless probe on the URL at a detection cycle of 1 minute, and the probe reuses the connection timeout, write timeout, and read timeout parameters of the original push; after the platform A service recovers, the probe request successfully receives an HTTP response, the circuit breaker recovery module removes the URL from the failure cache list and lifts the circuit breaker silence, and the message push module resumes pushing real-time data to platform A. During this period, the order-type interfaces of platform A are whitelisted, and the push core layer is not affected by the circuit breaker silence, and the policy configuration of the support configuration layer always takes effect at each layer.

[0039] In this embodiment, the message push module, circuit breaker determination module, health detection module, and circuit breaker recovery module are interconnected to form a complete data loop: The message push module initiates HTTP push requests to multiple target platforms for the message to be pushed, and the failure result is output to the circuit breaker determination module; The circuit breaker determination module determines whether the push interface that still fails after retry belongs to the core interface set. If it does, the push continues without circuit breaking; otherwise, the push direction is set to circuit breaking silence and output to the health detection module; The health detection module takes the URL of the original failed request according to the detection cycle, strips the business parameters, and initiates parameterless probe with the original request timeout parameters. The probe result is output to the circuit breaker recovery module; When the probe receives an HTTP response, the circuit breaker silence is lifted and the push is resumed; otherwise, the circuit breaker silence is maintained until the next detection cycle. Core interfaces never break circuits and deliver to the best of their ability. Non-core interfaces automatically break circuits and are silenced after an anomaly, and are accurately recovered through parameterless probe. This isolates abnormal nodes and prevents service avalanche without affecting core business, thus improving the overall stability of the push system.

[0040] The above are merely preferred embodiments of the present invention and do not limit the present invention. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A method for pushing charging platform data with graded circuit breaking and parameterless health detection, characterized in that, Including the following steps: S1. Obtain multiple target platforms for the message to be pushed, initiate HTTP push requests to each target platform, and retry according to the corresponding strategy if the request fails. S2. If the retry still fails, determine whether the push interface belongs to the preset core interface set. If it does, continue pushing without circuit breaking. If it does not, set the corresponding push direction to circuit breaking silence and pause push. S3. Based on the detection cycle, push the direction of the circuit breaker silence, extract the business parameters from the URL of the original failed request to construct a parameterless probe request, and reuse the timeout parameters of the original request to initiate the probe. S4. If an HTTP response is received, the circuit breaker will be lifted and push notifications will resume. If no response is received, the circuit breaker will remain inactive until the next detection cycle.

2. The charging platform push method with graded fuse breaking and parameterless health detection according to claim 1, characterized in that, In step S2, the core interface set includes the start charging result interface, the stop charging result interface, and the charging order information interface; The charging pile status interface and the real-time charging data interface are not part of the core interface set.

3. The charging platform push method with graded fuse failure and parameterless health detection according to claim 1, characterized in that, In step S1, push interfaces belonging to the core interface set are retried according to the multiple retry strategy; real-time data push interfaces not belonging to the core interface set are not retried, and after a push failure, they directly proceed to the determination in step S2.

4. The charging platform push method with graded fuse failure and parameterless health detection according to claim 1, characterized in that, In step S1, the connection timeout and read / write timeout for each target platform are configured independently; the connection timeout and read / write timeout for real-time data push are shorter than those for charging order push.

5. The charging platform push method with graded fuse breaking and parameterless health detection according to claim 1, characterized in that, In step S2, the combination of the target platform and the push interface is used as the circuit breaker unit, and the target address corresponding to the failed request is written into the failure cache list; different push interfaces of the same target platform independently determine whether to enter the circuit breaker silence.

6. The charging platform push method with graded fuse breaking and parameterless health detection according to claim 1, characterized in that, In steps S3 and S4, the business parameters are stripped by parsing the URL of the original failed request and removing the question mark and all subsequent request parameter fields; the probe only determines whether an HTTP response is received and whether a connection error or read / write error occurs, without verifying the business correctness of the response content.

7. The charging platform push method with graded fuse breaking and parameterless health detection according to claim 1, characterized in that, In step S4, after a single push direction enters the circuit breaker silence, it will be silent for at least one complete detection cycle. During this detection cycle, no probes or pushes will be initiated for that push direction.

8. The charging platform push method with graded fuse failure and parameterless health detection according to claim 1, characterized in that, In step S3, the detection cycle is set according to the service stability level of the target platform. The detection cycle for the target platform with poor service stability is longer than that for the target platform with good service stability.

9. The charging platform push method for graded fuse failure and parameterless health detection according to claim 1 or 8, characterized in that, In step S3, the connection timeout, write timeout, and read timeout of the parameterless probe request are consistent with the connection timeout, write timeout, and read timeout of the original failed push request, respectively.

10. A charging platform push system with graded fuse tripping and parameterless health detection, characterized in that, This includes a message push module, which sends HTTP push requests to multiple target platforms for the message to be pushed, and outputs the failure result to the circuit breaker determination module. The circuit breaker determination module determines whether the push interface that still fails after retry belongs to the core interface set. If it does, the push will continue without circuit breaking. If it does not, the push direction will be set to circuit breaking silence and output to the health detection module. The health detection module takes the URL of the original failed request according to the detection period, strips the business parameters, and initiates a parameterless probe with the original request timeout parameters. The probe result is output to the circuit breaker recovery module. When the circuit breaker recovery module detects and receives an HTTP response, it cancels the circuit breaker silent recovery push; otherwise, it maintains the circuit breaker silence until the next detection cycle.

Images