Charging pile platform uninterrupted service publishing system and method

Abstract

The invention discloses a charging pile platform uninterrupted service publishing system and method, the system comprises a charging pile end, a TCP server and a service server, and a configuration center is deployed between the TCP server and the service server. According to the method, a to-be-updated service server cluster list is obtained from a configuration center, a target service server is determined, a service message is formed and forwarded to a charging pile end for deployment, and after the target service server confirms that the service of the charging pile end is normal through health check, the target service server is added into a routing list again. According to the invention, the TCP connection management and the business logic processing are thoroughly decoupled, so that the long connection between the charging pile and the front TCP server does not need to be disconnected when the platform service issues a new version. The service request of the charging pile and the channel for receiving the response are always kept smooth, so that the interruption or delay of the charging service caused by service release is completely eliminated, a user can complete service updating without perception, and the user experience and the overall service availability of the system are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of electric vehicle charging pile platform service publishing technology, and in particular to a charging pile platform uninterrupted service publishing system and method. Background Technology

[0002] In the operation and management of electric vehicle charging facilities, the number of networked charging piles is enormous, often exceeding hundreds of thousands. Currently, data communication between the charging piles and the back-end operation platform generally uses TCP long connections. This architecture ensures the real-time performance and reliability of data transmission. However, in the practical application of this technical solution, especially when the platform service needs to be updated or released, a series of significant technical defects have been exposed.

[0003] The existing technology works by proactively disconnecting the persistent TCP connections with all charging station terminals when a new version of the platform service is released. After detecting the disconnection, the charging station needs to re-establish the TCP connection and complete the full login authentication process before normal business interaction can resume. This mechanism has three main problems:

[0004] First, service deployment is inefficient: Because it involves disconnecting and rebuilding all connections, the entire deployment process becomes lengthy and complex, extending the service deployment cycle to hours, severely impacting business agility. Second, there are platform stability risks: After deployment, a large number of charging piles will attempt to reconnect and log in within a short period, causing a huge instantaneous traffic surge to the platform server, easily leading to service overload, response delays, or even system crashes, threatening the overall stability of the system. Third, user experience is compromised: During the connection disconnection and reconnection process, the business interaction between the charging pile and the platform will be interrupted. If users are performing operations such as charging or payment at this time, it will directly lead to operation failure or delay, significantly impacting the user experience and resulting in a strong perception of the issue.

[0005] For example, the invention application with application number 202210178386.X discloses a hot upgrade system and method for the charging pile service program of an electric vehicle charging service platform. Although the solution in this application maintains the connection to the charging pile through improvements, and can ensure that the platform service does not need to be restarted during the upgrade and the charging service is not interrupted during the upgrade, the solution also has the problem that the TCP server and the business server interact, which is not conducive to improving the efficiency of service release.

[0006] Therefore, in reality, there is a need for a technical solution that can efficiently and smoothly deploy services without interrupting existing TCP connections, in order to overcome the shortcomings of the existing technologies mentioned above. Summary of the Invention

[0007] To address the aforementioned problems, the present invention aims to provide a system and method for uninterrupted service publishing on a charging pile platform, thereby resolving issues such as low service publishing efficiency, high platform stability risks, and compromised user experience.

[0008] The objective of this invention can be achieved through the following technical solution: a charging pile platform uninterrupted service publishing system, comprising:

[0009] At the charging pile end, a TCP server is connected to form a business application, which sends and receives business packets forwarded by the TCP server.

[0010] A TCP server connects to the business server and forwards business packets.

[0011] The business server processes business applications and generates business response messages.

[0012] A configuration center is deployed between the TCP server and the business server to store the association between the TCP server and the business server.

[0013] As a further embodiment of the present invention, the TCP server adopts the Netty framework to implement high-concurrency charging pile connection management, and a single TCP server maintains no less than 100,000 long connections to charging piles at the same time.

[0014] As a further embodiment of the present invention, the TCP server uses a heartbeat detection mechanism to determine the connection status of the charging pile. If there is no response after a timeout, it actively initiates a reconnection request to maintain a stable connection.

