Remote calling method and service calling method of network equipment, equipment and storage medium

Abstract

The invention relates to a remote calling method of network equipment, a service calling method, equipment and a storage medium. Comprising the following steps: acquiring identification information of target network equipment, and sending a connection request to the target network equipment according to the identification information; in response to a connection success message from the target network equipment, sending an interface deployment request to the target network equipment to control the target network equipment to register a plurality of remote call services; in response to a deployment success message from the target network equipment, a remote call request is sent to the target network equipment, and the remote call request comprises the target service identifier; and receiving an execution result for the remote call request from the target network equipment. Therefore, the management and control platform can dynamically and flexibly deploy, maintain and configure the interface after the connection is established according to the specific function requirements of the network equipment, and supports the version upgrade and backspacing of the interface, thereby breaking through the limitation of a traditional preset static function model.

Description

Technical Field

[0001] This disclosure relates to the field of equipment scheduling, and in particular to remote invocation methods, service invocation methods, equipment, and storage media for network devices. Background Technology

[0002] In related technologies, centralized management of network devices can be achieved by deploying a configuration distribution module on the management end and a configuration receiving module on the network device end, communicating based on the IP protocol. This enables batch initialization configuration of network devices in a one-to-many manner, effectively improving the configuration efficiency during the initial deployment phase. However, the configuration logic in these technologies is usually pre-developed and embedded in the module, primarily suitable for device initialization scenarios with relatively fixed functions and uniform configuration modes. It is difficult to support flexible and dynamic adjustments or additions of new configuration interfaces to network devices after they are operational, based on business needs. This fails to meet the management requirements of continuous iteration and customization of functions for programmable network devices and other similar devices. Summary of the Invention

[0003] In view of this, embodiments of the present disclosure provide a remote invocation method for network devices, a service invocation method, a device, and a storage medium to solve the problems existing in the related technologies.

[0004] A first aspect of this disclosure provides a remote invocation method for a network device. The method includes: obtaining identification information of a target network device and sending a connection request to the target network device based on the identification information; in response to a connection success message from the target network device, sending an interface deployment request to the target network device to control the target network device to register multiple remote invocation services; in response to a deployment success message from the target network device, sending a remote invocation request to the target network device, wherein the remote invocation request includes a target service identifier; and receiving an execution result from the target network device in response to the remote invocation request.

[0005] A second aspect of this disclosure provides a service invocation method, the method comprising: in response to a connection request from a management platform, establishing a connection with the management platform and sending a connection success message to the management platform; in response to an interface deployment request from the management platform, registering multiple remote invocation services according to the interface deployment request and sending a deployment success message to the management platform; in response to a remote invocation request from the management platform, invoking a target remote invocation service to execute the remote invocation request according to a target service identifier included in the remote invocation request, wherein the target service identifier is an identifier of the target remote invocation service; and sending an execution result to the management platform.

[0006] A third aspect of this disclosure provides a remote invocation apparatus for a network device, applied to the remote invocation method for a network device as described in the first aspect. The apparatus includes: an acquisition module, configured to acquire identification information of a target network device and send a connection request to the target network device based on the identification information; a first sending module, configured to send an interface deployment request to the target network device in response to a connection success message from the target network device, thereby controlling the target network device to register multiple remote invocation services; a second sending module, configured to send a remote invocation request to the target network device in response to a deployment success message from the target network device, wherein the remote invocation request includes a target service identifier; and a receiving module, configured to receive an execution result from the target network device in response to the remote invocation request.

[0007] A fourth aspect of this disclosure provides a service invocation apparatus applied to the service invocation method of the second aspect. The apparatus includes: a connection module, configured to establish a connection with a management platform in response to a connection request from the management platform and send a connection success message to the management platform; a registration module, configured to register multiple remote invocation services according to an interface deployment request from the management platform and send a deployment success message to the management platform in response to an interface deployment request from the management platform; an invocation module, configured to invoke a target remote invocation service to execute the remote invocation request according to a target service identifier included in the remote invocation request, wherein the target service identifier is the identifier of the target remote invocation service; and a third sending module, configured to send the execution result to the management platform.

[0008] A fifth aspect of this disclosure provides a computer device including a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the remote invocation method of the network device described above.

[0009] A sixth aspect of this disclosure provides a computer-readable storage medium having a computer program / operation instructions stored thereon, which, when executed by a processor, implement the steps of the remote invocation method for the network device described above.

[0010] A seventh aspect of this disclosure provides a computer program product that, when executed by a processor, implements the steps of the remote invocation method for the network device described above.

[0011] The at least one technical solution adopted in this disclosure can achieve the following beneficial effects: by obtaining the identification information of the target network device, a connection request is sent to the target network device according to the identification information; in response to the connection success message from the target network device, an interface deployment request is sent to the target network device to control the target network device to register multiple remote call services; in response to the deployment success message from the target network device, a remote call request is sent to the target network device, wherein the remote call request includes the target service identifier; and the execution result from the target network device in response to the remote call request is received. In this way, the management and control platform can dynamically and flexibly deploy and maintain configuration interfaces after the connection is established according to the specific functional requirements of the network devices, supporting interface version upgrades and rollbacks. This breaks through the limitations of traditional pre-set static functional models, realizing the proactive and customized distribution and real-time invocation of configuration interfaces for different functional devices. Thus, while maintaining lightweight communication, it significantly improves the flexibility and efficiency of batch configuration and real-time operation and maintenance management of large-scale, diverse network device clusters. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 A schematic diagram illustrating a remote invocation process for a network device provided in one embodiment of this disclosure; Figure 2 A flowchart illustrating a service invocation method provided in one embodiment of this disclosure; Figure 3 A schematic diagram of the structure of a remote invocation device for a network device provided in an embodiment of this disclosure; Figure 4 This is a schematic diagram of the structure of a service invocation device provided in an embodiment of the present disclosure; Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure; Figure 6 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present disclosure; Figure 7 A schematic diagram of a computer program product provided according to an embodiment of this disclosure. Detailed Implementation

[0014] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0015] It should be understood that the steps described in the method embodiments of this disclosure may be performed in different orders and / or in parallel. Furthermore, the method embodiments may include additional steps and / or omit the steps shown. The scope of this disclosure is not limited in this respect.

[0016] The term "comprising" and its variations as used herein are open-ended, meaning "including but not limited to". The term "based on" means "at least partially based on". The term "one embodiment" means "at least one embodiment"; the term "another embodiment" means "at least one additional embodiment"; the term "some embodiments" means "at least some embodiments". Definitions of other terms will be given in the description below. It should be noted that the concepts of "first", "second", etc., used in this disclosure are only used to distinguish different devices, modules, or units, and are not intended to limit the order of functions performed by these devices, modules, or units or their interdependencies.

[0017] It should be noted that the terms "a" and "a plurality of" used in this disclosure are illustrative rather than restrictive, and those skilled in the art should understand that, unless otherwise expressly indicated in the context, they should be understood as "one or more".

[0018] The names of messages or information exchanged between multiple devices in the embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of such messages or information.

[0019] Currently, Remote Procedure Call (RPC) is the mainstream solution for communication and control between distributed systems and network devices. Common RPC implementations, such as gRPC and Thrift, rely on pre-defining service interfaces and data types using an interface definition language, and then using code generation tools to generate multilingual client and server code, thereby achieving cross-language interoperability. These solutions emphasize universality and standardization, but in scenarios requiring high flexibility and dynamic deployment, the reliance on pre-compiled and static interface definitions can introduce certain complexities. Here, gRPC is a high-performance, cross-language remote procedure call framework developed and open-sourced by a relevant company; Thrift is a cross-language remote service call framework developed and open-sourced by a relevant company, integrating its own interface definition language and communication protocol stack.

[0020] Another type is the service governance RPC framework represented by Dubbo, which focuses on high-performance service invocation, discovery, and governance. It is particularly suitable for the decomposition and management of large-scale microservice architectures. However, it is usually deeply coupled with specific programming languages, presenting a hurdle for cross-language support, and the overall framework is relatively heavyweight. It may not be suitable for resource-constrained or functionally variable edge devices, such as programmable network devices. Here, Dubbo is a high-performance, lightweight Java RPC framework open-sourced by a relevant company. Its core focus is on distributed service governance, concentrating on providing interface-oriented remote method invocation, intelligent fault tolerance and load balancing, and automated service registration and discovery capabilities.

[0021] Existing technologies for centralized management of network devices can achieve one-to-many batch initialization configuration of network devices by deploying a configuration distribution module on the management end and a configuration receiving module on the network device end, and communicating based on the IP protocol. This effectively improves the configuration efficiency during the initial deployment phase of network devices. However, the configuration logic of this method is usually pre-developed and embedded in the module, which is mainly suitable for device initialization scenarios with relatively fixed functions and uniform configuration modes. It is difficult to support network devices to flexibly and dynamically adjust or add new configuration interfaces according to business needs after they are running, and it cannot meet the management needs of continuous iteration and customization of device functions such as programmable network devices.

[0022] Furthermore, in terms of improving the efficiency of interface development and deployment, related technologies can accelerate the development and deployment process of business interfaces by decoupling interface protocols, parameters, and other information, and providing a visual configuration, testing, and deployment platform. However, the focus is on building the capabilities of the low-code platform itself. Specific implementation methods are not provided for how the low-code platform can interact efficiently, flexibly, and programmably with the network devices that ultimately carry the business logic, especially how to achieve remote dynamic deployment and real-time invocation of interface logic.

[0023] It is evident that existing technical solutions have the following limitations: Firstly, at the remote procedure call (RPC) technology level, existing mainstream RPC frameworks struggle to meet the dynamic management needs of network devices like programmable network devices. While service governance-based RPC frameworks offer rich functionality, they are highly coupled to specific programming languages ​​and have a heavyweight architecture, placing a significant burden on resource-constrained network devices. Cross-language RPC frameworks, on the other hand, rely on predefined interface description files and code generation steps, resulting in static, pre-compiled service interfaces. This necessitates a complete re-generation, compilation, and deployment process whenever an interface needs modification or addition, hindering the dynamic deployment and updating of configuration interfaces during device runtime and lacking necessary flexibility.

