Service system migration method, equipment, medium and product

Abstract

The invention discloses a service system migration method and device, a medium and a product, and the method comprises the steps: obtaining an original online assembly in a first system and a target online assembly in a second system when a system for providing a service needs to be migrated from the first system to the second system; migrating an upstream real-time service request responded by an original online component in the first system to a target online component in the second system for response through a multi-stage online migration processing mechanism; when the multi-stage online migration process is carried out to the target migration stage, the batch tasks are switched from the first system to the second system for task response through a batch task migration processing mechanism, and according to the technical scheme of the embodiment of the invention, non-stop operation of the service system in the migration process is realized; and non-perceptual migration of the user is ensured through a progressive switching mechanism, and the technical problems of data consistency and service continuity among heterogeneous systems are solved.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and in particular to a service system migration method, device, medium, and product. Background Technology

[0002] With the rapid development of information technology, enterprise system upgrades or migrations have become commonplace. Therefore, achieving a smooth migration between old and new systems has become crucial.

[0003] In existing technologies, traditional system migration techniques typically employ either full data migration or shutdown switching: the full data migration method first stops the source system service, then uses an ETL tool to completely export and convert the source system database before importing it into the target system, and finally switches the application to connect to the new system; the shutdown switching method requires pre-setting a maintenance window, completing data synchronization, configuring the target and deploying the application during the shutdown period, and restarting the service after all components have been verified.

[0004] In developing this invention, the inventors discovered that while traditional migration algorithms can guarantee data consistency to a certain extent, they require system downtime during migration, leading to a degraded user experience. While downtime switching can ensure data consistency, service interruptions still exist. Furthermore, due to differences in the technical architecture between the old and new systems, direct switching may result in system malfunctions or data loss, increasing migration risks. Summary of the Invention

[0005] This invention provides a service function migration method, device, medium, and product that enables seamless migration of old and new service functions without system downtime.

[0006] According to one aspect of the present invention, a service function migration method is provided, the method comprising:

[0007] When it is necessary to migrate the system providing services from the first system to the second system, obtain the original online components in the first system and the target online components in the second system;

[0008] The original online component includes a first original processing interface and a second original processing interface connected together, and the second online component includes a first target processing interface and a second target processing interface connected together.

[0009] Through a multi-stage online migration processing mechanism, upstream real-time service requests that are responded to by the original online component in the first system are migrated to the target online component in the second system for response.

[0010] When the multi-stage online migration process reaches the target migration stage, the batch task migration processing mechanism switches the batch tasks from the first system to the second system for task response.

[0011] According to another aspect of the present invention, a service function migration apparatus is provided, the apparatus comprising:

[0012] The component acquisition module is used to acquire the original online components in the first system and the target online components in the second system when it is necessary to migrate the system providing services from the first system to the second system; wherein, the original online components include an original first processing interface and an original second processing interface connected together, and the second online components include a target first processing interface and a target second processing interface connected together;

[0013] The online migration module is used to migrate upstream real-time service requests that are responded to by the original online component in the first system to the target online component in the second system through a multi-stage online migration processing mechanism.

[0014] The batch task migration module is used to switch batch tasks from the first system to the second system for task response when the multi-stage online migration process reaches the target migration stage.

[0015] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0016] At least one processor; and

[0017] A memory communicatively connected to the at least one processor; wherein,

[0018] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform a service function migration method according to any embodiment of the present invention.

[0019] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement a service function migration method according to any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer program product is also provided, including computer instructions that, when executed by a processor, implement the steps of the method as described in any embodiment of the present invention.

[0021] The technical solution of this invention, when a service system needs to be migrated from a first system to a second system, firstly obtains the original online components in the first system and the target online components in the second system. Subsequently, through a multi-stage online migration processing mechanism, upstream real-time service requests are transitioned from the original online components in the first system to the target online components in the second system for response, ensuring a smooth migration of business traffic. When the multi-stage online migration process reaches the target migration stage, a batch task migration processing mechanism switches batch tasks from the first system to the second system for task response. This novel service function migration method enables the business system to operate without downtime during the migration process, and ensures seamless migration for users through a gradual switching mechanism. At the same time, the adoption of a batch task and online business collaborative migration strategy effectively solves the technical challenges of data consistency and business continuity between heterogeneous systems, significantly reducing the risks and costs of system upgrades and transformations.

[0022] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0023] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0024] Figure 1 This is a flowchart of a service function migration method provided in Embodiment 1 of the present invention;

[0025] Figure 2 This is a flowchart of another service function migration method provided in Embodiment 2 of the present invention;

[0026] Figure 3 This is a schematic diagram of an upstream migration stage provided according to Embodiment 2 of the present invention;

[0027] Figure 4 This is a schematic diagram of a first processing interface migration stage provided in Embodiment 2 of the present invention;

[0028] Figure 5 This is a flowchart of another service function migration method provided in Embodiment 3 of the present invention;

[0029] Figure 6 This is a schematic diagram of a second processing interface migration during the first system effective period according to Embodiment 3 of the present invention;

[0030] Figure 7 This is a schematic diagram of a second interface migration to a first interface comparison period according to Embodiment 3 of the present invention;

[0031] Figure 8 This is a schematic diagram of a second interface migration and second interface comparison stage according to Embodiment 3 of the present invention;

