Link traffic data processing method and device, electronic equipment and storage medium

Abstract

The invention relates to a link traffic data processing method and device, electronic equipment and a storage medium, and the method comprises the steps: determining traffic call description information of at least two call objects according to call link data generated by a service system in response to a service call request; the at least two calling objects comprise at least two of services, interfaces and links in the business system; comparing the difference between the traffic calling description information of each calling object, and determining the traffic calling amplification condition of each service; according to the resource consumption condition of each service and the traffic calling description information of each service, determining an abnormal service from each service; and inputting the resource consumption condition of the abnormal service and the traffic call amplification condition of the abnormal service into a pre-trained large model, and generating link optimization indication information of the abnormal service. According to the invention, the link flow management efficiency can be improved.

Description

Technical Field

[0001] This disclosure relates to the field of Internet technology, and in particular to a method, apparatus, electronic device and storage medium for processing link traffic data. Background Technology

[0002] With the rapid development of internet technology, distributed network architecture has become the mainstream choice for building large-scale business systems. In a distributed network architecture, a business request initiated by a user often needs to pass through multiple service nodes and call multiple interfaces in the backend system to be completed. These service nodes are interconnected through remote procedure calls and other methods, forming a complex call chain.

[0003] As business scales up, cost control of computing resources (such as server CPUs, memory, and bandwidth) becomes a key focus for enterprises. Given relatively fixed resource unit prices, optimizing service costs typically relies on improving resource utilization or service performance. However, in actual operation and maintenance, technicians have discovered that business systems often experience significant and unreasonable traffic consumption. This consumption is not caused by a natural increase in user requests, but rather stems from a phenomenon called "link traffic amplification" within the system. Link traffic amplification refers to a situation where, in a call chain, the downstream service receives far more requests than the upstream entry point, or a service is called far more times than expected. This is usually caused by issues such as duplicate requests, ineffective polling mechanisms, abnormal retry strategies, or circular calls in the code logic. This amplification brings multiple drawbacks: First, it leads to resource consumption being disproportionate to actual business value, resulting in huge cost waste, and due to the complexity of call relationships, it is difficult to quantify the cause; second, amplification increases the overall system load, easily triggering cascading failures in high-concurrency scenarios and reducing system stability; finally, redundant calls significantly increase interface response latency, directly deteriorating the end-user experience.

[0004] While traditional link traffic management methods can identify the location of link amplification anomalies, the link traffic management process still requires manual analysis and verification of the causes of the anomalies, formulation of management plans, and implementation of repairs. This manual-dependent management model is inefficient and cannot cope with large-scale traffic management needs, resulting in low efficiency in link traffic management. Summary of the Invention

[0005] This disclosure provides a link traffic data processing method, apparatus, electronic device, and storage medium to at least solve the problem of low link traffic management efficiency in related technologies. The technical solution of this disclosure is as follows:

[0006] According to a first aspect of the present disclosure, a link traffic data processing method is provided, comprising:

[0007] Based on the call chain data generated by the business system in response to business call requests, traffic call description information for at least two call objects is determined; the at least two call objects include at least two of the services, interfaces, and links in the business system; the link is used to characterize the call path of the business system to the service and / or the interface;

[0008] By comparing the differences in the traffic call description information of each of the called objects, the traffic call amplification of each of the services is determined; the traffic call amplification is used to characterize the traffic changes of the service being called in the link;

[0009] Based on the resource consumption of each service and the traffic call description information of each service, abnormal services are identified from each service; the resource consumption is used to characterize the resource consumption of the service in processing the business call request; the abnormal service is the service whose resource consumption meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition.

[0010] The resource consumption and traffic amplification of the abnormal service are input into the pre-trained large model to generate link optimization indication information for the abnormal service.

[0011] In one possible implementation, when the calling object includes a service, the traffic call description information includes the time when the query rate per second of the service reaches its peak, and the call status of each link to the service at that time;

[0012] When the calling object includes an interface, the traffic call description information includes the time when the query rate per second of the interface reaches its peak, and the call status of each link to the interface at that time;

[0013] When the calling object includes a link, the traffic call description information includes the time when the query rate per second of the link reaches its peak, and the call status of each service and / or interface on the link at that time.

[0014] In one possible implementation, comparing the differences between the traffic call description information of each of the calling objects to determine the traffic call amplification of each of the services includes:

[0015] The call amplification ratio of the upstream interface relative to the downstream interface is determined based on the ratio between the query rate per second of the upstream interface being called and the query rate per second of the downstream interface being called.

[0016] The call amplification ratio of the link inlet relative to the downstream interface is determined based on the ratio between the query rate per second of the link inlet and the query rate per second of the downstream interface of the link.

[0017] Based on the call amplification ratio, determine the traffic call amplification of each service.

[0018] In one possible implementation, the service traffic call description information includes the peak query rate per second of the service, and the service resource consumption includes the CPU core consumption of the service; the step of determining abnormal services from each of the services based on the resource consumption and traffic call description information of each service includes:

[0019] Construct a comparative relationship between the peak query rate per second of the service and the CPU core consumption trend;

[0020] If the trend comparison indicates that the CPU core consumption is increasing, but the peak query rate per second indicates that the service traffic is not increasing, then the service is determined to be the abnormal service.

[0021] In one possible implementation, after determining the traffic call description information of at least two calling objects based on the call chain data generated by the business system in response to the business call request, the method further includes:

[0022] If the peak query rate per second for the same interface on each of the aforementioned links increases by more than a first threshold within a preset time, an alarm message will be sent to the service to which the interface belongs.

[0023] or,

[0024] If the increase in traffic along the call path of the interface exceeds a second threshold within the preset time period, an alarm message will be sent to the service to which the interface belongs.

[0025] In one possible implementation, the step of inputting the resource consumption and traffic amplification of the abnormal service into a pre-trained large model to generate link optimization indication information for the abnormal service includes:

[0026] Based on the resource consumption of the abnormal service, the traffic amplification of the abnormal service, and the call code of the abnormal service, construct the prompt words;

[0027] The prompt words are input into the pre-trained large model; the prompt words are used to instruct the pre-trained large model to mine the link optimization strategy of the abnormal service from the traffic call amplification situation based on the call code, and to determine the amount of resource savings for the abnormal service to implement the link optimization strategy based on the resource consumption situation;

[0028] Obtain the link optimization indication information output by the pre-trained large model based on the prompt words; the link optimization indication information includes the link optimization strategy and the resource saving amount.

[0029] According to a second aspect of the present disclosure, a link traffic data processing apparatus is provided, comprising:

[0030] The description unit is configured to determine traffic call description information for at least two call objects based on the call chain data generated by the business system in response to a business call request; the at least two call objects include at least two of the services, interfaces, and links in the business system; the link is used to characterize the call path of the business system to the service and / or the interface;

[0031] The comparison unit is configured to compare the differences between the traffic call description information of each of the called objects to determine the traffic call amplification of each of the services; the traffic call amplification is used to characterize the traffic changes of the services being called in the link;

[0032] An exception unit is configured to determine an abnormal service from among the services based on the resource consumption status of each service and the traffic call description information of each service; the resource consumption status is used to characterize the resource consumption of the service in processing the business call request; the abnormal service is a service whose resource consumption status meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition.

[0033] The generation unit is configured to input the resource consumption and traffic amplification of the abnormal service into a pre-trained large model to generate link optimization indication information for the abnormal service.

[0034] According to a third aspect of the present disclosure, an electronic device is provided, including a memory and a processor, the memory storing a computer program, the processor executing the computer program to implement the link traffic data processing method as described in the first aspect or any possible implementation thereof.

[0035] According to a fourth aspect of the present disclosure, a storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the link traffic data processing method as described in the first aspect or any possible implementation thereof.

