Digital clone full life cycle management method and device based on containerization arrangement

Abstract

The embodiment of the application provides a kind of digital incarnation full life cycle management method and device based on containerization arrangement, by analyzing the incarnation type identification in creation request and user identification and tenant identification, execute audit process to generate gateway authentication token and drive container engine to create and start incarnation container, incarnation container initiates periodic heartbeat request carrying local configuration version number and configuration checksum, and token hot rotation is completed by heartbeat response when being lower than rotation threshold by management platform verifying token validity period, and management platform is assembled according to version comparison result Configuration snapshot is issued by heartbeat response, and is written into local configuration file by incarnation container and triggers runtime hot reload after, effectively solve the deficiency of traditional technology in multi-identity joint audit container arrangement start, heartbeat driven token hot rotation and configuration version difference hot reload linkage, etc., provide technical support for digital incarnation full life cycle safe and efficient management.

Description

Technical Field

[0001] This application relates to the field of data processing, specifically to a method and apparatus for managing the entire lifecycle of digital clones based on containerized orchestration. Background Technology

[0002] Existing digital clone management technologies have significant shortcomings in clone creation parameter parsing and containerized orchestration startup. Traditional solutions typically employ static deployment or manual configuration, lacking the ability to receive digital clone creation requests and parse clone type, user, and tenant identifiers from them to obtain clone creation parameters; execute an approval process based on these parameters and generate a gateway authentication token containing gateway, clone, user, and tenant identifiers upon approval; construct container runtime configuration based on the gateway authentication token and management platform connection address; and create and start the clone container via a unified orchestration interface by calling the container engine. This results in a lack of standardized identity binding and permission approval mechanisms in the clone creation process, and the container startup configuration struggles to carry a complete authentication context, severely limiting the security isolation and automated orchestration capabilities of digital clones in multi-tenant environments.

[0003] Existing systems suffer from technical bottlenecks in periodic heartbeat maintenance of clone containers and hot rotation of gateway authentication tokens. Most platforms lack a heartbeat-driven mechanism for dynamically monitoring and seamlessly rotating tokens. This mechanism involves the clone container reading the gateway authentication token after startup and sending a periodic heartbeat request to the management platform, carrying the local configuration version number and configuration checksum. The management platform then verifies the token's validity, checks the remaining validity period, and generates a new token when it falls below a preset rotation threshold, returning it to the clone container via a heartbeat response. This results in long-lifecycle clone containers facing the risk of authentication interruption due to token expiration. Furthermore, the management platform cannot continuously monitor the container's operational status, significantly weakening the authentication continuity and security reliability of digital clones in continuously running scenarios.

[0004] Existing technologies are insufficient in terms of configuration version difference comparison and runtime configuration hot reload. They lack a management platform that extracts the local configuration version number from heartbeat data packets and compares it with the latest version number on the server to obtain the version comparison result; assembles a complete configuration snapshot based on the version comparison result when the version numbers are inconsistent and sends it to the clone container via a heartbeat response; and a heartbeat link mechanism that the clone container receives the configuration snapshot, writes it to its local configuration file, and triggers runtime hot reload. This results in a heartbeat link mechanism that reuses the version difference-driven configuration snapshot sending and runtime hot reload, causing clone container configuration updates to rely on restart operations. During operation, the clone cannot promptly synchronize configuration changes from the platform side, severely impacting the configuration consistency and business continuity assurance capabilities throughout the entire lifecycle of the digital clone. Summary of the Invention

[0005] To address the problems in existing technologies, this application provides a method and apparatus for managing the entire lifecycle of digital clones based on containerized orchestration. This method effectively solves the shortcomings of traditional technologies in areas such as multi-identifier joint audit container orchestration startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, providing technical support for the secure and efficient management of the entire lifecycle of digital clones.

[0006] To solve at least one of the above problems, this application provides the following technical solution: Firstly, this application provides a method for managing the entire lifecycle of digital clones based on containerized orchestration, including: The system receives a digital clone creation request and parses the clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, it executes an audit process and generates a gateway authentication token containing the gateway identifier, clone identifier, user identifier, and tenant identifier after the audit is passed. Based on the gateway authentication token and the management platform connection address, it constructs a container runtime configuration and calls the container engine through the unified orchestration interface to create and start the clone container. After the clone container starts, it reads the gateway authentication token and sends a periodic heartbeat request to the management platform. The heartbeat request carries the local configuration version number and configuration checksum to form a heartbeat data packet. After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than the preset rotation threshold, a new token is generated and returned to the clone container through a heartbeat response to complete the token hot rotation. The management platform extracts the local configuration version number from the heartbeat data packet and compares it with the latest version number on the server to obtain the version comparison result. Based on the version comparison result, when the version numbers are inconsistent, a complete configuration snapshot is assembled and sent to the clone container through a heartbeat response. After receiving the configuration snapshot, the clone container writes it to the local configuration file and triggers runtime hot reload.

[0007] Furthermore, it also includes: receiving a digital clone creation request and parsing the clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters; creating a clone record in the database based on the clone creation parameters and setting the initial state to pending review; and the administrator reading the clone record from the pending review queue and performing the review operation to obtain the review result. After the audit result is determined to be approved, the clone identifier, user identifier, and tenant identifier in the clone record are read. A gateway identifier is generated based on the clone identifier, and a token payload is constructed based on the gateway identifier, the clone identifier, the user identifier, and the tenant identifier. A signature operation is performed on the token payload according to the preset validity period parameter to obtain the gateway authentication token.

[0008] Furthermore, it also includes: reading the gateway authentication token and the management platform connection address and writing them as environment variables into the container environment configuration; determining the container image identifier based on the clone type identifier and configuring processor core limit and memory limit according to preset resource constraint rules to obtain resource limit parameters; and constructing the container running configuration based on the container environment configuration and the resource limit parameters, plus health check endpoint configuration and persistent storage volume configuration. Based on the current deployment environment identifier, the container engine type is determined and the corresponding orchestration driver is selected. The container runtime configuration is read through the unified orchestration interface and the container creation method of the orchestration driver is called to obtain a container instance. Based on the container instance, the container startup method is called and the status of the clone record is updated to running state after successful startup, and the container identifier and container network address are recorded.

[0009] Furthermore, it also includes: after the clone container starts, it reads the gateway authentication token and the management platform connection address from the container environment variables, establishes a communication connection with the management platform based on the management platform connection address and starts a heartbeat timer, and the heartbeat timer triggers a heartbeat request to generate a task according to a preset heartbeat cycle; In response to the heartbeat request, the task generates a configuration checksum by reading the local configuration version number from the local configuration file and performing a checksum calculation on the local configuration content. Based on the local configuration version number and the configuration checksum, and with the addition of platform type, architecture type, runtime, number of active tasks, task queue depth, and number of currently connected users, runtime metadata is constructed. Based on the gateway authentication token and the runtime metadata, a heartbeat data packet is encapsulated and sent to the management platform.

[0010] Furthermore, it also includes: the management platform receiving the heartbeat data packet and extracting the gateway authentication token from it, performing signature verification and validity period verification on the gateway authentication token to obtain a token verification result, determining that the verification is successful based on the token verification result, parsing the payload of the gateway authentication token to obtain the gateway identifier, clone identifier and expiration timestamp, and calculating the remaining validity period based on the expiration timestamp and the current timestamp; A comparison is performed based on the remaining validity period and a preset rotation threshold. When the remaining validity period is lower than the preset rotation threshold, the payload information of the gateway authentication token is read, and the gateway identifier, clone identifier, user identifier, and tenant identifier remain unchanged. A new issuance time and a new expiration time are generated based on the current timestamp, and a signature operation is performed on the updated payload to obtain a new token. A heartbeat response is constructed based on the new token and returned to the clone container. After receiving the heartbeat response, the clone container extracts the new token and replaces the gateway authentication token stored locally.

[0011] Furthermore, it also includes: the management platform extracts the local configuration version number and configuration checksum from the heartbeat data packet, queries the clone record based on the gateway identifier in the heartbeat data packet to obtain the clone identifier, tenant identifier and user identifier, and reads the latest version number of the server and the server configuration checksum from the configuration storage based on the clone identifier; A version number comparison identifier is obtained by comparing the local configuration version number with the latest version number on the server. A checksum comparison identifier is obtained by comparing the configuration checksum with the server configuration checksum. A version comparison result is obtained by comprehensively judging the version number comparison identifier and the checksum comparison identifier.

