CN106060088A - 一种服务管理方法及装置 - Google Patents

Abstract

本申请实施例公开了一种服务管理方法及装置，涉及计算机技术领域，上述方法应用于服务管理系统中的管理器，服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端；管理器通过预设的第一端口与服务器通信连接，管理器通过预设的第二端口与客户端通信连接；包括：接收并存储服务器发送的自身的属性和状态；接收客户端发送的服务申请；根据预设的服务申请响应策略、服务器的属性和/或服务器的状态，确定目标服务器；向客户端发送针对服务申请的申请响应，以使得客户端根据申请响应向目标服务器请求服务，其中，申请响应中携带目标服务器的属性。应用本申请实施例提供的方案，能够使得客户端的服务请求得到及时响应。

Description

一种服务管理方法及装置

技术领域

本申请涉及计算机技术领域，特别涉及一种服务管理方法及装置。

背景技术

随着计算机技术的快速发展，各类分布式应用程序得到了越来越广泛的应用。其中，大多数分布式应用程序以客户端/服务器的方式进行工作，即服务器对外提供服务，客户端也就是应用程序享受服务。

在上述客户端/服务器方式的工作过程中，各个客户端需知晓各个服务器监听的IP地址、TCP端口等等信息，这样，客户端向服务器请求服务时，才能根据上述知晓的信息选择可用的服务器为其提供服务。

然而，现有技术中，客户端只有在重启的时候才会更新各个服务器监听的IP地址、TCP端口等等信息，而客户端两次重启之间，各个服务器所监听的信息可能会发生变化，这样应用上述方式客户端则无法及时了解到服务器所监听信息的真实情况，进而导致客户端的服务请求可能无法及时得到响应。

发明内容

本申请实施例公开了一种服务管理方法和装置，以使得客户端的服务请求得到及时响应。

为达到上述目的，本申请实施例公开了一种服务管理方法，应用于服务管理系统中的管理器，其中，所述服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端；所述管理器通过预设的第一端口与所述服务器通信连接，所述管理器通过预设的第二端口与所述客户端通信连接；所述方法包括：

接收并存储所述服务器发送的自身的属性和状态；

接收所述客户端发送的服务申请；

根据预设的服务申请响应策略、所述服务器的属性和/或所述服务器的状态，确定目标服务器；

向所述客户端发送针对所述服务申请的申请响应，以使得所述客户端根据所述申请响应向所述目标服务器请求服务，其中，所述申请响应中携带所述目标服务器的属性。

为达到上述目的，本申请实施例公开了一种服务管理装置，应用于服务管理系统中的管理器，其中，所述服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端；所述管理器通过预设的第一端口与所述服务器通信连接，所述管理器通过预设的第二端口与所述客户端通信连接；所述装置包括：

信息存储模块，用于接收并存储所述服务器发送的自身的属性和状态；

申请接收模块，用于接收所述客户端发送的服务申请；

服务器确定模块，用于根据预设的服务申请响应策略、所述服务器的属性和/或所述服务器的状态，确定目标服务器；

响应发送模块，用于向所述客户端发送针对所述服务申请的申请响应，以使得所述客户端根据所述申请响应向所述目标服务器请求服务，其中，所述申请响应中携带所述目标服务器的属性。

由以上可见，本申请实施例提供的方案中，服务器向管理器发送自身的属性和状态后，管理器接收并存储上述服务器的属性和状态，客户端向管理器发送服务申请，管理器根据预设的服务申请响应策略、上述服务器的属性和/或上述服务器的状态，确定目标服务器，并向客户端发送针对服务申请的申请响应，客户端接收到申请响应后，并向目标服务器请求服务。由于服务器会向管理器发送其自身的属性和状态，所以，管理器能够及时了解各个服务器的真实情况，这样管理器确定出的目标服务器为能够向客户端提供服务的服务器，进而能够使得客户端的服务请求能够得到及时响应。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为本申请实施例提供的一种服务管理系统的结构示意图；

图2为本申请实施例提供的另一种服务管理系统的结构示意图；

图3为本申请实施例提供的一种服务管理方法的流程示意图；

图4为本申请实施例提供的另一种服务管理方法的流程示意图；

图5为本申请实施例提供的再一种服务管理方法的流程示意图；

图6为本申请实施例提供的一种服务管理装置的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

