Context information processing method and device, computer equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a context information processing method and device, computer equipment and a storage medium. According to the method, first context information is carried in a first processing request generated by a first micro-service. The first context information is obtained by compressing second context information composed of a trace identifier, a parent span identifier, a current span identifier and an optional field by the first micro-service in a preset coding format. As the size of the first context information is reduced, in the process of sending the first processing request to the third micro-service by the first micro-service, the communication load of the first context information in the transmission process is reduced, the consumption of communication resources is reduced, the communication efficiency is improved, and the system load is reduced.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, apparatus, computer device, and storage medium for processing context information. Background Technology

[0002] Distributed tracing, as an important technique in microservice architecture, can track the transmission process of user requests by recording the context information of user requests as they are passed through microservices, thereby enabling the monitoring and analysis of system performance.

[0003] Current trace tracing schemes typically transmit context information between microservices that includes at least a `traceparent` field, a `tracestate` field, and a `baggage` field. The `traceparent` field carries a version number, trace ID, span ID, and flags. The `tracestate` field carries vendor-defined information. The `baggage` field carries business tags, etc. This scheme consumes significant communication resources and results in high system load. Summary of the Invention

[0004] To address the aforementioned technical problems, this application provides a context information processing method, apparatus, computer device, and storage medium.

[0005] Firstly, this application provides a context information processing method, the method comprising:

[0006] The first microservice generates a first processing request for the user's business; wherein, the first processing request carries first context information, which is obtained by compressing the second context information using a preset encoding format; the second context information consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields; wherein, the parent span identifier is the identifier corresponding to the second microservice that called the first microservice, and the current span identifier is the identifier corresponding to the first microservice; the first microservice sends the first processing request to the third microservice.

[0007] In some optional embodiments, the total length of the second context information is less than or equal to 28 bytes.

[0008] In some optional embodiments, the first microservice generates a first processing request for the user's business, including: the first microservice obtaining second context information from the target cache corresponding to the first microservice through a preset plugin; and the first microservice injecting the first context information into the first processing request through the preset plugin.

[0009] In some optional embodiments, the default plugin can be an interceptor or a middleware gateway; wherein the interceptor is one of the following: ClientHttpRequestInterceptor, Feign plugin, Filter, HandlerInterceptor, ClientInterceptor, ServerInterceptor; or, the middleware gateway is the Kong plugin.

[0010] In some optional embodiments, before the first microservice generates the first processing request for the user's business, the method further includes:

[0011] Under the condition of meeting the preset exception, the third context information is obtained from the target cache corresponding to the first microservice. The first context information is a part of the context information in the third context information. The third context information is then associated with the logs of the first microservice.

[0012] In some optional embodiments, the preset abnormal conditions include at least one of the following:

[0013] The first microservice provides an HTTP interface path to the user's business that is on a pre-defined whitelist; the response status code is abnormal; and uncaught exceptions or errors at the error level are detected in the logs.

[0014] In some optional embodiments, the first microservice runs a first thread and a second thread, wherein the first thread corresponds to a first cache and the second thread corresponds to a second cache; before the first microservice generates a first processing request for the user's business, the method further includes:

[0015] The first thread retrieves the fourth context information from the first cache, which includes the trace identifier and the current span identifier. The first thread encapsulates the fourth context information and the first task into a second task, which is a task to be executed by the second thread to process user business. The second thread retrieves the fourth context information from the second task and stores the fourth context information in the second cache.

[0016] Secondly, this application provides a context information processing apparatus, the apparatus comprising:

[0017] The generation module is used by the first microservice to generate a first processing request for the user's business. The first processing request carries first context information, which is obtained by compressing second context information using a preset encoding format. The second context information consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields. The parent span identifier is the identifier of the second microservice that called the first microservice, and the current span identifier is the identifier of the first microservice. The sending module is used by the first microservice to send the first processing request to the third microservice.

[0018] Thirdly, this application provides a computer device, comprising:

[0019] The memory and the processor are interconnected and communicate with each other. The memory stores computer instructions, and the processor executes the computer instructions to perform the context information processing method corresponding to the first aspect and any embodiment thereof.

[0020] Fourthly, this application provides a computer-readable storage medium storing computer instructions, which are used to cause a computer to execute the context information processing method corresponding to the first aspect and any embodiment thereof.

[0021] The technical solution provided in this application has the following advantages compared with the prior art:

[0022] The context information processing method provided in this embodiment carries first context information in the first processing request generated by the first microservice. The first context information is obtained by the first microservice compressing second context information, which consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields, using a preset encoding format. Because the size of the first context information is reduced, the communication load on the first context information during transmission is lessened when the first microservice sends the first processing request to the third microservice, reducing the consumption of communication resources, improving communication efficiency, and reducing system load. Attached Figure Description

[0023] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

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

[0025] Figure 1 A flowchart illustrating a context information processing method provided in an embodiment of this application;

[0026] Figure 2 A flowchart illustrating a preferred context information processing method provided in this application embodiment;

[0027] Figure 3 A structural connection diagram of a context information processing device provided in an embodiment of this application;

[0028] Figure 4 This is a structural connection diagram of a computer device provided in an embodiment of this application. Detailed Implementation

[0029] To better understand the above-mentioned objectives, features, and advantages of this application, the solution of this application will be further described below. It should be noted that, unless otherwise specified, the embodiments and features described in these embodiments can be combined with each other.

[0030] Many specific details are set forth in the following description to provide a thorough understanding of this application, but this application may also be implemented in other ways different from those described herein; obviously, the embodiments in the specification are only a part of the embodiments of this application, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without inventive effort are within the scope of protection of this invention.

[0031] According to an embodiment of the present invention, a context information processing method embodiment is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0032] To facilitate understanding, the technical terms and related concepts involved in the embodiments of this application will be introduced below.

[0033] 1. Link tracing

[0034] Distributed tracing is a technique used to monitor and analyze the performance of distributed systems. By recording the transmission process of user requests across multiple microservices, distributed tracing can help locate performance bottlenecks and troubleshoot faults. For example, in this embodiment, microservices may include, but are not limited to, gateways, databases, caches, and message queues.

[0035] The core concepts of link tracing include trace and span.

[0036] A trace represents the complete lifecycle of a user request, from the initiation of the request to its termination. Each trace can be identified by a unique traceID.

[0037] Each trace can include multiple spans. A span refers to the specific operation performed by a microservice in response to a user request. Each span can be identified by a unique spanID.

[0038] 2. Contextual information

[0039] In a distributed system, a user request is processed by multiple microservices, which are deployed independently. Therefore, context information can be used by different microservices to know that they are processing the same user request.

[0040] For example, the context information may carry trace ID, span ID, and other auxiliary information (such as timestamp, microservice name, etc.).

[0041] When a user request is passed from microservice A to microservice B, the context information that needs to be carried includes, but is not limited to, trace ID, span ID, etc., to ensure that microservice B and microservice A are associated with the same link.

[0042] In current link tracing schemes, open telemetry is used. Taking the above solutions as an example, the context information passed between microservices includes at least the information shown in Table 1.

[0043] Table 1

[0044]

[0045] As shown in Table 1, the trace ID is represented in 32-bit hexadecimal format, and the span ID is represented in 16-bit hexadecimal format.

[0046] As shown in Table 1, the context information can reach 120 characters, approximately 150 bytes, which is quite lengthy. Furthermore, the parameters carried in the baggage field require multiple layers of parsing and validation. Therefore, transmitting this context information between microservices consumes significant communication resources, resulting in high system load (such as central processing unit (CPU) and memory load).

[0047] Based on this, the context information processing method provided in this embodiment carries first context information in the first processing request generated by the first microservice. The first context information is obtained by the first microservice compressing the second context information, which consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields, using a preset encoding format. Since the compression process reduces the size of the first context information, the communication load of the first context information during transmission is reduced, the consumption of communication resources is reduced, the communication efficiency is improved, and the system load is reduced during the process of the first microservice sending the first processing request to the third microservice.

[0048] In addition, the current context information is automatically generated and injected by components such as the Software Development Kit (SDK), Agent, Sampler, and Collector modules deployed in the microservices. The SDK is a set of tools provided to developers for developing specific software applications, frameworks, or platforms. In tracing scenarios, the SDK typically includes a series of APIs and libraries for generating, manipulating, and transmitting tracing data.

[0049] An Agent is a program that runs independently on the host machine where the application resides. Its main function is to collect the tracing data generated by the application, perform preliminary processing on the tracing data, and then send it to the link tracing system.