[0032] Figure 9 This is a schematic diagram of a mutually exclusive batch migration stage provided in Embodiment 3 of the present invention;

[0033] Figure 10 This is a real-time synchronization data flow diagram provided according to Embodiment 3 of the present invention;

[0034] Figure 11 This is a schematic diagram of a service function migration device according to Embodiment 4 of the present invention;

[0035] Figure 12 This is a schematic diagram of the structure of an electronic device that implements a service function migration method according to an embodiment of the present invention. Detailed Implementation

[0036] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0037] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0038] Example 1

[0039] Figure 1This is a flowchart of a service function migration method provided in Embodiment 1 of the present invention. This embodiment is applicable to scenarios where smooth migration between heterogeneous systems is required and zero service interruption is required. The method can be executed by a service function migration device, which can be implemented in hardware and / or software and is generally configured in an electronic device.

[0040] Correspondingly, such as Figure 1 As shown, the method includes:

[0041] S110. When it is necessary to migrate the system providing services from the first system to the second system, obtain the original online components in the first system and the target online components in the second system.

[0042] The original online component includes a first original processing interface and a second original processing interface connected together, and the second online component includes a first target processing interface and a second target processing interface connected together.

[0043] In this embodiment, the first system and the second system are deployed on different types of machines, using different programming languages ​​and different types of databases. The first part of the system migration is the online part, which adopts a layered architecture design and includes two core interface components, A and B. The A-layer interface (front-end access layer) is mainly responsible for receiving and forwarding requests and does not directly participate in database operations. After receiving the instructions forwarded by the A-layer interface, the B-layer interface (business logic layer) directly interacts with the underlying database to complete specific business logic processing and data access operations.

[0044] The original first processing interface and the original second processing interface can be understood as layer A and layer B on the first system, and for ease of understanding, they are labeled A1 and B1 respectively. The target first processing interface and the target second processing interface can be understood as layer A and layer B on the second system, and for ease of understanding, they are labeled A2 and B2 respectively.

[0045] S120. Through a multi-stage online migration processing mechanism, the upstream real-time service requests responded to by the original online component in the first system are migrated to the target online component in the second system for response.

[0046] In this embodiment, a progressive online migration mechanism is adopted to achieve seamless switching of service requests. This process is carried out through a layered architecture design. First, a smooth transition of the request entry point is completed, then the business processing logic is migrated, and finally a complete switch of database operations is achieved.

[0047] S130. When the multi-stage online migration process reaches the target migration stage, the batch tasks are switched from the first system to the second system for task response through the batch task migration processing mechanism.

[0048] Batch tasks can be understood as pre-combining multiple computational tasks that do not require real-time user interaction into a batch, which is then automatically and continuously executed by the computer system in the background according to a sequence or scheduling strategy. This aims to efficiently complete resource-intensive or time-consuming tasks, such as data processing, report generation, and scientific computing. It is initiated in the background, not triggered by the client.

[0049] In this embodiment, batch tasks are designed for all data already absorbed by the system. Therefore, the switch can only begin after the data in the new and old systems are fully aligned. The batch part is divided into parallel batch and mutually exclusive batch: parallel batch refers to batch jobs where the new and old systems can each process all the data, such as report generation; mutually exclusive batch refers to batch jobs where only one side can run at a time, as parallel running will cause business errors, such as batch billing.

[0050] The technical solution of this invention, when a service system needs to be migrated from a first system to a second system, firstly obtains the original online components in the first system and the target online components in the second system. Subsequently, through a multi-stage online migration processing mechanism, upstream real-time service requests are transitioned from the original online components in the first system to the target online components in the second system for response, ensuring a smooth migration of business traffic. When the multi-stage online migration process reaches the target migration stage, a batch task migration processing mechanism switches batch tasks from the first system to the second system for task response. This novel service function migration method enables the business system to operate without downtime during the migration process, and ensures seamless migration for users through a gradual switching mechanism. At the same time, the adoption of a batch task and online business collaborative migration strategy effectively solves the technical challenges of data consistency and business continuity between heterogeneous systems, significantly reducing the risks and costs of system upgrades and transformations.

[0051] Example 2

[0052] Figure 2 This is a flowchart of another service function migration method provided in Embodiment 2 of the present invention. This embodiment is based on the above embodiments and optimized. In this embodiment, under the condition that the original first processing interface and the target first processing interface do not perform database read and write operations, but the original second processing interface and the target second processing interface do perform database read and write operations, the operation of "migrating the upstream real-time service request responded by the original online component in the first system to the target online component in the second system for response through a multi-stage online migration processing mechanism" in the above embodiments is refined. Specifically, it can be: migrating the upstream real-time service request responded by the original first processing interface to the target first processing interface for response through multiple first interface online migration stages; after completing the online migration of each first interface, migrating the calling interface of the target first processing interface from the original second processing interface response to the target second processing interface through multiple second interface online migration stages.

[0053] Correspondingly, such as Figure 2 As shown, the method includes:

[0054] S210. When it is necessary to migrate the system providing services from the first system to the second system, obtain the original online component in the first system and the target online component in the second system.

[0055] The original online component includes a first original processing interface and a second original processing interface connected together, and the second online component includes a first target processing interface and a second target processing interface connected together.

[0056] S220. Through multiple online migration phases of the first interface, the upstream real-time service request that was responded to by the original first processing interface is migrated to the target first processing interface for response.

