Cloud agent resource consolidation migration method and device based on network card slot capacity constraint, equipment and medium

Abstract

The application provides a cloud agent resource merging and migration method and device based on network card slot capacity constraint, equipment and medium, the method comprises the following steps: obtaining the mapping relationship between the public network IP and the network card, filtering the full slot instance after grouping according to the isolation key; according to the remaining valid period of the instance, the expiration classification is carried out; the minimum reserved instance number is calculated and the reserved set and the candidate deletion set are divided, the migration details are generated after the capacity constraint is met through dynamic backfill iteration; after the target network card applies for a distributed lock, the binding change task is initiated; the migration success callback is received, and the associated data is updated atomically in the database transaction; the connectivity detection is carried out on the agent after migration, and the full empty instance is written into the to-be-deleted queue after the detection is passed; after the secondary network card state determination, the instance release request is initiated; the scattered agent resources can be concentrated to the minimum necessary instance, the data consistency is ensured, and the cloud resource cost is reduced.

Description

Technical Field

[0001] This invention relates to the field of cloud computing resource management technology, and in particular to a method, apparatus, device, and medium for merging and migrating cloud proxy resources based on network interface card slot capacity constraints. Background Technology

[0002] In a cloud proxy service system, to provide proxy services (such as HTTP / SOCKS5 proxy) to external users, the system typically assigns a public IP address to each proxy instance. This public IP address is attached to the cloud provider's virtual machine instance via a network interface (hereinafter referred to as "NIC"). A virtual machine instance can have multiple NICs attached, and each NIC can be bound to a public IP address. The maximum number of NICs that an instance can have is determined by its specifications, which is referred to as "slot capacity" in this article. In actual operation, the underlying instance resources often come from multiple cloud accounts and combinations of various instance specifications.

[0003] Proxy resources have a lifecycle characteristic: when a user releases the proxy, the corresponding public IP address and the network card slot it occupies immediately become free, but the virtual machine instance where the network card is located is not released synchronously, because other network card slots on the instance may still be in use.

[0004] To control cloud resource costs and optimize resource utilization, existing technologies involve merging and migrating virtual machine instances in the aforementioned scenarios. However, analysis reveals that existing solutions suffer from one or more of the following technical issues when dealing with multi-account, multi-specification, and dynamically changing proxy resource pools: 1. Fragmentation and Insufficient Instance Resource Utilization: Existing technologies typically manage single instances or single accounts. In real-world operational scenarios with multiple accounts and different instance sizes, as proxy resources are gradually released, only a small number of network interface card slots on different instances are occupied, resulting in a large number of "half-empty instances." Since cloud providers charge based on the entire virtual machine instance, these half-empty instances continue to incur costs, leading to low overall slot utilization and cost-effectiveness. Existing technologies lack a scheduling method that can systematically identify and merge these scattered resources across accounts and instances to approach the theoretical lower limit of slot capacity as a whole.

[0005] 2. Resource contention in concurrent migration operations: When multiple migration tasks are executed concurrently, or when migration tasks and routine agent allocation tasks occur simultaneously, existing technologies lack effective concurrency control mechanisms for the specific resource of "network interface card (NIC) slots." Specifically, different tasks may simultaneously identify and attempt to occupy the same idle NIC slot, leading to data write conflicts or inconsistent resource states. Although technologies such as distributed locks are known in general computing, how to apply them in a lightweight and precise manner to NIC slot-level migration scheduling in cloud environments to avoid excessively impacting task execution efficiency remains a challenge that existing technologies have not fully addressed.

[0006] 3. System consistency issues after migration: A successful migration involves changes to multiple business objects, such as public IP binding relationships, network interface card status, subscription information, and proxy service configuration. Existing technical solutions often focus on completing the core operation of IP rebinding, but fail to adequately guarantee the eventual consistency of the control plane (database) and data plane (actual cloud resources, proxy service processes) after the migration. For example, if the related information in the business database is not updated synchronously after the rebinding operation, or if the proxy configuration is not correctly restored on the new instance, the proxy service may become unavailable or generate dirty data. Existing technologies lack a complete callback processing mechanism to ensure atomic and consistent updates to multiple related systems after a successful migration.

[0007] 4. Operational Risks in Asynchronous Deletion Processes: After merging and migrating, it is typically necessary to asynchronously release "idle instances" that are no longer under load to save costs. Current technologies lack an effective secondary confirmation mechanism before initiating instance deletion operations. Due to the asynchronous nature of system state changes, within the time window between "determining if an instance is idle" and "actually calling the deletion interface," the instance may have its network interface resources reallocated by other business logic. Directly deleting the instance under these circumstances will lead to business incidents. Therefore, existing technologies pose a risk of mistakenly deleting instances that are being reused due to state synchronization delays.

[0008] 5. Blurred Boundaries and Compliance Risks in Cross-Account Migration: In multi-account scenarios, different cloud accounts are typically isolated in terms of billing, quotas, and compliance. Existing technologies often lack strict constraints on account boundaries when merging resources, potentially migrating proxy resources from account A to instances under account B. This can lead to quota misuse, incorrect billing attribution, and even violations of security and compliance policies. Current technologies lack a routing mechanism that can enforce account and specification boundary isolation during the resource grouping phase and independently complete migration decisions within this isolated domain.

[0009] 6. Lack of forward-looking consideration of instance lifecycle: Existing migration decisions typically only focus on current resource capacity (such as slot availability), ignoring the remaining lifecycle of candidate target instances (such as expiration dates). This leads to a common problem: proxy resources are merged and migrated to an instance that is about to expire, and shortly afterward, that instance is released due to expiration. The business system is forced to perform a secondary migration of these proxy resources, causing unnecessary system load and business fluctuations. Existing technologies lack a mechanism to proactively avoid the "secondary migration" problem by using the remaining validity period of the target instance as a pre-constraint for migration decisions.

[0010] 7. Insufficient Post-Migration Availability Verification and Fault Handling Mechanisms: Existing technical solutions typically use a successful API response from the cloud vendor as a marker of migration completion, without actively verifying the actual availability of the proxy service after migration. This leads to a situation where the IP rebinding operation succeeds, but the proxy configuration fails to be correctly distributed or fails to take effect on the new instance for other reasons, causing silent failures in user-side proxy requests. Furthermore, when persistent failures occur during the migration process, the existing scheduling system lacks an automatic circuit breaker mechanism, which may lead to continuous retries or task advancement, causing the fault to spread within the system, increasing the difficulty of manual intervention and business recovery time.

