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

Abstract

The invention discloses a service-oriented distributed resource automatic extraction and packaging method and a server, and relates to the technical field of micro-services, and the method comprises the following steps: querying to obtain a service packaging task state according to a service identifier; determining whether a packing task being executed exists or not; if not, performing dynamic dependency analysis on the target service corresponding to the service identifier during operation, and constructing a service dependency graph; detecting cyclic dependency based on the service dependency graph, and if the cyclic dependency exists, determining a resource acquisition range; obtaining multi-dimensional service resources from the plurality of distributed data sources; carrying out resource aggregation processing on the multi-dimensional service resources to generate a service basic information file, and packaging the multi-dimensional service resources and the service basic information file to generate a service resource package; and uploading the service resource packet to a distributed service management platform for deployment, and creating an asynchronous task. According to the method, the dependency relationship dynamically generated during operation can be effectively captured, the error rate is reduced, and the efficiency is improved.

Description

TECHNICAL FIELD

[0001] Embodiments of the present application relate to the technical field of microservices, and particularly relate to a service-oriented distributed resource automatic extraction and packaging method and server. BACKGROUND

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

[0003] In the microservice 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, and environment replication 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 missing 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] Embodiments of the present application provide a service-oriented distributed resource automatic extraction and packaging method and server for effectively capturing runtime dynamically generated dependencies, reducing error rates, and improving efficiency.

[0008] To achieve the above purpose, embodiments of the present application adopt the following technical solutions: 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: In response to receiving the service packaging request, a service packaging task state is queried according to a service identifier in the service packaging request; It is determined whether there is an executing packaging task according to the service packaging task state; In the case where there is no executing packaging task, a runtime dynamic dependency analysis is performed on a target service corresponding to the service identifier, and a service dependency graph is constructed; Based on the service dependency graph, a circular dependency is detected, and in the case where there is a circular dependency, a resource acquisition range is determined through a dependency decoupling strategy; According to the service identifier and the resource acquisition range, 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; The multi-dimensional service resources are subjected to resource aggregation processing 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; The service resource package is uploaded to a distributed service management platform for deployment, and an asynchronous task is created to monitor the execution state of the deployment processing.

[0009] In a possible implementation manner of the first aspect, the acquiring, according to the service identifier and the resource acquisition range, of multi-dimensional service resources from a plurality of distributed data sources comprises: Service information is queried according to the service identifier and the resource acquisition range to acquire service code and service version information; According to the service identifier, the resource acquisition range and a preset on-shelf state identifier, an API interface information list that has been on-shelf is queried to obtain the API definition resources; According to the service identifier and the resource acquisition range, associated data source configuration information list is queried to obtain the data source configuration resources; According to the service identifier, the resource acquisition range and the API interface information list, business logic design data is extracted through a target database, and the business logic design data is converted into a SQL script file to obtain the business logic script resources.

[0010] In another possible implementation manner of the first aspect, the extracting, according to the service identifier, the resource acquisition range and the API interface information list, of business logic design data through a target database and the converting of the business logic design data into a SQL script file to obtain the business logic script resources comprises: According to a preset API design enumeration type list, a target database table name list is determined; querying table structure information corresponding to each database table name in the list of target database table names, and obtaining a list of column names; constructing a query condition parameter according to an API identifier in the list of API interface information, and performing a query operation in a corresponding database table according to the query condition parameter to obtain business logic design data; parsing the business logic design data into an INSERT type SQL statement, and writing the SQL statement into a SQL script file to obtain the business logic script resource.

[0011] In a possible implementation of the first aspect, the determining the list of target database table names according to the list of API design enumeration types comprises: extracting a database table name from the list of API design enumeration types, wherein 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; filtering a list of target database table names from the list of database table names according to an interface type in the list of API interface information.

[0012] In a possible implementation of the first aspect, the obtaining the multi-dimensional service resource from the plurality of distributed data sources according to the service identifier and the resource acquisition range further comprises: determining whether to perform ETL process resource extraction according to a preset ETL data extraction configuration switch; in a case where the ETL data extraction configuration switch is in an open state, querying a list of associated ETL system information according to the service identifier and the resource acquisition range; calling a batch export interface of an ETL management platform through an HTTP request, and obtaining an ETL process configuration file according to a list of system identifiers in the list of ETL system information; saving the ETL process configuration file to a preset resource directory path to obtain the ETL process resource.

[0013] In a possible implementation of the first aspect, the performing resource aggregation processing on the multi-dimensional service resource to generate a service basic information file, and packing the multi-dimensional service resource and the service basic information file to generate a service resource package comprises: exporting a service construction file to a temporary directory path according to the API definition resource and the data source configuration resource; copying the business logic script resource to the temporary directory path; creating a service basic information file in an XML format, wherein the service basic information file contains service code information; saving the service basic information file to the temporary directory path; saving the ETL process resource to the temporary directory path; compressing all files under the temporary directory path by a preset compression algorithm to generate a service resource package, and deleting the temporary directory path.

