A distributed system plug-in management method, device and equipment and storage medium

Abstract

Embodiments of the present application disclose a kind of distributed system plug-in management method, device, equipment and storage medium, wherein, method includes: in the case where network request instruction is received, at least one target function plug-in is determined based on checksum parameter in the network request instruction;For each target function plug-in, in the case where the target function plug-in contains configuration file, based on the loading function extension data of the configuration file, and the function extension data is distributed to the target function plug-in;So that the target function plug-in loads and runs the function extension data, and provides corresponding function service for the network request instruction.The technical scheme provided in the embodiments of the present application can provide a kind of standardized management mode based on function plug-in processing business request, so as to simplify the function implementation process of client program in complex and changeable distributed environment, and improve the overall reliability and operating efficiency of system.

Description

Technical Field

[0001] The embodiments of the present invention relate to the field of distributed system management technology, and in particular to a method, apparatus, device and storage medium for plug-in management of distributed systems. Background Technology

[0002] Traditional distributed client programs typically employ a highly coupled design, with business logic and technical implementation often intertwined. This design pattern makes it easy for the code to become more complex when new features are introduced or existing features are modified, and it can also potentially impact system stability. Furthermore, a monolithic client program struggles to handle dynamic business expansion needs and flexibly support diverse user requirements. For example, in a multi-user distributed environment, different users often have different access permissions, which need to be dynamically bound to different business functions, further increasing the complexity of the client program design.

[0003] Existing distributed client management frameworks typically face the following problems: high coupling between business logic and technical implementation. Many systems embed business logic directly into the underlying code, leading to extensive modifications to existing code when expanding functionality, which easily results in code errors and system instability. Therefore, how to rationally layer and functionally divide the internal business modules of client programs, given the dual characteristics of business logic and technical implementation, to improve development efficiency and reduce maintenance costs, has become an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a method, apparatus, device, and storage medium for managing plug-in systems in a distributed system. It solves the problem that the high coupling between business logic and technical implementation in the prior art can easily lead to system instability. It can provide a standardized management method for handling business requests based on functional plug-ins, thereby simplifying the functional implementation process of client programs in complex and ever-changing distributed environments and improving the overall reliability and operating efficiency of the system.

[0005] In a first aspect, embodiments of the present invention provide a method for managing plug-in systems in a distributed system, the method comprising: Upon receiving a network request instruction, at least one target functional plugin is determined based on the checksum parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, functional extension data is loaded based on the configuration file, and the functional extension data is distributed to the target functional plugin; so that the target functional plugin loads and runs the functional extension data, and provides corresponding functional services for the network request instruction.

[0006] In a second aspect, embodiments of the present invention provide a distributed system plug-in management device, the device comprising: A data acquisition module is used to determine at least one target functional plugin based on the checksum parameters in the network request instruction upon receiving a network request instruction; a functional extension data loading module is used to load functional extension data based on the configuration file if the target functional plugin contains a configuration file, and distribute the functional extension data to the target functional plugin; a functional service providing module is used to enable the target functional plugin to load and run the functional extension data, and provide corresponding functional services for the network request instruction.

[0007] Thirdly, embodiments of the present invention provide a computer device, the computer device comprising: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed system plug-in management method described in any embodiment.

[0008] Fourthly, embodiments of the present invention provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the distributed system plug-in management method described in any embodiment.

[0009] The technical solution provided by this invention, upon receiving a network request instruction, determines at least one target functional plugin based on the checksum parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, it loads functional extension data based on the configuration file and distributes the functional extension data to the target functional plugin; thereby enabling the target functional plugin to load and run the functional extension data and provide corresponding functional services for the network request instruction. This solves the problem of high coupling between business logic and technical implementation in existing technologies, which can easily lead to system instability. It provides a standardized management method for handling business requests based on functional plugins, simplifying the functional implementation process of client programs in complex and ever-changing distributed environments and improving the overall reliability and operating efficiency of the system. Attached Figure Description

[0010] Figure 1 This is a flowchart of a distributed system plug-in management method provided by an embodiment of the present invention; Figure 2 This is a flowchart of another distributed system plug-in management method provided by an embodiment of the present invention; Figure 3This is a framework diagram of a distributed system plug-in management device provided in an embodiment of the present invention; Figure 4 This is a flowchart illustrating the process of determining user function plugins according to an embodiment of the present invention; Figure 5 This is a schematic diagram illustrating the achievable functions of plug-in management in a distributed system according to an embodiment of the present invention; Figure 6 This is a flowchart of a loading function plugin provided in an embodiment of the present invention; Figure 7 This is a flowchart illustrating the lifecycle of a management function plugin provided in an embodiment of the present invention; Figure 8 This is a schematic diagram of the structure of a distributed system plug-in management device provided in an embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0011] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. The acquisition, storage, use, and processing of data in the technical solutions of the embodiments of the present invention all comply with the relevant provisions of national laws and regulations.

[0012] Figure 1 This is a flowchart of a distributed system plug-in management method provided by an embodiment of the present invention. The embodiment of the present invention can be applied to the scenario of plug-in management in a distributed operating system. The method can be executed by a distributed system plug-in management device, which can be implemented by software and / or hardware.

