A smart audit whole-process information communication management method and system

Abstract

The application discloses a kind of wisdom audit whole-process information communication management method and system, it is related to digital management technical field, method includes: according to audit system source code is parsed modeling by code attribute graph, and microservice unit cluster is divided, builds gateway route and forms audit microservice framework. Upload the data to be audited to complete automatic audit and obtain audit result, with immutable event flow storage, generate and correlate structured attribution chain when abnormal. Side deployment against tester periodic test, output contains black box, white box dimension operation evaluation index, according to this, carry out local optimization or architecture reconstruction to framework.The application solves the technical problem that traditional audit system is split when microservice architecture, which relies on manual experience, leads to unreasonable boundary division, and lacks self-adaptive optimization capability after system deployment, achieves audit system reasonable architecture division and continuous self-optimization, ensures audit whole-process reliable execution and long-term stable evolution technical effect.

Description

Technical Field

[0001] This invention relates to the field of digital management technology, and in particular to a smart audit full-process information communication management method and system. Background Technology

[0002] Today, industrial big data has deeply empowered the digitalization of enterprise internal audits. Intelligent audit end-to-end information and communication systems are the core carriers for audit data flow and risk management. Microservice architecture has become the mainstream construction solution, and its architectural stability and end-to-end evidence storage and traceability capabilities directly affect the compliance of industrial audit data and the accuracy of risk assessment. Existing audit microservices mostly rely on manual experience to break down modules and build communication gateways, lacking quantitative decomposition standards; the system only undergoes one-time functional testing before going live, with no routine risk inspections during operation; audit business link data lacks an immutable storage mechanism, and cannot automatically generate a complete chain of attribution evidence when business disputes or system anomalies occur. The above solutions are difficult to adapt to the full lifecycle management needs of massive audit data in industrial big data, cannot achieve autonomous architectural iteration and optimization, resulting in difficulty in predicting risks in the audit data communication link, low efficiency in problem tracing, and difficulty in supporting accurate control and compliance evidence collection throughout the entire audit process in industrial scenarios. Summary of the Invention

[0003] This application provides a smart audit full-process information communication management method and system, which solves the technical problems of traditional audit systems relying on manual experience during microservice architecture splitting, resulting in unreasonable boundary division, and lack of adaptive optimization capabilities after system deployment.

[0004] The first aspect of this application provides a smart audit end-to-end information communication management method, the method comprising: modeling business function themes based on multi-dimensional analysis of code attribute graphs according to the source code of the audit system, obtaining a microservice unit cluster and establishing gateway routing, and determining the audit microservice framework; uploading data to be audited, performing automatic audit processing under the framework service link according to the audit microservice framework, and obtaining audit results; storing the audit results in the form of an immutable event stream, wherein, if an exception is triggered, reasoning and associating a structured attribution chain; wherein, by deploying an adversarial tester on the edge of the audit microservice framework, performing periodic adversarial tests on the audit microservice framework, generating operational evaluation indicators including black-box performance and white-box activation mode analysis, and performing local optimization and architecture reconstruction processing on the audit microservice framework.

[0005] The second aspect of this application provides a smart audit end-to-end information communication management system, the system comprising: an audit microservice framework construction module, which performs business function theme modeling based on the source code of the audit system and multi-dimensional analysis of code attribute graphs to obtain a microservice unit cluster and establish gateway routing, thereby determining the audit microservice framework; an audit result acquisition module, which uploads data to be audited and performs automatic audit processing under the framework service link according to the audit microservice framework to obtain audit results; an audit result storage module, which stores the audit results in the form of an immutable event stream, wherein if an exception is triggered, a structured attribution chain is inferred and associated; and a runtime evaluation index acquisition module, which performs periodic adversarial testing on the audit microservice framework by deploying an adversarial tester on the side of the audit microservice framework, generates runtime evaluation indexes including black-box performance and white-box activation mode analysis, and performs local optimization and architecture reconstruction processing on the audit microservice framework.

[0006] One or more technical solutions provided in this application have at least the following technical effects or advantages:

[0007] This application achieves full-domain modeling of the audit system's program code, automatically divides business service units based on business content, builds a unified communication gateway, continuously simulates various abnormal inputs to periodically verify the system's operating status, solidifies and retains all audit business operations in chronological order, and automatically derives the complete problem chain when anomalies occur. Based on the system's operational health status, it autonomously completes architecture adjustment and optimization, realizing full-process data communication, risk inspection, compliance evidence storage, and adaptive architecture iteration for audit business. It adapts to the digital management and control needs of the entire audit process in industrial big data scenarios, improves the stability of audit data flow, the efficiency of problem tracing, and the long-term operation and maintenance capabilities of the system, achieving the technical effect of reasonable architecture division and continuous self-optimization of the audit system, ensuring reliable execution and long-term stable evolution of the entire audit process. Attached Figure Description

[0008] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0009] Figure 1 This is a flowchart illustrating a smart audit full-process information communication management method provided in an embodiment of this application.

[0010] Figure 2 This is a schematic diagram of the structure of a smart audit full-process information communication management system provided in an embodiment of this application.

[0011] Figure labeling: Audit microservice framework construction module 1, audit result acquisition module 2, audit result storage module 3, and operation evaluation index acquisition module 4. Detailed Implementation

[0012] This application provides a smart audit full-process information communication management method and system, which solves the technical problems of traditional audit systems relying on manual experience during microservice architecture splitting, resulting in unreasonable boundary division, and lack of adaptive optimization capabilities after system deployment.

[0013] 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 them. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0014] It should be noted that the terms "first," "second," etc., in the specification and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. 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 server that includes a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or modules not explicitly listed or inherent to such processes, methods, products, or devices.

[0015] Example 1, as Figure 1 As shown, a smart audit end-to-end information communication management method includes:

[0016] Based on the source code of the audit system, business function theme modeling is performed using multidimensional analysis of code attribute graphs to obtain microservice unit clusters and establish gateway routing, thus determining the audit microservice framework.

[0017] In this embodiment, the audit system is a digital business management platform used by the group to support the entire online operation of audit planning, on-site implementation, rectification, and archiving. The code attribute graph is a unified program calculation model that integrates multi-dimensional information such as program syntax, control, dependencies, and version evolution for quantitatively decomposing services. Business function themes are standardized audit business classification tags extracted from audit business document corpora, such as economic responsibility audits and engineering audits. Microservice unit clusters are collections of independent, separately deployable business code modules divided according to code cohesion and coupling characteristics and matching audit business themes. Gateway routing is a set of access forwarding rules deployed at the service front end for unified authentication and distributing audit data requests according to business coupling relationships. The audit microservice framework is a complete distributed audit business operation foundation built from various audit microservice unit clusters and a unified gateway routing.

[0018] Specifically, the process of determining the audit microservice framework is as follows: First, the source code of the audit system is obtained and parsed into a code attribute graph with a single computable graph structure. Then, community detection analysis is performed on the code attribute graph, and disjoint code clusters are determined based on a first high internal cohesion threshold and a second low external coupling threshold. These disjoint code clusters serve as candidate boundaries for microservice decomposition. Subsequently, based on a business document corpus, similarity matching and topic modeling are performed between the disjoint code clusters and business function topics to obtain audit microservice unit clusters. Finally, based on the coupling relationship of microservice business functions, gateway routing for information communication is established for the audit microservice unit clusters, ultimately determining the audit microservice framework. The specific implementation process of this step will be described in detail later.

[0019] Upload the data to be audited, and perform automatic auditing processing under the framework service link according to the audit microservice framework to obtain the audit results.

[0020] In this embodiment of the application, the data to be audited is collected from the enterprise data platform, various business systems, engineering, material, and personnel ledgers, as well as various structured and unstructured business data submitted at the audit site.

