Automatic Analysis of Complex Interactions in Microservice Systems

Interactions in microservice systems are complex due to three dimensions: numerous asynchronous interactions, the diversity of asynchronous communication, and unbounded buffers. Analyzing such complex interactions is challenging. In this paper, we propose an approach for interaction analysis using model checking techniques, which is supported by the Process Analysis Toolkit (PAT) tool. First, we use Labeled Transition Systems (LTSs) to model interaction behaviors in microservice systems as sequences of send actions under synchronous and asynchronous communications. Second, we introduce a notion of correctness called “interaction soundness” which is considered as a minimal requirement for microservice systems. -ird, we propose an encoding of LTSs into the CSP# process algebra for automatic verification of the property interaction soundness. -e experimental results show that our approach can automatically and effectively identify interaction faults in microservice systems.


Introduction
e cloud computing paradigm [1][2][3] and edge computing paradigm [4][5][6] enable us to utilize IT resources flexibly. is trend not only drives many software systems to migrate from monolithic architecture to microservice architecture [7] but also attracts more and more research focuses on how to build "cloud-native" [8] applications.
Microservice architecture [9] can be used to develop a single application composed of a set of microservices. Compared with traditional web services, these microservices are much more fine-grained and are independently developed and deployed [3]. ese characteristics of microservice architecture are particularly suitable for losing coupling and updating systems running on cloud infrastructures [10]. e interactions in microservice systems are complex due to three dimensions: numerous asynchronous interactions, effective technique for analyzing interactions in microservice systems is synchronizability analysis [25][26][27]. A system is synchronizable if it sends actions which remain the same for both the asynchronous communication and synchronous communication. However, recent research shows synchronizability is undecidable [14].
In this paper, we propose an approach for interaction analysis using model checking techniques, which is supported by the Process Analysis Toolkit (PAT) [28] tool. Such an analysis approach enables us to effectively and automatically identify interaction faults of microservice systems. Our contribution can be summarized as follows: (i) We model complex interactions in microservice systems under synchronous and peer-to-peer asynchronous communications (ii) We introduce a notion of correctness called "interaction soundness" which is considered as a minimal requirement for microservice systems (iii) We automatically verify the property interaction soundness using model checking techniques under the support of the Process Analysis Toolkit (PAT) tool.
Moreover, we propose an encoding of LTSs into the CSP# process algebra. We choose CSP# because it is equipped with the PAT tool which offers the PAT simulator for state space generation and the PAT verifier for property verification. In particular, when the PAT verifier returns not valid using model checking, it gives us the counterexample which is very useful to fix faults. e rest of this paper is organized as follows. Section 2 discusses related work. Section 3 presents some formal definitions used throughout this paper. Section 4 formally defines the interaction behaviors of microservice systems under synchronous and peer-to-peer asynchronous communications. Section 5 introduces a notion of interaction soundness and verifies the property using model checking techniques based on CSP# encoding. Section 6 discusses the implementation of our approach and experimental results. Section 7 concludes this paper.

Related Work
ere has been some research on debugging microservice systems. In [10], the authors conducted an industrial survey to show three main faults in microservice systems, namely, internal faults, interaction faults, and environment faults. In [11,17], the authors proposed a novel approach for debugging microservice systems. In [18], the authors discussed complex live testing strategies for microservice systems. In [19], the authors proposed a new approach to test performance of each microservice participating in a microservice system. All these studies can be used to test microservice systems. However, our work focuses on analyzing interactions in microservice systems.
ere are some other studies on microservice systems. In [20], the authors proposed an approach to modeling and managing deployment costs for microservice systems. In [21], the authors discussed how to improve the performance of a microservice architecture. In [22], the authors proposed an approach to integrate microservices based on Linked Data. In [23], the authors presented a tool for generating and managing models of microservice architecture. In [24], the authors discussed how to balance the granularity of a microservice architecture. However, all these methods cannot be used to analyze interactions in microservice systems.
To the best of our knowledge, we are the first to analyze complex interactions in microservice systems.