[0050] The sampler controls the frequency of data collection for tracking. Based on a preset sampling strategy, the sampler determines whether to track a particular request. This aims to reduce data volume and lower system overhead while ensuring the validity of the tracking data through a reasonable sampling strategy.

[0051] The Collector module is the data collection center, responsible for receiving tracking data sent from Agent or other data sources, and storing, aggregating and analyzing this data.

[0052] However, the aforementioned components have high startup and maintenance costs, making them unsuitable for microservices in low-memory and low-computation scenarios. Therefore, the context information processing method provided in this embodiment achieves automatic injection and propagation of the first context information through a preset plugin and a target cache. Compared to current technologies, the automatic injection and propagation process in this embodiment uses a preset plugin that supports hot-swappable deployment. Since this preset plugin only requires configuration without modifying the business code, its startup and maintenance costs are reduced. Therefore, the design of the preset plugin is more suitable for microservices in low-memory and low-computation scenarios.

[0053] Currently, when microservices execute requests for user business logic, they associate the logs generated during request processing with all context information corresponding to the current microservice. This association method results in log redundancy, causing performance degradation.

[0054] Based on this, the context information processing method provided in this embodiment only associates all context information (i.e., third context information) of the microservice with the log when the preset abnormal conditions are met. This method not only avoids log redundancy and reduces performance loss, but also facilitates automatic backtracking of abnormal links and improves fault diagnosis efficiency.

[0055] Furthermore, since context information cannot be propagated across threads, the propagation mechanism of context information based on the current thread variable fails when microservices execute asynchronous tasks, which can easily lead to the loss of context information.

[0056] Based on this, the context information processing method provided in this embodiment encapsulates the fourth context information in an asynchronous task, which can solve the problem of easy loss of context information and realize the transmission of the fourth context information in asynchronous scenarios.

[0057] This embodiment provides a context information processing method applied to microservice nodes. Figure 1 This is a flowchart of a context information processing method according to an embodiment of the present invention, such as... Figure 1 As shown, the process includes the following steps:

[0058] S101, the first microservice generates the first processing request for the user's business.

[0059] Here, the first microservice refers to any microservice node in the request chain corresponding to a user request, excluding the last microservice node. For example, the first microservice can be the first microservice node in the request chain, or it can be any other intermediate microservice node.

[0060] The first processing request is a call request to the second microservice generated by the first microservice after it finishes processing the user service.

[0061] The first processing request carries first context information, which is obtained by compressing second context information using a preset encoding format. The second context information consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields. The parent span identifier is the identifier corresponding to the second microservice that called the first microservice, and the current span identifier is the identifier corresponding to the first microservice. For example, the trace identifier could be traceID, the parent span identifier could be parent spanID, and the current span identifier could be spanID.

[0062] In some examples, the default encoding format is base62. Base62 encoding converts binary or integer data into a printable short string consisting of [0-9][AZ][az]. Base62 encoding has advantages such as low parsing cost, low network load, fixed format, and ease of high-speed processing. It can also improve compatibility in scenarios such as HTTP headers, message attributes, and URL parameters.

[0063] For example, the following example shows the first context information obtained by compressing the second context information using base62 encoding: "3FD4A23E9B1A3C1F0012ABCD9002". This first context information includes all the fields in the second context information.

[0064] In other examples, the default encoding format can also be JSON (JavaScript Object Notation). JSON encoding represents context fields in a structured text format, making it suitable for debugging scenarios and systems with high compatibility requirements.

[0065] For example, the following example shows the first context information obtained by compressing the second context information using JSON encoding:

[0066] {

[0067] "traceId": "3fd4a23e9b1a3c1f",

[0068] "spanId": "0012abcd",

[0069] "serviceId": "svc123",

[0070] }

[0071] In some other examples, the default encoding format can also be protocol buffers encoding. Protocol buffers encoding is a binary structure serialization format with high compression ratio and cross-language support, making it suitable for use in performance-sensitive scenarios.

[0072] Optional fields in the second context information include, but are not limited to, tag digest, service name, log file path index, and creation timestamp.

[0073] Optionally, the first request to be processed can be an HTTP request, a gRPC request, or an MQ message, etc.

[0074] S102, the first microservice sends the first processing request to the third microservice.

[0075] based on Figure 1 The technical solution shown carries first context information in the first processing request generated by the first microservice. The first context information is obtained by the first microservice compressing the second context information, which consists of trace identifier, parent span identifier, current span identifier, and optional fields, using a preset encoding format. Since the compression process reduces the size of the first context information, the communication load of the first context information during transmission is reduced, communication efficiency is improved, and system load is reduced during the process of the first microservice sending the first processing request to the third microservice.

