CN112579397A - Service online self-checking method, device, equipment and storage medium - Google Patents
Service online self-checking method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN112579397A CN112579397A CN202011573351.3A CN202011573351A CN112579397A CN 112579397 A CN112579397 A CN 112579397A CN 202011573351 A CN202011573351 A CN 202011573351A CN 112579397 A CN112579397 A CN 112579397A
- Authority
- CN
- China
- Prior art keywords
- instance
- target service
- preset
- judgment result
- survival
- 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.)
- Granted
Links
- 238000000034 method Methods 0.000 title claims abstract description 69
- 230000004083 survival effect Effects 0.000 claims abstract description 127
- 230000015654 memory Effects 0.000 claims description 32
- 230000002159 abnormal effect Effects 0.000 claims description 22
- 238000005096 rolling process Methods 0.000 claims description 8
- 238000012360 testing method Methods 0.000 claims description 3
- 230000008569 process Effects 0.000 abstract description 23
- 238000005516 engineering process Methods 0.000 abstract description 6
- 238000010586 diagram Methods 0.000 description 8
- 238000012545 processing Methods 0.000 description 8
- 230000006870 function Effects 0.000 description 5
- 230000001360 synchronised effect Effects 0.000 description 4
- 238000007689 inspection Methods 0.000 description 2
- 239000000463 material Substances 0.000 description 2
- 238000012544 monitoring process Methods 0.000 description 2
- 230000003068 static effect Effects 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000003491 array Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 230000003287 optical effect Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
- G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3668—Software testing
- G06F11/3672—Test management
- G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Hardware Design (AREA)
- Stored Programmes (AREA)
- Debugging And Monitoring (AREA)
Abstract
The application relates to a service online self-checking method, a device, equipment and a storage medium, wherein the method comprises the following steps: according to the technical scheme, firstly, the operation parameters of the target service operated in each instance are obtained, the survival state of each instance is determined, then whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not is judged, if yes, the service package corresponding to the target service operated at present in the instance is stored in a preset file system, and if not, the target service package corresponding to the target service of the previous version is obtained from the preset file system, so that the target service in each instance is rolled back to the previous version by using the target service package. Therefore, the whole process of online service can realize self-checking, the dependence on manpower is greatly reduced, and the problems of low efficiency and high missing rate of checking the online service process by the manpower in the related technology are solved.
Description
Technical Field
The present application relates to the field of service online technologies, and in particular, to a service online self-checking method, device, equipment, and storage medium.
Background
Under the existing micro-service architecture, the process of service online generally includes that a developer submits a bottom code of the service to a GitLab, then Jenkins pulls the bottom code submitted by the developer from the GitLab, the service is constructed according to the bottom code, and then the service is deployed to a corresponding instance.
In order to ensure that the service has higher stability after being deployed to the instance, in the related technology, a developer in charge of the service online can manually check whether the service normally runs in each instance and whether the versions of the service running in each instance are consistent, and can check the calling amount, the performance and the like of the service after the service is online.
Disclosure of Invention
In order to solve the problems of low efficiency and high missing rate of manual inspection in the service online process in the related technology, the application provides a service online self-inspection method, device, equipment and storage medium.
According to a first aspect of the present application, a method for self-checking online service is provided, which includes:
acquiring operation parameters of a target service operated in each instance, and determining the survival state of each instance;
judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not;
if yes, storing a service package corresponding to the target service currently running in the instance into a preset file system;
and if not, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and rolling back the target service in each instance to the previous version by using the target service package.
In an alternative embodiment, said determining the survival status of said instance comprises
Sending a request message to the instance and starting a timer;
if the timer is timed to a preset time period, receiving data returned by the instance according to the request message, and determining that the survival state of the instance is survival;
and if the data returned by the instance according to the request message is not received within the preset time period timed by the timer, determining that the survival state of the instance is non-survival.
In an optional embodiment, the operation parameter includes an operation log of the target service, a version number of the target service, and an operation status parameter of the target service;
the judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions includes:
judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition to obtain a first judgment result;
judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not to obtain a second judgment result;
judging whether the running state parameters of the target service meet a third preset sub-condition or not to obtain a third judgment result;
if the first judgment result, the second judgment result and the third judgment result are all satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions;
and if at least one of the first judgment result, the second judgment result and the third judgment result is not satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not satisfy preset conditions.
In an optional embodiment, the determining whether the survival status of each instance and the running log of the target service run by each instance satisfy a first preset sub-condition to obtain a first determination result includes:
if the survival state of each instance is survival and the running log of the target service run by each instance comprises a preset identifier, the first judgment result is satisfied;
if the survival status of at least one instance is non-survival, or the running log of the target service run by at least one instance does not include a preset identifier, the first judgment result is unsatisfied.
In an optional embodiment, the determining whether the version number of the target service run by each instance satisfies a second preset sub-condition to obtain a second determination result includes:
if the version number of the target service operated by each instance is a pre-acquired latest generated version number, the second judgment result is satisfied;
and if the version number of the target service operated by at least one instance is not the latest pre-acquired version number, the second judgment result is not satisfied.
In an optional embodiment, the operation state parameters at least include a call amount of the target service, an amount of abnormal information, and a performance parameter value;
judging whether the running state parameter of the target service meets a third preset sub-condition to obtain a third judgment result, wherein the third judgment result comprises the following steps:
if the call quantity is smaller than a first preset threshold value, the performance parameter value is larger than a second preset threshold value, and the quantity of the abnormal information is smaller than a third preset threshold value, the third judgment result is satisfied;
if the call volume is greater than or equal to a first preset threshold, or the performance parameter value is less than or equal to a second preset threshold, or the quantity of the abnormal information is greater than or equal to a third preset threshold, the third judgment result is that the call volume is not greater than or equal to the first preset threshold, or the quantity of the abnormal information is greater than or equal to a third preset threshold.
In an optional embodiment, after the determining whether the survival status of each instance and the operation parameters of the target service operated in each instance satisfy the preset conditions, the method further includes:
if not, recording the identifiers of the target instances which do not meet the preset conditions in all the instances;
generating alarm information according to the identification of the target instance;
and prompting the alarm information according to a preset mode.
According to a second aspect of the present application, there is provided a service online self-checking device, including:
the acquisition module is used for acquiring the operation parameters of the target service operated in each instance and determining the survival state of each instance;
the judging module is used for judging whether the survival state of each example and the operation parameters of the target service operated in each example meet preset conditions or not;
the storage module is used for storing the service package corresponding to the currently running target service in the instance into a preset file system if the requirement is met;
and if the current version of the target service package is not met, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and rolling the target service in each instance to the previous version by using the target service package.
In an optional embodiment, the determining module includes:
a sending unit, configured to send a request packet to the instance and start a timer;
a first determining unit, configured to determine that the survival state of the instance is alive when receiving data returned by the instance according to the request message within a preset time period after a timer times;
and the second determining unit is used for determining that the survival state of the instance is non-survival if the data returned by the instance according to the request message is not received within the preset time period timed by the timer.
In an optional embodiment, the operation parameter includes an operation log of the target service, a version number of the target service, and an operation status parameter of the target service;
the judging module comprises:
the first judging unit is used for judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition or not to obtain a first judging result;
the second judging unit is used for judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not to obtain a second judging result;
the third judging unit is used for judging whether the running state parameters of the target service meet a third preset sub-condition or not to obtain a third judging result;
a fourth determining unit, configured to determine that a survival state of each instance and an operation parameter of the target service operated in each instance meet a preset condition if the first determination result, the second determination result, and the third determination result are all met;
a fifth determining unit, configured to determine that the survival state of each instance and the operation parameter of the target service operated in each instance do not satisfy a preset condition if at least one of the first determination result, the second determination result, and the third determination result is not satisfied.
In an optional embodiment, the first determining unit includes:
a first determining subunit, configured to, if the survival status of each instance is alive, and the running log of the target service run by each instance includes a preset identifier, obtain a first determination result that the running log satisfies the preset identifier;
a second determining subunit, configured to determine that the first determination result is unsatisfied if the survival status of the at least one instance is non-survival, or the running log of the target service run by the at least one instance does not include a preset identifier.
In an optional embodiment, the second judging unit includes:
a third determining subunit, configured to determine that the second determination result is satisfied if the version number of the target service run by each instance is a pre-acquired latest generated version number;
a fourth determining subunit, configured to determine that the second determination result is not satisfied if the version number of the target service operated by the at least one instance is not the newly-generated version number that is pre-acquired.
In an optional embodiment, the operation state parameters at least include a call amount of the target service, an amount of abnormal information, and a performance parameter value;
the third judgment unit includes:
a fifth judging subunit, configured to, if the call volume is smaller than a first preset threshold, the performance parameter value is greater than a second preset threshold, and the number of the abnormal information is smaller than a third preset threshold, determine that a third judgment result is satisfied;
a sixth determining subunit, configured to determine that the third determination result is unsatisfied, if the call volume is greater than or equal to a first preset threshold, or the performance parameter value is less than or equal to a second preset threshold, or the number of the abnormal information is greater than or equal to a third preset threshold.
In an optional embodiment, the apparatus further comprises:
the recording module is used for recording the identification of the target instance which does not meet the preset condition in all instances if the identification does not meet the preset condition;
the generating module is used for generating alarm information according to the identification of the target instance;
and the prompting module is used for prompting the alarm information according to a preset mode.
According to a third aspect of the present application, there is provided a service presence self-checking apparatus, including: at least one processor and memory;
the processor is configured to execute a service online self-checking program stored in the memory, so as to implement the service online self-checking method according to the first aspect of the present application.
According to a fourth aspect of the present application, a storage medium is provided, where one or more programs are stored in the storage medium, and the one or more programs may be executed by the service presence self-checking apparatus according to the third aspect of the present application, so as to implement the service presence self-checking method according to the first aspect of the present application.
The technical scheme provided by the application can comprise the following beneficial effects: according to the technical scheme, firstly, the operation parameters of the target service operated in each instance are obtained, the survival state of each instance is determined, then whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not is judged, if yes, the service package corresponding to the target service operated at present in the instance is stored in a preset file system, and if not, the target service package corresponding to the target service of the previous version is obtained from the preset file system, so that the target service in each instance is rolled back to the previous version by using the target service package. Thus, by using the technical scheme of the application, the process of the service online can be detected by using the operation parameters of the target service and the survival state of the instance of the operation target service in the process of the service online, when the running parameters of the target service and the survival state of the running example of the target service meet preset conditions, storing the service package corresponding to the target service into a preset file system, and when the running parameters of the target service and the survival state of the running example of the target service do not meet the preset conditions, if not, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and the target service in each instance is rolled back to the previous version by using the target service package, so that the whole service online process can realize self-checking, the dependence on manpower is greatly reduced, and the problems of low efficiency and high missing rate of checking the service online process manually in the related technology are solved.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and together with the description, serve to explain the principles of the application.
FIG. 1 is a flow diagram of a new version of a service coming online in the prior art;
fig. 2 is a flowchart illustrating a method for online self-check of a service according to an embodiment of the present application;
FIG. 3 is a schematic flow chart diagram for determining an example survival status according to an embodiment of the present application;
fig. 4 is a schematic flowchart illustrating a process of determining whether a preset condition is satisfied according to an embodiment of the present application;
fig. 5 is a schematic structural diagram of a service online self-checking device according to another embodiment of the present application;
fig. 6 is a schematic structural diagram of an online self-checking device for services according to another embodiment of the present application.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present application, as detailed in the appended claims.
Under the existing micro-service architecture, the process of online new version of the service can be as shown in fig. 1, and fig. 1 is a flow diagram of online new version of the service in the prior art, generally, a developer submits a bottom code of the service to a GitLab, Jenkins pulls the bottom code submitted by the developer from the GitLab, constructs the new version of the service according to the bottom code, and deploys the new version of the service to a corresponding instance.
Fig. 1 illustrates two services, namely, an order service and a user service, and for convenience of explanation, an upcoming release version of the order service is illustrated below, and after the upcoming release version of the order service is deployed into the instance, service registration and service discovery are carried out through the registration center, so that order service normally runs, each instance carrying the order service generates a corresponding log in the process of running the order service, such as a call log generated when the order service is called, a data processing log generated when data is processed by the order service, and the like, these logs are collected by the logbook, and, in addition, the order service runs are monitored by the monitoring system, link tracking may be provided for calls between services, such as when an order service is called, through which service is called at all, monitoring the length of time it takes for a service to process data, etc.
In order to ensure that the service has higher stability after being deployed to the instance, in the related technology, a developer in charge of the service online can manually check whether the service normally runs in each instance and whether the versions of the service running in each instance are consistent, and can check the calling amount, the performance and the like of the service after the service is online.
In order to overcome the problems of low efficiency and high missed detection probability of manual service online check in the related art, the present application provides a service online self-checking method, apparatus, device and storage medium, which are described below in an embodiment.
Referring to fig. 2, fig. 2 is a flowchart illustrating a method for self-checking online service according to an embodiment of the present application.
As shown in fig. 2, the on-line self-checking method for service provided by this embodiment may include:
step S201, obtaining the operation parameters of the target service operated in each instance, and determining the survival status of each instance.
It should be noted that, in this step, the target service is executed in the instance, and the execution parameters of the target service may include a call amount of the target service, a performance parameter value (here, a parameter that can represent the performance of the service, such as a processing time or a processing speed), and a quantity of exception information.
In addition, referring to fig. 3, a process for determining the survival status of each instance may be shown, where fig. 3 is a schematic flow chart for determining the survival status of an instance according to an embodiment of the present application.
As shown in fig. 3, the process of determining the instance survival status provided by this embodiment may include:
step S301, sending a request message to the instance and starting a timer.
It should be noted that the manner of sending the request message in this step may be, but is not limited to, sending the request message to the instance by using a ping instruction by using a network diagnostic tool, that is, ping, by using the address of the instance in the network.
Generally, after receiving a request message, a live instance returns corresponding data according to the request message, and if the instance is in a non-live state, the instance cannot return the corresponding data.
Step S302, if the timer times to a preset time period, receiving data returned by the instance according to the request message, and determining the survival state of the instance to be survival.
Step S303, if the data returned by the instance according to the request message is not received within the preset time period timed by the timer, determining that the survival state of the instance is non-survival.
It should be noted that the preset time period may be preset according to a specific situation, for example, in a network where the instance is located, the delay is low, in a specific example, the average duration of the instance response is approximately 20ms, and then the preset time period may be set to a time period slightly longer than 20ms, such as 25ms, 30ms, and the like.
When the timer times to a preset time period, if data returned by the instance according to the request message is received, it may be determined that the survival state of the instance is alive, where it should be noted that the survival state is alive means that the instance is in a normal working state, and there are no conditions of downtime, congestion, and the like. If the data returned by the instance according to the request message is not received all the time within the preset time period timed by the timer, it is indicated that the instance cannot normally work, and may be in the states of congestion, downtime and the like.
Step S202, judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions.
In this step, the operation parameters include an operation log of the target service, a version number of the target service, and an operation state parameter of the target service, and this step may specifically have multiple ordered determination processes, and specifically refer to fig. 4, where fig. 4 is a schematic flow diagram for determining whether a preset condition is satisfied according to an embodiment of the present application.
As shown in fig. 4, the specific process for determining whether the survival status of each instance and the operation parameters of the target service operated in each instance satisfy the preset conditions according to this embodiment may include:
step S401, determining whether the survival status of each instance and the running log of the target service run by each instance satisfy a first preset sub-condition, to obtain a first determination result.
It should be noted that in this step, when Jenkins deploys (also referred to as releases) the target service into the example, a strategy of gray release is often adopted, that is, the target service of the version that needs to be released at this time is released in a part of the present examples, and the step is gradual until the target service of the version that needs to be released at this time is released in all the examples.
For example, the target service of the version to be released at this time is deployed in one of the examples, then the judgment in this step is performed, then 30% of the examples are taken from the other examples, the target service of the version to be released at this time is deployed in 30% of the examples, then the judgment in this step is performed until all the examples deploy the target service of the version to be released at this time, after the judgment in this step is performed, the first judgment result is satisfied, and then the judgment in step S402 is performed.
In this step, if the survival status of each instance is alive and the running log of the running target service of each instance includes the preset identifier, the first judgment result is satisfied; and if the survival state of at least one instance is non-survival or the running log of the target service run by at least one instance does not comprise the preset identification, the first judgment result is not satisfied.
It should be noted that the preset identifier refers to an identifier indicating that the operation is successful when the instance operates the target service, generally, when the instance operates the target service, after the operation is successful, the preset identifier is generated into an operation log to be stored, and if the operation is unsuccessful, the operation log does not include the preset identifier. Therefore, the step of determining whether the running log contains the preset identifier can determine whether the target service runs successfully in the instance.
Step S402, judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not, and obtaining a second judgment result.
Because the version of the target service is continuously updated, the scheme of this embodiment may be applied to the process of online the new version of the target service, that is, the embodiment of this application may perform self-check on the online process of the target service of the version that needs to be online this time.
It should be noted that Jenkins may generate a version number of the target service constructed this time when constructing the target service, where the version number has uniqueness, and generally, the generation of the version number may be performed according to a corresponding version number naming rule, for example, "service name + current date + current time", such as that one version number of the order service is order _ service _ 20200813-.
Based on the above description, in the step of determining, it is necessary to determine whether the version number of the target service operated by each instance is the pre-acquired latest generated version number, where the latest generated version number is the version number corresponding to the current version, and if the version number of the target service operated by each instance is the pre-acquired latest generated version number, the second determination result is satisfied; and if the version number of the target service operated by at least one instance is not the latest pre-acquired version number, the second judgment result is not satisfied.
After the determination in this step is satisfied, the determination in step S403 may be performed.
Step S403, determining whether the operating state parameter of the target service satisfies a third preset sub-condition, and obtaining a third determination result.
The step is mainly to carry out self-checking on the running state of the target service, and as the running state parameters at least comprise the call quantity of the target service, the quantity of the abnormal information and the performance parameter values, if the call quantity is smaller than a first preset threshold value, the performance parameter values are larger than a second preset threshold value, the quantity of the abnormal information is smaller than a third preset threshold value, and a third judgment result is satisfied; and if the call quantity is greater than or equal to a first preset threshold value, or the performance parameter value is less than or equal to a second preset threshold value, or the quantity of the abnormal information is greater than or equal to a third preset threshold value, the third judgment result is that the call quantity is not greater than the first preset threshold value.
Step S404, if the first judgment result, the second judgment result and the third judgment result are all satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions.
It should be noted that, only if the first determination result, the second determination result, and the third determination result are all satisfied, it is determined that the survival state of each instance and the operation parameter of the target service operated in each instance satisfy the preset condition, and then step S203 is executed.
Step S405, if at least one of the first judgment result, the second judgment result and the third judgment result is not satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not satisfy preset conditions.
In this step, if only one of the first determination result, the second determination result, and the third determination result is not satisfied, it is determined that the survival state of each instance and the operation parameter of the target service operated in each instance do not satisfy the preset condition, and then step S204 is performed.
It should be noted that, since the foregoing steps S401 to S403 are a process of sequential determination, as long as the result of the previous determination is not satisfied, step S405 may be directly executed.
Step S203, if the requirement is met, storing the service package corresponding to the currently running target service in the example into a preset file system.
The satisfaction in this step means that the first determination result, the second determination result, and the third determination result in step S404 are all satisfied, that is, in the determinations in steps S401 to S403, the preset sub-conditions (including the first preset sub-condition, the second preset sub-condition, and the third preset sub-condition) are all satisfied, so that the service package corresponding to the currently running target service in the instance can be stored in the preset file system, and is used for rolling back when the target service of the next updated version is online.
And step S204, if the current version of the target service package is not met, acquiring the target service package corresponding to the target service of the previous version from the preset file system, and rolling the target service in each instance back to the previous version by using the target service package.
If at least one of the first determination result, the second determination result, and the third determination result in step S405 is not satisfied, a target service package corresponding to the target service of the previous version needs to be obtained from the preset file system, so that the target service in each instance is rolled back to the previous version by using the target service package.
It should be noted that, when the target service package corresponding to the target service of the previous version in the preset file system is online, the method of this embodiment is used to perform self-check, and the self-check is stored in the file system through step S203.
In addition, after step S202, if it is determined that the survival status of each instance and the operation parameters of the target service operated in each instance do not satisfy the preset conditions, an identifier of the target instance that does not satisfy the preset conditions in the instance may also be recorded, then alarm information is generated according to the identifier of the target instance, and finally the alarm information is prompted according to a preset manner.
It should be noted that, when generating the alarm information according to the identifier of the target instance, the alarm information may be generated according to a link of a table recording the identifier of the target instance, in this embodiment, a process of recording the identifier of the target instance that does not satisfy the preset condition in the instance may form a record table storing the identifiers of all target instances that do not satisfy the preset condition in the online process, then a link capable of being linked to the record table is generated according to a storage location of the record table, and finally the alarm information is generated according to the link. When the alarm information is prompted according to a preset mode, the record table can be directly opened according to the link in the alarm information, and the identification of the target instance which does not meet the preset condition is obtained.
In addition, the preset mode can be a graphic mode, a mail mode or a short message mode and the like.
Referring to fig. 5, fig. 5 is a schematic structural diagram of a self-checking device on a service according to another embodiment of the present application.
As shown in fig. 5, the on-line self-checking device for service provided by this embodiment may include:
an obtaining module 501, configured to obtain an operation parameter of a target service that operates in each instance, and determine a survival status of each instance;
a judging module 502, configured to judge whether the survival status of each instance and the operation parameters of the target service operated in each instance meet preset conditions;
the storage module 503 is configured to, if the request is met, store the service package corresponding to the currently running target service in the instance in a preset file system;
and a rollback module 504, configured to, if the current version of the target service is not satisfied, obtain a target service package corresponding to the target service of the previous version from the preset file system, so as to rollback the target service in each instance to the previous version by using the target service package.
In an optional embodiment, the determining module includes:
the sending unit is used for sending the request message to the instance and starting the timer;
the first determining unit is used for receiving data returned by the example according to the request message and determining the survival state of the example as survival if the timer times to a preset time period;
and the second determining unit is used for determining that the survival state of the example is non-survival if the data returned by the example according to the request message is not received within the preset time period timed by the timer.
In an optional embodiment, the operation parameter includes an operation log of the target service, a version number of the target service, and an operation status parameter of the target service;
the judging module comprises:
the first judging unit is used for judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition or not to obtain a first judging result;
the second judging unit is used for judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not to obtain a second judging result;
the third judging unit is used for judging whether the running state parameters of the target service meet a third preset sub-condition or not to obtain a third judging result;
a fourth judging unit, configured to judge that the survival state of each instance and the operation parameter of the target service operated in each instance meet preset conditions if the first, second, and third judgment results are all met;
and the fifth judging unit is used for judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not meet the preset conditions if at least one of the first judging result, the second judging result and the third judging result is not met.
In an optional embodiment, the first judging unit includes:
the first judging subunit is used for judging whether the survival state of each instance is survival and the running log of the target service run by each instance comprises a preset identifier, wherein the first judging result is satisfied;
and the second judging subunit is used for judging that the first judgment result is not satisfied if the survival state of the at least one instance is non-survival or the running log of the target service run by the at least one instance does not include the preset identifier.
In an alternative embodiment, the second judging unit includes:
the third judgment subunit is configured to, if the version number of the target service operated by each instance is the latest pre-acquired version number, determine that the second judgment result is satisfied;
and the fourth judging subunit is configured to, if the version number of the target service operated by the at least one instance is not the newly-generated version number that is obtained in advance, determine that the second judgment result is unsatisfied.
In an optional embodiment, the operation state parameters at least include a call amount of the target service, an amount of the abnormal information, and a performance parameter value;
the third judgment unit includes:
a fifth judging subunit, configured to, if the call volume is smaller than the first preset threshold, the performance parameter value is greater than the second preset threshold, and the number of the abnormal information is smaller than a third preset threshold, determine that a third judgment result is satisfied;
and the sixth judging subunit is configured to, if the call volume is greater than or equal to the first preset threshold, or the performance parameter value is less than or equal to the second preset threshold, or the number of the abnormal information is greater than or equal to the third preset threshold, determine that the third judgment result is unsatisfied.
In an optional embodiment, the apparatus further comprises:
the recording module is used for recording the identification of the target instance which does not meet the preset condition in all instances if the identification does not meet the preset condition;
the generating module is used for generating alarm information according to the identification of the target example;
and the prompting module is used for prompting the alarm information according to a preset mode.
Referring to fig. 6, fig. 6 is a schematic structural diagram of a service presence self-checking device according to another embodiment of the present application.
As shown in fig. 6, the on-line service self-test apparatus 600 provided in this embodiment includes: at least one processor 601, memory 602, at least one network interface 603, and other user interfaces 604. The various components of the service bring-on-line self-test device 600 are coupled together by a bus system 605. It is understood that the bus system 605 is used to enable communications among the components. The bus system 605 includes a power bus, a control bus, and a status signal bus in addition to a data bus. For clarity of illustration, however, the various buses are labeled as bus system 605 in fig. 6.
The user interface 604 may include, among other things, a display, a keyboard, or a pointing device (e.g., a mouse, trackball, touch pad, or touch screen, among others.
It will be appreciated that the memory 602 in embodiments of the invention may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The non-volatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of illustration and not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic random access memory (Synchronous DRAM, SDRAM), Double Data Rate Synchronous Dynamic random access memory (ddr Data Rate SDRAM, ddr SDRAM), Enhanced Synchronous SDRAM (ESDRAM), synchlronous SDRAM (SLDRAM), and Direct Rambus RAM (DRRAM). The memory 602 described herein is intended to comprise, without being limited to, these and any other suitable types of memory.
In some embodiments, memory 602 stores the following elements, executable units or data structures, or a subset thereof, or an expanded set thereof: an operating system 6021 and a second application 6022.
The operating system 6021 includes various system programs, such as a framework layer, a core library layer, a driver layer, and the like, and is used for implementing various basic services and processing hardware-based tasks. The second application program 6022 includes various second application programs such as a Media Player (Media Player), a Browser (Browser), and the like for implementing various application services. A program implementing a method of an embodiment of the invention can be included in the second application program 6022.
In the embodiment of the present invention, by calling a program or an instruction stored in the memory 602, specifically, a program or an instruction stored in the second application program 6022, the processor 601 is configured to execute the method steps provided by the method embodiments, for example, including:
acquiring operation parameters of the target service operated in each instance, and determining the survival state of each instance;
judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not;
if yes, storing a service package corresponding to the currently running target service in the example into a preset file system;
and if not, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and rolling back the target service in each instance to the previous version by using the target service package.
In an alternative embodiment, determining the survival status of an instance comprises
Sending a request message to an example and starting a timer;
if the timer times to a preset time period, receiving data returned by the instance according to the request message, and determining the survival state of the instance as survival;
and if the data returned by the instance according to the request message is not received within the preset time period timed by the timer, determining that the survival state of the instance is non-survival.
In an optional embodiment, the operation parameter includes an operation log of the target service, a version number of the target service, and an operation status parameter of the target service;
judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not, wherein the judgment comprises the following steps:
judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition to obtain a first judgment result;
judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not to obtain a second judgment result;
judging whether the running state parameters of the target service meet a third preset sub-condition or not to obtain a third judgment result;
if the first judgment result, the second judgment result and the third judgment result are all satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions;
and if at least one of the first judgment result, the second judgment result and the third judgment result is not satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not satisfy preset conditions.
In an optional embodiment, determining whether the survival status of each instance and the running log of the target service run by each instance satisfy a first preset sub-condition to obtain a first determination result includes:
if the survival state of each instance is survival and the running log of the target service run by each instance comprises a preset identifier, and the first judgment result is satisfied;
and if the survival state of at least one instance is non-survival, or the running log of the target service run by at least one instance does not include the preset identifier, the first judgment result is unsatisfied.
In an optional embodiment, the determining whether the version number of the target service operated by each instance satisfies a second preset sub-condition to obtain a second determination result includes:
if the version number of the target service operated by each instance is the latest pre-acquired version number, the second judgment result is satisfied;
and if the version number of the target service operated by at least one instance is not the latest pre-acquired version number, the second judgment result is not satisfied.
In an optional embodiment, the operation state parameters at least include a call amount of the target service, an amount of the abnormal information, and a performance parameter value;
judging whether the running state parameter of the target service meets a third preset sub-condition to obtain a third judgment result, wherein the third judgment result comprises the following steps:
if the call quantity is smaller than a first preset threshold value, the performance parameter value is larger than a second preset threshold value, and the quantity of the abnormal information is smaller than a third preset threshold value, a third judgment result is satisfied;
and if the call quantity is greater than or equal to a first preset threshold value, or the performance parameter value is less than or equal to a second preset threshold value, or the quantity of the abnormal information is greater than or equal to a third preset threshold value, the third judgment result is that the call quantity is not greater than the first preset threshold value.
In an optional embodiment, after determining whether the survival status of each instance and the operation parameters of the target service operated in each instance satisfy the preset conditions, the method further includes:
if not, recording the identifiers of the target instances which do not meet the preset conditions in all the instances;
generating alarm information according to the identification of the target instance;
and prompting the alarm information according to a preset mode.
The method disclosed by the above-mentioned embodiment of the present invention can be applied to the processor 601, or implemented by the processor 601. The processor 601 may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method may be performed by integrated logic circuits of hardware or instructions in the form of software in the processor 601. The Processor 601 may be a general-purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, or discrete hardware components. The various methods, steps and logic blocks disclosed in the embodiments of the present invention may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of the method disclosed in connection with the embodiments of the present invention may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software elements in the decoding processor. The software elements may be located in ram, flash, rom, prom, or eprom, registers, among other storage media that are well known in the art. The storage medium is located in the memory 602, and the processor 601 reads the information in the memory 602 and completes the steps of the method in combination with the hardware thereof.
It is to be understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or any combination thereof. For a hardware implementation, the Processing units may be implemented in one or more Application Specific Integrated Circuits (ASICs), Digital Signal Processors (DSPs), Digital Signal Processing Devices (DSPDs), Programmable Logic Devices (PLDs), Field Programmable Gate Arrays (FPGAs), general purpose processors, controllers, micro-controllers, microprocessors, other electronic units configured to perform the functions of the present Application, or a combination thereof.
For a software implementation, the techniques herein may be implemented by means of units performing the functions herein. The software codes may be stored in a memory and executed by a processor. The memory may be implemented within the processor or external to the processor.
The embodiment of the invention also provides a storage medium (computer readable storage medium). The storage medium herein stores one or more programs. Among others, the storage medium may include volatile memory, such as random access memory; the memory may also include non-volatile memory, such as read-only memory, flash memory, a hard disk, or a solid state disk; the memory may also comprise a combination of memories of the kind described above.
When one or more programs in the storage medium can be executed by one or more processors, the service online self-checking method executed on the service online self-checking device side is realized.
The processor is used for executing the service on-line self-checking program stored in the memory so as to realize the following steps of the service on-line self-checking method executed on the service on-line self-checking equipment side:
acquiring operation parameters of the target service operated in each instance, and determining the survival state of each instance;
judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not;
if yes, storing a service package corresponding to the currently running target service in the example into a preset file system;
and if not, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and rolling back the target service in each instance to the previous version by using the target service package.
In an alternative embodiment, determining the survival status of an instance comprises
Sending a request message to an example and starting a timer;
if the timer times to a preset time period, receiving data returned by the instance according to the request message, and determining the survival state of the instance as survival;
and if the data returned by the instance according to the request message is not received within the preset time period timed by the timer, determining that the survival state of the instance is non-survival.
In an optional embodiment, the operation parameter includes an operation log of the target service, a version number of the target service, and an operation status parameter of the target service;
judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not, wherein the judgment comprises the following steps:
judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition to obtain a first judgment result;
judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not to obtain a second judgment result;
judging whether the running state parameters of the target service meet a third preset sub-condition or not to obtain a third judgment result;
if the first judgment result, the second judgment result and the third judgment result are all satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions;
and if at least one of the first judgment result, the second judgment result and the third judgment result is not satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not satisfy preset conditions.
In an optional embodiment, determining whether the survival status of each instance and the running log of the target service run by each instance satisfy a first preset sub-condition to obtain a first determination result includes:
if the survival state of each instance is survival and the running log of the target service run by each instance comprises a preset identifier, and the first judgment result is satisfied;
and if the survival state of at least one instance is non-survival, or the running log of the target service run by at least one instance does not include the preset identifier, the first judgment result is unsatisfied.
In an optional embodiment, the determining whether the version number of the target service operated by each instance satisfies a second preset sub-condition to obtain a second determination result includes:
if the version number of the target service operated by each instance is the latest pre-acquired version number, the second judgment result is satisfied;
and if the version number of the target service operated by at least one instance is not the latest pre-acquired version number, the second judgment result is not satisfied.
In an optional embodiment, the operation state parameters at least include a call amount of the target service, an amount of the abnormal information, and a performance parameter value;
judging whether the running state parameter of the target service meets a third preset sub-condition to obtain a third judgment result, wherein the third judgment result comprises the following steps:
if the call quantity is smaller than a first preset threshold value, the performance parameter value is larger than a second preset threshold value, and the quantity of the abnormal information is smaller than a third preset threshold value, a third judgment result is satisfied;
and if the call quantity is greater than or equal to a first preset threshold value, or the performance parameter value is less than or equal to a second preset threshold value, or the quantity of the abnormal information is greater than or equal to a third preset threshold value, the third judgment result is that the call quantity is not greater than the first preset threshold value.
In an optional embodiment, after determining whether the survival status of each instance and the operation parameters of the target service operated in each instance satisfy the preset conditions, the method further includes:
if not, recording the identifiers of the target instances which do not meet the preset conditions in all the instances;
generating alarm information according to the identification of the target instance;
and prompting the alarm information according to a preset mode.
With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.
It is understood that the same or similar parts in the above embodiments may be mutually referred to, and the same or similar parts in other embodiments may be referred to for the content which is not described in detail in some embodiments.
It should be noted that, in the description of the present application, the terms "first", "second", etc. are used for descriptive purposes only and are not to be construed as indicating or implying relative importance. Further, in the description of the present application, the meaning of "a plurality" means at least two unless otherwise specified.
Any process or method descriptions in flow charts or otherwise described herein may be understood as representing modules, segments, or portions of code which include one or more executable instructions for implementing specific logical functions or steps of the process, and the scope of the preferred embodiments of the present application includes other implementations in which functions may be executed out of order from that shown or discussed, including substantially concurrently or in reverse order, depending on the functionality involved, as would be understood by those reasonably skilled in the art of the present application.
It should be understood that portions of the present application may be implemented in hardware, software, firmware, or a combination thereof. In the above embodiments, the various steps or methods may be implemented in software or firmware stored in memory and executed by a suitable instruction execution system. For example, if implemented in hardware, as in another embodiment, any one or combination of the following techniques, which are known in the art, may be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application specific integrated circuit having an appropriate combinational logic gate circuit, a Programmable Gate Array (PGA), a Field Programmable Gate Array (FPGA), or the like.
It will be understood by those skilled in the art that all or part of the steps carried by the method for implementing the above embodiments may be implemented by hardware related to instructions of a program, which may be stored in a computer readable storage medium, and when the program is executed, the program includes one or a combination of the steps of the method embodiments.
In addition, functional units in the embodiments of the present application may be integrated into one processing module, or each unit may exist alone physically, or two or more units are integrated into one module. The integrated module can be realized in a hardware mode, and can also be realized in a software functional module mode. The integrated module, if implemented in the form of a software functional module and sold or used as a stand-alone product, may also be stored in a computer readable storage medium.
The storage medium mentioned above may be a read-only memory, a magnetic or optical disk, etc.
In the description herein, reference to the description of the term "one embodiment," "some embodiments," "an example," "a specific example," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the application. In this specification, the schematic representations of the terms used above do not necessarily refer to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.
Although embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application, and that variations, modifications, substitutions and alterations may be made to the above embodiments by those of ordinary skill in the art within the scope of the present application.
Claims (11)
1. A service online self-checking method is characterized by comprising the following steps:
acquiring operation parameters of a target service operated in each instance, and determining the survival state of each instance;
judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions or not;
if yes, storing a service package corresponding to the target service currently running in the instance into a preset file system;
and if not, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and rolling back the target service in each instance to the previous version by using the target service package.
2. The method of claim 1, wherein determining the survival status of each instance comprises:
sending a request message to the instance and starting a timer;
if the timer is timed to a preset time period, receiving data returned by the instance according to the request message, and determining that the survival state of the instance is survival;
and if the data returned by the instance according to the request message is not received within the preset time period timed by the timer, determining that the survival state of the instance is non-survival.
3. The method of claim 1 or 2, wherein the operational parameters comprise an operational log of the target service, a version number of the target service, and operational status parameters of the target service;
the judging whether the survival state of each instance and the operation parameters of the target service operated in each instance meet preset conditions includes:
judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition to obtain a first judgment result;
judging whether the version number of the target service operated by each instance meets a second preset sub-condition or not to obtain a second judgment result;
judging whether the running state parameters of the target service meet a third preset sub-condition or not to obtain a third judgment result;
if the first judgment result, the second judgment result and the third judgment result are all satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions;
and if at least one of the first judgment result, the second judgment result and the third judgment result is not satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not satisfy preset conditions.
4. The method of claim 1 or 2, wherein the operational parameters comprise an operational log of the target service, a version number of the target service, and operational status parameters of the target service;
the determining whether the survival state of each instance and the operation parameter of the target service operated in each instance meet preset conditions specifically includes:
judging whether the survival state of each instance and the running log of the target service run by each instance meet a first preset sub-condition to obtain a first judgment result;
if the first judgment result is satisfied, judging whether the version number of the target service operated by each instance satisfies a second preset sub-condition to obtain a second judgment result;
if the second judgment result is satisfied, judging whether the running state parameter of the target service satisfies a third preset sub-condition to obtain a third judgment result;
if the third judgment results are all satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions;
and if at least one of the first judgment result, the second judgment result and the third judgment result is not satisfied, judging that the survival state of each instance and the operation parameters of the target service operated in each instance do not satisfy preset conditions.
5. The method according to claim 3, wherein the determining whether the survival status of each instance and the running log of the target service run by each instance satisfy a first preset sub-condition to obtain a first determination result comprises:
if the survival state of each instance is survival and the running log of the target service run by each instance comprises a preset identifier, the first judgment result is satisfied;
if the survival status of at least one instance is non-survival, or the running log of the target service run by at least one instance does not include a preset identifier, the first judgment result is unsatisfied.
6. The method according to claim 3, wherein the determining whether the version number of the target service run by each instance satisfies a second preset sub-condition to obtain a second determination result comprises:
if the version number of the target service operated by each instance is a pre-acquired latest generated version number, the second judgment result is satisfied;
and if the version number of the target service operated by at least one instance is not the latest pre-acquired version number, the second judgment result is not satisfied.
7. The method of claim 3, wherein the operating state parameters include at least a call amount, an amount of exception information, and a performance parameter value for the target service;
the step of judging whether the running state parameter of the target service meets a third preset sub-condition to obtain a third judgment result includes:
if the call quantity is smaller than a first preset threshold value, the performance parameter value is larger than a second preset threshold value, and the quantity of the abnormal information is smaller than a third preset threshold value, the third judgment result is satisfied;
if the call volume is greater than or equal to a first preset threshold, or the performance parameter value is less than or equal to a second preset threshold, or the quantity of the abnormal information is greater than or equal to a third preset threshold, the third judgment result is that the call volume is not greater than or equal to the first preset threshold, or the quantity of the abnormal information is greater than or equal to a third preset threshold.
8. The method of claim 1, wherein after determining whether the survival status of each instance and the operation parameters of the target service operated in each instance satisfy preset conditions, the method further comprises:
if not, recording the identifiers of the target instances which do not meet the preset conditions in all the instances;
generating alarm information according to the identification of the target instance;
and prompting the alarm information according to a preset mode.
9. A service presence self-check device, the device comprising:
the acquisition module is used for acquiring the operation parameters of the target service operated in each instance and determining the survival state of each instance;
the judging module is used for judging whether the survival state of each example and the operation parameters of the target service operated in each example meet preset conditions or not;
the storage module is used for storing the service package corresponding to the currently running target service in the instance into a preset file system if the requirement is met;
and if the current version of the target service package is not met, acquiring a target service package corresponding to the target service of the previous version from the preset file system, and rolling the target service in each instance to the previous version by using the target service package.
10. A service online self-test device, comprising: at least one processor and memory;
the processor is used for executing the service on-line self-checking program stored in the memory so as to realize the service on-line self-checking method of any one of claims 1 to 8.
11. A storage medium storing one or more programs executable by the on-service self-check apparatus according to claim 10 to implement the on-service self-check method according to any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011573351.3A CN112579397B (en) | 2020-12-25 | 2020-12-25 | Service online self-checking method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011573351.3A CN112579397B (en) | 2020-12-25 | 2020-12-25 | Service online self-checking method, device, equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN112579397A true CN112579397A (en) | 2021-03-30 |
| CN112579397B CN112579397B (en) | 2024-06-18 |
Family
ID=75139976
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011573351.3A Active CN112579397B (en) | 2020-12-25 | 2020-12-25 | Service online self-checking method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112579397B (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115460101A (en) * | 2022-08-02 | 2022-12-09 | 北京达佳互联信息技术有限公司 | Network service management method, device, equipment and storage medium |
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8825792B1 (en) * | 2008-03-11 | 2014-09-02 | United Services Automobile Association (Usaa) | Systems and methods for online brand continuity |
| US20180286510A1 (en) * | 2015-09-21 | 2018-10-04 | Wenjie Robin Liang | Maintenance systems and methods for medical devices |
| CN109039740A (en) * | 2018-08-01 | 2018-12-18 | 平安科技（深圳）有限公司 | A kind of method and apparatus handling O&M monitoring alarm |
| CN111475372A (en) * | 2020-03-10 | 2020-07-31 | 中国平安人寿保险股份有限公司 | Method, device, equipment and storage medium for monitoring service instance of microservice |
| CN111813601A (en) * | 2020-07-09 | 2020-10-23 | 中国工商银行股份有限公司 | Micro-service rollback method and device for stateful distributed cluster |
-
2020
- 2020-12-25 CN CN202011573351.3A patent/CN112579397B/en active Active
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US8825792B1 (en) * | 2008-03-11 | 2014-09-02 | United Services Automobile Association (Usaa) | Systems and methods for online brand continuity |
| US20180286510A1 (en) * | 2015-09-21 | 2018-10-04 | Wenjie Robin Liang | Maintenance systems and methods for medical devices |
| CN109039740A (en) * | 2018-08-01 | 2018-12-18 | 平安科技（深圳）有限公司 | A kind of method and apparatus handling O&M monitoring alarm |
| CN111475372A (en) * | 2020-03-10 | 2020-07-31 | 中国平安人寿保险股份有限公司 | Method, device, equipment and storage medium for monitoring service instance of microservice |
| CN111813601A (en) * | 2020-07-09 | 2020-10-23 | 中国工商银行股份有限公司 | Micro-service rollback method and device for stateful distributed cluster |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN115460101A (en) * | 2022-08-02 | 2022-12-09 | 北京达佳互联信息技术有限公司 | Network service management method, device, equipment and storage medium |
| CN115460101B (en) * | 2022-08-02 | 2024-06-11 | 北京达佳互联信息技术有限公司 | Network service management method, device, equipment and storage medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN112579397B (en) | 2024-06-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108829487A (en) | A kind of methods of exhibiting of pop-up, device, storage medium and terminal | |
| CN108347476B (en) | Cross-machine-room data synchronization method and device and server | |
| CN107957837B (en) | Method and device for generating shortcut of webpage application program and terminal equipment | |
| CN110704166A (en) | Service operation method and device and server | |
| CN113190371B (en) | Task compensation method and device, electronic equipment and readable storage medium | |
| CN110825399A (en) | Deployment method and device of application program | |
| CN110990339A (en) | Distributed storage file reading and writing method, device and platform and readable storage medium | |
| US6185702B1 (en) | Method and system for process state management using checkpoints | |
| CN107864209B (en) | Data writing method and device and server | |
| CN112579397A (en) | Service online self-checking method, device, equipment and storage medium | |
| CN112068935A (en) | Method, device and equipment for monitoring deployment of kubernets program | |
| CN112965660A (en) | Method, system, device and medium for feeding back information of double storage pools | |
| US9513983B2 (en) | Method for maintaining file system of computer system | |
| CN110618853B (en) | Detection method, device and equipment for zombie container | |
| CN113965576B (en) | Container-based big data acquisition method, device, storage medium and equipment | |
| CN111324419A (en) | Deployment method, device, equipment and storage medium of combined container | |
| CN111198725B (en) | Application starting processing method, computing equipment and computer storage medium | |
| CN111880947A (en) | Data transmission method and device | |
| CN112486824B (en) | Case code generation method, device, computer equipment and storage medium | |
| US11307920B2 (en) | Automated crash recovery | |
| CN111949273B (en) | File extraction method and device based on iOS system | |
| JP2007058265A (en) | Log output controller and log output control program | |
| CN114764335A (en) | Method, device, terminal and storage medium for generating mirror image | |
| CN111158565A (en) | Page turning prompting method and device, electronic equipment and storage medium | |
| CN109672573B (en) | Configuration file deployment method, configuration file determination method, server 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 | ||
| CB02 | Change of applicant information |
Address after: Room 221, 2 / F, block C, 18 Kechuang 11th Street, Daxing District, Beijing, 100176 Applicant after: Jingdong Technology Holding Co.,Ltd. Address before: Room 221, 2 / F, block C, 18 Kechuang 11th Street, Daxing District, Beijing, 100176 Applicant before: Jingdong Digital Technology Holding Co.,Ltd. |
|
| CB02 | Change of applicant information | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |