Service state detection method and apparatus

Abstract

The application discloses a service state detection method and device. The method is applied to a service state detection node, the service state detection node is located in a preset network architecture, the preset network architecture further comprises a plurality of service nodes, and the method comprises the following steps: acquiring node tracking data in a processing process of a service request, the node tracking data being generated by the service nodes in the process of processing the service request, the node tracking data comprising tracking information of the service request, the tracking information being transmitted and updated between the service nodes along with the processing process of the service request, and the tracking information comprising a service request identifier, a service identifier, a tracking identifier and a link depth serial number; and determining the state of the service nodes according to the node tracking data. According to the embodiment of the application, the state of the service can be detected with high real-time performance and low resource occupation.

Description

Technical Field

[0001] This application belongs to the field of automotive electronics technology, and in particular relates to a service status detection method and device. Background Technology

[0002] As automotive electronics and electrical architecture evolves towards Service-Oriented Architecture (SOA), vehicle functions are broken down into numerous distributed services, enabling flexible combination and reuse of functions. Under SOA, complex and dynamic call relationships exist between services. Accurate and real-time monitoring of the status of each service and the entire call chain is crucial for ensuring the reliability and stability of automotive system functions.

[0003] Currently, common methods for state detection of SOA services rely on distributed tracing technology, which reconstructs call paths and analyzes service status by generating and transmitting global tracing identifiers. However, when applied to the automotive environment, the high frequency of SOA service calls and the highly limited resources of in-vehicle embedded systems, coupled with the fact that existing tracing identifiers are mostly strings or complex object structures, introduce significant additional communication load and processing latency during frequent cross-process and cross-controller calls. This severely impacts the real-time performance and feasibility of state detection, causing the detected service status to be out of sync with the actual system status, making it difficult to capture transient anomalies. Excessive resource consumption may also interfere with the normal execution of the service's core functions.

[0004] In summary, current methods for state detection of automotive SOA services suffer from high resource consumption and poor real-time performance. Summary of the Invention

[0005] This application provides a service status detection method, apparatus, device, computer-readable storage medium, and program product, which can detect the status of services with high real-time performance and low resource consumption.

[0006] On one hand, embodiments of this application provide a service status detection method, the method being applied to a service status detection node, the service status detection node being located in a preset network architecture, the preset network architecture further including multiple service nodes, the method comprising: Obtain node tracking data during the processing of a business request. The node tracking data is generated by the service node during the processing of the business request. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between the service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number. The status of the service node is determined based on the node tracking data.

[0007] On the other hand, embodiments of this application provide a service status detection method, the method being applied to a service node located in a preset network architecture, the preset network architecture further including a service status detection node, the method comprising: During the processing of a business request, node tracking data is generated for the business request during the processing process. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number.

[0008] In another aspect, embodiments of this application provide a service status detection device. The device is applied to a service status detection node located in a preset network architecture, which further includes multiple service nodes. The device comprises: The acquisition module is used to acquire node tracking data during the processing of a business request. The node tracking data is generated by the service node during the processing of the business request. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between the service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number. The determination module is used to determine the status of the service node based on the node tracking data.

[0009] In another aspect, embodiments of this application provide an electronic device, including: a processor and a memory communicatively connected to the processor, the memory storing computer execution instructions, and the processor executing the computer program instructions stored in the memory to implement any of the service status detection methods described in this application.

[0010] In another aspect, embodiments of this application provide a computer-readable storage medium storing computer program instructions, which, when executed by a processor, implement any one of the service status detection methods described in this application.

[0011] In another aspect, embodiments of this application provide a computer program product, including a computer program, which, when executed by a processor, implements any one of the service status detection methods.

[0012] The service status detection method, apparatus, device, and computer-readable storage medium of this application embodiment acquire node tracking data during the processing of a service request. Since the node tracking data is generated by the service node during the processing of the service request, it includes tracking information of the service request. The tracking information is transmitted and updated between service nodes during the processing of the service request, including a service request identifier, a service identifier, a tracking identifier, and a link depth sequence number. Therefore, the communication load required for the transmission of tracking information between services is low, and the computing resources consumed in updating the tracking information are small. The node tracking data can be generated and acquired in real time. The node tracking data can be associated with service calls during the processing of the service request through the request identifier and the service identifier. Therefore, the status of the service node can be determined based on the node tracking data, enabling the detection of service status with high real-time performance and low resource consumption. Attached Figure Description

[0013] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0014] Figure 1 A schematic diagram of the network architecture of a service status detection method provided in one embodiment of this application; Figure 2 A flowchart illustrating a service status detection method provided in one embodiment of this application; Figure 3 This is a schematic diagram of the structure of tracking information provided in one embodiment of this application; Figure 4 An example diagram illustrating the transmission and updating of tracking information provided in one embodiment of this application; Figure 5 This is a schematic diagram of the structure of node tracking data provided in one embodiment of this application; Figure 6 This is a schematic diagram of node tracking data grouped and sorted within each group, as shown in one embodiment of this application. Figure 7 This is a schematic diagram of the structure of a service invocation node provided in one embodiment of this application; Figure 8 A schematic diagram of a service invocation node for a business request provided in one embodiment of this application; Figure 9 A schematic diagram of a service call chain for a business request provided in one embodiment of this application; Figure 10 This is a schematic diagram of a preset network architecture in one embodiment of this application; Figure 11This is a schematic diagram illustrating the processing flow of tracking information by the node tracking data collection node in this embodiment of the application; Figure 12 For this application Figure 10 The following is a sequence diagram of the call timing of each node in the preset network architecture; Figure 13 This is a schematic diagram of the service status detection device provided in the embodiments of this application; Figure 14 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0015] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0016] 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..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0017] The background technology involved in this application is described below.

[0018] As automotive electronics and electrical architecture evolves towards Service-Oriented Architecture (SOA), vehicle functions are broken down into numerous distributed services, enabling flexible combination and reuse of functions. Under SOA, complex and dynamic call relationships exist between services. Accurate and real-time monitoring of the status of each service and the entire call chain is crucial for ensuring the reliability and stability of automotive system functions.

[0019] Currently, common methods for state detection of SOA services rely on distributed tracing technology, which reconstructs call paths and analyzes service status by generating and transmitting global tracing identifiers. However, when applied to the automotive environment, the high frequency of SOA service calls and the highly limited resources of in-vehicle embedded systems, coupled with the fact that existing tracing identifiers are mostly strings or complex object structures, introduce significant additional communication load and processing latency during frequent cross-process and cross-controller calls. This severely impacts the real-time performance and feasibility of state detection, causing the detected service status to be out of sync with the actual system status, making it difficult to capture transient anomalies. Excessive resource consumption may also interfere with the normal execution of the service's core functions.

[0020] In summary, current methods for state detection of automotive SOA services suffer from high resource consumption and poor real-time performance.

[0021] To address the problems of the prior art, embodiments of this application provide a service status detection method, apparatus, device, computer-readable storage medium, and computer program product. The network architecture involved in the service status detection method provided in this application embodiment is described below.

[0022] Figure 1 This is a schematic diagram of the network architecture of a service status detection method provided in one embodiment of this application. Figure 1 As shown, in one embodiment, the network architecture includes a service status detection node 11 and multiple service nodes 12.

[0023] Multiple service nodes 12 can call each other. During the processing of a business request, service node 12 can generate node tracing data for the business request during the processing based on the tracing information and context call information of the business request. The tracing information is transmitted and updated between service nodes as the business request is processed. The tracing information includes: business request identifier, service identifier, tracing identifier, and link depth sequence number.

[0024] Service status detection node 11 can obtain node tracking data during the processing of business requests and determine the status of service nodes based on the node tracking data.

[0025] The service status detection method provided in the embodiments of this application is described below.

[0026] Figure 2 This is a flowchart illustrating a service status detection method provided in one embodiment of this application. Figure 2 As shown, the service status detection method includes steps 201 to 202.

[0027] Step 201: Obtain node tracing data during the processing of the business request. The node tracing data is generated by the service node during the processing of the business request. The node tracing data includes the tracing information of the business request. The tracing information is transmitted and updated between service nodes as the business request is processed. The tracing information includes: business request identifier, service identifier, tracing identifier, and link depth sequence number.

[0028] Step 202: Determine the status of the service node based on the node tracking data.

[0029] The default network architecture can be a Service-Oriented Architecture (SOA), in which vehicle functions can be broken down into numerous distributed services, such as air conditioning and seat services, and implemented through different distributed service nodes. Service nodes are containers, instances, virtual machines, or physical servers used to provide specific services. Service nodes can be deployed using an SOA architecture.

[0030] A business request is an instruction or event that can trigger one or more service nodes to work together. A business request can be a specific function call, such as a user triggering a rapid cooling mode instruction through the central control screen.

[0031] Trace information, also known as trace code, includes a business request identifier to mark the traced business request and a service identifier to mark the service node currently processing the business request. The link depth sequence number is a monotonically increasing value that increments as the business request travels through the processing chain, recording the level or depth of the service node currently processing the business request within the entire call chain. In some embodiments, the initial value of the link depth sequence number can be 0. Trace information with a link depth sequence number of 0 identifies the service node that initially processed the business request, i.e., the entry point of the service call chain for the business request.

[0032] Because services in an SOA architecture have complex and dynamic call relationships, the node tracking data of a specific business request during its processing can be filtered from multiple node tracking data by using the business request identifier; similarly, the node tracking data of a business request processed by a specific service node can be filtered from multiple node tracking data by using the service identifier.

[0033] In some embodiments, the preset network architecture is an SOA framework, which also includes a tracing information generation node. When a business request reaches the first calling service node A in the SOA framework, the SOA framework can intercept the business request and generate tracing information for the business request by calling the tracing information generation and management code. At this time, the service identifier in the tracing information is the identifier of service node A. When service node A calls service node B, the tracing information is passed from service node A to service node B. When service node B receives the tracing information passed by service node A, it can update the tracing information by calling the tracing information generation and management code, such as updating the identifier of service node A in the tracing information to the identifier of service node B.

[0034] In some embodiments, tracing information can be updated when a tracking event is triggered in a service node. The tracing information also includes a tracking event identifier. The tracking event identifier is used to mark the tracking time in the service node that triggers the tracing information. For example, if tracing information generation and management code is added to key nodes such as "request reception," "processing start," "downstream service call," "processing end," and "response return" in the service, the tracing information generation and management code will generate or update the tracing information when the service node triggers events such as "request reception," "processing start," "downstream service call," "processing end," and "response return."

[0035] The tracking information generation and management code can be implemented using either automatic or manual tracking. Manual tracking can be done statically during the development and coding phase of service nodes to track their call context. For example, a manual tracking method could be: TRACE_CODE(service_location_id), where TRACE_CODE is the tracking identifier, and service_location_id is a custom tracking event identifier. This event identifier is unique within a service but can be repeated across different services. Automatic tracking involves adding the tracking information generation and management code to the SOA service development toolchain during SOA architecture development. This allows the tracking information generation and management code to be automatically added to key nodes of the SOA service during development.

[0036] Figure 3 This is a schematic diagram of the structure of tracking information provided in one embodiment of this application, as shown below. Figure 3 As shown, the tracing information can be an unsigned 64-bit integer, and the tracing information can include: business request identifier, service identifier, tracing identifier, event identifier, and link depth sequence number.

[0037] The business request identifier can occupy 0 to 15 bits, representing the business request associated with the tracking information. In the SOA architecture, the business request identifier of each business request is globally unique.

[0038] The service identifier can occupy 16 to 31 bits, representing the service provider corresponding to the tracing information. In an SOA architecture, each service identifier is globally unique. The tracing identifier can occupy 32 to 47 bits. It can uniquely represent a tracing information, or it can be combined with the business request identifier to uniquely represent a tracing information. The event identifier can occupy 48 to 55 bits, used to indicate the logical location of the event within a service. The link depth sequence number can occupy 56 to 63 bits. The initial sequence number of the business request can be 0, and the value of the link depth sequence number can be incremented by one for each subsequent service.

[0039] The unsigned 64-bit integer structure of the trace information not only ensures the global uniqueness of the trace information but also carries information about the source of the business request and the service path, facilitating subsequent link tracing and analysis. Furthermore, representing the trace information as a 64-bit unsigned integer minimizes the communication load introduced by link tracing, ensuring real-time communication. Moreover, this simple and basic data structure is easily compatible and adaptable to any communication protocol.

[0040] Figure 4 This diagram illustrates the transmission and updating of tracking information according to one embodiment of this application. In one embodiment of this application, in a human-machine interaction scenario on a vehicle's infotainment screen, when a user operates the "rapid cooling mode" via the central control screen, a series of linked controls are triggered. First, the user interaction service parses the rapid cooling mode command, determines that the main service is the air conditioning service, and requests the air conditioning service to activate the rapid cooling mode. After receiving the request, the air conditioning service calls the seat service and requests to activate the seat ventilation at its maximum setting. After completing the operation, the seat service sends a confirmation message to the air conditioning service confirming that the seat ventilation at its maximum setting has been activated. After receiving the response from the seat service, the air conditioning service executes the cooling operation and sends a confirmation message to the user interaction service confirming that all cooling measures have been activated and the current set temperature is 18°C. The user interaction service displays the status of all devices and the current temperature on the central control screen.