[0076] In some embodiments, to further reduce the communication load of the first context information during transmission, the total length of the second context information can be controlled to be less than or equal to 28 bytes.

[0077] For example, Table 2 shows the second context information, which has a total length of 28 bytes.

[0078] Table 2

[0079]

[0080] It should be noted that the number of bytes set for each field in Table 2 is for illustrative purposes only. In actual application scenarios, developers can set the number of bytes according to their actual needs.

[0081] After compressing the 28-byte second context information using base62 encoding, the resulting first context information is approximately 38 characters long.

[0082] In this embodiment, based on controlling the total length of the second context information, the second context information is further compressed using a preset encoding format, which further reduces the size of the first context information and also further reduces the communication load of the first context information during transmission.

[0083] The following will explain the specific implementation method of the first microservice generating the first processing request for user business.

[0084] In some embodiments, the first microservice obtains the second context information from the target cache corresponding to the first microservice through a preset plugin, compresses the second context information using a preset encoding format to obtain the first context information, and injects the first context information into the first processing request through the preset plugin.

[0085] The target cache corresponding to the first microservice is the space used to store the context information of the first microservice. For example, in this embodiment, the target cache can be a thread-local variable (threadlocal) or an asynchronous lock-free queue (concurrently linked queue).

[0086] The preset plugins are integrated into the microservices to enable automatic injection and propagation of context information. Optionally, the preset plugins can be implemented via files or other means, independent of the business logic code.

[0087] This embodiment achieves automatic injection and propagation of first context information through a preset plugin and target cache. Compared with the current technology, the automatic injection and propagation process in this embodiment is implemented by a preset plugin that supports hot-swappable deployment. Since the preset plugin only needs to be configured without modifying the business code, its startup and maintenance costs are reduced. Therefore, the design of the preset plugin is more suitable for microservices in low memory and low computing scenarios.

[0088] The source of context information in the target cache will be explained below.

[0089] When the first microservice receives a user request, it reads the information in the request header using a pre-defined plugin. It's important to clarify that a user request is one triggered by the user through a client application or by calling an application interface. This user request covers processing requests for at least one user business function, and each user business function corresponds to a microservice.

[0090] For example, when the request header of the user request does not contain context information, the first microservice is determined to be the first node in the request chain corresponding to the user request. At this time, the first microservice generates a unique trace identifier (traceID), a span identifier (spanID) corresponding to the first microservice, and timing information (such as start time and duration; the start time is the moment the first microservice begins processing the user request, the duration is the time between the start and end times, and the end time is the moment the first microservice finishes processing its corresponding user business request). After obtaining the traceID, spanID, and timing information, the traceID, spanID, and timing information, along with optional fields from the user request header, are stored in the target cache.

[0091] For example, when context information exists in the request header of a user request, the first microservice is identified as an intermediate node in the request chain corresponding to the user request. At this time, the first microservice obtains the context information from the request header through a pre-defined plugin. Simultaneously, the first microservice generates its own spanID and timing information by calling the tracing component in the tracing system, and establishes a parent-child relationship between the spanID of the first microservice and the spanID of the previous microservice. Finally, the obtained context information, the generated spanID, the timing information, and the established parent-child relationship are written to the target cache. The parent-child relationship between the spanID of the first microservice and the spanID of the previous microservice is established by using the spanID of the previous microservice as the parent span identifier, i.e., parentspanID.

[0092] It is understood that the context information written to the target cache in the above manner is complete context information. However, in this embodiment, the second context information is a part of the complete context information. During the process of the first microservice generating the first processing request, the first microservice extracts the second context information from its corresponding target cache through a preset plugin, and after compressing the second context information, automatically injects the compressed first context information into the first processing request.

[0093] Optionally, the first microservice can periodically clean up the thread-local variable `threadlocal` or the context information in the asynchronous lock-free queue according to the Time to Live (TTL) mechanism to avoid information leakage.

[0094] Optionally, the default plugin can be an interceptor or a middleware gateway. The interceptor or middleware gateway will vary depending on the scenario.

[0095] For example, in the Spring framework, interceptors can be client-side HTTP request interceptors such as ClientHttpRequestInterceptor and Feign plugins.

