Traffic request circulation method and device, electronic equipment and computer program product

Abstract

The invention discloses a traffic request circulation method and device, electronic equipment and a computer program product, and the method comprises the steps: receiving and analyzing a first traffic request, and obtaining a distributed link tracking identifier; determining whether label information of traffic lanes is analyzed, wherein the traffic lanes are in one-to-one correspondence with the service change scenes; if the label is analyzed, the label information and the distributed link tracking identifier are stored in an associated manner, and the first traffic request is forwarded to the service on the traffic lane corresponding to the label information; receiving and analyzing a second flow request of the service to obtain a distributed link tracking identifier; and forwarding the second flow request according to the distributed link tracking identifier, the association relationship between the label information and the distributed link tracking identifier, and a flow forwarding rule. Through the traffic lane design, the traffic isolation of different scenes is completed by using the least service resources, and the server resources are saved. And operations such as label storage and forwarding do not depend on business services and do not invade the businesses.

Description

Technical Field

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

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

[0003] A general business traffic request link may include a seven-layer load balancer, gateway, registration center, business system, database, etc., among which 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 will be developed for different scenarios and corresponding services will be deployed. In order to ensure the isolation of request traffic in each scenario, other systems on the corresponding request link also need to deploy multiple corresponding environments, so as to form a complete, isolated, and multi-environment-supporting architecture. Figure 1 As shown, a schematic diagram of a traffic request link in a multi-service environment in the prior art is provided. This solution has high deployment complexity, high cost and low efficiency, and has a large room for optimization.

[0004] An improved solution is proposed in the prior art, such as Figure 2 As shown, another flow request link diagram in a multi-business environment in the prior art is provided. In this scheme, the request information first enters the grayscale entrance, and then determines whether the request information can enter the grayscale lane based on the grayscale flow control rule. The grayscale lane delimits the grayscale version instance. That is to say, by combining the grayscale flow control rule and the grayscale lane, the flow control between the original version instance and the grayscale version instance can be achieved, thereby improving the controllability of the grayscale release. However, this scheme uses microservice-A as the grayscale entrance and is integrated into the service code in the form of SDK. There are at least the following technical problems:

[0005] 1) Highly invasive: The grayscale entry in the existing solution is coupled with the business service itself, which is highly invasive;

[0006] 2) Narrow applicability: Existing solutions only support HTTP request protocols, while in actual business scenarios, internal business systems are more likely to use RPC request protocols, so the applicability of this solution is relatively narrow;

[0007] 3) High maintenance cost: Existing solutions are integrated into various project systems in the form of SDKs. Adaptation work needs to be done for different languages ​​and project frameworks in order to complete tasks such as traffic marking, label forwarding between threads within a service, and label forwarding between services. Businesses need to be transformed and maintained in a supporting manner, and the access and maintenance costs are high.

[0008] 4) Low supported traffic: Grayscale rule parsing is located in business services, and the supported request traffic size is affected by business performance bottlenecks. Summary of the invention

[0009] The embodiments of the present application provide a traffic request transfer method, device, electronic device, and computer program product to save server resources required for traffic isolation in different scenarios and reduce intrusion into the business.

[0010] The present application embodiment adopts the following technical solutions:

[0011] In a first aspect, an embodiment of the present application provides a traffic request transfer method, the traffic request transfer method comprising:

[0012] 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;

[0013] 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 one by one;

[0014] In the case where 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 a first target service on the traffic lane corresponding to the label information;

[0015] 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;

[0016] According to 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, the second traffic request is forwarded to the second target service.

[0017] Optionally, 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:

[0018] The original first traffic request is intercepted and parsed by the load balancer to obtain a parsing 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 where there is matching label information, 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 trunk channel for processing.

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

[0024] In the case where the tag information is included, determining whether there is an efficient 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, an association relationship 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, the forwarding the second traffic request to a second target service based on a traffic forwarding rule implemented by the service grid includes:

[0032] Determine whether there is a second target service 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 trunk.

