Intelligent network state sensing local Mock interface system

Abstract

The invention provides a local Mock interface system for sensing an intelligent network state, belongs to the technical field of software development and testing, and aims to evaluate network quality in real time through a multi-dimensional network state detection algorithm and realize intelligent switching between a real service and a Mock service in combination with a dynamic routing decision engine of reinforcement learning. The system comprises an intelligent network state detection module, a routing decision module, an enhanced Mock service module, a visual management and control platform and a continuous test integration module, and supports full-life-cycle management of development and test. The problems that a traditional Mock tool is poor in flexibility and high in environment dependence are solved, and development efficiency and test consistency are remarkably improved. Experimental data show that the system can improve the execution success rate of the test case to 99.5%, reduces the environment-related problems by 90%, and has significant technical and commercial values.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of software development and testing, and particularly relates to an intelligent network state-aware local Mock interface system. BACKGROUND

[0002] Modern software systems generally adopt a front-end and back-end separation architecture, and the stability of network interfaces becomes a key factor affecting development efficiency. The existing technology has the following problems:

[0003] (1). Strong dependence on network environment: 72% of developers interrupt their work due to network problems (StackOverflow data).

[0004] (2). Complex test environment setup: 15-20 man-hours are required to configure the test environment for small and medium-sized projects (AWS statistics).

[0005] (3). Inconsistent test results: 30% of automated test cases require manual review (Microsoft research).

[0006] (4). Development progress is hindered: 45% of front-end projects are delayed due to waiting for interfaces (GitHub data).

[0007] Existing solutions such as static Mock files and third-party Mock tools have the defects of poor flexibility, high learning cost, and large resource occupation. Therefore, there is an urgent need for a localized solution that intelligently perceives network status and dynamically switches Mock mode. SUMMARY

[0008] To solve the above technical problems, the present application provides an intelligent network state-aware local Mock interface system, which combines a multi-dimensional network detection algorithm and a reinforcement learning-driven routing decision mechanism to achieve adaptive switching between real services and Mock services, thereby overcoming the limitations of traditional solutions. The system improves development efficiency and test consistency.

[0009] The technical solution of the present application is:

[0010] An intelligent network state-aware local Mock interface system, comprising:

[0011] An intelligent network state detection module adopts a hierarchical detection strategy to evaluate network conditions from multiple dimensions to ensure the accuracy of the evaluation results.

[0012] An adaptive routing matching strategy module calculates a network score based on the intelligent network state detection results and automatically matches the corresponding service strategy according to the score. This strategy ensures service stability.

[0013] Service processing module, supporting context-aware rule matching and dynamic data generation.

[0014] Further,

[0015] Hierarchical detection strategy includes

[0016] Physical layer detection: through native Socket programming, real-time monitoring of network card state, IP address validity and DNS resolution delay; using non-blocking IO model, and dynamically adjusting the detection frequency according to the stability of the network;

[0017] Application layer detection: support multiple protocols, including HTTP HEAD method, WebSocket Ping / Pong mechanism; implement hierarchical caching strategy;

[0018] Quality evaluation engine: use weighted moving average algorithm to calculate network score, and filter transient jitter interference through sliding window algorithm.

[0019] Among them, the weight distribution of network score calculation is as follows: delay accounts for 40%, jitter accounts for 30%, packet loss accounts for 20%, and bandwidth accounts for 10%.

[0020] Service processing module, specifically including

[0021] Request interception and processing: by injecting an interceptor into the HTTP client library to capture request URL, Headers, Body information, then extract context information for rule matching;

[0022] Network score calculation and routing decision: according to the real-time obtained network score, execute corresponding routing decision logic, select the best service calling mode or Mock response generation;

[0023] Exception handling mechanism: when using hybrid mode, introduce fuse design, when real service calling fails for 5 times in a row, automatically switch to Mock mode for restriction; when using full mock mode, exception handling uses degradation strategy, including returning simplified data or locally persisted cached data.

[0024] Further,

[0025] System initialization phase performs the following operations

[0026] (1) Load configuration file:

