Non-invasive synchronous traffic replication and comparison method, device and related equipment

Abstract

This application relates to the field of computer network technology and can be applied to the fields of fintech / digital healthcare. It discloses a non-intrusive synchronous traffic replication and comparison method, apparatus, and related equipment. The method includes: receiving the original service request through a first gateway cluster and forwarding it to the source target application; generating a target request in the first gateway cluster based on a mirroring mechanism and forwarding it to the replicated target application through a second gateway cluster; collecting request messages of the original request and the target request in the first and second gateway clusters and storing them in association based on request identifiers; collecting response messages returned by the source target application and the replicated target application and establishing a correspondence; sending the request messages and response messages to a target comparison platform through a scheduled task; and performing a consistency comparison of the request data and response data of both applications based on the request identifiers on the target comparison platform to generate a comparison result. This method achieves non-intrusive synchronous traffic consistency comparison and verification.

Description

Technical Field

[0001] This application relates to the field of computer network technology and can be applied to the fields of financial technology / digital healthcare, and in particular to a non-invasive synchronous traffic copying and comparison method, apparatus and related equipment. Background Technology

[0002] In the process of transforming fintech systems, replacing databases with domestically developed technologies, and migrating digital healthcare systems to the cloud, it is often necessary to verify interface consistency and system performance through real production traffic. Existing traffic replication solutions typically rely on embedding interception code within the business system. This involves capturing request and response messages and writing them to a message queue, then having a comparison platform construct replication requests to access the modified system. However, this approach is not only intrusive to the business system and can potentially affect the stability of the production chain due to malfunctions in the interception module, but also deviates from the real production environment in terms of data writing order, transaction execution timing, and concurrency conflicts due to time differences between replication requests and original requests. This can affect the accuracy of the comparison results. For example, in fintech scenarios, operations such as insurance claims processing and payment clearing rely on strict transaction timing. Delays in replication requests can lead to completely different version numbers, row locks, and concurrency sequences, making it difficult to determine whether the modified system actually has defects. In digital healthcare scenarios, operations such as writing medical orders and deducting inventory during peak registration periods have even higher requirements for timing and atomicity. Asynchronous replication methods often lead to inconsistencies in examination numbers and different order sequences, distorting the comparison results. Furthermore, message queues tend to accumulate in high-concurrency scenarios, further exacerbating replication latency. It is evident that existing technologies generally suffer from problems such as high invasiveness, significant timing distortion, insufficient replication accuracy, and poor adaptability to sensitive business scenarios, failing to meet the verification requirements of the financial and healthcare industries for high stability and high consistency. Summary of the Invention

[0003] The main technical problem addressed by the implementation method of this application is that the existing technology is highly invasive, has timing distortion, and is inaccurate in terms of traffic replication and interface consistency verification.

[0004] To address the aforementioned technical problems, the first technical solution adopted in this application is: providing a non-intrusive synchronous traffic replication and comparison method, comprising: receiving an original request through a first gateway cluster and forwarding the original request to a source target application; generating a target request for the original request in the first gateway cluster through a mirroring function, sending the target request to a second gateway cluster, and the target request being forwarded by the second gateway cluster to the replicated target application; acquiring request messages of the original request and the target request respectively through request message acquisition logic of the first gateway cluster and the second gateway cluster, and storing the request messages in association according to request identifiers; collecting response messages returned by the source target application and the replicated target application through the first gateway cluster and the second gateway cluster, and establishing an association relationship between the response messages and the corresponding request messages; executing a preset timed task to send the request messages and corresponding response messages in the first gateway cluster and the second gateway cluster to a target comparison platform; and performing a consistency comparison of the request and response data of the source target application and the replicated target application in the target comparison platform according to the same request identifier to obtain the corresponding comparison result.

[0005] Optionally, the step of generating the target request of the original request in the first gateway cluster through the mirroring function includes: when the first gateway cluster receives the original request, copying the request parameters and request message content of the original request based on a preset mirroring rule to generate a target request corresponding to the original request; when generating the target request, setting the same request identifier as the original request for the target request, the request identifier being used to identify the correspondence between the target request and the original request.

[0006] Optionally, the step of acquiring the request messages of the original request and the target request respectively through the request message acquisition logic of the first gateway cluster and the second gateway cluster, and associating and storing the request messages according to the request identifier, includes: before the original request is forwarded to the source target application, parsing the original request to obtain the request method, request path, request header information and request body data of the original request, so as to generate a first request message corresponding to the original request; before the target request is forwarded to the copied target application, parsing the target request to obtain the request method, request path, request header information and request body data of the target request, so as to generate a second request message corresponding to the target request; acquiring the request identifiers corresponding to the original request and the target request, and establishing a first association relationship between the first request message and the second request message according to the request identifier; and storing request data records where the first request message and the second request message are under the same request identifier according to the first association relationship.

[0007] Optionally, the step of collecting response messages returned by the source target application and the replicated target application through the first gateway cluster and the second gateway cluster, and establishing the association between the response messages and the corresponding request messages, includes: when the source target application returns first response data, parsing the first response data to obtain the response status information, response header information, and response body data returned by the source target application, so as to generate a first response message corresponding to the source target application; when the replicated target application returns second response data, parsing the second response data to obtain the response status information, response header information, and response body data returned by the replicated target application, so as to generate a second response message corresponding to the replicated target application; obtaining the request identifiers corresponding to the first response message and the second response message, and establishing a second association between the first response message and the second response message based on the request identifiers; and storing response data records where the first response message and the second response message are under the same request identifier based on the second association.

[0008] Optionally, the step of performing a consistency comparison of the request and response data of the source target application and the copied target application in the target comparison platform based on the same request identifier to obtain a corresponding comparison result includes: obtaining, based on the request identifier, the request message and response message corresponding to the source target application and the request message and response message corresponding to the copied target application from the target comparison platform; performing structured parsing on the obtained request messages to extract the request method, request path, request parameters, and request body data as request comparison data; performing structured parsing on the obtained response messages to extract the response status information, response header information, and response body data as response comparison data; performing a consistency comparison of the request comparison data of the source target application and the copied target application in the target comparison platform; performing a consistency comparison of the response comparison data of the source target application and the copied target application in the target comparison platform; and generating a comparison result corresponding to the request identifier based on the comparison results of the request comparison data and the response comparison data.

[0009] Optionally, the step of performing structured parsing on the acquired request message to extract the request method, request path, request parameters, and request body data as request comparison data includes: performing format recognition on the request message to determine the request protocol type corresponding to the request message; parsing the request message according to the request protocol type to obtain the interface call method and request path in the request message; extracting request header information from the request message and obtaining request parameters from the request header information according to preset parsing rules; parsing the request body data in the request message and converting the request body data into structured data form; and uniformly encapsulating the parsed interface call method, request path, request parameters, and request body data to generate the corresponding request comparison data.

[0010] Optionally, the step of performing structured parsing on the acquired response message to extract response status information, response header information, and response body data as response comparison data includes: identifying the format of the response message to determine the response protocol type corresponding to the response message; parsing the response message according to the response protocol type to obtain the response status information in the response message; extracting the response header information from the response message and performing structured processing on the response header information; parsing the response body data in the response message and converting the response body data into structured data format; and uniformly encapsulating the parsed response status information, response header information, and response body data to generate the corresponding response comparison data.

[0011] To solve the above-mentioned technical problems, the second technical solution adopted in this application is: providing a non-intrusive synchronous traffic replication and comparison device, comprising: an original request receiving module, used to receive an original request through a first gateway cluster and forward the original request to the source target application; an original request mirroring module, used to generate a target request of the original request in the first gateway cluster through mirroring function, send the target request to a second gateway cluster, and the target request is then forwarded by the second gateway cluster to the target application to be replicated; and a request message processing module, used to obtain the request messages of the original request and the target request respectively through the request message acquisition logic of the first gateway cluster and the second gateway cluster, and process the request messages according to the request. The system includes: an identifier for associated storage of the request message; a response message processing module for collecting response messages returned by the source target application and the copied target application through the first gateway cluster and the second gateway cluster, and establishing an association between the response message and the corresponding request message; a message timing comparison module for executing a preset timing task to send the request message and the corresponding response message from the first gateway cluster and the second gateway cluster to the target comparison platform; and a comparison result generation module for performing a consistency comparison of the request and response data of the source target application and the copied target application in the target comparison platform based on the same request identifier, to obtain the corresponding comparison result.

[0012] To solve the above-mentioned technical problems, the third technical solution adopted in the embodiments of this application is: to provide an electronic device, including: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to perform the non-intrusive synchronous traffic replication comparison method as described above.

[0013] To solve the above-mentioned technical problems, the fourth technical solution adopted in the embodiments of this application is: to provide a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by an electronic device, the electronic device performs the non-intrusive synchronous traffic copying and comparison method as described above.

[0014] Unlike related technologies, this application constructs a non-intrusive synchronous traffic replication and comparison mechanism by uniformly accessing, synchronously mirroring, and bidirectionally collecting requests and responses at the gateway layer, as well as comparing them based on request identifiers. Compared to solutions relying on application-level embedding, log replay, or asynchronous replay, this application, without altering the business logic of the source and target applications, allows real production requests to be processed in different application sides within the same request lifecycle, and completes the collection and association of request and response messages at the gateway side, thereby ensuring the consistency of request timing, request parameters, and processing context. Furthermore, by sending the collected request and response data to the target comparison platform and performing consistency comparison based on the same request identifier, this application can not only verify whether the processing results of different applications are consistent under the same request conditions, but also accurately locate inconsistencies caused by differences in interface parsing, business rules, or exception handling. Thus, this application effectively solves the problems of inaccurate traffic replication, inconsistent comparison timing, and strong intrusiveness to business systems in related technologies, improving the reliability and practical value of traffic replication and comparison in system transformation, upgrade, or replacement scenarios. Attached Figure Description

[0015] One or more embodiments are illustrated by way of example with reference to the accompanying drawings. These illustrations do not constitute a limitation on the embodiments. Elements having the same reference numerals in the drawings are denoted as similar elements. Unless otherwise stated, the figures in the drawings are not to be limited by scale.

[0016] Figure 1 This is a schematic diagram of the operating environment of the non-intrusive synchronous traffic replication and comparison method provided in the embodiments of this application.

[0017] Figure 2 This is a schematic diagram of the execution flow of the non-intrusive synchronous traffic replication and comparison method provided in the embodiments of this application.

[0018] Figure 3 This is a schematic diagram of the execution flow for obtaining request messages in the non-intrusive synchronous traffic replication and comparison method provided in the embodiments of this application.

[0019] Figure 4 This is a schematic diagram of the execution flow for obtaining the comparison results in the non-intrusive synchronous traffic replication comparison method provided in the embodiments of this application.

[0020] Figure 5 This is a schematic diagram of the system structure of the non-intrusive synchronous traffic replication and comparison device provided in the embodiments of this application.

[0021] Figure 6 This is a schematic diagram of the hardware structure of an electronic device that performs a non-intrusive synchronous traffic replication and comparison method according to an embodiment of this application. Detailed Implementation

[0022] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application. Software tools, components, or servers not belonging to this company that appear in the embodiments of this application are merely illustrative examples and do not represent actual use.

[0023] It should be noted that, unless otherwise specified, the various features in the embodiments of this application can be combined with each other, all of which are within the protection scope of this application. Furthermore, although functional modules are divided in the device schematic diagram and a logical order is shown in the flowchart, in some cases, the steps shown or described may be performed in a different order than the module division in the device schematic diagram or the order in the flowchart.

[0024] Unless otherwise defined, all technical and scientific terms used in this specification have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the scope of this application. The term "and / or" as used in this specification includes any and all combinations of one or more of the associated listed items.

[0025] To facilitate understanding of this embodiment, a non-intrusive synchronous traffic replication and comparison method disclosed in this application will first be described in detail. Please refer to [link to relevant documentation]. Figure 1 , Figure 1 This is a schematic diagram of the operating environment of the non-intrusive synchronous traffic replication and comparison method provided in the embodiments of this application, such as... Figure 1 As shown, the non-intrusive synchronous traffic replication and comparison method provided in this application is generally executed by an electronic device with a certain computing power, such as a computer. In some possible implementations, this non-intrusive synchronous traffic replication and comparison method can be implemented by a processor calling computer-readable instructions stored in memory. Figure 1 The computer equipment mentioned can be a server. A server can be a standalone server or a cloud server that provides basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks (CDNs), and big data and artificial intelligence platforms. This can be understood as... Figure 1 The number of computer devices shown is merely illustrative and can be expanded in any number according to actual needs.

[0026] Please continue reading. Figure 2 ,Figure 2 This is a schematic diagram of the execution flow of the non-intrusive synchronous traffic replication and comparison method provided in the embodiments of this application, as shown below. Figure 2 As shown, it includes the following steps: S1. Receive the original request through the first gateway cluster and forward the original request to the source target application.

