CN113515403B - Micro-service state checking method, computer device and storage medium - Google Patents
Micro-service state checking method, computer device and storage medium Download PDFInfo
- Publication number
- CN113515403B CN113515403B CN202110698869.8A CN202110698869A CN113515403B CN 113515403 B CN113515403 B CN 113515403B CN 202110698869 A CN202110698869 A CN 202110698869A CN 113515403 B CN113515403 B CN 113515403B
- Authority
- CN
- China
- Prior art keywords
- micro
- service
- interface
- state
- server
- 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
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/079—Root cause analysis, i.e. error or fault diagnosis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
- G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server 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/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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- Computing Systems (AREA)
- Quality & Reliability (AREA)
- General Physics & Mathematics (AREA)
- Mathematical Physics (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Computer Hardware Design (AREA)
- Debugging And Monitoring (AREA)
Abstract
The invention relates to the technical field of micro-service, and provides a micro-service state checking method, computer equipment and a storage medium, wherein the method comprises the following steps: grouping the micro-services according to service contents, configuring an interface configuration table for the grouped micro-services, when detecting that the interface configuration table is updated, sending the updated interface configuration table to Redis stream and a configuration modification message to a task scheduling server through a configuration server, acquiring the interface configuration table from the Redis stream through the task scheduling server and updating the interface configuration table to a local cache, when a timing task expires, reading the interface configuration table from the local cache through the task scheduling server and determining the group where the micro-services are located, and finally distributing a micro-service state check request to a state check server corresponding to the group through the task scheduling server so that the state check server performs state check. The method and the device can not only carry out state check on the micro-services, but also determine the affected business content when determining that a certain micro-service has a fault in a grouping mode.
Description
Technical Field
The invention relates to the technical field of micro-services, in particular to a micro-service state checking method, computer equipment and a storage medium.
Background
In order to ensure that all services are available, the services need to be periodically subjected to a status check, such as a health check, to ensure the availability of the services, and when a problem occurs in the services, the problem services can be removed in time. Conventional status checking typically involves detecting an interface, detecting a period, timeout time, status code, exception condition, etc.
Generally, a micro service configures a status checking endpoint, and a status checker detects the status of the service by calling a status checking API of the micro service, but the inventor finds that this method has obvious disadvantages in implementing the present invention, and in a complex system, there are usually more service processing logics and middleware dependencies, and the conventional status checking can only check whether the service is alive, but cannot ensure that the service is normal, for example, the middleware dependent on a certain service is down, and the service is still alive, but the service is already affected.
Disclosure of Invention
In view of the above, it is necessary to provide a micro-service status checking method, a computer device and a storage medium, which can not only check the status of the micro-service, but also determine the affected service.
A first aspect of the present invention provides a method for checking a microservice status, the method comprising:
grouping the micro-services according to the service content;
configuring an interface configuration table for the micro-services of the same group;
when detecting that the interface configuration table of any micro service is updated, sending the updated interface configuration table to the ReDisStream and a configuration modification message to the task scheduling server through the configuration server;
acquiring the updated interface configuration table from the ReDisStream through the task scheduling server, and updating the acquired interface configuration table to a local cache;
reading an interface configuration table from the local cache through the task scheduling server in response to the expiration of the timing task, and determining a group where any micro service is located according to the interface configuration table;
and distributing a micro-service state check request to a state check server corresponding to the group according to the group in which the micro-service is positioned by the task scheduling server, so that the state check server performs state check according to the micro-service state check request.
In an optional embodiment, the grouping of micro services according to service contents includes:
determining the level of the business content according to a preset business structure tree;
judging whether the service contents in the same level have the same father node;
when the service contents in the same level have the same father node, determining the service contents with the same father node as belonging to the same sub-domain;
and configuring a packet identifier for each subdomain according to the order from left to right and the hierarchy of the service content and associating a micro-service interface for each subdomain.
In an alternative embodiment, when each set of microservices corresponds to a plurality of stateful inspection servers, the method comprises:
distributing a status check test script to each status check server;
acquiring the range of the random number in the state checking test script through the state checking server;
generating a target random number according to the range of the random number;
generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file and the target random number;
performing state inspection test according to the state inspection test file and acquiring the performance after the test is finished;
and distributing a micro-service state check request to a state check server corresponding to the group according to the performance.
In an optional embodiment, the generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file, and the target random number includes:
calculating the size of the basic test file;
determining the cycle number according to the size of the basic test file and the standard test file;
and writing the target random number into the basic test file by using a command line, and circularly copying the cycle times to the target random number to obtain a state inspection test file.
In an optional embodiment, the distributing the microservice status check request to the status check server corresponding to the group according to the performance includes:
calculating a sum of the performance of the plurality of stateful inspection servers;
calculating a performance weight of each status check server according to the sum;
and distributing micro-service state checking requests to the corresponding state checking servers according to the performance weights.
In an optional embodiment, the method further comprises:
when detecting that the interface of the micro service has no error, acquiring a return result of the interface of the micro service;
acquiring a returned result verification rule in an interface configuration table of the microservice;
checking the returned result by using the returned result checking rule;
when the returned result is successfully verified, determining that any one micro service state is normal;
and when the check of the return result fails, determining that any micro-service state is abnormal.
In an optional embodiment, the non-occurrence of an error on the interface of the micro service includes that an interface return of the micro service is not timed out, and the detecting whether the interface return of the micro service is timed out includes:
receiving heartbeat detection sent by an interface of the micro service;
acquiring the time delay of the heartbeat detection;
judging whether the time delay of the heartbeat detection exceeds a preset time delay threshold value or not;
if the time delay of the heartbeat detection exceeds the preset time delay threshold value, determining that the interface of the micro service returns overtime;
and if the time delay of the heartbeat detection does not exceed the preset time delay threshold value, determining that the interface return of the micro service is not overtime.
In an optional embodiment, the method further comprises:
when detecting that the interface of the micro service has errors, printing an error log through the state checking server;
and calculating the number of error logs corresponding to each micro-service interface through a log platform, and triggering an alarm and informing an appointed person when the number is greater than a set threshold value.
A second aspect of the invention provides a computer device comprising a processor for implementing the microservice status checking method when executing a computer program stored in a memory.
A third aspect of the present invention provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, implements the microservice status checking method.
To sum up, the method, the computer device and the storage medium for checking micro service statuses described in the present invention first group micro services according to service contents, configure interface configuration tables for the grouped micro services, so that the micro services in the same group share the same interface configuration table, when detecting that an interface configuration table of any micro service is updated, send the updated interface configuration table to RedisStream and a configuration modification message to a task scheduling server through a configuration server, then obtain the updated interface configuration table from the RedisStream through the task scheduling server, and update the obtained interface configuration table to a local cache, so as to respond to the expiration of a timing task, read the interface configuration table from the local cache through the task scheduling server, determine a group of any micro service according to the interface configuration table, and finally distribute the micro service statuses to check the micro service statuses according to the group of the micro service through the task scheduling server And requesting to a state checking server corresponding to the group, so that the state checking server performs state checking according to the micro-service state checking request. The method and the device can not only carry out state check on the micro-services, but also determine the affected business content when determining that a certain micro-service has a fault in a grouping mode.
Drawings
Fig. 1 is a flowchart of a method for checking a micro service status according to an embodiment of the present invention.
Fig. 2 is a structural diagram of a microservice status checking apparatus according to a second embodiment of the present invention.
Fig. 3 is a schematic structural diagram of a computer device according to a third embodiment of the present invention.
Detailed Description
In order that the above objects, features and advantages of the present invention can be more clearly understood, a detailed description of the present invention will be given below with reference to the accompanying drawings and specific embodiments. It should be noted that the embodiments of the present invention and features of the embodiments may be combined with each other without conflict.
Unless defined otherwise, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The terminology used in the description of the invention herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.
The micro-service state checking method provided by the embodiment of the invention is executed by the computer equipment, and correspondingly, the micro-service state checking device runs in the computer equipment.
Fig. 1 is a flowchart of a method for checking a micro service status according to an embodiment of the present invention. The microservice status checking method specifically includes the following steps, and the sequence of the steps in the flowchart can be changed and some steps can be omitted according to different requirements.
And S11, grouping the micro-services according to the service contents.
Microservices are an architecture and organizational approach to developing software consisting of small, independent services that communicate through well-defined APIs (Application Programming interfaces). The microservice architecture makes applications easier to expand and develop faster, speeding innovation and shortening time-to-market for new functionality.
The microservice described in this embodiment may refer to a microservice system of a business (e.g., insurance sales). A complete micro service system comprises a plurality of micro services, and a call chain is formed when the micro services are called mutually.
In an optional embodiment, the grouping of micro services according to service contents includes:
determining the level of the business content according to a preset business structure tree;
judging whether the service contents in the same level have the same father node;
when the service contents in the same level have the same father node, determining the service contents with the same father node as belonging to the same sub-domain;
and configuring a packet identifier for each subdomain according to the order from left to right and the hierarchy of the service content and associating a micro-service interface for each subdomain.
The service structure tree is a nonlinear data structure which is established by service personnel in advance according to the attributes of the service and the functions of the service. And matching each service content with a plurality of service contents in the preset service structure tree, so as to determine the level of the service contents in the preset service structure tree. The hierarchy determines the sequence of executing the service contents, and the service contents in the upper hierarchy are executed preferentially to the service contents in the lower hierarchy. The service contents located in the same hierarchy are sequentially executed in the order from left to right.
The service contents with the same father node indicate that the same service function is completed together, so that the service contents with the same father node are determined as sub-domains belonging to the same service. For example, assuming that the service contents at the third hierarchy level and having the same parent node are determined as the same sub-domain, and the service contents at the third hierarchy level correspond to 3 sub-domains, a packet identifier 31, 32, 33 is configured for each sub-domain in sequence from left to right. The sub-domain corresponding to the packet identifier 31 is associated with an interface a of a micro-service, the sub-domain corresponding to the packet identifier 32 is associated with an interface B of a micro-service, and the sub-domain corresponding to the packet identifier 33 is associated with an interface C of a micro-service.
In this optional embodiment, the subdomains corresponding to the service content are determined according to the preset service structure tree, and a micro-service interface is associated with each subdomain, so that association between the service content and the micro-service interfaces is realized, and grouping of the micro-service interfaces is realized. Grouping the micro services according to the service content can ensure that the micro services are not divided too small and also can ensure that the micro services are not divided too large, thereby ensuring the close coupling between the micro services.
And S12, configuring an interface configuration table for the micro-service of the same group.
Configuring an interface configuration table for a microservice refers to a plurality of parameters that define an interface for the microservice, which may include, but are not limited to: the returned result check rule, Uniform Resource Locator (URL) of each interface, request mode, request parameter, timeout time, returned result data structure, interface grouping, calling sequence, and other information are configured in the configuration table.
The returned result verification rule defines the following parameters: key, compare operator, value. The same interface can correspond to a plurality of check rules.
The micro-services of the same group share the same interface configuration table, and the interface configuration tables of the micro-services of different groups are physically isolated.
S13, when detecting that the interface configuration table of any micro service is updated, sending the updated interface configuration table to the ReDisStream and the configuration modification message to the task scheduling server through the configuration server.
When detecting that any parameter in any interface configuration table has been added, modified, deleted, etc., it is determined that the interface configuration table of any interface of the microservice has been updated.
When detecting that the interface configuration table of any micro-service interface is updated, the configuration server sends the updated interface configuration table to the ReDisStream for storage, and simultaneously sends a configuration modification message to the task scheduling server through an XADD command.
The updated interface configuration table is sent to the ReDisStream through the configuration server, so that the persistence and the master-backup copying functions of the message can be ensured, and the message is not lost.
S14, the updated interface configuration table is obtained from the ReDisStream through the task scheduling server, and the obtained interface configuration table is updated to a local cache.
And after receiving the message sent by the configuration server, the task scheduling server acquires an interface configuration table from the ReDisStream through an XREAD command, wherein the acquired interface configuration table is the latest interface configuration table.
And the task scheduling server updates the acquired interface configuration table to the self cache, so that the task scheduling server is ensured to have the latest interface configuration information in the self cache.
S15, responding to the expiration of the timing task, reading an interface configuration table from the local cache through the task scheduling server, and determining the grouping where any micro service is located according to the interface configuration table.
The task scheduling server is preset with a timing task, executes the timing task once every fixed time (the fixed time is configurable), and reads an interface configuration table from the buffer memory of the task scheduling server.
The interface configuration table also records a group identifier corresponding to the interface of the micro service. And the task scheduling server determines a group identifier corresponding to the interface of the micro service according to the interface configuration table, so as to determine the group of the micro service.
S16, distributing micro service state check request to the state check server corresponding to the group according to the group where the micro service is located by the task scheduling server, so that the state check server performs state check according to the micro service state check request.
The interface of each group of microservices corresponds to one or more stateful inspection servers. And when the task scheduling server determines the group in which the micro service is positioned, initiating a micro service state check request, and distributing the micro service state check request to a state check server corresponding to the group in which the micro service is positioned.
And the state checking server initiates HTTP request calling to the corresponding micro-service interface according to the micro-service state checking request sent by the task scheduling service, and sets overtime time to check the state of the micro-service.
In an alternative embodiment, when each set of microservices corresponds to a plurality of stateful inspection servers, the method comprises:
distributing a status check test script to each status check server;
acquiring the range of the random number in the state checking test script through the state checking server;
generating a target random number according to the range of the random number;
generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file and the target random number;
performing state inspection test according to the state inspection test file and acquiring the performance after the test is finished;
and distributing a micro-service state check request to a state check server corresponding to the group according to the performance.
The state checking server randomly or randomly generates a target random number from the range of the random number, and controls the state checking server to generate the target random number through the range of the given random number, so that the probability that each random number is acquired by each state checking server is ensured to be the same, the target random numbers generated by the state checking server are the same, the state checking servers are uniformly grouped according to the generated target random numbers, the number of the state checking servers in each group is equal to the number of standard test files, the random numbers acquired by the state checking servers in the same group are the same, and the random numbers acquired by the state checking servers in different groups are different.
The stateful inspection server performs a stateful inspection test by installing and initializing the stateful inspection test file after generating the stateful inspection test file. The performance may include: CPU usage, etc.
By distributing the state inspection test scripts to each state inspection server, the state inspection servers can rapidly deploy different state inspection test files according to the state inspection test scripts, the deployment efficiency of the state inspection test files is improved, and the health test efficiency is improved. Because the content of the deployed state inspection test file is not required to be concerned when the performance of the state inspection server is tested, and only the size of the deployed state inspection test file is required to be concerned, the state inspection test file can be quickly generated according to the pre-stored basic test file, the standard test file and the target random number, and thus, the process of downloading the state inspection test file can be eliminated.
In an optional embodiment, the generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file, and the target random number includes:
calculating the size of the basic test file;
determining the cycle number according to the size of the basic test file and the standard test file;
and writing the target random number into the basic test file by using a command line, and circularly copying the cycle times to the target random number to obtain a state inspection test file.
In order to ensure that the contents of the test files deployed in the stateful inspection servers of the same group are the same, and the contents of the test files deployed in the stateful inspection servers of different groups are different, stateful inspection test files of different contents can be constructed by using the command line and the target random number generated by the stateful inspection servers.
In an optional embodiment, the distributing the microservice status check request to the status check server corresponding to the group according to the performance includes:
calculating a sum of the performance of the plurality of stateful inspection servers;
calculating a performance weight of each status check server according to the sum;
and distributing micro-service state checking requests to the corresponding state checking servers according to the performance weights.
Wherein the number of micro-service status check requests distributed by the status check server is inversely related to the performance weight. That is, the larger the performance weight of the status check server is, the smaller the number of micro-service status check requests to be distributed correspondingly is, and the smaller the performance weight of the status check server is, the larger the number of micro-service status check requests to be distributed correspondingly is.
And distributing the micro-service state check request to the state check servers corresponding to the group according to the performance, so that the load balance among the plurality of state check servers can be effectively ensured, the quick state check of the interface of the micro-service is ensured, and the efficiency of the state check of the micro-service interface is improved.
In an optional embodiment, the method further comprises:
when detecting that the interface of the micro service has no error, acquiring a return result of the interface of the micro service;
acquiring a returned result verification rule in an interface configuration table of the microservice;
checking the returned result by using the returned result checking rule;
when the returned result is successfully verified, determining that any one micro service state is normal;
and when the check of the return result fails, determining that any micro-service state is abnormal.
And when the interface return of the micro service is detected to be not overtime, determining that the interface of the micro service is detected to be not in error.
If the interface of the microservice returns normally, analyzing the returned result, checking by using a returned result checking rule, and if the returned result checking rule is not met, indicating that the checking fails. If the returned result check rule is met, the check is successful. After determining that the verification failed, an error log may also be printed and the number of error logs calculated by the log platform.
In an alternative embodiment, detecting whether an interface return of the microservice times out comprises:
receiving heartbeat detection sent by an interface of the micro service;
acquiring the time delay of the heartbeat detection;
judging whether the time delay of the heartbeat detection exceeds a preset time delay threshold value or not;
if the time delay of the heartbeat detection exceeds the preset time delay threshold value, determining that the interface of the micro service returns overtime;
and if the time delay of the heartbeat detection does not exceed the preset time delay threshold value, determining that the interface return of the micro service is not overtime.
In specific implementation, firstly, a heartbeat detection interval, preset sending time of heartbeat detection and preset normal time delay of heartbeat detection are set, then expected time of receiving the heartbeat detection is obtained, and the time difference between the time of actually receiving the heartbeat detection and the expected time is determined as the time delay of the heartbeat detection.
The preset time delay threshold may be a preset multiple of a normal time delay of a preset heartbeat detection.
In an optional embodiment, the method further comprises:
when detecting that the interface of the micro service has errors, printing an error log through the state checking server;
and calculating the number of error logs corresponding to each micro-service interface through a log platform, and triggering an alarm and informing an appointed person when the number is greater than a set threshold value.
When the interface detecting the micro service returns overtime, or throws other exception, or the interface returns an error code, it is determined that the interface detecting the micro service has an error.
Grouping micro services according to service contents, configuring an interface configuration table for the grouped micro services to enable the micro services in the same group to share the same interface configuration table, sending the updated interface configuration table to ReDisStream and a configuration modification message to a task scheduling server through a configuration server when the update of the interface configuration table of any micro service is detected, then obtaining the updated interface configuration table from the ReDisStream through the task scheduling server, updating the obtained interface configuration table to a local cache, reading the interface configuration table from the local cache through the task scheduling server in response to the expiration of a timing task, determining a group where any micro service is located according to the interface configuration table, and finally distributing a micro service state check request to a state check server corresponding to the group through the task scheduling server according to the group where the micro service is located, and enabling the state checking server to carry out state checking according to the micro-service state checking request.
According to the technical scheme, the state of the micro-service can be checked, and the affected service content can be determined when a certain micro-service is determined to have a fault in a grouping mode.
The designated person refers to a person responsible for the microservice, such as an operation and maintenance person. When the number of the error logs corresponding to the interface of the micro service is larger than the set threshold value, the micro service is indicated to have higher failure frequency, and the appointed person is informed in time, so that the appointed person can know the health condition of the service in the first time.
It is emphasized that the interface configuration table may be stored in a node of the blockchain in order to further ensure the privacy and security of the interface configuration table.
Fig. 2 is a structural diagram of a microservice status checking apparatus according to a second embodiment of the present invention.
In some embodiments, the microservice status checking apparatus 20 may comprise a plurality of functional modules comprised of computer program segments. The computer program of each program segment in the microservice status checking apparatus 20 may be stored in a memory of a computer device and executed by at least one processor to perform the functions of microservice status checking (described in detail in fig. 1).
In this embodiment, the microservice status checking apparatus 20 may be divided into a plurality of functional modules according to the functions performed by the microservice status checking apparatus. The functional module may include: a grouping module 201, a configuration module 202, a sending module 203, a caching module 204, a reading module 205, a distribution module 206, a verification module 207, and a printing module 208. The module referred to herein is a series of computer program segments capable of being executed by at least one processor and capable of performing a fixed function and is stored in memory. In the present embodiment, the functions of the modules will be described in detail in the following embodiments.
The grouping module 201 is configured to group the micro services according to the service content.
Microservices are an architecture and organizational approach to developing software consisting of small, independent services that communicate through well-defined APIs (Application Programming interfaces). The microservice architecture makes applications easier to expand and develop faster, speeding innovation and shortening time-to-market for new functionality.
The microservice described in this embodiment may refer to a microservice system of a business (e.g., insurance sales). A complete micro service system comprises a plurality of micro services, and a call chain is formed when the micro services are called mutually.
In an optional embodiment, the grouping module 201 grouping the micro services according to the service content includes:
determining the level of the business content according to a preset business structure tree;
judging whether the service contents in the same level have the same father node;
when the service contents in the same level have the same father node, determining the service contents with the same father node as belonging to the same sub-domain;
and configuring a packet identifier for each subdomain according to the order from left to right and the hierarchy of the service content and associating a micro-service interface for each subdomain.
The service structure tree is a nonlinear data structure which is established by service personnel in advance according to the attributes of the service and the functions of the service. And matching each service content with a plurality of service contents in the preset service structure tree, so as to determine the level of the service contents in the preset service structure tree. The hierarchy determines the sequence of executing the service contents, and the service contents in the upper hierarchy are executed preferentially to the service contents in the lower hierarchy. The service contents located in the same hierarchy are sequentially executed in the order from left to right.
The service contents with the same father node indicate that the same service function is completed together, so that the service contents with the same father node are determined as sub-domains belonging to the same service. For example, assuming that the service contents at the third hierarchy level and having the same parent node are determined as the same sub-domain, and the service contents at the third hierarchy level correspond to 3 sub-domains, a packet identifier 31, 32, 33 is configured for each sub-domain in sequence from left to right. The sub-domain corresponding to the packet identifier 31 is associated with an interface a of a micro-service, the sub-domain corresponding to the packet identifier 32 is associated with an interface B of a micro-service, and the sub-domain corresponding to the packet identifier 33 is associated with an interface C of a micro-service.
In this optional embodiment, the subdomains corresponding to the service content are determined according to the preset service structure tree, and a micro-service interface is associated with each subdomain, so that association between the service content and the micro-service interfaces is realized, and grouping of the micro-service interfaces is realized. Grouping the micro services according to the service content can ensure that the micro services are not divided too small and also can ensure that the micro services are not divided too large, thereby ensuring the close coupling between the micro services.
The configuration module 202 is configured to configure an interface configuration table for the micro services in the same group.
Configuring an interface configuration table for a microservice refers to a plurality of parameters that define an interface for the microservice, which may include, but are not limited to: the returned result check rule, Uniform Resource Locator (URL) of each interface, request mode, request parameter, timeout time, returned result data structure, interface grouping, calling sequence, and other information are configured in the configuration table.
The returned result verification rule defines the following parameters: key, compare operator, value. The same interface can correspond to a plurality of check rules.
The micro-services of the same group share the same interface configuration table, and the interface configuration tables of the micro-services of different groups are physically isolated.
The sending module 203 is configured to send the updated interface configuration table to the RedisStream and the configuration modification message to the task scheduling server through the configuration server when detecting that the interface configuration table of any microservice is updated.
When detecting that any parameter in any interface configuration table has been added, modified, deleted, etc., it is determined that the interface configuration table of any interface of the microservice has been updated.
When detecting that the interface configuration table of any micro-service interface is updated, the configuration server sends the updated interface configuration table to the ReDisStream for storage, and simultaneously sends a configuration modification message to the task scheduling server through an XADD command.
The updated interface configuration table is sent to the ReDisStream through the configuration server, so that the persistence and the master-backup copying functions of the message can be ensured, and the message is not lost.
The cache module 204 is configured to obtain the updated interface configuration table from the RedisStream through the task scheduling server, and update the obtained interface configuration table to a local cache.
And after receiving the message sent by the configuration server, the task scheduling server acquires an interface configuration table from the ReDisStream through an XREAD command, wherein the acquired interface configuration table is the latest interface configuration table.
And the task scheduling server updates the acquired interface configuration table to the self cache, so that the task scheduling server is ensured to have the latest interface configuration information in the self cache.
The reading module 205 is configured to, in response to the expiration of the timing task, read an interface configuration table from the local cache through the task scheduling server, and determine a packet where any micro service is located according to the interface configuration table.
The task scheduling server is preset with a timing task, executes the timing task once every fixed time (the fixed time is configurable), and reads an interface configuration table from the buffer memory of the task scheduling server.
The interface configuration table also records a group identifier corresponding to the interface of the micro service. And the task scheduling server determines a group identifier corresponding to the interface of the micro service according to the interface configuration table, so as to determine the group of the micro service.
The distributing module 206 is configured to distribute, by the task scheduling server, a micro-service status check request to a status check server corresponding to the group according to the group in which the micro-service is located, so that the status check server performs status check according to the micro-service status check request.
The interface of each group of microservices corresponds to one or more stateful inspection servers. And when the task scheduling server determines the group in which the micro service is positioned, initiating a micro service state check request, and distributing the micro service state check request to a state check server corresponding to the group in which the micro service is positioned.
And the state checking server initiates HTTP request calling to the corresponding micro-service interface according to the micro-service state checking request sent by the task scheduling service, and sets overtime time to check the state of the micro-service.
In an optional embodiment, when each set of microservices corresponds to a plurality of stateful inspection servers, the distribution module 206 is configured to: distributing a status check test script to each status check server; acquiring the range of the random number in the state checking test script through the state checking server; generating a target random number according to the range of the random number; generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file and the target random number; performing state inspection test according to the state inspection test file and acquiring the performance after the test is finished; and distributing a micro-service state check request to a state check server corresponding to the group according to the performance.
The state checking server randomly or randomly generates a target random number from the range of the random number, and controls the state checking server to generate the target random number through the range of the given random number, so that the probability that each random number is acquired by each state checking server is ensured to be the same, the target random numbers generated by the state checking server are the same, the state checking servers are uniformly grouped according to the generated target random numbers, the number of the state checking servers in each group is equal to the number of standard test files, the random numbers acquired by the state checking servers in the same group are the same, and the random numbers acquired by the state checking servers in different groups are different.
The stateful inspection server performs a stateful inspection test by installing and initializing the stateful inspection test file after generating the stateful inspection test file. The performance may include: CPU usage, etc.
By distributing the state inspection test scripts to each state inspection server, the state inspection servers can rapidly deploy different state inspection test files according to the state inspection test scripts, the deployment efficiency of the state inspection test files is improved, and the health test efficiency is improved. Because the content of the deployed state inspection test file is not required to be concerned when the performance of the state inspection server is tested, and only the size of the deployed state inspection test file is required to be concerned, the state inspection test file can be quickly generated according to the pre-stored basic test file, the standard test file and the target random number, and thus, the process of downloading the state inspection test file can be eliminated.
In an optional embodiment, the generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file, and the target random number includes:
calculating the size of the basic test file;
determining the cycle number according to the size of the basic test file and the standard test file;
and writing the target random number into the basic test file by using a command line, and circularly copying the cycle times to the target random number to obtain a state inspection test file.
In order to ensure that the contents of the test files deployed in the stateful inspection servers of the same group are the same, and the contents of the test files deployed in the stateful inspection servers of different groups are different, stateful inspection test files of different contents can be constructed by using the command line and the target random number generated by the stateful inspection servers.
In an optional embodiment, the distributing the microservice status check request to the status check server corresponding to the group according to the performance includes:
calculating a sum of the performance of the plurality of stateful inspection servers;
calculating a performance weight of each status check server according to the sum;
and distributing micro-service state checking requests to the corresponding state checking servers according to the performance weights.
Wherein the number of micro-service status check requests distributed by the status check server is inversely related to the performance weight. That is, the larger the performance weight of the status check server is, the smaller the number of micro-service status check requests to be distributed correspondingly is, and the smaller the performance weight of the status check server is, the larger the number of micro-service status check requests to be distributed correspondingly is.
And distributing the micro-service state check request to the state check servers corresponding to the group according to the performance, so that the load balance among the plurality of state check servers can be effectively ensured, the quick state check of the interface of the micro-service is ensured, and the efficiency of the state check of the micro-service interface is improved.
The verification module 207 is configured to: when detecting that the interface of the micro service has no error, acquiring a return result of the interface of the micro service; acquiring a returned result verification rule in an interface configuration table of the microservice; checking the returned result by using the returned result checking rule; when the returned result is successfully verified, determining that any one micro service state is normal; and when the check of the return result fails, determining that any micro-service state is abnormal.
And when the interface return of the micro service is detected to be not overtime, determining that the interface of the micro service is detected to be not in error.
If the interface of the microservice returns normally, analyzing the returned result, checking by using a returned result checking rule, and if the returned result checking rule is not met, indicating that the checking fails. If the returned result check rule is met, the check is successful. After determining that the verification failed, an error log may also be printed and the number of error logs calculated by the log platform.
In an alternative embodiment, detecting whether an interface return of the microservice times out comprises:
receiving heartbeat detection sent by an interface of the micro service;
acquiring the time delay of the heartbeat detection;
judging whether the time delay of the heartbeat detection exceeds a preset time delay threshold value or not;
if the time delay of the heartbeat detection exceeds the preset time delay threshold value, determining that the interface of the micro service returns overtime;
and if the time delay of the heartbeat detection does not exceed the preset time delay threshold value, determining that the interface return of the micro service is not overtime.
In specific implementation, firstly, a heartbeat detection interval, preset sending time of heartbeat detection and preset normal time delay of heartbeat detection are set, then expected time of receiving the heartbeat detection is obtained, and the time difference between the time of actually receiving the heartbeat detection and the expected time is determined as the time delay of the heartbeat detection.
The preset time delay threshold may be a preset multiple of a normal time delay of a preset heartbeat detection.
The printing module 208 is configured to print an error log through the status check server when detecting that an error occurs in the interface of the micro service.
The sending module 203 is configured to calculate, through the log platform, the number of error logs corresponding to each interface of the micro service, and trigger an alarm and notify an appointed person when the number is greater than a set threshold.
When the interface detecting the micro service returns overtime, or throws other exception, or the interface returns an error code, it is determined that the interface detecting the micro service has an error.
The designated person refers to a person responsible for the microservice, such as an operation and maintenance person. When the number of the error logs corresponding to the interface of the micro service is larger than the set threshold value, the micro service is indicated to have higher failure frequency, and the appointed person is informed in time, so that the appointed person can know the health condition of the service in the first time.
Grouping micro services according to service contents, configuring an interface configuration table for the grouped micro services to enable the micro services in the same group to share the same interface configuration table, sending the updated interface configuration table to ReDisStream and a configuration modification message to a task scheduling server through a configuration server when the update of the interface configuration table of any micro service is detected, then obtaining the updated interface configuration table from the ReDisStream through the task scheduling server, updating the obtained interface configuration table to a local cache, reading the interface configuration table from the local cache through the task scheduling server in response to the expiration of a timing task, determining a group where any micro service is located according to the interface configuration table, and finally distributing a micro service state check request to a state check server corresponding to the group through the task scheduling server according to the group where the micro service is located, and enabling the state checking server to carry out state checking according to the micro-service state checking request.
According to the technical scheme, the state of the micro-service can be checked, and the affected service content can be determined when a certain micro-service is determined to have a fault in a grouping mode.
It is emphasized that the interface configuration table may be stored in a node of the blockchain in order to further ensure the privacy and security of the interface configuration table.
Fig. 3 is a schematic structural diagram of a computer device according to a third embodiment of the present invention. In the preferred embodiment of the present invention, the computer device 3 includes a memory 31, at least one processor 32, at least one communication bus 33, and a transceiver 34.
It will be appreciated by those skilled in the art that the configuration of the computer device shown in fig. 3 does not constitute a limitation of the embodiments of the present invention, and may be a bus-type configuration or a star-type configuration, and that the computer device 3 may include more or less hardware or software than those shown, or a different arrangement of components.
In some embodiments, the computer device 3 is a device capable of automatically performing numerical calculation and/or information processing according to instructions set or stored in advance, and the hardware includes but is not limited to a microprocessor, an application specific integrated circuit, a programmable gate array, a digital processor, an embedded device, and the like. The computer device 3 may also include a client device, which includes, but is not limited to, any electronic product capable of interacting with a client through a keyboard, a mouse, a remote controller, a touch pad, or a voice control device, for example, a personal computer, a tablet computer, a smart phone, a digital camera, etc.
It should be noted that the computer device 3 is only an example, and other electronic products that are currently available or may come into existence in the future, such as electronic products that can be adapted to the present invention, should also be included in the scope of the present invention, and are included herein by reference.
In some embodiments, the memory 31 has stored therein a computer program which, when executed by the at least one processor 32, implements all or part of the steps of the microservice status checking method as described. The Memory 31 includes a Read-Only Memory (ROM), a Programmable Read-Only Memory (PROM), an Erasable Programmable Read-Only Memory (EPROM), a One-time Programmable Read-Only Memory (OTPROM), an electronically Erasable rewritable Read-Only Memory (Electrically-Erasable Programmable Read-Only Memory (EEPROM)), an optical Read-Only disk (CD-ROM) or other optical disk Memory, a magnetic disk Memory, a tape Memory, or any other medium readable by a computer capable of carrying or storing data.
Further, the computer-readable storage medium may mainly include a storage program area and a storage data area, wherein the storage program area may store an operating system, an application program required for at least one function, and the like; the storage data area may store data created according to the use of the blockchain node, and the like.
The block chain is a novel application mode of computer technologies such as distributed data storage, point-to-point transmission, a consensus mechanism, an encryption algorithm and the like. A block chain (Blockchain), which is essentially a decentralized database, is a series of data blocks associated by using a cryptographic method, and each data block contains information of a batch of network transactions, so as to verify the validity (anti-counterfeiting) of the information and generate a next block. The blockchain may include a blockchain underlying platform, a platform product service layer, an application service layer, and the like.
In some embodiments, the at least one processor 32 is a Control Unit (Control Unit) of the computer device 3, connects various components of the entire computer device 3 by using various interfaces and lines, and executes various functions and processes data of the computer device 3 by running or executing programs or modules stored in the memory 31 and calling data stored in the memory 31. For example, the at least one processor 32, when executing the computer program stored in the memory, implements all or part of the steps of the microservice status checking method described in the embodiments of the present invention; or implement all or part of the functions of the microservice status checking apparatus. The at least one processor 32 may be composed of an integrated circuit, for example, a single packaged integrated circuit, or may be composed of a plurality of integrated circuits packaged with the same or different functions, including one or more Central Processing Units (CPUs), microprocessors, digital Processing chips, graphics processors, and combinations of various control chips.
In some embodiments, the at least one communication bus 33 is arranged to enable connection communication between the memory 31 and the at least one processor 32 or the like.
Although not shown, the computer device 3 may further include a power supply (such as a battery) for supplying power to each component, and preferably, the power supply may be logically connected to the at least one processor 32 through a power management device, so as to implement functions of managing charging, discharging, and power consumption through the power management device. The power supply may also include any component of one or more dc or ac power sources, recharging devices, power failure detection circuitry, power converters or inverters, power status indicators, and the like. The computer device 3 may further include various sensors, a bluetooth module, a Wi-Fi module, and the like, which are not described herein again.
The integrated unit implemented in the form of a software functional module may be stored in a computer-readable storage medium. The software functional module is stored in a storage medium and includes several instructions to enable a computer device (which may be a personal computer, a computer device, or a network device) or a processor (processor) to execute parts of the methods according to the embodiments of the present invention.
In the embodiments provided in the present invention, it should be understood that the disclosed apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the modules is only one logical functional division, and other divisions may be realized in practice.
The modules described as separate parts may or may not be physically separate, and parts displayed as modules may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of the present embodiment.
In addition, functional modules in the embodiments of the present invention may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into one unit. The integrated unit can be realized in a form of hardware, or in a form of hardware plus a software functional module.
It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned. Furthermore, it is obvious that the word "comprising" does not exclude other elements or that the singular does not exclude the plural. A plurality of units or means recited in the present invention can also be implemented by one unit or means through software or hardware. The terms first, second, etc. are used to denote names, but not any particular order.
Finally, it should be noted that the above embodiments are only for illustrating the technical solutions of the present invention and not for limiting, and although the present invention is described in detail with reference to the preferred embodiments, it should be understood by those skilled in the art that modifications or equivalent substitutions may be made on the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention.
Claims (10)
1. A method for micro-service status checking, the method comprising:
grouping the micro-services according to the service content;
configuring an interface configuration table for the micro-services of the same group;
when detecting that the interface configuration table of any micro service is updated, sending the updated interface configuration table to the ReDisStream and a configuration modification message to the task scheduling server through the configuration server;
acquiring the updated interface configuration table from the ReDisStream through the task scheduling server, and updating the acquired interface configuration table to a local cache;
reading an interface configuration table from the local cache through the task scheduling server in response to the expiration of the timing task, and determining a group where any micro service is located according to the interface configuration table;
and distributing a micro-service state check request to a state check server corresponding to the group according to the group in which the micro-service is positioned by the task scheduling server, so that the state check server performs state check according to the micro-service state check request.
2. The method for checking the status of micro-services according to claim 1, wherein said grouping micro-services according to the contents of the services comprises:
determining the level of the business content according to a preset business structure tree;
judging whether the service contents in the same level have the same father node;
when the service contents in the same level have the same father node, determining the service contents with the same father node as belonging to the same sub-domain;
and configuring a packet identifier for each subdomain according to the order from left to right and the hierarchy of the service content and associating a micro-service interface for each subdomain.
3. The method of claim 1, wherein when each set of microservices corresponds to a plurality of state checking servers, the method comprises:
distributing a status check test script to each status check server;
acquiring the range of the random number in the state checking test script through the state checking server;
generating a target random number according to the range of the random number;
generating a state check test file according to a pre-stored basic test file, a pre-stored standard test file and the target random number;
performing state inspection test according to the state inspection test file and acquiring the performance after the test is finished;
and distributing a micro-service state check request to a state check server corresponding to the group according to the performance.
4. The method of claim 3, wherein the generating the state check test file according to the pre-stored basic test file, the standard test file, and the target random number comprises:
calculating the size of the basic test file;
determining the cycle number according to the size of the basic test file and the standard test file;
and writing the target random number into the basic test file by using a command line, and circularly copying the cycle times to the target random number to obtain a state inspection test file.
5. The method of claim 4, wherein the distributing the microservice status check request to the status check server corresponding to the packet according to the performance comprises:
calculating a sum of the performance of the plurality of stateful inspection servers;
calculating a performance weight of each status check server according to the sum;
and distributing micro-service state checking requests to the corresponding state checking servers according to the performance weights.
6. The microservice status checking method according to any one of claims 1 to 5, characterized in that the method further comprises:
when detecting that the interface of the micro service has no error, acquiring a return result of the interface of the micro service;
acquiring a returned result verification rule in an interface configuration table of the microservice;
checking the returned result by using the returned result checking rule;
when the returned result is successfully verified, determining that any one micro service state is normal;
and when the check of the return result fails, determining that any micro-service state is abnormal.
7. The method of claim 6, wherein the micro-service interface failing to fail comprises the micro-service interface returning failing to time out, and wherein detecting whether the micro-service interface returning has timed out comprises:
receiving heartbeat detection sent by an interface of the micro service;
acquiring the time delay of the heartbeat detection;
judging whether the time delay of the heartbeat detection exceeds a preset time delay threshold value or not;
if the time delay of the heartbeat detection exceeds the preset time delay threshold value, determining that the interface of the micro service returns overtime;
and if the time delay of the heartbeat detection does not exceed the preset time delay threshold value, determining that the interface return of the micro service is not overtime.
8. The microservice status checking method of claim 6, wherein the method further comprises:
when detecting that the interface of the micro service has errors, printing an error log through the state checking server;
and calculating the number of error logs corresponding to each micro-service interface through a log platform, and triggering an alarm and informing an appointed person when the number is greater than a set threshold value.
9. A computer device, characterized in that the computer device comprises a processor for implementing the microservice status checking method according to any of the claims 1 to 8 when executing a computer program stored in a memory.
10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out a microservice status checking method according to any one of claims 1 to 8.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110698869.8A CN113515403B (en) | 2021-06-23 | 2021-06-23 | Micro-service state checking method, computer device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202110698869.8A CN113515403B (en) | 2021-06-23 | 2021-06-23 | Micro-service state checking method, computer device and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN113515403A CN113515403A (en) | 2021-10-19 |
| CN113515403B true CN113515403B (en) | 2021-11-16 |
Family
ID=78066119
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202110698869.8A Active CN113515403B (en) | 2021-06-23 | 2021-06-23 | Micro-service state checking method, computer device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN113515403B (en) |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106648936A (en) * | 2016-12-29 | 2017-05-10 | Tcl集团股份有限公司 | Cooperative processing method and system based on microservices and server |
| CN110032393A (en) * | 2019-04-18 | 2019-07-19 | 恒生电子股份有限公司 | A kind of micro services dissemination method, device, equipment and medium |
| WO2020257383A1 (en) * | 2019-06-20 | 2020-12-24 | Citrix Systems, Inc. | Systems and method updating adc configuration with intended state using desired state api |
| CN112346899A (en) * | 2020-11-06 | 2021-02-09 | 北京北信源软件股份有限公司 | Method and device for optimizing microservice performance |
Family Cites Families (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US11388273B2 (en) * | 2019-05-05 | 2022-07-12 | International Business Machines Corporation | Achieving atomicity in a chain of microservices |
-
2021
- 2021-06-23 CN CN202110698869.8A patent/CN113515403B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106648936A (en) * | 2016-12-29 | 2017-05-10 | Tcl集团股份有限公司 | Cooperative processing method and system based on microservices and server |
| CN110032393A (en) * | 2019-04-18 | 2019-07-19 | 恒生电子股份有限公司 | A kind of micro services dissemination method, device, equipment and medium |
| WO2020257383A1 (en) * | 2019-06-20 | 2020-12-24 | Citrix Systems, Inc. | Systems and method updating adc configuration with intended state using desired state api |
| CN112346899A (en) * | 2020-11-06 | 2021-02-09 | 北京北信源软件股份有限公司 | Method and device for optimizing microservice performance |
Also Published As
| Publication number | Publication date |
|---|---|
| CN113515403A (en) | 2021-10-19 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105933137B (en) | A kind of method for managing resource, apparatus and system | |
| CN103201724B (en) | Providing application high availability in highly-available virtual machine environments | |
| US10635473B2 (en) | Setting support program, setting support method, and setting support device | |
| WO2013140608A1 (en) | Method and system that assist analysis of event root cause | |
| CN110995511A (en) | Cloud computing operation and maintenance management method and device based on micro-service architecture and terminal equipment | |
| EP3239840B1 (en) | Fault information provision server and fault information provision method | |
| CN111897697B (en) | Server hardware fault repairing method and device | |
| CN103377101A (en) | Testing system and testing method | |
| CN110677453A (en) | ZooKeeper-based distributed lock service implementation method, device, equipment and storage medium | |
| CN113064744A (en) | Task processing method and device, computer readable medium and electronic equipment | |
| EP3301576A1 (en) | Method and apparatus for monitoring logs of multi-tenant systems | |
| US20220334825A1 (en) | Modular firmware update | |
| CN113076112A (en) | Database deployment method and device and electronic equipment | |
| CN111209333B (en) | Data updating method, device, terminal and storage medium | |
| CN113485933A (en) | Automatic testing method and distributed system | |
| CN113542387A (en) | System publishing method, device, electronic equipment and storage medium | |
| CN113515403B (en) | Micro-service state checking method, computer device and storage medium | |
| JP6015750B2 (en) | Log collection server, log collection system, and log collection method | |
| CN113419949B (en) | Abnormality detection method, device, equipment and storage medium for data processing | |
| CN110928679B (en) | Resource allocation method and device | |
| CN114489956A (en) | Instance starting method and device based on cloud platform | |
| CN110188008B (en) | Job scheduling master-slave switching method and device, computer equipment and storage medium | |
| CN108551484B (en) | User information synchronization method, device, computer device and storage medium | |
| CN114065190A (en) | High-availability and high-safety algorithm automatic online test system | |
| CN109672551B (en) | Cross-data center application publishing method, device, storage medium and device |
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 |