服务内存信息的负载均衡方法、装置、存储介质和设备转让专利

申请号 : CN202211639798.5

文献号 : CN116126521B

文献日 :

基本信息:

PDF:

法律信息:

相似专利:

发明人 : 杨娟翟士丹葛永全王道广鲍红飞于政

申请人 : 北京海致星图科技有限公司

摘要 :

本发明实施例提供一种服务内存信息的负载均衡方法、装置、存储介质和设备,该方法包括:监控服务接收上游应用服务监控数据获取请求,监控服务根据监控数据获取请求,获取各应用服务的监控数据,当监控服务中存在监控数据时,读取监控数据并将监控数据发送至上游应用服务,当监控服务中不存在监控数据时,读取各应用服务当前的内存数据进行汇总,最后将监控数据返回至上游应用服务,以使上游应用服务根据监控数据选择目标应用服务进行调用。本发明能够进行分布式部署,实时监控各应用服务内存中的数据,根据各应用服务的内存情况进行负载均衡,从而保证各应用服务功能的效果一致,且对单个服务器的硬件要求不高,应用服务数量可扩展,支持高并发。

权利要求 :

1.一种服务内存信息的负载均衡方法,其特征在于,所述方法包括:监控服务接收上游应用服务监控数据获取请求,所述监控数据获取请求用于获取各应用服务中内存使用情况;

监控服务根据所述监控数据获取请求,获取各应用服务的监控数据;

当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据返回至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用;

当监控服务中不存在监控数据时,读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用;其中,所述监控数据包括各应用服务的内存变更数据和内存情况数据,获取各应用服务的监控数据包括:所述各应用服务定时将各自的内存情况数据上传至中间件集群,所述监控服务通过所述中间件集群接收各应用服务的内存情况数据;

所述各应用服务中内存数据发生变更时将内存变更数据写入redis服务,所述监控服务定时读取所述redis服务中各应用服务中内存变更数据;

所述内存情况数据包括各应用服务健康状态、服务名、服务IP、服务端口号、服务中的监控内存数据关键值的集合;其中,所述上游应用服务根据所述监控数据选择目标应用服务进行调用包括:所述上游应用服务过滤掉所述监控数据中不完全包含需要使用的内存值的应用服务;

以及过滤掉最新变更状态与所述中间件集群中其他应用服务不一致的应用服务;

所述上游应用服务从过滤后的应用服务中随机选择目标应用程序进行调用。

2.根据权利要求1所述的方法,其特征在于,获取各应用服务的监控数据前,所述方法还包括:所述监控服务获取各应用服务的监控数据的当前版本号,并将所述当前版本号发送至redis服务中存储,其中,所述当前版本号为各应用服务的监控数据发生变更时生成的标识信息;

所述监控服务根据所述当前版本号查询各应用服务的监控数据。

3.根据权利要求1所述的方法,其特征在于,读取各应用服务当前的监控数据进行汇总包括:所述监控服务遍历各应用服务当前的监控数据;

所述监控服务将各应用服务的内存变更数据和内存情况数据进行汇总,获得汇总数据。

4.根据权利要求3所述的方法,其特征在于,读取各应用服务当前的监控数据进行汇总后,所述方法还包括:所述监控服务根据各应用服务的内存变更数据和内存情况数据,获得各应用服务中活跃内存的关键值;

所述监控服务将各应用服务中活跃内存的内存数据和详细数据同时存入redis服务和mysql服务,其中,redis服务数据用于展示所述监控数据实时变更情况,以及为上游应用服务提供目标应用服务的可用情况,mysql服务数据用于审计目标应用服务的活跃状态和高可用情况。

5.一种服务内存信息的负载均衡装置,其特征在于,所述装置包括:获取模块,用于通过监控服务接收上游应用服务监控数据获取请求,所述监控数据获取请求用于获取各应用服务中内存活跃情况;

监控模块,用于通过监控服务根据所述监控数据获取请求,获取各应用服务的监控数据;

第一返回模块,用于当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据返回至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用;

第二返回模块,用于当监控服务中不存在监控数据时,读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用;其中,所述监控模块获取的监控数据包括各应用服务的内存变更数据和内存情况数据,监控模块包括:内存情况获取单元,用于通过中间件集群接收各应用服务的内存情况数据,各应用服务的内存情况数据由所述各应用服务定时将各自的内存情况数据上传至中间件集群;

