CN113064732A - 一种分布式***及其管理方法 - Google Patents

Abstract

本发明实施例公开了一种分布式***及其管理方法，包括：接收客户端发送的地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；缓存所述地址更新请求；在所述地址更新请求对应的超时时间到达之前，如果确定为所述客户端提供服务的服务节点由第一服务节点迁移到第二服务节点，则将所述第二服务节点的地址返回给所述客户端。当客户端请求服务失败时，本发明实施例的方案可加快故障修复速度，提升用户体验。

Description

一种分布式***及其管理方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种分布式***及其管理方法。

背景技术

分布式***的服务框架通常包括如下组件：客户端(Client)：用户端程序，提供用户用于访问服务的接口；服务节点(Server)：为用户提供具体的接口逻辑功能，通常由多个节点组成；主控节点(Master)：主要用于对服务节点进行管理、调度，对客户端进行服务准入认证，以及对集群资源的管理和分配，通常由单个或者多个节点组成。一个典型的分布式***对外提供应用程序接口(API)服务通常包括如下步骤：

1)客户端向主控节点询问所需服务的服务节点地址，由主控节点向客户端返回对应的服务节点地址。

2)客户端调用远程过程调用协议(RPC)访问得到的服务节点地址，以获取所需的服务，整个服务的过程不再需要跟Master节点进行交互。

在上述过程中，分布式***中的服务节点通常是不显示工作状态的，因此，一旦服务节点发生故障，主控节点将服务调度到其他服务节点上之后，客户端需要感知并更新服务地址才能进行正确访问到所需服务，而客户端更新服务地址的速度直接决定了客户端的访问速度以及准确性。目前业界所采用的地址更新方案是由客户端进行周期性地询问，直至得到新的服务地址。然而，这种采用周期轮询访问主控节点的方式，对轮询频率设置要求较高，轮询频率过高，会产生大量的无效请求从而加重主控节点的处理负担，而轮询频率过低，则会降低客户端得到新服务地址的速度。可见，目前的分布式***对于客户端访问服务节点失败时，依然存在无法及时响应的问题。

发明内容

鉴于上述问题，本发明实施例提出了一种分布式***及其管理方法，主要目的在于对客户端在请求服务失败时，提高修复访问故障的速度，提升用户体验。

为达到上述目的，本发明实施例主要提供如下技术方案：

第一方面，本发明实施例提供一种分布式***的管理方法，所述方法应用于分布式***的主控节点，包括：

接收客户端发送的地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；

缓存所述地址更新请求；

在所述地址更新请求对应的超时时间到达之前，如果确定为所述客户端提供服务的服务节点由第一服务节点迁移到第二服务节点，则将所述第二服务节点的地址返回给所述客户端。

第二方面，本发明实施例提供一种分布式***的管理方法，所述方法应用于客户端，包括：

根据第一服务节点反馈的请求失败信息，向主控节点发送地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；

接收所述地址更新请求的响应信息，所述响应信息中包括主控节点存储的所述服务对应的服务节点地址；

若所述响应信息中的服务节点地址为第一服务节点地址，则向主控节点发送地址更新请求；

若所述响应信息中的服务节点地址为第二服务节点地址，则根据所述第二服务节点地址向第二服务节点请求所述服务。

第三方面，本发明实施例提供一种分布式***，所述分布式***包括主控节点、多个服务节点以及至少一个客户端，其中，所述主控节点执行上述第一方面所述的管理方法，所述客户端执行上述第二方面所述的管理方法。

第四方面，本发明实施例提供一种分布式***的管理装置，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在调用所述计算机程序时执行上述第一方面所述的管理方法。

第五方面，本发明实施例提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如上述第一方面所述的管理方法，或实现如上述第二方面所述的管理方法。

借由上述技术方案，本发明实施例提供的一种分布式***及其管理方法，能够让用户在对分布式***中的服务节点请求服务失败时，快速获取提供该服务的服务节点地址，从而成功访问到所需的服务。为此，在该分布式***中，在客户端请求失败，向主控节点发送地址更新请求时，本发明在主控节点中缓存该地址更新请求，使得主控节点不会实时地响应该地址更新请求，而是会根据预设的超时时间缓存地址更新请求，并且在该超时时间内，如果检测到存在新服务节点的地址，则会将其反馈给客户端，否则在达到超时时间后，根据主控节点存储的地址如实反馈客户端。如此，就可以避免采用轮询请求而导致的大量无效请求，减轻了主控节点的处理负担，并且能够在超时时间段内，将最新更新的服务节点地址反馈给客户端，让客户端能够及时得到新服务节点的地址以修复访问故障。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示相同的部件。在附图中：

图1示出了本发明实施例提出的一种分布式***中主控节点的数据访问方法流程图；

图2示出了本发明实施例提出的一种分布式***中客户端的数据访问方法流程图；

图3示出了本发明实施例提出的一种分布式***中服务节点的数据访问方法流程图；

