服务器扩缩容方法、服务器、系统及存储介质

技术领域

本申请属于数据处理领域，尤其涉及一种服务器扩缩容方法、服务器、系统及存储介质。

背景技术

在用户使用某种网络服务的情况下，分流服务器会将用户的访问请求分流至对应的应用服务器，由应用服务器提供相应的服务。服务网络架构发生改变的情况下，对应会出现应用服务器的增加或减少，即进行服务器的扩容或缩容。

现阶段，应用服务器扩容或缩容需要专业工作人员对分流服务器进行手工配置修改。但专业人员人工的介入使得服务器扩容或缩容的流程较为繁琐，效率较低。

发明内容

本申请实施例提供一种服务器扩缩容方法、服务器、系统及存储介质，能够提高服务器扩缩容的效率。

第一方面，本申请实施例提供一种服务器扩缩容方法，应用于注册中心，方法包括：接收应用服务器触发发送的更新消息，更新消息用于表征应用服务器上线或下线；响应于更新消息，在注册中心添加或删除应用服务器对应的节点；向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息，第一通知消息用于表征应用服务器上线或下线。

第二方面，本申请实施例提供一种服务器扩缩容方法，应用于分流服务器，方法包括：接收注册中心发送的第一通知消息，第一通知消息是注册中心基于应用服务器触发发送的更新消息生成的，用于表征应用服务器上线或下线，分流服务器与注册中心中应用服务器对应的节点具有订阅关系；响应于第一通知消息，在分流服务器增添或删除应用服务器的通信信息。

第三方面，本申请实施例提供一种注册中心服务器，包括：接收模块，用于接收应用服务器触发发送的更新消息，更新消息用于表征应用服务器上线或下线；节点管理模块，用于响应于更新消息，在注册中心添加或删除应用服务器对应的节点；发送模块，用于向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息，第一通知消息用于表征应用服务器上线或下线。

第四方面，本申请实施例提供一种分流服务器，包括：接收模块，用于接收注册中心发送的第一通知消息，第一通知消息是注册中心基于应用服务器触发发送的更新消息生成的，用于表征应用服务器上线或下线，分流服务器与注册中心中应用服务器对应的节点具有订阅关系；处理模块，用于响应于第一通知消息，在分流服务器增添或删除应用服务器的通信信息。

第五方面，本申请实施例提供一种注册中心服务器，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第一方面的服务器扩缩容方法。

第六方面，本申请实施例提供一种分流服务器，包括：处理器以及存储有计算机程序指令的存储器；处理器执行计算机程序指令时实现第二方面的服务器扩缩容方法。

第七方面，本申请实施例提供一种服务器扩缩容系统，包括第五方面的注册中心服务器和第六方面的分流服务器。

第八方面，本申请实施例提供一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序指令，计算机程序指令被处理器执行时实现第一方面的服务器扩缩容方法或第二方面的服务器扩缩容方法。

本申请提供一种服务器扩缩容方法、服务器、系统及存储介质，通过应用服务器自动触发发送的更新消息，通知注册中心应用服务器上线或下线。注册中心可根据应用服务器上线或下线，在注册中心添加或删除该应用服务器对应的节点。注册中心通过向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息，以使分流服务器得知该应用服务器上线或下线，从而使得分流服务器可对与自身具有订阅关系的节点对应的应用服务器即在线的应用服务器进行分流，实现了应用服务器的自动扩缩容，减少甚至避免了人工介入服务器扩容或缩容的流程及时间，从而简化服务器扩缩容流程，提高服务器扩缩容的效率。

附图说明

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

图1为本申请实施例提供的服务器扩缩容方法的应用场景的一示例的示意图；

图2为本申请第一方面提供的服务器扩缩容方法的一实施例的流程图；

图3为本申请第一方面提供的服务器扩缩容方法的另一实施例的流程图；

图4为本申请第二方面提供的服务器扩缩容方法的一实施例的流程图；

图5为本申请第二方面提供的服务器扩缩容方法的另一实施例的流程图；

图6为本申请实施例提供的服务器扩容流程的一示例的流程图；

图7为本申请实施例提供的服务器缩容流程的一示例的流程图；