[0014] In a possible implementation of the first aspect, the uploading the service resource package to the distributed service management platform for deployment comprises: querying an associated product identifier and a project identifier according to the service identifier and the resource acquisition range; obtaining an uploading service address of the distributed service management platform; constructing an uploading parameter of a packaging type containing the product identifier, the project identifier and the service resource package; sending the service resource package and the uploading parameter to the distributed service management platform; parsing a response result returned by the distributed service management platform to obtain a deployment task identifier.

[0015] In a possible implementation of the first aspect, the performing runtime dynamic dependency analysis on the target service corresponding to the service identifier to construct a service dependency graph comprises: determining a key calling point of the target service; injecting a dependency tracking probe at the key calling point, and constructing a service dependency graph to record the dependency relationship between services.

[0016] In a possible implementation of the first aspect, the detecting a circular dependency based on the service dependency graph, and determining a resource acquisition range by a dependency decoupling strategy in the case where there is a circular dependency comprises: detecting a strongly connected component to identify a circular dependency by traversing the service dependency graph using a depth-first search algorithm; calculating an influence range and a risk level of a circular dependency ring in the case where a circular dependency is detected; determining a dependency decoupling strategy according to the risk level, the dependency decoupling strategy comprising an asynchronous modification strategy, a middleware introduction strategy and an interface splitting strategy; determining a list of dependent services to be excluded based on the dependency decoupling strategy; generating the resource acquisition range according to the list of dependent services to be excluded, the resource acquisition range being used to limit a service range contained in a resource extraction process and an excluded service range.

[0017] Secondly, this application provides a server, comprising: The memory is configured to store instructions; and The processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the aforementioned service-oriented distributed resource automated extraction and packaging method.

[0018] Through the above technical solutions, runtime dynamic dependency analysis can accurately capture all dependencies generated by services during actual operation, including complex scenarios such as dynamic configuration dependencies, runtime service discovery, and conditional resource invocation, significantly improving the accuracy and completeness of dependency identification. The introduction of circular dependency detection and decoupling strategies effectively avoids deadlocks and startup failures that may occur during service deployment. Through intelligent risk assessment and strategy selection, it ensures the integrity of the service package while avoiding the inclusion of harmful dependencies, greatly improving the deployment success rate. Automated extraction of multi-dimensional service resources covers a full range of service resources, including API definitions, data source configurations, business logic scripts, and ETL processes, achieving complete packaging of service resources and ensuring the normal operation of services in the target environment. Furthermore, resource aggregation processing and standardized packaging processes unify resources originally scattered across different systems and formats into standardized service packages, greatly simplifying the complexity of service migration, backup, and deployment operations and improving operational efficiency. The establishment of an asynchronous task monitoring mechanism provides full-process visualized status tracking for service deployment, enabling timely detection and handling of anomalies during deployment, improving system reliability and user experience. In summary, this technical solution can not only effectively capture dynamically generated dependencies at runtime in a microservice architecture, reducing error rates and improving efficiency, but also significantly improve the management efficiency and stability of the microservice ecosystem.

[0019] Other features and advantages of the embodiments of this application will be described in detail in the following detailed description section. Attached Figure Description

[0020] Figure 1 A flowchart illustrating a service-oriented distributed resource automated extraction and packaging method provided in an embodiment of this application; Figure 2 A flowchart illustrating the circular dependency detection and decoupling strategy provided in this application embodiment. Detailed Implementation

[0021] In order to make the purposes, 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 implementation described herein is only used to explain and illustrate the embodiments of the present application, and is 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 creative labor fall within the scope of protection of the present application.

[0022] It should be noted that if the embodiments of the present application involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative positional relationship, motion condition, etc. between components in a certain specific posture (as shown in the drawings), and if the specific posture changes, the directional indications will also change accordingly.

[0023] 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 of the indicated technical features or implicitly indicating the number of the 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 fact that a person of ordinary skill in the art can realize it, 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 scope of protection claimed by the present application.

[0024] Figure 1 A flowchart of a service-oriented distributed resource automatic extraction and packaging method according to an embodiment of the present application is schematically shown. As shown in Figure 1 The embodiment of the present application provides 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, and the method can include the following steps.

[0025] S110, in response to receiving a service packaging request, querying a service packaging task state according to a service identifier in the service packaging request; S120, determining whether there is an executing packaging task according to the service packaging task state; S130, in the case that 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; S140, detecting a circular dependency based on the service dependency graph, and determining a resource acquisition range through a dependency decoupling strategy in the case that there is a circular dependency; S150, acquire the multi-dimension service resource from the multiple distributed data sources according to the service identity and the resource acquisition range, wherein the multi-dimension service resource comprises API definition resource, data source configuration resource, business logic script resource and ETL flow resource; S160, perform resource aggregation processing on the multi-dimension service resource to generate a service basic information file, and pack the multi-dimension service resource and the service basic information file to generate a service resource package; S170, upload the service resource package to the distributed service management platform for deployment, and create an asynchronous task to monitor the execution state of the deployment processing.

