Interface change risk management and control method and device based on multi-source evidence fusion

Abstract

The invention provides an interface change risk management and control method and device based on multi-source evidence fusion, and the method comprises the steps: carrying out the standardization processing of interface call data from various heterogeneous evidence sources, and generating a unified endpoint set and a call relation set; fusing the multi-source data pointing to the same calling relationship to calculate the confidence of the multi-source data, and constructing a service dependency topological graph based on a high-confidence relationship; when an interface change is detected, analyzing an influence range of the change in the topological graph, quantitatively calculating an influence surface score, and dynamically judging a risk level; and implementing corresponding automatic management and control actions in the continuous integration / continuous delivery process according to the risk levels. According to the method and the device, the problem of frequent interface change online faults caused by inaccurate dependence identification, inaccurate change influence evaluation and risk management and control lagging can be solved, the risk discovery and management and control of interface definition destructive change can be advanced from online to before-online, and the online fault rate is further remarkably reduced.

Description

Technical Field

[0001] This application relates to the fields of software engineering and information technology, and in particular to a method and device for risk management of interface changes based on multi-source evidence fusion. Background Technology

[0002] With the widespread adoption of microservice architecture, monolithic applications are being broken down into dozens or even hundreds of independent services, which communicate with each other through interfaces such as OpenAPI and Remote Procedure Call (RPC). The number of interfaces has surged, and dependencies have become increasingly complex, exposing the serious shortcomings of traditional interface management methods based on manual processes or single tools. Against this backdrop, accurately identifying the true dependencies between services, effectively assessing the impact of interface changes, and proactively preventing online failures caused by these changes have become core challenges in ensuring the stable and efficient evolution of microservice systems.

[0003] Currently, the industry mainly uses the following technical solutions for service dependency identification and interface change management: (1) Static code analysis-based approach: This approach extracts statically declared dependencies between services by parsing import statements and HTTP client call declarations (such as Feign) in the source code. However, this approach can only capture explicit call intents in the code and cannot distinguish between "declared but not called" cases, resulting in a high false positive rate.

[0004] (2) Dynamic solution based on call chain tracing: By analyzing the request chain data collected in distributed tracing systems (such as Zipkin and Jaeger), the actual call topology between services is constructed. This solution relies on runtime sampling, which has limited coverage of interfaces with low-frequency calls or insufficient sampling rates, resulting in missed reports, and it cannot be associated with interface design definitions.

[0005] (3) Scheme based on interface description file difference comparison: By comparing the description files of two versions of the Open Application Programming Interface (OpenAPI) specification, changes in endpoints, parameters, data structures, etc. are identified, and destructive changes are marked according to fixed rules. This scheme only performs static literal difference comparison and does not combine the actual call relationships, traffic, and business importance and other runtime contexts to conduct impact assessment.

[0006] However, all the aforementioned existing technical solutions have significant drawbacks, resulting in an inability to achieve accurate risk management: First, dependency identification is inaccurate. Both static analysis and dynamic tracing rely on a single source of evidence. The former suffers from false positives due to intent rather than fact, while the latter suffers from missed positives due to sampling bias. Neither can construct an accurate and complete service dependency topology. Second, change impact assessment is inaccurate. Existing difference comparison tools rely solely on literal changes in interface definitions for mechanical judgment, failing to combine the actual caller, call frequency, service level objectives (SLOs), and business criticality of the interface for quantitative assessment, leading to severely distorted impact assessments. Finally, risk management is lagging. The above problems collectively result in the identification and risk assessment of disruptive changes heavily relying on manual processes and exhibiting slow response times. Automated and intelligent risk prevention or approval processes cannot be achieved in continuous integration or continuous delivery (CI / CD) workflows, making it easy for high-risk changes to enter the production environment and cause online failures. Summary of the Invention

[0007] In view of this, embodiments of this application provide a method and device for interface change risk management based on multi-source evidence fusion, so as to eliminate or improve one or more defects existing in the prior art.

[0008] One aspect of this application provides a method for managing interface change risks based on multi-source evidence fusion, including: Standardize the interface call data from various types of evidence sources to obtain an endpoint set and a call relationship set; each call relationship in the call relationship set is uniquely determined by the caller endpoint and the callee endpoint in an endpoint pair, and each call relationship is associated with standardized data records from its corresponding evidence source; Multiple standardized data records from different evidence sources corresponding to the same endpoint pair are fused and calculated to obtain the confidence level of the call relationship determined by the endpoint pair; the call relationships with confidence levels higher than a preset threshold are used as edges, and the endpoints in the endpoint set are used as nodes to construct a service dependency topology graph. When a change in the interface definition is detected, the service dependency topology graph is traversed in reverse from the target endpoint corresponding to the interface definition change to determine all affected endpoints that directly or indirectly call the target endpoint; the individual influence weights corresponding to each of the affected endpoints are obtained and aggregated to obtain the influence surface score of the interface definition change. Based on the impact score, the risk level of the interface definition change is dynamically determined; according to the risk level, corresponding control actions are implemented on the execution process of the interface definition change in the continuous integration or continuous delivery process.

[0009] In some embodiments of this application, prior to the standardization processing of interface call data originating from multiple different types of evidence sources, the method further includes: Scheduled tasks executed according to a preset cycle, code commit or build completion events associated with continuous integration or continuous delivery processes, or on-demand collection instructions initiated by users, collect interface call data from various types of evidence sources. These various types of evidence sources include: static evidence sources, dynamic evidence sources, gateway evidence sources, and registration evidence sources. Static evidence sources provide interface declaration information extracted from program code or interface definition files; dynamic evidence sources provide interface call information extracted from data generated during software system runtime; gateway evidence sources provide access log data from application interface gateways; and registration evidence sources provide service instance information and routing configuration data from service registries. The static evidence sources include at least one of the following: source code analysis results, application programming interface (API) description files, or compilation and build artifacts; The dynamic evidence sources include at least one of the following: call chain tracing data, application programming interface (API) gateway access logs, or service registry information.

[0010] In some embodiments of this application, the standardization of interface call data from various types of evidence sources to obtain an endpoint set and a call relationship set includes: The interface call data collected from different evidence sources is parsed to obtain the service identifier, protocol type, HTTP request method and original interface path of each interface; The original interface path is divided into a sequence of path segments by a delimiter. The path segments in the sequence that conform to a numeric pattern or a universally unique identifier pattern are identified. The identified path segments are replaced with the corresponding parameter placeholders. The replaced path segment sequences are then recombined to generate the standardized path template. Each of the interfaces is treated as different endpoints. The service identifier, protocol type, HTTP request method and standardized path template corresponding to each interface are concatenated to obtain the endpoint identifier of each interface, so as to form an endpoint set containing the endpoint identifier corresponding to each endpoint. Furthermore, the endpoint identifiers of the caller endpoint and the callee endpoint are extracted from the interface call data and associated with the corresponding evidence sources to form a call relationship set.

[0011] In some embodiments of this application, the step of fusing and calculating multiple standardized data records corresponding to the same endpoint pair and from different evidence sources to obtain the confidence level of the call relationship determined by the endpoint pair includes: Obtain each standardized data record corresponding to the same endpoint pair and its respective associated source of evidence; For each of the standardized data records, an initial score is calculated by calling a preset scoring function based on the type of the evidence source associated with it. Obtain adaptively adjustable weights corresponding to each type of evidence source; wherein, the adaptively adjustable weights are obtained based on periodic steps, the periodic steps including: obtaining a historical sample set containing verified real call relationships and false positive call relationships, calculating the accuracy of each type of evidence source in identifying call relationships in the historical sample set; and assigning normalized weights to each type of evidence source based on the accuracy as the current adaptively adjustable weights. A fusion score is obtained by weighting the initial score and the corresponding adaptively adjustable weights. Based on the time of the most recent occurrence among the multiple standardized data records, the time decay is calculated; the time decay is subtracted from the fusion score to obtain the confidence level of the endpoint for the determined call relationship.

[0012] In some embodiments of this application, the step of constructing a service dependency topology graph by using the call relationships with confidence levels higher than a preset threshold as edges and the endpoints in the endpoint set as nodes includes: Set each endpoint in the endpoint set as a node in the service dependency topology graph; Furthermore, each call relationship with a confidence level higher than a preset threshold is set as a directed edge in the service dependency topology graph connecting the node where its corresponding caller endpoint is located and the node where its corresponding callee endpoint is located; wherein each directed edge is associated with the confidence level of its corresponding call relationship and multiple standardized data records used to calculate the confidence level. Generate a versioned snapshot for the service dependency topology graph and store the versioned snapshot.

[0013] In some embodiments of this application, when a change in the interface definition is detected, a reverse traversal is performed on the service dependency topology graph, starting from the target endpoint corresponding to the interface definition change, to determine all affected endpoints that directly or indirectly call the target endpoint, including: When a change in the interface definition is detected, the target endpoint corresponding to the interface definition change is determined; Using the target endpoint as the starting node, a reverse breadth-first search or depth-first search is performed on the service dependency topology graph; the search radius of the reverse breadth-first search or depth-first search is configurable. Based on the search radius, traverse and collect all nodes that reach the starting node directly or indirectly through the edge, and determine the endpoints corresponding to each collected node as the affected endpoints.

[0014] In some embodiments of this application, obtaining and aggregating the individual influence weights corresponding to each of the affected endpoints to obtain the influence surface score of the interface definition change includes: Obtain the historical call frequency index of each affected endpoint within a preset historical time period, compare the historical call frequency index with a preset traffic threshold, take the smaller value of the two, and then divide the smaller value by the traffic threshold to obtain the traffic weight. In addition, the business criticality preset for each of the affected endpoints is obtained; Based on the traffic weight, service level target weight, business criticality, and edge confidence of each affected endpoint, the individual impact weight corresponding to each affected endpoint is calculated; wherein, the service level target weight is determined in advance based on a preset allowable error rate, and the edge confidence is the confidence of the call relationship between the affected endpoint and the target endpoint; The individual impact weights of all affected endpoints are summed to obtain the impact surface score of the interface definition change.