[0057] In this embodiment, a whitelist-based progressive traffic scheduling strategy is adopted to increase the request processing ratio of the new interface by dynamically adjusting the whitelist scope. The whitelist can be understood as a dynamically maintained set of business traffic access rules. Essentially, it is a traffic scheduling list used to precisely control the switching process between old and new systems, represented as a set of real-time target data identifiers (such as combinations of key fields like user ID, transaction type, and channel code). By verifying the matching relationship between request characteristics and the whitelist, it is determined whether the request will be routed to the second system interface or the first system interface for processing.

[0058] Specifically, in the initial stage of the migration, the whitelist only includes core business identifiers that have undergone rigorous verification (such as internal test accounts, low-risk transaction types, etc.). As more business identifiers are added after verification, it will eventually cover all business scenarios. Each expansion of the whitelist requires double verification: it must ensure that the business corresponding to the newly added identifier has the same processing result in the second system interface as in the first system, and it must also verify that the system load capacity meets expectations, so as to complete the migration between the two systems under the safest conditions.

[0059] S230. After completing the online migration of each first interface, through multiple online migration stages of second interfaces, the calling interface of the target first processing interface is migrated from the original second processing interface response to the target second processing interface.

[0060] In this embodiment, after completing the online migration of the first interface, the migration of the second interface continues, switching the downstream services called by the target first processing interface from the original second processing interface to the target second processing interface. The migration process adopts a phased strategy, ensuring a smooth transition of call requests through controllable traffic scheduling, ultimately enabling all downstream services to respond independently from the target second processing interface.

[0061] S240. When the multi-stage online migration process reaches the target migration stage, the batch tasks are switched from the first system to the second system for task response through the batch task migration processing mechanism.

[0062] The technical solution of this invention first obtains the original online component in the first system and the target online component in the second system. Through multiple first interface online migration stages, upstream real-time service requests responded to by the original first processing interface are migrated to the target first processing interface for response. After completing the online migration of each first interface, through multiple second interface online migration stages, the calling interface of the target first processing interface is migrated from the original second processing interface response to the target second processing interface. When the multi-stage online migration process reaches the target migration stage, a batch task migration processing mechanism is used to switch batch tasks from the first system to the second system for task response, ultimately completing the smooth migration of the entire system. This novel service function migration method effectively achieves seamless switching of business services through a layered and progressive migration mechanism, ensuring both high availability of inter-system calls and the integrity and consistency of data across the entire chain. This two-layer migration architecture significantly reduces the risk of system upgrades, enabling core business processing and auxiliary services to complete a smooth transition independently and controllably, greatly improving the stability and reliability of the overall migration process.

[0063] Optionally, based on the above embodiments, migrating upstream real-time service requests responded to by the original first processing interface to the target first processing interface for response through multiple first interface online migration stages may include:

[0064] Triggering the upstream switching phase, during which the target first processing interface receives the upstream real-time service request, calls the original first processing interface to process the upstream real-time service request and obtain the real-time result, and then calls the original second processing interface to process the real-time result.

[0065] When it is determined that the accuracy of the real-time results processing meets the preset accuracy threshold, the process is triggered to enter the first processing interface switching stage.

[0066] During the first processing interface switching phase, after receiving the upstream real-time service request through the target first processing interface, the operation of calling the original first processing interface to process the upstream real-time service request and obtain the real-time result, and then calling the original second processing interface to process the real-time result, is switched to the operation of directly processing the upstream real-time service request through the target first processing interface and obtaining the real-time result, and then calling the original second processing interface to process the real-time result.

[0067] Generally, when the upstream switching phase is triggered by meeting preset conditions (such as passing tests or meeting monitoring metrics), the target primary processing interface will initially serve as the request entry point to receive traffic, but will still rely on the original system's processing logic to ensure business continuity. This transition method can both verify the access capabilities of the new interface in advance and avoid business risks that may result from a direct switch.

[0068] Specifically, Figure 3 This is a schematic diagram of the upstream migration stage, such as... Figure 3 As shown, when A2 (the target first processing interface) receives a real-time service request from the upstream, it first forwards the request to A1 (the original first processing interface) to complete the core business processing. After A1 returns the real-time result, the system continues to process the result further at B1 (the original second processing interface). This step-by-step invocation mechanism achieves smooth switching of the request entry point while ensuring the integrity and consistency of the business processing flow.

[0069] Generally, when the accuracy of the new interface in processing real-time business operations reaches a preset standard (such as an error rate below 0.001% or a success rate exceeding 99.99%), the switching process for the primary processing interface is automatically triggered. During this process, the request distribution logic is controlled by a dynamically adjusted traffic whitelist, gradually migrating business processing responsibilities from the original primary interface to the target primary interface. This data-verified, phased transition mechanism ensures service stability while effectively verifying the processing capabilities of the new interface, ultimately achieving a smooth migration of business processing.

[0070] Specifically, Figure 4 This is a diagram illustrating the first processing interface migration phase, as shown below. Figure 4 As shown, after receiving a real-time service request from upstream, A2 initially forwards the request to A1 for business processing according to a preset whitelist rule, and then calls B1 for subsequent operations. As the number of whitelist entries increases, more requests will be directly processed by A2 in real-time, retaining only the step of calling B1, ultimately achieving a complete migration of the first processing layer.

[0071] Example 3

[0072] Figure 5 This is a flowchart of another service function migration method provided in Embodiment 3 of the present invention. This embodiment is based on and optimized from the above embodiments. In this embodiment, the operation of "migrating the call interface of the target first processing interface from the original second processing interface response to the target second processing interface through multiple second interface online migration stages" is specifically refined.

[0073] Correspondingly, such as Figure 5 As shown, the method includes:

[0074] S310. When it is necessary to migrate the system providing services from the first system to the second system, obtain the original online components in the first system and the target online components in the second system.

[0075] The original online component includes a first original processing interface and a second original processing interface connected together, and the second online component includes a first target processing interface and a second target processing interface connected together.

[0076] S320. Through multiple online migration phases of the first interface, the upstream real-time service request that was responded to by the original first processing interface is migrated to the target first processing interface for response.

[0077] S330, triggering entry into the first system effective period, and responding to the call of the target first processing interface through the target second processing interface during the first system effective period, calling the original second processing interface to process the received real-time results.

[0078] In this embodiment, when a preset condition is met, the system will enter a first-system-only effective period. Specifically, Figure 6 This is a schematic diagram illustrating the phase where the migration of the second processing interface is only effective during the first system's active period. As shown in the diagram, when A1 needs to call a downstream service, it first sends the request to B2. However, B2 does not directly process the business logic at this time; it merely acts as a forwarding shell and does not execute its own business logic. Instead, it forwards the request to B1 to complete the actual processing and returns the processing result to A2. The business logic is essentially still completed by the first system. The preset condition is that the A-layer interface has been switched over and has been running stably for more than 24 hours.

[0079] S340. When it is determined that the accuracy of the processing of the real-time results meets the preset accuracy threshold condition, the first interface comparison period is triggered.

[0080] In this embodiment, when the accuracy of the new interface in processing real-time business results consistently reaches a preset standard, the first interface comparison period will be automatically triggered. During this phase, requests are processed in parallel by the old and new systems, and the results are rigorously compared to ensure the consistency of business logic, providing a data verification basis for the subsequent complete switchover.

[0081] S350. During the first interface comparison period, the target second processing interface responds to the call of the target first processing interface, calls the original second processing interface to process the received real-time results to obtain the old interface data, and then the target second processing interface processes the real-time results to obtain the new interface data, and performs the comparison of the new interface data and the old interface data and the return operation of the old interface data.

[0082] In this embodiment, Figure 7 This is a diagram illustrating the migration phase from the second interface to the first interface, as shown below. Figure 6As shown: After the upstream caller sends a request to A2, A2 triggers its local business logic module B2 to process it. B2 then employs a step-by-step execution strategy: first, it calls B1 from the first system to complete the business processing, and then executes its own local logic processing. Throughout the entire process, the processing result of B1 is always returned to the upstream caller as the final response, ensuring the accuracy and consistency of the business results.

[0083] S360. When it is determined that the new interface data and the old interface data meet the consistency conditions, the second interface comparison period is triggered.

[0084] In this embodiment, when the output data of B2 and B1 are completely consistent through real-time comparison (such as 100% field matching and transaction status synchronization) and have been running stably for more than a preset period (such as 24 hours), the second interface comparison period will be automatically triggered.

[0085] S370. During the second interface comparison period, the target second processing interface responds to the call of the target first processing interface. After the target second processing interface processes the real-time results to obtain new interface data, it calls the original second processing interface to process the real-time results to obtain old interface data, and performs the comparison of new interface data and old interface data and the return operation of new interface data.

[0086] In this embodiment, Figure 8 This is a diagram illustrating the second interface migration and the second interface comparison phase, as shown below. Figure 7 As shown: The upstream caller sends a request to A2, which executes its local business processing flow. This flow ultimately calls module B2 to complete the specific business logic. Module B2 employs a step-by-step execution mechanism during processing: it first executes its own local business logic, then calls the first system B1 for supplementary processing, and finally returns the result after complete processing by B2.

[0087] Meanwhile, the migration work has been basically completed, but for the sake of robustness, the interfaces and processing logic of the first system have been retained. This provides reliable fault tolerance for the second system. When the second system becomes unstable or experiences sudden anomalies in the early stages of operation, it can be immediately switched back to the first system to continue processing business requests, ensuring that service continuity is not affected.

[0088] S380. When it is determined that the new interface data and the old interface data meet the consistency condition, the second processing interface switching stage is triggered. In the second processing interface switching stage, the target second processing interface responds to the call of the target first processing interface. The target second processing interface processes the received real-time results to obtain the new interface data and returns the new interface data.

[0089] In this embodiment, when the system confirms through real-time monitoring and log comparison that the output data of B2 and B1 are completely consistent (including core indicators such as transaction status, business fields, and return codes), and this consistency remains stable for a preset duration, the system enters the final stage of business migration. The upstream service has completely switched to calling A2, and A2 only executes its own business processing flow, ultimately handing over the business logic calculations to B2. B2 independently runs its business rules and directly returns the processing result, no longer relying on other components. At this point, the incremental data generated by the old and new environments remains completely synchronized. If the historical data migration is verified to be complete and error-free, it indicates that the new environment has the capability to independently handle all business traffic and can operate completely independently of the original architecture.

[0090] S390. When the multi-stage online migration process reaches the target migration stage, the batch tasks are switched from the first system to the second system for task response through the batch task migration processing mechanism.

[0091] The technical solution of this invention first obtains the original online components of the first system and the target online components of the second system. Through multiple first interface online migration stages, upstream requests are gradually migrated from the original first processing interface to the target first processing interface. Then, a first system-only effective period begins, where the target second processing interface calls the original second processing interface to process requests. When the processing accuracy reaches a preset threshold, a first interface comparison period begins, where the old and new interfaces process in parallel and compare the results. After consistency verification is passed, a second interface comparison period begins, where the processing order is swapped for further verification. Finally, a second processing interface switching stage is triggered, where requests are entirely processed by the target second processing interface. After the online migration is complete, a batch task migration processing mechanism switches batch tasks to the second system. This novel service function migration method ensures the accuracy and consistency of data processing through a phased comparison and verification mechanism. The dual-path verification mode in the first and second interface comparison periods not only promptly detects deviations in the new interface processing results but also ensures uninterrupted business continuity, ultimately achieving a smooth transition between the old and new systems.

[0092] Optionally, based on the above embodiments, when the multi-stage online migration process reaches the target migration stage, a batch task migration processing mechanism is used to switch the batch tasks from the first system to the second system for task response. This may include:

[0093] During the second interface comparison period of the multi-stage online migration process, the first and second control systems jointly receive the parallel batch task set, obtain the two task processing results generated by the first and second systems for the parallel batch task set, and send them to the downstream module for result comparison.

[0094] During the multi-stage online migration process, when the second processing interface switching stage is reached, only the second system receives and processes the parallel batch task set, and sends the generated task processing results to the downstream module.

[0095] Generally, in the second interface comparison phase of the migration process, a dual-path parallel processing mechanism is adopted to ensure the accuracy of business processing. At this time, the first and second systems simultaneously receive the same batch task requests, process them independently, and generate results. These results are then sent to the downstream comparison module for consistency verification. This dual-track operation mode can both verify the processing capabilities of the new architecture and ensure timely detection of problems when discrepancies occur.

[0096] Generally, when the migration enters the second processing interface switching phase, the processing mode will switch to single-path operation. At this time, all batch task requests are received and processed only by the second system, and the generated results are directly sent to downstream modules for use. This phase signifies that the new architecture has passed the initial verification, has the ability to independently handle business, and can fully handle production traffic. The entire switching process adopts a gradual transition, ensuring both business continuity and the reliability of processing results.

[0097] Optionally, based on the above embodiments, when the multi-stage online migration process reaches the target migration stage, a batch task migration processing mechanism is used to switch the batch tasks from the first system to the second system for task response. This may include:

[0098] During the multi-stage online migration process, when the second interface comparison period is reached, a first online interface corresponding to the first system and a second online interface corresponding to the second system are constructed.

[0099] The first online interface is used to modify database tables in the first system, and the second online interface is used to modify database tables in the second system.

[0100] The system controls the first system and the second system to jointly receive a set of mutually exclusive batch tasks. When the first system detects that the currently processed mutually exclusive batch task is a task pointing to the local system based on the task whitelist jointly maintained and expanded with the second system, it performs a deduction operation and then only calls the first online interface to modify the database table in the first system. When the second system detects that the currently processed mutually exclusive batch task is a task pointing to the local system based on the task whitelist, it performs a deduction operation and then sequentially calls the second online interface and the first online interface to modify the database tables in the two systems.

[0101] The task whitelist is used to switch tasks in a mutually exclusive batch task set from the first system to the second system for exclusive execution.

[0102] During the multi-stage online migration process, when the second processing interface is switched, the second system only receives the mutually exclusive batch task set, performs the billing operation, and then calls the second online interface to modify the database tables within the second system.

[0103] Generally, during the second interface comparison phase of a multi-stage online migration, the second system builds its own batch job P1 based on the first system's batch job P, and encapsulates online interfaces C1 and C2 respectively. These two interfaces may serve different environments, but their core logic originates from the first system's "modify database table" logic. The first system can modify its own database tables through interface C1, and the second system can modify its own database tables through interface C2. This design maintains the consistency of processing logic while achieving environmental isolation, laying the technical foundation for subsequent dual-write verification and result comparison. Through this interface mirroring mechanism, it can be effectively ensured that both the old and new environments can handle data change requests in the same way during the migration process.

[0104] Generally, during the migration of mutually exclusive batch tasks, a task diversion mechanism based on a traffic whitelist is used to coordinate the collaboration between the first and second systems. Specifically, Figure 9 This is a diagram illustrating the mutual exclusion batch migration phase, as shown below. Figure 9 As shown, the second system's batch task execution flow is as follows: deduction - call C2 interface - call C1 interface. Both the first and second systems maintain the same whitelist. The second system only processes whitelisted data, while the first system processes non-whitelisted data. During the migration process, the whitelist scope is expanded, and ultimately, all data is processed entirely by the second system's batch job P1. The first system's batch job P is deactivated, only passively modifying database tables through the C1 interface. To ensure data consistency, interfaces C1 and C2 use database transaction control, following the "shared success, shared failure" principle to guarantee consistent processing results. If results are inconsistent, a transaction rollback mechanism is triggered, thus ensuring the reliability of the entire migration process.

[0105] Furthermore, a service system migration method may also include:

[0106] During the multi-stage online migration process, when the second interface comparison period is reached, whenever the preset database table synchronization conditions are met, the changed data is obtained from the database table in the first system, and the changed data is used to perform data targeting on the database table in the second system.

[0107] Generally, data in the second system's database is synchronized from the first system's database. When processing parallel batch tasks, the two systems will process data simultaneously, and the data in their respective databases will also be synchronized. However, when processing mutually exclusive batch tasks, the second system, when processing whitelisted data, first calls interface C2 and then calls C1, and the databases of the two systems will remain consistent. But when processing non-whitelisted data, data processing is only performed through the first system's C1 interface, and the data in the modified database cannot be synchronized to the second system's database. In this case, a preset data synchronization algorithm will be used to synchronize batch files in real time and at the end of the day to maintain data consistency between the first and second systems.

[0108] Specifically, Figure 10 It is a flowchart of real-time data synchronization, such as Figure 10 As shown: First, the data change monitoring thread of the first system (old system) database table captures the source data changes in real time and pushes the changed data to the message queue cluster; then, the consumer service of the second system (new system) subscribes to and pulls these changed data from the message queue, and finally performs incremental target operations on the new system database table according to the data content.

[0109] Generally, as a fallback mechanism for near real-time synchronization, the batch file synchronization process starts at midnight on day T: The first system first performs a batch file processing job, scanning all changed data in the database table of the previous day (day T-1) and generating batch files to be sent to the second system (theoretically, these data have been synchronized the previous day); After receiving the files, the second system starts a reading job, comparing the file data with the local database records one by one - if the file data timestamp is the target, the target is overwritten; if the data does not exist, the insertion operation is performed. This dual verification mechanism ensures that the eventual consistency of the data at both ends can be maintained even in extreme cases.

[0110] Example 4

[0111] Figure 11 This is a schematic diagram of a service function migration device provided in Embodiment 4 of the present invention. Figure 11 As shown, the device includes:

[0112] The component acquisition module 1110 is used to acquire the original online component in the first system and the target online component in the second system when it is necessary to migrate the system providing services from the first system to the second system; wherein, the original online component includes an original first processing interface and an original second processing interface connected together, and the second online component includes a target first processing interface and a target second processing interface connected together.

[0113] The online migration module 1120 is used to migrate upstream real-time service requests responded to by the original online component in the first system to the target online component in the second system for response through a multi-stage online migration processing mechanism.

[0114] The batch task migration module 1130 is used to switch batch tasks from the first system to the second system for task response when the multi-stage online migration process reaches the target migration stage, through the batch task migration processing mechanism.

[0115] The technical solution of this invention, when a service system needs to be migrated from a first system to a second system, firstly obtains the original online component in the first system and the target online component in the second system. Subsequently, through a multi-stage online migration processing mechanism, the upstream real-time service requests are transitioned from the original online component in the first system to the target online component in the second system for response, ensuring a smooth migration of business traffic. When the multi-stage online migration process reaches the target migration stage, a batch task migration processing mechanism switches batch tasks from the first system to the second system for task response. This novel service function migration method achieves zero-interruption operation of the business system during the migration process, and ensures seamless migration for users through a gradual switching mechanism. At the same time, the adoption of a batch task and online business collaborative migration strategy effectively solves the technical challenges of data consistency and business continuity between heterogeneous systems, significantly reducing the risks and costs of system upgrades and transformations.

[0116] Based on the above embodiments, the original first processing interface and the target first processing interface do not perform database read / write operations, while the original second processing interface and the target second processing interface do perform database read / write operations. The online migration module 1120 may further include:

[0117] The first processing interface migration submodule is used to migrate upstream real-time service requests that are responded to by the original first processing interface to the target first processing interface for response through multiple online migration stages of the first interface;

[0118] The second processing interface migration submodule is used to migrate the call interface of the target first processing interface from the original second processing interface response to the target second processing interface through multiple second interface online migration stages after completing the online migration of each first interface.

[0119] Based on the above embodiments, the first processing interface migration submodule is specifically used for:

[0120] Triggering the upstream switching phase, during which the target first processing interface receives the upstream real-time service request, calls the original first processing interface to process the upstream real-time service request and obtain the real-time result, and then calls the original second processing interface to process the real-time result.

[0121] When it is determined that the accuracy of the real-time results processing meets the preset accuracy threshold, the process is triggered to enter the first processing interface switching stage.

[0122] During the first processing interface switching phase, after receiving the upstream real-time service request through the target first processing interface, the operation of calling the original first processing interface to process the upstream real-time service request and obtain the real-time result, and then calling the original second processing interface to process the real-time result, is switched to the operation of directly processing the upstream real-time service request through the target first processing interface and obtaining the real-time result, and then calling the original second processing interface to process the real-time result.

[0123] Based on the above embodiments, the second processing interface migration submodule is specifically used for:

[0124] Trigger entry into the first system effective period, and during the first system effective period, respond to the call of the target first processing interface through the target second processing interface, and call the original second processing interface to process the received real-time results;

[0125] When it is determined that the accuracy of the real-time results processing meets the preset accuracy threshold, the first interface comparison period is triggered.

[0126] During the first interface comparison period, the target second processing interface responds to the call of the target first processing interface, calls the original second processing interface to process the received real-time results to obtain the old interface data, and then the target second processing interface processes the real-time results to obtain the new interface data, and performs the comparison of the new interface data and the old interface data and the return operation of the old interface data.

