Microservice code management method and device, electronic equipment and storage medium

Abstract

The invention discloses a micro-service code management method and device, electronic equipment and a storage medium, relates to the technical field of Internet, is applied to a micro-service code management system.The method comprises the steps that an interface definition language document on which each micro-service needed by a to-be-created project depends is obtained; determining a target micro-service with the same interface definition language document in all micro-services; union set taking operation is carried out on the interface definition language document on which the target micro-service depends, and a target interface definition language document is obtained; based on the target interface definition language document, generating a micro-service code corresponding to the target micro-service; the micro-service code corresponding to the target micro-service is stored in the single code warehouse, so that the code volume in the micro-service code generation process is reduced, generation of invalid or useless codes and dependence on downstream unnecessary interface codes are avoided, and the problems of long compilation time, jump jamming and the like caused by excessive code volume are solved.

Description

Technical Field

[0001] The present disclosure relates to the field of Internet technology, and in particular to a microservice code management method, device, electronic device, storage medium, and program product. Background Art

[0002] Projects under the microservices architecture integrate multiple types of microservices, such as advertising creation projects, which may include inventory microservices, planning microservices, and material microservices. In related technologies, the microservice code corresponding to each type of microservice is stored in its own code repository. When multiple microservices rely on the same IDL (Interface Definition Language), the code generated based on the same IDL file will exist in each microservice code repository, resulting in high coupling and code duplication between microservices, affecting the project's compilation efficiency. Summary of the Invention

[0003] In view of this, the present disclosure provides a microservice code management method, device, electronic device and storage medium to solve the problem of high coupling between existing microservices and high code duplication, which affects the compilation efficiency of the project.

[0004] In a first aspect, the present disclosure provides a microservice code management method, which is applied to a microservice code management system configured with a single code repository; the method includes: obtaining an interface definition language document that each microservice required for a project to be created depends on; determining a target microservice with the same interface definition language document among all the microservices; performing a union operation on the interface definition language documents that the target microservice depends on to obtain a target interface definition language document; generating a microservice code corresponding to the target microservice based on the target interface definition language document; and storing the microservice code corresponding to the target microservice in the single code repository.

[0005] In a second aspect, the present disclosure provides a microservice code management device, which is applied to a microservice code management system, and the microservice code management system is configured with a single code repository; the device includes: a first acquisition module, which is used to obtain the interface definition language document that each microservice required for a project to be created depends on; a first determination module, which is used to determine a target microservice with the same interface definition language document among all the microservices; a first merging module, which is used to perform a union operation on the interface definition language documents that the target microservice depends on to obtain a target interface definition language document; a first generation module, which is used to generate a microservice code corresponding to the target microservice based on the target interface definition language document; and a storage module, which is used to store the microservice code corresponding to the target microservice in the single code repository.

[0006] In a third aspect, the present disclosure provides an electronic device comprising: a memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, and the processor executing the microservice code management method of the first aspect or any corresponding embodiment thereof by executing the computer instructions.

[0007] In a fourth aspect, the present disclosure provides a computer-readable storage medium having computer instructions stored thereon, the computer instructions being used to enable a computer to execute the microservice code management method of the first aspect or any corresponding embodiment thereof.

[0008] In a fifth aspect, the present disclosure provides a computer program product, including computer instructions, which are used to enable a computer to execute the microservice code management method of the above-mentioned first aspect or any corresponding embodiment thereof.

[0009] The microservice code management method provided by the embodiment of the present disclosure is applied to a microservice code management system configured with a single code repository. By obtaining the interface definition language document that each microservice required for the project to be created depends on, determining a target microservice with the same interface definition language document among all microservices, performing a union operation on the interface definition language documents that the target microservice depends on to obtain the target interface definition language document, generating microservice code corresponding to the target microservice based on the target interface definition language document, and storing the microservice code corresponding to the target microservice in a single code repository. By determining a target microservice with the same interface definition language document among multiple microservices required for the project to be created, performing a union operation on the interface definition language documents that the target microservice depends on so that only one identical interface definition language document is retained, and performing a microservice code generation operation based on the obtained target interface definition language document, the generated microservice code corresponding to the target microservice is generated based on different interface definition language documents, without duplicate code, and storing the generated microservice code in the same single code repository, the code generated based on different interface definition language documents can be directly obtained from the single code repository during the project compilation operation, thereby improving the project compilation efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order to more clearly illustrate the specific embodiments of the present disclosure or the technical solutions in the related technologies, the following briefly introduces the drawings required for use in the specific embodiments or related technical descriptions. Obviously, the drawings described below are some embodiments of the present disclosure. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0011] Figure 11 is a flow chart of a microservice code management method according to an embodiment of the present disclosure;

