A plug-in software system based on standardization-customization function separation implementation

Abstract

The application discloses a plug-in software system based on standardization-customization function separation, and belongs to the technical field of computers, comprising a front-end architecture and a server architecture, and solves the technical problems of standardization and customization coordination in system delivery, reduces development and maintenance costs, and enhances the extensibility of the system, the application provides a front-end architecture system and a standardization and customization decoupling method, through a configuration system and a glue component mechanism, the standard and custom functions are completely isolated, the system maintainability and delivery efficiency are improved, component dynamic loading, automatic extraction of route configuration and customization of page jumping are supported, an extension point and an executor mechanism are used on the server side, independent development and deployment of standard and custom logic are realized, tenant-level extension and plug-in mounting are supported, an open and extensible ecological system is constructed, and the application is suitable for multi-tenant, multi-scene enterprise-level application delivery requirements.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of computers, and particularly relates to a plug-in software system based on separation of standardized and customized functions. BACKGROUND

[0002] The existing retail software adopts monolithic front-end engineering and single back-end service, and realizes customer customization through branching mode, which causes frequent code conflicts; components and routes are hard-coded, cannot be dynamically loaded according to tenants, the construction process needs to be repeatedly packaged, and operation and maintenance are complex.

[0003] Standardization can improve development efficiency, guarantee system consistency and reduce maintenance cost, and is therefore widely used in the design and delivery of enterprise-level products; customization is a direct manifestation of customer business differentiation and an important means to improve customer satisfaction and product competitiveness. In ToB systems, in the face of multiple customers, multiple industries and multiple scene requirements, both rapid delivery and accurate adaptation are required, and traditional architectures often face problems such as bloated architecture, repeated development and high maintenance cost. Standard functions and customized functions are mixed together, with high code coupling, which affects the stability of the main system and increases the chain change risk caused by customization.

[0004] Defects and deficiencies of the prior art:

[0005] Most systems use a single code repository or unified deployment package mode for delivery, and fail to clearly separate standard functions and customer customization functions at the architecture level, mainly having the following problems:

[0006] Severe module coupling: standard functions and customization logic are mixed in the same code, making maintenance difficult and having high change risk.

[0007] Difficult to reuse: after standard functions are continuously eroded by customization logic, reusability is greatly reduced, resulting in a large number of "customer unique versions".

[0008] Low delivery efficiency: each delivery needs to repeat the evaluation and manually strip the customer customization code, affecting the delivery cycle.

[0009] High testing cost: standard functions cannot be tested uniformly, and the quality of the main system may decrease due to customer customization.

[0010] Version management is chaotic: code branches are numerous and difficult to merge, version release is uncontrollable, and regression problems are likely to occur. SUMMARY

[0011] The application aims to provide a plug-in software system based on separation of standardized and customized functions, which solves the technical problems of coordination of standardization and customization in system delivery, reduces development and maintenance costs, and enhances scalability.

[0012] To achieve the above object, the application adopts the following technical solutions:

[0013] A plug-in software system based on standardization-customization function separation implementation, comprising a front-end architecture and a server architecture;

[0014] The front-end architecture comprises a configuration system module, a configuration reading module, a glue component module, a plug-in mechanism module and a customized product module;

[0015] The configuration reading module is responsible for connecting the configuration center, adopting a configuration reader based on the LRU cache mechanism, and uniformly obtaining the system-level global configuration;

[0016] The glue component module is responsible for uniformly loading local components and remote components, shielding the differences in component sources, and providing a standard component loading interface, performing component meta-information registration, on-demand loading and life cycle management;

[0017] The plug-in mechanism module is used to uniformly manage public dependencies, and perform dynamic expansion, uninstallation and hot update of public functions;

[0018] The customized product module is based on a standardized engineering base, supports calling a standard component library, customized Groovy scripts and API services through configuration and plug-in mechanisms, and performs isolation and reuse of customized functions;

[0019] The server architecture comprises a configuration service module, an extension point execution engine module, an extension client module and an extension calling module;

