Method, device and equipment for performing integrated optimization on multiple heterogeneous systems

Abstract

The embodiment of the invention provides a method, a device and equipment for performing integrated optimization on a plurality of heterogeneous systems. The method comprises the following steps: in response to a received system integration instruction, decomposing and comparing a plurality of heterogeneous systems to be integrated and optimized to establish a unified function meta-model, and integrating according to the function meta-model to obtain a core function module; calling a meta-model compiler to compile the function meta-model into a system description file, verifying the dependency relationship of the core function module according to the system description file, and generating a modular design rule; performing micro-service segmentation on the core function module by utilizing a modular design rule to obtain a plurality of micro-services, and packaging each micro-service into an independent container mirror image; and calling a container arrangement platform, and performing integrated deployment and treatment on each independent container mirror image according to a modular design rule to generate a cloud native integrated system. By utilizing the method disclosed by the embodiment of the invention, more reliable and efficient integrated experience can be provided for the user.

Description

Technical Field

[0001] This disclosure relates to the field of system integration optimization technology, specifically to a method, apparatus, and equipment for integrating and optimizing multiple heterogeneous systems. Background Technology

[0002] As enterprises deepen their IT infrastructure development, the need to integrate multiple heterogeneous systems is becoming increasingly urgent. System integration aims to combine independent software, hardware, network, and other subsystems into a comprehensive system that operates in a coordinated manner and achieves optimal overall performance, thereby realizing resource sharing and functional synergy.

[0003] Currently, the industry commonly uses integration technologies including monolithic architecture integration, traditional service-oriented architecture (SOA), traditional distributed architecture, preliminary microservice architecture, and traditional cloud platform integration. However, these existing solutions all have significant limitations in practical applications: monolithic architectures have high coupling and poor scalability; traditional SOA relies on a centralized enterprise service bus (ESB), which easily leads to performance bottlenecks and coarse-grained service; traditional distributed architectures are complex to operate and maintain, lack effective fault tolerance and dynamic scaling capabilities; preliminary microservice architectures face challenges in service boundary planning and high operational complexity in integration scenarios; and traditional cloud platform integration lacks high-level abstraction of system functions, making it difficult to clearly define functional boundaries and posing a risk of platform lock-in.

[0004] In summary, existing technologies have three main common defects: First, the blurred functional boundaries lead to functional redundancy and conflicts within the system, affecting overall efficiency; second, the architecture lacks flexibility and is difficult to adapt to rapid business changes; and third, centralized communication components or rigid architectures are prone to performance bottlenecks. Summary of the Invention

[0005] To address the aforementioned technical problems, the solutions disclosed herein are proposed. Embodiments of this disclosure provide a method, apparatus, and device for integrating and optimizing multiple heterogeneous systems.

[0006] According to a first aspect of the present disclosure, a method for integrating and optimizing multiple heterogeneous systems is provided, wherein the method includes: In response to receiving a system integration instruction, the system decomposes and compares multiple heterogeneous systems to be integrated and optimized in order to establish a unified functional meta-model, and integrates the core functional modules based on the functional meta-model. The metamodel compiler is invoked to compile the functional metamodel into a system description file, and the dependencies of the core functional modules are verified based on the system description file to generate modular design rules. Using the modular design rules, the core functional module is divided into multiple microservices, and each microservice is packaged into an independent container image. The container orchestration platform is invoked to deploy and manage each independent container image in an integrated manner according to the modular design rules, thereby generating a cloud-native integrated system with elastic scaling and intelligent traffic management capabilities.

[0007] According to a second aspect of the present disclosure, an apparatus is provided for integrating and optimizing multiple heterogeneous systems, wherein the apparatus includes: The meta-model creation unit is configured to: in response to receiving a system integration instruction, decompose and compare multiple heterogeneous systems to be integrated and optimized in order to establish a unified functional meta-model, and integrate the core functional modules according to the functional meta-model. The rule generation unit is configured to: call the metamodel compiler to compile the functional metamodel into a system description file, verify the dependency relationship of the core functional modules based on the system description file, and generate modular design rules; The microservice processing unit is configured to: use the modular design rules to perform microservice splitting on the core functional module to obtain multiple microservices, and package each microservice into an independent container image; The system integration unit is configured to: invoke the container orchestration platform, and according to the modular design rules, perform integrated deployment and governance of each independent container image to generate a cloud-native integrated system with elastic scaling and intelligent traffic management capabilities.

[0008] According to a third aspect of the present disclosure, an electronic device is provided, the electronic device comprising: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the method for integrating and optimizing multiple heterogeneous systems as described in the present disclosure.

[0009] According to a fourth aspect of the present disclosure, a computer-readable storage medium is provided, the storage medium storing a computer program for executing the method for integrating and optimizing multiple heterogeneous systems as described in the present disclosure.

[0010] According to a fifth aspect of the present disclosure, a computer program product is provided, including a computer program, wherein the computer program, when executed by a processor, implements the method for integrating and optimizing multiple heterogeneous systems as described in the present disclosure.

[0011] As described above, the method for integrating and optimizing multiple heterogeneous systems provided in this disclosure achieves significant beneficial technical effects through the deep integration of functional meta-modeling and cloud-native technologies. Specifically, this method effectively solves the common problems of functional overlap and redundancy in traditional system integration. By atomized decomposition and horizontal comparison, redundant nodes are identified and eliminated, thereby establishing a unified functional model. This clarifies the boundaries of system modules, improves the flexibility and adaptability of the overall architecture, and enables dynamic responses to business changes. Simultaneously, combined with containerized deployment and intelligent orchestration mechanisms, the system achieves efficient resource scheduling and service governance, enhances scalability and maintainability, ensures stable operation in complex environments, and ultimately provides users with a more reliable and efficient integration experience. Attached Figure Description

