System migration method and device

Abstract

The invention discloses a system migration method, device and equipment, and relates to the technical field of system migration. The method comprises the following steps: determining a target user group; the system plug-in collects service request data of a user of the target user group for a target service provided by the first system in the evaluation period, and result data and time consumption data of processing the request by the first system; sending the request to a second system, and collecting result data and time consumption data of processing the request by the second system; respectively comparing the result data and the time consumption data of the two systems, and judging whether the target services respectively provided by the two systems have functional equivalence to the target user group; and if the function is judged to be equivalent, switching the service request data of the users of the target user group after the evaluation period to the second system. By adopting the processing mode, normal use of user functions after the new system and the old system are switched can be guaranteed, and the user experience can be effectively improved.

Description

Technical Field

[0001] The present application relates to the technical field of system migration, and in particular to a system migration method and apparatus, a system migration functional equivalence evaluation method and apparatus, a system service method and apparatus, a migration system, a system plug-in, and an electronic device. Background Art

[0002] In the internet industry, with the rapid growth of application demand, many systems are facing architectural bottlenecks, unable to support rapidly expanding and complex application requirements. To address this issue, system architecture refactoring has become a common solution. During the refactoring process, a new system must be designed to replace the old one. During the transition between the old and new systems, system functionality must be maintained to avoid impacting user functionality.

[0003] A typical system migration method is a downtime migration, which involves migrating all users from the old system to the new one all at once. The disadvantage of a downtime migration is that any issues with the new system can impact users globally, resulting in a poor user experience. Compared to downtime migration, a grayscale migration is a more flexible and commonly used system migration method. During a grayscale migration, you can initially direct some traffic or users to the new system, then gradually increase traffic or users. This approach effectively minimizes the impact of the migration on actual applications while also improving data security and reliability.

[0004] At present, the specific implementation method of grayscale migration is to directly access a part of the traffic or users through the new system, and then correct the new system based on the feedback from these users on the problems they encounter when using the new system. After the new system is corrected, the traffic or individual users will be gradually increased.

[0005] Then, in the process of implementing this application, the inventor discovered that the existing grayscale migration method has at least the following problems: when switching the flow for a specified user, it is not known whether there is a problem with the new system. If there is a problem with the new system, it will affect the user experience of these users. Summary of the Invention

[0006] This application provides a system migration method to address the existing problem of poor user experience caused by the inability to pre-determine whether the new and old systems are functionally equivalent during the grayscale migration process. This application also provides a system migration device, a system migration functional equivalence assessment method and device, a system service method and device, a migration system, a system plug-in, and an electronic device.

[0007] The present application provides a system migration method for a first system, further comprising:

[0008] Identify target user groups;

[0009] collecting, through a system plug-in, first service request data of users of the target user group for a target service provided by the first system during an evaluation period, as well as first result data and first time consumption data of the first system processing the first service request data; sending the first service request data to a second system, and collecting second result data and second time consumption data of the second system processing the first service request data; and determining, based on the first result data, the second result data, the first time consumption data, and the second time consumption data, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group;

[0010] If it is determined that there is functional equivalence for the target user group, the service request data of users of the target user group after the evaluation period are switched to the second system.

[0011] Optionally, the collection of the first service request data, the first result data and the first time-consuming data is implemented as follows: using aspect-oriented programming, the first application program interface of the target service entrance of the first system is intercepted to collect the first service request data, the first result data and the first time-consuming data.

[0012] Optionally, the method further includes: performing exception capture on the step of determining whether the target services provided by the first system and the second system are functionally equivalent for the target user group based on the first result data, the second result data, the first time consumption data, and the second time consumption data;

[0013] If an exception is caught, the exception information is stored.

[0014] Optionally, sending the first service request data to the second system includes: sending the service request data to the second system in an asynchronous playback manner.

[0015] Optionally, sending the first service request data to the second system includes: setting thread pool parameters; and sending the first service request data to the second system through the thread pool.

[0016] Optionally, it also includes: determining a comparison indicator; judging whether the target services provided by the first system and the second system are functionally equivalent to the at least one target user based on the first result data, the second result data, the first time consumption data and the second time consumption data, including: judging whether the comparison indicator data are the same based on the comparison indicator data in the first result data and the comparison indicator data in the second result data.

[0017] Optionally, the method further includes: determining whether to start a plug-in; if it is determined to start the plug-in, collecting the first service request data through the system plug-in.

[0018] Optionally, the method further includes: determining a non-target user group; the determining the target user group includes: acquiring the target user group based on users other than the non-target user group.

[0019] Optionally, the method further includes: determining a non-target service; and taking a service other than the non-target service as the target service.

[0020] Optionally, the method further includes: displaying an alarm message if it is determined that there is no functional equivalence for the target user group.

[0021] Optionally, the method further includes: obtaining statistical data of functional equivalence evaluation, the statistical data including at least one of the following data: the total number of service request playbacks, the number of functionally equivalent service requests, the number of functionally inequal service requests, and the number of abnormal service requests compared with the results; and displaying the statistical data.

[0022] The present application also provides a system migration method for a second system, further comprising:

[0023] Get the target user group;

[0024] collecting, through a system plug-in, second service request data of users of the target user group for a target service provided by the second system during a verification period, as well as third result data and third time consumed by the second system in processing the second service request data; sending the second service request data to the first system, and collecting fourth result data and fourth time consumed by the first system in processing the second service request data; and determining, based on the third result data, the fourth result data, the third time consumed data, and the fourth time consumed data, whether the target services provided by the first system and the second system are functionally equivalent for the target user group;

[0025] If it is determined that there is no functional equivalence for the target user group, subsequent service request data of users of the target user group is switched to the first system.

[0026] Optionally, the method further includes: determining whether the service request data received by the second system is the second service request data.

[0027] This application also provides a system migration functional equivalence evaluation method for a plug-in of a first system, comprising:

[0028] Collecting service request data of users of the target user group for the target service provided by the first system during the evaluation period, as well as first result data and first time consumption data of the first system processing the service request data;

[0029] Sending the service request data to a second system, and collecting second result data and second time consumption data of processing the service request data by the second system;

[0030] Based on the first result data, the second result data, the first time consumption data and the second time consumption data, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and use the judgment result as the basis for determining whether the first system switches the service request data of users of the target user group after the evaluation period to the second system.

[0031] The present application also provides a system service method for a first system, comprising:

[0032] receiving service request data from a user for a target service provided by the first system;

[0033] If the user is a user of the target user group, and the target services provided by the first system and the second system respectively have functional equivalence for the target user group, switching the service request data to the second system, and processing the service request data by the second system;

[0034] otherwise, processing the service request data by the first system;

[0035] Wherein, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group is judged by the method provided in claim 14.

[0036] This application also provides a system migration functional equivalence evaluation method for a plug-in of a second system, comprising:

[0037] Collecting service request data of users of the target user group for the target service provided by the second system during the verification period, as well as third result data and third time consumption data of the second system processing the service request data;

[0038] Sending the service request data to the first system, and collecting fourth result data and fourth time consumption data of processing the service request data by the first system;

[0039] Based on the third result data, the fourth result data, the third time-consuming data and the fourth time-consuming data, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and use the judgment result as the basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system.

[0040] The present application also provides a system service method for a second system, comprising:

[0041] receiving service request data from a user for a target service provided by the second system;

[0042] If the user is a user of the target user group, and the target services provided by the first system and the second system respectively do not have functional equivalence for the target user group, switching the service request data to the first system, and processing the service request data by the first system;

[0043] otherwise, processing the service request data by the second system;

[0044] Wherein, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group is judged by the method provided in claim 16.

[0045] The present application also provides a system migration device for a first system, comprising:

[0046] A user setting unit, used to determine a target user group;

[0047] a system plug-in configured to collect first service request data of users of the target user group for a target service provided by the first system during an evaluation period, as well as first result data and first time consumption data of the first system processing the first service request data; send the first service request data to a second system, and collect second result data and second time consumption data of the second system processing the first service request data; and determine, based on the first result data, the second result data, the first time consumption data, and the second time consumption data, whether the target services provided by the first system and the second system are functionally equivalent for the target user group;

[0048] A user switching unit is configured to switch the service request data of users of the target user group after the evaluation period to the second system if it is determined that the system has functional equivalence to the target user group.

[0049] The present application also provides a system migration device for a second system, comprising:

[0050] A user acquisition unit, used to acquire a target user group;

[0051] a system plug-in configured to collect second service request data of users of the target user group for a target service provided by the second system during a verification period, as well as third result data and third time consumed by the second system in processing the second service request data; send the second service request data to the first system, and collect fourth result data and fourth time consumed by the first system in processing the second service request data; and determine, based on the third result data, the third result data, the fourth time consumed data, and the fourth time consumed data, whether the target services provided by the first system and the second system are functionally equivalent for the target user group;

[0052] The user flow switching unit is configured to switch the service request data of users of the target user group to the first system if it is determined that there is no functional equivalence for the target user group.

[0053] The present application also provides a migration system, comprising: the above-mentioned system migration device for the first system; and the above-mentioned system migration device for the second system.

[0054] This application also provides a system plug-in, including:

[0055] a traffic collection unit, configured to collect service request data of users of a target user group for a target service provided by the first system during an evaluation period, and first result data and first time consumption data of the first system processing the service request data;

[0056] a traffic replay unit, configured to send the service request data to the second system, and collect second result data and second time consumption data of processing the service request data by the second system;

[0057] A result comparison unit is used to determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time consumption data and the second time consumption data, and use the judgment result as a basis for determining whether the first system switches the service request data of users of the target user group after the evaluation period to the second system.

[0058] The present application also provides a system service device for a first system, comprising:

[0059] a request receiving unit, configured to receive service request data from a user for a target service provided by the first system;

[0060] a user flow switching unit configured to, if the user is a user of the target user group and the target services provided by the first system and the second system respectively have functional equivalence for the target user group, switch the first service request data to the second system and process the service request data via the second system; otherwise, activate a request processing unit;

[0061] The request processing unit is configured to process the service request data through the first system;

[0062] Wherein, whether the target services respectively provided by the first system and the second system have functional equivalence for the target user group is judged by using the system migration functional equivalence evaluation method for the plug-in of the first system.

[0063] This application also provides a system plug-in, including:

[0064] a traffic collection unit, configured to collect service request data of users of the target user group for the target service provided by the second system during the verification period, and third result data and third time consumption data of the second system processing the service request data;

[0065] a traffic replay unit, configured to send the service request data to the first system, and collect fourth result data and fourth time consumption data of the first system processing the service request data;

[0066] A result comparison unit is used to determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time-consuming data, and the fourth time-consuming data, and use the judgment result as a basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system.

[0067] The present application also provides a system service device for a second system, comprising:

[0068] a request receiving unit, configured to receive service request data from a user for a target service provided by the second system;

[0069] a user flow switching unit configured to, if the user is a user of a target user group and the target services provided by the first system and the second system are not functionally equivalent for the target user group, switch the service request data to the first system and process the service request data via the first system; otherwise, activate a request processing unit;

[0070] The request processing unit is configured to process the service request data through the second system;

[0071] Wherein, whether the target services respectively provided by the first system and the second system have functional equivalence for the target user group is determined by using the system migration functional equivalence evaluation method for the plug-in of the second system.

[0072] The present application also provides an electronic device, comprising:

[0073] processor; and

[0074] The memory is used to store a program for implementing any of the methods described above. The device is powered on and runs the program for the method through the processor.

[0075] The present application also provides a computer-readable storage medium, wherein the computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the above-mentioned various methods.

[0076] The present application also provides a computer program product comprising instructions, which, when executed on a computer, enables the computer to perform the above methods.

[0077] Compared with the prior art, this application has the following advantages:

[0078] The system migration method for a first system (old system) provided in an embodiment of the present application is by determining a target user group; collecting, through a system plug-in, first service request data of users of the target user group for a target service provided by the first system during an evaluation period, as well as first result data and first time data of the first system processing the first service request data; sending the first service request data to a second system (new system), and collecting second result data and second time data of the second system processing the first service request data; judging whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time data, and the second time data; if it is determined that they are functionally equivalent to the target user group, switching the service request data of the users of the target user group after the evaluation period to the second system. This approach allows the old system to pre-determine whether the new and old systems are functionally equivalent before switching a specific user. If so, the user is then switched to the new system. This resolves the issue of system architecture reconstruction, ensuring that the new system is functionally equivalent to the old system, thus guaranteeing the normal functioning of user functions after the system switch, effectively improving the user experience. Furthermore, this functional equivalence assessment between the old and new systems, performed by a plug-in in the old system, eliminates the need to modify the old system's program code and container images, is lightweight and non-invasive to the old system's program code and service runtime environment, and therefore does not impact the old system's reliability. Furthermore, developers developing plug-ins for functional equivalence assessments simply deploy them in the old system to execute the assessment. This makes implementation simple and controllable for developers, with easy integration, out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0079] The system migration method for a second system (new system) provided in an embodiment of the present application obtains a target user group; collects, through a system plug-in, second service request data of users of the target user group for a target service provided by the second system during a verification period, as well as third result data and third time data of the second system processing the second service request data; sends the second service request data to the first system, and collects fourth result data and fourth time data of the first system processing the second service request data; determines whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time data, and the fourth time data; if it is determined that they are not functionally equivalent to the target user group, switching subsequent service request data of the users of the target user group to the first system. This approach allows for the functional equivalence of the old and new systems, assessed by the old system before the switchover, to be verified based on their actual usage. If the new and old systems are found to be not functionally equivalent based on more actual usage, these users are switched back to the old system to prevent any issues with the new system from impacting them. This effectively further enhances the user experience. Furthermore, this new system's plug-in-based functional equivalence assessment eliminates the need to modify the new system's program code and container images, making it lightweight and non-invasive to the new system's program code and service runtime environment. This ensures minimal impact on the new system's reliability. Furthermore, developers can simply deploy the plug-in to perform the functional equivalence assessment in the new system, allowing them to execute the assessment. This makes implementation simple and controllable for developers, with easy integration and out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0080] The embodiment of the present application provides a method for evaluating the functional equivalence of system migration for the first system (old system). The method collects the traffic of a specified user in the old system during the evaluation period and replays the traffic in the new system (second system) to simulate the functional behavior of the old system. The result data of the new and old systems are compared to determine whether the functions of the new and old systems are consistent. The judgment result is used as the basis for judging whether the old system will switch the service request data of the specified user after the evaluation period to the new system. This method of performing the functional equivalence evaluation of the new and old systems by the plug-in of the old system includes a complete link of traffic collection, replay, comparison, and equivalence observation, which can guide the smooth migration solution of the new and old systems. At the same time, the solution is also lightweight. There is no need to modify the system code and container image, and there is no intrusion into the program code and service operating environment of the old system; therefore, it will not affect the reliability of the system. Furthermore, when developing a plug-in for evaluating functional equivalence, the developer only needs to deploy the plug-in in the old system and execute the evaluation scheme through the plug-in. Therefore, for the developer, the implementation is simple and controllable, the access is simple, it is ready to use out of the box, and the learning cost is low. Therefore, it can effectively improve the efficiency of system migration and enhance the user experience.