[0015] As a further embodiment of the present invention, the system adopts a uniform message format, the TCP server verifies the message magic number and length, does not parse the message content, and the TCP server message forwarding delay is no more than 10ms.

[0016] As a further embodiment of the present invention, Nacos is used as the configuration center between the TCP server and the business server.

[0017] As a further embodiment of the present invention, the service server is divided into a core service server and a non-core service server, wherein:

[0018] The core business server is used to handle core business processes such as charging start / stop, electricity cost calculation, payment callback, and device status reporting.

[0019] Non-core business servers are used to handle non-core business tasks such as data statistics, report generation, historical record query, and user message push.

[0020] As a further embodiment of the present invention, the core business server and non-core business servers are deployed in isolation, and the core business server is equipped with high hardware resources and independent database tables.

[0021] As a further embodiment of the present invention, the core business server adopts a redundant deployment and fault isolation mechanism.

[0022] A method for uninterrupted service delivery on a charging pile platform includes the following steps:

[0023] S1. Based on the TCP server, obtain the list of business server clusters to be updated from the configuration center;

[0024] S2. Identify the target business server and remove it from the routing list on the TCP server side;

[0025] S3. Wait for the target business server to finish processing the existing business, form a business message, forward it to the charging pile terminal for deployment and startup;

[0026] S4. After the target service server confirms that the charging pile service is normal through a health check, it will re-add the charging pile to the routing list.

[0027] S5. Repeat steps S1 to S4 until all servers are updated.

[0028] The beneficial effects of this invention are:

[0029] 1. This invention completely decouples TCP connection management from business logic processing, eliminating the need to disconnect the long-lived connection between the charging pile and the front-end TCP server when a new version of the platform service is released. The channels for charging pile business requests and response reception remain uninterrupted, thus completely eliminating charging service interruptions or delays caused by service releases. This allows users to complete service updates without noticing, significantly improving user experience and overall system service availability, achieving zero service interruption during service releases, and greatly enhancing user experience and system availability.

[0030] 2. This invention allows service processing servers to publish services in rotation, with the entire publishing process seamless for users, reducing the publishing time from hours to minutes. Simultaneously, stable TCP connections prevent the massive instantaneous load on the system caused by all charging piles simultaneously reconnecting and logging in, fundamentally eliminating the risk of service avalanche. This greatly enhances the smoothness of the publishing process and system stability, significantly shortens the service publishing cycle, effectively avoids the risk of instantaneous traffic surges, and ensures system stability.

[0031] 3. The business processing server of this invention can flexibly and quickly scale horizontally up or down according to actual business volume without changing the TCP connection layer. This one-to-many relationship mechanism and load balancing strategy not only optimizes resource allocation and avoids single-point bottlenecks, but also makes daily operation and maintenance, fault isolation, and capacity adjustment more convenient and efficient, enabling the system to better adapt to dynamic changes in business volume. This enhances the elasticity and scalability of the system architecture, improving operational efficiency and resource utilization. Attached Figure Description

[0032] Figure 1 This is a schematic diagram of the uninterrupted service publishing system for the charging pile platform of the present invention;

[0033] Figure 2 This is a flowchart illustrating the uninterrupted service publishing method for the charging pile platform of the present invention. Detailed Implementation

[0034] Embodiments of the present invention are described in detail below. Examples of these embodiments are illustrated in the accompanying drawings, wherein the same or similar symbols denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and should not be construed as limiting the present invention.

[0035] The current charging pile terminal and platform service use a TCP long connection mode for data interaction. When the platform service releases a new version, it will trigger a forced disconnection of the TCP connection on the charging pile terminal, and the connection and login process must be re-initiated. This mechanism has the following problems: First, it prolongs the service release cycle and reduces efficiency; second, a large number of charging piles re-login at the same time will cause a sudden traffic impact on the platform service, which poses a stability risk; third, the connection disconnection and reconnection process will directly affect the user experience, which is noticeable.

[0036] To address the aforementioned problems, this invention discloses a system and method for uninterrupted service publishing on a charging pile platform. This system solves the problems of long service publishing cycles and low efficiency in existing data interaction mechanisms between charging piles and platform services, the stability risks caused by a large number of charging piles logging in simultaneously and experiencing instantaneous traffic surges, and the impact of connection drops and reconnections on user experience.

[0037] Example 1:

[0038] like Figure 1 As shown, this embodiment discloses an uninterrupted service publishing system for a charging pile platform. The system includes three main parts: a charging pile terminal, a TCP server, and a business server, forming a three-layer interactive architecture of "charging pile terminal - TCP server - business processing server". Each of the three layers has its own core responsibilities, preventing functional overlap.

[0039] The charging pile connects to a TCP server to form a business application, which sends and receives business messages forwarded by the TCP server.

[0040] The charging pile terminal acts only as a terminal device, responsible for initiating connection requests to the TCP server and receiving service responses. In this solution, it no longer interacts directly with the service server.

[0041] The charging pile terminal is the business application terminal, responsible for interacting with users and receiving users' charging requests, payment instructions, and other operations.

[0042] The charging station terminal collects various operational data in real time, such as charging capacity, charging duration, and equipment status. It possesses some data processing capabilities, enabling preliminary organization and analysis of the collected data. The processed data is then transmitted to the business server via a TCP server to generate business application requirements. Based on the message instructions forwarded by the business server from the TCP server, the charging station terminal precisely controls the operation of the charging station.

[0043] The TCP server connects the business server and the charging pile terminal to forward business packets. The front-end TCP server acts as an intermediate layer, focusing on TCP connection management and packet forwarding, and does not participate in any business logic calculations.

[0044] In the deployment of charging piles, they are often deployed over a large area, forming a nationwide network with hundreds of thousands to millions of charging piles. In the existing charging pile platform service, the TCP server and business server are often set up in a mixed manner. When a new version of the platform service is released, it will trigger the TCP connection on the charging pile side to be forcibly disconnected, and the connection and login process needs to be re-initiated, which will cause many problems.

[0045] With the TCP server positioned in front, it only handles TCP connection management and packet forwarding, without participating in any business logic calculations. Therefore, when a new version of the platform service is released, it will no longer trigger a forced disconnection of the charging pile's TCP connection. This eliminates the need for the charging pile to re-initiate the connection and login process, avoiding time delays caused by connection interruptions and re-login, significantly improving service continuity and stability. Users will not be affected by platform service updates during charging, enabling continuous and stable charging operations and enhancing the user experience.

[0046] The TCP server no longer participates in business logic calculations, significantly improving its processing efficiency. It can more quickly and accurately complete the TCP connection management and packet forwarding tasks for a massive number of charging piles. The business server can focus on processing business logic, improving the overall system's operating efficiency and response speed, reducing the probability of system failures, and ensuring the efficient and stable operation of the charging pile platform service.

[0047] The business server connects to the TCP server. The business server is used to process business applications and generate business response messages. The business processing server focuses on business processing, interacts with middleware such as databases and Redis, and only exchanges messages with the TCP server.

[0048] This architecture allows the business server to focus entirely on implementing business logic, ensuring the accuracy and efficiency of business processing. Through close collaboration with databases and middleware such as Redis, the business server can quickly acquire and store critical data, providing strong support for the smooth operation of business applications.

[0049] The TCP server acts as a bridge between the service server and the charging pile terminal. It receives service request messages from the charging pile terminal and forwards them accurately to the service server. Simultaneously, the TCP server receives service response messages generated by the service server and promptly sends them back to the corresponding charging pile terminal. This clearly defined architecture allows each part of the system to perform its specific function, fully leveraging its strengths, thereby improving the overall operational efficiency and service quality of the charging pile platform.

[0050] A front-end TCP server can be configured to associate with multiple business servers, forming a one-to-many forwarding relationship. The TCP server will distribute the received business requests evenly to the back-end business servers based on preset strategies (such as round-robin and load balancing), which not only avoids overloading a single business server, but also lays the foundation for the "round-robin" release of subsequent business services.

[0051] A configuration center is deployed between the TCP server and the business server to store the association between the TCP server and the business server. In the three-layer architecture of "charging pile-TCP server-business processing server", the TCP server needs to know which business processing servers are available and how to route requests to them.