[0012] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0013] Figure 1 This is a flowchart illustrating a method for integrating and optimizing multiple heterogeneous systems, provided in an exemplary embodiment of this disclosure. Figure 2 This is a public announcement Figure 1 A schematic diagram of the framework structure of the intelligent production command platform system for railway equipment provided in the embodiment; Figure 3 This is a public announcement Figure 1 Another exemplary flowchart of the method for integrating and optimizing multiple heterogeneous systems provided in this embodiment; Figure 4 This is a public announcement Figure 1 This embodiment provides another exemplary flowchart of a method for integrating and optimizing multiple heterogeneous systems. Figure 5 This is a public announcement Figure 1 This embodiment provides another exemplary flowchart of a method for integrating and optimizing multiple heterogeneous systems. Figure 6 This is a public announcement Figure 1 This embodiment provides another exemplary flowchart of a method for integrating and optimizing multiple heterogeneous systems. Figure 7 This is a schematic diagram of the structure of an apparatus for integrating and optimizing multiple heterogeneous systems, provided in an exemplary embodiment of this disclosure; Figure 8This is a schematic diagram of the structure of one application embodiment of the electronic device disclosed herein. Detailed Implementation

[0014] The present disclosure will be further described below with reference to the embodiments shown in the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure. It should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0015] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0016] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0017] It should also be understood that in the embodiments disclosed herein, "multiple" can refer to two or more, and "at least one" can refer to one, two or more.

[0018] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0019] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0020] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0021] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0022] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0023] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0024] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0025] Overview of the inventive concept The core inventive concept of this disclosed technical solution lies in: using functional semantic abstraction and meta-modeling technology to atomically decompose and integrate heterogeneous systems, fundamentally eliminating functional redundancy and clarifying boundaries to form clear core functional modules; furthermore, by analyzing module dependencies to generate guiding design rules, scientifically dividing microservice boundaries and avoiding the blindness of traditional decomposition; finally, containerizing microservices and deploying and governing them in an integrated manner based on cloud-native technology stacks, and by integrating intelligent mechanisms such as real-time monitoring and predictive elastic scaling, achieving dynamic optimization of system resources and fine-grained control of traffic, thereby ultimately constructing a highly cohesive, loosely coupled cloud-native integrated system with elastic scaling and self-healing capabilities.

[0026] Based on the above-described inventive concept, this disclosure proposes a scheme for integrating and optimizing multiple heterogeneous systems as described in the following embodiments. Furthermore, it should be noted that, for ease of understanding, the following embodiments of this disclosure will be adaptively described using… Figure 2 The following explanation and description will use the railway equipment intelligent production command platform shown as an example. (Refer to...) Figure 2 The original intelligent production command platform for railway equipment had eight functional modules: "Centralized Management Platform for Freight Car Dispatch, Freight Car Status Monitoring and Maintenance System, Track Crossing Transportation Management System, Multi-T Integrated Management Platform, Railway Freight Car Beidou Positioning Integrated Management System, Dispatch Safety Emergency Command System, Construction Operation Video Monitoring System, and Industrial Video System." Through functional streamlining and integration using the scheme of this disclosed embodiment, these modules are clearly mapped into six functional modules, achieving system integration optimization.

[0027] Example 1 Figure 1 This is a schematic flowchart of a method for integrating and optimizing multiple heterogeneous systems, provided by an exemplary embodiment of this disclosure. The method can be executed on a server (e.g., a cloud service platform, a locally deployed server).

[0028] Specifically, refer to Figure 1 The method for integrating and optimizing multiple heterogeneous systems includes: S110. In response to receiving the system integration instruction, decompose and compare multiple heterogeneous systems to be integrated and optimized to establish a unified functional meta-model, and integrate the core functional modules according to the functional meta-model.

[0029] The "system integration command" can be a signal triggered by technicians through the management platform.

[0030] Step S110 involves atomizing and horizontally comparing the functions of the original eight systems to identify overlapping and redundant nodes (e.g., discovering that the "equipment fault diagnosis" function is repeatedly implemented in the equipment monitoring system, production safety system, and data platform, and that there are version conflicts in the diagnostic rules), thus establishing a unified functional meta-model. Based on this model, core functional modules are integrated, including a scheduling management module, a monitoring management module, an emergency management module, an operations management module, a video management module, and a large-screen management module, with the boundaries of each module defined. Specific implementation details are described below and will not be elaborated upon here.

[0031] S120. Call the meta-model compiler to compile the functional meta-model into a system description file, and verify the dependencies of the core functional modules based on the system description file to generate modular design rules.

[0032] This process involves using a metamodel compiler to convert the functional metamodel into a description file (such as YAML format), automatically adapting to heterogeneous protocols (e.g., integrating Modbus, OPCUA, and custom TCP), and eliminating code redundancy in legacy system interfaces. Based on the system description file, the dependencies between core functional modules are verified, and a directed acyclic graph is constructed to ensure that business processes are free of cyclical conflicts, generating modular design rules (including resource allocation strategies and communication protocols). Specific implementation details are described below and will not be elaborated upon here.

[0033] S130. Using the modular design rules, the core functional module is divided into multiple microservices, and each microservice is packaged into an independent container image.

[0034] This approach utilizes modular design principles to divide core functional modules into multiple microservices (e.g., splitting the scheduling management module into signal optimization and congestion detection microservices). For each microservice, a container building tool (such as Docker) is used to package the microservice code, dependencies, and configuration files into an independent container image. The image adopts a layered structure, with the base environment layer remaining fixed; code updates only require rebuilding the top layer. Specific implementation details are described below and will not be elaborated here.

[0035] S140. Invoke the container orchestration platform and, based on the modular design rules, deploy and manage each of the independent container images in an integrated manner to generate a cloud-native integrated system with elastic scaling and intelligent traffic management capabilities.

[0036] This involves using a container orchestration platform (such as Kubernetes) for integrated deployment and governance based on modular design rules. The number of replicas is defined through Deployment resources, and traffic routing and load balancing are achieved using a service mesh (such as Istio), generating a cloud-native integrated system with elastic scaling and intelligent traffic governance capabilities. For example, during peak periods for railway freight trains, the system automatically scales up the microservice instances to 10 replicas. Specific implementation details are described below and will not be elaborated upon here.

[0037] As described above, the method for integrating and optimizing multiple heterogeneous systems provided in this disclosure achieves significant beneficial technical effects through the deep integration of functional meta-modeling and cloud-native technologies. Specifically, this method effectively solves the common problems of functional overlap and redundancy in traditional system integration. By atomized decomposition and horizontal comparison, redundant nodes are identified and eliminated, thereby establishing a unified functional model. This clarifies the boundaries of system modules, improves the flexibility and adaptability of the overall architecture, and enables dynamic responses to business changes. Simultaneously, combined with containerized deployment and intelligent orchestration mechanisms, the system achieves efficient resource scheduling and service governance, enhances scalability and maintainability, ensures stable operation in complex environments, and ultimately provides users with a more reliable and efficient integration experience.

[0038] Example 2 Based on the above embodiment 1, as an optional implementation method, refer to Figure 3 Step S110, "In response to receiving a system integration instruction, decomposing and comparing multiple heterogeneous systems to be integrated and optimized to establish a unified functional meta-model, and integrating the core functional modules according to the functional meta-model," may include: S1110. In response to receiving the system integration instruction, based on functional semantics, interface contracts, resource constraints and behavioral rules, the functions of the multiple heterogeneous systems are atomically decomposed and horizontally compared to identify functional overlaps and redundant nodes, so as to establish the unified functional meta-model.

[0039] As an optional example, first, system integration instructions (such as trigger signals from the management platform) are parsed to identify the multiple heterogeneous systems to be integrated. Figure 2Taking the railway equipment intelligent production command platform as an example, the original eight systems include "freight car dispatching centralized management platform, freight car status monitoring and maintenance system, track crossing transportation management system, multi-T integrated management platform, railway freight car Beidou positioning integrated management system, dispatching safety and emergency command system, construction operation video monitoring system, and industrial video system". Based on functional semantics (such as the "equipment fault diagnosis" function), interface contracts (such as REST API or SOAP protocol), resource constraints (such as CPU and memory limits), and behavioral rules (such as concurrent processing logic), the functions of each system are atomically decomposed. Atomistic decomposition refers to breaking down each system function into the smallest independent unit. For example, the "vehicle trajectory analysis" function is decomposed into atomic operations such as data acquisition, trajectory calculation, and result output.

[0040] Subsequently, a horizontal comparison was conducted. Specifically, semantic graph analysis tools (such as natural language processing-based similarity calculation algorithms) were used to compare the semantic similarity of functional units in different systems. For example, the "equipment health assessment" function was identified as being implemented repeatedly in the equipment monitoring system, production safety system, and data platform, with conflicting diagnostic rule versions, thus marking it as a redundant node. Simultaneously, the consistency of interface contracts (such as the heterogeneity between HTTP and gRPC protocols), conflicts in resource constraints (such as exceeding memory allocation limits), and contradictions in behavioral rules (such as differences in timeout retry strategies) were examined. Finally, a unified functional meta-model was established, defined using a meta-model language (such as MOF), containing the attributes, relationships, and constraints of functional modules, providing a foundation for subsequent integration.

[0041] Understandably, by using atomized decomposition and horizontal comparison, functional redundancy and conflicts are eliminated, providing a clear functional view for system integration and improving the accuracy and efficiency of subsequent module integration.

[0042] S1120. Redundancy quantification is performed on the functional modules in the functional meta-model, and functional modules whose functional semantic similarity meets the preset similarity judgment conditions and whose resource requirements are coordinated are merged and integrated into a specified number of core functional modules, while defining the boundary of each core functional module.

[0043] As an optional example, based on the functional meta-model established in S1110, redundancy quantification is first performed. Specifically, the semantic similarity between functional modules is calculated using a cosine similarity algorithm, with a preset similarity threshold of 0.8 (i.e., modules with a similarity ≥ 0.8 are considered semantically similar). For example, in the railway platform scenario, the "material completeness calculation" function has algorithmic differences between the supply chain system and the production planning system. Quantification reveals a similarity of 0.75, which is below the threshold, so it is not merged; while the "equipment monitoring" and "status alarm" functions have a similarity of 0.9, meeting the condition. Simultaneously, the synergy of resource requirements is evaluated, such as whether the usage patterns of CPU, memory, and network bandwidth are compatible (e.g., both modules require high memory and can share a cache).

[0044] Next, modules with similar semantics and collaborative resources are merged. Specifically, a metamodel compiler (such as a custom tool based on the Eclipse Modeling Framework) is invoked to convert the functional metamodel into a description file (YAML or JSON format), automatically performing the merging operation. For example, the scattered "video acquisition" function is merged from the construction operation video monitoring system and the industrial video system into a core video management module. After integration, the number of core functional modules is specified as 6 (such as a scheduling management module, a monitoring management module, an emergency management module, etc.), and the boundaries of each module are defined: clearly defining the module's responsibilities (e.g., the video management module is only responsible for video acquisition and analysis), data ownership (e.g., an independent database instance), and the scope of interaction. During the process, the dependencies between modules are verified based on a directed acyclic graph (DAG) to ensure no circular conflicts, such as eliminating the circular dependency chain between process quality control and production planning scheduling.

[0045] Understandably, by quantifying redundancy and intelligently merging, the number of modules is reduced, functional overlap is avoided, and system simplicity and resource utilization are improved. At the same time, boundary delineation enhances the independence and maintainability of modules.

[0046] S1130. Define a unified interface contract, resource usage threshold, and exception handling rules for each core functional module.

[0047] As an optional example, for each core functional module integrated into S1120 (such as the scheduling management module and the video management module), a unified interface contract is first defined. Specifically, a standardized protocol (such as RESTful API or gRPC) is adopted to formulate interface specifications, including request formats (such as JSON data fields and error code definitions), transport protocols (HTTP / HTTPS or lightweight RPC), and response rules (such as status codes and data structures). For example, an interface contract is defined for the video management module, including a video stream acquisition interface (GET / api / video / stream) and data format (H264 encoding).

[0048] Secondly, set resource usage thresholds. Specifically, based on historical monitoring data or performance tests, assign resource constraints to each module, such as CPU utilization threshold ≤70%, memory usage threshold ≤2GB, and network bandwidth threshold ≤100Mbps. These thresholds ensure that the system will not become unstable due to resource contention during module operation. Simultaneously, define exception handling rules. Specifically, this includes error handling mechanisms (such as 3 timeout retries, circuit breaker triggered after 5 consecutive failures), fault recovery processes (such as automatically restarting container instances), and logging standards (such as reporting error logs to a centralized logging system). For example, set exception rules for the emergency management module: when handling an incident response, if a 5-second timeout occurs, automatically switch to a standby instance.

[0049] Ultimately, these definitions are solidified through configuration files (such as OpenAPI specification files) or code annotations and integrated into the containerized deployment process, ensuring that each microservice instance loads these rules at startup.