[0020] The configuration service module is used to manage the extension point configurations exposed by the standard project, supports adding, modifying, deleting, enabling and disabling operations of the configurations, and pushes configuration changes to the client;

[0021] The extension point execution engine module is deployed in the standard project, supports multiple extension execution modes based on HTTP, RPC, script engine and SPIJar package, dynamically matches according to business scenarios and tenant information, and calls customized extensions;

[0022] The extension client module is responsible for scanning classes with @preextension, @afterextension and @overrideextension annotations during startup, extracting metadata and registering with the configuration service, injecting the Spring container, and then completing the extension service initialization;

[0023] The extension calling module is responsible for intercepting the business method identified by the @extensionpoint annotation by the extension client, passing the extension parameters through the HTTP interface, routing and calling the corresponding extension service, executing the extension logic, and returning the result;

[0024] The configuration service module is configured to provide extension point configuration and extension script to the front-end architecture;

[0025] The front-end architecture and the service-end architecture interact through the extension point and the extension configuration.

[0026] Preferably, the configuration system module is also responsible for module menu management, component list management and operation permission management;

[0027] The LRU cache mechanism of the configuration reading module supports the invalidation policy of one-minute expiration for the cache entries;

[0028] The glue component module supports module federation and ESModule remote component loading;

[0029] The customized product module supports customized component library, customized page logic and page jump.

[0030] Preferably, the configuration service module is responsible for real-time push of configuration changes and configuration pull at the start of the client;

[0031] The extension point includes a calling party, an interface preposition, an interface main logic and an interface postposition;

[0032] The extension point execution engine module supports engineering mode and strategy design mode, and supports flexible extension of new execution modes.

[0033] The plug-in software system based on the separation of standardization and customization function realizes the coordination of standardization and customization in system delivery, reduces the development and maintenance cost, and enhances the extensibility, the front-end part of the application realizes the complete decoupling of standardization and customization, improves the system maintainability, the configuration system and the glue component mechanism are introduced, the effective isolation of standard function and customized function is realized at the architecture level, the code erosion is avoided, the coupling degree between modules is effectively reduced, the risk caused by change is reduced, the maintainability and extensibility of the system are improved, the delivery efficiency is improved, the multiple customer and multiple scene requirements are flexibly adapted, the page structure, component layout and routing logic can be quickly generated through the configuration driven mode, the repetitive development work is saved, the standard function is developed once and reused in multiple projects, the delivery cycle of the customized project is greatly shortened, the component dynamic loading and runtime management are supported, the front-end performance and system flexibility are optimized, the lazy loading strategy is adopted for local components, remote components are dynamically imported through module federation or ESModule, and the first screen loading volume is significantly reduced.Meanwhile, the unified component lifecycle management mechanism avoids repeated loading, improves system running efficiency, enhances function reuse and asset accumulation ability, reduces development and maintenance cost, and standard engineering deposits a unified component library, API service, tool function and configuration module to provide a stable and reliable basic framework for each customized project; combined with the plug-in mechanism and component recycling ability, the long-term accumulation and reuse of business assets are supported, the overall development efficiency of the team is improved, dynamic routing analysis and automatic extraction are supported, complex page jump logic is adapted, the relationship of inter-page jump is automatically extracted through static analysis ability, and the relationship of inter-page jump is configured and managed, the dependence on hard coding is reduced, the adaptation ability of the system to complex business processes is enhanced, the customization of page jump is good, the front-end and back-end are decoupled and evolved, the glue component and plug-in mechanism naturally support the dynamic arrangement of the low-code platform to the component and page, which lays a solid foundation for the complete decoupling and visual development evolution of the future system architecture, the server part of the application realizes the complete isolation of standardization and customization, supports independent development and deployment, and the standard project and the customized project are completely isolated through the extension point and the extension executor mechanism, the standard service can be evolved independently, the customized logic is mounted through the dynamic registration and the executor, and the development and deployment of the two are not interfered with each other, the version of the standard project is kept unified, efficient delivery and low-cost operation are realized, since the customization ability is hosted by the extension mechanism, the standard service can maintain a single version maintenance, avoiding code branching and splitting caused by customization requirements, significantly improving system stability and reducing maintenance cost, supporting tenant-level extension ability, enhancing system flexibility and openness, the system provides extension registration and execution ability in the tenant dimension, customers with independent development ability can access customized logic by registering extension services to meet differentiated business requirements, has the plug-in ecological ability, supports third-party function mounting and running, the system can build a unified plug-in market, allowing third-party developers to develop function plug-ins based on the extension interface and mount them to the platform for running, thereby building a flexible and open ecological system. BRIEF DESCRIPTION OF DRAWINGS