[0041] The identifiers for user interaction services are 0xx84A, air conditioning services are 0x0002, and seat services are 0x1A04. The identifiers for automatically event-driven request reception events are 0x00, downstream service call events are 0x02, processing completion events are 0xFF, and response return events are 0x06. The identifier for manually event-driven critical operation events is 0x23.

[0042] like Figure 4As shown, when a user operates the "rapid cooling mode" through the central control screen, the user interaction service receives the business request for the rapid cooling mode, triggers the request receiving event, and calls the trace information generation and management code to generate the trace information of the business request. At this time, the trace information includes: request identifier 0x89AB, service identifier 0x084A, trace identifier 0x403D, event identifier 0x00, and link depth sequence number 0x00.

[0043] When the user interaction service determines that the main service is the air conditioning service and requests the air conditioning service to start the rapid cooling mode, it triggers a downstream service call event, calls the trace information generation and management code to update the trace information of the business request. At this time, the trace information includes: request identifier 0x89AB, service identifier 0x084A, trace identifier 0x403D, event identifier 0x02, and link depth sequence number 0x00.

[0044] When the air conditioning service receives a request from the user interaction service to start the rapid cooling mode, it triggers a request reception event and calls the trace information generation and management code to update the trace information of the business request. At this time, the trace information includes: request identifier 0x89AB, service identifier 0x0002, trace identifier 0x403D, event identifier 0x00, and link depth sequence number 0x01.

[0045] When the air conditioning service processes a request to activate the rapid cooling mode and calls the seat service to request the seat ventilation to be turned on to its maximum setting, a downstream service call event is triggered. This calls the tracing information generation and management code to update the tracing information of the business request. At this time, the tracing information includes: request identifier 0x89AB, service identifier 0x0002, tracing identifier 0x403D, event identifier 0x02, and link depth sequence number 0x01. The link depth sequence number increments by 1 for each cross-service call. For example, from the user interaction service to the air conditioning service, the link depth sequence number is updated from 0x00 to 0x01.

[0046] The tracking information updates for the seat service's processes, including receiving a request to activate the seat ventilation at its maximum setting, completing the processing of the request, and returning a response to the request to activate the seat ventilation at its maximum setting, and the air conditioning service's processes for requests to activate the rapid cooling mode and set the air conditioning temperature to 18℃, can be found in [link to relevant documentation]. Figure 4 The details of the records are omitted here.

[0047] In some embodiments, when a business request begins processing, the service status detection node continuously acquires node tracing data reported by each service node during the processing of the business request, and monitors whether target node tracing data indicating that the business request has completed a complete service call chain has been acquired. If target node tracing data is acquired within a preset continuous monitoring period, it can be determined that the status of all service nodes involved in the service call chain of the business request is normal. If target node tracing data is not acquired within the preset continuous monitoring period, the status of each service node involved in the service call chain of the business request can be determined based on the acquired node tracing data.

[0048] Among them, the target node tracking data is the node tracking data generated when the entry service node of the business request triggers the response return event. That is to say, in the tracking information of the target node tracking data: the request identifier is the business request identifier, the service identifier is the service identifier of the entry service node of the business request, and the event identifier is the response return event.

[0049] If target node tracking data is obtained within the preset continuous monitoring period, the node tracking data of all service nodes involved in the service call chain of the business request can be filtered out by the business request identifier. The service identifier in the node tracking data can be used to determine all service nodes involved in the service call chain of the business request, and then the status of all service nodes involved in the service call chain of the business request can be determined to be normal.

[0050] If no target node tracking data is obtained within the preset continuous monitoring period, the received node tracking data can be filtered out using the business request identifier. Then, based on the service identifier within the node tracking data, all service nodes appearing in the service call chain of the business request can be selected. For each service node appearing in the service call chain of the business request, its status is determined based on the event tracking identifier. For example, it's determined whether the service node simultaneously possesses paired node tracking data for both request reception and response return events. The request reception event can also be any other similar start event, and the response return event can be any other similar end event. If the service node possesses both of these paired node tracking data, its status is determined to be normal; otherwise, its status is determined to be abnormal.

[0051] The service status detection method provided in this application obtains node tracking data during the processing of a business request. Since the node tracking data is generated by the service node during the processing of the business request, it includes tracking information of the business request. The tracking information is transmitted and updated between service nodes during the processing of the business request, including the business request identifier, service identifier, tracking identifier, and link depth sequence number. Therefore, the communication load required when the tracking information is transmitted between services is low, and the computing resources consumed in updating the tracking information are small. The node tracking data can be generated and obtained in real time. The node tracking data can be associated with the service call during the processing of the business request through the request identifier and service identifier. Then, the status of the service node can be determined based on the node tracking data, which can detect the service status with high real-time performance and low resource consumption.

[0052] In some embodiments, in order to accurately determine the status of each service node, node tracking data of the service nodes is collected in real time. Before step 201, the method further includes: Add at least one preset event to the business logic of the service node so that the service node, in response to the triggering of the preset event, performs at least one of the following: transmits and updates tracking information, or generates node tracking data.

[0053] Preset event tracking can include request reception events and response return events, as well as start events, downstream service call events, end events, and key user input events.

[0054] The specific implementation of transmitting and updating tracking information can be found in the descriptions in the above embodiments, and will not be repeated here.

[0055] Figure 5 This is a schematic diagram illustrating the structure of node tracking data provided in one embodiment of this application. Figure 5 As shown, in some embodiments, a service node can generate node tracking data based on tracking information and context call information. The context call information includes the timestamp when the event is triggered and the parent service identifier of the calling service. The service node can sequentially concatenate the tracking information, the timestamp when the event is triggered, and the parent service identifier of the calling service, and determine the concatenated data as node tracking data.

[0056] The service status detection method provided in this application embodiment enables the transmission and updating of tracking information to be automatically completed by the underlying service framework by adding at least one preset event to the business logic of the service node, thereby reducing resource consumption and improving the real-time performance of service status detection.

[0057] In some embodiments, to quickly determine the status of a service node, the tracking information further includes event identifiers, which include request reception event identifiers and response return event identifiers. The processing steps in step 202 may include: Based on node tracking data, determine the event triggering status of the embedded events within the service node; Determine the status of the service node based on the event triggering conditions.