[0015] In some embodiments of this application, the risk level of the interface definition change is dynamically determined based on the impact surface score; and corresponding control actions are implemented on the execution process of the interface definition change in the continuous integration or continuous delivery process according to the risk level, including: The interface definition change is matched with the rules in the rule base; the rule base contains multiple rule levels with different priorities, including global rules, service-level rules, and temporary exemption rules; Based on the highest priority rule matched, obtain and output the static risk assessment result of the interface definition change; Based on at least two preset impact score thresholds, the numerical range is divided into different risk level intervals; The calculated impact surface score is matched with each preset risk level interval to determine its corresponding risk level; wherein, the risk level interval is formed in advance by dividing the preset numerical range based on at least two impact surface score thresholds, and each risk level interval corresponds to a different risk level; wherein, each risk level includes high risk, medium risk and low risk. If the identified risk level is high, then control actions such as blocking the code merging process or blocking the deployment process will be implemented. If the determined risk level is medium risk, then the control action that triggers the manual approval process will be executed; If the determined risk level is low, then execute the control action of generating an alarm notification and allowing the process to continue; For interface definition changes that are determined to be of medium or high risk, a change impact notification is generated and sent to the responsible party corresponding to the affected endpoint, and a work item is created in the project management system to track the processing status of the interface definition change. For interface definition changes that are determined to be low-risk, backward compatibility support data is provided for the interface definition changes during the transition period defined in the pre-configured compatibility window; after the transition period ends, the backward compatibility support data automatically becomes invalid.

[0016] Another aspect of this application provides an interface change risk management system based on multi-source evidence fusion, including: The multi-source data standardization module is used to standardize interface call data from multiple different types of evidence sources to obtain an endpoint set and a call relationship set. Each call relationship in the call relationship set is uniquely determined by the caller endpoint and the callee endpoint in an endpoint pair, and each call relationship is associated with a standardized data record from its corresponding evidence source. The confidence assessment and dependency topology construction module is used to fuse and calculate multiple standardized data records from different evidence sources corresponding to the same endpoint pair to obtain the confidence of the call relationship determined by the endpoint pair; call relationships with confidence scores higher than a preset threshold are used as edges, and endpoints in the endpoint set are used as nodes to construct a service dependency topology graph. The change inspection and intelligent judgment module is used to, when a change in the interface definition is detected, perform a reverse traversal on the service dependency topology graph starting from the target endpoint corresponding to the interface definition change, determine all affected endpoints that directly or indirectly call the target endpoint; obtain and aggregate the individual influence weights corresponding to each of the affected endpoints, and obtain the influence surface score of the interface definition change; The risk level and process control module is used to dynamically determine the risk level of the interface definition change based on the impact surface score; and to implement corresponding control actions on the execution process of the interface definition change in the continuous integration or continuous delivery process according to the risk level.

[0017] A third aspect of this application provides an electronic device including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned interface change risk management method based on multi-source evidence fusion.

[0018] A fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the described interface change risk management method based on multi-source evidence fusion.

[0019] The fifth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the described interface change risk management method based on multi-source evidence fusion.

[0020] This application provides a multi-source evidence fusion-based interface change risk management method. By fusing and standardizing data from various evidence sources (static, dynamic, etc.), it overcomes the inherent false positives or false negatives of single evidence sources (such as code analysis alone or call chains alone). Utilizing confidence calculation and threshold filtering, it effectively distinguishes between real, stable call relationships and noisy data, thereby constructing a high-accuracy, high-confidence service dependency topology graph, laying a reliable foundation for subsequent impact analysis. When an interface change is detected, this method does not perform a simple static rule comparison, but rather performs a reverse traversal based on the constructed high-confidence topology graph to accurately locate all directly or indirectly affected callers. By aggregating the individual impact weights of each affected party (combining historical call volume, business criticality, etc.), a quantified impact surface score is calculated. This transforms impact assessment from a qualitative judgment of whether there is an impact to a quantitative analysis of the extent of the impact, resulting in a more objective and accurate assessment. Based on the quantified impact surface score, the risk level is dynamically determined, and the judgment result is directly linked to the continuous integration or continuous delivery process, automatically executing corresponding control actions (such as blocking, approval access control, and alarms). This allows for the timely discovery and control of risks, significantly advancing the process from post-deployment failures to the pre-deployment code commit or build phase, forming an automated security defense. The combination of these effects fundamentally reduces online failures caused by destructive interface changes. By accurately identifying dependencies, intelligently assessing risks, and automatically intercepting high-risk changes upfront, the frequency and impact of related online incidents can be significantly reduced, ensuring the stability and delivery efficiency of systems under a microservice architecture.

[0021] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0022] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0023] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a schematic diagram of the first process of the interface change risk management method based on multi-source evidence fusion in one embodiment of this application.

[0024] Figure 2 This is a schematic diagram of the second process of the interface change risk management method based on multi-source evidence fusion in one embodiment of this application.

[0025] Figure 3 This is a schematic diagram of the specific process of step 100 in the interface change risk management method based on multi-source evidence fusion in one embodiment of this application.

[0026] Figure 4 This is a schematic diagram of the specific process of step 200 in the interface change risk management method based on multi-source evidence fusion in one embodiment of this application.

[0027] Figure 5 This is a schematic diagram of the specific process of step 300 in the interface change risk management method based on multi-source evidence fusion in one embodiment of this application.

[0028] Figure 6 This is a schematic diagram of the specific process of step 400 in the interface change risk management method based on multi-source evidence fusion in one embodiment of this application.

[0029] Figure 7 This is a schematic diagram of the interface change risk management system based on multi-source evidence fusion in one embodiment of this application. Detailed Implementation

[0030] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0031] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the scheme according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0032] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0033] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0034] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0035] In one or more embodiments of this application, OpenAPI (Open Application Programming Interface Specification) is a standard format for describing RESTful interfaces, originally named Swagger. Service Level Objective Weighting (SLO) is a relative importance coefficient assigned to different service metrics (such as availability, latency, throughput, error rate, etc.) within the Service Level Objectives (SLO) framework. This weight is used to quantify the priority and impact of each metric during system evaluation, alerting policies, resource scheduling, or service governance. CI / CD (Continuous Integration / Continuous Delivery) is a process for automating the building, testing, and deployment of software. Distributed tracing is a technique that records the propagation of a request across multiple services using traces and spans; common tools include Zipkin, Jaeger, and SkyWalking. A Service Registry is a component used for service discovery in a microservice architecture, such as Nacos, Eureka, and Consul. An API gateway is middleware that unifies interface routing, authentication, rate limiting, and monitoring, such as Nginx Ingress and Kong. An endpoint is the specific access path of an interface, composed of a service identifier, HTTP method (GET / POST, etc.), and path template (e.g., / v1 / users / {id}). A schema is a specification describing the data structure, typically using JSON Schema to define request parameters and response fields. A breaking change is a change to the interface that causes existing callers to malfunction, such as deleting fields, modifying paths, or tightening parameter types. Static evidence is interface definition information extracted from source code, compilation artifacts, and interface description files. Dynamic evidence is interface call information collected from runtime logs, call chain tracing, and gateway access records. Confidence measures the degree to which a dependency truly exists, ranging from 0 to 1. Impact scope is the number of callers and the scope of business that an interface change may affect. A Mock Server is a service that automatically generates mock responses based on interface definitions, used for parallel front-end and back-end development. RBAC (Role-Based Access Control) is a security model that assigns permissions according to user roles.Semantic versioning uses a "major version number, minor version number, revision number" format to manage versions; disruptive changes require an upgrade of the major version number. Content-Addressable Storage (CAS) is a technology that stores and retrieves data based on content hash values, automatically deduplicating identical content.

[0036] To address the frequent online failures caused by inaccurate dependency identification, inaccurate change impact assessment, and lagging risk management, this application provides an interface change risk management method based on multi-source evidence fusion, an interface change risk management system based on multi-source evidence fusion for executing the method, an electronic device, a computer-readable storage medium, and a computer program product. By fusing multi-source evidence to construct a high-confidence dependency topology and combining runtime indicators to intelligently quantify the impact of changes, the risk discovery and management of destructive changes can be moved from after deployment to before deployment, thereby significantly reducing the online failure rate.

[0037] The following examples will provide a detailed description.

[0038] Based on this, embodiments of this application provide an interface change risk management method based on multi-source evidence fusion, which can be implemented by an interface change risk management system based on multi-source evidence fusion. See [link to relevant documentation]. Figure 1 The interface change risk management method based on multi-source evidence fusion specifically includes the following: Step 100: Standardize the interface call data from various types of evidence sources to obtain an endpoint set and a call relationship set; each call relationship in the call relationship set is uniquely determined by the caller endpoint and the callee endpoint in an endpoint pair, and each call relationship is associated with a standardized data record from its corresponding evidence source.

[0039] Specifically, the system collects data from multiple configured evidence sources. For example, it scans the user service source code and finds code that uses the Java HTTP client component Feign framework to declare a call to the order service's create order interface (static evidence); simultaneously, it collects a link record from the distributed tracing system showing a front-end application calling the user service and the user service calling the order service (dynamic evidence). The system parses this raw data, templates all interface paths (e.g., converting " / users / 12345" to " / users / {id}"), and generates endpoint identifiers for each interface according to a unified rule (e.g., "svc.user#HTTP#GET# / v1 / users / {id}"). Ultimately, this forms an endpoint set containing all unique endpoints, and a call relationship set containing relationships such as front-end application endpoints, user service endpoints, and relationships from user service endpoints to order service endpoints, with each relationship labeled with its source evidence.

