CN114968406B - Plug-in management method and device, electronic equipment and storage medium - Google Patents

Abstract

Embodiments of the present invention disclose a plug-in management method, device, electronic equipment and storage medium. The method includes: subscribing to a target plug-in in the server according to user installation instructions; downloading and deploying the target plug-in subscribed in the server according to preset conditions; loading the target plug-in into the running environment based on a minimal system loading tool for function expansion and plug-in management. In the embodiment of the present invention, by using the subscribed acquisition plug-in, the latest version of the plug-in can be maintained in real time, improving the user experience, and loading the plug-in's operating environment according to the minimum system loading tool, which can reduce the complex configuration process of plug-in use and enhance plug-in convenience. At the same time, it makes the running environment of the plug-in independent of the system environment, ensuring a low degree of coupling, realizing dynamic expansion of system functions, preventing plug-in updates from affecting the operation of the system, and improving the stability of the system.

Description

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

Technical field

The present invention relates to the field of communication technology, and in particular, to a plug-in management method, device, electronic equipment and storage medium.

Background technique

Currently, various front-end packaging tools basically need to package various functions and components together during compilation. Even micro front-end frameworks like those of some enterprises require configuration of each sub-application (plug-in) before compilation.

If the existing browser/server model architecture applications need to expand their functions, they will have certain flaws. In the existing technology, when adding or expanding new functional pages, modifying existing functional pages, and adding new language support, it is necessary to obtain all project codes and intrusively modify the core code files in order to add or expand new functions. Page, this modification method is highly coupled and intrusive, and cannot safely and flexibly control the update function modules, making the system unable to achieve dynamic expansion functions. And after using the above method to complete the code modification, the server process needs to be replaced to achieve the purpose of adding new functions, which will inevitably cause service interruption and affect the stability of the system.

public content

In view of this, the present invention provides a plug-in management method, device, equipment and medium, which can maintain the latest version of the plug-in in real time, improve the user experience, realize dynamic expansion of system functions, and improve the stability of the system.

According to one aspect of the present invention, an embodiment of the present invention provides a plug-in management method, which method includes:

Subscribe to the target plug-in in the server according to user installation instructions;

Download and deploy the target plug-in subscribed in the server according to preset conditions;

The target plug-in is loaded into the running environment based on the minimum system loading tool for function expansion and plug-in management.

According to another aspect of the present invention, an embodiment of the present invention also provides a plug-in management method and device, which includes:

The plug-in subscription module is used to subscribe to target plug-ins in the server according to user installation instructions;

A plug-in download and deployment module, used to download and deploy the target plug-in subscribed in the server according to preset conditions;

The plug-in management module is used to load the target plug-in into the running environment based on the minimum system loading tool for function expansion and plug-in management.

According to another aspect of the present invention, an embodiment of the present invention also provides an electronic device, the electronic device includes:

at least one processor; and

a memory communicatively connected to the at least one processor; wherein,

The memory stores a computer program that can be executed by the at least one processor, and the computer program is executed by the at least one processor, so that the at least one processor can execute the method described in any embodiment of the present invention. Plug-in management methods.

According to another aspect of the present invention, embodiments of the present invention also provide a computer-readable storage medium, the computer-readable storage medium stores computer instructions, and the computer instructions are used to enable the processor to implement any of the present invention when executed. A plug-in management method according to an embodiment.

The above technical solution of the embodiment of the present invention subscribes to the target plug-in in the server through user installation instructions, downloads and deploys the subscribed target plug-in in the server according to preset conditions, and loads the target plug-in into the running environment based on the minimum system loading tool to perform functions. Extension and plug-in management. In the embodiment of the present invention, by using the subscribed acquisition plug-in, the latest version of the plug-in can be maintained in real time, improving the user experience, and loading the plug-in's operating environment according to the minimum system loading tool, which can reduce the complex configuration process of plug-in use and enhance plug-in convenience. At the same time, it makes the running environment of the plug-in independent of the system environment, ensuring a low degree of coupling, realizing dynamic expansion of system functions, preventing plug-in updates from affecting the operation of the system, and improving the stability of the system.

It should be understood that what is described in this section is not intended to identify key or important features of the embodiments of the invention, nor is it intended to limit the scope of the invention. Other features of the present invention will become easily understood from the following description.

Description of the drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments will be briefly introduced below. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, other drawings can also be obtained based on these drawings without exerting creative efforts.

Figure 1 is a flow chart of a plug-in management method provided by Embodiment 1 of the present invention;

Figure 2 is a flow chart of a plug-in management method provided in Embodiment 2 of the present invention;

Figure 3 is a schematic diagram of the overall architecture provided by Embodiment 3 of the present invention;

Figure 4 is a schematic structural diagram of the front-end plug-in provided by Embodiment 3 of the present invention;

Figure 5 is a schematic diagram of the back-end plug-in architecture provided in Embodiment 3 of the present invention.

Figure 6 is a structural block diagram of a plug-in management device provided in Embodiment 4 of the present invention;

FIG. 7 shows a schematic structural diagram of an electronic device that can be used to implement embodiments of the present invention.

Detailed ways

In order to enable those skilled in the art to better understand the solutions of the present invention, the technical solutions in the embodiments of the present invention will be clearly and completely described below in conjunction with the accompanying drawings in the embodiments of the present invention. Obviously, the described embodiments are only These are some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts should fall within the scope of protection of the present invention.