由于现有技术中客户端无法及时了解服务器所监听信息的真实情况，导致客户端的服务请求无法及时得到响应，本申请提供了一种服务管理方法和装置，以使得客户端的服务请求得到及时响应。本申请实施例提供的服务管理方法和装置应用于服务管理系统中的管理器。

下面首先从服务管理系统的角度对本申请实施例提供的服务管理方法进行总体介绍。

上述服务管理系统包括：一个管理器(Manager)、至少两个服务器(Server)和至少一个客户端(Client)。

需要说明的是，上述管理器、服务器和客户端均可以理解为软件端，属于按照软件的实现功能划分得到的，可以位于同一物理实体上，也可以位于不同的物理实体上，本申请并不对此进行限定。

为保证系统正常运行，Server在启动后根据Manager的标准端口，向Manager发送注册消息，Manager通过上述标准端口接收到注册消息后，根据该注册消息完成Server的注册，其中，上述标准端口可以理解为：Manager的、预设的软件端口。

然后，Server主动根据预设的第一端口向Manager上报自身的属性和状态，Manager通过上述预设的第一端口接收Server上报的属性和状态，另外，Server在发现自身的属性、状态发生变化后，也会将变化后的属性、状态主动上报至Manager，这样Manager就可以很好的了解该系统中各个Server的真实信息。

当各个Client存在服务需求时，首先根据预设的第二端口向Manager发送服务申请，Manager通过预设的第二端口接收服务申请，由于Manager能够很好的了解系统中各个Server的属性和状态，因此，在接收到上述服务申请后，能够结合各个Server的属性和状态确定为Client提供服务的目标Server，并将该目标Server的属性发送至Client。

其中，上述属性可以包括Server类型、IP地址、Port信息等等；

第一端口和第二端口是预先设定好的，可以理解为Manager上的软件端口，分别用于实现Manager与Server之间的通信、Manager与Client之间的通信，第一端口和第二端口均可以是TCP(Transmission Control Protocol，传输控制协议)端口或者UDP(User Data Protocol，用户数据报协议)端口，第一端口的类型与第二端口的类型可以相同，也可以不同，本申请并不对此进行限定。

Client在接收到上述目标Server的属性后，可以根据接收到的属性中包括的IP地址确定目标Server，然后根据接收到的属性中包括的目标Port信息发送服务请求，目标Server通过目标Port接收上述服务请求，并响应上述服务请求。

图1为本申请实施例提供的一种服务管理系统的结构示意图，该系统包括：一个管理器、至少两个服务器和至少一个客户端，管理器通过预设的第一端口与服务器通信连接，管理器通过预设的第二端口与客户端通信连接。

具体的，服务器，用于向管理器发送自身的属性和状态；

管理器，用于接收并存储上述服务器的属性和状态；

客户端，用于向管理器发送服务申请；

管理器，用于接收服务申请，根据预设的服务申请响应策略、上述服务器的属性和/或上述服务器的状态，确定目标服务器，并向客户端发送针对服务申请的申请响应，其中，申请响应中携带目标服务器的属性；

客户端，用于接收申请响应，并向目标服务器请求服务。

具体的，上述服务器的属性可以包括：服务类型、IP地址、端口信息等等，本申请并不对此进行限定。

上述服务器的属性中的服务类型可用于协助管理器确定目标服务器，管理器确定目标服务器后，可将目标服务器的IP地址、端口信息等等发送至客户端，这样客户端可以根据目标服务器的IP地址、端口信息等等请求服务。

服务器向管理器发送自身的属性时，可以是在服务器启动之后向管理器发送自身的属性，还可以是服务器在检测到自身的属性发生变化之后向管理器发送自身的属性。

具体的，上述状态可以包括：Working(正常工作中)、Closed(已关闭)、NoService(故障中)、Updating(升级中)等等。

服务器向管理器发送自身的状态时，可以是在服务器启动之后向管理器发送自身的状态，还可以是服务器在检测到自身的状态发生变化之后向管理器发送自身的状态。

依据上述系统结构，本领域内的技术人员可以理解的是，上述管理器向上为服务器提供端口，也就是用于在管理器与服务器之间进行数据传输的端口，向下为客户端提供端口，也就是用于在管理器与客户端之间进行数据传输的端口。上述端口均可以理解为管理器上的软件端口。

具体的，管理器接收并存储服务器的属性和状态时，可以通过预设的第一端口接收服务器的属性和状态，并存储服务器的属性和状态；

管理器接收服务申请时，可以通过预设的第二端口接收服务申请。

