Service management method, device, equipment, storage medium and program product

Abstract

The present invention provides a service management method, apparatus, device, storage medium, and program product. The method of the present invention deploys a service in a container of a working node in a cluster. When the container is started, the container sends a service registration request containing registration information of the service to be registered to a master node. The master node stores the registration information of the service to be registered in the cluster's storage system, thereby implementing a service registration mechanism without relying on a third-party service registration center and improving service stability.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a service management method, apparatus, device, storage medium and program product. Background Art

[0002] In the existing microservice framework, the producer service needs to register its service interface information in a third-party service registration center. The consumer service discovers and calls the producer service by accessing the service registration center to obtain the service interface information of the producer service.

[0003] In the process of implementing the present invention, the inventors found that there are at least the following problems in the existing technology: in the existing microservice framework, it is necessary to introduce a third-party middleware as a service registration center to store service interface information. If an abnormality occurs in the service registration center, it will directly affect the use of the service. Summary of the Invention

[0004] The present invention provides a service management method, apparatus, equipment, storage medium and program product to solve the problem in the existing microservice framework that a third-party middleware needs to be introduced as a service registration center to store service information. If an abnormality occurs in the service registration center, it will directly affect the use of the service.

[0005] A first aspect of the present invention is to provide a service management method, which is applied to a master node in a cluster, wherein the cluster includes the master node, multiple worker nodes, and a storage system, and a service is deployed in a container on the worker node. The method includes:

[0006] Receive a service registration request sent by a first container on a first working node, where the service registration request includes registration information of a service deployed in the first container;

[0007] The registration information of the service deployed in the first container is stored in the storage system of the cluster.

[0008] A second aspect of the present invention is to provide a service management method applied to a working node in a cluster, wherein the cluster includes a master node, multiple working nodes, and a storage system, and a service is deployed in a container on each of the working nodes, including:

[0009] In response to the startup instruction of the first container on the first working node, a service registration request is sent to the master node through the first container, where the service registration request includes label information and address information of the service deployed in the first container. The service registration request is used to store the label information and access address information of the service deployed in the first container in the storage system of the cluster.

[0010] A third aspect of the present invention is to provide a service management device, applied to a master node in a cluster, wherein the cluster includes the master node, multiple worker nodes, and a storage system, and a service is deployed in a container on the worker node. The device includes:

[0011] A registration module, configured to receive a service registration request sent by a first container on a first working node, wherein the service registration request includes registration information of a service deployed in the first container;

[0012] The registration module is further configured to store registration information of the service deployed in the first container in a storage system of the cluster.

[0013] A fourth aspect of the present invention is to provide a service management device, which is applied to a working node in a cluster, wherein the cluster includes a master node, multiple working nodes, and a storage system, and a service is deployed in a container on each of the working nodes. The device includes:

[0014] A registration module is configured to respond to a startup instruction of a first container on a first working node and send a service registration request to a master node through the first container, wherein the service registration request includes label information and address information of the service deployed in the first container, and the service registration request is used to store the label information and access address information of the service deployed in the first container in a storage system of the cluster.

[0015] A fifth aspect of the present invention is to provide a service management device, comprising:

[0016] A processor, a memory, and a computer program stored in the memory and executable on the processor; wherein, when the processor executes the computer program, the method described in any one of the above aspects is implemented.

[0017] A sixth aspect of the present invention is to provide a computer-readable storage medium, wherein the computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method described in any one of the above aspects is implemented.

[0018] A seventh aspect of the present invention is to provide a computer program product, comprising a computer program, which implements the method according to any one of the above aspects when executed by a processor.

[0019] The service management method, apparatus, equipment, storage medium and program product provided by the present invention deploy the service in the container of the working node in the cluster. When the container is started, a service registration request containing the registration information of the service to be registered is sent to the master node through the container. The master node stores the registration information of the service to be registered in the storage system of the cluster, thereby realizing a service registration mechanism without relying on a third-party service registration center, thereby improving the stability of the service. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 A schematic diagram of a cluster architecture provided by an embodiment of the present invention;

[0021] Figure 2 A framework diagram of service registration and discovery provided by an embodiment of the present invention;

[0022] Figure 3 A flow chart of the service management method provided by an embodiment of the present invention;

[0023] Figure 4 A flow chart of a service management method provided by another embodiment of the present invention;

[0024] Figure 5 A schematic diagram of the etcd architecture provided in an embodiment of the present invention;

[0025] Figure 6 A schematic diagram of the overall process of service registration and discovery provided by an embodiment of the present invention;

[0026] Figure 7 A flow chart of a service management method provided by another embodiment of the present invention;

[0027] Figure 8 A schematic diagram of the structure of a service management device provided in an embodiment of the present invention;

[0028] Figure 9 A schematic structural diagram of a service management device provided in another embodiment of the present invention;

[0029] Figure 10 A schematic structural diagram of a service management device provided in another embodiment of the present invention;

[0030] Figure 11 A schematic structural diagram of a service management device provided in another embodiment of the present invention;

[0031] Figure 12 A schematic diagram of the structure of a service management device provided in an embodiment of the present invention.

[0032] The above drawings illustrate specific embodiments of the present invention, which will be described in more detail below. These drawings and the accompanying description are not intended to limit the scope of the present invention in any way, but rather to illustrate the concept of the present invention to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0033] Exemplary embodiments will be described in detail herein, examples of which are illustrated in the accompanying drawings. In the following description, when referring to the drawings, like numbers in different figures represent like or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all possible embodiments consistent with the present invention. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present invention, as detailed in the appended claims.

