A service-oriented CAE simulation platform micro-service architecture construction method and system

Abstract

The application relates to the fields of CAE simulation technology and distributed architecture, and discloses a service-oriented CAE simulation platform micro-service architecture construction method and system, which comprises the following steps: constructing a micro-service architecture, wherein the micro-service architecture comprises a core micro-service cluster, a unified service bus, a dynamic resource scheduling center and a distributed data layer; data generated by each micro-service is stored through the distributed data layer; the distributed data layer cuts unstructured data into data shards and stores the data shards in the form of multiple copies into an object storage cluster, stores structured data into a relational database, stores business metadata into a cache cluster, listens to change logs of the relational database by using a change data capture technology, and synchronizes change events to the cache cluster. The traditional monomer platform needs 3 hours to complete the same task, the application only needs 1 hour and 30 minutes, the efficiency is improved by 50%, and the task queuing time is shortened from 1 hour to 10 minutes.

Description

Technical Field

[0001] This invention relates to the fields of CAE simulation technology and distributed architecture, and in particular to a method and system for constructing a microservice architecture for a service-oriented CAE simulation platform. Background Technology

[0002] Traditional CAE simulation platforms mostly adopt a monolithic or modular monolithic architecture, integrating functions such as geometry processing, mesh generation, solver invocation, and post-processing into a single system, which has four major bottlenecks: 1. Poor scalability and high upgrade costs: Any functional module in the monolithic architecture (such as the upgrade of the mesh partitioning algorithm) requires the entire platform service to be stopped, recompiled and deployed, with upgrade downtime exceeding 8 hours; adding new functions (such as the electromagnetic simulation module) requires modification of the core code, with a development cycle exceeding 3 months, making it impossible to quickly respond to business needs.

[0003] 2. Rigid resource allocation and low utilization: Platform resources (CPU / memory / GPU) are allocated to each functional module in a fixed configuration. For example, when the geometry processing module is idle, the 20% of CPU resources it occupies cannot be scheduled to the high-load solver module, resulting in an overall resource utilization of less than 30%. When faced with sudden large-scale simulation tasks (such as 100 sets of parameter optimization), resources cannot be expanded quickly, and the task queuing time exceeds 24 hours.

[0004] 3. Low availability and wide impact of failures: A single functional failure in the monolithic architecture (such as the crash of the post-processing module) can paralyze the entire platform, with a mean time to recovery (MTTR) of over 4 hours; the lack of fault tolerance mechanisms makes it impossible to isolate local failures locally, which seriously affects the continuity of simulation tasks.

[0005] 4. Difficult cross-platform integration and low collaboration efficiency: Traditional platforms are difficult to integrate efficiently with external systems (such as CAD design software and PLM product lifecycle management systems). Data interaction requires customized interfaces, and the integration cycle exceeds 2 weeks. When conducting cross-team collaborative simulation, different teams need to download the same model and repeat the calculation, resulting in data synchronization delays of more than 12 hours and low collaboration efficiency.

[0006] Existing technologies cannot meet the requirements of CAE simulation for high elasticity, high availability, rapid iteration, and strong collaboration. There is an urgent need for a distributed CAE platform solution based on microservice architecture to achieve functional decoupling, dynamic resource scheduling, and efficient collaboration. Summary of the Invention

[0007] To address the aforementioned technical problems, this invention provides a method for constructing a service-oriented CAE simulation platform microservice architecture, comprising the following steps: Construct a microservice architecture, which includes a core microservice cluster, a unified service bus, a dynamic resource scheduling center, and a distributed data layer; The computer-aided engineering (CAE) simulation process is broken down into multiple microservices, and each microservice is packaged into a container image and deployed in the core microservice cluster. After each microservice starts, it sends a registration request containing a service identifier, network address and interface list to the unified service bus. The unified service bus maintains a service registry based on the registration request. The simulation process orchestration microservice in the core microservice cluster receives CAE simulation tasks and parses the CAE simulation tasks into an ordered sequence of subtasks containing dependencies. The unified service bus extracts the target service identifier and message tag of each subtask in the ordered subtask sequence, and distributes each subtask to the corresponding microservice for execution based on the two-layer routing strategy of the target service identifier and the message tag. During the execution of each subtask by each microservice, the dynamic resource scheduling center inputs the collected historical task load data and real-time task queue length into the long short-term memory neural network model and outputs resource prediction results. Based on the resource prediction results, it performs horizontal scaling operations by adjusting the number of microservice instances, or performs vertical scaling operations by adjusting the number of processor cores and memory quotas bound to the microservice instances while keeping them running. It also uses a two-factor scheduling algorithm that includes task priority factors and node load balancing factors to allocate computing node resources to the microservices. The data generated by each microservice is stored through the distributed data layer. The distributed data layer divides unstructured data into data shards and stores them in the object storage cluster in the form of multiple replicas, stores structured data in the relational database, stores business metadata in the cache cluster, and uses change data capture technology to monitor the change logs of the relational database and synchronize change events to the cache cluster.

