A transaction abnormal risk identification method, device and equipment and storage medium

Abstract

This application discloses a method, apparatus, device, and storage medium for identifying transaction anomaly risks, relating to the field of anomaly detection in microservice systems. The method includes: real-time collection of transaction business data, microservice operation data, and link call data, followed by feature extraction to obtain standardized real-time multi-dimensional risk correlation features; inputting these real-time multi-dimensional risk correlation features into an adaptive optimization model to obtain preliminary risk identification results; synchronizing these features to a digital twin of the microservice transaction link; using the digital twin to simulate the current transaction flow state and generate real-time simulation risk assessment results; and combining the preliminary risk identification results with the real-time simulation risk assessment results to query a dynamic causal graph, identify risk transmission paths and root causes, and determine the final risk level. Through the above methods, this application improves the accuracy, real-time performance, and adaptability of risk identification in complex microservice environments.

Description

Technical Field

[0001] This application relates to the field of anomaly detection in microservice systems, and in particular to a method, apparatus, device, and storage medium for identifying transaction anomaly risks. Background Technology

[0002] With the rapid development of fintech, trading systems are gradually shifting from monolithic architectures to microservice architectures. While microservice architecture improves system scalability and development efficiency, it also brings challenges such as a large number of services, complex call chains, and intricate dependencies. In a complex microservice cluster, a minor failure in one microservice can propagate rapidly along the call chain, paralyzing the entire trading system and causing significant economic losses. Existing risk monitoring solutions typically have the following shortcomings: (1) Severe data silos: transaction business data, microservice operation data and link call data are often scattered in different monitoring systems, lacking effective integration methods.

[0003] (2) Lack of predictive ability: Traditional monitoring is mostly based on threshold alarms, which are post-event responses or simple in-event alarms. It is difficult to simulate the system operating status and cannot predict potential risks in advance.

[0004] (3) Difficulty in fault location: When an anomaly occurs, due to the complex dependencies between services, it is difficult to quickly locate the root cause and to reconstruct the transmission path of the risk.

[0005] (4) Imbalanced training samples: In the training of risk control models, there are a huge number of normal transaction samples, while abnormal risk samples are very scarce, resulting in insufficient ability of the model to identify abnormal situations.

[0006] Therefore, there is an urgent need for a microservice transaction risk monitoring solution that can integrate multi-source data, has simulation and extrapolation capabilities, and can effectively solve the problem of sample imbalance. Summary of the Invention

[0007] This application provides a method, apparatus, device, and storage medium for identifying transaction anomaly risks, in order to address the problems of existing risk control technologies that are unable to capture cross-service chain risks, ignore the transmission effect of system anomalies to transaction risks, and have weak model adaptive capabilities.

[0008] To address the aforementioned technical problems, this application adopts the following technical solution: A method for identifying transaction anomaly risks is provided, comprising: real-time collection of transaction business data, microservice operation data, and link call data; feature extraction of the transaction business data, microservice operation data, and link call data to obtain standardized real-time multi-dimensional risk correlation features; inputting the real-time multi-dimensional risk correlation features into a pre-trained adaptive optimization model to obtain preliminary risk identification results; synchronizing the real-time multi-dimensional risk correlation features to a microservice transaction link digital twin; using the microservice transaction link digital twin to simulate the current transaction flow state and generate a real-time simulation risk assessment result; combining the preliminary risk identification result and the real-time simulation risk assessment result, querying a dynamic causal graph to identify risk transmission paths and risk root causes, and determining the final risk level based on the risk transmission paths and risk root causes.

[0009] In some embodiments, before inputting the real-time multi-dimensional risk association features into the pre-trained adaptive optimization model, the method further includes: collecting historical transaction business data, historical microservice operation data, and historical link call data to obtain standardized multi-source fusion data; constructing a digital twin of the microservice transaction link and a dynamic causal graph in parallel, wherein the digital twin of the microservice transaction link is used to simulate the operating state and resource load of the physical microservice cluster, and the dynamic causal graph is used to describe the causal dependency between transaction behavior, service operating state, and link calls; using the dynamic causal graph to perform counterfactual inference to generate counterfactual risk samples containing potential abnormal scenarios, and mixing the counterfactual risk samples with the standardized multi-source fusion data as the training set of the risk identification model; using an incremental federated learning framework to perform distributed training on the pre-built risk identification model based on the training set, and introducing a physical consistency constraint loss function during the training process to obtain the adaptive optimization model.

[0010] In some embodiments, the parallel construction of the microservice transaction link digital twin includes: constructing a transaction link meta-model containing risk transmission weight factors, wherein the transaction link meta-model defines core elements such as service nodes, call relationships, transaction processes, operating indicators, and risk transmission weights; extracting node attributes and link topology information from the standardized multi-source fusion data, mapping the physical microservice cluster to the transaction link meta-model, and generating an initial twin instance; calculating the risk sensitivity of each service node based on the node causal strength in the dynamic causal graph, and determining a differentiated synchronization strategy based on the risk sensitivity; updating the operating status of the initial twin instance through the differentiated synchronization strategy, so that the microservice transaction link digital twin is synchronized with the physical microservice cluster in real time.

[0011] In some embodiments, the parallel construction of the dynamic causal graph includes: mining the causal relationships between variables in the standardized multi-source fusion data using a linear non-Gaussian acyclic model to construct an initial causal graph; calculating the mutual information and conditional independence test statistics of each causal relationship edge, removing redundant edges from the initial causal graph based on the calculation results to obtain a pruned causal graph; acquiring newly generated incremental data, dynamically updating the node and edge weights of the pruned causal graph using a structured causal model, and outputting the dynamic causal graph containing risk transmission paths and weights.

[0012] In some embodiments, the step of using the dynamic causal graph to perform counterfactual inference and generate counterfactual risk samples containing potential abnormal scenarios includes: identifying key risk transmission paths in the dynamic causal graph, wherein the key risk transmission paths are paths whose causal weights exceed a preset threshold; selecting target nodes on the key risk transmission paths, applying virtual perturbations to the feature attributes of the target nodes in the standardized multi-source fusion data, wherein the virtual perturbations include traffic surges, latency increases, and message tampering; retrieving the set of parent nodes of the target nodes from the dynamic causal graph, and based on the historical data distribution of the parent node set and the virtual perturbations, inferring the feature values ​​of the target nodes under the perturbation state to generate the counterfactual risk samples.

[0013] In some embodiments, the incremental federated learning framework is used to perform distributed training on a pre-built risk identification model based on the training set, and a physical consistency constraint loss function is introduced during the training process to obtain the adaptive optimization model. This includes: each microservice node training a local sub-model based on local data and uploading the local model parameters to an aggregation server; the aggregation server aggregating the local model parameters to generate global model parameters and distributing the global model parameters to each microservice node; the microservice transaction link digital twin receiving the global model parameters, inputting the global model parameters based on the current simulation state, and outputting the twin risk prediction result; calculating the deviation between the twin risk prediction result and the physical operating rules within the microservice transaction link digital twin, and constructing a physical consistency constraint loss function; updating the global model parameters by combining the data classification loss and the physical consistency constraint loss function, iterating until convergence, to obtain the adaptive optimization model.

[0014] In some embodiments, the step of extracting features from the transaction business data, the microservice operation data, and the link call data to obtain standardized real-time multi-dimensional risk association features includes: extracting user behavior statistics, transaction pattern features, and business anomaly features from the transaction business data to obtain business dimension features; extracting resource utilization, service health, and container status features from the microservice operation data to obtain system dimension features; extracting call topology, call performance, and error rate features from the link call data to obtain link dimension features; and fusing the preprocessed business dimension features, system dimension features, and link dimension features to obtain the standardized real-time multi-dimensional risk association features.

[0015] To address the aforementioned technical problems, another technical solution adopted in this application is: providing a transaction anomaly risk identification device, comprising: a feature extraction module, used to collect transaction business data, microservice operation data, and link call data in real time, and to extract features from the transaction business data, the microservice operation data, and the link call data to obtain standardized real-time multi-dimensional risk correlation features; a risk identification module, used to input the real-time multi-dimensional risk correlation features into a pre-trained adaptive optimization model to obtain preliminary risk identification results, and to synchronize the real-time multi-dimensional risk correlation features to a microservice transaction link digital twin, using the microservice transaction link digital twin to simulate the current transaction flow state and generate a real-time simulation risk assessment result; and a final risk analysis module, used to combine the preliminary risk identification result and the real-time simulation risk assessment result to query a dynamic causal graph, identify risk transmission paths and risk root causes, and determine the final risk level based on the risk transmission paths and risk root causes.

[0016] This application also provides a computer device, the computer device comprising: a memory and at least one processor, the memory storing instructions; the at least one processor invokes the instructions in the memory to cause the computer device to execute the transaction anomaly risk identification method as described above.

[0017] This application also provides a computer-readable storage medium storing instructions that, when executed by a processor, implement the transaction anomaly risk identification method described above.

