WO2019105138A1

WO2019105138A1 - Service marking method, apparatus and device under multi-service system

Info

Publication number: WO2019105138A1
Application number: PCT/CN2018/110219
Authority: WO
Inventors: 王磊; 初兴涛; 魏鑫
Original assignee: 阿里巴巴集团控股有限公司
Priority date: 2017-11-29
Filing date: 2018-10-15
Publication date: 2019-06-06
Also published as: TW201926950A; CN108173706A; CN108173706B

Abstract

Disclosed are a service marking method, apparatus and device under a multi-service system. For multiple service requests sent out by a user for obtaining a service, a uniform service tracking identifier is generated. Even if service systems needing to be called by different service requests sent out by the user are different, the service tracking identifier can be transmitted between various service systems.

Description

Service marking method, device and device under multi-service system

Technical field

The present application relates to the field of computer technologies, and in particular, to a service marking method, apparatus, and device in a multi-service system.

Background technique

With the development of Internet technology, service providers can provide various types of business services to users based on the Internet. In the scenario where the user uses the service service, the service system generates a corresponding service log to record related information in the service process.

In the prior art, after a user sends a service request, processing the service request may involve calling multiple service systems to form a corresponding “call chain”, and the service system may generate a call chain identifier for the call chain, ie, traceID. On the basis of this, the service system records the trace ID in the service log. Then, in the service logs of different service systems belonging to the same call chain, the service track of the user is tracked according to the traceID.

However, in actual applications, there may be cases where users issue multiple different service requests. The call chains corresponding to different service requests are usually different, and the trace IDs are different.

Based on this, we need a way to easily mark the business trajectories of different business requests of the same user in the service logs of multiple business systems.

Summary of the invention

The embodiment of the present specification provides a method, a device, and a device for marking a service in a multi-service system, and a method for marking a user service trajectory in a multi-service system scenario.

A method for marking a service in a multi-service system according to an embodiment of the present disclosure, the method includes:

Determining a unified service tracking identifier for different service requests to complete the same service; wherein the service tracking identifier is transmitted between different service systems required to process different service requests;

The service log is recorded according to the service tracking identifier, and the service logs belonging to the same user are searched in the service logs of the multiple service systems according to the service tracking identifier.

The service marking device in the multi-service system provided by the embodiment of the present specification, the device includes:

An identity module, configured to determine a unified service tracking identifier for different service requests to complete the same service; wherein the service tracking identifier is transmitted between different service systems required to process different service requests;

The recording module records the service log according to the service tracking identifier, and searches for the service logs belonging to the same user in the service logs of the multiple service systems according to the service tracking identifier.

A service marking device in a multi-service system provided by the embodiment of the present specification, the device includes:

Processor, memory, where:

The memory, storing a service marking program;

The processor calls a service tag program stored in the memory and executes:

The above at least one technical solution adopted by the embodiments of the present specification can achieve the following beneficial effects:

A unified service tracking identifier is generated for a plurality of service requests sent by the user to obtain a certain service service, and the service tracking identifier can be transmitted between the service systems even if the service system called by the different service requests sent by the user is different. . Therefore, when the service logs record the service logs, the service tracking identifiers may be written into the service logs. Then, the service tracking identifiers can query and track the user's service trajectories in the service systems belonging to different call chains. .

DRAWINGS

The drawings described herein are intended to provide a further understanding of the present application, and are intended to be a part of this application. In the drawing:

FIG. 1 is a schematic structural diagram of a service marking method according to a multi-service system according to an embodiment of the present disclosure;

2 is a service marking process in a multi-service system according to an embodiment of the present disclosure;

FIG. 3 is a schematic diagram of an example of a service tracking identifier provided by an embodiment of the present disclosure;

FIG. 4 is a schematic diagram of a service tracking identifier delivery process in an actual application scenario according to an embodiment of the present disclosure;

FIG. 5 is a schematic structural diagram of a service marking apparatus in a multi-service system according to an embodiment of the present disclosure.

Detailed ways