It should be noted that the terms "target" and the like in the description and claims of the present invention and the above-mentioned drawings are used to distinguish similar objects and are not necessarily used to describe a specific sequence or sequence. It is to be understood that the data so used are interchangeable under appropriate circumstances so that the embodiments of the invention described herein are capable of being practiced in sequences other than those illustrated or described herein. In addition, the terms "including" and "having" and any variations thereof are intended to cover non-exclusive inclusions, e.g., a process, method, system, product, or apparatus that encompasses a series of steps or units and need not be limited to those explicitly listed. Those steps or elements may instead include other steps or elements not expressly listed or inherent to the process, method, product or apparatus.

Embodiment 1

In one embodiment, Figure 1 is a flow chart of a plug-in management method provided in Embodiment 1 of the present invention. This embodiment can be applied to the situation when plug-ins are managed. The method can be executed by a plug-in management device. The plug-in management device can be implemented in the form of hardware and/or software, and the plug-in management device can be configured in the electronic device. As shown in Figure 1, the method includes:

S110. Subscribe to the target plug-in in the server according to the user's installation instructions.

Among them, the user installation instruction can be understood as the plug-in installation instruction clicked by the end user. A server can be understood as a terminal that provides computing or application services to end-user computers in the network, such as personal terminals or smart phones. Target plug-ins can be understood as related plug-ins that end users need to install or use.

In this embodiment, target plug-ins may include external plug-ins and built-in plug-ins. Among them, external plug-ins can be understood as related plug-ins developed by developers. Of course, the target plug-ins can be classified accordingly according to the relevant models and version numbers of the target plug-ins. For example, the target plug-ins can be back-end service plug-ins. , front-end service plug-in or static resource service plug-in, etc.

In this embodiment, the target plug-in can be subscribed to in the server according to the plug-in installation instruction clicked by the end user. Specifically, it can be detected in real time whether a user inputs a corresponding plug-in installation instruction in the plug-in market. After detecting the corresponding user installation instruction, the plug-in installation instruction can be identified according to the corresponding plug-in name, plug-in version, etc., so as to The corresponding plug-in name and plug-in version are used to call the plug-in subscription interface on the server side to subscribe to the target plug-in in the server.

S120. Download and deploy the target plug-in subscribed in the server according to preset conditions.

Among them, the preset conditions can be understood as preset conditions related to subscribing to plug-ins. For example, they can be page refresh, or conditions related to subscribing to plug-in information. They can also be server startup, or setting the same or different times. Intervals, etc. are not limited in this embodiment.

In this embodiment, the user terminal can remotely download and deploy the target plug-in subscribed in the server through the hypertext transfer protocol based on the preset conditions related to the subscription plug-in. Specifically, when the page subscription instruction and the server startup instruction are detected, the target plug-in subscribed in the server can be downloaded and deployed, and then each target plug-in can be loaded accordingly according to the preset plug-in model.

S130. Load the target plug-in into the running environment based on the minimum system loading tool for function expansion and plug-in management.

Among them, the minimum system loading tool can also be called System JS. It can be understood as being used to create plug-ins to handle alternative scene loading processes. It mainly runs in browsers and Node.JS. It is an extension of the browser loader and will apply in a local browser. The running environment can be understood as an environment in which semi-compiled running code is run on the target machine. Plug-in management can be understood as operations such as installation, uninstallation, configuration, upgrade, activation, and deactivation of target plug-ins. Among them, plug-in uninstallation is to call the back-end interface to stop the subscription and remove the plug-in from the front-end kernel after the user clicks the uninstall button.

It should be noted that plug-in management has certain functions, which can realize the underlying framework functions such as plug-in life cycle management, routing management, internationalization management, runtime context management, event bus, plug-in market, basic pages, and middle layers.

In this embodiment, after successfully downloading and deploying the target plug-in subscribed in the server, the plug-in can be loaded into the front-end running environment based on the minimal system loading tool, and the routing management, internationalization management, and runtime context management in the kernel can be used. , event bus, plug-in market, basic page and middle layer and other modules integrate the target plug-in into the kernel and run it.

The above technical solution of the embodiment of the present invention first subscribes to the target plug-in in the server according to the user's installation instructions, downloads and deploys the subscribed target plug-in in the server according to the preset conditions, and then loads the target plug-in into the running environment based on the minimum system loading tool. For function expansion and plug-in management. In the embodiment of the present invention, by using the subscribed acquisition plug-in, the latest version of the plug-in can be maintained in real time, improving the user experience, and loading the plug-in's operating environment according to the minimum system loading tool, which can reduce the complex configuration process of plug-in use and enhance plug-in convenience. At the same time, it makes the running environment of the plug-in independent of the system environment, ensuring a low degree of coupling, realizing dynamic expansion of system functions, preventing plug-in updates from affecting the operation of the system, and improving the stability of the system.

In one embodiment, the functions of plug-in management include at least one of the following: plug-in life cycle management, routing management, internationalization management, runtime context management, and event bus management.

Among them, route management can be understood as forwarding messages from the specified source endpoint to the destination endpoint according to the user-configured message route. International management can be understood as the same website can support multiple different languages to facilitate corresponding access by users from different countries and languages. Runtime context management can be understood as the management of the current running environment of the runtime. Event bus management can be understood as an implementation of the publish-subscribe model. It is a centralized event processing mechanism that allows different components to communicate with each other without relying on each other, achieving the purpose of decoupling.

In this embodiment, the functions of plug-in management may include at least one of the following: plug-in life cycle management, routing management, internationalization management, runtime context management, and event bus management. In addition, plug-in management functions can also include plug-in market management, basic page management, middle-layer management, etc. In this embodiment, through plug-in life cycle management, operations such as adding a plug-in warehouse, installing, uninstalling, configuring, upgrading, enabling, and deactivating plug-ins can be implemented in the plug-in management page of the console.

Embodiment 2

