CN105208047A - 分布式系统服务器上下线方法及服务器 - Google Patents

Abstract

本申请涉及一种分布式系统服务器上下线方法及服务器，所述下线方法包括：应用程序的服务器接收到所述应用程序的控制端发送的下线指令时，所述服务器运行下线的运维脚本；所述服务器向分布式系统的配置中心发送第一通知消息，所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除；所述服务器向正在调用所述服务器的客户端发送第二通知消息，所述第二通知消息用于通知所述客户端停止发送请求；经过预设的第一时间后，所述服务器终止所述服务器的进程，以使所述服务器下线。本申请提供的方法及装置，可以有效避免在应用程序的服务器上下线时，服务器的客户端出现调用失败的问题，从而使分布式系统具有较好的稳定性。

Description

分布式系统服务器上下线方法及服务器

技术领域

本申请涉及计算机网络技术领域，尤其涉及一种分布式系统服务器上下线方法及服务器。

背景技术

随着电子商务网站(例如，淘宝网等)的用户数量和网站流量的不断增长，应用系统的数量和复杂程度也急剧增加。诸多前台系统都需要使用一些公共的业务逻辑，这些业务逻辑通常具有一些共性，比如，获取用户信息或查询宝贝详情等。如果将这些业务逻辑在各个系统内部都实现一遍，则大大增加了开发成本和后期维护成本,按照业务领域模型进行垂直拆分实现SOA架构是势在必行。面向服务的架构(ServiceOrientedArchitecture，SOA)是一个组件模型，它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以使用一种统一和通用的方式进行交互。面向服务架构可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。

远程调用框架(HighSpeedFramework，HSF)是淘宝网的分布式服务框架，是淘网宝服务化架构中的基础组件,是基于传输控制协议(TransmissionControlProtocol，TCP)长连接的远程调用框架，可以帮助各个应用系统将那些相似的业务逻辑抽离出来，并单独部署。前台系统在需要调用这些业务逻辑时，只需要通过服务框架远程调用即可，大大节约了前端系统的开发成本，也提高了系统的可维护性和可扩展性。

随着分布式服务框架规模的日益庞大，各个应用系统之间的依赖关系错综复杂，在分布式服务框架中牵一发动全身，容易出现因为某个应用系统提供的服务下线而导致客户端调用失败的现象，造成短时间内的数据有较大波动，影响分布式系统的稳定性。例如，在现有的分布式服务框架中，当遇到某个应用系统(例如，淘宝的某个交易核心系统)重启时，关闭阶段会导致周边应用系统大量调用失败，以至于交易有明显的波动。因为应用系统的服务端还有许多在处理而没有返回响应到客户端；另外有一部分请求在网络发送途中或者客户端准备发送中，这些调用中的请求基本都会失败。在应用系统的服务器在启动阶段，服务还没有完全初始化成功就绪，就有请求进来了，这时候的处理结果就是失败。最终，应用系统的服务器重启或上线就会出现调用失败的问题，对用户造成影响，导致分布式系统的稳定性差。

发明内容

本申请的目的是，提供一种分布式系统服务器上下线方法及服务器，可以有效避免在应用程序的服务器上下线时，服务器的客户端出现调用失败的问题，从而使分布式系统具有较好的稳定性。

本申请提供了一种分布式系统服务器下线方法，所述方法包括：

应用程序的服务器接收到所述应用程序的控制端发送的下线指令时，所述服务器运行下线的运维脚本；

所述服务器向分布式系统的配置中心发送第一通知消息，所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除，其中，所述地址服务簿用于存储和维护所述分布式系统中所有的可用服务器的地址信息；

所述服务器向正在调用所述服务器的客户端发送第二通知消息，所述第二通知消息用于通知所述客户端停止发送请求；

经过预设的第一时间后，所述服务器终止所述服务器的进程，以使所述服务器下线。

又一方面，本申请还提供了一种分布式系统服务器上线方法，所述方法包括：

应用程序的服务器上线时进行服务器初始化，判断是否初始化成功，如果是，则所述服务器将其地址信息注册到分布式系统配置中心的地址服务簿，提供所述应用程序相应的服务。

又一方面，本申请还提供了一种分布式系统服务器，所述服务器包括：

接收单元，用于接收应用程序的控制端发送的下线指令；

第一处理单元，用于当所述接收单元接收到所述下线指令时，运行下线的运维脚本；

第一发送单元，用于在所述第一处理单元运行所述下线的运维脚本之后，向分布式系统的配置中心发送第一通知消息，所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除，其中，所述地址服务簿用于存储和维护所述分布式系统中所有的可用服务器的地址信息；

第二发送单元，用于在所述第一处理单元运行所述下线的运维脚本之后，向正在调用所述服务器的客户端发送第二通知消息，所述第二通知消息用于通知所述客户端停止发送请求；

第二处理单元，用于在所述第一发送单元和第二发送单元发送完对应的通知消息之后，经过预设的第一时间后，终止所述服务器的进程，以使所述服务器下线。

又一方面，本申请还提供了一种分布式系统服务器，所述服务器包括：初始化单元、判断单元和注册单元；

所述初始化单元，用于当所述服务器上线时，进行初始化；

所述判断单元，用于判断所述初始化单元是否初始化成功，如果是，则进入注册单元；

所述注册单元，用于将所述服务器的地址信息注册到分布式系统配置中心的地址服务簿，提供所述应用程序相应的服务。

本申请实施例提供的分布式系统服务器上下线方法及服务器，可以有效避免在应用程序的服务器上下线时，服务器的客户端出现调用失败的问题，从而使分布式系统具有较好的稳定性，保证客户端调用的成功率，避免调用失败带来的负面影响。

附图说明

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

图1为本申请实施例提供的一种分布式服务框架的示意图；

图2为本申请实施例一提供的一种分布式系统服务器下线方法流程图；

图3为本申请实施例二提供的一种分布式系统服务器下线方法的具体处理流程图；

图4为本申请实施例三提供的一种分布式系统服务器上线方法流程图；

图5为本申请实施例四提供的一种分布式系统服务器的结构示意图；

图6为本申请实施例五提供的一种分布式系统服务器的结构示意图；

图7为本申请实施例五提供的一种分布式系统服务器的结构示意图。

具体实施方式

为使得本申请的发明目的、特征、优点能够更加的明显和易懂，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行描述，显然，所描述的实施例仅仅是本申请一部分实施例，而非全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本申请实施例提供的分布式系统服务器上下线方法及装置，适用于面向服务的架构SOA的分布式系统、基于远程调用的服务框架HSF的分布式系统等等。在本申请实施例中以HSF服务框架为例进行说明，但并不以此作为限制。

HSF服务框架从分布式应用层面以及统一的发布/调用方式层面为业务系统提供支持，从而可以很容易地开发分布式应用并提供和使用公用功能模块，而不用考虑分布式领域中的各种细节技术，例如，远程通讯、性能损耗、调用的透明化、同步/异步调用方式的实现等问题。

在一个HSF服务框架中，集成了大量的应用系统，每一个应用系统对应的应用程序在大量的服务器上运行，即对应了大量的应用系统服务器(或者服务)，每个服务器上可以提供至少一种应用系统的服务。这里的服务器是虚拟的服务器，以软件的形式存在于网络资源中，能提供或支持特定功能的服务或操作。