The technical solutions of the present application will be clearly and completely described in the following with reference to the specific embodiments of the present application and the corresponding drawings. It is apparent that the described embodiments are only a part of the embodiments of the present application, and not all of them. All other embodiments obtained by a person of ordinary skill in the art based on the embodiments of the present application without departing from the inventive scope are the scope of the present application.

In a practical application scenario, a certain service request initiated by a user may require multiple service systems to be collaboratively processed, and a “call chain” is formed between the various service systems participating in the process. For example, if a user logs in to a product website, the user's login request can be regarded as a service request, and the call chain between the business systems provided by the service provider in the background for providing the login service can be as follows:

Account Login System → Certification Center → Account Database.

After the above call chain, the user's login service can be completed. In the backend of the service provider, the same call chain generates the same traceID. Specifically, for a certain service request sent by the user, the service provider background allocates a corresponding calling thread to implement a call to a different service system. Then, the traceID generated by the service provider in the background for the call chain can be considered as the traceID generated by the calling thread corresponding to the service request.

However, it should be understood that certain business services may require users to send multiple business requests to complete. For example, for a scenario in which a user purchases an item online, if the user wants to purchase an item online, the user needs to initiate a plurality of different service requests, such as an order request and a payment request, for the item to be purchased after the user initiates the login request. The call chain corresponding to each service request may be different (that is, the call thread assigned by the service provider to different service requests is different), so its traceID is also different. Obviously, when the above service system writes the service log, the trace ID of the service log is also different.

To this end, in one or more embodiments of the present specification, a service tagging method applied to a multi-service system is provided, and the same service tracking can be set for different call chains corresponding to multiple service requests sent by the same user. Logo. Then, when the service system writes its own service log, the service tracking identifier can be written into the service log, so that the service track of the user is tracked in the service logs of different service systems through the service tracking identifier.

In one or more embodiments, the service provider may be a website, a bank, a telecommunications carrier, a data center, or a service platform, and the like, which can provide service services to users through the Internet. Based on the service tagging method in the embodiment of the present specification, the service architecture adopted by the service provider backend may be as shown in FIG. 1. The architecture includes at least: a business client and multiple business systems. among them:

The service client (for convenience of description, hereinafter referred to as: client) may be a business application (such as a shopping app) or a browser running in the terminal device. In other words, the user can obtain the business service of the service provider through the business application, or access the website of the service provider through the browser to obtain the business service of the service provider. This is not specifically limited.

The service system can be considered as a system capable of providing corresponding service functions, and is usually composed of a corresponding service server. Of course, as a conventional implementation manner, the service server constituting the service system can adopt a single server, a distributed server, or a cluster. The architecture (characterizing the business system in the form of a single server in FIG. 1) is not specifically limited herein. Of course, as mentioned above, the business functions provided by a single business system are not sufficient to complete certain business services, so multiple business systems need to be coordinated.

Based on the foregoing, the process of performing the service tagging method in the multi-service system described in the embodiment of the present disclosure may be as shown in FIG. 2, and specifically includes the following steps:

Step S201: Determine a unified service tracking identifier for different service requests to complete the same service.

The service tracking identifier is transmitted between different business systems that are required to process different service requests.

Based on the architecture shown in Figure 1, the service request can be issued by the client. It can be understood that different service requests for the same service are completed here, usually for the same user. In addition, in the embodiment of the present specification, the different service requests for completing the same service are often associated with each other in the execution order. Generally, the execution of the latter service request depends on the execution of the previous service request. After the business results. As described above, when a user purchases an online product and issues a login request, an order request, and a payment request respectively, the execution of the order request by the business system depends on the registered user account, and the execution of the payment request depends on the generated order number.

The service tracking identifier may be in the form of a text character and is unique to the entire network. In some special application scenarios, the service tracking identifier in the form of graphical symbols should also be included in the scope of the embodiments of the present specification. Considering that the user ID of the user (such as the user ID, the account name, the device number of the terminal device used by the user, etc.) is also unique, in a possible implementation manner, the service tracking identifier may be Generated based on the user ID.

In addition, in the embodiment of the present specification, the service tracking identifier is carried in a process in which multiple service systems transmit intermediate service data to each other to complete the same service. Thereby the service tracking identifier is passed between multiple business systems. In particular, for a service system belonging to different call chains, a service tracking identifier can also be transmitted therein. Further, an association between service systems of different call chains can be established through the service tracking identifier.

Step S203: Record a service log according to the service tracking identifier, and search for a service log belonging to the same user in the service logs of the multiple service systems according to the service tracking identifier.

As mentioned above, the service tracking identifier is transmitted between multiple service systems. Then, when the service system records the service log, the service tracking identifier can be written into the service log. Subsequently, the service tracking identifier in the service log of different service systems can be used to query and track the user's service trajectory.

For example, as shown in FIG. 3, it is assumed that for service systems A to C, service systems A and B are used as call chain I for processing service requests I issued by users; and service systems A and C are used as another call chain II. Used to process the business request II issued by the user. On this basis, a unified service tracking identifier "LogID" is generated for the service request of the user, and is transmitted between the service systems A to C. Obviously, the LogID is obtained for both the call chain I and the service system on the call chain II. Therefore, when the service log is recorded, the LogID is also written into the service log. Therefore, the query and tracking of the user service track can be performed through the LogID in the service logs of different service systems.

Through the above steps, a unified service tracking identifier is generated for multiple service requests sent by the user to obtain a certain service service, and the service tracking identifier can be in each service even if the service system called by the different service requests sent by the user is different. Pass between systems. Therefore, when the service logs record the service logs, the service tracking identifiers may be written into the service logs. Then, the service tracking identifiers can query and track the user's service trajectories in the service systems belonging to different call chains. .

When the foregoing method is actually implemented, as a possible implementation manner, the generation of the service tracking identifier may be the first service system that receives the service request. Taking the above example as an example, the service system A, as the first service system that receives the user service request, may generate a service tracking identifier after receiving the service request I of the user.

In another possible implementation manner, in the background of the service provider, a corresponding identity generation service is run, and the service is used to generate a globally unique service tracking identifier. Of course, in an actual application, the identity generation service may be provided by a server running independently, or the identity generation service may be set in each service system.

For the above two execution entities that generate the service tracking identifier, the manner in which the actual execution is performed will be determined according to the needs of the actual application, and should not constitute a limitation on the present application. Therefore, in the embodiment of the present specification, determining a unified service tracking identifier for different service requests for completing the same service may specifically include: receiving a different service request sent by the user to complete the same service, according to the first received The service request generates the service tracking identifier and delivers to the business system required to process the different service requests.

In addition, it should be noted that for the process of generating the service tracking identifier, it should generally be generated for different service requests issued by the same user. In the embodiment of the present specification, the process of generating the service tracking identifier may include: determining user identification information carried in the service request, and generating the service tracking identifier according to the user identification information.

The user identification information includes at least: a user's account name, a user ID, a device hardware MAC address and/or an IP address used by the user.

Here are two possible scenarios:

In one possible scenario, a user makes a different service request using a client on his terminal device. In this scenario, the service request sent by the user may carry device information (such as the MAC address of the device) and network information (such as an IP address). Then, the service is conveniently provided according to the foregoing information carried in the service request. Generate a business tracking ID. If other service requests are subsequently received, and the other service requests also carry the above information, it can be determined that the same device is sent for different service requests, so that a unified service tracking identifier can be used for different service requests from the same device.

In another possible scenario, the user uses the client to make a service request on the mobile phone and uses the client on the tablet to make another service request. In this scenario, the device information and the network information carried in the service request are different. Then, it is generally determined that the service requests are from the same account according to the account information used by the user. Further, a unified service tracking identifier can still be used for different service requests carrying the same account information.

Of course, the generated service tracking identifier may be time-sensitive, that is, the service tracking identifier may remain valid for a set time, and if the service request from the same account or from the same device is not received within the set time, the The service tracking ID is invalid. In other words, after the service tracking identifier is invalid, if the service system receives the same account or a service request sent by the same device, a new service tracking identifier is generated. However, it should be understood that for the same user, there is usually a correlation between the original service tracking identifier and the newly generated service tracking identifier, because the newly generated service tracking identifier can also be generated based on the user identifier. Then, in the service log, the service tracking identifier related to the same user can be determined.

In an actual application, the time limit of the service tracking identifier may be set according to the needs of the actual application, for example, it is set to several hours, several days, one week, or one month, and the like, and is not specifically limited herein.

The service tracking identifier generated by the above content can be transmitted in different business systems. In the embodiment of the present specification, the process of transmitting the service tracking identifier can be referred to FIG. 4.

In FIG. 4, assuming that the service request I sent by the user is received by the service system A for the first time, the service system A can generate a service tracking identifier LogID for the service request I, and call the service systems B and D to process the service request I. . During this process, the LogID will be passed to business systems B and D. When the service system B and D process the service request I, the processing result will be returned to the front-end service system A (the LogID is also returned).

Based on this, when the user issues another service request II, when the service system A is called for the second time, the generated LogID can be continuously used and transmitted to the corresponding service system C. Similarly, the service system C will carry the LogID in the processing result and return to the front-end service system A after performing the business processing.

Based on this, each business system can write the log ID into the service log when the service log is recorded. Then, the LogID can be used to query and track the user's service trajectory in the service logs of each business system.

As shown in the foregoing example, in the embodiment of the present specification, the foregoing process for the other service system required to process the different service request may be: carrying the service tracking identifier for the service system that processes the same service request. The intermediate service data is delivered to other service systems required for processing the service request; for the service system that processes the different service requests, the service result data generated by the previous service request and carrying the service tracking identifier is transmitted to A business system that processes a business request.

In this way, even if the service provider allocates different calling threads for different service requests and generates different traceIDs based on this, a unified service tracking identifier can be generated for these service requests, then different service systems are In the process of recording the service log, in addition to writing the traceID to the service log, the service tracking identifier is also written to the business day. In addition, the association between the different trace IDs is established through the service tracking identifier, and the service trajectory of a certain user can be queried through the service tracking identifier in the service logs of different service systems.

The foregoing is a service marking method in the multi-service system provided by the embodiment of the present disclosure. Based on the same idea, the embodiment of the present specification further provides a service marking device in a multi-service system, as shown in FIG. 5 . The device includes:

The identifier module 501 determines a unified service tracking identifier for different service requests to complete the same service, where the service tracking identifier is transmitted between different service systems that are required to be processed by different service requests;

The recording module 502 records the service log according to the service tracking identifier, and searches for the service logs belonging to the same user in the service logs of the multiple service systems according to the service tracking identifier.

Further, the identifier module 501 receives a different service request sent by the user to complete the same service, generates the service tracking identifier according to the received first service request, and transmits the service tracking identifier to the processing of the different service request. business system.

The identifier module 501 is configured to determine user identifier information carried in the service request, and generate the service tracking identifier according to the user identifier information;

The identifier module 501, for the service system that processes the same service request, carries the service tracking identifier in the intermediate service data, and delivers the other service system required for processing the service request;

For the service system that processes the different service requests, the service result data that is generated by the previous service request and carries the service tracking identifier is transmitted to the service system that processes the latter service request;

The intermediate service data includes: an intermediate service request and/or an intermediate service result.

The identifier module 501 monitors the time limit of the service tracking identifier, and when the service tracking identifier exceeds the aging time, indicates that the service tracking identifier is invalid.

The device shown in FIG. 5 may be implemented by a physical device (such as a server and/or a terminal) in an actual application, and specifically includes: a processor and a memory, where

The memory stores a service tagging program under the multi-service system;

The processor calls a service tagging program under the multi-service system stored in the memory, and executes:

The various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the device, the device, and the media type embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment, which will not be repeated here.

So far, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the actions recited in the claims can be performed in a different order and still achieve the desired results. In addition, the processes depicted in the figures are not necessarily in a particular order or in a continu In some embodiments, multitasking and parallel processing may be advantageous.

