Traffic request transfer method, device, electronic device, and computer program product

Abstract

The present application discloses a method, device, electronic device, and computer program product for transferring traffic requests, the method comprising: receiving a first traffic request and parsing it to obtain a distributed link tracking identifier; determining whether the label information of the traffic lane is parsed, and the traffic lane corresponds to the business change scenario one by one; if the label is parsed, the label information is associated with the distributed link tracking identifier and stored, and the first traffic request is forwarded to the service on the traffic lane corresponding to the label information; receiving a second traffic request for the service and parsing it to obtain a distributed link tracking identifier; forwarding the second traffic request based on the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules. The present application uses the traffic lane design to complete the isolation of traffic in different scenarios with minimal service resources, saving server resources. Operations such as label storage and forwarding do not rely on business services and are non-invasive to the business.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of traffic forwarding, in particular to a traffic request flow conversion method and device, electronic equipment and computer program product. BACKGROUND

[0002] In the process of project construction, the same service often needs to support multiple different business scenarios at the same time. How to efficiently, cost-effectively and non-invasively solve the problem of traffic isolation of different scenarios is a very challenging task.

[0003] A general business traffic request link may include a seven-layer load balancer, a gateway, a registration center, a business system, a database, etc. The business system may involve multiple related systems. If the business needs to support multiple business scenarios at the same time, some of the business systems involved in the transformation are developed for different scenarios and deploy corresponding services. In order to ensure the isolation of the request traffic of each scenario, other systems on the corresponding request link also need to deploy multiple sets of corresponding environments, so as to form a complete, isolated and multi-environment supporting architecture. Figure 1 As shown in the figure, a traffic request link diagram in a multi-business environment in the prior art is provided. This scheme has high deployment complexity, high cost and low efficiency, and has a large optimization space.

[0004] An improved scheme is proposed in the prior art, as shown in Figure 2 As shown in the figure, another traffic request link diagram in a multi-business environment in the prior art is provided. In this scheme, the request information first enters the gray entrance, and then determines whether the request information can enter the gray lane based on the gray traffic control rule. The gray lane circumscribes the gray version instance, that is, the combination of the gray traffic control rule and the gray lane can realize the traffic control between the original version instance and the gray version instance, and improve the controllability of the gray release. However, this scheme takes microservice-A as the gray entrance and integrates it into the service code in the form of SDK, which at least has the following technical problems:

[0005] 1) High invasiveness: the gray entrance in the existing scheme is coupled with the business service itself, which has high invasiveness;

[0006] 2) Narrow applicability: the existing scheme only supports HTTP request protocol, while in actual business scenarios, internal business systems more often give RPC request protocol, so the applicability of this scheme is relatively narrow;

[0007] 3) high maintenance cost: the existing solutions are integrated into various project systems in the form of SDK, and adaptation work needs to be done for different languages and project frameworks to complete traffic marking, tag forwarding between threads in the service, tag forwarding between services, etc. Business needs to be reformed and maintained, and the access and maintenance cost is high;

[0008] 4) low support traffic: the rule analysis of gray degree is located in the business service, and the size of the supported request traffic is affected by the performance bottleneck of the business. SUMMARY

[0009] Embodiments of the present application provide a traffic request flow conversion method and device, electronic equipment and computer program product to save server resources required for traffic isolation in different scenarios and reduce the invasion of business.

[0010] Embodiments of the present application adopt the following technical solutions:

[0011] In a first aspect, embodiments of the present application provide a traffic request flow conversion method, which comprises:

[0012] receiving and analyzing a first traffic request to obtain an analysis result of the first traffic request, wherein the analysis result of the first traffic request comprises a distributed link tracking identifier;

[0013] determining whether the analysis result of the first traffic request further comprises label information of a traffic lane, wherein the traffic lane corresponds to a business change scenario one by one;

[0014] in the case of containing label information, associating and storing the label information with the distributed link tracking identifier, and forwarding the first traffic request to a first target service on the traffic lane corresponding to the label information;

[0015] receiving and analyzing a second traffic request of the first target service to obtain an analysis result of the second traffic request, wherein the analysis result of the second traffic request comprises a distributed link tracking identifier;

[0016] According to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rule based on the service mesh, the second traffic request is forwarded to a second target service.

[0017] Optionally, before receiving and analyzing the first traffic request to obtain the analysis result of the first traffic request, the traffic request flow conversion method further comprises:

[0018] intercepting and analyzing the original first traffic request through a load balancer to obtain an analysis result of the original first traffic request;

[0019] Matching the parsing result of the original first traffic request with the label configuration information to determine whether there is matching label information;

[0020] In the case that matching label information exists, the matching label information and the corresponding lane field information are written into the message header of the original first traffic request to obtain an updated first traffic request.