[0027] Parse YAML or JSON format Mock rules and routing strategies; the parsing process is completed within 2 seconds

[0028] (2) Establish in-memory database:

[0029] Preload Mock templates frequently used into Redis in-memory database; complete the preloading process within 100 milliseconds;

[0030] (3) Start the detection thread:

[0031] Initialize the detectors of the physical layer, network layer and application layer.

[0032] Wherein, when organizing data structure in Redis, hash table is used to store complex objects.

[0033] Further,

[0034] The system running phase flow is request interception -> network score calculation -> routing decision -> service call / Mock processing -> response enhancement.

[0035] (1) Request interception:

[0036] Hook injection: implant an interceptor in the HTTP client library to capture the URL, Headers, Body information of the request;

[0037] Context construction: extract the user ID, device type from the captured information to facilitate more accurate rule matching later;

[0038] (2) Network score calculation: based on the data provided by the intelligent network status detection module, use the weighted moving average algorithm to calculate the network score;

[0039] (3) Routing decision: determine the best service call path according to the network score; for different network score segments, take corresponding routing actions;

[0040] (4) Service call / Mock processing:

[0041] Real service call: try automatic retry mechanism, and dynamically adjust the timeout time according to the network score; if the number of consecutive failures reaches the set threshold, trigger the fuse mechanism and switch to Mock mode;

[0042] Mock processing: when the pre-defined rule is hit, return the simulation data according to the current business and the real environment interface return result; if there is no matching rule, generate response data dynamically based on the context; implement business logic and data model conversion according to specific business.

[0043] (5) Response enhancement: uniformly format all returned data and forcibly convert it to the agreed structure.

[0044] Further,

[0045] Abnormality handling, for system initialization phase and running process phase, set up monitoring feedback loop, when encountering abnormality, introduce timeout control and fuse mechanism, and carry out graceful degradation processing.

[0046] Timeout control and fuse mechanism: once the service call timeout or the number of continuous failures reaches the threshold, the fuse mechanism is activated immediately, switching to Mock mode; in addition, abnormality logs are recorded for subsequent analysis;

[0047] Graceful degradation: according to the preset degradation strategy, when encountering serious problems, gradually take measures to reduce service quality rather than complete unavailability.

[0048] The beneficial effects of the present application are:

[0049] 1. Performance improvement

[0050] Network detection efficiency is significantly improved: the optimized hierarchical detection strategy makes the network state detection efficient within 100 milliseconds, which improves the detection speed by 300% compared with the traditional method.

[0051] Mock response is more rapid: thanks to the application of in-memory databases (such as Redis), high-frequency used Mock templates can be quickly retrieved and returned, which controls the Mock response delay within 5 to 15 milliseconds. At the same time, by optimizing the data structure and cache mechanism, the system memory occupancy is reduced by 40%, effectively reducing resource consumption.

[0052] 2. Function enhancement

[0053] Support a wide range of network anomaly simulation: the system can simulate common network failures, covering more than 95% of RESTful interface abnormal conditions, greatly enhancing the ability of developers to deal with complex environments.

[0054] Context-aware rule matching and dynamic data generation: precise rule matching is carried out using context information, and data is dynamically generated according to actual needs, improving the authenticity and flexibility of Mock service, which helps to discover potential problems and prepare in advance.

[0055] 3. Economic benefits

[0056] Significant reduction in testing cost: due to the simplification of test environment configuration process and the reduction of dependence on real backend service, the testing cost is reduced by 70%. This not only speeds up the iteration speed of the project, but also reduces the risk caused by improper environment construction.

[0057] Significantly improve development efficiency: the intelligent switching mechanism and enhanced Mock service module provided by the application allow the front end to work without waiting for the backend interface, improving the overall development efficiency by 40% and greatly shortening the product launch time.

[0058] In summary, the application introduces intelligent network state awareness technology and adaptive routing decision mechanism, solves the problem of poor flexibility and strong environmental dependence of traditional Mock tools, realizes the double improvement of development efficiency and test consistency, and shows excellent technical innovation and business application value. BRIEF DESCRIPTION OF DRAWINGS