以淘宝网的HSF服务框架为例，应用系统可以包括前端应用系统和后端服务系统，前端应用系统，例如搜索系统、商品详情系统、商铺系统等等，对应于搜索系统服务器、商品详情服务器、商品系统服务器等等；后端服务系统包括商品中心、用户中心、交易中心等等，对应于商品中心服务器、用户中心服务器、交易中心服务器等等。HSF是基于配置中心(Configserver)来管理和发现服务地址信息，在HSF架构中，所有应用系统服务器都需要在系统的配置中心的地址服务簿上注册，统一管理服务器的地址信息，以便需要使用该些服务的客户端通过地址服务簿调用所需要的服务器。其中，地址服务簿由地址服务器(ConfigServer)管理和维护。

客户端发起远程调用时，从分布式系统的配置中心的地址服务簿上，获得所需要的服务的服务器的地址信息，再发起调用请求。例如，用户在使用搜索系统在搜索商品时，则需要商品详情系统或商品中心等等应用系统，此时，商品详情系统或商品中心则为服务端，搜索系统为客户端，客户端调用服务端的服务，发起远程调用时，从HSF的配置中心的地址服务簿上，获得提供商品详情系统或商品中心的服务器的地址信息，发起调用请求即可。

图1是本申请实施例提供的一种分布式服务框架的示意图，如图1所示，该HSF服务框架包括配置中心101、服务器102以及客户端103。配置中心101可以是注册中心，服务器102可以是服务提供者，客户端103可以是服务消费者。服务器102在服务可用的前提下，将地址信息注册到配置中心101的地址服务簿。例如，服务器102可以通知配置中心101“IP地址为192.168.1.2的机器提供了A服务”。客户端103启动时，会接收到配置中心101的相关服务，获取服务地址，例如，“A服务地址：192.168.1.2，192.168.1.3”等，客户端103再通过一定的负载均衡策略调用服务，进而再向选择调用的服务器102发起远程调用。

实施例一

图2是本实施例提供的分布式系统服务器下线方法流程图，如图2所示，本申请的分布式系统服务器下线方法包括：

S201、应用程序的服务器接收到所述应用程序的控制端发送的下线指令时，所述服务器运行下线的运维脚本。

当一个应用系统需要重启，例如，需要更新或增加新功能或者升级或者扩容或者应用系统新上线时，则会出现分布式系统服务器上下线的情形。

运维系统对需要更新的应用系统进行分批关闭处理(即关闭应用程序对应的服务器)。运维系统具有人机操作界面，运维人员可以通过人机操作界面对HSF框架的应用系统远程管理，在需要重启某个应用系统时，通过运维系统发送重启命令给应用系统对应的服务器，关闭对应的应用程序。这样，服务器即可接收到应用程序的控制端发送的下线指令。

对于一个分布于大量服务器的应用系统，运维系统一般采用分批的方式进行处理。例如，“商品中心”等应用系统一般都有2000～3000台服务器，那么，对这2000～3000台服务器可以分成10批进行关闭处理。

由于HSF服务架构采用的是JAVA，因而，在HSF服务架构中，应用程序的控制端一般为JAVA虚拟机(JVM)，JVM可以控制和装载所述应用程序。

服务器接收到JVM发送的下线指令时，即运行下线的运维脚本，准备下线。

S202、所述服务器向分布式系统的配置中心发送第一通知消息。

所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除。

其中，所述地址服务簿用于存储和维护所述分布式系统中所有的可用服务器的地址信息。

服务器的地址信息包括以下至少一种：所述服务器的IP地址、端口信息、提供的服务信息。

在注册时，服务器会向配置中心发送消息，通知配置中心提供了哪些服务，例如，服务器A1可以通知“IP地址为192.168.1.2的机器提供了A服务”，服务器A2也可以通知“IP地址为192.168.1.3的机器提供了A服务”，那么，配置中心在收到这些消息时，则会在地址服务簿上记录各个服务器的IP地址、端口信息以及提供了哪些服务等信息。

当客户端需要使用到A服务时，发起远程调用，可以从地址服务簿上获得提供A服务的服务器信息，例如，可以获得“A服务地址有：192.168.1.2，192.168.1.3等等”这样的信息，然后根据相应的规则从A服务地址中选择一台服务器发起调用。