[0021] Optionally, after determining whether the parsing result of the first traffic request further includes label information of the traffic lane, the traffic request transfer method further includes:

[0022] When the parsing result of the first traffic request does not include label information, the first traffic request is forwarded to the service of the main channel for processing.

[0023] Optionally, when the tag information is included, associating and storing the tag information with the distributed link tracking identifier includes:

[0024] In the case where tag information is included, determining whether there is a high-efficiency compression bitmap corresponding to the tag information;

[0025] If so, the tag information is associated with the distributed link tracking identifier and stored in a high-efficiency compression bitmap corresponding to the tag information;

[0026] If it does not exist, a corresponding efficient compression bitmap is created for the tag information, and the tag information is associated with the distributed link tracking identifier and stored in the efficient compression bitmap corresponding to the tag information.

[0027] Optionally, forwarding the second traffic request to a second target service according to the distributed link tracking identifier, the association between the label information and the distributed link tracking identifier, and a traffic forwarding rule implemented based on a service grid includes:

[0028] According to the distributed link tracking identifier, traverse the efficient compressed bitmap database corresponding to the tag information to obtain the tag information corresponding to the distributed link tracking identifier;

[0029] Writing the label information corresponding to the distributed link tracking identifier into the request header of the second traffic request;

[0030] Based on the traffic forwarding rules implemented by the service grid, the second traffic request is forwarded to the second target service.

[0031] Optionally, forwarding the second traffic request to a second target service based on a traffic forwarding rule implemented by the service grid includes:

[0032] Determining whether a second target service exists in the traffic lane corresponding to the label information carried in the second traffic request;

[0033] If so, the second traffic request is forwarded to the second target service on the traffic lane corresponding to the label information;

[0034] Otherwise, the second traffic request is forwarded to the second target service on the main road.

[0035] Optionally, the traffic request transfer method further includes:

[0036] Clean the data in the efficient compression bitmap corresponding to the tag information using the preset data cleaning data;

[0037] Among them, the preset data cleaning data includes at least one of a traffic lane expiration cleaning strategy and a traffic request expiration cleaning strategy.

[0038] In a second aspect, an embodiment of the present application further provides a traffic request transfer device, the traffic request transfer device comprising:

[0039] A first receiving unit is configured to receive and parse a first traffic request to obtain a parsing result of the first traffic request, wherein the parsing result of the first traffic request includes a distributed link tracking identifier;

[0040] a determining unit, configured to determine whether the parsing result of the first traffic request further includes label information of a traffic lane, wherein the traffic lane corresponds to the service change scenario in a one-to-one manner;

[0041] a first forwarding unit, configured to associate and store the label information with the distributed link tracking identifier when the label information is included, and forward the first traffic request to a first target service on the traffic lane corresponding to the label information;

[0042] a second receiving unit, configured to receive and parse a second traffic request for the first target service to obtain a parsing result of the second traffic request, wherein the parsing result of the second traffic request includes a distributed link tracking identifier;

[0043] The second forwarding unit is used to forward the second traffic request to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

[0044] In a third aspect, an embodiment of the present application further provides an electronic device, including:

[0045] processor; and

[0046] A memory is arranged to store computer-executable instructions, which, when executed, cause the processor to perform any of the aforementioned traffic request forwarding methods.

[0047] In a fourth aspect, an embodiment of the present application further provides a computer program product, comprising a computer program or instructions, which, when executed by a processor, implements any of the aforementioned traffic request transfer methods.

[0048] At least one of the above technical solutions adopted in the embodiments of the present application can achieve the following beneficial effects: the traffic request forwarding method of the embodiment of the present application first receives and parses a first traffic request to obtain a parsing result of the first traffic request, the parsing result of the first traffic request including a distributed link tracking identifier; then determines whether the parsing result of the first traffic request also includes label information of a traffic lane, the traffic lane corresponding to a business change scenario; then, if the label information is included, the label information is associated with the distributed link tracking identifier and stored, and the first traffic request is forwarded to the first target service on the traffic lane corresponding to the label information; then, a second traffic request of the first target service is received and parses to obtain a parsing result of the second traffic request, the parsing result of the second traffic request including a distributed link tracking identifier; finally, according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid, the second traffic request is forwarded to the second target service. The traffic request forwarding method of the embodiment of the present application can isolate traffic in different scenarios with minimal service resources through the traffic lane design, saving server resources. In addition, operations such as parsing traffic requests and storing and forwarding labels do not rely on business services and are not affected by business performance bottlenecks. Business integration does not require any modification and is non-invasive to the business. BRIEF DESCRIPTION OF THE DRAWINGS

[0049] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0050] Figure 1 A schematic diagram of a traffic request link in a multi-service environment in the prior art;

[0051] Figure 2 A schematic diagram of a traffic request link in another multi-service environment in the prior art;

