Service-oriented distributed resource automatic extraction and packaging method and server

Abstract

The application discloses a service-oriented distributed resource automatic extraction and packaging method and a server, relates to the technical field of microservices, and comprises the following steps: querying a service packaging task state according to a service identifier; determining whether there is an executing packaging task; if not, performing runtime dynamic dependency analysis on a target service corresponding to the service identifier, and constructing a service dependency graph; detecting a circular dependency based on the service dependency graph, determining a resource acquisition range if the circular dependency exists; acquiring multi-dimensional service resources from multiple distributed data sources; performing resource aggregation processing on the multi-dimensional service resources, generating a service basic information file, packaging the multi-dimensional service resources and the service basic information file, and generating a service resource package; uploading the service resource package to a distributed service management platform for deployment, and creating an asynchronous task. The application can effectively capture runtime dynamically generated dependency relationships, reduce error rates and improve efficiency.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the technical field of micro-service, and particularly relates to a service-oriented distributed resource automatic extraction and packaging method and a server. BACKGROUND

[0002] With the deepening of enterprise digital transformation, micro-service architecture has become the mainstream mode of modern software system design. In the micro-service architecture, the traditional monolithic application is split into multiple independent, loosely coupled service units, and each service focuses on a specific business function.

[0003] In the micro-service ecosystem, a complete business service is not isolated, but is organically combined by multiple heterogeneous resources distributed in different system levels and different storage locations. These resource types are diverse and widely distributed: API definition resources are usually stored in API gateways or service registries; data source configuration resources may be scattered in configuration management systems, database connection pools or environment variables; business logic script resources are distributed in code repositories, function computing platforms or rule engines; ETL process resources may exist in data integration platforms, workflow engines or batch processing systems.

[0004] This distributed resource management mode provides good decoupling and flexibility in service runtime, but brings significant operational complexity in the service lifecycle management process, especially in service migration, version archiving, disaster recovery, environment replication and other scenarios. During the process of digital transformation, enterprises often need to migrate services between different environments, or regularly back up critical services to ensure business continuity and data security.

[0005] The traditional service resource management method mainly relies on static dependency analysis to identify service dependencies by parsing configuration files or code comments. This method cannot capture runtime dynamically generated dependencies and is prone to miss implicit dependent resources, resulting in high error rates and low efficiency.

[0006] Currently, there is no effective way to solve the above problems. SUMMARY

[0007] The embodiment of the present application provides a service-oriented distributed resource automatic extraction and packaging method and a server, which can effectively capture runtime dynamically generated dependencies, reduce error rates and improve efficiency.

[0008] To achieve the above purpose, the embodiments of the present application adopt the following technical solutions:

[0009] In a first aspect, a service-oriented distributed resource automatic extraction and packaging method is provided, applied to a server, wherein the server is deployed with a distributed service management platform, and the method comprises the following steps:

[0010] In response to receiving a service packaging request, querying a service packaging task state according to a service identifier in the service packaging request;

[0011] Determining whether there is an executing packaging task according to the service packaging task state;

[0012] In the case where there is no executing packaging task, performing runtime dynamic dependency analysis on a target service corresponding to the service identifier, and constructing a service dependency graph;

[0013] Detecting a circular dependency based on the service dependency graph, and determining a resource acquisition range through a dependency decoupling strategy in the case where there is a circular dependency;

[0014] Acquiring multi-dimensional service resources from multiple distributed data sources according to the service identifier and the resource acquisition range, wherein the multi-dimensional service resources comprise API definition resources, data source configuration resources, business logic script resources and ETL process resources;

[0015] Performing resource aggregation processing on the multi-dimensional service resources, generating a service basic information file, and packaging the multi-dimensional service resources and the service basic information file to generate a service resource package;

[0016] Uploading the service resource package to the distributed service management platform for deployment, and creating an asynchronous task to monitor the execution state of the deployment processing.

[0017] In a possible implementation manner of the first aspect, the acquiring of the multi-dimensional service resources from the multiple distributed data sources according to the service identifier and the resource acquisition range comprises the following steps:

[0018] Querying service information according to the service identifier and the resource acquisition range to acquire service code and service version information;

[0019] Querying a list of API interface information that has been put on the shelf according to the service identifier, the resource acquisition range and a preset on-shelf state identifier to obtain the API definition resources;

[0020] Querying a list of associated data source configuration information according to the service identifier and the resource acquisition range to obtain the data source configuration resources;

[0021] According to the service identifier, the resource acquisition range and the API interface information list, business logic design data is extracted from a target database, and the business logic design data is converted into an SQL script file to obtain the business logic script resource.

[0022] In a possible implementation of the first aspect, the business logic script resource is obtained by extracting business logic design data from a target database according to the service identifier, the resource acquisition range and the API interface information list, and converting the business logic design data into an SQL script file.

[0023] According to a preset API design enumeration type list, a target database table name list is determined.

[0024] For each database table name in the target database table name list, corresponding table structure information is queried to obtain a column name list.

[0025] According to an API identifier in the API interface information list, a query condition parameter is constructed, and a query operation is performed in a corresponding database table according to the query condition parameter to obtain the business logic design data.

[0026] The business logic design data is parsed into an INSERT type SQL statement, and the SQL statement is written into an SQL script file to obtain the business logic script resource.

[0027] In a possible implementation of the first aspect, the target database table name list is determined according to the preset API design enumeration type list, and the method comprises the following steps.

[0028] A database table name is extracted from the API design enumeration type list, and a table type corresponding to the database table name comprises a data source configuration table, an API parameter pool table, an API construction step table, an API construction version table, an HTTP interface table, an SQL interface table and a WebService interface table.

[0029] According to an interface type in the API interface information list, a target database table name list is filtered from the database table name.

[0030] In a possible implementation of the first aspect, the multi-dimensional service resource is obtained from a plurality of distributed data sources according to the service identifier and the resource acquisition range, and the method further comprises the following steps.

[0031] According to a preset ETL data extraction configuration switch, it is determined whether to perform ETL process resource extraction.

[0032] In a case where the ETL data extraction configuration switch is in an open state, ETL system information list associated with the service identifier and the resource acquisition range is queried according to the service identifier and the resource acquisition range;

[0033] A batch export interface of the ETL management platform is called through an HTTP request, and ETL process configuration files are acquired according to a system identifier list in the ETL system information list;

[0034] The ETL process configuration files are saved to a preset resource directory path, and the ETL process resources are obtained.

[0035] In a possible implementation manner of the first aspect, the multi-dimensional service resources are aggregated to generate a service basic information file, and the multi-dimensional service resources and the service basic information file are packaged to generate a service resource package, including:

[0036] According to the API definition resource and the data source configuration resource, a service construction file is exported to a temporary directory path;

[0037] The business logic script resource is copied to the temporary directory path;

[0038] A service basic information file in an XML format is created, and the service basic information file contains service code information;

[0039] The service basic information file is saved to the temporary directory path;

[0040] The ETL process resources are saved to the temporary directory path;

[0041] All files in the temporary directory path are compressed to generate a service resource package through a preset compression algorithm, and the temporary directory path is deleted.

[0042] In a possible implementation manner of the first aspect, the service resource package is uploaded to a distributed service management platform for deployment, including:

[0043] According to the service identifier and the resource acquisition range, a product identifier and a project identifier associated with the service identifier and the resource acquisition range are queried;

[0044] An upload service address of the distributed service management platform is acquired;

[0045] An upload parameter of a packaging type containing the product identifier, the project identifier and the service resource package is constructed;

[0046] The service resource package and the upload parameter are sent to the distributed service management platform;

[0047] Analyzing the response result returned by the distributed service management platform to obtain a deployment task identifier.

[0048] In a possible implementation of the first aspect, the runtime dynamic dependency analysis on the target service corresponding to the service identifier is performed to construct a service dependency graph, including:

[0049] Determining a key call point of the target service;

[0050] Injecting a dependency tracking probe at the key call point and constructing a service dependency graph to record the dependency relationship between services.

[0051] In a possible implementation of the first aspect, the service dependency graph is used to detect a circular dependency, and in the case where the circular dependency exists, a resource acquisition range is determined through a dependency decoupling strategy, including:

[0052] A depth-first search algorithm is used to traverse the service dependency graph to detect a strongly connected component to identify the circular dependency;

[0053] In the case where the circular dependency is detected, an influence range and a risk level of the circular dependency ring are calculated;

[0054] A dependency decoupling strategy is determined according to the risk level, the dependency decoupling strategy including an asynchronous modification strategy, a middleware introduction strategy and an interface splitting strategy;

[0055] A list of dependent services to be excluded is determined based on the dependency decoupling strategy;

[0056] The resource acquisition range is generated according to the list of dependent services to be excluded, the resource acquisition range being used to limit a service range included in a resource extraction process and an excluded service range.

[0057] In a second aspect, the present application provides a server, including:

[0058] a memory configured to store instructions; and

[0059] a processor configured to call the instructions from the memory and capable of implementing the above-mentioned service-oriented distributed resource automatic extraction and packaging method when the instructions are executed.

[0060] By the technical solution, the runtime dynamic dependency analysis can accurately capture all dependency relationships generated by the service in the actual running process, including dynamic configuration dependency, runtime service discovery, conditional resource invocation and other complex scenarios, significantly improving the accuracy and integrity of dependency relationship identification. The introduction of the circular dependency detection and decoupling strategy effectively avoids the deadlock and startup failure problems that may occur during service deployment. Through intelligent risk assessment and strategy selection, the integrity of the service package is ensured, and the inclusion of harmful dependencies is avoided, greatly improving the deployment success rate. The automatic extraction of multi-dimensional service resources covers API definition, data source configuration, business logic script, ETL process and other comprehensive service resources, realizing complete packaging of service resources and ensuring normal operation of the service in the target environment. In addition, the resource aggregation processing and standardized packaging process integrates the resources scattered in different systems and different formats into a standardized service package, greatly simplifying the operation complexity of service migration, backup and deployment, and improving the operation and maintenance efficiency. The establishment of the asynchronous task monitoring mechanism provides full-process visual state tracking for service deployment process, timely discovers and handles abnormal situations in the deployment process, and improves the reliability and user experience of the system. In summary, the technical solution can effectively capture runtime dynamically generated dependencies under the microservice architecture, reduce error rate and improve efficiency, and significantly improve the management efficiency and stability of the microservice ecosystem.