[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 flow request transfer device, the flow request transfer device comprising:

[0039] A first receiving unit, configured to receive and parse a first flow request to obtain a parsing result of the first flow request, wherein the parsing result of the first flow 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 a service change scenario one by one;

[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 of 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 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, including 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 embodiment of the present application can achieve the following beneficial effects: the flow request transfer method of the embodiment of the present application first receives and parses the first flow request to obtain the parsing result of the first flow request, and the parsing result of the first flow request includes a distributed link tracking identifier; then determines whether the parsing result of the first flow request also contains the label information of the flow lane, and the flow lane corresponds to the business change scenario one by one; then, if the label information is included, the label information is associated with the distributed link tracking identifier and stored, and the first flow request is forwarded to the first target service on the flow lane corresponding to the label information; then receives and parses the second flow request of the first target service to obtain the parsing result of the second flow request, and the parsing result of the second flow request includes 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 flow forwarding rules based on the service grid, the second flow request is forwarded to the second target service. The flow request transfer method of the embodiment of the present application can complete the isolation of different scene flows with the least service resources through the flow lane design, saving server resources. In addition, operations such as parsing of traffic requests and storage and forwarding of labels do not rely on business services and are not affected by business performance bottlenecks. Business integration does not require any transformation and does not intrude on 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 method for transferring traffic requests in an embodiment of the present application

[0053] Figure 4 A schematic diagram of a traffic request link implemented based on a traffic lane in an embodiment of the present application;

[0054] Figure 5 This is a schematic diagram of traffic request transfer between services in an embodiment of the present application;

[0055] Figure 6 A flow chart of a flow request marking process in an embodiment of the present application;

[0056] Figure 7 This is a flow chart of a traffic request forwarding process in an embodiment of the present application;

[0057] Figure 8 This is a structural diagram of a traffic request forwarding device implemented based on Envoy in an embodiment of the present application;

[0058] Fig. 9 This is a structural diagram of a flow request transfer device in an embodiment of the present application;

[0059] Fig.10 This is a schematic diagram of the structure of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0060] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0061] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0062] The present application embodiment provides a method for transferring traffic requests, such as Figure 3 As shown, a flow chart of a flow request transfer method in an embodiment of the present application is provided, and the flow request transfer method at least includes the following steps S310 to S350:

[0063] Step S310, receiving a first traffic request and parsing it 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.

[0064] The traffic request forwarding method of the embodiment of the present application can be implemented by an independently deployed traffic request forwarding device. When forwarding the traffic request, it is necessary to first receive the first traffic request sent by the application layer, and then parse the first traffic request according to the access protocol type corresponding to the request. The parsing result generally includes a distributed link tracking identifier. Usually, the service will integrate a distributed link tracking function, and the request message header will carry a link tracking number. 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 time-space relationship of the request between multiple service components.

[0065] Step S320, determining whether the parsing result of the first traffic request further includes label information of a traffic lane, wherein the traffic lane corresponds to a business change scenario one by one.

[0066] The embodiments of the present application can design traffic lanes based on the service mesh. The service mesh is an infrastructure layer for managing service communications. A set of lightweight network agents are deployed in the network. These agents are deployed together with the applications but do not invade the applications themselves, thereby achieving transparent management and regulation of inter-service communications.

[0067] The environment corresponding to the traffic lane is divided into the main lane environment and other traffic lane environments. The main lane environment is a stable public environment that includes all services on the request link, and other lane environments are isolated environments that include business changes in their respective scenarios. Traffic can request the lane environment from the main lane, or request the main lane from the lane environment, but lanes cannot request each other. The embodiment of the present application only needs to deploy services involving scene changes in the lane, and other services share the main lane service. Each traffic lane corresponds to a unique label information to identify the traffic lane. For example, label T1 represents traffic lane 1, and label T2 represents traffic lane 2.

[0068] To facilitate understanding of the above embodiments, Figure 4 As shown, a schematic diagram of a traffic request link implemented based on a traffic lane in an embodiment of the present application is provided.

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

[0070] Step S330, when 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.