[0012] Furthermore, it also includes: when the version number is determined to be inconsistent based on the version comparison result, querying and reading the configuration storage and large language model provider list, model calling strategy and default behavior parameters, embedded model configuration, toolchain configuration and infrastructure address configuration based on the clone identifier, the tenant identifier and the user identifier; filtering and assembling the read configuration items based on the permission scope of the tenant identifier and the user identifier to obtain a complete configuration snapshot; and constructing a heartbeat response based on the complete configuration snapshot and the latest version number of the server and sending it to the clone container. The clone container receives the heartbeat response and extracts the complete configuration snapshot and the latest version number of the server from it. It writes the complete configuration snapshot to the local configuration file and updates the local configuration version number based on the latest version number of the server. Based on the completed local configuration file, it sends a configuration reload command to the runtime management module to trigger runtime hot reload.

[0013] Secondly, this application provides a containerized orchestration-based digital clone lifecycle management device, comprising: The container clone module is used to receive digital clone creation requests and parse clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, it executes an audit process and generates a gateway authentication token containing gateway identifier, clone identifier, user identifier, and tenant identifier after the audit is passed. Based on the gateway authentication token and the management platform connection address, it constructs a container runtime configuration and calls the container engine through the unified orchestration interface to create and start the clone container. The token rotation module is used to read the gateway authentication token and send a periodic heartbeat request to the management platform after the clone container starts. The heartbeat request carries the local configuration version number and configuration checksum to form a heartbeat data packet. After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than the preset rotation threshold, a new token is generated and returned to the clone container through a heartbeat response to complete the token hot rotation. The version management module is used to manage the platform to extract the local configuration version number from the heartbeat data packet and compare it with the latest version number on the server to obtain the version comparison result. Based on the version comparison result, when the version numbers are inconsistent, a complete configuration snapshot is assembled and sent to the clone container through a heartbeat response. After receiving the configuration snapshot, the clone container writes it to the local configuration file and triggers runtime hot reload.

[0014] Thirdly, this application provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the steps of the containerized orchestration-based digital clone lifecycle management method.

[0015] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the containerized orchestration-based digital clone lifecycle management method.

[0016] Fifthly, this application provides a computer program product, including a computer program / instruction that, when executed by a processor, implements the steps of the containerized orchestration-based digital clone lifecycle management method.

[0017] As can be seen from the above technical solution, this application provides a method and apparatus for full lifecycle management of digital clones based on containerized orchestration. By parsing the clone type identifier, user identifier, and tenant identifier in the creation request, an audit process is executed to generate a gateway authentication token and drive the container engine to create and start the clone container. The clone container initiates a periodic heartbeat request carrying the local configuration version number and configuration checksum. The management platform verifies the token validity period and completes the token hot rotation through the heartbeat response when it is below the rotation threshold. The management platform assembles a configuration snapshot based on the version comparison result, which is then sent by the heartbeat response and written to the local configuration file by the clone container, triggering runtime hot reload. This effectively solves the shortcomings of traditional technologies in multi-identifier joint audit of container orchestration startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, providing technical guarantee for the secure and efficient management of the entire lifecycle of digital clones. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1This is a flowchart illustrating the containerized orchestration-based digital clone lifecycle management method in this application embodiment; Figure 2 This is a structural diagram of the containerized orchestration-based digital clone lifecycle management device in the embodiments of this application. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0021] The acquisition, storage, use, and processing of data in this application comply with relevant laws and regulations.

[0022] In view of the problems existing in the prior art, this application provides a method and device for full lifecycle management of digital clones based on containerized orchestration. By parsing the clone type identifier, user identifier and tenant identifier in the creation request, an audit process is executed to generate a gateway authentication token and drive the container engine to create and start the clone container. The clone container initiates a periodic heartbeat request carrying the local configuration version number and configuration checksum. The management platform verifies the token validity period and completes the token hot rotation through the heartbeat response when it is below the rotation threshold. The management platform assembles a configuration snapshot based on the version comparison result, which is then sent by the heartbeat response and written to the local configuration file by the clone container, triggering runtime hot reload. This effectively solves the shortcomings of traditional technologies in multi-identifier joint audit of container orchestration startup, heartbeat-driven token hot rotation and configuration version difference hot reload linkage, and provides technical guarantee for the secure and efficient management of the entire lifecycle of digital clones.

[0023] To effectively address the shortcomings of traditional technologies in areas such as multi-identifier joint audit container orchestration startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, and to provide technical assurance for the secure and efficient management of the entire lifecycle of digital clones, this application provides an embodiment of a containerized orchestration-based digital clone lifecycle management method. See [link to embodiment]. Figure 1 The containerized orchestration-based digital clone lifecycle management method specifically includes the following: Step S101: Receive a digital clone creation request and parse the clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Execute an audit process based on the clone creation parameters and generate a gateway authentication token containing the gateway identifier, clone identifier, user identifier, and tenant identifier after the audit is passed. Construct a container runtime configuration based on the gateway authentication token and the management platform connection address, and call the container engine through the unified orchestration interface to create and start the clone container. This embodiment obtains the digital clone creation request and forms the original request data through the request receiving interface of the management server. The original request data includes clone type identifier, user identifier, tenant identifier, clone name, and clone description, along with a request timestamp and request sequence number, and is stored in the request receiving cache. Field integrity checks are performed on the original request data. If a necessary field is missing, a field missing flag is registered and an error response is returned. If the field type is inconsistent, a type exception flag is registered and processing is rejected. After successful verification, the clone type identifier, user identifier, and tenant identifier are parsed from the original request data to obtain clone creation parameters. These clone creation parameters are written to the parameter parsing cache for the review process module to read.

[0024] After the clone creation parameters are ready, a clone record is created in the clone record table of the database based on the clone creation parameters, and the initial state is set to pending review. The clone record includes a system-generated clone identifier, a clone type identifier, a user identifier, a tenant identifier, and a creation timestamp. The clone identifier is generated according to a unique identifier generation rule. The administrator reads the clone record from the pending review queue and performs a review operation to obtain the review result. When the review is rejected, the clone record status is updated to rejected and the rejection reason field is recorded. When the review is approved, the clone record status is updated to approved and an approval timestamp is written. The review result is written to the review result cache for the token generation module to read.

[0025] Accordingly, based on the audit results, after the audit is deemed successful, the gateway authentication token generation process is executed. The clone identifier, user identifier, and tenant identifier are read from the clone record. A gateway identifier is generated according to the clone identifier and a preset gateway identifier format rule. A token payload is constructed based on the gateway identifier, clone identifier, user identifier, and tenant identifier. The token payload includes a token type identifier and an issuance timestamp. An expiration timestamp is determined according to a preset validity period parameter and written into the token payload. The preset validity period parameter is read from the security policy configuration file. A signature operation is performed on the token payload to obtain the gateway authentication token. The signature algorithm is selected based on the system security configuration. The gateway authentication token is written to the token storage area, and a corresponding gateway record is created in the gateway record table. The gateway record includes the gateway identifier, clone identifier, gateway status, and creation timestamp. The initial gateway status is set to the initial connection state.

[0026] After the gateway authentication token is generated, a container runtime configuration is constructed based on the gateway authentication token and the management platform connection address. The gateway authentication token and the management platform connection address are read and written as environment variables into the container environment configuration. The container image identifier is determined from the image configuration table based on the clone type identifier. Resource limit parameters are obtained by configuring processor core limits and memory limits according to preset resource constraint rules, which are determined based on the clone type and tenant resource quotas. The container runtime configuration is constructed based on the container environment configuration and the resource limit parameters, along with health check endpoint configuration and persistent storage volume configuration. This container runtime configuration is written to the deployment configuration cache for the orchestration interface module to read.

