Standardized micro-service development method and system

Abstract

The invention provides a standardized micro-service development method and a standardized micro-service development system, and aims to solve the problems of increased system complexity, high team cooperation difficulty, lack of consistency among services and difficulty in maintenance in a traditional scheme. Different developers can execute system development of the same micro-service based on a standard requirement specification; meanwhile, by setting an automatic processing flow of function requirements, code quality, function testing and performance testing, the efficiency and quality of micro-service development are effectively improved, and powerful support is provided for multiplexing, interoperability and continuous optimization of micro-services.

Description

Technical Field

[0001] The present invention belongs to the technical field of software engineering, and particularly relates to a standardized microservice development method and system. Background Art

[0002] The statements in this part only provide background technical information related to the present invention and do not necessarily constitute prior art.

[0003] The microservice architecture has gradually become an important trend in modern software development due to its flexibility, scalability, and maintainability. However, the inventor has found that the existing microservice development methods have the following deficiencies:

[0004] Increased system complexity: As the number of microservices increases, the complexity of the entire system will increase significantly, bringing greater challenges to development and management; Increased difficulty in team collaboration: The development, deployment, monitoring, and troubleshooting of different microservices require more systematic collaborative control, with higher requirements for the collaboration ability between teams, and the collaborative efficiency may be affected; Lack of consistency between services: The high autonomy of microservices allows different teams to freely choose technology stacks for innovation, easily leading to a lack of consistency in communication, data storage, and exception handling between services, which may affect the overall stability of the system; Difficult to maintain: For businesses lacking standardized protocols and practices, many problems will be faced during subsequent maintenance, increasing the maintenance cost and risk. Summary of the Invention

[0005] To overcome the deficiencies of the above-mentioned prior art, the present invention provides a standardized microservice development method and system to solve the problems of increased system complexity, great difficulty in team collaboration, lack of consistency between services, and difficult maintenance in traditional solutions.

[0006] According to the first aspect of the embodiments of the present invention, a standardized microservice development system is provided, including:

[0007] A standardized microservice definition module, which is used to receive configuration data of a microservice from a developer based on a preset configuration interface and generate a service requirement specification, wherein the configuration interface is generated based on a preset standard template;

[0008] A microservice development module, which is used to perform collaborative development of microservice code based on the generated service requirement specification and generate an interface specification document;

[0009] A requirement review and information extraction module, which is used to perform a functional requirement review based on the service requirement specification and the interface specification document, and enter the code quality review module after the functional requirement review is qualified;

[0010] A code quality review module, which is used to perform quality analysis on the developed microservice code according to a preset quality inspection strategy;

[0011] A test module, which is used to perform automated testing and performance testing on microservice interfaces based on test cases in the interface specification document, and run the microservices after successful testing.

[0012] A monitoring and warning module, which is used to monitor the performance parameters of microservices in real time and issue an alarm when the performance parameters exceed the preset threshold.

[0013] Furthermore, the requirements specification includes a document overview, project background, functional requirements, and non-functional requirements, and is organized and constructed in accordance with the standard directory format; among them, for the functional requirements part in the requirements specification, it is organized and constructed according to functional modules, and for each functional module, the name of the functional module provided by the microservice and the relevant description of the API interfaces exposed externally under the functional module are provided; for the non-functional requirements part in the requirements specification, it is divided into security, availability, and interface performance requirements parts.

[0014] Furthermore, the interface specification document includes a document overview and an interface list, and is organized and constructed in accordance with the standard directory format; among them, for the interface list part in the interface specification document, it is organized and constructed according to functional modules, and detailed descriptions are made for all externally exposed API interfaces under each functional module, specifically including: URL path, HTTP method, request parameters, response format, error code, self-test performance requirements, and exemplary test cases.

[0015] Furthermore, for the requirements specification and the interface specification document, based on a pre-built document transposition tool, they are transformed into relational data tables in a fixed format.

[0016] Furthermore, based on the service requirements specification and the interface specification document, a functional requirements review is carried out. Specifically, the first relational data table corresponding to the requirements specification and the second relational data table corresponding to the interface specification document are fully joined, and it is judged whether the self-test performance indicators in the second relational data table meet the corresponding indicator values and verification symbol requirements in the first relational data table according to the preset rules.