In one embodiment, Figure 2 is a flow chart of a plug-in management method provided in Embodiment 2 of the present invention. Based on the above embodiments, this embodiment subscribes to the target plug-in in the server according to the user's installation instructions, and Downloading and deploying target plug-ins subscribed in the server according to preset conditions are further refined, as shown in Figure 2. The plug-in management method in this embodiment may specifically include the following steps:

S210. Monitor user installation instructions input by users in the plug-in market.

Among them, the plug-in market includes various published plug-ins. In the plug-in market, users can download and deploy plug-ins according to their needs and embed them into corresponding development tools. The plug-in market can be a web page or APP application software. There are many types of plug-ins in the web page or APP application software. The user can install the plug-in into the system by clicking the install button on the interface. The user can click or touch Select the plug-in you want to install or use in the plug-in market.

In this embodiment, the user can select the plug-in that needs to be used in the plug-in market, and then the user terminal can generate a user installation instruction corresponding to the user's click or touch. The user terminal can monitor the generation process of the user installation instruction. When it is determined that the user is generated according to the instructions, it is determined that the user installation instructions entered by the user in the plug-in market are detected.

S220: Call the plug-in subscription interface according to the plug-in identification in the user installation instruction to subscribe to the target plug-in in the server.

Among them, the plug-in identification can be understood as the relevant identification used to identify the plug-in in the user's installation instructions. The plug-in identifier can be the name of the plug-in, the plug-in version number, the plug-in label, and other identifications used to distinguish different plug-ins. The plug-in subscription interface can be understood as the relevant program interface that interfaces with the server and is used to subscribe to the plug-in. For example, it can be an API interface. The plug-in subscription interface can include the relevant logic and rules of the plug-in subscription. The relevant logic and rules of the plug-in subscription are written in the relevant On the program interface, the program interface can realize plug-in subscription for end users.

In this embodiment, the target plug-in in the server subscribed by the user includes dependencies of the plug-in, and the target plug-in can be divided into built-in plug-ins and external plug-ins. Among them, external plug-ins can include DevOps, DMP, plug-in x, plug-in y, etc. Built-in plug-ins can include Clusters, Access, Apps, Projects, Workspaces, etc.

In this embodiment, the user installation instructions in the form of relevant pressing of the plug-in by the user are collected, for example, by right-clicking the mouse. The information of the user installation instructions includes the plug-in to be installed and related operation instructions, for example, it can be The command or the object of the command extracts the plug-in name, plug-in version number, plug-in label and other identifiers used to distinguish different plug-ins in the user installation instruction, and extracts the plug-in name, plug-in version in the user installation instruction Number, plug-in label, and other identifiers used to distinguish different plug-ins are used as parameters for calling the plug-in subscription interface. You can subscribe to the plug-in corresponding to the plug-in ID in the server according to these parameters.

In this embodiment, for plug-in developers, the system can provide a complete development framework and tool chain to help plug-in developers quickly build and publish corresponding plug-ins to the server for end users to subscribe accordingly. Specifically, the plug-in development process is as follows: First, generate a basic development directory through the KS-CLI command line tool. According to the front-end plug-in development specifications, based on KubeDesign component library, @ks-console/shared and other common component libraries, in the generated directory Develop the plug-in page and limit the development framework to react, then use any development language or component to provide the Application Programming Interface (API) that the plug-in depends on, package the plug-in's front-end and back-end services through Docker, and then use the JSBundle model with The APIService model declares the pages and APIs that the plug-in needs to register accordingly, arranges plug-in front-end services, back-end services, JSBundle models, APIService models and other resources with the help of Helm, and supplements the plug-in basic information in the Helm package metadata, and finally adds Plug-ins packaged as Helm Chart are packaged as Docker Image for distribution. The Docker Image base image file is packaged and the image contains a Helm Repository process, and the packaged plug-in is published to the server as an image file for end users to subscribe and use. When developing the environment, use Webpack to automatically discover and load plug-ins to achieve hot loading during development to achieve a better development experience.

S230. Monitor the page subscription instructions in the plug-in management page.

Among them, the page subscription instruction can be understood as an instruction to control the page to subscribe. The page subscription instruction may be a subscription instruction for a page that the user clicks by pressing a button, or may be a subscription instruction for a page that is touched. This embodiment does not limit the operation method of page subscription. The plug-in management page can be understood as a visual page of plug-ins, which can be used to manage related plug-ins downloaded by users. The plug-in management page can display the relevant plug-in information of the local plug-in in the plug-in management page accordingly. The plug-in management page may be displayed in the form of a browser page or in the form of an application software page, which is not limited in this embodiment.

It should be noted that the plug-in management page can be used to install, uninstall, configure, upgrade, enable, and deactivate plug-ins. The plug-in management page supports the classification of plug-ins. Of course, the plug-in management page can also view plug-ins in the warehouse. Information, including the version of the plug-in and the README file, basic configuration, deployment and other file information defined in the plug-in.

S240. After confirming that the page subscription instruction is received, download and deploy the target plug-in subscribed in the server.

In this embodiment, it is necessary to make corresponding judgments on the page subscription instructions, including but not limited to judging whether the related operations of the user's key clicks are received. For example, it can be a right-click operation, the operation of the user's refresh button. After determining that the page subscription is detected, In the case of instructions, obtain the directory of the local subscription target plug-in, communicate with the server accordingly according to the subscribed directory, thereby obtain the latest version of the plug-in, and download the obtained latest version of the plug-in to the local, or you can determine When the page subscription instruction is detected, the version plug-in corresponding to the local version is obtained and downloaded locally. This embodiment is not limited here.

Specifically, the process of downloading and deploying the subscription plug-in in the server may include finding the Helm Chart application template of the plug-in on the server, and using Helm and Kubernetes container management applications to manage the Helm Chart application template file, thereby converting the Helm Chart application template file from Server can be synchronized to local. It should be noted that the format of the subscribed target plug-in is saved in the image in the form of a file. There is also a corresponding plug-in warehouse in the server, and the target plug-in is stored in the form of a Kubernetes container.