[0021] Optionally, the data to be audited includes basic data of power transmission and transformation projects, distribution network projects, small-scale infrastructure projects, technological transformation projects, maintenance projects, contract management data, and material management data synchronized from the standard data management platform, as well as various structured and unstructured data such as leadership performance reports, business ledgers, and internal management system documents submitted online by the audited entity. Auditors submit data upload requests through the unified service gateway of the audit microservice framework. After the unified service gateway completes user authentication and request format verification, it routes and distributes the data to the data access interface of the corresponding audit business microservice unit according to the audit project type and audit matter to be audited, thus completing the standardized access of the data to be audited.

[0022] Upon receiving the data to be audited, each audit business microservice unit uniformly performs data preprocessing operations. This includes mapping fields, validating formats, and cleaning anomalies for structured data, and extracting text content, standardizing formats, and tagging business categories for unstructured documents. The extraction of key business information from unstructured documents involves using regular expressions to match key fields such as amount, date, contract number, and personnel name, combined with named entity recognition technology to extract information such as the business entity, the period of the transaction, and the amount of funds transferred. The extracted results are then mapped to the item numbers in the audit item list. After preprocessing, the audit data is stored in the corresponding microservice unit's business database, categorized by audit project and business dimension.

[0023] The audit microservice framework incorporates a process engine component, supporting the pre-setting of differentiated audit business service execution links for different types of audit projects. Audit project types include economic responsibility audits, engineering project audits, material procurement audits, and financial revenue and expenditure audits. The service execution link corresponding to each type of audit project can be visually configured through the process engine, supporting operations such as adding, deleting, and adjusting the execution order of service nodes in the link. The configured link is saved as a dedicated execution template for the corresponding audit type. When automatic audit processing is initiated, the audit microservice framework automatically matches and calls the corresponding pre-set service execution link based on the type identifier of the current audit project, sequentially calling the corresponding audit business microservice units for processing according to the pre-set node order of the link.

[0024] The audit service chain sequentially calls each audit business microservice unit according to a preset node order. The chain first calls the audit project planning management microservice unit to match the audit plan document and audit item list for the current audit project, clarifying the scope of verification and judgment criteria for this audit. It then calls the pre-audit analysis microservice unit, which deploys an audit model library, including models for engineering cost anomaly analysis, procurement price deviation analysis, and expense reimbursement compliance analysis. The reasonable thresholds for judging abnormal data in each model are comprehensively set based on the average fluctuation range of the auditee's historical three-year period business data, industry-standard benchmarks, and internal management system requirements. These thresholds can be configured differently according to audit project type and auditee category, and can be dynamically adjusted based on audit execution feedback. The pre-audit analysis microservice unit calls the corresponding audit analysis model to perform multi-dimensional comparative analysis of the operating indicators, business process nodes, and fund transfer records in the audit data, screening for abnormal data and operational risk points exceeding reasonable threshold ranges, generating an audit risk list and marking the corresponding risk level. The process then invokes the audit working paper management microservice unit. This unit has a pre-defined mapping table between audit items and audit working paper template fields. This mapping table is stored in the database as a configuration table, allowing system administrators to maintain and update it online. Based on the audit suspicion list, it automatically matches the corresponding audit items, retrieves the standardized audit working paper template, and fills in the corresponding audit working paper fields with the suspicion data details, verification process records, and risk level judgment results, generating a draft audit working paper. Finally, the process invokes the audit approval form management microservice unit. This unit has a built-in audit violation clause library. For verified audit suspicions, it performs keyword matching based on the business category and violation nature keywords of the suspicion, and supplements the matching results with semantic similarity calculations. Clauses with a matching degree higher than the preset matching threshold are automatically associated with the corresponding audit approval form, generating a draft audit approval form.

[0025] The process includes a built-in fault tolerance mechanism. If a single microservice unit call times out or fails, it automatically retryes up to three times. If the retry still fails, a service circuit breaker is triggered. If the failed node is a non-core processing node, the current node is skipped, and subsequent links continue execution, while an exception log is generated and pushed to the system management module. If the failed node is a core processing node, the current link execution is immediately terminated, all intermediate processing data generated in this link is rolled back, and an exception message is returned to the operation terminal. After the link execution is complete, the unified service gateway of the audit microservice framework aggregates the processing output results of each audit business microservice unit, integrating them into a complete audit result that includes a detailed list of audit suspicions, audit working papers, corresponding violations of audit issues, and risk level determination results. The audit result is returned to the operation terminal and simultaneously stored in the audit project results archive.

[0026] By leveraging the configurable service execution chain scheduling, multi-dimensional audit analysis model verification, and end-to-end fault tolerance mechanism of the audit microservice framework, automatic audit processing is achieved. This enables the system to adapt to various audit business scenarios, improve the accuracy and stability of audit data processing, and ensure consistency in processing standards for different audit projects.

[0027] The audit results are stored in the form of an immutable event stream, wherein if an anomaly is triggered, a structured attribution chain is inferred and associated.

[0028] In this embodiment, the immutable event stream format is a time-series data transmission and storage medium that only supports append-only writing, cannot be tampered with or deleted, and stores the entire process operation record in chronological order. The structured attribution chain is a standardized source tracing data structure that starts with the root cause of the anomaly, connects related events at all levels according to the causal transmission order, and records the causes and effects of the problem in a hierarchical manner.

[0029] In one embodiment of this application, the audit results are first integrated to generate a complete audit chain. The complete audit chain is then transmitted and stored in the audit archive in the form of an immutable event stream in chronological order. When an audit result is abnormal or a business dispute arises, the corresponding audit event is retrieved from the audit archive to perform logical reasoning and causal attribution processing, generating a structured attribution chain. Finally, the structured attribution chain is sent back and stored in the audit archive, establishing a binding relationship between the structured attribution chain and the corresponding audit event. The specific implementation process of this step will be described in detail later.

[0030] Specifically, by deploying an adversarial tester on the edge of the audit microservice framework, periodic adversarial tests are performed on the audit microservice framework, generating operational evaluation indicators that include black-box performance and white-box activation mode analysis, and performing local optimization and architecture reconstruction on the audit microservice framework.

[0031] In this embodiment, the adversarial tester is an independent testing component deployed outside the auditing microservice framework, automatically generating various abnormal test cases to periodically conduct stress and security tests. Black-box behavior involves not examining the program's internal code, but relying solely on external performance metrics such as service response speed and success rate obtained from external input / output statistics. White-box activation mode involves reading the program's internal code execution logs to observe whether the actual execution paths of code branches and verification nodes are misled by abnormal data regarding the internal program's running state.

[0032] Specifically, the architecture description and audit criteria corresponding to the audit microservice framework are extracted first, and the adversarial tester deployed on the framework edge is initialized. Then, based on the initialized adversarial tester, test inputs are periodically sent to the audit microservice framework. Based on the framework's operational feedback data, the operational evaluation indicators corresponding to various audit microservices are calculated. The specific implementation process of this step will be described in detail later.

[0033] Next, the operational evaluation metrics are compared horizontally with the security thresholds of the microservice architecture. When all operational evaluation metrics are consistently within the security threshold range, it is determined that the audit microservice framework is adapted to business needs and local optimization instructions are output. If the metrics cannot be consistently met, an architecture decay analysis based on the code attribute graph is initiated, and architecture refactoring instructions including audit service merging, splitting, adding, and adjusting types are output. The specific implementation process of this step will also be described in detail later.

[0034] Furthermore, the method provided in this application embodiment includes:

[0035] The source code of the audit system is obtained and parsed into a code attribute graph with a single computable graph structure. Community detection analysis is performed on the code attribute graph, and disjoint code clusters are determined using a first high internal cohesion threshold and a second low external coupling threshold. These disjoint code clusters serve as candidate boundaries for microservice decomposition. Based on a business document corpus, similarity matching and topic modeling are performed between the disjoint code clusters and business function topics to obtain audit microservice unit clusters. Based on the coupling of microservice business functions, gateway routing for information communication is established for the audit microservice unit clusters to determine the audit microservice framework.