[0058] In one implementation, the node tracking data is aggregated using the request identifier and tracking identifier as a composite primary key, grouping all node tracking data belonging to the same business request into a single set. Then, the node tracking data within each set is grouped according to the service identifier, grouping node tracking data with the same service identifier into the same group. For each group of node tracking data, the event triggering status of the event within the service node can be determined based on the event identifier, such as whether each event is triggered and the number of times each event is triggered.

[0059] In some embodiments, the state of a service node can be determined based on whether and how many times a request receive event and a response return event are triggered within the service node. For example, the state of the service node is determined to be abnormal when a request receive event is triggered but a response return event is not triggered, the state of the service node is determined to be abnormal when a response return event is triggered but a request receive event is not triggered, and the state of the service node is determined to be abnormal when the number of times the request receive event and the response return event are triggered are different.

[0060] The service status detection method provided in this application can quickly determine the event triggering status of embedded events within a service node by determining the event triggering status of embedded events within the service node based on node tracking data, and then quickly determine the status of the service node based on the event triggering status.

[0061] In some embodiments, to determine the state of a service node more quickly, the process of determining the state of a service node based on event triggering may include: If an isolated request receiving event or response returning event is identified, the service node's state is determined to be abnormal.

[0062] An isolated request receive event or response return event refers to a situation where, in the node trace data of a service node, a request receive event has no corresponding response return event, or a response return event has no corresponding request receive event. The occurrence of an isolated request receive event indicates that a service call failed to complete its full lifecycle; therefore, the service node's state can be determined to be abnormal.

[0063] In one implementation, the existence of an isolated request receiving event or response returning event can be determined based on the number of times the request receiving event and response returning event are triggered. For example, if the number of times the request receiving event and response returning event are triggered are different, it can be determined that an isolated request receiving event or response returning event exists.

[0064] The service status detection method provided in this application can quickly and accurately determine the status of a service node through isolated request receiving events or response return events.

[0065] In some embodiments, to more accurately determine the state of a service node, the node tracking data also includes context call information. The context call information includes the trigger time of the event tracking, and the event triggering details include the event triggering order. The process of determining the event triggering details of the event tracking within the service node based on the node tracking data may include: Based on the service identifier, identify the node tracking data belonging to the same service node; The node tracking data belonging to the same service node are sorted by link depth sequence number, and when the link depth sequence numbers are the same, they are sorted by trigger time to obtain the event triggering order; The process of determining the state of a service node based on the event triggering conditions may include: If at least one of the following conditions is met, the service node is determined to be in an abnormal state: the event triggering order is different from the preset order, or the interval between the triggering times of adjacent event points is greater than the preset time interval.

[0066] In a distributed environment, node tracing data from different service nodes is generated and reported in parallel. Therefore, the order in which service status monitoring nodes obtain node tracing data may be disordered and differ from the generation order of the node tracing data during business request processing. Consequently, filtering node tracing data using the request identifier and tracing identifier as a combined primary key can only filter out all node tracing data generated during business request processing, but cannot determine the generation order of the node tracing data. This makes it impossible to reconstruct the service call chain during business request processing and determine the status of service nodes through analysis of the service call chain.

[0067] In one implementation, the node tracing data also includes the trigger time. Since node tracing data is generated when a service node triggers an event, the order of trigger times for node tracing data with the same request identifier and service identifier must be the order in which the node tracing data was generated. Furthermore, because a service may simultaneously call two different downstream services, parallel calls may occur between services. The link depth sequence number indicates the depth of the service node during the business request processing, i.e., which layer the service node is located in the service call chain. Therefore, after aggregating the node tracing data using the request identifier and tracing identifier as a composite primary key, and grouping the node tracing data within the set according to the service identifier, the node tracing data within the same group can be sorted by link depth sequence number as the key, and node tracing data with the same link depth sequence number can be sorted by timestamp to obtain the generation order of the service node's node tracing data. Then, the event triggering order of the event within the service node is determined based on the event identifier in the sorted node tracing data.

[0068] Figure 6 This is a schematic diagram of node tracking data grouped and sorted within each group, as shown in one embodiment of this application. Figure 6 As shown, the node tracing data of the service request is divided into 4 groups according to the service identifiers 0x10, 0x3F, 0x5C and 0x7A. Group 1 contains all node tracing data with service identifier 0x10, Group 2 contains all node tracing data with service identifier 0x3F, Group 3 contains all node tracing data with service identifier 0x5C, and Group 4 contains all node tracing data with service identifier 0x7A. Taking Group 1 as an example, the node tracking data is first sorted by the link depth sequence number. For node tracking data with the same link depth sequence number, it is then sorted by timestamp. The order of the node tracking data is as follows: node tracking data with link depth sequence number 0, timestamp 10, event identifier 0, and parent service identifier -1; node tracking data with link depth sequence number 0, timestamp 11, event identifier 1, and parent service identifier -1; node tracking data with link depth sequence number 0, timestamp 78, event identifier FF, and parent service identifier -1; node tracking data with link depth sequence number 5, timestamp 32, event identifier 0, and parent service identifier 0x5C; and node tracking data with link depth sequence number 5, timestamp 50, event identifier FF, and parent service identifier 0x5C.

[0069] Taking the service node of group 1 as an example, the event triggering order of the event tracking within the service node is: event tracking 0, event tracking 1, event tracking FF, event tracking 0, event tracking FF.

[0070] In one implementation, the service status detection nodes can be pre-configured with a predefined, correct business logic execution order for each service node, i.e., a preset order. The preset order can be configured through a rule configuration file in XML format. For example, for a complete service call, the preset sequence could be: request reception, processing start, downstream service call, processing end, and response return. If the event triggering order of a service node is disordered, such as processing start before request reception, or the response return occurring before the downstream service call, the service node's status can be determined to be abnormal.

[0071] In one implementation, the rule configuration file may also include an ignore flag (such as the ignore field). When the ignore flag is a preset value (such as true), it means that the call chain of the corresponding business request does not need to be health diagnosed, and the service nodes involved in the service call chain of the business request can be directly determined to be in a normal state.

[0072] An interval between the trigger times of adjacent event tracking points exceeding a preset time interval means that the time spent by a service node between two consecutive critical execution steps exceeds the maximum allowed threshold. When the interval between the trigger times of adjacent event tracking points exceeds the preset time interval, it indicates that the service node has a performance bottleneck or is experiencing lag. Specifically, a timeout threshold (such as the `timeout` attribute) can be configured for preset event tracking points in the rule configuration file. When the actual time spent between adjacent preset event tracking points exceeds the timeout threshold, the service node's status is determined to be abnormal.

