Enterprise internal application full-life-cycle management system based on micro-service architecture

Abstract

The invention relates to the technical field of enterprise service collection, in particular to an enterprise internal application full-life-cycle management system based on a micro-service architecture, and the system comprises an application development test module which is used for carrying out the unit test and integration test of a test case through a containerized test environment; the application on-shelf auditing module is used for extracting metadata information in the application deployment package through a standardized configuration analyzer and outputting a compliance application package after passing an approval process; the application operation monitoring module is used for collecting an operation state data set of the compliance application package in real time through a resource probe; the application safety off-shelf module is used for executing off-shelf operation on the compliance application package with the risk assessment result meeting the preset off-shelf condition; and the full life cycle tracking module is used for performing tracking analysis on each module and outputting a visual topological relation graph. According to the method and the system, the whole process from development to off-shelf of the application can be managed and controlled, and the application quality, safety and management efficiency are remarkably improved.

Description

Technical Field

[0001] This invention relates to the field of enterprise service acquisition technology, and in particular to an enterprise internal application lifecycle management system based on a microservice architecture. Background Technology

[0002] In the process of enterprise digital transformation, third-party software integration and enterprise service integration have become important means to improve operational efficiency. While current mainstream application management models have achieved basic third-party software integration functions and can provide some standardized service support for enterprises, they have significant shortcomings in the construction of a full lifecycle management system. The root cause of this deficiency lies in the lack of a technical architecture and mechanism design that covers the entire process in the existing management system. During the development phase, due to the lack of standardized development frameworks and compliance verification tools, it is difficult to form unified standards for data collection and processing of enterprise application development needs, resulting in ineffective data compliance assurance. At the same time, the generation of test cases relies excessively on manual experience, lacking automated generation and optimization capabilities, leading to low testing efficiency. Before application deployment, due to the lack of a cross-dimensional automated security testing and compliance audit system, the review work relies heavily on manual sampling, making it difficult to comprehensively cover key dimensions such as code vulnerabilities, permission risks, and data compliance, resulting in difficulty in accurately identifying security risks. During operation, due to the lack of a real-time dynamic monitoring system and a lack of a mechanism for continuous collection and analysis of application performance indicators and abnormal behavior, it is impossible to detect operational failures and potential risks in a timely manner. In the risk management phase, the lack of an automated delisting trigger mechanism and a full-cycle logging system not only resulted in delayed delisting responses, but also failed to fully retain key information from application development to termination. This ultimately led to inconsistent application quality, increased security risk exposure, and a significant reduction in the overall efficiency of enterprise application management.

[0003] For example, Chinese Patent Publication No. CN114416297A discloses a method and system for containerizing a mobile platform, including: adding a backend management plugin to the platform backend; introducing a replugin application plug-in component to the platform client; implementing application system access authentication through an application access authentication interface; obtaining application system access authentication information through an inter-application call interface; implementing data communication methods between application systems through an inter-application communication interface; and starting other application systems and data processing processes. Although this solution can achieve containerization of the mobile platform and inter-application communication, it lacks full-process management of application development, testing, uploading, review, operation monitoring, and secure removal, which reduces application quality, security, and management efficiency. Summary of the Invention

[0004] To address this, the present invention provides an enterprise internal application lifecycle management system based on a microservice architecture, which overcomes the lack of full-process management of application development, testing, listing, operation monitoring, and secure delisting in existing technologies, thus reducing application quality, security, and management efficiency.

[0005] To achieve the above objectives, this invention provides an enterprise internal application lifecycle management system based on a microservice architecture, comprising: The application development testing module is used to acquire enterprise application development requirement data, perform syntax structure parsing, coding standard verification, and security rule analysis on the code files in the enterprise application development requirement data through a pre-built development specification verification engine, output code compliance report, generate test cases based on the code compliance report and enterprise application development requirement data, and perform unit testing and integration testing on the test cases through a containerized testing environment, and output application deployment package that passes the test; The application submission review module is used to extract metadata information from the application deployment package through a standardized configuration parser, input the metadata information into the automated compliance detection engine to perform code security scanning and permission policy verification, output security detection results, compare the security detection results with the preset approval rule base, and output a compliant application package after passing the approval process. The application runtime monitoring module is used to collect the runtime status dataset of the compliant application package in real time through resource probes after the compliant application package is deployed to the target runtime environment. The application security delisting module is used to perform risk assessment on the runtime status dataset through a risk assessment model, generate risk assessment results, and execute permission revocation instructions, data archiving tasks, and microservice registry decoupling operations on compliant application packages whose risk assessment results meet the preset delisting conditions, and output a delisting completion status identifier. The full lifecycle tracking module is used to input version change records, service dependency data, and operation logs generated by each module into the event tracing component to build a time-series database record and output a visual topology diagram.

[0006] Compared with the prior art, the beneficial effects of this application are as follows: By leveraging the collaborative management of the application development and testing module and the application submission review module, application quality and security are improved. The application development and testing module uses a pre-built development specification verification engine to parse the syntax structure of code files, verify coding standards, and analyze security rules. It outputs a code compliance report and generates test cases. After unit testing and integration testing in a containerized testing environment, a qualified deployment package is output. The application submission review module extracts metadata through a standardized configuration parser, performs code security scanning and permission policy verification through an automated compliance detection engine, and completes the approval process in conjunction with a pre-built approval rule library. This overcomes the problem of lacking quality control throughout the entire process from development to submission in existing technologies, reduces code defects and security risks, and improves application compliance.

[0007] By implementing closed-loop management through the application operation monitoring module and the application security delisting module, the stability and controllability of application operation are ensured. After deploying compliant application packages, the application operation monitoring module collects operational status datasets in real time through resource probes. The application security delisting module performs risk assessments on the datasets based on a risk assessment model. For applications that meet the delisting conditions, it performs permission revocation, data archiving, and decoupling operations from the microservice registry center. This avoids the problem of existing technologies lacking operation monitoring and standardized delisting mechanisms, enabling real-time perception of operational status and precise risk handling. It prevents system failures caused by the continued operation of risky applications and improves the timeliness and security of application management.

[0008] The application lifecycle tracking module enables full-process traceability, improving management efficiency. This module inputs version change records, service dependency data, and operation logs of each module into the event tracing component, constructs a time-series database record, and outputs a visual topology diagram. It overcomes the problem of existing technologies lacking full-process tracking methods, making data from each stage of development testing, app store approval, operation monitoring, and security delisting traceable. The visual topology clearly presents service relationships, helping managers quickly locate problems, optimize resource allocation, and improve the convenience and efficiency of application lifecycle management.

[0009] Furthermore, the application development and testing module includes: The static code analysis unit receives enterprise application development requirement data, performs syntax structure parsing, coding standard verification, and security rule analysis on the code files in the enterprise application development requirement data through a pre-built development standard verification engine, and outputs a code compliance report containing code compliance score, standard violation items, and repair suggestions. The test execution unit is used to dynamically adjust the test coverage strategy based on the distribution characteristics of specification violations in the code compliance report, combined with enterprise application development requirement data and a pre-built test case generator, to generate a test case set that matches the code defect pattern. The test case set is then injected into the containerized test environment to execute unit tests and integration tests. When the unit test coverage reaches a preset coverage threshold and the integration test passes the preset business scenario verification, the application deployment package is output. The containerized test environment uses Docker or Kubernetes to implement resource isolation and version rollback mechanisms, and collects test coverage and exception stack information in real time during test execution.

[0010] In this solution, the static code analysis unit can identify code syntax, standardization, and security issues in advance, output compliance reports, and reduce repair costs. The test execution unit can dynamically adjust test strategies based on the reports, generate matching test case sets, and execute tests in a containerized test environment to ensure comprehensive and efficient testing, improve test coverage and accuracy, and guarantee the quality of application deployment packages.

[0011] Furthermore, the test execution unit includes: The test configuration adaptation subunit is used to dynamically analyze the microservice topology of the containerized test environment based on the service dependency data in the code compliance report, and generate simulated service endpoints that are compatible with the target runtime environment. The test feedback optimization subunit is used to collect exception logs and performance metrics during test execution, predict potential defect patterns in the exception logs and performance metrics through machine learning models, obtain optimized test strategies, and write the optimized test strategies into the rule base of the test case generator as input parameters for the next round of test case generation.

[0012] In this solution, the test configuration adaptation subunit dynamically orchestrates the microservice topology of the containerized test environment and generates compatible simulated service endpoints based on the service dependency data in the code compliance report. This enables more accurate simulation of the target runtime environment and improves test realism. The test feedback optimization subunit collects exception logs and performance metrics, uses machine learning models to predict potential defect patterns, obtains optimized test strategies, and updates the test case generator rule base. This allows for continuous optimization of tests, early detection of potential problems, and improved test effectiveness and application quality.

[0013] Furthermore, the application submission review module includes: The metadata parsing unit is used to input the application deployment package into the standardized configuration parser to extract metadata information and output a structured metadata set. The metadata information includes application dependency library versions, service interface definitions and configuration parameters. The compliance detection execution unit is used to input the structured metadata set into the automated compliance detection engine, perform a security scan on the structured metadata set through a pre-built code security rule base and permission policy verification module, and output a security detection result set containing defect locations and risk levels. The security scan includes vulnerability pattern matching and sensitive permission call path analysis. The approval process decision unit is used to match and compare the security detection result set with the threshold conditions and approval strategies in the preset approval rule base. When the detection result meets the preset pass conditions, it triggers the electronic approval process generation instruction and outputs a compliant application package containing the approval status identifier after the approval process is passed.

[0014] In this solution, the metadata parsing unit uses a standardized configuration parser to extract application deployment package metadata and output a structured set, which can accurately obtain key application information; the compliance detection execution unit uses an automated compliance detection engine to perform security scanning on metadata based on a pre-set rule base and verification module, covering vulnerability matching and permission path analysis, and comprehensively investigating risks; the approval process decision unit matches the security detection results with preset rules, triggers the electronic approval process when the conditions are met, and outputs a compliant application package with an approval mark after the approval process is passed, realizing automated and accurate review, and improving the efficiency and accuracy of listing review.

[0015] Furthermore, in the application operation monitoring module, the resource probe includes a container metric collector and a call chain tracer. The container metric collector acquires resource consumption metrics in real time, and the call chain tracer acquires the abnormal call frequency between microservices through the service mesh component.

[0016] In this solution, resource consumption metrics are acquired in real time through the container metric collector in the resource probe, and the call chain tracer is combined with the service mesh component to capture the frequency of abnormal calls between microservices, so as to achieve accurate monitoring of the application's running resource status and service call anomalies, and improve the timeliness of problem discovery and the comprehensiveness of monitoring.

[0017] Furthermore, the application security removal module includes: The risk assessment unit is used to analyze the resource consumption indicators, abnormal call frequency and service dependency data in the operation status dataset through the risk assessment model, and generate a risk assessment result containing risk level identifiers. The delisting execution unit is used to execute a role-based permission revoke instruction on the compliant application package when the delisting decision information in the risk assessment results meets the preset delisting conditions, and to trigger a data archiving task to store the operation logs and configuration data of the compliant application package, and send a service instance decoupling request to the microservice registry center. Finally, it outputs a delisting completion status identifier containing a delisting timestamp and resource release status. The service instance decoupling request includes a service instance ID cancellation instruction and a configuration metadata clearing instruction.

[0018] In this solution, the risk assessment unit analyzes resource consumption indicators, abnormal call frequency and service dependencies to generate assessment results with risk levels. When the delisting conditions are met, the delisting execution unit performs permission revocation and data archiving, sends a decoupling request containing instance ID cancellation and metadata clearing to the microservice registry center, and outputs a delisting status identifier to achieve standardized delisting with controllable risks and ensure the integrity of resource release and data retention.

[0019] Furthermore, the risk assessment unit includes: The risk assessment model construction subunit is used to acquire historical operation status data and corresponding risk labeling information, form historical operation status data samples, divide the historical operation status data samples into data training set and data validation set, input the data training set into the convolutional neural network model for training, adjust the model parameters of the convolutional neural network model through the data validation set, and output the convolutional neural network model that meets the preset accuracy as the risk assessment model. The risk analysis subunit is used to input the runtime status dataset into the risk assessment model to perform multi-dimensional correlation analysis on resource consumption indicators, abnormal call frequency and service dependency data, and generate risk assessment results containing risk level identifiers in combination with preset risk level classification rules.

[0020] In this solution, a risk assessment model construction sub-unit uses historical data samples to train and adjust a convolutional neural network model to generate a risk assessment model. The risk analysis sub-unit inputs the operating status data into the model and performs multi-dimensional correlation analysis on resource consumption indicators, abnormal call frequency, and service dependencies. Combined with preset rules, it generates results with risk levels, thereby improving the accuracy and comprehensiveness of risk assessment and ensuring the reliability of assessment results.

[0021] Furthermore, the full lifecycle tracking module includes: The data integration unit is used to obtain version change records from the application development and testing module, approval process logs from the application listing review module, running status datasets from the application operation monitoring module, and risk assessment results and listing completion status indicators from the application security delisting module through the event tracing component, forming structured event objects, and storing the structured event objects as time series database records through the time series database write interface; The visualization processing unit is used to perform association analysis on the event association identifiers in the time series database records using graph algorithms, generate topological relationship data containing nodes and edges, and input the topological relationship data into the visualization rendering engine to generate a visualized topological relationship graph containing application version, service dependency and operation trajectory based on a preset layout algorithm.