[0061] Other features and advantages of the embodiments of the present application will be described in detail in the subsequent specific embodiments section. BRIEF DESCRIPTION OF DRAWINGS

[0062] Figure 1 A flowchart of a service-oriented distributed resource automatic extraction and packaging method provided by the embodiments of the present application is shown.

[0063] Figure 2 A circular dependency detection and decoupling strategy flowchart provided by the embodiments of the present application is shown. DETAILED DESCRIPTION

[0064] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the drawings in the embodiments of the present application. It should be understood that the specific embodiments described herein are only used to illustrate and explain the embodiments of the present application, and are not used to limit the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without making creative efforts fall within the scope of protection of the present application.

[0065] It should be noted that if the embodiments of the present application involve directionality indication (such as up, down, left, right, front, back, etc.), the directionality indication is only used to explain the relative position relationship, movement condition, etc. between components in a certain posture (as shown in the drawings), and if the certain posture changes, the directionality indication also changes accordingly.

[0066] In addition, if the embodiments of the present application involve descriptions such as "first", "second", etc., the descriptions of "first", "second", etc. are only for description purposes, and cannot be understood as indicating or implying the relative importance or implicitly indicating the number of indicated technical features. Therefore, the features limited by "first", "second" can explicitly or implicitly include at least one of the features. In addition, the technical solutions of each embodiment can be combined with each other, but it must be based on the realization of a person skilled in the art, and when the combination of technical solutions contradicts each other or cannot be realized, it should be considered that the combination of technical solutions does not exist and is not within the protection scope required by the present application.

[0067] Figure 1 The flowchart of the service-oriented distributed resource automatic extraction and packaging method according to the embodiments of the present application is schematically shown. As shown in Figure 1 The embodiments of the present application provide a service-oriented distributed resource automatic extraction and packaging method, which is applied to a server. The server is deployed with a distributed service management platform. The method can include the following steps.

[0068] S110, in response to receiving the service packaging request, querying the service packaging task state according to the service identifier in the service packaging request;

[0069] S120, determining whether there is an executing packaging task according to the service packaging task state;

[0070] S130, in the case where there is no executing packaging task, performing runtime dynamic dependency analysis on the target service corresponding to the service identifier, and constructing a service dependency graph;

[0071] S140, detecting circular dependency based on the service dependency graph, and determining the resource acquisition range through a dependency decoupling strategy in the case where there is circular dependency;

[0072] S150, acquiring multi-dimensional service resources from a plurality of distributed data sources according to the service identifier and the resource acquisition range, wherein the multi-dimensional service resources include API definition resources, data source configuration resources, business logic script resources and ETL process resources;

[0073] S160. Aggregate the multi-dimensional service resources to generate a service basic information file, and package the multi-dimensional service resources and the service basic information file to generate a service resource package.

[0074] S170. Upload the service resource package to the distributed service management platform for deployment and create asynchronous tasks to monitor the execution status of the deployment process.

[0075] In one embodiment of this invention, runtime dynamic dependency analysis is performed on the target service corresponding to the service identifier to construct a service dependency graph, including the following steps:

[0076] S1. Based on Java Agent technology, the dependency tracking agent is loaded when the JVM starts.

[0077] S2. Use bytecode enhancement technology to identify the key call points of the target service. These key call points include HTTP client call points, database connection call points, message queue client call points, cache client call points, and configuration center client call points.

[0078] S3. Inject dependency tracking probes at key call points. Dependency tracking probes are used to capture resource identification information and record call timestamps, call duration, and call result status.

[0079] S4. Send the captured dependency call information to the distributed dependency collector;

[0080] S5. Construct a service dependency graph based on dependency call information. The service dependency graph includes service nodes, resource nodes, and configuration nodes, as well as dependency edges connecting each node.

[0081] In this embodiment, the resource identification information may be a target address, port, database name, queue name, etc.

[0082] Step S3 includes the following steps:

[0083] S31. Using the ASM bytecode manipulation framework, perform runtime bytecode modification on the key classes of the target service. The key classes include the HTTP client call class, database connection class, message queue client class, cache client class, and configuration center client class.

[0084] S32. Insert dependency recording code at the entry and exit points of the methods in the critical class. The dependency recording code is used to capture the resource identification information of the call, record the call timestamp, call time, call result status, and generate a unique call chain identifier.

[0085] Step S5 includes the following steps:

[0086] S51, a multi-level dependency relationship model is established based on dependency call information, including service-level dependency, resource-level dependency, configuration-level dependency, and version-level dependency;

[0087] S52, a Neo4j graph database is used to construct a dependency relationship network to obtain a dependency graph, wherein node types include service nodes, resource nodes, and configuration nodes, and edge types include synchronous call edges, asynchronous call edges, data dependency edges, and configuration dependency edges;

[0088] S53, a circular dependency detection algorithm is used to traverse the dependency graph using a depth-first search algorithm, detect strongly connected components, calculate the influence range and risk level of the detected circular dependency, and generate a service dependency graph.

[0089] The server in this embodiment can be a physical server, a virtual server, or a cloud server, and is deployed with a distributed service management platform for managing and coordinating the life cycle of multiple microservices. The distributed service management platform includes a service registry center, a configuration management center, a dependency tracking module, a resource extraction module, and a packaging and deployment module. The service registry center is used to maintain the registration information and state of all microservices; the configuration management center is responsible for managing various configuration files and environment variables; the dependency tracking module is used to monitor and analyze the dependency relationship between services in real time; the resource extraction module is responsible for extracting related resources from various distributed data sources; and the packaging and deployment module is responsible for aggregating, packaging, and deploying the extracted resources.

[0090] In actual implementation, when a user or other system needs to migrate, backup, or version archive a certain microservice, a service packaging request is sent to the server. The request contains the unique identifier of the service to be packaged, usually in the form of service name, version number, or UUID, etc. After receiving the request, the server first parses the service identifier in the request, and then queries the packaging task state of the service in the task management database of the distributed service management platform. The task state information includes task creation time, execution state (such as pending, in execution, completed, failed, etc.), execution progress, estimated completion time, and other detailed information.

[0091] The query process uses an index-optimized SQL query statement to quickly locate the relevant records by using the service identifier as the primary key. If the query result is empty, it means that the service has never executed a packaging task; if there is a record, the execution status of the current task is determined according to the state field. This query mechanism ensures accurate tracking and management of service packaging tasks, avoids the generation of duplicate tasks, and improves the stability and resource utilization efficiency of the system.

[0092] According to the service packaging task state obtained through the query, the platform will perform task conflict detection to determine whether there is an executing packaging task. In specific implementation, the platform will check whether the task state field is "executing", "queued", or other values indicating active state. If there is an executing packaging task, the platform will return a task conflict prompt information, informing the user that the current service is performing packaging operation, suggesting to wait for the completion of the current task before attempting again, or providing a task cancellation option for the user to select. This mechanism effectively avoids concurrent packaging operations of the same service, preventing resource competition and data inconsistency problems.

[0093] If there is no executing packaging task, the platform will create a new packaging task record in the task management database, set the task state to "executing", record the task start time, and generate a unique task identifier for subsequent tracking. At the same time, the platform will also set a task timeout mechanism, if the task execution time exceeds the preset threshold, the task state will be automatically set to "timeout failure", releasing the related resources, ensuring the effective use of resources, wherein the preset threshold is usually set to 30 minutes to 2 hours, which can be dynamically adjusted according to the service complexity.

[0094] After confirming that the packaging task can be executed, the platform performs runtime dynamic dependency analysis on the target service. Specifically, the runtime dynamic dependency analysis is realized by combining Java Agent technology and bytecode enhancement technology. First, a specially designed dependency tracking agent program is loaded when the JVM starts, which is developed based on Java Instrumentation API and can modify the bytecode when the class is loaded. Through the ASM bytecode operation framework, the platform identifies the key call points in the target service, including HTTP client call points (such as calls using OkHttp, Apache HttpClient libraries), database connection call points (such as JDBC connection, MyBatis mapper calls), message queue client call points (such as RabbitMQ, Kafka producers and consumers), cache client call points (such as Redis, Memcached clients), and configuration center client call points (such as Nacos, Apollo configuration acquisition).

[0095] At these key call points, dependency tracking probes are injected, and the probe code records detailed call information before and after method execution, including target resource identification information (such as URL, database name, queue name, etc.), call timestamp, call time consumption, call result status, call parameter summary, etc. All captured dependency call information is sent to a distributed dependency collector, which uses a high-performance message queue for asynchronous processing to minimize the impact on business service performance. Based on the collected dependency call information, the platform builds a multi-level service dependency graph, using a Neo4j graph database to store the dependency relationship network, which includes service nodes, resource nodes, configuration nodes, and dependency relationship edges connecting the nodes, forming a complete service ecosystem view.

[0096] Based on the constructed service dependency graph, the platform performs cyclic dependency detection to ensure service resource package integrity and deployment success rate. Referring to Figure 2 , the cyclic dependency detection uses a classic depth-first search algorithm to traverse the service dependency graph and identify cyclic dependencies by detecting strongly connected components using the Tarjan algorithm. In specific implementation, the algorithm starts from the target service node, recursively visits all dependent service nodes, and maintains an access stack and access state flag. When a node is found to have been visited in the current access path, a cyclic dependency is detected.

[0097] For each detected cyclic dependency loop, the platform calculates its impact scope and risk level. The impact scope is determined by analyzing the number of services involved in the cyclic dependency loop, call frequency, data traffic, and other indicators; the risk level is evaluated based on the closeness of the cyclic dependency, business importance, historical fault records, and other factors, and is divided into high, medium, and low levels.

[0098] According to the risk level, the platform selects the corresponding dependency decoupling strategy: for low-risk cyclic dependencies, use the asynchronous transformation strategy to change synchronous calls to asynchronous calls to reduce the closeness of dependencies; for medium-risk cyclic dependencies, use the middleware introduction strategy to decouple direct dependencies between services through message queues or event buses; for high-risk cyclic dependencies, use the interface splitting strategy to split complex service interfaces into multiple independent sub-interfaces to reduce dependency complexity. Based on the selected dependency decoupling strategy, the platform generates a list of dependent services to be excluded, and determines the resource acquisition range based on this, which clearly defines the service range that needs to be included and the service range that needs to be excluded in the resource extraction process, ensuring that the packaged service resource package is complete and does not contain harmful cyclic dependencies.