图4示出了本发明实施例提出的一种分布式***中主控节点的组成框图；

图5示出了本发明实施例提出的另一种分布式***中主控节点的组成框图；

图6示出了本发明实施例提出的一种分布式***中客户端的组成框图；

图7示出了本发明实施例提出的另一种分布式***中客户端的组成框图；

图8示出了本发明实施例提出的一种分布式***的组成框图。

具体实施方式

下面将参照附图更详细地描述本发明的示例性实施例。虽然附图中显示了本发明的示例性实施例，然而应当理解，可以以各种形式实现本发明而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本发明，并且能够将本发明的范围完整的传达给本领域的技术人员。

本发明是在现有的分布式***的服务框架下，对客户端访问服务节点出现故障时，为提高故障的修复速度做出的优化改进。在本发明实施例中，访问故障一般是指客户端访问服务节点失败，这种无法访问的原因主要是网络不稳定的问题，或者是服务节点当前无法提供服务等问题。对此，现有的分布式***中，需要通过主控节点核实，在确定当前服务节点无法提供服务时，将该服务迁移至新服务节点，在迁移到新服务节点后，根据客户端的请求提供新服务节点的地址。而在该过程中，由于客户端与主控节点对故障的感知是异步的，导致客户端需要等待主控节点的反馈来修复访问故障。而本发明通过在客户端、主控节点以及服务节点中分别进行优化改进，使得该等待的时间得到缩减，提高了访问故障的修复速率，从而提高用户的应用体验。

以下分别针对本发明在客户端、主控节点以及服务节点中做出的改进通过具体实施例进行说明。

1)、对于分布式***中的主控节点，本发明实施例提供了一种分布式***的管理方法，其具体步骤如图1所示，该方法包括：

步骤101、接收客户端发送的地址更新请求。

其中，该地址更新请求是由客户端在无法正常访问服务节点或无法得到该服务节点提供的服务时，触发的向分布式***中的主控节点发送的请求。该地址更新请求中用于获取为客户端提供服务的服务节点地址。

步骤102、缓存地址更新请求。

主控节点在接收到地址更新请求后，会先将该其缓存在本地，而不是实时反馈该地址更新请求。

步骤103、在地址更新请求对应的超时时间到达之前，如果确定为客户端提供服务的服务节点由第一服务节点迁移到第二服务节点，则将第二服务节点的地址返回给客户端。

本步骤中，第一服务节点是指客户端访问失败的服务节点。而由于主控节点在分布式***中的主要作用之一就是调度***中各个服务节点中所提供的服务，因此，在主控节点中存储有分布式***中各个服务节点的地址，以及各服务节点所提供的服务的标识信息，即在主控节点中记录有当前有效的服务与提供该服务的服务节点地址的对应关系。

由于步骤102中缓存了地址更新请求，而本步骤中的超时时间就是用于确定该地址更新请求的最大缓存时长，在地址更新请求缓存期间，主控节点将判断提供该服务的服务节点是否由第一服务节点迁移到第二服务节点，即判断提供服务的服务节点的地址是否更新为第二服务节点地址，如果是，则将第二服务节点的地址返回给客户端；而如果在达到超时时间时还未更新，则将第一服务节点的地址返回给客户端，对应的，客户端在收到的响应信息中确定为第一服务节点的地址时，将再次发送地址更新请求，即返回执行步骤101的操作。而主控节点一旦响应地址更新请求，则该地址更新请求将会从缓存中删除。

需要说明的是，超时时间的设置可以是由主控节点统一设置或根据不同的服务区别设置的，也可以是由客户端根据实际需求自定义设置的，即不同的客户端可以设置不同的超时时间。

通过上述实施例中的各步骤可知，主控节点在处理客户端发送的地址更新请求时，并不是实时反馈，而是将该地址更新请求缓存在本地一段时间，同时查找所请求服务对应的服务节点是否由第一服务节点迁移至第二服务节点，若在该时间段内确定已迁移，则直接反馈客户端第二服务节点的地址，而若在该时间段内无法确定该服务已迁移，则将本地存储的第一服务节点地址反馈给客户端。由此可知，在超时时间设置较为合理的情况下，就可以避免接收到客户端发送的大量轮询地址更新请求，从而降低主控节点对大量无效请求的重复处理，降低主控节点的处理负担。同时，由于缓存地址更新请求的过程中，主控节点会实时或周期性地监控服务节点地址的更新状态，一旦发现更新就会向客户端进行反馈，如此，也提高了对客户端请求的响应速度，从而减少对访问故障的修复时间。

