配电物联网台区边缘计算终端微服务的文件锁数据同步机制

岑伯维，胡春潮，2，蔡泽祥，武志刚，屈 径，刘媛媛

（1. 华南理工大学电力学院，广东省 广州市 510641；2. 中国南方电网电力科技股份有限公司，广东省 广州市 510080）

0 引言

在“双碳”目标的驱动下，新型电力系统在接入对象［1］、时空特性［2］、信息特性［3］等方面产生了显著的变化。接入对象类型的扩展、时空管控范围的延伸及多源异构数据的激增给配电自动化系统的信息感知和分析处理能力带来了挑战［4］。近年来，以低压配电台区为单位的自动化、数字化改造逐步开展，基于配电物联网边缘计算理念的新一代智能配电台区成为建设路径之一［5-6］。

边缘计算终端是新型智能配电台区的关键节点［7］，为满足配电台区业务灵活组织和高效管理的需求，微服务逐渐成为构建以边缘计算终端为载体的新型配电台区业务的关键技术之一［8］。与单体应用相比，微服务的种类更加多样，运行机制更加灵活［9-10］，但这同时也增加了微服务数据读写冲突的隐患。当微服务之间发生数据读写冲突时，极有可能造成数据错误、错乱、丢失等问题［11］，进而导致边缘计算终端无法正常完成业务。此外，由数据可靠性下降所带来的潜在风险隐患易通过信息-物理耦合网络进一步影响一次系统的安全稳定运行［12-13］，甚至引起连锁事故的发生［14-15］。因此，研究边缘计算终端微服务的数据同步机制具有十分重要的意义。

目前，关于数据同步机制已有相关的研究，文献［16］和文献［17］研究多活数据同步机制，通过阶段性地同步传输业务计算结果至其他分析决策中心，提高业务执行时数据的可靠性。然而，所设计的机制主要用于决策中心故障时业务计算无缝切换场景，若将该机制用于解决微服务数据读写冲突问题易造成数据的冗余备份。文献［18］设计了一种历史数据服务优化方案，利用数据缓冲区模块存放数据，利用缓存数据同步模块同步关系库和缓存区的数据。然而，微服务间具有时序逻辑关系，基于队列原理的同步机制虽能用于解决微服务数据读写冲突问题却易增加业务完成时间。以时序逻辑［19］为约束的微服务组织方式相较于彼此相互独立的单体应用而言，数据读写冲突问题更为复杂，现有方法无法提供直接处理的手段。

文件锁是实现进程同步与互斥的手段［20-21］，本文将文件锁应用于解决边缘计算终端微服务的数据读写冲突问题并建立其相应机制。本文的主要创新和贡献如下：1）设计了边缘计算终端微服务的文件锁数据交互机制，支撑微服务数据的有序存取；2）提出了同步分区机制对微服务进行区域划分，消除跨分区微服务的数据读写冲突隐患；3）提出了分区内同步机制和分区间同步机制，解决相同分区内和相邻分区间微服务的数据读写冲突；4）本文工作亦在数据读写可靠性和实时性层面为微服务数据同步机制的工程研发设计和技术方案的选定提供参考依据。

1 边缘计算终端微服务的文件锁数据交互机制

1.1 层次结构与时序逻辑模型

微服务是云原生技术体系中的一种应用程序的软件架构，本文所提配电物联网台区边缘计算终端是云原生技术在电力系统边缘侧应用的重要载体之一，具有就地采集分析控制［22］、微服务灵活更新部署［23］、终端功能软件定义［24］、业务多元化生态化［25-26］的特点和优势，与软硬件强耦合的传统配电终端相区别。

本文边缘计算终端微服务的层次结构如附录A图A1 所示。其中，业务功能类微服务由边缘计算终端的应用开发商研制，负责支撑配电台区边缘计算终端业务的实现，可再细分为采集类、分析类、控制类微服务。系统功能类微服务由边缘计算终端的系统开发商研制，负责为上层的业务功能类微服务提供后台支撑和管理手段。配电台区边缘计算终端的不同类微服务可由不同厂家设计，有利于发挥各研发团队的优势和促成各类厂家参与的格局，为形成开放创新的行业新生态带来了机遇［27］。

