CN112486629B - Micro-service state detection method, micro-service state detection device, electronic equipment and storage medium - Google Patents
Micro-service state detection method, micro-service state detection device, electronic equipment and storage medium Download PDFInfo
- Publication number
- CN112486629B CN112486629B CN202011359305.3A CN202011359305A CN112486629B CN 112486629 B CN112486629 B CN 112486629B CN 202011359305 A CN202011359305 A CN 202011359305A CN 112486629 B CN112486629 B CN 112486629B
- Authority
- CN
- China
- Prior art keywords
- container
- micro
- service
- information
- version
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000001514 detection method Methods 0.000 title claims description 40
- 238000000034 method Methods 0.000 claims abstract description 35
- 230000005856 abnormality Effects 0.000 claims description 12
- 238000004590 computer program Methods 0.000 claims description 10
- 230000002159 abnormal effect Effects 0.000 claims description 9
- 238000010586 diagram Methods 0.000 description 10
- 230000008569 process Effects 0.000 description 8
- 102100033121 Transcription factor 21 Human genes 0.000 description 7
- 238000004891 communication Methods 0.000 description 7
- 230000006870 function Effects 0.000 description 7
- 101150109289 tcf21 gene Proteins 0.000 description 7
- 238000011161 development Methods 0.000 description 4
- 230000007246 mechanism Effects 0.000 description 4
- 230000009471 action Effects 0.000 description 3
- 238000012790 confirmation Methods 0.000 description 3
- 101100491335 Caenorhabditis elegans mat-2 gene Proteins 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 238000011160 research Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 238000004883 computer application Methods 0.000 description 1
- 230000007547 defect Effects 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000006872 improvement Effects 0.000 description 1
- 230000003993 interaction Effects 0.000 description 1
- 238000012423 maintenance Methods 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- -1 pod2 Proteins 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
- G06F11/302—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a software system
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45533—Hypervisors; Virtual machine monitors
- G06F9/45558—Hypervisor-specific management and integration aspects
- G06F2009/45591—Monitoring or debugging support
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Physics & Mathematics (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- Computer Security & Cryptography (AREA)
- Mathematical Physics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The embodiment of the invention provides a method and a device for detecting a micro-service state, electronic equipment and a storage medium, and relates to the technical field of computer software. After the connection with the Kubernetes cluster which has executed the micro-service publishing operation, the identification information of all the container groups corresponding to the micro-service is obtained, the identification information of all the containers in each container group is obtained according to the identification information of each container group, the version information, the running state information and the restarting times of each container are obtained according to the identification information of each container, and the publishing state of the micro-service is output according to the version information, the running state information and the restarting times of each container. After the Kubernetes cluster executes the micro-service release operation, the micro-service state is detected from multiple dimensions such as version information, running state information and restarting times of the container, so that the release state of the micro-service can be fed back quickly and accurately, and a publisher can know the release result of the micro-service in time.
Description
Technical Field
The present invention relates to the field of computer software technologies, and in particular, to a method and apparatus for detecting a micro service state, an electronic device, and a storage medium.
Background
With the development of computer software technology, computer applications are becoming more powerful and more complex. In order to ensure the development efficiency of applications, applications or services are developed or updated by micro-services. The micro-service can be equivalent to a single project, can be combined with other micro-services to realize a certain function, and can adopt different storage modes, development technologies, programming languages and the like, so that the development of the application or service is simpler and more flexible, and the efficiency is higher.
Kubernetes, abbreviated as k8s, is a Google open-sourced system for managing container clusters that can provide automated deployment, scheduling, maintenance, and cluster management functions for micro services. However, the current micro-service issuing system can only simply send an instruction for updating version information to the k8s cluster, but cannot accurately judge the issuing state of the micro-service, which is unfavorable for the issuer to know the issuing result of the micro-service in time.
Disclosure of Invention
Accordingly, the present invention is directed to a method, an apparatus, an electronic device, and a storage medium for detecting a micro service state, which can quickly and accurately feed back the release state of a micro service after a Kubernetes cluster executes a micro service release operation, so that a publisher can know the release result of the micro service in time.
In order to achieve the above object, the technical scheme adopted by the embodiment of the invention is as follows:
in a first aspect, the present invention provides a method for detecting a micro service state, the method comprising:
after the connection with the Kubernetes cluster which has executed the micro-service release operation, acquiring the identification information of all container groups corresponding to the micro-service;
acquiring the identification information of all containers in each container group according to the identification information of each container group;
according to the identification information of each container, version information, running state information and restarting times of each container are obtained;
and outputting the release state of the micro service according to the version information, the running state information and the restarting times of each container.
In an alternative embodiment, the step of outputting the release state of the micro service according to the version information, the running state information and the number of restarts of each container includes:
if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, and the restarting times of each container are set values, outputting that the release state of the micro-service is normal;
if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting times of at least one container is not the set value, outputting the release state abnormality of the micro service.
In an alternative embodiment, the step of outputting the release state of the micro service according to the version information, the running state information and the number of restarts of each container includes:
if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, and the restarting times of each container are set values, verifying whether an interface corresponding to the micro-service is normal or not;
if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, the restarting times of each container are set values, and the interface corresponding to the micro service is normal, outputting the release state of the micro service to be normal;
if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not the set value, or the interface corresponding to the micro-service is abnormal, outputting the release state abnormality of the micro-service.
In an alternative embodiment, the operational status information of each container includes a first status field, a second status field, and a third status field, and if the value of the first status field indicates that the container has completed initialization, the value of the second status field indicates that the container is capable of providing service, and the value of the third status field indicates that the container has been scheduled, the container update is determined to be successful.
In an optional embodiment, the step of obtaining the identification information of all container groups corresponding to the micro service includes:
and acquiring configuration information corresponding to the micro service, wherein the configuration information comprises identification information of all container groups corresponding to the micro service.
In a second aspect, the present invention provides a micro-service state detection apparatus, the apparatus comprising:
the container group determining module is used for acquiring the identification information of all container groups corresponding to the micro service after being connected with the Kubernetes cluster which has executed the micro service release operation;
the container determining module is used for acquiring the identification information of all containers in each container group according to the identification information of each container group;
the container information acquisition module is used for acquiring version information, running state information and restarting times of each container according to the identification information of each container;
and the state detection module is used for outputting the release state of the micro service according to the version information, the running state information and the restarting times of each container.
In an optional embodiment, the state detection module is configured to output that the release state of the micro service is normal if the version information of each container is matched with the target update version, the running state information of each container indicates that the container is successfully updated, and the restart times of each container are set values; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting times of at least one container is not the set value, outputting the release state abnormality of the micro service.
In an optional embodiment, the state detection module is configured to verify whether an interface corresponding to the micro service is normal if version information of each container is matched with a target update version, running state information of each container indicates that the container is successfully updated, and restart times of each container are set values; if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, the restarting times of each container are set values, and the interface corresponding to the micro service is normal, outputting the release state of the micro service to be normal; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not the set value, or the interface corresponding to the micro-service is abnormal, outputting the release state abnormality of the micro-service.
In a third aspect, the invention provides an electronic device comprising a processor and a memory, the memory storing a computer program, the processor implementing the method of any of the preceding embodiments when executing the computer program.
In a fourth aspect, the present invention provides a computer readable storage medium having stored thereon a computer program which, when executed by a processor, implements a method according to any of the preceding embodiments.
The method, the device, the electronic equipment and the storage medium for detecting the micro service state acquire the identification information of all the container groups corresponding to the micro service after being connected with the Kubernetes cluster which has executed the micro service release operation, acquire the identification information of all the containers in each container group according to the identification information of each container group, acquire the version information, the running state information and the restarting times of each container according to the identification information of each container, and output the release state of the micro service according to the version information, the running state information and the restarting times of each container. After the Kubernetes cluster executes the micro-service release operation, the micro-service state is detected from multiple dimensions such as version information, running state information and restarting times of the container, so that the release state of the micro-service can be fed back quickly and accurately, a publisher can know the release result of the micro-service in time, and an accurate and effective release confirmation mechanism is provided for a continuous release system integrating flow tasks.
In order to make the above objects, features and advantages of the present invention more comprehensible, preferred embodiments accompanied with figures are described in detail below.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings that are needed in the embodiments will be briefly described below, it being understood that the following drawings only illustrate some embodiments of the present invention and therefore should not be considered as limiting the scope, and other related drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 illustrates a schematic diagram of an application environment suitable for use with embodiments of the present invention;
FIG. 2 shows a block diagram of an electronic device according to an embodiment of the present invention;
FIG. 3 is a schematic flow chart of a method for detecting a micro service state according to an embodiment of the present invention;
fig. 4 is a functional block diagram of a micro service state detection device according to an embodiment of the present invention.
Icon: 100-an electronic device; 200-network; 300-Kubernetes cluster; 600-micro service state detection means; 101-a client; 110-memory; a 120-processor; 130-a communication module; 610-a container group determination module; 620-a container determination module; 630-a container information acquisition module; 640-state detection module.
Detailed Description
The following description of the embodiments of the present invention will be made clearly and completely with reference to the accompanying drawings, in which it is apparent that the embodiments described are only some embodiments of the present invention, but not all embodiments. The components of the embodiments of the present invention generally described and illustrated in the figures herein may be arranged and designed in a wide variety of different configurations.
Thus, the following detailed description of the embodiments of the invention, as presented in the figures, is not intended to limit the scope of the invention, as claimed, but is merely representative of selected embodiments of the invention. All other embodiments, which can be made by a person skilled in the art without making any inventive effort, are intended to be within the scope of the present invention.
It is noted that relational terms such as "first" and "second", and the like, are used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Moreover, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising one … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
In the process of realizing the technical scheme of the embodiment of the invention, the inventor researches that after the k8s cluster executes the micro-service release operation, the release state of the micro-service cannot be fed back to the publisher quickly and accurately, so that the situation that the publisher cannot perceive the release result later after one micro-service is rolled and released often occurs. Although the commands provided by the native k8s shell and API (Application Program Interface) can query the running states of the corresponding discover (configuration) and pod (container set) of the micro-service, in some scenarios, when the queried running state of the pod is running (surviving), it is possible that the micro-service internal program is in a cycle of continually crashing and restarting, so the commands provided by the conventional k8s shell or API cannot effectively judge whether the micro-service is issued successfully or not, i.e. the prior art lacks a mechanism capable of accurately detecting the micro-service issuing state.
Based on the researches on the defects, the embodiment of the invention provides a micro-service state detection method, a micro-service state detection device, an electronic device and a storage medium, which detect the micro-service state from a plurality of dimensions such as version information, running state information, restarting times and the like of a container after performing micro-service release operation, so that the release state of the micro-service is fed back rapidly and accurately, and a publisher is enabled to know the release result of the micro-service in time. Embodiments of the present invention will be described in detail below with reference to the accompanying drawings.
Fig. 1 is a schematic view of an application environment suitable for an embodiment of the present invention. The electronic device 100 may communicate with the Kubernetes cluster 300 over the network 200. Kubernetes cluster 300 may include a plurality of nodes with micro services running on each node; a client 101 may be installed in the electronic device 100, and the client 101 is used to communicate with any node in the Kubernetes cluster 300 to implement access to a resource object in the Kubernetes cluster 300. Among them, the electronic device 100 includes, but is not limited to, a personal computer, a notebook computer, a smart phone, a tablet computer, etc.
Fig. 2 is a block diagram of an electronic device 100 according to an embodiment of the invention. The electronic device 100 includes a memory 110, a processor 120, and a communication module 130. The memory 110, the processor 120, and the communication module 130 are electrically connected directly or indirectly to each other to realize data transmission or interaction. For example, the components may be electrically connected to each other via one or more communication buses or signal lines.
Wherein the memory 110 is used for storing programs or data. The Memory 110 may be, but is not limited to, random access Memory (Random Access Memory, RAM), read Only Memory (ROM), programmable Read Only Memory (Programmable Read-Only Memory, PROM), erasable Read Only Memory (Erasable Programmable Read-Only Memory, EPROM), electrically erasable Read Only Memory (Electric Erasable Programmable Read-Only Memory, EEPROM), etc.
The processor 120 is used to read/write data or programs stored in the memory 110 and perform corresponding functions. For example, the micro service state detection method disclosed in the embodiment of the present invention may be implemented when the processor 120 executes a computer program stored in the memory 110.
The communication module 130 is configured to establish a communication connection between the electronic device 100 and other communication terminals (such as nodes in the Kubernetes cluster 300) through the network 200, and is configured to transmit and receive data through the network 200.
It should be understood that the structure shown in fig. 2 is merely a schematic diagram of the structure of the electronic device 100, and that the electronic device 100 may also include more or fewer components than shown in fig. 2, or have a different configuration than shown in fig. 2. The components shown in fig. 2 may be implemented in hardware, software, or a combination thereof.
Embodiments of the present invention also provide a computer-readable storage medium having stored thereon a computer program that, when executed by the processor 120, may implement the micro service state detection method disclosed in the embodiments of the present invention.
Referring to fig. 3, a flow chart of a method for detecting a micro service state according to an embodiment of the invention is shown. It should be noted that, the method for detecting a micro service state provided in the embodiment of the present invention is not limited by fig. 3 and the specific sequence below, and it should be understood that, in other embodiments, the sequence of part of the steps in the method for detecting a micro service state provided in the embodiment of the present invention may be interchanged according to actual needs, or part of the steps may be omitted or deleted. The micro service state detection method may be applied to the electronic device 100 shown in fig. 1, and a specific flow shown in fig. 3 will be described in detail.
Step S301, after the connection with the Kubernetes cluster that has performed the micro service publishing operation, obtains the identification information of all container groups corresponding to the micro service.
In this embodiment, after the Kubernetes cluster 300 performs the micro-service publishing operation, the electronic device 100 may connect to the Kubernetes cluster 300 through the client 101, and obtain, through the client 101, identification information of all container groups (pod) corresponding to the micro-service. A group of containers is understood to be a collection of containers, and a group of containers may include one or more containers. The client 101 may be client-go.
In this embodiment, the identification information of the container group may be information for uniquely identifying the container group, such as a name of the container group, and by acquiring identification information of all container groups corresponding to the micro service, it is possible to determine which pod corresponds to the micro service. For example, the microservice corresponds to three container groups, named pod1, pod2, pod3, respectively.
Step S302, according to the identification information of each container group, the identification information of all containers in each container group is obtained.
In this embodiment, after acquiring the identification information of all the container groups through the client 101, the electronic device 100 traverses the identification information of each container group, and revisits the Kubernetes cluster 300 by using the client 101 to acquire the identification information of all the containers in each container group, so as to determine which containers each container group includes. The identification information of the container may be information for uniquely identifying the container, such as a name of the container. For example, the container group pod1 includes two containers, which are named as docker1 and docker2 respectively; the container group pod2 comprises two containers, and the names of the two containers are respectively dock 3 and dock 4; the container group pod3 comprises two containers, and the names of the two containers are respectively docker5 and docker6.
Step S303, according to the identification information of each container, the version information, the running state information and the restarting times of each container are obtained.
In this embodiment, after acquiring the identification information of all the containers in each container group through the client 101, the electronic device 100 traverses the identification information of each container, and revisits the Kubernetes cluster 300 by using the client 101 to acquire the version information, the running state information and the restart times corresponding to each container.
Step S304, outputting the release state of the micro-service according to the version information, the running state information and the restarting times of each container.
In this embodiment, the electronic device 100 performs comprehensive judgment on the obtained version information, running state information and restarting times of each container, and determines the release state of the micro service, so as to feed back an intuitive and accurate release result to the publisher.
According to the micro-service state detection method provided by the embodiment of the invention, after the micro-service state detection method is connected with the Kubernetes cluster 300 which has executed micro-service release operation, identification information of all container groups corresponding to micro-service is obtained, identification information of all containers in each container group is obtained according to the identification information of each container group, version information, running state information and restarting times of each container are obtained according to the identification information of each container, and release states of the micro-service are output according to the version information, the running state information and the restarting times of each container. After the Kubernetes cluster 300 executes the micro-service publishing operation, the micro-service state is detected from multiple dimensions such as version information, running state information and restarting times of the container, so that the publishing state of the micro-service can be fed back quickly and accurately, a publisher can know the publishing result of the micro-service timely, and an accurate and effective publishing confirmation mechanism is provided for the continuous publishing system with integrated flow tasks.
Optionally, the step S301 may include: and acquiring configuration information corresponding to the micro-service, wherein the configuration information comprises identification information of all container groups corresponding to the micro-service.
In this embodiment, the content of all the container groups corresponding to the micro-service is predefined in the configuration (default) information, and after the electronic device 100 obtains the default information of the micro-service, the identification information of all the container groups corresponding to the micro-service may be obtained through the default information.
Optionally, in an embodiment, the step S304 may include: if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, and the restarting times of each container are set values, the release state of the output micro-service is normal; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not set value, outputting the release state abnormality of the micro service.
In this embodiment, the target updated version may be understood as a version of the newly released micro-service, such as version V3; when the version information of the container is not matched with the target updated version, the fact that the version information is not updated completely is indicated, and the release of the container is unsuccessful or the release is not completed. The set value may be 0, indicating that the container is still restarting or not yet issued when the number of restarting of the container is not 0.
In this embodiment, the running status information of each container includes a first status field, a second status field, and a third status field, and if the value of the first status field indicates that the container has completed initialization, the value of the second status field indicates that the container is capable of providing services, and the value of the third status field indicates that the container has been scheduled, then it is determined that the container update is successful.
For example, the first status field is set to Initialized, when a certain container has been Initialized, the Initialized value will be set to true, otherwise, will be set to false; setting the second status field as Ready, when a certain container can provide service, setting the value of Ready to true, otherwise setting false; the third status field is set to PodSchedule, and when a certain container has been scheduled successfully, the value of PodSchedule will be set to true, otherwise, will be set to false. Thus, for each container's operational status information, the operational status information characterizes the container's update as successful only if the values of the three fields Initialized, ready and podschedule are true; if the conditions for the values of the three fields Initialized, ready and PodScheduled are all true are not satisfied, then this indicates that the container is still restarting or that the release is not complete.
In the following, the detection process will be described in detail by taking the case that the microservice corresponds to two container groups (i.e., pod1 and pod 2), the container group pod1 includes two containers (dock 1 and dock 2), and the container group pod2 includes two containers (dock 3 and dock 4). The electronic device 100 starts from the container group pod1, firstly obtains the version information, the running state information and the restarting times of the container docker1 in the container group pod1, when the version information is matched with the target updated version, the values of the three fields Initialized, ready and PodScheduled in the running state information are true and the restarting times are 0, continues to obtain the version information, the running state information and the restarting times of the container docker2 in the container group pod1, when the version information is matched with the target updated version, the values of the three fields Initialized, ready and PodScheduled in the running state information are true and the restarting times are 0, continues to obtain the version information, the running state information and the restarting times of the container docker3 in the container group pod2, when the version information is matched with the target updated version, the values of the three fields Initialized, ready and PodScheduled in the running state information are true and the restarting times are 0, and the version information, and the running state information and the restarting times of the service information in the container group pod2 are equal to each other, and the running state information and the restarting times of the service is equal to the normal conditions are judged that the running state information and the restarting times of the service is slightly met under the conditions are issued when the running state information and the running state information is equal to the normal. Correspondingly, when the version information or the running state information or the restarting times of any container in the detection process do not meet the corresponding conditions, the micro-service is judged to be unsuccessfully released (the micro-service is failed to be updated), and the release state of the micro-service is output to be abnormal.
In practical application, the electronic device 100 may not limit the detection sequence of the version information, the running state information and the restarting times of each container in the process of outputting the release state of the micro service according to the version information, the running state information and the restarting times of each container.
According to the micro-service state detection method provided by the embodiment of the invention, by detecting whether the version information of all the containers corresponding to the micro-service is matched with the target update version, detecting whether the running state information of all the containers represents successful updating of the containers and detecting whether the restarting times of all the containers are set values or not, the effective judgment of the micro-service state is realized through multiple dimensions such as the version information, the running state information and the restarting times of the containers, so that the release state of the micro-service can be fed back quickly and accurately, and a publisher can know the release result of the micro-service timely.
Optionally, in practical application, in order to further improve accuracy of detecting the release state of the micro service, under the condition that version information, running state information and restarting times of all containers corresponding to the micro service meet corresponding conditions, the interface calling condition of the micro service can be further verified, and then the release state of the micro service is determined based on the detection results of the containers and the interfaces of the micro service.
Based on this, another implementation manner is provided in the embodiment of the present invention, that is, the step S304 may include: if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, and the restarting times of each container are set values, verifying whether an interface corresponding to the micro-service is normal or not; if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, the restarting times of each container are set values, and the interface corresponding to the micro service is normal, the release state of the output micro service is normal; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not set value, or the interface corresponding to the micro-service is abnormal, outputting the release state abnormality of the micro-service.
The detection process of version information, running state information and restarting times of all containers corresponding to the micro service is consistent with the foregoing embodiment, and will not be repeated here. The difference from the foregoing embodiment is that, in the case where version information, running state information, and the number of restarts of all containers corresponding to the micro service meet the corresponding conditions, it is not directly determined that the release state of the micro service is normal, but it is further verified whether the interface corresponding to the micro service is normal, if the interface is normal, the program is already able to normally provide the service, at this time, the release state of the output micro service is normal, if the interface is abnormal, it is indicated that the release of the micro service is unsuccessful, at this time, the release state of the output micro service is abnormal.
According to the method for detecting the micro-service state, provided by the embodiment of the invention, by detecting whether the version information of all the containers corresponding to the micro-service is matched with the target update version, detecting whether the running state information of all the containers represents successful updating of the containers, detecting whether the restarting times of all the containers are set values or not, and detecting whether the interfaces corresponding to the micro-service are normal or not, the effective judgment of the micro-service state is realized through multiple dimensions such as the version information, the running state information and the restarting times of the containers, the interface calling condition of the micro-service and the like, and the detection accuracy of the issuing state of the micro-service is further improved.
In order to perform the corresponding steps of the above embodiments and of the various possible ways, an implementation of the micro-service state detection device is given below. Referring to fig. 4, fig. 4 is a functional block diagram of a micro service state detection apparatus 600 according to an embodiment of the invention. It should be noted that, the basic principle and the technical effects of the micro service state detection apparatus 600 provided in this embodiment are the same as those of the above embodiment, and for brevity, reference should be made to the corresponding contents of the above embodiment. The micro service state detection apparatus 600 includes a container group determination module 610, a container determination module 620, a container information acquisition module 630, and a state detection module 640.
Alternatively, the above modules may be stored in the memory 110 shown in fig. 2 or solidified in an Operating System (OS) of the electronic device 100 in the form of software or Firmware (Firmware), and may be executed by the processor 120 in fig. 2. Meanwhile, data, codes of programs, and the like, which are required to execute the above-described modules, may be stored in the memory 110.
The container group determining module 610 is configured to obtain identification information of all container groups corresponding to the micro service after connecting with the Kubernetes cluster 300 that has performed the micro service publishing operation.
The container group determining module 610 is specifically configured to obtain configuration information corresponding to the micro service, where the configuration information includes identification information of all container groups corresponding to the micro service.
It is understood that the container group determination module 610 may perform the above step S301.
The container determining module 620 is configured to obtain identification information of all containers in each container group according to the identification information of each container group.
It is understood that the container determination module 620 may perform step S302 described above.
The container information obtaining module 630 is configured to obtain version information, running state information, and restart times of each container according to the identification information of each container.
It is understood that the container information obtaining module 630 may perform the above step S303.
The state detection module 640 is configured to output a release state of the micro service according to version information, running state information, and the number of restarts of each container.
It is understood that the state detection module 640 may perform the above step S304.
Optionally, in an embodiment, the state detection module 640 is specifically configured to, if the version information of each container matches the target update version, the running state information of each container indicates that the container is successfully updated, and the number of restarting times of each container is set, output that the release state of the micro service is normal; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not set value, outputting the release state abnormality of the micro service.
Optionally, in another embodiment, the state detection module 640 is configured to verify whether the interface corresponding to the micro service is normal if the version information of each container matches the target update version, the running state information of each container indicates that the container is successfully updated, and the restart times of each container are set values; if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, the restarting times of each container are set values, and the interface corresponding to the micro service is normal, the release state of the output micro service is normal; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not set value, or the interface corresponding to the micro-service is abnormal, outputting the release state abnormality of the micro-service.
Wherein the running status information of each container includes a first status field, a second status field, and a third status field, and the status detection module 640 is configured to determine that the container update is successful if the value of the first status field indicates that the container has completed initialization, the value of the second status field indicates that the container is capable of providing services, and the value of the third status field indicates that the container has been scheduled.
In the micro service state detection device 600 provided in the embodiment of the present invention, after the container group determining module 610 is connected to the Kubernetes cluster 300 that has performed the micro service publishing operation, the identification information of all the container groups corresponding to the micro service is obtained, the identification information of all the containers in each container group is obtained by the container determining module 620 according to the identification information of each container group, the version information, the running state information and the restarting times of each container are obtained by the container information obtaining module 630 according to the identification information of each container, and the publishing state of the micro service is output by the state detecting module 640 according to the version information, the running state information and the restarting times of each container. After the Kubernetes cluster 300 executes the micro-service publishing operation, the micro-service state is detected from multiple dimensions such as version information, running state information and restarting times of the container, so that the publishing state of the micro-service can be fed back quickly and accurately, a publisher can know the publishing result of the micro-service timely, and an accurate and effective publishing confirmation mechanism is provided for the continuous publishing system with integrated flow tasks.
In the several embodiments provided in this application, it should be understood that the disclosed apparatus and method may be implemented in other manners as well. The apparatus embodiments described above are merely illustrative, for example, of the flowcharts and block diagrams in the figures that illustrate the architecture, functionality, and operation of possible implementations of apparatus, methods and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams and/or flowchart illustration, and combinations of blocks in the block diagrams and/or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
In addition, functional modules in the embodiments of the present invention may be integrated together to form a single part, or each module may exist alone, or two or more modules may be integrated to form a single part.
The functions, if implemented in the form of software functional modules and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, comprising several instructions for causing a computer device (which may be a personal computer, a server, a network device, etc.) to perform all or part of the steps of the method according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (RAM, random Access Memory), a magnetic disk, or an optical disk, or other various media capable of storing program codes.
The above description is only of the preferred embodiments of the present invention and is not intended to limit the present invention, but various modifications and variations can be made to the present invention by those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present invention should be included in the protection scope of the present invention.
Claims (10)
1. A method for detecting a micro-service state, the method comprising:
after the connection with the Kubernetes cluster which has executed the micro-service release operation, acquiring the identification information of all container groups corresponding to the micro-service;
acquiring the identification information of all containers in each container group according to the identification information of each container group;
according to the identification information of each container, version information, running state information and restarting times of each container are obtained;
and outputting the release state of the micro service according to the version information, the running state information and the restarting times of each container.
2. The method of claim 1, wherein the step of outputting the distribution state of the micro service according to the version information, the running state information, and the number of restarts of each of the containers comprises:
if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, and the restarting times of each container are set values, outputting that the release state of the micro-service is normal;
if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting times of at least one container is not the set value, outputting the release state abnormality of the micro service.
3. The method of claim 1, wherein the step of outputting the distribution state of the micro service according to the version information, the running state information, and the number of restarts of each of the containers comprises:
if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, and the restarting times of each container are set values, verifying whether an interface corresponding to the micro-service is normal or not;
if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, the restarting times of each container are set values, and the interface corresponding to the micro service is normal, outputting the release state of the micro service to be normal;
if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not the set value, or the interface corresponding to the micro-service is abnormal, outputting the release state abnormality of the micro-service.
4. A method according to claim 2 or 3, wherein the operational status information for each of the containers comprises a first status field, a second status field and a third status field, and wherein the container update is determined to be successful if the value of the first status field indicates that the container has been initialized, the value of the second status field indicates that the container is capable of providing service and the value of the third status field indicates that the container has been scheduled.
5. A method according to any one of claims 1-3, wherein the step of obtaining identification information of all container groups corresponding to the micro-service comprises:
and acquiring configuration information corresponding to the micro service, wherein the configuration information comprises identification information of all container groups corresponding to the micro service.
6. A micro service state detection apparatus, the apparatus comprising:
the container group determining module is used for acquiring the identification information of all container groups corresponding to the micro service after being connected with the Kubernetes cluster which has executed the micro service release operation;
the container determining module is used for acquiring the identification information of all containers in each container group according to the identification information of each container group;
the container information acquisition module is used for acquiring version information, running state information and restarting times of each container according to the identification information of each container;
and the state detection module is used for outputting the release state of the micro service according to the version information, the running state information and the restarting times of each container.
7. The apparatus of claim 6, wherein the state detection module is configured to output that the release state of the micro service is normal if the version information of each container matches a target update version, the running state information of each container indicates that the container is successfully updated, and the number of times of restarting each container is set; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting times of at least one container is not the set value, outputting the release state abnormality of the micro service.
8. The apparatus of claim 6, wherein the state detection module is configured to verify whether an interface corresponding to the micro service is normal if version information of each container matches a target update version, running state information of each container indicates that the container is successfully updated, and a number of times of restarting each container is set as a set value; if the version information of each container is matched with the target update version, the running state information of each container represents that the container is successfully updated, the restarting times of each container are set values, and the interface corresponding to the micro service is normal, outputting the release state of the micro service to be normal; if the version information of at least one container is not matched with the target updated version, or the running state information of at least one container indicates that the container is not updated successfully, or the restarting frequency of at least one container is not the set value, or the interface corresponding to the micro-service is abnormal, outputting the release state abnormality of the micro-service.
9. An electronic device comprising a processor and a memory, the memory storing a computer program, the processor implementing the method of any one of claims 1-5 when executing the computer program.
10. A computer readable storage medium, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any of claims 1-5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011359305.3A CN112486629B (en) | 2020-11-27 | 2020-11-27 | Micro-service state detection method, micro-service state detection device, electronic equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011359305.3A CN112486629B (en) | 2020-11-27 | 2020-11-27 | Micro-service state detection method, micro-service state detection device, electronic equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112486629A CN112486629A (en) | 2021-03-12 |
| CN112486629B true CN112486629B (en) | 2024-01-26 |
Family
ID=74935983
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011359305.3A Active CN112486629B (en) | 2020-11-27 | 2020-11-27 | Micro-service state detection method, micro-service state detection device, electronic equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112486629B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113010266A (en) * | 2021-03-17 | 2021-06-22 | 北京金山云网络技术有限公司 | Cloud service restarting method and device |
| CN113590213B (en) * | 2021-06-24 | 2023-04-25 | 深圳开源互联网安全技术有限公司 | Component maintenance method, electronic device and storage medium |
| CN113485896A (en) * | 2021-07-22 | 2021-10-08 | 京东方科技集团股份有限公司 | Container state monitoring method, device, system and medium |
| CN113515297B (en) * | 2021-08-12 | 2023-09-26 | 深圳市晨北科技有限公司 | Version updating method and device, electronic equipment and storage medium |
| CN113656144B (en) * | 2021-08-17 | 2023-08-11 | 百度在线网络技术（北京）有限公司 | Data release system, method and device, electronic equipment and storage medium |
| CN113835974B (en) * | 2021-11-29 | 2022-03-01 | 深圳市明源云科技有限公司 | Supervision method and device for k8s cluster and computer readable storage medium |
| CN114168951B (en) * | 2022-02-11 | 2022-08-16 | 阿里云计算有限公司 | Abnormality detection method and apparatus |
| CN115174644B (en) * | 2022-06-28 | 2023-09-12 | 武汉烽火技术服务有限公司 | Container cluster service start-stop control method, device, equipment and storage medium |
Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017205222A1 (en) * | 2016-05-23 | 2017-11-30 | William Turner | Hyperconverged system including a core layer, a user interface, and a services layer equipped with a container-based user space |
| CN108038051A (en) * | 2017-11-03 | 2018-05-15 | 深圳市牛鼎丰科技有限公司 | Dissemination method, device, computer equipment and the storage medium of micro services |
| CN109542639A (en) * | 2018-11-06 | 2019-03-29 | 用友网络科技股份有限公司 | A kind of processing method, processing unit for ensureing micro services and calling data consistency |
| KR101998564B1 (en) * | 2018-07-19 | 2019-07-10 | 나무기술 주식회사 | Multi-cluster provisioning and managing method on cloud platform |
| CN110266872A (en) * | 2019-05-30 | 2019-09-20 | 世纪龙信息网络有限责任公司 | Management-control method, device and the cloud address book system of address book data |
| CN110427249A (en) * | 2019-07-26 | 2019-11-08 | 重庆紫光华山智安科技有限公司 | Method for allocating tasks, pod initial method and relevant apparatus |
| CN111143069A (en) * | 2019-12-27 | 2020-05-12 | 杭州数梦工场科技有限公司 | Service management method, device, electronic equipment and storage medium |
| WO2020121172A1 (en) * | 2018-12-10 | 2020-06-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Network function upgrade method, system and apparatus |
| CN111858001A (en) * | 2020-07-15 | 2020-10-30 | 武汉众邦银行股份有限公司 | Workflow processing method based on micro-service architecture system |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10241778B2 (en) * | 2016-09-27 | 2019-03-26 | Ca, Inc. | Microservices version state visualization |
| US10712968B2 (en) * | 2017-04-11 | 2020-07-14 | EMC IP Holding Company LLC | Management of state information backup for an auxiliary storage service in a microservice architecture |
| US10621005B2 (en) * | 2017-08-31 | 2020-04-14 | Oracle International Corporation | Systems and methods for providing zero down time and scalability in orchestration cloud services |
| US20190332522A1 (en) * | 2018-04-27 | 2019-10-31 | Satori Worldwide, Llc | Microservice platform with messaging system |
| JP7257537B2 (en) * | 2018-10-31 | 2023-04-13 | インフォブロックス・インコーポレーテッド | Decoupled cloud-native network architecture |
| US11184241B2 (en) * | 2019-02-08 | 2021-11-23 | International Business Machines Corporation | Topology-aware continuous evaluation of microservice-based applications |
| US11012520B2 (en) * | 2019-03-11 | 2021-05-18 | International Business Machines Corporation | Manage a network of microservices |
-
2020
- 2020-11-27 CN CN202011359305.3A patent/CN112486629B/en active Active
Patent Citations (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2017205222A1 (en) * | 2016-05-23 | 2017-11-30 | William Turner | Hyperconverged system including a core layer, a user interface, and a services layer equipped with a container-based user space |
| CN108038051A (en) * | 2017-11-03 | 2018-05-15 | 深圳市牛鼎丰科技有限公司 | Dissemination method, device, computer equipment and the storage medium of micro services |
| KR101998564B1 (en) * | 2018-07-19 | 2019-07-10 | 나무기술 주식회사 | Multi-cluster provisioning and managing method on cloud platform |
| CN109542639A (en) * | 2018-11-06 | 2019-03-29 | 用友网络科技股份有限公司 | A kind of processing method, processing unit for ensureing micro services and calling data consistency |
| WO2020121172A1 (en) * | 2018-12-10 | 2020-06-18 | Telefonaktiebolaget Lm Ericsson (Publ) | Network function upgrade method, system and apparatus |
| CN110266872A (en) * | 2019-05-30 | 2019-09-20 | 世纪龙信息网络有限责任公司 | Management-control method, device and the cloud address book system of address book data |
| CN110427249A (en) * | 2019-07-26 | 2019-11-08 | 重庆紫光华山智安科技有限公司 | Method for allocating tasks, pod initial method and relevant apparatus |
| CN111143069A (en) * | 2019-12-27 | 2020-05-12 | 杭州数梦工场科技有限公司 | Service management method, device, electronic equipment and storage medium |
| CN111858001A (en) * | 2020-07-15 | 2020-10-30 | 武汉众邦银行股份有限公司 | Workflow processing method based on micro-service architecture system |
Non-Patent Citations (4)
| Title |
|---|
| Dynamic On-Demand Fog Formation Offering On-the-Fly IoT Service Deployment;H. Sami and A. Mourad;《EEE Transactions on Network and Service Management》;全文 * |
| 一种基于执行轨迹监测的微服务故障诊断方法;王子勇;王焘;张文博;陈宁江;左春;;软件学报(06);全文 * |
| 基于Kubernetes容器集群资源调度策略研究;马希琳;《中国优秀博硕士学位论文全文数据库（硕士）信息科技辑》;全文 * |
| 基于微服务的分布式应用配置管理平台研究与实践;刘星;《中国优秀博硕士学位论文全文数据库（硕士）信息科技辑》;全文 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112486629A (en) | 2021-03-12 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN112486629B (en) | Micro-service state detection method, micro-service state detection device, electronic equipment and storage medium | |
| CN110191018B (en) | Abnormity monitoring method and device for vehicle CAN bus and computer equipment | |
| CN107733708B (en) | Equipment parameter configuration method and device, computer equipment and storage medium | |
| EP3575975B1 (en) | Method and apparatus for operating smart network interface card | |
| CN108347476B (en) | Cross-machine-room data synchronization method and device and server | |
| CN110222535B (en) | Processing device, method and storage medium for block chain configuration file | |
| CN110147241A (en) | Program configures update method, electronic device, computer equipment and storage medium | |
| CN110865835A (en) | Configuration file updating method and device, computer equipment and storage medium | |
| CN110784348A (en) | Firmware upgrading method and device, electronic equipment and storage medium | |
| CN111506358B (en) | Method and device for updating container configuration | |
| CN107203464B (en) | Method and device for positioning service problem | |
| US8099628B2 (en) | Software problem identification tool | |
| CN110874311A (en) | Database detection method and device, computer equipment and storage medium | |
| CN113672306A (en) | Server component self-checking abnormity recovery method, device, system and medium | |
| CN109218338B (en) | Information processing system, method and device | |
| CN113806138A (en) | Backup recovery detection method and device for database, electronic equipment and storage medium | |
| CN110752972A (en) | Network card state monitoring method, device, equipment and medium | |
| CN115543759A (en) | Log lookup method and device for operating system, electronic device and storage medium | |
| CN110045971A (en) | System upgrade restoration methods and device | |
| CN110752950A (en) | Update detection method and device for cloud resource pool and terminal equipment | |
| CN113726779A (en) | Rule false alarm test method and device, electronic equipment and computer storage medium | |
| CN111782515A (en) | Web application state detection method and device, server and storage medium | |
| CN111984484A (en) | Non-invasive micro-service access method and system | |
| CN116743990B (en) | Video stream testing method and video stream testing processing method of embedded equipment | |
| CN117453665B (en) | Data processing method, device, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |