Unit migration, request initiation and request routing methods and devices, equipment and medium

Abstract

The embodiment of the invention provides a unit migration, request initiation and request routing method and device, equipment and a medium, and relates to the field of financial science and technology or other related fields. The units are divided into logical units and physical units based on a unitized architecture, each logical unit has a corresponding physical unit in at least one park, and the call request domain name is generated based on the unit identifier of the physical unit where the service provider is located. According to the unit migration method, a new routing rule is generated firstly, a new domain name strategy is added to an old park load balancer and points to an old physical unit address, then application examples are migrated in batches, the new routing rule is configured in a new physical unit during migration, and domain name pointing is adjusted; according to the request initiating method, a load balancer determines a target fragment number, constructs a domain name and then sends a hypertext transfer protocol request; the request routing method comprises the following steps: extracting request information, and routing the request information to a target node according to a routing rule; according to the method, batch migration of the application examples in the logic unit is realized, and the migration efficiency is improved.

Description

Technical Field

[0001] The present 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 Art

[0002] With the continuous expansion of financial services and the acceleration of digital transformation, financial institutions are placing increasing demands on system high availability, data security, and business continuity. To address these challenges, modular architecture is becoming the mainstream choice. By partitioning business data and applications into multiple independent units, this architecture achieves data isolation, risk dispersion, and system elastic scalability, thereby improving overall processing capabilities and stability.

[0003] In the prior art, a data migration method based on a unitized architecture specifically discloses: when an application is migrated, all its upstream consumer applications must synchronously modify their configurations and complete the switching of service calls 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, since all upstream consumer applications are required to modify their configurations and complete the switch 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 are migrated simultaneously, the difficulty and workload of coordinating a large number of upstream applications increase significantly, and management costs rise sharply. In the scenario of batch 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 the operation, extending the implementation cycle, and resulting in low migration efficiency. Summary of the Invention

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

[0006] In a first aspect, the present application provides a unit migration method, which is applied to an application system based on a unitized architecture, 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 the infrastructure, and each physical unit corresponds to a park; each logical unit corresponds to a physical unit in at least one park; 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, and the method includes:

[0007] Generate a new routing rule based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated is located in the old park before migration and the corresponding physical unit is the old physical unit, and the new physical unit is located in the new park;

[0008] In the load balancer of the logical unit where the old campus service provider 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] For the batch migration of application instances within the logical unit to be migrated, during the migration process, the new routing rules are configured at 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, and the old domain name is generated based on the unit identifier of the old physical unit.

[0010] In a second aspect, the present application provides a request initiation method, which is applied to an application system based on a modular architecture, and the method includes:

[0011] Determine the shard number of the target shard based on the routing field in the call request sent by the client;

[0012] When the call request is converted into a hypertext transfer protocol request, the shard number of the target shard is added to the hypertext transfer protocol request, and based on the routing rule, the unit identifier of the physical unit corresponding to the logical unit to which the target shard belongs is determined, and the domain name of the hypertext transfer protocol request is constructed based on the unit identifier of the physical unit; wherein the application system based on the unitized architecture is migrated based on the method provided by the second aspect;

[0013] The hypertext transfer protocol request is sent.

[0014] In a third aspect, the present application provides a request routing method, which is applied to an application system based on a modular architecture, and the method includes:

[0015] In response to a hypertext transfer protocol request, extracting a unit identifier of a physical unit and a fragment number of a target fragment carried in the hypertext transfer protocol request; the hypertext transfer protocol request is initiated based on the method provided in the third aspect;

[0016] Based on a routing rule, the unit identifier of the physical unit and the slice number of the target slice, the hypertext transfer protocol request is routed to a target node, so that the hypertext transfer protocol request is responded to through the target node.

[0017] In a fourth aspect, the present application provides a unit migration device, characterized in that it is applied to an application system based on a unitized architecture, and the device includes:

[0018] A new routing rule generation module is configured to generate a new routing rule based on a unit identifier of a new physical unit corresponding to a to-be-migrated logical unit; the to-be-migrated logical unit is located in an old park before migration and the corresponding physical unit is an old physical unit, and the new physical unit is located in a new park;

[0019] A migration preparation module is configured to add a load balancing policy corresponding to the new domain name in 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] A batch migration module is used to migrate application instances in the logical unit to be migrated in batches. During the migration process, the new routing rules are configured at 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] In a fifth aspect, the present application provides a request initiating device, which is applied to an application system based on a unitized architecture, and the device includes:

[0022] A shard number determination module is used to determine the shard number of the target shard based on the routing field in the call request sent by the client;

[0023] A request conversion module, configured to, when converting a call request into a hypertext transfer protocol request, add the shard number of the target shard to the hypertext transfer protocol request, determine the unit identifier of the physical unit corresponding to the logical unit to which the target shard belongs based on a routing rule, and construct a domain name of the hypertext transfer protocol request based on the unit identifier of the physical unit; wherein the application system based on the unitized architecture is migrated based on the method provided in the first aspect;

[0024] The request initiating module is used to send the hypertext transfer protocol request.

[0025] In a sixth aspect, the present application provides a request routing device, characterized in that it is applied to an application system based on a modular architecture, and the device includes:

[0026] a request parameter extraction module, configured to extract, in response to a hypertext transfer protocol request, a unit identifier of a physical unit and a fragment number of a target fragment carried in the hypertext transfer protocol request; the hypertext transfer protocol request being initiated based on the method provided in the second aspect;