[0013] like Figure 1 As shown, the plug-in management method for distributed systems includes the following steps: S110. Upon receiving a network request instruction, determine at least one target functional plugin based on the checksum parameters in the network request instruction.

[0014] The network request instruction can be a request instruction requiring the implementation of distributed network functions. The technical solution of this embodiment can, upon receiving a network request instruction, allocate corresponding functional plugins to provide services based on the business requirements corresponding to the network request instruction. The checksum parameter can be a parameter used to indicate the type of business requirement. Specifically, the checksum parameter can be set by the user according to business requirements, or it can be determined by extracting the specific request business from the network request instruction. The target functional plugin can be a plugin used to provide the business function corresponding to the network request instruction. Specifically, a mapping relationship between the checksum parameter and the functional plugin can be preset, and then, based on this mapping relationship, a corresponding functional plugin can be matched according to the checksum parameter in the network request instruction, and the matched functional plugin can be designated as the target functional plugin for the network request.

[0015] S120. For each target function plugin, if the target function plugin contains a configuration file, load the function extension data based on the configuration file and distribute the function extension data to the target function plugin.

[0016] The configuration file can be a file corresponding to a functional plugin that allows configuration of extended functions (additional functions beyond the basic functions provided by the functional plugin). The extended function data can be the specific parameter data of the extended functions that the target functional plugin can provide. Furthermore, the extended function data can be distributed to the target functional plugin so that the target functional plugin can configure its own specific parameters according to the extended function data.

[0017] S130, to enable the target function plugin to load and run function extension data, and to provide corresponding function services for network request commands.

[0018] Upon receiving the extended functionality data, the target functional plugin can load and run the extended functionality data, set the corresponding plugin parameters within the functional plugin through the extended functionality data, and provide extended functionality to the requester of the network request instruction based on the running extended functionality data.

[0019] The technical solution provided by this invention, upon receiving a network request instruction, determines at least one target functional plugin based on the verification and parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, it loads functional extension data based on the configuration file and distributes the functional extension data to the target functional plugin; thereby enabling the target functional plugin to load and run the functional extension data and provide corresponding functional services for the network request instruction. This solves the problem of high coupling between business logic and technical implementation in existing technologies, which can easily lead to system instability. It provides a standardized management method for handling business requests based on functional plugins, simplifying the functional implementation process of client programs in complex and ever-changing distributed environments and improving the overall reliability and operating efficiency of the system.

[0020] Figure 2 This is a flowchart of another distributed system plug-in management method provided by the embodiments of the present invention. The embodiments of the present invention can be applied to the scenario of plug-in management in a distributed operating system. Based on the above embodiments, this embodiment further explains how to load and run functional extension data of the target functional plug-in and provide corresponding functional services for network request commands. The device can be implemented by software and / or hardware and integrated into a computer device with application development capabilities.

[0021] like Figure 2 As shown, the plug-in management method for distributed systems includes the following steps: S210. Upon receiving a network request instruction, determine at least one target functional plugin based on the checksum parameters in the network request instruction.

[0022] The network request instruction can be a request instruction requiring the implementation of distributed network functions. The technical solution of this embodiment can, upon receiving a network request instruction, allocate corresponding functional plugins to provide services based on the business requirements corresponding to the network request instruction. The checksum parameter can be a parameter used to indicate the type of business requirement. Specifically, the checksum parameter can be set by the user according to business requirements, or it can be determined by extracting the specific request business from the network request instruction. The target functional plugin can be a plugin used to provide the business function corresponding to the network request instruction. Specifically, a mapping relationship between the checksum parameter and the functional plugin can be preset, and then, based on this mapping relationship, a corresponding functional plugin can be matched according to the checksum parameter in the network request instruction, and the matched functional plugin can be designated as the target functional plugin for the network request.

[0023] For example, to facilitate understanding of the technical solution, a framework diagram of a distributed system plug-in management device application is first introduced here. For example, Figure 3This is a framework diagram of a distributed system plug-in management device application provided by an embodiment of the present invention. The embodiment of the present invention is based on the Codigger product, and utilizes the Mulet Manager developed based on the Mutli Space architecture. The Mulet plug-in management framework design uses a Module pattern for development, and manages and operates through a Module repository. The following describes... Figure 3 The components are described below: 1. Mulet (Function Plugin): A general program framework for loading dynamic link libraries. Mulets that load dynamic link libraries are function plugins managed by Mulet Manager. Various types of Mulets provide infrastructure services for Codigger Application, support the Codigger system's extensibility, enhance the system's basic capabilities through Mulets, and declaratively support various heterogeneous networks, forming a unified whole between CDS and other networks.

[0024] 2. Workgroup (processing workgroup within a functional plugin): A workgroup that processes network requests for a specific type of Mulet business logic, running in an independent thread. Codigger Users access Mulets as Peers, and Mulets provide Mulet Services to Codigger Users through the Workgroup that handles the specific business logic.

[0025] 3. SPI: Service Provider Interface, or SPI for short, is a mechanism for dynamically loading extension points. It allows service providers to dynamically provide an implementation for an interface at runtime, without needing to hard-code it at compile time. The core idea of ​​this mechanism is to move the control of assembly outside the program, and by decoupling the interface from the service in a modular design, it provides a pluggable extension mechanism.

[0026] 4. Dynamic Link Library (hereinafter referred to as LoadableMulet): In this article, the dynamic link library loaded by the Mulet program framework refers to the dynamic shared library (Dynamic Mulet Library) that is loaded only at runtime. ① It is responsible for the specific business implementation of the Mulet, including starting the shared library to listen on the port and starting the service, which are all business logics within the shared library. The shared library responds to network requests from the Codigger User by creating a Workgroup. ② The dynamic link library acting as the Mulet Client obtains a client connection from the connection pool, writes request data, and initiates a request; the dynamic link library acting as the Mulet Server obtains business requests or writes response data from the service connection distributed by the Mulet Manager. ③ The Mulet handles the passing of connections through a pre-defined interface, but is not responsible for handling any internal business logic. The dynamic link library should ensure the thread safety of resources that the Mulet calls to the internal implementation logic of its pre-defined interface.

[0027] 5. Mulet Manager: (Can be understood as a distributed system plug-in management device) Based on the Mulet plug-in management framework, it manages the lifecycle of Mulet programs and acts as the overall business message distributor (mainly the Mulet management instructions passed in the connection and requests from other Mulets forwarded by MuletManager), and interacts with the Codigger system and its users for management business.

[0028] When Mulet Manager starts, it uses the SPI mechanism to launch plugins via the muletrc configuration. Multiple plugins run in isolated threads, and the Mulet performs the startup operation by instantiating the implementation class. When loading each Mulet, Mulet Manager calculates the checksum of each Mulet and stores it in memory for verification in subsequent business requests.

[0029] The Port Table is the core data structure maintained within Mulet Manager, representing the association between ports and connections. A connection is a logical connection object within the Port system. A connection identifies the logical connection between a Client Port and a Server Port. The Port Table is split by user; each application starts by explicitly specifying the starting user, and subsequent Instance ID allocation, record writing, querying, and binding all occur only within the Port Table corresponding to that user. This set of numbers is jointly defined by the Client and Server involved in the record. 1. The Eager preparation node related records are fixed at 0.

[0030] 2. The record for communication between built-in Mulets is fixed at 1.

[0031] 3. Application Peer-related records are uniformly allocated by the Essence Mulet, starting from 2 and incrementing.

[0032] The Eager preheating record and the Peer connection information corresponding to the actual application runtime are also written to the corresponding user's Port Table through MuletManager.

[0033] One Port Table record represents one unidirectional Connection: 1. There is one record from the client to the server.

[0034] 2. If communication is required between the server and the client, it is recorded in a separate record.

[0035] 3. Within the Port Table of the same user, a record must have at least two sets of conditions that can be used to uniquely identify it: username + instance id + clientname + servername, and username + serverport.

[0036] 4. Under the same user, there is no requirement for a semantically duplicate second record from the Client to the Server, nor is it allowed for two different records to reuse the same Server Port.

[0037] 5. If the same unidirectional join is repeatedly inserted, the semantics should be considered idempotent: return the same existing record and keep the insertion result stable.

[0038] Optionally, if the network request instruction contains user personal information, the corresponding user function plugin can be determined based on the user personal information, the user function plugin can be loaded and started, and a plugin connection request can be dispatched to the target function plugin; wherein, the plugin connection request is used to request the establishment of a communication connection between the user function plugin and the target function plugin.

[0039] The user's personal information can be the personal identification information of a distributed system user (or target user). Specifically, user personal information may include username, environment variables, regional address, and user token, etc. The user function plugin can be a function plugin that provides a separate service to the target user during this business service process. Specifically, the user function plugin can be identified from the function plugins loaded in business requests issued by the target user within a historical period. Therefore, when the network request instruction contains user personal information, the target user can be located based on the user personal information, and the corresponding user function plugin can be loaded. Furthermore, the user function plugin can send a plugin connection request to the target function plugin, establishing a communication connection between the two types of function plugins.

[0040] Optionally, the corresponding user function plugin is determined based on the user's personal information, and the user function plugin is loaded and started, including: performing user authentication based on the user's personal information to obtain the authentication result; if the authentication result is successful, determining the business request information based on the network request instruction, and selecting the user function plugin from the user's existing plugins based on the business request information; loading and starting the user function plugin in the user space, and loading and starting the target function plugin in the kernel space.

[0041] The authentication result can be a verification of whether the user's identity information is correct. Specifically, the user's personal information can be matched with the user information stored in the database. If the data in both sets of user information matches, the authentication result is considered successful; otherwise, the authentication result is considered unsuccessful. Existing user plugins can be functional plugins that the user has loaded during historical periods. Specifically, functional plugins that provided services to the target user during historical business requests can be considered as the target user's existing plugins. That is, each distributed user has independent existing plugins, and this system can establish a mapping relationship between users and their corresponding existing functional plugins to achieve effective management of user-level functional plugins.

[0042] Furthermore, based on the business type in the business request information, plugins that can serve that business type can be selected from the user's existing plugins as user function plugins. Further, the user function plugin can be loaded and started in user space, and the target function plugin can be loaded and started in kernel space. By loading the corresponding function plugins in two different spaces, user-level function plugins can run independently from system and function plugins, avoiding mutual interference and improving communication stability.

[0043] For example, Figure 4 This is a flowchart illustrating the process of determining user function plugins according to an embodiment of the present invention. Figure 4 As shown, Mulet Manager loads and starts the Mulet modules of the Kernel Space by default based on the muletrc of the Kernel Space (username: root).

[0044] Loading and starting Mulets in User Space is business-driven. When a client application initially requests a Mulet, it must first send (in sequence) the username, checksum, environment, region address, and user token. After verifying the user token, the Mulet Manager loads and starts all Mulets (existing plugins of the user) under the `.muletrc` file of that user space, and simultaneously dispatches a connection to the target Mulet requested by the user. (This example uses loading all existing plugins; it's also possible to filter user-specific plugins from existing plugins and connect them to the target plugin.) Connection reuse is combined with Connection Pool. Workgroups in Mulets need to maintain worker threads (Workgroups run in the worker pool provided by Multi Space). When a client application resends a request by reusing a connection, it must first send username, checksum, and env (in sequence) for verification.

[0045] On the Mudem side, after establishing a physical connection with the client application, it needs to send the username, checksum, environment, region address, and user token to establish a dispatch connection to the Mulet on the Mulet Manager side. If the Mulet being accessed is located in the Kernel Space, the username needs to be defined in the $(CDS_ROOT) / etc / sudoers file.

[0046] Example of a sudoers file: username / ALL “allow the user to access all kernel mulet username / mulet-onecloud-storage / mulet-onecloud-library-libc “allowthe user to access the specific kernel mulet.

[0047] S220. For each target function plugin, if the target function plugin contains a configuration file, load the function extension data based on the configuration file and distribute the function extension data to the target function plugin.

[0048] The configuration file can be a file corresponding to a functional plugin that allows configuration of extended functions (additional functions beyond the basic functions provided by the functional plugin). The extended function data can be the specific parameter data of the extended functions that the target functional plugin can provide. Furthermore, the extended function data can be distributed to the target functional plugin so that the target functional plugin can configure its own specific parameters according to the extended function data.

[0049] The business requirements of modern distributed systems change rapidly, and traditional static implementations are insufficient to meet these evolving needs. For example, adding new modules or adjusting business logic may require system restarts or extensive code modifications. By providing data expansion capabilities through configuration files, an efficient mechanism for dynamically extending business functionality is offered, enabling rapid deployment and adjustment of features based on changing business requirements.

[0050] Optionally, feature extension data can be loaded based on configuration files, including: loading feature extension data based on connection configuration files and connection pools in the configuration files.

[0051] The connection configuration file can represent the connection relationships between functional plugins and other nodes. The connection pool manages the business connections between the client and functional plugins, supporting the reuse of these connections. Furthermore, based on the connection configuration file and connection pool, a service channel for extending functionality can be built between the management client and functional plugins.

[0052] S230, to load and run the feature extension data in the target feature plugin, and to transfer the feature extension data to the processing workgroup within the target feature plugin.

[0053] The processing workgroup can be a workgroup within the target functional plugin used to provide a single type of functional business. For example, in a target functional plugin running in an independent thread, the processing workgroup for a specific business type can be accessed by distributed clients as nodes. The target functional plugin provides plugin functional services to the distributed clients through the processing workgroup that handles the specific business logic. Furthermore, the target functional plugin can pass functional extension data to its internal processing workgroup, allowing the processing workgroup to configure its specific parameters based on the functional extension data.

[0054] S240, to enable the processing workgroup to load and run extended functionality data, and to provide corresponding functional services for network request commands.

[0055] Upon receiving the extended functionality data, the processing team can load and run the extended functionality data, and then provide extended functionality to the requester of the network request instruction based on the running extended functionality data.

[0056] For example, Figure 5 This is a schematic diagram illustrating the achievable functionality of a plug-in management system for a distributed system, as provided in an embodiment of the present invention. For example... Figure 5 As shown, the Mulet Manager implements the following functions: 1. Mulet Manager Infrastructure: The Mulet Manager, which runs on each thread pool worker, needs to ensure thread safety for its own resources, including Mulet creation, searching, Mulet list maintenance, and real-time updates of muletrc. The Mulet Manager implements its own automatic update mechanism.

[0057] 2. Mulet Manager Plugin Management Framework: Mulet plugin loading and unloading are achieved through MuletManager startup parameters (mudemId, username) to implement service and user isolation. Mulets are invoked according to Mulet management commands. Based on the username corresponding to the current runtime environment, and combining `$CDS_ROOT / etc / muletrc` (for Kernel Space runtime environments) and `$CDS_HOME / .muletrc` (for username-based runtime environments), Mulet registration and runtime information are persisted. The runtime status is updated in real-time through a specific Mulet in the env service (updating is performed by the specific Mulet module). When a Mulet is `rose uninstall`, its registration information is deleted, and it is no longer subject to the Mulet's restricted state.

[0058] 3. Mulet Manager Command Management Framework: Implements Mulet lifecycle management commands, supporting register, unregister, start, stop, enable, disable, and restrict management operations for Mulets. Through the rose command, it provides users with enable and disable security management operations for specific Mulets and global restrict management operations for non-default Mulets.

[0059] 4. Mulet Manager Basic Management Functions: Enables interaction with external interactive scenarios such as System Keeping, Notice, and Sandbox, and completes corresponding management operations for Mulets.

[0060] 5. Mulet Manager's message distribution based on the Codigger system: It realizes the interaction of communication links and corresponding protocol transmission based on the overlay network, which is the basis for Mulet Manager to interact with rose, System Keeping, and Notice.

[0061] The main steps to ensure thread safety include:

[0062] 1. When processing network requests, the Mulet Manager is designed as thread-safe code, running in each network request business processing thread. For messages routed from the Mudem, it finds the corresponding Mulet based on the checksum. The Mulet then routes the network request to the specified Workgroup based on the network request parameters. Network requests and responses between Mulets are passed through the read and write queues of Connections that establish connections between nodes.

[0063] 2. Load the Mulet according to Muletrc, and register the Mulet when sending the register command after rose install.

[0064] 3. Maintain the Mulet list and update muletrc in real time when the Mulet's running status changes.

[0065] 4. The Mulet Manager finds the corresponding Mulet based on the Mulet's checksum. At the same time, according to the Mulet's connectionrc configuration file (if any), it loads and runs the Mulet of this business type. This requires extending the data / function of the connection (Decorate Connection) during the Mulet Manager's runtime (the connection obtained by the Mulet is encapsulated on the basis of the Mulet Manager. Each Mulet adds its own functional implementation (i.e., data) on the basis of the business processing of the previous Mulet or MuletManager). Then, it distributes the Mulet's request data according to the superimposed network target address.

[0066] 5. Automatic Mulet Manager update: After `rose install raw-onecloud-mulet-manager`, it notifies Mudem that the loaded Mulet Manager dynamic library needs to be updated. Mudem notifies Mulet Manager that an update is needed through the command interface provided by Mulet Manager. After receiving an OK response, it uninstalls the Mulet Manager dynamic library and then reloads Mulet Manager in the same way as the startup process.

[0067] Optionally, after receiving the function plugin loading instruction sent by the network requester, the system can also register an initial function plugin based on the function plugin loading instruction; generate checksum parameters corresponding to the initial function plugin; initialize and start the kernel-level plugin service of the initial function plugin based on the dynamic link library; determine the peer information based on the username, example name and peer name in the function plugin loading instruction; encapsulate the peer information into a data packet; and send the data packet to the network requester.

[0068] In this context, the network requester can be the sender of the network request command. For example, the network requester can be the client of a distributed user. The function plugin loading command can be a request command that requires function plugin registration. The initial function plugin can be a raw function plugin without specific parameter settings.

[0069] For example, Figure 6 This is a flowchart illustrating a loading function plugin provided in an embodiment of the present invention. For example... Figure 6 As shown, the specific process of Mulet Manager loading Mulets is explained below: S1. Send registration command: Send a data packet containing a registration command through the connection.

[0070] S2. Register Mulet and generate checksum: The system registers Mulets (simulating clients or services) and generates corresponding checksums.

[0071] S3. Load based on attributes: Load relevant configurations or resources based on preset attribute information.

[0072] S4. Open Dynamic Link Library (dlopen library): Loads and opens the required dynamic library file.

[0073] S5. Start Kernel Mulet: Initializes and starts the kernel-level Mulet service or process.

[0074] S6. Obtain peer information: Obtain the corresponding peer information based on the username, instance ID, and peer name.

[0075] S7. Encapsulate command response data packets: Encapsulate the command response information into data packets.

[0076] S8. Return command response via connection: Send the encapsulated response data packet back to the requester via the connection.

[0077] Optionally, upon receiving a plugin status adjustment instruction, the lifecycle status of the functional plugins managed by the functional plugin management instruction can be adjusted. The lifecycle status includes: registered status, unregistered status, started status, stopped status, enabled status, disabled status, constrained status, or updated status. The constrained status is used to prohibit the start of non-default plugins or to prohibit the modification of the lifecycle status of functional plugins.

[0078] For example, Figure 7 This is a flowchart illustrating the lifecycle of a management function plugin provided in an embodiment of the present invention. For example... Figure 7 As shown, Mulet Manager manages the lifecycle of Mulets, supporting Register, Unregister, Start, Stop, Enable, Disable, and Restrict management operations for Mulets. Through the rose command, it provides users with enable and disable security management operations for specific Mulets and global restrict management operations for non-default Mulets.

[0079] Specifically, Mulet Manager supports management operations for Mulets, including register, unregister, start, stop, enable, disable, and restrict. It also provides users with enable and disable security management operations for specific Mulets and global restrict management operations for non-default Mulets through the rose mulet command.

[0080] 1. Registration (rose mulet register mulet-user-xxxxxx) The rose mulet register is an interactive command between rose and the Mulet Manager, which notifies the Mulet Manager to register the Mulet registration information (Mulet properties from Sense.ose, the current status of the Mulet (enabled, disabled, constrained)).

[0081] 2. Unregister When a Mulet is uninstalled, executing `rose uninstall` first executes `rose mulet disable`, then stops all instances of the Mulet module through Mulet Manager, deletes all registration information of the Mulet module, and deletes all records corresponding to the muletrc file, without being restricted by the Mulet's restrict attribute.

[0082] 3. Start (rose mulet start mulet-user-xxxxxx) The interaction between Rose and Mulet Manager involves Rose sending the command to Mulet Manager. (If Mulet Manager detects that the specified Mulet has been disabled or is in a restricted on state, it will issue a Notice and will not start the Mulet again, and will update the corresponding status in the Mulet's registration information.) Mulet Manager finds the specified Mulet based on the Mulet module path provided by Rose, starts it, and updates the corresponding status in the Mulet's registration information.

[0083] After the module is installed, Rose automatically installs the Mulet in the require configuration item and sends a command to the Mulet Manager to start the Mulet for the app module. If the Mulet is disabled or restricted on, a notification will be issued and the Mulet will not be started again.

[0084] During the operation of the Codigger application module, if any Mulet in its require configuration is disabled, or if the Mulet restrict global state is enabled, the Mulet Manager will stop the Mulet according to the rose command, update the corresponding status information, and issue a notification via Notice.

[0085] 4. Stop (rose Mulet stop Mulet-user-xxxxxx) The interaction between Rose and the Mulet manager involves Rose sending a command to the Mulet manager to stop the specified Mulet. The Mulet manager, based on the Mulet's properties, regardless of whether the Mulet is shared by an app module or has multiple Mulet instances, directly closes it and updates the corresponding status in the Mulet's registration information.

[0086] Running `rose mulet disable` or `rose uninstall` will stop mulet-user-xxxxxx.

[0087] 5. Enable (rose mulet enable mulet-user-xxxxxx) The `rose` command can be sent to the Mulet Manager via the Terminal to update the status of the Mulet used by the application module, register / update the corresponding status in the Mulet's registration information, and issue a notification.

[0088] The granularity of Mulet's activation state management is user + workstation + parent environment. This means that the activation state management of the same Mulet across different workstations (worker machines) of the same user, and across different users (worker machines) of the same Mulet, is separate. This granularity is achieved by the `rose` instruction, which sends commands at this level.

[0089] Mulets can be run in multiple instances. If the listening port of the shared business library is occupied when multiple instances are run, a notification will be sent, indicating the status information of the instance loaded by the Mulet.

[0090] This is a startup time for Mulet.

[0091] 6. Disable (rose mulet disable mulet-user-xxxxxx) The `rose` command can be sent to the Mulet Manager via the Terminal. The Mulet Manager will stop the Mulet and update its stopped and disabled status in the Mulet's registration information. A Notice will be sent to disable the Mulet.

[0092] After the command is executed, a Notice will be sent to all modules that depend on the Mulet.

[0093] 7. Constraints (rose mulet restrict yes / no) The `rose` command can be sent to the Mulet Manager via the Terminal to update the restricted status of the Mulet management information and to display a Notice indicating the global restricted status of the Mulet.

[0094] Restrict mulet operation: `restrict yes`: stop all mulets (except default). Restricting Mulet state modification: `restrict yes`: Disallows modification of the current Mulet state. Mulets are globally restricted (yes) by default (except for the default installed Mulets) and cannot be directly enabled by MuletManager. When the global restricted state of a Mulet is no, it automatically changes to enabled when the Mulet registers its information with MuletManager. When the global restricted state changes, MuletManager updates the Mulet's runtime management information in real time.

[0095] Management granularity: user + workstation 8. Update (rose update mulet-user-xxxxxx) Mulet management is consistent with regular Rose module commands, such as `rose install`, `roseuninstall`, and `rose update`, but a user token is required. To update a Mulet, Rose first executes `rose mulet stop`. The Mulet Manager receives the `rose mulet stop` command and stops the Mulet. Then, Rose executes `rose update`. After Rose completes this action, Rose executes `rose mulet start`. The Mulet Manager receives the `rose mulet start` command and starts the Mulet according to its `Sense.ose` properties.

[0096] In summary, compared with the prior art, the technical solution of the embodiments of the present invention has the following significant advantages: 1. Complete decoupling and improved development efficiency: Through the Mulet Manager framework, business logic is encapsulated in independent Mulet plugins, completely decoupled from the underlying technical framework. Different teams can develop, test, and release their respective business modules in parallel without interference, greatly improving development efficiency and code quality.

[0097] 2. Dynamic Expansion for Agile Business Operations: Based on SPI and dynamic shared library technology, new features can be dynamically loaded, unloaded, and updated as plugins without recompiling or restarting the main program. This enables clients to quickly respond to changes in business requirements, achieving true agile development and deployment.

[0098] 3. Enhanced security and multi-tenancy support: Through the isolation mechanism of kernel space / user space and fine-grained permission control, this invention can run securely in a multi-user environment, ensuring the isolation of user data and the protection of core system functions, laying a solid foundation for building multi-tenant client applications.

[0099] 4. Unified management and control, enhancing system maintainability: It provides unified, fine-grained lifecycle management capabilities, enabling operation and maintenance personnel to manage various functional modules of the client in the same way as managing operating system services, which greatly reduces the complexity and cost of system operation and maintenance.

[0100] 5. Improve system reliability and performance: Thread-safe design, connection reuse mechanism, and clear module boundaries jointly ensure the stability and high performance of client programs in high-concurrency scenarios.

[0101] The Mulet Manager pluggable management framework and implementation method provided by this invention successfully builds a flexible, robust, secure, and easily evolving architectural foundation for client modules of distributed operating systems. It effectively solves the core pain points of traditional client development and provides crucial technical support for building next-generation complex, large-scale distributed application clients.

[0102] The technical solution provided by this invention, upon receiving a network request instruction, determines at least one target functional plugin based on the verification and parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, it loads functional extension data based on the configuration file and distributes the functional extension data to the target functional plugin; this causes the target functional plugin to load and run the functional extension data, and then transmits the functional extension data to the processing workgroup within the target functional plugin; this causes the processing workgroup to load and run the functional extension data, and provide corresponding functional services for the network request instruction. This solves the problem of high coupling between business logic and technical implementation in existing technologies, which can easily lead to system instability. It provides a standardized management method for handling business requests based on functional plugins, simplifying the functional implementation process of client programs and improving the overall reliability and operating efficiency of the system in complex and ever-changing distributed environments.

[0103] Figure 8 This is a schematic diagram of the structure of a distributed system plug-in management device provided in an embodiment of the present invention. The embodiment of the present invention can be applied to the scenario of plug-in management in a distributed operating system. The device can be implemented by software and / or hardware and integrated into a computer device with application development capabilities.

[0104] like Figure 8 As shown, the distributed system plug-in management device includes: a data acquisition module 310, a function expansion data loading module 320, and a function service provision module 330.

[0105] The data acquisition module 310 is used to determine at least one target functional plugin based on the checksum parameters in the network request instruction upon receiving a network request instruction; the functional extension data loading module 320 is used to load functional extension data based on the configuration file if the target functional plugin contains a configuration file, and distribute the functional extension data to the target functional plugin; the functional service providing module 330 is used to enable the target functional plugin to load and run the functional extension data, and provide corresponding functional services for the network request instruction.

[0106] The technical solution provided by this invention, upon receiving a network request instruction, determines at least one target functional plugin based on the checksum parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, it loads functional extension data based on the configuration file and distributes the functional extension data to the target functional plugin; thereby enabling the target functional plugin to load and run the functional extension data and provide corresponding functional services for the network request instruction. This solves the problem of high coupling between business logic and technical implementation in existing technologies, which can easily lead to system instability. It provides a standardized management method for handling business requests based on functional plugins, simplifying the functional implementation process of client programs in complex and ever-changing distributed environments and improving the overall reliability and operating efficiency of the system.

[0107] In one optional implementation, the function service providing module 330 is specifically configured to: enable the target function plugin to load and run the function extension data, and transmit the function extension data to the processing workgroup within the target function plugin; enable the processing workgroup to load and run the function extension data, and provide corresponding function services for the network request instruction.

[0108] In an optional implementation, the distributed system plug-in management device further includes: a user function plug-in management module, configured to: determine the corresponding user function plug-in based on the user's personal information when the network request instruction contains user personal information, load and start the user function plug-in, and dispatch a plug-in connection request to the target function plug-in; wherein the plug-in connection request is used to request the establishment of a communication connection between the user function plug-in and the target function plug-in.

[0109] In one optional implementation, the user function plugin management module includes: a user function plugin startup unit, configured to: perform user authentication based on the user's personal information to obtain an authentication result; if the authentication result is successful, determine business request information based on the network request instruction, and filter the user function plugin from the user's existing plugins based on the business request information; load and start the user function plugin in the user space, and load and start the target function plugin in the kernel space.

[0110] In one optional implementation, the user function plugin loading unit includes a function plugin loading subunit, configured to: upon receiving a function plugin loading instruction sent by a network requester, register an initial function plugin based on the function plugin loading instruction; generate checksum parameters corresponding to the initial function plugin, and initialize and start the kernel-level plugin service of the initial function plugin based on a dynamic link library; determine peer information according to the username, example name, and peer name in the function plugin loading instruction, encapsulate the peer information into a data packet, and send the data packet to the network requester.

[0111] In one optional implementation, the function extension data loading module 320 includes: a connection configuration unit, configured to: load the function extension data according to the connection configuration file and connection pool in the configuration file; wherein the connection pool is used to manage business connections between the client and the function plugin, and supports the reuse of business connections.

[0112] In an optional implementation, the distributed system plug-in management device further includes: a functional plug-in state adjustment module, used to: adjust the lifecycle state of the functional plug-in under the functional plug-in management instruction upon receiving a plug-in state adjustment instruction; wherein the lifecycle state includes: registration state, deregistration state, startup state, stop state, enable state, disable state, constraint state, or update state; wherein the constraint state is used to prohibit the startup of non-default plug-ins or to prohibit the modification of the lifecycle state of functional plug-ins.

[0113] The distributed system plug-in management device provided in the embodiments of the present invention can execute the distributed system plug-in management method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0114] Figure 9 This is a schematic diagram of the structure of a computer device provided in an embodiment of the present invention. Figure 9 A block diagram of an exemplary computer device 12 suitable for implementing embodiments of the present invention is shown. Figure 9 The computer device 12 shown is merely an example and should not be construed as limiting the functionality or scope of the embodiments of the present invention. The computer device 12 can be any terminal device with computing capabilities and can be configured in a distributed system plug-in management device.

[0115] like Figure 9 As shown, the computer device 12 is represented in the form of a general-purpose computing device. The components of the computer device 12 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0116] Bus 18 can be one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0117] Computer device 12 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by computer device 12, including volatile and non-volatile media, removable and non-removable media.