[0040] In one or more embodiments of this application, the source of evidence refers to the source of interface call data, which is mainly divided into static source evidence (such as source code, interface description file) and dynamic source evidence (such as distributed tracing system, application programming interface (API) gateway log); this embodiment combines these two types.

[0041] The endpoint set and the call relationship set are the core outputs after standardization. An endpoint is a unique abstract representation of an interface; the endpoint set is a list of all endpoints; the call relationship describes the directional relationship of one endpoint calling another; the call relationship set is a list of all such relationships.

[0042] An endpoint pair refers to two endpoints involved in a calling relationship, namely the caller endpoint and the callee endpoint. A relationship is uniquely determined by an endpoint pair.

[0043] The standardized data record refers to a structured data entry that, after standardization, belongs to a specific calling relationship and bears a source evidence marker.

[0044] Step 200: Merge and calculate multiple standardized data records from different evidence sources corresponding to the same endpoint pair to obtain the confidence level of the call relationship determined by the endpoint pair; take the call relationship with the confidence level higher than a preset threshold as an edge, and take the endpoints in the endpoint set as nodes to construct a service dependency topology graph.

[0045] Specifically, for the endpoint pair from user service to order service, the system finds that it exists in both static code and dynamic trace evidence. The system calls a preset scoring function to score these two standardized data records separately (e.g., dynamic records receive a higher score due to frequent calls, while static records receive a base score due to explicit declarations), and assigns adaptively adjustable weights to static and dynamic evidence sources based on historical data (e.g., dynamic evidence has a higher weight). Then, a fusion calculation (e.g., weighted average) is performed to obtain a confidence score (e.g., 0.9) for the call relationship. The system filters all call relationships with a confidence score exceeding a threshold (e.g., 0.7), treats them as edges, and the involved endpoints as nodes, drawing a service dependency topology graph.

[0046] Fusion computing refers to the process of combining multiple data points from different evidence sources that describe the same fact through weighting, denoising, and other algorithms to obtain a more reliable result.

[0047] In this embodiment, confidence is used to synthesize the confidence score. The confidence score is a value between 0 and 1, quantifying the degree to which a certain call relationship truly exists. The higher the confidence score, the more reliable the relationship.

[0048] A service dependency topology graph is a graphical representation in which nodes represent service endpoints, directed edges represent call dependencies between services, and edges can be assigned attributes such as confidence.

[0049] Step 300: When a change in the interface definition is detected, on the service dependency topology graph, a reverse traversal is performed starting from the target endpoint corresponding to the interface definition change to determine all affected endpoints that directly or indirectly call the target endpoint; the individual influence weights corresponding to each of the affected endpoints are obtained and aggregated to obtain the influence surface score of the interface definition change.

[0050] Specifically, when the definition of the order creation interface (i.e., the target endpoint) of the order service changes (e.g., deleting a response field), the system performs a reverse traversal on the service dependency topology graph, starting from the target endpoint and moving in the opposite direction of the call edges (i.e., finding which endpoints called it). The traversal reveals that the user service endpoint directly calls it. Further traversal reveals that the frontend application endpoint calls the user service; therefore, both the user service and the frontend application endpoints are identified as affected endpoints. The system then obtains the pre-defined individual impact weight for each affected endpoint (this weight is pre-calculated based on factors such as its historical call volume and business importance), aggregates and sums these weights, and finally obtains an impact surface score representing the potential impact of this change.

[0051] It should be noted that reverse traversal is an algorithm in graph theory that starts from a certain node and searches for all reachable nodes in the opposite direction to the edge direction. It is used to find which services have called the currently changed service.

[0052] The affected endpoints are all other endpoints in the topology graph that directly or indirectly call the target endpoint; these are the objects potentially affected by the change.

[0053] The individual impact weight is a quantitative value used to measure the extent to which a single affected endpoint may be affected by a change, typically calculated based on its traffic and business criticality.

[0054] The impact surface score is the sum of the individual impact weights of all affected endpoints. This score comprehensively reflects the breadth and depth of the impact of the change and is a core indicator for quantifying risk.

[0055] Step 400: Based on the impact surface score, dynamically determine the risk level of the interface definition change; according to the risk level, implement corresponding control actions on the execution process of the interface definition change in the continuous integration or continuous delivery process.

[0056] Specifically, the system compares the calculated impact score with a preset threshold range to dynamically determine the risk level of the change (e.g., a very high score indicates high risk). Based on the determined risk level, the system automatically implements corresponding control actions in the continuous integration or continuous delivery (CI / CD) process. For example, for high-risk changes, the system will automatically block the code merge or deployment process and notify the responsible person; for medium-risk changes, an approval gate will be triggered, requiring manual review and approval before proceeding.

[0057] The dynamic determination refers to flexibly matching and judging the risk level based on the specific impact surface score value calculated in real time, rather than using fixed and rigid rules.

[0058] The risk level is a classification label (such as high, medium, low) for the degree of potential hazard caused by changes, used to guide the implementation of control measures of different severity.

[0059] The continuous integration or continuous delivery process refers to an automated pipeline for software from code submission, building, testing to deployment. This method embeds control actions into key aspects of this process.

[0060] The control actions are automated operations performed to address different risk levels, mainly including blocking, approval access control, and alarm release, which aim to prevent or delay high-risk changes from entering the production environment.

[0061] As described above, the interface change risk management method based on multi-source evidence fusion provided in this application overcomes the inherent false positives or false negatives of a single evidence source (such as code analysis or call chain only) by fusing and standardizing data from various evidence sources (static, dynamic, etc.). Utilizing confidence calculation and threshold filtering, it effectively distinguishes between real, stable call relationships and noisy data, thereby constructing a high-accuracy, high-confidence service dependency topology graph, laying a reliable foundation for subsequent impact analysis. When an interface change is detected, this method does not perform a simple static rule comparison, but rather performs a reverse traversal based on the constructed high-confidence topology graph to accurately locate all directly or indirectly affected callers. By aggregating the individual impact weights of each affected party (combining historical call volume, business criticality, etc.), a quantified impact surface score is calculated. This transforms impact assessment from a qualitative judgment of whether or not there is an impact to a quantitative analysis of the extent of the impact, resulting in a more objective and accurate assessment. The risk level is dynamically determined based on the quantified impact surface score, and the judgment result is directly linked to the continuous integration or continuous delivery process, automatically executing corresponding control actions (such as blocking, approval access control, and alarms). This allows for the timely discovery and control of risks, significantly advancing the process from post-deployment failures to the pre-deployment code commit or build phase, forming an automated security defense. The combination of these effects fundamentally reduces online failures caused by destructive interface changes. By accurately identifying dependencies, intelligently assessing risks, and automatically intercepting high-risk changes upfront, the frequency and impact of related online incidents can be significantly reduced, ensuring the stability and delivery efficiency of systems under a microservice architecture.

[0062] During interface change processes, existing technologies often rely on single or manual data collection, leading to incomplete or delayed data updates. To further address the fundamental issue of how to comprehensively, timely, and automatically acquire this multi-source heterogeneous data, this application provides an interface change risk management method based on multi-source evidence fusion, see [link to relevant documentation]. Figure 2 The method for managing interface changes based on multi-source evidence fusion, prior to step 100, specifically includes the following: Step 010: Collect data from various types of evidence sources by using scheduled tasks executed according to a preset cycle, code commits or build completion events associated with continuous integration or continuous delivery processes, or on-demand collection instructions initiated by users.

[0063] Specifically, data collection tasks can be initiated in three ways: 1) Scheduled tasks: For example, the system is configured with a scheduled task that runs at 2 AM every day, automatically pulling data from all configured evidence sources for the past 24 hours. 2) Continuous Integration / Continuous Delivery (CI / CD) events: When developers commit code to a Git repository and trigger a build, the system will detect this event and initiate an incremental data collection for the services affected by the change. 3) On-demand collection commands: Operations personnel can manually trigger data collection for specific service API calls through the management interface.

[0064] Scheduled tasks are tasks that are automatically executed periodically according to preset time rules (such as hourly or daily) to ensure continuous data updates. Events associated with the Continuous Integration / Continuous Delivery (CI / CD) process refer to events generated at key nodes in the CI / CD pipeline, such as code commits, branch merging, build completion, and releases. This association enables change-driven real-time data acquisition.

[0065] In addition, the process of the system collecting data from multiple sources of evidence includes: (1) Collection from static evidence sources: The system calls source code analysis tools (such as SonarQube plugins) to scan the Java code of the order service and parse all interfaces declared using the Feign client (Feign) or the "@RestController" annotation; at the same time, it extracts the generated OpenAPI description file from the build artifacts.

[0066] (2) Collect evidence from dynamic sources: The system queries the call chain tracing system (such as SkyWalking) to obtain the link details (Trace and Span) of the "User Service" calling the "Order Service"; at the same time, it reads all access records to the "Order Service" interface from the logs of the application programming interface (API) gateway (such as Kong).

[0067] (3) Collection from gateway evidence source: The system directly reads the access log file of the application programming interface (API) gateway (such as Nginx) and parses the source IP (which can be mapped to the service name), request path, response status code and other information in each log.

[0068] (4) Collection from registration evidence source: The system connects to the service registry (such as Nacos) to obtain a list of all currently registered health service instances and their metadata (such as service name, IP address, port).

[0069] (5) All the raw data collected (code information, log entries, trace span, service list) are aggregated and await subsequent standardization processing.