[0081] The system service method for the first system (old system) provided in the embodiment of the present application receives service request data from a user for a target service provided by the first system; if the user is a user of the target user group, and the target services provided by the first system and the second system respectively have functional equivalence to the target user group, the service request data is switched to the second system, and the service request data is processed by the second system; otherwise, the service request data is processed by the first system; wherein, whether the target services provided by the first system and the second system respectively have functional equivalence to the target user group is judged by the above-mentioned system migration functional equivalence evaluation method for the first system (old system). This processing method enables the old system to perceive in advance whether the new and old systems have functional equivalence before switching the flow to the specified user. If they have functional equivalence, the specified user is switched to the new system; therefore, the problem of system architecture reconstruction can be solved, ensuring that the new system is functionally equivalent to the old system, thereby ensuring the normal use of user functions after the system switch, and effectively improving the user experience. Furthermore, this functional equivalence assessment between the old and new systems, performed by a plug-in in the legacy system, eliminates the need to modify the legacy system's program code and container images, is non-invasive to the legacy system's program code and service runtime environment, and is lightweight; therefore, it does not impact the reliability of the legacy system. Furthermore, when developing a plug-in for functional equivalence assessment, developers simply deploy it in the legacy system to execute the assessment. This makes implementation simple and controllable for developers, with easy integration, out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0082] The embodiment of the present application provides a method for evaluating the functional equivalence of system migration for a second system (new system), which collects service request data of users of a target user group for a target service provided by the second system during a verification period, as well as third result data and third time data of the second system processing the service request data; sends the service request data to a first system, and collects fourth result data and fourth time data of the first system processing the service request data; and determines whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time data, and the fourth time data, and uses the determination result as a basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system. This approach allows for the functional equivalence of the old and new systems, as assessed by the old system before the switch, to be verified based on the actual usage of these designated users after switching them to the new system. If the new and old systems are found to be not functionally equivalent based on more actual usage, the new system can be directed to switch these designated users back to the old system to prevent the new system's problems from continuing to impact these users. This effectively further enhances the user experience. Furthermore, this approach, in which the new system's plug-in performs the functional equivalence evaluation of the old and new systems, encompasses a complete chain of traffic collection, playback, comparison, and equivalence observation, providing guidance for a smooth migration solution between the old and new systems. This solution is also lightweight, requiring no modification to system code or container images, and is non-invasive to the new system's program code and service operating environment. Therefore, it does not impact system reliability. Furthermore, when R&D personnel develop plug-ins for evaluating functional equivalence, they only need to deploy the plug-in in the new system to execute the evaluation plan through the plug-in. Therefore, for R&D personnel, the implementation is simple and controllable, the access is simple, it can be used out of the box, and the learning cost is low. Therefore, it can effectively improve the efficiency of system migration and enhance the user experience.

[0083] The system service method for the second system (new system) provided in the embodiment of the present application receives service request data from a user for a target service provided by the second system; if the user is a user of the target user group and the target services provided by the first system and the second system respectively do not have functional equivalence for the target user group, the service request data is switched to the first system and the service request data is processed by the first system; otherwise, the service request data is processed by the second system; wherein whether the target services provided by the first system and the second system respectively have functional equivalence for the target user group is determined by the above-mentioned system migration functional equivalence evaluation method for the second system (new system). With this processing method, after the designated user is switched to the new system, the evaluation result of whether the new and old systems are functionally equivalent for the designated user before the switch is verified based on more actual usage of this part of the designated user; if it is verified that the new and old systems are not functionally equivalent based on more actual usage, the new system will switch these designated users back to the old system to avoid the problem of the new system from continuing to affect these users; therefore, the user experience can be effectively further improved. Furthermore, this new system's plug-in, which performs the functional equivalence assessment between the old and new systems, eliminates the need to modify the new system's program code and container images, making it non-invasive to the new system's program code and service runtime environment, and is lightweight; therefore, it does not impact the reliability of the old system. Furthermore, when developing a plug-in for functional equivalence assessment, developers simply deploy it in the new system to execute the assessment. This makes implementation simple and controllable for developers, with easy integration and out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0084] The migration system provided by the embodiment of the present application includes: a first system migration device and a second system migration device. Before the old system switches the flow to the designated user, it can pre-sense whether the old and new systems have functional equivalence. If they have functional equivalence, the designated user will be switched to the new system, which can ensure the normal use of user functions after the system switch. After the designated user is switched to the new system, the evaluation results of whether the new and old systems have functional equivalence, which were evaluated by the old system for the designated user before the switch, can be verified based on more actual usage of this part of the designated users. If it is found that the new and old systems do not have functional equivalence based on more actual usage, these designated users will be switched back to the old system to prevent the problems of the new system from continuing to affect these users; therefore, the user experience can be effectively further improved. BRIEF DESCRIPTION OF THE DRAWINGS

[0085] Figure 1A schematic diagram of a flow chart of an embodiment of a system migration method provided in this application;

[0086] Figure 2 Schematic diagram of a scenario of an embodiment of the system migration method provided in this application;

[0087] Figure 3 A flowchart of an embodiment of a system migration method provided in this application. DETAILED DESCRIPTION

[0088] The following description sets forth many specific details to facilitate a thorough understanding of the present application. However, the present application can be implemented in many other ways than those described herein, and those skilled in the art can make similar generalizations without violating the scope of the present application. Therefore, the present application is not limited to the specific implementations disclosed below.

[0089] In this application, a method and apparatus for evaluating the functional equivalence of system migration, as well as an electronic device are provided. The following describes various solutions in detail in each embodiment.

[0090] First embodiment

[0091] Please refer to Figure 1 , which is a flow chart of the system migration method of the present application. In this embodiment, the method may include the following steps:

[0092] Step S101: Determine the target user group.

[0093] In this application, the old system before the transformation is referred to as the first system, and the new system after the transformation is referred to as the second system. The second system can be a new system formed by reconstructing the architecture of the first system, or it can be a new system formed by improving the internal application logic of the target service of the first system. The first system and the second system provide the same services, and the corresponding services of the two systems should have functional equivalence to ensure the normal use of user functions after the switch between the old and new systems (system migration).

[0094] like Figure 2 As shown, the system migration method for the first system provided in this embodiment can be executed by the system migration component in the first system, which is also called the traffic diversion component. In this embodiment, a grayscale migration method is adopted. During the grayscale migration process, part of the traffic or users are accessed through the second system in batches. Figure 2 It can be seen that before switching each batch of users to the second system, the system migration component first uses the plug-in of the first system to evaluate the functional equivalence of the target services provided by the first system and the second system respectively for the users of the batch.

[0095] In this application, the target user group can be any batch of users. The target user group includes one or more users. In specific implementations, a variety of methods can be used to determine the target user group. For example, specifying specific users is called a user whitelist; specifying certain user attributes, such as region, active or inactive users, etc. For example, if the user's region is specified as Hangzhou, the target user group includes all users in the Hangzhou area.

[0096] In specific implementation, the method may further include the following steps: determining a non-target user group, which may be called a user blacklist; determining the target user group, by: obtaining the target user group based on users outside the non-target user group.

[0097] In one example, the information of the target user group may be stored in a grayscale system migration configuration file. The method provided in this embodiment obtains the information of the target user group by reading the configuration file.

[0098] During implementation, the client can be configured to specify target user groups, such as user IDs and user attributes. The client then sends a target user group configuration request to the server, which stores the configuration parameters in the configuration file. During implementation, the target user characteristics for each batch can also be specified, allowing for automated system migration for each batch of users.

[0099] In another example, the target user group can be determined by using an algorithm based on the usage of the previous target user group after switching to the new system. This approach makes the target user group more reasonable.

[0100] Step S103: collecting, through the system plug-in, first service request data of users of the target user group for the target service provided by the first system during the evaluation period, as well as first result data and first time consumption data of the first system processing the first service request data; sending the first service request data to the second system, and collecting second result data and second time consumption data of the second system processing the first service request data; judging whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time consumption data and the second time consumption data.

[0101] like Figure 2As shown, in this embodiment, before migrating users in the target user group, the system migration component first calls the old system's plug-in to perform a functional equivalence assessment between the new and old systems. The plug-in then passes the assessment results to the system migration component. This allows the system migration component to pre-determine whether the new and old systems are functionally equivalent. If so, it then switches the designated users to the new system, ensuring that the new system is functionally equivalent to the old system and that users can use the same functions after the system switch.

[0102] Using system plug-ins to perform functional equivalence assessments between the old and new systems eliminates the need to modify the old system's program code and container images, and is non-invasive to the old system's program code and service operating environment, without impacting the old system's reliability. This approach is also lightweight, requiring no server-side processing support and without impacting the old system's performance. For R&D personnel, after developing the system plug-in, they simply deploy it in the old system to execute the assessment plan. This makes implementation simple and controllable, with easy access, out-of-the-box usability, and a low learning curve, effectively improving system migration efficiency and enhancing user experience.

[0103] In specific implementation, the starter mechanism of SpringBoot can be used to create the plug-in, which has the characteristics of pluggable and out-of-the-box use. The application system is relatively simple to access, and the Maven coordinates can be introduced.

[0104] The following is a detailed description of the system plug-in processing process, which includes three steps.

[0105] In step 1, the system plug-in collects first service request data of users in the target user group for the target service provided by the first system during the evaluation period, as well as first result data and first time consumption data of the first system processing the first service request data.

[0106] The first service request is a request from a user of the first system and is a normal request of the first system. The content of the request protocol is intercepted for normal requests of the first system. In specific implementations, the intercepted request content can be recorded and stored for use in other applications.