[0052] When a business processing server starts up, it registers its address with the configuration center. The TCP server then dynamically pulls a list of available business processing servers from the configuration center. When a business processing server goes offline due to deployment, expansion, or failure, the TCP server can immediately detect the latest service instance status without restarting or modifying the configuration file.

[0053] The configuration center serves as the central hub connecting the TCP server and the business processing server. Through dynamic service discovery, flexible routing configuration, and centralized parameter management, it provides crucial technical support for the decoupling and scalability of the architecture, as well as enabling seamless round-robin deployment, ensuring the efficient and stable operation of the entire system.

[0054] Preferably, Nacos is used as the configuration center between the TCP server and the business server.

[0055] When Nacos is used as a configuration center, it can also act as a service center, managing the address list of all services. When a business processing server comes online, it registers its address with Nacos. The TCP server queries Nacos and calls the business processing server. This makes the calls between services independent of fixed IP addresses, enabling dynamic service discovery and elastic scaling.

[0056] When Nacos is used as a configuration center, it can also centrally manage the configuration information required by all services. When the configuration changes, Nacos can notify each TCP server in real time, enabling it to dynamically obtain the new configuration without restarting the application.

[0057] Example 2:

[0058] This embodiment optimizes TCP server management based on embodiment 1, thereby better leveraging the role of the TCP server.

[0059] Preferably, the TCP server uses the Netty framework to implement high-concurrency charging pile connection management, and a single TCP server can maintain no less than 100,000 long connections to charging piles at the same time.

[0060] The Netty framework is used to implement high-concurrency TCP connection management, which supports a single server to maintain more than 100,000 long connections to charging piles at the same time, greatly improving the system's concurrency processing capability and stability.

[0061] Netty's asynchronous non-blocking I / O capabilities enable the TCP server to efficiently utilize system resources when handling a large number of connections, reducing the overhead of thread creation and switching. Through an event-driven mechanism, the TCP server can respond quickly to critical events such as connection establishment and data reading / writing, ensuring real-time and accurate interaction between the charging station and the TCP server.

[0062] The Netty framework also provides a rich set of encoding and decoding tools, which can easily process the data transmitted between the charging station and the TCP server.

[0063] Furthermore, multiple TCP servers using the Netty framework are grouped into a cluster, and load balancing technology is used to evenly distribute connection requests from charging piles across the various TCP servers. This not only improves the overall processing capacity of the system but also automatically transfers connection requests to other normally functioning servers when one server fails, ensuring uninterrupted service.

[0064] Preferably, the TCP server uses heartbeat detection to determine the connection status. If there is no response within a timeout period, it actively initiates a reconnection request to ensure connection stability. The time interval of heartbeat detection can be flexibly adjusted according to the actual network environment and business needs.

[0065] Furthermore, to avoid frequent reconnections caused by temporary interference such as network jitter, the system also sets limits on the number of reconnections and a reconnection waiting time. When the number of reconnections reaches the preset limit and still fails, the system will record the fault information and notify the operations and maintenance personnel for manual intervention. The reconnection waiting time will gradually increase with the number of reconnections to prevent the continuous initiation of invalid reconnection requests before the network returns to normal.

[0066] Preferably, the system uses a unified message format. With a unified message format, the TCP server verifies the message magic number and length without parsing the message content, improving processing efficiency. The TCP server message forwarding delay is no greater than 10ms. A unified message format also facilitates data interaction and processing between different servers, enabling the entire cluster system to operate more efficiently and stably.

[0067] Example 3:

[0068] This embodiment optimizes the management of the business server based on embodiment 1 or 2, so as to better leverage the role of the business server.

[0069] Preferably, the business servers are divided into core business servers and non-core business servers, wherein:

[0070] The core business server is used to handle core business processes such as charging start / stop, electricity cost calculation, payment callback, and device status reporting.

[0071] Preferably, the core business servers are deployed redundantly, with replicas of the core business servers configured. When one core business server fails, other backup core business servers can quickly take over its work, ensuring the continuous and stable operation of core services. When a core business server fails, the TCP server immediately marks it as faulty and forwards all core business requests to other normal core servers.

