A self-constructing network building method and system

Abstract

The application relates to the technical field of network building, in particular to a self-constructed network building method and system. The method comprises the following steps: obtaining a network building requirement; analyzing the network building requirement to determine a network use scenario and a network use scale; determining time attribute characteristics and event attribute characteristics according to the network use scenario and the network use scale; determining the response priority of a front end and the interface concurrent logic of an application layer according to the event attribute characteristics; and determining the triggering time of the response priority of the front end and the interface concurrent logic of the application layer according to the time attribute characteristics. The application environment and scale index of network deployment are determined, demand ambiguity is eliminated, and optimization for specific scenarios and scales is ensured. The content loading sequence and the interface calling mode are dynamically adjusted, so that the response efficiency is improved and the system pressure is reduced. The configuration is dynamically enabled before or during a network traffic peak, so that the resource optimization is timely put into effect, and invalid or delayed response is avoided.

Description

Technical Field

[0001] This application relates to the field of network construction technology, and in particular to a method and system for building a self-constructing network. Background Technology

[0002] With the rapid development of cloud computing technology, more and more enterprises are choosing to lease server resources from cloud service providers to build custom networks to meet their business needs. Currently, cloud service providers typically design static network deployment solutions based on the network deployment requirements provided by customers.

[0003] However, in high-concurrency scenarios such as user platforms, existing network construction solutions usually rely on fixed parameter configurations, which cannot adapt to fluctuations in network usage, resulting in rigid resource allocation, low response efficiency, and seriously affecting user experience and system stability. Summary of the Invention

[0004] This application provides a method and system for building a self-constructing network to solve the above problems.

[0005] Firstly, this application provides a method for building a self-constructing network, the method comprising:

[0006] Obtain network setup requirements; analyze the network setup requirements to determine network usage scenarios and network usage scale;

[0007] Based on the network usage scenario and the network usage scale, determine the time attribute characteristics and event attribute characteristics;

[0008] Based on the characteristics of the event attributes, determine the response priority of the front end and the concurrent logic of the application layer interface;

[0009] Based on the time attribute characteristics, the response priority of the front end and the triggering timing of the application layer's interface concurrency logic are determined.

[0010] This solution identifies network deployment requirements and initiates a resolution process based on the client's actual needs, preventing process interruptions due to missing requirements. The resolution process determines network usage scenarios and scale, clarifies the application environment and scale indicators for network deployment, eliminates ambiguities, and ensures optimization tailored to specific scenarios and scales. Based on network usage scenarios and scale, the solution identifies time and event attributes, effectively recognizing dynamic changes in the network environment across time and events. Based on event attributes, the solution determines front-end response priorities and application-layer interface concurrency logic, dynamically adjusting content loading order and API call methods to improve response efficiency and reduce system load. Based on time attributes, the solution determines the triggering timing of front-end response priorities and application-layer interface concurrency logic, dynamically enabling configurations before or during peak network traffic periods to ensure timely resource optimization and avoid ineffective or delayed responses.

[0011] Optionally, determining the time attribute characteristics and event attribute characteristics based on the network usage scenario and the network usage scale includes:

[0012] Acquire historical event data, analyze the historical event data, and determine the event type classification rules;

[0013] Based on the event type classification rules, the network usage scenarios are analyzed to determine the types of network congestion events;

[0014] Based on the network congestion event types, the historical event data is analyzed to determine the characteristics of historical traffic peaks and interface call paths.

[0015] Based on the historical traffic peak characteristics and the interface call path characteristics, the time attribute characteristics and event attribute characteristics are determined.

[0016] This solution acquires and analyzes historical event data to determine event type classification rules, ensuring accurate identification of network congestion event types and avoiding the lack of dynamic analysis capabilities. Based on the event type classification rules, it analyzes network usage scenarios to determine network congestion event types, addressing the underutilization of event attribute characteristics. Based on network congestion event types, it analyzes historical event data to determine historical traffic peak characteristics and API call path characteristics, quantifying dynamic behavior under event types and providing a data foundation for attribute characteristic generation, eliminating the deficiency of missing time and event attribute characteristic predictions. Based on historical traffic peak characteristics and API call path characteristics, it determines time and event attribute characteristics, achieving the goal of dynamically determining time and event attribute characteristics and improving response efficiency.

[0017] Optionally, determining the front-end response priority and application-layer interface concurrency logic based on the event attribute characteristics includes:

[0018] Based on the characteristics of the event attributes, determine the core content of the user's browsing and the content of the browsed pages;

[0019] Analyze the historical event data to determine event browsing preferences;

[0020] The content of the browsed page is broken down into several content units;

[0021] Based on the aforementioned event browsing preferences, several content units are prioritized to obtain the front-end response priority;

[0022] Based on the historical traffic peak characteristics and the interface call path characteristics, the application layer interface concurrency logic is generated.

[0023] This solution identifies core user browsing patterns and page content based on event attributes, avoiding resource waste on low-relevance pages and ensuring optimization efforts target actual congestion sources. Historical event data is analyzed to determine browsing preferences, ensuring response priorities align with real user behavior rather than static preset rules. Page content is broken down into smaller units, allowing optimization to be precise down to the smallest functional module, avoiding resource redundancy from full-page loading. Based on event browsing preferences, these content units are prioritized to determine front-end response priorities, significantly reducing perceived user wait time and alleviating page lag. Application-layer API concurrency logic is generated based on historical traffic peak characteristics and API call path characteristics, dynamically distributing concurrency pressure and eliminating API response latency.

[0024] Optionally, determining the time attribute characteristics and event attribute characteristics based on the historical traffic peak characteristics and the interface call path characteristics includes:

[0025] Analyze the characteristics of the historical traffic peaks to determine periodic and sudden time patterns;

[0026] Analyze the characteristics of the interface call path to determine the interface response delay pattern and interface error rate pattern;

[0027] Based on the periodic time pattern, the burst time pattern, the interface response delay pattern, and the interface error rate pattern, the time attribute characteristics and event attribute characteristics are determined.

[0028] This solution analyzes historical traffic peak characteristics to identify periodic and bursty time patterns, addressing the lack of dynamic analysis capabilities. Predictable patterns are generated from historical traffic peak characteristics, preventing resource optimization delays. Interface call path characteristics are analyzed to identify interface response latency and error rate patterns, addressing the deficiencies in response priority and concurrency logic. Pattern data is generated from interface call path characteristics to ensure adaptive settings for interface concurrency logic. Based on periodic, bursty, interface response latency, and interface error rate patterns, time and event attribute characteristics are determined, resolving scalability deficiencies. Attribute characteristics are generated by integrating pattern data to ensure dynamic configuration adjustments as network usage expands.

[0029] Optionally, the historical event data includes historical traffic data, and the step of analyzing the network usage scenario and determining the network congestion event type based on the event type classification rules includes:

[0030] Extract the network usage scenarios and determine scenario feature parameters;

[0031] Analyze the historical traffic data to identify traffic anomalies;

[0032] Based on the event type classification rules, the initial matching type is determined according to the traffic anomaly points and the scene feature parameters;

[0033] Based on the network usage scale, verify the initial matching type and determine the network congestion event type.