[0050] Understandably, a unified interface contract improves system interoperability and consistency, while resource thresholds and exception rules enhance system reliability and resilience, reduce runtime failures, and improve overall service quality.

[0051] Example 3 Based on the above embodiments 1 and 2, as an optional implementation, the step S120 of "calling the metamodel compiler to compile the functional metamodel into a system description file" can be implemented in the following way: I1. Input and Initialization. Specifically, first, the functional metamodel (defined based on MOF or a similar metamodel language) includes the attributes, semantic relationships, interface contracts, and resource constraints of functional modules. For example, in Figure 2In the scenario of the intelligent production command platform for railway equipment shown, the functional meta-model integrates the functional units of eight major systems (such as the "equipment health assessment" service). Then, the meta-model compiler (such as a custom development tool based on the Eclipse Modeling Framework) is called to configure compilation parameters (such as target format YAML and protocol adaptation rules).

[0052] I2. Compilation and Transformation. Specifically, first, the compiler parses the semantic elements of the functional metamodel (such as function name, input / output parameters, and behavioral rules) and maps them to an intermediate representation (IR). For example, the semantic tags of the "video capture" function (such as resolution and frame rate) are transformed into a standardized data structure. Then, the intermediate representation is compiled into a system description file (YAML or JSON format). This system description file contains: module definitions—meta-information of core functional modules (such as name, version, and responsibilities); interface specifications—unified interface contracts (such as REST endpoints and gRPC service definitions), i.e., "exposing a unified interface contract to the outside world"; resource constraints—CPU and memory usage thresholds (such as CPU ≤ 70%, memory ≤ 2GB); and dependencies—inter-module call chains and data flows (used for subsequent DAG verification). For example, in the case of... Figure 2 In the intelligent production command platform for railway equipment shown, the system description file clearly states that the interface for the scheduling management module is GET / api / schedule, and the resource limit is 1GB of memory.

[0053] I3. Automatic Adaptation of Heterogeneous Protocols. Specifically, first, the compiler integrates protocol conversion plugins (such as a SOAP-to-REST converter) to automatically handle heterogeneous protocols from legacy systems (such as Modbus, OPC UA, and custom TCP). For example, it converts the custom TCP protocol of a truck status monitoring system to a standard HTTP interface, eliminating code redundancy during integration; for example, "eliminating code redundancy in legacy system integration." Then, it outputs the adapted system description file, ensuring that all module interfaces are in a unified, interoperable format.

[0054] Understandably, automated protocol adaptation reduces manual coding workload and improves development efficiency (e.g., eliminating code redundancy in legacy system integration). System description files ensure consistency between functional semantics and technical implementation, avoiding runtime ambiguity. Machine-readable description files support version control and dynamic updates, laying the foundation for subsequent flexible deployment. Automated compilation processes reduce manual intervention and shorten the overall integration cycle.

[0055] Based on the above implementation method, as another optional implementation method, refer to Figure 4 Step S120, "Verifying the dependencies of the core functional modules according to the system description file and generating modular design rules," may include: S1210. Based on the system description file, analyze the call and data dependency relationships between the core functional modules to obtain the dependency analysis results.

[0056] As an optional example, step S1210 can be implemented as follows: First, based on the system description file, a directed acyclic graph representing module dependencies is constructed; second, in response to verifying by traversing the directed acyclic graph that there are no circular dependency conflicts in the business processes between the core functional modules, the modular design rule is determined to be reasonable. The specific implementation process includes: 1) Input and Parsing. First, the system description file, generated by the metamodel compiler, contains the interface contracts, resource constraints, and dependency information of the core functional modules. For example, in the scenario of a smart production command platform for railway equipment, the description file defines the metadata of six core modules, including the scheduling management module and the monitoring management module. Then, a parsing tool (such as a YAML parsing library or a custom JSON parser) loads the description file to extract the call relationships between modules (such as module A calling module B's API endpoint) and data dependencies (such as modules sharing database tables or message queues). The parser transforms the dependencies into structured data, such as adjacency lists or matrices, for easier subsequent analysis.

[0057] 2) Construct a Directed Acyclic Graph (DAG). Specifically, based on the analysis results, construct a DAG to represent module dependencies. Nodes in the graph represent core functional modules (such as the "Video Management Module"), and edges represent the direction of dependency (such as the "Emergency Management Module" depending on the data output of the "Data Aggregation Module"). Use graph building tools (such as the NetworkX library or a custom graph engine) to ensure that edge weights include call frequency and data sharing degree. For example, in a railway platform, the DAG might show the "Freight Freight Dispatch Centralized Management System" module calling real-time data from the "Vehicle Monitoring Module," but without reverse dependencies, thus avoiding cycles.

[0058] 3) Traverse and verify for circular dependencies. First, use Depth-First Search (DFS) or topology sorting algorithm to traverse the DAG and check for circular dependencies (e.g., module A→B→C→A). If no circular path is found during the traversal (i.e., the topology sorting is successful), the modular design rules are considered reasonable; if a cycle is found, an error is thrown and the conflicting path is identified. Second, if a cycle is detected (e.g., a circular dependency between process quality control and production planning scheduling), the system outputs a detailed report, suggesting adjustments to module boundaries or the insertion of an intermediate layer (e.g., a cache service), and recompiling the description file.

[0059] 4) Output dependency analysis results. Specifically, first, generate an analysis report in JSON or XML format, including: a dependency matrix (to display the frequency of calls and the degree of data sharing between modules), a loop detection log (marked as "verification passed" if there are no loops; otherwise, listing conflicting modules), and a behavioral coupling factor (used to quantify the coupling degree between modules; for example, a value ≤0.3 indicates low coupling, conforming to microservice principles)). Then, the analysis results are stored in the configuration management database (CMDB) for use in subsequent steps.

[0060] S1220. Based on the analysis results of the dependencies, generate rules for guiding the division of domain boundaries between microservice splitting modules, and resource constraint rules and behavior constraint rules for guiding system architecture planning.

