Traffic migration methods

Abstract

This application discloses a traffic migration method, which includes: intercepting target traffic transmitted to a first platform in response to an access request of a target Uniform Resource Locator (URL); wherein the target traffic is generated by accessing the target URL; the access request carries target user information and target Application Programming Interface (API) information; determining batch migration conditions for the target traffic based on the application scenario of the access request; and migrating the target traffic to a second platform when the target user information and the target API information meet the batch migration conditions.

Description

Technical Field

[0001] This application belongs to the field of computer technology, and specifically relates to a traffic migration method. Background Technology

[0002] During the initial infrastructure upgrade of a platform, traffic needs to be migrated from the old platform to the new platform. In related technologies, DNS-based traffic migration involves a full switch, transferring all traffic to the new platform. This can lead to excessive load on the new platform, making a smooth transition impossible. Batch traffic switching, on the other hand, migrates traffic in batches based on traffic proportions, failing to provide precise migration tailored to different application scenarios. Summary of the Invention

[0003] This application provides a traffic migration method that can solve the problem in related technologies where traffic migration based on traffic ratio in batches cannot be accurately migrated in various application scenarios.

[0004] In a first aspect, embodiments of this application provide a traffic migration method, the method comprising: intercepting target traffic transmitted to a first platform in response to an access request of a target Uniform Resource Locator (URL); wherein the target traffic is generated by accessing the target URL; the access request carries target user information and target Application Programming Interface (API) information; determining batch migration conditions for the target traffic based on the application scenario of the access request; and migrating the target traffic to a second platform when the target user information and the target API information satisfy the batch migration conditions.

[0005] In a second aspect, embodiments of this application provide an electronic device including a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the method described in the first aspect.

[0006] Thirdly, embodiments of this application provide a readable storage medium on which a program or instructions are stored, which, when executed by a processor, implement the steps of the method described in the first aspect.

[0007] Fourthly, embodiments of this application provide a chip, the chip including a processor and a communication interface, the communication interface being coupled to the processor, the processor being used to run programs or instructions to implement the steps of the method described in the first aspect.

[0008] Fifthly, embodiments of this application provide a computer program product, the computer program product including a computer program stored on a non-transitory computer-readable storage medium, the computer program including a program or instructions, which, when executed, implement the steps of the method described in the first aspect.

[0009] In this embodiment, target traffic transmitted to a first platform is intercepted in response to an access request to a target Uniform Resource Locator (URL). This target traffic originates from accessing the target URL, and the access request carries target user information and target Application Programming Interface (API) information. Based on the application scenario of the access request, batch migration conditions for the target traffic are determined. If the target user information and the target API information meet the batch migration conditions, the target traffic is migrated to a second platform. This allows for precise migration of target traffic meeting the batch migration conditions to the second platform, tailored to the specific application scenario of the access request. Attached Figure Description

[0010] Figure 1 This is a flowchart illustrating a traffic migration method provided in an embodiment of this application;

[0011] Figure 2 This is a schematic diagram of the structure of a traffic migration system provided in an embodiment of this application;

[0012] Figure 3 This is a flowchart illustrating another traffic migration method provided in an embodiment of this application;

[0013] Figure 4 This is a flowchart illustrating another traffic migration method provided in an embodiment of this application;

[0014] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0015] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0016] The terms "first," "second," etc., used in the specification and claims of this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such use of data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein, and the objects distinguished by "first," "second," etc., are generally of the same class and the number of objects is not limited; for example, a first object can be one or more. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0017] The traffic migration method provided in this application will be described in detail below with reference to the accompanying drawings, through specific embodiments and application scenarios.

[0018] Figure 1 This diagram illustrates a flow chart of a traffic migration method provided in an embodiment of this application, which can be executed by an electronic device. See also... Figure 1 The method may include the following steps.

[0019] Step 102: In response to an access request to the target Uniform Resource Locator (URL), intercept the target traffic transmitted to the first platform; wherein the target traffic is generated by accessing the target URL; and the access request carries target user information and target application programming interface (API) information.

[0020] The target users can include existing users, i.e., users who registered before a specific date, and users who are currently registering. The target traffic can be cloud drive user domain traffic.

[0021] Step 104: Determine the batch migration conditions for the target traffic based on the application scenario of the access request.

[0022] The conditions for determining the migration of target traffic vary depending on the application scenario.

[0023] Step 106: If the target user information and the target application programming interface (API) information meet the batch migration conditions, migrate the target traffic to the second platform.

[0024] In this embodiment, by responding to an access request for a target Uniform Resource Locator (URL), target traffic transmitted to a first platform is intercepted. Based on the application scenario of the access request, batch migration conditions for the target traffic are determined. Then, the target user information and target Application Programming Interface (API) information carried in the access request are compared with the batch migration conditions. If the target user information and the target API information satisfy the batch migration conditions, the target traffic is migrated to a second platform. This allows for precise migration of target traffic that meets the batch migration conditions to the second platform, tailored to the application scenario of the access request.

[0025] In one implementation, step 104 above, which determines the batch migration conditions of the target traffic based on the scenario of the access request, may include: when the scenario of the access request is a user domain pass-through login interface scenario or a first platform user login interface scenario, the batch migration conditions of the target traffic are: (1) the user's mobile phone number is a whitelisted mobile phone number; (2) the type value of the application programming interface (API) is a preset value.

[0026] In this application embodiment, an application scenario for an access request is provided, namely a user domain transparent login interface scenario or a first platform user login interface scenario. In this scenario, the decision to migrate target traffic is made based on two dimensions: whether the user's mobile phone number is a whitelisted mobile phone number and whether the type value of the application programming interface (API) is a preset value. That is, when the access request scenario is a user domain transparent login interface scenario or a first platform user login interface scenario, if it is determined that the user's mobile phone number is a whitelisted mobile phone number and the type value of the application programming interface (API) is a preset value, it is determined that the target traffic can be migrated to the second platform.

[0027] In one implementation, the target user information may include the target user's mobile phone number. The target application programming interface (API) information may include the type value of the target API.

[0028] In this embodiment, the access request carries the target user's mobile phone number and the type value of the target application programming interface (API). When the access request scenario is a user domain pass-through login interface scenario or a first platform user login interface scenario, the target user's mobile phone number and the type value of the target API can be used to determine whether the batch migration conditions are met, thereby migrating the target traffic. Table 1 provides a correspondence between the type values ​​of the application programming interface (API) and the user domain pass-through login interface scenario.

[0029] Table 1.

[0030]

[0031] In one implementation, step 106 above, where the target user information and the target application programming interface (API) information satisfy the batch migration conditions, involves migrating the target traffic to the second platform, and includes the following steps.

[0032] Step 1061: If the access request scenario is a user domain pass-through login interface scenario or a first platform user login interface scenario, determine that the target user's mobile phone number is the whitelisted mobile phone number; and determine that the type value of the target application programming interface (API) is a preset value.

[0033] Step 1062: Migrate the target traffic to the second platform.

[0034] In this embodiment of the application, when the access request scenario is a user domain transparent login interface scenario or a first platform user login interface scenario, by determining that the target user's mobile phone number carried in the access request is a whitelisted mobile phone number, and by determining that the type value of the target application programming interface (API) carried in the access request is a preset value, it can be determined that the target user information and the target application programming interface (API) information meet the batch migration conditions, thereby migrating the target traffic to the second platform, and achieving accurate migration of target traffic for user domain transparent login interface scenarios or first platform user login interface scenarios.

[0035] In one implementation, step 104 above, which determines the batch migration conditions of the target traffic based on the application scenario of the access request, may include: when the application scenario of the access request is a scenario where the first platform can resolve user mobile phone numbers, the batch migration condition of the target traffic is: the user mobile phone number is a whitelisted mobile phone number.

[0036] In this application embodiment, another application scenario for access requests is provided, namely, a scenario where the first platform can resolve user mobile phone numbers via an interface. In this scenario, the decision to migrate target traffic is made based on the user's mobile phone number. In other words, when the access request scenario is a scenario where the first platform can resolve user mobile phone numbers via an interface, if the user's mobile phone number is determined to be a whitelisted mobile phone number, it is determined that the target traffic can be migrated to the second platform.

[0037] In one implementation, the target user information may include the target user's mobile phone number. Step 106, where the target user information and the target application programming interface (API) information satisfy the batch migration conditions, involves migrating the target traffic to the second platform. This may include: if the application scenario of the access request is a scenario where the first platform can resolve user mobile phone numbers, determining that the target user's mobile phone number is a whitelisted mobile phone number; and migrating the target traffic to the second platform.

[0038] In this embodiment of the application, when the scenario of the access request is a scenario where the first platform can resolve user mobile phone numbers, if the target user mobile phone number carried in the access request is determined to be a whitelisted mobile phone number, it can be determined that the target user information meets the conditions for batch migration, thereby migrating the target traffic to the second platform, and realizing accurate migration of target traffic for the scenario where the first platform can resolve user mobile phone numbers.

[0039] In one implementation, determining that the target user's mobile phone number is a whitelisted mobile phone number may include the following steps.