[0027] A request routing module is used to route the hypertext transfer protocol request to a target node based on a routing rule, a unit identifier of the physical unit, and a slice number of a target slice, so as to respond to the hypertext transfer protocol request through the target node.

[0028] In the seventh aspect, the present application provides an electronic device comprising: 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] In an eighth aspect, the present application provides a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided in the first, second and third aspects above.

[0030] In a ninth aspect, the present application provides a computer program product, comprising a computer program, which, when executed by a processor, implements the methods provided in the first, second and third aspects above.

[0031] The unit migration, request initiation and request routing methods provided in this application are based on a unitized architecture application system that divides units 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 application system calls the request domain name based on the unit identifier of the physical unit where the service provider is located; the unit migration method is applied to the system, first generating a new routing rule based on the unit identifier of the new physical unit of the logical unit to be migrated, adding a load balancing policy corresponding to the new domain name to the load balancer of the logical unit where the service provider is located in the old park and making the new domain name point to the load balancer address of the old physical unit, and then migrating the application instances in the migrated logical unit in batches. During the migration process, new routing rules are configured at the new physical unit service node. Then the new and old domain names are pointed to the new physical unit load balancer address; the request initiation method is applied to the load balancer in the first logical unit, and the shard number of the target shard is determined based on the routing field in the call request. When the call request is converted into a hypertext transfer protocol request, the shard number is added and the physical unit unit identifier corresponding to the logical unit to which the target shard belongs is determined based on the routing rule to construct the domain name and then send the hypertext transfer protocol request; the request routing method is applied to the load balancer in the second logical unit, and responds to the hypertext transfer protocol request initiated based on the request initiation method, extracts the physical unit unit identifier and the target shard shard number, and routes the request to the target node based on the routing rule to respond to the request; this solution improves the call success rate in the unit migration scenario and effectively guarantees the reliability and stability of the service during the migration process. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0033] Figure 1 An application system diagram based on a unitized architecture provided in an embodiment of the present application;

[0034] Figure 2 A schematic diagram of a flow chart of a unit migration method provided in an embodiment of the present application;

[0035] Figure 3 A schematic diagram of unit migration provided in an embodiment of the present application;

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

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

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

[0039] Figure 7 A schematic structural diagram of a unit migration device provided in an embodiment of the present application;

[0040] Figure 8 A schematic diagram of the structure of a request initiating device provided in an embodiment of the present application;

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

[0042] Figure 10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0043] The above drawings illustrate specific embodiments of the present application, which will be described in more detail below. These drawings and the textual description are not intended to limit the scope of the present application in any way, but rather to illustrate the concepts of the present application to those skilled in the art by reference to specific embodiments. DETAILED DESCRIPTION

[0044] Exemplary embodiments will be described in detail herein, with examples illustrated in the accompanying drawings. In the following description, when referring to the drawings, identical numerals in different figures represent identical or similar elements, unless otherwise indicated. The embodiments described in the following exemplary embodiments are not intended to represent all embodiments consistent with the present application. Rather, they are merely examples of apparatus and methods consistent with certain aspects of the present 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, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, storage, use, processing, transmission, provision, disclosure and application of the relevant data comply with the relevant laws, regulations and standards of the relevant countries and regions, take necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0046] In addition, this application involves conducting 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 using artificial intelligence technology to make automated decisions, and making technical solutions that have a significant impact on personal rights and interests based on the results of automated decisions. The application provides users with corresponding operation entrances for them to choose to agree or reject the results of automated decisions; if the user chooses to reject, the expert decision-making process will be entered.

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

[0048] As financial services continue to expand and digital transformation accelerates, the financial sector's demands for high system availability, data security, and business continuity are significantly increasing. To address these challenges, modular architectures are becoming a mainstream technology solution, thanks to their ability to partition business data and applications into multiple independent units, achieving data isolation, risk dispersion, and elastic scalability. These advantages effectively enhance the system's overall processing capabilities and stability.

[0049] In the prior art, a data migration method based on a unitized architecture specifically discloses the following method: when an application needs to be migrated, all its upstream consumer applications must synchronously complete configuration modifications and switching of service call addresses at the same time point; if there are multiple applications that need to be migrated at the same time, the upstream consumers corresponding to each migrated application must participate in the coordination; and when faced with large-scale migration tasks, due to resource or operation limitations, the migration tasks usually need to be divided into multiple batches and implemented step by step.

[0050] However, existing technologies require all upstream consumer applications to synchronously modify their configurations and complete the switch during migration, resulting in a strong coupling relationship between upstream and downstream systems, making the migration operation complex and error-prone. 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 repeatedly participate in the change process, resulting in more cumbersome operations, extended implementation cycles, and low overall migration efficiency.

[0051] The unit migration, request initiation and request routing methods provided in this application are intended to solve the above technical problems of the prior art. Specifically, the application system unit is subdivided into logical units (including data shards and application nodes) and physical units (bound to the infrastructure and each corresponding to a park). Each logical unit has a corresponding physical unit in at least one park, and the call request domain name is generated based on the unit identifier of the physical unit where the service provider is located; on this basis, 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 and constructs the domain name before sending a Hypertext Transfer Protocol request; and a request routing method is proposed, in which the load balancer in another logical unit extracts the physical unit identifier and the target shard number in the Hypertext Transfer Protocol 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 following specific embodiments describe in detail the technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0053] Figure 1 This is a diagram of an application system based on a unitized architecture provided by an embodiment of the present application. This application provides an application system based on a unitized architecture, where the units in the application system are divided into logical units and physical units.