S250. Store each target plug-in in the default plug-in management system according to the default plug-in model.

Among them, the preset plug-in model can be understood as a preset plug-in model. The preset plug-in models can include three types: APIService model, JSBundle model and ReverseProxy model. The APIService model is an API expansion mechanism that can declaratively register resource-based APIs to facilitate unified API permission control through the core permission control system. A plug-in can contain multiple APIService models. The JSBundle model defines the JavaScript files that need to be injected into the front-end framework. After the plug-in is enabled, APIService will proxy related static resource requests, and the front-end framework will use this API to dynamically discover and load JavaScript files. The ReverseProxy model provides a direction proxy for non-resource APIs, which can be used to proxy some static resource files. It supports Rewrite of paths, injection of request headers and other gateway functions.

In this embodiment, each target plug-in can be stored in the default plug-in management system according to the corresponding default plug-in model. Specifically, when the target plug-in is a back-end service plug-in, the target plug-in is registered to the default plug-in management system according to the APIService model; when the target plug-in is a front-end service plug-in, the target plug-in is registered to the default plug-in management system according to the JSBundle model; When the static resource serves a plug-in, the target plug-in is registered to the default plug-in management system according to the ReverseProxy model. It should be noted that after each target plug-in is stored in the default plug-in management system and added, the plug-in information in the warehouse can be viewed on the console plug-in management page, which can include the version of the plug-in, as well as the README file, basic configuration, and Deployment and other file information.

S260. Load the target plug-in into the running environment based on the minimum system loading tool for function expansion and plug-in management.

The above technical solution of the embodiment of the present invention achieves real-time maintenance of the latest plug-ins by monitoring the user installation instructions input by the user in the plug-in market and calling the plug-in subscription interface according to the plug-in identification in the user installation instructions to subscribe to the target plug-in in the server. version to further improve the user experience; by monitoring the page subscription instructions in the plug-in management page, if it is determined that the page subscription instructions are received, the target plug-ins subscribed in the server will be downloaded and deployed, and each target plug-in will be stored in the preset according to the preset plug-in model. Establishing a plug-in management system can achieve the purpose of unified standards for target plug-ins to facilitate distribution and management, so that the target plug-ins are not bound to development languages; by loading the target plug-ins into the running environment based on the minimum system loading tool for function expansion and plug-in management, it can reduce the cost The complex configuration process used by plug-ins makes the plug-in's operating environment independent of the system environment, ensuring a low degree of coupling, realizing dynamic expansion of system functions, preventing plug-in updates from affecting the operation of the system, and improving system stability.

In one embodiment, downloading and deploying target plug-ins subscribed in the server include:

Find the Helm Chart application template file of the target plug-in subscribed in the server, where the Helm Chart application template file includes the dependent components of the target plug-in;

Call the copy controller in Helm and Kubernetes container management applications to synchronize the Helm Chart application template file of the target plug-in from the server to the local default plug-in management system.

Among them, the Helm Chart application template file can be understood as making a series of files of a specific target plug-in into a single file in a certain format to facilitate users to download, deploy and use. The copy controller can also be called a plug-in copy controller. After the default plug-in warehouse is deployed, the plug-in manager will regularly pull the latest Helm Chart application template file and parse it to generate a plug-in object for subscription. The preset plug-in management system can create an image file Helm and Kubernetes container management locally based on the plug-in warehouse generated by Helm and Kubernetes container management applications, thereby using the image file Helm and Kubernetes container management as a preset plug-in management system. Of course, By default, the name of the plug-in in the plug-in management system is unique, and the plug-in exists in at least one version. The dependent component can be a common dependent component of the target plug-in, and can include dependencies such as React, kube-design, @ks-console/shared, etc.

In this embodiment, the Helm Chart application template file of the target plug-in subscribed to in the server is found to call the replica controller in the Helm and Kubernetes container management applications, thereby synchronizing the Helm Chart application template file of the target plug-in from the server to the local The default plug-in management system. Among them, the Helm Chart application template file includes the JavaScript script file of the target plug-in and the corresponding dependencies. It should be noted that the local and server configuration environments are the same. It should be noted that in this embodiment, by synchronizing the Helm Chart application template file from the server to the local preset plug-in management system, the purpose of unifying plug-in standards to facilitate distribution and management can be achieved. The target plug-in is packaged (standardized) with the help of image files, so that the target plug-in has no development language binding, is completely loosely coupled, and is non-intrusive.

In one embodiment, the default plug-in management system is implemented based on Helm and Kubernetes container management applications. The names of plug-ins in the default plug-in management system are unique and there is at least one version.

In this embodiment, the default plug-in management system is implemented based on Helm and Kubernetes container management applications. The names of plug-ins in the default plug-in management system are unique, and plug-ins can exist in multiple versions at the same time.

In one embodiment, storing each target plug-in in the default plug-in management system according to the default plug-in model includes:

Call the gateway service application program interface to authenticate and authenticate the API call request of the target plug-in;

If the target plug-in is a back-end service plug-in, register the target plug-in in the default plug-in management system according to the APIService model;

If the target plug-in is a front-end service plug-in, register the target plug-in in the default plug-in management system according to the JSBundle model;

If the target plug-in is a static resource service plug-in, register the target plug-in in the default plug-in management system according to the ReverseProxy model.