[0018] The beneficial effects of this application are as follows: Unlike existing technologies, this application discloses a method, apparatus, device, and storage medium for identifying transaction anomaly risks. It collects transaction business data, microservice operation data, and link call data in real time, and extracts features from these data to obtain standardized real-time multi-dimensional risk correlation features. By generating these standardized real-time multi-dimensional risk correlation features, high-quality, uniformly formatted input data is provided for subsequent models, eliminating heterogeneity between different data sources and achieving deep integration of transaction business data, microservice operation data, and link call data, thus breaking down data silos between business and operational perspectives. Real-time multi-dimensional risk correlation features are input into a pre-trained adaptive optimization model to obtain preliminary risk identification results. These features are then synchronized to a digital twin of the microservice transaction link. The digital twin simulates the current transaction flow state and generates real-time simulation risk assessment results. The adaptive optimization model focuses on data-driven pattern recognition, using historical data to mine hidden fraud patterns or abnormal transaction behaviors to achieve rapid identification and high-accuracy judgment of known risk types. The digital twin of the microservice transaction link focuses on mechanism-driven simulation deduction, replicating the physical system state in real time and simulating the impact of resource load on transactions based on physical laws. This enables early warning of potential risks caused by unknown scenarios or system bottlenecks, compensating for the weak predictive ability of pure data models for unseen faults. By combining preliminary risk identification results with real-time simulation risk assessment results, a dynamic causal graph is queried to identify risk transmission paths and root causes, and the final risk level is determined based on these paths and root causes. The causal graph is also used to verify the logical consistency of risk transmission paths and eliminate false alarms based on spurious correlations. The dynamic causal graph can accurately locate the root service and intermediate nodes of risk transmission based on preliminary and simulation results, solving the problem of locating cross-service cascading risks. Ultimately, this represents a technological breakthrough, moving from post-event identification to pre-event warning, from isolated detection to chain-based coordination, and from black-box prediction to explainable tracing, significantly improving the accuracy, real-time performance, and explainability of risk identification in complex microservice environments. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort, wherein: Figure 1 This is a flowchart illustrating an embodiment of the transaction anomaly risk identification method provided in this application; Figure 2This is a schematic diagram of the structure of an embodiment of the transaction anomaly risk identification device provided in this application; Figure 3 This is a schematic diagram of the structure of a computer device according to an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0021] The terms "first," "second," and "third" used in the embodiments of this application are for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Thus, a feature defined as "first," "second," or "third" may explicitly or implicitly include at least one of that feature. In the description of this application, "multiple" means at least two, such as two, three, etc., unless otherwise explicitly specified. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to these processes, methods, products, or devices.

[0022] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0023] See Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the transaction anomaly risk identification method provided in this application. The transaction anomaly risk identification method includes the following steps: 100: Real-time collection of transaction business data, microservice operation data, and link call data, and feature extraction of the transaction business data, microservice operation data, and link call data to obtain standardized real-time multi-dimensional risk association features.

[0024] The core of this embodiment lies in building a full-dimensional, non-intrusive data perception system.

[0025] In this embodiment, a data acquisition probe is first deployed, and data is captured in real time from the kernel and application states of the physical microservice cluster using extended Berkeley packet filtering technology and open observability technology.

[0026] Extended Berkeley Packet Filters are kernel-level technologies that allow the acquisition of system call and network data without the need for embedding code in business logic. Their advantages include zero performance impact on business logic and broad coverage. Open Observability, on the other hand, is a set of standard tools for generating, collecting, analyzing, and exporting telemetry data (such as tracking, metrics, and logs), providing a unified interface specification.

[0027] Specifically, the collected data is divided into three categories: The first category is transaction business data, which includes user identifiers, transaction amounts, payment channels, merchant IDs, timestamps, etc. This type of data directly reflects business intentions and behavioral patterns; the second category is microservice operation data, which covers the CPU utilization, memory usage, disk read / write speed, network throughput, and HIP status code distribution of each service node. This type of data characterizes the underlying health status of the system; the third category is link call data, which includes trace identifiers, span identifiers, upstream service names, downstream service names, call duration, and call success or failure. This type of data outlines the dependency topology between services.

[0028] After data collection, the feature extraction stage begins. The raw data is often unstructured or semi-structured, and contains noise and redundancy, requiring cleaning and transformation using the Flink streaming engine. The cleaning process includes removing missing values, smoothing outliers, and aligning data based on time windows to ensure that transaction data and microservice runtime data correspond on the same time dimension.

[0029] Subsequently, key indicators characterizing the risk situation are extracted through feature engineering and transformed into vector forms understandable to the model, ultimately outputting standardized real-time multi-dimensional risk correlation features. This feature set is the cornerstone of subsequent model training and real-time inference, and its quality directly determines the accuracy of risk identification. Compared to traditional methods that rely solely on single business data collection, this embodiment achieves a comprehensive understanding of the entire transaction chain by integrating system operation and link call data, thus solving the problem of missed reports caused by blind spots in data from a single perspective.

[0030] In one optional embodiment, feature extraction is performed on transaction business data, microservice operation data, and link call data to obtain standardized real-time multi-dimensional risk correlation features, including the following steps: 110: Extract user behavior statistics, transaction pattern characteristics, and business anomaly characteristics from transaction business data to obtain business dimension characteristics.

[0031] The core of this embodiment is the in-depth mining of transaction data, with the goal of identifying potential risk profiles of users and merchants from massive transaction records. In practice, the cleaned transaction data is first aggregated using a sliding window method.

[0032] In terms of user behavior statistics, the system calculates the frequency of a user's transactions, the average transaction amount, the maximum transaction amount, and the rate of change of the latitude and longitude of the transaction location within a short time window. If a user initiates a series of high-value transactions within a short period of time, and the geographical location changes extremely rapidly, this is highly likely to indicate that the account has been stolen or that fraudulent money laundering activities are involved.

[0033] Regarding transaction pattern characteristics, the system utilizes clustering algorithms to analyze users' historical transaction habits and construct a user profile baseline. During real-time feature extraction, the deviation between the current transaction and the baseline profile is calculated, such as changes in commonly used payment methods, unusual transaction times, and abrupt changes in the categories of purchased goods. These pattern characteristics can effectively identify abnormal behaviors disguised as normal transactions.

[0034] Regarding abnormal business characteristics, the system focuses on extracting indicators that violate business logic. Examples include multiple payments for the same order number, discrepancies between payment and order amounts, and repeated use of coupons. Additionally, it includes external features such as user credit scores and blacklist associations.

[0035] Ultimately, the above three types of features are combined into a business dimension feature vector, which transforms redundant transaction records into digital signals with risk characterization capabilities.

[0036] Through this example, the model can understand the business semantics behind transactions, thereby capturing abnormal signals at the business level as soon as risks occur. Compared to traditional methods that rely solely on monetary thresholds, multi-dimensional business feature extraction can cover more concealed fraud scenarios and significantly improve the sensitivity of business risk perception.

[0037] 120: Extract resource utilization, service health, and container status characteristics from microservice runtime data to obtain system-level characteristics.

[0038] The purpose of this embodiment is to quantify the operational status of a microservice cluster from a system operations perspective, because the root cause of most transaction risks lies in the scarcity of system resources or service anomalies. During implementation, the system continuously pulls monitoring metrics from the containerization platform and the host operating system.

[0039] Resource utilization characteristics primarily reflect the load on computing and storage resources. These include the real-time load percentage of the CPU, interrupts per second, memory usage and remaining memory, garbage collection frequency and time, disk I / O latency, and network bandwidth utilization. In a microservice architecture, resource contention is common. Once the resource utilization of a service approaches saturation, it will inevitably lead to increased response latency for that service, potentially causing transaction failures or data inconsistencies.

[0040] Service health characteristics focus on the application-level liveness and response quality. This includes the service instance liveness, the response time of the Hypertext Transfer Protocol (HTTP) interface, the success rate of requests, and the density of error logs.

[0041] For example, if the error rate of a payment service suddenly spikes from 0.01% to 5%, the service is in an extremely unhealthy state and the associated transaction risk is extremely high.

[0042] Container state characteristics specifically refer to the runtime parameters of each container instance in a container orchestration platform. These include the number of container restarts, image version number, the ratio of resource quota to actual usage, and the network packet loss rate between containers. Frequent container restarts often indicate program crashes and failures, posing a significant potential risk.

[0043] Ultimately, these indicators together constitute the system-level characteristics. This dimension establishes a mapping relationship between system status and transaction risk. Traditional risk identification often overlooks system status, leading to misjudgments of transaction failures caused by system malfunctions as malicious user fraud.

[0044] This embodiment introduces system-level features, enabling the model to distinguish between business fraud and system failure, thereby significantly reducing the false alarm rate and achieving accurate positioning of system-level risks.

[0045] 130: Extract the call topology, call performance, and error rate features of the link call data to obtain the link dimension features.

[0046] The core of this embodiment lies in describing the dynamic dependencies and interaction quality between microservices, because the core risks of microservice architecture are often hidden in complex call chains. The implementation process is based on distributed tracing technology, which uses tracing identifiers to chain log fragments scattered across different services into a complete call chain.

[0047] The topology features describe the static and dynamic dependencies between services. These include the number of upstream and downstream services, in-degree and out-degree of services, the length of the critical path, and the dependency density of core services. By constructing a dynamic service dependency graph, single points of failure in the system can be identified. For example, if all transactions must pass through a certain authentication service, then that authentication service is a critical bottleneck node in the topology, and its failure can easily paralyze the entire system.

[0048] Call performance characteristics quantify the efficiency of inter-service interactions. These primarily include the total end-to-end call duration, the average duration of a single-hop call, latency fluctuations in cross-network calls, and the overhead of serialization and deserialization. In a microservice call chain, the cumulative effect of latency can lead to severe transaction timeouts, impacting user experience and even causing transaction rollbacks.

[0049] Error rate characteristics reflect failures during the call process. These include the rate of Hypertext Transfer Protocol (HTTP) 5xx server errors, the rate of 4xx client errors, the number of network timeouts and connection rejections, and the number of circuit breaker triggers. A surge in error rate is a precursor to system crashes and must be considered a key risk characteristic.

[0050] By extracting the aforementioned features to form link-dimensional features, the black-box call relationships of the microservice architecture are made transparent. This enables the risk identification model to not only know "what happened," but also "where it happened" and "how it might propagate." Compared to monitoring that only focuses on the state of a single service, link-dimensional features can reveal chain reactions across services, providing a topological foundation for subsequent causal tracing and root cause analysis.

[0051] 140: By integrating the preprocessed business dimension features, system dimension features, and link dimension features, standardized real-time multi-dimensional risk association features are obtained.

[0052] The goal of this embodiment is to fuse three heterogeneous dimensional features into a unified and standardized input vector for use by a pre-trained adaptive optimization model. The process involves data alignment, normalization, and fusion.

[0053] Since the collection frequency and timestamp accuracy of business, system and link data may be inconsistent, strict time window alignment is required first.

[0054] For example, based on the arrival time of a transaction request, a time window is traced back, and the corresponding average system load and average link latency within that window are extracted to ensure that the feature vectors strictly correspond to the same transaction or the same time slice in time.

