Method and device for realizing full-link tracking of service data and storage medium

Abstract

The invention discloses a method and a device for realizing full-link tracking of business data and a storage medium, which are used for tracking all associated businesses of an order. The method for realizing the full-link tracking of the service data comprises the following steps: receiving a service request sent by a client; generating a tracking identifier according to the service request, and storing the tracking identifier in a context related to the service request, the context being capable of being shared by multiple threads of the first service node; when multiple threads of the first service node need to respond to the service request, the service request is transmitted among the multiple threads based on the tracking identifier carried by the context; obtaining first service data of a multi-thread response service request; and returning the first service data to the client.

Description

Technical Field

[0001] The present application relates to the field of distributed link tracking technology, and in particular to a method, device and storage medium for implementing full-link tracking of business data. Background Art

[0002] Distributed link tracing technology can record how a single request flows between different modules of the entire system, the calling relationship between the modules in the entire calling link, how long each microservice takes to process, whether the processing result is correct, etc. The above recorded information is helpful for the operation and maintenance, performance analysis and fault tracking of the entire system.

[0003] However, with the continuous expansion and complexity of corporate business, the tracking mode of distributed link tracking technology can no longer meet all needs. Especially in business scenarios involving multi-threaded and multi-service collaborative processing, such as financial transaction processing, a typical transaction order may go through multiple stages such as order placement, payment, channel callback, result query and possible order closing. These stages may be processed by multiple threads of the same service node, and there are close business connections between multiple threads. In the scenario of multi-threaded and multi-service response to business requests, the existing distributed link tracking system cannot associate these scattered response processes through a unified tracking identifier, making it difficult to track the entire business life cycle. Summary of the invention

[0004] In order to solve the above technical problems, the present application provides a method, device and storage medium for implementing full-link tracking of business data, which are used to track all related businesses of an order.

[0005] The technical solution provided in this application is described below:

[0006] The first aspect of the present application provides a method for implementing full-link tracking of business data, including:

[0007] Receive business requests sent by clients;

[0008] generating a tracking identifier according to the service request, and storing the tracking identifier in a context related to the service request, wherein the context can be shared by multiple threads of the first service node;

[0009] When the multiple threads of the first service node need to respond to the service request, the service request is transmitted between the multiple threads based on the tracking identifier carried in the context;

[0010] Acquire first business data of the multithreaded response to the business request;

[0011] The first service data is returned to the client.

[0012] Optionally, the method further comprises:

[0013] When there is a second service node that needs to respond to the service request, sending the service request carrying the tracking identifier to the second service node;

[0014] receiving second service data from the second service node in response to the service request;

[0015] The second service data is returned to the client.

[0016] Optionally, generating a tracking identifier according to the service request includes:

[0017] When responding to the business request, the AOP aspect is used to intercept and obtain the return value of the business request;

[0018] A tracking identifier is generated according to the return value.

[0019] Optionally, after generating a tracking identifier according to the service request, the method further includes:

[0020] When it is detected that the business request has information update, the new information of the business request is intercepted and obtained through the AOP aspect;

[0021] The tracking indicator is updated according to the new information.

[0022] Optionally, intercepting and obtaining new information of the business request through the AOP aspect includes:

[0023] Creating an annotation and writing the annotation into the business request, wherein the annotation is used to identify a field name to be obtained in the business request and a location where the field name needs to be stored;

[0024] After intercepting and obtaining the annotation of the business request through the AOP aspect, new information of the business request is obtained according to the annotation.

[0025] Optionally, returning the first service data to the client or returning the second service data to the client includes:

[0026] Writing the first service data or the second service data into the MDC;

[0027] The data in the MDC is returned to the client in the form of a log.

[0028] Optionally, returning the first service data to the client or returning the second service data to the client includes:

[0029] extracting measurement data from the first business data or the second business data;

[0030] The metric data is uploaded to a service monitoring system and a time series database to be returned to the client.

[0031] A second aspect of the present application provides a device for implementing full-link tracking of business data, including:

[0032] A receiving unit, used for receiving a service request sent by a client;

[0033] A generating unit, configured to generate a tracking identifier according to the service request, and save the tracking identifier in a context related to the service request, wherein the context can be shared by multiple threads of the first service node;

[0034] a transmitting unit, configured to transmit the service request between the multiple threads based on the tracking identifier carried in the context when the multiple threads of the first service node need to respond to the service request;

