An industry model differentiation and extension method and system based on product package decoupling

Abstract

The application discloses an industry model differentiation expansion method and system based on product package decoupling, and relates to the technical field of industrial software architecture; the method comprises the following steps: acquiring a basic service platform defined with controlled extension points; receiving a dependent configuration of a differentiated business module; comparing a target version model with an interface model of a current running instance, and generating a compatibility evaluation result in combination with the dependent configuration; creating an isolated environment for independent running according to the result, and injecting an implementation declaration; responding to a business request, parsing a request context, determining a target extension definition by using a conflict arbitration mechanism in combination with the context, and performing the target extension definition; the application realizes automatic prediction of upgrade risks by abstract syntax tree comparison, reduces regression test load; prevents system downtime caused by single module failure by using an independent isolated environment; realizes zero-interruption business upgrade by using a hot migration process; solves multi-industry extension conflicts by using context-based dynamic arbitration, and improves the stability and reusability of an industrial software platform.

Description

Technical Field

[0001] This application relates to the field of industrial software architecture technology, specifically to an industry model differentiation extension method and system based on product package decoupling. Background Technology

[0002] As industrial software evolves towards platformization and ecosystem development, the basic platform needs to support differentiated functional extensions for various industry scenarios. However, existing technologies typically employ a tightly coupled architecture between the basic platform and industry extension packages. When implementing differentiated extensions, there is a lack of a security control mechanism that spans the entire lifecycle of the extension, making it impossible to achieve accurate adaptation of multi-industry models while ensuring the high availability of the basic platform.

[0003] Specifically, the lack of such a control mechanism is reflected in the following three aspects: First, during the expansion loading phase, existing technologies lack the ability to structurally compare interface models, leading to uncontrollable expansion risks. When upgrades to the underlying platform cause changes to the interface model, the system cannot automatically identify incompatibilities before loading, and problems are often only exposed at runtime due to interface call failures, lacking risk quantification and prevention mechanisms before upgrades.

[0004] Secondly, during the execution phase, in the existing architecture, industry extension packages typically share the same process memory space with the basic platform, lacking an effective physical isolation environment. Once a differentiated business module experiences a memory leak or logical anomaly, it will directly affect the basic platform, causing the entire process to crash and severely impacting the overall stability of the system.

[0005] Finally, during the business scheduling phase, existing technologies lack context-based dynamic arbitration capabilities when multiple extensions coexist. When multiple industry packages provide different implementations for the same extension point, the system cannot accurately route to the correct target extension definition based on the specific request context (such as tenant attributes), and can only adopt a static overriding strategy, leading to errors in business logic execution. Summary of the Invention

[0006] This application provides a method and system for differentiated extension of industry models based on product package decoupling. It can solve the technical problem that the basic platform and industry extension packages in the prior art usually adopt a tightly coupled architecture pattern. When implementing differentiated extension, there is a lack of a security control mechanism that runs through the entire life cycle of the extension, which makes it impossible to achieve accurate adaptation of multiple industry models while ensuring the high availability of the basic platform.

[0007] In a first aspect, embodiments of this application provide a method for differentiating and extending an industry model based on product package decoupling, comprising: Obtain the current running instance and target version model of the basic service platform, which has controlled extension points defined based on a preset design pattern; The system receives the dependency configuration of the differentiated business module, which includes the implementation declaration of the controlled extension point, the base version compatibility range, and the extension point locking strategy; it compares the interface model of the currently running instance with the target version model and generates a compatibility assessment result based on the dependency configuration; it determines a loading strategy based on the compatibility assessment result, and when the loading strategy indicates that loading is accepted, it creates an isolated environment for the differentiated business module to run independently and injects the implementation declaration into the corresponding controlled extension point; In response to business requests, the request context is parsed; when multiple implementation declarations of the same controlled extension point are detected, the target extension definition is determined by combining the request context with a conflict arbitration mechanism, and the target extension definition is executed in the independently running isolated environment.

[0008] Preferably, the interface model of the currently running instance is compared with the target version model, and a compatibility assessment result is generated in conjunction with the dependency configuration, specifically including: Parse the dependency configuration and construct an extension point dependency graph containing the mapping relationship between the differentiated business modules and the controlled extension points; Using an abstract syntax tree comparison algorithm, a structural difference analysis is performed on the interface model of the current running instance and the target version model to identify the changed extension points and generate a structural change set. The types of changes in the structural change set include extension point addition, extension point deletion, extension point modification, extension point renaming, extension point splitting, and extension point merging. Based on the extension point dependency graph, the dependency paths associated with the changed extension points in the structural change set are retrieved, the affected scope of the differentiated business modules is calculated, and the compatibility assessment result is generated according to the affected scope and the extension point locking strategy.

[0009] Preferably, the compatibility assessment result is generated based on the affected range and the expansion point locking strategy, specifically including: A high-risk block is generated when the affected area includes the deleted extension point; When the affected range includes the split expansion point, if the expansion point locking strategy is strict locking, a high-risk block is generated; if the expansion point locking strategy is loose locking, a medium-risk drift is generated, and automatic mapping to the split equivalent child node is configured. When the affected scope includes the modified extension point, if the modification results in type incompatibility, a medium-risk pass is generated; if the modification is compatible, a low-risk pass is generated. A low-risk passage is generated when the affected area does not hit any change node.

