面向空间操控仿真模型计算的动态任务调度系统

1.本发明涉及计算机系统空间操控仿真领域，尤其涉及面向空间操控仿真模型计算的动态任务调度系统。


背景技术：

2.针对空间领域的探索研究，各国为提升航天器性能，同时降低航天器研制风险与费用开销，纷纷开展全空间轨道维修、相机载荷探测、碎片规避与清障、在轨操作等空间操控任务仿真方面的研究。空间操控任务过程仿真需要在仿真模拟环境下进行虚拟化的空间操控任务推演、评估、控制与决策等活动，涉及飞行器动力学、流体力学、计算机视觉等多学科耦合建模的复杂任务处理，其量级不再是单个应用或者单台服务器所能承受，而是多服务器集群相互作用的结果，因此空间操控任务过程仿真对服务器集群资源利用率提出了更高的要求。
3.如今服务端架构已经从单一架构到分布式再到微服务开展了不断升级与迭代，在微服务带来强大的灵活扩展应用的同时，也存在集群部署与调度优化等相关问题。为优化集群资源调度，许多分布式任务调度系统随之产生，其瓶颈在于如何对服务器资源进行最优控制，即解决如何为各个计算节点指定不同业务类的线程/进程配额。其中，当当集团开发的elastic-job任务调度系统提供任务分片、弹性扩容缩容等功能，但不支持定时任务的动态管理以及工作流类型的定时任务；大众点评集团的xxl-job任务调度系统提供轻量级的任务调度动态管理，但在海量业务处理下服务注册能力较为迟缓；阿里巴巴公司推出的tbschedule任务调度系统可扩展性较强，但任务类型比较单一；spring cloud scheduler任务调度系统有强大的社区功能，但架构较为繁杂对硬件资源有一定需求。
4.在实际空间操控仿真任务中，由于服务器集群中各计算节点性能的差异性，众多任务调度系统会存在负载不平衡的现象，导致系统处理速度下降、网络延迟增加等问题，例如：1)任务节点资源角色固定或较为单一，同时节点备份过多造成资源的大量无效开销；2)负载迁移时大量任务将迁入负载较轻的任务节点，导致任务节点再次触发负载平衡，产生周期性震荡，影响服务器系统性能。
5.由此，面向空间操控仿真任务，如何设计一种任务调度系统达到优化资源使用、最小化系统响应时间、最大化模型计算效率、避免服务端过载成为目前亟待解决的问题。


技术实现要素：

