Topology-aware Microservice Architecture in Edge Networks: Deployment Optimization and Implementation

Although MSA is anticipated to provide finer-grained deployment schemes for edge networks, enhancing flexibility and scalability, and speeding up application development cycles, the development of microservices in edge networks still encounters numerous stringent challenges.

To effectively overcome the aforementioned challenges, we have proposed an innovative topology-aware MSA, which incorporates a three-tier network traffic analysis model. Then, we have formulated a weighted sum communication delay optimization problem that aims to improve delay performance by optimizing microservices deployment. To effectively tackle this problem, we have developed a novel topology-aware and individual-adaptive microservices deployment (TAIA-MD) scheme. Extensive simulations and physical platform validations demonstrate the superior performance of our proposed TAIA-MD scheme. The primary contributions of this paper are summarized as follows:

• •

  For the first time, we have proposed an innovative topology-aware MSA, which features a three-tier network traffic analysis model comprising the service, microservice, and edge node layers. This model meticulously captures the complex inter-microservice dependencies and edge network topologies by mapping microservice deployments onto edge nodes’ link traffic to accurately estimate the communication delay.

• •

  Building upon this model, we have formulated a weighted sum communication delay optimization problem that considers the load conditions of services, aiming to improve delay performance through optimizing microservices deployment. To address this intractable problem, we have developed a novel microservice deployment scheme named TAIA-MD, which customizes the deployment scheme by sensing network topologies and incorporates an individual-adaptive mechanism in the genetic algorithm (GA) to accelerate the convergence and avoid local optima.

• •

  Extensive simulations demonstrate that TAIA-MD can reduce communication delay by approximately 30% to 60% compared to existing deployment schemes in bandwidth-constrained and topology-complex edge networks. Moreover, physical platform experiments further show the superior robustness of the TAIA-MD in effectively combating link failures and network fluctuations.

The remainder of this paper is organized as follows. In Section II, we provide an in-depth literature review of relevant studies. The topology-aware MSA is introduced in Section III. Section IV formulates and solves the weighted sum communication delay optimization problem. The results and analysis of simulations and physical verifications are provided in Section V. Finally, Section VI concludes this paper and discusses future directions.

Due to the highly decoupled nature of MSA, implementing a certain service usually requires close collaboration among numerous microservices [37, 38]. However, deploying hundreds or thousands of microservice instances on resource-constrained servers presents a formidable challenge [39, 38, 13, 23, 24]. Research on microservice deployment schemes is always of paramount importance. Early studies on microservice deployment primarily centered around cloud environments [40, 41, 42]. In [40], the authors have considered resource contention and deployment time among microservices, and proposed a parallel deployment scheme to aggregate microservices that compete for as diverse resources as possible, thereby minimizing interference in resource-constrained cloud systems. To alleviate the enormous pressure brought by the scale of microservices on cluster management in cloud computing, the authors in [41] have developed a topology-aware deployment framework that leverages a heuristic graph mapping algorithm to capture the topological structure of microservices and clusters, thereby minimizing network overhead for applications. In order to mitigate communication delays caused by intricately interdependent microservices, the authors in [42] have explored a novel deployment scheme that leverages the fine-grained and comprehensive modeling of microservice dependencies.

Microservice deployment in edge networks is receiving increasing attention due to the flourishing development of latency-sensitive services, as well as advancements in edge or fog computing techniques. In [20] and [43], the authors have proposed a novel MSA called Nautilus to deploy microservice instances in the cloud-edge continuum effectively. This MSA adjusts instance placement and achieves load balancing by migrating containers from busy nodes, thereby ensuring the required QoS under external shared resource contention. To mitigate the impact of network load and routing on service reliability, in [44], we have proposed a network-aware service reliability model that effectively captures the correlation between network state changes and reliability. In addition, we have designed a service reliability-aware deployment algorithm, which leverages shared path reliability calculation to improve service failure tolerance and bandwidth consumption. In [45], the authors have studied an optimal microservice deployment scheme to balance layer sharing and chain sharing in resource-constrained edge servers. This scheme effectively addresses the challenges of microservice image pull delay and communication overhead minimization.