[0070] Specifically, various types of evidence sources include: static evidence sources, dynamic evidence sources, gateway evidence sources, and registration evidence sources; wherein, the static evidence source is used to provide interface declaration information extracted from program code or interface definition files, the dynamic evidence source is used to provide interface call information extracted from data generated during software system runtime, the gateway evidence source provides access log data from the application interface gateway, and the registration evidence source provides service instance information and routing configuration data from the service registry.

[0071] The static evidence sources include at least one of the following: source code analysis results, application interface (API) description files, or compilation and build artifacts; the dynamic evidence sources include at least one of the following: call chain tracing data, application interface (API) gateway access logs, or service registry information. It should be noted that static evidence sources are data derived from the "design state" or "build state" artifacts before the system runs, reflecting the developer's stated intent. Examples include source code analysis results (obtained by parsing the code syntax tree), application programming interface (API) description files (such as OpenAPI specification files), and compilation and build artifacts (such as annotation information in packaged JAR files).

[0072] Dynamic evidence sources derive their data from the "runtime state" of the system, reflecting actual call behavior. Examples include call chain tracing data (which records the complete path of a request across services) and Application Programming Interface (API) gateway access logs (which record all requests passing through the gateway).

[0073] Gateway evidence sources specifically refer to data generated by the application programming interface (API) gateway, a network infrastructure that provides a network-layer, service-independent perspective for access observation.

[0074] The source of registered evidence specifically refers to the service registry, a microservice infrastructure that provides core information on service discovery and health status.

[0075] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application, by defining a flexible event triggering mechanism and a complete evidence source system covering the design state and the runtime state, can ensure that the original data necessary for constructing a high-confidence dependency topology can be automatically and comprehensively collected, thereby consolidating the data foundation of the entire method and ensuring the real-time performance and reliability of dependency identification and analysis results.

[0076] During interface change processes, to further address the key issue of how to transform raw data from different sources and with heterogeneous formats (such as paths containing specific IDs and service names with different naming conventions) into a unified data model capable of consistency comparison and fusion, this application provides an interface change risk management method based on multi-source evidence fusion, see [link to relevant documentation]. Figure 3 Step 100 of the interface change risk management method based on multi-source evidence fusion specifically includes the following: Step 110: Parse the interface call data collected from different evidence sources to obtain the service identifier, protocol type, HTTP request method and original interface path of each interface.

[0077] Specifically, the system parses the collected raw API call data. For example, from an access log from the Application Programming Interface (API) gateway, it parses out: the service identifier is "svc.order" (order service), the protocol type is "HTTP", the HTTP request method is "POST", and the original interface path is " / v1 / orders". From a span in the call chain tracing data, it parses out: the caller service identifier is "svc.user" (user service), the callee service identifier is "svc.order", and the original interface path is " / v1 / orders / 67890".

[0078] The service identifier is a string used to uniquely identify a microservice within the system, and is usually consistent with the service name in the deployment configuration, such as "svc.user". The protocol type is the protocol used for interface communication, such as HTTP or gRPC. The raw interface path is the unprocessed interface access path extracted directly from the raw data, and usually contains specific parameter values, such as " / v1 / users / 12345".

[0079] Step 120: Divide the original interface path into a sequence of path segments according to the delimiter, identify the path segments in the sequence that conform to the numeric pattern or the universally unique identifier pattern, replace the identified path segments with the corresponding parameter placeholders, and recombine the replaced path segment sequence to generate the standardized path template.

[0080] Specifically, the system processes the original interface path obtained in the previous step. Taking the path " / v1 / users / 12345 / profile" as an example, it first splits the path into a sequence of path segments by " / ": ["v1", "users", "12345", "profile"]. Next, it identifies the path segments in this sequence and finds that "12345" conforms to a numeric pattern. Then, it replaces this path segment with the corresponding parameter placeholder "{id}". Finally, it recombines the replaced sequence ["v1", "users", "{id}", "profile"] to generate the standardized path template " / v1 / users / {id} / profile". For paths containing a universally unique identifier (UUID) such as "a1b2c3d4-...", it replaces it with "{uuid}".

[0081] The standardized path template is a static path pattern formed by replacing the variable parameter values ​​in the interface path with uniform placeholders (such as {id}, {uuid}). It is a key part of generating a unified endpoint identifier.

[0082] Step 130: Treat each of the interfaces as different endpoints, and concatenate the service identifier, protocol type, HTTP request method and standardized path template corresponding to each interface to obtain the endpoint identifier of each interface, so as to form an endpoint set containing the endpoint identifiers corresponding to each endpoint.

[0083] Specifically, the system defines each parsed and templated interface as an endpoint. For the order service creation interface in the example above, its service identifier is "svc.order", its protocol type is "HTTP", its HTTP request method is "POST", and its standardized path template is " / v1 / orders". The system concatenates these parts in a fixed order to obtain the endpoint identifier for this interface: "svc.order#HTTP#POST# / v1 / orders". All such unique endpoint identifiers together constitute the endpoint set.

[0084] The endpoint identifier is a globally unique string used to precisely identify a specific interface within the system. Its concatenation format ensures that the same interface can be consistently identified across different sources of evidence.

[0085] And step 140: extract the endpoint identifiers of the caller endpoint and the callee endpoint from the interface call data, and associate them with the corresponding evidence sources to form a call relationship set.

[0086] Specifically, the system extracts call relationships from the parsed data. For example, from a call chain tracing data, it extracts the caller endpoint identifier as "svc.user#HTTP#GET# / v1 / users / {id}" and the callee endpoint identifier as "svc.order#HTTP#GET# / v1 / orders / {id}". The system records this pair of endpoint identifiers and associates them with the evidence source of this relationship as "dynamic evidence (call chain)," thus forming a call relationship record. All such records constitute a call relationship set.

[0087] The call relationship set is a data set consisting of multiple records. Each record stores the core information of a call relationship (who calls whom) and its data source, which serves as the input for subsequent multi-source fusion.

[0088] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application provides a specific and operable standardized method by defining path template algorithm and endpoint identifier splicing rules. This method maps multi-source heterogeneous data into a unified endpoint identifier and call relationship representation, thereby eliminating noise caused by differences in data sources and providing high-quality, consistent input data for fusion computing.

[0089] In the process of interface change, to further address the two key issues of how to quantify the reliability differences of different evidence sources and how to avoid interference from outdated data, this application provides an interface change risk management method based on multi-source evidence fusion, see [link to relevant documentation]. Figure 4 Step 200 of the interface change risk management method based on multi-source evidence fusion specifically includes the following: Step 210: Obtain the standardized data records corresponding to the same endpoint pair and their respective associated sources of evidence.

[0090] Specifically, the system searches the standardized data for the endpoint pair "user service calls order service details". It finds two related standardized data records: one from source code scanning (static evidence), and the other from a call chain tracing system (dynamic evidence). The system extracts these records along with their associated evidence source types for fusion. The endpoint pair can contain: the caller: "svc.user#HTTP#GET# / v1 / users / {id}"; and the callee: "svc.order#HTTP#GET# / v1 / orders / {id}".

[0091] The endpoint pair is an ordered combination that clearly indicates the direction of the call relationship, namely the caller endpoint and the callee endpoint. The standardized data record is a structured data entry about a specific call event after standardization processing.

[0092] Step 220: For each of the standardized data records, according to the type of the evidence source associated with it, call the preset scoring function to calculate an initial score.

[0093] Specifically, the system invokes a pre-defined scoring function based on the type of evidence source for each record. For call chain records from dynamic evidence sources, the scoring function examines their call frequency (e.g., an average query per second (QPS) of 50 over the past 7 days) and stability (error rate of 0.5%). Assuming an initial score of 0.85 based on the rules. For code records from static evidence sources, the scoring function examines the clarity of their code declarations and the completeness of their interface definitions. Assuming an initial score of 0.70.

[0094] A pre-defined scoring function is an algorithm designed for a specific type of evidence source. It is used to transform the evidence into an initial quality score between 0 and 1. The higher the score, the more reliable the evidence is.

[0095] Step 230: Obtain the adaptively adjustable weights corresponding to each type of evidence source; wherein the adaptively adjustable weights are obtained based on periodic steps, the periodic steps including: obtaining a historical sample set containing verified real call relationships and false positive call relationships, calculating the accuracy of each type of evidence source in identifying call relationships in the historical sample set; and assigning normalized weights to each type of evidence source based on the accuracy as the current adaptively adjustable weights.

[0096] Specifically, the system executes a weight update task weekly. This task analyzes a historical sample set, which includes manually labeled "real call relationships" (positive samples) and "false positive relationships" (negative samples). Statistical analysis reveals that over the past week, dynamic evidence sources (such as call chains) appeared frequently in positive samples but rarely in negative samples, resulting in an accuracy rate of 92%. Static evidence sources (such as code scanning), while comprehensive, contain some declarations that were not actually called, achieving an accuracy rate of 78%. The system normalizes these two accuracy rates, calculating a weight of 0.54 for dynamic evidence sources and 0.46 for static evidence sources at the current stage. These two values ​​are the currently used, adaptively adjustable weights.

[0097] The adaptively adjustable weight is a coefficient assigned to different types of evidence sources to reflect their relative importance during fusion. This coefficient is not fixed but is automatically adjusted periodically based on historical performance (accuracy).

[0098] The historical sample set is a set of labeled data used to evaluate and train the system, and it serves as the basis for weighted adaptive learning.

[0099] Accuracy is the probability that a given source of evidence correctly identifies or excludes a call relationship in a historical sample.

[0100] Step 240: Perform a weighted calculation on the initial score and the corresponding adaptively adjustable weights to obtain a fusion score.