[0034] Fig. 1 is the overall system architecture of the application;

[0035] Fig. 2 is a schematic diagram of the server architecture of the application;

[0036] Fig. 3 is a schematic diagram of the front-end architecture of the application. DETAILED DESCRIPTION

[0037] Based on the standardization-customization function separation implementation Figs. 1-3 The plug-in software system shown in the standardization-customization function separation implementation includes a front-end architecture and a server architecture.

[0038] The front-end architecture comprises a configuration system module, a configuration reading module, a glue component module, a plug-in mechanism module and a customized product module.

[0039] The configuration system module, the configuration reading module, the glue component module, the plug-in mechanism module and the customized product module communicate with each other through the Internet.

[0040] The configuration reading module is responsible for connecting the configuration center, adopting a configuration reader based on an LRU cache mechanism, and uniformly obtaining system-level global configurations.

[0041] The glue component module is responsible for uniformly loading local components and remote components, shielding the differences in component sources, and providing a standard component loading interface, performing component meta-information registration, on-demand loading and life cycle management.

[0042] The plug-in mechanism module is used to uniformly manage public dependencies, and perform dynamic expansion, uninstallation and hot update of public functions.

[0043] The customized product module is based on a standardized engineering base, supports calling a standard component library, customized Groovy scripts and API services through a configuration and plug-in mechanism, and performs isolation and reuse of customized functions.

[0044] The configuration system module is also responsible for module menu management, component list management and operation permission management.

[0045] The LRU cache mechanism of the configuration reading module supports an invalidation policy with a cache entry validity period of one minute.

[0046] The glue component module supports module federation and ESModule remote component loading.

[0047] The customized product module supports customized component libraries, customized page logic and page jumping.

[0048] The workflow of the front-end architecture is as follows:

[0049] Step A1: configuration system initialization and management, specifically:

[0050] The configuration system acts as a bridge between standards and customization, centrally manages various configuration items such as page-level component configurations, page element jump configurations and page jump configurations. Through the configuration system, operation and maintenance personnel can uniformly manage module menus, component lists and operation permissions, and support component auditing, editing, previewing and rollback operations, ensuring the reliability and flexibility of configurations.

[0051] Step A2: global configuration reading and caching, specifically:

[0052] The system uniformly obtains system-level global configurations from a configuration center through a configuration reader, adopts a cache mechanism based on an LRU strategy, improves configuration reading performance, and reduces request pressure. Configuration content remains backward compatible, ensuring stable operation of the system.

[0053] Step A3: dynamic loading of glue component, specifically:

[0054] A "glue component" system is introduced to realize unified loading and management of local components and remote components. The glue component system internally shields differences in component sources and externally uniformly provides a standard component loading interface. The component loading process includes meta-information registration, on-demand loading, unified management of life cycle, and the like, ensuring efficient rendering of components and resource utilization.

[0055] Step A4: support of plug-in mechanism, specifically:

[0056] To solve the redundancy problem caused by repeated introduction of public dependencies by multiple components, the front-end architecture of the present application integrates a plug-in mechanism, uniformly manages public dependencies, realizes dynamic extension, uninstallation and hot update of public functions, and improves system flexibility and maintenance efficiency.

[0057] Step A5: standardization of custom products, specifically:

[0058] Based on ToB project experience, a standardized engineering base is abstracted, covering a general business component library, a unified API service, public tool functions and a configuration management module, and serves as a basis for custom product development.

[0059] Custom projects call standard modules through configuration and plug-in mechanisms, realize a development mode of "standard as a service, customization with isolation", and promote code reuse and unified operation and maintenance.

