Unit migration, request initiation and request routing method, device, apparatus and medium

Abstract

Embodiments of the present application provide a unit migration, request initiation and request routing method, device, equipment and medium, relating to the field of financial technology or other related fields. Based on the unit architecture, units are divided into logical units and physical units, each logical unit has a corresponding physical unit in at least one park, and the domain name of the calling request is generated based on the unit identifier of the physical unit where the service provider is located. The unit migration method first generates a new routing rule, adds a new domain name strategy to the old park load balancer and points to the old physical unit address, then migrates application instances in batches, and during migration, the new routing rule is configured in the new physical unit and the domain name is adjusted to point to. The request initiation method determines the target shard number by the load balancer and constructs the domain name before sending the hypertext transfer protocol request; the request routing method extracts the request information and routes to the target node according to the routing rule; the method realizes the batch migration of application instances in the logical unit, and improves the migration efficiency.

Description

Technical Field

[0001] This application relates to the field of financial technology or other related fields, and in particular to a method, apparatus, device and medium for unit migration, request initiation and request routing. Background Technology

[0002] With the continuous expansion of financial business and the accelerated pace of digital transformation, financial institutions are increasingly demanding higher system availability, data security, and business continuity. To address these challenges, modular architecture is gradually becoming the mainstream choice. This architecture divides business data and applications into multiple independent units, achieving data isolation, risk diversification, and elastic system scalability, thereby improving overall processing capacity and stability.

[0003] In the prior art, a data migration method based on a unitized architecture is disclosed, which specifically states that when an application is migrated, all its upstream consumer applications must synchronously modify their configurations and complete the service call switch at the same time; if multiple applications need to be migrated at the same time, the number of upstream applications that need to be coordinated needs to be increased; and when the migration scale is large, it needs to be implemented in batches.

[0004] However, because all upstream consumer applications are required to modify their configurations and switch over synchronously during migration, the migration operation is strongly coupled to the upstream and downstream systems, increasing the complexity of implementation and the risk of errors. When multiple applications migrate simultaneously, the difficulty and workload of coordinating a large number of upstream applications increase significantly, and management costs rise sharply. In the scenario of phased migration, the dependencies between different batches will cause some upstream applications to be involved in the change process multiple times, further increasing the complexity of operations, prolonging the implementation cycle, and resulting in low migration efficiency. Summary of the Invention

[0005] This application provides a method, apparatus, device, and medium for unit migration, request initiation, and request routing to solve the problem of low migration efficiency.

[0006] In a first aspect, this application provides a unit migration method applied to an application system based on a unitized architecture. The method is characterized in that the units in the application system are divided into logical units and physical units; the logical units include data shards and application nodes; the physical units are bound to infrastructure, and each physical unit corresponds to a campus; each logical unit corresponds to a physical unit in at least one campus; the domain name of the application system's call request is generated based on the unit identifier of the physical unit where the service provider is located. The method includes:

[0007] A new routing rule is generated based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated was located in the old campus before migration and the corresponding physical unit was the old physical unit, and the new physical unit is located in the new campus;

[0008] In the load balancer of the logical unit where the service provider of the old campus is located, add a load balancing policy corresponding to the new domain name, and configure the new domain name to point to the address of the load balancer of the old physical unit; the new domain name is generated based on the unit identifier of the new physical unit;

[0009] The application instances within the logical unit to be migrated are migrated in batches. During the migration process, the new routing rules are configured on the service nodes of the new physical unit, and the new domain name and the old domain name are modified to point to the address of the load balancer of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit.

[0010] Secondly, this application provides a request initiation method applied to an application system based on a unitized architecture, the method comprising:

[0011] The fragment number of the target fragment is determined based on the routing field in the call request sent by the client;

[0012] When a call request is converted into a Hypertext Transfer Protocol (HTTP) request, the fragment number of the target fragment is added to the HTTP request, and based on routing rules, the unit identifier of the physical unit corresponding to the logical unit to which the target fragment belongs is determined. The domain name of the HTTP request is constructed based on the unit identifier of the physical unit. The application system based on the unit architecture is migrated based on the method provided in the second aspect.

[0013] Send the Hypertext Transfer Protocol request.

[0014] Thirdly, this application provides a request routing method applied to an application system based on a unitized architecture, the method comprising:

[0015] In response to a Hypertext Transfer Protocol (HTTP) request, the unit identifier of the physical unit and the fragment number of the target fragment carried in the HTTP request are extracted; the HTTP request is initiated based on a method provided by a third party.

[0016] Based on routing rules, as well as the unit identifier of the physical unit and the fragment number of the target fragment, the Hypertext Transfer Protocol request is routed to the target node so that the target node can respond to the Hypertext Transfer Protocol request.

[0017] Fourthly, this application provides a unit migration device, characterized in that it is applied to an application system based on a unitized architecture, the device comprising:

[0018] The new routing rule generation module is used to generate new routing rules based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated was located in the old campus before migration and the corresponding physical unit was the old physical unit, and the new physical unit is located in the new campus;

[0019] The migration preparation module is used to add a load balancing policy corresponding to the new domain name to the load balancer of the logical unit where the old campus service provider is located, and configure the new domain name to point to the address of the load balancer of the old physical unit; the new domain name is generated based on the unit identifier of the new physical unit.

[0020] The batch migration module is used to migrate application instances within the logical unit to be migrated in batches. During the migration process, the new routing rules are configured on the service node of the new physical unit, and the new domain name and the old domain name are modified to point to the address of the load balancer of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit.

[0021] Fifthly, this application provides a request initiation apparatus for use in a unitized architecture-based application system, the apparatus comprising:

[0022] The fragment number determination module is used to determine the fragment number of the target fragment based on the routing field in the call request sent by the client.

[0023] The request conversion module is used to add the fragment number of the target fragment to the Hypertext Transfer Protocol request when the call request is converted into a Hypertext Transfer Protocol request, and to determine the unit identifier of the physical unit corresponding to the logical unit to which the target fragment belongs based on the routing rules, and to construct the domain name of the Hypertext Transfer Protocol request based on the unit identifier of the physical unit; wherein, the application system based on the unit architecture migrates based on the method provided in the first aspect;

[0024] The request initiation module is used to send the Hypertext Transfer Protocol request.

[0025] Sixthly, this application provides a request routing apparatus, characterized in that it is applied to an application system based on a modular architecture, the apparatus comprising:

[0026] The request parameter extraction module is used to extract the unit identifier of the physical unit and the fragment number of the target fragment carried in the Hypertext Transfer Protocol request in response to the Hypertext Transfer Protocol request; the Hypertext Transfer Protocol request is initiated based on the method provided in the second aspect;

[0027] The request routing module is used to route the Hypertext Transfer Protocol request to the target node based on routing rules, the unit identifier of the physical unit and the fragment number of the target fragment, so that the target node can respond to the Hypertext Transfer Protocol request.

[0028] In a seventh aspect, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the methods provided in the first, second, and third aspects above.

[0029] Eighthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the methods provided in the first, second, and third aspects above.

[0030] Ninthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the methods provided in the first, second, and third aspects described above.

[0031] The unit migration, request initiation, and request routing methods provided in this application, based on a unitized architecture, divide application systems into logical units (including data shards and application nodes) and physical units (bound to infrastructure and each corresponding to a park). Each logical unit has a corresponding physical unit in at least one park. The application system's call request domain name is generated based on the unit identifier of the physical unit where the service provider is located. The unit migration method is applied to this system by first generating new routing rules based on the new physical unit identifier of the logical unit to be migrated. Then, a load balancing policy corresponding to the new domain name is added to the load balancer of the logical unit where the service provider is located in the old park, and the new domain name is made to point to the load balancer address of the old physical unit. Next, application instances within the logical unit to be migrated are migrated in batches. During the migration process, new routing rules are configured on the service nodes of the new physical units. Then, the new and old domain names are pointed to the address of the new physical unit load balancer. The request initiation method is applied to the load balancer in the first logical unit. Based on the routing field in the call request, the target shard number is determined. When the call request is converted into a Hypertext Transfer Protocol (HTTP) request, the shard number is added, and the domain name is constructed based on the unit identifier of the physical unit to which the target shard belongs, and then the HTTP request is sent. The request routing method is applied to the load balancer in the second logical unit. It responds to the HTTP request initiated by the request initiation method, extracts the physical unit identifier and the target shard number, and routes the request to the target node based on the routing rules to respond to the request. This scheme improves the call success rate in the unit migration scenario and effectively ensures the reliability and stability of the service during the migration process. Attached Figure Description

[0032] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0033] Figure 1 An application system diagram based on a modular architecture is provided for embodiments of this application;

[0034] Figure 2 A flowchart illustrating a cell migration method provided in an embodiment of this application;

[0035] Figure 3 A schematic diagram of cell migration provided in an embodiment of this application;

[0036] Figure 4 A flowchart illustrating a request initiation method provided in an embodiment of this application;

[0037] Figure 5 A flowchart illustrating a request routing method provided in an embodiment of this application;

[0038] Figure 6-1 , Figure 6-2 , Figure 6-3 and Figure 6-4 A schematic diagram illustrating request initiation and request routing provided in an embodiment of this application;

[0039] Figure 7 This is a schematic diagram of the structure of a unit migration device provided in an embodiment of this application;

[0040] Figure 8 A schematic diagram of a request initiation device provided in an embodiment of this application;

[0041] Figure 9 This is a schematic diagram of the structure of a request routing device provided in an embodiment of this application;

[0042] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0043] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0044] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0045] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of the relevant data all comply with the relevant laws, regulations, and standards of the relevant countries and regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation access points for users to choose to authorize or refuse.

[0046] Furthermore, the technical solution involved in this application, which involves big data analysis of user information (including but not limited to personal biometrics, identity data, consumption data, asset data, electronic terminal operation data, etc.) and the use of artificial intelligence technology for automated decision-making, and makes decisions that have a significant impact on personal rights based on the results of automated decision-making, provides users with corresponding operation entry points for users to choose to agree to or reject the results of automated decision-making; if the user chooses to reject, the process will proceed to the expert decision-making process.

[0047] It should be noted that the application system, unit migration method and request initiation based on unitized architecture provided in this application can be used in the fintech field, or in any field other than fintech. The application field of the application system, unit migration method and request initiation based on unitized architecture in this application is not limited.

[0048] With the continuous expansion of financial business and the acceleration of digital transformation, the financial sector's demand for high system availability, data security, and business continuity has significantly increased. To address these challenges, modular architecture, due to its ability to divide business data and applications into multiple independent units, achieving advantages such as data isolation, risk diversification, and elastic scaling, has gradually become a mainstream technical solution, effectively improving the overall processing capacity and stability of the system.

[0049] In the prior art, a data migration method based on a unitized architecture specifically discloses the following approach: when an application needs to be migrated, all its upstream consumer applications must synchronously complete the configuration modification and service call address switching at the same time; if multiple applications need to be migrated at the same time, the upstream consumer corresponding to each migrated application must participate in the coordination; and when facing a large-scale migration task, due to resource or operational limitations, the migration task usually needs to be divided into multiple batches for gradual implementation.

[0050] However, existing technologies require all upstream consumer applications to modify their configurations and switch synchronously during migration, resulting in a strong coupling between upstream and downstream systems, making the migration operation complex and prone to errors. When multiple applications need to be migrated at the same time, the difficulty and workload of coordinating a large number of upstream applications increase significantly. In the scenario of batch migration, due to the dependencies between different batches, some upstream applications need to participate in the change process repeatedly, resulting in more cumbersome operations, longer implementation cycles, and low overall migration efficiency.

[0051] The unit migration, request initiation, and request routing methods provided in this application aim to solve the aforementioned technical problems of existing technologies. Specifically, the application system unit is subdivided into logical units (including data shards and application nodes) and physical units (bound to infrastructure and each corresponding to a park). Each logical unit has a corresponding physical unit in at least one park, and the domain name of the call request is generated based on the unit identifier of the physical unit where the service provider is located. Based on this, a unit migration method is designed to achieve smooth migration of logical units between different physical units by generating new routing rules, adjusting load balancing strategies, and migrating application instances in batches. At the same time, a request initiation method is proposed, in which the load balancer determines the target shard number based on the routing field in the call request, constructs the domain name, and sends a Hypertext Transfer Protocol (HTTP) request. A request routing method is also proposed, in which the load balancer in another logical unit extracts the physical unit identifier and the target shard number from the HTTP request and routes the request to the target node according to the routing rules. Through the synergistic effect of these methods, the unit migration efficiency is effectively improved.

[0052] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will now be described with reference to the accompanying drawings.