[0118] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache 32. Computer device 12 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 9 Not shown; usually referred to as a "hard drive"). Although Figure 9 Not shown, a disk drive for reading and writing to a removable non-volatile disk (e.g., a "floppy disk") and an optical disk drive for reading and writing to a removable non-volatile optical disk (e.g., a CD-ROM, DVD-ROM, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0119] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0120] Computer device 12 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with the computer device 12, and / or with any device that enables the computer device 12 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed through input / output (I / O) interface 22. Furthermore, computer device 12 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 9 As shown, network adapter 20 communicates with other modules of computer device 12 via bus 18. It should be understood that, although... Figure 9 As not shown, it can be used in conjunction with computer device 12 with other hardware and / or software modules, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0121] Processing unit 16 executes various functional applications and data processing by running programs stored in system memory 28, such as implementing the distributed system plug-in management method provided in this embodiment of the invention, which includes: Upon receiving a network request instruction, at least one target functional plugin is determined based on the checksum parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, functional extension data is loaded based on the configuration file, and the functional extension data is distributed to the target functional plugin; so that the target functional plugin loads and runs the functional extension data, and provides corresponding functional services for the network request instruction.

[0122] This embodiment provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the distributed system plug-in management method provided in any embodiment of the present invention, including: Upon receiving a network request instruction, at least one target functional plugin is determined based on the checksum parameters in the network request instruction; for each target functional plugin, if the target functional plugin contains a configuration file, functional extension data is loaded based on the configuration file, and the functional extension data is distributed to the target functional plugin; so that the target functional plugin loads and runs the functional extension data, and provides corresponding functional services for the network request instruction.