[0024] Secondly, at the centralized configuration management level of network devices, existing architectures typically pre-define configuration logic within the client and server programs. While this approach enables batch initialization configuration of network devices, the functionality is fixed after deployment, essentially a "static deployment" model. It cannot support dynamically deploying new configuration interfaces or modifying existing interface logic to network devices based on constantly changing business needs during operation. Therefore, this type of solution is ill-suited to the management requirements of programmable network devices, which offer rich functional combinations, require frequent iterations, and are highly customizable.

[0025] Furthermore, in terms of improving the efficiency of interface development and deployment, existing low-code platform solutions focus on simplifying the development, testing, and release processes of the interfaces themselves, but the technical path usually ends at the platform level. It is evident that this solution fails to address a key issue: how to dynamically deploy the interface logic defined or generated in the platform to the target device in an efficient, flexible, and programmable manner and enable remote calls. This results in a lack of interaction mechanisms between the platform and network devices, preventing the "rapidly developed" interfaces from being "flexibly deployed."

[0026] To address the aforementioned issues, this application provides a method for remotely invoking network devices. The method involves obtaining the identification information of the target network device and sending a connection request to it based on that information. In response to a connection success message from the target network device, an interface deployment request is sent to the target network device to control the registration of multiple remote invoking services. In response to a deployment success message from the target network device, a remote invoking request is sent to the target network device, where the remote invoking request includes a target service identifier. Finally, the method receives the execution result from the target network device in response to the remote invoking request. This allows the management platform to dynamically and flexibly deploy and maintain configuration interfaces after the connection is established, based on the specific functional requirements of the network devices. It supports interface version upgrades and rollbacks, thus overcoming the limitations of traditional pre-built static functional models. This enables proactive, customized distribution and real-time invoking of configuration interfaces for different functional devices, significantly improving the flexibility and efficiency of batch configuration and real-time operation and maintenance management of large-scale, diverse network device clusters while maintaining lightweight communication.

[0027] The remote invocation method for network devices provided in this disclosure can be executed by a terminal or by a chip applied to the terminal.

[0028] For example, the aforementioned terminals may include one or more of the following: mobile phones, tablets, wearable devices, in-vehicle devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, handheld computers (PDAs), and wearable devices based on augmented reality (AR) and / or virtual reality (VR) technologies. They may also include, but are not limited to, remote control devices, wearable devices, streetlights, home appliances, and other smart terminals. This disclosure does not impose specific limitations on these aspects.

[0029] Figure 1 This is a schematic diagram illustrating a remote invocation process for a network device according to an embodiment of this disclosure. Figure 1 As shown, the remote invocation method for network devices is applied to a management and control platform. The management and control platform is a software system used for centralized monitoring, configuration, management, and control of distributed network devices or systems. The remote invocation method for network devices includes: S101: Obtain the identification information of the target network device and send a connection request to the target network device based on the identification information. Here, the target network device specifically refers to an intelligent network device capable of running custom software and supporting remote dynamic programming configuration, which may include switches, intelligent gateways, and routers, etc.

[0030] In some embodiments, the management platform can obtain the identification information of the target device from a pre-set network device information database based on user selection or task instructions. The identification information includes at least the management IP address of the target device. Subsequently, the connection management module of the management platform constructs a WebSocket connection to the target device based on the management IP address and a preset port number, and actively initiates a WebSocket connection request to the target device to establish a bidirectional communication link. Here, the IP address is a logical address in the Internet Protocol (IP) used to uniquely identify a network device in a network; WebSocket is a network communication protocol that provides full-duplex, bidirectional communication capabilities over a single Transmission Control Protocol (TCP) connection.

[0031] In this way, by pre-building a network device information database and using the precise logical identifier of the target device's management IP address, the management platform achieves accurate addressing and proactive connection to specific network devices. Simultaneously, the full-duplex, bidirectional real-time communication link established by the WebSocket protocol not only ensures high reliability and low latency of the connection channel but also provides a stable and efficient transmission foundation for the dynamic deployment and invocation of subsequent remote configuration interfaces. This improves the automation and operational accuracy of device management in large-scale network environments, enabling the management platform to flexibly and reliably interface with heterogeneous programmable devices, providing core communication guarantees for centralized operation and maintenance and dynamic policy distribution in intelligent networks.

[0032] S102, in response to a connection success message from the target network device, an interface deployment request is sent to the target network device to control the target network device to register multiple remote call services. The interface deployment request carries multiple logic files, each defining at least one interface, and one logic file corresponds to one remote call service. Here, each logic file acts as an independent functional unit, and one or more interfaces defined within it are uniformly integrated into the single remote call service corresponding to that logic file, avoiding service instance redundancy and achieving modular management of interfaces.

[0033] In some embodiments, after the management platform successfully establishes a WebSocket connection with the target network device, the interface deployment module of the management platform can select or dynamically generate a corresponding configuration interface definition file from the local interface code repository according to the current business strategy or configuration task requirements. This configuration interface definition file contains one or more logical files written in Python to implement specific network functions. Subsequently, the interface deployment module sends a structured interface deployment request to the target network device through the established WebSocket connection. This request encapsulates the identifiers of multiple logical files and their associated interfaces to drive the target network device to register the corresponding remote call service locally. Here, the logical files use lightweight script formats such as Python bytecode (.pyc), which can effectively compress the file size compared to the original source code files, thereby significantly reducing the amount of data transmitted.