[0026] In one of the implementation manners of the embodiment, runtime dynamic dependency analysis is performed on the target service corresponding to the service identity, and a service dependency graph is constructed, including the following steps: S1, based on Java Agent technology, load a dependency tracking agent program when the JVM is started; S2, determine the key calling points of the target service through bytecode enhancement technology, the key calling points comprising HTTP client calling point, database connection calling point, message queue client calling point, cache client calling point and configuration center client calling point; S3, inject a dependency tracking probe at the key calling point, the dependency tracking probe being used to capture resource identity information and record calling timestamp, calling time consumption and calling result state; S4, send the captured dependency calling information to a distributed dependency collector; S5, construct a service dependency graph based on the dependency calling information, the service dependency graph comprising service nodes, resource nodes and configuration nodes, and dependency relationship edges connecting the nodes.

[0027] In the embodiment, the resource identity information can be target address, port, database name, queue name, etc.

[0028] For step S3, it comprises the following steps: S31, through the ASM bytecode operation framework, perform runtime bytecode modification on the key classes of the target service, the key classes comprising HTTP client calling class, database connection class, message queue client class, cache client class and configuration center client class; S32, insert dependency recording code at the method entrance and exit of the key class, the dependency recording code being used to capture the called resource identity information, record calling timestamp, calling time consumption, calling result state, and generate a unique calling link identity.

[0029] For step S5, it comprises the following steps: 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; 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; S53, a loop 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 loop dependency, and generate a service dependency graph.

[0030] 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 status 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.

[0031] 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.

[0032] The query process uses an index-optimized SQL query statement, which quickly locates 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.

[0033] 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.

[0034] 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.

[0035] 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).

[0036] 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.

[0037] 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 the classic depth-first search algorithm to traverse the service dependency graph and identifies 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.

[0038] 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.

[0039] 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.

[0040] 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 API path, HTTP method, request parameter definition, response format definition, authentication method, flow limiting configuration, etc.

[0041] The data source configuration resource acquisition 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.

[0042] 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.

[0043] 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.

[0044] 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.

[0045] 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.

[0046] 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.

