0 引言

随着物联网和5G通信技术的普及，网络数据量呈爆炸式增长。边缘计算通过在网络边缘近源处理数据的方式，可以有效减少延迟，提升数据处理效率^[1-2]。因其服务器和设备的计算和存储能力有限，并不适用于处理一些传统云计算任务^[3]。微服务架构因其轻量级、灵活和模块化的特点，成为开发边缘计算应用的理想选择^[4]。

为优化微服务在资源有限的边缘环境的适用性，研究如何对微服务进行有效部署至关重要。基于容器的云作为云计算领域的一种新型虚拟化解决方案，为微服务提供了低开销、安全隔离的执行环境^[5]。

在边缘环境中，计算通信开销是衡量部署结果优劣的重要指标。例如，Deng等^[6]提出了移动边缘计算中有限资源条件下服务部署成本最小化的方法。Guerrero等^[7]从构建服务部署模型的角度考虑了负载均衡、节点可靠性和网络开销等目标，获得最优的容器部署策略。此外，Lin等^[8]以降低网络传输开销、均衡资源负载、提高业务可靠性为目标，构建了多目标优化模型。

现有文章已提出降低微服务响应时间从而降低整体开销的一些部署策略，Brogi等^[9]通过优化网络延迟、优化节点执行时间以及优化应用部署位置来降低服务响应时间。Smet等^[10]通过在边缘云中策略性地放置Docker层，选取必要的层并在服务器节点上部署服务实例，以此来降低服务响应时间。此外，Samanta等^[11]提出了一个优先级的效用函数和一个动态微服务调度框架来优化总延迟。然而上述研究仅考虑了节点间的物理距离差异对通信开销的影响，却未考虑微服务的交互频率影响。

Joseph等^[12]从微服务之间的通信频率角度出发，提出了感知交互的微服务部署策略。通过在同一节点上部署大量微服务，最小化微服务之间的通信开销，但这可能导致节点出现资源不平衡的问题，增加应用程序的总访问延迟。因此，在交互感知的基础上，构建多目标优化模型时需要进一步考虑负载均衡，避免因部分节点资源占用过高而导致微服务应用程序整体执行性能下降。

从求解模型的角度看，强化学习因其在解决决策问题方面的显著优势而被应用于微服务部署。Wang等^[13]使用改进的Q学习算法解决边缘服务器上的微服务部署问题，以降低整体服务延迟。Chen等^[14]提出了一种在混合边缘云环境中部署物联网微服务的新方法，其可以在边缘和云节点之间实现动态迁移服务，以提高资源利用率并减少延迟。此外，Fu等^[15]同样提出一种基于强化学习的算法，考虑工作负载和资源可用性信息，动态迁移拥塞节点，缓解响应负载动态的资源争用，以确定最优部署策略。

本文针对微服务之间不同交互频率产生的影响以及边缘节点的资源均衡分配问题，引入深度Q学习来设计微服务部署方法。主要工作如下。

1) 构建微服务交互通信开销模型和节点资源分配模型，综合考虑微服务之间的交互关系和边缘节点的资源平衡的情况，以优化服务执行性能。

2) 提出了最优多目标微服务部署(optimal multi-objective microservices deployment，OMMD)问题, 旨在最小化通信开销的同时实现边缘节点的资源平衡，将微服务部署问题建模为马尔可夫决策过程，以找到在约束条件下的最佳部署策略。

3) 设计微服务优化奖励深度Q学习(microservice-optimized reward enhanced deep Q-learning，MORE-DQL)算法来解决最优部署问题。通过引入深度Q学习算法和优化奖励机制，优化部署决策过程，提高模型的收敛性，达到最优部署的效果。

1 多目标优化系统模型

本文采用容器化技术对微服务进行管理，承载微服务实例的容器通过Kubernetes容器编排平台利用相应策略部署到对应节点上，对节点进行排序并动态地加载。

设置一个边缘云平台，其中包含一组边缘节点E={e₁, e₂, …, e_N}和一个云端节点C，N是边缘平台中边缘节点的个数。对第i个边缘节点e_i，定义一组该边缘节点包含的资源OR_i={OR_i¹, OR_i², …, OR_i^|R|}，OR_i^j表示第j个资源在第i个节点的容量，|R|表示资源的数量，资源是指边缘节点上用于部署和执行微服务应用程序的资源，如计算资源、存储资源和网络带宽等。