[0034] In this way, by deploying the interface immediately after the connection is established, and dynamically selecting or generating multiple logical files based on business needs, on-demand distribution and real-time injection of network configuration logic are achieved. This enables the management and control platform to remotely deploy business functions immediately after the target network device comes online, significantly shortening the preparation time from target network device access to having business capabilities, while ensuring a high degree of matching between the configuration content and the real-time business scenario. Furthermore, due to the use of structured transmission of multiple logical files and a clear interface identification mechanism, this process has strong traceability, easy maintainability, and a good foundation for version management, providing solid support for flexible invocation and continuous integration of subsequent remote services, and significantly improving the response speed and automation level of network operations and maintenance.

[0035] S103, in response to the deployment success message from the target network device, a remote call request is sent to the target network device, wherein the remote call request includes the target service identifier.

[0036] In some embodiments, after the management platform receives a successful deployment confirmation message from the target network device for the interface, the remote invocation module in the management platform can construct and send a remote invocation request to the target network device according to predefined or dynamically generated business logic. The remote invocation request can be encapsulated in JSON format, explicitly containing a target service identifier. This target service identifier corresponds to a remote invocation service pre-deployed on the target network device, indicating the specific remote service to be executed by the target network device. Here, JSON format is a lightweight, text-based, language-independent data exchange format, short for JavaScript Object Notation. JSON uses a completely language-independent text format to store and represent data, making it easy for humans to read and write, and also easy for machines to parse and generate.

[0037] This ensures that remote call services can be put into use immediately after they become available, greatly shortening the business launch cycle. Furthermore, by using a service location identification method, the complexity of the underlying code implementation is shielded, enabling the management platform to perform network operations in a declarative, intent-driven manner. This enhances the real-time response, accuracy of calls, and consistency of operation and maintenance of the management platform, providing key technical support for the automated service orchestration and rapid iteration of programmable networks.

[0038] S104, Receive the execution result from the target network device in response to the remote call request.

[0039] This enables the management platform to dynamically and flexibly deploy and maintain configuration interfaces after the connection is established, based on the specific functional requirements of network devices. It also supports interface version upgrades and rollbacks, thus breaking through the limitations of traditional pre-built static functional models. This allows for proactive and customized distribution and real-time invocation of configuration interfaces for different functional devices, thereby significantly improving the flexibility and efficiency of batch configuration and real-time operation and maintenance management of large-scale and diverse network device clusters while maintaining lightweight communication.

[0040] In some embodiments, the remote call request includes a target service identifier, and the method further includes receiving an execution result from a target network device for the remote call request: obtaining a service identifier included in the execution result; and associating the remote call request and the execution result if the service identifier matches the target service identifier in the remote call request.

[0041] Specifically, the management platform can explicitly include a target service identifier in the remote call request sent to the target network device, and receive the execution result returned by the target network device after execution. This execution result also contains the corresponding service identifier. The management platform's call processing module compares the service identifier in the returned result with the target service identifier in the original request to achieve accurate matching and association between the asynchronous call request and the returned result. Furthermore, during the interface deployment phase, the management platform can send a deployment package containing multiple logical files to the target network device at once. Each logical file independently defines at least one remotely callable interface, thereby achieving batch and atomic deployment of multiple interfaces.

[0042] For example, suppose the management platform initiates a remote call request to the target network device, and this request includes the target service identifier `set_port_rate`. After the target network device completes the execution, the returned execution result also includes the service identifier `set_port_rate`. Based on this, after receiving the execution result, the management platform's call processing module extracts the service identifier from the execution result and compares it with the original request information recorded locally. When it is confirmed that the service identifiers are the same (both are `set_port_rate`), it is determined that this result successfully matches the previously initiated call request.

[0043] In this way, by introducing a bidirectional transmission and matching mechanism for service identifiers, the association between requests and responses is accurately realized in asynchronous communication scenarios. This effectively avoids result corruption in multi-network device and high-concurrency call environments, ensuring the reliability and determinism of the management platform's calls. Simultaneously, by supporting batch interface deployment with multiple logic files, the efficiency of interface distribution and the atomicity of deployment operations are significantly improved. This not only meets the needs of multi-functional interface combination deployment in complex business scenarios but also reduces the network and management overhead caused by frequent communication. This combined design optimizes both call reliability and deployment efficiency, providing a highly available and high-performance foundation for the centralized and automated operation and maintenance of large-scale programmable network devices.

[0044] In some embodiments, when the management platform initiates a remote call request to the target network device, it can also synchronously register a unique callback function for the remote call request on the local client, and associate the callback function with the target service identifier of the remote call request for subsequent asynchronous reception and processing of the execution result from the network device. Here, the role of the callback function in this embodiment is to process the execution result of the asynchronous remote call. That is, when the management platform initiates a remote call request, since network communication and execution are asynchronous, the program will not block and wait for the result; at this time, the management platform will immediately register a callback function for the call and bind the callback function with the unique target service identifier of this remote call request. In this way, when the target completes execution and pushes the result back via WebSocket, the management platform finds the corresponding callback function according to the call identifier in the result and executes it, thereby completing the processing of the returned data.