[0053] Figure 1 This application system diagram illustrates a unitized architecture based on embodiments of this application. The application system provided by this application is a unitized architecture where units are divided into logical units and physical units.

[0054] Logical units include data shards and application nodes, while physical units are bound to infrastructure. Each physical unit corresponds to a campus; each logical unit has a corresponding physical unit in at least one campus.

[0055] The domain name of the application system's call request is generated based on the unit identifier of the physical unit where the service provider is located.

[0056] Among them, the logical unit corresponds to the original concept of unit division and layout. It is an abstract division, mainly to maintain consistency and coherence in system architecture design and operation and maintenance management.

[0057] Physical units are bound to infrastructure, specifically to data centers and resource domains, with each physical unit corresponding to a campus. The division of physical units is based on actual physical location and infrastructure resources.

[0058] Each logical unit corresponds to a physical unit in at least one campus, and there is a many-to-many relationship between them, connected by a "1:N" mapping. For example, one logical unit may correspond to physical units in multiple campuses to achieve distributed data storage and multi-site deployment of applications; while one physical unit may also carry the business of multiple logical units.

[0059] During the migration of units from the new data center campus to the old campus, the logical unit number remained unchanged, ensuring the stability of business logic and operation and maintenance management. However, the physical unit number differed on both sides due to the different physical locations, because physical units are closely associated with specific campuses and infrastructures, and changes in physical location inevitably lead to changes in their identification.

[0060] The domain name for application system call requests is generated based on the unit identifier of the physical unit where the service provider is located. This means that the physical location (campus) of the service provider can be clearly identified through the domain name, facilitating precise service calls and resource location. For example, if the service provider is located in a physical unit of a specific campus, its domain name will contain the identifier information of that physical unit, allowing the caller to directly find the corresponding service provider based on the domain name.

[0061] Figure 2 This is a flowchart illustrating a unit migration method provided in an embodiment of this application. The method provided in this application can be executed by an application system based on a unitized architecture, or by a device communicatively connected to an application system based on a unitized architecture, such as a computer or server. Figure 2 As shown, the cell migration method provided in this embodiment includes the following steps:

[0062] S101: Generate new routing rules based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated was located in the old campus before migration and the corresponding physical unit was the old physical unit, and the new physical unit is located in the new campus.

[0063] In scenarios involving unit migration within a unit-based architecture application system, updating routing rules is crucial for ensuring normal system operation and accurate data flow. When deciding to migrate a logical unit from the old campus to the new campus, it's essential to first identify the corresponding new physical unit within the new campus. Each physical unit has a unique unit identifier, which is key information for identifying and locating the physical unit. Based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated, the system generates new routing rules.

[0064] The logical unit to be migrated was located in the old campus before the migration, and it had a corresponding physical unit in the old campus, namely the old physical unit. The old physical unit carried out the business operation and data storage functions of the logical unit in the old campus. The new physical unit, on the other hand, is located in the new campus and is the target physical environment in which the logical unit to be migrated will be deployed and run after the migration.

[0065] The new routing rule is generated based on the unit identifier of the new physical unit. This new routing rule explicitly instructs the system to correctly route requests to the new physical unit after the logical unit to be migrated is moved to the new campus. For example, in a distributed system, when a client initiates a request, the system will direct the request to the corresponding new physical unit in the new campus according to the new routing rule, instead of directing it to the old physical unit in the old campus as before the migration.

[0066] S102: In the load balancer of the logical unit where the old campus service provider is located, add the load balancing policy corresponding to the new domain name, and configure the new domain name to point to the address of the load balancer of the old physical unit; the new domain name is generated based on the unit identifier of the new physical unit.

[0067] When migrating an application system with a modular architecture to a new campus, the load balancer of the logical unit where the old campus service provider is located needs to be configured and adjusted to ensure a smooth transition and continuous availability of services during the migration process.

[0068] First, a new domain name will be generated based on the unit identifier of the new physical unit. This unit identifier is the unique identifier of the new physical unit in the system, and the new domain name is generated from this identifier.

[0069] Next, within the logical unit where the service provider in the old campus resides, the load balancer is responsible for distributing received requests appropriately across various service nodes to maintain the system's efficient operation and stability. To enable the system to handle new domain name requests related to the new physical unit, a load balancing strategy corresponding to the new domain name needs to be added to this load balancer.

[0070] Finally, configure the new domain name to point to the load balancer address of the old physical unit. During the migration transition phase, even though the new domain name corresponds to the new physical unit, requests will first reach the load balancer in the old campus. The old campus load balancer, according to a preset policy, forwards the requests to the old physical unit for processing, thereby ensuring uninterrupted service during the migration process and continuously providing services to users. As the migration work is gradually completed, the load balancing policy can be further adjusted to gradually redirect requests to the new physical unit in the new campus, achieving a smooth service migration.

[0071] For example, suppose a financial application system uses a unitized architecture and is deployed in an old campus and a new campus. The old campus has four logical units, numbered RZ01, RZ02, RZ03, and RZ04. Each logical unit has a corresponding load balancer to distribute requests evenly to the service providers within that unit. Now, it is planned to migrate some services to the new campus, which also has corresponding physical units. To achieve a smooth transition during the migration, a load balancing strategy corresponding to the new domain name needs to be added to the load balancer of the old campus.

[0072] The new campus has set up new physical units corresponding to the old campus units RZ02 and RZ04. Unit identifiers have been generated for these two new physical units. The physical unit identifier for RZ02 is NZ02, and the physical unit identifier for RZ04 is NZ04. New domain names are generated based on these unit identifiers.

[0073] S103: For batch migration of application instances within the migration logical unit, during the migration process, new routing rules are configured on the service nodes of the new physical unit, and the new and old domain names are modified to point to the address of the load balancer of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit.

[0074] During the migration process, new routing rules need to be configured on the service nodes of the new physical unit. These new routing rules are generated based on the unit identifier of the new physical unit and determine how the system correctly routes requests to application instances within the new physical unit. Configuring these new routing rules on the service nodes of the new physical unit enables these nodes to process and forward requests according to predetermined strategies, ensuring the accurate execution of business logic.

[0075] Simultaneously, both the new and old domain names need to be modified. The new domain name is generated based on the unit identifier of the new physical unit, representing the access address of the new physical unit in the network. The old domain name is generated based on the unit identifier of the old physical unit; before the migration, requests were directed to the old physical unit via the old domain name. During the migration process, both the new and old domain names are modified to point to the address of the load balancer of the new physical unit. Requests initiated via either the new or old domain name will be redirected to the load balancer of the new physical unit, which will then distribute the requests to the appropriate application instances according to the new routing rules, thus achieving a smooth service transition and continuous availability.