[0061] As an optional example, step S1220 can be implemented as follows: First, based on coupling metrics (such as call frequency and data sharing degree) from dependency analysis results, delineate microservice domain boundaries. For example, highly coupled modules (e.g., call frequency > 1000 times / second) are merged into a single microservice, while loosely coupled modules are deployed independently. Output a domain boundary rule file (YAML format) that clearly defines the responsibilities and boundaries of each microservice. For instance, Rule 1 assigns the scheduling management module and the monitoring management module to the same domain context due to their high data sharing degree (sharing rate ≥ 80%). Rule 2 designates the video management module as an independent microservice because of its low behavioral coupling factor (≤ 0.3).

[0062] Secondly, resource constraints (such as CPU and memory thresholds) are extracted from the system description file and combined with load characteristics from dependency analysis (such as high-frequency modules requiring more resources) to generate resource allocation rules. For example, for high-load modules (such as real-time data processing), the CPU request value is set to ≥1 core, and the limit value is ≤2 cores; or, for data-intensive modules, the memory limit is set to ≤4GB. Additionally, a Kubernetes resource manifest (such as Deployment YAML) is generated and integrated into the container orchestration configuration.

[0063] Secondly, define interaction constraints between microservices based on the behavioral rules in the dependencies (such as timeout retries and circuit breaking mechanisms). For example, for high-frequency call interfaces (such as trajectory queries), set rate limiting rules (≤1000 requests / second); define circuit breaking strategies (such as triggering degradation after 5 consecutive failures) and retry logic (giving up after 3 timeouts); and write the behavioral rules into the service mesh configuration (such as Istio VirtualService) to ensure that they are enforced at runtime.

[0064] Finally, execute rule validation and optimization. Specifically, use a rule engine (such as Drools) to check rule consistency and avoid conflicts. Deploy microservices in a sandbox environment to validate rule validity (e.g., load testing to verify resource constraints). Package the files into versioned packages (e.g., Git repositories) for use in CI / CD pipelines.

[0065] Understandably, rule generation enables optimized segmentation of microservices and efficient utilization of resources, avoiding issues of granularity imbalance and boundary confusion.

[0066] Example 4 Based on the above embodiments, as an optional implementation method, refer to Figure 5 In step S130, "using the modular design rules, the core functional module is divided into multiple microservices, and each microservice is packaged into an independent container image," can be achieved in the following way: S1310. Based on the domain boundary division rules between the modules, the core functional modules are initially divided into multiple business units.

[0067] As an optional example, first, input a domain boundary delineation rule file (e.g., YAML format) based on dependency analysis results. The rules clearly define domain context boundaries, for example, merging highly coupled modules and independently separating loosely coupled modules. Parse the rule file to extract the delineation logic. For example, the "Schedule Management Module," due to its single responsibility (only handling truck scheduling), can be directly treated as a business unit; while the "Monitoring Management Module," containing multiple functions such as trajectory tracking and status alarms, requires further decomposition.

[0068] Secondly, using the Domain-Driven Design (DDD) principle, each core functional module is initially divided into business units. For example, in Figure 2 In the illustrated intelligent production command platform scenario for railway equipment, core functional modules (such as the scheduling management module and the monitoring management module) are broken down into business units. For example, the scheduling management module is divided into a "signal optimization unit" and a "congestion detection unit," and the monitoring management module is divided into a "track tracking unit" and a "status alarm unit." The division is based on factors including the cohesion of business functions (such as the single responsibility principle) and boundary thresholds defined in the rules (such as units with a coupling degree ≤ 0.3 needing to be independent). A list of business units (in JSON format) is generated, which can include the name, responsibility description, and domain context of each unit.

[0069] Understandably, the initial division clarifies the responsibilities of business units, reduces functional coupling, provides structured input for subsequent quantitative analysis, and improves the accuracy of microservice partitioning.

[0070] S1320. Extract and quantify the interaction relationship indicators among the multiple business units; wherein, the interaction relationship indicators include call frequency, data sharing degree and behavior coupling factor.

[0071] As an optional example, collect interaction data from system runtime logs, monitoring agents (such as Prometheus), or historical data. For example, in a railway platform, collect API call records between business units, database access logs, and message queue traffic. Set the collection period to real-time or near real-time (e.g., sampling every 5 minutes) to ensure the timeliness of the metrics. Count the number of calls between business units within a unit of time (e.g., 24 hours). Use a counting algorithm (e.g., a sliding window counter), for example, the frequency of the "Track Tracking Unit" calling the "Signal Optimization Unit" is 10,000 times / day. Refer to the threshold setting reference for "Call Frequency" as a core metric. Calculate the proportion of shared data sources (e.g., database table or file sharing rate) between business units. Use the formula: Shared data volume / Total data volume × 100%. For example, the Track Tracking Unit and the Status Alarm Unit share vehicle location data, with a sharing rate of 85%. Calculate the coupling degree using call chain analysis tools (e.g., Jaeger or SkyWalking), with the formula: Number of components that are jointly modified or depended upon / Total number of components. For example, if two units frequently collaborate on the same transaction, the coupling factor might be 0.6 (a threshold of ≤0.3 indicates low coupling, consistent with microservice principles). The quantification results are stored as an indicator matrix (CSV or JSON format) for easy subsequent analysis.

[0072] Understandably, by using quantitative indicators to objectively identify highly interactive units, the bias of subjective division is avoided, and the scientific nature and efficiency of microservice partitioning are improved.

[0073] S1330. Based on the interaction relationship indicators, the multiple business units are divided into microservices to obtain multiple microservices.

[0074] Each microservice is responsible for a single business function and has its own independent data storage.

[0075] As an optional example, the application of segmentation rules can first include setting segmentation thresholds; specifically, unit pairs with a call frequency > 1000 times / minute and a behavior coupling factor > 0.5 are merged into a single microservice (to avoid over-splitting); unit pairs with a data sharing degree > 70% are prioritized for merging (to reduce cross-service data synchronization overhead); units with a behavior coupling factor ≤ 0.3 are independent microservices (to ensure low coupling). Based on this, as a specific example, in a railway platform scenario, the trajectory tracking unit and the status alarm unit, due to their high call frequency (5000 times / day) and high sharing degree (80%), are merged into a "vehicle monitoring microservice." The signal optimization unit, due to its low coupling factor (0.2), is an independent "signal optimization microservice."

