Automatic Analysis of Complex Interactions in Microservice Systems

Dai, Fei; Chen, Hao; Qiang, Zhenping; Liang, Zhihong; Huang, Bi; Wang, Leiguang

doi:https://doi.org/10.1155/2020/2128793

Complexity

On this page

Abstract Introduction Related Work Preliminaries Implementation Conclusion Data Availability Conflicts of Interest Acknowledgments References Copyright Related Articles

Special Issue

Collaborative Big Data Management and Analytics in Complex Systems with Edge

View this Special Issue

Research Article | Open Access

Volume 2020 | Article ID 2128793 | https://doi.org/10.1155/2020/2128793

Automatic Analysis of Complex Interactions in Microservice Systems

Fei Dai,¹Hao Chen,¹Zhenping Qiang,¹Zhihong Liang,¹Bi Huang,¹and Leiguang Wang¹

Guest Editor: Xuyun Zhang

Received03 Dec 2019

Revised02 Feb 2020

Accepted07 Feb 2020

Published31 Mar 2020

Abstract

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. Third, we propose an encoding of LTSs into the CSP# process algebra for automatic verification of the property interaction soundness. The experimental results show that our approach can automatically and effectively identify interaction faults in microservice systems.

1. Introduction

The cloud computing paradigm [1–3] and edge computing paradigm [4–6] enable us to utilize IT resources flexibly. This 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]. These characteristics of microservice architecture are particularly suitable for losing coupling and updating systems running on cloud infrastructures [10].

The interactions in microservice systems are complex due to three dimensions: numerous asynchronous interactions, the diversity of asynchronous communication, and unbounded buffers. First, the execution of a microservice system may involve numerous interactions among microservices. Most of these interactions are asynchronous because synchronous interactions may cause the multiplicative effect of downtime [11, 12]. For example, Netflix’s online service system involves 5 billion service invocations per day [13]. These asynchronous interactions may cause unexpected sequences of messages during execution. Second, under point-to-point semantics, there are at least two asynchronous communications with FIFO buffers [14], namely, peer-to-peer communication and mailbox communication. Microservice systems can be realized by the two different asynchronous communication models. Compared with the mailbox semantics, the peer-to-peer semantics causes the interaction topology to be a much complex graph. Third, because the sizes of the buffers of microservice systems are not known a priori, their sizes are often considered to be unbounded. Microservice systems with unbounded buffers may exhibit infinite state space such that the reachability problem of such systems is known to be undecidable [15].

The complexity of interactions in microservice systems poses great challenges to analyzing because missing or improper coordination among microservices may cause interaction faults. The results of the industrial survey in [10] show that interaction faults are common in microservice systems.

Although there are a few papers on microservice systems [16], most of them focus on debugging [10, 11, 17–19], deployment [20, 21], composition [22], architecture [23], and adaptation [24]. However, there is little research on the interaction analysis of microservice systems. A basic and effective technique for analyzing interactions in microservice systems is synchronizability analysis [25–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.

The 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.

There 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.

There 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.

3. Preliminaries

In this section, we present some definitions used throughout this paper.

Definition 1. (labeled transition system). A labeled transition system is a tuple LTS = (S, s₀, F, A, Δ), where(i)S is a set of states(ii)s₀ S is the initial state(iii)F S is a set of final states(iv)A is a set of labels(v) is a transition relationFor the sake of simplicity, we use 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. The following is a BNF description of the #CSP process expression. More details of CSP# can be found in [30]. P::=Stop in-action |Skip terminal |e ⟶ P prefix |ch!exp ⟶ P channel input |ch?exp ⟶ P channel output |P\X hiding |P; Q sequential composition |P[]X external choice |PΠX internal choice |if b {P} else {Q} conditional choice |[b]P guarded process |P||Q parallel composition |P|||Q interleaving |PΔQ interrupting |ref(Q) process referencingwhere P and Q are processes, e is an event, X is a set of event names (e.g., {e₁, e₂}), b is a Boolean expression, ch is a channel, exp is an expression, and x is a variable [28].
The syntax of LTL formulas are defined as follows. More details of LTL can be found in [29]. F = e | prop | [] F | <> F | X F | F1 U F2 | F1 R F2where e is an event, prop is a predefined proposition, F, F1, and F2 are three LTL formulas, [] denotes “always,” <> denotes “eventually,” X denotes “next,” U denotes “until”, and R denotes “release.”

4. 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₁, MS₂, and MS₃ with messages a, b, c, and d that are from the example in [8]. The initial states of each microservice are subscripted with 0 and marked with incoming half-arrows. The 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). The 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₁₂ denotes the buffer of MS₂ which is used to store incoming messages sent from MS₁. 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-to-point asynchronous communication, namely, peer-to-peer communication and mailbox communication. The mailbox communication shown in Figure 2 requires all messages sent to MS₁ from the other microservices are stored in a buffer (i.e., a message queue) that is specific to MS₁. The peer-to-peer communication requires each message sent from a microservice MS₁ to another microservice MS₂ is stored in a buffer in an FIFO fashion which is specific to the pair (MS₁, MS₂). 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. Then, 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.