[0045] Meanwhile, during the interface deployment phase, the target network device stores the registered interface logic file definitions in a local interface registration dictionary. This dictionary uses the service identifier as the key, and the corresponding values ​​record the location and parameters of the interface logic file, providing support for subsequent reflection calls. Based on this, when the management platform initiates a remote call, the constructed JSON-formatted remote call request includes structured path information. This path information integrates the service identifier (used to locate the target interface) and a unique call identifier (used to identify this specific call instance). Therefore, upon receiving the remote call request, the target network device first parses the service identifier from the path information and uses it to find the corresponding interface logic file and metadata in the interface registration dictionary. Then, it uses Python's reflection mechanism to locate and execute the corresponding interface function. After execution, the target network device actively pushes the execution result (including the remote call return value, the call identifier, and a return status identifier) ​​back to the management platform in JSON format.

[0046] Correspondingly, when initiating a remote call request, the management platform maintains a callback registration dictionary locally. This remote call request uses the complete path used in the call as the key, and its corresponding value records the callback function information pre-registered for processing the call result. Based on this, when the management platform receives the execution result pushed by the target network device, it locates the unique callback function in the local callback registration dictionary by parsing the call identifier in the result and executes it, thus completing the closed-loop processing of this asynchronous call. This ensures accurate matching of requests and responses in high-concurrency scenarios.

[0047] For example, suppose the management platform initiates a remote call request to the target network device. This request includes the call identifier `call_20240625001` and the service identifier `set_port_rate`. After the target network device completes the execution, the returned execution result also includes the service identifier `set_port_rate` and the call identifier `call_20240625001`. Based on this, the call processing module of the management platform receives the execution result, extracts the service identifier and call identifier from the result, and compares them with the original remote call request recorded locally. When it is confirmed that the service identifier is the same (both are `set_port_rate`) and the call identifier is the same (both are `call_20240625001`), it is determined that this result matches the previously initiated call request successfully. Subsequently, the execution result data is routed to the callback function pre-registered for `call_20240625001` for processing, thus completing a complete asynchronous call loop.

[0048] This allows the management platform to continue processing other tasks or initiating new calls while waiting for responses from one or more network devices, significantly improving the overall throughput and response speed. Simultaneously, a precise identifier matching mechanism ensures the correct association between requests and responses in high-concurrency scenarios, preventing result corruption. This provides flexibility while guaranteeing the reliability and determinism of the management platform in large-scale device management.

[0049] Furthermore, the management platform can continuously maintain deployed interfaces. This means that by repeatedly sending the same interface identifier but updated logic files to the same network device, it can upgrade specific interfaces or roll back to previous versions. This mechanism not only applies to the iteration of service configuration interfaces but can also be extended to updates to the underlying system modules of network devices. Specifically, the management platform can deploy dedicated upgrade interface files to network devices. By calling these interfaces, the platform drives the network device to complete online updates and functional integration of kernel modules, drivers, or basic services, thereby achieving remote, seamless upgrades and capability expansion of the entire network device system software.

[0050] As can be seen, the logic file in this embodiment uses a lightweight script format such as Python bytecode (.pyc), which can effectively compress the file size compared to the original source code file. At the same time, remote call requests and responses are encapsulated in JSON format, which has lower data redundancy than traditional formats such as XML, significantly reducing the amount of data transmitted. Furthermore, the batch deployment process is further optimized through incremental transmission and differential update mechanisms. The complete logic file is transmitted during the initial deployment, and only file differences such as interface parameter modifications and logic code increments are transmitted during version upgrades or rollbacks. This ensures that the total amount of data in batch deployment is effectively managed, thereby effectively avoiding the increased communication load caused by full transmission.

[0051] The service invocation method provided in this disclosure can be executed by a terminal or by a chip applied to the terminal.

[0052] For example, the aforementioned terminals may include one or more of the following: mobile phones, tablets, wearable devices, in-vehicle devices, laptops, ultra-mobile personal computers (UMPCs), netbooks, handheld computers (PDAs), and wearable devices based on augmented reality (AR) and / or virtual reality (VR) technologies. They may also include, but are not limited to, remote control devices, wearable devices, streetlights, home appliances, and other smart terminals. This disclosure does not impose specific limitations on these aspects.

[0053] Figure 2 This is a flowchart illustrating a service invocation method according to an embodiment of this disclosure. Figure 2 As shown, the service invocation methods applied to the target network device include: S201: In response to a connection request from the management platform, establish a connection with the management platform and send a connection success message back to the management platform.

[0054] S202, in response to the interface deployment request from the management platform, registers multiple remote call services according to the interface deployment request, and sends a deployment success message back to the management platform.

