服务故障处理方法、终端设备及可读存储介质
技术领域
本申请涉及通信技术领域,具体而言,涉及一种服务故障处理方法、终端设备及可读存储介质。
背景技术
在分布式系统中,通常会有多个独立运行的进程实现独立功能,并以服务的形式对外提供功能支持,对外提供服务的方式通常为暴露http或RPC调用接口,以供客户端调用。这些服务可能运行在同一服务器上,也可能分散在不同服务器上。
目前,在客户端发现与其通信的服务器无法提供服务时,一般需要网络管理员手动切换到另一服务器上,使得客户端与另一服务器通信。然后在管理员手动切换的过程中,服务中断时间可能较长,在这段时间中,客户端所请求的业务也会中断,这大大影响了客户端的运行效率。
发明内容
本申请实施例的目的在于提供一种服务故障处理方法、终端设备及可读存储介质,用以改善现有技术中通过管理员手动切换服务器影响客户端的运行效率的问题。
第一方面,本申请实施例提供了一种服务故障处理方法,应用于客户端,所述方法包括:确定向第一服务器发送的业务请求响应失败;从配置的服务器地址列表中确定目标服务器地址;向所述目标服务器地址对应的第二服务器重新发送所述业务请求。
在上述实现过程中,客户端在确定向第一服务器发送的业务请求响应失败时,重新从配置的服务器地址列表中确定目标服务器地址,从而可使得在第一服务器响应失败后,客户端可快速切换到目标服务器地址对应的第二服务器,重新向第二服务器请求服务,以快速恢复与服务器的业务通信,进而可有效减小对客户端的运行效率的影响。
可选地,所述确定向第一服务器发送的业务请求响应失败,包括:
若未在约定时间内接收到所述第一服务器针对所述业务请求返回的响应时,则确定向所述第一服务器发送的业务请求响应失败;或者若连续多次未在约定时间内接收到所述第一服务器针对所述业务请求返回的响应时,则确定向所述第一服务器发送的业务请求响应失败。
在上述实现过程中,通过上述方式客户端可准确确定向第一服务器发送的业务请求是否响应失败。
可选地,在所述确定向第一服务器发送的业务请求响应失败之后,所述方法还包括:
将所述第一服务器标记为失效服务器,从而可使得客户端记录失效的服务器,以便于管理员针对失效服务器进行维修,或者避免客户端继续查找到的服务器地址为失效服务器时使得客户端请求服务的时间较长的问题。
可选地,所述服务器地址列表包括失效服务器地址列表以及有效服务器地址列表,所述将所述第一服务器标记为失效服务器,包括:
将所述第一服务器对应的第一服务器地址添加至所述失效服务器地址列表中;
所述从配置的服务器地址列表中确定目标服务器地址,包括:
从所述有效服务器地址列表中确定目标服务器地址。
在上述实现过程中,通过将服务器地址列表分为失效服务器地址列表和有效服务器地址列表,将失效服务器对应的服务器地址移入到失效服务器地址列表中,并从有效服务器地址列表中确定目标服务器地址,则可以使得客户端可快速找到有效服务器地址,以快速建立与服务器之间的通信。
可选地,所述将所述第一服务器对应的第一服务器地址添加至所述失效服务器地址列表中之后,还包括:
在预设时间段后将所述第一服务器从所述失效服务器地址列表中移入所述有效服务器地址列表中,并重新向所述第一服务器发送业务请求,从而可避免失效服务器永久失效的问题,使得客户端可以重新与恢复可用的服务器进行通信。
可选地,所述方法还包括:
向配置服务器发送查询服务器地址是否更新的查询请求;
若接收到表征所述服务器地址有更新的反馈信息时,根据所述反馈信息中携带的更新的服务器地址更新所述服务器地址列表。
在上述实现过程中,通过向配置服务器发送查询请求,以及时更新服务器地址列表,从而可以在服务器地址变化时,客户端能够将业务通信转移到新的服务器。
可选地,所述向配置服务器发送查询服务器地址是否更新的查询请求,包括:
在接收到所述配置服务器发送的广播报文时,向所述配置服务器发送查询服务器地址是否更新的查询请求,所述广播报文用于通知所述客户端所述配置服务器从故障状态恢复到工作状态。
在上述实现过程中,配置服务器通过发送广播报文,可使得客户端知晓配置服务器已恢复工作状态,从而可及时从配置服务器那获取服务器地址更新信息,便于及时对服务器地址列表进行更新。
可选地,所述服务器地址列表包括按服务能力顺序排列的多个服务器地址,所述从配置的服务器地址列表中确定目标服务器地址,包括:
从所述服务器地址列表中确定所述第一服务器对应的第一服务器地址,以及排在所述第一服务器地址的下一位的第二服务器地址,所述目标服务器地址为所述第二服务器地址,所述第二服务器的服务能力不低于所述第一服务器。
在上述实现过程中,通过按照服务器的服务能力对多个服务器地址进行排序,使得客户端优先切换到服务器能力较强的服务器,从而可确保客户端与服务器之间的稳定通信。
第二方面,本申请实施例提供了一种服务故障处理装置,运行于客户端,所述装置包括:
响应确定模块,用于确定向第一服务器发送的业务请求响应失败;
地址获取模块,用于从配置的服务器地址列表中确定目标服务器地址;
请求重发模块,用于向所述目标服务器地址对应的第二服务器重新发送所述业务请求。
可选地,所述响应确定模块,用于若未在约定时间内接收到所述第一服务器针对所述业务请求返回的响应时,则确定向所述第一服务器发送的业务请求响应失败;或者若连续多次未在约定时间内接收到所述第一服务器针对所述业务请求返回的响应时,则确定向所述第一服务器发送的业务请求响应失败。
可选地,所述装置还包括:
失效标记模块,用于将所述第一服务器标记为失效服务器。
可选地,所述服务器地址列表包括失效服务器地址列表以及有效服务器地址列表,所述失效标记模块,用于将所述第一服务器对应的第一服务器地址添加至所述失效服务器地址列表中;
所述地址获取模块,用于从所述有效服务器地址列表中确定目标服务器地址。
可选地,所述装置还包括:
地址移动模块,用于在预设时间段后将所述第一服务器从所述失效服务器地址列表中移入所述有效服务器地址列表中,并重新向所述第一服务器发送业务请求。
可选地,所述装置还包括:
地址更新模块,用于向配置服务器发送查询服务器地址是否更新的查询请求;若接收到表征所述服务器地址有更新的反馈信息时,根据所述反馈信息中携带的更新的服务器地址更新所述服务器地址列表。
可选地,所述地址更新模块,用于在接收到所述配置服务器发送的广播报文时,向所述配置服务器发送查询服务器地址是否更新的查询请求,所述广播报文用于通知所述客户端所述配置服务器从故障状态恢复到工作状态。
可选地,所述服务器地址列表包括按服务能力顺序排列的多个服务器地址,所述地址获取模块,用于从所述服务器地址列表中确定所述第一服务器对应的第一服务器地址,以及排在所述第一服务器地址的下一位的第二服务器地址,所述目标服务器地址为所述第二服务器地址,所述第二服务器的服务能力不低于所述第一服务器。
第三方面,本申请实施例提供一种终端设备,包括处理器以及存储器,所述存储器存储有计算机可读取指令,当所述计算机可读取指令由所述处理器执行时,运行如上述第一方面提供的所述方法中的步骤。
第四方面,本申请实施例提供一种可读存储介质,其上存储有计算机程序,所述计算机程序被处理器执行时运行如上述第一方面提供的所述方法中的步骤。
本申请的其他特征和优点将在随后的说明书阐述,并且,部分地从说明书中变得显而易见,或者通过实施本申请实施例了解。本申请的目的和其他优点可通过在所写的说明书、权利要求书、以及附图中所特别指出的结构来实现和获得。
附图说明
为了更清楚地说明本申请实施例的技术方案,下面将对本申请实施例中所需要使用的附图作简单地介绍,应当理解,以下附图仅示出了本申请的某些实施例,因此不应被看作是对范围的限定,对于本领域普通技术人员来讲,在不付出创造性劳动的前提下,还可以根据这些附图获得其他相关的附图。
图1为本申请实施例提供的一种用于执行服务故障处理方法的终端设备的结构示意图;
图2为本申请实施例提供的一种服务故障处理方法的流程图;
图3为本申请实施例提供的一种客户端、配置服务器与服务器之间的交互示意图;
图4为本申请实施例提供的一种服务故障处理装置的结构框图。
具体实施方式
下面将结合本申请实施例中附图,对本申请实施例中的技术方案进行清楚、完整地描述。
本申请实施例提供一种服务故障处理方法,通过在确定向第一服务器发送的业务请求响应失败时,重新从配置的服务器地址列表中确定目标服务器地址,然后向目标服务器地址对应的第二服务器重新发送该业务请求,从而可使得在第一服务器响应失败后,客户端可快速切换到目标服务器地址对应的第二服务器,重新向第二服务器请求服务,以快速恢复与服务器的业务通信,进而可有效减小对客户端的运行效率的影响。
本申请提供的服务故障处理方法可应用于客户端,客户端可以理解为是终端设备,也可以是终端设备上安装的软件或者应用程序等,在客户端为终端设备时,该终端设备用于执行本申请提供的服务故障处理方法。
如图1所示,图1为本申请实施例提供的一种用于执行服务故障处理方法的终端设备的结构示意图,所述终端设备可以包括:至少一个处理器110,例如CPU,至少一个通信接口120,至少一个存储器130和至少一个通信总线140。其中,通信总线140用于实现这些组件直接的连接通信。其中,本申请实施例中设备的通信接口120用于与其他节点设备进行信令或数据的通信。存储器130可以是高速RAM存储器,也可以是非易失性的存储器(non-volatile memory),例如至少一个磁盘存储器。存储器130可选的还可以是至少一个位于远离前述处理器的存储装置。存储器130中存储有计算机可读取指令,当所述计算机可读取指令由所述处理器110执行时,终端设备执行下述图2所示方法过程,例如,存储器130可用于存储配置的服务器地址列表,处理器110在进行服务故障处理时,可从存储器130中获取服务器地址列表,并从该服务器地址列表中确定目标服务器地址,以向目标服务器地址对应的第二服务器重新发送业务请求。
可以理解,图1所示的结构仅为示意,所述终端设备还可包括比图1中所示更多或者更少的组件,或者具有与图1所示不同的配置。图1中所示的各组件可以采用硬件、软件或其组合实现。
请参照图2,图2为本申请实施例提供的一种服务故障处理方法的流程图,该方法包括如下步骤:
步骤S110:确定向第一服务器发送的业务请求响应失败。
在不同的应用场景下,客户端所请求的服务可能分布在一个服务器上,也可能分布在多个服务器上,例如,客户端请求查询某个数据的服务时,而这数据可能存储在多个服务器中,这样客户端在请求查询该数据的服务时,可以向多个服务器中的其中一个服务器发送该业务请求,这种情况下,客户端向服务器发送的业务请求即为查询该数据。当然,在不同应用场景下,其业务请求所请求的业务不同,且可响应对应的业务请求的服务器也可能不同。在本申请实施例中的第一服务器和第二服务器均是客户端认为可以响应客户端的业务请求的服务器。
第一服务器可以是上述多个服务器中的其中一个服务器,或者,可以指定客户端优先向哪个服务器发送业务请求,如指定第一服务器为客户端优先发送业务请求的服务器,这样客户端可先向第一服务器发送业务请求。
而可能在某些情况下,由于第一服务器故障,或者第一服务器与客户端之间的网络连接故障,使得第一服务器无法获得客户端发送的业务请求,也就无法响应客户端发送的业务请求,或者客户端无法接收到第一服务器返回的响应。
其中,客户端确定向第一服务器发送的业务请求响应失败的方式可以有如下两种方式:
1、若未在约定时间内接收到第一服务器针对业务请求返回的响应时,则确定响应失败。
举例来说,客户端在向第一服务器发送业务请求后,等待第一服务器的响应,若客户端在约定时间内未收到响应时,或者收到的响应为错误响应,如不是针对业务请求返回的响应,则认为第一服务器响应失败。
其中,约定时间可以根据实际需求灵活设置,如10s或15s等,在本申请实施例中不特别限定。
2、若连续多次未在约定时间内接收到第一服务器针对业务请求返回的响应时,则确定响应失败。
例如,客户端第一次向第一服务器发送业务请求后,若未在约定时间内接收到第一服务器针对该业务请求的响应,则客户端可再次向第一服务器发送业务请求,若还是在约定时间内未接收到第一服务器针对业务请求的响应时,则客户端可继续向第一服务器发送业务请求,直到第N次发送业务请求,第一服务器还是未响应时,则确定响应失败。
也就是说,客户端最多向第一服务器发送N次业务请求,每次间隔时间为约定时间,若N次均未接收到第一服务器返回的响应时,则确定响应失败。其中,N可以根据实际需求灵活设置,如5或6等,在本申请实施例中对其不做具体限定。
当然,在一些其他实施方式中,确定响应失败的方式还可以为:服务器返回的响应不合法,即服务器针对业务请求返回的是与业务请求无关的信息,并且该信息可能涉及到不合法信息,如返回指示用户填写个人隐私信息的页面,或者返回的是一些不合法的广告页面等,在这种情况下,也确定服务器响应失败。
应理解的是,确定服务器响应失败的方式还可以有其他方式,对于其他实现方式也应包含在本申请的保护范围之内。
步骤S120:从配置的服务器地址列表中确定目标服务器地址。
在客户端确定第一服务器针对发送的业务请求响应失败后,可从配置的服务器地址列表中重新确定另一目标服务器地址,该目标服务器地址为除第一服务器对应的第一服务器地址外的其他服务器的地址。
服务器地址列表可以是配置在客户端中的,其包括可以响应客户端的业务请求的多个服务器对应的地址,这样客户端在确定第一服务器响应失败后,即可从服务器地址列表中选择另一服务器地址,然后向另一服务器地址对应的服务器重新发送业务请求,从而可使得即使第一服务器响应失败,也仍然可以通过其他服务器响应。
在一些实施方式中,客户端可以从服务器地址列表中任意选择另一服务器地址作为目标服务器地址,也可以按照一定的策略选择另一服务器地址作为目标服务器地址,例如,选择服务器地址列表中与第一服务器对应的第一服务器地址相邻的服务器地址中的一个服务器地址作为目标服务器地址。
步骤S130:向目标服务器地址对应的第二服务器重新发送所述业务请求。
在获得目标服务器地址后,客户端可向目标服务器地址对应的第二服务器重新发送业务请求,这样客户端可尝试从第二服务器获得针对业务请求的响应。
可以理解地,若第二服务器也无法针对业务请求进行响应,即客户端确定向第二服务器发送的业务请求也响应失败时,客户端也可继续从服务器地址列表中重新选择另一服务器地址,然后再向另一服务器地址对应的服务器发送业务请求,直到找到可用的服务器,即找到可以接收到针对业务请求返回的响应为止;或者直到服务器地址列表中所对应的所有服务器均无法针对业务请求进行响应,这种情况下,客户端可向后台服务器上报提示信息,以提示维修人员对服务器地址列表中所对应的服务器进行故障查看,或者客户端还可以请求更新服务器地址列表。
在上述实现过程中,客户端在确定向第一服务器发送的业务请求响应失败时,重新从配置的服务器地址列表中确定目标服务器地址,从而可使得在第一服务器响应失败后,客户端可快速切换到目标服务器地址对应的第二服务器,重新向第二服务器请求服务,以快速恢复与服务器的业务通信,进而可有效减小对客户端的运行效率的影响。
在一些实施方式中,为了便于客户端快速找到可用的服务器,在确定向第一服务器发送的业务请求响应失败后,还可以将第一服务器标记为失效服务器,这样客户端在下次发送新的业务请求时,不用再向标记为失效的服务器发送,而是可以向其他有效服务器(如未标记为失效的服务器)发送业务请求,这样客户端就不用一直还尝试向已经无法响应的服务器继续发送业务请求,避免客户端继续查找到的服务器地址为失效服务器时使得客户端请求服务的时间较长的问题。并且,也可以便于管理员在客户端查看失效服务器,并可及时对失效服务器进行维修等。
其中,将第一服务器标记为失效服务器的方式可以为:将服务器地址列表中第一服务器对应的第一服务器地址添加失效标记,失效标记可以根据实际情况设定,如数字“0”,则在第一服务器地址上添加失效标记为0,当然也可以采用其他方式来表征失效标记,在此不一一列举。
或者,将第一服务器标记为失效服务器的方式还可以为:将第一服务器地址从服务器地址列表中移出。当然,也可以采用其他方式标记第一服务器为失效服务器,在此不一一列举。
可以理解地,在客户端向第二服务器发送业务请求后,若确定第二服务器也响应失败,则也将第二服务器标记为失效服务器。也就是说,客户端可以将无法响应业务请求的服务器均标记为失效服务器。
在一些实施方式中,为了便于区分无效服务器和有效服务器,可以将服务器地址列表分为失效服务器地址列表和有效服务器地址列表,这样在将第一服务器标记为失效服务器的方式中,还可以将第一服务器对应的第一服务器地址添加到失效服务器地址列表中。
可以理解地,在客户端向第一服务器发送业务请求之前,第一服务器地址可以是在有效服务器地址列表中,此时认为第一服务器为有效服务器,然后在确定第一服务器对业务请求响应失败后,则将第一服务器地址从有效服务器地址列表中移入到无效服务器地址列表中。
另外,上述确定目标服务器地址时,可以从有效服务器地址列表中确定目标服务器地址。可以理解地,有效服务器地址列表中包含的服务器地址为当前认为有效的服务器地址,即客户端认为这些有效服务器地址对应的服务器可以响应其发送的业务请求,而失效服务器地址列表中包含的服务器地址为当前认为失效的服务器地址,客户端认为这些失效服务器地址对应的服务器无法响应其发送的业务请求。所以客户端在确定目标服务器地址时,可以从有效服务器地址列表中查找目标服务器地址,如可从有效服务器地址列表中任意选择一个服务器地址作为目标服务器地址,或者按照一定的策略确定目标服务器地址,从而使得查找到的目标服务地址对应的第二服务器可能是有效的服务器,使得客户端可快速找到有效服务器地址,以快速建立与服务器之间的通信。
在一些实施方式,为了避免失效服务器地址列表对应的服务器被永久标记为失效,而客户端无法再与其进行通信。还可以在预设时间段后将加入失效服务器地址列表中的服务器地址移入有效服务器地址列表中,例如,可以在预设时间段后将第一服务器从失效服务器地址列表中移入有效服务器地址列表中,并重新向第一服务器发送业务请求。
其中,预设时间段可以根据实际情况灵活设置,如2小时或1天等。可以理解地,每个服务器地址加入失效服务器地址列表中的时间可能不同,所以,还可以在将各个服务器地址加入失效服务器地址列表中时,记录对应其加入的时间,并在客户端重启一个进程用于监控各个服务器地址的到期时间。在预设时间段后,将到期的服务器地址从失效服务器地址列表中移入有效服务器地址列表中,从而可允许客户端再次尝试连接。
在一些其他实施方式中,也可通过用户手动将失效服务器重置为有效,或者通过用户将失效服务器对应的服务器地址从失效服务器地址列表中移入有效服务器地址列表中,从而可便于对服务器的管理和灰度升级。
可以理解地,若第一服务器标记为失效服务器后,此时客户端与第二服务器进行正常通信,若客户端检测到第一服务器地址重新移入到有效服务器地址列表中时,或者第一服务器重新标记为有效服务器时,则客户端可重新向第一服务器发送后续的业务请求,以尝试与第一服务器重新建立通信连接。
或者,若第一服务器与第二服务器均标记为失效服务器,此时客户端与第三服务器进行正常通信,而第一服务器地址可能先移入到有效服务器地址列表中,客户端可先尝试与第一服务器建立通信。若与第一服务器正常通信过程中,检测到第二服务器对应的目标服务器地址移入有效服务器地址列表中,此时客户端不进行通信切换,即客户端继续与第一服务器进行通信,直至第一服务器对客户端的业务请求响应失败时,再切换到与第二服务器进行通信。但是,若在第一服务地址移入到有效服务器地址列表中后,若客户端与第一服务器建立通信失败,即第一服务器针对客户端发送的业务请求响应失败,则可以重新将第一服务器地址移入失效服务器地址中,客户端继续与第三服务器进行通信,若又检测到目标服务器地址移入有效服务器地址列表中时,则客户端又尝试与第二服务器建立通信,这样使得客户端尽量与先前已经通信或者尝试通信过的服务器进行通信。
在上述实现过程中,在预设时间段后将所述第一服务器从所述失效服务器地址列表中移入所述有效服务器地址列表中,并重新向所述第一服务器发送业务请求,从而可避免失效服务器永久失效的问题,使得客户端可以重新与恢复可用的服务器进行通信。
另外,为了便于确定目标服务器地址,服务器地址列表可以包括按服务能力顺序排列的多个服务器地址,上述确定目标服务器地址的方式还可以为:从服务器地址列表中确定第一服务器对应的第一服务器地址,以及排在第一服务器地址的下一位的第二服务器地址,该目标服务器地址为第二服务器地址,第二服务器的服务能力不低于第一服务器。
上述的服务能力可以包括负载能力、传输带宽、运算能力、响应速度等中的至少一种。多个服务器地址包括至少两个服务器地址,在将多个服务器地址进行排序时,可以先获取这多个服务器地址对应的服务器的服务能力,然后基于这些服务器的服务能力进行排序。可以理解地,可在客户端上先配置一个服务器地址列表,用户可在客户端中输入表征各个服务器的服务能力的相关参数信息,这样客户端即可针对各个服务器的服务能力对多个服务器地址进行排序。
当然,也可以在客户端配置服务器地址列表时,该服务器地址列表中的多个服务器地址即就按照各个服务器的服务能力预先排序好的,这样客户端在确定目标服务器地址时,即可从排序好的多个服务器地址中找到对应的目标服务器地址。
其中,排序的方式可以是按照服务能力由强到弱排序,或者是按照服务能力由弱到强排序,若两个服务器的服务能力等同时,该两个服务器对应的服务器地址可随机排序。
在排序方式按照服务器能力由强到弱排序时,若第一服务器地址排在第一位,表示第一服务器的服务能力最强,此时,若没有与第一服务器的服务能力相同的第二服务器时,则客户端也可将排在第一服务器地址后一位的服务器地址作为目标服务器地址,或者可选择排在第一服务器地址后的任一服务器地址作为目标服务器地址。若第一服务器地址不是排在第一位,则可选择排在第一服务器地址前面的任意一个服务器地址作为目标服务器地址,或者是选择排在第一服务器地址前面一位的服务器地址作为目标服务器地址(这种情况下,上述所说的目标服务器地址(也即第二服务器地址)为排在第一服务器地址前面一位的服务器地址)。
在排序方式按照服务器能力由弱到强排序时,若第一服务器地址排在最后一位,表示第一服务器的服务能力最强,此时,若没有与第一服务器的服务能力相同的第二服务器时,则客户端也可将排在第一服务器地址前一位的服务器地址作为目标服务器地址,或者可选择排在第一服务器地址前的任一服务器地址作为目标服务器地址。若第一服务器地址不是排在最后一位,则可选择排在第一服务器地址后面的任意一个服务器地址作为目标服务器地址,或者是选择排在第一服务器地址后面一位的服务器地址作为目标服务器地址(这种情况下,上述所说的目标服务器地址(也即第二服务器地址)为排在第一服务器地址后面一位的服务器地址)。
在上述实现过程中,通过按照服务器的服务能力对多个服务器地址进行排序,使得客户端优先切换到服务器能力较强的服务器,从而可确保客户端与服务器之间的稳定通信。
在一些实施方式中,服务器地址列表若是包括排列好的多个服务器地址,这些服务器地址可以是用户根据实际需求排列的,客户端中还可以配置负载均衡策略,负载均衡策略用于指示某个服务器失效后,客户端重新发送业务请求的服务器为哪一个。如该负载均衡策略指示第一服务器失效后,其目标服务器地址为排在第一服务器地址后一位的服务器地址,也即,客户端在确定第一服务器失效后,直接查找排在第一服务器地址的后一位服务器地址,并将该服务器地址确定为目标服务器地址。
或者,服务器地址列表中的多个服务器列表未按照一定顺序排列,而负载均衡策略指示在某个服务器地址标记为失效后,确定与其有关联关系的服务器地址作为目标服务器地址,也即负载均衡策略规定了各个服务器地址之间的关联关系,其关联关系可如下所示:
第一服务器地址->第二服务器地址;
第二服务器地址->第三服务器地址;
……;
第N服务器地址->第一服务器地址。
在配置好上述的关联关系后,客户端即可根据上述关联关系查找获得对应的目标服务器地址。例如,若在第二服务器地址失效后,根据上述的关联关系确定目标服务器地址为第三服务器地址。但是,若此时第三服务器地址也标记为失效时,则继续查找对应的第四服务器地址,直至找到未标记为失效的服务器地址作为目标服务器地址。
在一些实施方式中,与客户端通信的服务器地址可能存在更新,如增加与客户端通信的服务器或者删除与客户端通信的服务器,或者服务器地址变化等,为了便于对服务器地址列表进行更新,可通过配置服务器来对与客户端通信的服务器进行维护,其中,客户端、配置服务器与服务器之间的交互可如图3所示。
配置服务器可以获取与客户端进行通信的多个服务器的相关信息,如服务器地址、负载能力、传输带宽等,并可以根据多个服务器的服务地址生成服务器地址列表。其获得服务器地址列表的方式可以是根据各个服务器的服务能力对多个服务器地址列表进行排序后生成的,也可以是通过用户在配置服务器上配置相应的服务器地址列表而获得的。
由于客户端有多个,若在每个客户端中均配置服务器地址列表,可能需要耗费较多的时间,所以通过在配置服务器上配置服务器地址列表,由配置服务器将服务器地址列表下发至各个客户端,则可减少配置的时间。
客户端将配置服务器下发的服务器地址列表进行存储,并可以实时或定时向配置服务器发送查询服务器地址是否更新的查询请求,若接收到表征服务器地址有更新的反馈信息时,则可根据反馈信息中携带的更新的服务器地址更新服务器地址列表。
可以理解地,为了确保能够及时更新服务器地址列表,客户端可以实时向配置服务器发送查询请求,而为了减轻客户端以及配置服务器的处理负担,客户端也可以定时向配置服务器发送查询请求。配置服务器在接收到查询请求后,可根据查询请求查找是否有服务器的服务器地址发生变化,或者服务器地址列表中多个服务器地址的排序是否有变化,或者是否有增删服务器地址等,若有变化,则可将变化信息携带在反馈信息中发送给客户端,从而客户端即可根据反馈信息更新服务器地址列表。
或者,配置服务器也可以在检测到服务器地址列表有变化时,主动向客户端发送反馈信息,这样可在减少客户端的负担的情况下也可确保客户端能及时更新服务器地址列表。
在一些实施方式中,若某个服务器对应的服务器地址发生变化时,则配置服务器可针对该服务器地址添加对应的更新标记,客户端在向配置服务器发送的查询请求中携带查询对应的服务器地址是否有更新标记,若配置服务器在查找到有更新标记时,则将更新后的服务器地址携带在反馈信息中发送给客户端。
另外,针对上述实施例中的负载均衡策略也可以是配置在配置服务器中,然后由配置服务器下发给客户端,客户端还可以实时或定时查询负载均衡策略是否有更新,在有更新时,也可对应更新客户端存储的负载均衡策略。
在上述实现过程中,通过向配置服务器发送查询请求,以及时更新服务器地址列表,从而可以在服务器地址变化时,客户端能够将业务通信转移到新的服务器。
在一些实施方式中,若配置服务器发生故障后,客户端无法查询到服务器地址列表是否有更新,则客户端可按照当前存储的服务器地址列表与服务器进行通信,这样即使在配置服务器发生故障后,客户端仍然可以自行寻找服务器进行通信。
而在配置服务器从故障状态恢复到工作状态时,配置服务器可向各个客户端发送广播报文,则客户端在接收到广播报文时,可重新向配置服务器发送查询服务器地址是否更新的查询请求,该广播报文即用于通知客户端配置服务器从故障状态恢复到工作状态。
在上述实现过程中,配置服务器通过发送广播报文,可使得客户端知晓配置服务器已恢复工作状态,从而可及时从配置服务器那获取服务器地址更新信息,便于及时对服务器地址列表进行更新。
在另外一些实施方式中,上述实施例提供的方法可以是在配置服务器故障时由客户端执行的,而在配置服务器正常运行之后,其也可以由配置服务器来运行。也就是说,上述实施例提供的方法可以是在客户端向配置服务器发送查询请求,若在约定时间未接收到配置服务器的响应时,则确定配置服务器发生故障,然后客户端即可按照自身存储的服务器地址列表,向第一服务器发送业务请求,在确定向第一服务器发送的业务请求响应失败时,查找目标服务器地址,再重新向目标服务器地址对应的第二服务器发送业务请求,这样使得即使配置服务器故障时,客户端的业务请求也可以直达服务器,降低了配置服务器引起的单点故障而导致网络瘫痪的问题。
而在配置服务器恢复正常运行时,也即客户端在接收到广播报文知晓配置服务器恢复工作状态后,可由配置服务器来执行上述方法(此时配置服务器可以为代理服务器,具有网络代理功能),即客户端可将业务请求提交给配置服务器,由配置服务器将业务请求转发给第一服务器,若确定第一服务器无法响应时,则配置服务器从配置的服务器地址列表中确定目标服务器地址,然后将业务请求重新转发给对应的第二服务器。
当然,在配置服务器执行上述方法的期间,客户端也可实时或定时向配置服务器发送查询服务器地址是否更新的查询请求,以便于在配置服务器故障时,其可以依据自身获得的服务器地址列表来选择对应的服务器进行通信。
请参照图4,图4为本申请实施例提供的一种服务故障处理装置200的结构框图,该装置200可以是终端设备(客户端为终端设备)上的模块、程序段或代码。应理解,该装置200与上述图2方法实施例对应,能够执行图2方法实施例涉及的各个步骤,该装置200具体的功能可以参见上文中的描述,为避免重复,此处适当省略详细描述。
可选地,所述装置200包括:
响应确定模块210,用于确定向第一服务器发送的业务请求响应失败;
地址获取模块220,用于从配置的服务器地址列表中确定目标服务器地址;
请求重发模块230,用于向所述目标服务器地址对应的第二服务器重新发送所述业务请求。
可选地,所述响应确定模块210,用于若未在约定时间内接收到所述第一服务器针对所述业务请求返回的响应时,则确定向所述第一服务器发送的业务请求响应失败;或者若连续多次未在约定时间内接收到所述第一服务器针对所述业务请求返回的响应时,则确定向所述第一服务器发送的业务请求响应失败。
可选地,所述装置200还包括:
失效标记模块,用于将所述第一服务器标记为失效服务器。
可选地,所述服务器地址列表包括失效服务器地址列表以及有效服务器地址列表,所述失效标记模块,用于将所述第一服务器对应的第一服务器地址添加至所述失效服务器地址列表中;
所述地址获取模块220,用于从所述有效服务器地址列表中确定目标服务器地址。
可选地,所述装置200还包括:
地址移动模块,用于在预设时间段后将所述第一服务器从所述失效服务器地址列表中移入所述有效服务器地址列表中,并重新向所述第一服务器发送业务请求。
可选地,所述装置200还包括:
地址更新模块,用于向配置服务器发送查询服务器地址是否更新的查询请求;若接收到表征所述服务器地址有更新的反馈信息时,根据所述反馈信息中携带的更新的服务器地址更新所述服务器地址列表。
可选地,所述地址更新模块,用于在接收到所述配置服务器发送的广播报文时,向所述配置服务器发送查询服务器地址是否更新的查询请求,所述广播报文用于通知所述客户端所述配置服务器从故障状态恢复到工作状态。
可选地,所述服务器地址列表包括按服务能力顺序排列的多个服务器地址,所述地址获取模块220,用于从所述服务器地址列表中确定所述第一服务器对应的第一服务器地址,以及排在所述第一服务器地址的下一位的第二服务器地址,所述目标服务器地址为所述第二服务器地址,所述第二服务器的服务能力不低于所述第一服务器。
需要说明的是,本领域技术人员可以清楚地了解到,为描述的方便和简洁,上述描述的装置的具体工作过程,可以参考前述方法实施例中的对应过程,在此不再重复描述。
本申请实施例提供一种可读存储介质,所述计算机程序被处理器执行时,执行如图2所示方法实施例中终端设备所执行的方法过程。
本实施例公开一种计算机程序产品,所述计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序,所述计算机程序包括程序指令,当所述程序指令被计算机执行时,计算机能够执行上述各方法实施例所提供的方法,例如,包括:确定向第一服务器发送的业务请求响应失败;从配置的服务器地址列表中确定目标服务器地址;向所述目标服务器地址对应的第二服务器重新发送所述业务请求。
综上所述,本申请实施例提供一种服务故障处理方法、终端设备及可读存储介质,通过客户端在确定向第一服务器发送的业务请求响应失败时,重新从配置的服务器地址列表中确定目标服务器地址,从而可使得在第一服务器响应失败后,客户端可快速切换到目标服务器地址对应的第二服务器,重新向第二服务器请求服务,以快速恢复与服务器的业务通信,进而可有效减小对客户端的运行效率的影响。
在本申请所提供的实施例中,应该理解到,所揭露装置和方法,可以通过其它的方式实现。以上所描述的装置实施例仅仅是示意性的,例如,所述单元的划分,仅仅为一种逻辑功能划分,实际实现时可以有另外的划分方式,又例如,多个单元或组件可以结合或者可以集成到另一个系统,或一些特征可以忽略,或不执行。另一点,所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些通信接口,装置或单元的间接耦合或通信连接,可以是电性,机械或其它的形式。
另外,作为分离部件说明的单元可以是或者也可以不是物理上分开的,作为单元显示的部件可以是或者也可以不是物理单元,即可以位于一个地方,或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
再者,在本申请各个实施例中的各功能模块可以集成在一起形成一个独立的部分,也可以是各个模块单独存在,也可以两个或两个以上模块集成形成一个独立的部分。
在本文中,诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来,而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。
以上所述仅为本申请的实施例而已,并不用于限制本申请的保护范围,对于本领域的技术人员来说,本申请可以有各种更改和变化。凡在本申请的精神和原则之内,所作的任何修改、等同替换、改进等,均应包含在本申请的保护范围之内。