[0096] For example, in a gRPC scenario, interceptors can be client-side interceptors such as ClientInterceptor and server-side interceptors such as ServerInterceptor.

[0097] For example, in other scenarios, interceptors can also be custom filters and handler interceptors, etc.

[0098] For example, the middleware gateway can be the Kong plugin.

[0099] For example, when the first request to be processed is an HTTP request, the first microservice automatically injects the first context information into the HTTP request header (i.e., the HTTP header) through a preset plugin (such as the ClientHttpRequestInterceptor or the Feign plugin).

[0100] For another example, when the first processing request is a gRPC request, the first microservice automatically injects the first context information into the key-value pair set (i.e., gRPC Metadata) in the gRPC request for passing additional information through a preset plugin (such as a client interceptor or a server interceptor).

[0101] For example, when the first processing request is an MQ message, the first microservice automatically injects the first context information into the message attributes of the MQ message through a preset plugin.

[0102] In some embodiments, to address the issue of log redundancy, during the business processing of the first microservice, generally only the first context information is associated with the logs by default. Only when a preset exception condition is met is the third context information retrieved from the target cache corresponding to the first microservice; the third context information is then associated with the logs of the first microservice. In other words, if the preset exception condition is not met, only the first context information can be associated with the logs.

[0103] The first context information is a portion of the third context information. Optionally, the third context information can be the complete context information corresponding to the first microservice.

[0104] The preset exception conditions are defined by the developers themselves based on the actual situation.

[0105] The logs of the first microservice are the logs generated by the first microservice during the process of executing processing requests for user business (hereinafter referred to as the business processing process).

[0106] Specifically, during the business processing of the first microservice, the Mapped Diagnostic Context (MDC) mechanism is used to associate the first context information with the logs of the first microservice. When an event that meets the preset exception conditions occurs, the first microservice retrieves the third context information from its corresponding target cache and associates the third context information with the logs of the first microservice.

[0107] For example, the way to associate the third context information with the logs of the first microservice can be to inject the third context information into the log MDC, or to write the third context information into the structured log TraceStore.

[0108] In this embodiment, the complete context information (i.e., third context information) in the target cache is associated with the log only when the preset abnormal conditions are met. This method avoids log redundancy and performance bottlenecks, facilitates automatic backtracking of abnormal links, and improves the efficiency of fault diagnosis.

[0109] In some embodiments, the preset exception conditions include at least one of the following: the HTTP interface path provided by the first microservice for the user's business belongs to the preset whitelist; the response status code is abnormal; or an uncaught exception or error-level log is detected.

[0110] For example, the default whitelist can be all HTTP interface paths that begin with / api / pay / .

[0111] For example, the exception status code can be HTTP 5xx, such as HTTP 500 or HTTP 502.

[0112] Examples include uncaught exceptions such as NullPointerException and TimeoutException.

[0113] For example, the logs at the error level, such as the logs corresponding to error_level=true.

[0114] For example, after associating the third context information with the log, the following log information is obtained:

[0115]

[0116]

[0117] The log information, after associating the third context information with the logs, includes: the third context information and log information when a preset exception condition occurs. The third context information includes the trace identifier (trace_id), the current span identifier (span_id), the name of the microservice (service) processing the user's business request, the port (endpoint) on which the microservice receives the processing request, the parameter information (params) of the user's business request, and the time (timestamp) when the microservice starts processing the user's business request. The log information includes the error type (error_type) and the error message (error_message).

[0118] Optionally, the preset exception conditions may also include the occurrence of a user-defined business exception code. For example, the business exception code may be code="BIZ_FAIL".

[0119] Optionally, after the first microservice finishes its corresponding business processing operation, it can encapsulate the third context information and push it to the tracing system so that the tracing system can construct the request chain based on the third context information pushed by each microservice and generate an inter-service call tree.

[0120] In some embodiments, before the first microservice generates a first processing request for the user's business, when there is an asynchronous task in the first microservice, the first microservice may run a first thread and a second thread. Specifically, the first thread retrieves fourth context information from a first cache; the first thread encapsulates the fourth context information and the first task into a second task; the second thread retrieves the fourth context information from the second task and stores the fourth context information in a second cache.

[0121] In this context, the first thread corresponds to the first cache, and the second thread corresponds to the second cache. The first and second caches serve the same purpose as the aforementioned target cache, and will not be elaborated upon further here.