容器被定义为C={c₁, c₂, …, c_{| C|}}，| C |表示应用程序中的容器数量。对于容器，两个二元部署指示变量p_{i, j}^E和p_i^C定义为

$ p_{i, j}^E= \begin{cases}1, & \text { 容器 } i \text { 部署在边缘节点 } j \text { 上, } \\ 0, & \text { 其他, }\end{cases} $

$ p_i^c= \begin{cases}1, & \text { 容器 } i \text { 部署在云节点 } j \text { 上, } \\ 0, & \text { 其他。}\end{cases} $

L_{i, j}表示部署了容器c_i和c_j节点之间的通信距离(包括边缘节点之间的通信距离和边缘节点到云的通信距离)。将容器i请求的资源表示为cr_i¹, cr_i², …, cr_i^|R|。

设定一个由多个具有调用关系的微服务MS={ms₁, ms₂, …, ms_|M|}组成的应用程序，|M|表示应用程序中微服务的数量。假设一个容器化的微服务包含一个或多个容器，对于第i个微服务ms_i，有ms_i={c₁, c₂, …, c_|msi|}，|ms_i|表示微服务i中的容器数量。

1.1 应用程序通信开销模型

微服务之间的调用关系通常会被描述为有向无环图(DAG)^[9-10]，然而任何方向的通信都会导致部署微服务的节点之间发生交互，因此笔者将通信模型建模为无向加权交互图, 并基于微服务的感知交互来计算应用程序的通信开销。

将微服务ms_i和ms_j之间的通信流量的相对值定义为w_ij，以心血管健康监测(cardiovascular health monitoring，CHM)应用程序^[16-17]为例：CHM应用程序由四个微服务组成，分别是预处理微服务、紧急诊断微服务、预测微服务和客户端微服务。

图 1展示了CHM应用程序中四个主要微服务之间的交互关系。每个节点代表一个微服务，边上的权重表示两个微服务之间的通信频率。

将微服务部署在多个容器中，所有部署的容器都共享请求负载，即对$\forall c_k \in m s_i$, $\forall c_l \in m s_j$，将微服务上部署的容器c_k和c_l之间的交互权值定义为

$ W_{\left\langle c_k, c_l\right\rangle}=w_{i j} /\left|m s_i\right|\left|m s_j\right| 。$

(1)

c_k和c_l两个容器之间的通信开销表示为W_{〈ck, cl〉}与部署容器的节点之间的通信距离L_{k, l}的乘积。若在同一节点部署有两个容器，则这两个容器的通信开销为0。在此基础上，将微服务ms_i和ms_j所包含的所有容器的通信开销全部相加就可以得到总通信开销。由于通信是双向的，每对微服务间的通信会被计算两次。为了修正计算问题，避免在总通信开销中的重复计算，可以得出应用程序的总通信开销Com，即

$ { Com }=\sum\limits_{m s_i \in M} \sum\limits_{m s_j \in M, i \neq j} \sum\limits_{c_k \in m s_i} \sum\limits_{c_l \in m s_j} W_{\left\langle c_k, c_l\right\rangle} \times L_{i, j}^E / 2 。$

(2)

1.2 边缘节点资源分配模型

为了避免服务执行性能下降，维持系统均衡，并在保证资源合理分配的情况下尽量减少云边通信，将边缘节点的资源占用率r定义为

$ r_i^j=\sum\limits_{m s_k \in M} \sum\limits_{c_l \in m s_k} p_{i, j}^E c r_l^j / O R_{i }^j 。$

将资源j在全部边缘计算的平均使用率表示为$\bar{r}_j$，而$\Delta r_i^j=\left|r_i^j-\bar{r}_j\right|$表示节点i上资源j的实际使用率与资源j平均占用率之间的差异。全部资源的方差可以定义为一个元组σ²={σ₁², σ₂², …, σ_|R|²}。即对于第j类资源，它的方差σ_j²可以表示为

$ \sigma_j^2=\sum\limits_{i=1}^N\left(\Delta r_i^j\right)^2 / N_{\circ} $

