CN109918268A - 系统兼容方法、装置、设备和计算机可读存储介质 - Google Patents

Abstract

本申请关于一种系统兼容方法和装置。该系统兼容方法通过监听集群事件，根据集群事件判断应用服务的当前状态，并据此向集群外的至少一个服务发现系统发送相应请求，所述相应请求向所述至少一个服务发现系统提供应用服务的应用入口信息和/或当前状态信息。该系统兼容方法不影响集群和所述至少一个服务发现系统各自的正常工作，从而实现集群和外部的服务发现系统的兼容。

Description

系统兼容方法、装置、设备和计算机可读存储介质

技术领域

本申请属于计算机技术领域，尤其是一种系统兼容方法、装置、设备和计算机可读存储介质。

背景技术

kubernetes是一个用于自动部署、扩展和管理容器化应用程序的开源的集权管理系统。近年来，随着以kubernetes和docker为代表的容器技术以及容器编排管理技术等云计算相关技术的持续完善，越来越多的开发者和团队选择使用公/私有云平台，通过使用容器装载自己的应用程序，通过kubernetes等容器编排系统批量管理自身容器的部署、发现、升级等，从而达到降低系统运维成本、提升系统鲁棒性、提高机器资源使用率等目的。

绝大多数的应用服务不是孤立的，即服务之间一般需要相互访问，或者服务需要向终端用户暴露请求入口。对于以容器方式部署在kubernetes集群中的应用服务，kubernetes提供了一种服务发现机制：kubernetes可为提供相同服务的容器组创建kubernetes service资源，通过service clusterIP向同集群内其他服务提供访问入口，根据service类型(LoadBlancer Service、NodePort Service、Ingress)以不同方式向集群外提供访问入口。

但是在实际应用场景中，应用服务往往会同时以不同的方式部署、维护在不同的环境中，例如，应用服务部分部署在kubernetes集群内，部分部署在非kubernetes集群内，如直接运行在宿主机上；或者应用服务部署在多个不同的kubernetes集群内。然而kubernetes系统默认提供的服务发现机制只能发现运行在本系统内部的应用服务，对于运行在本系统之外的应用服务，无论运行在另一个kubernetes内部还是运行直接运行在宿主机上，并没有提供一个适当的发现机制。

对此，一种常见的现有技术方案是，设置容器网络模式为host，即该容器的网络堆栈不与宿主机隔离，kubernets系统默认提供的service机制也就失效，集群中每个容器都直接注册到第三方服务发现系统。但是该方案也有如下缺点：

1)由于容器网络采用host模式，即容器与宿主机之间没有网络隔离，破坏了容器网络的隔离性，宿主机端口可能存在冲突，同时也增加了基于kubernetes的云平台服务管理等相关功能的复杂性；

2)由于不使用kubernets系统默认提供的service机制，kubernetes系统为service配套支持的系列功能也就无法发挥作用了，如service默认支持的系列负载均衡策略、kubernetes pod健康检查机制与service的联动、容器组(deployment)变动与service联动等功能。应用服务通过kubernetes系统进行服务管理的难度增大、集群易用性和稳定性受到影响。

由此可见，现有技术中并没有提供一种有效的解决方案，以解决kubernets系统和第三方服务发现系统兼容的问题。

发明内容

有鉴于此，本申请公开一种系统兼容方法和系统，以解决现有技术中存在的问题。

第一方面，本发明实施例提供一种系统兼容方法，包括：

监听并获取和集群内运行的应用服务相关的集群事件；

根据所述集群事件判断所述应用服务的当前状态；以及

根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求，所述相应请求向所述至少一个服务发现系统提供所述应用服务的应用入口信息和/或当前状态信息。

在一些实施例中，所述相应请求包括注册请求、解注册请求和状态健康的报告。

在一些实施例中，所述应用服务的当前状态包括：可用且未注册、不可用且已经注册、可用且已经注册和不可用且未注册，所述根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求包括：

当判定所述应用服务的当前状态为可用且未注册时，向至少一个服务发现系统发送所述应用服务的注册请求；

当判定所述应用服务的当前状态为不可用且已经注册时，向至少一个服务发现系统发送所述应用服务的解注册请求；

当判定所述应用服务的当前状态为可用且已经注册时，向至少一个服务发现系统发送所述应用服务的状态健康的报告。

在一些实施例中，还包括：配置所述应用服务的配置数据，则所述判断所述应用服务的当前状态包括：根据所述集群事件和所述配置数据判断所述应用服务的当前状态。

在一些实施例中，所述集群事件为所述应用服务对应的容器组和/或容器事件，所述根据所述集群事件和所述配置数据判断所述应用服务的当前状态包括：

如果所述应用服务对应的容器的总和小于设定阈值，则判定所述应用服务的当前状态为不可用；

如果所述应用服务对应的容器的总和大于或者等于设定阈值，则判定所述应用服务的当前状态为可用。

在一些实施例中，所述集群管理系统为kubernetes系统，所述应用服务的配置数据包括：应用服务名称、容器组名称、kubernetes服务发现组名、集群列表、应用服务的最低可用容器数量、服务发现系统列表和服务发现系统各自的汇报周期。

在一些实施例中，根据所述集群事件的应用服务名称、容器组名称和kubernetes服务发现组名称唯一确定一个所述应用服务。

在一些实施例中，所述根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求包括：

定时从所述数据库中读取当前状态信息并据此向至少一个服务发现系统发送相应请求。

在一些实施例中，所述定时从所述数据库中读取当前状态信息并据此向至少一个服务发现系统发送相应请求包括：

采用定时器定时生成触发信号；

采用独立线程接收所述触发信号，并在接收到所述触发信号之后，从所述数据库中读取所述当前状态信息并据此向至少一个服务发现系统发送相应请求。

第二方面，本发明实施例提供一种系统兼容装置，包括：

事件监听模块，用于监听并获取和集群内运行的应用服务相关的集群事件；

流程控制模块，用于整体流程控制，以及根据所述集群事件判断所述应用服务的当前状态；

服务汇报模块，用于根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求，所述相应请求用于向所述至少一个服务发现系统提供所述应用服务的应用入口信息和/或当前状态信息；

存储模块，用于将所述应用服务的当前状态信息到数据库中。

在一些实施例中，所述相应请求包括注册请求、解注册请求和状态健康的报告。

在一些实施例中，所述应用服务的当前状态包括：可用且未注册、不可用且已经注册、可用且已经注册和不可用且未注册，所述服务汇报模块包括：

所述应用服务的当前状态为可用且未注册时，发送所述应用服务的注册请求；

当判定所述应用服务的当前状态为不可用且已经注册时，发送所述应用服务的解注册请求；

当判定所述应用服务的当前状态为可用且已经注册时，发送所述应用服务的状态健康的报告。

在一些实施例中，所述存储模块还包括：配置模块，用于配置所述应用服务的配置数据，则所述流程控制模块根据所述集群事件和所述配置数据判断所述应用服务的当前状态。

在一些实施例中，所述集群事件为所述应用服务对应的容器组和/或容器事件，所述流程控制模块包括：

如果所述应用服务对应的容器的总和小于设定阈值，则判定所述应用服务的当前状态为不可用；

如果所述应用服务对应的容器的总和大于或者等于设定阈值，则判定所述应用服务的当前状态为可用。

在一些实施例中，所述集群管理系统为kubernetes系统，所述应用服务的配置数据包括：应用服务名称、容器组名称、kubernetes服务发现组名、集群列表、应用服务的最低可用容器数量、服务发现系统列表和服务发现系统各自的汇报周期。

在一些实施例中，根据所述集群事件的应用服务名称、容器组名称和kubernetes服务发现组名称唯一确定一个所述应用服务。