[0011] In summary, while existing technologies have provided various implementations for single-point aspects such as virtual machine migration and resource scheduling, in the specific scenario of cloud agent resource merging, facing the complex challenges of multiple accounts, multiple specifications, and dynamic lifecycles, there is still a lack of a systematic solution to address the multiple technical issues mentioned above, including fragmentation, concurrency conflicts, data consistency, protection against accidental deletion, isolation constraints, expiration decisions, and rapid termination in case of failure, and to form an end-to-end, highly reliable technical solution. Therefore, there is an urgent need to propose a new, systematic approach to overcome the shortcomings of existing technologies and improve the automation level, cost-effectiveness, and operational reliability of cloud agent resource management. Summary of the Invention

[0012] The technical problem to be solved by the present invention is to provide a method, apparatus, device and medium for merging and migrating cloud proxy resources based on network interface card slot capacity constraints, which can concentrate scattered proxy resources to the minimum necessary instances, thereby reducing cloud resource costs while ensuring data consistency.

[0013] In a first aspect, the present invention provides a method for merging and migrating cloud proxy resources based on network interface card slot capacity constraints, comprising the following steps: Step S1: Obtain the mapping relationship between the currently used public IP address and the instance network card under the target cloud vendor, group the mapping relationship according to the preset isolation key to obtain at least one isolation group, and filter the instances with full slots in each isolation group. The instances with full slots refer to instances whose number of currently used network cards is equal to the upper limit of its slot capacity. Step S2: For each isolation group, obtain the remaining validity period of each candidate migration-instance, and divide them into a bearable layer and a non-bearable layer according to a preset expiration threshold, wherein only the reusable network interface card slots of the bearable layer instances are included in the subsequent capacity calculation; Step S3: Calculate the minimum number of reserved instances required by the isolation group according to the formula need_instance_count=ceil(public_ip_count / ip_mode), sort the instances in descending order based on the current number of network interface cards in use of each instance, divide the first need_instance_count instances into a reserved set, and divide the remaining instances into a to-be-deleted set, where public_ip_count is the total number of public IPs currently in use in the isolation group, and ip_mode is the upper limit of slot capacity of a single instance; Step S4: Count the total number of reusable network interface card slots residue_count on the instances in the bearable layer in the reserved set, and the total number of to-be-migrated public IPs change_ip_count in the to-be-deleted set; if residue_count < change_ip_count, move the instance with the largest number of currently occupied network interface card slots in the to-be-deleted set into the reserved set, and repeat the statistics and comparison of this step until residue_count ≥ change_ip_count is satisfied or it is determined that the to-be-deleted set is empty; Step S5: When residue_count ≥ change_ip_count is satisfied, take the instances in the to-be-deleted set as source instances, take the corresponding bearable layer instances in the reserved set as target instances, assign a reusable network interface card slot of a bearable layer instance in the reserved set to each proxy in use in the to-be-deleted set, generate a one-to-one migration detail record, attribute a group of migration detail records generated under the same trigger condition to the same migration batch, and persist the migration detail records; Step S6: Apply for a distributed lock for the target network interface card ID in each migration detail according to the cloud vendor configuration item; after the lock is successfully acquired, initiate an asynchronous public IP rebinding task to the migration execution service; if the lock acquisition fails, set the status of the migration detail to a failure status of waiting for retry, and it will be reprocessed in a subsequent scheduling cycle; Step S7: Receive a migration success callback, and in a single database transaction of the service database, update the public IP binding relationship, the target network interface card status, the source network interface card status, the resource object reference, the subscription expiration time, the network interface card binding history and the proxy association relationship in an atomic operation manner, wherein if any update operation fails, the entire transaction is rolled back; after the update is successful, trigger a proxy configuration recovery process; Step S8: Perform connectivity detection of at least one channel on the migrated agent, and after the detection is passed, determine whether there are no in-use network adapters remaining for the source instance corresponding to the migration detail, and if so, write the record of the source instance into the to-be-deleted queue; Step S9: Take out the instance record from the to-be-deleted queue, and query again the current status of all network adapter records associated with the instance in the database; if the status of any network adapter record is "in-use", mark the to-be-deleted record as "not to be deleted" and skip the current deletion operation; if it is confirmed that there is no network adapter with the status of "in-use", initiate an instance release request to the cloud vendor interface, and update the status of the instance and its associated network adapters to deleted after a successful callback.

[0014] In a second aspect, the present invention provides a cloud proxy resource merging and migration apparatus based on network adapter slot capacity constraints, comprising: A resource collection and isolation grouping module, configured to obtain the mapping relationship between currently used public IPs and instance network adapters under the target cloud vendor, group the mapping relationship according to a preset isolation key to obtain at least one isolation group, and filter out full-slot instances in each isolation group, where the full-slot instance refers to an instance whose current number of in-use network adapters is equal to its upper slot capacity limit; A grading module, configured to, for each isolation group, obtain the remaining validity period of each candidate migration destination instance, and divide them into a bearable layer and a non-bearable layer according to a preset expiration threshold, wherein only the reusable network adapter slots of the instances in the bearable layer are included in subsequent capacity calculation; A capacity calculation and division module, configured to calculate the minimum number of reserved instances required for the isolation group according to the formula need_instance_count=ceil(public_ip_count / ip_mode), perform descending sorting based on the current number of in-use network adapters of each instance, divide the first need_instance_count instances into a reserved set, and divide the remaining instances into a pending-deletion set, where public_ip_count is the total number of currently used public IPs in the isolation group, and ip_mode is the upper slot capacity limit of a single instance; An isolation grouping routing module, configured to count the total number of reusable network adapter slots residue_count on the instances in the bearable layer in the reserved set, and the total number of public IPs to be migrated change_ip_count in the pending-deletion set; if residue_count<change_ip_count, move the instance with the largest number of currently occupied network adapter slots in the pending-deletion set into the reserved set, and repeat the statistics and comparison of this step until residue_count≥change_ip_count is satisfied or it is determined that the pending-deletion set is empty; The migration detail generation module, when the residue_count ≥ change_ip_count is satisfied, takes the instance in the candidate deletion set as the source instance, takes the corresponding bearable layer instance in the retention set as the target instance, allocates a reusable network card slot of a bearable layer instance in the retention set to each in-use proxy in the candidate deletion set, generates a one-to-one migration detail record, assigns a group of migration detail records generated under the same trigger condition to the same migration batch, and persists the migration detail record; The concurrent lock control migration scheduling module requests a distributed lock for the target network interface ID in each migration detail based on the cloud vendor's configuration items; after successfully acquiring the lock, it initiates an asynchronous task to change the public IP binding to the migration execution service; if the lock acquisition fails, the status of the migration detail is set to a failed status of waiting for retry, and it will be reprocessed in a subsequent scheduling cycle. The callback consistency update module receives a successful migration callback and, within a single database transaction of the business database, updates the public IP binding relationship, target network interface status, source network interface status, resource object references, subscription expiration time, network interface binding history, and proxy association relationship in an atomic manner. If any update operation fails, the entire transaction is rolled back. After a successful update, the proxy configuration recovery process is triggered. The availability verification module performs connectivity checks on at least one channel for the migrated agent. If the check passes, it determines whether the source instance corresponding to the migration details no longer has any in-use network interface cards. If so, the record of the source instance is written to the deletion queue. The deletion determination and release module retrieves instance records from the deletion queue and queries the database again to check the current status of all network interface records associated with the instance. If any network interface record is in use, the record is marked as "not to be deleted" and the deletion operation is skipped. If it is confirmed that there is no network interface in use, an instance release request is sent to the cloud vendor interface, and the status of the instance and its associated network interface is updated to deleted after a successful callback.

