A cloud-native microservice system simulation method and tool based on an MWORKS simulation platform

Abstract

A cloud-native microservice system simulation method and tool based on an MWORKS simulation platform belong to the technical field of computer simulation. The method is: S1. Constructing a hierarchical simulation system overall architecture: the simulation system is divided into four layers from top to bottom: a Modelica model layer, which is used for constructing a topology model of a microservice system in an MWORKS Sysplorer platform by using a Modelica language; a C language interface layer, which is used for mapping functions in a C++ runtime dynamic library into functions that can be called by a Modelica simulation system, so as to interact with the model layer through a function calling mechanism; a C++ runtime core layer, which is used for accessing the simulation system in the form of a dynamic link library and serving as a calculation engine of the whole simulation system; and a strategy configuration layer, which is used for defining a simulation strategy through a strategy configuration file in a JSON format and supporting flexible configuration before simulation running; S2. Hybrid simulation execution; S3. Dual-mode hybrid running mechanism; and S4. Cross-language interface design. The application is used for cloud-native microservice system simulation.

Description

Technical Field

[0001] This invention belongs to the field of computer simulation technology, specifically relating to a hybrid simulation method and tool for microservice systems based on the MWORKS Sysplorer multi-domain unified modeling and simulation platform. This method uses the Modelica language for system topology modeling and simulation within the MWORKS Sysplorer platform, and performs cross-language hybrid programming through a C language interface and a C++ dynamic library. It belongs to the interdisciplinary technical fields of cloud-native infrastructure simulation, distributed system performance engineering, and multi-domain unified modeling and simulation. Background Technology

[0002] In recent years, with the rapid development of cloud-native technologies, microservice architecture has become the mainstream paradigm for building large-scale distributed systems. In microservice architecture, a traditional monolithic application is broken down into dozens or even hundreds of independently deployed microservice units, which communicate with each other through lightweight network protocols (such as HTTP / REST and gRPC). To manage the complexity of inter-service communication, the industry has introduced service mesh as an infrastructure layer, deploying sidecar proxies alongside each service instance to achieve functions such as traffic management, service discovery, load balancing, fault recovery, and secure communication.

[0003] Simulating microservice systems faces numerous challenges. First, the behavior of a microservice system is the result of the coupled effects of various factors such as network topology, communication latency, processing time, and scheduling strategies, making it difficult to predict using simple mathematical analytical models. Second, conducting large-scale load testing or fault drills on microservice systems in production environments is costly and risky, potentially leading to business interruptions or data corruption. Third, during the development and iteration of microservice systems, large-scale deployment and orchestration experiments using real systems present problems such as high resource requirements and deployment complexity, which are often unacceptable. Furthermore, due to the complex dependencies between microservices, simulation of service dependencies is also essential.

[0004] To address the aforementioned issues, the industry has proposed various simulation solutions. Existing microservice simulation technologies mainly fall into two categories:

[0005] The first category is based on mathematical modeling, which uses statistical models or differential equations to theoretically model the behavior of microservices, such as performance models based on queuing theory or Markov chains. The input to this type of method is a system-level abstract model and parameters, and the output is analytical results such as latency distribution. This type of method is more mathematical, lacks general-purpose tools and standardized implementations, and has limited practical applications.

[0006] The second category is based on pure software simulation, which uses general-purpose programming languages ​​(such as Python, Java, and Go) to build discrete event simulation models and simulate the behavior of microservice systems through event scheduling and time progression. This type of method can simulate application-layer business logic and some metrics, and can iterate quickly and support large-scale system simulation. However, this type of method usually has a high degree of abstraction, ignoring the real impact of factors such as network topology, bandwidth constraints, and routing strategies on system behavior.

[0007] Furthermore, existing simulation solutions generally lack the ability to "combine virtual and real"—that is, they cannot flexibly select simulated services or connect to real services in a simulation scenario. In microservice systems, the actual performance of microservices (such as response latency) is closely related to factors such as node status, which is difficult for simulated services to accurately simulate. Therefore, if certain real services and simulated services can be seamlessly integrated into the same simulation loop, the credibility and accuracy of simulation results can be greatly increased.

[0008] In summary, existing technologies have not yet provided a technical solution that can simultaneously meet the following requirements: (1) accurate modeling of network layer characteristics (bandwidth, routing, NAT); (2) efficient simulation of large-scale microservice clusters; and (3) support for the mixed operation of real services and simulated services in the same simulation. This invention is proposed to address the aforementioned technological gaps. Summary of the Invention

[0009] The purpose of this invention is to propose a cloud-native microservice system simulation method and tool based on the MWORKS simulation platform, aiming to solve the following technical problems existing in current microservice simulation technologies:

[0010] Problem 1: Insufficient accuracy in network layer simulation. Existing microservice simulation solutions typically simplify network communication to an ideal transmission model, failing to reflect the impact of dynamic constraints such as bandwidth constraints and routing topology on the performance of microservice systems in real networks. This invention aims to address the technical problem of accurately modeling network layer characteristics in simulation.

[0011] Problem 2: Lack of dual-mode simulation capability combining virtual and real elements. Existing simulation tools struggle to simultaneously support both "real microservice integration" and "data-driven simulated behavior" operating modes within the same simulation scenario. This invention aims to address the technical challenge of seamlessly integrating real and simulated services within the same simulation loop.

[0012] Question 3: Interface complexity and state management in cross-language simulation. When using the C language interface of MWORKS Sysplorer to combine Modelica with the C++ runtime, issues arise regarding data type mapping, memory lifecycle management, thread safety, and cross-language instance reference passing. This invention aims to solve the technical problem of establishing an efficient, secure, and type-compatible cross-language calling mechanism between the Modelica equation solver and the C++ runtime on the MWORKS Sysplorer platform.

[0013] This invention proposes a microservice system simulation method based on the MWORKS Sysplorer platform and C++ hybrid programming. This method leverages the multi-domain unified modeling capabilities of the MWORKS Sysplorer platform to decompose the microservice system simulation task into two dimensions: Within the MWORKS Sysplorer platform, the system topology model is constructed using the Modelica language, and simulation time progression is performed. The C++ layer, connected to the simulation system as a dynamic link library, is responsible for providing complex utility functions, high-performance request processing, and load calculation. Data exchange and control transfer between the Modelica layer and the C++ layer are achieved through the MWORKS Sysplorer C language interface.

[0014] The core innovation of this invention lies in proposing a dual-mode hybrid simulation architecture. Each service Pod group can be configured as either "simulation mode" or "real mode". Simulation mode simulates the request processing behavior of microservices through a pre-built JSONL data pool and configurable random latency distribution, without requiring the startup of external microservice instances. Real mode communicates with real microservice instances via an HTTP client and intercepts inter-service dependency calls through a built-in HTTP listener, re-injecting them into the simulation loop. Both modes can be deployed in the same simulation scenario.

[0015] This invention is particularly suitable for full-link behavior simulation of microservice systems based on service mesh architecture, and can be widely applied to engineering scenarios such as cloud computing platform capacity planning, microservice architecture performance evaluation, network topology optimization design and resilience testing.

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

[0017] A simulation method for a cloud-native microservice system based on the MWORKS simulation platform, the method comprising the following steps:

[0018] S1. Constructing the overall architecture of the hierarchical simulation system

[0019] The simulation system adopts a layered architecture, consisting of four layers from top to bottom:

[0020] The first layer: Modelica model layer, used to build the topology model of a microservice system using the Modelica language on the MWORKS Sysplorer platform;

[0021] The second layer is the C language interface layer, which is used to map functions in the C++ runtime dynamic library to functions that can be called by the Modelica simulation system based on the C language interface features provided by the MWORKS Sysplorer platform, so that the model layer can interact through the function call mechanism.

[0022] The third layer: the C++ runtime core layer, which is used to access the simulation system as a dynamic link library and serves as the computing engine for the entire simulation system;

[0023] The fourth layer is the strategy configuration layer, which is used to define simulation strategies through JSON-formatted strategy configuration files, supporting flexible configuration before simulation runs.

[0024] S2. Hybrid Simulation Execution

[0025] According to the set step size, the MWORKS Sysplorer solver drives the time progression, and executes user traffic generation, ingress routing, network topology forwarding, Pod processing, response return and statistical reporting in sequence.

[0026] S3. Dual-mode hybrid operation mechanism

[0027] In the same simulation scenario, Pod groups in both simulation and real modes are deployed in a mixed manner. The two modes are uniformly scheduled through the link policy in the topology configuration and appear to the outside world as the same simulation interface.

[0028] S4. Cross-language interface design

[0029] Data exchange and control transfer are achieved between the Modelica layer in the MWORKS Sysplorer platform and the C++ runtime through a C language interface.

[0030] Furthermore, the first layer of step S1, the Modelica model layer, includes the following components:

[0031] User component: Used to simulate user traffic generation and behavior simulation, supporting two access modes: simulated users and real users. Each sub-user has an independent source port and transmit timer.

[0032] IngressGateway component: As an ingress gateway, it is used to route user requests to the PodGroup that is the target service.

[0033] NetworkGateway component: As a gateway router, it provides transmission delay simulation and subnet routing functions, and has one upstream port and multiple downstream ports;

[0034] PhysicalMachine component: As a physical server, it hosts virtual machines and provides simulation hardware resource information and monitoring functions;

[0035] VirtualMachine component: As a virtual machine, it is used to host microservice Pods and supports full NAT functionality, local routing between Pods, and temporary port allocation and reclamation;

[0036] Sidecar component: As a service mesh sidecar proxy, it is deployed between the VirtualMachine component and the PodGroup component, and is responsible for service discovery and redirection of downstream requests;

[0037] PodGroup component: As an interface component with the C++ runtime layer, it is used to submit inbound packets and poll ready packets;

[0038] Connectors component: As a standardized connector interface, it is used to define the communication protocol between components;

[0039] The above components can be used to build any topology in the MWORKS Sysplorer platform via graphical drag-and-drop, and data flow between components is automatically transferred through connectors.

[0040] Furthermore, in the second layer of step S1, the C language interface layer includes the following interfaces:

[0041] HybridPodRuntime interface: used to create / destroy runtime instances, update the Pod list, submit inbound data packets, and poll the ready queue;

[0042] The UserRuntime interface is used to create / destroy user runtimes, send data packets, process response packets, and detect request timeouts.

[0043] NetQueue / VirtualNetQueue interface: used for creating physical / virtual network queues and enqueuing / dequeuing data packets;

[0044] The NatTable interface is used for creating NAT port mapping tables, allocating temporary ports, looking up ports, and releasing ports.

[0045] Statistics interface: used for registering and reporting statistical information in the Modelica layer;

[0046] The PacketDataStore interface is used for the global storage, querying, marking, and removal of JSON payloads from network packets in the simulation system.

[0047] The SidecarDispatchPolicy interface is used for PodGroup registration, service discovery, destination address decision-making, and ingress scheduling policy decision-making.

[0048] Furthermore, in the third layer of step S1, the core classes of the C++ runtime core layer include:

[0049] (1) HybridPodRuntime class: used to manage the entire runtime state of PodGroup, and internally maintains a thread pool to handle parallel processing requests; worker threads obtain tasks from the shared queue of pending tasks and execute them; the HybridPodRuntime defines three types of inbound data packets: UpstreamRequest, DownstreamResponse and ListenerResponse, and executes different processing logic according to the type of inbound data packet;

[0050] (2) UserRuntime class: used to manage user traffic generation, supporting both virtual and real modes;

[0051] In the virtual mode, UserRuntime calculates the next launch time for each sub-user based on the configured launch interval distribution, and constructs data packets by obtaining request data from the request pool. At the same time, it maintains an outstanding table to record the packet ID and launch time of each sent request for response matching and timeout detection.

[0052] In the real mode, UserRuntime creates a HybridUserListener instance to receive external HTTP requests, injects the requests into the simulation loop, and completes response matching.

[0053] (3) PacketDataStore class: used for thread-safe packet data storage, the key is a double type UUID, the value is a JSON string, supports registration, query, marking as consumed and removal operations, built-in background cleanup thread, periodically serializes the entries marked as consumed into a JSONL file and removes them from memory, realizing memory-controllable data lifecycle management;

[0054] (4) DynamicRingQueue template class: used for circular queues based on dynamic arrays, supporting automatic doubling and expansion;

[0055] (5) Statistics class: a time slot-based statistical subsystem that internally stores statistical data for each simulation time slot and optimizes the lookup performance of hotspot paths by caching pointers;

[0056] (6) NAT table class: used to manage the SNAT temporary port pool and use bitmaps to track port usage status;

[0057] (7) InstanceStore / PtrInstanceStore instance storage module template: used to provide basic instance management functions, support access to instances through credentials, and used as a C++ instance intermediary for Modelica layer operations;

[0058] (8) Random distribution sampling module: It provides three sampling functions: sim_rand_uniform, sim_rand_normal and sim_jitter. All sampling functions use the Mersenne Twister 64-bit random number engine of thread_local to achieve lock-free thread-safe random number generation.

[0059] Furthermore, (1) in the HybridPodRuntime class, different processing logic is executed in the following two modes according to the type of inbound data packet:

[0060] In simulation mode, the upstream request processing flow of HybridPodRuntime is as follows:

[0061] (a) Retrieve the JSON payload of inbound data from PacketDataStore;

[0062] (b) Call the sample_delay() method to sample and process the delay according to the configured delay distribution and simulate the delay;

[0063] (c) If downstream dependencies are configured, sequential chaining of multiple downstream calls is implemented through the PendingDownstreamContext structure; when all downstream processes are completed, data is retrieved from the final response pool to construct the upstream response packet;

[0064] (d) Enqueue the constructed response packet into the ReadyPacketQueue.

[0065] Furthermore, in the fourth layer of step S1, the policy configuration file of the policy configuration layer includes:

[0066] topology.json: Used to define the dependency chain strategy and entry strategy between services;

[0067] pod_policy.json: This file defines the running mode, service name, mapped port, initial number of Pods, and detailed configuration for each PodGroup.

[0068] user_policy.json: Used to define the IP address of the user group, the number of sub-users, the request pool configuration, the timeout time and the distribution parameters of the transmission interval;

[0069] nat_policy.json: Used to define NAT timeout configuration;

[0070] stats_policy.json: Used to define the statistics persistence configuration;

[0071] packet_data_policy.json: Used to define the packet storage policy.

[0072] Furthermore, in step S2, the hybrid simulation execution follows the following timing loop:

[0073] S21.MWORKS Sysplorer Solver Time Advancement: The equation solver of the MWORKS Sysplorer platform advances the simulation time variable by a set step size to perform discrete-time simulation;

[0074] S22. User traffic generation: The User component calls UserRuntime.TryEmit() to attempt to send data packets; in virtual mode, it polls the emission timer of each sub-user; in real mode, it retrieves the data packets injected by HybridUserListener from ready_queue, and successfully obtained data packets are sent to IngressGateway through the connector;

[0075] S23. Ingress Routing: The IngressGateway component receives user data packets, obtains the target service name, and forwards the data packets with the modified destination address to NetworkGateway based on load balancing decisions;