在一些实施例中，所述系统还包括定时器，所述定时器用于生成触发信号并发送给所述服务汇报模块，所述服务汇报模块在一个独立的线程中执行，并在接收到所述触发信号之后，从所述数据库中读取当前状态信息并据此向至少一个服务发现系统发送相应请求。

第三方面，本发明实施例提供一种实现集群管理系统和服务发现系统兼容的装置，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行上述任意一项所述的系统兼容方法。

第四方面，提供一种计算机可读存储介质，所述计算机可读存储介质存储有计算机指令，所述计算机指令被执行时实现上述任一项所述的系统兼容方法。

第五方面，本发明实施例提供计算机程序产品，包括计算机程序，所述计算机程序包括程序指令，当所述程序指令被处理器执行时，执行上述任意一项的方法。

本申请的实施例提供的技术方案可以包括以下有益效果：通过监听集群事件，根据集群事件判断应用服务的当前状态，并据此向集群外的至少一个服务发现系统发送相应请求,所述相应请求向至少一个服务发现系统汇报应用服务的应用入口信息和/或当前状态信息，该系统兼容方法不影响集群和所述至少一个服务发现系统各自的正常工作，从而实现集群和外部的服务发现系统的兼容。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本申请。

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本申请的实施例，并与说明书一起用于解释本申请的原理。

图1所示为本发明一示例性实施例提供的系统兼容方法的流程图；

图2所示为本发明一示例性实施例提供的系统兼容方法的流程图；

图3所示为kubernets集群、本发明实施例的系统兼容装置和第三方的服务发现系统的部署示意图；

图4所示为基于图3所示的部署示意图的系统兼容方法的流程图；

图5a和5b所示分别为图3的系统兼容装置的结构示意图；

图6所示为本发明一示例性实施例提供的实现集群管理系统和服务发现系统兼容的装置的结构框图；

图7所示为本发明一示例性实施例提供的另一种实现集群管理系统和服务发现系统兼容的装置的结构框图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本申请相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本申请的一些方面相一致的装置和方法的例子。

图1所示为本发明一示例性实施例提供的系统兼容方法的流程图。该方法实现集群管理系统和服务发现系统的兼容。具体包括以下步骤。

在步骤S101中，监听并获取和集群内运行的应用服务相关的集群事件。

集群是一组相互独立的、通过高速网络互联的计算机，集群管理软件将集群上的多个计算机变成了一个整体服务器，以单一模式进行管理并同时和外部系统进行交互。应用服务部署并运行在集群上的一个或多个计算机上。和应用服务相关的集群事件，例如应用服务的状态改变、数据库操作等事件可以通过集群管理软件获取到。

在步骤S102中，根据集群事件判断应用服务的当前状态。

在步骤S103中，根据应用服务的当前状态向至少一个服务发现系统发送相应请求。

在步骤S102-S103中，通过获取到的集群事件判断应用服务的当前状态，并根据应用服务的当前状态向外部的至少一个服务发现系统发送相应请求，通过相应请求将集群上的应用服务的应用入口信息和/或当前状态信息汇报给服务发现系统。

根据本发明实施例提供的方法，通过监听集群事件，根据集群事件判断应用服务的当前状态，并据此向集群外的服务发现系统发送相应请求，从而实现集群和外部的服务发现系统的兼容。可以理解，无论集群是否采用kubernets，均能够获取到集群上的集群事件。而且，由于通过监听模式获取集群事件，因此不影响集群上原有的集群管理系统的正常工作。

在上述实施例，相应请求用于向外部的服务发现系统汇报应用服务的应用入口信息和/或当前状态信息，可选地，相应请求可包括注册请求、解注册请求和状态健康的报告。具体地，当根据集群事件判定某个特定的应用服务在集群上初次运行时，向服务发现系统提供注册请求，表示该应用服务开始向外界提供相应的服务，之后，当该应用服务在集群上稳定运行时，向服务发现系统发送应用服务状态健康的报告，当该应用服务停止工作或者状态不正常时，则向服务发现系统发送应用服务解注册的请求，表示该应用服务无法提供服务。当然，本发明不局限于此，服务请求的种类可根据实际需要设计。

图2所示为本发明一示例性的实施例提供的系统兼容方法的流程图。具体包括以下步骤。

在步骤S201中，监听并获取和集群内运行的应用服务相关的集群事件。

本步骤和前述步骤S101相同，这里就不再赘述。

在步骤S202中，根据集群事件检索数据库

集群事件和应用服务相关，因此,每个集群事件必须包含应用服务的标识。步骤S201中，通过持续监听集群内任何事件获取和应用相关的集群事件。虽然前述方法中并未提及，但是实质上集群事件和/应用服务的当前状态信息需要存储到数据库中，以用于后续检索。因此当每获取到一个集群事件时，解析该集群事件，从中获取应用服务的标识，根据应用服务的标识检索数据时，获得该应用服务的集群事件和/或当前状态信息。

在步骤S203中，判断应用服务的当前状态。当应用服务的当前状态为可用且未注册时，执行步骤S204，当应用服务的当前状态为不可用且已经注册时，执行步骤S205，当应用服务的当前状态为可用且已经注册时，执行步骤S206。

在步骤S204中，向至少一个服务发现系统发送应用服务的注册请求。

在步骤S205中，向至少一个服务发现系统发送应用服务的解注册请求。

在步骤S206中，向至少一个服务发现系统发送应用服务的状态健康的报告。

在步骤S203-S206中，根据在先检索到的数据确定应用服务的当前状态。应用服务的当前状态包括以下四种：不可用且未注册，可用且未注册，不可用且已经注册和可用且已经注册。其中，可用或不可用表示应用服务是否能够对外提供服务。应用服务是否可用的判定标准可以预先设定，从而根据判断应用服务是否满足设定标准确定应用服务是否可用。例如，可以简单地将应用服务的启动事件作为应用服务可用的判定标准，将应用服务暂停或停止的事件作为应用服务不可用的判定标准。另外，根据是否能够在数据库中检索到相关数据判定应用服务是否注册过。例如，如果数据库没有找到相关数据时，可以确定应用服务没有注册过，如果数据库中找到相关数据时，可以确定应用服务注册过。在具体实施例中，具体检索哪些数据和表结构的设计相关。此外，对于不可用且未注册的应用服务，因为既不需要发送注册请求，也不需要发送解注册请求，因此不执行任何步骤。

本发明提供的系统兼容方法通过主动监听集群内应用服务的变动事件，并主动向其他服务发现系统汇报应用服务的当前信息，从而实现集群管理系统和服务发现系统兼容工作的目标。

在上述实施例中，提及集群事件和/应用服务的当前状态信息需要存储到数据库中，通常情况下，应用服务的一些配置数据也需要存储到数据库中，这些配置数据可用于判断应用服务的当前状态。

另外，在上述实施例中，根据应用服务的当前状态向服务发现系统发送相应请求，这里既包括实时发送相应请求，也包括定时发送相应请求。其中，可选地，通过定时器实现定时发送相应请求，具体包括：

采用定时器定时生成触发信号；

采用独立线程接收触发信号，并在接收到触发信号之后，从数据库中读取当前状态信息并据此向至少一个服务发现系统发送相应请求。

应该理解，可以结合上述一个或多个实施例，形成新的可选实施例，该可选实施例也应在本发明的保护范围之内。

图3所示为kubernets集群、本发明实施例的系统兼容装置和第三方的服务发现系统的部署示意图。下面结合图3的部署图进一步的说明本发明实施例的系统兼容方法如何应用于kubernets集群。

参见图3，多个kubernets集群310和本发明实施例的系统320通信连接，多个服务发现系统330和系统320通信连接。该通信连接可以基于HTTP协议、更底层的TCP/IP协议或其他协议构建。

其中，kubernets集群310包括管理节点311和多个工作节点312。管理节点311部署有APIServer、Replication Controller等多个应用程序，用于管理多个工作节点312。工作节点312上部署有kubelet、kube-proxy、docket等应用程序，用于管理部署在工作节点312上的应用服务。kubernets集群310采用容器组(Container)提供应用服务。每个容器组包含多个容器，每个容器里都运行一个应用程序，应用程序均各自独立地完成对应的应用服务。如图上所示，容器组部署在多个工作节点上。管理节点311实时监听并获取集群事件，并控制整个集群的负载均衡。服务发现系统330一般为第三方的服务发现系统，用于维护多个应用服务的应用入口信息以及当前状态信息。

基于上述kubernets集群，本发明实施例提供了如图4所示的系统兼容方法。具体包括以下步骤。

在步骤S401中，监听并获取和集群内运行的应用服务相关的集群事件。

在步骤S402中，存储应用服务的当前状态。

在步骤S403中，应用服务的容器数量是否大于或等于最低可用容器数量。如果是，则执行步骤S406，如果否，执行步骤S404。

在步骤S404中，是否发送过注册请求。如果是，执行步骤S405，如果否，判定应用服务当前处于部署状态，不发送任何请求。

在步骤S405中，发送解注册请求。

在步骤S406中，是否发送过注册请求。如果是，执行步骤S408，如果否，执行步骤S407。

在步骤S407中，发送注册请求。

在步骤S408中，发送状态健康的报告。

在本实施例中，根据应用服务对应的容器的数量判断当前的应用服务是否可用，根据是否发送过注册请求判断是否注册过，并且根据是否可用以及是否发送过注册请求向多个服务发现系统发送相应请求。kubernets集群中，一个应用服务一般对应一个容器组，则应用服务对应的容器组内的容器数量即为应用服务对应的容器数量。

基于上述kubernets集群，本发明实施例进一步提供了图5a和5b所示的集群管理系统和服务发现系统兼容的系统。参见图5a，系统400包括：事件监听模块420、服务汇报模块430、流程控制模块410和存储模块450。

事件监听模块420负责监控应用服务在kubernetes集群中发生的任何变动事件。对部署了应用服务容器的每个kubernetes集群，事件监听模块420与集群的APIServer组件建立http长连接，当应用程序的容器组(deployment)或服务发现组(service)发生变化时，集群事件监听器通过http长连接实时获得变化事件信息，并将事件信息推送给流程控制模块410。

存储模块450用于维护应用服务的当前状态信息以及应用服务的配置数据。应用服务的配置数据，具体包括：应用服务需要联动哪些服务发现系统、应用服务需要部署在哪些集群、容器组存活度判断标准、应用服务信息汇报周期等。同时维护了应用服务在各个kubernetes集群中的实时状态的数据，具体包括：各集群中应用容器数量、各容器组总体健康状态、serviceport、service clusterIP、集群接入IP等。

流程控制模块410是系统的核心组件，用于控制系统的整体流程并判断应用服务的当前状态。当集群中的应用服务发生变化时，流程控制模块410通过各集群的事件监听模块420获得变化事件，更新应用服务的当前状态，并根据应用服务的配置数据，将应用服务相关的各种请求推送到服务汇报模块430。

服务汇报模块430根据应用服务的当前状态向服务发现系统发送相应请求。服务汇报模块430可以实时或者定时向服务发现系统发送各种请求，例如注册请求、解注册请求和状态健康的报告等请求。在发送注册请求中，将应用服务的应用入口信息一并发送给服务发现系统，以便于其他系统能够访问应用服务。考虑到多个服务发现系统设计及实现的多样性，服务汇报模块430支持以http、tcp、proto-rpc等通信方式汇报请求。

图5b提供了另一个示例性的系统兼容装置的结构图。从图5b上可以看出，该系统500还可以包括定时器460和配置模块440。