Preliminaries
In this section, we present some definitions used throughout this paper.
For the sake of simplicity, we use r ⟶ a s to denote (r, a, s) ∈ Δ.
CSP# is an extension of CSP (communicating sequential processes) [29]. In this paper, we use CSP# for microservice system verification. In essence, CPS# is a formal method which integrates state-based specification and event-based specification. e following is a BNF description of the #CSP process expression. More details of CSP# can be found in [30]. where P and Q are processes, e is an event, X is a set of event names (e.g., {e 1 , e 2 }), b is a Boolean expression, ch is a channel, exp is an expression, and x is a variable [28]. e syntax of LTL formulas are defined as follows. More details of LTL can be found in [29].

Interaction Behavior Model
In this section, we introduce a formal model (see Figure 1) for modeling complex interactions in microservice systems. In our model, microservices with unbounded buffers communicate asynchronously with each other and interactions in a microservice system can be viewed as sequences of send actions because receive actions which consume messages from buffers are considered as local invisible actions. Figure 1 illustrates the three communicating microservices MS 1 , MS 2 , and MS 3 with messages a, b, c, and d that are from the example in [8].
e initial states of each microservice are subscripted with 0 and marked with incoming half-arrows. e final states of each microservice are marked with double circles. Each transition of each microservice is labeled with send action (exclamation marks) or receive message action (question marks). e buffers are in red lines and marked with i and j, where i denotes the sender and j denotes the receiver. For example, the buffer 12 denotes the buffer of MS 2 which is used to store incoming messages sent from MS 1 . Note that each buffer is an FIFO message queue.
When we further consider asynchronous messaging in Figure 1, there are two different semantics for the point-topoint asynchronous communication, namely, peer-to-peer communication and mailbox communication. e mailbox communication shown in Figure 2 requires all messages sent to MS 1 from the other microservices are stored in a buffer (i.e., a message queue) that is specific to MS 1 . e peer-topeer communication requires each message sent from a microservice MS 1 to another microservice MS 2 is stored in a buffer in an FIFO fashion which is specific to the pair (MS 1 , MS 2 ). In other words, each participating microservice of a microservice system is equipped with many buffers for different incoming messages from other microservices. In this paper, we focus on peer-to-peer communication.
Based on the analysis above, we first use finite LTSs to model the behaviors of individual microservices. en, we move to model the asynchronous interaction behaviors of microservice systems both with unbounded buffers and with bounded buffers (say k). Finally, we model the synchronous interaction behaviors of microservice systems based on the asynchronous interaction behaviors.

the transition relation
A transition τ ∈ δ can be one of the following three types: We often use s i ⟶ !m i→j s j to denote that (s i , !m i⟶j , s j ).

internal action]
According to Definition 4, microservices with unbounded buffers participating in a microservice system can interact with each other under the peer-to-peer semantics.
e states (C) of a composite service consisting of n microservices are described by each microservice' local state and its respective buffers. Each microservice has n − 1 unbounded buffers. When MS 1 sends a message m to MS 2 , the message will be inserted to the tail of the buffer 12 which is specific to the pair (MS 1 , MS 2 ) and then MS 2 can consume this message from the head of its buffer 12 . e send action (item 4a) is nonblocking and involves a sender, a receiver, and receiver's buffer. After the sender MS i sends a message m to the receiver MS j , the state of the sender is changed (4a-ii), the message will be inserted to the tail of the buffer ij which is specific to the pair (MS i , MS j ) (4a-iv), and the other buffers do not change (4a-v). e receive message action (item 4b) is blocking and local, which involves only a receiver. After the receive message action is executed, the state of the message receiver is changed (4bii), the message at the head of the buffer of the receiver is consumed (4b-ii), and the other buffers do not change (4bv). e epsilon-labeled transition (item 4c) is internal actions and can simply change the local state of a microservice.
Moreover, if we set Q i � (buffer i ) and keep others unchanged in Definition 4, the semantics of asynchronous communication is changed to the mailbox communication.
erefore, the mailbox communication is a special case of the peer-to-peer communication.
e interaction behavior of a microservice system depends on not only the order in which send actions are executed but also the size of each microservice's buffers [31].