[0034] First, the terms involved in the present invention are explained:

[0035] Kubernetes: K8s for short, is an open source containerized application for managing multiple hosts in a cloud platform.

[0036] etcd: It is a highly available Key-Value storage system and the default storage system provided by Kubernetes. It is mainly used for shared configuration and service discovery.

[0037] Mirroring: A file storage format in which data on one disk is identically copied on another disk.

[0038] Load balancing: Commonly used to distribute workloads across multiple servers to improve the performance and reliability of websites, applications, and databases.

[0039] Service platform: a platform developed based on the microservice framework to provide services and their interfaces.

[0040] JSF (Jingdong Service Framework, Jeff): A high-performance service framework developed based on the evolution of Remote Procedure Call (RPC).

[0041] The JSF gateway is the JSF entry point for HTTP requests, adding a layer between the service consumer and the service provider. The service consumer indirectly accesses the target service through the JSF gateway.

[0042] JDOS, short for Jingdong Datacenter Operating System, is responsible for software-defined data center management, providing unified management of physical machines, virtual machines, and containers, flexible network interconnection, and reliable block storage.

[0043] In addition, the terms "first," "second," etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features. In the description of the following embodiments, "plurality" means more than two, unless otherwise specifically defined.

[0044] In existing microservice frameworks (such as JSF), the producer service needs to register its service interface information in a third-party service registration center. The consumer service discovers and calls the producer service by accessing the service registration center to obtain the service interface information of the producer service.

[0045] In the process of implementing the present invention, the inventors found that there are at least the following problems in the prior art: In the existing microservice framework, it is necessary to introduce a third-party middleware as a service registration center to store service interface information. If an abnormality occurs in the service registration center, it will directly affect the use of the service. Since the service registration center is implemented in a specific programming language and cannot support cross-language interaction, developers need to customize a software development kit (SDK) that interacts with the service registration center for each service in a different language. The development cycle is long and consumes a lot of manpower and equipment resources. In addition, a service gateway is set between the service consumer and the service producer. The service consumer uses DNS to access the service producer through the service gateway, which requires the configuration of a router and a load balancer, resulting in poor communication performance of the remote procedure call (RPC) between services.

[0046] The service management method provided by the present invention is intended to solve the above technical problems in the prior art.

[0047] The present invention is specifically applied to Figure 1 The containerized cluster that implements the discovery and registration mechanism of microservices shown in the figure can be a containerized cluster such as Kubernetes. Figure 1 Taking Kubernetes as an example, the architecture of the containerized cluster that implements the discovery and registration mechanism of microservices is illustrated. Figure 1 As shown, the cluster includes the master node (such as Figure 1 master node shown), multiple working nodes ( Figure 1 Taking four worker nodes as an example) and a storage system. Each worker node has a container deployed on it, and each container can host one or more services (including consumer services and / or producer services). The services in the containers communicate with the master node through the containers. The storage system can be a component included in the cluster framework for storing cluster data, such as etcd in Kubernetes.

[0048] In addition, the master node may include components such as the API Server, Controller, and Selector, and different components are used to implement different functions. Among them, the API Server is used to implement the interaction between the master node and the containers on the working nodes, and to implement the registration and discovery mechanism of services within the container. Other components on the master node cannot directly interact with the containers on the working nodes. The controller is an optional component that is used to automatically obtain the status information of each container and automatically clear the registration information of the container that has been disconnected. The selector is an optional component that is used to determine the container that provides the target service based on the load situation of the container that can provide the target service and the load balancing strategy.

[0049] Optionally, the method of the present invention can be based on Kubernetes which deploys the infrastructure via JDOS containers to implement a service registration and discovery mechanism. Figure 2 As shown in the figure, the producer service registers the service in Kubernetes, and the consumer service discovers the service in Kubernetes.

[0050] The following describes in detail the technical solutions of the present invention and how the technical solutions of this application solve the above-mentioned technical problems using specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described in detail in some embodiments. The following embodiments of the present invention are described in conjunction with the accompanying drawings.

[0051] Figure 3 Flowchart of the service management method provided by the embodiment of the present invention. Figure 3 As shown, the specific steps of this method are as follows:

[0052] Step S101: In response to the startup instruction of the first container on the first working node, a service registration request is sent to the master node through the first container. The service registration request includes the registration information of the service deployed in the first container. The service registration request is used to store the registration information of the service deployed in the first container in the storage system of the cluster.

[0053] The first worker node can be any worker node in the cluster, and the first container is a container on the first worker node, that is, any container where a service in the cluster resides. The term "first service" refers to the service deployed in the first container. One or more services can be deployed in the first container, including consumer services and / or producer services.

[0054] Registration information includes the service's tag information and the resource information of the container where the service resides. The service's tag information can include service interface information, alias, service category (including consumer services and producer services), and other relevant information about the service to be registered. This tag information uniquely identifies a service.

[0055] The resource information for a service container includes at least the access address of the service container. This information may also include information about the container and its node, including its status, name, communication protocol, and preset timeout period. Container status information may include healthy, unhealthy, or pending deletion.

[0056] In this embodiment, the registration information of the service is saved in the storage system of the cluster.

[0057] In response to the startup instruction of the first container on the first working node, a service registration request is sent to the master node through the first container, so that the master node stores the registration information of the service deployed in the first container in the storage system of the cluster, thereby realizing the service registration mechanism.

[0058] Step S102: The master node receives a service registration request sent by the first container on the first working node, where the service registration request includes registration information of the service deployed in the first container.

[0059] The master node receives the service registration request sent by the first working node through the first container, and obtains registration information of the to-be-registered service in the first container.

[0060] Step S103: The master node stores the registration information of the service deployed in the first container in the storage system of the cluster.

[0061] After obtaining the registration information of the service deployed in the first container, the master node stores the registration information of the service deployed in the first container in the storage system of the cluster, thereby realizing registration of the service deployed in the first container.

[0062] The embodiment of the present invention deploys the service in the container of the working node in the cluster. When the container is started, the container sends a service registration request containing the registration information of the service to be registered to the master node. The master node stores the registration information of the service to be registered in the storage system of the cluster, thereby realizing a service registration mechanism without relying on a third-party service registration center, thereby improving the stability of the service.

[0063] Figure 4 This is a flow chart of a service management method provided by another embodiment of the present invention. Figure 3On the basis of the illustrated embodiment, in this embodiment, when the first service in the first container needs to call the second service, the working node where the first service is located sends a service discovery request to the master node through the first container, and the service discovery request includes the label information of the second service; the master node receives the service discovery request sent by the first container, and the service discovery request is used to discover the second service, and the service discovery request includes the label information of the second service; according to the label information of the second service, the access address information of the second service is obtained from the storage system; and the access address information of the second service is sent to the first container; the working node receives the access address information of the second service sent by the master node through the first container; and calls the second service according to the access address information of the second service. In this embodiment, based on Figure 1 Taking the containerized cluster architecture shown in FIG. 1 as an example, the process of the service management method is described in detail.

[0064] like Figure 4 As shown, the specific steps of this method are as follows:

[0065] Step S201: In response to the startup instruction of the first container on the first working node, a service registration request is sent to the master node through the first container. The service registration request includes the label information and address information of the service deployed in the first container. The service registration request is used to store the label information and access address information of the service deployed in the first container in the storage system of the cluster.

[0066] The first worker node can be any worker node in the cluster, and the first container is a container on the first worker node, that is, any container where a service in the cluster resides. The term "first service" refers to the service deployed in the first container. One or more services can be deployed in the first container, including consumer services and / or producer services.

[0067] Registration information includes the service's tag information and the resource information of the container where the service resides. The service's tag information can include service interface information, alias, service category (including consumer services and producer services), and other relevant information about the service to be registered. This tag information uniquely identifies a service.

[0068] Resource information for a service container includes at least the access address of the service container. This information may also include information about the container's status, name, communication protocol, preset timeouts, preset policies, and other related information about the container and its worker node. Container status information may include healthy, unhealthy, and pending deletion, indicating the container's health.

[0069] For example, the storage system used to store service registration information can be etcd in Kubernetes, eliminating the need for additional storage software. etcd is a key-value storage system. Service registration information is represented in a key-value format, where the key represents the service's label information and the value represents the resource information of the container where the service resides. The storage system stores the registration information of all registered services.

[0070] In Kubernetes, etcd cluster plays two main roles: one is a persistent key-value storage system, and the second is a distributed system data consistency service provider. The container-related information stored in etcd includes health status, container resources, name, address information, etc. Figure 5 As shown in the figure, an etcd cluster typically consists of a network layer, a Raft module, a storage layer, and a state machine. When a container request is sent, it is forwarded via the network layer to the storage layer for specific transaction processing. If it involves an update to the container (or worker node) status information, it is submitted to the Raft module for arbitration and logging, and then synchronized to other etcd nodes. Data persistence occurs only after more than half of the etcd nodes confirm the container status change.

[0071] In response to the start instruction of the first container on the first working node, a service registration request is sent to the interface server of the master node through the first container. The master node stores the registration information of the service deployed in the first container in the storage system of the cluster through the interface server, thereby implementing the service registration mechanism.

[0072] In this embodiment, the service registration information included in the service registration request may include the registration information of all services deployed in the first container, or the service registration information included in the service registration request may only include the registration information of the producer service among all services deployed in the first container.

[0073] Step S202: The master node receives a service registration request sent by the first container on the first working node, where the service registration request includes registration information deployed in the first container.

[0074] In this step, the master node receives the service registration request sent by the first container through the interface server, and obtains the registration information of the service to be registered in the first container.

[0075] Step S303: The master node stores the registration information of the service deployed in the first container in the storage system of the cluster.

[0076] After obtaining the registration information of the service deployed in the first container, the master node stores the registration information of the service deployed in the first container in the storage system of the cluster through the interface server, thereby realizing registration of the service deployed in the first container.

[0077] In this embodiment, for a registered second service, when the second service needs to be called, the second service can be discovered through steps S204 to S209 to implement a service discovery mechanism.

[0078] Step S204: When the first service in the first container needs to call the second service, a service discovery request is sent to the master node through the first container, where the service discovery request includes label information of the second service.

[0079] In this step, when the first service deployed in the first container on the first working node needs to call the second service, the first service is a consumer service and the second service is a producer service, and a service discovery request is sent to the interface server of the master node through the first container.

[0080] In this embodiment, when it is necessary to send a request message to the master node through the first container, the address information of the master node is obtained through the first container; and the request message is sent to the master node according to the address information.

[0081] Specifically, when it is necessary to send request information to the master node through the first container, the address information of the interface server of the master node is obtained through the first container; and the request information is sent to the interface server of the master node according to the address information of the interface server.

[0082] Optionally, obtaining the address information of the master node through the first container includes:

[0083] By running the command line tool in the first container and executing the corresponding command, the address information of the master node is obtained.

[0084] Specifically, the address information of the interface server of the master node is obtained by running a command line tool in the first container and executing a corresponding command.

[0085] Exemplarily, the interface server is a service deployed on the master node in kubernetes. The service name is "kubernetes", its IP address is a Cluster IP address, which is the first address in the Cluster IP address pool, and the service port is HTTPS port 443. Kubectl is a command line tool provided by Kubernetes. The interface server of Kubernetes can be operated in a command line interactive manner through kubectl. The communication protocol can use HTTP or JSON. The corresponding HTTP request is sent to kubectl, and the request is received and processed by the interface server of Kubernetes and the processing result is fed back to kubectl. In this embodiment, the IP address and port of the interface server can be obtained by running the command line tool in the first container and running the corresponding command.

[0086] Step S205: The master node receives a service discovery request sent by the first container. The service discovery request is used to discover the second service. The service discovery request includes label information of the second service.

[0087] The master node receives the service discovery request sent by the first container through the interface server, and can obtain the label information of the second service to be discovered.

[0088] Step S206: The master node obtains access address information of the second service from the storage system according to the label information of the second service.

[0089] In an optional implementation, this step can be implemented as follows:

[0090] The master node sends a service information request to the storage system, which includes the tag information of the second service. The storage system determines the access address information of the second service based on the tag information of the second service and feeds it back to the master node. The master node receives the access address information of the second service fed back by the storage system.

[0091] The access address information of the second service fed back by the storage system includes the IP address and port number of the second container used to provide the second service to the first service in the first container.

[0092] In this embodiment, the master node and the storage system also interact with each other through the interface server. Specifically, the master node sends a service information request to the storage system through the interface server. The service information request includes the tag information of the second service. The storage system determines the access address information of the second service based on the tag information of the second service and feeds it back to the master node's interface server. The master node receives the access address information of the second service fed back by the storage system through the interface server.

[0093] Furthermore, to improve service latency and enhance service efficiency, a single service can be deployed simultaneously in containers on multiple worker nodes. When a second service is discovered, the second service is deployed in containers on multiple worker nodes. Based on a pre-set load balancing policy, the container with the least load is selected as the container providing the second service. This allows the service discovery mechanism to select service containers and worker nodes based on the load balancing policy, improving service efficiency.

[0094] Optionally, the second container may be determined by the storage system according to load information of all containers where the second service is located and based on a load balancing policy; or, the second container may be randomly selected by the storage system.

[0095] In another optional implementation, this step can be implemented as follows:

[0096] The master node obtains the access address information of all containers where the second service is located from the storage system based on the label information of the second service; and determines the access address information of the second container providing the second service based on the load information of all containers where the second service is located and the load balancing strategy.

[0097] Specifically, the master node sends a service information request to the storage system via the interface server. The service information request includes the tag information of the second service. The storage system determines the access address information of all containers containing the second service based on the tag information and sends this information back to the master node's interface server. The master node receives the access address information of all containers containing the second service via the interface server. The master node sends the access address information of all containers containing the second service to the controller via the interface server. The controller determines the access address information of the second container providing the second service based on the load balancing policy and the load information of all containers containing the second service.

[0098] Step S207: Send access address information of the second service to the first container.

[0099] In this step, after the master node obtains the access address information of the second service through the interface server, it sends the access address information of the second service to the first container through the interface server.

[0100] Step S208: Receive access address information of the second service sent by the master node through the first container.

[0101] In this step, the first working node receives the access address information of the second service sent by the master node through the first container, thereby realizing discovery of the second service.

[0102] Step S209: Call the second service according to the access address information of the second service.

[0103] After the access address information of the second service is obtained, the second service may be called according to the access address information of the second service.

[0104] For example, in an optional embodiment, Figure 6 As shown, the overall process of service registration and discovery can include the following steps: S1. Deploy the service: The developer deploys the service to the container of the working node. S2. Initiate a service discovery request: Send a service discovery request to the interface server through the container. S3. Query the access address information of the target service: The interface server sends a service information request to etcd. S4. Return the query result: etcd obtains the access address information list of the container where the target service is located, and feeds back the access address information list of the container where the target service is located as the query result to the interface server. S5. The interface server sends the access address information list of the container where the target service is located to the selector. S6. Return the access address information of the target service: The selector determines the access address information of the container that ultimately provides the target service based on the load of the container where the target service is located, and feeds back the access address information of the target service to the interface server as the access address information of the target service. S7. The interface server returns the access address information of the target service to the container. S8. Return service execution success / failure: The container calls and executes the target service based on the access address information of the target service, and feeds back the execution result to the developer.

[0105] This embodiment deploys the service in the container of the working node in the cluster, and stores the service registration information in the storage system of the cluster. When the first service in the first container needs to call the second service, the first container sends a service discovery request to the master node, and the service discovery request includes the label information of the second service. The master node receives the service discovery request sent by the first container, and the service discovery request is used to discover the second service, and the service discovery request includes the label information of the second service. Based on the label information of the second service, the access address information of the second service is obtained from the storage system, and the access address information of the second service is sent to the first container. The access address information of the second service sent by the master node is received through the first container; based on the access address information of the second service, the second service is called. This implements a service discovery mechanism without relying on a third-party service registration center, thereby improving the stability of the service.