Among them, the gateway service application program interface can be understood as an expandable API gateway. The API Server provides unified API authentication capabilities and supports dynamic API expansion. The backend service plug-in can be understood as a plug-in for back-end services. For example, the back-end service plug-in can be Clusters, Access, etc. The front-end service plug-in can be understood as a plug-in for front-end services. For example, the front-end service plug-in can be DevOps, DMP, etc. Static resource service plug-ins can be understood as fixed pages for the front end, which include service plug-ins for pages that can be displayed such as HTML, CSS, JS, pictures, etc.

In this embodiment, the gateway service application program interface can be called to authenticate and authenticate the target plug-in of the front-end service. If the authentication and authentication pass, if the target plug-in is a back-end service plug-in, the target plug-in will be authenticated according to the APIService model. Register to the default plug-in management system; if the target plug-in is a front-end service plug-in, register the target plug-in to the default plug-in management system according to the JSBundle model; if the target plug-in is a static resource service plug-in, register the target plug-in to the pre-set plug-in management system according to the ReverseProxy model. Set up a plug-in management system.

Embodiment 3

In one embodiment, in order to better understand the plug-in management method, Figure 3 is a schematic diagram of the overall architecture provided in Embodiment 3 of the present invention. In this embodiment of the present invention, without changing the core framework code, dynamically add multiple Language support: Insert new function entrances into existing page navigation bars to integrate with existing systems; dynamically add new function pages and dynamically add page routing to achieve hot loading; dynamically update existing function pages to achieve hot repair ; Dynamically register new APIs. Among them, API represents the gateway service application program interface in the above embodiment, as shown in Figure 3, the details are as follows:

In this embodiment, the overall architecture mainly includes: front-end plug-in technology, back-end plug-in management technology, and plug-in development and packaging standards. The back-end plug-in mainly includes the registration of interface services, the registration of identity and access management, the loading of plug-in management, and the proxying of static resources. Plug-in 1 can include the registration of interface services, roles and related static files, and plug-in 2 can include static files. Import the executable module. In the front-end architecture, plug-in module 1 includes: routing management, internationalization management, time bus management, etc. Plug-in module 2 includes covering the existing routing management and internationalization management, etc., and then to the front-end kernel, The kernel contains basic pages, route registration, internationalization, time bus, plug-in manager, etc.

In this embodiment, the front-end plug-in technology can also be called the front-end core framework. The front-end core framework provides a plug-in management module, which is responsible for plug-in loading and plug-in management. Among them, plug-in management mainly includes: installation, uninstallation, activation, Deactivate, configure. Back-end plug-in management technology mainly provides plug-in life cycle management functions, plug-in scheduling, and provides a unified API gateway and permission control system.

In this embodiment, the pluggable software architecture of the micro-frontend is used to completely separate the core framework from the plug-in runtime, and realize functional expansion through the plug-in mechanism. Compared with common technical solutions, it has the following advantages: Under this software architecture, plug-in code and core project code are isolated from each other, and changes in plug-ins will not affect the stability of the core system, making it more stable. Under this software architecture, plug-ins can reuse the functions provided by the core framework, such as basic UI components, public methods, APIs, etc., to reduce coupling and standardize the development process. Under this software architecture, the runtime environments of plug-ins are isolated from each other, and plug-ins can be deployed independently, dynamically loaded, and enabled on demand, making them more secure and flexible. It defines plug-in development standards and provides a plug-in warehouse to facilitate plug-in distribution and management. The plug-in architecture can reduce the cost of function iteration and increase the speed of version iteration.

The following is a detailed description of the front-end plug-in technology, back-end plug-in management technology, and plug-in development and packaging standards.

In this embodiment, Figure 4 is a schematic structural diagram of the front-end plug-in provided by Embodiment 3 of the present invention, in which System JS represents the minimum system loading tool in the above embodiment, and API represents the gateway service application in the above embodiment. The interface, JSBundle model, APIService model represents the preset plug-in model in the above embodiment, and Helm Chart represents the Helm Chart image file in the above embodiment. The front-end plug-in adopts the "microkernel + plug-in" architecture, as shown in Figure 4. It should be noted that the “kernel” in Figure 4 can implement the underlying framework functions such as plug-in life cycle management, routing management, internationalization management, runtime context management, event bus, plug-in market, basic page, and middle layer. Built-in plug-ins can include Clusters, Access, Apps, Projects, etc., and external plug-ins can include DevOps, DMP, plug-in X, plug-in Y, etc. Common dependent components can include React, kube-design, @ks-console/shared, etc., and front-end engineering can include KS-CLI, scaffolding, etc.

In this embodiment, the specific process of loading the plug-in on the front end is as follows: the plug-in clicks the install button in the plug-in market, and the front end calls the plug-in subscription interface to subscribe. After refreshing the page, the front end can remotely download and deploy the plugin's JavaScript script file via HTTP. After successful download and deployment, the front-end kernel loads the plug-in into the front-end running environment through System JS and uses the routing management, internationalization management, event management and other modules in the kernel to integrate the plug-in into the kernel and run it. The plug-in is uninstalled after the user clicks the uninstall button. Call the backend interface to stop the subscription and remove the plug-in from the front-end kernel.

It should be noted that for plug-in developers, the development process provides a complete development framework and tool chain to help plug-in developers quickly build and release corresponding plug-ins. The specific plug-in development process is as follows:

a1. Generate the basic development directory through the KS-CLI command line tool.

a2. According to the front-end plug-in development specifications, the plug-in page is developed in the generated directory based on KubeDesign component library, @ks-console/shared and other common component libraries, and the development framework is restricted to react.

a3. Use any development language or component to provide the API that the plug-in depends on.

a4. Package the plug-in’s front-end and back-end services through Docker.

a5. Declare the pages and APIs that the plug-in needs to register through the JSBundle model and APIService model.

a6. Arrange plug-in front-end services, back-end services, JSBundle models, APIService models and other resources with Helm, and supplement basic plug-in information in the Helm package metadata.