[0099] According to the determined service identifier and resource acquisition range, the platform acquires multi-dimensional service resources from multiple distributed data sources. Among them, the API defines the acquisition of resources through the query API gateway or service registration center, and the platform queries the API interface information list according to the service identifier and the preset on-shelf state identifier. The query result includes the complete information of the API path, HTTP method, request parameter definition, response format definition, authentication method, flow limiting configuration, etc.

[0100] The acquisition of data source configuration resources involves multiple configuration storage systems, including configuration management center, environment variable, configuration file, etc. The platform will query all related database connection configurations, cache configurations, message queue configurations, etc. according to the service identifier.

[0101] For the acquisition of business logic script resources, the platform first determines the database tables that need to be queried according to the preset API design enumeration type list, including data source configuration table, API parameter pool table, API construction step table, API construction version table, HTTP interface table, SQL interface table, WebService interface table, etc. For each table, the platform queries the corresponding table structure information to obtain the column name list, and then constructs the query condition parameters according to the API identifier in the API interface information list, executes the query operation in the corresponding database table, and acquires the business logic design data. These data are then parsed and converted into INSERT type SQL statements and written into SQL script files. The acquisition of ETL process resources is optional, and whether to execute is determined according to the preset ETL data extraction configuration switch. When the switch is on, the platform will query the ETL system information list associated with the target service, call the batch export interface of the ETL management platform through HTTP request, acquire the ETL process configuration file according to the system identifier list, and save it to the preset resource directory path. The whole resource acquisition process adopts parallel processing mechanism, and multiple resource type acquisition tasks are executed simultaneously, which significantly improves the processing efficiency.

[0102] After obtaining all the multi-dimensional service resources, the platform performs resource aggregation processing. Specifically, the platform creates a temporary directory path for storing all files to be packaged. According to the API definition resource and data source configuration resource, the platform exports the service construction file to the temporary directory. These files usually include service configuration files, API definition files, data source connection configuration files, etc., stored in JSON or YAML format for subsequent parsing and deployment. Business logic script resources are copied to the temporary directory in the form of SQL script files, and the files are named and organized according to function modules and execution order. The platform creates an XML format service basic information file, which serves as the metadata description file of the service package, containing service code, service name, version number, creation time, dependent service list, resource list, and other key information, providing necessary metadata support for subsequent deployment and management. If ETL process resources exist, they will also be saved to the temporary directory, usually in the form of XML or JSON format configuration files.

[0103] After all the above files are prepared, the platform uses a preset compression algorithm (usually ZIP or TAR.GZ format) to compress all files in the temporary directory to generate a service resource package. During compression, the platform calculates the checksum of the files to ensure data integrity. After compression is complete, the platform deletes the temporary directory and all its contents to release disk space and avoid resource waste. The generated service resource package has good portability and integrity, containing all resources and configuration information required for the target service to run.

[0104] Finally, the platform uploads the generated service resource package to the distributed service management platform for deployment and establishes a comprehensive monitoring mechanism. The upload process first needs to obtain relevant deployment parameters, including product identification and project identification obtained by querying according to service identification and resource acquisition range. These identifiers are used to determine the ownership and permissions of the service package in the target environment.

[0105] The platform obtains the upload service address of the distributed service management platform, which is usually a RESTful API endpoint that supports file upload and metadata transmission. Build upload parameters containing product identification, project identification, and service resource package packaging type, which indicates the format and processing method of the service package. Send the service resource package and upload parameters to the distributed service management platform through an HTTP POST request. The request uses multipart / form-data format, supporting large file transmission and progress monitoring.

[0106] The platform parses the response result returned by the distributed service management platform, extracts the deployment task identifier therefrom, and the identifier is used for subsequent task state query and monitoring. An asynchronous task is created to monitor the execution state of the deployment processing, and the asynchronous task queries the execution progress of the deployment task, including file decompression state, configuration verification state, service startup state, health check state, etc., at regular intervals (usually every 30 seconds to 2 minutes). The monitoring task also records detailed execution logs, including the start time, end time, execution result, error information, etc. of each deployment step, to provide data support for problem diagnosis and performance optimization. When the deployment task is completed, the asynchronous monitoring task updates the state of the original packaging task and notifies the relevant user or system of the deployment result.

[0107] In this embodiment, runtime dynamic dependency analysis can accurately capture all dependencies generated by services in actual running process, including dynamic configuration dependency, runtime service discovery, conditional resource invocation and other complex scenarios, significantly improving the accuracy and integrity of dependency relationship identification. The introduction of circular dependency detection and decoupling strategy effectively avoids the deadlock and startup failure problems that may occur in the service deployment process, and through intelligent risk assessment and strategy selection, the integrity of the service package is ensured, and the inclusion of harmful dependencies is avoided, greatly improving the deployment success rate. The automatic extraction of multi-dimensional service resources covers API definition, data source configuration, business logic script, ETL process and other comprehensive service resources, realizes complete packaging of service resources, and ensures normal operation of services in the target environment. In addition, resource aggregation processing and standardized packaging process unify the resources originally scattered in different systems and different formats into standardized service packages, greatly simplifying the operation complexity of service migration, backup and deployment, and improving the operation and maintenance efficiency. The establishment of the asynchronous task monitoring mechanism provides full-process visual state tracking for the service deployment process, discovers and handles abnormal situations in the deployment process in a timely manner, and improves the reliability and user experience of the system. In summary, this technical solution not only effectively captures runtime dynamically generated dependencies under the microservice architecture, reduces error rate and improves efficiency, but also significantly improves the management efficiency and stability of the microservice ecosystem.

[0108] In one of the embodiments of the present embodiment, the multi-dimensional service resources are obtained from a plurality of distributed data sources according to the service identifier and the resource acquisition range, including the following steps:

[0109] S210, querying service information according to the service identifier and the resource acquisition range to obtain service code and service version information;

[0110] S220, querying the list of API interface information that has been put on the shelf according to the service identifier, the resource acquisition range and the preset on-shelf state identifier to obtain API definition resources;

[0111] S230, querying the associated data source configuration information list according to the service identification and the resource acquisition range, and obtaining data source configuration resources;

[0112] S240, obtaining business logic design data through target database extraction according to the service identification, the resource acquisition range and the API interface information list, and converting the business logic design data into an SQL script file to obtain business logic script resources.

[0113] Query the service information according to the service identification and the resource acquisition range. The platform first parses the format and type of the service identification, which can be a service name, a service UUID or a composite identification, etc. After parsing, the platform accesses the metadata repository of the service registry center, uses an index-optimized query statement, and quickly locates the service record through the service identification as the primary key.

[0114] The query result contains the complete metadata information of the service, including the service code as the business identification of the service, the service version information following the semantic version control specification, and containing the major version number, the minor version number, the revision number, etc. The resource acquisition range plays a filtering role in this step, ensuring that only the information of the related services within the range is obtained, avoiding unnecessary data loading and processing. The query process also verifies the state information of the service to ensure that the target service is in an available state.

[0115] Query the API interface information according to the service identification, the resource acquisition range and the preset on-shelf state identification. API interface information is usually stored in API gateways, service registries or dedicated API management platforms. The preset on-shelf state identification includes "PUBLISHED", "ACTIVE", "DEPRECATED", "BETA" and other states, and only API interfaces in valid states are obtained during the query.

[0116] The query process uses multi-table association query, involving multiple data tables such as service table, API interface table, interface version table, interface parameter table, etc. The query result forms a complete API interface information list, and each interface record includes interface path, HTTP method, request parameter definition, response format definition, authentication method, flow control configuration, interface description document and other complete information. These API definition resources provide standardized interface contracts for the redeployment and integration of services.

[0117] Query the associated data source configuration information according to the service identification and the resource acquisition range. Data source configuration information covers all connection parameters of external systems and resources that need to be accessed during service running, including database connection configuration, cache system configuration, message queue configuration, external API configuration, file storage configuration, etc.

[0118] The query process first retrieves all configuration items related to the target service from the configuration management center, which uses a hierarchical configuration structure organized by environment, application, module, etc. For database connection configuration, the query result includes database type, connection address, port number, database name, connection pool configuration, transaction configuration, etc. For cache system configuration, it includes cache type, cluster node information, authentication information, serialization method, expiration policy, etc. Message queue configuration includes queue type, Broker address, queue name, exchange configuration, consumer group configuration, etc.

[0119] All sensitive information is desensitized during the query process, while retaining necessary configuration structure information to provide complete data source configuration resources for correct service deployment.

[0120] According to the service identifier, resource acquisition range, and API interface information list, the target database extracts business logic design data and converts it into a SQL script file. The platform determines the target database table name based on the pre-set API design enumeration type list, including data source configuration table, API parameter pool table, API construction step table, API construction version table, HTTP interface table, SQL interface table, WebService interface table, etc.

[0121] For each target database table, the platform queries the corresponding table structure information, including column name, data type, constraint condition, index information, etc. The platform constructs query condition parameters based on the API identifier in the API interface information list and executes batch query operations in the corresponding database table to obtain all business logic design data related to the target service.

[0122] After obtaining the business logic design data, the platform parses and converts these data into INSERT-type SQL statements, handling data type mapping, special character escaping, NULL value processing, date and time format conversion, etc. The generated SQL statements are sorted according to the table dependency relationship to ensure that there are no foreign key constraint violations when executed in the target environment. Finally, all SQL statements are written into a SQL script file, which uses UTF-8 encoding and includes necessary comment information and execution instructions, forming a complete business logic script resource.

[0123] In this embodiment, the service information query provides an accurate metadata basis for the entire resource acquisition process, ensuring the target and range of subsequent resource extraction. The systematic acquisition of API interface information ensures the integrity of the service contract, providing standardized interface definitions for correct integration and invocation of services in new environments. The comprehensive extraction of data source configuration information ensures that services can correctly connect and access the required external resources in the target environment, avoiding runtime errors caused by missing configurations. The automated generation of business logic script resources implements the complete migration of service core business logic, ensuring the consistency and executability of business logic between different environments. The entire resource acquisition process uses parallel processing and batch query optimization to significantly improve processing efficiency, providing technical support for automated operations in large-scale microservice environments.