当服务器重启需要下线时，现有的系统中该服务器并不会通知配置中心更新地址服务簿。这样，已经下线的服务器的地址信息还保存在该地址服务簿上，会导致客户端在调用地址服务簿上的某个服务时，可能会选择到已经下线的服务器，出现调用失败的状况。在本申请实施例中，当服务器重启下线时，通过第一通知消息通知配置中心更新地址服务簿，从地址服务簿上删除这个需要下线的服务器的地址信息，这样，客户端就发现不了这些已经下线的服务器，在根据该地址服务簿进行调用时，也不会选择到这些已经下线的服务器。

S203、所述服务器向正在调用所述服务器的客户端发送第二通知消息。

所述第二通知消息用于通知所述客户端停止发送请求。

在服务器需要重启下线时，可能会存在一些客户端还正在调用该服务器。

对于正在调用服务器的客户端，现有的系统中当服务器重启需要下线时，该服务器也不会通知这些客户端停止调用该服务器，这样，正在调用该服务器的客户端仍会发送请求到该服务器，导致调用失败的问题。在本申请实施例中，当服务器重启下线时，通过第二通知消息通知正在调用所述服务器的客户端停止发送请求。

服务器在准备下线时，先确认是否有正在调用该服务器的客户端，如果有，则向该些客户端发送第二通知消息，通知该些客户端停止向该服务器发送请求。

S204、经过预设的第一时间后，所述服务器终止所述服务器的进程，以使所述服务器下线。

在S202和S203发送完通知消息之后等待一个预设的第一时间，终止服务器的进程，即kill(终结)服务进程。

其中，预设的第一时间可以根据服务器实际的处理速度的经验值来确定，例如30秒等，用以保证配置中心和客户端有足够的时间去处理对应的通知消息。

实施例二

图3为本申请实施例提供的一种分布式系统服务器下线方法的具体处理流程图，如图3所示，该分布式系统服务器下线方法包括：

S301、服务器接收到所述应用程序的控制端发送的下线指令，运行下线的运维脚本，准备下线。

S302、服务器判断下线的运维脚本是否调用离线控制命令，如果是，则进入S304，否则，进入S303。

运维人员可以修改下线的运维脚本，在该运维脚本中增加调用离线控制命令，如果下线的运维脚本中有调用离线控制命令，则可以直接执行S304和S305。

如果下线的运维脚本是原有的运维脚本，则需要通过S303来捕获运维系统发送关机事件后再执行S304和S305。

运维系统发送的关机事件可以是运维人员通过运维系统输入的shutdown等命令，也可以是运维系统在确定控制端发送下线指令之后的一段预设的时间之后自动触发的shutdown命令。

S303、服务器等待接收运维系统发送关机事件，当所述服务器接收到所述关机事件时，进入S304。

S304、服务器向分布式系统的配置中心发送第一通知消息。

第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除。

S305、服务器向正在调用所述服务器的客户端发送第二通知消息。

所述第二通知消息用于通知所述客户端停止发送请求。

步骤S304和S305与图2中的步骤S202和S203对应相同，于此不再赘述。

S306、服务器在等待预设的第一时间(例如，30秒)后，终止所述服务器的进程，以使所述服务器下线。

S307、服务器进入睡眠状态，并经过预设的第二时间(例如，10秒)后，所述服务器关闭服务。

在S306终止服务器的进程后，服务器即进入睡眠状态，再等待10秒之后真正关闭服务器。

这样，本申请实施例提供的分布式系统服务器下线方法，通过发送通知消息，通知配置中心删除对应服务器的地址信息，以及，通知客户端停止发送请求，可以在服务器下线时，有效避免客户端调用服务失败的问题，使系统更稳定。

实施例三

图4是本申请实施例提供的分布式系统服务器上线方法流程图，如图4所示，所述上线方法包括：

S401、应用程序的服务器上线时，进行服务器初始化。

