Method for simplifying reverse proxy system to acquire multi-dimensional traffic

Abstract

The invention belongs to the technical field of software testing, and particularly relates to a method for simplifying a reverse proxy system to acquire multi-dimensional traffic, which comprises the following steps of: constructing a closed-loop self-consistent system integrating traffic generation and response simulation, thoroughly breaking the strong coupling relationship between test logic and physical deployment architecture in the traditional test method, and improving the test efficiency. The complexity of a test environment is greatly simplified, hardware resources and operation and maintenance cost are remarkably reduced, testers are endowed with extremely high flexibility to define, combine and dynamically schedule multi-dimensional service scenes with any complexity, meanwhile, the reproducibility of the test is ensured by means of a deterministic data generation mechanism, and the test efficiency is improved. Therefore, a brand-new and systematic solution is provided for efficient, deep and comprehensive verification of the reverse proxy system.

Description

Technical Field

[0001] This invention belongs to the field of software testing technology, specifically a method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system. Background Technology

[0002] With the increasing prevalence of modern distributed network architectures and microservice systems, reverse proxy systems have become an indispensable key component of network service infrastructure. As the core hub between client requests and the backend real business service cluster, they undertake multiple critical functions, including but not limited to traffic distribution, load balancing, security policy enforcement, SSL / TLS encryption offloading, and static content caching. The stability, performance, and effectiveness of the upper-layer governance functions of the reverse proxy system directly determine the availability, response speed, and security level of the entire business system. Therefore, conducting comprehensive, rigorous, and real-world testing and verification of the reverse proxy system before system deployment or after feature iteration is a necessary step to ensure overall service quality.

[0003] To observe and evaluate the behavior and performance of reverse proxy systems under real load, a testing paradigm based on environment simulation is commonly used in the current technology field. Specifically, this technical solution follows a classic three-tier architecture: in the test environment, an independent client simulation cluster, the reverse proxy system under test, and a backend business service cluster are built. Its core design principle lies in generating a massive number of concurrent requests simulating real user behavior by running automated scripts on the client simulation cluster. These requests first traverse the network to reach the reverse proxy system, which then forwards them to a specific instance in the backend business service cluster according to its internally configured routing and load balancing strategies. The backend business service is typically implemented as a lightweight stub service at this stage, whose main responsibility is to provide a pre-defined, correctly formatted response based on the received requests. By constructing such an end-to-end, physically isolated test link, technicians can relatively realistically reproduce the online traffic model, thereby collecting key performance indicators of the reverse proxy system in handling large-scale concurrent connections, data forwarding, and session persistence. In specific historical periods, when business scenarios are relatively fixed and iteration cycles are long, this testing method, which aims to replicate high-fidelity environments, effectively solves the problems of early discovery of performance bottlenecks and functional verification in reverse proxy systems, providing solid data support for ensuring the stable operation of the system.

[0004] However, as software development models evolve towards agility, continuous integration, and continuous deployment (CI / CD), and business scenarios become increasingly complex and diverse, the inherent strong environmental coupling of the aforementioned technical solutions at the principle level gradually reveals profound limitations in addressing new challenges. The root cause lies in the fact that this testing paradigm deeply binds the richness of test logic to the complexity of the test infrastructure. Under this model, the dimension of test traffic—that is, the diversity of business scenarios—directly depends on the implementation complexity of the backend business service cluster and the degree of customization of the client-side simulation scripts. For example, if it is necessary to simultaneously verify the performance of a reverse proxy system in three distinct business scenarios—e-commerce shopping processes, online community content interaction, and online medical registration—it is essential to develop and deploy three separate backend stub service logics and three corresponding client-side automated access scripts for each scenario. This means that any expansion of the test scenario dimension inevitably leads to a linear or even exponential increase in the physical deployment and logic configuration costs of the test environment. This asset-heavy testing system, built in pursuit of the authenticity of traffic in a single dimension, inadvertently gives rise to a more hidden secondary problem: There is an inherent contradiction between the agility and coverage of testing. On the one hand, the rapidly iterating business requirements demand that testing be able to flexibly and efficiently combine and switch between various complex business processes. On the other hand, rigid and highly coupled testing infrastructure makes any change or addition to a scenario a complex systems engineering project involving the development, deployment, and integration of multiple components, significantly slowing down testing efficiency and inhibiting the possibility of exploring boundary conditions and abnormal paths. The generation of test data is also severely limited, its diversity constrained by pre-coded client and backend logic, making it difficult to dynamically generate sufficiently rich, random, and edge-case-covering data samples.

[0005] Therefore, a simplified method for obtaining multi-dimensional traffic in a reverse proxy system is proposed to address the above problems. Summary of the Invention