[0076] Optionally, for the phased migration of application instances within the logical unit to be migrated, new routing rules are configured on the service nodes of the new physical unit during the migration process. Specific implementation methods include:

[0077] When migrating application instances within a logical unit in batches, for each application instance in the logical unit to be migrated, a unitized environment for the application instance is built in the new physical unit; the load balancing strategies corresponding to the new domain name and the old domain name are imported into the load balancer of the new physical unit, and new routing rules are configured on the service nodes of the new physical unit; the data of the application instance is switched from the database of the old physical unit to the database of the new physical unit; and the new domain name and the old domain name are modified to point to the address of the load balancer of the new physical unit.

[0078] First, when migrating application instances within logical units to be migrated in batches, the first step is to build a unitized environment for the application instances in the new physical unit. This is because the new physical unit, as the runtime environment for the migrated application instances, needs to have basic operating conditions that match the old physical unit and meet the requirements of the new environment. Building a unitized environment involves many aspects, such as configuring server resources, installing necessary software and dependencies, and setting up the network environment, to ensure that the new physical unit can provide stable operational support for the application instances.

[0079] Next, load balancing policies corresponding to the new and old domain names are imported into the load balancer of the new physical unit. The new domain name is generated based on the unit identifier of the new physical unit, representing the new access identifier of the new physical unit in the network; the old domain name is generated based on the unit identifier of the old physical unit and was used to access application instances in the old physical unit before the migration. The purpose of importing the load balancing policies is to enable the load balancer to reasonably distribute requests to various service nodes in the new physical unit according to preset rules, such as the load status and response time of service nodes. At the same time, new routing rules are configured on the service nodes of the new physical unit. The new routing rules are generated based on the unit identifier of the new physical unit and determine the routing path of requests within the new physical unit, ensuring that requests can accurately reach the corresponding application instances.

[0080] Next, the application instance's data is switched from the database in the old physical unit to the database in the new physical unit. Data is one of the core elements for the normal operation of the application instance, and data switching requires careful operation. This typically involves steps such as data backup, data transfer, and data recovery. It is essential to ensure that data is not lost or corrupted during the switching process, and that data consistency is maintained. Only after the data switch is completed can the application instance process business logic normally in the new physical unit.

[0081] Finally, both the new and old domain names are modified to point to the load balancer address of the new physical unit. After the modification, requests initiated through either the new or old domain names will be directed to the load balancer in the new physical unit. The load balancer will then distribute the requests to the appropriate application instances according to the new routing rules, thus completing the migration process of application instances from the old physical unit to the new physical unit and ensuring the continuous and stable operation of the system during the migration process.

[0082] For example, such as Figure 3 As shown, the logical units to be migrated are units containing application A and application B. The old physical units include Campus A, Campus B, etc., and the new physical units include Campus E, Campus F, etc. The routing rules for the old units contain information such as RZ01: Campus A unit number, RZ02: Campus A unit number, etc. These rules are used for referencing applications that have not yet been migrated.

[0083] Taking applications A and B as examples, in the new physical units (Campus E and Campus F), environments suitable for the operation of applications A and B are built according to the requirements of the unitized architecture. This ensures that applications A and B can be deployed and run normally in the new physical units. Under the SLB (Load Balancer) in Campus F, the corresponding server resources are prepared for applications A and B.

[0084] The new routing rules are those referenced by the migrated applications and include information such as RZ02:E campus unit number and RZ04:F campus unit number. These new routing rules are configured on the service nodes in the new physical units, enabling the service nodes to correctly identify and process requests based on these rules, routing them to the appropriate application instances. When a request contains a specific identifier, the service node can forward the request to the corresponding application instance in the new physical unit according to the new routing rules.

[0085] For applications A and B, migrate their data from the database in the old physical unit (such as Campus A and Campus B) to the database in the new physical unit (such as Campus F).

[0086] The unit migration method provided in this application generates new routing rules based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated. The logical unit to be migrated was located in the old campus before migration, and its corresponding physical unit is the old physical unit. The new physical unit is located in the new campus. A load balancing policy corresponding to the new domain name is added to the load balancer of the logical unit where the service provider in the old campus is located, and the new domain name is configured to point to the address of the load balancer of the old physical unit. The new domain name is generated based on the unit identifier of the new physical unit. During the batch migration of application instances within the logical unit to be migrated, new routing rules are configured on the service nodes of the new physical unit, and the new and old domain names are modified to point to the address of the load balancer of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit. This method achieves batch migration of application instances within a logical unit by generating new routing rules and configuring new domain names to point to the new physical unit, thereby reducing the coupling between upstream and downstream systems while improving migration efficiency.

[0087] In some embodiments, the method for updating new routing rules includes: after completing the migration of an application instance, performing intra-city switching on multiple logical units of the application instance that has not been migrated in the old campus; after completing the intra-city switching of multiple logical units, updating the routing rules of the service nodes of the multiple logical units to the new routing rules.

[0088] First, after migrating an application instance, a local handover needs to be implemented for multiple logical units in the old campus where the application instances that were not migrated reside. The purpose of the local handover is to adjust the system's resource allocation and operating strategies to accommodate the situation where some application instances have already been migrated to the new campus. During the local handover process, the system will adjust the configuration and connection methods of these unmigrated logical units in the old campus to ensure they can work collaboratively with the migrated parts in the new campus, maintaining the stability and availability of the entire system. For example, network connection parameters and data synchronization methods may be adjusted to ensure smooth data flow and consistency between different campuses.

[0089] After completing the intra-city handover of multiple logical units, the next step is to update the routing rules of the service nodes of these logical units to the new routing rules. The new routing rules are generated based on the unit identifier of the new physical unit and can accurately guide the routing path of requests in the new environment. Updating the service node routing rules to the new rules indicates that the system will intelligently route requests according to the new architecture and environment. In this way, requests from both the new and old campuses can be correctly directed to the corresponding service nodes according to the new routing rules, ensuring the accurate execution of business logic and the efficient operation of the system.

[0090] For example, assume that application A has been migrated from unit RZ04 (Campus B) to a new campus (such as Campus F). During the migration process, the runtime environment of application A has been set up in the new campus, the load balancing policy and routing rules have been configured, the data has been migrated to the database in the new campus, and the relevant domain names have been pointed to the load balancer address in the new campus.