Definition 2. (message set). A message set M is a tuple (, p, src, dst).(i) is a finite set of letters(ii) is a nonnegative integer number which denotes the number of participating microservices(iii)src and dst are functions that associate message m ∈ Σ to nonnegative integer numbers src(m) ≠dst(m) ∈ {1, 2, …, p}We often use for a message m such that src(m) = i and dst(m) = j.

Definition 3. (microservice). A microservice MS is a labeled transition system (S, s₀, F, M, δ), where(i)S is the finite set of states(ii)s₀ is the initial state(iii)F ⊆ S is the finite set of final states(iv)M is a message set(v)δ ⊆ S × (M ∪ {ε}) × S is the transition relationA transition τ ∈ δ can be one of the following three types:(1)A send-transition (s₁, , s₂) which denotes that the microservice MS₁ sends out a message to another microservice MS₂ where ∈ M(2)A receive-transition (s₁, , s₂) which denotes that the microservice MS₁ consumes a message where ∈ M(3)An ε-transition (s₁, ε, s₂) which denotes the invisible action of MS₁We often use to denote that (s_i, !, s_j).

4.1. Asynchronous Interaction Behaviors of Microservice Systems

Definition 4. (asynchronous interaction behavior of a microservice system with unbounded buffers). An asynchronous interaction behavior of a microservice system with unbounded buffers over a set of microservices (MS₁, MS₂, …, MS_n), where MS_i = (S_i, s_0i, F_i, M_i, δ_i) and M_i = (, p_i, src_i, dst_i), is denoted by a labeled transition system B_a = (C, c₀, F, M, ) (possible infinite state) where(i)C ⊆ Q₁ × S₁ × Q₂ × S₂…Q_n × S_n is the set of states such that ∀i ∈ {1, 2, …, n}:Q_i = (buffer_ji), where ∀j ∈ {1, 2, …, n}∧i ≠ j∧buffer_ji ⊆ (M_j).(ii)c₀ ∈ C is the initial state such that c₀ = (, c₀₁, , c₀₂,…, , c_0n), where c_0i = MS_i·s_0i.(iii)F ⊆ C is the set of final states such that ∀f ∈ F = (, f₁, , f₂,…, , f_n), where f_i ∈ MS_i·F_i.(iv)M = is the set of messages.(v)Δ ⊆ C × (M∪{ε}) × C for c = (Q₁, s₁, Q₂, s₂, …, Q_n, s_n) and c′ = (Q′₁, s′₁, Q′₂, s′₂, …, Q′_n, s′_n).(a) ∈ if ∃i, j ∈ {1, 2, …, n}:m ∈ M:(i) src(m) = i ∧ dst(m) = j,(ii) ∈ δ_i,(iii) ∀k ∈ {1, 2, …, n}:k ≠ i ⟹ s^’_k = s_k,(iv) ∀k ∈ {1, 2, …, n} ∧ k = i ⟹ buffer_kj = buffer_kjm,(v) ∀k, l ∈ {1, 2, …, n} ∧k ≠ i∧l ≠ j∧k ≠ l ⟹ buffer_kl′ = buffer_kl. [send action](b) ∈ Δ if ∃i, j ∈ {1, 2, …, n}∧m ∈ M:(i) src(m) = i∧dst(m) = j,(ii) ∈ δ_j,(iii) ∀k ∈ {1, 2, …, n}:k ≠ j ⟹ = s_k,(iv) ∀k ∈ {1, 2, …, n}∧k = i ⟹ buffer_kj′ = mbuffer_kj,(v) ∀k, l ∈ {1, 2, …, n}k ≠ i∧l ≠ j∧k ≠ l ⟹ buffer_kl′ = buffer_kl. [receive action](c) ∈ Δ if ∃i, j ∈ {1, 2, …, n}:(i) ∈ δ_i,(ii) ∀k ∈ {1, 2, …, n}: k ≠ i ⟹ = s_k,(iii) ∀k ∈ {1, 2, …, n}: = Q_k. [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. The 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₁ sends a message m to MS₂, the message will be inserted to the tail of the buffer₁₂ which is specific to the pair (MS₁, MS₂) and then MS₂ can consume this message from the head of its buffer₁₂. The 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). The 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 (4b-ii), the message at the head of the buffer of the receiver is consumed (4b-ii), and the other buffers do not change (4b-v). The 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. Therefore, the mailbox communication is a special case of the peer-to-peer communication.
The 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]. 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). The asynchronous interaction behavior of a microservice system with buffers of size k is denoted by a labeled transition system and described by augmenting condition (a) in Definition 4 to include the condition Q_j = (q₁, 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. Therefore, 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 under the peer-to-peer communication. The initial state is denoted by c₀ = (([], []), s₀₁, ([], []), s₀₂, ([], []), s₀₃) (i.e., each microservice is in its initial state and all the buffers are empty). After MS₁ sends the message a to the buffer₁₂ of MS₂, the system evolves from c₀ to c₁ and the buffer₁₂ contains a. Then, MS₂ consumes the “matching” message a at the head of its buffer₁₂, the system evolves from c₁ to c_3, and the message a is removed from the buffer₁₂.
Figure 3(b) illustrates the asynchronous interaction behavior of the microservice system with buffers of size 2 shown in Figure 1 under the mailbox communication. The initial state is c₀ = (([], []), s₀₁, ([], []), s₀₂, ([], []), s₀₃), and the final state is c₁₀.

(a)

(b)

4.2. 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₁, MS₂, …, MS_n), where MS_i = MS_i = (S_i, s_0i, F_i, M_i, δ_i) and M_i = (Σ_i, p_i, src_i, dst_i), is denoted by a labeled transition system B_s = (C, c₀, F, M, Δ), where(i) is the set of states.(ii)c₀ ∈ C is the initial state.(iii)F ⊆ C is the set of final states such that ∀f ∈ F = (f₁, f₂, …, f_n) where f_i ∈ MS_i·F_i.(iv)M = is the set of messages.(v)Δ ⊆ C × (M ∪ {ε}) × C for c = (s₁, s₂, …, s_n) and .(a) ∈ Δ if ∃i, j ∈ {1, 2, …, n}∧m ∈ M:(i) src(m) = i∧dst(m) = j,(ii) ∈ δ_i,(iii) ∈ δ_j,(iv) ∀k ∈ {1, 2, …, n} : k ≠ i∧k ≠ j ⟹ = s_k. [synchronous send-receive action](b) ∈ Δ if ∃i, j ∈ {1, 2, …, n}:(i) ∈ δ_i,(ii) ∀k ∈ {1, 2, …, n} : k ≠ i ⟹ = s_k, [internal action]Figure 4 illustrates the synchronous behavior of a microservice system shown in Figure 1. The behavior of the system have transitions , followed by , followed by , and followed by .

