容器更新方法、装置、设备及存储介质
文献发布时间:2024-01-17 01:27:33
技术领域
本公开涉及计算机技术领域和金融科技领域,尤其涉及一种容器更新方法、装置、设备、介质和程序产品。
背景技术
容器是一种沙盒技术,主要目的是为了将应用运行在其中,与外界隔离,及方便这个沙盒可以被转移到其它宿主机器。随着云服务的发展,越来越多的应用采用容器化部署,容器既能解决持续集成、版本控制,又可以实现快速部署、应用隔离,还能实现资源合理利用。
在实现本公开构思的过程中,发明人发现相关技术中至少存在如下问题:对于容器存在的问题,例如:容器内存不足等,皆需要中断服务后再进行处理,同时对于容器存在的问题依据为人为判断,无法保证实时性和准确性。
发明内容
鉴于上述问题,本公开提供了容器更新方法、装置、设备、介质和程序产品。
根据本公开的第一个方面,提供了一种容器更新方法,包括:响应于接收到业务处理请求,基于上述业务处理请求携带的业务信息确定与上述业务信息对应的业务容器;在通过预设监控节点监控得到上述业务容器的第一目标数据的情况下,确定目标时间段内的第二目标数据集合,其中,上述第一目标数据包括第一内存使用量,上述第二目标数据集合包括上述目标时间段内的不同时刻的多个第二内存使用量;基于上述第二目标数据集合确定上述业务容器的内存使用趋势信息;基于上述第一目标数据和上述内存使用趋势信息,生成目标业务容器;以及利用上述目标业务容器更新上述业务容器。
根据本公开的实施例,上述基于上述第二目标数据集合确定上述业务容器的内存使用趋势信息,包括:从上述监控节点在上述目标时间段内监控到的上述第二目标数据集合中,确定历史时刻的第三目标数据和当前时刻的第四目标数据;对上述第三目标数据和上述第四目标数据进行第一计算处理,得到上述业务容器的内存使用趋势信息。
根据本公开的实施例,上述基于上述第一目标数据和上述内存使用趋势信息,生成目标业务容器,包括:确定上述第一目标数据所属数据阈值;基于上述内存使用趋势信息,确定趋势类型;在确定上述数据阈值与上述趋势类型满足预定条件的情况下,生成目标业务容器,其中,上述目标业务容器的内存容量为目标内存容量。
根据本公开的实施例,上述预定条件包括第一预定条件和第二预定条件,上述方法还包括:在上述数据阈值为第一数据阈值且上述趋势类型为上升趋势的情况下,确定上述数据阈值与上述趋势类型满足上述第一预定条件;在上述数据阈值为第二数据阈值且上述趋势类型为下降趋势的情况下,确定上述数据阈值与上述趋势类型满足上述第二预定条件,其中,上述第一数据阈值大于上述第二数据阈值。
根据本公开的实施例,上述在确定上述数据阈值与上述趋势类型满足预定条件的情况下,生成目标业务容器,包括:在确定上述数据阈值与上述趋势类型满足第一预定条件的情况下,基于第一目标内存容量生成上述目标业务容器,其中,上述第一目标内存容量大于上述业务容器的内存容量;在确定上述数据阈值与上述趋势类型满足第二预定条件的情况下,基于第二目标内存容量生成上述目标业务容器,其中,上述第二目标内存容量小于上述业务容器的内存容量。
根据本公开的实施例,上述基于上述第一目标数据和上述内存使用趋势信息,生成目标业务容器,包括:基于上述业务容器的业务处理记录,确定上述业务容器的故障检测信息;在确定上述业务容器的故障检测信息用于表征上述业务容器发生过故障的情况下,基于上述第一目标数据和上述内存使用趋势信息,生成目标业务容器。
根据本公开的实施例,基于上述业务容器的业务处理记录,确定上述业务容器的故障检测信息,包括:从上述业务容器的业务处理记录中确定第一历史处理结果和第二历史处理结果,其中,上述第一历史处理结果和上述第二历史处理结果为图表类型结果;将上述历史处理结果与上述目标处理结果进行比较,确定上述历史处理结果与上述目标处理结果的相似度;在上述相似度大于等于相似度阈值的情况下,确定上述第一历史处理结果和上述第二历史处理结果中存在差异的数据位置;基于与上述数据位置相对应的历史处理数据,确定上述目标业务容器的故障检测信息。
根据本公开的实施例,上述响应于接收到业务处理请求,基于上述业务处理请求携带的业务信息确定与上述业务信息对应的业务容器,包括:响应于接收到业务处理请求,基于上述业务处理请求确定上述业务信息;基于预设配置文件,确定与上述业务信息对应的上述业务容器,其中,上述配置文件中包括上述业务信息与上述业务容器的关联关系。
本公开的第二方面提供了一种容器更新装置,包括:业务容器确定模块,用于响应于接收到业务处理请求,基于上述业务处理请求携带的业务信息确定与上述业务信息对应的业务容器;第二目标数据集合确定模块,用于在通过预设监控节点监控得到上述业务容器的第一目标数据的情况下,确定目标时间段内的第二目标数据集合,其中,上述第一目标数据包括第一内存使用量,上述第二目标数据集合包括上述目标时间段内的不同时刻的多个第二内存使用量;内存使用趋势信息确定模块,用于基于上述第二目标数据集合确定上述业务容器的内存使用趋势信息;目标业务容器生成模块,用于基于上述第一目标数据和上述内存使用趋势信息,生成目标业务容器;以及业务容器更新模块,用于利用上述目标业务容器更新上述业务容器。
本公开的第三方面提供了一种电子设备,包括:一个或多个处理器;存储器,用于存储一个或多个程序,其中,当上述一个或多个程序被上述一个或多个处理器执行时,使得一个或多个处理器执行上述方法。
本公开的第四方面还提供了一种计算机可读存储介质,其上存储有可执行指令,该指令被处理器执行时使处理器执行上述方法。
本公开的第五方面还提供了一种计算机程序产品,包括计算机程序,该计算机程序被处理器执行时实现上述方法。
根据本公开提供的容器更新方法,通过利用业务处理请求确定对应的业务容器,在检测到该业务容器的第一目标数据,即至少监测到某一时刻的内存使用量达到阈值的情况下,确定目标时间段内的第二目标数据集合,再基于第二目标数据集合计算目标时间内的内存使用趋势,基于内存使用趋势和第一目标数据可以生成目标业务容器,最后利用目标业务容器来替换业务容器。由于在检测到第一目标数据的情况下,计算了目标时间段内的内存使用趋势,基于内存使用趋势和第一目标数据来生成符合预期的目标业务容器,因此,至少部分的解决了对于容器存在的问题需要人为判断的技术问题,实现了根据实时数据监测可以快速确定容器内存的使用情况,并基于容器内存的使用情况生成目标业务容器,保障了对问题判断的实时性和可靠性以及新业务容器的高可用性。由于利用了目标业务容器来更新业务容器,因此,至少部分的解决了对于容器存在的问题皆需中断服务后再进行处理的技术问题,实现了对业务容器的自动在线更新,保证了业务处理的连续性以及降低了运维成本。
附图说明
通过以下参照附图对本公开实施例的描述,本公开的上述内容以及其他目的、特征和优点将更为清楚,在附图中:
图1示意性示出了根据本公开实施例的容器更新方法、装置、设备、介质和程序产品的应用场景图;
图2示意性示出了根据本公开实施例的容器更新方法的流程图;
图3示意性示出了根据本公开实施例的确定内存使用趋势信息的流程图;
图4示意性示出了根据本公开实施例的确定业务容器的故障检测信息的流程图;
图5示意性示出了根据本公开实施例的容器更新方法的示意图;
图6示意性示出了根据本公开另一实施例的容器更新方法的流程图;
图7示意性示出了根据本公开实施例的容器更新方法装置的结构框图;以及
图8示意性示出了根据本公开实施例的适于实现容器更新方法的电子设备的方框图。
具体实施方式
以下,将参照附图来描述本公开的实施例。但是应该理解,这些描述只是示例性的,而并非要限制本公开的范围。在下面的详细描述中,为便于解释,阐述了许多具体的细节以提供对本公开实施例的全面理解。然而,明显地,一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外,在以下说明中,省略了对公知结构和技术的描述,以避免不必要地混淆本公开的概念。
在此使用的术语仅仅是为了描述具体实施例,而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了特征、步骤、操作和/或部件的存在,但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。
在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义,除非另外定义。应注意,这里使用的术语应解释为具有与本说明书的上下文相一致的含义,而不应以理想化或过于刻板的方式来解释。
在使用类似于“A、B和C等中至少一个”这样的表述的情况下,一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如,“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。
在本公开的技术方案中,所涉及的数据(如包括但不限于用户个人信息)的收集、存储、使用、加工、传输、提供、公开和应用等处理,均符合相关法律法规的规定,采取了必要保密措施,且不违背公序良俗。
K8s全称Kubernetes,是为容器服务而生的一个可移植容器的编排管理工具。K8s以集群模式部署,由管理节点、工作节点、存储节点组成。管理节点是K8s集群控制节点,管理和控制整个集群。工作节点也叫宿主机,每个工作都会被管理节点分配一些工作负载,当某个工作节点宕机时,该节点上的工作负载(容器)会被管理节点自动转移至其他节点。存储节点为一个高可用分布式键值数据库。
在研究过程中发现,随着云服务的发展,越来越多的应用采用容器技术,在服务的业务流量突增时,可以提升当前容器的CPU、内存等性能容量来提高系统的整体处理能力,也叫做资源预热,即将资源提前扩充/缩容出来,以备有状态容器业务使用,提高容器资源利用率。其中,服务可以包括有状态服务和无状态服务,有状态服务即为需要数据存储持久化的服务。无状态服务为没有特殊状态的服务,各个请求对于服务器来说统一无差别处理,服务端自身不存储跟请求相关的任何数据。其中,容器封装了所有运行应用程序所必须的相关细节,比如应用依赖以及操作系统。
对于容器的扩容期间需要中断服务,影响业务服务的连续性和高可用性。且扩容依据是人工判断,准确性和实时性都难以保证,带来一定的运维成本。在人为监控到资源不足时,再进行资源扩容,存在不够及时的问题,也会影响到业务使用体验。
有鉴于此,本公开的实施例提供了一种容器更新方法,包括:响应于接收到业务处理请求,基于业务处理请求携带的业务信息确定与业务信息对应的业务容器;在通过预设监控节点监控得到业务容器的第一目标数据的情况下,确定目标时间段内的第二目标数据集合,其中,第一目标数据包括第一内存使用量,第二目标数据集合包括目标时间段内的不同时刻的多个第二内存使用量;基于第二目标数据集合确定业务容器的内存使用趋势信息;基于第一目标数据和内存使用趋势信息,生成目标业务容器;以及利用目标业务容器更新业务容器。
图1示意性示出了根据本公开实施例的容器更新方法、装置、设备、介质和程序产品的应用场景图。
如图1所示,根据该实施例的应用场景100可以包括第一终端设备101、第二终端设备102、第三终端设备103。网络104用以在第一终端设备101、第二终端设备102、第三终端设备103和服务器105之间提供通信链路的介质。网络104可以包括各种连接类型,例如有线、无线通信链路或者光纤电缆等等。
用户可以使用第一终端设备101、第二终端设备102、第三终端设备103中的至少一个通过网络104与服务器105交互,以接收或发送消息等。第一终端设备101、第二终端设备102、第三终端设备103上可以安装有各种通讯客户端应用,例如购物类应用、网页浏览器应用、搜索类应用、即时通信工具、邮箱客户端、社交平台软件等(仅为示例)。
第一终端设备101、第二终端设备102、第三终端设备103可以是具有显示屏并且支持网页浏览的各种电子设备,包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。
服务器105可以是提供各种服务的服务器,例如对用户利用第一终端设备101、第二终端设备102、第三终端设备103所浏览的网站提供支持的后台管理服务器(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理,并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。
需要说明的是,本公开实施例所提供的容器更新方法一般可以由服务器105执行。相应地,本公开实施例所提供的容器更新装置一般可以设置于服务器105中。本公开实施例所提供的容器更新方法也可以由不同于服务器105且能够与第一终端设备101、第二终端设备102、第三终端设备103和/或服务器105通信的服务器或服务器集群执行。相应地,本公开实施例所提供的容器更新装置也可以设置于不同于服务器105且能够与第一终端设备101、第二终端设备102、第三终端设备103和/或服务器105通信的服务器或服务器集群中。
应该理解,图1中的终端设备、网络和服务器的数目仅仅是示意性的。根据实现需要,可以具有任意数目的终端设备、网络和服务器。
以下将基于图1描述的场景,通过图2~图6对公开实施例的容器更新方法进行详细描述。
图2示意性示出了根据本公开实施例的容器更新方法的流程图。
如图2所示,该实施例的容器更新方法包括操作S201~操作S205。
在操作S201,响应于接收到业务处理请求,基于业务处理请求携带的业务信息确定与业务信息对应的业务容器。
根据本公开的实施例,在接收到业务处理请求的情况下,可以基于业务信息来确定与该业务信息关联的业务容器,其中,业务容器可以用于处理该业务处理请求。
根据本公开的实施例,如果容器更新方法应用场景为K8s集群,则可以利用通过管理节点接收目标客户端发送业务处理请求,并将客户端的业务处理请求发送至对应的工作节点中的业务容器中。
根据本公开的实施例,通过业务处理请求携带的业务信息可以确定对应的业务容器,从而可以快速的找到相对应的业务容器,进行后续的业务处理过程。
在操作S202,在通过预设监控节点监控得到业务容器的第一目标数据的情况下,确定目标时间段内的第二目标数据集合,其中,第一目标数据包括第一内存使用量,第二目标数据集合包括目标时间段内的不同时刻的多个第二内存使用量。
根据本公开的实施例,通过预设监控节点可以监控得到业务容器的第一目标数据,第一目标数据至少要包括第一内存使用量,第一内存使用量可以为达到数据阈值的内存使用量。
根据本公开的实施例,通过预设监控节点实时不间断的对业务容器目标数据的监控,在监控得到第一目标数据的情况下,可以进行确定目标时间段内的第二目标数据集合,其中,目标时间段可以为监控到第一目标数据的时刻之后的时间段,也可以为包含监控到第一目标数据的时刻的时间段,例如:时刻1、2、3、4、5,其中5为当前时刻,在时刻2时,检测到第一目标数据,则可以认为时刻1~5为目标时间段。也可以认为时刻3~5为目标时间段。
根据本公开的实施例,预设监控节点可以为可以对监控数据进行监控并报警的系统或应用,例如:Prometheus,其中,Prometheus为一个开源的系统监控和报警系统。
根据本公开的实施例,在监控到第一目标数据的情况下,再确定目标时间段内的第二目标数据集合,可以实现节省计算资源的效果,即在没有监控到第一目标数据时,可以先不进行第二目标数据集合的确定,避免了计算资源的浪费。
在操作S203,基于第二目标数据集合确定业务容器的内存使用趋势信息。
根据本公开的实施例,通过对第二目标数据集合中包括的不同时刻的第二目标数据进行计算,可以确定业务容器在目标时间段内的内存使用趋势信息,其中,该内存使用趋势信息中可以包括趋势类型和趋势上升或下降的趋势率,例如:上升率为60%等。
根据本公开的实施例,通过第二目标数据集合确定的业务容器的内存使用趋势信息,可以确定目标时间段内业务容器的内存使用趋势,对于不同的使用趋势可以确定不同的处理方向,避免了由人工进行判断可以导致的不及时或者不够准确的技术问题,节省了一定的运维成本。
在操作S204,基于第一目标数据和内存使用趋势信息,生成目标业务容器。
根据本公开的实施例,第一目标数据可以满足第一数据阈值或第二数据阈值两种数据阈值,当第一目标数据满足第一数据阈值时可以认为该业务容器的内存使用量接近饱和,例如:当业务容器的内存容量为100GB时,第一数据阈值可以为75GB。当第一目标数据满足第二数据阈值时可以认为该业务容器的内存使用量较少,例如:当业务容器的内存容量为100GB时,第二数据阈值可以为35GB。
根据本公开的实施例,基于第一目标数据满足的数据阈值以及内存使用趋势信息中包括的趋势类型,可以确定业务容器的更新方向,例如:基于第一目标数据满足的数据阈值以及内存使用趋势信息中包括的趋势类型得到该业务容器的内存不足,则可以生成内存满足要求的目标业务容器,例如:当业务容器的内存使用量为80GB,总的内存容量为100GB,且处于上升趋势,则可以生成内存容量为120GB的业务容器。
根据本公开的实施例,在得知业务容器的内存不足的情况下,可以通过调用目标线程生成目标业务容器。
根据本公开的实施例,通过第一目标数据和内存使用趋势信息,可以生成符合预期的目标业务容器,在第一目标数据满足的数据阈值与内存使用趋势信息符合预定规则时,可以确定目标业务容器的生成方向,如果处于快速上升趋势且数据阈值为第一数据阈值,则可以生成内存容量更大的目标业务容器,避免业务容器无法对后续过载的业务处理请求进行处理,如果处于快速下降趋势且数据阈值为第二数据阈值,则可以生成内存容量更小的目标业务容器,节省资源利用率。
在操作S205,利用目标业务容器更新业务容器。
根据本公开的实施例,可以利用新生成的目标业务容器替换业务容器,以实现对目标业务容器的更新。
根据本公开提供的容器更新方法,通过利用业务处理请求确定对应的业务容器,在检测到该业务容器的第一目标数据,即至少监测到某一时刻的内存使用量达到阈值的情况下,确定目标时间段内的第二目标数据集合,再基于第二目标数据集合计算目标时间内的内存使用趋势,基于内存使用趋势和第一目标数据可以生成目标业务容器,最后利用目标业务容器来替换业务容器。由于在检测到第一目标数据的情况下,计算了目标时间段内的内存使用趋势,基于内存使用趋势和第一目标数据来生成符合预期的目标业务容器,因此,至少部分的解决了对于容器存在的问题需要人为判断的技术问题,实现了根据实时数据监测可以快速确定容器内存的使用情况,并基于容器内存的使用情况生成目标业务容器,保障了对问题判断的实时性和可靠性以及新业务容器的高可用性。由于利用了目标业务容器来更新业务容器,因此,至少部分的解决了对于容器存在的问题皆需中断服务后再进行处理的技术问题,实现了对业务容器的自动在线更新,保证了业务处理的连续性以及降低了运维成本。
根据本公开的实施例,响应于接收到业务处理请求,基于业务处理请求携带的业务信息确定与业务信息对应的业务容器,可以包括以下操作。
响应于接收到业务处理请求,基于业务处理请求确定业务信息;基于预设配置文件,确定与业务信息对应的业务容器,其中,配置文件中包括业务信息与业务容器的关联关系。
根据本公开的实施例,在接收到业务处理请求的情况下,可以确定业务处理请求中包括的业务信息,根据预设配置文件中包括的业务信息与业务容器的关联关系,确定该业务信息对应的业务容器。
图3示意性示出了根据本公开实施例的确定内存使用趋势信息的流程图。
如图3所示,确定内存使用趋势信息包括操作S301~操作S302。
在操作S301,从监控节点在目标时间段内监控到的第二目标数据集合中,确定历史时刻的第三目标数据和当前时刻的第四目标数据。
在操作S302,对第三目标数据和第四目标数据进行第一计算处理,得到业务容器的内存使用趋势信息。
根据本公开的实施例,历史时刻可以表征在目标时间段内的除当前时刻之外的任意时刻。
根据本公开的实施例,第一处理计算可以包括计算得到内存使用趋势信息的任意计算方式,如公式(1)所示。
其中,ρ表征内存使用量的上升率或者下降率;a表征历史时刻的内存使用量;b表征当前时刻的内存使用量。
根据本公开的实施例,通过第一处理计算可以得到内存使用量的上升率或者下降率,以及内存使用趋势的类型,通过确定趋势类型和内存使用量的上升率或者下降率可以进一步分析是否需要对业务容器进行更新,如果需要则尽快进行业务容器的更新,扩大内存或者缩小内存,以对内存进行在线预热,保证业务的连续性等。
根据本公开的实施例,基于第一目标数据和内存使用趋势信息,生成目标业务容器,还可以包括以下操作。
确定第一目标数据所属数据阈值;基于内存使用趋势信息,确定趋势类型;在确定数据阈值与趋势类型满足预定条件的情况下,生成目标业务容器,其中,目标业务容器的内存容量为目标内存容量。
根据本公开的实施例,可以确定第一目标数据的数据阈值,以及基于内存使用趋势信息来确定趋势类型,如果数据阈值和趋势类型满足预定条件,则可以通过预定条件来生成目标业务容器。
根据本公开的实施例,在确定数据阈值与趋势类型不满足预定条件的情况下,利用业务容器对业务处理请求进行处理;在目标业务容器更新业务容器情况下,利用目标业务容器对业务处理请求进行处理。即在业务容器无需更新的情况下,可以通过业务容器对业务处理请求进行处理,在业务容器需要更新的情况下,可以通过目标业务容器对业务处理请求进行处理。
根据本公开的实施例,预定条件包括第一预定条件和第二预定条件,容器更新方法还可以包括以下操作。
在数据阈值为第一数据阈值且趋势类型为上升趋势的情况下,确定数据阈值与趋势类型满足第一预定条件;在数据阈值为第二数据阈值且趋势类型为下降趋势的情况下,确定数据阈值与趋势类型满足第二预定条件,其中,第一数据阈值大于第二数据阈值。
根据本公开的实施例,在数据阈值为第一数据阈值而且趋势类型为上升趋势的情况下,可以确定数据阈值与趋势类型满足第一预定条件,例如:假设业务容器的内存容量为100GB,已存在第一目标数据满足第一数据阈值为85GB,且趋势类型为上升趋势,可以认为在某一时刻的业务容器的可用内存很小的情况下,其后续的内存使用趋势或者期间的内存使用趋势皆为上升趋势,如果不进行处理很可能导致由于内存爆满无法继续处理业务。
根据本公开的实施例,在第一目标数据的数据阈值为第二数据阈值且趋势类型为下降趋势的情况下,确定数据阈值与趋势类型满足第二预定条件。例如:假设业务容器的内存容量为100GB,已存在第一目标数据满足第二数据阈值为35GB,且趋势类型为下降趋势,可以认为在某一时刻的业务容器的已用内存很小的情况下,其后续的内存使用趋势或者期间的内存使用趋势仍为下降趋势,可能仅使用很小的内存容量就可以完成后续的业务处理工作。
根据本公开的实施例,还可以对不同的趋势类型设定趋势率阈值,如:上升率阈值或者下降率阈值,利用数据阈值、趋势类型和趋势率阈值确定是否满足预定条件。例如:如果在数据阈值为第一数据阈值的前提下,计算得到趋势类型为上升趋势且上升率达到80%的情况下,可以认为满足第一预定条件;如果在数据阈值为第二数据阈值的前提下,计算得到趋势类型为下降趋势且下降率达到30%的情况下,可以认为满足第二预定条件。
根据本公开的实施例,在确定数据阈值与趋势类型满足预定条件的情况下,生成目标业务容器,还可以包括以下操作。
在确定数据阈值与趋势类型满足第一预定条件的情况下,基于第一目标内存容量生成目标业务容器,其中,第一目标内存容量大于业务容器的内存容量;在确定数据阈值与趋势类型满足第二预定条件的情况下,基于第二目标内存容量生成目标业务容器,其中,第二目标内存容量小于业务容器的内存容量。
根据本公开的实施例,在满足第一预定条件的情况下,即某一时刻的业务容器的可用内存很小,且该时刻后续时间段的内存使用趋势或者包含该时刻的时间段的内存使用趋势仍为上升趋势的情况下,如果不进行处理很可能导致由于内存爆满无法继续处理业务的问题,则可以进行内存的在线预热,生成内存容量更大的目标业务容器,保证业务的连续性。
根据本公开的实施例,在满足第二预定条件的情况下,即某一时刻的业务容器的已用内存很小,且该时刻后续时间段的内存使用趋势或者包含该时刻的时间段的内存使用趋势仍为下降趋势的情况下,可能仅使用很小的内存容量就可以完成后续的业务处理工作,则可以进行内存的在线预热,生成内存容量更小的目标业务容器,保证在业务连续的前提下提高资源使用率。
根据本公开的实施例,基于第一目标数据和内存使用趋势信息,生成目标业务容器,还可以包括以下操作。
基于业务容器的业务处理记录,确定业务容器的故障检测信息;在确定业务容器的故障检测信息用于表征业务容器发生过故障的情况下,基于第一目标数据和内存使用趋势信息,生成目标业务容器。
根据本公开的实施例,基于业务容器的业务处理记录,可以确定业务容器的故障检测信息,基于故障检测信息,可以确定该业务容器是否发生过故障以及故障发生率,在该业务容器发生过故障或者故障发生率比较高的情况下,可以再基于第一目标数据和内存使用趋势信息生成目标业务容器。
根据本公开的实施例,故障检测信息可以包括业务容器的故障发生信息、故障发生率和故障发生位置等信息。
根据本公开的实施例,确定业务容器的是否发生过故障,再进行目标业务容器的生成,可以节省计算资源,避免对没问题的业务容器频繁进行更新造成的资源浪费,同时,基于故障检测信息,可以得到处理逻辑更完善的业务容器,避免业务容器存在的问题,目标业务容器还会存在。此外,基于故障检测信息可以帮助运维人员更快速的确定业务容器的故障位置,便于查询故障原因。
图4示意性示出了根据本公开实施例的确定业务容器的故障检测信息的流程图。
如图4所示,确定业务容器的故障检测信息可以包括操作S401~操作S404。
在操作S401,从业务容器的业务处理记录中确定第一历史处理结果和第二历史处理结果,其中,第一历史处理结果和第二历史处理结果为图表类型结果。
在操作S402,将历史处理结果与目标处理结果进行比较,确定历史处理结果与目标处理结果的相似度。
在操作S403,在相似度大于等于相似度阈值的情况下,确定第一历史处理结果和第二历史处理结果中存在差异的数据位置。
在操作S404,基于与数据位置相对应的历史处理数据,确定目标业务容器的故障检测信息。
根据本公开的实施例,可以从业务处理记录中确定两个历史处理结果,其中,该历史处理结果皆为同一类型的业务处理结果。对两个历史处理结果进行比对,确定图片或者图表相似度,如果确定图片或者图表相似度达到相似度阈值则认为两个处理结果可能不存在问题,接着确定二者之间存在差异的位置,确定该存在差异的位置是否为预定位置,如果该存在差异的位置为预定位置则认为两个处理结果同样不存在问题,如果该存在差异的位置是不为预定位置,则可以基于该数据位置对应的历史处理数据来确定目标业务容器的故障检测信息。
根据本公开的实施例,由于历史处理结果皆为同一类型的业务处理结果,则同一类型的业务处理结果的图表是相似的,如果相似度过低则其中一个历史处理结果可能存在问题,则可以将可能存在问题的历史处理结果继续与其他历史处理结果进行比较,若多次比较后相似度仍然较低,则认为该业务处理结果存在问题。
根据本公开的实施例,可以将每个历史处理结果都与不同的历史处理结果进行多次比较,进而可使得故障检测信息的精确度更高。
图5示意性示出了根据本公开实施例的容器更新方法的示意图。
如图5所示,在容器更新方法应用场景为K8s集群时,可以通过管理节点501接收业务处理请求,管理节点501从存储节点502中调用配置文件或者其他数据得到业务信息和业务容器的对应关系,进而找到该业务处理请求对应的工作节点503的业务容器。业务容器内部运行的是具体业务,可以提供业务服务。
根据本公开的实施例,监控节点504对业务容器进行监控,可以实现对业务容器中性能数据的监控,例如:内存使用数据等。
根据本公开的实施例,在监控节点504监控到第一目标数据的情况下,确定目标时间段内的第二目标数据集合,根据第二目标数据集合计算得到内存使用趋势信息。在第一目标数据的数据阈值为第一数据阈值且内存使用趋势信息为上升趋势的情况下,业务容器A需要进行扩容,则生成业务容器B,用业务容器B来替换业务容器A。在第一目标数据的数据阈值为第二数据阈值且内存使用趋势信息为下降趋势的情况下,业务容器C需要进行缩容,则生成业务容器C来替换业务容器A。
根据本公开的实施例,业务容器A、业务容器B和业务容器C的内存容量为示意性的,可根据具体情况设定不同的内存容量。
图6示意性示出了根据本公开另一实施例的容器更新方法的流程图。
如图6所示,另一实施例的容器更新方法包括操作S601~操作S610。
在操作S601,响应于接收到业务处理请求,基于业务处理请求携带的业务信息确定与业务信息对应的业务容器。
在操作S602,在通过预设监控节点监控得到业务容器的第一目标数据的情况下,确定目标时间段内的第二目标数据集合。
在操作S603,基于第二目标数据集合确定业务容器的内存使用趋势信息。
在操作S604,确定第一目标数据所属数据阈值与趋势类型是否满足预定条件。
在操作S605,在数据阈值为第一数据阈值且趋势类型为上升趋势的情况下,确定数据阈值与趋势类型满足第一预定条件。
在操作S606,在数据阈值为第二数据阈值且趋势类型为下降趋势的情况下,确定数据阈值与趋势类型满足第二预定条件。
在操作S607,在确定数据阈值与趋势类型满足第一预定条件的情况下,基于第一目标内存容量生成目标业务容器,其中,第一目标内存容量大于业务容器的内存容量。
在操作S608,在确定数据阈值与趋势类型满足第二预定条件的情况下,基于第二目标内存容量生成目标业务容器,其中,第二目标内存容量小于业务容器的内存容量。
在操作S609,利用目标业务容器处理业务处理请求。
在操作S610,在第一目标数据所属数据阈值与趋势类型不满足预定条件的情况下,确定利用业务容器处理业务处理请求。
基于上述容器更新方法,本公开还提供了一种容器更新装置。以下将结合图7对该装置进行详细描述。
图7示意性示出了根据本公开实施例的容器更新装置的结构框图。
如图7所示,该实施例的容器更新装置700包括业务容器确定模块710、第二目标数据集合确定模块720、内存使用趋势信息确定模块730、目标业务容器生成模块740和业务容器更新模块750。
业务容器确定模块710,用于响应于接收到业务处理请求,基于业务处理请求携带的业务信息确定与业务信息对应的业务容器;
第二目标数据集合确定模块720,用于在通过预设监控节点监控得到业务容器的第一目标数据的情况下,确定目标时间段内的第二目标数据集合,其中,第一目标数据包括第一内存使用量,第二目标数据集合包括目标时间段内的不同时刻的多个第二内存使用量;
内存使用趋势信息确定模块730,用于基于第二目标数据集合确定业务容器的内存使用趋势信息;
目标业务容器生成模块740,用于基于第一目标数据和内存使用趋势信息,生成目标业务容器;以及
业务容器更新模块750,用于利用目标业务容器更新业务容器。
根据本公开的实施例,业务容器确定模块710可以包括:业务信息确定子模块和业务容器确定子模块。
业务信息确定子模块,用于响应于接收到业务处理请求,基于业务处理请求确定业务信息。
业务容器确定子模块,用于基于预设配置文件,确定与业务信息对应的业务容器,其中,配置文件中包括业务信息与业务容器的关联关系。
根据本公开的实施例,内存使用趋势信息确定模块730可以包括:目标数据确定子模块和第一计算处理子模块。
目标数据确定子模块,用于从监控节点在目标时间段内监控到的第二目标数据集合中,确定历史时刻的第三目标数据和当前时刻的第四目标数据。
第一计算处理子模块,用于对第三目标数据和第四目标数据进行第一计算处理,得到业务容器的内存使用趋势信息。
根据本公开的实施例,目标业务容器生成模块740可以包括:数据阈值确定子模块、趋势类型确定子模块和目标业务容器生成子模块。
数据阈值确定子模块,用于确定第一目标数据所属数据阈值。
趋势类型确定子模块,用于基于内存使用趋势信息,确定趋势类型。
目标业务容器生成子模块,用于在确定数据阈值与趋势类型满足预定条件的情况下,生成目标业务容器,其中,目标业务容器的内存容量为目标内存容量。
根据本公开的实施例,预定条件包括第一预定条件和第二预定条件,容器更新装置700还可以包括:第一预定条件满足模块和第二预定条件满足模块。
第一预定条件满足模块,用于在数据阈值为第一数据阈值且趋势类型为上升趋势的情况下,确定数据阈值与趋势类型满足第一预定条件。
第二预定条件满足模块,用于在数据阈值为第二数据阈值且趋势类型为下降趋势的情况下,确定数据阈值与趋势类型满足第二预定条件,其中,第一数据阈值大于第二数据阈值。
根据本公开的实施例,目标业务容器生成子模块可以包括:第一目标业务容器生成单元和第二目标业务容器生成单元。
第一目标业务容器生成单元,用于在确定数据阈值与趋势类型满足第一预定条件的情况下,基于第一目标内存容量生成目标业务容器,其中,第一目标内存容量大于业务容器的内存容量。
第二目标业务容器生成单元,用于在确定数据阈值与趋势类型满足第二预定条件的情况下,基于第二目标内存容量生成目标业务容器,其中,第二目标内存容量小于业务容器的内存容量。
根据本公开的实施例,目标业务容器生成模块740还可以包括:故障检测信息确定模块和目标业务容器更新模块。
故障检测信息确定模块,用于基于业务容器的业务处理记录,确定业务容器的故障检测信息。
目标业务容器更新模块,用于在确定业务容器的故障检测信息用于表征业务容器发生过故障的情况下,基于第一目标数据和内存使用趋势信息,生成目标业务容器。
根据本公开的实施例,故障检测信息确定模块可以包括:历史处理结果确定子模块、相似度确定子模块、数据位置确定子模块和故障检测信息确定子模块。
历史处理结果确定子模块,用于从业务容器的业务处理记录中确定第一历史处理结果和第二历史处理结果,其中,第一历史处理结果和第二历史处理结果为图表类型结果。
相似度确定子模块,用于将历史处理结果与目标处理结果进行比较,确定历史处理结果与目标处理结果的相似度。
数据位置确定子模块,用于在相似度大于等于相似度阈值的情况下,确定第一历史处理结果和第二历史处理结果中存在差异的数据位置。
故障检测信息确定子模块,用于基于与数据位置相对应的历史处理数据,确定目标业务容器的故障检测信息。
根据本公开的实施例,业务容器确定模块710、第二目标数据集合确定模块720、内存使用趋势信息确定模块730、目标业务容器生成模块740和业务容器更新模块750中的任意多个模块可以合并在一个模块中实现,或者其中的任意一个模块可以被拆分成多个模块。或者,这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合,并在一个模块中实现。根据本公开的实施例,业务容器确定模块710、第二目标数据集合确定模块720、内存使用趋势信息确定模块730、目标业务容器生成模块740和业务容器更新模块750中的至少一个可以至少被部分地实现为硬件电路,例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC),或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现,或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者,业务容器确定模块710、第二目标数据集合确定模块720、内存使用趋势信息确定模块730、目标业务容器生成模块740和业务容器更新模块750中的至少一个可以至少被部分地实现为计算机程序模块,当该计算机程序模块被运行时,可以执行相应的功能。
图8示意性示出了根据本公开实施例的适于实现容器更新方法的电子设备的方框图。
如图8所示,根据本公开实施例的电子设备800包括处理器801,其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。处理器801例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如,专用集成电路(ASIC))等等。处理器801还可以包括用于缓存用途的板载存储器。处理器801可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。
在RAM 803中,存储有电子设备800操作所需的各种程序和数据。处理器801、ROM802以及RAM 803通过总线804彼此相连。处理器801通过执行ROM 802和/或RAM 803中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意,程序也可以存储在除ROM802和RAM 803以外的一个或多个存储器中。处理器801也可以通过执行存储在一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。
根据本公开的实施例,电子设备800还可以包括输入/输出(I/O)接口805,输入/输出(I/O)接口805也连接至总线804。电子设备800还可以包括连接至输入/输出(I/O)接口805的以下部件中的一项或多项:包括键盘、鼠标等的输入部分806;包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807;包括硬盘等的存储部分808;以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至输入/输出(I/O)接口805。可拆卸介质811,诸如磁盘、光盘、磁光盘、半导体存储器等等,根据需要安装在驱动器810上,以便于从其上读出的计算机程序根据需要被安装入存储部分808。
本公开还提供了一种计算机可读存储介质,该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的;也可以是单独存在,而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序,当上述一个或者多个程序被执行时,实现根据本公开实施例的方法。
根据本公开的实施例,计算机可读存储介质可以是非易失性的计算机可读存储介质,例如可以包括但不限于:便携式计算机磁盘、硬盘、随机访问存储器(RAM)、只读存储器(ROM)、可擦式可编程只读存储器(EPROM或闪存)、便携式紧凑磁盘只读存储器(CD-ROM)、光存储器件、磁存储器件、或者上述的任意合适的组合。在本公开中,计算机可读存储介质可以是任何包含或存储程序的有形介质,该程序可以被指令执行系统、装置或者器件使用或者与其结合使用。例如,根据本公开的实施例,计算机可读存储介质可以包括上文描述的ROM 802和/或RAM 803和/或ROM 802和RAM 803以外的一个或多个存储器。
本公开的实施例还包括一种计算机程序产品,其包括计算机程序,该计算机程序包含用于执行流程图所示的方法的程序代码。当计算机程序产品在计算机系统中运行时,该程序代码用于使计算机系统实现本公开实施例所提供的容器更新方法。
在该计算机程序被处理器801执行时执行本公开实施例的系统/装置中限定的上述功能。根据本公开的实施例,上文描述的系统、装置、模块、单元等可以通过计算机程序模块来实现。
在一种实施例中,该计算机程序可以依托于光存储器件、磁存储器件等有形存储介质。在另一种实施例中,该计算机程序也可以在网络介质上以信号的形式进行传输、分发,并通过通信部分809被下载和安装,和/或从可拆卸介质811被安装。该计算机程序包含的程序代码可以用任何适当的网络介质传输,包括但不限于:无线、有线等等,或者上述的任意合适的组合。
在这样的实施例中,该计算机程序可以通过通信部分809从网络上被下载和安装,和/或从可拆卸介质811被安装。在该计算机程序被处理器801执行时,执行本公开实施例的系统中限定的上述功能。根据本公开的实施例,上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。
根据本公开的实施例,可以以一种或多种程序设计语言的任意组合来编写用于执行本公开实施例提供的计算机程序的程序代码,具体地,可以利用高级过程和/或面向对象的编程语言、和/或汇编/机器语言来实施这些计算程序。程序设计语言包括但不限于诸如Java,C++,python,“C”语言或类似的程序设计语言。程序代码可以完全地在用户计算设备上执行、部分地在用户设备上执行、部分在远程计算设备上执行、或者完全在远程计算设备或服务器上执行。在涉及远程计算设备的情形中,远程计算设备可以通过任意种类的网络,包括局域网(LAN)或广域网(WAN),连接到用户计算设备,或者,可以连接到外部计算设备(例如利用因特网服务提供商来通过因特网连接)。
附图中的流程图和框图,图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分,上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如,两个接连地表示的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图或流程图中的每个方框、以及框图或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的系统来实现,或者可以用专用硬件与计算机指令的组合来实现。
本领域技术人员可以理解,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合或/或结合,即使这样的组合或结合没有明确记载于本公开中。特别地,在不脱离本公开精神和教导的情况下,本公开的各个实施例和/或权利要求中记载的特征可以进行多种组合和/或结合。所有这些组合和/或结合均落入本公开的范围。
以上对本公开的实施例进行了描述。但是,这些实施例仅仅是为了说明的目的,而并非为了限制本公开的范围。尽管在以上分别描述了各实施例,但是这并不意味着各个实施例中的措施不能有利地结合使用。本公开的范围由所附权利要求及其等同物限定。不脱离本公开的范围,本领域技术人员可以做出多种替代和修改,这些替代和修改都应落在本公开的范围之内。
- 一种存储器数据更新方法、装置、设备及存储介质
- 一种CPLD版本更新方法、装置、设备及存储介质
- 一种定位信息更新方法、装置、设备及存储介质
- 页面信息更新方法、装置、计算机设备及存储介质
- 一种固件更新的方法、系统、装置、设备及存储介质
- 容器云平台更新展示方法、装置、电子设备及存储介质
- 一种容器更新方法、装置、电子设备及存储介质