[0076] S24. Network topology forwarding: The Network Gateway first obtains data packets from the connected interface, and then pushes the data packets into the sending queue of the corresponding downstream port according to the subnet matching; after receiving the packets, the PhysicalMachine routes them to the target VirtualMachine according to the routing; the VirtualMachine performs DNAT checks and Pod local routing, and pushes the data packets into the downstream queue of the target Pod.

[0077] S25. Pod processing: The PodGroup calls HybridPodRuntime.SubmitIncoming() to submit the inbound data packet. The C++ runtime executes the corresponding processing logic according to the inbound type and the worker thread pool, and after generating the response packet, it is enqueued into ReadyPacketQueue.

[0078] S26. Response backhaul: PodGroup calls HybridPodRuntime.PopReady() to poll the ready queue, obtains the response packet, and then backhauls it in reverse along the original path, via VirtualMachine→PhysicalMachine→NetworkGateway→IngressGateway→User. UserRuntime matches outstanding requests or suspended requests of HybridUserListener and records the response delay.

[0079] S27. Statistical Reporting: Each core component periodically calls the statistics subsystem to report its own status data according to STATS_REPORT_INTERVAL.

[0080] Furthermore, in step S3, the dual-mode hybrid operation mechanism allows different PodGroups in the same simulation scenario to be independently configured as either simulation mode or real mode:

[0081] Simulation mode: The Pod group does not start the HTTP client and listener. Instead, it reads fake data directly from the JSONL data pool in the worker thread of HybridPodRuntime, and constructs the response packet after delaying according to the configured latency distribution.

[0082] Real Mode: The Pod group sends an HTTP POST request to the URL of the real microservice instance via HttpClient; if the Pod group has downstream dependencies, an additional HybridListener instance is started to listen on a specified port; when the real microservice calls the downstream service, the HTTP request is intercepted by HybridListener and injected into the simulation loop. After the downstream response is transmitted back through the simulation network, HybridListener returns the response to the real microservice, making the call chain of the real microservice transparently penetrate the simulation network;

[0083] The two modes are uniformly scheduled through the link policy in the topology configuration.

[0084] Furthermore, in step S4, the cross-language interface design includes:

[0085] Type Mapping: The mapping method is as follows: Modelica's Real type MoReal is mapped to double, MoInteger to int, MoBoolean to int, and MoString to double. All cross-language types are uniformly declared through the mo_type.h header file;

[0086] Credential mechanism: The slot pool is maintained internally through the InstanceStore / PtrInstanceStore template, and the slot index is returned to Modelica as a credential in double type;

[0087] Thread safety: All data structures that may be accessed concurrently by the Modelica main thread and C++ worker threads are protected by std::mutex;

[0088] Dynamic library export: All functions are exported using the MWORKS_EXPORT macro.

[0089] A cloud-native microservice system simulation tool based on the MWORKS simulation platform, the simulation tool comprising:

[0090] Modelica model layer: Deployed on the MWORKS Sysplorer platform, it is used to build the topology model of the microservice system and perform simulation time progression;

[0091] C Language Interface Layer: Connects the Modelica model layer and the C++ runtime core layer, used to implement bidirectional data exchange and control transmission;

[0092] The C++ runtime core layer is used to connect to the simulation system as a dynamic link library.

[0093] Instance storage module templates: used to provide templated management of InstanceStore / PtrInstanceStore;

[0094] Random distribution sampling module: used to provide delayed sampling functions for uniform distribution, normal distribution, and fixed values;

[0095] Policy configuration layer: This layer provides configuration files for topology.json, pod_policy.json, user_policy.json, and nat_policy.json, and supports flexible switching between simulation mode and real mode as well as parameter configuration.

[0096] The C++ runtime core layer includes:

[0097] HybridPodRuntime class unit: Used to manage the runtime state of Pod groups and maintain a thread pool to handle parallel requests;

[0098] UserRuntime class unit: Used to manage user traffic generation and request initiation;

[0099] PacketDataStore class unit: used to manage the storage and retrieval of data packets;

[0100] DynamicRingQueue template class unit: used to provide a thread-safe ring queue data structure;

[0101] The Statistics class unit is responsible for collecting and reporting simulation statistics.

[0102] NAT table class unit: used to manage network address translation and timeout configuration.

[0103] The advantages of this invention over the prior art are:

[0104] I. Improved Simulation Accuracy

[0105] This invention achieves high-precision full-stack simulation of microservice systems by combining the multi-domain unified modeling capabilities of the MWORKS Sysplorer platform with fine-grained logic computation in C++. Specifically, it is reflected in:

[0106] 1. Precise Network Layer Modeling: Unlike traditional simulation tools that simplify network transmission to varying degrees, this invention accurately characterizes the impact of network topology on microservice system performance through bandwidth constraint calculation and propagation delay simulation, multi-level routing decisions using PhysicalMachine, and complete NAT translation using VirtualMachine. In the simulation, the readiness time of each data packet is determined by both link latency and link busy status, rather than by simply adding fixed delays or using theoretical calculations based on mathematical methods such as queuing theory.

[0107] 2. Multi-level service scheduling simulation: This invention implements a three-level load balancing model from the ingress gateway to the sidecar to the pod group, fully replicating the complete scheduling path of a request in the service mesh from user submission to final processing.

[0108] II. Improved Simulation Efficiency

[0109] 1. Thread Pool Parallel Computing (parallel computing refers to the behavior of "multiple threads processing simultaneously"): Modules such as HybridPodRuntime adopt a thread pool architecture, which separates request processing from the main MWORKS Sysplorer simulation thread and executes it in parallel by multiple worker threads, thus making full use of multi-core processors. In large-scale simulation scenarios (such as 128 concurrent worker threads), a near-linear speedup can be achieved compared to single-threaded mode.

[0110] 2. Thread-local random number generation: The delayed sampling function uses the Mersenne Twister random number engine of thread_local, which completely eliminates the lock contention overhead under multi-threaded concurrency and ensures sampling efficiency in high-concurrency scenarios.

[0111] 3. Optimization of the statistics subsystem: The time-slot-based statistics architecture avoids map lookups during each report by caching pointers, and places time-consuming operations such as memory release outside the mutex lock when data is written to disk, reducing the latency caused by a large number of data operations; at the same time, the query interface implements transparent rollback from memory to disk, minimizing memory usage while ensuring data integrity.

[0112] III. The flexibility of combining the real and the virtual

[0113] The dual-mode hybrid operation mechanism of this invention provides great flexibility for the development, testing, and operation of microservice systems:

[0114] 1. Progressive simulation: The development team can switch simulated Pods to real Pods one by one according to the service readiness, and can perform system-level debugging in the early stages of development without waiting for all services to be developed.

[0115] 2. Hybrid Scenario Load Testing: Core services can be configured in real mode, while non-critical services can be configured in simulation mode, enabling large-scale load testing under limited real service resources.

[0116] 3. Fault Injection and Resilience Testing: By configuring specific latency distributions or error responses in simulation mode, various abnormal scenarios can be simulated without modifying the real code.

[0117] 4. Offline simulation: In full simulation mode, a complete simulation can be run without a network connection or external services, making it suitable for developers' local development environment or prototype verification.

[0118] IV. Scalability and Universality

[0119] 1. Component-based MWORKS Sysplorer Model: Each model component communicates within the MWORKS Sysplorer platform via standardized connector interfaces. Adding new topology components simply requires implementing the corresponding connector to seamlessly integrate into existing simulation systems. Furthermore, leveraging the platform's graphical modeling capabilities, even non-developers can quickly build simulation systems by dragging and dropping and connecting graphics.

[0120] 2. Templated C++ Architecture: The DynamicRingQueue template class and the InstanceStore / PtrInstanceStore template class can provide queue and instance management functions for any data type, supporting rapid expansion of functional modules.

[0121] 3. Fully configurable strategy management: Simulation strategies are described through JSON files. Modifying the simulation scenario only requires changing the configuration file without modifying the code, avoiding time-consuming recompilation.

[0122] 4. Multi-platform support: The C++ runtime is adapted to Windows and Linux operating systems through MWORKS cross-platform macros, and can be deployed to different simulation environments.

[0123] V. Practicality of the Project

[0124] 1. Extensive runtime diagnostics: Each component exposes detailed runtime state variables and statistical counters, supporting real-time monitoring and performance analysis.

[0125] 2. Automated build system: CMake build scripts automatically retrieve dependency libraries via FetchContent, while PowerShell build scripts provide one-click compilation functionality. Attached Figure Description

[0126] Figure 1 This is a flowchart of the cloud-native microservice system simulation method based on the MWORKS simulation platform of the present invention;

[0127] Figure 2 This is a schematic diagram of the structure of the cloud-native microservice system simulation tool based on the MWORKS simulation platform of the present invention. Detailed Implementation

[0128] like Figure 1 , Figure 2 As shown in the figure, this embodiment describes a cloud-native microservice system simulation method based on the MWORKS simulation platform. The method includes the following steps:

[0129] S1. Constructing the overall architecture of the hierarchical simulation system

[0130] The simulation system adopts a layered architecture, consisting of four layers from top to bottom:

[0131] The first layer: Modelica model layer, used to build the topology model of a microservice system using the Modelica language on the MWORKS Sysplorer platform;

[0132] The second layer is the C language interface layer, which is used to map functions in the C++ runtime dynamic library (hybrisim_runtime.dll) to functions that can be called by the Modelica simulation system based on the C language interface features provided by the MWORKS Sysplorer platform, so that the model layer can interact through the function call mechanism.

[0133] The third layer: the C++ runtime core layer, which is used to access the simulation system as a dynamic link library (hybrisim_runtime.dll) and serves as the computing engine for the entire simulation system;

[0134] The fourth layer is the strategy configuration layer, which is used to define simulation strategies through JSON-formatted strategy configuration files, supporting flexible configuration before simulation runs.

[0135] S2. Hybrid Simulation Execution

[0136] Based on the overall architecture of the hierarchical simulation system constructed in step S1, the Modelica model layer calls the C++ runtime core layer through the C language interface layer, and according to the simulation strategy loaded by the strategy configuration layer, the time advances according to the set step size, driven by the MWORKSSysplorer solver, and sequentially executes user traffic generation, ingress routing, network topology forwarding, Pod processing, response feedback and statistical reporting.

[0137] S3. Dual-mode hybrid operation mechanism (one of the key innovations of this invention)

[0138] During the hybrid simulation execution process described in step S2, based on the Pod running mode and topology link policy defined in the policy configuration layer, Pod groups in simulation mode and real mode are deployed in the same simulation scenario. The two modes are uniformly scheduled through the link policy in the topology configuration and appear to the outside world as the same simulation interface.

[0139] S4. Cross-language interface design

[0140] To enable the Modelica model layer to call the C++ runtime core layer in step S2 and to achieve unified scheduling of Pod groups in simulation mode and real mode in step S3, a unified cross-language interface protocol was designed. Data exchange and control transmission are achieved between the Modelica layer and the C++ runtime in the MWORKSSysplorer platform through the C language interface.

[0141] Furthermore, the first layer of step S1, the Modelica model layer, includes the following (core) components:

[0142] User component: Used to simulate user traffic generation and behavior simulation, supporting two access modes: simulated users and real users. Each sub-user has an independent source port and transmit timer.

[0143] IngressGateway component: As an ingress gateway, it is used to route user requests to the PodGroup that is the target service.

[0144] NetworkGateway component: As a gateway router, it provides transmission delay simulation and subnet routing functions, and has one upstream port and multiple downstream ports;

[0145] PhysicalMachine component: As a physical server, it hosts virtual machines and provides simulation hardware resource information and monitoring functions;

[0146] VirtualMachine component: As a virtual machine, it is used to host microservice Pods and supports full NAT (SNAT / DNAT) functionality, local routing between Pods, and temporary port allocation and reclamation;

[0147] Sidecar component: As a service mesh sidecar proxy, it is deployed between the VirtualMachine component and the PodGroup component, and is responsible for service discovery and redirection of downstream requests;

[0148] PodGroup component: As an interface component with the C++ runtime layer, it is used to submit inbound packets and poll ready packets;

[0149] Connectors component: As a standardized connector interface, it is used to define the communication protocol between components;

[0150] The above components can be used to build any topology in the MWORKS Sysplorer platform via graphical drag-and-drop, and data flow between components is automatically transferred through connectors.

[0151] Furthermore, in the second layer of step S1, the C language interface layer includes the following interfaces:

[0152] HybridPodRuntime interface: used to create / destroy runtime instances, update the Pod list, submit inbound data packets, and poll the ready queue;

[0153] The UserRuntime interface is used to create / destroy user runtimes, send data packets, process response packets, and detect request timeouts.

[0154] NetQueue / VirtualNetQueue interface: used for creating physical / virtual network queues and enqueuing / dequeuing data packets;

[0155] The NatTable interface is used for creating NAT port mapping tables, allocating temporary ports, looking up ports, and releasing ports.

[0156] Statistics interface: used for registering and reporting statistical information in the Modelica layer;

[0157] The PacketDataStore interface is used for the global storage, querying, marking, and removal of JSON payloads from network packets in the simulation system.

[0158] The SidecarDispatchPolicy interface is used for PodGroup registration, service discovery, destination address decision-making, and ingress scheduling policy decision-making.

[0159] Furthermore, in the third layer of step S1, the core classes of the C++ runtime core layer include:

[0160] (3) HybridPodRuntime class: Used to manage the entire runtime state of PodGroup, internally maintaining a thread pool to handle parallel processing requests; worker threads obtain tasks from the shared queue of pending tasks and execute them, while the main simulation thread (Modelica layer) is only responsible for submitting tasks and polling the result queue. The HybridPodRuntime class defines three types of inbound data packets: UpstreamRequest (new upstream request), DownstreamResponse (response returned by downstream), and ListenerResponse (response returned by downstream intercepted by the listener), and executes different processing logic according to the type of inbound data packet;

[0161] (4) UserRuntime class: used to manage user traffic generation, supporting both virtual and real modes;

[0162] In the virtual mode, UserRuntime is distributed according to the configured transmission interval (uniform distribution is also supported). ,normal distribution (Including three fixed modes) calculate the next launch time for each sub-user, and construct data packets by obtaining request data from the request pool. At the same time, it maintains an outstanding table to record the packet ID and sending time of each sent request for response matching and timeout detection.

[0163] In the real mode, UserRuntime creates a HybridUserListener instance to receive external HTTP requests, injects the requests into the simulation loop, and completes response matching.

[0164] (3) PacketDataStore class: used for thread-safe packet data storage, the key is a double type UUID, the value is a JSON string, supports registration, query, marking as consumed and removal operations, built-in background cleanup thread, periodically (according to the time interval specified in the user configuration file) serializes the entries marked as consumed into a JSONL file and removes them from memory, realizing memory-controllable data lifecycle management;

[0165] (4) DynamicRingQueue template class: used for circular queues based on dynamic arrays, supporting automatic doubling and expansion (maximum capacity is configured by queue_config); uses copy-and-swap mode to ensure exception safety: when expanding, new memory is allocated first and elements are moved, and then the old memory is released. The queue is automatically expanded when it is full, and new elements are discarded and drop_count is recorded after the maximum capacity limit is reached. It is used to derive various queues, including data packet queues for various Modelica models, etc.