[0017] Furthermore, based on the developed microservice code, a quality analysis of the code is carried out according to the preset quality inspection strategy. Specifically, a static analysis tool is used to automatically analyze whether the variable names, method names, and class names of the code meet the camel case naming rule, and the comment rate of the code is counted. For the source code that does not meet the camel case naming rule or the code comment rate is lower than the agreed threshold, a warning is issued and feedback is given to the developer, prompting the developer to optimize the code and resubmit it.

[0018] Further, automated testing and performance testing are performed on the microservice interface based on the test cases in the interface specification document, specifically: performing tests based on a preset automated testing tool and storing the test data in a test result table; based on the test result table, first determining whether the function availability and interface security pass the tests, warning the interfaces that fail the tests, and feedbacking to the developers to prompt them to optimize and resubmit; for the interfaces that pass the function availability and interface security tests, performing a full join of the first relational data table and the test result table, and determining whether the performance index test values in the test result table can meet the corresponding index values and verification symbol requirements in the first relational data table according to preset rules.

[0019] According to the second aspect of the embodiments of the present invention, a standardized microservice development method is provided, which is based on the above-mentioned standardized microservice development system, and includes:

[0020] Receiving configuration data of the microservice from the developer based on a preset configuration interface, and generating a service requirement specification, wherein the configuration interface is generated based on a preset standard template;

[0021] Based on the generated service requirement specification, performing collaborative development of the microservice code and generating an interface specification document;

[0022] Based on the service requirement specification and the interface specification document, performing a functional requirement review, and entering the code quality review module after the functional requirement review is qualified;

[0023] Based on the developed microservice code, performing quality analysis on the code according to a preset quality inspection strategy;

[0024] Based on the test cases in the interface specification document, performing automated testing and performance testing on the microservice interface, and running the microservice after the testing is successful;

[0025] Performing real-time monitoring on the performance parameters during the operation of the microservice, and issuing an alarm when the performance parameters exceed the preset threshold.

[0026] According to the third aspect of the embodiments of the present invention, an electronic device is provided, including a memory, a processor, and a computer program running on the memory, and the processor implements the above-mentioned standardized microservice development method when executing the program.

[0027] According to the fourth aspect of the embodiments of the present invention, a non-transitory computer-readable storage medium is provided, on which a computer program is stored, and the program implements the above-mentioned standardized microservice development method when executed by the processor.

[0028] The above one or more technical solutions have the following beneficial effects:

[0029] (1) The solution provided by the present invention is a standardized microservice development method and system. To solve the problems of increased system complexity, difficult team collaboration, lack of consistency between services, and difficult maintenance in traditional solutions, the solution standardizes the configuration by using a unified configuration template for the definition of microservices. Different developers can perform the system development of the same microservice based on a standard requirements specification. At the same time, by setting up automated processing flows for functional requirements, code quality, functional testing, and performance testing, the efficiency and quality of microservice development are effectively improved, and strong support is also provided for the reuse, interoperability, and continuous optimization of microservices.

[0030] (2) The solution of the present invention involves the definition, development, testing, and operation monitoring of microservices, providing a full-life-cycle development control solution for microservices, which can effectively address various problems throughout the life cycle of microservices.

[0031] (3) Through standardization and automation means, the solution of the present invention enables users to better cope with complex business requirements and technical challenges, achieving a faster market response speed and higher competitiveness.

[0032] Advantages of additional aspects of the present invention will be partly given in the following description, partly become apparent from the following description, or be learned through the practice of the present invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The specification drawings forming a part of the present invention are used to provide a further understanding of the present invention. The schematic embodiments of the present invention and their descriptions are used to explain the present invention and do not constitute an improper limitation of the present invention.

[0034] Figure 1 It is a flowchart of a standardized microservice development method described in an embodiment of the present invention;

[0035] Figure 2 It is the structure of the requirements specification stipulated in a standardized microservice development method described in an embodiment of the present invention;

[0036] Figure 3 It is the structure of the interface specification document stipulated in a standardized microservice development method described in an embodiment of the present invention;

[0037] Figure 4 It is a schematic diagram of the structure of a standardized microservice development system described in an embodiment of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0038] To make the above objects, features, and advantages of the present invention more obvious and understandable, the following detailed description of the specific embodiments of the present invention will be given in conjunction with the specification drawings.

[0039] In the following description, many specific details are set forth in order to provide a thorough understanding of the present invention. However, the present invention may be practiced in other ways different from those described herein. Those skilled in the art can make similar extensions without departing from the spirit of the present invention. Therefore, the present invention is not limited by the specific embodiments disclosed below.