[0123] The computer storage medium of this invention can be any combination of one or more computer-readable media. A computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having 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 device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0124] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0125] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF (Radio Frequency), etc., or any suitable combination thereof.

[0126] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as C, Java, Smalltalk, C++, C#, and Python, 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 (e.g., via the Internet using an Internet service provider).

[0127] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0128] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A plug-in management method for a distributed system, characterized in that, include: Upon receiving a network request instruction, at least one target functional plugin is determined based on the checksum parameters in the network request instruction. For each target function plugin, if the target function plugin contains a configuration file, load the function extension data based on the configuration file and distribute the function extension data to the target function plugin; This enables the target function plugin to load and run the function extension data, and provides corresponding function services for the network request command.

2. The method according to claim 1, characterized in that, The process of loading and running the functional extension data for the target functional plugin and providing corresponding functional services for the network request command includes: This enables the target functional plugin to load and run the functional extension data, and transmits the functional extension data to the processing workgroup within the target functional plugin; This enables the processing workgroup to load and run the extended functionality data, and to provide corresponding functional services for the network request instructions.

3. The method according to claim 1, characterized in that, The method further includes: If the network request instruction contains user personal information, the corresponding user function plugin is determined based on the user personal information, the user function plugin is loaded and started, and a plugin connection request is dispatched to the target function plugin. The plugin connection request is used to request the establishment of a communication connection between the user function plugin and the target function plugin.

