Traffic switching method, apparatus, device, and product

Abstract

This application discloses a traffic switching method, apparatus, device, and product, relating to the field of traffic scheduling technology. The method is applied to a service response end, which includes an entry service unit and an edge distribution unit. It receives access requests sent by user terminals and processes these requests through the entry service unit according to gray-scale traffic rules to obtain a request result. Upon receiving an application update instruction, the entry service unit performs a switching determination on the access request to obtain a gray-scale traffic switching result. Based on the gray-scale traffic switching result, it switches the traffic for the user terminal's access request and processes the static resource requests corresponding to the access requests through the edge distribution unit until the application update instruction is completed, thereby improving the efficiency of traffic switching.

Description

Technical Field

[0001] This application relates to the field of traffic scheduling technology, and in particular to a traffic switching method, apparatus, device, and product. Background Technology

[0002] In current conventional front-end application architectures, the common approach during front-end version releases and canary traffic switching is to use a combination of static file hash naming and strong caching. In scenarios where users have long-term login status and the external environment is single and stable, this approach can alleviate resource access anomalies caused by version switching to a certain extent. At the same time, in order to improve the performance of static resource access and reduce the load on the origin server, the front-end architecture is gradually transforming into a CDN distribution architecture, relying on CDN edge nodes to achieve the nearest distribution of static resources and optimize the access experience for end users.

[0003] However, the aforementioned existing technologies have obvious limitations. First, for high-traffic stateless page scenarios, users can switch between multiple external environments, which greatly reduces the applicability of hash caching solutions. When switching versions, HTML files and static resources are easily distributed to servers of different versions, causing instantaneous 404 access errors. Second, the existing CDN architecture lacks a sound fault degradation mechanism. When CDN servers fail, access to static resources is easily interrupted. Third, during the transition from conventional front-end architecture to CDN architecture, there is a lack of smooth traffic switching solutions, which can easily cause traffic loss and reduced service availability, making it difficult to meet the usage requirements of high-availability business scenarios.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a traffic switching method, device, equipment, and product, which aims to solve the technical problems of access anomalies caused by mismatch between page and static resource versions and insufficient smoothness and availability of update services when application version gray-scale switching is carried out in high-traffic stateless scenarios.

[0006] To achieve the above objectives, this application proposes a traffic switching method, which is applied to a service response end, the service response end including an ingress service unit and an edge distribution unit, and the traffic switching method includes: Receive access requests sent by user clients, process the access requests through the entry service unit according to the gray-scale traffic rules, and obtain the request results; Upon receiving an application update instruction, the entry service unit performs a switching determination on the access request to obtain the gray-scale traffic switching result. Based on the gray-scale traffic switching result, the access request of the user terminal is switched, and the static resource request corresponding to the access request is processed by the edge distribution unit until the application update instruction is completed.

[0007] In one embodiment, the step of processing the access request through the entry service unit according to the grayscale traffic rules to obtain the request result includes: Extract traffic identification information from the access request; The grayscale traffic rules are used to perform rule matching on the traffic identification information to obtain the matching result; The access application version corresponding to the access request is determined based on the matching result. Based on the accessed application version, the application homepage entry file is retrieved through the entry service unit as the request result, and the request result is sent to the user terminal.

[0008] In one embodiment, the step of determining the switching of the access request through the entry service unit to obtain the gray-scale traffic switching result includes: According to the application update instruction, the updated gray-scale switching rules and version mapping relationships are loaded through the entry service unit; The access request version is adapted and verified according to the updated gray-scale switching rules to obtain the version adaptation verification result. If the version compatibility verification result is passed, the target application version is determined through the version mapping relationship; The grayscale traffic switching result is generated based on the target application version.

[0009] In one embodiment, the step of switching the access request of the user terminal according to the gray-scale traffic switching result includes: The target application version corresponding to the access request is determined based on the gray-scale traffic switching result. The access request is switched to the service link corresponding to the target application version through the entry service unit; The homepage entry file corresponding to the target application version is sent to the user terminal according to the service link of the target application version.

[0010] In one embodiment, before the step of processing the static resource request corresponding to the access request through the edge distribution unit, the method further includes: After detecting that the user terminal loads the homepage entry file, the response detection is performed on several nodes of the edge distribution node to obtain the response status and response content of the several nodes; The availability of the nodes is determined based on the response status and response content, and an availability determination result is obtained. The availability judgment result determines the available hierarchical resource service link, which is used to process the static resource request corresponding to the access request through the edge distribution unit.

[0011] In one embodiment, the step of processing the static resource request corresponding to the access request through the edge distribution unit includes: The static resource request is parsed to obtain the resource version identifier and resource path; Based on the resource version identifier and resource path, the edge distribution unit performs resource file matching on the local cache to obtain the resource matching result. Based on the resource matching results, a static resource access result is sent to the user terminal.

[0012] In one embodiment, after the steps of switching the access request of the user terminal according to the gray-scale traffic switching result and processing the static resource request corresponding to the access request through the edge distribution unit, the method further includes: Continuously monitor the running status and access response data of the service links corresponding to the target application version to obtain the running monitoring results; Based on the operational monitoring results, the functional integrity and operational stability of the target application version are verified to obtain the stability verification results. If the stability verification result is passed, all user traffic will be switched to the service link corresponding to the target application version, and the application update instruction will be marked as completed.

[0013] Furthermore, to achieve the above objectives, this application also proposes a traffic switching device, which is applied to a service response end, the service response end including an ingress service unit and an edge distribution unit, and the traffic switching device includes: The receiving module is used to receive access requests sent by the user terminal, process the access requests through the entry service unit according to the gray-scale traffic rules, and obtain the request result; The determination module is used to determine the switching of the access request through the entry service unit when an application update instruction is received, and to obtain the gray-scale traffic switching result. The switching module is used to switch the access request of the user terminal according to the gray-scale traffic switching result, and process the static resource request corresponding to the access request through the edge distribution unit until the application update instruction is completed.

[0014] In addition, to achieve the above objectives, this application also proposes a traffic switching device, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the traffic switching method as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the traffic switching method described above.

[0016] In addition, to achieve the above objectives, this application also provides a computer program product, which includes a computer program that, when executed by a processor, implements the steps of the traffic switching method described above.

[0017] One or more technical solutions proposed in this application have at least the following technical effects: This application discloses a traffic switching method, apparatus, device, and product. The method is applied to a service response end, which includes an entry service unit and an edge distribution unit. The method receives an access request from a user terminal, processes the access request through the entry service unit according to gray-scale traffic rules, and obtains a request result. Upon receiving an application update instruction, the entry service unit performs a switching determination on the access request, obtaining a gray-scale traffic switching result. Based on the gray-scale traffic switching result, the method switches the traffic of the user terminal's access request, and the edge distribution unit processes the static resource request corresponding to the access request until the application update instruction completes the update. Therefore, by uniformly accepting all user access requests through the entry service unit, and completing version matching and switching determination based on the gray-scale traffic rules, it ensures that the version of the distributed page entry file is strictly consistent with the traffic distribution rules. Then, the edge distribution unit matches and processes the corresponding version of static resource requests, thereby avoiding access anomalies caused by page and resource version mismatches from the root. The entire process is a gradual switch according to the gray-scale rules until the update is completed, ensuring the smoothness and high availability of services in high-traffic stateless scenarios. This solves the problem of access anomalies caused by page and static resource version mismatches and insufficient smoothness and availability of update services when application version gray-scale switching is performed in high-traffic stateless scenarios, and improves the efficiency of traffic switching. Attached Figure Description

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

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating an embodiment of the traffic switching method of this application. Figure 2 This is a schematic diagram of the system architecture involved in the traffic switching method of this application; Figure 3 This is a schematic diagram illustrating the architecture involved in the traffic switching method of this application to implement traffic switching; Figure 4 This is a flowchart illustrating Embodiment 2 of the traffic switching method of this application; Figure 5 This is a schematic diagram illustrating the degradation plugin processing involved in the traffic switching method of this application; Figure 6 This is a schematic diagram of the user architecture application involved in the traffic switching method of this application; Figure 7 This is a schematic diagram of the user architecture application involved in the traffic switching method of this application during traffic switching; Figure 8 A simplified flowchart illustrating the traffic switching method provided in Embodiment 2 of this application; Figure 9 This is a schematic diagram of the module structure of the flow switching device according to an embodiment of this application; Figure 10 This is a schematic diagram of the device structure of the hardware operating environment involved in the traffic switching method in the embodiments of this application.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0024] The main solution of this application embodiment is as follows: extract traffic identification information from the access request; perform rule matching on the traffic identification information using the gray-scale traffic rules to obtain a matching result; determine the access application version corresponding to the access request based on the matching result; retrieve the application homepage entry file as the request result through the entry service unit based on the access application version, and send the request result to the user terminal. According to the application update instruction, load the updated gray-scale switching rules and version mapping relationship through the entry service unit; perform adaptation verification on the access request version according to the updated gray-scale switching rules to obtain a version adaptation verification result; if the version adaptation verification result is successful, determine the target application version through the version mapping relationship; generate a gray-scale traffic switching result based on the target application version. Determine the target application version corresponding to the access request based on the gray-scale traffic switching result; switch the access request to the service link corresponding to the target application version through the entry service unit; send the homepage entry file corresponding to the target application version to the user terminal according to the service link of the target application version. After detecting that the user terminal has loaded the homepage entry file, the response probes are performed on several nodes of the edge distribution node to obtain the response status and content of the nodes. The availability of the nodes is determined based on the response status and content, resulting in an availability assessment result. The available hierarchical resource service links are determined based on the availability assessment result. These hierarchical resource service links are used to process the static resource requests corresponding to the access requests through the edge distribution unit. The static resource requests are parsed to obtain resource version identifiers and resource paths. Based on the resource version identifiers and resource paths, resource files are matched against the local cache through the edge distribution unit to obtain resource matching results. Static resource access results are sent to the user terminal based on the resource matching results. The running status and access response data of the service links corresponding to the target application version are continuously monitored to obtain running monitoring results. The functional integrity and running stability of the target application version are verified based on the running monitoring results to obtain stability verification results. If the stability verification result is passed, all user traffic is switched to the service links corresponding to the target application version, and the application update instruction is marked as completed. This solves the problem of access anomalies caused by mismatch between page and static resource versions during application version canary switching in high-traffic, stateless scenarios, as well as the lack of smoothness and availability of update services. It enables traffic switching and improves the efficiency of traffic switching.Based on the present invention, addressing the problem that real-world traffic switching lacks smooth transition solutions, easily leading to traffic loss and decreased service availability, making it difficult to meet the needs of high-availability business scenarios and resulting in low efficiency, a traffic switching method is designed. The effectiveness of the traffic switching method of the present invention is verified during traffic switching, and the efficiency of traffic switching using the present invention is significantly improved.

[0025] In this embodiment, for ease of description, the flow switching device will be used as the execution subject in the following description.

[0026] Due to the limitations of existing technologies in front-end canary releases and CDN distribution architectures, service stability during version traffic switching needs improvement. One issue is version mismatch. In high-traffic stateless page scenarios, users can switch between multiple external environments, significantly reducing the applicability of traditional hash caching solutions. During version switching, HTML files and static resources are easily distributed to servers of different versions, leading to an increase in the instantaneous 404 error rate. Another issue is fault degradation. Existing CDN architectures generally lack a robust multi-level fault degradation mechanism. If there is no backup distribution link when a CDN server fails, the continuity of static resource access will also decrease significantly. Finally, there is the issue of architecture migration. Smooth architecture upgrades require mature, gradual traffic switching solutions. However, in scenarios involving the transformation of existing businesses, such as transitioning from a conventional front-end architecture to a CDN distribution architecture, the lack of a smooth transition traffic scheduling mechanism also affects service availability during the architecture migration process. Therefore, in the current high-availability front-end business scenarios, there are also challenges in the adaptability of version iteration and architecture upgrade. Since different business areas have different traffic scales and availability requirements, if the traffic switching solution does not take into account version consistency, disaster recovery and degradation and smooth migration capabilities, the overall service stability and user access experience will also decline.

