The following call chain model is abstracted based on previous experience and specific business scenario requirements:

Call chain metadata:

1) SpanEndpointType: call type (Root(” E “),Service(” S “), Client(” C “), Method(” M “));

Root refers to the first node in the invocation chain, i.e. the beginning of an invocation chain, which can be a service request, an HttpClient call, etc.

Service refers to the external Service provided by the system that is not the first node in the current invocation chain, for example, user login Service.

Client refers to the current call chain is not the first node and is a way of the current system and external communication, such as HttpClient, Mongoclient, etc.;

The value of Method is not the first node in the current call chain and is a function in the system, such as log counting function.

2) traceId: unique identifier of the call chain;

3) spanId: call order of the current node in a call chain (unique in combination with SpanEndpointType); SpanId adopts a layered design, shaped like 1.2.1, which can represent both the order of calls and the hierarchy of the call chain.

4) parentId: the parent calling node of the current node in a calling chain.

Call chain drawing rules:

1) The initial call (fatherless call) of the caller (service, Web) is recorded as the start node E, and the unique call chain ID, traceID, is generated;

2) System application component calls (such as HttpClient, method calls, etc.), spanId end by 1 (if it is the first one, the spanId end by.1);

3) Inter-system invocation (for example, service A calls service B). The span information of service A and service B differs only from that of SpanEndpointType (corresponding to two ends of span respectively).

Take a chestnut

Background: User Xiao Ming wants to get some knowledge through the network, through the network he entered the system O. Service A and B are deployed in service O. Service A uses HttpClient to communicate with SERVICE B. Service B will first interact with Redis and then interact with MyQL.

To complete this request the UAV abstracts out the following call chain model:

1) Xiaoming (the caller in the figure below) accesses service A through the portal. At this time, the calling chain generates A unique traceId and sets the SpanEndpointType of the current node to N (meaning the first node) and spanId to 1 (the first node in the current calling layer). ParentId = E (no parent node);

2) Service A initiates an HTTP request to service B through HttpClient, and invokes the chain metadata as follows: traceId (the parent node ID is used); 1.1 (spanId ends with.1 because it’s the first call); 1 (spanId of the parent parentId); C (call type recorded as C client call);

3) Service B receives A call from service A via HttpClient. At this time, the metadata of the call chain is as follows: traceId (same as the id of the initial call); 1.1 (spanId follows the spanId passed); 1 (parentId follows the passed parentId); S (call type recorded as S server processing request);

4) Service B queries Redis first, at this time, the call chain metadata is as follows: traceId (the id of the initial call is used); 1.1.1 (spanId ends with.1 because it’s the first call); 1.1 (spanId of parentId parent node); C (call type recorded as C client call);

5) B service initiates a query against mysql again, and at this time, the call chain metadata is as follows: traceId (the id of the initial call is used); 1.1.2 (spanId ends with a 1 because it is not the first call); 1.1 (spanId of parentId parent node); C (call type recorded as C client call);

6) At the end of processing, the call chain will record the recorded information.

Call the chain sequence diagram

UAVServer: Middleware enhancement framework, which provides the ability to hijack in different life cycles of middleware, i.e., middleware hijack technology, such as tomcat WebContainer startup time, etc.

JEEServiceRunGlobalFilterHandler: using middleware hijack technology extends the global filter, to intercept all passes through the middleware (such as tomcat) requests;

ServiceSpanInvokeChainHandler: in the call chain focus processing as a Service type node handler;

ClientSpanInvokeChainHandler: in the call chain focus processing as Client type node handler;

XXAdapter: refers to all adapters in the call chain, providing the ability to operate data in the handler (Service, Client, Method handler, Method type omitted in the figure) at the time before and after the action.

To complete the generation of the call chain without any “intrusion” into the user code, the process is roughly divided into the following processes:

1) in JEEServiceRunGlobalFilterHandler doRepuest packaging parse request;

2) Before in xxAdapter ADAPTS data;

3) xxHandler processes the request data within the corresponding scope (Service, Client and Method);

4) After in xxAdapter collates or records the data;

5) in JEEServiceRunGlobalFilterHandler doResponse returned after processing the request.

conclusion