进一步的，针对图1所示实施例中的步骤103，为了确保判断服务节点迁移的准确性以及第二服务节点地址的可用性，本发明的优选实施例中，客户端会在发送的地址更新请求中添加请求失败信息，该请求失败信息也是由第一服务节点反馈客户端的信息，用于表示客户端向第一服务节点请求失败，其中，请求失败信息中除了具有错误信息(即失败原因，可以由错误代码表示)外还包括有服务版本号等信息。服务版本号用于表示服务的版本信息，本实施例中，服务对应的服务版本号是根据为客户端提供服务所对应的服务节点地址变化而改变的，比如根据服务节点地址的变更而单调增加。也就是说，提供该服务的服务节点每迁移一次，即服务节点地址变更一次，该服务版本号会在原有的版本号的基础上加一。因此，通过对比服务版本号，其数值越大，说明服务版本越新，而对于客户端而言，最大的服务版本号所对应的服务节点才是能有效提供服务的服务节点。

基于所添加的请求失败信息，在执行确定为客户端提供服务的服务节点由第一服务节点迁移到第二服务节点的具体方式包括：

判断主控节点本地存储的该服务对应的服务版本号是否大于地址更新请求中携带的服务版本号。

如果主控节点本地的服务版本号大于请求携带的服务版本号，则说明该服务已经从第一服务节点迁移至第二服务节点，此时，将获取该第二服务节点的地址，并更新本地对应该服务的服务节点地址。

如果主控节点本地的服务版本号等于或小于请求携带的服务版本号，则说明该服务当前没有迁移至第二服务节点，此时，无需更新本地对应该服务的服务节点地址。

进一步的，上述实施例是利用请求失败信息中携带的服务版本号来验证服务节点是否迁移，对于请求失败信息中携带的错误信息，在本发明的另一优选实施例中，则可以用于统计针对第一服务节点的故障信息，从而主动触发对该服务节点所提供的服务进行迁移，具体的：

第一，根据请求失败信息确定向第一服务节点请求该服务失败的客户端数量。

由于主控节点服务于分布式***中的所有客户端，因此，在某一时间段内，可能会接收到多个客户端针对第一服务节点中同一个服务请求失败的地址更新请求，对此，本实施例将由主控节点对这些地址更新请求中携带的请求失败信息进行统计，以确定客户端数量。

需要说明的是，在统计过程中，对于所统计的请求失败信息会进行筛选，这是因为，客户端访问第一服务节点失败的原因可能是由于网络不稳定导致的，也可能是第一服务节点故障或无法提供相应的服务而导致的。而本步骤在统计请求失败信息时，考虑到诸如网络问题导致的访问失败可能是暂时的，不需要进行服务的迁移，因此，对于这类请求失败信息将会过滤掉，得到指定类型的请求失败信息，其中，该指定类型的请求失败信息可以是某一类的请求失败信息，也可以是几类请求失败信息的集合。也就是说，所统计的客户端是由于第一服务节点无法正常响应请求而导致的请求失败。

此外，统计出的客户端数量是指对同一服务节点中提供的相同服务请求失败的客户端的数量。

第二，在客户端数量大于阈值时，触发迁移服务的调度请求。

其中，阈值为自定义设置的经验值，能够根据分布式***的应用场景进行区别设置。

上述说明的是根据客户端上报给主控节点的地址更新请求，主动触发服务迁移的调度请求，此外，主控节点还可以通过与服务节点之间的心跳检测来判断第一服务节点是否存在故障，即判断服务节点是否具有提供该服务的能力，若存在故障，即长时间接收不到第一服务节点的心跳检测，则触发迁移该第一服务节点中所提供服务的调度请求，将这些服务迁移至第二服务节点。

进一步的，针对上述主控节点主动触发迁移服务的调度请求的两种方式，本发明实施例中，主控节点在发出调度请求后，会进一步监控第一服务节点是否完成对服务的迁移，若迁移成功，则更新本地存储的该服务对应的服务版本号，以便主控节点能够及时地监测到该服务发生迁移并告知客户端，即对缓存中相应的地址更新请求进行响应。相对应的，在迁移完成后的第二服务节点中，也会同步更新该服务的服务版本号。

对于主控节点更新本地存储的该服务对应的服务版本号后，主控节点将根据所更新的服务以及对应的服务版本号，对缓存中存储的请求相同服务的地址更新请求进行响应，即对比两者的服务版本号，若大于地址更新请求的服务版本号，则直接向对应的客户端返回更新后的第二服务节点地址。

进一步的，在本发明的另一优选实施例中，客户端也可以不再地址更新请求中设置超时时间，而是预先设置，也就是说，在主控节点中将维护一个超时时间的数据表，该数据表中记录有分布式***中各个客户端所设置的超时时间。如此，主控节点在接收客户端发送的地址更新请求时，就可以根据客户端的标识，在数据表中查找该客户端标识对应的超时时间，进而利用该超时时间缓存地址更新请求。

此外，主控节点对于缓存中的地址更新请求，还可以根据预设周期定期扫描，以判断地址更新请求是否达到对应的超时时间，若达到，且没有第二服务节点的地址时，则将其从缓存中删除，并向对应的客户端反馈第一服务节点的地址。

2)、对于分布式***中的客户端，本发明实施例还提供了一种分布式***的管理方法，其具体步骤如图2所示，该方法包括：