[0040] Step 1: Use the first three digits of the target user's mobile phone number as the key and the last eight digits of the target user's mobile phone number as the offset corresponding to the key.

[0041] Step 2: If the key and the offset are found in the preset whitelist, determine that the user's mobile phone number is a whitelisted mobile phone number; wherein, the preset whitelist stores the key and offset corresponding to the whitelisted mobile phone number.

[0042] The preset whitelist can be stored in the Redis database. The keys and offsets corresponding to the whitelisted phone numbers in the preset whitelist are stored in the form of a bitmap for easy querying.

[0043] In this embodiment, the first three digits of the target user's mobile phone number are used as a key, and the last eight digits are used as an offset corresponding to the key. Based on this key and offset, a query is performed from a preset whitelist. If the key and offset are found in the preset whitelist, the user's mobile phone number is determined to be a whitelisted mobile phone number, thus achieving the goal of determining whether a user's mobile phone number is a whitelisted mobile phone number.

[0044] In one implementation, after step 104 above, which determines the batch migration conditions of the target traffic based on the application scenario of the access request, the method further includes: if the user information and the application programming interface (API) information do not meet the batch migration conditions, transmitting the target traffic to the first platform.

[0045] In this embodiment, upon responding to an access request for a target Uniform Resource Locator (URL), target traffic destined for the first platform is intercepted. After determining the batch migration conditions for the target traffic based on the application scenario of the access request, the target traffic is migrated to the second platform if the target user information and the target application programming interface (API) information meet the batch migration conditions. Conversely, if the user information and the API information do not meet the batch migration conditions, the target traffic is transmitted back to the first platform. This achieves the goal of migrating target traffic to the second platform if the target user information and the target API information meet the batch migration conditions, and continuing to migrate target traffic back to the original first platform if they do not, thus continuing to provide services to users and avoiding impact on user experience.

[0046] In one implementation, the above method may further include: switching the target traffic to the first platform when a migration failure is detected in the target traffic.

[0047] In this embodiment of the application, during the migration of target traffic, there may be a migration failure. In the event of a failure, the target traffic will be switched back to the original first platform for transmission only, and the service will continue to be provided to users through the original first platform to avoid affecting the user experience.

[0048] In one implementation, before intercepting the target traffic transmitted to the first platform in step 102 above, the method further includes the following steps.

[0049] Step 1021: Determine the transmission volume of the target traffic based on the network environment and the application scenario of the access request.

[0050] Step 1022: Divide the target traffic into multiple batches of traffic based on the transmission volume.

[0051] The transmission volume can be a preset data volume or a certain percentage of the data volume.

[0052] In this embodiment, the transmission volume of the target traffic is determined based on the network environment and the application scenario of the access request. Based on the transmission volume, the target traffic is divided into multiple batches. Then, traffic interception is performed on each batch, and it is determined whether the batch meets the batch migration conditions. If the batch meets the batch migration conditions, the batch is migrated. This embodiment effectively avoids network congestion and data loss, improving network transmission efficiency and stability.

[0053] Figure 2 This paper shows a schematic diagram of the structure of a traffic migration system provided in an embodiment of this application. See also: Figure 2 The system includes a client, an Nginx cluster for the old platform, an application server (e.g., Application as a Service (AAS)), a resource pool for the old platform, a server load balancer (SLB) for the new platform, a user domain adaptation layer, and a resource pool for the new platform.

[0054] Figure 3 This paper illustrates a flowchart of another traffic migration method provided in an embodiment of this application. This method can be applied to, for example... Figure 2 The traffic migration system shown is described in the following document. Figure 3 The method may include the following steps.

[0055] Step 301: The client sends an interface request to the F5 load balancer.

[0056] Step 302: The F5 load balancer forwards the interface requests to the Nginx cluster on the old platform.

[0057] Step 303: The Nginx cluster parses the request path and determines whether the requested interface is in the compatible interface list. If not, proceed to step 304. If yes, proceed to step 305.

[0058] Step 304: The Nginx cluster sends an application service request to the application server on the old platform, and the application server on the old platform returns a response.

[0059] Step 305: The Nginx cluster checks if the user information is in the whitelist. If not, proceed to step 304. If yes, proceed to step 306.

[0060] Step 306: The Nginx cluster sends an adaptation interface request to the user domain adaptation layer of the new platform through the internal SLB of the new platform, and the user domain adaptation layer of the new platform returns a response. This allows traffic to be migrated to the user domain adaptation layer of the new platform through the requested adaptation interface.