本文配电物联网台区边缘计算终端主要面向分布式光伏、储能系统、充电桩等低压增量接入对象及其相关新型配电台区业务（例如需求侧响应、配电网监控、配电网保护、拓扑识别等）。这些业务一般具有采集、分析、控制等环节，本文将以文献［8］中电价型负荷响应业务的微服务时序逻辑图为例阐述后续所提出的机制，具体如附录A 图A2 所示。该业务包含7 个微服务，具体业务流程如下：

首先，由负荷数据采集类微服务解析负荷数据，由电量电价采集类微服务解析负荷用电量与电价关系曲线的形状系数，由峰谷电价采集类微服务解析分时电价；接着，负荷预测分析类微服务利用解析的负荷数据进行短期负荷预测，弹性矩阵分析类微服务利用电量电价曲线形状系数和分时电价数值计算出负荷响应的弹性系数；最后，负荷响应分析类微服务利用负荷预测、弹性系数和分时电价结果计算负荷响应量大小，由负荷控制类微服务形成负荷控制信号。

在实际系统中，配电物联网台区边缘计算终端的数据来源于智能电表、传感器和云主站等，边缘计算终端业务通过部署于边缘计算终端的各类微服务完成相应的数据处理、决策分析和就地控制。本文主要研究边缘计算终端微服务的文件锁数据同步机制，解决数据读写冲突问题。

1.2 文件锁状态转移模型

边缘计算终端微服务的文件锁主要分为读锁和写锁两种。读锁又称为共享锁，当微服务加读锁时，则可对数据库表进行读操作。写锁又称为排斥锁，当微服务加写锁时，则可对数据库表进行写操作。文件锁的类型决定了微服务拥有的读写操作权限，合理有序的文件锁加锁保证了微服务数据的可靠有序读写。建立的边缘计算终端微服务的文件锁加锁规则如附录A 表A1 所示。

然后，建立微服务的文件锁状态转移模型，如附录A 图A3 所示。其中共有6 种状态，包括无加锁状态、加读锁状态、加写锁状态、解锁状态、阻塞状态、等待状态。微服务的文件锁状态转移过程可总结为3 种。1）正常读-写的状态转移过程为：无加锁状态→加读/写锁状态→解锁状态→无加锁状态；2）读-写排斥的状态转移过程为：无加锁状态→加读锁→阻塞→等待→加读锁→解锁→无加锁状态；3）写-读、写-写排斥的状态转移过程为：无加锁状态→加写锁→阻塞→等待→加写锁→解锁→无加锁状态。

1.3 文件锁数据交互机制

受电力系统保护开关接线的启发，本文在建立的微服务层次结构、时序逻辑模型和文件锁状态转移模型的基础上，设计了边缘计算终端微服务的文件锁数据交互机制，用于支撑微服务数据的有序存取。边缘计算终端微服务的文件锁数据交互机制如图1 所示。

图1 边缘计算终端微服务的文件锁数据交互机制Fig.1 File lock based data interaction mechanism for microservices of edge computing terminal

配电台区边缘计算终端业务所含微服务都会经历从数据库读取数据、执行微服务和将数据写入数据库的过程。读写数据流母线将与闭合的一组读锁开关或写锁开关共同构成微服务与数据库间的数据流通路径。数据库是数据存放的仓库，采用垂直分库和水平分表相结合的方式构建，通过垂直分库可创建多个数据库，每个数据库中存放同类微服务的数据，通过水平分表可在每个数据库内创建多个表，每个表中存放不同配电台区边缘计算终端业务的微服务数据。

若没有微服务的文件锁数据同步机制，微服务的数据读取开关和写入开关则根据微服务自身读写需求闭合，易造成数据读写冲突问题，尤其在多微服务场景中更为显著。通过微服务的文件锁数据同步机制，使得各微服务的数据读取开关和写入开关合理有序闭合，从而避免微服务数据读写冲突，保证配电台区边缘计算终端业务的正常完成。

2 边缘计算终端微服务的文件锁数据同步机制

本文为了解决微服务的数据读写冲突问题，提出了边缘计算终端微服务的文件锁数据同步机制，所提出机制包括微服务分区机制、分区内同步机制和分区间同步机制。微服务的文件锁加锁不仅受微服务时序逻辑的影响，还受微服务所处同步分区、微服务类型、读写时间等的影响，是多因素耦合的复杂问题。而所提出机制充分考虑了这些影响，并能有效避免微服务的数据读写冲突。为了便于读者理解，本文继续以配电台区边缘计算终端电价型负荷响应业务为示例阐述所提出机制。

2.1 边缘计算终端微服务的分区机制

2.1.1 分区机制

