Plug-in secondary development system and method based on industrial internet of things platform

Abstract

The application discloses a kind of based on industrial internet of things platform's plug-in secondary development system, system uses front-end and back-end integrated plug-in architecture, including front-end plug-in layer, back-end microservice layer, unified gateway layer and plug-in management layer.Based on the centralized management construction of plug-in metadata of Nacos registration configuration center storage structure, base application is automatically registered subapplication according to metadata and synchronously driven gateway generates routing authority, reuses Nacos monitoring ability to realize front-end configuration hot update;Through state synchronizer, front and back health state two-way linkage mechanism is established, and three-layer standardized data context is simultaneously constructed to guarantee cross-end data consistency.The application also discloses a supporting development method, realizes the whole life cycle collaborative management of front and back plug-in from development, deployment, operation to uninstall, solves the defects such as traditional platform front and back plug-in management split, configuration update complicated, state out of synchronization, data inconsistency, reduces industrial internet of things custom development and operation cost.

Description

Technical Field

[0001] This invention relates to a development system and method, specifically to a plug-in-based secondary development system and method based on an industrial Internet of Things (IoT) platform, belonging to the field of industrial IoT technology. Background Technology

[0002] As the core hub of industrial digital transformation, the Industrial Internet of Things (IIoT) platform, in addition to basic device access and data collection, needs to support a large number of upper-layer business functions, including real-time monitoring dashboards, alarm rule engines, equipment linkage control, data analysis reports, energy consumption optimization calculations, and predictive maintenance diagnostics. Different industries, such as power, petrochemicals, and smart manufacturing, have significantly different needs for business functions. Therefore, the same platform faces frequent functional customization requirements in different project deliveries, which places high demands on the platform's underlying architecture's scalability, iteration efficiency, and compatibility with third-party development.

[0003] This customization requirement presents two challenges to the existing platform architecture:

[0004] From a front-end perspective: Traditional industrial IoT platforms employ a monolithic front-end architecture (such as a single Vue / React application), where all business pages and components are packaged into the same JavaScript bundle. When adding or modifying business function pages, the entire front-end project must be recompiled, and all static resources must be deployed. Furthermore, modifications made by different teams to the same front-end codebase pose a risk of conflict. More importantly, third-party developers cannot independently develop and deliver functional pages without accessing the platform's core front-end code.

[0005] From a backend perspective: Business logic is deeply coupled with the platform's core code. Adding or modifying any business function requires modifying the core code and performing a full compilation and shutdown deployment. Although microservice decomposition solutions can deploy different business modules as independent processes, each new microservice requires independent operation and maintenance (independent resource allocation, monitoring, log collection, and fault tolerance), significantly increasing the platform's operational complexity and cost.

[0006] To address the insufficient scalability of monolithic architectures, the front-end field has seen the emergence of micro-frontend architecture and module federation technologies. Module federation, a revolutionary feature introduced in Webpack 5, allows multiple independent JavaScript applications to dynamically share code and resources at runtime without recompiling the entire application. Module federation 2.0 further reduces its dependence on Webpack, supporting integration with multiple build tools (Rspack, Vite, etc.), and enabling independent deployment and dynamic loading of modules through a unified protocol specification. In the back-end field, Nacos, Alibaba's open-source microservice governance platform, provides core capabilities such as service registration and discovery, configuration management, and dynamic configuration hot updates. It has become a core component of the Spring Cloud Alibaba ecosystem, and numerous industrial IoT platforms have chosen Nacos for microservice cluster governance.

[0007] The mainstream approach in current technologies is to implement and maintain front-end micro-frontend solutions and back-end microservice solutions independently. The front-end solution uses a micro-frontend framework (such as qiankun, single-spa) or module federation to split the platform front-end into a base application and several sub-applications. Sub-applications are developed and deployed independently, with the base application dynamically loading static resources (JS / CSS) from the sub-applications at runtime. The sub-applications communicate through routing and state management mechanisms provided by the base application. In the specific implementation of module federation, remote applications expose shareable components through the `exposes` field of `ModuleFederationPlugin`, and the container application declares the source URL of remote modules through the `remotes` field, loading them dynamically at runtime.

[0008] The backend solution adopts a Spring Cloud microservice architecture, breaking down business functions into multiple independent microservices, with Nacos serving as the registry and configuration center. Each microservice registers its instance information (IP, port, metadata) with Nacos upon startup, and services communicate with each other via OpenFeign or RestTemplate in conjunction with Nacos service discovery. For configuration management, the Nacos registry configuration center supports runtime hot updates of configurations using @RefreshScope and @ConfigurationProperties. Many existing IoT platforms have adopted this architecture to decouple business logic, separating protocol parsing, device management, and rule engines into independent microservices.

