Microservice processing method, device, electronic device and computer readable medium

Abstract

The embodiments of the present disclosure disclose a microservice processing method, device, electronic device and computer-readable medium. A specific implementation of the method includes: in response to determining that at least one microservice is started, for each microservice, executing a first generation step: using a service metadata acquisition device to obtain metadata information during the execution of a self-check program; sending the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object; aggregating at least one microservice description object to a service collection device; in response to detecting a service processing request, instructing a service registration device to traverse a service description object queue to register the service description object queue to a service processing device. This implementation can accurately and efficiently implement the registration of microservices. On the basis of registration, efficient processing of each service of the microservice is achieved to ensure the normal execution of the microservice.

Description

Technical Field

[0001] Embodiments of the present disclosure relate to the field of computer technology, and in particular to a microservice processing method, device, electronic device, and computer-readable medium. Background Art

[0002] At present, with the development of Internet and cloud computing technology, the monolithic architecture has gradually exposed problems such as poor scalability, high maintenance cost, and low deployment efficiency. Microservice architecture came into being, splitting the monolithic application into multiple independent small services, each of which focuses on a single business function and interacts through lightweight communication mechanisms (such as HTTP, gRPC). In the existing microservice architecture system, the service distribution is very scattered. Although it reduces the system coupling, it increases the difficulty of unified management of microservices. On the one hand, the system maintainer does not have a global view to uniformly manage the authentication, current limiting, logging, monitoring and other functions of microservices. On the other hand, the authentication, current limiting, logging, monitoring and other functions of microservices need to be implemented separately by each microservice to achieve logical redundancy. As a result, the existing microservice architecture system has the problems of scattered service distribution, lack of unified management of services, lack of effective service automatic discovery and automatic registration mechanism, and the existing service automatic discovery and automatic registration method and device are not universal and do not support Restful type services, resulting in the inability to achieve various efficient processing for microservices.

[0003] The above information disclosed in this Background section is only for enhancement of understanding of the background of the inventive concept and therefore it may contain information that does not form the prior art that is already known in this country to a person of ordinary skill in the art. Summary of the invention

[0004] The content of this disclosure is used to introduce concepts in a brief form, which will be described in detail in the detailed implementation section below. The content of this disclosure is not intended to identify the key features or essential features of the technical solution claimed for protection, nor is it intended to limit the scope of the technical solution claimed for protection.

[0005] Some embodiments of the present disclosure propose microservice processing methods, devices, electronic devices, and computer-readable media to solve one or more of the technical problems mentioned in the above background technology section.

[0006] In a first aspect, some embodiments of the present disclosure provide a microservice processing method, comprising: in response to determining that at least one microservice is started, for each microservice in the at least one microservice, executing the following first generation step: using a service metadata acquisition device injected into a microservice self-checking program, acquiring metadata information corresponding to the microservice during the execution of the microservice self-checking program; sending the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object; aggregating the obtained at least one microservice description object to a service collection device, so that the service collection device can store the at least one microservice description object in a target memory in the form of a queue; in response to detecting a service processing request sent by a service processing device, instructing a service registration device to traverse the service description object queue in the target memory to call the registration interface of the service processing device, and register the service description object queue to the at least one service processing device, wherein the service processing device supports persistent storage and service processing of the service description object queue, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing.

[0007] In a second aspect, some embodiments of the present disclosure provide a microservice processing device, including: an execution unit, configured to, in response to determining that at least one microservice is started, execute the following first generation step for each microservice in the at least one microservice: using a service metadata acquisition device injected into a microservice self-checking program to acquire metadata information corresponding to the microservice during the execution of the microservice self-checking program; sending the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object; a summary unit, configured to summarize the obtained at least one microservice description object into a service collection; A device for the service collection device to store the at least one microservice description object in the target memory in the form of a queue; an instruction unit is configured to, in response to detecting a service processing request sent by a service processing device, instruct the service registration device to traverse the service description object queue in the target memory to call the registration interface of the service processing device to register the service description object queue to the service processing device, wherein the service processing device supports persistent storage of the service description object queue and at least one service processing, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing.

[0008] In a third aspect, some embodiments of the present disclosure provide an electronic device comprising: one or more processors; a storage device on which one or more programs are stored, and when the one or more programs are executed by the one or more processors, the one or more processors implement the method described in any implementation manner in the first aspect.

[0009] In a fourth aspect, some embodiments of the present disclosure provide a computer-readable medium having a computer program stored thereon, wherein when the program is executed by a processor, the method described in any implementation manner in the first aspect is implemented.

[0010] The above-mentioned various embodiments of the present disclosure have the following beneficial effects: through the microservice processing method of some embodiments of the present disclosure, the registration of microservices can be accurately and efficiently realized. On the basis of registration, efficient processing of each service of the microservice is realized to ensure the normal execution of the microservice. Specifically, the reason for the inefficient processing of microservices is that the existing microservice architecture system has scattered service distribution, a general lack of unified management of services, a general lack of effective service automatic discovery and automatic registration mechanism, and the existing service automatic discovery and automatic registration methods and devices are not universal and do not support Restful type services, resulting in the inability to realize various efficient processing for microservices. Based on this, the microservice processing method of some embodiments of the present disclosure, first, in response to determining that at least one microservice is started, for each microservice in the above at least one microservice, the following first generation step is performed: the first step is to use the service metadata acquisition device injected into the microservice self-check program to obtain the metadata information corresponding to the above microservice during the execution of the above self-check program. Here, by injecting a service metadata acquisition device into the microservice self-checking program, the metadata information corresponding to the microservice can be accurately extracted in the microservice self-checking program, which ensures the completeness of the metadata information corresponding to the microservice, and by injecting the service metadata acquisition device into the self-checking program, the omission of the metadata information corresponding to the microservice is avoided. In the second step, the metadata information is sent to the microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object. Here, the microservice description object conversion device can efficiently and accurately realize the data format unification of the metadata information, avoid the problem of information format confusion, and cause deviation in the corresponding registration of the microservice. Then, the obtained at least one microservice description object is summarized to the service collection device, so that the above-mentioned service collection device can store the above-mentioned at least one microservice description object in the target memory in the form of a queue, so as to realize the collection and sorting processing of at least one microservice description object, so as to facilitate the subsequent automatic registration. Finally, in response to detecting the service processing request sent by the service processing device, the above-mentioned service registration device is instructed to traverse the service description object queue in the above-mentioned target memory to call the registration interface of the above-mentioned service processing device, and register the above-mentioned service description object queue to the above-mentioned service processing device. The service processing device supports the persistent storage of the service description object queue and at least one service processing, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing. Here, by calling the registration interface of the service processing device through the service registration device, each microservice can be automatically and accurately registered in the service processing device, so that the subsequent service processing device can realize dynamic expansion and contraction processing, load balancing processing, service fault detection, service version processing, etc. according to each registered microservice, so as to ensure the normal execution and management and maintenance of at least one microservice.In summary, by injecting the service metadata acquisition device, service collection device, service registration device and service processing device into the microservice self-check program, efficient registration and processing of microservices can be achieved, ensuring the normal operation and abnormal monitoring of at least one microservice. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] The above and other features, advantages and aspects of the embodiments of the present disclosure will become more apparent with reference to the following detailed description in conjunction with the accompanying drawings. Throughout the accompanying drawings, the same or similar reference numerals represent the same or similar elements. It should be understood that the drawings are schematic and that components and elements are not necessarily drawn to scale.