[0036] According to a fifth aspect of the present disclosure, a computer program product is provided, the program product including a computer program stored in a readable storage medium, wherein at least one processor of a device reads from the readable storage medium and executes the computer program, causing the device to perform the link traffic data processing method described in any possible implementation of the first aspect.

[0037] The technical solutions provided by the embodiments of this disclosure have at least the following beneficial effects:

[0038] Based on the call chain data generated by the business system in response to business call requests, traffic call description information for at least two call objects is determined. These at least two call objects include services, interfaces, and at least two types of links within the business system. A link characterizes the call path from the business system to a service and / or interface. By comparing the differences in traffic call description information between each call object, the traffic call amplification of each service is determined. Traffic call amplification characterizes the changes in traffic to a service within the link. Based on the resource consumption and traffic call description information of each service, abnormal services are identified. Resource consumption characterizes the resource consumption of a service in processing business call requests. Abnormal services are those whose resource consumption meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition. The resource consumption and traffic call amplification of abnormal services are input into a pre-trained large model to generate link optimization indication information for the abnormal services. In this way, by determining the traffic call description information of at least two types of call objects in the service, interface, and link based on the call link data of the business system, it is possible to comprehensively capture the traffic call characteristics of different dimensions. Then, by comparing the differences in the traffic call description information of each call object, the traffic call amplification of each service can be clarified, realizing the accurate identification and quantification of link traffic amplification phenomenon. Then, by combining the resource consumption of each service with the traffic call description information, abnormal services that meet the abnormal conditions in both resource consumption and traffic call are screened out, realizing the accurate location of abnormal services. Finally, the resource consumption and traffic call amplification of abnormal services are input into the pre-trained large model to generate link optimization indication information, automatically analyze the cause of the anomaly and generate targeted link traffic governance solutions, replacing the traditional mode of manually analyzing and verifying the cause of the anomaly and formulating governance solutions, thus improving the efficiency and accuracy of link traffic governance.

[0039] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0040] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure, and are not intended to unduly limit this disclosure.

[0041] Figure 1 This is an application environment diagram illustrating a link traffic data processing method according to an exemplary embodiment.

[0042] Figure 2 This is a flowchart illustrating a link traffic data processing method according to an exemplary embodiment.

[0043] Figure 3 This is a logical diagram illustrating a critical moment in link traffic according to an exemplary embodiment.

[0044] Figure 4 This is a schematic diagram illustrating a peak link QPS moment according to an exemplary embodiment.

[0045] Figure 5 This is a call diagram illustrating a service QPS peak moment according to an exemplary embodiment;

[0046] Figure 6 This is a call diagram illustrating the peak QPS of an interface according to an exemplary embodiment;

[0047] Figure 7 This is a flowchart illustrating another link traffic data processing method according to an exemplary embodiment;

[0048] Figure 8 This is a logic diagram illustrating an attribution process according to an exemplary embodiment;

[0049] Figure 9 This is a flowchart illustrating yet another link traffic data processing method according to an exemplary embodiment;

[0050] Figure 10 This is a block diagram illustrating a link traffic data processing apparatus according to an exemplary embodiment.

[0051] Figure 11 This is a block diagram illustrating an electronic device according to an exemplary embodiment. Detailed Implementation

[0052] To enable those skilled in the art to better understand the technical solutions of this disclosure, the technical solutions in the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings.

[0053] It should be noted that the terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this disclosure described herein can be implemented in orders other than those illustrated or described herein. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure.

[0054] It should also be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for display, data used for analysis, etc.) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties.

[0055] The link traffic data processing method provided in this disclosure can be applied to, for example... Figure 1 In the application environment shown, the electronic device 102 can be a single server, a distributed cluster containing multiple servers, or a cloud computing platform. In practical applications, the electronic device 102, as part of a big data platform, can connect to the distributed file storage system 104 (Hadoop Distributed File System, HDFS). Raw logs generated by the business system (including Nginx logs, RPC call logs, etc.) can be uploaded and stored in the distributed file storage system 104 via a log collection component, forming a structured big data table, instead of being intercepted in real time by the electronic device 102. The link traffic data processing method of this application can be an offline batch processing analysis based on this big data table.

[0056] In one embodiment, the electronic device 102 may include a data acquisition layer, an analysis and calculation layer, a monitoring and early warning layer, and an application governance layer. The data acquisition layer is used to collect raw data such as link logs, gateway logs, and business code libraries from the business system; the analysis and calculation layer is used to aggregate the raw data into data views in three dimensions: service dimension, interface dimension, and link dimension, to provide peak query rate per second and CPU core consumption statistics for each service, interface-level call frequency and resource usage distribution, and traffic transmission and cost allocation for end-to-end call paths; the monitoring and early warning layer is used for specific business logic analysis, such as cost attribution, traffic early warning, and generation of link optimization solutions; the application governance layer is used for user-oriented application scenarios, including traffic cost monitoring, service governance, and link rationality governance. Among them, service governance may include identifying and cleaning up service or application instances where the actual number of user requests is zero or close to zero during the statistical period, but still occupies computing resources and incurs costs.

[0057] In practical applications, electronic device 102 determines the traffic call description information of at least two calling objects based on the call chain data generated by the business system in response to business call requests. The at least two calling objects include services, interfaces, and links in the business system. The link is used to characterize the call path of the business system to services and / or interfaces. Electronic device 102 compares the differences between the traffic call description information of each calling object to determine the traffic call amplification of each service. The traffic call amplification is used to characterize the traffic changes of the service being called in the link. Electronic device 102 identifies abnormal services from each service based on the resource consumption of each service and the traffic call description information of each service. The resource consumption is used to characterize the resource consumption of the service in processing business call requests. An abnormal service is a service whose resource consumption meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition. Electronic device 102 inputs the resource consumption of the abnormal service and the traffic call amplification of the abnormal service into a pre-trained large model to generate link optimization indication information for the abnormal service.

[0058] Figure 2 This is a flowchart illustrating a link traffic data processing method according to an exemplary embodiment, such as... Figure 2 As shown, the link traffic data processing method is used in electronic device 102 and includes the following steps.

[0059] In step S210, based on the call chain data generated by the business system in response to the business call request, traffic call description information of at least two call objects is determined.

[0060] In practical applications, electronic devices can initiate pre-set scheduled tasks, such as a task that starts at midnight every day. This task can access a large data table of call logs stored on HDFS. This large data table records the call chain data of the business system. Based on this large data table, the electronic device can extract and aggregate data according to service, interface, and call chain dimensions.

[0061] The link is used to characterize the call path of the business system to services and / or interfaces.

[0062] In this context, a business system refers to a computer system that provides specific business functions. This system may include multiple service nodes, each providing a specific service function. A business call request is a request initiated by a user or other external system to the business system to obtain data, perform operations, or invoke specific functions. When a business system receives a business call request, it needs to coordinate the processing of multiple internal service nodes to complete the response. During the processing of business call requests, calling relationships occur between the various services within the business system; that is, in order to complete its own processing tasks, a service needs to call the interfaces provided by other services to obtain the required data or perform specific functions.

[0063] Call chain data refers to the call record data generated by the business system in response to business call requests. This call record data may include the internal transmission path and call relationships within the business system. Optionally, call chain data can be generated by the log collection component in the business system. This component records call-related information each time a service call occurs, including but not limited to the time of the call, the identifier of the calling service, the identifier of the called service, the identifier of the called interface, and the query rate per second of the call.

[0064] The calling object can refer to an entity in the business system that participates in the business call. At least two calling objects must be included, specifically services, interfaces, and call chains within the business system. In practical applications, a service refers to an independently deployed functional module within the business system; each service can provide one or more interfaces for other services to call. An interface is the external call entry point exposed by a service, typically corresponding to a method or a group of methods within the service. A call chain refers to the path along which a business call request is passed within the business system, representing the calling relationship between the business system and services and / or interfaces.