[0036] Specifically, the first step is to obtain all source code files of the audit system, perform lexical analysis and syntax parsing on the source code, and construct a code attribute graph with a single computable graph structure. The specific composition and construction process of the code attribute graph will be described in detail in the subsequent implementation examples.

[0037] Next, the Louvain community detection algorithm is used to perform community detection analysis on the node set of the code attribute graph. Specifically: in the initialization phase of the algorithm, each code node is treated as an independent community. In each iteration, a single node is moved into an adjacent community in turn, and the modularity gain before and after the move is calculated. When the modularity gain is positive, the node is moved in. This process is repeated for all nodes to complete one iteration. The formula for calculating the modularity Q is:

[0038] ,in, This represents the weight of the actual connection edge between node i and node j. This represents the sum of the weights of all edges connected to node i. Let represent the sum of the weights of all edges connected to node j, and m represent the total weight of all connecting edges in the graph structure. This indicates the community to which node i belongs. Indicates the community to which node j belongs, when = hour The value is 1 if the value is positive and 0 otherwise. The modularity Q ranges from -1 to 1, with a larger value indicating higher quality community partitioning. During iteration, the modularity difference ΔQ before and after moving node i into adjacent community C is calculated. If ΔQ is positive, the move-in operation is performed. The iteration process is repeated until the global modularity difference between two consecutive iterations is less than 0.001 or the number of iterations reaches 20. The iteration process is then terminated, yielding the initial candidate community set.

[0039] Next, a dual-threshold check is performed on the initial candidate community set. The first threshold is the high internal cohesion threshold, which measures the degree of correlation between code nodes within a community. The formula for calculating the internal cohesion (C) of community C is as follows:

[0040] Where Einternal represents the number of internal connection edges within community C. This indicates the number of code nodes contained within community C. This represents the theoretical maximum number of pairs of edges connecting all nodes within community C. The cohesion (Cohesion(C)) ranges from [0,1]. A value of 1 indicates that every pair of nodes within the community is connected, while a value of 0 indicates that no two nodes within the community are connected. The default value for this threshold is 0.7. Alternatively, it can be dynamically determined by calculating the average cohesion of all candidate subgraphs in the entire graph and using 1.2 times the average cohesion as the criterion. The dynamically calculated result is preferred over the dynamically calculated result. If no full-graph statistical data is available, the default value is used. When the cohesion of a candidate community is greater than or equal to this threshold, it is considered to meet the high internal cohesion requirement.

[0041] The second threshold is the low external coupling threshold, used to measure the degree of connection between the community and other external modules. The formula for calculating the external coupling degree Coupling(C) of community C is:

[0042] Here, `Eexternal` represents the number of edges connecting code nodes in community C to code nodes outside the community, `Einternal` represents the number of edges connecting within community C, and `Einternal + Eexternal` represents the sum of the degrees of all code nodes within community C. The coupling degree `Coupling(C)` ranges from [0,1]. A value of 0 indicates that the community is completely unrelated to external modules, while a value of 1 indicates that all nodes within the community are only connected to external nodes. The default threshold is 0.3, but it can also be dynamically determined by taking 0.8 times the average coupling degree of all candidate subgraphs in the entire graph, with the priority consistent with the cohesion threshold. When the external coupling degree of a candidate community is less than or equal to this threshold, it is considered to meet the low external coupling requirement.

[0043] For candidate communities that simultaneously meet both threshold requirements, they are directly marked as valid disjoint code clusters. For candidate communities that do not meet the thresholds, if the cohesion is insufficient, the community is split into two sub-communities along the position with the lowest density of internal connection edges; if the coupling is too high, the community is merged with the adjacent community with the most external connection edges. After splitting or merging, only the clusters involved in the adjustment are re-verified for the two thresholds, without restarting the global community detection iteration. If a single cluster still fails to meet the two threshold requirements after three consecutive adjustments, the granularity adjustment is re-executed based on the partitioning result of the previous iteration of community detection until all candidate clusters meet the two threshold requirements, ultimately resulting in disjoint code clusters, which serve as candidate boundaries for microservice splitting, with no overlapping code nodes between different candidate boundaries.

[0044] Next, a business document corpus is constructed, containing various business and technical text materials such as audit system requirement design documents, user operation guides, functional comments in code files, and project description documents. All text in this corpus undergoes Chinese word segmentation, stop word filtering, and stemming. A bag-of-words model is used to construct text feature vectors. A latent Dirichlet Allocation (LDA) model is then used to model the business corpus, with the number of topics matching the number of pre-defined audit business modules. The model training iterations are set to 1000, and a convergence criterion is a decrease in perplexity of less than 1e-5. During training, the document-topic prior distribution hyperparameter α of the LDA model is set to 50 / number of topics, and the topic-word prior distribution hyperparameter β is set to 0.1. After training, topic feature vectors corresponding to different audit business functions, such as audit plan management, audit implementation management, and audit result management, are extracted. Simultaneously, the same text preprocessing and vectorization processing are performed on the code comments, function names, and module description texts corresponding to each disjoint code cluster. The cosine similarity between the text vector of each code cluster and the vectors of each business function theme is calculated, with a minimum similarity threshold of 0.5. Each code cluster is matched to the business function theme with the highest similarity that is above the minimum threshold. If the similarity between a code cluster and all business themes is below the minimum threshold, the cluster is classified as a general support service unit. After completing the matching of all clusters, audit microservice unit clusters corresponding to different audit business functions are obtained.

[0045] Finally, the number of interface calls and data interaction frequencies between the audit microservice unit clusters were statistically analyzed to clarify the business coupling relationships between microservices. Coupling levels were categorized into high, medium, and low based on interaction frequency, as shown in Table 1. Corresponding routing rules were configured at the service gateway layer, assigning a unique service identifier and access path to each audit microservice unit. For microservices with high coupling levels, a proximity forwarding and local caching strategy was configured, prioritizing routing requests to target service instances within the same host or availability zone, and caching frequently accessed response data locally on the service gateway to reduce cross-service call latency. For microservices with medium and low coupling levels, a unified authentication and traffic control strategy was configured, requiring all requests to undergo unified authentication of identity tokens and operation permissions through the service gateway, and limiting the number of requests processed by each microservice per unit time using a token bucket algorithm to prevent service overload. A unified request entry point and authentication verification logic were established, completing the gateway routing for information communication and ultimately forming a complete audit microservice framework.

[0046] Table 1: Standard for Classifying Coupling Levels of Audit Microservice Unit Clusters

[0047] High Coupling Level The daily average interaction frequency between microservice unit clusters, calculated on a calendar day basis, meets the criteria for high coupling. 20 times or more Medium Coupling Level The average daily interaction frequency between microservice unit clusters, calculated on a calendar day basis, meets the criteria for moderate coupling. 5 times or more and less than 20 times Low Coupling Level The average daily interaction frequency between microservice unit clusters, calculated on a calendar day basis, meets the criteria for low coupling. Less than 5 times

[0048] By combining code attribute graph community detection with business theme matching, microservice boundaries are automatically defined and a unified communication gateway is built. This achieves the effects of quantitatively splitting audit business microservices, reducing inter-service coupling, and improving the matching degree between microservice architecture and audit business scenarios.

[0049] Furthermore, the method provided in this application embodiment includes:

[0050] The single computable graph structure includes an abstract syntax tree, a control flow graph, a program dependency graph, and a temporal code evolution layer; wherein, the abstract syntax tree encodes the nesting structure and statement relationships of the code, the control flow graph depicts the execution order of statements and conditional jump logic, the program dependency graph shows data dependency and control dependency relationships, and the temporal code evolution layer analyzes the symbiotic relationships of code parts.