[0107] like Figure 2 As shown, a functional equivalence evaluation period is usually set for the target user group, such as 3 days or 6 hours, etc. The system plug-in collects the first service request data of users in the target user group during the corresponding evaluation period.

[0108] In one example, the system plug-in collects the first service request data, the first result data and the first time-consuming data, which can be achieved in the following way: using aspect-oriented programming, the first application program interface of the target service entrance of the first system is intercepted to collect the first service request data, the first result data and the first time-consuming data. Using the aspect-oriented programming (AOP) mechanism, the service entrance API (or directory, annotation markup class) of the first system is intercepted to collect the traffic of the first system. Using this processing method, not only the first service request data (including the input parameters of the service entrance API interface, referred to as interface input parameters) can be collected, but also the interface output parameters (first result data) obtained after the service entrance API interface is processed according to the input parameters, and the execution time of the API interface (first interface time-consuming) can be collected. In addition, this processing method is non-invasive to the system program code, and is simple and controllable for R&D personnel.

[0109] During specific implementation, the input parameters of the service entry API interface (the first service request data) can be obtained through ProceedingJoinPoint; the return value of executing proceedingJoinPoint.proceed() is the interface output parameter; timing can be performed before executing the proceedingJoinPoint.proceed() method, and after execution, the time difference can be calculated to obtain the interface time consumption.

[0110] In one example, the system plug-in collects the first service request data, which can be implemented in the following manner: collecting the first service request data that meets the traffic collection condition.

[0111] During specific implementation, collecting first service request data that meets the traffic collection conditions can be achieved as follows: First service request data is collected based on a traffic sampling rate. During specific implementation, traffic can be randomly sampled according to the sampling rate. The sampling rate refers to the ratio of the number of sampled traffic flows per unit time to the total traffic flow of all requests per unit time. Due to the high volume of traffic on user lines, collecting all traffic flows would affect the normal operation of the first system. By sampling the traffic of the first system, the consumption of the first system's performance can be effectively controlled, achieving low consumption, safety, and reliability. During specific implementation, controlling the sampling rate to a lower level can effectively control the stability of system performance.

[0112] During specific implementation, the sampling rate of the service level can be set to effectively solve the situation where the proportion of traffic from different services varies greatly.

[0113] In actual applications, the first system can provide one or more services. In one example, it is possible to specify which services are to be processed for system migration. This processing method allows different systems to provide different services to the same user. For example, the first system provides service A to the user, and the second system provides service B to the same user. In this case, collecting first service request data that meets the traffic collection conditions can be achieved as follows: for different specified services, the first service request data for the specified service is collected separately. For example, if services A and B are specified, the first service request data for services A and B will be collected.

[0114] In a specific implementation, the method may further include the following steps: determining non-target services; and using services other than the non-target services as the target services. This processing method eliminates the functional equivalence evaluation process for non-target services.

[0115] Step 2: Send the first service request data to the second system, and collect second result data and second time consumption data of the second system processing the first service request data.

[0116] After the traffic collection of the target service in the first system is completed, traffic replay is performed on the target service in the second system based on the collected input parameters. Traffic replay refers to resending the previously recorded network traffic data to the network to simulate the network traffic in a real environment. The method provided in the embodiment of the present application adopts a directional playback traffic method. Directional playback means that the playback has a directionality. In this embodiment, the traffic of the old system (first system) is collected and replayed to the new system (second system).

[0117] During specific implementation, the aspect-oriented programming (AOP) mechanism can also be used to intercept the service entry API (or directory, annotation markup class) of the second system to achieve traffic collection of the second result data and the second time-consuming data.

[0118] In practice, before replaying traffic to the second system, the playback time can be recorded to facilitate comparison with the service interface performance time of the first system. Before replaying, a short sleep period can also be set to allow time for data synchronization.

[0119] In addition, you can also specify the playback direction. If the current traffic collected is the traffic of the first system, the playback direction is the second system, otherwise the opposite is true. If it is a system migration component (stream switching component) implemented through AOP, the playback direction is specified by ThreadLocal, set to the stream switching component, and consumed by the stream switching component. The stream switching component will perform interface routing in the specified direction. When executing playback, if you combine the AOP stream switching component for playback, execute proceedingJoinPoint.proceed() again. After playback, you can perform cleanup work, calculate the total time consumed for stream switching playback, and clean up the ThreadLocal context.

[0120] In one example, the first service request data may be sent to the second system by using an asynchronous playback method, which does not block normal traffic on the first system.

[0121] In one example, sending the first service request data to the second system can be achieved by setting thread pool parameters; and sending the first service request data to the second system through the thread pool. This processing method allows the consumption of system performance to be controlled by setting thread pool parameters, thereby achieving low consumption, safety and reliability. For example, by using the ExecutorService thread pool, the loss of system performance caused by traffic playback can be reduced by controlling the configuration of thread pool parameters, thereby achieving low consumption, safety and reliability. For example, the thread pool parameters are set to: number of threads: 4, thread pool size: 1000, timeout: 60 seconds.

[0122] During specific implementation, important thread contexts can be recorded and restored, including important information such as the traceId passed, the flow direction (such as flow switching from the first system to the second system, or from the second system to the first system), and other important information.

[0123] Step three: judging whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time consumption data, and the second time consumption data.

[0124] Functional equivalence means that for the API interfaces of the corresponding services of the new and old systems, if the input parameters are the same, the returned results are exactly the same, and the interface time difference is small, with almost no impact on the application and can be ignored, then the two new and old API interfaces are said to meet the equivalence.

[0125] In specific implementations, whether the corresponding services of the first and second systems are functionally equivalent can be determined by whether the entry API interfaces of the corresponding services of the first and second systems respond with the same output parameters and side effects (such as stateful storage) under the same input parameters. In specific implementations, the high-performance FastJSON tool can be used to compare the response result objects (first result data and second result data).

[0126] In specific implementation, the processing of a service can be composed of multiple API interfaces, or all API interfaces under the service can meet the equivalence, which is called the equivalence of the function.

[0127] In specific implementation, step three may include the following sub-steps: 3.1) Based on the first result data, the second result data, the first time consumption data and the second time consumption data, determine whether the target services provided by the first system and the second system are functionally equivalent to the first service request data; 3.2) Based on the functional equivalence judgment results corresponding to multiple first service request data of users of the target user group, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group.

[0128] In specific implementation, step 3.2 can be achieved in the following manner: based on the functional equivalence judgment result corresponding to the first service request data, obtain the first service request ratio of the target services provided by the first system and the second system that are functionally equivalent to the target user group; if the first service request ratio meets the conditions, such as the ratio of first service requests with functional equivalence reaches 95%, it is determined that the target services provided by the first system and the second system are functionally equivalent to the target user group.

[0129] In specific implementations, the output data of step 3.1 may include the result data and time consumption data of the functional equivalence evaluation for a first service request, as well as the functional equivalence evaluation results. This comparison data can be stored on the server. The server can store the comparison data in a structured log, which can be used to monitor the overall system and generate functional consistency comparison alerts. Subsequently, this log can be configured to the stability monitoring platform for statistics, overall system configuration, and alert generation. Interfaces with inconsistent results need to be individually troubleshooted and resolved.

[0130] During specific implementation, the structured log may include the following contents: 1) comparison result mark: true indicates that the comparison results are the same and the functions are equivalent; fall indicates that the comparison is different and the functions are not equivalent; error indicates that an exception occurs during the comparison; 2) the name of the comparison service (target service); 3) the first time-consuming data of calling the first system interface; 4) the time-consuming data of replaying the interface of the second system, and the second time-consuming data; 5) the input parameters of the interface, and the content of the first service request; 6) the interface return value of the first system, and the first result data; 7) the interface return value of the second system, and the second result data.

[0131] In practice, if the results are identical (i.e., the corresponding services in the first and second systems are functionally equivalent), there is no need to log the input parameters and return values ​​of the API interface during execution. This approach can effectively improve system performance.

[0132] In one example, the method further includes determining a comparison indicator. The result comparison in step 3 can be implemented by determining whether the comparison indicator data in the first result data and the second result data are identical based on the comparison indicator data. The comparison indicator can be a comparison indicator without a path or a comparison indicator with a path, such as $.phoneNumbers[0:].type. This processing method reduces noise during the result comparison process and ignores unimportant result data.

