CN111143069A - 服务管理方法、装置、电子设备、存储介质 - Google Patents

Abstract

本发明公开了服务管理方法、装置、电子设备、存储介质。方法应用于通过微服务架构构建的应用***，所述应用***包含多个服务，所述多个服务中的至少一个服务处于停止状态；方法包括：监听并拦截针对目标服务的访问请求；识别所述目标服务的当前状态；若所述目标服务的当前状态为启动状态，则放行所述访问请求；若所述目标服务的当前状态为停止状态，则启动所述目标服务后，放行所述访问请求。从而无需将应用***的所有服务始终处于启动状态，可控制部分不常用的服务处于常停止状态，仅在有需要的时候启动该服务，从而***不会因为大量服务一直处于启动状态占用大量资源。

Description

服务管理方法、装置、电子设备、存储介质

技术领域

本发明涉及互联网技术领域，特别涉及服务管理方法、装置、电子设备、存储介质。

背景技术

随着云计算的不断发展，容器技术与微服务技术在构建大规模分布式应用中大量应用，应用服务化拆分后存在大量服务。在应用***实际运行中，部署服务时，为了确保用户访问请求过来时，能成功访问，需要将服务配置于始终启动状态。而大量服务一直处于启动状态会占用大量资源，使***存在资源利用率低的问题。

发明内容

本发明提供了服务管理方法、装置、电子设备、存储介质，以解决现有技术中应用***的所有服务始终处于启动状态，致使***的资源利用率较低的缺陷。

具体地，本发明是通过如下技术方案实现的：

第一方面，提供一种服务管理方法，应用于通过微服务架构构建的应用***，所述应用***包含多个服务，所述多个服务中的至少一个服务处于停止状态；

所述服务管理方法，包括：

监听并拦截针对目标服务的访问请求；

识别所述目标服务的当前状态；

若所述目标服务的当前状态为启动状态，则放行所述访问请求；

若所述目标服务的当前状态为停止状态，则启动所述目标服务后，放行所述访问请求。

可选地，若所述目标服务存在依赖服务且所述依赖服务的当前状态为停止状态，所述服务管理方法还包括：

预启动所述依赖服务。

可选地，

所述依赖服务为预先配置的与所述目标服务具有依赖关系的服务；

和/或，所述依赖服务为启动概率高于概率阈值的服务，所述启动概率为根据所述应用***的历史运行数据统计的所述目标服务启动后其他的服务启动的概率。

可选地，启动所述目标服务和所述依赖服务之前，所述服务管理方法还包括：

将所述目标服务和所述依赖服务预先放入预加载资源池。

可选地，所述服务管理方法还包括：

若经过预设时长未监听到针对已启动的所述目标服务的下一访问请求，则停止所述目标服务。

可选地，所述目标服务的每个运行周期包括：空闲时间段和工作时间段；

所述服务管理方法还包括：

在所述空闲时间段内，停止已启动的所述目标服务；

在所述工作时间段内，启动已停止的所述目标服务。

可选地，所述服务管理方法还包括：

预先配置声明文件，所述声明文件用于确定需要状态切换的服务；

所述配置声明文件包括以下信息中的至少一种：所述访问请求中的访问路径与服务的关系、服务与依赖服务的关系、服务的启停时间。

可选地，预启动当前状态为停止状态的服务对应的容器。

可选地，所述服务管理方法还包括：

若启动所述目标服务未成功，则重复启动所述目标服务；

若重复启动所述目标服务的次数达到次数阈值或重复启动所述目标服务的时长达到时长阈值，则停止所述目标服务的重复启动并生成故障信息。

第二方面，提供一种服务管理装置，应用于通过微服务架构构建的应用***，所述应用***包含多个服务，所述多个服务中的至少一个服务处于停止状态；

所述服务管理装置，包括：

监听模块，用于在所述微服务架构的网关监听针对目标服务的访问请求；