[0035] A first service data unit, used for obtaining first service data of the multithreaded response to the service request;

[0036] The first returning unit is used to return the first service data to the client.

[0037] A third aspect of the present application provides a device for implementing full-link tracking of business data, the device comprising:

[0038] Processor, memory, input-output unit, and bus;

[0039] The processor is connected to the memory, the input and output unit, and the bus;

[0040] The memory stores a program, and the processor calls the program to execute the first aspect and any optional method for implementing full-link tracking of business data in the first aspect.

[0041] The fourth aspect of the present application provides a computer-readable storage medium, on which a program is stored. When the program is executed on a computer, the method for implementing full-link tracking of business data in the first aspect and any optional item in the first aspect is executed.

[0042] It can be seen from the above technical solutions that this application has the following advantages:

[0043] The present application provides a method for implementing full-link tracking of business data, which first receives a business request sent by a client; then generates a tracking identifier based on the business request, and saves the tracking identifier in a context related to the business request, and the context can be shared by multiple threads of a first service node; when multiple threads of the first service node need to respond to the business request, the business request is transferred between multiple threads based on the tracking identifier carried in the context; further, the first business data of the multi-threaded response to the business request is obtained; and finally, the first business data is returned to the client. The method of the present application sets a tracking identifier in a context related to the business request, and the context can be shared by multiple threads of the same service node, so that when multiple threads respond to the business request, the tracking identifier can be transferred between multiple threads, and then the business data of the multi-threaded response to the business request can be obtained, and then a unified tracking identifier can be extracted through the business data, and the relationship between the multiple threads and the process of transferring the business request between the multiple threads can be associated according to the unified tracking identifier, so as to realize the tracking of the entire business life cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] In order to more clearly illustrate the technical solution in the present application, the drawings required for use in the description of the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0045] Figure 1 A flowchart of an embodiment of a method for implementing full-link tracking of business data provided by this application;

[0046] Figure 2 A flowchart of another embodiment of the method for implementing full-link tracking of business data provided by the present application;

[0047] Figure 3 A flowchart of another embodiment of the method for implementing full-link tracking of business data provided by the present application;

[0048] Figure 4 A flowchart of another embodiment of the method for implementing full-link tracking of business data provided by the present application;

[0049] Figure 5 A flowchart of another embodiment of the method for implementing full-link tracking of business data provided by the present application;

[0050] Figure 6 A flowchart of another embodiment of the method for implementing full-link tracking of business data provided by the present application;

[0051] Figure 7A flowchart of another embodiment of the method for implementing full-link tracking of business data provided by the present application;

[0052] Figure 8 A schematic diagram of the structure of an embodiment of a device for implementing full-link tracking of business data provided by the present application;

[0053] Fig. 9 A schematic diagram of the structure of another embodiment of the device for implementing full-link tracking of business data provided in this application. DETAILED DESCRIPTION

[0054] Embodiments of the present invention are described in detail below, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain the present invention, and cannot be understood as limiting the present invention.

[0055] In the description of the present invention, "several" means one or more, "more" means more than two, "greater than", "less than", "exceed" etc. are understood as not including the number itself, and "above", "below", "within" etc. are understood as including the number itself. If there is a description of "first" or "second", it is only used for the purpose of distinguishing the technical features, and cannot be understood as indicating or implying the relative importance or implicitly indicating the number of the indicated technical features or implicitly indicating the order of the indicated technical features.

[0056] In the description of the present invention, it should be understood that descriptions involving orientation, such as up, down, left, right, front, back, etc., indicating orientations or positional relationships, are based on the orientations or positional relationships shown in the accompanying drawings, and are only for the convenience of describing the present invention and simplifying the description, rather than indicating or implying that the device or element referred to must have a specific orientation, be constructed and operated in a specific orientation, and therefore should not be understood as a limitation on the present invention.

[0057] In the description of this specification, the description with reference to the terms "one embodiment", "some embodiments", "illustrative embodiments", "examples", "specific examples", or "some examples" means that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representation of the above terms does not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0058] In the description of the present invention, it should be noted that, unless otherwise clearly defined, terms such as setting, installing, connecting, etc. should be understood in a broad sense, and technicians in the relevant technical field can reasonably determine the specific meanings of the above terms in the present invention in combination with the specific content of the technical solution. In addition, the identification of specific steps below does not represent a limitation on the order of steps and execution logic, and the execution order and execution logic between each step should be understood and inferred with reference to the contents described in the embodiment.