图8为本申请实施例提供的服务器缩容流程的另一示例的流程图；

图9为本申请第三方面提供的注册中心服务器的一实施例的结构示意图；

图10为本申请第四方面提供的分流服务器的一实施例的结构示意图；

图11为本申请第五方面提供的注册中心服务器的一实施例的结构示意图；

图12为本申请第六方面提供的分流服务器的一实施例的结构示意图。

具体实施方式

下面将详细描述本申请的各个方面的特征和示例性实施例，为了使本申请的目的、技术方案及优点更加清楚明白，以下结合附图及具体实施例，对本申请进行进一步详细描述。应理解，此处所描述的具体实施例仅意在解释本申请，而不是限定本申请。对于本领域技术人员来说，本申请可以在不需要这些具体细节中的一些细节的情况下实施。下面对实施例的描述仅仅是为了通过示出本申请的示例来提供对本申请更好的理解。

随着网络技术的发展，网络能够提供的服务种类也越来越多。为了满足用户需求，会需要对网络架构进行调整，例如，对用于提供服务的应用服务器进行扩容或缩容，即增加应用服务器或减少应用服务器。现阶段，如需对应用服务器进行扩容或缩容，需要专业工作人员对分流服务器进行手工配置修改，工作量较大，且流程繁琐，效率较低。

本申请提供一种服务器扩缩容方法、服务器、系统及存储介质，能够减少或避免人工介入服务器扩容或缩容的流程及时间，从而简化服务器扩缩容流程，提高服务器扩缩容的效率。

本申请提供的服务器扩缩容方法可涉及分流服务器、注册中心和应用服务器。分流服务器具体可包括超文本传输协议(HyperText Transfer Protocol)服务器，如nginx服务器、apache服务器等，在此并不限定。应用服务器可包括tomcat服务器、upjas服务器等，在此并不限定。注册中心可包括Zookeeper服务器等，在此并不限定。分流服务器、注册中心、应用服务器可为虚拟服务器，也可为实体服务器，在此并不限定。

图1为本申请实施例提供的服务器扩缩容方法的应用场景的一示例的示意图。如图1所示，分流服务器11可与应用服务器12进行通信，注册中心13可与应用服务器12、分流服务器11进行通信。

下面对服务器扩缩容方法进行具体说明。

本申请第一方面提供一种服务器扩缩容方法，可应用于注册中心。图2为本申请第一方面提供的服务器扩缩容方法的一实施例的流程图。如图2所示，该服务器扩缩容方法可包括步骤S201至步骤S203。

在步骤S201中，接收应用服务器触发发送的更新消息。

在应用服务器上线或下线的情况下，应用服务器触发向注册中心发送更新消息。对应地，更新消息用于表征应用服务器上线或下线。应用服务器上线表示在网络架构中增添该应用服务器，即该应用服务器参与网络架构中的通信及服务。应用服务器下线表示在网络架构中移除该应用服务器，即该应用服务器不再参与网络架构中的通信及服务。

在一些示例中，在更新消息用于表征应用服务器上线的情况下，更新消息是应用服务器启动完毕后触发发送的。即将应用服务器添加至网络架构中，该应用服务器启动完毕后主动触发向注册中心发送更新消息，以实现应用服务器的扩容。

在另一些示例中，在更新消息用于表征应用服务器下线的情况下，更新消息是应用服务器停止工作前触发发送的。即在将应用服务器从网络架构中移除前，该应用服务器主动触发向注册中心发送更新消息，以实现应用服务器的缩容。

注册中心通过应用服务器自动发送的更新消息，可获取到应用服务器上线、下线的相关信息。

在步骤S202中，响应于更新消息，在注册中心添加或删除应用服务器对应的节点。

注册中心包括多个节点，每个节点与一个应用服务器对应。在更新消息表征应用服务器上线的情况下，注册中心添加与更新消息表征的上线的服务器对应的节点。在更新消息表征应用服务器下线的情况下，注册中心删除与更新消息表征的下线的服务器对应的节点。

例如，注册中心包括节点A1至A10。在注册中心接收到表征应用服务器B11上线的更新消息的情况下，注册中心添加新的节点A11，新的节点A11与应用服务器B11对应。

又例如，注册中心包括节点A1至A10，节点A1至A10分别与服务器B1至B10对应。在注册中心接收到表征应用服务器B7下线的更新消息的情况下，注册中心删除与应用服务器B7对应的节点A7。

在一些示例中，还可在注册中心建立或删除应用服务器对应的节点与分流服务器的订阅关系。在更新消息用于表征应用服务器上线的情况下，注册中心建立该应用服务器对应的节点与分流服务器的订阅关系。在更新消息用于保证应用服务器下线的情况下，注册中心删除该应用服务器对应的节点与分流服务器的订阅关系。

注册中心会主动向分流服务器发送与该分流服务器具有订阅关系的节点对应的应用服务器的相关信息。注册中心通过建立或删除订阅关系，可对分流服务器和应用服务器之间的通信进行管理。

在步骤S203中，向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息。

分流服务器可进行该分流服务器订阅的节点对应的应用服务器的分流。在存在多个分流服务器的情况下，每个分流服务器可订阅至少一个节点。注册中心添加与上线的应用服务器对应的节点，注册中心可主动建立该节点与一分流服务器的订阅关系，或者，分流服务器主动配置与该上线的应用服务器对应的节点之间的订阅关系，在此并不限定。

例如，注册中心包括节点A1至A10，分流服务器包括分流服务器C1和C2。其中，分流服务器C1与节点A1至A6具有订阅关系，分流服务器C2与节点A7至A10具有订阅关系。分流服务器C1可将流量分流至节点A1至A6对应的应用服务器。分流服务器C2可将流量分流至节点A7至A10对应的应用服务器。

第一通知消息用于表征应用服务器上线或下线。注册中心通过向订阅更新消息表征上线或下线的应用服务器的节点的分流服务器发送第一通知消息，通知分流服务器该应用服务器上线或下线，以使分流服务器能够对更新后的应用服务器进行分流。

在本申请实施例中，通过应用服务器自动触发发送的更新消息，通知注册中心应用服务器上线或下线。注册中心可根据应用服务器上线或下线，在注册中心添加或删除该应用服务器对应的节点。注册中心通过向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息，以使分流服务器得知该应用服务器上线或下线，从而使得分流服务器可对与自身具有订阅关系的节点对应的应用服务器即在线的应用服务器进行分流，实现了应用服务器的自动扩缩容，减少甚至避免了人工介入服务器扩容或缩容的流程及时间，从而简化服务器扩缩容流程，提高服务器扩缩容的效率。应用服务器的扩缩容由应用服务器、注册中心和分流服务器自动完成，具有透明性。

在一些示例中，上述实施例中的更新消息可包括应用服务器的地址信息和应用服务器的端口信息。通过应用服务器的地址信息和引用服务器的端口信息可定位该应用服务器，因此可利用应用服务器的地址信息和端口信息标识应用服务器。地址信息用于表征应用服务器的地址，具体可包括网络协议(Internet Protocol，IP)地址及其他类型的地址等，在此并不限定。端口信息可表征访问该应用服务器所需的端口，具体可包括端口名称等，在此并不限定。

对应地，第一通知消息可包括应用服务器的地址信息和应用服务器的端口信息。应用服务器的地址信息和应用服务器的端口信息可参见上述相关说明，在此不再赘述。接收第一通知消息的分流服务器在后续过程中可根据地址信息和端口信息进行该应用服务器的分流。

在一些示例中，上述实施例中的更新消息还可包括应用服务器的健康页面的地址信息。应用服务器的地址信息和应用服务器的健康页面的地址信息可定位至应用服务器的健康页面。应用服务器的健康页面记录有应用服务器的健康状态。健康状态可包括应用服务器的上电状态、应用服务器的存储器状态等，在此并不限定。通过访问应用服务器的健康页面可确定应用服务器的健康状态。在应用服务器发生故障的情况下，应用服务器的健康页面无法访问成功。

在一些示例中，可通过定时访问应用服务器的健康页面，检测应用服务器是否发生故障导致该应用服务器下线。可通过定时向应用服务器发送健康页面访问消息来定时访问应用服务器的健康页面。可由能够与注册中心通信的检测系统向应用服务器发送健康页面访问消息，也可由注册中心向应用服务器发送健康页面访问消息。

图3为本申请第一方面提供的服务器扩缩容方法的另一实施例的流程图。图3与图2的不同之处在于，图3所示的服务器扩缩容方法还可包括步骤S204和步骤S205。

在步骤S204中，在超时未接收到应用服务器的健康页面反馈信息的情况下，在注册中心删除应用服务器对应的节点。

应用服务器在接收到健康页面访问消息且对应用服务器的健康页面访问成功的情况下，应用服务器会反馈健康页面反馈信息。但在应用服务器发生如应用服务器断电、应用服务器的磁盘损坏等宕机故障导致该应用服务器下线的情况下，该应用服务器不会反馈健康页面反馈信息。

在检测系统向应用服务器发送健康页面访问消息的情况下，若应用服务器未发生故障，应用服务器会向检测系统反馈健康页面反馈信息，检测系统会将健康页面反馈信息向注册中心发送；若应用服务器发生故障，应用服务器无法向检测系统反馈健康页面反馈信息，检测系统也无法向注册中心发送健康页面反馈信息，导致注册中心超时未接收到健康页面反馈信息，从而使注册中心确定应用服务器故障。

在注册系统向应用服务器发送健康页面访问消息的情况下，若应用服务器未发生故障，应用服务器会向注册中心反馈健康页面反馈信息；若应用服务器发生故障，应用服务器无法向注册中心反馈健康页面反馈信息，导致注册中心超时未接收到健康页面反馈信息，从而使注册中心确定应用服务器故障。

超时的时长可根据场景和需求设定，在此并不限定。

注册中心超时未接收到应用服务器的健康页面反馈信息，表示应用服务器发生故障下线。注册中心可删除该应用服务器对应的节点，即注册中心自动完成移除异常下线的应用服务器的缩容。

在步骤S205中，向与应用服务器对应的节点具有订阅关系的分流服务器发送第二通知消息。

第二通知消息用于表征应用服务器下线。注册中心可通过第二通知消息通知与异常下线的应用服务器对应的节点具有订阅关系的分流服务器，使该分流服务器确定异常下线的应用服务器，不再向该异常下线的应用服务器分流。

通过健康监测，可及时发现异常下线的应用服务器，注册中心可自动删除异常下线的应用服务器对应的节点，并通知分流服务器，以自动高效地完成移除异常下线的应用服务器的缩容。

本申请第二方面提供一种服务器扩缩容方法，可应用于分流服务器。图4为本申请第二方面提供的服务器扩缩容方法的一实施例的流程图。如图4所示，该服务器扩缩容方法可包括步骤S301和步骤S302。

在步骤S301中，接收注册中心发送的第一通知消息。

第一通知消息是注册中心基于应用服务器触发发送的更新消息生成的，用于表征应用服务器上线或下线。分流服务器与注册中心中应用服务器对应的节点具有订阅关系。第一通知消息、更新消息、应用服务器上线、应用服务器下线、订阅关系等可参见上述实施例中的相关说明，在此不再赘述。

在步骤S302中，响应于第一通知消息，在分流服务器增添或删除应用服务器的通信信息。

分流服务器通过第一通知消息，可确定与分流服务器对应的上线或下线的应用服务器。从而根据应用服务器上线或下线，确定增添或删除应用服务器的通信信息。应用服务器的通信信息用于分流服务器与该应用服务器进行通信。第一通知消息可包括上线或下线的应用服务器的通信信息。通过应用服务器的通信信息，分流服务器可与该应用服务器通信，从而完成分流。

在第一通信消息表征应用服务器上线的情况下，分流服务器增添该应用服务器的通信信息。增添该应用服务器的通信信息后，分流服务器可与该应用服务器进行通信，从而实现对该应用服务器的分流。在第一通信消息表征应用服务器下线的情况下，分流服务器删除该应用服务器的通信信息。删除该应用服务器的通信信息后，分流服务器不会与该应用服务器通信，从而避免应用服务器下线而分流服务器仍对其分流的情况。