[0040] In one or more embodiments, as Figure 4 shown, the present embodiment provides a standardized microservice development system, which specifically includes the following parts:

[0041] A standardized microservice definition module, which is used to receive configuration data of a microservice from a developer based on a preset configuration interface, and generate a service requirement specification. Among them, the configuration interface is generated based on a preset standard template;

[0042] In specific implementation, it is required that the developer perform the following processing procedures based on the preset configuration interface:

[0043] The microservice developer submits the registration name of the new microservice, the Chinese name of the service, and the requirement specification of the microservice. After submission, first, conflict checks are performed on the registration name of the service and the Chinese name of the service to avoid confusion in service calls caused by the existence of services with the same name in the system; second, functional and non-functional requirement information is extracted from the requirement specification according to rules.

[0044] In order to standardize the service development process, as Figure 2 shown, the requirement specification needs to include core contents such as a document overview, a project background, functional requirements, and non-functional requirements, and be organized in a standard table of contents format. For the functional requirement part in the requirement specification, it is organized by functional modules. For each functional module, first, the name of the functional module provided by the microservice is described in detail, and then all externally exposed API interfaces under this functional module are described in sequence, including the URL path, HTTP method, request parameters, response format, error code, etc. For the non-functional requirement part in the requirement specification, it is divided into parts such as security, availability, and interface performance requirements. Among them, the interface performance requirements are divided into general performance requirements and special performance requirements. The special performance requirement part stipulates the interfaces for which performance requirements need to be specified separately, and the general performance requirements are for the performance requirements of all other interfaces in this microservice except those for which performance requirements are specified separately.

[0045] For the requirements specification, a requirements document transposition tool is built based on the python-docx library and standardized document structure rules. The functional requirements and non-functional requirements in the requirements specification are automatically extracted according to information such as title styles, title texts, and context positions, and parsed into table form. For functional requirements, the data is extracted into the table FUNC_TABLE, and the style of each row in the table is: <function module name, interface name, URL path, HTTP method, request parameters, response format, error code>; for non-functional requirements, the focus is on its performance requirements part. For the general performance requirements in the performance requirements, the data is extracted into the table G_PERF_TABLE, and the table has only one row with the style: <performance metric 1 value, performance metric 1 verification symbol, performance metric 2 value, performance metric 2 verification symbol, ···>. For the special performance requirements in the performance requirements, the data is extracted into the table S_PERF_TABLE, and the table style is: <interface name, performance metric 1 value, performance metric 1 verification symbol, performance metric 2 value, performance metric 2 verification symbol, ···>.

[0046] Check the data in the FUNC_TABLE, G_PERF_TABLE, and S_PERF_TABLE tables. If there are missing fields in the data, the abnormal data of that row is fed back to the developer, prompting the developer to optimize the requirements specification and resubmit. If there is no missing data, for the extracted functional requirements and non-functional requirements, they are merged and aligned according to the rules to obtain the final requirements data table REQU_TABLE, and the table style is: <function module name, interface name, URL path, HTTP method, request parameters, response format, error code, performance metric 1 value, performance metric 1 verification symbol, performance metric 2 value, performance metric 2 verification symbol, ···>. The data in the REQU_TABLE table can be obtained by executing the following statement:

[0047] "insert into REQU_TABLE

[0048] select a.function module name,a.interface name,a.URL path,a.HTTP method,a.request parameters,a.response format,a.error code,b.performance metric 1 value, b.performance metric 1 verification symbol, b.performance metric 2 value, b.performance metric 2 verification symbol, ···

[0049] from FUNC_TABLE a,S_PERF_TABLE b

[0050] where a.interface name = b.interface name

[0051] UNION

[0052] select a. Functional module name, a. Interface name, a. URL path, a. HTTP method, a. Request parameters, a. Response format, a. Error code, b. Performance metric 1 value, b. Performance metric 1 verification symbol, b. Performance metric 2 value, b. Performance metric 2 verification symbol, ···

[0053] from FUNC_TABLE a, G_PERF_TABLE b

[0054] where 1 = 1

[0055] and a. Interface name not in (select interface name from S_PERF_TABLE)”

[0056] The performance metrics include, but are not limited to, metrics such as interface response time, throughput, error rate, etc. The performance metric verification symbols include, but are not limited to, “<”, “>”, etc.

[0057] The microservice development module is used to perform collaborative development of microservice code based on the generated service requirement specification and generate an interface description document;

[0058] In a specific implementation, since the same microservice may be developed by multiple developers, the generated service requirement specification enables multiple developers to perform collaborative development according to the same standard.

[0059] The requirement review and information extraction module is used to perform functional requirement review based on the service requirement specification and the interface description document. After the functional requirement review is qualified, it enters the code quality review module;

[0060] Furthermore, for the generated interface description document, it is necessary to automatically review the integrity and standardization of documents such as the interface description document based on preset rules and extract relevant information; specifically:

[0061] After the developer develops the microservice according to the requirement specification, the original service code is submitted and the interface description document is filled in and submitted as required.

[0062] To standardize the service development process, as Figure 3 shown, the interface description document needs to include core contents such as a document overview and an interface list, and be organized in a standard table of contents format. For the interface list part in the requirement specification, it is organized by functional module, and all externally exposed API interfaces under this functional module are described in sequence, including URL path, HTTP method, request parameters, response format, error code, self-test performance requirements, exemplary test cases, etc.

[0063] Similar to the requirements specification, for the interface specification document, an interface specification document transposition tool is built based on the python-docx library and standardized document structure rules. The interface list in the interface specification document is automatically extracted according to information such as title styles, title texts, and context positions, and is parsed into a table form to obtain the interface information table API_TABLE. The style of each row in the table is: <function module name, interface name, URL path, HTTP method, request parameters, response format, error code, test cases, self-test performance indicator 1, self-test performance indicator 2, self-test performance indicator 3, ···>. According to the extraction result, if the extraction is successful, the table is fed back to the developer for confirmation; otherwise, an exception message is returned, prompting the developer to optimize the interface specification document and resubmit it.

[0064] The performance indicators include, but are not limited to, indicators such as interface response time, throughput, error rate, etc., but need to be exactly the same as the performance indicators in the requirements specification.

[0065] In a specific implementation, in order to make the requirements meet the review, functional review is automatically performed based on the service requirements specification and the interface specification document to determine whether the service has completed the functional requirements and non-functional requirements specified in the requirements specification.

[0066] The REQU_TABLE and API_TABLE are fully joined, and it is judged according to the rules whether the self-test performance indicators in API_TABLE can meet the corresponding indicator values and verification symbol requirements in REQU_TABLE. Taking the response time indicator as an example, if the required value of the response time indicator for a certain interface in REQU_TABLE is 0.1 and the verification symbol is "<", it is feedback as false when the self-test response time indicator value in API_TABLE is greater than 0.1, prompting the developer that the performance indicator does not meet the requirements of the requirements specification; when the self-test response time indicator value in API_TABLE is less than 0.1, it means that the performance of this interface can meet the requirements and the verification passes. Early warnings are given for the interfaces that fail the verification and are fed back to the developer, prompting the developer to optimize the interface service and resubmit it.

[0067] The code quality review module is used to perform quality analysis on the developed microservice code according to the preset quality inspection strategy.

[0068] In a specific implementation, the review of the code quality is specifically as follows: for the source code submitted by the developer, static analysis tools such as checkstyle are used to automatically analyze whether the variable names, method names, and class names in the code meet the camel case naming rule, and the comment rate of the code is counted. Warnings are given for the source code that does not meet the camel case naming rule or the code comment rate is lower than the agreed threshold, and are fed back to the developer, prompting the developer to optimize the code and resubmit it.

[0069] A test module, which is used to perform automated testing and performance testing on microservice interfaces based on test cases in the interface specification document, and run the microservices after successful testing.

[0070] In specific implementation, the microservices are automatically deployed to the test environment, and testers design automated test scenarios and test cases according to the interface specification document. Use automated testing tools such as Postman or jmeter to execute the tests, and store the test data in the test result table TEST_TABLE. The format of each row in the table is: <function module name, interface name, function availability, interface security, performance metric 1 test value, performance metric 2 test value, performance metric 3 test value, ···>. Among them, the results of function availability and interface security are of boolean type, where true means the test passes, and false means the test fails.

[0071] Based on the test result table, first judge whether the function availability and interface security pass the test. For the interfaces that fail the test, give a warning and feedback to the developers, prompting the developers to optimize and resubmit. For the interfaces that pass the function availability and interface security tests, perform a full join on the table REQU_TABLE and TEST_TABLE, and judge whether the performance metric test values in TEST_TABLE can meet the corresponding metric values and verification symbol requirements in REQU_TABLE according to the rules. For the interfaces that fail the verification, give a warning and feedback to the developers, prompting the developers to optimize the interface service and resubmit.