本文提出的边缘计算终端微服务的分区机制共有3 个步骤：1）根据微服务时序逻辑图中的横向前向路径最大微服务数，获取分区列数；2）根据微服务时序逻辑图中的纵向最大微服务数，获取分区行数；3）依次将微服务时序逻辑图中的所有前向路径上的微服务填入分区空位中，已填写的微服务不再填写。

依据提出的分区机制，对配电台区边缘计算终端电价型负荷响应业务中的微服务进行同步分区，结果如图2 所示。图2 中共有7 个微服务，分别为微服务1（1.负荷数据微服务）、微服务2（2.电量电价微服务）、微服务3（3.峰谷电价微服务）、微服务4（4.负荷预测微服务）、微服务5（5.弹性矩阵微服务）、微服务6（6.负荷响应微服务）、微服务7（7.负荷控制微服务）。图2 中的前向路径①具有的最大微服务数为5，因此共有5 列，每列代表一个分区。图2 中，纵向最大微服务数为2，因此共有2 行。将前向路径①中的微服务1、3、5、6、7 填入第1 行，将前向路径②中的微服务2 和微服务4 填入第2 行，剩余空位不填写，最终得到了同步分区结果。图中微服务间连线表示各微服务的前置关系。

图2 微服务的同步分区机制示意图Fig.2 Schematic diagram of synchronization partitioning mechanism for microservices

2.1.2 同步矩阵

微服务的文件锁数据同步矩阵包括类型矩阵A、分区矩阵B和前置矩阵C。

类型矩阵A用于刻画各微服务所属的类型，记微服务个数为n，则类型矩阵A为1×n矩阵。矩阵元素1、2、3 分别表示采集类、分析类、控制类。

分区矩阵B用于刻画各微服务所属分区，记微服务个数为n，则分区矩阵B为1×n矩阵。若微服务i与微服务j同属于分区k，则将分区矩阵B的第i和第j列元素置为k。

前置矩阵C用于刻画各微服务的前置微服务，记微服务个数为n，则前置矩阵C为n×n矩阵。若微服务i是微服务j的前置微服务，则将前置矩阵C的第i行第j列元素置为1。

2.2 边缘计算终端微服务的分区内同步机制

2.2.1 分区内同步机制

因文件锁中的读锁具有共享特性，同一分区内的同一类微服务可同时读取相同的数据库表。同一分区内的不同类微服务因读取的数据库表不同，不存在冲突。因此，分区内微服务的数据读取过程不冲突。

因文件锁中的写锁具有排斥特性，同一分区内的同一类微服务不允许同时向相同的数据库表写入数据。同一分区内的不同类微服务因写入的数据库表不同，不存在冲突。因此，建立分区内同步机制解决同一分区内的同类微服务同时写入的冲突风险。

现以分区1 的微服务1 和微服务2 为例阐述分区内同步机制，如图3 所示，该图中共有2 种情况。假设微服务1 的数据读取和微服务执行时间之和小于微服务2，则微服务1 需要先写入数据，因此先加写锁。微服务2 在微服务1 写入数据过程中不允许加写锁，因此，需要等待微服务1 写入解锁后才可加写锁写入数据，如图3 中第1 种情况所示。若微服务1 在微服务2 执行完成前写入完毕，则微服务2 无须等待可直接写入，如图3 中第2 种情况所示。

图3 分区内同步机制示意图Fig.3 Schematic diagram of in-area synchronization mechanism in partition

2.2.2 分区内同步时间模型

分区内同步时间模型用于刻画分区内同步机制下各微服务文件锁加锁的时序配合过程，具体如下：

式 中：Tini，h，a，m、Trl，h，a，m、Tro，h，a，m、Tex，h，a，m、Twl，h，a，m和Two，h，a，m分 别 为 分 区h的 第a类 微 服 务 中 的 第m个 微服务的起始时间戳、加读锁时间戳、解读锁时间戳、执行完成时间戳、加写锁时间戳和解写锁时间戳；tc，h，a，m、tr，h，a，m和tw，h，a，m分 别 为 分 区h的 第a类 微 服 务中的第m个微服务的执行时长、读取时长和写入时长；dr，h，a，m和dw，h，a，m分 别 为 分 区h的 第a类 微 服 务 中的第m个微服务的读数据量和写数据量；αr和αw分别为读取和写入时长系数。

2.3 边缘计算终端微服务的分区间同步机制

2.3.1 分区间同步机制