[0060] The following is an application scenario of the front-end architecture in the present embodiment:

[0061] Step S1: build standard project framework and custom engineering structure.

[0062] In the present embodiment, the front-end system is composed of standard products and custom functions. The front-end architecture first builds a standard project framework, which includes a front-end application framework module, a glue component submodule, a custom configuration submodule and an extension point definition module. These modules together constitute an extensible and reusable basic capability system.

[0063] The custom engineering is extended on this basis, and realizes the differentiated needs of tenants or business scenarios by introducing custom pages and custom components.

[0064] Step S2: load extension configuration from the configuration server front-end module.

[0065] In this embodiment, the front-end architecture initiates a request to the configuration service of the service end to obtain extension configuration information including extension point registration information, extension service configuration, and extension script configuration.

[0066] The front-end architecture has local caching capability, which is used to support fault-tolerant loading in an offline environment and serve as a basic data source for subsequent page rendering and component loading.

[0067] Step S3: Start the front-end application framework and execute the extension configuration logic.

[0068] In this embodiment, the front-end application framework pulls the extension script and extension point configuration in the initialization phase, combines the current tenant context and routing path, and dynamically determines the page structure and logical behavior.

[0069] In this process, the front-end application framework injects the extension configuration into the standard process to form an organic combination of standard logic and customized logic.

[0070] Step S4: Load the customized page logic to adapt to different strategies.

[0071] In this embodiment, the front-end architecture distinguishes the customized logic of new pages or old pages according to the extension point configuration. Each page is loaded by customized configuration. Different customization points (such as customization 1, customization 2, etc.) are embedded into the page as functional placeholders to support flexible assembly of views and business logic and realize low-invasive extension.

[0072] Step S5: The configuration center module supports configuration management throughout the process.

[0073] In this embodiment, the front-end architecture uniformly manages the dimensions of page configuration, component configuration, engineering configuration, and tenant configuration, and supports page generation and component combination through a what-you-see-is-what-you-get interactive mode.

[0074] The front-end architecture builds an end-to-end configuration link, which is a key support for realizing the standardization and customization of front-end engineering.

[0075] Step S6: Load components and render pages through the glue component submodule.

[0076] In this embodiment, the front-end architecture completes dynamic loading and life cycle management of components through the glue component submodule.

[0077] The glue component submodule shields the technical differences between local components and remote components, provides a unified registration, loading, rendering, and caching mechanism, and effectively supports module federation and remote hot update capability of low-code components.

[0078] Step S7: The configuration reading and caching module optimizes the running performance.

[0079] In this embodiment, the front-end architecture adopts an LRU cache mechanism and sets a 1-minute invalidation strategy to ensure the timeliness and access efficiency of configuration information and provide stable performance support for high-frequency page access scenarios.

[0080] The service end architecture includes a configuration service module, an extension point execution engine module, an extension client module and an extension calling module; the configuration service module, the extension point execution engine module, the extension client module and the extension calling module communicate with each other through the Internet.

[0081] The configuration service module is configured to manage the exposed extension points of the standard project, support the addition, modification, deletion, enablement and disablement of configurations, and push configuration changes to the client;

[0082] The extension point execution engine module is deployed in the standard project, supports multiple extension execution modes based on HTTP, RPC, a script engine and an SPIJar package, dynamically matches according to business scenarios and tenant information, and calls customized extensions;

[0083] The extension client module is responsible for scanning classes with @preextension, @afterextension and @overrideextension annotations during startup, extracting metadata and registering with the configuration service, injecting a Spring container, and then initializing the extension service;

[0084] The extension calling module is responsible for intercepting business methods identified by the @extensionpoint annotation, passing extension parameters through an HTTP interface, routing and calling corresponding extension services, executing extension logic, and returning results. In this embodiment, a built-in script engine can also be used to execute customized Groovy scripts to achieve customized logic extension;

[0085] The configuration service module is configured to provide extension point configurations and extension scripts to the front-end architecture;

[0086] The front-end architecture and the service end architecture interact through extension points and extension configurations.

[0087] The configuration service module is responsible for real-time configuration change pushing and configuration pulling during client startup.

[0088] The extension point includes a caller, an interface prefix, an interface main logic and an interface postfix.

[0089] The extension point execution engine module supports engineering patterns and strategy design patterns, and supports flexible extension of new execution modes.

[0090] The workflow of the service end is as follows:

[0091] Step B1: Extension point and extension configuration management, specifically including:

[0092] The configuration service module is responsible for managing the extension point configuration exposed by the standard project and the specific extension configuration for the extension point, supporting the addition, modification, deletion, and enable / disable operations of the extension point and the extension configuration.

[0093] Through the configuration service module, real-time push of configuration changes and configuration pull of the client are realized, ensuring the dynamic consistency of system configuration.

[0094] Step B2: Extension point execution engine mechanism, specifically including:

[0095] The standard project exposes multiple extension points in the core business process, such as the caller, interface preposition, interface main logic, and interface postposition, and the extension point execution engine dynamically matches the corresponding custom extension based on business scenarios and tenant information.

[0096] The execution engine supports multiple execution modes, with HTTP, RPC executor, and script engine provided by default, and can be extended with SPI-based Jar package executors to meet different extension implementation needs.

[0097] In this embodiment, the extension point execution engine is a bridge connecting the standard business process and the custom logic, and its core structure includes:

[0098] The extension point registration manager is responsible for the registration and verification of extension metadata;

[0099] The executor adaptation layer supports multiple calling modes, including HTTP caller, RPC caller, and script engine by default, and reserves SPI plug-in extension;

[0100] The execution router is used to dynamically select the appropriate extension service based on extensionName, tenant ID, and business context;

[0101] The execution cache module is used for cache management of the extension service Bean instance to optimize performance;

[0102] The call tracking and exception processor is used to record the call link, capture exception information, and ensure the stability of the extension.

[0103] Step B3: Start-up and registration process, specifically including:

[0104] During the system startup phase, the extension client scans the classes annotated with @preextension, @afterextension, and @overrideextension annotations, extracts the annotation metadata, and registers it with the configuration server.

[0105] After the configuration server confirms the successful registration, the client injects the extension class into the Spring container, completing the initialization of the extension service.

[0106] Step B4: Extension call flow, specifically including:

[0107] At runtime, the business method is annotated with @extensionpoint and intercepted by the extension client.

[0108] The client passes the extension configuration parameters to the extension execution engine through the HTTP interface, routes the request according to the extension name, calls the corresponding extension service Bean, executes the extension logic, and finally returns the extension result to the caller, achieving dynamic extension and customization of business functions or executing customized Groovy scripts through the built-in script engine, thereby achieving extension and customization of logic.

[0109] Step B5: Standard project and custom project collaboration, specifically including:

[0110] The standard project and the custom project share the above extension mechanism, and the startup and call flow of the two are consistent, ensuring that the system functions dynamically inject custom logic through extension points to meet the business needs of different customers, while ensuring the stability and maintainability of the core system.

[0111] The following is the running process of the server architecture in the standard project and the custom project:

[0112] moana-server: Corresponding to the configuration service module, responsible for the registration, management, and push functions of the extension point configuration and extension implementation configuration, serving as the configuration center;

[0113] moana-extension-client: Corresponding to the extension client module, responsible for scanning, registering, injecting extension classes, and actually calling extension logic, mainly running in the custom project;

[0114] moana-client: Corresponding to the extension call module, located in the standard project, responsible for intercepting extension points in the standard business process, and calling the extension service defined in the extension client module through a unified interface;

[0115] Executor components (such as HTTP / RPC executors, script engines, SPI Jar executors): collectively known as the extension point execution engine module, responsible for distributing extension requests to corresponding extension services according to the definition and configuration of the extension point, and supporting multiple execution protocols.

[0116] The specific steps of the standard service process are as follows:

[0117] Startup phase:

[0118] Step Y1: Scan all extension classes annotated with @PreExtension, @AfterExtension or @OverrideExtension by moana-extension-client module in startup phase;

[0119] Step Y2: Extract annotation class meta information and register to moana-server module as extension point metadata;