[0027] This application provides a solution that unifies all user access requests through an entry service unit, completes version matching and switching determination based on canary traffic rules, ensures that the version of the distributed page entry file is strictly consistent with the traffic distribution rules, and then the edge distribution unit matches and processes the corresponding version of static resource requests. This fundamentally avoids access anomalies caused by page and resource version mismatches. The entire process is a gradual switch according to canary rules until the update is complete, ensuring the smoothness and high availability of services in high-traffic stateless scenarios. This solves the problem of access anomalies caused by page and static resource version mismatches and insufficient smoothness and availability of update services during application version canary switching in high-traffic stateless scenarios, and improves the efficiency of traffic switching.

[0028] Based on this, embodiments of this application provide a traffic switching method, referring to... Figure 1 , Figure 1This is a flowchart illustrating the first embodiment of the traffic switching method of this application.

[0029] In this embodiment, the traffic switching method is applied to the service response end, which includes an ingress service unit and an edge distribution unit: The system architecture in this embodiment is as follows: Figure 2 As shown, the architecture is divided into four layers, from top to bottom: user client, entry service unit, edge distribution unit, and remote object storage.

[0030] The user client is used to initiate web page access and static resource requests. The entry service unit corresponds to the NGINX server, which is responsible for uniformly receiving front-end access requests, distributing the homepage entry file, and completing reverse proxy and canary traffic distribution. The edge distribution unit corresponds to the CDN server, which processes various static resource requests locally and supports parallel distribution of multiple versions of static resources. The remote object storage is used to persistently store all static resources and provide CDN nodes with the ability to return resources to the origin. The four-layer architecture works together to complete the end-to-end traffic distribution and resource response.

[0031] Having understood the architecture of this embodiment, the traffic switching method includes steps S01 to S03: Step S01: Receive the access request sent by the user terminal, process the access request through the entry service unit according to the gray-scale traffic rules, and obtain the request result; Before describing the solution in this embodiment, it should be clear that the existing technology has obvious limitations when switching traffic. First, for high-traffic stateless page scenarios, users can switch between multiple versions of external environments, which greatly reduces the applicability of the hash caching solution. When switching versions, HTML files and static resources are easily distributed to servers of different versions, causing instantaneous 404 access errors. Second, the existing CDN architecture lacks a sound fault degradation mechanism. When the CDN server fails, it can easily lead to the interruption of access to static resources. Third, during the transition from conventional front-end architecture to CDN architecture, there is a lack of a smooth traffic switching solution, which can easily cause traffic loss and reduced service availability, making it difficult to meet the usage requirements of high-availability business scenarios.

[0032] Therefore, in order to solve the above problems, the system continuously monitors web page access requests initiated by front-end users, and completes unified identification and pre-processing of requests within the entry service unit based on the preset gray-scale traffic distribution rules. It also divides the corresponding access links based on the user's own traffic identifier, and finally generates the homepage access result that matches the current user's access permissions and sends it back to the front-end user.

[0033] Step S02: Upon receiving an application update instruction, the access request is switched through the entry service unit to obtain the gray-scale traffic switching result. After receiving the application version update instruction from the backend, the entry service unit automatically retrieves the latest version iteration configuration information, performs a full-dimensional version adaptation verification based on the current online user's access environment and session status, determines whether the current user session supports seamless version switching, and finally outputs the gray-scale traffic switching judgment result adapted to the current user session status.

[0034] Step S03: Based on the grayscale traffic switching result, the access request of the user terminal is switched according to traffic, and the static resource request corresponding to the access request is processed by the edge distribution unit until the application update instruction is completed.

[0035] Based on the generated gray-scale switching results, the access requests of the corresponding users will be smoothly switched to the service link corresponding to the target version. The edge distribution unit will independently handle all subsequent static resource requests generated by the users. The CDN node will prioritize calling local cached resources to respond to the requests. If there are no corresponding resources locally, it will automatically pull resources from the remote object storage, continuously maintaining the gray-scale distribution state until the full update of this application version is completed.

[0036] Therefore, from the above content, it can be understood that the overall implementation steps of this embodiment are as follows: Figure 3 As shown, the overall traffic switching process adopts a dual-stack parallel operation mode of old and new versions. During the version iteration process, the static resources of the historical version will not be cleaned up, and all static files are distinguished by version through differential hash naming.

[0037] During the traffic gray-scale switching process, even if a user's single session is diverted to different service nodes, the CDN edge unit can still match the corresponding version of the static resources, thereby avoiding instantaneous 404 access errors caused by the mismatch between the HTML homepage file and the static resource version, and ensuring the consistency of access throughout a single user session.

[0038] Specifically, step S01 above, which involves processing the access request through the entry service unit according to the grayscale traffic rules to obtain the request result, includes: Step S011: Extract traffic identification information from the access request; Step S012: Perform rule matching on the traffic identification information using the grayscale traffic rules to obtain the matching result; Step S013: Determine the access application version corresponding to the access request based on the matching result; Step S014: Based on the accessed application version, retrieve the application homepage entry file as the request result through the entry service unit, and send the request result to the user terminal.

