A method, apparatus, equipment and medium for operating a plug-in system

Abstract

This invention provides a method, apparatus, device, and medium for operating a plug-in system. Existing plug-in systems only allow developers' plug-ins to run in a single target computing environment. The plug-in system of this invention obtains a plug-in to be deployed, which includes business logic code and descriptive information; receives a deployment instruction for the plug-in; determines the target computing environment based on the deployment instruction; performs adaptation processing on the business logic code based on the descriptive information and the target computing environment to generate an executable adapted to the target computing environment; runs the executable in the target computing environment, establishing a mapping relationship between the executable and a unique identifier; and manages the executables running in different target computing environments uniformly based on the mapping relationship, enabling efficient and secure operation in different target computing environments without modifying the plug-in code.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and in particular to a method, apparatus, device, and medium for operating a plug-in system. Background Technology

[0002] With the rapid development of large language models and artificial intelligence agent technology, plugins have become a key component for expanding the boundaries of AI capabilities. Through relevant plugins, AI systems can connect to external data, perform complex calculations, or operate real-world software systems, thereby solving more complex practical problems.

[0003] Typically, plugin developers need to write and build code for a single, pre-defined runtime environment. For example, plugins for individual users are usually designed to run in a local process and directly call the local file system; while plugins for enterprise users need to be adapted to private cloud container clusters or public cloud serverless architectures to meet the requirements of data compliance or elastic scaling.

[0004] However, if developers want their plugins to serve both individual developers running on local devices and enterprise private cloud customers with strict data security requirements, they usually need to maintain multiple sets of code logic or build scripts, which greatly increases development and maintenance costs.

[0005] Therefore, there is an urgent need for a method to run a plug-in system that enables the same plug-in to run efficiently and securely in different target computing environments such as local, private cloud, and public cloud without modifying the code. Summary of the Invention

[0006] The present invention aims to provide a method, apparatus, device and medium for operating a plug-in system.

[0007] According to a first aspect of the present invention, a method for operating a plug-in system is provided, comprising: step 301: obtaining a plug-in to be deployed, the plug-in comprising business logic code and description information; step 302: receiving a deployment instruction for the plug-in, and determining a target computing environment based on the deployment instruction; step 303: performing adaptation processing on the business logic code based on the description information and the target computing environment to generate an executable adapted to the target computing environment; step 304: running the executable in the target computing environment and establishing a mapping relationship between the executable and a unique identifier; step 305: performing unified management of the executables running in different target computing environments based on the mapping relationship.

[0008] Preferably, in step 302, based on the deployment instructions, the target computing environment is determined to be a local environment, a private cloud environment, or a public cloud environment.

[0009] Preferably, step 303 includes: step 401: in response to the deployment instruction pointing to the local environment, creating an independent working directory in the local environment and releasing the business logic code to the independent working directory; step 402: based on the running requirements in the description information, initializing a virtual running environment in the independent working directory and installing the environment-dependent components in the description information into the virtual running environment; step 403: based on the interpreter path in the virtual running environment and the entry file path of the business logic code, constructing subprocess startup parameters and obtaining the executor adapted to the local environment.

[0010] Preferably, step 401 includes: dividing a dedicated area in the file system of the physical facility carrying the local environment to obtain the independent working directory; performing decompression or copying operations on the business logic code and releasing it to the independent working directory.

[0011] Preferably, step 403 includes: traversing the virtual runtime environment and locating the interpreter path of the virtual runtime environment; scanning the business logic code and locking the entry file path of the business logic code; concatenating the interpreter path and the entry file path and adding preset startup parameters to obtain the child process startup parameters; the child process launched by the child process startup parameters is the executor.

[0012] Preferably, step S303 includes: step 501: in response to the deployment instruction pointing to the private cloud environment, the business logic code is transferred to the preprocessing component in the private cloud environment to obtain a container build description file; step 502: based on the container build description file and the business logic code, the code is reorganized according to a preset build specification to generate a build context package; step 503: based on the build context package, a container image is built, the container image is pushed to the image repository, and the executable adapted to the private cloud environment is obtained.

[0013] Preferably, step 501 includes: establishing a communication connection with the private cloud environment; transmitting a data packet containing the business logic code to the preprocessing component deployed in the private cloud environment; parsing the business logic code, identifying the programming language type and environment dependency components required by the business logic code, and obtaining an identification result; and dynamically generating a container build description file adapted to the business logic code based on the identification result.

[0014] Preferably, step 502 includes: creating a build directory based on a specific package structure specification in the private cloud environment; placing the container build description file and the business logic code in the build directory; and compressing and packaging the build directory to generate the build context package.

[0015] Preferably, step 503 includes: transmitting the build context package to the unified build module of the private cloud environment; compiling or encapsulating the business logic code into the container image based on the container build description file of the build context package; assigning a unique version identifier to the container image and generating a unique storage address for the container image within the private cloud environment by combining the network location information of the image repository; pushing the container image to the image repository for persistent storage; obtaining the storage address and using the container running instance of the container image launched at the storage address as the executor.

[0016] Preferably, step 303 includes: step 601: in response to the deployment instruction pointing to the public cloud environment, synchronizing the business logic code to a pre-set managed code repository; step 602: triggering the continuous integration module associated with the managed code repository, the continuous integration module constructing a function deployment package and deploying the function deployment package to the public cloud environment to obtain a cloud function instance; step 603: obtaining the function resource identifier of the cloud function instance and establishing the execution body based on the function resource identifier.

[0017] Preferably, step 602 includes: when the business logic code is synchronized to the managed code repository, the continuous integration module is automatically activated and the build environment is started; the business logic code and dependent libraries are loaded in the build environment and packaged into the function deployment package that conforms to the specifications of the public cloud environment; the interface of the public cloud environment is called to upload and register the function deployment package as the cloud function instance in the public cloud environment.

[0018] Preferably, step 603 includes: establishing the cloud function instance pointed to by the function resource identifier and located in the public cloud environment as the executor.

[0019] Preferably, when a user's call request for the executable corresponding to the plugin is received in gateway mode, the method further includes: step 701: receiving the call request carrying the unique identifier, and querying the type of the target computing environment and the access endpoint of the executable based on the unique identifier; step 702: sending the call request to the access endpoint based on the type of the target computing environment.

[0020] Preferably, when a user's call request for the executor corresponding to the plugin is received in interface mode, the method further includes: step 801: receiving the call request and obtaining the type of the target computing environment and the access endpoint of the executor; step 802: converting the call request into a specific protocol payload based on the type of the target computing environment; step 803: sending the specific protocol payload using the access endpoint and receiving the standardized execution result.

[0021] Preferably, step 802 includes: dynamically selecting and activating the corresponding protocol adaptation component based on the type of the target computing environment, so as to obtain the specific protocol payload that the target computing environment can recognize and process.

[0022] According to a second aspect of the present invention, a device for running a plug-in system is provided, characterized in that it comprises: a plug-in acquisition module, configured to acquire a plug-in to be deployed, the plug-in including business logic code and descriptive information; an environment decision module, configured to receive a deployment instruction for the plug-in and determine a target computing environment based on the deployment instruction; an adaptation construction module, configured to perform adaptation processing on the business logic code based on the descriptive information and the characteristics of the target computing environment, and generate an executable adapted to the target computing environment; a deployment registration module, configured to load and run the executable in the target computing environment and establish a mapping relationship between the executable and a unique identifier; and a unified management and control module, configured to perform unified management of the executables running in different target computing environments based on the mapping relationship.

[0023] Preferably, the operating device of the plug-in system further includes: a unified interface module, used to receive a call request for the plug-in in interface mode.

[0024] According to a third aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that the computer program is loaded and executed by the processor to perform the operations performed in the plug-in system operation method of the embodiments of the present application.

[0025] According to a fourth aspect of the present invention, a computer-readable storage medium is provided having a computer program stored thereon, characterized in that the computer program, when executed by a processor, implements operations performed as described in the operation method of the plug-in system in the embodiments of this application.

[0026] This invention provides a method, apparatus, device, and medium for operating a plug-in system. Existing plug-in systems only allow developers' plug-ins to run in a single target computing environment. The plug-in system of this invention obtains a plug-in to be deployed, which includes business logic code and descriptive information; receives a deployment instruction for the plug-in; determines the target computing environment based on the deployment instruction; performs adaptation processing on the business logic code based on the descriptive information and the target computing environment to generate an executable adapted to the target computing environment; runs the executable in the target computing environment, establishing a mapping relationship between the executable and a unique identifier; and manages the plug-ins running in different target computing environments uniformly based on the mapping relationship, enabling the same plug-in to run efficiently and securely in different target computing environments such as local, private cloud, and public cloud without modifying its code. Attached Figure Description

[0027] The accompanying drawings, which are included to provide a further understanding of the invention and form part of this invention, illustrate exemplary embodiments of the invention and are used to explain the invention, but do not constitute an undue limitation of the invention. In the drawings:

[0028] Figure 1 This is a schematic diagram of the implementation environment of the plug-in system operation method provided in the embodiments of this application;

[0029] Figure 2 This is a schematic diagram of the composition structure of a server according to an embodiment of this application;

[0030] Figure 3 This is a flowchart illustrating the operation method of the plug-in system provided in the embodiments of this application;

[0031] Figure 4 This is a schematic diagram of the adaptation process for the local environment provided according to the embodiments of this application;

[0032] Figure 5 This is a schematic diagram of the adaptation process for a private cloud environment provided according to an embodiment of this application;

[0033] Figure 6 This is a schematic diagram of the adaptation process for public cloud environments provided in the embodiments of this application;

[0034] Figure 7 This is a schematic diagram of the request invocation process in gateway mode according to the embodiments of this application;

[0035] Figure 8 This is a flowchart illustrating the request invocation process under the interface mode provided in the embodiments of this application;

[0036] Figure 9This is a schematic diagram of the operating device of the plug-in system provided in the embodiments of this application. Detailed Implementation

[0037] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art.

[0038] Furthermore, the described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. Numerous specific details are provided in the following description to give a thorough understanding of embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced without one or more of the specific details, or other methods, components, apparatuses, steps, etc., can be employed. In other instances, well-known methods, apparatuses, implementations, or operations are not shown or described in detail to avoid obscuring various aspects of this application.

[0039] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0040] The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be broken down, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0041] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for descriptive purposes only and is not intended to limit the scope of this application.

[0042] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0043] Before providing a further detailed description of the embodiments of this application, the nouns and terms that may be involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0044] Artificial Intelligence (AI) is the theory, methods, technology, and application systems that use digital computers or machines controlled by digital computers to simulate, extend, and expand human intelligence, perceive the environment, acquire knowledge, and use that knowledge to achieve optimal results. In other words, AI is a comprehensive technical field within computer science that attempts to understand the essence of intelligence and produce a new kind of intelligent machine that can react in a way similar to human intelligence. AI studies the design principles and implementation methods of various intelligent machines, enabling them to have perception, reasoning, and decision-making capabilities. AI technology is a comprehensive discipline involving a wide range of fields, encompassing both hardware and software technologies. Fundamental AI technologies generally include sensors, dedicated AI chips, cloud computing, distributed storage, big data processing, pre-trained model technology, operating / interactive systems, and mechatronics. Pre-trained models, also known as large models or foundational models, can be widely applied to downstream tasks in various AI fields after fine-tuning. AI software technologies mainly include computer vision, speech processing, natural language processing, and machine learning / deep learning.

[0045] Natural Language Processing (NLP) is an important field within computer science and artificial intelligence. It studies the theories and methods for enabling effective communication between humans and computers using natural language. NLP deals with natural language, the language people use in daily life, and is closely related to linguistics; it also involves computer science and mathematics. Pre-trained models, a crucial technique for model training in artificial intelligence, evolved from large language models in NLP. After fine-tuning, large language models can be widely applied to downstream tasks. NLP techniques typically include text processing, semantic understanding, machine translation, question answering, and knowledge graphs.

[0046] Python is a high-level, interpreted, general-purpose programming language developed by Guido van Rossum in late 1989, renowned for its concise readability and high flexibility. It features automatic memory management, supports multiple programming paradigms (such as object-oriented and functional programming), and is managed by the Python Software Foundation. It is primarily used in web development, data science, artificial intelligence, and other fields. Furthermore, Python 3.10, mentioned in this application, is a major upgrade to the Python programming language, released in October 2021.

[0047] GitHub is the world's largest code hosting platform and collaboration service. It allows developers to store, manage, share, and collaborate on software projects, providing features such as version control, code review, issue tracking, and project management. It is an important infrastructure for open-source communities and commercial software development.

[0048] AWS Lambda (Amazon Web Services Lambda) is a serverless computing resource provided by Amazon, meaning it is a computing service that allows you to run code directly without deploying and managing servers.

[0049] The following describes some key terms or abbreviations that may be involved in the embodiments of this application.

[0050] Plugin system: For short, "system" refers to a software framework or service platform responsible for managing and orchestrating external extensions. In this application, the aforementioned system specifically refers to a management terminal with multi-runtime adaptability, whose functions include, but are not limited to: parsing plugin standard specification files, dynamically constructing execution modules according to the target environment, and managing the lifecycle of plugin instances.

[0051] Local: refers to the computing environment of the physical machine or logical node where the main service of the above-mentioned plug-in system is deployed and runs.

[0052] Private cloud: refers to cloud computing infrastructure that is independently owned or controlled by an enterprise and deployed inside the enterprise's firewall or in a controlled network environment.

[0053] Public cloud: refers to computing resource services provided to the public by third-party cloud service providers via the Internet.

[0054] Developer: Refers to the technical personnel responsible for writing the source code of the plugin, defining standardized documentation, and declaring runtime dependencies.

[0055] Operator: refers to the administrator or organization responsible for deploying, maintaining and managing the basic services of the aforementioned plug-in system.

[0056] User: Also known as external caller, refers to the end user who uses the above-mentioned plug-in system to build applications, agents, or workflows.