[0051] Optionally, a single computable graph structure is formed by merging four layers: an abstract syntax tree, a control flow graph, a program dependency graph, and a time-code evolution layer. Before merging, the source code is first divided into basic blocks based on functions. The function entry statement serves as the starting point of the first basic block. Each time a conditional statement, loop statement, unconditional jump statement, or function return statement is encountered, that statement becomes the termination point of the current basic block, and the next executable statement becomes the starting point of the next basic block. Exception handling and exception catching code blocks are divided into independent basic blocks, and the function exit return statement serves as the termination point of the last basic block of that function. Each basic block is assigned a unique node identifier consisting of a file path, function name, and block number. All four layers are constructed based on the unified basic block node identifier, and are ultimately merged into the same set of computable graph data.

[0052] When constructing the abstract syntax tree, those skilled in the art use open-source parsing tools for the corresponding programming language to perform lexical analysis and syntax parsing line by line on the source code files of the auditing system. For mainstream compiled languages, corresponding parsing components are adapted; for mainstream scripting languages, corresponding general parsing components are adapted. This identifies syntactic units such as keywords, identifiers, functions, classes, and statement blocks in the code, and constructs a tree structure according to the nesting level and statement hierarchy. All syntactic units within each basic block are mapped to the corresponding basic block node as child attribute nodes. Nodes are connected by parent-child edges, encoding the nesting structure and statement relationships of the code, thus completely reconstructing the syntactic hierarchy logic of the source code.

[0053] When constructing the control flow graph, based on the divided basic blocks, the execution order of the basic blocks in each function is sorted out through static program analysis, the branch basic blocks corresponding to conditional statements, loop statements, and jump statements are identified, and the nodes of each basic block are connected according to the direction of program execution to form a directed graph structure, which depicts the execution order of statements and the conditional jump logic, and fully covers all possible program execution paths.

[0054] When constructing a program dependency graph, data flow analysis and control dependency analysis are performed based on the control flow graph. Data flow analysis tracks the basic blocks where the definition and usage points of variables are located, and establishes data dependency edges to connect the corresponding basic block nodes. Control dependency analysis identifies the execution constraints of the basic block containing the judgment condition on the subsequent statement basic blocks, and establishes control dependency edges to connect the corresponding basic block nodes. The final program dependency graph can fully display the data dependency and control dependency relationships in the code.

[0055] When constructing the time-based code evolution layer, historical commit records are extracted from the code version control system. The frequency of common modifications across different code files in each version update is calculated, and the symbiotic relationships between code modules are analyzed. The frequency of common modifications is then... Transformed into the co-occurrence weights between basic block node i and basic block node j The specific conversion method is as follows: count the total number of all historical submissions within a preset time window. Count the number of times code file i and code file j are modified together in the same commit record. Calculate co-occurrence frequency After min-max normalization, the weights are mapped to the [0,1] interval and used as the co-occurrence weights between basic block node i and basic block node j. The calculation formula is: ,in, This represents the minimum co-occurrence frequency among all code file pairs within the entire graph. This represents the maximum co-occurrence frequency among all code file pairs across the entire graph. Each code file is mapped to all its constituent basic block nodes, with the co-occurrence weights assigned accordingly. Add them as edge attributes to the corresponding connecting edges of the graph structure to form a time-dimensional code evolution association layer.

[0056] Finally, the nodes and edges of the four-layer structure are fused and mapped based on a unified basic block node identifier. Edges at different levels are labeled with their corresponding structure types, and the attribute data of all edges are uniformly stored in the attribute set of the corresponding connected edges, ultimately forming a code attribute graph with a single computable graph structure.

[0057] By constructing a unified code attribute graph by unifying the granularity of basic block nodes and integrating four layers of information—syntactic structure, control logic, dependency relationships, and evolution history—it achieves the effect of comprehensively and multidimensionally characterizing code features and providing a complete quantitative analysis foundation for subsequent automatic microservice decomposition.

[0058] Furthermore, the method provided in this application embodiment includes:

[0059] Based on the audit results, a complete audit chain is integrated and transmitted to the audit archive in chronological order in the form of an immutable event stream. If the audit results trigger an anomaly or dispute, the corresponding audit event is read from the audit archive and the cause is inferred and woven into a structured attribution chain. The structured attribution chain is then sent back to the audit archive and associated with the corresponding audit event.

[0060] In this embodiment, the audit archive is a distributed time-series event storage system for audit business scenarios. It adopts an append-only storage mechanism and does not support modification or deletion of written data. It is used to uniformly store operation records, business data, processing results and evidence files generated throughout the audit process. It has the ability to perform time-series retrieval, data integrity verification and compliance evidence storage, and can meet the storage needs of audit business tracing and compliance evidence collection.

[0061] Specifically, after obtaining the generated audit results in the aforementioned steps, all operation records of this audit task, from data upload, data preprocessing, and calls to various audit business microservice units to result generation, are extracted. Each operation record includes a unique event identifier, a timestamp, operation subject information, operation content description, input data summary, and output data summary. All records are sorted in ascending order according to the chronological order of the operations, forming a complete audit chain covering the entire audit process. A message queue sequential message transmission mechanism is used to encapsulate each event in the complete audit chain into an independent event message in chronological order, transmitting them one by one to the audit archive in the form of an immutable event stream. The audit archive persistently stores the event messages in the order they are received using an append-only method. After writing, a secure hash algorithm (256) is used to generate a corresponding data verification digest for each event, ensuring the integrity and immutability of the stored data.

[0062] Next, the system monitors the status field of the audit results stored in the audit archive in real time. Different judgment logics are used for anomaly triggers and dispute triggers. Anomaly triggers employ an automatic judgment mechanism with preset rules for anomaly judgment of audit results. These rules include three judgment dimensions: a threshold for the number of significant risk points, a data integrity rate threshold, and a service call success rate threshold. For example, the default threshold for the number of significant risk points is set to 5, the default threshold for data integrity rate is set to 95%, and the default threshold for service call success rate is set to 98%. All three thresholds can be customized according to the type of audit project and business control requirements. When the number of significant risk points in the audit results exceeds the preset threshold, or the proportion of valid data in the audit chain is lower than the preset data integrity rate threshold, or the proportion of successful microservice unit calls in the audit chain to the total number of calls is lower than the preset service call success rate threshold, the system automatically marks the audit result as an anomaly, determining it as an triggered anomaly scenario. Dispute triggers employ a business application trigger mechanism. During the audit result disclosure period, the audited entity or audit reviewer can submit a dispute application through the system front end. The application must include a description of the disputed matter and upload supporting materials. After receiving the application, the system performs material format verification and application information integrity verification. If the verification is successful, the corresponding audit result is automatically marked as a disputed state, which is determined to trigger a dispute scenario.

[0063] Once an audit result is determined to trigger an anomaly or dispute, the system retrieves all related audit events within the corresponding time frame from the audit archive based on the unique task identifier of that audit result, and retrieves the complete audit chain event set in ascending chronological order. Normal processing benchmark parameters are generated statistically based on the corresponding event output data of similar audit projects completed normally within the past three months. The numerical distribution of each output indicator is extracted, and the normal benchmark range is defined as the indicator mean ± 2 standard deviations. The benchmark parameters are automatically updated monthly with new normal audit project data. A rule-based reverse tracing method is used for inference and attribution. Starting with the result event corresponding to the anomaly or dispute, the system traverses each preceding event in reverse along the audit chain, comparing the output data summary of each event with the preset normal processing benchmark parameters item by item to identify event nodes where the output data deviates from the benchmark range. The deviation type of each deviation node is then determined: if the input data does not conform to the preset format specifications, it is determined to be a data input anomaly; if the service processing logic output result does not conform to the preset rules, it is determined to be a service processing anomaly; and if the runtime configuration parameters do not match the business requirements, it is determined to be a parameter configuration anomaly.