[0076] Secondly, the partitioning process may include: invoking automated partitioning tools (such as those based on the K-means clustering algorithm), inputting an indicator matrix, and outputting a microservice grouping scheme. The tool ensures that each microservice is responsible for only a single business function. Independent data storage is allocated to each microservice: for example, the vehicle monitoring microservice uses a separate MySQL database to avoid sharing tables with the signal optimization microservice, thus improving isolation.

[0077] Finally, the output microservice manifest (YAML format) can include service names, responsibilities, data storage configurations, and dependencies.

[0078] Understandably, the granularity of microservices is balanced after partitioning, avoiding the granularity imbalance problem in traditional architectures and improving system maintainability and performance.

[0079] S1340. For each of the microservices, invoke the container building tool to package the environment definition file created for the microservice into a layered immutable container image; wherein, the environment definition file includes the basic environment, dependency libraries and configuration parameters.

[0080] As an optional example, first write an environment definition file (such as a Dockerfile) for each microservice, which includes: selecting a lightweight base image (such as an Alpine Linux or OpenJDK image), listing the required libraries (such as the Python library NumPy or Java Spring Boot dependencies), and installing them via a package manager (such as pip or Maven). Inject environment variables (such as database connection strings and service ports), for example, setting SERVER_PORT=8080.

[0081] Secondly, the container build tool (such as Docker or Buildah) is invoked to execute the build command (e.g., `docker build -t my-service:latest .`). The image adopts a layered structure: the base layer remains unchanged and contains the OS and runtime; the dependency layer installs library files and changes less frequently; the code layer contains the application code and is updated frequently. When the code is updated, only the top layer is rebuilt, reducing build time.

[0082] Finally, the image is uploaded to a repository (such as Docker Hub or a private Harbor), tagged with a version (such as v1.0.0) to ensure deployment consistency.

[0083] Understandably, layered images improve build efficiency, immutability ensures deployment consistency, and support rapid scaling and rollback.

[0084] Example 5 Based on the above embodiments, as an optional implementation method, refer to Figure 6 In step S140, "calling the container orchestration platform and, according to the modular design rules, performing integrated deployment and governance of each independent container image" can be achieved in the following way: S1410. According to the resource constraint rules, the container orchestration platform allocates isolated computing resources to each microservice and executes an elastic scaling strategy.

[0085] As an optional example, the execution of the elastic scaling strategy includes: invoking the automatic scaling component of the container orchestration platform to dynamically adjust the number of replicas of each microservice instance based on the integration metrics; wherein the integration metrics include at least: real-time collected CPU utilization and memory usage matching each microservice, and prediction results obtained by a time-series prediction model for predicting business metrics matching each microservice.

[0086] As another optional example, resource constraint rules are first derived from modular design rules and may include CPU utilization thresholds (e.g., ≤70%), memory usage thresholds (e.g., ≤2GB), and custom metrics (e.g., request concurrency). For example, in Figure 2 In the scenario of the intelligent production command platform for railway equipment, resource constraints are set for the vehicle monitoring microservice: a CPU request limit of 0.5 cores and a limit of 1 core, and a memory limit of 2GB. The rule file is in YAML format and integrated into the configuration of the container orchestration platform, such as Kubernetes' ResourceQuota and LimitRange resources. Secondly, resource requests and limits are defined for each microservice Pod using the Deployment resource of the container orchestration platform (such as Kubernetes). The platform automatically allocates isolated computing resources to Pods (such as dedicated CPU cores and memory segments for each node) to avoid resource contention. Finally, the orchestration platform's automatic scaling component (such as Kubernetes HPA) is invoked to dynamically adjust the number of Pod replicas based on real-time metrics (CPU utilization, memory usage, or custom metrics). For example, an HPA policy can be set: when CPU utilization exceeds 70%, the number of replicas expands from 2 to 5; during periods of low traffic, the number automatically shrinks. Combined with predictive models, traffic peaks are identified in advance to achieve predictive scaling. For example, one hour before the peak period for railway freight trains, instances are predicted and expanded based on historical data. The elastic strategy ensures zero-disruption rolling updates through declarative configuration management.

[0087] Understandably, resource isolation and elastic scaling avoid resource bottlenecks and improve system resilience and cost efficiency.

[0088] S1420. Using the service discovery mechanism of the container orchestration platform, each microservice is registered to the service registry center, and a network access endpoint is created for each microservice.

[0089] As another optional example, firstly, after the corresponding microservice instance starts, it calls the orchestration platform's built-in mechanism (such as Kubernetes' Endpoints API) or an external tool (such as Consul) to register metadata (such as IP address, port, and health status) with the service registry. This achieves a "two-layer logical model of configuration namespace and service discovery channel built in the registry." When the microservice container starts, it sends a heartbeat signal to the registry via a sidecar proxy (such as Envoy) or SDK to ensure real-time updates. Secondly, a virtual IP (VIP) and DNS name are created for each microservice using the orchestration platform's Service resources (such as Kubernetes Service). For example, a ClusterIP type Service is created for the vehicle monitoring microservice, providing an internal access endpoint vehicle-service:8080. The endpoint configuration includes port mapping (e.g., mapping the container port (e.g., 8080) to the Service port (e.g., 80)) and uses a round-robin algorithm to support session persistence (e.g., supporting cookie-based or IP-based session affinity to avoid requests jumping across Pods). Additionally, for external access, a LoadBalancer or NodePort type Service can be created to integrate with the cloud provider's load balancer. Finally, microservices dynamically obtain target endpoints by querying the registry center via DNS or API. For example, the signal optimization microservice resolves the DNS name `vehicle-service` to the current instance list of the vehicle monitoring microservice. The container orchestration platform automatically handles instance changes (such as scaling up or down) and updates the endpoint list to ensure high availability.

[0090] exist Figure 2 In the scenario of the intelligent production command platform for railway equipment shown, the emergency management microservice can discover the endpoint of the vehicle monitoring microservice through Kubernetes Service, realize real-time data access, and automatically switch to a healthy instance when the endpoint fails.

[0091] Understandably, the service discovery mechanism improves the reliability of communication between microservices, and dynamic endpoint management reduces configuration redundancy.

[0092] S1430. Based on the behavioral constraint rules, the service mesh and application interface gateway integrated in the container orchestration platform are used to perform traffic routing, load balancing and security policy control on the communication between the multiple microservices.