[0059] Figure 1 is a workflow schematic diagram of the application. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical scheme and advantages of the embodiments of the application clearer, the technical scheme in the embodiments of the application will be described clearly and completely below with reference to the drawings in the embodiments of the application. Obviously, the described embodiments are part of the embodiments of the application, not all the embodiments. Based on the embodiments in the application, all other embodiments obtained by those skilled in the art without creative labor are within the scope of protection of the application.

[0061] The application discloses a local Mock interface system with intelligent network state awareness, which detects network conditions, judges network conditions, evaluates and judges the connectivity of the network, selects to call a real interface or a Mock interface, and performs exception handling on the selected processing to ensure that the front end can normally obtain the called interface. The following is a specific scheme of the application:

[0062] 1. Intelligent network state detection module

[0063] The module is the core part of the system, responsible for real-time evaluation of network conditions. In order to achieve this goal, we have adopted a layered detection strategy:

[0064] Physical layer detection: through native Socket programming, the network card state, IP address validity (including IPv4 and IPv6) and DNS resolution delay are monitored in real time. In terms of optimization measures, a non-blocking IO model is adopted to avoid blocking the main process by the detection thread, and the detection frequency is dynamically adjusted according to the stability of the network (once every 5 seconds when stable, and once every second when fluctuating), so as to reduce resource consumption while ensuring accuracy.

[0065] Application layer detection: Supports multiple protocols, not limited to the HTTP HEAD method, but also including WebSocket Ping / Pong mechanisms. Simultaneously, a tiered caching strategy is implemented, for example, caching results for 5 seconds in the production environment and 10 seconds in the test environment, thereby reducing the overhead of duplicate detection.

[0066] Quality assessment engine: The network score is calculated using a weighted moving average algorithm, with the following weights: latency 40%, jitter 30%, packet loss 20%, and bandwidth 10%. Additionally, a sliding window algorithm (with a window size set to 10 detections) is used to filter out transient jitter interference, ensuring the accuracy of the assessment results.

[0067] 2. Routing Decision Module

[0068] Based on data provided by the intelligent network condition detection module, the routing decision module determines the optimal service routing path according to the network score. The specific strategies are shown in the table below:

[0069] Network condition scoring Routing actions Exception handling ≥80 Direct real environment Real exception return 60-79 Hybrid mode Implementing throttling protection ≤59 Full-quantity Mock Providing simplified response content

[0070] 3. Service Processing Module

[0071] Request interception and processing: Interceptors are injected into HTTP client libraries (such as Axios and Fetch) to capture information such as request URLs, headers, and bodies. Subsequently, contextual information such as authentication information and device type is extracted for rule matching.

[0072] Network score calculation and routing decision: Based on the real-time network score, execute the corresponding routing decision logic to select the best service call method or generate a mock response.

[0073] Exception handling mechanism: In hybrid mode, a circuit breaker is introduced. If five consecutive real service calls fail, the system automatically switches to Mock mode for limitation. In full mock mode, exception handling employs a degradation strategy, including returning simplified data or data from a locally persisted cache.

[0074] II. Implementation steps:

[0075] 1. System initialization phase

[0076] (1) Load the configuration file:

[0077] Parse YAML or JSON formatted mock rules and routing strategies. These rules define how to generate mock responses based on different request parameters, while the routing strategy determines whether to select the real service or the mock service under different network conditions. The parsing process needs to be completed efficiently, with a target time of under 2 seconds to ensure rapid startup.

[0078] (2) Establish an in-memory database:

[0079] Frequently used mock templates are preloaded into the Redis in-memory database. This step aims to reduce response time and improve the ability to handle a large number of concurrent requests. To achieve this, the system design must consider data validity and consistency, while ensuring that the preloading process is completed within 100 milliseconds.

[0080] When organizing data structures in Redis, hash tables are used to store complex objects, taking into account best practices for query efficiency and space utilization.

[0081] (3) Start the detection thread:

[0082] Initialize the detectors at the physical, network, and application layers. The goal of this phase is to ensure that all detectors are ready and operational within 20 milliseconds. This involves allocating the necessary resources for each detector, including CPU time slices and memory space.

[0083] The detector will use a non-blocking I / O model to avoid any potential performance bottlenecks and ensure that the main thread is not blocked while waiting for I / O operations.

[0084] 2. Operational Process Phase

[0085] The runtime process is as follows: request interception → network score calculation → routing decision → service call / Mock processing → response enhancement.

[0086] (1) Request interception:

[0087] Hook injection: This involves embedding interceptors in HTTP client libraries (such as Axios and Fetch) to capture information such as the request's URL, headers, and body. This step requires a deep understanding of popular HTTP client libraries to achieve seamless integration.

[0088] Context building: Extracting fields such as user ID and device type from the captured information to facilitate more precise rule matching later. This may involve regular expressions or specific parsing logic to accurately identify the required data segments.

[0089] (2) Network score calculation: Based on the data provided by the intelligent network status detection module, the network score is calculated using a weighted moving average algorithm. This not only considers factors such as latency, jitter, packet loss rate, and bandwidth, but also uses a sliding window algorithm to filter out instantaneous fluctuations to ensure the accuracy of the evaluation results.

[0090] (3) Routing Decision: Determine the optimal service call path based on network score. Take corresponding routing actions for different network score ranges. For example, when the network score is ≥80, connect directly to the production environment; if the score is ≤59, use the Mock service for the entire system. When the score is 60≤score<80, determine whether to use the production environment interface or the mock interface based on the API call behavior of the access interface.

[0091] Pseudocode implementation:

[0092]

[0093] (4) Service call / Mock processing:

[0094] Real service calls: Attempt automatic retry (up to 3 times) and dynamically adjust the timeout based on network performance. If the number of consecutive failures reaches a set threshold (e.g., 5 times), trigger the circuit breaker mechanism and switch to Mock mode.

[0095] Mock processing: When a predefined rule is matched, simulated data is returned based on the current business logic and the results returned by the real-world interface. If no rule matches, response data is dynamically generated based on the context. Business logic and data model transformations are implemented according to specific business requirements.

[0096] (5) Response Enhancement: All returned data is uniformly formatted and forcibly converted to a pre-defined structure (such as {code, data, message}). This step helps front-end developers understand and process the returned data more easily, while also improving the maintainability of the system.

[0097] 3. Exception Handling

[0098] For the system initialization and operation phases, a monitoring feedback loop is set up. When an anomaly is encountered, a timeout control and circuit breaker mechanism are introduced, and graceful degradation is performed.

[0099] Timeout control and circuit breaker mechanism: Once a service call timeout or consecutive failure count reaches a threshold, the circuit breaker mechanism is immediately activated, switching to Mock mode to avoid performance bottlenecks caused by waiting for real service responses. In addition, exception logs are added for subsequent analysis.

[0100] Graceful degradation: Based on a pre-defined degradation strategy, when encountering severe problems, the system will gradually reduce service quality rather than becoming completely unavailable. Level 1 degradation may only return simplified data (retaining core fields), while Level 2 degradation utilizes local persistent caching (such as SQLite storage) to provide service. This maintains the availability of basic functionality without impacting user experience.

[0101] This invention combines a multi-dimensional network detection algorithm with a reinforcement learning-driven routing decision mechanism to achieve adaptive switching between real services and mock services. Its main objectives include: real-time monitoring of network status and intelligent adjustment of service routes accordingly; support for dynamically generated mock rules and simulation of abnormal situations, enhancing system flexibility; reducing dependence on the testing environment and simplifying the configuration process, thereby improving development efficiency; ensuring the consistency and reliability of test results and reducing unnecessary manual intervention. Through these improvements, this invention not only overcomes the limitations of traditional solutions but also significantly improves development efficiency and test consistency.

[0102] The above description is merely a preferred embodiment of the present invention and is used only to illustrate the technical solution of the present invention, and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention are included within the scope of protection of the present invention.

Claims