[0101] Specifically, the system performs a weighted calculation by combining the two initial scores (0.85 and 0.70) obtained in step B with the corresponding weights (0.54 and 0.46) obtained in step 230. That is: Fusion score = 0.85 × 0.54 + 0.70 × 0.46 = 0.459 + 0.322 = 0.781.

[0102] The weighted calculation involves multiplying each input value by a coefficient (weight) representing its importance, and then summing all the products. This is used here to synthesize multi-source evidence.

[0103] Step 250: Calculate the time decay based on the most recent occurrence time among the multiple standardized data records.

[0104] Specifically, the system checks the most recent occurrence time of the two standardized data records mentioned above. Assume the dynamic evidence record is from 1 day ago and the static evidence record is from 15 days ago. The system takes the most recent time (1 day ago) as the most recent occurrence time of this data set. Assume the system's half-life is configured to be 30 days and uses an exponential decay model. The calculated time decay is: decay coefficient × exp(-1 / 30). If the decay coefficient is 0.2, the decay is approximately 0.2 × 0.967 = 0.1934.

[0105] The time decay factor is a deduction value used to reduce the credibility of evidence that has not appeared for a long time. It is calculated based on the most recent occurrence time and a preset half-life parameter; the longer the time, the greater the decay factor.

[0106] Step 260: Subtract the time decay from the fusion score to obtain the confidence level of the determined call relationship by the endpoint.

[0107] Specifically, the system subtracts the time decay (0.1934) from the fusion score (0.781), obtaining a preliminary result of 0.5876. The system then limits this result to the interval [0,1], ultimately obtaining a confidence level of 0.5876, or approximately 0.59, for the endpoint regarding the determined call relationship. The confidence level, considering multi-source evidence scores, evidence source weights, and time decay, is the final quantifiable value of the credibility of a call relationship, ranging from 0 to 1.

[0108] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application introduces a weight adaptive adjustment mechanism based on historical performance and a time decay function, which enables confidence assessment to dynamically adapt to changes in the quality of evidence sources and mitigate the impact of outdated data, thereby significantly improving the timeliness and accuracy of dependency identification.

[0109] During interface changes, to further address the issue that the topology diagram is dynamic and transient, lacking state retention capabilities, it is impossible to answer questions such as "What was the system dependency state at a certain point in the past?" and "How does this change differ from the last one?" This hinders root cause analysis and change auditing. In this application's embodiment, an interface change risk management method based on multi-source evidence fusion is provided, see [link to relevant documentation]. Figure 4 The method for managing interface changes based on multi-source evidence fusion, after step 260 in step 200, further includes the following: Step 270: Set each endpoint in the endpoint set as a node in the service dependency topology graph.

[0110] Specifically, the system reads the endpoint set, which contains all standardized interface identifiers, such as the user service query interface and the order service creation interface. The system instantiates each unique endpoint identifier as a node in the service dependency topology graph. The node records basic information such as the endpoint's service name and interface path.

[0111] In a graph data structure, a node represents an entity. In this topology graph, each node uniquely corresponds to a service endpoint, serving as the start or end point of a dependency relationship.

[0112] Step 280: For each call relationship with a confidence level higher than a preset threshold, set it as a directed edge in the service dependency topology graph that connects the node where the corresponding caller endpoint is located to the node where the callee endpoint is located; wherein, each directed edge is associated with the confidence level of its corresponding call relationship and multiple standardized data records used to calculate the confidence level.

[0113] Specifically, the system iterates through all call relationships whose confidence scores are calculated through the fusion process. For example, if the confidence score of the relationship "svc.user endpoint A to svc.order endpoint B" is 0.85, which is higher than a preset threshold (e.g., 0.7), the system finds the corresponding two nodes (the user service node and the order service node) in the graph and creates a directed edge between them. The system appends the confidence score of 0.85 to this edge. Simultaneously, the system associates the index or summary information of multiple standardized data records used to calculate this confidence score (such as dynamic records from the call chain and static records from code scanning) with this edge for subsequent tracing.

[0114] In a graph data structure, a directed edge represents a unidirectional relationship from one node to another. In this topology graph, a directed edge represents a dependency relationship where one endpoint calls another endpoint, with the direction from the caller to the callee.

[0115] Step 290: Generate a versioned snapshot for the service dependency topology graph and store the versioned snapshot.

[0116] Specifically, whenever a complete topology construction is completed (e.g., a daily scheduled task or triggered after deployment), the system generates a versioned snapshot of the current complete service dependency topology graph. This snapshot contains a unique version identifier (e.g., "snapshot-2023-10-27-01") and records the complete state of all nodes and edges and their associated data at the current moment. The system employs an efficient storage strategy (e.g., copy-on-write) for storage, meaning that the new snapshot only stores incremental changes relative to the previous snapshot to save space. All historical snapshots are saved, forming a traceable time series.

[0117] A versioned snapshot is a read-only backup of the complete state of the topology at a specific point in time. It allows the system to rewind to any point in history and view the service dependencies at that time.

[0118] Copy-on-write is a storage optimization strategy that, when creating a new version, does not directly copy all data, but instead shares the unchanged parts and stores only the changed parts independently. This significantly reduces the storage space consumption caused by frequent version creation.

[0119] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application can realize the historical traceability and time travel capability of dependency status by introducing a versioned snapshot mechanism to the topology graph. Furthermore, it enhances the interpretability and verifiability of topology conclusions by associating confidence with original data, thereby providing a key data foundation for fault review, compliance audit, and trend analysis.

[0120] In the process of interface changes, to further address how to control the depth of analysis to avoid unlimited expansion or excessive limitation, and how to flexibly adjust the granularity of analysis according to different scenarios (such as core service changes vs. edge service changes), this application provides an interface change risk management method based on multi-source evidence fusion, see [link to relevant documentation]. Figure 5 Step 300 in the interface change risk management method based on multi-source evidence fusion specifically includes the following: Step 310: When a change in the interface definition is detected, determine the target endpoint corresponding to the interface definition change.

[0121] Specifically, the system detects an interface definition change through continuous monitoring or receiving notifications. For example, when comparing the old and new versions of the OpenAPI description files, it was found that a field had been deleted from the response schema of the order service's query order details interface (path " / v1 / orders / {id}"). The system immediately identified the standardized endpoint identifier corresponding to this interface as the target endpoint for this change.

[0122] The target endpoint refers to the specific interface directly affected by this interface definition change. It serves as the logical starting point for subsequent impact analysis.

[0123] Step 320: Using the target endpoint as the starting node, perform a reverse breadth-first search or depth-first search on the service dependency topology graph; the search radius of the reverse breadth-first search or depth-first search is configurable.

[0124] Specifically, in the latest version of the service dependency topology graph, the system uses the node corresponding to the target endpoint as the starting node. The system then begins a reverse traversal based on a preset algorithm (e.g., breadth-first search) and a configurable search radius (e.g., radius set to 2).

[0125] First layer (radius=1): The system searches for all directed edges that directly point to the starting node. Suppose two edges are found, one from the user service's "retrieve user orders" endpoint ("svc.user#HTTP#GET# / v1 / users / {id} / orders") and the other from the payment service's "query payment status" endpoint. The system marks the nodes corresponding to these two endpoints as directly affected.

[0126] Second layer (radius = 2): The system uses the two nodes found in the previous layer as new starting points and continues to search backwards for edges pointing to them. For example, if it finds that the "Front-end Application" page endpoint calls the "Get User Order" interface of "User Service", the system marks the "Front-end Application" endpoint as indirectly affected.

[0127] The traversal process continues until the configured search radius limit is reached.

[0128] Breadth-first search (BFS) first explores all direct neighbors of the starting node, then explores the neighbors of those neighbors, making it suitable for evaluating the impact of layer-by-layer diffusion. Depth-first search (DFS) explores a path in depth, then backtracks to explore other paths.

[0129] The search radius is a configurable integer parameter that limits the depth or "number of jumps" of the reverse traversal. Radius = 1 means searching only the direct caller; radius = 2 means searching the direct caller and the caller's caller, and so on. This allows for a flexible trade-off between evaluation accuracy and computational overhead.

[0130] Step 330: Based on the search radius, traverse and collect all nodes that can reach the starting node directly or indirectly through the edge, and determine the endpoints corresponding to the collected nodes as the affected endpoints.

[0131] Specifically, the system collects all nodes visited during the traversal in step B (excluding the starting node itself). The endpoint identifiers corresponding to each of these nodes are then compiled into a list. This list contains all affected endpoints that directly or indirectly called the target endpoint. Affected endpoints are all endpoints within the given search radius that are above the target endpoint in the dependency chain; these are the potential targets of this change.

[0132] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application embodiment, by introducing a configurable search radius parameter, makes the impact range analysis flexible and controllable. It can achieve the best balance between analysis accuracy and efficiency according to the severity of the change and the business scenario, thereby realizing a more refined change impact assessment that is more in line with actual operation and maintenance needs.

[0133] During interface change processes, to further address how to objectively and quantitatively define the magnitude of the "impact"—that is, how to transform the abstract impact into a calculable and comparable specific value—to avoid subjective and biased assessments, this application provides an interface change risk management method based on multi-source evidence fusion. (See [link to relevant documentation]). Figure 5 The method for managing interface changes based on multi-source evidence fusion, after step 330 in step 300, further includes the following: Step 340: Obtain the historical call frequency index of each affected endpoint within a preset historical time period, compare the historical call frequency index with a preset traffic threshold, take the smaller value of the two, and then divide the smaller value by the traffic threshold to obtain the traffic weight.