[0012] Figure 1 is a flow chart of some embodiments of the microservice processing method according to the present disclosure;

[0013] Figure 2 is a schematic diagram of the structure of some embodiments of the microservice processing device according to the present disclosure;

[0014] Figure 3 It is a schematic diagram of the structure of an electronic device suitable for implementing some embodiments of the present disclosure. DETAILED DESCRIPTION

[0015] Embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although certain embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be construed as being limited to the embodiments set forth herein. On the contrary, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure. It should be understood that the drawings and embodiments of the present disclosure are only for exemplary purposes and are not intended to limit the scope of protection of the present disclosure.

[0016] It should also be noted that, for ease of description, only the parts related to the invention are shown in the drawings. In the absence of conflict, the embodiments and features in the embodiments of the present disclosure can be combined with each other.

[0017] It should be noted that the concepts such as "first" and "second" mentioned in the present disclosure are only used to distinguish different devices, modules or units, and are not used to limit the order or interdependence of the functions performed by these devices, modules or units.

[0018] It should be noted that the modifications of "one" and "plurality" mentioned in the present disclosure are illustrative rather than restrictive, and those skilled in the art should understand that unless otherwise clearly indicated in the context, it should be understood as "one or more".

[0019] The names of the messages or information exchanged between multiple devices in the embodiments of the present disclosure are only used for illustrative purposes and are not used to limit the scope of these messages or information.

[0020] The present disclosure will be described in detail below with reference to the accompanying drawings and in conjunction with embodiments.

[0021] refer to Figure 1 , shows a process 100 of some embodiments of the microservice processing method according to the present disclosure. The microservice processing method includes the following steps:

[0022] Step 101, in response to determining that at least one microservice is started, for each microservice in the at least one microservice, the following first generation step is performed:

[0023] Step 1011, using the service metadata acquisition device injected into the microservice self-checking program, acquires metadata information corresponding to the microservice during the execution of the microservice self-checking program.

[0024] In some embodiments, the execution subject (e.g., computing device) of the microservice processing method can use the service metadata acquisition device injected into the microservice self-checking program to acquire metadata information corresponding to the microservice in the process of executing the microservice self-checking program. Among them, the microservice can be an application in the form of a microservice architecture. Among them, the microservice self-checking program can be a self-checking program for the microservice. The self-checking program of the microservice refers to a program mechanism for automatically checking the health status of the service and the correctness of the configuration when the microservice is started or the configuration is changed, so as to ensure that the service can operate normally. This program mechanism is particularly important for complex systems, which can help to quickly locate and solve problems and reduce system failure time. The self-checking program can automatically check whether the various functions of the service are working properly when the service is started or the configuration is changed, so as to ensure that there are no omissions or wrong configurations. Through the self-checking program, problems with the service can be discovered in time to avoid service interruptions caused by configuration errors or functional abnormalities. Through regular self-checking, system failures caused by human errors can be reduced and the overall stability of the system can be improved. The service metadata acquisition device can be an acquisition device for acquiring metadata information corresponding to the microservice. For example, the service metadata acquisition device can be a metadata acquisition plug-in for acquiring metadata information (i.e., an acquisition plug-in written by a relevant script). For another example, the service metadata acquisition device may be a device that encapsulates the acquisition plug-in for easy real-time calling. For another example, the service metadata acquisition device may be a service registration center. For example, the service registration center may be one of the following: Consul, Eureka, Zookeeper. The metadata information may be the configuration description information corresponding to the microservice. The metadata information may include but is not limited to at least one of the following: microservice name, application name, request return parameter, service address, service path, request method, custom field.

[0025] Step 1012: Send the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object.

[0026] In some embodiments, the above-mentioned execution subject may send the above-mentioned metadata information to a microservice description object conversion device to perform data conversion processing on the above-mentioned metadata information to generate a microservice description object. Among them, the microservice description object conversion device may be a device that performs data conversion on the metadata information corresponding to the microservice to generate a microservice description object in a predetermined format. In practice, the predetermined format may be a pre-set format that is convenient for subsequent microservice registration. In a specific scenario, the microservice description object conversion device may be an OpenApi conversion device. The microservice description object may be an OpenApi service description object. The OpenApi conversion device is used to convert different types of service metadata into a general OpenApi service description object. In practice, the microservice description object may also be a characterization describing the corresponding configuration of the microservice.