步骤201、根据第一服务节点反馈的请求失败信息，向主控节点发送地址更新请求。

其中，地址更新请求用于获取为该客户端提供服务的服务节点地址。

本步骤是由客户端向第一服务节点请求服务失败后，接收到第一服务节点反馈的请求失败信息，该请求失败信息中至少包括服务版本号等信息，其与上述图1所示实施例中的请求失败信息相同。

步骤202、接收地址更新请求的响应信息。

该响应信息中包括主控节点本地存储的所要请求服务对应的服务节点地址。

地址更新请求经过主控节点的处理后，其具体处理过程为上述图1所示实施例内容。客户端会接收到其反馈的响应信息，该响应信息中包括主控节点存储的服务对应的服务节点地址。其中，主控节点存储的服务对应的服务节点地址不是固定不变的，而是会根据该服务的迁移情况进行更新，所以，如果客户端无法通过第一服务节点请求该服务时，就可以通过询问主控节点已获知提供该服务的服务节点是否变更，即获知是否存在第二服务节点地址。

根据图1所示的实施例可知，主控节点反馈的响应信息中含有服务节点地址，而该服务节点地址有可能是第二服务节点地址，也有可能是原地址(第一服务节点地址)，因此，本发明实施例通过识别响应信息中的服务节点地址确定客户端修复访问故障的具体操作，具体为：当响应信息中的服务节点地址为第二服务节点地址时，执行步骤204；若为第一服务节点地址，则执行步骤203。

步骤203、若响应信息中的服务节点地址为第一服务节点地址，则向主控节点发送地址更新请求。

该步骤是得到的服务节点地址仍然为第一服务节点地址时，说明主控节点中未发现该服务存在迁移的情况，此时，客户端将再次向主控节点发送地址更新请求。需要说明的是，发送该地址更新请求的时间与上一次发送的时间之间的间隔时长应大于超时时间，相对现有的按照一定频率周期轮询的方式，本发明实施例中的超时时间一般会大于轮询周期，因此，对于客户端而言，该方式可以减少对向主控节点发送地址更新请求的数量，也减少了大量无效请求对主控节点的处理负担。

步骤204、若响应信息中的服务节点地址为第二服务节点地址，则根据第二服务节点地址向第二服务节点请求服务。

该步骤是得到不同的服务节点地址时，说明主控节点已更新了该服务对应的服务节点地址，即服务已经迁移至第二服务节点，此时，客户端就可以根据该第二服务节点地址进行访问，即向第二服务节点请求该服务。

通过上述步骤，详细说明了本发明提出的分布式***的客户端在发生访问故障时具体的故障修复流程，通过该流程可以大大提高故障修复的速度，减少向主控节点发送的无效请求。

进一步的，基于图2所示的实施例，在向主控节点发送地址更新请求之前，为了能够减少主控节点处理地址更新请求的压力，本实施例中，还可在将服务从第一服务节点迁移至其他服务节点时，将其他服务节点的地址保存在第一服务节点中，而当客户端向第一服务节点请求该服务时，将其他服务节点的地址添加到请求失败信息中一同反馈给客户端。如此，客户端在接收到第一服务节点反馈的请求失败信息时，就可以先判断请求失败信息中是否存在第三服务节点(其他服务节点)的地址，若存在，则可以根据第三服务节点地址直接向第三服务节点请求该服务，无需再触发向主控节点发送地址更新请求。若不存在，则可能是第一服务节点自身的故障导致无法提供该服务，也可能是该服务在迁移过程中导致无法提供服务。也就是说，此时无法确定访问失败的原因，对此，客户端将触发向主控节点发送地址更新请求，即执行上述的步骤201。需要说明的是，上述的第三服务节点也可以为第二服务节点。

进一步的，基于图2所示的实施例，为了更准确地验证服务所对应的服务节点地址是否更新为第二服务节点地址，在本发明的另一优选实施例中，客户端在触发地址更新请求时，可以将所请求的服务的服务版本号添加到地址更新请求中。如此，主控节点就可以基于该服务版本号对其在主控节点中存储的该服务的服务版本号进行验证，即服务版本号高的为当前有效版本，具体的验证过程已在上述主控节点的实施例中进行了详细说明，此处不再赘述。

进一步，由于客户端可以对同一个服务节点提供的多个服务进行并发请求，且都存在访问故障的可能，此时，客户端就有可能对主控节点并发多个地址更新请求，而在分布式***中，客户端的数量众多，为了减轻主控节点处理并发请求的负担，本发明将设置第一阈值，以此来限制客户端对同一个服务节点并发的地址更新请求的数量，比如，服务节点A中有5个服务，客户端对着5个服务同时发起访问，其中有4个是访问失败的，此时，假设第一阈值设置为2，那么，该客户端将只能向主控节点发送2个地址更新请求，等待其中一个处理完成后，再发送第3个地址更新请求，以此类推，直至发送4个地址更新请求，完成访问故障的修复，即，客户端向主控节点并发的请求数量上限为2。