[0061] In one implementation, Figure 4 This paper illustrates a flowchart of another traffic migration method provided in an embodiment of this application. This method can be applied to, for example... Figure 2 The traffic migration system shown is described in the following document. Figure 4 The method may include the following steps.

[0062] Step 401: The client sends an interface request to the F5 load balancer.

[0063] Step 402: The F5 load balancer forwards the interface requests to the Nginx cluster on the old platform.

[0064] Step 403: The Nginx cluster determines whether the user is on the whitelist based on the user information. If not, proceed to step 404. If yes, proceed to step 405.

[0065] Step 404: The Nginx cluster sends an application service request to the application server on the old platform, and the application server on the old platform returns a response.

[0066] Step 405: The Nginx cluster intercepts application service requests sent to the application server on the old platform.

[0067] Step 406: The Nginx cluster forwards application service requests to the user domain adaptation layer of the new platform via the internal network SLB.

[0068] Step 407: The new platform's user domain adaptation layer returns the request result.

[0069] Step 408 (optional): If a failure occurs during steps 404 to 405, the fault switch in the Nginx cluster is turned on, and the application service request is switched to the application server of the old platform.

[0070] In this embodiment, user information or interface information is used to determine whether to send the application service request to the application server of the old platform or the user domain adaptation layer of the new platform. This ensures that normal service is guaranteed for users regardless of whether the application service request is sent to the application server of the old platform or the user domain adaptation layer of the new platform, avoiding any impact on user experience and thus enabling a smooth transition from the old platform to the new platform.

[0071] This application also provides an electronic device for performing the traffic migration method described above. Figure 5This is a schematic diagram of the structure of an electronic device to implement the various embodiments of this application. The electronic device can vary significantly due to differences in configuration or performance, and may include a processor 501, a communications interface 502, a memory 503, and a communication bus 504. The processor 501, communications interface 502, and memory 503 communicate with each other via the communication bus 504. The processor 501 can call a computer program stored in the memory 503 and executable on the processor 501 to perform the various steps of the traffic migration method embodiments described above, achieving the same technical effects. To avoid repetition, further details are omitted here.

[0072] The above electronic device structure does not constitute a limitation on the electronic device. An electronic device may include more or fewer components than illustrated, or combine certain components, or arrange them differently. For example, an input unit may include a Graphics Processing Unit (GPU) and a microphone, and a display unit may use a liquid crystal display (LCD), organic light-emitting diode (OLED), or other similar display panels. User input units include at least one of a touch panel and other input devices. A touch panel is also called a touchscreen. Other input devices may include, but are not limited to, physical keyboards, function keys (such as volume control buttons, power buttons, etc.), trackballs, mice, and joysticks, which will not be elaborated further here.

[0073] Memory can be used to store software programs and various data. Memory can primarily include a first storage area for storing programs or instructions and a second storage area for storing data. The first storage area can store the operating system, application programs or instructions required for at least one function (such as sound playback, image playback, etc.). Furthermore, memory can include volatile memory or non-volatile memory, or both. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), static random access memory (SRAM), dynamic random access memory (DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDRSDRAM), enhanced synchronous dynamic random access memory (ESDRAM), synchronous linked dynamic random access memory (Synchlink DRAM, SLDRAM), and direct memory bus RAM (DRRAM).

[0074] The processor may include one or more processing units; optionally, the processor integrates an application processor and a modem processor, wherein the application processor mainly handles operations related to the operating system, user interface, and applications, while the modem processor mainly handles wireless communication signals, such as a baseband processor. It is understood that the aforementioned modem processor may also not be integrated into the processor.

[0075] This application also provides a readable storage medium storing a program or instructions. When the program or instructions are executed by a processor, they implement the various processes of the above-described traffic migration method embodiments and achieve the same technical effect. To avoid repetition, they will not be described again here.

[0076] The processor is the processor in the electronic device described in the above embodiments. The readable storage medium includes computer-readable storage media, such as computer read-only memory (ROM), random access memory (RAM), magnetic disk, or optical disk.

[0077] This application embodiment also provides a chip, which includes a processor and a communication interface. The communication interface is coupled to the processor. The processor is used to run programs or instructions to implement the various processes of the above-described traffic migration method embodiments and can achieve the same technical effect. To avoid repetition, it will not be described again here.

[0078] It should be understood that the chip mentioned in the embodiments of this application may also be referred to as a system-on-a-chip, system chip, chip system, or system-on-a-chip, etc.

[0079] This application also provides a computer program product, which includes a computer program stored on a non-transitory computer-readable storage medium. The computer program includes a program or instructions. When the program or instructions are executed, they implement the various processes of the above-described traffic migration method embodiments and can achieve the same technical effect. To avoid repetition, they will not be described again here.