6.本发明的目的在于克服现有技术的缺陷，提出了面向空间操控仿真模型计算的动态任务调度系统。
7.本发明主要针对大型空间操控仿真试验中海量多源异构空间操控仿真模型的高并发调用对传统服务架构带来的挑战，建立以负载迁移模型为核心的动态任务调度系统。
8.为了实现上述目的，本发明提出了一种面向空间操控仿真模型计算的动态任务调度系统，所述系统包括：调度中心、若干个调度器节点和若干个执行器节点；所述调度器节
点和执行器节点分别部署在不同的服务器集群上，其中，
9.所述调度中心，用于根据空间操控仿真服务的任务调度需求，基于动态负载迁移技术进行任务调度的动态调节，将任务分配至已注册的调度器节点；
10.所述调度器节点，用于进行任务的生产与缓存，并采用远程过程调用rpc技术触发执行器中心，还用于针对无法满足的任务，对执行器节点进行动态弹性扩容；
11.所述执行器中心，用于通过心跳注册的方式在调度中心登录实现二者远程通信；还用于对任务进行具体的计算流程与计算任务分解，触发相应的执行器节点实现任务调度的高并发执行；
12.所述执行器节点，用于执行相应的空间操控仿真模型计算任务。
13.作为上述系统的一种改进，所述动态负载迁移技术为采用动态负载迁移算法建立最优控制的负载迁移模型；其中，所述负载迁移模型包括：
14.调度器节点j返回的状态信息由任务调度队列长度qi和调度器线程池中空闲的线程个数tj组成n个二元组＜qi,tj＞,i,j＝1,2,...,n，调度器节点负载均衡时间正比于任务调度队列长度，反比于并发处理该类任务的线程数目，满足下式：
[0015][0016][0017]
其中，表示调度器节点j服务于i个任务调度的空闲度，α为传输衰减系数，是与服务端交换机、控制器相关的常数，e[δl
i,j
(t)]是调度器节点负载变化量的数学期望。
[0018]
作为上述系统的一种改进，所述建立最优控制的负载迁移模型具体包括：
[0019]
定义实时负载rlp指标l
i,j
(t)满足下式：
[0020]
l
i,j
(t)＝(anc+bcc+cmc)/(nr+cr+mr)
[0021]
其中，a、b、c分别表示网络带宽、cpu资源及内存资源在服务器整体资源中的占比系数，下标r表示服务器整体资源，下标c表示当前已使用的各类资源，n表示网络带宽，c表示cpu计算资源、m表示内存大小；
[0022]
定义任务调度分配权重tsw指标w
i,j
(t)满足下式：
[0023]wi,j
(t)＝h
i,j
(t-1)ξi(l
i,j
(t)-l
i,j
(t-1))/qi[0024]
其中，ξi为任务调度复杂度，h
i,j
(t-1)为当前调度器节点的负载迁移标记系数，如果在上一采样时刻该调度器节点没有进行负载迁移操作，h
i,j
(t-1)默认为1，已被迁移负载时h
i,j
(t-1)为0.5；
[0025]
定义负载迁移量tlt指标u(t)满足下式：
[0026][0027]
其中，u
i,j
(t)为单次负载迁移量；
[0028]
得到调度器节点负载均衡时间为：
[0029]
[0030]
满足调度器节点负载均衡时间尽量小，并尽可能减少负载迁移量tlt指标u(t)的变化率以减少服务器资源调整频率，得到第t个采样时刻最优控制的负载迁移量u
*
(t)为：
[0031]u*
(t)＝u(t-1)-e
i,j
{α/2w
i,j
(t)qitj}
[0032]
其中，u(t-1)表示第t-1个采样时刻负载迁移量tlt指标，e
i,j
{}为数学期望计算。
[0033]
作为上述系统的一种改进，所述动态负载迁移算法具体包括：
[0034]
输入当前t时刻的任务调度队列长度qi(t)和调度器线程池中的线程个数tj(t)；
[0035]
将各调度器节点按照rlp指标降序排列加入集合φ{desc}，同时计算当前时刻的负载平衡阈值u
thr
(t)，并规定在同一时间，调度器节点只响应一个负载迁移请求，在此请求完成后才能再次接受请求；
[0036]
采用贪心思想遍历各调度器节点每个采样时刻的最优负载迁移节点，进行迭代选择，计算最优控制的负载迁移量。
[0037]
作为上述系统的一种改进，所述采用贪心思想遍历各调度器节点每个采样时刻的最优负载迁移节点，进行迭代选择，计算最优控制的负载迁移量；具体包括：
[0038]
计算tlt指标，选择空闲度最小的调度器节点作为负载迁移对象；
[0039]
若存在多个空闲度相同的调度器节点，则计算单个调度器节点tsw指标，并选择权重较高的调度器节点作为首个负载迁移对象，根据该调度器节点的资源状态计算单次负载迁移量u
i,j
(t)，当单次负载迁移量超过负载平衡阈值u
i,j
(t)时，将该调度器节点从集合中去除，并顺延选择后续调度器节点重新计算是否可接受任务调度请求；
[0040]
计算最优控制的负载迁移总量u
*
(t)，并对该调度器节点进行标记，将负载迁移标记系数h
i,j
(t)置为0.5。
[0041]
作为上述系统的一种改进，所述系统还包括：全局资源控制模块、监视器、弹性伸缩模块和容器编排工具；其中，
[0042]
所述全局资源控制模块，用于通过心跳机制接收服务器集群中任务的挂起状态；
[0043]
所述监视器，用于通过订阅全局资源控制模块的心跳信息，定时监控执行器节点所在的服务器集群中的任务挂起情况；
[0044]
所述弹性伸缩模块，用于根据任务挂起情况采用动态弹性扩容算法auto scale(
·
)创建新的执行器节点并保存至扩容队列expanding q中，还用于发送创建新执行器节点指令至容器编排工具；
[0045]
所述容器编排工具，用于在扩容队列中读取新的执行器节点信息，新建执行器节点并加入到容器集群中。
[0046]
作为上述系统的一种改进，所述弹性伸缩模块的处理过程具体包括：
[0047]
根据每一个被挂起任务的资源信息设定执行器节点的类型type，如果扩容队列expanding q中包含该执行器节点类型，则继续迭代查找下一个被挂起任务，否则将该执行器节点加入至扩容队列expanding q中。
[0048]
作为上述系统的一种改进，所述调度器节点的处理还包括：
[0049]
当调度器检测到新加入的执行器节点，重新唤醒处于被挂起状态的任务，并再次判断该执行器节点是否满足任务的资源要求：如果该执行器节点满足任务资源要求，任务将被调度到该执行器节点，若依旧不满足，则任务再次转化为被挂起状态。
[0050]
与现有技术相比，本发明的优势在于：
[0051]
1、本发明突破了动态任务调度、动态负载迁移，以及动态弹性扩容等关键技术，优化服务端资源分配以提升任务处理能力，为大型空间操控仿真试验中高并发的任务计算需求提供技术支撑；
[0052]
2、本发明推动了以微服务技术为基础的任务调度平台与负载均衡技术的发展，解决现有技术在高并发任务响应下服务注册能力迟缓、服务端资源大量开销、负载迁移周期震荡的技术难题；
[0053]
3、本发明建立以负载迁移模型为核心的动态任务调度系统实现最优服务端资源分配，同时为规避负载均衡震荡设计了一种动态负载迁移算法，有效约束负载迁移的行为，提升服务端稳定性，最终提高海量任务处理性能；
[0054]
4、本发明建立了适用于大型空间操控仿真试验的泛化性平台系统，支撑涉及多学科耦合建模与复杂任务处理的空间操控仿真推演、评估、控制与决策等活动，具有很高的应用价值。
附图说明
[0055]
图1是本发明的面向空间操控仿真模型计算的动态任务调度系统技术路线图；
[0056]
图2是全异步化分布式动态任务调度工作时序图；
[0057]
图3是动态负载迁移算法流程描述；
[0058]
图4是动态弹性扩容技术描述；
[0059]
图5是硬件环境部署；
[0060]
图6是40g操控对象交互数据包的实时负载状态；
[0061]
图7(a)是不同量级任务调度的实时负载状态；
[0062]
图7(b)是不同量级任务调度的负载均衡耗时。
具体实施方式
[0063]
本发明涉面向空间操控仿真模型计算的动态任务调度系统，技术路线如图1所示：
[0064]
系统包括：调度中心、若干个调度器节点和若干个执行器节点；所述调度器节点和执行器节点分别部署在不同的服务器集群上，其中，
[0065]
所述调度中心，用于根据空间操控仿真服务的任务调度需求，基于动态负载迁移技术进行任务调度的动态调节，将任务分配至已注册的调度器节点；
[0066]
所述调度器节点，用于进行任务的生产与缓存，并采用远程过程调用rpc技术触发执行器中心，还用于针对无法满足的任务，对执行器节点进行动态弹性扩容；
[0067]
所述执行器中心，用于通过心跳注册的方式在调度中心登录实现二者远程通信；还用于对任务进行具体的计算流程与计算任务分解，触发相应的执行器节点实现任务调度的高并发执行；
[0068]
所述执行器节点，用于执行相应的空间操控仿真模型计算任务。
[0069]
下面结合附图和实施例对本发明的技术方案进行详细的说明。
[0070]
实施例1
[0071]
本发明的实施例提出了一种面向空间操控仿真模型计算的动态任务调度系统，动
态任务调度系统主要由任务调度、远程执行、数据管理三部分组成，在动态任务调度系统中主要涉及三个关键技术：全异步化分布式动态任务调度技术、基于负载迁移模型的动态负载迁移技术，以及动态弹性扩容技术。
[0072]
面向航天器轨道机动推演、步进调姿、星地与星间通信、空间操作等各类空间操控仿真任务调度需求，动态任务调度系统通过全异步化分布式动态任务调度技术进行海量仿真任务的高并发计算：首先由调度中心动态激活各调度器节点，之后各调度器节点采用远程过程调用(remote procedure call，简称rpc)技术将消息发布至执行器中心，执行器中心针对计算流程拆解为相应的计算任务，并对各个计算任务分配执行器节点进行计算，最后将计算结果同步至关系型与非关系型数据库，实现数据的快速缓存、存储、检索与管理功能。其中，调度中心通过基于负载迁移模型的动态负载迁移技术实现自适应的调度器节点资源分配，如若当前服务端集群资源不满足任务分配的资源消耗要求，则通过动态弹性扩容技术对服务端集群进行纵向扩容，增加节点资源完成计算任务。
[0073]
(1)全异步化分布式动态任务调度技术
[0074]
全异步化分布式动态任务调度技术的具体工作时序流程如图2所示，当外部存在新的任务调度需求时，通过动态负载迁移算法分发任务至调度中心，调度中心不参与计算任务的执行，而是将任务再次分配至已注册的调度器节点，由调度器节点在队列交互层进行任务的生产与写入消费队列缓存；之后根据调度器节点的任务分配结果，按写入顺序稳定消费队列中的各个任务，并采用远程过程调用rpc技术触发执行计算层中的执行器中心，执行器中心能够在服务器集群中进行分布式集群部署，通过心跳注册的方式在调度中心登录实现二者远程通信；最后执行器中心对任务进行具体计算流程与计算任务分解，触发相应的执行器节点实现任务调度的高并发执行。
[0075]
动态任务调度系统以调度中心作为控制中台，通过快速分析用户的相关计算需求触发调度中心分配作业，并通过执行器中心开展作业的实际处理工作，支持注册或摘除相应的执行器进行动态弹性扩容，实现任务调度的全异步化设计以及分布式部署。
[0076]
全异步化分布式动态任务调度技术的具体工作时序流程如图2所示，当外部存在新的任务调度需求时，通过动态负载迁移算法分发任务至调度中心，调度中心不参与计算任务的执行，而是将任务再次分配至已注册的调度器节点，由调度器节点在队列交互层进行任务的生产与写入消费队列缓存；之后根据调度器节点的任务分配结果，按写入顺序稳定消费队列中的各个任务，并采用远程过程调用rpc技术触发执行计算层中的执行器中心，执行器中心能够在服务器集群中进行分布式集群部署，通过心跳注册的方式在调度中心登录实现二者远程通信；最后执行器中心对任务进行具体计算流程与计算任务分解，触发相应的执行器节点实现任务调度的高并发执行。
[0077]
其中，全异步化分布式动态任务调度技术的核心在于如何对调度器节点进行最优任务分配，因此本发明提出动态任务调度算法task schedule(
·
)，即通过遍历服务器集群中的所有调度器节点来得到满足资源要求的节点集合，并采用基于负载迁移模型的动态负载迁移技术进行任务调度的动态调节，对于在该调度策略下无法满足的任务，采用动态弹性扩容技术对服务端集群进行纵向扩容，增加节点资源完成调度任务，整体思路如表1所示。
[0078]
表1动态任务调度算法task schedule(
·
)
[0079][0080][0081]
具体来讲，首先对服务端集群进行资源初始化resources init，之后用户提交的任务调度请求会进入到调度队列qi,i＝{1,2,...,n}中，通过遍历服务端集群中的所有调度器节点，根据任务自身携带的资源要求qi.dem,本地调度器将首先判断自身节点的资源localnode.res是否满足，若满足则将任务调度到自身节点，若不满足则执行动态负载迁移算法load balance(
·
)，通过遍历集群中的所有节点来得到满足资源要求的节点集合,并根据动态负载均衡算法在此节点集合上得到最优任务调度分配结果。如果任意节点的资源都无法满足此任务的资源要求，此时任务被挂起q
i pending，同时对服务器集群进行扩容操作，执行动态弹性扩容算法auto scale(
·
)。扩容操作分为横向扩容与纵向扩容，其中横向扩容只能复制已配置的资源节点，纵向扩容机制灵活多变，可根据任务的资源要求重新创建资源节点。当服务端集群中增加新节点后会重新遍历被挂起的任务，并对任务进行资源需求查验，当节点满足要求时将挂起的任务重新转为就绪态，重新调度至新加入的节点。
[0082]
(2)基于负载迁移模型的动态负载迁移技术
[0083]
1)负载迁移模型定义
[0084]
全异步化分布式动态任务调度技术的瓶颈在于如何对服务器资源进行最优控制，即解决如何为各个计算任务分配不同的计算节点，而负载均衡策略则保证均衡调度各个计算节点，避免节点处于过载或空闲状态。当前大多数的负载均衡策略主要基于客户端访问量与服务响应时间呈现指数分布的假设上，但空间操控仿真任务包含大规模计算服务的同步调用以及高频次数据交互与读写操作需求，服务响应时间难以拟合计算。为了准确评估服务器上各个节点的负载状况进而高效分配新的任务请求，同时避免计算任务激增造成服务端过载或任务骤减造成服务端休眠等问题，本发明建立负载迁移模型，实现最优节点资源分配。
[0085]
服务器节点j返回的状态信息是由任务调度队列长度qi和服务器线程池中空闲的线程个数tj组成的n个二元组＜qi,tj＞i,j＝1,2,...,n。服务器各节点负载均衡时间正比于任务调度队列长度，反比于并发处理该类任务的线程数目。
[0086][0087]
表示服务器节点j服务于i个任务调度的空闲度，与服务器节点负载均衡时间成反比。α为传输衰减系数，是与服务端交换机、控制器等系统相关的常数。
[0088]
e[δl
i,j
(t)]是服务器节点负载变化量的数学期望。
[0089]
定义1实时负载指标(realtime load probability,rlp)：服务器的工作负载状态与网络带宽n、cpu计算资源c、内存大小m等因素相关，衡量rlp的计算公式如公式(2)所示：
[0090][0091]
其中a、b、c分别表示网络带宽、cpu资源及内存资源在整体服务部件中的资源权重，下标r表示服务部件整体资源，下标c表示当前已使用的各类资源。
[0092]
定义2任务调度分配权重(task scheduler weight,tsw)：定义tsw为服务器对任务调度分配的优先级关系，与当前节点的空闲度成正比。tsw越小，相应的业务流在资源调度时越受“歧视”。
[0093][0094]
其中ξi为任务调度复杂度，h
i,j
(t-1)为当前节点的负载迁移标记系数，如果在上一采样时刻该节点没有进行负载迁移操作，该系数默认为1，已被迁移负载时系数为0.5。
[0095]
定义3负载迁移量指标(total load transform，tlt)：定义tlt为在服务器节点与空闲线程间的负载迁移总量，用于描述系统总体开销。
[0096][0097]
其中，u
i,j
(t)为单次负载迁移量，结合公式(1)与(4)可得服务器负载均衡时间为：
[0098][0099]
综上所述，服务端的线程/进程调度可以建立最优控制的负载迁移模型，一方面希望服务器各节点负载均衡时间尽量小，另一方面尽可能减少tlt的变化率以减小系统开销，构造损失函数为：
[0100][0101]
其中e
i,j
为数学期望。当loss取最小值时，关于u(t)的导数为零，有：
[0102][0103]
求解式(6)，得到第t个采样时刻最优控制的负载迁移量为：
[0104]u*
(t)＝u(t-1)-e
i,j
{α/2w
i,j
(t)qitj}
ꢀꢀꢀ
(8)
[0105]
2)动态负载迁移算法
[0106]
在服务端线程或进程间进行负载迁移时，需要考虑如何解决任务激增造成服务端过载致使再次迁移负载，形成的一种震荡迁移现象。为此本发明基于负载迁移模型设计一种动态负载迁移算法load balance(
·
)，可以有效约束负载迁移的行为，规避负载均衡震荡。
[0107]
表2动态负载迁移算法load balance(
·
)
[0108][0109][0110]
动态负载迁移算法load balance(
·
)的整体思路如表2所示，算法流程图如图3所示，算法输入当前t时刻的任务调度队列长度qi(t)和服务器线程池中的线程个数tj(t)，其中i,j＝{1,2,...,n}。首先将各资源节点按照rlp降序排列加入集合φ{desc}，同时计算当前时刻的负载平衡阈值u
thr
(t)，并规定在同一时间，资源节点只响应一个负载迁移请求，在此请求完成后才能再次接受请求。之后采用贪心思想确定可接受请求的资源节点：(1)根据公式(2)计算实时负载，选择空闲度最小的节点作为负载迁移对象；(2)若存在多个空闲度相同的节点，则根据公式(3)计算个节点任务调度分配权重tsw，并选择权重较高的节点作为首个负载迁移对象。根据该节点的资源状态计算单次负载迁移量u
i,j
(t)，当单次负载迁移量超过负载平衡阈值u
i,j
(t)时，将该资源节点从集合中去除，并顺延选择后续资源节点重新计算是否可接受任务调度请求。最后根据公式(8)推导的最优控制负载迁移模型的损失函数，计算最优控制的负载迁移总量u
*
(t)，并对该资源节点进行标记，即将负载迁移标记系数h
i,j
(t)置为0.5。同理对后续采样时刻的最优负载迁移节点进行迭代选择，计算最优
控制的负载迁移量。由于算法优先选择任务调度分配权重tsw较低的节点作为负载迁移对象，因此该资源节点在下一个采样时刻下再次被选择的概率会有所提升，以期尽可能减少整体的负载迁移次数。
[0111]
(3)动态弹性扩容技术
[0112]
扩容操作分为横向扩容与纵向扩容，其中横向扩容只能复制已配置的资源节点，纵向扩容机制灵活多变，可根据任务的资源要求重新创建资源节点。对于在上述动态负载迁移技术的调度下无法满足的任务，本发明设计一种动态弹性扩容技术对服务器集群进行纵向扩容，增加节点资源来完成调度：重新遍历被挂起的任务，并对任务进行资源需求查验，当节点满足要求时将挂起的任务重新转为就绪态，重新调度至新加入的节点，并与横向扩容共同降低服务器集群负载。
[0113]
动态弹性扩容技术机制如图4所示，设置监视器对扩容过程进行管理，弹性伸缩模块负责扩容的具体执行，具体流程如下：
[0114]
(1)当服务器集群节点无法满足任务资源要求时，该任务转化为被挂起状态，同时该节点要求的资源resource b将借助心跳机制传递到全局资源控制模块；
[0115]
(2)监视器通过订阅心跳来监控集群状况，监视器每隔一个心跳时间接受一次全局资源控制模块传来的信息，包括处于被挂起状态的任务资源要求resource b，随后触发纵向扩容，弹性伸缩模块根据动态弹性扩容算法auto scale(
·
)创建新的资源节点，并保存至扩容队列expanding q中，动态弹性扩容算法如表3所示；
[0116]
(3)容器编排工具接收到创建新节点的指令后，在扩容队列中读取该节点信息，新建节点并加入到容器集群中。当新节点创建完成后,则将扩容队列中的相应节点移除；
[0117]
(4)最后调度器会检测到新加入的节点，重新唤醒处于被挂起状态的任务，并再次判断该节点是否满足任务资源要求：如果该节点满足任务资源要求，任务将被调度到此节点，若依旧不满足，则任务再次转化为被挂起状态。
[0118]
表3动态弹性扩容算法auto scale(
·
)
[0119][0120]
在动态弹性扩容算法auto scale(
·
)中，根据每一个被挂起任务的资源信息设定
节点类型type，如果扩容队列中包含该节点类型，则继续迭代查找下一个被挂起任务，否则将该节点类型加入至扩容队列中。通过扩容队列的设置，降低节点的创建时间，同时防止一个被挂起任务创建过多的节点。
[0121]
仿真示例：
[0122]
(1)实验环境准备
[0123]
本发明设计的动态任务调度系统与方法在大型航天器试验仿真系统中进行了现场实地测试，系统部署了两类云计算虚拟节点集群，分别为：1)任务调度中控集群：由3台服务器组成，采用云平台搭建技术虚拟出云计算节点，负责部署调度中心用于接收用户的海量仿真任务调度请求；2)执行器处理集群：由5台服务器组成，负责部署执行器中心与数据库，进行高效任务处理与数据存储，其硬件部署图如图5所示。基于国产自主可控原则，采用龙芯机架式服务器tl621集群、银河麒麟服务器版操作系统v4.0，以及神州通用国产数据库v7.0搭建基础环境，其详细配置参数如表2所示。
[0124]
表4软硬件环境参数配置表
[0125][0126]
(2)实验结果分析
[0127]
面向航天器轨道机动推演、步进调姿、星地与星间通信、空间操作等各类空间操控仿真任务调度需求，通过实验验证本发明中的动态任务调度系统实际性能，并分别从架构时延与负载平衡性能两方面进行对比分析，实验结果与分析如下。
[0128]
1)架构响应时延实验
[0129]
通过同时计算1000个航天器轨道推演、航天器在轨姿态计算、星地与星间通信时段计算等空间操控仿真任务，对比动态任务调度系统与当前国内外主流开源微服务架构的响应时延，实验结果如表5所示，可知xxl-job作为轻量级架构整体时延较短，spring cloud由于架构较为复杂其业务响应时延较长，本发明中的动态任务调度系统在不同架构中有较好表现，与其他三种任务调度架构相比单次任务响应时延平均缩短0.10s、0.25s、0.92s。
[0130]
2)负载平衡性能实验
[0131]
测试负载平衡耗时选取以下观测指标进行实时负载rlp计算：(1)cpu使用率；(2)内存使用率；(3)硬盘传输量；(4)网络流量。负载平衡耗时计算为从服务器运行开始，每隔0.2s记录一次上述观测指标，当处理不同任务调度时计算任务调度前后负载趋于稳定的最大时间间隔。如图6所示，观测指标(1)-(4)一开始位于平衡状态的时刻分别为6.02s、
6.05s、0.12s、0.10s，在4000个单体10m的操控对象交互数据包处理过程中，各个指标再次达到平衡状态的时刻分别为24.34s、24.10s、22.26s、26.15s，两次平衡状态的时间间隔分别为18.32s、18.05s、22.14s、26.05s，因此本发明动态任务调度系统的平均负载平衡耗时为21.56s。
[0132]
分别处理航天器轨道推演、航天器在轨姿态计算、星地与星间通信时段计算等空间操控仿真任务，且在任务数量递增下的负载平衡耗时结果如图7(a)所示：负载平衡耗时与任务调度数量正相关，同时空间操控仿真任务的相关算法复杂度越大造成的负载平衡耗时也越大。具体分析其中一类空间操控仿真任务，在航天器轨道推演任务数量递增条件下的实时负载状态如图7(b)所示：系统cpu使用率、磁盘读写率与任务调度数量成正比，内存使用率跟随任务调度数量一同增加直至饱和；与此同时，在2000量级任务调度处理时，虽然内存使用率已趋于极限，但由于本发明的基于负载迁移模型的动态负载迁移技术，计算调度只获取与当前有效负载匹配的计算任务量，剩余计算任务会在等待队列中排队处理，因此不会出现计算调度阻塞导致服务器崩溃等问题。后续展望认为随着软硬件环境的升级与扩容，本发明的动态任务调度系统能够支撑万、百万等更大量级的空间操控仿真任务处理。
[0133]
需要说明的是：空间操控的仿真模型不仅局限于航天器，也包括地面应用系统通信链路方面的仿真模型调用。本系统还可应用于所有大规模高并发调用的模型计算。
[0134]
创新点：
[0135]
(1)目前国内外的任务调度系统存在架构繁杂、任务类型单一、海量业务处理下服务注册能力较为迟缓等问题，本发明搭建了全异步化与分布式的动态任务调度系统，具备计算任务响应迅速、高吞吐稳定性等优点。
[0136]
(2)在实际应用中，由于服务器集群中各计算节点性能的差异性，任务调度系统会存在负载不平衡现象，而当前国内外负载平衡技术存在节点备份造成的资源大量开销、负载迁移周期震荡等局限性，本发明在动态任务调度系统中通过任务调度算法、动态负载迁移算法，以及动态弹性扩容算法，能够缩短负载平衡周期，优化服务端节点资源分配，提升服务器稳定性。
[0137]
最后所应说明的是，以上实施例仅用以说明本发明的技术方案而非限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行修改或者等同替换，都不脱离本发明技术方案的精神和范围，其均应涵盖在本发明的权利要求范围当中。