由于不同类型资源有不同权重，每个微服务ms_i对不同资源R_j有不同的需求因子β_i^j，可以得到每个微服务ms_i对资源j的加权依赖权重为$\beta_i{ }^j \times \sum\limits_{k=1}^{\left|m s_i\right|} c r_k^j$。最后将所有微服务对每种资源的加权需求进行累加，得到整个系统对于资源j的总体依赖权重$\boldsymbol{\gamma}_j=\sum\limits_{i=1}^{|M|} B_i^j, $，使用这个总体权重得到加权资源方差σ_eq²为

$ \sigma_{\mathrm{eq}}^2=\sum\limits_{j=1}^{|R|} \hat{\boldsymbol{\gamma}}_j \times \sigma_j^2, $

(3)

其中：$\hat{\boldsymbol{\gamma}}_j$是γ_j在归一化后的对应向量。

1.3 多目标优化的部署问题

为解决OMMD问题，需要确立双重优化目标：首先是最小化通信开销，即根据式(2)追求在微服务间传递信息时所需成本的最低化，以减少因数据传输导致的额外延迟和能耗；其次是最小化资源加权方差，根据式(2)，平衡各边缘计算节点上资源占用的不均匀性，通过调整资源分配达到系统负载的均衡状态。通过这两个目标，OMMD问题的模型能在保持服务质量的前提下，优化整体的系统性能和资源利用率。部署问题的优化目标为

$ \begin{aligned} & \text { s. t. } C 1: \sum\limits_{e_k \in E} \sum\limits_{c_i \in C} p_i^k q_i^j \geqslant 1, \forall m s_j \in M S, \\ & C 2: \sum\limits_{j=1}^N p_{i, j}^E+p_i^C \geqslant 1, \forall i \in C, \\ & C 3: \sum\limits_{c_i \in C} p_{i, k}^E c r_i^j \leqslant O R_k^j, \forall e_k \in E, \forall O R_i^j \in O R_i, \\ & C 4: \sum\limits_{c_i \in C} p_i^C c r_i^j \leqslant O R_C, \forall j \in\{1, 2, \cdots, |R|\}, \end{aligned} $

式中：约束C1表示保证为每个微服务至少部署一个容器，若容器i属于微服务j，则q_i^j值为1，否则为0；约束C2表示每个容器至少要部署在一个节点上(不论是云节点还是边缘节点)；约束C3表示一个边缘节点上的容器占用的资源不能超过其容量；约束C4表示容器占用云节点的资源不超过云节点的资源容量。

1.4 多目标优化联合成本

根据1.3节所述最优部署问题，为共同优化最小化通信开销以及方差两个指标，达到多目标优化效果，使用归一化来进行多目标优化联合成本Cost的计算，即

$ { Cost }=\alpha \times { Com }+(1-\alpha) \times \sigma_{e q}^2 \text { 。} $

部署过程中根据算法1计算联合成本Cost。

算法1  部署过程的联合成本算法

输入：微服务之间的权重因子W；微服务的容器集合C；节点之间的通信距离L；资源方差σ²；在计算不同资源方差时的权重向量γ；状态S_t；动作a_t；计算联合成本时的权重因子α。

输出：联合成本Cost。

1) begin

2) 接收动作a_t，将状态S_t转到S_t+1

3) 根据式(1)计算系统中每两个微服务的交互权重

4) 计算微服务在容器之间通信产生的总开销

5) 计算微服务的通信开销

6) 根据式(2)计算整个系统的通信开销

7) 根据式(3)计算负载均衡资源方差

8) 归一化，计算联合成本Cost

9) end

2 基于强化学习的微服务部署方法

本文基于深度Q学习方法进行改进，引入奖励共享机制来实现最优部署。深度Q学习(DQL)是一种利用深度学习技术解决Q学习问题的方法^[18]。在DQL中，奖励基于单独的动作和状态转移计算，无法在所有微服务部署完毕之前准确评估奖励，导致模型收敛速度慢且不稳定。为此，可以借鉴时序差分学习(temporal difference learning)^[19]中TD(λ)方法的思想，通过未来状态的估计值来更新当前状态的价值。同时共享奖励机制类似于策略梯度方法^[20]中的优势函数，通过引入全局的策略评估结果，将最终奖励传播到每个步骤，优化每个局部策略的更新过程。而优先级经验回放^[21]通过为重要经验样本分配更高的更新优先级，进一步提高了样本利用效率。

2.1 MORE-DQL算法设计