[0057] The implementation environment of the plug-in system operation method provided in the embodiments of this application is described below.

[0058] The plug-in system operation method provided in this application embodiment is applied to a computer device. Exemplarily, the computer device described above is a terminal used by a developer.

[0059] For example, Figure 1 This is a schematic diagram illustrating the implementation environment of the plug-in system operation method provided in the embodiments of this application. The implementation environment includes: terminal 101 and server 102.

[0060] In this embodiment, the terminal 101 can be a client such as a smartphone, tablet, laptop, or desktop computer. The terminal 101 can be configured with the plug-in system. The developer can transmit the plug-in they developed to the server 102 through the terminal 101. The operator can deploy, maintain, and manage the plug-in provided by the developer through the plug-in system developed in the server 102. The user can use the plug-in provided by the developer through the plug-in system in the server 102 via the terminal 101.

[0061] Optionally, terminal 101 generally refers to one or more of a plurality of terminals. This application embodiment only uses one of the aforementioned terminal 101 as an example for illustration. Those skilled in the art will know that the number of the aforementioned terminal 101 can be more. For example, there may be dozens or hundreds of terminals 101, or even more. This application embodiment does not limit the number and type of terminals.

[0062] In this embodiment, the server 102 can be an independent physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, and big data and artificial intelligence platforms.

[0063] In order to implement the corresponding functions on the server 102, the memory of the server 102 needs to store the program that implements the corresponding function. To facilitate understanding of the hardware configuration of the server 102, the server 102 will be described below.

[0064] like Figure 2The diagram shown is a schematic diagram of the composition structure of the server 102 described above in this application. The server 102 in this embodiment may include: a processor 201, a memory 202, a communication interface 203, an input unit 204, a display 205, and a communication bus 206.

[0065] The processor 201, the memory 202, the communication interface 203, the input unit 204, and the display 205 all communicate with each other through the communication bus 206.

[0066] In this embodiment, the processor 201 can be a central processing unit, an application-specific integrated circuit, a digital signal processor, an off-the-shelf programmable gate array, or other programmable logic devices.

[0067] The processor 201 can call programs stored in the memory 202. Specifically, the processor 201 can perform the operations performed on the server side in the following embodiments of the plug-in system operation method.

[0068] The aforementioned memory 202 is used to store one or more programs. Each program may include program code, which includes computer operation instructions. In this embodiment, the memory 202 stores at least a program for implementing the following functions: acquiring a plugin to be deployed, the plugin including business logic code and description information; receiving deployment instructions for the plugin; determining a target computing environment based on the deployment instructions; performing adaptation processing on the business logic code based on the description information and the characteristics of the target computing environment to generate an executable adapted to the target computing environment; loading and running the executable in the target computing environment, and establishing a mapping relationship between the executable's access endpoint and a unique identifier; and managing the executable uniformly based on the mapping relationship.

[0069] Optionally, the memory 202 may include a program storage area and a data storage area. The program storage area may store the plug-in system and at least one application program required for a function or step, such as the deployment, operation, and management of the plug-in. The data storage area may store data created during computer use, such as the plug-in's code and documentation.

[0070] Optionally, the memory 202 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device or other volatile solid-state storage device.

[0071] Optionally, the communication interface 203 can be an interface of a communication module.

[0072] It should be noted that, Figure 2 The structure of server 102 shown above does not constitute a limitation on the server in the embodiments of this application. In practical applications, the server may include more than [other components]. Figure 2 More or fewer components as shown, or combinations of certain components.

[0073] like Figure 3 The diagram shown is a flowchart illustrating the operation method of the plug-in system provided in this application embodiment. The method specifically includes the following steps:

[0074] Step S301: Obtain the plugin to be deployed. The plugin contains business logic code and description information.

[0075] In step S301 above, the plugin system receives the plugin submitted by the developer. Further, this process can be implemented by uploading a compressed file, specifying a code repository address, or synchronizing from a plugin marketplace.

[0076] It should be noted that the above description defines the runtime requirements and interaction protocols for the aforementioned business logic code.

[0077] It should be noted that the aforementioned business logic code refers to the script of the original program that can implement specific business functions within the aforementioned plugin. Preferably, the aforementioned business logic code only contains code for core algorithms or business process processing logic, and does not contain any configuration code strongly related to the underlying infrastructure. For example, the aforementioned business logic code does not contain server startup code for listening to network ports, nor does it contain encapsulation of proprietary function entry points for specific cloud platforms. This design ensures code purity, enabling the aforementioned plugin to migrate between different target computing environments.

[0078] Preferably, the above-mentioned descriptive information is a collection of metadata written in declarative syntax, used to declare to the system the context constraints required for the operation of the above-mentioned business logic code, such as: environment dependencies (also known as environment dependency information, environment dependency components, environment dependency declarations), interface protocol definitions, resource permission declarations, etc.

[0079] For illustrative purposes, let's take a specific "weather query plugin" as an example: The business logic code of the plugin only contains the core code for processing the business process. This core code receives a string representing a "city name" as input, then calls a third-party meteorological service interface to obtain data and returns the real-time temperature value of the city. It's important to emphasize that the core code itself is unaware of whether it ultimately runs as a local subprocess or a serverless function in the cloud; it focuses solely on data processing. Preferably, the plugin's description includes: runtime: specifying that the plugin requires a Python 3.10 interpreter environment; environment dependencies: listing the specific third-party Hypertext Transfer Protocol libraries and their version numbers used by the plugin to send network requests; input specifications: defining the plugin's input parameter name as "city," the data type as "text string," and as a "required field"; network permissions: declaring that the plugin needs internet access to connect to the meteorological service provider's server.

[0080] Step S302: Receive deployment instructions for the above-mentioned plugins, and determine the target computing environment based on the above-mentioned deployment instructions.

[0081] In step S302 above, the plugin system provides an interactive interface for the operator or the upper-layer orchestration engine to specify the runtime strategy of the plugin; in response to the received deployment instruction, the plugin system parses the configuration parameters contained in the deployment instruction, thereby locking the target destination of the plugin, that is, determining the target computing environment of the plugin.

[0082] It should be noted that the heterogeneous target computing environment mentioned above includes computing environments that differ significantly in underlying infrastructure architecture, resource scheduling methods, and network isolation strategies; these can also be referred to as runtime environments or sets of runtime environments. In the embodiments of this application, the heterogeneous target computing environment mentioned above includes at least the following three typical computing environments:

[0083] Local environment: This refers to the plugins running directly on the physical server or virtual machine where the main service of the plugin system resides. In this local environment, the plugins typically operate as child processes or native threads managed by the kernel of the plugin system. The advantages of running plugins in this local environment include fast startup, convenient debugging, and sharing the file system with the main service. It is suitable for individual developers debugging or single-machine operation scenarios with extremely high data privacy requirements.

[0084] Private cloud environment: This refers to the above plugins running in a container cluster controlled internally by the enterprise and with restricted network access. In this private cloud environment, the plugins function as independent containers or container groups. The characteristics of running these plugins in a private cloud environment include good resource isolation, support for horizontal scaling, and strict data exclusivity, making it suitable for enterprise-level confidential production environments.