[0027] Step S1 ensures that business requests are centrally accessed and scheduled via the first gateway cluster before entering the source target application. This achieves unified carrying and control of real production traffic without altering the deployment structure of the source target application, intruding on business code, or introducing additional call chains. Using the first gateway cluster as the traffic entry point preserves the true access characteristics of requests in the production environment, including request frequency, request order, concurrency relationships, and upstream / downstream dependencies, avoiding the timing distortion issues caused by traditional methods such as log replay and message queue callbacks. Furthermore, it provides a stable technical entry point for subsequent request mirroring, request packet collection, and request identifier generation at the gateway layer. This ensures that copied requests and original requests are processed within the same network path and the same request lifecycle, laying the foundation for highly consistent traffic comparison.

[0028] S2. The target request of the original request is generated in the first gateway cluster through the mirroring function, and the target request is sent to the second gateway cluster. The target request is then forwarded by the second gateway cluster to the target application to be replicated.

[0029] The core of step S2 lies in generating the replication request within the first gateway cluster. This ensures that the target request and the original request are within the same request lifecycle and network scheduling sequence, thus avoiding the time offset and state inconsistency problems introduced by traditional methods based on log replay, message queue replay, or secondary callbacks. By mirroring the original request at the gateway layer, the target request maintains a high degree of consistency with the original request in terms of request parameters, request context, and access sequence. This allows both to arrive at the source target application and the replicated target application almost simultaneously, achieving a synchronous parallel processing effect and significantly improving the reliability of subsequent request-response comparison results.

[0030] Furthermore, by forwarding target requests to the replicated target application via a second gateway cluster, isolated deployment of replication traffic can be achieved along the network path. This decouples the scheduling and collection of replication traffic from the original business traffic, avoiding additional load or risk to existing business systems. In scenarios such as fintech and digital healthcare, this step enables the same business request to simultaneously enter the old and new systems under real concurrency conditions. This is used to verify the consistency of transaction processing, risk control judgment, treatment decisions, or cost calculation results, thereby building a parallel verification mechanism based on real production traffic. This is a key technical step in achieving non-intrusive, high-time-consistency traffic replication and comparison.

[0031] As an optional implementation, the process of generating the target request in step S2 above may further include the following steps S21 to S22.

[0032] S21. When the first gateway cluster receives the original request, it copies the request parameters and request message content of the original request based on the preset mirroring rules to generate the target request corresponding to the original request.

[0033] S22. When generating the target request, set the same request identifier as the original request for the target request. The request identifier is used to identify the correspondence between the target request and the original request.

[0034] The target request generated in steps S21 to S22 above can completely retain the access path, parameter structure, request context, and call sequence characteristics of the original request, providing a foundation for subsequent real business processing on the target application side. Simultaneously with generating the target request, a request identifier identical to the original request is set for the target request, establishing a one-to-one correspondence between the target and original requests at the data level. This request identifier serves as a unified index throughout the request collection, response association, and consistency comparison process, identifying processing instances of the same business request on different application sides, thereby supporting subsequent precise association, item-by-item comparison, and result traceability analysis of request-response data.

[0035] In fintech scenarios, such as during the transformation of core transaction systems or credit approval systems, the original requests received by the first gateway cluster may include account query requests, credit assessment requests, or transaction execution requests. Target requests generated through mirroring rules can be synchronously sent to the next-generation accounting or risk control system without affecting the original transaction chain. By setting a request identifier consistent with the original request for the target request, it can be ensured that the processing results of the same transaction request in the original and new systems are accurately matched. This verifies the consistency of transaction status, risk control decision results, and returned data, thereby reducing business risks caused by system switching or model upgrades. In digital healthcare scenarios, such as during the upgrade of treatment decision support systems or medical insurance settlement systems, the original requests received by the first gateway cluster may include patient information query requests, treatment suggestion generation requests, or cost settlement requests. Target requests generated through mirroring can be synchronously processed in the new system. With a unified request identifier, the processing results of the same patient and the same treatment request in the original and new systems can be accurately matched. This compares the consistency of diagnostic suggestions, cost calculation results, or compliance verification logic, thereby verifying the reliability and accuracy of the new system without affecting actual medical business operations.

[0036] In practical implementation, the aforementioned mirroring and request identifier setting processes can be implemented by gateway components that support high-performance reverse proxying and scalable request processing capabilities. For example, in a more specific implementation, a gateway framework based on OpenResty can be used. Through the request processing and extension mechanisms provided by OpenResty, the original request can be mirrored and the request identifier injected before it enters the application. This allows for the synchronous generation and distribution of the target request without intruding into the business system code or changing the application deployment structure. It should be noted that OpenResty is only an exemplary implementation method and does not limit the specific gateway implementation technology. Any technology that can implement request mirroring and identifier injection at the gateway layer is applicable.

[0037] S3. The request message collection logic of the first gateway cluster and the second gateway cluster is used to obtain the request messages of the original request and the target request respectively, and the request messages are associated and stored according to the request identifier.

[0038] Step S3 above achieves request-level data alignment for the same business request across different application sides. This ensures that the request semantics of the original and target requests are synchronously captured before entering their respective applications, providing a unified data foundation for subsequent response association and consistency comparison. By collecting request messages at the gateway layer, request methods, request paths, request parameters, and request body data can be directly obtained without modifying business system code or relying on application logs. This avoids log loss, timing shifts, or data inconsistencies that may occur with application-layer collection.

[0039] Meanwhile, by setting a unified request identifier for both the original and target requests, and storing request messages in association based on this identifier, the access points for the same request in the source and replicated target applications can be accurately matched, supporting subsequent request-by-request comparison and problem localization. In scenarios such as fintech and digital healthcare, this step ensures that the access conditions for the same business request are consistent between the old and new systems, thereby reducing the risk of business deviations during system upgrades or replacements.

[0040] As an alternative implementation method, please continue reading. Figure 3 , Figure 3 This is a schematic diagram of the execution flow for obtaining request packets in the non-intrusive synchronous traffic replication and comparison method provided in this application embodiment, as shown below. Figure 3 As shown, it may also include the following steps S31 to S34.

[0041] S31. Before the original request is forwarded to the source target application, the original request is parsed to obtain the request method, request path, request header information and request body data of the original request, so as to generate the first request message corresponding to the original request.