拦截模块，用于拦截所述访问请求；

识别模块，用于识别所述目标服务的当前状态；

控制模块，在所述目标服务为停止状态时，用于启动所述目标服务；

放行模块，在所述目标服务为启动状态时，用于放行所述访问请求。

第三方面，提供一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时实现第一方面任一项所述的服务管理方法。

第四方面，提供一种计算机可读存储介质，其上存储有计算机程序，所述计算机程序被处理器执行时实现第一方面所述的服务管理方法的步骤。

本发明的实施例提供的技术方案可以包括以下有益效果：

无需将应用***的所有服务始终处于启动状态，可控制部分不常用的服务处于常停止状态，仅在有需要的时候启动该服务，从而***不会因为大量服务一直处于启动状态占用大量资源。

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

附图说明

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

图1是本发明一示例性实施例示出的一种通过微服务架构构建的应用***的结构示意图；

图2是本发明一示例性实施例示出的一种服务管理方法的流程图；

图3是本发明一示例性实施例示出的另一种服务管理方法的流程图；

图4是本发明一示例性实施例示出的一种服务管理装置的模块示意图；

图5是本发明一示例性实施例示出的一种电子设备的结构示意图。

具体实施方式

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

在本发明使用的术语是仅仅出于描述特定实施例的目的，而非旨在限制本发明。在本发明和所附权利要求书中所使用的单数形式的“一种”、“所述”和“该”也旨在包括多数形式，除非上下文清楚地表示其他含义。还应当理解，本文中使用的术语“和/或”是指并包含一个或多个相关联的列出项目的任何或所有可能组合。

应当理解，尽管在本发明可能采用术语第一、第二、第三等来描述各种信息，但这些信息不应限于这些术语。这些术语仅用来将同一类型的信息彼此区分开。例如，在不脱离本发明范围的情况下，第一信息也可以被称为第二信息，类似地，第二信息也可以被称为第一信息。取决于语境，如在此所使用的词语“如果”可以被解释成为“在……时”或“当……时”或“响应于确定”。

随着云计算的不断发展，容器技术与微服务技术在构建大规模分布式应用***中的应用越来越多。微服务技术使用的微服务架构将应用程序划分为多个小的服务进行独立开发，服务与服务之间通过轻量级的通信机制实现解耦合。这些服务以具体业务进行构建，并通过自动化部署机制进行服务的部署。容器技术可以屏蔽应用架构和依赖的差异，为微服务架构***的实现、部署和维护提供可行的解决方案。

图1是本发明一示例性实施例示出的一种通过微服务架构构建的应用***的结构示意图。参见图1，对应用***进行应用服务化拆分后，得到大量服务，每个服务部署于相应的容器中。可以但不限于采用kubernetes(容器技术采样的一种容器调度平台，简称K8s)实现服务的部署，K8s使用yaml文件描述部署信息。K8s作为容器的管理中心，对所有的容器的生命周期进行管理。

微服务架构一般通过API网关1代理请求，API网关1实时监听客户端2发送的针对服务的访问请求，应用***根据监听到的访问请求，以及预先配置的控制策略调用K8s，以控制对应的容器对服务进行状态切换，实现服务的按需启停管理。从而，在服务有访问需求的情况下，使其处于启动状态；在服务无访问请求的情况下，使其处于停止状态，以减小***的资源占用率。

下面结合图1对本发明的服务管理实施例进行详细描述。

图2是本发明一示例性实施例示出的一种服务管理方法的流程图，方法应用于控制器，参见图2，方法包括以下步骤：

步骤201、监听并拦截针对服务的访问请求。

步骤201中，控制器通过微服务架构的API网关监听用户发送的访问请求，并调用***拦***问请求。可以但不限于在API网关中预先配置声明文件，该声明文件可以但不限于包括以下信息：访问请求中的访问路径与服务的关系、服务的启停时间等，用于供K8s确定需要状态切换的服务、该服务的启动时长等。