[0010] Preferably, a loading strategy is determined based on the compatibility assessment results. When the loading strategy indicates that loading is accepted, an isolated environment for the differentiated business module to run independently is created, specifically including: When the compatibility assessment result is low-risk and allows passage, the loading strategy is determined to be direct migration. An isolated environment is created in the target running instance that has the target version model loaded, and the differentiated business module is loaded directly. When the compatibility assessment result is medium-risk drift, the loading strategy is determined to be drift migration. An isolated environment is created in the target running instance that loads the target version model, and the differentiated business module is loaded after the extension point path is redirected and mapped. When the compatibility assessment result is high-risk blocking, the loading strategy is determined to be to refuse loading, refuse to create an isolated environment for independent operation, and generate alarm information.

[0011] Preferably, an isolated environment is created in the target running instance that loads the target version model, specifically including triggering an environment upgrade and switching process; triggering the environment upgrade and switching process specifically includes: The system controls the currently running instance to serialize and save the internal business runtime state, generating a state snapshot; the state snapshot filters out non-migratable resources. Start the target running instance loaded with the target version model, and inject the deserialized state snapshot into the target running instance to restore the business runtime state; By using an atomic traffic switching switch, the routing target of the service request is changed from the currently running instance to the target running instance; Monitor the anomaly rate within the preset time window after switching, and if it exceeds the threshold, roll back to the currently running instance.

[0012] Preferably, creating an isolated, independently operating environment includes: Construct a three-level class loader structure that includes a base layer, an industry layer, and a proxy layer; The base public classes and extension point interfaces are loaded through the class loader corresponding to the base layer. The private class library of the differentiated business module is loaded through the class loader corresponding to the industry layer, and a hybrid delegation mechanism is configured: parent priority delegation is adopted for the base public class, and child priority self-check is adopted for the private class library, so as to achieve memory space isolation and ensure type consistency. The proxy layer dynamically generates extension point proxy classes, routes the implementation declaration to the class loader corresponding to the industry layer, and inserts conflict arbitration logic before and after the call.

[0013] Preferably, the dependency configuration is a declarative inheritance manifest in YAML or JSON format, containing extension point type definitions; the extension point types include field extension points, association extension points, rule overriding points, and event interception points.

[0014] Preferably, the dependency configuration for receiving differentiated business modules includes: Dependency data is read from a pre-defined relational database table. This dependency data includes module identifiers, platform version numbers, and extension point priorities; or... Parse the independently stored configuration file and obtain the dependent configuration.

[0015] Preferably, the target extension definition is determined using a conflict arbitration mechanism in conjunction with the request context, including: Parse the user's industry affiliation identifier in the request context; Query the extension point registry. When multiple extension definitions match the same controlled extension point, obtain a preset priority strategy. The preset priority strategy includes an industry-dominant strategy, a base-dominant strategy, and a merging strategy. When the preset priority strategy is an industry-led strategy, the extended definition of the corresponding industry is matched based on the user's industry affiliation identifier as the target extended definition. When the preset priority strategy is a base-dominated strategy or a merging strategy, the extension definition with the highest priority is selected as the target extension definition; The arbitration result is cached in an in-memory cache table, so subsequent identical requests will directly hit the cache.

[0016] Secondly, embodiments of this application provide an industry model differentiation extension system based on product package decoupling, which includes: The basic service module is used to provide controlled extension points based on preset design pattern definitions; A configuration receiving module is configured to receive the dependency configuration of the differentiated business module, wherein the dependency configuration includes the implementation declaration of the controlled extension point; The compatibility analysis module is used to compare the interface model of the currently running instance with the target version model, and generate a compatibility evaluation result in combination with the dependency configuration. An isolation loading module is used to determine a loading strategy based on the compatibility assessment results. When the loading strategy indicates that loading is accepted, an isolated environment for the differentiated business module to run independently is created, and the implementation declaration is injected into the corresponding controlled extension point. The arbitration execution module is used to respond to business requests, parse the request context, and when multiple implementation declarations of the same controlled extension point are detected, it uses a conflict arbitration mechanism in conjunction with the request context to determine the target extension definition and executes the target extension definition in the independently running isolated environment.

[0017] The beneficial effects of the technical solutions provided in this application include: By constructing a closed-loop security management system that spans the entire lifecycle of extensions, the constraints of tightly coupled architecture are fundamentally broken. In the pre-access phase, the system generates compatibility assessment results by structurally comparing dependency configurations with the interface models of the currently running instance, thereby automatically identifying and blocking potential crash risks caused by interface changes before loading. In the execution phase, the system dynamically creates independent isolated environments (such as independent class loaders or container processes) based on these assessment results, physically isolating differentiated business modules from the basic platform in memory or process space, effectively curbing global downtime caused by single-point anomalies and ensuring high platform availability. In the business scheduling phase, the system dynamically routes multiple coexisting extension implementations by parsing the context attributes of business requests (such as tenant identifiers or industry affiliation) and utilizing a conflict arbitration mechanism, accurately matching and executing the target extension definition. This solution deeply integrates static contract verification, dynamic fault isolation, and context-aware scheduling, decoupling the basic platform and industry extension packages, effectively solving the technical problem of simultaneously ensuring high availability of the basic platform and accurate adaptation to multiple industry models. Attached Figure Description

[0018] Figure 1 This is a flowchart illustrating the industry model differentiation extension method based on product package decoupling proposed in this application. Detailed Implementation

[0019] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of the present application.

[0020] First, some of the technical terms used in this application will be explained to help those skilled in the art understand this application.

[0021] Basic service platform: refers to the core software layer running on the computer processor, occupying shared memory space, providing public business model data and controlled extension point interfaces, and is the parent class carrier for industry model inheritance.

[0022] Independently running isolated environment: refers to a logical sandbox built through class loader namespace isolation or container process isolation, with independent stack memory space or process space to prevent mutual interference between modules.