[0047] 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., regularly (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.

[0048] 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 call 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 integrate 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 efficiency. The establishment of the asynchronous task monitoring mechanism provides full-process visual state tracking for 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 can effectively capture runtime dynamically generated dependencies under microservice architecture, reduce error rate and improve efficiency, but also significantly improves the management efficiency and stability of the microservice ecosystem.

[0049] In one of the implementation manners of the embodiment, the multi-dimensional service resources are obtained from the plurality of distributed data sources according to the service identifier and the resource acquisition range, including the following steps: S210, querying service information according to the service identifier and the resource acquisition range to obtain service code and service version information; S220, 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 API definition resources; S230, query the associated data source configuration information list according to the service identification and resource acquisition range, and obtain the data source configuration resource; S240, according to the service identification, resource acquisition range and API interface information list, obtain the business logic design data through the target database extraction, and convert the business logic design data into a SQL script file to obtain the business logic script resource.

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

[0051] The query result contains the complete metadata information of the service, among which the service code is the business identification of the service, the service version information follows the semantic version control specification, and contains the main version number, secondary version number, 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.

[0052] According to the service identification, resource acquisition range and preset on-shelf state identification, the API interface information is queried. API interface information is usually stored in API gateway, service registry center or special API management platform. The preset on-shelf state identification includes "PUBLISHED", "ACTIVE", "DEPRECATED", "BETA" and other states, and only the API interfaces in the valid state are obtained when querying.

[0053] The query process uses multi-table association query, involving service table, API interface table, interface version table, interface parameter table and other data tables. The query result forms a complete API interface information list, each interface record including 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.

[0054] According to the service identification and resource acquisition range, the associated data source configuration information is queried. Data source configuration information covers all external systems and resource connection parameters that need to be accessed during service running, including database connection configuration, cache system configuration, message queue configuration, external API configuration, file storage configuration and other types.

[0055] 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, and other detailed parameters. For cache system configuration, it includes cache type, cluster node information, authentication information, serialization method, expiration policy, and other configurations. Message queue configuration includes queue type, Broker address, queue name, exchange configuration, consumer group configuration, and other information.

[0056] 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.

[0057] According to the service identification, 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 to be queried based on the pre-set API design enumeration type list, including data source configuration tables, API parameter pool tables, API construction step tables, API construction version tables, HTTP interface tables, SQL interface tables, WebService interface tables, etc.

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

[0059] 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, and other technical details during the conversion process. 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.

[0060] In this embodiment, the service information query provides an accurate metadata basis for the entire resource acquisition process, ensuring that the target of subsequent resource extraction is clear and the range is accurate. The systematic acquisition of API interface information ensures the integrity of the service contract, providing standardized interface definitions for the 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.

[0061] 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: S310, according to the preset API design enumeration type list, determine the target database table name list; 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; 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; 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.

[0062] 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, including basic configuration class, interface definition class, business logic class, version management class, monitoring and statistics class, etc. multiple dimensions.

[0063] 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.

[0064] 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.

[0065] 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.

[0066] 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.

[0067] 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.

[0068] 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 attack risks and improve query performance.

[0069] 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.

[0070] 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.

[0071] 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.

[0072] For fields of different data types, appropriate processing strategies are used: string type fields are processed for special character escaping, with single quotes escaped to two single quotes and backslashes doubly escaped to ensure the grammatical correctness of the SQL statement; numerical type fields are verified for format to ensure the validity and precision of the numerical value; date and time type fields are standardized in format to the standard format supported by the target database; Boolean type fields are converted to the corresponding representation form according to the support of the target database.

[0073] For columns that allow NULL, NULL keyword is used directly; for columns that do not allow NULL, appropriate default values or null values are used. The generation of INSERT statements follows the standard SQL syntax specification, adopts the form of explicit column name list, and ensures the readability and maintainability of the statement.

[0074] The generated SQL statements are sorted according to the dependency relationship of the tables, the dependency graph of the tables is constructed by analyzing the foreign key constraint relationship, the correct execution order is determined using the topological sorting algorithm, and the foreign key constraint violation error is avoided when executing 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.

[0075] 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.

[0076] 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 to 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.

[0077] In one embodiment of the present embodiment, the target database table name list is determined according to the pre-defined API design enumeration type list, including the following steps: S410, extracting the database table name from the API design enumeration type list, 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; S420, filtering the target database table name list from the database table name according to the interface type in the API interface information list.

[0078] 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.

[0079] 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 for API runtime access, 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.

[0080] 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.

[0081] The API construction version table manages the version history and change record of the API, including version number, release time, change content, compatibility information, rollback configuration, and other version management data. The HTTP interface table specially 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.

[0082] 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.

[0083] 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.

[0084] 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.

[0085] 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 table, API parameter pool table, API construction step table, etc.; SQL / DATABASE type interfaces mainly access SQL interface table, data source configuration table, API construction version table, etc.; WEBSERVICE / SOAP type interfaces mainly access WebService interface table, API parameter pool table, etc.

[0086] 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 the integrity of the data.

[0087] 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 first and auxiliary configuration tables being placed last, optimizing the subsequent data extraction order.

[0088] The final generated list of target database table names is a carefully selected and optimized sorted table set, which ensures the integrity of data extraction and avoids unnecessary data processing overhead.

[0089] In this embodiment, the systematic extraction of API design enumeration type list ensures comprehensive coverage of business logic data sources, and provides 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, avoids the resource waste of traditional full table scanning, and ensures the integrity and consistency of business logic data. The multi-level screening and dependency relationship analysis mechanism ensures the data integrity in complex business scenarios, providing reliable technical support for accurate migration and environment replication of microservices.

[0090] In one embodiment 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, further comprising the following steps: S510, determining whether to perform ETL process resource extraction according to the preset ETL data extraction configuration switch; S520, in the case that the ETL data extraction configuration switch is in the open state, querying the associated ETL system information list according to the service identifier and the resource acquisition range; S530, calling the batch export interface of the ETL management platform through HTTP request, and obtaining the ETL process configuration file according to the system identifier list in the ETL system information list; S540, saving the ETL process configuration file to the preset resource directory path to obtain the ETL process resource.

[0091] 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.

[0092] 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.

[0093] 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.

[0094] 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.

[0095] In the case of the ETL data extraction configuration switch being 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.

[0096] 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.

[0097] 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.

[0098] 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.

[0099] 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.

[0100] 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.

[0101] 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.

[0102] 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 will be parsed as configuration object, for file stream format response will be saved as file directly.

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

[0104] 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.

[0105] 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.

[0106] 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.

[0107] During the saving process, the file name conflict problem is handled, 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.

[0108] 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.

[0109] 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: S610, according to the API definition resource and the data source configuration resource, export the service construction file to the temporary directory path; S620, copy the business logic script resource to the temporary directory path; S630, create an XML format service basic information file, wherein the service basic information file contains service code information; S640, save the service basic information file to the temporary directory path; S650, save the ETL process resource to the temporary directory path; S660, compress all files under the temporary directory path to generate a service resource package by a preset compression algorithm, and delete the temporary directory path.

[0110] 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 processing concurrently.

[0111] 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.

[0112] 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, using 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 password, key and other sensitive data with placeholders, and generate the corresponding environment variable configuration file to provide a template for subsequent security deployment.

[0113] The platform also generates a service dependency configuration file to record the dependency relationship of the service to external systems, including the dependent service name, version requirement, connection parameter and other information. All generated configuration files will be subjected to format verification and syntax checking to ensure the correctness and integrity of the files.

[0114] Copy the business logic script resources 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 type, etc.

[0115] 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 uses buffer stream technology to improve copying performance while verifying file integrity.

[0116] During the copying process, the file name conflict problem is handled, and an intelligent renaming strategy is adopted to add a serial number or timestamp suffix based on maintaining the original semantics, ensuring that all script files can be saved correctly. The platform also generates a script execution manifest file to record the execution order, dependency relationship, execution condition, and other metadata information of all script files.

[0117] For large script files, block copying technology is used to avoid memory overflow problems and provide copying progress feedback. After copying is complete, appropriate file permissions are set to ensure that script files have readable and executable permissions.

[0118] Create a service basic information file in XML format. This file serves as a descriptive document for the service resource package, containing 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.

[0119] 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.

[0120] The generation of XML files uses DOM or SAX parsers to ensure that the generated XML documents conform 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 escape of XML special characters. The generated XML files also contain digital signatures or checksum information to verify the integrity and authenticity of the files.

[0121] 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.

[0122] 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.

[0123] 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, as it has good cross-platform compatibility, high compression ratio, and extensive tool support.

[0124] 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.

[0125] 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.

[0126] The compression process also generates a compression manifest, which 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 follows standardized naming conventions and typically includes service identification, version number, timestamp, and other information.

[0127] After compression is complete, the platform calculates the MD5 and SHA256 checksums of the entire resource package and generates the corresponding verification files, providing 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 this does not affect the completion of the entire packaging process.

[0128] 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 standardized deployment of services. The ordered organization of business logic scripts and metadata management provide reliable guarantees for 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 efficient use of system resources through integrity verification and temporary resource cleanup.

[0129] 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: S710, querying the associated product identification and project identification according to the service identification and resource acquisition range; S720, obtaining the upload service address of the distributed service management platform; S730, constructing upload parameters containing product identification, project identification, and packaging type of service resource package; S740, sending the service resource package and upload parameters to the distributed service management platform; S750, parsing the response result returned by the distributed service management platform to obtain a deployment task identification.

[0130] According to the service identification and resource acquisition range, the associated product identification and project identification are queried. Product identification and project identification are important organizational dimensions in enterprise-level service management systems. Product identification usually represents business product lines or business domains, and project identification represents specific projects or applications. This hierarchical organizational structure helps with the classification management and permission control of services.

[0131] The platform accesses the organization architecture management system or project management database of the enterprise, which usually maintains a complete service-project-product mapping table. The query process uses multi-table association query technology, involving multiple data tables such as service registry table, project service mapping table, product project mapping table, and organization architecture table, to establish a complete association relationship chain through LEFT JOIN or INNER JOIN operations.

[0132] The construction of the query condition not only contains the service identifier as the main query parameter, but also combines the organization boundary and permission range 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, and a service may belong to multiple projects or products. The platform determines the main affiliation relationship according to priority rules or recent use records.

[0133] For the case where the query result is empty, the platform will adopt 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 permission, management permission, and access permission, which will be used for subsequent deployment operation verification.

[0134] 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.

[0135] 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.

[0136] 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.

[0137] The platform also performs service discovery operations by calling the API of the service registry center or querying DNS records to obtain the latest service address list. This dynamic discovery mechanism can adapt to changes in platform addresses and dynamic scaling of nodes. The address acquisition process includes a health check segment, where the platform sends a health check request to the candidate address to verify the availability and response time of the service, and selects the address with the fastest response and normal status as the upload target.

[0138] For platforms supporting multi-region deployment, geographical location factors are also considered, with the nearest service node being prioritized to reduce network latency and transmission time. The obtained upload service address contains the complete URL path, as well as API version information, authentication requirements, request format requirements, and other interface specification information.

[0139] The upload parameters are constructed to include product identification, project identification, and service resource package packaging types. The construction of upload parameters uses a structured data format, usually using JSON format to organize parameter information, ensuring parameter readability and parsability.

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

[0141] Product identification and project identification are standardized to ensure compliance with the naming conventions and character set requirements of the target platform. Special characters in the identification are URL encoded or Base64 encoded. The packaging type parameter of the service resource package indicates the format and content type of the resource package. Common types include complete service package, only configuration file, only script file, incremental update package, etc. These type information helps the target platform choose the correct parsing and deployment strategy.

[0142] The parameter construction process also adds security-related parameters such as digital signature, encryption identifier, permission token, etc. to ensure the security and credibility of the upload process. For large file uploads, chunk upload-related parameters such as chunk size, chunk number, breakpoint resume identifier, etc. are added to support reliable large file transmission.

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

[0144] 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, with the first part containing JSON data of upload parameters and the second part containing the service resource package file.

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

[0146] 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 network or large file transmission scenarios. The exception handling of the transmission process includes network timeout, connection interruption, server error, and other situations. The platform will use appropriate retry strategies based on the type of exception.

[0147] The response result returned by the distributed service management platform is parsed to obtain the deployment task identifier. The response result 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.

[0148] The response parsing process first verifies whether the Content-Type of the response is application / json, and 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.

[0149] 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 provide support for subsequent task tracking and monitoring.

[0150] The parsing process includes error handling mechanisms. For JSON format errors, missing necessary fields, and type mismatches, appropriate exceptions are thrown with detailed error descriptions. The deployment task identifier obtained through parsing is subjected to format verification to ensure it meets the identifier specification requirements.

[0151] In this embodiment, the query of product and project identification establishes the correct attribution of services in the enterprise organizational structure, ensuring the compliance and management standardization of deployment operation permissions. Dynamic acquisition of platform addresses and health checks 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 identification provide a reliable tracking foundation for subsequent deployment monitoring and management, enabling visual management of the entire service deployment life cycle.

[0152] In one implementation of the present embodiment, runtime dynamic dependency analysis is performed on the target service corresponding to the service identification to construct a service dependency graph, including the following steps: S810, determining the key calling point of the target service; S820, injecting a dependency tracking probe at the key calling point and constructing a service dependency graph to record the dependency relationship between services.

[0153] The key calling point of the target service is determined. The key calling point refers to a specific location in the service code that calls 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.

[0154] 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. It scans all class files of the service to 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.

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

[0156] Message queue client invocation points include RabbitMQ producers and consumers, Kafka producers and consumers, ActiveMQ clients, and the like. The platform identifies key operation points such as message sending, receiving, and confirmation. Cache client invocation points involve Redis clients, Memcached clients, local caches, and the like, and identify cache reading, writing, and deletion operations. Configuration center client invocation points include Nacos configuration acquisition, Apollo configuration reading, Spring Cloud Config, and the like, and identify configuration access operations.

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

[0158] Dependency tracking probes are injected at key invocation points and a service dependency graph is constructed. A dependency tracking probe is a lightweight monitoring code that is inserted into the method entry and exit of a key invocation point through bytecode injection technology, and is used to capture and record detailed information about dependency calls.

[0159] 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, and inserts probe code at the beginning and end of the method.

[0160] The design of the probe code follows the principle of minimal performance impact, and uses an asynchronous processing mechanism to separate the collection and transmission of dependency information from the execution of business logic, avoiding 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.

[0161] 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, and the like, and each node contains rich attribute information such as node type, name, version, address, and status.

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

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

[0164] 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, dependency relationships in various complex scenarios can be captured. The non-invasive injection technology of the dependency tracking probe ensures zero modification and minimal performance impact on business code, and through asynchronous processing and lightweight design, sustainable monitoring in production environment is realized. Real-time construction and dynamic updating 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 safe migration and environment replication of services.

[0165] In one of the embodiments of the present embodiment, the service dependency graph is used to detect circular dependencies, and in the case of circular dependencies, the resource acquisition range is determined through a dependency decoupling strategy, including the following steps: S910, using a depth-first search algorithm to traverse the service dependency graph, detecting strongly connected components to identify circular dependencies; S920, in the case of detecting circular dependencies, calculating the influence range and risk level of the circular dependency ring; S930, determining the dependency decoupling strategy according to the risk level, the dependency decoupling strategy including the asynchronous transformation strategy, the middleware introduction strategy and the interface splitting strategy; S940, determining the list of dependent services to be excluded based on the dependency decoupling strategy; 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.

[0166] The 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.

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

[0168] 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 visit to the node, and the lowest link value records the discovery time of the earliest ancestor node reachable 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.

[0169] A strongly connected component containing multiple nodes indicates the existence of a circular dependency, and a single-node strongly connected component indicates the absence of a 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 handle 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.

[0170] In the case of detecting a circular dependency, the impact range and risk level of the circular dependency loop are calculated. The calculation of the impact range involves multiple dimensions of 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.

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

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

[0173] The user impact analysis determines the number of users and business functions that may be affected by the cyclic dependency fault. The cyclic dependency that affects the core user functions has the highest risk level. The risk level is calculated using a weighted scoring model that considers the indicators of each dimension. The formula is: ; wherein 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, and different risk levels correspond to different handling strategies and priorities.

[0174] The dependency decoupling strategy is determined according to the risk level. The dependency decoupling strategy is a set of predefined technical solutions that break the cyclic dependency relationship and restore the hierarchical architecture of the system. The platform maintains a strategy decision table that selects the appropriate decoupling strategy based on risk level, characteristics of cyclic dependency, technology stack of services, and other factors.

[0175] The asynchronous transformation strategy is suitable for low to medium risk cyclic dependencies. It breaks the cyclic 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 transformation 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.

[0176] The middleware introduction strategy is suitable for medium to high risk cyclic dependencies. It decouples direct dependency relationships by introducing middleware components between cyclic dependent services. Common middleware includes API gateways, service buses, data buses, and event buses. API gateways can manage service-to-service calls, provide routing, load balancing, and circuit breaking functions; service buses can enable loose coupling communication between services; data buses can solve the cyclic dependency problem of data sharing.

[0177] The interface splitting strategy is suitable for high-risk complex cyclic dependencies. It fundamentally eliminates cyclic dependencies by redesigning service interfaces and responsibility boundaries. Specific implementations include redefining service boundaries by business domain, extracting common functions into independent services, and splitting large services into multiple small services. This strategy requires in-depth analysis and reconstruction of business logic, and the transformation cost is high, but it can completely solve the cyclic dependency problem from the architecture level.

[0178] The strategy selection process also considers technical feasibility, business impact, time cost, maintenance cost, and other factors to determine the optimal decoupling solution through multi-dimensional evaluation.

[0179] A list of dependent services to be excluded is determined based on the selected decoupling strategy. The list of dependent services to be excluded refers to a set of services that should not be included in the current packaging task. Excluding these services helps break the circular dependency and ensures the independence and deployability of the service resource package.

[0180] The determination process of the exclusion list varies depending on the selected decoupling strategy. For the asynchronous transformation strategy, the platform analyzes which service calls in the circular dependency loop can be changed to asynchronous mode. The target services that are asynchronous can be excluded from the current packaging task because asynchronous calls do not require the target service to exist simultaneously during deployment.

[0181] For the middleware introduction strategy, the platform identifies pairs of services in the circular dependency loop that can be decoupled through middleware. Services connected through middleware can be deployed independently, so some services can be excluded from the current packaging range. For the interface splitting strategy, the platform analyzes the splitting scheme of the service interface to determine which functions can be deployed independently and which functions need to be retained in the current service.

[0182] The generation of the exclusion list also takes into account the transitive dependency relationship between services. By analyzing the dependency graph, it determines which other services may be affected if a certain service is excluded, avoiding dependency loss due to improper exclusion. The platform verifies the feasibility of the exclusion list and tests the correctness of the exclusion scheme through simulation deployment.

[0183] A resource acquisition range is generated based on the list of dependent services to be excluded. The resource acquisition range is a structured configuration object that clearly defines which services and resources should be included and which services and resources should be excluded during resource extraction, providing precise guidance for subsequent resource extraction operations.

[0184] The generation of the resource acquisition range uses an include-exclude mode, first defining the basic include range, and then removing the services to be excluded using exclusion rules. The definition of the include range is based on a breadth-first traversal of the service dependency graph. Starting from the target service, it expands layer by layer according to the dependency relationship until it reaches the preset dependency depth limit or encounters a circular dependency boundary.

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

[0186] The generated resource acquisition range uses 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 range configuration also includes verification rules to verify the integrity and consistency of the extraction results during resource extraction.

[0187] In this embodiment, the depth-first search and strongly connected component detection algorithm ensures the accuracy and efficiency of the circular dependency identification, and can handle complex dependency relationships in large-scale microservice environments. The multi-dimensional risk assessment mechanism provides a scientific decision basis for the processing of circular dependencies, and ensures the rationality and effectiveness of the processing strategy through quantitative analysis. The differentiated decoupling strategy selection mechanism adapts to the needs of different risk levels and technical scenarios, ensuring the decoupling effect while controlling the transformation cost. The accurate resource acquisition range 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.

[0188] The embodiment of the present application also provides a server, comprising: a memory configured to store instructions; and a processor configured to call the instructions from the memory and capable of realizing the above-mentioned service-oriented distributed resource automatic extraction and packaging method when executing the instructions.

[0189] Those skilled in the art should understand that the embodiments of the present application can be provided as a method, a system or a computer program product. Therefore, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, the present application can take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0190] The present application is described with reference to flowcharts and / or block diagrams of the method, equipment (system), computer program product according to the embodiments of the present application. It should be understood that each flow and / or block in the flowcharts and / or block diagrams and the combination of the flows and / or blocks can be realized by computer program instructions. These computer program instructions can be provided to a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing devices to produce a machine, so that the instructions executed by the computer or other programmable data processing devices produce a device implemented in the flowcharts and / or block diagrams. Figure 1 The device for implementing the function specified in one flow or multiple flows and / or blocks Figure 1 The device for implementing the function specified in one flow or multiple flows and / or blocks

[0191] These computer program instructions can also be stored in a computer-readable memory capable of guiding the computer or other programmable data processing devices to work in a specific way, so that the instructions stored in the computer-readable memory produce a manufactured product including instruction devices, which realize the flowcharts and / or block diagrams. Figure 1 one or more processes and / or blocks Figure 1 the function(s) specified in the block or blocks.

[0192] These computer program instructions can also be loaded into a computer or other programmable data processing devices to cause a series of operational steps to be performed on the computer or other programmable devices to produce a computer implemented process such that the instructions which execute on the computer or other programmable devices provide steps for implementing the flow Figure 1 one or more processes and / or blocks Figure 1 the function(s) specified in the block or blocks.

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

[0194] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) about which the computer stores information such as computer program instructions. Memory is an example of computer readable media. A computer can further include other volatile (e.g., RAM), non-volatile (e.g., read only memory (ROM), electrically programmable (EPROM), or electrically erasable programmable (EEPROM) memory) storage devices.

[0195] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as 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 programmable (EPROM), or electrically erasable programmable (EEPROM) memory, flash memory or other memory technology, compact disc read only memory (CD-ROM), digital versatile discs (DVDs) or other optical storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device. According to the definition herein, computer readable media does not include transitory media, such as modulated data signals and carrier waves.