鉴于上述情况，管理器接收并存储上述服务器的属性和状态后，还可以依据服务类型等信息进行适配转换，得到与客户端对应的接口相匹配的信息。

例如，管理器接收到服务器A发送的属性包括：

ZK(ZooKeeper)类型(服务类型)、A的IP地址和A的端口信息，

管理器对上述服务器A进行适配转换，将服务器A划分至用于提供ZK服务的服务器类别Z，并得到与针对客户端的接口相匹配的信息：A的IP地址和A的端口信息。

在本申请的一种具体实现方式中，服务器还用于在向管理器发送自身的属性和状态之前，向管理器发送注册请求；

管理器，还用于接收注册请求，并响应注册请求。

可选的，上述注册请求可以是服务器第一次启动或者是重启后向管理器发送的。上述注册请求中可以包含用户名、密码等信息，管理器接收到上述注册请求后，对其中携带的信息进行验证，若验证通过，则可以认为是注册成功。

另外，由上述描述可知，服务器和管理器之间能够进行通信则说明两者之间是成功建立了通信连接的，为提高系统的安全性，服务器与管理器之间的通信连接可以是经过验证的安全连接，可以简单的理解为通过用户名、密码等信息进行了安全验证的安全连接。

与服务器与管理器之间的连接类似，客户端与管理器之间也需要成功建立安全连接，为提高系统的安全性，客户端与管理器之间的连接也可以是经过验证的安全连接。

需要说明的是，通常情况下提供服务的服务器为主服务器。

实际应用中，处于正常工作状态的服务器由于各种原因出现故障，若出现故障的服务器当前正在向客户端提供服务，则可能会造成服务中断，鉴于此，在本申请的一种具体实现方式中，

管理器，还用于监测服务器的状态，当监测到主服务器处于故障状态时，将提供服务的服务器由主服务器切换至备服务器。这样即使主服务器出现故障，也不会带来向客户端所提供服务的中断，而且服务器切换操作是由管理器完成的，在客户端而言，完全感受不到服务器的切换，因此不会对客户端带来任何影响。

具体的，管理器监测服务器的状态时，可以通过向服务器发送用于探测服务器是否在线的第一心跳信息的方式监测。当然，管理器还可以通过判断预设时长内是否接收到服务器发送的信息的方式监测服务器的状态，例如，预设时长内接收到了服务器发送的信息，则可以认为该服务器处于正常工作状态，相反，若预设时长内没有接收到服务器发送的信息，则可以任务该服务器处于故障状态。

在本申请的一种可选实现方式中，管理器还可以监测主服务器的状态，当监测到主服务器的状态由故障状态切换回正常工作状态，则还可以将提供服务的服务器由备服务器切换回主服务器。

假设，当前向客户端提供服务的服务器为服务器A，服务器A为主服务器，服务器B为备服务器，服务器A出现故障，管理器监测到服务器A出现故障后，确定由服务器B向客户端提供服务，即发生了服务器切换，提供服务的服务器由服务器A切换到了服务器B。

具体的，管理器还可以继续监测服务器A的状态，当监测到服务器A故障恢复后，可以确定由服务器A向客户端提供服务，也就提供服务的服务器由服务器B切换至服务器A。

本领域内的技术人员可以理解的是，由于业务需要等原因可能会对各个服务器进行升级，但是若要升级的服务器当前正在为客户端提供服务，直接对该服务器进行升级的话，势必造成服务中断。鉴于此，在本申请的一种具体实现方式中，管理器，还用于接收到针对主服务器的升级指令时，将提供服务的服务器由主服务器切换至备服务器。这样的话，在主服务器进行升级时，由备服务器为客户端提供服务，不会带来客户端所享受服务的中断，另外，从客户端的角度而言，由于服务器切换是由管理器完成的，且服务没有中断，所以客户端不会感受到服务器的切换。

可选的，管理器，还用于在主服务器完成升级后，将提供服务的服务器由备服务器切换回主服务器。

管理器监测主服务器是否完成升级时，可以通过向主服务器发送用于探测该服务器是否在线的心跳信息的方式监测，还可以通过检测是否接收到该服务器发送的信息的方式监测，若接收到该服务器发送的信息，则认为主服务器完成了升级。

需要说明的是，本申请只是以此为例进行说明，实际应用中管理器监测主服务器是否完成升级的方式并不仅限于此。

假设，当前向客户端提供服务的服务器为服务器A，服务器A为主服务器，服务器B为备服务器，服务器A需要进行升级，管理器接收到服务器A进行升级的指令后，确定由服务器B向客户端提供服务，即发生了服务器切换，提供服务的服务器由服务器A切换到了服务器B。

具体的，管理器还可以继续监测服务器A的状态，当监测到服务器A升级完成后，可以确定由服务器A向客户端提供服务，提供服务的服务器由服务器B切回原来的服务器A。

具体的，上述预设的服务申请响应策略，可以包括以下策略中的至少一种：

根据服务申请中携带的客户端的信息、服务类型和服务器的状态，确定与客户端匹配的目标服务器；其中，客户端的信息包括：客户端标识等等；

根据服务器的负载状态、服务器的优先级，确定目标服务器；

根据服务器提供服务的时间，确定目标服务器，这种情况下，可以将接收服务申请的时间与各个服务器提供服务的时间进行匹配，根据匹配的服务时间对应的服务器，确定目标服务器。

例如，假设，服务器A为用于为人力资源部的员工提供ZK服务的服务器，且处于正常工作状态，服务器B为用于为研发部的员工提供ZK服务的服务器，且处于正常工作状态，服务器C为用于为研发部的员工提供ZK服务的服务器，且处于故障状态。

情况一：服务申请中携带的信息如下：

客户端M的信息包括：人力资源部的员工X(客户端标识)，

服务类型为ZK类型，

服务器的状态为：正常工作状态，

则管理器根据上述服务器申请中携带的信息可以确定目标服务器为服务器A，这样上述客户端M可以向服务A请求服务。

情况二：服务申请中携带的信息如下：

客户端N的信息包括：人力资源部的员工Y(客户端标识)，

服务类型为ZK类型，

服务器的状态为：故障状态，

则管理器根据上述服务器申请中携带的信息可以确定目标服务器为服务器C，这样上述客户端N可以向服务C请求查看服务器C的故障信息等。

在本申请的一种实现方式中，客户端和服务器还可以自主发现管理器，

具体的，客户端，还用于广播或组播用于发现管理器的第一报文；

管理器，还用于接收第一报文，并向客户端发送第一发现响应；

客户端，还用于接收第一发现响应，进而确定成功发现管理器，这时可以理解为建立了管理器与客户端之间的通信连接；

服务器，还用于广播或组播用于发现管理器的第二报文，其中，第二报文中携带预设的针对服务器的广播或组播地址；

管理器，还用于接收第二报文，并向服务器发送第二发现响应；

服务器，还用于接收第二发现响应，进而确定成功发现管理器，这时可以理解为建立管理器与服务器之间的通信连接。

需要说明的是，上述管理器可以理解为一台终端设备，如，服务器，还可以理解为运行于终端设备上的软件，本申请并不对此进行限定。

在本申请的一种具体实现方式中，管理器，还用于通过向服务器发送用于探测服务器是否在线的第一心跳信息，维护与所述服务器之间的连接；

管理器，还用于通过向客户端发送用于探测客户端是否在线的第二心跳信息，维护与所述客户端之间的连接。

具体的，管理器向服务器发送第一心跳信息后，若在一定时长内接收到服务器的反馈信息，可以认为服务器处于在线状态，说明管理器与服务器之间的连接处于正常状态，若在一定时长内没有接收到服务器的反馈信息，则可以认为服务器处于离线状态，说明管理器与服务器之间的连接处于异常状态。

站在服务器的角度而言，若服务器间隔一定时长没有接收到管理器发送的第一心跳信息，则说明管理器与服务器之间的连接处于异常状态，而若服务器在一定时长内接收到了管理器发送的第一心跳信息，则说明管理器与服务器之间的连接处于正常状态。

管理器与客户端之间的情况和管理器与服务器之间的情况类似，这里不再赘述。

这样管理器能够及时掌握服务器、客户端的在线情况，有利于准确有效的确定目标服务器。

由以上可见，上述各个实施例提供的方案中，服务器向管理器发送自身的属性和状态后，管理器接收并存储上述服务器的属性和状态，客户端向管理器发送服务申请，管理器根据预设的服务申请响应策略、上述服务器的属性和/或上述服务器的状态，确定目标服务器，并向客户端发送针对服务申请的申请响应，客户端接收到申请响应后，并向目标服务器请求服务。由于服务器会向管理器发送其自身的属性和状态，所以，管理器能够及时了解各个服务器的真实情况，这样管理器确定出的目标服务器为能够向客户端提供服务的服务器，进而能够使得客户端的服务请求能够得到及时响应。

下面在通过具体实例对上述服务管理系统进行介绍。

本实例中，上述服务器为：ZooKeeper Server，其中，ZooKeeper为(ApacheZooKeeper的简称，或者还可以简称ZK)是Apache基金会开发的分布式应用协调服务，它为分布式应用程序提供了诸如统一命名服务、配置管理、分布式锁等服务。ZooKeeper具有开源、使用简单、性能高效、稳定可靠等优点，广泛应用于各类分布式应用程序。

具体的，参见图2所示的服务管理系统结构示意图，假设，ZK Server集中管理器向上与主ZK Server、备ZK Server通信连接，ZK Server集中管理器向下与M个应用程序通信连接。当前主ZK Server正在向应用程序1提供服务。备ZK Server当前处于正常工作状态。

一种情况下，管理器监测到主ZK Server处于故障状态后，管理器进行服务器切换，将为应用程序1提供服务的服务器由主ZK Server切换至备ZK Server。可见，在此过程中应用程序1不需要做任何更改，分布式协调服务不中断，从而实现针对ZK Server的高可用，当管理器监测到主ZK Server故障恢复后，再将为应用程序1提供服务的服务器由备ZK Server切换至主ZK Server。

另一种情况下，管理器接收到主ZK Server的升级指令后，则管理器进行服务器切换，将为应用程序1提供服务的服务器由主ZK Server切换至备ZK Server，主ZK Server进行升级，当管理器监测到主ZK Server完成升级时，再将为应用程序1提供服务的服务器由备ZK Server切换至主ZK Server。可见，整个过程中应用程序1使用的分布式协调服务不会中断，服务器的转移、升级等操作对应用程序1无影响，实现了ZK Server的平滑升级。

与上述服务管理系统相对应，本申请实施例还提供了一种服务管理方法。

图3为本申请实施例提供的一种服务管理方法的流程示意图，该方法应用于服务管理系统中的管理器，其中，上述服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端，管理器通过预设的第一端口与服务器通信连接，管理器通过预设的第二端口与客户端通信连接。

具体的，上述服务管理方法包括：

S301：接收并存储服务器发送的自身的属性和状态。

具体的，上述服务器的属性可以包括：服务类型、IP地址、端口信息等等，本申请并不对此进行限定。

服务器向管理器发送自身的属性时，可以是在服务器启动之后向管理器发送自身的属性，还可以是服务器在检测到自身的属性发生变化之后向管理器发送自身的属性。

具体的，上述状态可以包括：Working(正常工作中)、Closed(已关闭)、NoService(故障中)、Updating(升级中)等等。

服务器向管理器发送自身的状态时，可以是在服务器启动之后向管理器发送自身的状态，还可以是服务器在检测到自身的状态发生变化之后向管理器发送自身的状态。

S302：接收客户端发送的服务申请。

S303：根据预设的服务申请响应策略、服务器的属性和/或服务器的状态，确定目标服务器。

具体的，上述预设的服务申请响应策略，可以包括以下策略中的至少一种：

根据服务申请中携带的客户端的信息、服务类型和服务器的状态，确定与客户端匹配的目标服务器；

根据服务器的负载状态、服务器的优先级，确定目标服务器；

根据服务器提供服务的时间，确定目标服务器，这种情况下，可以将接收服务申请的时间与各个服务器提供服务的时间进行匹配，根据匹配的服务时间对应的服务器，确定目标服务器。

S304：向客户端发送针对服务申请的申请响应，以使得客户端根据申请响应向目标服务器请求服务。

其中，申请响应中携带目标服务器的信息。

由前面的描述可知，管理器通过端口分别与服务器和客户端通信连接，具体的，可以理解为：上述管理器向上为服务器提供端口，也就是用于在管理器与服务器之间进行数据传输的端口，向下为客户端提供端口，也就是用于在管理器与客户端之间进行数据传输的端口。上述端口均可以理解为管理器上的软件端口。

在本申请的一种实现方式中，管理器接收并存储所述服务器的属性和状态时，可以通过预设的第一端口接收所述服务器的属性和状态，并存储所述服务器的属性和状态；

管理器接收所述服务申请时，可以通过预设的第二端口接收所述服务申请。

本申请的一种具体实现方式中，在管理器接收并存储服务器发送的自身的属性和状态之前，还可以包括：

管理器接收服务器发送的注册请求，并响应注册请求。

可选的，上述注册请求可以是服务器第一次启动或者是重启后向管理器发送的。上述注册请求中可以包含用户名、密码等信息，管理器接收到上述注册请求后，对其中携带的信息进行验证，若验证通过，则可以认为是注册成功。

在本申请的一种实现方式中，上述服务管理方法还可以包括：

接收客户端广播或组播的用于发现管理器的第一报文，并向客户端发送第一发现响应，以使得客户端接收到第一发现响应后与管理器建立通信连接；

接收服务器广播或组播的用于发现管理器的第二报文，并向服务器发送第二发现响应，以使得服务器接收到第二发现响应后与管理器建立通信连接。

在本申请的一种具体实现方式中，上述方法还可以包括：

管理器通过向服务器发送用于探测服务器是否在线的第一心跳信息，维护与所述服务器之间的连接；

管理器通过向客户端发送用于探测客户端是否在线的第二心跳信息，维护与所述客户端之间的连接。

由以上可见，上述各个实施例提供的方案中，服务器向管理器发送自身的属性和状态后，管理器接收并存储上述服务器的属性和状态，客户端向管理器发送服务申请，管理器根据预设的服务申请响应策略、上述服务器的属性和/或上述服务器的状态，确定目标服务器，并向客户端发送针对服务申请的申请响应，客户端接收到申请响应后，并向目标服务器请求服务。由于服务器会向管理器发送其自身的属性和状态，所以，管理器能够及时了解各个服务器的真实情况，这样管理器确定出的目标服务器为能够向客户端提供服务的服务器，进而能够使得客户端的服务请求能够得到及时响应。

实际应用中，处于正常工作状态的服务器由于各种原因出现故障，若出现故障的服务器当前正在向客户端提供服务，则可能会造成服务中断，鉴于此，在本申请的一种具体实现方式中，参见图4，提供了另一种服务管理方法的流程示意图，与前述实施例相比，本实施例中，上述服务管理方法还包括：

S305：监测服务器的状态，当监测到主服务器处于故障状态时，将提供服务的服务器由主服务器切换至备服务器。

通常情况下，主要由主服务器提供服务。

具体的，管理器监测服务器的状态时，可以通过向服务器发送用于探测服务器是否在线的第一心跳信息的方式监测。当然，管理器还可以通过判断预设时长内是否接收到服务器发送的信息的方式监测服务器的状态，例如，预设时长内接收到了服务器发送的信息，则可以认为该服务器处于正常工作状态，相反，若预设时长内没有接收到服务器发送的信息，则可以任务该服务器处于故障状态。

在本申请的一种可选实现方式中，管理器还可以监测主服务器的状态，当监测到主服务器的状态由故障状态切换回正常工作状态，则还可以将提供服务的服务器由备服务器切换回主服务器。

由以上可见，管理器监测到主服务器处于故障状态时，将主服务器切换至备服务器，这样即使主服务器出现故障，也不会带来向客户端所提供服务的中断，而且服务器切换操作是由管理器完成的，在客户端而言，完全感受不到服务器的切换，因此不会对客户端带来任何影响。

本领域内的技术人员可以理解的是，由于业务需要等原因可能会对各个服务器进行升级，但是若要升级的服务器当前正在为客户端提供服务，直接对该服务器进行升级的话，势必造成服务中断。鉴于此，在本申请的一种具体实现方式中，参见图5，提供了再一种服务管理方法的流程示意图，与前述实施例相比，本实施例中，上述服务管理方法还包括：

S306：接收到针对主服务器的升级指令时，将提供服务的服务器由主服务器切换至备服务器。

上述升级指令可以是运营维护人员告知管理器的，还可以是主服务器发送至管理器的，本申请并不对此进行限定。

可选的，上述服务管理方法还可以包括：

管理器在主服务器完成升级后，将主服务器切换回切备服务器。

管理器监测主服务器是否完成升级时，可以通过向主服务器发送用于探测该服务器是否在线的心跳信息的方式监测，还可以通过检测是否接收到该服务器发送的信息的方式监测，若接收到该服务器发送的信息，则认为主服务器完成了升级。

需要说明的是，本申请只是以此为例进行说明，实际应用中管理器监测主服务器是否完成升级的方式并不仅限于此。