[0022] In this solution, the data integration unit uses the event tracing component to obtain key data from multiple modules to form structured event objects, which are then stored as time-series database records, achieving efficient integration and orderly storage of full lifecycle data. The visualization processing unit uses graph algorithms to analyze event relationships and generate topological relationship data. Then, the visualization rendering engine generates a visual topological relationship graph containing version, dependencies, and trajectories based on a preset layout algorithm, which can intuitively present the application's full lifecycle status and relationships, improving the efficiency and accuracy of full lifecycle tracking. Attached Figure Description

[0023] Figure 1 This is a schematic diagram of the structure of an enterprise internal application lifecycle management system based on a microservice architecture, according to an embodiment of the present invention. Detailed Implementation

[0024] The following detailed description illustrates the specific implementation method: Please see Figure 1 As shown, it is a structural diagram of an enterprise internal application lifecycle management system based on a microservice architecture according to an embodiment of the present invention, including: The application development testing module is used to acquire enterprise application development requirement data, perform syntax structure parsing, coding standard verification, and security rule analysis on the code files in the enterprise application development requirement data through a pre-built development specification verification engine, output code compliance report, generate test cases based on the code compliance report and enterprise application development requirement data, and perform unit testing and integration testing on the test cases through a containerized testing environment, and output application deployment package that passes the test; The application submission review module is used to extract metadata information from the application deployment package through a standardized configuration parser, input the metadata information into the automated compliance detection engine to perform code security scanning and permission policy verification, output security detection results, compare the security detection results with the preset approval rule base, and output a compliant application package after passing the approval process. The application runtime monitoring module is used to collect the runtime status dataset of the compliant application package in real time through resource probes after the compliant application package is deployed to the target runtime environment. The application security delisting module is used to perform risk assessment on the runtime status dataset through a risk assessment model, generate risk assessment results, and execute permission revocation instructions, data archiving tasks, and microservice registry decoupling operations on compliant application packages whose risk assessment results meet the preset delisting conditions, and output a delisting completion status identifier. The full lifecycle tracking module is used to input version change records, service dependency data, and operation logs generated by each module into the event tracing component to build a time-series database record and output a visual topology diagram.

[0025] Specifically, the application development and testing module includes: The static code analysis unit receives enterprise application development requirement data, performs syntax structure parsing, coding standard verification, and security rule analysis on the code files in the enterprise application development requirement data through a pre-built development standard verification engine, and outputs a code compliance report containing code compliance score, standard violation items, and repair suggestions. The test execution unit is used to dynamically adjust the test coverage strategy based on the distribution characteristics of specification violations in the code compliance report, combined with enterprise application development requirement data and a pre-built test case generator. It generates a test case set that matches the code defect pattern and injects the test case set into the containerized test environment to execute unit tests and integration tests. When the unit test coverage reaches the preset coverage threshold and the integration test passes the preset business scenario verification, the application deployment package is output. The containerized test environment uses Docker or Kubernetes to implement resource isolation and version rollback mechanisms, and collects test coverage and exception stack information in real time during test execution.

[0026] Specifically, the test execution unit includes: The test configuration adaptation subunit is used to dynamically analyze the microservice topology of the containerized test environment based on the service dependency data in the code compliance report, and generate simulated service endpoints that are compatible with the target runtime environment. The test feedback optimization subunit is used to collect exception logs and performance metrics during test execution, predict potential defect patterns in the exception logs and performance metrics through machine learning models, obtain optimized test strategies, and write the optimized test strategies into the rule base of the test case generator as input parameters for the next round of test case generation.

[0027] In this embodiment, enterprise application development requirement data refers to the requirements information proposed by enterprises regarding application functions, performance, security, etc., during application development. A pre-set development specification verification engine refers to a program module that checks whether the code conforms to pre-defined development specifications and standards. A pre-set test case generator refers to a program module that automatically generates test cases based on input conditions, pre-built with certain rules and algorithms. For example, it generates test cases based on code functional modules using methods such as boundary value analysis and equivalence class partitioning. For instance, for an input age field, it generates boundary values ​​such as 0, 1, 100, and 101, as well as values ​​within the normal range, as test cases. A test coverage strategy refers to the plan and methods for determining which code parts, functionalities, or scenarios need to be tested during the testing process. Code defect patterns refer to frequently occurring errors or non-compliance patterns with similar characteristics in the code. A preset coverage threshold refers to the minimum standard value that the preset test coverage should achieve. Pre-set business scenarios refer to various situations and processes that the application may encounter in actual business operations, predefined. Service dependency data refers to information describing the mutual calls and dependencies between various services in the application. The target runtime environment refers to the environment in which the application is ultimately deployed and runs, including hardware, operating system, middleware, etc. For example, the target runtime environment could be a Windows operating system, using Tomcat as the web server, MySQL as the database, and deployed on a server with a 4-core CPU and 8GB of memory. Simulated service endpoints refer to interfaces or endpoints provided by real services in the test environment, used for interaction testing with other services. The rule base of the test case generator refers to the collection of various rules that the test case generator uses to generate test cases, including boundary value rules and equivalence class rules for input fields, and sequence rules and exception handling rules for business processes.

[0028] The pre-built development specification verification engine is determined jointly by the enterprise's internal development team, architects, and adhered industry standards (such as ISO / IEC 9126 software quality standards and OWASP secure coding standards). The pre-built test case generator is determined based on the software's functional requirements, non-functional requirements (such as performance and security), and common testing techniques and methods. Functional requirements determine which business functions and operational processes need to be tested, while non-functional requirements guide the generation of test cases targeting performance bottlenecks, security vulnerabilities, etc. Furthermore, by incorporating testing techniques such as boundary value analysis, equivalence class partitioning, scenario-based testing, and cause-effect graphing, these rules and methods are built into the test case generator, enabling it to automatically generate comprehensive and effective test cases based on different input conditions. The method for determining the preset coverage threshold is as follows: Taking into account factors such as the software's scale, complexity, importance, and project time and resource constraints, a relatively low coverage threshold, such as 70%-80%, can be set for smaller, less complex software with less stringent quality requirements. For large, complex, and critical business systems, such as financial transaction systems and aviation control systems, a higher coverage threshold, such as above 90%, is needed to ensure software quality. At the same time, project time and resources must be considered; an excessively high coverage threshold may lead to excessively long testing cycles and high costs. Therefore, a balance needs to be found between quality and cost. The method for determining the preset business scenarios is as follows: These are jointly determined by business experts, product managers, and testers. Business experts are familiar with actual business processes and various business rules, and can provide comprehensive business scenario information. Product managers analyze and supplement the business scenarios from the perspective of product functionality and user needs. Testers refine and complete the business scenarios based on their testing experience and common boundary conditions.

[0029] The process of parsing syntax, verifying coding standards, and analyzing security rules using code files in a pre-built development specification verification engine is as follows: First, the received code file undergoes syntax parsing. A lexical analyzer breaks the code down into a tokenized stream, and a syntax analyzer generates an Abstract Syntax Tree (AST) to identify syntax errors, structural anomalies, and other issues. Next, coding standard verification is performed, comparing the AST with a pre-built specification library (including naming rules, comment requirements, format standards, etc.). A rule engine matches violations, such as variable names not conforming to camelCase or function length exceeding limits. Finally, security rule analysis is conducted based on a pre-built security rule library (including rules on SQL injection risks, hard-coded sensitive information, and access control deficiencies). Through pattern matching and data flow analysis, security vulnerabilities in the code are identified, such as unfiltered user input or the use of insecure encryption algorithms. The analysis results are then summarized to generate a report containing a compliance score, violation details, and remediation suggestions.

[0030] When adjusting test coverage strategies based on code compliance reports, first analyze the distribution characteristics of violations to identify high-frequency violation modules, business scenarios with concentrated defects, and key risk points. Combined with enterprise application development requirements data, prioritize core business modules and performance-sensitive components, allocating test resources to high-risk, high-priority areas. A pre-built test case generator dynamically generates targeted test cases based on the defect patterns corresponding to violations (such as null pointer exceptions and logical judgment errors), supplementing the basic test suite. Simultaneously, adjust test depth based on violation density, adding boundary tests and stress test cases to high-violation modules to expand coverage; appropriately reducing the amount of testing in low-violation areas to ensure unit test coverage meets standards and integration tests cover key business scenarios. Finally, execute tests in a containerized environment and output deployment packages.

[0031] The process of injecting test case sets into a containerized testing environment to execute unit and integration tests is as follows: A containerized testing environment is built using Docker or Kubernetes to implement resource isolation and version rollback mechanisms. The required dependencies of the application under test, such as databases and middleware, are deployed in the container. The generated test case sets are injected into the containerized testing environment using testing tools or scripts. The testing tools can automatically send test cases to the corresponding test interfaces or modules according to the format and requirements of the test cases. In the containerized testing environment, unit tests are executed one by one according to the order and requirements of the test cases. The testing tools record the execution results of each test case, including whether it passed, execution time, etc. After completing the unit tests, integration tests are performed. The various unit modules are combined together to simulate real-world business scenarios, and integration test cases are executed. The interaction between the modules is checked for normal operation, and the data transmission is verified for accuracy. During test execution, test coverage and exception stack information are collected in real time. Test coverage information can be obtained through techniques such as code instrumentation to record which code statements have been executed; exception stack information is used to locate errors and exceptions that occur during the test.

[0032] The process of dynamically analyzing the microservice topology of the containerized testing environment based on service dependency data in the code compliance report is as follows: Service dependency data is extracted from the code compliance report to clarify the call relationships and dependency order between various services. Based on the extracted service dependency data, the microservice topology is dynamically analyzed in the containerized testing environment. A directed graph from graph theory can be used to represent the topological relationships between microservices, where each service node represents a microservice and directed edges represent the call relationships between services. Based on the analyzed microservice topology, simulated service endpoints compatible with the target runtime environment are generated. For example, if a service depends on a specific interface of another service, this interface is simulated in the testing environment and returns preset data to ensure that the service under test can be called and run normally.

[0033] The process of predicting potential defect patterns in abnormal logs and performance metrics using a machine learning model is as follows: Collect historical abnormal logs and performance metric data, and invite experts to label whether potential defect patterns exist (1 for presence, 0 for absence). Clean the data, removing noise and missing values; segment and vectorize the text logs (e.g., using TF-IDF); standardize the performance metrics. Extract key features, such as the frequency of error types in the logs and the fluctuation range of performance metrics. Divide the data into training and test sets in a 7:3 ratio. Use a random forest classifier. Train the model using the training set data, setting the number of trees to 100 and the maximum depth to 10. Use the test set data for prediction; accuracy = number of correctly predicted samples / total number of samples. If 85 samples are correctly predicted out of 100 samples, the accuracy is 85%. Recall = number of correctly predicted samples / actual number of samples. If there are 90 actual defects and 80 are predicted, the recall is 80 / 90 ≈ 88.9%. If the accuracy does not meet the requirements (e.g., setting a threshold of 90%), adjust the model parameters (e.g., increase the number of trees) or add features, and retrain and evaluate. In actual testing, input real-time data, the model predicts potential defect patterns and outputs results.

[0034] Specifically, the application submission review module includes: The metadata parsing unit is used to input the application deployment package into the standardized configuration parser to extract metadata information and output a structured metadata set. The metadata information includes application dependency library versions, service interface definitions and configuration parameters. The compliance detection execution unit is used to input the structured metadata set into the automated compliance detection engine. It performs a security scan on the structured metadata set through the pre-built code security rule base and permission policy verification module, and outputs a security detection result set containing the defect location and risk level. The security scan includes vulnerability pattern matching and sensitive permission call path analysis. The approval process decision unit is used to match and compare the security detection result set with the threshold conditions and approval strategies in the preset approval rule base. When the detection result meets the preset pass conditions, it triggers the electronic approval process generation instruction and outputs a compliant application package containing the approval status identifier after the approval process is passed.

[0035] Specifically, in the application runtime monitoring module, the resource probe includes a container metrics collector and a call chain tracer. The container metrics collector obtains resource consumption metrics in real time, and the call chain tracer obtains the frequency of abnormal calls between microservices through the service mesh component.

[0036] In this embodiment, the standardized configuration parser refers to a tool or module used to parse application deployment packages, extract metadata information, and transform it into a structured metadata set. The automated compliance detection engine refers to a system or module that uses pre-defined rules and policies to automatically scan the input structured metadata set for security vulnerabilities and compliance issues. The pre-defined code security rule base refers to a set of pre-defined code security rules used to detect potential security vulnerabilities and risks in code or metadata. The permission policy verification module refers to a module used to verify whether an application or system complies with pre-defined policies regarding permission management, ensuring that the application has legitimate permissions when accessing resources or performing operations. The pre-defined approval rule base refers to a set of rules and conditions used to determine whether an application deployment package passes approval. The threshold conditions in the pre-defined approval rule base refer to numerical or state limits used to define whether specific approval requirements are met. Approval strategy refers to the approach used to determine the approval process and outcome of application deployment packages based on different security test results and other relevant factors. For example, an approval strategy could be: "Application packages with fully compliant security test results are automatically approved for deployment; application packages with a few low-risk vulnerabilities that do not affect the main functions enter a manual review process, where relevant personnel decide whether to approve them; application packages with high-risk vulnerabilities are directly rejected for approval." Preset approval conditions refer to the explicitly defined conditions that an application deployment package must meet to pass approval, as specified in the preset approval rule base.

[0037] The pre-built code security rule base is determined based on industry standards: referencing international and domestic security standards, such as the security guidelines published by OWASP (Open Web Application Security Project) and the national information security level protection system, the code security requirements are translated into specific rules and incorporated into the rule base. The pre-built approval rule base is determined based on business needs and risk tolerance: security approval requirements for different types of applications are determined according to the enterprise's business characteristics and risk tolerance. For example, approval rules will be stricter for applications involving core business and sensitive data; while approval rules may be relatively lenient for some internal tool applications. The threshold conditions in the pre-built approval rule base are determined based on security assessments and testing: through security assessments and tests on a large number of applications, the impact of the number and severity of different types of vulnerabilities on system security is analyzed to determine reasonable threshold conditions. For example, if testing shows that when the number of high-risk vulnerabilities exceeds one, the security risk faced by the system increases significantly, the threshold for the number of high-risk vulnerabilities can be set to 0. The determination of preset pass conditions is based on comprehensive security, business and compliance factors: Preset pass conditions need to take into account security test results, business continuity requirements and compliance requirements. For example, while ensuring that the security test results meet certain security standards, it is also necessary to consider whether the application's functions are complete, whether they meet business needs, and whether they comply with relevant laws and regulations and policy requirements.

[0038] The automated compliance detection engine compares the application dependency library version information extracted from the structured metadata set with the known vulnerability database in the pre-built code security rule base. If a known security vulnerability is found in a dependency library version, detailed information about the vulnerability is recorded, including the vulnerability name, severity, and scope of impact. Based on the code style rules in the pre-built code security rule base, it checks whether the code related to service interface definitions and configuration parameters in the metadata conforms to secure coding standards. For example, it checks whether interface parameters have effective input validation to prevent SQL injection and cross-site scripting (XSS) attacks; and whether configuration parameters contain sensitive information that has not been encrypted. The permission policy verification module checks whether the application has legitimate permissions when accessing system resources (such as databases, file systems, network services, etc.). Based on the application roles and permission information recorded in the metadata, it compares them with preset permission policies to ensure that the application can only access its authorized resources. It checks whether the application has the corresponding permissions when performing various operations (such as data modification, deletion, and querying). For example, it verifies whether the application is performing sensitive operations with the correct user identity to prevent unauthorized access and operations.

[0039] Key information, such as vulnerability type, number of vulnerabilities, and risk level, is extracted from security test results and formatted for easy comparison. The extracted vulnerability count and other information are then compared one by one with threshold conditions in a pre-defined approval rule base. For example, the number of high-risk vulnerabilities is compared with a pre-defined high-risk vulnerability threshold (e.g., 0), and the number of medium-risk vulnerabilities is compared with a pre-defined medium-risk vulnerability threshold (e.g., 3). Based on the threshold comparison results and the approval policies in the pre-defined approval rule base, the approval process and result for the application deployment package are determined. For example, if the number of high-risk vulnerabilities is 0 and the number of medium-risk vulnerabilities does not exceed 3, approval may be automatically granted according to the approval policy; if high-risk vulnerabilities exist or the number of medium-risk vulnerabilities exceeds the threshold, the application will proceed to a manual approval process or be rejected directly according to the policy. Service meshes (such as Istio and Linkerd) are infrastructure layers used to manage communication between microservices. They can provide microservices with service discovery, load balancing, traffic management, and secure communication functions without modifying application code. Service mesh intercepts and processes inter-microservice communication by deploying a sidecar alongside each microservice instance. When microservice A initiates a call to microservice B, the call chain tracer records the call start timestamp in the service mesh's sidecar. When microservice B completes processing and returns a response, the sidecar records the call end timestamp. By calculating the difference between the call end timestamp and the call start timestamp, the latency of the call is obtained. The call chain tracer can aggregate and analyze this latency data to generate a time-series set of resource metrics for monitoring the performance of inter-microservice calls. The service mesh's sidecar can identify error status codes returned during inter-microservice calls (e.g., 5xx series indicating internal server errors). When the sidecar detects an error status code, it marks the call as an erroneous call. The call chain tracer counts the number of erroneous calls and the total number of calls within a certain time window (e.g., 1 minute), and calculates the error rate of inter-microservice calls by calculating the ratio of erroneous calls to the total number of calls. This error rate data can be combined with distributed call topology data to help developers quickly locate and resolve problems in inter-microservice communication.

[0040] Specifically, the application security removal module includes: The risk assessment unit is used to analyze the resource consumption indicators, abnormal call frequency and service dependency data in the operation status dataset through the risk assessment model, and generate risk assessment results containing risk level identifiers. The delisting execution unit is used to execute role-based permission revoke instructions on compliant application packages when the delisting decision information in the risk assessment results meets the preset delisting conditions. It also triggers a data archiving task to store the operation logs and configuration data of the compliant application packages, and sends a service instance decoupling request to the microservice registry center. Finally, it outputs a delisting completion status identifier containing a delisting timestamp and resource release status. The service instance decoupling request includes a service instance ID cancellation instruction and a configuration metadata clearing instruction.

[0041] In this embodiment, the preset delisting conditions are a series of pre-set standards or rules used by the risk assessment unit to determine whether to delist a compliant application package after generating the risk assessment results. These conditions are based on the delisting decision information in the risk assessment results. The delisting execution unit will only initiate the delisting process when the delisting decision information meets these conditions. For example, the preset delisting conditions can be set as follows: when the risk level in the risk assessment results is marked as "high risk" and the frequency of abnormal calls exceeds 200% of the average frequency of abnormal calls in the past month, the preset delisting conditions are deemed to be met. Alternatively, when resource consumption indicators (such as CPU utilization and memory usage) continuously exceed a preset threshold for a certain period of time (such as 1 hour), and service dependency data indicates that the application package is too closely dependent on other critical services, which may cause systemic risks, the preset delisting conditions are also considered to be met.

[0042] The service instance ID deregistration command is an instruction sent by the delisting execution unit to the microservice registry. Its purpose is to remove the service instance ID corresponding to a specific compliant application package from the registry of the microservice registry. In a microservice architecture, each running service instance is registered in the registry so that other services can discover and call it. When an application package needs to be delisted, its related service instances need to be delisted from the registry. This prevents other services from finding and calling these soon-to-be-delisted service instances through the registry, thus achieving decoupling of service instances. For example, suppose there is a compliant application package named "Order Service" with three service instances registered in the microservice registry, with service instance IDs "order-service-1", "order-service-2", and "order-service-3". When the preset delisting conditions are met and the "Order Service" application package needs to be delisted, the delisting execution unit will send a service instance ID deregistration command to the microservice registry, explicitly specifying that these three service instance IDs should be delisted. After receiving the instruction, the registry center will remove these three service instances from the registry. When other services query "Order Service", they will no longer be able to obtain information about these deregistered service instances.

[0043] The configuration metadata clearing command is also a command sent by the delisting execution unit to the microservice registry center to clear configuration metadata related to a specific compliant application package. Configuration metadata contains various configuration information of a service instance, such as the service's port number, service address, information about other dependent services, and environment variables. This configuration metadata plays a crucial role during service operation, but when a service instance is delisted, this configuration information no longer needs to be retained in the registry center. To avoid occupying storage space and to prevent potential configuration conflicts or misuse in the future, it needs to be cleared. For example, continuing with the "Order Service" example above, when the configuration metadata clearing command is sent, the registry center will delete these configuration metadata related to the "Order Service" from storage, ensuring that only the configuration information of currently running, valid services is retained in the registry center.

[0044] By analyzing resource consumption metrics, abnormal call frequency, and service dependency data in the operational status dataset using a risk assessment model, a risk assessment result containing risk level identifiers is generated. This can be achieved as follows: Resource consumption metrics (such as CPU / memory utilization), abnormal call frequency (number of abnormal requests per unit time), and service dependencies (call chain complexity and critical node dependencies) are normalized to eliminate dimensional differences and ensure data comparability. Weights are set for each metric based on the business scenario (e.g., 40% for resource consumption, 30% for abnormal calls, and 30% for dependencies) to reflect the impact of different factors on risk. Based on the standardized data and weights, a comprehensive risk score is calculated using weighted summation or tiered scoring rules (e.g., setting threshold ranges for corresponding scores). For example, points are deducted when resource consumption exceeds a threshold, and higher abnormal call frequencies result in greater point deductions. Levels are divided according to the scoring range (e.g., low risk [0-30], medium risk [31-70], high risk [71-100]), with a dynamic adjustment mechanism (e.g., temporarily increasing weights when historical abnormal call frequencies surge). The rating is linked to the level identifier to form a risk assessment result (such as JSON format), which can be used for subsequent dynamic comparison with the delisting threshold.

[0045] Specifically, the risk assessment unit includes: The risk assessment model construction subunit is used to acquire historical operation status data and corresponding risk labeling information, form historical operation status data samples, divide the historical operation status data samples into data training set and data validation set, input the data training set into the convolutional neural network model for training, adjust the model parameters of the convolutional neural network model through the data validation set, and output the convolutional neural network model that meets the preset accuracy as the risk assessment model. A risk analysis subunit, which is used to input the operation status data set into a risk assessment model to perform multi-dimensional correlation analysis on resource consumption indicators, abnormal call frequencies, and service dependency relationship data, and generate a risk assessment result containing a risk level identifier in combination with a preset risk level classification rule.

[0046] In this embodiment, the preset accuracy rate refers to the minimum accuracy threshold set when evaluating the model performance through a validation set during the model training stage. For example, if the preset accuracy rate is 95%, it is required that the prediction accuracy rate of the model on the validation set must reach or exceed 95% to be considered qualified. If the standard is not met, it is necessary to retrain by adjusting model parameters (such as learning rate, network structure, regularization strength, etc.) or increasing training data until the threshold is satisfied. Determination method: Driven by business requirements: Set according to the severity of the consequences of risk assessment (e.g., financial systems require ≥99%, and general monitoring systems can be relaxed to 90%). Historical benchmark reference: Refer to the performance of mature models in similar scenarios. Experimental tuning: Test the impact of different thresholds on the model generalization ability through cross-validation and select a balance point.

[0047] The preset risk level classification rule refers to a quantization standard that maps multi-dimensional risk indicators (such as resource consumption, abnormal call frequency, service dependency relationship) to discrete risk levels. For example: High risk: Resource consumption ≥90% and abnormal call frequency ≥10 times / minute or critical service dependency interruption; Medium risk: Resource consumption 70%-90% or abnormal call 5-10 times / minute; Low risk: Resource consumption <70% and abnormal call <5 times / minute. Determination method: Expert experience method: Domain experts define rules based on historical accident analysis (such as "system response latency increases significantly when resource occupancy exceeds 85%"). Data-driven method: Group historical data through clustering algorithms (such as K-means), count the failure probability of each group, and set thresholds (such as failure rate of high-risk group >30%). Dynamic adjustment: Optimize the rules according to the feedback of real-time monitoring data (such as fine-tuning if the false alarm rate is too high under a certain threshold).

[0048] In the risk assessment model construction subunit, historical operational status data (such as CPU usage, memory consumption, and number of API calls) and corresponding risk labeling information (such as manually labeled "high risk," "medium risk," and "low risk") are first collected from the monitoring system or log platform to form a structured sample set. This set is then divided into training and validation sets in a ratio (e.g., 7:3) to ensure balanced data distribution. The Convolutional Neural Network (CNN) model takes the training set as input, extracts spatiotemporal features (such as fluctuation patterns in resource consumption) through convolutional layers, and learns the mapping relationship between risk and features through fully connected layers. During training, accuracy and recall are calculated using the validation set. If the preset accuracy (e.g., 95%) is not achieved, hyperparameters (such as learning rate and batch size) are adjusted through grid search or regularization techniques are introduced to prevent overfitting until the model performance meets the target, ultimately outputting the risk assessment model.

[0049] In the risk analysis subunit, real-time operational status data is input into the trained model. The risk assessment model first extracts features from resource consumption indicators (such as instantaneous CPU usage), abnormal call frequency (such as the number of erroneous requests per unit time), and service dependencies (such as call chain topology). Then, it uses a multi-head attention mechanism to correlate and analyze multi-dimensional data (such as high resource usage accompanied by abnormal calls may exacerbate the risk). Combined with preset risk level rules (such as "high risk" requiring resources ≥90% and abnormal calls ≥10 times / minute), the risk assessment model outputs results with level labels (such as "Order Service: High Risk, Dependent on Payment Service Timeout"). Rules can be determined through expert experience (such as business continuity requirements) or clustering algorithms (such as K-means grouping historical failure data) and support dynamic adjustment to adapt to system changes. The final result can trigger alarms or automated responses (such as elastic scaling).

[0050] Specifically, the full lifecycle tracking module includes: The data integration unit is used to obtain version change records from the application development and testing module, approval process logs from the application listing review module, running status datasets from the application operation monitoring module, and risk assessment results and listing completion status indicators from the application security delisting module through the event tracing component, forming structured event objects, and storing the structured event objects as time series database records through the time series database write interface; The visualization processing unit is used to perform association analysis on the event association identifiers in the time series database records using graph algorithms, generate topological relationship data containing nodes and edges, and input the topological relationship data into the visualization rendering engine to generate a visualized topological relationship graph containing application version, service dependency and operation trajectory based on a preset layout algorithm.

[0051] In this embodiment, the event tracing component is an intermediate component used to obtain specific types of data (such as version change records, approval process logs, etc.) from different data sources (such as application development and testing modules, application listing and review modules, etc.) and convert them into a unified format (structured event objects). The visualization rendering engine is a software component or system capable of converting data (such as topological relationship data) into visual graphics (such as topological relationship graphs). The preset layout algorithm is a predefined algorithm in the visualization rendering engine used to determine the position and arrangement of each element (such as nodes and edges) in the visual graphics, resulting in graphics with good readability and aesthetics. The method for determining the preset layout algorithm is as follows: Analyze the type, quantity, and complexity of the data. For example, if there is a hierarchical structure between nodes in the data, a hierarchical layout algorithm may be selected; if the relationship between nodes is a network, a force-directed layout algorithm may be selected. Display requirements: Consider the user's needs for graphic display, such as whether certain nodes or relationships need to be highlighted, or whether specific patterns or trends need to be displayed. For example, if it is necessary to highlight key application version nodes, a layout algorithm that can place key nodes in prominent positions can be selected. Readability and aesthetics: Ensure that the generated graphics are easy to read and understand, and have good visual effects. The effectiveness of different layout algorithms can be evaluated through experiments and user feedback to select the optimal algorithm.

[0052] Storing structured event objects as time-series database records via the time-series database's write interface involves the following steps: First, the data integration unit needs to establish a connection with the time-series database. This typically involves configuring database connection parameters such as host address, port number, username, and password to ensure successful database access. Although the structured event objects are already structured data, they may require additional transformations based on the time-series database's requirements. For example, some time-series databases may require data to be transmitted in a specific format (such as CSV, JSON Lines, etc.) or have specific requirements regarding the type and name of data fields. The data integration unit then calls the write interface provided by the time-series database, passing the transformed structured event objects as parameters. The write interface is responsible for storing the data according to the time-series database's internal storage format, typically organizing and indexing the data in chronological order for efficient subsequent querying and analysis. The data integration unit receives the response from the write interface and determines whether the data was successfully written to the database based on the response. If the write fails, error handling may be necessary, such as retrying the write operation or logging error information for later troubleshooting.

[0053] Association analysis of event association markers in time-series database records using graph algorithms includes: extracting records containing event association markers from the time-series database. These records may contain association information between different events, such as the association between application version change events and approval process events, or the association between service dependency events and operation trajectory events. The extracted event association markers are then used as nodes and edges to construct a graph model. For example, if there is a relationship between two events, an edge is drawn between their corresponding nodes. In this way, the records in the time-series database are transformed into a graph structure, where nodes represent events and edges represent the associations between events. A suitable graph algorithm is then selected to analyze the constructed graph model. Common graph algorithms include Depth-First Search (DFS), Breadth-First Search (BFS), shortest path algorithms, and connected component algorithms. For example, if it is necessary to find all other events associated with a specific application version event, a DFS or BFS algorithm can be used to traverse the graph and find all nodes connected to that node. Based on the output of the graph algorithm, the association relationships and patterns between events are analyzed. For example, by analyzing connected components, we can identify which events belong to the same group; by analyzing shortest paths, we can find the shortest path between events, and so on.

[0054] Inputting topology data into the visualization rendering engine generates a visualized topology graph containing application versions, service dependencies, and operation trajectories based on a preset layout algorithm. This includes ensuring the topology data is organized and formatted according to the visualization rendering engine's requirements. Topology data typically includes node and edge information. Node information may include node ID, node type (e.g., application version, service, operation), and node attributes (e.g., version number, service name). Edge information may include edge ID, source node ID, target node ID, and edge type (e.g., dependency, operation trajectory). Inputting the prepared topology data into the visualization rendering engine can be done by calling the engine's provided interface or using the engine's supported data import function. For example, if the visualization rendering engine supports JSON format data input, the topology data can be converted to JSON format and then passed to the engine via the interface. Selecting a suitable preset layout algorithm within the visualization rendering engine. Based on the characteristics of the topology data and display requirements, select the layout algorithm that best displays the relationships between the data. For example, if you need to display the hierarchical structure and service dependencies between application versions, you can choose a hierarchical layout algorithm; if you need to display the complex relationships between all nodes, you can choose a force-directed layout algorithm. The visualization rendering engine calculates the position of each node and the drawing method of each edge based on the input topological relationship data and the selected preset layout algorithm. It then uses its built-in graphics drawing functions to generate a visualized topological relationship diagram. The diagram clearly displays information such as application version, service dependencies, and operation trajectories. The styles of nodes and edges (such as color, shape, and size) can be set according to preset rules to enhance the readability and aesthetics of the diagram. The generated visualized topological relationship diagram is displayed on the user interface, allowing users to intuitively view and analyze the relationships between application versions, service dependencies, and operation trajectories. Users can further explore the data in the diagram through interactive functions (such as zooming, panning, and clicking on nodes to view detailed information).

[0055] Taking the implementation of an enterprise to-do application as an example, after obtaining the application requirements document and code files, the code is first parsed using the pre-built specification verification engine of the application development and testing module (e.g., checking whether Java method declarations meet JDK version requirements), verified for coding standards (e.g., verifying whether variable naming conforms to camelCase rules), and analyzed for security rules (e.g., detecting SQL injection vulnerabilities). A compliance report containing 200+ test results is generated. Based on the issues in the report (e.g., unhandled null pointer exceptions), test cases covering core scenarios such as login, task creation, and deadline reminders are automatically generated. Unit tests (e.g., verifying the parameter boundaries of the task list pagination query interface) and integration tests (e.g., testing the transaction consistency of message queues and databases) are executed in a Docker container cluster. Finally, a WAR deployment package that passes the tests is output. Upon entering the application review stage, the standardized configuration parser extracts metadata such as the application version (1.2.0), dependent components (Spring Boot 2.7.5), and API interface list (15 interfaces including / tasks / create) from the deployment package. The automated compliance detection engine calls OWASP ZAP to perform vulnerability scanning (e.g., discovering the XSS vulnerability CVE-2023-12345), and simultaneously verifies whether the permission policy conforms to the RBAC model (e.g., verifying whether ordinary users have unauthorized access to management interfaces). After the detection results are compared with the preset approval rule base (containing 20 rules such as "reject if the number of high-risk vulnerabilities ≥ 3") and pass the verification, a compliant application package containing a digital signature is output. After deployment to the Kubernetes production environment, the resource probe collects runtime indicators such as JVM memory usage and thread pool status via the JMX protocol, and records user operation logs in conjunction with the ELK stack (e.g., a user created 5 to-do tasks at 10:00). After the application has been running for 6 months, the risk assessment model analyzes historical data and finds that the standard deviation of the interface response time exceeds the threshold (suddenly increasing from 50ms to 300ms), triggering the delisting process: The system first revokes database connection permissions, archives business data to an S3 storage bucket via a Cron task, and finally deregisters the service instance in the Eureka registry, ultimately outputting a delisting timestamp and the operator's status identifier. The full lifecycle tracking module inputs version iteration records from the development phase (such as change points from 1.1.0 to 1.2.0), service dependencies (the application depends on the user center service), and operation logs (including test pass times, approver information, etc.) into the event tracing component to build a time-series-based causal relationship chain, displaying the complete topology diagram of the application from development to delisting in a visual interface.

[0056] The above are merely embodiments of the present invention. Commonly known structures and characteristics are not described in detail here. Those skilled in the art are aware of all common technical knowledge in the field prior to the application date or priority date, are aware of all existing technologies in that field, and have the ability to apply conventional experimental methods prior to that date. Those skilled in the art can, under the guidance of this application, improve and implement this solution in combination with their own capabilities. Some typical known structures or methods should not be obstacles for those skilled in the art to implement this application. It should be noted that those skilled in the art can make several modifications and improvements without departing from the structure of the present invention. These should also be considered within the scope of protection of the present invention, and will not affect the effectiveness of the implementation of the present invention or the practicality of the patent. The scope of protection claimed in this application should be determined by the content of its claims, and the specific embodiments described in the specification can be used to interpret the content of the claims.

Claims

1. A microservice-based enterprise internal application lifecycle management system, characterized in that: include: The application development testing module is used to acquire enterprise application development requirement data, perform syntax structure parsing, coding standard verification, and security rule analysis on the code files in the enterprise application development requirement data through a pre-built development specification verification engine, output code compliance report, generate test cases based on the code compliance report and enterprise application development requirement data, and perform unit testing and integration testing on the test cases through a containerized testing environment, and output application deployment package that passes the test; The application submission review module is used to extract metadata information from the application deployment package through a standardized configuration parser, input the metadata information into the automated compliance detection engine to perform code security scanning and permission policy verification, output security detection results, compare the security detection results with the preset approval rule base, and output a compliant application package after passing the approval process. The application runtime monitoring module is used to collect the runtime status dataset of the compliant application package in real time through resource probes after the compliant application package is deployed to the target runtime environment. The application security delisting module is used to perform risk assessment on the runtime status dataset through a risk assessment model, generate risk assessment results, and execute permission revocation instructions, data archiving tasks, and microservice registry decoupling operations on compliant application packages whose risk assessment results meet the preset delisting conditions, and output a delisting completion status identifier. The full lifecycle tracking module is used to input version change records, service dependency data, and operation logs generated by each module into the event tracing component to build a time-series database record and output a visual topology diagram.

2. The enterprise internal application lifecycle management system based on microservice architecture according to claim 1, characterized in that: The application development and testing module includes: The static code analysis unit receives enterprise application development requirement data, performs syntax structure parsing, coding standard verification, and security rule analysis on the code files in the enterprise application development requirement data through a pre-built development standard verification engine, and outputs a code compliance report containing code compliance score, standard violation items, and repair suggestions. The test execution unit is used to dynamically adjust the test coverage strategy based on the distribution characteristics of specification violations in the code compliance report, combined with enterprise application development requirement data and a pre-built test case generator, to generate a test case set that matches the code defect pattern. The test case set is then injected into the containerized test environment to execute unit tests and integration tests. When the unit test coverage reaches a preset coverage threshold and the integration test passes the preset business scenario verification, the application deployment package is output. The containerized test environment uses Docker or Kubernetes to implement resource isolation and version rollback mechanisms, and collects test coverage and exception stack information in real time during test execution.

3. The enterprise internal application lifecycle management system based on microservice architecture according to claim 2, characterized in that: The test execution unit includes: The test configuration adaptation subunit is used to dynamically analyze the microservice topology of the containerized test environment based on the service dependency data in the code compliance report, and generate simulated service endpoints that are compatible with the target runtime environment. The test feedback optimization subunit is used to collect exception logs and performance metrics during test execution, predict potential defect patterns in the exception logs and performance metrics through machine learning models, obtain optimized test strategies, and write the optimized test strategies into the rule base of the test case generator as input parameters for the next round of test case generation.

4. The enterprise internal application lifecycle management system based on microservice architecture according to claim 1, characterized in that: The application submission review module includes: The metadata parsing unit is used to input the application deployment package into the standardized configuration parser to extract metadata information and output a structured metadata set. The metadata information includes application dependency library versions, service interface definitions and configuration parameters. The compliance detection execution unit is used to input the structured metadata set into the automated compliance detection engine, perform a security scan on the structured metadata set through a pre-built code security rule base and permission policy verification module, and output a security detection result set containing defect locations and risk levels. The security scan includes vulnerability pattern matching and sensitive permission call path analysis. The approval process decision unit is used to match and compare the security detection result set with the threshold conditions and approval strategies in the preset approval rule base. When the detection result meets the preset pass conditions, it triggers the electronic approval process generation instruction and outputs a compliant application package containing the approval status identifier after the approval process is passed.

5. The enterprise internal application lifecycle management system based on microservice architecture according to claim 1, characterized in that: In the application operation monitoring module, the resource probe includes a container metric collector and a call chain tracer. The container metric collector obtains resource consumption metrics in real time, and the call chain tracer obtains the abnormal call frequency between microservices through the service mesh component.

6. The enterprise internal application lifecycle management system based on microservice architecture according to claim 1, characterized in that: The application security removal module includes: The risk assessment unit is used to analyze the resource consumption indicators, abnormal call frequency and service dependency data in the operation status dataset through the risk assessment model, and generate a risk assessment result containing risk level identifiers. The delisting execution unit is used to execute a role-based permission revoke instruction on the compliant application package when the delisting decision information in the risk assessment results meets the preset delisting conditions, and to trigger a data archiving task to store the operation logs and configuration data of the compliant application package, and send a service instance decoupling request to the microservice registry center. Finally, it outputs a delisting completion status identifier containing a delisting timestamp and resource release status. The service instance decoupling request includes a service instance ID cancellation instruction and a configuration metadata clearing instruction.

7. The enterprise internal application lifecycle management system based on microservice architecture according to claim 6, characterized in that: The risk assessment unit includes: The risk assessment model construction subunit is used to acquire historical operation status data and corresponding risk labeling information, form historical operation status data samples, divide the historical operation status data samples into data training set and data validation set, input the data training set into the convolutional neural network model for training, adjust the model parameters of the convolutional neural network model through the data validation set, and output the convolutional neural network model that meets the preset accuracy as the risk assessment model. The risk analysis subunit is used to input the runtime status dataset into the risk assessment model to perform multi-dimensional correlation analysis on resource consumption indicators, abnormal call frequency and service dependency data, and generate risk assessment results containing risk level identifiers in combination with preset risk level classification rules.

8. The enterprise internal application lifecycle management system based on microservice architecture according to claim 1, characterized in that: The full lifecycle tracking module includes: The data integration unit is used to obtain version change records from the application development and testing module, approval process logs from the application listing review module, running status datasets from the application operation monitoring module, and risk assessment results and listing completion status indicators from the application security delisting module through the event tracing component, forming structured event objects, and storing the structured event objects as time series database records through the time series database write interface; The visualization processing unit is used to perform association analysis on the event association identifiers in the time series database records using graph algorithms, generate topological relationship data containing nodes and edges, and input the topological relationship data into the visualization rendering engine to generate a visualized topological relationship graph containing application version, service dependency and operation trajectory based on a preset layout algorithm.

Images