[0106] Figure 7 This is a flow chart of a service management method provided by another embodiment of the present invention. Figure 3 or Figure 4Based on the embodiment shown, in this embodiment, the master node may further include a controller, which is configured to obtain the status information of the first container at intervals of a time period and determine whether the first container is abnormal; if the first container is determined to be abnormal, the tag information and access address information of the service deployed in the first container in the storage system are deleted. Figure 7 As shown, the specific steps of the service management method are as follows:

[0107] Step S301: Obtain status information of a first container at intervals of a time period.

[0108] The first container can be a container on any working node.

[0109] In this embodiment, the interface server obtains container-related information in real time and sends it to the controller. Based on this information, the controller can manage and monitor each container in the cluster. The obtained container-related information primarily includes container status information. Container status information includes healthy, unhealthy, and pending deletion.

[0110] For example, the interface server may send a status information request to the first container in a polling manner, and send the received status information fed back by the container to the controller. If no feedback from the container is received, the interface server will not send the container status information to the controller.

[0111] Step S302: If the status information of the first container is not obtained, or the obtained status information of the first container is in an unhealthy state, determine whether the abnormality start time of the first container is set.

[0112] If the status information of the first container is not received within the preset timeout period, it is determined that the status information of the first container has been obtained. The preset timeout period can be set and adjusted according to the actual application scenario and is not specifically limited here.

[0113] In this step, if the status information of the first container is not obtained, or the obtained status information of the first container is in an unhealthy state, it means that the first container is abnormal. Then, it is determined whether the abnormality start time of the first container is set.

[0114] If the abnormality start time of the first container is not set, it means that the abnormality of the first container is discovered for the first time, and step S303 is executed to set the abnormality start time of the first container.

[0115] If the abnormality start time of the first container has been set, the process continues with step S304.

[0116] Step S303: If the abnormality start time of the first container is not set, set the abnormality start time of the first container.

[0117] Step S304: Calculate the time interval between the current time and the abnormality start time.

[0118] Step S305: If the time interval is greater than the first duration, the state information of the first container in the storage system is set to a pending deletion state.

[0119] If the time interval is greater than the first duration, it means that the first container has not recovered to a healthy state within the first duration after the abnormality start time of the first container is set, and the state information of the first container in the storage system is set to a pending deletion state.

[0120] If the time interval is less than or equal to the first duration, then continue with step S301. If the first container recovers to a healthy state within the first duration, then proceed to step S308 to clear the abnormal start time of the first container and set the state information of the first container in the storage system to a healthy state.

[0121] Among them, the first duration can be set and adjusted according to the actual application scenario, which will not be repeated here.

[0122] Step S306: If the time interval is greater than the third time period, and the state information of the first container in the storage system is saved in a pending deletion state, it is determined that the first container is abnormal.

[0123] The third duration is equal to the sum of the first duration and the second duration. The second duration can be set and adjusted according to the actual application scenario, which will not be described in detail here.

[0124] If the time interval is greater than the third duration, and the status information of the first container in the storage system is saved in the pending deletion state, it means that after the status information of the first container in the storage system is set to the pending deletion state, the first container has not recovered to a healthy state within the second duration. In this case, the first container is determined to be abnormal, and the process proceeds to step S307.

[0125] If the time interval is less than or equal to the third duration, step S301 is continued. If, after the status information of the first container in the storage system is set to the pending deletion state, the first container returns to a healthy state within the second duration, step S308 is executed to clear the abnormal start time of the first container and set the status information of the first container in the storage system to a healthy state.

[0126] Step S307: Delete the registration information of the service deployed in the first container in the storage system.

[0127] After determining that the first container is abnormal, the registration information of the service deployed in the first container in the storage system is deleted.

[0128] In addition, after determining that the first container is abnormal, other relevant information of the first container in the storage system may be deleted. The specific configuration and adjustment may be made according to the actual application scenario and is not specifically limited here.

[0129] Step S308: If the acquired status information of the first container is in a healthy state, the abnormal start time of the first container is cleared, and the status information of the first container in the storage system is set to a healthy state.

[0130] In this embodiment, the first duration, the second duration, and the third duration may be replaced by the number of retries for obtaining the status information of the container, which will not be described in detail here.

[0131] In addition, the status information of the container can also be used as the status information of the service deployed in the container and the status information of the working node where the container is located.

[0132] The controller in this embodiment can be a controller in Kubernetes, or can also be implemented using a control component developed based on Kubernetes (such as Conduit with its own monitoring panel, etc.), which is not specifically limited here.

[0133] The embodiments of the present invention can realize status monitoring and maintenance of the container where the service is located, thereby realizing monitoring and maintenance of the service, and can automatically clean up non-surviving abnormal services to ensure that the services returned to the consumer are all surviving services, thereby improving the stability and efficiency of the service.

[0134] The service management method provided by the embodiment of the present invention entrusts service registration to the container and Kubernetes, rather than the service itself registering with the service registration center, and the service registration information is stored in the storage system of Kubernetes itself, without the need to introduce a third-party database. Consumer services do not need to interact directly with the service registration center, but instead use the container where the service is located and the interface server of Kubernetes to discover the service, and entrust the access address information of the query service and the complex logic of load balancing to the container and Kubernetes. Finally, the monitoring and maintenance of services in the cluster are also completed by the container and Kubernetes, which automatically clean up the information of inactive services in the storage system. Without the need for a third-party service registration center, service registration, discovery and maintenance can be achieved, thereby improving the stability and efficiency of the service.

[0135] Figure 8 The schematic diagram of the structure of the service management device provided by the embodiment of the present invention. The service management device provided by the embodiment of the present invention can execute the processing flow provided by the embodiment of the service management method. Figure 8As shown, the service management device 80 includes: a registration module 801.

[0136] Specifically, the registration module 801 is used to receive a service registration request sent by a first container on a first working node, where the service registration request includes registration information of a service deployed in the first container.

[0137] The registration module 801 is further configured to store the registration information of the service deployed in the first container in the storage system of the cluster.

[0138] The device provided in the embodiment of the present invention can be specifically used to perform the above Figure 3 The method flow executed by the master node in the illustrated embodiment and the specific functions thereof are not described in detail here.

[0139] The embodiment of the present invention deploys the service in the container of the working node in the cluster. When the container is started, the container sends a service registration request containing the registration information of the service to be registered to the master node. The master node stores the registration information of the service to be registered in the storage system of the cluster, thereby realizing a service registration mechanism without relying on a third-party service registration center, thereby improving the stability of the service.

[0140] Figure 9 This is a structural diagram of a service management device provided by another embodiment of the present invention. Figure 8 Based on the embodiment shown in FIG. 1 , in this embodiment, as Figure 9 As shown, the service management device 80 further includes: a discovery module 802.

[0141] The discovery module 802 is used to: receive a service discovery request sent by the first container, where the service discovery request is used to discover the second service, and the service discovery request includes label information of the second service; obtain access address information of the second service from the storage system based on the label information of the second service; and send the access address information of the second service to the first container.

[0142] Optionally, the discovery module 802 is further configured to: send a service information request to the storage system, where the service information request includes label information of the second service; and receive access address information of the second service fed back by the storage system.

[0143] Optionally, the second service is deployed in the containers of multiple working nodes, and the access address information of the second service fed back by the storage system includes the IP address and port number of the second container used to provide the second service to the first service in the first container; wherein, the second container is determined based on the load balancing policy according to the load information of all containers where the second service is located.

[0144] Optionally, the discovery module 802 is further used to: obtain access address information of all containers where the second service is located from the storage system according to the label information of the second service; and determine the access address information of the second container providing the second service based on the load balancing strategy according to the load information of all containers where the second service is located.

[0145] Alternatively, as Figure 9 As shown, the service management device 80 further includes: a service control module 803.

[0146] The service control module 803 is configured to obtain status information of the first container at intervals of a time period and determine whether the first container is abnormal; if the first container is determined to be abnormal, delete registration information of the service deployed in the first container in the storage system.

[0147] Optionally, the service control module 803 is further configured to:

[0148] If the status information of the first container is not obtained, or the obtained status information of the first container is in an unhealthy state, determine whether the abnormality start time of the first container is set; if the abnormality start time of the first container is not set, set the abnormality start time of the first container.

[0149] Optionally, the service control module 803 is further configured to:

[0150] After setting the abnormality start time of the first container, if the first container recovers to a healthy state within a first time period, the abnormality start time of the first container is cleared; if the first container does not recover to a healthy state within the first time period, the status information of the first container in the storage system is set to a pending deletion state.

[0151] Optionally, the service control module 803 is further configured to:

[0152] If the first container does not recover to a healthy state within the first time period, the status information of the first container in the storage system is set to a pending deletion state. If the first container recovers to a healthy state within a second time period, the abnormal start time of the first container is cleared, and the status information of the first container in the storage system is set to a healthy state. If the first container does not recover to a healthy state within the second time period, the first container is determined to be abnormal.

[0153] The device provided in the embodiment of the present invention can be specifically used to perform the above Figure 4 or Figure 7 The method flow executed by the master node in the illustrated embodiment and the specific functions thereof are not described in detail here.

[0154] This embodiment deploys the service in the container of the working node in the cluster, and stores the registration information of the service in the storage system of the cluster. When the first service in the first container needs to call the second service, the first container sends a service discovery request to the master node, and the service discovery request includes the label information of the second service; the master node receives the service discovery request sent by the first container, and the service discovery request is used to discover the second service, and the service discovery request includes the label information of the second service; according to the label information of the second service, the access address information of the second service is obtained from the storage system; and the access address information of the second service is sent to the first container. The access address information of the second service sent by the master node is received through the first container; according to the access address information of the second service, the second service is called; a service discovery mechanism is implemented without relying on a third-party service registration center, thereby improving the stability of the service. Furthermore, it can realize the status monitoring and maintenance of the container where the service is located, thereby realizing the monitoring and maintenance of the service, and can automatically clean up the abnormal services that have not survived, ensuring that the services returned to the consumer service are all surviving services, thereby improving the stability and efficiency of the service.

[0155] Figure 10 This is a structural diagram of a service management device provided by another embodiment of the present invention. The service management device provided by the embodiment of the present invention can execute the processing flow provided by the embodiment of the service management method. Figure 10 As shown, the service management device 90 includes: a registration module 901.

[0156] Specifically, the registration module 901 is used to respond to the startup instruction of the first container on the first working node, and send a service registration request to the master node through the first container. The service registration request includes the label information and address information of the service deployed in the first container. The service registration request is used to store the label information and access address information of the service deployed in the first container in the storage system of the cluster.

