服务管理方法、装置、设备、存储介质及程序产品与流程

1.本发明涉及计算机技术领域，尤其涉及一种服务管理方法、装置、设备、存储介质及程序产品。


背景技术：

2.现有的微服务框架中，生产者服务需要在第三方的服务注册中心注册其服务接口信息，消费者服务通过访问服务注册中心获取生产者服务的服务接口信息，来发现和调用生产者服务。
3.在实现本发明过程中，发明人发现现有技术中至少存在如下问题：现有的微服务框架中，需要引入第三方中间件作为服务注册中心对服务接口信息进行存储，如果服务注册中心出现异常，将直接影响服务的使用。


技术实现要素：

4.本发明提供一种服务管理方法、装置、设备、存储介质及程序产品，用以解决现有的微服务框架中，需要引入第三方中间件作为服务注册中心对服务信息进行存储，如果服务注册中心出现异常，将直接影响服务的使用的问题。
5.本发明的第一个方面是提供一种服务管理方法，应用于集群中的主节点，所述集群包括主节点、多个工作节点和存储系统，在所述工作节点上的容器内部署有服务，所述方法包括：
6.接收第一工作节点上第一容器发送的服务注册请求，所述服务注册请求包括所述第一容器内部署的服务的注册信息；
7.将所述第一容器内部署的服务的注册信息，存储至所在集群的存储系统中。
8.本发明的第二个方面是提供一种服务管理方法，应用于集群中的工作节点，所述集群包括主节点、多个工作节点和存储系统，每个所述工作节点上的容器内部署有服务，包括：
9.响应于第一工作节点上第一容器的启动指令，通过所述第一容器向主节点发送服务注册请求，所述服务注册请求包括所述第一容器内部署的服务的标签信息和地址信息，所述服务注册请求用于将所述第一容器内部署的服务的标签信息和访问地址信息存储至所在集群的存储系统中。
10.本发明的第三个方面是提供一种服务管理装置，应用于集群中的主节点，所述集群包括主节点、多个工作节点和存储系统，在所述工作节点上的容器内部署有服务，所述装置包括：
11.注册模块，用于接收第一工作节点上第一容器发送的服务注册请求，所述服务注册请求包括所述第一容器内部署的服务的注册信息；
12.所述注册模块还用于将所述第一容器内部署的服务的注册信息，存储至所在集群的存储系统中。
13.本发明的第四个方面是提供一种服务管理装置，应用于集群中的工作节点，所述集群包括主节点、多个工作节点和存储系统，每个所述工作节点上的容器内部署有服务，所述装置包括：
14.注册模块，用于响应于第一工作节点上第一容器的启动指令，通过所述第一容器向主节点发送服务注册请求，所述服务注册请求包括所述第一容器内部署的服务的标签信息和地址信息，所述服务注册请求用于将所述第一容器内部署的服务的标签信息和访问地址信息存储至所在集群的存储系统中。
15.本发明的第五个方面是提供一种服务管理设备，包括：
16.处理器，存储器，以及存储在所述存储器上并可在所述处理器上运行的计算机程序；其中，所述处理器运行所述计算机程序时实现如上述任一方面所述的方法。
17.本发明的第六个方面是提供一种计算机可读存储介质，所述计算机可读存储介质中存储有计算机程序，所述计算机程序被处理器执行时实现如上述任一方面所述的方法。
18.本发明的第七个方面是提供一种计算机程序产品，包括计算机程序，所述计算机程序在被处理器执行时实现根据上述任一方面所述的方法。
19.本发明提供的服务管理方法、装置、设备、存储介质及程序产品，通过将服务部署在集群中工作节点的容器内，在容器启动时，通过容器向主节点发送包含待注册服务的注册信息的服务注册请求，主节点将待注册服务的注册信息存储至集群的存储系统中，实现服务的注册机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。
附图说明
20.图1为本发明实施例提供的集群架构示意图；
21.图2为本发明实施例提供的服务注册发现的框架图；
22.图3为本发明实施例提供的服务管理方法流程图；
23.图4为本发明另一实施例提供的服务管理方法流程图；
24.图5为本发明实施例提供的etcd的架构示意图；
25.图6为本发明实施例提供的服务注册和发现的总体流程的示意图；
26.图7为本发明另一实施例提供的服务管理方法流程图；
27.图8为本发明实施例提供的服务管理装置的结构示意图；
28.图9为本发明另一实施例提供的服务管理装置的结构示意图；
29.图10为本发明另一实施例提供的服务管理装置的结构示意图；
30.图11为本发明另一实施例提供的服务管理装置的结构示意图；
31.图12为本发明实施例提供的服务管理设备的结构示意图。
32.通过上述附图，已示出本发明明确的实施例，后文中将有更详细的描述。这些附图和文字描述并不是为了通过任何方式限制本发明构思的范围，而是通过参考特定实施例为本领域技术人员说明本发明的概念。
具体实施方式
33.这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例
中所描述的实施方式并不代表与本发明相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本发明的一些方面相一致的装置和方法的例子。
34.首先对本发明所涉及的名词进行解释：
35.kubernetes：简称k8s，是一个开源的用于管理云平台中多个主机上的容器化的应用。
36.etcd：是一个高可用的key
‑
value存储系统，是kubernetes提供的默认的存储系统，主要用于分享配置和服务发现。
37.镜像：一种文件存储形式，一个磁盘上的数据在另一个磁盘上存在完全相同的副本即为镜像。
38.负载均衡：通常用于将工作负载分布到多个服务器来提高网站、应用、数据库的性能和可靠性。
39.服务平台：是基于微服务框架研发的用于提供服务及其接口的平台。
40.jsf(jingdong service framework，杰夫)：基于远程过程调用(remote procedure call，缩写rpc)演进研发的一种高性能服务框架。
41.jsf网关是jsf对于http请求的入口，在服务消费方和服务提供方之间增加一层，服务消费方通过jsf网关间接访问目标服务。
42.jdos是jingdong datacenter operating system的简称，负责软件定义的数据中心管理，提供物理机，虚拟机和容器的统一管理、灵活的网络互连、可靠的块存储。
43.此外，术语“第一”、“第二”等仅用于描述目的，而不能理解为指示或暗示相对重要性或者隐含指明所指示的技术特征的数量。在以下各实施例的描述中，“多个”的含义是两个以上，除非另有明确具体的限定。
44.现有的微服务框架(如jsf)中，生产者服务需要在第三方的服务注册中心注册其服务接口信息，消费者服务通过访问服务注册中心获取生产者服务的服务接口信息，来发现和调用生产者服务。
45.在实现本发明过程中，发明人发现现有技术中至少存在如下问题：现有的微服务框架中，需要引入第三方中间件作为服务注册中心对服务接口信息进行存储，如果服务注册中心出现异常，将直接影响服务的使用。由于服务注册中心是采用特定编程语言实现的，无法支持跨语言的交互，开发人员需要为每种不同语言的服务专门定制与服务注册中心交互的软件开发工具包(software development kit，简称sdk)，开发周期长，耗费大量人力及设备资源；另外，在服务消费者和服务生产者之间设置有服务网关，服务消费者通过服务网关使用dns访问服务生产者，需要配置路由器和负载均衡器，导致服务之间远程过程调用(remote procedure call，简称rpc)的通信性能差。
46.本发明提供的服务管理的方法，旨在解决现有技术的如上技术问题。
47.本发明具体的应用于如图1所示的实现微服务的发现和注册机制的容器化集群，该集群可以是kubernetes等容器化集群，图1中以kubernetes为例，对实现微服务的发现和注册机制的容器化集群的架构进行示例性地说明，如图1所示，集群包括主节点(如图1所示的master节点)、多个工作节点(图1以4个worker节点为例)和存储系统。其中，每个工作节点上部署有一个容器，每个容器中可以部署一个或者多个服务(可以包括消费者服务和/或生产者服务)，容器中的服务通过容器与主节点进行通信。存储系统可以是集群框架中包括
的用于存储集群数据的组件，例如kubernetes中的etcd。
48.另外，主节点上可以包括接口服务器(api server)、控制器(controller)、选择器等组件，不同的组件用于实现不同的功能。其中，接口服务器(api server)用于实现主节点与工作节点上容器之间的交互，实现容器内服务的注册和发现机制。主节点上其他组件无法直接与工作节点上的容器进行交互。控制器为可选组件，用于自动获取各个容器的状态信息，并自动清除已掉线的容器的注册信息。选择器为可选组件，用于基于能够提供目标服务的容器的负载情况，基于负载均衡策略确定提供目标服务的容器。
49.可选地，本发明的方法可以基于通过jdos容器部署基础设施的kubernetes，实现服务的注册发现机制。如图2所示，生产者服务在kubernetes中进行服务注册，消费者服务在kubernetes中进行服务发现。
50.下面以具体地实施例对本发明的技术方案以及本技术的技术方案如何解决上述技术问题进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例中不再赘述。下面将结合附图，对本发明的实施例进行描述。
51.图3为本发明实施例提供的服务管理方法流程图。如图3所示，该方法具体步骤如下：
52.步骤s101、响应于第一工作节点上第一容器的启动指令，通过第一容器向主节点发送服务注册请求，服务注册请求包括第一容器内部署的服务的注册信息，服务注册请求用于将第一容器内部署的服务的注册信息存储至所在集群的存储系统中。
53.其中，第一工作节点可以是集群上的任意一个工作节点，第一容器为第一工作节点上的容器，也即可以是集群中服务所在的任一容器，可以用第一服务指代第一容器内部署的服务。第一容器内可以部署一个或者多个服务，其中可以包括消费者服务和/或生产者服务。
54.注册信息包括服务的标签信息和服务所在容器的资源信息。其中，服务的标签信息可以包括服务接口信息、别名、服务类别(包括消费者服务和生产者服务两种类型)等需要进行注册的服务的相关信息，通过标签信息可以唯一确定一个服务。
55.服务所在容器的资源信息至少包括服务所在容器的访问地址信息，也即服务的访问地址信息，服务所在容器的资源信息还可以包括容器的状态信息、名称、使用的通信协议，预设超时时间等容器及容器所在工作节点的相关信息。容器的状态信息可以包括健康状态、非健康状态和待删除状态。
56.本实施例中，将服务的注册信息保存到集群的存储系统中。
57.响应于第一工作节点上第一容器的启动指令，通过第一容器向主节点发送服务注册请求，使得主节点将第一容器内部署的服务的注册信息存储到集群的存储系统中，实现服务的注册机制。
58.步骤s102、主节点接收第一工作节点上第一容器发送的服务注册请求，服务注册请求包括第一容器内部署的服务的注册信息。
59.主节点接收第一工作节点通过第一容器发送的服务注册请求，并获取到第一容器中的待注册服务的注册信息。
60.步骤s103、主节点将第一容器内部署的服务的注册信息，存储至所在集群的存储系统中。
61.主节点在获取到第一容器内部署的服务的注册信息之后，将第一容器内部署的服务的注册信息存储至所在集群的存储系统中，实现第一容器内部署的服务端注册。
62.本发明实施例通过将服务部署在集群中工作节点的容器内，在容器启动时，通过容器向主节点发送包含待注册服务的注册信息的服务注册请求，主节点将待注册服务的注册信息存储至集群的存储系统中，实现服务的注册机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。
63.图4为本发明另一实施例提供的服务管理方法流程图。在上述图3所示实施例的基础上，本实施例中，当第一容器内的第一服务需要调用第二服务时，第一服务所在工作节点通过第一容器向主节点发送服务发现请求，服务发现请求包含第二服务的标签信息；主节点接收第一容器发送的服务发现请求，服务发现请求用于发现第二服务，服务发现请求包括第二服务的标签信息；根据第二服务的标签信息，从存储系统获取第二服务的访问地址信息；并向第一容器发送第二服务的访问地址信息；工作节点通过第一容器接收主节点发送的第二服务的访问地址信息；根据第二服务的访问地址信息，调用第二服务。本实施例中基于图1所示的容器化集群架构为例，对服务管理方法的流程进行详细地说明。
64.如图4所示，该方法具体步骤如下：
65.步骤s201、响应于第一工作节点上第一容器的启动指令，通过第一容器向主节点发送服务注册请求，服务注册请求包括第一容器内部署的服务的标签信息和地址信息，服务注册请求用于将第一容器内部署的服务的标签信息和访问地址信息存储至所在集群的存储系统中。
66.其中，第一工作节点可以是集群上的任意一个工作节点，第一容器为第一工作节点上的容器，也即可以是集群中服务所在的任一容器，可以用第一服务指代第一容器内部署的服务。第一容器内可以部署一个或者多个服务，其中可以包括消费者服务和/或生产者服务。
67.注册信息包括服务的标签信息和服务所在容器的资源信息。其中，服务的标签信息可以包括服务接口信息、别名、服务类别(包括消费者服务和生产者服务两种类型)等需要进行注册的服务的相关信息，通过标签信息可以唯一确定一个服务。
68.服务所在容器的资源信息至少包括服务所在容器的访问地址信息，也即服务的访问地址信息，服务所在容器的资源信息还可以包括容器的状态信息、名称、使用的通信协议，预设超时时间，预设的策略等容器及容器所在工作节点的相关信息。容器的状态信息可以包括健康状态、非健康状态和待删除状态，能够表示容器的健康状况。
69.示例性地，用于存储服务的注册信息的存储系统可以是kubernetes中的etcd，无需增加额外的存储软件设备。etcd是一种key
‑
value存储系统。服务的注册信息表示为key
‑
value的形式，其中key为服务的标签信息，value为服务所在容器的资源信息。存储系统用于存储所有已注册服务的注册信息。
70.在kubernetes中，etcd集群所起到的作用主要有两个：一个是持久化的键值存储系统，第二个是分布式系统数据一致性服务提供者。etcd中存储的容器相关信息包括健康状况、容器资源、名称、地址信息等。如图5所示，etcd集群通常包括网络层、raft模块、存储层和状态机。一个容器的请求发送过来，会经由网络层转发给存储层进行具体的事务处理，如果涉及容器(或工作节点)状态信息的更新，则交给raft模块进行仲裁和日志的记录，然
后再同步给别的etcd节点，只有当半数以上的etcd节点确认了该容器状态的修改之后，才会进行数据的持久化。
71.响应于第一工作节点上第一容器的启动指令，通过第一容器向主节点的接口服务器发送服务注册请求。主节点通过接口服务器将第一容器内部署的服务的注册信息存储到集群的存储系统中，实现服务的注册机制。
72.本实施例中，服务注册请求中所包含的服务的注册信息可以包括第一容器内部署的所有服务的注册信息，或者服务注册请求中所包含的服务的注册信息可以只包括第一容器内部署的所有服务中生产者服务的注册信息。
73.步骤s202、主节点接收第一工作节点上第一容器发送的服务注册请求，服务注册请求包括第一容器内部署的注册信息。
74.该步骤中，主节点通过接口服务器，接收第一容器发送的服务注册请求，并获取到第一容器中的待注册服务的注册信息。
75.步骤s303、主节点将第一容器内部署的服务的注册信息，存储至所在集群的存储系统中。
76.主节点在获取到第一容器内部署的服务的注册信息之后，通过接口服务器，将第一容器内部署的服务的注册信息存储至所在集群的存储系统中，实现第一容器内部署的服务端注册。
77.本实施例中，对于已注册的第二服务，在需要调用第二服务时，可以通过步骤s204
‑
s209来发现第二服务，实现服务的发现机制。
78.步骤s204、当第一容器内的第一服务需要调用第二服务时，通过第一容器向主节点发送服务发现请求，服务发现请求包含第二服务的标签信息。
79.该步骤中，在第一工作节点上第一容器内部署的第一服务需要调用第二服务时，第一服务为消费者服务，第二服务为生产者服务，通过第一容器向主节点的接口服务器发送服务发现请求。
80.本实施例中，在需要通过第一容器向主节点发送请求信息时，通过第一容器获取主节点的地址信息；根据地址信息，向主节点的发送请求信息。
81.具体地，在需要通过第一容器向主节点发送请求信息时，通过第一容器获取主节点的接口服务器的地址信息；根据接口服务器的地址信息，向主节点的接口服务器发送请求信息。
82.可选地，通过第一容器获取主节点的地址信息，包括：
83.通过在第一容器内运行命令行工具，并执行对应命令，获取主节点的地址信息。
84.具体地，通过在第一容器内运行命令行工具，并执行对应命令，获取主节点的接口服务器的地址信息。
85.示例性地，接口服务器是kubernetes中部署在主节点上的一个服务(service)，服务名称就是“kubernetes”，它的ip地址是一个cluster ip地址，是cluster ip地址池里的第1个地址，服务的端口是https端口443。kubectl是kubernetes提供的命令行工具，可以通过kubectl以命令行交互的方式对kubernetes的接口服务器进行操作，通信协议可以使用http或json。通过kubectl向发送相应的http请求，请求由kubernetes的接口服务器接收、处理并将处理结果反馈给kubectl。本实施例中，可以通过在第一容器内运行该命令行工
具，并运行对应命令，来获取接口服务器的ip地址和端口。
86.步骤s205、主节点接收第一容器发送的服务发现请求，服务发现请求用于发现第二服务，服务发现请求包括第二服务的标签信息。
87.主节点通过接口服务器接收第一容器发送的服务发现请求，并可以获取到待发现的第二服务的标签信息。
88.步骤s206、主节点根据第二服务的标签信息，从存储系统获取第二服务的访问地址信息。
89.一种可选的实施方式中，该步骤可以采用如下方式实现：
90.主节点向存储系统发送服务信息请求，服务信息请求包含第二服务的标签信息；存储系统根据第二服务的标签信息确定第二服务的访问地址信息，并反馈给主节点。主节点接收存储系统反馈的第二服务的访问地址信息。
91.其中，存储系统反馈的第二服务的访问地址信息，包括用于向第一容器内的第一服务提供第二服务的第二容器的ip地址和端口号。
92.本实施例中，主节点与存储系统之间的交互，也是通过接口服务器与存储系统进行交互。具体地，主节点通过接口服务器向存储系统发送服务信息请求，服务信息请求包含第二服务的标签信息；存储系统根据第二服务的标签信息确定第二服务的访问地址信息，并反馈给主节点的接口服务器。主节点通过接口服务器接收存储系统反馈的第二服务的访问地址信息。
93.进一步地，为了提高服务的延迟，提高服务的使用效率，可以将一个服务同时部署在多个工作节点的容器内。在发现第二服务时，多个工作节点的容器内均部署了第二服务，基于预先设置的负载均衡策略，选择一个负载最小的容器，作为提供第二服务的容器。这样，在实现服务发现机制时，可以基于负载均衡策略选择提供服务的容器及工作节点，能够提高服务的效率。
94.可选地，第二容器可以是存储系统根据第二服务所在的所有容器的负载信息，基于负载均衡策略确定的；或者，第二容器可以是存储系统随机选择的。
95.另一种可选的实施方式中，该步骤可以采用如下方式实现：
96.主节点根据第二服务的标签信息，从存储系统获取第二服务所在的所有容器的访问地址信息；根据第二服务所在的所有容器的负载信息，基于负载均衡策略，确定提供所第二服务的第二容器的访问地址信息。
97.具体地，主节点通过接口服务器向存储系统发送服务信息请求，服务信息请求包含第二服务的标签信息；存储系统根据第二服务的标签信息确定所在的所有容器的访问地址信息，并反馈给主节点的接口服务器。主节点通过接口服务器接收第二服务所在的所有容器的访问地址信息。主节点通过接口服务器将第二服务所在的所有容器的访问地址信息发送给控制器。通过控制器根据第二服务所在的所有容器的负载信息，基于负载均衡策略，确定提供所第二服务的第二容器的访问地址信息。
98.步骤s207、向第一容器发送第二服务的访问地址信息。
99.该步骤中，主节点通过接口服务器获取到第二服务的访问地址信息之后，通过接口服务器向第一容器发送第二服务的访问地址信息。
100.步骤s208、通过第一容器接收主节点发送的第二服务的访问地址信息。
101.该步骤中，第一工作节点通过第一容器接收主节点发送的第二服务的访问地址信息，实现第二服务的发现。
102.步骤s209、根据第二服务的访问地址信息，调用第二服务。
103.在获取到第二服务的访问地址信息，根据第二服务的访问地址信息可以调用第二服务。
104.示例性地，一种可选的实施方式中，如图6所示，服务注册和发现的总体流程可以包含如下步骤：s1、部署服务：开发人员将服务部署至工作节点的容器内。s2、发起服务发现请求：通过容器向接口服务器发送服务发现请求。s3、查询目标服务的访问地址信息：接口服务器向etcd发送服务信息请求。s4、返回查询结果：etcd获取到目标服务所在容器的访问地址信息列表，并将目标服务所在容器的访问地址信息列表作为查询结果反馈给接口服务器。s5、接口服务器将目标服务所在容器的访问地址信息列表发给选择器。s6、返回目标服务的访问地址信息：选择器根据目标服务所在容器的负载情况，确定最终提供目标服务的容器的访问地址信息，作为目标服务的访问地址信息反馈给接口服务器。s7、接口服务器向容器返回目标服务的访问地址信息。s8、返回服务执行成功/失败：容器中根据目标服务的访问地址信息调用执行目标服务，并将执行结果反馈给开发人员。
105.本实施例通过将服务部署在集群中工作节点的容器内，服务的注册信息存储在集群的存储系统中，当第一容器内的第一服务需要调用第二服务时，通过第一容器向主节点发送服务发现请求，服务发现请求包含第二服务的标签信息；主节点接收第一容器发送的服务发现请求，服务发现请求用于发现第二服务，服务发现请求包括第二服务的标签信息；根据第二服务的标签信息，从存储系统获取第二服务的访问地址信息；向第一容器发送第二服务的访问地址信息。通过第一容器接收主节点发送的第二服务的访问地址信息；根据第二服务的访问地址信息，调用第二服务；实现了服务发现机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。
106.图7为本发明另一实施例提供的服务管理方法流程图。在上述图3或图4所示实施例的基础上，本实施例中，主节点还可以包括控制器，控制器用于每间隔一个时间段，获取第一容器的状态信息，并确定第一容器是否异常；若确定第一容器异常，则删除存储系统中的第一容器内部署的服务的标签信息和访问地址信息。如图7所示，服务管理方法的具体步骤如下：
107.步骤s301、每间隔一个时间段，获取第一容器的状态信息。
108.其中，第一容器可以是任一工作节点上的容器。
109.本实施例中，通过接口服务器实时地获取容器的相关信息，并将容器的相关信息发送给控制器。控制器基于容器的相关信息可以实现管理和监控集群中的各个容器的相关控制功能。其中，获取的容器的相关信息主要包括容器的状态信息。容器的状态信息包括健康状态、非健康状态和待删除状态三种。
110.示例性地，接口服务器可以通过轮询的方式向第一容器发送状态信息请求，并将接收到的容器反馈的状态信息发送给控制器，若未接收到容器的反馈则接口服务器也不会向控制器发送容器状态信息。
111.步骤s302、若未获取到第一容器的状态信息，或者获取到的第一容器的状态信息为非健康状态，则确定是否设置了第一容器的异常起始时间。
112.若在预设超时时长内未接收到第一容器的状态信息，则确定为获取到第一容器的状态信息。其中预设超时时长可以根据实际应用场景进行设置和调整，此处不做具体限定。
113.该步骤中，若未获取到第一容器的状态信息，或者获取到的第一容器的状态信息为非健康状态，说明第一容器有异常，则确定是否设置了第一容器的异常起始时间。
114.如果未设置第一容器的异常起始时间，则说明当前是第一次发现第一容器的异常，执行步骤s303，设置第一容器的异常起始时间。
115.如果已经设置了第一容器的异常起始时间，则继续执行步骤s304。
116.步骤s303、若未设置第一容器的异常起始时间，则设置第一容器的异常起始时间。
117.步骤s304、计算当前时间与异常起始时间之间的时间间隔。
118.步骤s305、若时间间隔大于第一时长，将存储系统中第一容器的状态信息设置为待删除状态。
119.若时间间隔大于第一时长，则说明在设置第一容器的异常起始时间之后的第一时长内，第一容器仍然未恢复健康状态，则将存储系统中第一容器的状态信息设置为待删除状态。
120.若时间间隔小于或等于第一时长，则继续执行步骤s301。如果在第一时长内第一容器恢复健康状态，则执行步骤s308，清除第一容器的异常起始时间，并将存储系统中第一容器的状态信息设置为健康状态。
121.其中，第一时长可以根据实际应用场景进行设置和调整，此处不再赘述。
122.步骤s306、若时间间隔大于第三时长，且存储系统中第一容器的状态信息保存为待删除状态，则确定第一容器异常。
123.其中第三时长等于第一时长和第二时长之和。其中，第二时长可以根据实际应用场景进行设置和调整，此处不再赘述。
124.若时间间隔大于第三时长，且存储系统中第一容器的状态信息保存为待删除状态，则说明在将存储系统中第一容器的状态信息设置为待删除状态之后，在第二时长内第一容器未恢复健康状态，则确定第一容器异常，继续执行步骤s307。
125.若时间间隔小于或等于第三时长，则继续执行步骤s301。如果在将存储系统中第一容器的状态信息设置为待删除状态之后，在第二时长内第一容器恢复健康状态，则执行步骤s308，清除第一容器的异常起始时间，并将存储系统中第一容器的状态信息设置为健康状态。
126.步骤s307、删除存储系统中的第一容器内部署的服务的注册信息。
127.在确定第一容器异常之后，删除存储系统中的第一容器内部署的服务的注册信息。
128.另外，在确定第一容器异常之后，还可以将存储系统中的第一容器的其他相关信息删除，具体可以根据实际应用场景进行配置和调整，此处不做具体限定。
129.步骤s308、获取到的第一容器的状态信息为健康状态，则清除第一容器的异常起始时间，并将存储系统中第一容器的状态信息设置为健康状态。
130.本实施例中，涉及第一时长、第二时长、第三时长的地方，可以用获取容器的状态信息的重试次数进行替换，此次不再赘述。
131.另外，容器的状态信息也可以作为容器中部署的服务的状态信息和容器所在工作
节点的状态信息。
132.本实施例中的控制器可以是kubernetes中的控制器，或者还可以采用在kubernetes基础上开发得到的控制组件(如自带监控面板的conduit等)等实现，此处不做具体限定。
133.本发明实施例能够实现服务所在容器的状态监控和维护，从而实现服务的监控和维护，能够自动清理未存活的异常服务，保证返回给消费者服务的服务都是存活的服务，提高了服务的稳定性和效率。
134.本发明实施例提供的服务管理的方法，将服务注册交给容器和kubernetes负责，而不是服务本身向服务注册中心进行注册，并且服务的注册信息存储在kubernetes自带的存储系统中，无需引入第三方数据库。消费者服务不需要和服务注册中心直接进行交互，而是利用服务所在容器和kubernetes的接口服务器进行服务的发现，将查询服务的访问地址信息以及负载均衡的复杂逻辑都交给容器和kubernetes来做。最后集群中服务的监控和维护也是由容器和kubernetes完成，自动清理存储系统中不存活的服务的信息，无需第三方服务注册中心，即可实现服务的注册、发现和维护，提高了服务的稳定性和效率。
135.图8为本发明实施例提供的服务管理装置的结构示意图。本发明实施例提供的服务管理装置可以执行服务管理方法实施例提供的处理流程。如图8所示，该服务管理装置80包括：注册模块801。
136.具体地，注册模块801用于接收第一工作节点上第一容器发送的服务注册请求，服务注册请求包括第一容器内部署的服务的注册信息。
137.注册模块801还用于将第一容器内部署的服务的注册信息，存储至所在集群的存储系统中。
138.本发明实施例提供的装置可以具体用于执行上述图3所示实施例中主节点所执行的方法流程，具体功能此处不再赘述。
139.本发明实施例通过将服务部署在集群中工作节点的容器内，在容器启动时，通过容器向主节点发送包含待注册服务的注册信息的服务注册请求，主节点将待注册服务的注册信息存储至集群的存储系统中，实现服务的注册机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。
140.图9为本发明另一实施例提供的服务管理装置的结构示意图。在上述图8所示实施例的基础上，本实施例中，如图9所示，该服务管理装置80还包括：发现模块802。
141.发现模块802用于：接收第一容器发送的服务发现请求，服务发现请求用于发现第二服务，服务发现请求包括第二服务的标签信息；根据第二服务的标签信息，从存储系统获取第二服务的访问地址信息；向第一容器发送第二服务的访问地址信息。
142.可选地，发现模块802还用于：向存储系统发送服务信息请求，服务信息请求包含第二服务的标签信息；接收存储系统反馈的第二服务的访问地址信息。
143.可选地，多个工作节点的容器内均部署了第二服务，存储系统反馈的第二服务的访问地址信息包括用于向第一容器内的第一服务提供第二服务的第二容器的ip地址和端口号；其中，第二容器是根据第二服务所在的所有容器的负载信息，基于负载均衡策略确定的。
144.可选地，发现模块802还用于：根据第二服务的标签信息，从存储系统获取第二服
务所在的所有容器的访问地址信息；根据第二服务所在的所有容器的负载信息，基于负载均衡策略，确定提供所第二服务的第二容器的访问地址信息。
145.可选地，如图9所示，服务管理装置80还包括：服务控制模块803。
146.服务控制模块803用于：每间隔一个时间段，获取第一容器的状态信息，并确定第一容器是否异常；若确定第一容器异常，则删除存储系统中的第一容器内部署的服务的注册信息。
147.可选地，服务控制模块803还用于：
148.若未获取到第一容器的状态信息，或者获取到的第一容器的状态信息为非健康状态，则确定是否设置了第一容器的异常起始时间；若未设置第一容器的异常起始时间，则设置第一容器的异常起始时间。
149.可选地，服务控制模块803还用于：
150.设置第一容器的异常起始时间之后，若在第一时长内第一容器恢复健康状态，则清除第一容器的异常起始时间；若在第一时长内第一容器未恢复健康状态，则将存储系统中第一容器的状态信息设置为待删除状态。
151.可选地，服务控制模块803还用于：
152.若在第一时长内第一容器未恢复健康状态，则将存储系统中第一容器的状态信息设置为待删除状态之后，若在第二时长内第一容器恢复健康状态，则清除第一容器的异常起始时间，并将存储系统中第一容器的状态信息设置为健康状态；若在第二时长内第一容器未恢复健康状态，则确定第一容器异常。
153.本发明实施例提供的装置可以具体用于执行上述图4或图7所示实施例中主节点所执行的方法流程，具体功能此处不再赘述。
154.本实施例通过将服务部署在集群中工作节点的容器内，服务的注册信息存储在集群的存储系统中，当第一容器内的第一服务需要调用第二服务时，通过第一容器向主节点发送服务发现请求，服务发现请求包含第二服务的标签信息；主节点接收第一容器发送的服务发现请求，服务发现请求用于发现第二服务，服务发现请求包括第二服务的标签信息；根据第二服务的标签信息，从存储系统获取第二服务的访问地址信息；向第一容器发送第二服务的访问地址信息。通过第一容器接收主节点发送的第二服务的访问地址信息；根据第二服务的访问地址信息，调用第二服务；实现了服务发现机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。进一步地，能够实现服务所在容器的状态监控和维护，从而实现服务的监控和维护，能够自动清理未存活的异常服务，保证返回给消费者服务的服务都是存活的服务，提高了服务的稳定性和效率。
155.图10为本发明另一实施例提供的服务管理装置的结构示意图。本发明实施例提供的服务管理装置可以执行服务管理方法实施例提供的处理流程。如图10所示，该服务管理装置90包括：注册模块901。
156.具体地，注册模块901用于响应于第一工作节点上第一容器的启动指令，通过第一容器向主节点发送服务注册请求，服务注册请求包括第一容器内部署的服务的标签信息和地址信息，服务注册请求用于将第一容器内部署的服务的标签信息和访问地址信息存储至所在集群的存储系统中。
157.本发明实施例提供的装置可以具体用于执行上述图3所示实施例中工作节点所执
行的方法流程，具体功能此处不再赘述。
158.本发明实施例通过将服务部署在集群中工作节点的容器内，在容器启动时，通过容器向主节点发送包含待注册服务的注册信息的服务注册请求，主节点将待注册服务的注册信息存储至集群的存储系统中，实现服务的注册机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。
159.图11为本发明另一实施例提供的服务管理装置的结构示意图。在上述图10所示实施例的基础上，本实施例中，如图11所示，该服务管理装置90还包括：发现模块902。
160.发现模块902用于：
161.当第一容器内的第一服务需要调用第二服务时，通过第一容器向主节点发送服务发现请求，服务发现请求包含第二服务的标签信息；通过第一容器接收主节点发送的第二服务的访问地址信息；根据第二服务的访问地址信息，调用第二服务。
162.可选地，发现模块902还用于：
163.通过第一容器获取主节点的地址信息；根据地址信息，向主节点的发送请求信息。
164.可选地，发现模块902还用于：
165.通过在第一容器内运行命令行工具，并执行对应命令，获取主节点的地址信息。
166.本发明实施例提供的装置可以具体用于执行上述图4或图7所示实施例中工作节点所执行的方法流程，具体功能此处不再赘述。
167.本实施例通过将服务部署在集群中工作节点的容器内，服务的注册信息存储在集群的存储系统中，当第一容器内的第一服务需要调用第二服务时，通过第一容器向主节点发送服务发现请求，服务发现请求包含第二服务的标签信息；主节点接收第一容器发送的服务发现请求，服务发现请求用于发现第二服务，服务发现请求包括第二服务的标签信息；根据第二服务的标签信息，从存储系统获取第二服务的访问地址信息；向第一容器发送第二服务的访问地址信息。通过第一容器接收主节点发送的第二服务的访问地址信息；根据第二服务的访问地址信息，调用第二服务；实现了服务发现机制，无需依赖第三方的服务注册中心，提高了服务的稳定性。进一步地，能够实现服务所在容器的状态监控和维护，从而实现服务的监控和维护，能够自动清理未存活的异常服务，保证返回给消费者服务的服务都是存活的服务，提高了服务的稳定性和效率。
168.图12为本发明实施例提供的服务管理设备的结构示意图。如图12所示，该服务管理设备100包括：处理器1001，存储器1002，以及存储在存储器1002上并可在处理器1001上运行的计算机程序。
169.其中，处理器1001运行计算机程序时实现上述任一方法实施例中工作节点或者主节点所执行的方法流程。
170.本发明实施例通过。
171.本发明实施例还提供一种计算机可读存储介质，计算机可读存储介质中存储有计算机程序，计算机程序被处理器执行时实现上述任一方法实施例中工作节点或者主节点所执行的方法流程。
172.本发明实施例还提供了一种计算机程序产品，程序产品包括：计算机程序，计算机程序存储在可读存储介质中，服务管理设备的至少一个处理器可以从可读存储介质读取计算机程序，至少一个处理器执行计算机程序使得服务管理设备执行上述任一方法实施例中
工作节点或者主节点所执行的方法流程。
173.在本发明所提供的几个实施例中，应该理解到，所揭露的装置和方法，可以通过其它的方式实现。例如，以上所描述的装置实施例仅仅是示意性的，例如，单元的划分，仅仅为一种逻辑功能划分，实际实现时可以有另外的划分方式，例如多个单元或组件可以结合或者可以集成到另一个系统，或一些特征可以忽略，或不执行。另一点，所显示或讨论的相互之间的耦合或直接耦合或通信连接可以是通过一些接口，装置或单元的间接耦合或通信连接，可以是电性，机械或其它的形式。
174.作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施例方案的目的。
175.另外，在本发明各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用硬件加软件功能单元的形式实现。
176.上述以软件功能单元的形式实现的集成的单元，可以存储在一个计算机可读取存储介质中。上述软件功能单元存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)或处理器(processor)执行本发明各个实施例方法的部分步骤。而前述的存储介质包括：u盘、移动硬盘、只读存储器(read
‑
only memory，rom)、随机存取存储器(random access memory，ram)、磁碟或者光盘等各种可以存储程序代码的介质。
177.本领域技术人员可以清楚地了解到，为描述的方便和简洁，仅以上述各功能模块的划分进行举例说明，实际应用中，可以根据需要而将上述功能分配由不同的功能模块完成，即将装置的内部结构划分成不同的功能模块，以完成以上描述的全部或者部分功能。上述描述的装置的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。
178.本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本发明的其它实施方案。本发明旨在涵盖本发明的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本发明的一般性原理并包括本发明未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本发明的真正范围和精神由下面的权利要求书指出。
179.应当理解的是，本发明并不局限于上面已经描述并在附图中示出的精确结构，并且可以在不脱离其范围进行各种修改和改变。本发明的范围仅由所附的权利要求书来限制。