[0093] As another optional example, firstly, implement traffic routing and load balancing. Specifically, configure traffic rules using a service mesh (such as Istio). Routing rules define path matching strategies based on request tags (such as user region or service level). For example, route requests from mobile devices to low-latency instances, thereby implementing an intelligent multi-dimensional Ingress traffic scheduling mechanism. Load balancing uses weighted round-robin or least-connections algorithms to dynamically allocate traffic. For example, set weights for multiple instances of the video management microservice (instance A: 60%, instance B: 40%), adjusting based on real-time load. Furthermore, edge traffic can be handled through an API gateway (such as Kong or an Ingress controller); for example, define HTTP / HTTPS routing rules (such as the path / api / video directing to the video microservice) and implement SSL termination. Secondly, security policy control can adopt a zero-trust security model. Specifically, define RBAC rules through the service mesh's AuthorizationPolicy to restrict access between microservices (e.g., only allow the scheduling microservice to call the monitoring microservice). Enable mTLS (mutually linked TLS encryption) to automatically inject certificates into microservice communications, achieving a "zero-trust access control policy injection mechanism combined with service mesh". Integrate WAF (Web Application Firewall) to filter malicious traffic, such as SQL injection detection. Finally, configure circuit breakers and retry policies; for example, triggering a circuit breaker after 5 consecutive failures, and retrying 3 times after a timeout. Policies can also be adjusted in real time based on monitoring data (such as Prometheus metrics) to ensure SLA compliance.

[0094] exist Figure 2 In the scenario of the intelligent production command platform for railway equipment shown, traffic routing is configured through Istio VirtualService: 80% of requests are directed to the canary release of the new version of the microservice; simultaneously, mTLS is enabled to ensure secure cross-cluster communication. Understandably, this refined traffic management and security control improves system resilience and response efficiency.

[0095] As described above, the method for integrating and optimizing multiple heterogeneous systems provided in this disclosure uses functional meta-modeling technology to atomically decompose and intelligently integrate multiple heterogeneous systems, effectively identifying and eliminating functional overlaps and redundant nodes, and establishing a unified functional model. This solves the inherent problems of unclear functional abstraction and ambiguous boundaries in traditional system integration. Combined with cloud-native architecture, a microservice partitioning method based on domain context and behavioral weights is adopted to divide core functional modules into microservice units with single responsibilities and independent data, avoiding granularity imbalance and coupling conflicts, and significantly improving the modularity and maintainability of the system. Furthermore, through containerization technology and an automated orchestration platform, dynamic isolation, elastic scaling, and intelligent routing and security control of service traffic are achieved, enhancing the adaptability and stability of the system in high-concurrency scenarios. Ultimately, the overall flexibility, scalability, and operational efficiency of the integration solution are improved, providing efficient and reliable support for multi-system collaboration in complex environments.

[0096] Example 6 It should be understood that the methods described in the foregoing embodiments of this document for integrating and optimizing multiple heterogeneous systems can also be similarly applied to the apparatus described below for integrating and optimizing multiple heterogeneous systems, with similar extensions. For simplicity, they are not described in detail.

[0097] Figure 7 This is a schematic diagram of an apparatus structure for integrating and optimizing multiple heterogeneous systems, provided in an exemplary embodiment of this disclosure. (Refer to...) Figure 7 The device includes: The meta-model creation unit 710 is configured to: in response to receiving a system integration instruction, decompose and compare multiple heterogeneous systems to be integrated and optimized in order to establish a unified functional meta-model, and integrate the core functional modules according to the functional meta-model. The rule generation unit 720 is configured to: call the metamodel compiler to compile the functional metamodel into a system description file, verify the dependency relationship of the core functional modules based on the system description file, and generate modular design rules; The microservice processing unit 730 is configured to: use the modular design rules to perform microservice splitting on the core functional module to obtain multiple microservices, and package each microservice into an independent container image; The system integration unit 740 is configured to: invoke the container orchestration platform, and according to the modular design rules, perform integrated deployment and governance of each independent container image to generate a cloud-native integrated system with elastic scaling and intelligent traffic management capabilities.

[0098] As described above, the method for integrating and optimizing multiple heterogeneous systems provided in this disclosure uses functional meta-modeling technology to atomically decompose and intelligently integrate multiple heterogeneous systems, effectively identifying and eliminating functional overlaps and redundant nodes, and establishing a unified functional model. This solves the inherent problems of unclear functional abstraction and ambiguous boundaries in traditional system integration. Combined with cloud-native architecture, a microservice partitioning method based on domain context and behavioral weights is adopted to divide core functional modules into microservice units with single responsibilities and independent data, avoiding granularity imbalance and coupling conflicts, and significantly improving the modularity and maintainability of the system. Furthermore, through containerization technology and an automated orchestration platform, dynamic isolation, elastic scaling, and intelligent routing and security control of service traffic are achieved, enhancing the adaptability and stability of the system in high-concurrency scenarios. Ultimately, the overall flexibility, scalability, and operational efficiency of the integration solution are improved, providing efficient and reliable support for multi-system collaboration in complex environments.

[0099] Example 7 In addition, this disclosure also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the method for integrating and optimizing multiple heterogeneous systems as described in any of the above embodiments of this disclosure.

[0100] Figure 8 This is a schematic diagram of an application embodiment of the electronic device disclosed herein. Below, reference is made to… Figure 8 This describes an electronic device according to embodiments of the present disclosure. The electronic device may be either or both of a first device and a second device, or a standalone device independent of them, which may communicate with the first device and the second device to receive acquired input signals from them.

[0101] like Figure 8As shown, the electronic device includes one or more processors and memory. The processor may be a central processing unit (CPU) or other processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. The memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc. One or more computer program instructions may be stored on the computer-readable storage medium, and the processor may execute the program instructions to implement the methods for integrating and optimizing multiple heterogeneous systems and / or other desired functions described in the various embodiments of this disclosure above.

[0102] In one example, the electronic device may further include input and output devices, which are interconnected via a bus system and / or other forms of connection mechanisms (not shown). Furthermore, the input device may include, for example, a keyboard, a mouse, etc. The output device can output various information to the outside, including determined distance information, direction information, etc. The output device may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0103] Of course, for the sake of simplicity, Figure 8 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0104] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the methods for integrating and optimizing multiple heterogeneous systems according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0105] The computer program product can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0106] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps in the methods for integrating and optimizing multiple heterogeneous systems according to various embodiments of this disclosure as described in the foregoing portion of this specification.