[0034] This solution extracts network usage scenarios, determines scenario characteristic parameters, and addresses the deficiency of missing event attribute characteristics. It analyzes historical traffic data to identify traffic anomalies and expose sudden congestion that cannot be handled. Based on event type classification rules, it determines the initial matching type according to traffic anomalies and scenario characteristic parameters, solving the problem of unpredictable network congestion event types and avoiding the blindness of static solutions. Combined with network usage scale, the initial matching type is validated to determine the network congestion event type, ensuring that the results match actual scale requirements and avoiding misallocation of resources.

[0035] Optionally, analyzing the historical event data to determine event browsing preferences includes:

[0036] The historical event data is parsed to obtain user clickstream data;

[0037] Analyze the user clickstream data to determine the page dwell time distribution and click heatmap;

[0038] Based on the page dwell time distribution and the click heatmap, determine the content attention index;

[0039] By combining the event attribute characteristics and the content attention index, low-attention events are filtered out to determine event browsing preferences.

[0040] This solution analyzes historical event data to obtain user clickstream data, addressing the lack of dynamic analysis capabilities. Analyzing the user clickstream data determines page dwell time distribution and click heatmaps, eliminating issues related to missing response priorities and concurrency logic. Based on the page dwell time distribution and click heatmaps, content attention metrics are determined, ensuring event browsing preferences are based on quantitative data to address insufficient scalability. Combining event attribute characteristics and content attention metrics, low-attention events are filtered out, event browsing preferences are determined, and issues related to missing response priorities and concurrency logic are eliminated.

[0041] Optionally, the step of prioritizing several content units based on the event browsing preferences to obtain the front-end response priority includes:

[0042] Based on the event browsing preferences, assign preference weights to each content unit;

[0043] Analyze the characteristics of the historical traffic peaks to determine the unit loading delay tolerance;

[0044] Calculate the priority score based on the preference weights and the unit loading delay tolerance;

[0045] Based on the priority scores, the content units are sorted to obtain the front-end response priority.

[0046] This solution assigns preference weights to each content unit based on event browsing preferences, ensuring that response priority ranking prioritizes high-preference content units, thus optimizing the initial basis for front-end loading in dynamic network environments. Historical traffic peak characteristics are analyzed to determine unit loading latency tolerance and identify the performance weaknesses of each content unit under pressure scenarios, ensuring that response priority ranking prioritizes low-tolerance content units, thereby alleviating interface congestion. Priority scores are calculated based on preference weights and unit loading latency tolerances, ensuring response priority while considering user behavior and network performance requirements. Based on the priority scores, several content units are ranked to obtain the front-end response priority, ensuring that high-priority content units respond quickly in dynamic events, reducing latency and error rates, optimizing content loading order, and resolving the issue of missing response priorities.

[0047] Optionally, generating application-layer interface concurrency logic based on the historical traffic peak characteristics and the interface call path characteristics includes:

[0048] Analyze the characteristics of the historical traffic peaks to determine the peak concurrency threshold;

[0049] Analyze the characteristics of the interface call paths to determine the interface dependency graph;

[0050] Based on the peak concurrency threshold and the interface dependency graph, an interface call concurrency strategy and a timeout fallback mechanism are generated.

[0051] The interface call concurrency strategy and the timeout fallback mechanism are used as the interface concurrency logic of the application layer.

[0052] This solution analyzes historical traffic peak characteristics to determine peak concurrency thresholds, reflecting the maximum concurrent pressure of historical peak events and addressing the inability to predict time-related characteristics. It analyzes API call path characteristics to determine API dependency graphs, eliminating the inability to parse event attribute characteristics. Based on peak concurrency thresholds and API dependency graphs, it generates API call concurrency strategies and timeout fallback mechanisms, optimizing application-layer API call logic, preventing congestion caused by multiple simultaneous triggers of the same API, and alleviating pressure in high-concurrency scenarios. It also eliminates response timeout or error issues, preventing the entire chain from paralyzing due to single API blockage and reducing user experience degradation. By incorporating the API call concurrency strategies and timeout fallback mechanisms into the application-layer API concurrency logic, it eliminates the deficiency of missing application-layer API concurrency logic.

[0053] Optionally, the analysis of the historical event data to determine event type classification rules includes:

[0054] The historical event data is parsed to obtain user behavior logs and network traffic logs;

[0055] Analyze the user behavior logs to determine user behavior patterns;

[0056] Analyze the network traffic logs to determine the traffic fluctuation pattern;

[0057] Based on the user behavior patterns and the traffic fluctuation patterns, determine the event type classification rules.

[0058] This solution analyzes historical event data to obtain user behavior logs and network traffic logs, correlates them with user behavior pattern analysis requirements, supports the quantification of traffic fluctuation patterns, and avoids the coupling of operation records and traffic metrics in the analysis. Analyzing user behavior logs identifies user behavior patterns, addressing the inability to predict event attributes. Analyzing network traffic logs identifies traffic fluctuation patterns, eliminating the inability to predict time-related attributes. Based on user behavior patterns and traffic fluctuation patterns, event type classification rules are determined, addressing the core deficiency of lacking dynamic analysis capabilities.

[0059] Secondly, this application provides a self-built network construction system, the system comprising:

[0060] The requirement analysis module is used to obtain network construction requirements; analyze the network construction requirements to determine the network usage scenarios and network usage scale;

[0061] The feature determination module is used to determine the time attribute features and event attribute features based on the network usage scenario and the network usage scale.

[0062] The event characteristic analysis module is used to determine the front-end response priority and application layer interface concurrency logic based on the event attribute characteristics.

[0063] The time characteristic analysis module is used to determine the response priority of the front end and the triggering timing of the application layer's interface concurrency logic based on the time attribute characteristics.

[0064] Optionally, when the feature determination module determines the time attribute features and event attribute features based on the network usage scenario and the network usage scale, it is used for:

[0065] Acquire historical event data, analyze the historical event data, and determine the event type classification rules;

[0066] Based on the event type classification rules, the network usage scenarios are analyzed to determine the types of network congestion events;

[0067] Based on the network congestion event types, the historical event data is analyzed to determine the characteristics of historical traffic peaks and interface call paths.

[0068] Based on the historical traffic peak characteristics and the interface call path characteristics, the time attribute characteristics and event attribute characteristics are determined.

[0069] Optionally, when the event characteristic analysis module determines the front-end response priority and application layer interface concurrency logic based on the event attribute characteristics, it is used for:

[0070] Based on the characteristics of the event attributes, determine the core content of the user's browsing and the content of the browsed pages;

[0071] Analyze the historical event data to determine event browsing preferences;

[0072] The content of the browsed page is broken down into several content units;

[0073] Based on the aforementioned event browsing preferences, several content units are prioritized to obtain the front-end response priority;

[0074] Based on the historical traffic peak characteristics and the interface call path characteristics, the application layer interface concurrency logic is generated.

[0075] Optionally, when the feature determination module determines the time attribute characteristics and event attribute characteristics based on the historical traffic peak characteristics and the interface call path characteristics, it is used for:

[0076] Analyze the characteristics of the historical traffic peaks to determine periodic and sudden time patterns;