[0124] In one embodiment of the present embodiment, according to the service identifier, resource acquisition range and API interface information list, the business logic design data is extracted from the target database, and the business logic design data is converted into a SQL script file to obtain the business logic script resource, including the following steps:

[0125] S310, according to the preset API design enumeration type list, determine the target database table name list;

[0126] S320, for each database table name in the target database table name list, query the corresponding table structure information to obtain the column name list;

[0127] S330, according to the API identifier in the API interface information list, construct the query condition parameter, and execute the query operation in the corresponding database table according to the query condition parameter to obtain the business logic design data;

[0128] S340, parse the business logic design data into an INSERT type SQL statement, and write the SQL statement into a SQL script file to obtain the business logic script resource.

[0129] According to the preset API design enumeration type list, the target database table name list is determined. The API design enumeration type list is a pre-configured data structure that contains all possible API design-related data table types in the microservice architecture, classified by function domain, mainly including basic configuration class, interface definition class, business logic class, version management class, monitoring and statistics class and other dimensions.

[0130] In specific implementations, the platform traverses this list of enumeration types, performing table name resolution operations for each enumeration type, taking into account the naming specification differences of different database vendors, supporting Oracle's capitalization naming, MySQL's lowercase naming, PostgreSQL's underscore naming, and other styles. The resolution process will also handle the dynamic generation of table name prefixes and suffixes, such as adding corresponding prefixes according to the environment identifier, or adding numerical suffixes according to the database and table splitting strategy.

[0131] After determining the table name, the platform verifies the existence of these tables in the target database, confirming the actual existence state of the table by querying the system table of the database. For non-existent tables, warning information will be recorded in the log, but the entire extraction process will not be interrupted. The final generated target database table name list is a verified and optimized table set.

[0132] For each database table name in the target database table name list, query the corresponding table structure information. Table structure information query uses standard SQL metadata query technology, accessing the database's system table or view to obtain detailed table structure definitions. For different database types, the platform will query the corresponding system view, such as MySQL's information_schema.columns view, Oracle's user_tab_columns view, etc.

[0133] During the query process, special attention will be paid to column data type information, including basic types, precision and scale, character set and sorting rules, and other detailed attributes. The platform will also query table constraints, including primary key constraints, foreign key constraints, unique constraints, check constraints, etc., to ensure that the generated INSERT statement meets data integrity requirements.

[0134] The obtained column name list will be sorted according to the defined order of the column in the table, ensuring that the subsequent generated SQL statements have good readability and consistency. For columns containing sensitive information, special markers will be added to the column name list for appropriate desensitization processing in subsequent processing.

[0135] According to the API identifier in the API interface information list, construct the query condition parameters and execute the query operation. API identifier is usually the unique identifier of the API, and the platform first performs format verification and standardization processing on these identifiers to ensure the correctness of the query condition. The construction of query condition parameters uses parameterized query technology to avoid SQL injection attacks and improve query performance.

[0136] For a single API identifier, a simple equality query condition is constructed; for multiple API identifiers, an IN clause query condition is constructed, and when the number of API identifiers exceeds the limit of the database IN clause, the query operation is automatically executed in batches. The execution of the query operation adopts a batch processing strategy, manages connection resources through a database connection pool, and uses a PreparedStatement precompiled SQL statement to improve execution efficiency.

[0137] During the query process, appropriate query timeout time is set to prevent long-running queries from affecting system performance. For large table queries, a paging query technique is used to query a fixed number of records each time, avoiding memory overflow caused by loading a large amount of data at once. The obtained business logic design data contains the complete business definition of the API, such as parameter mapping rules, data conversion logic, business process steps, verification rules, and exception handling strategies.

[0138] The business logic design data is parsed into INSERT type SQL statements and written into a SQL script file. The data parsing process first performs structured analysis on the obtained business logic design data, identifies each field in the data and its corresponding target table column, and establishes a field mapping relationship.

[0139] For fields of different data types, appropriate processing strategies are adopted: for string type fields, special character escaping is performed, converting single quotes to two single quotes and backslashes to double escaping, to ensure the grammatical correctness of the SQL statement; for numerical type fields, format verification is performed to ensure the validity and precision of the numerical value; for date and time type fields, format standardization is performed to convert to the standard format supported by the target database; for Boolean type fields, conversion is performed to the corresponding representation form according to the support of the target database.

[0140] For columns that allow NULL, NULL is used directly; for columns that do not allow NULL, the corresponding default value or empty value is used. The generation of the INSERT statement follows the standard SQL syntax specification and uses an explicit column name list form to ensure the readability and maintainability of the statement.

[0141] The generated SQL statements are sorted according to the table dependency relationship, the dependency graph of the table is constructed by analyzing the foreign key constraint relationship, and the topological sorting algorithm is used to determine the correct execution order to avoid foreign key constraint violation errors during execution in the target environment. The SQL script file uses UTF-8 encoding format and contains detailed comment information, such as generation time, data source, and execution instructions.

[0142] The script file will also contain necessary transaction control statements to ensure data consistency. For large data cases, the INSERT statements will be grouped into multiple script files, each containing an appropriate number of statements for batch execution and error localization.

[0143] In this embodiment, the systematic determination of target database tables ensures the comprehensiveness of business logic data extraction, avoiding the risk of missing critical business data. Detailed acquisition of table structure information provides accurate metadata support for data type conversion and SQL statement generation, ensuring the correctness and compatibility of generated scripts. Intelligent construction of query condition parameters and batch query execution significantly improve the efficiency of data acquisition while ensuring the safety and stability of query operations. Precise conversion of business logic design data into INSERT statements enables standardized expression of complex business logic, ensuring correct execution of generated SQL scripts in the target environment through strict data type processing and dependency relationship ordering. The automation of the entire process greatly reduces the complexity and error rate of manual operations, providing reliable technical support for the migration of business logic and environment replication of microservices.

[0144] In one embodiment of the present embodiment, according to the pre-defined API design enumeration type list, the target database table name list is determined, including the following steps:

[0145] S410, extract the database table name from the API design enumeration type list, and the table type corresponding to the database table name includes data source configuration table, API parameter pool table, API construction step table, API construction version table, HTTP interface table, SQL interface table and WebService interface table;

[0146] S420, according to the interface type in the API interface information list, filter the target database table name list from the database table name.

[0147] Extract the database table name from the API design enumeration type list. The API design enumeration type list is a structured configuration file or data structure, usually stored in JSON, XML or YAML format, containing all data table definitions related to API design and business logic in microservice architecture.

[0148] The platform parses this enumeration list and extracts the database table name according to the pre-defined table type classification. The data source configuration table stores various data source connection information required by API runtime, including database connection parameters, cache configuration, message queue configuration, etc. These tables usually contain fields such as data source name, connection URL, authentication information, connection pool configuration, etc.

[0149] The API parameter pool table maintains the input and output parameter definitions of the API interface, including parameter name, data type, verification rule, default value, parameter description, and other detailed information, supporting complex nested parameter structure and dynamic parameter configuration. The API construction step table records the processing flow of the API business logic, and each step contains execution order, processing type, input and output mapping, condition judgment, exception handling, and other configuration information.

[0150] The API construction version table manages the version history and change records of the API, including version number, release time, change content, compatibility information, rollback configuration, and other version management data. The HTTP interface table specifically stores the definition information of RESTful API, including URL path, HTTP method, request header configuration, response format, status code definition, and other detailed configurations related to HTTP protocol.

[0151] The SQL interface table manages API interfaces based on database operations, including SQL templates, parameter binding rules, result set mapping, transaction configuration, performance optimization configuration, and other database access-related information. The WebService interface table maintains the interface definition of SOAP WebService, including WSDL definition, namespace configuration, message format, security configuration, and other WebService-related metadata.

[0152] During the extraction process, the validity of each table name is verified, the consistency of naming specifications is checked, and the differences in table name prefixes or suffixes in different environments are handled.

[0153] According to the interface type in the API interface information list, the database table name is filtered. The API interface information list contains all the external interface definitions of the target service, and each interface record contains an interface type identifier. Common interface types include HTTP / REST, SQL / DATABASE, WEBSERVICE / SOAP, RPC, GRAPHQL, WEBSOCKET, and other types.

[0154] The platform establishes a mapping table between interface types and database table types, which defines which types of database tables each interface type needs to access. For example, HTTP / REST type interfaces mainly access HTTP interface tables, API parameter pool tables, API construction step tables, etc.; SQL / DATABASE type interfaces mainly access SQL interface tables, data source configuration tables, API construction version tables, etc.; WEBSERVICE / SOAP type interfaces mainly access WebService interface tables, API parameter pool tables, etc.

[0155] The filtering process adopts a multi-level screening strategy. First, coarse-grained filtering is performed according to the interface type to determine the range of table types that need to be accessed. Then, fine-grained filtering is performed according to specific business requirements to exclude irrelevant tables. The filtering algorithm also considers the dependency relationship between tables, automatically includes related dependent tables by analyzing foreign key constraints and business association relationships, and ensures data integrity.

[0156] For composite type interfaces, the filter combines the table requirements of multiple interface types to generate a comprehensive list of table names. During the filtering process, the priority of the tables is also handled, with core business tables being placed in the front and auxiliary configuration tables being placed in the back, optimizing the subsequent data extraction order.

[0157] The final generated target database table name list is a precisely filtered and optimized sorted table set, which ensures the integrity of data extraction and avoids unnecessary data processing overhead.

[0158] In this embodiment, the systematic extraction of the API design enumeration type list ensures comprehensive coverage of business logic data sources, providing complete data support for different types of API business logic through standardized table classification and naming conventions. The interface type-driven filtering strategy significantly improves the accuracy and efficiency of data extraction, avoiding the resource waste of traditional full table scanning methods while ensuring the integrity and consistency of business logic data. The multi-level screening and dependency relationship analysis mechanism ensures data integrity in complex business scenarios, providing reliable technical support for accurate migration and environment replication of microservices.

[0159] In one embodiment of the present embodiment, the multi-dimensional service resource is obtained from a plurality of distributed data sources according to the service identifier and the resource acquisition range, further comprising the following steps:

[0160] S510, determining whether to perform ETL process resource extraction according to a preset ETL data extraction configuration switch;

[0161] S520, in the case where the ETL data extraction configuration switch is in an open state, querying an associated ETL system information list according to the service identifier and the resource acquisition range;

[0162] S530, calling a batch export interface of an ETL management platform through an HTTP request, and obtaining an ETL process configuration file according to a system identifier list in the ETL system information list;

[0163] S540, saving the ETL process configuration file to a preset resource directory path to obtain an ETL process resource.

[0164] According to the preset ETL data extraction configuration switch, it is determined whether to perform ETL process resource extraction. The ETL data extraction configuration switch is a system-level configuration parameter, usually stored in the configuration management center, environment variable or configuration file, in various forms such as Boolean value, numerical value or string value.

[0165] The platform first reads this switch parameter from the configuration source. The configuration reading process supports a multi-level configuration override mechanism, and the parameters are parsed according to the priority order of system default configuration, environment configuration, application configuration and user configuration, to ensure the flexibility and manageability of the configuration.

[0166] The design of the configuration switch takes into account the differences in requirements of different business scenarios. For pure business services that do not involve ETL processes, ETL resource extraction can be turned off to improve processing efficiency. For data-intensive services or services that require complex data conversion, ETL resource extraction needs to be turned on to ensure the integrity of the service. The switch state is determined using strict Boolean logic, supporting case-insensitive string comparison, while handling abnormal cases such as null values. By default, a conservative strategy is adopted.

[0167] The platform also records the reading log of the switch state, including the configuration source, reading time, final value and other information, providing audit tracking for subsequent problem diagnosis and configuration management. When the switch is in the off state, the platform will skip all ETL-related resource extraction steps and directly proceed to the next processing link.

[0168] In the case where the ETL data extraction configuration switch is in the on state, the associated ETL system information list is queried according to the service identifier and resource acquisition range. ETL system information is usually stored in the enterprise's data integration management platform or metadata management system, containing detailed data such as the registration information, configuration parameters and running status of all ETL systems.

[0169] The platform constructs a composite query condition, taking the service identifier as the main query parameter, and combining the system boundaries and dependency relationships defined in the resource acquisition range to perform an associated query operation in the ETL system registry. The query process uses multi-table join technology, involving multiple data tables such as the service registry, ETL system table, service dependency relationship table and system mapping table, to establish the association between services and ETL systems through JOIN operation.

[0170] The construction of the query condition takes into account various association methods, including direct association, indirect association, configuration association and other complex scenarios. The query result forms an ETL system information list, and each system record contains detailed information such as system identifier, system type, system version, connection parameters, authentication information and management interface address.

[0171] The platform also verifies the availability status of the ETL system, confirms the normal operation state of the system through the health check interface or heartbeat mechanism, and adds a state label to the result list for the unavailable system. The query process also handles permission verification to ensure that the current operation user has access to the relevant ETL system.

[0172] The ETL management platform is called by HTTP request to get the ETL process configuration file. The ETL management platform usually provides RESTful API interface for external system calling, and the batch export interface is the core function interface, which supports batch getting configuration files of multiple ETL processes according to system identifier list.

[0173] The platform first constructs the HTTP request parameters, extracts the system identifier in the ETL system information list to form the system identifier list parameter, usually in JSON array or comma separated string format. The construction of HTTP request follows the standard specification of RESTful API, adopts POST method to send request, sets Content-Type as application / json, Accept as application / json or application / octet-stream, and adds necessary authentication header information.

[0174] The request body contains system identifier list, export format parameter, export range parameter, compression option and other detailed configurations. The sending of HTTP request adopts high-performance HTTP client library, sets appropriate connection timeout, reading timeout, retry mechanism and other parameters to ensure the reliability and stability of the request.

[0175] The response processing process will first check the HTTP status code, for 200 status code, it will continue to process the response body; for 4xx client error or 5xx server error, it will record error information and decide whether to retry according to error type. The processing of response body is according to Content-Type for corresponding analysis, for JSON format response, it will be parsed into configuration object, for file stream format response, it will be saved as file directly.

[0176] The obtained ETL process configuration file usually contains complete ETL job definition, such as data source configuration, transformation rule, target configuration, scheduling parameter, error handling strategy and other detailed information.

[0177] The ETL process configuration file is saved to a preset resource directory path to form an ETL process resource. The preset resource directory path is a system configured directory structure, which is usually organized in a hierarchical manner, and is divided into directories according to service identification, resource type, timestamp and other dimensions, to ensure that ETL resources of different services and different times can be stored and managed in order.

[0178] The platform first checks the existence of the target directory path, and if the directory does not exist, the complete directory structure is automatically created, and appropriate directory permissions are set during the creation process to ensure that subsequent file read and write operations can be normally executed. The file saving process will process according to the format and content of the ETL process configuration file. For a single configuration file, it will be saved as an independent file, and the file name uses the naming rule of system identification plus timestamp; for batch configuration files, they will be saved according to the system identification, and the configuration files of each system are saved in an independent subdirectory.

[0179] During the file saving process, data integrity verification is performed, the MD5 or SHA256 checksum of the file is calculated, and the checksum information is saved in the same name.checksum file to provide a basis for subsequent file integrity verification. The platform also creates a resource manifest file to record detailed information of all saved ETL configuration files, including file name, file size, creation time, checksum, source system and other metadata.

[0180] The file name conflict problem is handled during the saving process, and an automatic renaming mechanism is used to add a serial number suffix to the file name to ensure that all files can be successfully saved. The final formed ETL process resource is a structured file set containing all ETL process definitions dependent on the target service.

[0181] In this embodiment, the introduction of the configuration switch provides optional control of ETL resource extraction, which meets the differentiated needs of different business scenarios and avoids unnecessary resource consumption and processing overhead. The associated query of ETL system information ensures the accuracy and integrity of ETL resource acquisition, and through multi-dimensional association analysis, the ETL dependency range of the target service is accurately identified. The standardized calling of the batch export interface realizes the cross-system ETL configuration acquisition, and through the standardized interaction of the HTTP protocol, the compatibility and interoperability of different ETL management platforms are ensured. The structured file saving mechanism provides a good organization and management basis for ETL resources, and through integrity verification and metadata management, the reliability and traceability of ETL configuration files are ensured, providing technical support for the data processing capability migration of microservices.

[0182] In one embodiment of the present embodiment, the multi-dimensional service resources are aggregated to generate a service basic information file, and the multi-dimensional service resources and the service basic information file are packaged to generate a service resource package, including the following steps:

[0183] S610, according to the API definition resource and the data source configuration resource, export the service construction file to the temporary directory path;

[0184] S620, copy the business logic script resource to the temporary directory path;

[0185] S630, create an XML format service basic information file, wherein the service basic information file contains service code information;

[0186] S640, save the service basic information file to the temporary directory path;

[0187] S650, save the ETL process resource to the temporary directory path;

[0188] S660, compress all files in the temporary directory path to generate a service resource package by a preset compression algorithm, and delete the temporary directory path.

[0189] According to the API definition resource and the data source configuration resource, export the service construction file to the temporary directory path. The temporary directory path is named by a unique identifier generated by the system, usually combined with a timestamp and a random string, to ensure that there is no directory conflict when concurrent processing.

[0190] The platform first parses the API definition resource, extracts the interface path, HTTP method, parameter definition, response format and other information, and converts these information into a standardized API configuration file, usually in YAML or JSON format according to OpenAPI 3.0 specification. The generation process of the API configuration file will process complex data structure conversion, including the expansion of nested objects, the standardization of array types, the standardization of enumeration values, etc., to ensure that the generated configuration file meets the standard specification and has good readability.

[0191] The processing of data source configuration resource involves the standardization of configuration of various data source types. The platform generates corresponding configuration files according to the data source type, uses a unified configuration format, and the files are named according to the data source type. The generation process of the configuration file will process the desensitization of sensitive information, replace the sensitive data such as password, key, etc. with placeholders, and generate the corresponding environment variable configuration file to provide a template for subsequent security deployment.

[0192] The platform also generates a service dependency configuration file, which records the service's dependencies on external systems, including the dependent service name, version requirements, connection parameters, and other information. All generated configuration files are subjected to format verification and syntax checking to ensure their correctness and completeness.

[0193] The business logic script resources are copied to the temporary directory path. Business logic script resources usually contain multiple SQL script files, which are classified and named according to functional modules, execution order, database types, and other dimensions.

[0194] The platform creates a special script subdirectory under the temporary directory and further creates a subdirectory structure according to the script type, such as a subdirectory for storing data definition language scripts, a subdirectory for storing data manipulation language scripts, and a subdirectory for storing initialization scripts. The file copying process uses efficient file I / O operations and buffer stream technology to improve copying performance while performing file integrity verification.

[0195] During the copying process, file name conflicts are handled using an intelligent renaming strategy that adds a serial number or timestamp suffix based on maintaining the original semantics to ensure that all script files are saved correctly. The platform also generates a script execution manifest file that records metadata information such as the execution order, dependencies, and execution conditions of all script files.

[0196] For large script files, block copying technology is used to avoid memory overflow issues while providing copying progress feedback. After copying is complete, appropriate file permissions are set to ensure that script files have read and executable permissions.

[0197] A service basic information file in XML format is created. This file serves as a descriptive document for the service resource package and contains complete metadata information about the service. The choice of XML format is based on its good structured characteristics and extensive tool support, making it easy to parse and process later.

[0198] The service basic information file uses a standardized XML Schema definition, with the root element being <service>The service code information is included as a core element, containing the unique identifier of the service, service name, version number, build time, and other basic information. The file also includes a service description element, providing a functional description and business use description of the service; a dependency relationship element, listing external services and resources that the service depends on; a configuration parameter element, describing the service's configurable parameters and default values; a resource manifest element, listing all files and directories included in the service resource package; and a deployment requirement element, describing the service's deployment environment requirements and configuration parameters.

[0199] The generation of the XML file uses a DOM or SAX parser to ensure that the generated XML document conforms to W3C standards and predefined Schema specifications. Character encoding processing is performed during file generation, using UTF-8 encoding to ensure correct display of internationalized characters, while handling the escaping of XML special characters. The generated XML file also includes digital signature or checksum information for verifying the integrity and authenticity of the file.