[0008] This invention also provides a service-oriented CAE simulation platform microservice architecture construction system for implementing the aforementioned method, the system comprising: The core microservice cluster module contains multiple microservices that are packaged as container images and deployed on compute nodes. The multiple microservices include a simulation process orchestration microservice, which is configured to receive CAE simulation tasks and parse the CAE simulation tasks into an ordered sequence of subtasks containing dependencies. The unified service bus module communicates with the core microservice cluster module, is configured with a service registry maintained based on a server-side active registration and client-side subscription discovery mechanism, and is configured with a message routing component. The message routing component is configured to extract the target service identifier and message tag of each subtask in the ordered subtask sequence, and distribute each subtask to the corresponding microservice for execution based on a two-layer routing strategy of the target service identifier and the message tag. The dynamic resource scheduling center module is equipped with a resource prediction unit that embeds a long short-term memory neural network model. This unit inputs historical task load data and real-time task queue length into the long short-term memory neural network model to output resource prediction results. It also includes an elastic scaling execution unit and a two-factor scheduling unit. The elastic scaling execution unit is configured to perform horizontal scaling operations by adjusting the number of microservice instances based on the resource prediction results, or to perform vertical scaling operations by adjusting the number of processor cores and memory quotas bound to microservice instances while keeping them running. The two-factor scheduling unit uses a two-factor scheduling algorithm that includes task priority factors and node load balancing factors to allocate computing node resources to the microservices. The distributed data layer module communicates with the core microservice cluster module and the unified service bus module. It is configured to split unstructured data into data shards and store them in the object storage cluster in the form of multiple replicas, store structured data in the relational database, and store business metadata in the cache cluster. The distributed data layer module is configured with a change data capture middleware, which is used to monitor the change log of the relational database and synchronize the log change events to the cache cluster.

[0009] Compared with the prior art, the beneficial effects of the present invention are as follows: 1. Extremely flexible scaling, significantly improving resource utilization. The number of service instances can be expanded from 1 to 10 within 2 minutes to cope with sudden large-scale tasks, and the task queuing time is reduced by 80%; the resource configuration of a single service can be dynamically adjusted, and the resource satisfaction rate of heavy load solving tasks is increased from 60% to 100%; from less than 30% of the traditional platform to more than 80%, saving 40% of hardware costs per year.

[0010] 2. High availability and fault tolerance, minimizing the impact of failures. A single service failure only affects that service, while other functions continue to operate normally, reducing the scope of the failure by 90%; the average failure recovery time is reduced from 4 hours to 2 minutes, and the platform availability reaches 99.99%, meeting the critical business continuity requirements; the asynchronous message delivery success rate is ≥99.99%, avoiding task rework caused by data loss.

[0011] 3. Rapid iteration and easy expansion improve development efficiency. Each microservice is developed, tested, and deployed independently, reducing the new feature launch cycle from 3 months to 2 weeks and improving iteration efficiency by 85%; different microservices can adopt technology stacks that are adapted to their own needs, increasing the freedom of technology selection by 90%; through standardized APIs and integration with CAD / PLM systems, the integration cycle is reduced from 2 weeks to 1 day, and cross-system collaboration efficiency is improved by 95%.

[0012] 4. Efficient cross-team collaboration and data sharing All models / results are shared through a distributed data layer, avoiding redundant storage and reducing data redundancy by 70%; cross-regional teams can view simulation progress and results simultaneously, with data synchronization latency ≤3s, improving collaboration efficiency by 80%; fine-grained access control is achieved based on data management microservices, and data security complies with ISO27001 standards. Attached Figure Description

[0013] Figure 1 A flowchart provided for an embodiment of the present invention. Detailed Implementation

[0014] The terms “first,” “second,” “third,” “fourth,” etc. (if present) in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms “comprising” or “having,” and any variations thereof, are intended to cover a non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0015] like Figure 1 A method for constructing a microservice architecture for a service-oriented CAE simulation platform includes the following steps: Construct a microservice architecture, which includes a core microservice cluster, a unified service bus, a dynamic resource scheduling center, and a distributed data layer; The computer-aided engineering (CAE) simulation process is broken down into multiple microservices, and each microservice is packaged into a container image and deployed in the core microservice cluster. After each microservice starts, it sends a registration request containing a service identifier, network address and interface list to the unified service bus. The unified service bus maintains a service registry based on the registration request. The simulation process orchestration microservice in the core microservice cluster receives CAE simulation tasks and parses the CAE simulation tasks into an ordered sequence of subtasks containing dependencies. The unified service bus extracts the target service identifier and message tag of each subtask in the ordered subtask sequence, and distributes each subtask to the corresponding microservice for execution based on the two-layer routing strategy of the target service identifier and the message tag. During the execution of each subtask by each microservice, the dynamic resource scheduling center inputs the collected historical task load data and real-time task queue length into the long short-term memory neural network model and outputs resource prediction results. Based on the resource prediction results, it performs horizontal scaling operations by adjusting the number of microservice instances, or performs vertical scaling operations by adjusting the number of processor cores and memory quotas bound to the microservice instances while keeping them running. It also uses a two-factor scheduling algorithm that includes task priority factors and node load balancing factors to allocate computing node resources to the microservices. The data generated by each microservice is stored through the distributed data layer. The distributed data layer divides unstructured data into data shards and stores them in the object storage cluster in the form of multiple replicas, stores structured data in the relational database, stores business metadata in the cache cluster, and uses change data capture technology to monitor the change logs of the relational database and synchronize change events to the cache cluster.