[0052] Figure 3 A flow chart of a traffic request transfer method in an embodiment of the present application

[0053] Figure 4 Fig. 1 is a schematic diagram of a traffic request link based on a traffic lane according to an embodiment of the present application;

[0054] Figure 5 Fig. 2 is a schematic diagram of a traffic request flow transfer between services according to an embodiment of the present application;

[0055] Figure 6 Fig. 3 is a schematic diagram of a traffic request marking process according to an embodiment of the present application;

[0056] Figure 7 Fig. 4 is a schematic diagram of a traffic request forwarding process according to an embodiment of the present application;

[0057] Figure 8 Fig. 5 is a schematic diagram of a traffic request forwarding device based on Envoy according to an embodiment of the present application;

[0058] Figure 9 Fig. 6 is a schematic diagram of a traffic request flow transfer device according to an embodiment of the present application;

[0059] Figure 10 Fig. 7 is a schematic diagram of an electronic device according to an embodiment of the present application. DETAILED DESCRIPTION

[0060] In order to make the objectives, technical solutions and advantages of the present application clearer, the technical solutions of the present application will be described below in detail with reference to the embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only some of the embodiments of the present application, but not all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of protection of the present application.

[0061] The technical solutions provided by the embodiments of the present application will be described in detail below with reference to the drawings.

[0062] The embodiments of the present application provide a traffic request flow transfer method, as shown in Figure 3 Fig. 1 is a schematic diagram of a traffic request link based on a traffic lane according to an embodiment of the present application;

[0063] Step S310, receiving and analyzing a first traffic request to obtain an analysis result of the first traffic request, wherein the analysis result of the first traffic request includes a distributed link tracking identifier.

[0064] The flow request flow conversion method of the embodiment of the application can be implemented by an independently deployed flow request forwarding device. When the flow request is converted, a first flow request sent by an application layer needs to be received first, and then the first flow request is parsed according to an access protocol type corresponding to the request. The parsing result generally contains a distributed link tracking identifier. Generally, a service will integrate a distributed link tracking function, and a link tracking number will be carried in a request message header. The type of the link tracking number can be customized, for example, a long integer type tracking number can be used to identify the calling process and the space-time relationship of the request between multiple service components.

[0065] In step S320, it is determined whether the label information of the flow lane is further contained in the parsing result of the first flow request, and the flow lane corresponds to the business change scenario one by one.

[0066] The embodiment of the application can design a flow lane based on a service mesh. The service mesh is an infrastructure layer for managing service communication. A set of lightweight network agents are deployed in the network. These agents are deployed together with the application program, but do not invade the application program itself, thereby realizing transparent management and regulation of inter-service communication.

[0067] The environment corresponding to the flow lane is divided into a main lane environment and other flow lane environments. The main lane environment is a stable public environment, which contains all services on the request link. The other flow lane environments are mutually isolated environments, which contain business changes of respective scenarios. The flow can be requested from the main lane request flow lane environment, or from the flow lane environment to the main lane. However, the flow between each flow lane cannot be requested from each other. The embodiment of the application only needs to deploy services related to scenario changes in the flow lane. Other services share the main lane service. Each flow lane corresponds to a unique label information, which is used to identify the flow lane. For example, the label T1 represents the flow lane 1, and the label T2 represents the flow lane 2.

[0068] For the convenience of understanding the above-mentioned embodiments, as shown in Figure 4 A flow request link diagram implemented based on a flow lane in the embodiment of the application is provided.

[0069] Based on the design of the above-mentioned flow lane, after the parsing of the first flow request is completed, it is further determined whether the label information of the flow lane is contained in the parsing result, so as to determine which target service the current first flow request should be forwarded to for processing.

[0070] In step S330, in the case where the label information is contained, the label information is stored in association with the distributed link tracking identifier, and the first flow request is forwarded to a first target service on a flow lane corresponding to the label information.

[0071] If the request header is parsed to contain the label information of the traffic lane, it means that the request needs to be forwarded to the service of the corresponding lane for processing. The first traffic request can be forwarded to the first target service on the traffic lane corresponding to the label information for processing.

[0072] In addition, to ensure that traffic can access the correct lane throughout the entire request link, labels need to be forwarded from upstream services to downstream services. However, without intruding into the service, for example, the incoming request of service A and the incoming request of service B (that is, the outgoing request of service A) cannot be directly associated.

[0073] like Figure 5 As shown, a schematic diagram of the flow of traffic requests between services in an embodiment of the present application is provided. Before forwarding a request, the embodiment of the present application needs to associate and store the label information with the distributed link tracking identifier. Since the distributed link tracking identifier is information that is always carried in the request, during the subsequent request flow, the label information can be transmitted throughout the entire link based on the association information between the stored label information and the distributed link tracking identifier, thereby ensuring the correctness of the request forwarding.