4. The method according to claim 3, characterized in that, The step of determining the corresponding user function plugin based on the user's personal information, loading and starting the user function plugin includes: The user authentication result is obtained by performing user authentication based on the user's personal information; If the authentication result is successful, the service request information is determined based on the network request instruction, and the user function plugin is selected from the user's existing plugins based on the service request information. The user function plugin is loaded and started in user space, and the target function plugin is loaded and started in kernel space.

5. The method according to claim 4, characterized in that, Loading functional plugins, including: Upon receiving a function plugin loading instruction from the network requester, an initial function plugin is registered based on the function plugin loading instruction; Generate the checksum parameters corresponding to the initial functional plugin, and initialize and start the kernel-level plugin service of the initial functional plugin based on the dynamic link library; The peer information is determined based on the username, example name, and peer name in the function plugin loading instruction. The peer information is then encapsulated into a data packet, which is then sent to the network requester.

6. The method according to claim 1, characterized in that, The extended data for loading functionality based on the configuration file includes: The extended functionality data is loaded according to the connection configuration file and connection pool in the configuration file. The connection pool is used to manage business connections between clients and functional plugins, and supports the reuse of business connections.

7. The method according to claim 1, characterized in that, The method further includes: Upon receiving a plugin status adjustment instruction, the lifecycle status of the functional plugins mentioned in the functional plugin management instruction is adjusted. The lifecycle states include: registration state, deregistration state, startup state, stop state, enable state, disable state, constraint state, or update state; wherein, the constraint state is used to prohibit the startup of non-default plugins or the modification of functional plugins.

8. A distributed system plug-in management device, characterized in that, The device includes: The data acquisition module is used to determine at least one target functional plugin based on the checksum parameters in the network request instruction when a network request instruction is received. The function extension data loading module is used to load function extension data based on the configuration file for each target function plugin, and distribute the function extension data to the target function plugin if the target function plugin contains a configuration file. A function service providing module is used to enable the target function plugin to load and run the function extension data, and to provide corresponding function services for the network request command.

9. A computer device, characterized in that, The computer device includes: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the distributed system plug-in management method as described in any one of claims 1-7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the distributed system plug-in management method as described in any one of claims 1-7.

Images