[0015] Thirdly, the present invention 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 method described in the first aspect.

[0016] Fourthly, the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described in the first aspect.

[0017] One or more technical solutions provided by this invention have at least the following technical effects or advantages: 1. This invention accurately calculates the minimum number of retained instances based on network interface card (NIC) slot capacity, determining the number of retained instances using a theoretical lower bound. Combined with a full-priority, non-dispersed scheduling strategy, it ensures that the number of instances within the same isolation group converges towards the theoretical minimum. In multi-account, multi-specification scenarios, each isolation group independently performs capacity convergence. Cross-account slot compression from a unified perspective further eliminates resource fragmentation between accounts, directly reducing cloud resource costs billed per instance. The cost compression rate significantly improves with increasing fragmentation levels.

[0018] 2. This invention performs connectivity checks on at least one channel after the proxy configuration is restored, and sets timeout control and retry mechanisms. Only after the checks pass is the old instance release process allowed, ensuring the proxy service is truly available on the target instance, rather than relying solely on the cloud vendor's API return as a sign of migration completion. Simultaneously, this invention accumulates failure counts at both the source instance and batch levels during migration scheduling. When either level reaches a preset threshold, a circuit breaker is immediately executed: for the source instance level, a circuit breaker suspends all scheduling details under that instance until manual confirmation; for the batch level, a circuit breaker immediately terminates subsequent batch scheduling. This dual-dimensional circuit breaker mechanism effectively prevents fault propagation and shortens the business impact time.

[0019] 3. This invention employs a capacity constraint matching and dynamic replenishment mechanism, using the condition that "the number of reusable slots in the reserved set is not less than the number of IPs to be migrated in the candidate set" as a feasibility condition. Migration details are only generated and scheduling is initiated after this condition is met, avoiding failures and retries caused by forced migration due to insufficient slots. A distributed lock based on network interface card ID eliminates multi-task slot preemption conflicts. Each cloud vendor independently configures the lock key prefix; when locking fails, the detail status is set to a failed state awaiting retry, and reprocessed in subsequent scheduling cycles. Continuous scheduling of details from the same source instance compresses the intermediate state time window. These three mechanisms work synergistically to comprehensively reduce the failure rate of migration tasks.

[0020] 4. After a successful rebinding operation and asynchronous callback confirmation from the cloud vendor, this invention atomically updates seven types of associated objects within a single database transaction. These include the binding relationship between public IP addresses and network interface cards (NICs), the target NIC status, the source NIC status, resource object references, subscription expiration times, NIC binding history, and the mapping between proxies, instances, and NICs. If any update operation fails, the entire transaction is rolled back, ensuring complete consistency between control plane data and data plane states. This fundamentally eliminates dirty state data between systems and guarantees the integrity and accuracy of business data during migration.

[0021] 5. Before initiating an instance release request to the cloud provider, this invention performs a secondary network interface card (NIC) usage status check, re-querying the current status of all NIC records associated with the target instance in the business database. Only after confirming that no NIC is in use will the instance release request be submitted. This mechanism effectively prevents accidental deletion caused by concurrent task delays, delayed status synchronization, or asynchronous timing issues, thus improving the security of deletion operations.

[0022] 6. This invention establishes a mapping model from external product specifications to multiple accounts and internal specifications through an external product specification virtualization mapping mechanism. Independent isolation keys are constructed based on the combination of accounts and specifications, and capacity constraint matching and target slot selection are performed independently within the isolation key range. External business requests are only aware of the external product specifications and are unaware of the differences in underlying accounts and internal specifications. Internal resource reorganization operations such as account switching and specification adjustments are completely transparent to the external business layer, and the external service identifier remains unchanged throughout the migration process, ensuring the stability and continuity of business calls.

[0023] 7. This invention achieves differentiated adaptation to various cloud vendors through cloud vendor configuration items, including independent configuration of the distributed lock key prefix, enumeration definition of network interface card status codes, and skippable steps for deleting tasks, all of which can be customized by extending the cloud vendor. The expiration threshold supports configurable multi-level decrement strategies, and the migration action types can be expanded to support multiple operating modes. The above design gives this invention good cross-cloud vendor versatility and business scenario scalability.

[0024] The above description is merely an overview of the technical solution of the present invention. In order to better understand the technical means of the present invention and to implement it in accordance with the contents of the specification, and in order to make the above and other objects, features and advantages of the present invention more apparent and understandable, specific embodiments of the present invention are described below. Attached Figure Description

[0025] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0026] Figure 1 This is a flowchart of the method in Embodiment 1 of the present invention; Figure 2 This is a schematic diagram of the device in Embodiment 2 of the present invention. Detailed Implementation Example 1