[0133] In specific implementation, you can use the API corresponding to the fastJSON tool to remove comparison indicators, JSONPath.remove(source,ignorePropertyPath); and use source.equa ls(target) for comparison. The fastJSON object will override the equa ls method to perform recursive comparison of complex models.

[0134] In specific implementation, a comparison index can be set for the API interface of the target service in the configuration file. The comparison index of the obtained result data can be implemented in the following way: obtaining the comparison index from the configuration file.

[0135] In one example, the system plug-in captures an exception in the step of determining whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time consumption data, and the second time consumption data; if an exception is captured, the exception information is stored.

[0136] In specific implementations, exceptions during the result comparison phase may be caused by changes in the return values ​​of the entry APIs for the target services provided by the first and second systems, respectively. For example, the return values ​​of the same entry API in both systems may include a certain field, but the data types of the two fields may be different. Another example is that the return values ​​of the same entry API in the two systems may differ: the old system's return value includes two data items, while the new system's return value excludes one. This approach ensures the normal operation of the first system, preventing exceptions from being thrown. It also records exception information, which developers can use to troubleshoot the cause of the problem.

[0137] In one example, the method may further include the steps of: determining whether to activate the plug-in; and if the plug-in is activated, collecting the first service request data via the system plug-in. This approach allows for the immediate deactivation of the plug-in if performance or other issues arise with the system plug-in, enabling timely stability degradation. This approach is simple, transparent, easily controllable, secure, and reliable, suitable for use in production environments.

[0138] It should be noted that if the traffic of the first system is the traffic being replayed, the subsequent method of replay is not performed, and there is no need to re-collect the replayed traffic. After the target user is migrated to the second system, the service request of the target user to the second system is called a second service request.

[0139] Step S105: If it is determined that there is functional equivalence for the target user group, the service request data of the users of the target user group after the evaluation period is switched to the second system.

[0140] If the system plug-in determines that the corresponding services of the first and second systems are functionally equivalent, the first system can be smoothly migrated to the second system. The system migration is transparent to the user, and the user cannot perceive the functional differences between the second and first systems. If the determination result is that the corresponding functions of the first and second systems are not functionally equivalent, the first system cannot be smoothly migrated to the second system, and the user can perceive the functional differences between the second and first systems.

[0141] In one example, the method may further include the step of displaying abnormality alarm information related to the functional equivalence evaluation. This abnormality alarm information includes, but is not limited to, alarm information indicating that the corresponding services of the first and second systems are not functionally equivalent, alarm information indicating that an abnormality has occurred during the functional equivalence evaluation process, and alarm information indicating that the performance of the functional equivalence evaluation is time-consuming. This processing method can implement functional equivalence alarms. In specific implementations, the alarms can be sent to system developers' alarm groups or SMS channels.

[0142] In a specific implementation, displaying abnormal alarm information of functional equivalence evaluation may include: if it is determined that the corresponding services of the first system and the second system are not functionally equivalent, then displaying alarm information that the corresponding services of the first system and the second system are not functionally equivalent.

[0143] In one example, the method may further include the following steps: obtaining the processing time of step 3; and displaying a performance time alarm message for the functional equivalence evaluation if the processing time exceeds a time threshold. The time threshold may be set based on application requirements.

[0144] In one example, the method may further include the following steps: obtaining statistical data of functional equivalence evaluation; and displaying the statistical data. The statistical data includes at least one of the following data: the total number of service request playbacks, the number of functionally equivalent service requests, the number of functionally inequal service requests, and the number of abnormal service requests compared with the results. In addition, the dashboard monitoring data may also include: equivalence performance comparison, such as the interface time (ms) of the second system (new system), the interface time (ms) of the first system (old system), and the increase in the interface time of the new and old systems (such as: an increase in time of 30%, or -30%). In specific implementation, the following calculation formula may be used: (${new system time}-${old system time}) / ${old system time}*100%. Furthermore, the dashboard monitoring data may also include: comparison of abnormal situations, such as abnormal error codes, which can facilitate problem troubleshooting.

[0145] After the system plug-in generates a structured log of the comparison results, it transmits the log to the log platform to facilitate problem location and troubleshooting. At the same time, the log is connected to the monitoring platform and the corresponding monitoring dashboard is configured for global equivalence observation before traffic switching (system migration). Traffic switching is enabled only after all equivalence indicators are normal, thereby globally controlling traffic switching risks.

[0146] As can be seen from the above embodiments, the system migration method for the first system (old system) provided in the embodiments of the present application determines the target user group; collects the first service request data of the users of the target user group for the target service provided by the first system during the evaluation period through the system plug-in, as well as the first result data and first time data of the first system processing the first service request data; sends the first service request data to the second system (new system), and collects the second result data and second time data of the second system processing the first service request data; judges whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time data and the second time data; if it is determined that they are functionally equivalent to the target user group, the service request data of the users of the target user group after the evaluation period is switched to the second system. This approach allows the old system to pre-determine whether the new and old systems are functionally equivalent before switching a specific user. If so, the user is then switched to the new system. This resolves the issue of system architecture reconstruction, ensuring that the new system is functionally equivalent to the old system, thus guaranteeing the normal functioning of user functions after the system switch, effectively improving the user experience. Furthermore, this functional equivalence assessment between the old and new systems, performed by a plug-in in the old system, eliminates the need to modify the old system's program code and container images, is lightweight and non-invasive to the old system's program code and service runtime environment, and therefore does not impact the old system's reliability. Furthermore, developers developing plug-ins for functional equivalence assessments simply deploy them in the old system to execute the assessment. This makes implementation simple and controllable for developers, with easy integration, out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0147] Second embodiment

[0148] In the above-mentioned embodiment, a system migration method for a first system is provided. Correspondingly, this application also provides a system migration device for the first system. This device corresponds to the above-mentioned method embodiment. Since the device embodiment is substantially similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the description of the method embodiment. The device embodiment described below is merely illustrative.

[0149] The present application further provides a system migration device for a first system, comprising:

[0150] A user setting unit, used to determine a target user group;

[0151] a system plug-in configured to collect first service request data of users of the target user group for a target service provided by the first system during an evaluation period, as well as first result data and first time consumption data of the first system processing the first service request data; send the first service request data to a second system, and collect second result data and second time consumption data of the second system processing the first service request data; and determine, based on the first result data, the second result data, the first time consumption data, and the second time consumption data, whether the target services provided by the first system and the second system are functionally equivalent for the target user group;

[0152] A user switching unit is configured to switch the service request data of users of the target user group after the evaluation period to the second system if it is determined that the system has functional equivalence to the target user group.

[0153] Third embodiment

[0154] In the above embodiment, a system migration method for a first system is provided. Correspondingly, this application also provides a system migration method for a second system. This method corresponds to the above method embodiment. Since this method embodiment is substantially similar to the first method embodiment, its description is relatively brief. For relevant details, please refer to the description of the first method embodiment. The following method embodiment is merely illustrative.

[0155] This application also provides a system migration for the second system. Figure 3 , which is a flow chart of the system migration method of the present application, the method comprising the following steps:

[0156] Step S301: Acquire a target user group.

[0157] After the system migration component of the first system switches designated users to the second system, these users may experience more extensive system usage, which did not occur during the functional equivalence evaluation of the first system. Therefore, the previous evaluation results were based on incomplete information, which may cause problems for these users when using the second system.

[0158] The method provided in this embodiment is that the second system can verify whether the new and old systems have functional equivalence based on more actual usage of these designated users, as evaluated by the first system for designated users before system migration. If it is verified that the new and old systems are not functionally equivalent based on more actual usage, these designated users must be switched back to the old system to prevent problems with the new system from continuing to affect these users. Therefore, the method provided in this embodiment first obtains the target user group and verifies the previous functional equivalence evaluation results of the target user group. In specific implementation, the second system can obtain the information of the target user group from the configuration file.

[0159] Step S303: collecting, through the system plug-in, the second service request data of the users of the target user group for the target service provided by the second system during the verification period, as well as the third result data and the third time data of the second system processing the second service request data; sending the second service request data to the first system, and collecting the fourth result data and the fourth time data of the first system processing the second service request data; judging whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time data and the fourth time data.

[0160] This step is basically similar to step S103 of the first embodiment, and the similarities are not repeated here. The difference is that the system plug-in of this embodiment is deployed in the second system, while the system plug-in of the first embodiment is deployed in the first system. In addition, the plug-in of the first system collects the traffic of the target user group during the evaluation period, and the traffic playback direction is from the first system to the second system. The plug-in of the second system collects the traffic of the target user group during the verification period, and the traffic playback direction is from the second system to the first system.

