发明内容
本发明的主要目的在于提供一种分布式***及其管理方法和管理装置,其从应用维度出发对分布式***的健康状态进行判断,能够有效避免由于某个应用异常造成整个分布式***不可服务的情况的发生。
根据本发明的一个方面,提供了一种分布式***,包括管理节点和用于运行任务的多个业务节点,多个业务节点分属于至少两个应用组,每个应用组包括至少一个业务节点以用于特定应用,其中,多个业务节点周期性地向管理节点发送其自身的状态信息;管理节点根据多个业务节点的状态信息,判定各个业务节点是否可用;管理节点根据各个业务节点所属的应用组确定各个应用组分别包含的可用业务节点数量,以判定各个应用组是否可用;以及管理节点根据可用应用组的数量判定分布式***是否可用。
由此本发明从应用维度出发,以可用应用组的数量为基准来判断分布式***是否可用。与单纯以可用的业务节点的数量为基准来判断分布式***是否可用相比,可以避免由于某个或某些应用组异常导致整个分布式***被判定为不可用,使得其它正常应用组也不可服务的情况的发生。
优选地,管理节点根据多个业务节点的状态信息判定各个业务节点是否可用,包括:在业务节点的状态信息指示该业务节点繁忙时判定该业务节点不可用;以及在没有接收到业务节点的状态信息时判定该业务节点不可用。由此可以根据业务节点的存活状态或健康状态这两个方面来判断该业务节点是否可用。
优选地,管理节点可以根据如下至少之一确定各个业务节点所属的应用组:管理节点保存的各个业务节点所属应用列表;各个业务节点在***初始化时上报的所属应用信息;以及业务节点周期性发送的状态信息中包含的所属应用信息。由此可以通过多种方式来灵活确定业务节点所属的应用组。
优选地,管理节点可以在应用组包含的业务节点都不可用的情况下才判定该应用组不可用,以尽可能地维持应用/***的可服务性。
优选地,管理节点根据可用应用组的数量判定分布式***是否可用可以包括:管理节点在可用应用组的数量与应用组总数量之比达到预定阈值时判定分布式***可用。
优选地,管理节点包括任务分发子节点和信息汇总子节点,并且其中,信息汇总子节点周期性地汇总多个业务节点的状态信息并将汇总的状态信息上报给任务分发子节点;任务分发子节点根据汇总的状态信息判定分布式***是否可用,并且在判定分布式***可用时向可用的业务节点分发任务。由此,在判定分布式***可用时,可以由任务分发子节点继续向可用的业务节点分发任务,使得可用的业务节点能够正常提供服务。
根据本发明的另一个方面,还提供了一种分布式***的管理装置,分布式***包括用于运行任务的多个业务节点,多个业务节点分属于至少两个应用组,每个应用组包括至少一个业务节点以用于特定应用,管理装置包括:信息获取单元,用于周期性地获取多个业务节点的状态信息;可用节点判断单元,用于根据多个业务节点的状态信息,判定各个业务节点是否可用;可用应用组判断单元,用于根据各个业务节点所属的应用组确定各个应用组分别包含的可用业务节点数量,以判定各个应用组是否可用;以及***可用判断单元,用于根据可用应用组的数量判定分布式***是否可用。
优选地,可用节点判断单元还可以用于:在业务节点的状态信息指示该业务节点繁忙时判定该业务节点不可用;以及在没有接收到业务节点的状态信息时判定该业务节点不可用。
优选地,***可用判断单元应用在可用应用组的数量与应用组总数量之比达到预定阈值时判定分布式***可用。
优选地,该管理装置还可以包括任务分发子单元,用于在***可用判断单元判定分布式***可用时向可用的业务节点分发任务。
根据本发明的又一个方面,还提供了一种分布式***的管理方法,分布式***包括用于运行任务的多个业务节点,多个业务节点分属于至少两个应用组,每个应用组包括至少一个业务节点以用于特定应用,管理方法包括:周期性地获取多个业务节点的状态信息;根据多个业务节点的状态信息,判定各个业务节点是否可用;根据各个业务节点所属的应用组确定各个应用组分别包含的可用业务节点数量,以判定各个应用组是否可用;以及根据可用应用组的数量判定分布式***是否可用。
优选地,该管理方法可以根据如下至少之一确定各个业务节点所属的应用组:管理节点保存的各个业务节点所属应用列表;各个业务节点在***初始化时上报的所属应用信息;以及业务节点周期性发送的状态信息中包含的所属应用信息。
优选地,该管理方法还可以包括:在判定分布式***可用时向可用的业务节点分发任务。
本发明的分布式***及其管理方法和管理装置从应用维度出发,以可用应用组的数量为基准来判断分布式***是否可用。与单纯以可用的业务节点的数量为基准来判断分布式***是否可用相比,可以避免由于某个应用组异常导致整个分布式***被判定为不可用,使得其它正常应用组也不可服务的情况的发生。
具体实施方式
下面将参照附图更详细地描述本公开的优选实施方式。虽然附图中显示了本公开的优选实施方式,然而应该理解,可以以各种形式实现本公开而不应被这里阐述的实施方式所限制。相反,提供这些实施方式是为了使本公开更加透彻和完整,并且能够将本公开的范围完整地传达给本领域的技术人员。
下面将参照图1至图3来具体地描述本发明的实施例。图1是示出了根据本发明一实施例的分布式***100的功能框图。如图1所示,分布式***100包括管理节点110和多个业务节点120。在这里,“节点”可以指的是分布式***中运行“进程”的载体。
管理节点110和业务节点120均可以部署在分布式***100下的集群服务器中。其中,在同一服务器上可以部署一个业务节点120,也可以部署两个或更多个业务节点120。管理节点110可以部署在不同于业务节点120的一个独立的服务器中,也可以和其中一个或多个业务节点120部署在同一个服务器中。附图中的连线表示管理节点110和业务节点120之间存在信息交互,上述连线可以是有线连接、无线连接,或是能够进行信息传送的任何形式的连接。
业务节点120能够利用其所在的服务器提供的资源运行任务,多个业务节点120所运行的任务可以分属于多个不同的应用组(如图中虚线框所示),每个应用组中的业务节点可以用于特定应用。这里,“应用组”可以指示用于同一应用的一组业务节点。例如,分布式***100可以是针对搜索业务的分布式搜索***,针对不同的搜索对象,可以设置不同的搜索应用组,如可以设置图片搜索应用组、视频搜索应用组、小说搜索应用组等,***中的业务节点虽然都可用于执行搜索任务,但不同搜索应用组中的业务节点可以执行对应类别的搜索任务。另外,虽然图中示出了各自涉及两个业务节点的N个应用,但应该理解本发明的分布式***可以用于任意多个应用,每个应用可以各自涉及一个或多个业务节点,并且用于不同应用的业务节点数量可以相同也可以不同。
业务节点120可以周期性地向管理节点110发送其自身的状态信息。上述信息可以证明业务节点120的存活,即,正常连接在分布式***中,因此可被称为“心跳信息”。发送的信息中还可以包含用于指示业务节点120当前使用状况的信息,这些信息可被称为“健康状态”信息,可以用来表征具体节点的健康状况。在一个实施例中,健康状态信息可以是包括当前资源占用信息和当前任务队列信息。
管理节点110可以根据多个业务节点120的状态信息,判定各个业务节点是否可用。如上文所述,业务节点120发送的状态信息可以证明其存活,也可以指示其当前的健康状况。因此,管理节点110可以根据业务节点120的存活状态或健康状况来判定业务节点120是否可用。
具体地,管理节点110可以在业务节点120的状态信息指示其繁忙时判定该业务节点120不可用。例如,在业务节点120发送的状态信息指示当前资源占用率过高和/或当前任务队列过长时,可以判定其不可用。另外,管理节点110还可以在没有接收到业务节点120发送的信息时,判定其不可用。这里,管理节点110可以在单个周期内没有接收到来自业务节点120的信息时,判定该业务节点120不可用,也可以在持续一段时间(例如多周期)内没有接收到来自业务节点120的信息时,才判定该业务节点120不可用。
在确定了各个业务节点120是否可用后,管理节点110就可以根据各个业务节点所属的应用组确定各个应用组分别包含的可用业务节点数量,以判定各个应用组是否可用。这里,管理节点110可以在应用组包含的业务节点都不可用时判定该应用组不可用,也可以在应用组中的不可用业务节点数量占该组中的全部业务节点数量的比值超过一定阈值时,判定该应用组不可用。
另外,管理节点110可以通过多种方式灵活确定业务节点所属的应用组。例如,管理节点110可以保存各个业务节点所属应用列表,根据该列表可以确定业务节点所属的应用组。再例如,各个业务节点120在分布式***100初始化时,可以上报各自所属的应用信息,这里业务节点12可以在初始化时上报一次,今后不上报,也可以初始化时上报一次,今后次次都上报。还例如,业务节点120在周期性发送的状态信息中也可以包含所属应用信息,例如,业务节点120发送的状态信息可以包括该业务节点所在ip地址、服务端口和所属的应用名字等内容。当然,还可以通过其它方式来确定业务节点所属的应用组,这里不再赘述。
在确定应用组是否可用后,管理节点110就可以根据可用应用组的数量判断分布式***100是否可用。例如,管理节点110可以在可用应用组的数量与应用组总数量之比达到预定阈值时判定分布式***100可用。在判定分布式***100可用的情况下,管理节点110就可以继续向可用的业务节点分发新的任务。
如图1所示,管理节点110可以包括任务分发子节点111和信息汇总子节点112。信息汇总子节点112可以周期性地汇总多个业务节点的状态信息并将汇总的状态信息上报给任务分发子节点111,例如汇总的状态信息可以包括总的应用组的个数,每个应用组中可用的业务节点的数量、不可用的业务节点的数量、可用的业务节点的地址、服务端口等等。任务分发子节点111可以根据汇总的状态信息判定分布式***100是否可用,并且在判定分布式***100可用时向可用的业务节点分发任务。其中,分布式***100是否可用的具体判定方式已在上文做过详细说明,这里不再赘述。
需要说明的是,任务分发子节点111可以根据信息汇总子节点112周期性发送的汇总状态信息,定期更新任务分发子节点111的健康状态,这里判断任务分发子节点111的健康状态的方式可以与分布式***100是否可用的判定方式相同。在确定任务分发子节点111健康状态异常时,可以停止任务分发子节点111继续下发新的任务。
至此结合图1详细说明了本发明的分布式***。由上可知,本发明的分布式***从应用维度出发,以可用应用组的数量为基准来判断分布式***是否可用,与单纯以可用的业务节点的数量为基准来判断分布式***是否可用相比,可以避免由于某个应用组异常导致整个分布式***被判定为不可用,使得其它正常应用组也不可服务的情况的发生。
图2是示出了根据本发明一实施例的分布式***的管理装置的结构示意图。图3是示出了根据本发明一实施例的分布式***的管理方法的流程图。图2和图3所涉及的分布式***可以包括多个业务节点。业务节点可以部署在分布式***下的集群服务器中,其中可以在同一服务器上部署一个业务节点,也可以部署两个或更多个业务节点。
业务节点能够利用其所在的服务器提供的资源运行任务,多个业务节点所运行的任务可以分属于多个不同的应用组,每个应用组中的业务节点可以用于特定应用。例如,分布式***可以是针对搜索业务的分布式搜索***,针对不同的搜索对象,可以设置不同的搜索应用组,如可以设置图片搜索应用组、视频搜索应用组、小说搜索应用组等,不同搜索应用组中的业务节点可以执行对应类别的搜索任务。
如图2所示,管理装置200包括信息获取单元210、可用节点判断单元220、可用应用组判断单元230以及***可用判断单元240。在一个实施例中,可用节点判断单元220、可用应用组判断单元230以及***可用判断单元240可以是属于同一判断单元的三个子单元。
如图3所示,在步骤S310,例如可以由信息获取单元210,周期性地获取多个业务节点的状态信息。
业务节点可以周期性地向管理装置200发送其自身的状态信息,信息获取单元210在接收到业务节点发送的信息时,可以证明该业务节点存活,业务节点正常连接在分布式***中。信息获取单元210在没有接收到业务节点发送的信息时,表明该业务节点的通信异常,存活状态未知。另外,业务节点发送的信息中还可以包含用于指示业务节点当前使用状况的信息,这些信息可被称为“健康状态”信息,用来表征具体节点的健康状况。在一个实施例中,健康状态信息可以是或者可以包括当前资源占用信息和当前任务队列信息。
在步骤S320,例如可以由可用节点判断单元220,根据多个业务节点的状态信息,判定各个业务节点是否可用。
此处,节点判断单元220可以在业务节点的状态信息指示该业务节点繁忙时判定该业务节点不可用,也可以在没有接收到业务节点的状态信息时判定该业务节点不可用。
在步骤S330,例如可以由可用应用组判断单元230,根据各个业务节点所属的应用组确定各个应用组分别包含的可用业务节点数量,以判定各个应用组是否可用。
可用应用组判断单元230可以在应用组包含的业务节点都不可用时判定该应用组不可用,也可以在应用组中的不可用节点数量占该组中的全部节点数量的比值超过一定阈值时,判定该应用组不可用。
另外,可以通过多种方式了灵活确定业务节点所属的应用组。例如,可以通过管理节点保存的各个业务节点所属应用列表确定业务节点所属的应用组。再例如,还可以根据各个业务节点在分布式***初始化时上报的各自所属的应用信息来确定。还例如,还可以根据业务节点周期性发送的状态信息中中包含的所属应用信息来确定。当然,还可以通过其它方式来确定业务节点所属的应用组,这里不再赘述。
在步骤S340,例如可以由***可用判断单元240,根据可用应用组的数量判定分布式***是否可用。其中,***可用判断单元240可以可用应用组的数量与应用组总数量之比达到预定阈值时判定分布式***可用。
回到图2,管理装置200还可以包括任务分发子单元250。在***可用判断单元240判定分布式***可用时,任务分发子单元250可以向可用的业务节点分发任务。
综上,本发明以应用组代替业务节点作为健康检查的粒度,依托每个业务节点的心跳汇报,当某个应用组中的所有业务节点失去心跳时,则认为该应用组不可用,当不可用的应用组超过阈值时,则认为分布式***不可用,可以停止下发新的任务。
上文中已经参考附图详细描述了根据本发明的分布式***及其管理方法和管理装置。如下将结合图4A-C描述根据本发明的一个应用例。
应用例
图4示出了一种具有健康检查功能的多应用***(例如,双层检索***),其上层实现请求分发功能,底层实现检索功能,底层进程往往功能相同或者相关。具体***涉及三种节点/进程:同在上层的admin和dispatcher、以及位于下层的多个worker。其中,admin负责接收worker心跳,汇总应用状态;dispatcher为上层的分发进程,admin和dispatcher优选包括在一个管理装置内,或是由一个管理节点实现;worker为底层各个应用的进程。图4所示的***是具有多个相关应用的多应用***,其中,每个应用的功能由至少一个worker实现。图4A示出了***正常工作时的状态。
在***运行过程中,分属于不同应用的worker都定期向admin汇报心跳信息。心跳信息可以包括进程所在ip地址、进程服务端口和进程所属的应用名字等内容。
admin接收来自worker的心跳信息。在一轮决策的过程中,根据worker汇报的心跳信息,判断每个worker的状态,如死活、是否可用等。并对worker按应用进行分类,当一个应用的所有worker都死亡或者不可服务时,则认为该应用不可服务。admin会定期向dispatcher发送应用的状态信息,包括总的应用个数、每个应用所有可服务worker的地址、服务端口等。
dispatcher接收来自admin的应用更新命令。dispatcher会比较本次命令和与上次命令的异同。如果有区别,则根据本次命令,重新建立与底层可服务worker的连接。dispatcher会定期更新自己的健康状态,dispatcher的健康状态由可服务的应用个数和总的应用个数的比值决定。当每个应用都有部分worker时,dispatcher向正常的worker发送请求,***正常服务,如图4B所示。当可服务的应用与总应用个数比值小于阈值时,则认为dispatcher不可服务,如图4C所示。
本发明通过以应用代替进程作为健康检查的粒度,依托每个进程的心跳汇报,当某个应用的所有进程失去心跳,则认为该应用不可服务。当失去服务能力的应用超过阈值时,则认为上层分发进程服务不可用。由此,能够有效避免由于某个/某些应用异常造成整个***不可服务的情况,保证其他应用的服务不受影响。
此外,根据本发明的方法还可以实现为一种计算机程序,该计算机程序包括用于执行本发明的上述方法中限定的上述各步骤的计算机程序代码指令。或者,根据本发明的方法还可以实现为一种计算机程序产品,该计算机程序产品包括计算机可读介质,在该计算机可读介质上存储有用于执行本发明的上述方法中限定的上述功能的计算机程序。本领域技术人员还将明白的是,结合这里的公开所描述的各种示例性逻辑块、模块、电路和算法步骤可以被实现为电子硬件、计算机软件或两者的组合。
附图中的流程图和框图显示了根据本发明的多个实施例的***和方法的可能实现的体系架构、功能和操作。在这点上,流程图或框图中的每个方框可以代表一个模块、程序段或代码的一部分,所述模块、程序段或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意,在有些作为替换的实现中,方框中所标记的功能也可以以不同于附图中所标记的顺序发生。例如,两个连续的方框实际上可以基本并行地执行,它们有时也可以按相反的顺序执行,这依所涉及的功能而定。也要注意的是,框图和/或流程图中的每个方框、以及框图和/或流程图中的方框的组合,可以用执行规定的功能或操作的专用的基于硬件的***来实现,或者可以用专用硬件与计算机指令的组合来实现。
以上已经描述了本发明的各实施例,上述说明是示例性的,并非穷尽性的,并且也不限于所披露的各实施例。在不偏离所说明的各实施例的范围和精神的情况下,对于本技术领域的普通技术人员来说许多修改和变更都是显而易见的。本文中所用术语的选择,旨在最好地解释各实施例的原理、实际应用或对市场中的技术的改进,或者使本技术领域的其它普通技术人员能理解本文披露的各实施例。