[0055] In some embodiments, after receiving an interface deployment request from the management platform, the target network device parses the multiple logical files carried in the deployment request and stores the logical file paths and metadata of each interface in a local interface registration dictionary, using the service identifiers in the logical files as keys, thus completing the dynamic registration of multiple remote call services. Furthermore, upon successful registration, the target network device immediately sends a structured deployment success confirmation message to the management platform via a WebSocket connection. This message contains a list of all service identifiers that have been successfully registered.

[0056] Specifically, when the target network device receives an interface deployment request, it loads each logic file, extracts all the interfaces defined inside, aggregates and registers these interfaces as a remote call service corresponding to the logic file, and binds and stores the logic file identifier with the target service identifier of the remote call service to ensure that the corresponding logic file and its subordinate interfaces can be accurately located through the service identifier when making a call.

[0057] In this way, the target device proactively sends a success message after completing local registration, enabling the management platform to perceive the deployment status in real time and accurately. This completely changes the blind operation mode of traditional configuration methods that assumes success upon deployment. This two-way confirmation mechanism not only significantly improves the reliability and auditability of configuration operations, but also provides accurate status information for subsequent batch deployments, version management, and dependency scheduling. It fundamentally avoids invocation errors caused by deployment failures and enhances the determinism and automation level of the entire operation and maintenance system.

[0058] S203, in response to a remote call request from the management platform, invoke the target remote call service to execute the remote call request based on the target service identifier included in the remote call request, wherein the target service identifier is the identifier of the target remote call service.

[0059] In some embodiments, in response to a remote call request from a management platform, the target network device first parses the target service identifier from the JSON data of the request; then, it queries the local interface registration dictionary using the target service identifier as the key to obtain the corresponding interface logic file path and metadata; and then dynamically loads and executes the target interface function through Python reflection mechanism to complete the configuration or query operation indicated by the remote call request.

[0060] By using structured target service identifiers as the call entry point, network devices can quickly locate and trigger specific remote services, directly converting complex business intentions into executable operations on the device side. This not only shields the heterogeneity of the underlying implementation but also ensures the flexibility and dynamism of the execution process through reflection calls. This enables the management and control platform to drive network devices in a declarative and stateless manner, significantly improving the accuracy, response speed, and maintainability of remote configuration calls in large-scale, multi-service scenarios, and providing core instruction execution guarantees for automated operation and maintenance.

[0061] S204 sends the execution result of the remote call request to the management platform.

[0062] In summary, the embodiments disclosed herein fully construct a closed-loop system encompassing connection establishment, service deployment, invocation execution, and result feedback, thoroughly realizing remote, dynamic, and automated network device configuration management. This design upgrades the traditional static and discrete device configuration process into a programmable interactive system based on bidirectional real-time communication. Through proactive state feedback at each step, the management platform gains precise state perception and control capabilities over remote network devices, fundamentally solving the core pain points of black-box configuration operations and state agnosticity in distributed environments. Simultaneously, leveraging identifier-based service addressing and reflection execution mechanisms, it provides extreme deployment flexibility and execution elasticity while ensuring high reliability, providing a solid technical foundation for building an intelligent, adaptive, large-scale network operation and maintenance system.

[0063] In some embodiments, the interface deployment request carries multiple logic files, each logic file defining at least one interface, and a remote call service corresponds to one logic file. In response to the interface deployment request from the management platform, multiple remote call services are registered according to the interface deployment request, including: for any logic file, loading the logic file to register at least one interface defined in the logic file as a remote call service.

[0064] Specifically, when the target network device receives an interface deployment request containing multiple logic files, its interface deployment module will traverse each logic file in the request and perform loading operations in sequence: for any logic file, the logic file is first loaded into the local Python runtime environment, then one or more interface functions defined in the logic file are extracted, and the corresponding function references and metadata are registered in the local interface registration dictionary using the preset service identifier of each interface as the key, thereby completing the remote call service registration of all interfaces in the logic file.

[0065] This allows the management platform to aggregate relevant interfaces into a single logic file for batch deployment, while network devices can automatically disassemble and accurately register each independent interface. This maintains ease of deployment while ensuring refined management of service registration. This not only significantly improves the efficiency and reliability of batch deployment of multiple interfaces but also lays a solid foundation for subsequent interface discovery, version control, and independent invocation through a clear load-registration process. It greatly enhances the management platform's deployment flexibility and maintainability when facing complex, composite business functions.

[0066] The foregoing primarily describes the solutions provided by the embodiments of this disclosure from the perspective of the server. It is understood that, in order to implement the above functions, the server includes the corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, based on the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein, this disclosure can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0067] This disclosure embodiment can divide the server into functional units according to the above method example. For example, it can divide each function into separate functional modules, or it can integrate two or more functions into one management module. The integrated module can be implemented in hardware or as a software functional module. It should be noted that the module division in this disclosure embodiment is illustrative and only represents one logical functional division. In actual implementation, there may be other division methods.

[0068] In the case of dividing each function into different modules, an exemplary embodiment of this disclosure provides a remote calling device for a network device, which can be a server or a chip applied to a server. Figure 3 This is a schematic diagram of the structure of a remote invocation device for a network device provided in one embodiment of this disclosure. Figure 3 As shown, the remote invocation device 300 of the network device includes: The acquisition module 301 is used to acquire the identification information of the target network device and send a connection request to the target network device according to the identification information.