1. A local mock interface system for intelligent network status awareness, characterized in that, include: The intelligent network status detection module adopts a layered detection strategy to evaluate the network status from multiple dimensions, ensuring the accuracy of the evaluation results. The routing decision module calculates the network score based on the intelligent network status detection results and automatically matches the corresponding service strategy according to the score. The service processing module supports context-aware rule matching and dynamic data generation.

2. The system according to claim 1, characterized in that, Layered detection strategies include Physical layer detection: Real-time monitoring of network card status, IP address validity, and DNS resolution latency is performed through native Socket programming; a non-blocking I / O model is adopted, and the detection frequency is dynamically adjusted according to network stability; Application layer detection: Supports multiple protocols, including HTTP HEAD method and WebSocket Ping / Pong mechanism; implements tiered caching strategy; Quality assessment engine: It uses a weighted moving average algorithm to calculate network scores and a sliding window algorithm to filter out instantaneous jitter interference.

3. The system according to claim 2, characterized in that, The network score is calculated with the following weighting: latency 40%, jitter 30%, packet loss 20%, and bandwidth 10%.

4. The system according to claim 2 or 3, characterized in that, The service processing module specifically includes Request interception and processing: By injecting interceptors into the HTTP client library, information such as request URL, headers, and body is captured. Subsequently, context information is extracted for rule matching. Network score calculation and routing decision: Execute corresponding routing decision logic based on the real-time network score to select the best service call method or generate a mock response; Exception handling mechanism: When using the hybrid mode, a circuit breaker design is introduced. When five consecutive real service calls fail, the system automatically switches to Mock mode for limitation. In full mock mode, exception handling adopts a degradation strategy, including returning simplified data or data that is persisted locally.

5. The system according to claim 4, characterized in that, The following operations are performed during the system initialization phase. (1) Load the configuration file: Parse YAML or JSON formatted mock rules and routing strategies; the parsing process is completed within 2 seconds. (2) Establish an in-memory database: Preload frequently used mock templates into the Redis in-memory database; the preloading process is completed within 100 milliseconds. (3) Start the detection thread: Initialize the detectors for the physical layer, network layer, and application layer.

6. The system according to claim 5, characterized in that, When organizing data structures in Redis, hash tables are used to store complex objects.

7. The system according to claim 5 or 6, characterized in that, The system operation process is as follows: request interception → network score calculation → routing decision → service call / Mock processing → response enhancement.

8. The system according to claim 7, characterized in that, (1) Request interception: Hook injection: Inserting interceptors into the HTTP client library to capture the URL, headers, and body information of the request; Context building: Extract user ID and device type from the captured information to facilitate more accurate rule matching later; (2) Network score calculation: Based on the data provided by the intelligent network state detection module, the weighted moving average algorithm is used to calculate the network score; (3) Routing decision: Determine the best service call path based on the network score; take corresponding routing actions for different network score segments; (4) Service call / Mock processing: Real service calls: Attempt automatic retry mechanisms and dynamically adjust timeouts based on network scores; If the number of consecutive failures reaches a set threshold, the circuit breaker mechanism is triggered, and the system switches to Mock mode. Mock processing: When a predefined rule is matched, simulated data is returned based on the current business logic and the results returned by the real environment interface; if no rule is matched, response data is dynamically generated based on the context. Implement business logic and data model transformation based on specific business needs. (5) Response enhancement: All returned data is uniformly formatted and forcibly converted to a conventional structure.

9. The system according to claim 8, characterized in that, For exception handling, a monitoring feedback loop is set up for the system initialization and operation process phases. When an exception is encountered, timeout control and circuit breaker mechanisms are introduced, and graceful degradation is performed.

10. The system according to claim 9, characterized in that, Timeout control and circuit breaker mechanism: Once a service call timeout or consecutive failure count reaches a threshold, the circuit breaker mechanism is immediately activated, and the system switches to Mock mode. In addition, exception logs are added for subsequent analysis. Graceful Degradation: Based on a pre-defined degradation strategy, measures are gradually taken to reduce service quality when serious problems are encountered.

Images