a7. Package the plug-in packaged as a Helm Chart application template into a Docker Image for distribution. The Docker Image base image is provided by this technical solution. The packaged image contains a Helm Repository process.

It should be noted that for plug-in users (end users), the present invention provides complete plug-in life cycle management, and can realize the addition of plug-in warehouse, plug-in installation, uninstallation, configuration, etc. in the plug-in management page in the console. For operations such as upgrade, activation, and deactivation, the specific usage process is as follows:

b1. Create a Repository object through the console page or CLI command line tool, and declare the image of the plug-in warehouse that needs to be added.

b2. After the plug-in warehouse is added, you can view the plug-in information in the warehouse on the console plug-in management page. The plug-in management page supports the classification of plug-ins.

b3. On the plug-in list page, you can preview the basic information of the plug-in.

b4. The plug-in details page contains the plug-in version, as well as the README file, basic configuration, deployment and other file information defined in the plug-in.

b5. On the plug-in management page, you can install, uninstall, configure, upgrade, enable, and deactivate plug-ins.

b6. When the plug-in is correctly installed and enabled, you can see the plug-in function entrance on the plug-in declaration page in the system.

In this embodiment, Figure 5 is a schematic diagram of the back-end plug-in architecture provided in Embodiment 3 of the present invention. Plugin-Controller-Manager represents the copy controller in the above embodiment, and API represents the gateway service application program interface in the above embodiment. , the plug-in model represents the default plug-in model in the above embodiment, and Helm Chart represents the Helm Chart image file in the above embodiment. Specifically, back-end plug-in mainly includes API registration and static resource proxy. APIServer can be regarded as an expandable API gateway. APIServer provides unified API authentication capabilities and supports dynamic API expansion.

In this embodiment, plug-in model: plug-ins mainly include three types: APIService model, JSBundle model and ReverseProxy model. The specific definitions are as follows: First: APIService model. The APIService model is an API expansion mechanism that can be registered declaratively. Resource-based API facilitates unified API permission control through the core permission control system. A plug-in can contain multiple APIService models. The second is: JSBundle model. The JSBundle model defines the JS files that need to be injected into the front-end framework. After the plug-in is enabled, the API server will proxy related static resource requests, and the front-end framework will use this API to dynamically discover and load JS files. The third is: ReverseProxy model. The ReverseProxy model provides a direction proxy for non-resource APIs. It can be used to proxy some static resource files, supports path Rewrite, and supports gateway functions such as request header injection.

In this embodiment, plug-in life cycle management: After the default plug-in warehouse is deployed, the PluginController Manager will regularly pull the latest Helm Chart and parse it to generate a Plugin object for subscription. PluginVersion is used to save the version information of the plug-in. A plug-in with the same name can exist in multiple versions at the same time. The plug-in name is a unique value in the same warehouse. Subscription installs plug-ins through subscription, and uses Subscription to control installation and uninstallation, activation, deactivation, status synchronization, and version upgrades.

In this embodiment, the development and packaging of plug-ins includes project initialization, development of front-end pages, development of back-end APIs, packaging and publishing of plug-ins, and establishment of plug-in warehouses. Among them, a project scaffolding needs to be created through the CLI during project initialization; the development of the front-end page requires the development of the plug-in page in the scaffolding based on the KubeDesign component library, @ks-console/shared and other common component libraries. After the development is completed, the front-end plug-in is compiled and packaged through the CLI; Development of back-end API Back-end API style guide and API permission control. Packaging and publishing of plug-ins. After the plug-in development is completed, it needs to be packaged as a Helm Chart together with the dependent components. A plug-in is packaged as a Helm Chart, and a group of plug-ins is packaged as a Docker Image. The Docker Image contains a Helm Repository process, which can be released later. Plug-in warehouse, after we package the Helm Chart plug-in through Docker Image, we can deploy this warehouse to the cluster. Define the Repository object to load the plug-in template packaged into the Docker Image. After the Repository object is created, the Plugin Controller Manager will deploy the Docker Image to provide APIs related to Helm Repository (HTTP) and Plugin (Aggregated API).

Embodiment 4

In one embodiment, FIG. 6 is a structural block diagram of a plug-in management device provided in Embodiment 4 of the present invention. The device is suitable for managing plug-ins. The device can be implemented by hardware/software. It can be configured in an electronic device to implement a plug-in management method in an embodiment of the present invention. As shown in Figure 6, the device includes: a plug-in subscription module 610, a plug-in download and deployment module 620, and a plug-in management module 630.

Among them, the plug-in subscription module 610 is used to subscribe to the target plug-in in the server according to the user's installation instructions.

The plug-in download and deployment module 620 is used to download and deploy the target plug-in subscribed in the server according to preset conditions.

The plug-in management module 630 is used to load the target plug-in into the running environment based on the minimum system loading tool for function expansion and plug-in management.

In the embodiment of the present invention, through the plug-in download and deployment module, the target plug-in subscribed in the server is downloaded and deployed according to preset conditions, which can maintain the latest version of the plug-in in real time and improve the user experience; the plug-in management module is based on the minimum system The loading tool is loaded into the running environment for function expansion and plug-in management, which can reduce the complex configuration process of plug-in use and enhance plug-in convenience. At the same time, it makes the plug-in running environment independent of the system environment, ensuring low coupling and realizing system functions. Dynamic expansion prevents plug-in updates from affecting the operation of the system and improves system stability.

In one embodiment, the plug-in subscription module 610 includes:

An instruction detection unit is configured to monitor the user installation instructions input by users in the plug-in market.

A plug-in subscription unit is configured to call a plug-in subscription interface according to the plug-in identification in the user installation instruction to subscribe to the target plug-in in the server.

