System.ArgumentOutOfRangeException: 索引和长度必须引用该字符串内的位置。 参数名: length 在 System.String.Substring(Int32 startIndex, Int32 length) 在 zhuanliShow.Bind()
【技术实现步骤摘要】
本专利技术属于云计算,涉及面向服务器无感知计算场景的函数间数据直接传递方法。
技术介绍
1、近年来,由于具备对资源和编程的高度抽象、按需使用计费以及动态扩容等优势,服务器无感知计算成为日益流行的云计算开发范式。为实现复杂的实际应用,用户通常以有向无环图的形式将一系列细粒度函数编排成工作流,工作流中定义了函数的顺序以及彼此间的数据依赖。
2、当前主流的服务器无感知计算平台将函数部署在单独的沙箱执行环境之中,当请求到达后,由于服务器无感知计算的无状态特性,位置互不感知的函数之间无法建立点对点的直接通信,只能通过第三方转发的方式实现函数间中间数据传输。在这种方式下,这些无状态函数通过平台的控制器以及云存储协同配合完成数据传递。在这一过程中,数据流与控制流耦合,交替执行,进而导致不可忽视的通信开销。例如,将一个真实的web应用——media service托管到当前平台后,由于第三方转发引起的中间数据通信延迟可以占到单次请求服务总延迟的77.6%,这导致请求服务总延迟超过了100ms,违反了服务水平目标(slo)。因此,如何解决当前平台函数间数据传递效率低效、通信延迟高的问题,是服务器无感知计算领域的一个重要挑战。
3、为此,已有现有工作在第三方转发方案上提出了优化方案,采用了节点内共享的方法,以改善同节点部署函数间的数据通信。这种技术采取了两种策略来减少传递过程中的开销,从而降低节点内函数间通信的延迟。首先,它利用数据局部性消除了同一节点内函数之间的数据拷贝开销,从而优化了数据流。其次,它采用了更高效的进程间通
技术实现思路
1、针对现有方法中存在的技术问题,本专利技术的目的在于提供面向大场景的群体轨迹预测方法,旨在解决现有服务器无感知计算场景下函数间通信延迟高的问题。
2、为了实现上述目的,本专利技术采用了如下技术方案:
3、面向服务器无感知计算场景的函数间数据直接传递方法,包括以下步骤:
4、s1、用作前端api端点的网关接收外部函数请求,执行负载平衡,并将其转发到节点内引擎;
5、s2、节点内引擎分派请求给上游函数,并根据“建立通道后所产生的收益是否足以覆盖建立开销”决定(即qps决定),通知所述上游函数是否和下游函数之间建立直接传输通道(dtcs);
6、s3、若根据“建立通道后所产生的收益是否足以覆盖建立开销”决定,节点内引擎通知上游函数和下游函数之间不能建立dtcs,则同节点函数之间采用ipc的传输方式进行数据传输,跨节点函数之间采用fabric的传输方式进行数据传输;
7、s4、若根据“建立通道后所产生的收益是否足以覆盖建立开销”决定,节点内引擎通知上游函数和下游函数之间能够建立dtcs,则同节点函数间采用dtc_over_ipc的传输方式建立有状态连接,通过使用linux fifo建立全双工连接,实现节点内函数间数据直接传递;跨节点函数间采用dtc_over_fabric的传输方式建立有状态连接,通过使用rdma在节点之间建立全双工连接,实现跨节点函数间数据直接传递。
8、优选地,步骤s2中,所述节点内引擎根据“建立通道后所产生的收益是否足以覆盖建立开销”来决定是否通知所述上游函数与下游函数之间建立dtcs,具体包括以下步骤:
9、s21、刻画开销:
10、设λ表示分摊dtcs建立开销所需的最小请求数,于是有:
11、
12、其中,tshake表示建立上游函数和下游函数之间dtcs的握手开销;tthird表示使用第三方转发方法在上游函数和下游函数之间传输数据的数据传输延迟;表示使用直接传输方式进行数据传输的数据传输延迟;tshake,tthird和通过离线分析进行表征刻画;
13、s22、预测请求:
14、使用arima模型预测分摊dtcs下一时刻到达的请求数a;
15、s23、进行决策:
16、设talive表示dtcs的保持活动不被释放的时间,即在dtcs传输后保留连接的时间,这里将talive设置为上游函数的保持活动时间,并且dtcs的保持活动时间会随着请求的到达而刷新;
17、设想一种极端情况,如果函数实例在建立dtcs后,刚好服务了λ个请求后被回收,那么dtcs所存在的最大的时间tmax_alive为:
18、tmax_alive=(λ-1)talive (1)
19、那么在每一个时间间隔最少应该到达的请求reqmin_arr为:
20、reqmin_arr=λ/[(λ-1)talive] (2)
21、这里使用reqmin_arr的2倍数作为阈值,因此,只要下式成立,就会建立dtcs:
22、a>2*reqmin_arr (3)。
23、优选地,所述dtc_over_ipc传输方式,通过使用linux fifo建立全双工连接,允许节点内的函数之间进行直接连接,但直连通道的初始建立需要在节点内进行一次ipc往返以在函数间交换握手信息。
24、优选地,所述dtc_over_fabric传输方式,通过使用rdma在节点之间建立全双工连接,使得跨节点部署的函数能够进行直接连接,但直连通道的初始建立需要在节点之间进行fabric往返。
25、优选地,步骤s4中,所述同节点函数间采用dtc_over_ipc的传输方式建立有状态连接,通过使用linux fifo建立全双工连接,实现节点内函数间数据直接传递,包括以下步骤:
26、阶段①:外部调用函数a的请求到达时,节点内引擎将其打包成消息,若决策满足建立dtcs的条件,则节点内引擎在消息头中将dtc控制字段设置为true,并放入分发请求队列;
27、阶段②:一旦函数a有可用的工作进程,消息将发送到workera,workera接收消息后,根据消息头信息更新内部变量method,并执行函数a的代码逻辑来处理消息;
28、阶段③:当workera使用用户接口调用函数b时,根据内部变量method确定数据传输方式,若内部变量method为dtc但当前没有可用的dtcs,则workera生成握手请求消息并发送到节点内引擎;
29、阶段④:函数b的节点内引擎将消息分派本文档来自技高网...
【技术保护点】
1.面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:包括以下步骤:
2.根据权利要求1所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:步骤S2中,所述节点内引擎分派请求给上游函数,并根据“建立通道后所产生的收益是否足以覆盖建立开销”决定,通知所述上游函数是否和下游函数之间建立DTCs,具体包括以下步骤:
3.根据权利要求1所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:所述DTC_over_IPC传输方式,通过使用Linux FIFO建立全双工连接,允许节点内的函数之间进行直接连接,但直连通道的初始建立需要在节点内进行一次IPC往返以在函数间交换握手信息。
4.根据权利要求1所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:所述DTC_over_Fabric传输方式,通过使用RDMA在节点之间建立全双工连接,使得跨节点部署的函数能够进行直接连接,但直连通道的初始建立需要在节点之间进行Fabric往返。
5.根据权利要求2所述的面向服务器无感知计算场景的函数间数据
6.根据权利要求2所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:步骤S4中,所述跨节点函数间采用DTC_over_Fabric的传输方式建立有状态连接,通过使用RDMA在节点之间建立全双工连接,实现跨节点函数间数据直接传递,包括以下步骤:
...【技术特征摘要】
1.面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:包括以下步骤:
2.根据权利要求1所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:步骤s2中,所述节点内引擎分派请求给上游函数,并根据“建立通道后所产生的收益是否足以覆盖建立开销”决定,通知所述上游函数是否和下游函数之间建立dtcs,具体包括以下步骤:
3.根据权利要求1所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特征在于:所述dtc_over_ipc传输方式,通过使用linux fifo建立全双工连接,允许节点内的函数之间进行直接连接,但直连通道的初始建立需要在节点内进行一次ipc往返以在函数间交换握手信息。
4.根据权利要求1所述的面向服务器无感知计算场景的函数间数据直接传递方法,其特...
【专利技术属性】
技术研发人员:赵来平,刘国威,曲雯毓,段兆麟,苏志远,亓开元,
申请(专利权)人:天津大学,
类型:发明
国别省市:
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。