S402、判断是否初始化成功，如果是，则进入S403，否则进入S405。

在S401之后，服务器需要判断是否初始化成功。服务器需要初始化的项目可以包括：加载服务器缓存中的数据，确认需要调用的服务是否处于可用状态，以及判断是否启动接收web服务请求的功能等。

不同应用程序的服务区需要初始化的项目可以不同，例如，有些应用程序可能需要加载数据库或者需要调用其他服务，有些可能不需要。

相应的，服务器判断是否初始化成功，则是判断所需要初始化的项目是否完成。如果服务器需要初始化的项目包括：加载服务器缓存中的数据，确认需要调用的服务是否处于可用状态，以及判断是否启动接收web服务请求的功能。那么，服务器需要判断所述服务器的缓存中的数据是否加载完成，所述服务器所调用的服务是否处于可用状态等是否完成，以及，判断是否启动接收web服务请求的功能。当服务器的缓存中的数据加载完成且调用的服务处于可用状态且已经启动接收web服务请求的功能，则可以认为服务器初始化成功。

可选的，HSF服务框架的所有服务器在初始化阶段都不注册到地址服务簿中，而是等待初始化成功后，再注册到地址服务簿上。

或者，应用程序可以提供配置参数，该配置参数用于指示允许所述服务器启动时，不注册到地址服务薄，并提供支持基于http协议的远程控制支持，以让运维脚本根据业务本身场景决定何时注册到地址服务薄。不同应用程序的服务需要初始化的项目可以不同，那么，应用程序的服务器可以根据本身具体需要初始化的项目的不同来决定何时注册到地址服务簿。

服务器启动接收网页服务请求的功能，是为了接收所述服务器的客户端发送的网页服务请求。

由于HSF服务框架是基于远程调用的服务框架，客户端在使用HSF服务框架调用服务时，需要通过web服务器发送请求，因而，HSF服务框架中的服务器一般都需要启动web服务器，以启动接收网页服务请求的功能，接收所述服务器的客户端发送的网页服务请求。

具体地，在判断是否启动接收web服务请求的功能时，可以通过回声检测(echo)服务请求来判断。服务器启动接收回声检测(echo)服务请求的功能，以接收所述服务器的本地客户端发送的基于http服务请求来判断服务是否准备就绪。

S403、所述服务器将其地址信息注册到分布式系统配置中心的地址服务簿。

在服务器初始化成功之后，服务器向配置中心注册自己的地址信息，添加到地址服务簿中。

S404、服务器将状态设置为成功(OK)。

在将地址信息注册到地址服务簿之后，服务器还会将状态设置为OK，表示该服务器初始化成功完成，服务器可以提供所述应用程序相应的服务。

S405、服务器将状态设置为失败(failure)。

当状态设置为失败时，表示该服务器初始化失败，不能提供相应的服务，不能注册到地址服务簿上，不能启动接收网页服务请求的功能，无法为客户端提供相应的服务。

HSF服务框架的所有服务器在初始化阶段都不注册到地址服务簿中，而是等待服务容器把所有的服务器初始化成功后，收到成功事件后再注册到地址服务簿上，并设定状态(status)为OK或者true，于此同时，基于远程端口来提供status命令。

可选的，在HSF服务架构中，可以设置为默认的服务器是不需要在服务地址簿上注册的，只有在运维系统(可以有运维人员参与)根据检查脚本测试具体的业务逻辑后，才进行注册。运维系统在启动完应用程序的服务器后，在启动web服务器之前，还可以通过基于远程命令来检测服务器的状态是否OK，如果是，再启动web服务器，即启动接收网页服务请求的功能，以提供web服务的功能，接收客户端的服务请求。

本申请实施例提供的分布式系统服务器上线方法，在服务器初始化成功后再将服务器地址注册到地址服务簿中，可以在服务器上线时，有效避免客户端调用服务失败的问题，使系统更稳定。