[0059] It should be noted that the method for implementing full-link tracking of business data provided in this application can be applied to terminals, systems, and servers. For example, the terminal can be a smart phone or computer, tablet computer, smart TV, smart watch, portable computer terminal, or a fixed terminal such as a desktop computer. For the convenience of explanation, this application uses the terminal as the execution subject for example.

[0060] It should also be noted that the terms "first", "second", etc. in the specification and drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order, sequence or importance.

[0061] The present invention aims to solve at least one of the technical problems existing in the prior art. To this end, the present invention proposes a method, device and storage medium for achieving full-link tracking of business data.

[0062] See also Figure 1 , Figure 1 A flow chart of an embodiment of a method for implementing full-link tracking of business data provided by the present application, the method comprising:

[0063] Step S101, receiving a service request sent by a client;

[0064] Step S102, generating a tracking identifier according to the service request, and saving the tracking identifier in a context related to the service request, where the context can be shared by multiple threads of the first service node;

[0065] Step S103: when multiple threads of the first service node need to respond to a service request, the service request is transmitted between the multiple threads based on the tracking identifier carried in the context;

[0066] Step S104, obtaining first service data of a multi-threaded response service request;

[0067] Step S105: returning the first service data to the client.

[0068] The method for implementing full-link tracking of business data provided by the present application first receives a business request sent by a client; then generates a tracking identifier based on the business request, and saves the tracking identifier in a context related to the business request, and the context can be shared by multiple threads of the first service node; when multiple threads of the first service node need to respond to the business request, the business request is transferred between multiple threads based on the tracking identifier carried in the context; further, the first business data of the multi-threaded response to the business request is obtained; and finally, the first business data is returned to the client. The method of the present application sets a tracking identifier in a context related to the business request, and the context can be shared by multiple threads of the same service node, so that when multiple threads respond to the business request, the tracking identifier can be transferred between multiple threads, and then the business data of the multi-threaded response to the business request can be obtained, and then a unified tracking identifier can be extracted through the business data, and the relationship between the multiple threads and the process of transferring the business request between the multiple threads can be associated according to the unified tracking identifier, so as to realize the tracking of the entire business life cycle.

[0069] In step S101 of some embodiments, a service request sent by a client is received. First, a service request from a client is received through HTTP, HTTPS or other network communication protocols. The service request may contain various service-specific contents and related parameters, which are used to instruct service nodes, etc. to respond to specific service operations. To ensure correct parsing and identification of the request sent by the client, the service request of this embodiment may specifically include but is not limited to the following: the type, parameters and data format of the request, etc. Taking the service request as a transaction order as an example, the service request includes the order number, order type, transaction content, time, information of both parties to the transaction and the specified transaction process, etc. of the transaction order.

[0070] In step S102 of some embodiments, a tracking identifier is generated according to the business request, and the tracking identifier is saved in the context related to the business request, and the context can be shared by multiple threads of the first service node. After receiving the business request, the system needs to generate a unique tracking identifier for tracking and associating the request during the entire request processing process. This tracking identifier will be saved in the context related to the business request so that subsequent processing steps can access and use the tracking identifier. The generated tracking identifier is stored in the context, which means that the business request carries the context with the tracking identifier, and the tracking identifier is also passed in the process of transmitting the business request. It should be noted that the generation of the tracking identifier can adopt a timestamp, UUID or other uniqueness algorithm (for example, applied to the transaction order mentioned in step S101, a unique tracking identifier can be generated according to the order number of the transaction order).

[0071] Generally, the tracing identifier is not directly transmitted between multiple threads of the same service node, but it can be transmitted by wrapping the thread pool, that is, setting tools such as context to propagate the tracing identifier. The context is usually a thread-local storage object or other tool that can share data between threads, which can store the tracing identifier and the information of the thread that calls the context, including the ID of the thread, the calling time, etc. It should be noted that in the multi-threaded environment of the first service node, the context should be designed to be thread-safe to ensure the shareability of the context and the correct transmission and access of the context between different threads.

[0072] Reference Figure 2 According to some embodiments of the present invention, generating a tracking identifier according to the service request in step S102 may specifically include, but is not limited to, the following:

[0073] Step S201, when responding to a business request, intercept and obtain the return value of the business request through the AOP aspect;

[0074] Step S202: Generate a tracking identifier according to the returned value.