[0200] The service basic information file is saved to a temporary directory path, and the generated XML file is written to the specified location using file system APIs, with appropriate file permissions and attributes set.

[0201] The ETL process resources are saved to a temporary directory path, and the corresponding subdirectories are created under the temporary directory. All ETL configuration files are saved according to system type and functional module.

[0202] All files in the temporary directory path are compressed to generate a service resource package using a preset compression algorithm, and the temporary directory is deleted. The preset compression algorithm usually chooses ZIP format due to its good cross-platform compatibility, high compression ratio, and extensive tool support.

[0203] The compression process uses stream compression technology, reading files in the temporary directory one by one and adding them to the ZIP archive, avoiding memory pressure caused by loading all files at once. The compression parameters are set to balance compression ratio and compression speed, usually using a medium compression level to ensure reasonable compression ratio and avoid excessive compression time.

[0204] The file directory structure and relative path are maintained during compression to ensure correct restoration of file organization structure after decompression. Different compression strategies are used for different types of files, with text files usually achieving higher compression ratios, while binary files have relatively limited compression effectiveness.

[0205] The compression process also generates a compression manifest that records the original size, compressed size, compression ratio, checksum, and other information for each file, providing a basis for subsequent integrity verification. The generated service resource package file adopts standardized naming conventions and typically contains service identification, version number, timestamp, and other information.

[0206] After compression is complete, the platform calculates the MD5 and SHA256 checksums of the entire resource package and generates the corresponding verification files to provide a guarantee for the integrity verification of file transmission and storage. The deletion of the temporary directory uses a recursive deletion algorithm to ensure that all subdirectories and files are thoroughly cleaned up and disk space is released. The deletion operation performs exception handling, and for files that fail to be deleted, a warning log is recorded, but it does not affect the completion of the entire packaging process.

[0207] In this embodiment, the standardized export of service construction files ensures the standardized expression of API and data source configurations, providing a configuration foundation for the standardized deployment of services. The ordered organization of business logic scripts and metadata management provide reliable guarantees for the accurate reconstruction of complex business logic. The creation of XML format service basic information files establishes a complete service metadata system, providing standardized description documents for service management, deployment, and maintenance. The efficient compression and packaging mechanism integrates all resources into a single transmissible package, significantly simplifying the service distribution and deployment process, while ensuring the reliability of the packaging process and the effective use of system resources through integrity verification and temporary resource cleaning.

[0208] In one embodiment of the present embodiment, the service resource package is uploaded to the distributed service management platform for deployment, including the following steps:

[0209] S710, querying the associated product identification and project identification according to the service identification and resource acquisition range;

[0210] S720, obtaining the upload service address of the distributed service management platform;

[0211] S730, constructing upload parameters containing product identification, project identification, and packaging type of service resource package;

[0212] S740, sending the service resource package and upload parameters to the distributed service management platform;

[0213] S750, parsing the response result returned by the distributed service management platform to obtain a deployment task identification.

[0214] According to the service identifier and resource acquisition range, the product identifier and project identifier are queried. The product identifier and project identifier are important organizational dimensions in the enterprise-level service management system. The product identifier usually represents a business product line or business domain, and the project identifier represents a specific project or application. This hierarchical organizational structure helps with the classification management and permission control of services.

[0215] The platform accesses the organization structure management system or project management database of the enterprise. These systems usually maintain a complete service-project-product mapping table. The query process uses multi-table association query technology, involving multiple data tables such as the service registry table, the project service mapping table, the product project mapping table, and the organization structure table. The LEFT JOIN or INNER JOIN operation is used to establish a complete association relationship chain.

[0216] The construction of the query condition not only includes the service identifier as the main query parameter, but also combines the organizational boundaries and permission ranges defined in the resource acquisition range to ensure that the query result meets the permission requirements of the current operation context. Multiple mapping relationships are handled in the query process. A service may belong to multiple projects or products, and the platform will determine the main affiliation relationship based on priority rules or recent use records.

[0217] For the case where the query result is empty, the platform will use a default value strategy or prompt the user to manually specify, ensuring the normal progress of the subsequent process. The query result also includes relevant permission information such as deployment permissions, management permissions, and access permissions, which will be used for subsequent deployment operation verification.

[0218] The platform also verifies the validity of the product identifier and project identifier, checking whether they are in an active state. For disabled or archived product projects, appropriate warning prompts are given. The results of the query process are cached for a certain period of time to avoid performance pressure on the database caused by repeated queries, while ensuring the timeliness of the data.

[0219] Get the upload service address of the distributed service management platform. The distributed service management platform is usually deployed in a cluster environment with multiple service nodes and load balancing mechanisms. The upload service address may be a virtual IP address, domain name, or unified entry of a service gateway of a load balancer.

[0220] The platform first reads the basic configuration information of the service management platform from the configuration management center. These configurations usually include platform type, connection protocol, basic domain name or IP address, port number, and other basic parameters. The acquisition process handles multi-environment configurations, selects the corresponding platform address according to the current running environment, and ensures that the service package is uploaded to the correct target environment.

[0221] The platform also performs service discovery, obtaining the latest list of service addresses by calling the service registry's API or querying DNS records. This dynamic discovery mechanism can adapt to changes in platform addresses and dynamic scaling of nodes. The address acquisition process includes a health check step, where the platform sends health check requests to candidate addresses to verify service availability and response time, selecting the address with the fastest response and normal status as the upload target.

[0222] For platforms that support multi-region deployment, geographical location is also considered, prioritizing the nearest service node to reduce network latency and transmission time. The obtained upload service address will contain the complete URL path, as well as API version information, authentication requirements, request format requirements, and other interface specification information.

[0223] Construct upload parameters that include product identifiers, project identifiers, and service resource package types. The upload parameters are constructed using a structured data format, typically JSON, to organize the parameter information, ensuring readability and parsability.

[0224] The parameter building process creates a JSON object with multiple levels. The root level contains basic metadata information, such as request ID, timestamp, and API version. The business level contains business-related information such as product identifier, project identifier, and service identifier. The technical level contains technical parameters such as packaging type, compression format, file size, and checksum.

[0225] Product and project identifiers undergo format standardization to ensure compliance with the target platform's naming conventions and character set requirements. Identifiers containing special characters are URL-encoded or Base64-encoded. The service resource package packaging type parameter indicates the format and content type of the resource package. Common types include complete service packages, configuration files only, script files only, incremental update packages, etc. This type information helps the target platform select the correct parsing and deployment strategy.

[0226] The parameter construction process also adds security-related parameters, such as digital signatures, encryption identifiers, and permission tokens, to ensure the security and trustworthiness of the upload process. For large file uploads, parameters related to chunked uploads are added, such as chunk size, number of chunks, and resume upload flags, to support reliable large file transfers.

[0227] The service resource package and upload parameters are sent to the distributed service management platform. File transfer uses the HTTP POST method with multipart / form-data encoding format, supporting the simultaneous transfer of file data and form parameters.

[0228] The construction of the HTTP request sets appropriate request header information, including Content-Type set to multipart / form-data, Accept set to application / json, User-Agent set to system identification information, Authorization set to authentication token, etc. The request body uses a multi-part format, the first part contains JSON data of upload parameters, and the second part contains service resource package files.

[0229] The file transfer process uses streaming technology to avoid loading the entire file into memory. File data is read and sent in chunks through a buffer, with a buffer size typically set to 8KB to 64KB, balancing memory usage and transmission efficiency. A progress monitoring mechanism is implemented during the transmission process, with real-time reporting of transmission progress through callback functions or event listeners.

[0230] The platform also implements a resume function, supporting continuous transmission from the breakpoint through the HTTP Range request header, which is particularly useful for unstable networks or large file transfer scenarios. Exception handling during the transmission process includes network timeouts, connection interruptions, server errors, and other situations. The platform will use appropriate retry strategies based on the type of exception.

[0231] The response returned by the distributed service management platform is parsed to obtain the deployment task identifier. The response is usually returned in JSON format, containing a multi-level information structure. The root level contains basic information such as response status, message, and timestamp. The data level contains detailed information about the deployment task. The error level contains possible error codes and error descriptions.

[0232] The response parsing process first verifies that the response Content-Type is application / json, then uses a JSON parser to parse the response body into a structured object. The parsing process handles various data type conversions, including strings, numbers, booleans, arrays, and nested objects, ensuring accurate data extraction.

[0233] The deployment task identifier is usually located in a specific field of the response JSON. The parsing process locates the correct field according to the API document specification. In addition to the deployment task identifier, the parsing process also extracts other useful information such as task creation time, estimated completion time, task status, task description, and monitoring URL, which provides support for subsequent task tracking and monitoring.

[0234] The parsing process includes an error handling mechanism, which throws corresponding exceptions and provides detailed error descriptions for improperly formatted JSON, missing required fields, type mismatches, etc. The parsed deployment task identifier is format-verified to ensure compliance with the identifier specification requirements.

[0235] In this embodiment, the query of product and project identifiers establishes the correct attribution of services in the enterprise organizational structure, ensuring compliance and management standards for deployment operation permissions. Dynamic acquisition and health checks of platform addresses ensure the availability and optimal selection of deployment targets, improving the success rate and efficiency of deployment operations. Standardized parameter construction and secure transmission mechanisms ensure the reliability and security of cross-system interactions, supporting service deployment requirements in complex enterprise environments. Accurate parsing of response results and extraction of task identifiers provide a reliable tracking foundation for subsequent deployment monitoring and management, enabling visual management of the entire service deployment lifecycle.

[0236] In one implementation of the present embodiment, runtime dynamic dependency analysis is performed on the target service corresponding to the service identifier to construct a service dependency graph, including the following steps:

[0237] S810, determining the key calling points of the target service;

[0238] S820, injecting dependency tracking probes at the key calling points and constructing a service dependency graph to record the dependency relationships between services.

[0239] Determine the key calling points of the target service. Key calling points refer to specific locations in the service code that call external resources or services. These locations typically include HTTP client calling points, database connection calling points, message queue client calling points, cache client calling points, configuration center client calling points, file system access points, network socket calling points, and other types.