[0127] Once it is determined that the new interface data and the old interface data meet the consistency conditions, the second interface comparison period is triggered.

[0128] During the second interface comparison period, the target second processing interface responds to the call of the target first processing interface. After the target second processing interface processes the real-time results to obtain new interface data, it calls the original second processing interface to process the real-time results to obtain old interface data, and performs the comparison of new interface data and old interface data and the return operation of new interface data.

[0129] When it is determined that the new interface data and the old interface data meet the consistency condition, the second processing interface switching phase is triggered. During the second processing interface switching phase, the target second processing interface responds to the call of the target first processing interface. The target second processing interface processes the received real-time results to obtain the new interface data and returns the new interface data.

[0130] Based on the above embodiments, the batch task migration module 1130 is specifically used for:

[0131] During the second interface comparison period of the multi-stage online migration process, the first and second control systems jointly receive the parallel batch task set, obtain the two task processing results generated by the first and second systems for the parallel batch task set, and send them to the downstream module for result comparison.

[0132] During the multi-stage online migration process, when the second processing interface switching stage is reached, only the second system receives and processes the parallel batch task set, and sends the generated task processing results to the downstream module.

[0133] Based on the above embodiments, the batch task migration module 1130 is specifically used for:

[0134] During the multi-stage online migration process, when the second interface comparison period is reached, a first online interface corresponding to the first system and a second online interface corresponding to the second system are constructed.

[0135] The first online interface is used to modify database tables in the first system, and the second online interface is used to modify database tables in the second system.

[0136] The system controls the first system and the second system to jointly receive a set of mutually exclusive batch tasks. When the first system detects that the currently processed mutually exclusive batch task is a task pointing to the local system based on the task whitelist jointly maintained and expanded with the second system, it performs a deduction operation and then only calls the first online interface to modify the database table in the first system. When the second system detects that the currently processed mutually exclusive batch task is a task pointing to the local system based on the task whitelist, it performs a deduction operation and then sequentially calls the second online interface and the first online interface to modify the database tables in the two systems.

[0137] The task whitelist is used to switch tasks in a mutually exclusive batch task set from the first system to the second system for exclusive execution.

[0138] During the multi-stage online migration process, when the second processing interface is switched, the second system only receives the mutually exclusive batch task set, performs the billing operation, and then calls the second online interface to modify the database tables within the second system.

[0139] Based on the above embodiments, it may further include: a data synchronization module, specifically used for:

[0140] During the multi-stage online migration process, when the second interface comparison period is reached, whenever the preset database table synchronization conditions are met, the changed data is obtained from the database table in the first system, and the changed data is used to perform data targeting on the database table in the second system.

[0141] Example 5

[0142] Figure 12 A schematic diagram of an electronic device 10 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0143] like Figure 12 As shown, the electronic device 10 includes at least one processor 11 and a memory, such as a read-only memory (ROM) 12 or a random access memory (RAM) 13, communicatively connected to the at least one processor 11. The memory stores computer programs executable by the at least one processor. The processor 11 can perform various appropriate actions and processes based on the computer program stored in the ROM 12 or loaded from storage unit 18 into the RAM 13. The RAM 13 may also store various programs and data required for the operation of the electronic device 10. The processor 11, ROM 12, and RAM 13 are interconnected via a bus 14. An input / output (I / O) interface 15 is also connected to the bus 14.

[0144] Multiple components in electronic device 10 are connected to I / O interface 15, including: input unit 16, such as keyboard, mouse, etc.; output unit 17, such as various types of displays, speakers, etc.; storage unit 18, such as disk, optical disk, etc.; and communication unit 19, such as network card, modem, wireless transceiver, etc. Communication unit 19 allows electronic device 10 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0145] Processor 11 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 11 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 11 performs the various methods and processes described above, such as a service function migration method, namely:

[0146] When it is necessary to migrate the system providing services from the first system to the second system, obtain the original online components in the first system and the target online components in the second system;

[0147] The original online component includes a first original processing interface and a second original processing interface connected together, and the second online component includes a first target processing interface and a second target processing interface connected together.

[0148] Through a multi-stage online migration processing mechanism, upstream real-time service requests that are responded to by the original online component in the first system are migrated to the target online component in the second system for response.

[0149] When the multi-stage online migration process reaches the target migration stage, the batch task migration processing mechanism switches the batch tasks from the first system to the second system for task response.

[0150] In some embodiments, a service function migration method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 18. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 10 via ROM 12 and / or communication unit 19. When the computer program is loaded into RAM 13 and executed by processor 11, one or more steps of the service function migration method described above may be performed. Alternatively, in other embodiments, processor 11 may be configured to perform a service function migration method by any other suitable means (e.g., by means of firmware).

[0151] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0152] Computer programs used to implement the methods of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer programs cause the functions / operations specified in the flowcharts and / or block diagrams to be performed. The computer programs may be executed entirely on a machine, partially on a machine, or as a standalone software package, partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0153] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0154] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0155] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or computing systems that include middleware components (e.g., application servers), or computing systems that include frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0156] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0157] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0158] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A service system migration method, characterized in that, include: When it is necessary to migrate the system providing services from the first system to the second system, obtain the original online components in the first system and the target online components in the second system; The original online component includes a first original processing interface and a second original processing interface connected together, and the second online component includes a first target processing interface and a second target processing interface connected together. Through a multi-stage online migration processing mechanism, upstream real-time service requests that are responded to by the original online component in the first system are migrated to the target online component in the second system for response. When the multi-stage online migration process reaches the target migration stage, the batch task migration processing mechanism switches the batch tasks from the first system to the second system for task response.

