Instruction distribution method based on gateway cluster and terminal

Abstract

The invention discloses an instruction distribution method based on a gateway cluster and a terminal, and the method comprises the steps: responding to a control request for target equipment, broadcasting a control instruction for the target equipment to the gateway cluster, and enabling each gateway service in the gateway cluster to issue the control instruction to the target equipment; responding to issuing success information returned by the first gateway service in the gateway cluster, and terminating issuing of the control instruction by other gateway services in the gateway cluster; the issuing success information is generated when the first gateway service successfully issues the control instruction to the target equipment; according to the invention, a core mechanism of broadcast instruction and priority response termination is adopted, the step of inquiring the node to which the equipment belongs in advance is avoided, and other issues are terminated immediately after any gateway responds successfully, so that the instruction response time is greatly shortened, and the instruction issuing efficiency is improved; meanwhile, based on a redundant delivery mode of broadcasting the control instruction to the gateway cluster, the risk of instruction loss caused by an inaccurate binding relationship is reduced.

Description

[0001] This case is a divisional application of the patent application with application number 202511320141.6, application date September 16, 2025, entitled "A method for issuing control commands, a terminal and a storage medium". Technical Field

[0002] This invention relates to the field of data transmission technology, and in particular to a method and terminal for distributing instructions based on a gateway cluster. Background Technology

[0003] The "Cloud Fast Charging Protocol" is a standardized communication interface designed specifically for electric vehicle charging stations, aiming to achieve efficient and secure data interaction between charging stations and cloud platforms. Developing a gateway system compliant with this protocol is of significant strategic importance for promoting the construction of charging infrastructure. To achieve high availability of the gateway service, a multi-instance cluster approach is adopted in the deployment architecture. In this case, due to the cluster approach, multiple gateway nodes exist.

[0004] In existing technologies, when a charging pile (or charging gun) is connected to the platform, the information of the server it is currently connected to is recorded based on its access address (IP / port or other identifier).

[0005] When a control command needs to be issued to a gun, the system looks up the "connecting" gateway service for that gun. If the gun is indeed online in the corresponding gateway service, the command is issued directly through that channel; if it is offline (e.g., the device has been disconnected, migrated, or taken over by another service), a rerouting mechanism is triggered to attempt to bind it to a new available gateway service.

[0006] Therefore, charging pile devices frequently experience disconnections, reconnections, and cross-service migrations. The existing mechanism still uses the initial access address as the sole binding basis, which easily leads to "inconsistent states".

[0007] It is evident that the existing technology has at least the following problems: (1) Inaccurate binding between device status and service node leads to command failure or delay.

[0008] The current system relies on the address information of the charging pile when it is first connected for service binding, and lacks a dynamic update mechanism; after the charging pile is disconnected and reconnected or migrated across nodes, the server still retains the old state, causing instructions to be unable to be delivered in time or to be routed incorrectly; the lack of a unified online device status management mechanism leads to frequent "device not found" or "incorrectly sent to other nodes" when issuing instructions.

[0009] (2) The command issuance path is redundant and the response efficiency is low.

[0010] When issuing commands, it is necessary to first query the service node to which the device belongs. If it is not found, rerouting is triggered, which is a cumbersome process. Multiple status confirmation and forwarding operations increase the delay in issuing commands and affect the real-time performance of remote control. For functions that require high-frequency interaction, the performance bottleneck is obvious. Summary of the Invention

[0011] The technical problem to be solved by the present invention is to provide a command distribution method and terminal based on a gateway cluster, which can ensure the efficient distribution of control commands.

[0012] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows: A method for distributing instructions based on a gateway cluster includes the following steps: A gateway cluster is constructed based on instances of deploying gateway services in multiple deployment units of the container orchestration platform. Each gateway service is configured with a fixed address and name through the container orchestration platform. After a device establishes a long connection with a gateway service, an association table between the device and the gateway service is established based on the address and name of the gateway service. Generate a control request for the target device and broadcast the control command for the target device to the gateway cluster; Each gateway service in the gateway cluster determines whether a long connection exists with the target device based on the unique identifier of the target device contained in the control command. If a connection exists, the control command is sent to the target device, and a success message including a success status code and processing result is returned. An action log is generated when the control command sent by the gateway service is executed. In response to the successful delivery information returned by the first gateway service in the gateway cluster, the other gateway services in the gateway cluster are terminated from sending the control command to the target device.

[0013] To solve the above-mentioned technical problems, another technical solution adopted by the present invention is as follows: A gateway cluster-based instruction distribution terminal includes a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the methods described above.

[0014] The beneficial effects of this invention are as follows: It adopts the core mechanism of "broadcast command + priority response termination", which avoids the step of querying the node to which the device belongs in advance, and immediately terminates the other commands after any gateway responds successfully, which greatly shortens the command response time and improves the command delivery efficiency; at the same time, based on the redundant delivery method of broadcasting control commands to the gateway cluster, even if the device has migrated the gateway service, it can still receive and process commands, reducing the risk of command loss due to inaccurate binding relationship. Attached Figure Description

[0015] Figure 1 This is a flowchart of a control command issuance method according to an embodiment of the present invention; Figure 2 This is a schematic diagram of a control command issuing terminal according to an embodiment of the present invention; Label Explanation: 1. A control instruction issuing terminal; 2. A processor; 3. A memory. Detailed Implementation

[0016] To explain in detail the technical content, objectives, and effects of the present invention, the following description is provided in conjunction with the embodiments and accompanying drawings.

[0017] Before detailing the embodiments of this application, some related concepts will first be explained: Gateway cluster: A distributed communication architecture consisting of multiple gateway services, which achieves high availability, load balancing and fault tolerance through the collaborative work of multiple nodes.

[0018] Container orchestration platform: refers to the tools or systems used to automate the entire lifecycle management of containerized applications. Its core functions are to implement operations such as container deployment, scaling, scheduling, load balancing, and fault recovery to ensure that containerized applications run efficiently and stably in a cluster environment.

[0019] Long connection: refers to a connection that is maintained after a client and a server establish a connection, allowing data to be sent and received multiple times on the same connection until one party actively closes the connection.

[0020] Heartbeat: A special data packet sent by a device to the connected gateway service at fixed time intervals. Its core function is to maintain a long connection and provide real-time feedback on the device's online status.

[0021] Health check tools: Health check tools built into container orchestration platforms are used to periodically check whether containers are "alive" (i.e., whether they are running normally, rather than just existing processes that are unresponsive). Examples include the Liveness Probe built into the Kubernetes platform, and Health Checks on AWS ECS (Elastic Container Service), Mesos, and Marathon platforms.

[0022] Kubernetes (K8s) is an open-source container orchestration platform used to automate the deployment, scaling, and management of containerized applications.

[0023] Kubernetes StatefulSet: A controller in Kubernetes used to manage stateful applications.

[0024] Pod: A deployment unit, which is the smallest deployable and manageable unit in Kubernetes.

[0025] In existing technologies, charging pile devices communicate with a gateway service cluster built by the server through long connections. Each gateway service implements long connections with multiple charging pile devices. When the server needs to send control commands to the charging pile devices, it does so through long connection communication between the gateway service and the charging pile devices.

[0026] In scenarios involving issuing commands to charging pile devices, these devices frequently experience disconnections, reconnections, and migrations across services. After these disconnections and reconnections, or migrations across gateway services, the static binding mechanism can easily lead to inconsistent states. In edge computing or multi-region deployment scenarios, when devices frequently switch network environments, it becomes difficult to accurately track their latest location, potentially resulting in commands being sent to the wrong gateway service or the gateway service not being found.

[0027] Therefore, before issuing control commands, the server needs to query the gateway service to which the target device belongs. If it is not found, it will trigger rerouting to establish a connection between the gateway service and the target device. This requires multiple status confirmations and forwardings, which further increases the response time and causes a delay in the issuance of control commands.

[0028] To at least solve the above problems, please refer to Figure 1 This invention provides a method for issuing control commands, including the following steps: In response to a control request for a target device, a control command for the target device is broadcast to the gateway cluster, and each gateway service in the gateway cluster issues the control command to the target device. In response to the successful delivery information returned by the first gateway service in the gateway cluster, the delivery of the control command by other gateway services in the gateway cluster is terminated. The successful delivery information is generated by the first gateway service when it successfully delivers the control command to the target device.

[0029] As can be seen from the above description, the beneficial effects of the present invention are as follows: The control command issuance method of the present invention adopts a core mechanism of broadcasting commands to the gateway cluster and terminating the issuance of control commands to other gateway services upon receiving a successful issuance message from one gateway service. This eliminates the need to pre-query the gateway service to which the target device belongs, directly reducing the redundant process of querying the current gateway service of the device before each command issuance. Furthermore, if the gateway service connected to the target device changes frequently, it may lead to query failures or detours, significantly shortening the response time for command issuance and mitigating efficiency issues caused by path redundancy. Moreover, the immediate termination of command issuance to other gateway services after a successful response from any gateway service greatly shortens the command response time and improves command issuance efficiency. Simultaneously, based on the redundant delivery method of broadcasting control commands to the gateway cluster, even if the target device has changed its connected gateway service, it can still receive and process control commands, reducing the risk of command loss due to inaccurate binding relationships.

[0030] Furthermore, the gateway service communicates with the device via a long-lived connection; The gateway service sends the control commands to the target device, including: The gateway service determines whether a long-term connection with the target device exists based on the information of the target device contained in the control command. The gateway service sends the control command to the target device only when a long-term connection with the target device exists, and returns a success message.

[0031] As described above, the gateway service only issues commands and returns a success message when a persistent connection exists with the target device. This design reduces the transmission of invalid commands and avoids unnecessary processing when the gateway service is not connected to the target device. The broadcast mechanism ensures that commands cover all possible gateway services, while the persistent connection check can filter out gateway services that can effectively process commands. The combination of the two maintains the reliability of redundant delivery while reducing invalid overhead through precise filtering.

[0032] Furthermore, if the successful delivery information is not received and the waiting time reaches a preset first duration, or if all the gateway services return the delivery failure information, then the delivery failure error information is recorded.

[0033] As described above, when all gateway services time out or have no long connection with the target device, the system can proactively record errors to facilitate subsequent troubleshooting (such as device offline or network anomalies) and prevent commands from going unanswered. At the same time, it forms a complete command lifecycle management system—broadcasting → long connection filtering → termination upon success → recording upon failure, which ensures both efficient response and a complete exception handling process.

[0034] Furthermore, the gateway service receives heartbeat packets periodically reported by the device. If it does not receive a heartbeat packet from the first device and the waiting time reaches a preset second duration, the gateway service actively disconnects the long connection with the first device and releases the long connection resources.

[0035] As described above, the gateway service dynamically cleans up invalid long connections that have timed out and failed to respond between the gateway and the device, freeing up system resources; it ensures that the long connection status maintained by the gateway service is accurate in real time, providing a reliable basis for judging long connections; the heartbeat mechanism continuously updates the connection status, making the judgment of "existing long connection" more accurate and avoiding errors in command issuance caused by invalid connections; at the same time, it works in conjunction with the broadcast mechanism to ensure that all gateways within the broadcast range hold valid connection information, improving command processing efficiency.

[0036] Furthermore, the construction of the gateway cluster includes: deploying instances of the gateway service in multiple deployment units of the container orchestration platform, and constructing the gateway cluster based on the deployed instances of the gateway service.

[0037] As described above, the container orchestration platform in this embodiment is Kubernetes. Through containerized deployment, the gateway service can be rapidly scaled up and down to adapt to fluctuations in the number of devices. At the same time, standardized deployment units simplify cluster management and improve system maintainability. The large-scale clusters supported by container orchestration can broadcast to a sufficient number of gateway services to ensure the feasibility of redundant delivery.

[0038] Furthermore, it also includes the following steps: The health check tool of the container orchestration platform is used to check whether the gateway service in each deployment unit is available. If a second gateway service is unavailable, the container orchestration platform will restart the deployment unit of the second gateway service to restore its availability.

[0039] As described above, real-time detection of faulty gateway services and automatic recovery reduce manual intervention and enhance the self-healing capability of the gateway cluster. It ensures that the gateway cluster always maintains sufficient healthy gateway services to support the effective operation of the broadcast mechanism: container orchestration provides a deployment framework, while health checks and restarts ensure the availability of services within the framework, so that broadcast commands can always be received and processed by healthy gateway services, avoiding command loss due to gateway service failures.

[0040] Furthermore, if an unavailable second gateway service exists, the following steps are also implemented: Before the second gateway service is restored, all requests sent to the second gateway service are forwarded to other available gateway services through a load balancing algorithm.

[0041] As described above, before the faulty second gateway service recovers, request forwarding is used to prevent traffic loss and ensure service continuity; request pressure is evenly distributed to improve the overall processing capacity of the gateway cluster. Specifically, in conjunction with health checks, the faulty second gateway service is quickly identified and isolated, and the forwarding mechanism takes effect immediately; in collaboration with the broadcast mechanism, even if some gateway services fail, forwarding can still ensure that instructions are received by valid gateway services, further enhancing fault tolerance and availability.