[0023] Abstract Syntax Tree (AST): refers to a tree-like data representation of source code or model structure. In this application, the processor automatically traverses and compares the data to identify node changes (addition / deletion / modification / splitting / merging) to generate a set of structural changes.

[0024] Hot migration: refers to the technical process of transferring the running state from the old environment to the new environment without interrupting the processor's processing of external requests, through memory snapshot serialization and atomic routing switching.

[0025] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0026] Firstly, an industry model differentiation extension system based on product package decoupling is provided, which includes: The basic service module is used to provide controlled extension points based on preset design pattern definitions; The configuration receiving module is used to receive the dependency configuration of differentiated business modules. The dependency configuration includes the implementation declaration of the controlled extension point. The compatibility analysis module is used to compare the interface model of the currently running instance with the target version model, and generate compatibility assessment results in combination with dependency configuration. The isolation loading module is used to create an isolated environment for the independent operation of differentiated business modules based on the compatibility assessment results, and inject the implementation declarations into the corresponding controlled extension points; The arbitration execution module is used to respond to business requests, parse the request context, and when multiple implementation declarations of the same controlled extension point are detected, it uses the conflict arbitration mechanism in combination with the request context to determine the target extension definition and executes the target extension definition in an independently running isolated environment.

[0027] The above demonstrates the functions of each module. This system architecture primarily showcases the following core advantages: ① Pre-emptive defense (compatibility analysis module): By comparing the "dependency configuration" with the "interface model," the system can predict the risks of interface changes brought about by the upgrade of the basic platform (such as the deletion or modification of extension points) before loading. This avoids runtime crashes caused by blind loading in traditional architectures, realizing a shift from "passive repair" to "proactive interception."

[0028] ② Runtime isolation (isolated loading module): This module creates an "isolated environment for independent operation" based on the evaluation results. This means that the code of the industry extension package is physically or logically isolated from the core code of the underlying platform. A memory leak or anomaly in a single extension package will not cause the entire underlying platform to crash, greatly improving the stability and availability of the system (i.e., "fault isolation").

[0029] ③ Decoupled Extension Mechanism (Basic Service Module + Configuration Receiving Module): The system implements declarative extension through "controlled extension points" and "dependency configurations." Developers do not need to modify the basic platform code; they can simply insert business logic through configuration declarations. This breaks the tight coupling between the basic platform and industry business, supporting the parallel development and deployment of multi-industry models.

[0030] ④ Dynamic Conflict Arbitration (Arbitration Execution Module): Addressing the conflict issue of "multiple implementations of the same extension point" in multi-tenant or multi-industry scenarios, the system utilizes "request context" (such as user industry attributes) for dynamic routing. This ensures that in complex business environments, the system can accurately match and execute the corresponding target extension definition, solving the problem of unarbitrated extension conflicts.

[0031] The above-mentioned "isolated loading modules" adopt different loading strategies based on the "compatibility assessment results" (such as direct loading for low-risk modules, triggering upgrade switching for medium-risk modules, and blocking for high-risk modules). This intelligent hierarchical processing mechanism not only ensures the security of the system, but also provides an architectural foundation for non-stop hot migration (through state snapshots and traffic switching), meeting the requirements of 24 / 7 continuous operation in industrial scenarios.

[0032] In summary, this system architecture, through a closed-loop design of "evaluation-isolation-arbitration," constructs a secure, stable, and flexible scalability ecosystem. It not only solves the problems of uncontrollable upgrade risks and poor operational stability in traditional architectures, but also achieves precise adaptation and parallel operation of multiple industry businesses.

[0033] Secondly, embodiments of this application provide a method for differentiated extension of industry models based on product package decoupling, which includes the following steps: Step S1: Obtain the current running instance and target version model of the basic service platform. The basic service platform has controlled extension points defined based on a preset design pattern. Receive the dependency configuration of the differentiated business module. The dependency configuration includes the implementation declaration of the controlled extension points. Step S2: Compare the interface model of the currently running instance with the target version model, and generate a compatibility assessment result based on the dependency configuration; determine the loading strategy based on the compatibility assessment result; when the loading strategy indicates to accept loading, create an isolated environment for the differentiated business modules to run independently, and inject the implementation declaration into the corresponding controlled extension point; Step S3: Respond to business requests and parse the request context; when multiple implementation declarations are detected for the same controlled extension point, use the conflict arbitration mechanism in conjunction with the request context to determine the target extension definition, and execute the target extension definition in an independently running isolated environment.

[0034] By constructing a closed-loop security management system that spans the entire lifecycle of extensions, the constraints of tightly coupled architecture are fundamentally broken. In the pre-access phase, the system generates compatibility assessment results through structured comparison of the old and new base models, automatically identifying and blocking potential crash risks caused by interface changes before loading. In the execution phase, the system dynamically creates independent isolated environments (such as independent class loaders or container processes) based on the assessment results, physically isolating differentiated business modules from the basic platform in memory or process space, effectively curbing global downtime caused by single-point anomalies and ensuring high platform availability. In the business scheduling phase, the system dynamically routes multiple coexisting extension implementations by parsing the context attributes of business requests (such as tenant identifiers or industry affiliation) and utilizing a conflict arbitration mechanism, accurately matching and executing the target extension definition. This solution deeply integrates static contract verification, dynamic fault isolation, and context-aware scheduling, effectively decoupling the basic platform and industry extension packages, and effectively solving the technical problem of simultaneously ensuring high availability of the basic platform and accurate adaptation of multiple industry models.