[0064] Once the root cause event node is located, all transmission events from the root cause event to the resulting event are traced and arranged in causal transmission order to form a structured attribution chain. The structured attribution chain consists of three layers: the root cause layer, the transmission layer, and the result layer. The root cause layer includes a unique identifier for the root cause event, the anomaly type determination result, the event occurrence time, and a detailed description of the root cause. The transmission layer includes a sequence of transmission events arranged in causal order, the deviation performance of each transmission event, and a description of the transmission relationship between preceding and following events. The result layer includes a unique identifier for the final result event, a detailed description of the abnormal result, and a description of the scope of business impact.

[0065] Finally, a unique attribution chain identifier is assigned to the generated structured attribution chain, and the complete structured attribution chain data is uploaded back to the audit archive for persistent storage. In the audit archive, an attribution chain identifier-related attribute field is added to all original audit events associated with this process. Simultaneously, a unique event identifier for the corresponding original audit event is stored in each event node of the structured attribution chain, achieving a bidirectional association between the structured attribution chain and the original audit events. Subsequent retrieval of original audit events allows direct viewing of the corresponding attribution analysis results, and retrieval of the structured attribution chain allows for retrospective viewing of the complete information of the original events.

[0066] By storing audit data in an immutable event stream time sequence, and combining an automatic and manual dual-trigger anomaly and dispute determination mechanism with a reverse rule tracing method to generate a structured attribution chain and store it in a bidirectional association, the audit achieves the effects of ensuring that audit data is tamper-proof, improving the efficiency of tracing audit anomalies and disputes, and supporting audit compliance evidence collection.

[0067] Furthermore, the method provided in this application embodiment includes:

[0068] The architecture description and audit criteria of the audit microservice framework are determined, and the adversarial tester deployed on the edge of the framework is initialized. Based on the initialized adversarial tester, periodic test inputs are performed on the audit microservice framework to determine the operational evaluation indicators of the audit microservice.

[0069] Specifically, the process begins by obtaining the architecture description file for the audit microservice framework. This file contains complete architectural information, including the microservice node topology, a list of external service interfaces, gateway routing rules, service authentication mechanism specifications, and data interaction protocol specifications. Simultaneously, the audit guidelines file corresponding to the audit business is obtained. This file includes business and security control requirements such as audit data compliance verification rules, audit business process compliance requirements, audit result judgment standards, and data security control specifications. The architecture description file and audit guidelines file are then synchronized to an adversarial tester deployed on the edge of the audit microservice framework. This adversarial tester is deployed as an independent container instance on the edge node of the container cluster containing the audit microservice framework, using a bypass deployment method, independent of the normal business service chain. The adversarial tester establishes a communication connection with the unified service gateway of the audit microservice framework through a dedicated test interface. The interface uses a common descriptive state transmission communication protocol, and all test requests carry a unique test traffic identifier. The unified service gateway routes test traffic to an independent test runtime environment based on the identifier, physically isolated from the normal business runtime environment. Test data is only written to a dedicated test storage area and does not contaminate formal business data.

[0070] The adversarial tester's initialization process begins by parsing the architecture description file to identify all testable service interfaces and access paths, generating a list of testable interfaces. Next, it parses the audit criteria file, extracting compliance judgment rules and security control requirements, and converting them into a test judgment benchmark rule base. Finally, it configures the test execution parameters. For example, the default test execution cycle is set to 7 days, the maximum duration of a single test round is 2 hours, and the concurrent number of test requests is 10. The test execution cycle can be manually adjusted to 3 days, 14 days, or 30 days according to the business iteration rhythm. It also supports administrators manually triggering immediate test tasks through the system management terminal. Manually triggered test tasks have higher priority than periodic tests and do not affect the original cycle's timing logic upon completion. After all initialization configurations are completed, the adversarial tester enters a standby state.

[0071] After initialization, the adversarial tester automatically starts test tasks according to a preset cycle, sends test input data to the unified service gateway of the audit microservice framework according to preset test request generation rules, and synchronously collects the framework's response data and runtime status data, providing basic data support for the calculation of runtime evaluation indicators. The specific calculation and determination process of runtime evaluation indicators will be described in detail in the corresponding implementation examples later.

[0072] By parsing the architecture description and audit criteria, the parameterization initialization of the side-side adversarial tester is completed. Combined with physically isolated test links and an adjustable periodic mechanism, periodic test inputs are executed, achieving the effect of automating microservice architecture stability testing, not interfering with normal audit business operations, and adapting to different business iteration rhythms.

[0073] Furthermore, the method provided in this application embodiment includes:

[0074] Based on the adversarial tester, an adversarial testing strategy is automatically generated, which includes constructing fuzzy boundary data, logical traps, and hint injection attacks. Based on the adversarial testing strategy, periodic tests are performed on the audit microservice framework to determine operational evaluation indicators.

[0075] Specifically, the adversarial tester has a built-in test case generation engine that automatically generates adversarial test strategies based on the architecture information and audit criteria imported during the initialization phase, according to the rule mapping relationship. For data format compliance rules in the audit criteria, it generates corresponding fuzzy boundary data test cases; for business process compliance rules, it generates corresponding logic trap test cases; and for data content security rules, it generates corresponding hint injection attack test cases. Each audit criterion corresponds to at least one set of test cases, and the criteria for judging the test cases are completely consistent with the requirements of the corresponding audit criterion. The test strategy includes three sets of test cases, as detailed below:

[0076] The first category is fuzzy boundary data test cases. This category uses boundary value analysis to construct test data, extracting the value range, length limits, and format requirements of each field in normal audit business data. It then constructs upper and lower limit threshold values, excessively long characters, combinations of special symbols, null values, and partially valid format data to form a fuzzy boundary test dataset. This dataset is used to test the microservice's ability to handle boundary anomalies. The second category is logic trap test cases. This category uses a process branch traversal method to construct test sequences. It analyzes all conditional branch nodes in the audit business service chain and constructs request sequences that meet pre-verification conditions but trigger abnormal branches, including duplicate requests. Test cases include cross-request, reverse-flow request, and cross-permission simulated request, used to test the robustness of microservice business logic; the third type is the hint injection attack test case, which uses a text embedding method to construct test documents, inserting misleading instructions into the beginning, middle and end paragraphs of the document as invisible characters or in a manner consistent with normal text format. Each test document embeds no more than 5 instructions, and the number of embeddings is determined according to the average text length of normal audit documents at a ratio of 1 instruction per 100 characters. At the same time, special trigger characters are embedded to form an injection test document, used to test the anti-interference capability of the unstructured data parsing module.

[0077] After the test strategy is generated, the adversarial tester starts test tasks according to a preset execution cycle, sending three types of test cases to the audit microservice framework in a fixed order. Each round of testing first executes fuzzy boundary data testing, then logic trap testing, and finally, hint injection attack testing. After each type of test case is executed, the corresponding response results and runtime logs are temporarily stored. Built-in exception handling logic is implemented during test execution. The timeout for a single test request is set to 30 seconds. After the timeout, it automatically retryes twice. If the retry still fails, the test case is marked as failed and the reason for failure is recorded, and subsequent test cases continue to be executed. If the failure rate of a certain type of test case exceeds 50%, that type of test is terminated and a test exception report is generated, without affecting the normal execution of other types of tests. After all test cases are executed, the adversarial tester summarizes all test process data and determines the corresponding operational evaluation indicators based on preset indicator calculation rules. The operational evaluation indicators cover two dimensions: external service performance and internal operational status.

[0078] By automatically generating three types of adversarial test cases through the rule-based mapping between audit criteria and test cases, and combining them with the full-process exception tolerance mechanism to execute tests periodically, the system achieves the effect of multi-dimensional verification of the robustness of the audit microservice framework, comprehensive coverage of data and logic-level risk points, and stable and controllable testing process.

