Method and device for realizing remote debugging and repairing of gateway based on cloud platform, and medium
By establishing an intranet penetration channel between the cloud platform and the gateway, precise management and troubleshooting of remote gateways are achieved, which solves the problem in the existing technology that fault repair requires large-area system upgrades, and improves the efficiency of fault repair. and user experience.
Patent Information
- Application Number
- CN202411520750.1
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-10-29
- Publication Date
- 2025-01-21
AI Technical Summary
The existing technology cannot achieve accurate management and troubleshooting of remote gateways, resulting in large-scale system upgrades required for fault repair, resulting in business interruption.
By deploying the FRP server on the cloud platform and the FRP client on the gateway, an intranet penetration channel is established to realize remote access and repair of the gateway from the cloud platform, avoiding large-scale system upgrades.
The precise management and fault investigation of the remote gateway can be achieved, and remote debugging and restoration can be performed without interrupt business, which improves the efficiency and user experience of fault repair.
Smart Images

Figure CN119341887A_ABST
Abstract
Description
Technical Field
[0001] The present invention relates to the field of gateway remote processing technology, and in particular to a method, device and medium for implementing gateway remote debugging and repair based on a cloud platform. Background Art
[0002] In the existing solution, most of the gateway configuration can only be done locally. Since the cloud platform uses a public network address, and the gateway is connected to the cloud platform through a wired or 4G / 5G network, although the gateway can connect to the cloud platform, the cloud platform cannot reversely connect to the gateway to access the gateway system. Since the cloud platform manages the remote gateway at a coarse granularity, there is no way to achieve more precise management. Therefore, after a gateway fails, the cloud platform can only simply know the gateway's online, offline, and operating status. There is no way to conduct further problem analysis and testing on the operation of the remote gateway through the cloud platform.
[0003] After the problem is identified, if you want to solve it, you can only upgrade the entire system of each gateway through the cloud platform, which will cause business interruption to users, especially when the upgrade frequency is frequent, which will be more obvious and bring a bad experience to users. Summary of the invention
[0004] In view of this, the purpose of the present invention is to propose a method for remote debugging and repair of gateways based on a cloud platform, thereby improving the management granularity of the cloud platform for remote gateways, and allowing users to know the operating status of each gateway at any time; when a gateway fails but can still connect to the cloud platform, not only can the cause of the failure of the gateway system be identified, but remote debugging can also be performed until the gateway system is remotely repaired, and normal operation can continue without the need for a large-scale upgrade of the gateway system.
[0005] In order to achieve the above technical objectives, the technical solution adopted by the present invention is:
[0006] The present invention provides a method for realizing remote debugging and repairing of a gateway based on a cloud platform, which is applied to a cloud platform, multiple gateways and a remote client, and specifically comprises the following steps:
[0007] Step 1: Connect the remote client and all gateways to the cloud platform;
[0008] Step 2: Establish an intranet penetration channel between the cloud platform and all gateways through the FRP protocol;
[0009] Step 3: All gateways perform self-checks regularly, and the target gateways that fail through self-checks send corresponding repair requests to the cloud platform;
[0010] Step 4: When the remote client finds that the target gateway fails through the cloud platform, the intranet penetration channel between the cloud platform and the target gateway is opened; the remote client remotely accesses the target gateway through the cloud platform; when the remote access ends, the intranet penetration channel between the cloud platform and the target gateway is closed;
[0011] Step 5: The maintenance personnel analyze the specific cause of the failure of the target gateway based on the access result, and upload the patch package corresponding to the cause of the failure to the cloud platform through the remote client; the target gateway obtains the corresponding patch package from the cloud platform and repairs it.
[0012] Furthermore, the step 1 specifically includes:
[0013] Step 11: Start the cloud platform;
[0014] Step 12: All gateways are connected and registered on the cloud platform, and all gateways report their own device information and current operating status information to the cloud platform;
[0015] Step 13: The maintenance personnel log in to the cloud platform through the remote client and view the device information and current operation status information of all gateways through the cloud platform.
[0016] Furthermore, the step 2 specifically includes:
[0017] Step 21, deploying the FRP server on the cloud platform;
[0018] Step 22: deploying an FRP client on each of the gateways;
[0019] Step 23: A two-way data transmission function is provided between the FRP server and the FRP client to form an intranet penetration channel.
[0020] Furthermore, the step 3 specifically includes:
[0021] Step 31: A fault self-checking mechanism is set in all gateways, and the service modules in each gateway are regularly checked through the fault self-checking mechanism, and the test results are returned;
[0022] Step 32: determine whether there is a faulty target service module according to the detection result. If yes, proceed to step 33; if not, end the process;
[0023] Step 33: Find the corresponding target gateway according to the target business module, and send a repair request to the cloud platform through the target gateway. The repair request includes the specific type of fault, the model of the target gateway and the current version number of the target gateway.
[0024] Furthermore, the step 4 specifically includes:
[0025] Step 41, the cloud platform groups the target gateways according to the specific type of the fault;
[0026] Step 42: The maintenance personnel view the repair request corresponding to each target gateway in the group from the cloud platform through the remote client;
[0027] Step 43: Select an available external network mapping port from the cloud platform;
[0028] Step 44: Send a channel opening instruction to the FRP client of the target gateway through the FRP server, wherein the channel opening instruction includes the server address, the selected external network mapping port, the authentication information and the internal network mapping port;
[0029] Step 45, after receiving the channel opening instruction, the FRP client of the target gateway parses the server address, the selected external network mapping port, the authentication information and the internal network mapping port, and establishes a two-way connection between the internal network mapping port of the FRP client in the target gateway and the external network mapping port of the FRP server in the cloud platform according to the server address, the selected external network mapping port and the internal network mapping port; and after authenticating the FRP server and the FRP client through the authentication information, the corresponding service is opened;
[0030] Step 46: The maintenance personnel connects to the server address and the external network mapping port through the remote client, and then accesses the fault area of the target gateway through the internal mapping port;
[0031] Step 47: After the maintenance personnel finishes the remote access, the FRP server of the cloud platform sends a channel closing instruction to the FRP client of the target gateway. After receiving the channel closing instruction, the FRP client of the target gateway closes the intranet penetration channel.
[0032] Furthermore, the step 43 specifically includes:
[0033] Step 431: a port pool is configured on the cloud platform, wherein the port pool includes a plurality of available external network mapping ports;
[0034] Step 432: when an external network mapping port is needed, an external network mapping port is taken out from the port pool through the cloud platform for allocation;
[0035] Step 433: When the taken-out external network mapping port is not used within a preset time, the taken-out external network mapping port is put back into the port pool;
[0036] Step 434: When the external network mapping port is released after use, the external network mapping port is put back into the port pool;
[0037] Step 435: When the number of gateways connected to the cloud platform exceeds a preset threshold, the cloud platform automatically expands the number of port pools.
[0038] Furthermore, the step 46 specifically includes:
[0039] Step 461: Generate an access link on the cloud platform and send it to the remote client;
[0040] Step 462: After receiving the access link, the remote client identifies and opens a preconfigured remote window through the access link;
[0041] Step 463, the maintenance personnel enters the account and password required to access the gateway in the remote window for authentication. After successful authentication, the remote client connects to the server address of the FRP server on the cloud platform and the external network mapping port. The remote client sends the access request to the internal network mapping port of the target gateway via the external network mapping port of the FRP server. After the internal network mapping port of the target gateway receives the access request, the maintenance personnel is allowed to access the fault area of the target gateway.
[0042] Step 464: The cloud platform is provided with a real-time monitoring function for tracking the activity status of the remote window; when it is monitored that the maintenance personnel have not performed any operation on the remote window within the set time, the cloud platform will close the remote window and release the external network mapping port previously occupied.
[0043] Furthermore, the step 5 specifically includes:
[0044] Step 51: The maintenance personnel analyzes the access result and obtains the specific cause of the failure of the target gateway;
[0045] Step 52: Analyze the cause of the fault, the specific type of the fault, the model of the target gateway and the current version number of the target gateway, and search the patch package library on the cloud platform to see if there is a patch package matching the fault. If so, proceed to step 53; if not, the maintenance personnel generates a corresponding patch package as the target patch package according to the cause of the fault, the specific type of the fault, the model of the target gateway and the current version number of the target gateway, and uploads it to the patch package library on the cloud platform, and proceeds to step 54;
[0046] Step 53: determine whether the number of matched patch packages is one, if so, use the patch package as the target patch package; if not, negotiate with the target gateway through the cloud platform to determine the patch package that best suits the current situation as the target patch package;
[0047] Step 54: The cloud platform sends the download link of the target patch package to the corresponding target gateway;
[0048] Step 55: After the target gateway obtains the download link of the target patch package, it downloads the target patch package according to the download link and performs repair.
[0049] The present invention also provides an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for remotely debugging and repairing a gateway based on a cloud platform as described above is implemented.
[0050] The present invention also provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for realizing remote debugging and repairing of a gateway based on a cloud platform as described above is implemented.
[0051] By adopting the above technical solution, the present invention has the following beneficial effects compared with the prior art:
[0052] 1. The gateway is connected to the cloud platform. On the cloud platform, the external network mapping port of the FRP server is mapped to the internal network mapping port of the FRP client on the gateway. The internal network penetration service can be enabled by remotely controlling the FRP server on the cloud platform. These connection parameters are issued by the cloud platform, eliminating the trouble of manually pre-configuring the internal network penetration in the gateway. The FRP protocol is used here (FRP Fast Reverse Proxy is an efficient internal network penetration tool that can publish services in the internal network (such as TCP, UDP, HTTP, SSH and other protocol services) to the public network to achieve internal network penetration, thereby supporting remote access to the gateway system by the cloud platform), thereby enabling maintenance personnel to access the gateway, so that remote maintenance personnel can access the gateway as flexibly and conveniently as operating the local gateway.
[0053] 2. After the intranet penetration function is implemented, maintenance personnel can troubleshoot and debug the gateway system as they would locally until the problem is solved and repaired. At this time, the gateway system is patched remotely to replace the faulty module in real time and repair the system, that is, only the faulty business module needs to be replaced without affecting the normal operation of other businesses, thus avoiding the impact of business interruption caused by system upgrade and restart of the gateway and minimizing the impact of the failure. BRIEF DESCRIPTION OF THE DRAWINGS
[0054] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative work.
[0055] Figure 1It is an execution flow chart of a method for implementing remote debugging and repair of a gateway based on a cloud platform provided by an embodiment of the present invention.
[0056] Figure 2 It is a framework diagram of the cloud platform, gateway and remote client provided in an embodiment of the present invention.
[0057] Figure 3 It is a schematic diagram of an electronic device provided by an embodiment of the present invention.
[0058] Figure 4 It is a schematic diagram of a computer-readable storage medium provided by an embodiment of the present invention. DETAILED DESCRIPTION
[0059] The present invention will be further described in detail below in conjunction with the accompanying drawings and examples. It is particularly noted that the following examples are only used to illustrate the present invention, but are not intended to limit the scope of the present invention. Similarly, the following examples are only partial embodiments of the present invention rather than all embodiments, and all other embodiments obtained by those of ordinary skill in the art without creative work are within the scope of protection of the present invention.
[0060] See also Figure 1 and Figure 2 The present invention provides a method for realizing remote debugging and repairing of a gateway based on a cloud platform, which is applied to a cloud platform, multiple gateways and a remote client, and specifically includes the following steps:
[0061] Step 1: Connect the remote client and all gateways to the cloud platform;
[0062] In this embodiment, the step 1 specifically includes:
[0063] Step 11: Start the cloud platform to facilitate remote clients and gateways to connect to the cloud platform and realize data interaction;
[0064] Step 12. All gateways are connected to the cloud platform through the 4G / 5G network and registered on the cloud platform. All gateways report their own device information and current operating status information to the cloud platform; the gateway transmits its own information to the cloud platform in real time, so that the cloud platform can monitor all gateways; the gateway will report the current operating status to the cloud platform in the form of event notifications or alarms. These operating conditions include device CPU utilization, storage space utilization, Wi-Fi usage, and the operation of data collection services.
[0065] Step 13: The maintenance personnel log in to the cloud platform through the remote client (the remote client also connects to the cloud platform through the 4G / 5G network) and views the device information and current operation status information of all gateways through the cloud platform. The remote client uses a PC, which can log in to the cloud platform and perform a series of operations on the cloud platform.
[0066] Step 2: Establish an intranet penetration channel between the cloud platform and all gateways through the FRP protocol; the FRP protocol is used to achieve intranet penetration and then remote access to the gateway;
[0067] In this embodiment, step 2 specifically includes:
[0068] Step 21, deploying the FRP server on the cloud platform;
[0069] Step 22: deploying an FRP client on each of the gateways;
[0070] Step 23: A two-way data transmission function is provided between the FRP server and the FRP client to form an intranet penetration channel.
[0071] Step 3: All gateways perform self-checks regularly, and the target gateways that fail through self-checks send corresponding repair requests to the cloud platform;
[0072] In this embodiment, step 3 specifically includes:
[0073] Step 31: A fault self-checking mechanism is set in all gateways, and the service modules in each gateway are regularly checked through the fault self-checking mechanism, and the test results are returned;
[0074] 1) Define fault detection points: It is necessary to clarify which business modules inside the gateway require regular self-checks, and how to use specific detection indicators (such as response time, error rate, resource consumption, etc.) to determine whether these business modules are operating normally.
[0075] 2) Write self-check scripts: Write corresponding test scripts for each business module that needs self-checking. These scripts should be able to be executed regularly and return the test results.
[0076] Step 32: Determine whether there is a target service module with a fault according to the test results. If yes, proceed to step 33; if not, end the process. The self-test system should be able to automatically analyze the test results and determine which service modules have faults.
[0077] Step 33: find the corresponding target gateway according to the target business module, and send a repair request to the cloud platform through the target gateway. The repair request includes the specific type of fault, the model of the target gateway and the current version number of the target gateway, so that the cloud platform can accurately judge and provide a suitable patch package.
[0078] Step 4: When the remote client finds that the target gateway fails through the cloud platform, the intranet penetration channel between the cloud platform and the target gateway is opened; the remote client remotely accesses the target gateway through the cloud platform; when the remote access ends, the intranet penetration channel between the cloud platform and the target gateway is closed;
[0079] In this embodiment, step 4 specifically includes:
[0080] Step 41, the cloud platform groups the target gateways according to the specific type of the fault; the purpose of grouping the faulty gateways is to trigger batch processing of the entire group of gateways;
[0081] Step 42: The maintenance personnel view the repair request corresponding to each target gateway in the group from the cloud platform through the remote client;
[0082] Step 43, select the available external network mapping port from the cloud platform; there is a time-consuming problem in manual configuration and manual inspection of the external network mapping port, especially when the number of gateways connected to the cloud platform is large, it is more likely to cause errors, which brings great inconvenience to maintenance personnel. In order to improve efficiency and automation level, some cloud platform automatic port allocation strategies that can be improved are used.
[0083] In this embodiment, step 43 specifically includes:
[0084] Step 431: a port pool is configured on the cloud platform, wherein the port pool contains a plurality of available external network mapping ports; the design of the port pool facilitates automatic selection of available external network mapping ports, thereby improving port allocation efficiency;
[0085] Step 432: When an external network mapping port is needed, the cloud platform takes out an external network mapping port from the port pool for allocation; when there is a new port mapping requirement, the cloud platform can quickly select an unoccupied port from the port pool for allocation. This strategy ensures the speed and accuracy of port allocation and avoids the tedious process of manually finding and configuring ports.
[0086] Step 433: When the external network mapping port taken out is not used within the preset time, the external network mapping port taken out is put back into the port pool; in order to avoid waste and conflict of port resources, a port usage timeout aging mechanism is designed, which helps to optimize the utilization of port resources and reduce service problems caused by port conflicts.
[0087] Step 434: When the external network mapping port is released after use, the external network mapping port is put back into the port pool, thereby saving port resources.
[0088] Step 435: When the number of gateways connected to the cloud platform exceeds the preset threshold, the cloud platform automatically expands the number of port pools. This is done to accommodate more port requirements. This strategy ensures that port resources can be replenished in a timely manner in high-concurrency scenarios to avoid service interruptions caused by insufficient ports.
[0089] Step 44, the FRP server sends a channel opening instruction to the FRP client of the target gateway, the channel opening instruction carries the configuration information of the FRP client, including the server address (referring to the address of the FRP server), the selected external network mapping port, authentication information and the internal network mapping port; the server address and the selected external network mapping port are used to inform the FRP client which cloud FRP server to connect to, the authentication information is used to provide access control, the internal network mapping port is the port used to map with the external network mapping port, and there is a mapping relationship between the external network mapping port and the internal network mapping port. These are to provide the required parameter configuration information to the FRP client, and after parsing these parameters, the gateway writes this information into the configuration file specified by the FRP client, and finally opens the FRP client.
[0090] Step 45, after receiving the channel opening instruction, the FRP client of the target gateway parses the server address, the selected external network mapping port, the authentication information and the internal network mapping port, and establishes a two-way connection between the internal network mapping port of the FRP client in the target gateway and the external network mapping port of the FRP server in the cloud platform according to the server address, the selected external network mapping port and the internal network mapping port; and after authenticating the FRP server and the FRP client through the authentication information, the corresponding service is opened; the FRP client parses the configuration file specified by the client, identifies the internal network mapping port that the local gateway needs to connect to, and then connects to the corresponding port, for example: the internal network mapping port of the FRP client can be set to 22, the external network mapping port of the FRP server can be set to 40022, and the corresponding service opened is the ssh service; at this point, the intranet penetration channel is opened, and two-way data transmission can be achieved between the cloud platform and the gateway;
[0091] Step 46, the maintenance personnel connects to the server address and the external network mapping port (for example, the external network mapping port 40022 of the ssh service) through the remote client, and then accesses the fault area of the target gateway through the internal mapping port (for example, the internal network mapping port 22 of the ssh service);
[0092] In this embodiment, step 46 specifically includes:
[0093] Step 461: Generate an access link on the cloud platform and send it to the remote client; the user only needs to click on the access link to immediately start a pre-configured remote window and connect directly to the gateway, which greatly simplifies the remote access process. One-click remote access is achieved, and the user does not need to manually configure complex network settings or remember cumbersome link addresses and port numbers.
[0094] Step 462: After receiving the access link, the remote client identifies and opens a pre-configured remote window (e.g., an ssh client access window) through the access link. This window not only provides the user with an intuitive and easy-to-use operation interface, but also automatically handles all necessary account password authentication and encryption processes to ensure the security and privacy of data transmission. The user can start remote access without any additional configuration or operation;
[0095] Step 463, the maintenance personnel enters the account and password required to access the gateway in the remote window for authentication. After successful authentication, the remote client connects to the server address of the FRP server on the cloud platform and the external network mapping port. The remote client sends the access request to the internal network mapping port of the target gateway via the external network mapping port of the FRP server. After the internal network mapping port of the target gateway receives the access request, the maintenance personnel is allowed to access the fault area of the target gateway.
[0096] Step 464: The cloud platform is provided with a real-time monitoring function for tracking the activity status of the remote window, including the user's operation frequency, duration, etc.; when it is monitored that the maintenance personnel have not performed any operation on the remote window within the set time (such as no interaction within the set timeout threshold), the cloud platform will close the remote window and release the external network mapping port previously occupied. This mechanism effectively avoids the idleness and waste of port resources, ensures the efficient use of resources and improves the user experience.
[0097] Step 47: After the maintenance personnel finish the remote access, the FRP server of the cloud platform sends a channel closing instruction to the FRP client of the target gateway, and the FRP client of the target gateway closes the intranet penetration channel after receiving the channel closing instruction, so as to avoid occupying system resources and network resources.
[0098] Step 5: The maintenance personnel analyze the specific cause of the failure of the target gateway based on the access result, and upload the patch package corresponding to the cause of the failure to the cloud platform through the remote client; the target gateway obtains the corresponding patch package from the cloud platform and repairs it.
[0099] In this embodiment, step 5 specifically includes:
[0100] Step 51: The maintenance personnel analyzes the access result and obtains the specific cause of the failure of the target gateway;
[0101] Step 52: Analyze according to the fault cause, the specific type of fault, the model of the target gateway and the current version number of the target gateway, and search from the patch package library on the cloud platform whether there is a patch package matching the fault. If so, proceed to step 53; if not, the maintenance personnel generates a corresponding patch package as the target patch package according to the fault cause, the specific type of fault, the model of the target gateway and the current version number of the target gateway and uploads it to the patch package library on the cloud platform, and proceed to step 54; the patch package includes a running script, an executable file (i.e., an application of a certain business module), a dynamic link library file and a configuration file;
[0102] Step 53: determine whether the number of matching patch packages is one. If so, use the patch package as the target patch package. If not, negotiate with the target gateway through the cloud platform to determine the patch package that best suits the current situation as the target patch package. This process may involve some policy judgments, such as the compatibility, size, and download time of the patch package.
[0103] Step 54: The cloud platform sends the download link of the target patch package to the corresponding target gateway;
[0104] Step 55: After the target gateway obtains the download link of the target patch package, it downloads the target patch package according to the download link and performs repair;
[0105] Automatic download: Automatically download the patch package to local storage;
[0106] Patch package installation: After downloading is complete, the gateway should be able to automatically install the patch package and update the software version of the faulty module.
[0107] Repair process: The target gateway parses the target patch package to obtain the running script, executable file (i.e., the application of a certain business module), dynamic link library file, and configuration file; it executes according to the running script, and the script automatically performs a series of operations: replaces the contents of the patch package one by one, re-pulls the new business module, and finally replaces the faulty business module, thereby realizing the repair of the system. The whole process does not require upgrading the entire firmware, and will not interfere with other normal businesses, thus ensuring the uninterrupted business and bringing a good experience to users.
[0108] Installation verification: After the installation is complete, the gateway should run the self-test script again to verify whether the fault has been fixed.
[0109] like Figure 3As shown, an embodiment of the present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein when the processor executes the program, the method for remote debugging and repairing a gateway based on a cloud platform is implemented.
[0110] like Figure 4 As shown, an embodiment of the present invention further provides a computer-readable storage medium on which a computer program is stored. When the program is executed by a processor, the method for realizing remote debugging and repairing of a gateway based on a cloud platform is implemented.
[0111] In addition, each functional unit in each embodiment of the present invention may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.
[0112] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for a computer device (which can be a personal computer, server, or network device, etc.) or a processor (processor) to perform all or part of the steps of each embodiment of the present invention. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), disk or optical disk and other media that can store program codes.
[0113] The above descriptions are only some embodiments of the present invention, and are not intended to limit the protection scope of the present invention. Any equivalent device or equivalent process transformation made using the contents of the present invention specification and drawings, or directly or indirectly applied in other related technical fields, are also included in the patent protection scope of the present invention.
Claims
1. A method for implementing remote debugging and repair of a gateway based on a cloud platform, characterized in that: Applied to cloud platforms, multiple gateways, and remote clients, the specific steps include: Step 1: Connect the remote client and all gateways to the cloud platform; Step 2: Establish an intranet penetration channel between the cloud platform and all gateways through the FRP protocol; Step 3: All gateways perform self-checks regularly, and the target gateways that fail through self-checks send corresponding repair requests to the cloud platform; Step 4: When the remote client finds that the target gateway fails through the cloud platform, the intranet penetration channel between the cloud platform and the target gateway is opened; the remote client remotely accesses the target gateway through the cloud platform; when the remote access ends, the intranet penetration channel between the cloud platform and the target gateway is closed; Step 5: The maintenance personnel analyze the specific cause of the failure of the target gateway based on the access result, and upload the patch package corresponding to the cause of the failure to the cloud platform through the remote client; the target gateway obtains the corresponding patch package from the cloud platform and repairs it.
2. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 1, characterized in that: The step 1 specifically includes: Step 11: Start the cloud platform; Step 12: All gateways are connected and registered on the cloud platform, and all gateways report their own device information and current operating status information to the cloud platform; Step 13: The maintenance personnel log in to the cloud platform through the remote client and view the device information and current operation status information of all gateways through the cloud platform.
3. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 2, characterized in that: The step 2 specifically includes: Step 21, deploying the FRP server on the cloud platform; Step 22: deploying an FRP client on each of the gateways; Step 23: A two-way data transmission function is provided between the FRP server and the FRP client to form an intranet penetration channel.
4. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 3, characterized in that: The step 3 specifically includes: Step 31: A fault self-checking mechanism is set in all gateways, and the service modules in each gateway are regularly checked through the fault self-checking mechanism, and the test results are returned; Step 32: determine whether there is a faulty target service module according to the detection result. If yes, proceed to step 33; if not, end the process; Step 33: Find the corresponding target gateway according to the target business module, and send a repair request to the cloud platform through the target gateway. The repair request includes the specific type of fault, the model of the target gateway and the current version number of the target gateway.
5. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 4, characterized in that: The step 4 specifically includes: Step 41, the cloud platform groups the target gateways according to the specific type of the fault; Step 42: The maintenance personnel view the repair request corresponding to each target gateway in the group from the cloud platform through the remote client; Step 43: Select an available external network mapping port from the cloud platform; Step 44: Send a channel opening instruction to the FRP client of the target gateway through the FRP server, wherein the channel opening instruction includes the server address, the selected external network mapping port, the authentication information and the internal network mapping port; Step 45, after receiving the channel opening instruction, the FRP client of the target gateway parses the server address, the selected external network mapping port, the authentication information and the internal network mapping port, and establishes a two-way connection between the internal network mapping port of the FRP client in the target gateway and the external network mapping port of the FRP server in the cloud platform according to the server address, the selected external network mapping port and the internal network mapping port; and after authenticating the FRP server and the FRP client through the authentication information, the corresponding service is opened; Step 46: The maintenance personnel connects to the server address and the external network mapping port through the remote client, and then accesses the fault area of the target gateway through the internal mapping port; Step 47: After the maintenance personnel finishes the remote access, the FRP server of the cloud platform sends a channel closing instruction to the FRP client of the target gateway. After receiving the channel closing instruction, the FRP client of the target gateway closes the intranet penetration channel.
6. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 5, characterized in that: The step 43 specifically includes: Step 431: a port pool is configured on the cloud platform, wherein the port pool includes a plurality of available external network mapping ports; Step 432: when an external network mapping port is needed, an external network mapping port is taken out from the port pool through the cloud platform for allocation; Step 433: When the taken-out external network mapping port is not used within a preset time, the taken-out external network mapping port is put back into the port pool; Step 434: When the external network mapping port is released after use, the external network mapping port is put back into the port pool; Step 435: When the number of gateways connected to the cloud platform exceeds a preset threshold, the cloud platform automatically expands the number of port pools.
7. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 5, characterized in that: The step 46 specifically includes: Step 461: Generate an access link on the cloud platform and send it to the remote client; Step 462: After receiving the access link, the remote client identifies and opens a preconfigured remote window through the access link; Step 463, the maintenance personnel enters the account and password required to access the gateway in the remote window for authentication. After successful authentication, the remote client connects to the server address of the FRP server on the cloud platform and the external network mapping port. The remote client sends the access request to the internal network mapping port of the target gateway via the external network mapping port of the FRP server. After the internal network mapping port of the target gateway receives the access request, the maintenance personnel is allowed to access the fault area of the target gateway. Step 464: The cloud platform is provided with a real-time monitoring function for tracking the activity status of the remote window; when it is monitored that the maintenance personnel have not performed any operation on the remote window within the set time, the cloud platform will close the remote window and release the external network mapping port previously occupied.
8. The method for implementing remote debugging and repairing of a gateway based on a cloud platform as claimed in claim 5, characterized in that: The step 5 specifically includes: Step 51: The maintenance personnel analyzes the access result and obtains the specific cause of the failure of the target gateway; Step 52: Analyze the cause of the fault, the specific type of the fault, the model of the target gateway and the current version number of the target gateway, and search the patch package library on the cloud platform to see if there is a patch package matching the fault. If so, proceed to step 53; if not, the maintenance personnel generates a corresponding patch package as the target patch package according to the cause of the fault, the specific type of the fault, the model of the target gateway and the current version number of the target gateway, and uploads it to the patch package library on the cloud platform, and proceeds to step 54; Step 53: determine whether the number of matched patch packages is one, if so, use the patch package as the target patch package; if not, negotiate with the target gateway through the cloud platform to determine the patch package that best suits the current situation as the target patch package; Step 54: The cloud platform sends the download link of the target patch package to the corresponding target gateway; Step 55: After the target gateway obtains the download link of the target patch package, it downloads the target patch package according to the download link and performs repair.
9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that: When the processor executes the program, the method for realizing remote debugging and repair of a gateway based on a cloud platform as described in any one of claims 1 to 8 is implemented.
10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method for realizing remote debugging and repairing of a gateway based on a cloud platform as described in any one of claims 1 to 8 is implemented.