[0035] Furthermore, step S1 specifically includes steps S1-1 and S1-2; Step S1-1 involves obtaining the currently running instance and target version model of the basic service platform. The basic service platform defines controlled extension points based on a preset design pattern. Specifically, the processor reads the binary code of the basic service platform (e.g., base-core.jar) from the hard drive and loads it into the common heap area of ​​memory. The platform uses the strategy pattern or template method pattern to predefine controlled extension point interfaces (e.g., interfaces annotated with @ExtensionPoint). When the platform starts, it scans the class structure in memory and registers the interface signatures to the extension point registry in memory (using a ConcurrentHashMap structure).

[0036] The above method achieves fast lookup through the in-memory registry, reducing the time complexity of expansion point lookup to O(1). Compared to traditional reflection queries, this reduces runtime CPU computation load and improves the real-time response of requests. Simultaneously, the system obtains the target version model for planned upgrades as a benchmark for compatibility comparison.

[0037] Steps S1-2 involve receiving the dependency configuration of the differentiated business module. The dependency configuration includes implementation declarations for controlled extension points. Receiving the dependency configuration of the differentiated business module includes: reading dependency relationship data from a preset relational database table, where the dependency relationship data includes the module identifier, platform version number, and extension point priority; or parsing an independently stored configuration file and obtaining the dependency configuration. Specifically, the system receives differentiated business modules (such as the "Mold Industry Package").

[0038] The extension points include: Field extension points: Add fields / substructures to the base data model (such as adding mold base / cavity / core to the basic BOM); Related extension points: Establish new associations between base models (such as establishing a dispatch association between work orders and electrode lists). Rule coverage points: Cover / add base business rules (such as adding electrode loss verification when closing a work order); Event interception point: interception / additional processing on the event bus (such as adding electrode return after work order closure).

[0039] The configuration receiving module reads dependency configurations, supporting two methods: 1. File-based method: Reads the manifest.yaml file stream from the module directory and deserializes it into a JSON object. The configuration file contains base_dependency, locked_extension_points, and extensions.

[0040] 2. Database Approach: Dependency data is read from a pre-defined relational database table (e.g., t_module_dependency), with fields including module identifier, platform version number, and extension point priority. This approach establishes dependency indexes through declarative configuration, avoiding full code scanning. Database configuration allows for dynamic modification of dependencies at runtime without restarting the service, reducing configuration file I / O operations and improving system response speed and operational efficiency.

[0041] In some preferred embodiments, step S2 includes: Step S2-1 involves comparing the interface model of the currently running instance with the target version model and generating a compatibility assessment result based on the dependency configuration. The specific steps are as follows: Step S2-1-1: Parse the dependency configuration and construct an extension point dependency graph containing the mapping relationship between differentiated business modules and controlled extension points; Step S2-1-2: Using the abstract syntax tree comparison algorithm, perform structural difference analysis on the interface model of the current running instance and the target version model, identify the changed extension points, and generate a set of structural changes. Step S2-1-3: Based on the extension point dependency graph, retrieve the dependency paths associated with the changed extension points in the structural change set, calculate the affected scope of differentiated business modules, and generate compatibility assessment results based on the affected scope and extension point locking strategy. The types of changes in the structural change set include extension point addition, deletion, modification, renaming, splitting, and merging. Compatibility assessment results are generated based on the affected scope and the expansion point locking strategy. Specifically, the following applies: when the affected scope includes deleted expansion points, a high-risk block is generated; when the affected scope includes split expansion points, if the expansion point locking strategy is strict, a high-risk block is generated; if the expansion point locking strategy is lenient, a medium-risk drift is generated, and automatic mapping to the split equivalent child nodes is configured; when the affected scope includes modified expansion points, if the modification results in type incompatibility, a medium-risk drift is generated; if the modification is compatible, a low-risk passage is generated; when the affected scope does not hit any changed nodes, a low-risk passage is generated.

[0042] Specifically: Dependency configuration is parsed, and a Dependency Graph (DAG) containing the mapping relationships between differentiated business modules and controlled extension points is constructed. AST comparison is performed; using an Abstract Syntax Tree Comparison algorithm, structural differences are analyzed between the interface model of the current running instance and the target version model. Identified change types include: extension point addition, deletion, modification, renaming, splitting, and merging. For example, splitting an interface into two interfaces falls under "extension point splitting."

[0043] Risk Calculation: Based on the extension point dependency graph, the dependency paths associated with the changed extension points in the structural change set are retrieved, and the affected scope of differentiated business modules is calculated. If the affected scope includes deleted extension points, a high-risk block is generated. If the affected scope includes split extension points, a medium-risk drift is generated according to a preset locking strategy (e.g., strict mode is high-risk, lenient mode is medium-risk). If the affected scope includes modified extension points, medium-risk or low-risk is generated based on type compatibility. Specifically, if the modification causes type incompatibility, a medium-risk (adaptation required) is generated; if the modification is compatible, a low-risk pass is generated. If the affected scope does not hit any changed nodes, a low-risk pass is generated. The above steps utilize the computer's automated processing of code structure data (AST tree) to predict runtime errors before code execution. This avoids the situation in traditional methods where full regression testing is required to discover problems, significantly reducing the CPU load and memory usage of the test server, shortening the upgrade verification time, and achieving quantifiable control of upgrade risks.

[0044] Step S2-2: Determine the loading strategy based on the compatibility assessment results. When the loading strategy indicates that loading is accepted, create an isolated environment for the differentiated business modules to run independently, and inject the implementation declaration into the corresponding controlled extension point.