本实施例通过定时器460，触发服务汇报模块430定期向服务发现系统发送请求。具体地，参见图5b，定时器460根据预先设定的应用服务信息汇报周期，定时产生触发信号，推送到服务汇报模块430。服务汇报模块430系统启动之后，即以独立线程启动并保持运行，当收到定时器460的触发信号之后，从内存/数据库读取应用服务的状态信息，判断本次汇报是需要向服务发现系统发起注册请求、还是正常的状态周期上报还是解除注册的请求，从而向服务发现系统发送相应请求。当结束一次处理后，继续等待下一次定时器460发送的触发信号。

配置模块440用于向用户或者其他系统提供配置接口，以获取应用服务的配置数据。配置模块440可以仅提供接口API或可编辑的配置文件，也可以提供配置页面，用于获取配置数据。配置数据具体包括：

1)应用服务名称、容器组(deployment)名称、kubernetes服务发现组名称(service)，系统通过以上三个名称将收到的kubernetes监听事件与具体服务关联；

2)应用服务目标部署集群列表，用于系统向具体集群发起监听连接；

3)应用服务的最低用容器数量，当集群内可用容器数量低于该阈值时，认为kubernetes集群内的应用服务不可用；

4)对接服务发现系统列表，用于告知系统向对应的多个服务发现系统推送应用入口信息信息。

5)服务发现汇报周期，不同服务发现系统要求应用服务定时汇报信息的周期不同，因此需要提前告知系统各对应服务发现系统的汇报周期。

在本实施例中，通过配置模块确定具体监听的应用服务。可以理解，在kubernetes集群上运行的多个应用服务部分需要向服务发现系统提供应用入口信息，部分不需要向服务发现系统提供应用入口信息，因此，提供配置模块将需要监听的应用服务配置出来。当然，如图5a所示的实施例中没有配置模块440，则监听所有的应用服务。

本发明提供的系统兼容方法和系统解决了部署在集群中的应用服务如何兼容使用多个服务发现系统的问题，应用服务在集群中使用集群技术实现集群内的服务相互发现，同时向集群外暴露应用入口信息。对于kubernetes集群，应用服务在内部通过service发现服务，外部通过该系统将应用服务的服务访问接口暴露给服务发现系统。

应该指出的是，虽然上述实施例多以kubernetes集群进行描述，但是该方法不限于kubernetes集群，其他任何集群管理系统，依然能够应用该方法和系统实现兼容的目的。

图6是根据一示例性实施例示出的一种执行系统兼容方法的装置的框图。该装置包括处理器和用于存储处理器可执行指令的存储器；

其中，处理器被配置为执行上述任意一项的系统兼容方法。

例如，装置1200可以是移动电话，计算机，数字广播终端，消息收发设备，游戏控制台，平板设备，医疗设备，健身设备，个人数字助理等。

参照图6，装置1200可以包括以下一个或多个组件：处理组件1202，存储器1204，电力组件1206，多媒体组件1208，音频组件1210，输入/输出(I/O)的接口1212，传感器组件1214，以及通信组件1216。

处理组件1202通常控制装置1200的整体操作，诸如与显示，电话呼叫，数据通信，相机操作和记录操作相关联的操作。处理组件1202可以包括一个或多个处理器1220来执行指令，以完成上述的方法的全部或部分步骤。此外，处理组件1202可以包括一个或多个模块，便于处理组件1202和其他组件之间的交互。例如，处理组件1202可以包括多媒体模块，以方便多媒体组件1208和处理组件1202之间的交互。

存储器1204被配置为存储各种类型的数据以支持在设备1200的操作。这些数据的示例包括用于在装置1200上操作的任何应用程序或方法的指令，联系人数据，电话簿数据，消息，图片，视频等。存储器1204可以由任何类型的易失性或非易失性存储设备或者它们的组合实现，如静态随机存取存储器(SRAM)，电可擦除可编程只读存储器(EEPROM)，可擦除可编程只读存储器(EPROM)，可编程只读存储器(PROM)，只读存储器(ROM)，磁存储器，快闪存储器，磁盘或光盘。

电源组件1206为装置1200的各种组件提供电力。电源组件1206可以包括电源管理系统，一个或多个电源，及其他与为装置1200生成、管理和分配电力相关联的组件。