以上是对本申请实施例所提供的分布式系统服务器上下线方法进行的详细描述，下面对本申请提供的分布式系统服务器进行详细描述。

实施例四

图5是本实施例提供的分布式系统服务器的示意图，如图5所示，本申请的服务器包括：接收单元501、第一处理单元502、第一发送单元503、第二发送单元504和第二处理单元505。

接收单元501用于接收应用程序的控制端发送的下线指令。

当一个应用系统需要重启，例如，需要更新或增加新功能或者升级或者扩容或者应用系统新上线时，则会出现分布式系统服务器上下线的情形。

运维系统对需要更新的应用系统进行分批关闭处理(即关闭应用程序对应的服务器)。运维系统具有人机操作界面，运维人员可以通过人机操作界面对HSF框架的应用系统远程管理，在需要重启某个应用系统时，通过运维系统发送重启命令给应用系统对应的服务器，关闭对应的应用程序。这样，接收单元即可接收到应用程序的控制端发送的下线指令。

在HSF服务架构中，应用程序的控制端为控制和装载所述应用程序的JAVA虚拟机。

第一处理单元502用于当接收单元501接收到所述下线指令时，运行下线的运维脚本。

第一发送单元503用于在所述第一处理单元运行所述下线的运维脚本之后，向分布式系统的配置中心发送第一通知消息。

所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除。服务器的地址信息包括以下至少一种：所述服务器的IP地址、端口信息、提供的服务信息。

其中，所述地址服务簿用于存储和维护所述分布式系统中所有的可用服务器的地址信息。

第二发送单元504在第一处理单元502运行所述下线的运维脚本之后，向正在调用所述服务器的客户端发送第二通知消息。

所述第二通知消息用于通知所述客户端停止发送请求。

在服务器需要重启下线时，可能会存在一些客户端还正在调用该服务器。第二发送单元504向该些客户端发送第二通知消息，通知该些客户端停止向该服务器发送请求。

第二处理单元505用于在第一发送单元503和第二发送单元504发送完对应的通知消息之后，经过预设的第一时间后，终止所述服务器的进程，以使所述服务器下线。

其中，预设的第一时间可以根据服务器实际的处理速度的经验值来确定，用以保证配置中心和客户端有足够的时间去处理对应的通知消息。

实施例五

图6是本实施例提供的分布式系统服务器的示意图，如图6所示，所述服务器还包括：判断单元506和第三处理单元507。

判断单元506用于在第一处理单元502运行下线的运维脚本之后，判断所述下线的运维脚本是否调用离线控制命令，如果是，则通过第一发送单元503向所述分布式系统的配置中心发送第一通知消息。如果否，则利用接收单元501等待接收运维系统发送关机事件，当接收单元501接收到所述关机事件时，通过第一发送单元503向所述分布式系统的配置中心发送第一通知消息。

第三处理单元507用于在第二处理单元505之后，使所述服务器进入睡眠状态，并经过预设的第二时间后，所述服务器关闭服务。

在第二处理单元505终止服务器的进程后，服务器即进入睡眠状态，第三处理单元507再等待预设的第二时间，例如10秒之后，真正关闭服务器。

本申请实施例提供的分布式系统服务器，通过发送通知消息，通知配置中心删除对应服务器的地址信息，以及，通知客户端停止发送请求，可以在服务器下线时，有效避免客户端调用服务失败的问题，使系统更稳定。

实施例六

图7是本申请实施例提供的分布式系统服务器的示意图，如图7所示，所述服务器还包括：初始化单元601、判断单元602和注册单元603。

初始化单元601用于当所述服务器上线时，进行初始化。

初始化单元601需要初始化的项目可以包括：加载服务器缓存中的数据，确认需要调用的服务是否处于可用状态，以及判断是否启动接收web服务请求的功能等。

判断单元602用于判断初始化单元601是否初始化成功，如果是，则进入注册单元603。

不同应用程序的服务区需要初始化的项目可以不同，例如，有些应用程序可能需要加载数据库或者需要调用其他服务，有些可能不需要。

相应的，判断单元602用于判断初始化单元601是否初始化成功，则是判断初始化单元601所需要初始化的项目是否完成。如果初始化单元601需要初始化的项目包括：加载服务器缓存中的数据，确认需要调用的服务是否处于可用状态，以及判断是否启动接收web服务请求的功能。那么，判断单元602具体用于判断所述服务器的缓存中的数据是否加载完成，所述服务器所调用的服务是否处于可用状态，以及，判断是否启动接收web服务请求的功能。当判断单元602判断到服务器的缓存中的数据加载完成且调用的服务处于可用状态且已经启动接收web服务请求的功能，则可以认为服务器初始化成功。

可选的，HSF服务框架的所有服务器在初始化阶段都不注册到地址服务簿中，而是等待初始化成功后，再注册到地址服务簿上。

或者，应用程序可以提供配置参数，该配置参数用于指示允许所述服务器启动时不注册到地址服务薄，并提供支持基于http协议的远程控制支持，以让运维脚本根据业务本身场景决定何时注册到地址服务薄。不同应用程序的服务区需要初始化的项目可以不同，那么，应用程序的服务器可以根据本身具体需要初始化的项目的不同来决定何时注册到地址服务簿。

服务器启动接收网页服务请求的功能，是为了接收所述服务器的客户端发送的网页服务请求。

由于HSF服务框架是基于远程调用的服务框架，客户端在使用HSF服务框架调用服务时，需要通过web服务器发送请求，因而，HSF服务框架中的服务器一般都需要启动web服务器，以启动接收网页服务请求的功能，接收所述服务器的客户端发送的网页服务请求。

具体地，判断单元602在判断是否启动接收web服务请求的功能时，可以通过回声检测(echo)服务请求来判断。服务器启动接收回声检测(echo)服务请求的功能，以接收所述服务器的本地客户端发送的基于http服务请求来判断服务是否准备就绪。

注册单元603用于将所述服务器的地址信息注册到分布式系统配置中心的地址服务簿。

注册单元603在服务器初始化成功之后，向配置中心注册自己的地址信息，添加到地址服务簿中。

可选的，所述服务器还包括：状态设置单元604，该状态设置单元604用于设置服务器的状态。

如果判断单元602判断到服务器初始化成功，则在注册单元603将地址信息注册到地址服务簿之后，状态设置单元604将服务器的状态设置为OK，表示该服务器初始化成功完成，服务器可以提供所述应用程序相应的服务。

如果判断单元602判断到服务器初始化失败，则无法为客户端提供相应的服务。状态设置单元604将服务器的状态设置为失败(failure)。

本申请实施例提供的分布式系统服务器上下线方法及服务器，可以有效避免在应用程序的服务器上下线时，服务器的客户端出现调用失败的问题，从而使分布式系统具有较好的稳定性，保证客户端调用的成功率，避免调用失败带来的负面影响。

专业人员应该还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(RAM)、内存、只读存储器(ROM)、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上所述的具体实施方式，对本申请的目的、技术方案和有益效果进行了进一步详细说明，所应理解的是，以上所述仅为本申请的具体实施方式而已，并不用于限定本申请的保护范围，凡在本申请的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (12)

1.一种分布式系统服务器下线方法，其特征在于，所述方法包括：

应用程序的服务器接收到所述应用程序的控制端发送的下线指令时，所述服务器运行下线的运维脚本；

所述服务器向分布式系统的配置中心发送第一通知消息，所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除，其中，所述地址服务簿用于存储和维护所述分布式系统中所有的可用服务器的地址信息；

所述服务器向正在调用所述服务器的客户端发送第二通知消息，所述第二通知消息用于通知所述客户端停止发送请求；