[0045] Specifically, based on the compatibility assessment results, a loading strategy is determined. When the loading strategy indicates that loading is accepted, an isolated environment for independently running differentiated business modules is created, including: Step S2-2-1: When the compatibility assessment result is low-risk and allows passage, the loading strategy is determined to be direct migration. An isolated environment is created in the target running instance that has the target version model loaded, and the differentiated business modules are loaded directly. Step S2-2-2: When the compatibility assessment result is medium-risk drift or medium risk, determine the loading strategy as drift migration, create an isolated environment for independent operation in the target running instance with the target version model loaded, and load the differentiated business module after redirecting the extension point path. Step S2-2-3: When the compatibility assessment result is high-risk blocking, determine the loading policy as reject loading, refuse to create an isolated environment for independent operation, and generate alarm information.

[0046] The above describes the logical choices made under different compatibility assessment results, including three scenarios: steps S2-2-1, S2-2-2, and S2-2-3. However, the specific technical means for building an independently running isolated environment are not specified. Therefore, they will be described in detail below: The first approach involves constructing an independently operating, isolated environment. This includes: building a three-tier class loader structure comprising a base layer, an industry layer, and a proxy layer; loading base public classes and extension point interfaces through the class loader corresponding to the base layer; loading private class libraries for differentiated business modules through the class loader corresponding to the industry layer, and configuring a hybrid delegation mechanism: parent-first delegation for base public classes and child-first self-checking for private class libraries to achieve memory space isolation and ensure type consistency; and dynamically generating extension point proxy classes through the proxy layer to route implementation declarations to the class loader corresponding to the industry layer.

[0047] The first approach leverages the namespace isolation feature of class loaders to ensure system stability. It solves the traditional problem of a single plugin error causing the entire process to crash; memory leaks only affect the sandbox area. The proxy layer enables transparent calls, reducing coupling. The hybrid delegation mechanism ensures that industry packages can access the base interface (type consistency) without polluting the base memory space (isolation).

[0048] The second approach involves building an independently running isolated environment, which specifically includes: starting an independent container process or virtual machine instance as an independently running isolated environment; and establishing a communication connection between the container process and the basic service platform through inter-process communication protocols or remote procedure call protocols.

[0049] The second approach offers an alternative isolation method. Instead of using the Java ClassLoader, it launches independent Docker containers or virtual machine instances as isolated runtime environments. Each container has its own independent process space, file system, and network stack. Inter-process communication between the base service platform and the industry package containers is achieved via gRPC or HTTP / RPC. This is suitable for multi-language mixed scenarios (e.g., a Java-based platform with Python industry packages), further enhancing system compatibility and resource isolation levels. Process-level isolation is more thorough than class loader isolation, preventing single-language runtime failures from affecting the entire system and enhancing system robustness.

[0050] Specifically, step S2-2 above includes: Low-risk handling: Create an isolated environment to run independently within the target instance that has the target version model loaded, and directly load the differentiated business modules.

[0051] Medium-risk handling: Trigger the environment upgrade and switchover process, and perform path redirection mapping in the target running instance.

[0052] High-risk handling: Refuse to create an isolated, independently running environment and generate alarm information (such as sending emails or text messages to operations and maintenance personnel).

[0053] Isolation Build: Builds a three-level class loader structure that includes a base layer, an industry layer, and a proxy layer.

[0054] The base class loader loads common class libraries and is visible to all industry packages.

[0055] Industry Layer (IndustryPackClassLoader): Loads private class libraries for differentiated business modules, configuring a hybrid delegation mechanism: parent-first delegation for base public classes, and child-first self-checking for private class libraries. The memory increment for a single sandbox instance is approximately 8-15MB.

[0056] Proxy layer (ProxyClassLoader): Dynamically generates extension point proxy classes, routing implementation declarations to the corresponding class loader in the industry layer. Extension point proxy calls incur an additional overhead of ≤50 microseconds.

[0057] The above steps leverage the namespace isolation feature of class loaders to ensure system stability. This solves the traditional problem of a single plugin error causing the entire process to crash; memory leaks only affect the sandbox area; and the proxy layer enables transparent calls, reducing coupling.

[0058] Further, step S2-2-2: Trigger the environment upgrade and switching process, and build a target running instance loaded with the target version model, specifically including: Control the currently running instance to serialize and save the internal business runtime state, and generate a state snapshot; Start the target running instance loaded with the target version model, and inject the deserialized state snapshot into the target running instance to restore the business runtime state; By using an atomic traffic switching switch, the routing target of business requests is changed from the current running instance to the target running instance; Monitor the anomaly rate within the preset time window after the switch, and if it exceeds the threshold, roll back to the currently running instance.

[0059] Specifically, it includes: Snapshot saving: Controls the serialization and saving of the internal runtime state of the currently running instance (such as Session, queue, extension point registry, cache) to generate a state snapshot. The snapshot content uses a whitelist mechanism to automatically filter non-migratable resources such as local file handles and socket connections. The typical snapshot size is 5-20MB, and the time taken is approximately 80-200ms.

[0060] New environment startup: Starts the target running instance loaded with the target version model, injects the deserialized state snapshot, and restores the business runtime state. The new sandbox warm-up takes approximately 1.2-1.8 seconds.

[0061] Atomic switching: By using atomic traffic switching switches (such as Nginx Upstream configuration updates or CAS atomic operations), the routing target of business requests is changed from the current running instance to the target running instance. The switching window is ≤10ms.

[0062] Rollback monitoring: Monitor the anomaly rate within a preset time window (e.g., 30 seconds) after the switch. If the rate exceeds the threshold (e.g., 1%), automatically roll back to the currently running instance.