2. The method according to claim 1, characterized in that, The original first processing interface and the target first processing interface do not perform database read and write operations, while the original second processing interface and the target second processing interface do perform database read and write operations. Through a multi-stage online migration processing mechanism, upstream real-time service requests that are responded to by the original online component in the first system are migrated to the target online component in the second system for response. Specifically, this includes: Through multiple online migration phases of the first interface, upstream real-time service requests that were originally responded to by the first processing interface are migrated to the target first processing interface for response; After completing the online migration of each first interface, the call interface of the target first processing interface is migrated from the original second processing interface response to the target second processing interface through multiple second interface online migration stages.

3. The method according to claim 2, characterized in that, Through multiple online migration phases using the first interface, upstream real-time service requests that were originally responded to by the first processing interface are migrated to the target first processing interface for response, including: Triggering the upstream switching phase, during which the target first processing interface receives the upstream real-time service request, calls the original first processing interface to process the upstream real-time service request and obtain the real-time result, and then calls the original second processing interface to process the real-time result. When it is determined that the accuracy of the real-time results processing meets the preset accuracy threshold, the process is triggered to enter the first processing interface switching stage. During the first processing interface switching phase, after receiving the upstream real-time service request through the target first processing interface, the operation of calling the original first processing interface to process the upstream real-time service request and obtain the real-time result, and then calling the original second processing interface to process the real-time result, is switched to the operation of directly processing the upstream real-time service request through the target first processing interface and obtaining the real-time result, and then calling the original second processing interface to process the real-time result.

4. The method according to claim 2, characterized in that, Through multiple online migration phases via second interfaces, the calling interface of the target first processing interface is migrated from the original second processing interface response to the target second processing interface, including: Trigger entry into the first system effective period, and during the first system effective period, respond to the call of the target first processing interface through the target second processing interface, and call the original second processing interface to process the received real-time results; When it is determined that the accuracy of the real-time results processing meets the preset accuracy threshold, the first interface comparison period is triggered. During the first interface comparison period, the target second processing interface responds to the call of the target first processing interface, calls the original second processing interface to process the received real-time results to obtain the old interface data, and then the target second processing interface processes the real-time results to obtain the new interface data, and performs the comparison of the new interface data and the old interface data and the return operation of the old interface data. Once it is determined that the new interface data and the old interface data meet the consistency conditions, the second interface comparison period is triggered. During the second interface comparison period, the target second processing interface responds to the call of the target first processing interface. After the target second processing interface processes the real-time results to obtain new interface data, it calls the original second processing interface to process the real-time results to obtain old interface data, and performs the comparison of new interface data and old interface data and the return operation of new interface data. When it is determined that the new interface data and the old interface data meet the consistency condition, the second processing interface switching phase is triggered. During the second processing interface switching phase, the target second processing interface responds to the call of the target first processing interface. The target second processing interface processes the received real-time results to obtain the new interface data and returns the new interface data.

5. The method according to claim 4, characterized in that, During the multi-stage online migration process, when reaching the target migration stage, a batch task migration processing mechanism switches batch tasks from the first system to the second system for task response, including: During the second interface comparison period of the multi-stage online migration process, the first and second control systems jointly receive the parallel batch task set, obtain the two task processing results generated by the first and second systems for the parallel batch task set, and send them to the downstream module for result comparison. During the multi-stage online migration process, when the second processing interface switching stage is reached, only the second system receives and processes the parallel batch task set, and sends the generated task processing results to the downstream module.

6. The method according to claim 4, characterized in that, During the multi-stage online migration process, when reaching the target migration stage, a batch task migration processing mechanism switches batch tasks from the first system to the second system for task response, including: During the multi-stage online migration process, when the second interface comparison period is reached, a first online interface corresponding to the first system and a second online interface corresponding to the second system are constructed. The first online interface is used to modify database tables in the first system, and the second online interface is used to modify database tables in the second system. The system controls the first system and the second system to jointly receive a set of mutually exclusive batch tasks. When the first system detects that the currently processed mutually exclusive batch task is a task pointing to the local system based on the task whitelist jointly maintained and expanded with the second system, it performs a deduction operation and then only calls the first online interface to modify the database table in the first system. When the second system detects that the currently processed mutually exclusive batch task is a task pointing to the local system based on the task whitelist, it performs a deduction operation and then sequentially calls the second online interface and the first online interface to modify the database tables in the two systems. The task whitelist is used to switch tasks in a mutually exclusive batch task set from the first system to the second system for exclusive execution. During the multi-stage online migration process, when the second processing interface is switched, the second system only receives the mutually exclusive batch task set, performs the billing operation, and then calls the second online interface to modify the database tables within the second system.

7. The method according to claim 6, characterized in that, The method further includes: During the multi-stage online migration process, when the second interface comparison period is reached, whenever the preset database table synchronization conditions are met, the changed data is obtained from the database table in the first system, and the changed data is used to perform data targeting on the database table in the second system.

8. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the service system migration method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that are used to cause a processor to execute the service system migration method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the service system migration method according to any one of claims 1-7.

Images