[0240] The platform first performs static analysis on the bytecode of the target service, using the ASM bytecode analysis framework or the Javassist bytecode operation library to scan all class files of the service and identify methods and code segments containing external calls. The static analysis process establishes a call graph to determine possible dependency call paths through method call relationship analysis, identifying all possibilities of direct and indirect calls.

[0241] For HTTP client invocation points, the platform identifies code locations that use HTTP client libraries such as OkHttp, Apache HttpClient, SpringRestTemplate, Feign Client, and analyzes key code segments such as URL construction logic, request parameter configuration, response processing, etc. The identification of database connection invocation points involves multiple data access patterns such as JDBC connection creation, PreparedStatement execution, MyBatis mapper invocation, JPA Repository invocation, etc. The platform analyzes key operations such as SQL statement construction, parameter binding, result set processing, etc.

[0242] Message queue client invocation points include RabbitMQ producers and consumers, Kafka producers and consumers, ActiveMQ clients, etc. The platform identifies key operation points such as message sending, receiving, and confirmation. Cache client invocation points involve Redis clients, Memcached clients, local caches, etc. The platform identifies cache read, write, and delete operations. Configuration center client invocation points include Nacos configuration acquisition, Apollo configuration reading, Spring Cloud Config, and other configuration access operations.

[0243] The platform also uses reflection mechanisms and annotation scanning techniques to identify indirectly generated dependency invocation points through dependency injection, configuration binding, etc. The determination of key invocation points also considers indirect calls generated by dynamic proxies, AOP aspects, interceptors, etc. Through runtime class loading monitoring and method call stack analysis, these dynamically generated invocation points are captured.

[0244] Inject dependency tracking probes at key invocation points and build service dependency graphs. Dependency tracking probes are lightweight monitoring code inserted into the method entry and exit of key invocation points through bytecode injection technology, used to capture and record detailed information about dependency calls.

[0245] The probe injection process uses Java Agent technology to dynamically load the dependency tracking agent program at JVM startup or runtime. This agent program is developed based on the Java Instrumentation API and can modify bytecode at class loading time. The bytecode enhancement process uses the ASM bytecode operation framework to modify the target class's key methods at runtime, inserting probe code at the beginning and end of the method.

[0246] The design of the probe code follows the principle of minimum performance impact, uses an asynchronous processing mechanism to separate the collection and transmission of dependency information from the execution of business logic, and avoids significant impact on service performance. The probe captures multi-dimensional dependency information, including call timestamp, call duration, target resource identifier, call parameter summary, call result status, exception information, call thread information, and call context.

[0247] The construction of the service dependency graph uses graph database technology, usually using Neo4j as the storage engine, to establish a relationship model of nodes and edges. The node types in the graph include service nodes, resource nodes, configuration nodes, etc., and each node contains rich attribute information such as node type, name, version, address, and status.

[0248] The edge types in the graph include synchronous call edges, asynchronous call edges, data dependency edges, and configuration dependency edges, and each edge contains statistical information such as call frequency, average duration, error rate, and last call time. The graph construction process uses a real-time update mechanism, and the dependency information collected by the probe is sent asynchronously to the graph construction service through a high-performance message queue, and the construction service processes these information in real time to update the nodes and edges in the graph.

[0249] The graph also supports historical version management, records the change history of dependency relationships, supports time range queries and dependency relationship evolution analysis. In order to handle complex dependency relationships in large-scale microservice environments, the graph construction process uses a distributed processing architecture, supports horizontal expansion and load balancing, and ensures the scalability and high availability of the system.

[0250] In this embodiment, the accurate identification of key call points ensures the comprehensiveness and accuracy of dependency analysis, and through the combination of static analysis and dynamic monitoring, it can capture dependency relationships in various complex scenarios. The non-invasive injection technology of the dependency tracking probe ensures zero modification and minimum performance impact on business code, and through asynchronous processing and lightweight design, it realizes sustainable monitoring in production environment. The real-time construction and dynamic update of the service dependency graph provide a powerful visualization tool for dependency management of microservice architecture, support analysis, optimization and governance of complex dependency relationships, and provide a reliable dependency relationship basis for service migration and environment replication.

[0251] In one embodiment of the present embodiment, based on the service dependency graph, a circular dependency is detected, and in the case of a circular dependency, a resource acquisition range is determined through a dependency decoupling strategy, including the following steps:

[0252] S910, a depth-first search algorithm is used to traverse the service dependency graph to detect strongly connected components to identify circular dependencies;

[0253] S920, in the case of detecting a circular dependency, calculating the influence range and risk level of the circular dependency loop;

[0254] S930, determining a dependency decoupling strategy according to the risk level, the dependency decoupling strategy including an asynchronous modification strategy, a middleware introduction strategy, and an interface splitting strategy;

[0255] S940, determining a list of dependent services to be excluded based on the dependency decoupling strategy;

[0256] S950, generating a resource acquisition range according to the list of dependent services to be excluded, the resource acquisition range being used to limit the service range included in the resource extraction process and the excluded service range.

[0257] A depth-first search algorithm is used to traverse the service dependency graph to detect strongly connected components to identify circular dependencies. The depth-first search algorithm is a basic algorithm for graph traversal, and the Tarjan algorithm is a classic algorithm for detecting strongly connected components, and the combination of the two can efficiently identify the circular structure in the directed graph.

[0258] The algorithm first converts the service dependency graph into a standard directed graph data structure, where each node in the graph represents a microservice, and each directed edge represents the dependency relationship between services. The direction of the edge represents the direction of the dependency. The DFS traversal process starts from any unvisited node in the graph, and uses recursion or stack structure to implement depth-first access. The access state of each node is marked, including unvisited, being visited, and completed access.

[0259] The Tarjan algorithm maintains two important attributes for each node based on DFS: discovery time and lowest link value. The discovery time records the timestamp of the first access to the node, and the lowest link value records the discovery time of the earliest ancestor node that can be reached from the node. A stack structure is maintained during the algorithm process to store the nodes on the current search path. When the lowest link value of a node is equal to its discovery time, it means that a root node of a strongly connected component has been found. At this time, the nodes are popped from the stack until the root node, which form a strongly connected component.

[0260] A strongly connected component containing multiple nodes indicates the existence of a circular dependency, and a single-node strongly connected component indicates no circular dependency. The time complexity of the algorithm is O(V+E), where V is the number of nodes and E is the number of edges, and the space complexity is O(V), which can efficiently process large-scale service dependency graphs. The detection process also handles special cases such as self-loop dependencies and multiple edges to ensure the completeness and accuracy of the circular dependency detection.

[0261] In the case of detecting circular dependencies, the impact range and risk level of the circular dependency loop are calculated. The calculation of the impact range involves multiple dimensional analysis, including the number of services involved in the circular dependency loop, the business importance of the services, the call frequency, data traffic, user impact, and other key indicators.

[0262] The platform conducts a detailed analysis of each detected strongly connected component, first counting the number of service nodes included in the loop. The more nodes, the higher the complexity of the circular dependency and the greater the impact range. The business importance of the services is quantified by a pre-set weight coefficient. Core business services have a higher weight value, while supporting services have a lower weight value. The weight value usually uses a 1-10 rating standard.

[0263] Call frequency analysis is evaluated by counting the number of calls between services and call density. High-frequency calls have a higher risk level. Call frequency data comes from real-time monitoring data collected by the dependency tracking probe. Data traffic analysis considers the size of data transmitted between services and data sensitivity. Large data transmission and sensitive data transmission have a higher risk rating.

[0264] User impact analysis determines the number of users and business function ranges that may be affected by the circular dependency failure. Circular dependencies that affect core user functions have the highest risk level. The risk level calculation uses a weighted scoring model that considers various indicators in each dimension. The formula is:

[0265] ;

[0266] Where is the weight coefficient of the i-th dimension, is the score value of the i-th dimension. The final risk level is divided into high risk, medium risk, and low risk, with different risk levels corresponding to different handling strategies and priorities.

[0267] According to the risk level, determine the dependency decoupling strategy. Dependency decoupling strategy is a set of pre-defined technical solutions to break the circular dependency relationship and restore the hierarchical architecture of the system. The platform maintains a strategy decision table to select the appropriate decoupling strategy based on risk level, characteristics of circular dependency, technology stack of services, and other factors.

[0268] Asynchronous transformation strategy is suitable for low to medium risk circular dependencies. It breaks the circular dependency chain by changing synchronous calls to asynchronous calls. Specific implementations include introducing message queues for asynchronous communication, using event-driven architecture instead of direct calls, and using callback mechanisms to handle responses. The advantage of this strategy is that the modification cost is relatively low, and the impact on existing business logic is small, but it needs to handle the consistency and timing problems brought by asynchronous calls.

[0269] Middleware introduction strategies are suitable for medium to high-risk circular dependencies. They decouple direct dependencies by introducing middleware components between services with circular dependencies. Commonly used middleware includes API gateways, service buses, data buses, and event buses. API gateways can uniformly manage call relationships between services, providing functions such as routing, load balancing, and circuit breaking; service buses can achieve loosely coupled communication between services; and data buses can resolve circular dependencies related to data sharing.

[0270] Interface splitting is a strategy suitable for high-risk, complex circular dependencies. It fundamentally eliminates circular dependencies by redesigning service interfaces and responsibility boundaries. Specific implementations include re-dividing service boundaries according to business domains, extracting common functions into independent services, and splitting large services into multiple smaller services. This strategy requires in-depth analysis and refactoring of business logic, resulting in high transformation costs, but it can completely solve the circular dependency problem at the architectural level.

[0271] The strategy selection process also considers multiple factors such as technical feasibility, business impact, time cost, and maintenance cost, and determines the optimal decoupling solution through multi-dimensional evaluation.

[0272] The dependency decoupling strategy determines the list of dependent services to be excluded. This list refers to the set of services that should not be included in the current packaging task. Excluding these services helps break circular dependencies and ensures the independence and deployability of service resource packages.

[0273] The process of determining the exclusion list involves different analyses depending on the selected decoupling strategy. For asynchronous transformation strategies, the platform analyzes which service calls in the circular dependency loop can be changed to asynchronous methods. The target service to be asynchronous can be excluded from the current packaging task because asynchronous calls do not require the target service to exist at the time of deployment.