[0063] The above steps achieve zero service interruption. Traditional upgrades require service downtime for maintenance; this solution improves the real-time performance of data processing through memory state transfer and network routing switching. The rollback mechanism further ensures the security of the upgrade process, preventing service unavailability caused by the spread of faulty versions.

[0064] In some preferred embodiments, step S3, which utilizes a conflict arbitration mechanism in conjunction with the request context to determine the target extension definition, includes: Parse the user's industry affiliation identifier from the request context; The system queries the extension point registry. When multiple extension definitions matching the same controlled extension point exist, a preset priority strategy is obtained. The preset priority strategy includes an industry-dominant strategy, a base-dominant strategy, and a merging strategy. When the preset priority strategy is an industry-dominant strategy, the extension definition corresponding to the user's industry affiliation is matched as the target extension definition. When the preset priority strategy is a base-dominant strategy or a merging strategy, the extension definition with the highest priority is selected as the target extension definition. The arbitration result is cached in the memory cache table, and subsequent identical requests will directly hit the cache.

[0065] Specifically, this embodiment includes the following steps: Context parsing: The arbitration execution module parses the user's industry affiliation identifier (such as Industry-Type) in the request header.

[0066] Priority arbitration: The extension point registry is queried. When multiple extension definitions match the same controlled extension point, a preset priority strategy is used to select the correct one. Strategies include: industry_dominant (industry-dominant, selects based on tenant industry), base_dominant (base-dominant, reverts to the original base definition), and merge (merges, prioritizes the highest priority in case of field conflicts). When the strategy is industry-dominant, the parsed industry affiliation identifier is used directly for matching, rather than simply comparing priority values.

[0067] Cache optimization: Cache the arbitration result in an in-memory cache table (such as ConcurrentHashMap + segmented lock), so subsequent identical requests will directly hit the cache, with a cache hit rate of approximately 99%. Execution: Execute the business logic corresponding to the target extension definition in an independently running isolated environment.

[0068] In the above steps, the extended dependency graph is used not only for loading but also for dependency chain resolution during conflict arbitration. Context-based dynamic routing avoids logical breaks caused by blind overriding and reduces the waste of resources due to repeated computation caused by business logic errors. The caching mechanism further reduces the CPU consumption of the arbitration process.

[0069] In summary, this application achieves significant technical effects through a specific computer internal resource processing flow, specifically manifested as follows: ① An automated closed loop of "prediction-decision-execution": This application uses AST analysis results as control signals to directly drive the sandbox's loading and migration strategies (such as high-risk blocking and medium-risk migration). This deep coupling of data flow and control flow produces a synergistic effect, solving the technical problem of uncontrollable upgrade risks in traditional solutions.

[0070] ② Combination of fine-grained isolation and lossless state transfer: This application maintains strong isolation (stability) during runtime and achieves lossless state transfer (continuity) by using "serialized snapshot + independent sandbox preheating", thus balancing the two contradictory technical requirements of "isolation" and "continuity".

[0071] ③ Dynamic conflict arbitration mechanism: An arbitration mechanism based on request context and priority is introduced, combined with cache optimization, to solve the expansion conflict problem in multi-tenant scenarios and improve system response speed.

[0072] ④ Enhanced logical consistency: The migration strategy for different risk levels in the context of base upgrade is clarified, avoiding the logical contradiction of "compatibility without upgrade"; the description of class loading mechanism is revised to ensure the unity of type consistency and isolation.

[0073] The following example, using a shared platform for the mold and injection molding industries, illustrates the application effects of this invention. Application Background: An industrial internet platform needs to simultaneously support the MES / APS platforms of both the mold manufacturing and injection molding industries. The two industries share 80% of their business logic in modules such as work order management, BOM management, and process management, but each has 20% differentiated requirements: the mold industry requires electrode management, cavity / core BOM structure, and EDM / 3D printing processes; the injection molding industry requires mold flow analysis, material proportioning management, and injection / blow molding / extrusion processes. Furthermore, the mold industry's process routes are updated on average every quarter, requiring the platform to support the smooth evolution of base process nodes. Traditional solutions involve developing separate systems for each industry, resulting in a code reuse rate of approximately 30% and high maintenance costs.

[0074] The implementation results show that by adopting the industry model inheritance method of this invention, 80% of the common logic is extracted to form a universal base, while each of the two industries develops a 20% differentiated industry package. The total code volume is: 12,000 lines for the base + 1,000 lines for the mold industry package + 1,000 lines for the injection molding industry package = 14,000 lines, which is about 53% less than the 30,000 lines of the traditional solution (15,000 lines for each industry). When the base is upgraded, conflict detection automatically identifies the affected industry packages, and only the marked parts need to be repaired, shortening the upgrade cycle from 14 days to 2 days. When a new equipment industry is added, only the equipment industry package (about 1,000 lines of code) needs to be developed, which can be completed within 1 week, while the traditional solution requires the independent development of a complete system (about 15,000 lines of code, taking 3 months). The three industries share the base, the code reuse rate is about 80%, and the maintenance cost is significantly reduced.