[0085] Public cloud environment: This refers to the above plugins running on infrastructure hosted by a third-party cloud service provider. In this public cloud environment, the plugins behave as event-driven cloud function instances. The characteristics of running the plugins in the above public cloud environment are pay-as-you-go pricing, extremely strong elastic scaling capabilities, and no need to maintain the underlying server, making it suitable for business scenarios with high concurrency or intermittent calls.

[0086] For example, the description continues using the "weather query plugin" in step S301 above: In this embodiment, the operator, as the manager and maintainer of the plugin system, issues a corresponding deployment instruction to the plugin system based on the current business delivery requirements or system operation and maintenance status; then, the plugin system receives and parses the configuration parameters (e.g., running mode identifier) ​​carried in the deployment instruction, thereby locking the target computing environment of the current plugin from the heterogeneous target computing environment.

[0087] Step S303: Based on the above description information and the above target computing environment, perform adaptation processing on the above business logic code to generate an executable that is adapted to the above target computing environment.

[0088] In step S303 above, the plug-in system automatically performs corresponding encapsulation and / or supplementation operations on the business logic code based on the operation requirements of the plug-in in the above description information and in combination with the underlying specifications of the target computing environment determined in step S302 above, to generate the execution body adapted to the target computing environment.

[0089] It should be noted that the above adaptation process follows the principle of non-intrusion, meaning that the plugin system adapts to the target computing environment by wrapping an environment adaptation layer outside the business logic code, injecting dependent components, or generating plug-in configurations, without modifying the business logic code itself. Through these steps, the original compressed package of the plugin is converted into an executable that can be directly loaded, scheduled, and monitored by the target computing environment.

[0090] It should be noted that the specific steps for generating the above-mentioned execution entity vary significantly depending on the different types of target computing environments. The specific construction process and adaptation details for the above-mentioned local environment, private cloud environment and public cloud environment will be described in detail in the subsequent embodiments, and will not be repeated here.

[0091] For example, continuing the explanation using the "weather query plugin" example: Assuming the business logic code of the weather query plugin is a standard script file, the plugin system converts the weather query plugin into different forms of executables based on the determined target computing environment: When the target computing environment is determined to be the local environment, after the adaptation process, the executable is generated, and the plugin system can launch an independent child process on server 102 through the executable; when the target computing environment is determined to be the private cloud environment, after the adaptation process, the executable is generated, and the executable conforms to the standard container runtime specification and is scheduled by the container orchestration engine in the private cloud environment; when the target computing environment is determined to be the public cloud environment, after the adaptation process, the executable is generated, and the executable conforms to the function computing specification of the third-party cloud service provider and can be uploaded to the hosting platform of the public cloud environment for execution.

[0092] Step S304: Run the above-mentioned execution unit in the target computing environment and establish the mapping relationship between the above-mentioned execution unit and the unique identifier.

[0093] In step S304 above, firstly, the plug-in system distributes the executable corresponding to the plug-in to the target computing environment and triggers a startup command to put it into a callable ready state; secondly, as the executable is started, the target computing environment allocates a corresponding access endpoint to the executable, which refers to network addressing information (such as Internet Protocol address, port number, or resource locator) that can locate and connect to the executable; finally, the plug-in system captures the access endpoint and binds it to the unique identifier of the plug-in in the plug-in system. This mapping relationship allows users to route to the dynamic executable without needing to consider the differences in the target computing environment, simply by using the static unique identifier.

[0094] For example, continuing the description using the "weather query plugin" example: In this embodiment, firstly, the plugin system loads the executable corresponding to the weather query plugin into the target computing environment and issues a startup command to put it into an active running state; secondly, with the successful startup of the executable, the target computing environment allocates an access endpoint capable of network addressing to the executable according to its own network architecture; finally, the plugin system captures the access endpoint and establishes a dynamic mapping relationship between the access endpoint of the executable and the unique identifier of the weather query plugin in the plugin system in the routing registry.

[0095] Step S305: Based on the above mapping relationship, perform unified management on the above execution entities running in different above target computing environments.

[0096] In step S305 above, the plug-in system constructs a unified management and control module through the above mapping relationship. The operator enables the unified management and control module to perform full lifecycle management of the execution entities distributed in different target computing environments through a standardized instruction set.

[0097] It should be noted that the aforementioned executables running in different target computing environments are uniformly managed through the aforementioned unified management module, which specifically includes two management dimensions: First, status monitoring, where the aforementioned plug-in system periodically probes the liveness status of the aforementioned executables through the aforementioned access endpoints and uniformly collects running logs and performance indicators (such as CPU utilization and memory consumption); Second, instruction scheduling, where the aforementioned plug-in system receives control instructions (such as stop, restart, expand, and destroy) from the aforementioned operators and translates the aforementioned control instructions into operation commands that the aforementioned target computing environments can recognize, thereby controlling the aforementioned executables.

[0098] For example, continuing with the "weather query plugin" example: Suppose the operator needs to perform a "restart" operation on the execution body of the weather query plugin. The operator only needs to issue a standardized "restart command" through the unified management module's interface. First, upon receiving the "restart command," the unified management module identifies the current execution body of the weather query plugin and its target computing environment by querying the mapping relationship. Second, the unified management module automatically converts the "restart command" into a specific control signal adapted to the target computing environment and issues it: If the mapping relationship points to the local environment, the unified management module directly restarts the associated local process; if the mapping relationship points to the private cloud environment, the unified management module issues a restart scheduling command to the associated container instance; if the mapping relationship points to the public cloud environment, the unified management module remotely calls the update interface of the associated cloud function instance or reloads the configuration to achieve a logical reset. In other words, regardless of changes in the target computing environment, the operator's operational logic for the unified management module remains unchanged, achieving unified and transparent management.

[0099] Figure 4 A schematic diagram of the adaptation process for a local environment provided according to an embodiment of this application is shown. When the deployment instruction includes configuration parameters pointing to the local environment, step S303 specifically includes the following sub-steps S401 to S403:

[0100] Step S401: In response to the above deployment instruction pointing to the local environment, create an independent working directory in the local environment and release the above business logic code to the above independent working directory.

[0101] In step S401 above, the plug-in system, based on the deployment instructions, determines the target computing environment as the local environment. To prevent conflicts in file naming or storage paths between the business logic code of different plug-ins, firstly, the plug-in system allocates a dedicated area in the file system of the physical facility hosting the local environment (i.e., the server 102) as the independent working directory; secondly, the plug-in system decompresses or copies the business logic code contained in the plug-in, completely releasing the business logic code to the independent working directory. Through these steps, the business logic code achieves localized storage and realizes space isolation at the file system level.

[0102] For example, continuing the explanation using the "weather query plugin" example: Assume the plugin system receives an instruction requiring the weather query plugin to run in the local environment. First, the plugin system automatically generates a folder on the hard drive of server 102 named after the plugin's unique identifier, serving as the plugin's independent working directory. Second, the plugin system decompresses or copies the plugin, releasing the business logic code into the folder. At this point, the business logic code exists independently within the folder, without interfering with the code files of other plugins.

[0103] Step S402: Based on the runtime requirements in the above description information, initialize the virtual runtime environment in the above independent working directory, and install the environment dependency components in the above description information into the above virtual runtime environment.

[0104] In step S402 above, firstly, the plugin system parses the description information and extracts the runtime requirements (e.g., a specific programming language interpreter version or basic runtime framework version); secondly, based on the extracted runtime requirements, the plugin system initializes a virtual runtime environment within the independent working directory created in step S401. This virtual runtime environment has an independent interpreter copy, library search path, and environment variable configuration, and is logically isolated from the global environment of the host operating system of the server; thirdly, the plugin system reads the environment dependency components from the description information and calls a package management tool adapted to the virtual runtime environment to obtain the corresponding dependency packages (e.g., archived compressed files) from a pre-set software source; finally, the plugin system accurately installs the obtained environment dependency components into the dedicated library directory of the virtual runtime environment. Through these steps, the plugin possesses a completely private, closed-loop runtime context, thereby avoiding dependency conflicts or version incompatibility issues caused by sharing a host environment.

[0105] For example, continuing with the "weather query plugin" example: Assume the description states that the plugin requires the "Python 3.10" runtime environment and depends on a requested library. First, the plugin system identifies the "Python 3.10" runtime requirement from the description. Second, the plugin system creates a standard "Python" virtual environment within a specific folder, generating the independent working directory within that folder. Third, the plugin system reads the environment dependency components of the requested library and uses the package management tool to connect to the software source and download the dependency packages. Fourth, the plugin system decompresses the dependency package files and releases the functional code into the dedicated library directory of the virtual runtime environment. At this point, the plugin has network request capabilities without interfering with other programs on the server using older versions of network libraries.

[0106] Step S403: Based on the interpreter path in the virtual runtime environment and the entry file path of the business logic code, construct the subprocess startup parameters and obtain the execution body adapted to the local environment.

[0107] In step S403 above, firstly, the plug-in system traverses the virtual runtime environment under the independent working directory and locates the interpreter path specific to the virtual runtime environment; secondly, the plug-in system scans the released business logic code and locks the path of the entry file of the business logic code; thirdly, the plug-in system concatenates the interpreter path and the entry file path according to the command line specifications of the operating system where the local environment is located, and adds preset startup parameters to obtain the child process startup parameters; finally, the plug-in system encapsulates this set of concatenated child process startup parameters into the startup configuration of the executable.

[0108] Furthermore, when the encapsulated startup parameters of the aforementioned subprocess are executed, the subprocess it launches in the aforementioned plug-in system is the aforementioned executable body in a running state.

[0109] For example, continuing the explanation using the "weather query plugin" example: After the plugin system has completed environment initialization, firstly, the plugin system identifies the path of the interpreter in the virtual runtime environment; secondly, the plugin system identifies the path of the entry file of the business logic code; thirdly, the plugin system combines the path of the interpreter and the path of the entry file of the business logic code, and adds preset startup parameters to generate subprocess startup parameters; finally, the subprocess startup parameters, after being encapsulated, are marked as the startup configuration of the execution body of the weather query plugin in the local environment. When the encapsulated subprocess startup parameters are executed, the subprocess launched in the plugin system is the execution body of the running weather query plugin.

[0110] Figure 5 A schematic diagram of the adaptation process for a private cloud environment according to an embodiment of this application is shown. When the deployment instruction includes configuration parameters pointing to the private cloud environment, step S303 specifically includes the following sub-steps S501 to S503:

[0111] Step S501: In response to the above deployment instruction pointing to the private cloud environment, the above business logic code is transferred to the preprocessing component in the above private cloud environment to obtain the container build description file.

[0112] In step S501 above, the plug-in system determines the target computing environment as the private cloud environment based on the deployment instructions. First, the plug-in system establishes a communication connection with the private cloud environment and transmits the data packet (such as a compressed package) containing the business logic code to the preprocessing component deployed in the private cloud environment. Second, the preprocessing component parses the received business logic code, identifies the programming language type required by the business logic code and the environment-dependent components, and obtains the identification result. Finally, the preprocessing component dynamically generates the container construction description file adapted to the business logic code based on the identification result.

[0113] For example, continuing the explanation using the "weather query plugin" example: Assuming the operator specifies that the weather query plugin be deployed to the aforementioned private cloud environment, firstly, the plugin system transmits the data packet containing the business logic code to the preprocessing component on the private cloud side; secondly, the preprocessing component decompresses and scans the data packet, parsing that the weather query plugin is a "Python" application that depends on a specific network library; finally, the preprocessing component dynamically generates the corresponding container build description file based on a preset "Python" template. The container build description file explicitly defines, in text form, the required "Python" base image version, the list of dependent libraries to be installed, and the entry command for service startup. At this point, the plugin system successfully obtains the container build description file used to build the image.

[0114] Step S502: Based on the container construction description file and the business logic code described above, reorganize them according to the preset construction specifications to generate a construction context package.

[0115] In step S502 above, firstly, the preprocessing component obtains the container build description file generated in step S501 and the business logic code obtained in step S301; secondly, the preprocessing component creates a temporary build directory according to the specific package structure specification defined in the private cloud environment, and places the container build description file and the business logic code in a specified hierarchical location under the build directory (for example, placing the container build description file in the root directory and the business logic code in a subdirectory); finally, the preprocessing component compresses and packages the build directory as a whole to generate a build context package containing complete build context information.

[0116] For example, continuing the explanation using the "weather query plugin" example: First, the preprocessing component obtains the container build description file generated in step S501 and the business logic code of the weather query plugin; second, the preprocessing component creates a temporary folder locally according to the preset standard build package specification, places the container build description file at the top level of the folder, and decompresses the running code of the weather query plugin and places it in the same level folder directory; finally, the preprocessing component recompresses the temporary folder to generate a new data package (i.e., a build context package).

[0117] Step S503: Build a container image based on the above-mentioned build context package, push the above-mentioned container image to the image repository, and obtain the above-mentioned execution body adapted to the above-mentioned private cloud environment.

[0118] In step S503 above, firstly, the preprocessing component transmits the build context package generated in step S502 to the unified build module deployed in the private cloud environment; secondly, after receiving the build context package, the unified build module extracts the container build description file from the build context package, and performs build operations layer by layer according to the instructions in the container build description file, compiling or packaging the business logic code into a standard container image; thirdly, the unified build module assigns a unique version identifier to the built container image, and combines it with the network location information of the image repository to generate a unique storage address for the container image in the private cloud environment; subsequently, the container image is pushed to the image repository for persistent storage; finally, the plugin system obtains the storage address of the container image, and uses the container runtime instance of the plugin launched through the storage address as the execution body.