[0072] The redundantly deployed core business servers perform real-time data synchronization to ensure data consistency and accuracy. Regarding load balancing, the system rationally allocates core business requests based on the load of each core business server, preventing some servers from being overloaded while others are idle, thus further improving the overall system performance and processing efficiency.

[0073] This redundant deployment can effectively improve the reliability and availability of the system and reduce business interruption time caused by server failure.

[0074] Non-core business servers are used to handle non-core business tasks such as data statistics, report generation, historical record queries, and user message pushes. These tasks have relatively low real-time requirements but involve large data volumes. The non-core business servers adopt a distributed architecture, with multiple server nodes jointly undertaking the processing tasks to improve processing capacity and efficiency. The nodes are connected and interact with each other via a high-speed network to ensure timely data transmission and sharing.

[0075] Preferably, Prometheus is used to monitor the business processing success rate, response time, and error code distribution of all business servers. For core business servers, additional key indicators such as database connection count and cache hit rate are monitored to comprehensively and accurately grasp the server's operating status.

[0076] Prometheus collects data on these metrics at preset time intervals and stores the collected data in a time-series database. By monitoring the success rate of business processing, one can intuitively understand the effectiveness of the server in processing business. If the success rate drops significantly, it may indicate a performance bottleneck on the server or a problem with the business logic. The system sets corresponding thresholds for these monitoring metrics. When a metric exceeds the threshold, an alarm mechanism is triggered in a timely manner to notify operations and maintenance personnel to handle the situation.

[0077] Preferably, core business servers and non-core business servers are deployed in isolation, preferably using physical isolation on different servers. The core business servers are equipped with high-end hardware resources and independent database partitioning to ensure stable operation and data security of core business processes. Non-core business servers can flexibly allocate hardware resources according to business needs, using relatively economical configurations. Independent database partitioning enables more efficient data management for core business processes, facilitating data backup, recovery, and optimization.

[0078] This isolated deployment method can effectively avoid non-core business from interfering with core business. When a non-core business fails, the TCP server directly stops forwarding requests to it, and the non-core business is temporarily unavailable, but it does not affect the routing of core business. When a core business server fails, the TCP server immediately marks it as a failure and forwards all core business requests to other normal core business servers.

[0079] Based on the above core business server and non-core business server structure, this system can decouple core business from non-core business, and non-core business failures will not spread to critical links such as charging and billing, thus ensuring users' basic usage needs.

[0080] The core business has high disaster recovery capabilities. When a single server fails, the switching time is less than 3 seconds, and the core business interruption time is controlled at the second level, which is far below the industry average.

[0081] Resource allocation is more rational, with core businesses receiving priority resource guarantees, while non-core businesses can scale elastically based on traffic, reducing overall operation and maintenance costs.

[0082] Example 4:

[0083] This embodiment, based on the system structure of the above embodiments, discloses a method for uninterrupted service publishing on a charging pile platform, such as... Figure 2 As shown, the steps include:

[0084] S1. Based on the TCP server, obtain the list of business server clusters to be updated from the configuration center.

[0085] S2. Identify the target business server and remove it from the routing list on the TCP server side;

[0086] S3. Wait for the target business server to finish processing the existing business, form a business message, forward it to the charging pile terminal for deployment and startup;

[0087] S4. After the target service server confirms that the charging pile service is normal through a health check, it will re-add the charging pile to the routing list.

[0088] S5. Repeat steps S1 to S4 until all servers are updated.

[0089] In scenarios where multiple business processing server clusters are deployed, an orderly round-robin release strategy ensures that the connection between the charging pile and the TCP server remains uninterrupted and the charging business is unaware of the update when the service version is updated, thus completely solving the efficiency and stability issues of connection disconnection and centralized reconnection in traditional releases.

[0090] Taking the deployment process of a single server as an example:

[0091] Before release, the system obtains the association between the current TCP server and the business server from the configuration center, clarifies the release order, and deploys the new version code to the spare directory of the business server to be updated in advance.

[0092] Step 1: The TCP server suspends forwarding new requests to the target business server, retains only its ability to process existing business, and marks the target business server as being in a publishing state.

[0093] Step 2: Wait for the target business server to complete the processing of existing requests, ensuring no business interruption or data residue.