[0027] In some optional implementations of some embodiments, the metadata information includes: at least one parameter information. The parameter information may be the specific parameter content corresponding to the parameter. For example, the parameter information may be the parameter content corresponding to the service address parameter (i.e., the service address). In practice, the at least one parameter may include but is not limited to at least one of the following: microservice name parameter, application name parameter, request return parameter, service address parameter, service path parameter, request method parameter, and custom field parameter.

[0028] Optionally, the execution subject may send the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object, including the following steps:

[0029] In the first step, for the parameter information in the at least one parameter information, the following second generation step is performed:

[0030] Sub-step 1, determining whether the above parameter information is array type information.

[0031] Sub-step 2, in response to determining that the above-mentioned array type is not the above-mentioned array type, determine whether the above-mentioned parameter information is a pre-set predetermined parameter type. The predetermined parameter type may be a pre-determined basic parameter type. For example, the basic parameter type may be one of the following: a character parameter type, a Boolean parameter type.

[0032] Sub-step 3, in response to determining that it is not the above-mentioned predetermined parameter type, performing data parsing on the above-mentioned parameter information to obtain the parsed parameter information as parameter extraction information.

[0033] Here, data parsing may be parameter content extraction under the corresponding type. Parameter extraction information may be the result of content extraction for the parameter. In practice, the above parameter information may be parsed according to at least one regular expression corresponding to the basic parameter type to obtain the parsed parameter information as parameter extraction information.

[0034] In the second step, information is extracted based on at least one parameter obtained to generate a microservice description object.

[0035] As an example, the execution subject may input at least one parameter extraction information into a target description object template to generate a microservice description object. The target description object template may be a description object template to which the specific content of the parameter has not yet been added. The template format corresponding to the target description object template is the same as the object format corresponding to the microservice description object.

[0036] In some optional implementations of some embodiments, the execution subject may perform data conversion processing on the metadata information to generate a microservice description object, including the following steps:

[0037] The first step is to obtain the description field set and description field format set corresponding to the above microservice description object. The description field can be a field in the microservice description object that describes the microservice. The description field set corresponding to the microservice description object can be pre-set. The description field format can be a representation format of the field content corresponding to the description field. Each description field has a one-to-one corresponding description field format.

[0038] In the second step, for each description field in the description field set, the following fourth generation step is performed:

[0039] Sub-step 1: determine the description field format corresponding to the above description field as the target description field format.

[0040] Sub-step 2, generating a conversion instance set for the above-mentioned target description field format, wherein each conversion instance corresponds to metadata of a different format, and the conversion result corresponding to the conversion instance is the field content under the above-mentioned target description field. Among them, the conversion instance can represent an instance after the metadata is converted into the description field content (i.e., the conversion result) under the target description field format. For example, the formats for metadata information include: a first format, a second format, and a third format. The corresponding conversion instance set may include: a conversion instance representing the conversion of the first format into the target description field format, a conversion instance representing the conversion of the second format into the target description field format, and a conversion instance representing the conversion of the third format into the target description field format. Each conversion instance in the above-mentioned conversion instance set can be manually converted and set by relevant technical personnel according to the formats of each metadata information collected.

[0041] Sub-step 3: Filter out a transformation instance matching the metadata information from the transformation instance set as a target transformation instance.

[0042] As an example, first, the execution subject may determine the metadata format that matches the metadata information by format matching, and then select the conversion instance corresponding to the metadata format from the conversion instance set as the target conversion instance.

[0043] Sub-step 4, determining the model conversion parameters corresponding to the above target conversion instance as the target model conversion parameters. Among them, the model conversion parameters can be the conversion parameters corresponding to the description field content generation model. Each target conversion instance has a metadata format. Each metadata format has a corresponding description field content generation model (that is, a neural network model for metadata format conversion). The model conversion parameters are the specific model parameter sets of the description field content generation model. The model structures of the description field content generation models under each metadata format conversion are the same, but their respective model parameter sets are different. The description field content generation model can be a neural network model in the field in the above metadata information corresponding to the description field under the target description field format. In practice, the description field content generation model can be a generative model. Considering that the generative model is currently based on the encoding and decoding model as the model structure, the relevant R&D personnel adaptively adjust the number of layers in the encoding layer and the decoding layer to increase the metadata format conversion. For example, the encoding and decoding model includes: 11 layers of downsampling convolution layers (encoding layer) connected in series and 6 layers of upsampling convolution layers 8 (decoding layer) connected in series.

[0044] As an example, first, the execution subject may determine the instance identifier corresponding to the target conversion instance, then determine the metadata format identifier corresponding to the instance identifier, and finally determine the model conversion parameters corresponding to the metadata format identifier as the target model conversion parameters.

[0045] Sub-step 5: determining a description field content generation model corresponding to the target model conversion parameters.

[0046] As an example, the execution subject may substitute the target model conversion parameters into the initial description field content generation model to obtain the description field content generation model. The initial description field content generation model may be a description field content generation model that has not yet been trained (i.e., the model parameters are a neural network model in an initialized state).

[0047] Sub-step 6: Input the metadata information, the target description field format and the target conversion instance into the description field content generation model to generate the first description field content corresponding to the metadata information under the description field. The field format corresponding to the first description field content is the target description field format.

[0048] Sub-step 7, obtaining the pre-stored regular expression conversion information corresponding to the above target conversion instance. The regular expression conversion information is the conversion information for converting metadata information in the form of regular expressions. The regular expression conversion information can be set by relevant technical personnel according to the different formats of the previous and next information.

[0049] As another example, first, the execution subject may generate an information generation instruction for generating regular expression conversion information according to the target conversion instruction, and then input the information generation instruction into a pre-trained large language model to generate regular expression conversion information.

[0050] Sub-step 8: generating the second description field content in the metadata information under the description field according to the regular expression conversion information.

[0051] As an example, the execution entity may input metadata information under the description field into the regular expression conversion information to obtain the second description field content.

[0052] Sub-step 9: generating conversion description field content according to the first description field content and the second description field content.

[0053] As an example, the execution entity may receive description field selection information selected by a relevant technician from a target platform, and determine the description field content selected from the first description field content and the second description field content as the conversion description field content.

[0054] The third step is to generate a microservice description object based on the obtained conversion description field content set.

[0055] As an example, the execution entity may substitute the conversion description field content set into the microservice description object generation template to generate a microservice description object.

[0056] Optionally, the execution subject may generate the conversion description field content according to the first description field content and the second description field content, comprising the following steps:

[0057] In the first step, in response to determining that the content of the first description field is consistent with the content of the second description field, the content of the first description field is determined as the content of the conversion description field.

[0058] In the second step, in response to determining the inconsistency, a field information set corresponding to the description field is screened out from the metadata information.

[0059] The third step is to display the above-mentioned field information set, the above-mentioned target description field format, the above-mentioned target conversion instance, the above-mentioned first description field content and the above-mentioned second description field content on the target conversion page so that relevant technical personnel can manually confirm the description field content.

[0060] The fourth step is to determine the confirmed content of the confirmation description field as the content of the conversion description field.

[0061] Optionally, after the fourth step, the steps further include:

[0062] In the first step, in response to determining that the above-mentioned confirmation description field content is the first description field content, the above-mentioned regular expression conversion information is adjusted and tested according to the confirmation description field content set within the target time period to generate updated regular expression conversion information as regular expression conversion information. Here, adjustment and testing can be performed on the regular expression information adjustment page.

[0063] In the second step, in response to determining that the above-mentioned confirmed description field content is the second description field content, the above-mentioned description field content generation model is adjusted according to the confirmed description field content set within the above-mentioned target time period to generate an updated description field content generation model as the description field content generation model.

[0064] Step 102 : Aggregate the obtained at least one microservice description object to a service collection device, so that the service collection device can store the at least one microservice description object in a target memory in a queue form.

[0065] In some embodiments, the execution entity may aggregate the obtained at least one microservice description object to a service collection device, so that the service collection device may store the at least one microservice description object in a target memory in the form of a queue. The service collection device may be a device for collecting and arranging microservice information. Here, after storing at least one microservice description object in the target memory in the form of a queue, it is convenient to directly read it from the target memory and perform subsequent microservice registration. The result after storage in the target memory is a service description object queue. Here, the order of the service description objects in the service description object queue may be the order in which the service collection device collects the microservice description objects.

[0066] Step 103, in response to detecting the service processing request sent by the service processing device, instruct the above-mentioned service registration device to traverse the service description object queue in the above-mentioned target memory to call the registration interface of the above-mentioned service processing device to register the above-mentioned service description object queue with the above-mentioned service processing device.

[0067] In some embodiments, in response to detecting a service processing request sent by a service processing device, the execution subject may instruct the service registration device to traverse the service description object queue in the target memory to call the registration interface of the service processing device to register the service description object queue with the service processing device. The service processing device may be a device that supports various service processing of microservices. In practice, the service processing device can realize service operation supervision of microservices at all levels and aspects to ensure the normal operation of each registered microservice. In practice, service processing can be the operation management of microservices. The service processing request may be a request for service processing of microservices. In practice, the service processing request may represent the acquisition of real-time microservices to be registered, and at the same time perform service operation supervision for each microservice. The registration interface may be an interface for registering each service description object in the service registration device to realize microservice registration or registration, which is convenient for the management of subsequent microservices. The service processing device supports persistent storage and service processing of the service description object queue. Service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing. Dynamic scaling processing may be dynamic scaling processing corresponding to microservices. Load balancing processing may be load balancing processing of each microservice during operation. Service fault detection may be detecting fault problems existing in microservices. Service version processing may be various processing for maintaining and controlling the corresponding versions of microservices.

[0068] In some optional implementations of some embodiments, the service processing device is a network interface processing layer. The network interface processing layer may be a Kong gateway. The Kong gateway is a cloud-native, fast, and scalable distributed microservice abstraction layer (also known as an API gateway, API middleware, or Service Mesh in some cases).

[0069] Optionally, the registering of the service description object queue to the service processing device may include the following steps:

[0070] In the first step, in response to determining that the service description object queue is not an empty queue, for the service description objects in the service description object queue, the following registration steps are performed:

[0071] Sub-step 1, determining whether there is a processing object corresponding to the service description object in the corresponding object processing list of the network interface processing layer.

[0072] As an example, the execution subject may determine whether there is a processing object corresponding to the service description object in the object processing list corresponding to the network interface processing layer by querying the identification corresponding to the processing object identification (ie, object ID).

[0073] Sub-step 2: In response to determining existence, replace the corresponding processing object in the above object processing list with the above service description object.

[0074] Sub-step 3: in response to determining that the service description object does not exist, adding the service description object to the object processing list.

[0075] Sub-step 4, in response to determining that the target service description object queue after removing the above service description object is an empty queue, determining the updated object processing list as the microservice registration result corresponding to the above network interface processing layer.

[0076] In the second step, in response to determining that the target service description object queue is not an empty queue, the target service description object queue is used as the service description object queue, and the updated object processing list is used as the object processing list, and the above registration step is continued.

[0077] In some optional implementations of some embodiments, the service processing in the at least one service processing has a corresponding current service processing summary table and a historical service processing summary table. The current service processing summary table may be a summary table of the field contents required in the service processing at the current time. The historical service processing summary table may be a summary table of the field contents required in the service processing at the historical time.

[0078] Optionally, the current service process summary table corresponding to the target service process is generated by the following steps:

[0079] The first step is to determine the processing field set corresponding to the target service process, wherein each processing field in the processing field set may be each field required in the target service process.

[0080] In the second step, for each microservice in the at least one microservice, the following third generation step is performed:

[0081] Sub-step 1: determine the service description object stored corresponding to the above microservice as the target service description object.

[0082] Sub-step 2: for each processing field in the processing field set, filter out the field content corresponding to the processing field from the target service description object.

[0083] The third step is to add the obtained at least one field content set to the initial service processing summary table to obtain the current service processing summary table.

[0084] In some optional implementations of some embodiments, the service failure corresponding to the at least one microservice is detected by the following steps:

[0085] In the first step, for each microservice in the at least one microservice, the following detection steps are performed:

[0086] Sub-step 1, determine the traffic data sequence, resource usage information sequence, microservice call data and processing log of the above-mentioned microservice in the target historical time period. Among them, the traffic data sequence can be the change in traffic corresponding to the microservice in the target historical time period. There is corresponding traffic data at each historical time point. The resource usage information sequence can be the change in resource usage corresponding to the microservice in the target historical time period. Resource usage information can be the computing resources used by the microservice in the process of providing services. Microservice call data can be the call situation of calling other microservices or other call objects to provide services in the target historical time period. The processing log can be the log content of the microservice processing various matters in the target historical time period.

[0087] Sub-step 2, based on the above-mentioned traffic data sequence, using the traffic anomaly monitoring model, generates the first anomaly information corresponding to the traffic monitoring of the above-mentioned microservice. Among them, the traffic anomaly monitoring model can be a neural network model that determines whether there is an anomaly in the traffic. In practice, the traffic anomaly monitoring model can be a regression model based on a time series neural network model (for example, a recurrent neural network model, a long short-term memory neural network model). The output result corresponding to the traffic anomaly monitoring model is the anomaly probability (that is, the first anomaly information). The larger the probability value corresponding to the first anomaly information, the higher the probability that the microservice has an anomaly in the target historical time period. The input of the traffic anomaly monitoring model can be the traffic change data of the time period content. The traffic anomaly monitoring model can be trained based on a conventional model training method.

[0088] As an example, first, data preprocessing is performed on each flow data in the flow data sequence to generate a preprocessed flow data sequence. Then, the preprocessed flow data sequence is input into the flow anomaly monitoring model to generate the above-mentioned first anomaly information.

[0089] Sub-step 3, based on the above-mentioned resource usage information sequence, using the resource anomaly monitoring model, generates the second anomaly information corresponding to the resource monitoring of the above-mentioned microservice. Among them, the resource anomaly monitoring model can be a neural network model that determines whether there is an anomaly in resource usage. In practice, the resource anomaly monitoring model can be a regression model based on a time series neural network model (for example, a recurrent neural network model, a long short-term memory neural network model). The larger the probability value corresponding to the second anomaly information, the higher the probability of the microservice being anomaly in the target historical time period. The input of the resource anomaly monitoring model can be the resource change data of the time period content. The resource anomaly monitoring model can be trained based on a conventional model training method.

[0090] Sub-step 4: Generate third abnormal information corresponding to the microservice in microservice call monitoring by using a clustering algorithm based on the microservice call data, wherein the clustering algorithm may be a k-means clustering algorithm.

[0091] As an example, the specific steps are as follows:

[0092] 1. Data collection: Collect indicator data of each microservice.

[0093] 2. Data preprocessing: cleaning, standardization, feature selection / dimensionality reduction.

[0094] 3. Clustering model selection and training: Select a suitable clustering algorithm and train the model.

[0095] 4. Anomaly detection: Identify outliers based on clustering results.

[0096] 5. Real-time detection and feedback: Deploy the model into real-time data streams, continuously monitor and provide feedback on the results.

[0097] 6. Model update: Regularly retrain the model with new data to adapt to environmental changes.

[0098] Sub-step 5, based on the above-mentioned processing log, using the log anomaly detection model, generates the fourth anomaly information corresponding to the above-mentioned microservice in log monitoring. Among them, the log anomaly detection model can be a neural network model that detects whether there is an abnormality in the log content. In practice, the fourth anomaly information can be a value between 0 and 1. In practice, the log anomaly detection model can be a Transformer model.

[0099] As an example, first, the execution subject may perform word embedding processing on the processing log to obtain a word embedding set, and then input the word embedding set into the log anomaly detection model to generate the fourth anomaly information.

[0100] The second step is to generate service fault information corresponding to the microservice according to the first exception information, the second exception information, the third exception information and the fourth exception information.

[0101] As an example, first, the execution subject may select the abnormal information whose corresponding probability is higher than the target probability value from the first abnormal information, the second abnormal information, the third abnormal information, and the fourth abnormal information to obtain an abnormal information set. Then, the abnormal problem set corresponding to the abnormal information set is summarized to obtain service fault information.

[0102] Optionally, the execution subject may generate first abnormal information representing the microservice corresponding to traffic monitoring according to the traffic data sequence and using a traffic abnormality monitoring model, including the following steps:

[0103] The first step is to determine the number of traffic feature extraction layers included in the above-mentioned traffic anomaly monitoring model. Among them, the traffic feature extraction layer can be a network layer that extracts traffic feature information. In practice, each traffic feature extraction layer can be arranged in parallel. The traffic feature extraction layer can be a recurrent neural network model.

[0104] The second step is to evenly divide the above traffic data sequence according to the above number to obtain a set of traffic data subsequences.

[0105] Step 3: For each traffic data subsequence in the above traffic data subsequence set, perform the following generation steps:

[0106] Sub-step 1: Input the traffic data subsequence into the corresponding traffic feature extraction layer in each of the traffic feature extraction layers to generate traffic feature information, wherein the traffic feature information may be feature information in vector form.

[0107] Sub-step 2, inputting the time tag corresponding to the above-mentioned traffic data subsequence into the time feature extraction layer included in the traffic anomaly monitoring model to generate time feature information. The time tag can represent the data generation time corresponding to the above-mentioned traffic data subsequence. The time feature extraction layer can be a network layer for extracting time feature information. For example, the time feature extraction layer can be a convolution layer with multiple layers connected in series. The time feature information can be feature information in vector form.

[0108] Sub-step 3, generating flow data description information for the above-mentioned flow data subsequence. The above-mentioned flow data description information can be input by a description information input platform. The description information input platform supports intelligent generation of flow data description information corresponding to the flow data subsequence, and can also be obtained by manual input by relevant technical personnel. Here, the flow data description information corresponding to the flow data subsequence can be generated based on the question-answering model.

[0109] Sub-step 4, inputting the above-mentioned traffic data description information into the description feature information generation layer included in the traffic anomaly monitoring model to generate description feature information. The description feature information can be a feature semantic content in the vector form that characterizes the traffic data description information. For example, the description feature information generation layer can be a TextCNN network layer.

[0110] Sub-step 5: splicing the above-mentioned traffic characteristic information, time characteristic information and description characteristic information to generate spliced ​​characteristic information.

[0111] In the fourth step, the obtained splicing feature information set is input into the multi-head attention mechanism layer (Multi-Head Attention Layer) included in the traffic anomaly monitoring model to generate a splicing feature weight information set. Among them, the splicing feature weight information can be a value between 0 and 1. The splicing feature weight information can represent the importance of the splicing feature information. Each splicing feature information has corresponding splicing feature weight information.

[0112] In the fifth step, weighted summation is performed on the splicing feature weight information in the splicing feature weight information set and the splicing feature information in the above splicing feature information set to generate weighted feature information.

[0113] In the sixth step, the weighted feature information is input into the abnormal information generation layer included in the traffic abnormality monitoring model to generate the first abnormal information. The abnormal information generation layer can be a network layer for generating abnormal information. In practice, the first abnormal information can be a multi-layer series of convolutional layers + fully connected layers.

[0114] The above-mentioned "first step to sixth step" as one of the inventive points of the present disclosure solves another technical problem "how to accurately generate the first abnormal information based on the above-mentioned traffic data sequence". Based on this, the present disclosure utilizes the traffic feature extraction layer, time feature extraction layer, description feature information generation layer and abnormal information generation layer connected in parallel, including the traffic anomaly monitoring model, and considers various aspects of feature information corresponding to the traffic data, so as to accurately generate the first abnormal information.

[0115] The above-mentioned various embodiments of the present disclosure have the following beneficial effects: through the microservice processing method of some embodiments of the present disclosure, the registration of microservices can be accurately and efficiently realized. On the basis of registration, efficient processing of each service of the microservice is realized to ensure the normal execution of the microservice. Specifically, the reason for the inefficient processing of microservices is that the existing microservice architecture system has scattered service distribution, a general lack of unified management of services, a general lack of effective service automatic discovery and automatic registration mechanism, and the existing service automatic discovery and automatic registration methods and devices are not universal and do not support Restful type services, resulting in the inability to realize various efficient processing for microservices. Based on this, the microservice processing method of some embodiments of the present disclosure, first, in response to determining that at least one microservice is started, for each microservice in the above at least one microservice, the following first generation step is performed: the first step is to use the service metadata acquisition device injected into the microservice self-check program to obtain the metadata information corresponding to the above microservice during the execution of the above microservice self-check program. Here, by injecting a service metadata acquisition device into the microservice self-checking program, the metadata information corresponding to the microservice is accurately extracted during the self-checking process, which ensures the completeness of the metadata information corresponding to the microservice, and by injecting the service metadata acquisition device into the self-checking program, the omission of the metadata information corresponding to the microservice is avoided. In the second step, the metadata information is sent to the microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object. Here, the microservice description object conversion device can efficiently and accurately realize the data format unification of the metadata information, avoid the confusion of the information format, and cause the problem of deviation in the corresponding registration of the microservice. Then, the obtained at least one microservice description object is summarized to the service collection device, so that the above-mentioned service collection device can store the above-mentioned at least one microservice description object in the target memory in the form of a queue, so as to realize the collection and sorting processing of at least one microservice description object, so as to facilitate the subsequent automatic registration. Finally, in response to detecting the service processing request sent by the service processing device, the above-mentioned service registration device is instructed to traverse the service description object queue in the above-mentioned target memory to call the registration interface of the above-mentioned service processing device and register the above-mentioned service description object queue to the above-mentioned service processing device. The service processing device supports the persistent storage of the service description object queue and at least one service processing, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing. Here, by calling the registration interface of the service processing device through the service registration device, each microservice can be automatically and accurately registered in the service processing device, so that the subsequent service processing device can realize dynamic expansion and contraction processing, load balancing processing, service fault detection, service version processing, etc. according to each registered microservice, so as to ensure the normal execution and management and maintenance of at least one microservice.In summary, by injecting the service metadata acquisition device, service collection device, service registration device and service processing device into the microservice self-check program, efficient registration and processing of microservices can be achieved, ensuring the normal operation and abnormal monitoring of at least one microservice.

[0116] Further references Figure 2 As an implementation of the methods shown in the above figures, the present disclosure provides some embodiments of a microservice processing device. These device embodiments are similar to Figure 1 Corresponding to the method embodiments shown, the microservice processing device can be specifically applied to various electronic devices.

[0117] like Figure 2 As shown, a microservice processing device 200 includes: an execution unit 201, a summary unit 202 and an indication unit 203. The execution unit 201 is configured to, in response to determining that at least one microservice is started, execute the following first generation step for each microservice in the at least one microservice: using the service metadata acquisition device injected into the microservice self-checking program, obtain metadata information corresponding to the microservice in the process of executing the microservice self-checking program; sending the metadata information to the microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object; the aggregation unit 202 is configured to aggregate the obtained at least one microservice description object to the service collection device, so that the service collection device stores the at least one microservice description object in the target memory in the form of a queue; the indication unit 203 is configured to, in response to detecting the service processing request sent by the service processing device, indicate the service registration device to traverse the service description object queue in the target memory to call the registration interface of the service processing device and register the service description object queue to the service processing device, wherein the service processing device supports persistent storage of the service description object queue and at least one service processing, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing.

[0118] It is understandable that the units recorded in the microservice processing device 200 are similar to those in the reference Figure 1 Therefore, the operations, features and beneficial effects described above for the method are also applicable to the microservice processing device 200 and the units contained therein, and will not be described in detail here.

[0119] Reference below Figure 3 , which shows a structural schematic diagram of an electronic device (eg, an electronic device) 300 suitable for implementing some embodiments of the present disclosure. Figure 3The electronic device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present disclosure.