[0075] In steps S201 to S202 of some embodiments, when responding to a business request, the return value of the business request is intercepted and obtained through the AOP aspect; and then a tracking identifier is generated according to the return value. AOP aspect is a type of AOP technology. An AOP aspect is defined in the system, and the aspect will be applied to the execution points of all methods that respond to business requests. The definition of the aspect usually includes a pointcut expression, which is used to specify which methods will be intercepted. One or more notifications are written in the aspect, and these notifications will be triggered after the execution operation in response to the business request is completed. Common notification types include "post notifications", which allow custom logic to be executed after the method returns normally. The aspect is associated with the method that responds to the business request through the pointcut expression. The pointcut expression can be configured based on multiple conditions such as method name, annotation, package path, etc. Therefore, in the notification of the AOP aspect, a certain parameter data in the business request is parsed through the method return value. The parsed parameter data is then verified to ensure its validity and uniqueness. It should be noted that this step is not necessary in the automatic generation of the tracking identifier. For example, when a transaction order is used as a business request, the order number of the transaction order is used as input, and a unique tracking identifier is generated through a certain algorithm (such as UUID combined with the order number prefix or hash algorithm). It should be noted that the tracking identifier generation algorithm can be customized according to system requirements.

[0076] Reference Figure 3According to some embodiments of the present invention, after the tracking identifier is generated in step S102 or step S202, in practice, the data carried in the business request is usually added or modified. If the tracking identifier is not adaptively added or modified according to the data update of the business request, the correct process information cannot be queried and tracked in subsequent steps. Therefore, the tracking identifier needs to be updated in real time, which may include, but is not limited to, the following:

[0077] Step S301, when it is detected that the business request has information update, the new information of the business request is intercepted and obtained through the AOP aspect;

[0078] Step S302: Update the tracking identifier according to the new information.

[0079] In steps S301 to S302 of some embodiments, when it is detected that a business request has an information update, the new information of the business request is intercepted and obtained through the AOP aspect; the tracking identifier is updated according to the new information. An event listener is set to monitor related events of business request information update. When the event listener detects a business request information update event, the updated new information is extracted from the event message. The acquired new information is verified to ensure its integrity and validity. The verification process may include checking the information format, consistency check with existing data, etc. After confirming that the new information is correct, the new information is stored in the tracking identifier. For example, taking a transaction order as a business request, the information update event may be triggered by an order processing service, an inventory service, or a payment service. The updated new information that can be extracted from the event message may include any order-related fields such as order status, amount, and delivery address. The verified new information is further stored in the tracking identifier. Thereby achieving the purpose of updating the correct information in real time and ensuring the correctness of subsequent steps.

[0080] Reference Figure 4 According to some embodiments of the present invention, the new information of the service request obtained in step S301 may specifically include, but is not limited to, the following:

[0081] Step S401, creating an annotation and writing the annotation into the business request, the annotation is used to identify the field name that needs to be obtained in the business request and the location where the field name needs to be stored;

[0082] Step S402, after intercepting and obtaining the annotation of the business request through the AOP aspect, new information of the business request is obtained according to the annotation.

[0083] In steps S401 to S402 of some embodiments, an annotation is first created and written into a business request. The annotation is used to identify the field name that needs to be obtained in the business request and the location where the field name needs to be stored; then, after intercepting and obtaining the annotation of the business request through the AOP aspect, new information of the business request is obtained according to the annotation. One or more custom annotations are defined to identify the fields that need to be monitored in the business request. The annotation should contain meta-information such as the field name (or the matching pattern of the field name), whether it needs to be monitored and updated, and the location where the updated information should be stored. These custom annotations are applied to the relevant fields of the business request. For example, taking a transaction order as a business request, if the "delivery address" field in the transaction order needs to be monitored, a corresponding annotation is added to the declaration of the field and its meta-information is specified. Similar to the AOP technology used in step S201, one or more notifications (such as pre-notifications, post-notifications, etc.) are written in the AOP aspect to execute custom logic before and after the execution of the transaction order processing method. In the notification, iterate over all fields of the trade order object, check if they have custom annotations applied, and obtain the annotation information in the trade order. Extract the update information of the corresponding field in the trade order object according to the field name and update information storage location specified in the annotation. If the value of the field has changed since the last check, the change is considered as update information and stored in the specified location according to the instructions in the annotation.