[0069] The first sending module 302 is used to send an interface deployment request to the target network device in response to a connection success message from the target network device, so as to control the target network device to register multiple remote call services.

[0070] The second sending module 303 is used to send a remote call request to the target network device in response to a deployment success message from the target network device, wherein the remote call request includes a target service identifier.

[0071] The receiving module 304 is used to receive the execution result from the target network device in response to the remote call request.

[0072] In one alternative approach, the remote call request includes a target service identifier, and the receiving module 304 is further configured to obtain the service identifier included in the execution result; if the service identifier matches the target service identifier in the remote call request, the remote call request and the execution result are associated.

[0073] In one alternative approach, the interface deployment request carries multiple logic files, each logic file defining at least one interface, and the remote call service corresponds one-to-one with the logic file.

[0074] An exemplary embodiment of this disclosure provides a service invocation apparatus, which may be a server or a chip applied to a server. Figure 4 This is a schematic diagram of a service invocation device provided in one embodiment of the present disclosure. Figure 4 As shown, the service invocation device 400 includes: The connection module 401 is used to respond to a connection request from the management and control platform, establish a connection with the management and control platform, and send a connection success message back to the management and control platform; The registration module 402 is used to respond to the interface deployment request from the management and control platform, register multiple remote call services according to the interface deployment request, and send a deployment success message back to the management and control platform; The calling module 403 is used to respond to a remote call request from the management and control platform, and to call a target remote call service to execute the remote call request according to the target service identifier included in the remote call request, wherein the target service identifier is the identifier of the target remote call service; The third sending module 404 is used to send the execution result to the control platform.

[0075] In an alternative approach, the interface deployment request carries multiple logic files, each logic file defining at least one interface, and one remote call service corresponds to one logic file. The registration module 402 is further configured to load the logic file for any given logic file to register at least one interface defined in the logic file as a remote call service.

[0076] This disclosure also provides an electronic device, including: at least one processor; a memory for storing at least one processor-executable instruction; wherein the at least one processor is used to execute the instruction to implement the steps of the method disclosed in this disclosure.

[0077] Figure 5 This is a schematic diagram of the structure of an electronic device provided according to an embodiment of the present disclosure. Figure 5 As shown, the electronic device 500 includes at least one processor 501 and a memory 502 coupled to the processor 501, which can perform the corresponding steps in the methods disclosed in the embodiments of this disclosure.

[0078] The processor 501 described above can also be called a Central Processing Unit (CPU), which can be an integrated circuit chip with signal processing capabilities. Each step in the method disclosed in this embodiment can be implemented by the integrated logic circuitry in the processor 501 or by software instructions. The processor 501 can be a general-purpose processor, a digital signal processor (DSP), an ASIC, a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in this embodiment can be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software modules can be located in the memory 502, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The processor 501 reads information from the memory 502 and, in conjunction with its hardware, completes the steps of the method described above.

[0079] Furthermore, various operations / processes according to this disclosure, implemented via software and / or firmware, can be transmitted from a storage medium or network to a computer system with a dedicated hardware architecture, for example, Figure 6 The computer system 600 shown is equipped with the programs that constitute the software. When various programs are installed, the computer system is able to perform various functions, including those described above. Figure 6 This is a schematic diagram of the structure of a computer system provided in an embodiment of the present disclosure.

[0080] Computer system 600 is intended to represent various forms of digital electronic computer devices, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the present disclosure described and / or claimed herein.

[0081] like Figure 6 As shown, the computer system 600 includes a computing unit 601, which can perform various appropriate actions and processes based on a computer program stored in a read-only memory (ROM) 602 or a computer program loaded from a storage unit 608 into a random access memory (RAM) 603. The RAM 603 may also store various programs and data required for the operation of the computer system 600. The computing unit 601, ROM 602, and RAM 603 are interconnected via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0082] Multiple components in the computer system 600 are connected to the I / O interface 605, including: an input unit 606, an output unit 607, a storage unit 608, and a communication unit 609. The input unit 606 can be any type of device capable of inputting information into the computer system 600. The input unit 606 can receive input digital or character information and generate key signal inputs related to user settings and / or function control of the electronic device. The output unit 607 can be any type of device capable of presenting information and may include, but is not limited to, a monitor, speaker, video / audio output terminal, vibrator, and / or printer. The storage unit 608 may include, but is not limited to, a hard disk and an optical disk. The communication unit 609 allows the computer system 600 to exchange information / data with other devices via a network such as the Internet, and may include, but is not limited to, a modem, network card, infrared communication device, wireless communication transceiver, and / or chipset, such as Bluetooth™ devices, WiFi devices, WiMax devices, cellular communication devices, and / or the like.

[0083] The computing unit 601 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of the computing unit 601 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. The computing unit 601 performs the various methods and processes described above. For example, in some embodiments, the methods disclosed in this disclosure can be implemented as a computer software program tangibly contained in a machine-readable medium, such as storage unit 608. In some embodiments, part or all of the computer program can be loaded and / or installed on an electronic device via ROM 602 and / or communication unit 609. In some embodiments, the computing unit 601 can be configured to perform the methods disclosed in this disclosure by any other suitable means (e.g., by means of firmware).

