Traffic splitting method, storage medium, and electronic device

Abstract

The present disclosure provides a traffic splitting method, a storage medium, and an electronic device. The method comprises: acquiring a first request message; converting the first request message to generate an accompanying data packet; in the process of a service call chain transmitting the accompanying data packet, using a service mesh proxy corresponding to each application service in the service call chain to generate a target routing rule on the basis of the accompanying data packet; and routing the first request message to a target workload of a target application service on the basis of the target routing rule. The present disclosure solves the technical problems in the related art of poor routing accuracy and the inability to precisely control request routing by means of dynamic routing overlay metadata during traffic splitting in a service mesh.

Description

[0001] TECHNICAL FIELD The present disclosure relates to the field of service grids, and more specifically, to a traffic diversion method, storage medium, and electronic device. Background: A service grid is an infrastructure for managing and connecting distributed microservices. It provides a unified approach to managing multiple microservices and offers advanced features such as traffic management, routing, and security policies, helping organizations better manage complex microservice architectures. Traffic diversion can help manage and control traffic within a service grid, thereby improving service performance, reliability, and manageability. Related art uses routing keywords to make routing decisions during requests to achieve traffic diversion. However, this traffic diversion approach struggles to precisely control the routing of request messages, resulting in poor routing accuracy when performing traffic diversion within a service grid. Currently, no effective solutions have been proposed to address these issues. SUMMARY OF THE INVENTION Embodiments of the present disclosure provide a traffic diversion method, storage medium, and electronic device to at least address the technical issues of related art, such as poor routing accuracy when performing traffic diversion within a service grid and the inability to precisely control request routing through dynamic routing overlay metadata. According to one aspect of an embodiment of the present disclosure, a traffic diversion method is provided, comprising: obtaining a first request message, wherein the first request message is used to represent a portion of request messages to be diverted in a service grid; converting the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, and the dynamic routing overlay metadata is used to determine a target application service corresponding to the first request message, wherein the target application service is used to represent a diverted application service corresponding to at least one instance application service in the service grid; generating a target routing rule based on the accompanying data packet using a service grid agent corresponding to each application service in the service call link during transmission of the accompanying data packet; and routing the first request message to a target workload of the target application service according to the target routing rule. According to another aspect of an embodiment of the present disclosure, a traffic diversion method is provided, comprising: obtaining a target test request, wherein the target test request is used to represent a portion of test requests to be diverted in a service grid; converting the target test request to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing coverage metadata, and the dynamic routing coverage metadata is used to determine a target application service corresponding to the target test request, wherein the target application service is used to represent a diverted application service corresponding to at least one instance application service in the service grid; during transmission of the accompanying data packet in a service call link, generating a target routing rule based on the accompanying data packet using a service grid agent corresponding to each application service in the service call link; and routing the target test request to a target workload of the target application service according to the target routing rule.According to another aspect of an embodiment of the present disclosure, a traffic offloading system is provided, comprising: a gateway and multiple application services configured on a service invocation link; the gateway, configured to convert and process received request messages to generate accompanying data packets, wherein the request messages represent a portion of request messages to be offloaded in the service grid; the accompanying data packets contain dynamic routing overlay metadata, the dynamic routing overlay metadata being used to determine a target application service corresponding to the request message; the target application service representing the offloaded application service corresponding to at least one instance application service in the service grid; and the multiple application services, configured to generate target routing rules based on the accompanying data packets during transmission of the accompanying data packets on the service invocation link, and to route the request messages to target workloads of the target application services according to the target routing rules. According to another aspect of an embodiment of the present disclosure, a computer-readable storage medium is provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is executed, the device containing the computer-readable storage medium is controlled to execute any one of the traffic offloading methods of the embodiments of the present disclosure. According to another aspect of the present disclosure, an electronic device is provided, including: a memory storing an executable program; and a processor configured to execute the program, wherein when the program executes, the traffic diversion method according to any one of the embodiments of the present disclosure is executed. According to another aspect of the present disclosure, a computer program product is provided, including the computer program. When executed by the processor, the computer program implements the traffic diversion method according to any one of the embodiments of the present disclosure. In an embodiment of the present disclosure, a first request message to be offloaded in a service grid is obtained, and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to determine the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along the service invocation link, the service grid proxy corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the first request message is routed to the target workload of the target application service according to the target routing rule. This achieves the goal of efficiently offloading traffic in the service grid, thereby improving routing accuracy and service invocation efficiency in the service grid. This solves the technical problems of poor routing accuracy and the inability to accurately control request routing using dynamic routing overlay metadata when performing traffic offload in a service grid in related technologies. It should be noted that the general description above and the detailed description below are merely examples and explanations of the present disclosure and do not constitute limitations of the present disclosure.BRIEF DESCRIPTION OF THE DRAWINGS The drawings described herein are used to provide a further understanding of the present disclosure and constitute a part of the present disclosure. The illustrative embodiments of the present disclosure and their descriptions are used to explain the present disclosure and do not constitute an improper limitation on the present disclosure. In the accompanying drawings: FIG1 is a hardware block diagram of a computer terminal (or mobile device) for implementing a traffic diversion method according to Example 1 of the present disclosure; FIG2 is a schematic diagram of a communication system for a traffic diversion method according to Example 1 of the present disclosure; FIG3 is a flow chart of a traffic diversion method according to Example 1 of the present disclosure; FIG4 is a schematic diagram of a process for generating an accompanying data packet according to Example 1 of the present disclosure; FIG5 is a schematic diagram of a service grid according to Example 1 of the present disclosure; FIG6 is a schematic diagram of a traffic diversion method according to Example 1 of the present disclosure; FIG7 is a schematic diagram of a testing process of a traffic diversion method according to Example 1 of the present disclosure; FIG8 is a schematic diagram of another traffic diversion method according to Example 1 of the present disclosure; FIG9 is a flow chart of a traffic diversion method according to Example 2 of the present disclosure; FIG10A is a structural block diagram of a traffic diversion device according to Example 3 of the present disclosure; FIG10B is a structural block diagram of another traffic diversion device according to Example 3 of the present disclosure; FIG11 is a structural block diagram of another traffic diversion device according to Example 3 of the present disclosure; Figure 12 is a block diagram of a computer terminal according to Embodiment 4 of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS To help those skilled in the art better understand the present disclosure, the technical solutions in the embodiments of the present disclosure will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments represent only a portion of the present disclosure, and are not exhaustive. Based on the embodiments of the present disclosure, all other embodiments devised by persons of ordinary skill in the art without inventive effort should fall within the scope of protection of the present disclosure. It should be noted that the terms "first," "second," and so on, in the specification and claims of the present disclosure, and in the accompanying drawings, are used to distinguish similar objects and are not necessarily used to describe a specific order or precedence. It should be understood that such terms are interchangeable where appropriate, so that the embodiments of the present disclosure described herein can be implemented in an order other than that illustrated or described herein. In addition, the terms "comprises" and "having" and any variations thereof are intended to cover a non-exclusive inclusion. For example, a process, method, system, product or apparatus that includes a series of steps or elements is not necessarily limited to those steps or elements expressly listed but may include other steps or elements not expressly listed or inherent to such process, method, product or apparatus.First, some nouns or terms that appear in the description of the embodiments of this disclosure are subject to the following explanations: Service mesh: Commonly used to describe the network of microservices that make up an application and the interactions between them. As the infrastructure layer that handles inter-service communication, the service mesh is responsible for reliably delivering requests by constructing the complex service topology of modern cloud-native applications. Service mesh proxy: A service mesh generally consists of a control plane and a data plane. Specifically, the control plane is a set of services running in a dedicated namespace. These services perform control and management functions, including aggregating telemetry data, providing user-facing application programming interfaces (APIs), and providing control data to data plane proxies. Together, they drive the behavior of the data plane. The data plane is composed of a series of transparent proxies running alongside each service instance. Example 1 According to an embodiment of the present disclosure, a method embodiment of a traffic offloading method is also provided. It should be noted that the steps shown in the flowcharts of the accompanying figures can be executed in a computer system, such as a set of computer-executable instructions. Although the flowcharts show a logical order, in some cases, the steps shown or described can be executed in a different order than shown. The method embodiment provided in the first embodiment of the present disclosure can be executed in a mobile terminal, a computer terminal, or a similar computing device. Figure 1 is a hardware block diagram of a computer terminal (or mobile device) for implementing the traffic diversion method according to the first embodiment of the present disclosure. As shown in Figure 1 , the computer terminal 10 (or mobile device) may include one or more processors 102 (illustrated as 102a, 102b, 102n in the figure) (processor 102 may include, but is not limited to, a microcontroller unit (MCU) or a field programmable gate array (FPGA)), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, the device may also include: a display, an input / output interface (I / O interface), a universal serial bus (USB) port (which may be included as one of the ports of a BUS), a network interface, a power supply, and / or a camera. Those skilled in the art will appreciate that the structure shown in Figure 1 is merely illustrative and does not limit the structure of the electronic device described above.For example, the computer terminal 10 may include more or fewer components than shown in FIG. 1 , or have a configuration different from that shown in FIG. It should be noted that the one or more processors 102 and / or other data processing circuits described above may generally be referred to herein as "data processing circuitry." This data processing circuitry may be embodied in whole or in part as software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuitry may be a single, independent processing module, or may be fully or partially integrated into any of the other components of the computer terminal 10 (or mobile device). As described in the embodiments of the present disclosure, the data processing circuitry functions as a processor control (e.g., selecting a variable resistor terminal path connected to an interface). The memory 104 may be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the traffic diversion method described in the embodiments of the present disclosure. The processor 102 executes the software programs and modules stored in the memory 104 to execute various functional applications and data processing, thereby implementing the aforementioned traffic diversion method. Memory 104 may include high-speed random access memory (RAM) and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, memory 104 may further include memory located remotely from processor 102, which can be connected to computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks (LANs), mobile communication networks, and combinations thereof. Transmission device 106 is used to receive or transmit data via a network. Specific examples of such networks may include a wireless network provided by the computer terminal 10's communications provider. In one instance, transmission device 106 includes a network interface controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In one instance, transmission device 106 may be a radio frequency (RF) module for wireless communication with the Internet. The display may be, for example, a touchscreen liquid crystal display (LCD), which enables a user to interact with the user interface of computer terminal 10 (or mobile device).The hardware structure block diagram shown in FIG1 can serve not only as an exemplary block diagram of the aforementioned computer terminal 10 (or mobile device), but also as an exemplary block diagram of the aforementioned server. In an alternative embodiment, FIG2 is a schematic diagram of a communication system for a traffic offload method according to Embodiment 1 of the present disclosure. FIG2 illustrates, as a block diagram, an embodiment using the computer terminal 10 (or mobile device) shown in FIG1 as a receiving end. As shown in FIG2 , the computer terminal 10 (or mobile device) can be connected to one or more servers, such as a security server, a resource server, a game server, etc., via a data network connection or electronic connection. In an alternative embodiment, the computer terminal 10 (or mobile device) can be any mobile computing device. The data network connection can be a local area network connection, a wide area network connection, an Internet connection, or other types of data network connections. The computer terminal 10 (or mobile device) can be connected to a network service performed by a server (e.g., a security server) or a group of servers 20. Network servers are network-based user services, such as social networks, cloud resources, email, online payment, or other online applications. In the above-mentioned operating environment, the present disclosure provides a traffic diversion method as shown in Figure 3. Figure 3 is a flowchart of a traffic diversion method according to Example 1 of the present disclosure. As shown in Figure 3, the method includes the following steps: Step S31: Obtaining a first request message, wherein the first request message is used to represent a portion of request messages to be diverted in the service grid; Step S32: Converting the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, which is used to determine the target application service corresponding to the first request message, and the target application service is used to represent the diverted application service corresponding to at least one instance application service in the service grid; Step S33: During transmission of the accompanying data packet in the service invocation link, the service grid agent corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet; Step S34: Routing the first request message to the target workload of the target application service according to the target routing rule. The first request message is a specific request message that needs to be diverted to the target application service for processing. Specifically, the first test request can be a test request or a specific request in an actual production environment. The first request message can be a request from a front-end application to a back-end service, or a request for communication between different microservices. The first request message can involve, but is not limited to, various functions such as data transmission, authentication, authorization, and monitoring.Therefore, the service mesh needs to effectively manage and process these different types of requests to ensure system stability, reliability, and security. The first request message is converted to generate an accompanying data packet containing dynamic routing override metadata to guide the flow of the first request message within the service mesh. This accompanying data packet is a data format transmitted within the service call chain. It contains dynamic routing override metadata, which is used to identify the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service mesh. Transmission of the accompanying data packet within the service call chain propagates the dynamic routing override metadata throughout the service mesh. In the corresponding upstream call, the mesh proxy filter of each application service in the service call chain changes the route to the corresponding offload application deployment. The target application service is a offload application deployment created in a pre-production or production environment. This offload application deployment does not register with the service mesh's service discovery function, so other request messages are not routed to the target application service. This ensures isolation between the target application service and the instance application services in the main traffic environment while also allowing specific first request messages to be routed to the offload target application service. In the disclosed embodiments, offloaded application deployment refers to the process of shifting a portion of the request traffic load from the primary version environment to another environment (such as an environment requiring phased validation), specifically deploying a new version of an application. This allows for testing new service versions or configuration changes without impacting the primary production environment. Offloaded application deployment diverts traffic and request load, shifting some of the traffic or processing pressure from the primary production environment to other environments to test new service versions or configuration changes. Offloaded application deployment also reduces disruption to the production environment. By deploying and testing changes in a non-production environment, the impact on running production services is minimized, helping to maintain the stability and reliability of the production environment while still allowing for testing and validation of new changes. Offloaded application deployment can utilize a progressive release approach, with new versions of application services first deployed in a secondary environment to monitor their performance before deciding whether to push them to the production environment. Furthermore, by shifting portions of the deployment process to a specific environment, organizations can more optimally allocate and utilize resources, for example, by performing large updates at night or during off-peak hours, reducing resource waste.The service invocation chain includes multiple application services, each of which has multiple workloads. After receiving an accompanying data packet, the application service in the service invocation chain analyzes the accompanying data packet to determine a target routing rule. The target routing rule can be used to route the first request message to a target workload of the target application service. The target workload is any one of the multiple workloads corresponding to the target application service. Based on steps S31 to S34 above, a first request message to be offloaded in the service grid is obtained and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to identify the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along the service invocation link, the service grid agent corresponding to each application service in the service invocation link extracts rules from the accompanying data packet to obtain rule extraction results. The rule extraction results are then integrated with preset routing rules to obtain target routing rules. Finally, the first request message is routed to the target workload of the target application service according to the target routing rules. This achieves efficient traffic offload in the service grid, thereby improving routing accuracy and service invocation efficiency in the service grid. This solves the technical problems of poor routing accuracy in traffic offload in the service grid and the inability to accurately control request routing using dynamic routing overlay metadata in related technologies. The traffic offload method according to the disclosed embodiments is further described below. In an optional embodiment, in step S32, converting the first request message to generate an accompanying data packet further includes: step S321, obtaining first metadata based on the first request message; step S322, determining dynamic routing overlay metadata and second metadata corresponding to the target application service based on the first metadata, wherein the second metadata is used to describe the port information and network address corresponding to the target application service; and step S323, generating an accompanying data packet based on the dynamic routing overlay metadata and the second metadata. In an optional embodiment, the first metadata includes at least one of the following: request header information, request body information, request query string information, and request path parameter information. Specifically, the disclosed embodiment can utilize a context processor to convert the first request message to generate the accompanying data packet. The first metadata obtained based on the first request message includes at least one of the following: request header information, request body information, request query string information, and request path parameter information.Exemplarily, the first metadata is the request header metadata corresponding to the first request message. Dynamic routing override metadata and the port information and IP address corresponding to the target application service are determined based on the request header information, and an accompanying data packet is generated based on the dynamic routing override metadata and the port information and IP address corresponding to the target application service. It should be noted that in the disclosed embodiment, the traffic diversion method is described using the first metadata as the request header information, but this does not constitute a specific limitation. Based on the above optional embodiment, by obtaining the first metadata based on the first request message, determining the dynamic routing override metadata and the second metadata corresponding to the target application service based on the first metadata, and finally generating the accompanying data packet based on the dynamic routing override metadata and the second metadata, the flow of the first request message in the service grid can be flexibly and accurately guided, further improving routing accuracy. In an optional embodiment, determining the dynamic routing override metadata based on the first metadata in step S322 includes: step S3221: obtaining context information, where the context information includes different request metadata and corresponding dynamic routing override metadata; and step S3222: querying the context information to obtain dynamic routing override metadata based on the first metadata. Continuing with the example of the first metadata being the request header information, the context information includes a series of context objects, each of which defines a set of routing override rules based on specific request header information. For example, the context object may be: Dynamic routing override metadata (routingOverrides) is provided. The dynamic routing override metadata may include, but is not limited to, configuration items such as the service name (serviceName), label selector (label Selector), and environment variables (environmentvariables). This information can be used to override and modify routing and environment variables during service invocation to meet specific requirements or conditions. Dynamic routing override metadata is obtained by querying the context information based on the first metadata and embedded into the request header information, enabling the first request message to be correctly routed to the specified offload application deployment. In an optional embodiment, in step S322, determining second metadata based on the first metadata includes: step S3223, querying the target application service from the target cluster using the first metadata; and step S3224, determining second metadata corresponding to the target application service based on the dynamic routing override metadata. Specifically, the target application service corresponding to the first request message is queried based on the first metadata, that is, by querying the container (Pod) information of the Kubemetes cluster, according to the serviceName in the dynamic routing overlay metadata, the second metadata corresponding to the corresponding target application service can be obtained, including but not limited to the IP address and port information, so that the target application service can be accurately located according to the second metadata. Figure 4 is a schematic diagram of a process of generating an accompanying data packet according to Example 1 of the present disclosure. As shown in Figure 4, the request header information is determined based on the first request message, the corresponding context information is obtained based on the request header information, and then the dynamic routing overlay metadata is obtained from the context information. The target application service corresponding to the first request message is queried based on the request header information, that is, by querying the Pod information of the Kubernetes cluster, according to the serviceName in the dynamic routing overlay metadata, the IP address and port information corresponding to the corresponding target application service can be obtained. An accompanying data packet is generated based on the dynamic routing overlay metadata and the IP address and port information corresponding to the target application service. For example, an example of a data structure of context information is shown in Table 1 below: Table 1 Specifically, as shown in Table 1, the above context information can be applied to the service grid. The routing override rules can change dynamically based on the request metadata. For example, when the first request message arrives, the service grid entry gateway checks the current value of the request header "x-asm-request-id" in the first request message. If the current value of the request header "x-asm-request-id" is "aaaOOl", the routing override rules in the routing context object 1 will be applied to override the routing and configuration of "serviceOOl". Similarly, if the current value of the request header "x-asm-request-id" is "aaa002", the routing override rules in the context object 2 will be applied. This may affect the routing and configuration of one or more services (such as "serviceOOl" and "service002"). Exemplarily, when the request header information is x-asm-request-id:aaa001, the accompanying data packet generated by the conversion is shown in Table 2 below: Table 2 Specifically, the data structure shown in Table 2 represents a companion data packet format that carries service-specific routing and configuration override information. This accompanying data packet format is commonly used in microservices or service mesh architectures to convey additional routing and configuration information during internal service calls. The accompanying data packet structure allows service callers to dynamically specify the behavior of the target service when sending a request, such as instance selection and configuration changes, without having to modify the service's code or configuration. This accompanying data packet enables flexible routing strategies, such as intelligent routing based on request attributes, traffic splitting, and on-demand service configuration adjustments. If a specific application service receives a first request message containing the accompanying data packet, it can parse the dynamic routing metadata to forward the first request message to the specified IP address and port, and configure the environment variables specified by the calling application. This makes communication between different application services more flexible and dynamic, and supports complex operations and maintenance requirements, including but not limited to traffic management, software release strategies such as blue-green deployment, and online experimental methods such as splitting and split testing. For example, when the request header information is x-asm-request-id:aaa002, the accompanying data packet generated by conversion is shown in Table 3 below: Table 3 In an optional embodiment, in step S333, routing the first request message to the target workload of the target application service according to the target routing rule includes: routing the first request message to the target workload of the target application service via multiple application services in the service invocation chain according to the target routing rule. Specifically, to ensure that user-defined settings can be implemented throughout the entire request processing process, the continuity of the request header information must be maintained. All application services in the service invocation chain, regardless of whether they directly use the request header information, can receive and transmit the user-specified settings. When the first request message needs to be processed sequentially by multiple application services, each application service can correctly transmit the accompanying data packet to the specific workload of the next service. In an optional embodiment, the traffic offloading method in the disclosed embodiment further includes: receiving an accompanying data packet from the first application service; and, in response to the first application service invoking the second application service, transmitting the accompanying data packet from the first application service to the second application service. The first and second application services described above have an upstream-downstream calling relationship, with the first application service being the upstream application service and the second application service being the downstream application service. After receiving an accompanying data packet from the upstream application service and then invoking the downstream application service, the accompanying data packet is then transmitted to the downstream application service, thereby enabling tracing management for multiple application services in the service call chain. Specifically, automatic instrumentation technology enables request header information to be received and propagated accordingly by each application service along the way. Automatic instrumentation allows developers to seamlessly integrate tracing capabilities into their applications with minimal or no manual code modifications. Automatic instrumentation tools recognize common libraries and frameworks and automatically capture relevant tracing information at runtime, such as the request start, end, and any important intermediate steps. When automatic instrumentation is enabled, accompanying data packet propagation is automatically handled. Specifically, when a service receives the first request message, it can read the associated tracing context, including any accompanying data packets. When the accompanying data packet is transmitted in the service invocation chain, it is intercepted by the service grid proxy corresponding to each application service in the service invocation chain. The rule coverage information extractor in the service grid proxy can extract rules from the accompanying data to obtain the IP address corresponding to the target application service, i.e., the rule extraction result. Furthermore, the rule extraction result is integrated with the preset routing rules in the current application service to generate a processed rule configuration, i.e., the target routing rule. The first request message is then routed and forwarded to the new target application service deployment address through the filter in the service grid proxy.During any external call, an accompanying data packet is sent to the downstream service along with the first request message. This can be achieved through Hypertext Transfer Protocol (HTTP) headers or other suitable transmission mechanisms, and is not limited by the present embodiment. Based on the above optional embodiment, it is possible to ensure that the accompanying data packet and other tracking information are correctly transmitted and maintained during each service call. In an optional embodiment, the traffic diversion method in the present embodiment further includes: obtaining first service registration information, where the first service registration information is used to represent the registration information corresponding to the application services included in the service grid; filtering the first service registration information based on preset filtering conditions to obtain second service registration information, where the preset filtering conditions are used to identify the anti-service discovery tag corresponding to the target application service, and the second service registration information is used to represent the registration information corresponding to the instance application service; and pushing the second service registration information to the service grid proxy, so that the service grid proxy routes the second request message to the instance application service, where the second request message is used to represent the remaining request messages in the service grid except the first request message. Specifically, the second request message is the remaining request message in addition to the first request message. The second request message does not need to be routed to the target application service for processing, thereby preventing inter-service calls from not meeting expectations. For example, an anti-service discovery configuration definer is used to define whether a description meets preset filtering criteria. For example, the preset filtering criteria can include whether pod metadata contains specific labels, or a custom description file is created to describe which pods need to be filtered. The preset filtering criteria generated by the anti-service discovery configuration definer are included in the monitoring of the application load listener. When the corresponding target application service is discovered, the service discovery data processor excludes the application load from the originally collected first service registration information and only pushes the second service registration information that does not include the target application service to the service mesh proxy. Service discovery can be blocked using pod labels. For example, any application deployment that includes the anti-service discovery label "servicemesh-servicediscovery-offloaded: true" or the anti-service discovery label "exclude-from-discovery: true" will be filtered out. In order to exclude it from service discovery, the control plane embeds additional information in the Kubernetes pod label to indicate that the Pod has been uninstalled and diverted.Based on the above optional embodiment, by obtaining first service registration information, filtering the first service registration information based on preset filtering conditions to obtain second service registration information, and finally pushing the second service registration information to the service grid proxy, the service grid proxy routes the second request message to the instance application service, thereby achieving anti-service discovery, ensuring that inter-service calls meet expectations and further improving routing accuracy within the service grid. In an optional embodiment, the traffic diversion method in the disclosed embodiment further includes: in response to performing a replacement operation on the instance application service using the target application service, deleting the anti-service discovery tag corresponding to the target application service, so that the target application service enters the service discovery scope of the service grid. Specifically, when the target application reading material is ready to be rolled to the mainline version, the corresponding anti-service discovery tag can be deleted, so that the target application service will be re-discovered and enter the discovery scope of the service grid. In an optional embodiment, in step S33, generating a target routing rule based on the accompanying data packet using the service grid proxy corresponding to each application service in the service invocation link includes: step S331, extracting rules from the accompanying data packet using the service grid proxy corresponding to each application service in the service invocation link to obtain a rule extraction result; and step S332, fusing the rule extraction result with the preset routing rule to obtain the target routing rule. Specifically, when the accompanying data packet is transmitted in the service invocation link, it is intercepted by the service grid proxy corresponding to each application service in the service invocation link. The rule coverage information extractor in the service grid proxy can extract rules from the accompanying data to obtain the IP address corresponding to the target application service, i.e., the rule extraction result. Furthermore, the rule extraction result is fusing with the preset routing rule in the current application service to generate a processed rule configuration, i.e., the target routing rule. The first request message is then routed to the new target workload through a filter in the service grid proxy. Based on the above optional embodiment, the service grid proxy corresponding to each application service in the service call link extracts rules from the accompanying data packet to obtain rule extraction results. The rule extraction results are then integrated with the preset routing rules to obtain accurate target routing rules, thereby accurately routing the first request information. The traffic diversion method in this embodiment of the present disclosure is described below in conjunction with services.Figure 5 is a schematic diagram of a service grid according to Embodiment 1 of the present disclosure. This service grid 500 is primarily used to facilitate secure and reliable communication between multiple microservices. Microservices refer to applications that are decomposed into multiple smaller services or instances and distributed across different clusters / machines. As shown in Figure 5 , an application is decomposed into two microservices, including application service instance A and application service instance B. Application service instance A and application service instance B form the functional application layer of service grid 500. For example, an e-commerce application allows users to browse and purchase products. Users can browse product catalogs, view product details, add products to shopping carts, and check out. This e-commerce application is decomposed into two microservices. Application service instance A can be a product management service responsible for handling product catalogs, product details, and product inventory. Application service instance B can be a shopping cart and checkout service responsible for managing users' shopping carts, calculating order totals, and performing checkout. In one embodiment, application service instances A and B run as containers / processes on a machine / workload container group 508 (POD). In one embodiment, application service instance A may be a product query service, and application service instance B may be a product ordering service. As shown in Figure 5 , application service instance A and grid proxy (sidecar) 503 coexist in machine workload container group 514, while application service instance B and grid proxy 505 coexist in machine workload container 514. Grid proxies 503 and 505 form the data plane layer of service grid 500. Grid proxies 503 and 505 run as containers / processes 504 and 506, respectively. Grid proxy 503 and application service instance A can communicate bidirectionally, while grid proxy 505 and application service instance B can communicate bidirectionally. Furthermore, grid proxy 503 and grid proxy 505 can also communicate bidirectionally with each other. In one embodiment, all traffic for application service instance A is routed to the appropriate destination via grid proxy 503, and all network traffic for application service instance B is routed to the appropriate destination via grid proxy 505. It should be noted that the network traffic mentioned herein includes, but is not limited to, HTTP, REST, gRPC, Redis, and other formats.In one embodiment, the functionality of the extended data plane layer can be implemented by writing custom filters for the proxy (Envoy) in service mesh 500. Service mesh proxy configuration can be designed to enable the service mesh to correctly proxy service traffic, enabling service interoperability and service governance. Mesh proxy 503 and mesh proxy 505 can be configured to perform at least one of the following functions: service discovery, health checking, routing, load balancing, authentication and authorization, and observability. As shown in FIG5 , service mesh 500 also includes a control plane layer. The control plane layer can be comprised of a set of services running in a dedicated namespace, hosted by a managed control plane component 501 on a machine / workload container group (machine / pod) 502. As shown in FIG5 , managed control plane component 501 communicates bidirectionally with mesh proxy 503 and mesh proxy 505. Managed control plane component 501 is configured to perform certain control and management functions. For example, managed control plane component 501 receives telemetry data transmitted by mesh proxy 503 and mesh proxy 505 and can further aggregate this telemetry data. For these services, managed control plane component 501 can also provide user-oriented application programming interfaces (APIs) to facilitate manipulation of network behavior and provide configuration data to mesh proxy 503 and mesh proxy 505. Figure 6 is a schematic diagram of a traffic diversion method according to Embodiment 1 of the present disclosure. As shown in Figure 6, request header information is determined based on a first request message, corresponding context information is obtained based on the request header information, and dynamic routing overlay metadata is then obtained from the context information. The target application service corresponding to the first request message is queried based on the request header information. Specifically, by querying the Pod information of the Kubernetes cluster, the IP address and port information corresponding to the target application service can be obtained based on the serviceName in the dynamic routing overlay metadata. An accompanying data packet is generated based on the dynamic routing overlay metadata and the IP address and port information corresponding to the target application service.When the accompanying data packet is transmitted within the service grid, it is intercepted by the service grid proxy of application service A. The rule coverage information extractor in the service grid proxy extracts rules from the accompanying data, thereby obtaining the IP address corresponding to the target application service, i.e., the rule extraction result. Furthermore, the rule extraction result is combined with the preset routing rules within the current application service to generate a processed rule configuration, i.e., the target routing rule. The first request message is then routed and forwarded to application service B through the filter in the service grid proxy. Simultaneously, the accompanying data packet propagator uses automatic instrumentation technology to transmit the accompanying data packet to the specific workload of application service B. Application service B performs a similar processing as application service A, and will not be further described. Figure 7 is a schematic diagram of the testing process of a traffic diversion method according to Example 1 of the present disclosure. As shown in Figure 7, the base version of all microservices in the application is defined as the baseline environment. The baseline environment serves as the default version for each microservice in the environment, and its contents are continuously updated with each release process. For each new development / test, or even staging environment, only the changes are deployed—that is, the updated portion within the sandbox environment, such as Application Service B and Application Service D, or Application Service C and Application Service D. This typically represents a small number of microservices compared to the overall number, sharing any unchanged dependencies with the baseline environment. The traffic diversion method in the disclosed embodiments plays a crucial role in the software development lifecycle, allowing testing in an environment similar to production. It emphasizes fully isolating microservices to create a sandbox environment that can be used during development. This allows the service system to validate new service versions in different staging environments and supports staged testing based on actual production traffic, ultimately achieving a seamless transition to full production deployment. Figure 8 is a schematic diagram of another traffic diversion method according to Example 1 of the present disclosure. As shown in Figure 8, the first request message corresponding to user C can be converted and processed by the context processor in the ingress gateway to generate an accompanying data packet. The accompanying data packet is first transmitted to the workload of application service A and intercepted by the service grid agent of application service A. The rule coverage information extractor in the service grid agent can extract rules from the accompanying data packet, thereby obtaining the IP address corresponding to the target application service, that is, the rule extraction result.Furthermore, based on the rule extraction results and the preset routing rules within the current application service, a fusion process is performed to generate a processed rule configuration, i.e., a target routing rule. The first request message is then routed and forwarded through a filter in the service grid proxy to a specific workload in the verified version of application service B. Similar processing is then performed as for application service A, ultimately transmitting the accompanying data packet to the specific workload in application service C. The second request messages corresponding to users A and B do not need to be routed to the verified version of application service B. In the embodiments of the present disclosure, executing the above process can achieve the following technical effects:

[0002] 1) Logical Isolation: Environments are separated not physically (different hardware or clusters) but logically. Logical isolation means that the same physical environment (such as the same Kubernetes cluster) can run different versions of a service, differentiated by configuration or metadata labels. Each logical environment has a corresponding set of service replicas, configured with environment-specific parameters, such as database connections, feature flags, or API endpoints.

[0003] 2) Dynamicity: The dynamic multiple environments in the disclosed embodiments are not statically created but can be created and destroyed as needed. This dynamism allows teams to spin up new environments on demand for specific tests or drills, and then destroy them upon completion. This provides configuration flexibility and effectively conserves resources.

[0004] 3) Multi-environment support: This disclosed embodiment allows for the simultaneous existence of multiple logically isolated environments, each with independent control over traffic and configuration. For example, one environment could be dedicated to QA testing, another for performance testing, and yet another for real-time monitoring of phased releases.

[0005] 4) Dynamic Traffic Diversion: Through a series of routing rules and policies, traffic can be selectively directed to a specific environment. This is typically achieved based on request characteristics, such as header tags, user identity, or request origin. As requests flow through various services, it is crucial to ensure that the request context is maintained and propagated throughout the chain, ensuring that requests are always handled in the correct environment. These logically isolated dynamic multiple environments provide a secure and flexible way to test new features, fix bugs, or conduct A / B testing. This allows teams to test and validate without disrupting the production environment, ensuring stability and a consistent user experience. Applications using this system can be securely deployed in both pre-release and production environments. Dynamic routing overlays provide precise control over request routing, ensuring efficient and accurate inter-service calls. It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, storage, and display) involved in this disclosure are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of the relevant data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation portals are provided for users to choose to authorize or reject. It should be noted that for the sake of simplicity, the aforementioned method embodiments are described as a series of actions. However, those skilled in the art should understand that this disclosure is not limited by the order of the actions described, as certain steps can be performed in a different order or simultaneously according to this disclosure. Secondly, those skilled in the art should also understand that the embodiments described in this specification are all preferred embodiments, and the actions and modules involved are not necessarily required by this disclosure. Through the above description of the embodiments, those skilled in the art will clearly understand that the methods according to the above embodiments can be implemented using software and a necessary general-purpose hardware platform, or of course, hardware. Based on this understanding, the technical solution of the present disclosure, or the portion 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, a magnetic disk, or an optical disk) and includes a number of instructions for enabling a terminal device (which can be a mobile phone, a computer, a server, or a network device, etc.) to execute the methods described in various embodiments of the present disclosure.Example 2 According to an embodiment of the present disclosure, a traffic diversion method is also provided. Figure 9 is a flowchart of a traffic diversion method according to Example 2 of the present disclosure. As shown in Figure 9, the method includes the following steps: Step S91, obtaining a target test request, wherein the target test request is used to represent part of the test requests to be diverted in the service grid; Step S92, converting the target test request to generate an accompanying data packet, wherein the accompanying data packet contains dynamic routing coverage metadata, and the dynamic routing coverage metadata is used to determine the target application service corresponding to the target test request, and the target application service is used to represent the diversion application service corresponding to at least one instance application service in the service grid; Step S93, in the process of transmitting the accompanying data packet in the service call link, using the service grid agent corresponding to each application service in the service call link to generate a target routing rule based on the accompanying data packet; Step S94, routing the target test request to the target workload of the target application service according to the target routing rule. Based on steps S91 to S94 above, the target test request to be offloaded in the service grid is obtained, and then the target test request is converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to identify the target application service corresponding to the target test request. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet through the service invocation link, the service grid agent corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the target test request is routed to the target workload of the target application service according to the target routing rule. This achieves the goal of efficiently offloading traffic in the service grid, thereby achieving the technical effect of improving routing accuracy and service invocation efficiency in the service grid. This further solves the technical problems of poor routing accuracy in traffic offloading in the service grid and the inability to accurately control request routing using dynamic routing overlay metadata in related technologies. For portions not detailed in the above embodiments of the present disclosure, reference is made to the relevant description of Example 1 and is not repeated here.Embodiment 3 According to an embodiment of the present disclosure, a traffic diversion device for implementing the above-mentioned traffic diversion method is further provided. FIG10A is a structural block diagram of a traffic diversion device according to Embodiment 3 of the present disclosure. As shown in FIG10A , the device includes: an acquisition module 1001, configured to acquire a first request message, wherein the first request message is used to represent a portion of request messages to be diverted in a service grid; a first generation module 1002, configured to convert the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, and the dynamic routing overlay metadata is used to determine a target application service corresponding to the first request message, where the target application service is used to represent a diverted application service corresponding to at least one instance application service in the service grid; a second generation module 1003, configured to generate a target routing rule based on the accompanying data packet using a service grid agent corresponding to each application service in the service call link during transmission of the accompanying data packet in a service call link; and a routing module 1004, configured to route the first request message to a target workload of the target application service according to the target routing rule. Optionally, the first generation module 1002 is further configured to: obtain first metadata based on the first request message; determine dynamic routing overlay metadata and second metadata corresponding to the target application service based on the first metadata, wherein the second metadata describes the port information and network address corresponding to the target application service; and generate an accompanying data packet based on the dynamic routing overlay metadata and the second metadata. Optionally, the first metadata includes at least one of the following: request header information, request body information, request query string information, and request path parameter information. Optionally, the first generation module 1002 is further configured to: obtain context information, wherein the context information includes different request metadata and corresponding dynamic routing overlay metadata; and obtain dynamic routing overlay metadata from the context information based on the first metadata. Optionally, the first generation module 1002 is further configured to: query a target application service from a target cluster using the first metadata; and determine second metadata corresponding to the target application service based on the dynamic routing overlay metadata. Optionally, the routing module 1004 is further configured to: route the first request message to a target workload of the target application service via multiple application services in the service call chain according to a target routing rule.Figure 10B is a structural block diagram of another traffic diversion device according to Example 3 of the present disclosure. As shown in Figure 10B, in addition to the modules shown in Figure 10A, the device further includes: a receiving module 1005, which is configured to receive an accompanying data packet from a first application service; and a transmission module 1006, which is configured to transmit the accompanying data packet from the first application service to the second application service in response to the first application service calling the second application service. Optionally, the acquisition module 1001 is further configured to acquire first service registration information, where the first service registration information is used to represent registration information corresponding to an application service included in the service grid. The traffic diversion device further includes: a filtering module 1007 configured to filter the first service registration information based on a preset filtering condition to obtain second service registration information, where the preset filtering condition is used to identify an anti-service discovery tag corresponding to the target application service, and the second service registration information is used to represent registration information corresponding to the instance application service; a push module 1008 configured to push the second service registration information to the service grid proxy, so that the service grid proxy routes a second request message to the instance application service, where the second request message is used to represent remaining request messages in the service grid other than the first request message. Optionally, the traffic diversion device further includes: a deletion module 1009 configured to, in response to performing a replacement operation on the instance application service using the target application service, delete the anti-service discovery tag corresponding to the target application service, so that the target application service enters the service discovery scope of the service grid. Optionally, the second generation module 1003 is further configured to: use the service grid agent corresponding to each application service in the service call link to extract rules from the accompanying data packet to obtain a rule extraction result; and perform fusion processing based on the rule extraction result and the preset routing rule to obtain a target routing rule.In an embodiment of the present disclosure, a first request message to be offloaded in a service grid is obtained and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata, which is used to determine the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along a service invocation link, a service grid proxy corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the first request message is routed to the target workload of the target application service according to the target routing rule. This achieves efficient traffic offload in the service grid, thereby improving routing accuracy and service invocation efficiency in the service grid. This addresses the technical issues of poor routing accuracy in traffic offload in a service grid and the inability to accurately control request routing using dynamic routing overlay metadata in related technologies. It should be noted that the acquisition module 1001, the first generation module 1002, the second generation module 1003, and the routing module 1004 correspond to steps S31 to S34 in Example 1. The examples and application scenarios implemented by these four modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 1. It should be noted that the above modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above modules may also be part of an apparatus and run in the computer terminal 10 provided in Example 1.11 is a structural block diagram of another traffic diversion device according to Embodiment 3 of the present disclosure. As shown in FIG11 , the device includes: an acquisition module 1101, configured to acquire a target test request, wherein the target test request is used to represent a portion of test requests to be diverted in the service grid; a first generation module 1102, configured to convert the target test request to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing coverage metadata, and the dynamic routing coverage metadata is used to determine a target application service corresponding to the target test request, and the target application service is used to represent a diverted application service corresponding to at least one instance application service in the service grid; a second generation module 1103, configured to generate a target routing rule based on the accompanying data packet by using the service grid agent corresponding to each application service in the service call link during transmission of the accompanying data packet in the service call link; and a routing module 1104, configured to route the target test request to the target workload of the target application service according to the target routing rule. In an embodiment of the present application, a target test request to be diverted in a service grid is obtained, and then the target test request is converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to determine the target application service corresponding to the target test request. The target application service is used to represent the diverted application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along the service call link, the service grid agent corresponding to each application service in the service call link generates a target routing rule based on the accompanying data packet. Finally, the target test request is routed to the target workload of the target application service according to the target routing rule. This achieves the purpose of efficiently implementing traffic diversion in the service grid, thereby achieving the technical effect of improving routing accuracy and service call efficiency in the service grid. This further solves the technical problems of poor routing accuracy when performing traffic diversion in the service grid and the inability to accurately control request routing through dynamic routing overlay metadata in related technologies. It should be noted that the acquisition module 1101, the first generation module 1102, the second generation module 1103, and the routing module 1104 correspond to steps S91 to S94 in Example 2. The examples and application scenarios implemented by the four modules and the corresponding steps are the same, but are not limited to the contents disclosed in Example 2.It should be noted that the above-mentioned modules or units may be hardware components or software components stored in a memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, 102n). The above-mentioned modules may also be part of a device and run in the computer terminal 10 provided in Example 1. It should be noted that the preferred implementation schemes involved in the above-mentioned embodiments of the present disclosure are the same as the solution provided in Example 1, as well as the application scenarios and implementation processes, but are not limited to the solution provided in Example 1. Example 4 The embodiments of the present disclosure may provide a computer terminal, which may be any computer terminal device in a computer terminal group. Optionally, in this embodiment, the above-mentioned computer terminal may be replaced by a terminal device such as a mobile terminal. Optionally, in this embodiment, the above-mentioned computer terminal may be located in at least one of multiple network devices in a computer network. In this embodiment, the computer terminal can execute program code for the following steps in the traffic offloading method: obtaining a first request message, wherein the first request message is used to represent a portion of request messages to be offloaded in the service grid; converting the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, and the dynamic routing overlay metadata is used to determine the target application service corresponding to the first request message, wherein the target application service is used to represent the offloaded application service corresponding to at least one instance application service in the service grid; during transmission of the accompanying data packet in the service invocation link, generating a target routing rule based on the accompanying data packet using the service grid agent corresponding to each application service in the service invocation link; and routing the first request message to the target workload of the target application service according to the target routing rule. Alternatively, Figure 12 is a block diagram of a computer terminal according to Embodiment 4 of the present disclosure. As shown in Figure 12, the computer terminal may include: one or more (only one is shown) processors 122, a memory 124, a storage controller, and a peripheral interface, wherein the peripheral interface is connected to a radio frequency module, an audio module, and a display. The memory may be used to store software programs and modules, such as the program instructions / modules corresponding to the traffic diversion method and apparatus in the embodiments of the present disclosure. The processor executes the software programs and modules stored in the memory to perform various functional applications and data processing, thereby implementing the aforementioned traffic diversion method. The memory may include high-speed random access memory (RAM) or non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory.In some instances, the memory may further include a memory remotely located from the processor, and these remote memories may be connected to the computer terminal via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof. The processor may access information and applications stored in the memory via a transmission device to perform the following steps: obtaining a first request message, wherein the first request message represents a portion of request messages to be offloaded in the service grid; converting the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, and the dynamic routing overlay metadata is used to determine a target application service corresponding to the first request message, wherein the target application service represents an offloaded application service corresponding to at least one instance application service in the service grid; generating a target routing rule based on the accompanying data packet during transmission of the accompanying data packet in a service invocation link by a service grid agent corresponding to each application service in the service invocation link; and routing the first request message to a target workload of the target application service according to the target routing rule. Optionally, the processor may further execute program code for the following steps: obtaining first metadata based on the first request message; determining dynamic routing overlay metadata and second metadata corresponding to the target application service based on the first metadata, wherein the second metadata describes the port information and network address corresponding to the target application service; and generating an accompanying data packet based on the dynamic routing overlay metadata and the second metadata. Optionally, the first metadata includes at least one of the following: request header information, request body information, request query string information, and request path parameter information. Optionally, the processor may further execute program code for the following steps: obtaining context information, wherein the context information includes different request metadata and corresponding dynamic routing overlay metadata; and obtaining dynamic routing overlay metadata from the context information based on the first metadata. Optionally, the processor may further execute program code for the following steps: obtaining a target application service from a target cluster using the first metadata; and determining second metadata corresponding to the target application service based on the dynamic routing overlay metadata. Optionally, the processor may further execute program code for the following steps: routing the first request message to a target workload of the target application service via multiple application services in a service call chain according to a target routing rule. Optionally, the processor may further execute program code of the following steps: receiving an accompanying data packet from the first application service; and transmitting the accompanying data packet from the first application service to the second application service in response to the first application service calling the second application service.Optionally, the processor may further execute program code for the following steps: obtaining first service registration information, wherein the first service registration information is used to represent registration information corresponding to an application service included in the service grid; filtering the first service registration information based on a preset filtering condition to obtain second service registration information, wherein the preset filtering condition is used to identify an anti-service discovery tag corresponding to a target application service, and the second service registration information is used to represent registration information corresponding to an instance application service; and pushing the second service registration information to a service grid proxy, so that the service grid proxy routes a second request message to the instance application service, wherein the second request message is used to represent remaining request messages in the service grid other than the first request message. Optionally, the processor may further execute program code for the following steps: in response to performing a replacement operation on the instance application service using the target application service, deleting the anti-service discovery tag corresponding to the target application service, so that the target application service enters the service discovery scope of the service grid. Optionally, the processor may further execute program code for the following steps: extracting rules from an accompanying data packet using a service grid proxy corresponding to each application service in the service call link to obtain a rule extraction result; fusing the rule extraction result with a preset routing rule to obtain a target routing rule. Optionally, the processor may further execute program code for the following steps: obtaining a target test request, wherein the target test request represents a portion of test requests to be diverted in the service grid; converting the target test request to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, the dynamic routing overlay metadata being used to determine a target application service corresponding to the target test request, the target application service representing a diverted application service corresponding to at least one instance application service in the service grid; generating a target routing rule based on the accompanying data packet during transmission of the accompanying data packet by the service grid proxy corresponding to each application service in the service call link; and routing the target test request to a target workload of the target application service according to the target routing rule.According to the embodiments of the present disclosure, a first request message to be offloaded in a service grid is obtained and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata, which is used to determine the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along the service invocation link, the service grid agent corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the first request message is routed to the target workload of the target application service according to the target routing rule. This achieves the goal of efficiently offloading traffic in the service grid, thereby improving routing accuracy and service invocation efficiency in the service grid. This solves the technical problem of poor routing accuracy and the inability to accurately control request routing using dynamic routing overlay metadata when performing traffic offload in a service grid in related technologies. Those skilled in the art will appreciate that the structure shown in the figure is merely illustrative, and that the computer terminal may also be a smartphone (such as an Android phone, an iOS phone, etc.), a tablet computer, a PDA, or a mobile internet device (MID). Figure 12 does not limit the structure of the electronic device described above. For example, the computer terminal may include more or fewer components (such as a network interface, a display device, etc.) than those shown in Figure 12, or may have a configuration different from that shown in Figure 12. Those skilled in the art will appreciate that all or part of the steps in the various methods of the above embodiments can be completed by a program instructing the hardware associated with the terminal device. The program can be stored in a computer-readable storage medium, which may include a flash drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk. It should be noted that the preferred implementation schemes involved in the above embodiments of the present disclosure are the same as the scheme provided in Example 1, as well as the application scenarios and implementation processes, but are not limited to the scheme provided in Example 1. Example 5 The embodiments of the present disclosure also provide a computer-readable storage medium. Optionally, in this embodiment, the above storage medium can be used to store the program code executed by the traffic diversion method provided in Example 1. Optionally, in this embodiment, the storage medium may be located in any computer terminal in a computer terminal group in a computer network, or in any mobile terminal in a mobile terminal group.Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining a first request message, wherein the first request message is used to represent a portion of request messages to be offloaded in the service grid; converting the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, the dynamic routing overlay metadata is used to determine a target application service corresponding to the first request message, and the target application service is used to represent an offloaded application service corresponding to at least one instance application service in the service grid; during transmission of the accompanying data packet along a service invocation link, generating a target routing rule based on the accompanying data packet using a service grid agent corresponding to each application service in the service invocation link; and routing the first request message to a target workload of the target application service according to the target routing rule. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining first metadata based on the first request message; determining dynamic routing overlay metadata and second metadata corresponding to the target application service based on the first metadata, wherein the second metadata describes port information and a network address corresponding to the target application service; and generating the accompanying data packet based on the dynamic routing overlay metadata and the second metadata. Optionally, the first metadata includes at least one of the following: request header information, request body information, request query string information, and request path parameter information. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining context information, wherein the context information includes different request metadata and corresponding dynamic routing override metadata; and querying the dynamic routing override metadata from the context information based on the first metadata. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: querying a target application service from a target cluster using the first metadata; and determining second metadata corresponding to the target application service based on the dynamic routing override metadata. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: routing the first request message to a target workload of the target application service via multiple application services in a service call chain according to a target routing rule. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: receiving an accompanying data packet from a first application service; and transmitting the accompanying data packet from the first application service to the second application service in response to the first application service invoking the second application service.Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining first service registration information, wherein the first service registration information represents registration information corresponding to an application service included in the service grid; filtering the first service registration information based on a preset filtering condition to obtain second service registration information, wherein the preset filtering condition is used to identify an anti-service discovery tag corresponding to a target application service, and the second service registration information represents registration information corresponding to an instance application service; and pushing the second service registration information to a service grid proxy, so that the service grid proxy routes a second request message to the instance application service, wherein the second request message represents remaining request messages in the service grid other than the first request message. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: in response to performing a replacement operation on the instance application service using the target application service, deleting the anti-service discovery tag corresponding to the target application service, so that the target application service enters the service discovery scope of the service grid. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: extracting rules from an accompanying data packet using a service mesh proxy corresponding to each application service in a service invocation link to obtain a rule extraction result; fusing the rule extraction result with a preset routing rule to obtain a target routing rule. Optionally, in this embodiment, the storage medium is configured to store program code for performing the following steps: obtaining a target test request, wherein the target test request represents a portion of test requests to be offloaded in the service mesh; converting the target test request to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, the dynamic routing overlay metadata being used to determine a target application service corresponding to the target test request, the target application service representing an offloaded application service corresponding to at least one instance application service in the service mesh; generating a target routing rule based on the accompanying data packet during transmission of the accompanying data packet using the service mesh proxy corresponding to each application service in the service invocation link; and routing the target test request to a target workload of the target application service according to the target routing rule.In an embodiment of the present disclosure, a first request message to be offloaded in a service grid is obtained, and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to determine the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet in the service invocation link, the service grid agent corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the first request message is routed to the target workload of the target application service according to the target routing rule. This achieves the goal of efficiently offloading traffic in the service grid, thereby improving routing accuracy and service invocation efficiency in the service grid. This solves the technical problems of poor routing accuracy and the inability to accurately control request routing using dynamic routing overlay metadata when performing traffic offload in a service grid in related technologies. It should be noted that the preferred implementation schemes involved in the above embodiments of the present disclosure are the same as the scheme, application scenarios, and implementation process provided in Example 1, but are not limited to the scheme provided in Example 1. Example 6 The embodiments of the present disclosure also provide a computer program product. Optionally, in this embodiment, the computer program product may include a computer program that, when executed by a processor, implements the method provided in the above embodiment. Optionally, the computer program included in the computer program product causes the processor to execute the following steps: obtain a first request message, wherein the first request message is used to represent a portion of request messages to be offloaded in the service grid; convert the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, and the dynamic routing overlay metadata is used to determine a target application service corresponding to the first request message, wherein the target application service is used to represent an offloaded application service corresponding to at least one instance application service in the service grid; during transmission of the accompanying data packet in a service invocation link, generate a target routing rule based on the accompanying data packet using a service grid agent corresponding to each application service in the service invocation link; and route the first request message to a target workload of the target application service according to the target routing rule. Optionally, the computer program included in the above-mentioned computer program product is used by a processor to execute the following steps: obtain first metadata based on the first request message; determine dynamic routing overlay metadata and second metadata corresponding to the target application service based on the first metadata, wherein the second metadata is used to describe port information and network address corresponding to the target application service; and generate an accompanying data packet based on the dynamic routing overlay metadata and the second metadata.Optionally, the first metadata includes at least one of the following: request header information, request body information, request query string information, and request path parameter information. Optionally, the computer program included in the computer program product is executed by a processor to: obtain context information, wherein the context information includes different request metadata and corresponding dynamic routing override metadata; and query the context information to obtain the dynamic routing override metadata based on the first metadata. Optionally, the computer program included in the computer program product is executed by a processor to: query a target application service from a target cluster using the first metadata; and determine second metadata corresponding to the target application service based on the dynamic routing override metadata. Optionally, the computer program included in the computer program product is executed by a processor to: route the first request message to a target workload of the target application service via multiple application services in a service call link according to a target routing rule. Optionally, the computer program included in the computer program product is executed by a processor to: receive an accompanying data packet from a first application service; and transmit the accompanying data packet from the first application service to the second application service in response to the first application service calling the second application service. Optionally, the computer program included in the computer program product is configured to cause a processor to execute the following steps: obtain first service registration information, wherein the first service registration information is used to represent registration information corresponding to an application service included in a service grid; filter the first service registration information based on a preset filtering condition to obtain second service registration information, wherein the preset filtering condition is used to identify an anti-service discovery tag corresponding to a target application service, and the second service registration information is used to represent registration information corresponding to an instance application service; and push the second service registration information to a service grid proxy, so that the service grid proxy routes a second request message to the instance application service, wherein the second request message is used to represent remaining request messages in the service grid other than the first request message. Optionally, the computer program included in the computer program product is configured to cause a processor to execute the following steps: in response to performing a replacement operation on the instance application service using the target application service, delete the anti-service discovery tag corresponding to the target application service, so that the target application service enters the service discovery scope of the service grid. Optionally, the computer program included in the computer program product is used by the processor to execute the following steps: using the service grid agent corresponding to each application service in the service call link to extract rules from the accompanying data packet to obtain a rule extraction result; and fusing the rule extraction result with a preset routing rule to obtain a target routing rule.Optionally, the computer program included in the above-mentioned computer program product is used by a processor to execute the following steps: obtaining a target test request, wherein the target test request is used to represent part of the test requests to be diverted in the service grid; converting the target test request to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing coverage metadata, and the dynamic routing coverage metadata is used to determine the target application service corresponding to the target test request, and the target application service is used to represent the diverted application service corresponding to at least one instance application service in the service grid; in the process of transmitting the accompanying data packet in the service call link, using the service grid agent corresponding to each application service in the service call link to generate a target routing rule based on the accompanying data packet; routing the target test request to the target workload of the target application service according to the target routing rule. In an embodiment of the present disclosure, a first request message to be offloaded in a service grid is obtained, and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to determine the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along the service invocation link, the service grid proxy corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the first request message is routed to the target workload of the target application service according to the target routing rule. This achieves the goal of efficiently offloading traffic in the service grid, thereby achieving the technical effect of improving routing accuracy and service invocation efficiency in the service grid. This further solves the technical problems of poor routing accuracy and the inability to accurately control request routing using dynamic routing overlay metadata when performing traffic offload in a service grid in related technologies. It should be noted that the preferred implementation schemes involved in the above embodiments of the present disclosure are the same as the scheme provided in Example 1, as well as the application scenarios and implementation processes, but are not limited to the scheme provided in Example 1.Embodiment 7. Embodiments of the present disclosure also provide a traffic offload system, comprising: a gateway and multiple application services configured on a service invocation link; the gateway, configured to convert and process received request messages to generate accompanying data packets, wherein the request messages represent portions of request messages to be offloaded in the service grid; the accompanying data packets contain dynamic routing overlay metadata, the dynamic routing overlay metadata being used to determine a target application service corresponding to the request message; the target application service representing the offloaded application service corresponding to at least one instance application service in the service grid; and the multiple application services, configured to generate target routing rules based on the accompanying data packets during transmission of the accompanying data packets on the service invocation link, and to route the request messages to target workloads of the target application services according to the target routing rules. Optionally, the multiple application services are configured to perform rule extraction on the accompanying data packets to obtain rule extraction results, and to fuse the rule extraction results with preset routing rules to obtain target routing rules. In an embodiment of the present disclosure, a first request message to be offloaded in a service grid is obtained, and then converted to generate an accompanying data packet. The accompanying data packet contains dynamic routing overlay metadata. The dynamic routing overlay metadata is used to determine the target application service corresponding to the first request message. The target application service represents the offload application service corresponding to at least one instance application service in the service grid. During the transmission of the accompanying data packet along the service invocation link, the service grid proxy corresponding to each application service in the service invocation link generates a target routing rule based on the accompanying data packet. Finally, the first request message is routed to the target workload of the target application service according to the target routing rule. This achieves the goal of efficiently offloading traffic in the service grid, thereby improving routing accuracy and service invocation efficiency in the service grid. This further addresses the technical issues of poor routing accuracy and the inability to accurately control request routing using dynamic routing overlay metadata when performing traffic offload in a service grid in related technologies. It should be noted that the preferred implementation schemes involved in the above embodiments of the present disclosure are the same as those provided in Example 1, as well as their application scenarios and implementation processes, but are not limited to the scheme provided in Example 1. The serial numbers of the above embodiments of the present disclosure are for descriptive purposes only and do not represent the advantages or disadvantages of the embodiments. In the above-described embodiments of the present disclosure, the descriptions of each embodiment are given with emphasis. For portions not described in detail in a particular embodiment, reference can be made to the relevant descriptions of other embodiments. It should be understood that the disclosed technical content of the several embodiments provided in the present disclosure can be implemented in other ways.The device embodiments described above are merely illustrative. For example, the division of units is merely a logical functional division. In actual implementation, other divisions may be employed. For example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not implemented. Furthermore, the couplings or direct couplings or communication connections shown or discussed may be through interfaces, or indirect couplings or communication connections between units or modules, and may be electrical or other. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, i.e., they may be located in one location or distributed across multiple network units. Some or all of these units may be selected to achieve the objectives of the present embodiments based on actual needs. Furthermore, the functional units in the various embodiments of the present disclosure may be integrated into a single processing unit, each unit may exist physically separately, or two or more units may be integrated into a single unit. These integrated units may be implemented in either hardware or software functional units. If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present disclosure, or the portion that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product, stored in a storage medium, includes instructions for causing a computer device (such as a personal computer, server, or network device) to perform all or part of the steps of the methods described in the various embodiments of the present disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memories (ROMs), random access memories (RAMs), removable hard drives, magnetic disks, or optical disks. The above description is merely a preferred embodiment of the present disclosure. It should be noted that those skilled in the art can make various improvements and modifications without departing from the principles of the present disclosure, and such improvements and modifications should also be considered within the scope of protection of the present disclosure.