多媒体组件1208包括在装置1200和用户之间的提供一个输出接口的屏幕。在一些实施例中，屏幕可以包括液晶显示器(LCD)和触摸面板(TP)。如果屏幕包括触摸面板，屏幕可以被实现为触摸屏，以接收来自用户的输入信号。触摸面板包括一个或多个触摸传感器以感测触摸、滑动和触摸面板上的手势。触摸传感器可以不仅感测触摸或滑动动作的边界，而且还检测与触摸或滑动操作相关的持续时间和压力。在一些实施例中，多媒体组件1208包括一个前置摄像头和/或后置摄像头。当设备1200处于操作模式，如拍摄模式或视频模式时，前置摄像头和/或后置摄像头可以接收外部的多媒体数据。每个前置摄像头和后置摄像头可以是一个固定的光学透镜系统或具有焦距和光学变焦能力。

音频组件1210被配置为输出和/或输入音频信号。例如，音频组件1210包括一个麦克风(MIC)，当装置1200处于操作模式，如呼叫模式、记录模式和语音识别模式时，麦克风被配置为接收外部音频信号。所接收的音频信号可以被进一步存储在存储器1204或经由通信组件1216发送。在一些实施例中，音频组件1210还包括一个扬声器，用于输出音频信号。

I/O接口1212为处理组件1202和外围接口模块之间提供接口，上述外围接口模块可以是键盘，点击轮，按钮等。这些按钮可包括但不限于：主页按钮、音量按钮、启用按钮和锁定按钮。

传感器组件1214包括一个或多个传感器，用于为装置1200提供各个方面的状态评估。例如，传感器组件1214可以检测到设备1200的打开/关闭状态，组件的相对定位，例如组件为装置1200的显示器和小键盘，传感器组件1214还可以检测装置1200或装置1200一个组件的位置改变，用户与装置1200接触的存在或不存在，装置1200方位或加速/减速和装置1200的温度变化。传感器组件1214可以包括接近传感器，被配置用来在没有任何的物理接触时检测附近物体的存在。传感器组件1214还可以包括光传感器，如CMOS或CCD图像传感器，用于在成像应用中使用。在一些实施例中，该传感器组件1214还可以包括加速度传感器，陀螺仪传感器，磁传感器，压力传感器或温度传感器。

通信组件1216被配置为便于装置1200和其他设备之间有线或无线方式的通信。装置1200可以接入基于通信标准的无线网络，如WiFi，运营商网络(如2G、3G、4G或5G)，或它们的组合。在一个示例性实施例中，通信组件1216经由广播信道接收来自外部广播管理系统的广播信号或广播相关信息。在一个示例性实施例中，通信组件1216还包括近场通信(NFC)模块，以促进短程通信。例如，在NFC模块可基于射频识别(RFID)技术，红外数据协会(IrDA)技术，超宽带(UWB)技术，蓝牙(BT)技术和其他技术来实现。

在示例性实施例中，装置1200可以被一个或多个应用专用集成电路(ASIC)、数字信号处理器(DSP)、数字信号处理设备(DSPD)、可编程逻辑器件(PLD)、现场可编程门阵列(FPGA)、控制器、微控制器、微处理器或其他电子元件实现，用于执行上述方法。

在示例性实施例中，还提供了一种包括指令的非临时性计算机可读存储介质，例如包括指令的存储器1204，上述指令可由装置1200的处理器1220执行以完成上述方法。例如，非临时性计算机可读存储介质可以是ROM、随机存取存储器(RAM)、CD-ROM、磁带、软盘和光数据存储设备等。

图7是根据一示例性实施例示出的执行系统兼容方法的装置的框图。例如，装置1300可以被提供为一服务器。参照图7，装置1300包括处理组件1322，其进一步包括一个或多个处理器，以及由存储器1332所代表的存储器资源，用于存储可由处理组件1322的执行的指令，例如应用程序。存储器1332中存储的应用程序可以包括一个或一个以上的每一个对应于一组指令的模块。此外，处理组件1322被配置为执行指令，以执行上述系统兼容方法。