In one embodiment, the plug-in download and deployment module 620 includes:

The subscription instruction detection unit is used to monitor the page subscription instructions in the plug-in management page.

A plug-in download and deployment unit is configured to determine to download and deploy the target plug-in subscribed in the server upon receiving the page subscription instruction.

A plug-in storage unit is used to store each target plug-in in the default plug-in management system according to the preset plug-in model.

In one embodiment, the plug-in storage unit includes:

The plug-in authentication subunit is used to call the gateway service application program interface to authenticate and authenticate the API call request of the target plug-in.

The first registration subunit is used to register the target plug-in in the preset plug-in management system according to the APIService model if the target plug-in is a back-end service plug-in.

The second registration subunit is used to register the target plug-in in the preset plug-in management system according to the JSBundle model if the target plug-in is a front-end service plug-in.

The third registration subunit is used to register the target plug-in in the preset plug-in management system according to the ReverseProxy model if the target plug-in is a static resource service plug-in.

In one embodiment, the plug-in download deployment unit includes:

The image file search subunit is used to search for the Helm Chart application template file of the target plug-in subscribed in the server, where the Helm Chart application template file includes dependent components of the target plug-in.

The image file synchronization subunit is used to call the copy controller in the Helm and Kubernetes container management applications to synchronize the Helm Chart application template file of the target plug-in from the server to the local default plug-in management system.

In one embodiment, the preset plug-in management system is implemented based on Helm and Kubernetes container management applications. The name of the plug-in in the preset plug-in management system is unique and there is at least one version.

In one embodiment, the functions of plug-in management include at least one of the following: plug-in life cycle management, routing management, internationalization management, runtime context management, and event bus management.

The plug-in management device provided by the embodiment of the present invention can execute the plug-in management method provided by any embodiment of the present invention, and has functional modules and beneficial effects corresponding to the execution method.

In an embodiment, FIG. 7 shows a schematic structural diagram of an electronic device that can be used to implement embodiments of the present invention. Electronic device 10 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. Electronic devices may also represent various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices (eg, helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are examples only and are not intended to limit the implementation of the invention described and/or claimed herein.

As shown in Figure 7, the electronic device 10 includes at least one processor 11, and a memory communicatively connected to the at least one processor 11, such as a read-only memory (ROM) 12, a random access memory (RAM) 13, etc., wherein the memory stores There is a computer program that can be executed by at least one processor. The processor 11 can perform the operation according to the computer program stored in the read-only memory (ROM) 12 or loaded from the storage unit 18 into the random access memory (RAM) 13. Perform various appropriate actions and processing. In the RAM 13, various programs and data required for the operation of the electronic device 10 can also be stored. The processor 11, the ROM 12 and the RAM 13 are connected to each other via the bus 14. An input/output (I/O) interface 15 is also connected to bus 14 .

Multiple components in the electronic device 10 are connected to the I/O interface 15, including: an input unit 16, such as a keyboard, a mouse, etc.; an output unit 17, such as various types of displays, speakers, etc.; a storage unit 18, such as a magnetic disk, an optical disk, etc. etc.; and communication unit 19, such as network card, modem, wireless communication transceiver, etc. The communication unit 19 allows the electronic device 10 to exchange information/data with other devices through computer networks such as the Internet and/or various telecommunications networks.

Processor 11 may be a variety of general and/or special purpose processing components having processing and computing capabilities. Some examples of the processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various dedicated artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, digital signal processing processor (DSP), and any appropriate processor, controller, microcontroller, etc. The processor 11 executes various methods and processes described above, such as the plug-in management method.

In some embodiments, the plug-in management method may be implemented as a computer program, which is tangibly embodied in a computer-readable storage medium, such as the storage unit 18. In some embodiments, part or all of the computer program may be loaded and/or installed onto the electronic device 10 via the ROM 12 and/or the communication unit 19 . When the computer program is loaded into the RAM 13 and executed by the processor 11, one or more steps of the plug-in management method described above may be performed. Alternatively, in other embodiments, the processor 11 may be configured to perform the plug-in management method in any other suitable manner (eg, by means of firmware).

Various implementations of the systems and techniques described above may be implemented in digital electronic circuit systems, integrated circuit systems, field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on a chip implemented in a system (SOC), load programmable logic device (CPLD), computer hardware, firmware, software, and/or a combination thereof. These various embodiments may include implementation in one or more computer programs executable and/or interpreted on a programmable system including at least one programmable processor, the programmable processor The processor, which may be a special purpose or general purpose programmable processor, may receive data and instructions from a storage system, at least one input device, and at least one output device, and transmit data and instructions to the storage system, the at least one input device, and the at least one output device. An output device.

Computer programs for implementing the methods of the invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that the computer program, when executed by the processor, causes the functions/operations specified in the flowcharts and/or block diagrams to be implemented. A computer program may execute entirely on the machine, partly on the machine, as a stand-alone software package, partly on the machine and partly on a remote machine or entirely on the remote machine or server.

In the context of this invention, a computer-readable storage medium may be a tangible medium that may contain or store a computer program for use by or in connection with an instruction execution system, apparatus, or device. Computer-readable storage media may include, but are not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, devices or devices, or any suitable combination of the foregoing. Alternatively, the computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media would include one or more wire-based electrical connections, laptop disks, hard drives, 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 of the above.

To provide interaction with a user, the systems and techniques described herein may be implemented on an electronic device having a display device (eg, a CRT (cathode ray tube) or LCD (liquid crystal display)) for displaying information to the user monitor); and a keyboard and pointing device (e.g., a mouse or a trackball) through which a user can provide input to the electronic device. Other kinds of devices may also be used to provide interaction with the user; for example, the feedback provided to the user may be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and may be provided in any form, including Acoustic input, voice input or tactile input) to receive input from the user.