[0071] If the request header is parsed to contain 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, in order to ensure that traffic can access the correct lane throughout the entire request link, the label needs to be forwarded from the upstream service to the downstream service, but without intruding 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. In the embodiment of the present application, the label information needs to be associated and stored with the distributed link tracking identifier before forwarding the request. Since the distributed link tracking identifier is information that is always carried in the request, in the subsequent request flow process, the label information can be transmitted in 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, receiving and parsing the second traffic request of 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.

[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, namely 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 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 transfer method of the embodiment of the present application can isolate traffic in different scenarios with minimal service resources through traffic lane design, saving server resources. In addition, the analysis of traffic requests and the storage and forwarding of labels do not depend on business services, are not affected by business performance bottlenecks, and do not require business integration and transformation, and are 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 mark 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 script and cache database.

[0082] As a unified entrance for business traffic, the seven-layer load balancer belongs to the application layer and can obtain the specific content of the request. Lua scripts are used by the seven-layer load balancer to access the cache database, read the label rule configuration, parse the request content, perform label rule matching and traffic labeling. The cache database is used to store labels and label matching rules. This design can not only meet the label configuration requirements, but also withstand high business 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 that the value of the user number field in the request is 12345, and the tag information is written into the cache database;

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

[0086] 3) The script accesses the cache database to obtain the tag configuration information according to the request information, and performs tag condition matching. If there is a matching tag, the lane field name and tag value are written in the message header of the request. 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 service of the main channel 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 channel, and the first traffic request is directly forwarded to the service of the main channel for processing.

[0089] In some embodiments of the present application, when the tag information is included, the tag information is associated with the distributed link tracking identifier and stored, including: when the tag information is included, determining whether there is an efficient compression bitmap corresponding to the tag information; if so, the tag information is associated with the distributed link tracking identifier and stored in the efficient compression bitmap corresponding to the tag information; if not, creating a corresponding efficient compression bitmap 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.

[0090] The embodiment of the present application can write a plug-in based on Envoy, using 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, the traffic flowing into and out of the service will be intercepted. When the traffic request flowing into the service is intercepted, the message header is 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 road and does not need to be processed. If it exists, determine whether the efficient compression bitmap corresponding to the label exists. If not, create an efficient compression bitmap for the label. The embodiment of the present 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 according to 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 compression 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 a service outflow traffic request is received, 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, and the label information corresponding to the high-efficiency compression bitmap is written into the request message header, 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 schematic diagram of a flow request forwarding process in an embodiment of the present application is provided.

[0096] In some embodiments of the present application, the traffic forwarding rules based on the service grid implementation forward 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 trunk road.

[0097] The embodiments of the present application can customize traffic forwarding rules based on the service grid. For example, the traffic can be defined to be forwarded preferentially 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, the traffic 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 trunk, 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 flow method also includes: using preset data cleaning data to clean up the data in the efficient compression bitmap corresponding to the label 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, mainly including the following 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 occupying memory. 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 avoid the high memory usage of the efficient compression bitmap 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, the efficient compression bitmap corresponding to the label and the expired efficient compression bitmap are performed. The purpose of data cleaning is achieved, and the operation is very efficient.

[0103] like Figure 8 As shown, a structural schematic 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 compression 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 requested 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 requested distributed global link tracking number 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. In the configuration file, define the lane information and request address of each service in the lane, and define the routing matching rule as the lane field in the request message header. For each specific request, parse the message header to obtain the lane information in the label. If the label does not exist in the request information header, the request will be routed to the main lane of the corresponding service; if the label field exists, the request will be routed to the service of the lane corresponding to the label.

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

[0106] 1) Traffic marking process: Using the seven-layer load balancer, Lua script, and cache database, we can match traffic and mark lane information. This is a high-performance, non-intrusive process that does not affect the upstream and downstream systems, and does not require any modification.

[0107] 2) Label forwarding process: By utilizing service mesh technology, distributed link tracking numbers, and efficient compressed bitmap data structures, the label forwarding and deletion between processes is cleverly accomplished, 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 involve changes need to be deployed, and services that do not involve changes can be shared.

