(19)国家知识产权局 (12)发明 专利申请 (10)申请公布号 (43)申请公布日 (21)申请 号 202211028074.7 (22)申请日 2022.08.25 (71)申请人 湖南大学 地址 410000 湖南省长 沙市岳麓区麓山 南 路麓山门 (72)发明人 陈果　王文涛　曾一夫　蒋洪波　 李肯立　 (74)专利代理 机构 长沙达伦知识产权代理事务 所(普通合伙) 43272 专利代理师 夏胜伟 (51)Int.Cl. G06F 9/48(2006.01) G06F 9/50(2006.01) (54)发明名称 一种保障服务质量的无服务计算系统及方 法 (57)摘要 一种保障服务质量的无服务计算系统， 包括 HTTP网关、 调度器和工作池； HTTP网关将传来的 DAG请求经过序列化器进行序列化， 将序列化的 DAG请求中的无服务函数依次加入到等待队列 中； 调度器将根据调度策略从等待队列和链运行 队列中调取无服务函数到工作池中进行处理。 本 发明的障服务质量的无服务系统和方法通过对 平台内的调度器进行改造， 通过生产者 ‑‑消费者 模式， 来对传来的请求进行处理。 此外， 通过添加 含有丰富策略的策略框架。 针对不同种类的应用 请求， 设置不同种类的策略， 从而在一定程度上 减少排队时间， 改善运行性能。 权利要求书1页 说明书10页 附图5页 CN 115525408 A 2022.12.27 CN 115525408 A 1.一种保障服务质量的无服务计算系统， 其特征在于： 包括HTTP网关、 调度器和工作 池； 所述HTTP 网关将传来的DAG请求经过序列化器进行序列化， 将序列化的DAG请求中的无 服务函数依次加入到等待队列中； 取DAG的第一个函数进行处理， 将DAG中剩余没有处理的 函数加入到链运行队列， 调 度器将根据调 度策略从等待队列和链运行队列中调取无服务函 数到工作池中进行处 理。 2.根据权利要求1所述的保障服务质量的无服务计算系统， 其特征在于： 所述调度 策略 通过策略框架进行 添加、 移除、 修改或者 替换。 3.根据权利要求1所述的保障服务质量的无服务计算系统， 其特征在于： 所述调度器为 半全局调度器； 所述半全局调度器将集群划分成多个工作池， 每个工作池对应一个半全局 调度器； 所述等待队列中的DAG请求达到扩展阀值， 负载均衡器将DAG请求扩展到另外一个 带有当前DAG请求的半全局调度器。 4.根据权利要求3所述的保障服务质量的无服务计算系统， 其特征在于： 所述等待队列 中的DAG请求低于收缩阀值， 负载均衡器将DAG请求中分离并移除一个最近被添加的半全局 调度器。 5.根据权利要求3所述的保障服务质量的无服务计算系统， 其特征在于： 所述半全局调 度器中还包括评估者和沙箱管理者； 沙箱管理者制作沙箱分配和回收的决定； 评估者针对 每个DAG请求的执 行进行周期评估。 6.根据权利要求1所述的保障服务质量的无服务计算系统， 其特征在于： 所述调度 策略 包括函数级分配、 链级分配、 反应的并发分配、 进 行链优先级、 最短作业优先、 显示优先级分 配、 混合调度和资源意识的调度中的一种或者多种。 7.一种保障服 务质量的无服 务计算方法， 其特 征在于： 包括以下 方法： 1） 将DAG请求在HT TP网关经 过序列化器进行序列化； 2） 步骤1） 将DAG请求序列化后依次将无服 务函数加入等待队列； 3） 调度器将根据调度策略从等待队列和链运行队列中调取无服务函数到工作池中进 行处理。 8.根据权利要求7 所述的保障服 务质量的无服 务计算方法， 其特 征在于： 在所述步骤1） 中评估者将DAG请求执行周期进行评估， 沙箱管理者根据评估结果进行 当前DAG请求的沙箱分配。 9.根据权利要求7所述的保障服务质量的无服务计算方法， 其特征在于： 所述步骤3中 调度器为半全局调度器； 所述半全局调度器将集群划分成多个工作池， 每个工作池对应一 个半全局调度器； 每个DAG请求可被路由到任一个负载均衡器中； 负载均衡器可路由请求到 任一个半全局调度器中。 10.根据权利要求7所述的保障服务质量的无服务计算方法， 其特征在于： 所述步骤3） 中所述等待队列中的DAG请求达到扩展阀值， 负载均衡器将DAG请求扩展到另外一个带有当 前DAG请求的半全局调度器； 所述等待队列中的DAG请求低于收缩阀值， 负载均衡器将DAG请 求中分离一个半全局调度器。权　利　要　求　书 1/1 页 2 CN 115525408 A 2一种保障服务质量的无服务计算系统及方 法 技术领域 [0001]本发明涉及无服务计算技术领域， 尤其涉及一种保障服务质量的无服务计算系统 及方法。 背景技术 [0002]在无服务计算中， 也涉及到函数即服务 （FaaS） ， 应用开发者提供一个事件驱动的 函数给云提供商。 并且随着事件触发器的发生， 云提供商响应无缝拓展的函数调用来符合 需求。 无服务是强大且富有表现力的， 带着设计的应用是针对视频 处理， 高性能计算以及科 学计算， 机器学习， 数据分析， 聊天机器人， 后端， IoT， 以及 普遍的应用程序。 确实， 最近提供 无服务生产的研究显示应用程序在大小上从单个函数到几百个函数， 带着函数的执行时间 从少于1秒到分钟的量级。 因此， 未来允诺快速增长的无服务原生生态系统， 在其中有各种 各样的无服务函数链， 在这里无服务函数会调用后面的无服务函数去创建成分， 必须被各 种各样普遍的框架 支持。 [0003]在云中， 针对云提供商， 当无服务计算简化设计和部署微服务工作方面， 它会有许 多新的挑战关于 资源和调度。 具体制作调 度挑战的工作属性， 特别是在多租户的设置中， 它 们支持来自不同应用程序的微服务， 包括： （1） 函数执行时间是短的，  90%的函数执行少于1 秒， 但是有几个函数的执行是10秒； （2） 因为函数期待被隔离， 它们要求搭建合适的计算单 元， 或者沙箱， 但是这些沙箱可以被用来服务未来的函数请求； （3） 应用程序请求的到达模 式作为一个整体， 并且针对在其中的微服务和 函数， 可能出现巨大变化使得调度器去处理 工作中大量动态变化。 [0004]在大的集群中， 存在针对调度和资源分配 的架构是不能处理 以上要求的。 集中式 调度器并不能扩展去处理低延迟以及每秒高请求的吞吐率要求， 在快速改变的请求到达模 式之下， 它们并没有被设计去提供好的性能。 在另一方面， 分布 式的方法 （比如： Sparrow或 者Ray。 其中Sparrow是一个分布式， 低延迟的调度器。 Ray是针对AI应用的分布式框架） ， 在 这里带着全局视图的多个调度器执行调度 （比如： 通过随机探索机器） 是可拓展的， 但是并 不能找到拥有 可访问重复使用的沙箱机器， 这将会导致沙箱搭建的额外开销。 最后， 存在的 框架并不能统计个别函数的执行时间， 并且因此不能合适的优化DAG请求去确保端到端的 延迟 （这可能包括沙箱的提供和搭建） ， 而这针对到来的应用程序的请求是尽可能的接近执 行时间。 [0005]然而， 在无服务函数链目前状态的管理还留有很多工作可以做。 管理无服务函数 以及函数链的策略是相对简单 的： 目前典型 的调度策略实现了基本的先来先服务算法。 当 限制被实施在 并行运行 的无服务工作上， 要么是来自提供商所迫使的硬件并发限制， 要么 就是由于无效的资源分配所观察到的软件并发限制， 这导致显示无服务应用程序应该在有 挑战的条件下被管 理， 显得不灵活。 而在现有的先进的无服务平台中， 却存在一些明显的问 题。 相应客户的请求不能得到反馈， 或者请求的返回的时间过长。 考虑其内部具体原因， 可 能是相应的平台在设计调度策略的时候， 考虑的因素太片面。 使得某些DAG请求 （多个无服说　明　书 1/10 页 3 CN 115525408 A 3