经过预设的第一时间后，所述服务器终止所述服务器的进程，以使所述服务器下线。

2.根据权利要求1所述的方法，其特征在于，在所述服务器运行下线的运维脚本之后，还包括：

判断所述下线的运维脚本是否调用离线控制命令，如果是，则所述服务器向所述分布式系统的配置中心发送第一通知消息；

否则，所述服务器等待接收运维系统发送关机事件，当所述服务器接收到所述关机事件时，向所述分布式系统的配置中心发送第一通知消息。

3.根据权利要求1所述的方法，其特征在于，在所述服务器终止所述服务器的进程之后，还包括：

所述服务器进入睡眠状态，并经过预设的第二时间后，所述服务器关闭服务。

4.根据权利要求1所述的方法，其特征在于，所述服务器的地址信息包括以下至少一种：所述服务器的IP地址、端口信息、提供的服务信息。

5.一种分布式系统服务器上线方法，其特征在于，所述方法包括：

应用程序的服务器上线时进行服务器初始化，判断是否初始化成功，如果是，则所述服务器将其地址信息注册到分布式系统配置中心的地址服务簿，提供所述应用程序相应的服务。

6.根据权利要求5所述的方法，其特征在于，所述判断是否初始化成功，具体包括：

判断所述服务器的缓存中的数据是否加载完成；

判断所述服务器所调用的服务是否处于可用状态；

或者，判断是否启动接收web服务请求的功能。

7.一种分布式系统服务器，其特征在于，所述服务器包括：

接收单元，用于接收应用程序的控制端发送的下线指令；

第一处理单元，用于当所述接收单元接收到所述下线指令时，运行下线的运维脚本；

第一发送单元，用于在所述第一处理单元运行所述下线的运维脚本之后，向分布式系统的配置中心发送第一通知消息，所述第一通知消息用于通知所述配置中心将所述服务器的地址信息从地址服务簿上删除，其中，所述地址服务簿用于存储和维护所述分布式系统中所有的可用服务器的地址信息；

第二发送单元，用于在所述第一处理单元运行所述下线的运维脚本之后，向正在调用所述服务器的客户端发送第二通知消息，所述第二通知消息用于通知所述客户端停止发送请求；

第二处理单元，用于在所述第一发送单元和第二发送单元发送完对应的通知消息之后，经过预设的第一时间后，终止所述服务器的进程，以使所述服务器下线。

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

判断单元，用于在所述第一处理单元运行下线的运维脚本之后，判断所述下线的运维脚本是否调用离线控制命令，如果是，则通过所述第一发送单元向所述分布式系统的配置中心发送第一通知消息；如果否，则利用所述接收单元等待接收运维系统发送关机事件，当所述接收单元接收到所述关机事件时，通过所述第一发送单元向所述分布式系统的配置中心发送第一通知消息。

9.根据权利要求7所述的服务器，其特征在于，所述服务器还包括：第三处理单元，用于在所述第二处理单元之后，使所述服务器进入睡眠状态，并经过预设的第二时间后，所述服务器关闭服务。

10.根据权利要求7所述的服务器，其特征在于，所述服务器的地址信息包括以下至少一种：所述服务器的IP地址、端口信息、提供的服务信息。

11.一种分布式系统服务器，其特征在于，所述服务器包括：初始化单元、判断单元和注册单元；

所述初始化单元，用于当所述服务器上线时，进行初始化；

所述判断单元，用于判断所述初始化单元是否初始化成功，如果是，则进入注册单元；

所述注册单元，用于将所述服务器的地址信息注册到分布式系统配置中心的地址服务簿，提供所述应用程序相应的服务。

12.根据权利要求11所述的服务器，其特征在于，所述判断单元具体用于判断所述服务器的缓存中的数据是否加载完成，和/或，判断所述服务器所调用的服务是否处于可用状态，和/或，判断是否启动接收web服务请求的功能。