[0196] It should also be noted that the terms "comprising", "comprises", "including", "includes" or any other variation 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 include only those elements but can include other elements not expressly listed or inherent to such process, method, article or apparatus. Without limitation, an element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article or apparatus that includes the element.

[0197] The above merely provides an example of the present application, but is not intended to limit the present application. The present application can have various modifications and changes for those skilled in the art. 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 method for automated extraction and packaging of distributed resources, characterized in that, Applied to a server, wherein the server is equipped with a distributed service management platform, the method includes: In response to receiving a service packaging request, the service packaging task status is retrieved based on the service identifier in the service packaging request; Determine whether there is an ongoing packaging task based on the service packaging task status; In the absence of an ongoing packaging task, perform runtime dynamic dependency analysis on the target service corresponding to the service identifier to construct a service dependency graph; Based on the service dependency graph, circular dependencies are detected, and in the case of circular dependencies, the scope of resource acquisition is determined through a dependency decoupling strategy. Based on the service identifier and the resource acquisition scope, multi-dimensional service resources are obtained from multiple 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; 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. The service resource package is uploaded to the distributed service management platform for deployment, and an asynchronous task is created to monitor the execution status of the deployment process.

2. The method according to claim 1, characterized in that, The step of obtaining multi-dimensional service resources from multiple distributed data sources based on the service identifier and the resource acquisition range includes: Query service information based on the service identifier and the resource acquisition range to obtain service code and service version information; Based on the service identifier, the resource acquisition scope, and the preset listing status identifier, query the list of listed API interface information to obtain the API definition resource; Based on the service identifier and the resource acquisition range, query the associated data source configuration information list to obtain the data source configuration resource; Based on the service identifier, the resource acquisition scope, and the API interface information list, business logic design data is extracted from the target database and converted into an SQL script file to obtain the business logic script resource.