下面是声明文件中针对服务b的配置描述的一个例子：

接收到针对服务b的访问请求，触发服务b的启动，服务b运行5分钟后停止。

步骤202、在监听到针对目标服务的访问请求的情况下，调用***判断目标服务的当前状态。

其中，目标服务为多个服务中监听到客户端发送的访问请求的服务。

在一个实施例中，控制器调用***，以使***尝试与目标服务建立连接，如果连接失败，则确定该目标服务的当前状态为停止状态；如果连接成功，则确定该目标服务的当前状态为启动状态。其中，***可以是网关中的一个功能模块，也可以是独立于网关的一个功能模块。

步骤202中，若判断目标服务的当前状态为停止状态，此时目标服务不能响应访问请求，则执行步骤203。

步骤203、将目标服务的状态切换为启动状态。然后执行步骤204。

步骤203中，在进行服务的状态切换时，控制器根据声明文件确定需要启动的服务，并调用K8s，K8s根据部署信息确定与目标服务对应的容器，并控制该容器实现将目标服务的停止状态切换为启动状态。

如果容器未将目标服务的停止状态切换为启动状态，也即如果目标服务未启动，则可重复对目标服务进行状态切换，尝试拉起服务；若经过预设时长或重复次数达到次数阈值，目标服务仍未被拉起，说明该目标服务可能出现故障，无法启动，K8s停止控制与该目标服务对应的容器启动目标服务，并发出故障信息至控制器，以使控制器根据需要决定是否关停该服务，以释放服务占用的资源。此处关停服务与上述将服务切换至停止状态不同，若一服务被关停，容器将无法随意切换该服务的状态。

步骤202中，若判断目标服务的当前状态为启动状态，此时目标服务能响应访问请求，则执行步骤204。

步骤204、控制***放行访问请求。

步骤204中，***放行针对目标服务的访问请求，以使目标服务响应访问请求，从而用户通过客户端能够实现对该目标服务的访问。

本实施例中，在监听到目标服务的访问请求后，对访问请求进行拦截，避免了因目标服务未启动导致的访问请求得不到响应，用户访问失败；在目标服务启动后，放行访问请求，使用户能够成功访问目标服务。

在另一个实施例中，如果经过预设时长(例如，10分钟)，未监听到针对已启动的目标服务的下一访问请求，则将该目标服务的状态切换为停止状态，以释放该目标服务的资源占用，直至监听到该目标服务的下一访问请求，参照步骤203，将目标服务的状态切换为启动状态。

在另一个实施例中，根据服务的历史运行数据，可将服务的每个运行周期(运行周期根据服务的运行规律确定，可以但不限于是一天、一周或一个月等)划分为空闲时间段和工作时间段。所谓工作时间段即为有访问需求的时间段，在该时间段内将服务的状态切换为启动状态，以确保用户能够成功访问服务；所谓空闲时间段即为无访问需求的时间段，在该时间段内将服务的运行状态切换为停止状态，以释放服务占用的资源。举例来说，若对历史运行数据分析得到服务a，在每天的2：00～6：00无访问请求，其余时间段有访问请求，则可在2：00～6：00(空闲时间段)将服务a的状态切换为停止状态，在每天中除2：00～6：00之外的其余时间段(工作时间段)将服务a的状态切换为启动状态。可以理解的，每个服务的运行周期不同，对运行周期的时间段划分也不相同，根据每个服务的实际运行规律确定。

下面以用户针对服务a(目标服务)发出访问请求为例，对本实施例的具体实现过程作进一步说明：

用户通过客户端向应用***发送访问服务a的访问请求，控制器通过网关在监听到该访问请求时，调用***拦***问请求并识别服务a的当前状态。若服务a的当前状态为启动状态，则控制器控制***放行访问请求。若服务a的当前状态为停止状态，控制器根据声明文件识别出需要启动的服务，并调用k8s，以使k8s控制对应的容器将服务a的停止状态切换为启动状态。等服务a启动后，控制器控制***放行该访问请求，以通过访问请求路径建立访问请求与服务a之间的关系。