[0027] like Figure 1 As shown, this embodiment provides a cloud proxy resource merging and migration method based on network interface card slot capacity constraints, characterized by the following steps: Step S1: Obtain the mapping relationship between currently used public IPs and instance network adapters under the target cloud vendor, group the mapping relationship according to a preset isolation key to obtain at least one isolation group, and filter out instances with full slots in each isolation group, where the instance with full slots refers to an instance whose current number of used network adapters is equal to its slot capacity upper limit; Step S2: For each isolation group, obtain the remaining validity period of each candidate migration-instance, and divide them into a bearable layer and a non-bearable layer according to a preset expiration threshold, wherein only the reusable network adapter slots of the instances in the bearable layer are included in the subsequent capacity calculation; Step S3: Calculate the minimum number of reserved instances required for the isolation group according to the formula need_instance_count=ceil(public_ip_count / ip_mode), sort the instances in descending order based on the current number of used network adapters of each instance, classify the first need_instance_count instances into a reservation set, and classify the remaining instances into a candidate-to-delete set, where public_ip_count is the total number of public IPs currently in use in the isolation group, and ip_mode is the upper limit of the slot capacity of a single instance; Step S4: Count the total number of reusable network adapter slots residue_count of the instances in the bearable layer in the reservation set, and the total number of public IPs to be migrated change_ip_count in the candidate-to-delete set; if residue_count < change_ip_count, move the instance with the largest number of currently occupied network adapter slots in the candidate-to-delete set into the reservation set, and repeatedly perform the statistics and comparison in this step until residue_count ≥ change_ip_count is satisfied or it is determined that the candidate-to-delete set is empty; Step S5: When residue_count ≥ change_ip_count is satisfied, take the instances in the candidate-to-delete set as source instances, take the corresponding bearable layer instances in the reservation set as target instances, allocate a reusable network adapter slot of one bearable layer instance in the reservation set for each in-use proxy in the candidate-to-delete set, generate a one-to-one migration detail record, assign a group of migration detail records generated under the same trigger condition to the same migration batch, and persist the migration detail records; Step S6: Apply for a distributed lock for the target network adapter ID in each migration detail according to the cloud vendor configuration item; after the lock is successfully acquired, initiate an asynchronous public IP rebinding task to the migration execution service; if the lock acquisition fails, set the status of this migration detail to a failure state of waiting for retry, and it will be reprocessed in a subsequent scheduling cycle; Step S7: Receive the migration success callback. Within a single database transaction of the business database, update the public IP binding relationship, target network card status, source network card status, resource object reference, subscription expiration time, network card binding history, and proxy association relationship in an atomic manner. If any update operation fails, the entire transaction is rolled back. After the update is successful, the proxy configuration recovery process is triggered. Step S8: Perform connectivity checks on at least one channel for the migrated agent. If the checks pass, determine whether the source instance corresponding to the migration details no longer has any in-use network interface cards. If so, write the record of the source instance into the deletion queue. Step S9: Retrieve the instance record from the queue to be deleted, and query the current status of all network interface records associated with the instance in the database again; if the status of any network interface record is "in use", mark the record to be deleted as "not to delete" and skip this deletion operation; if it is confirmed that there is no network interface with the status of "in use", initiate an instance release request to the cloud vendor interface, and update the status of the instance and its associated network interface to "deleted" after a successful callback.

[0028] In this embodiment, preferably, the isolation key is a specification identifier, or a combination key of specification identifier and account identifier; in a multi-account, multi-specification scenario, the isolation key is a three-level combined key composed of external product specification identifier, internal specification identifier, and account identifier, and the migration operation is performed within the scope determined by the same three-level combined key; The rule for filtering instances that are already full in each isolation group is as follows: when the number of network cards currently in use for an instance is equal to the upper limit of its slot capacity, the instance is excluded from the candidate deletion set and is not processed as a source of migration.

[0029] In this embodiment, preferably, the preset expiration threshold is a configurable parameter; when the total number of reusable slots of the bearable layer instance is insufficient, the value of the expiration threshold is gradually increased according to the preset decreasing step size and the capacity is recalculated, or the current round of merging and migration is terminated directly.

[0030] In this embodiment, preferably, when initiating an asynchronous task to change the binding of a public IP address, multiple migration details belonging to the same source instance are prioritized to be continuously issued within the same scheduling batch, so as to compress the time window in which the source instance is in an intermediate state; The lock key prefix of the distributed lock is configured independently by each cloud vendor, with the target network interface ID as the locking value; the failure status of waiting for retry corresponding to the locking failure is picked up by the subsequent scheduling cycle and the locking and rebinding process is re-initiated.

[0031] In this embodiment, preferably, the connectivity detection includes a first channel detection, which specifically involves: initiating an HTTP request to a pre-configured external detection service address via the SOCKS5 proxy protocol, setting a single timeout threshold, retrying at fixed intervals when it fails, and the number of retries not exceeding a preset upper limit; if any request succeeds within the number of retries, the first channel detection is determined to be passed.

[0032] In this embodiment, preferably, a circuit breaker step is further included, which is executed during the migration scheduling process, and specifically includes: Maintain the failure count for each migration batch and the failure count for each source instance. When any migration detail fails to initiate an asynchronous task to change the public IP address in step S6, or fails to receive a migration callback in step S7, the failure is simultaneously counted in the failure count of the batch to which the migration detail belongs and the failure count of the source instance to which the migration detail belongs. When the failure count of any source instance reaches the first preset threshold, the scheduling of all migration details under that source instance that have not yet initiated the asynchronous task of changing public IP binding will be suspended, the migration details under that source instance that have not yet completed scheduling will be marked as failed, and further scheduling of that source instance will be stopped until a manual confirmation instruction is received before it can be resumed. When the failure count of any batch reaches the second preset threshold, the scheduling of all unexecuted migration details in that batch is immediately terminated, the overall status of the batch is set to failure, and all subsequent execution processes of that batch are stopped.

[0033] In this embodiment, preferably, after initiating an instance release request to the cloud vendor interface in step S9, the method further includes: receiving a release success callback, updating the status of the instance and its associated network interface to "deleted", and recording the actual release time of the instance; if a release failure callback is received, the failure count is added to the instance release error counter of the corresponding batch, and the subsequent instance release operation of the batch is terminated when the instance release error count reaches a preset threshold.

[0034] Based on the same inventive concept, this application also provides an apparatus corresponding to the method in Embodiment 1, as detailed in Embodiment 2. Example 2

[0035] like Figure 2 As shown, this embodiment provides a cloud proxy resource merging and migration device based on network interface card slot capacity constraints, including: resource collection and isolation grouping module, which acquires the mapping relationship between currently used public IPs and instance network adapters under the target cloud vendor, groups the mapping relationship according to a preset isolation key to obtain at least one isolation group, and filters out full-slot instances in each isolation group, where the full-slot instance refers to an instance whose number of currently used network adapters is equal to its slot capacity upper limit; classification module, which for each isolation group, acquires the remaining validity period of each candidate migration-in instance, and divides the candidate migration-in instances into a bearable layer and a non-bearable layer according to a preset expiration threshold, wherein only the reusable network adapter slots of the instances in the bearable layer are included in subsequent capacity calculation; capacity calculation and division module, which calculates the minimum number of reserved instances required by the isolation group according to the formula need_instance_count=ceil(public_ip_count / ip_mode), sorts the instances in descending order based on the number of currently used network adapters of each instance, divides the first need_instance_count instances into a reserved set, and divides the remaining instances into a pending-deletion set, wherein public_ip_count is the total number of currently used public IPs in the isolation group, and ip_mode is the slot capacity upper limit of a single instance; isolation grouping routing module, which counts the total number of reusable network adapter slots residue_count of the instances in the bearable layer in the reserved set, and the total number of public IPs to be migrated change_ip_count in the pending-deletion set; if residue_count<change_ip_count, the instance with the largest number of currently occupied network adapter slots in the pending-deletion set is moved into the reserved set, and the statistics and comparison of this step are repeatedly executed until residue_count≥change_ip_count is satisfied or the pending-deletion set is determined to be empty; migration detail generation module, which, when residue_count≥change_ip_count is satisfied, takes the instances in the pending-deletion set as source instances, takes the corresponding bearable layer instances in the reserved set as target instances, allocates a reusable network adapter slot of one bearable layer instance in the reserved set to each active proxy in the pending-deletion set, generates a one-to-one migration detail record, attributes a group of migration detail records generated under the same trigger condition to the same migration batch, and persists the migration detail records; concurrent lock control migration scheduling module, which applies for a distributed lock for the target network adapter ID in each migration detail according to the cloud vendor configuration item; after the lock is successfully acquired, an asynchronous public IP rebinding task is initiated to the migration execution service; if the lock acquisition fails, the state of the migration detail is set to a failure state of waiting for retry, and the migration detail is reprocessed in a subsequent scheduling period; The callback consistency update module receives a successful migration callback and, within a single database transaction of the business database, updates the public IP binding relationship, target network interface status, source network interface status, resource object references, subscription expiration time, network interface binding history, and proxy association relationship in an atomic manner. If any update operation fails, the entire transaction is rolled back. After a successful update, the proxy configuration recovery process is triggered. The availability verification module performs connectivity checks on at least one channel for the migrated agent. If the check passes, it determines whether the source instance corresponding to the migration details no longer has any in-use network interface cards. If so, the record of the source instance is written to the deletion queue. The deletion determination and release module retrieves instance records from the deletion queue and queries the database again to check the current status of all network interface records associated with the instance. If any network interface record is in use, the record is marked as "not to be deleted" and the deletion operation is skipped. If it is confirmed that there is no network interface in use, an instance release request is sent to the cloud vendor interface, and the status of the instance and its associated network interface is updated to deleted after a successful callback.