Claims

25 Claims 1. A traffic diversion method, comprising: Obtain a first request message, wherein the first request message is used to represent part of the request messages to be diverted in the service grid; convert the first request message to generate an accompanying data packet, wherein the accompanying data packet includes dynamic routing overlay metadata, the dynamic routing overlay metadata is used to determine a target application service corresponding to the first request message, and the target application service is used to represent the diverted application service corresponding to at least one instance application service in the service grid; in the process of transmitting the accompanying data packet in a service call link, use the service grid agent corresponding to each application service in the service call link to generate a target routing rule based on the accompanying data packet; and route the first request message to a target workload of the target application service according to the target routing rule.

2. The traffic diversion method according to claim 1, wherein: Converting and processing the first request message to generate the accompanying data packet also includes: obtaining first metadata based on the first request message; determining the dynamic routing overlay metadata and the second metadata corresponding to the target application service based on the first metadata, wherein the second metadata is used to describe the port information and network address corresponding to the target application service; generating the accompanying data packet based on the dynamic routing overlay metadata and the second metadata.

3. The flow diversion method according to claim 2, wherein: The first metadata includes at least one of the following: request header information, request body information, request query string information, and request path parameter information.

4. The traffic diversion method according to claim 2, wherein: Determining the dynamic routing overlay metadata according to the first metadata includes: acquiring context information, wherein the context information includes different request metadata and corresponding dynamic routing overlay metadata; and querying the dynamic routing overlay metadata from the context information based on the first metadata.