[0119] For example, continuing the explanation using the "weather query plugin" described above: First, the preprocessing component transmits the build context package generated in step S502 to the unified build module within the cluster of the private cloud environment via the internal network; second, the unified build module decompresses the build context package, reads the container build description file within the build context package, and executes the build logic to package the business logic code of the weather query plugin into a complete container image; third, the unified build module assigns a unique version tag (i.e., the version identifier) ​​to the generated container image, and combines it with the domain name of the image repository within the private cloud environment to generate the complete storage address of the container image, and then uploads the container image to the image repository within the enterprise; finally, the plugin system obtains and records the storage address, and uses the storage address to launch the container runtime instance of the container image of the weather query plugin as the execution body.

[0120] Figure 6 A schematic diagram of the adaptation process for a public cloud environment according to an embodiment of this application is shown. When the deployment instruction includes configuration parameters pointing to the public cloud environment, step S303 specifically includes the following sub-steps S601 to S603:

[0121] Step S601: In response to the above deployment instruction pointing to the above public cloud environment, synchronize the above business logic code to the pre-configured managed code repository.

[0122] In step S601 above, the plugin system determines the target computing environment as the public cloud environment based on the deployment instructions. First, the plugin system determines the managed code repository and corresponding access endpoints for adapting to the public cloud environment according to the configuration parameters in the deployment instructions. Second, the plugin system encapsulates the business logic code and necessary environment configuration files (such as configuration information for defining the cloud runtime environment or build process) into a commit object that conforms to version control specifications. Finally, the plugin system performs data synchronization operations (such as push operations) to upload and update the commit object to the designated branch of the managed code repository, thus completing the cloud hosting of the business logic code.

[0123] For example, continuing with the "weather query plugin" example: First, when the plugin system recognizes that a public cloud environment is specified in the deployment instructions, it immediately locks onto a pre-configured online software source code hosting service platform (e.g., GitHub). Second, the plugin system packages the business logic code and the environment configuration file into a single commit object. Finally, the plugin system calls the version control interface to push the commit object to the main branch of the online software source code hosting service platform. At this point, the business logic code of the weather query plugin has been successfully transferred from the plugin system's local environment to the hosting repository of the online software source code hosting service platform.

[0124] Step S602: Trigger the continuous integration module associated with the above-mentioned managed code repository. The continuous integration module builds a function deployment package and deploys the function deployment package to the above-mentioned public cloud environment to obtain a cloud function instance.

[0125] In step S602 above, firstly, when the business logic code is synchronized to the managed code repository, the continuous integration module associated with the managed code repository is automatically activated and the build environment is started; secondly, the continuous integration module loads the business logic code and project dependency library in the build environment, and encapsulates the business logic code and project dependency library into the function deployment package that conforms to the specifications of the public cloud environment; finally, the continuous integration module calls the management interface of the public cloud environment to upload and register the function deployment package as the cloud function instance in the public cloud environment.

[0126] For example, continuing the explanation using the "weather query plugin" example: First, when the aforementioned commit object is pushed to the main branch of the online software source code hosting service platform repository, the built-in continuous integration module of the online software source code hosting service platform will be automatically activated; second, the continuous integration module executes a preset script, installs the aforementioned project dependency library of the weather plugin, and compresses the aforementioned business logic code together with the aforementioned project dependency library to build and generate the aforementioned function deployment package; finally, the continuous integration module uses a preset key to execute a deployment command, uploads the aforementioned function deployment package to AWS Lambda, thereby generating the aforementioned cloud function instance of the weather query plugin in the cloud.

[0127] Step S603: Obtain the function resource identifier of the above cloud function instance, and establish the above execution body based on the above function resource identifier.

[0128] In step S603 above, firstly, the plug-in system locates the cloud function instance in step S602 based on feedback information from the public cloud environment or a preset naming rule; secondly, the plug-in system obtains the unique index information (i.e., function resource identifier) ​​of the cloud function instance in the public cloud environment; finally, the plug-in system establishes the function resource identifier as the access endpoint required for the subsequent step S304, and establishes the cloud function instance in the public cloud environment pointed to by the function resource identifier as the execution body.

[0129] For example, continuing with the "weather query plugin" example: First, the plugin system locates the cloud function instance by reading the predefined function name in the environment configuration file or by actively querying the Amazon Web Services interface; second, the plugin system extracts the function resource identifier of the cloud function instance; finally, the plugin system records the function resource identifier as the access endpoint and marks the cloud function instance running in the cloud, which is pointed to by the function resource identifier, as the execution body.

[0130] Figure 7 A flowchart illustrating a call request in gateway mode according to an embodiment of this application is shown. When the plugin system receives a call request from a user for the executable corresponding to the plugin, the following steps are included after step S305:

[0131] Step S701: Receive the above-mentioned call request carrying the above-mentioned unique identifier, and query the type of the target computing environment and the access endpoint of the execution entity according to the above-mentioned unique identifier.

[0132] In step S701 above, the plug-in system acts as a unified entry gateway for business traffic. The specific processing flow is as follows: First, the plug-in system receives the call request from the client (e.g., user interface front-end, command line tool, or third-party application) and performs protocol parsing and format verification on the call request to extract the unique identifier used to specify the target plug-in; second, the plug-in system uses the unique identifier as a query condition to perform a matching search in the mapping relationship established in step S304; finally, based on the successfully matched mapping relationship, the plug-in system reads the routing configuration information recorded in the mapping relationship to determine the type of the target computing environment in which the plug-in is currently located and the specific access endpoint of the execution entity.

[0133] For example, continuing with the "weather query plugin" example: First, the user clicks the "Query" button on the front-end interface, sending a call request containing the command "Query Shanghai weather" to the plugin system. Upon receiving this request, the gateway module of the plugin system parses the protocol header and verifies the content, extracting a string to uniquely identify the plugin as its unique identifier. Second, the plugin system uses this unique identifier as an index to match and query the mapping relationship in a memory or database routing registry. Third, based on the successfully matched mapping relationship, the plugin system reads the routing configuration information associated with the weather query plugin. Based on this routing configuration information, the plugin system confirms that the weather query plugin is currently deployed in the public cloud environment and that its corresponding executable is a specific cloud function instance. Thus, the plugin system completes the precise addressing of the executable.

[0134] Step S702: Based on the type of the target computing environment, send the above-mentioned call request to the above-mentioned access endpoint.

[0135] In step S702 above, the plug-in system incorporates multiple protocol adaptation modules to shield communication differences between different underlying environments. Based on the target computing environment type queried in step S701, the plug-in system executes a dynamic distribution strategy: if the target computing environment type is the local environment, the plug-in system activates local communication adaptation logic, identifies the executable (i.e., the local subprocess generated in step S403), and serializes the call request before writing it to the access endpoint; if the target computing environment type is the private cloud environment, the plug-in system activates network communication adaptation logic, locks the executable pointed to by the mapping relationship (i.e., the container runtime instance generated in step S503), and encapsulates the call request into a network packet and sends it to the access endpoint; if the target computing environment type is the public cloud environment, the plug-in system activates cloud call adaptation logic, and for the executable (i.e., the cloud function instance generated in step S603), uses the access endpoint to initiate a remote procedure call by calling the software development kit provided by the third-party cloud vendor.