为了避免微服务跨分区的读写冲突风险，需建立分区间同步机制，分区间同步机制包括了前置同步和非前置同步2 种。

1）前置同步机制

前置同步机制是指微服务需要等待其所有前置微服务完成写入后才可加读锁读取数据，从而避免微服务的读写冲突。

现以分区1 和分区2 的微服务为例阐述前置同步机制，如图4 所示。微服务1 和微服务2 均为微服务3 和微服务4 的前置微服务，当微服务1 完成数据写入后微服务3 和微服务4 准备加读锁读取数据。但此时，微服务2 准备加写锁写入数据，将造成微服务的读写冲突。此时，微服务3 和微服务4 均需等待其前置微服务1 和微服务2 完成写入后才加读锁。

图4 前置同步机制示意图Fig.4 Schematic diagram of pre-synchronization mechanism

2）非前置同步机制

非前置同步机制是指处于后一分区的微服务需等待前一分区同类微服务和与其前置微服务同类的微服务完成写入后才可开始加读锁读取数据，从而避免微服务的读写冲突。

现以分区2 和分区3 的微服务为例阐述非前置同步机制，如图5 所示。当微服务3 完成数据写入后，微服务5 准备加读锁读取数据，但此时微服务4准备加写锁写入数据，将造成微服务的读写冲突。此时，微服务5 的前置微服务为微服务3，微服务4为微服务5 的前一分区内同类微服务，因此，微服务5 需等待微服务3 和微服务4 完成写入后才可以开始加读锁。因非前置同步与前置同步在时序配合方法上相似，在后续文件锁加锁时间模型中，微服务4也可视作微服务5 的前置微服务来计算。

图5 非前置同步机制示意图Fig.5 Schematic diagram of non-pre-synchronization mechanism

2.3.2 分区间同步时间模型

分区间同步时间模型用于刻画分区间同步机制下各微服务文件锁加锁的时序配合过程，具体如下：

式中：pj和pk分别为微服务j和微服务k；ckj为前置矩阵C中 第k行 第j列 元 素；Two，cr，h，pk为 分 区 间 同 步 机制 下 分 区h内 微 服 务k的 解 写 锁 时 间 戳；Tini，cr，h+1，pj、Trl，cr，h+1，pj、Tro，cr，h+1，pj和Tex，cr，h+1，pj分 别 为 分 区 间 同 步机制下分区h+1 内微服务j的起始时间戳、加读锁时 间 戳、解 读 锁 时 间 戳、执 行 完 成 时 间 戳；tr，cr，h+1，pj、tc，cr，h+1，pj和dr，cr，h+1，pj分 别 为 分 区 间 同 步 机 制 下 分 区h+1 内微服务j的读取时长、执行时长和读取数据量。

3 边缘计算终端微服务的文件锁加锁方法

边缘计算终端微服务的文件锁加锁结果求解流程如附录A 图A4 所示。本文文件锁的加锁不仅受时序逻辑的影响，还受微服务所处同步分区、微服务类型、读写时间等的影响。通过所提出方法，可以获得在本文微服务文件锁数据同步机制下，各微服务加读锁、解读锁、执行完成、加写锁、解写锁的时间戳。

本文所提出机制的适用性分析：首先，本文每个配电台区边缘计算终端的业务由微服务构成，微服务间具有时序逻辑性，而不同时序逻辑结构均可采用本文4 种类型的支路构成，因此时序逻辑图的构成是完备的。接着，本文提出的同步分区机制是在时序逻辑图的基础上，依据所有前向路径，将微服务进行分区，因此对于不同的时序逻辑图而言，同步分区机制依然适用。最后，本文文件锁的加锁不仅受时序逻辑的影响，还受微服务所处同步分区、微服务类型、读写时间等的影响，所提出分区内同步和分区间同步机制均充分考虑了这些影响，并已给出了讨论分析。因此，本文所提出机制对于其他具有微服务时序逻辑的配电台区边缘计算终端业务仍具有适用性。