Although current research reveals valuable insights into microservice deployment in edge networks, it seldom accounts for the tangible impact of edge environments and resource contention [37, 38, 39, 13, 23, 24, 40, 41, 42, 20, 43, 44, 45]. The widespread distribution of edge devices and nodes, multi-hop forwarding characteristics of inter-node communications, and the complex intrinsic dependencies among microservices make accurate traffic analysis modeling a mystery [31, 20, 35]. Concurrently, the coexistence of multiple flows on numerous links sparks resource competition, leading to significant variations in link performance across deployment strategies. Moreover, improper deployment might overwhelm links, drastically degrading data transfer rates and increasing service delays. Nevertheless, prevailing studies typically simplify traffic analysis by disregarding the dynamic nature of network topology, node bandwidth, and delay [35].

First of all, we introduce the service layer invocation model. To facilitate clarity, we illustrate it with a specific example. As shown in Fig. 5, we examine a particular service invocation executing the service $W_{k},k\!\in\!\mathcal{K}$. The labels inside each node indicate the type of microservice, while the labels on each arrow represent the execution order of requests or responses. In edge networks, users access the network through their nearby user-access nodes. In particular, user’s requests first arrive at the user-access nodes and are then forwarded to the appropriate computing nodes based on the deployment scheme. To describe the process of user requests transitioning from the user-access node to the first microservice, we introduce a special microservice type $M_{0}$ called the virtual head microservice that is occupancy-free of any computational resources.

Let $F_{i,j}$ and $R_{i,j},i,j\in\mathcal{I},i\neq j$ indicate a request and response from $M_{i}$ to $M_{j}$ during the execution of service $W_{k}$, respectively. In this case, the microservice invocation of service $W_{k}$ presented in Fig. 5 can be formulated using multiset as follows:

We define $\mathcal{F}_{k}$ as the request matrix for $W_{k}$, where $F_{i,j}^{k}\in\mathcal{F}_{k}$ represent the number of requests from $M_{i}$ to $M_{j}$ during the execution of service $W_{k}$. Thus, $\mathcal{F}_{k}$ can be given by

Similarly, the response matrix of service $W_{k}$ can be defined by $\mathcal{R}^{k}=\left(\mathcal{F}_{k}\right)^{\mathrm{T}}$.

Each type of microservice is usually equipped with multiple instances, and this paper considers scheduling them using the Round Robin method. Thus, the likelihood of each instance $M_{i,a}$ for microservice $M_{i}$ being invoked is the same and can be given as follows:

For the case of $i=0$, it depends on the service arrival rate at each user-access node, which will be explained in detail later.

Let $P_{M_{i,a}}^{k}$ denote the probability of selecting instance $M_{i,a}$ when invoking microservice $M_{i}$ during the execution of service $W_{k}$, where $i\in\mathcal{I},k\in\mathcal{K},a\in\mathcal{A}_{i}$. Let $F_{M_{i,a},M_{j,b}}^{k}$ represent the average frequencies instance $M_{i,a}$ requests instance $M_{j,b}$ during the execution of service $W_{k}$, then we have

Let $D_{i,k}^{req}$ indicate the average requested data size when $M_{i}$ invokes $M_{j}$, and $\widetilde{F}_{M_{i,a},M_{j,b}}^{k}$ denote the average data size requested by instance $M_{i,a}$ from instance $M_{j,b}$ during the execution of service $W_{k}$. Then we can obtain that

Similarly, let $R_{M_{i,a},M_{j,b}}^{k}$ indicate the average frequencies that the instance $M_{i,a}$ responds to instance $M_{j,b}$ when $W_{k}$ is invoked, where $i,j\in\mathcal{I},a\in\mathcal{A}_{i},b\in\mathcal{A}_{j}$. The average data size per invocation from $M_{i}$ to $M_{j}$ and from $M_{i,a}$ to $M_{j,b}$ can be expressed as $D_{i,j}^{res}$ and $\widetilde{R}_{M_{i,a},M_{j,b}}^{k}$, respectively. Since the request and response processes correspond to each other, we can obtain that