[0136] Figure 8 The diagram illustrates a flowchart of a call request under the interface mode provided in this application embodiment. When the plugin system receives a call request from a user for the execution body corresponding to the plugin, the following steps S801 to S803 are specifically included after step S305:

[0137] Step S801: Receive the above call request and obtain the type and access endpoint of the target computing environment.

[0138] In step S801, the aforementioned plug-in system utilizes its built-in unified interface module as the sole external interaction window. The specific processing flow is as follows: First, the unified interface module receives the aforementioned call request initiated by the upper-layer client. It should be emphasized that the aforementioned call request is a structured data object conforming to a predefined interface contract, which explicitly encapsulates the aforementioned unique identifier used to uniquely identify the target plug-in and the parameter payload required to execute the business logic. Second, in response to receiving the aforementioned call request, the unified interface module quickly parses and extracts the aforementioned unique identifier as key index information, and uses the aforementioned index information as an index to perform a search and match in the aforementioned mapping relationship to obtain the search and match results. Finally, based on the aforementioned search and match results, the unified interface module successfully obtains and establishes metadata containing two key dimensions: first, it clearly determines the type of the aforementioned target computing environment in which the aforementioned plug-in is currently located; second, it simultaneously obtains the access endpoint of the aforementioned execution entity corresponding to the aforementioned target computing environment.

[0139] For example, let's continue with the "weather query plugin" example: Suppose an upper-level enterprise resource planning (ERP) backend needs to initiate a weather query. First, the ERP system sends a call request to the unified interface module by invoking its internal software development kit. Second, after receiving the call request, the unified interface module extracts the unique identifier and then uses it to quickly search the routing registry in its local memory to obtain the search results. Finally, the search results clearly show that the weather query plugin is currently hosted in the public cloud environment and return the corresponding function resource identifier of the target cloud vendor as the specific access endpoint.

[0140] Step S802: Based on the target computing environment described above, convert the above call request into a specific protocol payload.

[0141] In step S802 above, the unified interface module resolves the communication protocol differences between the unified interface module and different target computing environments based on the determined type of the target computing environment. Specifically, the unified interface module dynamically selects and activates the corresponding protocol adaptation component according to the type of the target computing environment. The protocol adaptation component is responsible for receiving the input call request, extracting the business parameter payload from the call request, translating and converting it, thereby forming a specific protocol payload that can be recognized and processed by the target computing environment.

[0142] For example, following the "weather query plugin" scenario in step S801, since step S801 has clearly determined that the type of the target computing environment is the public cloud environment, in this step, the unified interface module automatically calls the built-in protocol adapter component. After receiving the call request in the previous step, the protocol adapter component quickly converts it into the format required by the internal software development kit of the target cloud vendor, thereby obtaining the specific protocol payload that is finally sent.

[0143] Step S803: Send the specific protocol payload using the access endpoint and receive the standardized execution result.

[0144] First, the unified interface module distributes the specific protocol payload to the access endpoint through the corresponding communication channel. Second, after sending the request, the unified interface module waits for and receives the raw execution result from the target computing environment, and converts the raw execution result into the standardized execution result. Finally, the unified interface module returns the standardized execution result to the upper-layer client that initially initiated the call.

[0145] For example, continuing with the "weather query plugin" scenario described above. Execution phase: The unified interface module calls the execution method (e.g., function call) of the built-in cloud vendor's internal software development kit, sending the specific protocol payload (as a parameter) generated in step S802 to the cloud function resource identifier (as the target address) obtained in step S801. After the call is completed, the unified interface module receives a cloud platform-specific raw execution result (e.g., a complex object containing execution status code, log references, and business result data). At this point, the protocol adaptation component immediately intervenes, extracts core business data from the raw execution result, and deserializes it into the standardized execution result. Finally, the unified interface module returns the standardized execution result to the upper-layer system client.

[0146] According to an embodiment of the present invention, a device for operating a plug-in system is provided. Figure 9 This is a schematic diagram of the operating device of the plug-in system provided in the embodiments of this application, such as... Figure 9As shown, the system includes: a plugin acquisition module 901, used to acquire plugins to be deployed, the plugins containing business logic code and description information; an environment decision module 902, used to receive deployment instructions for the plugins and determine the target computing environment based on the deployment instructions; an adaptation construction module 903, used to perform adaptation processing on the business logic code based on the description information and the characteristics of the target computing environment, generating an executable adapted to the target computing environment; a deployment registration module 904, used to load and run the executable in the target computing environment, and establish a mapping relationship between the executable and a unique identifier; and a unified management and control module 905, used to perform unified management of the executables running in different target computing environments based on the mapping relationship.

[0147] Furthermore, the aforementioned plug-in management system also includes: a routing and forwarding module, used to receive a call request carrying the aforementioned unique identifier, query the corresponding target computing environment type and the access endpoint of the aforementioned execution entity in the aforementioned mapping relationship based on the aforementioned unique identifier; and forward the call request to the access endpoint of the aforementioned execution entity based on the aforementioned target computing environment type.

[0148] According to embodiments of the present invention, a computer program product is provided, comprising a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the operation method of the plug-in system described in the embodiments of this application.

[0149] According to an embodiment of the present invention, an electronic device is provided, which may include a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus. The processor may invoke logical instructions in the memory to execute a method for operating the plug-in system, including: acquiring a plug-in to be deployed, the plug-in including business logic code and description information; receiving a deployment instruction for the plug-in; determining a target computing environment based on the deployment instruction; performing adaptation processing on the business logic code based on the description information and the target computing environment to generate an executable adapted to the target computing environment; running the executable in the target computing environment and establishing a mapping relationship between the executable and a unique identifier; and performing unified management of plug-ins running in different target computing environments based on the mapping relationship. Further, the electronic device may execute the method for operating the plug-in system according to the embodiments of this application.

[0150] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this invention, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, external hard drives, read-only memory, random access memory, magnetic disks, or optical disks.

[0151] According to embodiments of the present invention, a computer-readable storage medium is provided, wherein computer-executable instructions or computer programs are stored, and when the computer-executable instructions or computer programs are executed by a processor, the processor will execute the operation method of the plug-in system provided in the above embodiments of the present application.

[0152] According to embodiments of the present invention, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including being deployed as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0153] According to embodiments of the present invention, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that stores other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., files that store one or more modules, subroutines, or code sections).

[0154] According to embodiments of the present invention, computer-executable instructions may be deployed to execute on an electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed at multiple locations and interconnected via a communication network.

[0155] According to embodiments of the present invention, the term "module" or "unit" refers to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0156] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

[0157] The foregoing description of specific exemplary embodiments of the invention is for illustrative and explanatory purposes. These descriptions are not intended to limit the invention to the precise forms disclosed, and it will be apparent that many changes and variations can be made in accordance with the foregoing teachings. The exemplary embodiments were chosen and described in order to explain the specific principles of the invention and its practical application, thereby enabling those skilled in the art to implement and utilize various different exemplary embodiments of the invention, as well as various different choices and variations.