由以上可见，管理器接收到主服务器的升级指令后，进行服务器切换，这样的话，在主服务器进行升级时，由备服务器为客户端提供服务，不会带来客户端所享受服务的中断，另外，从客户端的角度而言，由于服务器切换是由管理器完成的，且服务没有中断，所以客户端不会感受到服务器的切换。

与上述服务管理方法相对应，本申请实施例还提供了一种服务管理装置。

图6为本申请实施例提供的一种服务管理装置的结构示意图，该装置应用于服务管理系统中的管理器，其中，所述服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端；所述管理器通过预设的第一端口与所述服务器通信连接，所述管理器通过预设的第二端口与所述客户端通信连接；所述装置包括：

信息存储模块601，用于接收并存储所述服务器发送的自身的属性和状态；

申请接收模块602，用于接收所述客户端发送的服务申请；

服务器确定模块603，用于根据预设的服务申请响应策略、所述服务器的属性和/或所述服务器的状态，确定目标服务器；

响应发送模块604，用于向所述客户端发送针对所述服务申请的申请响应，以使得所述客户端根据所述申请响应向所述目标服务器请求服务，其中，所述申请响应中携带所述目标服务器的属性。

具体的，所述服务管理装置还可以包括：

请求响应模块，用于在所述信息存储模块接收并存储所述属性和状态之前，接收所述服务器发送的注册请求，并响应所述注册请求。

具体的，所述服务管理装置还可以包括：

服务器切换模块，用于监测所述服务器的状态，当监测到主服务器处于故障状态时，将提供服务的服务器由主服务器切换至备服务器；

所述服务器切换模块，还用于接收到所述主服务器的升级指令时，将提供服务的服务器由主服务器切换至所述备服务器。

具体的，所述服务器切换模块，还用于在所述主服务器故障恢复后，将提供服务的服务器由所述备服务器切换至所述主服务器；

所述服务器切换模块，还用于在所述主服务器完成升级后，将提供服务的服务器由所述备服务器切换至所述主服务器。

具体的，所述服务管理装置装置还可以包括：

报文接收模块，用于接收所述客户端广播或组播的用于发现管理器的第一报文，并向所述客户端发送第一发现响应，以使得所述客户端接收到所述第一发现响应后与所述管理器建立通信连接；

所述报文接收模块，还用于接收所述服务器广播或组播的用于发现管理器的第二报文，并向所述服务器发送第二发现响应，以使得所述服务器接收到所述第二发现响应后与所述管理器建立通信连接。

具体的，所述服务管理装置还可以包括：

连接维护模块，用于通过向所述服务器发送用于探测服务器是否在线的第一心跳信息，维护与所述服务器之间的连接；

所述连接维护模块，还用于通过向所述客户端发送用于探测客户端是否在线的第二心跳信息，维护与所述客户端之间的连接。

由以上可见，上述各个实施例提供的方案中，服务器向管理器发送自身的属性和状态后，管理器接收并存储上述服务器的属性和状态，客户端向管理器发送服务申请，管理器根据预设的服务申请响应策略、上述服务器的属性和/或上述服务器的状态，确定目标服务器，并向客户端发送针对服务申请的申请响应，客户端接收到申请响应后，并向目标服务器请求服务。由于服务器会向管理器发送其自身的属性和状态，所以，管理器能够及时了解各个服务器的真实情况，这样管理器确定出的目标服务器为能够向客户端提供服务的服务器，进而能够使得客户端的服务请求能够得到及时响应。

对于方法、装置实施例而言，由于其基本相似于系统实施例，所以描述的比较简单，相关之处参见方法实施例的部分说明即可。

需要说明的是，在本文中，诸如第一和第二等之类的关系术语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何这种实际的关系或者顺序。而且，术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含，从而使得包括一系列要素的过程、方法、物品或者设备不仅包括那些要素，而且还包括没有明确列出的其他要素，或者是还包括为这种过程、方法、物品或者设备所固有的要素。在没有更多限制的情况下，由语句“包括一个……”限定的要素，并不排除在包括所述要素的过程、方法、物品或者设备中还存在另外的相同要素。

本领域普通技术人员可以理解实现上述方法实施方式中的全部或部分步骤是可以通过程序来指令相关的硬件来完成，所述的程序可以存储于计算机可读取存储介质中，这里所称得的存储介质，如：ROM/RAM、磁碟、光盘等。

以上所述仅为本申请的较佳实施例而已，并非用于限定本申请的保护范围。凡在本申请的精神和原则之内所作的任何修改、等同替换、改进等，均包含在本申请的保护范围内。

Claims (12)