5. 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. The 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.

5.1. 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₁₇ which denotes that each participating microservice reaches its corresponding final state, but the message queue buffer₁₂ of MS₁ and the message queue buffer₂₁ of MS₂ are not empty. In other words, there is an interaction fault which causes messages and not to be consumed correctly.

In Figure 5, we take a snapshot of the system in c₁₇. There are two messages in buffer₁₂ of MS₁ and one message in buffer₂₁ of MS₂.

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.

Definition 7. (interaction soundness under synchronous communication). A microservice system B_s = (M, C, F, c₀, Δ) is interaction soundness under synchronous communication if and only if the following condition is satisfied.
For every state c reachable from the initial state c₀, there exists a transition sequence leading from state c to a final state c_x. Formally,

Definition 8. (interaction soundness under unbounded asynchronous communication or k-bounded asynchronous communication). A microservice system B_a = (M, C, F, c₀, Δ) or is interaction soundness under unbounded asynchronous communication or k-bounded asynchronous communication if and only if the following condition is satisfied.
For every state c reachable from the initial state c₀, there exists a transition sequence leading from state c to a final state c_x. Formally,The 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.

5.2. 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. Then, we discuss how to encode a synchronous interaction behavior.

The CSP# process encoding an asynchronous interaction behavior of a microservice system mainly includes the following three steps:(1)Encodes all the transitions in each microservice as events in CSP#. For example, the send-transition (s₁, , s₂) is encoded as an event !m and the receive-transition (s₁, , s₂) is encoded as an event ?m.(2)Encodes the order in which the adjacent transitions are executed as prefix or external choice in CSP#. For example, the order in which the microservice MS₁ executes transitions in Figure 1 is , followed by and 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 ⟶ 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 ⟶ to denote that the receiver MS_j consumes the message m from its buffer_ij, where the expression [x = = m] is used to check whether the top element in the buffer_ij is the matching message m.