[0009] While the aforementioned independent front-end and back-end implementation solutions address some issues related to front-end modularization and back-end service-oriented architecture, they still suffer from the following technical drawbacks as a complete platform plug-in solution:

[0010] (1) Lack of unified lifecycle management for front-end and back-end plugins. Front-end module federated plugins and back-end Nacos microservices are deployed and managed independently, and the loading status of front-end plugins cannot be linked with the health status of back-end service instances. For example, there is a lack of synchronized construction for linking the states of front-end and back-end plugins; when a back-end service is removed by Nacos due to a failure, the corresponding UI entry point on the front end may still be visible to the user, leading to operation failure. The asynchrony between front-end and back-end states seriously affects the availability of the plugin-based solution.

[0011] (2) Weak configuration management capabilities for front-end plugins. In existing module federation solutions, the parameter configurations of remote modules (such as API base address, function switches, UI style variables, etc.) are usually hard-coded in the remote module code or passed through URL parameters, lacking unified configuration center support. When plugin parameters need to be adjusted, the plugin code still needs to be modified and redeployed. Furthermore, the back-end configuration management capabilities of Nacos's registration configuration center have not been effectively extended to the front-end plugin domain.

[0012] (3) Backend microservice splitting leads to increased complexity in the frontend call chain. When a frontend page needs to aggregate data from multiple business microservices, the frontend needs to make multiple HTTP requests or introduce a BFF (Backend for Frontend) layer for aggregation. Multiple requests increase the complexity of frontend logic and page loading latency, while the BFF layer introduces additional development and maintenance burdens.

[0013] (4) Module federation plugins lack unified control over server-side routing and permissions. When the front-end loads remote plugins in a module federation manner, the back-end API routing permissions corresponding to the plugins are usually managed by each microservice, lacking a unified routing registration and authentication mechanism at the API gateway level. Plugins need to manually configure routing rules and permission policies on the gateway, increasing the complexity of deployment.

[0014] (5) Lack of standardized mechanism for cross-plugin front-end and back-end data sharing. Different business plugins need to share data (such as user session information, device list cache, business context, etc.). In the existing solution, the front end shares data through global state management (such as Vuex / Pinia), and the back end shares data through Redis or distributed cache. There is no unified data context passing standard between the two, which leads to frequent data consistency problems between the front end and the back end.

[0015] In summary, the existing technology of separately deployed micro-frontends and Nacos microservice combination solutions cannot achieve integrated collaborative governance of front-end and back-end plugins. It has a series of practical problems such as asynchronous states, high configuration update costs, large amount of manual operation for gateway configuration, and non-standard data sharing. It is difficult to meet the business needs of industrial IoT platforms for large-scale, multi-industry plugin rapid secondary development and lightweight operation and maintenance. Summary of the Invention

[0016] The purpose of this invention is to provide a plug-in-based secondary development system and method based on an industrial Internet of Things (IoT) platform. It aims to establish a unified plug-in metadata management mechanism and a front-end and back-end status linkage protocol, forming a plug-in-based secondary development system covering the entire front-end and back-end chain, and realizing independent development, dynamic loading, hot-swapping, and unified governance of front-end and back-end functional modules.

[0017] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0018] A plug-in secondary development system based on an industrial Internet of Things platform adopts a front-end and back-end integrated plug-in architecture, including the following layers: front-end plug-in layer, back-end microservice layer, unified gateway layer and plug-in governance layer.

[0019] The front-end plugin layer includes a base application and several independent sub-applications. Each sub-application is built and deployed independently, and the base application dynamically loads the corresponding sub-application.

[0020] The backend microservice layer is configured with a registration configuration center. Each business function plugin corresponds to at least one backend microservice. After the backend microservice starts, it automatically registers the service instance with the registration configuration center.

[0021] The unified gateway layer serves as the unified entry point for frontend requests, integrates the service discovery capabilities of the registration configuration center, and dynamically senses changes in backend service instances to achieve routing, authentication, and access control.

[0022] The plugin governance layer interacts with the front-end plugin layer, the back-end microservice layer, and the unified gateway layer, and includes a plugin metadata center, a front-end and back-end state synchronizer, a front-end configuration proxy, and a unified data context manager.

[0023] Preferably, the aforementioned front-end plugin layer is built on the qiankun micro-front-end framework; the base application adopts the Vite+Vue3 technology stack, completes the registration of sub-applications through the registerMicroApps interface provided by qiankun, and matches and dynamically loads the corresponding sub-applications according to the preset activeRule routing rules; the back-end microservice layer is built on the Spring Cloud microservice architecture, using Nacos as the registration configuration center; the unified gateway layer is built on Spring Cloud Gateway, which greatly reduces the threshold for platform ecosystem expansion.