[0091] In the old campus, Application A still has units such as RZ01 (Campus A), RZ02 (Campus A), and RZ03 (Campus B) that have not been migrated; Application B also has units such as RZ01 (Campus A) and RZ03 (Campus B) that have not been migrated.

[0092] The purpose of intra-city failover is to enable application instances in the old campus that have not been migrated to better balance load and provide services within the same city, while also preparing for a full migration later. For application A's RZ01-A unit, its load balancing strategy might have previously only applied to campus A. Now, it needs to be adjusted to allow it to work collaboratively with other campuses in the same city (such as the unmigrated portion of campus B and the new campus). Specifically, the load balancing strategy is adjusted so that when consumers (regardless of whether they have migrated) access application A, requests can be distributed based on the load of each unit within the same city. For example, when the load on unit RZ01-A in campus A is high, some requests can be distributed to unit RZ03-B in campus B (if that unit has sufficient resources), achieving load balancing within the same city.

[0093] After confirming that the same-city handover is running stably and that the collaboration between various logical units is normal, the routing rules of the service nodes are updated.

[0094] The specific steps for updating routing rules are as follows: Taking RZ01-A unit of application A as an example, its original routing rules might only contain unit numbers and routing logic within the old campus (such as RZ01:A campus unit number in the old unit routing rules). Now, it is updated to a new routing rule, which includes information such as the new campus unit number (such as RZ04:F campus unit number in the new unit routing rule). Thus, when a service node receives a request, it will make a routing decision based on the new routing rules, potentially routing the request to the application instance in the new campus, rather than being limited to the old campus. Similarly, a similar routing rule update operation is performed for other non-migrated logical units such as RZ01-A unit of application B, enabling them to interact and collaborate with application instances in the new campus according to the new rules.

[0095] In some embodiments, after an application instance within the logical unit to be migrated has been migrated, the device resources of that application instance in the old physical unit are reclaimed.

[0096] When application instances run in the old physical unit, they consume various device resources such as server computing resources (CPU, memory), storage resources (hard disk space), and network resources. After the application instances are migrated to the new physical unit, these resources become idle in the old physical unit. If they are not reclaimed in a timely manner, it will not only waste resources but may also lead to resource shortages in the old physical unit, affecting the performance and stability of other application instances still running in the old physical unit.

[0097] First, a comprehensive review and identification of the resources occupied by the application instance within the old physical unit is necessary, clearly identifying which servers, storage devices, and network ports are involved. Next, these resources are gradually released according to a predetermined resource reclamation process. For example, for server computing resources, related processes and services should be stopped, and the CPU and memory resources allocated to the application instance should be returned to the resource pool; for storage resources, the application instance's data files should be deleted to free up disk space; and for network resources, the network ports occupied by the application instance should be unbound, etc.

[0098] Through orderly and thorough resource recycling operations, the resources of old physical units can be reasonably released and redistributed, improving resource utilization. This also creates favorable conditions for subsequent system maintenance and management, ensuring that resource management and utilization of the entire modular architecture system are more efficient and reasonable during the migration process.

[0099] For example, suppose there are old campuses (such as Campus A and Campus B) and a new campus (such as Campus F), and applications are deployed using a unitized architecture. Multiple applications, such as Application A and Application B, are distributed across different logical units (such as RZ01, RZ02, etc.). Now, we want to migrate the instance of Application A in unit RZ04 of the old campus (Campus B) to the new campus (Campus F). Once the instance of Application A in unit RZ04 of Campus B has been successfully deployed and is running in the new campus (Campus F), the device resources of unit RZ04 in Campus B can be reclaimed.

[0100] In some embodiments, after all application instances within the logical unit to be migrated have been migrated, the policies corresponding to the old domain names in all load balancers of the new and old parks are deleted.

[0101] Specifically, in the migration of a unitized architecture system, once all application instances within the logical unit to be migrated have been successfully migrated, the system architecture has undergone substantial changes. At this point, the business logic and data access paths corresponding to the original old domain names have been completely transferred to the new physical units in the new campus. The old domain names were originally generated based on the unit identifiers of the old physical units. During the migration process, they served a transitional role, ensuring continued service availability during the migration. However, with all application instances migrated, the relevant policies of the old domain names in the load balancer become unnecessary and may even cause potential problems, thus requiring cleanup.

[0102] To ensure a smooth service transition during the migration process, the load balancers in both the new and old campuses retained the policies corresponding to the old domain names. These policies were originally intended to route and process requests originating from the old domain names according to certain rules during the migration, initially directing them to the old physical units (in the early stages of migration) and gradually redirecting them to the new physical units. However, once all application instances have been migrated, retaining these policies could lead to confusion in request routing. For example, some requests might still be incorrectly routed to old physical units that no longer support the relevant business logic, or the load balancer's routing decision-making process might become complex and inefficient, increasing system management difficulty and potential risks.

[0103] Remove the policies corresponding to the old domain names from all load balancers in both the new and old campuses. After removing these policies, the load balancers will no longer handle requests originating from the old domain names specially, but will instead route requests entirely based on the new domain names and new routing rules. This not only simplifies the routing decision-making process of the load balancers and improves the overall performance and stability of the system, but also avoids potential errors and security risks caused by the existence of old policies, ensuring that the system can operate in a clearer and more efficient manner after the migration is completed.

[0104] For example, the old campus has two campuses, A and B, and the new campus is campus C. Multiple applications are distributed across different logical units (such as RZ01, RZ02, RZ03, RZ04, etc.). Routing rules based on the old campus unit numbers (such as R2, R4) are configured in the load balancer (SLB). If the enterprise decides to migrate all applications from the old campus to the new campus, it can delete the routing rules corresponding to the old domain names (such as R2, R4) in all load balancers in both the new and old campuses.

[0105] Figure 4This is a flowchart illustrating a request initiation method provided in an embodiment of this application. The method provided in this application can be executed by an application system based on a unitized architecture. In this unitized architecture application system, the logical unit includes a first logical unit. Specifically, it can be executed by a load balancer within the first logical unit, or by a device communicatively connected to the load balancer within the first logical unit, such as a computer or server. Figure 4 As shown, the request initiation method provided in this embodiment includes the following steps:

[0106] S201: Determine the fragment number of the target fragment based on the routing field in the call request sent by the client.

[0107] Specifically, the target shard's shard number is determined based on the routing field in the client's request. In distributed systems, data is typically distributed across multiple shards, with each shard responsible for processing a portion of the data. The routing field contains key information related to the request, such as the user's identifier and the business type. By parsing this routing field, the load balancer can obtain the target shard's shard number. For example, if the routing field is a user ID, the load balancer might perform a modulo operation between the hash value of the user ID and the total number of shards to obtain the target shard's shard number. This process ensures that requests are accurately routed to the shard storing the relevant data, avoiding blind data lookups and unnecessary network transmissions.

[0108] Once the load balancer determines the shard number, it can locate the corresponding service node based on the system's configuration information and forward the call request to that service node. Upon receiving the request, the service node can process it according to the specific business logic within the request and return the appropriate result. Furthermore, the method of determining the shard number based on the routing field also offers flexibility and scalability. When the system needs to add or remove shards, simply adjusting the corresponding algorithm or rules can adapt to the new system architecture and ensure accurate request routing.

[0109] S202: When the call request is converted into a Hypertext Transfer Protocol (HTTP) request, the fragment number of the target fragment is added to the HTTP request, and based on the routing rules, the unit identifier of the physical unit corresponding to the logical unit to which the target fragment belongs is determined, and the domain name of the HTTP request is constructed based on the unit identifier of the physical unit; wherein, the application system based on the unit architecture is migrated based on the method provided above.

[0110] The routing rules can be old or new. The rules stored are different at different migration stages. After the migration is completed, the rules are new, and before the migration is completed, the rules are old.

[0111] In distributed or modular system interactions, call requests need to be converted into Hypertext Transfer Protocol (HTTP) requests for transmission and processing over the network. When a call request enters this conversion process, the system adds the previously determined target shard's fragment number to the HTTP request. The target shard's fragment number carries the specific location information of the data the request needs to access. In distributed data storage scenarios, data is distributed across multiple shards. By adding the fragment number to the HTTP request, subsequent routing and data processing stages can clearly determine which data shard the request should be directed to, ensuring that the request accurately reaches the node storing the relevant data, thus improving the efficiency and accuracy of data processing.

[0112] After adding the fragment number, the system further determines the unit identifier of the physical unit corresponding to the logical unit to which the target fragment belongs, based on preset routing rules. Through these rules, the system can intelligently map fragments within a logical unit to specific physical units. For example, data of certain business types may be preferentially allocated to physical units with specific performance characteristics, or the distribution of fragments may be dynamically adjusted based on the current load of the physical unit. Once the unit identifier of the physical unit is determined, the system clearly defines the actual physical location to which the request will ultimately reach, providing crucial information for subsequently constructing the domain name for the Hypertext Transfer Protocol (HTTP) request.

[0113] Based on the defined physical unit identifier, the system constructs the domain name for the Hypertext Transfer Protocol (HTTP) request. Domain names serve as identifiers and location services in network communication. By incorporating the physical unit identifier into the domain name construction rules, the system generates a unique and accurate domain name, ensuring that the HTTP request is correctly sent to the target physical unit. During the migration process, routing rules and domain name construction rules are adjusted accordingly to ensure that requests can still be accurately routed to the correct physical unit after the logical unit migration, guaranteeing stable system operation and business continuity.

[0114] S203: Send Hypertext Transfer Protocol request.

[0115] After adding the target fragment number to the Hypertext Transfer Protocol (HTTP) request, determining the physical unit identifier, and constructing the HTTP request domain name, the system sends the constructed HTTP request out through the underlying network protocol stack. During transmission, the HTTP request is encapsulated into network data packets, forwarded by multiple network devices (such as routers and switches), and finally reaches the server of the target physical unit.

[0116] After a Hypertext Transfer Protocol (HTTP) request is sent, the system does not immediately terminate the processing flow but waits for a response from the target server. During this waiting period, the system continuously monitors the network connection status to ensure the request can be transmitted normally. Once a response is received from the target server, the system parses and processes it. The response may contain the result of the request processing, a status code, error messages, etc. Based on this information, the system determines whether the request was successfully executed and performs appropriate follow-up operations according to business requirements. For example, if the request succeeds, the system may return the processing result to the client; if the request fails, the system may log errors and provide error messages. Through this result processing and feedback mechanism, the system can promptly identify and resolve problems, ensuring the normal operation of the business.

[0117] Figure 5 This is a flowchart illustrating a request routing method provided in an embodiment of this application. The method provided in this application can be executed by an application system based on a unitized architecture. In this unitized architecture application system, the logical unit includes a second logical unit. Specifically, it can be executed by a load balancer within the second logical unit, or by a device communicatively connected to the load balancer within the second logical unit, such as a computer or server. Figure 5 As shown, the request routing method provided in this embodiment includes the following steps:

[0118] S301: In response to a Hypertext Transfer Protocol (HTTP) request, extract the unit identifier of the physical unit and the fragment number of the target fragment carried in the HTTP request; the HTTP request is initiated based on the method provided above.

[0119] When the load balancer within the second logical unit receives a Hypertext Transfer Protocol (HTTP) request, it responds to the request and initiates an information retrieval process. This response inevitably includes two key pieces of information: the physical unit's identifier and the target shard's shard number. The physical unit's identifier uniquely identifies the physical server or server cluster to which the request originates, while the target shard's shard number specifies the exact location of the requested data within the distributed storage.

[0120] Once the unit identifier of the physical unit and the fragment number of the target fragment are successfully extracted, the unit identifier can be used to determine which physical unit the request should be routed to, and the fragment number can be used to further locate the specific service node in that physical unit that is responsible for processing the relevant data.

[0121] S302: Based on routing rules, the unit identifier of the physical unit and the fragment number of the target fragment, the Hypertext Transfer Protocol request is routed to the target node so that the target node can respond to the Hypertext Transfer Protocol request.

[0122] Routing rules work closely with the unit identifier of the physical unit and the shard number of the target shard. Routing rules may contain various routing strategies, such as a unit identifier-based load balancing strategy, which distributes requests to lighter-loaded units based on their current load to improve overall system performance and response speed; or a shard number-based hash routing strategy, which maps shard numbers to specific service nodes using a hash algorithm to ensure that data requests for the same shard are routed to the same node. When the load balancer makes decisions based on routing rules, it quickly and accurately determines the target node based on the unit identifier and shard number. For example, if the routing rule specifies that requests for a certain business type should be routed to a specific physical unit first, and the shard number is used to determine the specific service node within that unit, then the load balancer can quickly find the target node and accurately send the Hypertext Transfer Protocol (HTTP) request there.