[0122] The fourth context information includes the trace identifier and the current span identifier. Optionally, the fourth context information may also include other fields. Therefore, the fourth context information can be part or all of the third context information.

[0123] The first task is the task to be executed by the second thread to process user business. It can be understood as the asynchronous task to be executed.

[0124] Specifically, when there is an asynchronous task to be executed in the first microservice (i.e., the first task), the first microservice extracts the fourth context information from the first cache through a preset plugin, and encapsulates the fourth context information with the first task to obtain the encapsulated task, i.e., the second task. When it is determined that the second thread is enabled to run the second task, and the second thread is running the second task, the preset component is automatically triggered to obtain the fourth context information from the second task and send the fourth context information to the second cache corresponding to the second thread.

[0125] This embodiment solves the problem of easy loss of context information by encapsulating the fourth context information in an asynchronous task, and realizes the transmission of the fourth context information in asynchronous scenarios.

[0126] Optionally, the encapsulated second task can be directly sent to the thread pool.

[0127] Optionally, the encapsulated second task described above can be written to a message queue in Kafka or Rocket.

[0128] For example, if the first task is a Runnable or Callable, the fourth context is encapsulated with the first task to obtain a TraceRunnable or TraceCallable, and the encapsulated TraceRunnable or TraceCallable is sent to the thread pool. Before the second thread is started to run the second task, a preset component in the tracing system, such as a Hook, is automatically triggered to extract the fourth context information from the second task and store it in the second cache.

[0129] The following describes a specific embodiment of this application.

[0130] like Figure 2 As shown, in response to a user request generated through interaction with the client, or in response to a user request generated by calling a specific application interface, microservice A reads optional fields from the request header of the user request through a pre-defined plugin. Simultaneously, microservice A calls the tracing component in the distributed tracing system to generate a traceID corresponding to the user request, a spanID corresponding to microservice A, and timing information corresponding to microservice A. Microservice A then writes the optional fields obtained from the request header through the pre-defined plugin, the traceID generated by the tracing component, the spanID corresponding to microservice A, and the timing information corresponding to microservice A as context information into its target cache.

[0131] After microservice A finishes its business processing, it retrieves the traceID, spanID, and optional fields from the target cache using a pre-defined plugin. The aforementioned context information is then compressed using a pre-defined encoding method to obtain compressed context information. This compressed context information is then injected into the call request to microservice B (i.e., the first processing request) via the pre-defined plugin.

[0132] The default plugin for microservice B retrieves context information from the request header of the first processing request, namely the traceID, the spanID corresponding to microservice A, and optional fields. Simultaneously, microservice B invokes the tracing component in the distributed tracing system to generate its own spanID and timing information, establishing a parent-child relationship between the spanIDs of microservice A and microservice B, using the spanID of microservice A as the parentspanID. Then, microservice B writes the traceID, parentspanID, spanID, timing information, and optional fields together into its target cache.

[0133] During business processing, microservice B uses log MDC to associate traceID, parentspanID, the spanID corresponding to microservice B, and optional fields with the logs. When an event that meets preset exception conditions occurs, complete context information is read from the target cache corresponding to microservice B, and this complete context information is associated with the logs of microservice B.

[0134] When an asynchronous task exists in microservice B, a first thread and a second thread run within microservice B. The first thread retrieves the traceID and the corresponding spanID of microservice B from the target cache of microservice B, encapsulates the traceID and spanID into the asynchronous task, and sends the encapsulated asynchronous task as a Kafka message queue. When the second thread is enabled to execute the encapsulated asynchronous task, a preset component in the tracing system is automatically triggered to extract the traceID and the corresponding spanID of microservice B from the message header of the Kafka message corresponding to the asynchronous task, and sends the extracted traceID and spanID to the target cache of the second thread.

[0135] After microservice B finishes its business processing, it retrieves the traceID, parentspanID, spanID corresponding to microservice B, and optional fields from the target cache using a pre-defined plugin. It then compresses these data using a pre-defined encoding method to obtain compressed context information. This compressed context information is then injected into the call request to microservice C via the same pre-defined plugin, allowing microservice C to continue its business processing.

[0136] This embodiment also provides a context information processing device for implementing the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0137] This embodiment provides a context information processing device, such as... Figure 3 As shown, it includes:

[0138] Generation module 301 is used by the first microservice to generate the first processing request for the user's business.