[0161] Step S305: If it is determined that there is no functional equivalence for the target user group, subsequent service request data of users of the target user group is switched to the first system.

[0162] In a specific implementation, the method may further include the step of determining whether the service request data received by the second system is the second service request data. This processing method allows the plug-in of the second system to determine which service requests are second service requests from users of the second system and which service requests are first service requests replayed by the plug-in of the first system, thereby preventing the plug-in of the second system from collecting first service requests. Therefore, the accuracy of the functional equivalence assessment performed by the second system can be effectively improved.

[0163] As can be seen from the above embodiments, the system migration method for the second system (new system) provided in the embodiments of the present application obtains a target user group; collects, through a system plug-in, the second service request data of the users of the target user group for the target service provided by the second system during the verification period, as well as the third result data and third time data of the second system processing the second service request data; sends the second service request data to the first system, and collects the fourth result data and fourth time data of the first system processing the second service request data; determines whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time data and the fourth time data; if it is determined that they are not functionally equivalent to the target user group, the subsequent service request data of the users of the target user group is switched to the first system. This approach allows for the functional equivalence of the old and new systems, assessed by the old system before the switchover, to be verified based on their actual usage. If the new and old systems are found to be not functionally equivalent based on more actual usage, these users are switched back to the old system to prevent any issues with the new system from impacting them. This effectively further enhances the user experience. Furthermore, this new system's plug-in-based functional equivalence assessment eliminates the need to modify the new system's program code and container images, making it lightweight and non-invasive to the new system's program code and service runtime environment. This ensures minimal impact on the new system's reliability. Furthermore, developers can simply deploy the plug-in to perform the functional equivalence assessment in the new system, allowing them to execute the assessment. This makes implementation simple and controllable for developers, with easy integration and out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0164] Fourth embodiment

[0165] In the above-mentioned embodiments, a system migration method is provided. Correspondingly, this application also provides a system migration device, deployed on the second system side. This device corresponds to the above-mentioned method embodiment. Since the device embodiment is substantially similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the description of the method embodiment. The device embodiment described below is merely illustrative.

[0166] The present application further provides a system migration device, the device comprising:

[0167] A user acquisition unit, used to acquire a target user group;

[0168] a system plug-in configured to collect second service request data of users of the target user group for a target service provided by the second system during a verification period, as well as third result data and third time consumed by the second system in processing the second service request data; send the second service request data to the first system, and collect fourth result data and fourth time consumed by the first system in processing the second service request data; and determine, based on the third result data, the third result data, the fourth time consumed data, and the fourth time consumed data, whether the target services provided by the first system and the second system are functionally equivalent for the target user group;

[0169] The user flow switching unit is configured to switch the service request data of users of the target user group to the first system if it is determined that there is no functional equivalence for the target user group.

[0170] Fifth embodiment

[0171] In the above-mentioned embodiment, a system migration method is provided. Correspondingly, this application also provides a method for evaluating the functional equivalence of system migration for a plug-in of a first system. This method corresponds to the above-mentioned method embodiment. Since this method embodiment is substantially similar to the first method embodiment, its description is relatively simple. For relevant details, please refer to the partial description of the first method embodiment. The method embodiment described below is merely illustrative.

[0172] The present application further provides a method for evaluating system migration functional equivalence of a plug-in for a first system, comprising the following steps:

[0173] Step 1: Collect service request data of users of the target user group for the target service provided by the first system during an evaluation period, as well as first result data and first time consumption data of the first system processing the service request data.

[0174] This step corresponds to step 1 of embodiment 1 and will not be described again here.

[0175] Step 2: Send the service request data to the second system, and collect second result data and second time consumption data of the second system processing the service request data.

[0176] This step corresponds to step 2 of Example 1 and will not be repeated here.

[0177] Step 3: Based on the first result data, the second result data, the first time consumption data and the second time consumption data, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and use this judgment result as the basis for determining whether the first system switches the service request data of users of the target user group after the evaluation period to the second system.

[0178] This step corresponds to step 3 of Example 1 and will not be described again here.

[0179] As can be seen from the above embodiments, the system migration functional equivalence evaluation method for the first system (old system) provided in the embodiment of the present application collects the traffic of the designated user in the old system during the evaluation period, and replays the traffic in the new system (second system) to simulate the functional behavior of the old system; the result data of the old and new systems are compared to determine whether the functions of the old and new systems are consistent, and the judgment result is used as the basis for determining whether the old system switches the service request data of the designated user after the evaluation period to the new system. This method of performing functional equivalence evaluation processing of the old and new systems by the plug-in of the old system, including the complete link of traffic collection, playback, comparison, and equivalence observation, can guide the smooth migration solution of the old and new systems. At the same time, the solution is also lightweight, does not require the modification of system code and container images, and does not invade the program code and service operating environment of the old system; therefore, it will not affect the reliability of the system. Furthermore, when R&D personnel develop plug-ins for evaluating functional equivalence, they only need to deploy the plug-in in the old system to execute the evaluation plan through the plug-in. Therefore, for R&D personnel, the implementation is simple and controllable, the access is simple, it can be used out of the box, and the learning cost is low. Therefore, it can effectively improve the efficiency of system migration and enhance the user experience.

[0180] Sixth embodiment

[0181] In the above-mentioned embodiment, a method for evaluating the equivalence of system migration functions is provided. Correspondingly, this application also provides a system plug-in. This plug-in corresponds to the above-mentioned method embodiment. Since this plug-in embodiment is substantially similar to the first method embodiment, its description is relatively simple. For relevant details, please refer to the partial description of the first method embodiment. The plug-in embodiment described below is merely illustrative.

[0182] This application also provides a system plug-in, including:

[0183] a traffic collection unit, configured to collect service request data of users of a target user group for a target service provided by the first system during an evaluation period, and first result data and first time consumption data of the first system processing the service request data;

[0184] a traffic replay unit, configured to send the service request data to the second system, and collect second result data and second time consumption data of processing the service request data by the second system;

[0185] A result comparison unit is used to determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time consumption data and the second time consumption data, and use the judgment result as a basis for determining whether the first system switches the service request data of users of the target user group after the evaluation period to the second system.

[0186] Seventh embodiment

[0187] In the above embodiment, a system migration method is provided. Correspondingly, this application also provides a system service method for a first system. This method corresponds to the above method embodiment. Since this method embodiment is substantially similar to the first method embodiment, its description is relatively brief. For relevant details, please refer to the description of the first method embodiment. The following method embodiment is merely illustrative.

[0188] The present application further provides a system service method for a first system, comprising the following steps:

[0189] Step 1: Receive service request data from a user for a target service provided by the first system.

[0190] The service request data is the same as the first service request data in the first embodiment. The method provided in this embodiment is a specific solution for processing the first service request when providing the target service externally from the first system.

[0191] Step 2: If the user is a member of the target user group and the target services provided by the first system and the second system are functionally equivalent for the target user group, the service request data is switched to the second system and processed by the second system. Otherwise, the service request data is processed by the first system.

[0192] This step is equivalent to step S105 of the first embodiment and will not be described again here.

[0193] Whether the target services provided by the first system and the second system respectively have functional equivalence for the target user group is determined by using step S103 of the method provided in the first embodiment.

[0194] As can be seen from the above embodiments, the system service method for the first system (old system) provided in the embodiment of the present application receives service request data from a user for a target service provided by the first system; if the user is a user of the target user group, and the target services provided by the first system and the second system respectively have functional equivalence for the target user group, the service request data is switched to the second system, and the service request data is processed by the second system; otherwise, the service request data is processed by the first system; wherein, whether the target services provided by the first system and the second system respectively have functional equivalence for the target user group is judged by the above-mentioned system migration functional equivalence evaluation method for the first system (old system). By adopting this processing method, the old system can pre-perceive whether the new and old systems have functional equivalence before switching the flow to the specified user. If they have functional equivalence, the specified user is switched to the new system; therefore, the system architecture reconstruction problem can be solved, ensuring that the new system is functionally equivalent to the old system, thereby ensuring the normal use of user functions after the system switch, and effectively improving the user experience. Furthermore, this functional equivalence assessment between the old and new systems, performed by a plug-in in the legacy system, eliminates the need to modify the legacy system's program code and container images, is non-invasive to the legacy system's program code and service runtime environment, and is lightweight; therefore, it does not impact the reliability of the legacy system. Furthermore, when developing a plug-in for functional equivalence assessment, developers simply deploy it in the legacy system to execute the assessment. This makes implementation simple and controllable for developers, with easy integration, out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0195] Eighth embodiment