[0006] The purpose of this invention is to address the shortcomings of existing technologies by providing a simplified method for reverse proxy systems to acquire multi-dimensional traffic, thereby solving the technical problems mentioned in the background.

[0007] To address the above technical issues, the following technical solution is adopted: A method for simplifying the acquisition of multi-dimensional traffic by a reverse proxy system, comprising: The test service system, physically deployed on one or more computing nodes, includes an external request sending network interface and an internal request receiving network interface. The external request sending network interface is configured to send requests to the entry address of the reverse proxy system under test; the internal request receiving network interface is configured to receive requests forwarded by the reverse proxy system. The test service system integrates and runs a complete set of collaborative subsystems, including: a declarative scenario modeling subsystem, a stateful transaction simulation engine, a hierarchical asynchronous task scheduler, a probabilistic scenario distribution controller, and a data persistence and analysis subsystem.

[0008] Furthermore, the declarative scenario modeling subsystem is responsible for transforming abstract business processes into precise, machine-executable structured data objects. This subsystem provides a graphical user interface or a text interface based on a domain-specific language to receive user-defined business scenarios. Its core function is to parse and construct a scenario definition object from a complete business process—executively, a user registration, login, browsing products, adding items to the shopping cart, and finally payment—into a scenario definition object. The SDO is represented in data structure as a directed acyclic graph (DAG). Each node in the graph is defined as a transaction state object, representing a specific interaction step in the business process. Each directed edge in the graph is defined as a state transition rule, defining the triggering condition for transitioning from one transaction state to the next.

[0009] Furthermore, the transaction state object contains a set of precisely defined attribute fields to fully describe a network interaction round. These fields include: a unique state identifier; a request template containing a path template for the target Uniform Resource Locator, the HTTP request method, and HTTP header field templates; a request payload pattern that defines the structure and data type rules for generating the request body; a response template containing the expected HTTP response status code and response header field templates; a response payload pattern that defines the structure and data type rules for generating the response body; and a state update logic that defines, in the form of an executable script or function, how to modify the context information associated with the current session after the transaction state is completed.

[0010] Furthermore, the state transition rule includes a set of attribute fields to control the evolution of the scenario flow. These fields include: a source state identifier, pointing to the starting TSO of the transition; a destination state identifier, pointing to the ending TSO of the transition; and a conditional logic that defines the conditions that must be met to trigger this state transition, for example, based on whether the received HTTP response status code is 200, or whether the response body content contains a specific string pattern.

[0011] Furthermore, the stateful transaction simulation engine is the central processing unit for executing scenario-defined objects. For each concurrent user session to be simulated, the engine creates an independent session context object. The SCO is a key-value pair storage structure used to continuously store and update the session's state information, such as user identifiers, authentication tokens, session cookies, and shopping cart contents, throughout the entire business process lifecycle. The engine's operating mode is divided into a request synthesis phase and a response synthesis phase, which are coupled through a unique transaction association identifier.

[0012] During the request composition phase, the stateful transaction simulation engine performs the following sequence of operations for a virtual user session in a specific transaction state: First, the data required for the current state is read from the Session Context Object (SCO) of the session, exemplarily authenticating the token. Second, based on the request template defined in the TSO, the URL path and variable placeholders in the header fields are populated. Next, a built-in context-aware data generation unit based on a deterministic pseudo-random number generation algorithm is invoked to generate structured and realistic request body data according to the request payload pattern. Subsequently, a globally unique transaction association identifier is generated and injected into a custom HTTP request header field. Finally, the constructed HTTP request object is handed over to the hierarchical asynchronous task scheduler for transmission.

[0013] During the response synthesis phase, the internal request receiving network interface of the test service system receives an HTTP request forwarded by the reverse proxy system under test. The stateful transaction simulation engine performs the following sequence of operations: First, extract the transaction association identifier from the HTTP header of the inbound request; Secondly, using this identifier as an index, the corresponding virtual user session that is waiting for a response, its session context object, and its current transaction state object can be accurately located. Next, based on the response payload pattern defined in the TSO, the context-aware data generation unit is invoked to dynamically generate a response body consistent with the current business scenario and request context logic, in conjunction with the data in the current SCO. Subsequently, a complete HTTP response is constructed based on the response template, including the status code, headers, and the generated response body. Before sending the response, the state update logic defined in the TSO is executed to process data in the response that needs to be persisted to subsequent states. Finally, all state transition rules originating from the current TSO are evaluated, and based on the received requests and generated responses, the next transaction state that meets the conditions is determined, and the state machine of the virtual user session is advanced to the next TSO.