[0036] In this embodiment, preferably, the isolation key is a specification identifier, or a combination key of specification identifier and account identifier; in a multi-account, multi-specification scenario, the isolation key is a three-level combined key composed of external product specification identifier, internal specification identifier, and account identifier, and the migration operation is performed within the scope determined by the same three-level combined key; The rule for filtering instances that are already full in each isolation group is as follows: when the number of network cards currently in use for an instance is equal to the upper limit of its slot capacity, the instance is excluded from the candidate deletion set and is not processed as a source of migration.

[0037] In this embodiment, preferably, the preset expiration threshold is a configurable parameter; when the total number of reusable slots of the bearable layer instance is insufficient, the value of the expiration threshold is gradually increased according to the preset decreasing step size and the capacity is recalculated, or the current round of merging and migration is terminated directly.

[0038] In this embodiment, preferably, when initiating an asynchronous task to change the binding of a public IP address, multiple migration details belonging to the same source instance are prioritized to be continuously issued within the same scheduling batch, so as to compress the time window in which the source instance is in an intermediate state; The lock key prefix of the distributed lock is configured independently by each cloud vendor, with the target network interface ID as the locking value; the failure status of waiting for retry corresponding to the locking failure is picked up by the subsequent scheduling cycle and the locking and rebinding process is re-initiated.

[0039] In this embodiment, preferably, the connectivity detection includes a first channel detection, which specifically involves: initiating an HTTP request to a pre-configured external detection service address via the SOCKS5 proxy protocol, setting a single timeout threshold, retrying at fixed intervals when it fails, and the number of retries not exceeding a preset upper limit; if any request succeeds within the number of retries, the first channel detection is determined to be passed.

[0040] In this embodiment, preferably, it further includes a circuit breaker module, which is executed during the migration scheduling process, and specifically includes: Maintain the failure count for each migration batch and the failure count for each source instance. When any migration detail fails to initiate an asynchronous task for changing the public IP address in the concurrent locking migration scheduling module, or fails to receive a migration callback in the callback consistency update module, the failure will be counted in both the failure count of the batch to which the migration detail belongs and the failure count of the source instance to which the migration detail belongs. When the failure count of any source instance reaches the first preset threshold, the scheduling of all migration details under that source instance that have not yet initiated the asynchronous task of changing public IP binding will be suspended, the migration details under that source instance that have not yet completed scheduling will be marked as failed, and further scheduling of that source instance will be stopped until a manual confirmation instruction is received before it can be resumed. When the failure count of any batch reaches the second preset threshold, the scheduling of all unexecuted migration details in that batch is immediately terminated, the overall status of the batch is set to failure, and all subsequent execution processes of that batch are stopped.

[0041] In this embodiment, preferably, after initiating an instance release request to the cloud vendor interface in the deletion determination and release module, the module further includes: receiving a release success callback, updating the status of the instance and its associated network card to deleted, and recording the actual release time of the instance; if a release failure callback is received, the failure count is added to the instance release error counter of the corresponding batch, and the subsequent instance release operation of the batch is terminated when the instance release error count reaches a preset threshold.

[0042] Since the apparatus described in Embodiment 2 of the present invention is an apparatus used to implement the method of Embodiment 1 of the present invention, those skilled in the art can understand the specific structure and variations of the apparatus based on the method described in Embodiment 1 of the present invention, and therefore will not be described again here. All apparatuses used in the method of Embodiment 1 of the present invention fall within the scope of protection of the present invention.

[0043] Based on the same inventive concept, this application provides an electronic device embodiment corresponding to Embodiment 1, as detailed in Embodiment 3. Example 3

[0044] This embodiment provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it can implement any of the implementation methods in Embodiment 1.

[0045] Since the electronic device described in this embodiment is the device used to implement the method in Embodiment 1 of this application, those skilled in the art can understand the specific implementation method and various variations of the electronic device in this embodiment based on the method described in Embodiment 1 of this application. Therefore, how the electronic device implements the method in the embodiment of this application will not be described in detail here. Any device used by those skilled in the art to implement the method in the embodiment of this application falls within the scope of protection of this application.

[0046] Based on the same inventive concept, this application provides a storage medium corresponding to Embodiment 1, as detailed in Embodiment 4. Example 4

[0047] This embodiment provides a computer-readable storage medium storing a computer program thereon. When the computer program is executed by a processor, it can implement any of the implementation methods in Embodiment 1. Example 5

[0048] This embodiment uses a real-world operational scenario of a cloud proxy service provider as its background. The provider offers a product specification called "Standard Proxy," identified externally as `outer_sku = PROXY_STANDARD`. The underlying resources are shared by three different cloud accounts, each with different instance specifications, but these specifications are completely transparent to external users. The resource configurations of each account are as follows: Account A is located in the Tencent Cloud Guangzhou region, using specification S5.SMALL2, with a single instance slot capacity of ip_mode = 4, and a total of 4 running instances; Account B is located in the Tencent Cloud Shanghai region, using specification S5.MEDIUM4, ip_mode = 6, and a total of 3 running instances; Account C is located in the Alibaba Cloud Hangzhou region, using specification ecs.g6.large, ip_mode = 4, and a total of 2 running instances. The expiration times of the instances are unevenly distributed, with some instances having less than one day of remaining validity. The system administrator initiates a merge migration task through the scheduling platform, aiming to concentrate the proxy resources scattered across various instances into fewer instances and release idle instances that are no longer under load.