In the 1990s, improvements to a technology could clearly distinguish between hardware improvements (eg, improvements to circuit structures such as diodes, transistors, switches, etc.) or software improvements (for process flow improvements). However, as technology advances, many of today's method flow improvements can be seen as direct improvements in hardware circuit architecture. Designers almost always get the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that the improvement of a method flow cannot be implemented by hardware entity modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is an integrated circuit whose logic function is determined by the user programming the device. Designers program themselves to "integrate" a digital system on a single PLD without having to ask the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Moreover, today, instead of manually making integrated circuit chips, this programming is mostly implemented using "logic compiler" software, which is similar to the software compiler used in programming development, but before compiling The original code has to be written in a specific programming language. This is called the Hardware Description Language (HDL). HDL is not the only one, but there are many kinds, such as ABEL (Advanced Boolean Expression Language). AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., are currently the most commonly used VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog. It should also be apparent to those skilled in the art that the hardware flow for implementing the logic method flow can be easily obtained by simply programming the method flow into the integrated circuit with a few hardware description languages.

The controller can be implemented in any suitable manner, for example, the controller can take the form of, for example, a microprocessor or processor and a computer readable medium storing computer readable program code (eg, software or firmware) executable by the (micro)processor. In the form of logic gates, switches, application specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers, examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, The Microchip PIC18F26K20 and the Silicone Labs C8051F320, the memory controller can also be implemented as part of the memory's control logic. Those skilled in the art will also appreciate that in addition to implementing the controller in purely computer readable program code, the controller can be logically programmed by means of logic gates, switches, ASICs, programmable logic controllers, and embedding. The form of a microcontroller or the like to achieve the same function. Such a controller can therefore be considered a hardware component, and the means for implementing various functions included therein can also be considered as a structure within the hardware component. Or even a device for implementing various functions can be considered as a software module that can be both a method of implementation and a structure within a hardware component.

The system, device, module or unit illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product having a certain function. A typical implementation device is a computer. Specifically, the computer can be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or A combination of any of these devices.

For the convenience of description, the above devices are described separately by function into various units. Of course, the functions of each unit may be implemented in the same software or software and/or hardware when implementing the present application.

Those skilled in the art will appreciate that embodiments of the present invention can be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment, or a combination of software and hardware. Moreover, the invention can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (system), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flowchart illustrations and/or FIG. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing device to produce a machine for the execution of instructions for execution by a processor of a computer or other programmable data processing device. Means for implementing the functions specified in one or more of the flow or in a block or blocks of the flow chart.

The computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing device to operate in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture comprising the instruction device. The apparatus implements the functions specified in one or more blocks of a flow or a flow and/or block diagram of the flowchart.

These computer program instructions can also be loaded onto a computer or other programmable data processing device such that a series of operational steps are performed on a computer or other programmable device to produce computer-implemented processing for execution on a computer or other programmable device. The instructions provide steps for implementing the functions specified in one or more of the flow or in a block or blocks of a flow diagram.

In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

The memory may include non-persistent memory, random access memory (RAM), and/or non-volatile memory in a computer readable medium, such as read only memory (ROM) or flash memory. Memory is an example of a computer readable medium.

Computer readable media, including both permanent and non-persistent, removable and non-removable media, can be stored by any method or technology. The information can be computer readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read only memory. (ROM), electrically erasable programmable read only memory (EEPROM), flash memory or other memory technology, compact disk read only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, Magnetic tape cartridges, magnetic tape storage or other magnetic storage devices or any other non-transportable media can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary storage of computer readable media, such as modulated data signals and carrier waves.

It is also to be understood that the terms "comprises" or "comprising" or "comprising" or any other variations are intended to encompass a non-exclusive inclusion, such that a process, method, article, Other elements not explicitly listed, or elements that are inherent to such a process, method, commodity, or equipment. An element defined by the phrase "comprising a ..." does not exclude the presence of additional equivalent elements in the process, method, item, or device including the element.

Those skilled in the art will appreciate that embodiments of the present application can be provided as a method, system, or computer program product. Thus, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment in combination of software and hardware. Moreover, the application can take the form of a computer program product embodied on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) including computer usable program code.