[0024] Preferably, when the aforementioned base application registers the qiankun sub-application, it notifies the API gateway of the plugin information (plugin identifier, plugin resources, plugin routes, etc.) in the plugin metadata through the internal API. The gateway automatically generates routing forwarding rules and authentication policies. Relying on the plugin metadata to automatically drive the gateway to generate routes and permission policies, the front-end UI sub-application registration and back-end API gateway configuration are completed synchronously without manual intervention, shortening the plugin online delivery cycle, eliminating the risk of online failure caused by manual configuration, and improving the stability of platform delivery.

[0025] Preferably, the aforementioned Nacos registration and configuration center provides service registration discovery, configuration change monitoring, and service health status event push capabilities, and establishes a unified plugin metadata storage structure. When each business plugin is deployed, its metadata information is written to the Nacos registration and configuration center in YAML format.

[0026] Preferably, when the aforementioned base application starts, it pulls all plugin metadata in the active state from the Nacos registration configuration center; the base application dynamically registers sub-applications through qiankun's registerMicroApps based on the plugin routing information in the metadata; during the registration process, the base application merges the frontend.configSchema in the plugin information (menu routing, authentication authorization, global parameters) metadata with the actual plugin configuration values ​​stored in Nacos, and injects it into the sub-application through qiankun's props mechanism, so that the sub-application can obtain runtime parameters without hard-coding configuration.

[0027] More preferably, when the plugin configuration changes in the Nacos registry configuration center, the base application detects the change in real time through the Nacos configuration listening mechanism (addListener) and passes the new configuration to the loaded remote component through reactive state management (Vuex / Pinia or React Redux), thereby realizing hot update of the front-end plugin configuration without refreshing the page.

[0028] More preferably, the aforementioned front-end and back-end state synchronizer subscribes to Nacos service health change events and the base application sub-application loading / unloading events to achieve bidirectional linkage and synchronization between the health status of the back-end microservices and the display status of the front-end sub-applications.

[0029] More preferably, the bidirectional synchronization logic of the aforementioned front-end and back-end state synchronizers is specifically as follows:

[0030] Backend to frontend synchronization: When a backend microservice instance is removed from the list of healthy instances by Nacos due to a failure, Nacos's subscribe mechanism pushes a service change event. The gateway layer and the base application subscribe to this event simultaneously. The base application updates the health status identifier of the plugin according to the event and blocks the corresponding function entry or displays a service unavailable prompt in the UI of the qiankun sub-application to prevent users from initiating invalid operations.

[0031] Front-end to back-end synchronization: When the base application successfully loads or uninstalls a Qiankun sub-application, it notifies the back-end plugin management service via an internal API to update the corresponding plugin's metadata status field in Nacos. The back-end microservice then performs relevant operations based on this status, such as starting or stopping scheduled tasks or releasing business cache resources. This two-way synchronization loop ensures that the running status of front-end and back-end plugins remains consistent, significantly improving the overall stability of the platform.

[0032] More preferably, the aforementioned unified data context manager constructs a three-layer standardized data context to achieve data interoperability between the front-end global state and the back-end distributed cache and thread-local storage; the three-layer standardized data context includes a request-level context, a session-level context, and a plugin-level context. By designing a three-layer standardized context specification, the data transmission format across plugins and between front-end and back-end is uniformly constrained, ensuring data consistency across the entire chain of the same user operation, reducing data anomaly issues in industrial data analysis and equipment linkage scenarios, and lowering the difficulty of troubleshooting business faults.

[0033] Furthermore, this invention also discloses a plug-in-based secondary development method for the aforementioned system, comprising the following steps:

[0034] S1, Plugin Development and Building Phase: Developers independently develop front-end sub-applications and back-end microservices, and write the plugin's metadata YAML file. The front-end sub-application and back-end microservice of the plugin are built separately and then mixed and compiled into a Docker image.

[0035] S2, Plugin Deployment and Registration Phase: Start the backend microservice and register the service instance with Nacos; Operations personnel publish the plugin metadata YAML file to the Nacos registration configuration center and deploy the static resources of the frontend sub-application to the CDN or web server;

[0036] S3, Base Application Loading Stage: After the base application starts, it reads all plugin metadata that are active from Nacos; based on the metadata front-end parameters, it calls qiankun's registerMicroApps to register sub-applications in batches, calls qiankun's start() to start the micro-front-end framework, and injects the metadata configuration into the sub-applications; the base application synchronously pushes the back-end configuration to the API gateway, and the gateway automatically generates routes and permission rules.