[0157] The device provided in the embodiment of the present invention can be specifically used to perform the above Figure 3 The method flow executed by the working node in the illustrated embodiment and the specific functions are not described here in detail.

[0158] The embodiment of the present invention deploys the service in the container of the working node in the cluster. When the container is started, the container sends a service registration request containing the registration information of the service to be registered to the master node. The master node stores the registration information of the service to be registered in the storage system of the cluster, thereby realizing a service registration mechanism without relying on a third-party service registration center, thereby improving the stability of the service.

[0159] Figure 11 This is a structural diagram of a service management device provided by another embodiment of the present invention. Figure 10 Based on the embodiment shown in FIG. 1 , in this embodiment, as Figure 11 As shown, the service management device 90 further includes: a discovery module 902.

[0160] The discovery module 902 is used to:

[0161] When the first service in the first container needs to call the second service, a service discovery request is sent to the master node through the first container, and the service discovery request includes the label information of the second service; the access address information of the second service sent by the master node is received through the first container; and the second service is called according to the access address information of the second service.

[0162] Optionally, the discovery module 902 is further configured to:

[0163] The address information of the master node is obtained through the first container; and a request information is sent to the master node according to the address information.

[0164] Optionally, the discovery module 902 is further configured to:

[0165] By running the command line tool in the first container and executing the corresponding command, the address information of the master node is obtained.

[0166] The device provided in the embodiment of the present invention can be specifically used to perform the above Figure 4 or Figure 7 The method flow executed by the working node in the illustrated embodiment and the specific functions are not described here in detail.

[0167] This embodiment deploys the service in the container of the working node in the cluster, and stores the registration information of the service in the storage system of the cluster. When the first service in the first container needs to call the second service, the first container sends a service discovery request to the master node, and the service discovery request includes the label information of the second service; the master node receives the service discovery request sent by the first container, and the service discovery request is used to discover the second service, and the service discovery request includes the label information of the second service; according to the label information of the second service, the access address information of the second service is obtained from the storage system; and the access address information of the second service is sent to the first container. The access address information of the second service sent by the master node is received through the first container; according to the access address information of the second service, the second service is called; a service discovery mechanism is implemented without relying on a third-party service registration center, thereby improving the stability of the service. Furthermore, it can realize the status monitoring and maintenance of the container where the service is located, thereby realizing the monitoring and maintenance of the service, and can automatically clean up the abnormal services that have not survived, ensuring that the services returned to the consumer service are all surviving services, thereby improving the stability and efficiency of the service.

[0168] Figure 12 This is a schematic diagram of the structure of the service management device provided by the embodiment of the present invention. Figure 12As shown, the service management device 100 includes: a processor 1001 , a memory 1002 , and a computer program stored in the memory 1002 and executable on the processor 1001 .

[0169] Among them, when the processor 1001 runs the computer program, it implements the method flow executed by the working node or the master node in any of the above method embodiments.

[0170] The embodiment of the present invention is adopted.

[0171] An embodiment of the present invention also provides a computer-readable storage medium, which stores a computer program. When the computer program is executed by a processor, it implements the method flow executed by the working node or the master node in any of the above method embodiments.

[0172] An embodiment of the present invention also provides a computer program product, which includes: a computer program, the computer program is stored in a readable storage medium, at least one processor of the service management device can read the computer program from the readable storage medium, and at least one processor executes the computer program so that the service management device executes the method flow executed by the working node or the main node in any of the above method embodiments.

[0173] In the several embodiments provided by the present invention, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For example, the division of units is merely a logical function division. In actual implementation, there may be other division methods, such as multiple units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the mutual coupling or direct coupling or communication connection shown or discussed can be through some interface, indirect coupling or communication connection of devices or units, which can be electrical, mechanical or other forms.

[0174] Units described as separate components may or may not be physically separate, and components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of these units may be selected to achieve the purpose of this embodiment according to actual needs.

[0175] In addition, the functional units in various embodiments of the present invention may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or hardware plus software functional units.

[0176] The above-mentioned integrated unit implemented in the form of a software functional unit can be stored in a computer-readable storage medium. The above-mentioned software functional unit is stored in a storage medium and includes a number of instructions for causing a computer device (which can be a personal computer, server, or network device, etc.) or a processor to perform some steps of the method of each embodiment of the present invention. The aforementioned storage medium includes: a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, etc., various media that can store program code.

[0177] Those skilled in the art will clearly understand that for the sake of convenience and brevity, the division of the above-mentioned functional modules is only used as an example for illustration. In actual applications, the above-mentioned functions can be assigned to different functional modules as needed, that is, the internal structure of the device can be divided into different functional modules to complete all or part of the functions described above. The specific working process of the device described above can refer to the corresponding process in the aforementioned method embodiment and will not be repeated here.

[0178] Other embodiments of the present invention will readily occur to those skilled in the art after considering the specification and practicing the invention disclosed herein. The present invention is intended to cover any variations, uses, or adaptations of the present invention that follow the general principles of the invention and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, with the true scope and spirit of the invention being indicated by the following claims.

[0179] It should be understood that the present invention is not limited to the exact construction described above and shown in the drawings, and that various modifications and changes may be made without departing from the scope thereof, which is limited only by the appended claims.

Claims

1. A service management method, characterized in that: Applied to a master node in a cluster, the cluster comprising the master node, multiple worker nodes, and a storage system, wherein a service is deployed in a container on the worker node, the method comprising: Receive a service registration request sent by a first container on a first working node, where the service registration request includes registration information of a service deployed in the first container; wherein the registration information includes label information of the service and access address information of the service; Storing the registration information of the service deployed in the first container in the storage system of the cluster; The method further comprises: Receive a service discovery request sent by the first container, where the service discovery request is used to discover a second service, and the service discovery request includes label information of the second service; acquiring access address information of the second service from the storage system according to the label information of the second service; Send access address information of the second service to the first container.

2. The method according to claim 1, characterized in that The acquiring, from the storage system according to the tag information of the second service, access address information of the second service includes: Sending a service information request to the storage system, where the service information request includes label information of the second service; Receive access address information of the second service fed back by the storage system.

3. The method according to claim 2, characterized in that The second service is deployed in the containers of multiple working nodes. The access address information of the second service fed back by the storage system includes the IP address and port number of the second container used to provide the second service to the first service in the first container; The second container is determined based on a load balancing policy according to load information of all containers where the second service is located.

4. The method according to claim 1, wherein The acquiring, from the storage system according to the tag information of the second service, access address information of the second service includes: According to the label information of the second service, access address information of all containers where the second service is located is obtained from the storage system; According to the load information of all containers where the second service is located and based on the load balancing strategy, access address information of the second container providing the second service is determined.

5. The method according to any one of claims 1 to 4, characterized in that The method further comprises: acquiring status information of the first container at intervals of a time period, and determining whether the first container is abnormal; If it is determined that the first container is abnormal, the registration information of the service deployed in the first container in the storage system is deleted.

6. The method according to claim 5, characterized in that The acquiring the status information of the first container and determining whether the first container is abnormal includes: If the status information of the first container is not obtained, or the obtained status information of the first container is in an unhealthy state, determining whether an abnormal start time of the first container is set; If the abnormality start time of the first container is not set, the abnormality start time of the first container is set.

7. The method according to claim 6, characterized in that After setting the abnormal start time of the first container, the method further includes: If the first container recovers to a healthy state within the first time period, clearing the abnormal start time of the first container; If the first container does not recover to a healthy state within a first period of time, the state information of the first container in the storage system is set to a pending deletion state.

8. The method according to claim 7, characterized in that If the first container does not recover to a healthy state within the first time period, after setting the state information of the first container in the storage system to a pending deletion state, the method further includes: If the first container recovers to a healthy state within the second time period, clearing the abnormal start time of the first container and setting the state information of the first container in the storage system to a healthy state; If the first container does not recover to a healthy state within the second time period, it is determined that the first container is abnormal.

9. A service management method, characterized in that: Applied to a worker node in a cluster, the cluster includes a master node, multiple worker nodes, and a storage system. Services are deployed in a container on each worker node, including: In response to a start instruction of a first container on a first working node, sending a service registration request to a master node through the first container, where the service registration request includes label information and access address information of a service deployed in the first container, and the service registration request is used to store the label information and access address information of the service deployed in the first container in a storage system of the cluster; When the first service in the first container needs to call the second service, a service discovery request is sent to the master node through the first container, where the service discovery request includes label information of the second service; receiving, through the first container, access address information of the second service sent by the master node; The second service is called according to the access address information of the second service.

10. The method according to claim 9, characterized in that Sending request information to the master node through the first container includes: Obtaining address information of the master node through the first container; According to the address information, request information is sent to the master node.

11. The method according to claim 10, characterized in that The acquiring the address information of the master node through the first container includes: The address information of the master node is obtained by running a command line tool in the first container and executing a corresponding command.

12. A service management device, characterized in that: Applied to a master node in a cluster, the cluster including the master node, multiple worker nodes, and a storage system, with services deployed in containers on the worker nodes, the apparatus comprising: A registration module, configured to receive a service registration request sent by a first container on a first working node, the service registration request including registration information of a service deployed in the first container; wherein the registration information includes service label information and service access address information; The registration module is further configured to store registration information of the service deployed in the first container in a storage system of the cluster; a discovery module, configured to receive a service discovery request sent by the first container, where the service discovery request is used to discover a second service, and the service discovery request includes label information of the second service; acquiring access address information of the second service from the storage system according to the label information of the second service; Send access address information of the second service to the first container.

13. A service management device, characterized in that: Applied to a working node in a cluster, the cluster includes a master node, multiple working nodes, and a storage system, and a service is deployed in a container on each working node. The device includes: a registration module, configured to, in response to a startup instruction of a first container on a first working node, send a service registration request to a master node through the first container, wherein the service registration request includes label information and access address information of a service deployed in the first container, and the service registration request is used to store the label information and access address information of the service deployed in the first container in a storage system of the cluster; a discovery module, configured to send a service discovery request to the master node through the first container when the first service in the first container needs to call the second service, where the service discovery request includes label information of the second service; receiving, through the first container, access address information of the second service sent by the master node; The second service is called according to the access address information of the second service.

14. A service management device, characterized in that: include: a processor, a memory, and a computer program stored on the memory and executable on the processor; Wherein, when the processor runs the computer program, the method according to any one of claims 1 to 11 is implemented.

15. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 11 is implemented.

16. A computer program product, characterized in that A computer program is included which, when executed by a processor, implements the method according to any one of claims 1 to 11.

Images