3. The method according to claim 2, characterized in that, The process involves extracting business logic design data from a target database based on the service identifier, the resource acquisition scope, and the API interface information list, and then converting the business logic design data into an SQL script file to obtain the business logic script resource, including: Based on the pre-defined API design enumeration type list, determine the target database table name list; For each database table name in the target database table name list, query the corresponding table structure information to obtain the column name list; Based on the API identifier in the API interface information list, construct query condition parameters, and perform query operations in the corresponding database table according to the query condition parameters to obtain business logic design data; 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.

4. The method according to claim 3, characterized in that, The step of determining the target database table name list based on the preset API design enumeration type list includes: The database table names are extracted from the API design enumeration type list. The table types corresponding to the database table names include 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. Based on the interface types in the API interface information list, the target database table name list is obtained by filtering the database table names.

5. The method according to claim 1, characterized in that, The step of obtaining multi-dimensional service resources from multiple distributed data sources based on the service identifier and the resource acquisition range further includes: Based on the preset ETL data extraction configuration switch, determine whether to perform ETL process resource extraction; When the ETL data extraction configuration switch is turned on, query the associated ETL system information list based on the service identifier and the resource acquisition range; The ETL management platform's batch export interface is invoked via an HTTP request, and the ETL process configuration file is obtained based on the system identifier list in the ETL system information list. The ETL process configuration file is saved to a preset resource directory path to obtain the ETL process resource.