[0037] S4, User Access and Data Flow Stage: When the browser URL matches the sub-application's activeRule, qiankun dynamically loads the sub-application and executes the mount lifecycle to render the UI; the sub-application UI initiates an API request, which is forwarded to the corresponding backend microservice via the unified gateway; the front-end and back-end complete business data interaction.

[0038] S5. Plugin Update and Uninstallation Phase: When a plugin is updated, the version field of the metadata in Nacos is modified and the frontend.entry address is updated. The base application listens for and detects the metadata change through the Nacos configuration. When a plugin is uninstalled, the status of the Nacos metadata is changed to inactive, the corresponding sub-application is deregistered on the base, and the corresponding routing rules are deleted synchronously on the gateway.

[0039] As can be seen, this method covers the standardized process of the entire lifecycle of plugins, including development, deployment, loading, access, operation, update, and uninstallation. The entire process relies on Nacos for unified management and control, eliminating the need for manual multi-node configuration operations. The plugin launch, update, and uninstallation are fully automated, greatly reducing the threshold for customized secondary development of industrial IoT platforms. It supports the rapid access of various industry plugins such as device monitoring, energy consumption analysis, and predictive maintenance, and is suitable for batch delivery needs of multiple projects and industries.

[0040] This invention organically integrates the Qiankun-based micro-frontend architecture with the Nacos microservice governance framework to construct a plug-in-based secondary development system covering the entire front-end and back-end chain. It also proposes a method for a plug-in-based secondary development system based on this industrial IoT platform, which has the following beneficial effects:

[0041] (1) This invention solves the problem of cumbersome front-end and back-end installation and deployment through an integrated plugin approach. Based on Nacos, a unified governance system for integrated front-end and back-end plugins is built, enabling hot configuration updates and automatic gateway route generation. This significantly reduces the cost of plugin deployment and maintenance, eliminates manual configuration operations across multiple nodes, and establishes a unified configuration plane between the front-end and back-end, avoiding the shortcomings of existing solutions such as hard-coded front-end parameters and error-prone manual gateway configuration. For installation and deployment, the plugin can directly compile the front-end and back-end into a Docker image. During installation, the front-end and back-end can be installed, deployed, and uninstalled with a single click using docker-compose orchestration, completely eliminating the traditional method of manually uploading to a specified location for deployment and operation. This truly realizes the practical application of plugins from concept to reality.

[0042] (2) This invention establishes a Nacos-driven bidirectional state linkage mechanism for front-end and back-end plugins, fundamentally solving the problem of asynchronous front-end and back-end states and enhancing the platform's operational stability by increasing bidirectional awareness between the front-end and back-end. At the front-end level, the base application dynamically loads and obtains the plugin's routing access permission at runtime through qiankun, and the plugin's front-end sub-applications receive configuration information through props, allowing for configuration adjustments without code modification. At the back-end level, each plugin microservice implements service registration, discovery, and dynamic configuration management through Nacos. In terms of front-end and back-end collaboration, unified plugin metadata management ensures synchronized loading and state linkage between qiankun sub-applications and back-end modules, while automatic gateway route registration enables the front-end UI entry point and back-end API to take effect simultaneously in the same plugin deployment process.

[0043] (3) By subscribing to Nacos service health events, the front end automatically blocks the corresponding plugin entry when the backend microservice fails and goes offline, thus avoiding invalid interface requests; the front end updates the Nacos plugin status synchronously after the plugin is loaded / unloaded, and the backend can release resources and shut down scheduled tasks as needed, thus avoiding problems such as backend service failure and continuous resource occupation, and can effectively reduce online business anomalies.

[0044] (4) The present invention designs a three-layer standardized unified data context, establishes a three-layer standardized data context of request, session and plugin, and is equipped with a plugin lossless hot update and uninstallation scheme to adapt to the parallel scenario of multiple plugins in industrial IoT, and ensures the consistency of front-end and back-end data in the same user operation link.

[0045] (5) The diversity of the design of this invention achieves a qualitative leap, and there is no longer a single development language limitation for secondary development plugins. It supports the mainstream front-end technology stack and various back-end development languages. Developers only need to follow the standards of secondary development plugins to complete the development and then install and use it.

[0046] In summary, compared with the existing technical solutions that implement the Qiankun micro-frontend and backend microservices independently, this invention realizes the collaborative management of the entire lifecycle of frontend and backend plugins from development, deployment, operation to uninstallation, which significantly reduces the technical threshold and operation and maintenance costs of expanding the business functions of the industrial IoT platform, and enables third-party developers to contribute expansion capabilities to the platform in a standardized manner. Attached Figure Description

[0047] Figure 1 This is a system architecture diagram of Embodiment 1 of the present invention;