[0084] In step S103 of some embodiments, when multiple threads of the first service node need to respond to a service request, the service request is transferred between multiple threads based on the tracking identifier carried in the context. In the multi-threaded environment of the first service node, when a thread needs to respond to a service request, the thread can obtain the tracking identifier from the context, and obtain the service request based on the tracking identifier, thereby achieving the transfer of the service request between multiple threads. For example, a thread obtains an order number based on the tracking identifier, and then obtains the corresponding transaction order based on the order number, and then completes the response operation based on the content of the transaction order and the function of the thread itself.

[0085] In step S104 of some embodiments, the first business data of the multi-threaded response to the business request is obtained. The business data generated by the multi-thread can be obtained through a callback mechanism, a Future object or other asynchronous processing mechanism. When obtaining the first business data, it is necessary to ensure the integrity and correctness of the data, and to be able to associate the first business data with the business request. Among them, the first business data includes: thread information responding to the business request, the process of the thread responding to the business request, and the subsequent processing of the business request after the thread responds to the business request. For example, after a thread responds to the transaction order mentioned in step S101, the first business data includes the ID of the thread that performs the response operation, the status of the order (such as paid, waiting to be shipped, etc.), payment information, logistics information and other specific responses to the transaction order, and the ID of other threads after the transaction order is passed to other threads.

[0086] In step S105 of some embodiments, the first business data is returned to the client. In order to allow the user to query the business data on the client, the first business data obtained in step S104 needs to be returned to the client, and the user can subsequently track the business request through the first business data on the client. For example, after receiving the first business data, the client will parse and display the first business data so that the user can view the detailed information and status of the transaction order. The business data can be returned to the client via an HTTP response, a WebSocket message, or other network communication protocols. When returning data, it should be ensured that the format and content of the data meet the expectations and requirements of the client.

[0087] Reference Figure 5 ,Apart from Figure 1 In the embodiment, the multi-threaded response of the same service node to the service request may actually also be a scenario where different service nodes respond to the service request. The steps of transmitting the tracking identifier between the multiple service nodes may specifically include, but are not limited to, the following:

[0088] Step S501: When there is a second service node that needs to respond to a service request, a service request carrying a tracking identifier is sent to the second service node;

[0089] Step S502, receiving second service data from the second service node in response to the service request;

[0090] Step S503: Return the second service data to the client.

[0091] In steps S501 to S503 of some embodiments, when there is a second service node that needs to respond to a service request, a service request carrying a tracking identifier is sent to the second service node; then the second service data of the second service node in response to the service request is received; and the second service data is returned to the client. It should be noted that the multi-threaded processing flow within the second service node is the same as the multi-threaded processing flow within the first service node of right 1. Steps S501 to S503 of this embodiment focus on describing the transmission of tracking identifiers between multiple service nodes. Whether it is the first service node or the second service node, after responding to the service request, business data will be generated and stored. Similar to the processing of the first service node, it is necessary to ensure the integrity and correctness of the second business data generated when the second service node responds to the service request, and to be able to associate the second business data with the service request.

[0092] It should be noted that when a business request is transmitted from the first service node to the second service node, the business request is processed at the first service node, and a corresponding new context is generated or updated inside the first service node according to the business request, such as user information of the transaction order, order status, etc. The generated context is written into the business request. After the first service node completes the processing, it sends the call request and the business request to the next service node (i.e., the second service node) so that the subsequent service nodes can identify and access the context and tracking identifier of the business request.

[0093] The second service node receives the call request and business request from the first service node, and updates or supplements the context again according to the function of the second service node. Taking the transaction order as an example, the second service node may update the order status, add processing logs, etc. The updated context is rewritten into the business request so that the subsequent service nodes can access the latest context. After the second service node completes all processing, it sends the new call request and business request to the next service, and repeats the above process until all operations in response to the business request are executed.

[0094] Reference Figure 6 The step of returning the first service data to the client in step S105 or the step of returning the second service data to the client in step S503 may specifically include, but not limited to, the following:

[0095] Step S601, writing the first service data or the second service data into the MDC;

[0096] Step S602: Return the data in the MDC to the client in the form of logs.