Complexity
When buffers are unbounded, interaction behavior may be infinite. We define the asynchronous interaction behavior of microservice systems with bounded buffers in the following, where each participating microservice has buffers of size k.
Definition 5 (asynchronous interaction behavior of a microservice system with buffers of size k). e asynchronous interaction behavior of a microservice system with buffers of size k is denoted by a labeled transition system B k a � (C, c 0 , F, M, Δ) and described by augmenting condition (a) in Definition 4 to include the condition Q j � (q 1 , q j−1 , q j+1 ,. . ., q n ): |q j | < k, where |q i | denotes the length of the buffers for microservice MS i. In a microservice system with buffers of size k, the send actions are blocked if the receiver's buffer contains k messages. erefore, the interaction behavior of a microservice system with buffers of size k is finite. Figure 3(a) illustrates the asynchronous interaction behavior of the microservice system with buffers of size 2 shown in Figure 1  en, MS 2 consumes the "matching" message a at the head of its buffer 12 , the system evolves from c 1 to c 3, and the message a is removed from the buffer 12 . Figure 3(b) illustrates the asynchronous interaction behavior of the microservice system with buffers of size 2 shown in Figure 1

Synchronous Interaction Behaviors of Microservice
Systems. In synchronous communication, every send action is executed followed by a receive action, i.e., the microservices interact synchronously. It seems that each microservice of a microservice system has buffers of size 0.
Definition 6 (synchronous behavior of a microservices system). A synchronous behavior of a microservices system over a set of microservices (MS 1 , [synchronous send-receive action] [internal action] Figure 4 illustrates the synchronous behavior of a microservice system shown in Figure 1. e behavior of the system have transitions a 1⟶2 , followed by a 1⟶2 , followed by b 1⟶2 , and followed by c 3⟶2 .

Interaction Soundness-Based Verification
Given a microservice system, one crucial problem is to check whether the interaction behavior is correct. In this paper, we check whether the interaction behavior of a microservice system satisfies a minimal requirement for correctness using model-checking techniques. e whole process includes the following three steps: (1) We introduce a notion of correctness called 'interaction soundness' which is considered as a minimal requirement for microservice systems (2) We present an encoding of the interaction behavior into the CSP# process (3) We translate the property interaction soundness into LTL formulas such that we can verify this property using model-checking techniques under the support by the PAT verifier.

Interaction Soundness.
Let us further analyze the asynchronous interaction behavior of a microservice system with buffers of size 2 shown in Figure 3(a). When the execution of the microservice system is along the sequence of send and receive actions circled by a red dashed line, the terminating state is c 17 which denotes that each participating microservice reaches its corresponding final state, but the message queue buffer 12 of MS 1 and the message queue buffer 21 of MS 2 are not empty. In other words, there is an interaction fault which causes messages a 1⟶2 and d 1⟶2 not to be consumed correctly.
In Figure 5, we take a snapshot of the system in c 17 . ere are two messages a 1⟶2 in buffer 12 of MS 1 and one message d 1⟶2 in buffer 21 of MS 2 .
Based on the above analysis, we use the interaction correctness criterion as a minimal requirement any microservice system should satisfy. In particular, the requirement is described as follows.
For any case, the microservice system will terminate eventually and the moment the system terminates the terminating state is the final state.

Complexity
For every state c reachable from the initial state c 0 , there exists a transition sequence leading from state c to a final state c x . Formally, For every state c reachable from the initial state c 0 , there exists a transition sequence leading from state c to a final state c x . Formally, (2) e difference between Definitions 7 and 8 is that the states of the former are described in terms of local states of the participating microservices, while the states of the latter are described in terms of local states of the participating microservices and their respective buffers.

CPS# Encoding for the Behaviors of Microservice Systems.
We first discuss how to encode an asynchronous interaction behavior of a microservice system as a CSP# process. en, we discuss how to encode a synchronous interaction behavior.
e CSP# process encoding an asynchronous interaction behavior of a microservice system mainly includes the following three steps:  Figure 1 is a 1⟶2 , followed by a 1⟶2 and b 1⟶2 which can be encoded as !a->!a->!b-> Skip without considering buffers. (3) Encodes peer-to-peer asynchronous communication. In CSP#, the channel can be used to encode a buffer. Because each buffer is specific to the pair (sender, receiver) in the peer-to-peer asynchronous communication, we use the process buffer ij !m ⟶ P to denote that the sender MS i sends the message m to the buffer ij of the receiver MS j . Conversely, we use the process buffer ij [x � � m]?m ⟶ P to denote that the receiver MS j consumes the message m from its  Function gen_buffers generates all the buffers in a microservice system: Function gen_message_variable generates message variables in a microservice system: Function trace() obtains a set of sequences of send and receive messages on any path from the initial state s 0 : where the function sort(σ i ) sorts the messages on the path by their execution order. Because synchronous communication is a special case of asynchronous communication (i.e., the size of buffer is set to 0), the CSP# process of a synchronous behavior can be generated by using Algorithm 1 except setting the size of buffer ij to be 0.

LTL Formulas of Interaction Soundness.
After generating the CSP# process of a microservice system using Algorithm 1, we can generate the state space of the CSP# process using the PATsimulator and verify temporal logic properties using the PAT verifier. us, we need to translate Definitions 7 and 8 into LTL formulas. e property interaction soundness under synchronous communication can be defined as follows: where init denotes the initial state of the system, terminate denotes the final state of the system, and F denotes strong fairness conditions. e property interaction soundness under asynchronous communication can be defined as follows: #define buf ij call cempty, buf fer ij �� true; where cempty is channel operation which is a Boolean function to test whether the asynchronous channel is empty or not and buffer ij is channel specific to the pair (MS i , MS j ) which denotes the buffer of a microservice MS j .

Implementation and Experiments
6.1. Implementation. Our approach is completely automated. First, we have implemented an encoder which takes a microservice system as input and outputs the corresponding CSP# process. Second, once the CSP# process is obtained, we can generate the state space of the asynchronous interaction behavior of the microservice system using the PAT simulator 8 Complexity which is defined in an LTS. ird, we verify whether the generated state space satisfies the property interaction soundness using the PAT verifier. e generated asynchronous interaction behavior of the microservice system with buffers of size 3 shown in Figure 1 is shown in Figure 6 using the PAT simulator. e verification result shown in Figure 7 returns not valid, which means that the microservice system with buffers of size 3 has an interaction fault.

Experiments.
To validate our approach, we use 10 cases obtained from the literature. We choose these cases because the literature is representative. All cases were carried out on a PC with 2.50 GHz Processor and 8 GB of RAM, running Windows 10. Table 1 shows the experimental results for all the cases we conducted. e table gives for each case the number of participating microservices (MSs) involved in a microservice system, the number of messages (Ms), the size of the LTS of the synchronous interaction behaviors of a microservice system (B s ), the verification result under synchronous communication (IR a ) ("−" denotes that the system is not interaction sound and "+" denotes that the system is interaction sound), the size of the LTS of the asynchronous interaction behaviors of a microservice system with buffers of size k (B k a ), and the verification result under k-bounded asynchronous communication (IR s ).

Conclusion and Future Work
In this paper, we introduce a formal model for modeling complex interactions of microservice systems and verify whether these systems satisfy a minimal requirement for correctness using model-checking techniques. We have used LTLs to model complex interactions of microservice systems under synchronous and asynchronous communications and introduced a notion of correctness called "interaction soundness" which is considered as a minimal requirement for microservice systems. We automatically verified the property interaction soundness under the support of the PAT tool. Experiments showed that many cases have interaction faults.
Our future work is to investigate whether our results stand for mailbox communication, e.g., each microservice is  equipped with one buffer which is used to store incoming messages from the other microservices.

Data Availability
e data used to support the findings of this study are included within the article.

Conflicts of Interest
e authors declare that they have no conflicts of interest.