装置1300还可以包括一个电源组件1326被配置为执行装置1300的电源管理，一个有线或无线网络接口1350被配置为将装置1300连接到网络，和一个输入输出(I/O)接口1358。装置1300可以操作基于存储在存储器1332的操作系统，例如Windows ServerTM，MacOS XTM，UnixTM,LinuxTM，FreeBSDTM或类似。

在示例性实施例中，还提供了计算机程序产品，包括计算机程序，计算机程序包括程序指令，当程序指令被装置执行时，使装置执行上述系统兼容方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本申请的其它实施方案。本申请旨在涵盖本申请的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本申请的一般性原理并包括本申请未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本申请的真正范围和精神由下面的权利要求指出。

应当理解的是，本申请并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本申请的范围仅由所附的权利要求来限制。

Claims (10)

1.一种系统兼容方法，其特征在于，包括：

监听并获取和集群内运行的应用服务相关的集群事件；

根据所述集群事件判断所述应用服务的当前状态；以及

根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求，所述相应请求向所述至少一个服务发现系统提供所述应用服务的应用入口信息和/或状态信息。

2.根据权利要求1所述的系统兼容方法，其特征在于，所述相应请求包括注册请求、解注册请求和状态健康的报告。

3.根据权利要求2所述的系统兼容方法，其特征在于，所述应用服务的当前状态包括：可用且未注册、不可用且已经注册、可用且已经注册和不可用且未注册，所述根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求包括：

当判定所述应用服务的当前状态为可用且未注册时，向所述至少一个服务发现系统发送所述应用服务的注册请求；

当判定所述应用服务的当前状态为不可用且已经注册时，向所述至少一个服务发现系统发送所述应用服务的解注册请求；

当判定所述应用服务的当前状态为可用且已经注册时，向所述至少一个服务发现系统发送所述应用服务的状态健康的报告。

4.根据权利要求1所述的系统兼容方法，其特征在于，还包括：配置所述应用服务的配置数据，则所述判断所述应用服务的当前状态包括：根据所述集群事件和所述配置数据判断所述应用服务的当前状态。

5.根据权利要求4所述的系统兼容方法，其特征在于，所述集群事件为所述应用服务对应的容器组和/或容器事件，所述根据所述集群事件和所述配置数据判断所述应用服务的当前状态包括：

如果所述应用服务对应的容器的总和小于设定阈值，则判定所述应用服务的当前状态为不可用；

如果所述应用服务对应的容器的总和大于或者等于设定阈值，则判定所述应用服务的当前状态为可用。

6.根据权利要求1所述的系统兼容方法，其特征在于，所述根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求包括：

定时从所述数据库中读取当前状态信息并据此向至少一个服务发现系统发送相应请求。

7.根据权利要求6所述的系统兼容方法，其特征在于，所述定时从所述数据库中读取当前状态信息并据此向至少一个服务发现系统发送相应请求包括：

采用定时器定时生成触发信号；

采用独立线程接收所述触发信号，并在接收到所述触发信号之后，从所述数据库中读取所述当前状态信息并据此向至少一个服务发现系统发送相应请求。

8.一种系统兼容装置，其特征在于，包括：

事件监听模块，用于监听并获取和集群内运行的应用服务相关的集群事件；

流程控制模块，用于整体流程控制，以及根据所述集群事件判断所述应用服务的当前状态；

服务汇报模块，用于根据所述应用服务的当前状态向至少一个服务发现系统发送相应请求，所述相应请求用于向所述至少一个服务发现系统提供所述应用服务的应用入口信息和/或当前状态信息；

存储模块，用于将所述应用服务的当前状态信息到数据库中。

9.一种设备，其特征在于，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中，所述处理器被配置为执行上述权利要求1至7任意一项所述的系统兼容方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令被执行时实现如权利要求1至7任一项所述的系统兼容方法。