Given a microservice system B_a = (M, C, F, c₀, Δ) over a set of microservices {MS₁, MS₂, …, MS_n}, we generate the CSP# process by using Algorithm 1.

Input: a microservice system B_a = (C, c₀, F, M, Δ)
Output: a CSP# process
(1)	{buffer₁₂,…, buffer_n−1n} = gen_buffers(B_a·C)
(2)	set {buffer₁₂,…, buffer_n−1n}’s size
(3)	gen_message_variable(B_a·M})
(4)	for MS_i ∈ (MS₁, MS₂, …, MS_n) do
(5)	{σ₁,…, σ_n} = trace(MS_i)
(6)	for σ_j ∈ (σ₁,…, σ_n) do
(7)	z = 1
(8)	while (m = getHead(σ_j))! = null
(9)	if type(m) = = “!”
(10)	P_z() = buffer_{src(m)_dst(m)}!action(m) ⟶ P_z+1()
(11)	else
(12)	P_z() = buffer_{src(m)_dst(m)}[x_z = = action(m)]?action(m) ⟶ P_z+1()
(13)	z = z + 1
(14)	end if
(15)	end while
(16)	P_MSi() = P₁()
(17)	end for
(18)	end for
(19)	System () = P_MS1()\|\|\|P_MS1()\|\|\|…\|\|\|P_MSn()

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₀:where the function sort(σ_i) sorts the messages on the path by their execution order.

For a message , function action() = m denotes the message and function type() = ! denotes the message type.

Let m, n, and p be separately the number of microservices, the max number of the traces, and the max number of messages on a branch. The worst time complexity of Algorithm 1 is (mnp).

Example 1. For the microservice system with buffers of size 2 shown in Figure 3, the CSP# process is shown below: ////////////////The buffers////////////////// channel buffer₁₂ 2; channel buffer₁₃ 2; channel buffer₂₁ 2; channel buffer₂₃ 2; channel buffer₃₁ 2; channel buffer₃₂ 2; ////////////////The messages////////////////// var a = 1; var b = 2; var c = 3; var d = 4; //////////The process of each participating microservice/////// P_MS1() = buffer₁₂!a ⟶ buffer₁₂!a ⟶ buffer₁₃!b ⟶ Skip; P_MS2() = buffer₁₂? 1 ⟶ buffer12? 1 ⟶ buffer32? 3 ⟶ Skip[]buffer₃₂? 3 ⟶ buffer₂₁!d ⟶ Skip; P_MS3() = buffer₁₃?2 ⟶ buffer₃₂!c ⟶ Skip; //////The process of an asynchronous interaction behavior of a microservice system ////// System() = P_MS1()|||P_MS2()|||P_MS3().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.

5.3. 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 PAT simulator and verify temporal logic properties using the PAT verifier. Thus, we need to translate Definitions 7 and 8 into LTL formulas.

The 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.

The property interaction soundness under asynchronous communication can be defined as follows: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.

Example 2. For the microservice system with buffers of size 3 shown in Figure 3, the LTL formula of the property interaction soundness is defined as follows: #define buf12 call(cempty,buffer12) = = true; #define buf13 call(cempty,buffer13) = = true; #define buf21 call(cempty,buffer21) = = true; #define buf23 call(cempty,buffer23) = = true; #define buf31 call(cempty,buffer31) = = true; #define buf32 call(cempty,buffer32) = = true; #assert System()| = [](“init”-> <> (“terminate” && buf12 && buf13 && buf21 && buf23 && buf31 && buf32));

6. 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 which is defined in an LTS. Third, we verify whether the generated state space satisfies the property interaction soundness using the PAT verifier.

The 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. The verification result shown in Figure 7 returns not valid, which means that the microservice system with buffers of size 3 has an interaction fault.