[0049] The system receives request parameters including: a cloud vendor identifier (provider_id) corresponding to Tencent Cloud and Alibaba Cloud respectively; a target specification list (sku_list) containing the three internal specifications mentioned above; and an action type (action) of "merge and migrate first, then release empty instances". The system first creates a migration batch for this request, initializing the batch status to INITIAL. Then, it enters the resource collection phase, querying the business database for all public IP records in use. Each record is associated with complete information such as its network interface card, instance, proxy service, account, and region. During collection, the system automatically filters out records marked as "deleted" (within 1), public IP statuses other than "assigned", network interface statuses other than "in use", instance statuses other than "running", and public IP records created less than 24 hours ago, to avoid unnecessary disruption to newly allocated instances.

[0050] After data collection is complete, the system groups resources based on the isolation key. Since this embodiment involves a multi-account, multi-specification scenario, the system uses a three-level composite key as the isolation key: outer_sku@@@inner_sku_key@@@account_id. In this embodiment, three isolation groups are formed: the first isolation group is PROXY_STANDARD@@@S5.SMALL2@@@account_A, the second isolation group is PROXY_STANDARD@@@S5.MEDIUM4@@@account_B, and the third isolation group is PROXY_STANDARD@@@ecs.g6.large@@@account_C. Resources within each isolation group are independent of each other, and all subsequent migration operations are strictly performed within the same isolation key, never crossing account or specification boundaries.

[0051] The first isolation group is used as an example for detailed explanation. This isolation group is located in the Tencent Cloud Guangzhou region, with instance specification S5.SMALL2 and ip_mode = 4. The system statistics show that there are currently 10 public IPs in use within this isolation group, distributed across 4 instances. The detailed status of each instance is as follows: Instance A1 currently occupies 3 network card slots, with 1 reusable slot remaining, and a remaining validity period of 7 days; Instance A2 currently occupies 3 network card slots, with 1 reusable slot remaining, and a remaining validity period of 5 days; Instance A3 currently occupies 2 network card slots, with 2 reusable slots remaining, and a remaining validity period of 3 days; Instance A4 currently occupies 2 network card slots, with 2 reusable slots remaining, and a remaining validity period of 12 hours. The system first performs expiration classification, with a preset expiration threshold T_expire of 1 day. Instance A4, with a remaining validity period of 12 hours (less than 1 day), is classified into the transition layer; the remaining validity periods of the other three instances are all greater than or equal to 1 day, and they are classified into the bearable layer. Subsequently, the system filtered instances with full slots. No instances in this isolation group had a network interface card (NIC) usage count of ip_mode=4, therefore no filtering was needed. The system sorted instances in descending order of their current NIC usage count: Instance A1 (3 NICs), Instance A2 (3 NICs), Instance A3 (2 NICs), Instance A4 (2 NICs).

[0052] Next, the system proceeds to the capacity constraint matching phase. The system calculates the minimum number of instances theoretically required to retain this isolation group: need_instance_count = ceil(10 / 4) = 3. Therefore, the system selects the top 3 instances in descending order to form the retention set no_del_list = {A1, A2, A3}, and the remaining instances form the candidate deletion set del_list = {A4}. The system counts the total number of reusable network interface card slots on the bearable layer instances in the retention set. Instances A1, A2, and A3 all belong to the bearable layer, with 1, 1, and 2 reusable slots respectively, totaling residue_count = 4. The total number of public IPs to be migrated in the candidate deletion set is the 2 currently in use IPs on instance A4, i.e., change_ip_count = 2. Since residue_count = 4 is greater than or equal to change_ip_count = 2, the feasibility condition is directly met, and no dynamic replenishment iteration is required.

[0053] The system enters the migration detail generation phase. The system allocates a reusable network interface card (NIC) slot from a hostable layer instance in the reservation set to each in-use agent in the candidate deletion set. Various allocation strategies can be used; this embodiment uses a round-robin approach, allocating the first agent on instance A4 to a reusable slot on instance A1, and the second agent on instance A4 to a reusable slot on instance A2. The system generates a migration detail record for each migration relationship, including fields such as source instance ID, source NIC ID, target instance ID, target NIC ID, public IP address, batch ID, tenant ID, account ID, region ID, and specification identifier, and initializes the detail status to INITIAL. Simultaneously, the system categorizes all migration details generated in this batch into the same migration batch, updating the batch status to READY.

[0054] The scheduler retrieves the INITIAL records from the migration details table according to the configured concurrency limit. For the first record, the system first performs an instance-wide error circuit breaker check to confirm that there are no other failed records under instance A4. Then, the system checks the deletion flag of the proxy service to confirm that the associated proxy record has not been deleted. Next, the system checks the target network interface card (NIC) status to confirm that the target NIC on instance A1 is still in a "reusable" state and has not been preempted by other tasks. After all the above pre-checks pass, the system requests a distributed lock for the target NIC ID based on the cloud vendor's configuration item lock_network_key. In this embodiment, Tencent Cloud's lock key prefix is ​​configured as tencent_network_lock, and the lock value is the unique identifier of the target NIC. After successful locking, the system initiates an asynchronous task to change the public IP binding to the migration execution service. The task parameters include cloud vendor credential information, target region, public IP identifier, source instance and NIC information, target instance and NIC information, SSH key pair, and login username. Two migration details under the same source instance A4 are prioritized and issued consecutively in the same scheduling batch to compress the time window during which instance A4 is in an intermediate migration state. If locking fails, the system will set the detail status to READY_FAILURE, and it will be reprocessed in a subsequent scheduling cycle.

[0055] After the migration execution service completes the rebinding operation, it sends an asynchronous callback to this system. The callback processing is executed within a single database transaction in the business database. First, the system updates the `ip_address` table, changing the network interface ID (NIC) of the public IP address from the source NIC ID to the target NIC ID. Then, it updates the target NIC's status from "reusable" to "in use." Next, it updates the source NIC's status from "in use" to "reusable." The system also updates the `artifact` table, synchronously updating the `object_id` associated with resources such as the public IP address, NIC, instance, and disk to the identifiers of the target instance and NIC. If the target instance has an expiration date, the system also updates the subscription expiration date in the `subscription` table to match the target instance's expiration date. The system records the unbinding timestamp of the source NIC in the `network_interface_history` table and inserts a new binding history record for the target NIC. Finally, the system updates the `proxy` and `t_instances` tables, updating the association between the proxy service and the instance / NIC to point to the target instance. The above seven types of update operations are executed within the same transaction. If any operation fails, the entire transaction is rolled back to ensure complete consistency between the control plane data and the data plane state. Upon successful update, the system triggers the agent configuration recovery process, distributing the agent-related configurations to the target instance, enabling the agent service to resume normal operation on the new instance. The migration details status is synchronously updated to CHECKING.