在一些示例中，分流服务器中包括负载均衡(即loadbalance)列表，该负载均衡列表可通过loadbalance组件实现。负载均衡列表中包括该分流服务器能够通信的应用服务器的通信信息。分流服务器响应于第一通知消息，具体可在分流服务器中的负载均衡列表中增添或删除该应用服务器的通信信息。在第一通信消息表征应用服务器上线的情况下，分流服务器在负载均衡列表中增添该应用服务器的通信信息。在第一通信消息表征应用服务器下线的情况下，分流服务器在负载均衡里列表中删除该应用服务器的通信信息。

在本申请实施例中，分流服务器接收注册中心发送的能够表征应用服务器上线或下线的第一通知消息。分流服务器根据第一通知消息，确定该应用服务器上线或下线，从而增添或删除应用服务器的通信信息，以在后续过程中实现分流服务器与上线的应用服务器的分流，避免分流服务器与下线的应用服务器的分流，自动完成应用服务器的扩缩容，减少或避免人工介入服务器扩容或缩容的流程及时间，从而简化服务器扩缩容流程，提高服务器扩缩容的效率。应用服务器的扩缩容由应用服务器、注册中心和分流服务器自动完成，具有透明性。

在一些示例中，第一通知消息包括应用服务器的地址信息和应用服务器的端口信息。通信信息包括应用服务器的地址信息和应用服务器的端口信息。

第一通知消息、服务器的地址信息、应用服务器的端口信息等的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在一些示例中，应用服务器可能会因为意外故障发生宕机导致下线。可通过检测系统或注册中心对应用服务器的健康监测，检测系统或注册中心定时向应用服务器发送健康页面访问消息，通过是否能够在超时时间内接收到与健康页面访问信息对应的健康页面反馈信息，来确定应用服务器是否因意外故障宕机而下线。

图5为本申请第二方面提供的服务器扩缩容方法的另一实施例的流程图。图5与图4的不同之处在于，图5所示的服务器扩缩容方法还可包括步骤S303和步骤S304。

在步骤S303中，接收注册中心发送的第二通知消息。

第二通知消息是注册中心在超时未接收到应用服务器的健康页面反馈信息的情况下发送的，用于表征应用服务器下线。

在步骤S304中，响应于第二通知消息，在分流服务器删除应用服务器的通信信息。

第二通知消息、健康页面反馈信息、健康页面访问消息、通信信息等具体内容可参见上述实施例中的相关说明，在此不再赘述。

下面通过应用服务器、注册中心和分流服务器之间的交互来进一步说明服务器扩缩容方法涉及到的各个流程。

图6为本申请实施例提供的服务器扩容流程的一示例的流程图。在服务器扩容流程中，应用服务器上线，更新消息具体可为扩容更新消息，扩容更新消息用于表征应用服务器上线。如图6所示，该服务器扩容更新消息可包括步骤S401至步骤S405。

在步骤S401中，为应用服务器配置注册中心的地址信息。

在步骤S402中，应用服务器启动，触发向注册中心发送扩容更新消息。

在步骤S403中，注册中心响应于该扩容更新消息，添加该应用服务对应的节点。

在步骤S404中，注册中心向与该节点具有订阅关系的分流服务器发送第一通知消息。该第一通知消息用于表征该应用服务器上线。

在步骤S405中，分流服务器响应于第一通知消息，增添该应用服务器的通信信息。

图7为本申请实施例提供的服务器缩容流程的一示例的流程图。在服务器缩容流程中，应用服务器正常下线，更新消息具体可为缩容更新消息，缩容更新消息用于表征应用服务器下线。如图7所示，该服务器缩容更新消息可包括步骤S501至步骤S504。

在步骤S501中，应用服务器在正常停止工作前，触发向注册中心发送缩容更新消息。

在步骤S502中，注册中心响应于该缩容更新消息，删除该应用服务器对应的节点。

在步骤S503中，注册中心向与该节点具有订阅关系的分流服务器发送第一通知消息。该第一通知消息用于表征该应用服务器下线。

在步骤S505中，分流服务器响应于第一通知消息，删除该应用服务器的通信信息。

图8为本申请实施例提供的服务器缩容流程的另一示例的流程图。在服务器缩容流程中，检测系统可对应用服务器定时进行健康检测，应用服务器异常下线。检测系统可与注册中心集成设置，也可独立设置。在本实施例中以检测系统与注册中心独立设置为例进行说明。如图8所示，该服务器缩容更新消息可包括步骤S601至步骤S604。

在步骤S601中，检测系统定时向应用服务器发送健康页面访问消息。

在应用服务器正常工作的情况下，应用服务器会向检测系统反馈健康页面反馈信息，检测系统会将接收到的反馈健康页面反馈信息向注册中心转发。在应用服务器因故障导致下线的情况下，应用服务器不会向检测系统反馈健康页面反馈信息，检测系统也无法将健康页面反馈信息向注册中心转发。

在步骤S602中，注册中心在超时未接收到应用服务器的健康页面反馈信息的情况下，删除该应用服务器对应的节点。

在步骤S603中，注册中心向与该节点具有订阅关系的分流服务器发送第二通知消息。第二通知消息用于保证该应用服务器下线。

在步骤S604中，分流服务器响应于第二通知消息，删除该应用服务器的通信信息。

上述服务器扩容流程、服务器缩容流程可相互结合，在此并不限定。

本申请第三方面提供了一种注册中心服务器。上述实施例中的注册中心可包括至少一个注册中心服务器，在此并不限定。图9为本申请第三方面提供的注册中心服务器的一实施例的结构示意图。如图9所示，该注册中心服务器700可包括接收模块701、节点管理模块702和发送模块703。

接收模块701可用于接收应用服务器触发发送的更新消息。

更新消息用于表征应用服务器上线或下线。

节点管理模块702可用于响应于更新消息，在注册中心添加或删除应用服务器对应的节点。

发送模块703可用于向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息。

第一通知消息用于表征应用服务器上线或下线。

在本申请实施例中，通过应用服务器自动触发发送的更新消息，通知注册中心应用服务器上线或下线。注册中心可根据应用服务器上线或下线，在注册中心添加或删除该应用服务器对应的节点。注册中心通过向与应用服务器对应的节点具有订阅关系的分流服务器发送第一通知消息，以使分流服务器得知该应用服务器上线或下线，从而使得分流服务器可对与自身具有订阅关系的节点对应的应用服务器即在线的应用服务器进行分流，实现了应用服务器的自动扩缩容，减少甚至避免了人工介入服务器扩容或缩容的流程及时间，从而简化服务器扩缩容流程，提高服务器扩缩容的效率。应用服务器的扩缩容由应用服务器、注册中心和分流服务器自动完成，具有透明性。

在一些示例中，更新消息包括应用服务器的地址信息和应用服务器的端口信息。第一通知消息包括应用服务器的地址信息和应用服务器的端口信息。

在一些示例中，更新消息还包括应用服务器的健康页面的地址信息，健康页面记录有应用服务器的健康状态。

在一些示例中，上述节点管理模块702还可用于在注册中心建立或删除应用服务器对应的节点与分流服务器的订阅关系。

在一些示例中，上述节点管理模块702还可用于在超时未接收到应用服务器的健康页面反馈信息的情况下，在注册中心删除应用服务器对应的节点。

上述发送模块703还可用于在超时未接收到应用服务器的健康页面反馈信息的情况下，向与应用服务器对应的节点具有订阅关系的分流服务器发送第二通知消息。第二通知消息用于表征应用服务器下线。

在一些示例中，在更新消息用于表征应用服务器上线的情况下，更新消息是应用服务器启动完毕后触发发送的。

在更新消息用于表征应用服务器下线的情况下，更新消息是应用服务器停止工作前触发发送的。

本申请第四方面提供了一种分流服务器。图10为本申请第四方面提供的分流服务器的一实施例的结构示意图。如图10所示，该分流服务器800可包括接收模块801和处理模块802。

接收模块801可用于接收注册中心发送的第一通知消息。

第一通知消息是注册中心基于应用服务器触发发送的更新消息生成的，用于表征应用服务器上线或下线。分流服务器与注册中心中应用服务器对应的节点具有订阅关系。

处理模块802可用于响应于第一通知消息，在分流服务器增添或删除应用服务器的通信信息。

在本申请实施例中，分流服务器接收注册中心发送的能够表征应用服务器上线或下线的第一通知消息。分流服务器根据第一通知消息，确定该应用服务器上线或下线，从而增添或删除应用服务器的通信信息，以在后续过程中实现分流服务器与上线的应用服务器的分流，避免分流服务器与下线的应用服务器的分流，自动完成应用服务器的扩缩容，减少或避免人工介入服务器扩容或缩容的流程及时间，从而简化服务器扩缩容流程，提高服务器扩缩容的效率。应用服务器的扩缩容由应用服务器、注册中心和分流服务器自动完成，具有透明性。

在一些示例中，第一通知消息包括应用服务器的地址信息和应用服务器的端口信息。通信信息包括应用服务器的地址信息和应用服务器的端口信息。

在一些示例中，上述处理模块802可用于响应于第一通知消息，在分流服务器中的负载均衡列表中增添或删除应用服务器的通信信息。

在一些示例中，上述接收模块801还可用于接收注册中心发送的第二通知消息。第二通知消息是注册中心在超时未接收到应用服务器的健康页面反馈信息的情况下发送的，用于表征应用服务器下线。

上述处理模块802可用于响应于第二通知消息，在分流服务器删除应用服务器的通信信息。

本申请第五方面提供一种注册中心服务器。图11为本申请第五方面提供的注册中心服务器的一实施例的结构示意图。如图11所示，注册中心服务器900包括存储器901、处理器902及存储在存储器901上并可在处理器902上运行的计算机程序。

在一个示例中，上述处理器902可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器901可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(RandomAccess Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请应用于注册中心的服务器扩缩容方法所描述的操作。

处理器902通过读取存储器901中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述实施例中应用于注册中心的服务器扩缩容方法。

在一个示例中，注册中心服务器900还可包括通信接口903和总线904。其中，如图11所示，存储器901、处理器902、通信接口903通过总线904连接并完成相互间的通信。

通信接口903，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口903接入输入设备和/或输出设备。

总线904包括硬件、软件或两者，将注册中心服务器900的部件彼此耦接在一起。举例来说而非限制，总线904可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industrial Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low pincount，LPC)总线、存储器总线、微信道架构(Micro Channel Architecture，MCA)总线、外围组件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial Advanced Technology Attachment，SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线904可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

本申请第六方面提供一种分流服务器。图12为本申请第六方面提供的分流服务器的一实施例的结构示意图。如图12所示，分流服务器1000包括存储器1001、处理器1002及存储在存储器1001上并可在处理器1002上运行的计算机程序。

在一个示例中，上述处理器1002可以包括中央处理器(CPU)，或者特定集成电路(Application Specific Integrated Circuit，ASIC)，或者可以被配置成实施本申请实施例的一个或多个集成电路。

存储器1001可包括只读存储器(Read-Only Memory，ROM)，随机存取存储器(Random Access Memory，RAM)，磁盘存储介质设备，光存储介质设备，闪存设备，电气、光学或其他物理/有形的存储器存储设备。因此，通常，存储器包括一个或多个编码有包括计算机可执行指令的软件的有形(非暂态)计算机可读存储介质(例如，存储器设备)，并且当该软件被执行(例如，由一个或多个处理器)时，其可操作来执行参考根据本申请应用于分流服务器的服务器扩缩容方法所描述的操作。

处理器1002通过读取存储器1001中存储的可执行程序代码来运行与可执行程序代码对应的计算机程序，以用于实现上述实施例中应用于分流服务器的服务器扩缩容方法。

在一个示例中，分流服务器1000还可包括通信接口1003和总线1004。其中，如图12所示，存储器1001、处理器1002、通信接口1003通过总线1004连接并完成相互间的通信。

通信接口1003，主要用于实现本申请实施例中各模块、装置、单元和/或设备之间的通信。也可通过通信接口1003接入输入设备和/或输出设备。