此外，客户端除了限制对同一个服务节点触发的地址更新请求的并发数量外，还可以对所有客户端总体的并发数量进行限制，即在多个客户端并发访问多个服务节点且访问故障时，会限制所有客户端向主控节点并发地址更新请求的总数量，该数量值设置为第二阈值，其与第一阈值都可以自定义设置。比如，假设第二阈值为10，而主控节点当前已经在处理的地址更新请求有7个，当服务节点A存在5个并发的访问故障时，其需要先询问主控节点还可以处理几个地址更新请求，即3个，此时，只能将5个地址更新请求中的3个发送至主控节点。

进一步的，基于上述对客户端并发地址更新请求的流控方式，为了避免高流量服务节点对应的地址更新请求抢占低流量服务节点对应的地址更新请求，本发明实施例还设置了允许每个服务节点至少发送一个地址更新请求。比如，服务节点A为高流量节点，其有4个并发的访问失败的请求，且第一阈值为2，有2个地址更新请求被限，服务节点B为低流量节点，其只有1个访问失败的请求，并且由于第二预置为2，导致B的地址更新请求被限，按照上述的流控原则，当主控节点处理完成一个地址更新请求后，此时将优先处理B对应的地址更新请求，而不是等A的地址更新请求都处理完成后再处理B的地址更新请求。

3)、对于分布式***中的服务节点，本发明实施例还提供了一种分布式***的管理方法，其具体步骤如图3所示，该方法包括：

步骤301、根据客户端发送服务请求，判断是否具有访问权限。

在分布式***中，不同的服务节点提供的不同服务中可能需要读取同一存储地址中的数据，而对于具有访问限制的数据而言，为了避免被过多的用户同时访问，其在访问过程中只能对应于一个服务。因此，服务请求是否成功，还取决于服务节点中的该服务是否有权限访问。本实施例中，可以通过文件锁的获取来确定服务节点中的服务是否具有访问权限，即由需要读取同一具有访问限制数据的多个服务进行抢锁，成功抢锁的服务具有对该数据的访问权限。而对于上述实施例中的第一服务节点而言，就是判断其所属的服务是否抢到文件锁，若抢到，则具有访问权限，执行步骤302，反之则执行步骤303。

步骤302、若具有，则获取服务对应的访问权限数据作为该服务请求的响应信息。

步骤303、若不具有，则查询具有访问权限的第二服务节点的地址，将所述第二服务节点的地址添加至响应信息中。

其中，本步骤中的响应信息为第一服务节点响应服务请求失败时的回复信息。

可见，本发明实施例中第一服务节点通过对服务访问权限的记录可以查询到具有权限的目标服务节点，以此来记录服务迁移的状态，从而在响应客户端的服务请求时，即使无法返回访问权限数据，也可以将具有访问权限的服务节点的地址反馈给客户端，让客户端直接访问该服务节点，而无需触发地址更新请求至主控节点，提高访问故障的修复速度。

进一步的，为了确保查询出的目标服务节点能够提供有效的服务，本发明的优先实施例中，还可以通过判断服务的服务版本号进行验证。具体查询过程如下：

首先，在查询到第二服务节点的地址后，获取该第二服务节点中提供该服务的服务版本号。

之后，判断第二服务节点中的服务版本号是否大于第一服务节点存储的服务版本号，若大于，则将该新地址添加至响应信息中，否则不添加该新地址。

服务版本号的比较原则在上述主控节点和客户端中已做说明，此处不再赘述。

进一步的，作为对上述图1所示方法的实现，本发明实施例提供了一种分布式***的主控节点，主要用于提高访问故障的修复速度，提升用户的使用体验。为便于阅读，本实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的主控节点能够对应实现前述方法实施例中的全部内容。该主控节点如图4所示，具体包括：

接收单元41，用于接收客户端发送的地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；

缓存单元42，用于缓存所述地址更新请求；

响应单元43，用于在所述地址更新请求对应的超时时间到达之前，如果确定为所述客户端提供服务的服务节点由第一服务节点迁移到第二服务节点，则将所述第二服务节点的地址返回给所述客户端。

进一步的，所述地址更新请求中还包括请求失败信息，所述请求失败信息用于表示所述客户端向所述第一服务节点请求失败；

所述请求失败信息还包括服务版本号，所述服务版本号根据为所述客户端提供服务的服务节点地址变化而改变。

进一步的，如图5所示，所述响应单元43包括：

判断模块431，用于判断所述主控节点存储的所述服务对应的服务版本号是否大于所述地址更新请求中携带的服务版本号；

确定模块432，用于若判断模块431确定大于，则确定所述服务迁移至所述第二服务节点，并获取该第二服务节点地址。

进一步的，如图5所示，所述主控节点还包括：

统计单元44，用于根据请求失败信息确定向所述第一服务节点请求所述服务失败的客户端数量，所述请求失败信息是由于所述第一服务节点无法响应请求而生成的；