[0048] Figure 2 This is a timing diagram of the system front-end and back-end state linkage in Embodiment 1 of the present invention;

[0049] Figure 3 This is a flowchart of the plugin registration process in the method of Embodiment 2 of the present invention. Detailed Implementation

[0050] The present invention will now be described in detail with reference to the accompanying drawings and specific embodiments.

[0051] Example 1

[0052] like Figure 1 As shown, the plug-in secondary development system based on the industrial IoT platform in this embodiment adopts a front-end and back-end integrated plug-in architecture, including the following layers: front-end plug-in layer, back-end microservice layer, unified gateway layer, and plug-in governance layer.

[0053] The front-end plugin layer can be built on the qiankun micro-frontend framework, or it can use the single-spa native solution as an alternative, or it can use the Wujie micro-frontend framework as an alternative. This embodiment comprehensively considers factors such as cost and application, and chooses qiankun as the micro-frontend, including a base application and several independent sub-applications. Each sub-application is built and deployed independently. The base application uses the Vite+Vue3 technology stack, completes the registration of sub-applications through the registerMicroApps interface provided by qiankun, and dynamically loads the corresponding sub-applications according to the preset activeRule routing rules.

[0054] When registering the qiankun sub-application in the base application, the backend information from the plugin metadata is notified to the API gateway via an internal API. The gateway automatically creates routing rules based on the serviceName and basePath in the metadata: requests starting with / api / alert / ** are routed to the alert-service instance registered in Nacos. Simultaneously, the gateway reads the apiList.permission field from the metadata, associates the API path with the required permissions, and automatically completes the permission configuration. This mechanism ensures that the front-end UI entry point of the qiankun sub-application and the back-end API routing are synchronized—when the sub-application registration is complete, the back-end API routing is already ready at the gateway layer, avoiding the problem of asynchronous front-end and back-end states.

[0055] The backend microservice layer is built on the Spring Cloud microservice architecture and can use Nacos, Consul or Eureka as the registration configuration center. Given that Nacos has more complete configuration management capabilities, Nacos is selected as the backend service governance in this embodiment. Each business function plugin corresponds to at least one backend microservice. After the backend microservice starts, it automatically registers the service instance with the registration configuration center.

[0056] The Nacos Registration and Configuration Center provides services such as registration and discovery, configuration change monitoring, and service health status event push. It also establishes a unified plugin metadata storage structure. When each business plugin is deployed, its metadata information is written to the Nacos Registration and Configuration Center in YAML format to ensure data format consistency.

[0057] The unified gateway layer is built on Spring Cloud Gateway. As the unified entry point for frontend requests, it integrates the service discovery capabilities of the registration configuration center and dynamically detects changes in backend service instances to achieve routing, authentication, and access control.

[0058] The plugin governance layer interacts with the front-end plugin layer, the back-end microservice layer, and the unified gateway layer, including the plugin metadata center, the front-end and back-end state synchronizer, the front-end configuration proxy, and the unified data context manager.

[0059] Specifically, the front-end and back-end state synchronizers subscribe to Nacos service health change events and base application sub-application loading / unloading events to achieve bidirectional linkage and synchronization between the health status of back-end microservices and the display status of front-end sub-applications. For details on the linkage sequence process, please refer to [link / details]. Figure 2 Its bidirectional synchronization logic is as follows:

[0060] Backend to frontend synchronization: When a backend microservice instance is removed from the list of healthy instances by Nacos due to a failure, Nacos's subscribe mechanism pushes a service change event. The gateway layer and the base application subscribe to this event simultaneously. The base application updates the health status identifier of the plugin according to the event and blocks the corresponding function entry or displays a service unavailable prompt in the UI of the qiankun sub-application to prevent users from initiating invalid operations.

[0061] Front-end to back-end synchronization: When the base application successfully loads or uninstalls a Qiankun sub-application, it notifies the back-end plugin management service via an internal API to update the corresponding plugin's metadata status field in Nacos. The back-end microservice then performs relevant operations based on this status, such as starting or stopping scheduled tasks or releasing business cache resources. This two-way synchronization loop ensures that the running status of front-end and back-end plugins remains consistent, significantly improving the overall stability of the platform.

[0062] It should be noted that the unified data context manager of the present invention constructs a three-layer standardized data context to realize data communication between the front-end global state and the back-end distributed cache and thread-local storage; as shown in Table 1, the three-layer standardized data context includes request-level context, session-level context and plugin-level context.

[0063]

[0064] Table 1

[0065] Through this three-layer standardized context specification, the data transmission format across plugins and front-end and back-end can be uniformly constrained, ensuring data consistency across the entire chain of the same user operation, reducing data anomaly issues in industrial data analysis and equipment linkage scenarios, and lowering the difficulty of troubleshooting business faults.