6.2. 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. The 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 (), and the verification result under k-bounded asynchronous communication (IR_s).

Out of the 10 cases presented in Table 1, 7 cases can be interaction sound under synchronous communication, e.g., see cases Ca-02, Ca-03, Ca-04, Ca-06, Ca-07, Ca-08, and Ca-10. In 7 cases, microservice systems with buffers of size 3 are not interaction sound, e.g., see cases Ca-01, Ca-02, Ca-03, Ca-05, Ca-06, Ca-09, and Ca-10.

From Table 1, we can further see that, (1) in each case, the LTS of the asynchronous interaction behavior of a microservice system is bigger than that of the synchronous interaction behavior, i.e., the asynchronous interaction behavior is more complex than the synchronous interaction behavior; (2) the asynchronous interaction behavior of some microservice systems is stable, i.e., once the size of the LTS of the asynchronous interaction behavior remains unchanged for a buffer bound, e.g., see cases Ca-04, Ca-07, Ca-08, Ca-09, and Ca-10. This property on the system is called stable which is proposed in [40]; (3) when some microservice systems with buffers of size 1 are interaction sound, it does not mean that the systems with buffers of size k (k > 1) are also interaction sound, e.g., see the case Ca-10; (4) during the experiments, Case-5 faces the state space explosion problem. “Too large” means that the PAT simulator is forced to stop due to the huge state space size (>300 states).

7. 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

The data used to support the findings of this study are included within the article.

Conflicts of Interest

The authors declare that they have no conflicts of interest.

Acknowledgments

This work was supported in part by the project of National Natural Science Foundation of China (Grant nos. 61702442 and 61862065) and the Application Basic Research Project in Yunnan Province (Grant no. 2018FB105).

References