The edge-node layer comprises three types of nodes: user-access nodes for processing user requests, routing nodes for data forwarding, and computing nodes for deploying and executing microservices. All nodes can be represented as set $\mathcal{N}$, with user-acess nodes as set $\mathcal{N}_{acc}$, routing nodes as set $\mathcal{N}_{rou}$, and computing nodes as set $\mathcal{N}_{cmp}$. In this case, we have $\mathcal{N}\triangleq\mathcal{N}_{acc}\cup\mathcal{N}_{rou}\cup\mathcal{N}_{cmp}$. We consider service requests arriving at each user-access node follow a Poisson distribution. If the Poisson parameter for $W_{k}$ at user-access node $N_{p}\in\mathcal{N}_{acc}$ is $\lambda_{p}^{k}$, then the Poisson parameter for the request of service $W_{k}$ in the edge-node layer can be expressed as

The computing node for deploying instance $M_{i,a}$ can be represented as $L_{i,a}\in\mathcal{N}_{cmp}$. For instances of the virtual head microservice $M_{0}$, the invocation probability of invoking instance $M_{0,c}$ during the execution of service $W_{k}$ can be given by

In this case, once microservice $M_{i}$ is invoked during the execution of $W_{k}$, the invocation probability of the instance $M_{i,a}$ can be denoted as follows:

Given any two nodes $N_{p}$, $N_{q}\in\mathcal{N}$, we define the traffic that directly flows from $N_{p}$ to $N_{q}$ without any forwarding as the direct traffic $S_{p,q}$. If nodes $N_{x}$ and $N_{y}$ are two adjacent nodes, then the traffic of all types, including forwarding traffic flowing this link, can be defined as the total traffic, represented by $\widetilde{S}_{x,y}$. Let $\mathcal{Q}_{p}$ denote the set of instances deployed on node $N_{p},p\in\mathcal{N}$, then the direct traffic between any two nodes $N_{p}$ and $N_{q}$ during a single execution of $W_{k}$ can be represented as

Then, the direct traffic from $N_{p}$ to $N_{q}$ in unit time can be represented by

We use $U_{p,q}$ to represent the routing path from $N_{p}$ to $N_{q}$, where $p,q\in\mathcal{N}$. Given any two adjacent nodes $N_{x}$ and $N_{y}$, if the directly connected link between them is one hop of the routing path $U_{p,q}$, then we can denote it as $\langle N_{x},N_{y}\rangle\in U_{p,q}$. The total traffic from $N_{x}$ to its adjacent nodes $N_{y}$ can be expressed as

where $(\ref{eq12})$ reveals that when traversing the routing path $U_{p,q}$, if the direct traffic from $N_{p}$ to $N_{q}$ is $S_{p,q}$, and $N_{x}$ to $N_{y}$ is one hop of $U_{p,q}$, then the total traffic between $N_{x}$ and $N_{y}$ is incremented by $S_{p,q}$.

To address the issue of multiple service traffic flows sharing link bandwidth, this paper leverages queuing theory to analyze available link bandwidth. We exploit the M/M/1 queuing model to model the data packet transmission process between any two adjacent nodes $N_{x}$ and $N_{y}$. Let the packet size be $s$ kB, the bandwidth from $N_{x}$ to $N_{y}$ be $Z_{x,y}$ Mbps, the packet arrival rate from $N_{x}$ to $N_{y}$ be $\lambda_{x,y}$ Mbps, and the service rate of the link be $\mu_{x,y}$ Mbps. The average sending time for each packet between $N_{x}$ and $N_{y}$ can be expressed as

The average available bandwidth of the directly connected link from $N_{x}$ to its adjacent node $N_{y}$ can be represented by

Given any two adjacent nodes $N_{x}$ and $N_{y}$, the propagation delay between them is represented as $V_{x,y}$. Assume full-duplex communication method among nodes, the total propagation delay between any two nodes $N_{p}$ and $N_{q}$ can be expressed as follows:

Let $Z_{min}^{p,q}$ denote the minimum available bandwidth among all paths from $N_{p}$ to $N_{q}$. Ignoring the forwarding time at intermediate nodes, the average communication delay $T_{M_{i,a},M_{j,b}}$ for instance $M_{i,a}$ to send requests to instance $M_{j,b}$ can be calculated as