本文所提出机制的技术实现与实时性分析：本文同步分区机制与微服务执行延时无关。本文分区内同步机制避免微服务同时写入冲突的方法，在技术实现中采用写入请求先到先写的方式来实现先执行完的微服务先加写锁写入数据，不依赖于微服务执行延时为确定值。本文分区间同步机制避免微服务读写冲突的方法，在技术实现中采用事件中断的方式来实现每个微服务在其前置微服务写锁解锁后加读锁读取数据，也不依赖于微服务执行延时为确定值。因此，所提出机制的有效性不依赖于微服务执行延时为确定值。而本文算例分析为了更好让读者易懂，以微服务延时为确定值的方式展示本文机制的有效性。此外，所提出机制的同步耗时受微服务数量、微服务时序逻辑结构、微服务分解度的影响，本文工作正为分析这些影响和降低同步耗时提供了手段，且所提出机制是解决边缘计算终端数据读写冲突的一种直接有效手段，与微服务轻量级理念相一致。因此，所提出机制在适应实时性业务方面仍具有优势。

4 算例分析

4.1 仿真参数

本文以配电台区边缘计算终端电价型负荷响应业务的微服务时序逻辑图为例进行文件锁数据同步机制有效性的验证和算例分析，具体如附录A 图A2所示，仿真参数如表A2 所示。表中包含了业务所含各微服务、读取数据量、写入数据量、执行时长及相应矩阵。本文在MATLAB 软件环境上搭建面向配用电物联网边缘计算终端微服务的仿真平台，硬件环境为：CPU 型号为Intel Core i7-9700，GPU 型号为AMD Radeon R7 430，内存容量为8 GB。

4.2 边缘计算终端微服务的文件锁加锁结果

采用本文边缘计算终端微服务的文件锁数据同步机制，得到各微服务的文件锁加锁结果如附录A表A3 所示。表中展示了各微服务的加读锁、解读锁、执行完成、加写锁和解写锁状态的时间戳。

由附录A 表A3 可知，微服务1 在0.152 0 s 执行完成，微服务2 在0.151 5 s 执行完成，微服务2 先于微服务1 执行完成，先加写锁。微服务2 写入数据的时间段为0.151 5 s 至0.154 5 s，由于写锁的排斥特性，微服务1 等待至0.154 5 s 才加写锁，有效避免了写入冲突，验证了分区内同步机制的有效性。

微服务1 和微服务2 均为微服务3 的前置微服务，微服务1 在0.154 5 s 解写锁，微服务2 在0.158 1 s 解写锁，在分区间同步机制下微服务3 需等待至0.158 1 s 加读锁，有效避免了读写冲突，验证了前置同步机制的有效性。

微服务3 为微服务5 的前置微服务，微服务4 为微服务5 的非前置微服务，微服务3 在0.312 6 s 解写锁，微服务4 在0.415 9 s 解写锁，在分区间同步机制下微服务5 需等待至0.415 9 s 加读锁，有效避免了读写冲突，验证了非前置同步机制的有效性。

各类数据库的读写记录如附录A 表A4 所示。表中展示了各微服务对数据库的读、写操作记录和读、写耗时。该读写结果与微服务的时序逻辑具有一致性，说明读写的数据库对象正确。

根据各微服务的写入时刻、写入时长、写入数据量可得到各数据库及边缘计算终端的累计写入数据量，如附录A 图A5 所示。边缘计算终端的累计写入数据量为各数据库累计写入数据量之和。

4.3 时序逻辑结构对文件锁加锁的影响

时序逻辑结构改变后，如附录A 图A6 所示，原本的微服务3 从串联支路移到了并联支路，与微服务2 和微服务3 构成并联支路。采用本文边缘计算终端微服务的文件锁数据同步机制，得到时序逻辑结构改变后的文件锁加锁结果如表A5 所示，累计写入数据量统计结果如图A7 所示。时序逻辑结构改变对数据同步的影响，如表A6 所示。表中，读写耗时占比为读写总耗时与业务期望延时之比，同步耗时占比为同步总耗时与业务期望延时之比，本文该业务期望延时为1 s。

由附录A 表A5 可知，在分区内同步机制下，微服务2 在0.151 5 s 执行完成先加写锁，微服务3 需等待至0.154 5 s 加写锁，微服务1 需等待至0.157 5 s加写锁，有效避免了写入冲突。

微服务4 和微服务5 在分区间同步机制下，在0.161 1 s 加读锁。由于微服务5 在0.312 6 s 执行完成先加写锁，在0.315 0 s 解写锁，而此时微服务4 仍处于执行过程中，无须加写锁，无写入冲突。待微服务4 在0.414 1 s 执行完成后，由于无写入冲突，可直接加写锁写入数据。