[0134] Specifically, the system first obtains the historical call frequency metrics for each affected endpoint within a preset historical period (e.g., the past 7 days), such as the average queries per second (QPS), assumed to be 120. The system's preset traffic threshold is 100 (to avoid single-point traffic dominating the evaluation). The system sets Min(120,100)=100, then calculates 100 / 100=1, resulting in a traffic weight of 1 for that endpoint. If another affected endpoint has a QPS of 30, its traffic weight is Min(30,100) / 100=0.3.

[0135] The historical call frequency metric is a measure of the activity of the interface, typically expressed as average queries per second (QPS) or total number of calls.

[0136] The traffic threshold is a preset benchmark value used to normalize the call frequency and prevent excessively high-traffic interfaces from having an excessively large proportion in the calculation, thus making the evaluation more balanced.

[0137] Step 350: Obtain the preset business criticality for each of the affected endpoints.

[0138] Specifically, the system reads the pre-configured business criticality score for each affected endpoint from the pre-configured metadata. For example, the payment query interface of the payment service might be marked as a core business with a business criticality score of 1; the statistics interface of the reporting service might be marked as a general business with a business criticality score of 0.4. These values ​​are usually defined in advance by the architect or business owner based on business importance.

[0139] The business criticality is a preset numerical coefficient used to characterize the importance of the business functions carried by the endpoint, with core businesses (such as transactions) having the highest value.

[0140] Step 360: Based on the traffic weight, service level target weight, business criticality and edge confidence of each of the affected endpoints, calculate the individual impact weight corresponding to each of the affected endpoints; wherein, the service level target weight is determined in advance based on a preset allowable error rate, and the edge confidence is the confidence of the call relationship between the affected endpoint and the target endpoint.

[0141] Specifically, the system collects all the parameters required for computation for each affected endpoint: (1) Traffic weight: as calculated in the previous step (e.g., 1).

[0142] (2) Service Level Objective (SLO) Weight: The system calculates the weight based on the preset Service Level Objective (SLO) of the interface. For example, if the SLO requirement for this interface is 99.9% availability, that is, the allowable error rate is 0.1%. Then the SLO weight = 1 - allowable error rate = 1 - 0.001 = 0.999.

[0143] (3) Business criticality: as obtained in the previous step (e.g., 1).

[0144] (4) Edge confidence: The system queries the directed edge (e.g., 0.85) between the affected endpoint and the target endpoint from the service dependency topology graph.

[0145] The system then calculates the individual influence weights according to the formula: Individual impact weight = Traffic weight × SLO weight × Business criticality × Side confidence.

[0146] Substituting the values: 1 × 0.999 × 1 × 0.85 ≈ 0.849.

[0147] The Service Level Objective (SLO) weight is a coefficient derived from the service stability commitment, calculated as: 1 - allowable error rate. The more stringent the SLO requirements (the lower the allowable error rate), the closer this weight is to 1, indicating a higher sensitivity to changes in stability.

[0148] The edge confidence refers to the confidence level of the specific calling edge connecting the affected endpoint and the target endpoint in the dependency topology, reflecting the credibility of the dependency relationship.

[0149] The individual impact weight is a quantitative value that integrates traffic, stability requirements, business importance, and dependency credibility, representing the potential impact of this change on a specific caller.

[0150] Step 370: Sum the individual impact weights of all affected endpoints to obtain the impact surface score of the interface definition change.

[0151] Specifically, the system sums the individual impact weights of all affected endpoints calculated in step 360. For example, assuming there are three affected endpoints with weights of 0.849, 0.245, and 0.120 respectively, the impact score would be 0.849 + 0.245 + 0.120 = 1.214. This total score is the quantitative assessment result of the overall impact scope of this interface change.

[0152] The impact score is the arithmetic sum of the individual impact weights of all affected endpoints. It is a scalar value that intuitively reflects the overall potential risk of this interface change. The higher the score, the wider the scope of the change's impact or the deeper its impact on key business operations.

[0153] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application introduces a multi-dimensional and quantifiable calculation formula (comprehensive traffic, SLO, business criticality, confidence level) to transform the abstract impact of changes into a precise impact surface score, enabling risk assessment to move from qualitative to quantitative, greatly improving the objectivity, consistency and interpretability of impact assessment, and providing reliable data basis for accurate risk decision-making.

[0154] In the process of interface change, to further address the issues of balancing unified standards with flexible exceptions, and how to effectively translate risk assessment results into automated governance actions of varying degrees of stringency to form a management closed loop, this application provides an interface change risk management method based on multi-source evidence fusion. (See [link to relevant documentation]). Figure 6 Step 400 in the interface change risk management method based on multi-source evidence fusion specifically includes the following: Step 410: Match the interface definition change with the rules in the rule base; the rule base contains multiple rule levels with different priorities, including global rules, service-level rules and temporary exemption rules.

[0155] Step 420: Based on the highest priority rule matched, obtain and output the static risk assessment result of the interface definition change.

[0156] Specifically, the system will match the detected interface change details (e.g., service "svc.order", endpoint " / v1 / orders / {id}", change type "delete response field") with the rule base: (1) First, match the global rules and find a rule: "Delete any response field" leads to the static risk assessment result of "destructive change".

[0157] (2) Next, the service-level rules were matched, and a special rule was found for the service "svc.order": "The remark field of the / v1 / orders / {id} interface can be deleted" leads to the static risk assessment result of "non-destructive change". This rule has a higher priority than the global rules.

[0158] (3) Finally, the temporary exemption rules were checked and it was found that this submission was associated with an exemption form that was still valid, which allowed the deletion operation to be directed to a static risk assessment result of "allowed".

[0159] (4) The system adopts the result of the highest priority rule based on priority (temporary exemption > service level > global) and outputs the static risk assessment result of this change as "allowed".

[0160] The rule base is a collection that stores various risk assessment rules. Each rule defines the matching conditions (such as service, interface, change type) and the corresponding assessment result and action.

[0161] The rule hierarchy refers to the organization of rules into different levels to handle special cases and general situations. Global rules apply to all services; service-level rules are customized for specific services; temporary exemption rules are temporary permission instructions for a specific change and have the highest priority.

[0162] The static risk assessment result is a preliminary assessment based solely on the literal differences in the interface definition and pre-configuration rules, and has not yet incorporated runtime impact analysis.

[0163] Step 430: Based on at least two preset impact surface score thresholds, divide the numerical range into different risk level intervals.

[0164] Specifically, the system obtains the calculated impact score (e.g., 1.214). The system reads preset impact score thresholds, assuming: low-risk threshold = 1, high-risk threshold = 5.0. Based on this, the system divides the numerical range into three risk level intervals: [0,1) corresponds to low risk, [1,5.0) corresponds to medium risk, and [5.0,+∞) corresponds to high risk. The system matches the score 1.214 with the intervals, determining that it falls within the [1,5.0) interval, thus dynamically determining the risk level of this change as medium risk.

[0165] The impact surface score threshold is a critical value used to segment continuous impact surface scores. By setting different thresholds, it is possible to flexibly define which score range corresponds to which risk level. The risk level interval is a continuous numerical interval divided by the impact surface score threshold, and each interval maps to a specific risk level (such as high, medium, or low).

[0166] The matching process involves comparing the calculated score with a preset range of values ​​to determine the category to which the score belongs.

[0167] Step 440: Match the calculated impact surface score with each preset risk level interval to determine its corresponding risk level; wherein, the risk level interval is formed in advance by dividing the preset numerical range based on at least two impact surface score thresholds, and each risk level interval corresponds to a different risk level; wherein, each risk level includes high risk, medium risk and low risk.

[0168] Step 450: If the determined risk level is high risk, then execute control actions to block the code merging process or block the deployment process.

[0169] Specifically, if the risk level is determined to be high, the system will send a failure command to the continuous integration or continuous delivery pipeline. For example, if the change is in the Git merge request phase of a distributed version control system, the system will automatically block the code merge process and mark the merge request page as failed, explaining the reason. If the change has entered the deployment phase, the system will block the deployment process and pause the release.

[0170] The aforementioned blocking is a strict control action that refers to automatically causing a process to fail or be suspended, preventing changes from proceeding to the next stage. It is typically used in the highest-risk situations.

[0171] Step 460: If the determined risk level is medium risk, then execute the control action that triggers the manual approval process.

[0172] Specifically, for medium-risk changes, the system will not directly block them, but will trigger a manual approval process. It will create an approval task in the associated approval system (such as JIRA), specify the approver (such as the service owner or architect), attach a detailed change impact report, and pause the CI / CD pipeline, awaiting the approval result. Only after approval will the process continue.

[0173] Among them, access control approval is a control action that requires that changes must be explicitly approved by designated personnel before they can proceed, thus striking a balance between efficiency and security.

[0174] Step 470: If the determined risk level is low, then perform the control action of generating an alarm notification and allowing the process to continue.

[0175] Specifically, for low-risk changes, the system generates an alert notification (such as sending an email or instant message to the relevant developers) to inform them of the change and the low-risk assessment result, but at the same time allows the process to continue without interrupting code merging or deployment.

[0176] The alarm release is a control action that only notifies and records information without hindering automated processes, and is applicable to changes that have been assessed as having minimal impact.

[0177] For interface definition changes that are determined to be of medium or high risk, step 480 is also performed: generating and sending a change impact notification to the responsible party corresponding to the affected endpoint, and creating a work item in the project management system to track the processing status of the interface definition change.

[0178] Specifically, for medium- and high-risk changes, the system automatically generates a change impact notification and sends it to the service team leader corresponding to the affected endpoint via email or WeChat Work. Simultaneously, the system creates a work item in the project management system to track the processing status of the change (e.g., pending approval, compatible modification, live), and links the change details and impact report to this work item.

[0179] For interface definition changes that are determined to be low-risk, step 490 is also performed: during the transition period defined by the pre-configured compatibility window, backward compatibility support data is provided for the interface definition change; after the transition period ends, the backward compatibility support data automatically becomes invalid.