[0027] Based on the aforementioned container runtime configuration, a clone container is created and started by calling the container engine through a unified orchestration interface. The container engine type is determined based on the current deployment environment identifier, and the corresponding orchestration driver is selected. The unified orchestration interface is compatible with multiple container engines, enabling transparent switching between orchestration engines. The container runtime configuration is read through the unified orchestration interface, and the container creation method of the orchestration driver is called to obtain a container instance. If container creation fails, a creation failure flag and failure reason code are registered, and a retry process is triggered. If the number of retries exceeds a preset limit, the clone record status is updated to the deployment failure state. The container instance is used to call the container startup method. After successful startup, the clone record status is updated to the running state, and the container identifier and container network address are recorded. The clone container and the gateway record are the output of step S101, which are read at the heartbeat receiving interface in step S102 for receiving periodic heartbeat requests and verifying tokens.

[0028] Step S102: After the clone container starts, it reads the gateway authentication token and sends a periodic heartbeat request to the management platform. The heartbeat request carries the local configuration version number and configuration checksum to form a heartbeat data packet. After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than the preset rotation threshold, a new token is generated and returned to the clone container through a heartbeat response to complete the token hot rotation. In this embodiment, after the clone container starts, it reads the gateway authentication token and the management platform connection address from the container environment variables to establish a communication connection with the management platform. After the clone container completes the initialization process, it loads the environment variable configuration module and reads the gateway authentication token environment variable and the management platform connection address environment variable from the container environment variables. The gateway authentication token environment variable stores the gateway authentication token string injected in step S101, and the management platform connection address environment variable stores the interface base address of the management server. After the environment variables are read, a format verification is performed. If the gateway authentication token format does not conform to the preset token format specification, a token format exception flag is registered and the startup process is terminated.

[0029] After the gateway authentication token and management platform connection address are read, a communication connection is established with the management platform based on the management platform connection address, and a heartbeat timer is started. The network communication client is initialized based on the management platform connection address, and connection timeout and retry policy parameters are configured. A connection handshake request is initiated to the management platform to verify network reachability. After a successful connection handshake, the heartbeat timer is initialized. The heartbeat timer triggers a heartbeat request generation task according to a preset heartbeat period, which is determined based on a balance between network status monitoring accuracy requirements and communication overhead. After the heartbeat timer starts, a timer start timestamp is registered, and the system enters a periodic triggering state.

[0030] In this embodiment, in response to the heartbeat request generation task, the local configuration version number is read from the local configuration file, and a checksum calculation is performed on the local configuration content to obtain a configuration checksum. After the heartbeat timer triggers the heartbeat request generation task, the local configuration version number field is read from the local configuration file. The local configuration version number is an incrementing integer used to identify the configuration version sequence. The complete content of the local configuration file is read, and a hash operation is performed on the complete content to obtain the configuration checksum. The hash operation uses a preset hash algorithm to ensure the uniqueness and collision resistance of the checksum. After the configuration checksum calculation is completed, it is written together with the local configuration version number into the heartbeat data cache.

[0031] After obtaining the local configuration version number and configuration checksum, a heartbeat data packet is constructed based on the local configuration version number and configuration checksum, along with attached runtime metadata. The platform type, architecture type, runtime, number of active tasks, task queue depth, and number of currently connected users are read from the system status monitoring module, and these are assembled into a runtime metadata structure. The heartbeat data packet is then encapsulated according to a preset heartbeat data format based on the local configuration version number, configuration checksum, and runtime metadata, with the gateway authentication token appended as an identity credential field. After encapsulation, the heartbeat data packet is sent to the management platform and a heartbeat response is awaited.

[0032] In this embodiment, the management platform receives the heartbeat data packet and extracts the gateway authentication token from it, performing signature verification and validity period verification to obtain the token verification result. The management platform's heartbeat receiving interface receives the heartbeat data packet and extracts the gateway authentication token. It performs signature verification on the gateway authentication token to confirm that the token has not been tampered with. The signature verification is based on a preset signature key and signature algorithm. After successful signature verification, the validity period of the gateway authentication token is verified. The expiration timestamp is read from the token payload and compared with the current timestamp to determine if the token is still valid. The token verification result is obtained based on a comprehensive determination of the signature verification result and the validity period verification result. If the token verification result is a verification failure, an authentication failure response is returned and the heartbeat processing flow is terminated.

[0033] After the token verification result indicates successful verification, the payload of the gateway authentication token is parsed to obtain the gateway identifier, clone identifier, and expiration timestamp, and the remaining validity period is calculated. The gateway identifier, clone identifier, user identifier, tenant identifier, and expiration timestamp fields are extracted from the payload of the gateway authentication token. Based on the gateway identifier, the gateway status record table is queried to obtain the current gateway status. The remaining validity period is calculated by performing a difference calculation between the expiration timestamp and the current timestamp, and the remaining validity period represents the remaining time before the token expires, expressed in seconds. If it is the first heartbeat, the gateway status is updated from the initial connected state to the online state, and a clone online event is broadcast. If it is not the first heartbeat, the heartbeat timestamp and runtime metadata records are updated.

[0034] This embodiment determines whether token rotation needs to be performed by comparing the remaining validity period with a preset rotation threshold. The preset rotation threshold is read from the token rotation configuration; this threshold represents the remaining validity period threshold that triggers token rotation. The remaining validity period is compared with the preset rotation threshold. If the remaining validity period is lower than the preset rotation threshold, token rotation is determined to be required, and the token rotation flag is set to true. If the remaining validity period is not lower than the preset rotation threshold, token rotation is determined not to be required, and the token rotation flag is set to false.

[0035] When the token rotation flag is true, the payload information of the gateway authentication token is read and a new token is generated. The payload information of the gateway authentication token is read while keeping the gateway identifier, clone identifier, user identifier, and tenant identifier unchanged to ensure the continuity of token identity information. A new issuance time is generated based on the current timestamp, and a new expiration time is calculated according to preset validity period parameters. The new issuance time and the new expiration time are written into the payload, and a signature operation is performed on the updated payload to obtain a new token. The new token has the same identity information as the original token but has an updated validity period.

[0036] Accordingly, a heartbeat response is constructed based on the new token and returned to the clone container to complete the token hot rotation. The new token is written into the token update field of the heartbeat response, which also includes a heartbeat confirmation identifier and a server-side timestamp. The heartbeat response is returned to the clone container, which checks whether the token update field exists upon receiving it. If the token update field exists, the clone container retrieves the new token and replaces the locally stored gateway authentication token. Subsequent heartbeat requests use the new token as identity credentials. This token hot rotation process does not require stopping the clone container or interrupting ongoing tasks, achieving zero-downtime authentication credential updates.

[0037] Step S103: The management platform extracts the local configuration version number from the heartbeat data packet and compares it with the latest version number on the server to obtain the version comparison result. Based on the version comparison result, when the version numbers are inconsistent, a complete configuration snapshot is assembled and sent to the clone container through a heartbeat response. After receiving the configuration snapshot, the clone container writes it to the local configuration file and triggers runtime hot reload.

[0038] This embodiment extracts the local configuration version number and configuration checksum from the heartbeat data packet using the heartbeat processing module of the management platform. Based on the gateway identifier in the heartbeat data packet, it queries the gateway record table to obtain the clone identifier, and then queries the clone record table to obtain the tenant identifier and user identifier. Based on the clone identifier, it reads the latest version number of the server and the server configuration checksum from the configuration storage. If the read fails, it registers a configuration read exception flag and carries an error status code in the heartbeat response. The local configuration version number and the latest version number of the server are written to the version comparison cache for the comparison module to read.

[0039] After the local configuration version number and the latest version number on the server are ready, a version comparison operation is performed to obtain the version comparison result. A numerical comparison is performed between the local configuration version number and the latest version number on the server to obtain a version number comparison identifier. A consistency comparison is performed between the configuration checksum and the server configuration checksum to obtain a checksum comparison identifier. A comprehensive judgment is made based on the version number comparison identifier and the checksum comparison identifier to obtain the final version comparison result. When both the version number and checksum match, the version comparison result is marked as a configuration synchronization state; otherwise, it is marked as a configuration pending update state. The version comparison result is written to the comparison result cache for the configuration assembly module to read.