[0077] Analyze the characteristics of the interface call path to determine the interface response delay pattern and interface error rate pattern;

[0078] Based on the periodic time pattern, the burst time pattern, the interface response delay pattern, and the interface error rate pattern, the time attribute characteristics and event attribute characteristics are determined.

[0079] Optionally, the historical event data includes historical traffic data. When the feature determination module analyzes the network usage scenario based on the event type classification rules and determines the network congestion event type, it is used for:

[0080] Extract the network usage scenarios and determine scenario feature parameters;

[0081] Analyze the historical traffic data to identify traffic anomalies;

[0082] Based on the event type classification rules, the initial matching type is determined according to the traffic anomaly points and the scene feature parameters;

[0083] Based on the network usage scale, verify the initial matching type and determine the network congestion event type.

[0084] Optionally, when the event feature analysis module analyzes the historical event data to determine event browsing preferences, it is used for:

[0085] The historical event data is parsed to obtain user clickstream data;

[0086] Analyze the user clickstream data to determine the page dwell time distribution and click heatmap;

[0087] Based on the page dwell time distribution and the click heatmap, determine the content attention index;

[0088] By combining the event attribute characteristics and the content attention index, low-attention events are filtered out to determine event browsing preferences.

[0089] Optionally, when the event feature analysis module prioritizes several content units based on the event browsing preferences to obtain the front-end response priority, it is used for:

[0090] Based on the event browsing preferences, assign preference weights to each content unit;

[0091] Analyze the characteristics of the historical traffic peaks to determine the unit loading delay tolerance;

[0092] Calculate the priority score based on the preference weights and the unit loading delay tolerance;

[0093] Based on the priority scores, the content units are sorted to obtain the front-end response priority.

[0094] Optionally, when the event characteristic analysis module generates application-layer interface concurrency logic based on the historical traffic peak characteristics and the interface call path characteristics, it is used for:

[0095] Analyze the characteristics of the historical traffic peaks to determine the peak concurrency threshold;

[0096] Analyze the characteristics of the interface call paths to determine the interface dependency graph;

[0097] Based on the peak concurrency threshold and the interface dependency graph, an interface call concurrency strategy and a timeout fallback mechanism are generated.

[0098] The interface call concurrency strategy and the timeout fallback mechanism are used as the interface concurrency logic of the application layer.

[0099] Optionally, when the feature determination module analyzes the historical event data and determines the event type classification rules, it is used for:

[0100] The historical event data is parsed to obtain user behavior logs and network traffic logs;

[0101] Analyze the user behavior logs to determine user behavior patterns;

[0102] Analyze the network traffic logs to determine the traffic fluctuation pattern;

[0103] Based on the user behavior patterns and the traffic fluctuation patterns, determine the event type classification rules. Attached Figure Description

[0104] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0105] Figure 1 This is a schematic diagram illustrating an application scenario provided in one embodiment of this application;

[0106] Figure 2A flowchart illustrating a self-constructing network building method provided in one embodiment of this application;

[0107] Figure 3 This is a schematic diagram of a self-built network construction system provided in an embodiment of this application. Detailed Implementation

[0108] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0109] Furthermore, the term "and / or" in this article is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this article, unless otherwise specified, generally indicates that the preceding and following related objects have an "or" relationship.

[0110] The embodiments of this application will now be described in further detail with reference to the accompanying drawings.

[0111] In high-concurrency scenarios such as user platforms, existing network deployment solutions typically rely on fixed parameter configurations, resulting in rigid resource allocation, low response efficiency, and severely impacting user experience and system stability. Especially in event-driven scenarios, they cannot adapt to fluctuations in network usage in real time, leading to decreased system performance and a deterioration in user experience.

[0112] Based on this, this application provides a self-built network construction method and system. It obtains network construction requirements and initiates a parsing process based on the customer's actual needs, avoiding process interruptions due to missing requirements. Parsing network construction requirements determines the network usage scenario and scale, clarifies the application environment and scale indicators for network deployment, eliminates ambiguity, and ensures optimization for specific scenarios and scales. Based on the network usage scenario and scale, it determines time and event attribute characteristics, effectively identifying dynamic changes in the network environment across time and events. Based on event attribute characteristics, it determines the front-end response priority and application-layer interface concurrency logic, dynamically adjusting content loading order and interface call methods to improve response efficiency and reduce system pressure. Based on time attribute characteristics, it determines the triggering timing of the front-end response priority and application-layer interface concurrency logic, dynamically enabling configurations before or during network traffic peaks to ensure timely resource optimization and avoid ineffective or delayed responses.

[0113] Figure 1 This is a schematic diagram illustrating an application scenario provided by this application, showing the application of the method provided in this application when building a self-constructed network.

[0114] Specifically, the method provided in this application can be applied to any server. The server interacts with the user device, obtains the network setup requirements submitted by the customer through the user device, and initiates a parsing process based on the customer's actual needs. The parsing of the network setup requirements determines the network usage scenario and network scale. Based on the network usage scenario and network scale, the time attribute characteristics and event attribute characteristics are determined. Based on the event attribute characteristics, the front-end response priority and application-layer interface concurrency logic are determined, dynamically adjusting the content loading order and interface call methods to improve response efficiency and reduce system pressure. Based on the time attribute characteristics, the triggering timing of the front-end response priority and application-layer interface concurrency logic is determined, dynamically enabling configurations before or during network traffic peaks to ensure timely resource optimization and avoid invalid or delayed responses.

[0115] For specific implementation details, please refer to the following examples.

[0116] Figure 2 This is a flowchart illustrating a self-built network setup method according to an embodiment of this application. The method of this embodiment can be applied to servers in the above scenarios. Figure 2 As shown, the method includes:

[0117] S201. Obtain network setup requirements; analyze network setup requirements, and determine network usage scenarios and network usage scale.

[0118] Network deployment requirements can be the information submitted by customers when leasing cloud services, including parameters such as bandwidth requirements, capacity requirements, and latency requirements. Network usage scenarios can be the type of application environment in which the network is deployed. Network usage scale can be a metric indicating the scale of the network deployment.

[0119] Specifically, network setup requirements submitted by customers are obtained through user devices. A natural language processing engine is used to parse these requirements, matching them with a list of keywords (e.g., e-commerce keywords include "promotion" and "shopping cart," while education keywords include "course" and "live streaming") to determine the network usage scenario (e.g., a user platform or an online education platform). Simultaneously, numerical parameters (e.g., 100 in "bandwidth: 100Mbps") are extracted from the network setup requirements to determine the scale of network usage.

[0120] S202. Determine the characteristics of time attributes and event attributes based on network usage scenarios and network usage scale;

[0121] The time attribute characteristics can be the characteristic patterns of traffic peaks in the time dimension.

[0122] Event attributes can be event characteristics driven by user behavior patterns.

[0123] Specifically, the system matches records with similar network usage scenarios and scales from the historical event database (which stores historical traffic data and user behavior logs) established by the user platform's network monitoring system, and extracts historical traffic data (for example, for e-commerce scenarios, it retrieves traffic logs during holidays); it then uses statistical analysis tools to process the historical traffic data and identify time attribute characteristics (time series features, such as periodic patterns of traffic peaks (peaks at fixed times each day) and the timing of sudden events (instantaneous traffic surges caused by holiday activities)).

[0124] At the same time, analyze user behavior logs (such as clickstream data) in the historical event database to extract event attribute characteristics (such as high concurrency triggering interfaces in flash sale events and interface congestion caused by browsing preferences).

[0125] S203. Based on the characteristics of event attributes, determine the response priority of the front end and the concurrent logic of the application layer interface;

[0126] The front end can be the user interface, involved in page rendering and content display, and handling user requests. Response priority can be the loading order rules for content units. The application layer can be the logic processing layer in the software architecture, involved in API calls and business logic execution, and used to handle application layer requests. API concurrency logic can be the API call strategy.

[0127] Specifically, based on the characteristics of the event attributes, the front-end response priority is set. For example, in an e-commerce scenario, if the event attributes show that the user prefers gift-related pages, the response priority is set to prioritize loading this type of content (high-priority content is processed first).

[0128] Based on the characteristics of the event attributes, set the concurrency logic of the application layer interface. For example, for high-concurrency events (operations with a large number of requests in a short period of time, such as flash sales), increase the thread pool size (which represents the number of threads that can process requests at the same time, and adjust concurrency control parameters, such as the number of threads).

[0129] S204. Based on the characteristics of time attributes, determine the response priority of the front end and the triggering time of the concurrent logic of the application layer interface.

[0130] The triggering time can be the activation point of response priority and interface concurrency logic.

[0131] Specifically, the characteristics of time attributes are analyzed, and combined with event triggers (the triggering time is determined in real time based on the characteristics of time attributes) to generate the response priority of the front end and the triggering time of the concurrent logic of the application layer interface.

[0132] This solution identifies network deployment requirements and initiates a resolution process based on the client's actual needs, preventing process interruptions due to missing requirements. The resolution process determines network usage scenarios and scale, clarifies the application environment and scale indicators for network deployment, eliminates ambiguities, and ensures optimization tailored to specific scenarios and scales. Based on network usage scenarios and scale, the solution identifies time and event attributes, effectively recognizing dynamic changes in the network environment across time and events. Based on event attributes, the solution determines front-end response priorities and application-layer interface concurrency logic, dynamically adjusting content loading order and API call methods to improve response efficiency and reduce system load. Based on time attributes, the solution determines the triggering timing of front-end response priorities and application-layer interface concurrency logic, dynamically enabling configurations before or during peak network traffic periods to ensure timely resource optimization and avoid ineffective or delayed responses.

[0133] In some embodiments, historical event data is acquired, analyzed, and event type classification rules are determined; based on the event type classification rules, network usage scenarios are analyzed to determine network congestion event types; based on the network congestion event types, historical event data is analyzed to determine historical traffic peak characteristics and interface call path characteristics; and based on the historical traffic peak characteristics and interface call path characteristics, time attribute characteristics and event attribute characteristics are determined.

[0134] Historical event data can be a historical dataset related to network usage scenarios, including historical traffic data and user behavior logs. Event type classification rules can be logical conditions used to classify network usage scenarios into different event types. Network congestion event types can be congestion event categories determined according to the event type classification rules. Historical traffic peak characteristics can be quantitative patterns related to traffic surges extracted from historical event data. Interface call path characteristics can be behavioral patterns related to application layer interface calls extracted from historical event data.

[0135] Specifically, historical event data is extracted from the historical event database collected through the vendor's log server; statistical analysis tools are used to process the historical event data to identify event characteristics (such as event frequency and user behavior patterns), and then event type classification rules are formulated based on the event characteristics, for example, events are classified into high-concurrency events or low-concurrency events according to user concurrency.

[0136] Apply event type classification rules to the current network usage scenario. By matching scenario features (such as the description of a flash sale event on a user platform), identify network congestion event types that may cause network congestion. For example, in an e-commerce scenario, the rules match flash sale events or holiday promotion events as network congestion event types.

[0137] For each type of network congestion event (such as a flash sale event), historical event data is filtered, and statistical analysis tools are used to analyze the data to calculate the peak traffic time (peak occurrence time) and peak amplitude (maximum request volume) to determine the characteristics of historical traffic peaks; and frequently called interface sequences (such as the interface call chain from a user browsing a page to placing an order) are identified to determine the characteristics of the interface call path.

[0138] Analyze the time point data in historical traffic peak characteristics to generate time attribute features, such as the daily, periodic occurrence of traffic peaks. Analyze API call path characteristics to generate event attribute features, such as user preference for calling the gift page API during flash sales.

[0139] This solution acquires and analyzes historical event data to determine event type classification rules, ensuring accurate identification of network congestion event types and avoiding the lack of dynamic analysis capabilities. Based on the event type classification rules, it analyzes network usage scenarios to determine network congestion event types, addressing the underutilization of event attribute characteristics. Based on network congestion event types, it analyzes historical event data to determine historical traffic peak characteristics and API call path characteristics, quantifying dynamic behavior under event types and providing a data foundation for attribute characteristic generation, eliminating the deficiency of missing time and event attribute characteristic predictions. Based on historical traffic peak characteristics and API call path characteristics, it determines time and event attribute characteristics, achieving the goal of dynamically determining time and event attribute characteristics and improving response efficiency.

[0140] In some embodiments, the core user browsing and page content are determined based on event attribute characteristics; historical event data is analyzed to determine event browsing preferences; the page content is split into several content units; based on event browsing preferences, the content units are prioritized to obtain the front-end response priority; and application-layer interface concurrency logic is generated based on historical traffic peak characteristics and interface call path characteristics.

[0141] The core of user browsing can be the core pages or functional interfaces that users visit most frequently.

[0142] The content of a web page can be a complete collection of pages that are relevant to the core browsing experience of a user in a web usage scenario.

[0143] Event browsing preferences can be a quantitative indicator of the frequency with which users access different page content or interfaces.

[0144] A content unit can be the smallest independently loadable component derived from the breakdown of page content.

[0145] Specifically, by analyzing user behavior patterns in the event attributes (such as high-frequency calls to the gift page interface or user concurrency patterns), the core of user browsing can be identified. For example, in a flash sale event on a user platform, the event attributes include user preference for calling the gift page interface, thus determining that the core of user browsing is the gift page.

[0146] Based on the core user browsing behavior, query the customer descriptions in the network setup requirements (such as the project requirements submitted by the customer) and extract the corresponding browsing page content. For example, extract the gift page, product details page, and shopping cart page from the customer description as browsing page content.

[0147] Use statistical analysis tools to process historical event data, filter data to match network congestion event types (such as flash sale events); analyze user behavior logs (such as page browsing history) in historical event data to determine event browsing preferences. For example, in a flash sale event, analyze historical event data to determine the frequency of visits to the gift page as an event browsing preference.

[0148] Page parsing tools are used to break down the content of browsed pages into several content units (such as page titles, product images, description text, and buttons). For example, a gift page is broken down into gift image units, gift price units, and purchase button units. Based on browsing preferences, each content unit is weighted according to the preference value of its respective page. Then, multiple content units on the same page are further sorted by the frequency of API calls in user behavior logs (e.g., the purchase button unit has the highest call frequency on the gift page). A sorting algorithm is then used to sort all content units in descending order of weight, generating front-end response priorities, such as the purchase button unit, gift image unit, and gift price unit. Peak time windows are extracted from historical traffic peak characteristics to generate time-driven rules (used to control API concurrency behavior within different time windows, generating application-layer API concurrency logic). High-concurrency APIs are extracted from API call path characteristics to generate API scheduling rules (used to optimize API scheduling strategies, generating application-layer API concurrency logic). The time-driven rules and API scheduling rules are merged to generate application-layer API concurrency logic.

[0149] This solution identifies core user browsing patterns and page content based on event attributes, avoiding resource waste on low-relevance pages and ensuring optimization efforts target actual congestion sources. Historical event data is analyzed to determine browsing preferences, ensuring response priorities align with real user behavior rather than static preset rules. Page content is broken down into smaller units, allowing optimization to be precise down to the smallest functional module, avoiding resource redundancy from full-page loading. Based on event browsing preferences, these content units are prioritized to determine front-end response priorities, significantly reducing perceived user wait time and alleviating page lag. Application-layer API concurrency logic is generated based on historical traffic peak characteristics and API call path characteristics, dynamically distributing concurrency pressure and eliminating API response latency.

[0150] In some embodiments, historical traffic peak characteristics are analyzed to determine periodic time patterns and burst time patterns; interface call path characteristics are analyzed to determine interface response delay patterns and interface error rate patterns; and time attribute characteristics and event attribute characteristics are determined based on periodic time patterns, burst time patterns, interface response delay patterns, and interface error rate patterns.

[0151] Periodic time patterns can be fixed time regularities that recur.

[0152] Sudden time patterns can be abnormal traffic peaks with no fixed pattern.

[0153] The interface response latency pattern can be the distribution pattern of the interface response latency.

[0154] An interface error rate pattern can be a probability pattern of interface call failure.

[0155] Specifically, statistical analysis tools are used to detect recurring periods (such as daily or weekly peak periods) in historical traffic peak characteristics. The average traffic value (used to identify periodic time patterns) and standard deviation (used to quantify traffic fluctuations and assist in identifying periodic time patterns) within the time window are calculated. Traffic peaks at fixed intervals (high points at fixed intervals in historical traffic peak characteristics, used to determine periodic time patterns) are identified, and the periodic time patterns are determined. Anomaly detection algorithms are applied to calculate the deviation between the traffic value (used to detect deviations) and the historical average value (long-term average traffic value, used to detect deviations), and sudden peaks (abnormal traffic high points that deviate significantly from the historical average value, used to determine sudden time patterns) are identified, and the sudden time patterns are determined.

[0156] The API call path characteristics are analyzed to calculate the average response time of each API (the arithmetic mean of API response times, used to determine the API response latency pattern). High-latency APIs (APIs with excessively long response times) are identified by comparing the average response times, and the API response latency pattern is determined. At the same time, the API call path characteristics are analyzed to calculate the error rate (the proportion of API call failures) of each API. High-error-rate APIs (APIs with excessively high error rates) are identified by comparing the error rates, and the API error rate pattern is determined.

[0157] The system maps periodic time patterns to the periodic component of time attribute characteristics (describing the fixed recurring pattern of traffic peaks, such as daily or weekly peaks); it maps bursty time patterns to the bursty component of time attribute characteristics (describing abnormal and irregular surges in traffic peaks, such as promotional events); and it integrates the periodic and bursty components to generate time attribute characteristics. Similarly, it maps interface response latency patterns to response latency characteristics of event attribute characteristics (describing the latency performance characteristics of interfaces, such as the distribution of high-latency interfaces); and it maps interface error rate patterns to error rate characteristics of event attribute characteristics (describing the error rate performance characteristics of interfaces, such as the distribution of high-error-rate interfaces); it integrates response latency and error rate characteristics to generate event attribute characteristics.

[0158] This solution analyzes historical traffic peak characteristics to identify periodic and bursty time patterns, addressing the lack of dynamic analysis capabilities. Predictable patterns are generated from historical traffic peak characteristics, preventing resource optimization delays. Interface call path characteristics are analyzed to identify interface response latency and error rate patterns, addressing the deficiencies in response priority and concurrency logic. Pattern data is generated from interface call path characteristics to ensure adaptive settings for interface concurrency logic. Based on periodic, bursty, interface response latency, and interface error rate patterns, time and event attribute characteristics are determined, resolving scalability deficiencies. Attribute characteristics are generated by integrating pattern data to ensure dynamic configuration adjustments as network usage expands.

[0159] In some embodiments, network usage scenarios are extracted to determine scenario characteristic parameters; historical traffic data is analyzed to identify traffic anomalies; based on event type classification rules, the initial matching type is determined according to the traffic anomalies and scenario characteristic parameters; combined with network usage scale, the initial matching type is verified to determine the network congestion event type.

[0160] Scene feature parameters can be quantitative feature parameters extracted from network usage scenarios to describe the dynamic characteristics of the application environment.

[0161] Historical traffic data can be derived from historical event data and is used to analyze network usage scale and time attributes; these are traffic-related metrics.

[0162] Traffic anomalies can be points of abnormal fluctuation identified when analyzing historical traffic data.

[0163] The initial matching type can be a network congestion event type initially determined based on the event type classification rules.

[0164] Specifically, network usage scenarios (such as user platforms or online education platforms) are extracted from the network setup requirements submitted by customers. Based on the network usage scenarios, a pre-set scenario database (which stores common scenario templates from historical event data) is queried to map scenario feature parameters. For example, for user platforms, scenario feature parameters include page types (product details page and checkout page) and event triggering frequency (high-concurrency interface call mode).

[0165] Calculate the average and standard deviation of historical traffic data within a specified time window (a fixed time range for calculating the average and standard deviation of traffic data); compare the current traffic value with the historical average; if the comparison result exceeds the standard deviation threshold set based on historical event data (used to determine whether the traffic value is abnormal), mark it as a traffic anomaly point.

[0166] Based on the traffic anomaly points and scene feature parameters, a similarity score is calculated using event type classification rules. The initial matching type is determined based on the similarity score. For example, if the scene feature parameter is e-commerce and the traffic anomaly point occurs during a holiday, then it is matched as a holiday promotion event.

[0167] The network usage scale is compared with the scale threshold set based on historical event data corresponding to the initial matching type (used to verify whether the network usage scale causes congestion). If the network usage scale exceeds the scale threshold, the verification is passed and the network congestion event type is determined. If the network usage scale does not reach the scale threshold, the event type classification rules are adjusted (such as reducing the similarity score), the initial matching type is re-determined, and the verification is repeated until the final network congestion event type is determined.

[0168] This solution extracts network usage scenarios, determines scenario characteristic parameters, and addresses the deficiency of missing event attribute characteristics. It analyzes historical traffic data to identify traffic anomalies and expose sudden congestion that cannot be handled. Based on event type classification rules, it determines the initial matching type according to traffic anomalies and scenario characteristic parameters, solving the problem of unpredictable network congestion event types and avoiding the blindness of static solutions. Combined with network usage scale, the initial matching type is validated to determine the network congestion event type, ensuring that the results match actual scale requirements and avoiding misallocation of resources.