[0180] Specifically, for low-risk changes (such as adding optional fields), the system can configure a compatibility window (e.g., 30 days). During this window, the server-side code supports both the old and new interface formats (e.g., providing default values ​​when the old client does not transmit new fields). The system records the end time of the transition period. After the transition period ends, the system can automatically remove the compatibility logic or issue a strong warning. Backward compatibility supports data (such as default value configurations) being valid during the window period, after which it becomes invalid.

[0181] The compatibility window is a time-limited transition period set up for low-risk changes, allowing callers to gradually adapt and providing compatibility support between the old and new versions within the window. Backward compatibility support data refers to additional logic or configuration data (such as default values ​​and parameter filling rules) provided by the server during the compatibility window to enable callers with older versions to continue working normally.

[0182] As can be seen from the above description, the interface change risk management method based on multi-source evidence fusion provided in this application combines a hierarchical rule engine with dynamic judgment of quantitative scores to achieve accurate and flexible risk judgment; and through hierarchical control actions and automated governance linkage, the judgment results are seamlessly embedded into the development process, forming a complete automated governance closed loop from risk identification, assessment, decision-making to execution tracking, which greatly improves governance efficiency and effectiveness.

[0183] From a software perspective, this application also provides a system for implementing all or part of the interface change risk management method based on multi-source evidence fusion, see [link to relevant documentation]. Figure 7 The interface change risk management system based on multi-source evidence fusion specifically includes the following: The multi-source data standardization module 10 is used to standardize interface call data from multiple different types of evidence sources to obtain an endpoint set and a call relationship set. Each call relationship in the call relationship set is uniquely determined by the caller endpoint and the callee endpoint in an endpoint pair, and each call relationship is associated with a standardized data record from its corresponding evidence source.

[0184] The confidence assessment and dependency topology construction module 20 is used to fuse and calculate multiple standardized data records corresponding to the same endpoint pair from different evidence sources to obtain the confidence of the call relationship determined by the endpoint pair; call relationships with confidence scores higher than a preset threshold are used as edges, and endpoints in the endpoint set are used as nodes to construct a service dependency topology graph.

[0185] The change inspection and intelligent judgment module 30 is used to, when a change in the interface definition is detected, perform a reverse traversal on the service dependency topology graph starting from the target endpoint corresponding to the interface definition change, determine all affected endpoints that directly or indirectly call the target endpoint, obtain and aggregate the individual influence weights corresponding to each of the affected endpoints, and obtain the influence surface score of the interface definition change.

[0186] The risk level and process control module 40 is used to dynamically determine the risk level of the interface definition change based on the impact surface score; and to implement corresponding control actions on the execution process of the interface definition change in the continuous integration or continuous delivery process according to the risk level.

[0187] The embodiments of the interface change risk management system based on multi-source evidence fusion provided in this application can be used to execute the processing flow of the interface change risk management method based on multi-source evidence fusion in the above embodiments. Its functions will not be repeated here, but can be referred to the detailed description of the interface change risk management method based on multi-source evidence fusion in the above embodiments.

[0188] The interface change risk management system based on multi-source evidence fusion can perform the risk management portion based on multi-source evidence fusion in either a server or a client device. The choice can be made based on the processing capabilities of the client device and limitations of the user's usage scenario. This application does not impose any limitations in this regard. If all operations are performed in the client device, the client device may further include a processor for the specific processing of interface change risk management based on multi-source evidence fusion.

[0189] The aforementioned client device may have a communication module (i.e., a communication unit) that can communicate with a remote server to achieve data transmission with the server. The server may include a server on the task scheduling center side; in other implementation scenarios, it may also include a server on an intermediate platform, such as a server on a third-party server platform that has a communication link with the task scheduling center server. The server may include a single computer device, a server cluster consisting of multiple servers, or a distributed server structure.

[0190] The server and the client device can communicate using any suitable network protocol, including those not yet developed as of the date of this application. Such network protocols may include, for example, TCP / IP, UDP / IP, HTTP, HTTPS, etc. Furthermore, such network protocols may also include RPC (Remote Procedure Call Protocol) and REST (Representational State Transfer Protocol) protocols used on top of the aforementioned protocols.

[0191] As described above, the interface change risk management system based on multi-source evidence fusion provided in this application overcomes the inherent false positives or false negatives of a single evidence source (such as code analysis or call chain only) by fusing and standardizing data from various evidence sources (static, dynamic, etc.). Utilizing confidence calculation and threshold filtering, it effectively distinguishes between real, stable call relationships and noisy data, thereby constructing a high-accuracy, high-confidence service dependency topology graph, laying a reliable foundation for subsequent impact analysis. When an interface change is detected, this method does not perform a simple static rule comparison, but rather performs a reverse traversal based on the constructed high-confidence topology graph to accurately locate all directly or indirectly affected callers. By aggregating the individual impact weights of each affected party (combining historical call volume, business criticality, etc.), a quantified impact surface score is calculated. This transforms impact assessment from a qualitative judgment of whether or not there is an impact to a quantitative analysis of the extent of the impact, resulting in a more objective and accurate assessment. The risk level is dynamically determined based on the quantified impact surface score, and the judgment result is directly linked to the continuous integration or continuous delivery process, automatically executing corresponding control actions (such as blocking, approval access control, and alarms). This allows for the timely discovery and control of risks, significantly advancing the process from post-deployment failures to the pre-deployment code commit or build phase, forming an automated security defense. The combination of these effects fundamentally reduces online failures caused by destructive interface changes. By accurately identifying dependencies, intelligently assessing risks, and automatically intercepting high-risk changes upfront, the frequency and impact of related online incidents can be significantly reduced, ensuring the stability and delivery efficiency of systems under a microservice architecture.

[0192] To further illustrate the above embodiments, this application also provides an application example of an interface change risk management method based on multi-source evidence fusion. Through a specific e-commerce platform microservice scenario, it demonstrates how this method can be applied in practice, specifically including the following: 1. Scene setting Suppose an e-commerce platform contains the following core microservices: user service (svc.user), order service (svc.order), payment service (svc.payment), and frontend application (svc.frontend). Its key API call chain is as follows: when the frontend application displays order details, it calls the user service to retrieve user information, and the user service then calls the order service to retrieve order details.

[0193] 2. Change Triggering and Data Acquisition The order service developers modified the "Query Order Details" interface ( / v1 / orders / {id}), removing a field named couponInfo (coupon information) from the response body, and committed the code to the Git repository. This commit triggered the Continuous Integration (CI) process. The system of this invention detected this code commit event and immediately initiated multi-source evidence collection: (1) Static evidence source: The system extracts the interface definition change (deletion of the couponInfo field) from the code submitted this time through source code analysis.

[0194] (2) Dynamic evidence source: The system collected the call records from the call chain tracing system for the past week from the "user service to order service".

[0195] (3) Gateway evidence source: The system collected all access records to the order service interface from the application programming interface (API) gateway log.

[0196] (4) Source of registration evidence: The system confirmed from the service registration center that the order service, user service, etc. are in a healthy and available state.

[0197] 3. Data standardization processing The system standardizes the collected raw data. For example, it unifies paths like / v1 / orders / 12345 and / v1 / orders / 67890 in dynamic evidence into / v1 / orders / {id} through path template processing. Subsequently, the system generates endpoint identifiers for each interface, such as the query interface identifier for the order service and the relevant interface identifiers for the user service. Ultimately, the system forms an endpoint set containing all endpoints, as well as a call relationship set recording relationships such as "svc.user endpoint A called svc.order endpoint B".

[0198] 4. Confidence fusion calculation and topology construction The system discovered that the endpoint "User service calls order service details" exists in both static and dynamic evidence. The system calls a scoring function to score both pieces of evidence and combines them with adaptively adjusted weights (e.g., dynamic evidence has a higher weight) for fusion calculation. Simultaneously, the system considers the timeliness of the evidence and applies time decay to older records. The final calculated confidence level for this call relationship is 0.88, higher than the threshold of 0.7. Using this high-confidence relationship as an edge and related endpoints as nodes, the system constructs the current service dependency topology graph and generates a versioned snapshot (e.g., snapshot-20231027-01) for storage.