[0075] Key technical indicators comparison: In the actual operation of MES platforms in the mold / injection molding / equipment industries, the key indicators of this invention and traditional solutions are compared as follows: The development time for the work order module is approximately 90 person-days across three industries using the traditional solution, while this invention requires approximately 36 person-days, a reduction of 60%. Code reuse rate: Traditional solutions are about 30%, while this invention is about 80%; Base quarterly upgrade regression coverage: Traditional solution 100% (full regression required), this invention approximately 20% (only HIGH / MEDIUM extension points regression); Base upgrade and deployment cycle: Traditional solution: about 14 days, this invention: about 2 days; Business downtime window: Traditional solution: 2-4 hours, this invention: 0 (sandbox hot migration). New industry deployment cycle: Traditional solutions take approximately 3 months, this invention takes approximately 1 week. Platform single instance memory usage: Traditional monolithic solutions (three-industry integrated deployment) are approximately 1.2GB, while this invention (base + three-industry package) is approximately 0.8GB, a reduction of approximately 33%. Industry package hot reloading latency: Traditional plugin / monolithic mode does not support runtime hot reloading. The hot reloading of a single industry package (including class loading + extension point registration) in this invention takes about 1.5 seconds, enabling dynamic expansion without downtime 24 / 7. Number of defects introduced by base upgrade: Traditional solutions introduce approximately 8 regression defects per upgrade due to full-scale modification, while this invention introduces approximately 1 defect per upgrade by only fixing HIGH / MEDIUM level extension points, reducing the number by approximately 87%; Extension point conflict resolution time: Traditional solutions require manual intervention for multi-industry plug-in conflicts, which takes an average of about 2-4 hours. The conflict arbitrator of this invention automatically processes the conflict in about 30 microseconds (when the cache is hit).

[0076] Thirdly, this application provides an industry model differentiation extension device based on product package decoupling. The industry model differentiation extension device based on product package decoupling can be a personal computer (PC), laptop computer, server, or other device with data processing capabilities.

[0077] In this embodiment of the application, the industry model differentiation extension device based on product package decoupling may include a processor, memory, communication interface, and communication bus.

[0078] The communication bus can be of any type and is used to interconnect the processor, memory, and communication interface.

[0079] Communication interfaces include input / output (I / O) interfaces, physical interfaces, and logical interfaces used for interconnecting devices within the product-package-decoupled industry-model differentiated expansion device, as well as interfaces used for interconnecting the product-package-decoupled industry-model differentiated expansion device with other devices (such as other computing devices or user equipment). Physical interfaces can be Ethernet interfaces, fiber optic interfaces, ATM interfaces, etc.; user equipment can be displays, keyboards, etc.

[0080] Memory can be various types of storage media, such as random access memory (RAM), read-only memory (ROM), non-volatile RAM (NVRAM), flash memory, optical storage, hard disk, programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), etc.

[0081] The processor can be a general-purpose processor, which can call the industry model differentiation extension program based on product package decoupling stored in memory and execute the industry model differentiation extension method based on product package decoupling provided in the embodiments of this application. For example, the general-purpose processor can be a central processing unit (CPU). The method executed when the industry model differentiation extension program based on product package decoupling is called can be referred to the various embodiments of the industry model differentiation extension method based on product package decoupling in this application, and will not be repeated here.

[0082] Fourthly, embodiments of this application also provide a computer-readable storage medium.

[0083] The present application stores an industry model differentiation extension program based on product package decoupling on a computer-readable storage medium, wherein when the industry model differentiation extension program based on product package decoupling is executed by a processor, it implements the steps of the industry model differentiation extension method based on product package decoupling as described above.

[0084] The method implemented when the industry model differentiation extension program based on product package decoupling is executed can be referred to in the various embodiments of the industry model differentiation extension method based on product package decoupling in this application, and will not be repeated here.

[0085] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0086] The terms "comprising" and "having," and any variations thereof, in the specification, claims, and accompanying drawings of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus. The terms "first," "second," and "third," etc., are used to distinguish different objects, etc., and do not indicate a sequence, nor do they limit "first," "second," and "third" to different types.

[0087] In the description of the embodiments of this application, terms such as "exemplary," "for example," or "for instance" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplary," "for example," or "for instance" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or designs. Specifically, the use of terms such as "exemplary," "for example," or "for instance" is intended to present the relevant concepts in a concrete manner.

[0088] In the description of the embodiments of this application, unless otherwise stated, " / " means "or". For example, A / B can mean A or B. The "and / or" in the text is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can mean: A exists alone, A and B exist simultaneously, and B exists alone. In addition, in the description of the embodiments of this application, "multiple" means two or more.

[0089] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0090] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0091] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for differentiated extension of industry models based on product package decoupling, characterized in that, It includes: Obtain the current running instance and target version model of the basic service platform, which has controlled extension points defined based on a preset design pattern; Receive the dependency configuration of the differentiated business module, wherein the dependency configuration includes the implementation declaration of the controlled extension point, the base version compatibility range and the extension point locking strategy; The interface model of the currently running instance is compared with the target version model, and a compatibility assessment result is generated in combination with the dependency configuration; a loading strategy is determined based on the compatibility assessment result; when the loading strategy indicates that loading is accepted, an isolated environment for independent operation is created for the differentiated business module, and the implementation declaration is injected into the corresponding controlled extension point; Respond to business requests and parse the request context; When multiple implementation declarations of the same controlled extension point are detected, the target extension definition is determined by using a conflict arbitration mechanism in conjunction with the request context, and the target extension definition is executed in the independently running isolated environment.

2. The industry model differentiation extension method based on product package decoupling as described in claim 1, characterized in that, The interface model of the currently running instance is compared with the target version model, and a compatibility assessment result is generated based on the dependency configuration, specifically including: Parse the dependency configuration and construct an extension point dependency graph containing the mapping relationship between the differentiated business modules and the controlled extension points; Using an abstract syntax tree comparison algorithm, a structural difference analysis is performed on the interface model of the current running instance and the target version model to identify the changed extension points and generate a structural change set. The types of changes in the structural change set include extension point addition, extension point deletion, extension point modification, extension point renaming, extension point splitting, and extension point merging. Based on the extension point dependency graph, the dependency paths associated with the changed extension points in the structural change set are retrieved, the affected scope of the differentiated business modules is calculated, and the compatibility assessment result is generated according to the affected scope and the extension point locking strategy.

