一种分布式环境下的服务寻址方法及装置
技术领域
本申请涉及数据寻址技术领域,特别是涉及一种分布式环境下的服务寻址方法和一种分布式环境下的服务寻址装置。
背景技术
随着信息化产业的不断发展,不同种类的操作系统、应用软件、系统软件和应用基础结构(application infrastructure)交融得越来越多,使得SOA(Service-OrientedArchitecture,面向服务的体系架构)技术应运而生并得到广泛应用。
SOA是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。其中,对外提供服务的应用成为服务提供者,使用其他应用提供的服务的应用称为服务消费者。在分布式环境下,服务消费者与服务提供者的数量众多,例如一些以客户为中心的网上购物商城,目前已经拥有上千个服务提供者,服务消费者的数量则更多,在这种情况下,就形成了一个集群环境。
随着系统中服务的不断增加,整个系统中服务的依赖关系逐渐呈现复杂的网状图现象,在这种情况下,对统一的服务寻址场所的需求就非常明显,因此产生了服务注册中心,通常,服务提供者需要将其提供的服务地址信息以及名称、接口、属性等其他元信息统一注册到服务注册中心,然后由服务注册中心将各服务提供者的服务信息以列表或其他形式提供给服务消费者,则服务消费者就可以根据此服务信息列表找到需要的服务提供者,进而请求该服务提供者提供相应的服务。
但是,在集群环境下,服务消费者通过服务注册中心获得的目标服务地址可能有多个,当局部服务器发生故障无法正常提供服务时,落到这些服务器的请求将会执行失败。在高并发的情况下,如果服务消费者不能够及时识别故障服务器,并采取有效隔离手段,将会出现大量的服务调用失败,影响系统可用率。随着集群规模的不断增大,故障出现越大,更加需要针对故障的有效隔离方法。
目前支持故障隔离功能的服务寻址策略主要有:
基于负载的寻址策略:选择负载较低的服务器,但是这种寻址策略需要每次进行服务调用时感知服务提供者一端的负载情况,增加服务提供者对自身负载实时监控的负担,并且需要服务消费者实时获取该负载数据,从而占用大量的计算和网络传输资源。
基于并发的寻址策略:选择并发较小的服务器,但是这种寻址策略需要服务消费者每次进行服务调用时实时统计对各服务提供者的并发调用量,同样需要大量的计算。
基于权重的寻址策略:选择权重较大(或较小,视具体算法而定)的服务器,是一种综合的方式,根据一定的公式,计算权重,也需要针对每次调用进行计算。
综上,以上寻址策略针对每次服务调用均需要进行相应的信息采集和计算,特别是当高并发以及所调用的服务数量和服务提供者地址数量比较多的时候,计算的代价是很高的。在调用成功率比较高的环境下,很多计算其实是没有必要的。
因此,目前需要本领域技术人员迫切解决的一个技术问题就是:提供一种分布式环境下的服务寻址机制,用以提高服务调用的效率。
发明内容
本申请实施例所要解决的技术问题是提供一种分布式环境下的服务寻址方法,用以提高服务调用的效率。
相应的,本申请实施例还提供了一种分布式环境下的服务寻址装置,用以保证上述方法的实现及应用。
为了解决上述问题,本申请公开了一种分布式环境下的服务寻址方法,所述方法包括:
生成服务查询请求,所述服务查询请求包括查询条件;
获取与所述查询条件对应的目标服务的第一服务器地址列表;
获取故障服务器地址列表;
在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表;
从所述第二服务器地址列表中选择目标服务器地址;
向所述目标服务器地址发起对所述目标服务的调用。
优选地,在所述获取故障服务器地址列表的步骤之前,还包括:
预置故障数据库,所述故障数据库中存储一条或多条故障服务器地址与对应的故障次数统计值的关联关系。
优选地,所述获取故障服务器地址列表的步骤包括:
从所述故障数据库中获取与所述第一服务器地址列表匹配的故障服务器地址;
若所述匹配的故障服务器地址有多条,则按照所述故障次数统计值将所述多条故障服务器地址排序;
将排序在前的预设数量的故障服务器地址组织成故障服务器地址列表。
优选地,所述方法还包括:
若对所述目标服务的调用失败,则判定所述目标服务器地址为故障服务器地址;
判断所述故障数据库中是否存在所述故障服务器地址;
若是,则对所述故障服务器地址对应的故障次数统计值增加预设阈值;
若否,则将所述故障服务器地址添加到故障数据库,并设置对应的故障次数统计值为预设的初始值;
更新所述故障服务器地址列表;
针对所述更新后的故障服务器地址列表,返回所述在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表的步骤。
优选地,所述对所述目标服务的调用失败的情形至少包括如下情形的一种:响应超时、目标服务器线程池繁忙。
优选地,所述方法还包括:
对所述故障数据库中的故障服务器地址分别设置定时器;
当所述定时器到时时,将对应的故障服务器地址所对应的故障次数统计值清零。
优选地,所述获取故障服务器地址列表的步骤包括:
生成故障信息获取请求,其中,所述故障信息获取请求用于获取预设时间周期内集群内出现过故障的服务器的信息;
将所述故障信息获取请求发送至远程服务器,其中,所述远程服务器中记录有集群内出现故障的故障服务器的地址信息;
接收远程服务器针对所述故障信息获取请求返回的故障服务器地址列表。
优选地,所述从所述第二服务器地址列表中选择目标服务器地址的步骤为:
从所述第二服务器地址列表中随机选择目标服务器地址。
本申请还提供了一种分布式环境下的服务寻址装置,所述装置包括:
请求生成模块,用于生成服务查询请求,所述服务查询请求包括查询条件;
第一地址获取模块,用于获取与所述查询条件对应的目标服务的第一服务器地址列表;
故障地址获取模块,用于获取故障服务器地址列表;
第二地址获取模块,用于在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表;
地址选择模块,用于从所述第二服务器地址列表中选择目标服务器地址;
服务调用模块,用于向所述目标服务器地址发起对所述目标服务的调用。
优选地,所述装置还包括:
数据库预置模块,用于预置故障数据库,所述故障数据库中存储一条或多条故障服务器地址与对应的故障次数统计值的关联关系。
优选地,所述故障地址获取模块包括:
地址匹配子模块,用于从所述故障数据库中获取与所述第一服务器地址列表匹配的故障服务器地址;
地址排序子模块,用于在所述匹配的故障服务器地址有多条时,按照所述故障次数统计值将所述多条故障服务器地址排序;
列表组织子模块,用于将排序在前的预设数量的故障服务器地址组织成故障服务器地址列表。
优选地,所述装置还包括:
判定模块,用于在对所述目标服务的调用失败时,判定所述目标服务器地址为故障服务器地址;
判断模块,用于判断所述故障数据库中是否存在所述故障服务器地址;
第一计算模块,用于在判定所述故障数据库中存在所述故障服务器地址时,对所述故障服务器地址对应的故障次数统计值增加预设阈值;
第二计算模块,用于在判定所述故障数据库中不存在所述故障服务器地址时,将所述故障服务器地址添加到故障数据库,并设置对应的故障次数统计值为预设的初始值;
列表更新模块,用于更新所述故障服务器地址列表;
触发模块,用于针对所述更新后的故障服务器地址列表,触发所述第二地址获取模块的执行。
优选地,所述对所述目标服务的调用失败的情形至少包括如下情形的一种:响应超时、目标服务器线程池繁忙。
优选地,所述装置还包括:
定时器模块,用于对所述故障数据库中的故障服务器地址分别设置定时器;
清零模块,用于在所述定时器到时时,将对应的故障服务器地址所对应的故障次数统计值清零。
优选地,所述故障地址获取模块包括:
故障请求生成子模块,用于生成故障信息获取请求,其中,所述故障信息获取请求用于获取预设时间周期内集群内出现过故障的服务器的信息;
故障请求发送子模块,用于将所述故障信息获取请求发送至远程服务器,其中,所述远程服务器中记录有集群内出现故障的故障服务器的地址信息;
故障信息接收子模块,用于接收远程服务器针对所述故障信息获取请求返回的故障服务器地址列表。
优选地,所述地址选择模块包括:
随机选择子模块,用于从所述第二服务器地址列表中随机选择目标服务器地址。
与背景技术相比,本申请实施例包括以下优点:
本申请实施例提出一种在大规模高并发的分布式服务调用场景下的基于调用失败量统计的寻址策略,在寻址时,将最近调用失败次数较多的故障服务器地址列表从当前获得的第一服务器地址列表中删除,得到第二服务器地址列表,然后在第二服务器地址列表中再随机选择目标服务器地址进行目标服务的调用,这种只针对调用失败的情形进行统计分析的寻址策略,避免了针对每次服务调用进行的大量的实时计算,实现高效的服务寻址,从而以较小的代价实现有效的集群局部故障隔离。
附图说明
图1是本申请的一种分布式环境下的服务寻址方法实施例一的步骤流程图;
图2是本申请的一种分布式环境下的服务寻址方法实施例二的步骤流程图;
图3是本申请的一种分布式环境下的服务寻址方法实施例三的步骤流程图;
图4是本申请的一种分布式环境下的服务寻址装置实施例的结构框图。
具体实施方式
为使本申请的上述目的、特征和优点能够更加明显易懂,下面结合附图和具体实施方式对本申请作进一步详细的说明。
参照图1,示出了本申请的一种分布式环境下的服务寻址方法实施例一的步骤流程图,具体可以包括如下步骤:
步骤101,生成服务查询请求,所述服务查询请求包括查询条件;
具体而言,本申请实施例可以应用于SOA架构中,当服务提供者在服务注册中心发布服务描述后,服务注册中心对其进行登记,则服务消费者可以查找发布在服务注册中心的服务描述,具体的,服务消费者可以生成包含查询条件的服务查询请求以查找所需的服务,并将服务查询请求发送至服务注册中心。其中,查询条件可以包括服务类型、服务质量保证、安全验证等等。
步骤102,获取与所述查询条件对应的目标服务的第一服务器地址列表;
服务注册中心接收到服务查询请求后,根据查询条件在所发布的服务描述中进行搜索,查找与查询条件匹配的目标服务。
在集群的环境下,提供目标服务的服务器地址可以有多个,因此,服务注册中心可以将提供目标服务的服务器地址以列表的形式(即第一服务器地址列表)呈现给服务消费者。
在具体实现中,第一服务器地址列表可以包括服务器地址标识(即服务的访问路径)、服务调用的参数、传输协议、安全要求等等。
步骤103,获取故障服务器地址列表;
应用于本申请实施例,故障服务器地址具有对应的故障次数统计值,其中,故障次数统计值用于统计对应的故障服务器在预设周期内出现故障的次数。则故障服务器地址列表可以为从第一服务器地址列表中识别出的故障服务器地址后,获取所述故障次数统计值排序在前的预设数量的故障服务器地址组成的列表。
在本申请实施例的一种优选实施例中,在步骤103之前,还可以包括:
预置故障数据库,所述故障数据库中存储一条或多条故障服务器地址与对应的故障次数统计值的关联关系;
应用于本申请实施例,可以在服务消费者的内存中设置故障数据库,该故障数据库用来存储故障服务器以及统计该故障服务器出现故障的次数的统计值。其中,故障服务器为对服务调用失败的服务器(即服务提供者),调用失败的情形可以为如下情形中的至少一种:调用超时、服务端抛异常、服务端线程池繁忙、通信层异常、服务器端拒绝执行等,而当服务器端出现僵死等缓慢型故障时,常见的失败原因有调用超时、服务端线程池繁忙等。需要说明的是,若服务端抛异常是因为服务器依赖的底层存储出了问题,而不是服务器本身的问题,则这种情况下的调用失败不属于服务器故障的范畴。
作为一种示例,故障数据库中存储故障服务器及出现故障的次数的统计值的形式可以为存储故障服务器地址标识和故障次数统计值的对应关系,作为一条数据记录,例如,<192.168.0.1:15>,其中,192.168.0.1是故障服务器地址标识,15为故障次数统计值。
在实际中,当一个故障服务器首次添加到故障数据库中时,其故障次数统计值可以为预设的初始值,该预设的初始值可以为1或其他数值。
在本申请实施例的一种优选实施例中,步骤103可以包括如下子步骤:
子步骤S11,从所述故障数据库中获取与所述第一服务器地址列表匹配的故障服务器地址;
当获取第一服务器地址列表后,可以从故障数据库中获取与第一服务器地址列表相匹配的故障服务器地址,具体的,可以将故障数据库中的每条数据记录遍历第一服务器地址列表,若能在第一服务器地址列表找到该条数据记录,则表示该条数据记录能与第一服务器地址列表中的数据匹配上,如是重复,直到查找到全部的与第一服务器地址列表匹配的故障服务器地址。该查找到的故障服务器地址的数量可以是0条、1条或多条。
子步骤S12,若所述匹配的故障服务器地址有多条,则按照所述故障次数统计值将所述多条故障服务器地址排序;
当匹配的故障服务器地址有多条,可以按照每条故障服务器地址对应的故障次数统计值将多条故障服务器地址排序,可以按照故障次数统计值进行升序排序或降序排序。例如,若按照降序排序,可以是:[<192.168.0.1:15>,<192.168.0.3:13>,…,<192.168.0.18:3>,…,<192.168.0.111:1>]。
子步骤S13,将排序在前的预设数量的故障服务器地址组织成故障服务器地址列表。
若按照降序排序,则可以获得队首中排序在前的预设数量的故障服务器地址组织成故障服务器地址列表(可以标记为unstableUrls);对应的,若按照升序排序,则可以获得队尾中排序在前的预设数量的故障服务器地址组织成故障服务器地址列表。其中,为了避免某些异常情况下隔离掉过多的故障服务器,导致剩余的服务器被冲垮,预设数量的主要作用是表示最多可以隔离掉几台故障服务器,可以为根据需要设定的阈值,在实际中,由于服务的设计和实现都会保证一定的可用率目标,在大型的商用SOA中,对可用率的要求一般在99.99%以上,所以,在这样的体系中,绝大部分的服务调用都是能够成功完成的,出现故障的服务器一般是比较少的,通常单机故障比较多,所以预设数量可以取1或2等比较少的数量,例如,针对上例,如果预设数量为2,则unstableUrls就是[192.168.0.1,192.168.0.3];如果预设数量为1,则unstableUrls就是[192.168.0.1]。
步骤104,在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表;
当获取故障服务器地址列表后,可以在第一服务器地址列表中过滤该故障服务器地址列表,即从第一服务器地址列表中删除故障服务器地址列表,将剩下的服务器地址列表作为第二服务器地址列表,以此来隔离故障服务器。
步骤105,从所述第二服务器地址列表中选择目标服务器地址;
在本申请实施例的一种优选实施例中,由于第二服务器地址列表中已经将能识别出的故障服务器地址隔离,并且,提供服务的服务器一般也都是统一规格的,也就是说集群中,每台服务器的服务能力是基本相等的,因此,可以使用在所述第二服务器地址列表中随机选择目标服务器地址的随机寻址策略,而无需进行刻意的计算和选择,简化了寻址流程,同时,由于计算的数据少了,降低了服务器(服务提供者以及服务消费者)的数据处理压力,提升了寻址效率。
步骤106,向所述目标服务器地址发起对所述目标服务的调用。
当选择了目标服务器以后,则可以向该目标服务器地址发起对目标服务的调用。此时,若目标服务器对服务的调用失败,则判定该目标服务器地址为故障服务器地址,然后进一步判断故障数据库中是否存在该故障服务器地址,若存在,则对该故障服务器地址对应的故障次数统计值增加预设阈值;若不存在,则将该故障服务器地址添加到故障数据库,并设置对应的故障次数统计值为预设的初始值。其中,预设阈值可以为预设的增加幅度(如,增加预设倍数,或增加1等等),例如,原来故障数据库中的服务调用失败数据是[<192.168.0.1:9>,<192.168.0.3:6>],本次调用192.168.0.3失败,汇总后,服务调用失败数据就变为了[<192.168.0.1:9>,<192.168.0.3:7>]。
由于故障数据库中的故障次数统计值发生了改变,这可能会影响到故障数据库中的故障服务器的排序,因此需要按照排序的结果更新故障服务器地址列表,并针对更新后的故障服务器地址列表,返回步骤104继续以重试的方式选择目标服务器,以及对目标服务器进行目标服务的调用,重复进行上述故障服务器地址列表的更新以及重新选择目标服务器的过程,直到目标服务调用成功。本申请实施例采用允许服务消费者重试的方式进行目标服务器的选择,这样可以提高服务调用的成功率。
另外,在本申请实施例中,针对故障数据库中的每条数据记录,即每条故障服务器地址,都可以设置定时器,当定时器到时时,将对应的故障服务器地址所对应的故障次数统计值清零,以这种周期性清空故障服务器地址的故障次数统计值的方式使得当故障服务器的服务能力恢复后,该服务器地址被正常调用。
本申请实施例提出一种在大规模高并发的分布式服务调用场景下的基于调用失败量统计的寻址策略,在寻址时,将最近调用失败次数较多的故障服务器地址列表从当前获得的第一服务器地址列表中删除,得到第二服务器地址列表,然后在第二服务器地址列表中再随机选择目标服务器地址进行目标服务的调用,这种只针对调用失败的情形进行统计分析的寻址策略,避免了针对每次服务调用进行的大量的实时计算,实现高效的服务寻址,从而以较小的代价实现有效的集群局部故障隔离。
参照图2,示出了本申请的一种分布式环境下的服务寻址方法实施例二的步骤流程图,具体可以包括如下步骤:
步骤201,服务消费者预置故障数据库;
其中,故障数据库中存储一条或多条故障服务器地址与对应的故障次数统计值的关联关系。
在该故障数据库中,针对每条故障服务器地址设置有定时器,用于周期性地清空故障服务器中的故障次数统计值,以使得当故障服务器恢复正常时可以被正常调用。
步骤202,服务消费者生成服务查询请求,并将所述查询请求发送至服务注册中心,所述服务查询请求包括查询条件;
其中,查询条件可以为服务类型、服务质量保证、安全验证等等。
步骤203,服务消费者从服务注册中心中获得与所述查询条件对应的目标服务的第一服务器地址列表;
步骤204,服务消费者从所述故障数据库中获取与所述第一服务器地址列表匹配的故障服务器地址;
步骤205,若所述匹配的故障服务器地址有多条,则按照所述故障次数统计值将所述多条故障服务器地址排序;
步骤206,服务消费者将排序在前的预设数量的故障服务器地址组织成故障服务器地址列表;
步骤207,服务消费者在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表;
步骤208,服务消费者从所述第二服务器地址列表中随机选择目标服务器地址,并向所述目标服务器地址发起对所述目标服务的调用;
步骤209,服务消费者判断所述目标服务的调用是否成功,若是,则流程结束;若否,则执行步骤210;
步骤210,服务消费者判断所述故障数据库中是否存在所述故障服务器地址,若是,则执行步骤211,若否,则执行步骤212;
步骤211,对所述故障服务器地址对应的故障次数统计值增加预设阈值,返回继续执行步骤204;
步骤212,将所述故障服务器地址添加到故障数据库,并设置对应的故障次数统计值为预设的初始值,返回继续执行步骤204。
对于图2所述的方法实施例而言,由于其与图1的方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
参照图3,示出了本申请的一种分布式环境下的服务寻址方法实施例三的步骤流程图,具体可以包括如下步骤:
步骤301,生成服务查询请求,所述服务查询请求包括查询条件;
服务消费者可以生成包含查询条件的服务查询请求以查找所需的服务,并将服务查询请求发送至服务注册中心。其中,查询条件可以包括服务类型、服务质量保证、安全验证等等。
步骤302,获取与所述查询条件对应的目标服务的第一服务器地址列表;
服务消费者从服务注册中心处获取与所述查询条件对应的目标服务的第一服务器地址列表。具体的,服务注册中心接收到服务查询请求后,根据查询条件在所发布的服务描述中进行搜索,查找与查询条件匹配的目标服务。
在集群的环境下,提供目标服务的服务器地址可以有多个,因此,服务注册中心可以将提供目标服务的服务器地址以列表的形式(即第一服务器地址列表)呈现给服务消费者。
在具体实现中,第一服务器地址列表可以包括服务器地址标识(即服务的访问路径)、服务调用的参数、传输协议、安全要求等等。
步骤303,生成故障信息获取请求,其中,所述故障信息获取请求用于获取预设时间周期内集群内出现过故障的服务器的信息;
应用于本申请实施例,服务消费者还可以生成故障信息获取请求,该故障信息获取请求用于获取预设时间周期内集群内出现过故障的服务器的信息,例如服务器地址信息、标识信息、路径信息等。该故障信息获取请求包括目标服务标识。
其中,预设时间周期可以为按需设定的时间周期,例如一天、一个星期等。
需要说明的是,步骤301与步骤303可以同时进行,也可以异步进行,例如先执行步骤301获得第一服务器地址列表后再执行步骤303。本申请实施例对步骤301与步骤303的执行顺序无需加以限制。
步骤304,将所述故障信息获取请求发送至远程服务器,其中,所述远程服务器中记录有集群内出现故障的故障服务器的地址信息;
步骤305,接收远程服务器针对所述故障信息获取请求返回的故障服务器地址列表;
服务消费者生成故障信息获取请求后,可以将该故障信息获取请求发送至远程服务器,该远程服务器中记录有集群内出现故障的故障服务器的地址信息。具体而言,当服务消费者向服务提供者调用服务失败时,服务消费者都可以将服务提供者地址(即故障服务器地址)、调用的服务标识、调用时间、失败原因(调用超时、服务端抛异常、服务端线程池繁忙、通信层异常、服务器端拒绝执行等)等调用失败信息发送至远程服务器,则远程服务器记录该调用失败信息,并统计该调用失败的故障服务器出现故障的故障次数统计值,以及,生成故障服务器地址与对应的故障次数统计值的关联关系,例如,<192.168.0.1:15>。在实际中,远程服务器中可以设置容器来计算每个故障服务器的故障次数统计值。当然,调用失败信息除了是服务消费者提供给远程服务器的以外,还可以是服务提供者主动向远程服务器提供的,本申请实施例对此无需加以限制。
在具体实现中,当远程服务器接收到调用失败信息后,首先查找本地是否记录有该调用失败信息对应的故障服务器地址,若没有,则记录该调用失败信息,并设置故障次数统计值为预设的初始值,该预设的初始值可以为1或其他数值。若本地记录有调用失败信息对应的故障服务器地址,则对对应的故障次数统计值增加预设阈值,例如加1。
在远程服务器中,若故障服务器地址有多条,则可以按照故障次数统计值将多条故障服务器地址排序,可以按照故障次数统计值进行升序排序或降序排序。例如,若按照降序排序,可以是:[<192.168.0.1:15>,<192.168.0.3:13>,…,<192.168.0.18:3>,…,<192.168.0.111:1>]。
当远程服务器接收到故障信息获取请求后,可以将排序在前的预设数量的故障服务器地址组织成故障服务器地址列表,并将该故障服务器地址列表返回服务消费者。
另外,在远程服务器中,针对每条故障服务器地址,都可以设置定时器,当定时器到时时,将对应的故障服务器地址所对应的故障次数统计值清零,以这种周期性清空故障服务器地址的故障次数统计值的方式使得当故障服务器的服务能力恢复后,该服务器地址被正常调用。
步骤306,在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表;
具体而言,服务消费者接收到故障服务器地址列表后,将故障服务器地址列表中的每条故障服务器地址与第一服务器地址列表进行匹配,若能在第一服务器地址列表找到该故障服务器地址,则从第一服务器地址列表中删除所述故障服务器地址,如此重复,直到故障服务器地址列表中的所有故障服务器地址都匹配完成,则删除了故障服务器地址后的第一服务器地址列表为第二服务器地址列表。
步骤307,从所述第二服务器地址列表中选择目标服务器地址;
步骤308,向所述目标服务器地址发起对所述目标服务的调用。
本申请实施例与图1或图3的实施例相比,其区别在于,图1及图2的实施例是将故障服务器地址维护在服务消费者本地,即从服务消费者本地来获得故障服务器地址列表,而本实施例是将故障服务器地址维护在远程服务器中,即从远程服务器中获得故障服务器地址列表。将故障服务器地址维护在远程服务器中的好处是可以减轻服务消费者的本地存储压力,提高服务消费者的数据处理效率,进一步提升服务消费者的性能;另一方面,还可以将识别的故障服务器共享给所有的服务消费者,免去在每个服务消费者中都维护故障服务器地址的麻烦,从而提高了服务消费者获取故障服务器地址列表的效率。
对于图3所述的方法实施例而言,由于其与图1及图2的方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
需要说明的是,对于方法实施例,为了简单描述,故将其都表述为一系列的动作组合,但是本领域技术人员应该知悉,本申请实施例并不受所描述的动作顺序的限制,因为依据本申请实施例,某些步骤可以采用其他顺序或者同时进行。其次,本领域技术人员也应该知悉,说明书中所描述的实施例均属于优选实施例,所涉及的动作并不一定是本申请实施例所必须的。
参照图4,示出了本申请一种分布式环境下的服务寻址装置实施例的结构框图,具体可以包括如下模块:
请求生成模块401,用于生成服务查询请求,所述服务查询请求包括查询条件;
第一地址获取模块402,用于获取与所述查询条件对应的目标服务的第一服务器地址列表;
故障地址获取模块403,用于获取故障服务器地址列表;
其中,所述故障服务器地址具有对应的故障次数统计值,所述故障服务器地址列表为从所述第一服务器地址列表中识别出的故障服务器地址后,获取所述故障次数统计值排序在前的预设数量的故障服务器地址组成的列表;
第二地址获取模块404,用于在所述第一服务器地址列表中删除所述故障服务器地址列表,得到第二服务器地址列表;
地址选择模块405,用于从所述第二服务器地址列表中选择目标服务器地址;
服务调用模块406,用于向所述目标服务器地址发起对所述目标服务的调用。
在本申请实施例的一种优选实施例中,本申请实施例的装置还可以包括:
数据库预置模块,用于预置故障数据库,所述故障数据库中存储一条或多条故障服务器地址与对应的故障次数统计值的关联关系。
在本申请实施例的一种优选实施例中,所述故障地址获取模块403可以包括如下子模块:
地址匹配子模块,用于从所述故障数据库中获取与所述第一服务器地址列表匹配的故障服务器地址;
地址排序子模块,用于在所述匹配的故障服务器地址有多条时,按照所述故障次数统计值将所述多条故障服务器地址排序;
列表组织子模块,用于将排序在前的预设数量的故障服务器地址组织成故障服务器地址列表。
在本申请实施例的一种优选实施例中,所述装置还包括:
判定模块,用于在对所述目标服务的调用失败时,判定所述目标服务器地址为故障服务器地址;
判断模块,用于判断所述故障数据库中是否存在所述故障服务器地址;
第一计算模块,用于在判定所述故障数据库中存在所述故障服务器地址时,对所述故障服务器地址对应的故障次数统计值增加预设阈值;
第二计算模块,用于在判定所述故障数据库中不存在所述故障服务器地址时,将所述故障服务器地址添加到故障数据库,并设置对应的故障次数统计值为预设的初始值;
列表更新模块,用于更新所述故障服务器地址列表;
触发模块,用于针对所述更新后的故障服务器地址列表,触发所述第二地址获取模块的执行。
作用于本申请实施例的一种优选示例,所述对所述目标服务的调用失败的情形至少可以包括如下情形的一种:响应超时、目标服务器线程池繁忙。
在本申请实施例的一种优选实施例中,所述装置还可以包括:
定时器模块,用于对所述故障数据库中的故障服务器地址分别设置定时器;
清零模块,用于在所述定时器到时时,将对应的故障服务器地址所对应的故障次数统计值清零。
在本申请实施例的另一种优选实施例中,所述故障地址获取模块403可以包括如下子模块:
故障请求生成子模块,用于生成故障信息获取请求,其中,所述故障信息获取请求用于获取预设时间周期内集群内出现过故障的服务器的信息;
故障请求发送子模块,用于将所述故障信息获取请求发送至远程服务器,其中,所述远程服务器中记录有集群内出现故障的故障服务器的地址信息;
故障信息接收子模块,用于接收远程服务器针对所述故障信息获取请求返回的故障服务器地址列表。
在本申请实施例的一种优选实施例中,所述地址选择模块405包括:
随机选择子模块,用于从所述第二服务器地址列表中随机选择目标服务器地址。
对于图4所述的装置实施例而言,由于其与上述的方法实施例基本相似,所以描述的比较简单,相关之处参见方法实施例的部分说明即可。
本说明书中的各个实施例均采用递进的方式描述,每个实施例重点说明的都是与其他实施例的不同之处,各个实施例之间相同相似的部分互相参见即可。
本领域内的技术人员应明白,本申请实施例的实施例可提供为方法、装置、或计算机程序产品。因此,本申请实施例可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且,本申请实施例可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。
在一个典型的配置中,所述计算机设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。内存可能包括计算机可读介质中的非永久性存储器,随机存取存储器(RAM)和/或非易失性内存等形式,如只读存储器(ROM)或闪存(flash RAM)。内存是计算机可读介质的示例。计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括,但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带,磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质,可用于存储可以被计算设备访问的信息。按照本文中的界定,计算机可读介质不包括非持续性的电脑可读媒体(transitory media),如调制的数据信号和载波。
本申请实施例是参照根据本申请实施例的方法、终端设备(系统)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理终端设备的处理器以产生一个机器,使得通过计算机或其他可编程数据处理终端设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。
这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理终端设备以特定方式工作的计算机可读存储器中,使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品,该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。
这些计算机程序指令也可装载到计算机或其他可编程数据处理终端设备上,使得在计算机或其他可编程终端设备上执行一系列操作步骤以产生计算机实现的处理,从而在计算机或其他可编程终端设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。
尽管已描述了本申请实施例的优选实施例,但本领域内的技术人员一旦得知了基本创造性概念,则可对这些实施例做出另外的变更和修改。所以,所附权利要求意欲解释为包括优选实施例以及落入本申请实施例范围的所有变更和修改。
最后,还需要说明的是,在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者终端设备不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者终端设备所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括所述要素的过程、方法、物品或者终端设备中还存在另外的相同要素。
以上对本申请所提供的一种分布式环境下的服务寻址方法和分布式环境下的服务寻址装置,进行了详细介绍,本文中应用了具体个例对本申请的原理及实施方式进行了阐述,以上实施例的说明只是用于帮助理解本申请的方法及其核心思想;同时,对于本领域的一般技术人员,依据本申请的思想,在具体实施方式及应用范围上均会有改变之处,综上所述,本说明书内容不应理解为对本申请的限制。