1.一种服务管理方法，其特征在于，应用于服务管理系统中的管理器，其中，所述服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端；所述管理器通过预设的第一端口与所述服务器通信连接，所述管理器通过预设的第二端口与所述客户端通信连接；所述方法包括：

接收并存储所述服务器发送的自身的属性和状态；

接收所述客户端发送的服务申请；

根据预设的服务申请响应策略、所述服务器的属性和/或所述服务器的状态，确定目标服务器；

向所述客户端发送针对所述服务申请的申请响应，以使得所述客户端根据所述申请响应向所述目标服务器请求服务，其中，所述申请响应中携带所述目标服务器的属性。

2.根据权利要求1所述的方法，其特征在于，在所述接收并存储所述服务器发送的自身的属性和状态之前，还包括：

接收所述服务器发送的注册请求，并响应所述注册请求。

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

监测所述服务器的状态，当监测到主服务器处于故障状态时，将提供服务的服务器由主服务器切换至备服务器；

接收到所述主服务器的升级指令时，将提供服务的服务器由主服务器切换至所述备服务器。

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

在所述主服务器故障恢复后，将提供服务的服务器由所述备服务器切换至所述主服务器；

在所述主服务器完成升级后，将提供服务的服务器由所述备服务器切换至所述主服务器。

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

接收所述客户端广播或组播的用于发现管理器的第一报文，并向所述客户端发送第一发现响应，以使得所述客户端接收到所述第一发现响应后与所述管理器建立通信连接；

接收所述服务器广播或组播的用于发现管理器的第二报文，并向所述服务器发送第二发现响应，以使得所述服务器接收到所述第二发现响应后与所述管理器建立通信连接。

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

通过向所述服务器发送用于探测服务器是否在线的第一心跳信息，维护与所述服务器之间的连接；

通过向所述客户端发送用于探测客户端是否在线的第二心跳信息，维护与所述客户端之间的连接。

7.一种服务管理装置，其特征在于，应用于服务管理系统中的管理器，其中，所述服务管理系统包括：一个管理器、至少两个服务器和至少一个客户端；所述管理器通过预设的第一端口与所述服务器通信连接，所述管理器通过预设的第二端口与所述客户端通信连接；所述装置包括：

信息存储模块，用于接收并存储所述服务器发送的自身的属性和状态；

申请接收模块，用于接收所述客户端发送的服务申请；

服务器确定模块，用于根据预设的服务申请响应策略、所述服务器的属性和/或所述服务器的状态，确定目标服务器；

响应发送模块，用于向所述客户端发送针对所述服务申请的申请响应，以使得所述客户端根据所述申请响应向所述目标服务器请求服务，其中，所述申请响应中携带所述目标服务器的属性。

8.根据权利要求7所述的装置，其特征在于，所述装置还包括：

请求响应模块，用于在所述信息存储模块接收并存储所述属性和状态之前，接收所述服务器发送的注册请求，并响应所述注册请求。

9.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：

服务器切换模块，用于监测所述服务器的状态，当监测到主服务器处于故障状态时，将提供服务的服务器由主服务器切换至备服务器；

所述服务器切换模块，还用于接收到所述主服务器的升级指令时，将提供服务的服务器由主服务器切换至所述备服务器。

10.根据权利要求9所述的装置，其特征在于，

所述服务器切换模块，还用于在所述主服务器故障恢复后，将提供服务的服务器由所述备服务器切换至所述主服务器；

所述服务器切换模块，还用于在所述主服务器完成升级后，将提供服务的服务器由所述备服务器切换至所述主服务器。

11.根据权利要求7或8所述的装置，其特征在于，所述装置还包括：

报文接收模块，用于接收所述客户端广播或组播的用于发现管理器的第一报文，并向所述客户端发送第一发现响应，以使得所述客户端接收到所述第一发现响应后与所述管理器建立通信连接；

所述报文接收模块，还用于接收所述服务器广播或组播的用于发现管理器的第二报文，并向所述服务器发送第二发现响应，以使得所述服务器接收到所述第二发现响应后与所述管理器建立通信连接。

12.根据权利要求11所述的装置，其特征在于，所述装置还包括：

连接维护模块，用于通过向所述服务器发送用于探测服务器是否在线的第一心跳信息，维护与所述服务器之间的连接；

所述连接维护模块，还用于通过向所述客户端发送用于探测客户端是否在线的第二心跳信息，维护与所述客户端之间的连接。