[0199] 5. Change Impact Analysis and Quantitative Assessment The system identifies the changed interface endpoint (svc.order#HTTP#GET# / v1 / orders / {id}) as the target endpoint. On the latest topology graph, the system uses this endpoint as the starting point and performs a reverse traversal (search radius set to 2). The traversal reveals: (1) Directly affected endpoint: “svc.user#HTTP#GET# / v1 / users / {id} / orders” (the “Get User Orders” interface of the user service).

[0200] (2) Indirectly affected endpoint: “svc.frontend#HTTP#GET# / page / orderDetail” (order details page of the front-end application).

[0201] The system then calculates individual impact weights for the two affected endpoints. For example, the user service endpoint has a traffic weight (calculated based on QPS) of 0.9, an SLO weight of 0.999, a business criticality of 0.8, and an edge confidence of 0.88 with the target endpoint, resulting in an individual impact weight of approximately 0.63. The front-end application endpoint has an individual impact weight of approximately 0.42. After aggregating the weights of both, the impact surface score for this change is 1.05.

[0202] 6. Intelligent risk assessment and automated governance The system first matches the change details against the rule base. A global rule determines that "deleting the response field" is a destructive change, but a service-level rule exempts the deletion of the couponInfo field. Therefore, the static risk assessment result is "low-risk potential damage".

[0203] Next, the system makes a dynamic judgment based on the calculated impact surface score (1.05). Since the score exceeds the low-risk threshold (1.0) but does not reach the high-risk threshold (5.0), the system ultimately determines the risk level as "medium risk".

[0204] Based on the medium risk level, the system triggers a manual approval process in the CI / CD workflow: automatically creates an approval task, assigns it to the person in charge of order service and user service, attaches a detailed change impact report, and suspends this deployment.

[0205] Simultaneously, the system performs governance coordination: (1) Automatically send change impact notifications to the heads of the user service and front-end application teams.

[0206] (2) Create a tracking work item in a project management system (such as JIRA).

[0207] (3) Since the static judgment is low-risk potential damage, the system suggests and can configure a compatibility window (such as 30 days), during which the order service can be temporarily compatible with the caller that is not adapted.

[0208] 7. Summary of Examples As demonstrated by the above examples, the method in this application intelligently evaluates a seemingly simple change involving the deletion of a field within a quantified runtime context constructed from multi-source evidence. It not only accurately identifies the directly affected party (user service) but also discovers the indirectly affected party (front-end application) and quantifies the overall impact (score 1.05). Ultimately, instead of mechanically blocking the change, it initiates a precise approval and notification process based on intelligent judgment, ensuring system stability while also considering development efficiency. This fully embodies the closed-loop governance capability of this application, from "perception" and "cognition" to "decision" and "action."

[0209] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the interface change risk management method based on multi-source evidence fusion mentioned in the above embodiments. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0210] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0211] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the interface change risk management method based on multi-source evidence fusion in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby implementing the interface change risk management method based on multi-source evidence fusion in the above method embodiments.

[0212] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0213] The one or more modules are stored in the memory, and when executed by the processor, the interface change risk management method based on multi-source evidence fusion in the embodiment is executed.

[0214] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0215] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0216] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0217] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of the aforementioned interface change risk management method based on multi-source evidence fusion. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, register, floppy disk, hard disk, removable storage disk, CD-ROM, or any other form of storage medium known in the art.

[0218] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned interface change risk management method based on multi-source evidence fusion.

[0219] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0220] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0221] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0222] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for managing interface change risks based on multi-source evidence fusion, characterized in that, include: Standardize the interface call data from various types of evidence sources to obtain the endpoint set and the call relationship set; Each call relationship in the set of call relationships is uniquely determined by the caller endpoint and the callee endpoint in an endpoint pair, and each call relationship is associated with a standardized data record from its corresponding source of evidence; Multiple standardized data records from different evidence sources corresponding to the same endpoint pair are fused and calculated to obtain the confidence level of the call relationship determined by the endpoint pair; the call relationships with confidence levels higher than a preset threshold are used as edges, and the endpoints in the endpoint set are used as nodes to construct a service dependency topology graph. When a change in the interface definition is detected, the service dependency topology graph is traversed in reverse from the target endpoint corresponding to the interface definition change to determine all affected endpoints that directly or indirectly call the target endpoint. Obtain and aggregate the individual impact weights corresponding to each of the affected endpoints to obtain the impact surface score of the interface definition change; Based on the impact score, the risk level of the interface definition change is dynamically determined; Based on the risk level, corresponding control actions are implemented during the execution of interface definition changes in the continuous integration or continuous delivery process.

2. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, Before standardizing the interface call data from various different types of evidence sources, the following steps are also included: Scheduled tasks executed according to a preset cycle, code commit or build completion events associated with continuous integration or continuous delivery processes, or on-demand collection instructions initiated by users, collect interface call data from various types of evidence sources. These various types of evidence sources include: static evidence sources, dynamic evidence sources, gateway evidence sources, and registration evidence sources. Static evidence sources provide interface declaration information extracted from program code or interface definition files; dynamic evidence sources provide interface call information extracted from data generated during software system runtime; gateway evidence sources provide access log data from application interface gateways; and registration evidence sources provide service instance information and routing configuration data from service registries. The static evidence sources include at least one of the following: source code analysis results, application programming interface (API) description files, or compilation and build artifacts; The dynamic evidence sources include at least one of the following: call chain tracing data, application programming interface (API) gateway access logs, or service registry information.

3. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, The standardization process for interface call data originating from various types of evidence sources yields an endpoint set and a call relationship set, including: The interface call data collected from different evidence sources is parsed to obtain the service identifier, protocol type, HTTP request method and original interface path of each interface; The original interface path is divided into a sequence of path segments by a delimiter. The path segments in the sequence that conform to a numeric pattern or a universally unique identifier pattern are identified. The identified path segments are replaced with the corresponding parameter placeholders. The replaced path segment sequences are then recombined to generate the standardized path template. Each of the interfaces is treated as different endpoints. The service identifier, protocol type, HTTP request method and standardized path template corresponding to each interface are concatenated to obtain the endpoint identifier of each interface, so as to form an endpoint set containing the endpoint identifier corresponding to each endpoint. Furthermore, the endpoint identifiers of the caller endpoint and the callee endpoint are extracted from the interface call data and associated with the corresponding evidence sources to form a call relationship set.

4. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, The step of fusing and calculating multiple standardized data records corresponding to the same endpoint pair but from different evidence sources to obtain the confidence level of the call relationship determined by the endpoint pair includes: Obtain each standardized data record corresponding to the same endpoint pair and its respective associated source of evidence; For each of the standardized data records, an initial score is calculated by calling a preset scoring function based on the type of the evidence source associated with it. Obtain adaptively adjustable weights corresponding to each type of evidence source; wherein, the adaptively adjustable weights are obtained based on periodic steps, the periodic steps including: obtaining a historical sample set containing verified real call relationships and false positive call relationships, calculating the accuracy of each type of evidence source in identifying call relationships in the historical sample set; and assigning normalized weights to each type of evidence source based on the accuracy as the current adaptively adjustable weights. A fusion score is obtained by weighting the initial score and the corresponding adaptively adjustable weights. Based on the time of the most recent occurrence among the multiple standardized data records, the time decay is calculated; the time decay is subtracted from the fusion score to obtain the confidence level of the endpoint for the determined call relationship.

5. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, The step of constructing a service dependency topology graph by using call relationships with confidence levels higher than a preset threshold as edges and endpoints in the endpoint set as nodes includes: Set each endpoint in the endpoint set as a node in the service dependency topology graph; Furthermore, each call relationship with a confidence level higher than a preset threshold is set as a directed edge in the service dependency topology graph connecting the node where its corresponding caller endpoint is located and the node where its corresponding callee endpoint is located; wherein each directed edge is associated with the confidence level of its corresponding call relationship and multiple standardized data records used to calculate the confidence level. Generate a versioned snapshot for the service dependency topology graph and store the versioned snapshot.

6. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, When a change in the interface definition is detected, the service dependency topology graph is traversed in reverse order, starting from the target endpoint corresponding to the interface definition change, to determine all affected endpoints that directly or indirectly call the target endpoint, including: When a change in the interface definition is detected, the target endpoint corresponding to the interface definition change is determined; Using the target endpoint as the starting node, a reverse breadth-first search or depth-first search is performed on the service dependency topology graph; the search radius of the reverse breadth-first search or depth-first search is configurable. Based on the search radius, traverse and collect all nodes that reach the starting node directly or indirectly through the edge, and determine the endpoints corresponding to each collected node as the affected endpoints.

7. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, The step of obtaining and aggregating the individual impact weights corresponding to each of the affected endpoints to obtain the impact surface score of the interface definition change includes: Obtain the historical call frequency index of each affected endpoint within a preset historical time period, compare the historical call frequency index with a preset traffic threshold, take the smaller value of the two, and then divide the smaller value by the traffic threshold to obtain the traffic weight. In addition, the business criticality preset for each of the affected endpoints is obtained; Based on the traffic weight, service level target weight, business criticality, and edge confidence of each affected endpoint, the individual impact weight corresponding to each affected endpoint is calculated; wherein, the service level target weight is determined in advance based on a preset allowable error rate, and the edge confidence is the confidence of the call relationship between the affected endpoint and the target endpoint; The individual impact weights of all affected endpoints are summed to obtain the impact surface score of the interface definition change.

8. The interface change risk management method based on multi-source evidence fusion according to claim 1, characterized in that, The risk level of the interface definition change is dynamically determined based on the impact surface score. Based on the aforementioned risk level, corresponding control actions are implemented during the execution of interface definition changes in the continuous integration or continuous delivery process, including: The interface definition change is matched with the rules in the rule base; the rule base contains multiple rule levels with different priorities, including global rules, service-level rules, and temporary exemption rules; Based on the highest priority rule matched, obtain and output the static risk assessment result of the interface definition change; Based on at least two preset impact score thresholds, the numerical range is divided into different risk level intervals; The calculated impact surface score is matched with each preset risk level interval to determine its corresponding risk level; wherein, the risk level interval is formed in advance by dividing the preset numerical range based on at least two impact surface score thresholds, and each risk level interval corresponds to a different risk level; wherein, each risk level includes high risk, medium risk and low risk. If the identified risk level is high, then control actions such as blocking the code merging process or blocking the deployment process will be implemented. If the determined risk level is medium risk, then the control action that triggers the manual approval process will be executed; If the determined risk level is low, then execute the control action of generating an alarm notification and allowing the process to continue; For interface definition changes that are determined to be of medium or high risk, a change impact notification is generated and sent to the responsible party corresponding to the affected endpoint, and a work item is created in the project management system to track the processing status of the interface definition change. For interface definition changes that are determined to be low-risk, backward compatibility support data is provided for the interface definition changes during the transition period defined in the pre-configured compatibility window; after the transition period ends, the backward compatibility support data automatically becomes invalid.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the interface change risk management method based on multi-source evidence fusion as described in any one of claims 1 to 8.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the interface change risk management method based on multi-source evidence fusion as described in any one of claims 1 to 8.

Images