[0054] Logical units include data shards and application nodes. Physical units are bound to infrastructure, and 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 unit division and layout concept. It is a division at an abstract level, mainly to maintain consistency and coherence in system architecture design and operation and maintenance management.

[0057] Physical units are tied to infrastructure, specifically computer rooms and resource domains. Each physical unit corresponds 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. These units have a many-to-many relationship, connected by a "1:N" mapping. For example, a logical unit may correspond to physical units in multiple campuses, enabling distributed data storage and multi-location application deployment. A single physical unit may also carry services from multiple logical units.

[0059] When migrating units from the new data center campus to the old campus, the logical unit number remains unchanged, ensuring stability in business logic and operations management. However, the physical unit number differs between the two locations due to physical location. Because physical units are closely associated with specific campuses and infrastructure, changes in physical location inevitably lead to changes in their identification.

[0060] The domain name of the application system's call request is generated based on the unit identifier of the service provider's physical unit. This means that the domain name can clearly identify the service provider's physical location (campus), facilitating accurate service invocation and resource location. For example, if the service provider is located in a physical unit within a specific campus, its domain name will include the unit's identifier, allowing the caller to directly locate the corresponding service provider based on the domain name.

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

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

[0063] When migrating a unit in a modular application system, updating routing rules is crucial for ensuring proper system operation and accurate data flow. When migrating a logical unit from an old campus to a new one, the first step is to identify the new physical unit that corresponds to the logical unit. Each physical unit has a unique unit identifier, which is crucial for identifying and locating the physical unit. Based on the unit identifier of the new physical unit corresponding to the logical unit being migrated, the system generates new routing rules.

[0064] Before migration, the logical unit to be migrated was located in the old campus and had a corresponding physical unit in the old campus, the old physical unit. The old physical unit carried out business operations and data storage for the logical unit in the old campus. The new physical unit, located in the new campus, is the target physical environment in which the logical unit to be migrated will be deployed and operated after migration.

[0065] New routing rules are 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 is migrated to the new campus. For example, in a distributed system, when a client initiates a request, the system will use the new routing rule to direct the request to the corresponding new physical unit in the new campus, rather than to the old physical unit in the old campus as it did before the migration.

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

[0067] When performing campus migration operations on a unitized architecture application system, in order to ensure a smooth transition and continuous availability of services during the migration process, it is necessary to configure and adjust the load balancer of the logical unit where the old campus service provider is located.

[0068] First, a new domain name is 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 based on this.

[0069] Next, within the logical unit (LU) where the old campus service provider resides, the load balancer is responsible for properly distributing incoming requests to the various service nodes to maintain efficient and stable system operation. To enable the system to handle requests for the new domain name associated with the new physical unit, a load balancing policy corresponding to the new domain name needs to be added to the load balancer.

[0070] Finally, configure the new domain name to point to the address of the load balancer of the old physical unit. During the transition phase of the migration, even though the new domain name corresponds to the new physical unit, requests will first reach the load balancer of the old campus. The load balancer of the old campus will forward the requests to the old physical unit for processing according to the preset policy, ensuring that services are not interrupted during the migration process and that services can continue to be provided 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 migration of services.

[0071] For example, consider a financial application system using a modular architecture, deployed across both the old and new campuses. The old campus has four logical units, numbered RZ01, RZ02, RZ03, and RZ04. Each logical unit has a corresponding load balancer, which evenly distributes requests to the service providers within that unit. Now, plans are underway to migrate some services to the new campus, which also has corresponding physical units. To ensure a smooth transition, the load balancing policy corresponding to the new domain name needs to be added to the load balancer in the old campus.

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

[0073] S103: For the batch migration of application instances within the migration logical unit, during the migration process, new routing rules are configured at 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.

[0074] During the migration process, new routing rules must 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 the application instances of 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 incoming requests according to the established policy, ensuring accurate execution of business logic.

[0075] At the same time, the new and old domain names also need to be modified. The new domain name is generated based on the unit identifier of the new physical unit and represents 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 through 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. Regardless of whether the request is initiated through the new or old domain name, it will be directed to the load balancer of the new physical unit, and the load balancer will then distribute the request to the corresponding application instance according to the new routing rules, thereby achieving a smooth transition and continuous availability of the service.

[0076] Optionally, for batch migration of application instances within a migration logical unit, new routing rules are configured at the service nodes of the new physical unit during the migration process. The specific implementation method includes:

[0077] When migrating application instances in a logical unit in batches, a unitized environment for the application instances in the logical unit to be migrated is built in the new physical unit; the load balancing policies 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 in the service nodes of the new physical unit; the data of the application instances is switched from the database of the old physical unit to the database of the new physical unit; 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 the logical unit to be migrated in batches, the first step is to build a modular environment for the application instances in the new physical unit. This is because the new physical unit, as the operating location for the migrated application instances, must have basic operating conditions that match those of the old physical unit and meet the requirements of the new environment. Building a modular 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, 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. The new domain name is generated based on the unit identifier of the new physical unit and represents 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 has been used to access the application instances in the old physical unit before migration. The purpose of importing the load balancing policy is to enable the load balancer to reasonably distribute requests to the various service nodes in the new physical unit according to preset rules, such as the load status and response time of the 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. They determine the routing path of the request within the new physical unit, ensuring that the request can accurately reach the corresponding application instance.