MORE-DQL算法由MORE-DQL智能体、环境和状态三部分组成。该算法的目标是通过与环境的动态互动来探索并学习最优部署策略，其框架见图 2。具体MORE-DQL算法见算法2。

算法2  MORE-DQL算法

输入：迭代次数E；每次迭代步数T；系统状态集合S；动作集合A；下一个状态的集合NS；迭代完成标志IsDone；折扣因子γ；学习率ε；批量大小batch；目标Q网络更新频率K；Q网络Q(ϕ, a; θ)；目标Q网络$\tilde{Q}(\phi, a ; \widetilde{\theta})$。

输出：Q网络参数。

1) begin

2) 初始化S，Q，Q的参数和$\tilde{Q}$，回放池P

3) for迭代次数episode=1, 2，…，E do

4)     初始化状态s₁，特征向量ϕ (s₁)

5)     for迭代步数t=1, 2, …, T do

6)         以概率ε选择随机行动a_t，否则选择a_t=argmax_aQ(ϕ(s_t), a; θ)

7)         根据算法1得到联合成本Cost，执行a_t，得到完成标志done和下一状态的特征向量ϕ(s_t+1)

8)         将ϕ(s_t), a_t, ϕ(s_t+1), done_t分别存入S, A, NS, IsDone集合中

9)         设置s_t←s_t+1

10)       if t=T then

11)           计算最后一步奖励r

12)           for每一步i=1, 2, …, T do

13)                将转换的(S[i], A[i], r, NS[i], IsDone[i])存储进P

14)           end for

15)           end if

16)           从P中随机选取batch大小的转换(ϕ(s_j), a_j, ϕ(s_j+1), done_j)

17)           if done_j(j已完成)then

18)                将y_j←r_j

19)           else

20)                将$y_j \leftarrow r_j+\gamma \cdot \tilde{Q}\left(\boldsymbol{\phi}\left(s_{j+1}\right), a^{\prime} ; \tilde{\theta}\right)$

21)           end if

22)           对损失函数$\left(y_j-Q\left(\boldsymbol{\phi}\left(s_j\right), a_j ; \theta\right)\right)^2$执行梯度下降，更新网络参数θ

23)           每隔K步重置$\tilde{\theta}=\theta$

24)           end for

25)           清空S, A, NS, IsDone

26)        end for

27)        end

2.2 MORE-DQL复杂度分析

假设神经网络的深度为d，每层的最大神经元数量为n，则每次前向传播的时间复杂度为O(d ·n²)。在一个训练回合中，有T个时间步，则Q值更新的总时间复杂度为O(T ·d ·n²)。从经验回放池中采样小批量数据进行训练。假设每批次采样的大小为B，采样时间复杂度为O(B)。对于每个采样样本，总的经验回放时间复杂度为O(B ·d ·n²)。对于|C|个容器和N个边缘节点，概率转移矩阵中计算Softmax函数的时间复杂度为O(|C| ·N)。即在一个训练回合中，计算概率转移矩阵中Softmax函数的总时间复杂度为O(T · |C| ·N)。综合以上部分，MORE-DQL算法的总体时间复杂度为

$ O\left(T \cdot d \cdot n^2+B \cdot d \cdot n^2+T \cdot|C| \cdot N\right)。$

3 实验与性能分析 3.1 Kubernetes集群部署

本实验基于心血管健康监测(CHM)开源应用程序实现。实验中的云边计算平台是由虚拟机组成的小规模云边平台，使用Kubernetes作为微服务管理工具。不同的虚拟机实例分为8核、16 GB内存、50 GB磁盘、64位CentOS 7.4核的云节点以及4核、4 GB内存、20 GB磁盘、64位CentOS 7.4核的边缘节点。

云节点管理和控制整个集群，负责服务发现、服务管理、服务部署等。边缘节点可以接收云节点分配的资源数据，并负责运行容器。云节点根据Kubernetes的默认策略或用户自定义策略来管理微服务。

初步部署过程的Kubernetes集群包括一个云节点和5个边缘节点。CHM应用程序由6个Docker容器部署，紧急诊断服务需要的实例数往往更多，因此本文将紧急诊断微服务的初始实例数设定为3个，其他三类微服务的初始实例数为1个。每个容器的资源需求如表 1所示。