[0056] After the proxy configuration is restored, the system performs availability checks on migration details in the CHECKING state. The system first performs a first-channel check by initiating an HTTP request to the pre-configured external detection service address via the SOCKS5 proxy protocol, with a timeout of 5 seconds per request. If the request fails, the system retryes at 6-second intervals, up to a maximum of 20 retries. If any request succeeds within the 20 retries, the first-channel check is considered passed. In this embodiment, the proxy service also enables enhanced proxy functionality; therefore, the system additionally performs a second-channel check to verify the connectivity of the enhanced proxy link. If both checks pass, the system updates the migration detail status to SUCCESS. If either check fails, the system updates the detail status to FAILURE and increments the failure count to the error counter for the corresponding batch.

[0057] After the migration details verification passes, the system performs a full empty check on the source instance corresponding to the details. The system queries the current status of all network cards under instance A4 and confirms that the two original network cards on instance A4 have been successfully unbound and there are no other network cards in use. Therefore, instance A4 is determined to be a full empty instance, and its record is written to the pending deletion instance table t_migrate_del_instance, with the initial status set to "pending deletion".

[0058] The deletion process retrieves records with a "pending deletion" status from the pending instance table in batches. For instance A4, the system first performs a secondary network interface card (NIC) usage status check, then queries the business database to check the current status of all NIC records associated with instance A4, confirming that no NICs are currently in use. Next, the system checks the instance's business status to confirm that instance A4 is not marked as deleted in the business database. After these checks pass, the system submits an instance release task to the task scheduling service, carrying parameters including the instance's cloud vendor identifier, region, account credentials, and availability zone information. After task submission, the pending record status is updated to "deleting." The system waits for the cloud vendor's release callback. Upon successful callback, the system updates instance A4's status to "deleted" in the business database, batch updates all NICs under that instance in the "reusable" state to "deleted," and records the actual release time of the instance. If the callback fails, the system adds the failure count to the corresponding batch's deletion error counter. When the deletion error count reaches a preset threshold, the execution of subsequent deletion tasks in this batch is terminated.

[0059] For the second and third isolation groups, the system independently executes the following steps—resource acquisition, expiration grading, capacity constraint matching, migration detail generation, concurrent scheduling, callback updates, availability verification, full-empty determination, and instance release—following the same logic as the first isolation group. Operations between each isolation group are isolated and do not affect each other. Instances in account B with less than one day remaining on their validity period are placed in the transition layer during the expiration grading phase, only allowed as migration sources and not as migration targets. This mechanism avoids the secondary migration problem caused by migrating proxy resources to near-expiring instances. Throughout the migration process, the external service identifier remains PROXY_STANDARD, and the reorganization of internal account resources is completely transparent to the business layer.

[0060] After the above-described merging and migration operations, the original four instances in the first isolation group were reduced to three. Slot utilization shifted from a dispersed state with ten slots distributed across four instances to a concentrated state across three instances, and instance A4 was safely released. If consecutive failures occur under a source instance during the migration scheduling process, the system will suspend scheduling for all pending details under that source instance until manual confirmation is required. If the cumulative number of failures in the entire batch reaches a preset threshold, the system will immediately terminate subsequent scheduling for that batch and set the batch status to failure, preventing the spread of the fault. Through the above steps, this invention achieves automated merging and migration of cloud proxy resources and safe release of idle instances while ensuring tenant isolation constraints and proxy service continuity, effectively reducing cloud resource costs.

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

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

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

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

[0065] While specific embodiments of the present invention have been described above, those skilled in the art should understand that the specific embodiments described are merely illustrative and not intended to limit the scope of the invention. Equivalent modifications and variations made by those skilled in the art in accordance with the spirit of the invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for merging and migrating cloud proxy resources based on network interface card slot capacity constraints, characterized in that, comprising the following steps: Step S1: Acquire the mapping relationship between public IPs currently in use and instance network adapters under the target cloud vendor, group the mapping relationship according to a preset isolation key to obtain at least one isolation group, and filter out full-slot instances in each isolation group, where the full-slot instance refers to an instance whose current number of in-use network adapters is equal to its slot capacity upper limit; Step S2: For each isolation group, acquire the remaining validity period of each candidate migration-instance, and divide them into a bearable layer and a non-bearable layer according to a preset expiration threshold, wherein only the reusable network adapter slots of the instances in the bearable layer are included in the subsequent capacity calculation; Step S3: Calculate the minimum number of reserved instances required for the isolation group according to the formula need_instance_count=ceil(public_ip_count / ip_mode), sort the instances in descending order based on the current number of in-use network adapters of each instance, classify the first need_instance_count instances into a reserved set, and classify the remaining instances into a candidate-to-delete set, wherein public_ip_count is the total number of public IPs currently in use in the isolation group, and ip_mode is the upper limit of the slot capacity of a single instance; Step S4: Count the total number of reusable network adapter slots residue_count of the instances in the bearable layer in the reserved set, and the total number of public IPs to be migrated change_ip_count in the candidate-to-delete set; if residue_count < change_ip_count, move the instance with the largest number of currently occupied network adapter slots in the candidate-to-delete set into the reserved set, and repeatedly perform the statistics and comparison in this step until residue_count ≥ change_ip_count is satisfied or it is determined that the candidate-to-delete set is empty; Step S5: When residue_count ≥ change_ip_count is satisfied, take the instances in the candidate-to-delete set as source instances, take the corresponding instances in the bearable layer in the reserved set as target instances, assign a reusable network adapter slot of one instance in the bearable layer in the reserved set to each in-use proxy in the candidate-to-delete set, generate a one-to-one migration detail record, attribute a group of migration detail records generated under the same trigger condition to the same migration batch, and persist the migration detail records; Step S6: Apply for a distributed lock for the target network adapter ID in each migration detail according to the cloud vendor configuration item; after the lock is successfully acquired, initiate an asynchronous public IP rebinding task to the migration execution service; if the lock acquisition fails, set the status of this migration detail to a failure status of waiting for retry, for reprocessing in a subsequent scheduling cycle; Step S7: Receive a migration success callback, and in a single database transaction of the service database, update the public IP binding relationship, target network adapter status, source network adapter status, resource object reference, subscription expiration time, network adapter binding history and proxy association relationship in an atomic operation manner, wherein if any update operation fails, the entire transaction is rolled back; after the update is successful, trigger the proxy configuration recovery process; Step S8: Perform connectivity checks on at least one channel for the migrated agent. If the checks pass, determine whether the source instance corresponding to the migration details no longer has any in-use network interface cards. If so, write the record of the source instance into the deletion queue. Step S9: Retrieve the instance record from the queue to be deleted, and query the current status of all network interface records associated with the instance in the database again; if the status of any network interface record is "in use", mark the record to be deleted as "not to delete" and skip this deletion operation; if it is confirmed that there is no network interface with the status of "in use", initiate an instance release request to the cloud vendor interface, and update the status of the instance and its associated network interface to "deleted" after a successful callback.