where $L_{i,a},a\in\mathcal{A}_{i}$ and $L_{j,b},b\in\mathcal{A}_{j}$ represent the computing nodes where $M_{i,a}$ and $M_{j,b}$ are deployed, respectively. Similarly, the average communication delay for $M_{i,a}$ to send responses to $M_{j,b}$ can be given as follows:

Therefore, the average communication delay for each execution of service $W_{k}$ can be expressed as

Due to the various delay requirements of different service types, we employ the weighted sum of the average communication delays for each type of service to indicate system’s overall average communication delay, which can be expressed as follows:

where $\theta_{k}\in\Theta\triangleq\left\{\theta_{1},\cdots,\theta_{K}\right\}$ denotes the weight of service $W_{k},k\in\mathcal{K}$.

Due to the numerous microservices and nodes, it is extremely challenging to efficiently tackle the optimal solution of the original problem $\mathcal{P}1$ leveraging traditional convex optimization methods. To this end, we first introduce $0$-$1$ variables to transform $\mathcal{P}1$ into a nonlinear $0$-$1$ programming problem.

Given a large number of microservices and nodes, effectively tackling the nonlinear $0$-$1$ programming problem $\mathcal{P}2$ optimally within a constrained timeframe is challenging. While the genetic algorithm (GA) offers a robust heuristic approach for combinatorial problems, its inherent limitations of slow convergence and suboptimal performance in specific scenarios necessitate refinement. To address these shortcomings, we propose a novel topology-aware and individual-adaptive microservice deployment (TAIA-MD) scheme. This scheme leverages the perceived network topology to design the microservice deployment scheme. Moreover, it incorporates an individual-adaptive mechanism that enhances individual adaptability by strategically initializing a select group of “super individuals” within the GA population, thereby accelerating convergence and avoiding local optima. As described in Algorithm 1, the first part of our proposed TAIA-MD scheme encompasses four aspects, as follows:

• •

  Chromosome Encoding: We employ binary encoding, where each chromosome consists of $\left|\mathcal{I}\right|$ genes, representing the deployment of $\left|\mathcal{I}\right|$ microservice types. The set of computing nodes available for deployment is $\left|\mathcal{N}_{cmp}\right|$. Each gene is a binary string of length $\left|\mathcal{N}_{cmp}\right|$, with a value of ‘$0$’ or ‘$1$’ indicating whether the microservice is deployed on the corresponding computing node or not. In addition, the number of ‘$1$’s on each gene is consistent with the number of instances of the corresponding microservice type.

• •

  Fitness Function: The fitness function measures the quality of an individual in solving $\mathcal{P}2$. To minimize the average communication delay $T$, the fitness function is defined as a sufficiently large number minus $T$. The calculation of $T$ is detailed in Algorithm 2.

• •

  Genetic Operators: Genetic operators generate new individuals through selection, crossover, and mutation. For the selection operation, we implement the tournament method as our selection scheme. Specifically, two groups of individuals are randomly sampled from the population, with each containing $Y_{m}$ individuals. The fittest individual from each group is then selected as the parent. Following the selection operation, crossover operations are performed on these selected parents. Each gene from the parent has a probability of $Y_{p}$ to exchange two genes if the chromosomes of both individuals are feasible after exchanging. Subsequently, the offspring undergo mutation with a probability of $Y_{q}$, where bits are randomly flipped to maintain chromosome feasibility. The process of selection, crossover, and mutation repeats until the offspring population reaches the desired population size $Y_{n}$.

• •

  Termination Conditions: The algorithm has a maximum iteration count of $Y_{k}$ to ensure timely problem-solving. Termination transpires upon reaching this threshold or when individual fitness for $Y_{i}$ consecutive iterations has no significant change, conserving computational resources.

Moreover, we implement an individual-adaptive mechanism. This mechanism generates a select few “super individuals” during population initialization and endows them with adaptive capabilities to accelerate algorithm convergence. Algorithm 3 introduces a low-complexity algorithm named greedy-based time optimization algorithm to fine-tune deployment strategies for these super individuals. By altering the traversal order of services in line 3 of Algorithm 3, we can generate diverse deployment schemes, ensuring the genetic diversity of super individuals. To prevent the algorithm from getting trapped in local optima, we strictly limit the number of super individuals. Coupled with the tournament selection scheme, non-super individuals still have a significant chance of being selected as parents.