[0166] (5) Statistics class: a time-slot-based statistical subsystem that internally uses std::map<sim_time_slot, StatsData> It stores statistical data for each simulation time slot and optimizes the lookup performance of hotspot paths through cached pointers; it supports statistical mode registration, single-value and batch statistical reporting. A background thread periodically serializes closed time slot data into JSON files and writes them to disk, while simultaneously removing them from memory. The query interface automatically falls back to disk file lookup when memory is not found.

[0167] (6) NAT table class: used to manage the SNAT temporary port pool (49152 to 65535), using a bitmap to track the port usage status; the background cleanup thread periodically releases expired port mappings according to the configured timeout period (default 30 seconds);

[0168] (7) InstanceStore / PtrInstanceStore instance storage module template: used to provide basic instance management functions, support access to instances via certificates, and be used as a C++ instance intermediary for Modelica layer operations;

[0169] (8) Random distribution sampling module: It provides three sampling functions: sim_rand_uniform (uniform distribution), sim_rand_normal (truncated normal distribution based on Box-Muller transformation) and sim_jitter (amplitude jitter). All sampling functions use the Mersenne Twister 64-bit random number engine (std::mt19937_64) of thread_local to achieve lock-free thread-safe random number generation.

[0170] Furthermore, (1) in the HybridPodRuntime class, different processing logic is executed in the following two modes according to the type of inbound data packet:

[0171] In simulation mode, the upstream request processing flow of HybridPodRuntime is as follows:

[0172] (e) Retrieve the JSON payload of inbound data from PacketDataStore;

[0173] (f) Call the sample_delay() method to sample and process the delay according to the configured delay distribution (uniform distribution, normal distribution, or fixed value) and simulate the delay;

[0174] (g) If downstream dependencies are configured, sequential chaining of multiple downstream requests is implemented through the PendingDownstreamContext structure (which records upstream request information, current Pod index, Pod IP, and the index of the next downstream to be processed); when all downstream requests are completed, data is retrieved from the final response pool to construct the upstream response package.

[0175] (h) Enqueue the constructed response packet into the ReadyPacketQueue;

[0176] In real mode, HybridPodRuntime sends HTTP POST requests to the real microservice instance via HttpClient (based on the CPR library). If the Pod group declares downstream dependencies, a HybridListener instance is created during construction (if no downstream dependencies are declared, no HybridListener instance is created), listens on a specified port, and intercepts packets generated by the real microservice (including return packets and downstream request packets). HybridListener uses the httplib library to implement HTTP server functionality, distinguishing different Pod instances and downstream target services by URL path prefixes. Intercepted downstream calls are implemented through std::promise / std::future mechanisms to achieve cross-thread synchronous blocking and waiting, and are returned to the real microservice after the simulation loop returns a response.

[0177] Furthermore, in the fourth layer of step S1, the policy configuration file of the policy configuration layer includes:

[0178] topology.json: Used to define the dependency chain strategy between services (e.g., the scheduling strategy for "svc-a → svc-b" is "round_robin") and the entry strategy;

[0179] pod_policy.json: Used to define the running mode (real / simulated), service name, mapped port, initial number of Pods for each PodGroup, as well as detailed configurations for each mode (base URL and listener port for real mode, downstream services and latency distribution parameters for simulated mode).

[0180] user_policy.json: Used to define the IP address of the user group, the number of sub-users, the request pool configuration, the timeout time and the distribution parameters of the transmission interval;

[0181] nat_policy.json: Used to define NAT timeout configuration;

[0182] stats_policy.json: Used to define the statistics persistence configuration;

[0183] packet_data_policy.json: Used to define the packet storage policy.

[0184] The strategy configuration file is lazily loaded via a static const local variable when first accessed at C++ runtime, leveraging the thread-safe initialization features guaranteed by the C++11 standard to avoid explicit locking. All strategy configuration files can be configured with a default configuration file and a model-specific configuration file.

[0185] Furthermore, in step S2, the hybrid simulation execution follows the following timing loop (each simulation step is TICK_TIME, default 0.1 milliseconds):

[0186] S21.MWORKS Sysplorer Solver Time Advancement: The equation solver of the MWORKS Sysplorer platform advances the simulation time variable by a set step size (TICK_TIME) to perform discrete-time simulation;

[0187] S22. User traffic generation: The User component calls UserRuntime.TryEmit() to attempt to send data packets; in virtual mode, it polls the emission timer of each sub-user; in real mode, it retrieves the data packets injected by HybridUserListener from ready_queue, and successfully obtained data packets are sent to IngressGateway through the connector;

[0188] S23. Ingress Routing: The IngressGateway component receives user data packets, obtains the target service name (supports dynamic target service coverage based on request granularity in real mode), and forwards the data packets with the modified destination address to NetworkGateway according to the load balancing decision (Round-Robin or Random).

[0189] S24. Network topology forwarding: The Network Gateway first obtains data packets from the connected interfaces (one upstream and multiple downstream), and then pushes the data packets into the sending queue (PhysicalMachine) of the corresponding downstream port according to the subnet matching; after receiving the packets, the PhysicalMachine routes them to the target VirtualMachine according to the routing; the VirtualMachine performs DNAT checks and Pod local routing, and pushes the data packets into the downstream queue of the target Pod;

[0190] S25. Pod processing: The PodGroup calls HybridPodRuntime.SubmitIncoming() to submit the inbound data packet. The C++ runtime executes the corresponding processing logic according to the inbound type and the worker thread pool, and after generating the response packet, it is enqueued into ReadyPacketQueue.

[0191] S26. Response backhaul: PodGroup calls HybridPodRuntime.PopReady() to poll the ready queue, obtains the response packet, and then backhauls it in reverse along the original path, via VirtualMachine→PhysicalMachine→NetworkGateway→IngressGateway→User. UserRuntime matches outstanding requests or suspended requests of HybridUserListener and records the response delay.

[0192] S27. Statistical Reporting: Each core component periodically calls the statistical subsystem to report its own status data according to STATS_REPORT_INTERVAL (default 0.1 seconds simulation time).

[0193] Furthermore, in step S3, the dual-mode hybrid operation mechanism allows different PodGroups in the same simulation scenario to be independently configured as either simulation mode or real mode:

[0194] Simulation mode: The Pod group does not start the HTTP client and listener. Instead, it reads fake data directly from the JSONL data pool in the worker thread of HybridPodRuntime, and constructs the response packet after delaying according to the configured latency distribution. No external microservice instance needs to be deployed, which is suitable for early development or pure simulation verification scenarios.

[0195] Real Mode: The Pod group sends an HTTP POST request to the URL of the real microservice instance via HttpClient; if the Pod group has downstream dependencies, an additional HybridListener instance is started to listen on a specified port; when the real microservice calls the downstream service, the HTTP request is intercepted by HybridListener and injected into the simulation loop. After the downstream response is transmitted back through the simulation network, HybridListener returns the response to the real microservice, making the call chain of the real microservice transparently penetrate the simulation network.

[0196] The two modes are uniformly scheduled through the link strategy in the topology configuration. Simulated Pods and real Pods present the same simulation interface to the outside world, realizing an engineering practice model of progressive simulation: the full simulation mode is used to quickly verify the system architecture in the early stages of development; as the services gradually become ready, the corresponding Pod groups are switched to real mode; ultimately, full-link real service simulation verification is achieved. At the same time, the existence of the simulation mode can replace some services with less impact on the simulation effect, reducing the resources required for simulation.

[0197] Furthermore, in step S4, the cross-language interface design includes:

[0198] Type Mapping: Since the data types in Modelica do not completely correspond to those in C / C++, this invention provides a mapping method as follows: Modelica's Real type MoReal is mapped to double (64-bit floating-point), MoInteger to int, MoBoolean to int, and MoString to... All cross-language types are uniformly declared through the mo_type.h header file;

[0199] Credential Mechanism: Since instances in the C++ runtime (NetQueue, HybridPodRuntime, NatTable, etc.) cannot directly expose pointers to the Modelica layer, this invention maintains a slot pool internally through the InstanceStore / PtrInstanceStore template, returning the slot index as a double type to Modelica as a credential. The Modelica layer accesses the corresponding instance by passing the credential through function calls. The return values ​​of the corresponding functions are all basic types supported by Modelica, thus solving the problem of data type interoperability between Modelica and C++.

[0200] Thread safety: All data structures that may be accessed concurrently by the Modelica main thread and C++ worker threads are protected by std::mutex. Worker threads only operate on internal data structures and do not directly call back to the Modelica layer.

[0201] Dynamic library export: All extern "C" functions are marked as exported using the MWORKS_EXPORT macro (__declspec(dllexport) on Windows) to ensure that MWORKS Sysplorer can correctly load and resolve symbols.

[0202] Specific Implementation Method Two: This implementation method describes a cloud-native microservice system simulation tool based on the MWORDS simulation platform. It performs cloud-native microservice system simulation based on the cloud-native microservice system simulation method of Specific Implementation Method One. The simulation tool includes:

[0203] Modelica model layer: Deployed on the MWORKS Sysplorer platform, it is used to build the topology model of the microservice system and perform simulation time progression;

[0204] C Language Interface Layer: Connects the Modelica model layer and the C++ runtime core layer, used to implement bidirectional data exchange and control transmission;

[0205] The C++ runtime core layer is used to connect to the simulation system as a dynamic link library.

[0206] Instance storage module templates: used to provide templated management of InstanceStore / PtrInstanceStore;

[0207] Random distribution sampling module: used to provide delayed sampling functions for uniform distribution, normal distribution, and fixed values;

[0208] Policy configuration layer: This layer provides configuration files for topology.json, pod_policy.json, user_policy.json, and nat_policy.json, and supports flexible switching between simulation mode and real mode as well as parameter configuration.

[0209] The C++ runtime core layer includes:

[0210] HybridPodRuntime class unit: Used to manage the runtime state of Pod groups and maintain a thread pool to handle parallel requests;

[0211] UserRuntime class unit: Used to manage user traffic generation and request initiation;

[0212] PacketDataStore class unit: used to manage the storage and retrieval of data packets;

[0213] DynamicRingQueue template class unit: used to provide a thread-safe ring queue data structure;

[0214] The Statistics class unit is responsible for collecting and reporting simulation statistics.

[0215] NAT table class unit: used to manage network address translation and timeout configuration.

[0216] Example 1:

[0217] This embodiment describes a microservice system simulation scenario based entirely on simulation mode (full simulation mode simulation scenario), which is used to verify system architecture and evaluate performance without the need for any external microservices.

[0218] a. Scene Configuration

[0219] The simulation scene includes the following components and their connections:

[0220] User node User-1 is connected to IngressGateway via a communication link. IngressGateway is connected to NetworkGateway, and NetworkGateway is connected to a PhysicalMachine. This PhysicalMachine hosts three virtual machines: VM-1, VM-2, and VM-3.

[0221] Under VM-1, there is a SidecarA and its associated PodGroupA, which corresponds to service svc-a; and a SidecarI and its associated PodGroupI, which corresponds to service svc-i.

[0222] Under VM-2, there is a SidecarB and its associated PodGroupB, which corresponds to the service svc-b; and a SidecarJ and its associated PodGroupJ, which corresponds to the service svc-j.

[0223] Under VM-3, SidecarK and its associated PodGroupK are deployed, corresponding to the service svc-k.

[0224] The dependencies between services are as follows:

[0225] PodGroupA (svc-a) depends on PodGroupB (svc-b); PodGroupI (svc-i) depends on PodGroupJ (svc-j); PodGroupJ (svc-j) depends on PodGroupK (svc-k).

[0226] The above call chain is defined by specific rules in the topology configuration file (topology.json).

[0227] b. Key configuration files

[0228] topology.json

[0229] {

[0230] "links": [

[0231] { "from": "svc-a", "to": "svc-b", "policy": "round_robin"},

[0232] { "from": "svc-i", "to": "svc-j", "policy": "random"},

[0233] { "from": "svc-j", "to": "svc-k", "policy": "round_robin"}

[0234] ,

[0235] "ingress":

[0236] { "service_name": "svc-a", "policy": "round_robin"},

[0237] { "service_name": "svc-i", "policy": "round_robin"}

[0239] }

[0240] pod_policy.json, taking svc-a as an example

[0241] {

[0242] "pod_group_name": "A1_sim",

[0243] "selection_policy": "round_robin",

[0244] "initial_count": 2,

[0245] "service_name": "svc-a",

[0246] "map_port": 9443,

[0247] "mode": "simulated",

[0248] "simulated": {

[0249] "has_downstream": true,

[0250] "downstreams":

[0251] {

[0252] "service_name": "svc-b",

[0253] "pool": {

[0254] ​"jsonl_path": "pool / svc_a_to_svc_b.jsonl",

[0255] "mode": "round_robin"

[0256] }

[0257] }

[0258] ],

[0259] "response_pool": {

[0260] "jsonl_path": "pool / svc_a_response.jsonl",

[0261] "mode": "random"

[0262] },

[0263] "delay": {

[0264] "distribution": "normal",

[0265] "mean_s": 0.03,

[0266] "sigma_s": 0.005,

[0267] "lo_s": 0.01,

[0268] "hi_s": 0.10

[0269] }

[0270] }

[0271] }

[0272] user_policy.json

[0273] {

[0274] "users": [

[0275] {

[0276] "user_name": "user-buyer",

[0277] "mode": "real",

[0278] "ip": [10, 13, 13, 10],

[0279] "count": 50,

[0280] "source_port_range": [49152, 65535],

[0281] "real": {

[0282] "listener_port": 30720,

[0283] "request_timeout_s": 30.0,

[0284] },

[0285] "response_timeout_s": 60.0,

[0286] "outstanding_buffer_size": 2048

[0287] } ]

[0289] }

[0290] c. Key parameters

[0291] Simulation step size: TICK_TIME = 0.0001 seconds (0.1ms)

[0292] Statistical reporting interval: STATS_REPORT_INTERVAL = 0.1 seconds

[0293] Network Gateway link bandwidth: 1 Gbps

[0294] NetworkGateway link propagation delay: 0.001 seconds

[0295] Number of worker threads: 4 (default)

[0296] Delay distribution: Normal distribution (mean 30ms, standard deviation 5ms, range [10ms, 100ms]).

[0297] Example 2: Hybrid Simulation Scenarios Combining Reality Mode and Simulation Mode

[0298] This embodiment describes a hybrid simulation scenario, in which svc-a uses real mode to connect to the actual running microservices, and svc-b uses simulation mode.

[0299] a. Scene Configuration

[0300] The simulation scene includes the following components and their connections:

[0301] User node User-1 is connected to IngressGateway via a communication link; IngressGateway is connected to NetworkGateway; NetworkGateway is connected to a PhysicalMachine. This PhysicalMachine hosts three virtual machines, namely VM-1 and VM-2.

[0302] Under VM-1, SidecarA and its associated PodGroupA are deployed, corresponding to service svc-a, and configured in real mode.

[0303] Under VM-2, SidecarB and its associated PodGroupB are deployed, corresponding to the service svc-b, and configured in simulation mode.

[0304] The dependencies between services are as follows:

[0305] PodGroupA (svc-a) depends on PodGroupB (svc-b).