[0014] The hierarchical asynchronous task scheduler is responsible for efficiently managing massive concurrent network I / O operations. This scheduler employs a single-threaded or multi-threaded model based on a non-blocking I / O event loop. Its internal structure includes: a virtual user agent pool, responsible for managing the lifecycle of all active virtual user sessions; each virtual user agent is an independent coroutine or lightweight thread responsible for executing instances of scenario-defined objects; and a request dispatch queue, used to cache pending HTTP requests generated by the stateful transaction simulation engine. The network I / O module maintains a persistent TCP connection pool for the reverse proxy system under test to reuse connections, reduce the latency overhead of TCP handshake and TLS handshake, and is responsible for asynchronously sending requests and receiving responses driven by the event loop; as well as a global and local rate limiter, which is implemented based on the token bucket algorithm and can precisely control the number of requests per second for each business scenario and the system as a whole.

[0015] To simulate a real-world traffic model with multiple services coexisting, the probabilistic scenario distribution controller is responsible for macroscopically controlling the traffic allocation across different business scenarios. This controller receives a scenario mixing weight configuration, which defines the proportion of each modeled business scenario in the total traffic. For example, 70% of the traffic is allocated to the product browsing scenario, 20% to the user login scenario, and 10% to the order query scenario. During test runs, the controller performs weighted random sampling based on this probabilistic distribution model at preset time intervals or event triggers to determine which type of virtual user agent should be initialized and launched next. By dynamically injecting instances of different scenarios into the agent pool of the hierarchical asynchronous task scheduler, the controller ensures that, statistically, the business dimension composition of the test traffic is consistent with the preset real traffic model.

[0016] To ensure the traceability, reproducibility, and validity of the testing process, the data persistence and analysis subsystem provides comprehensive data recording and measurement capabilities. This subsystem includes a high-performance data logger that asynchronously writes complete measurement data for each request-response interaction to a time-series database optimized for high-concurrency writes. Each record includes a transaction association identifier, timestamps for each stage accurate to microseconds, complete headers and payloads for the request and response, response status codes, source and destination IP addresses, the scenario and status ID, and the virtual user agent ID that executed the transaction; a metrics aggregator, which runs in the background with fixed time windows, aggregates and calculates raw data in the time-series database to generate key performance indicators, such as average / P95 / P99 response time, throughput, error rate, and data transfer volume, and can group statistics by business scenario, specific API endpoint, and other dimensions; and a report generation and query interface, which provides an HTTP API endpoint for real-time exposure of aggregated metrics data for integration with external monitoring systems, and generates a comprehensive test report based on the data throughout the entire test cycle, including detailed statistical charts, performance trend analysis, and error summaries after the test.

[0017] The specific implementation steps of the method disclosed in this invention are as follows: Step 1: System Initialization. The test service system starts, loads and parses all scene definition objects predefined by the declarative scene modeling subsystem.

[0018] Step 2, Scene Instantiation. The probabilistic scene distribution controller selects an SDO based on the preset scene mixing weight configuration and instructs the hierarchical asynchronous task scheduler to create a new virtual user agent instance to execute the SDO, while initializing an empty session context object (SCO) for the instance.

[0019] Step 3: Initial Request Synthesis and Distribution. The virtual user agent begins execution from its initial transaction state object (TSO). Based on the definition of this stateful transaction emulation engine, the engine synthesizes the first HTTP request, injects a unique transaction association identifier, and submits it to the hierarchical asynchronous task scheduler. The scheduler then sends the request to the reverse proxy system under test through its external request sending network interface.

[0020] Step four: Request loopback and reception. After being processed by the reverse proxy system, the request is forwarded to the backend address configured in the reverse proxy system, which is the internal request reception network interface of this test service system.

[0021] Step 5: Context Association and Response Synthesis. Upon receiving the loopback request, the stateful transaction simulation engine extracts its transaction association identifier, locating the corresponding virtual user agent, SCO, and the current TSO. Subsequently, the engine synthesizes a context-consistent HTTP response based on the TSO's response definition.

[0022] Step Six: State Update and Response Sending. Before sending the response, the engine executes the state update logic in the TSO and modifies the SCO. Then, the synthesized response is sent back to the reverse proxy system through the internal request receive network interface.

[0023] Step 7, State Transition. Based on the completed interaction results, the engine evaluates all outbound state transition rules of the current TSO, determines the next transaction state, and advances the virtual user agent's state machine to that new state.

[0024] Step 8, Iterative Execution. The virtual user agent repeatedly executes steps 3 through 7, following the business process diagram defined by the SDO, until it reaches a termination state with no outbound edges. During this process, each request-response interaction constitutes a complete traffic loop through the reverse proxy system under test.