[0040] Accordingly, based on the version comparison results, when the configuration is in a state awaiting update, a configuration snapshot assembly process is executed. The configuration storage is queried based on the clone identifier, the tenant identifier, and the user identifier. The large language model provider list, model invocation strategy, default behavior parameters, embedded model configuration, toolchain configuration, and infrastructure address configuration are read. The read configuration items are filtered based on the permission scope of the tenant identifier and the user identifier, removing sensitive configuration items that exceed the permission scope and registering configuration filter flags. The filtered configuration items are then assembled to obtain a complete configuration snapshot, which is appended with the latest version number of the server and the server configuration checksum.

[0041] After the complete configuration snapshot is assembled, a heartbeat response is sent to the clone container, triggering a runtime hot reload. A heartbeat response data packet is constructed based on the complete configuration snapshot and the latest version number of the server. When the version comparison result indicates a configuration synchronization state, the heartbeat response data packet carries only a synchronization confirmation identifier and no configuration data. The clone container receives the heartbeat response and determines whether it carries configuration data. If so, it extracts the complete configuration snapshot and the latest version number of the server. The local configuration file is overwritten based on the complete configuration snapshot. If the write fails, a configuration write exception flag is registered, and the original configuration file is retained. The local configuration version number is updated based on the latest version number of the server, and a configuration reload command is sent to the runtime management module to trigger a runtime hot reload. The hot reload process does not require restarting the container. The updated status of the local configuration file is the output of step S103, which is read in subsequent heartbeat cycles during the configuration version reporting stage for continuous configuration synchronization status maintenance.

[0042] As described above, the containerized orchestration-based digital clone lifecycle management method provided in this application can generate a gateway authentication token by parsing the clone type identifier, user identifier, and tenant identifier in the creation request, executing an audit process, and driving the container engine to create and start the clone container. The clone container initiates a periodic heartbeat request carrying the local configuration version number and configuration checksum. The management platform verifies the token validity period and completes the token hot rotation through the heartbeat response when it is below the rotation threshold. The management platform assembles a configuration snapshot based on the version comparison result, sends it through the heartbeat response, and the clone container writes it to the local configuration file and triggers runtime hot reload. This effectively solves the shortcomings of traditional technologies in multi-identifier joint audit of container orchestration startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, providing technical guarantee for the secure and efficient management of the digital clone lifecycle.

[0043] In one embodiment of the containerized orchestration-based digital clone lifecycle management method of this application, the following may also be included: Step S201: Receive a digital clone creation request and parse the clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, create a clone record in the database and set the initial state to pending review. The administrator reads the clone record from the pending review queue and performs the review operation to obtain the review result. Step S202: After the audit is approved based on the audit result, read the clone identifier, user identifier and tenant identifier in the clone record, generate a gateway identifier based on the clone identifier, and construct a token payload based on the gateway identifier, the clone identifier, the user identifier and the tenant identifier. Perform a signature operation on the token payload according to the preset validity period parameter to obtain the gateway authentication token.

[0044] This embodiment receives digital clone creation requests through the request receiving interface of the management server and parses the clone creation parameters from them. The creation request includes clone type identifier, user identifier, tenant identifier, and clone name fields, along with a request timestamp to identify the request sequence. The creation request undergoes field integrity and format compliance checks. If the clone type identifier does not belong to the preset type enumeration, a type exception flag is registered and an error response is returned. After successful verification, the clone type identifier, user identifier, and tenant identifier are parsed from the creation request to obtain the clone creation parameters. These parameters are written to a parameter cache for the clone record creation module to read.

[0045] After the clone creation parameters are ready, a clone record is created in the clone record table of the database based on the clone creation parameters, and the initial state is set to "pending review". A clone identifier is generated according to the unique identifier generation rules, and a clone record data structure is constructed based on the clone identifier, the clone type identifier, the user identifier, and the tenant identifier. The clone record data structure is written into the clone record table of the database, with the initial state field set to "pending review" and a creation timestamp recorded. If the database write fails, a write exception flag is registered and a retry is performed; if the retry limit is exceeded, a creation failure response is returned. After the clone record is successfully written, it is synchronously written to the pending review queue for administrators to read.

[0046] Accordingly, the administrator reads the clone record from the queue to be reviewed and performs the review operation to obtain the review result. The management console pulls a list of clone records in the review queue that are in the review state. The administrator selects the clone record and views details such as clone name, clone type, user identifier, and tenant identifier. The administrator performs the review operation on the clone record according to the review specifications and submits the review conclusion. The review conclusion includes a review pass or review rejection indicator and a review comment field. Based on the review conclusion, a review result is generated and the status of the clone record is updated. If the review is rejected, the status is updated to the rejected state and the rejection reason field is registered. The review result is written to the review result cache area for the token generation module in step S202 to read.

[0047] In this embodiment, after the review result is deemed approved, the identifier information is read from the clone record for gateway identifier generation. The review result is read from the review result cache output in step S201. If the review result is deemed approved, the status of the clone record is updated to "reviewed" and a timestamp of approval is recorded. The clone identifier, user identifier, and tenant identifier are read from the clone record; the clone identifier serves as the input parameter for gateway identifier generation. If identifier reading fails, a reading exception flag is registered, and the subsequent process is terminated.

[0048] After the clone identifier, user identifier, and tenant identifier are read, a gateway identifier is generated based on the clone identifier, and a token payload is constructed. The clone identifier is format-converted according to preset gateway identifier format rules to obtain the gateway identifier, which is globally unique and used to identify the communication gateway between the clone container and the management platform. A token payload data structure is constructed based on the gateway identifier, clone identifier, user identifier, and tenant identifier, with an additional token type identifier and issuance timestamp field. The token payload is written to the payload buffer for the signature calculation module to read.

[0049] Based on the aforementioned token payload, a signature operation is performed on the token payload according to a preset validity period parameter to obtain a gateway authentication token. The preset validity period parameter is read from the security policy configuration file; this parameter is determined based on security compliance requirements and the token rotation cycle. An expiration timestamp is calculated based on the current timestamp and the preset validity period parameter and written into the token payload. A signature operation is performed on the complete token payload to obtain the gateway authentication token. The signature operation uses a preset signature algorithm and signature key to ensure the token's tamper-proof nature. The gateway authentication token is written to the token storage area, and a corresponding gateway record is created in the gateway record table. The initial gateway state is set to the initial connection state. The gateway authentication token, as the output of step S202, is read by subsequent steps at the token input interface of the container configuration building module for environment variable injection and container runtime configuration building.

[0050] In one embodiment of the containerized orchestration-based digital clone lifecycle management method of this application, the following may also be included: Step S301: Read the gateway authentication token and the management platform connection address and write them as environment variables into the container environment configuration. Determine the container image identifier based on the clone type identifier and configure the processor core limit and memory limit according to the preset resource constraint rules to obtain resource limit parameters. Based on the container environment configuration and the resource limit parameters, and with the addition of health check endpoint configuration and persistent storage volume configuration, construct the container running configuration. Step S302: Determine the container engine type based on the current deployment environment identifier and select the corresponding orchestration driver. Read the container runtime configuration through the unified orchestration interface and call the container creation method of the orchestration driver to obtain a container instance. Call the container startup method based on the container instance and update the status of the clone record to the running state after successful startup, and record the container identifier and container network address.

[0051] This embodiment reads the gateway authentication token from the token storage area and the management platform connection address from the system configuration to build the container environment configuration. The gateway authentication token string is obtained from the token storage area output in step S101, and the management platform connection address is read from the system configuration file of the management server. The gateway authentication token is written as a gateway token environment variable into the container environment configuration, and the management platform connection address is written as a platform address environment variable into the container environment configuration. If the environment variable writing fails, an environment configuration exception flag is registered, and the deployment process is aborted. The container environment configuration is written to the environment configuration cache area for the image selection module to read.

[0052] After the container environment is configured, the container image identifier is determined based on the clone type identifier, and resource limit parameters are configured. The clone type identifier is read from the clone record, and the container image identifier is determined by querying the image configuration table, which maintains the mapping relationship between clone types and container images. Processor core limits and memory limits are configured according to preset resource constraint rules to obtain resource limit parameters. These preset resource constraint rules are read from the resource policy configuration based on the clone type and tenant resource quota. When resource parameters exceed the tenant quota limit, they are truncated to the quota limit, and a resource truncation flag is registered. The resource limit parameters are written to the resource configuration cache for the configuration assembly module to read.