3. The industry model differentiation extension method based on product package decoupling as described in claim 2, characterized in that, The compatibility assessment result is generated based on the affected scope and the expansion point locking strategy, specifically including: A high-risk block is generated when the affected area includes the deleted extension point; When the affected range includes the split expansion point, if the expansion point locking strategy is strict locking, a high-risk block is generated; if the expansion point locking strategy is loose locking, a medium-risk drift is generated, and automatic mapping to the split equivalent child node is configured. When the affected scope includes the modified extension point, if the modification results in type incompatibility, a medium-risk pass is generated; if the modification is compatible, a low-risk pass is generated. A low-risk passage is generated when the affected area does not hit any change node.

4. The industry model differentiation extension method based on product package decoupling as described in claim 3, characterized in that, Based on the compatibility assessment results, a loading strategy is determined. When the loading strategy indicates that loading is accepted, an isolated environment for the differentiated business modules is created to run independently. Specifically, this includes: When the compatibility assessment result is low-risk and allows passage, the loading strategy is determined to be direct migration. An isolated environment is created in the target running instance that has the target version model loaded, and the differentiated business module is loaded directly. When the compatibility assessment result is medium-risk drift, the loading strategy is determined to be drift migration. An isolated environment is created in the target running instance that loads the target version model, and the differentiated business module is loaded after the extension point path is redirected and mapped. When the compatibility assessment result is high-risk blocking, the loading strategy is determined to be to refuse loading, refuse to create an isolated environment for independent operation, and generate alarm information.

5. The industry model differentiation extension method based on product package decoupling as described in claim 4, characterized in that: Create an isolated, independently running environment within the target running instance that loads the target version model, specifically including triggering an environment upgrade and switching process; triggering the environment upgrade and switching process specifically includes: The system controls the currently running instance to serialize and save the internal business runtime state, generating a state snapshot; the state snapshot filters out non-migratable resources. Start the target running instance loaded with the target version model, and inject the deserialized state snapshot into the target running instance to restore the business runtime state; By using an atomic traffic switching switch, the routing target of the service request is changed from the currently running instance to the target running instance; Monitor the anomaly rate within the preset time window after switching, and if it exceeds the threshold, roll back to the currently running instance.

6. The industry model differentiation extension method based on product package decoupling as described in claim 1, characterized in that, Creating an isolated, independently operating environment includes: Construct a three-level class loader structure that includes a base layer, an industry layer, and a proxy layer; The base public classes and extension point interfaces are loaded through the class loader corresponding to the base layer. The private class library of the differentiated business module is loaded through the class loader corresponding to the industry layer, and a hybrid delegation mechanism is configured: parent priority delegation is adopted for the base public class, and child priority self-check is adopted for the private class library, so as to achieve memory space isolation and ensure type consistency. The proxy layer dynamically generates extension point proxy classes, routes the implementation declaration to the class loader corresponding to the industry layer, and inserts conflict arbitration logic before and after the call.

7. The industry model differentiation extension method based on product package decoupling as described in claim 1, characterized in that: The dependency configuration is a declarative inheritance manifest, in YAML or JSON format, containing extension point type definitions; the extension point types include field extension points, association extension points, rule overriding points, and event interception points.

8. The industry model differentiation extension method based on product package decoupling as described in claim 1, characterized in that, Receive the dependency configuration of differentiated business modules, which includes: Dependency data is read from a pre-defined relational database table. This dependency data includes module identifiers, platform version numbers, and extension point priorities; or... Parse the independently stored configuration file and obtain the dependent configuration.

9. The industry model differentiation extension method based on product package decoupling as described in claim 1, characterized in that, The target extension definition is determined using a conflict arbitration mechanism in conjunction with the request context, including: Parse the user's industry affiliation identifier in the request context; Query the extension point registry. When multiple extension definitions match the same controlled extension point, obtain a preset priority strategy. The preset priority strategy includes an industry-dominant strategy, a base-dominant strategy, and a merging strategy. When the preset priority strategy is an industry-led strategy, the extended definition of the corresponding industry is matched based on the user's industry affiliation identifier as the target extended definition. When the preset priority strategy is a base-dominated strategy or a merging strategy, the extension definition with the highest priority is selected as the target extension definition; The arbitration result is cached in an in-memory cache table, so subsequent identical requests will directly hit the cache.

10. An industry model differentiation extension system based on product package decoupling, characterized in that, It includes: The basic service module is used to provide controlled extension points based on preset design pattern definitions; A configuration receiving module is configured to receive the dependency configuration of the differentiated business module, wherein the dependency configuration includes the implementation declaration of the controlled extension point; The compatibility analysis module is used to compare the interface model of the currently running instance with the target version model, and generate a compatibility evaluation result in combination with the dependency configuration; An isolation loading module is used to determine a loading strategy based on the compatibility assessment results. When the loading strategy indicates that loading is accepted, an isolated environment for the differentiated business module to run independently is created, and the implementation declaration is injected into the corresponding controlled extension point. The arbitration execution module is used to respond to business requests, parse the request context, and when multiple implementation declarations of the same controlled extension point are detected, it uses a conflict arbitration mechanism in conjunction with the request context to determine the target extension definition and executes the target extension definition in the independently running isolated environment.

Images