[0074] Step S340: Receive and parse the second traffic request for the first target service to obtain a parsing result of the second traffic request, where the parsing result of the second traffic request includes a distributed link tracking identifier.

[0075] After forwarding the first traffic request to the first target service, the first target service will process the first traffic request based on its own business processing logic, and repackage the traffic request after processing, which is the second traffic request. The second traffic request here can be regarded as an outgoing request of the first target service, and the above-mentioned first traffic request can be regarded as an incoming request of the first target service.

[0076] Receive the second traffic request returned by the first target service and parse the second traffic request according to the access protocol type corresponding to the request to obtain the parsing result of the second traffic request. The parsing result of the second traffic request will also carry a distributed link tracking identifier.

[0077] Step S350: forward the second traffic request to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

[0078] Based on the distributed link tracking identifier parsed from the second traffic request and the association between the stored label information and the distributed link tracking identifier, the label information corresponding to the second traffic request can be determined, and then combined with the custom traffic forwarding rules implemented by the service grid, the second traffic request can be forwarded to the service of the main road or to the service of the traffic lane corresponding to the label information.

[0079] The traffic request forwarding method of the present embodiment utilizes a traffic lane design to isolate traffic flows in different scenarios with minimal service resources, thus saving server resources. Furthermore, operations such as traffic request parsing and tag storage and forwarding are independent of business services and unaffected by business performance bottlenecks. Business integration requires no modification and is non-invasive to the business.

[0080] In some embodiments of the present application, before receiving the first traffic request and parsing it to obtain the parsing result of the first traffic request, the traffic request transfer method also includes: intercepting the original first traffic request through a load balancer and parsing it to obtain the parsing result of the original first traffic request; matching the parsing result of the original first traffic request with the label configuration information to determine whether there is matching label information; if there is matching label information, writing the matching label information and the corresponding lane field information into the message header of the original first traffic request to obtain an updated first traffic request.

[0081] like Figure 4 As shown, the embodiment of the present application can also intercept and label the traffic request before forwarding it. The purpose is to configure the forwarding rules of the traffic request according to the needs of the actual application scenario. It can be specifically implemented through a seven-layer load balancer, Lua scripts and cache databases.

[0082] The Layer 7 load balancer serves as a unified entry point for service traffic and belongs to the application layer. It can obtain the specific content of requests. Lua scripts are used by the Layer 7 load balancer to access the cache database, read tag rule configurations, parse request content, perform tag rule matching, and tag traffic. The cache database stores tags and tag matching rules. This design meets tag configuration requirements while also accommodating high service traffic.

[0083] like Figure 6 As shown, a flow chart of a flow request marking process in an embodiment of the present application is provided, which mainly includes the following steps:

[0084] 1) Configure tag information: including tag name and matching conditions, for example, the tag name is T1, the matching condition is the value of the user number field in the request is 12345, and the tag information is written to the cache database;

[0085] 2) Write a Lua script, integrate it into the Layer 7 load balancer, and run the script. The script will intercept and parse the request to obtain the request header and message body;

[0086] 3) The script accesses the cache database based on the request information to obtain the tag configuration information and performs tag condition matching. If a matching tag exists, the lane field name and tag value are written to the request message header. Otherwise, no processing is performed and subsequent steps are executed.

[0087] In some embodiments of the present application, after determining whether the parsing result of the first traffic request also contains label information of the traffic lane, the traffic request transfer method also includes: if the parsing result of the first traffic request does not contain label information, forwarding the first traffic request to the main channel service for processing.

[0088] If the request header of the first traffic request does not contain label information, it means that the request is processed by the service of the main trunk, and the first traffic request is directly forwarded to the service of the main trunk for processing.

[0089] In some embodiments of the present application, when tag information is included, the tag information is associated with the distributed link tracking identifier and stored, including: when tag information is included, determining whether there is a high-efficiency compression bitmap corresponding to the tag information; if so, the tag information is associated with the distributed link tracking identifier and stored in the high-efficiency compression bitmap corresponding to the tag information; if not, creating a corresponding high-efficiency compression bitmap for the tag information, and the tag information is associated with the distributed link tracking identifier and stored in the high-efficiency compression bitmap corresponding to the tag information.

[0090] The embodiment of the present application can write a plug-in based on Envoy, and use distributed link tracking identifiers and efficient compression bitmaps (Roaring Bitmap) to solve the problem of traffic request association between services. Envoy is an open source edge and service proxy. In the service grid, Envoy is often used as a sidecar proxy for each service, providing network communication control and observation functions. The efficient compression bitmap is an optimized data structure designed to address the serious problem of space waste in traditional bitmaps (BitMap) when data is sparse. In the embodiment of the present application, it is mainly used as a data structure for storing the association relationship between lane label information and distributed link tracking identifiers.

[0091] During the entire process of traffic request forwarding, traffic flowing into and out of the service will be intercepted. When a traffic request flowing into the service is intercepted, the message header will be parsed according to the access protocol type corresponding to the request to obtain the distributed link tracking number and label information.

[0092] Determine whether valid label information can be parsed. If not, the traffic request belongs to the main lane and does not need to be processed. If it exists, determine whether an efficient compression bitmap corresponding to the label exists. If not, create an efficient compression bitmap for the label. This embodiment of the application creates an efficient compression bitmap for each lane label and writes the distributed link tracking number into the efficient compression bitmap of the label.

[0093] In some embodiments of the present application, forwarding the second traffic request to the second target service based on the distributed link tracking identifier, the association between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid includes: traversing the efficient compressed bitmap database corresponding to the label information according to the distributed link tracking identifier to obtain the label information corresponding to the distributed link tracking identifier; writing the label information corresponding to the distributed link tracking identifier into the request header of the second traffic request; and forwarding the second traffic request to the second target service based on the traffic forwarding rules implemented by the service grid.

[0094] When receiving a service outflow traffic request, the message header is parsed according to the access protocol type corresponding to the request to obtain the distributed link tracking identifier, and then the high-efficiency compression bitmaps corresponding to all labels are traversed based on the distributed link tracking identifier to determine in which high-efficiency compression bitmap the distributed link tracking number exists. The label information corresponding to the high-efficiency compression bitmap is written into the message header of the request, and then the traffic is forwarded according to the custom forwarding rules.

[0095] To facilitate understanding of the above embodiments, Figure 7 As shown, a flow chart of a traffic request forwarding process in an embodiment of the present application is provided.

[0096] In some embodiments of the present application, the traffic forwarding rules implemented based on the service grid forwarding the second traffic request to the second target service include: determining whether there is a second target service in the traffic lane corresponding to the label information carried in the second traffic request; if so, forwarding the second traffic request to the second target service on the traffic lane corresponding to the label information; otherwise, forwarding the second traffic request to the second target service on the main road.

[0097] The embodiment of the present application can customize traffic forwarding rules based on the service grid. For example, it can be defined that traffic is preferentially forwarded to the corresponding target service on the lane with the same label. If there is no corresponding target service on the lane with the same label or the label information is not parsed, it is forwarded to the service corresponding to the main lane.

[0098] Of course, the specific service to which the request is forwarded on the traffic lane or main road, for example, whether the outgoing request of service A is forwarded to service B or service C, is pre-set based on the request flow rules of the actual business scenario. For example, the flow rule of business requests in a certain business scenario is pre-defined as A→B→C, that is, the business request is first processed by service A, then transferred to service B for processing, and finally transferred to service C for processing.

[0099] In some embodiments of the present application, the traffic request transfer method also includes: using preset data cleaning data to clean up the data in the efficient compression bitmap corresponding to the tag information; wherein, the preset data cleaning data includes at least one of a traffic lane expiration cleaning strategy and a traffic request expiration cleaning strategy.

[0100] The embodiment of the present application can adopt a certain cleaning strategy to clean up the expired data in the efficient compression bitmap. There are mainly two scenarios and corresponding cleaning strategies:

[0101] 1) Lane expiration: When a scene goes offline, the label data of the current lane needs to be deleted to avoid memory usage. The cleanup strategy can be to directly delete the efficient compressed bitmap of the label corresponding to the lane, which is simple and efficient.

[0102] 2) Request expiration: In order to prevent the efficient compression bitmap from taking up too much memory as time goes by, it supports setting the storage duration of the request in the efficient compression bitmap, and different lanes support setting different times. It will be automatically deleted after expiration. When the label data is written to the efficient compression bitmap, the corresponding efficient compression bitmap for managing the expiration time (such as in minutes) will also be written. There will be a scheduled task in the background to regularly select expired efficient compression bitmaps, and use the efficient compression bitmap corresponding to the label to batch delete the expired efficient compression bitmaps, that is, perform a difference set on the efficient compression bitmap corresponding to the label and the expired efficient compression bitmap to achieve the purpose of data cleanup. The operation is very efficient.

[0103] like Figure 8 As shown, a structural diagram of a traffic request forwarding device based on Envoy in an embodiment of the present application is provided, which mainly includes a bitmap module, a storage interface, a read interface, a deletion module, etc. Among them, the bitmap module is used to create corresponding efficient compressed bitmap data structures for different labels, and store the requested distributed link tracking numbers with corresponding bitmap labels. The storage interface is used to process the distributed global link tracking number of the request traffic and the label in the request, and write to the corresponding bitmap. The read module is used to access the bitmap module according to the distributed global link tracking number of the request to obtain the corresponding label data. The deletion module is used to delete expired lane data and expired request data.

[0104] Envoy supports defining request routing rules through configuration files. The configuration file defines lane information and request addresses for each service in the lane, and defines routing matching rules based on the lane field in the request message header. For each specific request, the message header is parsed to obtain the lane information in the label. If the label field is not present in the request header, the request is routed to the corresponding service's main channel; if the label field is present, the request is routed to the service in the corresponding lane.

[0105] In summary, the key points of the traffic request transfer method of this application are:

[0106] 1) Traffic tagging: Using a seven-layer load balancer, Lua scripts, and a cache database, we achieve traffic matching and lane tagging. This delivers high performance, is non-invasive, and is completely unaware of upstream and downstream systems, eliminating the need for modification.

[0107] 2) Label forwarding process: Utilizing service mesh technology, distributed link tracking numbers, and an efficient compressed bitmap data structure, this system cleverly implements label forwarding and deletion between processes, with low memory usage and simple and efficient maintenance.

[0108] 3) Traffic lanes: Traffic lanes are designed based on the service mesh, which isolate traffic in different scenarios with minimal service resources. Only services that require changes need to be deployed, and services that do not require changes can be shared.

[0109] The traffic request transfer method of this application has achieved at least the following technical effects:

[0110] 1) Save server resources, reduce machine costs and service operation and maintenance complexity;

[0111] 2) Services in different scenarios can run in parallel, which speeds up project progress. At the same time, project code and request traffic do not interfere with each other, improving the robustness of the system.

[0112] 3) Non-intrusive design, no modification required for business integration, and no access cost;

[0113] 4) It has wide applicability and is not limited to specific project code language implementations and code frameworks. It is a general-purpose underlying design.

[0114] 5) Traffic tagging and label storage and forwarding are independent of business services and unaffected by business performance bottlenecks. In particular, the traffic tagging device is integrated into the Layer 7 load balancer, which can support high-concurrency scenarios and meet the needs of high-traffic businesses.

[0115] 6) Low storage space: Tag storage uses an efficient compressed bitmap data structure. For storing massive amounts of mapping data between tags and distributed link tracking identifiers, the storage space occupied is much smaller than other data structures.

[0116] The embodiment of the present application also provides a flow request transfer device 900, such as Figure 9 As shown, a schematic structural diagram of a traffic request transfer device in an embodiment of the present application is provided. The traffic request transfer device 900 includes: a first receiving unit 910, a determining unit 920, a first forwarding unit 930, a second receiving unit 940, and a second forwarding unit 950, wherein:

[0117] A first receiving unit 910 is configured to receive and parse a first traffic request to obtain a parsing result of the first traffic request, wherein the parsing result of the first traffic request includes a distributed link tracking identifier;

[0118] A determining unit 920 is configured to determine whether the parsing result of the first traffic request further includes label information of a traffic lane, where the traffic lane corresponds to the service change scenario in a one-to-one manner;

[0119] A first forwarding unit 930 is configured to associate and store the label information with the distributed link tracking identifier when the label information is included, and forward the first traffic request to a first target service on the traffic lane corresponding to the label information;

[0120] A second receiving unit 940 is configured to receive and parse a second traffic request for the first target service to obtain a parsing result of the second traffic request, where the parsing result of the second traffic request includes a distributed link tracking identifier;

[0121] The second forwarding unit 950 is used to forward the second traffic request to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

[0122] In some embodiments of the present application, the traffic request transfer device 900 also includes: an interception unit, which is used to intercept and parse the original first traffic request through a load balancer before receiving the first traffic request and parsing it to obtain the parsing result of the first traffic request, so as to obtain the parsing result of the original first traffic request; a matching unit, which is used to match the parsing result of the original first traffic request with the label configuration information to determine whether there is matching label information; and a writing unit, which is used to write the matching label information and the corresponding lane field information into the message header of the original first traffic request when there is matching label information, so as to obtain an updated first traffic request.

[0123] In some embodiments of the present application, the traffic request transfer device 900 also includes: a third forwarding unit, which is used to forward the first traffic request to the trunk service for processing when the parsing result of the first traffic request does not contain label information.

[0124] In some embodiments of the present application, the first forwarding unit 930 is specifically used to: when label information is included, determine whether there is an efficient compression bitmap corresponding to the label information; if so, associate the label information with the distributed link tracking identifier and store it in the efficient compression bitmap corresponding to the label information; if not, create a corresponding efficient compression bitmap for the label information, and associate the label information with the distributed link tracking identifier and store it in the efficient compression bitmap corresponding to the label information.

[0125] In some embodiments of the present application, the second forwarding unit 950 is specifically used to: traverse the efficient compressed bitmap database corresponding to the label information according to the distributed link tracking identifier to obtain the label information corresponding to the distributed link tracking identifier; write the label information corresponding to the distributed link tracking identifier into the request header of the second traffic request; and forward the second traffic request to the second target service based on the traffic forwarding rules implemented by the service grid.