[0084] This disclosure also provides a computer-readable storage medium, wherein when the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device is able to perform the methods disclosed in this disclosure.

[0085] The computer-readable storage medium in this disclosure can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. The aforementioned computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specifically, the aforementioned computer-readable storage medium may include electrical connections based on one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing.

[0086] The aforementioned computer-readable medium may be included in the aforementioned electronic device; or it may exist independently and not assembled into the electronic device.

[0087] Figure 7 This is a schematic diagram of a computer program product provided according to an embodiment of the present disclosure. Figure 7 As shown, the computer program product 700 includes a computer program 701, which, when executed by a processor, implements the methods disclosed in the embodiments of this disclosure.

[0088] In embodiments of this disclosure, computer program code for performing the operations of this disclosure can be written in one or more programming languages ​​or a combination thereof. These programming languages ​​include, but are not limited to, object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)), or it can be connected to an external computer.

[0089] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0090] The modules, components, or units described in the embodiments of this disclosure can be implemented in software or hardware. The names of the modules, components, or units do not necessarily constitute a limitation on the module, component, or unit itself.

[0091] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary hardware logic components that can be used include: field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SoCs), complex programmable logic devices (CPLDs), and so on.

[0092] The above description is merely an illustration of some embodiments of this disclosure and the technical principles employed. Those skilled in the art should understand that the scope of this disclosure is not limited to technical solutions formed by specific combinations of the above-described technical features, but should also cover other technical solutions formed by arbitrary combinations of the above-described technical features or their equivalents without departing from the above-described concept. For example, technical solutions formed by substituting the above features with (but not limited to) technical features disclosed in this disclosure that have similar functions.

[0093] While specific embodiments of this disclosure have been described in detail by way of example, those skilled in the art should understand that the examples are for illustrative purposes only and not intended to limit the scope of this disclosure. Those skilled in the art should understand that modifications can be made to the above embodiments without departing from the scope and spirit of this disclosure. The scope of this disclosure is defined by the appended claims.

Claims

1. A method for remotely invoking a network device, characterized in that, Applications in management and control platforms include: Obtain the identification information of the target network device, and send a connection request to the target network device based on the identification information; In response to a connection success message from the target network device, an interface deployment request is sent to the target network device to control the target network device to register multiple remote call services; In response to a deployment success message from the target network device, a remote call request is sent to the target network device, wherein the remote call request includes a target service identifier; Receive the execution result from the target network device in response to the remote call request.

2. The method according to claim 1, characterized in that, The remote call request includes a target service identifier, and the method of receiving the execution result from the target network device in response to the remote call request further includes: The service identifier included in the execution result is obtained; If the service identifier matches the target service identifier in the remote call request, the remote call request and the execution result are associated.

3. The method according to claim 1, characterized in that, The interface deployment request carries multiple logic files, each of which defines at least one interface, and one remote call service corresponds to one logic file.

4. A service invocation method, characterized in that, Applied to target network devices, including: In response to a connection request from the management and control platform, a connection is established with the management and control platform, and a connection success message is sent back to the management and control platform; In response to an interface deployment request from the management and control platform, multiple remote call services are registered according to the interface deployment request, and a deployment success message is sent back to the management and control platform. In response to a remote call request from the management platform, the target remote call service is invoked to execute the remote call request according to the target service identifier included in the remote call request, wherein the target service identifier is the identifier of the target remote call service; Send the execution result of the remote call request to the management and control platform.

5. The method according to claim 4, characterized in that, The interface deployment request carries multiple logic files, each logic file defining at least one interface, and one remote invocation service corresponds to one logic file. In response to the interface deployment request from the management platform, registering multiple remote invocation services according to the interface deployment request includes: For any given logic file, load the logic file to register at least one interface defined in the logic file as a remote invocation service.

6. A remote access device for a network device, characterized in that, include: The acquisition module is used to acquire the identification information of the target network device and send a connection request to the target network device based on the identification information; The first sending module is used to send an interface deployment request to the target network device in response to a connection success message from the target network device, so as to control the target network device to register multiple remote call services; The second sending module is configured to send a remote call request to the target network device in response to a deployment success message from the target network device, wherein the remote call request includes a target service identifier; The receiving module is used to receive the execution result from the target network device in response to the remote call request.

7. A service invocation device, characterized in that, include: The connection module is used to respond to a connection request from the management and control platform, establish a connection with the management and control platform, and send a connection success message back to the management and control platform; The registration module is used to respond to the interface deployment request from the management and control platform, register multiple remote call services according to the interface deployment request, and send a deployment success message back to the management and control platform. The invocation module is used to respond to a remote invocation request from the management and control platform, and invoke a target remote invocation service to execute the remote invocation request according to the target service identifier included in the remote invocation request, wherein the target service identifier is the identifier of the target remote invocation service; The third sending module is used to send the execution results to the management and control platform.

8. A computer device, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 3.

9. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 3.

10. A computer program product comprising a computer program / instructions, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 3.

Images