[0042] The timing of request parsing and message generation is set before the original request is forwarded to the source target application. This aims to fully preserve the original access semantics of the request before business processing occurs. By obtaining information such as the request method, request path, request headers, and request body at this stage, it can be ensured that the generated first request message accurately reflects the entry conditions of the business request, unaffected by subsequent business logic processing, parameter changes, or exception returns. This provides an accurate data foundation for subsequent request alignment and consistency verification.

[0043] S32. Before the target request is forwarded to the target application to be copied, the target request is parsed to obtain the request method, request path, request header information and request body data of the target request, so as to generate the second request message corresponding to the target request.

[0044] Corresponding to the original request side, the target request is parsed and a second request message is generated before it is forwarded to the target application being replicated. This ensures that the replicated request maintains a symmetrical structure with the original request at the data level. By parsing the target request at the same stage, consistency in field dimensions, semantic structure, and collection timing between the first and second request messages can be guaranteed. This avoids issues such as missing or inconsistent request information caused by different parsing locations, laying a unified data format foundation for subsequent cross-system comparisons.

[0045] S33. Obtain the request identifiers corresponding to the original request and the target request, and establish a first association between the first request message and the second request message based on the request identifiers.

[0046] After generating the first and second request messages, a unified request identifier is introduced to establish a clear correspondence between the two messages. This ensures that request data for the same business request can be accurately matched on both the source and replicated target application sides. This association mechanism provides a stable index for subsequent response association, result comparison, and anomaly localization, avoiding request mismatches or data confusion in high-concurrency or multi-request scenarios.

[0047] S34. Based on the first association relationship, store the request data record where the first request message and the second request message are under the same request identifier.

[0048] Based on the established first association, the first and second request messages are uniformly stored as request data records under the same request identifier, achieving centralized management and traceable storage of request data. This storage method allows for the rapid retrieval of complete request information for the same request on different application sides during subsequent comparisons. It also supports retrospective analysis and batch statistics of historical requests, providing data support for system verification, problem investigation, and performance evaluation.

[0049] In practical implementation, the aforementioned request parsing, request message generation, and request identifier association storage processes can be implemented by gateway components that support high-performance request processing and flexible scalability. For example, in a more specific implementation, based on the request processing mechanism provided by OpenResty, the request content can be parsed before the request enters the application, and the generated request message and its request identifier can be stored in the context or cache structure on the gateway side. This allows for the collection and association of request messages without intruding on the business system code.

[0050] S4. Collect the response messages returned by the source target application and the replicated target application through the first gateway cluster and the second gateway cluster, and establish the association between the response messages and the corresponding request messages.

[0051] Step S4 above enables the processing results of the same business request on different application sides to form a complete request-response data loop. This ensures that after the business processing is completed, the response result can be accurately captured and correspond one-to-one with the preceding request data, providing a complete and reliable data foundation for subsequent consistency comparison. By collecting response messages at the gateway cluster layer, response status information, response header information, and response body data can be directly obtained without intruding on the application's internal logic or relying on the business log mechanism. This avoids response loss or mismatch issues caused by asynchronous log writing, interface callbacks, or message forwarding. Simultaneously, by associating response messages with corresponding request messages based on request identifiers, the processing results of the same request on the source target application side and the replicated target application side can be accurately mapped and uniformly managed, supporting subsequent comparison analysis and problem tracing.

[0052] In fintech scenarios, such as account inquiry, transaction execution, or risk control decision interfaces, request-response correlation allows for a transaction-by-transaction comparison of the return status, data, and anomaly information of the same transaction request in the original and new systems, verifying the consistency of accounting processing and risk control results. In digital healthcare scenarios, such as treatment decision support interfaces, electronic medical record access interfaces, or medical insurance settlement interfaces, the correlation between response and request messages allows for comparative analysis of diagnostic suggestions, cost calculation results, and compliance verification results, thereby ensuring the accuracy and security of business processes during system upgrades or replacements. Step S3 above, through the collection of response messages and their correlation with request messages, achieves traceable modeling of business processing results.

[0053] As an optional implementation, the process of collecting response messages in step S4 above may also specifically include the following steps S41 to S44.

[0054] S41. When the source target application returns the first response data, the first response data is parsed to obtain the response status information, response header information and response body data returned by the source target application, so as to generate the first response message corresponding to the source target application.

[0055] By setting the response parsing process after the source target application returns the business processing result, the complete capture of the actual business execution result can be ensured. By parsing the first response data and extracting response status information, response header information, and response body data, the processing status and return semantics of the source target application in the current business scenario can be comprehensively reflected, thereby avoiding the problems of missing or incomplete response information that may be caused by relying solely on application logs or business callbacks.

[0056] S42. When the target application being copied returns the second response data, the second response data is parsed to obtain the response status information, response header information and response body data returned by the target application being copied, so as to generate the second response message corresponding to the target application being copied.

[0057] Corresponding to the source target application, after the replicated target application returns its processing result, the second response data is parsed and a second response message is generated, ensuring that the response data of the replicated target application is consistent with that of the source target application in terms of structure and semantics. By collecting and parsing the response data at the same stage, the comparability of the first and second response messages in terms of field dimensions, data structure, and collection timing can be guaranteed, providing a unified data foundation for subsequent consistency comparisons.

[0058] S43. Obtain the request identifiers corresponding to the first response message and the second response message, and establish a second association relationship between the first response message and the second response message based on the request identifiers.

[0059] After generating the first and second response messages, the system obtains their corresponding request identifiers and establishes a correlation between the response messages based on these identifiers. This ensures that the processing results of the same business request can be accurately matched across different application sides. This correlation mechanism logically links the response data with the preceding request data, forming a complete request-response mapping relationship. This avoids response mismatches or inaccurate comparisons in high-concurrency or multi-service scenarios.

[0060] S44. Based on the second association relationship, store the response data record where the first response message and the second response message are under the same request identifier.

[0061] Based on the established second association, the first and second response messages are uniformly stored as response data records under the same request identifier, achieving centralized management and traceable storage of response data. This storage method allows for rapid location of the two-sided response results corresponding to the same request during subsequent comparison stages. It also supports retrospective analysis of abnormal and discrepancies in responses, providing reliable data support for system verification, problem localization, and result evaluation.

[0062] Through steps S41 to S44 above, unified collection and precise association of response data generated by the source target application and the replicated target application under the same business request are achieved. This enables the response results from different application sides to be matched one-to-one based on the request identifier and stored centrally. Without intruding on the internal processing logic of the application, a complete request-response data closed loop is constructed, avoiding the problems of response mismatch or data loss in concurrent scenarios. This provides a stable and reliable response data foundation for subsequent consistency comparison, thereby improving the accuracy and reliability of traffic replication comparison results.