[0120] Step Y3: moana-server module confirms the success of metadata registration and returns the confirmation result;

[0121] Step Y4: moana-extension-client module injects the above-mentioned annotation class into the Spring container, which needs to implement the corresponding extension interface (such as Pre, After or Override type);

[0122] Step Y5: Spring container completes the injection and initialization of extension classes and notifies the extension client module.

[0123] Execution phase:

[0124] Step Y6: moana-client module intercepts the method annotated with @ExtensionPoint in business logic;

[0125] Step Y7: Forward the call request containing extension configuration parameters (such as extensionName) to moana-extension-client module through / extension / gateway interface;

[0126] Step Y8: moana-extension-client module routes to the corresponding extension service according to the extension name;

[0127] Step Y9: Get the matching extension service Bean instance from the Spring container;

[0128] Step Y10: Spring container returns the instance to the extension client module;

[0129] Step Y11: moana-extension-client module calls the target method in the extension Bean to execute custom logic;

[0130] Step Y12: The extension service executes and returns the processing result;

[0131] Step Y13: The extension client module returns the result to the caller (moana-client);

[0132] Step Y14: The final result is sent to the user terminal or the upper layer service.

[0133] The custom service process is the same as the standard service process in terms of starting and calling logic, but it provides independently developed extended service logic that is independently deployed from the standard project implementation.

[0134] The custom service process differs from the standard service process in that:

[0135] Although the scanning and registration processes of the annotation class are consistent, the registered is a "custom implementation class";

[0136] The extended service Bean is implemented by the custom project and is dynamically loaded and executed within the standard process;

[0137] The extension point execution engine has dynamic selection capability and matches the corresponding custom implementation according to the tenant context or business identifier;

[0138] Support for remote invocation of custom services through HTTP / RPC interfaces, script engines, or local integration through SPI plug-ins.

[0139] The front-end architecture cooperates with the configuration service module in the back-end architecture through network communication.

[0140] The front-end architecture pulls the extension point configuration and extension scripts from the configuration service module during the application framework startup phase to drive the loading of page structure and component logic.

[0141] The back-end architecture calls the registered custom services through the extension point execution engine according to the extension points defined in the standard project to achieve dynamic extension of business logic.

[0142] The front-end and back-end are decoupled and linked through extension points, supporting low-intrusion customization and dynamic rendering of interfaces and execution logic according to tenant dimensions.

[0143] In this embodiment, the integration of the front-end and back-end dynamic extension capabilities is achieved through the configuration center and extension point mechanism. The front-end loads components and pages based on configuration, and the back-end calls specific custom logic through the extension execution engine. Both ensure the configurability, pluggability, and isolation of business processes.