[0055] Subsequently, features with different dimensions are standardized. Business features, such as monetary amounts, may reach millions, while the error rate is only between 0 and 1. System resource utilization is also a percentage. Direct fusion would lead to features with larger dimensions dominating model decisions. Therefore, Z-score standardization or Min-Max normalization methods are used to map all features to the same numerical range, eliminating the impact of differences in dimensions.

[0056] In terms of fusion strategy, vector concatenation or tensor outer product is adopted. Business-dimensional feature vectors, system-dimensional feature vectors, and link-dimensional feature vectors are concatenated end-to-end to form a high-dimensional joint feature vector. To capture the interactive effects between features, cross-features can also be constructed to explicitly describe the relationships between features of different dimensions.

[0057] For example, construct combined features such as "CPU utilization during high concurrency periods" or "network latency during large transactions".

[0058] The final output, standardized real-time multi-dimensional risk association features, is a comprehensive, unbiased mathematical object with a uniform numerical distribution. It breaks down data silos and achieves semantic alignment of cross-domain features. This multi-source fusion feature not only contains rich risk information but, more importantly, implies potential causal relationships between features. It provides the necessary data support for subsequent models to accurately identify risks from complex system behaviors and is a prerequisite for the model to achieve high performance.

[0059] For example, during the peak of the Double Eleven shopping festival, the system detected a transaction request from user ID U_88888. This user requested to purchase five high-end servers, amounting to 500,000 yuan, and the IP address of the request source jumped from Beijing to an overseas node within one minute. Simultaneously, the backend logs showed that the container hosting the order service restarted.

[0060] Based on sliding window statistics, the system discovered that this user initiated 12 transactions in the past 10 minutes, a frequency far exceeding the baseline of 0.5 transactions per day over the past six months; the transaction amount also showed explosive growth. Through pattern recognition model comparison, the user's historical preference was to purchase low-priced electronic accessories, while the current transaction involved high-value hardware, and the transaction time was outside their usual active period, resulting in a pattern deviation of 0.95. The system detected that the same order number ORD_20231111_88392 was submitted 3 times within 500ms, exhibiting obvious duplicate submission anomalies; simultaneously, the device fingerprint hash value changed, suggesting device hijacking. This resulted in the following business dimension feature vector: [Frequency Anomaly Score: 0.98, Pattern Deviation Score: 0.95, Duplicate Submission Flag: 1].

[0061] Monitoring showed that the CPU utilization of container Pod_01, which hosts the order service, spiked to 99% and memory utilization to 92% the instant a transaction occurred. The Hypertext Transfer Protocol (HTP) P99 response time for the order service increased dramatically from the normal 50ms to 2500ms; the health check interface returned timeouts three times consecutively, and the container had restarted one minute prior. The container restart counter was at 3, its status was "Starting - Unstable," and the resource limit triggered the OOM Killer. This resulted in the following system-level feature vector: [CPU utilization: 0.99%, P99 latency: 2500ms, container restart count: 3].

[0062] Trace ID Trace_12345 shows the call chain as: Client - Gateway - Order Service - Inventory Service - Payment Service. The system calculated that the Order Service has extremely high betweenness centrality, making it a critical bottleneck node. Link monitoring revealed that the average time for a single call from the Order Service to the Inventory Service increased from 10ms to 800ms, far exceeding the threshold. The Order Service's call to the Inventory Service's interface returned a 503 Service Unavailable error, with the error rate soaring to 40%. This resulted in the following link-dimensional feature vector: [Topological criticality: 0.9, cross-service latency: 800ms, error rate: 0.4].

[0063] The system aligns the three vectors in time to confirm that the data corresponds to the same millisecond-level time window. Z-score normalization is applied: the 500,000 yuan amount is mapped to +2.5 standard deviations, and 99% CPU usage is mapped to +3.0 standard deviations. The duplicate submissions from the business dimension, the CPU overload from the system dimension, and the 503 errors in downstream services from the link dimension are combined into a high-dimensional feature vector X = [2.5, 0.98, 1, 3.0, 2500, 3, 0.9, 800, 0.4]. This feature vector not only contains the statistical characteristics of user fraud but also the physical characteristics of system crashes, comprehensively describing this as a "suspected malicious order-brushing transaction occurring under a high-load system failure environment," providing complete input for subsequent accurate model judgment.

[0064] 200: Input real-time multi-dimensional risk correlation features into a pre-trained adaptive optimization model to obtain preliminary risk identification results, and synchronize the real-time multi-dimensional risk correlation features to the microservice transaction link digital twin. Use the microservice transaction link digital twin to simulate the current transaction flow state and generate real-time simulation risk assessment results.

[0065] This embodiment employs a dual-engine driven architecture: a pre-trained adaptive optimization model for efficient data-driven identification, and a mechanism-driven simulation verification using a digital twin of the microservice transaction chain. The implementation process consists of two parallel paths.

[0066] The first path is the data-driven path. The standardized real-time multi-dimensional risk association features generated in step 140 are input into a pre-trained adaptive optimization model. This model is typically a hybrid model built on extreme gradient boosting and long short-term memory networks. Extreme gradient boosting excels at handling tabular features and can quickly uncover non-linear relationships between features, while long short-term memory networks excel at handling time-series features and can capture the trend of risk evolution over time.

[0067] The model output includes the probability values ​​of whether a transaction falls under various risks, such as fraud, system failure, or normal, as well as a preliminary risk score, which constitutes the initial risk identification result. It utilizes statistical patterns from historical data to quickly and accurately classify current transactions.

[0068] The second path is the mechanism-driven path. Simultaneously, real-time, multi-dimensional risk correlation features are synchronized to the digital twin of the microservice transaction chain. The microservice transaction chain digital twin is a high-fidelity virtual mapping built on a physical microservice cluster. It not only replicates the topology of the physical system but also incorporates a queuing theory model or a physical performance model. When real-time features are input into the twin, the twin simulates the flow of the current transaction stream in the virtual cluster, calculating the expected response time, queue length, and resource consumption of each service under the current load. If the input features indicate that the database connection pool is about to be exhausted, the twin, through physical model deduction, will simulate the consequences of a large number of transaction requests being blocked, thereby generating real-time simulation risk assessment results. This compensates for the shortcomings of pure data models in predicting unseen scenarios, and by simulating the operating rules of the physical world, it can predict systemic risks that have not yet occurred but are highly likely to occur.

[0069] The results of the two paths corroborate each other, utilizing both the generalization ability of deep learning and the determinism of physical models, significantly improving the robustness and accuracy of risk identification.

[0070] Optionally, before inputting real-time multi-dimensional risk association features into the pre-trained adaptive optimization model, the following steps are also included: 210: Collect historical transaction data, historical microservice operation data, and historical link call data to obtain standardized multi-source fusion data.

[0071] This embodiment involves large-scale historical data backtracking and preprocessing. The system extracts full logs and database records from a data warehouse or data lake over a long period of time.

[0072] The historical data collected must cover normal business scenarios, known abnormal scenarios, and various extreme boundary conditions, such as high traffic surges during major promotional events, degraded states during system maintenance, and various periods of failure that have occurred in the past. For microservice runtime data, historical monitoring metrics from the container orchestration platform need to be collected; for cascading call data, full tracing logs need to be collected; and for transaction business data, complete transaction flows and final status labels must be included.

[0073] Due to the massive volume and diverse formats of historical data, offline cleaning and fusion are required using big data batch processing technologies (such as Hadoop or Spark). The cleaning process includes deduplication, filling in missing values, and correcting timestamp drift.

[0074] The fusion process also requires aligning transaction behaviors, system states, and call chains at the same historical moment based on time windows or association keys. Furthermore, to improve model training efficiency, feature extraction and dimensionality reduction of the data are necessary to remove redundant information, ultimately resulting in a high-quality, standardized multi-source fusion dataset.

[0075] This embodiment provides a complete sample space for subsequent digital twin construction and causal graph mining. Sufficient and comprehensive historical data is a necessary condition for training high-precision models, especially historical data containing fault periods, which is crucial for the model to learn risk characteristics. Through standardization, noise interference in historical data is eliminated, ensuring that the mined causal relationships and the constructed twin have high accuracy and reliability.

[0076] 220: Parallel construction of digital twins and dynamic causal graphs of microservice transaction links. The digital twins of microservice transaction links are used to simulate the running status and resource load of physical microservice clusters, and the dynamic causal graphs are used to describe the causal dependencies between transaction behavior, service running status and link calls.

[0077] This embodiment utilizes parallel processing technology to simultaneously construct two key models: a digital twin of the microservice transaction chain and a dynamic causal graph. During implementation, the standardized multi-source fusion data generated in step 210 is used as input, and the construction tasks are initiated simultaneously in two independent computational pipelines.

[0078] The construction of the microservice transaction link digital twin aims to create a virtual mirror that corresponds 1:1 to the physical system. It not only includes the static topology of the microservices but also encapsulates mathematical models describing the system's dynamic behavior (such as response time models based on queuing theory). This twin can receive real-time transaction traffic input and output predicted values ​​of various system indicators under current physical resource constraints. Its core function is to achieve virtual-real interaction and simulation, allowing testing of various extreme scenarios without affecting the production environment.

[0079] The construction of dynamic causal graphs aims to uncover causal mechanisms between variables from historical data, rather than simple correlations. Nodes in the graph represent various metrics (such as CPU utilization and transaction failure rate), and edges represent the direction of causal influence. The graph's purpose is to reveal how risks propagate from one service to another; for example, how database lock waits ultimately lead to front-end order timeouts. Through dynamic causal graphs, the source of risk can be precisely located.

[0080] By employing a parallel construction strategy, the offline model building cycle is significantly shortened, improving the efficiency of system engineering implementation. Simultaneously, the simulation capabilities provided by the twin and the interpretive capabilities provided by the causal graph combine to form a dual guarantee for the solution: one predicts "what will happen," and the other explains "why it will happen." This combination overcomes the limitations of traditional monitoring methods that can only see the surface, delving into the essential level of risk transmission.

[0081] Furthermore, in one embodiment, constructing a digital twin of the microservice transaction chain in parallel includes the following steps: 221: Construct a transaction link meta-model containing risk transmission weight factors. The transaction link meta-model defines the core elements of service nodes, call relationships, transaction process, operation indicators and risk transmission weights.

[0082] The first step is to define a general metamodel, which is an abstract description of the microservice transaction chain in the physical world. This metamodel is not specific to any particular business, but rather a general domain knowledge template. The metamodel contains five core elements: Service node: Defines the basic attributes of a microservice, such as service name, function type, and deployment specifications.

[0083] Call relationships: Define the connection methods between services, including synchronous calls, asynchronous messages, and Hypertext Transfer Protocol requests.

[0084] Transaction process: Define the flow logic of a transaction between services, such as the necessary process nodes such as authentication, authorization, and data entry.

[0085] Operational metrics: Define the physical quantities that need to be monitored and simulated, such as CPU load, network latency, etc.

[0086] Risk transmission weighting factor: Defines the attenuation or amplification coefficient of risk transmission between services. For example, the risk transmission weight of the core accounting service is extremely high, and even a minor anomaly in it may cause a global shutdown; while the weight of the edge log service is relatively low.

[0087] A transaction link meta-model incorporating risk transmission weights is constructed, endowing the digital twin with semantic-level risk perception capabilities. Traditional topology models only describe physical connections, while this meta-model, by introducing risk transmission weights, enables the twin to simulate not only data flow but also risk flow during simulation. This provides a mathematical framework for subsequent differentiated synchronization and risk assessment, making the results of virtual simulation more closely resemble the risk transmission patterns in the real world.

[0088] 222: Extract node attributes and link topology information from standardized multi-source fusion data, map the physical microservice cluster to the transaction link meta-model, and generate an initial twin instance.

[0089] This involves instantiating an abstract meta-model into a concrete digital twin, thus mapping the physical world to the digital world. The process relies on in-depth analysis of standardized, multi-source fused data.

[0090] First, node attributes are extracted. The system scans the configuration data of the service registry and the resource list of the container orchestration platform to obtain static attributes such as IP address, port, image version, and resource limits for each physical service node, and then populates them into the service node elements of the metamodel.

[0091] Secondly, extract the link topology information. Analyze the call chain logs to identify the call relationships between services. For example, service A calls service B at a frequency of 100 times per second, with an average latency of 20ms. Populate these dynamic attributes into the call relationship elements of the metamodel.

[0092] Subsequently, based on the transaction flow data from the standardized multi-source fusion data, typical transaction process paths were reconstructed, and key links were identified.

[0093] Finally, the instantiated data is stored in a graph database to form an initial twin instance. This instance is completely identical to the physical microservice cluster in terms of structure and static attributes.

[0094] In this embodiment, the generated initial twin not only possesses the same basic architecture as the physical system but also has a certain initial state. This is a prerequisite for subsequent real-time synchronization and dynamic simulation; without this accurate initial instance, any simulation will lose its reference frame. Through automated mapping technology, it can adapt to the frequent changes in microservice architecture. When the physical cluster expands or shrinks, the digital twin can also be automatically reconstructed, realizing a digital clone of the physical system.

[0095] 223: Based on the causal strength of nodes in the dynamic causal graph, calculate the risk sensitivity of each service node, and determine the differentiated synchronization strategy based on the risk sensitivity.

[0096] Due to the large number of microservice nodes, performing high-frequency synchronization on all nodes would generate enormous network overhead and computational pressure. The implementation process introduced an intelligent scheduling strategy based on causal analysis to address the resource and accuracy balance issue during real-time synchronization of digital twins.

[0097] First, the causal strength of each node is obtained from the dynamic causal graph. Causal strength reflects the degree of causal impact of a node's state change on the entire system or downstream nodes. A node with high causal strength is often a bottleneck node or core service on the critical path, and its anomaly can trigger a severe chain reaction.

[0098] Subsequently, the risk sensitivity of each service node is calculated. Risk sensitivity is a quantitative indicator calculated by comprehensively considering factors such as causal strength, business importance, and historical failure frequency. For example, the payment service has extremely high causal strength and extremely high business importance, and its risk sensitivity is rated as "extremely high"; while the risk sensitivity of a certain auxiliary recommendation service may be rated as "low".

[0099] Finally, differentiated synchronization strategies are determined based on risk sensitivity. For nodes with high risk sensitivity, an extremely high-frequency real-time synchronization strategy is adopted to ensure that the state in the twin is perfectly matched with the physical state; for nodes with low risk sensitivity, a low-frequency synchronization strategy or an event-triggered synchronization strategy is adopted.

[0100] Compared to full-scale high-frequency synchronization, the differentiation strategy significantly improves the scalability and operating efficiency of the system while ensuring simulation accuracy. This allows the solution to be applied to large-scale production environments, significantly reduces the resource consumption of twin operation, and ensures accurate monitoring of key risk nodes.

[0101] 224: Update the running status of the initial twin instance through a differentiated synchronization strategy, so that the digital twin of the microservice transaction link is synchronized with the physical microservice cluster in real time.

[0102] The consistency between the twin and the physical twin is maintained through continuous synchronization operations. This process relies on message queue middleware and network socket technology.

[0103] On the physical microservice cluster side, data acquisition probes continuously push real-time operational status data, including current CPU utilization, memory usage, and the length of the current request queue. This data is tagged with the corresponding service node and sent to the synchronization gateway.

[0104] The synchronization gateway filters and distributes received data according to a preset differentiated synchronization strategy. Data belonging to high-frequency synchronization nodes is immediately pushed to the digital twin engine via a long network socket connection, where the engine updates the state variables of the corresponding node in the twin instance. Data from low-frequency synchronization nodes is temporarily stored in a cache, awaiting batch updates after a scheduled task or when trigger conditions are met.

[0105] Upon receiving an update, the digital twin engine not only modifies the state values ​​of the nodes but also triggers its internal state propagation algorithm.

[0106] For example, when an update indicating increased load on a database service node is received, the engine will automatically extrapolate and update the expected latency of all upstream service nodes that depend on the database based on a preset physical model.

[0107] Through this continuous closed-loop process, the digital twin of the microservice transaction chain can map the operational status of the physical microservice cluster in real time, establishing a real-time foundation for virtual-physical interaction. Only when the synchronization latency is sufficiently low can the simulation results of the twin have real-time early warning value. This ensures that the digital twin is always a dynamic mirror of the physical system, rather than static data, thus providing a reliable virtual environment for real-time risk assessment.

[0108] In another alternative embodiment, the dynamic causal graph is constructed in parallel, including the following steps: 225: Utilize a linear non-Gaussian acyclic model to mine the causal relationships among variables in standardized multi-source fusion data and construct an initial causal graph.

[0109] The linear non-Gaussian acyclic model (LCA) is a causal discovery algorithm based on the assumption of non-Gaussianity. Its basic principle is to use the non-Gaussian distribution characteristics of data to distinguish causal directions. Compared to traditional algorithms based on correlation or conditional independence tests, the LCA can more accurately identify the causal direction between variables, i.e., determine whether A caused B or B caused A, which is crucial for risk attribution.

[0110] In practice, the various metrics (such as transaction volume, CPU utilization, response time, and error rate) in the standardized multi-source fusion data are first treated as nodes in a graph. The algorithm performs independence checks and causal direction determination on each pair of nodes, constructing a directed acyclic graph as the initial causal graph. To adapt to the characteristics of microservice data, this step improves the algorithm by introducing domain knowledge constraints. For example, the logical rule that downstream services cannot negatively influence the response time of upstream services is used as a hard constraint input into the algorithm, eliminating impossible causal directions and narrowing the search space.

[0111] The initial causal map not only shows which indicators are related, but also clearly points out the direction of risk transmission. This discovery of causal relationships breaks through the limitations of traditional correlation analysis, provides a theoretical basis for accurately locating the root causes of risks, and is a prerequisite for subsequent counterfactual deduction and path tracing.

[0112] 226: Calculate the mutual information and conditional independence test statistics of each causal relationship edge, and remove redundant edges from the initial causal graph based on the calculation results to obtain the pruned causal graph.

[0113] In the initial causal graph, there may be many edges that do not truly represent the causal mechanism; these edges may be spurious correlations caused by data noise or third variables. To address this issue, the system performs an in-depth evaluation of each edge in the graph.

[0114] First, calculate the mutual information of the edges. Mutual information measures the degree of interdependence between two variables. The higher the mutual information value, the stronger the relationship between the two variables. If the mutual information value of an edge is lower than a preset threshold, it means that the relationship is extremely weak and may be a coincidence, so it is judged as a weak connection and considered for removal.

[0115] Secondly, perform a conditional independence test. Given a set of control variables, test whether a dependency still exists between two nodes. If the test results show that the two nodes are conditionally independent given an intermediate node, then the direct causal edge between them does not actually exist and should be removed.

[0116] Based on the above calculation results, the system performs graph pruning operations, removing redundant edges and weak connections, and retaining those edges that have strong mutual information and satisfy causal logic.

[0117] The pruned causal graph removes noise interference, highlighting the core risk transmission paths. This not only reduces the computational complexity of subsequent graph search and inference, but more importantly, it avoids erroneous risk diagnosis caused by false causality, ensuring the accuracy and reliability of risk tracing and significantly improving the quality and clarity of the causal graph.

[0118] 227: Acquire newly generated incremental data, dynamically update the node and edge weights of the pruned causal graph using a structured causal model, and output a dynamic causal graph containing risk transmission paths and weights.

[0119] Microservice architecture is highly dynamic; services can be launched, taken offline, or refactored at any time, and business traffic patterns can drift over time. Static causal graphs quickly become outdated. To address this issue, the system establishes an incremental data stream processing channel. Whenever new transaction and operational data is generated, it is fed into the structured causal model.

[0120] The structured causal model maintains the parameter state of the causal graph. Upon receiving incremental data, the model uses online learning methods such as Bayesian updates or stochastic gradient descent to re-evaluate the causal strength between nodes. If a new service call relationship is discovered, the model automatically adds new nodes and edges to the graph; if an old call relationship disappears, the corresponding edge is removed. Simultaneously, the edge weights are fine-tuned based on the statistical characteristics of the latest data.

[0121] The output dynamic causal graph not only includes the latest topology, but also includes the real-time weights of each edge, which directly represent the strength of risk transmission.

[0122] By dynamically updating the node and edge weights of the pruned causal graph, the long-term effectiveness and adaptability of the risk monitoring system are ensured. This endows the causal graph with the ability to dynamically evolve in response to environmental changes, enabling it to self-update along with changes in the microservice architecture and the evolution of business models. The dynamic causal graph always reflects the current true state of the system, rather than historical patterns, allowing the system to automatically adapt to the scaling up and down of microservices, link reconstruction, and the launch of new services. This eliminates the need for frequent manual intervention to adjust model parameters, fully realizing intelligent operation and maintenance risk control.

[0123] 230: Use dynamic causal graphs to perform counterfactual inference, generate counterfactual risk samples containing potential abnormal scenarios, and mix the counterfactual risk samples with standardized multi-source fusion data as the training set for the risk identification model.

[0124] In real-world production environments, genuine risk samples are extremely scarce, which often leads to trained risk control models being insensitive to anomalies. To address this challenge, this step introduces counterfactual reasoning techniques.

[0125] The core idea of ​​counterfactual reasoning is to answer the question of differing outcomes under different circumstances. In a dynamic causal graph, the system selects certain key nodes and virtually intervenes in them, for example, by forcibly setting their values ​​to extreme outliers. Then, using the causal structure in the graph, this intervention is propagated forward along the causal edges, observing and calculating changes in downstream nodes.

[0126] In this way, the system generates a large amount of data on abnormal scenarios that have never occurred in reality but are logically sound—that is, counterfactual risk samples. These samples include various potential crises such as extreme traffic surges, critical service outages, and severe network jitter.

[0127] These counterfactual risk samples are mixed with the real standardized multi-source fusion data obtained in step 210 to construct a balanced training set.

[0128] This allows pre-trained adaptive optimization models to be exposed to various extreme boundary conditions during the training phase, thereby learning to identify these potential risks. Compared to traditional oversampling or data augmentation techniques, data generated by counterfactual inference based on causal graphs better conforms to the physical logic of the system, resulting in models with stronger generalization ability and higher robustness. It also greatly enriches the diversity of training samples, especially by supplementing high-value outlier samples.

[0129] In one optional embodiment, counterfactual inference is performed using a dynamic causal graph to generate counterfactual risk samples containing potential anomalous scenarios, including the following steps: 231: Identify key risk transmission paths in dynamic causal graphs. Key risk transmission paths are those whose causal weights exceed a preset threshold.

[0130] In dynamic causal graphs, the connections between nodes and edges form a complex network structure. Not all paths have a decisive impact on risk propagation; most paths are marginal. To improve the efficiency of the simulation, the system first filters out the paths with the strongest risk transmission capabilities.

[0131] The system traverses the graph, calculating the total weight of each path from the system's source to its end. Path weight is typically defined as the product or weighted sum of the causal influence strengths of all edges along the path. A high threshold is set; a path is only marked as a critical risk transmission path when its total weight exceeds this threshold.

[0132] For example, a path from the access gateway to the core accounting service and then to the database is identified as a critical path because it carries core transactions and has extremely high causal weights on its edges. Conversely, a path from the recommendation service to the log service is ignored due to its lower weight.

[0133] By focusing on key risk transmission paths, the system can concentrate computational resources on counterfactual analysis at the points most prone to problems and with the worst impact. This not only improves the effectiveness of counterfactual sample generation but also significantly enhances the algorithm's operational efficiency, avoiding meaningless blind searches across the entire graph.

[0134] 232: Select target nodes on the key risk transmission path and apply virtual perturbations to the characteristic attributes of the target nodes in standardized multi-source fusion data. Virtual perturbations include traffic surges, latency increases, and message tampering.

[0135] This embodiment is a specific execution operation of counterfactual reasoning, which triggers risks by artificially creating virtual anomalies. The process is to simulate attacks or failures in a virtual digital environment.

[0136] On the identified key risk transmission paths, the system selects representative nodes as intervention targets, usually those nodes that are in bottleneck positions or core business logic positions.

[0137] Subsequently, the system applies virtual perturbations to the normal characteristic attributes of the target node in historical data. These perturbations simulate various attack or failure scenarios that might be encountered in the real world, such as: Traffic surge: Instantly amplify the number of requests per unit time by 10 to 50 times to simulate denial-of-service attacks or traffic surges during peak sales periods; Increased latency: Increase network latency or service processing latency from the normal tens of milliseconds to several seconds or even timeouts to simulate network congestion or service deadlock; Message tampering: Modify fields in transaction requests to illegal values ​​to simulate scenarios where data is hijacked or tampered with; This intervention is not performed in a real physical system, but rather through mathematical simulation on a dynamic causal graph instance in memory.

[0138] By applying various extreme virtual disturbances, the system can test its response under various harsh conditions without touching the production environment. This proactive risk detection, compared to passively waiting for risks to occur, can expose system vulnerabilities in advance, providing valuable training data for subsequent risk defense.

[0139] 233: Retrieve the set of parent nodes of the target node from the dynamic causal graph, and based on the historical data distribution and virtual perturbation of the parent node set, infer the characteristic value of the target node under the perturbation state to generate counterfactual risk samples.

[0140] When a virtual perturbation is applied to the target node, this perturbation propagates downstream along the causal edges, while also being constrained by its upstream parent nodes. The system first retrieves the set of direct parent nodes of the target node from the dynamic causal graph, that is, those upstream variables that directly point to the target node.

[0141] Based on the historical data distribution of the parent node set, the system uses the structural equation modeling mechanism of a linear non-Gaussian acyclic model for deduction. The model reads the historical statistical patterns of the parent nodes and combines them with the virtual perturbation parameters applied to the current link, substituting them into the structural equations for solution.

[0142] For example, the target node is transaction response time, and its parent node is database query time. When a virtual perturbation that increases latency is applied to the parent node, the model calculates the new value of the target node's transaction response time under the perturbation based on the causal relationship between the two.

[0143] Finally, the new values ​​of each node obtained from the deduction are combined to form a complete counterfactual risk sample.

[0144] Unlike simple random noise addition, samples generated based on causal graphs and parent node distribution inference strictly adhere to the physical and logical constraints of the system. This means that the generated counterfactual samples are real and plausible, rather than absurd. Adding these high-quality counterfactual samples to the training set generates highly logically consistent virtual samples, significantly improving the model's accuracy in identifying unknown abnormal patterns.

[0145] 240: An incremental federated learning framework is adopted to perform distributed training on the pre-built risk identification model based on the training set, and a physical consistency constraint loss function is introduced during the training process to obtain an adaptive optimization model.

[0146] Incremental federated learning is a distributed machine learning paradigm that allows multiple microservice nodes to train models locally without sharing raw transaction data, exchanging only model parameters. It is better suited for microservice architectures where data is dispersed and privacy is a concern.

[0147] During training, each microservice node trains its local sub-model using standardized multi-source fusion data and generated counterfactual risk samples. The server is responsible for aggregating the parameters of these sub-models. To ensure that the model not only fits the statistical characteristics of the data but also conforms to the operating rules of the physical system, this step innovatively introduces a physical consistency constraint loss function.

[0148] This loss function adds a penalty term to the traditional classification loss. This penalty term measures whether the model's prediction is consistent with the digital twin simulation results. If the model predicts a transaction to be low-risk, but the digital twin simulation shows that the current system resources are severely overloaded, inevitably leading to a failure, then the physical consistency constraint loss function will generate a large penalty value, forcing the model to adjust its parameters.

[0149] By weighting and summing the data classification loss and the physical consistency constraint loss function, and using the sum as the total loss function, the gradient update and iterative optimization of the model are guided, ultimately resulting in an adaptive optimization model.

[0150] Federated learning protects user privacy and data security; physical consistency constraints inject the system's mechanistic knowledge into the data-driven model, preventing the model from learning erroneous associations. This results in a trained adaptive optimization model that not only has high recognition accuracy but also strong robustness and interpretability, enabling it to make logical judgments even when faced with complex, unseen scenarios.

[0151] In an optional embodiment, step 240 further includes the following steps: 241: Each microservice node trains a local sub-model based on local data and uploads the local model parameters to the aggregation server.

[0152] Each microservice node maintains a local copy of the dataset. To prevent data from leaving the local domain, data is strictly prohibited from leaving the node. The node initiates a local training process, loads a pre-built risk identification model architecture, and performs multiple training rounds using the local dataset.

[0153] During training, the model continuously adjusts its internal parameters using the backpropagation algorithm to minimize the loss function of the local data. This model can be a deep neural network or a gradient boosting tree. After local training is complete, the node does not upload the data; instead, it encrypts or compresses the trained model parameters and uploads them to a centralized aggregation server.

[0154] The upload process typically employs asynchronous or synchronous strategies to ensure that parameter reporting can be completed smoothly even under fluctuating network conditions.

[0155] In a microservice architecture, data is naturally distributed across various services, making centralized training extremely costly and posing compliance risks. Local training keeps data within its domain, eliminating the risk of data leakage. It also leverages the computing resources of each node to achieve collaborative modeling, breaking down data silos and ensuring data privacy and security.

[0156] 242: The aggregation server aggregates local model parameters to generate global model parameters and distributes the global model parameters to each microservice node.

[0157] After receiving local model parameters from each microservice node, the aggregation server merges them according to a preset aggregation strategy. Optionally, a federated averaging algorithm is used, which assigns different weights to each node based on the amount of data, and then performs a weighted average of all uploaded parameters. Nodes with larger data volumes and higher data quality have their model parameters carry a greater weight in the global model, thus avoiding the misleading influence of individual abnormal nodes on the global model.

[0158] After generating global model parameters, the aggregation server distributes them to all participating microservice nodes. Upon receiving the new global parameters, each node replaces its local model's parameters with them, using them as the initial starting point for the next round of training.

[0159] This iterative process continues until the global model converges or reaches a preset number of iterations.

[0160] Through aggregation, the model absorbs data features from all microservice nodes, enabling it to learn more comprehensive risk patterns. Simultaneously, the weighted averaging mechanism effectively suppresses the negative impact of local noise and non-independent, identically distributed data, ensuring the overall model is optimal. The distribution mechanism guarantees synchronized model updates across all nodes, maintaining the consistency of the system's risk control strategy.

[0161] 243: The digital twin of the microservice transaction link receives global model parameters, inputs global model parameters based on the current simulation state, and outputs twin risk prediction results.

[0162] After each round of parameter updates in federated learning, or after model training is complete, the latest global model parameters are synchronously input into the digital twin of the microservice transaction chain. At this point, the digital twin is not merely a passive simulator; it embeds this risk identification model.

[0163] The twin runs the current simulation state based on real-time input, calculating various operational metrics in the virtual system. These simulated operational metrics are then input into the embedded model. The model uses these metrics to perform inference and outputs a risk prediction result for the current simulation state, i.e., the twin risk prediction result.

[0164] For example, a twin simulates a state where CPU utilization reaches 99%, and the model is input into this state to predict a "high-risk" outcome.

[0165] By constructing a closed-loop validation environment and using virtual data provided by a digital twin to test the model, it is equivalent to conducting a high-intensity stress test on the model without interfering with the production environment. This helps to discover the model's performance under extreme conditions and provides a crucial benchmark for calculating the physical consistency constraint loss function.

[0166] 244: Calculate the deviation between the twin risk prediction results and the physical operation rules inside the digital twin of the microservice transaction link, and construct a physical consistency constraint loss function.

[0167] The digital twin of a microservice transaction chain not only stores state data but also encapsulates the physical operating rules. These rules can be theoretical formulas for queuing, benchmark curves for resource performance, or empirical rules based on historical statistics. These rules describe what the system "should" do in a specific state.

[0168] The system compares the twin risk prediction results obtained in step 243 with the theoretical results derived from the laws of physical operation.

[0169] For example, the model predicts a high success rate for transactions, but according to physical laws, the current queue length has exceeded the threshold, inevitably resulting in a large number of timeouts, and there is a huge discrepancy between the two.

[0170] By calculating this deviation, a physical consistency constraint loss function is constructed. The goal of this function is to minimize the difference between the model's predictions and physical laws. If the model violates physical common sense, this loss value will increase, thus acting as a penalty in the total loss function and pushing the model parameters in a direction that conforms to physical laws.

[0171] By incorporating prior knowledge of physics into the training of the artificial intelligence model, and building upon the model's data fitter, the understanding of the system's operating mechanism is further deepened. This improves the model's generalization ability and reliability on out-of-sample data, and avoids the model making absurd predictions that defy common sense.

[0172] In an alternative embodiment, step 244 includes the following steps: 2441: The digital twin of the microservice transaction link calculates the theoretical risk threshold under the current simulation state based on the physical mapping relationship between resource consumption and service response time.

[0173] The digital twin of the microservice transaction chain establishes a nonlinear mapping relationship between resource consumption and service response time and error rate by fitting a large amount of historical data or based on queuing theory models. This relationship is an objective physical law; for example, the higher the resource utilization, the more exponentially the response time increases, and the more sharply the error rate rises.

[0174] In simulation mode, the twin acquires current resource consumption metrics in real time, substitutes them into the aforementioned physical mapping relationship, and calculates the theoretically tolerable risk threshold of the system at that resource level. This theoretical risk threshold defines the system's safety boundary.

[0175] For example, calculations show that when CPU utilization is 85%, the transaction failure rate corresponding to the theoretical risk threshold should not exceed 1%.

[0176] The theoretical risk threshold reflects the physical limits of the system; it is an inviolable physical law. Models must refer to this benchmark when making predictions; otherwise, they are invalid. This provides an objective physical benchmark for model judgment and a specific scale for subsequent deviation calculations.

[0177] 2442: Compare the risk probability values ​​in the twin risk prediction results with the theoretical risk threshold.

[0178] The system obtains the risk probability value output by the model in step 243 and the theoretical risk threshold calculated in step 2441. The two are compared, and the difference is calculated.

[0179] The difference can be either an absolute difference or a relative difference. The purpose of the comparison is to determine whether the model's prediction is too optimistic or too pessimistic. If the model predicts a very low risk, but the theoretical threshold shows a high risk, it indicates that the model has failed to identify the system's potential physical bottlenecks.

[0180] This difference is a direct input to the loss function. The larger the difference, the less reliable the model's predictions are, and the greater the adjustment is needed. The difference quantifies the degree to which the model deviates from physical reality.

[0181] 2443: If the risk probability value is lower than the theoretical risk threshold and the current simulation status shows resource overload, it is determined to be a logical conflict, and the difference caused by the logical conflict is calculated as the deviation.

[0182] Set a judgment condition: the risk probability value is lower than the theoretical risk threshold and the current simulation status shows resource overload.

[0183] Resource overload usually refers to resource utilization exceeding the warning threshold (e.g., CPU > 90%).

[0184] In this situation, the system determines a high theoretical risk threshold based on physical laws, but the model predicts a very low risk. This is a typical logical conflict, meaning that the model is exhibiting severe illusion or underfitting.

[0185] Once a logical conflict is identified, the system immediately calculates the difference between the two as the deviation. This deviation is not only a numerical difference, but also a quantitative representation of the logical error. This deviation will be amplified and included in the physical consistency constraint loss function.

[0186] Risk control models typically perform well under normal traffic conditions, but are prone to failure under extreme resource overload. By specifically penalizing such logical conflicts, the model is forced to learn the basic common sense that "resource overload equals high risk," accurately capturing the model's failure modes under extreme pressure and significantly improving the model's early warning capabilities in high-load system scenarios.

[0187] For example, during the model training phase, an input sample of a seemingly normal flash sale transaction is presented. The transaction amount is small, and the user behavior is normal. However, in the digital twin, the simulation shows that the current system load has reached its physical limits.

[0188] The microservice transaction chain digital twin displays in real time that the current concurrent connections for the inventory service have reached the maximum of 10,000, and the CPU utilization is 99.5%. The twin's built-in queuing theory model (M / M / 1 model) calculates, based on the current state, that the expected service response time will exceed the business timeout limit (2000ms). Based on physical laws, under the current resource exhaustion state, this transaction will theoretically inevitably time out or fail. Therefore, the system calculates a theoretical risk threshold of 95%, i.e., extremely high risk.

[0189] The pre-trained adaptive optimization model is input with the sample's features. Because the transaction amount is small and the user behavior is normal, the model, based on weights trained from historical data, predicts a high probability of success for the transaction, outputting a risk probability value of only 5%, i.e., low risk. The system compares the model's predicted value of 5% with the theoretical threshold of 95% for twins. The difference is huge; the model considers it safe, while physical laws determine it's doomed.

[0190] The system checks the simulation status and confirms that current resources are overloaded (CPU 99.5%, connections full). The conditions are met: risk probability value 5% < theoretical risk threshold 95% and resources are overloaded. The system determines that a serious logical conflict has occurred. The model has committed the error of "failure to detect potential danger." The system calculates the difference deviation = |5% - 95%| = 90%. This 90% deviation value is input into the physical consistency constraint loss function, generating a large gradient penalty. In subsequent iterative training, this penalty term forces the model to correct its parameters, enabling it to learn that when system resources are overloaded, regardless of the transaction amount, it must predict high risk, thus eliminating the illusion that the model violates physical common sense.

[0191] 245: Combine the data classification loss and the physical consistency constraint loss function to update the global model parameters, iterate until convergence, and obtain the adaptive optimization model.

[0192] The system defines a total loss function, optionally in the form: Total Loss = Data Classification Loss + λ * Physical Consistency Constraint Loss Function. Here, λ is a weighting coefficient used to balance the importance of fitting the data and adhering to physical laws.

[0193] In each training round, the gradient is calculated based on the total loss function, and the global model parameters are updated using stochastic gradient descent. If the model predicts accurately but violates physical laws, the physical consistency constraint loss function term will increase, widening the total loss and forcing the model to adjust its parameters to conform to physical laws. If the model conforms to physical laws but misclassifies the data, the data classification loss term will come into play.

[0194] This process iterates continuously, performing multiple rounds of aggregation and updates within the federated learning framework, until the total loss function converges to a minimum point, or the performance metrics on the validation set no longer improve.

[0195] The resulting adaptive optimization model is a hybrid intelligent agent that deeply analyzes the statistical patterns of historical data and deeply understands the physical operating mechanism of the system.

[0196] This dual-drive optimization approach enables the adaptive optimization model to maintain a high recognition rate for routine fraudulent transactions when facing complex and ever-changing microservice environments, while also maintaining rational judgment when the system experiences abnormal fluctuations. It avoids severe false alarms and false negatives due to data noise, producing a highly reliable model with excellent performance, and truly achieving a unity of intelligence and robustness.

[0197] 300: Combining the preliminary risk identification results with the real-time simulation risk assessment results, query the dynamic causal graph, identify the risk transmission path and risk root cause, and determine the final risk level based on the risk transmission path and risk root cause.

[0198] This embodiment employs a comprehensive assessment mechanism to ultimately characterize the risk. The implementation process integrates data-driven model prediction, digital twin simulation, and causal graph source analysis.

[0199] First, the system summarizes the preliminary risk identification results from the pre-trained adaptive optimization model and the real-time simulation risk assessment results from the digital twin of the microservice transaction link.

[0200] To eliminate the bias of a single perspective, the system performs a weighted fusion of the two results. For example, if the model predicts high risk, but the twin shows that the system is in an extremely healthy state, the risk level may be appropriately downgraded; conversely, if the model predicts low risk, but the twin predicts an impending avalanche, the risk level will be significantly upgraded.

[0201] Subsequently, based on the fused risk characteristics, the system queries a dynamic causal graph. Inputting the current set of abnormal indicators, the system searches the graph for causal paths that can explain these anomalies. The graph returns the most likely transmission chain leading to the current risk, such as which service initiated the anomaly, which intermediate steps it passed through, and which business indicator it ultimately affected.

[0202] The system marks the starting node of the transmission chain as the root cause of the risk. For example, the root cause might be identified as a disk I / O anomaly on a database server.

[0203] Finally, considering the severity of the root cause of the risk, the length of the risk transmission path, the number of key nodes involved in the path, and the preliminary risk score, the final risk level is calculated. The level is typically divided into three categories: high-risk, medium-risk, and low-risk.

[0204] Compared to the black-box output of a single model, this embodiment provides accurate, interpretable, and actionable final risk conclusions by combining multi-source information and causal attribution. It not only informs operations and maintenance personnel about the fault details but also the causes and root causes. This helps shorten troubleshooting time, supports rapid loss mitigation, and achieves a closed loop from risk identification to risk management.

[0205] In an optional embodiment, step 300 further includes the following steps: 310: Based on the preliminary risk identification results and the real-time simulation risk assessment results, determine the target abnormal node set that triggers the risk. The target abnormal node set includes abnormal transaction behavior feature nodes and abnormal microservice running status nodes.

[0206] The system first analyzes the preliminary risk identification results and extracts transaction behavior features that the model determines are abnormal. For example, if a transaction is determined to be fraudulent, then the corresponding user credit score, transaction amount, device fingerprint, and other feature nodes are marked as abnormal transaction behavior feature nodes.

[0207] Simultaneously, the system analyzes the real-time simulation risk assessment results to identify services or resources in the twin that have exceeded their state limits. For example, if the simulation results show that the order service is experiencing a memory overflow, then characteristic nodes such as the order service's memory usage rate and GC frequency are marked as abnormal microservice running state nodes.

[0208] These nodes are aggregated, deduplicated, and a target abnormal node set is formed. This set represents all abnormal elements in the system at the current moment, whether they are business-level or technical-level.

[0209] By defining a set of anomalous nodes, the abstract risk is visualized as a specific anomalous node, providing a clear starting point and end point for subsequent path searching in the causal graph, making the source tracing process targeted and avoiding blind searching in the entire graph.

[0210] 320: Execute a path search algorithm in a dynamic causal graph to find directed causal paths between target abnormal node sets. In the dynamic causal graph, nodes represent indicators or events, edges represent causal relationships mined based on an improved linear non-Gaussian acyclic causal model, and edge weights represent the intensity of causal influence.

[0211] In a dynamic causal graph, there may be multiple connected paths between nodes in the target set of abnormal nodes. The system executes a path search algorithm to find directed causal paths that connect nodes with abnormal microservice running status with nodes exhibiting abnormal transaction behavior characteristics.

[0212] During the search process, edge weights are considered as a key metric. The algorithm prioritizes paths with high weights because higher weights imply stronger causal relationships and are more likely to be the true channels of risk transmission. Path length is also a consideration; the algorithm typically favors shorter and more direct paths because Occam's razor principle suggests that the simplest explanation is often closest to the truth.

[0213] For example, the search found a path: Database node (abnormal) - Slow stored procedure response (high edge weight) - Order service timeout (high edge weight) - Payment failure (abnormal transaction behavior).

[0214] By tracing the directed causal path, the flow of risk within the system was reproduced. The system not only confirmed the correlation between various anomalies, but also clarified the order of their impact, providing a clear logical chain for subsequent determination of root causes and assessment of risk levels. It proved how the risk was transmitted step by step from the underlying infrastructure to the upper-level business.

[0215] 330: The directed causal path with the starting node being the microservice running status node and the ending node being the transaction behavior node is determined as the risk transmission path, and the starting node is marked as the risk root cause.

[0216] Among all the directed causal paths found, the system filters out those that start at a microservice runtime status node and end at a transaction behavior node. Paths in this direction represent system failures leading to business risks, which are precisely the technical risks that need to be focused on preventing and resolving. Conversely, if the path points from a transaction behavior node to a microservice runtime status node, it indicates that excessive business traffic has overwhelmed the system, which falls under the category of business risks.

[0217] For paths that meet the criteria, they will be formally identified as the risk propagation path for this round of events. The starting node of the path, that is, the microservice runtime status node where the anomaly first occurs, will be marked as the root cause of this risk.

[0218] By marking the starting node as the root cause of the risk, the responsible party is accurately identified. This allows maintenance personnel to know immediately which service or device to repair, rather than getting lost in a large number of alarm messages, thus improving the efficiency of fault repair.

[0219] 340: Calculate the cumulative value of the causal influence intensity of all edges on the risk transmission path as the path risk value, and determine the final risk level based on the path risk value and the path length.

[0220] For each defined risk transmission path, the system reads the weight of each edge on the path, i.e., the causal influence strength. The weights of all edges on the path are summed to obtain the total causal influence strength of the path, which is recorded as the path risk value.

[0221] A higher path risk value indicates a stronger risk transmission effect, meaning the anomaly at the root node has a greater destructive impact on downstream business metrics. The system also considers path length. Shorter paths generally indicate more direct and rapid risk transmission, and a higher degree of urgency.

[0222] The system uses a multi-threshold method to determine the final risk level by combining the path risk value and path length. For example: if the path risk value exceeds threshold A and the path length is less than 3 hops, it is judged as high-risk and must be immediately blocked to stop losses; if the path risk value is between thresholds A and B, it is judged as medium-risk and requires manual intervention; if the path risk value is below threshold B, it is judged as low-risk and only logs need to be recorded.

[0223] Through quantitative calculations, refined and scientific management of risk levels is achieved. Risk levels are no longer subjectively determined but objectively assessed based on mathematical models. This enables the system to rationally allocate operational resources according to the severity and urgency of risks, ensuring that major risks are addressed first, thereby minimizing system losses. Simultaneously, the quantified risk values ​​can also serve as historical data for continuous optimization and improvement of subsequent models.

[0224] For example, the risk monitoring system detects a failed transaction, the initial model identifies it as a payment anomaly, and the digital twin also issues a response timeout warning. The next step is to determine which specific service is experiencing the problem and classify it accordingly.

[0225] Based on the preliminary risk identification results: the transaction was marked as a payment timeout, and the abnormal transaction behavior feature node N_trans_timeout was extracted. The system detected a surge in slow query logs for "Database Service A", and the abnormal microservice running status node N_db_slow was extracted. The target abnormal node set was determined to be {N_trans_timeout, N_db_slow}.

[0226] In the dynamic causal graph, the system initiates a path search algorithm. The graph structure shows that N_db_slow (database slow) has a directed edge pointing to N_order_high_load (order service high load), with a weight of 0.9; N_order_high_load has a directed edge pointing to N_pay_timeout (payment timeout), with a weight of 0.8; and finally, it points to N_trans_timeout. The algorithm finds a complete path from the microservice running status node to the transaction behavior node: N_db_slow - N_order_high_load - N_pay_timeout - N_trans_timeout.

[0227] The starting node of this path is the microservice runtime status node, and the ending node is the transaction behavior node. This matches the definition of a risk propagation path and has been officially identified as the risk propagation path for this incident. The starting node N_db_slow is marked as the root cause of the risk. This means that the root cause of the transaction failure was slow database queries, rather than a problem with the payment service itself.

[0228] The system calculates the cumulative causal impact strength of all edges along the path. In this example, the path risk value = 0.9 (DB-Order) + 0.8 (Order-Pay) + 0.7 (Pay-Trans) = 2.4. The path length is 3 hops, which is considered an extremely short link, indicating that risk transmission is very direct and rapid. The system's default rule is: if the path risk value > 2.0 and the length < 4, it is considered high-risk. The system outputs a final risk level of high-risk and highlights "Database Service A" in red on the operations and maintenance dashboard, prompting operations and maintenance personnel to prioritize database issues rather than investigating the payment gateway, thus achieving precise loss mitigation.

[0229] The method for identifying transaction anomaly risks in embodiments of the present invention has been described above. The following describes the device for identifying transaction anomaly risks in embodiments of the present invention. Please refer to [link / reference]. Figure 2 One embodiment of the transaction anomaly risk identification device in this invention includes: The feature extraction module 410 is used to collect transaction business data, microservice operation data and link call data in real time, and extract features from the transaction business data, the microservice operation data and the link call data to obtain standardized real-time multi-dimensional risk association features.

[0230] The risk identification module 420 is used to input the real-time multi-dimensional risk association features into a pre-trained adaptive optimization model to obtain preliminary risk identification results, and to synchronize the real-time multi-dimensional risk association features to the microservice transaction link digital twin, and use the microservice transaction link digital twin to simulate the current transaction flow state to generate real-time simulation risk assessment results.

[0231] The final risk analysis module 430 is used to combine the preliminary risk identification results with the real-time simulation risk assessment results, query the dynamic causal graph, identify the risk transmission path and risk root cause, and determine the final risk level based on the risk transmission path and risk root cause.

[0232] above Figure 2 The transaction anomaly risk identification device in this embodiment of the invention will be described in detail from the perspective of modular functional entities. The computer equipment in this embodiment of the invention will be described in detail from the perspective of hardware processing.

[0233] Figure 3This is a schematic diagram of a computer device 500 provided in an embodiment of the present invention. The computer device 500 can vary significantly due to different configurations or performance characteristics. It may include one or more central processing units (CPUs) 510 (e.g., one or more processors) and a memory 520, and one or more storage media 530 (e.g., one or more mass storage devices) for storing application programs 533 or data 532. The memory 520 and storage media 530 may be temporary or persistent storage. The program stored in the storage media 530 may include one or more modules (not shown in the diagram), each module may include a series of instruction operations on the computer device 500. Furthermore, the processor 510 may be configured to communicate with the storage media 530 and execute the series of instruction operations in the storage media 530 on the computer device 500.

[0234] Computer device 500 may also include one or more power supplies 540, one or more wired or wireless network interfaces 550, one or more input / output interfaces 560, and / or one or more operating systems 531, such as Windows Server, MacOSX, Unix, Linux, FreeBSD, etc. Those skilled in the art will understand that... Figure 3 The computer device structure shown does not constitute a limitation on the computer device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0235] The present invention also provides a computer device, which includes a memory and a processor. The memory stores computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor performs the steps of the transaction anomaly risk identification method in the above embodiments.

[0236] The present invention also provides a computer-readable storage medium, which can be a non-volatile computer-readable storage medium or a volatile computer-readable storage medium, wherein the computer-readable storage medium stores instructions that, when executed on a computer, cause the computer to perform the steps of a transaction anomaly risk identification method.