[0053] Accordingly, a container runtime configuration is constructed based on the container environment configuration and the resource limitation parameters, along with the health check endpoint configuration and persistent storage volume configuration. The health check endpoint configuration, which includes the check path, check cycle, timeout threshold, and number of retries, is read from the health check configuration template. The persistent storage volume configuration, which includes the storage volume identifier, mount path, and access mode, is read from the storage configuration template. The container environment configuration, the resource limitation parameters, the health check endpoint configuration, and the persistent storage volume configuration are assembled according to a preset configuration structure to obtain the container runtime configuration. The container runtime configuration is written to the deployment configuration cache for reading in step S302 of the orchestration interface module.

[0054] This embodiment determines the container engine type and selects the corresponding orchestration driver based on the current deployment environment identifier. The current deployment environment identifier is read from the system deployment configuration; this identifier indicates the container engine type used by the current runtime environment. Based on this identifier, a corresponding orchestration driver instance is selected from the orchestration driver registry. The unified orchestration interface is compatible with multiple container engines, enabling transparent switching between orchestration engines. If orchestration driver selection fails, a driver selection exception flag is registered, and a deployment failure response is returned. The orchestration driver instance is written to the driver instance cache for use by the container creation module.

[0055] After the orchestration driver selection is completed, the container runtime configuration is read through the unified orchestration interface, and the container creation method is called to obtain a container instance. The container runtime configuration is read from the deployment configuration cache through the unified orchestration interface, and the container creation method of the orchestration driver is called, passing in the container runtime configuration. The container creation method performs image pulling and container instantiation operations. If image pulling fails, an image pulling exception flag is registered, and a retry process is triggered. Upon successful container creation, a container instance object is returned, containing a container identifier and a container status descriptor. If creation fails and the number of retries exceeds a preset limit, the clone record status is updated to a deployment failure state, and the failure reason code is registered.

[0056] Based on the aforementioned container instance, the container startup method is invoked, and upon successful startup, the status of the clone record is updated to running. The orchestration driver's container startup method is then invoked based on the container instance, performing container process initialization and network configuration binding operations. During startup, the health check endpoint response status is monitored; if a health check times out, a startup timeout flag is registered, and container stop and cleanup operations are performed. Upon successful startup, the container identifier and container network address are read from the container instance, and the status of the corresponding record in the clone record table is updated to running, with the container identifier and container network address written to it. The running status of the clone record and the container network address are the output of step S302, which is then read by the heartbeat routing module in step S102 for receiving and forwarding heartbeat requests.

[0057] In one embodiment of the containerized orchestration-based digital clone lifecycle management method of this application, the following may also be included: Step S401: After the clone container starts, it reads the gateway authentication token and the management platform connection address from the container environment variables, establishes a communication connection with the management platform based on the management platform connection address, and starts a heartbeat timer. The heartbeat timer triggers a heartbeat request to generate a task according to a preset heartbeat cycle. Step S402: In response to the heartbeat request, the task generates a task to read the local configuration version number from the local configuration file and perform a checksum calculation on the local configuration content to obtain a configuration checksum. Based on the local configuration version number and the configuration checksum, and with the addition of platform type, architecture type, runtime, number of active tasks, task queue depth, and number of currently connected users, runtime metadata is constructed. Based on the gateway authentication token and the runtime metadata, a heartbeat data packet is encapsulated and sent to the management platform.

[0058] In this embodiment, after the clone container starts, it reads the gateway authentication token and the management platform connection address from the container environment variables. After the clone container completes process initialization, it loads the environment variable reading module and reads the gateway authentication token and the management platform connection address injected in step S301 from the container environment variables. A format compliance check is performed on the gateway authentication token; if the token format does not conform to the preset specification, a token format exception flag is registered and the startup process is terminated. An address format check and reachability pre-check are performed on the management platform connection address; if the address format is invalid or unreachable, a connection address exception flag is registered and a retry waiting state is entered. The gateway authentication token and the management platform connection address are written to the runtime credential cache for the communication connection module to read.

[0059] After the gateway authentication token and management platform connection address are read, a communication connection is established with the management platform based on the management platform connection address, and a heartbeat timer is started. The network communication client is initialized based on the management platform connection address, configuring connection timeout parameters, reconnection interval parameters, and maximum retries parameters. A connection handshake request is initiated to the management platform to verify the availability of the communication link. If the handshake fails, reconnection is performed according to the exponential backoff strategy, and the reconnection count is recorded. After a successful handshake, the heartbeat timer is initialized. The heartbeat timer triggers a heartbeat request generation task according to a preset heartbeat period, which is read from the heartbeat configuration file based on the real-time requirements of status monitoring and network overhead balance. The heartbeat timer start timestamp is written to the timer status record for runtime monitoring.

[0060] In this embodiment, in response to the heartbeat request generation task, the local configuration version number is read from the local configuration file, and a checksum calculation is performed on the local configuration content. After the heartbeat timer triggers the heartbeat request generation task, the local configuration version number field is read from the local configuration file. The local configuration version number is a monotonically increasing integer that identifies the configuration version sequence. The complete content of the local configuration file is read, and a hash operation is performed on the complete content to obtain the configuration checksum. The hash operation uses a preset hash algorithm to ensure the determinism and uniqueness of the checksum. If the configuration file reading fails, a configuration reading exception flag is registered and replaced with a cached historical version number and checksum. The local configuration version number and the configuration checksum are written to the heartbeat data cache for the metadata assembly module to read.

[0061] After obtaining the local configuration version number and configuration checksum, runtime metadata is constructed based on the local configuration version number and configuration checksum, along with runtime status indicators. The platform type and architecture type are read from the operating system interface; the runtime, number of active tasks, and task queue depth are read from the process status monitoring module; and the number of currently connected users is read from the session management module. The platform type and architecture type, runtime, number of active tasks, task queue depth, number of currently connected users, the local configuration version number, and the configuration checksum are assembled into a runtime metadata structure. If a status indicator reading is abnormal, it is filled with a default placeholder value, and a missing indicator flag is registered. The runtime metadata is written to the metadata cache for the data packet encapsulation module to read.

[0062] Based on the aforementioned runtime metadata, a heartbeat data packet is encapsulated using the gateway authentication token and the runtime metadata and sent to the management platform. The gateway authentication token is read from the runtime credential cache, and a heartbeat data packet is encapsulated using the gateway authentication token and the runtime metadata according to a preset heartbeat data format. The heartbeat data packet includes an authentication header, metadata payload, and a request timestamp. The heartbeat data packet is sent to the management platform through the established communication connection, and a response timeout timer is started. If transmission fails, a transmission error flag is registered, and a retry is triggered in the next cycle. If a response times out, a timeout flag is registered, and the communication connection status is checked. The heartbeat data packet, as the output of step S402, is read by the management platform at the heartbeat receiving interface for token verification, validity period checking, and configuration version comparison.

[0063] In one embodiment of the containerized orchestration-based digital clone lifecycle management method of this application, the following may also be included: Step S501: The management platform receives the heartbeat data packet and extracts the gateway authentication token from it. It performs signature verification and validity period verification on the gateway authentication token to obtain the token verification result. Based on the token verification result, it determines that the verification is successful. After that, it parses the payload of the gateway authentication token to obtain the gateway identifier, clone identifier and expiration timestamp. Based on the expiration timestamp and the current timestamp, it calculates the remaining validity period. Step S502: Perform a comparison and determination based on the remaining validity period and the preset rotation threshold condition. When the remaining validity period is lower than the preset rotation threshold condition, read the payload information of the gateway authentication token and keep the gateway identifier, clone identifier, user identifier, and tenant identifier unchanged. Generate a new issuance time and a new expiration time based on the current timestamp and perform a signature operation on the updated payload to obtain a new token. Construct a heartbeat response based on the new token and return it to the clone container. After receiving the heartbeat response, the clone container extracts the new token and replaces the gateway authentication token stored locally.