[0042] Furthermore, it also includes: Each gateway service is configured with a fixed address and name through the container orchestration platform; The device communicates with the gateway service via a long connection. After establishing a long connection with the gateway service, the device establishes an association table with the gateway service based on the address and name of the gateway service and records the action log. The action log is generated when the control command issued by the gateway service is executed.

[0043] As described above, a fixed identifier ensures that the connection relationship between all devices and the gateway service is traceable, and an association table is used to record the connection status, which facilitates log querying and problem localization.

[0044] Please refer to Figure 2 Another embodiment of the present invention provides a control command issuing terminal 1, including a processor 2, a memory 3, and a computer program stored in the memory 3 and executable on the processor 2. When the processor 2 executes the computer program, it implements the steps in the control command issuing method described above.

[0045] Another embodiment of the present invention provides a storage medium on which a computer program is stored, wherein the computer program, when executed, implements the steps in the control command issuance method described above.

[0046] The control command issuance method, terminal, and storage medium described above in this invention are applicable to the issuance of control commands in a server-gateway cluster-device architecture, and are particularly applicable to the issuance of control commands in scenarios where charging pile devices communicate with a gateway service cluster built by the server via a long connection.

[0047] The following describes the specific implementation methods: Please refer to Figure 1 One embodiment of the present invention provides a method for issuing control commands.

[0048] This embodiment illustrates a scenario where the charging pile device communicates with a gateway service cluster built on the server via a long-lived connection. A layered architecture design is adopted, splitting the services into: Connection layer: Responsible for maintaining long-term connections with devices and managing network communication; Business layer: Handles core logic such as charging control and status synchronization.

[0049] The connection layer includes a gateway cluster built on a container orchestration platform, which deploys gateway service instances within the deployment unit of the container orchestration platform.

[0050] The construction of the gateway cluster includes: deploying instances of the gateway service in multiple deployment units of the container orchestration platform, and constructing the gateway cluster based on the deployed instances of the gateway service.

[0051] In this embodiment, the container orchestration platform adopts the Kubernetes platform, which will be referred to as K8s below.

[0052] Specifically, each gateway service is configured with a fixed address and name through the container orchestration platform. After establishing a long-lived connection with the gateway service, the device creates an association table based on the gateway service's address and name and records action logs.

[0053] In this embodiment, Kubernetes Service resources provide stable IP addresses and DNS names for Pods, ensuring service discovery and load balancing. A Kubernetes StatefulSet is used to deploy the gateway service, with fixed instance names (e.g., service-0, service-1) to ensure traceable service addresses and facilitate problem localization; the binding relationship between devices and the gateway service is also stable. StatefulSet itself has the ability to manage stateful applications, automatically assigning a stable network identifier to each Pod. Because each Pod has a fixed network name, such as service-0, service-1, there is a basis for devices to connect to specific Pods. During each deployment process, the application Pod name and service name remain constant. Simultaneously, after the device and gateway service connect, a relationship table is recorded, allowing for quick identification of the corresponding relationship between devices and gateway services, and viewing relevant logs.

[0054] Meanwhile, the gateway service communicates with the device via a persistent connection. The gateway service receives heartbeat packets periodically reported by the device. If it does not receive a heartbeat packet from the first device and the waiting time reaches a preset second duration, the gateway service actively disconnects the persistent connection with the first device and releases the persistent connection resources.

[0055] In this embodiment, the gateway service determines the online status by the heartbeat packets reported by the device at regular intervals. If no heartbeat is received within the timeout period, the connection is actively disconnected to release resources and avoid invalid long connections from consuming system performance.

[0056] Simultaneously, the availability of the gateway service in each deployment unit is periodically checked using the health detection tool of the container orchestration platform. If an unavailable second gateway service exists, the container orchestration platform restarts the deployment unit of the second gateway service to restore its use. Before the second gateway service is restored, all requests sent to the second gateway service are forwarded to other available gateway services through a load balancing algorithm.

[0057] In this embodiment, all gateway nodes (gateway services) are deployed based on Kubernetes and utilize Kubernetes liveness probes to detect whether Pods are alive. If the liveness probe detects that a container is unhealthy (e.g., multiple consecutive HTTP requests returning error status codes, TCP port inaccessibility, or command execution failure), and a preset failure threshold is reached, the container is determined to be in a non-live state. Kubernetes considers the Pod unavailable and attempts to restart it to ensure that the application does not stop due to a single point of failure. Simultaneously, the Service automatically distributes traffic to healthy Pods; if the current Pod is in an unavailable state, traffic will not be redirected to that Pod.