[0237] Unlike existing technologies, this application employs an extended Berkeley packet filter to collect microservice runtime data from the kernel space. Combined with open observability technology, it achieves end-to-end tracing, avoiding the intrusive impact of traditional data logging on business code, reducing maintenance costs and system risks. By directly obtaining resource utilization and response time from the kernel space, it ensures the real-time nature and accuracy of microservice runtime data, achieving comprehensive awareness of transaction business data, microservice runtime data, and link call data, breaking the limitations of a single data source. This application also utilizes a Kafka message queue for high-throughput transmission, employs a Flink stream processing engine for real-time cleaning, standardization, and feature extraction, and uses Radisson cache for hot data, ensuring system stability under high concurrency scenarios, optimizing data flow efficiency, achieving end-to-end low latency, meeting the stringent requirements of real-time risk control, and significantly improving the processing efficiency of subsequent risk identification models by caching hot data. By constructing a digital twin fully synchronized with the physical microservice cluster, employing a push-pull combined differentiated synchronization strategy, and using Monte Carlo algorithms for risk simulation, real-time synchronization between the physical and virtual systems is achieved. This accurately replicates the entire flow of each transaction and, by simulating scenarios such as extreme traffic surges, identifies system bottlenecks and potential crash points in advance. This application also introduces an improved linear non-Gaussian acyclic model to mine causal relationships between data, combines domain knowledge-constrained optimization algorithms, and constructs a dynamically updated causal graph. Compared to traditional graph neural networks that only capture node relationships, this technology clarifies the causal direction of risk propagation, solves the problem of difficulty in identifying cross-service chain risks, accurately locates the root service and intermediate nodes of risk transmission, reduces the time required for risk tracing, supports rapid loss mitigation, and ensures that causal relationships adapt to the dynamic changes in the microservice architecture through incremental learning and real-time updates of the causal graph. This application also utilizes causal graphs for counterfactual reasoning, generating counterfactual risk samples containing potential anomalous scenarios through virtual perturbations. These samples are then mixed with real data as the training set. This addresses the scarcity of risk samples in real-world scenarios by generating a large number of high-quality, logically consistent virtual anomalous samples, exposing the model to various extreme boundary conditions during training and improving its ability to identify unknown or rare risk patterns and its generalization performance. When training the hybrid model, a physical consistency constraint loss function is introduced to calculate the deviation between the model's predictions and the internal physical operating rules of the digital twin. This forces the model to learn decisions that conform to the laws of the physical system, avoiding logical fallacies such as severe resource overload but extremely low predicted risk. Combined with data classification loss and physical constraints, this significantly improves the accuracy of risk identification. These technologies are not isolated but deeply collaborative through a dual-engine driven architecture. The microservice transaction link digital twin provides the physical reality and simulation environment for system operation, the dynamic causal graph provides the logical structure and knowledge graph for risk transmission, and incremental federated learning ensures the model's continued effectiveness under data dispersion and dynamic architectural changes.The combination of these three elements has achieved a breakthrough from isolated detection to link-based collaboration, and from post-event identification to pre-event warning, constructing a high-precision, adaptive, and real-time end-to-end risk identification system that integrates transaction semantics and system operation status.

[0238] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on its differences from other embodiments. In particular, the storage medium embodiments and computer device embodiments are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0239] This application can be used in a wide range of general-purpose or special-purpose computing system environments or configurations. For example: personal computers, handheld or portable devices, tablet devices, multiprocessor systems, microprocessor-based systems, network PCs, minicomputers, distributed computing environments including any of the above systems or devices, etc.

[0240] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative; multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed.

[0241] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment, depending on actual needs.

[0242] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

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

Claims

1. A method for identifying abnormal transaction risks, characterized in that, include: Real-time collection of transaction business data, microservice operation data, and link call data; and feature extraction of the transaction business data, microservice operation data, and link call data to obtain standardized real-time multi-dimensional risk association features; The real-time multi-dimensional risk correlation features are input into a pre-trained adaptive optimization model to obtain preliminary risk identification results. The real-time multi-dimensional risk correlation features are then synchronized to the microservice transaction link digital twin. The microservice transaction link digital twin is used to simulate the current transaction flow state and generate real-time simulation risk assessment results. By combining the preliminary risk identification results with the real-time simulation risk assessment results, the dynamic causal graph is queried to identify the risk transmission path and the root cause of the risk, and the final risk level is determined based on the risk transmission path and the root cause of the risk.

2. The method for identifying abnormal transaction risks according to claim 1, characterized in that, Before inputting the real-time multi-dimensional risk association features into the pre-trained adaptive optimization model, the method further includes: Collect historical transaction data, historical microservice operation data, and historical link call data to obtain standardized multi-source fusion data; A digital twin of the microservice transaction link and a dynamic causal graph are constructed in parallel. The digital twin of the microservice transaction link is used to simulate the running state and resource load of the physical microservice cluster, and the dynamic causal graph is used to describe the causal dependencies between transaction behavior, service running state and link calls. The dynamic causal graph is used to perform counterfactual inference to generate counterfactual risk samples containing potential abnormal scenarios, and the counterfactual risk samples are mixed with the standardized multi-source fusion data as a training set. An incremental federated learning framework is used to perform distributed training on the pre-built risk identification model based on the training set, and a physical consistency constraint loss function is introduced during the training process to obtain the adaptive optimization model.

3. The method for identifying abnormal transaction risks according to claim 2, characterized in that, The parallel construction of the microservice transaction link digital twin includes: A transaction link meta-model containing risk transmission weight factors is constructed. The transaction link meta-model defines the core elements of service nodes, call relationships, transaction process, operation indicators and risk transmission weights. Extract node attributes and link topology information from the standardized multi-source fusion data, map the physical microservice cluster to the transaction link metamodel, and generate an initial twin instance; Based on the causal strength of the nodes in the dynamic causal graph, the risk sensitivity of each service node is calculated, and a differentiated synchronization strategy is determined based on the risk sensitivity. The running status of the initial twin instance is updated through the differentiated synchronization strategy, so that the digital twin of the microservice transaction link is synchronized with the physical microservice cluster in real time.

4. The method for identifying abnormal transaction risks according to claim 2, characterized in that, The parallel construction of the dynamic causal graph includes: A linear non-Gaussian acyclic model was used to mine the causal relationships among variables in the standardized multi-source fusion data and construct an initial causal graph. Calculate the mutual information and conditional independence test statistics of each causal relationship edge, and remove redundant edges from the initial causal graph based on the calculation results to obtain the pruned causal graph; The newly generated incremental data is acquired, and the node and edge weights of the pruned causal graph are dynamically updated using a structured causal model to output the dynamic causal graph containing risk transmission paths and weights.

5. The method for identifying abnormal transaction risks according to claim 4, characterized in that, The step of using the dynamic causal graph to perform counterfactual inference and generate counterfactual risk samples containing potential abnormal scenarios includes: Identify key risk transmission paths in the dynamic causal graph, where the key risk transmission paths are those whose causal weights exceed a preset threshold; Target nodes are selected along the key risk transmission path, and virtual perturbations are applied to the characteristic attributes of the target nodes in the standardized multi-source fusion data. The virtual perturbations include traffic surges, latency increases, and message tampering. The set of parent nodes of the target node is retrieved from the dynamic causal graph. Based on the historical data distribution of the parent node set and the virtual perturbation, the characteristic value of the target node under the perturbation state is deduced, and the counterfactual risk sample is generated.

6. The method for identifying abnormal transaction risks according to claim 2, characterized in that, The incremental federated learning framework is used to perform distributed training on the pre-built risk identification model based on the training set, and a physical consistency constraint loss function is introduced during the training process to obtain the adaptive optimization model, including: Each microservice node trains a local sub-model based on local data and uploads the local model parameters to the aggregation server; The aggregation server aggregates the local model parameters to generate global model parameters, and then distributes the global model parameters to each microservice node; The microservice transaction link digital twin receives the global model parameters, inputs the global model parameters based on the current simulation state, and outputs the twin risk prediction result; Calculate the deviation between the twin risk prediction result and the physical operation law inside the digital twin of the microservice transaction link, and construct a physical consistency constraint loss function; The global model parameters are updated by combining the data classification loss and the physical consistency constraint loss function, and the iteration continues until convergence, thus obtaining the adaptive optimization model.

7. The method for identifying abnormal transaction risks according to claim 1, characterized in that, The process of extracting features from the transaction data, the microservice operation data, and the link call data to obtain standardized real-time multi-dimensional risk association features includes: Extract user behavior statistics, transaction pattern characteristics, and business anomaly characteristics from the transaction business data to obtain business dimension characteristics; Extract resource utilization, service health, and container status characteristics from the microservice runtime data to obtain system-level characteristics; Extract the call topology, call performance, and error rate features of the link call data to obtain link-dimensional features; By integrating the preprocessed business dimension features, system dimension features, and link dimension features, the standardized real-time multi-dimensional risk association features are obtained.

8. A device for identifying abnormal transaction risks, characterized in that, include: The feature extraction module is used to collect transaction business data, microservice operation data and link call data in real time, and extract features from the transaction business data, microservice operation data and link call data to obtain standardized real-time multi-dimensional risk association features; The risk identification module is used to input the real-time multi-dimensional risk correlation features into a pre-trained adaptive optimization model to obtain preliminary risk identification results, and to synchronize the real-time multi-dimensional risk correlation features to the microservice transaction link digital twin, and use the microservice transaction link digital twin to simulate the current transaction flow state to generate real-time simulation risk assessment results. The final risk analysis module is used to combine the preliminary risk identification results with the real-time simulation risk assessment results, query the dynamic causal graph, identify the risk transmission path and risk root cause, and determine the final risk level based on the risk transmission path and risk root cause.

9. A computer device, characterized in that, The computer device includes: a memory and at least one processor, wherein the memory stores instructions; The at least one processor invokes the instructions in the memory to cause the computer device to execute the transaction anomaly risk identification method as described in any one of claims 1-7.

10. A computer-readable storage medium storing instructions thereon, characterized in that, When the instruction is executed by the processor, it implements the transaction anomaly risk identification method as described in any one of claims 1-7.

Images