[0012] Figure 2 is a schematic diagram of a microservice code management method according to an embodiment of the present disclosure;

[0013] Figure 3 is a structural block diagram of a microservice code management device according to an embodiment of the present disclosure;

[0014] Figure 4 Schematic diagram of the hardware structure of an electronic device according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0015] To make the purpose, technical solutions, and advantages of the embodiments of the present disclosure more clear, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are part of the embodiments of the present disclosure, not all of the embodiments. Based on the embodiments of the present disclosure, all other embodiments obtained by those skilled in the art without making creative efforts shall fall within the scope of protection of the present disclosure.

[0016] It is understandable that before using the technical solutions disclosed in the various embodiments of this disclosure, the type, scope of use, usage scenarios, etc. of the personal information involved in this disclosure should be informed to the user and the user's authorization should be obtained in an appropriate manner in accordance with relevant laws and regulations.

[0017] For example, in response to a user's active request, a prompt message is sent to the user to clearly inform the user that the operation requested will require the acquisition and use of the user's personal information. This allows the user to independently choose whether to provide personal information to the electronic device, application, server, storage medium, or other software or hardware that performs the operations of the disclosed technical solution based on the prompt message.

[0018] As an optional but non-limiting implementation, in response to receiving a user's active request, the prompt information may be sent to the user in the form of a pop-up window, in which the prompt information may be presented in text form. Furthermore, the pop-up window may also contain a selection control for the user to select "agree" or "disagree" to provide personal information to the electronic device.

[0019] It is understandable that the above notification and user authorization process are merely illustrative and do not limit the implementation of the present disclosure. Other methods that comply with relevant laws and regulations may also be applied to the implementation of the present disclosure.

[0020] It is understandable that the data involved in this technical solution (including but not limited to the data itself, the acquisition or use of the data) must comply with the requirements of relevant laws, regulations and relevant provisions.

[0021] Projects under the microservice architecture integrate multiple types of microservices, such as advertising creation projects, which can include inventory microservices, planning microservices, material microservices, etc. In the related art, the microservice codes corresponding to each type of microservice are stored in their respective code repositories. When multiple microservices rely on the same IDL (Interface Definition Language), the code generated based on the same IDL file will exist in each microservice code repository, resulting in excessive coupling and code duplication between microservices, affecting the compilation efficiency of the project. For example, if microservice A and microservice B both rely on the IDL of microservice C, it is necessary to integrate the full code of microservice C with a dependency relationship into the code repositories of microservices A and microservice B; or if microservices A and microservice B both rely on the same IDL of public service F, the full code of public service F is integrated into the code repositories of microservices A and microservice B, resulting in excessive coupling and code duplication between microservices, affecting the compilation efficiency of the project.

[0022] According to an embodiment of the present disclosure, an embodiment of a microservice code management method is provided. It should be noted that the steps shown in the flowcharts of the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowcharts, in some cases, the steps shown or described can be executed in an order different from that shown here.

[0023] In this embodiment, a microservice code management method is provided, which is applied to a microservice code management system. The microservice code management system is configured with a single code repository. The single code repository is used to store the code of each microservice required for project creation, including the code of each microservice's own part and the code of all microservices' common parts. Figure 1 is a flowchart of a microservice code management method according to an embodiment of the present disclosure. Figure 1 As shown, the process includes the following steps:

[0024] Step S101: Obtain the interface definition language document of each microservice dependency required by the project to be created.

[0025] For example, when creating a project, technicians can pre-define the corresponding IDL for each microservice based on project requirements and declare dependencies in psm-version.yml. Automated parsing tools can be used to parse the IDL definition results to obtain the IDL that each microservice depends on. Assume that the microservices corresponding to the project to be created include: Microservice A, Microservice B, Microservice C, and Microservice D. The IDLs that microservice A depends on obtained through parsing include: IDL1, IDL2, IDL3; the IDLs that microservice B depends on include: IDL1, IDL2, IDL3; the IDLs that microservice C depends on include: IDL4, IDL5, IDL6; and the IDLs that microservice C depends on include: IDL6, IDL7, IDL8.

[0026] Step S102: determining a target microservice having the same interface definition language document among all microservices.

[0027] Exemplarily, the method for determining the target microservice with the same interface definition language document among all microservices can be to perform a polling comparison search based on the parsing results in the IDL corresponding to all microservices to determine the target microservice. The embodiment of the present application does not limit the method for determining the target microservice; the number of corresponding microservices among the determined target microservices with the same IDL is not limited and can be 2 or more. Taking the example in the above step as an example, the target microservices with the same interface definition language document among all microservices are: target microservice 1 composed of microservice A and microservice B with the same IDL1, IDL2, and IDL3, and target microservice 2 composed of microservice C and microservice D with the same IDL6.