[0073] In one implementation, the service status detection node can also be configured with a preset time interval for any two adjacent event tracking points of the service node. For example, the preset time interval from the start of processing to the invocation of the downstream service is 50 milliseconds. After determining the event triggering order of the service node, the actual time taken to trigger adjacent event tracking points can be calculated based on the timestamps in the node tracking data. If the calculated actual time taken is greater than the preset time interval, it can be determined that the service node has a performance bottleneck or is experiencing lag, and the service node's status is determined to be abnormal.

[0074] The service status detection method provided in this application determines the event triggering order of the embedded events within the service node based on the service identifier, link depth sequence number, and trigger time. It determines the status of the service node based on the event triggering order and the triggering time interval of adjacent embedded events, thus accurately determining the status of the service node without needing to reconstruct the service call chain of the business request.

[0075] In one implementation, after determining the event triggering order of the service node, the occurrence frequency and pairing of specific types of key events can be calculated. If a request to receive an event occurs, but no response return event occurs in the entire event triggering order, the service status is determined to be abnormal.

[0076] In some embodiments, the tracking information further includes a tracking event identifier, and the node tracking data further includes context invocation information, which includes the trigger time of the tracking event and the parent service identifier of the calling service node. After step 202, the tracking information further includes: Based on the parent service identifier and the link depth sequence number, reconstruct the service call link of the business request; Based on the service call chain and trigger time, determine the performance parameters of the service call chain. The performance parameters include at least one of the following: total chain time, number of service calls, average service response time, and service call frequency.

[0077] In one implementation, firstly, based on the request identifier and trace identifier in the node tracing data, all node tracing data belonging to the same business request are identified. Then, all node tracing data belonging to the same business request are divided into different groups according to different service identifiers. Next, the node tracing data in the same group are sorted by link depth sequence number, and if the link depth sequence numbers are the same, they are sorted by trigger time. Finally, using the service identifier and sequence number as a composite primary key, node aggregation is performed on the sorted node tracing data in the same group, aggregating one service call into one service call node.

[0078] Figure 7 This is a schematic diagram of the structure of a service invocation node provided in one embodiment of this application. Figure 7 As shown, the service call node contains the following fields: service identifier, parent service identifier, and link depth sequence number.

[0079] Finally, using the service identifier, parent service identifier, and link depth sequence number of the service call node as the service call node index, the node tracing data of different groups belonging to the same business request are aggregated to obtain the node aggregation result of the business request. The service call link is then determined based on the node aggregation result.

[0080] Figure 8 A schematic diagram of a service call node for a business request provided in one embodiment of this application, as shown below. Figure 8 As shown, the node aggregation result includes a service call node index and a list of event tracking points. The list of event tracking points is a list of event tracking points triggered by the service node corresponding to the service call node during the processing of business requests.