[0039] After receiving a user access request message, the entry service unit first parses the X-Forwarded-For field in the HTTP request header to extract the user's real public IP address, parses the User-Agent field to extract the device hardware identifier and client environment information, and reads the cookie data carried in the request and the persistent random code in the browser's LocalStorage. The three types of identifiers are extracted in parallel and are independent of each other, avoiding the failure of gray-scale traffic splitting due to the tampering or loss of a single identifier.

[0040] The system backend has a built-in three-layer structured grayscale rule library. The first layer is the IP whitelist rule, which supports configuring exclusive grayscale groups by region and network segment. The second layer is the device whitelist rule, which is adapted for internal testing and specified user verification scenarios. The third layer is the random code ratio rule, which is used for batch grayscale deployment of public network users. Rule matching adopts a priority-based logic, first matching IP and device whitelists, and only performing random code ratio determination when no whitelist match is found, and outputting the final grayscale group for the user based on the comprehensive results.

[0041] Based on the matching results, the system assigns the corresponding old or new version of the application service link to the user, and at the same time retrieves the corresponding version's homepage HTML file. The file response header is forcibly configured with Cache-Control: no-cache, no-store, must-revalidate to prevent the browser from caching the homepage and ensure that the version switch takes effect immediately.

[0042] The client-side random code uses Math.floor(Math.random()). The algorithm 1e13)+Date.now() % 1e13 generates a fixed 13-character string. On the first visit, when there is no random code, it is generated by the entry service unit and written to the browser via Set-Cookie. At the same time, the front-end script synchronously writes it to LocalStorage. On subsequent visits, double caching is used for cross-validation. If a valid random code exists in either location, it is reused. If the two locations are inconsistent, the Cookie takes precedence and LocalStorage is corrected synchronously. The random code is set to a long-term validity period of 365 days to completely prevent traffic group drift when the user visits repeatedly and ensure that the version remains consistent for the same user over a long period of time.

[0043] More specifically, step S02 above, which involves the entry service unit making a switching determination on the access request to obtain the grayscale traffic switching result, includes: Step S021: According to the application update instruction, load the updated gray-scale switching rules and version mapping relationship through the entry service unit; Step S022: Perform adaptation verification on the access request version according to the updated grayscale switching rules to obtain the version adaptation verification result; Step S023: If the version compatibility verification result is passed, determine the target application version through the version mapping relationship; Step S024: Generate grayscale traffic switching results based on the target application version.

[0044] After the backend operations and maintenance terminal issues the application version update command, the entry service unit pulls the latest grayscale rule file and version mapping table through the atomic configuration loading mechanism. The loading process adopts a dual configuration cache switching scheme. The new configuration will only take effect after it passes the verification, so as to avoid online failures caused by configuration loading interruption.

[0045] The version mapping table uses structured storage. Each record contains a version ID, static resource hash prefix, interface path mapping rules, and a business function association list, fully covering the differentiated file names, access paths, and backend interface call addresses of all static resources such as JS, CSS, and images in the old and new versions.

[0046] The system combines the service path currently accessed by the user, the list of cached resources in the browser, the client's operating system and browser version to perform a three-dimensional adaptation check. First, it performs an interface compatibility check, comparing the differences in request parameters and returned fields between the old and new versions of the interface to determine whether there are missing fields or incompatible types. Second, it performs a static resource path check, verifying the mapping relationship between the old and new versions of the resource paths to avoid resource path 404 errors after version switching. Third, it performs a client environment check to exclude scenarios where older browsers are incompatible with the new features.

[0047] After passing the full-dimensional verification, the target application version to be switched by the user is locked based on the version mapping table. Combined with the gray-scale traffic ratio and time-segmented volume release weight parameters configured by operation and maintenance, a standardized gray-scale switch result containing the user's unique identifier, target version number, switch effective timestamp, and link routing rules is generated and written to the distributed cache for persistent storage, providing an accurate execution basis for subsequent seamless traffic switching across the entire link.

[0048] This embodiment, through the above-described scheme, specifically receives access requests sent by the user client, processes the access requests through the entry service unit according to the gray-scale traffic rules, and obtains the request result; upon receiving an application update instruction, the entry service unit performs a switching determination on the access request, obtaining a gray-scale traffic switching result; based on the gray-scale traffic switching result, the access request from the user client is switched, and the static resource requests corresponding to the access requests are processed by the edge distribution unit until the application update instruction is completed. Thus, the entry service unit uniformly accepts all user access requests, completes version matching and switching determination based on gray-scale traffic rules, ensuring that the version of the distributed page entry file is strictly consistent with the traffic distribution rules, and then the edge distribution unit matches and processes the corresponding version of the static resource requests. This fundamentally avoids access anomalies caused by page and resource version mismatches. The entire process is a gradual switch according to gray-scale rules until the update is complete, ensuring the smoothness and high availability of services in high-traffic stateless scenarios. This solves the problem of access anomalies caused by page and static resource version mismatches during application version gray-scale switching in high-traffic stateless scenarios, and the insufficient smoothness and availability of update services, thus improving the efficiency of traffic switching.

[0049] Based on the first embodiment of this application, in the second embodiment of this application, the content that is the same as or similar to the first embodiment described above can be referred to the above description, and will not be repeated hereafter. Based on this, please refer to... Figure 4 In step S03, the step of switching the access request of the user terminal according to the gray-scale traffic switching result, the traffic switching method further includes steps S031 to S033: Step S031: Determine the target application version corresponding to the access request based on the grayscale traffic switching result; Step S032: The access request is switched to the service link corresponding to the target application version through the entry service unit; Step S033: Send the homepage entry file corresponding to the target application version to the user terminal according to the service link of the target application version.

[0050] The system reads the grayscale switching results from the distributed cache, accurately locates the old version link currently accessed by the user and the target new version service link, and the entry service unit achieves seamless session takeover at the application layer, reusing the user's original TCP long connection and retaining all session data such as session ID, user login status, and page context status, without requiring the user to log in again or refresh the page.

[0051] The system silently performs the link switch in the background. First, it establishes a long connection channel with the new version of the service, synchronizes the session context to the new link, and disconnects the old version of the service after confirming that the connection is stable. The entire switching process is completed in the hundreds of milliseconds, and the user is unaware of it.

[0052] After the link switch is completed, the new homepage entry file of the corresponding version is pushed to the client. The front end adopts the route incremental rendering mechanism, which only updates the DOM nodes with version differences in the page, reuses the context state such as user input and scroll position of the current page, and directly completes the incremental update rendering of the page. There will be no problems such as page white screen, full page reload, or access disconnection throughout the process.

[0053] Meanwhile, the switching process incorporates built-in request debouncing and interception. User requests within the switching window are automatically cached and forwarded to the new service only after the link stabilizes, avoiding request loss or errors and ensuring a seamless user experience.

[0054] Specifically, before step S03 above, which involves the edge distribution unit processing the static resource request corresponding to the access request, the method further includes: Step S0301: After detecting that the user terminal loads the homepage entry file, the response detection is performed on several nodes of the edge distribution node to obtain the response status and response content of the several nodes. Step S0302: Determine the availability of the plurality of nodes based on the response status and response content, and obtain the availability determination result; Step S0303: Determine the available hierarchical resource service link based on the availability judgment result. The hierarchical resource service link is used to process the static resource request corresponding to the access request through the edge distribution unit.

[0055] Combined with the three-level CDN node detection branch process in this embodiment, after the client loads the new homepage file, it automatically and asynchronously starts the background node health detection task, and initiates HTTP GET detection requests in the fixed priority order of primary CDN node, first-level backup CDN node, and second-level backup CDN node.

[0056] The probe request is set to a uniform timeout threshold of 2 seconds. Each node can retry a maximum of 2 times. The retry adopts an exponential backoff strategy, with an interval of 300ms for the first retry and 600ms for the second retry, to avoid misjudgment caused by instantaneous network fluctuations.

[0057] During the probe, three core metrics are collected in real time: first, the interface response time, accurate to the millisecond level; second, the HTTP response status code, identifying 2xx success and 4xx / 5xx error; and third, the probe message return content, verifying whether the SM3 signature matches the preset whitelist.

[0058] The system has a pre-defined unified health assessment standard. If the response time is less than 2 seconds, the status code is 200, and the signature verification is successful, the node is considered healthy and available. If any one of these criteria is not met, the node is considered abnormal.

[0059] The system sequentially marks the health status of all edge distribution nodes, removes all faulty and timed-out nodes, and combines the remaining healthy nodes according to primary and backup priorities to build a hierarchical redundant resource distribution link.

[0060] Under normal circumstances, the primary node is used to distribute static resources. If the primary node fails, it automatically switches to the first-level backup node. If both backup nodes fail, the second-level fallback node is activated. All switching is completed automatically on the front end without page refresh.

[0061] The probe results are cached in the local session storage. A full probe is performed only once per session. The probe results are reused directly within the session's validity period to avoid repeated probes that consume performance.

[0062] More specifically, step S03 above, the step of processing the static resource request corresponding to the access request through the edge distribution unit, includes: Step S034: Parse the static resource request to obtain the resource version identifier and resource path; Step S035: Based on the resource version identifier and resource path, the local cache is matched with resource files through the edge distribution unit to obtain the resource matching result; Step S036: Send the static resource access result to the user terminal based on the resource matching result.

[0063] First, parse the path parameter in the request URL and the x-resource-version field in the request header to extract the resource version hash identifier and the complete resource access path.

[0064] Version identification uses a filename prefix hashing scheme, with different versions of the same resource having different hash prefixes, achieving version isolation at the path level and avoiding cache confusion between different versions of resources.

[0065] Subsequently, the edge node searches the local cache pool and uses a combination of version number and resource path as the cache key for accurate matching. The local cache adopts an LRU eviction policy to prioritize the retention of frequently accessed popular resources.

[0066] If the cache is hit, the local cache file is read directly and returned to the user. The response time is usually in the milliseconds. If the local cache is not hit, a redirected origin request is automatically sent to the remote object storage. The origin request carries the version identifier and resource path authentication parameters. After authentication is successful, the corresponding version of the static resource file is retrieved.

[0067] After a resource is successfully retrieved, it is first written to the local node cache and then returned to the user. Subsequent requests for the same version and resource can directly hit the cache, greatly reducing the access pressure on the origin server.

[0068] The system also supports a version pre-release mechanism. After a new version is released, it proactively pushes all static resources to all CDN edge nodes to ensure that all nodes have cached the new version's resources before the gradual rollout, thus avoiding delays and errors caused by the first access to the origin server. Combination Figure 5 The phased traffic rollout sequence shown is divided into two independent phases. In the initial phase of the rollout, 100% of traffic from external users is routed to the old traditional architecture application, and all public domain name resolutions are directed to the old service cluster to ensure stable public network access. In the second phase of the rollout verification period, traffic is only released to internal testers through internal domain names and whitelist policies to access the new CDN architecture application and complete the full-scenario functional verification, compatibility testing, and stress testing of the new version.

[0069] The system has a built-in front-end integrated degradation plugin. The plugin code is inlined into the homepage HTML and loaded along with the page. No additional external resources are needed, thus avoiding degradation failure due to plugin loading failure.

[0070] The plugin includes three independent probe scripts: probe.js, probe1.js, and probe2.js, which correspond to the primary CDN, the first-level backup, and the second-level backup tertiary nodes, respectively. All probe files generate content hash signatures using the national cryptographic SM3 algorithm. The signature whitelist is hard-coded in the front-end plugin code and cannot be tampered with.

[0071] After the page loads, the plugin asynchronously initiates probe requests in parallel to verify the availability of the three-level nodes in sequence. Once any of the following conditions is detected—request failure, response timeout, or signature verification error—it automatically downgrades and switches to the next-level backup node. If all three levels of CDN fail, the ultimate fallback strategy is automatically triggered, rewriting all static resource request paths to relative paths, so that the NGINX entry service directly responds to the static resources, completely eliminating page unavailability caused by a CDN failure.

[0072] Meanwhile, all probe files and homepage HTML files are uniformly configured with Cache-Control: no-cache, no-store, must-revalidate and Pragma: no-cache response headers, forcing the browser to make a new request every time it is accessed, completely avoiding the problem of probe results expiring and becoming invalid due to browser local caching.

[0073] The plugin supports flexible expansion. Adding a new vendor's CDN only requires adding the corresponding probe file and configuration items, without modifying the core logic, thus adapting to disaster recovery scenarios involving multiple vendors' CDNs.

[0074] Further, after step S03 above, which involves switching the access request of the user terminal according to the grayscale traffic switching result and processing the static resource request corresponding to the access request through the edge distribution unit, the method further includes: Step S04: Continuously monitor the running status and access response data of the service link corresponding to the target application version to obtain the running monitoring results; Step S05: Verify the functional integrity and operational stability of the target application version based on the operation monitoring results, and obtain the stability verification results; Step S06: If the stability verification result is passed, switch all user traffic to the service link corresponding to the target application version and mark the application update instruction as completed.

[0075] After the phased switchover of grayscale traffic is completed, system 7 We collect full-chain operation data of the new service 24 / 7, and break it down into five core monitoring dimensions: 1. Static resource request success rate, which counts the percentage of 2xx responses, with a threshold set at 99.99%; 2. Page first-screen loading time, which counts the time from user request to page full rendering, with a threshold set at less than 2 seconds; 3. Average interface response latency, with a threshold set at less than 200 milliseconds; 4. 404 / 5xx error reporting volume, with a threshold set at less than 10 errors per minute; and 5. CDN node origin pull rate, with a threshold set at less than 5%.

[0076] All metrics generate visualized monitoring reports with second-level granularity, supporting multi-dimensional filtering and anomaly alarms. Based on preset stability thresholds, the system automatically verifies the integrity of the new version's business process and the stability of the entire service chain. Through interface call chain analysis and business scenario data, it accurately identifies hidden faults such as version resource mismatch, node return-to-origin anomalies, and upstream and downstream link compatibility issues after gray-scale switching.

[0077] When all indicators meet the standards and there are no access anomalies or alarms triggered within three consecutive monitoring cycles (5 minutes per cycle), the system determines that the gray-scale verification is successful and starts the full traffic switching process. The remaining existing user traffic is gradually migrated in a gradient release mode of 5%→20%→50%→100%, with a 30-minute cooldown observation period set for each gradient. The system will proceed to the next release stage only after confirming that there are no anomalies.

[0078] If an abnormal indicator triggers an alarm during monitoring, the system supports one-click, second-level traffic rollback. By switching the gray-scale rule through the configuration center, all traffic is switched back to the old version link in milliseconds. At the same time, the abnormal situation log is retained for troubleshooting, ensuring zero failures in online business and no impact on users.

[0079] After switching traffic, a subsequent architecture switch is also required. Previously, this was handled using a traditional architecture, but internal staff are now using a CDN architecture for processing, such as... Figure 6 As shown, the initial migration from traditional architecture to CDN architecture adopts a physical isolation scheme between internal and external networks. A completely new CDN architecture application cluster is deployed independently. The cluster network is physically isolated from the online traditional business cluster, and traffic and data do not interfere with each other.

[0080] The new CDN architecture only opens up a dedicated test domain name on the internal network, does not connect to public DNS resolution, does not carry any online traffic, and has no impact on the operation of existing businesses.

[0081] R&D and testing personnel conducted four categories of full-scenario verifications using the internal network test domain: first, static resource distribution testing to verify parallel access to multiple versions of resources, caching strategies, and origin return logic; second, full-scale interface integration testing to verify front-end and back-end interface compatibility and data consistency; third, high-traffic stress testing to simulate peak traffic and verify cluster carrying capacity and stability; and fourth, fault degradation testing to simulate CDN node failures and verify the fallback capability of degradation plugins.

[0082] In advance, investigate underlying architectural issues such as CDN origin pull failures, multi-version resource conflicts, downgrade plugin failures, and cross-domain configuration anomalies. Only allow access to public network traffic after all internal network test cases have passed, performance indicators have met standards, and stability verification has been passed, thus avoiding large-scale online failures caused by direct deployment of the architecture from the source.

[0083] During the switching process, user access can also be appropriately integrated with CDN architecture applications, such as... Figure 7 As shown, after the internal network test and acceptance are passed, the public network gray-scale traffic access will be officially launched. During the release phase, all static resources of the new and old versions will be synchronized to object storage first, and then pushed to all CDN edge nodes for preheating to ensure that the online dual version resources coexist for a long time and are accessible at any time.

[0084] All gray-scale traffic control in the system is completed at the NGINX entry layer, without requiring any changes to the original business front-end and back-end code, resulting in extremely low intrusion into the business.

[0085] It supports flexible combinations of three traffic distribution modes: IP regional grayscale, suitable for gradual volume release by region; device-level grayscale, suitable for specific terminal user verification; and random code hash ratio grayscale, suitable for large-scale public network user release.

[0086] The random code uses an ASCII character cumulative hash algorithm, which iterates through the ASCII code value of each character in the random code and hashes it according to hash=hash. The 27+charCode iterative calculation finally yields a hash value of 0-999 by taking the modulo of 1000. The traffic ratio is controlled by a threshold.

[0087] The algorithm has undergone chi-square uniformity verification, and the distribution deviation is controlled within 1% for millions of samples, ensuring uniform flow distribution and avoiding local flow overload.

