System.ArgumentOutOfRangeException: 索引和长度必须引用该字符串内的位置。 参数名: length 在 System.String.Substring(Int32 startIndex, Int32 length) 在 zhuanliShow.Bind()
【技术实现步骤摘要】
本专利技术涉及云计算,具体涉及服务器无感知计算场景下工作流中函数间数据传输。
技术介绍
1、近几年来,由于具备对资源和编程的高度抽象、按需使用计费以及动态扩容等优势,服务器无感知计算成为日益流行的云计算开发范式。为实现复杂的实际应用,用户通常以有向无环图的形式将一系列细粒度函数编排成工作流,工作流中定义了函数的顺序以及彼此间的数据依赖。例如公布号为cn117834709a的现有专利技术专利申请文献《面向服务器无感知计算场景的函数间数据直接传递方法》,该现有方法包括:用作前端api端点的网关接收外部函数请求,执行负载平衡,并将其转发到节点内引擎;节点内引擎分派请求给函数,并根据qps决定通知该函数是否和下游函数之间建立dtcs;若函数间不能建立dtcs,则同节点函数间和跨节点函数间分别采用ipc和fabric传输方式数据传输;若函数间能建立dtcs,则同节点函数间和跨节点函数间分别采用dtc_over_ipc和dtc_over_fabric传输方式建立有状态连接,实现函数间数据直接传递。前述当前主流的服务器无感知计算平台将每个函数部署在单独的实例中,由于服务器无感知计算的无状态特性和实例动态伸缩,平台不向用户提供函数实例的实际地址。因此,地址互不感知的实例之间无法建立点对点的直接通信,只能通过第三方路由完成函数间数据的传输。具体而言,上游函数的结果首先通过平台提供的api被全局控制器接收,然后控制器查找存有所有函数实例状态的全局路由表,找到空闲的下游函数实例的地址,最后将收到的数据发送过去。整个传输过程中数据经历多次拷贝,相比实例
2、现有的工作大多通过优化数据转发的效率来加速函数间中间数据传输,例如使用更快的内存型数据库代替磁盘数据库,或者将函数部署在同一节点上,使用高效的进程间通信技术代替协议栈开销高昂的网络通信等。这些方案尽管在延迟上取得了一定改进,但是并没有改变第三方路由的本质,所有的数据传输依然需要经过全局控制器。因此,系统瓶颈的到来只是被推迟,并不能被避免。
3、为了优化服务器无感知计算工作流的吞吐,现有的系统大多聚焦于优化通信方式,使用更快的数据库,亦或使用本地通信代替网络通信等。这些方案通过加速数据转发速率在一定程度上降低了通信延迟,实现了系统吞吐的提升,但是这些基于第三方路由的方案中的每个请求依然经过集中式的控制器,高吞吐下系统瓶颈依然会出现。为克服函数间直连的限制,部分方法先通过第三方路由完成两个实例间的握手,再复用建立的直传连接传输后续的中间数据。但是,基于第三方路由的握手会为关键路径带来高昂的开销,同时复用连接采用的静态路由策略导致实例间的相互锁定,进而引发全部函数的同步实例扩容,致使严重的资源浪费。
4、也有一些工作尝试通过连接复用的方案突破函数间直接通信的限制。具体而言,该方案首先通过第三方路由完成函数实例间的握手,即先交换地址信息,再建立直接连接通道,握手完成后函数实例即可不断复用该通道传输中间数据。尽管该方案通过直连传输实现了最优的通信效率,但是会导致显著的握手开销和低资源效率,进而影响系统吞吐。首先,函数实例间的握手仍然依赖第三方路由完成,并且第一次中间数据传输需要等待握手完成后才开始,所以第一个请求会经历比原本基于第三方路由更高的端到端延迟。此外,上游函数只与每个下游函数的单个实例握手,并不断复用同一个直连通道传输数据,这种静态路由策略导致函数实例间相互锁定,即新扩容出的实例无法再与原有实例直连。因此,系统只能同步扩容其他所有函数并在这些新的实例间重新握手,致使严重的资源浪费,进而限制了系统吞吐的提升。
5、综上,现有技术存在实例间锁定、缺少全局控制器协调导致的路由矛盾、限制系统吞吐性能提高的技术问题。
技术实现思路
1、本专利技术所要解决的技术问题在于:如何解决现有技术中实例间锁定、缺少全局控制器协调导致的路由矛盾、限制系统吞吐性能提高的技术问题。
2、本专利技术是采用以下技术方案解决上述技术问题的:服务器无感知计算工作流吞吐优化的本地路由方法包括:
3、s1、利用全局控制器,将函数路由的功能信息下放至每个函数实例,函数实例根据功能信息,获取存在依赖关系函数实例的地址,与存在依赖关系函数实例建立直传连接,对每个工作流请求动态选择适用路由对象,进行扩容操作;
4、s2、使得函数实例获取其余函数实例的地址并进行直接握手操作,根据函数实例内存中的本地路由表,为每个工作流请求动态选择路由实例;
5、s3、设计稳定和恐慌路由机制,使每个函数实例独立进行动态路由决策,选择数据发送的目的实例,其中,工作流包括:第一函数a、第二函数b以及第三函数c,利用预置扇入结构执行第一函数a、第二函数b以及第三函数c;
6、s4、将函数扩缩容的部分功能也下放至每个实例,构建基于本地路由组的扩缩容机制,以利用函数实例实时监测工作流请求的到达频率、请求执行时间,与集中式控制器协同决策扩缩容策略,并设计本地路由组作为扩缩容管理单位。
7、本专利技术通过本地路由实现支持直接握手和动态路由的数据直传,通过将路由功能由全局控制器下放给每个函数实例以支持高系统吞吐,降低额外握手开销和资源浪费。本专利技术设计稳定/恐慌模式和本地路由组扩缩容等机制,保障本地路由方法下工作流的正确运行和扩缩容,解决了服务器无感知计算工作流中系统吞吐低下的问题。
8、由于全局控制器被从中间数据传输中移除,本专利技术将函数扩缩容的部分功能也下放至每个实例,构建了基于本地路由组的扩缩容机制以满足不同的系统吞吐需要。
9、在更具体的技术方案中,s1包括:
10、s11、利用系统网关,将工作流请求直接发送至入口函数的函数实例,执行函数代码;
11、s12、在当前的函数实例,利用本地控制器查阅本地存储路由表,选择合适的下游函数实例作为适用路由对象,将中间数据直传至适用路由对象;
12、s13、使得函数实例实时监控工作流请求的到达频率、请求自身处理能力,在工作流请求处于排队状态时,请求集中式控制器进行扩容操作。
13、在更具体的技术方案中,s2包括:
14、s21、利用集中式控制器,向新函数实例发送路由表更新信息;
15、s22、函数实例与新函数实例进行握手操作,供后续的工作流请求的直传备选。
16、本专利技术支持函数实例自行获取其他函数实例的地址并进行直接握手,同时在实例内存有本地路由表,可以为每个请求动态选择路由实例,避免实例间锁定。
17、本专利技术将路由能力下放至每个函数实例中,从而实现实例的直接握手和动态路由能力本文档来自技高网...
【技术保护点】
1.服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述方法包括:
2.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S1包括:
3.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S2包括:
4.根据权利要求3所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S22中,对于部署在不同节点的所述函数实例,根据所述本地路由表内存储的IP地址,在所述函数实例间建立TCP连接,通过预置网络连接方式完成数据直传,其中,所述预置网络连接方式包括:RDMA硬件加速跨机通信,以及共享内存与单边RDMA加速大数据传输。
5.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S3包括:
6.根据权利要求5所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S32还包括:
7.根据权利要求5所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S33包括:
8
9.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述S4中,所述本地路由组包括:存在直传连接的所述函数实例,每个所述本地路由组还包括:工作流函数;优先在所述本地路由组内,对所述函数实例进行扩缩容操作。
10.服务器无感知计算工作流吞吐优化的本地路由系统,其特征在于,所述系统包括:
...【技术特征摘要】
1.服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述方法包括:
2.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述s1包括:
3.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述s2包括:
4.根据权利要求3所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述s22中,对于部署在不同节点的所述函数实例,根据所述本地路由表内存储的ip地址,在所述函数实例间建立tcp连接,通过预置网络连接方式完成数据直传,其中,所述预置网络连接方式包括:rdma硬件加速跨机通信,以及共享内存与单边rdma加速大数据传输。
5.根据权利要求1所述的服务器无感知计算工作流吞吐优化的本地路由方法,其特征在于,所述s3包括:
6.根据权利要求5所述的服务器无感知计算工作流...
【专利技术属性】
技术研发人员:赵来平,李一鸣,曲雯毓,刘国威,陈胜,
申请(专利权)人:天津大学合肥创新发展研究院,
类型:发明
国别省市:
还没有人留言评论。发表了对其他浏览者有用的留言会获得科技券。