[0058] In addition, in this embodiment, a logging and monitoring function is deployed based on Prometheus+Grafana. If the status of the Pod is not right, the company's operations and maintenance personnel will be notified to ensure the availability of the Pod as soon as possible.

[0059] In the specific instruction issuance steps, in response to the control request for the target device, a control instruction for the target device is broadcast to the gateway cluster, and each gateway service in the gateway cluster issues the control instruction to the target device.

[0060] In this embodiment, when issuing control commands, a message is broadcast to all gateway services (sending HTTP requests to multiple gateway services), and each gateway service handles the request autonomously based on its local connection status (connection status with the charging pile device). Specifically: The gateway service communicates with the device via a long-lived connection. The gateway service sends the control commands to the target device, including: The gateway service determines whether a long-term connection with the target device exists based on the information of the target device contained in the control command. The gateway service sends the control command to the target device only when a long-term connection with the target device exists, and returns a success message; otherwise, it returns a failure message.

[0061] In this embodiment, after receiving an HTTP request, the gateway service checks the unique identifier (target device information) in the control command and, in conjunction with the charging pile device it is connected to, determines whether the control command is valid. If the command is valid, it returns an HTTP 200 status code and the processing result (ACK) after processing is completed; if the command is invalid or the processing fails, it returns an HTTP 500 status code or other error information (NACK).

[0062] In response to the successful delivery information returned by the first gateway service in the gateway cluster, the delivery of the control command by other gateway services in the gateway cluster is terminated. The successful delivery information is generated by the first gateway service when it successfully delivers the control command to the target device.

[0063] In this embodiment, once a gateway service successfully responds (ACK), other requests are immediately terminated, and waiting for other gateway services is stopped, balancing system response speed and command reliability.

[0064] If the successful delivery message is not received and the waiting time reaches the preset first duration, or if all the gateway services return the delivery failure message, then the delivery failure error message is recorded.

[0065] In addition, a timeout mechanism is set in this embodiment to wait for the response from the first gateway service. If all gateway services fail (return NACK) or time out, an error is logged.

[0066] In this embodiment, the layered architecture decouples the connection layer from the business layer, allowing the connection layer to focus on maintaining long-lived connections to ensure communication stability, while the business layer focuses on core logic to improve processing efficiency. K8s StatefulSet deployment assigns gateways fixed identifiers and stable network identities, and combined with an association table, enables traceability of device-gateway service bindings, facilitating problem localization. A heartbeat mechanism dynamically cleans up invalid long-lived connections, avoiding resource waste while ensuring real-time and accurate connection status. K8s liveness probes, automatic restart, and load balancing work in tandem to achieve self-healing of gateway cluster faults, ensuring service continuity. A broadcast command + race-to-terminate mechanism eliminates redundant query steps, ensuring command delivery through redundant delivery and shortening latency with the fastest response. Timeout and error logging mechanisms improve exception handling and enhance system robustness.

[0067] Meanwhile, the heartbeat mechanism maintains accurate connection status, enabling the gateway service to accurately determine whether to process broadcast commands and avoid invalid operations. Kubernetes health checks ensure that all gateway services within the broadcast range are available, and load balancing ensures that faulty gateway services do not affect command delivery. The broadcast and racing mechanisms utilize the multi-node characteristics of the cluster to achieve "wide coverage + fast response" with the support of healthy gateway services, ultimately forming a closed loop of "stable connection → reliable cluster → efficient commands → perfect anomaly handling," comprehensively improving the real-time performance, reliability, and maintainability of communication between charging piles and the cloud.

[0068] According to another aspect of the invention, Figure 2 This is a schematic diagram illustrating a control command issuing terminal 1 according to an embodiment of the present invention. It includes a processor 2, a memory 3, and a computer program stored in the memory 3 and executable on the processor 2. When the processor 2 executes the computer program, it implements the steps in the control command issuing method described in Embodiment 1 above.

[0069] According to another aspect of the present invention, a storage medium is provided on which a computer program is stored, wherein when the computer program is executed, the steps of the control instruction issuing method described in Embodiment 1 above are implemented.

[0070] The above description is merely an embodiment of the present invention and does not limit the patent scope of the present invention. Any equivalent modifications made based on the content of the present invention specification and drawings, or direct or indirect applications in related technical fields, are similarly included within the patent protection scope of the present invention.

Claims