[0126] In some embodiments of the present application, the second forwarding unit 950 is specifically used to: determine whether there is a second target service in the traffic lane corresponding to the label information carried in the second traffic request; if so, forward the second traffic request to the second target service on the traffic lane corresponding to the label information; otherwise, forward the second traffic request to the second target service on the main road.

[0127] In some embodiments of the present application, the traffic request flow transfer device 900 also includes: a cleaning unit, which is used to clean the data in the efficient compression bitmap corresponding to the tag information using preset data cleaning data; wherein, the preset data cleaning data includes at least one of the traffic lane expiration cleaning strategy and the traffic request expiration cleaning strategy.

[0128] It can be understood that the above-mentioned traffic request transfer device can implement the various steps of the traffic request transfer method provided in the aforementioned embodiment. The relevant explanations about the traffic request transfer method are applicable to the traffic request transfer device and will not be repeated here.

[0129] Figure 10 This is a schematic diagram of the structure of an electronic device according to an embodiment of the present application. Figure 10At the hardware level, the electronic device includes a processor and, optionally, an internal bus, a network interface, and memory. The memory may include internal memory, such as high-speed random-access memory (RAM), or non-volatile memory, such as at least one disk drive. Of course, the electronic device may also include other hardware required for its services.

[0130] The processor, network interface, and memory can be interconnected via an internal bus, which can be an ISA (Industry Standard Architecture) bus, a PCI (Peripheral Component Interconnect) bus, or an EISA (Extended Industry Standard Architecture) bus. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 10 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0131] The memory is used to store programs. Specifically, the program may include program code, which includes computer operating instructions. The memory may include internal memory and non-volatile memory, and provides instructions and data to the processor.

[0132] The processor reads the corresponding computer program from the non-volatile memory into the memory and then runs it, forming a traffic request flow device at the logical level. The processor executes the program stored in the memory and is specifically used to perform the following operations:

[0133] receiving a first traffic request and parsing the request to obtain a parsing result of the first traffic request, wherein the parsing result of the first traffic request includes a distributed link tracking identifier;

[0134] Determining whether the parsing result of the first traffic request further includes label information of a traffic lane, where the traffic lane corresponds to the service change scenario one by one;

[0135] In the case where the tag information is included, the tag information is associated with the distributed link tracking identifier and stored, and the first traffic request is forwarded to the first target service on the traffic lane corresponding to the tag information;

[0136] receiving a second traffic request for the first target service and parsing the request to obtain a parsing result of the second traffic request, wherein the parsing result of the second traffic request includes a distributed link tracking identifier;

[0137] The second traffic request is forwarded to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

[0138] The above application Figure 1 The methods performed by the traffic request forwarding device disclosed in the illustrated embodiments can be applied to or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method can be completed by hardware integrated logic circuits in the processor or by software instructions. The above processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. The various methods, steps, and logic block diagrams disclosed in the embodiments of this application can be implemented or executed. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in conjunction with the embodiments of this application can be directly implemented and executed by a hardware decoding processor, or by a combination of hardware and software modules in the decoding processor. The software module can be located in a storage medium well-known in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, etc. The storage medium is located in the memory, and the processor reads the information in the memory and, in conjunction with its hardware, completes the steps of the above method.

[0139] The present application also provides a computer program product, including a computer program or instructions. When executed by a processor, the computer program or instructions implements any of the aforementioned traffic request forwarding methods, and is specifically configured to perform:

[0140] receiving a first traffic request and parsing the request to obtain a parsing result of the first traffic request, wherein the parsing result of the first traffic request includes a distributed link tracking identifier;

[0141] Determining whether the parsing result of the first traffic request further includes label information of a traffic lane, where the traffic lane corresponds to the service change scenario one by one;

[0142] In the case where the tag information is included, the tag information is associated with the distributed link tracking identifier and stored, and the first traffic request is forwarded to the first target service on the traffic lane corresponding to the tag information;

[0143] receiving a second traffic request for the first target service and parsing the request to obtain a parsing result of the second traffic request, wherein the parsing result of the second traffic request includes a distributed link tracking identifier;

[0144] The second traffic request is forwarded to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

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

[0146] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowcharts and / or block diagrams, as well as combinations of processes and / or blocks in the flowcharts and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowcharts and / or block diagrams. Figure 1 a process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0147] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 a process or multiple processes and / or boxes Figure 1 The function specified in one or more boxes.

[0148] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 a process or multiple processes and / or boxes ​ A step that specifies a function in one or more boxes.

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

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

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

[0152] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

[0153] Those skilled in the art will appreciate that embodiments of the present application can be devised for a method, a system, or a computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer-readable program code thereon for use by or in connection with an instruction execution system. For the purposes of this description, a computer-usable or computer readable storage medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0154] The above descriptions are only some embodiments of the present application and are not intended to limit the present application. Various modifications and changes can be made by those skilled in the art to the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the scope of claims of the present application.