We first denote the maximum number of instances for each type of microservice as $X$. Then the complexity for randomly generating the deployment scheme in the initialization phase can be calculated $\mathcal{O}\left(X\left|\mathcal{M}\right|\right)$. In Algorithm 3, the complexity of deploying each microservice instance based on the invocation relationship is $\mathcal{O}\left(X\left|\mathcal{M}\right|\left|\mathcal{N}\right|\right)$. As illustrated in Algorithm 1, each iteration involves generating a new population and evaluating its fitness. As a result, the complexities for selection, crossover, and mutation operations are $\mathcal{O}\left(Y_{m}\right)$, $\mathcal{O}\left(\left|\mathcal{M}\right|\left|\mathcal{N}\right|\right)$, and $\mathcal{O}\left(1\right)$, respectively, resulting in the complexity for producing a new individual of $\mathcal{O}\left(Y_{m}+\left|\mathcal{M}\right|\left|\mathcal{N}\right|\right)$. The fitness evaluation in Algorithm 2 considers node-to-node forwarding paths and microservice instance invocation relationships, leading to a complexity of $\mathcal{O}\left(X^{2}\left|\mathcal{M}\right|^{2}\right)$. Algorithm 2 may require up to $Y_{k}$ iterations, each producing $Y_{n}$ individuals and evaluating their fitness. Compared to the iterative process, the initialization phase’s complexity is negligible. As a result, the proposed TASA-MD scheme has an overall computational complexity of $\mathcal{O}\left(Y_{k}Y_{n}\big{(}Y_{m}+X^{2}\left|\mathcal{M}\right|^{2}\big{)}\right)$, significantly improving solving efficiency compared to the exponential time complexity of the enumeration algorithm $\mathcal{O}\left(\big{(}X\left|\mathcal{M}\right|\big{)}^{\left|\mathcal{N}\right|}\right)$.

In our simulations, we consider there are $50$ types of microservices, each with input and output data sizes ranging from $10$ KB to $100$ KB, requiring $0.1$ to $0.3$ CPU units and $100$ MB to $300$ MB of memory per instance, typically deployed in $3$ to $5$ instances. There are $10$ service types with $5\!\sim\!8$ microservice invocations and an arrival rate $\lambda^{k}$ of $30\!\sim\!50$. The edge network topology comprises $50$ nodes, including $35$ computing nodes, $10$ routing nodes, and $5$ user-access nodes. Each link has a propagation delay of $10\mu s$ and a bandwidth of $100$ Mbps. Microservice instances are deployed on computing nodes, user requests arrive via user-access nodes, and routing nodes handle data forwarding. Each computing node has $8$ CPU cores and $8000$ MB memory. Notably, the simulation parameter settings are randomly generated within a reasonable range with reference to works [47, 31, 22] as well as the edge environment characteristics.

Furthermore, since different network topologies can significantly impact the performance of edge networks, for example, links used by multiple routing paths may lead to bandwidth shortages, in order to quantify this, we introduce the concept of link forwarding load (LFL) to indicate how often a link serves as the forwarding path in the network topology.

Fig. 6 depicts the LFLs across two different topologies, where edge weights signify LFLs calculated per Definition 1. In Topology 1, all adjacent nodes have LFLs of $12$, resulting in an average LFL of $12$. In Topology 2, links such as $E_{2,4}$ and $E_{4,7}$ bear higher routing tasks, leading to higher LFLs. Despite both topologies having identical node and edge counts, Topology 2 exhibits a higher average LFL, making it more prone to bandwidth bottlenecks. In our simulation’s default topology, the connections between nodes in the edge network are based on the concept of the defined LFL. By adjusting different LFLs, we can simulate various network topologies. The default topology used in our simulations is shown in Fig. 7.

DMSA is a decentralized MSA platform, and the biggest difference from traditional centralized MSAs is that it sinks the scheduling function from the control plane to edge nodes [46]. In particular, DMSA has redesigned three core modules of microservice discovery, monitoring, and scheduling, which achieve precise awareness of instance deployments, low monitoring overhead and measurement errors, and accurate dynamic scheduling, respectively. However, despite having a comprehensive scheduling mechanism, DMSA has not yet integrated microservice deployment optimization [46]. The picture of the real-world physical verification platform DMSA we constructed is shown in Fig. 8 (a).