本实施例中，无需将应用***的所有服务始终处于启动状态，可控制部分服务处于常停止状态，仅在有需要的时候启动该服务，使其处于启动状态，从而***不会因为大量无访问需求的服务一直处于启动状态占用大量资源。

需要说明的是，如果将与处于停止状态的服务对应的容器的状态切换为停止运行状态，在启动服务的过程中需要先启动容器，会使得整体启动速度较慢，且容器启动时占用的资源很少，从而可使容器始终处于运行状态，也即即便服务处于停止状态时，与其对应的容器也处于运行状态，从而可以提高启动速度。

在图2示出的一种服务管理方法的流程图的基础上，图3示出了本发明一示例性实施例的另一种服务管理方法的流程图。本实施例中，在目标服务具有依赖服务的情况下，还预先启动目标服务的依赖服务。参见图3，方法包括以下步骤：

步骤301、监听并拦截针对服务的访问请求。

与步骤201类似的，步骤301中，控制器通过API网关实时监听访问请求，并调用***拦***问请求。可以但不限于在API网关中配置声明文件，该声明文件可以但不限于包括以下信息：访问请求中的访问路径与服务的关系、服务与依赖服务的关系、服务的启停时间等。其中，依赖服务为与服务有依赖关系的服务，例如，服务a被访问后，服务b和服务c有很大概率被访问，则服务b和服务c为服务a的依赖服务。其中，服务的依赖服务可以由程序员预先根据应用***的业务逻辑手动写入于声明文件中。服务的依赖服务也可以通过应用***的历史运行数据，通过计算模型给出，具体的，根据历史运行数据统计某个服务启动后其他服务启动的启动概率，将启动概率高于概率阈值的其他服务确定为该服务的依赖服务。通过声明文件可以很直观的看出服务与依赖服务之间的关系，以及对应的启动时间和停止时间。

下面是声明文件中针对服务a及其依赖服务的配置描述的一个例子：

接收到针对服务a或服务b的访问请求，触发服务a的启动，启动服务a的时候会触发服务a的依赖服务c启动。

步骤302、在监听到针对目标服务的访问请求的情况下，调用***判断目标服务的当前状态。

其中，步骤302的具体实现方式与步骤202类似，此处不再赘述。

步骤302中，若目标服务的当前状态为停止状态，则执行步骤303。

步骤303、将目标服务及其依赖服务的状态切换为启动状态。然后执行步骤304。

本实施例中，在将目标服务的状态切换为启动状态的同时，将其依赖服务的状态也切换为启动状态，实现依赖服务的预启动，从而可以提高用户的访问效率。举例来说，用户访问服务a，那么下一步很有可能再访问依赖服务b和依赖服务c，预先启动依赖服务b和依赖服务c，使得用户访问服务a后，如果再访问服务b和服务c，由于服务b和服务c已提前启动，则用户可以快速访问到服务b和服务c，提高了用户的访问效率。

步骤303中，服务状态的具体切换过程与步骤303类似，此处不再赘述。

步骤302中，若目标服务的当前状态为启动状态，则执行步骤304。

步骤304、放行访问请求。从而客户端可以访问对应的服务。

本实施例中，在实际请求之前，将依赖服务拉起，从而实现了依赖服务的快速响应。

下面以用户针对服务a(目标服务)发出访问请求，声明文件中配置服务a存在依赖服务b为例，对本实施例的具体实现过程作进一步说明：