[0274] For middleware introduction strategies, the platform identifies service pairs in circular dependency loops that can be decoupled through middleware. Services connected through middleware can be deployed independently, thus excluding some services from the current package scope. For interface splitting strategies, the platform analyzes the service interface splitting scheme to determine which functions can be deployed independently and which functions need to be retained in the current service.

[0275] The exclusion list generation also considers transitive dependencies between services. Dependency graph analysis is used to determine other services that might be affected by excluding a particular service, thus avoiding dependency omissions due to improper exclusion. The platform verifies the feasibility of the exclusion list by conducting simulated deployment tests to validate the correctness of the exclusion scheme.

[0276] A resource acquisition scope is generated according to the list of dependent services to be excluded. The resource acquisition scope is a structured configuration object that explicitly defines which services and resources should be included and which services and resources should be excluded in the resource extraction process, providing precise guidance for subsequent resource extraction operations.

[0277] The generation of the resource acquisition scope adopts an include-exclude mode, first defining a basic include scope, and then applying exclusion rules to remove the services to be excluded. The definition of the include scope is based on the breadth-first traversal of the service dependency graph, starting from the target service and expanding layer by layer according to the dependency relationship until the preset dependency depth limit is reached or a circular dependency boundary is encountered.

[0278] The definition of the exclusion scope is based on the list of dependent services to be excluded, including not only the directly excluded services but also the transitive dependencies of these services. The scope definition also considers the granularity level of resources, including service level, module level, resource level, and different granularities.

[0279] The generated resource acquisition scope adopts a standardized data format, including a list of service identifiers, a list of resource types, a list of exclusion rules, a dependency depth limit, a time range limit, and other detailed configurations. The scope configuration also includes verification rules for verifying the integrity and consistency of the extraction results during the resource extraction process.

[0280] In this embodiment, the depth-first search and strongly connected component detection algorithm ensures the accuracy and efficiency of circular dependency recognition, and can handle complex dependency relationships in large-scale microservice environments. The multi-dimensional risk assessment mechanism provides a scientific basis for the treatment of circular dependencies, ensuring the rationality and effectiveness of the treatment strategy through quantitative analysis. The differentiated decoupling strategy selection mechanism adapts to the needs of different risk levels and technical scenarios, ensuring decoupling effectiveness while controlling the cost of transformation. The accurate resource acquisition scope generation mechanism provides reliable protection for the independence and deployability of service resource packages, effectively avoiding the adverse effects of circular dependencies on service migration and deployment, and providing technical support for the healthy development and efficient governance of microservice architecture.

[0281] The embodiment of the application also provides a server, comprising:

[0282] a memory configured to store instructions; and

[0283] a processor configured to call the instructions from the memory and capable of implementing the above-mentioned service-oriented distributed resource automatic extraction and packaging method when executing the instructions.

[0284] Those skilled in the art will appreciate that embodiments of the present application can be readily used as a method, a system or a computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer readable storage media (including, but not limited to, disk memory, CD-ROMs, optical storage devices, etc.) embodying computer readable program code.

[0285] The present application is described in reference to the flow diagrams and / or block diagrams of the methods, apparatus (systems), computer program products according to embodiments of the application. It will be understood that each block of the flow diagrams and / or block diagrams, and combinations of blocks in the flow diagrams and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, embedded processing device or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flow diagrams and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flow diagram and / or block diagram block or blocks. Figure 1 one or more functions specified in the flow diagram and / or block diagram block or blocks.

[0286] These computer program instructions can also be stored in a computer readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer readable memory produce an article of manufacture including instructions which implement the flow diagrams and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flow diagram and / or block diagram block or blocks. Figure 1 one or more functions specified in the flow diagram and / or block diagram block or blocks.

[0287] These computer program instructions can also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the flow diagrams and / or block diagrams block or blocks. Figure 1 one or more functions specified in the flow diagram and / or block diagram block or blocks. Figure 1 one or more functions specified in the flow diagram and / or block diagram block or blocks.

[0288] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0289] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) and / or cache memory. The memory can also include non-volatile memory, such as read-only memory (ROM), electrically programmable read-only memory (EPROM), electrically erasable read-only memory (EEPROM), flash memory, or a combination of non-volatile memories in different forms. The memory is an example of computer readable storage media.

[0290] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology to store information. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. According to the definition herein, computer-readable media does not include transitory media such as modulated data signals and carriers.

[0291] It should also be noted that the terms "comprising", "containing", or any other variant thereof are intended to cover a non-exclusive inclusion, such that a process, method, article or apparatus that comprises a list of elements does not only include those elements, but can also include other elements not expressly listed or inherent to such process, method, article or apparatus. Without more limitations, the element defined by the statement "comprising a" does not exclude the presence of additional identical elements in the process, method, article or apparatus that includes the element.

[0292] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application can have various modifications and changes. Any modification, equivalent replacement, improvement, etc. within the spirit and principle of the present application shall be included in the scope of claims of the present application.< / service>

Claims

1. A service-oriented distributed resource automation extraction and packaging method, characterized in that, Applied to a server, the server is deployed with a distributed service management platform, and the method comprises: In response to receiving a service packaging request, querying the service packaging task state according to the service identification in the service packaging request; According to the service packaging task state, it is determined whether there is an executing packaging task; In the case where there is no executing packaging task, the target service corresponding to the service identification is analyzed for runtime dynamic dependence, and a service dependence graph is constructed; Based on the service dependence graph, the circular dependence is detected, and in the case where there is circular dependence, the resource acquisition range is determined through the dependence decoupling strategy; According to the service identification and the resource acquisition range, a plurality of multi-dimensional service resources are acquired from a plurality of distributed data sources, wherein the multi-dimensional service resources include API definition resources, data source configuration resources, business logic script resources and ETL process resources; According to the API definition resources and the data source configuration resources, the service construction file is exported to the temporary directory path; The business logic script resource is copied to the temporary directory path; An XML format service basic information file is created, wherein the service basic information file contains service code information; The service basic information file is saved to the temporary directory path; The ETL process resource is saved to the temporary directory path; Through a preset compression algorithm, all files under the temporary directory path are compressed to generate a service resource package, and the temporary directory path is deleted; The service resource package is uploaded to the distributed service management platform for deployment, and an asynchronous task is created to monitor the execution state of the deployment processing.

2. The method of claim 1, wherein, According to the service identification and the resource acquisition range, a plurality of multi-dimensional service resources are acquired from a plurality of distributed data sources, wherein the multi-dimensional service resources include API definition resources, data source configuration resources, business logic script resources and ETL process resources; According to the service identification and the resource acquisition range, the service information is queried to obtain service code and service version information; According to the service identification, the resource acquisition range and the preset on-shelf state identification, the API interface information list is queried to obtain the API definition resource; According to the service identification and the resource acquisition range, the associated data source configuration information list is queried to obtain the data source configuration resource; According to the service identification, the resource acquisition range and the API interface information list, the business logic design data is extracted through the target database, and the business logic design data is converted into a SQL script file to obtain the business logic script resource.

3. The method of claim 2, wherein, According to the service identification, the resource acquisition range and the API interface information list, the business logic design data is extracted through the target database, and the business logic design data is converted into a SQL script file to obtain the business logic script resource, comprising: According to a preset API design enumeration type list, a target database table name list is determined; For each database table name in the target database table name list, the corresponding table structure information is queried to obtain a column name list; According to the API identification in the API interface information list, a query condition parameter is constructed, and a query operation is performed in a corresponding database table according to the query condition parameter, so that business logic design data is obtained; The business logic design data is parsed into an INSERT type SQL statement, and the SQL statement is written into a SQL script file, so that the business logic script resource is obtained.

4. The method of claim 3, wherein, The target database table name list is determined according to the preset API design enumeration type list, including: The database table name is extracted from the API design enumeration type list, and the table type corresponding to the database table name includes a data source configuration table, an API parameter pool table, an API construction step table, an API construction version table, an HTTP interface table, an SQL interface table and a WebService interface table; According to the interface type in the API interface information list, the target database table name list is filtered from the database table name.

5. The method of claim 1, wherein, The multi-dimensional service resource is obtained from the multiple distributed data sources according to the service identification and the resource acquisition range, and further includes: According to the preset ETL data extraction configuration switch, it is determined whether to execute the ETL process resource extraction; In the case that the ETL data extraction configuration switch is in the open state, the associated ETL system information list is queried according to the service identification and the resource acquisition range; The batch export interface of the ETL management platform is called through the HTTP request, and the ETL process configuration file is obtained according to the system identification list in the ETL system information list; The ETL process configuration file is saved to a preset resource directory path, and the ETL process resource is obtained.

6. The method of claim 1, wherein, The service resource package is uploaded to the distributed service management platform for deployment, including: According to the service identification and the resource acquisition range, the product identification and the project identification associated are queried; The upload service address of the distributed service management platform is obtained; The upload parameter of the packaging type containing the product identification, the project identification and the service resource package is constructed; The service resource package and the upload parameter are sent to the distributed service management platform; The response result returned by the distributed service management platform is parsed, and a deployment task identification is obtained.

7. The method of claim 1, wherein, The target service corresponding to the service identification is analyzed for runtime dynamic dependency, and a service dependency graph is constructed, including: The key calling point of the target service is determined; The dependency tracking probe is injected at the key calling point, and the service dependency graph is constructed to record the dependency relationship between services.

8. The method of claim 1, wherein, The circular dependency is detected based on the service dependency graph, and in the case that there is circular dependency, the resource acquisition range is determined through the dependency decoupling strategy, including: The depth-first search algorithm is used to traverse the service dependency graph to detect strongly connected components to identify circular dependency; In the case that the circular dependency is detected, the influence range and the risk level of the circular dependency ring are calculated; The dependency decoupling strategy is determined according to the risk level, and the dependency decoupling strategy includes the asynchronous transformation strategy, the middleware introduction strategy and the interface splitting strategy; determine a list of dependent services to be excluded based on the dependent decoupling strategy; generate the resource acquisition range according to the list of dependent services to be excluded, the resource acquisition range being used to define a service range included in a resource extraction process and an excluded service range.

9. A server, characterized by comprise: a memory configured to store instructions; and a processor configured to invoke the instructions from the memory and enable the service-oriented distributed resource automatic extraction and packaging method according to any one of claims 1 to 8 when the instructions are executed.

Images