由附录A 表A6 可知，时序逻辑结构改变对同步总耗时和业务总时长产生影响。在时序逻辑改变前，同步总耗时为0.105 8 s，业务总时长为0.881 0 s，时序逻辑改变后，同步总耗时为0.008 5 s，业务总时长为0.730 1 s，其原因在于时序逻辑改变后串联支路数量减少有利于同步总耗时和业务总时长的减少。

4.4 采用文件锁数据同步机制前后结果的对比

在时序逻辑结构改变的基础上，本文对比了采用文件锁数据同步机制前后的结果，如附录A 表A7所示。由表A7 可知，没有采用文件锁数据同步机制前虽没有同步耗时开销，但因为存在微服务同时写入或同时读写的现象，形成了冲突时段。而采用文件锁数据同步机制后虽产生了同步耗时的开销，但有效避免了微服务的数据读写冲突问题，提高了数据读写的可靠性。时序逻辑结构改变后，微服务冲突个数从2 个增加至3 个，其原因在于并联支路中微服务的数量增加，而采用文件锁数据同步机制后，仍然能有效避免时序逻辑结构变化后带来的冲突风险。

4.5 考虑不同微服务分解度的结果对比分析

微服务分解度指业务分解为微服务的颗粒度大小，可由业务分解后的微服务数量体现。在附录A图A6 基础上将采集类微服务1、2、3 合并为一个采集类微服务，将分析类微服务4、5、6 合并为一个分析类微服务，则该业务的微服务数量由7 变为3。

本文对比了微服务合并前后的结果，如附录A表A8 所示。表中，读写耗时占比为读写总耗时与业务期望延时之比，同步耗时占比为同步总耗时与业务期望延时之比，本文该业务期望延时为1 s。

由附录A 表A8 可知，微服务分解度对同步总耗时和业务总时长产生影响。合并后的微服务等效于被合并的微服务以串联的方式执行，使同步总耗时减少为0，但却增加了业务总时长。合并后业务的总时长为1.187 5 s，显然已经超出了该业务的期望延时，因此微服务分解度需兼顾同步总耗时和业务延时进行合理设计。

4.6 不同微服务数据同步机制对比分析

本文将所提出的文件锁数据同步机制与队列机制、独立空间机制进行了对比，如附录A 表A9 所示。由表A9 可知，在数据读写可靠性层面，3 种机制均能满足要求；在实时性层面，本文机制介于队列机制和独立空间机制二者之间，队列机制下的业务总时长最大，独立空间机制下的业务总时长最小；在存储空间占用层面，独立空间机制下所需占用的存储空间是本文机制和队列机制的2 倍。因此，综合考虑数据读写可靠性、实时性和存储空间3 个方面，本文机制更具有优势。

采用队列机制和独立空间机制获得的微服务数据读写时间结果分别如附录A 表A10 和表A11 所示。由表A10 可知，在队列机制下各微服务按队列先后顺序从数据库读取数据和写入数据，队列机制保证了微服务数据读写的有序进行，避免数据读写冲突。采用队列机制后，业务完成的时长为0.732 1 s，存储空间占用量与本文机制相同。由表A11 可知，在独立空间机制下各微服务无须等待彼此读取数据和写入数据的完成，从而降低了业务完成的时长。采用独立空间机制后，业务完成的时长为0.724 6 s，虽然微服务通过额外开辟独立存储空间能有效避免数据读写冲突，实时性较强，但却使得存储空间占用增大。

5 结语

本文提出了一种配电物联网台区边缘计算终端微服务的文件锁数据同步机制，用于解决微服务数据读写冲突问题。仿真结果表明，所提出机制能有效避免微服务的数据读写冲突，而微服务时序逻辑结构和微服务分解度均会对数据同步耗时产生影响，合理的微服务时序逻辑结构和微服务分解度有利于减少同步总耗时和业务总时长，更好满足业务延时要求。本文工作为分析这些影响提供了有效手段，也为边缘计算终端的微服务数据同步机制、微服务时序逻辑和微服务分解度的工程研发设计提供参考依据。此外，本文所提出的文件锁数据同步机制相较于队列机制在同步耗时和业务总时长方面更具优势，相较于独立空间机制在存储空间占用上更具优势。

本文工作既为后续研究考虑微服务数据同步机制的计算资源优化配置与调度问题奠定基础，也为后续研究配电台区边缘计算终端云边协同业务的高并发数据同步问题奠定基础。

附录见本刊网络版（http：//www.aeps-info.com/aeps/ch/index.aspx），扫英文摘要后二维码可以阅读网络全文。