[0028] Step S103 performs a union operation on the interface definition language documents that the target microservice depends on to obtain the target interface definition language document. For example, taking the example in the previous step as an example, for target microservice 1, which is composed of microservices A and B with the same IDL1, IDL2, and IDL3, the target interface definition language documents corresponding to target microservice 1 are obtained by taking a union operation, namely, IDL1, IDL2, and IDL3; for target microservice 2, which is composed of microservices C and D with the same IDL6, the target interface definition language documents corresponding to target microservice 2 are obtained by taking a union operation, namely, IDL4, IDL5, IDL6, IDL7, and IDL8.

[0029] Step S104, based on the target interface definition language document, generates the microservice code corresponding to the target microservice. Exemplarily, a code generation tool based on IDL drive can be used to perform microservice code generation operations. The embodiment of the present application does not limit the specific type of the code generation tool, and those skilled in the art can choose according to actual needs. Taking the example in the above step as an example, the microservice code corresponding to the target microservice 1 is generated based on IDL1, IDL2, and IDL3, and the microservice code corresponding to the target microservice 2 is generated based on IDL4, IDL5, IDL6, IDL7, and IDL8, so that the generated microservice codes are all codes generated based on different IDLs, avoiding repeated configuration of the same IDL in different microservices.

[0030] Step S105, the microservice code corresponding to the target microservice is stored in a single code repository. Exemplarily, the generated microservice code corresponding to the target microservice can be stored in a single code repository. Specifically, the microservice code corresponding to different target microservices can be stored in different sub-areas in the single code repository, so that the microservice codes corresponding to different microservices are isolated in the same code repository or isolated according to the namespace. When it is necessary to compile the corresponding microservice, the microservice code can be directly obtained from the single code repository, such as obtaining the public general service program code required for compilation or obtaining the microservice code for self-use of other dependent microservices, without the need for remote calls, thereby improving the project compilation efficiency.

[0031] The microservice code management method provided in this embodiment determines a target microservice with the same interface definition language document from multiple microservices required for a project to be created, performs a union operation on the interface definition language document on which the target microservice depends, so that only one identical interface definition language document is retained, and performs a microservice code generation operation based on the obtained target interface definition language document, so that the generated microservice codes corresponding to the target microservices are all generated based on different interface definition language documents, and there is no duplicate code. The generated microservice codes are stored in the same single code repository, so that during the project compilation operation, the codes generated based on different interface definition language documents can be directly obtained from the single code repository, thereby improving the project compilation efficiency.

[0032] In some optional implementations, the method further includes: if there are multiple groups of target microservices, isolating and storing microservice codes corresponding to different groups of target microservices in a single code repository based on the namespace.

[0033] For example, using the example in the previous embodiment as an example, for the microservice code corresponding to target microservice 1 and the microservice code corresponding to target microservice 2 generated based on different IDLs, a code organization strategy based on a virtual directory structure of namespaces isolates and stores the microservice code corresponding to different groups of target microservices (such as target microservice 1 and target microservice 2) in the same code repository, so that the namespaces corresponding to different groups of target microservices are different. This logical grouping method based on namespaces can resolve naming conflicts and dependency management issues for multiple groups of microservice codes in the same code repository.

[0034] In some optional implementations, the method further includes: if the multiple microservices required for the project to be created include other microservices in addition to the target microservice, determining the microservice codes corresponding to the other microservices; in a single code repository, isolating and storing the microservice codes corresponding to the other microservices and the microservice codes corresponding to the target microservice according to the namespace.

[0035] For example, using the example in the previous embodiment, if the microservices corresponding to the project to be created also include microservice E, and the IDL that microservice E depends on is parsed and includes IDL9, it can be seen that microservice E does not have the same IDL as other microservices in the project to be created. Therefore, the microservice code corresponding to microservice E is generated based on IDL9. The microservice code corresponding to microservice E is also stored in the same single code repository, isolated from the microservice code corresponding to target microservice 1 and target microservice 2, similarly according to the namespace.

[0036] In some optional implementations, the microservice code management system is further configured with an interface definition language document repository, which is used to store the interface definition language documents required for project creation. Specifically, the interface definition language document repository can store IDL documents required for project creation in different formats, such as Thrift-type IDL documents, Protobuf-type IDL documents, etc. Alternatively, the interface definition language document repository can store IDL documents required for microservice compilation corresponding to multiple projects, resulting in the interface definition language documents containing multiple types of IDL. The method also includes: obtaining the type of interface definition language document contained in the interface definition language document repository; and tailoring the interface definition language documents contained in the interface definition language document repository based on the type of interface definition language document that each microservice required for the project to be created depends on.