[0123] Once a Hypertext Transfer Protocol (HTTP) request is routed to the target node, the target node begins processing the request and responding. The target node can be a server running specific business logic. Upon receiving the request, it retrieves the necessary data from local storage or relevant data sources based on the information in the request and processes it according to business rules. For example, if the request is to query information about a user, the target node will retrieve the relevant data for that user from the database, format and organize it, and then encapsulate the results into an HTTP response and return it to the client.

[0124] For example, such as Figure 6-1 As shown, Application A (not migrated) initiates a Hypertext Transfer Protocol (HTTP) request using Application B's old domain name according to the old routing rules. The load balancer receives the request within the first logical unit and determines the fragment number of the target fragment based on the routing field. The load balancer adds the fragment number to the HTTP request and determines the physical unit (new campus R2 / R4 nodes) to which the target fragment belongs according to the old routing rules. The load balancer constructs the domain name for the HTTP request and sends the request. The load balancer in the logical unit where Application B resides receives the HTTP request. It extracts the physical unit identifier and the target fragment number carried in the request. According to the new routing rules, it routes the request to Application B's new campus R2 / R4 nodes.

[0125] like Figure 6-2As shown, Application B (which has been migrated) initiates a Hypertext Transfer Protocol (HTTP) request using Application A's new domain name according to the new routing rules. The load balancer receives the request within the first logical unit and determines the target shard number based on the routing field. The load balancer adds the shard number to the HTTP request and determines the physical unit (old campus R2 / R4 nodes) to which the target shard belongs according to the new routing rules. The load balancer constructs the domain name for the HTTP request and sends the request. The load balancer in the logical unit where Application A resides receives the HTTP request. It extracts the physical unit identifier and target shard number carried in the request. According to the old routing rules, it routes the request to Application A's old campus R2 / R4 nodes.

[0126] like Figure 6-3 As shown, application A (not migrated) initiates a Hypertext Transfer Protocol (HTTP) request to application C (not migrated) according to the old routing rules. The request initiation method is executed on the load balancer within the first logical unit, responsible for constructing and sending the HTTP request. The request routing method is executed on the load balancer within the second logical unit, responsible for receiving the HTTP request and routing it to the correct target node (the old campus R2 / R4 nodes of application C).

[0127] like Figure 6-4 As shown, Application B (which has been migrated) initiates a Hypertext Transfer Protocol (HTTP) request using the new domain name of Application D, according to the new routing rules. The load balancer receives the request within the first logical unit and determines the fragment number of the target fragment based on the routing field. The load balancer adds the fragment number to the HTTP request and determines the physical unit (new campus R2 / R4 nodes) to which the target fragment belongs according to the new routing rules. The load balancer constructs the domain name for the HTTP request and sends the request. The load balancer in the logical unit where Application D resides receives the HTTP request. It extracts the physical unit identifier and the target fragment number carried in the request. According to the new routing rules, it routes the request to the new campus R2 / R4 nodes of Application D.

[0128] Figure 7 This is a schematic diagram of a unit migration device provided in an embodiment of this application. Figure 7 As shown, the unit migration device provided in this embodiment includes: a new routing rule generation module 401, a migration preparation module 402, and a batch migration module 403.

[0129] The new routing rule generation module 401 generates new routing rules based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated was located in the old campus before migration and the corresponding physical unit was the old physical unit, and the new physical unit is located in the new campus.

[0130] The migration preparation module 402 adds a load balancing policy corresponding to the new domain name to the load balancer of the logical unit where the old campus service provider is located, and configures the new domain name to point to the address of the load balancer of the old physical unit; the new domain name is generated based on the unit identifier of the new physical unit.

[0131] The batch migration module 403 performs batch migration of application instances within the logical unit to be migrated. During the migration process, it configures new routing rules on the service nodes of the new physical unit and modifies the new and old domain names to point to the load balancer address of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit.

[0132] Optional, the batch migration module 403 is specifically used for:

[0133] When migrating application instances within a logical unit in batches, for each application instance in the logical unit to be migrated, a unitized environment for the application instance is built in the new physical unit; the load balancing strategies corresponding to the new domain name and the old domain name are imported into the load balancer of the new physical unit, and new routing rules are configured on the service nodes of the new physical unit; the data of the application instance is switched from the database of the old physical unit to the database of the new physical unit; and the new domain name and the old domain name are modified to point to the address of the load balancer of the new physical unit.

[0134] Optionally, the cell migration apparatus further includes: an update routing rules module 404, used for:

[0135] After migrating an application instance, for multiple logical units of the application instance that were not migrated in the old park, implement same-city handover for multiple logical units; after completing the same-city handover of multiple logical units, update the routing rules of the service nodes of multiple logical units to the new routing rules.

[0136] Optionally, the unit migration device further includes: a resource recovery module 405, used for:

[0137] After an application instance within the logical unit to be migrated has been migrated, the device resources of that application instance in the old physical unit are reclaimed.

[0138] Optionally, the cell migration device further includes: a deletion strategy module 406, used for:

[0139] After all application instances within the logical unit to be migrated have been migrated, delete the policies corresponding to the old domain names in all load balancers of the new and old parks.

[0140] Figure 8 This is a schematic diagram of a request initiation device provided in an embodiment of this application. Figure 8As shown, the request initiation device provided in this embodiment includes: a fragment number determination module 501, a request conversion module 502, and a request initiation module 503.

[0141] The fragment number determination module 501 is used to determine the fragment number of the target fragment based on the routing field in the call request sent by the client.

[0142] The request conversion module 502 is used to add the fragment number of the target fragment to the Hypertext Transfer Protocol request when the call request is converted into a Hypertext Transfer Protocol request, and to determine the unit identifier of the physical unit corresponding to the logical unit to which the target fragment belongs based on the routing rules, and to construct the domain name of the Hypertext Transfer Protocol request based on the unit identifier of the physical unit; wherein, the first logical unit and / or the second logical unit to which the target fragment belongs are migrated based on the method provided above;

[0143] The request initiation module 503 is used to send a Hypertext Transfer Protocol request.

[0144] Figure 9 This is a schematic diagram of a request routing device provided in an embodiment of this application. Figure 9 As shown, the request routing device provided in this embodiment includes: a request parameter extraction module 601 and a request routing module 602.