5. The traffic diversion method according to claim 2, wherein: Determining the second metadata according to the first metadata includes: querying and obtaining the target application service from a target cluster using the first metadata; and determining the second metadata corresponding to the target application service based on the dynamic routing overlay metadata.

6. The traffic diversion method according to claim 1, wherein: Routing the first request message to the target application load of the target application service according to the target routing rule includes: routing the first request message to the target application load of the target application service via multiple application services in the service call link according to the target routing rule.

7. The traffic diversion method according to claim 1, wherein: The method further includes: receiving the accompanying data packet from a first application service; In response to the first application service calling the second application service, the accompanying data packet is transmitted from the first application service to the second application service.

8. The traffic diversion method according to claim 1, wherein: The method also includes: obtaining first service registration information, wherein the first service registration information is used to represent registration information corresponding to the application service contained in the service grid; filtering the first service registration information based on preset filtering conditions to obtain second service registration information, wherein the preset filtering conditions are used to identify the anti-service discovery tag corresponding to the target application service, and the second service registration information is used to represent registration information corresponding to the instance application service; pushing the second service registration information to the service grid agent so that the service grid agent routes a second request message to the instance application service, wherein the second request message is used to represent the remaining request messages in the service grid except the first request message.

9. The traffic diversion method according to claim 8, wherein: The method further includes: in response to performing a replacement operation on the instance application service using the target application service, deleting the anti-service discovery tag corresponding to the target application service, so that the target application service enters the service discovery scope of the service grid.