[0065] Traffic call description information refers to information describing the invocation status of the invoked objects. This information may include the invocation frequency, invocation time, and invocation source of the invoked objects. Traffic call description information is used to characterize the traffic features of the business system from different dimensions. Optionally, traffic call description information also includes invocation relationship information between invoked objects. This invocation relationship information records the upstream and downstream relationships of the invoked objects, as well as the invocation frequency between upstream and downstream. By recording invocation relationship information, a complete invocation topology graph can be constructed, laying the foundation for subsequent traffic amplification analysis.

[0066] In practice, the electronic device obtains call chain data from the log collection system of the business system. This call chain data exists in the form of call logs, recording information such as the caller, the called party, the call time, and the call result for each call. The electronic device processes the obtained call chain data to extract at least two dimensions of traffic call description information, with each dimension corresponding to a call object.

[0067] Optionally, for the service dimension, the electronic device counts the number of times each service is called within a unit of time, determining the query rate per second for each service, which serves as the traffic call description information for the service dimension. For the interface dimension, the electronic device counts the number of times each interface is called within a unit of time, determining the query rate per second for each interface, which serves as the traffic call description information for the interface dimension. For the link dimension, the electronic device constructs call paths based on call relationships, counts the number of times each link is called within a unit of time, determines the query rate per second for each link, and serves as the traffic call description information for the link dimension.

[0068] Queries per second (QPS) is the amount of request data (for generating inference results) processed per unit of computing resources per unit of time. It can be used as a metric for how much traffic a specific query server processes within a given time period.

[0069] As an example, electronic devices can aggregate call link data according to service, interface, and link dimensions to generate traffic call description information. Specifically, electronic devices can aggregate call link data according to a preset time granularity, which can be set to the minute level. That is, the electronic device aggregates call link data once per minute, generating traffic call description information for each call object within that minute. By aggregating call link data across multiple dimensions to generate traffic call description information for at least two of the service, interface, and link dimensions, query and analysis efficiency can be significantly improved while ensuring analytical accuracy.

[0070] In step S220, the differences between the traffic call description information of each calling object are compared to determine the traffic call amplification of each service.

[0071] Traffic amplification is used to characterize the changes in traffic to services within a call chain. In practical applications, traffic amplification refers to a disproportionate increase in the number of calls to downstream services relative to the number of calls to upstream services within a call chain. Traffic amplification occurs when a service is called multiple times in the chain, or when calls to that service trigger more calls to downstream services. Traffic amplification can be quantified by the call amplification ratio, which is the ratio of the queries per second (MS / MS) of downstream calls to the queries per second (MS / MS) of upstream calls.

[0072] As an example, an electronic device can extract query rate per second (MRS) data from the traffic call description information of each calling object. For two adjacent interfaces in a link, the electronic device calculates the ratio between the MRS of the downstream interface and the MRS of the upstream interface; this ratio is the call amplification ratio of the upstream interface relative to the downstream interface. For example, suppose the link includes interface A and interface B, and interface A calls interface B. If at a certain moment, the MRS of interface A is 1000 and the MRS of interface B is 2000, then the call amplification ratio of interface A relative to interface B is 2. This means that for every call to interface A, interface B will be called twice.

[0073] As another example, an electronic device can calculate the call amplification ratio of a link entry point relative to each interface in the link. A link entry point is the point where a user or other system initiates a request to the business system. The electronic device calculates the ratio between the query rate per second of the link entry point and the query rate per second of each interface in the link; this ratio is the call amplification ratio of the link entry point relative to that interface. For example, assuming the query rate per second of the link entry point is 1000, and the query rate per second of a certain interface in the link is 5000, then the call amplification ratio of the link entry point relative to that interface is 5. This means that each user request entering the system will result in that interface being called 5 times.

[0074] In practice, the electronic device determines the traffic amplification of each service based on the calculated call amplification ratios. The electronic device can generate a traffic amplification report, which includes information such as the call amplification ratio, call path, and call frequency for each service. Through this report, operations and maintenance personnel can intuitively understand the traffic amplification of each service in the network and identify services with abnormal amplification.

[0075] It's important to note that in real-world business systems, traffic amplification can be caused by a variety of reasons. For example, circular calls within the service may lead to repeated calls to downstream services; abnormal retry logic within the service may cause numerous retries to downstream services upon failure; or invalid polling may result in frequent calls to downstream services. Analyzing traffic amplification can help identify these abnormal call patterns, providing a basis for subsequent service optimization.

[0076] Optionally, the electronic device can also visualize the traffic amplification situation. The device generates a call topology map, which graphically displays the call relationships and amplification ratios between services. In the call topology map, services are represented as nodes, and the call relationships between services are represented as lines, with the amplification ratio marked on the lines. Through the call topology map, operations personnel can more intuitively understand the traffic transmission in the link and quickly locate locations with abnormal amplification.

[0077] In step S230, abnormal services are identified from each service based on the resource consumption of each service and the traffic call description information of each service.

[0078] Resource consumption is used to characterize the resource consumption of a service in processing business call requests. Specifically, resource consumption refers to the computing resources consumed by the service during the processing of business call requests, including but not limited to the consumption of Central Processing Unit (CPU) cores, memory, network bandwidth, and disk input / output (I / O) resources. Resource consumption reflects the service's load and cost.

[0079] Among them, abnormal services are those whose resource consumption meets the abnormal resource consumption conditions and whose traffic call description information meets the abnormal traffic call conditions. Abnormal resource consumption conditions refer to conditions where the service's resource consumption shows an abnormal increase; for example, the increase in the service's CPU core consumption exceeds a preset threshold within a preset time period. Abnormal traffic call conditions refer to conditions where the service's traffic call behavior is abnormal; for example, the service's peak query rate per second does not show a significant increase, or the increase is lower than a preset increase threshold.

[0080] In practice, electronic devices can obtain resource consumption information for each service from a resource monitoring system. This system can monitor the resource usage of each service in real time, including metrics such as CPU utilization and memory utilization. The electronic devices then correlate the resource consumption of each service with its traffic call descriptions to identify any abnormal services.

[0081] As an example, if, based on the resource consumption of each service and the traffic call description information of each service, it is determined that the increase in resource consumption of a certain service is much greater than the increase in business traffic, then it can be determined that the service may have an anomaly, such as code degradation, link call amplification, etc., and electronic devices can mark the service as an abnormal service.

[0082] As another example, resource consumption includes CPU core consumption, and traffic call description information includes peak queries per second. The electronic device can calculate the historical ratio between the service's CPU core consumption and peak queries per second, representing the number of CPU cores required to process a unit of traffic. The electronic device compares the current ratio with the historical ratio; if the difference between the current ratio and the historical ratio is greater than a threshold, the service is deemed abnormal.

[0083] It's important to note that determining whether a service is abnormal relies not only on resource consumption but also on a comprehensive assessment of traffic call descriptions. This is because increased resource consumption can be caused by various factors, including normal growth in business traffic, service configuration changes, and infrastructure modifications. Only when resource consumption increases without a corresponding increase in business traffic can the service be considered abnormal.

[0084] Optionally, the electronic device can further filter abnormal services based on traffic amplification. After initially filtering abnormal services based on resource consumption and traffic call description information, the electronic device can further filter out services whose call amplification ratio exceeds a preset amplification threshold, and these services will be the final identified abnormal services. These services not only have abnormal resource consumption but also exhibit significant traffic amplification issues, and can be prioritized for remediation.

[0085] In step S240, the resource consumption and traffic amplification of the abnormal service are input into the pre-trained large model to generate link optimization indication information for the abnormal service.

[0086] In this context, a pre-trained large model refers to an artificial intelligence model that has been pre-trained on a large scale of data, possessing powerful language understanding and code analysis capabilities. Optionally, the pre-trained large model can be a large language model based on the Transformer architecture, such as the GPT series models or the BERT series models.

[0087] For example, the link optimization indication information may include link optimization suggestions, such as merging calls, batching, caching / prefetching, retries and timeout reconfiguration, as well as estimated benefits. Optionally, the link optimization suggestions can be distributed for canary testing to observe the amplification ratio, cost and performance indicators, and write back the results after success, forming a continuous optimization closed loop.

[0088] In practice, electronic devices can generate structured data based on the resource consumption and traffic amplification of abnormal services. This structured data may include the identification information of the abnormal service, numerical data on resource consumption, numerical data on traffic amplification, and the topology of the call chain. Then, this structured data is input into a pre-trained large model. The pre-trained large model can parse and analyze this structured data, identify the potential causes of traffic amplification, and generate targeted optimization suggestions based on learned knowledge and experience, serving as link optimization instructions.

[0089] In the above-mentioned link traffic data processing method, by determining the traffic call description information of at least two types of call objects in the service, interface, and link based on the call link data of the business system, it can comprehensively capture traffic call characteristics of different dimensions. Then, by comparing the differences in the traffic call description information of each call object, the traffic call amplification of each service is clarified, realizing the accurate identification and quantification of link traffic amplification phenomenon. Then, by combining the resource consumption of each service with the traffic call description information, abnormal services that meet the abnormal conditions in both resource consumption and traffic call are screened out, realizing the accurate location of abnormal services. Finally, the resource consumption and traffic call amplification of abnormal services are input into the pre-trained large model to generate link optimization indication information, automatically analyze the cause of the anomaly and generate targeted link traffic governance solutions, replacing the traditional mode of manually analyzing and verifying the cause of the anomaly and formulating governance solutions, thus improving the efficiency and accuracy of link traffic governance.

[0090] In an exemplary embodiment, when the invoked object includes a service, the traffic invocation description information includes the time when the service's query rate per second reaches its peak, and the invocation status of each link to the service at that time;

[0091] When the calling object includes an interface, the traffic call description information includes the time when the interface's query rate per second reaches its peak, and the call status of each link to the interface at that time;

[0092] When the calling object includes a link, the traffic call description information includes the time when the link's query rate per second reaches its peak, and the call status of each service and / or interface on the link at that time.

[0093] In practical applications, the amount of data involved in call chain data is generally quite large. Analyzing traffic anomalies directly by querying call chain data would be extremely slow. Therefore, it's beneficial to focus on three key moments in traffic data: the moment when the service's query rate per second reaches its peak (i.e., the service's peak QPS moment), the moment when the interface's query rate per second reaches its peak (i.e., the interface's peak QPS moment), and the moment when the chain's query rate per second reaches its peak (i.e., the chain's peak QPS moment). These three key moments provide a complete picture of the traffic situation. Specifically, the link peak QPS moment provides the call status of all nodes along the entire chain; each chain corresponds to a peak QPS moment, and these peak moments may differ between chains. The service peak QPS moment provides the call status of all chains for that service; the service peak QPS moment may or may not be the peak moment of the chain containing that service. The interface peak QPS moment provides the call status of all chains for that interface; the interface's peak moment may or may not be the peak moment of the service to which that interface belongs.

[0094] For the convenience of those skilled in the art, Figure 3 An example is provided: a logical diagram of critical moments in link traffic. Figure 3 The data illustrates the call topology between the link intersection, service A, service B, and interface D, and marks different times. In practical applications, these three key times can be identified from the call link data, and the traffic call information at these key times can be extracted.

[0095] The peak query rate per second refers to the moment when the calling object is called most frequently within a day. This moment reflects the maximum load on the calling object and is an important reference for analyzing traffic characteristics.

[0096] In practice, electronic devices can count the query rate per second for each called object at various times within a preset time period (such as within a day).

[0097] For example, at the service level, the electronic device calculates the query rate per second (ms) of the service at various times within a preset time period, identifies the maximum ms of query rate per second within a day and its corresponding time, which is the moment when the service's ms of query rate per second reaches its peak. The electronic device further records the call status of the service by each link at this peak moment, including the number of calls and call frequency of each link.

[0098] For example, at the interface level, the electronic device uses a similar method to determine the interface's traffic call description information. The electronic device calculates the query rate per second (QPS) of the interface at various times within a preset time period, identifies the maximum QPS and its corresponding time, and this time is the moment when the interface's QPS reaches its peak. The electronic device records the call status of each link to the interface at this peak time.

[0099] It's important to note that the peak time for a service may differ from the peak time for an interface. This is because a service can include multiple interfaces, and different interfaces may reach their peak at different times. Similarly, for a particular interface, its peak time may be the peak time for some connections, or it may not be the peak time for others.

[0100] For example, at the link level, the electronic device calculates the query rate per second (ms) of the link at various times within a preset time period, identifies the maximum ms and its corresponding time, and this time is the moment when the link's ms reaches its peak. The electronic device records the call status of each service and / or interface on the link at this peak time, including the ms at the link ingress, the ms of each node in the link, and the call relationships between the nodes.

[0101] Optionally, the electronic device can identify the call diffusion status of each node in the link based on the call status of services and interfaces in the link. Call diffusion refers to the situation where a node is called by multiple branch paths. The electronic device can count the number of paths that call each node in the link. If a node is called by multiple paths, then the call diffusion status of that node exists. Call diffusion will lead to an amplification of traffic to that node.

[0102] Optionally, the electronic device can also determine the upstream and downstream relationships between calling objects based on the call information of services and interfaces in the link. For two adjacent nodes in the link, the electronic device records the identification information of the upstream node and the downstream node, as well as the call relationship between the upstream node and the downstream node. The node identification information may include service name, interface name, method name, etc.

[0103] In one embodiment, the electronic device stores the determined traffic call description information in a database, forming a service dimension view, an interface dimension view, and a link dimension view. Figure 3 These three data tables serve as the foundational data source for subsequent analyses, including flow amplification analysis and cost attribution analysis.

[0104] The technical solution of this application embodiment, by recording the peak times and corresponding call details in three dimensions, enables the electronic device to comprehensively characterize the traffic features of the business system from different perspectives. The data in these three dimensions complement each other, jointly constituting complete traffic call description information, thus improving the reliability of traffic data processing; furthermore, key information can be extracted from massive amounts of call chain data, improving the efficiency of traffic data processing.

[0105] For the convenience of those skilled in the art, Figure 4 An exemplary schematic diagram of the peak QPS of a link is provided. Figure 4 In this scenario, the system can record the peak QPS at the ingress point of the chain throughout the day, as well as the call data from all upstream service methods to downstream service interfaces. The ingress point branches downwards into specific interface paths, which then extend downwards to specific downstream services and interfaces. Figure 4 It records the call status of all upstream and downstream nodes in the entire chain at the moment when the ingress QPS reaches the peak of the day.

[0106] For the convenience of those skilled in the art, Figure 5 An exemplary diagram illustrating peak service QPS is provided. Figure 5 In this scenario, the peak QPS moment when each service is called can be recorded, as well as the call data of the specific interfaces of each upstream service to this service interface. The top shows the upstream interfaces that call service A, and the bottom shows the downstream interfaces called by service A. The focus is on the traffic situation when a specific service (such as service A) is the callee and its load reaches its maximum.

[0107] For the convenience of those skilled in the art, Figure 6 An exemplary diagram illustrating the peak QPS of an interface is provided. Figure 6 In this scenario, call data from each upstream interface to the downstream interface can be recorded for each link. For a specific interface (such as interface B1), even if the overall service load does not reach its peak, that interface may experience a QPS peak due to the superposition of specific upstream calls.

[0108] In one exemplary embodiment, such as Figure 7 As shown, in step S220, the differences between the traffic call description information of each calling object are compared to determine the traffic call amplification of each service. This can be achieved through the following steps:

[0109] In step S711, the call amplification ratio of the upstream interface relative to the downstream interface is determined based on the ratio between the query rate per second of the upstream interface being called and the query rate per second of the downstream interface being called.

[0110] In this context, upstream interfaces refer to interfaces located upstream in the call chain, while downstream interfaces refer to interfaces located downstream in the call chain. Upstream interfaces call downstream interfaces. The query rate per second (QPS) of upstream interfaces refers to the frequency at which upstream interfaces are called during peak times, and the query rate per second of downstream interfaces refers to the frequency at which downstream interfaces are called during the same peak times.

[0111] The call amplification ratio of the upstream interface relative to the downstream interface refers to the ratio of the queries per second (MS / s) of the downstream interface to the queries per second (MS / s) of the upstream interface. The call amplification ratio reflects the degree of traffic amplification from the upstream interface to the downstream interface. If the call amplification ratio is greater than 1, it indicates that there is traffic amplification from the upstream interface to the downstream interface; if the call amplification ratio is equal to 1, it indicates that the traffic remains unchanged; if the call amplification ratio is less than 1, it indicates that the traffic has decreased.

[0112] In practical applications, electronic devices can extract the call topology of a link from traffic call description information, determining the upstream and downstream relationships between interfaces in the link. The electronic device traverses each pair of adjacent interfaces in the link, extracting the query rate per second (ms) of the upstream interface and the query rate per second of the downstream interface for each pair. The electronic device calculates the ratio between the query rate per second of the downstream interface and the query rate per second of the upstream interface; this ratio is the call amplification ratio of the upstream interface relative to the downstream interface. The electronic device then associates and stores the calculated call amplification ratio with the corresponding interface information.

[0113] In step S712, the call amplification ratio of the link entry relative to the downstream interface is determined based on the ratio between the query rate per second of the link entry and the query rate per second of the downstream interface of the link.

[0114] The link ingress point refers to the entry point where a user or other system initiates a request to the business system; it corresponds to the starting node of the link. The query rate per second of the link ingress point refers to the frequency of requests received by the link ingress point at its peak.

[0115] The call amplification ratio of the ingress link relative to the downstream interface refers to the ratio between the query rate per second of the downstream interface and the query rate per second of the ingress link. This call amplification ratio reflects the overall traffic amplification from the ingress link to the downstream interface and can measure the number of downstream interface calls triggered by a single user request within the system.

[0116] In practical applications, electronic devices can extract the query rate per second (RPS) of the link ingress from the traffic call description information. The electronic device iterates through each interface in the link, and for each interface, extracts the RPS of the interface calls. The electronic device calculates the ratio between the RPS of the interface calls and the RPS of the link ingress; this ratio is the call amplification ratio of the link ingress relative to that interface. The electronic device then associates and stores the calculated call amplification ratio with the corresponding interface information.

[0117] In step S713, the traffic call amplification of each service is determined based on the call amplification ratio.

[0118] In practice, the amplification ratio of each call corresponding to the service can be used as the traffic amplification of the service.

[0119] The service traffic amplification can include the call amplification ratio of the upstream interface relative to the downstream interface, and the call amplification ratio of the link entry point relative to the downstream interface.

[0120] For example, an electronic device can aggregate the call amplification ratios of various services to obtain the traffic call amplification of the service. For instance, service F includes upstream interface A and downstream interface B, and the link where service F is located includes link C; then, the traffic call amplification of service F can include the call amplification ratio of upstream interface A relative to downstream interface B, and the call amplification ratio of the entry point of link C relative to downstream interface B.

[0121] The technical solution of this application embodiment can comprehensively and accurately determine the traffic amplification of each service by calling the amplification ratio, thereby improving the efficiency and reliability of subsequent abnormal service identification and link optimization.

[0122] In an exemplary embodiment, the service's traffic call description information includes the service's peak query rate per second, and the service's resource consumption includes the service's CPU core consumption. Based on the resource consumption of each service and the traffic call description information of each service, abnormal services are identified from each service, including:

[0123] Construct a comparative relationship between the peak query rate per second and the CPU core consumption of the service; if the comparative relationship indicates that the CPU core consumption is increasing, but the business traffic indicated by the peak query rate per second is not increasing, the service is determined to be an abnormal service.

[0124] Among them, the peak query rate per second refers to the maximum frequency at which the service is called within a day, reflecting the service's business traffic. CPU core consumption refers to the number of CPU cores used by the service, reflecting its resource consumption. The trend comparison shows the changes in the peak query rate per second and CPU core consumption over time; optionally, this trend comparison can be displayed using a trend comparison chart.

[0125] In practice, the electronic device aligns the peak query rate per second and CPU core consumption data by time to construct time series data. Based on this time series data, the electronic device can generate a trend comparison chart. This chart plots time on the horizontal axis and peak query rate per second and CPU core consumption on the vertical axis, showing the changing trends of peak query rate per second and CPU core consumption, respectively.

[0126] Optionally, the electronic device can also perform quantitative analysis of the changing trends. Specifically, it can calculate the growth rate of the peak query rate per second and the growth rate of CPU core consumption. By calculating the growth rate, the magnitude of change in these two indicators can be quantitatively assessed.

[0127] An upward trend in CPU core consumption can refer to a continuous increase in CPU core consumption within a preset time period or an increase exceeding a preset threshold. A non-increasing trend in business traffic means that the peak query rate per second remains stable or increases very little within a preset time period. The preset increase threshold is a threshold used to determine whether business traffic has increased significantly. This threshold can be set according to actual business conditions, for example, to 10% or 20%.

[0128] It should be noted that if CPU core consumption shows an upward trend, while business traffic does not show an upward trend or the increase is relatively small, the electronic device will determine that the service is abnormal. This situation indicates that the increase in service resource consumption is not matched with the increase in business traffic, which may be due to issues such as code degradation, amplified call chains, or unreasonable configuration.

[0129] The technical solution of this application embodiment can accurately identify services with abnormal resource consumption and abnormal traffic calls by constructing a comparison relationship of change trends, thereby improving the accuracy and efficiency of subsequent link optimization.

[0130] In one exemplary embodiment, after determining the traffic call description information of at least two calling objects based on the call chain data generated by the business system in response to the business call request, the method further includes:

[0131] If the peak query rate per second for the same interface on each link increases by more than a first threshold within a preset time, an alarm message will be sent to the service to which the interface belongs; or, if the traffic on the call path of the interface increases by more than a second threshold within a preset time, an alarm message will be sent to the service to which the interface belongs.

[0132] The preset time can be a time window used to compare traffic changes, such as one day.

[0133] The first magnitude threshold can refer to the threshold used to determine whether the traffic has increased significantly, for example, 20%.

[0134] Alarm messages are messages used to notify operations and maintenance personnel of abnormal traffic increases. These messages can be sent via messaging systems, emails, SMS, etc.

[0135] In practice, the electronic device periodically analyzes traffic call description information, for example, once a day. The electronic device extracts the peak query rate per second (PSR) data for each link to the same interface within the current time window, as well as the peak PSR data for each link to the same interface within the previous time window. The electronic device calculates the increase in PSR between the current and previous time windows. The formula for calculating the increase is: (Current peak PSR - Previous time window peak PSR) / Previous time window peak PSR × 100%.

[0136] The electronic device determines whether the increase in query rate exceeds a first threshold. If the increase exceeds the first threshold, an alarm is generated. Optionally, the alarm information includes the interface's identifier, the current peak query rate per second, the peak query rate per second in the previous time window, and the increase rate. Then, the service to which the interface belongs is determined, and the alarm information is sent to the operations and maintenance personnel of that service.

[0137] Optionally, the electronic device can also set a change threshold to filter out cases with small absolute changes. Even if the increase exceeds a first threshold, the electronic device will not send an alarm if the change is below the change threshold. This is to avoid false alarms due to a large relative rate of change when the base is very small. For example, an alarm will only be sent if the peak query rate per second for all links to the same interface increases by 20% compared to yesterday and the change is greater than 40. In other words, the electronic device will send an alarm to the service to which the interface belongs if the peak query rate per second for all links to the same interface increases by more than a first threshold within a preset time, and the peak query rate per second is greater than the change threshold.

[0138] The call path of the interface refers to the call chain containing the interface, and the traffic of the call path can be represented by the queries per second of the call chain. The second magnitude threshold is a threshold used to determine whether the traffic of the call path has increased significantly. This threshold can be the same as or different from the first magnitude threshold, for example, it can be set to 20%.

[0139] In practice, the electronic device extracts traffic data from the call paths of the interface within the current time window, as well as traffic data from the call paths of the interface within the previous time window. The electronic device calculates the increase in call path traffic between the current and previous time windows. The electronic device then determines whether the increase exceeds a second threshold. If the increase exceeds the second threshold, the electronic device generates an alarm and sends the alarm to the operations and maintenance personnel of the service to which the interface belongs.

[0140] The technical solution of this application embodiment, through a traffic early warning mechanism, can promptly issue alerts when traffic anomalies occur, reducing the time cost of attribution analysis for traffic increases and improving the stability and reliability of traffic management.

[0141] In one exemplary embodiment, the resource consumption and traffic amplification of the abnormal service are input into a pre-trained large model to generate link optimization indication information for the abnormal service. This includes: constructing prompt words based on the resource consumption, traffic amplification, and call code of the abnormal service; inputting the prompt words into the pre-trained large model; and obtaining the link optimization indication information output by the pre-trained large model based on the prompt words.

[0142] The calling code can refer to the source code related to the chain call in the abnormal service, including the calling logic of downstream services, retry logic, batch processing logic, caching logic, etc.

[0143] Specifically, the cue words are used to instruct the pre-trained large model to extract link optimization strategies for abnormal services from traffic amplification based on the calling code, and to determine the resource savings of implementing link optimization strategies for abnormal services based on resource consumption. The cue words can refer to text used to guide the pre-trained large model in generating link optimization instruction information, which organizes various information about abnormal services in a structured manner.

[0144] In practice, the electronic device can first obtain the call code of the abnormal service from the code repository of the business system. The code repository can be a version control system, such as a Git repository. Based on the identification information of the abnormal service, the electronic device locates the service in the code repository and extracts code snippets related to the call chain. Optionally, the electronic device can analyze the call chain data to determine which methods or interfaces in the abnormal service are involved in the traffic amplification problem, and extract the source code of these methods or interfaces as part of the call code.

[0145] For example, the prompt may include background information, call chain data, call entry information, key link call code, and task description. Background information may include basic information about the abnormal service, such as service name, service function, and service location within the business system. Call chain data may include fields such as the main control point, the controlled point, entry point query rate per second, call query rate per second, call amplification ratio, and entry point call amplification ratio. Call entry information may include the entry point of the abnormal call, such as the entry service name, entry interface path, and entry point query rate per second. Key link call code may include source code snippets related to the call chain in the abnormal service. The task description may include the task that the pre-trained large model needs to complete; for example, the task description could be: "Based on the above information, analyze the reasons for the traffic call amplification in the code, propose specific optimization suggestions, and estimate the number of CPU cores that can be saved after implementing the optimization suggestions."

[0146] Among them, pre-trained large models refer to artificial intelligence models that have been pre-trained on large-scale data and possess powerful language understanding and code analysis capabilities. These models can understand task requirements described in natural language, analyze code logic, and generate optimization suggestions that meet the requirements.

[0147] After receiving prompts, the pre-trained large model parses the prompts to extract key information such as task background, data information, code logic, and task requirements. The pre-trained large model first analyzes the calling code to identify the calling logic and control structure within the code.

[0148] The pre-trained large-scale model, combined with call chain data, analyzes the specific reasons for traffic amplification. For example, the pre-trained large-scale model identifies loop structures in the code, where downstream services are called only once within the loop. The pre-trained large-scale model further calculates the relationship between the number of loops and the call amplification ratio, confirming that loop calls are the main cause of traffic amplification.

[0149] The pre-trained large model generates link optimization strategies based on the identified problems. To address the traffic amplification issue caused by loop calls, the pre-trained large model recommends using a batch call approach, merging multiple single calls within a loop into a single batch call. The pre-trained large model further explains the implementation method of batch calls, for example, suggesting passing a list of user IDs as parameters to downstream services all at once, allowing the downstream services to return results in batches.

[0150] The pre-trained large model also analyzes other possible optimization strategies. For example, it checks for caching logic in the code. If caching is not used, the pre-trained large model suggests adding caching to reduce repeated calls to downstream services. It also checks retry logic in the code; if the number of retries is too high or the retry interval is unreasonable, it suggests adjusting the retry strategy.

[0151] The pre-trained large model calculates the resource savings achieved by implementing link optimization strategies based on resource consumption. The pre-trained large model first estimates the additional resource consumption caused by traffic amplification. For example, based on the call amplification ratio and resource consumption data, the pre-trained large model calculates the additional CPU core consumption caused by call amplification.

[0152] The pre-trained large model further estimates the expected reduction in call amplification ratio after implementing the optimization strategy. For example, if batch calling is used, the pre-trained large model estimates that the call amplification ratio can be reduced from the current 5 to 2. Based on the reduction in call amplification ratio, the pre-trained large model calculates the resource savings.

[0153] The link optimization indication information can be an optimization suggestion report generated by a pre-trained large model, which organizes optimization-related information in a structured manner. The link optimization indication information includes link optimization strategies and resource savings. The electronic device receives the link optimization indication information returned by the pre-trained large model, parses the information, and extracts the link optimization strategies and resource savings.

[0154] Optionally, the link optimization strategy may include: problem analysis, explaining the specific reasons for the amplified traffic calls; optimization plan, explaining the specific optimization measures to address the problem; implementation steps, explaining how to implement the optimization plan; and precautions, explaining the issues that need to be considered during the optimization process.

[0155] Optionally, resource savings may include: current resource consumption, indicating the current CPU core consumption of the abnormal service; additional resource consumption, indicating the additional CPU core consumption caused by traffic amplification; optimized resource consumption, indicating the expected CPU core consumption after implementing the optimization strategy; and resource savings, indicating the expected number of CPU cores that can be saved after implementing the optimization strategy.

[0156] In one embodiment, the electronic device can provide visualization capabilities, generating an interactive HTML page for link traffic analysis using a pre-trained large model. This interactive page may include a call chain graph. Optionally, the call chain graph can be a clear tree-like topology diagram that renders complex call relationships through a Mermaid Graph visualization.

[0157] The call chain diagram graphically displays the call topology of the business system, including the call relationships between various services and interfaces. In the call chain diagram, services and interfaces are represented as nodes, and call relationships are represented as lines. Electronic devices annotate key information in the call chain diagram. For each node, the electronic device annotates the node name, query rate per second, call amplification ratio, etc. For each line, the electronic device annotates the query rate per second, call amplification ratio, etc. Electronic devices use different colors or styles to identify different types of nodes. For example, red indicates nodes with abnormal services, orange indicates nodes with high call amplification ratios, and green indicates normal nodes. Through color coding, operations and maintenance personnel can quickly identify problematic nodes.

[0158] Below this visualization view, link optimization instructions can be displayed. These instructions may include a text analysis report that points out specific call amplification issues and provides targeted optimization suggestions.

[0159] The technical solution of this application embodiment can automatically generate link optimization indication information for abnormal services by utilizing a pre-trained large model, providing operation and maintenance personnel with an executable governance solution, and significantly improving the efficiency and quality of link governance.

[0160] The link traffic data processing method in this application reduces the total amount of traffic that needs to be supported from the source by identifying and managing these abnormal link amplification problems, thereby fundamentally reducing resource requirements and lowering service costs; it also reduces unnecessary link calls, lowers the overall system load and the risk of fault propagation, and improves architectural stability; it eliminates redundant requests and abnormal retries, effectively reducing interface response time and improving user experience; and it improves attribution efficiency and governance quality, reducing cost attribution investment.

[0161] In an exemplary embodiment, cost attribution analysis can also be performed to determine the specific reasons for the increase in service costs. Cost attribution analysis is an analysis process performed before or simultaneously with identifying abnormal services, which helps operations personnel better understand the root causes of cost changes. In specific implementations, electronic devices can obtain the resource consumption of each service (such as the number of instances, the number of CPU cores, etc.) and traffic call description information such as the peak QPS of the service dimension. These two are aligned with resource costs to form a "load-cost" view for monitoring and analyzing cost changes. When service costs increase, the following analysis logic can be used to attribute the cause from the overall link: increased upstream traffic / message / task calls (including message queues, scheduled tasks, and call amplification caused by code degradation); increased downstream call volume; unreasonable elastic scaling configuration (the minimum number of instances is too large, resulting in low CPU utilization of the service); uneven traffic scheduling (the minimum number of instances is too large, resulting in low CPU utilization of the service); manual expansion without reclamation; and code degradation. Therefore, when service costs increase, the above analysis logic can be used to distinguish whether it is normal business growth, configuration problems (such as setting the number of instances too large), or code defects that need to be addressed.

[0162] Therefore, if it is confirmed that business volume has not increased, but costs have risen due to other reasons, a large-scale model can be used for supply chain management. For ease of understanding by those skilled in the art, Figure 8 An example is provided as a logic diagram of the attribution process. Figure 8 In one branch, if the business volume increases, it can be confirmed that the expected results are met; in the other branch, if the business volume does not increase but the call volume increases, the analysis will proceed to the large model, and the root cause summary and governance plan will be output. Figure 8 It demonstrates how to identify anomalies by judging the relationship between resources and traffic, and automatically trigger the intervention of a large model to perform root cause analysis and solution generation, thus realizing a closed loop from problem discovery to problem resolution.

[0163] The link traffic data processing method in this application proposes a three-dimensional aggregation approach centered on service, interface, and link dimensions. This approach unifies and correlates existing operational data, clarifying and presenting end-to-end link traffic relationships. Based on this, and combined with existing cost indicators (such as CPU core count), cost allocation is performed according to link-level traffic transmission, forming an interpretable cost profile. This achieves white-boxing of link costs and traffic. When costs increase, intelligent attribution is performed based on the three-dimensional aggregation and allocation results to pinpoint the main affected services / interfaces / link segments. For links identified as having unreasonable amplification, governance suggestions and executable solutions are generated using a large model, improving the targeting and implementation efficiency of governance.

[0164] Figure 9This is a flowchart illustrating yet another link traffic data processing method according to an exemplary embodiment, such as... Figure 9 As shown, this method is used Figure 1 The electronic device 102 includes the following steps.

[0165] In step S910, based on the call chain data generated by the business system in response to the business call request, traffic call description information of at least two call objects is determined.

[0166] Among them, at least two calling objects include at least two of the services, interfaces and links in the business system; the link is used to characterize the calling path of the business system to the service and / or interface.

[0167] In one embodiment, when the calling object includes a service, the traffic call description information includes the time when the service's query rate per second reaches its peak, and the call status of each link to the service at that time; when the calling object includes an interface, the traffic call description information includes the time when the interface's query rate per second reaches its peak, and the call status of each link to the interface at that time; when the calling object includes a link, the traffic call description information includes the time when the link's query rate per second reaches its peak, and the call status of each service and / or interface on the link at that time.

[0168] In step S911, the call amplification ratio of the upstream interface relative to the downstream interface is determined based on the ratio between the query rate per second of the upstream interface and the query rate per second of the downstream interface; the call amplification ratio of the link inlet relative to the downstream interface is determined based on the ratio between the query rate per second of the link inlet and the query rate per second of the downstream interface; and the traffic call amplification of each service is determined based on each call amplification ratio.

[0169] In step S912, a comparison relationship between the peak query rate per second and the CPU core consumption is constructed. If the comparison relationship indicates that the CPU core consumption is increasing, but the business traffic indicated by the peak query rate per second is not increasing, the service is determined to be an abnormal service.

[0170] In step S913, if the peak query rate per second for the same interface on each link increases by more than a first threshold within a preset time, an alarm message is sent to the service to which the interface belongs; or, if the traffic on the call path of the interface increases by more than a second threshold within a preset time, an alarm message is sent to the service to which the interface belongs.

[0171] In step S914, a prompt word is constructed based on the resource consumption of the abnormal service, the traffic amplification of the abnormal service, and the call code of the abnormal service; the prompt word is input into the pre-trained large model; and the link optimization indication information output by the pre-trained large model based on the prompt word is obtained.

[0172] The prompt words are used to instruct the pre-trained large model to extract link optimization strategies for abnormal services from traffic amplification based on the calling code, and to determine the amount of resource savings achieved by implementing link optimization strategies for abnormal services based on resource consumption.

[0173] The link optimization indication information includes link optimization strategies and resource savings.

[0174] It should be noted that the specific limitations of the above steps can be found in the specific limitations of a link traffic data processing method described above, and will not be repeated here.

[0175] It should be understood that, although Figure 2 , Figure 7 and Figure 9 The steps in the flowchart are shown sequentially as indicated by the arrows, but these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order in which these steps are executed, and they can be performed in other orders. Figure 2 , Figure 7 and Figure 9 At least some of the steps in the process may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but may be executed at different times. The execution order of these steps or stages is not necessarily sequential, but may be executed in turn or alternately with other steps or at least some of the steps or stages in other steps.

[0176] It is understood that the same / similar parts between the various embodiments of the methods described above in this specification can be referred to each other. Each embodiment focuses on the differences from other embodiments, and relevant parts can be referred to the description of other method embodiments.

[0177] Figure 10 This is a block diagram illustrating a link traffic data processing apparatus according to an exemplary embodiment. (Refer to...) Figure 10 The device includes a description unit 1010, a comparison unit 1011, an exception unit 1012, and a generation unit 1013.

[0178] The description unit 1010 is configured to perform a call chain data generated by the business system in response to a business call request, and determine the traffic call description information of at least two call objects; the at least two call objects include at least two of the services, interfaces and chains in the business system; the chain is used to characterize the call path of the business system to the service and / or the interface.

[0179] The comparison unit 1011 is configured to perform a comparison of the differences between the traffic call description information of each of the called objects to determine the traffic call amplification of each of the services; the traffic call amplification is used to characterize the traffic changes of the services being called in the link.

[0180] The exception unit 1012 is configured to determine the exception service from the services based on the resource consumption status of each service and the traffic call description information of each service; the resource consumption status is used to characterize the resource consumption of the service in processing the business call request; the exception service is the service whose resource consumption status meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition.

[0181] The generation unit 1013 is configured to input the resource consumption and traffic call amplification of the abnormal service into a pre-trained large model to generate link optimization indication information for the abnormal service.

[0182] In an exemplary embodiment, the comparison unit 1011 is further configured to: determine a call amplification ratio of the upstream interface relative to the downstream interface based on the ratio between the query rate per second of the upstream interface of the link being called and the query rate per second of the downstream interface of the link being called; determine a call amplification ratio of the link inlet relative to the downstream interface based on the ratio between the query rate per second of the link inlet and the query rate per second of the downstream interface of the link being called; and determine the traffic call amplification of each service based on each of the call amplification ratios.

[0183] In an exemplary embodiment, the service traffic call description information includes the peak query rate per second of the service, and the resource consumption of the service includes the CPU core consumption of the service; the anomaly unit 1012 is further configured to construct a trend comparison relationship between the peak query rate per second of the service and the CPU core consumption; if the trend comparison relationship indicates that the CPU core consumption is on an upward trend, and the service traffic indicated by the peak query rate per second is not on an upward trend, the service is determined to be the abnormal service.

[0184] In one exemplary embodiment, the apparatus further includes an alarm unit. The alarm unit is configured to send an alarm message to the service to which the interface belongs if the peak query rate per second for the same interface on each of the links increases by more than a first threshold within a preset time; or, if the traffic on the call path of the interface increases by more than a second threshold within the preset time, the alarm message is sent to the service to which the interface belongs.

[0185] In an exemplary embodiment, the generation unit 1013 is further configured to: construct a prompt word based on the resource consumption of the abnormal service, the traffic amplification of the abnormal service, and the call code of the abnormal service; input the prompt word into the pre-trained large model; the prompt word is used to instruct the pre-trained large model to mine the link optimization strategy of the abnormal service from the traffic amplification based on the call code, and to determine the resource saving amount of the abnormal service by implementing the link optimization strategy based on the resource consumption; obtain the link optimization indication information output by the pre-trained large model based on the prompt word; the link optimization indication information includes the link optimization strategy and the resource saving amount.

[0186] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0187] Figure 11 This is a block diagram illustrating an electronic device 1100 for implementing the above-described link traffic data processing method according to an exemplary embodiment. For example, the electronic device 1100 may be a server. (Refer to...) Figure 11 The electronic device 1100 includes a processing component 1120, which further includes one or more processors, and memory resources represented by memory 1122 for storing instructions, such as application programs, that can be executed by the processing component 1120. The application programs stored in memory 1122 may include one or more modules, each corresponding to a set of instructions. Furthermore, the processing component 1120 is configured to execute instructions to perform the methods described above.

[0188] Electronic device 1100 may further include: a power supply component 1124 configured to perform power management of electronic device 1100, a wired or wireless network interface 1126 configured to connect electronic device 1100 to a network, and an input / output (I / O) interface 1128. Electronic device 1100 may operate on an operating system stored in memory 1122, such as Windows Server, Mac OS X, Unix, Linux, FreeBSD, or similar.

[0189] In an exemplary embodiment, a computer-readable storage medium including instructions is also provided, such as a memory 1122 including instructions, which can be executed by a processor of an electronic device 1100 to perform the above-described method. The storage medium may be a computer-readable storage medium, such as a ROM, random access memory (RAM), CD-ROM, magnetic tape, floppy disk, and optical data storage device.

[0190] In an exemplary embodiment, a computer program product is also provided, the computer program product including instructions that can be executed by the processor of the electronic device 1100 to perform the above-described method.

[0191] It should be noted that the above-mentioned apparatus, electronic equipment, computer-readable storage medium, computer program product, etc., may also include other implementation methods according to the description of the method embodiments. For specific implementation methods, please refer to the description of the relevant method embodiments, which will not be elaborated here.

[0192] Other embodiments of this disclosure will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This disclosure is intended to cover any variations, uses, or adaptations of this disclosure that follow the general principles of this disclosure and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this disclosure are indicated by the claims.

[0193] It should be understood that this disclosure is not limited to the precise structures described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this disclosure is limited only by the appended claims.

Claims

1. A method for processing link traffic data, characterized in that, include: Based on the call chain data generated by the business system in response to business call requests, determine the traffic call description information of at least two call objects; The at least two calling objects include at least two of the services, interfaces, and links in the business system; the link is used to characterize the calling path of the business system to the service and / or the interface; By comparing the differences in the traffic call description information of each of the called objects, the traffic call amplification of each of the services is determined; the traffic call amplification is used to characterize the traffic changes of the service being called in the link; Based on the resource consumption of each service and the traffic call description information of each service, abnormal services are identified from each service; the resource consumption is used to characterize the resource consumption of the service in processing the business call request; The abnormal service is the service whose resource consumption meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition. The resource consumption and traffic amplification of the abnormal service are input into the pre-trained large model to generate link optimization indication information for the abnormal service.

2. The link traffic data processing method according to claim 1, characterized in that, When the called object includes a service, the traffic call description information includes the time when the query rate per second of the service reaches its peak, and the call status of each link to the service at that time; When the calling object includes an interface, the traffic call description information includes the time when the query rate per second of the interface reaches its peak, and the call status of each link to the interface at that time; When the calling object includes a link, the traffic call description information includes the time when the query rate per second of the link reaches its peak, and the call status of each service and / or interface on the link at that time.

3. The link traffic data processing method according to claim 1, characterized in that, The step of comparing the differences between the traffic call description information of each of the called objects to determine the traffic call amplification of each of the services includes: The call amplification ratio of the upstream interface relative to the downstream interface is determined based on the ratio between the query rate per second of the upstream interface of the link and the query rate per second of the downstream interface of the link. The call amplification ratio of the link inlet relative to the downstream interface is determined based on the ratio between the query rate per second of the link inlet and the query rate per second of the downstream interface of the link. Based on the call amplification ratio, determine the traffic call amplification of each service.

4. The link traffic data processing method according to claim 1, characterized in that, The service's traffic call description information includes the service's peak query rate per second, and the service's resource consumption information includes the service's CPU core consumption. The step of identifying abnormal services from among the services based on their resource consumption and traffic call descriptions includes: Construct a comparative relationship between the peak query rate per second of the service and the CPU core consumption trend; If the trend comparison indicates that the CPU core consumption is increasing, but the peak query rate per second indicates that the service traffic is not increasing, then the service is determined to be the abnormal service.

5. The link traffic data processing method according to claim 1, characterized in that, After determining the traffic call description information of at least two calling objects based on the call chain data generated by the business system in response to the business call request, the method further includes: If the peak query rate per second for the same interface on each of the aforementioned links increases by more than a first threshold within a preset time, an alarm message will be sent to the service to which the interface belongs. or, If the increase in traffic along the call path of the interface exceeds a second threshold within the preset time period, an alarm message will be sent to the service to which the interface belongs.

6. The link traffic data processing method according to any one of claims 1 to 5, characterized in that, The step of inputting the resource consumption and traffic amplification of the abnormal service into a pre-trained large model to generate link optimization indication information for the abnormal service includes: Based on the resource consumption of the abnormal service, the traffic amplification of the abnormal service, and the call code of the abnormal service, construct the prompt words; The prompt words are input into the pre-trained large model; the prompt words are used to instruct the pre-trained large model to mine the link optimization strategy of the abnormal service from the traffic call amplification situation based on the call code, and to determine the amount of resource savings for the abnormal service to implement the link optimization strategy based on the resource consumption situation; Obtain the link optimization indication information output by the pre-trained large model based on the prompt words; the link optimization indication information includes the link optimization strategy and the resource saving amount.

7. A link traffic data processing device, characterized in that, include: The description unit is configured to determine the traffic call description information of at least two call objects based on the call chain data generated by the business system in response to the business call request; The at least two calling objects include at least two of the services, interfaces, and links in the business system; the link is used to characterize the calling path of the business system to the service and / or the interface; The comparison unit is configured to perform a comparison of the differences between the traffic call description information of each of the called objects to determine the traffic call amplification of each of the services; the traffic call amplification is used to characterize the traffic changes of the services being called in the link; An exception unit is configured to determine an exception service from among the services based on the resource consumption status of each service and the traffic call description information of each service; the resource consumption status is used to characterize the resource consumption of the service in processing the business call request; The abnormal service is the service whose resource consumption meets the abnormal resource consumption condition and whose traffic call description information meets the abnormal traffic call condition. The generation unit is configured to input the resource consumption and traffic amplification of the abnormal service into a pre-trained large model to generate link optimization indication information for the abnormal service.

8. An electronic device, characterized in that, include: processor; Memory used to store the processor's executable instructions; The processor is configured to execute the instructions to implement the link traffic data processing method as described in any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that, When the instructions in the computer-readable storage medium are executed by the processor of the electronic device, the electronic device is able to perform the link traffic data processing method as described in any one of claims 1 to 6.

10. A computer program product, the computer program product comprising instructions, characterized in that, When the instruction is executed by the processor of the electronic device, the electronic device is able to perform the link traffic data processing method as described in any one of claims 1 to 6.

Images