用户通过客户端向应用***发送访问服务a的访问请求，控制器通过网关在监听到该访问请求时，调用***拦***问请求并识别服务a及服务b的当前状态。若服务a的当前状态为启动状态，则控制器控制***放行访问请求；若服务b的当前状态为停止状态，控制器则调用k8s，以控制对应的容器预启动服务b。若服务a和服务b的当前状态均为停止状态，控制器则调用k8s，以控制对应的容器将服务a和服务b的停止状态切换为启动状态。等服务a启动后，控制器控制***放行该访问请求。

在一个实施例中，目标服务和依赖服务可以预先放入预加载资源池，从而保证目标服务和依赖服务之间可以快速进行调度。例如，使用list(预加载队列)实现预加载资源池的对应功能。在通过容器启动服务之前，根据声明文件确定需要启动的目标服务及其依赖服务，并加入list，容器依次启动list中服务。

在另一个实施例中，依赖服务不限于与目标服务同时进行状态切换，可以在目标服务的状态切换为启动状态后，再将依赖服务的状态切换为启动状态。从而避免无效的动作，例如，若目标服务未能成功切换为启动状态，则无需切换依赖服务的状态。

与前述服务管理方法实施例相对应，本发明还提供了服务管理装置的实施例。

图4示出了本发明一示例性实施例的一种服务管理装置的模块示意图，应用于通过微服务架构构建的应用***，服务管理装置可以但不限于通过控制器实现相应的功能，所述应用***包含多个服务，所述多个服务中的至少一个服务处于停止状态。参见图4，服务管理装置包括：监听模块41、拦截模块42、识别模块43、控制模块44和放行模块45。

监听模块41用于在所述微服务架构的网关监听针对目标服务的访问请求；

拦截模块42用于拦截所述访问请求；

识别模块43用于识别所述目标服务的当前状态；

控制模块44用于在所述目标服务为停止状态时，启动所述目标服务；

放行模块45用于在所述目标服务为启动状态时，放行所述访问请求。

具体的，控制模块44可通过调用K8s实现对应服务的状态的切换。

对于装置实施例而言，由于其基本对应于方法实施例，所以相关之处参见方法实施例的部分说明即可。以上所描述的装置实施例仅仅是示意性的，其中所述作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本公开方案的目的。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

图5示出了本发明一示例性实施例的一种电子设备的结构示意图，图中示出了适于用来实现本发明实施方式的示例性电子设备50的框图。图5显示的电子设备50仅仅是一个示例，不应对本发明实施例的功能和使用范围带来任何限制。

如图5所示，电子设备50可以以通用计算设备的形式表现，例如其可以为服务器设备。电子设备50的组件可以包括但不限于：上述至少一个处理器51、上述至少一个存储器52、连接不同***组件(包括存储器52和处理器51)的总线53。

总线53包括数据总线、地址总线和控制总线。

存储器52可以包括易失性存储器，例如随机存取存储器(RAM)521和/或高速缓存存储器522，还可以进一步包括只读存储器(ROM)523。

存储器52还可以包括具有一组(至少一个)程序模块524的程序工具525(或实用工具)，这样的程序模块524包括但不限于：操作***、一个或者多个应用程序、其它程序模块以及程序数据，这些示例中的每一个或某种组合中可能包括网络环境的实现。

处理器51通过运行存储在存储器52中的计算机程序，从而执行各种功能应用以及数据处理，例如上述任一实施例提供的方法。

电子设备50也可以与一个或多个外部设备54(例如键盘、指向设备等)通信。这种通信可以通过输入/输出(I/O)接口55进行。并且，模型生成的电子设备50还可以通过网络适配器56与一个或者多个网络(例如局域网(LAN)，广域网(WAN)和/或公共网络，例如因特网)通信。如图所示，网络适配器56通过总线53与模型生成的电子设备50的其它模块通信。应当明白，尽管图中未示出，可以结合模型生成的电子设备50使用其它硬件和/或软件模块，包括但不限于：微代码、设备驱动器、冗余处理器、外部磁盘驱动阵列、RAID(磁盘阵列)***、磁带驱动器以及数据备份存储***等。