[0066] Furthermore, it should be noted that when implementing dynamic loading and configuration injection of qiankun sub-applications, the system retrieves metadata of all active plugins from the Nacos registration configuration center when the base application starts. The base application dynamically registers the sub-applications using qiankun's registerMicroApps based on the frontend field in the metadata. During the registration process, the base application merges the plugin information (menu routing, authentication authorization, global parameters, etc.) in the metadata with the actual plugin configuration values ​​stored in Nacos and injects them into the sub-applications through qiankun's props mechanism, allowing the sub-applications to obtain runtime parameters without hard-coding configuration.

[0067] When the plugin configuration changes in the Nacos registry configuration center, the base application detects the change in real time through the Nacos configuration listening mechanism (addListener) and passes the new configuration to the loaded remote components through reactive state management (Vuex / Pinia or React Redux), realizing hot updates of the front-end plugin configuration without refreshing the page.

[0068] Example 2

[0069] This invention discloses a development method for the system applied to the aforementioned Embodiment 1, specifically including the following steps:

[0070] S1. Plugin Development and Building Phase: Developers independently develop front-end sub-applications and back-end microservices, and write the plugin's metadata YAML file. The plugin's front-end sub-application and back-end microservice are built separately and then compiled together into a Docker image.

[0071] Specifically, in this embodiment, the following sub-steps are included:

[0072] Step S101: The development team independently develops front-end sub-applications (technology stack not limited, such as Vue3+Vite, React+Vite, etc.) and back-end microservices (Spring Boot) according to functional division. Sub-applications built on Vite need to install the vite-plugin-qiankun plugin, configure the qiankun plugin in vite.config.js, and export the bootstrap, mount, and unmount lifecycle hooks. Back-end microservices import the spring-cloud-starter-alibaba-nacos-discovery dependency and enable service registration via @EnableDiscoveryClient.

[0073] Step S102: Developers write the plugin's metadata YAML file, describing the access addresses of the front-end and back-end modules, qiankun registration parameters, API routes, and permission information.

[0074] Step S103: Build the plugin front-end sub-application and back-end microservice separately and then compile them into a Docker image.

[0075] S2, Plugin Deployment and Registration Phase: Start the backend microservice and register the service instance with Nacos; the operations and maintenance personnel publish the plugin metadata YAML file to the Nacos registration configuration center and deploy the static resources of the frontend sub-application to the CDN or web server.

[0076] Specifically, in this embodiment, the following sub-steps are included:

[0077] Step S201: The operations and maintenance personnel deploy and start the backend microservice. When the service starts, it automatically registers the instance with Nacos.

[0078] Step S202: The operations and maintenance personnel publish the plugin's metadata YAML file to the Nacos Registry Configuration Center (via the Nacos console or API).

[0079] Step S203: The operations and maintenance personnel deploy the static resources of the front-end sub-application to the designated CDN or Web server.

[0080] S3, Base Application Loading Stage: After the base application starts, it reads all plugin metadata that are active from Nacos; based on the metadata front-end parameters, it calls qiankun's registerMicroApps to register sub-applications in batches, calls qiankun's start() to start the micro-frontend framework, and injects the metadata configuration into the sub-applications; the base application synchronously pushes the backend configuration to the API gateway, and the gateway automatically generates routes and permission rules.

[0081] Specifically, in this embodiment, see Figure 3 This includes the following sub-steps:

[0082] Step S301: When the base application (Vue3+Vite) starts, it reads the list of metadata for all plugins with an active status from the Nacos registry configuration center.

[0083] Step S302: The base application registers all sub-applications through qiankun's registerMicroApps based on the plugin routing information in the metadata, and configures the name, entry, container, activeRule, and props.

[0084] Step S303: The base application calls qiankun's start() to start the micro-frontend framework. When the browser URL matches the activeRule of a sub-application, qiankun automatically loads the entry resource of that sub-application.

[0085] Step S304: The base application injects the configuration parameters in the metadata into the sub-application via props, enabling the sub-application to obtain the runtime parameters.

[0086] Step S305: The base application notifies the gateway layer to register the backend API routes and permission rules corresponding to the plugin.

[0087] S4. User Access and Data Flow Stage: When the browser URL matches the sub-application's activeRule, qiankun dynamically loads the sub-application and executes the mount lifecycle to render the UI; the sub-application UI initiates an API request, which is forwarded to the corresponding backend microservice via the unified gateway; the front-end and back-end complete business data interaction.

[0088] Specifically, in this embodiment, the following sub-steps are included:

[0089] Step S401: When a user accesses a sub-application page (URL matches activeRule), qiankun dynamically loads the corresponding sub-application resources and calls the mount lifecycle to render the UI.

[0090] Step S402: The sub-application UI initiates an API request to the gateway (e.g., / api / alert / rules). The gateway forwards the request to the corresponding backend service instance in Nacos according to the automatically registered routing rules.

[0091] Step S403: The backend service processes the request, discovers other dependent services through the Nacos service, and returns the result to the frontend.

[0092] Step S404: The front-end application reads and writes the shared data context through props injected by the base application or qiankun's initGlobalState.

[0093] S5. Plugin Update and Uninstallation Phase: When a plugin is updated, the version field of the metadata in Nacos is modified and the frontend.entry address is updated. The base application listens for and detects the metadata change through the Nacos configuration. When a plugin is uninstalled, the status of the Nacos metadata is changed to inactive, the corresponding sub-application is deregistered on the base, and the corresponding routing rules are deleted synchronously on the gateway.

[0094] Specifically, in this embodiment, the following sub-steps are included:

[0095] Step S501 (Updated): The developer updates the sub-application code and rebuilds and redeploys, modifying the version field of the plugin metadata in Nacos and updating the frontend.entry address. The base application listens for metadata changes through Nacos configuration, and qiankun loads the new version of the sub-application resources during the next route matching. The old version of the sub-application is automatically uninstalled after switching routes.

[0096] Step S502 (Uninstall): The operations and maintenance personnel change the status field of the plugin metadata in Nacos to inactive. After the base application is aware of the change, the corresponding sub-application registration information is removed from qiankun's registerMicroApps, and the routing matching rule is canceled; at the same time, the gateway is notified to remove the corresponding API routing rule.

[0097] As can be seen, this method covers the standardized process of the entire lifecycle of plugins, including development, deployment, loading, access, operation, update, and uninstallation. The entire process relies on Nacos for unified management and control, eliminating the need for manual multi-node configuration operations. The plugin launch, update, and uninstallation are fully automated, greatly reducing the threshold for customized secondary development of industrial IoT platforms. It supports the rapid access of various industry plugins such as device monitoring, energy consumption analysis, and predictive maintenance, and is suitable for batch delivery needs of multiple projects and industries.

[0098] In summary, this invention solves the problem of cumbersome front-end and back-end installation and deployment through an integrated plug-in approach; it provides dynamic configuration support for front-end plug-ins using the Nacos registration and configuration center; it achieves unified access and access control for plug-in back-end services through automatic routing registration at the API gateway level; and it further achieves consistent data sharing between plug-ins and the front-end and back-end through standardized data context design. This forms a plug-in-based secondary development system and methodology covering the entire front-end and back-end chain, which can be widely applied to the following industrial IoT business scenarios: real-time equipment monitoring and alarm management plug-ins, energy consumption analysis and optimization plug-ins, predictive maintenance and diagnostic plug-ins, production process OEE calculation plug-ins, environmental monitoring exceeding standard early warning plug-ins, equipment linkage rule orchestration plug-ins, third-party data integration and forwarding plug-ins, etc. Each business function can be developed, deployed, and maintained as an independent front-end sub-application + back-end microservice plug-in.

[0099] The above embodiments are only used to illustrate the technical solutions of the present invention. Those skilled in the art should understand that the above embodiments do not limit the present invention in any way. All technical solutions obtained by equivalent substitution or equivalent transformation fall within the protection scope of the present invention.

Claims

1. A plug-in-based secondary development system based on an industrial Internet of Things (IoT) platform, characterized in that: It adopts a front-end and back-end integrated plugin architecture, including: front-end plugin layer, back-end microservice layer, unified gateway layer and plugin governance layer; The front-end plugin layer includes a base application and several independent sub-applications. Each sub-application is built and deployed independently, and the base application dynamically loads the corresponding sub-application. The backend microservice layer is configured with a registration configuration center. Each business function plugin corresponds to at least one backend microservice. After the backend microservice starts, it automatically registers the service instance with the registration configuration center. The unified gateway layer serves as the unified entry point for frontend requests, integrates the service discovery capabilities of the registration configuration center, and dynamically senses changes in backend service instances to achieve routing, authentication, and access control. The plugin governance layer interacts with the front-end plugin layer, the back-end microservice layer, and the unified gateway layer, and includes a plugin metadata center, a front-end and back-end state synchronizer, a front-end configuration proxy, and a unified data context manager.

2. The plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 1, characterized in that, The front-end plugin layer is built on the qiankun micro-front-end framework; the base application adopts the Vite+Vue3 technology stack, completes the registration of sub-applications through the registerMicroApps interface provided by qiankun, and matches and dynamically loads the corresponding sub-applications according to the preset activeRule routing rules. The backend microservice layer is built on the Spring Cloud microservice architecture and uses Nacos as the registration and configuration center; the unified gateway layer is built on Spring Cloud Gateway.