[0107] The computer-readable storage medium may be any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof.

[0108] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0109] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0110] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0111] The block diagrams of devices, apparatuses, devices, and systems disclosed herein are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as “comprising,” “including,” “having,” etc., are open-ended terms meaning “including but not limited to,” and are used interchangeably with them. The terms “or” and “and” as used herein refer to the terms “and / or,” and are used interchangeably with them unless the context clearly indicates otherwise. The term “such as” as used herein refers to the phrase “such as but not limited to,” and is used interchangeably with it.

[0112] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the methods is for illustrative purposes only, and the steps of the methods of this disclosure are not limited to the order specifically described above, unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the methods according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the methods according to this disclosure.

[0113] It should also be noted that in the apparatus, devices, and methods of this disclosure, the components or steps can be disassembled and / or recombined. These disassemblies and / or recombinations should be considered as equivalent solutions to this disclosure.

[0114] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0115] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A method for integrating and optimizing multiple heterogeneous systems, characterized in that, The method includes: In response to receiving a system integration instruction, the system decomposes and compares multiple heterogeneous systems to be integrated and optimized in order to establish a unified functional meta-model, and integrates the core functional modules based on the functional meta-model. The metamodel compiler is invoked to compile the functional metamodel into a system description file, and the dependencies of the core functional modules are verified based on the system description file to generate modular design rules. Using the modular design rules, the core functional module is divided into multiple microservices, and each microservice is packaged into an independent container image. The container orchestration platform is invoked to deploy and manage each independent container image in an integrated manner according to the modular design rules, thereby generating a cloud-native integrated system with elastic scaling and intelligent traffic management capabilities.

2. The method according to claim 1, characterized in that, In response to receiving a system integration instruction, the system decomposes and compares multiple heterogeneous systems to be integrated and optimized to establish a unified functional meta-model, and integrates the core functional modules based on the functional meta-model, including: In response to receiving the system integration instruction, based on functional semantics, interface contracts, resource constraints and behavioral rules, the functions of the multiple heterogeneous systems are atomically decomposed and horizontally compared to identify functional overlaps and redundant nodes in order to establish the unified functional meta-model. Redundancy quantification is performed on the functional modules in the functional meta-model, and functional modules whose functional semantic similarity meets the preset similarity judgment conditions and whose resource requirements are coordinated are merged and integrated into a specified number of core functional modules, while the boundaries of each core functional module are defined. Define a unified interface contract, resource usage threshold, and exception handling rules for each core functional module.

3. The method according to claim 1, characterized in that, Verify the dependencies of the core functional modules based on the system description file, and generate modular design rules, including: Based on the system description file, the call and data dependencies between the core functional modules are analyzed to obtain the dependency analysis results. Based on the analysis results of the dependencies, rules for defining domain boundaries between microservice partitioning modules, as well as resource constraint rules and behavioral constraint rules for guiding system architecture planning, are generated.

4. The method according to claim 3, characterized in that, The analysis of the call and data dependency relationships between the core functional modules based on the system description file includes: Based on the system description file, a directed acyclic graph representing module dependencies is constructed; If the business processes between the core functional modules are found to have no circular dependency conflicts by traversing the directed acyclic graph, then the modular design rule is determined to be reasonable.

5. The method according to claim 3, characterized in that, Using the aforementioned modular design rules, the core functional module is divided into multiple microservices, and each microservice is packaged into an independent container image, including: Based on the domain boundary division rules between modules, the core functional modules are initially divided into multiple business units; Extract and quantify the interaction relationship indicators among the multiple business units; wherein, the interaction relationship indicators include call frequency, data sharing degree and behavioral coupling factor; The multiple business units are divided into multiple microservices based on the interaction relationship indicators; each microservice is responsible for a single business function and has independent data storage. For each microservice, a container building tool is invoked to package the environment definition file created for that microservice into a layered, immutable container image; wherein, the environment definition file includes the basic environment, dependency libraries, and configuration parameters.

6. The method according to claim 3, characterized in that, The container orchestration platform is invoked to perform integrated deployment and governance of each independent container image according to the modular design rules, including: Based on the resource constraint rules, the container orchestration platform allocates isolated computing resources to each microservice and executes elastic scaling strategies. Using the service discovery mechanism of the container orchestration platform, each microservice is registered to the service registry center, and a network access endpoint is created for each microservice. Based on the behavioral constraint rules, the service mesh and application interface gateway integrated into the container orchestration platform are used to perform traffic routing, load balancing, and security policy control on the communication between the multiple microservices.

7. The method according to claim 6, characterized in that, The implementation of the elastic scaling strategy includes: The auto-scaling component of the container orchestration platform is invoked to dynamically adjust the number of replicas of each microservice instance based on the cohesion metric. The fusion metrics include at least: real-time collected CPU utilization and memory usage for each microservice, and prediction results obtained by a time-series prediction model for the business metrics of each microservice.

8. An apparatus for integrating and optimizing multiple heterogeneous systems, characterized in that, The device includes: The meta-model creation unit is configured to: in response to receiving a system integration instruction, decompose and compare multiple heterogeneous systems to be integrated and optimized in order to establish a unified functional meta-model, and integrate the core functional modules according to the functional meta-model. The rule generation unit is configured to: call the metamodel compiler to compile the functional metamodel into a system description file, verify the dependency relationship of the core functional modules based on the system description file, and generate modular design rules; The microservice processing unit is configured to: use the modular design rules to perform microservice splitting on the core functional module to obtain multiple microservices, and package each microservice into an independent container image; The system integration unit is configured to: invoke the container orchestration platform, and according to the modular design rules, perform integrated deployment and governance of each independent container image to generate a cloud-native integrated system with elastic scaling and intelligent traffic management capabilities.

9. A computer-readable storage medium, characterized in that, The storage medium stores a computer program for executing the method for integrating and optimizing multiple heterogeneous systems as described in claims 1 to 7.

10. An electronic device, characterized in that, The electronic device includes: a processor; a memory for storing executable instructions of the processor; the processor being configured to read the executable instructions from the memory and execute the instructions to implement the method for integrating and optimizing multiple heterogeneous systems as described in claims 1 to 7.

Images