[0016] The process of breaking down the Computer-Aided Engineering (CAE) simulation workflow into multiple microservices includes: The CAE simulation process is functionally decoupled into a geometry processing microservice, a mesh generation microservice, a solver management microservice, a post-processing microservice, a simulation process orchestration microservice, a data management microservice, an external integration microservice, and a monitoring and alarm microservice, and each of the microservices is configured to run with independent computing resources.

[0017] When distributing subtasks to their corresponding microservices for execution, the unified service bus employs the following communication and fault-tolerance mechanisms: For synchronous communication involving control commands and status queries, a descriptive state transition application programming interface protocol is used for data interaction; for asynchronous communication involving mesh files or rendering result files, the WebSocket protocol is used for binary data push; for process call communication for solver task scheduling, the gRPC protocol based on protocol buffer serialization is used for remote process calls. When the error rate of the target microservice is detected to be greater than the preset circuit breaker threshold, new call requests to the target microservice are blocked and a preset default response message is returned; When a network connection error is detected, an exponential backoff algorithm is used to initiate a preset number of retry calls at increasing time intervals; the call messages based on asynchronous communication are written to a distributed message queue system for persistent storage.

[0018] Based on the resource prediction results, the process of performing horizontal scaling by adjusting the number of microservice instances, or performing vertical scaling by adjusting the number of processor cores and memory quotas bound to microservice instances while keeping them running, includes: When the processor utilization of a specific microservice is found to be greater than a preset high load threshold or the request queue length is greater than a preset queue threshold, a new container instance is created on an idle computing node to increase the number of microservice instances for that specific microservice. When the processor utilization of a specific microservice is found to be lower than a preset low load threshold for a preset period of time, container instances are recycled to reduce the number of microservice instances of that specific microservice. For a specific microservice, the underlying container orchestration interface is called to modify the processor core quota and memory capacity quota of the corresponding container, and the original process of the microservice instance is not interrupted during the process of modifying the quota parameters.

[0019] The process of distributing each subtask to the corresponding microservice for execution includes: The geometry processing microservice receives the computer-aided design model, performs geometry repair and feature simplification operations to generate a repaired model, and routes the repaired model to the mesh partitioning microservice through the unified service bus. The mesh generation microservice receives the repaired model, performs mesh generation and mesh quality verification operations to generate a mesh file, and routes the mesh file to the solver management microservice through the unified service bus; The solver management microservice receives the mesh file, sends a computing resource request instruction to the dynamic resource scheduling center, and after obtaining the allocated processor and memory resources, starts the corresponding solver instance to perform physics field calculations to generate solution results, and routes the solution results to the post-processing microservice through the unified service bus. The post-processing microservice receives the solution result and performs data rendering operations to generate a cloud map data file containing the physical field distribution state.

[0020] In embodiments of the present invention, a service-oriented CAE simulation platform microservice architecture construction system is also provided for the aforementioned method, the system comprising: The core microservice cluster module contains multiple microservices that are packaged as container images and deployed on compute nodes. The multiple microservices include a simulation process orchestration microservice, which is configured to receive CAE simulation tasks and parse the CAE simulation tasks into an ordered sequence of subtasks containing dependencies. The unified service bus module communicates with the core microservice cluster module, is configured with a service registry maintained based on a server-side active registration and client-side subscription discovery mechanism, and is configured with a message routing component. The message routing component is configured to extract the target service identifier and message tag of each subtask in the ordered subtask sequence, and distribute each subtask to the corresponding microservice for execution based on a two-layer routing strategy of the target service identifier and the message tag. The dynamic resource scheduling center module is equipped with a resource prediction unit that embeds a long short-term memory neural network model. This unit inputs historical task load data and real-time task queue length into the long short-term memory neural network model to output resource prediction results. It also includes an elastic scaling execution unit and a two-factor scheduling unit. The elastic scaling execution unit is configured to perform horizontal scaling operations by adjusting the number of microservice instances based on the resource prediction results, or to perform vertical scaling operations by adjusting the number of processor cores and memory quotas bound to microservice instances while keeping them running. The two-factor scheduling unit uses a two-factor scheduling algorithm that includes task priority factors and node load balancing factors to allocate computing node resources to the microservices. The distributed data layer module communicates with the core microservice cluster module and the unified service bus module. It is configured to split unstructured data into data shards and store them in the object storage cluster in the form of multiple replicas, store structured data in the relational database, and store business metadata in the cache cluster. The distributed data layer module is configured with a change data capture middleware, which is used to monitor the change log of the relational database and synchronize the log change events to the cache cluster.

[0021] The core microservice cluster module is divided into several microservices, including geometry processing microservice, mesh generation microservice, solver management microservice, post-processing microservice, simulation process orchestration microservice, data management microservice, external integration microservice, and monitoring and alarm microservice.

[0022] The unified service bus module is equipped with a multi-protocol adapter and a fault-tolerant control component. The multi-protocol adapter includes a Representational State Transition Application Programming Interface (API) channel for handling synchronous communication, a WebSocket protocol channel for handling asynchronous communication, and a gRPC protocol channel based on protocol buffer serialization for handling procedure call communication. The fault tolerance control component is configured to block new request links to the target microservice when the call error rate of the target microservice is detected to be greater than a preset circuit breaker threshold, initiate retry calls by setting an incremental time interval using an exponential backoff algorithm when an abnormal network connection error is detected, and write asynchronous call messages to an external distributed message queue cluster.

[0023] The elastic scaling execution unit in the dynamic resource scheduling center module is configured as follows: When receiving status data that the processor utilization of a specific microservice is greater than the preset high load threshold or the request queue length is greater than the preset queue threshold, a horizontal scaling instruction to create a new container instance is issued to the compute node. When receiving status data that the processor utilization of a specific microservice is less than the preset low load threshold and continues for a preset period of time, a horizontal scaling instruction to destroy the container instance is issued to the compute node. While keeping the microservice running without interruption, the underlying container engine's application programming interface (API) is invoked to execute vertical scaling instructions that update the processor core quota parameters and memory capacity quota parameters of a specific container process.

[0024] The external integration microservice and monitoring / alerting microservice in the core microservice cluster module are configured as follows: The externally integrated microservice is configured with a representational state transition application programming interface and an open data protocol interface, which are used to receive data sent by an external computer-aided design system or product lifecycle management system to perform data synchronization operations. The monitoring and alarm microservice is connected to the system nodes and is configured to periodically extract the hardware resource utilization rate of each computing node and the request queue length of each microservice, and write the extracted status data into the time series database. The dynamic resource scheduling center module is also equipped with a cross-domain scheduling unit, which is used to encrypt and transmit the solution data of the simulation task to an idle computing cluster in a different location for scheduling and allocation when the available resources of the local computing cluster are insufficient to respond to the resource prediction result and the priority of the simulation task to be executed has not reached the high priority threshold.

[0025] The core of this invention is to construct a four-layer microservice architecture consisting of a core microservice cluster, a unified service bus (ESB), a dynamic resource scheduling center, and a distributed data layer. This architecture breaks down the entire CAE simulation process into independent microservices and achieves elastic scaling and high availability through standardized communication and scheduling.

[0026] 1. Core microservice cluster (functional decoupling layer) Following the CAE simulation workflow (preprocessing → solving → postprocessing → collaborative management), the functionality is divided into 8 independent microservices. Each service possesses the characteristics of "single responsibility, independent deployment, and autonomous expansion," as detailed below: Geometric processing microservices: CAD model import (STEP / IGES), geometry repair, feature simplification; technical support: Generator5; 100MB model processing response time ≤5s, concurrent support ≥50 channels.

[0027] Grid-based microservices: Tetrahedral / hexahedral mesh generation, mesh quality verification, and local refinement. Technical support: Generator 5.1 million node mesh generation ≤10s, pass rate ≥99%. Solver management microservice: Solver, task submission, progress monitoring; technical support: G5-jobs; solver task scheduling latency ≤1s; supports 100+ solver instances. Post-processing microservices: Simulation result visualization (cloud maps / animations), data export (CSV / Excel), technical support: G5-post; ParaViewWeb; 1GB result file rendering ≤3s, supports 10-way concurrent viewing. Simulation process orchestration microservices: Customizable simulation workflow (“Geometry → Mesh → Solve → Post-processing”), task dependency management, technical support: PDM, etc.; workflow definition response ≤ 2s, supports 1000+ concurrent workflow instances.

[0028] Data management microservices: Model / results data storage, version control, and access control; technical support: MinIO (object storage), PostgreSQL; data read / write throughput ≥ 100MB / s, version rollback ≤ 1s. External integration of microservices: Integration and data synchronization with CAD / PLM systems; technical support: RESTAPI, OData protocol; data synchronization latency ≤3s, integration success rate ≥99%.

[0029] Monitoring and Alerts Microservice: Service health checks, resource utilization monitoring, and fault alerts (email / SMS); technical support: Prometheus, Grafana, AlertManager; monitoring data collection interval ≤10s, fault detection accuracy ≥99.5%.

[0030] 2. Unified Service Bus (ESB) (Communication Collaboration Layer) As the "communication hub" between microservices, it enables service registration and discovery, message routing, protocol conversion, and fault tolerance. Its core functions include: 1. Service Registration and Discovery: The system adopts a "server-side active registration + client-side subscription discovery" mechanism. After a new microservice starts up, it automatically registers its metadata (service ID, IP / port, interface documentation, load threshold) with the ESB. The client queries the target service through the ESB's service registry, and the discovery latency is ≤500ms. 2. Multi-protocol communication support: 1) Synchronous communication: REST API (JSON format) is used for simple data interaction, with a response time of ≤1 second; 2) Asynchronous communication: WebSocket (binary protocol) is used for high-volume data transmission with a transmission rate ≥100MB / s; 3) High-performance communication: gRPC (Protocol Buffers serialization) is used for low-latency scenarios such as solver task scheduling, with a call latency of ≤100ms; 3. Message routing and filtering: Based on a two-layer routing strategy of "service ID + message tag", for example, "geometry processing completed message" is automatically routed to "mesh partitioning microservice", supports filtering by message priority (high / medium / low), high priority messages are processed first, and scheduling latency is ≤50ms; 4. Fault tolerance and reliability assurance: 1) Circuit breaker mechanism: When the error rate of a service is greater than 5%, the ESB will automatically circuit breaker the service call and return a default response to prevent the failure from spreading; 2) Retry mechanism: For temporary errors, an "exponential backoff retry" mechanism is adopted (retry interval 1s→2s→4s, up to 3 times), with a retry success rate of ≥95%; 3) Message persistence: Asynchronous messages are stored in the Kafka message queue to ensure that messages are not lost after service failure, and the message delivery success rate is ≥99.99%.