[0079] Furthermore, the method provided in this application embodiment includes:

[0080] The operational evaluation metrics include microservice performance from a black-box perspective and whether the internal activation mode is manipulated deceptively from a white-box perspective.

[0081] In one embodiment, the performance evaluation metrics include two parts: microservice performance metrics from a black-box perspective and internal activation mode determination results from a white-box perspective. These two types of metrics quantify the test results from the perspectives of external service effectiveness and internal operational logic, respectively. The microservice performance metrics from a black-box perspective are calculated using conventional data statistical methods based on test input and output results. Specifically, these metrics include five core indicators: test request response success rate, average response time, percentage of abnormal errors, accuracy of audit result compliance determination, and accuracy of data verification interception. An example of the weight allocation for these five core indicators is as follows: test request response success rate 25%, average response time 20%, percentage of abnormal errors 20%, accuracy of audit result compliance determination 20%, and accuracy of data verification interception 15%. Each indicator is quantified and scored on a percentage basis, then multiplied by its corresponding weight and summed to obtain the overall performance score from a black-box perspective, directly reflecting the stability and accuracy of the microservice's external services.

[0082] Internal activation mode determination from a white-box perspective is achieved by collecting execution logs from key logic nodes within the microservice. Logs are pre-collected at core branch nodes, verification nodes, and computation nodes in each audited microservice unit. Internal nodes are pre-classified into core and non-core nodes. Core nodes include authentication nodes, core verification nodes, and result output nodes; all other nodes are classified as non-core. By comparing the standard execution path under normal business input with the actual execution path under adversarial testing input, if any core node exhibits unexpected branch jumps, bypassed verification logic, or computation results deviating from the baseline range, the internal activation mode is directly determined to have been manipulated deceptively.

[0083] Furthermore, the following method is used to determine whether the calculation results deviate from the baseline range: For each data entry node, the baseline range is the mean ± 3 standard deviation of the node's output values ​​in historical operations under normal audit data input. When the actual output value of the node under adversarial test input exceeds this baseline range, the calculation result is considered to have deviated from the baseline range. When deviations occur in non-core nodes, if the number of deviation nodes accounts for 30% or more of the total number of non-core nodes, the internal activation mode is considered to have been manipulated fraudulently. If the execution path is consistent with the baseline path and the output results meet the rule judgment, it is considered that no fraudulent manipulation has occurred. Finally, the judgment result of whether fraudulent manipulation exists is output, and the number of affected nodes and the scope of impact are statistically analyzed to form an evaluation conclusion from a white-box perspective.

[0084] By constructing operational evaluation indicators from two dimensions—the external performance of the black box with clearly defined weights and the internal logic of the white box with tiered judgments—it achieves the effect of comprehensively and accurately measuring the anti-interference capability of audit microservices, accurately identifying potential architectural risks, and having clear and implementable judgment standards.

[0085] Furthermore, the method provided in this application embodiment includes:

[0086] By comparing operational evaluation metrics with the security thresholds of the microservice architecture, if all operational evaluation metrics remain within the security thresholds, it is determined that the audit microservice framework can meet business needs, and local optimization instructions are generated; if it does not meet business needs, an architecture decay analysis based on code property graphs is triggered, generating architecture refactoring instructions. The architecture refactoring methods include merging, splitting, adding, or adjusting audit services.

[0087] Optionally, first obtain the operational evaluation metrics output from the aforementioned periodic adversarial tests, and simultaneously retrieve the preset microservice architecture security threshold system. The microservice architecture security thresholds include three core performance thresholds: average service response latency threshold, single-node service throughput threshold, and service request error rate threshold; and two business security thresholds: audit result judgment accuracy threshold and data verification interception rate threshold. For example, the average service response latency threshold is set to 500 milliseconds by default, the single-node service throughput threshold is set to 100 requests per second by default, the service request error rate threshold is set to 2% by default, the audit result judgment accuracy threshold is set to 95% by default, and the data verification interception rate threshold is set to 90% by default. All thresholds can be customized according to the audit workload and control requirements.

[0088] Next, the operational evaluation metrics obtained from each round of testing are compared horizontally with the corresponding security thresholds, and the number of metrics within the security threshold range is counted. When all operational evaluation metrics from three consecutive rounds of periodic testing are within the corresponding security threshold range, it is determined that the overall operational status of the audit microservice framework can meet the current business needs, and no adjustment to the overall architecture is required, thus generating local optimization instructions. Local optimization instructions are generated differently based on the proximity of the metric to the threshold. If the average service response time exceeds 80% of the corresponding threshold limit for two consecutive test cycles and the throughput exceeds 70% of the corresponding threshold limit for two consecutive test cycles, a service instance expansion instruction is generated to increase the number of deployment instances of the corresponding high-load audit microservice unit and distribute the business request pressure. If the service request error rate fluctuates slightly due to sudden traffic, and the error rate fluctuates between 60% and 90% of the corresponding threshold limit with a fluctuation range not exceeding 30%, a rate limiting parameter adjustment instruction is generated to increase the traffic rate limiting threshold of the corresponding microservice unit and optimize the request acceptance capacity under sudden traffic. If the business security metric is below 90% of the corresponding threshold limit for two consecutive test cycles, a verification rule optimization instruction is generated to supplement the boundary judgment logic of the corresponding verification rule and improve the stability of data interception and result judgment. After the local optimization command is executed, the adversarial tester immediately triggers a round of supplementary testing, re-collects the running evaluation indicators and compares them with the security threshold. If the indicators fall back to the security threshold range, the optimization is deemed effective and the current optimization configuration is retained. If the indicators still do not meet the standards, the evaluation is upgraded to not meet business requirements, triggering the architecture decay analysis process to form a closed-loop verification of the optimization effect.

[0089] If two or more operational evaluation metrics exceed the corresponding security threshold in any round of testing, or if a single metric exceeds the threshold for two consecutive rounds of testing, the audit microservice framework is deemed unable to meet current business needs, triggering an architecture decay analysis process based on code attribute graphs. Architecture decay analysis is conducted based on the basic block node data of the code attribute graph. First, the total number of connection edges within each audit microservice unit cluster is counted, and the code cohesion value within the cluster is calculated. Simultaneously, the total number of connection edges across audit microservice unit clusters is counted, and the code coupling value between clusters is calculated. The calculation results are compared with the baseline values ​​at the initial architecture split. A decrease in cohesion exceeding 10% or an increase in coupling exceeding 15% is considered a deviation in cohesion and coupling characteristics. Second, the number of business function topics corresponding to each audit microservice unit cluster is counted. If the number exceeds the initially set number of topics by two or more, it is considered a deviation in responsibility boundaries. Finally, the total number of external interfaces for each audit microservice unit is counted. If the number increases by more than 30% compared to the initial version and there are functionally overlapping interfaces, it is considered interface bloat. By comprehensively analyzing three dimensions, core architectural issues are identified, and architectural refactoring instructions are generated. The refactoring methods include four categories: merging audit services, splitting audit services, adding audit services, and adjusting audit services. The specific generation and execution process of the refactoring plan will be described in detail in the subsequent examples.

[0090] By comparing multi-dimensional security thresholds and multi-round test results, the architecture adaptability is determined. Combined with local optimization instructions for closed-loop effect verification and multi-dimensional corruption analysis of code attribute graphs, architecture refactoring instructions are generated. This achieves the effect of accurately matching the architecture's operating status, selecting optimization and adjustment methods as needed, and ensuring that the audit microservice framework continuously adapts to business needs.

[0091] Furthermore, the method provided in this application embodiment includes:

[0092] If it is the architecture refactoring instruction, identify the type and severity of architecture corruption, and retrieve similar historical cases from the knowledge base; based on the similar historical cases, guide the generation of a refactoring plan, wherein the refactoring plan includes a microservice refactoring plan and a gateway routing adjustment plan; adjust the audit microservice framework according to the refactoring plan.