[0306] The above call chain is defined by specific rules in the topology configuration file (topology.json).

[0307] b. Key configuration files

[0308] topology.json

[0309] {

[0310] "links": [

[0311] { "from": "svc-a", "to": "svc-b", "policy": "round_robin"}

[0312] ],

[0313] "ingress": [

[0314] { "service_name": "svc-a", "policy": "round_robin"} ]

[0316] }

[0317] pod_policy.json, taking svc-a as an example

[0318] {

[0319] "pod_group_name": "A1",

[0320] "selection_policy": "round_robin",

[0321] "initial_count": 1,

[0322] "service_name": "svc-a",

[0323] "map_port": 9443,

[0324] "mode": "real",

[0325] "real": {

[0326] "service_base_urls": ["http: / / 127.0.0.1:9443"],

[0327] "request_timeout_s": 5.0,

[0328] "req_path": " / req",

[0329] "has_downstream": true,

[0330] "listener_port": 9500,

[0331] "listener_paths": [" / 1 / "]

[0332] }

[0333] }

[0334] user_policy.json

[0335] {

[0336] "users": [

[0337] {

[0338] "user_name": "user-buyer",

[0339] "mode": "real",

[0340] "ip": [10, 13, 13, 10],

[0341] "count": 50,

[0342] "source_port_range": [49152, 65535],

[0343] "real": {

[0344] "listener_port": 30720,

[0345] "request_timeout_s": 30.0

[0346] },

[0347] "response_timeout_s": 60.0,

[0348] "outstanding_buffer_size": 2048

[0349] } ]

[0351] }

[0352] c. Key parameters

[0353] Simulation step size: TICK_TIME = 0.0001 seconds (0.1ms)

[0354] Statistical reporting interval: STATS_REPORT_INTERVAL = 0.1 seconds

[0355] Network Gateway link bandwidth: 1 Gbps

[0356] NetworkGateway link propagation delay: 0.001 seconds

[0357] Number of worker threads: 4 (default)

[0358] Delay distribution: Normal distribution (mean 30ms, standard deviation 5ms, range [10ms, 100ms])

[0359] d. Actual microservice behavior conventions

[0360] A true SVC-A microservice must meet the following conventions:

[0361] 1. Provide a unified POST interface ` / req` that receives request bodies in JSON format;

[0362] 2. During the request processing, the downstream service svc-b should send a POST request to `http: / / 127.0.0.1:9500 / 1 / svc-b / ` (the path ` / 1 / ` in the URL is determined by the listener_paths configuration, and `svc-b` is the target service name).

[0363] Supplementary Explanation

[0364] The scope of protection of this invention is not limited to the specific embodiments described above. Any technical solution based on the MWORKS Sysplorer platform, utilizing its C language interface to perform mixed programming of the Modelica model layer and C++ runtime code, realizing dual-mode (real / simulation) hybrid microservice simulation, and performing refined modeling of network layer characteristics, falls within the scope of protection of this invention. In particular:

[0365] 1. Modifications to the model components of this invention, including adding, reducing, splitting, or merging components;

[0366] 2. Apply the method of this invention to the simulation of other service architectures (such as SOA, event-driven architecture);

[0367] 3. Extending the dual-mode hybrid operation mechanism of the present invention to variations with three or more modes;

[0368] 4. Replace Modelica with equivalent alternatives using other multi-domain modeling languages ​​(such as Simulink and VHDL-AMS);

[0369] 5. Use other compiled languages ​​(such as Rust or Go) instead of C++ equivalents.

[0370] All of these should be considered within the scope of protection of this invention.

Claims

1. A simulation method for a cloud-native microservice system based on the MWORKS simulation platform, characterized in that: The method includes the following steps: S1. Constructing the overall architecture of the hierarchical simulation system The simulation system adopts a layered architecture, consisting of four layers from top to bottom: The first layer: Modelica model layer, used to build the topology model of a microservice system using the Modelica language on the MWORKS Sysplorer platform; The second layer is the C language interface layer, which is used to map functions in the C++ runtime dynamic library to functions that can be called by the Modelica simulation system based on the C language interface features provided by the MWORKS Sysplorer platform, so that the model layer can interact through the function call mechanism. The third layer: the C++ runtime core layer, which is used to access the simulation system as a dynamic link library and serves as the computing engine for the entire simulation system; The fourth layer is the strategy configuration layer, which is used to define simulation strategies through JSON-formatted strategy configuration files, supporting flexible configuration before simulation runs. S2. Hybrid Simulation Execution According to the set step size, the MWORKS Sysplorer solver drives the time progression, and executes user traffic generation, ingress routing, network topology forwarding, Pod processing, response return and statistical reporting in sequence. S3. Dual-mode hybrid operation mechanism In the same simulation scenario, Pod groups in both simulation and real modes are deployed in a mixed manner. The two modes are uniformly scheduled through the link policy in the topology configuration and appear to the outside world as the same simulation interface. S4. Cross-language interface design Data exchange and control transfer are achieved between the Modelica layer in the MWORKS Sysplorer platform and the C++ runtime through a C language interface.

2. The simulation method according to claim 1, characterized in that: The first layer of step S1, the Modelica model layer, includes the following components: User component: Used to simulate user traffic generation and behavior simulation, supporting two access modes: simulated users and real users. Each sub-user has an independent source port and transmit timer. IngressGateway component: As an ingress gateway, it is used to route user requests to the PodGroup that is the target service. NetworkGateway component: As a gateway router, it provides transmission delay simulation and subnet routing functions, and has one upstream port and multiple downstream ports; PhysicalMachine component: As a physical server, it hosts virtual machines and provides simulation hardware resource information and monitoring functions; VirtualMachine component: As a virtual machine, it is used to host microservice Pods and supports full NAT functionality, local routing between Pods, and temporary port allocation and reclamation; Sidecar component: As a service mesh sidecar proxy, it is deployed between the VirtualMachine component and the PodGroup component, and is responsible for service discovery and redirection of downstream requests; PodGroup component: As an interface component with the C++ runtime layer, it is used to submit inbound packets and poll ready packets; Connectors component: As a standardized connector interface, it is used to define the communication protocol between components; The above components can be used to build any topology in the MWORKS Sysplorer platform via graphical drag-and-drop, and data flow between components is automatically transferred through connectors.

3. The simulation method according to claim 2, characterized in that: The second layer of step S1, the C language interface layer, includes the following interfaces: HybridPodRuntime interface: used to create / destroy runtime instances, update the Pod list, submit inbound data packets, and poll the ready queue; The UserRuntime interface is used to create / destroy user runtimes, send data packets, process response packets, and detect request timeouts. NetQueue / VirtualNetQueue interface: used for creating physical / virtual network queues and enqueuing / dequeuing data packets; The NatTable interface is used for creating NAT port mapping tables, allocating temporary ports, looking up ports, and releasing ports. Statistics interface: used for registering and reporting statistical information in the Modelica layer; The PacketDataStore interface is used for the global storage, querying, marking, and removal of JSON payloads from network packets in the simulation system. The SidecarDispatchPolicy interface is used for PodGroup registration, service discovery, destination address decision-making, and ingress scheduling policy decision-making.