10. The traffic diversion method according to claim 1, wherein: Generating the target routing rule based on the accompanying data packet using the service grid agent corresponding to each application service in the service call link includes: extracting rules from the accompanying data packet using the service grid agent corresponding to each application service in the service call link to obtain a rule extraction result; and fusing the rule extraction result with the preset routing rule to obtain the target routing rule.

11. A traffic diversion method, comprising: Obtain a target test request, wherein the target test request is used to represent part of the test requests to be diverted in the service grid; convert the target test request to generate an accompanying data packet, wherein the accompanying data packet contains dynamic routing coverage metadata, and the dynamic routing coverage metadata is used to determine the target application service corresponding to the target test request, and the target application service is used to represent the diverted application service corresponding to at least one instance application service in the service grid; in the process of transmitting the accompanying data packet through the service call link, use the service grid agent corresponding to each application service in the service call link to extract rules from the accompanying data packet to obtain a rule extraction result; perform fusion processing based on the rule extraction result and the preset routing rule to obtain a target routing rule; and route the target test request to the target workload of the target application service according to the target routing rule.

12. A traffic diversion system, comprising: Multiple application services set up on the gateway and service call link; The gateway is configured to convert the obtained request message to generate an accompanying data packet, wherein the request message is used to represent a portion of the request message to be offloaded in the service grid, and the accompanying data packet contains dynamic routing overlay metadata, and the dynamic routing overlay metadata is used to determine the target application service corresponding to the request message. The target application service is used to represent the offload application service corresponding to at least one instance application service in the service grid; the multiple application services are used to generate a target routing rule based on the accompanying data packet during the process of transmitting the accompanying data packet through the service call link, and route the request message to the target workload of the target application service according to the target routing rule.

13. The flow diversion system according to claim 12, wherein: The multiple application services are used to perform rule extraction on the accompanying data packet to obtain a rule extraction result, and perform fusion processing based on the rule extraction result and a preset routing rule to obtain a target routing rule.

14. A computer-readable storage medium comprising a stored executable program, wherein: When the executable program is running, the device where the computer-readable storage medium is located is controlled to execute the traffic diversion method described in any one of claims 1 to 11.

15. An electronic device, comprising: a memory storing an executable program; A processor is configured to run the program, wherein the program executes the traffic diversion method according to any one of claims 1 to 11 when running.

16. A computer program product, comprising a computer program, wherein when executed by a processor, the computer program implements the traffic diversion method according to any one of claims 1 to 11.

Images