[0081] Figure 9This is a schematic diagram of a service call chain for a business request provided in one embodiment of this application. Figure 9 As shown, in some embodiments, the service call chain can be reconstructed from the node aggregation results based on the link depth sequence number and the parent service identifier to form a service call chain. Figure 9 The service call chains shown are: {{0x10,0,-1}, [{0,10}, {1,11}, {FF, 78}]}, {{0x3F,1,0x10}, [{0, 15}, {FF, 76}]}, {{0x7A,2,0x3F},[{0, 19}, {FF, 74}]}, {{0x3F,3,0x7A}, [{0, 23}, {FF, 70}]}, {{0x5C,4,0x3F},[{0, 25}, {FF, 66}]}, and the parallel {{0x7A,4,0x3F}, [{0, 26}, {FF, 64}]} and {{0x10,5,0x5C}, [{0, 32}, {FF, 50}]}, where, taking the service call node {{0x10,0,-1}, [{0, 10}, {1,11}, {FF, 78}]} as an example, {{0x10,0,-1} is a set of service node identifier, link depth sequence number and parent service identifier, 0x10 is the service node identifier, 0 is the link depth sequence number, and -1 is the parent service identifier. The link depth sequence number of 0 and the parent service identifier of -1 indicate that service node 0x10 is the entry service for business call requests. [{0, 10},{1,11}, {FF, 78}] indicates that in service node 0x10, the list of event points is {0, 10}, {1,11}, {FF,78}. {0, 10}, {1,11}, {FF, 78} indicates that the triggering order of the event points is 0, 1, FF, and the triggering timestamps are 10, 11, 78. Taking the service calling nodes {{0x3F,1,0x10} and {0,15} as examples, {0x3F,1,0x10} is a set of service node identifier, link depth sequence number and parent service identifier. 0x3F is the service node identifier, 1 is the link depth sequence number, and 0x10 is the parent service identifier. {0x3F,1,0x10} means that the link depth sequence number of service node 0x3F is 1, and it is called by the service node with parent service identifier 0x10.

[0082] The total latency of the service call chain is the total time spent on the business request's service call chain, which can be determined based on the timestamps of the entry service's request reception event and response return event. (As mentioned above...) Figure 9In the corresponding embodiment, 0x10 represents the entry service. If in [{0,10},{1,11},{FF,78}], event 0 is a request to receive event and event FF is a response to return event, then the total link time is the difference between the timestamp 78 of event FF and the timestamp 10 of event 0. If the unit of timestamp is milliseconds, then the total link time is 68 milliseconds.

[0083] The service call count refers to the number of times a service node is called in the service call chain. The service call count of each service node can be directly calculated from the service call chain.

[0084] The average service response time can be the average response time of each service node in multiple calls, or it can be the average response time of all service nodes in the service call chain of the business request during the entire business request processing process. There is no limitation here.

[0085] Service call frequency can be defined as the number of times a service node's service is called within a unit of time or within a single business request.

[0086] The service status detection method provided in this application restores the service call chain of a business request and determines the performance parameters of the service call chain based on the service call chain and the trigger time. It can not only determine the status of the service node, but also determine the performance parameters of the entire service call chain of the business request, and then determine the status parameters of the service node more accurately based on the performance parameters.

[0087] In some embodiments, the event tracking includes request reception events and response return events. The process of determining the performance parameters of the service call chain based on the service call chain and the trigger time may include: Calculate the service response time of the service node based on the trigger time of the request receiving event and its corresponding response return event in the service node; Calculate the average service response time of all service nodes in the service call chain to obtain the average service response time.

[0088] In one implementation, for a service call node that has completed aggregation, the service call node contains all the instrumented events triggered within the service node and their trigger times. Therefore, the timestamps of the request reception event and the response return event can be determined from the instrumented event sequence of the service call node. Since the request reception event represents the start of the service call being processed by the service node, and the response return event represents the completion of the service call being processed by the service node and the service node is ready to return, the service response time of the service node = the trigger time of the response return event - the trigger time of the request reception event.

[0089] In this embodiment, the average response time of a service refers to the average time taken for all service nodes on the chain to respond to the service. After determining the service call chain, a depth-first approach can be used to traverse the service call chain. For each service node in the chain, the service response time is calculated based on the trigger time of the response return event and the trigger time of the request receive event. Then, the sum of the service response times of all service nodes on the chain is calculated, and the sum of the service response times is divided by the total number of service call nodes in the chain. The quotient obtained is the average response time of the service.

[0090] The service status detection method provided in this application can calculate the average response time of a service during the processing of a business request, and then determine whether the status of the service nodes on the link is normal by the trend of the change in the average response time of the service.

[0091] In some embodiments, the service call chain of business requests can be used to identify service dependencies, i.e., the caller-invoker relationship between services, to construct a service dependency graph, mark service dependencies, and identify circular dependencies between services. For services with circular dependencies, the service status can be determined based on the number of cycles. For example, when the number of cycles exceeds a preset number, the service status is determined to be abnormal, thereby accurately identifying situations where a service is online but abnormal.

[0092] In some embodiments, in response to determining that the state of a service node is abnormal, the method further includes: sending the identifier of the service node in the abnormal state to the abnormal service processing module, so that the abnormal service processing module performs at least one of the following actions on the service node in the abnormal state: circuit breaking, restarting, taking it offline, or replacing it with a backup service node.

[0093] This application embodiment also provides a service status detection method, applied to a service node, the service node being located in a preset network architecture, the preset network architecture also including a service status detection node, the method including: during the processing of a service request, generating node tracking data of the service request during the processing process, the node tracking data including tracking information of the service request, the tracking information being transmitted and updated between service nodes as the service request is processed, the tracking information including: service request identifier, service identifier, tracking identifier and link depth sequence number.

[0094] In some embodiments, before generating the business request and processing node tracing data, the method further includes: in response to being invoked, receiving tracing information sent by the parent service node, and updating at least one of the following in the tracing information: service identifier, link depth sequence number.

[0095] In this embodiment, the specific implementation methods and principles for the generation of node tracking data, the transmission and updating of tracking information, etc., can be found in the descriptions in the above embodiments, and will not be repeated here.

[0096] The service status detection method provided in this application generates node tracking data during the processing of business requests by the service node. This enables real-time tracking of business processing requests and allows for rapid determination of the service node's status based on the node tracking data. Furthermore, since the tracking information includes business request identifier, service identifier, tracking identifier, and link depth sequence number, the data volume is small and can be embedded in different communication protocol message packets, ensuring that the tracking information is not lost in complex calling scenarios involving cross-domain and multiple vehicle network protocols.

[0097] Figure 10 This is a schematic diagram of a preset network architecture in one embodiment of this application, such as... Figure 10 As shown, in one embodiment of this application, the preset network architecture 100 includes a tracking information generation and management node 101, a tracking information embedding and transmission node 102, a node tracking data collection node 103, a service call link tracing and analysis node 104, and a service status detection node 105. The tracking information generation and management node 101, the tracking information embedding and transmission node 102, the node tracking data collection node 103, the service call link tracing and analysis node 104, and the service status detection node 105 can communicate with each other.

[0098] The tracking information generation and management node 101 includes a tracking information generator and a tracking identifier rule management module. The tracking information generator is used to generate a globally unique tracking identifier for each business request, and the tracking identifier rule management module is used to configure the rules for generating tracking identifiers.

[0099] The tracing information instrumentation and transmission node 102 includes an automatic instrumentation module and a manual instrumentation module. The tracing information instrumentation and transmission node 102 is used to achieve seamless transmission of tracing information during cross-service calls. For example, the automatic instrumentation module can automatically add context call information, such as the parent service node of the current service call, during cross-service calls. It can also automatically instrument points on the critical paths of each service node to automatically add tracing information generation and update code at key nodes such as "request reception," "processing start," "call downstream service," "processing end," and "response return."

[0100] Node tracking data collection node 103 includes a tracking information collection module and a standardization processing module. The tracking information collection module collects tracking information from each service node in real time, providing data support for subsequent service status monitoring. The standardization processing module standardizes the tracking information collected by the tracking information collection module, removing incomplete or incorrectly formatted data, adding reporting timestamps, service identifiers, and parent service identifiers, and verifying the matching between the service identifiers and the tracking information to form node tracking data. The structure of the node tracking data can be as follows: Figure 5 As shown.

[0101] In some embodiments, the node tracing data collection node 103 can also push node tracing data to the log system according to the tracing level. On the other hand, the node tracing data collection node 103 can also aggregate node tracing data based on the "request ID + Unique ID" as a combined key value, and aggregate all node tracing data belonging to the same user request into a set. After the aggregation is completed, it is reported to the service call link tracing analysis node 104 for further tracing analysis.

[0102] The node tracing data collection node 103 reports node tracing data to the service call link tracing analysis node 104. The reporting timing can include two scenarios: first, reporting immediately upon receiving a complete call link, i.e., tracing information from the response return event of the entry service using the request identifier and tracing identifier as keys; second, if a complete link is not obtained after a preset waiting time, to avoid impacting system memory due to continuous lack of response, the incomplete link information can be reported, and subsequent related tracing information discarded. Furthermore, regardless of the scenario, the node tracing data collection node 103 can perform preliminary aggregation and organization of the tracing information, forming a set of node tracing data for subsequent analysis.

[0103] Figure 11 This is a schematic diagram illustrating the processing flow of tracking information by the node tracking data collection node in an embodiment of this application, as shown below. Figure 11 As shown, the process of node tracking data collection node 103 processing tracking information may include steps 1100 to 1109.

[0104] Step 1100: Wait to receive tracking information.

[0105] Step 1101: Tracking information received.

[0106] Step 1102: Determine whether the link corresponding to the tracking information has been reported. If yes, proceed to step 1109; otherwise, proceed to step 1103.

[0107] Step 1103: Determine if the tracking information is incomplete or formatted incorrectly. If yes, proceed to step 1109; otherwise, proceed to step 1104.

[0108] Step 1104: Add a timestamp and service identifier to the tracking information based on the identifier of the service node that reported the tracking information and the reporting time; add a parent service identifier to the tracking information based on the parent service identifier in the context call information of the service node that reported the tracking information, thus forming node tracking data.

[0109] Step 1105: Determine whether the service identifier of the node tracking data matches the tracking information. If yes, proceed to step 1106; otherwise, proceed to step 1109.

[0110] Step 1106: Determine if the link is complete. If it is, proceed to step 1108; otherwise, proceed to step 1107.

[0111] Step 1107: Confirm whether the timeout has occurred. If yes, proceed to step 1108. If no, continue waiting to receive tracking information.

[0112] Step 1108: Report node tracking data to the service status detection node.

[0113] Step 1109: Discard the tracking information.

[0114] Service call link tracing and analysis node 104 includes a service call link reconstruction and performance analysis module and a service dependency analysis and graph construction module. Since service calls in an SOA architecture may involve parallel or circular operations, the node tracing data reported by node tracing data collection node 103 may be out of order, have the same link depth sequence number but different service identifiers, etc. Based on the node tracing data, service call link tracing and analysis node 104 performs tracing link analysis on the stored node tracing data to reconstruct the complete service call link. The reconstruction process is as follows: Node grouping: Divide trace nodes into several groups according to their service IDs.

[0115] Within a group, nodes are sorted using their sequence number as the first sorting key and the timestamp as the second sorting key. This sorts the trace nodes within each group. Specifically, for trace data with the same sequence number, the timestamp is used for sorting. A screenshot of the grouped sorting can be seen as follows... Figure 6 As shown.

[0116] Node aggregation involves aggregating the grouped and sorted node tracking data. Using the service identifier and link depth sequence number as a composite primary key, a single call to a service is aggregated into a service call node. The service call node structure is as follows: Figure 7As shown, the aggregation results can be as follows: Figure 8 As shown.

[0117] The service call chain reconstruction and performance analysis module is used to reconstruct the service call chain based on the chain sequence number and the parent service identifier, forming the call chain. The reconstruction results can be as follows: Figure 9 As shown.

[0118] The service dependency analysis and graph construction module is used to traverse the call chain using a depth-first strategy after the service call chain is reconstructed. It calculates basic functionalities and performance metrics such as total chain latency, number of service calls, average response time per service, and call frequency. Through long-term collected chain data, it identifies dependencies between services, constructs a service dependency graph, marks dependencies, and identifies circular dependencies. Simultaneously, this module can send the call chain and its basic functionalities and performance metrics to the service status detection node for further service status monitoring.

[0119] Service status detection node 105 can combine service call chains with basic service monitoring metrics to detect the status of services and call chains. Pre-defined basic chain matching rules are used to check whether each service's start anchor point exists and has only one corresponding end anchor point, i.e., to check whether each service call is complete.

[0120] Service status detection node 105 can customize link matching rules through XML-formatted rule configuration files. The rules in the XML configuration file are based on business requests as the basic unit. Each rule unit is divided into specific link matching subsets according to service nodes. These correspond to the service call nodes aggregated by service call link tracing and analysis node 104. When the order of preset event points in the actual call link does not match the configuration, or the time between two preset event points exceeds the threshold, the status of the service node can be determined as abnormal, and alarm information can be output. The rule configuration file can include a whitelist, which can be represented by the ignore field. If the ignore field is marked as true, it means that the call link corresponding to a certain business request is always correct, and there is no need to perform health checks on the business request call.

[0121] Figure 12 For this application Figure 10 The diagram shows the call sequence of each node in the preset network architecture. (See diagram for example.) Figure 12 As shown, in Figure 10Based on the preset network architecture shown, it also includes a client 106 and at least one service node 107. The client 106 initiates a business request and calls the service provided by at least one service node 107 to process the business request. The tracking information transmission and event tracking node 102 performs automatic and / or manual event tracking on the service node 107 so that the service node can transmit and update tracking information. The service node triggers the event tracking time, calls the tracking information generation and management node 102 to generate tracking information, and calls the tracking information transmission and event tracking node 102 to transmit the tracking information during the request processing. The tracking information is reported to the node tracking data collection node 103. The node tracking data collection node 103 processes the tracking information. In the case of link integrity or timeout, the tracking information forms node tracking data and sends it to the service call link tracking analysis node 104. The service call link tracking analysis node 104 reconstructs the service call link based on the node tracking data and sends the service call link to the service status detection node 105. The service status detection node 105 detects the status of the service node based on the service call link and can send the status detection result to the client 106.

[0122] Figure 13 This is a schematic diagram of the service status detection device provided in the embodiments of this application, as shown below. Figure 13 As shown, the service status detection device 130 is applied to a service status detection node, which is located in a preset network architecture. The preset network architecture also includes multiple service nodes. The device includes: The acquisition module 1301 is used to acquire node tracing data during the processing of a business request. The node tracing data is generated by the service node during the processing of the business request. The node tracing data includes the tracing information of the business request. The tracing information is transmitted and updated between service nodes as the business request is processed. The tracing information includes: business request identifier, service identifier, tracing identifier and link depth sequence number. The determination module 1302 is used to determine the status of the service node based on the node tracking data.

[0123] In some embodiments, the service status detection device 130 further includes a data entry module, which is used for: Add at least one preset event to the business logic of the service node so that the service node, in response to the triggering of the preset event, performs at least one of the following: transmits and updates tracking information, or generates node tracking data.

[0124] In some embodiments, the tracking information further includes event identifiers, which include request reception event identifiers and response return event identifiers. The determination module is specifically used to: determine the event triggering status of the event within the service node based on the node tracking data; and determine the status of the service node based on the event triggering status.

[0125] In some embodiments, the determining module is further configured to: if it is determined that there is an isolated request receiving event or response returning event, then determine that the state of the service node is an abnormal state.

[0126] In some embodiments, the node tracking data further includes context call information, which includes the trigger time of the event and the event triggering condition, including the event triggering order. The determining module is further configured to: determine node tracking data belonging to the same service node based on the service identifier; sort the node tracking data belonging to the same service node by link depth sequence number, and sort them by trigger time when the link depth sequence numbers are the same to obtain the event triggering order; determine the state of the service node as abnormal if at least one of the following conditions is met: the event triggering order is different from the preset order, or the interval between the triggering times of adjacent events is greater than the preset time interval.

[0127] In some embodiments, the tracking information further includes a tracking event identifier, and the node tracking data further includes context call information, which includes the trigger time of the tracking event and the parent service identifier of the calling service node. The service status detection device 130 further includes a link restoration module, which is used to: restore the service call link of the business request according to the parent service identifier and the link depth sequence number; and determine the performance parameters of the service call link according to the service call link and the trigger time. The performance parameters include at least one of the following: total link time, number of service calls, average service response time, and service call frequency.

[0128] In some embodiments, the event tracking includes request reception events and response return events. The link restoration module is specifically used to: calculate the service response time of the service node based on the triggering time of the request reception event and its corresponding response return event in the service node; and calculate the average service response time of all service nodes in the service call link to obtain the average service response time.

[0129] The service status detection device provided in this application embodiment can implement the service status detection method applied to the service status detection node in the above embodiment. The specific implementation process and principle are similar, and will not be described in detail here.

[0130] This application embodiment also provides a service status detection device, applied to a service node, the service node being located in a preset network architecture, the preset network architecture further including a service status detection node, the service status detection device comprising: The generation module is used to generate node tracking data for business requests during the processing of business requests. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number.

[0131] In some embodiments, the service status detection device further includes an update module, which is configured to: receive tracing information sent by the parent service node in response to being invoked, and update at least one of the following in the tracing information: service identifier and link depth sequence number.

[0132] The service status detection device provided in this application embodiment can implement the service status detection method applied to service nodes in the above embodiment. The specific implementation process and principle are similar, and will not be described in detail here.

[0133] Figure 14 This is a schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application. Figure 14 As shown, the electronic device may include a processor 1401 and a memory 1402 storing computer program instructions.

[0134] Specifically, the processor 1401 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0135] Memory 1402 may include mass storage for data or instructions. For example, and not limitingly, memory 1402 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1402 may include removable or non-removable (or fixed) media. Where appropriate, memory 1402 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 1402 is non-volatile solid-state memory.

[0136] Memory may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, and electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it is operable to perform the operations described with reference to the methods according to one aspect of this disclosure.

[0137] The processor 1401 implements any of the service status detection methods in the above embodiments by reading and executing computer program instructions stored in the memory 1402.

[0138] In one example, the electronic device may also include a communication interface 1403 and a bus 1404. For example, Figure 14 As shown, the processor 1401, memory 1402, and communication interface 1403 are connected through bus 1404 and complete communication with each other.

[0139] The communication interface 1403 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0140] Bus 1404 includes hardware, software, or both, that couples components of an electronic device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 1404 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0141] The electronic device can execute the service status detection method in the embodiments of this application. The specific implementation method and principle are similar and will not be described in detail here.