[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 a key element in the normal operation of the application instance, so data switching requires careful attention. This typically involves steps such as data backup, data transfer, and data recovery. Ensure that data is not lost or corrupted during the switchover process, and that data consistency is maintained. Only after the data switchover is complete can the application instance process its business logic normally in the new physical unit.

[0081] Finally, modify the new and old domain names to point to the addresses of the load balancer of the new physical unit. After this modification, all requests initiated through both the new and old domain names will be directed to the load balancer of the new physical unit. The load balancer will then distribute the requests to the corresponding application instances based on the new routing rules, thus completing the migration of the application instances from the old physical unit to the new one and ensuring the continued stable operation of the system during the migration.

[0082] For example, Figure 3 As shown, the logical unit to be migrated contains applications A and B. The old physical units include Campus A and Campus B, and the new physical units include Campus E and Campus F. The old unit routing rules contain information such as RZ01: Campus A unit number and RZ02: Campus A unit number. These rules are referenced by the non-migrated applications.

[0083] Taking Application A and Application B as an example, in the new physical units (Campus E and Campus F), build an environment suitable for Application A and Application B according to the requirements of the modular architecture. Ensure that Application A and Application B can be deployed and run normally in the new physical units. Prepare the corresponding server resources for Application A and Application B under the SLB (Load Balancer) in Campus F.

[0084] The new routing rules are referenced by the migrated applications and include information such as the RZ02:E campus unit number and the RZ04:F campus unit number. These new routing rules are configured on the service nodes in the new physical unit so that the service nodes can correctly identify and process requests based on these rules and route them to the appropriate application instances. When a request contains a specific identifier, the service node forwards 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 in the database of the old physical unit (such as Park A and Park B) to the database of the new physical unit (such as Park F).

[0086] The unit migration method provided in the present application generates a new routing rule based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; before the migration, the logical unit to be migrated is located in the old park and the corresponding physical unit is the old physical unit, and the new physical unit is located in the new park. In the load balancer of the logical unit where the service provider of the old park is located, a load balancing policy corresponding to the new domain name is added, 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, and for the batch migration of application instances in the logical unit to be migrated, during the migration process, new routing rules are configured at 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, and the old domain name is generated based on the unit identifier of the old physical unit; the method realizes the batch migration of application instances in the logical unit by generating new routing rules and configuring the new domain name to point to the new physical unit, thereby reducing the coupling degree of upstream and downstream systems while improving the migration efficiency.

[0087] In some embodiments, the method for updating new routing rules includes: after completing the migration of an application instance, implementing intra-city switching of multiple logical units for multiple logical units of the application instance that have not been migrated in the old park; 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 completing the migration of an application instance, it is necessary to implement a local switchover for the multiple logical units in the old campus where the unmigrated application instances are located. The purpose of local switchover is to adjust the system's resource allocation and operating strategies to accommodate the situation where some application instances have been migrated to the new campus. During the local switchover process, the system will adjust the configuration and connection methods of these unmigrated logical units in the old campus to ensure that they can work together with the migrated parts of 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 switchover 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 accurately guide the routing path of requests in the new environment. Updating the routing rules of the service nodes to the new routing rules indicates that the system will intelligently route requests based on the new architecture and environment when processing them. This way, requests from both the new and old campuses are correctly directed to the corresponding service nodes according to the new routing rules, ensuring accurate execution of business logic and efficient system operation.

[0090] For example, assume that Application A has been migrated from RZ04 (Campus B) to a new campus (e.g., Campus F). During the migration, you've already set up Application A's operating environment in the new campus, configured the load balancing policy and routing rules, migrated the data to the new campus database, and pointed the relevant domain names to the new campus's load balancer address.

[0091] In the old park, application A still has units such as RZ01 (Park A), RZ02 (Park A), and RZ03 (Park B) that have not been migrated; application B still has units such as RZ01 (Park A) and RZ03 (Park B) that have not been migrated.

[0092] The purpose of switching within the same city is to enable the unmigrated application instances in the old campus to better balance the load and provide services within the same city, while also preparing for the subsequent full migration. For the RZ01-A unit of application A, its load balancing strategy may have originally been only for the interior of campus A. Now it needs to be adjusted so that it can work with other campuses in the same city (such as the unmigrated part of campus B and the new campus). Specifically, the load balancing strategy is adjusted so that when consumers (regardless of whether they have migrated or not) access application A, they can distribute requests based on the load conditions of each unit within the same city. For example, when the load on the RZ01-A unit in campus A is high, some requests can be distributed to the unmigrated RZ03-B unit in campus B (if the unit has sufficient resources) to achieve load balancing within the same city.

[0093] After confirming that the same-city switching is running stably and the coordination between the various logical units is normal, start updating the routing rules of the service node.

[0094] Specific operations for updating routing rules: Taking the RZ01-A unit of application A as an example, its original routing rules may only contain the unit number and routing logic within the old campus (such as RZ01:A campus unit number in the old unit routing rules, etc.). Now it is updated to a new routing rule, and the new routing rule contains information such as the new campus unit number (such as RZ04:F campus unit number in the new unit routing rules, etc.). In this way, when the service node receives a request, it will make a routing decision based on the new routing rules, and may route the request to the application instance of the new campus, rather than being limited to the old campus. Similarly, for other non-migrated logical units such as the RZ01-A unit of application B, similar routing rule update operations are also performed to enable them to interact and collaborate with the application instances of the new campus according to the new rules.

[0095] In some embodiments, after an application instance in a to-be-migrated logical unit is migrated, the device resources of the application instance in the old physical unit are reclaimed.

[0096] When an application instance runs on the old physical unit, it consumes various device resources, such as server computing resources (CPU, memory), storage resources (hard disk space), and network resources. After the application instance is migrated to the new physical unit, these resources become idle in the old physical unit. Failure to reclaim these resources promptly wastes resources and can lead to resource constraints in the old physical unit, impacting the performance and stability of other application instances still running on the old physical unit.

[0097] First, thoroughly analyze and identify the resources occupied by the application instance in the old physical unit, specifically identifying the servers, storage devices, and network ports involved. Next, gradually release these resources according to the established resource recovery process. For example, for server computing resources, stop the relevant processes and services and return the CPU and memory resources allocated to the application instance to the resource pool. For storage resources, delete the application instance's data files to free up hard disk space. For network resources, unbind the network ports occupied by the application instance.

[0098] Through orderly and thorough resource recovery operations, the resources of the old physical unit can be reasonably released and reallocated, improving resource utilization. At the same time, it also creates good conditions for subsequent system maintenance and management, ensuring that the resource management and utilization of the entire unitized architecture system during the migration process are more efficient and reasonable.

[0099] For example, assume that there are two existing campuses (such as Campus A and Campus B) and a new campus (such as Campus F). A modular architecture is used to deploy applications, with multiple applications, such as Application A and Application B, distributed across different logical units (such as RZ01 and RZ02). Now, you want to migrate the instance of Application A in unit RZ04 in the old campus, Campus B, to the new campus, Campus F. Once the instance of Application A in unit RZ04 in Campus B has been successfully deployed and is running in the new campus, Campus F, the device resources in unit RZ04 in Campus B can be reclaimed.

[0100] In some embodiments, after all application instances in the logical unit to be migrated are migrated, the policies corresponding to the old domain names in all load balancers in the new campus and the old campus 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 name have been completely transferred to the new physical unit in the new campus. The old domain name was originally generated based on the unit identifier of the old physical unit. During the migration process, it served as a transition to ensure continuous service availability during the migration. However, with the completion of the migration of all application instances, the related policies of the old domain name in the load balancer are no longer necessary and may even cause potential problems, so they need to be cleaned up.

[0102] During the migration process, to ensure a smooth transition of services, policies corresponding to the old domain names were retained in the load balancers of both the new and old campuses. These policies were originally intended to route and process requests initiated through the old domain names according to certain rules during the migration period, initially directing them to the old physical unit (in the early stages of the migration) and then gradually to the new physical unit. However, if these policies were retained after all application instances were migrated, this could lead to confusion in the routing of requests. For example, some requests might still be incorrectly routed according to the old policies to the old physical unit, which no longer carries the relevant business logic, or the load balancer's routing decision-making process might become complex and inefficient, increasing the difficulty of system management and potential risks.

[0103] Delete the policies corresponding to the old domain name from all load balancers in both the new and old campuses. After deleting these policies, the load balancers will no longer perform special processing on requests originating from the old domain name. Instead, they will route requests based entirely on the new domain name and routing rules. This not only simplifies the load balancer's routing decision-making process, improving overall system performance and stability, but also avoids potential errors and security risks caused by the presence of the old policies, ensuring a cleaner and more efficient system after the migration is complete.

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

[0105] Figure 4A flowchart of a request initiation method provided in an embodiment of the present application. The method provided in the present application can be executed by an application system based on a unitized architecture. The logical unit in the application system based on the unitized architecture includes a first logical unit. Specifically, it can be executed by a load balancer in the first logical unit, or by a device that is connected to the load balancer in 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 shard number of the target shard based on the routing field in the call request sent by the client.

[0107] Specifically, the shard number of the target shard is determined based on the routing field in the call request sent by the client. In a distributed system, data is usually stored in multiple shards, and each shard is responsible for processing a portion of the data. The routing field contains key information related to the request, such as the user's ID, business type, etc. The load balancer can obtain the shard number of the target shard by parsing this routing field. For example, if the routing field is a user ID, the load balancer may perform a modulo operation based on the hash value of the user ID and the total number of shards, and the result is the shard number of the target shard. This process ensures that the request can be accurately routed to the shard storing the relevant data, avoiding blind data searches and unnecessary network transmissions.

[0108] Once the load balancer determines the shard number, it can find the service node where the corresponding shard resides based on the system configuration and forward the call request to that service node. Upon receiving the request, the service node processes it based on the specific business logic in the request and returns the corresponding result. Furthermore, this method of determining shard numbers based on routing fields offers flexibility and scalability. When the system needs to add or remove shards, simply adjusting the corresponding algorithms or rules will adapt to the new system architecture and ensure accurate request routing.

[0109] S202: When the call request is converted into a Hypertext Transfer Protocol request, the shard number of the target shard 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 shard belongs is determined, and the domain name of the Hypertext Transfer Protocol request is constructed based on the unit identifier of the physical unit; wherein, the application system based on the unitized architecture is migrated based on the method provided above.

[0110] The routing rules can be either old or new. Different rules are stored in different migration stages. After the migration is completed, the new rules are used, while before the migration is completed, the old rules are used.

[0111] In the interaction of systems with distributed or modular architectures, call requests need to be converted into HyperText Transfer Protocol (HTTP) requests for transmission and processing on the network. When a call request enters this conversion process, the system will add the shard number of the previously determined target shard to the HTTP request. The shard number of the target shard carries the specific location information of the data that the request needs to access. In a distributed data storage scenario, data is stored in multiple shards. By adding the shard number to the HTTP request, subsequent routing and data processing links can clearly know which data shard the request should be directed to, ensuring that the request can accurately reach the node storing the relevant data, thereby improving the efficiency and accuracy of data processing.

[0112] After adding the shard number, the system further determines the unit ID of the physical unit corresponding to the logical unit to which the target shard belongs, based on pre-set routing rules. These rules enable the system to intelligently map shards within the logical unit to specific physical units. For example, data for certain business types may be prioritized for physical units with specific performance, or the distribution of shards may be dynamically adjusted based on the current load of the physical unit. Once the unit ID of the physical unit is determined, the system clearly identifies the actual physical location to which the request will ultimately reach, providing a key basis for subsequently constructing the domain name for the Hypertext Transfer Protocol request.

[0113] Based on the determined physical unit's unit identifier, the system constructs a domain name for HTTP requests. Domain names serve as identification and location services in network communications. By incorporating the physical unit's unit identifier into domain name construction rules, the system generates a unique and accurate domain name, allowing HTTP requests to be 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 are still accurately routed to the correct physical unit after the logical unit migration, ensuring stable system operation and business continuity.

[0114] S203: Send a Hypertext Transfer Protocol request.

[0115] After adding the target shard number to the HTTP request, determining the physical unit identifier, and constructing the HTTP request domain name, the system sends the constructed HTTP request through the underlying network protocol stack. During the transmission process, the HTTP request is encapsulated into a network data packet and forwarded by multiple network devices (such as routers and switches) before finally reaching the server of the target physical unit.

[0116] After a Hypertext Transfer Protocol request is sent, the system does not immediately terminate the processing flow. Instead, it waits for the target server to return a response. During this waiting period, the system continuously monitors the network connection status to ensure that the request can be transmitted normally. Once the response is received from the target server, the system parses and processes it. The response may include the request processing result, status code, error message, and other information. Based on this information, the system determines whether the request was successfully executed and performs subsequent actions based on business needs. For example, if the request is successful, the system may return the processing result to the client; if the request fails, the system may record an error log and provide an error message. 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 A flowchart of a request routing method provided by an embodiment of the present application. The method provided by the present application can be executed by an application system based on a unitized architecture, wherein the logic unit in the application system based on the unitized architecture includes a second logic unit. Specifically, the method can be executed by a load balancer in the second logic unit, or by a device connected to the load balancer in the second logic 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 request, extract the unit identifier of the physical unit and the slice number of the target slice carried in the hypertext transfer protocol request; the hypertext transfer protocol request is initiated based on the method provided above.

[0119] When the load balancer within the second logical unit receives a HTTP request, it responds and initiates the information extraction process. This response necessarily carries two key pieces of information: the physical unit's unit identifier and the target shard's shard number. The physical unit's unit identifier uniquely identifies the physical server or server cluster targeted by the request, while the target shard's shard number specifies the specific location of the data in the distributed storage that the request is accessing.

[0120] After successfully extracting the unit identifier of the physical unit and the shard number of the target shard, we can determine which physical unit the request should be routed to based on the unit identifier, and then further locate the specific service node in the physical unit responsible for processing the relevant data based on the shard number.

[0121] S302: Based on the routing rule, the unit identifier of the physical unit and the slice number of the target slice, the hypertext transfer protocol request is routed to the target node, so that the hypertext transfer protocol request is responded to through the target node.

[0122] Routing rules work closely with the unit identifier of the physical unit and the shard number of the target shard. Routing rules may include a variety of routing strategies, such as a load balancing strategy based on unit identifiers, which distributes requests to less loaded units based on the current load of each physical unit to improve overall system performance and responsiveness. Alternatively, a hash routing strategy based on shard numbers uses a hashing algorithm to map shard numbers to specific service nodes, ensuring that data requests for the same shard are routed to the same node. When the load balancer makes decisions based on routing rules, it uses the unit identifier and shard number to quickly and accurately determine the target node. For example, if the routing rule prioritizes routing requests for a certain business type to a specific physical unit and uses the shard number to identify the specific service node within that unit, the load balancer can quickly locate the target node and accurately route HTTP requests to it.

[0123] Once a Hypertext Transfer Protocol request is routed to a target node, it begins processing the request and responding. The target node can be a server running specific business logic. Upon receiving the request, it retrieves the required data from local storage or related data sources based on the request information and processes it according to business rules. For example, if the request is for information about a specific user, the target node will retrieve the user's relevant data 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, Figure 6-1 As shown, application A (not migrated) initiates an HTTP request using the old domain name of application B according to the old routing rules. The load balancer receives the request within the first logical unit and determines the shard number of the target shard based on the routing field. The load balancer adds the shard number to the HTTP request and, based on the old routing rules, determines the physical unit (new campus R2 / R4 node) to which the target shard belongs. 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 target shard number carried in the request. Based on the new routing rules, the request is routed to application B's new campus R2 / R4 node.

[0125] like Figure 6-2As shown, application B (migrated) initiates an HTTP request using the new domain name of application A according to the new routing rules. The load balancer receives the request within the first logical unit and determines the shard number of the target shard based on the routing field. The load balancer adds the shard number to the HTTP request and, based on the new routing rules, determines the physical unit (R2 / R4 node in the old campus) to which the target shard belongs. 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. Based on the old routing rules, the request is routed to application A's R2 / R4 node in the old campus.

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

[0127] like Figure 6-4 As shown, application B (migrated) initiates an 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 shard number of the target shard based on the routing field. The load balancer adds the shard number to the HTTP request and, based on the new routing rules, determines the physical unit (new campus R2 / R4 node) to which the target shard belongs. 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 target shard number carried in the request. Based on the new routing rules, the request is routed to application D's new campus R2 / R4 node.

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

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

[0130] 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 handles the batch migration of application instances within the migration logical unit. During the migration process, new routing rules are configured at 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.

[0132] Optionally, the batch migration module 403 is specifically configured to:

[0133] When migrating application instances in a logical unit in batches, a unitized environment for the application instances in the logical unit to be migrated is built in the new physical unit; the load balancing policies 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 in the service nodes of the new physical unit; the data of the application instances is switched from the database of the old physical unit to the database of the new physical unit; 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 unit migration apparatus further includes: a routing rule updating module 404, configured to:

[0135] After completing the migration of an application instance, multiple logical units of the application instance that has not been migrated in the old park are switched within the same city; after completing the switching of multiple logical units within the same city, the routing rules of the service nodes of the multiple logical units are updated to the new routing rules.

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

[0137] After the migration of an application instance in the to-be-migrated logical unit is completed, the device resources of the application instance in the old physical unit are reclaimed.

[0138] Optionally, the unit migration apparatus further includes a deletion policy module 406 configured to:

[0139] After all application instances in the logical unit to be migrated are migrated, delete the policies corresponding to the old domain names in all load balancers in the new and old campuses.

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

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

[0142] The request conversion module 502 is configured to, when converting the call request into a HTTP request, add the shard number of the target shard to the HTTP request, determine the unit identifier of the physical unit corresponding to the logical unit to which the target shard belongs based on the routing rule, and construct a domain name of the HTTP 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 shard belongs is migrated based on the method provided above;

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

[0144] Figure 9 This is a schematic diagram of the structure of a request routing device provided in an embodiment of the present application. Figure 9 As shown, the request routing device provided by 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 configured to route the HTTP request to the target node based on the routing rule, the unit identifier of the physical unit, and the slice number of the target slice, so as to respond to the HTTP request through the target node.

[0147] Figure 10 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present 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 the at least one processor; wherein the memory 702 stores instructions that can be executed by the at least one processor 701, and the instructions are executed by the at least one processor 701 so that the electronic device executes a method as in any of the above embodiments.

[0148] Optionally, the memory 702 may be independent or integrated with the processor 701. When the memory 702 is independently provided, the device further 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 aforementioned embodiments and will not be described in detail here.

[0150] An embodiment of the present application further provides a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, the method provided in any of the aforementioned embodiments can be implemented.

[0151] An embodiment of the present application also provides a computer program product, including a computer program, which implements the method provided in any of the aforementioned embodiments when executed by a processor.

[0152] It should be noted that for the aforementioned method embodiments, for the sake of simplicity, they are all expressed as a series of action combinations, but those skilled in the art should be aware that this application is not limited by the order of the actions described, because according to this application, certain steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also be aware that the embodiments described in this specification are all optional embodiments, and the actions and modules involved are not necessarily required by this application.

[0153] It should be further noted that, although the various steps in the flowchart are shown in sequence as indicated by the arrows, these steps are not necessarily performed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps may be performed in other orders. Moreover, at least a portion of the steps in the flowchart may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but may be performed at different times. The execution order of these sub-steps or stages is not necessarily to be performed in sequence, but may be performed in turn or alternately with other steps or at least a portion 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 the present application may also be implemented in other ways. For example, the division of units / modules in the above-described embodiments is merely a logical functional division, and actual implementations may employ other division methods. For example, multiple units, modules, or components may be combined or integrated into another system, or some features may be omitted or not implemented.

[0155] In addition, unless otherwise specified, the functional units / modules in the various embodiments of the present application may be integrated into a single unit / module, each unit / module may exist physically separately, or two or more units / modules may be integrated together. The aforementioned integrated units / modules may be implemented in the form of hardware or software program modules.

[0156] Unless otherwise specified, the processor can be any appropriate hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC. Unless otherwise specified, the storage unit can be any appropriate magnetic storage medium 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 in the form of a software program module and sold or used as an independent product, it can be stored in a computer-readable memory. Based on this understanding, the technical solution of the present application, 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. The computer software product is stored in a memory and includes a number of instructions for enabling a computer device (which can be a personal computer, server, or network device, etc.) to execute all or part of the steps of the various embodiments of the present application. The aforementioned memory includes: U disk, read-only memory (ROM), random access memory (RAM), mobile hard disk, magnetic disk, or optical disk, etc., various media that can store program code.

[0158] In the above embodiments, the description of each embodiment has its own emphasis. For parts not described in detail in a particular embodiment, please refer to the relevant description of other embodiments. The technical features of the above embodiments can be combined in any way. To keep the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0159] Those skilled in the art will readily appreciate other embodiments of the present application after considering the specification and practicing the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of the present application that follow the general principles of the present application and include common knowledge or customary techniques in the art not disclosed herein. The description and examples are to be considered as exemplary only, and the true scope and spirit of the present application are indicated by the following claims.

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