[0196] In the above-mentioned embodiment, a system service method is provided. Correspondingly, this application also provides a system service device, deployed on the first system side. This device corresponds to the above-mentioned method embodiment. Since the device embodiment is substantially similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the description of the method embodiment. The device embodiment described below is merely illustrative.

[0197] The present application further provides a system service device, the device comprising:

[0198] a request receiving unit, configured to receive service request data from a user for a target service provided by the first system;

[0199] a user flow switching unit configured to, if the user is a user of the target user group and the target services provided by the first system and the second system respectively have functional equivalence for the target user group, switch the first service request data to the second system and process the service request data via the second system; otherwise, activate a request processing unit;

[0200] The request processing unit is configured to process the service request data through the first system;

[0201] Whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group is determined by using the method provided in the fifth embodiment.

[0202] Ninth embodiment

[0203] In the above-mentioned embodiment, a system migration method is provided. Correspondingly, this application also provides a method for evaluating the functional equivalence of system migration for a plug-in in a second system. This method corresponds to the above-mentioned method embodiment. Since this method embodiment is substantially similar to the first method embodiment, its description is relatively brief. For relevant details, please refer to the partial description of the first method embodiment. The method embodiment described below is merely illustrative.

[0204] This application further provides a method for evaluating system migration functionality equivalence of a plug-in for a second system, comprising the following steps:

[0205] Step 1: Collect service request data of users of the target user group for the target service provided by the second system during the verification period, as well as third result data and third time consumption data of the second system processing the service request data.

[0206] This step corresponds to step 1 of Example 2 and will not be repeated here.

[0207] Step 2: Send the service request data to the first system, and collect fourth result data and fourth time consumption data of the first system processing the service request data.

[0208] This step corresponds to step 2 of the second embodiment and will not be described again here.

[0209] Step 3: Based on the third result data, the fourth result data, the third time-consuming data and the fourth time-consuming data, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and use the judgment result as the basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system.

[0210] This step corresponds to step 3 of the second embodiment and will not be described again here.

[0211] It can be seen from the above embodiments that the system migration functional equivalence evaluation method for the second system (new system) provided in the embodiments of the present application collects service request data of users of the target user group for the target service provided by the second system during the verification period, as well as third result data and third time data of the second system processing the service request data; sends the service request data to the first system, and collects fourth result data and fourth time data of the first system processing the service request data; based on the third result data, the fourth result data, the third time data and the fourth time data, determines whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and uses the judgment result as a basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system. This approach allows for the functional equivalence of the old and new systems, as assessed by the old system before the switch, to be verified based on the actual usage of these designated users after switching them to the new system. If the new and old systems are found to be not functionally equivalent based on more actual usage, the new system can be directed to switch these designated users back to the old system to prevent the new system's problems from continuing to impact these users. This effectively further enhances the user experience. Furthermore, this approach, in which the new system's plug-in performs the functional equivalence evaluation of the old and new systems, encompasses a complete chain of traffic collection, playback, comparison, and equivalence observation, providing guidance for a smooth migration solution between the old and new systems. This solution is also lightweight, requiring no modification to system code or container images, and is non-invasive to the new system's program code and service operating environment. Therefore, it does not impact system reliability. Furthermore, when R&D personnel develop plug-ins for evaluating functional equivalence, they only need to deploy the plug-in in the new system to execute the evaluation plan through the plug-in. Therefore, for R&D personnel, the implementation is simple and controllable, the access is simple, it can be used out of the box, and the learning cost is low. Therefore, it can effectively improve the efficiency of system migration and enhance the user experience.

[0212] Tenth embodiment

[0213] In the above-mentioned embodiment, a method for evaluating the equivalence of system migration functions is provided. Correspondingly, this application also provides a system plug-in. This plug-in corresponds to the above-mentioned method embodiment. Since this plug-in embodiment is substantially similar to the first method embodiment, its description is relatively simple. For relevant details, please refer to the partial description of the first method embodiment. The plug-in embodiment described below is merely illustrative.

[0214] This application also provides a system plug-in, including:

[0215] a traffic collection unit, configured to collect service request data of users of the target user group for the target service provided by the second system during the verification period, and third result data and third time consumption data of the second system processing the service request data;

[0216] a traffic replay unit, configured to send the service request data to the first system, and collect fourth result data and fourth time consumption data of the first system processing the service request data;

[0217] A result comparison unit is used to determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time-consuming data, and the fourth time-consuming data, and use the judgment result as a basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system.

[0218] Eleventh embodiment

[0219] In the above embodiment, a system migration method is provided. Correspondingly, this application also provides a system service method for a second system. This method corresponds to the above method embodiment. Since this method embodiment is substantially similar to the first method embodiment, its description is relatively simple. For relevant details, please refer to the description of the first method embodiment. The following method embodiment is merely illustrative.

[0220] The present application further provides a system service method for a second system, comprising the following steps:

[0221] Step 1: Receive service request data from a user for a target service provided by the second system.

[0222] The service request data is the same as the second service request data in the second embodiment. The method provided in this embodiment is a specific solution for processing the second service request when the second system provides the target service externally.

[0223] Step 2: If the user is a user of the target user group and the target services provided by the first system and the second system respectively are not functionally equivalent to the target user group, the service request data is switched to the first system and processed by the first system; otherwise, the service request data is processed by the second system.

[0224] This step is equivalent to step S105 of the second embodiment and will not be described again here.

[0225] Whether the target services provided by the first system and the second system respectively have functional equivalence for the target user group is determined by using step S303 of the method provided in the second embodiment.

[0226] As can be seen from the above embodiments, the system service method for the second system (new system) provided in the embodiment of the present application receives service request data from a user for a target service provided by the second system; if the user is a user of the target user group and the target services provided by the first system and the second system respectively do not have functional equivalence for the target user group, the service request data is switched to the first system and the service request data is processed by the first system; otherwise, the service request data is processed by the second system; wherein whether the target services provided by the first system and the second system respectively have functional equivalence for the target user group is determined by the above-mentioned system migration functional equivalence evaluation method for the second system (new system). With this processing method, after the designated user is switched to the new system, the evaluation result of whether the new and old systems are functionally equivalent to the designated user before the switch can be verified based on more actual usage of this part of the designated user; if it is verified that the new and old systems are not functionally equivalent based on more actual usage, the new system will switch these designated users back to the old system to avoid the problem of the new system from continuing to affect these users; therefore, the user experience can be effectively further improved. Furthermore, this new system's plug-in, which performs the functional equivalence assessment between the old and new systems, eliminates the need to modify the new system's program code and container images, making it non-invasive to the new system's program code and service runtime environment, and is lightweight; therefore, it does not impact the reliability of the old system. Furthermore, when developing a plug-in for functional equivalence assessment, developers simply deploy it in the new system to execute the assessment. This makes implementation simple and controllable for developers, with easy integration and out-of-the-box usability, and a low learning curve. This effectively improves system migration efficiency and enhances the user experience.

[0227] Twelfth embodiment

[0228] In the above-mentioned embodiments, a system service method is provided. Correspondingly, this application also provides a system service device, deployed on the second system side. This device corresponds to the above-mentioned method embodiment. Since the device embodiment is substantially similar to the method embodiment, the description is relatively simple. For relevant details, please refer to the description of the method embodiment. The device embodiment described below is merely illustrative.

[0229] The present application further provides a system service device, the device comprising:

[0230] a request receiving unit, configured to receive service request data from a user for a target service provided by the second system;

[0231] a user flow switching unit configured to, if the user is a user of a target user group and the target services provided by the first system and the second system are not functionally equivalent for the target user group, switch the service request data to the first system and process the service request data via the first system; otherwise, activate a request processing unit;

[0232] The request processing unit is configured to process the service request data through the second system;

[0233] Wherein, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group is determined by using the method provided in the ninth embodiment.

[0234] Thirteenth embodiment