[0142] Furthermore, in conjunction with the service status detection methods in the above embodiments, this application embodiment can provide a computer-readable storage medium for implementation. This computer-readable storage medium stores computer program instructions; when executed by a processor, these computer program instructions implement any of the service status detection methods in the above embodiments.

[0143] This application also provides a computer program product, including a computer program that, when executed by a processor, implements any of the service status detection methods described in the above embodiments.

[0144] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0145] The functional blocks shown in the above block diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0146] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0147] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0148] The above are merely specific embodiments of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A service status detection method, characterized in that, The method is applied to a service status detection node, which is located in a preset network architecture, and the preset network architecture also includes multiple service nodes. Obtain node tracking data during the processing of a business request. The node tracking data is generated by the service node during the processing of the business request. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between the service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number. The status of the service node is determined based on the node tracking data.

2. The service status detection method according to claim 1, characterized in that, Before obtaining the node tracking data of the business request during processing, the method further includes: Add at least one preset event to the business logic of the service node so that, in the process of processing the business request, the service node performs at least one of the following actions in response to triggering the preset event: transmitting and updating the tracking information, or generating the node tracking data.

3. The service status detection method according to claim 1, characterized in that, The tracking information also includes event identifiers, which include request reception event identifiers and response return event identifiers. Determining the status of the service node based on the node tracking data includes: Based on the node tracking data, determine the event triggering status of the embedded events within the service node; The status of the service node is determined based on the event triggering conditions.