In this paper, we have practically deployed the TAIA-MD scheme on the DMSA platform and verified its effectiveness and practicality. In particular, we exploit 6 Raspberry Pi 4Bs, 5 Orange Pi 5Bs, and 6 Gigabit Ethernet Switches to construct this edge network topology. This network topology includes 17 nodes, namely 6 Gigabit Ethernet switches as communication nodes, 3 Raspberry Pi 4B as user-access nodes, and 9 computing nodes (4 Raspberry Pi 4B and 5 Orange Pi 5B). We have designed three typical services: video services, download services, and graphic-text services. These services are implemented by 10 microservice instances ¹¹1Notably, three user-access nodes generate requests for three types of services at a specific arrival rate with loads evenly distributed.. Video segments range from $1$ to 3 MB with a maximum wait time of $10$ seconds. Graphic-text pages are $0.5$ to $1$ MB with the same wait time, while download files are $10$ to $20$ MB with a $100$-second wait time. If it times out, the service execution will be marked as failed. Each test lasts for $40$ minutes. To comprehensively evaluate the network performance of the TAIA-MD scheme deployed on the DMSA platform, we design two network emergencies, as shown in Fig. 8 (b). ➀ Link 1 between Switch 1 and Node 3 is disconnected at the 10th minute and restored at the 15th minute to simulate the computing node suddenly goes offline. ➁ Link 3 between Switch 3 and Switch 5 is restricted to 100 Mbps at the 30th minute and restored back to $1$ Gbps at the 35th minute to portray the network fluctuations. As shown in Table I, we also test the performance of TAIA-MD under high, medium, and low load conditions on the DMSA platform.

To comprehensively validate the effectiveness of the proposed TAIA-MD scheme, we compare it with four different baseline schemes in simulations, as follows:

• •

  Random Deployment Scheme (Random) [48]: Microservice instances are deployed randomly on selected nodes that meet resource requirements, generating the deployment scheme.

• •

  Greedy-based Deployment Scheme (Greedy) [31]: This scheme considers the complex dependencies among microservices, which are modeled as the chain structure but ignoring the network topology. It only considers the previous and next microservices in the invocation chain when deploying each instance, selecting the best-performing node after evaluating all possible nodes.

• •

  GA-Based Deployment Scheme (GA) [49]: This scheme takes into account the dependencies between microservices and the bandwidth capacity of edge nodes but overlooks the network topology. Since it also uses the GA, comparing it with our proposed TAIA-MD scheme highlights the performance gains from incorporating topology awareness.

• •

  Non-Individual-Adaptive TAIA-MD Scheme (w/o, IA) TAIA-MD: This variant of the proposed TAIA-MD scheme omits the individual-adaptation mechanism to validate the effectiveness individual-adaptation mechanism in accelerating convergence and avoiding local optima.

As illustrated in Fig. 9, we analyze the convergence performance of the traditional GA, (w/o, IA) TAIA-MD, and TAIA-MD schemes. Traditional GA converges quickly with fewer iterations. This primarily stems from its oversight of the edge network topology and individual adaptability, considering fewer influencing factors, thus necessitating fewer convergence iterations. Conversely, (w/o IA) TAIA-MD, which takes into account network topology and bandwidth contention, is more significantly impacted by deployment scheme variations, necessitating a longer optimization period. Addressing these issues, our proposed TAIA-MD scheme generates relatively superior individuals and gene fragments during genetic initialization, facilitating rapid convergence. Numerical results underscore that compared to (w/o, IA) TAIA-MD scheme, the proposed TAIA-MD reduces the iteration rounds by approximately $50\%$, typically completing within $300$ iterations. Furthermore, the TAIA-MD scheme tackles the tardy convergence issue of (w/o, IA) TAIA-MD, significantly enhancing algorithm efficiency. Noteworthy is that although traditional GA exhibits slightly faster convergence, its deployment schemes are far inferior compared to (w/o, IA) TAIA-MD and TAIA-MD, as will be detailed later.