4. The simulation method according to claim 3, characterized in that: The third layer of step S1, the core classes of the C++ runtime core layer, include: (1) HybridPodRuntime class: used to manage the entire runtime state of PodGroup, and internally maintains a thread pool to handle parallel processing requests; worker threads obtain tasks from the shared queue of pending tasks and execute them; the HybridPodRuntime defines three types of inbound data packets: UpstreamRequest, DownstreamResponse and ListenerResponse, and executes different processing logic according to the type of inbound data packet; (2) UserRuntime class: used to manage user traffic generation, supporting both virtual and real modes; In the virtual mode, UserRuntime calculates the next launch time for each sub-user based on the configured launch interval distribution, and constructs data packets by obtaining request data from the request pool. At the same time, it maintains an outstanding table to record the packet ID and launch time of each sent request for response matching and timeout detection. In the real mode, UserRuntime creates a HybridUserListener instance to receive external HTTP requests, injects the requests into the simulation loop, and completes response matching. (3) PacketDataStore class: used for thread-safe packet data storage, the key is a double type UUID, the value is a JSON string, supports registration, query, marking as consumed and removal operations, built-in background cleanup thread, periodically serializes the entries marked as consumed into a JSONL file and removes them from memory, realizing memory-controllable data lifecycle management; (4) DynamicRingQueue template class: used for circular queues based on dynamic arrays, supporting automatic doubling and expansion; (5) Statistics class: a time slot-based statistical subsystem that internally stores statistical data for each simulation time slot and optimizes the lookup performance of hotspot paths by caching pointers; (6) NAT table class: used to manage the SNAT temporary port pool and use bitmaps to track port usage status; (7) InstanceStore / PtrInstanceStore instance storage module template: used to provide basic instance management functions, support access to instances through credentials, and used as a C++ instance intermediary for Modelica layer operations; (8) Random distribution sampling module: It provides three sampling functions: sim_rand_uniform, sim_rand_normal and sim_jitter. All sampling functions use the Mersenne Twister 64-bit random number engine of thread_local to achieve lock-free thread-safe random number generation.

5. The simulation method according to claim 4, characterized in that: (1) In the HybridPodRuntime class, different processing logic is executed in the following two modes according to the type of inbound data packet: In simulation mode, the upstream request processing flow of HybridPodRuntime is as follows: (a) Retrieve the JSON payload of inbound data from PacketDataStore; (b) Call the sample_delay() method to sample and process the delay according to the configured delay distribution and simulate the delay; (c) If downstream dependencies are configured, sequential chaining of multiple downstream calls is implemented through the PendingDownstreamContext structure; when all downstream processes are completed, data is retrieved from the final response pool to construct the upstream response packet; (d) Enqueue the constructed response packet into the ReadyPacketQueue.

6. The simulation method according to claim 5, characterized in that: The fourth layer of step S1, the policy configuration file of the policy configuration layer, includes: topology.json: Used to define the dependency chain strategy and entry strategy between services; pod_policy.json: This file defines the running mode, service name, mapped port, initial number of Pods, and detailed configuration for each PodGroup. user_policy.json: Used to define the IP address of the user group, the number of sub-users, the request pool configuration, the timeout time and the distribution parameters of the transmission interval; nat_policy.json: Used to define NAT timeout configuration; stats_policy.json: Used to define the statistics persistence configuration; packet_data_policy.json: Used to define the packet storage policy.

7. The simulation method according to claim 6, characterized in that: In step S2, the hybrid simulation is executed following a timing loop: S21.MWORKS Sysplorer Solver Time Advancement: The equation solver of the MWORKS Sysplorer platform advances the simulation time variable by a set step size to perform discrete-time simulation; S22. User traffic generation: The User component calls UserRuntime.TryEmit() to attempt to send data packets; in virtual mode, it polls the emission timer of each sub-user; in real mode, it retrieves the data packets injected by HybridUserListener from ready_queue, and successfully obtained data packets are sent to IngressGateway through the connector; S23. Ingress Routing: The IngressGateway component receives user data packets, obtains the target service name, and forwards the data packets with the modified destination address to NetworkGateway based on load balancing decisions; S24. Network topology forwarding: NetworkGateway first obtains data packets from the connected interface, and then pushes the data packets into the sending queue of the corresponding downstream port according to the subnet matching; After receiving the packet, the PhysicalMachine routes it to the target VirtualMachine according to the routing; the VirtualMachine performs DNAT checks and Pod-local routing, and pushes the packet into the downlink queue of the target Pod. S25. Pod processing: The PodGroup calls HybridPodRuntime.SubmitIncoming() to submit the inbound data packet. The C++ runtime executes the corresponding processing logic according to the inbound type and the worker thread pool, and after generating the response packet, it is enqueued into ReadyPacketQueue. S26. Response backhaul: PodGroup calls HybridPodRuntime.PopReady() to poll the ready queue, obtains the response packet, and then backhauls it in reverse along the original path, via VirtualMachine→PhysicalMachine→NetworkGateway→IngressGateway→User. UserRuntime matches outstanding requests or suspended requests of HybridUserListener and records the response delay. S27. Statistical Reporting: Each core component periodically calls the statistics subsystem to report its own status data according to STATS_REPORT_INTERVAL.

8. The simulation method according to claim 7, characterized in that: In step S3, the dual-mode hybrid operation mechanism allows different PodGroups in the same simulation scenario to be independently configured as either simulation mode or real mode: Simulation mode: The Pod group does not start the HTTP client and listener. Instead, it reads fake data directly from the JSONL data pool in the worker thread of HybridPodRuntime, and constructs the response packet after delaying according to the configured latency distribution. Real mode: The Pod group sends an HTTP POST request to the URL of the real microservice instance via HttpClient; If the Pod group has downstream dependencies, an additional HybridListener instance is started to listen on the specified port. When the real microservice calls the downstream service, the HTTP request is intercepted by the HybridListener and injected into the simulation loop. After the downstream response is transmitted back through the simulation network, the HybridListener returns the response to the real microservice, making the call chain of the real microservice transparently penetrate the simulation network. The two modes are uniformly scheduled through the link policy in the topology configuration.

9. The simulation method according to claim 8, characterized in that: In step S4, the cross-language interface design includes: Type Mapping: The mapping method is as follows: Modelica's Real type MoReal is mapped to double, MoInteger to int, MoBoolean to int, and MoString to double. All cross-language types are uniformly declared through the mo_type.h header file; Credential mechanism: The slot pool is maintained internally through the InstanceStore / PtrInstanceStore template, and the slot index is returned to Modelica as a credential in double type; Thread safety: All data structures that may be accessed concurrently by the Modelica main thread and C++ worker threads are protected by std::mutex; Dynamic library export: All functions are exported using the MWORKS_EXPORT macro.

10. A cloud-native microservice system simulation tool based on the MWORKS simulation platform, characterized in that: The simulation tool for cloud-native microservice systems is based on the cloud-native microservice system simulation method according to any one of claims 6-9, and includes: Modelica model layer: Deployed on the MWORKS Sysplorer platform, it is used to build the topology model of the microservice system and perform simulation time progression; C Language Interface Layer: Connects the Modelica model layer and the C++ runtime core layer, used to implement bidirectional data exchange and control transmission; The C++ runtime core layer is used to connect to the simulation system as a dynamic link library. Instance storage module templates: used to provide templated management of InstanceStore / PtrInstanceStore; Random distribution sampling module: used to provide delayed sampling functions for uniform distribution, normal distribution, and fixed values; Policy configuration layer: This layer provides configuration files for topology.json, pod_policy.json, user_policy.json, and nat_policy.json, and supports flexible switching between simulation mode and real mode as well as parameter configuration. The C++ runtime core layer includes: HybridPodRuntime class unit: Used to manage the runtime state of Pod groups and maintain a thread pool to handle parallel requests; UserRuntime class unit: Used to manage user traffic generation and request initiation; PacketDataStore class unit: used to manage the storage and retrieval of data packets; DynamicRingQueue template class unit: used to provide a thread-safe ring queue data structure; The Statistics class unit is responsible for collecting and reporting simulation statistics. NAT table class unit: used to manage network address translation and timeout configuration.

Images