4. The service status detection method according to claim 3, characterized in that, Determining the state of the service node based on the event triggering condition includes: If an isolated request receiving event or response returning event is determined, then the state of the service node is determined to be abnormal.

5. The service status detection method according to claim 3, characterized in that, The node tracking data also includes context call information, which includes the trigger time of the event and the event triggering sequence. Determining the event triggering sequence of the event within the service node based on the node tracking data includes: Based on the service identifier, determine the node tracking data belonging to the same service node; The node tracking data belonging to the same service node are sorted according to the link depth sequence number, and when the link depth sequence numbers are the same, they are sorted according to the trigger time to obtain the event trigger order; Determining the state of the service node based on the event triggering condition includes: If at least one of the following conditions is met, the state of the service node is determined to be abnormal: the event triggering order is different from the preset order, or the interval between the triggering times of adjacent embedded events is greater than the preset time interval.

6. The service status detection method according to claim 1, characterized in that, The tracking information also includes event identifiers, and the node tracking data also includes context call information, which includes the trigger time of the event and the identifier of the parent service calling the service node. After determining the status of the service node based on the node tracking data, the process further includes: Based on the parent service identifier and the link depth sequence number, the service call link of the business request is reconstructed; Based on the service call chain and the trigger time, the performance parameters of the service call chain are determined, and the performance parameters include at least one of the following: total chain time, number of service calls, average service response time, and service call frequency.

7. The service status detection method according to claim 6, characterized in that, The event tracking includes request reception events and response return events. Determining the performance parameters of the service call chain based on the service call chain and the trigger time includes: The service response time of the service node is calculated based on the triggering time of the request receiving event and its corresponding response return event in the service node. Calculate the average service response time of all service nodes in the service call chain to obtain the average service response time.

8. A service status detection method, characterized in that, The method is applied to service nodes located in a preset network architecture, which also includes service status detection nodes. During the processing of a business request, node tracking data is generated for the business request during the processing process. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number.

9. The service status detection method according to claim 8, characterized in that, Before generating the node tracking data for the business request during processing, the process also includes: In response to being invoked, the system receives the tracing information sent by the parent service node and updates at least one of the following in the tracing information: the service identifier and the link depth sequence number.

10. A service status detection device, characterized in that, An apparatus for use in service status detection nodes, wherein the service status detection nodes are located in a preset network architecture, and the preset network architecture further includes multiple service nodes, the apparatus comprising: The acquisition module is used to acquire node tracking data during the processing of a business request. The node tracking data is generated by the service node during the processing of the business request. The node tracking data includes tracking information of the business request. The tracking information is transmitted and updated between the service nodes as the business request is processed. The tracking information includes: business request identifier, service identifier, tracking identifier, and link depth sequence number. The determination module is used to determine the status of the service node based on the node tracking data.

Images