[0094] Step 3: Stop the old version process of the target business server, start the new version process, and complete the code update.

[0095] Step 4: After the new version is launched, verify the availability of the charging pile terminal service through the health check interface.

[0096] Step 5: After the health check is passed, the TCP server resumes forwarding business requests to the business server, puts it back into the load balancing queue, and completes the deployment of a single business server.

[0097] When the business server cluster is fully deployed in a loop, the deployment process for a single business server is repeated, and then the second and third business servers are deployed and updated in sequence, until all business servers in the cluster have completed the version iteration.

[0098] Furthermore, during the deployment process, the TCP server uses a round-robin / load balancing strategy to distribute requests to servers that are not in the deployment state, ensuring that the overall business processing capacity does not decrease.

[0099] During the service launch, the connection between the charging piles and the TCP server remained stable, ensuring a seamless user experience for core operations such as charging and payment, completely eliminating user experience issues caused by connection drops. This also avoids the platform traffic surge caused by a large number of charging piles reconnecting simultaneously.

[0100] Business deployment efficiency has been greatly improved. A full update of a business server cluster of up to 5 units can be completed within 10 minutes, which significantly reduces the time required compared to traditional hourly deployments.

[0101] The method of this invention effectively ensures the stable operation of the charging pile platform during business server updates. On one hand, because the TCP server can accurately and reasonably allocate requests, the entire platform can still efficiently process business even when some servers are performing updates, greatly improving the platform's service quality and reliability. On the other hand, for charging pile users, their core operations such as charging and payment are not affected by business server updates, ensuring a smooth and stable service experience. Simultaneously, it significantly shortens business release time, improves release efficiency, and reduces maintenance costs. When facing sudden changes in business requirements or system vulnerability fixes, it can quickly iterate the business server version, responding promptly to market changes and ensuring system security. It avoids the traffic surge caused by a large number of charging piles reconnecting simultaneously, reducing the probability of system failures and making the platform operate more smoothly and efficiently.

[0102] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A continuous service publishing system for a charging pile platform, characterized in that, include: At the charging pile end, a TCP server is connected to form a business application, which sends and receives business packets forwarded by the TCP server. A TCP server connects to the business server and forwards business packets. The business server processes business applications and generates business response messages. A configuration center is deployed between the TCP server and the business server to store the association between the TCP server and the business server.

2. The system according to claim 1, characterized in that, The TCP server uses the Netty framework to manage high-concurrency charging pile connections, and a single TCP server can maintain no fewer than 100,000 long connections to charging piles simultaneously.

3. The system according to claim 2, characterized in that, The TCP server uses a heartbeat detection mechanism to determine the connection status of the charging pile. If there is no response within a timeout period, it will actively initiate a reconnection request to maintain a stable connection.

4. The system according to claim 1, characterized in that, The system uses a uniform message format, the TCP server verifies the message magic number and length, does not parse the message content, and the TCP server message forwarding delay is no more than 10ms.

5. The system according to claim 1, characterized in that, The TCP server and the business server use Nacos as the configuration center.

6. The system according to claim 1, characterized in that, The business servers are divided into core business servers and non-core business servers, among which: The core business server is used to handle core business processes such as charging start / stop, electricity cost calculation, payment callback, and device status reporting. Non-core business servers are used to handle non-core business tasks such as data statistics, report generation, historical record query, and user message push.

7. The system according to claim 6, characterized in that, The core business server is deployed in isolation from the non-core business server, and the core business server is equipped with high hardware resources and independent database tables.

8. The system according to claim 6, characterized in that, The core business server adopts redundant deployment and fault isolation mechanism.

9. The system according to claims 1 to 8, characterized in that, A method for uninterrupted service delivery on a charging pile platform includes the following steps: S1. Based on the TCP server, obtain the list of business server clusters to be updated from the configuration center; S2. Identify the target business server and remove it from the routing list on the TCP server side; S3. Wait for the target business server to finish processing the existing business, form a business message, forward it to the charging pile terminal for deployment and startup; S4. After the target service server confirms that the charging pile service is normal through a health check, it will re-add the charging pile to the routing list. S5. Repeat steps S1 to S4 until all servers are updated.

Images