[0109] The traffic request transfer method of the present 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 the project progress. At the same time, the project code and request traffic do not interfere with each other, which improves the robustness of the system;

[0112] 3) Non-intrusive design, no need 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 labeling and label storage and forwarding are independent of business services and are not affected by business performance bottlenecks. In particular, the traffic labeling device is integrated on the seven-layer load balancer, which can support high-concurrency scenarios and meet the needs of large-volume services.

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

[0116] The present application embodiment also provides a flow request transfer device 900, such as Fig. 9 As shown, a schematic diagram of the structure of a traffic request transfer device in an embodiment of the present application is provided, wherein 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 determination unit 920 is used 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 a service change scenario one by one;

[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 of 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;

[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 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 flow 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, 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: in the case of containing label information, 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 trunk 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 label information using preset data cleaning data; wherein the preset data cleaning data includes at least one of a traffic lane expiration cleaning strategy and a 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, and the relevant explanations about the traffic request transfer method are applicable to the traffic request transfer device and will not be repeated here.

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

[0130] The processor, network interface and memory can be interconnected through 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, Fig.10 Only one bidirectional arrow is used in the diagram, but this does not mean that there is only one bus or only one type of bus.

[0131] The memory is used to store the program. Specifically, the program may include a program code, and the program code includes a computer operation instruction. The memory may include a memory and a 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] 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;

[0134] 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 one by one;

[0135] In the case where 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 a first target service on the traffic lane corresponding to the label 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] According to 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, the second traffic request is forwarded to the second target service.

[0138] The above application Figure 1 The method performed by the traffic request transfer device disclosed in the illustrated embodiment can be applied to a processor or implemented by a processor. The processor may be an integrated circuit chip with signal processing capabilities. In the implementation process, each step of the above method can be completed by an integrated logic circuit of hardware in the processor or an instruction in the form of software. The above processor may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may 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 gates or transistor logic devices, discrete hardware components. The methods, steps and logic block diagrams disclosed in the embodiments of the present application can be implemented or executed. The general-purpose processor may be a microprocessor or the processor may also be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly embodied as being executed by a hardware decoding processor, or executed by a combination of hardware and software modules in a decoding processor. The software module can be located in a storage medium mature in the art, such as a random access memory, a flash memory, a read-only memory, a programmable read-only memory, or an electrically erasable programmable memory, a register, etc. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

[0139] The embodiment of the present application further proposes a computer program product, including a computer program or an instruction, which, when executed by a processor, implements any of the aforementioned traffic request transfer methods, and is specifically used to execute:

[0140] 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;

[0141] 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 one by one;

[0142] In the case where 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 a first target service on the traffic lane corresponding to the label 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] According to 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, the second traffic request is forwarded to the second target service.

[0145] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, 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 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 flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, 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 flowchart and / or block diagram. 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 capable of directing a computer or other programmable data processing device to operate 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 A 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 instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0150] The 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. The memory is an example of a computer-readable medium.

[0151] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (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 temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0152] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0153] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

[0154] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A traffic request transfer method, characterized in that: The traffic request transfer method comprises: 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; 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 one by one; In the case where 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 a first target service on the traffic lane corresponding to the label 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; According to 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, the second traffic request is forwarded to the second target service.

2. The method for transferring traffic requests according to claim 1, characterized in that: Before receiving and parsing the first traffic request to obtain the 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 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; In the case where there is matching label information, 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 method for transferring traffic requests 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 trunk channel for processing.

4. The method for transferring traffic requests 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 the tag information is included, determining whether there is an efficient 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 method for transferring traffic requests according to claim 1, characterized in that: The forwarding 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 rule based on the 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 method for transferring traffic requests 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: 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, 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 trunk.

7. The method for transferring traffic requests 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 comprises: A first receiving unit, configured to receive and parse a first flow request to obtain a parsing result of the first flow request, wherein the parsing result of the first flow 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 a service change scenario one by one; 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 of 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 executable 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 an instruction, wherein the computer program or the instruction, when executed by a processor, implements the traffic request transfer method according to any one of claims 1 to 7.

Images