[0145] The request parameter extraction module 601 is used to extract the unit identifier of the physical unit and the fragment number of the target fragment carried in the Hypertext Transfer Protocol request in response to the Hypertext Transfer Protocol request; the Hypertext Transfer Protocol request is initiated based on the above method;

[0146] The request routing module 602 is used to route a Hypertext Transfer Protocol request to a target node based on routing rules, the unit identifier of the physical unit, and the fragment number of the target fragment, so that the target node can respond to the Hypertext Transfer Protocol request.

[0147] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 10 As shown, the electronic device of this embodiment may include: at least one processor 701; and a memory 702 communicatively connected to at least one processor; wherein the memory 702 stores instructions that can be executed by at least one processor 701, and the instructions are executed by at least one processor 701 to cause the electronic device to perform the method as described in any of the above embodiments.

[0148] Optionally, the memory 702 can be either standalone or integrated with the processor 701. When the memory 702 is set up independently, the device also includes a bus for connecting the memory 702 and the processor 701.

[0149] The implementation principle and technical effects of the electronic device provided in this embodiment can be found in the foregoing embodiments, and will not be repeated here.

[0150] This application also provides a computer-readable storage medium storing computer-executable instructions. When the computer-executable instructions are executed by a processor, the methods provided in any of the foregoing embodiments can be implemented.

[0151] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in any of the foregoing embodiments.

[0152] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0153] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0154] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0155] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0156] Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as resistive random access memory (RRAM), dynamic random access memory (DRAM), static random access memory (SRAM), enhanced dynamic random access memory (EDRAM), high-bandwidth memory (HBM), hybrid memory cube (HMC), etc.

[0157] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0158] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0159] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0160] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A cell migration method, characterized in that, This is applied to application systems based on a unitized architecture, wherein the units in the application system are divided into logical units and physical units; the logical units include data shards and application nodes, and the physical units are bound to infrastructure, with each physical unit corresponding to a campus; each logical unit has a corresponding physical unit in at least one campus. The domain name for the application system's call request is generated based on the unit identifier of the physical unit where the service provider is located, and the method includes: A new routing rule is generated based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated was located in the old campus before migration and the corresponding physical unit was the old physical unit, and the new physical unit is located in the new campus; In the load balancer of the logical unit where the service provider of the old campus is located, add a load balancing policy corresponding to the new domain name, and configure the new domain name to point to the address of the load balancer of the old physical unit; the new domain name is generated based on the unit identifier of the new physical unit; The application instances within the logical unit to be migrated are migrated in batches. During the migration process, the new routing rules are configured on the service nodes of the new physical unit, and the new domain name and the old domain name are modified to point to the address of the load balancer of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit.

2. The method according to claim 1, characterized in that, The phased migration of application instances within the logical unit to be migrated, during the migration process, includes configuring the new routing rules on the service nodes of the new physical unit, including: When migrating application instances within the logical unit to be migrated in batches, a unitized environment for the application instances within the logical unit to be migrated is built in the new physical unit. Import the load balancing policies corresponding to the new domain name and the old domain name into the load balancer of the new physical unit, and configure the new routing rules on the service nodes of the new physical unit; The data of the application instance is switched from the database of the old physical unit to the database of the new physical unit; Modify the new and old domain names to point to the load balancer address of the new physical unit.

3. The method according to claim 2, characterized in that, The method further includes: After completing the migration of an application instance, for the multiple logical units of the application instance that have not been migrated in the old park, the multiple logical units are switched over within the same city. After completing the same-city handover of the multiple logical units, the routing rules of the service nodes of the multiple logical units are updated to the new routing rules.

4. The method according to claim 3, characterized in that, The method further includes: After an application instance within the logical unit to be migrated has been migrated, the device resources of that application instance in the old physical unit are reclaimed.

5. The method according to claim 4, characterized in that, The method further includes: After all application instances within the specified migration logical unit have been migrated, delete the policies corresponding to the old domain names from all load balancers in both the new and old parks.

6. The method according to any one of claims 1-5, characterized in that, The method for initiating the call request also includes: The fragment number of the target fragment is determined based on the routing field in the call request sent by the client; When the call request is converted into a Hypertext Transfer Protocol request, the fragment number of the target fragment is added to the Hypertext Transfer Protocol request, and based on the routing rules, the unit identifier of the physical unit corresponding to the logical unit to which the target fragment belongs is determined, and the domain name of the Hypertext Transfer Protocol request is constructed based on the unit identifier of the physical unit. Send the Hypertext Transfer Protocol request.

7. The method according to claim 6, characterized in that, The routing method for the invocation request also includes: In response to a Hypertext Transfer Protocol request, extract the unit identifier of the physical unit and the fragment number of the target fragment carried in the Hypertext Transfer Protocol request; Based on routing rules, as well as the unit identifier of the physical unit and the fragment number of the target fragment, the Hypertext Transfer Protocol request is routed to the target node so that the target node can respond to the Hypertext Transfer Protocol request.

8. A unit migration device, characterized in that, This is applied to application systems based on a unitized architecture, wherein the units in the application system are divided into logical units and physical units; the logical units include data shards and application nodes, and the physical units are bound to infrastructure, with each physical unit corresponding to a campus; each logical unit has a corresponding physical unit in at least one campus. The domain name for the application system's call request is generated based on the unit identifier of the physical unit where the service provider is located. The device includes: The new routing rule generation module is used to generate new routing rules based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated was located in the old campus before migration and the corresponding physical unit was the old physical unit, and the new physical unit is located in the new campus; The migration preparation module is used to add a load balancing policy corresponding to the new domain name to the load balancer of the logical unit where the old campus service provider is located, and configure the new domain name to point to the address of the load balancer of the old physical unit; the new domain name is generated based on the unit identifier of the new physical unit. The batch migration module is used to migrate application instances within the logical unit to be migrated in batches. During the migration process, the new routing rules are configured on the service node of the new physical unit, and the new domain name and the old domain name are modified to point to the address of the load balancer of the new physical unit. The old domain name is generated based on the unit identifier of the old physical unit.

9. An electronic device, characterized in that, include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executed instructions; The processor executes computer execution instructions stored in the memory to implement the method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer-executable instructions, which, when executed by a processor, are used to implement the method as described in any one of claims 1-7.

11. A computer program product, characterized in that, Includes a computer program that, when executed by a processor, implements the method of any one of claims 1-7.

Images