[0037] For example, in the case of type selection that includes both Thrift type IDL documents and Protobuf type IDL documents, you can directly select the IDL of either Thrift type IDL document or rotobuf type IDL document as the IDL type required for the microservice under the project to be created according to the requirements of the project to be created, and perform a trimming operation on the IDL corresponding to the unnecessary type in the interface definition language document repository, so that the IDL of the unnecessary type is deleted from the interface definition language document repository. In the case where the IDL required for microservice compilation corresponding to multiple projects is stored in the interface definition language document repository, the type of the interface definition language document contained in the interface definition language document repository can be obtained by parsing the IDL contained in the interface definition language document repository. For example, for Thrift type IDL documents, the required IDL document under the Thrift type can be selected according to the namespace field information or field number; for Protobuf type IDL documents, the required IDL document under the Protobuf type can be selected according to the syntax field information, etc.; for IDL corresponding to unnecessary Thrift types or Protobuf types, they are trimmed in the interface definition language document repository to reduce the dependence on downstream non-essential interface code in the current microservice compilation process.

[0038] In some optional implementations, the method further includes: before performing the microservice code generation operation, the method further includes: tailoring the structure contained in the interface definition language document that the target microservice depends on according to the requirements of the microservice for structure parameters required by the project to be created.

[0039] For example, the structure parameters contained in the structure field in the IDL can be adaptively configured according to the compilation requirements of the corresponding microservice, and unnecessary structure parameters can be trimmed. For example, structure parameters include required field parameters, optional field parameters, field parameters with default values, Boolean type parameters, floating-point type parameters, etc. Unnecessary field parameters can be trimmed as needed to reduce the amount of code generated.

[0040] In some optional implementations, the method further includes: receiving a selection of a microservice code generation template; and executing, based on the selected microservice code generation template, a step of generating microservice code based on a dependent target interface definition language document.

[0041] For example, different microservice code generation templates in the embodiments of the present application can be used to generate different amounts of code, such as templates for generating the full amount required for compilation and release, or templates for generating only part of the code, such as templates that do not contain code related to codecs. In the embodiments of the present application, for the use of different types of templates, the selection of corresponding types of templates can be enabled when the use conditions of the corresponding types of templates are met. For example, for templates that do not contain code related to codecs, the corresponding use conditions may be that the frugal codec must be enabled, and the framed or TTTHeaderFramed communication protocol corresponding to the frugal codec must be supported. Based on the selected microservice code generation template, the steps of generating microservice code based on the dependent target interface definition language document are executed.

[0042] In some optional embodiments, the microservice code generation template includes a first microservice code sub-template and a second microservice code sub-template, wherein the amount of code generated based on the first microservice code sub-template is greater than the amount of code generated based on the second microservice code sub-template, and the method further includes: when generating microservice code according to the dependent target interface definition language document, generating microservice code corresponding to the corresponding target microservice according to the second microservice code sub-template; when submitting a version of the generated microservice code, supplementing the generated microservice code according to the first microservice code sub-template.

[0043] For example, when relying on IDL to generate the corresponding microservice code, a second microservice code sub-template with a smaller generated code volume is selected to generate the microservice code corresponding to the target microservice. When the generated microservice code is submitted for version, the generated microservice code is supplemented and generated according to the first microservice code sub-template to meet the version submission and release requirements. If a microservice code that does not contain codec code is obtained when code is generated based on the second microservice code sub-template, the full template of the first microservice code sub-template is used when the version is submitted to generate the missing codec code, thereby meeting the requirements of different nodes for the generated code while minimizing the volume of code generated at each stage to improve the efficiency of compilation and release.

[0044] In some optional implementations, step S103 includes:

[0045] Step a1, determine whether the versions of the same interface definition language document that the target microservice depends on are the same; illustratively, taking the example in the above embodiment as an example, for microservice C and microservice D corresponding to target microservice 2, both depend on IDL6, determine whether the versions of IDL6 that microservice C and microservice D depend on are the same.

[0046] Step a2: If the target microservice depends on different versions of the same interface definition language document, obtain the first interface definition language document and the second interface definition language document contained in the different versions of the same interface definition language document, wherein the first interface definition language document is the new version of the interface definition language document in the same interface definition language document, and the second interface definition language document is the historical version of the interface definition language document in the same interface definition language document; exemplarily, if the target microservice depends on different versions of the same interface definition language document, such as one is IDL6 under the new version, use the IDL6 under the new version as the first interface definition language document, and the other is IDL6 under the historical version, use the IDL6 under the historical version as the second interface definition language document.

[0047] In step a3, if the first interface definition language document only increases the number of fields included in the second interface definition language document, then when performing the union operation, the first interface definition language document is selected as the result of the union operation; illustratively, the first interface definition language document and the second interface definition language document of different versions are compared. If the first interface definition language document only increases the number of fields included in the second interface definition language document, for example, the first interface definition language document contains 4 structure fields, and the second interface definition language document only contains 3 of them, then when performing the union operation, the first interface definition language document is directly selected as the result of the union operation.

[0048] In step a4, if the first interface definition language document contains the same number of fields as the second interface definition language document but the corresponding field types are different, then when performing the union operation, the first interface definition language document is selected as the result of the union operation, and a conflict prompt operation is responded to when a conflict occurs in the corresponding microservice code generation process; exemplarily, if the first interface definition language document and the second interface definition language document both contain 4 structure fields but the corresponding specific field types are different, when performing the union operation, the first interface definition language document is selected as the result of the union operation, and a conflict prompt operation is responded to when a conflict occurs in the corresponding microservice code generation process, such as an error reminder appearing on the command line and outputting the specific differences and difference locations based on a tool for comparing file or directory content differences (such as diff), so that the user can intervene according to the conflict prompt.

[0049] In step a5, if the first interface definition language document contains fewer fields than the second interface definition language document, stop responding to the union operation and perform microservice code generation operations according to the interface definition language documents corresponding to each microservice in the target microservice, and store the generated microservice codes in isolation according to the namespace.

[0050] For example, if the first interface definition language document contains fewer fields than the second interface definition language document, indicating that the new version has updated the field type, then the response to the union operation is stopped and the microservice code generation operation is performed according to the interface definition language document corresponding to each microservice in the target microservice. The generated microservice code is stored in isolation according to the namespace, that is, microservice C and microservice D respectively perform microservice code generation operations according to their respective dependent IDL6 to avoid compatibility issues caused by version changes.

[0051] In some optional embodiments, the method also includes: if different interface definition language documents that the same microservice depends on contain the same namespace and there is a version conflict in the interface definition language documents corresponding to the same namespace, then the codes generated based on the different interface definition language documents containing the same namespace are isolated and stored in a single code repository according to the namespace.

[0052] For example, for example, the IDL1, IDL2, and IDL3 that microservice A depends on are thrift type IDLs. Assume that IDL1 is "oe_idl / const / constant.thrift", and its corresponding "namespace=constant"; IDL2 is "service_rpc_idl / const / constant.thrift", and its corresponding "namespace=constant". It can be seen that different IDLs under the same microservice A contain the same namespace (namespace), and the constant codes of the two IDLs will be in the same path; if there is a version conflict between the constant.thrift of oe_idl and service_rpc_idl, the codes generated by oe_idl and service_rpc_idl will be isolated and stored according to the namespace in a single code repository.

[0053] As a specific embodiment of this application, Figure 2As shown, taking the diagram in the above embodiment as an example, the microservice code_1 contained in a single code repository is the microservice code corresponding to the target microservice 1 generated based on IDL1, IDL2, and IDL3, the microservice code_2 is the microservice code corresponding to the target microservice 2 generated based on IDL4, IDL5, IDL6, IDL7, and IDL8, and the microservice code_3 is the microservice code corresponding to other microservices generated based on IDL9; PSM represents microservices, where PSM_1 corresponds to microservice A, PSM_2 corresponds to microservice B, PSM_3 corresponds to microservice C, PSM_4 corresponds to microservice D, and PSM_5 corresponds to microservice E; IDL_1 in the IDL repository is composed of IDL1, IDL2, and IDL3, and IDL_2 is composed of IDL9. L4, IDL5, IDL6, IDL7, and IDL8 are composed, and IDL_3 is composed of IDL9. Among them, microservice code_1, PSM_1, PSM_2, and IDL_1 correspond to namespace Namespace_1; microservice code_2, PSM_3, PSM_4, and IDL_2 correspond to namespace Namespace_2; microservice code_3, PSM_5, and IDL_3 correspond to namespace Namespace_3, and are isolated and stored according to different namespaces; rpc_gen is a remote procedure call (rpc) code generation tool. The project creates business requirements (Biz_A) by introducing rpc_gen to call the corresponding microservice code to meet the project compilation and release requirements.