[0063] S5. Execute a preset timed task to send the request messages and corresponding response messages from the first gateway cluster and the second gateway cluster to the target comparison platform.

[0064] Step S5 decouples the data acquisition and processing from the comparison and analysis process, allowing request and response data to be transmitted to the comparison platform in batches and periodically after being associated and stored. This avoids introducing synchronous communication or real-time blocking operations during request processing. By employing a scheduled task mechanism, the sending frequency of request and response data can be uniformly controlled while ensuring data integrity, reducing the impact on the gateway cluster's forwarding performance and improving the system's stability and scalability in high-concurrency scenarios. Step S5, through asynchronous and scheduled data transmission, provides a stable data input channel for subsequent consistency comparisons.

[0065] S6. Based on the same request identifier, perform a consistency comparison of the request and response data of the source target application and the copied target application in the target comparison platform to obtain the corresponding comparison results.

[0066] Step S6 implements a request-level consistency verification mechanism based on real production traffic. Using the request identifier as a unified index, it compares the request and response messages collected and associated in previous steps. This allows for precise comparison and analysis of the processing behavior and results of the same business request on different application sides, avoiding the verification bias caused by traditional verification based solely on interface return values ​​or single-sided logs. By uniformly parsing and comparing request and response data in the target comparison platform, it can simultaneously cover two dimensions: request entry conditions and business processing results. It can not only determine whether the returned results are consistent but also identify potential inconsistencies caused by differences in parameter parsing, state changes, or business rules. Compared to solutions that only compare response results, this consistency comparison method more comprehensively reflects the behavioral differences of the system under real load and real call scenarios, significantly improving the accuracy and reliability of the verification results.

[0067] In fintech scenarios, such as during core transaction system switching or risk control model upgrades, consistency comparison based on request identifiers allows for the verification of approval results, risk assessments, and returned data for the same transaction request in both the original and new systems, enabling timely detection of rule deviations or abnormal processing paths. In digital healthcare scenarios, such as during the transformation of diagnostic decision support systems or medical insurance settlement systems, consistency comparison of the processing results of the same diagnostic request across different systems verifies the consistency of diagnostic recommendations, cost calculation results, and compliance verification logic, reducing the impact of system upgrades on the accuracy and security of medical services. Step S6 above, by introducing a request-response consistency comparison mechanism based on request identifiers into the comparison platform, not only achieves traffic replication but also enables quantifiable and verifiable evaluation of the system transformation or replacement process.

[0068] As an alternative implementation method, please continue reading. Figure 4 , Figure 4 This is a schematic diagram of the execution flow of obtaining the comparison results in the non-intrusive synchronous traffic replication comparison method provided in the embodiments of this application, as shown below. Figure 4 As shown, it may also include the following steps S61 to S66.

[0069] S61. Based on the request identifier, obtain the request message and response message corresponding to the source target application and the request message and response message corresponding to the copied target application from the target comparison platform.

[0070] The comparison phase begins with data retrieval based on request identifiers. This ensures that all data entering the comparison process originates from processing instances of the same business request on different application sides. By using request identifiers as a unified index, request and response messages from both sides are simultaneously retrieved from the target comparison platform. This avoids data mixing issues across requests and time windows, providing a paired and complete data input foundation for subsequent comparisons.

[0071] S62. Perform structured parsing on the obtained request message to extract the request method, request path, request parameters, and request body data as request comparison data.

[0072] Before comparison on the request side, performing structured parsing of the request message and extracting key request elements helps transform the raw message data into a unified and comparable data format. This process eliminates differences caused by different protocol formats or encoding methods, ensuring that the request entry conditions are represented in a consistent structure within the comparison platform, thereby improving the accuracy of request-level consistency judgment.

[0073] S63. Perform structured parsing on the acquired response message to extract response status information, response header information, and response body data as response comparison data.

[0074] Corresponding to the request-side processing, structured parsing of response messages and extraction of response status and content can comprehensively reflect the semantic information of business processing results. By transforming response data into structured response comparison data, it is possible to avoid the impact of differences in return format, field order, or encoding methods on the comparison results, providing a unified data foundation for subsequent response consistency analysis.

[0075] S64. In the target comparison platform, perform a consistency comparison on the request comparison data of the source target application and the target application being copied.

[0076] After completing the unified representation of request data, a consistency comparison is performed on the request comparison data between the source target application and the replicated target application. This can be used to verify the consistency of the two systems in terms of request entry conditions. This comparison can identify potential inconsistencies caused by differences in parameter parsing, interface definition, or calling rules, thereby discovering the sources of deviation at the request level in advance before the result comparison.

[0077] S65. In the target comparison platform, a consistency comparison is performed on the response comparison data of the source target application and the target application being copied.

[0078] Performing consistency comparisons on the response side can directly reflect the differences in business processing results between the source target application and the replicated target application under the same request conditions. By comparing the response status and response content, inconsistencies in function implementation, business rules, or exception handling paths can be identified, providing intuitive evidence for system verification and problem localization.

[0079] S66. Based on the comparison results of the request comparison data and the response comparison data, generate a comparison result corresponding to the request identifier.

[0080] After comparing the request and response sides, the two comparison results are summarized and a comparison result corresponding to the request identifier is generated, so that each business request can form a clear verification conclusion. This comparison result can be used for difference analysis of a single request, as well as as a basis for subsequent statistical analysis and evaluation, thereby providing quantitative and traceable verification support for system transformation, upgrade or replacement processes.

[0081] Through steps S61 to S66, the request and response data of the source and replicated target applications under the same business request are uniformly acquired, structured, and compared based on the request identifier. This enables precise comparison of processing behaviors and results from different application sides at the request level. It not only identifies differences between request entry conditions and business processing results but also avoids comparison errors caused by cross-request data confusion. This provides quantifiable and traceable verification results for system modification or upgrade processes, significantly improving the accuracy and reliability of consistency comparison.

[0082] As a preferred implementation, the process of performing structured parsing of the request message in step S62 above may further include the following steps.

[0083] S621. Perform format recognition on the request message to determine the request protocol type corresponding to the request message.

[0084] The message format is first identified during the request parsing phase. This helps distinguish different types of request protocols, allowing for the selection of an appropriate parsing strategy for subsequent processes. This design avoids the problems of field parsing errors or missing information that can occur when using a single parsing method to handle multiple protocols, thus improving the accuracy and versatility of the request data parsing process.

[0085] S622. Based on the request protocol type, parse the request message to obtain the interface call method and request path in the request message.

[0086] After clarifying the request protocol type, targeted parsing of the request message helps to accurately extract key information that characterizes the semantics of the request access. By obtaining the interface call method and request path, the call type of the request and its corresponding business interface can be identified, thus providing a basis for subsequently judging the consistency of behavior at the interface call level among different systems.

[0087] S623. Extract request header information from the request message and obtain request parameters from the request header information according to the preset parsing rules.

[0088] By parsing the request header information and extracting request parameters based on preset rules, business-related information scattered throughout the request header can be uniformly included in the comparison scope. This method avoids comparison omissions caused by differences in parameter location or field organization, ensuring that request parameters are expressed in a consistent structural form within the comparison platform.

[0089] S624. Parse the request body data in the request message and convert the request body data into structured data format.

[0090] Parsing and converting request body data into a structured data format transforms potentially unstructured or semi-structured data into a computable and comparable representation. This process eliminates the impact of different data encoding methods or field arrangements on the comparison results, improving the stability and accuracy of request body data in consistency comparisons.

[0091] S625. The parsed interface call method, request path, request parameters and request body data are uniformly encapsulated to generate corresponding request comparison data.

[0092] After parsing various request information, the interface call method, request path, request parameters, and request body data are uniformly encapsulated, integrating multi-dimensional request information into standardized request comparison data. This unified encapsulation method simplifies the implementation of subsequent comparison logic and provides a consistent data structure foundation for batch comparison and statistical analysis between different requests.

[0093] Through steps S621 to S624 above, layered processing of request messages from protocol identification to content parsing is achieved. This enables the accurate extraction and conversion of interface call methods, request paths, request parameters, and request body data of different types of requests into a structured form. This effectively avoids parsing deviations caused by protocol differences, inconsistent data formats, or different field organization methods. It provides a standardized and reliable data foundation for the unified encapsulation and consistency comparison of subsequent request data, thereby improving the accuracy and stability of the request comparison process.

[0094] As another preferred implementation, the process of performing structured parsing of the response message in step S63 above may also specifically include the following steps.

[0095] S631. Format recognition is performed on the response message to determine the response protocol type corresponding to the response message.

[0096] Identifying the format of the response message before processing it helps determine the protocol type followed by the response data, thus allowing for the selection of a matching parsing method in the subsequent parsing process. This design avoids field identification errors caused by parsing different response protocols together, improving the accuracy and stability of the response data parsing process.

[0097] S632. Parse the response message according to the response protocol type to obtain the response status information in the response message.

[0098] After identifying the response protocol type, targeted parsing of the response message and obtaining response status information helps to accurately reflect the application's processing status under the current request. By extracting the response status, a direct basis for status judgment can be provided for subsequent consistency comparisons, thereby quickly identifying differences in success, failure, or exception handling paths across different application sides.

[0099] S633. Extract response header information from the response message and perform structured processing on the response header information.

[0100] By extracting and structuring the response header information, control information, metadata, or business-related fields carried in the response header can be uniformly included in the comparison scope. This method can avoid the impact of differences in the distribution or order of response header fields on the comparison results, ensuring that the response header information is expressed and analyzed in a consistent form within the comparison platform.

[0101] S634. Parse the response body data in the response message and convert the response body data into structured data format.

[0102] Parsing and converting response data into a structured data format transforms complex or diverse response content into a comparable data structure. This process reduces the interference of data format differences in comparison results, making response content comparable across different systems and thus improving the reliability of response consistency assessments.

[0103] S635. The parsed response status information, response header information, and response body data are uniformly encapsulated to generate corresponding response comparison data.

[0104] After parsing the response status information, response header information, and response body data, this information is uniformly encapsulated, integrating multi-dimensional response results into standardized response comparison data. This encapsulation method simplifies the subsequent consistency comparison process and provides a unified data foundation for batch comparison, result statistics, and difference analysis of response data.

[0105] Through the above steps S631 to S635, unified parsing, structured processing, and standardized encapsulation of response messages from different application sides are achieved. This enables response status information, response header information, and response body data to be expressed and managed in a consistent data structure, effectively eliminating the impact of different response protocols, data formats, or field organization methods on the results. This provides a stable and comparable data foundation for subsequent response consistency comparisons on the target comparison platform, thereby improving the accuracy and reliability of the response comparison results.

[0106] The non-intrusive synchronous traffic replication and comparison method provided in this application enables the same business request to be processed in parallel in both the source and target applications by uniformly accessing, synchronously mirroring, and non-intrusively collecting real business requests at the gateway layer. It also allows for complete association and structured management of request and response data, achieving consistency verification based on real production traffic without modifying business system code or affecting existing business links. This method accurately reproduces the processing behavior and results of different systems under the same request conditions, effectively avoiding timing deviations and data distortion problems caused by traditional log replay or offline simulation methods. It provides quantifiable and traceable verification evidence for system transformation, upgrades, or replacement processes, significantly improving the accuracy, stability, and engineering feasibility of traffic replication and comparison.

[0107] Please continue reading. Figure 5 , Figure 5 This is a schematic diagram of the system structure of the non-intrusive synchronous traffic replication and comparison device provided in the embodiments of this application, as shown below. Figure 5As shown, the non-intrusive synchronous traffic replication and comparison device 50 includes: an original request receiving module 51, an original request mirroring module 52, a request message processing module 53, a response message processing module 54, a message timing comparison module 55, and a comparison result generation module 56. The original request receiving module 51 is specifically used to receive original requests through a first gateway cluster and forward them to the source target application. The original request mirroring module 52 generates a target request for the original request in the first gateway cluster through mirroring, sends the target request to a second gateway cluster, and the target request is then forwarded by the second gateway cluster to the replicated target application. The request message processing module 53 acquires the request messages of the original request and the target request respectively through the request message acquisition logic of the first and second gateway clusters, and associates and stores the request messages according to the request identifier. The response message processing module 54 collects the response messages returned by the source target application and the replicated target application through the first and second gateway clusters, and establishes the association between the response messages and the corresponding request messages. The message timing comparison module 55 is used to execute a preset timing task to send request messages and corresponding response messages from the first gateway cluster and the second gateway cluster to the target comparison platform. The comparison result generation module 56 is used to perform a consistency comparison of the request and response data of the source target application and the copied target application in the target comparison platform based on the same request identifier, so as to obtain the corresponding comparison result.

[0108] As an optional implementation, the original request mirroring module 52 is further configured to, after the first gateway cluster receives the original request, copy the request parameters and request message content of the original request based on a preset mirroring rule to generate a target request corresponding to the original request; when generating the target request, set the same request identifier for the target request as the original request, and the request identifier is used to identify the correspondence between the target request and the original request.

[0109] As an optional implementation, the request message processing module 53 is further configured to: parse the original request before it is forwarded to the source target application, obtain the request method, request path, request header information, and request body data of the original request, and generate a first request message corresponding to the original request; parse the target request before it is forwarded to the copied target application, obtain the request method, request path, request header information, and request body data of the target request, and generate a second request message corresponding to the target request; obtain the request identifiers corresponding to the original request and the target request, establish a first association relationship between the first request message and the second request message based on the request identifiers; and store request data records where the first request message and the second request message share the same request identifier based on the first association relationship.

[0110] As an optional implementation, the response message processing module 54 is further specifically configured to: when the source target application returns first response data, parse the first response data to obtain the response status information, response header information, and response body data returned by the source target application, so as to generate a first response message corresponding to the source target application; when the copied target application returns second response data, parse the second response data to obtain the response status information, response header information, and response body data returned by the copied target application, so as to generate a second response message corresponding to the copied target application; obtain the request identifiers corresponding to the first response message and the second response message, establish a second association relationship between the first response message and the second response message based on the request identifiers; and store response data records where the first response message and the second response message are under the same request identifier based on the second association relationship.

[0111] As an optional implementation, the comparison result generation module 56 is further configured to: obtain, based on the request identifier, the request message and response message corresponding to the source target application, and the request message and response message corresponding to the copied target application from the target comparison platform; perform structured parsing on the obtained request messages to extract the request method, request path, request parameters, and request body data as request comparison data; perform structured parsing on the obtained response messages to extract the response status information, response header information, and response body data as response comparison data; perform a consistency comparison on the request comparison data of the source target application and the copied target application in the target comparison platform; perform a consistency comparison on the response comparison data of the source target application and the copied target application in the target comparison platform; and generate a comparison result corresponding to the request identifier based on the comparison results of the request comparison data and the response comparison data.

[0112] As an optional implementation, the comparison result generation module 56 is further configured to: identify the format of the request message to determine the request protocol type corresponding to the request message; parse the request message according to the request protocol type to obtain the interface call method and request path in the request message; extract request header information from the request message and obtain request parameters from the request header information according to preset parsing rules; parse the request body data in the request message and convert the request body data into structured data format; and uniformly encapsulate the parsed interface call method, request path, request parameters, and request body data to generate the corresponding request comparison data.

[0113] As an optional implementation, the comparison result generation module 56 is further configured to: identify the format of the response message to determine the response protocol type corresponding to the response message; parse the response message according to the response protocol type to obtain the response status information in the response message; extract the response header information from the response message and perform structured processing on the response header information; parse the response body data in the response message and convert the response body data into structured data format; and uniformly encapsulate the parsed response status information, response header information, and response body data to generate the corresponding response comparison data.

[0114] It should be noted that the aforementioned non-invasive synchronous traffic replication and comparison device can execute the non-invasive synchronous traffic replication and comparison method provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects of the method. Technical details not described in detail in the embodiments of the non-invasive synchronous traffic replication and comparison device can be found in the non-invasive synchronous traffic replication and comparison method provided in the embodiments of this application.

[0115] Figure 6 This is a schematic diagram of the hardware structure of the electronic device that performs the non-intrusive synchronous traffic replication and comparison method provided in the embodiments of this application, as shown below. Figure 6 As shown, the electronic device 600 includes: one or more processors 610 and a memory 620. Figure 6 Take the 610 processor as an example.

[0116] The processor 610 and the memory 620 can be connected via a bus or other means. Figure 6 Taking the example of a connection between China and Israel via a bus.

[0117] The memory 620, as a non-volatile computer-readable storage medium, can be used to store non-volatile software programs, non-volatile computer-executable programs, and modules, such as the program instructions / modules corresponding to the non-intrusive synchronous traffic replication and comparison method in the embodiments of this application. The processor 610 executes various functional applications and data processing of the server by running the non-volatile software programs, instructions, and modules stored in the memory 620, thereby implementing the non-intrusive synchronous traffic replication and comparison method described in the above embodiments.

[0118] The memory 620 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created based on the use of the non-intrusive synchronous traffic replication and comparison device. Furthermore, the memory 620 may include high-speed random access memory and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other non-volatile solid-state storage device. In some embodiments, the memory 620 may optionally include memory remotely located relative to the processor 610, and this remote memory may be connected to the non-intrusive synchronous traffic replication and comparison device via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0119] The one or more modules are stored in the memory 620. When executed by the one or more processors 610, they perform the non-intrusive synchronous traffic replication and comparison method in any of the above method embodiments, for example, performing the above-described... Figure 2 Method steps S1 to S6, Figure 3 Method steps S31 to S34, Figure 4 Method steps S61 to S66 are implemented. Figure 5 The functions of modules 51-55 in the document.

[0120] The above-described product can perform the methods provided in the embodiments of this application, and has the corresponding functional modules and beneficial effects for performing the methods. Technical details not described in detail in this embodiment can be found in the methods provided in the embodiments of this application.

[0121] This application provides a non-volatile computer-readable storage medium storing computer-executable instructions that are executed by one or more processors, for example... Figure 6 One of the processors 610 enables the one or more processors to execute the non-intrusive synchronous traffic replication comparison method in any of the above method embodiments, for example, to perform the above-described... Figure 2 Method steps S1 to S6, Figure 3Method steps S31 to S34, Figure 4 Method steps S61 to S66 are implemented. Figure 5 The functions of modules 51-55 in the document.

[0122] This application provides a computer program product, which includes a computer program stored on a non-volatile computer-readable storage medium. The computer program includes program instructions that, when executed by an electronic device, enable the electronic device to perform the non-intrusive synchronous traffic replication and comparison method described in any of the above method embodiments. For example, it can perform the above-described method. Figure 2 Method steps S1 to S6, Figure 3 Method steps S31 to S34, Figure 4 Method steps S61 to S66 are implemented. Figure 5 The functions of modules 51-55 in the document.

[0123] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0124] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented using software and a general-purpose hardware platform, or of course, using hardware. Those skilled in the art will understand that all or part of the processes in the above embodiments can be implemented by a computer program instructing related hardware. The program can be stored in a computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0125] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and not to limit them; under the concept of this application, the technical features of the above embodiments or different embodiments can also be combined, the steps can be implemented in any order, and there are many other variations of different aspects of this application as described above, which are not provided in detail for the sake of brevity; although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application.

Claims

1. A non-intrusive synchronous traffic replication and comparison method, characterized in that, include: The first gateway cluster receives the original request and forwards it to the source target application. The target request of the original request is generated in the first gateway cluster through the mirroring function, and the target request is sent to the second gateway cluster. The target request is then forwarded by the second gateway cluster to the target application to be replicated. The request message collection logic of the first gateway cluster and the second gateway cluster is used to obtain the request messages of the original request and the target request respectively, and the request messages are associated and stored according to the request identifier; The first gateway cluster and the second gateway cluster collect the response messages returned by the source target application and the replicated target application, and establish the association between the response messages and the corresponding request messages. Execute a preset timed task to send the request messages and corresponding response messages from the first gateway cluster and the second gateway cluster to the target comparison platform; Based on the same request identifier, the request and response data of the source target application and the copied target application are compared in the target comparison platform to obtain the corresponding comparison results.

2. The non-intrusive synchronous traffic replication and comparison method according to claim 1, characterized in that, The step of generating the target request of the original request in the first gateway cluster through the mirroring function includes: When the first gateway cluster receives the original request, it copies the request parameters and request message content of the original request based on the preset mirroring rules to generate a target request corresponding to the original request. When generating the target request, the same request identifier as the original request is set for the target request. The request identifier is used to identify the correspondence between the target request and the original request.

3. The non-intrusive synchronous traffic replication and comparison method according to claim 1, characterized in that, The step of acquiring the request messages of the original request and the target request respectively through the request message acquisition logic of the first gateway cluster and the second gateway cluster, and associating and storing the request messages according to the request identifier, includes: Before the original request is forwarded to the source target application, the original request is parsed to obtain the request method, request path, request header information and request body data of the original request, so as to generate the first request message corresponding to the original request; Before the target request is forwarded to the target application to be copied, the target request is parsed to obtain the request method, request path, request header information and request body data of the target request, so as to generate a second request message corresponding to the target request; Obtain the request identifiers corresponding to the original request and the target request, and establish a first association relationship between the first request message and the second request message based on the request identifiers; Based on the first association relationship, store request data records where the first request message and the second request message are under the same request identifier.

4. The non-intrusive synchronous traffic replication and comparison method according to claim 1, characterized in that, The step of collecting response messages returned by the source target application and the replicated target application through the first gateway cluster and the second gateway cluster, and establishing the association between the response messages and the corresponding request messages, includes: When the source target application returns the first response data, the first response data is parsed to obtain the response status information, response header information and response body data returned by the source target application, so as to generate the first response message corresponding to the source target application. When the target application being copied returns the second response data, the second response data is parsed to obtain the response status information, response header information and response body data returned by the target application being copied, so as to generate the second response message corresponding to the target application being copied. Obtain the request identifiers corresponding to the first response message and the second response message, and establish a second association relationship between the first response message and the second response message based on the request identifiers; Based on the second association relationship, store response data records where the first response message and the second response message are under the same request identifier.

5. The non-intrusive synchronous traffic replication and comparison method according to claim 1, characterized in that, The step of performing a consistency comparison of the request and response data of the source target application and the copied target application in the target comparison platform based on the same request identifier to obtain the corresponding comparison result includes: Based on the request identifier, the request message and response message corresponding to the source target application and the request message and response message corresponding to the copied target application are obtained from the target comparison platform, respectively. The obtained request message is parsed in a structured manner to extract the request method, request path, request parameters, and request body data, which are used as request comparison data. The acquired response messages are parsed in a structured manner to extract response status information, response header information, and response body data, which are used as response comparison data. In the target comparison platform, a consistency comparison is performed on the request comparison data of the source target application and the copied target application; In the target comparison platform, a consistency comparison is performed on the response comparison data of the source target application and the copied target application; Based on the comparison results of the request comparison data and the response comparison data, a comparison result corresponding to the request identifier is generated.

6. The non-intrusive synchronous traffic replication and comparison method according to claim 5, characterized in that, The step of performing structured parsing of the acquired request message to extract the request method, request path, request parameters, and request body data as request comparison data includes: The request message is formatted to determine the request protocol type corresponding to the request message; Based on the request protocol type, the request message is parsed to obtain the interface call method and request path in the request message; Extract request header information from the request message, and obtain request parameters from the request header information according to preset parsing rules; The request body data in the request message is parsed and converted into a structured data format; The parsed interface call method, request path, request parameters, and request body data are uniformly encapsulated to generate corresponding request comparison data.

7. The non-intrusive synchronous traffic replication and comparison method according to claim 5, characterized in that, The step of performing structured parsing on the acquired response message to extract response status information, response header information, and response body data as response comparison data includes: The response message is formatted to determine the response protocol type corresponding to the response message; The response message is parsed according to the response protocol type to obtain the response status information in the response message; Extract response header information from the response message and perform structured processing on the response header information; The response body data in the response message is parsed and converted into structured data format; The parsed response status information, response header information, and response body data are uniformly encapsulated to generate corresponding response comparison data.

8. A non-invasive synchronous flow replication and comparison device, characterized in that, include: The original request receiving module is used to receive the original request through the first gateway cluster and forward the original request to the source target application; The original request mirroring module is used to generate a target request for the original request in the first gateway cluster through the mirroring function, send the target request to the second gateway cluster, and then the target request is forwarded by the second gateway cluster to the target application to be replicated; The request message processing module is used to obtain the request messages of the original request and the target request respectively through the request message acquisition logic of the first gateway cluster and the second gateway cluster, and to store the request messages in association according to the request identifier; The response message processing module is used to collect the response messages returned by the source target application and the replicated target application through the first gateway cluster and the second gateway cluster, and establish the association between the response message and the corresponding request message; The message timing comparison module is used to execute a preset timing task to send the request messages and corresponding response messages in the first gateway cluster and the second gateway cluster to the target comparison platform; The comparison result generation module is used to perform a consistency comparison of the request and response data of the source target application and the copied target application in the target comparison platform based on the same request identifier, so as to obtain the corresponding comparison result.

9. An electronic device, characterized in that, include: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the non-intrusive synchronous traffic replication comparison method according to any one of claims 1-7.

10. A non-volatile computer-readable storage medium, characterized in that, The non-volatile computer-readable storage medium stores computer-executable instructions, which, when executed by an electronic device, cause the electronic device to perform the non-intrusive synchronous traffic replication and comparison method according to any one of claims 1-7.

Images