2. The method according to claim 1, characterized in that, The isolation key is a specification identifier, or a combination of a specification identifier and an account identifier. In multi-account, multi-specification scenarios, the isolation key is a three-level combined key consisting of an external product specification identifier, an internal specification identifier, and an account identifier. Migration operations are performed within the scope defined by the same three-level combined key. The rule for filtering instances that are already full in each isolation group is as follows: when the number of network cards currently in use for an instance is equal to the upper limit of its slot capacity, the instance is excluded from the candidate deletion set and is not processed as a source of migration.

3. The method according to claim 1, characterized in that, The preset expiration threshold is a configurable parameter; when the total number of reusable slots of the loadable layer instance is insufficient, the value of the expiration threshold is gradually increased according to the preset decreasing step size and the capacity is recalculated, or the current round of merging and migration is terminated directly.

4. The method according to claim 1, characterized in that, When initiating an asynchronous task to change the binding of a public IP address, multiple migration details belonging to the same source instance are prioritized and continuously distributed within the same scheduling batch to compress the time window in which the source instance is in an intermediate state. The lock key prefix of the distributed lock is configured independently by each cloud vendor, with the target network interface ID as the locking value; the failure status of waiting for retry corresponding to the locking failure is picked up by the subsequent scheduling cycle and the locking and rebinding process is re-initiated.

5. The method according to claim 1, characterized in that, The connectivity detection includes a first channel detection, which specifically involves: initiating an HTTP request to a pre-configured external detection service address via the SOCKS5 proxy protocol, setting a single timeout threshold, and retrying at fixed intervals when it fails, with the number of retries not exceeding a preset upper limit; If any request within the retry limit is successful, the first channel test is considered passed.

6. The method according to claim 1, characterized in that, It also includes a circuit breaker step, which is executed during the migration scheduling process, specifically including: Maintain the failure count for each migration batch and the failure count for each source instance. When any migration detail fails to initiate an asynchronous task to change the public IP address in step S6, or fails to receive a migration callback in step S7, the failure is simultaneously counted in the failure count of the batch to which the migration detail belongs and the failure count of the source instance to which the migration detail belongs. When the failure count of any source instance reaches the first preset threshold, the scheduling of all migration details under that source instance that have not yet initiated the asynchronous task of changing public IP binding will be suspended, the migration details under that source instance that have not yet completed scheduling will be marked as failed, and further scheduling of that source instance will be stopped until a manual confirmation instruction is received before it can be resumed. When the failure count of any batch reaches the second preset threshold, the scheduling of all unexecuted migration details in this batch is immediately terminated, the overall status of this batch is set to failed, and all subsequent execution processes of this batch are stopped.

7. The method according to claim 1, characterized in that, After sending the instance release request to the cloud vendor interface in step S9, the method further comprises: receiving a release success callback, updating the status of the instance and its associated network interface card to deleted, and recording the actual release time of the instance; if a release failure callback is received, accumulating the failure count to the instance release error counter of the corresponding batch, and terminating subsequent instance release operations of this batch when the instance release error count reaches the preset threshold.

8. A cloud proxy resource merging and migration device based on network interface card slot capacity constraints, characterized in that, comprising: a resource collection and isolation grouping module, configured to obtain the mapping relationship between public IPs currently in use and instance network interface cards under a target cloud vendor, group the mapping relationship according to a preset isolation key to obtain at least one isolation group, and filter out instances with full slots in each isolation group, wherein the instance with full slots refers to an instance of which the number of currently used network interface cards is equal to its upper limit of slot capacity; a grading module, configured to, for each isolation group, acquire the remaining validity period of each candidate migration-in instance, divide the candidate migration-in instances into a bearable layer and a non-bearable layer according to a preset expiration threshold, wherein only the reusable network interface card slots of the instances in the bearable layer are included in subsequent capacity calculation; a capacity calculation and division module, configured to calculate the minimum number of reserved instances required by the isolation group according to the formula need_instance_count=ceil(public_ip_count / ip_mode), perform descending sorting based on the number of currently used network interface cards of each instance, divide the first need_instance_count instances into a reserved set, and divide the remaining instances into a to-be-deleted set, wherein public_ip_count is the total number of public IPs currently in use in the isolation group, and ip_mode is the upper limit of the slot capacity of a single instance; an isolation grouping routing module, configured to count the total number of reusable network interface card slots residue_count of the instances in the bearable layer in the reserved set, and the total number of to-be-migrated public IPs change_ip_count in the to-be-deleted set; if residue_count<change_ip_count, moving the instance with the largest number of currently occupied network interface card slots in the to-be-deleted set into the reserved set, and repeating the statistics and comparison of this step until residue_count≥change_ip_count is satisfied or it is determined that the to-be-deleted set is empty; a migration detail generation module, configured to, when residue_count≥change_ip_count is satisfied, take the instances in the to-be-deleted set as source instances, take the corresponding instances in the bearable layer in the reserved set as target instances, assign one reusable network interface card slot of the instance in the bearable layer in the reserved set to each proxy in use in the to-be-deleted set, generate one-to-one migration detail records, attribute a group of migration detail records generated under the same trigger condition to the same migration batch, and persist the migration detail records; The concurrent lock control migration scheduling module requests a distributed lock for the target network interface ID in each migration detail based on the cloud vendor's configuration items; after successfully acquiring the lock, it initiates an asynchronous task to change the public IP binding to the migration execution service; if the lock acquisition fails, the status of the migration detail is set to a failed status of waiting for retry, and it will be reprocessed in a subsequent scheduling cycle. The callback consistency update module receives a successful migration callback and, within a single database transaction of the business database, updates the public IP binding relationship, target network interface status, source network interface status, resource object references, subscription expiration time, network interface binding history, and proxy association relationship in an atomic manner. If any update operation fails, the entire transaction is rolled back. After a successful update, the proxy configuration recovery process is triggered. The availability verification module performs connectivity checks on at least one channel for the migrated agent. If the check passes, it determines whether the source instance corresponding to the migration details no longer has any in-use network interface cards. If so, the record of the source instance is written to the deletion queue. The deletion determination and release module retrieves instance records from the deletion queue and queries the database again to check the current status of all network interface records associated with the instance. If any network interface record is in use, the record is marked as "not to be deleted" and the deletion operation is skipped. If it is confirmed that there is no network interface in use, an instance release request is sent to the cloud vendor interface, and the status of the instance and its associated network interface is updated to deleted after a successful callback.

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 method as described in any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the method as described in any one of claims 1 to 7.

Images