[0054] The microservice code management method provided in the embodiment of the present application reduces the code volume of the microservice code generation process by taking the intersection and merging the same IDL, and through the IDL trimming operation, further reduces the generation of invalid or useless code and the dependence on downstream non-essential interface code, thereby solving problems such as long compilation time and IDE jump jamming caused by excessive code volume; at the same time, by storing the code generated with the same dependency in the same code repository, it solves the problems of duplicate generated code and difficult reuse of public structures.

[0055] In this embodiment, a microservice code management device is also provided, which is used to implement the above-mentioned embodiments and preferred implementation methods. The details that have been described will not be repeated here. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the devices described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

[0056] This embodiment provides a microservice code management device, which is applied to a microservice code management system. The microservice code management system is configured with a single code repository; Figure 3 Shown, including:

[0057] The first acquisition module 201 is used to obtain the interface definition language document of each microservice dependency required by the project to be created;

[0058] A first determining module 202 is configured to determine a target microservice having the same interface definition language document among all microservices;

[0059] The first merging module 203 is used to perform a union operation on the interface definition language documents that the target microservice depends on to obtain the target interface definition language document;

[0060] A first generating module 204 is configured to generate microservice code corresponding to a target microservice based on a target interface definition language document;

[0061] The storage module 205 is used to store the microservice code corresponding to the target microservice in a single code repository.

[0062] The microservice code management device provided by this embodiment determines a target microservice with the same interface definition language document from multiple microservices required for a project to be created, performs a union operation on the interface definition language document on which the target microservice depends, so that only one identical interface definition language document is retained, and performs a microservice code generation operation based on the obtained target interface definition language document, so that the generated microservice codes corresponding to the target microservices are all generated based on different interface definition language documents, without duplicate code, and the generated microservice codes are stored in the same single code repository, so that during the project compilation operation, the codes generated based on different interface definition language documents can be directly obtained from the single code repository, thereby improving the project compilation efficiency.

[0063] In some optional implementations, the apparatus further includes: a first isolation module configured to isolate and store microservice codes corresponding to target microservices of different groups in a single code repository based on namespaces if there are multiple groups of target microservices.

[0064] In some optional embodiments, the device also includes: a second determination module, which is used to determine the microservice codes corresponding to other microservices if the multiple microservices required for the project to be created include other microservices in addition to the target microservice; a second isolation module, which is used to isolate and store the microservice codes corresponding to other microservices and the microservice codes corresponding to the target microservice in a single code repository according to the namespace.

[0065] In some optional embodiments, the microservice code management system is further configured with an interface definition language document repository, which is used to store interface definition language documents required for project creation; the device also includes: a second acquisition module, which is used to obtain the type of interface definition language documents contained in the interface definition language document repository; and a first tailoring module, which is used to tailor the interface definition language documents contained in the interface definition language document repository according to the type of interface definition language documents that each microservice required for the project to be created depends on.

[0066] In some optional embodiments, the apparatus further includes: a second tailoring module for tailoring the structure contained in the interface definition language document that the target microservice depends on according to the requirements of the microservice for structure parameters required by the project to be created.

[0067] In some optional embodiments, the device further includes: a receiving module for receiving a selection of a microservice code generation template; and an execution module for executing the steps of generating microservice code according to a dependent target interface definition language document based on the selected microservice code generation template.

[0068] In some optional embodiments, the microservice code generation template includes a first microservice code sub-template and a second microservice code sub-template, wherein the amount of code generated based on the first microservice code sub-template is greater than the amount of code generated based on the second microservice code sub-template, and the device also includes: a second generation module for generating microservice code corresponding to the corresponding target microservice according to the second microservice code sub-template when generating microservice code according to the dependent target interface definition language document; and a third generation module for supplementing the generated microservice code according to the first microservice code sub-template when submitting a version of the generated microservice code.

[0069] In some optional implementations, the first merging module includes: a determining submodule for determining whether the versions of the same interface definition language document that the target microservice depends on are the same; an acquiring submodule for acquiring, if the versions of the same interface definition language document that the target microservice depends on are different, the first interface definition language document and the second interface definition language document contained in the different versions of the same interface definition language document, wherein the first interface definition language document is a new version of the interface definition language document in the same interface definition language document, and the second interface definition language document is a historical version of the interface definition language document in the same interface definition language document; the first merging submodule for performing a union operation if the first interface definition language document only increases the number of fields contained in the second interface definition language document compared to the second interface definition language document. When processing, the first interface definition language document is selected as the result of the union operation; the second merging sub-module is used to select the first interface definition language document as the result of the union operation if the first interface definition language document contains the same number of fields as the second interface definition language document but the corresponding field types are different, and respond to the conflict prompt operation when a conflict occurs in the corresponding microservice code generation process; the third merging sub-module is used to stop responding to the union operation if the first interface definition language document contains fewer fields than the second interface definition language document, and perform microservice code generation operations according to the interface definition language document corresponding to each microservice in the target microservice, and isolate and store the generated microservice code according to the namespace.