[0072] A monitoring and warning module, which is used to monitor the performance parameters of the microservices in real time during operation, and issue an alarm when the performance parameters exceed the preset threshold.

[0073] In specific implementation, the microservices are automatically deployed to the production environment for online operation. In order to ensure that the service can stably provide services externally according to the performance requirements specified in the requirements specification during operation, use monitoring tools such as Prometheus to monitor the performance metrics of the service in real time and set warning thresholds. When the performance of the service cannot meet the specified performance requirements due to factors such as the operating environment during operation, give a warning notice in time, and let the operation and maintenance personnel or developers optimize it.

[0074] In one or more embodiments, as Figure 1 shown, a standardized microservice development method is provided based on the above system, including:

[0075] Receiving configuration data for the microservices from the developers based on a preset configuration interface, and generating a service requirements specification, where the configuration interface is generated based on a preset standard template;

[0076] Based on the generated service requirement specification, perform collaborative development of microservice code and generate an interface specification document;

[0077] Based on the service requirement specification and the interface specification document, conduct a functional requirement review. After the functional requirement review is qualified, enter the code quality review module;

[0078] Based on the developed microservice code, perform quality analysis on the code according to a preset quality inspection strategy;

[0079] Based on the test cases in the interface specification document, conduct automated testing and performance testing on the microservice interface. After the testing is successful, run the microservice;

[0080] Real-time monitor the performance parameters during the operation of the microservice, and issue an alarm when the performance parameters exceed the preset threshold.

[0081] In more embodiments, there is also provided:

[0082] An electronic device includes a memory, a processor, and computer instructions stored on the memory and running on the processor. When the computer instructions are run by the processor, the method described in Embodiment 1 is completed. For the sake of brevity, it will not be elaborated here.

[0083] It should be understood that in this embodiment, the processor may be a central processing unit CPU, and the processor may also be other general-purpose processors, digital signal processors DSP, application-specific integrated circuits ASIC, field-programmable gate arrays FPGA or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc.

[0084] The memory may include a read-only memory and a random access memory, and provide instructions and data to the processor. A part of the memory may also include a non-volatile random access memory. For example, the memory may also store information about the device type.

[0085] A computer-readable storage medium is used to store computer instructions. When the computer instructions are executed by the processor, the method described in Embodiment 1 is completed.

[0086] The method in Embodiment 1 can be directly implemented by a hardware processor to complete, or implemented by a combination of hardware and software modules in the processor. The software module may be located in a mature storage medium in the art such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. This storage medium is located in the memory, and the processor reads the information in the memory and combines its hardware to complete the steps of the above method. To avoid repetition, it will not be described in detail here.

[0087] The present invention also provides at least one computer program product tangibly stored on a non-transitory computer-readable storage medium. The computer program product includes computer-executable instructions, such as instructions included in program modules, which are executed in a device on a target real or virtual processor to perform the processes / methods as described above. Generally, program modules include routines, programs, libraries, objects, classes, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In various embodiments, the functions of program modules can be combined or divided as needed among the program modules. The machine-executable instructions for the program modules can be executed within local or distributed devices. In a distributed device, the program modules can be located in local and remote storage media.

[0088] The computer program code for implementing the method of the present invention can be written in one or more programming languages. This computer program code can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when the program code is executed by the computer or other programmable data processing device, the functions / operations specified in the flowchart and / or block diagram are implemented. The program code can be executed entirely on the computer, partially on the computer, as a stand-alone software package, partially on the computer and partially on a remote computer, or entirely on a remote computer or server.

[0089] In the context of the present invention, the computer program code or related data can be carried by any suitable carrier such that a device, apparatus, or processor can perform the various processes and operations described above. Examples of carriers include signals, computer-readable media, and the like. Examples of signals can include electrical, optical, radio, acoustic, or other forms of propagated signals, such as carrier waves, infrared signals, etc.

[0090] Those of ordinary skill in the art can realize that the units and algorithm steps of the examples described in conjunction with this embodiment can be implemented by electronic hardware or a combination of computer software and electronic hardware. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Professional technicians can use different methods for each specific application to implement the described functions, but such implementation should not be considered to exceed the scope of this application.

[0091] Although the specific implementation manners of the present invention have been described above in conjunction with the accompanying drawings, it is not a limitation to the protection scope of the present invention. Those skilled in the art should understand that based on the technical solution of the present invention, various modifications or deformations that can be made by those skilled in the art without creative efforts are still within the protection scope of the present invention.

Claims

1. A standardized microservice development system, characterized in that: include: A standardized microservice definition module, which is used to receive configuration data for microservices from developers based on a preset configuration interface and generate a service requirement specification, wherein the configuration interface is generated based on a preset standard template; Microservice development module, which is used to perform collaborative development of microservice code based on the generated service requirement specification and generate interface description documents; The requirement review and information extraction module is used to review the functional requirements based on the service requirement specification and interface description document. After the functional requirements are reviewed and qualified, the module enters the code quality review module. The code quality review module is used to analyze the quality of the developed microservice code according to the preset quality inspection strategy; The test module is used to perform automated testing and performance testing on the microservice interface based on the test cases in the interface description document, and run the microservice after the test is successful; The monitoring and early warning module is used to monitor the performance parameters of microservices in real time during operation and issue an alarm when the performance parameters exceed the preset threshold.

2. A standardized microservice development system as claimed in claim 1, characterized in that: The requirement specification includes a document overview, project background, functional requirements and non-functional requirements, and is organized and constructed according to a standard directory format; the functional requirements part of the requirement specification is organized and constructed according to functional modules, and the functional module name provided by each functional module microservice and the relevant description of the API interface exposed to the outside under the functional module are provided; the non-functional requirements part of the requirement specification is divided into security, availability and interface performance requirements.

3. A standardized microservice development system as claimed in claim 1, characterized in that: The interface description document includes a document overview and an interface list, and is organized and constructed according to a standard directory format; wherein, the interface list part in the interface description document is organized and constructed according to functional modules, and all externally exposed API interfaces under each functional module are described in detail, specifically including: URL path, HTTP method, request parameters, response format, error code, self-test performance requirements, and exemplary test cases.

4. A standardized microservice development system as claimed in claim 1, characterized in that: The requirement specifications and interface description documents are converted into relational data tables in a fixed format based on the pre-built document conversion tool.

5. A standardized microservice development system as claimed in claim 1, characterized in that: The functional requirement review is conducted based on the service requirement specification and the interface description document, specifically: a first relational data table corresponding to the requirement specification and a second relational data table corresponding to the interface description document are fully connected, and a determination is made according to preset rules as to whether the self-test performance indicators in the second relational data table meet the corresponding indicator values ​​and checksum requirements in the first relational data table.

6. A standardized microservice development system as claimed in claim 1, characterized in that: The developed microservice code is subjected to quality analysis according to a preset quality inspection strategy. Specifically, a static analysis tool is used to automatically analyze whether the variable names, method names, and class names of the code meet the camel case naming rules, and the comment rate of the code is counted. For source codes that do not meet the camel case naming rules or whose code comment rate is lower than the agreed threshold, an early warning is issued, and feedback is given to the developer, prompting the developer to optimize the code and resubmit it.

7. A standardized microservice development system as claimed in claim 5, characterized in that: The automated testing and performance testing of the microservice interface based on the test cases in the interface description document is specifically: executing the test based on a preset automated testing tool and storing the test data in a test result table; Based on the test result table, first determine whether the functional availability and interface security tests have passed, issue warnings for interfaces that have failed the test, and provide feedback to developers, prompting them to optimize and resubmit; For interfaces that have passed the functional availability and interface security tests, the first relational data table is fully connected with the test result table, and it is determined according to preset rules whether the performance indicator test values ​​in the test result table can meet the corresponding indicator values ​​and checksum requirements in the first relational data table.

8. A standardized microservice development method, based on a standardized microservice development system as claimed in any one of claims 1 to 7, characterized in that: include: Receiving configuration data for microservices from developers based on a preset configuration interface, and generating a service requirement specification, wherein the configuration interface is generated based on a preset standard template; Based on the generated service requirement specification, perform collaborative development of microservice code and generate interface description documents; Based on the service requirement specification and interface description document, the functional requirement review is carried out. After the functional requirement review is qualified, the code quality review module is entered; Based on the developed microservice code, perform quality analysis on the code according to the preset quality inspection strategy; Based on the test cases in the interface description document, perform automated testing and performance testing on the microservice interface, and run the microservice after the test is successful; Monitor the performance parameters of microservices in real time during runtime and issue alarms when performance parameters exceed preset thresholds.

9. An electronic device comprising a memory, a processor and a computer program stored and running on the memory, characterized in that: When the processor executes the program, a standardized microservice development method as described in claim 8 is implemented.

10. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, a standardized microservice development method as described in claim 8 is implemented.

Images