[0064] In this embodiment, the heartbeat data packet is received through the heartbeat receiving interface of the management platform, and the gateway authentication token is extracted from it for identity verification. The management platform receives the heartbeat data packet from the network communication layer and performs a data packet integrity check. If the check fails, an abnormal flag is registered for the data packet and the heartbeat data packet is discarded. After the check passes, the gateway authentication token is extracted from the identity credential field of the heartbeat data packet. The gateway authentication token is the identity credential generated in step S101 and injected into the clone container environment variable. The gateway authentication token is written to the token verification cache for the signature verification module to read.

[0065] After the gateway authentication token is extracted, signature verification and validity period verification are performed on the gateway authentication token to obtain the token verification result. The signature verification key is read from the key management module, and signature verification is performed on the gateway authentication token based on the signature verification key and a preset signature algorithm. If signature verification fails, it is determined that the token has been tampered with and a signature anomaly flag is registered. If signature verification passes, the expiration timestamp is read from the payload of the gateway authentication token. The expiration timestamp is compared with the current timestamp to determine whether the token is within its validity period. If the expiration timestamp is earlier than the current timestamp, the token is determined to have expired and an expiration anomaly flag is registered. The token verification result is obtained based on a comprehensive determination of the signature verification result and the validity period verification result. If verification fails, an authentication failure response is returned and the heartbeat processing procedure is terminated.

[0066] Accordingly, after the token verification result is deemed successful, the payload of the gateway authentication token is parsed to obtain the identification information and expiration timestamp. The gateway identifier field, clone identifier field, user identifier field, tenant identifier field, and expiration timestamp field are extracted from the payload of the gateway authentication token. If payload parsing fails, a payload exception flag is registered and a parsing error response is returned. The gateway registration status is verified by querying the gateway record table based on the gateway identifier. If the gateway record does not exist, a gateway unregistered flag is registered and the heartbeat request is rejected. The remaining validity period is calculated by performing a difference calculation between the expiration timestamp and the current timestamp. The remaining validity period represents the remaining time before the token expires. The remaining validity period is written to the validity period cache for the rotation determination module in step S502 to read.

[0067] This embodiment determines whether to trigger the token rotation process by comparing the remaining validity period with a preset rotation threshold. The remaining validity period is read from the validity period cache output in step S501, and the preset rotation threshold is read from the token rotation policy configuration. The preset rotation threshold is determined based on the proportional relationship between the security policy and the token validity period parameter. The remaining validity period is numerically compared with the preset rotation threshold. If the remaining validity period is lower than the preset rotation threshold, the rotation trigger flag is set to true; otherwise, it is set to false. The rotation trigger flag is written to the rotation status cache for the new token generation module to read.

[0068] When the rotation trigger flag is true, the payload information of the gateway authentication token is read and a new token is generated. The payload information of the gateway authentication token is read while keeping the gateway identifier, clone identifier, user identifier, and tenant identifier unchanged, ensuring that the identity information of the new token is consistent with the original token. A new issuance time is generated based on the current timestamp, and a new expiration time is calculated according to preset validity period parameters and written into the payload. A signature operation is performed on the updated payload to obtain a new token. If the signature operation fails, a signature exception flag is registered, and the new token is not carried in the heartbeat response. The new token is written to the new token cache for the response construction module to read.

[0069] Based on the aforementioned new token, a heartbeat response is constructed and returned to the clone container to complete the token hot rotation. The new token is written to the token update field of the heartbeat response, which includes a heartbeat confirmation flag, a server-side timestamp, and a response status code. When the rotation trigger flag is false, the heartbeat response does not carry the token update field. The heartbeat response is returned to the clone container, which checks the existence of the token update field upon receiving it. If it exists, the new token is extracted and replaces the locally stored gateway authentication token and the token copy in persistent storage. Subsequent heartbeat requests use the new token as identity credentials. The token hot rotation process does not require stopping the clone container or interrupting the task; the validity status of the new token is the output of step S502 for subsequent heartbeat cycles to read in the token verification phase.

[0070] In one embodiment of the containerized orchestration-based digital clone lifecycle management method of this application, the following may also be included: Step S601: The management platform extracts the local configuration version number and configuration checksum from the heartbeat data packet, queries the clone record based on the gateway identifier in the heartbeat data packet to obtain the clone identifier, tenant identifier and user identifier, and reads the latest version number of the server and the server configuration checksum from the configuration storage based on the clone identifier; Step S602: Perform a numerical comparison between the local configuration version number and the latest version number on the server to obtain a version number comparison identifier; perform a consistency comparison between the configuration checksum and the server configuration checksum to obtain a checksum comparison identifier; and make a comprehensive judgment based on the version number comparison identifier and the checksum comparison identifier to obtain a version comparison result.

[0071] In this embodiment, the management platform's heartbeat processing module extracts the local configuration version number and configuration checksum from the heartbeat data packet. The management platform receives the heartbeat data packet sent in step S402 at the heartbeat receiving interface and performs data integrity and format compliance checks on the heartbeat data packet. If the checks pass, the local configuration version number and configuration checksum fields are parsed and extracted from the metadata payload of the heartbeat data packet. If parsing fails, a data parsing exception flag is registered and a format error response is returned. The local configuration version number and configuration checksum are written to the version data cache for the clone record query module to read.

[0072] After the local configuration version number and configuration checksum are extracted, the clone record is queried based on the gateway identifier in the heartbeat data packet to obtain the clone identifier, tenant identifier, and user identifier. The gateway identifier is parsed from the authentication header of the heartbeat data packet, and the associated clone identifier is obtained by querying the gateway record table based on the gateway identifier. The tenant identifier, user identifier, and clone status are obtained by querying the clone record table in the database based on the clone identifier. If the clone record does not exist, a record missing flag is registered and an authentication failure response is returned. The clone identifier, the tenant identifier, and the user identifier are written to the identity information cache for the configuration reading module to read.

[0073] Accordingly, based on the clone identifier, the latest version number of the server and the server configuration checksum are read from the configuration storage. Based on the clone identifier, the current configuration record of the clone is queried from the configuration storage, and the latest version number field and the server configuration checksum field are read. If the configuration record does not exist, the initial version number and an empty checksum are used as default values, and a configuration missing flag is registered. The latest version number of the server and the server configuration checksum are written to the server version cache for reading by the version comparison module in step S602.

[0074] This embodiment obtains a version number comparison identifier by performing a numerical comparison between the local configuration version number and the latest version number on the server. The local configuration version number is read from the version data cache, and the latest version number on the server is read from the server version cache. A numerical comparison operation is performed between the local configuration version number and the latest version number on the server. When the two values ​​are equal, the version number comparison identifier is set to a version consistency state; when the two values ​​are not equal, the version number comparison identifier is set to a version inconsistency state. The version number comparison identifier is written to the comparison identifier cache for the comprehensive judgment module to read.

[0075] After the version number comparison identifier is generated, a consistency comparison is performed between the configuration checksum and the server-side configuration checksum to obtain a checksum comparison identifier. The configuration checksum is read from the version data cache, and the server-side configuration checksum is read from the server-side version cache. A string consistency comparison is performed between the configuration checksum and the server-side configuration checksum. If they are completely consistent, the checksum comparison identifier is set to a consistent state; if they are inconsistent, the checksum comparison identifier is set to an inconsistent state. The checksum comparison identifier is written to the comparison identifier cache for the comprehensive judgment module to read.

[0076] Based on the aforementioned version number comparison identifier and checksum comparison identifier, a version comparison result is obtained through comprehensive judgment. The version number comparison identifier and the checksum comparison identifier are read from the comparison identifier cache, and a comprehensive logic judgment operation is performed. When the version number comparison identifier is in a version-consistent state and the checksum comparison identifier is in a checksum-consistent state, the version comparison result is set to a configuration synchronization state. When the version number comparison identifier is in a version-inconsistent state or the checksum comparison identifier is in a checksum-inconsistent state, the version comparison result is set to a configuration pending update state. The version comparison result is the output of step S602, which is read by step S701 at the judgment input interface of the configuration assembly module to determine whether to perform configuration snapshot assembly and distribution.