As depicted in Fig. 10, we compare the performance of TAIA-MD against the baseline schemes across different link bandwidths. In the scenarios with lower bandwidth, due to certain link traffic exceeding available bandwidth, the Random, Greedy, and GA schemes experience severe congestion and significant delays. In contrast, (w/o, IA) TAIA-MD and TAIA-MD can effectively reduce the delay by over $90\%$ and competently prevent congestion through optimized microservices deployment. As bandwidth scales up to $100$ Mbps, the congestion and delay issues for Random, Greedy, and GA schemes can be significantly alleviated. Nonetheless, (w/o, IA) TAIA-MD and TAIA-MD schemes still demonstrate remarkable performance advantages. This primarily arises from their consideration of the impact of microservice deployment on available bandwidth, incorporating network topology and individual adaptation. Compared to Greedy and GA, (w/o, IA) TAIA-MD reduces delay by $73.1\%$ and $39.3\%$, respectively. As the link bandwidth further increases to above $150$ Mbps, due to the available bandwidth being much greater than the system requirement, the actual available bandwidth between nodes approaches the link bandwidth, and the impact of deployment schemes on available bandwidth gradually weakens. Except for the Random scheme, the performance gap between other schemes and (w/o, IA) TAIA-MD and TAIA-MD gradually narrows to within $20\%$. Moreover, across diverse link bandwidths, TAIA-MD improves delay performance by about $5\%$ and convergence performance by approximately $50\%$ compared to (w/o, IA) TAIA-MD scheme, which demonstrates the effectiveness of the individual-adaptive mechanism, i.e., Algorithm 3.

Fig. 11 illustrates the performance of five schemes across diverse service arrival rates. In scenarios with lower service arrival rates, denoting low-load conditions, except for random deployment, the performance differentials among these schemes appear marginal. However, (w/o, IA) TAIA-MD and TAIA-MD consistently exhibit the most superior performance. As service arrival rates increase, the bandwidth requirements of the system also increase accordingly. Compared with Random, Greedy, and GA schemes, the advantages of (w/o, IA) TAIA-MD and TAIA-MD become increasingly pronounced. This is primarily because they have taken into account the impact of microservice deployments on available bandwidth. As the service arrival rates increase, the burden borne by the links of edge networks intensifies, thereby leading to the realm of heightened network intricacies. Therefore, the proposed TAIA-MD scheme that integrates topology awareness and individual adaptability can fully utilize its advantages in these constantly changing networks.

Given sufficient memory resources, we adjust the computational resources on each node to evaluate the performance of algorithms. As shown in Fig. 12, with limited CPU resources, the flexibility of microservice deployment options is constrained, which makes the crossover and mutation process difficult for GA and (w/o, IA) TAIA-MD. In this case, Greedy and TAIA-MD, with individual adaptability, demonstrate superior performance. As computational resources increase, the flexibility of microservice deployment options expands, enhancing the performance of GA and (w/o, IA) TAIA-MD. When CPUs exceed four units, they surpass microservice deployment requirements, resulting in no significant performance changes for all schemes. This reveals that dynamically adjusting computational resources based on microservice deployment results can reduce resource overhead.

To thoroughly investigate the impact of network topology on microservice deployment performance, we analyze the delay performance of TAIA-MD and baseline schemes under different average link forwarding loads, as shown in Fig. 13. As the average link forwarding load increases, the competition for bandwidth resources between microservices becomes more serious, leading to higher system delay. Under high average link forwarding loads, (w/o, IA) TAIA-MD and TAIA-MD exhibit significantly better delay performance compared to Random, GA, and Greedy, which demonstrates that (w/o, IA) TAIA-MD and TAIA-MD effectively address bandwidth collision in edge networks. Furthermore, although (w/o, IA) TAIA-MD and TAIA-MD achieve similar delay performance, Fig. 9 has already demonstrated TAIA-MD’s superior convergence performance.