1. A method for distributing instructions based on a gateway cluster, characterized in that, Including the following steps: A gateway cluster is constructed based on instances of gateway services deployed in multiple deployment units of the container orchestration platform, and a fixed address and name are configured for each gateway service through the container orchestration platform. After establishing a long connection with the gateway service, the device creates an association table between the device and the gateway service based on the address and name of the gateway service. Generate a control request for the target device and broadcast the control command for the target device to the gateway cluster; Each gateway service in the gateway cluster determines whether a long connection exists with the target device based on the unique identifier of the target device contained in the control command. If a connection exists, the control command is sent to the target device, and a success message including a success status code and processing result is returned. An action log is generated when the control command sent by the gateway service is executed. In response to the successful delivery information returned by the first gateway service in the gateway cluster, the other gateway services in the gateway cluster are terminated from sending the control command to the target device.

2. The method according to claim 1, characterized in that, If it exists, the control command is sent to the target device, and a success message is returned. The command also includes: If the successful delivery message is not received and the waiting time reaches the preset first duration, or if all the gateway services return delivery failure messages, then the delivery failure error message is recorded. The gateway service receives heartbeat packets periodically reported by the devices in long-connection communication. If it does not receive a heartbeat packet from the first device and the waiting time reaches a preset second duration, the gateway service actively disconnects the long connection with the first device and releases the long-connection resources.

3. The method according to claim 1, characterized in that, It also includes the following steps: The availability of the gateway service in each deployment unit is detected by the liveness probe of the container orchestration platform. If a second gateway service is unavailable, the container orchestration platform will restart the deployment unit of the second gateway service to restore its availability.

4. The method according to claim 3, characterized in that, The availability of the gateway service in each deployment unit is detected using the liveness probe of the container orchestration platform, including: When the liveness probe detects multiple consecutive HTTP requests returning error status codes, TCP ports failing to connect, or command execution failing, and reaches a preset failure threshold, it determines that the container is in a non-live state, indicating that an unavailable second gateway service exists.

5. The method according to claim 3, characterized in that, If an unavailable second gateway service exists, the following steps should also be implemented: Before the second gateway service is restored, all requests sent to the second gateway service are forwarded to other available gateway services through a load balancing algorithm.

6. A gateway cluster-based instruction distribution terminal, comprising a processor, a memory, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it performs the following steps: A gateway cluster is constructed based on instances of gateway services deployed in multiple deployment units of the container orchestration platform, and a fixed address and name are configured for each gateway service through the container orchestration platform. After establishing a long connection with the gateway service, the device creates an association table between the device and the gateway service based on the address and name of the gateway service. Generate a control request for the target device and broadcast the control command for the target device to the gateway cluster; Each gateway service in the gateway cluster determines whether a long connection exists with the target device based on the unique identifier of the target device contained in the control command. If a connection exists, the control command is sent to the target device, and a success message including a success status code and processing result is returned. An action log is generated when the control command sent by the gateway service is executed. In response to the successful delivery information returned by the first gateway service in the gateway cluster, the other gateway services in the gateway cluster are terminated from sending the control command to the target device.

7. The terminal according to claim 6, characterized in that, If it exists, the control command is sent to the target device, and a success message is returned. The command also includes: If the successful delivery message is not received and the waiting time reaches the preset first duration, or if all the gateway services return delivery failure messages, then the delivery failure error message is recorded. The gateway service receives heartbeat packets periodically reported by the devices in long-connection communication. If it does not receive a heartbeat packet from the first device and the waiting time reaches a preset second duration, the gateway service actively disconnects the long connection with the first device and releases the long-connection resources.

8. The terminal according to claim 6, characterized in that, It also includes the following steps: The availability of the gateway service in each deployment unit is detected by the liveness probe of the container orchestration platform. If a second gateway service is unavailable, the container orchestration platform will restart the deployment unit of the second gateway service to restore its availability.

9. The terminal according to claim 8, characterized in that, The availability of the gateway service in each deployment unit is detected using the liveness probe of the container orchestration platform, including: When the liveness probe detects multiple consecutive HTTP requests returning error status codes, TCP ports failing to connect, or command execution failing, and reaches a preset failure threshold, it determines that the container is in a non-live state, indicating that an unavailable second gateway service exists.

10. The terminal according to claim 8, characterized in that, If an unavailable second gateway service exists, the following steps should also be implemented: Before the second gateway service is restored, all requests sent to the second gateway service are forwarded to other available gateway services through a load balancing algorithm.

Images