内存变更数据获取单元,用于定时读取redis服务中各应用服务中内存变更数据,各应用服务中内存变更数据由所述各应用服务中内存数据发生变更时将内存变更数据写入redis服务;

所述内存情况数据包括各应用服务健康状态、服务名、服务IP、服务端口号、服务中的监控内存数据关键值的集合;其中,第二返回模块中所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用时具体通过以下方式实现:所述上游应用服务过滤掉所述监控数据中不完全包含需要使用的内存值的应用服务,以及过滤掉最新变更状态与所述中间件集群中其他应用服务不一致的应用服务;所述上游应用服务从过滤后的应用服务中随机选择目标应用程序进行调用。

6.一种存储介质,其特征在于,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述权利要求1至4中任一项所述的方法。

7.一种设备,包括存储器和处理器,其特征在于,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行所述权利要求1至4中任一项所述的方法。

说明书 :

服务内存信息的负载均衡方法、装置、存储介质和设备

技术领域

[0001] 本发明涉及数据处理技术领域,尤其涉及一种服务内存信息的负载均衡方法、装置、存储介质和设备。

背景技术

[0002] 随着科技的发展日新月异,各种互联网系统应运而生,人工智能领域的发展又进一步推高系统的整体复杂度。在涉及到大计算量、大模型的应用系统中,难免会有大量数据用于计算,而这些数据由于数据量较大,无法放到分布式缓存中,只能存在内存中。
[0003] 基于以上情况,往往此类服务只能单机部署,且对服务器资源要求很高,然而并不能支持常见的高并发需求。在分布式部署的情况下,又会存在以下问题。
[0004] 其一,由于网络原因、部署硬件原因、或者中间件原因,很难保证内存数据的一致性,进而不能在分布式部署对外提供服务时保持服务效果的一致性。
[0005] 其二,针对服务内存数据无监控,内存中加载的数据内容不可见,不能从外部清晰的判断服务当前状态。
[0006] 其三,服务效果不一致不可追溯。数据存在内存中,数据变更无历史记录,只能实时应用不能追溯服务内存的历史状态变化。
[0007] 以问答系统为例,人们日常生活中会产生大量的数据。这些数据中包括以明确知识存在的FAQ问答对,以非结构化文本存在的如规章制度、技术文档,以及各种系统产生的关系型数据和知识图谱数据。人们往往需要从这些数据中获取信息。而想要从如此庞大复杂的数据中获取有用信息,并不是一件容易的事情。
[0008] 目前具有如此强大能力的问答系统还比较少,比较好的方案是问答系统内部,根据领域不同、数据不同和召回答案的方案不同等因素,分成多种能力。这些能力可能涉及到不同的模型和数据,将这些能力统一加载到内存中,用于答案的快速召回排序。通常只能使用单机部署应用,不支持服务横向扩展,服务中有大量数据存在于内存中以用于计算。这样保证了服务效果的一致性,但存在对硬件要求高,且并发底不支持扩展的问题。

发明内容