Claims

1. A unit migration method, characterized in that: The method is applied to an application system based on a unitized architecture, 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 the infrastructure, and each physical unit corresponds to a park; each logical unit corresponds to a physical unit in at least one park; 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, and the method includes: Generate a new routing rule based on the unit identifier of the new physical unit corresponding to the logical unit to be migrated; the logical unit to be migrated is located in the old park before migration and the corresponding physical unit is the old physical unit, and the new physical unit is located in the new park; In the load balancer of the logical unit where the old campus service provider 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; For the batch migration of application instances within the logical unit to be migrated, during the migration process, the new routing rules are configured at 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, and 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 batch migration of the application instances in the to-be-migrated logical unit, during the migration process, configuring the new routing rule at the service node of the new physical unit, includes: When migrating the application instances in the to-be-migrated logical unit in batches, building a unitized environment of the application instances in the to-be-migrated logical unit in the new physical unit; Importing the load balancing policies corresponding to the new domain name and the old domain name respectively into the load balancer of the new physical unit, and configuring the new routing rule at the service node of the new physical unit; Switching the data of the application instance from the database of the old physical unit to the database of the new physical unit; 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.

3. The method according to claim 2, characterized in that The method further comprises: After completing the migration of an application instance, for multiple logical units of the application instance that have not been migrated in the old park, perform intra-city switching on the multiple logical units; After completing the intra-city switching 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 comprises: After the migration of an application instance in the to-be-migrated logical unit is completed, the device resources of the application instance in the old physical unit are recovered.