Claims

1. A traffic request transfer method, characterized in that: The traffic request transfer method includes: receiving a first traffic request and parsing the request to obtain a parsing result of the first traffic request, wherein the parsing result of the first traffic request includes a distributed link tracking identifier; Determining whether the parsing result of the first traffic request further includes label information of a traffic lane, where the traffic lane corresponds to the service change scenario one by one; In the case where the tag information is included, the tag information is associated with the distributed link tracking identifier and stored, and the first traffic request is forwarded to the first target service on the traffic lane corresponding to the tag information; receiving a second traffic request for the first target service and parsing the request to obtain a parsing result of the second traffic request, wherein the parsing result of the second traffic request includes a distributed link tracking identifier; The second traffic request is forwarded to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

2. The traffic request transfer method according to claim 1, characterized in that: Before receiving and parsing the first traffic request to obtain a parsing result of the first traffic request, the traffic request transfer method further includes: The original first traffic request is intercepted and parsed by the load balancer to obtain a parsed result of the original first traffic request; Matching the parsing result of the original first traffic request with the label configuration information to determine whether there is matching label information; In the case that matching label information exists, the matching label information and the corresponding lane field information are written into the message header of the original first traffic request to obtain an updated first traffic request.

3. The traffic request transfer method according to claim 1, characterized in that: After determining whether the parsing result of the first traffic request further includes label information of the traffic lane, the traffic request transfer method further includes: When the parsing result of the first traffic request does not include label information, the first traffic request is forwarded to the service of the main channel for processing.

4. The traffic request transfer method according to claim 1, characterized in that: In the case where the tag information is included, associating and storing the tag information with the distributed link tracking identifier includes: In the case where tag information is included, determining whether there is a high-efficiency compression bitmap corresponding to the tag information; If so, the tag information is associated with the distributed link tracking identifier and stored in a high-efficiency compression bitmap corresponding to the tag information; If it does not exist, a corresponding efficient compression bitmap is created for the tag information, and the tag information is associated with the distributed link tracking identifier and stored in the efficient compression bitmap corresponding to the tag information.

5. The traffic request transfer method according to claim 1, characterized in that: Forwarding the second traffic request to the second target service according to the distributed link tracking identifier, the association between the label information and the distributed link tracking identifier, and a traffic forwarding rule implemented based on a service grid includes: According to the distributed link tracking identifier, traverse the efficient compressed bitmap database corresponding to the tag information to obtain the tag information corresponding to the distributed link tracking identifier; Writing the label information corresponding to the distributed link tracking identifier into the request header of the second traffic request; Based on the traffic forwarding rules implemented by the service grid, the second traffic request is forwarded to the second target service.

6. The traffic request transfer method according to claim 5, characterized in that: The forwarding of the second traffic request to the second target service based on the traffic forwarding rule implemented by the service grid includes: Determining whether a second target service exists in the traffic lane corresponding to the label information carried in the second traffic request; If so, the second traffic request is forwarded to the second target service on the traffic lane corresponding to the label information; Otherwise, the second traffic request is forwarded to the second target service on the main road.

7. The traffic request transfer method according to any one of claims 4 to 6, characterized in that: The traffic request transfer method further includes: Clean the data in the efficient compression bitmap corresponding to the tag information using the preset data cleaning data; Among them, the preset data cleaning data includes at least one of a traffic lane expiration cleaning strategy and a traffic request expiration cleaning strategy.

8. A flow request transfer device, characterized in that: The traffic request transfer device includes: A first receiving unit is configured to receive and parse a first traffic request to obtain a parsing result of the first traffic request, wherein the parsing result of the first traffic request includes a distributed link tracking identifier; a determining unit, configured to determine whether the parsing result of the first traffic request further includes label information of a traffic lane, wherein the traffic lane corresponds to the service change scenario in a one-to-one manner; a first forwarding unit, configured to associate and store the label information with the distributed link tracking identifier when the label information is included, and forward the first traffic request to a first target service on the traffic lane corresponding to the label information; a second receiving unit, configured to receive and parse a second traffic request for the first target service to obtain a parsing result of the second traffic request, wherein the parsing result of the second traffic request includes a distributed link tracking identifier; The second forwarding unit is used to forward the second traffic request to the second target service according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and the traffic forwarding rules implemented based on the service grid.

9. An electronic device comprising: processor; as well as A memory arranged to store computer-executable instructions, wherein when the instructions are executed, the processor executes the traffic request forwarding method according to any one of claims 1 to 7.

10. A computer program product, comprising a computer program or instructions, wherein when the computer program or instructions are executed by a processor, the method for transferring traffic requests according to any one of claims 1 to 7 is implemented.

Images