触发单元45，用于在所述统计单元44确定的客户端数量大于阈值时，触发迁移所述服务的调度请求，将所述服务从第一服务节点迁移至第二服务节点。

进一步的，所述触发单元45还用于，利用心跳检测判断所述第一服务节点是否存在故障；若存在，则触发迁移所述服务的调度请求，将所述服务从第一服务节点迁移至第二服务节点。

进一步的，如图5所示，所述主控节点还包括：

更新单元46，用于根据所述触发单元45触发的调度请求，监测所述第一服务节点是否完成对所述服务的迁移；若迁移成功，则更新更新主控节点存储的所述服务对应的服务版本号。

进一步的，所述响应单元43还用于，在更新所述主控节点存储的所述服务对应的服务版本号后，利用所述更新后的服务版本号对比所述缓存中请求相同服务的地址更新请求对应的服务版本号；若大于地址更新请求的服务版本号，则执行将所述第二服务节点的地址返回给所述客户端的操作。

进一步的，所述响应单元43还用于，根据预设周期定期扫描缓存中的地址更新请求，判断所述地址更新请求是否达到对应的超时时间；若达到，则删除缓存中的所述地址更新请求，向客户端反馈所述第一服务节点的地址。

进一步的，作为对上述图2所示方法的实现，本发明实施例提供了一种分布式***的客户端，主要用于提高访问故障的修复速度，提升用户的使用体验。为便于阅读，本实施例不再对前述方法实施例中的细节内容进行逐一赘述，但应当明确，本实施例中的客户端能够对应实现前述方法实施例中的全部内容。该主控节点如图6所示，具体包括：

第一发送单元51，用于根据第一服务节点反馈的请求失败信息，向主控节点发送地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；

接收单元52，用于接收所述地址更新请求的响应信息，所述响应信息中包括主控节点存储的所述服务对应的服务节点地址；

所述第一发送单元51还用于，若所述响应信息中的服务节点地址为第一服务节点地址，则向主控节点发送地址更新请求；

第二发送单元53，用于若所述响应信息中的服务节点地址为第二服务节点地址，则根据所述第二服务节点地址向第二服务节点请求所述服务。

进一步的，如图7所示，所述客户端还包括：

判断单元54，用于在第一发送单元51向主控节点发送地址更新请求之前，判断所述请求失败信息中是否存在第三服务节点地址；

服务请求单元55，用于若存在，则根据所述第三服务节点地址向第三服务节点请求所述服务；

所述第一发送单元51还用于，若不存在，则向主控节点发送地址更新请求。

进一步的，如图7所示，所述请求失败信息中包含服务版本号，所述服务版本号根据为所述客户端提供服务的服务节点地址变化而改变，所述客户端还包括：

添加单元56，用于将所述请求失败信息添加至所述地址更新请求中。

进一步的，如图7所示，所述客户端还包括：

并发控制单元57，用于当对同一个服务节点存在多个并发请求失败信息时，控制向主控节点发送所述服务的地址更新请求的数量小于第一阈值；控制向主控节点并发多个服务的地址更新请求的总数量小于第二阈值。

进一步的，所述并发控制单元57还用于，在控制向主控节点发送地址更新请求的数量时，每个服务节点至少允许发送一个地址更新请求。

进一步的，在所述第一服务节点中的服务被迁移至第二服务节点后，所述服务请求单元55还用于，向第一服务节点发送服务请求，所述第一服务节点根据所述服务请求判断是否具有服务访问权限，若具有，则获取所述服务对应的访问权限数据作为所述服务请求的响应信息，反之，则查询具有访问权限的第二服务节点的地址，将所述第二服务节点的地址添加至所述响应信息中；

所述接收单元52还用于，接收所述第一服务节点反馈的所述响应信息。

进一步的，所述服务请求单元55还用于，判断所述响应信息中含有的第二服务节点所对应的服务版本号是否大于本地存储所述服务的服务版本号；若大于，则根据所述第二服务节点的地址向第二服务节点请求所述服务。

综合上述各实施例的内容，本发明实施例还提出了一种分布式***，具体如图8所示，该***包括主控节点(Master)、多个服务节点(Server)以及至少一个客户端(Client)，其中

所述客户端在访问第一服务节点提供的服务失败时，判断所述第一服务节点反馈的请求失败信息中是否存在第二服务节点的地址，若存在，则向所述第二服务节点发送服务请求；若不存在，则向所述主控节点发送地址更新请求；

所述主控节点接收到所述地址更新请求后，将所述地址更新请求缓存，在超时时间内到达之前，若检测到所述服务的服务节点由第一服务节点迁移到第二服务节点，则向客户端反馈所述第二服务节点的地址，若未检测到，则在达到所述超时时间时，向客户端反馈所述第一服务节点的地址；