6. The method according to claim 1, characterized in that, The step of aggregating the multi-dimensional service resources to generate a service basic information file, and packaging the multi-dimensional service resources and the service basic information file to generate a service resource package includes: Based on the API definition resources and the data source configuration resources, export the service build file to a temporary directory path; Copy the business logic script resources to the temporary directory path; Create a service basic information file in XML format, wherein the service basic information file contains service code information; Save the service basic information file to the temporary directory path; Save the ETL process resources to the temporary directory path; Using a preset compression algorithm, all files under the temporary directory path are compressed into a service resource package, and the temporary directory path is then deleted.

7. The method according to claim 1, characterized in that, Uploading the service resource package to the distributed service management platform for deployment includes: Based on the service identifier and the resource acquisition scope, query the associated product identifier and project identifier; Obtain the upload service address of the distributed service management platform; Construct upload parameters that include the product identifier, the project identifier, and the service resource package type; Send the service resource package and the upload parameters to the distributed service management platform; The deployment task identifier is obtained by parsing the response returned by the distributed service management platform.

8. The method according to claim 1, characterized in that, The step of performing runtime dynamic dependency analysis on the target service corresponding to the service identifier and constructing a service dependency graph includes: Identify the key call points of the target service; Dependency tracking probes are injected at the key call points, and a service dependency graph is constructed to record the dependencies between services.

9. The method according to claim 1, characterized in that, The step of detecting circular dependencies based on the service dependency graph, and determining the resource acquisition scope through a dependency decoupling strategy when circular dependencies exist, includes: A depth-first search algorithm is used to traverse the service dependency graph and detect strongly connected components to identify circular dependencies. If a circular dependency is detected, calculate the scope of the circular dependency cycle and its risk level. Dependency decoupling strategies are determined based on the risk level, including asynchronous transformation strategies, middleware introduction strategies, and interface splitting strategies. Based on the aforementioned dependency decoupling strategy, a list of dependency services to be excluded is determined; Based on the list of dependent services to be excluded, the resource acquisition scope is generated, which is used to limit the scope of services included and excluded during the resource extraction process.

10. A server, characterized in that, include: The memory is configured to store instructions; as well as A processor is configured to retrieve the instructions from the memory and, when executing the instructions, to implement the service-oriented distributed resource automated extraction and packaging method according to any one of claims 1 to 9.

Images