[0139] The first processing request carries first context information, which is obtained by compressing second context information using a preset encoding format.

[0140] The second context information consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields; wherein, the parent span identifier is the identifier corresponding to the second microservice that calls the first microservice, and the current span identifier is the identifier corresponding to the first microservice;

[0141] The sending module 302 is used to send the first processing request from the first microservice to the third microservice.

[0142] In some optional embodiments, the total length of the second context information is less than or equal to 28 bytes.

[0143] In some optional embodiments, the generation module 301 includes:

[0144] The `get` submodule is used by the first microservice to obtain the second context information from the target cache corresponding to the first microservice through a preset plugin; the `inject` submodule is used by the first microservice to inject the first context information into the first processing request through a preset plugin.

[0145] In some optional embodiments, the default plugin can be an interceptor or a middleware gateway; wherein the interceptor is one of the following: ClientHttpRequestInterceptor, Feign plugin, Filter, HandlerInterceptor, ClientInterceptor, ServerInterceptor; or, the middleware gateway is the Kong plugin.

[0146] In some alternative embodiments, the apparatus further includes:

[0147] The first acquisition module is used to acquire third context information from the target cache corresponding to the first microservice before the first microservice generates the first processing request for the user business, under the condition of meeting the preset exception conditions. The first context information is a part of the context information in the third context information. The association module is used to associate the third context information with the logs of the first microservice.

[0148] In some optional embodiments, the preset abnormal conditions include at least one of the following:

[0149] The first microservice provides an HTTP interface path to the user's business that is on a pre-defined whitelist; the response status code is abnormal; and uncaught exceptions or errors at the error level are detected in the logs.

[0150] In some optional embodiments, the first microservice runs a first thread and a second thread, wherein the first thread corresponds to a first cache and the second thread corresponds to a second cache; the apparatus further includes:

[0151] The second acquisition module is used to acquire fourth context information from the first cache before the first microservice generates the first processing request for the user business. The fourth context information includes a trace identifier and a current span identifier. The encapsulation module is used to encapsulate the fourth context information and the first task into a second task. The first task is a task to be executed by the second thread to process the user business. The storage module is used to acquire the fourth context information from the second task and store the fourth context information in the second cache.

[0152] Further functional descriptions of the above modules and units are the same as those in the corresponding embodiments described above, and will not be repeated here.

[0153] In this embodiment, a context information processing device is presented in the form of a functional unit. Here, a unit refers to an ASIC (Application Specific Integrated Circuit) circuit, a processor and memory that execute one or more software or fixed programs, and / or other devices that can provide the above-mentioned functions.

[0154] This invention also provides a computer device having the above-described features. Figure 3 The example shown is a context information processing device.

[0155] Please see Figure 4 , Figure 4 This is a schematic diagram of the structure of a computer device provided in an optional embodiment of the present invention, such as... Figure 4 As shown, the computer device includes one or more processors 401, memory 402, and interfaces for connecting the components, including high-speed interfaces and low-speed interfaces. The components communicate with each other via different buses and can be mounted on a common motherboard or otherwise installed as needed. The processors can process instructions executed within the computer device, including instructions stored in or on memory to display graphical information of a GUI on external input / output devices (such as display devices coupled to the interfaces). In some alternative implementations, multiple processors and / or multiple buses can be used with multiple memories and multiple memory modules, if desired. Similarly, multiple computer devices can be connected, each providing some of the necessary operations (e.g., as a server array, a group of blade servers, or a multiprocessor system). Figure 4 Take a processor 401 as an example.

[0156] Processor 401 may be a central processing unit, a network processor, or a combination thereof. Processor 401 may further include a hardware chip. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The programmable logic device may be a complex programmable logic device (CAMP), a field-programmable gate array (FPGA), a general-purpose array logic (GDA), or any combination thereof.

[0157] The memory 402 stores instructions executable by at least one processor 401 to cause the at least one processor 401 to perform the method shown in the above embodiments.

[0158] Memory 402 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 computer device. Furthermore, memory 402 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some alternative embodiments, memory 402 may optionally include memory remotely located relative to processor 401, and this remote memory may be connected to the computer device via a network. Examples of such networks include, but are not limited to, the Internet, intranets, local area networks, mobile communication networks, and combinations thereof.

[0159] Memory 402 may include volatile memory, such as random access memory; memory may also include non-volatile memory, such as flash memory, hard disk or solid-state drive; memory 402 may also include combinations of the above types of memory.

[0160] The computer device also includes a communication interface 403 for communicating with other devices or communication networks.

[0161] This invention also provides a computer-readable storage medium. The methods described above according to embodiments of the invention can be implemented in hardware or firmware, or implemented as computer code that can be recorded on a storage medium, or implemented as computer code downloaded via a network and originally stored on a remote storage medium or a non-transitory machine-readable storage medium and then stored on a local storage medium. Thus, the methods described herein can be processed by software stored on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. The storage medium can be a magnetic disk, optical disk, read-only memory, random access memory, flash memory, hard disk, or solid-state drive, etc.; further, the storage medium can also include combinations of the above types of memory. It is understood that computers, processors, microprocessor controllers, or programmable hardware include storage components capable of storing or receiving software or computer code, which, when accessed and executed by the computer, processor, or hardware, implements the methods shown in the above embodiments.

[0162] In addition to the computer devices and computer-readable storage media described above, embodiments of this application may also be computer program products, which include computer program instructions that, when executed by a processor, cause the processor to perform the steps of the sound source localization method provided in any embodiment of this application.

[0163] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of the embodiments of this application. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on the user's computing device, partially on the user's computing device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0164] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0165] The above description is merely a specific embodiment of this application, enabling those skilled in the art to understand or implement this application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of this application. Therefore, this application is not to be limited to the embodiments described herein, but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. A method for processing contextual information, characterized in that, The method includes: The first microservice generates the first processing request for the user's business; The first processing request carries first context information, which is obtained by compressing second context information using a preset encoding format. The second context information consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields; wherein, the parent span identifier is the identifier corresponding to the second microservice that calls the first microservice, and the current span identifier is the identifier corresponding to the first microservice; The first microservice sends the first processing request to the third microservice.

2. The method according to claim 1, characterized in that, The total length of the second context information is less than or equal to 28 bytes.

3. The method according to claim 1 or 2, characterized in that, The first microservice generates a first processing request for the user's business, including: the first microservice obtains the second context information from the target cache corresponding to the first microservice through a preset plugin; The first microservice injects the first context information into the first processing request through the preset plugin.

4. The method according to claim 3, characterized in that, The preset plugin can be an interceptor or a middleware gateway; The interceptor can be one of the following: ClientHttpRequestInterceptor, Feign plugin, Filter, HandlerInterceptor, ClientInterceptor, or ServerInterceptor. Alternatively, the middleware gateway may be a Kong plugin.

5. The method according to claim 1 or 2, characterized in that, Before the first microservice generates the first processing request for the user's business, the method further includes: Under the condition of meeting the preset exception, the third context information is obtained from the target cache corresponding to the first microservice, and the first context information is a part of the context information in the third context information. Associate the third context information with the logs of the first microservice.

6. The method according to claim 5, characterized in that, The preset abnormal conditions include at least one of the following: The HTTP interface path provided by the first microservice for the user service belongs to a preset whitelist; The response status code is incorrect; Uncaptured exceptions or errors at the error level were detected in the logs.

7. The method according to claim 1 or 2, characterized in that, The first microservice runs with a first thread and a second thread, wherein the first thread corresponds to a first cache and the second thread corresponds to a second cache; before the first microservice generates a first processing request for the user's business, the method further includes: The first thread retrieves fourth context information from the first cache, the fourth context information including the trace identifier and the current span identifier; The first thread encapsulates the fourth context information and the first task into a second task, whereby the first task is a task to be executed by the second thread for processing the user service. The second thread obtains the fourth context information from the second task and stores the fourth context information in the second cache.

8. A context information processing device, characterized in that, The device includes: The generation module is used by the first microservice to generate the first processing request for the user's business. The first processing request carries first context information, which is obtained by compressing second context information using a preset encoding format. The second context information consists of a trace identifier, a parent span identifier, a current span identifier, and optional fields; wherein, the parent span identifier is the identifier corresponding to the second microservice that calls the first microservice, and the current span identifier is the identifier corresponding to the first microservice; The sending module is used for the first microservice to send the first processing request to the third microservice.

9. A computer device, characterized in that, include: A memory and a processor are communicatively connected, the memory stores computer instructions, and the processor executes the context information processing method according to any one of claims 1 to 7 by executing the computer instructions.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the context information processing method according to any one of claims 1 to 7.

Images