[0031] 3. Dynamic Resource Scheduling Center (Resource Management Layer) Based on Kubernetes container orchestration technology, it enables "on-demand allocation and elastic scaling" of CPU / memory / GPU resources. Core functionalities include: 1. Resource Demand Forecasting: Combining historical task data with real-time task queue length, an LSTM neural network is used to predict resource demand for the next hour, with a prediction accuracy of ≥85%. 2. Elastic scaling strategy: 1) Horizontal scaling (number of service instances): When the CPU utilization of a service is >70% or the request queue length is >100, the service instance will be added automatically, with a scaling time of ≤2 minutes; when the CPU utilization is <30% and lasts for 5 minutes, the instance will be reduced automatically, with a scaling time of ≤1 minute. 2) Vertical scaling (single instance resource configuration): For heavy-load services such as solvers, it supports dynamic adjustment of the number of CPU cores (e.g., from 4 cores to 8 cores) and memory size (e.g., from 16GB to 32GB), without interrupting the service during the scaling process; 3. Resource scheduling algorithm: The "priority-load balancing" two-factor scheduling is adopted. High-priority tasks are allocated resources first, and tasks with the same priority are allocated according to the "least load node", which improves the resource utilization rate to more than 80%. 4. Multi-cluster management: Supports cross-regional cluster resource scheduling, and enables encrypted data transmission between clusters via VPN, with transmission security compliant with ISO27001 standards.

[0032] 4. Distributed Data Layer It adopts a hybrid storage architecture of "object storage + relational database + cache" to support efficient storage and access of CAE simulation data throughout the entire process: 1. Object Storage (MinIO): Stores large volumes of unstructured data (CAD models, mesh files, simulation results), supports data sharding (default 128MB / shard) and multiple replicas (default 3 replicas), with data reliability ≥99.9999%; 2. Relational database (PostgreSQL): Stores structured data (service configuration, user permissions, process definition, task status), supports ACID properties of transactions, and ensures data consistency; 3. Caching (Redis): Caches frequently accessed data (such as service registry, popular model metadata), with a cache hit rate of ≥90%, reducing database access pressure, and data query response time ≤10ms; 4. Data synchronization mechanism: Adopting ChangeDataCapture technology, relational database and cached data are synchronized in real time with a synchronization delay of ≤1s; cross-microservice data sharing is achieved through a unified interface of "data management microservice" to avoid data redundancy.

[0033] II. Implementation Methods of Microservice Architecture Based on the above architecture, the implementation process of the CAE simulation platform includes five stages: "architecture deployment → service registration → task execution → resource scheduling → monitoring and maintenance". The specific steps are as follows: 1. Architecture initialization and deployment 1.1 Infrastructure Deployment: Deploy a Kubernetes cluster in a public or private cloud environment, configuring 3 management nodes (Master) and N compute nodes (Worker). Each compute node should be configured with at least 8 CPU cores, 32GB of memory, and 1TB of SSD. 1.2 Microservice containerization: Eight core microservices are packaged into Docker container images (based on AlpineLinux streamlined images, with an average image size of ≤200MB). The images are stored in a Harbor private repository, supporting version management and vulnerability scanning. 1.3 ESB and Data Layer Deployment: Deploy a unified service bus (based on Spring Cloud Stream), a Kafka message queue (3-node cluster), and distributed storage (MinIO 4-node cluster, PostgreSQL master-slave architecture, Redis 3-node cluster), and complete the network configuration and permission integration of each component.

[0034] 2. Microservice Registration and Discovery 2.1 Service Registration: Start each microservice container. The microservice submits a registration request to the ESB via REST API, which includes the service ID, IP / port, list of interfaces, and health check address. 2.2 Registry Maintenance: After verifying the legality of the registration information, the ESB stores the service metadata in the Redis cache and PostgreSQL database to form a "real-time service registry". Every 10 seconds, a health check request is sent to each service, and services that "have not responded for more than 30 seconds" are marked as "offline" and removed from the registry. 2.3 Client Discovery: Users initiate simulation tasks through the platform's web interface. The client (browser / desktop) sends a service query request to the ESB. The ESB returns a list of available services, and the client selects the service with the lowest load to initiate the call.

[0035] 3. Collaborative execution of simulation tasks 3.1 Task Initiation: Users upload the car door CAD model (STEP format, 50MB) through the web interface, select "Collision Simulation Workflow" (Geometric Repair → Mesh Generation → LS-DYNA Solving → Stress Cloud Map Post-processing), set the task priority to "High", and submit it to "Simulation Workflow Orchestration Microservice"; 3.2 Process Analysis and Task Decomposition: The process orchestration microservice analyzes user requests, generates four ordered subtasks (T1: geometry repair, T2: mesh generation, T3: solution, T4: post-processing), and sends task requests to the microservices corresponding to each subtask via ESB; 3.3 Parallel / Serial Execution of Subtasks: 1. T1 (Geometric Processing Microservice): Receives the CAD model, performs repair (stitching gaps, deleting small faces), generates the repaired model, and sends the result to T2 via ESB, taking 3 seconds; 2. T2 (Mesh Generation Microservice): Receives the repaired model, generates a hexahedral mesh (200,000 nodes), verifies the quality (distortion rate ≤3%), and sends the mesh file to T3 via ESB, taking 8 seconds; 3.T3 (Solver Management Microservice): Receives mesh files, requests 8 CPU cores and 64GB memory resources from the dynamic resource scheduling center, starts the LS-DYNA solver instance, performs collision simulation (takes 15 minutes), and pushes progress in real time via ESB; 4.T4 (Post-processing microservice): Receives the solution results (2GB), generates stress cloud diagrams and animations, and pushes them to the user interface via WebSocket, taking 2 seconds; 3.4 Results Feedback: After post-processing is completed, the workflow orchestration microservice sends a "task completed" notification (email / platform message) to the user, who can view the results and export the data through the interface.

[0036] 4. Dynamic resource scheduling 4.1 Resource Monitoring: Monitoring and Alerts: Every 10 seconds, the microservice collects the CPU / memory / GPU utilization, number of microservice instances, and task queue length of each node. The data is stored in Prometheus and displayed as a real-time dashboard through Grafana. 4.2 Scaling Triggering and Execution: After the T3 task is submitted, the request queue length of the solver management microservice increases from 0 to 50, and the CPU utilization increases from 20% to 85%. The dynamic resource scheduling center triggers horizontal scaling. 1. Automatically add 3 solver instances (expanding from 1 instance to 4 instances). Kubernetes creates a new container on an idle worker node, taking 90 seconds. 2. After the expansion, the solver CPU utilization rate dropped to 40%, and the task queuing time was reduced from 20 minutes to 5 minutes; 4.3 Downsizing after task completion: After all solving tasks are completed, the solver CPU utilization drops to 15% for 5 minutes. The dynamic resource scheduling center automatically reduces 2 instances (from 4 instances to 2 instances), freeing up 16 CPU cores and 128GB of memory resources.

[0037] 5. Monitoring and Troubleshooting 5.1 Health monitoring: The ESB sends a health check request to each microservice every 10 seconds. If a microservice instance in a certain mesh partition fails to respond for 3 consecutive times, it is marked as "faulty". 5.2 Fault Isolation and Recovery: 1. Circuit Breaker: The ESB automatically circuit breaks the call to the faulty instance, and the new task is routed to other normal instances; 2. Restart: The dynamic resource scheduling center automatically restarts the faulty instance, with a recovery time of ≤2 minutes; 5.3 Alarms and Logs: The monitoring and alarm microservice sends fault alarms to the administrator, including the fault service ID, node IP, and fault time; all microservice logs are centrally collected through ELK, supporting fault tracing and root cause analysis.

[0038] Taking the thermal coupling simulation of aero-engine blade structure as an example, this paper details the implementation process of the present invention and verifies the feasibility and advantages of the architecture: 1. Implementation Environment Configuration 1) Hardware environment: Kubernetes cluster (3 Master nodes: 16-core CPU, 64GB memory; 10 Worker nodes: 32-core CPU, 128GB memory, NVIDIA A10 GPU×1); 2) Software environment: Docker 24.0.6, Kubernetes 1.27, Spring Cloud Stream 4.0, MinIO RELEASE.2024-05-08T14-48-27Z, PostgreSQL 15, Redis 7.0; 3) Microservice versions: Geometry processing service V2.1, mesh generation service V3.0, solver management service V1.8 (supports ANSYS Mechanical 2023 R2, FLUENT 2023 R2), and post-processing service V2.5; 4) Simulation requirements: Engine blade structure-thermal coupling simulation, the process is "CAD model import → geometry repair → mesh generation (structure + fluid mesh) → two-way fluid-structure interaction solution → temperature / stress cloud map post-processing", the task priority is "high" and must be completed within 2 hours.

[0039] 2. Implementation Steps 2.1 Architecture Deployment and Service Registration: Complete the deployment of Kubernetes cluster, ESB, and distributed data layer, start 8 types of microservices, and each service automatically registers with ESB. The registry shows "3 instances of geometry processing service, 4 instances of mesh generation service, 2 instances of solver management service, and 2 instances of post-processing service". Resource utilization: CPU 25%, memory 30%; 2.2 Task Submission and Workflow Arrangement: Users upload the blade CAD model (STEP format, 80MB), select "Structure-Thermal Coupled Simulation Workflow", and submit it to the workflow arrangement microservice. The workflow is parsed into 5 sub-tasks: T1 (CAD Import and Repair), T2 (Structural Mesh Generation), T3 (Fluid Mesh Generation), T4 (Fluid-Structure Coupled Solution), and T5 (Post-processing). 2.3 Subtask Execution and Resource Scheduling: 1) T1 (Geometric Processing Service): Completes model repair within 3 seconds and sends the results to T2 and T3 via ESB (T2 and T3 are executed in parallel). 2) T2 (Mesh Generation Service): Generates a structured mesh (300,000 nodes, 90% hexahedrons), taking 12 seconds; T3 (Mesh Generation Service): Generates a fluid mesh (500,000 nodes, tetrahedrons), taking 18 seconds; 3) T4 (Solver Management Service): Receives two types of meshes, requests 16 CPU cores, 128GB memory, and 1 GPU from the resource scheduling center. The scheduling center triggers horizontal expansion (increasing the number of solver instances from 2 to 4), completes the expansion within 90 seconds, starts ANSYSMechanical and FLUENT to solve collaboratively, takes 1 hour and 20 minutes, and pushes progress in real time. 4) T5 (Post-processing service): Receives the coupled solution results (5GB), generates temperature cloud map (maximum temperature 850℃) and stress cloud map (maximum stress 350MPa), taking 5 seconds; 2.4 Results and Resource Recovery: Users can view the post-processing results and export a PDF report; after the solution is completed, the solver CPU utilization drops to 18%, the scheduling center reduces 2 instances (from 4 to 2), and releases 32 CPU cores and 256GB of memory resources.