[0093] In one embodiment, upon receiving an architecture refactoring instruction, the corresponding architecture corruption type and severity level are identified based on the output of the architecture corruption analysis. Architecture corruption types include four categories: overlapping service responsibilities corruption, service monolithic expansion corruption, excessively long call chains corruption, and redundant interface logic corruption. Severity is divided into three levels: mild, moderate, and severe, determined comprehensively based on the extent to which indicators exceed thresholds, the number of affected microservice units, and the scope of business impact. Specific judgment rules are shown in Table 2. The highest severity level among the three dimensions is used as the final judgment result; for example, if one dimension reaches severe while the other dimensions are mild, the overall judgment is severe.

[0094] Table 2: Criteria for Classifying the Severity of Corruption in Audited Microservice Framework Architectures

[0095] Mild Within 10% 1 Limited to a single audit type moderate Between 10% and 30% 2 to 3 Covering multiple audit types Severe More than 30% 4 or more Covering all audit types

[0096] Subsequently, the identified corruption type, severity, audit business scenario, and number of affected microservice units are used as search features to retrieve similar historical cases from the historical refactoring knowledge base. This knowledge base stores the problem characteristics, refactoring solutions, and implementation results of all past architecture refactoring projects. The search employs a combination of keyword matching and feature similarity calculation. First, corruption type and business scenario keywords are matched to filter out candidate cases of the same type. Then, a cosine similarity calculation method is used to convert the four types of search features into standardized numerical feature vectors. The cosine similarity between the current case and each candidate case is calculated; a higher similarity value indicates a higher match. The top three historical cases with the highest similarity are selected as similar reference cases.

[0097] Next, based on the refactoring schemes and implementation effects of similar historical cases obtained from the retrieval, and combined with the code attribute graph analysis results of the current audit microservice framework, a complete refactoring plan is generated to guide the process. Specifically, the refactoring plan includes two parts: a microservice refactoring plan and a gateway routing adjustment plan. The microservice refactoring plan makes corresponding adjustments for different types of corruption. If the corruption is due to overlapping service responsibilities, a service merging plan is generated to merge two fine-grained audit service units with highly overlapping responsibilities into one independent service unit, eliminating duplicate business logic. If the corruption is due to service monolithic expansion, a service splitting plan is generated to split the expanded audit service unit into multiple independent service units according to business subdomains, with the splitting boundaries consistent with the cohesion boundaries in the code attribute graph. If the corruption is due to excessively long call chains, a service addition plan is generated to add independent business aggregation service units, consolidate cross-service call logic, and shorten the core business chain. If the corruption is due to redundant interface logic, a service adjustment plan is generated to clean up redundant interface logic, merge interfaces with similar functions, and optimize interface call efficiency. The gateway routing adjustment plan adjusts the routing and forwarding rules of the unified service gateway according to the service node topology after the microservice reconstruction, updates the access path mapping relationship of the service nodes, and synchronously adjusts the traffic control policies and authentication configurations of each service to ensure the accuracy of routing distribution after reconstruction.

[0098] Once the refactoring plan is generated, it is automatically pushed to the architecture management review module. Architecture administrators manually review the plan's rationality, business impact, and implementation risks. Refactoring plans that pass the review proceed to the implementation phase; those that fail are returned to the refactoring plan generation stage, where the refactoring scheme is adjusted based on the review comments before a new plan is generated. Refactoring plans that pass the review are first tested in the test environment, where framework adjustments are performed. Service units are merged, split, added, or adjusted according to the microservice refactoring plan, and the routing configuration and traffic policies of the unified service gateway are updated according to the gateway routing adjustment plan.

[0099] After the adjustments are completed, a full regression test will be performed. The test will pass if three conditions are met simultaneously: First, the pass rate of test cases for all core audit business functions must reach 100%, and the pass rate of test cases for non-core functions must reach over 98%; second, the three core performance indicators—average service response latency, single-node service throughput, and service request error rate—must all meet the security threshold requirements; third, the two business security indicators—audit result judgment accuracy and data verification interception rate—must both meet the security threshold standards. If all three conditions are met, the test is considered passed, and the restructured and adjusted architecture will be officially deployed to the production environment, completing the overall architecture refactoring of the audit microservice framework.

[0100] By using cosine similarity to retrieve similar historical cases to guide the generation of reconstruction plans, and combining manual review mechanisms with standardized regression testing to determine the completion of framework adjustments, the goal of improving the rationality of the architecture reconstruction plan, reducing the risk of reconstruction implementation, and ensuring that the reconstructed framework adapts to business needs has been achieved.

[0101] In summary, the intelligent auditing full-process information communication management method provided in this application has the following technical effects:

[0102] This application obtains audit results by performing full-link automatic audit processing on the data to be audited through an audit microservice framework. The audit link data is stored in an immutable event stream time sequence. Combined with periodic adversarial testing and architectural corruption analysis, the framework is partially optimized or restructured, thereby improving audit efficiency and traceability. This makes the entire audit process more stable, accurate, compliant and reliable, achieving the technical effect of reasonable architectural division and continuous self-optimization of the audit system, ensuring reliable execution and long-term stable evolution of the entire audit process.

[0103] Example 2, as Figure 2 As shown, based on the same inventive concept as in Embodiment 1 above, this application provides a smart audit end-to-end information communication management system, the system comprising:

[0104] Audit microservice framework construction module 1, based on the source code of the audit system, performs business function theme modeling based on multi-dimensional analysis of code attribute graph, obtains microservice unit cluster and establishes gateway routing, and determines the audit microservice framework.

[0105] Audit result acquisition module 2 is used to upload the data to be audited, and to perform automatic audit processing under the framework service link according to the audit microservice framework to obtain the audit result.

[0106] Audit result storage module 3 is used to store the audit results in the form of an immutable event stream, wherein if an anomaly is triggered, a structured attribution chain is inferred and associated.

[0107] The operation evaluation index acquisition module 4 includes deploying an adversarial tester on the side of the audit microservice framework to perform periodic adversarial tests on the audit microservice framework, generating operation evaluation indexes that include black-box performance and white-box activation mode analysis, and performing local optimization and architecture reconstruction on the audit microservice framework.

[0108] Furthermore, the audit microservice framework construction module 1 is used to perform the following steps:

[0109] The source code of the audit system is obtained and parsed into a code attribute graph with a single computable graph structure. Community detection analysis is performed on the code attribute graph, and disjoint code clusters are determined using a first high internal cohesion threshold and a second low external coupling threshold. These disjoint code clusters serve as candidate boundaries for microservice decomposition. Based on a business document corpus, similarity matching and topic modeling are performed between the disjoint code clusters and business function topics to obtain audit microservice unit clusters. Based on the coupling of microservice business functions, gateway routing for information communication is established for the audit microservice unit clusters to determine the audit microservice framework.

[0110] Furthermore, the audit microservice framework construction module 1 is used to perform the following steps:

[0111] The single computable graph structure includes an abstract syntax tree, a control flow graph, a program dependency graph, and a temporal code evolution layer; wherein, the abstract syntax tree encodes the nesting structure and statement relationships of the code, the control flow graph depicts the execution order of statements and conditional jump logic, the program dependency graph shows data dependency and control dependency relationships, and the temporal code evolution layer analyzes the symbiotic relationships of code parts.

[0112] Furthermore, the operation evaluation index acquisition module 4 is used to perform the following steps:

[0113] The architecture description and audit criteria of the audit microservice framework are determined, and the adversarial tester deployed on the edge of the framework is initialized. Based on the initialized adversarial tester, periodic test inputs are performed on the audit microservice framework to determine the operational evaluation indicators of the audit microservice.

[0114] Furthermore, the operation evaluation index acquisition module 4 is used to perform the following steps:

[0115] Based on the adversarial tester, an adversarial testing strategy is automatically generated, which includes constructing fuzzy boundary data, logical traps, and hint injection attacks. Based on the adversarial testing strategy, periodic tests are performed on the audit microservice framework to determine operational evaluation indicators.

[0116] Furthermore, the operation evaluation index acquisition module 4 is used to perform the following steps:

[0117] The operational evaluation metrics include microservice performance from a black-box perspective and whether the internal activation mode is manipulated deceptively from a white-box perspective.

[0118] Furthermore, the operation evaluation index acquisition module 4 is used to perform the following steps:

[0119] By comparing operational evaluation metrics with the security thresholds of the microservice architecture, if all operational evaluation metrics remain within the security thresholds, it is determined that the audit microservice framework can meet business needs, and local optimization instructions are generated; if it does not meet business needs, an architecture decay analysis based on code property graphs is triggered, generating architecture refactoring instructions. The architecture refactoring methods include merging, splitting, adding, or adjusting audit services.

[0120] Furthermore, the operation evaluation index acquisition module 4 is used to perform the following steps:

[0121] If it is the architecture refactoring instruction, identify the type and severity of architecture corruption, and retrieve similar historical cases from the knowledge base; based on the similar historical cases, guide the generation of a refactoring plan, wherein the refactoring plan includes a microservice refactoring plan and a gateway routing adjustment plan; adjust the audit microservice framework according to the refactoring plan.

[0122] Furthermore, the audit result storage module 3 is used to perform the following steps:

[0123] Based on the audit results, a complete audit chain is integrated and transmitted to the audit archive in chronological order in the form of an immutable event stream. If the audit results trigger an anomaly or dispute, the corresponding audit event is read from the audit archive and the cause is inferred and woven into a structured attribution chain. The structured attribution chain is then sent back to the audit archive and associated with the corresponding audit event.

[0124] The intelligent audit full-process information communication management system provided in the embodiments of the present invention can execute the intelligent audit full-process information communication management method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the execution method.

[0125] Although this application makes various references to certain modules in the system according to the embodiments of this application, any number of different modules can be used and run on user terminals and / or servers. The various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy distinction between each other and are not used to limit the scope of protection of this invention.

[0126] The specific embodiments described above do not constitute a limitation on the scope of protection of this application. Those skilled in the art should understand that various modifications, combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application should be included within the scope of protection of this application. In some cases, the actions or steps described in this application can be performed in a different order than that shown in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require a specific or sequential order to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A method for intelligent auditing full-process information communication management, characterized in that, The method includes: Based on the source code of the audit system, business function theme modeling is performed based on multi-dimensional analysis of code attribute graphs to obtain microservice unit clusters and establish gateway routing, thus determining the audit microservice framework. Upload the data to be audited, and perform automatic auditing processing under the framework service link according to the audit microservice framework to obtain the audit results; The audit results are stored in the form of an immutable event stream, wherein if an anomaly is triggered, a structured attribution chain is inferred and associated. Specifically, by deploying an adversarial tester on the edge of the audit microservice framework, periodic adversarial tests are performed on the audit microservice framework, generating operational evaluation indicators that include black-box performance and white-box activation mode analysis, and performing local optimization and architecture reconstruction on the audit microservice framework.

2. The intelligent auditing full-process information communication management method as described in claim 1, characterized in that, Define the audit microservice framework, including: Obtain the source code of the audit system and parse it into a code attribute graph with a single computable graph structure; Community detection analysis is performed in the code attribute graph. Disjoint code clusters are determined using a first high internal cohesion threshold and a second low external coupling threshold. Disjoint code clusters are candidate boundaries for microservice decomposition. Based on the business document corpus, similarity matching and topic modeling are performed between the disjoint code clusters and business function topics to obtain the audit microservice unit clusters; Based on the coupling of microservice business functions, gateway routing for information communication is established for the audit microservice unit cluster, and the audit microservice framework is determined.

3. The intelligent auditing full-process information communication management method as described in claim 2, characterized in that, The single computable graph structure includes an abstract syntax tree, a control flow graph, a program dependency graph, and a time code evolution layer; The abstract syntax tree encodes the nested structure and statement relationships of the code; the control flow graph depicts the execution order of statements and conditional jump logic; the program dependency graph shows the data dependency and control dependency relationships; and the time code evolution layer analyzes the symbiotic relationships of code parts.

4. The intelligent auditing full-process information communication management method as described in claim 1, characterized in that, Perform periodic adversarial testing on the audit microservice framework, including: Determine the architecture description and audit criteria of the audit microservice framework, and initialize the adversarial tester deployed on the edge of the framework; Based on the initialized adversarial tester, periodic test inputs are performed on the audit microservice framework to determine the operational evaluation metrics of the audit microservice.

5. The intelligent auditing full-process information communication management method as described in claim 4, characterized in that, Periodic test inputs are performed on the audit microservice framework to determine the operational evaluation metrics of the audit microservice, including: Based on the adversarial tester, an adversarial testing strategy is automatically generated, wherein the adversarial testing strategy includes constructing fuzzy boundary data, logical traps, and hint injection attacks; Based on the adversarial testing strategy, periodic tests are performed on the audit microservice framework to determine operational evaluation metrics.

6. The intelligent auditing full-process information communication management method as described in claim 5, characterized in that, The operational evaluation metrics include microservice performance from a black-box perspective and whether the internal activation mode is manipulated deceptively from a white-box perspective.

7. The intelligent auditing full-process information communication management method as described in claim 4, characterized in that, The audit microservice framework underwent partial optimization and architectural restructuring, including: By comparing the operational evaluation metrics with the security thresholds of the microservice architecture, if all operational evaluation metrics remain within the security thresholds, it is determined that the audited microservice framework can meet business needs, and local optimization instructions are generated. If business requirements are not met, an architecture decay analysis based on the code property graph is triggered, generating architecture refactoring instructions. The architecture refactoring methods include merging, splitting, adding, or adjusting audit services.

8. The intelligent auditing full-process information communication management method as described in claim 7, characterized in that, If it is the architecture refactoring instruction, identify the type and severity of architecture corruption, and retrieve similar historical cases from the knowledge base; Based on the similar historical cases, a refactoring plan is generated, which includes a microservice refactoring plan and a gateway routing adjustment plan. Based on the aforementioned restructuring plan, the audit microservice framework will be adjusted.

9. The intelligent auditing full-process information communication management method as described in claim 1, characterized in that, The audit results are stored in the form of an immutable event stream, including: Based on the audit results, a complete audit chain is obtained and transmitted to the audit archive in chronological order in the form of an immutable event stream. If the audit results trigger an anomaly or controversy, the corresponding audit event is retrieved from the audit archive and the cause is inferred and woven into a structured attribution chain; The structured attribution chain is then fed back to the audit archive and associated with the corresponding audit events.

10. A smart auditing full-process information communication management system, characterized in that, The system is used to implement the intelligent audit full-process information communication management method according to any one of claims 1-9, the system comprising: The audit microservice framework construction module, based on the source code of the audit system, performs business function theme modeling based on multi-dimensional analysis of code attribute graphs, obtains microservice unit clusters and establishes gateway routing, and determines the audit microservice framework. The audit result acquisition module is used to upload the data to be audited, and to perform automatic audit processing under the framework service link according to the audit microservice framework to obtain the audit result. An audit result storage module is used to store the audit results in the form of an immutable event stream, wherein if an anomaly is triggered, a structured attribution chain is inferred and associated. The operation evaluation index acquisition module deploys an adversarial tester on the edge of the audit microservice framework to perform periodic adversarial tests on the audit microservice framework, generates operation evaluation indexes that include black-box performance and white-box activation mode analysis, and performs local optimization and architecture reconstruction on the audit microservice framework.

Images