总线1004包括硬件、软件或两者，将分流服务器1000的部件彼此耦接在一起。举例来说而非限制，总线1004可包括加速图形端口(Accelerated Graphics Port，AGP)或其他图形总线、增强工业标准架构(Enhanced Industry Standard Architecture，EISA)总线、前端总线(Front Side Bus，FSB)、超传输(Hyper Transport，HT)互连、工业标准架构(Industrial Standard Architecture，ISA)总线、无限带宽互连、低引脚数(Low pincount，LPC)总线、存储器总线、微信道架构(Micro Channel Architecture，MCA)总线、外围组件互连(Peripheral Component Interconnect，PCI)总线、PCI-Express(PCI-X)总线、串行高级技术附件(Serial Advanced Technology Attachment，SATA)总线、视频电子标准协会局部(Video Electronics Standards Association Local Bus，VLB)总线或其他合适的总线或者两个或更多个以上这些的组合。在合适的情况下，总线1004可包括一个或多个总线。尽管本申请实施例描述和示出了特定的总线，但本申请考虑任何合适的总线或互连。

本申请第七方面提供一种服务器扩缩容系统。该服务器扩缩容系统可包括上述实施例种的注册中心服务器和分流服务器，具体内容可参见上述实施例中的相关说明，在此不再赘述。

在一些示例中，该服务器扩缩容系统还可包括应用服务器。应用服务器的具体内容可参见上述实施例中的相关说明，在此不再赘述。

在一些示例中，该服务器扩缩容系统还可包括检测系统。检测系统的具体内容可参见上述实施例中的相关说明，在此不再赘述。

本申请第八方面提供一种计算机可读存储介质。该计算机可读存储介质上存储有计算机程序指令，该计算机程序指令被处理器执行时可实现上述实施例中的第一方面的服务器扩缩容方法或第二方面的服务器扩缩容方法，且能达到相同的技术效果，为避免重复，这里不再赘述。其中，上述计算机可读存储介质可包括非暂态计算机可读存储介质，如只读存储器(Read-Only Memory，简称ROM)、随机存取存储器(Random Access Memory，简称RAM)、磁碟或者光盘等，在此并不限定。

需要明确的是，本说明书中的各个实施例均采用递进的方式描述，各个实施例之间相同或相似的部分互相参见即可，每个实施例重点说明的都是与其他实施例的不同之处。对于服务器实施例、系统实施例、计算机可读存储介质实施例而言，相关之处可以参见方法实施例的说明部分。本申请并不局限于上文所描述并在图中示出的特定步骤和结构。本领域的技术人员可以在领会本申请的精神之后，作出各种改变、修改和添加，或者改变步骤之间的顺序。并且，为了简明起见，这里省略对已知方法技术的详细描述。

上面参考根据本申请的实施例的方法、装置(系统)和计算机程序产品的流程图和/或框图描述了本申请的各方面。应当理解，流程图和/或框图中的每个方框以及流程图和/或框图中各方框的组合可以由计算机程序指令实现。这些计算机程序指令可被提供给通用计算机、专用计算机、或其它可编程数据处理装置的处理器，以产生一种机器，使得经由计算机或其它可编程数据处理装置的处理器执行的这些指令使能对流程图和/或框图的一个或多个方框中指定的功能/动作的实现。这种处理器可以是但不限于是通用处理器、专用处理器、特殊应用处理器或者现场可编程逻辑电路。还可理解，框图和/或流程图中的每个方框以及框图和/或流程图中的方框的组合，也可以由执行指定的功能或动作的专用硬件来实现，或可由专用硬件和计算机指令的组合来实现。

本领域技术人员应能理解，上述实施例均是示例性而非限制性的。在不同实施例中出现的不同技术特征可以进行组合，以取得有益效果。本领域技术人员在研究附图、说明书及权利要求书的基础上，应能理解并实现所揭示的实施例的其他变化的实施例。在权利要求书中，术语“包括”并不排除其他装置或步骤；数量词“一个”不排除多个；术语“第一”、“第二”用于标示名称而非用于表示任何特定的顺序。权利要求中的任何附图标记均不应被理解为对保护范围的限制。权利要求中出现的多个部分的功能可以由一个单独的硬件或软件模块来实现。某些技术特征出现在不同的从属权利要求中并不意味着不能将这些技术特征进行组合以取得有益效果。