[0040] 3. Implementation Results 1. Efficiency Improvement: Traditional single-platform systems require 3 hours to complete the same task, while this invention only requires 1 hour and 30 minutes, improving efficiency by 50%; task queuing time is reduced from 1 hour to 10 minutes; 2. Resource utilization: CPU utilization increased from 28% on traditional platforms to 78%, and GPU utilization increased from 15% to 82%; 3. Availability: During implementation, one mesh generation instance failed. The ESB automatically tripped and restarted, and the failure did not affect task execution. The platform availability reached 99.99%. 4. Scalability: Adding a new electromagnetic simulation microservice takes only 2 days (containerization + registration), without modifying the existing architecture, improving scalability by 90%.

[0041] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for constructing a microservice architecture for a service-oriented CAE simulation platform, characterized in that, Includes the following steps: Construct a microservice architecture, which includes a core microservice cluster, a unified service bus, a dynamic resource scheduling center, and a distributed data layer; The computer-aided engineering (CAE) simulation process is broken down into multiple microservices, and each microservice is packaged into a container image and deployed in the core microservice cluster. After each microservice starts, it sends a registration request containing a service identifier, network address and interface list to the unified service bus. The unified service bus maintains a service registry based on the registration request. The simulation process orchestration microservice in the core microservice cluster receives CAE simulation tasks and parses the CAE simulation tasks into an ordered sequence of subtasks containing dependencies. The unified service bus extracts the target service identifier and message tag of each subtask in the ordered subtask sequence, and distributes each subtask to the corresponding microservice for execution based on the two-layer routing strategy of the target service identifier and the message tag. During the execution of each subtask by each microservice, the dynamic resource scheduling center inputs the collected historical task load data and real-time task queue length into the long short-term memory neural network model and outputs resource prediction results. Based on the resource prediction results, it performs horizontal scaling operations by adjusting the number of microservice instances, or performs vertical scaling operations by adjusting the number of processor cores and memory quotas bound to the microservice instances while keeping them running. It also uses a two-factor scheduling algorithm that includes task priority factors and node load balancing factors to allocate computing node resources to the microservices. The data generated by each microservice is stored through the distributed data layer. The distributed data layer divides unstructured data into data shards and stores them in the object storage cluster in the form of multiple replicas, stores structured data in the relational database, stores business metadata in the cache cluster, and uses change data capture technology to monitor the change logs of the relational database and synchronize change events to the cache cluster.

2. The method according to claim 1, characterized in that, The process of breaking down the Computer-Aided Engineering (CAE) simulation workflow into multiple microservices includes: The CAE simulation process is functionally decoupled into a geometry processing microservice, a mesh generation microservice, a solver management microservice, a post-processing microservice, a simulation process orchestration microservice, a data management microservice, an external integration microservice, and a monitoring and alarm microservice, and each of the microservices is configured to run with independent computing resources.

3. The method according to claim 2, characterized in that, When distributing subtasks to their corresponding microservices for execution, the unified service bus employs the following communication and fault-tolerance mechanisms: For synchronous communication involving control commands and status queries, a descriptive state transition application programming interface (API) protocol is used for data interaction; for asynchronous communication involving mesh files or rendering result files, the WebSocket protocol is used for binary data push. For the procedure call communication of solver task scheduling, the gRPC protocol based on protocol buffer serialization is used for remote procedure calls. When the error rate of the target microservice is detected to be greater than the preset circuit breaker threshold, new call requests to the target microservice are blocked and a preset default response message is returned; When a network connection error is detected, an exponential backoff algorithm is used to initiate a preset number of retry calls at increasing time intervals; the call messages based on asynchronous communication are written to a distributed message queue system for persistent storage.

4. The method according to claim 1, characterized in that, Based on the resource prediction results, the process of performing horizontal scaling by adjusting the number of microservice instances, or performing vertical scaling by adjusting the number of processor cores and memory quotas bound to microservice instances while keeping them running, includes: When the processor utilization of a specific microservice is found to be greater than a preset high load threshold or the request queue length is greater than a preset queue threshold, a new container instance is created on an idle computing node to increase the number of microservice instances for that specific microservice. When the processor utilization of a specific microservice is found to be lower than a preset low load threshold for a preset period of time, container instances are recycled to reduce the number of microservice instances of that specific microservice. For a specific microservice, the underlying container orchestration interface is called to modify the processor core quota and memory capacity quota of the corresponding container, and the original process of the microservice instance is not interrupted during the process of modifying the quota parameters.