[0025] Step Nine, Concurrency and Scheduling. The hierarchical asynchronous task scheduler and the probabilistic scenario distribution controller continue to run, constantly creating, managing, and scheduling a large number of virtual user agents based on the configured number of concurrent users and scenario distribution, thereby forming a multi-dimensional, high-concurrency mixed traffic load on the reverse proxy system.

[0026] Step 10: Data Recording and Analysis. Throughout the entire test execution, the data persistence and analysis subsystem continuously records detailed data of all interactions and calculates performance metrics in real time until the test task ends, ultimately generating a test report.

[0027] The beneficial effects of this invention are: This invention, by constructing a closed-loop self-consistent system integrating traffic generation and response simulation, completely breaks the strong coupling between test logic and physical deployment architecture in traditional testing methods. It greatly simplifies the complexity of the test environment, significantly reduces hardware resources and operation and maintenance costs, and gives testers extremely high flexibility to define, combine, and dynamically schedule multi-dimensional business scenarios of arbitrary complexity. At the same time, it ensures the reproducibility of the test through a deterministic data generation mechanism, thus providing a new and systematic solution for the efficient, in-depth, and comprehensive verification of reverse proxy systems. Attached Figure Description

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

[0029] In the attached diagram: Figure 1 This is a block diagram of the test service system structure used in the method for simplifying the acquisition of multi-dimensional traffic by a reverse proxy system according to the present invention; Figure 2 This is a flowchart illustrating a simplified method for a reverse proxy system to obtain multi-dimensional traffic according to the present invention. Detailed Implementation

[0030] The exemplary embodiments of this disclosure are described below with reference to the accompanying drawings, including various details of the embodiments to aid understanding, and should be considered merely exemplary. Therefore, those skilled in the art will recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of this disclosure. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0031] Specific implementation examples are given below.

[0032] Example Please see Figures 1-2 This invention provides a simplified method for a reverse proxy system to obtain multi-dimensional traffic, referring to... Figure 1This paper demonstrates the overall functional structure of the test service system 100 upon which the proposed method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system relies. The core of this method lies in simulating the complete interaction process between the client and server in a closed-loop manner by deploying a functionally self-consistent and physically compact test service system 100. This test service system 100 can physically run on a single high-performance server node or distributed across a cluster of multiple computing nodes, executing through virtualization technology (such as containerization) or directly on the operating system. System 100 exposes two logically separate network interfaces: an external request sending network interface 101, configured to establish network communication with the entry address of the reverse proxy system 200 under test and actively send constructed HTTP or HTTPS requests; and an internal request receiving network interface 102, which serves as the backend service address configured for the reverse proxy system 200 and is used to receive requests forwarded by the reverse proxy system 200. This design enables the test service system 100 to simultaneously play the roles of the client cluster and the backend service cluster in a traditional test architecture. All traffic passing through the reverse proxy system 200 originates from this system and ultimately returns to this system, forming a complete traffic loopback path.

[0033] Specifically, the test service system 100 integrates a series of highly collaborative subsystems, including a declarative scenario modeling subsystem 110, a stateful transaction simulation engine 120, a hierarchical asynchronous task scheduler 130, a probabilistic scenario distribution controller 140, and a data persistence and analysis subsystem 150. These subsystems work together to realize the entire process from the abstract definition of complex business scenarios to the accurate generation, transmission, reception, response, state maintenance, and data measurement of high-concurrency, multi-dimensional traffic.

[0034] In some embodiments, the declarative scenario modeling subsystem 110 serves as the logical starting point of the entire testing process. Its core responsibility is to transform complex, multi-step business processes into structured data that machines can accurately parse and execute. This subsystem provides a textual definition method based on a domain-specific language (DSL), allowing test engineers to describe business scenarios in a declarative manner close to natural language. For example, an e-commerce shopping process can be defined as a ScenarioDefinitionObject (SDO). At the data structure level, an SDO is implemented as a Directed Acyclic Graph (DAG), which fully describes all possible states and transition paths between states in a business process. Each node in the graph is abstracted as a TransactionStateObject (TSO), representing an atomic interaction step in the business process, such as a user initiating a login request, the server returning an authentication token, or a user querying a product list. The directed edges connecting different TSO nodes are defined as StateTransitionRules (STRs), which specify the conditions required to transition from one state to the next.

[0035] In some embodiments, to precisely control the details of each network interaction, the Transaction State Object (TSO) contains a detailed set of attribute fields. Specifically, a TSO's data structure can be defined to include the following key fields: a globally unique string-type state identifier, state_id; a request template, which is itself a composite object; and a header field template. The path and header templates can contain placeholders, which will be dynamically replaced by the actual data in the session context during the request synthesis phase. The request payload schema, `request_payload_schema`, is defined in standard JSON Schema format and is used to guide the generation of a request body that conforms to specific structure and data type constraints. For example, a login request payload schema can specify that it must include two fields: username (a string that conforms to a specific regular expression) and password (a string with a minimum length of 8). The response template, `response_template`, defines the basic framework of the response that should be returned by the backend, including the expected HTTP status code `status_code` (exemplarily 200 or 201) and the response header field template `headers_template`. The response payload schema, `response_payload_schema`, also in JSON Schema format, defines the structure of the response body. For example, a successful login response body schema would specify that it includes a token field (a string) and a user_profile object. Finally, there is a state update logic called state_update_logic, which is usually implemented in an embedded scripting language (such as JavaScript or Lua). This script is executed after the response is synthesized and before it is sent. It has read and write permissions to the current session context and is used to extract key information from the response and update the session state.

[0036] Correspondingly, the State Transition Rule (STR) data structure defines how the process evolves from one TSO to the next. It contains a source state identifier (source_state_id) pointing to the starting TSO of the transition; a target state identifier (target_state_id) pointing to the ending TSO of the transition; and a conditional logic (condition_logic), which is also an executable script whose input is the complete request and response object of the most recent interaction. This logic returns a Boolean value, and a state transition only occurs when its evaluation result is true. By combining multiple STRs that originate from the same source state but have different and mutually exclusive conditions, conditional branching logic in a business process can be implemented.

[0037] The stateful transaction simulation engine 120 is the core processing unit that executes the SDO defined by the declarative scenario modeling subsystem 110. The engine is designed to maintain an independent, isolated state for each concurrently simulated user session. To this end, whenever a new virtual user session starts, the engine creates a SessionContextObject (SCO) for it. The SCO is implemented as a thread-safe key-value store used to persist state information throughout the entire lifecycle of the virtual user session, exemplified by user ID, authentication token, session cookie, and a list of item IDs in the shopping cart. The engine's workflow is rigorously divided into a request composition phase and a response composition phase, which are decoupled and associated through a globally unique transaction correlation identifier (transaction_correlation_id) generated when the request is issued.

[0038] During the request synthesis phase, simulation engine 120 performs a series of precise operations for a session in a state defined by a specific TSO. First, it accesses the session's SCO and reads the context data required to execute the current TSO, such as authToken or user_id; Secondly, based on the request_template defined in TSO, the read context data is used to render the path and placeholders in the header template to generate the specific URL and HTTP headers; Next, the engine calls a built-in context-aware data generation unit, which is based on a deterministic pseudo-random number generator, preferably using the Mason twisting algorithm MT19937, and is initialized with a composite seed calculated by combining a global seed and the current session ID to ensure the global reproducibility of the test and the differences between sessions. It generates a structured, realistic request body that conforms to the business logic according to request_payload_schema. The engine then generates a transaction association identifier in UUIDv4 format and injects it into a custom HTTP request header field, for example, X-Transaction-ID:a1b2c3d4-e5f6-4789-8a9b-0c1d2e3f4g5h; Finally, the fully constructed HTTP request object is placed in a queue, awaiting further processing by the hierarchical asynchronous task scheduler 130.

[0039] During the response synthesis phase, when the internal request receiving network interface 102 of the test service system 100 receives an HTTP request forwarded by the reverse proxy system 200, the simulation engine 120 is triggered. It first parses the value of the X-Transaction-ID field from the HTTP header of the inbound request; Then, using this identifier as a key, a lookup is performed in a global, concurrency-safe hash table to pinpoint the corresponding virtual user session instance that is currently waiting for a response, along with its SCO and the current TSO. Next, based on the response_payload_schema defined in the TSO, the engine again invokes the context-aware data generation unit. At this point, it can combine the data in the SCO to generate logically coherent response content (for example, in a request to query user information, the user_id returned in the response body must match the user_id stored in the SCO). Subsequently, a complete HTTP response object is constructed based on the response_template, including the status code, headers, and the newly generated response body. Before sending the response back to the reverse proxy system 200, the engine executes the state_update_logic script defined in the current TSO to make necessary modifications to the SCO; Finally, the engine will traverse all STRs originating from the current TSO, execute their condition_logic one by one, find the first transition rule whose evaluation result is true, and advance the state machine of the virtual user session to the target TSO pointed to by the rule, preparing for the next round of request synthesis.

[0040] In some embodiments, the hierarchical asynchronous task scheduler 130 provides the entire system with high-concurrency, high-performance network I / O capabilities, serving as the foundation for supporting a massive number of virtual users online simultaneously. This scheduler employs an event-driven, non-blocking I / O model at the underlying level, specifically implemented using the operating system's epoll (in Linux) or kqueue (in BSD) mechanisms, allowing tens of thousands of concurrent network connections to be handled with a very small number of threads. Its internal structure includes several key components: a virtual user agent pool, responsible for creating, managing, and destroying all virtual user agents; and each agent, logically an independent execution unit, typically implemented as a coroutine (such as Go's goroutine or Python's asyncioTask), responsible for the complete execution of the state machine process of an SDO instance. The request distribution queue is a lock-free queue in a multi-producer, single-consumer pattern, used to buffer requests to be sent generated by the simulation engine 120, decoupling business logic from network I / O. The network I / O module's core is a persistent TCP / TLS connection pool for the reverse proxy system under test 200. By reusing established connections, it significantly reduces latency and system overhead caused by frequent TCP three-way handshakes and TLS handshakes. Driven by an event loop, this module asynchronously retrieves requests from the request distribution queue and sends them through the connection pool, while simultaneously listening for readable events on all connections to receive responses. In addition, the scheduler has a built-in global and multiple local rate limiters, which are implemented based on the token bucket algorithm. They can accurately control the overall system and the requests per second (RPS) of each individual business scenario, ensuring the stability and controllability of the test load.

[0041] To simulate the complex interplay of various business traffic flows in the real world, the probabilistic scenario distribution controller 140 acts as a macro-level traffic controller. This controller operates by reading a scenario mixing weight configuration file, which defines the proportion of each modeled SDO (Service Decision Object) that should be allocated to the total test traffic. For example, a configuration might specify that 70% of the traffic should be allocated to product browsing scenarios, 20% to user login scenarios, and the remaining 10% to order query scenarios. During test runs, the controller performs weighted random sampling (using efficient algorithms such as Vose's AliasMethod) based on the configured weight distribution at fixed time intervals (for example, every 100 milliseconds) or according to changes in the current number of active users to determine which SDO the next virtual user agent should execute. It then instructs the hierarchical asynchronous task scheduler 130 to create a new instance in the agent pool to execute the selected SDO. By continuously injecting instances of different scenarios into the agent pool, the controller ensures that, at a macro-level statistical level, the business composition of the mixed traffic sent to the reverse proxy system 200 closely matches the preset real-world traffic model.

[0042] Understandably, the data persistence and analysis subsystem 150 provides comprehensive observability, traceability, and reproducibility for the entire testing process; This subsystem contains a high-performance data logger that asynchronously writes detailed metrics of each request-response interaction to a time-series database (exemplarily InfluxDB or ClickHouse) optimized for high concurrency and high write throughput. Each record is a data point with a precise timestamp, whose tags and fields fully describe all dimensions of the interaction, including: transaction association identifier, request generation timestamp, request sending timestamp, response first byte received timestamp, response received completion timestamp (all with microsecond precision), request method, URL, complete request and response headers, request and response body sizes, response status code, source IP, destination IP, associated SDOID, associated TSOID, and the virtual user agent ID that executed the transaction. The metrics aggregator, running as a background process, operates within a fixed time window (exemplarily every 1 second). It queries raw data in the time-series database and performs real-time aggregation calculations to generate key performance indicators (KPIs), such as average response time, 95th and 99th percentile response time, throughput (RPS), success rate, error rate, and data transfer per second. This aggregated data can be grouped according to multiple dimensions, such as business scenario (SDOID) and specific API endpoint (TSOID). Finally, the report generation and query interface is typically an HTTP API service. On the one hand, it can expose the aggregated metrics data in PrometheusExposition format in real time, facilitating integration with external monitoring systems such as Grafana to achieve visualized monitoring of the testing process. On the other hand, after the test is completed, it can query the data for the entire testing cycle and generate a comprehensive test report in HTML or PDF format that includes statistical charts, performance trend analysis, error classification summaries, and slow request tracing.

[0043] Reference Figure 2 The specific implementation steps of the method disclosed in this invention are as follows: First, proceed to step S201 to perform system initialization. The test service system 100 starts, loads all predefined scenario definition objects (SDOs), and initializes and configures each subsystem, exemplarily establishing a connection with the time series database and warming up the TCP connection pool.

[0044] Subsequently, step S202 is performed to instantiate the scene. The probabilistic scene distribution controller 140 performs a weighted random selection based on the preset scene mixing weight configuration to determine an SDO. Then, it notifies the hierarchical asynchronous task scheduler 130, which then creates a new agent instance in the virtual user agent pool and assigns a newly initialized, empty session context object (SCO) to the instance, ready to execute the selected SDO.

[0045] Next, step S203 is executed, performing the first round of request synthesis and distribution. The newly created virtual user agent begins execution from the initial TSO of its held SDO. The stateful transaction simulation engine 120 synthesizes the first HTTP request according to the definition of the TSO, generating and injecting a unique transaction association identifier in the process, and then submits the request object to the hierarchical asynchronous task scheduler 130. The scheduler 130 obtains an available connection from the connection pool through its external request sending network interface 101 and asynchronously sends the request to the reverse proxy system 200 under test.

[0046] Then, proceed to step S204 to implement request loopback and reception. The HTTP request is processed by the reverse proxy system 200 (exemplarily load balancing, SSL offloading, header modification, etc.) and forwarded by it to its configured backend service address according to the routing rules. This address is the internal request receiving network interface 102 of this test service system 100.

[0047] Next, step S205 is performed for context association and response synthesis. Upon receiving the request, the internal request receiving network interface 102 delivers it to the stateful transaction simulation engine 120. Engine 120 extracts the transaction association identifier from the request header and uses it as an index to quickly locate the virtual user agent instance that initiated the request, its SCO, and its current TSO. Subsequently, engine 120 dynamically synthesizes an HTTP response consistent with the current business context logic based on the response template and response payload pattern defined in the TSO.

[0048] Next, proceed to step S206 to complete the state update and response sending. Before sending the synthesized response, engine 120 executes the state update logic script defined in TSO, which may modify the contents of SCO, for example, storing the newly generated session token therein. After the update is completed, the response is sent back through the internal request receiving network interface 102, and finally returned to the client module of test service system 100 via reverse proxy system 200.

[0049] Subsequently, step S207 is performed to initiate a state transition. After completing a request-response interaction, the simulation engine 120 evaluates the state transition rules (STRs) for all outbound transactions of the current TSO. Based on the interaction results, such as the response status code, it determines the next transaction state that meets the conditions and advances the state machine within the virtual user agent to the new TSO.

[0050] Next, proceed to step S208 for iterative execution. The virtual user agent will repeatedly execute the loop from steps S203 to S207, continuously advancing along the business process diagram defined by SDO until it reaches a termination state with no outbound edges, at which point the virtual user session ends. Each loop constitutes a complete traffic loop through the reverse proxy system 200 under test.

[0051] Meanwhile, at the macro level, step S209 continues with concurrency and scheduling. The hierarchical asynchronous task scheduler 130 and the probabilistic scenario distribution controller 140 run in parallel throughout the test, continuously creating, scheduling, and managing hundreds or thousands of concurrent virtual user agents based on the configured number of concurrent users and scenario distribution, thereby applying a stable, controllable, and business-diverse mixed traffic load to the reverse proxy system 200.

[0052] Finally, throughout the entire testing process, step S210, data recording and analysis, continues continuously. The data persistence and analysis subsystem 150 continuously captures and records detailed telemetry data from all interactions, and performs aggregation calculations in real time until the test task is manually stopped or the preset duration is reached, ultimately generating a comprehensive test analysis report.

[0053] In the description of this invention, it should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this disclosure can be executed in parallel, sequentially, or in different orders, as long as the desired results of the technical solutions provided in this disclosure can be achieved, and no limitation is imposed herein.

[0054] The above description is merely a preferred embodiment of the present invention and does not constitute a limitation on the scope of protection of this disclosure. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this disclosure should be included within the scope of protection of this disclosure.

Claims

1. A simplified method for obtaining multi-dimensional traffic in a reverse proxy system, characterized in that, Includes the following steps: Deploy a test service system (100), the test service system (100) having an external request sending network interface (101) and an internal request receiving network interface (102). The external request sending network interface (101) is used to send a request to the entry address of a reverse proxy system (200) to be tested. The internal request receiving network interface (102) is used as the backend service address configured by the reverse proxy system (200) to receive requests forwarded by it. An HTTP request is synthesized by the stateful transaction simulation engine (120) inside the test service system (100). The synthesis step includes generating a globally unique transaction association identifier and injecting the transaction association identifier into a custom header field of the HTTP request. The synthesized HTTP request is sent to the reverse proxy system (200) to be tested through the external request sending network interface (101). The internal request receiving network interface (102) receives the HTTP request forwarded by the reverse proxy system (200); The stateful transaction simulation engine (120) extracts the transaction association identifier from the header of the received HTTP request; Using the transaction association identifier as an index, the session context and current transaction status associated with the sent HTTP request are queried and located within the test service system (100); Based on the located session context and current transaction state, an HTTP response is dynamically synthesized by the stateful transaction simulation engine (120); The synthesized HTTP response is sent back to the reverse proxy system (200) via the internal request receiving network interface (102).

2. The method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The composition of the request and the composition of the response are performed based on one or more predefined Scenario Definition Objects (SDOs); The Scenario Definition Object (SDO) is used to transform an abstract business process into machine-executable structured data, which is represented by a directed acyclic graph in terms of data structure. Each node of the directed acyclic graph is defined as a transaction state object (TSO) to represent a specific interaction step in the business process. Each directed edge of the directed acyclic graph is defined as a state transition rule (STR), which defines the triggering conditions for transitioning from one transaction state to the next transaction state.

3. The method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The Transaction State Object (TSO) contains a set of attribute fields to fully describe a network interaction round, including: A unique status identifier; A request template, which contains a path template for the target Uniform Resource Locator, an HTTP request method, and an HTTP header field template, wherein the path template and header field template may contain variable placeholders; The request payload pattern uses JSONSchema to define the structure and data type rules for generating the request body; A response template containing the expected HTTP response status code and response header field templates; The response payload pattern uses JSON Schema to define the structure and data type rules for generating the response body; and A state update logic, defined in the form of an executable script, specifies how to modify the context information associated with the current session after the transaction state is completed.

4. The method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 2, characterized in that: The state transition rule includes a set of attribute fields used to control the evolution of the scene flow. The attribute fields include: The source state identifier is used to point to the starting transaction state object of this transfer; The target state identifier, used to point to the endpoint transaction state object of this transition; and A conditional logic, defined in the form of an executable script, defines the conditions that must be met to trigger this state transition. The input of the conditional logic is a completed request-response interaction object, and its output is a Boolean value. The state transition occurs if and only if the output is true.

5. The method according to any one of claims 1 to 4, characterized in that, The method further includes: For each concurrent user session that needs to be simulated, the stateful transaction simulation engine (120) creates an independent session context object; The session context object is a key-value pair storage structure used to continuously store and update the state information of the user session throughout its entire lifecycle. During the request synthesis phase, data is read from the session context object to populate variable placeholders in the request template; After the response is synthesized but before it is sent, the state update logic defined in the transaction state object is executed to read the response data and update the session context object.

6. The method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The sending and receiving of the HTTP requests are managed by a hierarchical asynchronous task scheduler (130); The hierarchical asynchronous task scheduler (130) is built based on a non-blocking I / O event loop model, and its internal components include: The virtual user agent pool is responsible for managing the lifecycle of all active virtual user sessions, where each virtual user agent is an independent coroutine or lightweight thread responsible for executing an instance of the scenario definition object. A request dispatch queue is used to cache HTTP requests to be sent generated by the stateful transaction simulation engine (120) to decouple business logic from network I / O.

7. The method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The hierarchical asynchronous task scheduler (130) also includes: The network I / O module maintains a persistent TCP connection pool for the reverse proxy system under test (200) to reuse established network connections, reduce the latency overhead of TCP handshake and TLS handshake, and asynchronously send requests and receive responses under the drive of the event loop; as well as One or more rate limiters based on the token bucket algorithm are used to precisely control the number of requests per second for each business scenario and the system as a whole.

8. The method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The method further includes a step of macro-flow regulation by a probabilistic scene distribution controller (140); The probabilistic scenario distribution controller (140) receives a scenario mixing weight configuration, which defines multiple modeled business scenarios, i.e., the proportion of different scenario definition objects in the total traffic. During the test run, the probabilistic scenario distribution controller (140) performs weighted random sampling based on the scenario hybrid weight configuration to determine the scenario definition object type to be executed by the virtual user agent to be initialized next, and sends the instruction to the hierarchical asynchronous task scheduler (130) to ensure that the business dimension composition of the test traffic is consistent with the preset model.

9. A method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The method further includes the step of data recording by the data persistence and analysis subsystem (150); The data persistence and analysis subsystem (150) contains a high-performance data logger that asynchronously writes complete metric data of each request-response interaction to a time-series database; Each record written contains the transaction association identifier, as well as timestamps for each stage accurate to microseconds, complete headers and payload sizes for the request and response, response status codes, source and destination IP addresses, the identifier of the Scenario Definition Object (SDO) to which it belongs, the identifier of the Transaction State Object (TSO) to which it belongs, and the identifier of the virtual user agent executing the transaction.

10. A method for simplifying the acquisition of multi-dimensional traffic in a reverse proxy system according to claim 1, characterized in that: The data persistence and analysis subsystem (150) also includes: The metrics aggregator runs in the background within a fixed time window, aggregating and calculating the raw data in the time-series database to generate key performance indicators including average response time, percentile response time, throughput, error rate, and data transfer volume. It also supports grouping and statistical analysis by business scenario or API endpoint, among other dimensions. The report generation and query interface provides an HTTP API endpoint for exposing the aggregated metric data in real time for integration with external monitoring systems. After the test is completed, it generates a comprehensive test report based on the data from the entire test cycle, including statistical charts, performance trend analysis, and error summaries.

Images