[0169] In some embodiments, historical event data is parsed to obtain user clickstream data; the user clickstream data is analyzed to determine the page dwell time distribution and click heatmap; based on the page dwell time distribution and click heatmap, content attention indicators are determined; and by combining event attribute characteristics and content attention indicators, low-attention events are filtered out to determine event browsing preferences.

[0170] User clickstream data can be a record of the sequence of clicks a user makes on a page.

[0171] Page dwell time distribution can be a statistical distribution of the time a user spends on a single page.

[0172] A click heatmap is a density distribution map of the locations clicked by users on a page.

[0173] Content attention metrics can be numerical indicators that quantify the degree of user attention to page content.

[0174] Low-attention events can be those whose content attention metrics are below a preset threshold.

[0175] Specifically, the user behavior logs in historical event data are parsed to identify fields such as user identifier (e.g., user ID), page access events (e.g., the page path visited), click events (e.g., button or link clicks), and timestamps (recording the precise time the event occurred) for each user behavior log record; these records are then aggregated to generate user clickstream data.

[0176] Based on user clickstream data, for each page (such as the product details page on a user's platform), calculate the time users spend on each page (the difference between the page entry timestamp and the exit timestamp); aggregate the time spent by all users to generate a page dwell time distribution, for example, statistically analyze the frequency distribution of dwell time on the product details page and display the percentage of users in different dwell time periods.

[0177] Click events (records of user clicks on interactive elements (such as buttons, links, or images) on different pages) are extracted from user clickstream data and mapped to page areas (such as the positions of buttons and images on the page); the click frequency of each page area is counted (such as the number of times the payment button is clicked on the checkout page) and visualized as a click heatmap (where high-density areas represent high-frequency click locations).

[0178] Assign weights to the page dwell time distribution and click heatmap (where longer dwell time indicates higher attention and higher click density indicates higher attention); then calculate the weighted score of the page dwell time distribution weight and the click heatmap weight as a content attention indicator.

[0179] Based on the characteristics of event attributes and content attention metrics, associate each event (such as a single user session or page visit event) with a content attention metric; pre-set a preset threshold based on statistical experience of historical event data (used as a criterion when filtering low attention events); traverse all events and remove events with content attention metrics below the preset threshold (i.e., low attention events); then statistically analyze the frequency distribution of page identifiers for the remaining events to determine event browsing preferences.

[0180] This solution analyzes historical event data to obtain user clickstream data, addressing the lack of dynamic analysis capabilities. Analyzing the user clickstream data determines page dwell time distribution and click heatmaps, eliminating issues related to missing response priorities and concurrency logic. Based on the page dwell time distribution and click heatmaps, content attention metrics are determined, ensuring event browsing preferences are based on quantitative data to address insufficient scalability. Combining event attribute characteristics and content attention metrics, low-attention events are filtered out, event browsing preferences are determined, and issues related to missing response priorities and concurrency logic are eliminated.

[0181] In some embodiments, a preference weight is assigned to each content unit based on event browsing preferences; historical traffic peak characteristics are analyzed to determine the unit loading delay tolerance; a priority score is calculated based on the preference weight and the unit loading delay tolerance; and several content units are sorted based on the priority score to obtain the front-end response priority.

[0182] Preference weights can be numerical values ​​representing the intensity of user preference for each content unit.

[0183] Unit loading latency tolerance can be a time threshold representing the maximum acceptable latency for each content unit during loading.

[0184] Priority score can be a numerical value used to quantify the loading priority order of each content unit.

[0185] Specifically, iterate through all content units (for example, identify all content units in the user platform front-end page, such as product images and purchase buttons); for each content unit, query its corresponding frequency value in event browsing preferences; and assign preference weights to each content unit based on the frequency value.

[0186] Analyze historical traffic peak characteristics to identify the performance of each content unit during historical peak events (instances with abnormally high traffic in historical event data, such as flash sales) (e.g., extract the average response latency of the unit during peak periods from user behavior logs); then, based on preset rules established from historical performance data, determine the unit's loading latency tolerance. For example, compare the performance of content units during historical peak events; if the average latency of the content unit is high during peak periods, reduce its tolerance; if the average latency of the content unit is low during peak periods, increase its tolerance.

[0187] Based on preference weights and unit loading latency tolerance, a weighted formula is used to calculate priority scores, where a high score indicates high loading priority (high preference weight and low unit loading latency tolerance), and a low score indicates low priority. Based on these priority scores, a quicksort algorithm is used to sort several content units in descending order of priority score, thereby generating the front-end response priority, with the highest-scoring units loaded first.

[0188] This solution assigns preference weights to each content unit based on event browsing preferences, ensuring that response priority ranking prioritizes high-preference content units, thus optimizing the initial basis for front-end loading in dynamic network environments. Historical traffic peak characteristics are analyzed to determine unit loading latency tolerance and identify the performance weaknesses of each content unit under pressure scenarios, ensuring that response priority ranking prioritizes low-tolerance content units, thereby alleviating interface congestion. Priority scores are calculated based on preference weights and unit loading latency tolerances, ensuring response priority while considering user behavior and network performance requirements. Based on the priority scores, several content units are ranked to obtain the front-end response priority, ensuring that high-priority content units respond quickly in dynamic events, reducing latency and error rates, optimizing content loading order, and resolving the issue of missing response priorities.

[0189] In some embodiments, the characteristics of historical traffic peaks are analyzed to determine the peak concurrency threshold; the characteristics of interface call paths are analyzed to determine the interface dependency graph; based on the peak concurrency threshold and the interface dependency graph, an interface call concurrency strategy and a timeout fallback mechanism are generated; and the interface call concurrency strategy and timeout fallback mechanism are used as the interface concurrency logic of the application layer.

[0190] The peak concurrency threshold can be the upper limit of the maximum number of concurrent calls allowed by the application layer interface.

[0191] An interface dependency graph can be a graph data structure that represents the call dependencies between application layer interfaces.

[0192] API call concurrency strategies can be concurrency scheduling rules used to control the order and number of concurrent calls to application layer APIs.

[0193] The timeout fallback mechanism can be the handling logic when an interface call times out.

[0194] Specifically, the timestamp and request volume data in the historical traffic peak characteristics are analyzed to identify historical peak events, and the number of concurrent requests for each historical peak event is counted. The maximum value of the maximum number of concurrent requests is set as the peak concurrency threshold.

[0195] Each application layer interface is represented as a node (for example, node A represents the product query interface and node B represents the inventory check interface). Based on the call order in the interface call path characteristics, directed edges are added between nodes (for example, an edge from node A to node B indicates that the product query interface calls the inventory check interface), thereby constructing an interface dependency graph.

[0196] The dependencies in the interface dependency graph are analyzed, and concurrent call rules are designed. For interfaces without dependencies (independent nodes in the graph), a parallel call strategy is set (a concurrent execution rule designed for nodes without dependencies in the interface dependency graph, such as allowing multiple independent interfaces to be called concurrently). For interfaces with dependencies (nodes connected by directed edges in the graph), a serial call strategy is set (a sequential execution rule designed for nodes with dependencies in the interface dependency graph, such as calling the parent interface first and then the child interface). Then, combined with the peak concurrency threshold, a concurrency limit is assigned to each interface, thereby generating the interface call concurrency strategy.

[0197] Based on the interface dependency graph, identify potential timeout risk points (interface nodes in the interface dependency graph that are prone to response timeouts); set a timeout threshold (maximum allowed response time) for each interface and generate a timeout fallback mechanism, such as triggering a fallback to a preset backup path if an interface call times out. Integrate the interface call concurrency strategy and the timeout fallback mechanism to determine the application layer's interface concurrency logic.

[0198] This solution analyzes historical traffic peak characteristics to determine peak concurrency thresholds, reflecting the maximum concurrent pressure of historical peak events and addressing the inability to predict time-related characteristics. It analyzes API call path characteristics to determine API dependency graphs, eliminating the inability to parse event attribute characteristics. Based on peak concurrency thresholds and API dependency graphs, it generates API call concurrency strategies and timeout fallback mechanisms, optimizing application-layer API call logic, preventing congestion caused by multiple simultaneous triggers of the same API, and alleviating pressure in high-concurrency scenarios. It also eliminates response timeout or error issues, preventing the entire chain from paralyzing due to single API blockage and reducing user experience degradation. By incorporating the API call concurrency strategies and timeout fallback mechanisms into the application-layer API concurrency logic, it eliminates the deficiency of missing application-layer API concurrency logic.

[0199] In some embodiments, historical event data is parsed to obtain user behavior logs and network traffic logs; user behavior logs are analyzed to determine user behavior patterns; network traffic logs are analyzed to determine traffic fluctuation patterns; and event type classification rules are determined based on user behavior patterns and traffic fluctuation patterns.

[0200] User behavior logs can be structured log files parsed from historical event data, including user ID, operation type, timestamp, API call path, etc.

[0201] Network traffic logs can be structured log files parsed from historical event data, including interface request volume, response time, data throughput, etc.

[0202] User behavior patterns can be identified by analyzing user behavior logs, which can be used to determine high-frequency operation sequences or quantitative characteristics of user preference distributions.

[0203] Traffic fluctuation patterns can be quantitative characteristics of traffic peaks or fluctuation patterns determined by analyzing network traffic logs.

[0204] Specifically, the system parses user operation records (including user ID, operation type, timestamp, API call path, etc.) from historical event data to generate user behavior logs; it also parses network traffic records (including API request volume, response time, data throughput, etc.) from historical event data to generate network traffic logs.

[0205] Iterate through the operation types and timestamps in the user behavior log to identify high-frequency operation sequences (e.g., counting the number of times the product search → shopping cart addition sequence appears in the user behavior log); based on the operation type, determine the user behavior pattern (e.g., user browsing preferences), for example, by counting the proportion of operation types (e.g., browsing gift pages) to identify high-frequency behaviors (user operations that occur frequently); then, summarize the high-frequency operation sequences and user behavior patterns into a user behavior pattern.

[0206] The system iterates through the interface request volume and response time in the network traffic logs to identify historical peak events. By comparing the interface request volume with the baseline value (average request volume), it locates sudden peaks (abnormal events where the interface request volume suddenly and significantly increases). Then, it statistically analyzes traffic fluctuation patterns (dynamic changes in network traffic) and marks periodic patterns (such as peaks occurring at fixed times each day during holiday events). Finally, it summarizes sudden peaks and periodic patterns into a traffic fluctuation pattern.

[0207] Match user behavior patterns with traffic fluctuation patterns (for example, if user behavior patterns show high-frequency concurrent API calls and traffic fluctuation patterns show sudden peaks, they are associated with the same event); based on the matching results, determine the event type classification rules. For example, if user behavior patterns show browsing preferences concentrated in a certain product category and traffic fluctuation patterns show periodic peaks, it is classified as a holiday event; if user behavior patterns show a high-concurrency API call sequence and traffic fluctuation patterns show sudden peaks, it is classified as a flash sale event.

[0208] This solution analyzes historical event data to obtain user behavior logs and network traffic logs, correlates them with user behavior pattern analysis requirements, supports the quantification of traffic fluctuation patterns, and avoids the coupling of operation records and traffic metrics in the analysis. Analyzing user behavior logs identifies user behavior patterns, addressing the inability to predict event attributes. Analyzing network traffic logs identifies traffic fluctuation patterns, eliminating the inability to predict time-related attributes. Based on user behavior patterns and traffic fluctuation patterns, event type classification rules are determined, addressing the core deficiency of lacking dynamic analysis capabilities.

[0209] Figure 3 This is a schematic diagram of the structure of a self-built network construction system provided in an embodiment of this application, as shown below. Figure 3 As shown, the self-built network construction system 300 in this embodiment includes: a requirement analysis module 301, a feature determination module 302, an event feature analysis module 303, and a time feature analysis module 304.

[0210] The requirement analysis module 301 is used to obtain network construction requirements; analyze the network construction requirements, and determine the network usage scenarios and network usage scale.

[0211] The feature determination module 302 is used to determine the time attribute features and event attribute features based on the network usage scenario and the network usage scale.

[0212] The event characteristic analysis module 303 is used to determine the front-end response priority and application layer interface concurrency logic based on the event attribute characteristics.

[0213] The time characteristic analysis module 304 is used to determine the response priority of the front end and the triggering timing of the application layer interface concurrency logic based on the time attribute characteristics.

[0214] Optionally, when the feature determination module 302 determines the time attribute features and event attribute features based on the network usage scenario and the network usage scale, it is used to: acquire historical event data, analyze the historical event data, and determine event type classification rules; based on the event type classification rules, analyze the network usage scenario and determine network congestion event types; based on the network congestion event types, analyze the historical event data and determine historical traffic peak characteristics and interface call path characteristics; and determine the time attribute features and event attribute features based on the historical traffic peak characteristics and the interface call path characteristics.

[0215] Optionally, when the event characteristic analysis module 303 determines the front-end response priority and application layer interface concurrency logic based on the event attribute characteristics, it is used to: determine the user's browsing core and browsing page content based on the event attribute characteristics; analyze the historical event data to determine the event browsing preference; split the browsing page content to obtain several content units; prioritize the several content units based on the event browsing preference to obtain the front-end response priority; and generate application layer interface concurrency logic based on the historical traffic peak characteristics and the interface call path characteristics.

[0216] Optionally, when the feature determination module 302 determines the time attribute characteristics and event attribute characteristics based on the historical traffic peak characteristics and the interface call path characteristics, it is used to: analyze the historical traffic peak characteristics to determine periodic time patterns and burst time patterns; analyze the interface call path characteristics to determine interface response delay patterns and interface error rate patterns; and determine the time attribute characteristics and event attribute characteristics based on the periodic time patterns, the burst time patterns, the interface response delay patterns, and the interface error rate patterns.

[0217] Optionally, the historical event data includes historical traffic data. When the feature determination module 302 analyzes the network usage scenario based on the event type classification rules to determine the network congestion event type, it is used to: extract the network usage scenario and determine scenario feature parameters; analyze the historical traffic data and identify traffic anomalies; determine the initial matching type based on the event type classification rules, the traffic anomalies, and the scenario feature parameters; and verify the initial matching type in conjunction with the network usage scale to determine the network congestion event type.

[0218] Optionally, when the event feature analysis module 303 analyzes the historical event data to determine event browsing preferences, it is used to: parse the historical event data to obtain user clickstream data; analyze the user clickstream data to determine the page dwell time distribution and click heatmap; determine the content attention index based on the page dwell time distribution and the click heatmap; and filter low-attention events by combining the event attribute characteristics and the content attention index to determine event browsing preferences.

[0219] Optionally, when the event feature analysis module 303 prioritizes several content units based on the event browsing preferences to obtain the front-end response priority, it is used to: assign preference weights to each content unit according to the event browsing preferences; analyze the historical traffic peak characteristics to determine the unit loading delay tolerance; calculate the priority score according to the preference weights and the unit loading delay tolerance; and sort the several content units based on the priority scores to obtain the front-end response priority.

[0220] Optionally, when the event characteristic analysis module 303 generates application-layer interface concurrency logic based on the historical traffic peak characteristics and the interface call path characteristics, it is used to: analyze the historical traffic peak characteristics to determine the peak concurrency threshold; analyze the interface call path characteristics to determine the interface dependency graph; generate an interface call concurrency strategy and a timeout fallback mechanism based on the peak concurrency threshold and the interface dependency graph; and use the interface call concurrency strategy and the timeout fallback mechanism as the application-layer interface concurrency logic.

[0221] Optionally, when the feature determination module 302 analyzes the historical event data and determines the event type classification rules, it is used to: parse the historical event data to obtain user behavior logs and network traffic logs; analyze the user behavior logs to determine user behavior patterns; analyze the network traffic logs to determine traffic fluctuation patterns; and determine event type classification rules based on the user behavior patterns and the traffic fluctuation patterns.

[0222] The system in this embodiment can be used to execute the methods of any of the above embodiments, and its implementation principle and technical effect are similar, so they will not be described again here.

Claims

1. A method for building a self-constructing network, characterized in that, include: Obtain network setup requirements; analyze the network setup requirements to determine network usage scenarios and network usage scale; Based on the network usage scenario and the network usage scale, determine the time attribute characteristics and event attribute characteristics, including: Acquire historical event data, analyze the historical event data, and determine the event type classification rules; Based on the event type classification rules, the network usage scenarios are analyzed to determine the types of network congestion events; Based on the network congestion event types, the historical event data is analyzed to determine the characteristics of historical traffic peaks and interface call paths. Based on the historical traffic peak characteristics and the interface call path characteristics, the time attribute characteristics and event attribute characteristics are determined, including: Analyze the characteristics of the historical traffic peaks to determine periodic and sudden time patterns; Analyze the characteristics of the interface call path to determine the interface response delay pattern and interface error rate pattern; Based on the periodic time pattern, the burst time pattern, the interface response delay pattern, and the interface error rate pattern, determine the time attribute characteristics and event attribute characteristics; Based on the characteristics of the event attributes, determine the response priority of the front end and the interface concurrency logic of the application layer; Based on the time attribute characteristics, the response priority of the front end and the triggering timing of the application layer's interface concurrency logic are determined.

2. The method according to claim 1, characterized in that, The step of determining the front-end response priority and application-layer interface concurrency logic based on the event attribute characteristics includes: Based on the characteristics of the event attributes, determine the core content of the user's browsing and the content of the browsed pages; Analyze the historical event data to determine event browsing preferences; The content of the browsed page is broken down into several content units; Based on the aforementioned event browsing preferences, several content units are prioritized to obtain the front-end response priority; Based on the historical traffic peak characteristics and the interface call path characteristics, the application layer interface concurrency logic is generated.

3. The method according to claim 1, characterized in that, The historical event data includes historical traffic data. The process of analyzing network usage scenarios and determining network congestion event types based on the event type classification rules includes: Extract the network usage scenarios and determine the scenario feature parameters; Analyze the historical traffic data to identify traffic anomalies; Based on the event type classification rules, the initial matching type is determined according to the traffic anomaly points and the scene feature parameters; Based on the network usage scale, verify the initial matching type and determine the network congestion event type.

4. The method according to claim 2, characterized in that, The analysis of the historical event data to determine event browsing preferences includes: The historical event data is parsed to obtain user clickstream data; Analyze the user clickstream data to determine the page dwell time distribution and click heatmap; Based on the page dwell time distribution and the click heatmap, determine the content attention index; By combining the event attribute characteristics and the content attention index, low-attention events are filtered out to determine event browsing preferences.

5. The method according to claim 2, characterized in that, The process of prioritizing several content units based on the event browsing preferences to obtain the front-end response priority includes: Based on the event browsing preferences, assign preference weights to each content unit; Analyze the characteristics of the historical traffic peaks to determine the unit loading delay tolerance; Calculate the priority score based on the preference weights and the unit loading delay tolerance; Based on the priority scores, the content units are sorted to obtain the front-end response priority.

6. The method according to claim 2, characterized in that, The step of generating application-layer interface concurrency logic based on the historical traffic peak characteristics and the interface call path characteristics includes: Analyze the characteristics of the historical traffic peaks to determine the peak concurrency threshold; Analyze the characteristics of the interface call paths to determine the interface dependency graph; Based on the peak concurrency threshold and the interface dependency graph, an interface call concurrency strategy and a timeout fallback mechanism are generated. The interface call concurrency strategy and the timeout fallback mechanism are used as the interface concurrency logic of the application layer.

7. The method according to claim 1, characterized in that, The analysis of the historical event data to determine event type classification rules includes: The historical event data is parsed to obtain user behavior logs and network traffic logs; Analyze the user behavior logs to determine user behavior patterns; Analyze the network traffic logs to determine the traffic fluctuation pattern; Based on the user behavior patterns and the traffic fluctuation patterns, determine the event type classification rules.

8. A self-constructing network building system, characterized in that, Applied to the method as described in any one of claims 1-7, comprising: The requirement analysis module is used to obtain network construction requirements; analyze the network construction requirements to determine the network usage scenarios and network usage scale; The feature determination module is used to determine time attribute features and event attribute features based on the network usage scenario and the network usage scale, including: Acquire historical event data, analyze the historical event data, and determine the event type classification rules; Based on the event type classification rules, the network usage scenarios are analyzed to determine the types of network congestion events; Based on the network congestion event types, the historical event data is analyzed to determine the characteristics of historical traffic peaks and interface call paths. Based on the historical traffic peak characteristics and the interface call path characteristics, the time attribute characteristics and event attribute characteristics are determined, including: Analyze the characteristics of the historical traffic peaks to determine periodic and sudden time patterns; Analyze the characteristics of the interface call path to determine the interface response delay pattern and interface error rate pattern; Based on the periodic time pattern, the burst time pattern, the interface response delay pattern, and the interface error rate pattern, determine the time attribute characteristics and event attribute characteristics; The event characteristic analysis module is used to determine the front-end response priority and application layer interface concurrency logic based on the event attribute characteristics. The time characteristic analysis module is used to determine the response priority of the front end and the triggering timing of the application layer's interface concurrency logic based on the time attribute characteristics.

Images