[0070] In some optional embodiments, the device also includes: adding a module for isolating and storing the codes generated based on different interface definition language documents containing the same namespace in a single code repository according to the namespace if different interface definition language documents that the same microservice depends on contain the same namespace and there is a version conflict in the interface definition language documents corresponding to the same namespace.

[0071] The microservice code management device provided in the embodiments of the present disclosure can execute the microservice code management method provided in any embodiment of the present disclosure, and has the functional modules and beneficial effects corresponding to the execution method. The further functional description of each of the above modules and units is the same as that of the corresponding embodiment above, and will not be repeated here.

[0072] Figure 4 A schematic structural diagram of an electronic device provided in an embodiment of the present disclosure.

[0073] The following specific reference Figure 4, which shows a schematic diagram of the structure of an electronic device suitable for implementing the embodiments of the present disclosure. The electronic device may include a processor (e.g., a central processing unit, a graphics processing unit, etc.) 501, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 502 or a program loaded from a memory 508 into a random access memory (RAM) 503. Various programs and data required for the operation of the electronic device are also stored in the RAM 503. The processor 501, ROM 502, and RAM 503 are connected to each other via a bus 504. An input / output (I / O) interface 505 is also connected to the bus 504.

[0074] Typically, the following devices may be connected to the I / O interface 505: an input device 506 including, for example, a touch screen, a touchpad, a keyboard, a mouse, a camera, a microphone, an accelerometer, a gyroscope, etc.; an output device 507 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; a storage device 508 including, for example, a magnetic tape, a hard disk, etc.; and a communication device 509. The communication device 509 may allow the electronic device to communicate with other devices wirelessly or by wire to exchange data. Although Figure 4 An electronic device having various devices is shown, but it should be understood that it is not required to implement or possess all of the devices shown, and more or fewer devices may be implemented or possessed instead.

[0075] In particular, according to an embodiment of the present disclosure, the process described above with reference to the flowchart can be implemented as a computer software program. For example, an embodiment of the present disclosure includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program includes program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication device 509, or installed from the memory 508, or installed from the ROM 502. When the computer program is executed by the processor 501, the above-mentioned functions defined in the microservice code management method of the embodiment of the present disclosure are performed.

[0076] Figure 4 The electronic device shown is only an example and should not limit the functions and scope of use of the embodiments of the present disclosure.

[0077] The embodiments of the present disclosure also provide a computer-readable storage medium. The above-mentioned method according to the embodiments of the present disclosure can be implemented in hardware, firmware, or implemented as a computer code that can be recorded in a storage medium, or implemented as a computer code that is originally stored in a remote storage medium or a non-temporary machine-readable storage medium and downloaded through a network and will be stored in a local storage medium, so that the method described herein can be stored in such software processing on a storage medium using a general-purpose computer, a dedicated processor, or programmable or dedicated hardware. Among them, the storage medium can be a magnetic disk, an optical disk, a read-only storage memory, a random access memory, a flash memory, a hard disk or a solid-state drive, etc.; further, the storage medium can also include a combination of the above-mentioned types of memory. It can be understood that a computer, a processor, a microprocessor controller or programmable hardware includes a storage component that can store or receive software or computer code. When the software or computer code is accessed and executed by a computer, a processor or hardware, the microservice code management method shown in the above embodiment is implemented.

[0078] A portion of the present disclosure may be applied as a computer program product, such as a computer program instruction, which, when executed by a computer, can call or provide the method and / or technical solution according to the present disclosure through the operation of the computer. Those skilled in the art should understand that the form in which the computer program instruction exists in a computer-readable medium includes but is not limited to a source file, an executable file, an installation package file, etc. Accordingly, the way in which the computer program instruction is executed by the computer includes but is not limited to: the computer directly executes the instruction, or the computer compiles the instruction and then executes the corresponding compiled program, or the computer reads and executes the instruction, or the computer reads and installs the instruction and then executes the corresponding installed program. Here, the computer-readable medium can be any available computer-readable storage medium or communication medium that can be accessed by the computer.

[0079] Although the embodiments of the present disclosure have been described with reference to the accompanying drawings, those skilled in the art may make various modifications and variations without departing from the spirit and scope of the present disclosure, and such modifications and variations are all within the scope defined by the appended claims.

Claims

1. A microservice code management method, characterized in that: Applied to a microservice code management system configured with a single code repository; the method includes: Obtain the interface definition language document for each microservice dependency required for the project to be created; Determine a target microservice having the same interface definition language document among all the microservices; Performing a union operation on the interface definition language documents that the target microservice depends on to obtain a target interface definition language document; Generate microservice code corresponding to the target microservice based on the target interface definition language document; The microservice code corresponding to the target microservice is stored in the single code repository.

2. The method according to claim 1, characterized in that The method further comprises: If there are multiple groups of target microservices, the microservice codes corresponding to the target microservices of different groups are isolated and stored in the single code repository based on the namespace.

3. The method according to claim 1, characterized in that The method further comprises: If the multiple microservices required for the project to be created include other microservices except the target microservice, determining the microservice codes corresponding to the other microservices; In the single code repository, the microservice codes corresponding to the other microservices and the microservice code corresponding to the target microservice are isolated and stored according to the namespace.

4. The method according to claim 1, wherein The microservice code management system is further configured with an interface definition language document warehouse, which is used to store interface definition language documents required for project creation; the method further includes: Obtaining the type of the interface definition language document contained in the interface definition language document repository; The interface definition language documents contained in the interface definition language document repository are tailored according to the type of the interface definition language document that each microservice required for the project to be created depends on.

5. The method according to claim 4, characterized in that Before performing the microservice code generation operation, the method further includes: According to the requirements of the microservices required by the project to be created for the structure parameters, the structure contained in the interface definition language document that the target microservice depends on is tailored.

6. The method according to claim 1, wherein The method further comprises: Receive a selection of a microservice code generation template; According to the selected microservice code generation template, the step of generating microservice code according to the target interface definition language document is performed.

7. The method according to claim 6, characterized in that The microservice code generation template includes a first microservice code sub-template and a second microservice code sub-template, wherein an amount of code generated based on the first microservice code sub-template is greater than an amount of code generated based on the second microservice code sub-template, and the method further includes: When performing microservice code generation according to the target interface definition language document, generating microservice code corresponding to the corresponding target microservice according to the second microservice code sub-template; When the generated microservice code is submitted for version, the generated microservice code is supplemented and generated according to the first microservice code sub-template.

8. The method according to claim 1, characterized in that The performing a union operation on the interface definition language documents that the target microservice depends on includes: Determine whether the versions of the same interface definition language documents that the target microservice depends on are the same; If the target microservice depends on different versions of the same interface definition language document, obtaining a first interface definition language document and a second interface definition language document contained in the different versions of the same interface definition language document, wherein the first interface definition language document is a new version of the same interface definition language document, and the second interface definition language document is a historical version of the same interface definition language document; If the first interface definition language document only increases the number of fields included in the second interface definition language document, then when performing the union operation, the first interface definition language document is selected as the result of the union operation; If the first interface definition language document contains the same number of fields as the second interface definition language document but the corresponding field types are different, then when performing the union operation, the first interface definition language document is selected as the result of the union operation, and a conflict prompt operation is responded to when a conflict occurs in the corresponding microservice code generation process; If the first interface definition language document contains fewer fields than the second interface definition language document, stop responding to the union operation and perform microservice code generation operations according to the interface definition language documents corresponding to each microservice in the target microservice, and store the generated microservice codes in isolation according to the namespace.

9. The method according to claim 1, characterized in that The method further comprises: If different interface definition language documents that the same microservice depends on contain the same namespace and there is a version conflict in the interface definition language documents corresponding to the same namespace, the codes generated based on the different interface definition language documents containing the same namespace will be isolated and stored in the single code repository according to the namespace.

10. A microservice code management device, characterized in that: Applied to microservice code management system, which is configured with a single code repository; The device comprises: The first acquisition module is used to obtain the interface definition language document of each microservice dependency required by the project to be created; A first determining module is configured to determine a target microservice having the same interface definition language document among all the microservices; A first merging module is configured to perform a union operation on the interface definition language documents that the target microservice depends on to obtain a target interface definition language document; A first generation module is configured to generate a microservice code corresponding to the target microservice based on a target interface definition language document; A storage module is used to store the microservice code corresponding to the target microservice in the single code repository.

11. An electronic device, characterized in that: include: A memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the microservice code management method according to any one of claims 1 to 9 by executing the computer instructions.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer instructions, and the computer instructions are used to enable a computer to execute the microservice code management method according to any one of claims 1 to 9.

13. A computer program product, characterized in that The method comprises computer instructions for causing a computer to execute the microservice code management method according to any one of claims 1 to 9.

Images