[0088] The system gradually increases public network traffic in a tiered manner, with the old and new architectures running in parallel on a dual-stack basis for an extended period. It fully supports adjusting the traffic distribution ratio at any time and one-click overall rollback, achieving zero traffic loss, no service interruption, and seamless user experience throughout the architecture migration process.

[0089] This embodiment, through the above-described scheme, specifically determines the target application version corresponding to the access request based on the gray-scale traffic switching result; switches the access request to the service link corresponding to the target application version through the entry service unit; and sends the homepage entry file corresponding to the target application version to the user terminal according to the service link of the target application version. Thus, the entry service unit uniformly accepts all user access requests, completes version matching and switching determination based on gray-scale traffic rules, ensuring that the version of the distributed page entry file is strictly consistent with the traffic distribution rules. Then, the edge distribution unit matches and processes the corresponding version of static resource requests, fundamentally avoiding access anomalies caused by page and resource version mismatches. The entire process is a gradual switch according to gray-scale rules until the update is complete, ensuring the smoothness and high availability of services in high-traffic stateless scenarios. This solves the problem of access anomalies caused by page and static resource version mismatches and insufficient smoothness and availability of update services during application version gray-scale switching in high-traffic stateless scenarios, improving the efficiency of traffic switching.

[0090] For example, to help understand the implementation flow of the traffic switching method obtained by combining this embodiment with the above embodiment one, please refer to... Figure 8 , Figure 8 A simplified flowchart of a traffic switching method is provided, specifically: The entire traffic switching method forms a closed-loop system with full-link linkage across seven stages: the front-end access processing layer completes user identifier resolution and regular canary traffic distribution; the version canary switching layer completes update command triggering, version adaptation verification, and seamless link switching; the node health detection layer completes three-level CDN node detection and redundant link construction; the static resource response layer completes versioned resource distribution and intelligent caching origin pull; the automatic fault degradation layer completes multi-level node fault fallback and NGINX ultimate protection; the full traffic switching layer completes stability monitoring and gradient rollback; and the architecture smooth migration layer completes dual-stack parallelism and lossless architecture upgrades.

[0091] The entire process is fully automated, requiring no manual intervention during the switching process. It addresses three major industry pain points at their root: 404 errors due to version mismatch in traditional front-end releases, service disconnection due to CDN node failures, and traffic loss during architecture migration. It also features high availability, scalability, and ease of maintenance, making it perfectly suited for online business scenarios with high concurrency and high availability requirements, such as finance, e-commerce, and government services.

[0092] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the traffic switching method of this application. Any simple modifications based on this technical concept are within the protection scope of this application.

[0093] This application also provides a flow switching device, please refer to... Figure 9 The traffic switching device is applied to the service response end, which includes an ingress service unit and an edge distribution unit. The traffic switching device includes: The receiving module 10 is used to receive access requests sent by the user terminal, process the access requests through the entry service unit according to the gray-scale traffic rules, and obtain the request result; The determination module 20 is used to determine the switching of the access request through the entry service unit when an application update instruction is received, and to obtain the gray-scale traffic switching result. The switching module 30 is used to switch the access request of the user terminal according to the gray-scale traffic switching result, and process the static resource request corresponding to the access request through the edge distribution unit until the application update instruction is completed.

[0094] The traffic switching device provided in this application, employing the traffic switching method described in the above embodiments, can solve the technical problem of access anomalies caused by mismatch between page and static resource versions during application version gray-scale switching in high-traffic, stateless scenarios, resulting in insufficient smoothness and availability of update services. Compared with the prior art, the beneficial effects of the traffic switching device provided in this application are the same as those of the traffic switching method provided in the above embodiments, and other technical features in the traffic switching device are the same as those disclosed in the methods of the above embodiments, and will not be repeated here.

[0095] This application provides a traffic switching device, which includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, which are executed by the at least one processor to enable the at least one processor to perform the traffic switching method in the above embodiment 1.

[0096] The following is for reference. Figure 10The diagram illustrates a structural schematic of a traffic switching device suitable for implementing embodiments of this application. The traffic switching device in the embodiments of this application may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital broadcast receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), PMPs (Portable Media Players), in-vehicle terminals (e.g., in-vehicle navigation terminals), and fixed terminals such as digital TVs and desktop computers. Figure 10 The traffic switching device shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0097] like Figure 10 As shown, the flow switching device may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory 1002 or a program loaded from a storage device 1003 into a random access memory 1004. The random access memory 1004 also stores various programs and data required for the operation of the flow switching device. The processing unit 1001, the read-only memory 1002, and the random access memory 1004 are interconnected via a bus 1005. An input / output interface 1006 is also connected to the bus. Typically, the following systems can be connected to the input / output interface 1006: input devices 1007 including, for example, a touchscreen, touchpad, keyboard, mouse, image sensor, microphone, accelerometer, gyroscope, etc.; output devices 1008 including, for example, a liquid crystal display (LCD), speaker, vibrator, etc.; storage devices 1003 including, for example, magnetic tape, hard disk, etc.; and communication devices 1009. Communication device 1009 allows the flow switching device to communicate wirelessly or wiredly with other devices to exchange data. While the figure shows flow switching devices with various systems, it should be understood that implementation or possession of all the systems shown is not required. More or fewer systems may be implemented alternatively.

[0098] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from read-only memory 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0099] The traffic switching device provided in this application, employing the traffic switching method described in the above embodiments, can solve the technical problem of access anomalies caused by mismatch between page and static resource versions during application version gray-scale switching in high-traffic, stateless scenarios, resulting in insufficient smoothness and availability of update services. Compared with the prior art, the beneficial effects of the traffic switching device provided in this application are the same as those of the traffic switching method provided in the above embodiments, and other technical features in this traffic switching device are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0100] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0101] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0102] This application provides a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, the computer-readable program instructions being used to execute the traffic switching method in the above embodiments.