[0009] 有鉴于此,本发明提供一种服务内存信息的负载均衡方法、装置、存储介质和设备,能够进行分布式部署,实时监控各应用服务内存中的数据,根据各应用服务的内存情况进行负载均衡,从而保证各应用服务功能的效果一致,以及服务内存数据活跃状态可回溯,且对单个服务器的硬件要求不高,应用服务数量可扩展,支持高并发。
[0010] 第一方面,本发明实施例提供一种服务内存信息的负载均衡方法,所述方法包括:
[0011] 监控服务接收上游应用服务监控数据获取请求,所述监控数据获取请求用于获取各应用服务中内存活跃情况;
[0012] 监控服务根据所述监控数据获取请求,获取各应用服务的监控数据;
[0013] 当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据返回至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用;
[0014] 当监控服务中不存在监控数据时,读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用。
[0015] 进一步地,所述监控数据包括各应用服务的内存变更数据和内存情况数据,获取各应用服务的监控数据包括:
[0016] 所述各应用服务定时将各自的内存情况数据上传至中间件集群,所述监控服务通过所述中间件集群接收各应用服务的内存情况数据;
[0017] 所述各应用服务中内存数据发生变更时将内存变更数据写入redis服务,所述监控服务定时读取所述redis服务中各应用服务中内存变更数据。
[0018] 进一步地,所述内存情况数据包括各应用服务健康状态、服务名、服务IP、服务端口号、服务中的监控内存数据关键值的集合。
[0019] 进一步地,获取各应用服务的监控数据前,所述方法还包括:
[0020] 所述监控服务获取各应用服务的监控数据的当前版本号,并将所述当前版本号发送至redis服务中存储,其中,所述当前版本号为各应用服务的监控数据发生变更时生成的标识信息;
[0021] 所述监控服务根据所述当前版本号查询各应用服务的监控数据。
[0022] 进一步地,读取各应用服务当前的监控数据进行汇总包括:
[0023] 所述监控服务遍历各应用服务当前的监控数据;
[0024] 所述监控服务将各应用服务的内存变更数据和内存情况数据进行汇总,获得汇总数据。
[0025] 进一步地,读取各应用服务当前的监控数据进行汇总后,所述方法还包括:
[0026] 所述监控服务根据各应用服务的内存变更数据和内存情况数据,获得各应用服务中活跃内存的关键值;
[0027] 所述监控服务将各应用服务中活跃内存的内存数据和详细数据同时存入redis服务和mysql服务,其中,redis服务数据用于展示所述监控数据实时变更情况,以及为上游应用服务提供目标应用服务的可用情况,所述mysql服务数据用于审计目标应用服务的活跃状态和高可用情况。
[0028] 进一步地,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用包括:
[0029] 所述上游应用服务过滤掉所述监控数据中不完全包含需要使用的内存值的应用服务;
[0030] 以及过滤掉最新变更状态与所述中间件集群中其他应用服务不一致的应用服务;
[0031] 所述上游应用服务从过滤后的应用服务中随机选择目标应用程序进行调用。
[0032] 第二方面,本发明实施例提供一种服务内存信息的负载均衡装置,所述装置包括:
[0033] 获取模块,用于通过监控服务接收上游应用服务监控数据获取请求,所述监控数据获取请求用于获取各应用服务中内存活跃情况;
[0034] 监控模块,用于通过监控服务根据所述监控数据获取请求,获取各应用服务的监控数据;
[0035] 第一返回模块,用于当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据返回至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用;
[0036] 第二返回模块,用于当监控服务中不存在监控数据时,读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用。
[0037] 第三方面,本发明实施例提供一种存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行所述第一方面中任一项所述的方法。
[0038] 第四方面,本发明实施例提供一种设备,包括存储器和处理器,所述存储器中存储有计算机程序,所述处理器被设置为运行所述计算机程序以执行所述第一方面中任一项所述的方法。
[0039] 本发明提供的技术方案,通过监控服务接收上游应用服务监控数据获取请求,监控服务根据监控数据获取请求获取各应用服务的监控数据,当存在监控数据时,所述监控服务将各应用服务的监控数据发送至上游应用服务,当不存在监控数据时,所述监控服务读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以是上游应用服务根据汇总后的监控数据选择目标应用程序。由此,本发明能够根据实际中每个应用服务节点内的内存情况进行服务内存监控,实时展示每个应用服务节点的内存数据,根据服务内存监控情况实现服务调用的负载均衡,合理利用服务资源并且保证服务效果的一致性,实时记录内存监控数据,实现内存数据活跃状态回溯,实现大计算量、大模型、大内存数据服务分布式部署,降低对单个服务器硬件资源要求,并且提高系统并发性能。

附图说明

[0040] 图1是本发明实施例一提供的服务内存信息的负载均衡方法中用到的业务系统示意图;
[0041] 图2是本发明实施例一提供的服务内存信息的负载均衡方法的流程图;
[0042] 图3是本发明实施例二提供的服务内存信息的负载均衡方法的交互示意图;
[0043] 图4是本发明实施例三提供的服务内存信息的负载均衡装置的结构示意图;
[0044] 图5是本发明实施例四提供的电子设备的结构示意图。

具体实施方式

[0045] 为了使本发明的目的、技术方案和优点更加清楚,下面将结合附图对本发明作进一步地详细描述,显然,所描述的实施例仅仅是本发明一部份实施例,而不是全部的实施例。基于本发明中的实施例,本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其它实施例,都属于本发明保护的范围。
[0046] 实施例一
[0047] 参见图1,是本发明实施例一提供的服务内存信息的负载均衡方法中用到的业务系统示意图,本发明用于服务内存信息的负载均衡方法的系统可包括多个应用服务、监控服务和上游应用服务。
[0048] 其中,多个应用服务中包含目标应用服务,在本申请中指的是实际要被上游应用服务调用的服务,其中大量数据存在于内存中,且针对该应用服务的内存数据做应用服务的负载均衡。
[0049] 上游应用服务指的是业务系统中实际调用目标应用服务的服务。
[0050] 监控服务指的是用于汇总和展示各应用服务的内存监控数据,并为上游应用服务的调用目标应用服务的负载均衡提供数据支持。
[0051] 在本申请中,所有应用服务都能注册到nacos服务,以及所有应用服务都能正常使用redis服务和mysql服务。其中,nacos服务(DynamicNamingand ConfigurationService,简称nacos)一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台,能够发现、配置和管理微服务,具有以下特性:服务发现和服务健康监测,动态配置服务,动态DNS服务,服务及其元数据管理。Redis服务(RemoteDictionaryServer,简称Redis),即远程字典服务,是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key‑Value数据库,并提供多种语言的API。MySQL是一种关系型数据库管理系统,关系数据库将数据保存在不同的表中,而不是将所有数据放在一个大仓库内,这样就增加了速度并提高了灵活性。
[0052] 在本申请中,监控服务用于对各应用程序的内存数据进行监控,也即能够获取到各应用服务的监控数据。具体地,监控服务对各应用服务的内存数据进行监控分为两个部分,包括各应用服务的内存变更数据和内存情况数据。
[0053] 其一,各应用服务的内存情况数据统一上报到nacos服务集群中,在注册时将需要上报的数据写入nacos注册信息的matadata中,nacos服务集群再将各应用服务的监控数据发送至监控服务中。其中,各应用服务的内存情况数据必须包含本应用服务的5个信息,分别是服务健康状态、服务名、服务ip、服务端口号、服务中的监控内存数据关键值的集合。
[0054] 其二,各应用服务内存中数据变更情况,分别写入到redis服务中,存储为hash数据类型,以关键变动的内存数据关键值作为key,以“服务名+服务ip+服务端口号”作为hash中的name,以实际变更关键变动的内存数据内容作为value。
[0055] 同时,在监控服务中,能够自定义各应用程序的版本号,控制使用各应用程序的最新监控数据。具体地,每次监控数据变更,都生成一个新的唯一值,作为本次数据变更的版本号。并把该版本号作为分布式缓存存入redis服务中,每次从监控服务中获取监控数据之前,必须先获取当前最新版本号,再根据版本号查询当前最新的监控数据。版本号定义方式为当前时间戳。
[0056] 同时,监控服务每次对获取到的监控数据需汇总,汇总方法是,遍历每个服务的监控数据,再分别统计各应用服务中活跃内存数据的关键值。汇总后每个活跃内存数据将汇总数据和详细数据同时存入redis服务和mysql服务。redis服务数据用于页面展示监控数据实时变更情况,以及为上游应用服务提供当前目标应用服务的可用情况。mysql服务用于事后统计目标应用服务的活跃状态和高可用情况。
[0057] 上游应用服务能够从监控服务中获取到各应用服务的监控数据,根据监控数据选择目标应用程序。具体地,上游应用服务在调用目标应用服务之前,从监控服务中获取目标应用服务中内存活跃情况,过虑掉不完全包含需要使用的内存值的应用,过滤掉最新变更状态与nacos集群中其它服务不一致的服务,再随机调用目标应用程序。
[0058] 由此,本发明通过通过nacos注册信息的matadata监控全量的应用服务内存信息,通过redis服务上报传递各应用服务的内存变更信息,因此,监控服务能够实时获取各应用服务的当前内存情况,调用服务之前实时获取内存监控数据,在做业务过虑之后确定可用服务。能够进行分布式部署,实时监控各应用服务内存中的数据,根据各应用服务的内存情况进行负载均衡,从而保证各应用服务功能的效果一致,且对单个服务器的硬件要求不高,应用服务数量可扩展,支持高并发。
[0059] 请参见图2,图2是本发明实施例一提供的服务内存信息的负载均衡方法的流程图,所述方法包括:
[0060] 步骤101、监控服务接收上游应用服务监控数据获取请求,所述监控数据获取请求用于获取各应用服务中内存使用情况。
[0061] 在本步骤中,当上游应用需要调用目标应用程序时,向监控服务发送上游应用服务监控数据获取请求,上游应用服务监控数据获取请求用于获取各应用服务中内存使用情况。
[0062] 步骤102、监控服务根据所述监控数据获取请求,获取各应用服务的监控数据。
[0063] 在本步骤中,监控服务接收到上游应用服务发来的监控数据获取请求,获取各应用服务的监控数据。所述监控数据包括各应用服务的内存变更数据和内存情况数据,具体地,所述各应用服务定时将各自的内存情况数据上传至中间件集群,所述监控服务通过所述中间件集群接收各应用服务的内存情况数据;所述各应用服务中内存数据发生变更时将内存变更数据写入redis服务,所述监控服务定时读取所述redis服务中各应用服务中内存变更数据。由此,监控服务能够实时获得各应用服务的监控数据。
[0064] 在另一些实施例中,监控服务获取各应用服务的内存情况数据还可采用其他方式来实现,比如常见的各应用服务节点通过http定时直接上报各应用服务的内存信息,或者监控服务通过心跳检测去查询各应用服务节点的内存状况,或者各服务节点通过发送MQ消息上报各应用服务内存信息至监控服务中。
[0065] 在一些实施例中,所述内存情况数据包括各应用服务健康状态、服务名、服务IP、服务端口号、服务中的监控内存数据关键值的集合。
[0066] 在一些实施例中,获取各应用服务的监控数据前,所述方法还可包括:
[0067] 步骤102a、所述监控服务获取各应用服务的监控数据的当前版本号,并将所述当前版本号发送至redis服务中存储,其中,所述当前版本号为各应用服务的监控数据发生变更时生成的标识信息;
[0068] 步骤102b、所述监控服务根据所述当前版本号查询各应用服务的监控数据。
[0069] 也即在监控服务中,每次监控数据变更,都生成一个新的唯一值,作为本次数据变更的版本号。并把该版本号作为分布式缓存存入redis服务中,每次从监控服务中获取各应用服务监控数据之前,必须先获取各应用服务当前最新版本号,再根据版本号查询各应用服务当前最新的监控数据。版本号定义方式为当前时间戳。
[0070] 步骤103、当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据发送至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用。
[0071] 在本步骤中,监控服务判断各应用服务是否存在监控数据,当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据返回至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用。
[0072] 步骤104、当监控服务中不存在监控数据时,读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用。
[0073] 在本步骤中,监控服务判断各应用服务不存在监控数据,则需要对各应用服务的监控数据进行刷新。具体地,所述监控服务遍历各应用服务当前的监控数据,所述监控服务将各应用服务的内存变更数据和内存情况数据进行汇总,获得汇总数据。之后所述监控服务根据各应用服务的内存变更数据和内存情况数据,获得各应用服务中活跃内存的关键值,所述监控服务将各应用服务中活跃内存的内存数据和详细数据同时存入redis服务和mysql服务,其中,redis服务数据用于展示所述监控数据实时变更情况,以及为上游应用服务提供目标应用服务的可用情况,所述mysql服务数据用于审计目标应用服务的活跃状态和高可用情况。
[0074] 在一些实施例中,所述上游应用服务根据所述监控数据选择目标应用服务进行调用包括:上游应用服务过滤掉所述监控数据中不完全包含需要使用的内存值的应用服务,以及过滤掉最新变更状态与所述中间件集群中其他应用服务不一致的应用服务,所述上游应用服务从过滤后的应用服务中随机选择目标应用程序进行调用。
[0075] 由此,本发明通过监控服务接收上游应用服务监控数据获取请求,监控服务根据监控数据获取请求获取各应用服务的监控数据,当存在监控数据时,所述监控服务将各应用服务的监控数据发送至上游应用服务,当不存在监控数据时,所述监控服务读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使上游应用服务根据汇总后的监控数据选择目标应用程序。由此,本发明能够根据实际中每个应用服务节点内的内存情况进行服务内存监控,实时展示每个应用服务节点的内存数据,根据服务内存监控情况实现服务调用的负载均衡,合理利用服务资源并且保证服务效果的一致性,实时记录内存监控数据,实现内存数据活跃状态回溯,实现大计算量、大模型、大内存数据服务分布式部署,降低对单个服务器硬件资源要求,并且提高系统并发性能。
[0076] 实施例二
[0077] 请参见图3,图3是本发明实施例二提供的服务内存信息的负载均衡方法的交互示意图。
[0078] 首先,当上游应用需要调用目标应用程序时,向监控服务发送上游应用服务监控数据获取请求,监控数据获取请求用于获取各应用服务中内存使用情况。
[0079] 其次,监控服务接收到上游应用服务发来的监控数据获取请求,判断各应用服务的监控数据是否存在,如存在,读取所述监控数据并将所述监控数据返回至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用;如不存在,则刷新监控数据,具体为监控服务遍历各应用服务当前的监控数据,遍历redis服务中各应用服务的内容变更数据和mysql服务中各应用服务的内存情况数据,之后将各各应用服务的内容变更数据内存情况数据进行汇总后均写入redis服务和mysql服务,使得redis服务和mysql服务存储有各应用程序的监控数据;之后读取redis服务和mysql服务存储有各应用程序的监控数据发送至上游应用服务。
[0080] 第三,上游应用服务接收监控服务发来的各应用服务的监控数据,过滤掉所述监控数据中不完全包含需要使用的内存值的应用服务,以及过滤掉最新变更状态与所述中间件集群中其他应用服务不一致的应用服务,之后上游应用服务判断是否存在可使用的应用服务,如存在,则选择可用应用服务随机调用;如不存在,则结束应用。
[0081] 第四,目标应用服务接收上游应用服务的调用请求,根据所述调用请求执行核心业务,并将所述核心业务的运行结果发送至上游应用服务。
[0082] 由此,本发明通过监控服务接收上游应用服务监控数据获取请求,监控服务根据监控数据获取请求获取各应用服务的监控数据,当存在监控数据时,所述监控服务将各应用服务的监控数据发送至上游应用服务,当不存在监控数据时,所述监控服务读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使上游应用服务根据汇总后的监控数据选择目标应用程序。由此,本发明能够根据实际中每个应用服务节点内的内存情况进行服务内存监控,实时展示每个应用服务节点的内存数据,根据服务内存监控情况实现服务调用的负载均衡,合理利用服务资源并且保证服务效果的一致性,实时记录内存监控数据,实现内存数据活跃状态回溯,实现大计算量、大模型、大内存数据服务分布式部署,降低对单个服务器硬件资源要求,并且提高系统并发性能。
[0083] 实施例三
[0084] 参见图4,图4是本发明实施例三提供的服务内存信息的负载均衡装置的结构示意图,所述装置包括:
[0085] 获取模块21,用于通过监控服务接收上游应用服务监控数据获取请求,所述监控数据获取请求用于获取各应用服务中内存活跃情况;
[0086] 监控模块22,用于通过监控服务根据所述上游应用服务监控数据获取请求,获取各应用服务的监控数据;
[0087] 第一发送模块23,用于当监控服务中存在监控数据时,读取所述监控数据并将所述监控数据发送至上游应用服务,以使所述上游应用服务根据所述监控数据选择目标应用服务进行调用;
[0088] 第二发送模块24,用于当监控服务中不存在监控数据时,读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使所述上游应用服务根据汇总后的监控数据选择目标应用服务进行调用。
[0089] 在一些实施例中,监控模块22获取的监控数据包括各应用服务的内存变更数据和内存情况数据,监控模块22可包括:
[0090] 内存情况获取单元221,用于通过所述中间件集群接收各应用服务的内存情况数据,各应用服务的内存情况数据由所述各应用服务定时将各自的内存情况数据上传至中间件集群;
[0091] 内存变更数据获取单元222,用于定时读取所述redis服务中各应用服务中内存变更数据,各应用服务中内存变更数据由所述各应用服务中内存数据发生变更时将内存变更数据写入redis服务。
[0092] 在一些实施例中,所述内存情况数据包括各应用服务健康状态、服务名、服务IP、服务端口号、服务中的监控内存数据关键值的集合。
[0093] 在一些实施例中,所述装置还包括:
[0094] 版本号更新模块25,用于获取各应用服务的监控数据的当前版本号,并将所述当前版本号发送至redis服务中存储,其中,所述当前版本号为各应用服务的监控数据发生变更时生成的标识信息;
[0095] 查询模块26,用于根据所述当前版本号查询各应用服务的监控数据。
[0096] 在一些实施例中,第二发送模块24可包括:
[0097] 遍历单元241,用于遍历各应用服务当前的监控数据;
[0098] 汇总单元242,用于将各应用服务的内存变更数据和内存情况数据进行汇总,获得汇总数据。
[0099] 在一些实施例中,第二发送模块24还可包括:
[0100] 获取单元243,用于根据各应用服务的内存变更数据和内存情况数据,获得各应用服务中活跃内存的关键值;
[0101] 发送单元244,用于将各应用服务中活跃内存的内存数据和详细数据存入同时发送至redis服务和mysql服务,其中,redis服务数据用于展示所述监控数据实时变更情况,以及为上游应用服务提供目标应用服务的可用情况,所述mysql服务数据用于审计目标应用服务的活跃状态和高可用情况。
[0102] 在一些实施例中,所述上游应用服务过滤掉所述监控数据中不完全包含需要使用的内存值的应用服务,以及过滤掉最新变更状态与所述中间件集群中其他应用服务不一致的应用服务;所述上游应用服务从过滤后的应用服务中随机选择目标应用程序进行调用。
[0103] 由此,本发明通过监控服务接收上游应用服务监控数据获取请求,监控服务根据监控数据获取请求获取各应用服务的监控数据,当存在监控数据时,所述监控服务将各应用服务的监控数据发送至上游应用服务,当不存在监控数据时,所述监控服务读取各应用服务当前的监控数据进行汇总,并返回至上游应用服务,以使上游应用服务根据汇总后的监控数据选择目标应用程序。由此,本发明能够根据实际中每个应用服务节点内的内存情况进行服务内存监控,实时展示每个应用服务节点的内存数据,根据服务内存监控情况实现服务调用的负载均衡,合理利用服务资源并且保证服务效果的一致性,实时记录内存监控数据,实现内存数据活跃状态回溯,实现大计算量、大模型、大内存数据服务分布式部署,降低对单个服务器硬件资源要求,并且提高系统并发性能。
[0104] 需要说明的是,本发明实施例中的服务内存信息的负载均衡装置与上述实施例中的服务内存信息的负载均衡方法属于相同的发明构思,未在本装置中详述的技术细节可参见前面对方法的相关描述,在此不再赘述。
[0105] 此外,本发明实施例还提供一种存储介质,所述存储介质中存储有计算机程序,其中,所述计算机程序被设置为运行时执行前面所述的方法。
[0106] 图5示出了可以用来实施本发明的实施例的电子设备10的结构示意图。电子设备旨在表示各种形式的数字计算机,诸如,膝上型计算机、台式计算机、工作台、个人数字助理、服务器、刀片式服务器、大型计算机、和其它适合的计算机。电子设备还可以表示各种形式的移动装置,诸如,个人数字处理、蜂窝电话、智能电话、可穿戴设备(如头盔、眼镜、手表等)和其它类似的计算装置。本文所示的部件、它们的连接和关系、以及它们的功能仅仅作为示例,并且不意在限制本文中描述的和/或者要求的本发明的实现。
[0107] 如图5所示,电子设备10包括至少一个处理器11,以及与至少一个处理器11通信连接的存储器,如只读存储器(ROM)12、随机访问存储器(RAM)13等,其中,存储器存储有可被至少一个处理器执行的计算机程序,处理器11可以根据存储在只读存储器(ROM)12中的计算机程序或者从存储单元18加载到随机访问存储器(RAM)13中的计算机程序,来执行各种适当的动作和处理。在RAM13中,还可存储电子设备10操作所需的各种程序和数据。处理器11、ROM12以及RAM13通过总线14彼此相连。输入/输出(I/O)接口15也连接至总线14。
[0108] 电子设备10中的多个部件连接至I/O接口15,包括:输入单元16,例如键盘、鼠标等;输出单元17,例如各种类型的显示器、扬声器等;存储单元18,例如磁盘、光盘等;以及通信单元19,例如网卡、调制解调器、无线通信收发机等。通信单元19允许电子设备10通过诸如因特网的计算机网络和/或各种电信网络与其他设备交换信息/数据。
[0109] 处理器11可以是各种具有处理和计算能力的通用和/或专用处理组件。处理器11的一些示例包括但不限于中央处理单元(CPU)、图形处理单元(GPU)、各种专用的人工智能(AI)计算芯片、各种运行机器学习模型算法的处理器、数字信号处理器(DSP)、以及任何适当的处理器、控制器、微控制器等。处理器11执行上文所描述的各个方法和处理,例如空闲检测方法。
[0110] 在一些实施例中,空闲检测方法可被实现为计算机程序,其被有形地包含于计算机可读存储介质,例如存储单元18。在一些实施例中,计算机程序的部分或者全部可以经由ROM12和/或通信单元19而被载入和/或安装到电子设备10上。当计算机程序加载到RAM13并由处理器11执行时,可以执行上文描述的空闲检测方法的一个或多个步骤。备选地,在其他实施例中,处理器11可以通过其他任何适当的方式(例如,借助于固件)而被配置为执行空闲检测方法。
[0111] 本文中以上描述的系统和技术的各种实施方式可以在数字电子电路系统、集成电路系统、场可编程门阵列(FPGA)、专用集成电路(ASIC)、专用标准产品(ASSP)、芯片上系统的系统(SOC)、负载可编程逻辑设备(CPLD)、计算机硬件、固件、软件、和/或它们的组合中实现。这些各种实施方式可以包括:实施在一个或者多个计算机程序中,该一个或者多个计算机程序可在包括至少一个可编程处理器的可编程系统上执行和/或解释,该可编程处理器可以是专用或者通用可编程处理器,可以从存储系统、至少一个输入装置、和至少一个输出装置接收数据和指令,并且将数据和指令传输至该存储系统、该至少一个输入装置、和该至少一个输出装置。
[0112] 用于实施本发明的方法的计算机程序可以采用一个或多个编程语言的任何组合来编写。这些计算机程序可以提供给通用计算机、专用计算机或其他可编程数据处理装置的处理器,使得计算机程序当由处理器执行时使流程图和/或框图中所规定的功能/操作被实施。计算机程序可以完全在机器上执行、部分地在机器上执行,作为独立软件包部分地在机器上执行且部分地在远程机器上执行或完全在远程机器或服务器上执行。
[0113] 在本发明的上下文中,计算机可读存储介质可以是有形的介质,其可以包含或存储以供指令执行系统、装置或设备使用或与指令执行系统、装置或设备结合地使用的计算机程序。计算机可读存储介质可以包括但不限于电子的、磁性的、光学的、电磁的、红外的、或半导体系统、装置或设备,或者上述内容的任何合适组合。备选地,计算机可读存储介质可以是机器可读信号介质。机器可读存储介质的更具体示例会包括基于一个或多个线的电气连接、便携式计算机盘、硬盘、随机存取存储器(RAM)、只读存储器(ROM)、可擦除可编程只读存储器(EPROM或快闪存储器)、光纤、便捷式紧凑盘只读存储器(CD‑ROM)、光学储存设备、磁储存设备、或上述内容的任何合适组合。
[0114] 为了提供与用户的交互,可以在电子设备上实施此处描述的系统和技术,该电子设备具有:用于向用户显示信息的显示装置(例如,CRT(阴极射线管)或者LCD(液晶显示器)监视器);以及键盘和指向装置(例如,鼠标或者轨迹球),用户可以通过该键盘和该指向装置来将输入提供给电子设备。其它种类的装置还可以用于提供与用户的交互;例如,提供给用户的反馈可以是任何形式的传感反馈(例如,视觉反馈、听觉反馈、或者触觉反馈);并且可以用任何形式(包括声输入、语音输入或者、触觉输入)来接收来自用户的输入。
[0115] 可以将此处描述的系统和技术实施在包括后台部件的计算系统(例如,作为数据服务器)、或者包括中间件部件的计算系统(例如,应用服务器)、或者包括前端部件的计算系统(例如,具有图形用户界面或者网络浏览器的用户计算机,用户可以通过该图形用户界面或者该网络浏览器来与此处描述的系统和技术的实施方式交互)、或者包括这种后台部件、中间件部件、或者前端部件的任何组合的计算系统中。可以通过任何形式或者介质的数字数据通信(例如,通信网络)来将系统的部件相互连接。通信网络的示例包括:局域网(LAN)、广域网(WAN)、区块链网络和互联网。
[0116] 计算系统可以包括客户端和服务器。客户端和服务器一般远离彼此并且通常通过通信网络进行交互。通过在相应的计算机上运行并且彼此具有客户端‑服务器关系的计算机程序来产生客户端和服务器的关系。服务器可以是云服务器,又称为云计算服务器或云主机,是云计算服务体系中的一项主机产品,以解决了传统物理主机与VPS服务中,存在的管理难度大,业务扩展性弱的缺陷。
[0117] 应该理解,可以使用上面所示的各种形式的流程,重新排序、增加或删除步骤。例如,本发明中记载的各步骤可以并行地执行也可以顺序地执行也可以不同的次序执行,只要能够实现本发明的技术方案所期望的结果,本文在此不进行限制。
[0118] 上述具体实施方式,并不构成对本发明保护范围的限制。本领域技术人员应该明白的是,根据设计要求和其他因素,可以进行各种修改、组合、子组合和替代。任何在本发明的精神和原则之内所作的修改、等同替换和改进等,均应包含在本发明保护范围之内。