[0080] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element. Furthermore, it should be noted that the scope of the methods and apparatuses in the embodiments of this application is not limited to performing functions in the order shown or discussed, but may also include performing functions substantially simultaneously or in the reverse order, depending on the functions involved. For example, the described methods may be performed in a different order than described, and various steps may be added, omitted, or combined. Additionally, features described with reference to certain examples may be combined in other examples.

[0081] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal (which may be a mobile phone, computer, server, air conditioner, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0082] The embodiments of this application have been described above with reference to the accompanying drawings. However, this application is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of this application without departing from the spirit and scope of the claims, and all of these forms are within the protection scope of this application.

Claims

1. A traffic migration method, characterized in that, include: In response to an access request to a target Uniform Resource Locator (URL), the target traffic transmitted to the first platform is intercepted; wherein the target traffic is generated from accessing the target URL; and the access request carries target user information and target application programming interface (API) information. Based on the application scenario of the access request, determine the batch migration conditions for the target traffic; If the target user information and the target application programming interface (API) information meet the batch migration conditions, the target traffic will be migrated to the second platform.

2. The method according to claim 1, characterized in that, The step of determining the batch migration conditions for the target traffic based on the application scenario of the access request includes: When the application scenario of the access request is a user domain transparent login interface scenario or a first platform user login interface scenario, the batch migration conditions of the target traffic are as follows: The user's mobile phone number is a whitelisted mobile phone number; The type value of the Application Programming Interface (API) is a default value.

3. The method according to claim 2, characterized in that, The target user information includes the target user's mobile phone number; the target application programming interface (API) information includes the type value of the target application programming interface (API).

4. The method according to claim 3, characterized in that, If the target user information and the target application programming interface (API) information meet the batch migration conditions, the target traffic will be migrated to the second platform, including: In the case where the access request is made in the scenario of a user domain pass-through login interface or a first platform user login interface, the target user's mobile phone number is determined to be a whitelisted mobile phone number; and the type value of the target application programming interface (API) is determined to be a preset value. The target traffic will be migrated to the second platform.

5. The method according to claim 1, characterized in that, The step of determining the batch migration conditions for the target traffic based on the application scenario of the access request includes: When the application scenario of the access request is a scenario where the first platform can parse the user's mobile phone number interface, the batch migration conditions for the target traffic are as follows: The user's mobile phone number is a whitelisted mobile phone number.

6. The method according to claim 5, characterized in that, The target user information includes the target user's mobile phone number; when the target user information and the target application programming interface (API) information meet the batch migration conditions, the target traffic is migrated to the second platform, including: In the case where the application scenario of the access request is a scenario where the first platform can parse the user's mobile phone number interface, the target user's mobile phone number is determined to be a whitelisted mobile phone number; The target traffic will be migrated to the second platform.

7. The method according to claim 4 or 6, characterized in that, The step of determining that the target user's mobile phone number is a whitelisted mobile phone number includes: Use the first three digits of the target user's mobile phone number as the key and the last eight digits of the target user's mobile phone number as the offset corresponding to the key; If the key and the offset are found in the preset whitelist, the user's mobile phone number is determined to be a whitelisted mobile phone number; wherein, the preset whitelist stores the key and offset corresponding to the whitelisted mobile phone number.

8. The method according to claim 1, characterized in that, After determining the batch migration conditions of the target traffic based on the application scenario of the access request, the method further includes: If the user information and the application programming interface (API) information do not meet the batch migration conditions, the target traffic will be transmitted to the first platform.

9. The method according to claim 1, characterized in that, The method further includes: If a migration failure is detected in the target traffic, the target traffic will be switched to be transmitted to the first platform.

10. The method according to claim 1, characterized in that, Before intercepting the target traffic transmitted to the first platform, the method further includes: The transmission volume of the target traffic is determined based on the network environment and the application scenario of the access request; Based on the transmission volume, the target traffic is divided into multiple batches of traffic.

11. An electronic device, characterized in that, The electronic device includes a processor, a memory, and a program or instructions stored in the memory and executable on the processor, wherein the program or instructions, when executed by the processor, implement the steps of the traffic migration method as described in any one of claims 1 to 10.

12. A readable storage medium, characterized in that, The readable storage medium stores a program or instructions that, when executed by a processor, implement the steps of the traffic migration method as described in any one of claims 1 to 10.

13. A computer program product, characterized in that, The computer program product includes a computer program stored on a non-transitory computer-readable storage medium, the computer program including programs or instructions that, when executed, implement the steps of the traffic migration method as described in any one of claims 1 to 10.

Images