5. The method according to claim 2, characterized in that, The process of distributing each subtask to the corresponding microservice for execution includes: The geometry processing microservice receives the computer-aided design model, performs geometry repair and feature simplification operations to generate a repaired model, and routes the repaired model to the mesh partitioning microservice through the unified service bus. The mesh generation microservice receives the repaired model, performs mesh generation and mesh quality verification operations to generate a mesh file, and routes the mesh file to the solver management microservice through the unified service bus; The solver management microservice receives the mesh file, sends a computing resource request instruction to the dynamic resource scheduling center, and after obtaining the allocated processor and memory resources, starts the corresponding solver instance to perform physics field calculations to generate solution results, and routes the solution results to the post-processing microservice through the unified service bus. The post-processing microservice receives the solution result and performs data rendering operations to generate a cloud map data file containing the physical field distribution state.

6. A service-oriented CAE simulation platform microservice architecture construction system, characterized in that, The system for implementing the method of any one of claims 1 to 5 comprises: The core microservice cluster module contains multiple microservices that are packaged as container images and deployed on compute nodes. The multiple microservices include a simulation process orchestration microservice, which is configured to receive CAE simulation tasks and parse the CAE simulation tasks into an ordered sequence of subtasks containing dependencies. The unified service bus module communicates with the core microservice cluster module, is configured with a service registry maintained based on a server-side active registration and client-side subscription discovery mechanism, and is configured with a message routing component. The message routing component is configured to extract the target service identifier and message tag of each subtask in the ordered subtask sequence, and distribute each subtask to the corresponding microservice for execution based on a two-layer routing strategy of the target service identifier and the message tag. The dynamic resource scheduling center module is equipped with a resource prediction unit that embeds a long short-term memory neural network model. This unit inputs historical task load data and real-time task queue length into the long short-term memory neural network model to output resource prediction results. It also includes an elastic scaling execution unit and a two-factor scheduling unit. The elastic scaling execution unit is configured to perform horizontal scaling operations by adjusting the number of microservice instances based on the resource prediction results, or to perform vertical scaling operations by adjusting the number of processor cores and memory quotas bound to microservice instances while keeping them running. The two-factor scheduling unit uses a two-factor scheduling algorithm that includes task priority factors and node load balancing factors to allocate computing node resources to the microservices. The distributed data layer module communicates with the core microservice cluster module and the unified service bus module. It is configured to split unstructured data into data shards and store them in the object storage cluster in the form of multiple replicas, store structured data in the relational database, and store business metadata in the cache cluster. The distributed data layer module is configured with a change data capture middleware, which is used to monitor the change log of the relational database and synchronize the log change events to the cache cluster.

7. The system according to claim 6, characterized in that, The core microservice cluster module is divided into several microservices, including geometry processing microservice, mesh generation microservice, solver management microservice, post-processing microservice, simulation process orchestration microservice, data management microservice, external integration microservice, and monitoring and alarm microservice.

8. The system according to claim 6, characterized in that, The unified service bus module is equipped with a multi-protocol adapter and a fault-tolerant control component. The multi-protocol adapter includes a Representational State Transition Application Programming Interface (API) channel for handling synchronous communication, a WebSocket protocol channel for handling asynchronous communication, and a gRPC protocol channel based on protocol buffer serialization for handling procedure call communication. The fault tolerance control component is configured to block new request links to the target microservice when the call error rate of the target microservice is detected to be greater than a preset circuit breaker threshold, initiate retry calls by setting an incremental time interval using an exponential backoff algorithm when an abnormal network connection error is detected, and write asynchronous call messages to an external distributed message queue cluster.

9. The system according to claim 6, characterized in that, The elastic scaling execution unit in the dynamic resource scheduling center module is configured as follows: When receiving status data that the processor utilization of a specific microservice is greater than the preset high load threshold or the request queue length is greater than the preset queue threshold, a horizontal scaling instruction to create a new container instance is issued to the compute node. When receiving status data that the processor utilization of a specific microservice is less than the preset low load threshold and continues for a preset period of time, a horizontal scaling-down instruction to destroy the container instance is issued to the compute node. While keeping the microservice running without interruption, the underlying container engine's application programming interface (API) is invoked to execute vertical scaling instructions that update the processor core quota parameters and memory capacity quota parameters of a specific container process.

10. The system according to claim 7, characterized in that, The external integration microservice and monitoring / alerting microservice in the core microservice cluster module are configured as follows: The externally integrated microservice is configured with a representational state transition application programming interface and an open data protocol interface, which are used to receive data sent by an external computer-aided design system or product lifecycle management system to perform data synchronization operations. The monitoring and alarm microservice is connected to the system nodes and is configured to periodically extract the hardware resource utilization rate of each computing node and the request queue length of each microservice, and write the extracted status data into the time series database. The dynamic resource scheduling center module is also equipped with a cross-domain scheduling unit, which is used to encrypt and transmit the solution data of the simulation task to an idle computing cluster in a different location for scheduling and allocation when the available resources of the local computing cluster are insufficient to respond to the resource prediction result and the priority of the simulation task to be executed has not reached the high priority threshold.

Images