[0120] like Figure 3 As shown, the electronic device 300 may include a processing device (e.g., a central processing unit, a graphics processing unit, etc.) 301, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 302 or a program loaded from a storage device 308 to a random access memory (RAM) 303. In the RAM 303, various programs and data required for the operation of the electronic device 300 are also stored. The processing device 301, the ROM 302, and the RAM 303 are connected to each other via a bus 304. An input / output (I / O) interface 305 is also connected to the bus 304.

[0121] Typically, the following devices may be connected to the I / O interface 305: an input device 306 including, for example, a touch screen, a touch pad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 307 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 308 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 309. The communication device 309 may allow the electronic device 300 to communicate with other devices wirelessly or by wire to exchange data. Figure 3 The electronic device 300 is shown with various devices, but it should be understood that it is not required to implement or possess all the devices shown. More or fewer devices may be implemented or possessed instead. Figure 3 Each block shown in the figure may represent one device, or may represent multiple devices as required.

[0122] In particular, according to some embodiments of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, some embodiments of the present disclosure include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In some such embodiments, the computer program can be downloaded and installed from the network through the communication device 309, or installed from the storage device 308, or installed from the ROM 302. When the computer program is executed by the processing device 301, the above-mentioned functions defined in the method of some embodiments of the present disclosure are executed.

[0123] It should be noted that the computer-readable medium in some embodiments of the present disclosure may be a computer-readable signal medium or a computer-readable storage medium or any combination of the two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In some embodiments of the present disclosure, the computer-readable storage medium may be any tangible medium containing or storing a program, which may be used by or in combination with an instruction execution system, device or device. In some embodiments of the present disclosure, the computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, in which a computer-readable program code is carried. Such propagated data signals may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer readable signal media may also be any computer readable medium other than computer readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer readable medium may be transmitted using any appropriate medium, including but not limited to: wires, optical cables, RF (radio frequency), etc., or any suitable combination of the above.

[0124] In some embodiments, the client and the server may communicate using any currently known or future developed network protocol such as HTTP (HyperText Transfer Protocol), and may be interconnected with any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network ("LAN"), a wide area network ("WAN"), an internet (e.g., the Internet), and a peer-to-peer network (e.g., an ad hoc peer-to-peer network), as well as any currently known or future developed network.

[0125] The computer-readable medium may be included in the electronic device, or may exist independently without being incorporated into the electronic device. The computer-readable medium carries one or more programs. When the one or more programs are executed by the electronic device, the electronic device: in response to determining that at least one microservice is started, for each of the at least one microservice, performs the following first generation step: using a service metadata acquisition device injected into a microservice self-checking program, obtaining metadata information corresponding to the microservice during the execution of the microservice self-checking program; sending the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object; aggregating the obtained at least one microservice description object to a service collection device, so that the service collection device stores the at least one microservice description object in a target memory in the form of a queue; in response to detecting a service processing request sent by a service processing device, instructing the service registration device to traverse the service description object queue in the target memory to call the registration interface of the service processing device, and register the service description object queue to the service processing device, wherein the service processing device supports persistent storage of the service description object queue and at least one service processing, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing.

[0126] Computer program code for performing the operations of some embodiments of the present disclosure may be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, C++, and conventional procedural programming languages ​​such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0127] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present disclosure. In this regard, each square box in the flow chart or block diagram can represent a module, a program segment or a part of a code, and the module, the program segment or a part of the code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some implementations as replacements, the functions marked in the square box can also occur in a sequence different from that marked in the accompanying drawings. For example, two square boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0128] The units described in some embodiments of the present disclosure may be implemented by software or by hardware. The described units may also be provided in a processor, for example, may be described as: a processor comprising an execution unit, a summary unit, and an indication unit. Among them, the names of these units do not constitute a limitation on the unit itself in certain cases, for example, the summary unit may also be described as "a unit that summarizes the obtained at least one microservice description object to a service collection device, so that the above-mentioned service collection device can store the above-mentioned at least one microservice description object in the target memory in the form of a queue".

[0129] The functions described above herein may be performed at least in part by one or more hardware logic components. For example, without limitation, exemplary types of hardware logic components that may be used include: field programmable gate arrays (FPGAs), application specific integrated circuits (ASICs), application specific standard products (ASSPs), systems on chips (SOCs), complex programmable logic devices (CPLDs), and the like.