[0097] In steps S601 to S602 of some embodiments, the first business data or the second business data is first written into the MDC; and then the data in the MDC is returned to the client in the form of a log. The first business data or the second business data is parsed to extract key information that needs to be recorded in the log (such as user information, order status, processing time, etc. in the transaction order). The MDC mechanism provided by the log framework (such as Log4j, Logback, etc.) is used to write the key information into the MDC as a key-value pair. MDC is a thread-local variable used to store and access diagnostic information in the current thread without affecting other threads. In the log configuration file, the output format of the log is configured to ensure that the log contains the information in the MDC. When it is necessary to record the log, the log framework will automatically insert the data in the MDC into the log format string to generate a complete log entry containing context information. The generated log entry is sent to a specified log storage system (such as a file system, a database, a log center, etc.) for subsequent analysis and query. Thereby, the data of distributed link tracking is output through the log, which is convenient for relevant personnel to query the relevant business of the order.

[0098] Reference Figure 7 The step of returning the first service data to the client in step S105 or the step of returning the second service data to the client in step S503 may specifically include, but not limited to, the following:

[0099] Step S701, extracting measurement data from the first business data or the second business data;

[0100] Step S702, uploading the measurement data to the service monitoring system and the time series database to return to the client.

[0101] In steps S701 to S702 of some embodiments, the metric data is first extracted from the first business data or the second business data; and then the metric data is uploaded to the service monitoring system and the time series database to be returned to the client. The metric data is parsed and extracted from the first business data or the second business data. The metric data may include multiple indicators such as response time, throughput, error rate, resource utilization rate, etc. Then the extracted metric data is formatted to ensure that it meets the storage requirements of the service monitoring system and the time series database, including data type conversion, timestamp addition, data unit unification, etc. The formatted metric data is further uploaded to the service monitoring system. The service monitoring system is responsible for real-time monitoring of the operating status of the system, including service availability, performance indicators, etc. By integrating metric data, the service monitoring system can more comprehensively evaluate system performance and promptly discover potential problems. At the same time, the metric data is uploaded to the time series database. The time series database is a database system designed specifically for storing and analyzing time series data, which supports efficient data query and complex data analysis operations. By storing in a historical time series database, the metric data can be used in a variety of scenarios such as long-term trend analysis, anomaly detection, and resource prediction. In-depth analysis of uploaded metric data is performed in the service monitoring system and time series database. The analysis may include performance bottleneck identification, abnormal behavior detection, resource utilization optimization, etc. The analysis results are output in the form of charts, reports, etc., providing intuitive performance monitoring and troubleshooting tools for system administrators and developers.

[0102] The above embodiment describes the method for implementing full-link tracking of business data provided by the present application. The following describes the device and storage medium for implementing full-link tracking of business data provided by the present application:

[0103] See also Figure 8 , the device for realizing full-link tracking of business data includes:

[0104] The receiving unit 801 is used to receive a service request sent by a client;

[0105] A generating unit 802 is used to generate a tracking identifier according to the service request, and save the tracking identifier in a context related to the service request, where the context can be shared by multiple threads of the first service node;

[0106] A transmission unit 803, configured to transmit the service request between the multiple threads based on the tracking identifier carried in the context when the multiple threads of the first service node need to respond to the service request;

[0107] The first service data unit 804 is used to obtain the first service data of the multi-threaded response service request;

[0108] The first returning unit 805 is configured to return the first service data to the client.

[0109] Optionally, the device for implementing full-link tracking of business data also includes:

[0110] The sending unit 806 is configured to send a service request carrying a tracking identifier to the second service node when there is a second service node that needs to respond to the service request;

[0111] The second service data unit 807 receives the second service data of the second service node in response to the service request;

[0112] The second returning unit 808 is configured to return the second service data to the client.

[0113] Optionally, the generating unit 802 is specifically configured to:

[0114] When responding to business requests, the AOP aspect is used to intercept and obtain the return value of the business request;

[0115] Generates a trace flag based on the return value.

[0116] Optionally, after the generating unit 802, the method further includes:

[0117] New information unit 809, used to intercept and obtain new information of the business request through the AOP aspect when it is detected that the business request has information update;

[0118] The updating unit 810 is used to update the tracking identifier according to the new information.

[0119] Optionally, the new information unit 809 is specifically used for:

[0120] Create annotations and write them into business requests. Annotations are used to identify the field names that need to be obtained in business requests and the locations where the field names need to be stored.

[0121] After intercepting and obtaining the annotation of the business request through the AOP aspect, new information of the business request is obtained based on the annotation.

[0122] Optionally, the first returning unit 805 or the second returning unit 808 is specifically used for:

[0123] Writing the first service data or the second service data into the MDC;

[0124] Return the data in the MDC to the client in the form of logs.

[0125] Optionally, the first returning unit 805 or the second returning unit 808 is specifically used for:

[0126] extracting measurement data from the first business data or the second business data;

[0127] Upload metric data to service monitoring systems and time series databases for return to clients.

[0128] This application also provides a device for achieving full-link tracking of business data, please refer to Fig. 9 , the device for realizing full-link tracking of business data includes:

[0129] Processor 901, memory 902, input and output unit 903, bus 904;

[0130] The processor 901 is connected to the memory 902, the input and output unit 903 and the bus 904;

[0131] The memory 902 stores a program, and the processor 901 calls the program to execute the following steps: Figures 1 to 7 A method for implementing full-link tracking of business data as shown in any embodiment.

[0132] The present application also relates to a computer-readable storage medium, on which a program is stored, wherein when the program is run on a computer, the computer executes Figures 1 to 7 A method for implementing full-link tracking of business data as shown in any embodiment.

[0133] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working processes of the systems, devices and units described above can refer to the corresponding processes in the aforementioned method embodiments and will not be repeated here.

[0134] In the several embodiments provided in the present application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of the units is only a logical function division. There may be other division methods in actual implementation, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

[0135] The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0136] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit. The above-mentioned integrated unit may be implemented in the form of hardware or in the form of software functional units.

[0137] If the integrated unit is implemented in the form of a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or all or part of the technical solution can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions to enable a computer device (which can be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes: U disk, mobile hard disk, read-only memory (ROM, read-only memory), random access memory (RAM, random access memory), disk or optical disk and other media that can store program code.

Claims

1. A method for achieving full-link tracking of business data, characterized in that: Applied to a first service node, the method includes: Receive business requests sent by clients; generating a tracking identifier according to the service request, and storing the tracking identifier in a context related to the service request, wherein the context can be shared by multiple threads of the first service node; When the multiple threads of the first service node need to respond to the service request, the service request is transmitted between the multiple threads based on the tracking identifier carried in the context; Acquire first business data of the multithreaded response to the business request; The first service data is returned to the client.

2. The method according to claim 1, characterized in that The method further comprises: When there is a second service node that needs to respond to the service request, sending the service request carrying the tracking identifier to the second service node; receiving second service data from the second service node in response to the service request; The second service data is returned to the client.

3. The method according to claim 1, characterized in that Generating a tracking identifier according to the service request includes: When responding to the business request, the AOP aspect is used to intercept and obtain the return value of the business request; A tracking identifier is generated according to the return value.

4. The method according to claim 1, characterized in that After generating a tracking identifier according to the service request, the method further includes: When it is detected that the business request has information update, the new information of the business request is intercepted and obtained through the AOP aspect; The tracking indicator is updated according to the new information.

5. The method according to claim 4, characterized in that The new information of intercepting and obtaining the business request through the AOP aspect includes: Creating an annotation and writing the annotation into the business request, wherein the annotation is used to identify a field name to be obtained in the business request and a location where the field name needs to be stored; After intercepting and obtaining the annotation of the business request through the AOP aspect, new information of the business request is obtained according to the annotation.

6. The method according to claim 2, characterized in that The returning the first service data to the client or the returning the second service data to the client comprises: Writing the first service data or the second service data into the MDC; The data in the MDC is returned to the client in the form of a log.

7. The method according to claim 2, characterized in that The returning the first service data to the client or the returning the second service data to the client comprises: extracting measurement data from the first business data or the second business data; The metric data is uploaded to a service monitoring system and a time series database to be returned to the client.

8. A device for realizing full-link tracking of business data, characterized in that: include: A receiving unit, used for receiving a service request sent by a client; A generating unit, configured to generate a tracking identifier according to the service request, and save the tracking identifier in a context related to the service request, wherein the context can be shared by multiple threads of the first service node; a transmitting unit, configured to transmit the service request between the multiple threads based on the tracking identifier carried in the context when the multiple threads of the first service node need to respond to the service request; A first service data unit, used for obtaining first service data of the multithreaded response to the service request; The first returning unit is used to return the first service data to the client.

9. A device for realizing full-link tracking of business data, characterized in that: The device comprises: Processor, memory, input-output unit, and bus; The processor is connected to the memory, the input and output unit, and the bus; The memory stores a program, and the processor calls the program to execute the method for implementing full-link tracking of business data as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a program stored thereon, wherein the program, when executed on a computer, executes the method for implementing full-link tracking of business data as claimed in any one of claims 1 to 7.

Images