The systems and techniques described herein may be implemented in a computing system that includes back-end components (e.g., as a data server), or a computing system that includes middleware components (e.g., an application server), or a computing system that includes front-end components (e.g., A user's computer having a graphical user interface or web browser through which the user can interact with implementations of the systems and technologies described herein), or including such backend components, middleware components, or any combination of front-end components in a computing system. The components of the system may be interconnected by any form or medium of digital data communication (eg, a communications network). Examples of communication networks include: local area network (LAN), wide area network (WAN), blockchain network, and the Internet.

Computing systems may include clients and servers. Clients and servers are generally remote from each other and typically interact over a communications network. The relationship of client and server is created by computer programs running on corresponding computers and having a client-server relationship with each other. The server can be a cloud server, also known as cloud computing server or cloud host. It is a host product in the cloud computing service system to solve the problems of difficult management and weak business scalability in traditional physical hosts and VPS services. defect.

It should be understood that various forms of the process shown above may be used, with steps reordered, added or deleted. For example, each step described in the present invention can be executed in parallel, sequentially, or in different orders. As long as the desired results of the technical solution of the present invention can be achieved, there is no limitation here.

The above-mentioned specific embodiments do not constitute a limitation on the scope of the present invention. It will be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions are possible depending on design requirements and other factors. Any modifications, equivalent substitutions and improvements made within the spirit and principles of the present invention shall be included in the protection scope of the present invention.

Claims (8)

1. A plug-in management method, characterized by including: Subscribe to the target plug-in in the server according to user installation instructions; Download and deploy the target plug-in subscribed in the server according to preset conditions; Load the target plug-in into the running environment based on the minimum system loading tool for function expansion and plug-in management; Wherein, downloading and deploying the target plug-in subscribed in the server according to preset conditions includes: Monitor the page subscription instructions in the plug-in management page; Determine that upon receiving the page subscription instruction, download and deploy the target plug-in subscribed in the server; Store each target plug-in in a preset plug-in management system according to a preset plug-in model; wherein the preset plug-in model refers to a preset plug-in model; the preset plug-in management system is a container management application based on Helm and Kubernetes Generated plug-in warehouse; the preset plug-in models include three types: APIService model, JSBundle model and ReverseProxy model; Wherein, downloading and deploying the target plug-in subscribed in the server includes: Search for the Helm Chart application template file of the target plug-in subscribed in the server, where the HelmChart application template file includes the JavaScript script file of the target plug-in and the corresponding dependencies; Call the copy controller in Helm and the Kubernetes container management application to synchronize the Helm Chart application template file of the target plug-in from the server to the local default plug-in management system. 2. The method according to claim 1, characterized in that subscribing to the target plug-in in the server according to the user's installation instructions includes: Monitor said user installation instructions entered by users in the plug-in market; Call a plug-in subscription interface according to the plug-in identification in the user installation instruction to subscribe to the target plug-in in the server. 3. The method according to claim 1, characterized in that storing each target plug-in in a preset plug-in management system according to a preset plug-in model includes: Call the gateway service application program interface to authenticate and authenticate the API call request of the target plug-in; If the target plug-in is a back-end service plug-in, register the target plug-in in the preset plug-in management system according to the APIService model; If the target plug-in is a front-end service plug-in, register the target plug-in in the preset plug-in management system according to the JSBundle model; If the target plug-in is a static resource service plug-in, the target plug-in is registered in the preset plug-in management system according to the ReverseProxy model. 4. The method according to claim 1 or 3, characterized in that the preset plug-in management system is implemented based on Helm and Kubernetes container management applications, and the name of the plug-in in the preset plug-in management system is unique and there is at least one version. . 5. The method of claim 1, wherein the plug-in management functions include at least one of the following: plug-in life cycle management, routing management, internationalization management, runtime context management, and event bus management. 6. A plug-in management device, characterized in that it includes: The plug-in subscription module is used to subscribe to target plug-ins in the server according to user installation instructions; A plug-in download and deployment module, used to download and deploy the target plug-in subscribed in the server according to preset conditions; A plug-in management module, used to load the target plug-in into the running environment based on the minimum system loading tool for function expansion and plug-in management; Among them, the plug-in download and deployment module includes: The subscription instruction detection unit is used to monitor the page subscription instructions in the plug-in management page; A plug-in download and deployment unit, configured to determine to download and deploy the target plug-in subscribed in the server upon receipt of the page subscription instruction; A plug-in storage unit is used to store each target plug-in in a preset plug-in management system according to a preset plug-in model; wherein the preset plug-in model refers to a preset plug-in model; the preset plug-in management system is based on Plug-in warehouse generated by Helm and Kubernetes container management applications; the preset plug-in models include three types: APIService model, JSBundle model and ReverseProxy model; Wherein, the plug-in download deployment unit includes: The image file search subunit is used to search for the Helm Chart application template file of the target plug-in subscribed in the server, where the Helm Chart application template file includes the JavaScript script file of the target plug-in and the corresponding dependencies. ; The image file synchronization subunit is used to call the copy controller in the Helm and Kubernetes container management applications to synchronize the Helm Chart application template file of the target plug-in from the server to the local default plug-in management system. 7. An electronic device, characterized in that the electronic device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein, The memory stores a computer program executable by the at least one processor, the computer program being executed by the at least one processor, so that the at least one processor can execute any one of claims 1-5 Described plug-in management method. 8. A computer-readable storage medium, characterized in that the computer-readable storage medium stores computer instructions, and the computer instructions are used to implement the method of any one of claims 1-5 when executed by a processor. Plug-in management methods.