X. Xu, Q. Liu, Y. Luo et al., “A computation offloading method over big data for IoT-enabled cloud-edge computing,” Future Generation Computer Systems, vol. 95, pp. 522–533, 2019.
View at: Publisher Site | Google Scholar
L. Qi, Y. Chen, Y. Yuan, S. Fu, X. Zhang, and X. L. Xu, “A QoS-aware virtual machine scheduling method for energy conservation in cloud-based cyber-physical systems,” World Wide Web, 2019.
View at: Publisher Site | Google Scholar
X. Xu, Y. Xue, L. Qi et al., “An edge computing-enabled computation offloading method with privacy preservation for internet of connected vehicles,” Future Generation Computer Systems, vol. 96, pp. 89–100, 2019.
View at: Publisher Site | Google Scholar
X. Xu, X. Zhang, H. Gao, Y. Xue, L. Qi, and W. Dou, “BeCome: blockchain-enabled computation offloading for IoT in mobile edge computing,” IEEE Transactions on Industrial Informatics, vol. 16, no. 6, pp. 4187–4195, 2020.
View at: Publisher Site | Google Scholar
X. Xu, C. He, Z. Xu, L. Qi, S. Wan, and M. Z. A. Bhuiyan, “Joint optimization of offloading utility and privacy for edge computing enabled IoT,” IEEE Internet of Things Journal, p. 1, 2019.
View at: Publisher Site | Google Scholar
X. Xu, Y. Chen, X. Zhang, Q. Liu, X. Liu, and L. Qi, “A blockchain-based computation offloading method for edge computing in 5G networks,” Software: Practice and Experience, 2019.
View at: Publisher Site | Google Scholar
V. Heorhiadi, S. Rajagopalan, H. Jamjoom, M. K. Reiter, and V. Sekar, “Gremlin: systematic resilience testing of microservices,” in Proceedings of the 36th IEEE International Conference on Distributed Computing Systems, ICDCS, pp. 57–66, Nara, Japan, June 2016.
View at: Google Scholar
J. Lewis and M. Fowler, “Microservices a definition of this new architectural term,” 2014, http://martinfowler.com/articles/microservices.html.
View at: Google Scholar
A. Balalaie, A. Heydarnoori, and P. Jamshidi, “Microservices architecture enables DevOps: migration to a cloud-native architecture,” IEEE Software, vol. 33, no. 3, pp. 42–52, 2016.
View at: Publisher Site | Google Scholar
X. Zhou, X. Peng, T. Xie et al., “Fault analysis and debugging of microservice systems: industrial survey, benchmark system, and empirical study,” IEEE Transactions on Software Engineering, p. 1, 2018.
View at: Publisher Site | Google Scholar
X. Zhou, X. Peng, T. Xie et al., “Delta debugging microservice systems with parallel optimization,” IEEE Transactions on Services Computing, p. 1, 2019.
View at: Publisher Site | Google Scholar
J. Lewis and M. Fowler, “Microservices: a definition of this new architectural term,” 2014, http://martinfowler.com/articles/microservices.html.
View at: Google Scholar
A. Deb, “Application delivery service challenges in microservices-based applications,” 2016, http://www.thefabricnet.com/application-delivery-servicechallenges-in-microservices-based-applications/.
View at: Google Scholar
F. Alaina and É. Lozes, “Synchronizability of communicating finite state machines is not decidable,” in Proceedings of the 44th International Colloquium on Automata, Languages, and Programming ICALP 2017, vol. 122, pp. 1–14, Warsaw, Poland, 2017.
View at: Google Scholar
X. Fu, T. Bultan, and J. Su, “Synchronizability of conversations among web services,” IEEE Transactions on Software Engineering, vol. 31, no. 12, pp. 1042–1055, 2005.
View at: Publisher Site | Google Scholar
X. Zhou, X. Peng, T. Xie et al., “Poster: benchmarking microservice systems for software engineering research,” in Proceedings of the International Conference on Software Engineering: Companion Proceedings (ICSE’18), pp. 323-324, Gothenburg, Sweden, 2018.
View at: Google Scholar
X. Zhou, X. Peng, T. Xie et al., “Delta debugging microservice systems,” in Proceedings of the 33rd ACM/IEEE International Conference on Automated Software Engineering, pp. 802–807, New York, NY, USA, 2018.
View at: Google Scholar
G. Schermann, D. Schöni, P. Leitner, and H. C. Gall, “Bifrost: supporting continuous deployment with automated enactment of multi-phase live testing strategies,” in Proceedings of the 17th International Middleware Conference, p. 12, Trento, Italy, December 2016.
View at: Google Scholar
A. de Camargo, I. L. Salvadori, R. dos Santos Mello, and F. Siqueira, “An architecture to automate performance tests on microservices,” in Proceedings of the 18th International Conference on Information Integration and Web-Based Applications and Services, iiWAS 2016, pp. 422–429, Singapore, November 2016.
View at: Google Scholar
P. Leitner, J. Cito, and E. Stöckli, “Modelling and managing deployment costs of microservice-based cloud applications,” in Proceedings of the 9th International Conference on Utility and Cloud Computing, UCC 2016, pp. 165–174, Shanghai, China, December 2016.
View at: Google Scholar
S. Klock, J. M. E. M. van der Werf, J. P. Guelen, and S. Jansen, “Workload-based clustering of coherent feature sets in microservice architectures,” in Proceedings of the 2017 IEEE International Conference on Software Architecture, ICSA 2017, pp. 11–20, Gothenburg, Sweden, April 2017.
View at: Google Scholar
I. L. Salvadori, A. Huf, R. dos Santos Mello, and F. Siqueira, “Publishing linked data through semantic microservices composition,” in Proceedings of the 18th International Conference on Information Integration and Web-Based Applications and Services, iiWAS 2016, pp. 443–452, Singapore, November 2016.
View at: Google Scholar
G. Granchelli, M. Cardarelli, P. D. Francesco, I. Malavolta, L. Iovino, and A. D. S. Microart, “A software architecture recovery tool for maintaining microservice-based systems,” in Proceedings of the 2017 IEEE International Conference on Software Architecture Workshops, ICSA Workshops 2017, pp. 298–302, Gothenburg, Sweden, April 2017.
View at: Google Scholar
S. Hassan and R. Bahsoon, “Microservices and their design tradeoffs: a self-adaptive roadmap,” in Proceedings of the 2016 IEEE International Conference on Services Computing, SCC 2016, pp. 813–818, San Francisco, CA, USA, June 2016.
View at: Google Scholar
S. Basu and T. Bultan, “Choreography conformance via synchronizability,” in Proceedings of the 20th International Conference on World Wide Web, pp. 795–804, Hyderabad, India, March 2011.
View at: Google Scholar
S. Basu, T. Bultan, and M. Ouederni, “Synchronizability for verification of asynchronously communicating systems,” in Proceedings of the International Workshop on Verification, Model Checking, and Abstract Interpretation, pp. 56–71, Long Island, NY, USA, 2012.
View at: Google Scholar
S. Basu and T. Bultan, “On deciding synchronizability for asynchronously communicating systems,” Theoretical Computer Science, vol. 656, pp. 60–75, 2016.
View at: Publisher Site | Google Scholar
J. Sun, Y. Liu, and J. Dong, “Model checking CSP revisited: introducing a process analysis toolkit,” in Proceedings of the 2008 International Symposium on Leveraging Applications of Formal Methods, Verification and Validation, pp. 307–322, Porto Sani, Greece, 2008.
View at: Google Scholar
J. Sun, Y. Liu, J. Dong, and C. Chen, “Integrating specification and programs for system modeling and verification,” in Proceedings of the 3rd IEEE International Symposium on Theoretical Aspects of Software Engineering (TASE 2009), pp. 127–135, Tianjin, China, July 2009.
View at: Google Scholar
C. A. R. Hoare, “Communicating sequential processes,” International Series in Computer Science, Prentice-Hall, Upper Saddle River, NJ, USA, 1985.
View at: Google Scholar
S. Basu, T. Bultan, and M. Ouederni, “Deciding choreography realizability,” ACM SIGPLAN Notices, vol. 47, no. 1, pp. 191–202, 2012.
View at: Publisher Site | Google Scholar
X. Fu, T. Bultan, and J. Su, “Conversation protocols: a formalism for specification and verification of reactive electronic services,” Theoretical Computer Science, vol. 328, no. 1-2, pp. 19–37, 2004.
View at: Publisher Site | Google Scholar
P. Poizat, “Checking the realizability of BPMN 2.0 choreographies,” in Proceedings of the 2012 ACM Symposium on Applied Computing, pp. 1927–1934, ACM, Trento, Italy, March 2012.
View at: Google Scholar
G. Salaun, T. Bultan, and N. Roohi, “Realizability of choreographies using process algebra encodings,” IEEE Transactions on Services Computing, vol. 5, no. 3, pp. 290–304, 2012.
View at: Publisher Site | Google Scholar
T. Bultan, “Modeling interactions of web software,” in Proceedings of the 2006 International Workshop on Automated Specification and Verification of Web Systems, pp. 45–52, IEEE, Paphos, Cyprus, November 2006.
View at: Google Scholar
M. Güdemann, G. Salaün, and M. Ouederni, “Counterexample guided synthesis of monitors for realizability enforcement,” Automated Technology for Verification and Analysis, vol. 7561, pp. 238–253, 2012.
View at: Publisher Site | Google Scholar
M. Ouederni, G. Salaün, and T. Bultan, “Compatibility checking for asynchronously communicating software,” Formal Aspects of Component Software, Springer, Berlin, Germany, 2013.
View at: Google Scholar
G. Decker and M. Weske, “Local enforceability in interaction petri nets,” in Proceedings of the 5th International Conference on Business Process Management, pp. 305–319, Brisbane, Australia, September 2007.
View at: Google Scholar
T. Bultan, F. Chris, and F. Xiang, “A tool for choreography analysis using collaboration diagrams,” in Proceedings of the 7th IEEE International Conference on Web Services (ICWS 2009), pp. 856–863, Los Angeles, CA, USA, July 2009.
View at: Google Scholar
S. Basu and T. Bultan, “Automatic verification of interactions in asynchronous systems with unbounded buffers,” in Proceedings of the 29th ACM/IEEE International Conference on Automated Software Engineering ASE’14, pp. 743–754, Vsters, Sweden, September 2014.
View at: Publisher Site | Google Scholar

Copyright

Copyright © 2020 Fei Dai et al. This is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited.

PDF Download Citation

Download other formats

Order printed copies

Views

1414

Downloads

1369

Citations

Complexity

Collaborative Big Data Management and Analytics in Complex Systems with Edge

Automatic Analysis of Complex Interactions in Microservice Systems

Abstract

1. Introduction

2. Related Work

3. Preliminaries

4. Interaction Behavior Model

4.1. Asynchronous Interaction Behaviors of Microservice Systems

4.2. Synchronous Interaction Behaviors of Microservice Systems

5. Interaction Soundness-Based Verification

5.1. Interaction Soundness

5.2. CPS# Encoding for the Behaviors of Microservice Systems

5.3. LTL Formulas of Interaction Soundness

6. Implementation and Experiments

6.1. Implementation

6.2. Experiments

7. Conclusion and Future Work

Data Availability

Conflicts of Interest

Acknowledgments

References

Copyright