3. The plug-in secondary development system based on an industrial Internet of Things platform according to claim 2, characterized in that, When the base application registers the qiankun sub-application, it notifies the API gateway of the plugin information (plugin identifier, plugin resources, plugin routes, etc.) in the plugin metadata through the internal API. The gateway then automatically generates routing forwarding rules and authentication policies.

4. A plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 2, characterized in that, The Nacos Registration and Configuration Center provides services such as registration and discovery, configuration change monitoring, and service health status event push capabilities. It also establishes a unified plugin metadata storage structure. When each business plugin is deployed, its metadata information is written to the Nacos Registration and Configuration Center in YAML format.

5. A plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 2, characterized in that, When the base application starts, it pulls all plugin metadata in the active state from the Nacos registration configuration center. Based on the plugin routing information in the metadata, the base application dynamically registers sub-applications through qiankun's registerMicroApps. During the registration process, the base application injects plugin information (menu routing, authentication authorization, global parameters) into the sub-applications through qiankun's props mechanism, so that the sub-applications can obtain runtime parameters without hard-coding configuration.

6. A plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 1, characterized in that, When the plugin configuration changes in the Nacos registry configuration center, the base application senses the change in real time through the Nacos configuration listening mechanism and passes the new configuration to the loaded remote components through reactive state management, realizing hot updates of the front-end plugin configuration without refreshing the page.

7. A plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 1, characterized in that, The front-end and back-end state synchronizer subscribes to Nacos service health change events and the base application sub-application loading / unloading events to achieve bidirectional linkage and synchronization between the health status of the back-end microservices and the display status of the front-end sub-applications.

8. A plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 7, characterized in that, The bidirectional synchronization logic of the front-end and back-end state synchronizers is as follows: Backend to frontend synchronization: When a backend microservice instance is removed from the list of healthy instances by Nacos due to a failure, Nacos's subscribe mechanism pushes a service change event. The gateway layer and the base application subscribe to this event simultaneously. The base application updates the health status identifier of the plugin according to the event and blocks the corresponding function entry or displays a service unavailable prompt in the UI of the qiankun sub-application to prevent users from initiating invalid operations. Front-end to back-end synchronization: When the base application successfully loads or uninstalls a certain Qiankun sub-application, it notifies the back-end plugin management service through the internal API to update the status field of the corresponding plugin's metadata in Nacos. The back-end microservice then performs related operations based on this status: indicating whether to start or stop scheduled tasks or release business cache resources.

9. A plug-in-based secondary development system based on an industrial Internet of Things platform according to claim 1, characterized in that, The unified data context manager constructs a three-layer standardized data context to enable data exchange between the front-end global state and the back-end distributed cache and thread-local storage; the three-layer standardized data context includes request-level context, session-level context and plugin-level context.

10. A plug-in-based secondary development method based on an industrial Internet of Things (IoT) platform, applied to the system described in any one of claims 1-9, characterized in that, Includes the following steps: S1. Plugin Development and Building Phase: Developers independently develop front-end sub-applications and back-end microservices, and write the plugin's metadata YAML file. After the front-end sub-application is built, it is combined with the back-end microservice and packaged into a Docker image. S2, Plugin Deployment and Registration Phase: Start the backend microservice and register the service instance with Nacos; Operations personnel publish the plugin metadata YAML file to the Nacos registration and configuration center; S3, Base Application Loading Stage: After the base application starts, it reads all plugin metadata that is active from Nacos; Based on the metadata front-end parameters, qiankun's registerMicroApps is called to register sub-applications in batches, and qiankun's start() is called to start the micro-front-end framework. At the same time, the metadata configuration is injected into the sub-applications. The base application synchronously pushes the back-end configuration to the API gateway, and the gateway automatically generates routes and permission rules. S4, User Access and Data Flow Stage: When the browser URL matches the sub-application's activeRule, qiankun dynamically loads the sub-application and executes the mount lifecycle to render the UI. Sub-application UI initiates API requests, which are then forwarded to the corresponding backend microservices via a unified gateway; The front-end and back-end complete the business data interaction; S5. Plugin Update and Uninstallation Phase: When a plugin is updated, the version field of the metadata in Nacos is modified and the frontend.entry address is updated. The base application listens for and detects the metadata change through the Nacos configuration. When a plugin is uninstalled, the status of the Nacos metadata is changed to inactive, the corresponding sub-application is deregistered on the base, and the corresponding routing rules are deleted synchronously on the gateway.

Images