边缘节点之间的距离从集合{1, 2, 3, 4}中随机选取，设定云节点到边缘节点的物理距离为10。现根据实验具体需求，将微服务对资源的加权依赖权重β设置为(0.3, 0.2, 0.5, 0.2)，将在计算联合成本时的权重因子α设置为0.5，学习率τ设置为0.001, 奖励折扣因子γ设置为0.9，将智能体的学习数据量batch设置为30。

3.2 微服务交互权重分析

本文提出了基于交互感知的无向加权交互图，并以微服务间通信流量的相对值作为计算通信开销的指标。

在并发请求数为50的情况下，每15 s监视一次CHM的通信流量，并在60 min内获得结果。根据图 3中展示的240次微服务交互权重监测结果，本文将相互作用权重设置为w₁₂=w₁₃=1, w₁₄=2, w₂₃=3, w₃₄=4。

3.3 多目标优化性能验证

文献[12]中的动态资源分配部署(DIM)和Kubernetes默认(DE)方法被证明是有效的基准方法。DIM方法旨在最小化微服务间的通信开销，选用DIM进行对比可以评估MORE-DQL算法在通信开销最小化的效果。DE方法将微服务均匀分布在所有可用节点上。通过对比，可以评估MORE-DQL算法尤其是在响应时间方面的改进。

使用MORE-DQL、DIM和DE对CHM的四个微服务进行部署，之后Kubernetes向CHM发送请求，并监控每个节点的响应时间等占用情况，以验证不同方法的微服务执行性能。

图 4显示了三种策略下的微服务初步部署情况。图中可见DE在每个节点上都部署了容器，但忽略了微服务之间本身的交互，会增加通信成本；DIM选择将所有容器部署在同一节点上，但可能会有空闲节点，造成可用资源浪费。

图 3中展示的240次微服务交互权重监测结果显示，w₃₄的值最大，说明ms₃和ms₄的交互最频繁，MOER-DQL选择在同一节点上部署了两个紧急诊断微服务容器和预测微服务容器，将其他容器部署在其他节点上，以减少由于容器集中部署在一个节点上而导致业务执行性能下降的影响。

3.4 响应时间性能验证

为了对比三种策略的性能，本文将MORE-DQL与DIM、DE的响应时间进行了对比。

图 5展示了MORE-DQL算法与DE和DIM在TP90(90%响应时间)和TP95(95%响应时间)的响应时间表现。随着并发请求数量的增加，DE和DIM响应时间随并发请求数量增加而上升，但整体趋势DIM比DE算法更稳定，且增长速度较慢。而在所有测试的并发请求数量下，MORE-DQL算法的响应时间最低，表现出较佳的性能和稳定性。

从以上分析可以看出，在三种策略的对比中，MORE-DQL算法在处理高并发请求时具有明显的优势，其响应时间在并发请求数量增加时增长缓慢，表现出良好的扩展性和稳定性。

3.5 MORE-DQL收敛性验证

为了说明引入奖励优化机制的优势，本文将MORE-DQL模型与经典的DQN模型进行对比。其中，在每轮训练中，模型的参数都会根据算法2不断更新来开启下一轮训练，以观察模型在不同训练轮次中的表现和稳定性。

图 6给出了两种模型在6个训练过程的联合成本的收敛变化。在使用MORE-DQL进行训练时，联合成本在波动中逐渐减小并最终收敛到最小值，而DQN的联合成本波动剧烈且不规则。在DQN中，奖励的计算通常基于当前状态和动作的即时奖励^[22]，采用同一方法的不同训练回合可能导致奖励值差异较大，使得Q网络参数的更新变得混乱。而MORE-DQL算法通过将迭代中每个最后一步的奖励共享给所有步骤，改进了中间步骤的奖励值，有助于引导Q网络参数更优地收敛，并适应了微服务部署过程的特定需求。

4 结语

本文针对边缘环境的微服务部署方法进行了调查研究, 提出了边缘计算中的最优多目标微服务部署OMMD问题。为了求解该问题，设计了微服务优化奖励深度Q学习MORE-DQL算法，提出共享奖励机制，使算法拥有更好的收敛性。将MORE-DQL算法与DIM方法和Kubernetes方法相比较，本文所提MORE-DQL算法服务响应时间更短，且更能综合考虑微服务的交互频率以及边缘节点的资源分配与利用。