[0130] The above descriptions are only some preferred embodiments of the present disclosure and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the embodiments of the present disclosure is not limited to the technical solutions formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above inventive concept. For example, the above features are replaced with (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure.

Claims

1. A microservice processing method, comprising: In response to determining that at least one microservice is started, for each microservice in the at least one microservice, the following first generation step is performed: Using the service metadata acquisition device injected into the microservice self-checking program, metadata information corresponding to the microservice is acquired during the execution of the microservice self-checking program; The metadata information is sent to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object, wherein: The sending of the metadata information to the microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object includes: obtaining a description field set and a description field format set corresponding to the microservice description object; for each description field in the description field set, executing the following fourth generation step: determining the description field format corresponding to the description field as the target description field format; generating a conversion instance set for the target description field format, wherein each conversion instance corresponds to metadata of a different format, and the conversion result corresponding to the conversion instance is the field content under the target description field; filtering out the conversion instance that matches the metadata information from the conversion instance set as the target conversion instance; determining the model conversion parameters corresponding to the target conversion instance as the target conversion instance. is a target model conversion parameter; determines a description field content generation model corresponding to the target model conversion parameter; inputs the metadata information, the target description field format and the target conversion instance into the description field content generation model to generate a first description field content corresponding to the metadata information under the description field, wherein the field format corresponding to the first description field content is the target description field format; obtains pre-stored regular expression conversion information corresponding to the target conversion instance; generates a second description field content in the metadata information under the description field according to the regular expression conversion information; generates a conversion description field content according to the first description field content and the second description field content; generates a microservice description object according to the obtained conversion description field content set; Aggregating the obtained at least one microservice description object to a service collection device, so that the service collection device can store the at least one microservice description object in a target memory in a queue form; In response to detecting a service processing request sent by a service processing device, the service registration device is instructed to traverse the service description object queue in the target memory to call the registration interface of the service processing device to register the service description object queue to the service processing device, wherein the service processing device supports persistent storage of the service description object queue and at least one service processing, and the at least one service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing.

2. The method according to claim 1, wherein: The metadata information includes: at least one parameter information; and The step of sending the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object includes: For the parameter information in the at least one parameter information, the following second generating step is performed: Determine whether the parameter information is array type information; In response to determining that the parameter information is not of the array type, determining whether the parameter information is of a preset predetermined parameter type; In response to determining that the parameter is not of the predetermined parameter type, performing data parsing on the parameter information to obtain parsed parameter information as parameter extraction information; Extract information according to at least one obtained parameter and generate a microservice description object.

3. The method according to claim 1, wherein: The service processing device is a network interface processing layer; as well as The registering the service description object queue to the service processing device comprises: In response to determining that the service description object queue is not an empty queue, for the service description objects in the service description object queue, performing the following registration steps: Determine whether there is a processing object corresponding to the service description object in the object processing list corresponding to the network interface processing layer; In response to determining that it exists, replacing the corresponding processing object in the object processing list with the service description object; In response to determining that it does not exist, adding the service description object to the object handling list; In response to determining that the target service description object queue after the service description object is removed is an empty queue, determining the updated object processing list as the microservice registration result corresponding to the network interface processing layer; In response to determining that the target service description object queue is not an empty queue, the target service description object queue is used as the service description object queue, the updated object processing list is used as the object processing list, and the registration step is continued.

4. The method according to claim 1, wherein: There is a corresponding current service processing summary table and a historical service processing summary table for the service processing in the at least one service processing; as well as The current service process summary table corresponding to the target service process is generated by the following steps: Determine a processing field set corresponding to the target service processing; For each microservice in the at least one microservice, the following third generation step is performed: Determine the service description object stored corresponding to the microservice as the target service description object; For each processing field in the processing field set, filtering out field content corresponding to the processing field from the target service description object; The obtained at least one field content set is added to the initial service processing summary table to obtain the current service processing summary table.

5. The method according to claim 1, wherein: The service failure corresponding to the at least one microservice is detected by the following steps: For each microservice in the at least one microservice, the following detection steps are performed: Determine the traffic data sequence, resource usage information sequence, microservice call data and processing log of the microservice content in the target historical time period; According to the traffic data sequence, using a traffic anomaly monitoring model, generating first anomaly information corresponding to the traffic monitoring of the microservice; According to the resource usage information sequence, using a resource anomaly monitoring model, generating second anomaly information corresponding to resource monitoring of the microservice; Generate third abnormal information corresponding to the microservice in microservice call monitoring by using a clustering algorithm according to the microservice call data; Generate fourth abnormal information representing the microservice corresponding to log monitoring by using a log abnormality detection model according to the processing log; Service fault information corresponding to the microservice is generated according to the first exception information, the second exception information, the third exception information, and the fourth exception information.

6. The method according to claim 1, wherein: The step of generating the conversion description field content according to the first description field content and the second description field content includes: In response to determining that the first description field content and the second description field content are consistent, determining the first description field content as the conversion description field content; In response to determining the inconsistency, filtering out a field information set corresponding to the description field from the metadata information; The field information set, the target description field format, the target conversion instance, the first description field content, and the second description field content are displayed on a target conversion page so that relevant technical personnel can manually confirm the description field content; Determining the confirmed confirmation description field content as the conversion description field content; and The method further comprises: In response to determining that the confirmation description field content is the first description field content, adjusting and testing the regular expression conversion information according to the confirmation description field content set within the target time period to generate updated regular expression conversion information as the regular expression conversion information; In response to determining that the confirmed description field content is the second description field content, the description field content generation model is adjusted according to the confirmed description field content set within the target time period to generate an updated description field content generation model as the description field content generation model.

7. A microservice processing device, comprising: The execution unit is configured to, in response to determining that at least one microservice is started, perform the following first generation step for each microservice in the at least one microservice: using a service metadata acquisition device injected into a microservice self-checking program to acquire metadata information corresponding to the microservice during the execution of the microservice self-checking program; The metadata information is sent to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object. The sending of the metadata information to a microservice description object conversion device to perform data conversion processing on the metadata information to generate a microservice description object includes: obtaining a description field set and a description field format set corresponding to the microservice description object; for each description field in the description field set, executing the following fourth generation step: determining the description field format corresponding to the description field as the target description field format; generating a conversion instance set for the target description field format, wherein each conversion instance corresponds to metadata of a different format, and the conversion result corresponding to the conversion instance is the field content under the target description field; filtering out conversion instances that match the metadata information from the conversion instance set as the target description field. The method comprises the steps of: generating a description field content generation model corresponding to the target model conversion parameter; inputting the metadata information, the target description field format and the target conversion instance into the description field content generation model to generate a first description field content corresponding to the metadata information under the description field, wherein the field format corresponding to the first description field content is the target description field format; obtaining the pre-stored regular expression conversion information corresponding to the target conversion instance; generating a second description field content in the metadata information under the description field according to the regular expression conversion information; generating a conversion description field content according to the first description field content and the second description field content; generating a microservice description object according to the obtained conversion description field content set; a summarizing unit configured to summarize the obtained at least one microservice description object to the service collection device, so that the service collection device stores the at least one microservice description object in a target memory in the form of a queue; An indication unit is configured to, in response to detecting a service processing request sent by a service processing device, instruct a service registration device to traverse the service description object queue in the target memory to call the registration interface of the service processing device and register the service description object queue to the service processing device, wherein the service processing device supports persistent storage and service processing of the service description object queue, and the service processing includes at least one of the following: dynamic expansion and contraction processing, load balancing processing, service fault detection, and service version processing.

8. An electronic device, comprising: one or more processors; a storage device having one or more programs stored thereon, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

9. A computer readable medium having a computer program stored thereon, wherein: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Images