所述第一服务节点在接收到所述客户端的服务请求时，判断该服务是否具有访问权限，在不具有访问权限时，获取具有访问权限的目标服务节点的地址，将其地址反馈给所述客户端。

此外，在上述图1-3中还具体说明了主控节点、服务节点、客户端各自的工作流程，其同样适用于该分布式***，其具体说明此处不再赘述。

进一步的，根据上述的分布式***，本发明实施例还提出了一种管理装置，设置在分布式***的主控节点中，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在调用所述计算机程序时执行实现如图1-3所述的管理方法。

进一步的，本发明实施例还提出了一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现如图1-3所述的管理方法。

在上述实施例中，对各个实施例的描述都各有侧重，某个实施例中没有详述的部分，可以参见其他实施例的相关描述。

可以理解的是，上述方法及装置中的相关特征可以相互参考。另外，上述实施例中的“第一”、“第二”等是用于区分各实施例，而并不代表各实施例的优劣。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的***，装置和单元的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

在此提供的算法和显示不与任何特定计算机、虚拟***或者其它设备固有相关。各种通用***也可以与基于在此的示教一起使用。根据上面的描述，构造这类***所要求的结构是显而易见的。此外，本发明也不针对任何特定编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容，并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

此外，存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)，存储器包括至少一个存储芯片。

本领域内的技术人员应明白，本申请的实施例可提供为方法、***、或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例、或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

本申请是参照根据本申请实施例的方法、设备(***)、和计算机程序产品的流程图和/或方框图来描述的。应理解可由计算机程序指令实现流程图和/或方框图中的每一流程和/或方框、以及流程图和/或方框图中的流程和/或方框的结合。可提供这些计算机程序指令到通用计算机、专用计算机、嵌入式处理机或其他可编程数据处理设备的处理器以产生一个机器，使得通过计算机或其他可编程数据处理设备的处理器执行的指令产生用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的装置。

这些计算机程序指令也可存储在能引导计算机或其他可编程数据处理设备以特定方式工作的计算机可读存储器中，使得存储在该计算机可读存储器中的指令产生包括指令装置的制造品，该指令装置实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能。

这些计算机程序指令也可装载到计算机或其他可编程数据处理设备上，使得在计算机或其他可编程设备上执行一系列操作步骤以产生计算机实现的处理，从而在计算机或其他可编程设备上执行的指令提供用于实现在流程图一个流程或多个流程和/或方框图一个方框或多个方框中指定的功能的步骤。

在一个典型的配置中，计算设备包括一个或多个处理器(CPU)、输入/输出接口、网络接口和内存。

存储器可能包括计算机可读介质中的非永久性存储器，随机存取存储器(RAM)和/或非易失性内存等形式，如只读存储器(ROM)或闪存(flash RAM)。存储器是计算机可读介质的示例。

计算机可读介质包括永久性和非永久性、可移动和非可移动媒体可以由任何方法或技术来实现信息存储。信息可以是计算机可读指令、数据结构、程序的模块或其他数据。计算机的存储介质的例子包括，但不限于相变内存(PRAM)、静态随机存取存储器(SRAM)、动态随机存取存储器(DRAM)、其他类型的随机存取存储器(RAM)、只读存储器(ROM)、电可擦除可编程只读存储器(EEPROM)、快闪记忆体或其他内存技术、只读光盘只读存储器(CD-ROM)、数字多功能光盘(DVD)或其他光学存储、磁盒式磁带，磁带磁磁盘存储或其他磁性存储设备或任何其他非传输介质，可用于存储可以被计算设备访问的信息。按照本文中的界定，计算机可读介质不包括暂存电脑可读媒体(transitory media)，如调制的数据信号和载波。

还需要说明的是，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、商品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、商品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括要素的过程、方法、商品或者设备中还存在另外的相同要素。

本领域技术人员应明白，本申请的实施例可提供为方法、***或计算机程序产品。因此，本申请可采用完全硬件实施例、完全软件实施例或结合软件和硬件方面的实施例的形式。而且，本申请可采用在一个或多个其中包含有计算机可用程序代码的计算机可用存储介质(包括但不限于磁盘存储器、CD-ROM、光学存储器等)上实施的计算机程序产品的形式。

以上仅为本申请的实施例而已，并不用于限制本申请。对于本领域技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原理之内所作的任何修改、等同替换、改进等，均应包含在本申请的权利要求范围之内。

Claims (18)

1.一种分布式***的管理方法，其特征在于，所述方法应用于分布式***的主控节点，包括：

接收客户端发送的地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；

缓存所述地址更新请求；

在所述地址更新请求对应的超时时间到达之前，如果确定为所述客户端提供服务的服务节点由第一服务节点迁移到第二服务节点，则将所述第二服务节点的地址返回给所述客户端。

2.根据权利要求1所述的方法，其特征在于，所述地址更新请求中还包括请求失败信息，所述请求失败信息用于表示所述客户端向所述第一服务节点请求失败；