应当注意，尽管在上文详细描述中提及了电子设备的若干单元/模块或子单元/模块，但是这种划分仅仅是示例性的并非强制性的。实际上，根据本发明的实施方式，上文描述的两个或更多单元/模块的特征和功能可以在一个单元/模块中具体化。反之，上文描述的一个单元/模块的特征和功能可以进一步划分为由多个单元/模块来具体化。

以上所述仅为本发明的较佳实施例而已，并不用以限制本发明，凡在本发明的精神和原则之内，所做的任何修改、等同替换、改进等，均应包含在本发明保护的范围之内。

Claims (12)

1.一种服务管理方法，其特征在于，应用于通过微服务架构构建的应用***，所述应用***包含多个服务，所述多个服务中的至少一个服务处于停止状态；

所述服务管理方法，包括：

监听并拦截针对目标服务的访问请求；

识别所述目标服务的当前状态；

若所述目标服务的当前状态为启动状态，则放行所述访问请求；

若所述目标服务的当前状态为停止状态，则启动所述目标服务后，放行所述访问请求。

2.如权利要求1所述的服务管理方法，其特征在于，若所述目标服务存在依赖服务且所述依赖服务的当前状态为停止状态，所述服务管理方法还包括：

预启动所述依赖服务。

3.如权利要求2所述的服务管理方法，其特征在于，

所述依赖服务为预先配置的与所述目标服务具有依赖关系的服务；

和/或，所述依赖服务为启动概率高于概率阈值的服务，所述启动概率为根据所述应用***的历史运行数据统计的所述目标服务启动后其他的服务启动的概率。

4.如权利要求2所述的服务管理方法，其特征在于，启动所述目标服务和所述依赖服务之前，所述服务管理方法还包括：

将所述目标服务和所述依赖服务预先放入预加载资源池。

5.如权利要求1所述的服务管理方法，其特征在于，所述服务管理方法还包括：

若经过预设时长未监听到针对已启动的所述目标服务的下一访问请求，则停止所述目标服务。

6.如权利要求1所述的服务管理方法，其特征在于，所述目标服务的每个运行周期包括：空闲时间段和工作时间段；

所述服务管理方法还包括：

在所述空闲时间段内，停止已启动的所述目标服务；

在所述工作时间段内，启动已停止的所述目标服务。

7.如权利要求1所述的服务管理方法，其特征在于，所述服务管理方法还包括：

预先配置声明文件，所述声明文件用于确定需要状态切换的服务；

所述配置声明文件包括以下信息中的至少一种：所述访问请求中的访问路径与服务的关系、服务与依赖服务的关系、服务的启停时间。

8.如权利要求7所述的服务管理方法，其特征在于，预启动当前状态为停止状态的服务对应的容器。

9.如权利要求1所述的服务管理方法，其特征在于，所述服务管理方法还包括：

若启动所述目标服务未成功，则重复启动所述目标服务；

若重复启动所述目标服务的次数达到次数阈值或重复启动所述目标服务的时长达到时长阈值，则停止所述目标服务的重复启动并生成故障信息。

10.一种服务管理装置，其特征在于，应用于通过微服务架构构建的应用***，所述应用***包含多个服务，所述多个服务中的至少一个服务处于停止状态；

所述服务管理装置，包括：

监听模块，用于在所述微服务架构的网关监听针对目标服务的访问请求；

拦截模块，用于拦截所述访问请求；

识别模块，用于识别所述目标服务的当前状态；

控制模块，在所述目标服务为停止状态时，用于启动所述目标服务；

放行模块，在所述目标服务为启动状态时，用于放行所述访问请求。

11.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述计算机程序时实现权利要求1至9任一项所述的服务管理方法。

12.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，所述计算机程序被处理器执行时实现权利要求1至9任一项所述的服务管理方法的步骤。

Images