[0158] Those skilled in the art will understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in this application can be alternated, modified, combined, or deleted. Furthermore, other steps, measures, and solutions in the various operations, methods, and processes discussed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted. Furthermore, steps, measures, and solutions in the prior art that are similar to those disclosed in this application can also be alternated, modified, rearranged, decomposed, combined, or deleted.

[0159] The above description is only a partial embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for operating a plug-in system, characterized in that, include: Step 301: Obtain the plugin to be deployed, which includes business logic code and description information; Step 302: Receive deployment instructions for the plugin, and determine the target computing environment based on the deployment instructions; Step 303: Based on the description information and the target computing environment, perform adaptation processing on the business logic code to generate an executable body adapted to the target computing environment; Step 304: Run the executor in the target computing environment and establish a mapping relationship between the executor and the unique identifier; Step 305: Based on the mapping relationship, perform unified management of the execution entities running in different target computing environments.

2. The method for operating the plug-in system according to claim 1, characterized in that: In step 302, based on the deployment instructions, the target computing environment is determined to be a local environment, a private cloud environment, or a public cloud environment.

3. The method for operating the plug-in system according to claim 2, characterized in that, Step 303 includes: Step 401: In response to the deployment instruction pointing to the local environment, create a separate working directory in the local environment and release the business logic code to the separate working directory; Step 402: Based on the runtime requirements in the description information, initialize the virtual runtime environment in the independent working directory, and install the environment-dependent components in the description information into the virtual runtime environment; Step 403: Based on the interpreter path in the virtual runtime environment and the entry file path of the business logic code, construct the subprocess startup parameters and obtain the executable body adapted to the local environment.

4. The method for operating the plug-in system according to claim 3, characterized in that, Step 401 includes: A dedicated area is partitioned out in the file system of the physical facility that hosts the local environment to obtain the independent working directory; The business logic code is decompressed or copied and then released to the independent working directory.

5. The method for operating the plug-in system according to claim 3, characterized in that, Step 403 includes: Traverse the virtual runtime environment and locate the interpreter path of the virtual runtime environment; Scan the business logic code and locate the entry file path of the business logic code; The child process startup parameters are obtained by concatenating the interpreter path and the entry file path and appending preset startup parameters. The child process launched by the child process startup parameters is the executor.

6. The method for operating the plug-in system according to claim 2, characterized in that, Step S303 includes: Step 501: In response to the deployment instruction pointing to the private cloud environment, the business logic code is transferred to the preprocessing component in the private cloud environment to obtain the container build description file; Step 502: Based on the container construction description file and the business logic code, reorganize them according to the preset construction specifications to generate a construction context package; Step 503: Build a container image based on the build context package, push the container image to the image repository, and obtain the execution body adapted to the private cloud environment.

7. The method for operating the plug-in system according to claim 6, characterized in that, Step 501 includes: Establish a communication connection with the private cloud environment; The data packet containing the business logic code is transmitted to the preprocessing component deployed in the private cloud environment; The business logic code is parsed to identify the programming language type and environment dependency components required by the business logic code, and the identification results are obtained. Based on the identification results, a container construction description file adapted to the business logic code is dynamically generated.

8. The method for operating the plug-in system according to claim 6, characterized in that, Step 502 includes: Create a build directory based on the specific package structure specifications in the private cloud environment; Place the container build description file and the business logic code in the build directory; The build directory is compressed and packaged to generate the build context package.

9. The method for operating the plug-in system according to claim 6, characterized in that, Step 503 includes: The build context package is transferred to the unified build module of the private cloud environment; Based on the container build description file of the build context package, the business logic code is compiled or packaged into the container image; Assign a unique version identifier to the container image, and combine it with the network location information of the image repository to generate a unique storage address for the container image within the private cloud environment; The container image is pushed to the image repository for persistent storage; Obtain the storage address, and use the container running instance of the container image pulled up at the storage address as the execution body.

10. The method for operating the plug-in system according to claim 2, characterized in that, Step 303 includes: Step 601: In response to the deployment instruction pointing to the public cloud environment, synchronize the business logic code to the pre-configured managed code repository; Step 602: Trigger the continuous integration module associated with the managed code repository. The continuous integration module builds a function deployment package and deploys the function deployment package to the public cloud environment to obtain a cloud function instance. Step 603: Obtain the function resource identifier of the cloud function instance, and establish the execution body based on the function resource identifier.

11. The method for operating the plug-in system according to claim 10, characterized in that, Step 602 includes: When the business logic code is synchronized to the managed code repository, the continuous integration module is automatically activated and the build environment is started; The business logic code and its dependent libraries are loaded into the build environment and encapsulated into a function deployment package that conforms to the specifications of the public cloud environment. Call the interface of the public cloud environment to upload the function deployment package and register it as the cloud function instance in the public cloud environment.

12. The method for operating the plug-in system according to claim 10, characterized in that, Step 603 includes: The cloud function instance pointed to by the function resource identifier and located in the public cloud environment is identified as the executor.

13. The method for operating the plug-in system according to claim 2, characterized in that, When a user's invocation request for the executable corresponding to the plugin is received in gateway mode, the method further includes: Step 701: Receive the call request carrying the unique identifier, and query the type of the target computing environment and the access endpoint of the execution entity based on the unique identifier; Step 702: Based on the type of the target computing environment, send the call request to the access endpoint.

14. The method for operating the plug-in system according to claim 2, characterized in that, When a user's call request for the executable corresponding to the plugin is received in interface mode, the method further includes: Step 801: Receive the invocation request and obtain the type of the target computing environment and the access endpoint of the executor; Step 802: Based on the type of the target computing environment, convert the call request into a specific protocol payload; Step 803: Send the specific protocol payload using the access endpoint and receive the standardized execution result.

15. The method for operating the plug-in system according to claim 14, characterized in that, Step 802 includes: Based on the type of the target computing environment, the corresponding protocol adaptation components are dynamically selected and activated to obtain the specific protocol payload that the target computing environment can recognize and process.

16. A device for operating a plug-in system, characterized in that, include: The plugin acquisition module is used to acquire plugins to be deployed, which include business logic code and description information; An environment decision module is used to receive deployment instructions for the plugin and determine the target computing environment based on the deployment instructions. An adaptation building module is used to perform adaptation processing on the business logic code based on the description information and the characteristics of the target computing environment, and generate an executable body adapted to the target computing environment; The deployment registration module is used to load and run the executable in the target computing environment and establish a mapping relationship between the executable and a unique identifier; The unified management module is used to manage the execution entities running in different target computing environments in a unified manner based on the mapping relationship.

17. The operating device for the plug-in system according to claim 16, comprising: A unified interface module is used to receive call requests for the executor in interface mode.

18. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, include: When the processor executes the program, it implements the operation method of the plug-in system as described in any one of claims 1 to 15.

19. A computer-readable storage medium having a computer program stored thereon, characterized in that, include: When the computer program is executed by the processor, it implements the operation method of the plug-in system as described in any one of claims 1 to 15.

Images