[0144] The plug-in software system based on the separation of standardization and customization function realizes the coordination of standardization and customization in system delivery, reduces the development and maintenance cost, and enhances the extensibility, the front-end part of the application realizes the complete decoupling of standardization and customization, improves the system maintainability, the configuration system and the glue component mechanism are introduced, the effective isolation of standard function and customized function is realized at the architecture level, the code erosion is avoided, the coupling degree between modules is effectively reduced, the risk caused by change is reduced, the maintainability and extensibility of the system are improved, the delivery efficiency is improved, the multiple customer and multiple scene requirements are flexibly adapted, the page structure, component layout and routing logic can be quickly generated through the configuration driven mode, the repetitive development work is saved, the standard function is developed once and reused in multiple projects, the delivery cycle of the customized project is greatly shortened, the component dynamic loading and runtime management are supported, the front-end performance and system flexibility are optimized, the lazy loading strategy is adopted for local components, remote components are dynamically imported through module federation or ESModule, and the first screen loading volume is significantly reduced.Meanwhile, the unified component lifecycle management mechanism avoids repeated loading, improves system running efficiency, enhances function reuse and asset accumulation ability, reduces development and maintenance cost, and standard engineering deposits unified component library, API service, tool function and configuration module, provides stable and reliable basic framework for each customized project; combined with the plug-in mechanism and component recycling ability, long-term accumulation and reuse of business assets are supported, the overall development efficiency of the team is improved, dynamic routing analysis and automatic extraction are supported, complex page jump logic is adapted, through static analysis ability, the inter-page jump relationship is automatically extracted and configured management is carried out, the dependence on hard coding is reduced, the adaptation ability of the system to complex business processes is enhanced, the customization of page jump is good, front-end and back-end decoupling evolution is supported, the glue component and plug-in mechanism naturally support the dynamic arrangement of the low-code platform to the component and page, which lays a solid foundation for the future system architecture to completely decouple and visually develop and evolve, the server part of the application realizes the complete isolation of standardization and customization, supports independent development and deployment, and the standard project and the customized project realize complete isolation through the extension point and the extension executor mechanism, the standard service can evolve independently, the customized logic is mounted through the dynamic registration and the executor, and the development and deployment of the two are not interfered with each other, the standard project version remains unified, efficient delivery and low-cost operation and maintenance are realized, since the customization ability is hosted by the extension mechanism, the standard service can maintain a single version, avoiding code branching and splitting caused by customization requirements, significantly improving system stability and reducing maintenance cost, supporting tenant-level extension ability, enhancing system flexibility and openness, the system provides extension registration and execution ability in the tenant dimension, customers with independent development ability can access customized logic by registering extension services, meet differentiated business requirements, have plug-in ecological ability, support third-party function mounting and running, the system can build a unified plug-in market, allow third-party developers to develop function plug-ins based on the extension interface, and mount them to the platform for running, so as to build a flexible and open ecological system.

Claims

1. A plug-in software system based on implementation of a standardized- customized function separation, characterized in that: The front-end architecture and the service-end architecture are included; The front-end architecture includes a configuration system module, a configuration reading module, a glue component module, a plug-in mechanism module and a customized product module; The configuration system module is responsible for module menu management, component list management and operation permission management; The configuration reading module is responsible for connecting the configuration center, adopting a configuration reader based on an LRU cache mechanism and uniformly acquiring system-level global configurations; The glue component module is responsible for uniformly loading local components and remote components, shielding differences in component sources, providing a standard component loading interface, performing component meta-information registration, on-demand loading and life cycle management; The plug-in mechanism module is used for uniformly managing public dependencies, performing dynamic expansion, uninstallation and hot update of public functions; The customized product module supports the isolation and reuse of customized functions through configuration and plug-in mechanism, calling a standard component library, customized Groovy scripts and API services based on a standardized engineering base; The service-end architecture includes a configuration service module, an extension point execution engine module, an extension client module and an extension calling module; The configuration service module is used for managing extension point configurations exposed by a standard project, supporting addition, modification, deletion, enabling and disabling operations of configurations and pushing configuration changes to a client; The extension point execution engine module is deployed in a standard project, supports multiple extension execution modes based on HTTP, RPC, a script engine and a SPIJar package, dynamically matches according to business scenarios and tenant information and calls customized extensions; The extension client module is responsible for scanning classes with @preextension, @afterextension and @overrideextension annotations during startup, extracting metadata and registering with the configuration service, injecting a Spring container and then completing extension service initialization; The extension calling module is responsible for intercepting a business method identified by an @extensionpoint annotation, passing extension parameters through an HTTP interface, routing and calling corresponding extension services, executing extension logic and returning a result; The configuration service module is used for providing extension point configurations and extension scripts to the front-end architecture; The front-end architecture and the service-end architecture interact through extension points and extension configurations.

2. The plug-in software system based on separation of standardization and customization functions as claimed in claim 1, wherein: The LRU cache mechanism of the configuration reading module supports an invalidation policy with a cache item validity period of one minute; The glue component module supports module federation and ESModule remote component loading; The customized product module supports customized component libraries, customized page logic and page jumps.

3. The plug-in software system based on separation of standardization and customization functions as claimed in claim 1, wherein: The configuration service module is responsible for real-time configuration change pushing and configuration pulling during client startup; The extension point includes a caller, an interface prefix, an interface main logic and an interface postfix; The extension point execution engine module supports engineering patterns and strategy design patterns and supports flexible expansion of new execution modes.

Images