The application can be described in the general context of computer-executable instructions executed by a computer, such as a program module. Generally, program modules include routines, programs, objects, components, data structures, and the like that perform particular tasks or implement particular abstract data types. The present application can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are connected through a communication network. In a distributed computing environment, program modules can be located in both local and remote computer storage media including storage devices.

The various embodiments in the specification are described in a progressive manner, and the same or similar parts between the various embodiments may be referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the system embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiment.

The above description is only an embodiment of the present application and is not intended to limit the application. Various changes and modifications can be made to the present application by those skilled in the art. Any modifications, equivalents, improvements, etc. made within the spirit and scope of the present application are intended to be included within the scope of the appended claims.

Claims

A service marking method under a multi-service system, comprising:

Determining a unified service tracking identifier for different service requests to complete the same service; wherein the service tracking identifier is transmitted between different service systems required to process different service requests;

The service log is recorded according to the service tracking identifier, and the service logs belonging to the same user are searched in the service logs of the multiple service systems according to the service tracking identifier.
The method of claim 1, determining a unified service tracking identifier for different service requests to complete the same service, specifically including:

Receiving different service requests issued by users to complete the same service;

And generating, according to the received first service request, the service tracking identifier, and transmitting the service tracking identifier to a service system required to process the different service request.
The method of claim 2, the generating the service tracking identifier, specifically comprising:

Determining user identification information carried in the service request;

Generating the service tracking identifier according to the user identification information;

The user identification information includes at least: a user's account name, a user ID, a device hardware MAC address and/or an IP address used by the user.
The method of claim 2, which is delivered to other service systems required to process the different service requests, and specifically includes:

For the service system that processes the same service request, the service tracking identifier is carried in the intermediate service data and transmitted to other service systems required to process the service request;

For the service system that processes the different service requests, the service result data that is generated by the previous service request and carries the service tracking identifier is transmitted to the service system that processes the latter service request;

The intermediate service data includes: an intermediate service request and/or an intermediate service result.
The method of claim 1, before the recording of the service log according to the service tracking identifier, the method further comprises:

Monitoring the timeliness of the service tracking identifier;

When the service tracking identifier exceeds the aging time, the service tracking identifier is indicated to be invalid.
A service marking device under a multi-service system, comprising:

An identity module, configured to determine a unified service tracking identifier for different service requests to complete the same service; wherein the service tracking identifier is transmitted between different service systems required to process different service requests;

The recording module records the service log according to the service tracking identifier, and searches for the service logs belonging to the same user in the service logs of the multiple service systems according to the service tracking identifier.
The apparatus according to claim 6, wherein the identification module receives a different service request sent by the user to complete the same service, generates the service tracking identifier according to the received first service request, and transmits the difference to the processing The business system required for the business request.
The device of claim 7, the identification module, determining user identification information carried in the service request, and generating the service tracking identifier according to the user identification information;

The user identification information includes at least: a user's account name, a user ID, a device hardware MAC address and/or an IP address used by the user.
The device of claim 7, the identification module, for the service system that processes the same service request, carries the service tracking identifier in the intermediate service data and delivers to other service systems required to process the service request;

For the service system that processes the different service requests, the service result data that is generated by the previous service request and carries the service tracking identifier is transmitted to the service system that processes the latter service request;

The intermediate service data includes: an intermediate service request and/or an intermediate service result.
The apparatus according to claim 6, wherein the identification module monitors the time limit of the service tracking identifier, and when the service tracking identifier exceeds the aging time, indicating that the service tracking identifier is invalid.
A service marking device in a multi-service system, comprising: a processor and a memory, wherein:

The memory, storing a service marking program;

The processor calls a service tag program stored in the memory and executes:

Determining a unified service tracking identifier for different service requests to complete the same service; wherein the service tracking identifier is transmitted between different service systems required to process different service requests;

The service log is recorded according to the service tracking identifier, and the service logs belonging to the same user are searched in the service logs of the multiple service systems according to the service tracking identifier.