[0103] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems or devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system or device. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0104] The aforementioned computer-readable storage medium may be included in the flow switching device; or it may exist independently and not be assembled into the flow switching device.

[0105] The aforementioned computer-readable storage medium carries one or more programs. When these programs are executed by the traffic switching device, the traffic switching device: receives an access request sent by a user terminal; processes the access request through the ingress service unit according to the gray-scale traffic rules to obtain a request result; upon receiving an application update instruction, performs a switching determination on the access request through the ingress service unit to obtain a gray-scale traffic switching result; performs traffic switching on the user terminal's access request according to the gray-scale traffic switching result; and processes the static resource request corresponding to the access request through the edge distribution unit until the application update instruction completes the update.

[0106] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a Local Area Network (LAN) or a Wide Area Network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0107] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0108] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0109] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., a computer program) for executing the above-described traffic switching method. This solves the technical problem of access anomalies caused by mismatch between page and static resource versions, and insufficient smoothness and availability of update services during application version gray-scale switching in high-traffic, stateless scenarios. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the traffic switching method provided in the above embodiments, and will not be elaborated upon here.

[0110] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the traffic switching method described above.

[0111] The computer program product provided in this application can solve the technical problem of access anomalies caused by mismatch between page and static resource versions during application version gray-scale switching in high-traffic, stateless scenarios, and insufficient smoothness and availability of update services. Compared with the prior art, the beneficial effects of the computer program product provided in this application are the same as those of the traffic switching method provided in the above embodiments, and will not be repeated here.

[0112] The above description is only a part of the embodiments of this application and does not limit the patent scope of this application. All equivalent structural transformations made under the technical concept of this application and using the contents of the specification and drawings of this application, or direct / indirect applications in other related technical fields, are included in the patent protection scope of this application.

Claims

1. A traffic switching method, characterized in that, The traffic switching method is applied to the service response end, which includes an ingress service unit and an edge distribution unit. The traffic switching method includes: Receive access requests sent by user clients, process the access requests through the entry service unit according to the gray-scale traffic rules, and obtain the request results; Upon receiving an application update instruction, the entry service unit performs a switching determination on the access request to obtain the gray-scale traffic switching result. Based on the gray-scale traffic switching result, the access request of the user terminal is switched, and the static resource request corresponding to the access request is processed by the edge distribution unit until the application update instruction is completed.

2. The traffic switching method as described in claim 1, characterized in that, The step of processing the access request through the entry service unit according to the gray-scale traffic rules to obtain the request result includes: Extract traffic identification information from the access request; The grayscale traffic rules are used to perform rule matching on the traffic identification information to obtain the matching result; The access application version corresponding to the access request is determined based on the matching result. Based on the accessed application version, the application homepage entry file is retrieved through the entry service unit as the request result, and the request result is sent to the user terminal.

3. The traffic switching method as described in claim 1, characterized in that, The step of determining the switching of the access request through the entry service unit to obtain the gray-scale traffic switching result includes: According to the application update instruction, the updated gray-scale switching rules and version mapping relationships are loaded through the entry service unit; The access request version is adapted and verified according to the updated gray-scale switching rules to obtain the version adaptation verification result. If the version compatibility verification result is passed, the target application version is determined through the version mapping relationship; The grayscale traffic switching result is generated based on the target application version.

4. The traffic switching method as described in claim 1, characterized in that, The step of switching the access request of the user terminal according to the gray-scale traffic switching result includes: The target application version corresponding to the access request is determined based on the gray-scale traffic switching result. The access request is switched to the service link corresponding to the target application version through the entry service unit; The homepage entry file corresponding to the target application version is sent to the user terminal according to the service link of the target application version.

5. The traffic switching method as described in claim 4, characterized in that, Before the step of processing the static resource request corresponding to the access request through the edge distribution unit, the method further includes: After detecting that the user terminal loads the homepage entry file, the response detection is performed on several nodes of the edge distribution node to obtain the response status and response content of the several nodes; The availability of the nodes is determined based on the response status and response content, and an availability determination result is obtained. The availability judgment result determines the available hierarchical resource service link, which is used to process the static resource request corresponding to the access request through the edge distribution unit.

6. The traffic switching method as described in claim 1, characterized in that, The step of processing the static resource request corresponding to the access request through the edge distribution unit includes: The static resource request is parsed to obtain the resource version identifier and resource path; Based on the resource version identifier and resource path, the edge distribution unit performs resource file matching on the local cache to obtain the resource matching result. Based on the resource matching results, a static resource access result is sent to the user terminal.

7. The traffic switching method as described in claim 4, characterized in that, After the steps of switching the access request of the user terminal according to the gray-scale traffic switching result and processing the static resource request corresponding to the access request through the edge distribution unit, the method further includes: Continuously monitor the running status and access response data of the service links corresponding to the target application version to obtain the running monitoring results; Based on the operational monitoring results, the functional integrity and operational stability of the target application version are verified to obtain the stability verification results. If the stability verification result is passed, all user traffic will be switched to the service link corresponding to the target application version, and the application update instruction will be marked as completed.

8. A flow switching device, characterized in that, The traffic switching device is applied to the service response end, which includes an ingress service unit and an edge distribution unit. The traffic switching device includes: The receiving module is used to receive access requests sent by the user terminal, process the access requests through the entry service unit according to the gray-scale traffic rules, and obtain the request result; The determination module is used to determine the switching of the access request through the entry service unit when an application update instruction is received, and to obtain the gray-scale traffic switching result. The switching module is used to switch the access request of the user terminal according to the gray-scale traffic switching result, and process the static resource request corresponding to the access request through the edge distribution unit until the application update instruction is completed.

9. A flow switching device, characterized in that, The device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the traffic switching method as described in any one of claims 1 to 7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the steps of the traffic switching method as described in any one of claims 1 to 7.

Images