所述请求失败信息包括服务版本号，所述服务版本号根据为所述客户端提供服务的服务节点地址变化而改变。

3.根据权利要求2所述的方法，其特征在于，所述确定为所述客户端提供服务的服务节点由第一服务节点迁移到第二服务节点，包括：

判断所述主控节点存储的所述服务对应的服务版本号是否大于所述地址更新请求中携带的服务版本号；

若大于，则确定所述服务迁移至所述第二服务节点，并获取第二服务节点地址。

4.根据权利要求2所述的方法，其特征在于，所述方法还包括：

根据请求失败信息确定向所述第一服务节点请求所述服务失败的客户端数量，所述请求失败信息是由于所述第一服务节点无法响应请求而生成的；

在所述客户端数量大于阈值时，触发迁移所述服务的调度请求，将所述服务从第一服务节点迁移至第二服务节点。

5.根据权利要求1所述的方法，其特征在于，所述方法还包括：

利用心跳检测判断所述第一服务节点是否存在故障；

若存在，则触发迁移所述服务的调度请求，将所述服务从第一服务节点迁移至第二服务节点。

6.根据权利要求4或5所述的方法，其特征在于，所述方法还包括：

根据所述调度请求，监测所述第一服务节点是否完成对所述服务的迁移；

若迁移成功，则更新所述主控节点存储的所述服务对应的服务版本号。

7.根据权利要求6所述的方法，其特征在于，在更新所述主控节点存储的所述服务对应的服务版本号后，所述方法还包括：

利用所述更新后的服务版本号对比所述缓存中请求相同服务的地址更新请求对应的服务版本号；

若大于所述地址更新请求对应的服务版本号，则将所述第二服务节点的地址返回给所述客户端。

8.根据权利要求1所述的方法，其特征在于，所述方法还包括：

根据预设周期扫描缓存中的地址更新请求，判断所述地址更新请求是否达到对应的超时时间；

若达到，则删除缓存中的所述地址更新请求，向客户端反馈所述第一服务节点的地址。

9.一种分布式***的管理方法，其特征在于，所述方法应用于客户端，包括：

根据第一服务节点反馈的请求失败信息，向主控节点发送地址更新请求，所述地址更新请求用于获取为所述客户端提供服务的服务节点地址；

接收所述地址更新请求的响应信息，所述响应信息中包括主控节点存储的所述服务对应的服务节点地址；

若所述响应信息中的服务节点地址为第一服务节点地址，则向主控节点发送地址更新请求；

若所述响应信息中的服务节点地址为第二服务节点地址，则根据所述第二服务节点地址向第二服务节点请求所述服务。

10.根据权利要求9所述的方法，其特征在于，所述向主控节点发送地址更新请求之前，所述方法还包括：

判断所述请求失败信息中是否存在第三服务节点地址；

若存在，则根据所述第三服务节点地址向第三服务节点请求所述服务；

若不存在，则执行向主控节点发送地址更新请求的操作。

11.根据权利要求9所述的方法，其特征在于，所述请求失败信息中包含服务版本号，所述服务版本号根据为所述客户端提供服务的服务节点地址变化而改变，所述方法还包括：

将所述请求失败信息添加至所述地址更新请求中。

12.根据权利要求9所述的方法，其特征在于，所述方法还包括：

当对同一个服务节点存在多个并发请求失败信息时，控制向主控节点发送所述服务的地址更新请求的数量小于第一阈值；

控制向主控节点并发多个服务的地址更新请求的总数量小于第二阈值。

13.根据权利要求12所述的方法，其特征在于，所述方法还包括：

在控制向主控节点发送地址更新请求的数量时，每个服务节点至少允许发送一个地址更新请求。

14.根据权利要求9所述的方法，其特征在于，所述方法还包括：

向第一服务节点发送服务请求，所述第一服务节点根据所述服务请求判断是否具有服务访问权限，若具有，则获取所述服务对应的访问权限数据作为所述服务请求的响应信息，反之，则查询具有访问权限的第二服务节点的地址，将所述第二服务节点的地址添加至所述响应信息中；

接收所述第一服务节点反馈的所述响应信息。

15.根据权利要求14所述的方法，其特征在于，所述方法还包括：

判断所述响应信息中含有的第二服务节点所对应的服务版本号是否大于客户端存储所述服务的服务版本号；

若大于，则根据所述第二服务节点的地址向第二服务节点请求所述服务。

16.一种分布式***，其特征在于，所述分布式***包括主控节点、多个服务节点以及至少一个客户端，其中，所述主控节点执行权利要求1-8中任一项所述管理方法，所述客户端执行权利要求9-15中任一项所述的管理方法。

17.一种分布式***的管理装置，其特征在于，包括：存储器和处理器，所述存储器用于存储计算机程序；所述处理器用于在调用所述计算机程序时执行如权利要求1-8任一项所述的管理方法。

18.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现如权利要求1-8任一项所述的管理方法，或实现如权利要求9-15任一项所述的管理方法。

Images