2. 江苏虎甲虫计算技术有限公司, 江苏 无锡 214000;
3. 江苏省模式识别与计算智能工程实验室, 江苏 无锡 214122
2. Jiangsu Tiger Beetle Computing Technology Co., Ltd., Wuxi, Jiangsu 214000, China;
3. Jiangsu Provincial Engineering Laboratory of Pattern Recognition and Computational Intelligence, Wuxi, Jiangsu 214122, China
开放科学(资源服务)标志码(OSID):
现场可编程门阵列(Field Programmable Gate Array,FPGA)是一种可由用户定义其硬件架构的“空白芯片”,广泛应用于专用硬件设计、芯片验证等领域,并在计算机组成原理、集成电路设计等课程实验中大量使用[1-2]。但是,传统基于FPGA的实验通常依赖于专用设备,需要人员在指定时间到指定地点完成,影响了实验教学和系统开发的效率。随着互联网技术的发展,出现了不同类型的FPGA云平台,从而推动了FPGA相关技术在更大范围内的应用[3-5],FPGA云平台的系统架构也由耦合度较高、灵活性较差、开发运维成本较高的单体架构逐渐向松耦合、可伸缩、易部署的微服务架构转变[6]。微服务最初由FOWLER等[7]定义,其是对传统单体架构的解耦,将功能拆分成多个不同的服务,便于设计、开发以及运维部署。随着用户请求量的激增,FPGA云平台面临高并发请求的应用场景。单体架构的调用请求都在本地,因此,其网络延迟较低,但在,在高并发请求下,微服务架构的调用可以同时进行且不相互依赖,总执行时间也较短,相较单体架构性能显著提高[8]。
目前,许多学者对微服务架构的云平台并发请求进行了相关研究,这些研究主要分为2个方面。一方面侧重于保证服务质量(Quality of Service,QoS)[9],例如:SHETTY等[10]提出一种具有服务分组的云服务选择机制,基于改进的层次分析法(Analytic Hierarchy Process,AHP)分组选择算法来提高性能,但其仅适用于共享服务调度系统;MENGYU等[11]提出一种支持并发请求的物联网服务组合优化节能机制,该机制可以提高物联网服务在并发请求间的可共享性,但其受限于不同服务之间的粒度影响;郭军等[12]为提高整体的QoS,提出一种主动式突发并发量应对策略GMAC,该策略能预测用户并发量,但其并未进一步给出突发并发量的应对策略。另一方面从负载均衡入手进行研究,例如:AMAL等[13]为保证资源的有效使用,提出一种负载均衡算法,该算法对并发请求用户进行优先级排序;LIU等[14]通过确定综合负载值以衡量资源的利用率,但是其未在真实系统中处理并发请求;ZHOU等[15]提出一种基于微服务边缘计算的负载建模方法,该方法能够优化资源配置和调度,但是其并不通用,局限于特定类型的应用。
上述研究中的相关算法通过减少服务选择的计算时间和重复的存储库访问来提高并发性能,但仅适用于多服务共享调度系统,而FPGA云平台是基于单服务的调度系统,无需进行服务选择。因此,上述算法并不适用于处理FPGA云平台的并发请求问题。
本文基于单服务调度系统下的FPGA云平台,建立一种自定义参数响应指数计算模型,用于计算高并发请求下每个用户对应的响应指数,并基于该模型设计一种高并发请求调度(HCRS)算法。在真实运营的FPGA云平台中使用用户数据进行测试,以验证该算法的平均响应延时、系统吞吐量等性能。
1 基于微服务架构的FPGA云平台微服务架构按照业务边界进行细粒度的拆分以及部署,其将一个大型且复杂化的单体架构应用拆分出多个松耦合的微服务[16]。因此,本文在设计FPGA云平台时根据实际业务需求从单体架构模式下的平台上拆分出节点资源管理这一核心功能,并将其作为一个独立的微服务,它的特点是能够随时拥有整个集群的使用状况,并且能以全局视角选择合适的节点进行任务分配。微服务通过轻量级通信框架REST(Representational State Transfer)与外界进行通信[17],同时支持通过不同技术或平台来实现。
1.1 FPGA云平台架构FPGA云平台主要由Web应用层以及节点资源管理微服务组成,其系统架构及关键组件如图 1所示,终端用户可以在不同设备上使用网络浏览器访问FPGA云平台、在云平台上申请使用节点、检查FPGA硬件节点实时执行状态等。
![]() |
Download:
|
图 1 FPGA云平台系统架构 Fig. 1 FPGA cloud platform system architecture |
Web应用层含有心跳机制[18],该心跳机制用于检查用户申请到的节点是否长时间处于未使用状态,若用户在一段时间内未发送心跳包,则自动释放节点,未使用的这段时间即为用户空置时间。节点资源管理微服务主要负责管理节点的状态。上述两者均使用ELK(Elasticsearch,Logstash,Kibana)[19]日志平台进行日志采集与分析,并通过RESTful API进行通信,客户端发起请求经过反向代理服务器(Nginx)处理,对微服务接口添加JWT(Json Web Token)访问认证机制,以保证接口的安全性,并对节点使用界面Jupyter notebook配置安全策略,保障硬件节点使用安全。数据存储层则使用关系型数据库Mysql以及非关系型数据库Redis。
1.2 节点资源管理微服务节点资源管理微服务包含6个主要功能,分别为服务注册发现、节点申请、节点释放、节点实时状态查询、节点系统重置、节点定时测试。微服务架构如图 2所示,底层采用Python编写的Web应用框架Tornado(Tornado Web Server),控制层为RM Server节点状态控制器。微服务为节点定义了6种状态,分别为Boot(初始态)、Testing(测试态)、Valid(可用态)、Busy(占用态)、Resetting(重置态)、Broken(故障态),节点状态控制器的作用即为管理这6种状态的逻辑转换,其中,在申请和释放这2个操作时需加入互斥锁来解决资源同步与互斥问题。业务逻辑层为上述各个功能的具体实现,并对功能进行封装,将封装好的服务以接口的形式,利用通信层RESTful API与Web应用层进行通信,便于Web应用层调用接口。
![]() |
Download:
|
图 2 节点资源管理微服务架构 Fig. 2 Node resource management microservice architecture |
在微服务架构下的FPGA云平台实际应用场景中,由于FPGA服务器硬件节点个数有限,当大量用户在同一时间并发申请节点时,请求响应时间将延长,此时无法满足所有用户的请求,微服务节点资源被占满甚至直接导致微服务宕机。高并发请求过程如图 3所示。
![]() |
Download:
|
图 3 高并发请求过程 Fig. 3 High concurrent request process |
本文从节点资源管理微服务的高并发请求实际应用场景出发,建立自定义参数响应指数计算模型,确保能够准确描述每个用户申请节点请求的优先级顺序。在此基础上,提出一种高并发请求调度算法HCRS,以实现节点资源合理分配并优化微服务质量。
2.1 参数设置及权重确定 2.1.1 参数设置为解决FPGA云平台上的用户申请节点高并发控制问题,本文从优先级调度入手,分析用户申请操作的关键影响因素,将这些影响因素作为自定义参数,具体如表 1所示,其中:用户计划使用时间表示被申请节点预计占用时长;历史使用平均时长用来评估用户历史使用频率;历史空置时间用来衡量用户是否高效使用节点。
![]() |
下载CSV 表 1 自定义参数及其含义 Table 1 User-defined parameters and their meanings |
本文采用AHP确定自定义参数的权重。AHP是一种定性和定量分析相结合的决策方法,具有系统、灵活及简洁的优点。在解决实际问题时,AHP处理问题的思路与人的决策思维较为相似。AHP有4种权重计算方法,而4种计算方法得出的权重向量一般比较接近,仅有细微差别[20],因此,本文选取其中的算术平均法来计算权重。
结合本文应用场景,AHP可以根据各个自定义参数的重要级别对其进行排名,从而得出参数的权重大小。AHP定义的重要程度及其对应数值如表 2所示。
![]() |
下载CSV 表 2 参数重要程度及其对应的数值 Table 2 Parameters importance and its corresponding value |
根据表 2所示的比较标准,对上述自定义的5个参数,即用户计划使用时间、是否为会员、用户计划申请节点数量、用户历史使用平均时长以及用户历史空置时间进行比较,得出如表 3所示的判断矩阵。根据判断矩阵[21]计算各个参数对应的权重,本文使用Python实现AHP分析的完整过程,首先对判断矩阵进行一致性检验,检验通过方可进行权重计算,AHP计算权重的算法描述具体如算法1所示。
![]() |
下载CSV 表 3 判断矩阵 Table 3 Judgment matrix |
算法1 AHP计算权重算法
输入 判断矩阵
输出 参数权重大小
1.AHP(criteria);
2.max_eigen,CR,criteria_eigen ← weight_func(criteria);
3.if CR < 0.1 //一致性检验
4.else
5.end if;
经过AHP求得各参数权重具体为:W1=0.1;W2=0.4;W3=0.1;W4=0.2;W5=0.2。
2.2 模型建立 2.2.1 响应指数函数定义FPGA云平台在上线运行过程中将面临海量用户的注册登录以及申请节点等操作,此时会产生响应速度慢、响应延时长、长时间申请不到节点等问题。为此,本文建立一种自定义参数响应指数计算模型,该模型主要用于对每个用户的申请输入参数进行分析计算,对应的申请节点请求响应指数计算公式如式(1)所示:
$ \begin{array}{l}F\left(y\right)={W}_{1}^{}\cdot {X}_{\mathrm{p}\mathrm{l}\mathrm{a}\mathrm{n}}+{W}_{2}^{}\cdot {X}_{\mathrm{v}\mathrm{i}\mathrm{p}}+{W}_{3}^{}\cdot {X}_{\mathrm{n}\mathrm{o}\mathrm{d}\mathrm{e}\mathrm{n}\mathrm{u}\mathrm{m}}+\\ {W}_{4}^{}\cdot {X}_{\mathrm{h}\mathrm{i}\mathrm{s}\mathrm{a}\mathrm{v}\mathrm{g}}+{W}_{5}^{}\cdot {X}_{\mathrm{e}\mathrm{m}\mathrm{p}\mathrm{t}\mathrm{y}}\end{array} $ | (1) |
其中:y为响应指数;W1~W5为参数对应的权重;
本文模型模拟用户通过Web应用层发起申请节点请求,在传递相应的请求参数后,需要根据响应指数阈值对所有用户进行区分,设置最佳的上限和下限阈值极为重要,其有助于实现微服务的自动伸缩[22]。因此,本文模拟5组不同数量的用户并发登录及申请节点请求,分别计算其响应指数,并使用IBM SPSS Statistics开源工具对数据进行分析,具体阈值数据分析结果如表 4所示。5组数据均保留小数点后一位,则平均响应指数α=0.2,最低响应指数β=0.1。
![]() |
下载CSV 表 4 阈值分析结果 Table 4 Threshold analysis results |
在FPGA云平台环境中,为了进一步分析用户高并发申请节点时系统的整体性能以及用户申请节点情况,本文引入下列参数作为衡量指标:
1)用户请求响应时间Tu,其计算公式如式(2)所示:
$ {T}_{\mathrm{u}}={T}_{\mathrm{c}\mathrm{s}}+{T}_{\mathrm{s}}+{T}_{\mathrm{s}\mathrm{c}}+{T}_{\mathrm{c}} $ | (2) |
其中:Tcs为用户从客户端向服务器端发出请求的时间;Ts为服务器接受请求并处理所需的时间;Tsc为服务器端返回数据给客户端的时间;Tc为客户端接收响应数据并处理所需的时间。
2)吞吐量Qt,指单位时间内系统处理请求的数量,其计算公式如式(3)所示:
$ {Q}_{\mathrm{t}}={S}_{\mathrm{n}\mathrm{u}\mathrm{m}}/({T}_{\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{t}}+{T}_{\mathrm{l}\mathrm{a}\mathrm{s}\mathrm{t}\mathrm{t}\mathrm{i}\mathrm{m}\mathrm{e}}-{T}_{\mathrm{f}\mathrm{i}\mathrm{r}\mathrm{s}\mathrm{t}}) $ | (3) |
其中:Snum为样本总数量;Tlast为最后一个线程启动的时间;Tlasttime为最后一个线程持续的时间;Tfirst为第一个线程启动的时间。
3)平均响应延时La,其计算公式如式(4)所示:
$ {L}_{\mathrm{a}}=\sum \limits_{i}{l}_{i}/{S}_{\mathrm{s}\mathrm{u}\mathrm{m}} $ | (4) |
其中:li为单个请求的响应延时。
4)并发度C,其计算公式如式(5)所示,对于一个系统而言,平均响应延时为每个请求所需的时间,吞吐量为单位时间的请求数量,因此,两者相乘即为并发度。
$ C=Q_{\mathrm{t}} \cdot L_{\mathrm{a}} $ | (5) |
根据上述公式可以计算得出用户请求响应时间以及微服务的并发度,从而衡量FPGA云平台中节点资源管理微服务的服务质量。从用户请求响应时间角度分析,响应时间越小,用户体验质量越好;从系统的并发度角度分析,并发度越高,系统性能越好[23]。
2.4 算法设计本文在上述自定义参数响应指数计算模型的基础上,提出一种高并发请求调度算法HCRS,根据上述定义的阈值将用户响应指数划分为直接申请、加入队列等待申请、挂起申请3种执行类型,并以此为标准分配用户申请节点请求。
本文算法的执行流程如图 4所示,大量用户同时发起申请节点请求,输入对应的参数,在传递输入参数后,模型开始计算各个用户对应的响应指数,并将其大小与阈值进行比较,从而分类处理不同用户的请求。
![]() |
Download:
|
图 4 HCRS算法执行流程 Fig. 4 HCRS algorithm execution procedure |
基于自定义参数响应指数计算模型,本文设计的高并发请求调度算法描述具体如下:
算法2 HCRS算法
输入 用户请求参数
输出 用户请求执行顺序
1.array2 ← normalize(array);
2.y ← count(array2,weight);//计算响应指数
3.process_request();//处理用户请求
4.for i in range(0,num){
5.if res < min
6.else min < res < = avg
7.q.put(res);
8.else res > avg
9.apply();}
10.process_queue();
11.for i in range(0,qsize){
12.res = q.get();
13.apply();}
3 实验结果与分析本文将HCRS算法应用到真实的FPGA云平台上,并通过在真实应用场景下模拟同一组用户高并发登录及申请节点请求,以分析评估资源分配情况以及微服务的质量。
3.1 实验环境本文部署节点资源管理微服务的软件环境为CentOS Linux release 7.8.2003(Core)+GCC V4.8.5,其底层框架为Tornado5.1,FPGA云平台使用的硬件节点为Xilinx公司发布的PYNQ-Z2,节点系统为PYNQ Linux,based on Ubuntu 18.04+GCC V7.3.0。Web应用技术栈为Spring Boot、Apache Shiro、MyBatis、Thymeleaf。数据库采用Mysql 5.5与Redis 3.0相结合的方式存储管理数据。
测试部分首先使用可视化测试工具Badboy将单个登录以及申请节点的测试脚本直接导出生成Apache Jmeter脚本,然后使用Apache Jmeter,根据具体测试要求修改测试脚本,添加用户登录信息以及用户计划使用时间,即输入参数进行测试。
3.2 实验结果本文算法已在真实的FPGA云平台OpenHEC中实现,模拟1 000个用户分别在先来先服务(FCFS)调度算法以及本文HCRS算法下执行登录及申请节点请求,同时考虑HCRS算法中自定义参数的输入,为保证实验过程更接近真实的用户操作,所有参数设置如下:用户历史平均使用时间的权重较高,对实验影响较大,因此,需获取其真实数据;用户计划使用时间具有较大的随机性,因此,随机生成1 000个用户的计划使用时间并存入文本文件作为测试数据;是否为会员、用户计划申请节点数量、用户历史空置时间这3个参数均设为默认值。默认用户均为普通用户,并且一次申请一个节点使用,默认用户历史空置时间为零。
在不同算法下,1 000个用户登录以及申请节点的请求通过率为100%,请求响应时间如表 5所示,其中,“99%”表示99%请求的响应时间。从表 5可以看出,与FCFS算法相比,HCRS算法申请节点的平均响应时间缩短了12 605 ms。
![]() |
下载CSV 表 5 用户请求响应时间对比 Table 5 Comparison of user request response time |
2种算法在吞吐量及网络接收发送数据量上的对比结果如表 6所示,从表 6可以看出,在申请节点请求下,HCRS算法的吞吐量以及网络收发数据量均优于FCFS算法。
![]() |
下载CSV 表 6 吞吐量及网络收发数据量对比 Table 6 Comparison of throughput and network received and sent data volume |
衡量微服务质量的另一个指标为用户请求平均响应延时,1 000个用户并发请求执行完毕所需总时长为2 min。图 5对比显示了2种算法在总时长内每隔1 min的平均响应延时,从图 5可以看出,HCRS算法的请求平均响应延时略高于FCFS算法。
![]() |
Download:
|
图 5 2种算法的平均响应延时对比 Fig. 5 Comparison of average response delay of two algorithms |
从3.2节实验结果可以看出,HCRS算法申请节点请求平均响应时间优于FCFS算法。2种算法在不同响应时间区间内处理请求个数情况如图 6所示,从图 6可以看出,HCRS算法大部分请求响应时间处于40~80 s之间,少部分请求处于80~120 s之间,而FCFS算法几乎所有请求的响应时间都处于80~120 s之间。因此,在处理用户并发申请节点请求上,HCRS算法能有效降低请求响应时间。
![]() |
Download:
|
图 6 2种算法在不同响应时间区间内处理请求个数对比 Fig. 6 Comparison of the number of requests processed by the two algorithms in different response time intervals |
从3.2节实验结果可知,HCRS算法的系统吞吐量较FCFS算法更优。从图 7各时刻系统吞吐量的对比情况可知,HCRS算法更为稳定,前期处于上升趋势,中期最高能实现每秒处理11个请求,后期回落到每秒处理6个请求,而FCFS算法的系统吞吐量到后半程才逐渐上升,最高达到每秒处理约16个请求,相比之下,使用HCRS算法的系统吞吐量更为稳定并且性能更优。
![]() |
Download:
|
图 7 2种算法各时刻的系统吞吐量对比 Fig. 7 Comparison of system throughput of two algorithms at each time |
从3.2节实验结果可知,HCRS算法下的用户请求平均响应延时高于FCFS算法。从完成一个完整请求所需时间(即响应延时)与每秒请求数的关系角度分析,2种算法的实验结果分别如图 8、图 9所示。从中可以看出,并发处理用户请求的数量集中在250个请求以内,对比分析这段区间内的响应延时,FCFS算法的响应延时多数分布在80~100 s之间,少数分布在0~50 s之间,最高达到128 s左右,而HCRS算法的响应延时多数分布在50~100 s之间,少数分布在0~20 s之间,最高达到95 s。因此,HCRS算法处理请求的延时普遍低于FCFS算法。
![]() |
Download:
|
图 8 FCFS算法平均响应延时与每秒请求数的关系 Fig. 8 The relationship between the average response delay of FCFS algorithm and the number of requests per second |
![]() |
Download:
|
图 9 HCRS算法平均响应延时与每秒请求数的关系 Fig. 9 The relationship between the average response delay of HCRS algorithm and the number of requests per second |
对比2种算法每秒处理相同数量(1、2、6、185)用户请求时的响应延时,结果如表 7所示,从中可以看出,HCRS算法平均响应延时较FCFS算法降低29 074 ms。
![]() |
下载CSV 表 7 2种算法每秒处理相同数量请求时的响应延时对比 Table 7 Comparison of response delay of the two algorithms when processing the same number of requests per second |
由并发度公式可以计算出FCFS算法与HCRS算法的并发度,2种算法的吞吐量以及各时刻的平均响应延时对比如表 8所示。
![]() |
下载CSV 表 8 2种算法的吞吐量及各时刻的平均响应延时对比 Table 8 Comparison of throughput and average response delay at each time of the two algorithms |
根据表 8数据计算在0、1、2时刻下FCFS算法的并发度分别为:C0 = 88.592 4;C1 = 389.703 6;C2 = 674.754 6。
HCRS算法的并发度分别为:C
2种算法的总并发度为各时刻的并发度之和,具体为:CFCFS = 1 153.050 6;CHCRS = 1 562.525 3。
分析比较2种算法各时刻的并发度以及总并发度可知,HCRS算法的并发度均高于FCFS算法,因此,本文HCRS算法能有效提升系统并发度,从而提高微服务质量。
3.4 实验结果总结本文在真实FPGA云平台上进行实验,模拟同一组数量为1 000的用户的登录及申请节点操作,从而得到实际应用场景中的用户请求测试情况。对比分析2种算法的测试结果可知,在处理用户并发申请节点请求时,HCRS算法的请求响应时间较FCFS算法降低12 605 ms,并且HCRS算法在提高系统吞吐量以及网络接收发送数据量的同时使得系统更为稳定;在每秒处理相同数量用户请求的情况下,HCRS算法的平均响应延时较FCFS算法降低29 074 ms,前者可以提高系统并发度并提升微服务质量。
综上,本文HCRS算法能在满足用户高并发请求的情况下优化系统性能,合理分配硬件节点资源,提升硬件节点的资源利用率。
4 结束语本文针对微服务架构下的FPGA云平台用户请求并发控制问题,提出一种高并发请求调度算法HCRS。结合自定义参数响应指数计算模型,计算各个用户的响应指数,根据响应指数阈值划分用户类别,采取优先级调度的模式处理用户申请节点请求。实验结果表明,在高并发请求场景下,该算法能够有效降低平均响应延时和请求响应时间,提升系统吞吐量以及网络接收发送的数据量,同时提高系统并发度,优化系统性能,此外,HCRS算法能够使得历史行为较为友好以及使用频率较高的用户优先使用节点,从而提升硬件节点的资源利用率。目前,本文算法已经在改进后的FPGA云平台中上线投入使用,有效解决了用户并发申请节点的问题,并取得了较好的效果。为了进一步优化云平台性能及微服务质量,下一步将针对系统容错、网络通信安全、服务监控等方面进行研究,并优化微服务架构中的负载均衡机制,通过不同的高并发原则来提升系统吞吐量。
[1] |
ALVES G R, FIDALGO A, MARQUES A, et al. Spreading remote lab usage a system—a community—a Federation[C]//Proceedings of the 2nd International Conference of the Portuguese Society for Engineering Education. Washington D. C., USA: IEEE Press, 2016: 1-7.
|
[2] |
李康, 张鲁飞, 张新伟, 等. 基于FPGA集群的脉冲神经网络仿真器设计[J]. 计算机工程, 2020, 46(10): 201-209. LI K, ZHANG L F, ZHANG X W, et al. Design of spiking neural network simulator based on FPGA cluster[J]. Computer Engineering, 2020, 46(10): 201-209. (in Chinese) |
[3] |
DOSHI J, PATIL P, DAVE Z, et al. Implementing a cloud based Xilinx ISE FPGA design platform for integrated remote labs[C]//Proceedings of International Conference on Advances in Computing, Communications and Informatics. Washington D. C., USA: IEEE Press, 2015: 533-537.
|
[4] |
FUJII N, KOIKE N. IoT remote group experiments in the cyber laboratory: a FPGA-based remote laboratory in the hybrid cloud[C]//Proceedings of International Conference on Cyberworlds. Washington D. C., USA: IEEE Press, 2017: 162-165.
|
[5] |
TOYODA Y, KOIKE N, LI Y M. An FPGA-based remote laboratory: implementing semi-automatic experiments in the hybrid cloud[C]//Proceedings of the 13th International Conference on Remote Engineering and Virtual Instrumenta-tion. Washington D. C., USA: IEEE Press, 2016: 24-29.
|
[6] |
施凌鹏, 朱征, 周俊松, 等. 面向微服务架构的云系统负载均衡机制[J]. 计算机工程, 2021, 47(9): 44-50, 58. SHI L P, ZHU Z, ZHOU J S, et al. Load balancing mechanism for microservice architecture in cloud-based systems[J]. Computer Engineering, 2021, 47(9): 44-50, 58. (in Chinese) |
[7] |
FOWLER M, LEWIS J. Microservices[EB/OL]. [2021-07-05]. https://martinfowler.com.
|
[8] |
KAINZ A. Microservices vs. Monoliths: an operational comparison[EB/OL]. [2021-07-05]. https://thenewstack.io/microservices-vs-monoliths-an-operational-comparison.
|
[9] |
LIU X, ZHAI X B, LU W D, et al. QoS-guarantee resource allocation for multibeam satellite industrial Internet of Things with NOMA[J]. IEEE Transactions on Industrial Informatics, 2021, 17(3): 2052-2061. DOI:10.1109/TII.2019.2951728 |
[10] |
SHETTY J, ANTONY D'MELLO D. QoS based cloud service selection to handle large volume of concurrent requests[J]. Indian Journal of Science and Technology, 2016, 9(48): 15-26. |
[11] |
SUN M Y, ZHOU Z B, WANG J P, et al. Energy-efficient IoT service composition for concurrent timed applications[J]. Future Generation Computer Systems, 2019, 100: 1017-1030. DOI:10.1016/j.future.2019.05.070 |
[12] |
郭军, 武静, 邢留冬, 等. 面向突发业务的云服务并发量应对策略研究[J]. 计算机学报, 2019, 42(4): 864-882. GUO J, WU J, XING L D, et al. A coping strategy for bursty workload of cloud service[J]. Chinese Journal of Computers, 2019, 42(4): 864-882. (in Chinese) |
[13] |
AMAL MURAYKI ALRUWAILI B A A, HUMAYUN M, JHANJHI N Z. Proposing a load balancing algorithm for cloud computing applications[J]. Journal of Physics: Conference Series, 2021, 1979(1): 012034. DOI:10.1088/1742-6596/1979/1/012034 |
[14] |
LIU W, ZHANG D W, GAO Z J. A novel load balancing strategy based on node load comprehensive measuring under cloud computing environment[J]. Journal of Computational Methods in Sciences and Engineering, 2019, 19: 3-9. |
[15] |
ZHOU J, CEN B W, CAI Z X, et al. Workload modeling for microservice-based edge computing in power Internet of Things[J]. IEEE Access, 2021, 9: 76205-76212. DOI:10.1109/ACCESS.2021.3081705 |
[16] |
AL-DEBAGY O, MARTINEK P. A comparative review of microservices and monolithic architectures[C]//Proceedings of the 18th International Symposium on Computational Intelligence and Informatics. Washington D. C., USA: IEEE Press, 2018: 149-154.
|
[17] |
VILLAMIZAR M, GARCÉS O, OCHOA L, et al. Cost comparison of running Web applications in the cloud using monolithic, microservice, and AWS Lambda architectures[J]. Service Oriented Computing and Applications, 2017, 11(2): 233-247. DOI:10.1007/s11761-017-0208-y |
[18] |
LU X Z, PHANG K. An enhanced Hadoop heartbeat mechanism for MapReduce task scheduler using dynamic calibration[J]. China Communications, 2018, 15(11): 93-110. DOI:10.1109/CC.2018.8543052 |
[19] |
ROCHIM A F, AZIZ M A, FAUZI A. Design log management system of computer network devices infrastructures based on ELK stack[C]//Proceedings of International Conference on Electrical Engineering and Computer Science. Washington D. C., USA: IEEE Press, 2019: 338-342.
|
[20] |
邓雪, 李家铭, 曾浩健, 等. 层次分析法权重计算方法分析及其应用研究[J]. 数学的实践与认识, 2012, 42(7): 93-100. DENG X, LI J M, ZENG H J, et al. Research on computation methods of AHP wight vector and its applications[J]. Mathematics in Practice and Theory, 2012, 42(7): 93-100. (in Chinese) |
[21] |
刘卫锋, 何霞. 基于模糊判断矩阵的两阶段群决策方法[J]. 计算机工程, 2012, 38(10): 141-143. LIU W F, HE X. Two-step method of group decision making based on fuzzy judgment matrix[J]. Computer Engineering, 2012, 38(10): 141-143. (in Chinese) |
[22] |
RUDRABHATLA C K. A quantitative approach for estimating the scaling thresholds and step policies in a distributed microservice architecture[J]. IEEE Access, 2020, 8: 180246-180254. DOI:10.1109/ACCESS.2020.3028310 |
[23] |
BAE J, JANG H, JIN W J, et al. Jointly optimizing task granularity and concurrency for in-memory MapReduce frameworks[C]//Proceedings of IEEE International Conference on Big Data. Washington D. C., USA: IEEE Press, 2017: 130-140.
|