[0077] In one embodiment of the containerized orchestration-based digital clone lifecycle management method of this application, the following may also be included: Step S701: When the version number is determined to be inconsistent based on the version comparison result, query the configuration storage and read the list of large language model providers, model calling strategies, default behavior parameters, embedded model configuration, toolchain configuration, and infrastructure address configuration based on the clone identifier, the tenant identifier, and the user identifier. Filter and assemble the read configuration items based on the permission scope of the tenant identifier and the user identifier to obtain a complete configuration snapshot. Build a heartbeat response based on the complete configuration snapshot and the latest version number of the server and send it to the clone container. Step S702: The clone container receives the heartbeat response and extracts the complete configuration snapshot and the latest version number of the server from it. It writes the complete configuration snapshot to the local configuration file and updates the local configuration version number based on the latest version number of the server. Based on the written local configuration file, it sends a configuration reload command to the runtime management module to trigger runtime hot reload.

[0078] This embodiment executes the configuration item reading process when the configuration is in a state of pending update based on the version comparison result. The version comparison result is read from the version comparison result cache output in step S602. If the version comparison result indicates that the configuration is in a state of pending update, the configuration snapshot assembly process is triggered. The configuration storage is queried based on the clone identifier, the tenant identifier, and the user identifier. The large language model provider list is read from the provider configuration table in the configuration storage, the model invocation strategy is read from the model strategy configuration table, and the default behavior parameters are read from the behavior parameter configuration table. If configuration item reading fails, a configuration reading exception flag is registered, and a default configuration template is used instead.

[0079] After reading the list of large language model providers, model invocation strategies, and default behavior parameters, the system continues to read the embedded model configuration, toolchain configuration, and infrastructure address configuration. Based on the clone identifier, the embedded model configuration is read from the embedded model configuration table in the configuration storage, the toolchain configuration is read from the toolchain configuration table, and the infrastructure address configuration is read from the infrastructure configuration table. The toolchain configuration includes a list of enabled tools and tool invocation parameters, and the infrastructure address configuration includes external service endpoint addresses and internal service discovery addresses. All configuration items are written to the original configuration cache for the permission filtering module to read.

[0080] Accordingly, based on the permission ranges of the tenant identifier and the user identifier, the read configuration items are filtered and assembled to obtain a complete configuration snapshot. The permission management module queries the configuration access permission ranges corresponding to the tenant identifier and the user identifier; these permission ranges define the categories of accessible configuration items and sensitive field masking rules. All configuration items in the original configuration cache are traversed, removing those exceeding the permission range and performing desensitization processing on sensitive fields. If desensitization fails, a desensitization exception flag is registered, and the corresponding configuration item is removed. The filtered configuration items are assembled according to a preset configuration structure to obtain a complete configuration snapshot, with a configuration generation timestamp appended to the complete configuration snapshot.

[0081] After the complete configuration snapshot is assembled, a heartbeat response is constructed based on the complete configuration snapshot and the latest version number of the server and sent to the clone container. The complete configuration snapshot is written to the configuration data field of the heartbeat response, and the latest version number of the server is written to the version number field of the heartbeat response. When the version comparison result is in a configuration synchronization state, the heartbeat response does not carry a configuration data field but only a synchronization confirmation identifier. The heartbeat response is appended with a response status code and a server timestamp and sent to the clone container through the established communication connection. If the sending fails, a response sending exception flag is registered and the configuration sending is retried in the next heartbeat cycle.

[0082] In this embodiment, the clone container receives the heartbeat response and extracts the complete configuration snapshot and the latest version number of the server from it. The clone container receives the heartbeat response from the communication connection and performs a response integrity check. If the check fails, it registers a response exception flag and waits for the next heartbeat cycle. If the check passes, it checks whether the heartbeat response carries a configuration data field. If it does, it extracts the complete configuration snapshot and the latest version number of the server from the heartbeat response. The complete configuration snapshot and the latest version number of the server are written to the configuration update cache for the configuration writing module to read.

[0083] Based on the aforementioned complete configuration snapshot, the local configuration file is overwritten and a runtime hot reload is triggered. Before writing, the current configuration file is backed up to support rollback. If the write fails, a configuration write exception flag is registered and the configuration is rolled back to the backup configuration. The local configuration version number field is updated based on the latest version number on the server to ensure that the version number reported in subsequent heartbeats is consistent with the server version. A configuration reload command is sent to the runtime management module to trigger a runtime hot reload. The runtime hot reload reloads the configuration without stopping the container process, making the new configuration effective. If the hot reload fails, a reload exception flag is registered and the original configuration running state is maintained. The updated state of the local configuration file is the output of step S702, which is read in subsequent heartbeat cycles during the configuration version reporting stage for continuous configuration synchronization state maintenance.

[0084] To effectively address the shortcomings of traditional technologies in areas such as multi-identifier joint audit container orchestration startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, and to provide technical assurance for the secure and efficient management of the entire lifecycle of digital avatars, this application provides an embodiment of a container-based digital avatar lifecycle management device for implementing all or part of the aforementioned container-based orchestration-based digital avatar lifecycle management method. See [link to embodiment]. Figure 2 The containerized orchestration-based digital clone lifecycle management device specifically includes the following: The container clone module 10 is used to receive digital clone creation requests and parse clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, it executes an audit process and generates a gateway authentication token containing gateway identifier, clone identifier, user identifier, and tenant identifier after the audit is passed. Based on the gateway authentication token and the management platform connection address, it constructs a container runtime configuration and calls the container engine through the unified orchestration interface to create and start the clone container. The token rotation module 20 is used to read the gateway authentication token and send a periodic heartbeat request to the management platform after the clone container starts. The heartbeat request carries the local configuration version number and configuration checksum to form a heartbeat data packet. After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than the preset rotation threshold, a new token is generated and returned to the clone container through a heartbeat response to complete the token hot rotation. The version management module 30 is used to manage the platform to extract the local configuration version number from the heartbeat data packet and compare it with the latest version number on the server to obtain the version comparison result. Based on the version comparison result, when the version numbers are inconsistent, a complete configuration snapshot is assembled and sent to the clone container through a heartbeat response. After receiving the configuration snapshot, the clone container writes it to the local configuration file and triggers runtime hot reload.

[0085] As described above, the containerized orchestration-based digital clone lifecycle management device provided in this application can generate a gateway authentication token by parsing the clone type identifier, user identifier, and tenant identifier in the creation request, executing an audit process, and driving the container engine to create and start the clone container. The clone container initiates a periodic heartbeat request carrying the local configuration version number and configuration checksum. The management platform verifies the token validity period and completes the token hot rotation through the heartbeat response when the value is below the rotation threshold. The management platform assembles a configuration snapshot based on the version comparison result, sends it through the heartbeat response, and the clone container writes it to the local configuration file and triggers runtime hot reload. This effectively solves the shortcomings of traditional technologies in multi-identifier joint audit of container orchestration startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, providing technical assurance for the secure and efficient management of the digital clone lifecycle.

[0086] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the containerized orchestration-based digital clone lifecycle management method.

[0087] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described containerized orchestration-based digital clone full lifecycle management method.

[0088] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described containerized orchestration-based digital clone full lifecycle management method.

[0089] In this embodiment of the invention, by parsing the clone type identifier, user identifier, and tenant identifier in the creation request, an audit process is executed to generate a gateway authentication token and drive the container engine to create and start the clone container. The clone container initiates a periodic heartbeat request carrying the local configuration version number and configuration checksum. The management platform verifies the token validity period and completes the token hot rotation through the heartbeat response when it is below the rotation threshold. The management platform assembles a configuration snapshot based on the version comparison result, which is then sent by the heartbeat response and written to the local configuration file by the clone container, triggering runtime hot reload. This effectively solves the shortcomings of traditional technologies in multi-identifier joint audit container orchestration and startup, heartbeat-driven token hot rotation, and configuration version difference hot reload linkage, providing technical guarantee for the secure and efficient management of the entire lifecycle of digital clones.

[0090] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied 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.