5. The method according to claim 4, characterized in that The method further comprises: After all application instances in the to-be-migrated logical unit have been migrated, the policies corresponding to the old domain name in all load balancers in the new park and the old park are deleted.

6. A request initiation method, characterized in that: Applied to an application system based on a modular architecture, the method includes: Determine the shard number of the target shard 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 shard number of the target shard is added to the hypertext transfer protocol request, and based on the routing rule, the unit identifier of the physical unit corresponding to the logical unit to which the target shard belongs is determined, and the domain name of the hypertext transfer protocol request is constructed based on the unit identifier of the physical unit; wherein the application system based on the unitized architecture is migrated based on the method provided in any one of claims 1 to 5; The hypertext transfer protocol request is sent.

7. A request routing method, characterized in that: Applied to an application system based on a modular architecture, the method includes: In response to a hypertext transfer protocol request, extracting the unit identifier of the physical unit and the fragment number of the target fragment carried in the hypertext transfer protocol request; the hypertext transfer protocol request is initiated based on the method provided in claim 6; Based on a routing rule, the unit identifier of the physical unit and the slice number of the target slice, the hypertext transfer protocol request is routed to a target node, so that the hypertext transfer protocol request is responded to through the target node.

8. A unit migration device, characterized in that: Applied to an application system based on a modular architecture, the device includes: A new routing rule generation module is configured to generate a new routing rule based on a unit identifier of a new physical unit corresponding to a to-be-migrated logical unit; the to-be-migrated logical unit is located in an old park before migration and the corresponding physical unit is an old physical unit, and the new physical unit is located in a new park; A migration preparation module is configured to add a load balancing policy corresponding to the new domain name in 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; A batch migration module is used to migrate application instances in the logical unit to be migrated in batches. During the migration process, the new routing rules are configured at 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. A request initiating device, characterized in that: Applied to an application system based on a modular architecture, the device includes: A shard number determination module is used to determine the shard number of the target shard based on the routing field in the call request sent by the client; A request conversion module, configured to add the shard number of the target shard to the HTTP request when converting the call request into a HTTP request, and determine, based on routing rules, the unit identifier of the physical unit corresponding to the logical unit to which the target shard belongs, and construct a domain name of the HTTP request based on the unit identifier of the physical unit; wherein the application system based on the unitized architecture is migrated based on the method provided in any one of claims 1 to 5; The request initiating module is used to send the hypertext transfer protocol request.

10. A request routing device, characterized in that: Applied to an application system based on a modular architecture, the device includes: a request parameter extraction module for extracting, in response to a hypertext transfer protocol request, a unit identifier of a physical unit and a fragment number of a target fragment carried in the hypertext transfer protocol request; the hypertext transfer protocol request is initiated based on the method provided in claim 6; A request routing module is used to route the hypertext transfer protocol request to a target node based on a routing rule, a unit identifier of the physical unit, and a slice number of a target slice, so as to respond to the hypertext transfer protocol request through the target node.

11. An electronic device, characterized in that: include: 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 method according to any one of claims 1 to 7.

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

13. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 7 when executed by a processor.

Images