[0235] In the above-mentioned embodiments, a system migration method is provided. Correspondingly, this application also provides a migration system. This system corresponds to the above-mentioned method embodiments. Since the system embodiments are generally similar to the method embodiments, the description is relatively simple. For relevant details, please refer to the description of the method embodiments. The system embodiments described below are merely illustrative.

[0236] The migration system of this embodiment includes: a first system migration device constructed by the method provided in the above embodiment 1, that is, the system migration device provided in the second embodiment; and also includes: a second system migration device constructed by the method provided in the above embodiment 3, that is, the system migration device provided in the fourth embodiment.

[0237] The migration system provided by the embodiment of the present application includes: a first system migration device and a second system migration device. Before the old system switches the flow to the designated user, it can pre-sense whether the old and new systems have functional equivalence. If they have functional equivalence, the designated user will be switched to the new system, which can ensure the normal use of user functions after the system switch. After the designated user is switched to the new system, the evaluation results of whether the new and old systems have functional equivalence, which were evaluated by the old system for the designated user before the switch, can be verified based on more actual usage of this part of the designated users. If it is found that the new and old systems do not have functional equivalence based on more actual usage, these designated users will be switched back to the old system to prevent the problems of the new system from continuing to affect these users; therefore, the user experience can be effectively further improved.

[0238] Fourteenth embodiment

[0239] In the above-mentioned embodiments, a method for evaluating the functional equivalence of system migration is provided. Correspondingly, this application also provides an electronic device. This device corresponds to the above-mentioned method embodiments. Since the device embodiments are substantially similar to the method embodiments, the description is relatively simple. For relevant details, please refer to the description of the method embodiments. The device embodiments described below are merely illustrative.

[0240] The electronic device of this embodiment includes: a processor; and a memory. The memory is configured to store a program for implementing the method provided by any of the above method embodiments, and the processor is configured to execute the program stored in the memory. For detailed descriptions, please refer to the above method embodiments and will not be repeated here.

[0241] Fifteenth embodiment

[0242] In the above embodiments, a method for processing data from heterogeneous data sources is provided. Accordingly, this application also provides a computer-readable storage medium. This storage medium corresponds to the above method embodiments. Since the storage medium embodiments are substantially similar to the method embodiments, their description is relatively brief. For relevant details, please refer to the description of the method embodiments. The storage medium embodiments described below are merely illustrative.

[0243] The computer-readable storage medium of this embodiment stores instructions that, when executed on a computer, cause the computer to execute the method provided in any of the above method embodiments. For details, please refer to the above method embodiments and will not be repeated here.

[0244] Sixteenth embodiment

[0245] In the above embodiments, a method for processing data from heterogeneous data sources is provided. Correspondingly, this application also provides a computer program product. This product corresponds to the above method embodiments. Since the product embodiments are generally similar to the method embodiments, the description is relatively simple. For relevant details, please refer to the description of the method embodiments. The product embodiments described below are merely illustrative.

[0246] The computer program product of this embodiment, when executed on a computer, enables the computer to execute the method provided by any of the above method embodiments. Detailed descriptions can be found in the above method embodiments and will not be repeated here.

[0247] Although the present application is disclosed as above with the preferred embodiments, it is not intended to limit the present application. Any person skilled in the art may make possible changes and modifications without departing from the spirit and scope of the present application. Therefore, the scope of protection of the present application shall be based on the scope defined by the claims of the present application.

[0248] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0249] Memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0250] 1. Computer-readable media includes permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer-readable instructions, data structures, program modules, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include non-transitory computer-readable media, such as modulated data signals and carrier waves.

[0251] 2. Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems, or computer program products. Therefore, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present application may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to magnetic disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

Claims

1. A system migration method, used for a first system, characterized in that: Also includes: Identify target user groups; collecting, through a system plug-in, first service request data of users of the target user group for a target service provided by the first system during an evaluation period, as well as first result data and first time consumption data of processing the first service request data by the first system; Sending the first service request data to a second system, and collecting second result data and second time consumption data of processing the first service request data by the second system; determining, based on the first result data, the second result data, the first time consumption data, and the second time consumption data, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group; If it is determined that there is functional equivalence for the target user group, the service request data of users of the target user group after the evaluation period are switched to the second system.

2. A system migration method, used for a second system, characterized in that: Also includes: Get the target user group; collecting, through the system plug-in, second service request data of users of the target user group for the target service provided by the second system during the verification period, as well as third result data and third time consumption data of processing the second service request data by the second system; Sending the second service request data to the first system, and collecting fourth result data and fourth time consumption data of the first system processing the second service request data; determining, based on the third result data, the fourth result data, the third time consumption data, and the fourth time consumption data, whether the target services provided by the first system and the second system are functionally equivalent for the target user group; If it is determined that there is no functional equivalence for the target user group, subsequent service request data of users of the target user group is switched to the first system.

3. The method according to claim 2, characterized in that Also includes: Determine whether the service request data received by the second system is the second service request data.

4. A system migration functional equivalence evaluation method for a plug-in of a first system, characterized in that: include: Collecting service request data of users of the target user group for the target service provided by the first system during the evaluation period, as well as first result data and first time consumption data of the first system processing the service request data; Sending the service request data to a second system, and collecting second result data and second time consumption data of processing the service request data by the second system; Based on the first result data, the second result data, the first time consumption data and the second time consumption data, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and use the judgment result as the basis for determining whether the first system switches the service request data of users of the target user group after the evaluation period to the second system.

5. A system service method, used in a first system, characterized in that: include: receiving service request data from a user for a target service provided by the first system; If the user is a user of the target user group, and the target services provided by the first system and the second system respectively have functional equivalence for the target user group, switching the service request data to the second system, and processing the service request data by the second system; otherwise, processing the service request data by the first system; Wherein, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group is judged by the method provided in claim 14.

6. A method for evaluating the functional equivalence of system migration, for a plug-in of a second system, characterized in that: include: Collecting service request data of users of the target user group for the target service provided by the second system during the verification period, as well as third result data and third time consumption data of the second system processing the service request data; Sending the service request data to the first system, and collecting fourth result data and fourth time consumption data of processing the service request data by the first system; Based on the third result data, the fourth result data, the third time-consuming data and the fourth time-consuming data, determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group, and use the judgment result as the basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system.

7. A system service method, used for a second system, characterized in that: include: receiving service request data from a user for a target service provided by the second system; If the user is a user of the target user group, and the target services provided by the first system and the second system respectively do not have functional equivalence for the target user group, switching the service request data to the first system, and processing the service request data by the first system; otherwise, processing the service request data by the second system; Wherein, whether the target services respectively provided by the first system and the second system are functionally equivalent to the target user group is judged by the method provided in claim 16.

8. A migration system, characterized in that: include: A first system migration device constructed according to the method of claim 1; And, a second system migration device constructed according to the method of claim 2.

9. A system plug-in, characterized in that: include: a traffic collection unit, configured to collect service request data of users of a target user group for a target service provided by the first system during an evaluation period, and first result data and first time consumption data of the first system processing the service request data; a traffic replay unit, configured to send the service request data to the second system, and collect second result data and second time consumption data of processing the service request data by the second system; A result comparison unit is used to determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the first result data, the second result data, the first time consumption data and the second time consumption data, and use the judgment result as a basis for determining whether the first system switches the service request data of users of the target user group after the evaluation period to the second system.

10. A system plug-in, characterized in that: include: a traffic collection unit, configured to collect service request data of users of the target user group for the target service provided by the second system during the verification period, and third result data and third time consumption data of the second system processing the service request data; a traffic replay unit, configured to send the service request data to the first system, and collect fourth result data and fourth time consumption data of the first system processing the service request data; A result comparison unit is used to determine whether the target services provided by the first system and the second system are functionally equivalent to the target user group based on the third result data, the fourth result data, the third time-consuming data, and the fourth time-consuming data, and use the judgment result as a basis for determining whether the second system switches subsequent service request data of users of the target user group to the first system.

11. An electronic device, characterized in that: include: processor; as well as A memory is used to store a program for implementing the method according to any one of claims 1 to 7, and the device is powered on and runs the program of the method through the processor.

12. A computer-readable storage medium, characterized in that The computer-readable storage medium stores instructions, which, when executed on a computer, enable the computer to execute the method according to any one of claims 1 to 7.

13. A computer program product, characterized in that When the method is executed on a computer, the computer is enabled to execute the method according to any one of claims 1 to 7.

Images