[0091] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0092] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0093] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0094] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for full lifecycle management of digital clones based on containerized orchestration, characterized in that, The method includes: The system receives a digital clone creation request and parses the clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, it executes an audit process and generates a gateway authentication token containing the gateway identifier, clone identifier, user identifier, and tenant identifier after the audit is passed. Based on the gateway authentication token and the management platform connection address, it constructs a container runtime configuration and calls the container engine through the unified orchestration interface to create and start the clone container. After the clone container starts, it reads the gateway authentication token and sends a periodic heartbeat request to the management platform. The heartbeat request carries the local configuration version number and configuration checksum to form a heartbeat data packet. After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than the preset rotation threshold, a new token is generated and returned to the clone container through a heartbeat response to complete the token hot rotation. The management platform extracts the local configuration version number from the heartbeat data packet and compares it with the latest version number on the server to obtain the version comparison result. Based on the version comparison result, when the version numbers are inconsistent, a complete configuration snapshot is assembled and sent to the clone container through a heartbeat response. After receiving the configuration snapshot, the clone container writes it to the local configuration file and triggers runtime hot reload.

2. The method for full lifecycle management of digital clones based on containerized orchestration according to claim 1, characterized in that, The process of receiving a digital clone creation request and parsing the clone type identifier, user identifier, and tenant identifier from the request to obtain clone creation parameters, executing an approval process based on the clone creation parameters, and generating a gateway authentication token containing a gateway identifier, clone identifier, user identifier, and tenant identifier after approval includes: The system receives a digital clone creation request and parses the clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, it creates a clone record in the database and sets the initial state to pending review. The administrator reads the clone record from the pending review queue and performs the review operation to obtain the review result. After the audit result is determined to be approved, the clone identifier, user identifier, and tenant identifier in the clone record are read. A gateway identifier is generated based on the clone identifier, and a token payload is constructed based on the gateway identifier, the clone identifier, the user identifier, and the tenant identifier. A signature operation is performed on the token payload according to the preset validity period parameter to obtain the gateway authentication token.

3. The method for full lifecycle management of digital clones based on containerized orchestration according to claim 1, characterized in that, The process of constructing a container runtime configuration based on the gateway authentication token and the management platform connection address, and creating and starting the cloned container by calling the container engine through the unified orchestration interface, includes: The gateway authentication token and management platform connection address are read and written as environment variables into the container environment configuration. The container image identifier is determined based on the clone type identifier, and the processor core limit and memory limit are configured according to the preset resource constraint rules to obtain resource limit parameters. The container runtime configuration is constructed based on the container environment configuration and the resource limit parameters, and with the addition of health check endpoint configuration and persistent storage volume configuration. Based on the current deployment environment identifier, the container engine type is determined and the corresponding orchestration driver is selected. The container runtime configuration is read through the unified orchestration interface and the container creation method of the orchestration driver is called to obtain a container instance. Based on the container instance, the container startup method is called and the status of the clone record is updated to running state after successful startup, and the container identifier and container network address are recorded.

4. The method for full lifecycle management of digital clones based on containerized orchestration according to claim 1, characterized in that, After the clone container starts, it reads the gateway authentication token and sends periodic heartbeat requests to the management platform. The heartbeat request carries a heartbeat data packet consisting of the local configuration version number and the configuration checksum, including: After the clone container starts, it reads the gateway authentication token and the management platform connection address from the container environment variables, establishes a communication connection with the management platform based on the management platform connection address, and starts a heartbeat timer. The heartbeat timer triggers a heartbeat request to generate a task according to a preset heartbeat cycle. In response to the heartbeat request, the task generates a configuration checksum by reading the local configuration version number from the local configuration file and performing a checksum calculation on the local configuration content. Based on the local configuration version number and the configuration checksum, and with the addition of platform type, architecture type, runtime, number of active tasks, task queue depth, and number of currently connected users, runtime metadata is constructed. Based on the gateway authentication token and the runtime metadata, a heartbeat data packet is encapsulated and sent to the management platform.

5. The method for full lifecycle management of digital clones based on containerized orchestration according to claim 1, characterized in that, After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than a preset rotation threshold, a new token is generated and returned to the clone container via a heartbeat response to complete the token hot rotation, including: The management platform receives the heartbeat data packet and extracts the gateway authentication token from it. It performs signature verification and validity period verification on the gateway authentication token to obtain the token verification result. Based on the token verification result, it determines that the verification is successful. After that, it parses the payload of the gateway authentication token to obtain the gateway identifier, clone identifier and expiration timestamp. Based on the expiration timestamp and the current timestamp, it calculates the remaining validity period. A comparison is performed based on the remaining validity period and a preset rotation threshold. When the remaining validity period is lower than the preset rotation threshold, the payload information of the gateway authentication token is read, and the gateway identifier, clone identifier, user identifier, and tenant identifier remain unchanged. A new issuance time and a new expiration time are generated based on the current timestamp, and a signature operation is performed on the updated payload to obtain a new token. A heartbeat response is constructed based on the new token and returned to the clone container. After receiving the heartbeat response, the clone container extracts the new token and replaces the gateway authentication token stored locally.

6. The method for full lifecycle management of digital clones based on containerized orchestration according to claim 1, characterized in that, The management platform extracts the local configuration version number from the heartbeat data packet and compares it with the latest version number on the server to obtain the version comparison result, including: The management platform extracts the local configuration version number and configuration checksum from the heartbeat data packet, queries the clone record based on the gateway identifier in the heartbeat data packet to obtain the clone identifier, tenant identifier and user identifier, and reads the latest version number of the server and the server configuration checksum from the configuration storage based on the clone identifier; A version number comparison identifier is obtained by comparing the local configuration version number with the latest version number on the server. A checksum comparison identifier is obtained by comparing the configuration checksum with the server configuration checksum. A version comparison result is obtained by comprehensively judging the version number comparison identifier and the checksum comparison identifier.

7. The method for full lifecycle management of digital clones based on containerized orchestration according to claim 1, characterized in that, The process of assembling a complete configuration snapshot based on the version comparison result when the version numbers are inconsistent, and sending it to the clone container via a heartbeat response, and the clone container receiving the configuration snapshot, writing it to the local configuration file and triggering a runtime hot reload, includes: When the version number is determined to be inconsistent based on the version comparison result, the configuration storage is queried and the large language model provider list, model calling strategy, default behavior parameters, embedded model configuration, toolchain configuration, and infrastructure address configuration are read based on the clone identifier, the tenant identifier, and the user identifier. The read configuration items are filtered and assembled based on the permission scope of the tenant identifier and the user identifier to obtain a complete configuration snapshot. A heartbeat response is constructed based on the complete configuration snapshot and the latest version number of the server and sent to the clone container. The clone container receives the heartbeat response and extracts the complete configuration snapshot and the latest version number of the server from it. It writes the complete configuration snapshot to the local configuration file and updates the local configuration version number based on the latest version number of the server. Based on the completed local configuration file, it sends a configuration reload command to the runtime management module to trigger runtime hot reload.

8. A digital clone full lifecycle management device based on containerized orchestration, characterized in that, The device includes: The container clone module is used to receive digital clone creation requests and parse clone type identifier, user identifier, and tenant identifier from the creation request to obtain clone creation parameters. Based on the clone creation parameters, it executes an audit process and generates a gateway authentication token containing gateway identifier, clone identifier, user identifier, and tenant identifier after the audit is passed. Based on the gateway authentication token and the management platform connection address, it constructs a container runtime configuration and calls the container engine through the unified orchestration interface to create and start the clone container. The token rotation module is used to read the gateway authentication token and send a periodic heartbeat request to the management platform after the clone container starts. The heartbeat request carries the local configuration version number and configuration checksum to form a heartbeat data packet. After receiving the heartbeat data packet, the management platform verifies the validity of the gateway authentication token and checks the remaining validity period. When the remaining validity period is lower than the preset rotation threshold, a new token is generated and returned to the clone container through a heartbeat response to complete the token hot rotation. The version management module is used to manage the platform to extract the local configuration version number from the heartbeat data packet and compare it with the latest version number on the server to obtain the version comparison result. Based on the version comparison result, when the version numbers are inconsistent, a complete configuration snapshot is assembled and sent to the clone container through a heartbeat response. After receiving the configuration snapshot, the clone container writes it to the local configuration file and triggers runtime hot reload.

9. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the steps of the containerized orchestration-based digital clone lifecycle management method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When executed by a processor, the computer program implements the steps of the containerized orchestration-based digital clone lifecycle management method as described in any one of claims 1 to 7.

Images