Assume the delays for Scheme A and Scheme B are $T_{A}$ and $T_{B}$, respectively. Then, the performance improvement percentage of Scheme A over Scheme B can be calculated as $\frac{T_{B}-T_{A}}{T_{B}}\times 100\%$. As shown in Fig. 14, we present the performance improvement percentage of TAIA-MD compared to baseline schemes under varied bandwidths, service arrival rates, computational resources, and average link forwarding loads. In most cases, considering the effects of topology and traffic on available bandwidth during deployment scheme calculation can effectively reduce the system’s delay. TAIA-MD can decrease system delay by approximately $30\%$-$60\%$ compared to other baseline schemes assuming fixed link bandwidth. Remarkably, in scenarios with low bandwidth, high service arrival rates, and complex topologies, TAIA-MD significantly prevents link congestion, providing substantial performance improvements. Furthermore, as illustrated in Fig. 14 (c), TAIA-MD generally suggests a performance gain of about $5\%$ over (w/o, IA) TAIA-MD. Importantly, with limited CPU resources, TAIA-MD performs markedly better than (w/o, IA) TAIA-MD, which underscores TAIA-MD’s extraordinary performance with topology-aware and individual-adaptive mechanisms for edge networks.

For latency-sensitive services like video and graphic-text services, we focus on analyzing the average delay performance of the TAIA-MD scheme deployed on the DMSA platform. As shown in Fig. 15, the average delay under various load conditions reveals that the DMSA platform with the TAIA-MD scheme (i.e., (DMSA, TAIA-MD) scheme) significantly outperforms the standalone DMSA platform. Specifically, for graphic-text services, the average delay improvement of the (DMSA, TAIA-MD) scheme over standalone the DMSA scheme is substantial, ranging from 31.13% under low loads to 38.51% under high loads. For video services, the performance enhancement of average delay for the (DMSA, TAIA-MD) scheme under low, medium, and high loads is 25.20%, 26.48%, and 37.92%, respectively. It can be seen that as the load increases, the delay performance advantage of the (DMSA, TAIA-MD) scheme becomes increasingly significant. In addition, the average delay of the DMSA platform deteriorates with the increase of load for both graphic-text and video services, while the average delay of the (DMSA, TAIA-MD) scheme is less affected by increasing load. This is primarily attributed to microservice deployment optimization of the (DMSA, TAIA-MD) scheme, which significantly reduces the overhead of instance scheduling in the DMSA platform and thus achieves lower average delay.

As illustrated in Fig. 16, we present the dynamic variations in delay performance over run time under various load conditions, taking video services as an example. Fig. 16 (a), (b), and (c) demonstrate that the (DMSA, TAIA-MD) scheme consistently outperforms the standalone DMSA platform in terms of delay performance under different loads. In particular, during the $10\sim 15$ min interval, a link disruption occurs between Switch 1 and Node 3, which causes a sharp increase in delay for both the (DMSA, TAIA-MD) scheme and DMSA. However, the delay performance can quickly recover from the link disconnection. Remarkably, the (DMSA, TAIA-MD) scheme restores network performance more rapidly. This is primarily due to the fact that the TAIA-MD scheme optimizes instance deployment on the basis of the DMSA platform’s effective sensing of network load and edge node status, and dynamically adjusts the scheduling strategies. During the $30\sim 35$ min interval, the link bandwidth between Switch 3 and Switch 5 fluctuates and drops sharply to $100$ Mbps. During this period, user requests are still routed through the constrained link, resulting in a significant increase in delay for both the (DMSA, TAIA-MD) scheme and DMSA platform. However, the delay performance can recover shortly after. The (DMSA, TAIA-MD) scheme is less affected by network fluctuations and recovers faster. This demonstrates the enhanced robustness and adaptability of the DMSA platform with the TAIA-MD scheme in handling network emergencies.

Next, the robustness of the (DMSA, TAIA-MD) scheme and DMSA platform is analyzed. As shown in Fig. 17 (a), (b), and (c), we examine the average service execution success rates of graphic-text, video, and file download services under various load conditions. Compared to the performance of the DMSA platform itself, the (DMSA, TAIA-MD) scheme overall improves the service execution success rates in edge networks and significantly enhances their robust performance. Fig. 17 (a)-(c) demonstrate that the (DMSA, TAIA-MD) scheme exhibits more pronounced performance advantages in microservice deployments as service data volume and load increase. For graphic-text and video services, the (DMSA, TAIA-MD) scheme stably maintains the service execution success rates of more than 98% and 97%, respectively. In large file downloads, the delay performance improvements in service execution success rates with the (DMSA, TAIA-MD) scheme become notably more significant as the load increases compared to the DMSA platform alone.